lkml.org 
[lkml]   [2013]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ACPI vs Device Tree - moving forward
On Tue, Aug 20, 2013 at 01:51:03PM -0700, Darren Hart wrote:

> It seems to me that the only way to end up in a situation where the data
> is reused by other OSes, is to go through a standards body. What about
> attempting to standardize the _DSM method? I suppose the challenge then
> is how do we standardize arbitrary data (which, of course, is an
> oxymoron)...

Right. We could certainly spec the DT bindings that currently exist, but
the obvious pushback is that large chunks of it *are* already in ACPI -
a _PS0 method (which is ACPI for "Power up the device") that toggles a
GPIO pin, and then provides a different GPIO pin in the DT data, which
would we believe?

> The interesting thing about this to me is that many of these devices are
> added after-the-fact (as add-on boards, for example). With the
> MinnowBoard we are looking to provide this configuration data in an
> EEPROM. Would it make sense for the device manufacturer (rather than the
> base-board manufacturer) to define the key-value pairs for their
> hardware?

Yes, hardware information that's on add-in boards should probably be
provided by the add-in board if it carries a ROM. This is trivial on
UEFI systems - you just need a UEFI driver for the board that can
construct an appropriate SSDT. It's more of a problem for non-UEFI ACPI
systems.

> Sadly, I will not be in New Orleans and am unlikely to receive a Kernel
> Summit invite, but I am planning be in Edinburgh and would like the
> opportunity to participate in this discussion.

I'm not planning on being at kernel summit this year, so I think we'll
try to arrange something around that time but outside the event.

--
Matthew Garrett | mjg59@srcf.ucam.org


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