kernel.git/drivers/dma/ppc4xx, branch linux-3.6.y

dmaengine: ensure all DMA engine drivers initialize their cookies

2012-03-13T06:07:42Z

Ensure all DMA engine drivers initialize their cookies in the same way, so that they all behave in a similar fashion. This means their first issued cookie will be 2 rather than 1, and will increment to INT_MAX before returning 1 and starting over. In connection with this, Dan Williams said: > Russell King wrote: > > Secondly, some DMA engine drivers initialize the dma_chan cookie to 0, > > others to 1. Is there a reason for this, or are these all buggy? > > I know that ioat and iop-adma expect 0 to mean "I have cleaned up this > descriptor and it is idle", and would break if zero was an in-flight > cookie value. The reserved usage of zero is an driver internal > concern, but I have no problem formalizing it as a reserved value. Signed-off-by: Russell King Tested-by: Linus Walleij Reviewed-by: Linus Walleij Acked-by: Jassi Brar [imx-sdma.c & mxs-dma.c] Tested-by: Shawn Guo Signed-off-by: Vinod Koul

dmaengine: fix cookie handling in iop-adma.c and ppc4xx/adma.c

2012-03-13T06:07:33Z

Dan Williams said: > > Russell King wrote: > > Firstly, we have DMA_MIN_COOKIE which has value 1 - so any cookies below > > that aren't valid. That seems sane. > > > > We seem to have different behaviours: > > > > - cookie = c->cookie; > > - cookie++; > > - if (cookie < 0) > > - cookie = 1; > > - c->cookie = cookie; > > - tx->cookie = cookie; > > > > c->cookie here is initialized to zero, so the first cookie given out will > > be 1. This is how most DMA engine drivers implement this. > > > > Then we have this: > > > > cookie = chan->common.cookie; > > cookie++; > > if (cookie <= 1) > > cookie = 2; > > > > /* initialize the completed cookie to be less than > > * the most recently used cookie > > */ > > chan->common.completed_cookie = cookie - 1; > > chan->common.cookie = sw_desc->async_tx.cookie = cookie; > > > > Again, chan->common.cookie starts off at 0. The first cookie given out > > will be 2, and 1 will never be used. There are three drivers which > > implement it this way. > > > > Why is there this difference, and can these three be corrected to behave > > the same way as the first (and therefore the assignment of cookies > > consolidated?) > > Yes, they should be consolidated, and I believe they have drifted only > because there were no good common helpers and murphy's law took over. So lets fix this up to use the common dma_cookie_assign() helper. Signed-off-by: Russell King Tested-by: Linus Walleij Reviewed-by: Linus Walleij Acked-by: Jassi Brar [imx-sdma.c & mxs-dma.c] Tested-by: Shawn Guo Signed-off-by: Vinod Koul

dmaengine: consolidate tx_status functions

2012-03-13T06:07:14Z

Now that we have the completed cookie in the dma_chan structure, we can consolidate the tx_status functions by providing a function to set the txstate structure and returning the DMA status. We also provide a separate helper to set the residue for cookies which are still in progress. Signed-off-by: Russell King Tested-by: Linus Walleij Reviewed-by: Linus Walleij Acked-by: Jassi Brar [imx-sdma.c & mxs-dma.c] Tested-by: Shawn Guo Signed-off-by: Vinod Koul

dmaengine: consolidate assignment of DMA cookies

2012-03-13T06:06:52Z

Everyone deals with assigning DMA cookies in the same way (it's part of the API so they should be), so lets consolidate the common code into a helper function to avoid this duplication. Signed-off-by: Russell King Tested-by: Linus Walleij Reviewed-by: Linus Walleij Acked-by: Jassi Brar [imx-sdma.c & mxs-dma.c] Tested-by: Shawn Guo Signed-off-by: Vinod Koul

dmaengine: add private header file

2012-03-13T06:06:44Z

Add a local private header file to contain definitions and declarations which should only be used by DMA engine drivers. We also fix linux/dmaengine.h to use LINUX_DMAENGINE_H to guard against multiple inclusion. Signed-off-by: Russell King Tested-by: Linus Walleij Reviewed-by: Linus Walleij Acked-by: Jassi Brar [imx-sdma.c & mxs-dma.c] Tested-by: Shawn Guo Signed-off-by: Vinod Koul

dmaengine: move last completed cookie into generic dma_chan structure

2012-03-13T06:06:06Z

Every DMA engine implementation declares a last completed dma cookie in their private dma channel structures. This is pointless, and forces driver specific code. Move this out into the common dma_chan structure. Signed-off-by: Russell King Tested-by: Linus Walleij Reviewed-by: Linus Walleij Acked-by: Jassi Brar [imx-sdma.c & mxs-dma.c] Tested-by: Shawn Guo Signed-off-by: Vinod Koul

Merge branch 'old_next' into next

2011-04-06T06:21:12Z

dma: use BUG_ON correctly in ppc4xx/adam.c, v4

2011-03-31T05:37:40Z

This patch makes BUG_ON() usage correct in drivers/dma/ppc4xx/adam.c Cc: Vinod Koul Cc: Dan Williams Cc: Grant Likely Cc: Anatolij Gustschin Cc: Sean MacLennan Cc: Joe Perches Signed-off-by: Coly Li Signed-off-by: Vinod Koul

dt/powerpc: Eliminate users of of_platform_{,un}register_driver

2011-02-28T08:36:39Z

Get rid of old users of of_platform_driver in arch/powerpc. Most of_platform_driver users can be converted to use the platform_bus directly. Signed-off-by: Grant Likely

drivers/dma/ppc4xx: Use printf extension %pR for struct resource

2010-12-04T23:03:40Z

Using %pR standardizes the struct resource output. Signed-off-by: Joe Perches Signed-off-by: Dan Williams