Date:   Wed, 14 Jun 2017 18:13:43 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Liam Girdwood <lgirdwood@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Nayak, Rajendra" <rnayak@...eaurora.org>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Serge Broslavsky <serge.broslavsky@...aro.org>
Subject: Re: [RFC] regulator: Shared regulators (configured by bootloader)

On Mon, May 15, 2017 at 04:17:13PM +0530, Viresh Kumar wrote:
> On 14-05-17, 18:30, Mark Brown wrote:
> > On Mon, May 08, 2017 at 03:51:02PM +0530, Viresh Kumar wrote:

> > > I am looking to solve a problem faced by some of the Qualcomm
> > > platforms and want your suggestions on how should we fix it. One of my
> > > ex-colleague tried to solve [1] this problem but that thread never
> > > concluded (and I don't really agree with the solution it offered).

> > Please engage with the feedback I offered then.  I see no point in
> > repeating myself here, I'm just going to provide the same feedback as
> > before and if I'm going to be ignored (which appears to be the case) it
> > doesn't seem like it's worth the effort.

> I didn't ignore any of that. Most of the discussions then happened around the
> solution which Pingbo tried to implement (boot-protection flag). And that had
> obvious flaws as it depended on the state of the kernel to be known
> (booting/booted). And that will never work, as you pointed out then, because of
> the way kernel works (specially with modules).

You didn't comment in any way on any of the feedback, and have indeed
taken a step back to proxy regulators which were the first thing
proposed that time as well - the dependency on the boot state came about
as a result of Pingbo trying to solve solve some of the problems with
proxy regulators.  If nothing's said and the discussion just winds
backwards it's hard to tell if that's intentional or not.

> > I think you need to be looking at some combination of getting the
> > devices you're interested in started up early and more precisely
> > describing the end result you're trying to achieve.  The issues with

Please note the above bit about describing the end result you're trying
to achieve, it's a very important part of the problem.

> > probe deferral do seem related here, it's another symptom of not really
> > making any decisions about init ordering and so sometimes making bad
> > ones.

> I don't think we should depend on the order in which the devices get added. This
> is going to break for sure.

We want to do this anyway since if it's critical that things stay alive
it's also likely going to be important that they become responsive as
fast as possible, and it'd have more general applications.  I rather
suspect it's going to work a lot better in practice than you seem to be
imagining and it's less problematic for both systems with multiple use
cases and things like upgraded kernels with improved regulator (or clock
or power domain or whatever) support causing things to explode.

> - If the LCD kernel driver never turns up, then the regulator shall continue
>   satisfying the requirements set from the bootloader. Even if that means that
>   some devices may not get what they request for and perform badly. Someone
>   needs to fix the LCD driver and make sure it comes up.

This is a fundamental problem.  Users shouldn't have to load (or in the
worst case write) a driver for hardware they've no intention of using at
runtime just because whoever wrote the DT thought it was important, and
when people do want such behaviour they should be able to say so in
terms of the objective they want to achieve rather than having to figure
out how the hardware is wired together in order to do so.  It shouldn't
really be tied to the firmware interface at all, we have some pretty
similar goals for the displays on ACPI systems.

> I failed to find any other workable solution that anyone may have suggested in
> those email threads. Can you please point me to those (if any)?

Proxy regulators are just operating at the wrong abstraction level, take
a step back and think about the goal you're trying to achieve and design
an interface for doing that.  The user interfaces should be at the level
of the goal the user is trying to achieve rather than down in the
implementation details.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists