From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A9363C433EF for ; Mon, 7 Feb 2022 10:13:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ocJyxdJL5f8ic4mYv21irLX6QlsNpwE7thkbj1EuQ48=; b=RW4hrtwHFtlEHr yRzQkdAmcgu3wb6+lyeVrHbzfHhttZs4WKhyZrKvcyOzFDkVbLdWmi8aNHwgZvVdc/qpZoYGbavxB ydLwogv7cRSFu+oVn2qqsBPAUQ9uuNvhBLxEvDy9ef/+mDizo4sLXtbzeY2dh26W2pw1PU8xqUsOj AMcIe3wePV3LU5CE3D8kKPbxLpweQBxhtThEGrwhzqs0Ecv56Rrpj4sV2KjJJHFys6ymS0Rr1bFQ2 741ozf4+M5WTv2aZEp9MauB1wrvltJQn2Xwv6zY2sWhMacJNh82MCWLXv6t224tz9GKGpVRiOWB7D cGtmWAVFfryN+n5oxTqw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nH106-009mev-Sc; Mon, 07 Feb 2022 10:12:03 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nH0zM-009mN5-6k for linux-arm-kernel@lists.infradead.org; Mon, 07 Feb 2022 10:11:17 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BE3846D; Mon, 7 Feb 2022 02:11:12 -0800 (PST) Received: from bogus (unknown [10.57.41.150]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9A3223F718; Mon, 7 Feb 2022 02:11:11 -0800 (PST) Date: Mon, 7 Feb 2022 10:10:24 +0000 From: Sudeep Holla To: Wojciech Bartczak Cc: cristian.marussi@arm.com, linux-arm-kernel@lists.infradead.org, Sudeep Holla , linux-kernel@vger.kernel.org, sbalcerak@marvell.com Subject: Re: Mixing SCMI and ACPI? Message-ID: <20220207101024.rpcbbhtd6y6g7ykc@bogus> References: <20220204142150.glsu6ujjtqpcktjp@bogus> <20220204181641.28176-1-wbartczak@marvell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220204181641.28176-1-wbartczak@marvell.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220207_021116_349244_A534E193 X-CRM114-Status: GOOD ( 21.28 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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