linux-kernel - Re: [PATCH v2 3/6] dma: Add a jz4740 dmaengine driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130612053810.GF4107@intel.com>
Date:	Wed, 12 Jun 2013 11:08:10 +0530
From:	Vinod Koul <vinod.koul@...el.com>
To:	Lars-Peter Clausen <lars@...afoo.de>
Cc:	Ralf Baechle <ralf@...ux-mips.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>,
	Maarten ter Huurne <maarten@...ewalker.org>,
	linux-mips@...ux-mips.org, linux-kernel@...r.kernel.org,
	alsa-devel@...a-project.org
Subject: Re: [PATCH v2 3/6] dma: Add a jz4740 dmaengine driver

On Mon, Jun 10, 2013 at 07:29:46PM +0200, Lars-Peter Clausen wrote:
> On 05/30/2013 08:46 PM, Lars-Peter Clausen wrote:
> >>> +static int jz4740_dma_alloc_chan_resources(struct dma_chan *c)
> >>> +{
> >>> +	struct jz4740_dmaengine_chan *chan = to_jz4740_dma_chan(c);
> >>> +
> >>> +	chan->jz_chan = jz4740_dma_request(chan, NULL);
> >>> +	if (!chan->jz_chan)
> >>> +		return -EBUSY;
> >>> +
> >>> +	jz4740_dma_set_complete_cb(chan->jz_chan, jz4740_dma_complete_cb);
> >>> +
> >>> +	return 0;
> >> Sorry, I didnt reply on this one. The API expects you to allocate a pool of
> >> descriptors. These descriptors are to be used in .device_prep_xxx calls later.
> > 
> > The size of the descriptor is not fixed, so they can not be pre-allocated. And
> > this is nothing new either, most of the more recently added dmaengine drivers
> > allocate their descriptors on demand.
> 
> Vinod, are you ok with this explanation?
Sorry, I was travelling...

Can you explain more of a bit when you say size is not fixed. Why would it be
issue if we allocate descriptors at the alloc_chan. The idea is that you 
preallocated pool at alloc_chan and since the .device_prep_xxx calls can be
called from atomic context as well, you dont need to do this later. You can use use
these descriptors at that time. The idea is keep rotating the descriptors from
free poll to used one

--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/