[U-Boot] ACPI tables for Edison: advice needed

Bin Meng bmeng.cn at gmail.com
Tue Aug 29 09:34:52 UTC 2017

Hi Andy,

On Tue, Aug 29, 2017 at 5:10 PM, Andy Shevchenko
<andy.shevchenko at gmail.com> wrote:
> On Tue, Aug 29, 2017 at 7:49 AM, Bin Meng <bmeng.cn at gmail.com> wrote:
>> On Tue, Aug 29, 2017 at 1:12 AM, Andy Shevchenko
>> <andy.shevchenko at gmail.com> wrote:
>>> I have a preliminary working ACPI tables for Intel Edison (to replace
>>> ugly SFI provided by firmware).
>>> What I would like to ask is how better from your point of view to proceed.
>>> I have apparently not all devices covered in the tables, though I have
>>> almost stable code which brings ACPI support to Edison.
>>> I see few options here:
>>> 0. Do nothing :-)
>>> 1. Apply ACPI code, but leave no tables applied yet.
>>> 2. Apply both and amend whenever problem occurs.
>>> 3. Postpone until kernel will be ready for that (*)
>>> 4. ...other option...?
>> I would vote for option 2.
>>> *) LInux kernel (vanilla) is not ready for this change. It means in
>>> all above cases there will be neither new config file (like
>>> edison_acpi_defconfig) nor modification to the existing one (of
>>> course!). The stuff is highly experimental now.
> (Just to clarify, configurations mentioned in above remark are related
> solely for U-Boot)
>> Does Linux kernel need to do anything to support ACPI on Intel Edison?
> There are few groups of problems:
> 1. Edison has an _ugly_ SFI which means the kernel has many platform
> drivers, like board code, that enumerated from hard coded platform
> data.
> 2. ACPI is kinda artificial on Edison, that's why it uses HW reduced
> bit set, and kernel, surprise, surprise, has bugs in that code.

Ah, surprised! But I can imagine that is maybe due to there is no HW
reduced platform available to be tested with Linux kernel yet.

> 3. Drivers for devices that located on extension boards like
> Edison/Arduino are not ready to be enumerated via ACPI (this one
> optional and can be done later).
> 4. There is lack of framework such as pin control ACPI (glue layer
> between ACPICA and pin control which I'm working on as a main task),

Does drivers/pinctrl/intel/ (in kernel tree) not apply to this? I see
there are ACPI drivers, but maybe you are saying ACPI-defined native
support for GPIO (ie: using ASL to describe pin)?

> though in the sense of Linux kernel it affect entire x86 world.
>> My understanding is that ACPI is a standard spec, and as long as our
>> U-Boot implementation matches the spec, Linux kernel can support it
>> out of the box.
> That's correct, though see above.
> P.S. There is a wiki page that I'm filling with my progress wrt topic:
> https://edison.internet-share.com/wiki/ACPI

Thanks for the link! It's amazing job you have done so far.


More information about the U-Boot mailing list