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.
