> -----Original Message----- > From: David Brownell [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 09, 2006 2:05 AM > To: Li Yang-r58472 > Cc: linux-usb-devel@lists.sourceforge.net > Subject: Re: OTG HNP problem with EHCI > > On Wednesday 08 March 2006 5:12 am, Li Yang-r58472 wrote: > > > > While I dug deeper in the HNP process with EHCI host, I found > > [ that your mailer is not wrapping lines at 80 characters ...? ] Need I do that? I will if it's the convention. > > > > there is a conflict. The OTG spec defines that, in HNP, default-a > > device always supplies the vbus power even in peripheral mode. And > > thus default-b device will work in host mode with port power off. > > Here is the problem, if I don't set the PP(Port Power) bit in PORTSC > > register of EHCI(Linux ehci stack automatically sets it, but we > > It's the generic hub driver that's asking EHCI to set that bit. > > But an OTG root hub doesn't behave quite like a normal hub. Your > OTG controller needs to take over management of VBUS, and hence > by implication report not-quite-the-truth to usbcore. (At least > for now. It'd be possible to make the hub driver understand more > about OTG, but that's not been at the top of anyone's agenda.) > Yes, we have added OTG specified operation here. However, our OTG controller lacks control on VBUS. The only VBUS control I can find is via port power bit. The other way is to control through the ULPI registers on the transceiver. I don't if they will conflict to set port power to 1 on controller and DrvVbus to 0 on transceiver. And it is not good do transceiver operations at hub_control level. Looks like it's the shortcoming of our controller. > > > can by-pass it), the port will not working according to the EHCI > > spec. Otherwise, if I set the PP bit, the b_host will drive vbus > > which violates the OTG spec. > > Presumably you have a solution for the B_IDLE and B_PERIPHERAL cases > too? If so, I'm puzzled why that is being deactivated here. Or do > you not have the basic cable-based role switching working? HNP is > advanced stuff; get the basics working first.
B_IDLE and B_PERIPHERAL are in device mode in which the Port Power bit is not cared. It's always the A_HOST to driver vbus. So the cable-based switching is working very well. > > > > Does anyone have an idea on how to get around this? > > The best solution is to have HCD methods like hub_control() be > routines that understand the special requirements for VBUS, and > which preprocess requests accordingly. > > So for example hub_control() could forward all requests except > those related to port power features directly to the standard > EHCI routine ... but those requests would be handled specially. > In your case, they'd interact with the OTG state machine. > > - Dave ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
