PPC4XX DMA polarity bug in linuxppc-2.6.9

[Matt Porter]

On Fri, Dec 10, 2004 at 09:09:39AM -0000, Colin Wernham wrote:
> I believe that there is a PPC4xx DMA driver bug in the following kernel, 

<snip>

> Cause is (I believe):
> /arch/ppc/syslib/ppc4xx_dma.c:
> On line 469 the old polarity bits in p_dma_ch are ORed in when it should 
> be ORing in the new polarity bits from p_init. p_init is then saved into 
> p_dma_ch. This means that it only gets correctly programmed when the 
> function is called twice:
> 
>     467  /* clear all polarity signals and then "or" in new signal levels */
>     468  polarity &= ~GET_DMA_POLARITY(dmanr);
>     469  polarity |= p_dma_ch->polarity;
> 
> Fix should be:
>     469  polarity |= p_init->polarity;

Yes, that's a real bug.  Can you make a patch according to
Documentation/SubmittingPatches, add your signed off line, and
send to me or this list? This clear bug fix should go in
before 2.6.10.

> Is there anyone else using the PPC4XX DMA?

Yes, I've used this library code for simple memory<->memory DMA
tests to verify that programmed and SG mode work. For more common
setups like peripheral driven DMA from the EBC, I've simply programmed
the DMA engine directly.  This library doesn't seem to simplify anything
for me in those cases (it's just a thin wrapper around registers) so
I find it easier to program the DMA engine regs directly within the
driver that is making use of a channel. I've been keeping it around
since apparently a lot of people make use of it in hopes that
somebody might take the time to improve it.

Since the my apps that would exercise the polarity bits in the
init code don't use this library, I guess that's why I've never
run into this problem. :)

-Matt