From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH v6 6/8] dma-mapping: detect and configure IOMMU in of_dma_configure Date: Wed, 17 Dec 2014 16:38:22 +0100 Message-ID: <1926348.VsVWqO766S@wuerfel> References: <1417453034-21379-1-git-send-email-will.deacon@arm.com> <549192D2.10008@arm.com> <20141217150158.GF870@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20141217150158.GF870-5wv7dgnIgG8@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 Cc: Joerg Roedel , David Woodhouse , "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , Thierry Reding , Laurent Pinchart , Varun Sethi , Robin Murphy , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: iommu@lists.linux-foundation.org On Wednesday 17 December 2014 15:01:58 Will Deacon wrote: > On Wed, Dec 17, 2014 at 02:27:30PM +0000, Robin Murphy wrote: > > On 17/12/14 12:09, Will Deacon wrote: > > > I think that's a slightly different case. The `grouping' in the DT, is on a > > > per-master basis where a master may have a set of StreamIDs, which can be > > > expressed in a more efficient (per-IOMMU) manner that cannot easily be > > > determined at runtime. > > > > I'm pretty convinced that automatic SMR allocation is solvable; I was > > planning to take a look at it soon, once I've finished warming up the > > dormant mathematician in me on implementing the OF group allocator. So > > far I'm lucky that stream indexing is sufficient for the bits of our > > hardware that actually work. > > Hmm, a few of us have looked at that and failed, so I'm all ears if you > think you can do it. The main issue is that you need *complete* knowledge > of the allocated StreamID space before you can safely create any SMR entry > unless you restrict yourself to consecutive, power-of-2 sized ID regions > for each master (which doesn't match reality, unfortunately). Right, scanning the entire device tree in the SMMU driver is definitely something to avoid. > > > The problem with all of this is how we distinguish the different ID formats > > > in the `iommus' device-tree property. For the ARM SMMU, we could have: > > > > > > (1) [easy case] A device has a list of StreamIDs > > > > > > (2) A device has a list of SMR mask/value pairs > > > > > > (3) A (bus) device has a range translation for a downstream bus (e.g. > > > a PCI host controller which needs to convert RequesterID to StreamID). > > > > > > From the SMMU driver's perspective, they will all look like of_xlate calls > > > unless we augment the generic IOMMU bindings with extra properties to > > > identify the format. It also makes it difficult to pick a sensible value for > > > #iommu-cells, as it depends on the format. > > > > I thoroughly dislike the idea, but one /could/ simply abuse the generic > > bindings well within the current framework, e.g. > > > > #1: iommus = <&smmu 0 streamID 0 0>, <&smmu 0 streamID 0 0>, ...; > > #2: iommus = <&smmu 1 mask value 0>; > > #3: iommus = <&smmu 2 start end offset>; > > > > and have a big complicated of_xlate that knows the secret. I don't think > > it would be unreasonable to constrain all masters on the same SMMU to > > use the same format either - that way you can lose the type indicator > > and the padding and the driver simply inspects #iommu-cells in > > of_iommu_init and sets up that instance to take the right path in its > > of_xlate calls later. Having a handful of single-stream-ID masters > > behind the same SMMU as a whacking great bus controller with a massive > > range seems like the kind of system-designer-insanity we should > > emphatically NOT be looking to accommodate if we can possibly help it. > > > > That said, for the time being I see definite use-cases for #1, which > > already works, and #3, for which I really think we should be looking to > > add a parallel generic "iommu-ranges" or "iommu-bus-range" binding for > > bus controllers, rather than trying to overload "iommus" beyond > > describing actual bus masters. > > Yeah, let's avoid overloading the current bindings too much. Adding the > ranges property makes perfect sense, I'm just trying to to straighten > out how the "iommus" property should differ depending on the presence of > SMR groups. Is a range something that is defined in the hardware spec, or is that just what you expect the PCI host controllers to use? Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Wed, 17 Dec 2014 16:38:22 +0100 Subject: [PATCH v6 6/8] dma-mapping: detect and configure IOMMU in of_dma_configure In-Reply-To: <20141217150158.GF870@arm.com> References: <1417453034-21379-1-git-send-email-will.deacon@arm.com> <549192D2.10008@arm.com> <20141217150158.GF870@arm.com> Message-ID: <1926348.VsVWqO766S@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wednesday 17 December 2014 15:01:58 Will Deacon wrote: > On Wed, Dec 17, 2014 at 02:27:30PM +0000, Robin Murphy wrote: > > On 17/12/14 12:09, Will Deacon wrote: > > > I think that's a slightly different case. The `grouping' in the DT, is on a > > > per-master basis where a master may have a set of StreamIDs, which can be > > > expressed in a more efficient (per-IOMMU) manner that cannot easily be > > > determined at runtime. > > > > I'm pretty convinced that automatic SMR allocation is solvable; I was > > planning to take a look at it soon, once I've finished warming up the > > dormant mathematician in me on implementing the OF group allocator. So > > far I'm lucky that stream indexing is sufficient for the bits of our > > hardware that actually work. > > Hmm, a few of us have looked at that and failed, so I'm all ears if you > think you can do it. The main issue is that you need *complete* knowledge > of the allocated StreamID space before you can safely create any SMR entry > unless you restrict yourself to consecutive, power-of-2 sized ID regions > for each master (which doesn't match reality, unfortunately). Right, scanning the entire device tree in the SMMU driver is definitely something to avoid. > > > The problem with all of this is how we distinguish the different ID formats > > > in the `iommus' device-tree property. For the ARM SMMU, we could have: > > > > > > (1) [easy case] A device has a list of StreamIDs > > > > > > (2) A device has a list of SMR mask/value pairs > > > > > > (3) A (bus) device has a range translation for a downstream bus (e.g. > > > a PCI host controller which needs to convert RequesterID to StreamID). > > > > > > From the SMMU driver's perspective, they will all look like of_xlate calls > > > unless we augment the generic IOMMU bindings with extra properties to > > > identify the format. It also makes it difficult to pick a sensible value for > > > #iommu-cells, as it depends on the format. > > > > I thoroughly dislike the idea, but one /could/ simply abuse the generic > > bindings well within the current framework, e.g. > > > > #1: iommus = <&smmu 0 streamID 0 0>, <&smmu 0 streamID 0 0>, ...; > > #2: iommus = <&smmu 1 mask value 0>; > > #3: iommus = <&smmu 2 start end offset>; > > > > and have a big complicated of_xlate that knows the secret. I don't think > > it would be unreasonable to constrain all masters on the same SMMU to > > use the same format either - that way you can lose the type indicator > > and the padding and the driver simply inspects #iommu-cells in > > of_iommu_init and sets up that instance to take the right path in its > > of_xlate calls later. Having a handful of single-stream-ID masters > > behind the same SMMU as a whacking great bus controller with a massive > > range seems like the kind of system-designer-insanity we should > > emphatically NOT be looking to accommodate if we can possibly help it. > > > > That said, for the time being I see definite use-cases for #1, which > > already works, and #3, for which I really think we should be looking to > > add a parallel generic "iommu-ranges" or "iommu-bus-range" binding for > > bus controllers, rather than trying to overload "iommus" beyond > > describing actual bus masters. > > Yeah, let's avoid overloading the current bindings too much. Adding the > ranges property makes perfect sense, I'm just trying to to straighten > out how the "iommus" property should differ depending on the presence of > SMR groups. Is a range something that is defined in the hardware spec, or is that just what you expect the PCI host controllers to use? Arnd