public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@sirena.org.uk>
To: Jonathan Cameron <Jonathan.Cameron@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>, Liam Girdwood <lrg@kernel.org>
Subject: Re: Regulator: Use case query (many devices need to reg their voltage requirements?)
Date: Sat, 10 Jan 2009 17:46:03 +0000	[thread overview]
Message-ID: <20090110174602.GA31525@sirena.org.uk> (raw)
In-Reply-To: <4968BE74.1070903@gmail.com>

On Sat, Jan 10, 2009 at 03:27:48PM +0000, Jonathan Cameron wrote:

> A number of different embedded system now use main boards (core etc) in
> conjunction with daughter boards.  In these cases different modules may
> be inserted to support different daughter board options from a single kernel
> (and combinations if possible).  Thus we have a situation in which the
> appropriate voltage level can only be established if the various drivers
> specify what they need. The board config may specify numerous devices
> only some of which may actually be present.

The wide range of plug in and subfit options isn't that unusual.
There's quite a few modular reference designs out there, including
designs where the power module is replacable.

When I've considered this in the context of designs I've worked on in
the past I've always thought it would be easiest to represent the plug
in modules in the device tree with the main board regulators being set
up to know only about the supplies they provide to the board.  The plug
in boards could then map how those supplies are distributed within the
boards, using virtual regulators to pass through the supplies from the
main board and being able to supply board-wide requirements for the
design.

I've not actually tried doing this so I've not had a chance to run into
any practical problems with it yet, and I'm not sure how well it maps
onto your system.

> This leads to additional complexity in numerous drivers as they have to act
> as dynamic drivers (terminology from regulator docs) even though they don't
> actually vary the voltage, merely specify what ranges they can work with.

For simple cases it's only one function call, though power requirements
often depend on other system considerations such as clock rates and
analogue design.  There will also be issues if the drivers are for chips
which have multiple software compatible variants with differing power
requirements.

> Is this the best way to handle this situation, or do people have other
> suggestions?

Does the above idea work for you?

  reply	other threads:[~2009-01-10 17:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-10 15:27 Regulator: Use case query (many devices need to reg their voltage requirements?) Jonathan Cameron
2009-01-10 17:46 ` Mark Brown [this message]
2009-01-10 18:05   ` Jonathan Cameron
2009-01-10 18:58     ` 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=20090110174602.GA31525@sirena.org.uk \
    --to=broonie@sirena.org.uk \
    --cc=Jonathan.Cameron@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lrg@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