15.09.2021 15:09, Dmitry Osipenko пишет: > 15.09.2021 07:38, Nicolin Chen пишет: >> On Tue, Sep 14, 2021 at 10:20:30PM +0300, Dmitry Osipenko wrote: >>> 14.09.2021 21:49, Nicolin Chen пишет: >>>> On Tue, Sep 14, 2021 at 04:29:15PM +0300, Dmitry Osipenko wrote: >>>>> 14.09.2021 04:38, Nicolin Chen пишет: >>>>>> +static unsigned long pd_pt_index_iova(unsigned int pd_index, unsigned int pt_index) >>>>>> +{ >>>>>> + return ((dma_addr_t)pd_index & (SMMU_NUM_PDE - 1)) << SMMU_PDE_SHIFT | >>>>>> + ((dma_addr_t)pt_index & (SMMU_NUM_PTE - 1)) << SMMU_PTE_SHIFT; >>>>>> +} >>>>> >>>>> We know that IOVA is fixed to u32 for this controller. Can we avoid all >>>>> these dma_addr_t castings? It should make code cleaner a tad, IMO. >>>> >>>> Tegra210 actually supports 34-bit IOVA... >>>> >>> >>> It doesn't. 34-bit is PA, 32-bit is VA. >>> >>> Quote from T210 TRM: >>> >>> "The SMMU is a centralized virtual-to-physical translation for MSS. It >>> maps a 32-bit virtual address to a 34-bit physical address. If the >>> client address is 40 bits then bits 39:32 are ignored." >> >> If you scroll down by a couple of sections, you can see 34-bit >> virtual addresses in section 18.6.1.2; and if checking one ASID >> register, you can see it mention the extra two bits va[33:32]. > > Thanks for the pointer. It says that only certain memory clients allow > to combine 4 ASIDs to form 34bit VA space. In this case the PA space is > split into 4GB areas and there are additional bitfields which configure > the ASID mapping of each 4GB area. Still each ASID is 32bit. > > This is what TRM says: > > "For the GPU and other clients with 34-bit address interfaces, the ASID > registers are extended to point to four ASIDs. The SMMU supports 4GB of > virtual address space per ASID, so mapping addr[33:32] into ASID[1:0] > extends the virtual address space of a client to 16GB." > >> However, the driver currently sets its geometry.aperture_end to >> 32-bit, and we can only get 32-bit IOVAs using PDE and PTE only, >> so I think it should be safe to remove the castings here. I'll >> wait for a couple of days and see if there'd be other comments >> for me to address in next version. > > You will need to read the special "ASID Assignment Register" which > supports 4 sub-ASIDs to translate the PA address into the actual VA. By * VA to PA > default all clients are limited to a single ASID and upstream kernel > doesn't support programming of 34bit VAs. So doesn't worth the effort to > fully translate the VA, IMO. > >>> Even if it supported more than 32bit, then the returned ulong is 32bit, >>> which doesn't make sense. >> >> On ARM64 (Tegra210), isn't ulong 64-bit? > > Yes, indeed. >