Re: Nokia N900: musb is in wrong state after boot

[joerg Reisenweber <joerg@openmoko.org>]

[-- Attachment #1: Type: text/plain, Size: 2396 bytes --]

On Thu 21 January 2016 09:41:46 Tony Lindgren wrote:
> Then for supporting the USB host mode.. We should add regulator support
> to the USB PHY driver so if the ID pin is grounded, the PHY driver enables
> the VBUS regulator. That too seems to need some coordination between the
> drivers/phy/phy-twl4030-usb.c and 1707 driver if the ID pin interrupt is
> only detected in drivers/phy/phy-twl4030-usb.c.

Note that, while this is probably a good thing to do, it needs to be 
sufficiently loose coupling to allow user to 'intercept' this VBOOS regulator 
enabling and instead allow device charging while in externally powered 
hostmode. There's even a spec for this in USB-docs-foo iirc, something along a 
certain resistor value on ID to GND - alas I guess the twl4030 is not capable 
to detect such sophisticated signaling, and anyway it's always desirable to 
allow user to manually override the VBOOST and enable VBUS-charging while in 
hostmode.

On N900 the situation is even more complex since the 1707 doesn't support 
genuine ID detection, neither does it support emulated ID grounding. And 
there's no other method than a ID=GND message from PHY to musb core to make 
the musb core state engine transfer into proper hostmode. Thus my H-E-N 
hostmode botch abuses debug flags to force the musb core into a "emulated" 
hostmode and this mode doesn't support USB speed detection. Thus speed 
settings are forced onto musb core and PHY by software, and the musb core 
speed bits are only effective before session enabled. 
Bottom line: you need VBUS to try and negotiate speed with the attached device 
in hostmode, but to actually set this speed you detected by software means, 
you need to disable and discharge VBUS again, or musb core won't care about 
the speed you set. To be utterly clear: unconditional enabling of VBUS in 
ID=GND won't work.

This is quite complex and it's questionable if it could get handled reasonably  
in kernel space. *Very* N900 specific niche solution, I'd not think it's suited 
for upstreaming.

/jOERG
-- 
()  ascii ribbon campaign
/\  
against html e-mail - against proprietary attachments
http://www.georgedillon.com/web/html_email_is_evil.shtml          
http://www.nonhtmlmail.org/campaign.html
http://www.georgedillon.com/web/html_email_is_evil_still.shtml    
http://www.gerstbach.at/2004/ascii/ (German)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]