LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: srinivas.kandagatla@linaro.org, will.deacon@arm.com,
	joro@8bytes.org, ohad@wizery.com,
	linux-arm-kernel@lists.infradead.org,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
	linux-remoteproc@vger.kernel.org
Subject: Re: [PATCH 2/3] rpmsg: core: make rpmsg bus DMA capable
Date: Sun, 18 Mar 2018 15:47:24 -0700	[thread overview]
Message-ID: <20180318224724.GJ5626@tuxbook-pro> (raw)
In-Reply-To: <07503032-b08b-10ea-9d34-ddf85c682a9d@arm.com>

On Fri 02 Mar 08:14 PST 2018, Robin Murphy wrote:

> On 02/03/18 14:55, srinivas.kandagatla@linaro.org wrote:
> > From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> > 
> > Many of the rpmsg clients like audio drivers need to allocate
> > dma memory. Make this bus DMA capable so that the child devices
> > can use dma apis.
> 
> AFAICS after 15 minutes in the docs and code, the rpmsg "bus" is a virtual
> one based around shared-memory mailbox communication, so I don't really see
> how DMA exists in that context - I think maybe that abstraction needs
> looking at.
> 

That's right, rpmsg shuffles messages back and forth to some coprocessor
over shared memory, the contexts generating and receiving these messages
are "rpmsg devices".

The problem Srinivas is facing is that one of these rpmsg devices is
trying to allocate and map a larger chunk of memory to be shared with
the coprocessor, which is then going to be referenced in the messages
being passed in rpmsg.

> However, from grepping through the DTs it seems at first glance like the
> non-trivial things under the "qcom,smd" bus mostly map to actual platform
> devices via the "qcom,smd-edge" property - if those platform devices are the
> physical DMA masters, they should be the ones used for DMA API operations.
> 

One of the rpmsg implementations is virtio based and have a similar
problem, there dma_alloc*() is called with dev->parent->parent as
device, but this causes issues as dev->parent might not be what the
original author expected it to -- so this needs to be reworked as well.

> > Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> > ---
> >   drivers/rpmsg/rpmsg_core.c | 1 +
> >   1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> > index e84c71f8d6ab..540a3f3567b8 100644
> > --- a/drivers/rpmsg/rpmsg_core.c
> > +++ b/drivers/rpmsg/rpmsg_core.c
> > @@ -472,6 +472,7 @@ struct bus_type rpmsg_bus = {
> >   	.uevent		= rpmsg_uevent,
> >   	.probe		= rpmsg_dev_probe,
> >   	.remove		= rpmsg_dev_remove,
> > +	.force_dma	= true,
> 
> Regardless of the above, would you really need to use this brute force hack
> instead of just fixing the DTs? I'm struggling to find which drivers might
> currently be relying on this :/
> 

The rpmsg devices, described as child nodes of rpmsg bus relates to
specific functions in the coprocessor firmware. The fact that the
firmware can be started and stopped dynamically makes the current layout
quite convenient (in comparison to e.g. how we would describe a
mailbox).

We know for these cases that dev->parent->parent is a remoteproc
instance representing the coprocessor that sits on the other side of the
communication channel. So we did investigate if we could just have that
to allocate and map buffers. The problem with this is that these
functions has multiple iommu contexts.

Regards,
Bjorn

  parent reply	other threads:[~2018-03-18 22:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-02 14:55 [PATCH 0/3] drivers: rpmsg: " srinivas.kandagatla
2018-03-02 14:55 ` [PATCH 1/3] rpmsg: core: export rpmsg bus type srinivas.kandagatla
2018-03-02 15:25   ` Robin Murphy
2018-03-02 14:55 ` [PATCH 2/3] rpmsg: core: make rpmsg bus DMA capable srinivas.kandagatla
2018-03-02 16:14   ` Robin Murphy
2018-03-02 16:40     ` Srinivas Kandagatla
2018-03-18 22:47     ` Bjorn Andersson [this message]
2018-03-02 14:55 ` [PATCH 3/3] iommu: armsmmu: set iommu ops for rpmsg bus srinivas.kandagatla
2018-03-02 16:59   ` Robin Murphy
2018-05-07 19:28     ` Bjorn Andersson
2018-05-11 18:24       ` Robin Murphy

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=20180318224724.GJ5626@tuxbook-pro \
    --to=bjorn.andersson@linaro.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=ohad@wizery.com \
    --cc=robin.murphy@arm.com \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=will.deacon@arm.com \
    --subject='Re: [PATCH 2/3] rpmsg: core: make rpmsg bus DMA capable' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).