linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Sowjanya Komatineni <skomatineni@nvidia.com>
Cc: Dmitry Osipenko <digetx@gmail.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Mantravadi Karthik <mkarthik@nvidia.com>,
	Shardar Mohammed <smohammed@nvidia.com>,
	Timo Alho <talho@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 V13 3/5] i2c: tegra: Add DMA support
Date: Wed, 6 Feb 2019 17:41:58 +0100	[thread overview]
Message-ID: <20190206164158.GA6205@ulmo> (raw)
In-Reply-To: <BYAPR12MB33980C126166D851B91AB187C26F0@BYAPR12MB3398.namprd12.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 2552 bytes --]

On Wed, Feb 06, 2019 at 04:38:55PM +0000, Sowjanya Komatineni wrote:
> > >> Looking into timestamps and transactions, DMA timeouts after start of DMA for I2C1 to touch during this transaction.
> > >> While it is waiting for I2C1 DMA transfer, lots of DVC transactions 
> > >> happened thru DMA which are successful
> > >>
> > >> What is the I2C1 speed?
> > > 
> > > 400KHz
> > > 
> > >> Also incase if device is running slow for some reason, probably timeout was not enough as this patch series changes timeout with base 100mS + msg transfer time based on transfer size.
> > >> Can you give quick try with increased timeout incase if device is running slow?
> > >>
> > > 
> > > Tried to increase the timeout to 1 second, doesn't help.
> > > 
> > > What helped again is the I2C HW resetting after each transfer. Likely that means that HW isn't programmed correctly, please carefully check every bit.
> > > 
> > > DMA-only + I2C HW reset: http://dpaste.com/26AQXFM.txt
> >
> > Seems I found what's the problem. Here is the fix, please include it to v14 if it is correct.
> >
> > diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c index a9391c3646b6..5ad54da70304 100644
> > --- a/drivers/i2c/busses/i2c-tegra.c
> > +++ b/drivers/i2c/busses/i2c-tegra.c
> > @@ -912,7 +912,7 @@ static irqreturn_t tegra_i2c_isr(int irq, void *dev_id)  static void tegra_i2c_config_fifo_trig(struct tegra_i2c_dev *i2c_dev,
> >                                        size_t len)  {
> > -       u32 val, reg;
> > +       u32 val = 0, reg;
> >         u8 dma_burst = 0;
> >         struct dma_slave_config slv_config = {0};
> >         struct dma_chan *chan;
> > @@ -922,7 +922,6 @@ static void tegra_i2c_config_fifo_trig(struct tegra_i2c_dev *i2c_dev,
> >                 reg = I2C_MST_FIFO_CONTROL;
> >         else
> >                 reg = I2C_FIFO_CONTROL;
> > -       val = i2c_readl(i2c_dev, reg);
>  >
>  >        if (i2c_dev->is_curr_dma_xfer) {
>  >                if (len & 0xF)
> 
> Thanks dmitry. Good catch. Didn't caught to my eyes. Yes FIFO_CONTROL is set based on read value without masking and oring causing back-back DMA transfers resulting in incorrect trig levels
> We can directly set trig levels.

It might be safer to explicitly clear the trigger levels before we
overwrite them. Though, admittedly, this register hasn't changed in
years, so it's unlikely we'll ever see it change in a way that might
result in breakage if we construct the register value from scratch.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2019-02-06 16:41 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-06 14:47 [PATCH V13 1/5] i2c: tegra: sort all the include headers alphabetically Sowjanya Komatineni
2019-02-06 14:47 ` [PATCH V13 2/5] i2c: tegra: add bus clear Master Support Sowjanya Komatineni
2019-02-06 14:47 ` [PATCH V13 3/5] i2c: tegra: Add DMA support Sowjanya Komatineni
2019-02-06 15:02   ` Dmitry Osipenko
2019-02-06 15:15     ` Sowjanya Komatineni
2019-02-06 15:55       ` Sowjanya Komatineni
2019-02-06 16:07         ` Dmitry Osipenko
2019-02-06 16:32           ` Dmitry Osipenko
2019-02-06 16:38             ` Sowjanya Komatineni
2019-02-06 16:41               ` Dmitry Osipenko
2019-02-06 16:41               ` Thierry Reding [this message]
2019-02-06 16:56                 ` Sowjanya Komatineni
2019-02-06 14:47 ` [PATCH V13 4/5] i2c: tegra: update transfer timeout Sowjanya Komatineni
2019-02-06 14:47 ` [PATCH V13 5/5] i2c: tegra: add i2c interface timing support Sowjanya Komatineni

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=20190206164158.GA6205@ulmo \
    --to=thierry.reding@gmail.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=mkarthik@nvidia.com \
    --cc=skomatineni@nvidia.com \
    --cc=smohammed@nvidia.com \
    --cc=talho@nvidia.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).