public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Nikunj Kela <quic_nkela@quicinc.com>
Cc: cristian.marussi@arm.com, robh+dt@kernel.org,
	Sudeep Holla <sudeep.holla@arm.com>,
	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
Subject: Re: [PATCH v4 4/4] firmware: arm_scmi: Add qcom hvc/shmem transport support
Date: Tue, 3 Oct 2023 12:19:14 +0100	[thread overview]
Message-ID: <20231003111914.63z35sn3r3k7drtp@bogus> (raw)
In-Reply-To: <20230911194359.27547-5-quic_nkela@quicinc.com>

On Mon, Sep 11, 2023 at 12:43:59PM -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 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 HVC call is invoked.
> 
> The function-id & capability-id are allocated by the hypervisor on bootup
> and are 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    | 47 ++++++++++++++++++++++++++----
>  2 files changed, 43 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> index 87383c05424b..ea344bc6ae49 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-hvc-shmem", .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 0a0b7e401159..94ec07fdc14a 100644
> --- a/drivers/firmware/arm_scmi/smc.c
> +++ b/drivers/firmware/arm_scmi/smc.c
> @@ -50,6 +50,9 @@
>   * @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: hvc doorbell's capability id to be used on Qualcomm virtual
> + *	    platforms
> + * @qcom_xport: Flag to indicate the transport on Qualcomm virtual platforms
>   */
>  
>  struct scmi_smc {
> @@ -63,6 +66,8 @@ struct scmi_smc {
>  	u32 func_id;
>  	u32 param_page;
>  	u32 param_offset;
> +	u64 cap_id;

Can it be unsigned long instead so that it just works for both 32 and 64 bit.

> +	bool qcom_xport;

Do we really need this ?

>  };
>  
>  static irqreturn_t smc_msg_done_isr(int irq, void *data)
> @@ -129,6 +134,7 @@ static int smc_chan_setup(struct scmi_chan_info *cinfo, struct device *dev,
>  	struct resource res;
>  	struct device_node *np;
>  	u32 func_id;
> +	u64 cap_id;

Ditto..

>  	int ret;
>  
>  	if (!tx)
> @@ -158,9 +164,34 @@ static int smc_chan_setup(struct scmi_chan_info *cinfo, struct device *dev,
>  		return -EADDRNOTAVAIL;
>  	}
>  
> -	ret = of_property_read_u32(dev->of_node, "arm,smc-id", &func_id);
> -	if (ret < 0)
> -		return ret;
> +	if (of_device_is_compatible(dev->of_node, "qcom,scmi-hvc-shmem")) {
> +		scmi_info->qcom_xport = true;
> +
> +		/* The func-id & capability-id are kept in last 16 bytes of shmem.
> +		 *     +-------+
> +		 *     |       |
> +		 *     | shmem |
> +		 *     |       |
> +		 *     |       |
> +		 *     +-------+ <-- (size - 16)
> +		 *     | funcId|
> +		 *     +-------+ <-- (size - 8)
> +		 *     | capId |
> +		 *     +-------+ <-- size
> +		 */
> +
> +		func_id = readl((void __iomem *)(scmi_info->shmem) + size - 16);

So unlike 'arm,scmi-smc', you don't want 'arm,smc-id' in the DT ? Any
particular reason ? Just to get both FID and cap ID from shmem ?

> +#ifdef CONFIG_ARM64

I would rather make this arch agnostic using CONFIG_64BIT

> +		cap_id = readq((void __iomem *)(scmi_info->shmem) + size - 8);

Do you need __iomem typecast here ? Is scmi_info->shmem not already __iomem ?
Also scmi_info->shmem is ioremapped just few steps above and you are using
read* here, is that safe ?

> +#else
> +		/* capability-id is 32 bit wide on 32bit machines */
> +		cap_id = rieadl((void __iomem *)(scmi_info->shmem) + size - 8);

Other thought once you move for u64 to unsigned long you need not have
#ifdeffery, just do copy of sizeof(unsigned long)

> +#endif
> +	} else {
> +		ret = of_property_read_u32(dev->of_node, "arm,smc-id", &func_id);
> +		if (ret < 0)
> +			return ret;
> +	}
>  
>  	if (of_device_is_compatible(dev->of_node, "arm,scmi-smc-param")) {
>  		scmi_info->param_page = SHMEM_PAGE(res.start);
> @@ -184,6 +215,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 +245,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;
> +	unsigned long cap_id = (unsigned long)scmi_info->cap_id;
>  
>  	/*
>  	 * Channel will be released only once response has been
> @@ -222,8 +255,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 (scmi_info->qcom_xport)

Just make sure cap_id is set only for qcom and just use that as your flag.
No point in setting always true scmi_info->qcom_xport and using it here.

> +		arm_smccc_1_1_hvc(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) {
> -- 
> 2.17.1
> 

-- 
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2023-10-03 11:19 UTC|newest]

Thread overview: 89+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-18 16:08 [PATCH 0/2] Add qcom hvc/shmem transport Nikunj Kela
2023-07-18 16:08 ` [PATCH 1/2] dt-bindings: arm: Add qcom specific hvc transport for SCMI Nikunj Kela
2023-07-18 17:21   ` Rob Herring
2023-07-18 18:12   ` Krzysztof Kozlowski
2023-07-18 18:18     ` Nikunj Kela
2023-07-19 10:39   ` Sudeep Holla
2023-07-19 13:58     ` Nikunj Kela
2023-07-18 16:08 ` [PATCH 2/2] firmware: arm_scmi: Add qcom hvc/shmem transport Nikunj Kela
2023-07-18 18:17   ` Krzysztof Kozlowski
2023-07-18 18:25     ` Nikunj Kela
2023-07-18 18:42       ` Krzysztof Kozlowski
2023-07-18 21:16         ` Nikunj Kela
2023-07-19  6:15           ` Krzysztof Kozlowski
2023-07-18 18:29   ` Bjorn Andersson
2023-07-18 18:53     ` Nikunj Kela
2023-07-18 19:07       ` Bjorn Andersson
2023-07-18 19:10         ` Nikunj Kela
2023-07-18 19:30           ` Bjorn Andersson
2023-07-18 22:05             ` Nikunj Kela
2023-07-19 10:55       ` Cristian Marussi
2023-07-19 14:02         ` Nikunj Kela
2023-07-23  2:15   ` kernel test robot
     [not found] ` <20230724164419.16092-1-quic_nkela@quicinc.com>
     [not found]   ` <20230724164419.16092-4-quic_nkela@quicinc.com>
     [not found]     ` <ZMAASCqwMbqX7T7L@pluto>
     [not found]       ` <fc42e319-0ead-db94-9335-e07ff780dfa2@quicinc.com>
2023-07-31 14:04         ` [PATCH v2 3/3] " Nikunj Kela
2023-08-01  7:27     ` kernel test robot
2023-08-11 17:57 ` [PATCH v3 0/3] " Nikunj Kela
2023-08-11 17:57   ` [PATCH v3 1/3] dt-bindings: arm: convert nested if-else construct to allOf Nikunj Kela
2023-08-11 17:57   ` [PATCH v3 2/3] dt-bindings: arm: Add qcom specific hvc transport for SCMI Nikunj Kela
2023-08-11 17:57   ` [PATCH v3 3/3] firmware: arm_scmi: Add qcom hvc/shmem transport Nikunj Kela
2023-09-05 16:06   ` [PATCH v3 0/3] " Nikunj Kela
2023-09-05 16:37     ` Krzysztof Kozlowski
2023-09-07 10:36       ` Sudeep Holla
2023-09-07 14:20         ` Nikunj Kela
2023-09-07 16:16 ` [PATCH 0/2] " Konrad Dybcio
2023-09-07 22:32   ` Nikunj Kela
2023-09-11 19:43 ` [PATCH v4 0/4] Add qcom hvc/shmem transport support Nikunj Kela
2023-09-11 19:43   ` [PATCH v4 1/4] firmware: arm_scmi: Add polling support for completion in smc Nikunj Kela
2023-10-02 18:18     ` Brian Masney
2023-10-02 18:36       ` Nikunj Kela
2023-10-03 10:33     ` Sudeep Holla
2023-10-03 10:50       ` Cristian Marussi
2023-10-03 15:53       ` Nikunj Kela
2023-10-04 16:11         ` Sudeep Holla
2023-10-05  3:25           ` Nikunj Kela
2023-09-11 19:43   ` [PATCH v4 2/4] dt-bindings: arm: convert nested if-else construct to allOf Nikunj Kela
2023-09-11 19:43   ` [PATCH v4 3/4] dt-bindings: arm: Add new compatible for smc/hvc transport for SCMI Nikunj Kela
2023-10-03 10:44     ` Sudeep Holla
2023-10-03 15:59       ` Nikunj Kela
2023-10-04 15:53         ` Sudeep Holla
2023-10-05 21:51           ` Nikunj Kela
2023-09-11 19:43   ` [PATCH v4 4/4] firmware: arm_scmi: Add qcom hvc/shmem transport support Nikunj Kela
2023-10-02 18:34     ` Brian Masney
2023-10-02 18:39       ` Brian Masney
2023-10-02 18:45         ` Nikunj Kela
2023-10-02 18:42       ` Nikunj Kela
2023-10-03 10:48         ` Sudeep Holla
2023-10-03 11:19     ` Sudeep Holla [this message]
2023-10-03 16:16       ` Nikunj Kela
2023-10-04 16:06         ` Sudeep Holla
2023-10-04 17:48           ` Nikunj Kela
2023-10-05 22:20           ` Bjorn Andersson
2023-10-05 22:33             ` Nikunj Kela
2023-10-06  7:26             ` Sudeep Holla
2023-09-18 15:01   ` [PATCH v4 0/4] " Nikunj Kela
2023-09-18 15:15     ` Sudeep Holla
2023-09-18 15:54       ` Brian Masney
2023-09-19  8:56         ` Sudeep Holla
2023-10-02 17:31           ` Nikunj Kela
2023-10-02 17:58             ` Cristian Marussi
2023-10-03 10:34             ` Sudeep Holla
2023-09-18 20:32     ` Krzysztof Kozlowski
2023-10-06 16:42 ` [PATCH v5 0/2] Add qcom smc/hvc " Nikunj Kela
2023-10-06 16:42   ` [PATCH v5 1/2] dt-bindings: arm: Add new compatible for smc/hvc transport for SCMI Nikunj Kela
2023-10-06 20:08     ` Brian Masney
2023-10-09 14:41     ` Sudeep Holla
2023-10-09 14:52       ` Nikunj Kela
2023-10-09 21:03         ` Konrad Dybcio
2023-10-06 16:42   ` [PATCH v5 2/2] firmware: arm_scmi: Add qcom smc/hvc transport support Nikunj Kela
2023-10-06 20:17     ` Brian Masney
2023-10-09 14:47     ` Sudeep Holla
2023-10-09 14:59       ` Nikunj Kela
2023-10-09 15:29         ` Sudeep Holla
2023-10-09 17:49           ` Nikunj Kela
2023-10-09 19:08             ` Sudeep Holla
2023-10-09 19:16               ` Nikunj Kela
2023-10-09 19:14 ` [PATCH v6 0/2] " Nikunj Kela
2023-10-09 19:14   ` [PATCH v6 1/2] dt-bindings: arm: Add new compatible for smc/hvc transport for SCMI Nikunj Kela
2023-10-09 19:14   ` [PATCH v6 2/2] firmware: arm_scmi: Add qcom smc/hvc transport support Nikunj Kela
2023-10-10 10:42     ` Sudeep Holla
2023-10-10 10:21   ` [PATCH v6 0/2] " Sudeep Holla

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=20231003111914.63z35sn3r3k7drtp@bogus \
    --to=sudeep.holla@arm.com \
    --cc=andersson@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=cristian.marussi@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_nkela@quicinc.com \
    --cc=robh+dt@kernel.org \
    /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