On Tue, Apr 05, 2022 at 03:32:50PM +0100, Robin Murphy wrote: > Defer the IOMMU domain setup until after successfully binding > components, so we can figure out IOMMU support directly from the VOP > devices themselves, rather than manually inferring it from the DT (which > also fails to account for whether the IOMMU driver is actually loaded). > Although this is somewhat of a logical cleanup, the main motivation is > to prepare for a change in the iommu_domain_alloc() interface. > > Signed-off-by: Robin Murphy <robin.murphy@xxxxxxx> > --- > > Lightly tested on RK3288. This does stand to collide with the in-flight > VOP2 driver a little, if only that that will want an equivalent > rockchip_drm_dma_init_device() call too be able to use its IOMMU. I'm > happy to help sort that out either way, it just depends on what we want > to merge first. I tested it with the VOP2 driver. It needed a little refactoring, I had to move the call to rockchip_drm_dma_attach_device() from vop2_bind() to vop2_enable(), but then it works as expected. Assuming that this patch goes through Heikos tree just like the VOP2 driver we can merge it first. I'll base the next VOP2 round on it. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
