Message-ID: <4694F4EB.8040000@lemote.com>
Date:	Wed, 11 Jul 2007 23:19:07 +0800
From:	Songmao Tian <tiansm@...ote.com>
To:	"Maciej W. Rozycki" <macro@...ux-mips.org>
CC:	LinuxBIOS Mailing List <linuxbios@...uxbios.org>,
	marc.jones@....com, linux-kernel@...r.kernel.org,
	linux-mips@...ux-mips.org
Subject: Re: about cs5536 interrupt ack

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;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists