Fixing TegraDRM on multi_v7_defconfig / Enabling DMA API with tegra-smmu

[Mikko Perttunen <mperttunen@nvidia.com>]

Greetings everyone.

I've been looking at enabling more CI for 32-bit Tegra platforms 
recently, and I ran into a problem with TegraDRM not probing on 
tegra30-cardhu, but only on multi_v7_defconfig.

I traced the issue to the following sequence of events:

1. On multi_v7_defconfig, CONFIG_ARM_DMA_USE_IOMMU is enabled, while on 
   tegra_defconfig it is not. This causes arm_setup_iommu_dma_ops to run 
   on TegraDRM devices.

2. Some of these devices will be placed in a single IOMMU group by the 
   tegra-smmu driver. When arm_setup_iommu_dma_ops is called, depending 
   on probe deferrals, the group may have only the currently probing 
   device, or a previously deferred device and the new device.

   arm_setup_iommu_dma_ops calls iommu_attach_device. If the device is 
   alone in its group, this succeeds. If not, this fails. If 
   iommu_attach_device fails for every device in the group, everything 
   is "fine" and TegraDRM goes to probe and work fine. Hence let's 
   assume we have one device that succeeded the attach.

3. iommu_device_use_default_domain gets called and succeeds on the first 
   device in the group. On the second device in the group, it fails 
   since group->owner_cnt was already 1. The custom ARM DMA IOMMU 
   implementation uses a custom UNMANAGED domain so the domain != 
   default_domain check evaluates to true.

4. Devices fail to probe which leads TegraDRM overall not to probe.

I've thought of the following options to fix this:

1. Match behavior with tegra_defconfig: Figure out a way to not run 
   arm_setup_iommu_dma_ops for this situation (ideally any multi-device 
   group situation). However, I'd also like to enable DMA API with 
   tegra-smmu to get rid of the manual IOMMU API code paths in TegraDRM, 
   so this is not a particularly satisfying route.

2. Improve the legacy path: Fix the ARM IOMMU DMA code to support 
   groups, and add an exception in iommu_device_use_default_domain. But 
   I presume we don't want such non-trivial modifications to that code 
   at this point.

3. Modernize: Support CONFIG_IOMMU_DMA on ARM -- since there is an issue 
   with per-SoC quirks, I think this should be done one SoC at a time. 
   So come up with a way to dynamically pick between the legacy and 
   IOMMU_DMA paths. Perhaps if the SMMU driver explicitly requests the 
   DMA domain type, use the modern path. Currently, CONFIG_IOMMU_DMA and 
   CONFIG_ARM_DMA_USE_IOMMU are mutually exclusive so that has to be 
   changed.

FWIW, if we are to move to using DMA API with TegraDRM, one blocker 
would have to be resolved: boot splashes scanning out while the DMA 
domain is being set up. Since we cannot really use the iommu-addresses 
reserved-region device tree bindings with these old devices, my thought 
is to leave the display memory clients in bypass in tegra-smmu until the 
display driver has quiesced the hardware and can then call into 
tegra-smmu to enable translation.

Please let me know what you think and whom I missed in the To/Cc fields.

Thank you
Mikko