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] [day] [month] [year] [list]
Message-ID: <E0D41E29EB0DAC4E9F3FF173962E9E94030259DAFE@dbde02.ent.ti.com>
Date:	Tue, 12 Jul 2011 15:45:47 +0530
From:	"Raju, Sundaram" <sundaram@...com>
To:	Linus Walleij <linus.walleij@...aro.org>,
	Dan Williams <dan.j.williams@...el.com>
CC:	"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>,
	"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: Linus Walleij [mailto:linus.walleij@...aro.org]
> Sent: Tuesday, July 12, 2011 3:28 PM
> To: Dan Williams
> 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; linux-omap@...r.kernel.org
> Subject: Re: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride
> configuration
> 
> On Mon, Jul 11, 2011 at 11:39 PM, Dan Williams <dan.j.williams@...el.com>
> wrote:
> > On Mon, Jul 11, 2011 at 2:28 AM, Linus Walleij <linus.walleij@...aro.org>
> wrote:
> 
> > ...and I suspect the slave device drivers that use TI DMA are not
> > expected to ever work with other dmaengines?  Likely the case, but
> > just wondering out loud.
> 
> Typically the OMAP/TI drivers are one-to-one with this specific DMA
> controller, but they *can* support controllers without stride options, and
> notice that striding will only be used for the display driver IIRC,
> pseudo-code:
> 
> ret = dmaengine_device_control(chan, TI_DMA_STRIDE_CONFIG,
>                         (unsigned long) &my_stride_config);
> if (ret) {
>    /*
>     * OK no striding on this DMA engine, fall back to something else,
>     * such as creating an SGlist which emulates the striding with one
>     * sglist element per stride.
>     */
> }
> 
> By injecting an error in the stride config path this can even be
> properly tested. So it will become an optional acceleration.

Yes, this is exactly what I also wanted to say. :)

But if the client driver does not implement a fallback like this then that
driver will work only with TI DMA and not any other dmaengines.
(Mentioning this because, there are client drivers which are tightly 
coupled to this special configuration)

Keeping this in mind, I had started the original discussion with
the suggestion of modifying the existing prepare API and adding
an extra argument to it, which can be used to pass special configuration.
And I also wanted to generalize that configuration passed.

Anyways that design also will come down to this same path, and instead
of modifying the existing API signatures, I think this is the best way
we can go.

Regards,
Sundaram
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