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

On Mon, Apr 20, 2009 at 05:32:21PM +0300, Mike Rapoport wrote:

> It is the most simple and straight forward solution. However, I have several
> questions and I cannot answer them myself:

Some initial thoughts:

>   Should the driver handle single or several supplies at once?

I'd expect that it should be able to cope with that - a lot of hardware
takes multiple supplies.

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

I'd expect that if you're getting into much more than a simple enable
for the entire device it'd be getting to the point where it's worth
considering writing an actual driver for the device.  That said, it's a
fairly natural extension to support more fine grained stuff if someone
does actually end up wanting it.

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

I'd expect making them writable to be very fragile if there is an active
consumer driver - I'd expect reference counts to get lost with enable
and disable and I'd expect drivers managing voltages and currents to get
confused if their own configuration gets changed under them.  The core
already needs to arbitrate between multiple users so it seems to make
sense to have userspace represented as other users are to the core.

Being able to read back the consumer status doesn't seem unreasonable,
though.

  reply	other threads:[~2009-04-20 14:56 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-20 14:32 [RFD] voltage/current regulator consumer interface Mike Rapoport
2009-04-20 14:56 ` Mark Brown [this message]
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=20090420145627.GA5281@rakim.wolfsonmicro.main \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lrg@slimlogic.co.uk \
    --cc=mike@compulab.co.il \
    /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).