On Fri, Dec 2, 2022 at 8:41 AM Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > > On Thu, Nov 17, 2022 at 07:54:20PM +0100, Thierry Reding wrote: > > From: Thierry Reding <treding@xxxxxxxxxx> > > > > Hi, > > > > This version is a minor update to the previous v11, which can be found > > here: > > > > https://lore.kernel.org/all/20221111161806.630527-1-thierry.reding@xxxxxxxxx/ > > > > The only change here is that the #dma-{address,size}-cells is dropped. > > It turns out to be much simpler to just update #{address,size}-cells to > > what they should be rather than add extra complexity for the DMA work- > > around. There's a minor update to the DT binding so that it can now > > properly validate cases where we have both reg and iommu-addresses > > properties. > > > > An example is included in the DT bindings, but here is an extract of > > what I've used to test this: > > > > reserved-memory { > > #address-cells = <2>; > > #size-cells = <2>; > > ranges; > > > > /* > > * Creates an identity mapping for the framebuffer that > > * the firmware has setup to scan out a bootsplash from. > > */ > > fb: framebuffer@92cb2000 { > > reg = <0x0 0x92cb2000 0x0 0x00800000>; > > iommu-addresses = <&dc0 0x0 0x92cb2000 0x0 0x00800000>; > > }; > > > > /* > > * Creates a reservation in the IOVA space to prevent > > * any buffers from being mapped to that region. Note > > * that on Tegra the range is actually quite different > > * from this, but it would conflict with the display > > * driver that I tested this against, so this is just > > * a dummy region for testing. > > */ > > adsp: reservation-adsp { > > iommu-addresses = <&dc0 0x0 0x90000000 0x0 0x00010000>; > > }; > > }; > > > > host1x@50000000 { > > dc@54200000 { > > memory-region = <&fb>, <&adsp>; > > }; > > }; > > > > This is abbreviated a little to focus on the essentials. Note also that > > the ADSP reservation is not actually used on this device and the driver > > for this doesn't exist yet, but I wanted to include this variant for > > testing, because we'll want to use these bindings for the reservation > > use-case as well at some point. > > > > I've also been able to make use of this binding and the IOMMU code in > > conjunction with the simple-framebuffer driver to hand over a display > > configuration set up by UEFI to the Linux kernel. > > > > Janne has confirmed[0] this to be suitable for indirect mappings as > > well, though these patches don't implement that feature yet. Potential > > extensions to this have been discussed but are not yet included at this > > time to not further complicate things. > > > > Thierry > > > > [0]: https://lore.kernel.org/all/20220909144504.GA4024@xxxxxxxxxx/ > > > > Thierry Reding (4): > > of: Introduce of_translate_dma_region() > > dt-bindings: reserved-memory: Document iommu-addresses > > iommu: Implement of_iommu_get_resv_regions() > > iommu: dma: Use of_iommu_get_resv_regions() > > > > .../reserved-memory/reserved-memory.yaml | 89 +++++++++++++++++- > > drivers/iommu/dma-iommu.c | 3 + > > drivers/iommu/of_iommu.c | 94 +++++++++++++++++++ > > drivers/of/address.c | 41 ++++++++ > > include/linux/of_address.h | 2 + > > include/linux/of_iommu.h | 8 ++ > > 6 files changed, 233 insertions(+), 4 deletions(-) > > Joerg, Rob, > > Is there anything left to do on the series? It'd be great to get some > feedback from Robin on patch 3 since he had some concerns about how the > reservation type was getting determined. All those should now be > addressed and I think overall this is ready to go. > > Rob, you've given a Reviewed-by on all the DT-related parts, does that > mean you're okay with this going through Joerg's tree? Yes. Okay with and what I'm expecting. Rob
