Re: 2.6.32: Promise UDMA33 card refuses to work in UDMA mode

[Russell King <rmk@arm.linux.org.uk>]

On Mon, Jan 04, 2010 at 03:55:44PM +0000, Alan Cox wrote:
> > That's not the problem here - with the printk's I've added, there's no
> > way for the IO read/writes to come that fast.  Slowing down the IO
> > accesses made no difference what so ever.
> 
> Doing it within 400nS of command setup is suspect at the ATA level and
> can trivially fixed.
> 
> Sane PCI controllers (and quite a few less than sane ones) all implement
> an AltStatus which can be checked for busy bits with DMA running or stall
> that access until the DMA completes (wrongly in some CMD64x cases).
> 
> The 20246 implements its own magic 'am I busy' flag which old IDE
> supports and libata doesn't. So as well as the ndelay(400) fix for PIO
> controllers it needs pdc202xx_test_irq porting over to complete the fix.

Yes, but please use a non-buggy version of pdc202xx_test_irq() as per
my recent patch.  Testing for the DMA FIFOs being non-empty to qualify
an interrupt is Very Bad News too.

It's interesting to note that SFF 8038 suggests an approach to dealing
with IDE interrupts connected to a SFF compatible host interface:

3) Software issues the appropriate DMA transfer command to the disk device.
4) Engage the bus master function by writing a '1' to the Start bit in the
   Bus Master IDE Command Register for the appropriate channel.
5) The controller transfers data to/from memory responding to DMA requests
   from the IDE device.
6) at the end of the transfer the IDE device signals an interrupt .
7) In response to the interrupt, software resets the Start/Stop bit in the
   command register. It then reads the controller status and then the drive
   status to determine if the transfer completed successfully.

It goes on to say that the interrupt status bit in the BM-DMA status
register will only be set after buffered data has been transferred -
which means reading the altstatus register to determine when the device
has finished would give a premature indication and doesn't take any
account of the BM-DMA buffering.

So I think Jeff is not right on the "must read altstatus" point.

I would not be surprised if lots of host controllers were actually buggy
in respect of reading any ATA device register mid-transfer - firstly a
started UDMA operation can't be stopped before at least one word has been
transferred, nor can it be stopped without first transferring the CRC
bytes.  That's an awful lot of logic (and overhead) to be randomly
interacting with due to other shared devices interrupt activity.

Reading the BM-DMA status register (or equivalent on hosts) seems to be
the right way to tell if an interrupt is pending.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of: