From mboxrd@z Thu Jan 1 00:00:00 1970 From: Will Deacon Subject: Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings Date: Wed, 25 Jun 2014 11:14:09 +0100 Message-ID: <20140625101409.GJ6153@arm.com> References: <1400877218-4113-1-git-send-email-thierry.reding@gmail.com> <130361958.xFghHXmZkz@wuerfel> <20140625095735.GI6153@arm.com> <6589024.32Qh7fFhXo@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <6589024.32Qh7fFhXo@wuerfel> 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: Arnd Bergmann Cc: Olav Haugan , Mark Rutland , "linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Pawel Moll , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Grant Grundler , Ian Campbell , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Marc Zyngier , Linux IOMMU , Rob Herring , Rob Herring , Kumar Gala , Stephen Warren , Thierry Reding , Cho KyongHo , Dave P Martin , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: devicetree@vger.kernel.org On Wed, Jun 25, 2014 at 11:12:13AM +0100, Arnd Bergmann wrote: > On Wednesday 25 June 2014 10:57:36 Will Deacon wrote: > > So far, I've been avoiding the hardcoding. However, you could potentially > > build a system with a small number of SMRs (compared to the number of > > StreamIDs) and allocate the StreamIDs in such a way that I think the dynamic > > configuration would be NP complete if we require an optimal SMR allocation. > > > > However: > > > > (1) I don't know of a system where this is the case > > (2) Not much work has been done on improving the dynamic allocator yet > > > > which is why I'm still favouring dynamic configuration in the driver. > > > > The other thing I forgot to mention earlier is that we need to support > > device hotplug in the future, so some level of dynamic configuration > > will always be required. > > Ok, got it. So we just hope that we can make dynamic configuration > work all the time, but if it all fails, then we come up with a > hardcoded configuration method. > > I guess this could be done similarly to how we handle clocks on > a lot of systems: generally these are dynamic, but you have the > option to provide hints in the clock controller node about how > you expect things to be configured. > > For the SMMU that could mean that (if we get into the situation you > describe), we add optional properties to the SMMU node itself > describing how we expect the SMRs to be used. That sounds good to me! Thanks for the discussion. Will