On Thu, Feb 16, 2012 at 01:48:20PM -0600, Timur Tabi wrote:
> Ira W. Snyder wrote:
>
> > No. I don't have the ability to connect my P2020 up to an FPGA to
> > recreate the DMA workload that causes this on my 8349EA. I can run the
> > dmatest module, if you'd like.
>
> I just want to make sure you
Ira W. Snyder wrote:
> No. I don't have the ability to connect my P2020 up to an FPGA to
> recreate the DMA workload that causes this on my 8349EA. I can run the
> dmatest module, if you'd like.
I just want to make sure your patch doesn't break 85xx.
--
Timur Tabi
Linux kernel developer at Free
On Thu, Feb 16, 2012 at 01:34:00PM -0600, Timur Tabi wrote:
> Ira W. Snyder wrote:
> > This leads me to believe that this occurs mostly (but not always)
> > concurrent with the end-of-chain interrupt.
>
> Have you tested this on an 85xx platform?
>
No. I don't have the ability to connect my P202
Ira W. Snyder wrote:
> This leads me to believe that this occurs mostly (but not always)
> concurrent with the end-of-chain interrupt.
Have you tested this on an 85xx platform?
I noticed something odd. You're modifying fsldma_chan_irq(), which is for
DMA controllers that have per-channel IRQs.
On Thu, Feb 16, 2012 at 05:50:47PM +, Tabi Timur-B04825 wrote:
> On Thu, Jan 26, 2012 at 2:58 PM, Ira W. Snyder wrote:
> > The mpc8349ea has been observed to generate spurious end of segments
> > interrupts despite the fact that they are not enabled by this driver.
> > Check for them and ignor
On Thu, Jan 26, 2012 at 2:58 PM, Ira W. Snyder wrote:
> The mpc8349ea has been observed to generate spurious end of segments
> interrupts despite the fact that they are not enabled by this driver.
> Check for them and ignore them to avoid a kernel error message.
When this happens, are there any o
