Message ID | 20230926-pcc_defines-v1-1-0f925a1658fd@arm.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:cae8:0:b0:403:3b70:6f57 with SMTP id r8csp1876610vqu; Tue, 26 Sep 2023 05:35:16 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHucJqHCkfQpZ18bqC0oMh62l9xz7ZURFG+QhCW9XY0Dtl1sxKDxvEUW06gTrLWLSauF44X X-Received: by 2002:a05:6e02:1524:b0:351:5322:b815 with SMTP id i4-20020a056e02152400b003515322b815mr1988301ilu.21.1695731715710; Tue, 26 Sep 2023 05:35:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695731715; cv=none; d=google.com; s=arc-20160816; b=ZWcIhTAuZzj1P1wK1LoQuBGy82iKAJBAUOUVwMZXQO5PoHXRRKAcH2hs0i+HZyuli3 Imf+27hHcn0wXJHvj9F7ayDxpsjSFs5Ibg6nV7K+vh8ZOPvpAQdYOZnjYtlnVE1vklH7 rsWcBfYOWS10UPB/2LO3xMS8X0aTEOJUTyaGYcpzVAhz/irqHQAsSBYmtumL/cRYVewv 0pMzF+PHWYZ1Z6E5CznlzPTCGFSy1j+F3g2WWlonbuj5/rPLUPQt7ZT5CGVkLlO5tFJN OErfgqAyzndfUkSCxuWbUXrdoqy0pyExGs3GANknizNCqlrUXSJR9Sy5vwxjR6eWnj3R Cy8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:in-reply-to:references:message-id :content-transfer-encoding:mime-version:subject:date:from; bh=jdb7y3O6ZZByErQXhUgt50+tEm1+nnyRt17mcebengE=; fh=3cZkl5QQty6xKyDuHIlg2/YE6vxd8RaugrelrzDpK1A=; b=mwI6KWTDMzkb7DawBOBwjjH8K8MnYpyDr6TJvzc0gBOBLXUE0KkvPK8rLOg7xdKh4N NhvLCP2OSDWQKTzJ6PrhtgRFOen8521qd91RGEe/TNsTJRRVsRuPMVwb0EM9KtjxzcZ4 JM3v/vFXuWB/HEcIg0R9T+VY7c2yd0Hw578QfbwTOdaf3v7JixBnEXCET4Oiw4pQ1sSj K/vBokYWQWgz5owua+4fACvdTN6V4NWPwbPAJxKn/cC23s0UnGR8IpGY6c7ziTB+XbNZ JAAXDpj/chzIm1BXlVU9W5zG8iilgXsbOrurt9WAvscit0yu0H/2BC/W/ST/qEBfCEsD d4WA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from agentk.vger.email (agentk.vger.email. [2620:137:e000::3:2]) by mx.google.com with ESMTPS id d189-20020a6336c6000000b0057c7341d55bsi1618250pga.391.2023.09.26.05.35.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Sep 2023 05:35:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id A71E181D82E2; Tue, 26 Sep 2023 05:28:46 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234645AbjIZM2Z (ORCPT <rfc822;pwkd43@gmail.com> + 28 others); Tue, 26 Sep 2023 08:28:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42500 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234632AbjIZM2W (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 26 Sep 2023 08:28:22 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 03C4D10E; Tue, 26 Sep 2023 05:28:16 -0700 (PDT) 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 EEE4ADA7; Tue, 26 Sep 2023 05:28:53 -0700 (PDT) Received: from e103737-lin.cambridge.arm.com (e103737-lin.cambridge.arm.com [10.1.197.49]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A69B53F6C4; Tue, 26 Sep 2023 05:28:14 -0700 (PDT) From: Sudeep Holla <sudeep.holla@arm.com> Date: Tue, 26 Sep 2023 13:28:00 +0100 Subject: [PATCH 1/3] ACPI: PCC: Add PCC shared memory region command and status bitfields MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20230926-pcc_defines-v1-1-0f925a1658fd@arm.com> References: <20230926-pcc_defines-v1-0-0f925a1658fd@arm.com> In-Reply-To: <20230926-pcc_defines-v1-0-0f925a1658fd@arm.com> To: linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org, linux-acpi@vger.kernel.org Cc: Sudeep Holla <sudeep.holla@arm.com>, "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>, Andi Shyti <andi.shyti@kernel.org>, Jean Delvare <jdelvare@suse.com>, Guenter Roeck <linux@roeck-us.net> X-Mailer: b4 0.12.3 X-Developer-Signature: v=1; a=openpgp-sha256; l=1291; i=sudeep.holla@arm.com; h=from:subject:message-id; bh=NVqjx3KgceHBDTtKRT2jKbwqByxepAzV4t81BveYQ5M=; b=owEBbQKS/ZANAwAIAQBBurwxfuKYAcsmYgBlEs5cZoCKp1fj4orfty+KxtexocPaVbXd7vjYf uLKxbZc9vGJAjMEAAEIAB0WIQS6ceUSBvMeskPdk+EAQbq8MX7imAUCZRLOXAAKCRAAQbq8MX7i mLPaD/4vBWFKN8LW/fljCcv/jfrVigPDq5yyR4l6t/r19KeSBzENurRpQFPTxwg+oa88Wvnyu6s UO/+1IdUR4MotZ48Sb2rZUJKqPQP4iUGGPlC+q9EVW5TrTFpBBI+kNMxfp6mqSj6xCvKo+oROpE IPc3DJEUogDgTu1z70K7Ll5C1mxzmhJrZMEo/f5WGxXUETEfpb93rhUWcHSwC9flEc5a6gETG36 1fZ/rQHy2UVdLaNwpPQDeCpSl4CXcxyPk8FmKmlV/2bm2ZECgd5JgjuREZ56NA8mEcQN2VA4ODL pDYMQAuSTWXnAK0f3dMdMsXDoE1SzwcpAg5nlouZPEjg6790k2WMpK/oAPlqQA6X2OA+PLWnztu n+euqI/RQhCFohzKjvrW5/X5jMXCiVDgG7+wfoSeuWURqkCYSPD9cPQza0OP2FP7mHE9/lJv4I5 0RKBAHZpM2kjOgUcyziNGhnNx6pci8rVZXh8BytvUzpo2treIB/6vabmJiwWIjGyTa25IWibQhj SuhHVcAPVtWsEfte13t3DoLLphVQxCddRyrJOgrB5nXGTDJJpIgJZUPZL6JSWlW9gDWm9uVeW08 zJSdNwCG+8lwVfWL8L1nBTNA89dab4dcVaZmX4LoHvqRWud9C6Ss17aygeNx0zMdXXaw/mazg2N y+70fICPW4QTJnw== X-Developer-Key: i=sudeep.holla@arm.com; a=openpgp; fpr=7360A21742ADF5A11767C1C139CFD4755FE2D5B4 X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Tue, 26 Sep 2023 05:28:46 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778103579735168897 X-GMAIL-MSGID: 1778103579735168897 |
Series |
ACPI: PCC: Define and use the common PCC shared memory regions related macros
|
|
Commit Message
Sudeep Holla
Sept. 26, 2023, 12:28 p.m. UTC
Define the common macros to use when referring to various bitfields in
the PCC generic communications channel command and status fields.
Currently different drivers that need to use these bitfields have defined
these locally. This common macro is intended to consolidate and replace
those.
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
include/acpi/pcc.h | 11 +++++++++++
1 file changed, 11 insertions(+)
Comments
Hi Sudeep, 在 2023/9/26 20:28, Sudeep Holla 写道: > Define the common macros to use when referring to various bitfields in > the PCC generic communications channel command and status fields. Can you define the bit0 macros in the "flags" for Extended PCC Subspace Shared Memory Region? > > Currently different drivers that need to use these bitfields have defined > these locally. This common macro is intended to consolidate and replace > those. > > Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > --- > include/acpi/pcc.h | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/include/acpi/pcc.h b/include/acpi/pcc.h > index 73e806fe7ce7..66d9934c2ee4 100644 > --- a/include/acpi/pcc.h > +++ b/include/acpi/pcc.h > @@ -18,7 +18,18 @@ struct pcc_mbox_chan { > u16 min_turnaround_time; > }; > > +/* Generic Communications Channel Shared Memory Region */ > +#define PCC_SIGNATURE 0x50424300 Why is this signature 0x50424300? In ACPI spec, this signature is all 0x50434303. > +/* Generic Communications Channel Command Field */ > +#define PCC_CMD_GENERATE_DB_INTR BIT(15) > +/* Generic Communications Channel Status Field */ > +#define PCC_STATUS_CMD_COMPLETE BIT(0) > +#define PCC_STATUS_SCI_DOORBELL BIT(1) > +#define PCC_STATUS_ERROR BIT(2) > +#define PCC_STATUS_PLATFORM_NOTIFY BIT(3) > + > #define MAX_PCC_SUBSPACES 256 > + > #ifdef CONFIG_PCC > extern struct pcc_mbox_chan * > pcc_mbox_request_channel(struct mbox_client *cl, int subspace_id); >
On Wed, Sep 27, 2023 at 10:07:15AM +0800, lihuisong (C) wrote: > Hi Sudeep, > > 在 2023/9/26 20:28, Sudeep Holla 写道: > > Define the common macros to use when referring to various bitfields in > > the PCC generic communications channel command and status fields. > > Can you define the bit0 macros in the "flags" for Extended PCC Subspace > Shared Memory Region? Sure I will take a look and include it in v2 if applicable. > > > > Currently different drivers that need to use these bitfields have defined > > these locally. This common macro is intended to consolidate and replace > > those. > > > > Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > --- > > include/acpi/pcc.h | 11 +++++++++++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/include/acpi/pcc.h b/include/acpi/pcc.h > > index 73e806fe7ce7..66d9934c2ee4 100644 > > --- a/include/acpi/pcc.h > > +++ b/include/acpi/pcc.h > > @@ -18,7 +18,18 @@ struct pcc_mbox_chan { > > u16 min_turnaround_time; > > }; > > +/* Generic Communications Channel Shared Memory Region */ > > +#define PCC_SIGNATURE 0x50424300 > Why is this signature 0x50424300? It is as per the specification. > In ACPI spec, this signature is all 0x50434303. No, not exactly. It is just an example. The PCC signature - The signature of a subspace is computed by a bitwise-or of the value 0x50434300 with the subspace ID. For example, subspace 3 has signature 0x50434303 And I see the driver you mentioned(drivers/soc/hisilicon/kunpeng_hccs.c) is doing the right thing. I am bit confused as why you being the author of the driver are now confused.
在 2023/9/27 21:59, Sudeep Holla 写道: > On Wed, Sep 27, 2023 at 10:07:15AM +0800, lihuisong (C) wrote: >> Hi Sudeep, >> >> 在 2023/9/26 20:28, Sudeep Holla 写道: >>> Define the common macros to use when referring to various bitfields in >>> the PCC generic communications channel command and status fields. >> Can you define the bit0 macros in the "flags" for Extended PCC Subspace >> Shared Memory Region? > Sure I will take a look and include it in v2 if applicable. Thanks > >>> Currently different drivers that need to use these bitfields have defined >>> these locally. This common macro is intended to consolidate and replace >>> those. >>> >>> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> >>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> >>> --- >>> include/acpi/pcc.h | 11 +++++++++++ >>> 1 file changed, 11 insertions(+) >>> >>> diff --git a/include/acpi/pcc.h b/include/acpi/pcc.h >>> index 73e806fe7ce7..66d9934c2ee4 100644 >>> --- a/include/acpi/pcc.h >>> +++ b/include/acpi/pcc.h >>> @@ -18,7 +18,18 @@ struct pcc_mbox_chan { >>> u16 min_turnaround_time; >>> }; >>> +/* Generic Communications Channel Shared Memory Region */ >>> +#define PCC_SIGNATURE 0x50424300 >> Why is this signature 0x50424300? > It is as per the specification. > >> In ACPI spec, this signature is all 0x50434303. > No, not exactly. It is just an example. > The PCC signature - The signature of a subspace is computed by a bitwise-or > of the value 0x50434300 with the subspace ID. For example, subspace 3 has > signature 0x50434303 Sorry for my mistake. I know this. I mean, why doesn't the following macro follow spec and define this signature as 0x504*3*430. "#define PCC_SIGNATURE **0x504*2*4300*"* Because it seems that all version of ACPI spec is 0x5043430. > > And I see the driver you mentioned(drivers/soc/hisilicon/kunpeng_hccs.c) > is doing the right thing. I am bit confused as why you being the author > of the driver are now confused. I used 0x50424300 instead of 0x50424300 according to the spec. >
On Thu, Sep 28, 2023 at 11:49:25AM +0800, lihuisong (C) wrote: > > 在 2023/9/27 21:59, Sudeep Holla 写道: > > On Wed, Sep 27, 2023 at 10:07:15AM +0800, lihuisong (C) wrote: [...] > > > > +/* Generic Communications Channel Shared Memory Region */ > > > > +#define PCC_SIGNATURE 0x50424300 > > > Why is this signature 0x50424300? > > It is as per the specification. > > > > > In ACPI spec, this signature is all 0x50434303. > > No, not exactly. It is just an example. > > The PCC signature - The signature of a subspace is computed by a bitwise-or > > of the value 0x50434300 with the subspace ID. For example, subspace 3 has > > signature 0x50434303 > Sorry for my mistake. I know this. > I mean, why doesn't the following macro follow spec and define this > signature as 0x504*3*430. > "#define PCC_SIGNATURE **0x504*2*4300*"* > Because it seems that all version of ACPI spec is 0x5043430. Sorry my mistake. Stupidly the existing drivers have it wrong and I just copied them without paying much attention. I will fix it up. It must be 0x50434300 instead of 0x50424300. If you have no other comments, can you please ack v2 patch 4/4 changing soc kunpeng_hccs driver. I will fixup the PCC_SIGNATURE and send it as part of my PR to Rafael. Refer [1] for the change in PCC_SIGNATURE, sorry for missing the point. I was confident that the existing code is correct :), but I am wrong.
在 2023/9/28 19:11, Sudeep Holla 写道: > On Thu, Sep 28, 2023 at 11:49:25AM +0800, lihuisong (C) wrote: >> 在 2023/9/27 21:59, Sudeep Holla 写道: >>> On Wed, Sep 27, 2023 at 10:07:15AM +0800, lihuisong (C) wrote: > [...] > >>>>> +/* Generic Communications Channel Shared Memory Region */ >>>>> +#define PCC_SIGNATURE 0x50424300 >>>> Why is this signature 0x50424300? >>> It is as per the specification. >>> >>>> In ACPI spec, this signature is all 0x50434303. >>> No, not exactly. It is just an example. >>> The PCC signature - The signature of a subspace is computed by a bitwise-or >>> of the value 0x50434300 with the subspace ID. For example, subspace 3 has >>> signature 0x50434303 >> Sorry for my mistake. I know this. >> I mean, why doesn't the following macro follow spec and define this >> signature as 0x504*3*430. >> "#define PCC_SIGNATURE **0x504*2*4300*"* >> Because it seems that all version of ACPI spec is 0x5043430. > Sorry my mistake. Stupidly the existing drivers have it wrong and I just > copied them without paying much attention. I will fix it up. It must be > 0x50434300 instead of 0x50424300. If you have no other comments, can you They are very similar.😁 > please ack v2 patch 4/4 changing soc kunpeng_hccs driver. I will fixup > the PCC_SIGNATURE and send it as part of my PR to Rafael. ok > > Refer [1] for the change in PCC_SIGNATURE, sorry for missing the point. I > was confident that the existing code is correct :), but I am wrong. >
diff --git a/include/acpi/pcc.h b/include/acpi/pcc.h index 73e806fe7ce7..66d9934c2ee4 100644 --- a/include/acpi/pcc.h +++ b/include/acpi/pcc.h @@ -18,7 +18,18 @@ struct pcc_mbox_chan { u16 min_turnaround_time; }; +/* Generic Communications Channel Shared Memory Region */ +#define PCC_SIGNATURE 0x50424300 +/* Generic Communications Channel Command Field */ +#define PCC_CMD_GENERATE_DB_INTR BIT(15) +/* Generic Communications Channel Status Field */ +#define PCC_STATUS_CMD_COMPLETE BIT(0) +#define PCC_STATUS_SCI_DOORBELL BIT(1) +#define PCC_STATUS_ERROR BIT(2) +#define PCC_STATUS_PLATFORM_NOTIFY BIT(3) + #define MAX_PCC_SUBSPACES 256 + #ifdef CONFIG_PCC extern struct pcc_mbox_chan * pcc_mbox_request_channel(struct mbox_client *cl, int subspace_id);