From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Keeping Subject: Re: [PATCH 3/3] drm/rockchip: explain why we can't wait_for_vblanks Date: Thu, 14 Jan 2016 16:26:19 +0000 Message-ID: <20160114162619.233ab39c.john@metanate.com> References: <20160114142047.GD19130@phenom.ffwll.local> <107bbc36a316ed0ddc7b5a8bcd9b6db6cbc71d4f.1452782114.git.john@metanate.com> <20160114145705.GA24005@ulmo> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20160114145705.GA24005@ulmo> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Thierry Reding Cc: "linux-arm-kernel@lists.infradead.org" , "open list:ARM/Rockchip SoC..." , Linux Kernel Mailing List , dri-devel List-Id: linux-rockchip.vger.kernel.org T24gVGh1LCAxNCBKYW4gMjAxNiAxNTo1NzowNSArMDEwMCwgVGhpZXJyeSBSZWRpbmcgd3JvdGU6 Cgo+IE9uIFRodSwgSmFuIDE0LCAyMDE2IGF0IDAyOjM5OjQyUE0gKzAwMDAsIEpvaG4gS2VlcGlu ZyB3cm90ZToKPiA+IFNpZ25lZC1vZmYtYnk6IEpvaG4gS2VlcGluZyA8am9obkBtZXRhbmF0ZS5j b20+Cj4gPiAtLS0KPiA+ICBkcml2ZXJzL2dwdS9kcm0vcm9ja2NoaXAvcm9ja2NoaXBfZHJtX2Zi LmMgfCA2ICsrKysrKwo+ID4gIDEgZmlsZSBjaGFuZ2VkLCA2IGluc2VydGlvbnMoKykKPiA+IAo+ ID4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvZ3B1L2RybS9yb2NrY2hpcC9yb2NrY2hpcF9kcm1fZmIu YyBiL2RyaXZlcnMvZ3B1L2RybS9yb2NrY2hpcC9yb2NrY2hpcF9kcm1fZmIuYwo+ID4gaW5kZXgg Njc5ZDIzYS4uYjI2N2NlNCAxMDA2NDQKPiA+IC0tLSBhL2RyaXZlcnMvZ3B1L2RybS9yb2NrY2hp cC9yb2NrY2hpcF9kcm1fZmIuYwo+ID4gKysrIGIvZHJpdmVycy9ncHUvZHJtL3JvY2tjaGlwL3Jv Y2tjaGlwX2RybV9mYi5jCj4gPiBAQCAtMTc3LDYgKzE3NywxMiBAQCBzdGF0aWMgdm9pZCByb2Nr Y2hpcF9jcnRjX3dhaXRfZm9yX3VwZGF0ZShzdHJ1Y3QgZHJtX2NydGMgKmNydGMpCj4gPiAgCQlj cnRjX2Z1bmNzLT53YWl0X2Zvcl91cGRhdGUoY3J0Yyk7Cj4gPiAgfQo+ID4gIAo+ID4gKy8qCj4g PiArICogV2UgY2FuJ3QgdXNlIGRybV9hdG9taWNfaGVscGVyX3dhaXRfZm9yX3ZibGFua3MoKSBi ZWNhdXNlIHJrMzI4OCBhbmQgcmszMDY2Cj4gPiArICogaGF2ZSBoYXJkd2FyZSBjb3VudGVycyBm b3IgbmVpdGhlciB2YmxhbmtzIG5vciBzY2FubGluZXMuICBUaGlzIGZ1bmN0aW9uIGlzCj4gPiAr ICogZXF1aXZhbGVudCBidXQgdXNlcyByb2NrY2hpcF9jcnRjX3dhaXRfZm9yX3VwZGF0ZSgpIGlu c3RlYWQgb2Ygd2FpdGluZyBmb3IKPiA+ICsgKiB2YmxhbmtfY291bnQgdG8gY2hhbmdlLgo+ID4g KyAqLyAgCj4gCj4gVGhpcyBpcyBraW5kIG9mIG1pc2xlYWRpbmcuIEZyb20gcmVhZGluZyBlYXJs aWVyIHBhcnRzIG9mIHRoZSB0aHJlYWQgdGhlCj4gcmVhc29uIHdoeSBkcm1fYXRvbWljX2hlbHBl cl93YWl0X2Zvcl92YmxhbmtzKCkgd29uJ3Qgd29yayBpcyBiZWNhdXNlIGl0Cj4gaGFzIGEgcG90 ZW50aWFsIHJhY2UgY29uZGl0aW9uIHRoYXQgY2FuJ3QgYmUgZGV0ZWN0ZWQgdW5sZXNzIHlvdSBh bHNvCj4gaGF2ZSBhIHZibGFuayBjb3VudGVyLiBIb3dldmVyLCB0aGUgYWJvdmUgY29tbWVudCBt YWtlcyBpdCB3b3JrIGxpa2UKPiBkcm1fYXRvbWljX2hlbHBlcl93YWl0X2Zvcl92YmxhbmtzKCkg ZG9lc24ndCB3b3JrIGluIHRoZSBhYnNlbmNlIG9mIGEKPiB2YmxhbmsgY291bnRlciwgd2hpY2gg aXNuJ3QgcXVpdGUgdHJ1ZS4KCkhvdyBhYm91dCBzb21ldGhpbmcgbGlrZSB0aGlzICh1c2luZyB0 aGUgc2VxdWVuY2UgZnJvbSBNYXJrJ3MgbWVzc2FnZSk6CgovKgogKiBXZSBjYW4ndCB1c2UgZHJt X2F0b21pY19oZWxwZXJfd2FpdF9mb3JfdmJsYW5rcygpIGJlY2F1c2UgcmszMjg4IGFuZCByazMw NjYKICogaGF2ZSBoYXJkd2FyZSBjb3VudGVycyBmb3IgbmVpdGhlciB2YmxhbmtzIG5vciBzY2Fu bGluZXMsIHdoaWNoIHJlc3VsdHMgaW4KICogYSByYWNlIHdoZXJlOgogKgkJCQl8IDwtLSBIVyB2 c3luYyBpcnEgYW5kIHJlZyB0YWtlIGVmZmVjdAogKgkgICAgICAgcGxhbmVfY29tbWl0IC0tPiB8 CiAqCWdldF92YmxhbmsgYW5kIHdhaXQgLS0+IHwKICoJCQkJfCA8LS0gaGFuZGxlX3ZibGFuaywg dmJsYW5rLT5jb3VudCArIDEKICoJCSBjbGVhbnVwX2ZiIC0tPiB8CiAqCQlpb21tdSBjcmFzaCAt LT4gfAogKgkJCQl8IDwtLSBIVyB2c3luYyBpcnEgYW5kIHJlZyB0YWtlIGVmZmVjdAogKgogKiBU aGlzIGZ1bmN0aW9uIGlzIGVxdWl2YWxlbnQgYnV0IHVzZXMgcm9ja2NoaXBfY3J0Y193YWl0X2Zv cl91cGRhdGUoKSBpbnN0ZWFkCiAqIG9mIHdhaXRpbmcgZm9yIHZibGFua19jb3VudCB0byBjaGFu Z2UuCiAqLwpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpk cmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0 cDovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: john@metanate.com (John Keeping) Date: Thu, 14 Jan 2016 16:26:19 +0000 Subject: [PATCH 3/3] drm/rockchip: explain why we can't wait_for_vblanks In-Reply-To: <20160114145705.GA24005@ulmo> References: <20160114142047.GD19130@phenom.ffwll.local> <107bbc36a316ed0ddc7b5a8bcd9b6db6cbc71d4f.1452782114.git.john@metanate.com> <20160114145705.GA24005@ulmo> Message-ID: <20160114162619.233ab39c.john@metanate.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, 14 Jan 2016 15:57:05 +0100, Thierry Reding wrote: > On Thu, Jan 14, 2016 at 02:39:42PM +0000, John Keeping wrote: > > Signed-off-by: John Keeping > > --- > > drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c > > index 679d23a..b267ce4 100644 > > --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c > > @@ -177,6 +177,12 @@ static void rockchip_crtc_wait_for_update(struct drm_crtc *crtc) > > crtc_funcs->wait_for_update(crtc); > > } > > > > +/* > > + * We can't use drm_atomic_helper_wait_for_vblanks() because rk3288 and rk3066 > > + * have hardware counters for neither vblanks nor scanlines. This function is > > + * equivalent but uses rockchip_crtc_wait_for_update() instead of waiting for > > + * vblank_count to change. > > + */ > > This is kind of misleading. From reading earlier parts of the thread the > reason why drm_atomic_helper_wait_for_vblanks() won't work is because it > has a potential race condition that can't be detected unless you also > have a vblank counter. However, the above comment makes it work like > drm_atomic_helper_wait_for_vblanks() doesn't work in the absence of a > vblank counter, which isn't quite true. How about something like this (using the sequence from Mark's message): /* * We can't use drm_atomic_helper_wait_for_vblanks() because rk3288 and rk3066 * have hardware counters for neither vblanks nor scanlines, which results in * a race where: * | <-- HW vsync irq and reg take effect * plane_commit --> | * get_vblank and wait --> | * | <-- handle_vblank, vblank->count + 1 * cleanup_fb --> | * iommu crash --> | * | <-- HW vsync irq and reg take effect * * This function is equivalent but uses rockchip_crtc_wait_for_update() instead * of waiting for vblank_count to change. */ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755588AbcANQ0f (ORCPT ); Thu, 14 Jan 2016 11:26:35 -0500 Received: from dougal.metanate.com ([90.155.101.14]:53436 "EHLO metanate.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754680AbcANQ0c (ORCPT ); Thu, 14 Jan 2016 11:26:32 -0500 Date: Thu, 14 Jan 2016 16:26:19 +0000 From: John Keeping To: Thierry Reding Cc: Mark yao , Linux Kernel Mailing List , dri-devel , "open list:ARM/Rockchip SoC..." , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH 3/3] drm/rockchip: explain why we can't wait_for_vblanks Message-ID: <20160114162619.233ab39c.john@metanate.com> In-Reply-To: <20160114145705.GA24005@ulmo> References: <20160114142047.GD19130@phenom.ffwll.local> <107bbc36a316ed0ddc7b5a8bcd9b6db6cbc71d4f.1452782114.git.john@metanate.com> <20160114145705.GA24005@ulmo> Organization: Metanate Ltd X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; x86_64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 14 Jan 2016 15:57:05 +0100, Thierry Reding wrote: > On Thu, Jan 14, 2016 at 02:39:42PM +0000, John Keeping wrote: > > Signed-off-by: John Keeping > > --- > > drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c > > index 679d23a..b267ce4 100644 > > --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c > > @@ -177,6 +177,12 @@ static void rockchip_crtc_wait_for_update(struct drm_crtc *crtc) > > crtc_funcs->wait_for_update(crtc); > > } > > > > +/* > > + * We can't use drm_atomic_helper_wait_for_vblanks() because rk3288 and rk3066 > > + * have hardware counters for neither vblanks nor scanlines. This function is > > + * equivalent but uses rockchip_crtc_wait_for_update() instead of waiting for > > + * vblank_count to change. > > + */ > > This is kind of misleading. From reading earlier parts of the thread the > reason why drm_atomic_helper_wait_for_vblanks() won't work is because it > has a potential race condition that can't be detected unless you also > have a vblank counter. However, the above comment makes it work like > drm_atomic_helper_wait_for_vblanks() doesn't work in the absence of a > vblank counter, which isn't quite true. How about something like this (using the sequence from Mark's message): /* * We can't use drm_atomic_helper_wait_for_vblanks() because rk3288 and rk3066 * have hardware counters for neither vblanks nor scanlines, which results in * a race where: * | <-- HW vsync irq and reg take effect * plane_commit --> | * get_vblank and wait --> | * | <-- handle_vblank, vblank->count + 1 * cleanup_fb --> | * iommu crash --> | * | <-- HW vsync irq and reg take effect * * This function is equivalent but uses rockchip_crtc_wait_for_update() instead * of waiting for vblank_count to change. */