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

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

[Andy Shevchenko]

Hi!

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...?

*) 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.

-- 
With Best Regards,
Andy Shevchenko

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

[Bin Meng]

Hi Andy,

On Tue, Aug 29, 2017 at 1:12 AM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> Hi!
>
> 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.

Does Linux kernel need to do anything to support ACPI on Intel Edison?
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.

Regards,
Bin

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

[Stefan Roese]

Hi Andy,

On 29.08.2017 06:49, Bin Meng wrote:
> On Tue, Aug 29, 2017 at 1:12 AM, Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
>> Hi!
>>
>> 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.

+1

Thanks,
Stefan

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

[Andy Shevchenko]

On Tue, Aug 29, 2017 at 7:49 AM, Bin Meng <bmeng.cn@gmail.com> wrote:
> On Tue, Aug 29, 2017 at 1:12 AM, Andy Shevchenko
> <andy.shevchenko@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.
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),
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

-- 
With Best Regards,
Andy Shevchenko

[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@gmail.com> wrote:
> On Tue, Aug 29, 2017 at 7:49 AM, Bin Meng <bmeng.cn@gmail.com> wrote:
>> On Tue, Aug 29, 2017 at 1:12 AM, Andy Shevchenko
>> <andy.shevchenko@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

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

[Andy Shevchenko]

On Tue, Aug 29, 2017 at 12:34 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> On Tue, Aug 29, 2017 at 5:10 PM, Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
>> On Tue, Aug 29, 2017 at 7:49 AM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> On Tue, Aug 29, 2017 at 1:12 AM, Andy Shevchenko
>>> <andy.shevchenko@gmail.com> wrote:

>>>> *) 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.

No, ASuS T100TA is the one, but the hardware OTOH has legacy devices
and ACPI HW (or at least doesn't behave weird when accessing to ACPI
HW registers).
So, basically this seems to be _the_ HW reduced platform Linux kernel
has been tested on.

>> 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)?

Native support for _pin control_ (yes, in terms of ACPI r6.2). Native
GPIO support (ACPI r5.0 or even earlier?) is in Linux kernel already
for quite a few releases.

>> 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.


-- 
With Best Regards,
Andy Shevchenko