Message-ID: <20170616095917.GB3942@vireshk-i7>
Date:   Fri, 16 Jun 2017 15:29:17 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Mark Brown <broonie@...nel.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 14-06-17, 18:13, Mark Brown wrote:
> On Mon, May 15, 2017 at 04:17:13PM +0530, Viresh Kumar wrote:

> > > 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.

Right and this is where we need to start with for sure.

> > > 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.

Yes, but there can be weird dependencies between different components that want
to interact. For example a supply shared between LCD and I2C controller (Not
sure if such configurations are there in any of the hardware we have), where the
same i2c controller is used to access the LCD controller's registers. Both are
enabled at boot and the supply is configured to satisfy both. If the voltage
requirements of the I2C controller are below that of LCD, then we can't decide
on which one to probe first. We can't probe LCD first as its bus isn't active
and if we probe I2C first, then it may take the supply down to a level that
isn't acceptable for the LCD (which was on from boot).

> > - 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

I haven't thought about it earlier, but yeah you are absolutely right here. We
just can't force something like this on the user.

> 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.

Right. Where do you suggest such user-specific configuration should be present?
I hope userspace as we want different users (that want to use LCD vs doesn't
want to use LCD) to use the same kernel image?

> > 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.

Are we talking about writing a new framework here which can take care of the
constraints (which can support any resource type) set by the bootloader until
the time:

- the device get probed by its driver
- userspace overrides the constraint

Did I misunderstood your comment ?

Thanks for your feedback Mark.

-- 
viresh

Powered by blists - more mailing lists