linux-mips
[Top] [All Lists]

Re: about cs5536 interrupt ack

To: "Maciej W. Rozycki" <macro@linux-mips.org>
Subject: Re: about cs5536 interrupt ack
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Date: Wed, 11 Jul 2007 19:42:51 +0400
Cc: Songmao Tian <tiansm@lemote.com>, LinuxBIOS Mailing List <linuxbios@linuxbios.org>, marc.jones@amd.com, linux-kernel@vger.kernel.org, linux-mips@linux-mips.org
In-reply-to: <Pine.LNX.4.64N.0707111347360.26459@blysk.ds.pg.gda.pl>
Organization: MontaVista Software Inc.
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <4694A495.1050006@lemote.com> <Pine.LNX.4.64N.0707111347360.26459@blysk.ds.pg.gda.pl>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803
Hello.

Maciej W. Rozycki wrote:

"Control Logic
The INT output goes directly to the CPU interrupt input.
When an INT signal is activated, the CPU responds with an
Interrupt Acknowledge access that is translated to two
pulses on the INTA input of the PIC. At the first INTA pulse,
the highest priority IRR bit is loaded into the corresponding
ISR bit, and that IRR bit is reset. The second INTA pulse
instructs the PIC to present the 8-bit vector of the interrupt
handler onto the data bus."

Is it the responsibility of north bridge to reponse to intr with a PCI
Interrupt Ack cycle?

With an i386 system such a pair of INTA cycles would be generated by the CPU itself and translated by the north bridge to a PCI Interrupt Acknowledge cycle (see the PCI spec for a more elaborate description).

If the CPU does not generate INTA cycles, it is a common practice to let it ask the north bridge for a PCI Interrupt Acknowledge in some other way, typically by issuing a read cycle that returns the vector reported by the interrupt controller.

it's a problem that my northbridge didn't implement that! Fortunately we use a
fpga as a northbridge.

it seem it's no way to fix this by software, for OCW3 didn't implemnt Poll
command:(

Huh? Have you managed to find an 8259A clone *that* broken? So what

   It's not such a problem, believe me. ;-)
Some PPC boards use such clones -- you can see the comment in arch/powerpc/sysdev/i8259.c.

does it return if you write 0xc to the address 0x20 in the I/O port space and then read back from that location? You should complain to the manufacturer -- they may be able to fix the problem in a later revision.

   Haha, here's an excerpt form CS5535 spec. update:

96. PIC does not support Polling mode

[...]

Implications: This mode is not normally used in x86 systems.
Resolution: None.

so I guess the the process is:
1) 8259 receive a int, a bit irr got set.
2) 8259 assert intr.
3) northbrige generate a int ack cycle.
4) cs5536 translate the ack into two INTA pulse, and the reponse northbridge
with a interrupt vector.
5) then my program can get the vector from northbridge?

Is that right?

Indeed, this would seem right but one step skipped -- where CPU tells northbridge that it's accepted an interrupt (via INTA).

More or less -- 3-5 should probably be the outcome of a single read transaction from the north bridge. I.e. you issue a read to a "magic" location, 3-5 happen, and the data value returned is the vector presented by the interrupt controller on the PCI bus.

   Yeah, another way of doing the missed step.

Without int ack, generic linux-mips 8259 code can't work.

You can still dispatch interrupts manually by examining the IRR register, but having a way to ask the 8259A's prioritiser would be nice. Although given such a lethal erratum you report I would not count on the prioritiser to provide any useful flexibility...

   Why not? AMD just decided not to implement poll mode, that's all.

  Maciej

WBR, Sergei

<Prev in Thread] Current Thread [Next in Thread>