25.01.2019 12:23, Thierry Reding пишет: > On Fri, Jan 25, 2019 at 12:38:01AM +0300, Dmitry Osipenko wrote: >> 24.01.2019 21:02, Thierry Reding пишет: >>> From: Thierry Reding <treding@xxxxxxxxxx> >>> >>> Tegra186 and later are different from earlier generations in that they >>> use an ARM SMMU rather than the Tegra SMMU. The ARM SMMU driver behaves >>> slightly differently in that the geometry for IOMMU domains is set only >>> after a device was attached to it. This is to make sure that the SMMU >>> instance that the domain belongs to is known, because each instance can >>> have a different input address space (i.e. geometry). >>> >>> Work around this by moving all IOVA allocations to a point where the >>> geometry of the domain is properly initialized. >>> >>> This second version of the series addresses all review comments and adds >>> a number of patches that will actually allow host1x to work with an SMMU >>> enabled on Tegra186. The patches also add programming required to >>> address the full 40 bits of address space. >>> >>> This supersedes the following patch: >>> >>> https://patchwork.kernel.org/patch/10775579/ >> >> My understanding is that falcon won't boot because source DMA address >> of the firmware isn't set up correctly if the address is >32bit. >> Please correct me if I'm wrong, otherwise that need to be addressed in >> this series as well for completeness. > > What makes you say so? I was runtime testing this series as I was > developing these patches and this works properly on Tegra186 with a 40 > bit address space. Since the carveout is allocated from the top of the > IOMMU aperture, the addresses that the Falcon sees are always from the > top of the 40 bit IOVA space and this works flawlessly. I looked again at the code and noticed this time that the address is *shifted* by 256 bytes. Mikko told yesterday about the alignment requirement, but I just wasn't seeing the shifting in the code. Looks good then!