On Thu, Jul 4, 2019 at 1:20 AM Joerg Roedel joro@8bytes.org wrote:
Hi Rob,
On Tue, Jul 02, 2019 at 01:26:18PM -0700, Rob Clark wrote:
- In some cases the bootloader takes the iommu out of bypass and enables the display. This is in particular a problem on the aarch64 laptops that exist these days, and modern snapdragon android devices. (Older devices also enabled the display in bootloader but did not take the iommu out of bypass.) Attaching a DMA or IDENTITY domain while scanout is active, before the driver has a chance to intervene, makes things go *boom*
Just to make sure I get this right: The bootloader inializes the SMMU and creates non-identity mappings for the GPU? And when the SMMU driver in Linux takes over this breaks display output.
correct
/** If driver is going to manage iommu directly, then avoid* attaching any non driver managed domain. There could* be already active dma underway (ie. scanout in case of* bootloader enabled display), and interfering with that* will make things go *boom**/if ((domain->type != IOMMU_DOMAIN_UNMANAGED) &&dev->driver && dev->driver->driver_manages_iommu)return 0;When the default domain is attached, there is usually no driver attached yet. I think this needs to be communicated by the firmware to Linux and the code should check against that.
At least for the OF case, it happens in the of_dma_configure() which happens from really_probe(), so there is normally a driver. There are a few exceptional cases, where drivers call of_dma_configure() on their own sub-device without a driver attached (hence the need to check if dev->driver is NULL).
I'm also interested in the ACPI case eventually... the aarch64 "windows" laptops do have ACPI. But for now we are booting with DT since there is quite a lot of work before we get to point of using ACPI. (In particular, under windows, device power management is done thru a Platform Extension Plugin (PEP), but so far linux has no such mechanism.)
We really don't have control of the firmware. But when arm-smmu is probed it can read back the hw state and figure out what is going on (with an RFC series[1] from Bjorn which was posted earlier), so we don't really need to depend on the firmware.
bool suppress_bind_attrs; /* disables bind/unbind via sysfs */
bool suppress_bind_attrs:1; /* disables bind/unbind via sysfs */bool driver_manages_iommu:1; /* driver manages IOMMU explicitly */How does this field get set?
It is set in the driver in the second patch[2] in this series.
BR, -R
[1] https://www.spinics.net/lists/arm-kernel/msg732246.html [2] https://patchwork.freedesktop.org/patch/315291/