From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark yao Subject: Re: [PATCH 1/6] drm/rockchip: import dma_buf to gem Date: Fri, 19 Jun 2015 10:50:54 +0800 Message-ID: <5583838E.7080001@rock-chips.com> References: <1434613770-6608-1-git-send-email-mark.yao@rock-chips.com> <1434613770-6608-2-git-send-email-mark.yao@rock-chips.com> <20150618105715.GJ7557@n2100.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20150618105715.GJ7557@n2100.arm.linux.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Russell King - ARM Linux Cc: zwl@rock-chips.com, linux-kernel@vger.kernel.org, tfiga@chromium.org, linux-rockchip@lists.infradead.org, dri-devel@lists.freedesktop.org, xw@rock-chips.com, dkm@rock-chips.com, sandy.huang@rock-chips.com, linux-arm-kernel@lists.infradead.org List-Id: linux-rockchip.vger.kernel.org VGhhbmtzIFJ1c3NlbGwKT24gMjAxNeW5tDA25pyIMTjml6UgMTg6NTcsIFJ1c3NlbGwgS2luZyAt IEFSTSBMaW51eCB3cm90ZToKPiBUaGlzIGlzIHdyb25nLgo+Cj4gRmlyc3QsIGlmIHlvdSBjYW4g b25seSBjb3BlIHdpdGggYSBzaW5nbGUgc2NhdHRlcmxpc3QgZW50cnksIHlvdSBuZWVkIHRvCj4g ZW5mb3JjZSB0aGF0LiAgWW91IGNhbiBkbyB0aGF0IGluIHlvdXIgZ2VtX3ByaW1lX2ltcG9ydF9z Z190YWJsZSgpIG1ldGhvZAo+IGJ5IGNoZWNraW5nIHNndC0+bmVudHMuCkknbSBjb25mdXNlIHRo YXQgaG93IHRvIGdldCBjb2hlcmVudCBpb3ZhIGFkZHJlc3MgZnJvbSBub2NvaGVyZW50IApzY2F0 dGVybGlzdCB3aXRoIGlvbW11LgpJIHNhdyB0aGUgYXJtX2lvbW11X21hcF9zZywgaXQgc2F5cyB0 aGF0OgogICAgICAgICBUaGUgc2NhdHRlciBnYXRoZXIgbGlzdCBlbGVtZW50cyBhcmUgbWVyZ2Vk IHRvZ2V0aGVyIChpZiAKcG9zc2libGUpIGFuZAogICAgICAgICAgdGFnZ2VkIHdpdGggdGhlIGFw cHJvcHJpYXRlIGRtYSBhZGRyZXNzIGFuZCBsZW5ndGguCgpJIGd1ZXNzIHRoZSBtYXBfc2cgbWF5 YmUgbWVyZ2Ugc2NhdHRlcmxpc3QgaW50byBjb2hlcmVudCBpb3ZhIGFkZHJlc3MsIApidXQgSSBk b24ndCBrbm93IGhvdyB0bwpjaGVjayB0aGUgImlmIHBvc3NpYmxlIiwgYW5kIHRoZSBzZ3QtPm5l bnRzIG5vdCBiZSAxIHdoZW4gYWxyZWFkeSBtYXAgdG8gCmNvaGVyZW50IGlvdmEgYWRkcmVzcy4K CmNoZWNraW5nIHNndC1uZW50cyA9IDEgY2FuIHN1cmUgdGhhdCBpb3ZhIGlzIGNvaGVyZW50LCBi dXQgd2hlbiBjb2hlcmVudCAKaW92YSBhZGRyZXNzIGZyb20Kbm9jb2hlcmVudCBzY2F0dGVybGlz dCwgSSB0aGluayBzZ3QtPm5lbnRzIG1heWJlIGdyZWF0ZXIgdGhhbiAxLCBpcyAKdGhlcmUgYSBt ZXRob2QgY2FuIGRlYWwgaXQ/CgpBbGwgYWJvdmUgaXMgbXkgZ3Vlc3MsIG1heWJlIHdyb25nLCBJ IG9ubHkgdGVzdGVkIGl0IHdpdGggQ01BIGJ1ZmZlciBpbXBvcnQuCgo+IFNlY29uZGx5LCB5b3Un cmUgbWFwcGluZyBhbiBhbHJlYWR5IG1hcHBlZCBzY2F0dGVybGlzdCAtIHNjYXR0ZXJsaXN0cwo+ IGFyZSBtYXBwZWQgYnkgdGhlIGV4cG9ydGVyIGluc2lkZSBkbWFfYnVmX21hcF9hdHRhY2htZW50 KCkgZm9yIHlvdXIKPiBkZXZpY2UuCgpSaWdodCwgZm91bmQgdGhlIGRtYV9tYXBfc2cgb24gZG1h X2J1Zl9tYXBfYXR0YWNobWVudCgpLgoKPgo+IFRoaXJkbHksIEkgaGF0ZSBkcm1fZ2VtX3ByaW1l X2ltcG9ydCgpIGJlaW5nIHVzZWQgb24gQVJNLi4uIGl0IGZvcmNlcwo+IGRyaXZlcnMgdG8gZG8g c29tZXRoaW5nIHZlcnkgYnVnZ3k6IHRoZSBETUEgYnVmZmVyIGlzIG1hcHBlZCBmb3IgRE1BCj4g d2hlbiB0aGUgYnVmZmVyIGlzIGltcG9ydGVkLiAgSWYgdGhlIGJ1ZmZlciBpcyBhIHdyaXRlLWNv bWJpbmUgb3IgY2FjaGVkCj4gYnVmZmVyLCB3cml0ZXMgdG8gdGhlIGJ1ZmZlciBhZnRlciB0aGUg aW1wb3J0IHdpbGwgbm90IGJlY29tZSB2aXNpYmxlIHRvCj4gdGhlIGRpc3BsYXkgaGFyZHdhcmUg dW50aWwgc29tZXRpbWUgbGF0ZXIgKHdoZW4gdGhleSdyZSBldmljdGVkIGZyb20gdGhlCj4gY2Fj aGVzIGFuZC9vciBwdXNoZWQgb3V0IG9mIHRoZSBidXMgc3RydWN0dXJlLikgIFRoZSBETUEgbWFw cGluZyBzaG91bGQKPiBiZSBwZXJmb3JtZWQgYXMgY2xvc2UgdG8gdGhlIHN0YXJ0IG9mIERNQSBh cyBwb3NzaWJsZS4gIEhvd2V2ZXIsIHRoaXMgaXMKPiBhIGxvbmctc3RhbmRpbmcgaXNzdWUgSSBo YXZlIHdpdGggZG1hX2J1ZiBpdHNlbGYgYW5kIGlzIG5vdCBzb21ldGhpbmcgeW91Cj4gc2hvdWxk IGJlIHRvbyBjb25jZXJuZWQgd2l0aCBpbiB5b3VyIHBhdGNoLiAgSnVzdCBiZWFyIGl0IGluIG1p bmQgaWYgeW91Cj4gc3RhcnQgdG8gc2VlIGNvcnJ1cHRpb24gb2YgaW1wb3J0ZWQgYnVmZmVycyAt IHRoZSBhbnN3ZXIgaXMgbm90IG1vcmUKPiBkbWFfbWFwX3NnKCkgY2FsbHMsIGJ1dCB0byBnZXQg ZG1hX2J1ZiBmaXhlZC4KWWVhaCwgR290IGl0LgoKLS0gCu+8rWFyayBZYW8KCgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBs aXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cDovL2xpc3RzLmZyZWVkZXNr dG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: mark.yao@rock-chips.com (Mark yao) Date: Fri, 19 Jun 2015 10:50:54 +0800 Subject: [PATCH 1/6] drm/rockchip: import dma_buf to gem In-Reply-To: <20150618105715.GJ7557@n2100.arm.linux.org.uk> References: <1434613770-6608-1-git-send-email-mark.yao@rock-chips.com> <1434613770-6608-2-git-send-email-mark.yao@rock-chips.com> <20150618105715.GJ7557@n2100.arm.linux.org.uk> Message-ID: <5583838E.7080001@rock-chips.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Thanks Russell On 2015?06?18? 18:57, Russell King - ARM Linux wrote: > This is wrong. > > First, if you can only cope with a single scatterlist entry, you need to > enforce that. You can do that in your gem_prime_import_sg_table() method > by checking sgt->nents. I'm confuse that how to get coherent iova address from nocoherent scatterlist with iommu. I saw the arm_iommu_map_sg, it says that: The scatter gather list elements are merged together (if possible) and tagged with the appropriate dma address and length. I guess the map_sg maybe merge scatterlist into coherent iova address, but I don't know how to check the "if possible", and the sgt->nents not be 1 when already map to coherent iova address. checking sgt-nents = 1 can sure that iova is coherent, but when coherent iova address from nocoherent scatterlist, I think sgt->nents maybe greater than 1, is there a method can deal it? All above is my guess, maybe wrong, I only tested it with CMA buffer import. > Secondly, you're mapping an already mapped scatterlist - scatterlists > are mapped by the exporter inside dma_buf_map_attachment() for your > device. Right, found the dma_map_sg on dma_buf_map_attachment(). > > Thirdly, I hate drm_gem_prime_import() being used on ARM... it forces > drivers to do something very buggy: the DMA buffer is mapped for DMA > when the buffer is imported. If the buffer is a write-combine or cached > buffer, writes to the buffer after the import will not become visible to > the display hardware until sometime later (when they're evicted from the > caches and/or pushed out of the bus structure.) The DMA mapping should > be performed as close to the start of DMA as possible. However, this is > a long-standing issue I have with dma_buf itself and is not something you > should be too concerned with in your patch. Just bear it in mind if you > start to see corruption of imported buffers - the answer is not more > dma_map_sg() calls, but to get dma_buf fixed. Yeah, Got it. -- ?ark Yao From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753341AbbFSCvX (ORCPT ); Thu, 18 Jun 2015 22:51:23 -0400 Received: from regular1.263xmail.com ([211.150.99.135]:34121 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752933AbbFSCvO (ORCPT ); Thu, 18 Jun 2015 22:51:14 -0400 X-263anti-spam: KSV:0; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-KSVirus-check: 0 X-ABS-CHECKED: 4 X-ADDR-CHECKED: 0 X-RL-SENDER: mark.yao@rock-chips.com X-FST-TO: linux@arm.linux.org.uk X-SENDER-IP: 58.22.7.114 X-LOGIN-NAME: mark.yao@rock-chips.com X-UNIQUE-TAG: X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Message-ID: <5583838E.7080001@rock-chips.com> Date: Fri, 19 Jun 2015 10:50:54 +0800 From: Mark yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Russell King - ARM Linux CC: dri-devel@lists.freedesktop.org, zwl@rock-chips.com, Daniel Vetter , David Airlie , linux-kernel@vger.kernel.org, Daniel Kurtz , tfiga@chromium.org, linux-rockchip@lists.infradead.org, Rob Clark , Philipp Zabel , xw@rock-chips.com, dkm@rock-chips.com, sandy.huang@rock-chips.com, linux-arm-kernel@lists.infradead.org, Heiko Stuebner Subject: Re: [PATCH 1/6] drm/rockchip: import dma_buf to gem References: <1434613770-6608-1-git-send-email-mark.yao@rock-chips.com> <1434613770-6608-2-git-send-email-mark.yao@rock-chips.com> <20150618105715.GJ7557@n2100.arm.linux.org.uk> In-Reply-To: <20150618105715.GJ7557@n2100.arm.linux.org.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thanks Russell On 2015年06月18日 18:57, Russell King - ARM Linux wrote: > This is wrong. > > First, if you can only cope with a single scatterlist entry, you need to > enforce that. You can do that in your gem_prime_import_sg_table() method > by checking sgt->nents. I'm confuse that how to get coherent iova address from nocoherent scatterlist with iommu. I saw the arm_iommu_map_sg, it says that: The scatter gather list elements are merged together (if possible) and tagged with the appropriate dma address and length. I guess the map_sg maybe merge scatterlist into coherent iova address, but I don't know how to check the "if possible", and the sgt->nents not be 1 when already map to coherent iova address. checking sgt-nents = 1 can sure that iova is coherent, but when coherent iova address from nocoherent scatterlist, I think sgt->nents maybe greater than 1, is there a method can deal it? All above is my guess, maybe wrong, I only tested it with CMA buffer import. > Secondly, you're mapping an already mapped scatterlist - scatterlists > are mapped by the exporter inside dma_buf_map_attachment() for your > device. Right, found the dma_map_sg on dma_buf_map_attachment(). > > Thirdly, I hate drm_gem_prime_import() being used on ARM... it forces > drivers to do something very buggy: the DMA buffer is mapped for DMA > when the buffer is imported. If the buffer is a write-combine or cached > buffer, writes to the buffer after the import will not become visible to > the display hardware until sometime later (when they're evicted from the > caches and/or pushed out of the bus structure.) The DMA mapping should > be performed as close to the start of DMA as possible. However, this is > a long-standing issue I have with dma_buf itself and is not something you > should be too concerned with in your patch. Just bear it in mind if you > start to see corruption of imported buffers - the answer is not more > dma_map_sg() calls, but to get dma_buf fixed. Yeah, Got it. -- Ｍark Yao