Messages in this thread | | | From | (Linus Torvalds) | Subject | Re: 2.2.15 driver OK on UP - no ints on SMP (SOLVED) | Date | 6 Jul 2000 11:30:07 -0700 |
| |
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/
| |