> -----Original Message----- > From: Robin Murphy [mailto:robin.murphy@xxxxxxx] > Sent: Monday, March 05, 2018 21:07 > To: Nipun Gupta <nipun.gupta@xxxxxxx>; will.deacon@xxxxxxx; > mark.rutland@xxxxxxx; catalin.marinas@xxxxxxx > Cc: iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx; robh+dt@xxxxxxxxxx; hch@xxxxxx; > m.szyprowski@xxxxxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx; joro@xxxxxxxxxx; > Leo Li <leoyang.li@xxxxxxx>; shawnguo@xxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; linux-arm- > kernel@xxxxxxxxxxxxxxxxxxx; linuxppc-dev@xxxxxxxxxxxxxxxx; Bharat Bhushan > <bharat.bhushan@xxxxxxx>; stuyoder@xxxxxxxxx; Laurentiu Tudor > <laurentiu.tudor@xxxxxxx> > Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding > > On 05/03/18 15:00, Nipun Gupta wrote: > > > > > >> -----Original Message----- > >> From: Robin Murphy [mailto:robin.murphy@xxxxxxx] > >> Sent: Monday, March 05, 2018 20:23 > >> To: Nipun Gupta <nipun.gupta@xxxxxxx>; will.deacon@xxxxxxx; > >> mark.rutland@xxxxxxx; catalin.marinas@xxxxxxx > >> Cc: iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx; robh+dt@xxxxxxxxxx; hch@xxxxxx; > >> m.szyprowski@xxxxxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx; > joro@xxxxxxxxxx; > >> Leo Li <leoyang.li@xxxxxxx>; shawnguo@xxxxxxxxxx; linux- > >> kernel@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; linux-arm- > >> kernel@xxxxxxxxxxxxxxxxxxx; linuxppc-dev@xxxxxxxxxxxxxxxx; Bharat Bhushan > >> <bharat.bhushan@xxxxxxx>; stuyoder@xxxxxxxxx; Laurentiu Tudor > >> <laurentiu.tudor@xxxxxxx> > >> Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree > binding > >> > >> On 05/03/18 14:29, Nipun Gupta wrote: > >>> The existing IOMMU bindings cannot be used to specify the relationship > >>> between fsl-mc devices and IOMMUs. This patch adds a binding for > >>> mapping fsl-mc devices to IOMMUs, using a new iommu-parent property. > >> > >> Given that allowing "msi-parent" for #msi-cells > 1 is merely a > >> backward-compatibility bodge full of hard-coded assumptions, why would > >> we want to knowingly introduce a similarly unpleasant equivalent for > >> IOMMUs? What's wrong with "iommu-map"? > > > > Hi Robin, > > > > With 'msi-parent' the property is fixed up to have msi-map. In this case there is > > no fixup required and simple 'iommu-parent' property can be used, with MC > bus > > itself providing the stream-id's (in the code execution via FW). > > > > We can also use the iommu-map property similar to PCI, which will require u- > boot > > fixup. But then it leads to little bit complications of u-boot - kernel > compatibility. > > What needs fixing up? With a stream-map-mask in place to ignore the > upper Stream ID bits, you just need: > > iommu-map = <0 &smmu 0 0x80>; > > to say that the lower bits of the ICID value map directly to the lower > bits of the Stream ID value - that's the same fixed property of the > hardware that you're wanting to assume in iommu-parent. Makes sense. I was going in a little bit wrong direction. Thanks for correcting. I will send v2 patchset with iommu-map property. Regards, Nipun > > > If you suggest we can re-use the iommu-map property. What is your opinion? > > I think it makes a lot more sense to directly use the property which > already exists, than to introduce a new one to merely assume one > hard-coded value of the existing one. Extending msi-parent to msi-map > was a case of "oops, it turns out we need more flexibility here"; for > the case of iommu-map I can't imagine any justification for saying > "oops, we need less flexibility here" (saving 9 whole bytes in the DT > really is irrelevant). > > Robin. ��.n��������+%������w��{.n����z�{��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
