From patchwork Wed Jul 23 13:16:50 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Maarten Lankhorst X-Patchwork-Id: 4610801 Return-Path: X-Original-To: patchwork-dri-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id A60439F2B8 for ; Wed, 23 Jul 2014 13:17:07 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id E3A1620142 for ; Wed, 23 Jul 2014 13:17:02 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id 841D3200DB for ; Wed, 23 Jul 2014 13:17:01 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id DBF7D6E103; Wed, 23 Jul 2014 06:16:59 -0700 (PDT) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by gabe.freedesktop.org (Postfix) with ESMTP id 4B1D76E103; Wed, 23 Jul 2014 06:16:58 -0700 (PDT) Received: from 5ed49945.cm-7-5c.dynamic.ziggo.nl ([94.212.153.69] helo=[192.168.1.128]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1X9wPa-0001Hv-S6; Wed, 23 Jul 2014 13:16:50 +0000 Message-ID: <53CFB5C2.7060207@canonical.com> Date: Wed, 23 Jul 2014 15:16:50 +0200 From: Maarten Lankhorst User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5pZw==?= , Daniel Vetter Subject: Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences References: <20140709093124.11354.3774.stgit@patser> <53CF5B9F.1050800@amd.com> <53CF5EFE.6070307@canonical.com> <53CF63C2.7070407@vodafone.de> <53CF6622.6060803@amd.com> <53CF699D.9070902@canonical.com> <53CF6B18.5070107@vodafone.de> <53CF7035.2060808@amd.com> <53CF7191.2090008@canonical.com> <53CF765E.7020802@vodafone.de> <53CF8010.9060809@amd.com> <53CF822E.7050601@amd.com> <53CF84C7.2020507@vodafone.de> <53CF8693.1040006@canonical.com> <53CF8AB1.2000009@amd.com> <53CFAC38.9050501@amd.com> In-Reply-To: <53CFAC38.9050501@amd.com> Cc: Thomas Hellstrom , nouveau , LKML , dri-devel , Ben Skeggs , "Deucher, Alexander" X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP op 23-07-14 14:36, Christian König schreef: > Am 23.07.2014 12:52, schrieb Daniel Vetter: >> On Wed, Jul 23, 2014 at 12:13 PM, Christian König >> wrote: >>>> And the dma-buf would still have fences belonging to both drivers, and it >>>> would still call from outside the driver. >>> >>> Calling from outside the driver is fine as long as the driver can do >>> everything necessary to complete it's work and isn't forced into any ugly >>> hacks and things that are not 100% reliable. >>> >>> So I don't see much other approach as integrating recovery code for not >>> firing interrupts and some kind of lockup handling into the fence code as >>> well. >> That approach doesn't really work at that well since every driver has >> it's own reset semantics. And we're trying to move away from global >> reset to fine-grained reset. So stop-the-world reset is out of >> fashion, at least for i915. As you said, reset is normal in gpus and >> we're trying to make reset less invasive. I really don't see a point >> in imposing a reset scheme upon all drivers and I think you have about >> as much motivation to convert radeon to the scheme used by i915 as >> I'll have for converting to the one used by radeon. If it would fit at >> all. > Oh my! No, I didn't wanted to suggest any global reset infrastructure. > > My idea was more that the fence framework provides a fence->process_signaling callback that is periodically called after enable_signaling is called to trigger manual signal processing in the driver. > > This would both be suitable as a fallback in case of not working interrupts as well as a chance for any driver to do necessary lockup handling. I managed to do it without needing it to be part of the interface? I'm not sure whether radeon_fence_driver_recheck needs exclusive_lock, but if so it's a small change.. diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index 7fbfd41479f1..51b646b9c8bb 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -345,6 +345,9 @@ struct radeon_fence_driver { uint64_t sync_seq[RADEON_NUM_RINGS]; atomic64_t last_seq; bool initialized; + struct delayed_work work; + struct radeon_device *rdev; + unsigned ring; }; struct radeon_fence_cb { diff --git a/drivers/gpu/drm/radeon/radeon_fence.c b/drivers/gpu/drm/radeon/radeon_fence.c index da83f36dd708..955c825946ad 100644 --- a/drivers/gpu/drm/radeon/radeon_fence.c +++ b/drivers/gpu/drm/radeon/radeon_fence.c @@ -231,6 +231,9 @@ static bool __radeon_fence_process(struct radeon_device *rdev, int ring) } } while (atomic64_xchg(&rdev->fence_drv[ring].last_seq, seq) > seq); + if (!wake && last_seq < last_emitted) + schedule_delayed_work(&rdev->fence_drv[ring].work, jiffies_to_msecs(10)); + return wake; } @@ -815,6 +818,14 @@ int radeon_fence_driver_start_ring(struct radeon_device *rdev, int ring) return 0; } +static void radeon_fence_driver_recheck(struct work_struct *work) +{ + struct radeon_fence_driver *drv = container_of(work, struct radeon_fence_driver, work.work); + + DRM_ERROR("omg, working!\n"); + radeon_fence_process(drv->rdev, drv->ring); +} + /** * radeon_fence_driver_init_ring - init the fence driver * for the requested ring. @@ -836,6 +847,10 @@ static void radeon_fence_driver_init_ring(struct radeon_device *rdev, int ring) rdev->fence_drv[ring].sync_seq[i] = 0; atomic64_set(&rdev->fence_drv[ring].last_seq, 0); rdev->fence_drv[ring].initialized = false; + + rdev->fence_drv[ring].ring = ring; + rdev->fence_drv[ring].rdev = rdev; + INIT_DELAYED_WORK(&rdev->fence_drv[ring].work, radeon_fence_driver_recheck); } /** @@ -880,6 +895,7 @@ void radeon_fence_driver_fini(struct radeon_device *rdev) for (ring = 0; ring < RADEON_NUM_RINGS; ring++) { if (!rdev->fence_drv[ring].initialized) continue; + cancel_delayed_work_sync(&rdev->fence_drv[ring].work); r = radeon_fence_wait_empty(rdev, ring); if (r) { /* no need to trigger GPU reset as we are unloading */ diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c b/drivers/gpu/drm/radeon/radeon_irq_kms.c index 16807afab362..85391ddd3ce9 100644 --- a/drivers/gpu/drm/radeon/radeon_irq_kms.c +++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c @@ -331,7 +331,7 @@ void radeon_irq_kms_sw_irq_get(struct radeon_device *rdev, int ring) { unsigned long irqflags; - if (!rdev->ddev->irq_enabled) +// if (!rdev->ddev->irq_enabled) return; if (atomic_inc_return(&rdev->irq.ring_int[ring]) == 1) { @@ -355,7 +355,7 @@ void radeon_irq_kms_sw_irq_put(struct radeon_device *rdev, int ring) { unsigned long irqflags; - if (!rdev->ddev->irq_enabled) +// if (!rdev->ddev->irq_enabled) return; if (atomic_dec_and_test(&rdev->irq.ring_int[ring])) {