public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Anton Vorontsov <cbou@mail.ru>
To: David Brownell <david-b@pacbell.net>
Cc: Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/7] [RFC] Common power driver for Linux gadgets
Date: Fri, 13 Apr 2007 15:30:56 +0400	[thread overview]
Message-ID: <20070413113056.GA16342@zarina> (raw)
In-Reply-To: <200704130325.13813.david-b@pacbell.net>

On Fri, Apr 13, 2007 at 03:25:13AM -0700, David Brownell wrote:
> On Friday 13 April 2007 2:52 am, Anton Vorontsov wrote:
> > > > But I got the point, and yes I can't explain why it works correctly.
> > > 
> > > It probably doesn't work correctly.  But it's not broken enough to
> > > fail badly.
> > 
> > Can that comment be an explanation?
> > 
> > --- drivers/usb/gadget/pxa2xx_udc.c:
> > static const struct usb_gadget_ops pxa2xx_udc_ops = {
> >         .get_frame      = pxa2xx_udc_get_frame,
> >         .wakeup         = pxa2xx_udc_wakeup,
> >         .vbus_session   = pxa2xx_udc_vbus_session,
> >         .pullup         = pxa2xx_udc_pullup,
> > 
> >         // .vbus_draw ... boards may consume current from VBUS, up to
> >         // 100-500mA based on config.  the 500uA suspend ceiling means
> >         // that exclusively vbus-powered PXA designs violate USB specs.
> 
> That's basically a "plug in implementation here".  Nobody's yet done
> that on a platform that _uses_ the VBUS power.
> 
> 
> > };
> > 
> > 
> > Comparing to omap_udc.
> > 
> > --- drivers/usb/gadget/omap_udc.c
> > static int omap_vbus_draw(struct usb_gadget *gadget, unsigned mA)
> > {
> >         struct omap_udc *udc;
> > 
> >         udc = container_of(gadget, struct omap_udc, gadget);
> >         if (udc->transceiver)
> >                 return otg_set_power(udc->transceiver, mA);
> 
> Where the transceiver would then delegate to something else,
> like the tps65010 driver.
> 
> 
> >         return -EOPNOTSUPP;
> > }
> > [...]
> > static struct usb_gadget_ops omap_gadget_ops = {
> >         .get_frame              = omap_get_frame,
> >         .wakeup                 = omap_wakeup,
> >         .set_selfpowered        = omap_set_selfpowered,
> >         .vbus_session           = omap_vbus_session,
> >         .vbus_draw              = omap_vbus_draw,
> 
> .... which has most certainly been on platforms which are hooked
> up to draw power from VBUS.
> 
> 
> >         .pullup                 = omap_pullup,
> > };
> > 
> > 
> > 
> > Regarding API. If you all you want is to know how much power you need to
> > ask from VBUS, we can extend external power interface... thus suppliers
> > could ask their power consumption requirements in mA/uA, and these
> > requests will be forwarded to power supply driver, and power driver will
> > forward that request to USB transceiver (via platform hook).
> 
> I don't folow what you're saying.  The control flow *MUST* be that
> the USB stack provides the only indication of how much power may
> be drawn through the VBUS supply.  Nothing else in the system has
> the knowledge of what's legal, and when.
> 
> If you want to talk about a "supplier", the way to put it might
> then be that the USB stack is saying "here's N mA power for you";
> it's supplying the power, not the other way around.
> 
> There's no "ask" involved, since the host controls "N".  So the
> host supplies, the USB gadget stack interprets that, and some
> power component must obeys.  That includes rules like reducing
> VBUS draw to ~500 uA when the host suspends the USB link.

This framework (pda_power) support ability to charge from USB. But
it is only dispatcher, which implements logic. Issues like what
exact mA to draw, and how all that communicate to USB stack, left
to specific devices and/or additional drivers, users of framework.

In this regard, "USB" is just a label. Can be replaced with
"alternative power source".

> - Dave

-- 
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.org/bd2

  reply	other threads:[~2007-04-13 11:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-13  6:06 [PATCH 2/7] [RFC] Common power driver for Linux gadgets David Brownell
2007-04-13  7:36 ` Anton Vorontsov
2007-04-13  8:42   ` David Brownell
2007-04-13  9:52     ` Anton Vorontsov
2007-04-13 10:25       ` David Brownell
2007-04-13 11:30         ` Anton Vorontsov [this message]
2007-05-07  1:39 ` David Brownell
2007-05-07  2:40   ` Anton Vorontsov
  -- strict thread matches above, loose matches on Subject: below --
2007-04-11 23:24 Anton Vorontsov
2007-04-13 13:50 ` Anton Vorontsov
2007-04-16 20:16   ` Russell King
2007-04-16 20:43     ` Anton Vorontsov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070413113056.GA16342@zarina \
    --to=cbou@mail.ru \
    --cc=david-b@pacbell.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox