linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Rapoport <mike@compulab.co.il>
To: Liam Girdwood <lrg@slimlogic.co.uk>,
	Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: [RFD] voltage/current regulator consumer interface
Date: Mon, 20 Apr 2009 17:32:21 +0300	[thread overview]
Message-ID: <49EC8775.8060609@compulab.co.il> (raw)

Hi,

Recently there was a brief discussion on linux-arm-kernel list [1] about
controlling voltage regulator state in cases when there is no consumer device
for a particular regulator.

I have some thoughts but I'd like to know people opinion before I start
implementation.

Problem
-------
The regulator framework API provides ability to control the state of
voltage/current regulators from within the kernel. Usually the regulator
supplies power to a device and device driver or some hooks to the platform code
from the device driver manipulate the regulator state. However, the regulator
framework does not have userspace ABI that allows regulator state modifications.
Lack of this ABI prevents fine-grained control for power consumption of devices
such as GPS trancievers and GSM modems. Moreover, in SoC based systems it is
possible to switch on/off power to entire subsystem when it is not used.

Possible solutions
------------------
- Add a platform_driver similar to drivers/regulator/virtual.c that will expose
writable attributes to sysfs thus allowing userspace to control regulator state.
It is the most simple and straight forward solution. However, I have several
questions and I cannot answer them myself:
  Should the driver handle single or several supplies at once?
  If the driver handles single supply isn't it a waste of memory to have a
platform_device per supply?
  If the driver handles several supplies how to define attributes per-supply?
  What attributes will be exposed? Would it be simple 'state' that can be
enabled or disabled? Or the entire set of micorvolts/microamps etc?

- Extend regulator framework so that regulator_consumer_supply entities will
gain their own representation in sysfs. Depending on machine constraints the
supply attributes can be either read-only or writable. I haven't dedicated much
thought to it, so a cannot state any pros and cons.

Any feedback is appreciated.

--
[1] http://lists.arm.linux.org.uk/lurker/message/20090413.125359.613f85ad.en.html

-- 
Sincerely yours,
Mike.





             reply	other threads:[~2009-04-20 15:08 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-20 14:32 Mike Rapoport [this message]
2009-04-20 14:56 ` [RFD] voltage/current regulator consumer interface Mark Brown
2009-04-21 12:00   ` Mike Rapoport
2009-04-21 12:55     ` Mark Brown
2009-04-21 13:54       ` Mike Rapoport
2009-04-21 13:56         ` Mark Brown
2009-04-21 14:01           ` Mike Rapoport
2009-04-21 14:14             ` Mark Brown
2009-04-22  7:57               ` Mike Rapoport
2009-04-22  8:26                 ` Mark Brown
     [not found] <ct38K-3Fq-11@gated-at.bofh.it>
2009-04-20 15:38 ` James Kosin
2009-04-21  6:07   ` Mike Rapoport
2009-04-21 13:25     ` James Kosin
2009-04-21 14:05       ` Mike Rapoport
2009-04-21 14:31         ` James Kosin
2009-04-25  8:19         ` Pavel Machek
2009-04-25  9:04           ` Mark Brown
2009-04-27 13:47             ` James Kosin
2009-04-27 14:21               ` Mark Brown
2009-04-21 14:30       ` Mark Brown
2009-04-21 10:05   ` Mark Brown
     [not found] ` <ct38K-3Fq-9@gated-at.bofh.it>
     [not found]   ` <ctmXD-1yA-3@gated-at.bofh.it>
     [not found]     ` <ctnK4-2zP-11@gated-at.bofh.it>
     [not found]       ` <ctoG9-458-7@gated-at.bofh.it>
     [not found]         ` <ctoG9-458-5@gated-at.bofh.it>
     [not found]           ` <ctoPK-4y5-5@gated-at.bofh.it>
     [not found]             ` <ctoZv-4KN-23@gated-at.bofh.it>
     [not found]               ` <ctFxn-5OC-11@gated-at.bofh.it>
     [not found]                 ` <ctG0r-6HL-31@gated-at.bofh.it>
2009-04-22 14:31                   ` James Kosin
2009-04-22 14:49                     ` Alan Cox
2009-04-22 15:00                       ` James Kosin

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=49EC8775.8060609@compulab.co.il \
    --to=mike@compulab.co.il \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lrg@slimlogic.co.uk \
    /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;
as well as URLs for NNTP newsgroup(s).