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

[Olof Johansson <olof@lixom.net>]

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:
> > Hi Rafael,
> 
> Hi,
> 
> > On Sat, May 03, 2014 at 01:05:21AM +0100, Rafael J. Wysocki wrote:
> > > On Friday, May 02, 2014 02:42:07 PM Olof Johansson wrote:
> > > > I labelled this as a tech topic. Feel free to upgrade it to a workshop
> > > > or relabel it if needed. Base set of people I'd like to see involved
> > > > are:
> > > > 
> > > > * Darren Hart, who is doing things to make ACPI more DT-like for
> > > > embedded use cases.
> > > > * Rafael Wysocki, who also has had some ideas on how to make the
> > > > models fit together.
> > > > * Grant Likely, since he's in the intersection as well.
> > > > * Greg K-H would be much appreciated as well, since he'd have to deal
> > > > with some of the resulting mess.
> > > > * Dave Woodhouse would also be good to have there.
> > 
> > BTW, that's a topic of high interest to me as well (as arm64 maintainer
> > and lots of ACPI patches coming my way ;)).
> 
> Sure. :-)
> 
> > > > All solutions above have trade-offs, and neither is an obvious choice.
> > > > We could likely spend between now and KS arguing this every day on the
> > > > lists if we wanted to. Getting the people into the same room for a
> > > > couple of hours is likely to be a much better way to resolve it.
> > > 
> > > 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?

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

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


-Olof