Re: 2.2.15 driver OK on UP - no ints on SMP (SOLVED)

From: Linus Torvalds (torvalds@transmeta.com)
Date: Thu Jul 06 2000 - 13:30:07 EST


In article <Pine.LNX.3.96.1000706123221.6690B-100000@thing2.opinicus.com>,
William Montgomery <william@opinicus.com> wrote:
>
>So how can my driver my driver work fine in UP and not in SMP when
>using the pci_read_config* calls?

On UP, we don't generally use the IO-APIC and it's more advanced irq
routing features. So on a regular UP compile, there will be a 1:1
relationship between what the device _thinks_ the irq is, and what it
truly is..

>My workaround is to use
> struct pci_dev *dev;
>and when pci_find_device() inits dev, I use dev->irq instead of
> pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
>
>Can anyone explain this?

The above is not a work-around. It's the way you are supposed to work.

In fact, drivers should generally _never_ look at the "generic" part of
the PCI config space, because that part has been parsed for them by the
kernel, which does a whole lot better job of it than most drivers can
ever do. This includes more than just figuring out what the _real_
interrupt routing is. The generic PCI layer does a good job of figuring
out what resources the device has, of what type they are, and how large
they are. And it enables them correctly. Something that is usually a
lot more code than is good for you in a regular driver.

For example, on multi-bus systems (especially 64-bit sparcs with
multiple PCI buses mapped in strange ways), you should not do the config
byte read to figure out where your memory aperture is: you should use
the data in "struct pci_dev *dev" instead, notably you should use the
functions especially created for them: things like

        start = pci_resource_start(dev,nr);

to get at the resource start address. Because again, as with the
interrupt number, the device itself does not know what the global system
mapping is (it so happens that on PC's it's a 1:1 mapping, but that's
not always the case).

                Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:19 EST