diff mbox series

[V3] i2c: i2c-qcom-geni: Correct I2C TRE sequence

Message ID 20240201101323.13676-1-quic_vdadhani@quicinc.com
State Superseded
Headers show
Series [V3] i2c: i2c-qcom-geni: Correct I2C TRE sequence | expand

Commit Message

Viken Dadhaniya Feb. 1, 2024, 10:13 a.m. UTC
For i2c read operation in GSI mode, we are getting timeout
due to malformed TRE basically incorrect TRE sequence
in gpi(drivers/dma/qcom/gpi.c) driver.

TRE stands for Transfer Ring Element - which is basically an element with
size of 4 words. It contains all information like slave address,
clk divider, dma address value data size etc).

Mainly we have 3 TREs(Config, GO and DMA tre).
- CONFIG TRE : consists of internal register configuration which is
               required before start of the transfer.
- DMA TRE :    contains DDR/Memory address, called as DMA descriptor.
- GO TRE :     contains Transfer directions, slave ID, Delay flags, Length
               of the transfer.

Driver calls GPI driver API to config each TRE depending on the protocol.
If we see GPI driver, for RX operation we are configuring DMA tre and
for TX operation we are configuring GO tre.

For read operation tre sequence will be as below which is not aligned
to hardware programming guide.

- CONFIG tre
- DMA tre
- GO tre

As per Qualcomm's internal Hardware Programming Guide, we should configure
TREs in below sequence for any RX only transfer.

- CONFIG tre
- GO tre
- DMA tre

In summary, for RX only transfers, we are reordering DMA and GO TREs.
Tested covering i2c read/write transfer on QCM6490 RB3 board.

Fixes: d8703554f4de ("i2c: qcom-geni: Add support for GPI DMA")
Signed-off-by: Viken Dadhaniya <quic_vdadhani@quicinc.com>
---
v2 -> v3:
- Update commit log to explain change in simple way.
- Correct fix tag format.

v1 -> v2:
- Remove redundant check.
- update commit log.
- add fix tag.
---
---
 drivers/i2c/busses/i2c-qcom-geni.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

Comments

Viken Dadhaniya Feb. 2, 2024, 10:43 a.m. UTC | #1
On 2/1/2024 5:24 PM, Dmitry Baryshkov wrote:
> On Thu, 1 Feb 2024 at 12:13, Viken Dadhaniya <quic_vdadhani@quicinc.com> wrote:
>>
>> For i2c read operation in GSI mode, we are getting timeout
>> due to malformed TRE basically incorrect TRE sequence
>> in gpi(drivers/dma/qcom/gpi.c) driver.
>>
>> TRE stands for Transfer Ring Element - which is basically an element with
>> size of 4 words. It contains all information like slave address,
>> clk divider, dma address value data size etc).
>>
>> Mainly we have 3 TREs(Config, GO and DMA tre).
>> - CONFIG TRE : consists of internal register configuration which is
>>                 required before start of the transfer.
>> - DMA TRE :    contains DDR/Memory address, called as DMA descriptor.
>> - GO TRE :     contains Transfer directions, slave ID, Delay flags, Length
>>                 of the transfer.
>>
>> Driver calls GPI driver API to config each TRE depending on the protocol.
>> If we see GPI driver, for RX operation we are configuring DMA tre and
>> for TX operation we are configuring GO tre.
>>
>> For read operation tre sequence will be as below which is not aligned
>> to hardware programming guide.
>>
>> - CONFIG tre
>> - DMA tre
>> - GO tre
>>
>> As per Qualcomm's internal Hardware Programming Guide, we should configure
>> TREs in below sequence for any RX only transfer.
>>
>> - CONFIG tre
>> - GO tre
>> - DMA tre
>>
>> In summary, for RX only transfers, we are reordering DMA and GO TREs.
>> Tested covering i2c read/write transfer on QCM6490 RB3 board.
> 
> This hasn't improved. You must describe what is the connection between
> TRE types and the geni_i2c_gpi calls.
> It is not obvious until somebody looks into the GPI DMA driver.
> 
> Another point, for some reason you are still using just the patch
> version in email subject. Please fix your setup so that the email
> subject also includes the `[PATCH` part in the subject, which is there
> by default.
> Hint: git format-patch -1 -v4 will do that for you without a need to
> correct anything afterwards.
> 

At high level, let me explain the I2C to GPI driver flow in general.

I2C driver calls GPI driver exposed functions which will prepare all the 
TREs as per programming guide and
queues to the GPI DMA engine for execution. Upon completion of the 
Transfer, GPI DMA engine will generate an
interrupt which will be handled inside the GPIO driver. Then GPI driver 
will call DMA framework registered callback by i2c.
Upon receiving this callback, i2c driver marks the transfer completion.

>>
>> Fixes: d8703554f4de ("i2c: qcom-geni: Add support for GPI DMA")
>> Signed-off-by: Viken Dadhaniya <quic_vdadhani@quicinc.com>
> 
> I think you got some review tags for v2, didn't you? They should have
> been included here, otherwise the efforts spent by the reviewer are
> lost.
> 

Sorry, missed to add reviewed-by tag.
Andi will help to update.

>> ---
>> v2 -> v3:
>> - Update commit log to explain change in simple way.
>> - Correct fix tag format.
>>
>> v1 -> v2:
>> - Remove redundant check.
>> - update commit log.
>> - add fix tag.
>> ---
>> ---
>>   drivers/i2c/busses/i2c-qcom-geni.c | 14 +++++++-------
>>   1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c
>> index 0d2e7171e3a6..da94df466e83 100644
>> --- a/drivers/i2c/busses/i2c-qcom-geni.c
>> +++ b/drivers/i2c/busses/i2c-qcom-geni.c
>> @@ -613,20 +613,20 @@ static int geni_i2c_gpi_xfer(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], i
>>
>>                  peripheral.addr = msgs[i].addr;
>>
>> +               ret =  geni_i2c_gpi(gi2c, &msgs[i], &config,
>> +                                   &tx_addr, &tx_buf, I2C_WRITE, gi2c->tx_c);
>> +               if (ret)
>> +                       goto err;
>> +
>>                  if (msgs[i].flags & I2C_M_RD) {
>>                          ret =  geni_i2c_gpi(gi2c, &msgs[i], &config,
>>                                              &rx_addr, &rx_buf, I2C_READ, gi2c->rx_c);
>>                          if (ret)
>>                                  goto err;
>> -               }
>> -
>> -               ret =  geni_i2c_gpi(gi2c, &msgs[i], &config,
>> -                                   &tx_addr, &tx_buf, I2C_WRITE, gi2c->tx_c);
>> -               if (ret)
>> -                       goto err;
>>
>> -               if (msgs[i].flags & I2C_M_RD)
>>                          dma_async_issue_pending(gi2c->rx_c);
>> +               }
>> +
>>                  dma_async_issue_pending(gi2c->tx_c);
>>
>>                  timeout = wait_for_completion_timeout(&gi2c->done, XFER_TIMEOUT);
>> --
>> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
>> of Code Aurora Forum, hosted by The Linux Foundation
>>
>>
> 
>
Andi Shyti Feb. 8, 2024, 10:02 a.m. UTC | #2
Hi Viken, Dmitry,

On Fri, Feb 02, 2024 at 04:13:06PM +0530, Viken Dadhaniya wrote:
> 
> On 2/1/2024 5:24 PM, Dmitry Baryshkov wrote:
> > On Thu, 1 Feb 2024 at 12:13, Viken Dadhaniya <quic_vdadhani@quicinc.com> wrote:
> > > 
> > > For i2c read operation in GSI mode, we are getting timeout
> > > due to malformed TRE basically incorrect TRE sequence
> > > in gpi(drivers/dma/qcom/gpi.c) driver.
> > > 
> > > TRE stands for Transfer Ring Element - which is basically an element with
> > > size of 4 words. It contains all information like slave address,
> > > clk divider, dma address value data size etc).
> > > 
> > > Mainly we have 3 TREs(Config, GO and DMA tre).
> > > - CONFIG TRE : consists of internal register configuration which is
> > >                 required before start of the transfer.
> > > - DMA TRE :    contains DDR/Memory address, called as DMA descriptor.
> > > - GO TRE :     contains Transfer directions, slave ID, Delay flags, Length
> > >                 of the transfer.
> > > 
> > > Driver calls GPI driver API to config each TRE depending on the protocol.
> > > If we see GPI driver, for RX operation we are configuring DMA tre and
> > > for TX operation we are configuring GO tre.
> > > 
> > > For read operation tre sequence will be as below which is not aligned
> > > to hardware programming guide.
> > > 
> > > - CONFIG tre
> > > - DMA tre
> > > - GO tre
> > > 
> > > As per Qualcomm's internal Hardware Programming Guide, we should configure
> > > TREs in below sequence for any RX only transfer.
> > > 
> > > - CONFIG tre
> > > - GO tre
> > > - DMA tre
> > > 
> > > In summary, for RX only transfers, we are reordering DMA and GO TREs.
> > > Tested covering i2c read/write transfer on QCM6490 RB3 board.
> > 
> > This hasn't improved. You must describe what is the connection between
> > TRE types and the geni_i2c_gpi calls.
> > It is not obvious until somebody looks into the GPI DMA driver.
> > 
> > Another point, for some reason you are still using just the patch
> > version in email subject. Please fix your setup so that the email
> > subject also includes the `[PATCH` part in the subject, which is there
> > by default.
> > Hint: git format-patch -1 -v4 will do that for you without a need to
> > correct anything afterwards.
> > 
> 
> At high level, let me explain the I2C to GPI driver flow in general.
> 
> I2C driver calls GPI driver exposed functions which will prepare all the
> TREs as per programming guide and
> queues to the GPI DMA engine for execution. Upon completion of the Transfer,
> GPI DMA engine will generate an
> interrupt which will be handled inside the GPIO driver. Then GPI driver will
> call DMA framework registered callback by i2c.
> Upon receiving this callback, i2c driver marks the transfer completion.

Any news about this? Dmitry do you still have concerns? We can
add this last description in the commit log, as well, if needed.

Andi
Dmitry Baryshkov Feb. 8, 2024, 11:04 a.m. UTC | #3
On Thu, 8 Feb 2024 at 12:02, Andi Shyti <andi.shyti@kernel.org> wrote:
>
> Hi Viken, Dmitry,
>
> On Fri, Feb 02, 2024 at 04:13:06PM +0530, Viken Dadhaniya wrote:
> >
> > On 2/1/2024 5:24 PM, Dmitry Baryshkov wrote:
> > > On Thu, 1 Feb 2024 at 12:13, Viken Dadhaniya <quic_vdadhani@quicinc.com> wrote:
> > > >
> > > > For i2c read operation in GSI mode, we are getting timeout
> > > > due to malformed TRE basically incorrect TRE sequence
> > > > in gpi(drivers/dma/qcom/gpi.c) driver.
> > > >
> > > > TRE stands for Transfer Ring Element - which is basically an element with
> > > > size of 4 words. It contains all information like slave address,
> > > > clk divider, dma address value data size etc).
> > > >
> > > > Mainly we have 3 TREs(Config, GO and DMA tre).
> > > > - CONFIG TRE : consists of internal register configuration which is
> > > >                 required before start of the transfer.
> > > > - DMA TRE :    contains DDR/Memory address, called as DMA descriptor.
> > > > - GO TRE :     contains Transfer directions, slave ID, Delay flags, Length
> > > >                 of the transfer.
> > > >
> > > > Driver calls GPI driver API to config each TRE depending on the protocol.
> > > > If we see GPI driver, for RX operation we are configuring DMA tre and
> > > > for TX operation we are configuring GO tre.
> > > >
> > > > For read operation tre sequence will be as below which is not aligned
> > > > to hardware programming guide.
> > > >
> > > > - CONFIG tre
> > > > - DMA tre
> > > > - GO tre
> > > >
> > > > As per Qualcomm's internal Hardware Programming Guide, we should configure
> > > > TREs in below sequence for any RX only transfer.
> > > >
> > > > - CONFIG tre
> > > > - GO tre
> > > > - DMA tre
> > > >
> > > > In summary, for RX only transfers, we are reordering DMA and GO TREs.
> > > > Tested covering i2c read/write transfer on QCM6490 RB3 board.
> > >
> > > This hasn't improved. You must describe what is the connection between
> > > TRE types and the geni_i2c_gpi calls.
> > > It is not obvious until somebody looks into the GPI DMA driver.
> > >
> > > Another point, for some reason you are still using just the patch
> > > version in email subject. Please fix your setup so that the email
> > > subject also includes the `[PATCH` part in the subject, which is there
> > > by default.
> > > Hint: git format-patch -1 -v4 will do that for you without a need to
> > > correct anything afterwards.
> > >
> >
> > At high level, let me explain the I2C to GPI driver flow in general.
> >
> > I2C driver calls GPI driver exposed functions which will prepare all the
> > TREs as per programming guide and
> > queues to the GPI DMA engine for execution. Upon completion of the Transfer,
> > GPI DMA engine will generate an
> > interrupt which will be handled inside the GPIO driver. Then GPI driver will
> > call DMA framework registered callback by i2c.
> > Upon receiving this callback, i2c driver marks the transfer completion.
>
> Any news about this? Dmitry do you still have concerns? We can
> add this last description in the commit log, as well, if needed.

