From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756201AbaGVPnA (ORCPT ); Tue, 22 Jul 2014 11:43:00 -0400 Received: from mail-ig0-f178.google.com ([209.85.213.178]:64461 "EHLO mail-ig0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756061AbaGVPmt convert rfc822-to-8bit (ORCPT ); Tue, 22 Jul 2014 11:42:49 -0400 MIME-Version: 1.0 X-Originating-IP: [84.73.67.144] In-Reply-To: <53CE84AA.9030703@amd.com> References: <20140709093124.11354.3774.stgit@patser> <20140709122953.11354.46381.stgit@patser> <53CE2421.5040906@amd.com> <20140722114607.GL15237@phenom.ffwll.local> <20140722115737.GN15237@phenom.ffwll.local> <53CE56ED.4040109@vodafone.de> <20140722132652.GO15237@phenom.ffwll.local> <53CE6AFA.1060807@vodafone.de> <53CE84AA.9030703@amd.com> Date: Tue, 22 Jul 2014 17:42:48 +0200 Message-ID: Subject: Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences From: Daniel Vetter To: =?UTF-8?Q?Christian_K=C3=B6nig?= Cc: =?UTF-8?Q?Christian_K=C3=B6nig?= , Dave Airlie , Maarten Lankhorst , Thomas Hellstrom , nouveau , LKML , dri-devel , Ben Skeggs , "Deucher, Alexander" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 22, 2014 at 5:35 PM, Christian König wrote: > Drivers exporting fences need to provide a fence->signaled and a fence->wait > function, everything else like fence->enable_signaling or calling > fence_signaled() from the driver is optional. > > Drivers wanting to use exported fences don't call fence->signaled or > fence->wait in atomic or interrupt context, and not with holding any global > locking primitives (like mmap_sem etc...). Holding locking primitives local > to the driver is ok, as long as they don't conflict with anything possible > used by their own fence implementation. Well that's almost what we have right now with the exception that drivers are allowed (actually must for correctness when updating fences) the ww_mutexes for dma-bufs (or other buffer objects). Locking correctness is enforced with some extremely nasty lockdep annotations + additional debugging infrastructure enabled with CONFIG_DEBUG_WW_MUTEX_SLOWPATH. We really need to be able to hold dma-buf ww_mutexes while updating fences or waiting for them. And obviously for ->wait we need non-atomic context, not just non-interrupt. Agreed that any shared locks are out of the way (especially stuff like dev->struct_mutex or other non-strictly driver-private stuff, i915 is really bad here still). So from the core fence framework I think we already have exactly this, and we only need to adjust the radeon implementation a bit to make it less risky and invasive to the radeon driver logic. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences Date: Tue, 22 Jul 2014 17:42:48 +0200 Message-ID: References: <20140709093124.11354.3774.stgit@patser> <20140709122953.11354.46381.stgit@patser> <53CE2421.5040906@amd.com> <20140722114607.GL15237@phenom.ffwll.local> <20140722115737.GN15237@phenom.ffwll.local> <53CE56ED.4040109@vodafone.de> <20140722132652.GO15237@phenom.ffwll.local> <53CE6AFA.1060807@vodafone.de> <53CE84AA.9030703@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <53CE84AA.9030703@amd.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: =?UTF-8?Q?Christian_K=C3=B6nig?= Cc: Thomas Hellstrom , nouveau , LKML , dri-devel , "Deucher, Alexander" , Ben Skeggs List-Id: nouveau.vger.kernel.org T24gVHVlLCBKdWwgMjIsIDIwMTQgYXQgNTozNSBQTSwgQ2hyaXN0aWFuIEvDtm5pZwo8Y2hyaXN0 aWFuLmtvZW5pZ0BhbWQuY29tPiB3cm90ZToKPiBEcml2ZXJzIGV4cG9ydGluZyBmZW5jZXMgbmVl ZCB0byBwcm92aWRlIGEgZmVuY2UtPnNpZ25hbGVkIGFuZCBhIGZlbmNlLT53YWl0Cj4gZnVuY3Rp b24sIGV2ZXJ5dGhpbmcgZWxzZSBsaWtlIGZlbmNlLT5lbmFibGVfc2lnbmFsaW5nIG9yIGNhbGxp bmcKPiBmZW5jZV9zaWduYWxlZCgpIGZyb20gdGhlIGRyaXZlciBpcyBvcHRpb25hbC4KPgo+IERy aXZlcnMgd2FudGluZyB0byB1c2UgZXhwb3J0ZWQgZmVuY2VzIGRvbid0IGNhbGwgZmVuY2UtPnNp Z25hbGVkIG9yCj4gZmVuY2UtPndhaXQgaW4gYXRvbWljIG9yIGludGVycnVwdCBjb250ZXh0LCBh bmQgbm90IHdpdGggaG9sZGluZyBhbnkgZ2xvYmFsCj4gbG9ja2luZyBwcmltaXRpdmVzIChsaWtl IG1tYXBfc2VtIGV0Yy4uLikuIEhvbGRpbmcgbG9ja2luZyBwcmltaXRpdmVzIGxvY2FsCj4gdG8g dGhlIGRyaXZlciBpcyBvaywgYXMgbG9uZyBhcyB0aGV5IGRvbid0IGNvbmZsaWN0IHdpdGggYW55 dGhpbmcgcG9zc2libGUKPiB1c2VkIGJ5IHRoZWlyIG93biBmZW5jZSBpbXBsZW1lbnRhdGlvbi4K CldlbGwgdGhhdCdzIGFsbW9zdCB3aGF0IHdlIGhhdmUgcmlnaHQgbm93IHdpdGggdGhlIGV4Y2Vw dGlvbiB0aGF0CmRyaXZlcnMgYXJlIGFsbG93ZWQgKGFjdHVhbGx5IG11c3QgZm9yIGNvcnJlY3Ru ZXNzIHdoZW4gdXBkYXRpbmcKZmVuY2VzKSB0aGUgd3dfbXV0ZXhlcyBmb3IgZG1hLWJ1ZnMgKG9y IG90aGVyIGJ1ZmZlciBvYmplY3RzKS4gTG9ja2luZwpjb3JyZWN0bmVzcyBpcyBlbmZvcmNlZCB3 aXRoIHNvbWUgZXh0cmVtZWx5IG5hc3R5IGxvY2tkZXAgYW5ub3RhdGlvbnMKKyBhZGRpdGlvbmFs IGRlYnVnZ2luZyBpbmZyYXN0cnVjdHVyZSBlbmFibGVkIHdpdGgKQ09ORklHX0RFQlVHX1dXX01V VEVYX1NMT1dQQVRILiBXZSByZWFsbHkgbmVlZCB0byBiZSBhYmxlIHRvIGhvbGQKZG1hLWJ1ZiB3 d19tdXRleGVzIHdoaWxlIHVwZGF0aW5nIGZlbmNlcyBvciB3YWl0aW5nIGZvciB0aGVtLiBBbmQK b2J2aW91c2x5IGZvciAtPndhaXQgd2UgbmVlZCBub24tYXRvbWljIGNvbnRleHQsIG5vdCBqdXN0 Cm5vbi1pbnRlcnJ1cHQuCgpBZ3JlZWQgdGhhdCBhbnkgc2hhcmVkIGxvY2tzIGFyZSBvdXQgb2Yg dGhlIHdheSAoZXNwZWNpYWxseSBzdHVmZiBsaWtlCmRldi0+c3RydWN0X211dGV4IG9yIG90aGVy IG5vbi1zdHJpY3RseSBkcml2ZXItcHJpdmF0ZSBzdHVmZiwgaTkxNSBpcwpyZWFsbHkgYmFkIGhl cmUgc3RpbGwpLgoKU28gZnJvbSB0aGUgY29yZSBmZW5jZSBmcmFtZXdvcmsgSSB0aGluayB3ZSBh bHJlYWR5IGhhdmUgZXhhY3RseSB0aGlzLAphbmQgd2Ugb25seSBuZWVkIHRvIGFkanVzdCB0aGUg cmFkZW9uIGltcGxlbWVudGF0aW9uIGEgYml0IHRvIG1ha2UgaXQKbGVzcyByaXNreSBhbmQgaW52 YXNpdmUgdG8gdGhlIHJhZGVvbiBkcml2ZXIgbG9naWMuCi1EYW5pZWwKLS0gCkRhbmllbCBWZXR0 ZXIKU29mdHdhcmUgRW5naW5lZXIsIEludGVsIENvcnBvcmF0aW9uCis0MSAoMCkgNzkgMzY1IDU3 IDQ4IC0gaHR0cDovL2Jsb2cuZmZ3bGwuY2gKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KZHJpLWRldmVsIG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMu ZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0 aW5mby9kcmktZGV2ZWwK