From: Alexandre Bailon <abailon@baylibre.com>
To: bjorn.andersson@linaro.org, mathieu.poirier@linaro.org,
joro@8bytes.org, will@kernel.org, hch@lst.de,
m.szyprowski@samsung.com, yong.wu@mediatek.com
Cc: linux-remoteproc@vger.kernel.org, iommu@lists.linux-foundation.org
Subject: Help needed to unblock upstreaming of mt8365 / mt8183 APU remoteproc
Date: Thu, 14 Sep 2023 11:06:35 +0200 [thread overview]
Message-ID: <32df1f0e-282a-1efd-482c-01e61229f2c3@baylibre.com> (raw)
Hi,
For a long time now, I am trying to upstream support of remoteproc
driver for the APU (AI accelerator) found in MT8183 and MT8365.
There is a blocker that I am not able to address and I need some help to
find a solution. The blocker always related to IOMMU and device address
management.
Let's me give some context.
The APU is an xtensa processor with some instructions set that could be
used for edge AI/ML.
We want use remoteproc to load a firmware and start the processor.
The main issue is that the firmware is not relocatable so we have to
load it at specific address and the APU is behind an IOMMU.
This use case is already managed by remoteproc core.
But, the remoteproc require an unmanaged IOMMU domain to use the IOMMU
which is not supported by the MT8183 / MT8365.
To workaround it, I tried a couple of things:
- From the platform driver I passed to the core the device IOMMU domain
- I updated the platform to use the IOMMU API but this duplicates
remoteproc core
- I tried adding support of unmanaged domain IOMMU
None of these proposals were acceptable for good reasons but now I don't
have much thing to try.
The only thing I have not tried yet is adding a new function to DMA API
that would allow allocating a buffer that would be mapped at a specific
DMA address.
Currently, everything is closed source (the sources, the toolchains,
...) so there is not many thing I could do to make it relocatable.
Someday, I hope that we could use an open source toolchain and firmware
but this will take a lot of time before coming.
I hope the issue I am facing is clear and we will find a solution together.
Thanks,
Alexandre
reply other threads:[~2023-09-14 9:06 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=32df1f0e-282a-1efd-482c-01e61229f2c3@baylibre.com \
--to=abailon@baylibre.com \
--cc=bjorn.andersson@linaro.org \
--cc=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mathieu.poirier@linaro.org \
--cc=will@kernel.org \
--cc=yong.wu@mediatek.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