Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755267AbaFYJ2e (ORCPT ); Wed, 25 Jun 2014 05:28:34 -0400 Received: from mout.kundenserver.de ([212.227.126.131]:51450 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753576AbaFYJ2b (ORCPT ); Wed, 25 Jun 2014 05:28:31 -0400 From: Arnd Bergmann To: Will Deacon Cc: Olav Haugan , Rob Herring , Mark Rutland , "devicetree@vger.kernel.org" , "linux-samsung-soc@vger.kernel.org" , Pawel Moll , Ian Campbell , Grant Grundler , Joerg Roedel , Stephen Warren , "linux-kernel@vger.kernel.org" , Marc Zyngier , Linux IOMMU , Rob Herring , Thierry Reding , Kumar Gala , "linux-tegra@vger.kernel.org" , Cho KyongHo , Dave P Martin , "linux-arm-kernel@lists.infradead.org" , Hiroshi Doyu Subject: Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings Date: Wed, 25 Jun 2014 11:27:50 +0200 Message-ID: <4839521.56FtveYIl6@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.11.0-18-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20140625091702.GF6153@arm.com> References: <1400877218-4113-1-git-send-email-thierry.reding@gmail.com> <4855051.rhxSrNMNLg@wuerfel> <20140625091702.GF6153@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V02:K0:DCSTItur5/icev3eVxc/qb8swYJ+WshyPeWW/8mo+t7 jwA7qRo6UoRVS/0e97rBXHQ8PVz79NhsmsxP8lWQQbcfKVx6Wc 8jyryFSp+m4BHA86y7Sb1mMZW3gOLji+aT07rniEwGKBC1ZMsD 9b2arKkUExLxs6NS/YFms/xDnw3J2IQOgzD3Dilu+1lMOaAOLl o14RaCYNtWf1L/8EG6Obo1YPpETT/QSKRMovbxYOF644SXxzlj hAGKOYBGIeRQcU1L1+bbU3LtzeSi7p+Tk4/cLw5MAeQ1ANq7FK 9yEwa6GkiOaMGgzWXTW07WwbVZJiOSmUA60ITrUJ15UXPRIfPh EtkvGr+PM8e+Jf5toPGE= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 25 June 2014 10:17:02 Will Deacon wrote: > On Tue, Jun 24, 2014 at 07:20:56PM +0100, Arnd Bergmann wrote: > > On Tuesday 24 June 2014 19:11:50 Will Deacon wrote: > > > On Tue, Jun 24, 2014 at 06:57:44PM +0100, Olav Haugan wrote: > > > > We do describe the masked StreamID (SID) but we need to specify the mask > > > > that the SMMU should apply to the incoming SIDs, right? > > > > > > > > We have a bus master that emits 43 unique SIDs. However, we have only 40 > > > > SMMU_SMRn registers in the SMMU. So we need to mask out some of the > > > > incoming SID bits so that the 43 SIDs can match one of 40 entries in the > > > > SMR. > > > > > > Hmm, so you're talking about stream matching, right? That doesn't belong in > > > the device-tree. I appreciate that the current driver does a terrible job at > > > allocating the SMRs (it's bloody difficult!), but we should try to improve > > > the dynamic behaviour instead of moving configuration of the SMMU out into > > > device-tree, where it's inflexible at best. > > > > > > There have been patches previously posted by Andreas Herrmann helping here. > > > I'd be glad to see them revived. > > > > Note that there are areas where we have in the past decided that dynamic > > configuration is just too hard for the kernel to do and that we're better > > off putting the configuration into DT. Pinctrl and clocks are at least > > partially in that category. > > > > It's always best if you can get the kernel to do things in the ideal > > way where that is possible, but getting there may be just not worth it. > > > > I have no idea where it should be for SMMU, but it's something to consider: > > if you can take reasonable shortcuts by reading parts of the configuration > > from DT, you may just as well do that. > > I treat this in the same manner as the topology bindings we discussed > previously; we should do a best-effort to configure things dynamically and > solve corner-cases and quirks as special cases. I think the situation is a bit different here: It's less about the corner cases for the SMMU, but about the question whether it makes more sense to have the kernel figure out the settings, or have them come from DT all the time. As I said, I can't tell which approach is best here, but it sounds to me we should either do dynamic configuration and get it right, or hardcode the configuration it all the time if we can't. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/