From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Jitendra Sharma <shajit@codeaurora.org>
Cc: Andy Gross <andy.gross@linaro.org>,
David Brown <david.brown@linaro.org>,
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 11:33:38 -0800 [thread overview]
Message-ID: <20180221193338.GB18510@minitux> (raw)
In-Reply-To: <7d9ab926-a0cd-267e-6c85-3e3af2467e97@codeaurora.org>
On Wed 21 Feb 05:04 PST 2018, Jitendra Sharma wrote:
> 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
We're assigning the rmtfs memory to MPSS from the time this driver
probes until it is removed. The PIL related memory regions shared with
MPSS is handled by the remoteproc driver, for the duration of the MPSS
being up.
The one issue worth mentioning here is that this extends the dependency
the booting MPSS have on the remote-storage QMI service being
functional, i.e. if this device isn't present, we can't serve
remote-storage requests and MPSS will not function.
I haven't yet come up with a good idea of how to make the MPSS PIL
explicitly depend on the remote-storage service being present.
Regards,
Bjorn
prev parent reply other threads:[~2018-02-21 19:33 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 ` [PATCH 1/2] soc: qcom: rmtfs-mem: Add support for assigning memory to remote Jitendra Sharma
2018-02-21 19:33 ` Bjorn Andersson [this message]
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=20180221193338.GB18510@minitux \
--to=bjorn.andersson@linaro.org \
--cc=andy.gross@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=shajit@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
all inboxes | Powered by JetHome®