Re: [linux-usb-devel] PXA27x OHCI Driver RFC
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
Re: [linux-usb-devel] PXA27x OHCI Driver RFC
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
Re: [linux-usb-devel] PXA27x OHCI Driver RFC
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
Re: [linux-usb-devel] PXA27x OHCI Driver RFC
On Tue, 2005-08-23 at 12:43 +0200, Bernd Petrovitsch wrote: Just C-specific ones - God knows what people will pass as argument: +#ifdef CONFIG_PXA27x +#define OHCI_GETPORTNUM(x) ((x RH_A_NDP) + 1) +#define OHCI_GETPORTNUM(x) (((x) RH_A_NDP) + 1) +#else +#define OHCI_GETPORTNUM(x) (x RH_A_NDP) +#define OHCI_GETPORTNUM(x) ((x) RH_A_NDP) +#endif Thanks. I also noticed: - ndp = (temp RH_A_NDP); + ndp = OHCI_GETPORTNUM(temp RH_A_NDP); which should have been: + ndp = OHCI_GETPORTNUM(temp); 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
Re: [linux-usb-devel] PXA27x OHCI Driver RFC
On Tue, 2005-08-23 at 11:37 +0100, Richard Purdie wrote: [...] which corrects this - I'm not sure if this is the right way to do it and am open to comments. Just C-specific ones - God knows what people will pass as argument: +#ifdef CONFIG_PXA27x +#define OHCI_GETPORTNUM(x) ((x RH_A_NDP) + 1) +#define OHCI_GETPORTNUM(x) (((x) RH_A_NDP) + 1) +#else +#define OHCI_GETPORTNUM(x) (x RH_A_NDP) +#define OHCI_GETPORTNUM(x) ((x) RH_A_NDP) +#endif Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services --- 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
