From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Subject: Re: [RFC] Describing arbitrary bus mastering relationships in DT Date: Fri, 02 May 2014 12:55:45 -0600 Message-ID: <5363EA31.3000509@wwwdotorg.org> References: <20140501173248.GD3732@e103592.cambridge.arm.com> <4369315.NLgjZW6qVF@wuerfel> <20140502132327.GA14612@ulmo> <6555552.UqkKQIAsih@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <6555552.UqkKQIAsih@wuerfel> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Arnd Bergmann , Thierry Reding Cc: Mark Rutland , devicetree@vger.kernel.org, Shaik Ameer Basha , Grant Grundler , Will Deacon , Jason Gunthorpe , Marc Zyngier , Dave Martin , linux-arm-kernel@lists.infradead.org, Hiroshi Doyu List-Id: devicetree@vger.kernel.org On 05/02/2014 09:19 AM, Arnd Bergmann wrote: > On Friday 02 May 2014 15:23:29 Thierry Reding wrote: ... >> To some degree this also depends on how we want to handle IOMMUs. If >> they should remain transparently handled via dma_map_ops, then it makes >> sense to set this up at device instantiation time. But how can we handle >> this in situations where one device needs to master on two IOMMUs at the >> same time? Or if the device needs physically contiguous memory for >> purposes other than device I/O. Using dma_map_ops we can't control which >> allocations get mapped via the IOMMU and which don't. > > I still hope we can handle this in common code by selecting the right > dma_map_ops when the devices are instantiated, at least for 99% of the > cases. I'm not convinced we really need to handle the 'multiple IOMMUs > on one device' case in a generic way. If there are no common use cases > for that, we can probably get away with having multiple device nodes > and an ugly driver for the exception, instead of making life complicated > for everybody. By "multiple device nodes", I assume you mean device tree nodes? I'm not sure I like the sound of that. I believe that DT should represent the structure of the HW in terms of HW modules or blocks. If there's a single cohesive HW module that happens to talk to multiple MMUs, or indeed has any kind of unusual case at all, I don't think that should force the DT representation to be broken up into multiple nodes. We should have a DT node for that HW module, and it should be up to the device driver to make the internal SW representation work correctly.