From: Jonathan Cameron <jic23@cam.ac.uk>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>,
Jean Delvare <khali@linux-fr.org>,
lm-sensors <lm-sensors@lm-sensors.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [lm-sensors] regulator: regulator_get behaviour without CONFIG_REGULATOR set
Date: Wed, 07 Apr 2010 12:24:02 +0100 [thread overview]
Message-ID: <4BBC6B52.5030908@cam.ac.uk> (raw)
In-Reply-To: <1F9C625F-0467-4C6D-B57F-2E4FCAC76031@opensource.wolfsonmicro.com>
On 04/06/10 19:19, Mark Brown wrote:
> On 6 Apr 2010, at 17:25, Jonathan Cameron <jic23@cam.ac.uk> wrote:
>
>> On 04/06/10 16:27, Liam Girdwood wrote:
>>>>
>>>>
>>>>
>>>
>>> I suppose this is something we may look into more when we have more
>>> clients.
>> Makes sense. There will probably be quite a few IIO drivers over the
>> next
>> few months doing much the same as sht15, where the voltage ref for
>> devices
>> may well be fed by a regulator. In that case, we may only offer the
>> option
>> of using an external v_ref if the regulator is available. Many
>> devices have
>> an internal regulator to provide it so typically we'll start them up
>> using that
>> and provide an interface to switch to external regulator if one is
>> available.
>> I haven't thought through exactly how this will work as yet. I'll cc
>> people in
>> when this comes up.
>
> TBH this seems like a very vanilla use case - there may be some small
> advantage to representing the internal regulator via the regulator API
> but that's about the only thing I can think might be a bit odd.
>
I wasn't thinking of representing the internal regulator using the regulator
framework (though if it is externally available I guess that would make sense
though probably only if anyone is actually using this to supply something else
- most likely case I can think of is daisy chaining multiple adc's and ensuring
they have the same reference value).
The case I'm interested in is the externally supplied voltage reference. This
typically comes off a fixed regulator or a spare regulator on a pmic.
The use case is getting this voltage (and indeed buffering it using the
same notifier approach as in sht15). This is needed to provide api compliant info
to userspace (which needs sufficient info to work out what the actual value is).
I'd imagine similar cases occur in some hwmon devices.
Basically all these uses look just like that in sht15.
Nothing new here, but there will be a number of consumers that care about changes
in voltage (rather than typically controlling it.) Hence I'm welcoming the change
just agreed upon.
Thanks,
Jonathan
next prev parent reply other threads:[~2010-04-07 11:21 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2122967437.461270223106350.JavaMail.root@mail.savoirfairelinux.com>
2010-04-02 15:47 ` regulator: regulator_get behaviour without CONFIG_REGULATOR set Jerome Oufella
2010-04-02 16:00 ` Mark Brown
2010-04-02 16:44 ` [lm-sensors] " Jean Delvare
2010-04-02 18:51 ` Mark Brown
2010-04-02 19:30 ` Jean Delvare
2010-04-02 20:45 ` Mark Brown
2010-04-03 15:37 ` Jean Delvare
2010-04-05 13:23 ` Mark Brown
2010-04-06 12:04 ` Jonathan Cameron
2010-04-06 15:27 ` Liam Girdwood
2010-04-06 16:25 ` Jonathan Cameron
2010-04-06 18:19 ` Mark Brown
2010-04-07 9:50 ` Liam Girdwood
2010-04-07 11:24 ` Jonathan Cameron [this message]
2010-04-07 11:57 ` Mark Brown
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=4BBC6B52.5030908@cam.ac.uk \
--to=jic23@cam.ac.uk \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=khali@linux-fr.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lm-sensors@lm-sensors.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