lkml.org 
[lkml]   [2013]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: ACPI vs Device Tree - moving forward
Date
On Thursday, August 22, 2013 12:39:42 AM Matthew Garrett wrote:
> On Thu, Aug 22, 2013 at 01:11:14AM +0200, Rafael J. Wysocki wrote:
>
> > Moreover, even if we are able to instruct everyone interested how to create
> > the requisite ACPI tables, there is the little problem of shipping them
> > somehow so that they actually can be used by the kernel that needs to be
> > addressed too.
>
> I think the expectation in the ACPI ecosystem has to be that devices
> ship their own ACPI tables. I can't see any benefit in using ACPI if the
> aim is to just carry on shipping files with the kernel or install media
> - in that case, just use DT.

And now the practice appears to be that vendors actually ship some ACPI
tables with their systems, but those ACPI tables do not contain information
needed to enumerate all devices. On the other hand, it is known what the
DT bindings for the missing part should be. How can we address this?

Next, say we have a driver written with DT bindings in mind and there's
an ACPI-based system with identical hardware, although wired up slightly
differently. Say that all of the information needed by that driver is
there in the ACPI tables (Q: How the vendor is supposed to know what
information the driver expects?). Who is supposed to take care of updating
the driver to be able to use ACPI in addition to DTs?

I don't honestly think that the "ask vendors to ship their systems with correct
ACPI tables" approach will take us anywhere.

Thanks,
Rafael


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


\
 
 \ /
  Last update: 2013-08-22 02:21    [W:0.071 / U:1.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site