ACPI

ACPI

[Jon Masters]

Hi Folks,

Starting a new thread with a question. Suppose for a moment that ACPI is the way of the future and that there is, in fact, already a three year story behind this[0] that will come out in due course. What could be done to make things smoother /going forward/? Could we articulate a series of useful asks that would help with moving forward with ACPI? For example, it is clear that there needs to be more involvement in the standardization of ACPI (this is why we initiated the governance model change of ACPI several years ago that has taken this long to resolve with everyone involved in that) and we want to get more ARM kernel folks involved. But what else? Blank slate. What do we need to make ACPI a success here?

Jon.

[0] Allow me the indulgence of not going into the specifics just now - I'm not the bad guy maverick forcing this down anyone's throat, I'm just willing to speak publicly while many others won't just yet, because I know how Linux is developed and I know that the community really hate being out of the loop. I do get it.

ACPI

[Arnd Bergmann]

On Monday 18 November 2013, Jon Masters wrote:
> Hi Folks,
> 
> Starting a new thread with a question. Suppose for a moment that ACPI is
> the way of the future and that there is, in fact, already a three year
> story behind this[0] that will come out in due course. What could be
> done to make things smoother /going forward/? Could we articulate a
> series of useful asks that would help with moving forward with ACPI? 

I think the most important thing to do here is to actually describe
and agree on the scope of ACPI support here.  I think in the discussion,
everyone had different scenarios in mind, and hopefully only some
of them apply here. You keep saying "servers", but that isn't actually
a feature of how the system is designed, rather than what is running
on them. Given these examples (or any others, you could come up with),
which ones do you actually see as relevant here:

1. An exterprise server (SPARC enterprise M9000, Power 795, Integrity
   Superdome) with the CPU core changed to run ARM instructions
2. An ATX whitebox server mainboard with one to four sockets and PC
   peripherals and plug-compatible ARM CPU chips.
3. A purpose-built server SoC based on standard components
4. A new server SoC based on an older proprietary embedded or mobile
   SoC design (think Exynos, OMAP, Snapdragon, ... based)
5. A server built from using a cheap devboard (BeagleBone, Cubieboard, ...
   style) with an unmodified SoC.
6. A virtual machine running on KVM or Xen.

Related to that question, what would be the expected way to do runtime
device power management? 

a) not at all
b) using ACPI D states and AML
c) using HW-specific clock/regulator/pmdomain/pinctrl/phy/...
   kernel drivers

Some combinations of the above are particularly scary, and until we
have ruled out a good number of them, we will keep arguing about the
wrong problems.

The other really helpful would be a list of things that actually
speak in favor of doing ACPI, from a system design perspective.
What is it that people want out of it?

> For example, it is clear that there needs to be more involvement in the
> standardization of ACPI (this is why we initiated the governance model
> change of ACPI several years ago that has taken this long to resolve
> with everyone involved in that) and we want to get more ARM kernel folks
> involved. But what else? Blank slate.
> What do we need to make ACPI a success here?

I think you are asking the wrong question here. I assume we all try to
make ARM Linux work best on servers and that people are willing to
work together on that. However, to a lot of us that would mean making
sure that ACPI does not get anywhere near us (for the right or for the
wrong reasons). A blank slate to me would imply that you consider the
possibility that ACPI is not the right answer at this point at all rather
than asking everybody is working on platform code to take your word
that it is.

Since you mention this has been going for three years, I can understand
what arguments originally led to such a decision, but my feeling is that
we have move on since then and that the original discussion will need to
be revisited (ideally in a more open way) based on what we learned in
the meantime by moving most ARM platforms over from board files to DT.

	Arnd

ACPI

[Mark Brown]

On Tue, Nov 19, 2013 at 07:15:57PM +0100, Arnd Bergmann wrote:

> of them apply here. You keep saying "servers", but that isn't actually
> a feature of how the system is designed, rather than what is running
> on them. Given these examples (or any others, you could come up with),
> which ones do you actually see as relevant here:

> 1. An exterprise server (SPARC enterprise M9000, Power 795, Integrity
>    Superdome) with the CPU core changed to run ARM instructions
> 2. An ATX whitebox server mainboard with one to four sockets and PC
>    peripherals and plug-compatible ARM CPU chips.
> 3. A purpose-built server SoC based on standard components
> 4. A new server SoC based on an older proprietary embedded or mobile
>    SoC design (think Exynos, OMAP, Snapdragon, ... based)
> 5. A server built from using a cheap devboard (BeagleBone, Cubieboard, ...
>    style) with an unmodified SoC.
> 6. A virtual machine running on KVM or Xen.

I'd also ask if we need to consider desktops and laptops here - do we
really mean distros here rather than servers, even if servers are the
primary use case for distros right now?

> The other really helpful would be a list of things that actually
> speak in favor of doing ACPI, from a system design perspective.
> What is it that people want out of it?

+1.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131121/c28c9a46/attachment.sig>

ACPI

[Arnd Bergmann]

On Thursday 21 November 2013, Mark Brown wrote:
> On Tue, Nov 19, 2013 at 07:15:57PM +0100, Arnd Bergmann wrote:
> 
> > of them apply here. You keep saying "servers", but that isn't actually
> > a feature of how the system is designed, rather than what is running
> > on them. Given these examples (or any others, you could come up with),
> > which ones do you actually see as relevant here:
> 
> > 1. An exterprise server (SPARC enterprise M9000, Power 795, Integrity
> >    Superdome) with the CPU core changed to run ARM instructions
> > 2. An ATX whitebox server mainboard with one to four sockets and PC
> >    peripherals and plug-compatible ARM CPU chips.
> > 3. A purpose-built server SoC based on standard components
> > 4. A new server SoC based on an older proprietary embedded or mobile
> >    SoC design (think Exynos, OMAP, Snapdragon, ... based)
> > 5. A server built from using a cheap devboard (BeagleBone, Cubieboard, ...
> >    style) with an unmodified SoC.
> > 6. A virtual machine running on KVM or Xen.
> 
> I'd also ask if we need to consider desktops and laptops here - do we
> really mean distros here rather than servers, even if servers are the
> primary use case for distros right now?

Jon has previously said (multiple times) that he cares about servers
only, so I assume that is still given. If you take the exact same
hardware and firmware and add a PCIe GPU to turn it into a workstation
or laptop, I don't see that change anything from the kernel perspective,
but I'm trying to narrow the scope here, not widen it ;-)

	Arnd

ACPI

[Jon Masters]

Hi Arnd,

On 11/21/2013 07:29 PM, Arnd Bergmann wrote:
> On Thursday 21 November 2013, Mark Brown wrote:
>> On Tue, Nov 19, 2013 at 07:15:57PM +0100, Arnd Bergmann wrote:
>>
>>> of them apply here. You keep saying "servers", but that isn't actually
>>> a feature of how the system is designed, rather than what is running
>>> on them. Given these examples (or any others, you could come up with),
>>> which ones do you actually see as relevant here:
>>
>>> 1. An exterprise server (SPARC enterprise M9000, Power 795, Integrity
>>>    Superdome) with the CPU core changed to run ARM instructions
>>> 2. An ATX whitebox server mainboard with one to four sockets and PC
>>>    peripherals and plug-compatible ARM CPU chips.
>>> 3. A purpose-built server SoC based on standard components
>>> 4. A new server SoC based on an older proprietary embedded or mobile
>>>    SoC design (think Exynos, OMAP, Snapdragon, ... based)
>>> 5. A server built from using a cheap devboard (BeagleBone, Cubieboard, ...
>>>    style) with an unmodified SoC.
>>> 6. A virtual machine running on KVM or Xen.

By 64-bit ARM server, I mean a system conformant with a series of
specifications that define what such a server system consists of. It
might be a physical system featuring an ARM-based SoC containing a core
conformant to the v8 Architecture, along with standardized peripherals,
or it might be a virtual platform. The boot architecture would include
UEFI (specifically a sequential progression from an initial EL3 reset
secure ROM on through to a verified Tiano build), and ACPI being used to
convey the platform devices, as well as for runtime event delivery.

>> I'd also ask if we need to consider desktops and laptops here - do we
>> really mean distros here rather than servers, even if servers are the
>> primary use case for distros right now?
> 
> Jon has previously said (multiple times) that he cares about servers
> only, so I assume that is still given. If you take the exact same
> hardware and firmware and add a PCIe GPU to turn it into a workstation
> or laptop, I don't see that change anything from the kernel perspective,
> but I'm trying to narrow the scope here, not widen it ;-)

I expect to see a series of useful announcements soon that will serve to
articulate what I am referring to by an ARM v8 server. I will followup
then with more thoughts about how this fits together.

Thanks,

Jon.

ACPI

[Arnd Bergmann]

On Friday 22 November 2013, Jon Masters wrote:

> By 64-bit ARM server, I mean a system conformant with a series of
> specifications that define what such a server system consists of. It
> might be a physical system featuring an ARM-based SoC containing a core
> conformant to the v8 Architecture, along with standardized peripherals,
> or it might be a virtual platform. The boot architecture would include
> UEFI (specifically a sequential progression from an initial EL3 reset
> secure ROM on through to a verified Tiano build), and ACPI being used to
> convey the platform devices, as well as for runtime event delivery.

Ok, that narrows it down a little, although not in the way I expected.

It seems there is a secret spec along the lines of the older PREP, CHRP,
PAPR. Since the group behind this spec has not yet revealed itself, I will
refer to them as SPECTRE (maybe that should be SPCTR?) for the sake of
discussion.

>From your description, it sounds like SPECTRE is actually trying to make
the job easier for the operating system to some degree by defining a
standard hardware platform. If this actually works out and they hardware
people don't screw up too much, supporting that platform should be
a no-brainer, and I see no fundamental problem with adding ACPI support
for that.

What I also take away from this is that we should not any ACPI support
for platforms that are not SPECTRE compliant, because that would
add a long-term maintainance cost without the benefits, especially
if it ends up implementing an incompatible ACPI dialect. I certainly
don't want to have to maintain two or more versions of ACPI (e.g.
one doing power management using AML and one using SoC specific 
device drivers).

Unfortunately it is impossible to know at this point what work is
actually relevant for SPECTRE and what is not, so we can't really
merge anything specific to ARM64+ACPI until we have access to an
actual spec, or we get a video message by someone with a monocle
and a lap cat to shed some more light on the actual requirements.
There is also the danger that either the SPECTRE spec or the
actual implementations are so screwed up that we still wouldn't
merge anything, but you can probably judge better how likely that
worst-case scenario is.

Those people that have inside knowledge of SPECTRE can in the meantime
work on the patches and get them reviewed (I think this is happening
anyway), and we can certainly keep working with Intel to enable 
whatever features they need for embedded x86 with ACPI.

> I expect to see a series of useful announcements soon that will serve to
> articulate what I am referring to by an ARM v8 server. I will followup
> then with more thoughts about how this fits together.

Sounds good.

	Arnd

ACPI

[Jon Masters]

On 11/22/2013 03:31 PM, Arnd Bergmann wrote:
> On Friday 22 November 2013, Jon Masters wrote:
> 
>> By 64-bit ARM server, I mean a system conformant with a series of
>> specifications that define what such a server system consists of. It
>> might be a physical system featuring an ARM-based SoC containing a core
>> conformant to the v8 Architecture, along with standardized peripherals,
>> or it might be a virtual platform. The boot architecture would include
>> UEFI (specifically a sequential progression from an initial EL3 reset
>> secure ROM on through to a verified Tiano build), and ACPI being used to
>> convey the platform devices, as well as for runtime event delivery.
> 
> Ok, that narrows it down a little, although not in the way I expected.
> 
> It seems there is a secret spec along the lines of the older PREP, CHRP,
> PAPR. Since the group behind this spec has not yet revealed itself, I will
> refer to them as SPECTRE (maybe that should be SPCTR?) for the sake of
> discussion.

That's an *awesome* choice of name. Made my afternoon :) If there were
an organization such as SPECTRE, I really hope that it would come with
those lap cats (I seem to be missing mine - but I do have a stuffed
plush white toy cat in my Amazon wishlist, and a birthday coming..).

But regardless of the existence or otherwise of any organization, I
would expect to see some standards documents appearing in the not too
distant future. I share the concern that this stuff needs to be out in
public, but above all, all else, what I care about above all is that
when there are ARM server systems in market in the next few years that
you can run *any* one-size-fits-all generic Operating System you would
like to choose to run, and freely move from one OS to another. That
includes the ability to run generic Linux distributions, Hypervisors,
non-Unix Operating Systems, and so on. To do that requires that the
underlying server platform be standardized in the same way that it is
elsewhere on other arches, with sensitivity to a wide world of choice.

A few years ago, a strategic direction was chosen by a few industry
players around UEFI and ACPI on ARM. I look forward to seeing standards
published, to seeing more emerging members of this market announced
their intentions, and to an engaging dialog about how support for these
systems will be implemented so that there is one standardized 64-bit ARM
server platform upon which customers can run anything they want. I hope
we can have some really engaging conversation very soon about it.

Thanks,

Jon.

ACPI

[Jon Masters]

On 11/22/2013 03:59 PM, Jon Masters wrote:

> A few years ago, a strategic direction was chosen by a few industry
> players around UEFI and ACPI on ARM. I look forward to seeing standards
> published, to seeing more emerging members of this market announced
> their intentions, and to an engaging dialog about how support for these
> systems will be implemented so that there is one standardized 64-bit ARM
> server platform upon which customers can run anything they want. I hope
> we can have some really engaging conversation very soon about it.

To answer the rest of the thread a little more, what I look forward to
is (eventually) replacing every singe one of my personal servers with a
64-bit ARM based one running a generic OS. In the case of the Fedora
Server release (see the recent revival of that in connection with other
changes in the Fedora space), it is my intention that there ultimately
be supported ISO download media that can even be installed in a local
drive if anyone is antiquated enough to build such an ARM system. But
certainly installing multi-million node clusters (which will be the
norm) based upon HP Moonshot and other vendor hardware should "just
work", using standardized network boot and installation of any OS choice
you care to make, as should moving from one to another.

The bottom line for me is that for those moving from existing
architectures into the new world, everything else remains the same. Same
OEM vendor tooling used to design and build systems and deliver and
support them, same installation experience, very very boring. This is
exactly how ARM will succeed in the market. One Platform. Very very
boring and straightforward installation and management, and so on.

Jon.

ACPI

[Arnd Bergmann]

On Friday 22 November 2013, Jon Masters wrote:
> The bottom line for me is that for those moving from existing
> architectures into the new world, everything else remains the same. Same
> OEM vendor tooling used to design and build systems and deliver and
> support them, same installation experience, very very boring. This is
> exactly how ARM will succeed in the market. One Platform. Very very
> boring and straightforward installation and management, and so on.

Yes, that part seems fine, but be aware that we still have to deal
with lots of other types of systems that are well outside of the scope
of such a server infrastructure: mobile, industrial, networking,
hobbyist, etc equipment. These will typically have very different
SoCs and not follow the server platform specs, but we still want them
to be as boring when you install a Linux distro on them.

I've talked in the past to people who got your message about ACPI
but not the rest and that are now struggling in a very misguided
attempt to bring ACPI to systems that are anything but boring and
that will cause real headaches for years on both developers and users
if they actually end up shipping.

	Arnd

ACPI

[Jason Gunthorpe]

On Sat, Nov 23, 2013 at 10:11:45AM +0100, Arnd Bergmann wrote:

> I've talked in the past to people who got your message about ACPI
> but not the rest and that are now struggling in a very misguided
> attempt to bring ACPI to systems that are anything but boring and
> that will cause real headaches for years on both developers and users
> if they actually end up shipping.

I think a strong way to deal with this is to NAK any ACPI related
changes that are not implementing a published, released spec.

Forcing ACPI development to go through a multi-vendor standards
process, while allowing DT to be handled internally to the kernel
should provide enough incentive to direct people to the correct choice
:)

However, fundamentally, that would mean that ACPI on the ARM is on-hold
from a kernel perspective until the first spec is released by the new
working group - and that would imply initial servers should plan to
boot using DT, and provide experimental ACPI. Similar to how x86
introduced ACPI.

The ACPI working group should also hear what kernel folks want to see
of ACPI eg no clk, regulator, gpio, etc bindings, use DT for that.

First gen servers that can't implement the spec have the DT escape
hatch while they make changes which should reduce the pressure on
kernel folks to accept inappropriate patches...

Jason

ACPI

[Matthew Garrett]

On Sat, Nov 23, 2013 at 11:39:04AM -0700, Jason Gunthorpe wrote:

> However, fundamentally, that would mean that ACPI on the ARM is on-hold
> from a kernel perspective until the first spec is released by the new
> working group - and that would imply initial servers should plan to
> boot using DT, and provide experimental ACPI. Similar to how x86
> introduced ACPI.

Given a sufficiently well-defined platform (as Jon has hinted might be 
on the cards), there shouldn't really be any requirement to add any 
non-standardised ACPI support. Most of the ACPI-on-ARM work we've been 
talking about has been in order to provide a mechanism for booting a 
generic kernel on an ill-defined platform.

But, as it stands, the situation is still confusing. Different people 
who are interested in ACPI on ARM appear to want entirely different 
things, and it's not helped by this vague suggestion that server vendors 
want something entirely different from what Linaro have been working on 
and what we've been discussing at various points during recent 
conferences.

Jon, I know you're constrained by any number of hilarious NDAs, but this 
situation is currently fairly unworkable. The interest various people 
have in ensuring that ACPI on ARM is viable has been spurred on by your 
constant reassurances that server vendors are going to require it. But 
if we don't know what server vendors actually want then there's 
absolutely no guarantee that any of the work we're doing is going to be 
useful, and wasting time now is going to reduce people's ability to care 
in future. There's probably more ACPI expertise in the wider Linux 
community than anywhere else. Figure out a way to make use of it now, 
rather than relying on them to help you later.

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

ACPI

[Jon Masters]

On Nov 23, 2013, at 6:03 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> 
> Jon, I know you're constrained by any number of hilarious NDAs, but this 
> situation is currently fairly unworkable. The interest various people 
> have in ensuring that ACPI on ARM is viable has been spurred on by your 
> constant reassurances that server vendors are going to require it. But 
> if we don't know what server vendors actually want then there's 
> absolutely no guarantee that any of the work we're doing is going to be 
> useful, and wasting time now is going to reduce people's ability to care 
> in future. There's probably more ACPI expertise in the wider Linux 
> community than anywhere else. Figure out a way to make use of it now, 
> rather than relying on them to help you later.

Matthew, good points! Suffice it to say many productive conversations have occurred recently with regard to openness. I am constrained indeed, and somewhat willingly because that is the only way to engage with everyone who might (or might not) be involved in the ARM ecosystem in the timeframe that will matter in the medium/longer term (this is a decade+ long story). As you know, I'm a huge fan of standards (especially openly published ones), and in particular of having one way to do things that will work for an entire ecosystem (beyond just Linux), because that's how we get to an open platform that anyone can target. That's not the natural course things would take without steering. In the ARM space, the natural course might be to create vertical solutions that, while awesome, are harder to target with a general purpose one-size-fits-all OS story. I'll look forward to seeing more announcements coming soon.

Jon.

ACPI

[Matthew Garrett]

On Sat, Nov 23, 2013 at 10:52:25PM -0500, Jon Masters wrote:

> Matthew, good points! Suffice it to say many productive conversations 
> have occurred recently with regard to openness. I am constrained 
> indeed, and somewhat willingly because that is the only way to engage 
> with everyone who might (or might not) be involved in the ARM 
> ecosystem in the timeframe that will matter in the medium/longer term 
> (this is a decade+ long story). As you know, I'm a huge fan of 
> standards (especially openly published ones), and in particular of 
> having one way to do things that will work for an entire ecosystem 
> (beyond just Linux), because that's how we get to an open platform 
> that anyone can target. That's not the natural course things would 
> take without steering. In the ARM space, the natural course might be 
> to create vertical solutions that, while awesome, are harder to target 
> with a general purpose one-size-fits-all OS story. I'll look forward 
> to seeing more announcements coming soon.

That seems to be a very verbose way to say "We have no plans to make 
sure this is going to work for upstream Linux". I'm disappointed to see 
Red Hat play along with this.

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

ACPI

[Jon Masters]

On Nov 23, 2013, at 10:56 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Sat, Nov 23, 2013 at 10:52:25PM -0500, Jon Masters wrote:
> 
>> Matthew, good points! Suffice it to say many productive conversations 
>> have occurred recently with regard to openness. I am constrained 
>> indeed, and somewhat willingly because that is the only way to engage 
>> with everyone who might (or might not) be involved in the ARM 
>> ecosystem in the timeframe that will matter in the medium/longer term 
>> (this is a decade+ long story). As you know, I'm a huge fan of 
>> standards (especially openly published ones), and in particular of 
>> having one way to do things that will work for an entire ecosystem 
>> (beyond just Linux), because that's how we get to an open platform 
>> that anyone can target. That's not the natural course things would 
>> take without steering. In the ARM space, the natural course might be 
>> to create vertical solutions that, while awesome, are harder to target 
>> with a general purpose one-size-fits-all OS story. I'll look forward 
>> to seeing more announcements coming soon.
> 
> That seems to be a very verbose way to say "We have no plans to make 
> sure this is going to work for upstream Linux". I'm disappointed to see 
> Red Hat play along with this.

Matthew, it's a very verbose way to say "this is being worked on". The need to get specifications and standards out into public is acutely understood. It's something I've been pushing on for many many months, and it's something that I expect to see changing soon.  That's really all I'm going to say about it for the moment. Meanwhile, I hope that the ACPI patches being worked on (very very hard, by very awesome people) will be reviewed and considered on their merits.

Jon.

ACPI

[Matthew Garrett]

Jon Masters <jonathan@jonmasters.org> wrote:
>
>On Nov 23, 2013, at 10:56 PM, Matthew Garrett <mjg59@srcf.ucam.org>
>wrote:
>> That seems to be a very verbose way to say "We have no plans to make 
>> sure this is going to work for upstream Linux". I'm disappointed to
>see 
>> Red Hat play along with this.
>
>Matthew, it's a very verbose way to say "this is being worked on". The
>need to get specifications and standards out into public is acutely
>understood. It's something I've been pushing on for many many months,
>and it's something that I expect to see changing soon.  That's really
>all I'm going to say about it for the moment. Meanwhile, I hope that
>the ACPI patches being worked on (very very hard, by very awesome
>people) will be reviewed and considered on their merits.

The track record of vendors adopting solutions and then getting them upstream is significantly worse than that of vendors working with the community and then deploying the negotiated solution. Patches aren't going to be rejected out of hand, but if they satisfy a small number of vendors while compromising the wider kernel then there's a real risk that they won't end up upstream in the desired timescale.

If you're OK taking that risk then I don't think there's anything more to discuss - we'll just wait for the hardware/patches/spec to land and see whether they're reasonable or not. But that's really not the Red Hat way, and it's a shame seeing the company move away from its base. 


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

ACPI

[Mark Brown]

On Fri, Nov 22, 2013 at 01:29:54AM +0100, Arnd Bergmann wrote:
> On Thursday 21 November 2013, Mark Brown wrote:

> > I'd also ask if we need to consider desktops and laptops here - do we
> > really mean distros here rather than servers, even if servers are the
> > primary use case for distros right now?

> Jon has previously said (multiple times) that he cares about servers
> only, so I assume that is still given. If you take the exact same

Ah, I'd not seen that - but of course there are a bunch of different
and overlapping userbases out there each with their own focuses.

> hardware and firmware and add a PCIe GPU to turn it into a workstation
> or laptop, I don't see that change anything from the kernel perspective,
> but I'm trying to narrow the scope here, not widen it ;-)

Indeed.  I'd be surprised if people built too many systems that way
though, especially laptops.

I'm perfectly prepared to believe that the answer here is that nobody
cares about ACPI on anything other than some subset of servers (which
will depend in part on what people see ACPI doing for them) but I figure
it's important to ask the question, especially given that Intel seem to
be deploying more embedded style hardware in these applications - Linux
may have to cope with these cases anyway.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131122/5c1556c1/attachment.sig>

ACPI

[Måns Rullgård]

Jon Masters <jonathan@jonmasters.org> writes:

> What do we need to make ACPI a success here?

First and foremost, we need a reason.  So far none has been given.

-- 
M?ns Rullg?rd
mans at mansr.com

ACPI

[Matthew Garrett]

On Mon, Nov 18, 2013 at 01:42:32PM -0500, Jon Masters wrote:

> Starting a new thread with a question. Suppose for a moment that ACPI 
> is the way of the future and that there is, in fact, already a three 
> year story behind this[0] that will come out in due course. What could 
> be done to make things smoother /going forward/? Could we articulate a 
> series of useful asks that would help with moving forward with ACPI? 
> For example, it is clear that there needs to be more involvement in 
> the standardization of ACPI (this is why we initiated the governance 
> model change of ACPI several years ago that has taken this long to 
> resolve with everyone involved in that) and we want to get more ARM 
> kernel folks involved. But what else? Blank slate. What do we need to 
> make ACPI a success here?

Define what ARM vendors actually want from ACPI. Most ACPI functionality 
is entirely invisible to userspace. The enterprise-level functionality 
in the DSDT is all vendor-specific and exists primarily because of a 
Windows design decision[0], so there's no obvious requirement to do 
things the same way this time around. The other tables are meaningful, 
but also don't require the DSDT or a runtime ACPI interpreter.

The obvious compromise implementation would be to continue using DT for 
device discovery and just use ACPI as a means for providing static data. 
This would be a strict violation of the ACPI spec as it currently 
stands, but the only real change would be making the DSDT optional. Why 
would that not satisfy vendor requirements?

[0] Microsoft specced a mechanism for gluing WMI into ACPI, which means 
you can pretty much implement all your vendor magic in userspace rather 
than having to write a driver and get it signed

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

ACPI

[Linus Walleij]

On Mon, Nov 18, 2013 at 7:42 PM, Jon Masters <jonathan@jonmasters.org> wrote:

> Could we articulate a series of useful asks that would help with moving
> forward with ACPI? For example, it is clear that there needs to be
> more involvement in the standardization of ACPI (...)

One thing I think a bit about is ontology[1], what is written in that
spec and under what assumptions. I noticed from DSDT fragments
here and there that ACPI has no concept of pin control, but instead
adhere to the old fallacy of mixing this up with GPIO in the examples
I saw, and this would be good to have clarified, maybe I as a
subsystem maintainer need to go read some spec and provide
feedback on it?

For devicetree we have a bit of standardization in
Documentation/devicetree/bindings/pinctrl and if I'm not mistaken,
nothing of the sort exist in the ACPI spec.

The same can probably be said about slave DMA,
Documentation/devicetree/bindings/pinctrl?
Or regulators? Clocks? Runtime PM and D-states as
Arnd mentioned?

In which cases does the ACPI definitions of terms, paradigms and
ontologies match those if the kernel subsystems, and where will
we be shoehorned into somebody else's idea of the world, and
is there something we can do about it (i.e. influcence this).

Yours,
Linus Walleij

[1] Using this in the exact philosophical sense to be precise with
the problem I have, not trying to play smart.
Quote from Wikipedia:
" ontology deals with questions concerning what entities exist or
 can be said to exist, and how such entities can be grouped,
 related within a hierarchy, and subdivided according to similarities
 and differences"

ACPI

[Grant Likely]

On 24 Nov 2013 17:14, "Linus Walleij" <linus.walleij@linaro.org> wrote:
>
> On Mon, Nov 18, 2013 at 7:42 PM, Jon Masters <jonathan@jonmasters.org> wrote:
>
> > Could we articulate a series of useful asks that would help with moving
> > forward with ACPI? For example, it is clear that there needs to be
> > more involvement in the standardization of ACPI (...)
>
> One thing I think a bit about is ontology[1], what is written in that
> spec and under what assumptions. I noticed from DSDT fragments
> here and there that ACPI has no concept of pin control, but instead
> adhere to the old fallacy of mixing this up with GPIO in the examples
> I saw, and this would be good to have clarified, maybe I as a
> subsystem maintainer need to go read some spec and provide
> feedback on it?
>
> For devicetree we have a bit of standardization in
> Documentation/devicetree/bindings/pinctrl and if I'm not mistaken,
> nothing of the sort exist in the ACPI spec.

No, none of that exists in ACPI. We're looking at entirely new
territory for ACPI.

It seems there are two ways we can approach ACPI. 1) we could treat
ACPI exactly like DT and expect DT bindings to carry over verbatim
into the ACPI namespace. That means everything we've done with DT we
expect to show up in ACPI trees including clocks, regulators, pin
control, etc. Or, 2) assume that if ACPI is being used, then the
intent is to push responsibility for the platform as a whole
(system-wide details as opposed to individual devices) out of the
kernel.

The first option has the advantage of possibly being able to use DT
device drivers virtually unchanged because ACPI provides exactly the
same data. However, I expect that OEM vendors are actually after #2.
They are wanting the ability to abstract the platform sufficiently
enough that new hardware can be supported without explicitly working
with upstream[1][2].

I really don't know which is best here. Describing all the hardware
blocks is absolutely the right thing to do with DT. If ACPI does the
same, then I think a very strong requirement is for the bindings to be
*identical* to the DT ones (with the exception that cross-node
references will be of a different format).

If ACPI has to have different bindings, then I think we should push
back hard to not implement bindings for all of the platform
integration stuff (clock, regulators, etc). Don't even model them
since it would appear that the platform wants to be responsible for
all of them. Of course the downside here is that Linux gets to know
very little about the underlying platform. Things like i2c lmsensor
busses will possibly be unavailable.

[1] I'm Ignoring the other motivation which is that ACPI is the only
interface that Microsoft wants to use.
[2] The assumption being that new IP blocks for clocks or regulators
(for example) could be manipulated by AML without explicit Linux
device drivers.


>
> The same can probably be said about slave DMA,
> Documentation/devicetree/bindings/pinctrl?
> Or regulators? Clocks? Runtime PM and D-states as
> Arnd mentioned?
>
> In which cases does the ACPI definitions of terms, paradigms and
> ontologies match those if the kernel subsystems, and where will
> we be shoehorned into somebody else's idea of the world, and
> is there something we can do about it (i.e. influcence this).

The plus side is we do have a lot of influence here. ARM servers are
being built to run Linux. I don't know of any Microsoft plans, but
even if they plan to release a server OS, Linux is currently in the
driver seat.

g.

ACPI

[Matthew Garrett]

On Mon, Nov 25, 2013 at 12:42:13AM +0000, Grant Likely wrote:

> The plus side is we do have a lot of influence here. ARM servers are
> being built to run Linux. I don't know of any Microsoft plans, but
> even if they plan to release a server OS, Linux is currently in the
> driver seat.

We only have influence if the vendors are talking to us. Regardless of 
what we do in any standardisation bodies, if the vendors have already 
made decisions here then we have no influence at all.

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

ACPI

[Linus Walleij]

On Mon, Nov 25, 2013 at 1:42 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 24 Nov 2013 17:14, "Linus Walleij" <linus.walleij@linaro.org> wrote:

>> For devicetree we have a bit of standardization in
>> Documentation/devicetree/bindings/pinctrl and if I'm not mistaken,
>> nothing of the sort exist in the ACPI spec.
>
> No, none of that exists in ACPI. We're looking at entirely new
> territory for ACPI.
>
> It seems there are two ways we can approach ACPI. 1) we could treat
> ACPI exactly like DT and expect DT bindings to carry over verbatim
> into the ACPI namespace. That means everything we've done with DT we
> expect to show up in ACPI trees including clocks, regulators, pin
> control, etc. Or, 2) assume that if ACPI is being used, then the
> intent is to push responsibility for the platform as a whole
> (system-wide details as opposed to individual devices) out of the
> kernel.

Or (3): ACPI redefined on top of each subsystem. But I get
from the sound of this that this approach is not liked,
because (I assume?) we want to cut some corners.

Example from another architecture:
drivers/gpio/gpio-lynxpoint.c
with infrastructure in:
drivers/gpio/gpiolib-acpi.c

It is a "pure", embedded ACPI driver of the type that Intel is
pushing. They have been very helpful in integrating this
deeply with the GPIO subsystem and are now switching all
relevant drivers to using decriptors rather than GPIO numbers
for embedded x86 which is a big win.

So would ARM ACPI systems with GPIO drivers *not* use this
nice infrastructure ...? (Maybe not your stance but the
sound I hear from some places in this discussion.)

And I cannot see how Intels or anyones pin control, regulator,
clock etc drivers would be any different from this code.

Well, they have indicated that they would prefer to hide some
complex things behind an behind-the-scenes abstraction like
D-states or so, but I have my doubts about that approach,
they may prove me wrong.

Yours,
Linus Walleij

ACPI

[Grant Likely]

On Mon, Nov 25, 2013 at 11:07 AM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> On Mon, Nov 25, 2013 at 1:42 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
>> On 24 Nov 2013 17:14, "Linus Walleij" <linus.walleij@linaro.org> wrote:
>
>>> For devicetree we have a bit of standardization in
>>> Documentation/devicetree/bindings/pinctrl and if I'm not mistaken,
>>> nothing of the sort exist in the ACPI spec.
>>
>> No, none of that exists in ACPI. We're looking at entirely new
>> territory for ACPI.
>>
>> It seems there are two ways we can approach ACPI. 1) we could treat
>> ACPI exactly like DT and expect DT bindings to carry over verbatim
>> into the ACPI namespace. That means everything we've done with DT we
>> expect to show up in ACPI trees including clocks, regulators, pin
>> control, etc. Or, 2) assume that if ACPI is being used, then the
>> intent is to push responsibility for the platform as a whole
>> (system-wide details as opposed to individual devices) out of the
>> kernel.
>
> Or (3): ACPI redefined on top of each subsystem. But I get
> from the sound of this that this approach is not liked,
> because (I assume?) we want to cut some corners.
>
> Example from another architecture:
> drivers/gpio/gpio-lynxpoint.c
> with infrastructure in:
> drivers/gpio/gpiolib-acpi.c
>
> It is a "pure", embedded ACPI driver of the type that Intel is
> pushing. They have been very helpful in integrating this
> deeply with the GPIO subsystem and are now switching all
> relevant drivers to using decriptors rather than GPIO numbers
> for embedded x86 which is a big win.
>
> So would ARM ACPI systems with GPIO drivers *not* use this
> nice infrastructure ...? (Maybe not your stance but the
> sound I hear from some places in this discussion.)

No, that's not my stance. ACPI5 does define a GPIO address space and
it makes sense to work with that. When I say that the bindings be
identical between DT and ACPI implementations it is with the
understanding that DT or ACPI native references are used where
appropriate. ie. the DT version would use the gpios= property value,
but the ACPI implementation would use an ACPI native GPIO reference.

Regulators, clocks and pincontrol are all brand new areas. There is no
existing ACPI infrastructure or details in the spec on how to deal
with them. I honestly don't know what the best approach here is. Not
knowing enough about ACPI, I am concerned that the DT data model for
clocks, regulator, etc, bindings will interact badly with the ACPI
power management model.

> And I cannot see how Intels or anyones pin control, regulator,
> clock etc drivers would be any different from this code.
>
> Well, they have indicated that they would prefer to hide some
> complex things behind an behind-the-scenes abstraction like
> D-states or so, but I have my doubts about that approach,
> they may prove me wrong.

What I'm assuming here is that on ACPI the pinctrl setup and
management would be performed by the platform in AML methods so that
the kernel isn't aware of them at all. All it know is that it has a
(for example) SPI bus and as far as it is concerned the pins are
correctly attached when the SPI bus is active. My understanding is
that historically this is how ACPI has been used.

g.

ACPI

[Matthew Garrett]

On Mon, Nov 25, 2013 at 11:33:56AM +0000, Grant Likely wrote:

> What I'm assuming here is that on ACPI the pinctrl setup and
> management would be performed by the platform in AML methods so that
> the kernel isn't aware of them at all. All it know is that it has a
> (for example) SPI bus and as far as it is concerned the pins are
> correctly attached when the SPI bus is active. My understanding is
> that historically this is how ACPI has been used.

Pretty much. In the past ACPI implementations handled GPIO by providing 
methods that accessed hardware registers directly. I've seen DSDTs that 
implement i2c entirely in ASL. It's *very* common for hwmon devices to 
be hidden away behind some ACPI methods.

The obvious downside of this approach is that there's no real mechanism 
for allowing a real driver to access the hardware at the same time as 
the ACPI code, and as a consequence you're limited to whatever 
functionality is provided by the ACPI code.

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

ACPI

[Linus Walleij]

On Mon, Nov 25, 2013 at 4:41 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> In the past ACPI implementations handled GPIO by providing
> methods that accessed hardware registers directly. I've seen DSDTs that
> implement i2c entirely in ASL.

Is that common?

Since i2c is a slow bus, can be 100kHz or so, how does that
avoid locking the entire CPU while e.g. waiting for transactions on
the external bus to complete?

In I2C drivers we typically use completion IRQs so that we can
do other stuff when the I2C traffic is busy ...

I have a feeling we should not recommend ARM implementers
to go and do things like this.

Yours,
Linus Walleij

ACPI

[Grant Likely]

On Tue, Nov 26, 2013 at 12:43 PM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> On Mon, Nov 25, 2013 at 4:41 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>
>> In the past ACPI implementations handled GPIO by providing
>> methods that accessed hardware registers directly. I've seen DSDTs that
>> implement i2c entirely in ASL.
>
> Is that common?
>
> Since i2c is a slow bus, can be 100kHz or so, how does that
> avoid locking the entire CPU while e.g. waiting for transactions on
> the external bus to complete?
>
> In I2C drivers we typically use completion IRQs so that we can
> do other stuff when the I2C traffic is busy ...
>
> I have a feeling we should not recommend ARM implementers
> to go and do things like this.

ACPI5 defines a binding for serial busses (i2c & spi) which allows
real device drivers to drive the bus and allows ACPI and the kernel to
share the bus safely. Using that binding means some i2c devices can be
'owned' by ACPI and others owned by the kernel.

g.

ACPI

[Jürgen Beisert]

On Tuesday 26 November 2013 13:55:10 Grant Likely wrote:
> On Tue, Nov 26, 2013 at 12:43 PM, Linus Walleij
>
> <linus.walleij@linaro.org> wrote:
> > On Mon, Nov 25, 2013 at 4:41 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> >> In the past ACPI implementations handled GPIO by providing
> >> methods that accessed hardware registers directly. I've seen DSDTs that
> >> implement i2c entirely in ASL.
> >
> > Is that common?
> >
> > Since i2c is a slow bus, can be 100kHz or so, how does that
> > avoid locking the entire CPU while e.g. waiting for transactions on
> > the external bus to complete?
> >
> > In I2C drivers we typically use completion IRQs so that we can
> > do other stuff when the I2C traffic is busy ...
> >
> > I have a feeling we should not recommend ARM implementers
> > to go and do things like this.
>
> ACPI5 defines a binding for serial busses (i2c & spi) which allows
> real device drivers to drive the bus and allows ACPI and the kernel to
> share the bus safely. Using that binding means some i2c devices can be
> 'owned' by ACPI and others owned by the kernel.

This means bus locking. And Linus' other question about CPU locking while ACPI
drives the I2C bus?

jbe
-- 
Pengutronix e.K. ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| Juergen Beisert ? ? ? ? ? ? |
Linux Solutions for Science and Industry ? ? ?| http://www.pengutronix.de/  |

ACPI

[Grant Likely]

On Tue, 26 Nov 2013 14:43:30 +0100, J??rgen Beisert <jbe@pengutronix.de> wrote:
> On Tuesday 26 November 2013 13:55:10 Grant Likely wrote:
> > On Tue, Nov 26, 2013 at 12:43 PM, Linus Walleij
> >
> > <linus.walleij@linaro.org> wrote:
> > > On Mon, Nov 25, 2013 at 4:41 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > >> In the past ACPI implementations handled GPIO by providing
> > >> methods that accessed hardware registers directly. I've seen DSDTs that
> > >> implement i2c entirely in ASL.
> > >
> > > Is that common?
> > >
> > > Since i2c is a slow bus, can be 100kHz or so, how does that
> > > avoid locking the entire CPU while e.g. waiting for transactions on
> > > the external bus to complete?
> > >
> > > In I2C drivers we typically use completion IRQs so that we can
> > > do other stuff when the I2C traffic is busy ...
> > >
> > > I have a feeling we should not recommend ARM implementers
> > > to go and do things like this.
> >
> > ACPI5 defines a binding for serial busses (i2c & spi) which allows
> > real device drivers to drive the bus and allows ACPI and the kernel to
> > share the bus safely. Using that binding means some i2c devices can be
> > 'owned' by ACPI and others owned by the kernel.
> 
> This means bus locking. And Linus' other question about CPU locking while ACPI
> drives the I2C bus?

It means Linux owns the I2C bus and AML methods request the OS to
perform a transaction on its behalf.

g.

ACPI

[Linus Walleij]

On Wed, Nov 27, 2013 at 1:25 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Tue, 26 Nov 2013 14:43:30 +0100, J?rgen Beisert <jbe@pengutronix.de> wrote:
>> On Tuesday 26 November 2013 13:55:10 Grant Likely wrote:
>> > On Tue, Nov 26, 2013 at 12:43 PM, Linus Walleij

>> > > Since i2c is a slow bus, can be 100kHz or so, how does that
>> > > avoid locking the entire CPU while e.g. waiting for transactions on
>> > > the external bus to complete?
(...)
>> >
>> > ACPI5 defines a binding for serial busses (i2c & spi) which allows
>> > real device drivers to drive the bus and allows ACPI and the kernel to
>> > share the bus safely. Using that binding means some i2c devices can be
>> > 'owned' by ACPI and others owned by the kernel.
>>
>> This means bus locking. And Linus' other question about CPU locking while ACPI
>> drives the I2C bus?
>
> It means Linux owns the I2C bus and AML methods request the OS to
> perform a transaction on its behalf.

Aha OK so that is consistent with how control of GPIOs (and I guess
other things as well) are partitioned between the kernel and ACPI AML
methods. And it's not so bad, this is manageable.

Yours,
Linus Walleij

ACPI

[Matthew Garrett]

On Tue, Nov 26, 2013 at 12:55:10PM +0000, Grant Likely wrote:
> On Tue, Nov 26, 2013 at 12:43 PM, Linus Walleij
> <linus.walleij@linaro.org> wrote:
> > I have a feeling we should not recommend ARM implementers
> > to go and do things like this.
> 
> ACPI5 defines a binding for serial busses (i2c & spi) which allows
> real device drivers to drive the bus and allows ACPI and the kernel to
> share the bus safely. Using that binding means some i2c devices can be
> 'owned' by ACPI and others owned by the kernel.

