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

[Bin Meng]

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.

Regards,
Bin