Message ID | 20231006164206.40710-3-quic_nkela@quicinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:a888:0:b0:403:3b70:6f57 with SMTP id x8csp459308vqo; Fri, 6 Oct 2023 09:44:16 -0700 (PDT) X-Google-Smtp-Source: AGHT+IE0I47enRicOIgQPGTkw6lT8uHU4O8RruF+Q55pDptJJKpuBbH2hPNZpsH5GhtNP3YryITi X-Received: by 2002:a17:902:7084:b0:1b6:649b:92cc with SMTP id z4-20020a170902708400b001b6649b92ccmr7167295plk.69.1696610656012; Fri, 06 Oct 2023 09:44:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696610655; cv=none; d=google.com; s=arc-20160816; b=FoIWDR70RD1Iti30ZE0m2kdyRyPsjyZNGW74xpKQR7/gmJeoUkT7jQuS4w3yTmq8iA WEj1w7am3EFEvoW9uvrTlMcjhaHmQOe4NQCoZvwxYGsSWlQBfiEXA8qdGex+MR9FEXaA ZWxlGyxKLtTk0G7PXWj78QHbHL0s3mwAVo+BgqNEdbGn6rUgvngkmruA0Y9F4/lHyZWI z3GUIqOxv1HKF9RVyFob8WDVoOWREI1wz2EnjUFNABh4X5s1nsDjXu9uwLUUnOTBTJh0 wroKbWd0qX6PdZkxhp1y/wMLdaZOYmhqGS7L09rupTYgBoY9GOnRoc3hQryOA4fxIgEP Xhaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=kB8eOZJBMvny52vQeYnm+Wv5EpaqlsdgYlz93kNPdOw=; fh=GEq5dEC3I2ew8qX2rLc4VZLR0KApgkJja2wJiy1iHxw=; b=x8U4jj3tgbotnrxhPYdrQ5o7UQCn23nvxeSdquKYEbBkeVMeQx5JogemC/R5CM/Kj/ uh6UyYoP8DzKIU4xZZ2rNzst2Vz421G0NlHukldiD5yjVH0AYztvYobkA+lfp8GvHtOP IMigFk2nJxZQt5R9/3X1aPyLcRf8q6+Q5okyh01lphEDobBzAxxG5fUov7d2QN7fMhOQ ktrLCrVeP9y6u9juKtivn1LrU7RbA1FyElNArLJlXncaYIR6jhEK791dLtePuzxmap4i KYc5oUHlqZuEdgiPL25AHgUoIidMhQ+UIVE9gG2EyQNVEym1ZPFlVtfxvPh+WcG4QtSZ A4qw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=iVTJOX+0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id q16-20020a17090311d000b001c0c86a541asi4389867plh.375.2023.10.06.09.44.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Oct 2023 09:44:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=iVTJOX+0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id ECD7280972B2; Fri, 6 Oct 2023 09:44:07 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233113AbjJFQnc (ORCPT <rfc822;ezelljr.billy@gmail.com> + 18 others); Fri, 6 Oct 2023 12:43:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36082 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232991AbjJFQnW (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 6 Oct 2023 12:43:22 -0400 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5E4C41B4; Fri, 6 Oct 2023 09:42:49 -0700 (PDT) Received: from pps.filterd (m0279872.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 396DNswK011104; Fri, 6 Oct 2023 16:42:26 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type; s=qcppdkim1; bh=kB8eOZJBMvny52vQeYnm+Wv5EpaqlsdgYlz93kNPdOw=; b=iVTJOX+0DQZv/ghNbI/p5AAFznz6zmJ8QQaCQgIYKZl1tRzqk8EIOGSJt3eNVICdqTCQ Zwb/aTMmNBBKLY2YZQDiWac/zu+yHeSnEW9nRFY8YB3SrcsUJLdYo6FkxHLV0SBSw3Qe OuHCAIMZF6t/Rvjiy3WZU/bGwIISRkt1oZEQF2BVtS7fBxuXxYp3sU5nwX+S7NHUYfop +/DVPPOz0j95pH9pkWFZ2gFJf864/RO7SSIqajAsetSgzt2+dpcjJEqEUBXGADrnRC2j v60T/7yXJ60zI1r2/BWvtwvuRH5meQ76zOBGeYXgRDUQCqqtuaWOAZIspRW6Os0QRr0M 1A== Received: from nalasppmta04.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3thrjduv17-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 06 Oct 2023 16:42:26 +0000 Received: from nalasex01c.na.qualcomm.com (nalasex01c.na.qualcomm.com [10.47.97.35]) by NALASPPMTA04.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 396GgOd2017744 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 6 Oct 2023 16:42:25 GMT Received: from car-linux11.qualcomm.com (10.80.80.8) by nalasex01c.na.qualcomm.com (10.47.97.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.30; Fri, 6 Oct 2023 09:42:24 -0700 From: Nikunj Kela <quic_nkela@quicinc.com> To: <sudeep.holla@arm.com> CC: <cristian.marussi@arm.com>, <robh+dt@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>, <andersson@kernel.org>, <konrad.dybcio@linaro.org>, <linux-arm-kernel@lists.infradead.org>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>, Nikunj Kela <quic_nkela@quicinc.com> Subject: [PATCH v5 2/2] firmware: arm_scmi: Add qcom smc/hvc transport support Date: Fri, 6 Oct 2023 09:42:06 -0700 Message-ID: <20231006164206.40710-3-quic_nkela@quicinc.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20231006164206.40710-1-quic_nkela@quicinc.com> References: <20230718160833.36397-1-quic_nkela@quicinc.com> <20231006164206.40710-1-quic_nkela@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nalasex01c.na.qualcomm.com (10.47.97.35) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-ORIG-GUID: FOxYL3WpXLFpz8jxYFS1weZUFJ0vQZzL X-Proofpoint-GUID: FOxYL3WpXLFpz8jxYFS1weZUFJ0vQZzL X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.267,Aquarius:18.0.980,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-10-06_12,2023-10-06_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 priorityscore=1501 phishscore=0 mlxscore=0 mlxlogscore=999 impostorscore=0 bulkscore=0 suspectscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2309180000 definitions=main-2310060125 X-Spam-Status: No, score=2.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.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 (fry.vger.email [0.0.0.0]); Fri, 06 Oct 2023 09:44:08 -0700 (PDT) X-Spam-Level: ** X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779025215106593176 X-GMAIL-MSGID: 1779025215106593176 |
Series |
Add qcom smc/hvc transport support
|
|
Commit Message
Nikunj Kela
Oct. 6, 2023, 4:42 p.m. UTC
This change adds the support for SCMI message exchange on Qualcomm
virtual platforms.
The hypervisor associates an object-id also known as capability-id
with each smc/hvc doorbell object. The capability-id is used to
identify the doorbell from the VM's capability namespace, similar
to a file-descriptor.
The hypervisor, in addition to the function-id, expects the capability-id
to be passed in x1 register when SMC/HVC call is invoked.
The capability-id is allocated by the hypervisor on bootup and is stored in
the shmem region by the firmware before starting Linux.
Signed-off-by: Nikunj Kela <quic_nkela@quicinc.com>
---
drivers/firmware/arm_scmi/driver.c | 1 +
drivers/firmware/arm_scmi/smc.c | 33 ++++++++++++++++++++++++++++--
2 files changed, 32 insertions(+), 2 deletions(-)
Comments
On Fri, Oct 06, 2023 at 09:42:06AM -0700, Nikunj Kela wrote: > This change adds the support for SCMI message exchange on Qualcomm > virtual platforms. > > The hypervisor associates an object-id also known as capability-id > with each smc/hvc doorbell object. The capability-id is used to > identify the doorbell from the VM's capability namespace, similar > to a file-descriptor. > > The hypervisor, in addition to the function-id, expects the capability-id > to be passed in x1 register when SMC/HVC call is invoked. > > The capability-id is allocated by the hypervisor on bootup and is stored in > the shmem region by the firmware before starting Linux. > > Signed-off-by: Nikunj Kela <quic_nkela@quicinc.com> Reviewed-by: Brian Masney <bmasney@redhat.com>
On Fri, Oct 06, 2023 at 09:42:06AM -0700, Nikunj Kela wrote: > This change adds the support for SCMI message exchange on Qualcomm > virtual platforms. > > The hypervisor associates an object-id also known as capability-id > with each smc/hvc doorbell object. The capability-id is used to > identify the doorbell from the VM's capability namespace, similar > to a file-descriptor. > > The hypervisor, in addition to the function-id, expects the capability-id > to be passed in x1 register when SMC/HVC call is invoked. > > The capability-id is allocated by the hypervisor on bootup and is stored in > the shmem region by the firmware before starting Linux. > Since you are happy to move to signed value, I assume you are happy to loose upper half of the range values ? Anyways after Bjorn pointed out inconsistency, I am thinking of moving all the values to unsigned long to work with both 32bit and 64bit. Does the below delta on top of this patch works for you and makes sense? -- Regards, Sudeep -->8 diff --git c/drivers/firmware/arm_scmi/smc.c i/drivers/firmware/arm_scmi/smc.c index bf0b7769c7b2..e00c5e81c8d9 100644 --- c/drivers/firmware/arm_scmi/smc.c +++ i/drivers/firmware/arm_scmi/smc.c @@ -15,6 +15,7 @@ #include <linux/of.h> #include <linux/of_address.h> #include <linux/of_irq.h> +#include <linux/limits.h> #include <linux/processor.h> #include <linux/slab.h> @@ -65,7 +66,7 @@ struct scmi_smc { unsigned long func_id; unsigned long param_page; unsigned long param_offset; - s64 cap_id; + unsigned long cap_id; }; static irqreturn_t smc_msg_done_isr(int irq, void *data) @@ -127,11 +128,11 @@ static int smc_chan_setup(struct scmi_chan_info *cinfo, struct device *dev, bool tx) { struct device *cdev = cinfo->dev; + unsigned long cap_id = ULONG_MAX; struct scmi_smc *scmi_info; resource_size_t size; struct resource res; struct device_node *np; - s64 cap_id = -EINVAL; u32 func_id; int ret; @@ -167,6 +168,7 @@ static int smc_chan_setup(struct scmi_chan_info *cinfo, struct device *dev, return ret; if (of_device_is_compatible(dev->of_node, "qcom,scmi-smc")) { + void __iomem *ptr = (void __iomem *)scmi_info->shmem + size - 8; /* The capability-id is kept in last 8 bytes of shmem. * +-------+ * | | @@ -177,12 +179,7 @@ static int smc_chan_setup(struct scmi_chan_info *cinfo, struct device *dev, * | capId | * +-------+ <-- size */ - -#ifdef CONFIG_64BIT - cap_id = ioread64((void *)scmi_info->shmem + size - 8); -#else - cap_id = ioread32((void *)scmi_info->shmem + size - 8); -#endif + memcpy_fromio(&cap_id, ptr, sizeof(cap_id)); } if (of_device_is_compatible(dev->of_node, "arm,scmi-smc-param")) { @@ -247,7 +244,7 @@ static int smc_send_message(struct scmi_chan_info *cinfo, shmem_tx_prepare(scmi_info->shmem, xfer, cinfo); - if (cap_id >= 0) + if (cap_id != ULONG_MAX) arm_smccc_1_1_invoke(scmi_info->func_id, cap_id, 0, 0, 0, 0, 0, 0, &res); else
On 10/9/2023 7:47 AM, Sudeep Holla wrote: > On Fri, Oct 06, 2023 at 09:42:06AM -0700, Nikunj Kela wrote: >> This change adds the support for SCMI message exchange on Qualcomm >> virtual platforms. >> >> The hypervisor associates an object-id also known as capability-id >> with each smc/hvc doorbell object. The capability-id is used to >> identify the doorbell from the VM's capability namespace, similar >> to a file-descriptor. >> >> The hypervisor, in addition to the function-id, expects the capability-id >> to be passed in x1 register when SMC/HVC call is invoked. >> >> The capability-id is allocated by the hypervisor on bootup and is stored in >> the shmem region by the firmware before starting Linux. >> > Since you are happy to move to signed value, I assume you are happy to loose > upper half of the range values ? > > Anyways after Bjorn pointed out inconsistency, I am thinking of moving > all the values to unsigned long to work with both 32bit and 64bit. > > Does the below delta on top of this patch works for you and makes sense? This looks good to me. Will do some testing and float v6 with the changes you suggested below. Thanks > > -- > Regards, > Sudeep > > -->8 > diff --git c/drivers/firmware/arm_scmi/smc.c i/drivers/firmware/arm_scmi/smc.c > index bf0b7769c7b2..e00c5e81c8d9 100644 > --- c/drivers/firmware/arm_scmi/smc.c > +++ i/drivers/firmware/arm_scmi/smc.c > @@ -15,6 +15,7 @@ > #include <linux/of.h> > #include <linux/of_address.h> > #include <linux/of_irq.h> > +#include <linux/limits.h> > #include <linux/processor.h> > #include <linux/slab.h> > > @@ -65,7 +66,7 @@ struct scmi_smc { > unsigned long func_id; > unsigned long param_page; > unsigned long param_offset; > - s64 cap_id; > + unsigned long cap_id; > }; > > static irqreturn_t smc_msg_done_isr(int irq, void *data) > @@ -127,11 +128,11 @@ static int smc_chan_setup(struct scmi_chan_info *cinfo, struct device *dev, > bool tx) > { > struct device *cdev = cinfo->dev; > + unsigned long cap_id = ULONG_MAX; > struct scmi_smc *scmi_info; > resource_size_t size; > struct resource res; > struct device_node *np; > - s64 cap_id = -EINVAL; > u32 func_id; > int ret; > > @@ -167,6 +168,7 @@ static int smc_chan_setup(struct scmi_chan_info *cinfo, struct device *dev, > return ret; > > if (of_device_is_compatible(dev->of_node, "qcom,scmi-smc")) { > + void __iomem *ptr = (void __iomem *)scmi_info->shmem + size - 8; > /* The capability-id is kept in last 8 bytes of shmem. > * +-------+ > * | | > @@ -177,12 +179,7 @@ static int smc_chan_setup(struct scmi_chan_info *cinfo, struct device *dev, > * | capId | > * +-------+ <-- size > */ > - > -#ifdef CONFIG_64BIT > - cap_id = ioread64((void *)scmi_info->shmem + size - 8); > -#else > - cap_id = ioread32((void *)scmi_info->shmem + size - 8); > -#endif > + memcpy_fromio(&cap_id, ptr, sizeof(cap_id)); > } > > if (of_device_is_compatible(dev->of_node, "arm,scmi-smc-param")) { > @@ -247,7 +244,7 @@ static int smc_send_message(struct scmi_chan_info *cinfo, > > shmem_tx_prepare(scmi_info->shmem, xfer, cinfo); > > - if (cap_id >= 0) > + if (cap_id != ULONG_MAX) > arm_smccc_1_1_invoke(scmi_info->func_id, cap_id, 0, 0, 0, 0, 0, > 0, &res); > else >
On Mon, Oct 09, 2023 at 07:59:08AM -0700, Nikunj Kela wrote: > > On 10/9/2023 7:47 AM, Sudeep Holla wrote: > > On Fri, Oct 06, 2023 at 09:42:06AM -0700, Nikunj Kela wrote: > > > This change adds the support for SCMI message exchange on Qualcomm > > > virtual platforms. > > > > > > The hypervisor associates an object-id also known as capability-id > > > with each smc/hvc doorbell object. The capability-id is used to > > > identify the doorbell from the VM's capability namespace, similar > > > to a file-descriptor. > > > > > > The hypervisor, in addition to the function-id, expects the capability-id > > > to be passed in x1 register when SMC/HVC call is invoked. > > > > > > The capability-id is allocated by the hypervisor on bootup and is stored in > > > the shmem region by the firmware before starting Linux. > > > > > Since you are happy to move to signed value, I assume you are happy to loose > > upper half of the range values ? > > > > Anyways after Bjorn pointed out inconsistency, I am thinking of moving > > all the values to unsigned long to work with both 32bit and 64bit. > > > > Does the below delta on top of this patch works for you and makes sense? > > This looks good to me. Will do some testing and float v6 with the changes > you suggested below. Thanks > Please refer or use the patch from [1] when reposting. I rebased on my patch[2] that I posted few minutes back. I am trying to finalise the branch and send PR in next couple of days, so please test and post sooner. Sorry for the rush. -- Regards, Sudeep [1] https://git.kernel.org/sudeep.holla/h/for-next/scmi/updates [2] https://lore.kernel.org/r/20231009152049.1428872-1-sudeep.holla@arm.com
On 10/9/2023 8:29 AM, Sudeep Holla wrote: > On Mon, Oct 09, 2023 at 07:59:08AM -0700, Nikunj Kela wrote: >> On 10/9/2023 7:47 AM, Sudeep Holla wrote: >>> On Fri, Oct 06, 2023 at 09:42:06AM -0700, Nikunj Kela wrote: >>>> This change adds the support for SCMI message exchange on Qualcomm >>>> virtual platforms. >>>> >>>> The hypervisor associates an object-id also known as capability-id >>>> with each smc/hvc doorbell object. The capability-id is used to >>>> identify the doorbell from the VM's capability namespace, similar >>>> to a file-descriptor. >>>> >>>> The hypervisor, in addition to the function-id, expects the capability-id >>>> to be passed in x1 register when SMC/HVC call is invoked. >>>> >>>> The capability-id is allocated by the hypervisor on bootup and is stored in >>>> the shmem region by the firmware before starting Linux. >>>> >>> Since you are happy to move to signed value, I assume you are happy to loose >>> upper half of the range values ? >>> >>> Anyways after Bjorn pointed out inconsistency, I am thinking of moving >>> all the values to unsigned long to work with both 32bit and 64bit. >>> >>> Does the below delta on top of this patch works for you and makes sense? >> This looks good to me. Will do some testing and float v6 with the changes >> you suggested below. Thanks >> > Please refer or use the patch from [1] when reposting. I rebased on my > patch[2] that I posted few minutes back. I am trying to finalise the branch > and send PR in next couple of days, so please test and post sooner. Sorry > for the rush. Validated the patch from [1] below on Qualcomm ARM64 virtual platform using SMC64 convention. Thanks! > > -- > Regards, > Sudeep > [1] https://git.kernel.org/sudeep.holla/h/for-next/scmi/updates > [2] https://lore.kernel.org/r/20231009152049.1428872-1-sudeep.holla@arm.com
On Mon, Oct 09, 2023 at 10:49:44AM -0700, Nikunj Kela wrote: > > On 10/9/2023 8:29 AM, Sudeep Holla wrote: > > On Mon, Oct 09, 2023 at 07:59:08AM -0700, Nikunj Kela wrote: > > > On 10/9/2023 7:47 AM, Sudeep Holla wrote: > > > > On Fri, Oct 06, 2023 at 09:42:06AM -0700, Nikunj Kela wrote: > > > > > This change adds the support for SCMI message exchange on Qualcomm > > > > > virtual platforms. > > > > > > > > > > The hypervisor associates an object-id also known as capability-id > > > > > with each smc/hvc doorbell object. The capability-id is used to > > > > > identify the doorbell from the VM's capability namespace, similar > > > > > to a file-descriptor. > > > > > > > > > > The hypervisor, in addition to the function-id, expects the capability-id > > > > > to be passed in x1 register when SMC/HVC call is invoked. > > > > > > > > > > The capability-id is allocated by the hypervisor on bootup and is stored in > > > > > the shmem region by the firmware before starting Linux. > > > > > > > > > Since you are happy to move to signed value, I assume you are happy to loose > > > > upper half of the range values ? > > > > > > > > Anyways after Bjorn pointed out inconsistency, I am thinking of moving > > > > all the values to unsigned long to work with both 32bit and 64bit. > > > > > > > > Does the below delta on top of this patch works for you and makes sense? > > > This looks good to me. Will do some testing and float v6 with the changes > > > you suggested below. Thanks > > > > > Please refer or use the patch from [1] when reposting. I rebased on my > > patch[2] that I posted few minutes back. I am trying to finalise the branch > > and send PR in next couple of days, so please test and post sooner. Sorry > > for the rush. > > Validated the patch from [1] below on Qualcomm ARM64 virtual platform using > SMC64 convention. Thanks! > Thanks, since I have patched a bit, it is better if you post them so that we have a link for the exact patch on the list. Just pick up the patches from the branch[1] and post them as v6 with a change log so that all the details are captured for reference purposes.
On 10/9/2023 12:08 PM, Sudeep Holla wrote: > On Mon, Oct 09, 2023 at 10:49:44AM -0700, Nikunj Kela wrote: >> On 10/9/2023 8:29 AM, Sudeep Holla wrote: >>> On Mon, Oct 09, 2023 at 07:59:08AM -0700, Nikunj Kela wrote: >>>> On 10/9/2023 7:47 AM, Sudeep Holla wrote: >>>>> On Fri, Oct 06, 2023 at 09:42:06AM -0700, Nikunj Kela wrote: >>>>>> This change adds the support for SCMI message exchange on Qualcomm >>>>>> virtual platforms. >>>>>> >>>>>> The hypervisor associates an object-id also known as capability-id >>>>>> with each smc/hvc doorbell object. The capability-id is used to >>>>>> identify the doorbell from the VM's capability namespace, similar >>>>>> to a file-descriptor. >>>>>> >>>>>> The hypervisor, in addition to the function-id, expects the capability-id >>>>>> to be passed in x1 register when SMC/HVC call is invoked. >>>>>> >>>>>> The capability-id is allocated by the hypervisor on bootup and is stored in >>>>>> the shmem region by the firmware before starting Linux. >>>>>> >>>>> Since you are happy to move to signed value, I assume you are happy to loose >>>>> upper half of the range values ? >>>>> >>>>> Anyways after Bjorn pointed out inconsistency, I am thinking of moving >>>>> all the values to unsigned long to work with both 32bit and 64bit. >>>>> >>>>> Does the below delta on top of this patch works for you and makes sense? >>>> This looks good to me. Will do some testing and float v6 with the changes >>>> you suggested below. Thanks >>>> >>> Please refer or use the patch from [1] when reposting. I rebased on my >>> patch[2] that I posted few minutes back. I am trying to finalise the branch >>> and send PR in next couple of days, so please test and post sooner. Sorry >>> for the rush. >> Validated the patch from [1] below on Qualcomm ARM64 virtual platform using >> SMC64 convention. Thanks! >> > Thanks, since I have patched a bit, it is better if you post them so that > we have a link for the exact patch on the list. Just pick up the patches > from the branch[1] and post them as v6 with a change log so that all the > details are captured for reference purposes. v6 on its way, thanks! >
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c index 87383c05424b..09371f40d61f 100644 --- a/drivers/firmware/arm_scmi/driver.c +++ b/drivers/firmware/arm_scmi/driver.c @@ -2915,6 +2915,7 @@ static const struct of_device_id scmi_of_match[] = { #ifdef CONFIG_ARM_SCMI_TRANSPORT_SMC { .compatible = "arm,scmi-smc", .data = &scmi_smc_desc}, { .compatible = "arm,scmi-smc-param", .data = &scmi_smc_desc}, + { .compatible = "qcom,scmi-smc", .data = &scmi_smc_desc}, #endif #ifdef CONFIG_ARM_SCMI_TRANSPORT_VIRTIO { .compatible = "arm,scmi-virtio", .data = &scmi_virtio_desc}, diff --git a/drivers/firmware/arm_scmi/smc.c b/drivers/firmware/arm_scmi/smc.c index c193516a254d..3d594d65ab14 100644 --- a/drivers/firmware/arm_scmi/smc.c +++ b/drivers/firmware/arm_scmi/smc.c @@ -50,6 +50,8 @@ * @func_id: smc/hvc call function id * @param_page: 4K page number of the shmem channel * @param_offset: Offset within the 4K page of the shmem channel + * @cap_id: smc/hvc doorbell's capability id to be used on Qualcomm virtual + * platforms */ struct scmi_smc { @@ -63,6 +65,7 @@ struct scmi_smc { u32 func_id; u32 param_page; u32 param_offset; + s64 cap_id; }; static irqreturn_t smc_msg_done_isr(int irq, void *data) @@ -128,6 +131,7 @@ static int smc_chan_setup(struct scmi_chan_info *cinfo, struct device *dev, resource_size_t size; struct resource res; struct device_node *np; + s64 cap_id = -EINVAL; u32 func_id; int ret; @@ -162,6 +166,25 @@ static int smc_chan_setup(struct scmi_chan_info *cinfo, struct device *dev, if (ret < 0) return ret; + if (of_device_is_compatible(dev->of_node, "qcom,scmi-smc")) { + /* The capability-id is kept in last 8 bytes of shmem. + * +-------+ + * | | + * | shmem | + * | | + * | | + * +-------+ <-- (size - 8) + * | capId | + * +-------+ <-- size + */ + +#ifdef CONFIG_64BIT + cap_id = ioread64((void *)scmi_info->shmem + size - 8); +#else + cap_id = ioread32((void *)scmi_info->shmem + size - 8); +#endif + } + if (of_device_is_compatible(dev->of_node, "arm,scmi-smc-param")) { scmi_info->param_page = SHMEM_PAGE(res.start); scmi_info->param_offset = SHMEM_OFFSET(res.start); @@ -184,6 +207,7 @@ static int smc_chan_setup(struct scmi_chan_info *cinfo, struct device *dev, } scmi_info->func_id = func_id; + scmi_info->cap_id = cap_id; scmi_info->cinfo = cinfo; smc_channel_lock_init(scmi_info); cinfo->transport_info = scmi_info; @@ -213,6 +237,7 @@ static int smc_send_message(struct scmi_chan_info *cinfo, struct arm_smccc_res res; unsigned long page = scmi_info->param_page; unsigned long offset = scmi_info->param_offset; + long cap_id = (long)scmi_info->cap_id; /* * Channel will be released only once response has been @@ -222,8 +247,12 @@ static int smc_send_message(struct scmi_chan_info *cinfo, shmem_tx_prepare(scmi_info->shmem, xfer, cinfo); - arm_smccc_1_1_invoke(scmi_info->func_id, page, offset, 0, 0, 0, 0, 0, - &res); + if (cap_id >= 0) + arm_smccc_1_1_invoke(scmi_info->func_id, cap_id, 0, 0, 0, 0, 0, + 0, &res); + else + arm_smccc_1_1_invoke(scmi_info->func_id, page, offset, 0, 0, 0, + 0, 0, &res); /* Only SMCCC_RET_NOT_SUPPORTED is valid error code */ if (res.a0) {