On Tue, Jan 26, 2010 at 02:35:21PM +0100, ext David Brownell wrote:
On Tuesday 26 January 2010, Mark Brown wrote:
On Tue, Jan 26, 2010 at 03:16:20AM -0800, David Brownell wrote:
> I'd vote to convert all the USB-to-charger interfaces so
> they use notifiers. After fixing the events ... see
> comments below. :)
Yes please - it's not just chargers either, this can also be used by
PMICs which do power path management that includes USB.
Color me confused ... what do you mean by "power path"?
Do you mean something like "the board as a whole can take N mA of
current from USB", rather than specifically addressing a charger?
It's not uncommon to do things like use VBUS current to power the
USB circuitry, too. That can leave less for other purposes. All
of that being rather board-specific.
> Those seem like the wrong events. The right events for a charger
> would be more along the lines of:
> - For peripheral: "you may use N milliAmperes now".
> - General: "Don't Charge" (a.k.a. "use 0 mA").
> I don't see how "N" would be passed with those events ...
These are good for the peripheral side. You do get to pass a void *
along with the notifier value, that could be used to pass data like the
current limit.
I don't think I saw that being done ... either in code, comments,
or documentation. Passing N is fundamental.
yeah, my bad. I should have said that, but it's more related to the
implementation of the notifier_block.
> A host *might* want to be able to say things like "supply
> up to N milliAmperes now", e.g. to let a regulator choose
> the most efficient mode.
Yes, they definitely want this - not just for efficiency but also to
allow current limiting to protect the system from excessive current
drain.
There are load bursting issues too. All part of the USB spec;
a load that's OK for 1 millisecond might not be OK for 1 second.
if you get a SetConfiguration(config), then you can use that load for as
long as needed, the limitation is when not enumerated, afaict.
ISTR the "supply N mA" refers to an average. And there are some
limits to the capacitance that can practically be stuck on VBUS
output lines (which includes the cable). Solvable problems, but
not always pretty if software has to think it through.
Thing is, supplying current is a bit more involved. If the
board can't supply 300 mA, the USB configuration selection
mechanism has to know that, so it never selects peripheral
configurations which require that much current.
but that's done already by the usb core, no ? It rules out configuration
based on the hub->power_budget (can't remember if the field is that
exact name).
--
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
