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