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

[Thierry Reding <thierry.reding@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4233 bytes --]

On Thu, Nov 17, 2022 at 07:54:20PM +0100, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
> 
> 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@gmail.com/
> 
> 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@jannau.net/
> 
> 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?

Joerg, other than a Reviewed-by from Robin on patch 3, anything else
you'd like to see before you pick this up?

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]