[PATCH v1 00/23] ata: sata_dwc_460ex: make it working again

[Christian Lamparter]

On Sunday, April 24, 2016 09:05:43 AM Julian Margetson wrote:
> On 4/23/2016 3:41 PM, Christian Lamparter wrote:
> > There's a known errata for the 460EX, with the CPU lockup upon
> > high AHB traffic:
> > <http://lists.denx.de/pipermail/u-boot/2008-June/036078.html>
> >
> > "This patch implements a fix provided by AMCC so that the lockup upon
> > simultanious traffic on AHB USB OTG, USB 2.0 and SATA doesn't occur
> > anymore:..."
> >
> > This should be fixed by u-boot. However, there's no telling if
> > there's more to this workaround in the dma engine. You could try
> > to do the testing without anything connected to the USB ports
> > and disable/remove all usb hcds modules. As for fixing this:
> > I did a quick search but couldn't find any public information.
> > There's always support at apm.com (contact them!), or maybe someone
> > from the Amiga community knows more?
> >
> >
> 
> Tested with kernel with all USB disabled. No sata error messages 
> during the partition copy but the copying is quite slow.
Ok. The CONFIG_DMADEVICES_DEBUG and CONFIG_DMADEVICES_VDEBUG option
have quite a large overhead, if this fixed the issue for now you
could try to disable them and look if the issue comes back or not.
(also, you can drop the mdelay patch if it's still applied). If
the issue doesn't come back, you could add your "Tested-by" tag
too.

Another thing, the sata dwc driver doesn't yet support NCQ. Do you
know if the driver for the Amiga OS does?

> so this does appear to be the problem.
So, how to fix this? I know, there's an AHB DMA Arbiter. But I can't
get any documentation for it from AMCC/APM. Maybe denx.de or someone
from the Amiga community knows how to deal with it. In theory, we 
could try if limiting the burst length, pending dma request count or
add code to retry failed dma transfers and reinit the usb-cores would
help.

Regards,
Christian