I was looking for pretty simple addition to the commit message, that
links existing commit message to the actual source code change: that
geni_i2c_gpi(I2C_WRITE) results in the GO TRE and
geni_i2c_gpi(I2C_READ) generates DMA TRE. But I haven't seen anything
sensible up to now. So far we have a nice description of required
programming sequence in terms of CONFIG, GO, DMA TREs and then source
code change that seems completely unrelated to the commit message,
unless one actually goes deep into the corresponding GPI DMA driver.
Andi Shyti Feb. 8, 2024, 11:59 a.m. UTC | #4
Hi Dmitry,

On Thu, Feb 08, 2024 at 01:04:14PM +0200, Dmitry Baryshkov wrote:
> On Thu, 8 Feb 2024 at 12:02, Andi Shyti <andi.shyti@kernel.org> wrote:
> >
> > Hi Viken, Dmitry,
> >
> > On Fri, Feb 02, 2024 at 04:13:06PM +0530, Viken Dadhaniya wrote:
> > >
> > > On 2/1/2024 5:24 PM, Dmitry Baryshkov wrote:
> > > > On Thu, 1 Feb 2024 at 12:13, Viken Dadhaniya <quic_vdadhani@quicinc.com> wrote:
> > > > >
> > > > > For i2c read operation in GSI mode, we are getting timeout
> > > > > due to malformed TRE basically incorrect TRE sequence
> > > > > in gpi(drivers/dma/qcom/gpi.c) driver.
> > > > >
> > > > > TRE stands for Transfer Ring Element - which is basically an element with
> > > > > size of 4 words. It contains all information like slave address,
> > > > > clk divider, dma address value data size etc).
> > > > >
> > > > > Mainly we have 3 TREs(Config, GO and DMA tre).
> > > > > - CONFIG TRE : consists of internal register configuration which is
> > > > >                 required before start of the transfer.
> > > > > - DMA TRE :    contains DDR/Memory address, called as DMA descriptor.
> > > > > - GO TRE :     contains Transfer directions, slave ID, Delay flags, Length
> > > > >                 of the transfer.
> > > > >
> > > > > Driver calls GPI driver API to config each TRE depending on the protocol.
> > > > > If we see GPI driver, for RX operation we are configuring DMA tre and
> > > > > for TX operation we are configuring GO tre.
> > > > >
> > > > > For read operation tre sequence will be as below which is not aligned
> > > > > to hardware programming guide.
> > > > >
> > > > > - CONFIG tre
> > > > > - DMA tre
> > > > > - GO tre
> > > > >
> > > > > As per Qualcomm's internal Hardware Programming Guide, we should configure
> > > > > TREs in below sequence for any RX only transfer.
> > > > >
> > > > > - CONFIG tre
> > > > > - GO tre
> > > > > - DMA tre
> > > > >
> > > > > In summary, for RX only transfers, we are reordering DMA and GO TREs.
> > > > > Tested covering i2c read/write transfer on QCM6490 RB3 board.
> > > >
> > > > This hasn't improved. You must describe what is the connection between
> > > > TRE types and the geni_i2c_gpi calls.
> > > > It is not obvious until somebody looks into the GPI DMA driver.
> > > >
> > > > Another point, for some reason you are still using just the patch
> > > > version in email subject. Please fix your setup so that the email
> > > > subject also includes the `[PATCH` part in the subject, which is there
> > > > by default.
> > > > Hint: git format-patch -1 -v4 will do that for you without a need to
> > > > correct anything afterwards.
> > > >
> > >
> > > At high level, let me explain the I2C to GPI driver flow in general.
> > >
> > > I2C driver calls GPI driver exposed functions which will prepare all the
> > > TREs as per programming guide and
> > > queues to the GPI DMA engine for execution. Upon completion of the Transfer,
> > > GPI DMA engine will generate an
> > > interrupt which will be handled inside the GPIO driver. Then GPI driver will
> > > call DMA framework registered callback by i2c.
> > > Upon receiving this callback, i2c driver marks the transfer completion.
> >
> > Any news about this? Dmitry do you still have concerns? We can
> > add this last description in the commit log, as well, if needed.
> 
> I was looking for pretty simple addition to the commit message, that
> links existing commit message to the actual source code change: that
> geni_i2c_gpi(I2C_WRITE) results in the GO TRE and
> geni_i2c_gpi(I2C_READ) generates DMA TRE. But I haven't seen anything
> sensible up to now. So far we have a nice description of required
> programming sequence in terms of CONFIG, GO, DMA TREs and then source
> code change that seems completely unrelated to the commit message,
> unless one actually goes deep into the corresponding GPI DMA driver.

Agree. I can't take this patch until the commit message has a
proper description and until Dmitry doesn't have any concerns
pending.

Thanks,
Andi
Konrad Dybcio Feb. 9, 2024, 2:41 p.m. UTC | #5
On 8.02.2024 12:59, Andi Shyti wrote:
> Hi Dmitry,
> 
> On Thu, Feb 08, 2024 at 01:04:14PM +0200, Dmitry Baryshkov wrote:
>> On Thu, 8 Feb 2024 at 12:02, Andi Shyti <andi.shyti@kernel.org> wrote:
>>>
>>> Hi Viken, Dmitry,
>>>
>>> On Fri, Feb 02, 2024 at 04:13:06PM +0530, Viken Dadhaniya wrote:
>>>>
>>>> On 2/1/2024 5:24 PM, Dmitry Baryshkov wrote:
>>>>> On Thu, 1 Feb 2024 at 12:13, Viken Dadhaniya <quic_vdadhani@quicinc.com> wrote:
>>>>>>
>>>>>> For i2c read operation in GSI mode, we are getting timeout
>>>>>> due to malformed TRE basically incorrect TRE sequence
>>>>>> in gpi(drivers/dma/qcom/gpi.c) driver.
>>>>>>
>>>>>> TRE stands for Transfer Ring Element - which is basically an element with
>>>>>> size of 4 words. It contains all information like slave address,
>>>>>> clk divider, dma address value data size etc).
>>>>>>
>>>>>> Mainly we have 3 TREs(Config, GO and DMA tre).
>>>>>> - CONFIG TRE : consists of internal register configuration which is
>>>>>>                 required before start of the transfer.
>>>>>> - DMA TRE :    contains DDR/Memory address, called as DMA descriptor.
>>>>>> - GO TRE :     contains Transfer directions, slave ID, Delay flags, Length
>>>>>>                 of the transfer.
>>>>>>
>>>>>> Driver calls GPI driver API to config each TRE depending on the protocol.
>>>>>> If we see GPI driver, for RX operation we are configuring DMA tre and
>>>>>> for TX operation we are configuring GO tre.
>>>>>>
>>>>>> For read operation tre sequence will be as below which is not aligned
>>>>>> to hardware programming guide.
>>>>>>
>>>>>> - CONFIG tre
>>>>>> - DMA tre
>>>>>> - GO tre
>>>>>>
>>>>>> As per Qualcomm's internal Hardware Programming Guide, we should configure
>>>>>> TREs in below sequence for any RX only transfer.
>>>>>>
>>>>>> - CONFIG tre
>>>>>> - GO tre
>>>>>> - DMA tre
>>>>>>
>>>>>> In summary, for RX only transfers, we are reordering DMA and GO TREs.
>>>>>> Tested covering i2c read/write transfer on QCM6490 RB3 board.
>>>>>
>>>>> This hasn't improved. You must describe what is the connection between
>>>>> TRE types and the geni_i2c_gpi calls.
>>>>> It is not obvious until somebody looks into the GPI DMA driver.
>>>>>
>>>>> Another point, for some reason you are still using just the patch
>>>>> version in email subject. Please fix your setup so that the email
>>>>> subject also includes the `[PATCH` part in the subject, which is there
>>>>> by default.
>>>>> Hint: git format-patch -1 -v4 will do that for you without a need to
>>>>> correct anything afterwards.
>>>>>
>>>>
>>>> At high level, let me explain the I2C to GPI driver flow in general.
>>>>
>>>> I2C driver calls GPI driver exposed functions which will prepare all the
>>>> TREs as per programming guide and
>>>> queues to the GPI DMA engine for execution. Upon completion of the Transfer,
>>>> GPI DMA engine will generate an
>>>> interrupt which will be handled inside the GPIO driver. Then GPI driver will
>>>> call DMA framework registered callback by i2c.
>>>> Upon receiving this callback, i2c driver marks the transfer completion.
>>>
>>> Any news about this? Dmitry do you still have concerns? We can
>>> add this last description in the commit log, as well, if needed.
>>
>> I was looking for pretty simple addition to the commit message, that
>> links existing commit message to the actual source code change: that
>> geni_i2c_gpi(I2C_WRITE) results in the GO TRE and
>> geni_i2c_gpi(I2C_READ) generates DMA TRE. But I haven't seen anything
>> sensible up to now. So far we have a nice description of required
>> programming sequence in terms of CONFIG, GO, DMA TREs and then source
>> code change that seems completely unrelated to the commit message,
>> unless one actually goes deep into the corresponding GPI DMA driver.
> 
> Agree. I can't take this patch until the commit message has a
> proper description and until Dmitry doesn't have any concerns
> pending.

And please, please, include the word PATCH in the square brackets in
the subject, it's landing in the wrong email folders for a number of
folks..

Konrad
Viken Dadhaniya Feb. 12, 2024, 12:56 p.m. UTC | #6
On 2/8/2024 4:34 PM, Dmitry Baryshkov wrote:
> On Thu, 8 Feb 2024 at 12:02, Andi Shyti <andi.shyti@kernel.org> wrote:
>>
>> Hi Viken, Dmitry,
>>
>> On Fri, Feb 02, 2024 at 04:13:06PM +0530, Viken Dadhaniya wrote:
>>>
>>> On 2/1/2024 5:24 PM, Dmitry Baryshkov wrote:
>>>> On Thu, 1 Feb 2024 at 12:13, Viken Dadhaniya <quic_vdadhani@quicinc.com> wrote:
>>>>>
>>>>> For i2c read operation in GSI mode, we are getting timeout
>>>>> due to malformed TRE basically incorrect TRE sequence
>>>>> in gpi(drivers/dma/qcom/gpi.c) driver.
>>>>>
>>>>> TRE stands for Transfer Ring Element - which is basically an element with
>>>>> size of 4 words. It contains all information like slave address,
>>>>> clk divider, dma address value data size etc).
>>>>>
>>>>> Mainly we have 3 TREs(Config, GO and DMA tre).
>>>>> - CONFIG TRE : consists of internal register configuration which is
>>>>>                  required before start of the transfer.
>>>>> - DMA TRE :    contains DDR/Memory address, called as DMA descriptor.
>>>>> - GO TRE :     contains Transfer directions, slave ID, Delay flags, Length
>>>>>                  of the transfer.
>>>>>
>>>>> Driver calls GPI driver API to config each TRE depending on the protocol.
>>>>> If we see GPI driver, for RX operation we are configuring DMA tre and
>>>>> for TX operation we are configuring GO tre.
>>>>>
>>>>> For read operation tre sequence will be as below which is not aligned
>>>>> to hardware programming guide.
>>>>>
>>>>> - CONFIG tre
>>>>> - DMA tre
>>>>> - GO tre
>>>>>
>>>>> As per Qualcomm's internal Hardware Programming Guide, we should configure
>>>>> TREs in below sequence for any RX only transfer.
>>>>>
>>>>> - CONFIG tre
>>>>> - GO tre
>>>>> - DMA tre
>>>>>
>>>>> In summary, for RX only transfers, we are reordering DMA and GO TREs.
>>>>> Tested covering i2c read/write transfer on QCM6490 RB3 board.
>>>>
>>>> This hasn't improved. You must describe what is the connection between
>>>> TRE types and the geni_i2c_gpi calls.
>>>> It is not obvious until somebody looks into the GPI DMA driver.
>>>>
>>>> Another point, for some reason you are still using just the patch
>>>> version in email subject. Please fix your setup so that the email
>>>> subject also includes the `[PATCH` part in the subject, which is there
>>>> by default.
>>>> Hint: git format-patch -1 -v4 will do that for you without a need to
>>>> correct anything afterwards.
>>>>
>>>
>>> At high level, let me explain the I2C to GPI driver flow in general.
>>>
>>> I2C driver calls GPI driver exposed functions which will prepare all the
>>> TREs as per programming guide and
>>> queues to the GPI DMA engine for execution. Upon completion of the Transfer,
>>> GPI DMA engine will generate an
>>> interrupt which will be handled inside the GPIO driver. Then GPI driver will
>>> call DMA framework registered callback by i2c.
>>> Upon receiving this callback, i2c driver marks the transfer completion.
>>
>> Any news about this? Dmitry do you still have concerns? We can
>> add this last description in the commit log, as well, if needed.
> 
> I was looking for pretty simple addition to the commit message, that
> links existing commit message to the actual source code change: that
> geni_i2c_gpi(I2C_WRITE) results in the GO TRE and
> geni_i2c_gpi(I2C_READ) generates DMA TRE. But I haven't seen anything
> sensible up to now. So far we have a nice description of required
> programming sequence in terms of CONFIG, GO, DMA TREs and then source
> code change that seems completely unrelated to the commit message,
> unless one actually goes deep into the corresponding GPI DMA driver.
> 

