Prev: tty: usb_serial_mos7720: Fix get_lsr_info
Next: [PATCH] block: fix bio_add_page for non trivial merge_bvec_fn case
From: Felipe Balbi on 26 Jan 2010 09:30
Hi again,

On Tue, Jan 26, 2010 at 03:10:16PM +0100, Balbi Felipe (Nokia-D/Helsinki) wrote:
>On Tue, Jan 26, 2010 at 12:16:20PM +0100, ext David Brownell wrote:
>>On Friday 11 December 2009, Felipe Balbi wrote:
>>> The notifier will be used to communicate usb events
>>> to other drivers like the charger chip.
>>
>>Good idea ... but not OTG-specific. It doesn't seem to me
>
>thanks

just remember of another problem which I couldn't solve yet:

if you boot the board with the usb cable already attached, then we miss
the first notification because when the notifier is called, usb
controller driver isn't probed yet.

--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Oliver Neukum on 26 Jan 2010 09:30
Am Dienstag, 26. Januar 2010 15:14:43 schrieb Felipe Balbi:
> >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.

And when suspended.

HTH
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Mark Brown on 26 Jan 2010 09:30
On Tue, Jan 26, 2010 at 05:35:21AM -0800, David Brownell wrote:
> On Tuesday 26 January 2010, Mark Brown wrote:

> > 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"?

In the sort of design I'm talking about there is generally a system
power rail which is generated from the various power sources available
to the system, which might include a combination of batteries, USB and
wall adaptors. The power path management logic is the hardware which
controls which of these are actually being used as supplies, and may
also include battery charger management.

> Do you mean something like "the board as a whole can take N mA of
> current from USB", rather than specifically addressing a charger?

Pretty much, from this point of view.

> 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.

In this sort of design either VBUS goes through the power path
management logic before anything else gets to use it or the hardware
will know about the headroom it needs to leave. The power path
management will usually do things like try to suppliment VBUS with any
battery that's available to generate the main system supply rail.

This all needs to function without software since it tends to get used
to decide things like if the system is able to begin power up at all, .

> > > 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.

I think we're talking at cross purposes - I was reading "these events"
as being the new events quoted above, not the events in the existing
code. I certainly agree that N is fundamental.

> 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.

Indeed, the specific limits are more used for protection against things
like the connected devices drawing more current than they claimed than
anything else.

> 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!

Understandable. It would be good to have an idea what sort of general
direction to go in there, though I do agree that the gadget case is much
more important here.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Felipe Balbi on 26 Jan 2010 09:40
On Tue, Jan 26, 2010 at 03:24:49PM +0100, ext Oliver Neukum wrote:
>Am Dienstag, 26. Januar 2010 15:14:43 schrieb Felipe Balbi:
>> >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.
>
>And when suspended.

but when suspended, we have to cut power ASAP. If not enumerated we can
still draw power for a few miliseconds due to dead battery provision.

--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: David Brownell on 26 Jan 2010 10:10
On Tuesday 26 January 2010, Felipe Balbi wrote:
> >> +enum usb_xceiv_events {
> >
> >Let's keep charger events separate from anything else,
> >like "enter host mode" or "enter peripheral mode" (or
> >even "disconnect"). �The audiences for any other types
> >of event would be entirely different.
>
> the idea was to notify USB events to interested drivers, not only "usb
> charger events".

There are thousands of events that could be issued.
I'd rather start with one specific problem, which
can really benefit from being solved.

If necessary, other events can be added later.


> >Right now there's a mess in terms of charger hookup,
> >so getting that straight is IMO a priority over any
> >other type of event. �Using events will decouple a
> >bunch of drivers, and simplify driver configuration.
>
> well, if you consider that this transceiver isn't really otg specific,
> then this is already wrong.

It's the only transceiver interface we have; and it
works for OTG transceivers in peripheral-only mode,
as well as host-only and dual-role modes. So it's
not especially wrong.


However, "you can consume N milliAmperes now" doesn't
need to be coupled to a transceiver at all. In fact,
it works just fine with any pure peripheral interface.
The gadget stack uses such calls ... and doesn't need
to be coupled to any transceiver. (But obviously it
can hook up to an OTG transceiver.)



> >> +����USB_EVENT_NONE, � � � � /* no events or cable disconnected */
> >> +����USB_EVENT_VBUS, � � � � /* vbus valid event */
> >> +����USB_EVENT_ID, � � � � � /* id was grounded */
> >> +����USB_EVENT_CHARGER, � � �/* usb dedicated charger */
> >> +����USB_EVENT_ENUMERATED, � /* gadget driver enumerated */
> >
> >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 have to disagree, which information would you used to kick the usb
> dedicated charger detection other than VBUS irq from transceiver ?

That's why I said what I did about the separate charger spec (and
you quoted it below): it's not going to be less than those two
ops, which your events don't really capture.

That's "bonus" functionality though ... among other reasons, it's
not all that common yet. The basic "charge battery over USB"
scenario needs to work without that stuff.


> So we need at least that, and also need to notify when the charger
> detection is finished, so we can enable data pullups on the link.
> Remember we might be connected to a charging downstream port.

So you're presuming some separate component will do charger
detection by listening for events? If it's mucking with the
pullups, that seems very much like what an OTG transciever
needs to be managing. And thus, perhaps, transceiver code.

If there's such a separate component, I'd like to see some
detail about how it'd work. But ... at first glance, it'd
have thought it'd be simplest inside a transceiver driver.


> >I don't see how "N" would be passed with those events ...
>
> there's a void * we can use to pass bMaxPower field of the selected
> configuration.

Needs to be part of the event spec...


> >Haven't looked at the details of the charger spec, but
> >those two events are the *basics* from the USB 2.0 spec,
> >so "official" charger hardware wouldn't be less capable.
>
> I believe the dedicated charger is also "basic".

We could take a vote to see how many folk have even seen
one, much less own one. They're not very common, and not
part of the USB 2.0 spec. That's why I say "not basic".


> >Thing like different levels of VBUS validity, ID grounding,
> >and so forth ... wouldn't be very relevant. �An OTG driver
> >will do various things, internally, when ID grounds; but
> >anything else is a function of what role eventually gets
> >negotiated. �And for the charger, they all add up to "Don't
> >Charge" (since ID grounded means A-role, sourcing power).
>
> ID grounding event is necessary if you have an external charge pump.
> At least the boards I've been working use an external chip as the USB
> Charger and Charge pump, iow, the transceiver doesn't source VBUS on ID
> ground, but the charger chip is put into "boost" mode for that role.

As you say: transceiver stuff. What I'm used to seeing is
what the OTG spec says: ID grounding is an event, which
triggers state machine transitions. One such transition
involves sourcing VBUS power and making sure it ramps up
properly. Activating that, and monitoring it, depend on
hardware details which are tightly coupled to transceiver
logic and implementation.


> >> �#define USB_OTG_PULLUP_ID�����������(1 << 0)
> >> �#define USB_OTG_PULLDOWN_DP���������(1 << 1)
> >> �#define USB_OTG_PULLDOWN_DM���������(1 << 2)
> >> @@ -70,6 +80,9 @@ struct otg_transceiver {
> >> �����struct otg_io_access_ops��������*io_ops;
> >> �����void __iomem��������������������*io_priv;
> >>
> >> +����/* for notification of usb_xceiv_events */
> >> +����struct blocking_notifier_head���notifier;
> >
> >Why "blocking"? �That seems kind of unnatural; for example,
> >the main users -- like usb_gadget_vbus_draw() -- would be
> >called in IRQ context (blocking not allowed).
>
> what about irqs running in thread, wouldn't we "BUG sleeping in irq
> context" ?

Iff the IRQ has a thread context, it can block.

But a SET_CONFIGURATION request is mostly going to
be delivered to a hard IRQ context, and that is what
will pass the host's vbus_draw configuration to the
hardware. (Same for most of the other events you
sketched.)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: tty: usb_serial_mos7720: Fix get_lsr_info
Next: [PATCH] block: fix bio_add_page for non trivial merge_bvec_fn case