Thread (34 messages) 34 messages, 7 authors, 2021-04-15

Re: [RFC PATCH v2 0/8] ACPI/IORT: Support for IORT RMR node

From: Steven Price <steven.price@arm.com>
Date: 2020-12-10 10:27:23
Also in: linux-acpi, linux-iommu

On 19/11/2020 12:11, Shameer Kolothum wrote:
RFC v1 --> v2:
  - Added a generic interface for IOMMU drivers to retrieve all the
    RMR info associated with a given IOMMU.
  - SMMUv3 driver gets the RMR list during probe() and installs
    bypass STEs for all the SIDs in the RMR list. This is to keep
    the ongoing traffic alive(if any) during SMMUv3 reset. This is
    based on the suggestions received for v1 to take care of the
    EFI framebuffer use case. Only sanity tested for now.
Hi Shameer,

Sorry for not looking at this before.

Do you have any plans to implement support in the SMMUv2 driver? The 
platform I've been testing the EFI framebuffer support on has the 
display controller behind SMMUv2, so as it stands this series doesn't 
work. I did hack something up for SMMUv2 so I was able to test the first 
4 patches.
  - During the probe/attach device, SMMUv3 driver reserves any
    RMR region associated with the device such that there is a unity
    mapping for them in SMMU.
For the EFI framebuffer use case there is no device to attach so I 
believe we are left with just the stream ID in bypass mode - which is 
definitely an improvement (the display works!) but not actually a unity 
mapping of the RMR range. I'm not sure whether it's worth fixing this or 
not, but I just wanted to point out there's still a need for a driver 
for the device before the bypass mode is replaced with the unity mapping.

Thanks,

Steve

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help