[Ksummit-discuss] [TECH TOPIC] Driver model/resources, ACPI, DT, etc (sigh)

[Rafael J. Wysocki]

On Sunday, May 04, 2014 10:23:18 AM Olof Johansson wrote:
> On Sun, May 04, 2014 at 02:19:55PM +0200, Rafael J. Wysocki wrote:
> > On Sunday, May 04, 2014 11:56:12 AM Catalin Marinas wrote:

[cut]

> > > > For what it's worth, we are working on extending ACPI to allow DT-style
> > > > information to be included into ACPI tables.
> > > 
> > > That's good as long as it's covered by some future ACPI spec.
> > 
> > There are three levels of this.  First, we need an ACPI configuration object
> > to put the information into and getting this part into the spec is one of
> > the goals.  Second, the format of the information has to be specified and
> > that will probably require an auxiliary document the creation of which is
> > the next goal.  Finally, we need a specification of the DT bindings for the
> > IP blocks in question, but that's necessary for entirely DT-based firmware too.
> 
> Some of these things are simple, and some of them can get really really messy:
> 
> How are you anticipating handling power management? On x86, will you need to be
> able to handle controlling regulators and clocks through common frameworks? If
> so, do you have any proposed solutions for how to handle references to those
> since firmware usually keeps ownership of those hardware blocks in your
> environments?

There is no one simple answer here I'm afraid.

First, there is firmware and there are ACPI tables.  Technically, the ACPI tables
are provided by firware and used by the kernel.  If the kernel chooses not to use
and PM methods from the ACPI tables, it may very well decide to go for controlling
regulators and clocks directly if it knows how to do that.  [Note that the problem
arises only if the ACPI tables contain information on clocks and voltage regulators
*along* *with* ACPI PM methods for devices.]

On some platforms, however, ther is firware in addition to the ACPI tables (that
is, SMM on x86, for example) and *that* firmware may touch those things too in
which case it is better to use the ACPI methods for PM after all.

In my opinion the general rule should be that if ACPI PM methods are used, we
don't manipulate clocks and voltage regulators directly at the same time, because
that may lead to conflicts.  Moreover, the decision whether or not to use ACPI PM
methods cannot be made by individual drivers, because those methods for different
devices may not be mutually independent.  So there needs to be a way to determine
which approach to use upfront and to communicate that to all drivers.

So drivers should not refuse to work if certain PM-related controls are not
available to them and they should not blindly try to use those controls even if
they appear to be available.  If that is assured, things should work.

> Same for pin control, where we have frameworks in the kernel on ARM, but
> x86/ACPI tends to let firmware handle it all...

I would say if pin control information is made available to us by the firmware,
we can use it.  If it is not, we need to live without it.

> > > My biggest worry on the ARM(64) side is hw vendors being inventive and coming
> > > up with their own (less than standard) ACPI+DT mix.
> > 
> > That's everyone's worry so to speak.  It would be good if we could point them
> > in the right direction sooner rather than later.

Thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.