* PCI interrupt lost @ 2004-12-13 12:45 Dimitris Lampridis 2004-12-13 12:48 ` Dimitris Lampridis 2004-12-13 14:59 ` Zwane Mwaikambo 0 siblings, 2 replies; 9+ messages in thread From: Dimitris Lampridis @ 2004-12-13 12:45 UTC (permalink / raw) To: Linux Kernel [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: PCI interrupt lost 2004-12-13 12:45 PCI interrupt lost Dimitris Lampridis @ 2004-12-13 12:48 ` Dimitris Lampridis 2004-12-13 14:59 ` Zwane Mwaikambo 1 sibling, 0 replies; 9+ messages in thread From: Dimitris Lampridis @ 2004-12-13 12:48 UTC (permalink / raw) To: Linux Kernel [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: PCI interrupt lost 2004-12-13 12:45 PCI interrupt lost Dimitris Lampridis 2004-12-13 12:48 ` Dimitris Lampridis @ 2004-12-13 14:59 ` Zwane Mwaikambo 2004-12-13 17:08 ` linux-os 2004-12-15 10:54 ` Dimitris Lampridis 1 sibling, 2 replies; 9+ messages in thread From: Zwane Mwaikambo @ 2004-12-13 14:59 UTC (permalink / raw) To: Dimitris Lampridis; +Cc: Linux Kernel 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? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: PCI interrupt lost 2004-12-13 14:59 ` Zwane Mwaikambo @ 2004-12-13 17:08 ` linux-os 2004-12-15 11:11 ` Dimitris Lampridis 2004-12-15 10:54 ` Dimitris Lampridis 1 sibling, 1 reply; 9+ messages in thread From: linux-os @ 2004-12-13 17:08 UTC (permalink / raw) To: Zwane Mwaikambo; +Cc: Dimitris Lampridis, Linux Kernel 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: PCI interrupt lost 2004-12-13 17:08 ` linux-os @ 2004-12-15 11:11 ` Dimitris Lampridis 2004-12-16 0:17 ` Kenji Kaneshige 0 siblings, 1 reply; 9+ messages in thread From: Dimitris Lampridis @ 2004-12-15 11:11 UTC (permalink / raw) To: linux-os; +Cc: Linux Kernel [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: PCI interrupt lost 2004-12-15 11:11 ` Dimitris Lampridis @ 2004-12-16 0:17 ` Kenji Kaneshige 0 siblings, 0 replies; 9+ messages in thread From: Kenji Kaneshige @ 2004-12-16 0:17 UTC (permalink / raw) To: Dimitris Lampridis; +Cc: linux-os, Linux Kernel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: PCI interrupt lost 2004-12-13 14:59 ` Zwane Mwaikambo 2004-12-13 17:08 ` linux-os @ 2004-12-15 10:54 ` Dimitris Lampridis 2004-12-15 23:17 ` Guennadi Liakhovetski 1 sibling, 1 reply; 9+ messages in thread From: Dimitris Lampridis @ 2004-12-15 10:54 UTC (permalink / raw) To: Zwane Mwaikambo; +Cc: Linux Kernel [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: PCI interrupt lost 2004-12-15 10:54 ` Dimitris Lampridis @ 2004-12-15 23:17 ` Guennadi Liakhovetski 2004-12-15 23:22 ` Guennadi Liakhovetski 0 siblings, 1 reply; 9+ messages in thread From: Guennadi Liakhovetski @ 2004-12-15 23:17 UTC (permalink / raw) To: Dimitris Lampridis; +Cc: Zwane Mwaikambo, Linux Kernel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: PCI interrupt lost 2004-12-15 23:17 ` Guennadi Liakhovetski @ 2004-12-15 23:22 ` Guennadi Liakhovetski 0 siblings, 0 replies; 9+ messages in thread From: Guennadi Liakhovetski @ 2004-12-15 23:22 UTC (permalink / raw) To: Dimitris Lampridis; +Cc: Zwane Mwaikambo, Linux Kernel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2004-12-16 0:36 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-12-13 12:45 PCI interrupt lost Dimitris Lampridis 2004-12-13 12:48 ` Dimitris Lampridis 2004-12-13 14:59 ` Zwane Mwaikambo 2004-12-13 17:08 ` linux-os 2004-12-15 11:11 ` Dimitris Lampridis 2004-12-16 0:17 ` Kenji Kaneshige 2004-12-15 10:54 ` Dimitris Lampridis 2004-12-15 23:17 ` Guennadi Liakhovetski 2004-12-15 23:22 ` Guennadi Liakhovetski
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).