Messages in this thread | | | Subject | Re: Ideas for abstracting driver IO from bus implementation? | Date | Wed, 17 Mar 1999 15:35:54 GMT | From | David Howells <> |
| |
Alan Cox <alan@lxorguk.ukuu.org.uk> writes: > I2O wants a fairly wide set of tokens - This is a problem I've already hit > I need to be able to reserve PCI devices. The MCA bus code gets this right > with its mark as used/ mark as unused functions.
A number of questions:
(1) Can you give some examples of what tokens you might want? I've been thinking of changing how I label token types to make new types easier to handle (at the moment I use an enum which indexes into a number of tables, but I'm leaning towards some sort of operations lookup table instead). I currently have four types of token:
* interrupt - holds interrupt number, trigger type, share mode and handler routine.
* dma - holds DMA channel
* ioport - holds I/O port range
* memory - holds memory address range and ioremap()'ed flag
I'm thinking of creating a fifth type specifically for PCI devices. This is because, if I'm correct, PCI devices share a set of four IRQ pins, but these IRQ pins are reconfigurable over (pretty much) the whole IRQ range of the CPU. All the real interrupt tokens used by PCI devices anywhere would then be held by the CPU->PCI bridge (PnP-BIOS) device, and PCI devices would themselves have PCI interrupt-pin tokens attached that would reflect this:
* PCI interrupt-pin - holds ref to interrupt token and handler routine.
This would allow PCI device interrupts to be grouped together, and so reconfigured a lot easier.
(2) Can you also clarify by what you mean by 'reserving' PCI devices?
(3) I'm I right in thinking that the MCA mark/unmark stuff is a method of reserving devices?
David Howells
- 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/
| |