linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sowjanya Komatineni <skomatineni@nvidia.com>
To: Dmitry Osipenko <digetx@gmail.com>,
	Thierry Reding <thierry.reding@gmail.com>
Cc: <jonathanh@nvidia.com>, <linux-tegra@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <linux-i2c@vger.kernel.org>
Subject: Re: [PATCH v1] i2c: tegra: Fix i2c_writesl() to use writel() instead of writesl()
Date: Mon, 11 Jan 2021 09:38:28 -0800	[thread overview]
Message-ID: <6373bc13-a53d-2bb2-98f5-f6f01b0b8b69@nvidia.com> (raw)
In-Reply-To: <2212a21b-7dff-4ba0-a193-badd5a1770c8@gmail.com>


On 1/11/21 4:09 AM, Dmitry Osipenko wrote:
> 11.01.2021 14:50, Dmitry Osipenko пишет:
>> 20.10.2020 19:37, Sowjanya Komatineni пишет:
>>> On 10/20/20 12:48 AM, Thierry Reding wrote:
>>>> On Mon, Oct 19, 2020 at 09:03:54PM -0700, Sowjanya Komatineni wrote:
>>>>> VI I2C don't have DMA support and uses PIO mode all the time.
>>>>>
>>>>> Current driver uses writesl() to fill TX FIFO based on available
>>>>> empty slots and with this seeing strange silent hang during any I2C
>>>>> register access after filling TX FIFO with 8 words.
>>>>>
>>>>> Using writel() followed by i2c_readl() in a loop to write all words
>>>>> to TX FIFO instead of using writesl() helps for large transfers in
>>>>> PIO mode.
>>>>>
>>>>> So, this patch updates i2c_writesl() API to use writel() in a loop
>>>>> instead of writesl().
>>>>>
>>>>> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
>>>>> ---
>>>>>    drivers/i2c/busses/i2c-tegra.c | 9 ++++++---
>>>>>    1 file changed, 6 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/drivers/i2c/busses/i2c-tegra.c
>>>>> b/drivers/i2c/busses/i2c-tegra.c
>>>>> index 6f08c0c..274bf3a 100644
>>>>> --- a/drivers/i2c/busses/i2c-tegra.c
>>>>> +++ b/drivers/i2c/busses/i2c-tegra.c
>>>>> @@ -333,10 +333,13 @@ static u32 i2c_readl(struct tegra_i2c_dev
>>>>> *i2c_dev, unsigned int reg)
>>>>>        return readl_relaxed(i2c_dev->base +
>>>>> tegra_i2c_reg_addr(i2c_dev, reg));
>>>>>    }
>>>>>    -static void i2c_writesl(struct tegra_i2c_dev *i2c_dev, void *data,
>>>>> +static void i2c_writesl(struct tegra_i2c_dev *i2c_dev, u32 *data,
>>>>>                unsigned int reg, unsigned int len)
>>>>>    {
>>>>> -    writesl(i2c_dev->base + tegra_i2c_reg_addr(i2c_dev, reg), data,
>>>>> len);
>>>>> +    while (len--) {
>>>>> +        writel(*data++, i2c_dev->base + tegra_i2c_reg_addr(i2c_dev,
>>>>> reg));
>>>>> +        i2c_readl(i2c_dev, I2C_INT_STATUS);
>>>>> +    }
>>>>>    }
>>>>>      static void i2c_readsl(struct tegra_i2c_dev *i2c_dev, void *data,
>>>>> @@ -811,7 +814,7 @@ static int tegra_i2c_fill_tx_fifo(struct
>>>>> tegra_i2c_dev *i2c_dev)
>>>>>            i2c_dev->msg_buf_remaining = buf_remaining;
>>>>>            i2c_dev->msg_buf = buf + words_to_transfer *
>>>>> BYTES_PER_FIFO_WORD;
>>>>>    -        i2c_writesl(i2c_dev, buf, I2C_TX_FIFO, words_to_transfer);
>>>>> +        i2c_writesl(i2c_dev, (u32 *)buf, I2C_TX_FIFO,
>>>>> words_to_transfer);
>>>> I've thought a bit more about this and I wonder if we're simply reading
>>>> out the wrong value for tx_fifo_avail and therefore end up overflowing
>>>> the TX FIFO. Have you checked what the value is for tx_fifo_avail when
>>>> this silent hang occurs? Given that this is specific to the VI I2C I'm
>>>> wondering if this is perhaps a hardware bug where we read the wrong TX
>>>> FIFO available count.
>>>>
>>>> Thierry
>>> Yes FIFO status shows all 8 slots available.
>> Please explain how you checked that 8 slots are available, provide
>> example code.
>>
> Have you checked the FIFO overflow interrupt?

This is seen with VI I2C (which is under host1x) as we use PIO mode 
always even for large transfers.
HW wise VI I2C is similar to other I2C and FIFO depth is also 8 words.

tegra_i2c_fill_tx_fifo() reads I2C_FIFO_STATUS register field 
TX_FIFO_EMPTY_CNT which tells empty slots available in TX_FIFO that can 
be filled.
Added debug message to print empty count and, during beginning of 
transfer when it executes tegra_i2c_fill_tx_fifo(), empty slots are 8


Using writesl() for filling TX_FIFO causing silent hang immediate on any 
i2c register access after filling FIFO with 8 words and some times with 
6 words as well.

So couldn't INTERRUPT_STATUS registers to check for TX FIFO Overflows 
when this silent hang happens.

Tried to read thru back-door (JTAG path) but could not connect to JTAG 
either. Looks like Tegra chip is in some weird state.

But using writel() followed by i2c_readl helps. Not sure if any thing 
related to register access delay or some other issue.



  reply	other threads:[~2021-01-11 17:39 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-20  4:03 [PATCH v1] i2c: tegra: Fix i2c_writesl() to use writel() instead of writesl() Sowjanya Komatineni
2020-10-20  7:48 ` Thierry Reding
2020-10-20 16:37   ` Sowjanya Komatineni
2020-10-20 16:39     ` Sowjanya Komatineni
2021-01-11 11:50     ` Dmitry Osipenko
2021-01-11 12:09       ` Dmitry Osipenko
2021-01-11 17:38         ` Sowjanya Komatineni [this message]
2021-01-11 19:29           ` Dmitry Osipenko
2021-01-11 19:33             ` Sowjanya Komatineni
2021-01-12  9:32           ` David Laight
2021-01-12 16:56             ` Sowjanya Komatineni
2021-01-11  8:31 ` Thierry Reding

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6373bc13-a53d-2bb2-98f5-f6f01b0b8b69@nvidia.com \
    --to=skomatineni@nvidia.com \
    --cc=digetx@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=thierry.reding@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).