[PATCH V4 08/12] boot_constraint: Manage deferrable constraints

[Viresh Kumar]

On 31 October 2017 at 16:20, Rob Herring <robh+dt at kernel.org> wrote:
> What is the effect on boot time? It's highly platform dependent, but
> the worst case could be pretty bad I think.

Yeah, it can increase considerably here and I have plans for that, just
that i didn't wanted to get them in the first iteration to keep things simple.

What we can (should?) do is, that the boot constraint framework can hook
into other frameworks like regulators/clk/PM, etc, so that whenever a new
clk/regulator is added to those frameworks, they check for pending
requests from boot constraint framework. If found, they can call a callback
of the boot constraint framework which will set the constraints to the resource
before anyone else gets a chance. At that point we can remove the early
defer probing support that this patch is adding. And things would be quite fast
then.

> I don't see how this handles the case you mentioned where the amba
> pclk gets disabled. It only works if the constraint device is added
> before any others, but that is done with initcall level games.

Yeah, so as I said earlier, the basic idea is that these constraints must get
set before any user driver (for constrained devices) comes up. And the
only way to do that is by making sure the constraints get added at early
initcall levels. The same is done for all the three example drivers I have
added.

The amba-pclk thing isn't a issue then, as that stuff happens only at probe
and not when the amba device is created.

--
viresh