LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@codeaurora.org>
To: Mark Brown <broonie@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@sonymobile.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	Lee Jones <lee.jones@linaro.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Pawel Moll <pawel.moll@arm.com>, Rob Herring <robh+dt@kernel.org>,
	Andy Gross <agross@codeaurora.org>,
	Chanwoo Choi <cw00.choi@samsung.com>,
	Krzysztof Kozlowski <k.kozlowski@samsung.com>,
	Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH 4/4] regulator: qcom: Rework to single platform device
Date: Wed, 04 Mar 2015 17:46:25 -0800	[thread overview]
Message-ID: <54F7B571.7090705@codeaurora.org> (raw)
In-Reply-To: <20150305003004.GZ21293@sirena.org.uk>

On 03/04/15 16:30, Mark Brown wrote:
> On Wed, Mar 04, 2015 at 11:35:43AM -0800, Stephen Boyd wrote:
>
>> There's another problem with this of_parse_cb design. The regulator
>> framework requires supplies to be registered before consumers of the
>> supplies are registered. So when we register L23 we need to make sure
>> it's supply is already registered (S8 for example). If we used
>> of_regulator_match() we could sort the array by hand so that we always
>> register the supplies first. Or we could modify the regulator framework
>> to have a concept of "orphaned" supplies like the clock framework has so
>> that when a regulator is registered it waits until its supply is registered.
> Dependency resolution isn't anything new, I'm not sure why you think
> this is related to of_parse_cb()?  Open coding does exactly the same
> thing and the ability to have device specific properties on is not
> obviously related to dependency resolution so perhaps I'm
> misunderstanding what you're talking about...

I was just using of_parse_cb to indicate the difference from
of_regulator_match(). I could have said "between your design and my design".

>
> If you *are* talking about dependency resolution then just bulk
> registering the regulators (which we should be doing anyway) and then
> iterating the array until we stop making progress should do the trick
> for most cases, normally there's only one PMIC in play, or have people
> who care do a single struct device per regulator and then let the probe
> deferral stuff sort it out.

Yeah I think the brute force, keep trying approach will work for now if
we can't add orphan support to regulator core. I'm not aware of any
circular dependencies for these platforms.

>
> I'm a bit nervous of the idea of having orphaning without core support,
> it's not just inter regulator dependencies we need to worry about (they
> use GPIOs and so on) and there's concerns about debuggability but it is
> the kind of thing probe deferral was meant to be a cheap implementation
> of.  There was a proposal quite recently from someone at Samsung Poland
> to do something more coreish and basically split registrations in two,
> one half registering the things needed for each resource and then a
> second half which runs once the required resources are registered.
> Pushing that along might be best, it's a more general approach.  The
> component stuff Russell did has some similarities here.

Ah you're talking about the res track stuff[1]? That patchset seemed to
be doing a *lot* of different stuff where probe defer was just a part of
it. Frmo what I recall that still operates on the device level, where
here we want to be able to say that a particular regulator needs another
resource, but it's ok to register it's sibling regulator within this
device because that regulator doesn't need anything. Are you saying you
want the restrack stuff to work at the regulator level? If we went that
way we could do the same thing in the clock framework and get rid of the
orphan list and rely on the notifications from restrack to figure out
when a clock resource becomes fully available.

[1] https://lkml.org/lkml/2014/12/10/342

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


  reply	other threads:[~2015-03-05  1:46 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-03  4:25 [PATCH 0/4] Refactor Qualcomm RPM regulator to single platform_device Bjorn Andersson
2015-03-03  4:25 ` [PATCH 1/4] mfd: devicetree: bindings: Add Qualcomm RPM regulator subnodes Bjorn Andersson
2015-03-03 12:47   ` Mark Brown
2015-03-03 16:02     ` Bjorn Andersson
2015-03-05  0:33       ` Mark Brown
2015-03-03 18:53   ` Stephen Boyd
2015-03-03 21:54     ` Bjorn Andersson
2015-03-03 22:02       ` Stephen Boyd
2015-03-03 22:17         ` Bjorn Andersson
2015-03-03 23:25           ` Stephen Boyd
2015-03-03  4:25 ` [PATCH 2/4] regulator: core: Expose init_data to of_parse_cb Bjorn Andersson
2015-03-03 12:50   ` Mark Brown
2015-03-03 16:15     ` Bjorn Andersson
2015-03-05  0:42       ` Mark Brown
2015-03-03  4:25 ` [PATCH 3/4] regulator: qcom: Refactor of-parsing code Bjorn Andersson
2015-03-03 14:13   ` Mark Brown
2015-03-03 16:26     ` Bjorn Andersson
2015-03-03 18:56   ` Stephen Boyd
2015-03-03 22:07     ` Bjorn Andersson
2015-03-03  4:25 ` [PATCH 4/4] regulator: qcom: Rework to single platform device Bjorn Andersson
2015-03-03 22:09   ` Stephen Boyd
2015-03-03 22:32     ` Bjorn Andersson
2015-03-03 23:52       ` Mark Brown
2015-03-04  0:01         ` Stephen Boyd
2015-03-04  0:09           ` Mark Brown
2015-03-04 19:35   ` Stephen Boyd
2015-03-04 23:51     ` Bjorn Andersson
2015-03-05  0:56       ` Mark Brown
2015-03-05  0:30     ` Mark Brown
2015-03-05  1:46       ` Stephen Boyd [this message]
2015-03-05 10:38         ` 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=54F7B571.7090705@codeaurora.org \
    --to=sboyd@codeaurora.org \
    --cc=agross@codeaurora.org \
    --cc=bjorn.andersson@sonymobile.com \
    --cc=broonie@kernel.org \
    --cc=cw00.choi@samsung.com \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=k.kozlowski@samsung.com \
    --cc=lee.jones@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=srinivas.kandagatla@linaro.org \
    --subject='Re: [PATCH 4/4] regulator: qcom: Rework to single platform device' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).