linux-embedded.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bill Gatliff <bgat@billgatliff.com>
To: linux-embedded@vger.kernel.org
Subject: Expose regulator:set_consumer_device_supply()?
Date: Mon, 25 Apr 2011 21:16:55 -0500	[thread overview]
Message-ID: <BANLkTi=dCHXEtv+=+sRaDp_Pt3zQy5o7ug@mail.gmail.com> (raw)

Guys:


I have been looking at incorporating use of the voltage regulator
framework into one of my platforms, and have come across a problem
that I'm not quite sure how to solve.

In a nutshell, I have a lot of i2c chips, each of which is powered by
its own voltage regulator.  Among other things, I'm trying to write
the i2c drivers so that they are as platform-agnostic as possible,
because I intend for these drivers to be reused on future platforms
with different voltage regulator layouts.  On future platforms
regulators might be shared with multiple i2c chips, for example.

What I'm hoping for is i2c driver code that asks for a regulator based
on the name of the pin to which the regulator is connected.  So
instead of doing this:

i2c_chip_probe(i2c_client *this, ...)
{
...
   /* request the name of a regulator that will change
    * when the platform changes; ugh */
   reg = regulator_get(NULL, "VREG_U11");
...
}

... I can do this:

i2c_chip_probe(i2c_client *this, ...)
{
...
   /* ask for the regulator connected to our VDD pin */
   reg = regulator_get(this, "VDD");
...
}

The problem with i2c devices is that if you register them with
i2c_register_board_info(), you don't have a device pointer that you
can associate a regulator with.  So you have to register the regulator
after the i2c chip gets registered, which means doing it in the i2c
chip's probe method.  Ugly, and it won't work when regulators are
shared between devices.

A much cleaner way might be to pass a struct regulator_dev pointer in
the i2c chip's platform data, and then use something similar to
set_consumer_device_supply() to add the i2c chip's "VDD" pin as a
consumer of the regulator.  Or maybe that function exactly.

Any reason why we couldn't expose set_consumer_device_supply(), so
that I can add a device as a regulator consumer after a regulator is
already registered?


Curious,


b.g.
-- 
Bill Gatliff
bgat@billgatliff.com

             reply	other threads:[~2011-04-26  2:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-26  2:16 Bill Gatliff [this message]
2011-04-26  2:25 ` Expose regulator:set_consumer_device_supply()? Bill Gatliff
2011-04-26  8:34   ` Mark Brown
2011-04-26  8:33 ` Mark Brown
2011-04-26 15:33   ` Bill Gatliff
2011-04-26 16:15     ` Mark Brown
2011-04-26 21:15       ` Bill Gatliff

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='BANLkTi=dCHXEtv+=+sRaDp_Pt3zQy5o7ug@mail.gmail.com' \
    --to=bgat@billgatliff.com \
    --cc=linux-embedded@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).