Hi,

This series adds a driver for the Broadcom BCM2712 IOMMU found on
Raspberry Pi 5, and hooks up the display controller IOMMU for efficient
management of graphics memory. This is adapted from the downstream driver
from Raspberry Pi (original author Nick Hollinghurst), with main changes:
 - In page mapping mode, operate the translation aperture from address 0,
   with no bypass window. More like a IOMMU and less like a GART.
 - Implement the page table management using generic_pt
 - Support 4MB hugepage mapping in top level page table
 - Implement brcm,iommu-cache as standards-compliant DT property
 - Drop the dma-iova-offset hack, used to work around some issue seen with
   dma-ranges. This will need to be investigated separately and solved
   properly. (It's not needed for display controller iommu support included
   here.)
 - Misc simplifications/standardisations/cleanups
 
The IOMMU works strictly with 4KB pages. This means that unfortunately
when the kernel is compiled with PAGE_SIZE=16KB (the Raspberry Pi 5
kernel default), 12KB is wasted in each page that is allocated for page
tables. I plan to address this in followup work.

It has been tested on Raspberry Pi 5 using a 3D-accelerated graphical
environment which causes plenty of IOMMU maps & unmaps.

Thanks for the review comments and discussion. Further feedback and
testing welcome!

Changes in v4:
- Add Jim Quinlan and Florian Fainelli as bindings maintainers
- Replace MMU register access macros with static inline functions
- Clear illegal address register and flush caches on blocking domain attach
- Add __must_hold annotations in TLB helpers
- Use BIT() macro for MMUC_CONTROL definitions
- Link to v3: https://lore.kernel.org/r/20260825-bcm2712-iommu-submit-v3-0-7f143e7289b6@reactivated.net

Changes in v3:
- Switch from a aperture and bypass window GART-like approach
  to IOMMU-like 0-based translation
- Add 3 SW bits which seem unused (per the chipset docs); drop patch
  for NO_SW_BIT handling. This reduces the claimed address space, so I had
  to tweak a iommu_pt test accordingly.
- Disallow domain sharing across multiple hardware IOMMU instances
- Clear and flush local MMU TLB during domain attach
- Handle unattached domains safely during TLB sync
- Set cache platform driver data late during probe to prevent race condition
- Improved handling of cache flush timeouts
- Use format string for device name in iommu_device_sysfs_add()
- Use cleanup.h helpers for scope management
- Expand DT binding descriptions for IOMMU and IOMMUC
- Add iommus property to HVS display node in DT
- Drop iommuc back-compat with current RPi DT
- Link to v2: https://lore.kernel.org/r/20260727-bcm2712-iommu-submit-v2-0-0247b5c03de8@reactivated.net

Changes in v2:
- Use iommu_fwspec in xlate & probe_device
- Add blocked_domain support
- Simplify page size configuration between iommu driver and format
- Introduce PT_FEAT_NO_SW_BIT flag to allow formats to explicitly opt-in to
  a defensive flushing algorithm when no sw bit is available
- Implement 4MB pages at Level 1; this is more efficient and means the
  "allow full-table contiguous leaves in unit tests" commit has been
  dropped because it is no longer needed.
- Hardcode the aperture in an unused part of the address space, removing
  it from DT (it's a software-specific decision, not an attribute of the
  hardware), adding more explanatory comments
- Use pt_full_va_prefix to have the PT format operate within the aperture
  space, enabling use of IOMMU_PT_DOMAIN_OPS
- Add more dt-bindings explanation to brcm,iommu-cache and drop docs
  around the cache property used in RPi firmware (the driver still supports
  this however, for fw compat reasons)
- Correct iommu device address in bcm2712.dtsi
- Link to v1: https://lore.kernel.org/r/20260712-bcm2712-iommu-submit-v1-0-80e10cdde2ea@reactivated.net

