On Tue, Dec 08, 2009 at 04:04:32PM +0200, Felipe Balbi wrote: [...] > with e.g. RX-51 board, which uses a ulpi-connected transceiver (no > i2c control bus) and no irq line to cpu, we don't have information > on when to kick the charger detection. Moreover, we have to keep > e.g. musb (in RX-51) alive because it's the only way to have access > to the ulpi bus. Kicking the charger detection also breaks usb > communication during the time the detection is ongoing. > > How to tackle those problems ? Should we leave that to userland ? > Should we implement a "musb_power_supply.c" driver ? I'd say musb_power_supply.c. In the kernel you have all the control, in the userspace you don't have that much. You especially need the control if one thing could possibly distract another. Plus, after all, these are hw details that userspace shouldn't care about, in my opinion. > 2. Preventing usb gadget controller from connecting to the usb bus > while usb charger detection is ongoing. > > problem: spurious irqs during charger detection > > We need this in order to avoid "spurious" irqs comming while > charger detection is ongoing. > > If we kick charger detection when only VBUS + GND pins a > physically attached to the usb receptacle, the usb gadget > controller could see the DP Vsrc as a reset signal (this happened > on RX-51). If you're transceiver only supports BC1.0 then there's > nothing much we can do besides deboucing some 300ms or so before > kicking the charger detection. Another solution is to disable all > irqs (from gadget controller) and disable its data pullups (didn't > test that though). Wouldn't debouncing just work for both cases? 300ms delay for charging detection doesn't sound that bad. In pda_power.c we have much longer debouncing periods. Thanks, -- Anton Vorontsov email: cbouatmailru@xxxxxxxxx irc://irc.freenode.net/bd2 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html