Hi, I am trying to use a mips cpu the cs5536. I have some problem with the 8259 of cs5536. The databook said,
"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? 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:(
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?
Without int ack, generic linux-mips 8259 code can't work.
Greetings, Tian
On Wed, 11 Jul 2007, Songmao Tian 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 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.
BTW, I have just found a bug (OK, a misfeature, perhaps) in include/asm-mips/i8259.h. ;-) I'll cook a patch.
so I guess the the process is:
- 8259 receive a int, a bit irr got set.
- 8259 assert intr.
- northbrige generate a int ack cycle.
- 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?
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.
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...
Maciej
Before I post the mail, I think you will reply, and haha you did:), Thanks that.
Maciej W. Rozycki wrote:
On Wed, 11 Jul 2007, Songmao Tian 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 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
It's the value of IRR, so guess IRR. AMD has well documented cs5536, I appreciate that.
manufacturer -- they may be able to fix the problem in a later revision.
BTW, I have just found a bug (OK, a misfeature, perhaps) in include/asm-mips/i8259.h. ;-) I'll cook a patch.
so I guess the the process is:
- 8259 receive a int, a bit irr got set.
- 8259 assert intr.
- northbrige generate a int ack cycle.
- 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?
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, we can implement a register in north bridge.
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...
yeah, that's a straight thought, tried but failed:(, patch followed.
Maciej
diff --git a/include/asm-mips/i8259.h b/include/asm-mips/i8259.h index e88a016..38628af 100644 --- a/include/asm-mips/i8259.h +++ b/include/asm-mips/i8259.h @@ -42,6 +42,37 @@ extern void enable_8259A_irq(unsigned int irq); extern void disable_8259A_irq(unsigned int irq);
extern void init_i8259_irqs(void); +#define CONFIG_NO_INTERRUPT_ACK +#ifdef CONFIG_NO_INTERRUPT_ACK +static inline int _byte_ffs(u8 word) +{ + int num = 0; + if ((word & 0xf) == 0) { + num += 4; + word >>= 4; + } + if ((word & 0x3) == 0) { + num += 2; + word >>= 2; + } + if ((word & 0x1) == 0) + num += 1; + return num; +} + +static inline int read_irq(int port) +{ + outb(0x0A, port); + return _byte_ffs(inb(port)); +} +#else +static inline int read_irq(int port) +{ + /* Perform an interrupt acknowledge cycle on controller 1. */ + outb(0x0C, port); /* prepare for poll */ + return inb(port) & 7; +} +#endif
/* * Do the traditional i8259 interrupt polling thing. This is for the few @@ -54,18 +85,16 @@ static inline int i8259_irq(void)
spin_lock(&i8259A_lock);
- /* Perform an interrupt acknowledge cycle on controller 1. */ - outb(0x0C, PIC_MASTER_CMD); /* prepare for poll */ - irq = inb(PIC_MASTER_CMD) & 7; + irq = read_irq(PIC_MASTER_CMD); + if (irq == PIC_CASCADE_IR) { /* * Interrupt is cascaded so perform interrupt * acknowledge on controller 2. */ - outb(0x0C, PIC_SLAVE_CMD); /* prepare for poll */ - irq = (inb(PIC_SLAVE_CMD) & 7) + 8; - } - + irq = read_irq(PIC_SLAVE_CMD) + 8; + } +#ifndef CONFIG_NO_INTERRUPT_ACK if (unlikely(irq == 7)) { /* * This may be a spurious interrupt. @@ -78,7 +107,7 @@ static inline int i8259_irq(void) if(~inb(PIC_MASTER_ISR) & 0x80) irq = -1; } - +#endif spin_unlock(&i8259A_lock);
return likely(irq >= 0) ? irq + I8259A_IRQ_BASE : irq;
Songmao Tian wrote:
Before I post the mail, I think you will reply, and haha you did:), Thanks that.
Maciej W. Rozycki wrote:
On Wed, 11 Jul 2007, Songmao Tian 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 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
It's the value of IRR, so guess IRR. AMD has well documented cs5536, I appreciate that.
manufacturer -- they may be able to fix the problem in a later revision.
BTW, I have just found a bug (OK, a misfeature, perhaps) in include/asm-mips/i8259.h. ;-) I'll cook a patch.
so I guess the the process is:
- 8259 receive a int, a bit irr got set.
- 8259 assert intr.
- northbrige generate a int ack cycle.
- 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?
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, we can implement a register in north bridge.
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...
yeah, that's a straight thought, tried but failed:(, patch followed.
Maciej
diff --git a/include/asm-mips/i8259.h b/include/asm-mips/i8259.h index e88a016..38628af 100644 --- a/include/asm-mips/i8259.h +++ b/include/asm-mips/i8259.h @@ -42,6 +42,37 @@ extern void enable_8259A_irq(unsigned int irq); extern void disable_8259A_irq(unsigned int irq);
extern void init_i8259_irqs(void); +#define CONFIG_NO_INTERRUPT_ACK +#ifdef CONFIG_NO_INTERRUPT_ACK +static inline int _byte_ffs(u8 word) +{
- int num = 0;
- if ((word & 0xf) == 0) {
num += 4;word >>= 4;- }
- if ((word & 0x3) == 0) {
num += 2;word >>= 2;- }
- if ((word & 0x1) == 0)
num += 1;- return num;
+}
+static inline int read_irq(int port) +{
- outb(0x0A, port);
- return _byte_ffs(inb(port));
+} +#else +static inline int read_irq(int port) +{
- /* Perform an interrupt acknowledge cycle on controller 1. */
- outb(0x0C, port); /* prepare for poll */
- return inb(port) & 7;
+} +#endif
/*
- Do the traditional i8259 interrupt polling thing. This is for the few
@@ -54,18 +85,16 @@ static inline int i8259_irq(void)
spin_lock(&i8259A_lock);
- /* Perform an interrupt acknowledge cycle on controller 1. */
- outb(0x0C, PIC_MASTER_CMD); /* prepare for poll */
- irq = inb(PIC_MASTER_CMD) & 7;
- irq = read_irq(PIC_MASTER_CMD);
- if (irq == PIC_CASCADE_IR) { /* * Interrupt is cascaded so perform interrupt * acknowledge on controller 2. */
outb(0x0C, PIC_SLAVE_CMD); /* prepare for poll */irq = (inb(PIC_SLAVE_CMD) & 7) + 8;- }
irq = read_irq(PIC_SLAVE_CMD) + 8;- }
+#ifndef CONFIG_NO_INTERRUPT_ACK if (unlikely(irq == 7)) { /* * This may be a spurious interrupt. @@ -78,7 +107,7 @@ static inline int i8259_irq(void) if(~inb(PIC_MASTER_ISR) & 0x80) irq = -1; }
+#endif spin_unlock(&i8259A_lock);
return likely(irq >= 0) ? irq + I8259A_IRQ_BASE : irq;
after applying this patch, system hung when probing ide, seems reading harddisk continuously, since the led is on all the time.
On Wed, 11 Jul 2007, Songmao Tian wrote:
Huh? Have you managed to find an 8259A clone *that* broken? So what 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
It's the value of IRR, so guess IRR. AMD has well documented cs5536, I appreciate that.
Indeed. I am surprised they have decided to drop the poll command -- it surely does not require much logic as it mostly reuses what's used to produce the vector anyway and it is commonly used when 8259A implementations are interfaced to non-i386 processors. PPC is another example.
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, we can implement a register in north bridge.
Strictly speaking it would not be a register, but a "PCI INTA address space" much like PCI memory or I/O port address spaces. Though as the former ignores addresses driven on the bus, the space occupied does not have to be extensive -- I would assume whatever slot size is available with the address decoder you have implemented would do.
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...
yeah, that's a straight thought, tried but failed:(, patch followed.
You may have to modify other functions from arch/mips/kernel/i8259.c; yes, this makes the whole experience not as pretty as one would hope...
Maciej
On Wed, 11 Jul 2007, Maciej W. Rozycki wrote:
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...
yeah, that's a straight thought, tried but failed:(, patch followed.
You may have to modify other functions from arch/mips/kernel/i8259.c; yes, this makes the whole experience not as pretty as one would hope...
BTW, have you considered skipping the whole 8259A legacy burden and using the interrupt mapper directly? From a brief look at the datasheet I conclude you should be able to OR all the interrupt lines to a single 8259A input (say IRQ0 for the sake of this consideration -- it does not matter), set it to the level triggered mode, mask all the 8259A inputs but this one and ignore the device from then on.
It would work as a "virtual wire", using the Intel's terminology, with its INT output simply following its IR0 input. You can type:
$ grep '8259A Virtual Wire' arch/i386/kernel/io_apic.c
for a reference; ;-) you can skip the AEOI setup as in a system based on a MIPS processor an INTA cycle will be unlikely to reach the 8259A by accident (which may happen in the wild world of broken PCs) -- which you have learnt the hard way by now already.
You can then dispatch interrupts based on the interrupt mapper registers which has this nice side effect of much of the sharing having been removed. It will not work with edge-triggered interrupts, but you do not need that 8254 timer, do you?
Maciej
8259 problem seems to be done with the attached patch, IDE hung seems to be the dma setting problem.
Thanks all for your advise, comments. I have learned a lot. now I continue to trace down the IDE problem.
Mao
Maciej W. Rozycki wrote:
On Wed, 11 Jul 2007, Songmao Tian wrote:
Huh? Have you managed to find an 8259A clone *that* broken? So what 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
It's the value of IRR, so guess IRR. AMD has well documented cs5536, I appreciate that.
Indeed. I am surprised they have decided to drop the poll command -- it surely does not require much logic as it mostly reuses what's used to produce the vector anyway and it is commonly used when 8259A implementations are interfaced to non-i386 processors. PPC is another example.
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, we can implement a register in north bridge.
Strictly speaking it would not be a register, but a "PCI INTA address space" much like PCI memory or I/O port address spaces. Though as the former ignores addresses driven on the bus, the space occupied does not have to be extensive -- I would assume whatever slot size is available with the address decoder you have implemented would do.
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...
yeah, that's a straight thought, tried but failed:(, patch followed.
You may have to modify other functions from arch/mips/kernel/i8259.c; yes, this makes the whole experience not as pretty as one would hope...
Maciej
diff --git a/arch/mips/kernel/i8259.c b/arch/mips/kernel/i8259.c index 9c79703..fd7f4ba 100644 --- a/arch/mips/kernel/i8259.c +++ b/arch/mips/kernel/i8259.c @@ -47,11 +47,7 @@ static struct irq_chip i8259A_chip = { /* * This contains the irq mask for both 8259A irq controllers, */ -static unsigned int cached_irq_mask = 0xffff; - -#define cached_master_mask (cached_irq_mask) -#define cached_slave_mask (cached_irq_mask >> 8) - +unsigned int cached_irq_mask = 0xffff; void disable_8259A_irq(unsigned int irq) { unsigned int mask; diff --git a/include/asm-mips/i8259.h b/include/asm-mips/i8259.h index e88a016..e7dcf7b 100644 --- a/include/asm-mips/i8259.h +++ b/include/asm-mips/i8259.h @@ -37,11 +37,55 @@
extern spinlock_t i8259A_lock;
+extern unsigned int cached_irq_mask; +#define cached_master_mask (cached_irq_mask) +#define cached_slave_mask (cached_irq_mask >> 8) + extern void init_8259A(int auto_eoi); extern void enable_8259A_irq(unsigned int irq); extern void disable_8259A_irq(unsigned int irq);
extern void init_i8259_irqs(void); +#define CONFIG_NO_INTERRUPT_ACK +#ifdef CONFIG_NO_INTERRUPT_ACK +static inline int _byte_ffs(u8 word) +{ + int num = 0; + if ((word & 0xf) == 0) { + num += 4; + word >>= 4; + } + if ((word & 0x3) == 0) { + num += 2; + word >>= 2; + } + if ((word & 0x1) == 0) + num += 1; + return num; +} + +static inline int read_irq(int port) +{ + int irq; + outb(0x0A, port); + if (port == PIC_MASTER_CMD) { + irq = inb(port) & ~cached_master_mask; + } else { + irq = inb(port) & ~cached_slave_mask; + } + if (irq == 0) + return -1; + else + return _byte_ffs(irq); +} +#else +static inline int read_irq(int port) +{ + /* Perform an interrupt acknowledge cycle on controller 1. */ + outb(0x0C, port); /* prepare for poll */ + return inb(port) & 7; +} +#endif
/* * Do the traditional i8259 interrupt polling thing. This is for the few @@ -54,18 +98,16 @@ static inline int i8259_irq(void)
spin_lock(&i8259A_lock);
- /* Perform an interrupt acknowledge cycle on controller 1. */ - outb(0x0C, PIC_MASTER_CMD); /* prepare for poll */ - irq = inb(PIC_MASTER_CMD) & 7; + irq = read_irq(PIC_MASTER_CMD); if (irq == PIC_CASCADE_IR) { /* * Interrupt is cascaded so perform interrupt * acknowledge on controller 2. */ - outb(0x0C, PIC_SLAVE_CMD); /* prepare for poll */ - irq = (inb(PIC_SLAVE_CMD) & 7) + 8; - } + irq = read_irq(PIC_SLAVE_CMD) + 8; + }
+#ifndef CONFIG_NO_INTERRUPT_ACK if (unlikely(irq == 7)) { /* * This may be a spurious interrupt. @@ -78,6 +120,11 @@ static inline int i8259_irq(void) if(~inb(PIC_MASTER_ISR) & 0x80) irq = -1; } +#else + if (cached_irq_mask & (1 << irq)) { + irq = -1; + } +#endif
spin_unlock(&i8259A_lock);
On Thu, 12 Jul 2007, Songmao Tian wrote:
8259 problem seems to be done with the attached patch, IDE hung seems to be the dma setting problem.
Thanks all for your advise, comments. I have learned a lot. now I continue to trace down the IDE problem.
I would still recommend you to investigate the option of making the 8259A cores "transparent" and using the mapper registers to dispatch interrupts directly -- it would make processing of interrupt requests considerably faster and less complicated. Please note that ffs() is O(1) and actually some two or three machine instructions on MIPS architecture processors and the model used by the mapper is closer to the spirit of how MIPS processors do interrupt handling. With such an approach it will also likely be easier to integrate your changes upstream, than it would for your changes to i8259.{c,h} needed for your unusual setup to work.
Of course as an intermediate solution during development to make the whole thing work the complicated use of the 8259A cores may be justified.
Maciej
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:
- 8259 receive a int, a bit irr got set.
- 8259 assert intr.
- northbrige generate a int ack cycle.
- 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
Hi,
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:
- PIC does not support Polling mode
[...]
Implications: This mode is not normally used in x86 systems. Resolution: None.
Yes, of course:
$ grep OCW3 arch/i386/kernel/*.c arch/i386/kernel/time.c: outb(0x0c, PIC_MASTER_OCW3);
not at all, indeed!
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.
If they have decided to skip such an "unimportant" bit of logic, they could have skipped more, only providing support for the basic FNM INT/INTA/EOI scheme -- the only one "architecturally" supported from the original IBM PC on. And indeed, a brief look at the datasheed reveals they claim to have removed the SFNM too (which IMO provides a more reasonable nesting resolution and should be the default for setups where nesting is used, such as the environment as set up at the bootstrap by the PC BIOS).
Maciej
Songmao Tian wrote:
Hi,
I am trying to use a mips cpu the cs5536. I have some problem with the 8259 of cs5536. The databook said,
Which databook?
"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?
it's a problem that my northbridge didn't implement that! Fortunately we use a fpga as a northbridge.
Wait, CS5536 is a nortbridge itself!
it seem it's no way to fix this by software, for OCW3 didn't implemnt Poll command:(
Quite a few 8259 clones don't.
so I guess the the process is:
- 8259 receive a int, a bit irr got set.
- 8259 assert intr.
- northbrige generate a int ack cycle.
To what, PCI?
- cs5536 translate the ack into two INTA pulse, and the reponse
Nonsense. It would only make sense to translate INTA cycles from CPU bus to the PCI bus, not the other way around.
northbridge with a interrupt vector.
As I said, CS5536 is northbridge in itself.
- then my program can get the vector from northbridge?
It's CPU that gets the vector, your program could only do this using poll comand which as
Is that right?
No.
Without int ack, generic linux-mips 8259 code can't work.
I'm compleetly lost here -- what does CS5536 has to do with MIPS?
Greetings, Tian
WBR, Sergei
Sergei Shtylyov wrote:
Hello, I wrote:
it's a problem that my northbridge didn't implement that! Fortunately we use a fpga as a northbridge.
Wait, CS5536 is a nortbridge itself!
Apparently, it's only a south bridge. I must've mixed it with Geode itself.
WBR, Sergei
that's fine:)
-
Maciej W. Rozycki -
Sergei Shtylyov -
Songmao Tian