Mixing SCMI and ACPI?

Mixing SCMI and ACPI?

[Wojciech Bartczak]

Hi Folks,

I have been working with SCMI for some time now.
Here at Marvell, we use very common software stack. 
Mostly ATF, U-Boot and Kernel. With this software stack, SCMI integration is
just a matter of following the common sense.
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. 

This is where the problem begins. SCMI is quite well-defined for 
DT-based environments. 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.
However, SCMI has one single advantage over the ACPI, namely it defines pretty
nice framework for clocks management. ACPI is silent in this regard.
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.

Wonder, if you had chance discuss using SCMI in ACPI based environments?
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.

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?

Thanks,
Wojciech.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Mixing SCMI and ACPI?

[Sudeep Holla]

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.

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

--
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Mixing SCMI and ACPI?

[Sudeep Holla]

On Fri, Feb 04, 2022 at 02:21:50PM +0000, Sudeep Holla wrote:
> Hi Wojciech,
> 
> Please cc me too for anything SCMI related in the future.
> 

Ignore this, I somehow imagined I wasn't cc-ed while you had actually
cc-ed me. Sorry for the noise.

-- 
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Mixing SCMI and ACPI?

[Sudeep Holla]

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Mixing SCMI and ACPI?

[Wojciech Bartczak]

On Mon, Feb 07, 2022 at 10:10:24AM +0000, Sudeep Holla wrote:
> 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 ?
> 
I have at least one driver that requires the clock information to do
fancy tuning and clocks division 'drivers/mmc/host/cavium*.[ch]'.
Without the clock info MMC driver is useless. Moreover clock is configurable,
so I can't stick with sane default. That said, this is no on the Kernel
to solve, but on me and the IP designer :). Btw. this is just example,
there are more gems in this crown.

I understand my approach is convoluted. I also don't agree with it
completely. The goal was to have SCMI to minimize porting effort for
some drivers (MMC). At least until full ACPI implementation.
Mostly the ones that use the common clk framework.
Additionally, maybe have some extras for the platform.
SCMI could provide clocks, drivers can read it as usually.
Nevertheless, more I think about it then more I see all the nasty side
effects of this approach. I completely agree with NACK here.

Over a weekend I did additional research. I have found this post

https://lore.kernel.org/lkml/CABe79T6zQ_7Ycws5b=xaQ3edpVn1QPQyWd9p24eqLGpYbdtt0A@mail.gmail.com/#t

(Thanks Google for keeping it on 10th page).

This sheds some light on the topic. I was able to put my hands on
"Server Base System Architecture" and "Arm Base Boot Requirements".
This gives me extra ideas how to proceed.

Thank you for your help here! I think I will drop the topic at this
moment.

Kind regards,
Wojciech.

> --
> Regards,
> Sudeep
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel