From: Jitendra Sharma <shajit@codeaurora.org>
To: Bjorn Andersson <bjorn.andersson@linaro.org>,
Andy Gross <andy.gross@linaro.org>,
David Brown <david.brown@linaro.org>
Cc: Rajendra Nayak <rnayak@codeaurora.org>,
Govind Singh <govinds@qti.qualcomm.com>,
Shon Parate <sparate@qti.qualcomm.com>,
linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] soc: qcom: rmtfs-mem: Add support for assigning memory to remote
Date: Wed, 21 Feb 2018 18:34:23 +0530 [thread overview]
Message-ID: <7d9ab926-a0cd-267e-6c85-3e3af2467e97@codeaurora.org> (raw)
In-Reply-To: <20180213013724.3177-1-bjorn.andersson@linaro.org>
Hi Bjorn,
On 2/13/2018 7:07 AM, Bjorn Andersson wrote:
> On some platform the remote processor's memory map is not statically
> configured in TrustZone, so each memory region that is to be accessed by
> the remote needs a call into TrustZone to set up the remote's
> permissions.
>
> Implement this for the rmtfs memory driver, to give the modem on 8996
> access to the shared file system buffers.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> drivers/soc/qcom/Kconfig | 1 +
> drivers/soc/qcom/rmtfs_mem.c | 34 ++++++++++++++++++++++++++++++++++
> 2 files changed, 35 insertions(+)
>
> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> index e050eb83341d..a993d19fa562 100644
> --- a/drivers/soc/qcom/Kconfig
> +++ b/drivers/soc/qcom/Kconfig
> @@ -47,6 +47,7 @@ config QCOM_QMI_HELPERS
> config QCOM_RMTFS_MEM
> tristate "Qualcomm Remote Filesystem memory driver"
> depends on ARCH_QCOM
> + select QCOM_SCM
> help
> The Qualcomm remote filesystem memory driver is used for allocating
> and exposing regions of shared memory with remote processors for the
> diff --git a/drivers/soc/qcom/rmtfs_mem.c b/drivers/soc/qcom/rmtfs_mem.c
> index 0a43b2e8906f..c8999e38b005 100644
> --- a/drivers/soc/qcom/rmtfs_mem.c
> +++ b/drivers/soc/qcom/rmtfs_mem.c
> @@ -37,6 +37,8 @@ struct qcom_rmtfs_mem {
> phys_addr_t size;
>
> unsigned int client_id;
> +
> + unsigned int perms;
> };
>
> static ssize_t qcom_rmtfs_mem_show(struct device *dev,
> @@ -151,9 +153,11 @@ static void qcom_rmtfs_mem_release_device(struct device *dev)
> static int qcom_rmtfs_mem_probe(struct platform_device *pdev)
> {
> struct device_node *node = pdev->dev.of_node;
> + struct qcom_scm_vmperm perms[2];
> struct reserved_mem *rmem;
> struct qcom_rmtfs_mem *rmtfs_mem;
> u32 client_id;
> + u32 vmid;
> int ret;
>
> rmem = of_reserved_mem_lookup(node);
> @@ -204,10 +208,31 @@ static int qcom_rmtfs_mem_probe(struct platform_device *pdev)
>
> rmtfs_mem->dev.release = qcom_rmtfs_mem_release_device;
>
> + ret = of_property_read_u32(node, "qcom,vmid", &vmid);
> + if (ret < 0 && ret != -EINVAL) {
> + dev_err(&pdev->dev, "failed to parse qcom,vmid\n");
> + goto remove_cdev;
> + } else if (!ret) {
> + perms[0].vmid = QCOM_SCM_VMID_HLOS;
> + perms[0].perm = QCOM_SCM_PERM_RW;
> + perms[1].vmid = vmid;
> + perms[1].perm = QCOM_SCM_PERM_RW;
> +
> + rmtfs_mem->perms = BIT(QCOM_SCM_VMID_HLOS);
> + ret = qcom_scm_assign_mem(rmtfs_mem->addr, rmtfs_mem->size,
> + &rmtfs_mem->perms, perms, 2);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "assign memory failed\n");
> + goto remove_cdev;
> + }
> + }
> +
I have a query here,
We assigned memory ownership to modem at boot up. In case of errors in
other parts of driver, where we are returning, have we assigned memory
back to HLOS
> dev_set_drvdata(&pdev->dev, rmtfs_mem);
>
> return 0;
>
> +remove_cdev:
> + cdev_device_del(&rmtfs_mem->cdev, &rmtfs_mem->dev);
> put_device:
> put_device(&rmtfs_mem->dev);
>
> @@ -217,6 +242,15 @@ static int qcom_rmtfs_mem_probe(struct platform_device *pdev)
> static int qcom_rmtfs_mem_remove(struct platform_device *pdev)
> {
> struct qcom_rmtfs_mem *rmtfs_mem = dev_get_drvdata(&pdev->dev);
> + struct qcom_scm_vmperm perm;
> +
> + if (rmtfs_mem->perms) {
> + perm.vmid = QCOM_SCM_VMID_HLOS;
> + perm.perm = QCOM_SCM_PERM_RW;
> +
> + qcom_scm_assign_mem(rmtfs_mem->addr, rmtfs_mem->size,
> + &rmtfs_mem->perms, &perm, 1);
> + }
>
> cdev_device_del(&rmtfs_mem->cdev, &rmtfs_mem->dev);
> put_device(&rmtfs_mem->dev);
next prev parent reply other threads:[~2018-02-21 13:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-13 1:37 Bjorn Andersson
2018-02-13 1:37 ` [PATCH 2/2] arm64: dts: msm8996: Add rmtfs sharedmem node Bjorn Andersson
2018-02-21 13:04 ` Jitendra Sharma [this message]
2018-02-21 19:33 ` [PATCH 1/2] soc: qcom: rmtfs-mem: Add support for assigning memory to remote Bjorn Andersson
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=7d9ab926-a0cd-267e-6c85-3e3af2467e97@codeaurora.org \
--to=shajit@codeaurora.org \
--cc=andy.gross@linaro.org \
--cc=bjorn.andersson@linaro.org \
--cc=david.brown@linaro.org \
--cc=govinds@qti.qualcomm.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-soc@vger.kernel.org \
--cc=rnayak@codeaurora.org \
--cc=sparate@qti.qualcomm.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
Powered by JetHome