All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: David Collins <collinsd@codeaurora.org>
Cc: Rajendra Nayak <rnayak@ti.com>, Liam Girdwood <lrg@ti.com>,
	linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: Supporting non-device tree consumers with device tree regulator drivers
Date: Tue, 5 Jun 2012 17:22:14 +0100	[thread overview]
Message-ID: <20120605162214.GA14958@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4FCE30D6.7060102@codeaurora.org>

[-- Attachment #1: Type: text/plain, Size: 1328 bytes --]

On Tue, Jun 05, 2012 at 09:16:22AM -0700, David Collins wrote:

>  Therefore, we are left with a situation currently where some regulator
> consumer drivers are being probed via device tree and some are being
> probed via board file devices within a single platform.  If the regulator
> driver supporting the consumer drivers is converted to use device tree and
> probed via device tree, then the non-device tree consumer drivers will not
> be able to make use of the regulator devices.

This isn't something anyone else seems to be running into - most of the
world is converting entire boards to device tree in one fell swoop and
sticking with normal style until that works.

> Would it be possible to add a new binding that is handled inside of
> of_get_regulator_init_data() or of_get_regulation_constraints() that
> provides a means to directly specify regulator_init_data.consumer_supplies
> entries?  Is there some other mechanism that could be used instead to
> handle the mapping?

> One potentially binding could be:
> regulator-consumer-supplies = "supply_name1", "device_name1",
> "supply_name2", "device_name2", ...

Well, we certainly shouldn't be putting this in the device tree as that
rather defeats the point...  Some sort of auxdata style thing would be
possible I guess but I'm not sure it's worth bothering.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: Supporting non-device tree consumers with device tree regulator drivers
Date: Tue, 5 Jun 2012 17:22:14 +0100	[thread overview]
Message-ID: <20120605162214.GA14958@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4FCE30D6.7060102@codeaurora.org>

On Tue, Jun 05, 2012 at 09:16:22AM -0700, David Collins wrote:

>  Therefore, we are left with a situation currently where some regulator
> consumer drivers are being probed via device tree and some are being
> probed via board file devices within a single platform.  If the regulator
> driver supporting the consumer drivers is converted to use device tree and
> probed via device tree, then the non-device tree consumer drivers will not
> be able to make use of the regulator devices.

This isn't something anyone else seems to be running into - most of the
world is converting entire boards to device tree in one fell swoop and
sticking with normal style until that works.

> Would it be possible to add a new binding that is handled inside of
> of_get_regulator_init_data() or of_get_regulation_constraints() that
> provides a means to directly specify regulator_init_data.consumer_supplies
> entries?  Is there some other mechanism that could be used instead to
> handle the mapping?

> One potentially binding could be:
> regulator-consumer-supplies = "supply_name1", "device_name1",
> "supply_name2", "device_name2", ...

Well, we certainly shouldn't be putting this in the device tree as that
rather defeats the point...  Some sort of auxdata style thing would be
possible I guess but I'm not sure it's worth bothering.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120605/866883f0/attachment.sig>

  reply	other threads:[~2012-06-05 16:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-05 16:16 Supporting non-device tree consumers with device tree regulator drivers David Collins
2012-06-05 16:16 ` David Collins
2012-06-05 16:22 ` Mark Brown [this message]
2012-06-05 16:22   ` Mark Brown
2012-06-06  5:08 ` Rajendra Nayak
2012-06-06  5:08   ` Rajendra Nayak
2012-06-06 20:28   ` David Brown
2012-06-06 20:28     ` David 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=20120605162214.GA14958@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=collinsd@codeaurora.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lrg@ti.com \
    --cc=rnayak@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.