Subject: Re: Suspected 21285 deadlock?

From: Philip Blundell <[email-masked]>
Date: Sun, 25 Apr 1999 12:01:09 +0100

>Indeed yes, the SA110 this time was trying to do a PCI IACK cycle, however
>the DC21285 was attempting to perform some operation at PCI address 0x21
>(Control bits 0011, whatever that means), but getting retry responses from
>the Southbridge.

Command 0011 is an I/O write, and of course ISA I/O address 0x21 is the 
first PIC.  Since IACK is a read cycle it almost certainly requires the 
outbound FIFO to be flushed.

>if I clear this bit, then the bus seems to lock with the Southbridges
>bus request and bus grant permanently active, however it did (on my
>single attempt) get slightly further.  There appears to be no DMA

It's hard to say what happens in this case.  From the description you've given 
of the control bit, I'd expect the lock-up to occur with the 21285 having bus 
ownership (because it sits waiting for a TRDY that never comes; the latency 
timer doesn't really protect you against this case).

>The Southbridge doesn't seem to have a latency timer on it, nor any other
>timing-related registers - it just seems to have regs 0, 2, 4, 6, 8,
>9, A, B and E apart from the manufacturer specific regs at 0x40 and
>above.  Naturally for DMA, it has the normal PC DMA register set.

It may well not have a latency timer if it's not capable of burst transfers.  
Even if it did, it wouldn't help in either of the failure modes you're seeing 
-- in the first one you described, the southbridge is correctly relinquishing 
the bus anyway, and in the second one the arbiter isn't removing its GNT so 
the latency timer would have no effect.

Does the documentation or errata for the southbridge say anything about the 
circumstances under which it responds with retry to target write transactions?

p.

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Sun, 25 Apr 1999 12:15:50 +0100 (BST)

> outbound FIFO to be flushed.

Aha, as I was expecting...

> timer doesn't really protect you against this case).

I don't think the 21285 is at fault - it's looking like the Southbridge chip
isn't behaving as PCI 2.1 would expect.  Ok, it's giving retries which are allowed,
but surely it should not block accesses while a DMA operation is in progress (since
you therefore cannot get to the DMA controller or device to stop it).

> the latency timer would have no effect.

The arbiter is behaving as expected - in the total lock condition, the SA110 is
stalled while a memory read is processed.  However, the 21285 doesn't have anything
to do on the PCI, so it's request is not activated.  Therefore, the arbiter does
not remove the grant to the Southbridge since no other master is requesting the
bus.

> circumstances under which it responds with retry to target write transactions?

While looking for this, I suspect that the problems I'm seeing is why the chip
has gone obsolete about a year ago.  Unfortunately, Cypress have cleaned their
web site of all obsolete erratas and data sheets.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Sun, 25 Apr 1999 12:58:35 +0100

>> It's hard to say what happens in this case.  From the description you've
>> given of the control bit, I'd expect the lock-up to occur with the 21285 
>> having bus ownership (because it sits waiting for a TRDY that never comes; 
>> the latency timer doesn't really protect you against this case).
>
>isn't behaving as PCI 2.1 would expect.

No, I don't think the 21285 is at fault either.  In the scenario I described 
above the 21285 is behaving correctly.  If your observations are correct and 
it does lock up with the southbridge having bus ownership then the fault could 
be at either end -- the only way to find out would be to examine the bus 
transactions that occur during and maybe just prior to the lockup.

>The arbiter is behaving as expected - in the total lock condition, the SA110 
>is stalled while a memory read is processed.  However, the 21285 doesn't have 
>anything to do on the PCI, so it's request is not activated.  Therefore, the 
>arbiter does not remove the grant to the Southbridge since no other master is 
>requesting the bus.

Yes, that was precisely my point.

>web site of all obsolete erratas and data sheets.

Oh dear.  These parts do usually have a pretty short lifespan though, typically 
just a year or two.

p.