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 11:36:50 +0400	[thread overview]
Message-ID: <20070413073650.GA3763@zarina> (raw)
In-Reply-To: <200704122306.46518.david-b@pacbell.net>

Hello David,

On Thu, Apr 12, 2007 at 11:06:46PM -0700, David Brownell wrote:
> > This driver used to stop code/logic duplication through different
> > machines we porting at handhelds.org. pda_power register machs' power
> > supplies, and will take care about notifying batteries about power
> > changes through external power interface.
> 
> It gets USB power management wrong though.  Have a look at two I2C drivers
> in drivers/i2c/chips:  tps65010.c (which would talk to this API) and then
> isp1301_omap.c (which would talk to the tps65010 driver).  The tps65010
> chip accepts the same two power sources you're addressing here, as part
> of its battery charging responsibilities. [1]
> 
> Key points:
> 
>  - The API needs to say *how much power* can be drawn.  Common values
>    are 8 mA (OTG peripherals before configuration), 100 mA (non-OTG ones
>    before configuration), 500 mA (high power configurations) ... but the
>    exact value depends on what's listed in the configuration descriptor
>    for the chosen configuration, any value 0..500 mA (increments of two)
>    could be appropriate.
> 
>  - Sensing VBUS power is not the same thing as being allowed to consume
>    it.  Again, USB OTG devices are different:  OTG hosts **SUPPLY** the
>    current, so you really don't want to be telling the OTG transceiver to
>    fire up its charge pump (say, 3.0V VBAT converted to 5V VBUS) while at
>    the same time telling the battery manager to use that battery-derived
>    VBUS current to recharge its battery!  Not only would that waste power,
>    but it also deprives the peripheral of the power it needs to draw.
> 
> In general, no component other than the USB peripheral (or host) controller
> driver has any business trying to control how VBUS power is used.  It's
> likely to get it wrong ... as shown by this patch.  ;)
> 
> And that's exactly why the USB gadget API has had calls to manage the USB
> power consumption since mid-2004.  And I wonder why H5000 code evidently
> doesn't implement those calls.
> 
> - Dave
> 
> [1] You may find http://www.linux-usb.org/gadget/h2-otg.html useful too.
>     It gives a high level map of the complicated OTG case, including
>     those drivers, and points out how simpler peripheral-only systems
>     could behave with the same drivers.  However it does turn out to
>     be useful if USB peripheral drivers have a "transciever" notion
>     that can receive "VBUS present" interrupts, letting the peripheral
>     controller driver power down almost *everything* to save power,
>     and that otg_transceiver interface does that job.

I see. Current devices I have just consumes power from USB host. I.e.
they able to boot using only USB and discharged battery. :-/ Even
more, HP iPaq hx4700 able to charge battery from USB (using that driver).
We just setting USB charging GPIO, and it starts consume power from
the host.

But I got the point, and yes I can't explain why it works correctly.

(1) Anyway, you're hinting that you'd want to see some
"usb_vbus_start_consume_power(how much)" callback, which will be
handled by gadget driver? Or it should just start using some gadget api?
Or even pda_battery must become an "usb power supplicant" gadget itself
to consume power by law?

-

I'm stuck in null-modem century, so don't wonder my USB-dumbness.
Will read http://www.linux-usb.org/gadget/h2-otg.html, of course.

Though I'd appreciate answers for (1), thus I can think in right
direction from the start.

Much thanks for your comments.

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

  reply	other threads:[~2007-04-13  7:40 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 [this message]
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
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=20070413073650.GA3763@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