Hi Edgar, > Yes, we did SMMUv2 but I think there is opportunity to reuse quite a bit of > code.
I agree > > 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. We can collaborate in refactoring common code. > 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. Yes TT are same w.r.t CPU, my code re-uses the CPU code but just little differently > 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. Yes, I have so far only able to test S1 only, I'll contact you off-list for setting up a Xen based S1+S2 testing. But I guess my hands are tied in this case with S1+FastModels not (yet) having SMMUv3 And Qemu 64-bit ARM doesn't yet have KVM support, I'll be using Qemu v7 And it's a RFC version posted early to avoid duplicate effort and before digging too deep. > 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. No TLB cache so far, I have plans of implementing (or reusing code from your implementation, whichever works). I look forward to having more discussion on this topic. Cheers, /Prem
