On Saturday 09 December 2006 1:03 pm, Benjamin Herrenschmidt wrote: > > > A "fake PCI"? Strange. It'd make more sense to stick things > > onto some bus that's a more direct match. And to make all > > those platforms represent IOIF the same way ... reading between > > the lines, I suspect you had multiple Linux teams at work, who > > didn't cooperate as closely as might have been desirable! > > Multiple companies actually :-)
That's more understandable than when it happens within just one company ... ;) > But the situation is more complicated > than that... The Cell's IOIF itself is just a point-to-point interface > to a southbridge. What's in that bridge (and what type of backbone bus > is in there) is a different matter... But yes, the IBM blades generally > represent all the devices into the "spider" southbridge (or toshiba scc) > as pseudo-PCI device. The illusion is maintained by the firmware (which > has calls for config space accesses on those machines) so it's pretty > much transparent to the OS. In addition, I think the spider chip was > actually designed with that in mind as it does have some pseudo-PCI > config space registers for internal devices iirc. Huh. I guess that part of the PCI model has virtues I'm not used to thinking of. Does that pseudo-configspace cover *all* configuration for each controllers? Or are things like clocks, clock gating, and other chip configuration stuff still in separate registers? I suspect there are design methodology differences afoot here, where folk doing system-on-chip designs don't share priorities with folk doing multi-chip designs ... especially if they're co-designing the hardware with some specific firmware model in mind. > The Toshiba Celleb and PS3 platforms and does things differently though. > Celleb has a pseudo-PCI thingy but the illusion is maintained by the > kernel and it might be changed into a simple of_platform (device-tree > probed platform bus) and the PS3 has other differences related to Sony > Hypervisor which means it needs to use a special bus type to get things > like DMA mapping etc... right. Hardware architectures still not as open as might be. In some cases that's probably wise ... as they say about making sausage, you really do _not_ want to see some of that crap. > > In most cases, the advice is to use "platform_bus", but there can > > be cases where a new bus abstraction is appropriate. > > We try to use of_platform instead (which is similar but linked to the > Open Firmware device-tree). In the case of PS3 though, due to various > hypervisor funkyness (that, among others, result into tricks in the way > DMA mapping is handled), it should really be a special bus type. Yes, OpenFirmware appears to be enough better than e.g. ACPI BIOS that such approaches make sense. > > It'd be advantageous to (re)use the same driver glue. If it > > weren't for the fact that each chip/system vendor ends up with > > minor differences related to system integration, we could make > > do with a lot fewer "ohci-XXX.c" bus glue components. But > > having two (or three) for Cell seems excessive, especially > > if they're all going to the same IOIF ohci controller... > > Actually the same OCHI inside of the southbridge, IOIF itself has little > to do with that. The problem is essentially 3 completely different > environments (2 different hypervisors for Sony & Toshiba and a firmware > that exposes everything as a pseudo-PCI bus for IBM). Interesting. Well, my advice to Geoff still stands: since that quirk workaround is stuff I'd expect the boot firmware to have done, don't push the stuff into the core of the controller driver where it will impact _every_ vendor's OHCI implementation. - Dave ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
