about cs5536 interrupt ack

about cs5536 interrupt ack

[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,

"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

Re: about cs5536 interrupt ack

[Maciej W. Rozycki]

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:
> 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.

> 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

Re: about cs5536 interrupt ack

[Songmao Tian]

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:
>> 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.
>   
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;

Re: about cs5536 interrupt ack

[Sergei Shtylyov]

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:
> 1) 8259 receive a int, a bit irr got set.
> 2) 8259 assert intr.
> 3) northbrige generate a int ack cycle.

    To what, PCI?

> 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.

> northbridge with a interrupt vector.

    As I said, CS5536 is northbridge in itself.

> 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

> 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

Re: about cs5536 interrupt ack

[Sergei Shtylyov]

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

Re: about cs5536 interrupt ack

[Songmao Tian]

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:)

Re: about cs5536 interrupt ack

[Songmao Tian]

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:
>>> 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.
>>   
> 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.

Re: about cs5536 interrupt ack

[Sergei Shtylyov]

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

Re: about cs5536 interrupt ack

[Maciej W. Rozycki]

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

Re: about cs5536 interrupt ack

[Maciej W. Rozycki]

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:
> 
> 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!

> > 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

Re: about cs5536 interrupt ack

[Maciej W. Rozycki]

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

Re: about cs5536 interrupt ack

[Songmao Tian]

[-- Attachment #1: Type: text/plain, Size: 2210 bytes --]

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
>
>
>
>   


[-- Attachment #2: diff --]
[-- Type: text/plain, Size: 2758 bytes --]

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);
 

Re: about cs5536 interrupt ack

[Maciej W. Rozycki]

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