PCI interrupt lost

PCI interrupt lost

[Dimitris Lampridis]

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

Hi,
I'm writing a device driver for an embedded USB controller (philips
ISP116x). I'm using the evaluation board provided by philips for my
work. This board is a PCI board featuring the Host Controller ISP1160
and a PCI bridge by PLX.

The bad news (for me) is that I don't get to see any interrupts from my
device. 

The good news is that I've managed to narrow down the problem. Here is
my case:
1) The Host Controller is configured and operating and is producing
interrupts (I used a logic Analyzer and saw it happening).
2) The driver never services these interrupts. The exact behaviour is
dictated by the "trigger" setting of the INT pin. If it is
edge-triggered, the interrupts keep on coming from the HC. If it is
level-triggered, only one interrupt happens and since it is never
serviced, it keeps on forever, blocking any further signals.
3) The driver IS ABLE to service interrupts. The ISR is installed and
functioning (I was able to see that, when the device was sharing the IRQ
and the ISR was called only to return IRQ_NONE, nevertheless showing
that IF an interrupt was to be received, coming from the Host
Controller, the routine would be called, thus clearing the interrupt on
the controller).

So, to make things short, my device is generating interrupts, my code
has a functioning and registered interrupt routine (/proc/interrupts
agrees as well but interrupt count is 0 for the specific IRQ), but no
interrupt is ever received from the PCI card.

What is wrong here? I'm having trouble coming with any new ideas, so I
thought that maybe someone can help me.
I would appreciate any help, please CC me personally as I'm not yet
subscribed to the list, or find me at the linux-usb-devel list.

Thanx in advance,
-- 
Dimitris Lampridis <labis@mhl.tuc.gr>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: PCI interrupt lost

[Dimitris Lampridis]

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

I forgot to ask a final thing:
What is the proper way of configuring my INT pin on the Host Controller?
I can choose:
level/edge triggered
high/low   active
I've been told that PCI interrupts are level trig. active low. Is this
true? I've seen another driver initialize to level trig. active high!
(not that I haven't tried all the 4 cases anyway...)

Thanx again,
-- 
Dimitris Lampridis <labis@mhl.tuc.gr>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: PCI interrupt lost

[Zwane Mwaikambo]

On Mon, 13 Dec 2004, Dimitris Lampridis wrote:

> I'm writing a device driver for an embedded USB controller (philips
> ISP116x). I'm using the evaluation board provided by philips for my
> work. This board is a PCI board featuring the Host Controller ISP1160
> and a PCI bridge by PLX.
> 
> The bad news (for me) is that I don't get to see any interrupts from my
> device. 
> 
> The good news is that I've managed to narrow down the problem. Here is
> my case:
> 1) The Host Controller is configured and operating and is producing
> interrupts (I used a logic Analyzer and saw it happening).
> 2) The driver never services these interrupts. The exact behaviour is
> dictated by the "trigger" setting of the INT pin. If it is
> edge-triggered, the interrupts keep on coming from the HC. If it is
> level-triggered, only one interrupt happens and since it is never
> serviced, it keeps on forever, blocking any further signals.
> 3) The driver IS ABLE to service interrupts. The ISR is installed and
> functioning (I was able to see that, when the device was sharing the IRQ
> and the ISR was called only to return IRQ_NONE, nevertheless showing
> that IF an interrupt was to be received, coming from the Host
> Controller, the routine would be called, thus clearing the interrupt on
> the controller).
> 
> So, to make things short, my device is generating interrupts, my code
> has a functioning and registered interrupt routine (/proc/interrupts
> agrees as well but interrupt count is 0 for the specific IRQ), but no
> interrupt is ever received from the PCI card.

What does the PCI device report as the interrupt line? What do you 
register with request_irq?

	Zwane

Ps. Isn't there already a driver for that controller?

Re: PCI interrupt lost

[linux-os]

On Mon, 13 Dec 2004, Zwane Mwaikambo wrote:

> On Mon, 13 Dec 2004, Dimitris Lampridis wrote:
>
>> I'm writing a device driver for an embedded USB controller (philips
>> ISP116x). I'm using the evaluation board provided by philips for my
>> work. This board is a PCI board featuring the Host Controller ISP1160
>> and a PCI bridge by PLX.
>>
>> The bad news (for me) is that I don't get to see any interrupts from my
>> device.
>>
>> The good news is that I've managed to narrow down the problem. Here is
>> my case:
>> 1) The Host Controller is configured and operating and is producing
>> interrupts (I used a logic Analyzer and saw it happening).
>> 2) The driver never services these interrupts. The exact behaviour is
>> dictated by the "trigger" setting of the INT pin. If it is
>> edge-triggered, the interrupts keep on coming from the HC. If it is
>> level-triggered, only one interrupt happens and since it is never
>> serviced, it keeps on forever, blocking any further signals.
>> 3) The driver IS ABLE to service interrupts. The ISR is installed and
>> functioning (I was able to see that, when the device was sharing the IRQ
>> and the ISR was called only to return IRQ_NONE, nevertheless showing
>> that IF an interrupt was to be received, coming from the Host
>> Controller, the routine would be called, thus clearing the interrupt on
>> the controller).
>>
>> So, to make things short, my device is generating interrupts, my code
>> has a functioning and registered interrupt routine (/proc/interrupts
>> agrees as well but interrupt count is 0 for the specific IRQ), but no
>> interrupt is ever received from the PCI card.
>
> What does the PCI device report as the interrupt line? What do you
> register with request_irq?
>
> 	Zwane
>
> Ps. Isn't there already a driver for that controller?
>

Also, PCI interrupts __must__ be level. It's in the PCI specification.
If this IRQ level is raised, the kernel will call the registered 
interrupts. It has no choice and if it didn't work nobody would
be able to boot. The only  possibility is that somebody else is
using the interrupt and hasn't allocated it shared, or your
code has bug(s).

Also, returning IRQ_NONE will force your ISR to be called repeatedly
until the kernel is forced to shut off the ISR. It should return
IRQ_DONE. You need to allocate the interrupt specified in the
"dev" structure and not attempt to out-think anything. You should
never even care what the raw configuration settings are. If your
code looks at that stuff, it's broken.

     struct pci_dev *pdev;
     pdev = PCI_FIND_DEVICE(PCI_ID, PCI_DEV, pdev);

     // use ioremap_nocache() for BARS.

     request_irq(pdev->irq, my_isr, SA_INTERRUPT|SA_SHIRQ, "device", 
pointer_to_your_stuff);
     pci_set_drvdata(pdev, NULL);	// Not necessary
     pci_set_power_state(pdev, 0);	// Now mandatory
     pci_set_master(pdev);		// PLX is a master
     pci_set_dma_mask(pdev, 0xffffffffULL);	// Future needs on ix86
     pci_set_mwi(pdev);			// If you want
     pci_enable_device(pdev);		// Remember to do this


This __will__ initialize the PLX chip, but you still have to
set/unmask its interrupt registers to get an interrupt.

Both the PLX chip and the kernel code will properly handle an
interrupt. We use these extensively here, so it's just some
bug(s) in your code.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by John Ashcroft.
                  98.36% of all statistics are fiction.

Re: PCI interrupt lost

[Dimitris Lampridis]

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

On Mon, 2004-12-13 at 12:08 -0500, linux-os wrote:
> Also, PCI interrupts __must__ be level. It's in the PCI specification.
> If this IRQ level is raised, the kernel will call the registered 
> interrupts. It has no choice and if it didn't work nobody would
> be able to boot. The only  possibility is that somebody else is
> using the interrupt and hasn't allocated it shared, or your
> code has bug(s).
> 
OK, so level triggered, active low it is.
The interrupt line is not shared by anyone else (right now. in the past
it did but only with other pci devices) as I can see
in /proc/interrupts, but also request_irq() is returning with success.
So no problem there. Therefore, I must agree with you, my code has
bug(s).

> Also, returning IRQ_NONE will force your ISR to be called repeatedly
> until the kernel is forced to shut off the ISR. It should return
> IRQ_DONE. You need to allocate the interrupt specified in the
> "dev" structure and not attempt to out-think anything. You should
> never even care what the raw configuration settings are. If your
> code looks at that stuff, it's broken.
> 
Why returning IRQ_NONE is wrong? if it is not my interrupt but for
another driver for a device sharing the interrupt line, I should leave
it to him to return IRQ_HANDLED. No?

