Re: [PATCH v12 0/4] iommu: Support mappings/reservations in reserved-memory regions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux