From: Tim Bird <tim.bird@sonymobile.com>
To: "Mark Brown" <broonie@kernel.org>,
"\"Andersson, Björn\"" <Bjorn.Andersson@sonymobile.com>
Cc: "lgirdwood@gmail.com" <lgirdwood@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] regulator: Support different config and dev of_nodes in regulator_register
Date: Fri, 6 Feb 2015 11:56:13 -0800 [thread overview]
Message-ID: <54D51C5D.7050708@sonymobile.com> (raw)
In-Reply-To: <20150206114953.GT21293@sirena.org.uk>
On 02/06/2015 03:49 AM, Mark Brown wrote:
> On Thu, Feb 05, 2015 at 04:52:40PM -0800, Bjorn Andersson wrote:
>> On Thu 05 Feb 16:32 PST 2015, Mark Brown wrote:
>>> On Thu, Feb 05, 2015 at 02:08:54PM -0800, Bjorn Andersson wrote:
>
>>>> However this only works for the non-supply regulator properties - and
>>>> this is where Tim's patch is trying to sort out.
>
>>> No, this works completely fine for supply properties - to repeat what I
>>> said in reply to the original patch the supply is a supply to the chip
>>> not to an individual IP on the chip.
>
>> It does make some sense to consider the vbus-supply being connected to
>> the block, rather than directly to the vbus-switch. So it would work for
>> Tim's use case.
>
> Like I say if we do that then we don't have consistency in how we map a
> schematic into a DT binding - you have to dig into the binding of each
> device and figure out if the supply is viewed as being for blocks or for
> the chip as a whole and we've got the potential for problems in the
> binding if we figure out that a supply is actually used by other blocks
> later on and don't want to break existing DTs.
OK - the light bulb finally went on for me on this one.
So a chip can have multiple supplies (I saw examples of this
poking around in other source), and the details of
internal routing in the chip don't have to be expressed in
DT at all (in fact shouldn't, for the reason you mention).
Thanks - I will implement along these lines.
-- Tim
next prev parent reply other threads:[~2015-02-06 19:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-04 23:19 [PATCH] regulator: Support different config and dev of_nodes in regulator_register Tim Bird
2015-02-05 1:59 ` Mark Brown
2015-02-05 17:33 ` Tim Bird
2015-02-05 17:43 ` Mark Brown
2015-02-05 18:37 ` Tim Bird
2015-02-05 19:27 ` Mark Brown
2015-02-05 22:08 ` Bjorn Andersson
2015-02-06 0:32 ` Mark Brown
2015-02-06 0:52 ` Bjorn Andersson
2015-02-06 11:49 ` Mark Brown
2015-02-06 19:56 ` Tim Bird [this message]
2015-02-11 17:21 ` Tim Bird
2015-02-12 2:32 ` 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=54D51C5D.7050708@sonymobile.com \
--to=tim.bird@sonymobile.com \
--cc=Bjorn.Andersson@sonymobile.com \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@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