Hi all,
I'm trying to think about what would be the best way to support USB
Battery Charging Specification 1.x on Linux kernel.
The problems on design are:
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.
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 ?
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).
I guess there are other issues regarding usb charger detection which
made me think about how would be the best way to tackle this problem. If
you have any comment, please share with us.
--
balbi
--
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
