From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
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
Subject: Re: about cs5536 interrupt ack
Date: Wed, 11 Jul 2007 19:42:51 +0400 [thread overview]
Message-ID: <4694FA7B.6030409@ru.mvista.com> (raw)
In-Reply-To: <Pine.LNX.4.64N.0707111347360.26459@blysk.ds.pg.gda.pl>
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
next prev parent reply other threads:[~2007-07-11 15:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-11 9:36 about cs5536 interrupt ack Songmao Tian
2007-07-11 10:58 ` Songmao Tian
2007-07-11 13:24 ` Maciej W. Rozycki
2007-07-11 15:19 ` Songmao Tian
2007-07-11 15:38 ` Songmao Tian
2007-07-11 15:48 ` Maciej W. Rozycki
2007-07-11 16:51 ` Maciej W. Rozycki
2007-07-12 7:26 ` Songmao Tian
2007-07-16 15:11 ` Maciej W. Rozycki
2007-07-11 15:42 ` Sergei Shtylyov [this message]
2007-07-11 16:05 ` Maciej W. Rozycki
2007-07-11 15:22 ` Sergei Shtylyov
2007-07-11 15:31 ` Sergei Shtylyov
2007-07-11 15:35 ` Songmao Tian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4694FA7B.6030409@ru.mvista.com \
--to=sshtylyov@ru.mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=linuxbios@linuxbios.org \
--cc=macro@linux-mips.org \
--cc=marc.jones@amd.com \
--cc=tiansm@lemote.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.