Messages in this thread | | | Date | Fri, 13 Aug 1999 23:50:29 +0200 | From | Benjamin Herrenschmidt <> | Subject | Re: New resources - pls, explain :-( |
| |
On Wed, Aug 11, 1999, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>Its cute but if you think harder the implementation would suck > >> right thing" for that bus. One could add "bigendian_writel()" and >> "littleendian_writel()" to satisfy the Linus constraint of making >> unusual usage of writel() obvious. > >So every I/O has an if in it. Nothing like stalling the pipeline before we >probably stall on I/O writes to make things twice as painful.
And what about simply having a struct io_bus containing function pointers to read/write and ioremap routines ? This way, we could hide all the i/o range offset issues when using several busses (we do have such problems with the ppc, especially with IDE, see recent discussion of linuxppc-dev mailing list). Each driver would have an bus structure associated with the device, eventually provided by the resource tree, and the only overhead of i/os could be the indirect function call.
For the endian issue (which I think is a non-issue) , most of the time, the endian is known at compile time and could get be resolved by macros. If it's not the case, then just add two sets of i/o function pointers in the bus structure.
Also, each bus stucture (let's call this a bus driver) can have it's own alloc/dealloc range functions associated, and eventually generic notifiers for hotswap.
I beleive we can build some kind of "device-tree" which would be made of a virtual root, containing busses, containing resources trees. Looks a bit like Open Firmware ;-)
-- Perso. e-mail: <mailto:bh40@calva.net> Work e-mail: <mailto:benh@mipsys.com> BenH. Web : <http://calvaweb.calvacom.fr/bh40/>
- 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/
| |