---
Daniel Drake (5):
      iommu_pt: Fix test_pgsize_boundary() failure on narrow-OA formats
      dt-bindings: iommu: Add Broadcom BCM2712 IOMMU
      iommu/generic_pt: Add Broadcom BCM2712 page table format
      iommu: Add Broadcom BCM2712 IOMMU driver
      arm64: dts: broadcom: bcm2712: Add GPU IOMMU and IOMMU cache nodes

 .../bindings/iommu/brcm,bcm2712-iommu.yaml         |  54 ++
 .../bindings/iommu/brcm,bcm2712-iommuc.yaml        |  40 ++
 arch/arm64/boot/dts/broadcom/bcm2712.dtsi          |  15 +
 drivers/iommu/Kconfig                              |  15 +
 drivers/iommu/Makefile                             |   1 +
 drivers/iommu/bcm2712-iommu-cache.c                |  84 +++
 drivers/iommu/bcm2712-iommu-cache.h                |   9 +
 drivers/iommu/bcm2712-iommu.c                      | 577 +++++++++++++++++++++
 drivers/iommu/generic_pt/.kunitconfig              |   1 +
 drivers/iommu/generic_pt/Kconfig                   |  10 +
 drivers/iommu/generic_pt/fmt/Makefile              |   2 +
 drivers/iommu/generic_pt/fmt/bcm2712.h             | 288 ++++++++++
 drivers/iommu/generic_pt/fmt/defs_bcm2712.h        |  18 +
 drivers/iommu/generic_pt/fmt/iommu_bcm2712.c       |   6 +
 drivers/iommu/generic_pt/kunit_iommu_pt.h          |   2 +-
 include/linux/generic_pt/common.h                  |   6 +
 include/linux/generic_pt/iommu.h                   |  12 +
 17 files changed, 1139 insertions(+), 1 deletion(-)
---
base-commit: 786262be6048deab760f68c8acc2c85607165894
change-id: 20260712-bcm2712-iommu-submit-2e09899e65c4

Best regards,
-- 
Daniel Drake <dan@reactivated.net>

s

On Wed, Sep 2, 2026 at 1:58 PM Daniel Drake <dan@reactivated.net> wrote:
>
> Hi,
>
> This series adds a driver for the Broadcom BCM2712 IOMMU found on
> Raspberry Pi 5, and hooks up the display controller IOMMU for efficient
> management of graphics memory. This is adapted from the downstream driver
> from Raspberry Pi (original author Nick Hollinghurst), with main changes:
>  - In page mapping mode, operate the translation aperture from address 0,
>    with no bypass window. More like a IOMMU and less like a GART.
>  - Implement the page table management using generic_pt
>  - Support 4MB hugepage mapping in top level page table
>  - Implement brcm,iommu-cache as standards-compliant DT property
>  - Drop the dma-iova-offset hack, used to work around some issue seen with
>    dma-ranges. This will need to be investigated separately and solved
>    properly. (It's not needed for display controller iommu support included
>    here.)

Hi Daniel,
I wish you had kept the dma-iova offset hack but I understand why you
did not.  I've built and successfully tested your driver on the
Broadcom sister chip of the RpI 5.  I am mostly interested in the
iommu attached to the PCIe controller.  I tested this by running
multiple tests where 10MiB is sent by a Wifi chip.  Data integrity was
validated of course.

I did not use the driver code as is.  I tried merely decrementing the
MMMU_PT_PA_BASE value for the 4GB iova-offset required for our
configuration, but that did not work for some reason.  So I just
hacked in some iova conversions and got it working.

At any rate, LGTM and thanks for submitting this.

Regards,
Jim Quinlan
Broadcom


