drivers/iommu/ipmmu-vmsa.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
Add Renesas DMA controller devices to the devices_allowlist to enable
their use with the IPMMU. This allows DMA channels to operate through
the IOMMU when enabled.
Signed-off-by: Koichiro Den <den@valinux.co.jp>
---
drivers/iommu/ipmmu-vmsa.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index ffa892f65714..88c4fb6424ed 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -741,7 +741,9 @@ static const char * const devices_allowlist[] = {
"ee100000.mmc",
"ee120000.mmc",
"ee140000.mmc",
- "ee160000.mmc"
+ "ee160000.mmc",
+ "e7350000.dma-controller",
+ "e7351000.dma-controller"
};
static bool ipmmu_device_is_allowed(struct device *dev)
--
2.48.1
Hi Den-san,
On Mon, 27 Oct 2025 at 02:26, Koichiro Den <den@valinux.co.jp> wrote:
> Add Renesas DMA controller devices to the devices_allowlist to enable
> their use with the IPMMU. This allows DMA channels to operate through
> the IOMMU when enabled.
>
> Signed-off-by: Koichiro Den <den@valinux.co.jp>
Thanks for your patch!
> --- a/drivers/iommu/ipmmu-vmsa.c
> +++ b/drivers/iommu/ipmmu-vmsa.c
> @@ -741,7 +741,9 @@ static const char * const devices_allowlist[] = {
> "ee100000.mmc",
> "ee120000.mmc",
> "ee140000.mmc",
> - "ee160000.mmc"
> + "ee160000.mmc",
> + "e7350000.dma-controller",
> + "e7351000.dma-controller"
While your change looks correct to me, it causes DMA mapping failures on
Gray Hawk Single and Sparrow Hawk when IPMMU support is enabled
(on renesas-drivers-2025-10-28-v6.18-rc3 with renesas_defconfig
+ CONFIG_IPMMU_VMSA=y):
rcar-dmac e7351000.dma-controller: chan1: failed to map 1@0x00000000e656000c
sh-sci e6560000.serial: Failed preparing Tx DMA descriptor
0xe656000c = HSCIF2 Transmit FIFO data register.
With "#define DEBUG" added to drivers/dma/sh/rcar-dmac.c:
rcar-dmac e7351000.dma-controller: chan1: failed to map 1@0x00000000e656000c
sh-sci e6560000.serial: Failed preparing Tx DMA descriptor
rcar-dmac e7351000.dma-controller: chan2: map 1@0x00000000e6560014
to 0x00000000fff82014 dir: DMA_TO_DEVICE
rcar-dmac e7351000.dma-controller: chan2: chunk
00000000e5110c20/000000005e0ede90 sgl 0@000000000d8c5440, 256/256
0x00000000fff82014 -> 0x00000000ffed6000
rcar-dmac e7351000.dma-controller: chan2: submit #2@000000005e0ede90
rcar-dmac e7351000.dma-controller: chan2: chunk
0000000025f2f66c/00000000e5f0dd15 sgl 0@0000000064f1067f, 256/256
0x00000000fff82014 -> 0x00000000ffed6100
rcar-dmac e7351000.dma-controller: chan2: submit #3@00000000e5f0dd15
rcar-dmac e7351000.dma-controller: chan2: queue chunk
00000000e5110c20: 256@0x00000000fff82014 -> 0x00000000ffed6000
0xe6560014 = HSCIF2 Receive FIFO data register
Comparing to the CONFIG_IPMMU_VMSA=n case:
rcar-dmac e7351000.dma-controller: chan1: map 1@0x00000000e656000c
to 0x00000000e656000c dir: DMA_FROM_DEVICE
rcar-dmac e7351000.dma-controller: chan1: chunk
0000000096396eb4/00000000f35357b6 sgl 0@0000000013546bf6, 74/74
0x0000000489ab5000 -> 0x00000000e656000c
rcar-dmac e7351000.dma-controller: chan1: submit #2@00000000f35357b6
rcar-dmac e7351000.dma-controller: chan1: queue chunk
0000000096396eb4: 74@0x0000000489ab5000 -> 0x00000000e656000c
This confuses me even more: why no DMA_TO_DEVICE mapping in the
latter case?
> };
>
> static bool ipmmu_device_is_allowed(struct device *dev)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi, Geert!
I'm helping out Den-san a bit on the issue.
On Wed, 29 Oct 2025 17:08:07 +0100, Geert Uytterhoeven wrote:
>On Mon, 27 Oct 2025 at 02:26, Koichiro Den <den@valinux.co.jp> wrote:
>> Add Renesas DMA controller devices to the devices_allowlist to enable
>> their use with the IPMMU. This allows DMA channels to operate through
>> the IOMMU when enabled.
>>
>> Signed-off-by: Koichiro Den <den@valinux.co.jp>
>
>Thanks for your patch!
>
>> --- a/drivers/iommu/ipmmu-vmsa.c
>> +++ b/drivers/iommu/ipmmu-vmsa.c
>> @@ -741,7 +741,9 @@ static const char * const devices_allowlist[] = {
>> "ee100000.mmc",
>> "ee120000.mmc",
>> "ee140000.mmc",
>> - "ee160000.mmc"
>> + "ee160000.mmc",
>> + "e7350000.dma-controller",
>> + "e7351000.dma-controller"
>
>While your change looks correct to me, it causes DMA mapping failures on
>Gray Hawk Single and Sparrow Hawk when IPMMU support is enabled
>(on renesas-drivers-2025-10-28-v6.18-rc3 with renesas_defconfig
>+ CONFIG_IPMMU_VMSA=y):
>
> rcar-dmac e7351000.dma-controller: chan1: failed to map 1@0x00000000e656000c
> sh-sci e6560000.serial: Failed preparing Tx DMA descriptor
>
>0xe656000c = HSCIF2 Transmit FIFO data register.
Thank you for sharing.
I was able to reproduce the issue on Gray Hawk Single(r8a779h2).
>With "#define DEBUG" added to drivers/dma/sh/rcar-dmac.c:
>
> rcar-dmac e7351000.dma-controller: chan1: failed to map 1@0x00000000e656000c
> sh-sci e6560000.serial: Failed preparing Tx DMA descriptor
> rcar-dmac e7351000.dma-controller: chan2: map 1@0x00000000e6560014
>to 0x00000000fff82014 dir: DMA_TO_DEVICE
> rcar-dmac e7351000.dma-controller: chan2: chunk
>00000000e5110c20/000000005e0ede90 sgl 0@000000000d8c5440, 256/256
>0x00000000fff82014 -> 0x00000000ffed6000
> rcar-dmac e7351000.dma-controller: chan2: submit #2@000000005e0ede90
> rcar-dmac e7351000.dma-controller: chan2: chunk
>0000000025f2f66c/00000000e5f0dd15 sgl 0@0000000064f1067f, 256/256
>0x00000000fff82014 -> 0x00000000ffed6100
> rcar-dmac e7351000.dma-controller: chan2: submit #3@00000000e5f0dd15
> rcar-dmac e7351000.dma-controller: chan2: queue chunk
>00000000e5110c20: 256@0x00000000fff82014 -> 0x00000000ffed6000
>
>0xe6560014 = HSCIF2 Receive FIFO data register
Does IPMMU support handling FIFO registers?
(Forgive me the question... I'm still trying to learn how it works.)
If not, with now dma-controller backed with IPMMU, maybe what
we need is to map FIFO register directly like it used to do?
>Comparing to the CONFIG_IPMMU_VMSA=n case:
>
> rcar-dmac e7351000.dma-controller: chan1: map 1@0x00000000e656000c
>to 0x00000000e656000c dir: DMA_FROM_DEVICE
> rcar-dmac e7351000.dma-controller: chan1: chunk
>0000000096396eb4/00000000f35357b6 sgl 0@0000000013546bf6, 74/74
>0x0000000489ab5000 -> 0x00000000e656000c
> rcar-dmac e7351000.dma-controller: chan1: submit #2@00000000f35357b6
> rcar-dmac e7351000.dma-controller: chan1: queue chunk
>0000000096396eb4: 74@0x0000000489ab5000 -> 0x00000000e656000c
>
>This confuses me even more: why no DMA_TO_DEVICE mapping in the
>latter case?
I believe the DEVICE being reffered in DMA_FROM_DEVICE is
DMAC rather than FIFO TX register.
So from DMAC's point of view, the dma of DMAC->FIFO TX register
should be think of it as DMA_FROM_DEVICE.
>> };
>>
>> static bool ipmmu_device_is_allowed(struct device *dev)
>
>Gr{oetje,eeting}s,
>
> Geert
Sincerely,
Ryo Takakura
On Mon, Nov 03, 2025 at 05:56:12PM +0900, Ryo Takakura wrote:
> Hi, Geert!
>
> I'm helping out Den-san a bit on the issue.
>
> On Wed, 29 Oct 2025 17:08:07 +0100, Geert Uytterhoeven wrote:
> >On Mon, 27 Oct 2025 at 02:26, Koichiro Den <den@valinux.co.jp> wrote:
> >> Add Renesas DMA controller devices to the devices_allowlist to enable
> >> their use with the IPMMU. This allows DMA channels to operate through
> >> the IOMMU when enabled.
> >>
> >> Signed-off-by: Koichiro Den <den@valinux.co.jp>
> >
> >Thanks for your patch!
> >
> >> --- a/drivers/iommu/ipmmu-vmsa.c
> >> +++ b/drivers/iommu/ipmmu-vmsa.c
> >> @@ -741,7 +741,9 @@ static const char * const devices_allowlist[] = {
> >> "ee100000.mmc",
> >> "ee120000.mmc",
> >> "ee140000.mmc",
> >> - "ee160000.mmc"
> >> + "ee160000.mmc",
> >> + "e7350000.dma-controller",
> >> + "e7351000.dma-controller"
> >
> >While your change looks correct to me, it causes DMA mapping failures on
> >Gray Hawk Single and Sparrow Hawk when IPMMU support is enabled
> >(on renesas-drivers-2025-10-28-v6.18-rc3 with renesas_defconfig
> >+ CONFIG_IPMMU_VMSA=y):
> >
> > rcar-dmac e7351000.dma-controller: chan1: failed to map 1@0x00000000e656000c
> > sh-sci e6560000.serial: Failed preparing Tx DMA descriptor
> >
> >0xe656000c = HSCIF2 Transmit FIFO data register.
>
> Thank you for sharing.
> I was able to reproduce the issue on Gray Hawk Single(r8a779h2).
>
> >With "#define DEBUG" added to drivers/dma/sh/rcar-dmac.c:
> >
> > rcar-dmac e7351000.dma-controller: chan1: failed to map 1@0x00000000e656000c
> > sh-sci e6560000.serial: Failed preparing Tx DMA descriptor
> > rcar-dmac e7351000.dma-controller: chan2: map 1@0x00000000e6560014
> >to 0x00000000fff82014 dir: DMA_TO_DEVICE
> > rcar-dmac e7351000.dma-controller: chan2: chunk
> >00000000e5110c20/000000005e0ede90 sgl 0@000000000d8c5440, 256/256
> >0x00000000fff82014 -> 0x00000000ffed6000
> > rcar-dmac e7351000.dma-controller: chan2: submit #2@000000005e0ede90
> > rcar-dmac e7351000.dma-controller: chan2: chunk
> >0000000025f2f66c/00000000e5f0dd15 sgl 0@0000000064f1067f, 256/256
> >0x00000000fff82014 -> 0x00000000ffed6100
> > rcar-dmac e7351000.dma-controller: chan2: submit #3@00000000e5f0dd15
> > rcar-dmac e7351000.dma-controller: chan2: queue chunk
> >00000000e5110c20: 256@0x00000000fff82014 -> 0x00000000ffed6000
> >
> >0xe6560014 = HSCIF2 Receive FIFO data register
>
> Does IPMMU support handling FIFO registers?
> (Forgive me the question... I'm still trying to learn how it works.)
>
> If not, with now dma-controller backed with IPMMU, maybe what
> we need is to map FIFO register directly like it used to do?
>
> >Comparing to the CONFIG_IPMMU_VMSA=n case:
> >
> > rcar-dmac e7351000.dma-controller: chan1: map 1@0x00000000e656000c
> >to 0x00000000e656000c dir: DMA_FROM_DEVICE
> > rcar-dmac e7351000.dma-controller: chan1: chunk
> >0000000096396eb4/00000000f35357b6 sgl 0@0000000013546bf6, 74/74
> >0x0000000489ab5000 -> 0x00000000e656000c
> > rcar-dmac e7351000.dma-controller: chan1: submit #2@00000000f35357b6
> > rcar-dmac e7351000.dma-controller: chan1: queue chunk
> >0000000096396eb4: 74@0x0000000489ab5000 -> 0x00000000e656000c
> >
> >This confuses me even more: why no DMA_TO_DEVICE mapping in the
> >latter case?
>
> I believe the DEVICE being reffered in DMA_FROM_DEVICE is
> DMAC rather than FIFO TX register.
> So from DMAC's point of view, the dma of DMAC->FIFO TX register
> should be think of it as DMA_FROM_DEVICE.
>
> >> };
> >>
> >> static bool ipmmu_device_is_allowed(struct device *dev)
> >
> >Gr{oetje,eeting}s,
> >
> > Geert
>
> Sincerely,
> Ryo Takakura
Hi Geert and Takakura-san,
My sincere apologies for the very late follow-up email. Unfortunately, I
don't have access to Gray Hawk Single / Sparrow Hawk boards myself, so I
have not been able to reproduce the issue locally. Takakura-san does have
access to them and was able to reproduce the problem, thanks, Takakura-san.
As an update, at least for me, this patch will no longer be necessary due
to another ongoing work, "NTB transport backed by remote DW eDMA":
https://lore.kernel.org/all/20251129160405.2568284-1-den@valinux.co.jp/
Given that, I'm rather inclined to keep this on hold for now, unless you
have any objections.
Thank you both for your time and support.
Koichiro
© 2016 - 2026 Red Hat, Inc.