26.03.2021 19:55, Dmitry Osipenko пишет: > 26.03.2021 19:35, Thierry Reding пишет: >> On Fri, Mar 26, 2021 at 06:29:28PM +0300, Dmitry Osipenko wrote: >>> 25.03.2021 16:03, Thierry Reding пишет: >>>> From: Thierry Reding <treding@xxxxxxxxxx> >>>> >>>> Hi, >>>> >>>> this is a set of patches that is the result of earlier discussions >>>> regarding early identity mappings that are needed to avoid SMMU faults >>>> during early boot. >>>> >>>> The goal here is to avoid early identity mappings altogether and instead >>>> postpone the need for the identity mappings to when devices are attached >>>> to the SMMU. This works by making the SMMU driver coordinate with the >>>> memory controller driver on when to start enforcing SMMU translations. >>>> This makes Tegra behave in a more standard way and pushes the code to >>>> deal with the Tegra-specific programming into the NVIDIA SMMU >>>> implementation. >>> >>> It is an interesting idea which inspired me to try to apply a somewhat similar thing to Tegra SMMU driver by holding the SMMU ASID enable-bit until display driver allows to toggle it. This means that we will need an extra small tegra-specific SMMU API function, but it should be okay. >>> >>> I typed a patch and seems it's working good, I'll prepare a proper patch if you like it. >> >> That would actually be working around the problem that this patch was >> supposed to prepare for. The reason for this current patch series is to >> make sure SMMU translation isn't enabled until a device has actually >> been attached to the SMMU. Once it has been attached, the assumption is >> that any identity mappings will have been created. >> >> One Tegra SMMU that shouldn't be a problem because translations aren't >> enabled until device attach time. So in other words this patch set is to >> get Tegra186 and later to parity with earlier chips from this point of >> view. >> >> I think the problem that you're trying to work around is better solved >> by establishing these identity mappings. I do have patches to implement >> this for Tegra210 and earlier, though they may require additional work >> if you have bootloaders that don't use standard DT bindings for passing >> information about the framebuffer to the kernel. > > I'm not sure what else reasonable could be done without upgrading to a > very specific version of firmware, which definitely isn't a variant for > older devices which have a wild variety of bootloaders, customized > use-cases and etc. > > We could add a kludge that I'm suggesting as a universal fallback > solution, it should work well for all cases that I care about. > > So we could have the variant with identity mappings, and if mapping > isn't provided, then fall back to the kludge. > I tried a slightly different variant of the kludge by holding the ASID's enable till the first mapping is created for the display clients and IOMMU_DOMAIN_DMA now works properly (no EMEM errors on boot and etc) and without a need to change the DC driver. I also tried to remove the arm_iommu_detach_device() from the VDE driver and we now have 3 implicit domains in use (DRM, HX, VDE[wasted]) + 1 explicit (VDE) on T30, which works okay for today. So technically we could support the IOMMU_DOMAIN_DMA with a couple small changes right now or at least revert the hacks that were needed for Nyan. But in order to enable IOMMU_DOMAIN_DMA properly, we will need to do something about the DMA mappings first in the DRM driver and I also found that implicit IOMMU somehow doesn't work for host1x driver at all, so this needs to be fixed too.
