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

["Rafael J. Wysocki" <rjw@rjwysocki.net>]

On Monday, May 05, 2014 07:41:04 PM Linus Walleij wrote:
> On Sun, May 4, 2014 at 2:58 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Sunday, May 04, 2014 10:23:18 AM Olof Johansson wrote:
> 
> >> 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.
> 
> I would like to know *how* it will be made available in that case.
> 
> What I think will actually happen is this:
> 
> - Handling pin control is deemed unnecessary for the kernel in the same
> way that early reviews of the subsystem was received: "well we only set
> up this once at boot and never touch it, ideally the boot loader/ROM/BIOS
> do this and we need not care"
> 
> - Further down the road a "uh oh" moment - we *need* to screw around
> with pin control - usually due to firmware bugs and power savings - "we
> only need to augment this or these pins a little bit here ..."
> 
> - Ugliness threatens to invade, pin control subsystem maintainer get
> angry.
> 
> The thing is: with things like BayTrail I already *know* the pin control
> registers are there, they are just not implemented any handling of.
> I know very well how much the HW implementers think that a kernel
> "should never touch" these registers, and I know it will invariably happen
> sooner or later but like to be proven wrong.

First of all, I have a little influence on people who decide what to expose
and how.

That said, my personal intention is to work towards exposing things that ACPI
has no support for in such a way that the existing code in the kernel can use
them with as few modifications as reasonably possible.

That doesn't mean that we can switch x86 to over DTs (that currently is not an
option for various reasons, not necessarily techical), but we may be able to put
DT-style information that the current code expects to be there into the ACPI
tables.  And if that doesn't happen, for example because vendors don't choose
to do that in their firmware, we still can make it possible to read that
information from an ACPI definition block supplied along with the kernel
(kind of like a dts) and add it to the ACPI namespace during initialization. 

Thanks!

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