linux-kernel - Re: [PATCH/RFC] dmaengine: add a slave parameter to __dma_request

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1331285959.4657.76.camel@vkoul-udesk3>
Date:	Fri, 09 Mar 2012 15:09:19 +0530
From:	Vinod Koul <vinod.koul@...el.com>
To:	Guennadi Liakhovetski <g.liakhovetski@....de>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	linux-kernel@...r.kernel.org,
	'Jassi Brar' <jassisinghbrar@...il.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Magnus Damm <magnus.damm@...il.com>,
	Paul Mundt <lethal@...ux-sh.org>
Subject: Re: [PATCH/RFC] dmaengine: add a slave parameter to
 __dma_request_channel()

On Fri, 2012-03-09 at 10:24 +0100, Guennadi Liakhovetski wrote:
> On Fri, 9 Mar 2012, Vinod Koul wrote:
> 
> > On Thu, 2012-03-08 at 14:18 +0100, Guennadi Liakhovetski wrote:
> > > > Assuming I didn't miss...
> > > > 
> > > > The case B can be handled without sweat by platforms channel mapping
> > > > information.
> > > > 
> > > > Case A where we don't find that devices exist in map, thus being treated
> > > > as generic DMA channels and can be handled easily in sequence. So when
> > > > someone in Q request a channel it would get first channel in Ps
> > > > 
> > > > This way we handle both of them in a transparent manner to both clients
> > > > and controllers. 
> > > > 
> > > > Perhaps we can also add capability to know that if channel is to be
> > > > searched in map or not - would be anyway required for non slave cases.
> > > 
> > > Right, but I don't understand then what this gives us. You propose some 
> > > channel maps, that will not be used for your "case A." Which means, for 
> > > "case A" nothing changes. So, the reason for this whole thread hasn't been 
> > > addressed: how to pass channel configuration to the DMA controller driver.
> > For "Case A" there should be no filtering or any issues even now. You
> > have controller requesting a channel and as long as they get a channel
> > for respective pool, it should work.
> > 
> > Or is there anything else which is required in this case?
> 
> Yes, there is. You keep complaining about my use of .priv pointer, which I 
> use in the filter to pass channel configuration to the DMA controller 
> driver. That is the original reason for this whole discussion. If you're 
> fine with that, I'll just carry that .priv use over in the "simple" DMA 
> engine driver and stay happy forever:-)
Channel configuration != filtering & channel allocation

The discussion is focused on getting request_channel fixed so that we
take care of oddities in respective platforms for channel maps which
exist.
What the heck does it have to on how you configure you channel??

Once you have channel allocated correctly which can work for you, you
need to configure you channel. Since this is slave case you to tell what
your client FIFO depth, burst size, width etc parameters. There is
dma_slave_config for that purpose ONLY. Is there anything else required
for _configuring_ if yes, we can add those. But then again that doesn't
have anything to do with how you get a channel.


-- 
~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/