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
