Hi,
On Tue, Dec 08, 2009 at 03:54:48PM +0100, ext Anton Vorontsov wrote:
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.
than it would mean that we would have to poll for charger detection
until we find it and I guess that wouldn't be acceptable. Specially on
embedded, battery powered devices. I would have wake up the cpu way too
much in order to detect a charger; iow I would have to consume lots of
juice from the battery in order to try to charge the battery. Doesn't
sound good.
I would like to the power supply interface, but I would like to make it
so that "cat /sys/class/power_supply/..../online" to actually trigger
the usb charger detection.
Plus, after all, these are hw details that userspace shouldn't care
about, in my opinion.
sure..
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.
and if the connector isn't connected completely ever ? We will screw up
things again. We need to be sure the data lines are physically attached
before kicking charger detection, but that's only possible with USB BC
1.1, not 1.0.
Just to illustrate the problem, this is how a usb connector look like:
----
|---- vbus
|-- d-
|-- d+
|-- id
|---- gnd
----
so vbus and gnd will be attached before data lines are attached. That is
when things start to break.
--
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
