Messages in this thread | | | From | Wojciech Bartczak <> | Subject | Re: Mixing SCMI and ACPI? | Date | Fri, 4 Feb 2022 10:16:41 -0800 |
| |
On Fri, Feb 04, 2022 at 02:21:50PM +0000, Sudeep Holla wrote: Hi Sudeep,
Firstly, thank you for blazing fast answer.
> Hi Wojciech, > > Please cc me too for anything SCMI related in the future. > > On Fri, Feb 04, 2022 at 01:32:47PM +0000, Wojciech Bartczak wrote: > > Hi Folks, > > > > I have been working with SCMI for some time now. > > Good to know 😄 > > > Here at Marvell, we use very common software stack. > > Excellent! > > > Mostly ATF, U-Boot and Kernel. With this software stack, SCMI integration is > > just a matter of following the common sense. > > Glad to hear that. > > > Recently, the new requirement for supporting ACPI and UEFI has arrived. > > The main goal is to have ACPI and platform that works almost the same. > > > > Sure. > > > This is where the problem begins. SCMI is quite well-defined for DT-based > > environments. > > Indeed and that is intentional. However, lots of concepts in SCMI already aligns > well with ACPI concepts just under different name most of the time. > > > Unfortunately, there are not too many mentions for the UEFI/ACPI based > > platforms. This is probably caused by the fact that SCMI overlaps with ACPI > > in some points like sensors or performance management. > > Correct. > > > However, SCMI has one single advantage over the ACPI, namely it defines pretty > > nice framework for clocks management. ACPI is silent in this regard. > > Yes but any reasons why that can't be part of standard power methods. >
I should've explained it slightly better. Of course SCMI does great work when managing the clocks. However, what the intent here is the SCMI clocks register itself nicely into common clk framework. I don't intend to change the clock. SCP in my case is invariant source. Hence, no need for ASL methods. I just want to read given clock and have it registered in clk framework. Reason for that is simple, there's a good code in SCMI. I don't want to create own driver for that. I just have to be able to start SCMI when only source of hardware information is ACPI/UEFI.
> > It is just delegating clocks to OSPM. The kernel and OS should be unaware of > > the clocks management according to the ACPI spec. This surely does work for x86, > > but not so well for ARM. > > > > While that could be true, why do you need to manage the clocks so much outside > the standard power methods in ACPI. > > > Wonder, if you had chance discuss using SCMI in ACPI based environments? > > We have discussed in the past, SCMI can be used in ACPI abstracted under the > existing well defined methods(I know you will be shouting not clocks but > we need to know why that can't be done with standards device power/state > methods. > > > I am mostly interested in the description using ACPI tables and eventually > > the bindings for ACPI tables. I need something portable and > > in line with future development for SCMI. > > > > I don't understand what you mean by that. > > > Now the review of existing threads and forums returns almost nothing. > > The SCMI specification wasn't too helpful either. > > I did the code review too. But only thing I see are bindings for DT (v5.17-rc2). > > It will help greatly if you have any advice or pointer that I could try. > > Has anyone done this before? > > Not sure if anyone has told so in the public ML. However if you want to > run same platform both in ACPI and DT with same firmware, you can write > ASL to manage clocks via SCMI command so that same firmware can be used. > > I may be giving to generic info and may not be addressing your specific > issue, but I need specific info to address that. What have you tried with > ACPI so far, what are the issues you are seeing, ...etc ?
This is still most specific thing I could have found on the internet. So, to clear up the clouds about my idea.
I have platform with UEFI/ACPI only. I want my clocks to be registered. So, I use SCMI. The framework needs bindings for proper registration. Instead using DT approach:
firmware { scmi { compatible = "arm-scmi"; /* ... */
clks: protocol@14 { reg = <0x14>; #clock-cells = <1>; } } }
I add ACPI match table to SCMI code and present it with matching ACPI tables. It might look like this:
Scope (_SB) { Device (ARMSCMI) { Name (_HID, "ASCM0001") Name (_UID, 0)
Method (_STA) { Return (0xF) }
Device (CLKS) { Name (_ADR, 0x14) Name (_UID, 0)
Method (_STA) { Return (0xF) } } } }
Then SCMI registers the clocks protocol and does remaining magic.
Kind regards, Wojciech.
> -- > Regards, > Sudeep
| |