On Wed, 2005-08-24 at 14:42 -0700, David Brownell wrote: > 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?
This email will be followed by a patch along these lines. The one thing I'm unsure of is the point at which you can read the NDP value. I've done this in ohci_init and found it didn't seem to be required in ohci_hub_status. See what you think... > 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. They are GPIO pins but on the pxa27x, gpios have alternate functions and the USBHPEN/USBPWR pins fall into that category. As long as the pin is set to be a "normal" GPIO instead of an alternate function, it doesn't matter what state its set to by the ohci controller as it will have no effect on external circuitry. As an example, those pins on spitz have completely different uses which are not USB related. Mainstone uses the pins so it calls pxa_gpio_mode( 88 | GPIO_ALT_FN_1_IN) to set then to their alternate functions. With this in mind, I see no reason for the power control code in the driver. The second patch attached starts to tidy it up. Its incorrect anyway. > 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. On spitz, we have one power gpio (not connected into the ohci logic or the dedicated alternate functions) controlling power to port 2 which is the only one used. Sharp's 2.4 code just sets the power gpio before loading the ohci driver. Is there a way we can have platform code load the ohci driver and power up the port when it detects a device and shutdown otherwise? Reading the link you gave me, it mentions switching the initialisation model for ohci so I'll have to look at that. > Ideally that would be recorded in the dev->platform_data field; yes, > that stuff should be board-specific. > > 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...) I'm also sending a patch to move the existing mainstone code into the platform file (arch/arm/mach-pxa/mainstone.c) and add hooks other platforms such as spitz can use. I've tested this series of patches on spitz and they work. I've only compiled mainstone. > > 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 whether both 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.) I know the hardware can do it as the device came with both leads! I just wasn't sure how clever its detection is. Your hint about the "ID" pin answers my question though - I suspect this goes straight to a gpio. I did a bit of digging and discovered that whilst there is space left on the PCB for an OTG transceiver, they didn't include one. It'll be interesting to see how clever we can be with just what the pxa270 provides... The link to the OTG USB information is interesting and I'll have to see what I can do with it in due course. My priority for now is to get the UDC driver running. I think the hh.org code works but fails over a suspend/resume although I have yet to try it. Once that's done and the rest of the spitz drivers ready for mainline, I'll worry about OTG :) Cheers, 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
