> I've been experimenting with the OHCI interface on the Zaurus SL-C3000 > (Spitz) and have found a few things I wouldn't mind opinions on.
I'll even correlate them to your questions. :) > Firstly, the NDP register in roothub.a on the PXA270 isn't standard and > the number of ports is really the value of NDP+1. The chip supports > three ports and whilst I don't have the third connected but it was > confusing me when it only reported two! I've included a patch below > which corrects this - I'm not sure if this is the right way to do it and > am open to comments. What I'd like to do is have NDP used only in ohci_hub_status() (e.g. the workaround for those early AMD-756 chips) and have the rest of the driver reference some field in "struct ohci_hcd" which is initialized by OHCI "core" code -- iff it starts as zero. That way chip (and board) specific logic could initialize that field to address quirks like this one. (Another example would be the AT91rm9200. PQFP packages have fewer pins than the BGA ones, and one sacrifice was pins for the second OHCI port.) That'd get rid of the ugly #ifdef CONFIG_PXA27x in the core code, which will break for folk doing marginally perverse stuff like tacking a PCI bridge on the external bus to get EHCI and maybe other things. Feel like spinning a patch that looks like that? > There is a counting error in pxa27x_ohci_set_port_power() and > pxa27x_ohci_clear_port_power() as port 3 can't be accessed. Also, > pxa27x_ohci_clear_port_power() doesn't appear to do anything sane and > accesses the wrong register bits. The patch below fixes them. I'm not > sure these functions are even needed as doesn't the ohci driver handle > this? Does the ohci driver require port power settings to be in a > particular state before init? Maybe they can just be deleted? Not sure ... there's no guarantee the board designer has wired up the relevant USBHPEN (power enable) bits. Though if they do, you ought to be right about not needing special case logic there. Most embedded OHCI chips seem to expect those issues to be handled by GPIO pins; PXA 27x is a bit atypical in dedicating such bits. It'd be the USB hub driver that drives power switching, in whatever mode the chip supports. Sometimes that maps to a direct hardware request -- usual on PCs, and in this case the PXA 27x supports it -- but on embedded hardware that seems to be more typically handled with GPIOs instead of the root hub port power bits. > The driver currently assumes PMM_PERPORT_MODE and the patch alters it to > be selected by the machine specific code. This machine specific code > should probably be moved into the appropriate arch/arm/mach-pxa board > drivers. If this is the preferred course of action, I'll write a patch > to do this. Ideally that would be recorded in the dev->platform_data field; yes, that stuff should be board-specific. > I've included the spitz code for reference. In that machine_is_spitz() branch you indented wrong ... :) > The main difference is only > a global power control is used and over current monitoring is disabled. Again, overcurrent support (or lack thereof) is board specific. (Maybe the board doesn't have pins to spare for such a signal going to the CPU...) > There is logic to go into the board support file to control switching > between host and udc mode. I think my hardware might support detection > of the mode but I'm not sure how it will be possible to switch between > the two drivers... You think it might? That'd surprise me. But one way to test is to see whetherboth Mini-A and Mini-B connectors will fit (separately) into the socket on that device ... without forcing anything! If that works, it's likely you have the other hardware needed too. (Last I heard, the pxa27x_udc driver wasn't quite usable yet.) The "role switch" stuff is part of OTG, which PXA 27x should indeed support. You can see how this was done on the OMAP processors (using arm926ejs or arm11xx cores): http://www.linux-usb.org/gadget/h2-otg.html The simple version of role switching just senses the "ID" pin, which is grounded on all Mini-A connectors and floats on all Mini-B ones, and VBUS pin, which is pulled high by the USB host starting a power session with the peripheral. The CPU would get an IRQ when the other end connects, and then power up the relevant controller as part of resuming its driver. (Save power: keep them powered down whenever they're not needed.) The fancier version of role switching also understands "HNP" role negotiation, where the roles can be changed later without needing to re-cable things. There are a few more voltage comparator outputs -- usually from a special OTG transciever -- and fancier handshaking. - Dave > > Richard > ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
