* joerg Reisenweber <joerg@xxxxxxxxxxxx> [160121 10:45]: > 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. OK, I think this is what's happening with the Motorola LapDock BTW. It always feeds the VBUS, well most of the time. Do you have some pointer to the "certain resistor value on ID to GND" spec? Is it maybe part of the carkit related parts of the USB spec? > 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. Yeah OK. I think we should be able to support the aux VBUS regulator part with mainline kernel though. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
