Hi Geert, On Thu, Oct 27, 2016 at 7:42 PM, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > Hi Magnus, > > On Thu, Oct 27, 2016 at 12:29 PM, Magnus Damm <magnus.damm@xxxxxxxxx> wrote: >> From: Magnus Damm <damm+renesas@xxxxxxxxxxxxx> >> >> Hook up r8a7795 DMAC nodes to IPMMU-MP1, IPMMU-DS0 and IPMMU-DS1. >> >> Signed-off-by: Magnus Damm <damm+renesas@xxxxxxxxxxxxx> >> --- >> >> This patch can be merged any time, but it is however not recommended >> to enable IPMMU-MP1, IPMMU-DS0 or IPMMU-DS1 until various dependencies >> have been resolved: > > Forgive my ignorance, but how does the driver core treat devices with > iommus properties pointing to disabled IOMMU nodes? > Is this ignored silently, or does this cause -EPROBEDEFER, like for clocks > and power-domains? Not sure about current state of the driver core to be honest. Earlier I needed to add a local workaround in the ->xlate() callback in the IPMMU driver but I need to revisit to see if that needs to be updated. Any ideas? I do however know that the IPMMU driver stack included in renesas-drivers works both with and without iommus properties and in case an iommus property is used then both enabled and disabled are known to work. Looking at mainline, at this point the IPMMU driver changes for r8a7795 and r8a7796 are not included yet, so there is no driver code that will match with the DT compat string. Once we queue up the IPMMU driver code for merge then we need to make sure it still works as expected. I just booted r8a7795 Salvator-X with these patches on top of renesas-devel-20161024-v4.9-rc2 (that lacks the IPMMU driver for r8a7795) and the DU device that is connected via FCP and VSP operate as usual. So all seems fine what I can tell. Thanks, / magnus
