Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756033AbaGWMmK (ORCPT ); Wed, 23 Jul 2014 08:42:10 -0400 Received: from mail-ig0-f172.google.com ([209.85.213.172]:34758 "EHLO mail-ig0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752977AbaGWMmI convert rfc822-to-8bit (ORCPT ); Wed, 23 Jul 2014 08:42:08 -0400 MIME-Version: 1.0 X-Originating-IP: [84.73.67.144] In-Reply-To: <53CFAC38.9050501@amd.com> References: <20140709093124.11354.3774.stgit@patser> <53CF58FB.8070609@canonical.com> <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> Date: Wed, 23 Jul 2014 14:42:07 +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: Maarten Lankhorst , =?UTF-8?Q?Christian_K=C3=B6nig?= , 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 Wed, Jul 23, 2014 at 2:36 PM, Christian König wrote: > 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. Imo that should be an implementation detail of the fence provider. So in ->enable_signaling radeon needs to arm a delayed work to regularly check fence and signal them if the irq failed. If it's a common need we might provide some shared code for this (e.g. a struct unreliable_fence or so). But this shouldn't be mandatory since not all gpus are broken like that. And if we force other drivers to care for this special case that imo leaks the abstraction out of radeon (or any other driver with unreliable interrupts). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/