Re: ACPI vs Device Tree - moving forward

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/23/2013 07:38 PM, Matthew Garrett wrote:
On Fri, Aug 23, 2013 at 06:47:23PM -0700, Guenter Roeck wrote:
On Sat, Aug 24, 2013 at 02:10:36AM +0100, Matthew Garrett wrote:
On Fri, Aug 23, 2013 at 05:13:45PM -0700, Guenter Roeck wrote:

Did the group conclude that the idea of FDT augmenting ACPI is not feasible ?

I think expressing FDT in ACPI is feasible, I'm just not sure it's
desirable. We'd still end up with duplicate information and no mechanism
for drivers to handle both.

Not sure I understand what you are saying. My understanding of "augment"
would be that there is ACPI information, and there is a separate FDT
(or an FDT overlay) providing additional information. There should be
no duplicate information in this model.

What happens when you have an ACPI device that contains an interrupt in
_CRS and contains a different interrupt in an embedded FDT block?


Question is: Does this work _today_ with any existing driver, where
one interrupt is served through ACPI and another as 'standard' Linux
interrupt ? If yes, it must be working, and using fdt to describe
the interrupt mapping for the non-ACPI interrupt should not make
a difference. If no, the problem does not really have anything
to do with fdt.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux