ACPI vs DT at runtime

[Arnd Bergmann]

On Tuesday 19 November 2013, David Goodenough wrote:
> On Tuesday 19 Nov 2013, Arnd Bergmann wrote:
> > On Monday 18 November 2013, David Goodenough wrote:
> > > Would it not be possible to have ACPI read the hardware configuration
> > > from the DT, and provide whatever services it wants, while also allowing
> > > the kernel to retain the DT for its hardware config?  I suppose the only
> > > thing that would be needed would be some way to mark paricular bits of
> > > hardware (I am largely thinking of the things lmsensors deals with) as
> > > being used by ACPI and being off limits to the kernel.
> > 
> > While that may be possible, I don't see what problem that solves. Nobody
> > has so far explained what problem they want to solve by using ACPI. The
> > only reason we are discussing this is Jon's statement that "everybody
> > will use it". For any specific thing you might want to do in ACPI while
> > leaving the rest in DT, I suspect there is an easier solution in using
> > just DT.
>
> It strikes me that ACPI is really two things, a provider of configuration
> information and a provider of power management services.

As the acronym says, yes ;-)

> The first of
> these is - on ARM - more or less duplicated by DT, and so rather than having 
> to go through the excercise of modifying the kernel to support both sources
> of configuration information, I am suggesting making not just the kernel
> and uboot (or whatever boot loader) use DT, but also ACPI.  So the ACPI
> module for an ARM box would not have separate config information coded
> into it, but rather would either read the DT from the same place as
> the bootloader/kernel, or act as the source of the DT for the bootloader
> /kernel.  This way the kernel does not have to be modified again, and
> can simply use DT whether ACPI is present or not.

Well, this is what Olof suggested, and it may or may not be possible,
depending on what kind of data people actually want to put into ACPI
here.

> > Since you seem to have something specific in mind, can you elaborate on
> > why you think lmsensors (or any other device you can think of) would
> > benefit from ACPI?
> Its the other way around.  lmsensors often fights with ACPI in the x86
> world for control of sensors and fans, and on x86 motherboards they do
> silly tricks like hiding I2C busses from the kernel so that ACPI can
> have sole control.  Thus lmsensors (which on x86 boxes could use a source
> of information like DT as busses like I2C provide no chip ID services) needs 
> to know which sensor chips are being used or controlled by ACPI so that it 
> does not interfere.

Ah, I see. I suppose on a server, those sensors are part of the BMC anyway
and are accessible through IPMI only, so I'd hope that wouldn't be an issue.

	Arnd