From: Torsten Duwe <duwe@lst.de>
To: Mark Brown <broonie@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] regulator: Defer init completion for a while after late_initcall
Date: Mon, 18 Nov 2019 17:41:01 +0100 [thread overview]
Message-ID: <20191118164101.GA7894@lst.de> (raw)
In-Reply-To: <20191118124654.GD9761@sirena.org.uk>
On Mon, Nov 18, 2019 at 12:46:54PM +0000, Mark Brown wrote:
> On Sat, Nov 16, 2019 at 01:52:33PM +0100, Torsten Duwe wrote:
> > On Wed, 4 Sep 2019 13:42:50 +0100 Mark Brown <broonie@kernel.org> wrote:
>
> > But much later on
>
> > [ 38.248573] dcdc4: disabling
> > [ 38.268493] vcc-pd: disabling
> > [ 38.288446] vdd-edp: disabling
>
> > screen goes dark and stays dark. Use count of the regulators is 0. I guess
> > this is because the driver code had been returned the dummy instead?
>
> This is not new behaviour, all this change did was delay this. We've
> been powering off unused regulators for a bit over a decade.
For me, this appeared first after upgrading from from 5.3.0-rc1 to 5.4.0-rc6.
I guess the late initcall was executed before the regulator driver module got
loaded? And now, with the 30s delay, the regulator driver is finally there?
Would that explain it?
> We power off regulators which aren't enabled by any driver and where we
> have permission from the constraints to change the state. If the
> regulator can't be powered off then it should be flagged as always-on in
> constraints, if a driver needs it the driver should be enabling the
> regulator.
How exactly? I have been looking for deficiencies in the driver, but found
devm_regulator_get() should actually do the right thing (use_count++). Is
that correct, or am I missing something?
> I don't folow what you're saying about probe deferral here at all,
> sorry.
I was worried about the regulator core handing out refs to the dummy
regulator when the requesting driver wants to change the voltages next.
I concluded the requesting device driver would have to wait until the real
regulator driver was registered. But either this somehow works or my eDP
bridge is still powered on correctly from U-Boot. What does the warning
"... using dummy regulator" mean for the caller of regulator_get()?
AFAICS the caller is then stuck with a reference to the dummy, correct?
Any hints welcome,
Torsten
next prev parent reply other threads:[~2019-11-18 16:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-04 12:42 [PATCH] regulator: Defer init completion for a while after late_initcall Mark Brown
2019-09-04 17:53 ` Applied "regulator: Defer init completion for a while after late_initcall" to the regulator tree Mark Brown
2019-11-16 12:52 ` [PATCH] regulator: Defer init completion for a while after late_initcall Torsten Duwe
2019-11-18 12:46 ` Mark Brown
2019-11-18 16:41 ` Torsten Duwe [this message]
2019-11-18 16:56 ` Mark Brown
2019-11-18 19:40 ` Torsten Duwe
2019-11-18 20:29 ` Mark Brown
2019-11-30 15:27 ` Torsten Duwe
2019-12-01 23:49 ` 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=20191118164101.GA7894@lst.de \
--to=duwe@lst.de \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@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