>  - Misc simplifications/standardisations/cleanups
>
> The IOMMU works strictly with 4KB pages. This means that unfortunately
> when the kernel is compiled with PAGE_SIZE=16KB (the Raspberry Pi 5
> kernel default), 12KB is wasted in each page that is allocated for page
> tables. I plan to address this in followup work.
>
> It has been tested on Raspberry Pi 5 using a 3D-accelerated graphical
> environment which causes plenty of IOMMU maps & unmaps.
>
> Thanks for the review comments and discussion. Further feedback and
> testing welcome!
>
> Changes in v4:
> - Add Jim Quinlan and Florian Fainelli as bindings maintainers
> - Replace MMU register access macros with static inline functions
> - Clear illegal address register and flush caches on blocking domain attach
> - Add __must_hold annotations in TLB helpers
> - Use BIT() macro for MMUC_CONTROL definitions
> - Link to v3: https://lore.kernel.org/r/20260825-bcm2712-iommu-submit-v3-0-7f143e7289b6@reactivated.net
>
> Changes in v3:
> - Switch from a aperture and bypass window GART-like approach
>   to IOMMU-like 0-based translation
> - Add 3 SW bits which seem unused (per the chipset docs); drop patch
>   for NO_SW_BIT handling. This reduces the claimed address space, so I had
>   to tweak a iommu_pt test accordingly.
> - Disallow domain sharing across multiple hardware IOMMU instances
> - Clear and flush local MMU TLB during domain attach
> - Handle unattached domains safely during TLB sync
> - Set cache platform driver data late during probe to prevent race condition
> - Improved handling of cache flush timeouts
> - Use format string for device name in iommu_device_sysfs_add()
> - Use cleanup.h helpers for scope management
> - Expand DT binding descriptions for IOMMU and IOMMUC
> - Add iommus property to HVS display node in DT
> - Drop iommuc back-compat with current RPi DT
> - Link to v2: https://lore.kernel.org/r/20260727-bcm2712-iommu-submit-v2-0-0247b5c03de8@reactivated.net
>
> Changes in v2:
> - Use iommu_fwspec in xlate & probe_device
> - Add blocked_domain support
> - Simplify page size configuration between iommu driver and format
> - Introduce PT_FEAT_NO_SW_BIT flag to allow formats to explicitly opt-in to
>   a defensive flushing algorithm when no sw bit is available
> - Implement 4MB pages at Level 1; this is more efficient and means the
>   "allow full-table contiguous leaves in unit tests" commit has been
>   dropped because it is no longer needed.
> - Hardcode the aperture in an unused part of the address space, removing
>   it from DT (it's a software-specific decision, not an attribute of the
>   hardware), adding more explanatory comments
> - Use pt_full_va_prefix to have the PT format operate within the aperture
>   space, enabling use of IOMMU_PT_DOMAIN_OPS
> - Add more dt-bindings explanation to brcm,iommu-cache and drop docs
>   around the cache property used in RPi firmware (the driver still supports
>   this however, for fw compat reasons)
> - Correct iommu device address in bcm2712.dtsi
> - Link to v1: https://lore.kernel.org/r/20260712-bcm2712-iommu-submit-v1-0-80e10cdde2ea@reactivated.net
>
> ---
> Daniel Drake (5):
>       iommu_pt: Fix test_pgsize_boundary() failure on narrow-OA formats
>       dt-bindings: iommu: Add Broadcom BCM2712 IOMMU
>       iommu/generic_pt: Add Broadcom BCM2712 page table format
>       iommu: Add Broadcom BCM2712 IOMMU driver
>       arm64: dts: broadcom: bcm2712: Add GPU IOMMU and IOMMU cache nodes
>
>  .../bindings/iommu/brcm,bcm2712-iommu.yaml         |  54 ++
>  .../bindings/iommu/brcm,bcm2712-iommuc.yaml        |  40 ++
>  arch/arm64/boot/dts/broadcom/bcm2712.dtsi          |  15 +
>  drivers/iommu/Kconfig                              |  15 +
>  drivers/iommu/Makefile                             |   1 +
>  drivers/iommu/bcm2712-iommu-cache.c                |  84 +++
>  drivers/iommu/bcm2712-iommu-cache.h                |   9 +
>  drivers/iommu/bcm2712-iommu.c                      | 577 +++++++++++++++++++++
>  drivers/iommu/generic_pt/.kunitconfig              |   1 +
>  drivers/iommu/generic_pt/Kconfig                   |  10 +
>  drivers/iommu/generic_pt/fmt/Makefile              |   2 +
>  drivers/iommu/generic_pt/fmt/bcm2712.h             | 288 ++++++++++
>  drivers/iommu/generic_pt/fmt/defs_bcm2712.h        |  18 +
>  drivers/iommu/generic_pt/fmt/iommu_bcm2712.c       |   6 +
>  drivers/iommu/generic_pt/kunit_iommu_pt.h          |   2 +-
>  include/linux/generic_pt/common.h                  |   6 +
>  include/linux/generic_pt/iommu.h                   |  12 +
>  17 files changed, 1139 insertions(+), 1 deletion(-)
> ---
> base-commit: 786262be6048deab760f68c8acc2c85607165894
> change-id: 20260712-bcm2712-iommu-submit-2e09899e65c4
>
> Best regards,
> --
> Daniel Drake <dan@reactivated.net>
>

On 03/09/2026 19:14, Jim Quinlan wrote:
> I wish you had kept the dma-iova offset hack but I understand why you
> did not.


Well, having an initial iommu driver upstream will provide a good base 
on top of which we can work on that specific problem. It'll need some 
consideration/discussion to be done in a way that is not regarded as a 
hack. I might come back to this later, time permitting.

 > I've built and successfully tested your driver on the> Broadcom 
sister chip of the RpI 5.  I am mostly interested in the
> iommu attached to the PCIe controller.  I tested this by running
> multiple tests where 10MiB is sent by a Wifi chip.  Data integrity was
> validated of course.
> 
> I did not use the driver code as is.  I tried merely decrementing the
> MMMU_PT_PA_BASE value for the 4GB iova-offset required for our
> configuration, but that did not work for some reason.  So I just
> hacked in some iova conversions and got it working.

Thanks for the review and testing! I'll send an updated version that 
removes the blocking domain, hopefully that will be ready for inclusion.

Daniel

On Sat, Sep 5, 2026 at 3:25 PM Daniel Drake <dan@reactivated.net> wrote:
>
> On 03/09/2026 19:14, Jim Quinlan wrote:
> > I wish you had kept the dma-iova offset hack but I understand why you
> > did not.
>
>
> Well, having an initial iommu driver upstream will provide a good base
> on top of which we can work on that specific problem. It'll need some
> consideration/discussion to be done in a way that is not regarded as a
> hack. I might come back to this later, time permitting.

Yes, I plan on submitting an RFC on how to do this, assuming you don't
solve it first :-).
FWIW, I had to do the following to get your driver working on our 7712
PCIe IOMMU:

o force the aperture to start at SZ_4G
o change pt_full_va_prefix() to return SZ_4G (but it should really
return an offset derived from the dma-ranges prop of the PCIe node)
o modify bcm2712_iommu_shootdown_range() and
bcm2712_iommu_sync_range() to subtract SZ_4G from the iova.

Regards,
Jim Quinlan
Broadcom CM/STB
>
>  > I've built and successfully tested your driver on the> Broadcom
> sister chip of the RpI 5.  I am mostly interested in the
> > iommu attached to the PCIe controller.  I tested this by running
> > multiple tests where 10MiB is sent by a Wifi chip.  Data integrity was
> > validated of course.
> >
> > I did not use the driver code as is.  I tried merely decrementing the
> > MMMU_PT_PA_BASE value for the 4GB iova-offset required for our
> > configuration, but that did not work for some reason.  So I just
> > hacked in some iova conversions and got it working.
>
> Thanks for the review and testing! I'll send an updated version that
> removes the blocking domain, hopefully that will be ready for inclusion.
>
> Daniel
>