> > Feel like spinning a patch that looks like that? > > This email will be followed by a patch along these lines.
Looks pretty decent; thanks. I'll look at it later when I have some time. Ditto the other patches. > 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... That needs to be tweaked a bit; it's an AMD756 workaround. So it shouldn't really vanish. > > 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. Right; I meant that most/many embedded chips don't even have a dedicated pin mux mode for that. The way they'd handle that in OHCI is to provide their own root hub routines that intercept the power switch commands and diddle the right GPIOs, then delegates everything to the standard root hub. > > 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. A common arrangement. Power could also be gated through an OTG transceiver, like the isp1301 (used on OMAP H2/1611b as well as on PXA27x mainstone). Another one is a USB connection to some other chips on the motherboard, used sort of like a faster i2c. > Sharp's 2.4 code just sets the power gpio before > loading the ohci driver. It'd be more power efficient to leave power off until the ID pin is detected, as I mentioned. (An OTG host would be expected to power it off when no device was connected within a few seconds.) How much VBUS current does that "spitz" board supply ... 100mA? 8mA? > 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. Erm, those are very different things. Sensing the ID pin before turning on power is the best way to go. The very first implementation of this on Linux (OMAP H2) packaged that inside the OTG driver, but it should arguably be reflected into usbcore. If I were you I'd just have usbcore not worry about it for now. :) > > > 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! Curious... > 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 basic value of OTG is role switching, or maybe better ways to conserve power (depending on where you're coming from). The role switching comes in two parts (cable or protocol based), and cable based switching only needs you to sense the two pins I mentioned. > 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. Last I heard, it also had some problems with the way the hardware needed to know about the configurations, interfaces, altsettings, and endpoints that the software would be using. It couldn't for example support CDC Ethernet with RNDIS as an alternative. > Once that's done and the > rest of the spitz drivers ready for mainline, I'll worry about OTG :) Good, I'm glad someone's looking at that for pxa27x. - Dave ------------------------------------------------------- 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 _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
