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

Drivers: dma: remove __dev* attributes.

2013-01-03T23:57:15Z

CONFIG_HOTPLUG is going away as an option. As a result, the __dev* markings need to be removed. This change removes the use of __devinit, __devexit_p, __devinitconst, and __devexit from these drivers. Based on patches originally written by Bill Pemberton, but redone by me in order to handle some of the coding style issues better, by hand. Cc: Bill Pemberton Cc: Viresh Kumar Cc: Dan Williams Cc: Vinod Koul Cc: Barry Song Cc: Jeff Kirsher Cc: Alexander Duyck Cc: Russell King Cc: Linus Walleij Cc: Jassi Brar Cc: Dave Jiang Cc: Bill Pemberton Cc: Guennadi Liakhovetski Signed-off-by: Greg Kroah-Hartman

dma: remove use of __devinit

2012-11-28T20:42:36Z

CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Signed-off-by: Bill Pemberton Cc: Li Yang Cc: Zhang Wei Cc: Barry Song Acked-by: Viresh Kumar Signed-off-by: Greg Kroah-Hartman

dma: remove use of __devexit_p

2012-11-28T20:41:36Z

CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer needed. Signed-off-by: Bill Pemberton Acked-by: Barry Song Acked-by: Viresh Kumar Acked-by: Russell King Signed-off-by: Greg Kroah-Hartman

dma: fix comments

2012-09-01T15:57:12Z

Correct spelling typo in drivers/dma. Signed-off-by: Masanari Iida Signed-off-by: Jiri Kosina

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