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 at 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 at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel