On 2014/7/21 17:39, Will Deacon wrote: > [re-adding the lists] > > On Mon, Jul 21, 2014 at 02:51:48AM +0100, leizhen wrote: >> Hi, Will > > Hello, > >> I have sent this patch a week ago. I saw that you and Mitchel Humpherys had >> sent some patches which will impact my code. I list below: >> iommu/arm-smmu: remove support for chained SMMUs >> iommu/arm-smmu: fix some checkpatch issues > > There's also all of the development work I'm doing for VFIO and the page-table > rework that Varun's working on, so these patches are going to be difficult > to merge if we ever get to that point. I think Mitchel and Olav are also > busy trying to get their SMMU supported by the driver. Given that they've > actually bothered to follow the architecture, I don't see why they should > be messed about by your patches causing conflicts all over the place. > >> I can ajust my patch because of above. I known this patch is not follow what >> you suggested before(fit into arm-smmu.c). But I found when we need to >> support >> ARM SMMUv3, maybe we should do like this. I really want to know whether or >> not >> you agree the software framework in this patch? Or what do you think about >> SMMUv3? > > The only code I foresee sharing between SMMUv2 and SMMUv3 is the page-table > creation code. The two architectures are significantly different, so I don't > think your split really helps us there. For example, you've left the probing > code in smmu-base.c. Of course, if HiSilicon follow the SMMUv3 spec as well > they did with SMMUv2, then your point is moot anyway and we may as well go > home. > >>> I tried to merge hisi-smmu driver into arm-smmu.c, but it looks impossible. >>> The biggest problem is that too many registers are diffrent: the base >>> address, >>> the field definition, or present only on one side. And if I use #if, >>> hisi-smmu >>> and arm-smmu can not coexist in one binary file. Almost need 20 #if. > > I don't think #ifdefs are necessarily the right way to go. There are IMPDEF > parts of a compliant SMMU (e.g. power management), so having a new compatible > string and a set of internal ops which can be overridden by a particular > implementation wouldn't be the end of the world and would be far less > invasive. > > The problem you have is that your SMMU isn't architecturally compliant, so > you'll end up having to restructure parts of the driver so you can add > internal hooks for operations that aren't actually IMPDEF. That's the part > I'm worried about and we will have to draw the line somewhere, especially > when other people are trying to work with this code for compliant > implementations. > > So, NAK to your current approach. You need to try something like I said > above and, if you want to spit the file up, start with the page-table code. > > Will > > . >
OK. We have decided to discard current SMMU hardware design, and will completely follow the SMMUv3 specification. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
