Re: [PATCH] iommu: ipmmu-vmsa: Add DMA controllers to devices_allowlist

[Ryo Takakura]

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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx>
>
>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