Updated commit log in V4
Viken Dadhaniya Feb. 12, 2024, 12:58 p.m. UTC | #7
On 2/9/2024 8:11 PM, Konrad Dybcio wrote:
> On 8.02.2024 12:59, Andi Shyti wrote:
>> Hi Dmitry,
>>
>> On Thu, Feb 08, 2024 at 01:04:14PM +0200, Dmitry Baryshkov wrote:
>>> On Thu, 8 Feb 2024 at 12:02, Andi Shyti <andi.shyti@kernel.org> wrote:
>>>>
>>>> Hi Viken, Dmitry,
>>>>
>>>> On Fri, Feb 02, 2024 at 04:13:06PM +0530, Viken Dadhaniya wrote:
>>>>>
>>>>> On 2/1/2024 5:24 PM, Dmitry Baryshkov wrote:
>>>>>> On Thu, 1 Feb 2024 at 12:13, Viken Dadhaniya <quic_vdadhani@quicinc.com> wrote:
>>>>>>>
>>>>>>> For i2c read operation in GSI mode, we are getting timeout
>>>>>>> due to malformed TRE basically incorrect TRE sequence
>>>>>>> in gpi(drivers/dma/qcom/gpi.c) driver.
>>>>>>>
>>>>>>> TRE stands for Transfer Ring Element - which is basically an element with
>>>>>>> size of 4 words. It contains all information like slave address,
>>>>>>> clk divider, dma address value data size etc).
>>>>>>>
>>>>>>> Mainly we have 3 TREs(Config, GO and DMA tre).
>>>>>>> - CONFIG TRE : consists of internal register configuration which is
>>>>>>>                  required before start of the transfer.
>>>>>>> - DMA TRE :    contains DDR/Memory address, called as DMA descriptor.
>>>>>>> - GO TRE :     contains Transfer directions, slave ID, Delay flags, Length
>>>>>>>                  of the transfer.
>>>>>>>
>>>>>>> Driver calls GPI driver API to config each TRE depending on the protocol.
>>>>>>> If we see GPI driver, for RX operation we are configuring DMA tre and
>>>>>>> for TX operation we are configuring GO tre.
>>>>>>>
>>>>>>> For read operation tre sequence will be as below which is not aligned
>>>>>>> to hardware programming guide.
>>>>>>>
>>>>>>> - CONFIG tre
>>>>>>> - DMA tre
>>>>>>> - GO tre
>>>>>>>
>>>>>>> As per Qualcomm's internal Hardware Programming Guide, we should configure
>>>>>>> TREs in below sequence for any RX only transfer.
>>>>>>>
>>>>>>> - CONFIG tre
>>>>>>> - GO tre
>>>>>>> - DMA tre
>>>>>>>
>>>>>>> In summary, for RX only transfers, we are reordering DMA and GO TREs.
>>>>>>> Tested covering i2c read/write transfer on QCM6490 RB3 board.
>>>>>>
>>>>>> This hasn't improved. You must describe what is the connection between
>>>>>> TRE types and the geni_i2c_gpi calls.
>>>>>> It is not obvious until somebody looks into the GPI DMA driver.
>>>>>>
>>>>>> Another point, for some reason you are still using just the patch
>>>>>> version in email subject. Please fix your setup so that the email
>>>>>> subject also includes the `[PATCH` part in the subject, which is there
>>>>>> by default.
>>>>>> Hint: git format-patch -1 -v4 will do that for you without a need to
>>>>>> correct anything afterwards.
>>>>>>
>>>>>
>>>>> At high level, let me explain the I2C to GPI driver flow in general.
>>>>>
>>>>> I2C driver calls GPI driver exposed functions which will prepare all the
>>>>> TREs as per programming guide and
>>>>> queues to the GPI DMA engine for execution. Upon completion of the Transfer,
>>>>> GPI DMA engine will generate an
>>>>> interrupt which will be handled inside the GPIO driver. Then GPI driver will
>>>>> call DMA framework registered callback by i2c.
>>>>> Upon receiving this callback, i2c driver marks the transfer completion.
>>>>
>>>> Any news about this? Dmitry do you still have concerns? We can
>>>> add this last description in the commit log, as well, if needed.
>>>
>>> I was looking for pretty simple addition to the commit message, that
>>> links existing commit message to the actual source code change: that
>>> geni_i2c_gpi(I2C_WRITE) results in the GO TRE and
>>> geni_i2c_gpi(I2C_READ) generates DMA TRE. But I haven't seen anything
>>> sensible up to now. So far we have a nice description of required
>>> programming sequence in terms of CONFIG, GO, DMA TREs and then source
>>> code change that seems completely unrelated to the commit message,
>>> unless one actually goes deep into the corresponding GPI DMA driver.
>>
>> Agree. I can't take this patch until the commit message has a
>> proper description and until Dmitry doesn't have any concerns
>> pending.
> 
> And please, please, include the word PATCH in the square brackets in
> the subject, it's landing in the wrong email folders for a number of
> folks..

