From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161236AbbBCVnc (ORCPT ); Tue, 3 Feb 2015 16:43:32 -0500 Received: from mout.kundenserver.de ([212.227.126.130]:55695 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161212AbbBCVna (ORCPT ); Tue, 3 Feb 2015 16:43:30 -0500 From: Arnd Bergmann To: linaro-mm-sig@lists.linaro.org Cc: Daniel Vetter , linaro-kernel@lists.linaro.org, Russell King - ARM Linux , Robin Murphy , LKML , DRI mailing list , "linux-mm@kvack.org" , Rob Clark , Tomasz Stanislawski , "linux-arm-kernel@lists.infradead.org" , "linux-media@vger.kernel.org" Subject: Re: [Linaro-mm-sig] [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms Date: Tue, 03 Feb 2015 22:42:26 +0100 Message-ID: <3327782.QV7DJfvifL@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20150203200435.GX14009@phenom.ffwll.local> References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org> <7233574.nKiRa7HnXU@wuerfel> <20150203200435.GX14009@phenom.ffwll.local> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:atS404H3tNyz5GwjRQ9Y98BIPKrDwZX75f31KacBaYlZetrNHSc qDW2oDxnO3PjYHCkZk/Lhx4vvlXn0tj1qQEZ4xsoRkCDrJsES0F/eJvXPdqJSWYX1U5ISfq uSe+tWhz2kK+JvXtzmKf3pi0dClPp9sFm3oBtAKZ0zSXwdU8+AAABnvBHR03rpIIe6VWODo xid/awVC61hPhjDVOYcvg== X-UI-Out-Filterresults: notjunk:1; Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 03 February 2015 21:04:35 Daniel Vetter wrote: > - On many soc people love to reuse iommus with the same or similar > interface all over the place. The solution thus far adopted on arm > platforms is to write an iommu driver for those and then implement the > dma-api on top of this iommu. > > But if we unconditionally do this then we rob the gpu driver's ability > to control its private iommu like it wants to, because a lot of the > functionality is lost behind the dma api abstraction. I believe in case of rockchips, msm, exynos and tegra, the same iommu is used directly by the DRM driver while it is used implicitly by the dma-mapping API. We have run into some problems with this in 3.19, but they should be solvable. > Again assuming I'm not confused can't we just solve this by pushing the > dma api abstraction down one layer for just the gpu, and let it use its > private iommmu directly? Steps for binding a buffer would be: > 1. dma_map_sg > 2. Noodle the dma_addr_t out of the sg table and feed those into a 2nd > level mapping set up through the iommu api for the gpu-private mmu. If you want to do that, you run into the problem of telling the driver core about it. We associate the device with an iommu in the device tree, describing there how it is wired up. The driver core creates a platform_device for this and checks if it an iommu mapping is required or wanted for the device, which is then set up. When the device driver wants to create its own iommu mapping, this conflicts with the one that is already there. We can't just skip the iommu setup for all devices because it may be needed sometimes, and I don't really want to see hacks where the driver core knows which devices are GPUs and skips the mapping for them, which would be a layering violation. > Again, this is what i915 and all the ttm based drivers already do, except > that we don't use the generic iommu interfaces but have our own (i915 has > its interface in i915_gem_gtt.c, ttm just calls them tt for translation > tables ...). Right, if you have a private iommu, there is no problem. The tricky part is using a single driver for the system-level translation and the gpu private mappings when there is only one type of iommu in the system. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mout.kundenserver.de ([212.227.126.130]:55695 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161212AbbBCVna (ORCPT ); Tue, 3 Feb 2015 16:43:30 -0500 From: Arnd Bergmann To: linaro-mm-sig@lists.linaro.org Cc: Daniel Vetter , linaro-kernel@lists.linaro.org, Russell King - ARM Linux , Robin Murphy , LKML , DRI mailing list , "linux-mm@kvack.org" , Rob Clark , Tomasz Stanislawski , "linux-arm-kernel@lists.infradead.org" , "linux-media@vger.kernel.org" Subject: Re: [Linaro-mm-sig] [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms Date: Tue, 03 Feb 2015 22:42:26 +0100 Message-ID: <3327782.QV7DJfvifL@wuerfel> In-Reply-To: <20150203200435.GX14009@phenom.ffwll.local> References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org> <7233574.nKiRa7HnXU@wuerfel> <20150203200435.GX14009@phenom.ffwll.local> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-media-owner@vger.kernel.org List-ID: On Tuesday 03 February 2015 21:04:35 Daniel Vetter wrote: > - On many soc people love to reuse iommus with the same or similar > interface all over the place. The solution thus far adopted on arm > platforms is to write an iommu driver for those and then implement the > dma-api on top of this iommu. > > But if we unconditionally do this then we rob the gpu driver's ability > to control its private iommu like it wants to, because a lot of the > functionality is lost behind the dma api abstraction. I believe in case of rockchips, msm, exynos and tegra, the same iommu is used directly by the DRM driver while it is used implicitly by the dma-mapping API. We have run into some problems with this in 3.19, but they should be solvable. > Again assuming I'm not confused can't we just solve this by pushing the > dma api abstraction down one layer for just the gpu, and let it use its > private iommmu directly? Steps for binding a buffer would be: > 1. dma_map_sg > 2. Noodle the dma_addr_t out of the sg table and feed those into a 2nd > level mapping set up through the iommu api for the gpu-private mmu. If you want to do that, you run into the problem of telling the driver core about it. We associate the device with an iommu in the device tree, describing there how it is wired up. The driver core creates a platform_device for this and checks if it an iommu mapping is required or wanted for the device, which is then set up. When the device driver wants to create its own iommu mapping, this conflicts with the one that is already there. We can't just skip the iommu setup for all devices because it may be needed sometimes, and I don't really want to see hacks where the driver core knows which devices are GPUs and skips the mapping for them, which would be a layering violation. > Again, this is what i915 and all the ttm based drivers already do, except > that we don't use the generic iommu interfaces but have our own (i915 has > its interface in i915_gem_gtt.c, ttm just calls them tt for translation > tables ...). Right, if you have a private iommu, there is no problem. The tricky part is using a single driver for the system-level translation and the gpu private mappings when there is only one type of iommu in the system. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by kanga.kvack.org (Postfix) with ESMTP id B72336B006C for ; Tue, 3 Feb 2015 16:43:34 -0500 (EST) Received: by mail-wg0-f48.google.com with SMTP id x12so46995473wgg.7 for ; Tue, 03 Feb 2015 13:43:34 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de. [212.227.126.130]) by mx.google.com with ESMTPS id eg8si203888wic.99.2015.02.03.13.43.31 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Feb 2015 13:43:32 -0800 (PST) From: Arnd Bergmann Subject: Re: [Linaro-mm-sig] [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms Date: Tue, 03 Feb 2015 22:42:26 +0100 Message-ID: <3327782.QV7DJfvifL@wuerfel> In-Reply-To: <20150203200435.GX14009@phenom.ffwll.local> References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org> <7233574.nKiRa7HnXU@wuerfel> <20150203200435.GX14009@phenom.ffwll.local> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: owner-linux-mm@kvack.org List-ID: To: linaro-mm-sig@lists.linaro.org Cc: Daniel Vetter , linaro-kernel@lists.linaro.org, Russell King - ARM Linux , Robin Murphy , LKML , DRI mailing list , "linux-mm@kvack.org" , Rob Clark , Tomasz Stanislawski , "linux-arm-kernel@lists.infradead.org" , "linux-media@vger.kernel.org" On Tuesday 03 February 2015 21:04:35 Daniel Vetter wrote: > - On many soc people love to reuse iommus with the same or similar > interface all over the place. The solution thus far adopted on arm > platforms is to write an iommu driver for those and then implement the > dma-api on top of this iommu. > > But if we unconditionally do this then we rob the gpu driver's ability > to control its private iommu like it wants to, because a lot of the > functionality is lost behind the dma api abstraction. I believe in case of rockchips, msm, exynos and tegra, the same iommu is used directly by the DRM driver while it is used implicitly by the dma-mapping API. We have run into some problems with this in 3.19, but they should be solvable. > Again assuming I'm not confused can't we just solve this by pushing the > dma api abstraction down one layer for just the gpu, and let it use its > private iommmu directly? Steps for binding a buffer would be: > 1. dma_map_sg > 2. Noodle the dma_addr_t out of the sg table and feed those into a 2nd > level mapping set up through the iommu api for the gpu-private mmu. If you want to do that, you run into the problem of telling the driver core about it. We associate the device with an iommu in the device tree, describing there how it is wired up. The driver core creates a platform_device for this and checks if it an iommu mapping is required or wanted for the device, which is then set up. When the device driver wants to create its own iommu mapping, this conflicts with the one that is already there. We can't just skip the iommu setup for all devices because it may be needed sometimes, and I don't really want to see hacks where the driver core knows which devices are GPUs and skips the mapping for them, which would be a layering violation. > Again, this is what i915 and all the ttm based drivers already do, except > that we don't use the generic iommu interfaces but have our own (i915 has > its interface in i915_gem_gtt.c, ttm just calls them tt for translation > tables ...). Right, if you have a private iommu, there is no problem. The tricky part is using a single driver for the system-level translation and the gpu private mappings when there is only one type of iommu in the system. Arnd -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Tue, 03 Feb 2015 22:42:26 +0100 Subject: [Linaro-mm-sig] [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms In-Reply-To: <20150203200435.GX14009@phenom.ffwll.local> References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org> <7233574.nKiRa7HnXU@wuerfel> <20150203200435.GX14009@phenom.ffwll.local> Message-ID: <3327782.QV7DJfvifL@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tuesday 03 February 2015 21:04:35 Daniel Vetter wrote: > - On many soc people love to reuse iommus with the same or similar > interface all over the place. The solution thus far adopted on arm > platforms is to write an iommu driver for those and then implement the > dma-api on top of this iommu. > > But if we unconditionally do this then we rob the gpu driver's ability > to control its private iommu like it wants to, because a lot of the > functionality is lost behind the dma api abstraction. I believe in case of rockchips, msm, exynos and tegra, the same iommu is used directly by the DRM driver while it is used implicitly by the dma-mapping API. We have run into some problems with this in 3.19, but they should be solvable. > Again assuming I'm not confused can't we just solve this by pushing the > dma api abstraction down one layer for just the gpu, and let it use its > private iommmu directly? Steps for binding a buffer would be: > 1. dma_map_sg > 2. Noodle the dma_addr_t out of the sg table and feed those into a 2nd > level mapping set up through the iommu api for the gpu-private mmu. If you want to do that, you run into the problem of telling the driver core about it. We associate the device with an iommu in the device tree, describing there how it is wired up. The driver core creates a platform_device for this and checks if it an iommu mapping is required or wanted for the device, which is then set up. When the device driver wants to create its own iommu mapping, this conflicts with the one that is already there. We can't just skip the iommu setup for all devices because it may be needed sometimes, and I don't really want to see hacks where the driver core knows which devices are GPUs and skips the mapping for them, which would be a layering violation. > Again, this is what i915 and all the ttm based drivers already do, except > that we don't use the generic iommu interfaces but have our own (i915 has > its interface in i915_gem_gtt.c, ttm just calls them tt for translation > tables ...). Right, if you have a private iommu, there is no problem. The tricky part is using a single driver for the system-level translation and the gpu private mappings when there is only one type of iommu in the system. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [Linaro-mm-sig] [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms Date: Tue, 03 Feb 2015 22:42:26 +0100 Message-ID: <3327782.QV7DJfvifL@wuerfel> References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org> <7233574.nKiRa7HnXU@wuerfel> <20150203200435.GX14009@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) by gabe.freedesktop.org (Postfix) with ESMTP id D3AC46E02F for ; Tue, 3 Feb 2015 13:43:26 -0800 (PST) In-Reply-To: <20150203200435.GX14009@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: linaro-mm-sig@lists.linaro.org Cc: linaro-kernel@lists.linaro.org, Russell King - ARM Linux , Tomasz Stanislawski , LKML , DRI mailing list , "linux-mm@kvack.org" , Robin Murphy , "linux-arm-kernel@lists.infradead.org" , "linux-media@vger.kernel.org" List-Id: dri-devel@lists.freedesktop.org T24gVHVlc2RheSAwMyBGZWJydWFyeSAyMDE1IDIxOjA0OjM1IERhbmllbCBWZXR0ZXIgd3JvdGU6 Cgo+IC0gT24gbWFueSBzb2MgcGVvcGxlIGxvdmUgdG8gcmV1c2UgaW9tbXVzIHdpdGggdGhlIHNh bWUgb3Igc2ltaWxhcgo+ICAgaW50ZXJmYWNlIGFsbCBvdmVyIHRoZSBwbGFjZS4gVGhlIHNvbHV0 aW9uIHRodXMgZmFyIGFkb3B0ZWQgb24gYXJtCj4gICBwbGF0Zm9ybXMgaXMgdG8gd3JpdGUgYW4g aW9tbXUgZHJpdmVyIGZvciB0aG9zZSBhbmQgdGhlbiBpbXBsZW1lbnQgdGhlCj4gICBkbWEtYXBp IG9uIHRvcCBvZiB0aGlzIGlvbW11Lgo+IAo+ICAgQnV0IGlmIHdlIHVuY29uZGl0aW9uYWxseSBk byB0aGlzIHRoZW4gd2Ugcm9iIHRoZSBncHUgZHJpdmVyJ3MgYWJpbGl0eQo+ICAgdG8gY29udHJv bCBpdHMgcHJpdmF0ZSBpb21tdSBsaWtlIGl0IHdhbnRzIHRvLCBiZWNhdXNlIGEgbG90IG9mIHRo ZQo+ICAgZnVuY3Rpb25hbGl0eSBpcyBsb3N0IGJlaGluZCB0aGUgZG1hIGFwaSBhYnN0cmFjdGlv bi4KCkkgYmVsaWV2ZSBpbiBjYXNlIG9mIHJvY2tjaGlwcywgbXNtLCBleHlub3MgYW5kIHRlZ3Jh LCB0aGUgc2FtZQppb21tdSBpcyB1c2VkIGRpcmVjdGx5IGJ5IHRoZSBEUk0gZHJpdmVyIHdoaWxl IGl0IGlzIHVzZWQgCmltcGxpY2l0bHkgYnkgdGhlIGRtYS1tYXBwaW5nIEFQSS4gV2UgaGF2ZSBy dW4gaW50byBzb21lIHByb2JsZW1zCndpdGggdGhpcyBpbiAzLjE5LCBidXQgdGhleSBzaG91bGQg YmUgc29sdmFibGUuCgo+IEFnYWluIGFzc3VtaW5nIEknbSBub3QgY29uZnVzZWQgY2FuJ3Qgd2Ug anVzdCBzb2x2ZSB0aGlzIGJ5IHB1c2hpbmcgdGhlCj4gZG1hIGFwaSBhYnN0cmFjdGlvbiBkb3du IG9uZSBsYXllciBmb3IganVzdCB0aGUgZ3B1LCBhbmQgbGV0IGl0IHVzZSBpdHMKPiBwcml2YXRl IGlvbW1tdSBkaXJlY3RseT8gU3RlcHMgZm9yIGJpbmRpbmcgYSBidWZmZXIgd291bGQgYmU6Cj4g MS4gZG1hX21hcF9zZwo+IDIuIE5vb2RsZSB0aGUgZG1hX2FkZHJfdCBvdXQgb2YgdGhlIHNnIHRh YmxlIGFuZCBmZWVkIHRob3NlIGludG8gYSAybmQKPiBsZXZlbCBtYXBwaW5nIHNldCB1cCB0aHJv dWdoIHRoZSBpb21tdSBhcGkgZm9yIHRoZSBncHUtcHJpdmF0ZSBtbXUuCgpJZiB5b3Ugd2FudCB0 byBkbyB0aGF0LCB5b3UgcnVuIGludG8gdGhlIHByb2JsZW0gb2YgdGVsbGluZyB0aGUgZHJpdmVy CmNvcmUgYWJvdXQgaXQuIFdlIGFzc29jaWF0ZSB0aGUgZGV2aWNlIHdpdGggYW4gaW9tbXUgaW4g dGhlIGRldmljZQp0cmVlLCBkZXNjcmliaW5nIHRoZXJlIGhvdyBpdCBpcyB3aXJlZCB1cC4KClRo ZSBkcml2ZXIgY29yZSBjcmVhdGVzIGEgcGxhdGZvcm1fZGV2aWNlIGZvciB0aGlzIGFuZCBjaGVj a3MgaWYgaXQKYW4gaW9tbXUgbWFwcGluZyBpcyByZXF1aXJlZCBvciB3YW50ZWQgZm9yIHRoZSBk ZXZpY2UsIHdoaWNoIGlzIHRoZW4Kc2V0IHVwLiBXaGVuIHRoZSBkZXZpY2UgZHJpdmVyIHdhbnRz IHRvIGNyZWF0ZSBpdHMgb3duIGlvbW11IG1hcHBpbmcsCnRoaXMgY29uZmxpY3RzIHdpdGggdGhl IG9uZSB0aGF0IGlzIGFscmVhZHkgdGhlcmUuIFdlIGNhbid0IGp1c3QKc2tpcCB0aGUgaW9tbXUg c2V0dXAgZm9yIGFsbCBkZXZpY2VzIGJlY2F1c2UgaXQgbWF5IGJlIG5lZWRlZCBzb21ldGltZXMs CmFuZCBJIGRvbid0IHJlYWxseSB3YW50IHRvIHNlZSBoYWNrcyB3aGVyZSB0aGUgZHJpdmVyIGNv cmUga25vd3Mgd2hpY2gKZGV2aWNlcyBhcmUgR1BVcyBhbmQgc2tpcHMgdGhlIG1hcHBpbmcgZm9y IHRoZW0sIHdoaWNoIHdvdWxkIGJlIGEKbGF5ZXJpbmcgdmlvbGF0aW9uLgoKPiBBZ2FpbiwgdGhp cyBpcyB3aGF0IGk5MTUgYW5kIGFsbCB0aGUgdHRtIGJhc2VkIGRyaXZlcnMgYWxyZWFkeSBkbywg ZXhjZXB0Cj4gdGhhdCB3ZSBkb24ndCB1c2UgdGhlIGdlbmVyaWMgaW9tbXUgaW50ZXJmYWNlcyBi dXQgaGF2ZSBvdXIgb3duIChpOTE1IGhhcwo+IGl0cyBpbnRlcmZhY2UgaW4gaTkxNV9nZW1fZ3R0 LmMsIHR0bSBqdXN0IGNhbGxzIHRoZW0gdHQgZm9yIHRyYW5zbGF0aW9uCj4gdGFibGVzIC4uLiku CgpSaWdodCwgaWYgeW91IGhhdmUgYSBwcml2YXRlIGlvbW11LCB0aGVyZSBpcyBubyBwcm9ibGVt LiBUaGUgdHJpY2t5IHBhcnQKaXMgdXNpbmcgYSBzaW5nbGUgZHJpdmVyIGZvciB0aGUgc3lzdGVt LWxldmVsIHRyYW5zbGF0aW9uIGFuZCB0aGUgZ3B1CnByaXZhdGUgbWFwcGluZ3Mgd2hlbiB0aGVy ZSBpcyBvbmx5IG9uZSB0eXBlIG9mIGlvbW11IGluIHRoZSBzeXN0ZW0uCgoJQXJuZApfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGlu ZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cDovL2xpc3RzLmZyZWVk ZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo=