From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark yao Subject: Re: [PATCH 2/8] drm/rockchip: Get rid of some unnecessary code Date: Tue, 20 Sep 2016 09:36:12 +0800 Message-ID: <57E0928C.8080103@rock-chips.com> References: <1473857701-9250-1-git-send-email-tfiga@chromium.org> <1473857701-9250-3-git-send-email-tfiga@chromium.org> <57DDF2EE.5060807@rock-chips.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Tomasz Figa Cc: "linux-kernel@vger.kernel.org" , dri-devel , "open list:ARM/Rockchip SoC..." , "linux-arm-kernel@lists.infradead.org" List-Id: linux-rockchip.vger.kernel.org T24gMjAxNuW5tDA55pyIMTjml6UgMTI6MDEsIFRvbWFzeiBGaWdhIHdyb3RlOgo+IEhpIE1hcmss Cj4KPiBPbiBTdW4sIFNlcCAxOCwgMjAxNiBhdCAxMDo1MCBBTSwgTWFyayB5YW8gPG1hcmsueWFv QHJvY2stY2hpcHMuY29tPiB3cm90ZToKPj4gT24gMjAxNuW5tDA55pyIMTTml6UgMjA6NTQsIFRv bWFzeiBGaWdhIHdyb3RlOgo+Pj4gQ3VycmVudCBjb2RlIGltcGxlbWVudHMgcHJlcGFyZV9mYiBh bmQgY2xlYW51cF9mYiBjYWxsYmFja3Mgb25seSB0bwo+Pj4gZ3JhYi9yZWxlYXNlIGZiIHJlZmVy ZW5jZXMsIHdoaWNoIGlzIGFscmVhZHkgZG9uZSBieSBhdG9taWMgZnJhbWV3b3JrCj4+PiB3aGVu IGNyZWF0aW5nL2Rlc3RyeW9pbmcgcGxhbmUgc3RhdGUuIExldCdzIHJlbW92ZSB0aGVzZQo+Pj4g dW51c2VkIGJpdHMuCj4+Pgo+Pj4gU2lnbmVkLW9mZi1ieTogVG9tYXN6IEZpZ2EgPHRmaWdhQGNo cm9taXVtLm9yZz4KPj4+IC0tLQo+Pj4gICAgZHJpdmVycy9ncHUvZHJtL3JvY2tjaGlwL3JvY2tj aGlwX2RybV92b3AuYyB8IDE4IC0tLS0tLS0tLS0tLS0tLS0tLQo+Pj4gICAgMSBmaWxlIGNoYW5n ZWQsIDE4IGRlbGV0aW9ucygtKQo+Pgo+PiBIaSBUb21hc3oKPj4KPj4gSSB0aGluayB3ZSBjYW4n dCBnZXQgcmlkIG9mIHRoZSBwcmVwYXJlX2ZiIGFuZCBjbGVhbnVwX2ZiCj4gSSB0aGluayBJIGhh dmUgdG8gZGlzYWdyZWUuIFBsZWFzZSBzZWUgYmVsb3cgZm9yIGRldGFpbGVkIGV4cGxhbmF0aW9u Lgo+Cj4+IHNlZSB0aGUgcmVhc29uOgo+PiBjb21taXQgNDRkMDIzN2EyNjM5NWFjOTQxNjBjZjIz ZjMyNzY5MDEzYjM2NTU5MAo+PiBBdXRob3I6IE1hcmsgWWFvIDxtYXJrLnlhb0Byb2NrLWNoaXBz LmNvbT4KPj4gRGF0ZTogICBGcmkgQXByIDI5IDExOjM3OjIwIDIwMTYgKzA4MDAKPj4KPj4gICAg ICBkcm0vcm9ja2NoaXA6IHZvcDogZml4IGlvbW11IGNyYXNoIHdpdGggYXN5bmMgYXRvbWljCj4+ Cj4+ICAgICAgQWZ0ZXIgYXN5bmMgYXRvbWljX2NvbW1pdCBjYWxsYmFjaywgZHJtX2F0b21pY19j bGVhbl9vbGRfZmIgd2lsbAo+PiAgICAgIGNsZWFuIGFsbCBvbGQgZmIsIGJ1dCBiZWNhdXNlIGFz eW5jLCB0aGUgb2xkIGZiIG1heSBiZSBhbHNvIG9uCj4+ICAgICAgdGhlIHZvcCBoYXJkd2FyZSwg ZG1hIHdpbGwgYWNjZXNzIHRoZSBvbGQgZmIgYnVmZmVyLCBjbGVhbiBvbGQKPj4gICAgICBmYiB3 aWxsIGNhdXNlIGlvbW11IHBhZ2UgZmF1bHQuCj4gSSB0aGluayB0aGUgYWJvdmUgaXMgbm90IHF1 aXRlIHJpZ2h0LiBBdG9taWMgcGxhbmUgc3RhdGUgaG9sZHMgYQo+IHJlZmVyZW5jZSB0byBpdHMg ZmIgYW5kIG9sZCBzdGF0ZSBpcyBub3Qgc3VwcG9zZWQgdG8gYmUgZGVzdHJveWVkCj4gdW50aWwg dGhlIGZsaXAgY29tcGxldGVzLgo+Cj4gSW5kZWVkIGN1cnJlbnQgcm9ja2NoaXBfYXRvbWljX2Nv bW1pdCBpbXBsZW1lbnRhdGlvbiBoYXMgZm9sbG93aW5nCj4gb3JkZXIgb2YgY2FsbHM6IHJvY2tj aGlwX2F0b21pY193YWl0X2Zvcl9jb21wbGV0ZSgpLAo+IGRybV9hdG9taWNfaGVscGVyX2NsZWFu dXBfcGxhbmVzKCksIGRybV9hdG9taWNfc3RhdGVfZnJlZSgpLiBUaGlzCj4gbWVhbnMgdGhhdCAu Y2xlYW51cF9mYigpIGlzIGNhbGxlZCBmcm9tCj4gZHJtX2F0b21pY19oZWxwZXJfY2xlYW51cF9w bGFuZXMoKSBqdXN0IGJlZm9yZSBkcm1fYXRvbWljX3N0YXRlX2ZyZWUoKQo+IHdpbGwgcmVsZWFz ZSByZWZlcmVuY2VzIGJ5IGRlc3Ryb3lpbmcgb2xkIHBsYW5lIHN0YXRlcy4gTm90ZSB0aGF0IGJv dGgKPiBhcmUgY2FsbGVkIGFscmVhZHkgYWZ0ZXIgcm9ja2NoaXBfYXRvbWljX3dhaXRfZm9yX2Nv bXBsZXRlKCksIHNvIGl0Cj4gc2hvdWxkIGJlIGFscmVhZHkgc2FmZSB0byBmcmVlIHRoZSBvbGQg ZmJzLgo+Cj4gU28gdGhlIGFib3ZlIGZpeCBkb2Vzbid0IHJlYWxseSBkbyBhbnl0aGluZywgcG9z c2libHkganVzdCBjb3ZlcnMgdGhlCj4gcmFjZSBjb25kaXRpb24gb2YgdGhlIG9yaWdpbmFsIHdh aXQgZm9yIHZibGFuayBmdW5jdGlvbiBieSBkZWxheWluZwo+IGRybV9hdG9taWNfc3RhdGVfZnJl ZSgpIGEgYml0Lgo+Cj4gTW9yZW92ZXIsIHRoZSB3aG9sZSBzZXJpZXMgaGFzIGJlZW4gdGhvcm91 Z2hseSB0ZXN0ZWQgaW4gQ2hyb21lIE9TIDQuNAo+IGtlcm5lbCwgaW5jbHVkaW5nIGFzeW5jIGNv bW1pdHMuIChUaGVyZSBpcyBzdGlsbCBhIHBvc3NpYmlsaXR5IHNvbWUKPiBuZXdlciB1cHN0cmVh bSBjaGFuZ2VzIHNsaWdodGx5IG1vZGlmaWVkIHRoZSBzZW1hbnRpY3MsIGJ1dCBJIGNvdWxkbid0 Cj4gZmluZCBzdWNoIGRpZmZlcmVuY2UuIEFjdHVhbGx5IG9uZSBvZiB0aGUgYWR2YW50YWdlcyBv ZiBhdG9taWMgaGVscGVycwo+IHdhcyB0byBhdm9pZCBtYW51YWxseSByZWZjb3VudGluZyB0aGUg ZmJzIGZyb20gdGhlIGRyaXZlci4pCj4KPiBCZXN0IHJlZ2FyZHMsCj4gVG9tYXN6Cj4KSGkgVG9t YXN6CgpZb3UgYXJlIHJpZ2h0LCBwbGFuZV9kdXBsaWNhdGVfc3RhdGUvcGxhbmVfZGVzdHJveV9z dGF0ZSBhbHJlYWR5IHByb3RlY3QgCnRoZSBvbGQgZmJzLgp3ZSBjYW4gZ2V0IHJpZCBvZiBwcmVw YXJlX2ZiIGFuZCBjbGVhbnVwX2ZiLgoKLS0gCu+8rWFyayBZYW8KCgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRy aS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5v cmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 From: mark.yao@rock-chips.com (Mark yao) Date: Tue, 20 Sep 2016 09:36:12 +0800 Subject: [PATCH 2/8] drm/rockchip: Get rid of some unnecessary code In-Reply-To: References: <1473857701-9250-1-git-send-email-tfiga@chromium.org> <1473857701-9250-3-git-send-email-tfiga@chromium.org> <57DDF2EE.5060807@rock-chips.com> Message-ID: <57E0928C.8080103@rock-chips.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 2016?09?18? 12:01, Tomasz Figa wrote: > Hi Mark, > > On Sun, Sep 18, 2016 at 10:50 AM, Mark yao wrote: >> On 2016?09?14? 20:54, Tomasz Figa wrote: >>> Current code implements prepare_fb and cleanup_fb callbacks only to >>> grab/release fb references, which is already done by atomic framework >>> when creating/destryoing plane state. Let's remove these >>> unused bits. >>> >>> Signed-off-by: Tomasz Figa >>> --- >>> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 18 ------------------ >>> 1 file changed, 18 deletions(-) >> >> Hi Tomasz >> >> I think we can't get rid of the prepare_fb and cleanup_fb > I think I have to disagree. Please see below for detailed explanation. > >> see the reason: >> commit 44d0237a26395ac94160cf23f32769013b365590 >> Author: Mark Yao >> Date: Fri Apr 29 11:37:20 2016 +0800 >> >> drm/rockchip: vop: fix iommu crash with async atomic >> >> After async atomic_commit callback, drm_atomic_clean_old_fb will >> clean all old fb, but because async, the old fb may be also on >> the vop hardware, dma will access the old fb buffer, clean old >> fb will cause iommu page fault. > I think the above is not quite right. Atomic plane state holds a > reference to its fb and old state is not supposed to be destroyed > until the flip completes. > > Indeed current rockchip_atomic_commit implementation has following > order of calls: rockchip_atomic_wait_for_complete(), > drm_atomic_helper_cleanup_planes(), drm_atomic_state_free(). This > means that .cleanup_fb() is called from > drm_atomic_helper_cleanup_planes() just before drm_atomic_state_free() > will release references by destroying old plane states. Note that both > are called already after rockchip_atomic_wait_for_complete(), so it > should be already safe to free the old fbs. > > So the above fix doesn't really do anything, possibly just covers the > race condition of the original wait for vblank function by delaying > drm_atomic_state_free() a bit. > > Moreover, the whole series has been thoroughly tested in Chrome OS 4.4 > kernel, including async commits. (There is still a possibility some > newer upstream changes slightly modified the semantics, but I couldn't > find such difference. Actually one of the advantages of atomic helpers > was to avoid manually refcounting the fbs from the driver.) > > Best regards, > Tomasz > Hi Tomasz You are right, plane_duplicate_state/plane_destroy_state already protect the old fbs. we can get rid of prepare_fb and cleanup_fb. -- ?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 S932124AbcITBgY (ORCPT ); Mon, 19 Sep 2016 21:36:24 -0400 Received: from regular1.263xmail.com ([211.150.99.132]:49020 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751119AbcITBgW (ORCPT ); Mon, 19 Sep 2016 21:36:22 -0400 X-263anti-spam: KSV:0;BIG:0;ABS:1;DNS:0;ATT:0;SPF:S; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-KSVirus-check: 0 X-ABS-CHECKED: 1 X-SKE-CHECKED: 1 X-ADDR-CHECKED4: 1 X-RL-SENDER: mark.yao@rock-chips.com X-FST-TO: djkurtz@chromium.org X-SENDER-IP: 103.29.142.67 X-LOGIN-NAME: mark.yao@rock-chips.com X-UNIQUE-TAG: <6ec4a283d4fadd7b32a4dbb97023165e> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Subject: Re: [PATCH 2/8] drm/rockchip: Get rid of some unnecessary code To: Tomasz Figa References: <1473857701-9250-1-git-send-email-tfiga@chromium.org> <1473857701-9250-3-git-send-email-tfiga@chromium.org> <57DDF2EE.5060807@rock-chips.com> Cc: dri-devel , "linux-arm-kernel@lists.infradead.org" , "open list:ARM/Rockchip SoC..." , "linux-kernel@vger.kernel.org" , Heiko Stuebner , David Airlie , Sean Paul , Daniel Kurtz From: Mark yao Message-ID: <57E0928C.8080103@rock-chips.com> Date: Tue, 20 Sep 2016 09:36:12 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: 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 On 2016年09月18日 12:01, Tomasz Figa wrote: > Hi Mark, > > On Sun, Sep 18, 2016 at 10:50 AM, Mark yao wrote: >> On 2016年09月14日 20:54, Tomasz Figa wrote: >>> Current code implements prepare_fb and cleanup_fb callbacks only to >>> grab/release fb references, which is already done by atomic framework >>> when creating/destryoing plane state. Let's remove these >>> unused bits. >>> >>> Signed-off-by: Tomasz Figa >>> --- >>> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 18 ------------------ >>> 1 file changed, 18 deletions(-) >> >> Hi Tomasz >> >> I think we can't get rid of the prepare_fb and cleanup_fb > I think I have to disagree. Please see below for detailed explanation. > >> see the reason: >> commit 44d0237a26395ac94160cf23f32769013b365590 >> Author: Mark Yao >> Date: Fri Apr 29 11:37:20 2016 +0800 >> >> drm/rockchip: vop: fix iommu crash with async atomic >> >> After async atomic_commit callback, drm_atomic_clean_old_fb will >> clean all old fb, but because async, the old fb may be also on >> the vop hardware, dma will access the old fb buffer, clean old >> fb will cause iommu page fault. > I think the above is not quite right. Atomic plane state holds a > reference to its fb and old state is not supposed to be destroyed > until the flip completes. > > Indeed current rockchip_atomic_commit implementation has following > order of calls: rockchip_atomic_wait_for_complete(), > drm_atomic_helper_cleanup_planes(), drm_atomic_state_free(). This > means that .cleanup_fb() is called from > drm_atomic_helper_cleanup_planes() just before drm_atomic_state_free() > will release references by destroying old plane states. Note that both > are called already after rockchip_atomic_wait_for_complete(), so it > should be already safe to free the old fbs. > > So the above fix doesn't really do anything, possibly just covers the > race condition of the original wait for vblank function by delaying > drm_atomic_state_free() a bit. > > Moreover, the whole series has been thoroughly tested in Chrome OS 4.4 > kernel, including async commits. (There is still a possibility some > newer upstream changes slightly modified the semantics, but I couldn't > find such difference. Actually one of the advantages of atomic helpers > was to avoid manually refcounting the fbs from the driver.) > > Best regards, > Tomasz > Hi Tomasz You are right, plane_duplicate_state/plane_destroy_state already protect the old fbs. we can get rid of prepare_fb and cleanup_fb. -- Ｍark Yao