Right, we shouldn't see a problem in this specific case. But it does 
leave a wider philosophical concern - there are still components that 
can't be exposed to the OS via ACPI in standardised ways, and the 
traditional way of dealing with that on x86 is to just add the 
functionality via ASL. It seems that we have three basic options:

1) Encourage vendors to add functionality to their DSDTs
2) Encourage vendors to use existing kernel functionality, exposing 
information via either DT-in-ACPI or some other custom method
3) Encourage vendors to continue using DT until this functionality is 
standardised

Being consistent about our recommendations here would probably be 
helpful, but it seems like we don't have any kind of thought out story 
yet. That seems like a problem.

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

ACPI

[Matt Sealey]

On Tue, Nov 26, 2013 at 12:33 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Tue, Nov 26, 2013 at 12:55:10PM +0000, Grant Likely wrote:
>> On Tue, Nov 26, 2013 at 12:43 PM, Linus Walleij
>> <linus.walleij@linaro.org> wrote:
>> > I have a feeling we should not recommend ARM implementers
>> > to go and do things like this.
>>
>> ACPI5 defines a binding for serial busses (i2c & spi) which allows
>> real device drivers to drive the bus and allows ACPI and the kernel to
>> share the bus safely. Using that binding means some i2c devices can be
>> 'owned' by ACPI and others owned by the kernel.
>
> Right, we shouldn't see a problem in this specific case. But it does
> leave a wider philosophical concern - there are still components that
> can't be exposed to the OS via ACPI in standardised ways, and the
> traditional way of dealing with that on x86 is to just add the
> functionality via ASL. It seems that we have three basic options:
>
> 1) Encourage vendors to add functionality to their DSDTs
> 2) Encourage vendors to use existing kernel functionality, exposing
> information via either DT-in-ACPI or some other custom method

I have a real problem with the concept of putting device trees inside
ACPI, while still relying on this consensus that the preferred boot
method will also be UEFI.

Until Linux boots from UEFI on ARM without being a consumer of the
services that UEFI actually offers. Every platform in the Linaro tree
boots uImages and zImages and does not pass any UEFI System Table or
any other services to Linux, so it has no clue it booted from UEFI or
U-Boot - just that it was handed a device tree and everything works
because the device tree implementation works. UEFI is basically gone.

Before stabbing around adding ACPI and then having DT-in-ACPI isn't
there a use case for an an ARM Linux kernel actually being a good
citizen of UEFI?

How are they planning to get the ACPI tables in the first place
without going through UEFI to get it? I may not have been paying close
enough attention, I am certainly not invited to the secret meetings of
SPECTRE where this has already been implemented and tested properly,
but I don't see any evidence of it.. not even an inkling of it.

Having UEFI pass along the DT as a configuration table as well as ACPI
tables should be the first order of business. It needn't be
DT-specific either - there's no reason that specific configuration
table can't define a thousand ways to boot Linux on ARM. But one or
two might be better for the sanity of the Linux kernel guys. In fact,
because UEFI hands information in the early boot process to the
'application' (being the kernel), and has a very well defined API, it
would remove the need for weird out of band stuff like /memreserve/
entries in the DT and simplify and make the Linux early boot process
more robust and debuggable.

> 3) Encourage vendors to continue using DT until this functionality is
> standardised

I would attempt to encourage vendors to use DT by making UEFI actually
give a crap about DT if possible. Right now ACPI seems to be posited
for three reasons;

1) Existing code is around that drives certain logic common on a bunch
of server boards and nobody wants to write drivers for them *again*,
especially since there is a distinct advantage to hidin^H^H^H^H^H
abstracting the actual implementation from Linux (fan controllers etc.
could be done in hundreds of different ways) in terms of product
safety, product reliability, and kernel stability for companies like
Red Hat.

2) Because you can do fancy 'scripting' as well as bus and device
configuration abstraction on top of description.

3) Because there seems to be an absolutely moronic assumption that the
best way to get an ARMv8 server box on the market is take an existing
server design and just drop an ARM SoC into it and the above existing
code should "drop in" in that case.

Reasons one and two are *good enough reason to use ACPI* - but only if
there's a worthwhile application for it, as previously stated by
others. The one thing that got thrown in the weeds going Flattened
Device Tree (that didn't make sense because of the ABI, but.. could
have been solved) was some kind of standardized firmware interface you
could call - and packages/protocols and some standardized way of
accessing fixed function or otherwise needfully abstracted hardware
components that have a life of their own and cannot be statically
described.

But I can't think of a reason why an extension or companion to PSCI
couldn't do it, and why you WOULDN'T want to do this as an API
implemented via a secure monitor interface which is architecturally
defined on ARM where security extensions are present. I can't imagine
a reason why it couldn't be done over IPMI to some microcontroller or
dedicated external component, for the case of fans and chassis
components and tedious other stuff.

I keep hearing people talk about reason 3, and I gotta say.. if that's
the reason ACPI is being pushed out by the secret cabal.. May Glob
help them, if it's true, because they obviously have whacked-out
poo-brain.

> Being consistent about our recommendations here would probably be
> helpful, but it seems like we don't have any kind of thought out story
> yet. That seems like a problem.

+100.

I want to know how they're expecting to get hold of the magic they
need to have ACPI support work, first, and why that isn't solved in
other ways, and at least one use case where secure firmware and a
device tree can't do it in the same - or better and more secure - way.
It's all well and good looking to write a spec.. what should be going
on is designing a server platform, identifying the use cases as you go
through the design, and not just placing arbitrary stuff on a list
because that's how it's already implemented over there. ACPI exists
because it needed to solve a very specific x86-related problem.

Does it solve any ARM-related problems that aren't already solved or
capable of being solved with current methodologies?

How did IBM and Freescale get by for the past 6 years without ACPI on
POWER? Doesn't that inform anyone of any reasons why ACPI isn't
strictly necessary?

-- 
Matt Sealey <neko@bakuhatsu.net>

ACPI

[Matthew Garrett]

On Tue, Nov 26, 2013 at 05:11:23PM -0600, Matt Sealey wrote:

> Before stabbing around adding ACPI and then having DT-in-ACPI isn't
> there a use case for an an ARM Linux kernel actually being a good
> citizen of UEFI?

That's work in progress. Patches have been posted and are getting pretty 
close to being mergeable. You can already run VExpress with UEFI.

> Having UEFI pass along the DT as a configuration table as well as ACPI
> tables should be the first order of business. It needn't be
> DT-specific either - there's no reason that specific configuration
> table can't define a thousand ways to boot Linux on ARM. But one or
> two might be better for the sanity of the Linux kernel guys. In fact,
> because UEFI hands information in the early boot process to the
> 'application' (being the kernel), and has a very well defined API, it
> would remove the need for weird out of band stuff like /memreserve/
> entries in the DT and simplify and make the Linux early boot process
> more robust and debuggable.

Passing both is somewhat problematic - if one is supposed to be 
sufficient, why pass the other? It'd be pretty easy to end up with skew 
between them, and unless we're clear on what happens in the event of 
conflicting information then it's going to end badly.

> 1) Existing code is around that drives certain logic common on a bunch
> of server boards and nobody wants to write drivers for them *again*,
> especially since there is a distinct advantage to hidin^H^H^H^H^H
> abstracting the actual implementation from Linux (fan controllers etc.
> could be done in hundreds of different ways) in terms of product
> safety, product reliability, and kernel stability for companies like
> Red Hat.

Servers rarely use ACPI for thermal control, but yeah, I take your 
point.

> 2) Because you can do fancy 'scripting' as well as bus and device
> configuration abstraction on top of description.

Sure.

> 3) Because there seems to be an absolutely moronic assumption that the
> best way to get an ARMv8 server box on the market is take an existing
> server design and just drop an ARM SoC into it and the above existing
> code should "drop in" in that case.

Well, so far we had any indication as to whether or not anyone's 
planning on doing that. I suspect it could be made to work, the question 
is how invasive the kernel changes would be.

> But I can't think of a reason why an extension or companion to PSCI
> couldn't do it, and why you WOULDN'T want to do this as an API
> implemented via a secure monitor interface which is architecturally
> defined on ARM where security extensions are present. I can't imagine
> a reason why it couldn't be done over IPMI to some microcontroller or
> dedicated external component, for the case of fans and chassis
> components and tedious other stuff.

Primarily because people want solutions that aren't tied to having an 
entirely separate computer running its own embedded OS. The likely 
alternative to doing things in ACPI would be to do them in TrustZone, 
and let's not encourage that. A significant proportion of the bugs we 
see on x86 are down to SMM code that we can't see, let alone debug. It's 
much easier to handle bugs in code that runs in the same context as the 
OS.

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

ACPI

[Catalin Marinas]

On 26 November 2013 23:32, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Tue, Nov 26, 2013 at 05:11:23PM -0600, Matt Sealey wrote:
>> But I can't think of a reason why an extension or companion to PSCI
>> couldn't do it, and why you WOULDN'T want to do this as an API
>> implemented via a secure monitor interface which is architecturally
>> defined on ARM where security extensions are present. I can't imagine
>> a reason why it couldn't be done over IPMI to some microcontroller or
>> dedicated external component, for the case of fans and chassis
>> components and tedious other stuff.
>
> Primarily because people want solutions that aren't tied to having an
> entirely separate computer running its own embedded OS. The likely
> alternative to doing things in ACPI would be to do them in TrustZone,
> and let's not encourage that. A significant proportion of the bugs we
> see on x86 are down to SMM code that we can't see, let alone debug. It's
> much easier to handle bugs in code that runs in the same context as the
> OS.

I agree. While I'm pushing for standard firmware interfaces like PSCI
on ARMv8 (Power State Coordination Interface for those who haven't
heard of it yet), I would limit it to things that can only be done
(safely) in secure monitor mode (EL3) like CPU power management (and
that's hotplug/idle, not DVFS).

-- 
Catalin

ACPI

[Nicolas Pitre]

On Wed, 27 Nov 2013, Catalin Marinas wrote:

> On 26 November 2013 23:32, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > On Tue, Nov 26, 2013 at 05:11:23PM -0600, Matt Sealey wrote:
> >> But I can't think of a reason why an extension or companion to PSCI
> >> couldn't do it, and why you WOULDN'T want to do this as an API
> >> implemented via a secure monitor interface which is architecturally
> >> defined on ARM where security extensions are present. I can't imagine
> >> a reason why it couldn't be done over IPMI to some microcontroller or
> >> dedicated external component, for the case of fans and chassis
> >> components and tedious other stuff.
> >
> > Primarily because people want solutions that aren't tied to having an
> > entirely separate computer running its own embedded OS. The likely
> > alternative to doing things in ACPI would be to do them in TrustZone,
> > and let's not encourage that. A significant proportion of the bugs we
> > see on x86 are down to SMM code that we can't see, let alone debug. It's
> > much easier to handle bugs in code that runs in the same context as the
> > OS.
> 
> I agree. While I'm pushing for standard firmware interfaces like PSCI
> on ARMv8 (Power State Coordination Interface for those who haven't
> heard of it yet), I would limit it to things that can only be done
> (safely) in secure monitor mode (EL3) like CPU power management (and
> that's hotplug/idle, not DVFS).

And as we both know, even hotplug/idle may get quite complicated and bug 
prone in some circumstances.


Nicolas

ACPI

[Matt Sealey]

On Tue, Nov 26, 2013 at 5:32 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Tue, Nov 26, 2013 at 05:11:23PM -0600, Matt Sealey wrote:
>
>> Before stabbing around adding ACPI and then having DT-in-ACPI isn't
>> there a use case for an an ARM Linux kernel actually being a good
>> citizen of UEFI?
>
> That's work in progress. Patches have been posted and are getting pretty
> close to being mergeable. You can already run VExpress with UEFI.
>
>> Having UEFI pass along the DT as a configuration table as well as ACPI
>> tables should be the first order of business. It needn't be
>> DT-specific either - there's no reason that specific configuration
>> table can't define a thousand ways to boot Linux on ARM. But one or
>> two might be better for the sanity of the Linux kernel guys. In fact,
>> because UEFI hands information in the early boot process to the
>> 'application' (being the kernel), and has a very well defined API, it
>> would remove the need for weird out of band stuff like /memreserve/
>> entries in the DT and simplify and make the Linux early boot process
>> more robust and debuggable.
>
> Passing both is somewhat problematic - if one is supposed to be
> sufficient, why pass the other? It'd be pretty easy to end up with skew
> between them, and unless we're clear on what happens in the event of
> conflicting information then it's going to end badly.

Here's a theory; always pass a basic device tree that describes a
system. You know it *is* possible to get something running simply by
having

/ {
 model = "ACPI";
 cpu {
    cpu at 0 {
      device_type = "cpu";
      compatible = "arm,armv7";
    };
 };
 memory at 0 {
     device_type = "memory";
     reg = <0x0000000 0x20000000>;
 };
};

Give or take some address-cells, size-cells.. what you've lost is
interrupt controllers and whatever else, but then what you need is
some way of having a system that boots with DT somehow break into
loading ACPI information.

Right now the best way of doing that - if you're in a server
environment anyway and dictate UEFI - is the ACPI configuration table
off the System Table.

>> 2) Because you can do fancy 'scripting' as well as bus and device
>> configuration abstraction on top of description.
>
> Sure.
>
>> 3) Because there seems to be an absolutely moronic assumption that the
>> best way to get an ARMv8 server box on the market is take an existing
>> server design and just drop an ARM SoC into it and the above existing
>> code should "drop in" in that case.
>
> Well, so far we had any indication as to whether or not anyone's
> planning on doing that. I suspect it could be made to work, the question
> is how invasive the kernel changes would be.

It could be made to work; it's a stupid, stupid idea that throws any
of the benefits of using ARM in the first place out of the window. Why
would anyone do that?

>> But I can't think of a reason why an extension or companion to PSCI
>> couldn't do it, and why you WOULDN'T want to do this as an API
>> implemented via a secure monitor interface which is architecturally
>> defined on ARM where security extensions are present. I can't imagine
>> a reason why it couldn't be done over IPMI to some microcontroller or
>> dedicated external component, for the case of fans and chassis
>> components and tedious other stuff.
>
> Primarily because people want solutions that aren't tied to having an
> entirely separate computer running its own embedded OS.

Even though it is almost an absolutely hard requirement for a
production server environment to have some kind of out of band,
lights-out management implementation?

> alternative to doing things in ACPI would be to do them in TrustZone,
> and let's not encourage that.

Why not? It's the best method. Every platform has some teething
issues.. needing some time to mature. What might be a reasonable
method, and I can guarantee these will exist (Calxeda..?) is to
implement a tiny shim in TrustZone which gives an internal OOB
processor a kick to do the real work. It may have a highly restricted
address space (power control, DRAM, peripherals that it shares with
the apps processor) and be doing thermal management and whatever else,
too.. it is a solution that every server (x86, SPARC, etc.) I've ever
bought, sold or maintained for customers and in-house everywhere I've
worked has had.

What makes ARM servers so different?

> see on x86 are down to SMM code that we can't see, let alone debug. It's
> much easier to handle bugs in code that runs in the same context as the
> OS.

It really depends what the use case is... so far, none provided.

Ta,
Matt <neko@bakuhatsu.net>

ACPI

[Jon Masters]

On 11/27/2013 03:21 PM, Matt Sealey wrote:
> On Tue, Nov 26, 2013 at 5:32 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>> On Tue, Nov 26, 2013 at 05:11:23PM -0600, Matt Sealey wrote:
>>
>>> Before stabbing around adding ACPI and then having DT-in-ACPI isn't
>>> there a use case for an an ARM Linux kernel actually being a good
>>> citizen of UEFI?
>>
>> That's work in progress. Patches have been posted and are getting pretty
>> close to being mergeable. You can already run VExpress with UEFI.

Indeed. Mark Salter has done some great work porting Roy Franz's initial
UEFI shim to AArch64, and we have Fedora 19 Remix images that boot using
UEFI (a custom EDK2 build with the mmio virtio patches that are
currently in revision 4 for review upstream in the Ovmf package) today
that you can download from the Fedora wiki for the FVP model:

http://fedoraproject.org/wiki/Architectures/ARM/AArch64/QuickStart

UEFI specifies passing the ACPI root pointers in as part of the standard
interface and this will be the means through which the tables are
provided on AArch64 systems - per the UEFI 2.4 specification.

<snip>

> Right now the best way of doing that - if you're in a server
> environment anyway and dictate UEFI - is the ACPI configuration table
> off the System Table.

Indeed, this is indeed a feature of the EFI system table.

<snip>

>>> 3) Because there seems to be an absolutely moronic assumption

^^^ Is of course opinion. There are a large and growing number of
corporations who have already committed billions of dollars to this
"assumption". I think ARM is a very versatile (pun intended) and capable
architecture with many different use cases. One of them is in server
designs that look a lot like other architectures, but with an
alternative CPU in place. This leverages huge amounts of existing
capability and expertise. Perhaps it is not the ideal way given a blank
sheet of paper but there *isn't* a blank sheet. Not when you factor in
vendors having existing tooling, development teams, management software,
and an entire industry that is built the "traditional" way.

<snip>

> It could be made to work; it's a stupid, stupid idea that throws any
> of the benefits of using ARM in the first place out of the window. Why
> would anyone do that?

Because a lot of these vendors are used to doing things the existing
way. It's not a purely technical decision (if it were, we'd probably
have a global electrical system on a single frequency and voltage, all
drive on the same side of the road, etc.) but it's based on vendors
entering the ARM space and seeking to make it fit into what they know.
It doesn't "throw any of the benefits of using ARM out of the window".
That's hyperbole. It "throws *some* of the benefits of using ARM out of
the window" in the spirit of a platform these folks will work with.

Think about it in the same way that many other things in life are
horrible compromises. It's seldom about having the best technology.
Ultimately the DeviceTree vs. DSDT thing is just data (yes, ACPI will
need new bindings, revisions, and so on). Some folks will go one way,
others (many server folks) will go the other. But beyond the data piece,
the runtime power management and PSCI discussion is very important.
Nobody thinks ACPI's notion of power states adequately reflects the full
potential for the platform, but this is one reason the governance of
ACPI was adjusted to allow for changes to be made.

>>> But I can't think of a reason why an extension or companion to PSCI
>>> couldn't do it, and why you WOULDN'T want to do this as an API
>>> implemented via a secure monitor interface which is architecturally
>>> defined on ARM where security extensions are present. I can't imagine
>>> a reason why it couldn't be done over IPMI to some microcontroller or
>>> dedicated external component, for the case of fans and chassis
>>> components and tedious other stuff.
>>
>> Primarily because people want solutions that aren't tied to having an
>> entirely separate computer running its own embedded OS.
> 
> Even though it is almost an absolutely hard requirement for a
> production server environment to have some kind of out of band,
> lights-out management implementation?

Most v8 server systems will have a full TEE running underneath, or
separate management controller cores that do the management. Or both.
There are many of us with an interest in seeing a strong Open Source TEE
available that can be consumed by those wanting to implement various
Secure World features on server systems using FLOSS.

Btw, for the record, I have (once again) had many calls with many folks
over the last week, impressing upon them the need to (once again) get
the standardization stuff more openly accessible to everyone. All I can
say is that I am "happy" to be typecast (if really necessary) as some
Dr. Evil character, if that makes people feel better about life, but I
am trying to get those involved in these pieces to be more public. My
monocle wearing white cat (Mr. Bigglesworth) sends greetings.

Jon.

ACPI

[Stefano Stabellini]

On Tue, 26 Nov 2013, Matthew Garrett wrote:
> On Tue, Nov 26, 2013 at 05:11:23PM -0600, Matt Sealey wrote:
> 
> > Before stabbing around adding ACPI and then having DT-in-ACPI isn't
> > there a use case for an an ARM Linux kernel actually being a good
> > citizen of UEFI?
> 
> That's work in progress. Patches have been posted and are getting pretty 
> close to being mergeable. You can already run VExpress with UEFI.
> 
> > Having UEFI pass along the DT as a configuration table as well as ACPI
> > tables should be the first order of business. It needn't be
> > DT-specific either - there's no reason that specific configuration
> > table can't define a thousand ways to boot Linux on ARM. But one or
> > two might be better for the sanity of the Linux kernel guys. In fact,
> > because UEFI hands information in the early boot process to the
> > 'application' (being the kernel), and has a very well defined API, it
> > would remove the need for weird out of band stuff like /memreserve/
> > entries in the DT and simplify and make the Linux early boot process
> > more robust and debuggable.
> 
> Passing both is somewhat problematic - if one is supposed to be 
> sufficient, why pass the other? It'd be pretty easy to end up with skew 
> between them, and unless we're clear on what happens in the event of 
> conflicting information then it's going to end badly.

Because I think that it is likely that we'll be able to convince them
that device tree is the right thing to do right now for Linux, Xen,
BSDes, etc.  However they might want to support ACPI in the future, if
nothing else to get other proprietary operating systems running.
So at some point one or more SoCs are going to come out with both.

In that case, I think that we should use the one we know has better
support in the kernel, that at the moment is device tree but in the
future might change.

ACPI

[Matthew Garrett]

On Thu, Nov 28, 2013 at 06:26:11PM +0000, Stefano Stabellini wrote:

> In that case, I think that we should use the one we know has better
> support in the kernel, that at the moment is device tree but in the
> future might change.

We can't just flip this - systems that shipped with valid DT but broken 
ACPI would stop working. 

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

ACPI

[Stefano Stabellini]

On Thu, 28 Nov 2013, Matthew Garrett wrote:
> On Thu, Nov 28, 2013 at 06:26:11PM +0000, Stefano Stabellini wrote:
> 
> > In that case, I think that we should use the one we know has better
> > support in the kernel, that at the moment is device tree but in the
> > future might change.
> 
> We can't just flip this - systems that shipped with valid DT but broken 
> ACPI would stop working. 

I think that the switch should be on a per-platform basis.

ACPI

[Grant Likely]

On Tue, 26 Nov 2013 17:11:23 -0600, Matt Sealey <neko@bakuhatsu.net> wrote:
> On Tue, Nov 26, 2013 at 12:33 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > On Tue, Nov 26, 2013 at 12:55:10PM +0000, Grant Likely wrote:
> >> On Tue, Nov 26, 2013 at 12:43 PM, Linus Walleij
> >> <linus.walleij@linaro.org> wrote:
> >> > I have a feeling we should not recommend ARM implementers
> >> > to go and do things like this.
> >>
> >> ACPI5 defines a binding for serial busses (i2c & spi) which allows
> >> real device drivers to drive the bus and allows ACPI and the kernel to
> >> share the bus safely. Using that binding means some i2c devices can be
> >> 'owned' by ACPI and others owned by the kernel.
> >
> > Right, we shouldn't see a problem in this specific case. But it does
> > leave a wider philosophical concern - there are still components that
> > can't be exposed to the OS via ACPI in standardised ways, and the
> > traditional way of dealing with that on x86 is to just add the
> > functionality via ASL. It seems that we have three basic options:
> >
> > 1) Encourage vendors to add functionality to their DSDTs
> > 2) Encourage vendors to use existing kernel functionality, exposing
> > information via either DT-in-ACPI or some other custom method
> 
> I have a real problem with the concept of putting device trees inside
> ACPI, while still relying on this consensus that the preferred boot
> method will also be UEFI.

ACPI and UEFI are completely separate things. UEFI happily passes a DT
to the Linux kernel today, and the code to do so is in the UEFI
Tianocore project. (search for LinuxLoader).

There are changes that need to be made here such as storing the DT
pointer in the UEFI system table so that firmware can directly provide a
DT which either GRUB or the Linux UEFI stub can pick up, but that is a
relatively uncontroversial detail.

> Until Linux boots from UEFI on ARM without being a consumer of the
> services that UEFI actually offers. Every platform in the Linaro tree
> boots uImages and zImages and does not pass any UEFI System Table or
> any other services to Linux, so it has no clue it booted from UEFI or
> U-Boot - just that it was handed a device tree and everything works
> because the device tree implementation works. UEFI is basically gone.

Again, runtime services works and has no bearing on ACPI. Runtime
services allows Linux to do three things: query/adjust system time,
query/adjust boot variables, provide UEFI with a "capsule" which is
mostly used for updating firmware. That's it. It's there so that an
operating system can manipulate what the system does on the next boot.
The patches to support runtime services are pretty much complete and are
out for review.[1]

[1] http://lwn.net/Articles/569665/

If you're not comfortable with keeping the runtime portion of UEFI
around, no problem; it can be turned off. For some users (general
purpose machines running general purpose distributions in particular) it
is important.

> Before stabbing around adding ACPI and then having DT-in-ACPI isn't
> there a use case for an an ARM Linux kernel actually being a good
> citizen of UEFI?
> 
> How are they planning to get the ACPI tables in the first place
> without going through UEFI to get it? I may not have been paying close
> enough attention, I am certainly not invited to the secret meetings of
> SPECTRE where this has already been implemented and tested properly,
> but I don't see any evidence of it.. not even an inkling of it.

All of the implementation is going on in the open and has nothing to do
with the vendor meetings that Jon and I have been involved with. Al
Stone is leading the Linaro ACPI team, and Leif Leidholm is leading the
UEFI team. Both teams are posting patches publically.

ACPI is obtained from UEFI by reading the UEFI system table. This is a
memory mapped block of UUID/Pointer pairs available right at OS entry
time. The kernel obtains the ACPI pointer by searching for the ACPI UUID
in the system table.

> Having UEFI pass along the DT as a configuration table as well as ACPI
> tables should be the first order of business. It needn't be
> DT-specific either - there's no reason that specific configuration
> table can't define a thousand ways to boot Linux on ARM. But one or
> two might be better for the sanity of the Linux kernel guys. In fact,
> because UEFI hands information in the early boot process to the
> 'application' (being the kernel), and has a very well defined API, it
> would remove the need for weird out of band stuff like /memreserve/
> entries in the DT and simplify and make the Linux early boot process
> more robust and debuggable.

No problem here. DT and ACPI can actually coexist in the system table,
but in all the technical conversations I've had with Leif, Al, and
others we've pretty much agreed that an OS should use the data from one
or the other, but not try to parse both.

> 
> > 3) Encourage vendors to continue using DT until this functionality is
> > standardised
> 
> I would attempt to encourage vendors to use DT by making UEFI actually
> give a crap about DT if possible. Right now ACPI seems to be posited
> for three reasons;

Should be no problem. DT support with libfdt is already in tianocore
(though not part of the standard) and Leif is going to be publishing a
whitepaper with a specific UUID for providing a DT via the system
table (which doesn't need to be part of the standard).

> 1) Existing code is around that drives certain logic common on a bunch
> of server boards and nobody wants to write drivers for them *again*,
> especially since there is a distinct advantage to hidin^H^H^H^H^H
> abstracting the actual implementation from Linux (fan controllers etc.
> could be done in hundreds of different ways) in terms of product
> safety, product reliability, and kernel stability for companies like
> Red Hat.
>
> 2) Because you can do fancy 'scripting' as well as bus and device
> configuration abstraction on top of description.
> 
> 3) Because there seems to be an absolutely moronic assumption that the
> best way to get an ARMv8 server box on the market is take an existing
> server design and just drop an ARM SoC into it and the above existing
> code should "drop in" in that case.

To be honest, none of the three above arguments have come up in any of
the discussions I've been a party to. Instead, I've heard the following
concerns from vendors:

1) The embedded AML methods are useful for getting an existing OS
release to boot on new hardware that does things differently. (note:
this is about booting to a usable state, not necessarily fully
supported; there is still the assumption that 3rd party device drivers
may need to be installed after boot).

2) Existing tooling and management interfaces. This is almost like
reasons 1 & 3 above, but rather than being about describing hardware, it
is about being able to use the same development, testing and remote
management software on both x86 and ARM platforms. They are already up
and running based on a UEFI/ACPI stack and would like to continue to do
exactly the same thing on ARM.

3) Windows. They want one interface that works for both Windows and
Linux. Microsoft certainly haven't made any comments about whether or
not they will have an ARM server product, but if they do then the
requirement will be ACPI. They don't want to rule out a market segments
if they don't have to.

> 
> Reasons one and two are *good enough reason to use ACPI* - but only if
> there's a worthwhile application for it, as previously stated by
> others. The one thing that got thrown in the weeds going Flattened
> Device Tree (that didn't make sense because of the ABI, but.. could
> have been solved) was some kind of standardized firmware interface you
> could call - and packages/protocols and some standardized way of
> accessing fixed function or otherwise needfully abstracted hardware
> components that have a life of their own and cannot be statically
> described.

In FDT land the direction has been anything weird needs a device driver.
We're not going to try and abstract hardware interfaces. That's why I've
been resistant to adding any kind of bytecode language to FDT. This is
the big difference between ACPI and FDT for the kernel.

> But I can't think of a reason why an extension or companion to PSCI
> couldn't do it, and why you WOULDN'T want to do this as an API
> implemented via a secure monitor interface which is architecturally
> defined on ARM where security extensions are present. I can't imagine
> a reason why it couldn't be done over IPMI to some microcontroller or
> dedicated external component, for the case of fans and chassis
> components and tedious other stuff.

The problem here is that it becomes even further out of Linux's control.
At least with ACPI the bytecode runs at the pleasure of the kernel and
it can trace what is going on. At least with IPMI to a BMC it is on a
separate processor, but encouraging PM to be stuffed into TrustZone is a
bad precidence. It starts to look a lot like the bad old days of APM
before ACPI.

> I keep hearing people talk about reason 3, and I gotta say.. if that's
> the reason ACPI is being pushed out by the secret cabal.. May Glob
> help them, if it's true, because they obviously have whacked-out
> poo-brain.

Regarding the "secret cabal", they (myself included) don't actually have
any power over the Linux development process. They are representatives
of vendors who intend to produce products. Those products are intended
to run Linux. If they don't work with us to get good support for their
platform in mainline then it is going to affect how well their hardware
works. They have made the decision to persue an ACPI solution, mostly
for the reasons I listed above. Some have joined Linaro and are working
things out there (and therefore in public). Some have internal engineers
working on it. Some have done both.

Regardless, they *still* need to work with upstream to get their
hardware supported. The most important thing that we can do right now is
make that message clear. ACPI not ready for merging? Then we recommend
using FDT until we figure out what ACPI should look like. They want to
work on ACPI? Then we recommend posting draft patches and not lock down
their ACPI implementation until support is mainlined.

> > Being consistent about our recommendations here would probably be
> > helpful, but it seems like we don't have any kind of thought out story
> > yet. That seems like a problem.
> 
> +100.

yup

g.

ACPI

[Matt Sealey]

On Wed, Nov 27, 2013 at 8:16 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Tue, 26 Nov 2013 17:11:23 -0600, Matt Sealey <neko@bakuhatsu.net> wrote:
>> On Tue, Nov 26, 2013 at 12:33 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>> > On Tue, Nov 26, 2013 at 12:55:10PM +0000, Grant Likely wrote:
>> >> On Tue, Nov 26, 2013 at 12:43 PM, Linus Walleij
>> >> <linus.walleij@linaro.org> wrote:
>> >> > I have a feeling we should not recommend ARM implementers
>> >> > to go and do things like this.
>>
>> I have a real problem with the concept of putting device trees inside
>> ACPI, while still relying on this consensus that the preferred boot
>> method will also be UEFI.
>
> ACPI and UEFI are completely separate things.

Good lord, Grant. I have a working knowledge of both..

I got told to be concise, it turns out being concise just makes people
miss the point.

The easiest way to get hold of your ACPI tables on UEFI is from the
ACPI configuration table stored as one of the configurable tables off
the UEFI System Table which is supposed to be passed to the OS on
boot. Otherwise it has absolutely no access to Boot Services table or
Runtime Services Table or anything.

UEFI hands control to an entry point of a PE/COFF executable (the only
thing it's required to know how to load) passing the pointer to the
System Table as it's second argument, location defined by the UEFI
specification. This is completely subverted in LinuxLoader and the EFI
patches you mentioned, which I have seen before and I honestly don't
understand why it was done this way - except to assume that rampant
paranoia about something new and different took hold, and some
internal discussion ended up with "the mainline guys will never accept
this.... how do we work around that?"

Paranoia about another magic value (the kernel already looks for atags
and device tree magic) and doing some UEFI-specific process instead!

What LinuxLoader does is conform to the ARM Linux device tree booting
ABI - not the UEFI booting ABI. What the patches do is put the
responsibility of locating the System Table into the device tree,
which is fundamentally backwards from a firmware -> OS ABI point of
view... from the UEFI specification..

> There are changes that need to be made here such as storing the DT
> pointer in the UEFI system table so that firmware can directly provide a
> DT which either GRUB or the Linux UEFI stub can pick up, but that is a
> relatively uncontroversial detail.

As I said, I don't understand why this is so uncontroversial,
considering it by definition completely subverts the UEFI boot process
to try and make it conform to Linux's device tree or atags searching.

LinuxLoader is a workaround. BdsBootLinuxFdt doesn't do the 'right
thing' from a UEFI point of view. StartLinux just passes the FDT
pointer and machine ID just like a normal U-Boot DT boot, or a Redboot
boot, or any other firmware boot. Getting far enough down into Linux'
early boot process to unflatten a device tree, then finding the UEFI
pointers from the device tree, is just.. avoiding UEFI for no good
reason.

I know there is a historical distrust of firmware around here, but
this is ridiculous.

All the information being stuffed into device tree to support finding
EFI firmwares is all provided by UEFI to the Application (in UEFI
terminology) it boots.. no roundabout parsing of device trees
required, it's right there. As a side effect, the information stored
in device tree /memreserve/ blocks is hanging off the System Table
too.

It might even be nice for UEFI to eventually grow to provide a device
tree parsing service, if it's going to be kept around (fingers crossed
that this will be the case!)

> Again, runtime services works and has no bearing on ACPI.

How UEFI passes data to the OS means Runtime Services and ACPI are
essentially the same thing - stuff in the System Table. The System
Table is being hidden in some deep, dark recess past unflattening the
DT and that's not great.

> ACPI is obtained from UEFI by reading the UEFI system table. This is a
> memory mapped block of UUID/Pointer pairs available right at OS entry
> time.

Not as above.. implementation details.

> 3) Windows. They want one interface that works for both Windows and
> Linux.

There is also absolutely Z E R O reason why Microsoft wouldn't just
embed the relevant ACPI information or replacement tables in some
driver somewhere loaded by the kernel on boot, or OS vendors ship a
fancy wrapper of their own. If, in fact, a WindowsLoader wrapper could
put those tables there, and it could check if they're signed via
Secure Boot too, and this could all be controlled very tightly by
those vendors in this case.

If that's how it's gonna get done these days..

If they have a real need to update ACPI tables to add or fix
functionality, they patch the ACPI stuff at runtime just like Linux
does - to the point there are replacement DSDTs or workarounds for
glitchy AML functionality shipped with Windows. It's functionally no
different to go from half-working ACPI AML and tables to patched ACPI
AML and tables, than to go from zero ACPI to having something around
for the rest of the OS.

There are real, some even already existing, ways around this that
other manufacturers and OS vendors are going to have to feel out to
get the interface they need, and actually tell people what their
intent is rather than just keeping it a big secret. What exact parts
of ACPI do they really want, and why? Are they only concerned about
scripting things like fiddly GPIO management for lights and buzzers
and fans, and  abstract SoC-internal buses like SMBIOS that go as far
as giving access to the aforementioned?

Is it JUST the power management (slipping the CPU into some C-State
without the OS having to know precisely how) part they're really
concerned about?

At a certain level most of the features can be described by device
tree, and implemented in AML and the DT and ACPI tables can be used in
collaboration - describe the system the OS must control with it's own
drivers in DT, and reference those ACPI functionalities from the DT.
At the moment the ARM CPU bindings come with properties to enable PSCI
for moving the CPU between states - it could just as well be
enable-method = "acpi" in those nodes, and the method to go find that
ACPI functionality is extremely well-defined.

If we consider that the worst possible thing you can get on an ACPI
system is a screwy DSDT and some AML you have to patch for FFH
functionality which is kind of rotten or wrong, and device trees have
the same problem, it doesn't matter which gets used. There are going
to be systems booting wrong and fans running like jet engines, odd
crashes, CPU states that need to be disabled in *either* method.

> In FDT land the direction has been anything weird needs a device driver.
> We're not going to try and abstract hardware interfaces. That's why I've
> been resistant to adding any kind of bytecode language to FDT.

I am all for ACPI in theory; what's coming up now is the concept that
oh, we want to run bytecode, and we want a full and comprehensive
pre-boot environment too with some way of calling into it from the OS.
I hate to break it to everyone, but this existed in 1995.. we've gone
through OpenFirmware to FDT and stripping all the functionality, to
wanting it all back again in different ways. Since I loved the concept
of OpenFirmware in the first place, I can't say this is a crappy
idea.. in fact, I'm glad it came full circle.

Please can we get these secret cabal server vendors to start out by
implementing the core parts - UEFI (which will provide services at
boot time at least, and flexible and more importantly *reliable*
environments for server platforms) and the Linux boot process.. before
they start asking whether they can use ACPI *or* DT but not both? What
should come out is something a bit better (and more functional) than
LinuxLoader, and hopefully an uptake in people shipping UEFI. If I had
my way I'd make it a requirement for Linux on ARM, servers or not.

It doesn't matter if Linux supports ACPI or not, if Linux is treating
UEFI like a second class citizen to the device tree, and the way to
get to ACPI is through UEFI. From the bottom, the implementation is
already totally bass ackwards. Who knows what is going on top?

I just can't figure out exactly what is going to be in these ARM
processors that can't - and hasn't already in real life - been
implemented in another way, which is just as good. Windows on x86 is
absolutely not Windows on ARM. Windows on ARM already exists - and if
it's already doing ACPI things, then it's doing ACPI things, but this
is totally hidden inside Microsoft's implementation and the firmware
shipping with the Surface tablets right now, which are fundamentally
closed. If it's not doing ACPI things, then I fail to see why a server
needs ACPI but a tablet doesn't. There's REALLY no fundamental
difference here and REALLY no time saved

> At least with IPMI to a BMC it is on a
> separate processor, but encouraging PM to be stuffed into TrustZone is a
> bad precidence. It starts to look a lot like the bad old days of APM
> before ACPI.

Yes, because paranoia about this kind of stuff really helps, right?

I am not sure shipping buggy AML method and an ACPI package that does
the wrong thing and needs a workround, but being able to see it hosing
itself, is any better for being able to patch around it.

If you know the TrustZone solution doesn't work and the system
designers allow some kind of access to the privileged peripherals
(sharing address space etc.) then a Linux driver could always do it
itself. It was only very recently that the Linux on x86 guys realised
that using ACPI to do the power management was a better solution than
the hand-coded driver with no specs.. but when that doesn't work, what
you get is "it's broken".

There's no way around that, except to replace something at the heart
of the system.

What's the difference between flashing the firmware on the server
board to replace the secure firmware with a working version, vs.
flashing the firmware on the server board to replace the ACPI
functionality with a working version, and giving the system a reboot?

> Regardless, they *still* need to work with upstream to get their
> hardware supported.

If any of them were responsible for LinuxLoader, then they immediately
failed to work with upstream by deciding that they should implement
something completely backwards which - as an intended side effect, I
would assume - wouldn't have to touch a single line of kernel code. If
they're going to push a bunch of patches for ACPI on ARM support, then
fixing the booting situation by doing LinuxLoader the correct way to
start.

That is to say, not capitulating to non-existent device tree stalwarts
by refusing to touch their precious baby, but building them a
super-crib with toys and things for them to play with, a proper
wrapper that gets Linux the System Table without having to give it the
device tree first. It can get the DT, ACPI, and Services functionality
from there instead of going round in circles... once they proved that,
we might be less paranoid about their ability to get it right.

>> > Being consistent about our recommendations here would probably be
>> > helpful, but it seems like we don't have any kind of thought out story
>> > yet. That seems like a problem.
>>
>> +100.
>
> yup

Matt <neko@bakuhatsu.net>

ACPI

[Leif Lindholm]

On Wed, Nov 27, 2013 at 04:17:41PM -0600, Matt Sealey wrote:
> UEFI hands control to an entry point of a PE/COFF executable (the only
> thing it's required to know how to load) passing the pointer to the
> System Table as it's second argument, location defined by the UEFI
> specification. This is completely subverted in LinuxLoader and the EFI
> patches you mentioned, which I have seen before and I honestly don't
> understand why it was done this way - except to assume that rampant
> paranoia about something new and different took hold, and some
> internal discussion ended up with "the mainline guys will never accept
> this.... how do we work around that?"

The LinuxLoader is a legacy thing which needs to go away.
Proper UEFI support in the kernel is one way of making that possible.

Don't really understand yor comments about the arm kernel UEFI support,
but there seems to be some misunderstanding here, so I don't think going
over your email and tickbox-refuting them one by one will be of much
use to anyone.

I will be posting an updated set of the arm patches today, to go with
the updated UEFI stub patches submitted by Roy last night. I will be
happy to discuss the topics mentioned as part of this message as part
of the review of those, if you still consider them an issue.

But let's be clear - my intent is to get UEFI first-class citizen
status in the arm kernel.

/
    Leif

ACPI

[Grant Likely]

On 27 Nov 2013 22:17, "Matt Sealey" <neko@bakuhatsu.net> wrote:
>
> On Wed, Nov 27, 2013 at 8:16 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On Tue, 26 Nov 2013 17:11:23 -0600, Matt Sealey <neko@bakuhatsu.net> wrote:
> >> On Tue, Nov 26, 2013 at 12:33 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> >> > On Tue, Nov 26, 2013 at 12:55:10PM +0000, Grant Likely wrote:
> >> >> On Tue, Nov 26, 2013 at 12:43 PM, Linus Walleij
> >> >> <linus.walleij@linaro.org> wrote:
> >> >> > I have a feeling we should not recommend ARM implementers
> >> >> > to go and do things like this.
> >>
> >> I have a real problem with the concept of putting device trees inside
> >> ACPI, while still relying on this consensus that the preferred boot
> >> method will also be UEFI.
> >
> > ACPI and UEFI are completely separate things.
>
> Good lord, Grant. I have a working knowledge of both..

We're obviously getting crossed wires. I apologize for
misunderstanding. Yes, LinuxLoader is an obsolete hack. Roy Franz has
patches to port the x86 EFI_STUB to arm. I was merely using
LinuxLoader as evidence that having DT support in Tianocore should not
be a problem.

g.

ACPI

[Grant Likely]

On Tue, 26 Nov 2013 18:33:44 +0000, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Tue, Nov 26, 2013 at 12:55:10PM +0000, Grant Likely wrote:
> > On Tue, Nov 26, 2013 at 12:43 PM, Linus Walleij
> > <linus.walleij@linaro.org> wrote:
> > > I have a feeling we should not recommend ARM implementers
> > > to go and do things like this.
> > 
> > ACPI5 defines a binding for serial busses (i2c & spi) which allows
> > real device drivers to drive the bus and allows ACPI and the kernel to
> > share the bus safely. Using that binding means some i2c devices can be
> > 'owned' by ACPI and others owned by the kernel.
> 
> Right, we shouldn't see a problem in this specific case. But it does 
> leave a wider philosophical concern - there are still components that 
> can't be exposed to the OS via ACPI in standardised ways, and the 
> traditional way of dealing with that on x86 is to just add the 
> functionality via ASL. It seems that we have three basic options:
> 
> 1) Encourage vendors to add functionality to their DSDTs
> 2) Encourage vendors to use existing kernel functionality, exposing 
> information via either DT-in-ACPI or some other custom method
> 3) Encourage vendors to continue using DT until this functionality is 
> standardised

I think pushing for #3 is the correct thing to do right now. Even if the
core ACPI support were to get merged in the next merge window, it is
going to take time to work out best practices. Exactly how much of the
topology should be exposed in ACPI is a big question. Having real ARM
server machines commercially available will be important anyway to
actually figure out what ARM ACPI should look like.

g.

ACPI

[Matthew Garrett]

On Tue, Nov 26, 2013 at 01:43:40PM +0100, Linus Walleij wrote:
> On Mon, Nov 25, 2013 at 4:41 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> 
> > In the past ACPI implementations handled GPIO by providing
> > methods that accessed hardware registers directly. I've seen DSDTs that
> > implement i2c entirely in ASL.
> 
> Is that common?

No, thankfully.

> Since i2c is a slow bus, can be 100kHz or so, how does that
> avoid locking the entire CPU while e.g. waiting for transactions on
> the external bus to complete?

Check status register, interruptible sleep, repeat until done.

> I have a feeling we should not recommend ARM implementers
> to go and do things like this.

Oh, absolutely.

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

ACPI

[Heinrich Schuchardt]

Hello Anup,

different RISC-V platforms have chosen to generate ACPI tables in 
edk2-platforms.

With u-boot-next we can pass ACPI tables generated by 
qemu-system-riscv64 as EFI configuration table to the OS. For x86 
platforms the generation of ACPI tables has been implemented inside 
U-Boot. The same could be done for RISC-V.

Wouldn't it be preferable to move the generation of ACPI tables to the 
OpenSBI layer?

These are the advantages I see:

* Different UEFI implementations don't have to duplicate code. For 
instance you could have a very thin EFI implementation that is just good 
enough to call the Linux entry point (see the discussion about 
Coreboot). Or you could easily switch between EDK II and U-Boot without 
rewriting ACPI related code.

* As far as ACPI tables can be derived from device-trees we could use 
common library functions to generate the tables for all platforms.

To pass ACPI tables from OpenSBI to U-Boot or EDK II we could use a 
device-tree node.

Best regards

Heinrich

ACPI

[Anup Patel]

Hi Heinrich,

On Sat, Dec 16, 2023 at 3:15?PM Heinrich Schuchardt
<heinrich.schuchardt@canonical.com> wrote:
>
> Hello Anup,
>
> different RISC-V platforms have chosen to generate ACPI tables in
> edk2-platforms.
>
> With u-boot-next we can pass ACPI tables generated by
> qemu-system-riscv64 as EFI configuration table to the OS. For x86
> platforms the generation of ACPI tables has been implemented inside
> U-Boot. The same could be done for RISC-V.
>
> Wouldn't it be preferable to move the generation of ACPI tables to the
> OpenSBI layer?
>
> These are the advantages I see:
>
> * Different UEFI implementations don't have to duplicate code. For
> instance you could have a very thin EFI implementation that is just good
> enough to call the Linux entry point (see the discussion about
> Coreboot). Or you could easily switch between EDK II and U-Boot without
> rewriting ACPI related code.
>
> * As far as ACPI tables can be derived from device-trees we could use
> common library functions to generate the tables for all platforms.
>
> To pass ACPI tables from OpenSBI to U-Boot or EDK II we could use a
> device-tree node.

Sharing code to generate ACPI tables between multiple projects (U-Boot
and EDK2) is certainly a good idea but doing it in OpenSBI (M-mode
firmware) has following drawbacks:

1) We will need a DT node to pass the details generated ACPI tables
    which is later redundant.
2) This will bring large amount of code in OpenSBI which is only used
    at boot time and totally unused at runtime.
3) Having it in OpenSBI also makes it RISC-V specific and other
    architectures can't benefit from it.

Instead of the above, I would suggest having an independent dt2acpi
project (just like libfdt) which can be used by both EDK2 and U-Boot.
This will also allow other architectures to use and contribute to the
common dt2acpi project.

Regards,
Anup

>
> Best regards
>
> Heinrich
>
> --
> opensbi mailing list
> opensbi at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/opensbi

acpi

[Michael Lestoquoy]

ACPI: EC: Look up EC in DSDT
ACPI: BIOS _OSI(Linux) query ignored
ACPI: DMI System Vendor: Dell Inc.
ACPI: DMI Product Name: PowerEdge 2970
ACPI: DMI Product Version:
ACPI: DMI Board Name: 0CY813

ACPI

[Florian Sylla]

[   26.225155] ACPI: DMI System Vendor: LENOVO
[   26.225156] ACPI: DMI Product Name: 0769BBG
[   26.225158] ACPI: DMI Product Version: 3000
N200                       
[   26.225160] ACPI: DMI Board Name: IEL10
[   26.225161] ACPI: DMI BIOS Vendor: LENOVO
[   26.225163] ACPI: DMI BIOS Date: 04/16/2008
[   26.225164] ACPI: Please send DMI info above to
linux-acpi@vger.kernel.org

ACPI

[jd]

Hi 
 We ship some images (that kicks the install ) out of the box and would like to know peoples experiences and developer opinions on ACPI. This would help us determine if this should be enabled by default or not.

-- For Windows guests 
-- For Linix guests 

Thanks
/Jd
http://www.convirt.net


      

Re: ACPI

[Bryon Roche]

On Fri, 10 Oct 2008 13:32:48 -0700, jd wrote:

> Hi
> -- For Windows guests
No ACPI. XP and newer use an ACPI register, that according to the wiki, 
incurs a large virtualization penalty.
> -- For Linix guests
Go ACPI afaik, so you get PM support and guess sleeping IIRC.
> 

> Thanks
> /Jd
> http://www.convirt.net

Re: ACPI

[Avi Kivity]

jd wrote:
> Hi 
>  We ship some images (that kicks the install ) out of the box and would like to know peoples experiences and developer opinions on ACPI. This would help us determine if this should be enabled by default or not.
>
> -- For Windows guests 
> -- For Linix guests 
>
>   

I recommend you enable ACPI for all guests.

-- 
error compiling committee.c: too many arguments to function

ACPI

[Manuel Alberer]

0.390042] ACPI: DMI System Vendor:
[    0.390090] ACPI: DMI Product Name:
[    0.390138] ACPI: DMI Product Version:
[    0.390185] ACPI: DMI Board Name: DG45ID
[    0.390232] ACPI: DMI BIOS Vendor: Intel Corp.
[    0.390279] ACPI: DMI BIOS Date: 09/09/2008
[    0.390326] ACPI: Please send DMI info above to linux-acpi@vger.kernel.org
[    0.390378] ACPI: If "acpi_osi=Linux" works better, please notify
linux-acpi@vger.kernel.org

ACPI

[Moshe Aldelmen]

ACPI: If "acpi_apic_instance=2" works better, notify
linux-acpi@vger.kernel.org

Let me ask a question, does this line mean that an email is
automatically sent from my machine to this address ????


Thanks,

M.

ACPI

[Lademann, Klaus]

Dear Kernel.org - Team

Thats my DMI -Text from Lenovo 3000 N200
~# dmesg


ACPI: DMI System Vendor: LENOVO
ACPI: DMI Product Name: 0769B3G
ACPI: DMI Product Version: 3000 N200
ACPI: DMI Board Name: IEL10
ACPI: DMI BIOS Vendor: LENOVO
ACPI: DMI BIOS Date: 04/18/2007

I have interesting in thinkpad_acpi, but it is not running from
linux-2.6.24 with
error "no such device"

-- 
Lademann, Klaus
Teterower Ring 110
D-12619 Berlin
<azael@freenet.de>

Re: ACPI

[Alexey Starikovskiy]

Dear Klaus,

Lenovo 3000 N200 is not a ThinkPad, thus thinkpad_acpi fails to load, as 
it fails to
load on Dell, HP, etc.

Regards,
Alex.

Lademann, Klaus wrote:
> Dear Kernel.org - Team
>
> Thats my DMI -Text from Lenovo 3000 N200
> ~# dmesg
>
>
> ACPI: DMI System Vendor: LENOVO
> ACPI: DMI Product Name: 0769B3G
> ACPI: DMI Product Version: 3000 N200
> ACPI: DMI Board Name: IEL10
> ACPI: DMI BIOS Vendor: LENOVO
> ACPI: DMI BIOS Date: 04/18/2007
>
> I have interesting in thinkpad_acpi, but it is not running from
> linux-2.6.24 with
> error "no such device"
>
>   

ACPI

[Thomas Knox]

# dmidecode 2.9
SMBIOS 2.3 present.
68 structures occupying 2451 bytes.
Table at 0x000F0450.

Handle 0xDA00, DMI type 218, 47 bytes
OEM-specific Type
	Header and Data:
		DA 2F 00 DA B2 00 17 5B 0E 38 00 58 00 58 00 01
		00 59 00 59 00 01 00 DD 01 DD 01 03 00 DC 01 DC
		01 02 00 05 80 05 80 01 00 FF FF 00 00 00 00

Handle 0xDA01, DMI type 218, 35 bytes
OEM-specific Type
	Header and Data:
		DA 23 01 DA B2 00 17 5B 0E 38 00 10 F5 10 F5 00
		00 11 F5 11 F5 00 00 12 F5 12 F5 00 00 FF FF 00
		00 00 00

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
	Vendor: Dell Inc.                
	Version: 2.4.0 
	Release Date: 05/24/2007
	Address: 0xF0000
	Runtime Size: 64 kB
	ROM Size: 512 kB
	Characteristics:
		PCI is supported
		PNP is supported
		APM is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		Boot from CD is supported
		Selectable boot is supported
		EDD is supported
		Japanese floppy for Toshiba 1.2 MB is supported (int 13h)
		Print screen service is supported (int 5h)
		8042 keyboard services are supported (int 9h)
		Serial services are supported (int 14h)
		Printer services are supported (int 17h)
		ACPI is supported
		USB legacy is supported
		LS-120 boot is supported
		BIOS boot specification is supported
		Function key-initiated network boot is supported
		Targeted content distribution is supported
	BIOS Revision: 2.4

Handle 0x0100, DMI type 1, 27 bytes
System Information
	Manufacturer: Dell Inc.                
	Product Name: Dell DM061                   
	Version: Not Specified
	Serial Number: CFLWPC1
	UUID: 44454C4C-4600-104C-8057-C3C04F504331
	Wake-up Type: APM Timer
	SKU Number: Not Specified
	Family: Not Specified

Handle 0x0200, DMI type 2, 8 bytes
Base Board Information
	Manufacturer: Dell Inc.          
	Product Name: 0WG864
	Version:    
	Serial Number: ..CN481116CT0038.

Handle 0x0300, DMI type 3, 13 bytes
Chassis Information
	Manufacturer: Dell Inc.                
	Type: Mini Tower
	Lock: Not Present
	Version: Not Specified
	Serial Number: CFLWPC1
	Asset Tag:           
	Boot-up State: Safe
	Power Supply State: Safe
	Thermal State: Safe
	Security Status: None

Handle 0x0400, DMI type 4, 40 bytes
Processor Information
	Socket Designation: Microprocessor
	Type: Central Processor
	Family: <OUT OF SPEC>
	Manufacturer: Intel
	ID: F2 06 00 00 FF FB EB BF
	Version: Not Specified
	Voltage: 1.8 V
	External Clock: 1066 MHz
	Max Speed: 5200 MHz
	Current Speed: 2133 MHz
	Status: Populated, Enabled
	Upgrade: ZIF Socket
	L1 Cache Handle: 0x0700
	L2 Cache Handle: 0x0701
	L3 Cache Handle: Not Provided
	Serial Number: Not Specified
	Asset Tag: Not Specified
	Part Number: Not Specified
	Core Count: 2
	Core Enabled: 2
	Thread Count: 2
	Characteristics:
		64-bit capable

Handle 0x0700, DMI type 7, 19 bytes
Cache Information
	Socket Designation: Not Specified
	Configuration: Enabled, Not Socketed, Level 1
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 32 KB
	Maximum Size: 32 KB
	Supported SRAM Types:
		Other
	Installed SRAM Type: Other
	Speed: Unknown
	Error Correction Type: None
	System Type: Data
	Associativity: 8-way Set-associative

Handle 0x0701, DMI type 7, 19 bytes
Cache Information
	Socket Designation: Not Specified
	Configuration: Enabled, Not Socketed, Level 2
	Operational Mode: Varies With Memory Address
	Location: Internal
	Installed Size: 2048 KB
	Maximum Size: 2048 KB
	Supported SRAM Types:
		Other
	Installed SRAM Type: Other
	Speed: Unknown
	Error Correction Type: Single-bit ECC
	System Type: Unified
	Associativity: 8-way Set-associative

Handle 0x0805, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: USB1
	Internal Connector Type: None
	External Reference Designator: Not Specified
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x0806, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: USB2
	Internal Connector Type: None
	External Reference Designator: Not Specified
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x0807, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: USB3
	Internal Connector Type: None
	External Reference Designator: Not Specified
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x0808, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: USB4
	Internal Connector Type: None
	External Reference Designator: Not Specified
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x0809, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: USB5
	Internal Connector Type: None
	External Reference Designator: Not Specified
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x080A, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: USB6
	Internal Connector Type: None
	External Reference Designator: Not Specified
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x080B, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: USB7
	Internal Connector Type: None
	External Reference Designator: Not Specified
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x080C, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: USB8
	Internal Connector Type: None
	External Reference Designator: Not Specified
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x080D, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: ENET
	Internal Connector Type: None
	External Reference Designator: Not Specified
	External Connector Type: RJ-45
	Port Type: Network Port

Handle 0x080E, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: MIC
	Internal Connector Type: None
	External Reference Designator: Not Specified
	External Connector Type: Mini Jack (headphones)
	Port Type: Audio Port

Handle 0x080F, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: LINE-OUT
	Internal Connector Type: None
	External Reference Designator: Not Specified
	External Connector Type: Mini Jack (headphones)
	Port Type: Audio Port

Handle 0x0810, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: LINE-IN
	Internal Connector Type: None
	External Reference Designator: Not Specified
	External Connector Type: Mini Jack (headphones)
	Port Type: Audio Port

Handle 0x0811, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: HP-OUT
	Internal Connector Type: None
	External Reference Designator: Not Specified
	External Connector Type: Mini Jack (headphones)
	Port Type: Audio Port

Handle 0x0812, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: MONITOR
	Internal Connector Type: None
	External Reference Designator: Not Specified
	External Connector Type: DB-15 female
	Port Type: Video Port

Handle 0x090A, DMI type 9, 13 bytes
System Slot Information
	Designation: PEG  
	Type: x16 PCI Express
	Current Usage: In Use
	Length: Long
	ID: 10
	Characteristics:
		3.3 V is provided
		PME signal is supported

Handle 0x0901, DMI type 126, 13 bytes
Inactive

Handle 0x0902, DMI type 9, 13 bytes
System Slot Information
	Designation: SLOT2  
	Type: x1 PCI Express
	Current Usage: Available
	Length: Long
	ID: 2
	Characteristics:
		3.3 V is provided
		PME signal is supported

Handle 0x0903, DMI type 9, 13 bytes
System Slot Information
	Designation: SLOT3  
	Type: 32-bit PCI
	Current Usage: In Use
	Length: Long
	ID: 3
	Characteristics:
		5.0 V is provided
		3.3 V is provided
		PME signal is supported

Handle 0x0904, DMI type 9, 13 bytes
System Slot Information
	Designation: SLOT4  
	Type: 32-bit PCI
	Current Usage: In Use
	Length: Long
	ID: 4
	Characteristics:
		5.0 V is provided
		3.3 V is provided
		PME signal is supported

Handle 0x0905, DMI type 126, 13 bytes
Inactive

Handle 0x0906, DMI type 126, 13 bytes
Inactive

Handle 0x0907, DMI type 126, 13 bytes
Inactive

Handle 0x0908, DMI type 126, 13 bytes
Inactive

Handle 0x0A00, DMI type 10, 6 bytes
On Board Device Information
	Type: Video
	Status: Disabled
	Description: Intel Graphics Media Accelerator 950

Handle 0x0A02, DMI type 10, 6 bytes
On Board Device Information
	Type: Ethernet
	Status: Disabled
	Description: Intel Pro 1000 MT Network Connection

Handle 0x0A03, DMI type 10, 6 bytes
On Board Device Information
	Type: Sound
	Status: Enabled
	Description: Intel(R) High Definition Audio Controller

Handle 0x0B00, DMI type 11, 5 bytes
OEM Strings
	String 1: www.dell.com

Handle 0x0D00, DMI type 13, 22 bytes
BIOS Language Information
	Installable Languages: 1
		en|US|iso8859-1
	Currently Installed Language: en|US|iso8859-1

Handle 0x0F00, DMI type 15, 29 bytes
System Event Log
	Area Length: 2049 bytes
	Header Start Offset: 0x0000
	Header Length: 16 bytes
	Data Start Offset: 0x0010
	Access Method: Memory-mapped physical 32-bit address
	Access Address: 0xFFF8D000
	Status: Valid, Not Full
	Change Token: 0x0000000B
	Header Format: Type 1
	Supported Log Type Descriptors: 3
	Descriptor 1: POST error
	Data Format 1: POST results bitmap
	Descriptor 2: System limit exceeded
	Data Format 2: System management
	Descriptor 3: Log area reset/cleared
	Data Format 3: None

Handle 0x1000, DMI type 16, 15 bytes
Physical Memory Array
	Location: System Board Or Motherboard
	Use: System Memory
	Error Correction Type: Single-bit ECC
	Maximum Capacity: 4 GB
	Error Information Handle: Not Provided
	Number Of Devices: 4

Handle 0x1100, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x1000
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 1024 MB
	Form Factor: DIMM
	Set: None
	Locator: DIMM_1
	Bank Locator: Not Specified
	Type: DDR
	Type Detail: Synchronous
	Speed: 667 MHz (1.5 ns)
	Manufacturer: AD00000000000000
	Serial Number: 00001111
	Asset Tag: 010708
	Part Number: HYMP512U64CP8-Y5  

Handle 0x1101, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x1000
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: No Module Installed
	Form Factor: DIMM
	Set: None
	Locator: DIMM_3
	Bank Locator: Not Specified
	Type: DDR
	Type Detail: Synchronous
	Speed: 667 MHz (1.5 ns)
	Manufacturer: FFFFFFFFFFFFFFFF
	Serial Number: FFFFFFFF
	Asset Tag: FFFFFF
	Part Number:                   

Handle 0x1102, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x1000
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 1024 MB
	Form Factor: DIMM
	Set: None
	Locator: DIMM_2
	Bank Locator: Not Specified
	Type: DDR
	Type Detail: Synchronous
	Speed: 667 MHz (1.5 ns)
	Manufacturer: AD00000000000000
	Serial Number: 00001285
	Asset Tag: 010708
	Part Number: HYMP512U64CP8-Y5  

Handle 0x1103, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x1000
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: No Module Installed
	Form Factor: DIMM
	Set: None
	Locator: DIMM_4
	Bank Locator: Not Specified
	Type: DDR
	Type Detail: Synchronous
	Speed: 667 MHz (1.5 ns)
	Manufacturer: FFFFFFFFFFFFFFFF
	Serial Number: FFFFFFFF
	Asset Tag: FFFFFF
	Part Number:                   

Handle 0x1301, DMI type 19, 15 bytes
Memory Array Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x0007FFFFFFF
	Range Size: 2 GB
	Physical Array Handle: 0x1000
	Partition Width: 0

Handle 0x1400, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x0003FFFFFFF
	Range Size: 1 GB
	Physical Device Handle: 0x1100
	Memory Array Mapped Address Handle: 0x1301
	Partition Row Position: 1

Handle 0x1401, DMI type 126, 19 bytes
Inactive

Handle 0x1402, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00040000000
	Ending Address: 0x0007FFFFFFF
	Range Size: 1 GB
	Physical Device Handle: 0x1102
	Memory Array Mapped Address Handle: 0x1301
	Partition Row Position: 1

Handle 0x1403, DMI type 126, 19 bytes
Inactive

Handle 0x1800, DMI type 24, 5 bytes
Hardware Security
	Power-On Password Status: Enabled
	Keyboard Password Status: Not Implemented
	Administrator Password Status: Enabled
	Front Panel Reset Status: Not Implemented

Handle 0x1900, DMI type 25, 9 bytes
	System Power Controls
	Next Scheduled Power-on: *-* 00:00:00

Handle 0x1B10, DMI type 27, 12 bytes
Cooling Device
	Type: Fan
	Status: OK
	OEM-specific Information: 0x0000DD00

Handle 0x1B11, DMI type 126, 12 bytes
Inactive

Handle 0x1B12, DMI type 126, 12 bytes
Inactive

Handle 0x1B13, DMI type 126, 12 bytes
Inactive

Handle 0x1B14, DMI type 126, 12 bytes
Inactive

Handle 0x2000, DMI type 32, 11 bytes
System Boot Information
	Status: No errors detected

Handle 0x8800, DMI type 136, 6 bytes
OEM-specific Type
	Header and Data:
		88 06 00 88 5A 5A

Handle 0xD000, DMI type 208, 10 bytes
OEM-specific Type
	Header and Data:
		D0 0A 00 D0 01 03 FE 00 DD 01

Handle 0xD400, DMI type 212, 192 bytes
OEM-specific Type
	Header and Data:
		D4 C0 00 D4 70 00 71 00 00 10 2D 2E 42 00 11 FE
		01 43 00 11 FE 00 07 00 23 8F 00 08 00 23 F3 00
		09 00 23 F3 04 0A 00 23 F3 08 0B 00 23 8F 10 0C
		00 23 8F 20 0E 00 23 8F 30 0D 00 23 8C 40 A6 00
		23 8C 41 A7 00 23 8C 42 05 01 22 FD 02 06 01 22
		FD 00 8C 00 22 FE 00 8D 00 22 FE 01 09 01 25 3F
		80 A1 00 26 F3 00 A2 00 26 F3 08 A3 00 26 F3 04
		9F 00 26 FD 02 A0 00 26 FD 00 9D 00 11 FB 04 9E
		00 11 FB 00 54 01 23 7F 00 55 01 23 7F 80 5C 00
		78 BF 40 5D 00 78 BF 00 04 80 78 F5 0A 01 A0 78
		F5 00 93 00 7B 7F 80 94 00 7B 7F 00 8A 00 37 DF
		20 8B 00 37 DF 00 03 C0 67 00 05 FF FF 00 00 00

Handle 0xD401, DMI type 212, 192 bytes
OEM-specific Type
	Header and Data:
		D4 C0 01 D4 70 00 71 00 03 40 59 6D 2D 00 59 F8
		02 2E 00 59 F8 00 6E 00 59 F8 01 28 00 59 3F 00
		29 00 59 3F 40 2A 00 59 3F 80 2B 00 5A 00 00 2C
		00 5B 00 00 55 00 59 E7 00 6D 00 59 E7 08 8E 00
		59 E7 10 8F 00 59 E7 00 1C 00 55 FB 04 1D 00 55
		FB 00 19 00 55 E7 00 1A 00 55 E7 08 1B 00 55 E7
		10 23 00 55 7F 00 22 00 55 7F 80 EB 00 55 FE 00
		EA 00 55 FE 01 01 01 51 3F 00 02 01 51 3F 40 03
		01 51 3F 80 04 01 51 3F C0 40 01 54 EF 00 41 01
		54 EF 10 42 01 54 F7 00 43 01 54 F7 08 4A 01 54
		FB 00 4B 01 54 FB 04 4C 01 53 7F 00 4D 01 53 7F
		80 56 01 7B FD 00 57 01 7B FD 02 FF FF 00 00 00

Handle 0xD402, DMI type 212, 97 bytes
OEM-specific Type
	Header and Data:
		D4 61 02 D4 70 00 71 00 00 10 2D 2E 2D 01 21 FE
		01 2E 01 21 FE 00 E2 00 27 7F 00 E3 00 27 7F 80
		E4 00 27 BF 00 E5 00 27 BF 40 D1 00 22 7F 80 D2
		00 22 7F 00 37 01 21 F1 00 39 01 21 F1 02 4E 01
		65 CF 00 4F 01 65 CF 10 D4 01 65 F3 00 D5 01 65
		F3 04 D2 01 65 FC 00 D3 01 65 FC 01 FF FF 00 00
		00

Handle 0xD403, DMI type 212, 87 bytes
OEM-specific Type
	Header and Data:
		D4 57 03 D4 70 00 71 00 03 40 59 6D 17 01 52 FE
		00 18 01 52 FE 01 19 01 52 FB 00 1A 01 52 FB 04
		1B 01 52 FD 00 1C 01 52 FD 02 1D 01 52 F7 00 1E
		01 52 F7 08 1F 01 52 EF 00 20 01 52 EF 10 21 01
		52 BF 00 22 01 52 BF 40 87 00 59 DF 20 88 00 59
		DF 00 FF FF 00 00 00

Handle 0xD800, DMI type 126, 9 bytes
Inactive

Handle 0xDD00, DMI type 221, 19 bytes
OEM-specific Type
	Header and Data:
		DD 13 00 DD 00 01 00 00 00 10 F5 00 00 00 00 00
		00 00 00

Handle 0xDD01, DMI type 221, 19 bytes
OEM-specific Type
	Header and Data:
		DD 13 01 DD 00 01 00 00 00 11 F5 00 00 00 00 00
		00 00 00

Handle 0xDD02, DMI type 221, 19 bytes
OEM-specific Type
	Header and Data:
		DD 13 02 DD 00 01 00 00 00 12 F5 00 00 00 00 00
		00 00 00

Handle 0xDE00, DMI type 222, 13 bytes
OEM-specific Type
	Header and Data:
		DE 0D 00 DE C1 01 00 00 07 07 28 18 42

Handle 0x7F00, DMI type 127, 4 bytes
End Of Table

RE: ACPI

[Zhu, Yi]

linux-kernel-owner@vger.kernel.org wrote:
> Hey guys,
> 
> I last posted a problem regarding ACPI and shutting down the
> system. I believe the suggestion was for me to upgrade the
> kernel. With kernel 2.6.3, ACPI shutdown was working about
> 90% of the time but once I upgraded to 2.6.4, it never shut off again.
> 
> If anyone can tell me where I need to go for to correct this,
> I would really appreciate it. I've already tried one of the
> ASUS mailing lists but it's as dead as a ghost town.

http://bugme.osdl.org

ACPI

[Bruce Park]

Hey guys,

I last posted a problem regarding ACPI and shutting down the system. I believe the 
suggestion was for me to upgrade the kernel. With kernel 2.6.3, ACPI shutdown was 
working about 90% of the time but once I upgraded to 2.6.4, it never shut off again.

If anyone can tell me where I need to go for to correct this, I would really 
appreciate it. I've already tried one of the ASUS mailing lists but it's as dead as a 
ghost town.

bp

ACPI

[Trever L. Adams]

This is not entirely a bug report.  The last few kernels have been
getting better at dealing with my eMachines m6805 (Athlon 64 based).
The patch to fix up VIA irqs does NOT help with the via rhine in this
machine.  Also, pirqmask doesn't help when turning acpi configuration
off for the pcmcia (it hangs).

However, I can now view power status and unplug and plug in without the
machine hanging.  The biggest frustration is the lack of auto ACPI
configuration, this does seem to be getting better... that and the fact
I can't suspend to anything but mem and that hangs.  Suspend by standby
just flashes the screen and it is back.  This is likely an easy kernel
bug to fix, but I am not sure where to start.

I am not using x86-64 kernels.  I am using the x86 (686 variants) of
everything from Fedora Core test, or i386 where i686 is not available.

Good work everyone.  If there is any more information that would help,
let me know what and how to get it and I will fire it off.

Trever

ACPI

[Russell Coker]

Anyone tried out ACPI with SE Linux?  Does it have any requirements different 
from APM?

If not then perhaps the apm policy in the sample policy for apm should be 
renamed to "power"?

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.