From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Subject: Re: [PATCHv4 2/7] driver/core: Populate IOMMU'able devices in order Date: Wed, 13 Nov 2013 10:53:36 -0700 Message-ID: <5283BCA0.40300@wwwdotorg.org> References: <1384158718-4756-3-git-send-email-hdoyu@nvidia.com> <5282BAFC.8070405@wwwdotorg.org> <20131113143804.GA11928@mudshark.cambridge.arm.com> <20131113.180610.823304139654159769.hdoyu@nvidia.com> <20131113173142.GF11928@mudshark.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20131113173142.GF11928-MRww78TxoiP5vMa5CHWGZ34zcgK1vI+I0E9HWUfgJXw@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Will Deacon , Hiroshi Doyu Cc: Mark Rutland , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Lorenzo Pieralisi , Stephen Warren , "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , "thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" , "grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: devicetree@vger.kernel.org On 11/13/2013 10:31 AM, Will Deacon wrote: > On Wed, Nov 13, 2013 at 04:06:10PM +0000, Hiroshi Doyu wrote: >> Will Deacon wrote @ Wed, 13 Nov 2013 15:38:04 +0100: >> >>> On Tue, Nov 12, 2013 at 11:34:20PM +0000, Stephen Warren wrote: >>>> SMMU: >>>> smmu: smmu@xxxxxx { >>>> #smmu-cells = <1>; >>>> } >>>> >>>> Affected device: >>>> smmus = <&smmu 1>; >>>> (perhaps with smmu-names too) >>>> >>>> That would allow the DT to represent basically arbitrary HW configurations. >>>> >>>> The implementation of this patch would then be almost as trivial; you'd >>>> just need to walk the smmus property to find each phandle in turn, just >>>> like any other phandle+specifier property, and validate that the SMMU >>>> driver was already probe()d for each. >>> >>> There are a few problems with that: >>> >>> 1.) It assumes all devices sharing an SMMU have the same number of >>> "smmu cells" >> >> This can be solved with introducing the fixed size of bitmap. The size >> of bitmap can be fixed even per SoC. In tegra we used 64(2 cells) >> which I expect at most. > > That really doesn't sound like a good idea where you have bridges (like a > PCIe host controller) which could have a significant chunk of StreamID > space. You'd also need to pad everything out with some dummy IDs for parsing > purposes. Yuck! Can't you solve this by having the SMMU include a stream ID mapping table. In the case of stream IDs having a large "address" space, then just define the mapping table syntax to allow easy specification of ranges using start/length, start/end, or value/mask pairs. Similar to ranges or PCI's interrupt-map{,-mask}.