> -----Original Message----- > From: Linus Walleij [mailto:linus.walleij@xxxxxxxxxx] > Sent: Tuesday, July 12, 2011 3:28 PM > To: Dan Williams > Cc: Raju, Sundaram; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; davinci-linux-open-source@xxxxxxxxxxxxxxxxxxxx; > linux@xxxxxxxxxxxxxxxx; linux-omap@xxxxxxxxxxxxxxx > 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@xxxxxxxxx> > wrote: > > On Mon, Jul 11, 2011 at 2:28 AM, Linus Walleij <linus.walleij@xxxxxxxxxx> > 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-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
