[U-Boot] ACPI tables for Edison: advice needed
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.
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 :-)
- Apply ACPI code, but leave no tables applied yet.
- Apply both and amend whenever problem occurs.
- Postpone until kernel will be ready for that (*)
- ...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
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 :-)
- Apply ACPI code, but leave no tables applied yet.
- Apply both and amend whenever problem occurs.
- Postpone until kernel will be ready for that (*)
- ...other option...?
I would vote for option 2.
+1
Thanks, Stefan
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 :-)
- Apply ACPI code, but leave no tables applied yet.
- Apply both and amend whenever problem occurs.
- Postpone until kernel will be ready for that (*)
- ...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
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 :-)
- Apply ACPI code, but leave no tables applied yet.
- Apply both and amend whenever problem occurs.
- Postpone until kernel will be ready for that (*)
- ...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:
- 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.
- 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
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:
- 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.
- 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).
- 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.
participants (3)
-
Andy Shevchenko -
Bin Meng -
Stefan Roese