Hi,
I'm writing a kernel driver. It is not going to be widely used, so I'm
not motivated to make things nice enough for inclusion in the standard
kernel.
But lspci shows my device:
03:01.0 Serial bus controller [0c80]: Phoenix Contact GmbH & Co. Device 0002 (rev b7)
Flags: bus master, stepping, medium devsel, latency 32, IRQ 14
I/O ports at e070 [size=16]
Memory at f7d00000 (32-bit, non-prefetchable) [size=256K]
Now when I start my module and prod the device a bit, it will generate
an interrupt. (in this case the monitor program needs to start sending
messages to the card.)
Then the kernel reports:
irq 18: nobody cared (try booting with the "irqpoll" option)
I've been writing device drivers in the past, but in the past
when the lspci listed "IRQ 14" then I'd have to request_irq (14, ...
Has this changed? Or is this hardware "odd"/"bad"/"broken" in that it
initializes the PCI devices wrong? (*)
My driver now works with the interrupts coming in nicely on IRQ18...
I have this card where I'm writing my own driver, and another PCI card
that uses an "included-in-the-kernel" driver, and it too behaves as if
it doesn't get any interrupts.
Roger.
(*) Obviously according to everybody "windows works", so could it be
that modern windows simply activates an irq and polls to see what
driver handles it? Or something like that? Ah! That would be somewhat
similar to what "irqpoll" does on Linux!
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
On Mon, 3 Sep 2018 19:16:39 +0200
Rogier Wolff <[email protected]> wrote:
> Hi,
>
> I'm writing a kernel driver. It is not going to be widely used, so I'm
> not motivated to make things nice enough for inclusion in the standard
> kernel.
>
> But lspci shows my device:
>
> 03:01.0 Serial bus controller [0c80]: Phoenix Contact GmbH & Co. Device 0002 (rev b7)
> Flags: bus master, stepping, medium devsel, latency 32, IRQ 14
> I/O ports at e070 [size=16]
> Memory at f7d00000 (32-bit, non-prefetchable) [size=256K]
>
> Now when I start my module and prod the device a bit, it will generate
> an interrupt. (in this case the monitor program needs to start sending
> messages to the card.)
>
> Then the kernel reports:
>
> irq 18: nobody cared (try booting with the "irqpoll" option)
>
> I've been writing device drivers in the past, but in the past
> when the lspci listed "IRQ 14" then I'd have to request_irq (14, ...
The IRQ number in the PCI configuration space is just a label really for
legacy OS stuff. Nothing actually routes interrupts according to it (*).
If it's coming up as 14 that looks more like the BIOS mislabelled it.
Legacy PCI interrupts care about lines and pins not irq numbers.
Are you looking at values after things like pci_enable_device were called
or before ? Are you also looking at what is in pcidev->irq after the
enable ?
> Has this changed? Or is this hardware "odd"/"bad"/"broken" in that it
> initializes the PCI devices wrong? (*)
>
> My driver now works with the interrupts coming in nicely on IRQ18...
>
> I have this card where I'm writing my own driver, and another PCI card
> that uses an "included-in-the-kernel" driver, and it too behaves as if
> it doesn't get any interrupts.
>
> Roger.
>
> (*) Obviously according to everybody "windows works", so could it be
> that modern windows simply activates an irq and polls to see what
> driver handles it? Or something like that? Ah! That would be somewhat
> similar to what "irqpoll" does on Linux!
Does the hardware also support modern INTX interrupts or just the old
legacy ones. Could be Windows is using INTX if so
Alan
(*) PCI doesn't. Certain slightly stoned PCI 'emulations' in some
hardware do.
On Mon, Sep 03, 2018 at 07:09:03PM +0100, Alan Cox wrote:
> On Mon, 3 Sep 2018 19:16:39 +0200
> > irq 18: nobody cared (try booting with the "irqpoll" option)
> >
> > I've been writing device drivers in the past, but in the past
> > when the lspci listed "IRQ 14" then I'd have to request_irq (14, ...
>
> The IRQ number in the PCI configuration space is just a label really for
> legacy OS stuff. Nothing actually routes interrupts according to it (*).
> If it's coming up as 14 that looks more like the BIOS mislabelled it.
> Legacy PCI interrupts care about lines and pins not irq numbers.
>
> Are you looking at values after things like pci_enable_device were called
> or before ? Are you also looking at what is in pcidev->irq after the
> enable ?
The driver used to be for an ISA card. But as the ISA hardware is
becoming less and less available, things were in need of an upgrade.
So... So far I was just doing
inmod mydriver.ko pci=1 irq=14 io=0xae00 mem=0xfda00000
keeping most of the ISA driver. (for testing I was able to run the ISA
card with the upgraded driver that does the PCI card as well...
So io= is the address I got from lspci, mem= and irq= the
same. Apparently All of them are accurate except for the IRQ?
So the answer is: No I wasn't doing pci_enable_device. I guess I'll
have to make a proper PCI driver then. Hmm. OK. I'll look into it.
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
On Mon, Sep 03, 2018 at 07:09:03PM +0100, Alan Cox wrote:
> The IRQ number in the PCI configuration space is just a label really for
> legacy OS stuff. Nothing actually routes interrupts according to it (*).
> If it's coming up as 14 that looks more like the BIOS mislabelled it.
> Legacy PCI interrupts care about lines and pins not irq numbers.
Yeah, on ISA there are lines marked IRQ3, IRQ4 and you pull on such a
line and the CPU gets interrupted.
On PCI there are lines marked IRQA, IRQB... IRQD and you yan one line
and the CPU gets interrupted.
Usually IRQA on the first slot gets wired to IRQB on the second slot
and so on. This is because cards are expected to require only one IRQ,
but /can/ have upto four.
the IRQ register in the PCI configuration space is just an 8bit
register that is required to be able to remember those 8 bits nothing
else.
The BIOS is expected to know which SLOTx INTy line goes where in the
hardware. And then it should store the resulting interrupt number in
that 8-bit register.
Now when Linux knows enough about the hardware (interrupt controller)
to reroute interrupts on an interrupt controller, I would have liked
it to also note the result in the interrupt register in the affected
card. Apparently it doesn't.
Anyway. Yesterday I was: "OK, I'll have to make it into a real
PCI-device-driver", and today I'm thinking: "Now I know how this comes
about, I can make it nicer if I have time left", on to other stuff for
the time being.
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.