On Mon, Jan 18, 2016 at 06:11:35AM +0000, Prem (Premachandra) Mallappa wrote: > > Edgar has done all of the SMMU work for Xilinx, he knows it the best. > > I'll let him comment on it. > > > > For anyone interested you can see our implementation at: > > https://github.com/Xilinx/qemu/blob/master/hw/misc/arm-smmu.c. It does > > use the register API that we have been trying to upstream. > > > Hi, > I took a quick look at the code, The Xilinx implements mmu-500 which is a > SMMU- v2. > I am not very familiar with V2, however, the architecture and internal > workings are different between v2 and v3. > hence there are 2 different drivers in Linux for V2 and V3, and the code I > posted is for SMMU-v3. >
Hi, Yes, we did SMMUv2 but I think there is opportunity to reuse quite a bit of code. I don't mind basing the implementation from the broadcom code but there are a few things that could be taken from our our code or at least re-implemented. I haven't looked at the SMMUv3 at all but I'm guessing the translation tables are the same. We could share code between a v2 and a v3 SMMU and possibly even some of it with the CPU models. Our translation code has been tested with S1 only, S2 only and S1 + S2. We've ran it with the Linux SMMU v2 driver, XEN SMMU v2 driver and our internal testsuites. This code could be a candidate for merging with your SMMU code as I noticed that the broadcom implementation is lacking some of the modes. Another thing I noticed is that it doesn't seem like you've modelled the TBUs (these may be named differently in SMMUv3 terminology if they even exist)? Anyway, we need these as the address-spaces on the ZynqMP are not all the same for all TBUs. Cheers, Edgar