public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>,
	Liam Girdwood <lrg@ti.com>
Cc: Laxman Dewangan <ldewangan@nvidia.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: regulators: creating a regulator device for the AC/USB/BAT/charge component of a PMIC?
Date: Thu, 26 Jul 2012 12:02:31 -0600	[thread overview]
Message-ID: <50118637.9060205@wwwdotorg.org> (raw)

Mark, Liam,

A couple of the regulators I'm looking at (I guess many/most in fact)
are structured as:

Battery, AC, USB, ... -> PMIC -> main output (unregulated?)

main output -> PMIC input pins for some of the SW-controllable
regulators. This is an external connection on the board.

Should this "main output" be represented as a regulator itself?

In more graphical/concrete terms, take the TPS6586x:

        +---------------+
        |               |
AC  --> | \             |
USB --> |  |------> SYS | >---\
BAT --> | /             |     |
        |       VIN_SM0 | <---/
        |         v     |
        |       SM0 OUT | ---> other devices
        ...

... where SM0 is one of the regulators the driver already exposes.

I assume SYS should be an explicit regulator device, because all the
other regulators within the PMIC can be set up to require that a supply
be specified (in the DT, a vin-sm0-supply property is mandatory for the
TPS6586x driver), so some regulator object must exist and be provided as
the supply.

The alternative would be to this would be to ignore this aspect of the
PMIC, and just create a standalone fixed regulator to act as the supply
for the SM0 regulator. However, this doesn't seem like an accurate model
of the HW.

However, some of the regulators in the TPS6586x at least are fed
directly from the SYS output by an internal connection within the PMIC
(e.g. LDO5). Currently, the driver sets up these regulators as having no
supply, which seems wrong too. Presumably the PMIC driver should
internally hook up its SYS as LDO5's supply without needing any platform
data or DT ldo5-supply property to do this?

What are your thoughts here?

             reply	other threads:[~2012-07-26 18:02 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-26 18:02 Stephen Warren [this message]
2012-07-26 21:01 ` regulators: creating a regulator device for the AC/USB/BAT/charge component of a PMIC? 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=50118637.9060205@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=ldewangan@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lrg@ti.com \
    /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