From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5pZw==?= Subject: Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences Date: Wed, 23 Jul 2014 10:31:54 +0200 Message-ID: <53CF72FA.9070806@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> <53CE8A57.2000803@vodafone.de> <53CF58FB.8070609@canonical.com> <53CF5B9F.1050800@amd.com> <53CF5EFE.6070307@canonical.com> <53CF63C2.7070407@vodafone.de> <53CF6622.6060803@amd.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: Daniel Vetter Cc: Thomas Hellstrom , nouveau , LKML , dri-devel , "Deucher, Alexander" , Ben Skeggs List-Id: nouveau.vger.kernel.org QW0gMjMuMDcuMjAxNCAxMDowMSwgc2NocmllYiBEYW5pZWwgVmV0dGVyOgo+IE9uIFdlZCwgSnVs IDIzLCAyMDE0IGF0IDk6MzcgQU0sIENocmlzdGlhbiBLw7ZuaWcKPiA8Y2hyaXN0aWFuLmtvZW5p Z0BhbWQuY29tPiB3cm90ZToKPj4gQW0gMjMuMDcuMjAxNCAwOTozMSwgc2NocmllYiBEYW5pZWwg VmV0dGVyOgo+Pj4gT24gV2VkLCBKdWwgMjMsIDIwMTQgYXQgOToyNiBBTSwgQ2hyaXN0aWFuIEvD tm5pZwo+Pj4gPGRlYXRoc2ltcGxlQHZvZGFmb25lLmRlPiB3cm90ZToKPj4+PiBJdCdzIG5vdCBh IGxvY2tpbmcgcHJvYmxlbSBJJ20gdGFsa2luZyBhYm91dCBoZXJlLiBSYWRlb25zIGxvY2t1cAo+ Pj4+IGhhbmRsaW5nCj4+Pj4ga2lja3MgaW4gd2hlbiBhbnl0aGluZyBjYWxscyBpbnRvIHRoZSBk cml2ZXIgZnJvbSB0aGUgb3V0c2lkZSwgaWYgeW91Cj4+Pj4gaGF2ZSBhCj4+Pj4gZmVuY2Ugd2Fp dCBmdW5jdGlvbiB0aGF0J3MgY2FsbGVkIGZyb20gdGhlIG91dHNpZGUgYnV0IGRvZXNuJ3QgaGFu ZGxlCj4+Pj4gbG9ja3VwcyB5b3UgZXNzZW50aWFsbHkgcmVseSBvbiBzb21lYm9keSBlbHNlIGNh bGxpbmcgYW5vdGhlciByYWRlb24KPj4+PiBmdW5jdGlvbiBmb3IgdGhlIGxvY2t1cCB0byBiZSBy ZXNvbHZlZC4KPj4+IFNvIHlvdSBkb24ndCBoYXZlIGEgdGltZXIgaW4gcmFkZW9uIHRoYXQgcGVy aW9kaWNhbGx5IGNoZWNrcyB3aGV0aGVyCj4+PiBwcm9ncmVzcyBpcyBzdGlsbCBiZWluZyBtYWRl PyBUaGF0J3MgdGhlIGFwcHJvYWNoIHdlJ3JlIHVzaW5nIGluIGk5MTUsCj4+PiB0b2dldGhlciB3 aXRoIHNvbWUgdHJpY2tzIHRvIGtpY2sgYW55IHN0dWNrIHdhaXRlcnMgc28gdGhhdCB3ZSBjYW4K Pj4+IHJlbGlhYmx5IHN0ZXAgaW4gYW5kIGdyYWIgbG9ja3MgZm9yIHRoZSByZXNldC4KPj4KPj4g V2UgdHJpZWQgdGhpcyBhcHByb2FjaCwgYnV0IGl0IGRpZG4ndCB3b3JrZWQgYXQgYWxsLgo+Pgo+ PiBJIGFscmVhZHkgY29uc2lkZXJlZCB0cnlpbmcgaXQgYWdhaW4gYmVjYXVzZSBvZiB0aGUgdXBj b21pbmcgZmVuY2UKPj4gaW1wbGVtZW50YXRpb24sIGJ1dCByZWNvbnNpZGVyaW5nIHRoYXQgd2hl biBhIGRyaXZlciBpcyBmb3JjZWQgdG8gY2hhbmdlCj4+IGl0J3MgaGFuZGxpbmcgYmVjYXVzZSBv ZiB0aGUgZmVuY2UgaW1wbGVtZW50YXRpb24gdGhhdCdzIGp1c3QgYW5vdGhlciBoaW50Cj4+IHRo YXQgdGhlcmUgaXMgc29tZXRoaW5nIHdyb25nIGhlcmUuCj4gT3V0IG9mIGN1cmlvc2l0eTogV2hh dCdzIHRoZSBibG9ja2VyIGZvciB1c2luZyBhIHRpbWVyL3NjaGVkdWxlZCB3b3JrCj4gdG8gcmVz ZXQgcmFkZW9uPyBHZXR0aW5nIHRoaXMgcmlnaHQgb24gaTkxNSBoYXMgYmVlbiBmYWlybHkgdHJp Y2t5IGFuZAo+IHdlIG5vdyBoYXZlIGFuIGVsYWJvcmF0ZSBtdWx0aS1zdGFnZSBzdGF0ZSBtYWNo aW5lIHRvIGdldCB0aGUgZHJpdmVyCj4gdGhyb3VnaCBhIHJlc2V0LiBTbyBhbHdheXMgaW50ZXJl c3RlZCBpbiBkaWZmZXJlbnQgc29sdXRpb25zLgoKSUlSQyB3ZSB3b3VsZCBoYXZlIG5lZWRlZCBh IHF1aXRlIGFkdmFuY2VkIG11bHRpLXN0YWdlIHN0YXRlIG1hY2hpbmUgYXMgCndlbGwgYW5kIHRo YXQgd2FzIGp1c3QgdG8gbXVjaCBvdmVyaGVhZCBhdCB0aGlzIHBvaW50LgoKT25lIG1ham9yIHBy b2JsZW0gd2FzIHRoZSBwb3dlciBtYW5hZ2VtZW50IGluIHVzZSBiYWNrIHRoZW4sIGJ1dCB0aGF0 IApnb3QgcmVwbGFjZWQgYnkgRFBNIGluIHRoZSBtZWFudGltZS4gU28gaXQgbWlnaHQgYmUgYSBn b29kIGlkZWEgdG8gdHJ5IAphZ2Fpbi4KCldoYXQgd2UgY3VycmVudGx5IGRvIGlzIG1hcmtpbmcg dGhlIGRyaXZlciBhcyAibmVlZHMgcmVzZXQiIGFuZCAKcmV0dXJuaW5nIC1FQUdBSU4gYW5kIHRo ZW4gdGhlIG5leHQgSU9DVEwgc3RhcnRzIHRoZSByZXNldCBwcm9jZWR1cmUgCmJlZm9yZSBkb2lu ZyBhbnl0aGluZyBlbHNlLgoKQ2hyaXN0aWFuLgoKPiAtRGFuaWVsCgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRy aS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cDovL2xpc3RzLmZyZWVkZXNrdG9wLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757325AbaGWIcL (ORCPT ); Wed, 23 Jul 2014 04:32:11 -0400 Received: from dns-bn1lp0143.outbound.protection.outlook.com ([207.46.163.143]:30266 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755655AbaGWIcH convert rfc822-to-8bit (ORCPT ); Wed, 23 Jul 2014 04:32:07 -0400 X-WSS-ID: 0N95P1A-08-ZNC-02 X-M-MSG: Message-ID: <53CF72FA.9070806@amd.com> Date: Wed, 23 Jul 2014 10:31:54 +0200 From: =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5pZw==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Daniel Vetter CC: =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5pZw==?= , "Maarten Lankhorst" , Thomas Hellstrom , nouveau , LKML , dri-devel , Ben Skeggs , "Deucher, Alexander" Subject: Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences 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> <53CE8A57.2000803@vodafone.de> <53CF58FB.8070609@canonical.com> <53CF5B9F.1050800@amd.com> <53CF5EFE.6070307@canonical.com> <53CF63C2.7070407@vodafone.de> <53CF6622.6060803@amd.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed X-Originating-IP: [10.224.155.198] Content-Transfer-Encoding: 8BIT X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:165.204.84.222;CTRY:US;IPV:NLI;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(6009001)(428002)(189002)(199002)(51704005)(24454002)(377454003)(55674003)(84676001)(77982001)(85306003)(59896001)(101416001)(4396001)(64126003)(80022001)(65806001)(65956001)(79102001)(105586002)(83506001)(47776003)(74662001)(20776003)(64706001)(106466001)(23676002)(85202003)(21056001)(81342001)(95666004)(68736004)(65816999)(76176999)(87266999)(54356999)(107046002)(50466002)(33656002)(87936001)(83322001)(86362001)(85852003)(80316001)(19580405001)(83072002)(44976005)(99396002)(19580395003)(50986999)(92726001)(46102001)(76482001)(36756003)(93886003)(110136001)(97736001)(102836001)(81542001)(85182001);DIR:OUT;SFP:;SCL:1;SRVR:CO1PR02MB048;H:atltwp02.amd.com;FPR:;MLV:sfv;PTR:InfoDomainNonexistent;MX:1;LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 028166BF91 Authentication-Results: spf=none (sender IP is 165.204.84.222) smtp.mailfrom=Christian.Koenig@amd.com; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-OriginatorOrg: amd4.onmicrosoft.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 23.07.2014 10:01, schrieb Daniel Vetter: > On Wed, Jul 23, 2014 at 9:37 AM, Christian König > wrote: >> Am 23.07.2014 09:31, schrieb Daniel Vetter: >>> On Wed, Jul 23, 2014 at 9:26 AM, Christian König >>> wrote: >>>> It's not a locking problem I'm talking about here. Radeons lockup >>>> handling >>>> kicks in when anything calls into the driver from the outside, if you >>>> have a >>>> fence wait function that's called from the outside but doesn't handle >>>> lockups you essentially rely on somebody else calling another radeon >>>> function for the lockup to be resolved. >>> So you don't have a timer in radeon that periodically checks whether >>> progress is still being made? That's the approach we're using in i915, >>> together with some tricks to kick any stuck waiters so that we can >>> reliably step in and grab locks for the reset. >> >> We tried this approach, but it didn't worked at all. >> >> I already considered trying it again because of the upcoming fence >> implementation, but reconsidering that when a driver is forced to change >> it's handling because of the fence implementation that's just another hint >> that there is something wrong here. > Out of curiosity: What's the blocker for using a timer/scheduled work > to reset radeon? Getting this right on i915 has been fairly tricky and > we now have an elaborate multi-stage state machine to get the driver > through a reset. So always interested in different solutions. IIRC we would have needed a quite advanced multi-stage state machine as well and that was just to much overhead at this point. One major problem was the power management in use back then, but that got replaced by DPM in the meantime. So it might be a good idea to try again. What we currently do is marking the driver as "needs reset" and returning -EAGAIN and then the next IOCTL starts the reset procedure before doing anything else. Christian. > -Daniel