linux-kernel - RE: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride configuration

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: <E0D41E29EB0DAC4E9F3FF173962E9E9403026FE695@dbde02.ent.ti.com>
Date:	Mon, 18 Jul 2011 13:21:58 +0530
From:	"Raju, Sundaram" <sundaram@...com>
To:	Jassi Brar <jassisinghbrar@...il.com>
CC:	Linus Walleij <linus.walleij@...aro.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"davinci-linux-open-source@...ux.davincidsp.com" 
	<davinci-linux-open-source@...ux.davincidsp.com>,
	"linux@....linux.org.uk" <linux@....linux.org.uk>,
	"dan.j.williams@...el.com" <dan.j.williams@...el.com>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>
Subject: RE: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride
 configuration

> -----Original Message-----
> From: Jassi Brar [mailto:jassisinghbrar@...il.com]
> Sent: Tuesday, July 12, 2011 6:15 PM
> To: Raju, Sundaram
> Cc: Linus Walleij; linux-arm-kernel@...ts.infradead.org; linux-
> kernel@...r.kernel.org; davinci-linux-open-source@...ux.davincidsp.com;
> linux@....linux.org.uk; dan.j.williams@...el.com; linux-omap@...r.kernel.org
> Subject: Re: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride
> configuration
> 
> On Tue, Jul 12, 2011 at 5:01 PM, Raju, Sundaram <sundaram@...com> wrote:
> >> -----Original Message-----
> >> From: Jassi Brar [mailto:jassisinghbrar@...il.com]
> >> Sent: Tuesday, July 12, 2011 4:51 PM
> >> To: Linus Walleij
> >> Cc: Raju, Sundaram; linux-arm-kernel@...ts.infradead.org; linux-
> >> kernel@...r.kernel.org; davinci-linux-open-source@...ux.davincidsp.com;
> >> linux@....linux.org.uk; dan.j.williams@...el.com; linux-
> omap@...r.kernel.org
> >> Subject: Re: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride
> >> configuration
> >>
> >> On Tue, Jul 12, 2011 at 3:33 PM, Linus Walleij <linus.walleij@...aro.org>
> >> wrote:
> >> > On Tue, Jul 12, 2011 at 6:17 AM, Jassi Brar <jassisinghbrar@...il.com>
> >> wrote:
> >> >
> >> >> 1) Striding, in one form or other, is supported by other DMACs as well.
> >> >>   The number will only increase in future.
> >> >>   Are we to add  <VENDOR>_DMA_STRIDE_CONFIG for each case ?
> >> >
> >> > If we are sure about this and striding will work in a similar way on all
> >> > then let's have the enum named DMA_STRIDE_CONFIG and move the
> >> > passed-in struct to <linux/dmaengine.h) then?
> >> >
> >> > Would that be:
> >> >
> >> > struct dma_stride_config {
> >> >    u32 read_bytes;
> >> >    u32 skip_bytes;
> >> > };
> >> >
> >> > Or something more complex?
> >> Well, I am not sure if striding needs any special treatment at all.
> >> Why not have client drivers prepare and submit sg-list.
> >> Let the DMAC drivers interpret/parse the sg-list and program it
> >> as strides if the h/w supports it.
> >> If anything, we should make preparation and submission of sg-list
> >> as efficient as possible.
> > Jassi,
> >
> > sg_lists describe only a bunch of disjoint buffers. But what if the
> > DMAC can skip and read the bytes within each of the buffers in
> > the sg_list? (like TI EDMAC and TI SDMAC)
> > How can that information be passed to the offload
> > engine driver from the client?
> >
> OK, I overlooked.
> We do need something new to handle these ultra-fine-grained sg-lists.
> But still we shouldn't add SoC specific API to the common sub-systems.
> 
> Maybe a new api to pass fixed-format variable-length encoded message
> to the DMAC drivers?
> Which could be interpreted by DMAC drivers to extract all the needed xfer
> parameters from the 'header' section and instructions to program the xfers
> in the DMAC from the variable length body of the 'message' buffer.
> It might sound complicated but we can have helpers to make the job easy.
> Btw, the regular single/sg-list xfers could also be expressed by this method.

Do you expect this variable length body of the message to be DMAC
independent? I don't think so. In that case how is this different from what
we have here already?

If it can be DMAC independent, can you illustrate more on how this can
be done? But the point to note is, if this can be made DMAC independent
then the control command we have also can be made DMAC independent
by generalizing the configuration structure passed to it.

~ Sundaram