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. > > 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. 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. Or maybe these two ports can serve 500 mA, but not those two; or their total can't exceed N (function of componentry and power budgeting). Ergo my desire to start with a straightforward problem whose solution has real value (how much VBUS current may be consumed?), and leave some of those other messes for later! - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html