>      struct pci_dev *pdev;
>      pdev = PCI_FIND_DEVICE(PCI_ID, PCI_DEV, pdev);
> 
>      // use ioremap_nocache() for BARS.
> 
>      request_irq(pdev->irq, my_isr, SA_INTERRUPT|SA_SHIRQ, "device", 
> pointer_to_your_stuff);
>      pci_set_drvdata(pdev, NULL);	// Not necessary
>      pci_set_power_state(pdev, 0);	// Now mandatory
>      pci_set_master(pdev);		// PLX is a master
>      pci_set_dma_mask(pdev, 0xffffffffULL);	// Future needs on ix86
>      pci_set_mwi(pdev);			// If you want
>      pci_enable_device(pdev);		// Remember to do this
> 
> 
> This __will__ initialize the PLX chip, but you still have to
> set/unmask its interrupt registers to get an interrupt.
> 
> Both the PLX chip and the kernel code will properly handle an
> interrupt. We use these extensively here, so it's just some
> bug(s) in your code.
> 
The only thing that didn't already exist in my code was
pci_set_power_state(pdev, 0), but it did not make any difference. the
problem persists. Do you think that there is a problem if I request the
irq line after calling pci_enable_device()? I cannot think of anything
else. Everything that you mentioned is already in my code, and yet I can
see no interrupt. Maybe it has something to do with my HW / BIOS?

Thanks a lot,
 
Dimitris Lampridis <labis@mhl.tuc.gr>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: PCI interrupt lost

[Kenji Kaneshige]

Hi,

> The only thing that didn't already exist in my code was
> pci_set_power_state(pdev, 0), but it did not make any difference. the
> problem persists. Do you think that there is a problem if I request the
> irq line after calling pci_enable_device()? I cannot think of anything
> else. Everything that you mentioned is already in my code, and yet I can
> see no interrupt. Maybe it has something to do with my HW / BIOS?
> 

You should call pci_enable_device() first, and then request the irq.

Thanks,
Kenji Kaneshige

Re: PCI interrupt lost

[Dimitris Lampridis]

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

On Mon, 2004-12-13 at 07:59 -0700, Zwane Mwaikambo wrote:
> > So, to make things short, my device is generating interrupts, my code
> > has a functioning and registered interrupt routine (/proc/interrupts
> > agrees as well but interrupt count is 0 for the specific IRQ), but no
> > interrupt is ever received from the PCI card.
> 
> What does the PCI device report as the interrupt line? What do you 
> register with request_irq?

No there's no problem there. I always register the correct interrupt
line (the one that is seen with lspci for example), without explicitly
requesting the number, but by using dev->irq after I've called
pci_enable_device()

> 
> Ps. Isn't there already a driver for that controller?

Yep, and not only one I might add... But none of them is showing the
correct behaviour that a good driver should (in my humble opinion), and
the best efforts are for kernels 2.4

Anyway, thanks

-- 
Dimitris Lampridis <labis@mhl.tuc.gr>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: PCI interrupt lost

[Guennadi Liakhovetski]

On Wed, 15 Dec 2004, Dimitris Lampridis wrote:

> On Mon, 2004-12-13 at 07:59 -0700, Zwane Mwaikambo wrote:
> > 
> > Ps. Isn't there already a driver for that controller?
> 
> Yep, and not only one I might add... But none of them is showing the
> correct behaviour that a good driver should (in my humble opinion), and
> the best efforts are for kernels 2.4

Have you had a look at the recent work of Lothar Wassmann (and others) on 
generalisation of the OHCI driver to be used with other (including non-PCI 
connected) chips, specifically with 116x / 1362 from Philips?

If not - just browse usb-development ML archives for the last couple of 
months - you'll see lots of hits. Didn't look at the driver myself yet, 
but the reaction seems to be very positive from many USB developers

Thanks
Guennadi
---
Guennadi Liakhovetski

Re: PCI interrupt lost

[Guennadi Liakhovetski]

On Thu, 16 Dec 2004, Guennadi Liakhovetski wrote:

> On Wed, 15 Dec 2004, Dimitris Lampridis wrote:
> 
> > On Mon, 2004-12-13 at 07:59 -0700, Zwane Mwaikambo wrote:
> > > 
> > > Ps. Isn't there already a driver for that controller?
> > 
> > Yep, and not only one I might add... But none of them is showing the
> > correct behaviour that a good driver should (in my humble opinion), and
> > the best efforts are for kernels 2.4
> 
> Have you had a look at the recent work of Lothar Wassmann (and others) on 

Too early stroke "enter" - saw your discussion with Lothar after that. So, 
if you need 1160 specifically - good luck... You'll need it. Or better yet 
switch to 1362:-)

Regards
Guennadi
---
Guennadi Liakhovetski