LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>,
	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" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>
Subject: Re: [PATCH 4/4] regulator: qcom: Rework to single platform device
Date: Thu, 5 Mar 2015 00:56:14 +0000	[thread overview]
Message-ID: <20150305005614.GC21293@sirena.org.uk> (raw)
In-Reply-To: <20150304235146.GP26334@sonymobile.com>

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

On Wed, Mar 04, 2015 at 03:51:46PM -0800, Bjorn Andersson wrote:

> I took a stab at implementing EPROBE_DEFER within qcom_rpm-regulator,
> but as it's a mixture of internal and external dependencies (e.g.
> <&pm8921_s4> vs <&pm8921_mpp 7>) this became quite messy. I started
> looking at using the dt dependencies sort and iterate over the entries
> in a way that adheres to their dependencies, but that's also a lot of
> code.

This is why I don't like trying to open code in subsystems, it's too
much work.

> So I think you're right, we should be able to alter the supply lookup
> code to defer the EPROBE_DEFER until we actually need the supply to be
> there; e.g. attempt to map supplies when an external consumer request
> the regulator.
> Some care needs to be taken with regards to e.g. always-on regulators.

I'm not sure why always on regulators would need special casing here?
Enabling is orthogonal to supply mapping.

Like I said in reply to Stephen's mail I'm more worried about
discoverability of problems with this approach and with interactions
with dependencies on other subsystems (mainly GPIOs).  Thinking about it
some more the other subsystems will probably sort themselves out but the
diagnosics are an issue.

I do like the idea of a general mechanism for registering dependency
resources and deferring completion until they're ready more - I'm not
sure it's even that much more work, especially if the first cut only
handles regulators as a dependency...  that feels like attacking the
right problem, there's other things people are raising with deferred
probe like your complaint about logging.

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

  reply	other threads:[~2015-03-05  0:56 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 [this message]
2015-03-05  0:30     ` Mark Brown
2015-03-05  1:46       ` Stephen Boyd
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=20150305005614.GC21293@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=agross@codeaurora.org \
    --cc=bjorn.andersson@sonymobile.com \
    --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=sboyd@codeaurora.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).