This conversation seems to have pretty much entirely ended up happening
on ksummit-discuss, which doesn't seem that useful. So let's have
another go with a wider audience (and where I don't have to sign up for
yet another mailing list...)
ACPI and DT overlap in that they both provide a mechanism for
enumerating non-enumerable devices, and both also provide a mechanism
for attaching additional configuration data to devices (which may or may
not be otherwise enumerable). There's a sufficient overlap in
functionality that at least one platform that's traditionally been
Device Tree (arm) is also adding support for ACPI - there's even
ACPI-based arm hardware on the market already.
Right now that's a problem for us. The same hardware may end up shipped
with either ACPI or DT-based firmware, and at the moment we'd need to
either write two drivers or one driver with two glue layers. This is
somewhat suboptimal.
The biggest difference between DT and ACPI is that DT is effectively a
somewhat structured mechanism for passing arbitrary data, while ACPI
tends (with exceptions) to provide standardised data. For instance, in
DT we might have:
sdhci@c8000000 {
status = "okay";
power-gpios = <&gpio TEGRA_GPIO(K, 6) GPIO_ACTIVE_HIGH>;
bus-width = <4>;
keep-power-in-suspend;
};
In ACPI the normal way to handle this would be to have a GPIO operation
region that listed the GPIOs:
OperationRegion(GPO1, GeneralPurposeIO, 0, 1)
Field(GP01, ByteAcc, NoLock, Preserve)
{
Connection (GpioIo(Exclusive, PullUp,,,,,)
TG06, 1
}
And then an ACPI device:
Device (\_SB.SDHC)
{
Method (_PS0, 0, NotSerialized)
{
Store (1, TG06)
}
Method (_PS3, 0, NotSerialized)
{
Store (0, TG06)
}
}
with the ACPI core then executing these methods whenever a device is
powered up or down.
How can we unify these two different representations? The only terribly
plausible way of doing so seems to be to push that out to a helper
function and then have it handled as part of device runtime power
management, and just have the driver make pm_runtime_get() and _put()
calls.
So we can theoretically handle cases like power lines without /too/ much
trouble, while representing the same thing in either ACPI or DT. But we
have plenty of other data - in the case of SDHCI alone, there's the bus
width and potentially card detect and write protect gpio lines. These
can easily be represented in ACPI, but not in a terribly generic way. We
could easily add new functions to retrieve this information, but doing
this through the standards body is likely to prove tedious, especially
when new hardware types appear and we want to be able to ship support
pretty much immediately.
The other choice is to ignore most of the existing ACPI functionality
and just use it as a mechanism for providing additional metadata. Apple
already do this using the _DSM methods:
Method (_DSM, 4, NotSerialized)
{
Store (Package (0x07)
{
"refnum",
0x00,
"address",
0x39,
"device-id",
0x0cc8,
Buffer (0x01)
{
0x00
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
where the DTGP() method verifies that the caller passed in an
appropriate UUID and then hands back this buffer.
Putting all our existing DT metadata in there would be straightforward,
but we would then effectively just be using ACPI to repackage DT -
drivers would continue to make DT-specific calls in order to obtain the
information they need.
This seems like the least-effort approach, but it doesn't really solve
much. Any other OS on the same hardware is unlikely to use the DT data,
and if someone wants to run Linux on hardware that was intended for
another OS they're unlikely to have any DT data to use.
So while unifying this seems hugely desirable, right now it's not
incredibly obvious how we can actually achieve that. In some cases it's
easy to take DT information and rewrite it the ACPI way, but in others
we just don't seem to have the primitives we need for that. One approach
would be to work through the existing DT bindings documentation and see
what's missing from ACPI and work on adding it, but we'll still then
need helper functions that are able to obtain the same information from
either source.
In any case, it seems like this is something that should be discussed. A
bunch of people in the earlier discussion mentioned that they were going
to be in New Orleans, so I'd suggest that we arrange a time for
in-person discussion there. That should give us a solid basis for
further mailing list discussion, and then there'll be another
opportunity for discussion in Edinburgh.
--
Matthew Garrett | [email protected]
On Tue, 2013-08-20 at 20:26 +0100, Matthew Garrett wrote:
> This conversation seems to have pretty much entirely ended up happening
> on ksummit-discuss, which doesn't seem that useful. So let's have
> another go with a wider audience (and where I don't have to sign up for
> yet another mailing list...)
Hi Matthew,
Thanks for kicking this over where it belongs :-)
>
> ACPI and DT overlap in that they both provide a mechanism for
> enumerating non-enumerable devices, and both also provide a mechanism
> for attaching additional configuration data to devices (which may or may
> not be otherwise enumerable). There's a sufficient overlap in
> functionality that at least one platform that's traditionally been
> Device Tree (arm) is also adding support for ACPI - there's even
> ACPI-based arm hardware on the market already.
>
> Right now that's a problem for us. The same hardware may end up shipped
> with either ACPI or DT-based firmware, and at the moment we'd need to
> either write two drivers or one driver with two glue layers. This is
> somewhat suboptimal.
>
> The biggest difference between DT and ACPI is that DT is effectively a
> somewhat structured mechanism for passing arbitrary data, while ACPI
> tends (with exceptions) to provide standardised data. For instance, in
> DT we might have:
>
> sdhci@c8000000 {
> status = "okay";
> power-gpios = <&gpio TEGRA_GPIO(K, 6) GPIO_ACTIVE_HIGH>;
> bus-width = <4>;
> keep-power-in-suspend;
> };
>
> In ACPI the normal way to handle this would be to have a GPIO operation
> region that listed the GPIOs:
>
> OperationRegion(GPO1, GeneralPurposeIO, 0, 1)
> Field(GP01, ByteAcc, NoLock, Preserve)
> {
> Connection (GpioIo(Exclusive, PullUp,,,,,)
> TG06, 1
> }
>
> And then an ACPI device:
>
> Device (\_SB.SDHC)
> {
> Method (_PS0, 0, NotSerialized)
> {
> Store (1, TG06)
> }
> Method (_PS3, 0, NotSerialized)
> {
> Store (0, TG06)
> }
> }
>
> with the ACPI core then executing these methods whenever a device is
> powered up or down.
>
> How can we unify these two different representations? The only terribly
> plausible way of doing so seems to be to push that out to a helper
> function and then have it handled as part of device runtime power
> management, and just have the driver make pm_runtime_get() and _put()
> calls.
>
> So we can theoretically handle cases like power lines without /too/ much
> trouble, while representing the same thing in either ACPI or DT. But we
> have plenty of other data - in the case of SDHCI alone, there's the bus
> width and potentially card detect and write protect gpio lines. These
> can easily be represented in ACPI, but not in a terribly generic way. We
> could easily add new functions to retrieve this information, but doing
> this through the standards body is likely to prove tedious, especially
> when new hardware types appear and we want to be able to ship support
> pretty much immediately.
>
> The other choice is to ignore most of the existing ACPI functionality
> and just use it as a mechanism for providing additional metadata. Apple
> already do this using the _DSM methods:
>
> Method (_DSM, 4, NotSerialized)
> {
> Store (Package (0x07)
> {
> "refnum",
> 0x00,
> "address",
> 0x39,
> "device-id",
> 0x0cc8,
> Buffer (0x01)
> {
> 0x00
> }
> }, Local0)
> DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
> Return (Local0)
> }
>
> where the DTGP() method verifies that the caller passed in an
> appropriate UUID and then hands back this buffer.
>
> Putting all our existing DT metadata in there would be straightforward,
> but we would then effectively just be using ACPI to repackage DT -
> drivers would continue to make DT-specific calls in order to obtain the
> information they need.
>
> This seems like the least-effort approach, but it doesn't really solve
> much. Any other OS on the same hardware is unlikely to use the DT data,
> and if someone wants to run Linux on hardware that was intended for
> another OS they're unlikely to have any DT data to use.
>
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)...
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?
> So while unifying this seems hugely desirable, right now it's not
> incredibly obvious how we can actually achieve that. In some cases it's
> easy to take DT information and rewrite it the ACPI way, but in others
> we just don't seem to have the primitives we need for that. One approach
> would be to work through the existing DT bindings documentation and see
> what's missing from ACPI and work on adding it, but we'll still then
> need helper functions that are able to obtain the same information from
> either source.
>
> In any case, it seems like this is something that should be discussed. A
> bunch of people in the earlier discussion mentioned that they were going
> to be in New Orleans, so I'd suggest that we arrange a time for
> in-person discussion there. That should give us a solid basis for
> further mailing list discussion, and then there'll be another
> opportunity for discussion in Edinburgh.
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.
Thanks,
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
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 | [email protected]
On Tuesday, August 20, 2013 08:26:50 PM Matthew Garrett wrote:
> This conversation seems to have pretty much entirely ended up happening
> on ksummit-discuss, which doesn't seem that useful. So let's have
> another go with a wider audience (and where I don't have to sign up for
> yet another mailing list...)
>
> ACPI and DT overlap in that they both provide a mechanism for
> enumerating non-enumerable devices, and both also provide a mechanism
> for attaching additional configuration data to devices (which may or may
> not be otherwise enumerable). There's a sufficient overlap in
> functionality that at least one platform that's traditionally been
> Device Tree (arm) is also adding support for ACPI - there's even
> ACPI-based arm hardware on the market already.
>
> Right now that's a problem for us. The same hardware may end up shipped
> with either ACPI or DT-based firmware, and at the moment we'd need to
> either write two drivers or one driver with two glue layers. This is
> somewhat suboptimal.
There's one more problematic case which is that some systems ship with ACPI
tables that don't contain all of the information necessary to enumerate
hardware appropriately and it's difficult, if not impossible, to convince
the vendors of those systems to fix their ACPI firmware after the fact.
However, at least in some cases there are well defined DT bindings for the
hardware in question.
> The biggest difference between DT and ACPI is that DT is effectively a
> somewhat structured mechanism for passing arbitrary data, while ACPI
> tends (with exceptions) to provide standardised data. For instance, in
> DT we might have:
>
> sdhci@c8000000 {
> status = "okay";
> power-gpios = <&gpio TEGRA_GPIO(K, 6) GPIO_ACTIVE_HIGH>;
> bus-width = <4>;
> keep-power-in-suspend;
> };
>
> In ACPI the normal way to handle this would be to have a GPIO operation
> region that listed the GPIOs:
>
> OperationRegion(GPO1, GeneralPurposeIO, 0, 1)
> Field(GP01, ByteAcc, NoLock, Preserve)
> {
> Connection (GpioIo(Exclusive, PullUp,,,,,)
> TG06, 1
> }
>
> And then an ACPI device:
>
> Device (\_SB.SDHC)
> {
> Method (_PS0, 0, NotSerialized)
> {
> Store (1, TG06)
> }
> Method (_PS3, 0, NotSerialized)
> {
> Store (0, TG06)
> }
> }
>
> with the ACPI core then executing these methods whenever a device is
> powered up or down.
>
> How can we unify these two different representations? The only terribly
> plausible way of doing so seems to be to push that out to a helper
> function and then have it handled as part of device runtime power
> management, and just have the driver make pm_runtime_get() and _put()
> calls.
>
> So we can theoretically handle cases like power lines without /too/ much
> trouble, while representing the same thing in either ACPI or DT. But we
> have plenty of other data - in the case of SDHCI alone, there's the bus
> width and potentially card detect and write protect gpio lines. These
> can easily be represented in ACPI, but not in a terribly generic way. We
> could easily add new functions to retrieve this information, but doing
> this through the standards body is likely to prove tedious, especially
> when new hardware types appear and we want to be able to ship support
> pretty much immediately.
>
> The other choice is to ignore most of the existing ACPI functionality
> and just use it as a mechanism for providing additional metadata. Apple
> already do this using the _DSM methods:
>
> Method (_DSM, 4, NotSerialized)
> {
> Store (Package (0x07)
> {
> "refnum",
> 0x00,
> "address",
> 0x39,
> "device-id",
> 0x0cc8,
> Buffer (0x01)
> {
> 0x00
> }
> }, Local0)
> DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
> Return (Local0)
> }
>
> where the DTGP() method verifies that the caller passed in an
> appropriate UUID and then hands back this buffer.
>
> Putting all our existing DT metadata in there would be straightforward,
> but we would then effectively just be using ACPI to repackage DT -
> drivers would continue to make DT-specific calls in order to obtain the
> information they need.
>
> This seems like the least-effort approach, but it doesn't really solve
> much. Any other OS on the same hardware is unlikely to use the DT data,
> and if someone wants to run Linux on hardware that was intended for
> another OS they're unlikely to have any DT data to use.
>
> So while unifying this seems hugely desirable, right now it's not
> incredibly obvious how we can actually achieve that. In some cases it's
> easy to take DT information and rewrite it the ACPI way, but in others
> we just don't seem to have the primitives we need for that. One approach
> would be to work through the existing DT bindings documentation and see
> what's missing from ACPI and work on adding it, but we'll still then
> need helper functions that are able to obtain the same information from
> either source.
>
> In any case, it seems like this is something that should be discussed. A
> bunch of people in the earlier discussion mentioned that they were going
> to be in New Orleans, so I'd suggest that we arrange a time for
> in-person discussion there. That should give us a solid basis for
> further mailing list discussion, and then there'll be another
> opportunity for discussion in Edinburgh.
There is a time slot reserved for the second part of the ACPI/PM+PCI uconf
that may be used for this purpose if it's suitable for all of the interested
people. It is scheduled at 2 PM on Thursday, September 19 at the moment
(concurrently with the containers uconf).
Thanks,
Rafael
On Tuesday, August 20, 2013 09:57:13 PM Matthew Garrett wrote:
> 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.
Well, I'm attending the KS, however, so I'd prefer them not to conflict
with each other if possible.
Thanks,
Rafael
On Tue, 2013-08-20 at 21:57 +0100, Matthew Garrett wrote:
> 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?
Right, understood.
> > 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.
For development, those could pass the SSDT in via the initramfs
mechanism for Linux, but clearly a more integral solution would be
preferred.
>
> > 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.
>
Works for me :-) Please keep me on the list for that. That will become
my primary motivator for going.
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
On Tue, Aug 20, 2013 at 09:57:13PM +0100, Matthew Garrett wrote:
> 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.
>
For my part I'll be in New Orleans but not in Edinburgh. Meeting in Edinburgh
for the DT/ACPI discussion would of course be an incentive to be there even
without KS invitation, but it is too far to travel just for that purpose.
Guenter
On Tuesday, August 20, 2013 11:11:09 PM Rafael J. Wysocki wrote:
> On Tuesday, August 20, 2013 08:26:50 PM Matthew Garrett wrote:
> > This conversation seems to have pretty much entirely ended up happening
> > on ksummit-discuss, which doesn't seem that useful. So let's have
> > another go with a wider audience (and where I don't have to sign up for
> > yet another mailing list...)
[...]
> > In any case, it seems like this is something that should be discussed. A
> > bunch of people in the earlier discussion mentioned that they were going
> > to be in New Orleans, so I'd suggest that we arrange a time for
> > in-person discussion there. That should give us a solid basis for
> > further mailing list discussion, and then there'll be another
> > opportunity for discussion in Edinburgh.
>
> There is a time slot reserved for the second part of the ACPI/PM+PCI uconf
> that may be used for this purpose if it's suitable for all of the interested
> people. It is scheduled at 2 PM on Thursday, September 19 at the moment
> (concurrently with the containers uconf).
OK, so for the information of everyone interested, the discussion in New Orleans
is now officially on the LPC's ACPI/PM+PCI uconf agenda and tentatively scheduled
in the time slot mentioned above.
Thanks,
Rafael
On Tue, Aug 20, 2013 at 11:11 PM, Rafael J. Wysocki <[email protected]> wrote:
> There's one more problematic case which is that some systems ship with ACPI
> tables that don't contain all of the information necessary to enumerate
> hardware appropriately and it's difficult, if not impossible, to convince
> the vendors of those systems to fix their ACPI firmware after the fact.
> However, at least in some cases there are well defined DT bindings for the
> hardware in question.
I think this works as far as the hardware can be described in a simple
way.
When the hardware is complex, the problem of interoperating with ACPI
becomes complex, because when it comes to interrupts and other
resources, it seems to me that both ACPI and DT wants to be in
the driver seat and there is only place for one.
Let me copy this example again for this wider discusson
(OK Rafael has seen it before, so you can skip the rest):
Here is an example:
drivers/gpio/gpio-stmpe.c
This is a generic multi-purpose-expander, it can be used on any
system, be it ARM, blackfin or x86 embedded. You connect this
to an I2C port and then there is an IRQ line that you will need to
connect to a dedicated IRQ in pin or a GPIO line configured to take
an IRQ in. Since it contains a GPIO expander and a keypad driver
those two aspects get configured.
It looks like this in an I2C controller node
(condensed from arch/arm/boot/dts/href.dtsi and more)
i2c@80004000 {
stmpe1601: stmpe1601@40 {
compatible = "st,stmpe1601";
reg = <0x40>;
interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
interrupt-parent = <&gpio6>;
interrupt-controller;
wakeup-source;
st,autosleep-timeout = <1024>;
stmpe_keypad {
compatible = "st,stmpe-keypad";
debounce-interval = <64>;
st,scan-count = <8>;
st,no-autorepeat;
linux,keymap = <0x205006b
0x4010074
0x3050072
0x1030004
0x502006a
0x500000a
0x5008b
0x706001c
0x405000b
0x6070003
0x3040067
0x303006c
0x60400e7
0x602009e
0x4020073
0x5050002
0x4030069
0x3020008>;
};
};
};
As you can some stuff is nice to get for free: the keymap
parser, scan settings, debounce, and so on. But then we run
into these problems:
- The I2C address is specified in "reg" - maybe ACPI have
some other way to assign I2C addresses to I2C devices?
In any case, it *must* reference the parent I2C controller,
here that is done implicitly by placing this DT node inside
the I2C controllers DT node.
- Then it is using a GPIO line as interrupt, and specify that
this shall be configured as a falling edge IRQ.
- It then tells the interrupt controller parent. So it needs
to have a reference to whatever interrupt chip device
will handle that IRQ.
- Further it *is* an interrupt controller, so devices connected
to the GPIO lines may generate IRQs and then this
device should service them. Is it possible that the devices
connected to this expander in turn use ACPI to describe
themselves? Then we need a reference in the other
direction.
- Further it is a wakeup source, so each IRQ it provides
on its GPIO lines can be set as a wakeup. I wonder how
this plays with D-states and ACPI.
-------
I did present the above as an extreme example, but if we
start to combine DT and ACPI we have to have that kind of
hardware in mind. GPIO expanders with IRQs and all are
maybe rare on desktops and laptops but very common on
embedded systems.
Yours,
Linus Walleij
On Wed, Aug 21, 2013 at 05:57:07PM +0200, Linus Walleij wrote:
> - The I2C address is specified in "reg" - maybe ACPI have
> some other way to assign I2C addresses to I2C devices?
> In any case, it *must* reference the parent I2C controller,
> here that is done implicitly by placing this DT node inside
> the I2C controllers DT node.
That's fine. You put the child device inside the I2C contorller's scope,
which can be done from a separate ACPI table if you want. The address
can be provided via _ADR().
> - Then it is using a GPIO line as interrupt, and specify that
> this shall be configured as a falling edge IRQ.
ACPI 5 permits this.
> - It then tells the interrupt controller parent. So it needs
> to have a reference to whatever interrupt chip device
> will handle that IRQ.
By interrupt controller, do you mean the GPIO controller? ACPI GPIO
definitions include the parent device.
> - Further it *is* an interrupt controller, so devices connected
> to the GPIO lines may generate IRQs and then this
> device should service them. Is it possible that the devices
> connected to this expander in turn use ACPI to describe
> themselves? Then we need a reference in the other
> direction.
I think that's also doable.
> - Further it is a wakeup source, so each IRQ it provides
> on its GPIO lines can be set as a wakeup. I wonder how
> this plays with D-states and ACPI.
That's fine. GPIO lines can be described as causing ACPI events and then
that simply referenced as a wakeup event.
> I did present the above as an extreme example, but if we
> start to combine DT and ACPI we have to have that kind of
> hardware in mind. GPIO expanders with IRQs and all are
> maybe rare on desktops and laptops but very common on
> embedded systems.
Yeah, describing complicated device topology isn't really the problem I
think we'll end up facing - it's the wider range of device configuration
data that worries me.
--
Matthew Garrett | [email protected]
On Wednesday, August 21, 2013 05:09:03 PM Matthew Garrett wrote:
> On Wed, Aug 21, 2013 at 05:57:07PM +0200, Linus Walleij wrote:
>
> > - The I2C address is specified in "reg" - maybe ACPI have
> > some other way to assign I2C addresses to I2C devices?
> > In any case, it *must* reference the parent I2C controller,
> > here that is done implicitly by placing this DT node inside
> > the I2C controllers DT node.
>
> That's fine. You put the child device inside the I2C contorller's scope,
> which can be done from a separate ACPI table if you want. The address
> can be provided via _ADR().
>
> > - Then it is using a GPIO line as interrupt, and specify that
> > this shall be configured as a falling edge IRQ.
>
> ACPI 5 permits this.
>
> > - It then tells the interrupt controller parent. So it needs
> > to have a reference to whatever interrupt chip device
> > will handle that IRQ.
>
> By interrupt controller, do you mean the GPIO controller? ACPI GPIO
> definitions include the parent device.
>
> > - Further it *is* an interrupt controller, so devices connected
> > to the GPIO lines may generate IRQs and then this
> > device should service them. Is it possible that the devices
> > connected to this expander in turn use ACPI to describe
> > themselves? Then we need a reference in the other
> > direction.
>
> I think that's also doable.
>
> > - Further it is a wakeup source, so each IRQ it provides
> > on its GPIO lines can be set as a wakeup. I wonder how
> > this plays with D-states and ACPI.
>
> That's fine. GPIO lines can be described as causing ACPI events and then
> that simply referenced as a wakeup event.
>
> > I did present the above as an extreme example, but if we
> > start to combine DT and ACPI we have to have that kind of
> > hardware in mind. GPIO expanders with IRQs and all are
> > maybe rare on desktops and laptops but very common on
> > embedded systems.
>
> Yeah, describing complicated device topology isn't really the problem I
> think we'll end up facing - it's the wider range of device configuration
> data that worries me.
There are at least two problems here in my view. The above is the first one.
The second one is that even if there is a *theoretical* way to represent
the configuration information from a Device Tree in ACPI tables, there still
is the question who will be responsible for creating those ACPI tables for
the given system in the first place. That would involve writing ASL code,
compiling it into AML, possibly verifying that it does what it's supposed to
do etc. And it obviously has to match the rest of the ACPI namespace.
To me, there's quite a difference between saying "this can be done" and giving
instructions how to do it.
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.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
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.
--
Matthew Garrett | [email protected]
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.
On Thu, Aug 22, 2013 at 02:02:29AM +0200, Rafael J. Wysocki wrote:
> 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?
On ARM? I know that this is true on x86, but that's because x86 vendors
have never intended i2c hardware monitoring devices be driven by a
general purpoes OS - they're there for the benefit of the firmware, not
anything above that.
> 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?
Ideally we have a consistent in-kernel representation of this
information and drivers don't need to care about whether it came from DT
or ACPI, but like I said, that's going to be tricky.
> I don't honestly think that the "ask vendors to ship their systems with correct
> ACPI tables" approach will take us anywhere.
It's worked well enough on x86. If hardware vendors don't actually test
that their hardware is able to boot the OS it's intended to run then
there's very little we can do about that - and the worst case outcome is
that people just ignore the shipped ACPI and use FDT.
--
Matthew Garrett | [email protected]
On Thu, 2013-08-22 at 01:03 +0100, Matthew Garrett wrote:
> On Thu, Aug 22, 2013 at 02:02:29AM +0200, Rafael J. Wysocki wrote:
>
> > 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?
>
> On ARM? I know that this is true on x86, but that's because x86 vendors
> have never intended i2c hardware monitoring devices be driven by a
> general purpoes OS - they're there for the benefit of the firmware, not
> anything above that.
>
> > 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?
>
> Ideally we have a consistent in-kernel representation of this
> information and drivers don't need to care about whether it came from DT
> or ACPI, but like I said, that's going to be tricky.
>
> > I don't honestly think that the "ask vendors to ship their systems with correct
> > ACPI tables" approach will take us anywhere.
>
> It's worked well enough on x86. If hardware vendors don't actually test
> that their hardware is able to boot the OS it's intended to run then
> there's very little we can do about that - and the worst case outcome is
> that people just ignore the shipped ACPI and use FDT.
>
It appears both Matthew and Rafael are supporting a statement to the
effect that we should not expect anyone but BIOS/firmware vendors to be
writing ACPI code (such as SSDTs which they compile, store on the boot
media, and pass into the kernel at boot time). This is certainly the
case know (with a few rare exceptions where people are trying to work
around broken BIOS ACPI tables.
It had been my hope at the start of this project to open the creation of
SSDTs up to inventors and hackers who want to create Lures for the
MinnowBoard in such a way that they could write these SSDTs and load
them from a file at boot time, modify, rebuild, iterate, etc. When/if
the Lure goes to production, the SSDT could either be stored on an
EEPROM, or for very low volume boards, possibly just shipped as a binary
to be loaded (with source available of course).
It appears that Matthew, at least, would prefer this latter scenario
just used DT instead. However, that seems to leave a gap in the
transition to incorporating the table into the board firmware should a
derivative product be made. e.g. no good way to prototype with ACPI. It
also seems to have all the same problems raised regarding mixing ACPI
and DT on the same system.
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
On Fri, Aug 23, 2013 at 04:25:43PM -0700, Darren Hart wrote:
> It had been my hope at the start of this project to open the creation of
> SSDTs up to inventors and hackers who want to create Lures for the
> MinnowBoard in such a way that they could write these SSDTs and load
> them from a file at boot time, modify, rebuild, iterate, etc. When/if
> the Lure goes to production, the SSDT could either be stored on an
> EEPROM, or for very low volume boards, possibly just shipped as a binary
> to be loaded (with source available of course).
There's no fundamental problem with doing this, especially on UEFI
systems. As long as you know the host ACPI code, it's trivial to merge
an SSDT in from a UEFI option ROM.
> It appears that Matthew, at least, would prefer this latter scenario
> just used DT instead. However, that seems to leave a gap in the
> transition to incorporating the table into the board firmware should a
> derivative product be made. e.g. no good way to prototype with ACPI. It
> also seems to have all the same problems raised regarding mixing ACPI
> and DT on the same system.
I've no problem with additional hardware shipping with ACPI support - my
position was more that if a vendor ships a system with ACPI that fails
to describe the integrated hardware (or does so incorrectly), it's
probably easier to replace it with DT than a fixed ACPI table. Still, if
people *do* want to replace shipped ACPI tables, it's probably
preferable to do that at the bootloader level than the kernel level.
--
Matthew Garrett | [email protected]
On Sat, 2013-08-24 at 00:38 +0100, Matthew Garrett wrote:
> On Fri, Aug 23, 2013 at 04:25:43PM -0700, Darren Hart wrote:
>
> > It had been my hope at the start of this project to open the creation of
> > SSDTs up to inventors and hackers who want to create Lures for the
> > MinnowBoard in such a way that they could write these SSDTs and load
> > them from a file at boot time, modify, rebuild, iterate, etc. When/if
> > the Lure goes to production, the SSDT could either be stored on an
> > EEPROM, or for very low volume boards, possibly just shipped as a binary
> > to be loaded (with source available of course).
>
> There's no fundamental problem with doing this, especially on UEFI
> systems. As long as you know the host ACPI code, it's trivial to merge
> an SSDT in from a UEFI option ROM.
>
> > It appears that Matthew, at least, would prefer this latter scenario
> > just used DT instead. However, that seems to leave a gap in the
> > transition to incorporating the table into the board firmware should a
> > derivative product be made. e.g. no good way to prototype with ACPI. It
> > also seems to have all the same problems raised regarding mixing ACPI
> > and DT on the same system.
>
> I've no problem with additional hardware shipping with ACPI support - my
> position was more that if a vendor ships a system with ACPI that fails
> to describe the integrated hardware (or does so incorrectly), it's
> probably easier to replace it with DT than a fixed ACPI table. Still, if
> people *do* want to replace shipped ACPI tables, it's probably
> preferable to do that at the bootloader level than the kernel level.
>
OK. Thanks for elaborating.
It seems to me that in order to fully support this, we are back to the
problem of how do we provide arbitrary configuration data via ACPI (the
DSM being the only current means, but there is no standard there). Is
that still the hard problem we are looking to solve as a group?
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
On Fri, Aug 23, 2013 at 04:45:48PM -0700, Darren Hart wrote:
> On Sat, 2013-08-24 at 00:38 +0100, Matthew Garrett wrote:
> > On Fri, Aug 23, 2013 at 04:25:43PM -0700, Darren Hart wrote:
> >
> > > It had been my hope at the start of this project to open the creation of
> > > SSDTs up to inventors and hackers who want to create Lures for the
> > > MinnowBoard in such a way that they could write these SSDTs and load
> > > them from a file at boot time, modify, rebuild, iterate, etc. When/if
> > > the Lure goes to production, the SSDT could either be stored on an
> > > EEPROM, or for very low volume boards, possibly just shipped as a binary
> > > to be loaded (with source available of course).
> >
> > There's no fundamental problem with doing this, especially on UEFI
> > systems. As long as you know the host ACPI code, it's trivial to merge
> > an SSDT in from a UEFI option ROM.
> >
> > > It appears that Matthew, at least, would prefer this latter scenario
> > > just used DT instead. However, that seems to leave a gap in the
> > > transition to incorporating the table into the board firmware should a
> > > derivative product be made. e.g. no good way to prototype with ACPI. It
> > > also seems to have all the same problems raised regarding mixing ACPI
> > > and DT on the same system.
> >
> > I've no problem with additional hardware shipping with ACPI support - my
> > position was more that if a vendor ships a system with ACPI that fails
> > to describe the integrated hardware (or does so incorrectly), it's
> > probably easier to replace it with DT than a fixed ACPI table. Still, if
> > people *do* want to replace shipped ACPI tables, it's probably
> > preferable to do that at the bootloader level than the kernel level.
> >
>
> OK. Thanks for elaborating.
>
> It seems to me that in order to fully support this, we are back to the
> problem of how do we provide arbitrary configuration data via ACPI (the
> DSM being the only current means, but there is no standard there). Is
> that still the hard problem we are looking to solve as a group?
>
Did the group conclude that the idea of FDT augmenting ACPI is not feasible ?
If not, the key question for me is how to implement it, and how to handle
all its little problems.
If yes, the key question for me is how to handle all the drivers which
assume fdt-style properties, and how to express all that information in ACPI
in a way which does not require a substantial driver rewrite (and, as you point
out, how that data would be described in ACPI consistently across multiple
vendors).
Guenter
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.
--
Matthew Garrett | [email protected]
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.
Guenter
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?
--
Matthew Garrett | [email protected]
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
On Fri, Aug 23, 2013 at 07:55:31PM -0700, Guenter Roeck wrote:
> 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.
There's no such thing as an ACPI interrupt, it's just a data source in
the same way that PnP used to be. _CRS refers to platform interrupts.
--
Matthew Garrett | [email protected]
On 08/23/2013 08:06 PM, Matthew Garrett wrote:
> On Fri, Aug 23, 2013 at 07:55:31PM -0700, Guenter Roeck wrote:
>
>> 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.
>
> There's no such thing as an ACPI interrupt, it's just a data source in
> the same way that PnP used to be. _CRS refers to platform interrupts.
>
Ah, you are catching my lack of ACPI knowledge.
Rephrasing the question:
"What happens when you have an ACPI device that contains an interrupt in
_CRS and contains a different interrupt in an embedded FDT block?"
Does the situation occur today, ie does it ever happen that one interrupt
for a device is specified (if that is the correct term) in _CRS and
another by some other means ?
Guenter
On Fri, Aug 23, 2013 at 09:45:10PM -0700, Guenter Roeck wrote:
> "What happens when you have an ACPI device that contains an interrupt in
> _CRS and contains a different interrupt in an embedded FDT block?"
>
> Does the situation occur today, ie does it ever happen that one interrupt
> for a device is specified (if that is the correct term) in _CRS and
> another by some other means ?
The only case I can think of is PCI, where we ignored the ACPI-provided
resources until fairly recently. That was a somewhat reasonable thing to
do, since the hardware still had to support pre-ACPI operating systems
and so the non-ACPI information sources were typically correct.
Other than that, I think we always trust the ACPI data.
--
Matthew Garrett | [email protected]
On 08/23/2013 09:51 PM, Matthew Garrett wrote:
> On Fri, Aug 23, 2013 at 09:45:10PM -0700, Guenter Roeck wrote:
>
>> "What happens when you have an ACPI device that contains an interrupt in
>> _CRS and contains a different interrupt in an embedded FDT block?"
>>
>> Does the situation occur today, ie does it ever happen that one interrupt
>> for a device is specified (if that is the correct term) in _CRS and
>> another by some other means ?
>
> The only case I can think of is PCI, where we ignored the ACPI-provided
> resources until fairly recently. That was a somewhat reasonable thing to
> do, since the hardware still had to support pre-ACPI operating systems
> and so the non-ACPI information sources were typically correct.
>
> Other than that, I think we always trust the ACPI data.
>
Seems to me you answered your question. It should be possible
to do the same if you replace (ACPI, BIOS) with (ACPI, FDT).
Plus, hopefully there should be no reason to specify data in FDT
that is already provided through ACPI. If it is specified anyway,
its handling is a matter of policy.
Guenter
On Sat, Aug 24, 2013 at 2:13 AM, Guenter Roeck <[email protected]> wrote:
> Did the group conclude that the idea of FDT augmenting ACPI is not feasible ?
I don't think anyone really knows. For example: how to specify a few
config options through a FDT augmented ACPI system is trivial. Passing
system-wide resources such as clocks, regulators, pin control handles,
GPIOs, interrupts and DMA channels is a criss-cross operation and
nobody knows if that will work because nobody tried to hash out
the details of.
> If not, the key question for me is how to implement it, and how to handle
> all its little problems.
It seems like we are in the "teenagers talking about sex" situation,
everybody is talking about it but nobody is really doing it.
Which makes it all pretty theoretical.
> If yes, the key question for me is how to handle all the drivers which
> assume fdt-style properties, and how to express all that information in ACPI
> in a way which does not require a substantial driver rewrite (and, as you point
> out, how that data would be described in ACPI consistently across multiple
> vendors).
For GPIO we have this:
drivers/gpio/gpiolib-of.c
drivers/gpio/gpiolib-acpi.c
So one thing is clear: for this resource we're going to have two
implementations.
Yours,
Linus Walleij
On Mon, Aug 26, 2013 at 11:32:44AM +0200, Linus Walleij wrote:
> On Sat, Aug 24, 2013 at 2:13 AM, Guenter Roeck <[email protected]> wrote:
>
> > Did the group conclude that the idea of FDT augmenting ACPI is not feasible ?
>
> I don't think anyone really knows. For example: how to specify a few
> config options through a FDT augmented ACPI system is trivial. Passing
> system-wide resources such as clocks, regulators, pin control handles,
> GPIOs, interrupts and DMA channels is a criss-cross operation and
> nobody knows if that will work because nobody tried to hash out
> the details of.
>
This bit the ACPI team at Linaro is currently trying to hash out.
> > If not, the key question for me is how to implement it, and how to handle
> > all its little problems.
>
> It seems like we are in the "teenagers talking about sex" situation,
> everybody is talking about it but nobody is really doing it.
> Which makes it all pretty theoretical.
>
> > If yes, the key question for me is how to handle all the drivers which
> > assume fdt-style properties, and how to express all that information in ACPI
> > in a way which does not require a substantial driver rewrite (and, as you point
> > out, how that data would be described in ACPI consistently across multiple
> > vendors).
>
> For GPIO we have this:
>
> drivers/gpio/gpiolib-of.c
> drivers/gpio/gpiolib-acpi.c
>
> So one thing is clear: for this resource we're going to have two
> implementations.
>
My personal feeling is we will need two of everything at the ACPI/FDT level,
but we can share commonality between the two subsystems in a more generic
level. One thing we have been looking at it allowing some devices in ACPI
and some in FDT type initialisations.
Within the Linaro ACPI team we are currently prototyping to try and settle
some of the questions raised.
I do not think that trying to get OEMs to put FDT fragments inside ACPI will
work, although that solution would certainly "solve" a lot of driver
implementation issues.
Graeme