Linux Remote Processor Subsystem development
 help / color / mirror / Atom feed
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