about cs5536 interrupt ack
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
Quoted 3 lines · Songmao Tian
Hi,
I am trying to use a mips cpu the cs5536. I have some problem with
the 8259 of cs5536. The databook said,
cs5536 is a south bridge, cpu, of couse, is loongson:)
Quoted 35 lines
"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
Quoted 10 lines · Songmao Tian
"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."
Quoted 2 lines
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.
Quoted 5 lines
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) ininclude/asm-mips/i8259.h. ;-) I'll cook a patch.
Quoted 9 lines
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?
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.
Quoted 1 line
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.
Quoted 27 lines · Maciej W. Rozycki
Quoted 10 lines · Songmao Tian
"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."Quoted 3 lines
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.Quoted 3 lines
it's a problem that my northbridge didn't implement that! Fortunately we use a fpga as a northbridge.
Quoted 7 lines
Quoted 3 lines
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 write0xcto the address0x20in 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.
Quoted 14 lines
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.Quoted 8 lines
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?
Quoted 6 lines
Quoted 2 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 4 lines
Maciej
include/asm-mips/i8259.h +0 -0
@@ -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;Quoted 4 lines · Songmao Tian
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?
Quoted 10 lines
"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."
Quoted 5 lines
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!
Quoted 1 line
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.
Quoted 4 lines
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.
To what, PCI?
Quoted 1 line
4) 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.
Quoted 1 line
northbridge with a interrupt vector.
As I said, CS5536 is northbridge in itself.
Quoted 1 line
5) 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
Quoted 1 line
Is that right?
No.
Quoted 1 line
Without int ack, generic linux-mips 8259 code can't work.
I'm compleetly lost here -- what does CS5536 has to do with MIPS?
Quoted 2 lines
Greetings,
Tian
WBR, Sergei
Quoted 3 lines · Hello, I wrote:
Quoted 1 line
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
Quoted 12 lines · Sergei Shtylyov
Quoted 3 lines · Hello, I wrote:
Quoted 1 line
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:)
Quoted 143 lines · Songmao Tian
Before I post the mail, I think you will reply, and haha you did:), Thanks that.
Quoted 27 lines · Maciej W. Rozycki
Quoted 10 lines · Songmao Tian
"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."Quoted 3 lines
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.Quoted 3 lines
it's a problem that my northbridge didn't implement that! Fortunately we use a fpga as a northbridge.
Quoted 6 lines
Quoted 3 lines
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 write0xcto the address0x20in the I/O port space and then read back from that location? You should complain to theIt's the value of IRR, so guess IRR. AMD has well documented cs5536, I appreciate that.
Quoted 14 lines
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.Quoted 8 lines
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?Quoted 6 lines
Quoted 2 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 4 lines
Maciej
include/asm-mips/i8259.h +36
-7@@ -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.
include/asm-mips/i8259.h static inline int i8259_irq(void) · line 113
Quoted 8 lines
include/asm-mips/i8259.h +1
-1@@ -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.
Hello.
Quoted 19 lines · Maciej W. Rozycki
Quoted 10 lines
"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."Quoted 2 lines
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.
Quoted 7 lines
Quoted 5 lines
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 inarch/powerpc/sysdev/i8259.c.
Quoted 1 line
does it return if you write
0xcto the address0x20in 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.
Quoted 9 lines
Quoted 9 lines
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).
Quoted 2 lines
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.
Quoted 4 lines
Quoted 1 line
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.
Quoted 1 line
Maciej
WBR, Sergei
Quoted 7 lines · Songmao Tian
Quoted 4 lines
Huh? Have you managed to find an 8259A clone *that* broken? So what does it return if you write
0xcto the address0x20in the I/O port space and then read back from that location? You should complain to theIt'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.
Quoted 6 lines
Quoted 5 lines
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.
Quoted 6 lines
Quoted 5 lines
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
Hi,
Quoted 4 lines
Quoted 3 lines
does it return if you write
0xcto the address0x20in 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.
Quoted 8 lines
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.
Yes, of course:
$ grep OCW3 arch/i386/kernel/*.c arch/i386/kernel/time.c: outb(0x0c, PIC_MASTER_OCW3);
not at all, indeed!
Quoted 6 lines
Quoted 4 lines
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
Quoted 9 lines · Maciej W. Rozycki
Quoted 6 lines
Quoted 5 lines
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
Quoted 35 lines · Maciej W. Rozycki
Quoted 8 lines · Songmao Tian
Quoted 5 lines
Huh? Have you managed to find an 8259A clone *that* broken? So what does it return if you write
0xcto the address0x20in the I/O port space and then read back from that location? You should complain to theIt'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.Quoted 8 lines
Quoted 6 lines
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.Quoted 6 lines
Quoted 6 lines
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...
Quoted 11 lines
Quoted 2 lines
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
arch/mips/kernel/i8259.c +1 -5
@@ -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;
include/asm-mips/i8259.h +53 -6
88 lines not on this page · raw message
Quoted 5 lines · Songmao Tian
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