On Tue, Dec 08, 2009 at 04:04:32PM +0200, Felipe Balbi wrote: > 1. How/when to kick the charger detection > > problem: Different boards and different transceivers > > if you have an i2c connected transceiver which interrupts > cpu when VBUS level goes high, then we're good. We kick usb > charger detection based on the VBUS irq. Ok, that's easy. > 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 ? How does the hardware designers of the latter issue expect it to work? I can't imagine that loosing communication is a correct thing to have happen here, can't they fix their design? It seems like a driver is going to be needed, as either way you need to detect it from within the kernel, right? > 2. Preventing usb gadget controller from connecting to the usb bus while > usb charger detection is ongoing. Just do the detection first before binding the driver to the device? thanks, greg k-h -- 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
