From: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
To: Simon Maurer <mail@maurer.systems>,
<linux-remoteproc@vger.kernel.org>,
Christoph Hellwig <hch@lst.de>
Subject: Re: remoteproc over PCIe
Date: Tue, 9 May 2023 19:08:26 +0200 [thread overview]
Message-ID: <86dc39b0-61bf-5e83-e65d-1283fdf382b4@foss.st.com> (raw)
In-Reply-To: <72ff39f1-b966-a089-0f3c-9216d8a38e77@maurer.systems>
Hi Simon,
On 5/9/23 15:42, Simon Maurer wrote:
> Hi,
> I've got a "Zynq PCIe FMC Carrier Evaluation Board" with a x86 host. The Zynq
> 7000 is an FPGA with 2x Cortex-A9, on which ZephyrOS with the OpenAMP framework
> is running. The VirtIO ring and the buffer for the RPMSGs are located in the
> nocache memory section of the ZephyrOS. The card DDR-RAM and the CPU control
> registers are mapped into PCIe BARs. On the FPGA the "AXI Memory Mapped To PCI
> Express" IP core is used, so the kernel has mmio access to the card DDR-RAM.
> Besides the kernel module, I had to do a few modifications elsewhere in the
> kernel. In remoteproc_virtio.c I implemented the get_shm_region function for the
> rproc_virtio_config_ops. This gives access to the rpmsg buffer, that is already
> mapped.
+ christopher Hellwig.
Nice proposal!
I've also had the same approach in mind for a while, to remove the use of
dma_declare_coherent_memory in remoteproc_virtio[1][2].
But I haven't found the time to implement it yet.
[1] https://lkml.org/lkml/2021/6/23/607
[2]
https://patchwork.kernel.org/project/linux-remoteproc/patch/AOKowLclCbOCKxyiJ71WeNyuAAj2q8EUtxrXbyky5E@cp7-web-042.plabs.ch/
It would be nice to ensure same approach for the different virtio
backend (remoteproc_virtio, virtio_mmio, ...) to be able to reuse the virtio
drivers on top of.
The virtio_mmio seems the reference...
> In virtio_rpmsg_bus.c this function is used instead of allocating a new
> region.
The DT seems to me a valid place to define memory regions associated.
It can be one for vrings and buffers, or one unique pool.
One reason is that the main processor can have to specify the memory mapping
and to specify associated access right.
> This is just a proof of concept, but it seems to be working, ttyRPMSG is
> created and I can send and receive messages.
Great!
> But what would be the clean way to do this? I'm thinking about implementing
> dma_map_ops for the vdev, but maybe there is a better solution?
Good question...I don't have the answer.
I have implemented something different but not fully satisfied. For instance how
to manage the remoteproc address (DA) and CPU address(PA) conversion for vring
descriptor?
You can have a look to the work I started, described in the cover letter[3]] with
links to my github for the code source.
I have only up-streamed the step 1 yet.
We have some discussions in the OpenAMP project to reuse the virtio MMIO. So I
put on hold waiting more clues.
[3]https://www.spinics.net/lists/linux-remoteproc/msg13680.html
Regards,
Arnaud
>
> Best regards,
> Simon
next prev parent reply other threads:[~2023-05-09 18:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-09 13:42 remoteproc over PCIe Simon Maurer
2023-05-09 17:08 ` Arnaud POULIQUEN [this message]
2023-05-10 13:06 ` Simon Maurer
-- strict thread matches above, loose matches on Subject: below --
2025-01-22 15:59 [PATCH] remoteproc: add optional hook for resource checking Simon Maurer
2025-01-22 18:53 ` RemoteProc over PCIe Simon Maurer
2025-01-27 16:27 ` Mathieu Poirier
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=86dc39b0-61bf-5e83-e65d-1283fdf382b4@foss.st.com \
--to=arnaud.pouliquen@foss.st.com \
--cc=hch@lst.de \
--cc=linux-remoteproc@vger.kernel.org \
--cc=mail@maurer.systems \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).