> From: Andrea Cisternino <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Date: Tue, 30 Oct 2001 16:48:59 +0000
> I'm working on writing support for the USB HC available in our ST40GX1 system > on chip. [...] I am putting my ioport.c hacker hat on: the issue here has more to do with a reuse of generic drivers in weird circomstances than with USB. I think you are not the first who has OHCI core attached to a non-pci bus. SA1100 has something like that. Poke ARM hackers. > On Linux all these devices are available as sections of the address space by > using the I/O functions readX()/writeX(). For example the standard OHCI > Operational Registers are available from kernel address 0xBB170000 after > setting some bits in a system-wide configuration register that controls these > on-chip devices. readb and writeb are illegal oustide of the context of ioremap, I hope you realize that. If you want I/O access functions that work standalone, overload inb and outb. > I'm only changing the pci related sections using conditional compilation. Some > of the features needed by a PCI implementation are not needed in our system > (e.g. hotplug) while extensive use of pci_* routines makes things more > difficult when it comes to memory management. This is a wrong approach in my view and I disagree strongly. pci_* routines are there precisely to avoid conditional compilation. The SH people should make pci_* routines that work with internal buses _as if they were PCIs_. This is the whole point of those routines! If they have external PCI too, you have to figure pci_* routines that receive a bus information in their arguments (e.g. ioremap takes it from high-order bits of "physical address", which your own probing fills when it creates pci_dev; thus you may put what you want there). Then they may work differently for PCI and internal bus, but the point here is that the machinery is hidden from drivers. I suggest that you look at the way other architectures do it, especially sparc, mips, ppc, and cris. The i386 carries too much historic compatibility baggage, which can be distracting. The arm is way to kinky to be a proper educational example, plus its implementation uses vmalloc left and right (on this subject I disagree with RMK). -- Pete _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
