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

--
Regards,
Sudeep