Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Wojciech Bartczak <wbartczak@marvell.com>
Cc: cristian.marussi@arm.com, linux-arm-kernel@lists.infradead.org,
	Sudeep Holla <sudeep.holla@arm.com>,
	linux-kernel@vger.kernel.org, sbalcerak@marvell.com
Subject: Re: Mixing SCMI and ACPI?
Date: Mon, 7 Feb 2022 10:10:24 +0000	[thread overview]
Message-ID: <20220207101024.rpcbbhtd6y6g7ykc@bogus> (raw)
In-Reply-To: <20220204181641.28176-1-wbartczak@marvell.com>

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

  reply	other threads:[~2022-02-07 10:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-04 13:32 Mixing SCMI and ACPI? Wojciech Bartczak
2022-02-04 14:21 ` Sudeep Holla
2022-02-04 14:25   ` Sudeep Holla
2022-02-04 18:16   ` Wojciech Bartczak
2022-02-07 10:10     ` Sudeep Holla [this message]
2022-02-07 23:37       ` Wojciech Bartczak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220207101024.rpcbbhtd6y6g7ykc@bogus \
    --to=sudeep.holla@arm.com \
    --cc=cristian.marussi@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sbalcerak@marvell.com \
    --cc=wbartczak@marvell.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox