> 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?
Separate. Beside, I'm not even sure any of the OSes gives us access to it... at least the initial patches from Sony that were using virtual PCI had their own "image" of the EHCI & OHCI config space in the kernel... > 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. Yeah, that and other things.... but I'll stay polite today :-) > 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. Heh, indeed :-) > 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. Ben. ------------------------------------------------------------------------- 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
