On Fri, Apr 23, 2021 at 06:32:30PM +0200, Thierry Reding wrote: > From: Thierry Reding <treding@xxxxxxxxxx> > > Reserved memory region phandle references can be accompanied by a > specifier that provides additional information about how that specific > reference should be treated. > > One use-case is to mark a memory region as needing an identity mapping > in the system's IOMMU for the device that references the region. This is > needed for example when the bootloader has set up hardware (such as a > display controller) to actively access a memory region (e.g. a boot > splash screen framebuffer) during boot. The operating system can use the > identity mapping flag from the specifier to make sure an IOMMU identity > mapping is set up for the framebuffer before IOMMU translations are > enabled for the display controller. > > Signed-off-by: Thierry Reding <treding@xxxxxxxxxx> > --- > .../reserved-memory/reserved-memory.txt | 21 +++++++++++++++++++ > include/dt-bindings/reserved-memory.h | 8 +++++++ > 2 files changed, 29 insertions(+) > create mode 100644 include/dt-bindings/reserved-memory.h Sorry for being slow on this. I have 2 concerns. First, this creates an ABI issue. A DT with cells in 'memory-region' will not be understood by an existing OS. I'm less concerned about this if we address that with a stable fix. (Though I'm pretty sure we've naively added #?-cells in the past ignoring this issue.) Second, it could be the bootloader setting up the reserved region. If a node already has 'memory-region', then adding more regions is more complicated compared to adding new properties. And defining what each memory-region entry is or how many in schemas is impossible. Both could be addressed with a new property. Perhaps something like 'iommu-memory-region = <&phandle>;'. I think the 'iommu' prefix is appropriate given this is entirely because of the IOMMU being in the mix. I might feel differently if we had other uses for cells, but I don't really see it in this case. Rob
