Messages in this thread | | | Date | Wed, 19 Feb 2020 00:15:35 +0000 | From | Mark Brown <> | Subject | Re: [PATCH v3 1/2] driver core: Rework logic in __driver_deferred_probe_check_state to allow EPROBE_DEFER to be returned for longer |
| |
On Tue, Feb 18, 2020 at 04:51:39PM -0600, Rob Herring wrote: > On Tue, Feb 18, 2020 at 4:07 PM John Stultz <john.stultz@linaro.org> wrote:
> > Specifically, on db845c, this change (when combined with booting > > using deferred_probe_timeout=30) allows us to set SDM_GPUCC_845, > > QCOM_CLK_RPMH and COMMON_CLK_QCOM as modules and get a working > > system, where as without it the display will fail to load.
> I would change the default for deferred_probe_timeout to 30 and then > regulator code can rely on that. Curious, why 30 sec is fine now when > you originally had 2 min? I'd just pick what you think is best. I > doubt Mark had any extensive experiments to come up with 30sec.
Sort of - I've spent a bunch of time looking at the sorts of devices where this is applicable for regulators and 30s is wildly excessive for the use case. I didn't specifically measure anything at the time I did the change though, even longer should work just as well.
That feature in the regulator framework is targetted quite narrowly at things we really don't want to glitch out during boot if we can avoid it like the display, people tend to make efforts to ensure that they come up quickly during boot anyway so we're not expecting to worry about the full boot time for bigger systems. The expectation is that most devices will cope fine with having the power turned off for a period and if the user can't see it happening then it doesn't *really* matter. [unhandled content-type:application/pgp-signature] | |