* [PATCH] iommu: ipmmu-vmsa: Add DMA controllers to devices_allowlist @ 2025-10-27 0:48 Koichiro Den 2025-10-29 16:08 ` Geert Uytterhoeven 0 siblings, 1 reply; 4+ messages in thread From: Koichiro Den @ 2025-10-27 0:48 UTC (permalink / raw) To: iommu, linux-renesas-soc, linux-kernel; +Cc: joro, will, robin.murphy 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 ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] iommu: ipmmu-vmsa: Add DMA controllers to devices_allowlist 2025-10-27 0:48 [PATCH] iommu: ipmmu-vmsa: Add DMA controllers to devices_allowlist Koichiro Den @ 2025-10-29 16:08 ` Geert Uytterhoeven 2025-11-03 8:56 ` Ryo Takakura 0 siblings, 1 reply; 4+ messages in thread From: Geert Uytterhoeven @ 2025-10-29 16:08 UTC (permalink / raw) To: Koichiro Den Cc: iommu, linux-renesas-soc, linux-kernel, joro, will, robin.murphy 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] iommu: ipmmu-vmsa: Add DMA controllers to devices_allowlist 2025-10-29 16:08 ` Geert Uytterhoeven @ 2025-11-03 8:56 ` Ryo Takakura 2025-12-01 5:14 ` Koichiro Den 0 siblings, 1 reply; 4+ messages in thread From: Ryo Takakura @ 2025-11-03 8:56 UTC (permalink / raw) To: geert, den Cc: iommu, joro, linux-kernel, linux-renesas-soc, robin.murphy, will 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] iommu: ipmmu-vmsa: Add DMA controllers to devices_allowlist 2025-11-03 8:56 ` Ryo Takakura @ 2025-12-01 5:14 ` Koichiro Den 0 siblings, 0 replies; 4+ messages in thread From: Koichiro Den @ 2025-12-01 5:14 UTC (permalink / raw) To: Ryo Takakura Cc: geert, iommu, joro, linux-kernel, linux-renesas-soc, robin.murphy, will 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-12-01 5:14 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-10-27 0:48 [PATCH] iommu: ipmmu-vmsa: Add DMA controllers to devices_allowlist Koichiro Den 2025-10-29 16:08 ` Geert Uytterhoeven 2025-11-03 8:56 ` Ryo Takakura 2025-12-01 5:14 ` Koichiro Den
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox