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: Wed, 11 Feb 2015 09:21:32 -0800 [thread overview]
Message-ID: <54DB8F9C.1070104@sonymobile.com> (raw)
In-Reply-To: <54D51C5D.7050708@sonymobile.com>
On 02/06/2015 11:56 AM, Tim Bird wrote:
>
>
> 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.
Mark,
Just to follow up on this, I got things working with the current code
to my satisfaction. I ended up just punting on having multiple
regulators come from the charger block. Instead I expose a single regulator
from the charger driver, and just put all regulator attributes, including
the supply reference, directly in the charger DT block.
And I gave the charger block a label I could reference by phandle in the USB code.
I wanted to describe the difficulties I had, just for your
consideration. Maybe something can be done (either in doc or in
code), to help others avoid my pain.
My problem was in assuming that I could have a regulator
with dev.of_node different from config.of_node.
The definition of of_get_regulator_init_data() implies that this
is OK, because it accepts both a struct device and a struct device_node.
Also, when registering a regulator, you can pass a different
of_node in config (struct regulator_config) than the one in dev
(struct device)
However, this has problems in the current code, as the test in
regulator_dev_lookup requires that the device_node found by of_get_regulator()
match the dev.of_node in the regulator in the regulator list.
See this code in regulator_dev_lookup():
node = of_get_regulator(dev, NULL, supply);
if (node) {
list_for_each_entry(r, ®ulator_list, list)
if (r->dev.parent &&
node == r->dev.of_node)
return r;
It took me a while to figure this out, because a regulator defined
with dev.of_node != config.of_node worked fine, when accessed
directly by name (not using a supply-name). I only had problems
when I accessed the regulator using the "-supply" indirection technique
in DT.
In other words, using my previous DT configuration, I could do this:
reg = regulator_get(dev, "chg_otg");
and everything would work fine, but if I did this:
(in dt) vbus-supply = <&chg_otg>;
reg = regulator_get(dev, "vbus");
would not work. (And using the "-supply" indirection
in DT worked for other regulators).
Anyway, this caused me some confusion. If it's required to
have dev.of_node == config.of_node, than maybe this field should
be removed from struct regulator_config, and a separate device_node
arg not be passed to of_get_regulator_init_data().
Just my 2 cents.
Thanks,
-- Tim
next prev parent reply other threads:[~2015-02-11 17:21 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
2015-02-11 17:21 ` Tim Bird [this message]
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=54DB8F9C.1070104@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