Included "PATCH" string in subject in V4.

> 
> Konrad
diff mbox series

Patch

diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c
index 0d2e7171e3a6..da94df466e83 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -613,20 +613,20 @@  static int geni_i2c_gpi_xfer(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], i
 
 		peripheral.addr = msgs[i].addr;
 
+		ret =  geni_i2c_gpi(gi2c, &msgs[i], &config,
+				    &tx_addr, &tx_buf, I2C_WRITE, gi2c->tx_c);
+		if (ret)
+			goto err;
+
 		if (msgs[i].flags & I2C_M_RD) {
 			ret =  geni_i2c_gpi(gi2c, &msgs[i], &config,
 					    &rx_addr, &rx_buf, I2C_READ, gi2c->rx_c);
 			if (ret)
 				goto err;
-		}
-
-		ret =  geni_i2c_gpi(gi2c, &msgs[i], &config,
-				    &tx_addr, &tx_buf, I2C_WRITE, gi2c->tx_c);
-		if (ret)
-			goto err;
 
-		if (msgs[i].flags & I2C_M_RD)
 			dma_async_issue_pending(gi2c->rx_c);
+		}
+
 		dma_async_issue_pending(gi2c->tx_c);
 
 		timeout = wait_for_completion_timeout(&gi2c->done, XFER_TIMEOUT);