linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sowjanya Komatineni <skomatineni@nvidia.com>
To: David Laight <David.Laight@ACULAB.COM>,
	Dmitry Osipenko <digetx@gmail.com>,
	Thierry Reding <thierry.reding@gmail.com>
Cc: "jonathanh@nvidia.com" <jonathanh@nvidia.com>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>
Subject: Re: [PATCH v1] i2c: tegra: Fix i2c_writesl() to use writel() instead of writesl()
Date: Tue, 12 Jan 2021 08:56:44 -0800	[thread overview]
Message-ID: <ee6d9283-cbff-1d26-c1ea-2fff435d9c2c@nvidia.com> (raw)
In-Reply-To: <790fa75aaec146f0bb27703157c0e77a@AcuMS.aculab.com>


On 1/12/21 1:32 AM, David Laight wrote:
> From: Sowjanya Komatineni
>> Sent: 11 January 2021 17:38
> ...
>> 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.
> How much does the i2c_read() slow down the transfer?
> If the device is PCIe it is probably significant.
>
> If the underlying problem is that the Tegra chip can't handle
> back to back writes to the tx fifo maybe there are other solutions!
> 1) Send it back and ask for a working chip :-)
> 2) Maybe an interleaved write will slow things down enough?
>
> It may be worth testing back to back writes to other registers
> to see if it is a problem that is specific to the tx fifo.
>
> 	David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)

This is a known hardware bug with VI I2C controller which is under 
host1x where immediate multiple writes to TX FIFO register gets stuck 
and reading from a register allows them to be flushed out.

VI I2C is dedicated for camera sensors or HDMI2CSI bridge.


  reply	other threads:[~2021-01-12 16:57 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
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 [this message]
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=ee6d9283-cbff-1d26-c1ea-2fff435d9c2c@nvidia.com \
    --to=skomatineni@nvidia.com \
    --cc=David.Laight@ACULAB.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).