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
On Fri, Feb 04, 2022 at 10:16:41AM -0800, Wojciech Bartczak wrote:
>
> 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.
>
I don't agree, more details below.
> 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.
Just to read clock rates ?
> 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)
> }
> }
> }
> }
>
A *BIG FAT NACK* for this approach. SCMI is not intended to be used like
this on ACPI. Since ACPI has not support for clocks, you can't just do
something like above for clocks and rest of the SCMI support in the standard
ACPI methods.
> Then SCMI registers the clocks protocol and does remaining magic.
>
Sure, but what is the issue if you don't have this SCMI clock support
in ACPI system ? Can you provide details as what is failing ?
--
Regards,
Sudeep