All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Michele Rodolfi <michele.rodolfi@t3lab.it>
Cc: linux-remoteproc@vger.kernel.org
Subject: Re: Shared memory between remote processors
Date: Mon, 10 Apr 2017 12:25:47 -0700	[thread overview]
Message-ID: <20170410192547.GF15143@minitux> (raw)
In-Reply-To: <CAHXzriF1iW8gBaLfdSjUmmRYduNr35feEXVyBuas9+byQO8CUg@mail.gmail.com>

On Mon 10 Apr 02:00 PDT 2017, Michele Rodolfi wrote:

> Hi all,
> I'm trying to set up a shared memory region for image transfers
> between processors.
> Since the rpmsg buffer isn't large enough to contain a whole image, I
> would like to put the image into a shared memory buffer then send the
> physical address of this buffer to the remote processor using rpmsg.
> I'm trying to understand how to do so with the functionalities
> provided by remoteproc. Has anyone done this before?
> The remoteproc driver supports the request for allocation of a
> physically contiguous memory region via resource table. Could this be
> a solution?
> 

Specifying a carveout region in your resource table and use that for
your shared buffers sounds plausable, but today we do not have a
mechanism for a rpmsg client driver to acquire a handle to an arbitrary
carveout from a potential parenting remoteproc instance.

This is something that has been discussed, but I have not seem any good
suggestions on how to link the two pieces together.


But as it sounds like you're going to have a "control protocol" running
ontop of rpmsg to provide the remote firmware with buffers to operate on
I would suggest that you allocate the buffers (e.g. using
dma_alloc_coherent()) in the context of that implementation, rather than
tying them to remoteproc.

Regards,
Bjorn

      reply	other threads:[~2017-04-10 19:25 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-10  9:00 Shared memory between remote processors Michele Rodolfi
2017-04-10 19:25 ` 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=20170410192547.GF15143@minitux \
    --to=bjorn.andersson@linaro.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=michele.rodolfi@t3lab.it \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.