Re: Mixing SCMI and ACPI?

[Wojciech Bartczak]

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