From: Sowjanya Komatineni <skomatineni@nvidia.com>
To: Thierry Reding <thierry.reding@gmail.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 V2 3/4] i2c: tegra: Add DMA Support
Date: Fri, 25 Jan 2019 23:29:43 +0000 [thread overview]
Message-ID: <BYAPR12MB33989F7CC9FCB45AE0BFC561C29B0@BYAPR12MB3398.namprd12.prod.outlook.com> (raw)
In-Reply-To: <20190125231040.GA2013@mithrandir>
> > > >>> + if (i2c_dev->has_dma) {
> > > >>> + ret = tegra_i2c_init_dma_param(i2c_dev, true);
> > > >>> + if (ret == -EPROBE_DEFER)
> > > >>> + goto disable_div_clk;
> > > >>> + ret = tegra_i2c_init_dma_param(i2c_dev, false);
> > > >>> + if (ret == -EPROBE_DEFER)
> > > >>> + goto disable_div_clk;
> > > >>
> > > >> So tegra_i2c_init_dma_param() could fail, printing a error
> > > >> message, and probe will succeed? If allocation fails during the
> > > >> driver's probe, then just fail the probe. Please give the
> > > >> rationale.
> > > >
> > > > If APB DMA probe doesn’t happen prior to tegra i2c, DMA is not
> > > > available by the time tegra_init_dma_param tries to request slave
> > > > channel and in those cases dma_request_slave_channel_reason will
> > > > return EPROBE_DEFER for tegra I2C probe to retry
> > > >
> > > > In case if DMA is available but DMA buffer allocation fails, then
> > > > tegra_i2c_init_dma_param returns ENOMEM and probe also fails
> > > > returning same ENOMEM
> > >
> > > Is that what you're going to change in the next version? Your
> > > current variant of the code doesn't fail the probe on ENOMEM and
> > > there is duplicated attempt to invoke tegra_i2c_init_dma_param()
> > > during the transfer.
> >
> > Sorry correction to my previous reply. If DMA buffer allocation
> > fails, tegra_i2c_init_dma_param returns ENOMEM but probe will succeed
> > as i2c transaction need to happen during boot for some platform
> > device programming for successful boot and they use PIO mode as xfer
> > bytes is less and deferring i2c probe for ENOMEM causes boot to fail
> > so during probe EPROBE_DEFER is only taken care.
> >
> > Re-attempt of tegra_i2c_init_dma_param in xfer happens only if no
> > successful DMA channel allocation happens prior to that ( during probe
> > in case of ENOMEM).
> > DMA mode is mainly for large transfer, and i2c xfer returning failure
> > due to failing DMA buffer allocation causes boot to hang as platform
> > device programming need to happen which doesn’t need to use DMA.
> > Will fix this and will send updated patch to reattempt DMA request and
> > buffer allocation during DMA mode transfer and will return fail for
> > DMA mode I2C transfer...
>
> I'm wondering if we shouldn't gracefully to PIO if we fail to allocate DMA buffers. Even if it is unlikely that large transfers (> than the threshold that activates the DMA paths) will be needed by critical I2C clients, there's really no reason why we can't do PIO if DMA > doesn't work for some reason.
>
> Thierry
Yes we can fall back to PIO mode incase of DMA buffer allocation failure. Will add this in next revised patch
Sowjanya
next prev parent reply other threads:[~2019-01-25 23:29 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-24 20:51 [PATCH V2 1/4] i2c: tegra: Sort all the include headers alphabetically Sowjanya Komatineni
2019-01-24 20:51 ` [PATCH V2 2/4] i2c: tegra: Update I2C transfer using buffer Sowjanya Komatineni
2019-01-25 19:55 ` Dmitry Osipenko
2019-01-25 20:20 ` Sowjanya Komatineni
2019-01-25 21:25 ` Dmitry Osipenko
2019-01-25 23:22 ` Dmitry Osipenko
2019-01-25 23:26 ` Sowjanya Komatineni
2019-01-24 20:51 ` [PATCH V2 3/4] i2c: tegra: Add DMA Support Sowjanya Komatineni
2019-01-25 19:34 ` Dmitry Osipenko
2019-01-25 20:31 ` Sowjanya Komatineni
2019-01-25 20:40 ` Dmitry Osipenko
2019-01-25 21:11 ` Sowjanya Komatineni
2019-01-25 21:49 ` Dmitry Osipenko
2019-01-25 22:09 ` Dmitry Osipenko
2019-01-25 22:22 ` Sowjanya Komatineni
2019-01-25 23:10 ` Thierry Reding
2019-01-25 23:29 ` Sowjanya Komatineni [this message]
2019-01-25 22:03 ` Dmitry Osipenko
2019-01-25 22:35 ` Dmitry Osipenko
2019-01-26 0:28 ` Dmitry Osipenko
2019-01-26 0:49 ` Dmitry Osipenko
2019-01-26 1:51 ` Sowjanya Komatineni
2019-01-24 20:51 ` [PATCH V2 4/4] i2c: tegra: Update transfer timeout Sowjanya Komatineni
2019-01-24 21:31 ` [PATCH V2 1/4] i2c: tegra: Sort all the include headers alphabetically Dmitry Osipenko
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=BYAPR12MB33989F7CC9FCB45AE0BFC561C29B0@BYAPR12MB3398.namprd12.prod.outlook.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=mkarthik@nvidia.com \
--cc=smohammed@nvidia.com \
--cc=talho@nvidia.com \
--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).