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@gmail.com" <thierry.reding@gmail.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Mantravadi Karthik <mkarthik@nvidia.com>,
	Shardar Mohammed <smohammed@nvidia.com>,
	Timo Alho <talho@nvidia.com>
Cc: "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: Sat, 26 Jan 2019 01:51:59 +0000	[thread overview]
Message-ID: <BYAPR12MB33981C0EE06C88C9814B431EC2940@BYAPR12MB3398.namprd12.prod.outlook.com> (raw)
In-Reply-To: <e782dfd3-4dc4-4f69-e360-f38e4705fdb4@gmail.com>

> > +static int tegra_i2c_init_dma_param(struct tegra_i2c_dev *i2c_dev,
> > +				    bool dma_to_memory)
> > +{
> > +	struct dma_chan *dma_chan;
> > +	u32 *dma_buf;
> > +	dma_addr_t dma_phys;
> > +	int ret;
> > +	const char *chan_name = dma_to_memory ? "rx" : "tx";
> > +
> > +	dma_chan = dma_request_slave_channel_reason(i2c_dev->dev, chan_name);
> > +	if (IS_ERR(dma_chan))
> > +		return PTR_ERR(dma_chan);
>
> Here shall be a check of whether dma_buf is already allocated, otherwise it will be allocated twice and the first allocation turned into memleak:
>
>	if (i2c_dev->dma_buf)
>		return 0;

If dma_buf is allocated already then dma channels will be assigned and it will not perform init dma again.
So if dma buf allocation happens already then it will not come here again.

> > +
> > +	dma_buf = dma_alloc_coherent(i2c_dev->dev, i2c_dev->dma_buf_size,
> > +				     &dma_phys, GFP_KERNEL);
> > +
>
> I'm wondering whether a write-combined DMA mapping will be more optimal than having L2 flushes / invalidation for the "coherent" allocations. 
>
> And I'm now questioning whether there is any real benefit from the DMA transferring at all, given the DMA bounce-buffer CPU read/write overhead. It looks to me that the whole purpose of the I2C DMA transferring is to move data from (to) some I2C device to a > > some device on the APB bus, bypassing the CPU. If that's is the case, then this patch may not really worth the effort and instead could only hurt the transferring performance. Please provide some performance results or correct me if I'm wrong.
>
> [snip]

DMA transfer helps to reduce overhead only during large transfer which is very rare operation. Will check and provide some performance data...

> >  
> >  	if (!i2c_dev->hw->has_single_clk_source) {
> >  		fast_clk = devm_clk_get(&pdev->dev, "fast-clk"); @@ -1079,6 
> > +1402,15 @@ static int tegra_i2c_probe(struct platform_device *pdev)
> >  		}
> >  	}
> >  
> > +	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;
>
> Missing dma_buf freeing and channel releasing in a case of error.

dma buf freeing and channel release happens inside init_dma when buffer allocation fails.
If dma_request_slave_channel_reason fails no need to release channel but if channel request succeeds and buffer allocation fails, then buffer free and channel release will happen.

> > +	}
> > +
> >  	ret = tegra_i2c_init(i2c_dev);
> >  	if (ret) {
> >  		dev_err(&pdev->dev, "Failed to initialize i2c controller\n");
> > 


  parent reply	other threads:[~2019-01-26  1:52 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
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 [this message]
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=BYAPR12MB33981C0EE06C88C9814B431EC2940@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).