From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Christian_K=F6nig?= Subject: Re: Include request for reset-rework branch v3 Date: Wed, 02 May 2012 13:25:05 +0200 Message-ID: <4FA11991.9060308@vodafone.de> References: <1335931258-11756-1-git-send-email-j.glisse@gmail.com> <4FA0F895.80701@vodafone.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from outgoing.email.vodafone.de (outgoing.email.vodafone.de [139.7.28.128]) by gabe.freedesktop.org (Postfix) with ESMTP id 02A4BA09A9 for ; Wed, 2 May 2012 04:25:09 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Dave Airlie Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On 02.05.2012 12:32, Dave Airlie wrote: > On Wed, May 2, 2012 at 10:04 AM, Christian K=F6nig > wrote: >> On 02.05.2012 06:04, Jerome Glisse wrote: >>> On Wed, May 2, 2012 at 12:00 AM, wrote: >>>> Ok so i reread stuff and the : >>>> drm/radeon: add general purpose fence signaled callback >>>> is a big NAK actually. It change the paradigm. Moving most of >>>> the handling into the irq process which is something i am intimatly >>>> convinced we should avoid. >>>> >>>> Here is the patchset up to ib pool cleanup. I have yet rebase the >>>> other patches as i am tracking done some issue in the sa allocation. >>>> >>>> Cheers, >>>> Jerome >>>> >>> Before i forget, the big issue with doing work from irq handler is that >>> we never know in middle of what other part can be. I believe it's lot >>> better to have irq process only update fence (signaled/not signaled). >>> and have the actual work happening on behalf of the process wether >>> through sa alloc path or ttm path. >> >> Disagree. >> >> Why should it be better to delay work outside of the interrupt context if >> proper locking can make the driver much more responsive and easier to >> implement? >> >> I don't want to call into TTM or stuff like that, just want make it poss= ible >> to release the resources acquired for a job immediately after the job is >> completed instead of waiting for the next allocation to happen. Cause th= en >> you don't need to check if a bunch of fences might possible be signaled = and >> instead just get a proper signal that resources can be deallocated. >> >> Also if you really want to keep the irq context out of the drivers upper >> layers, it should be quite easy to modify the code so that the callback >> won't happen from there. > as a general rule try an minimise how much work we do in irq context, > the locking gets very messy once you have to use a mutex somewhere > else in the future. Akk, that sounds reasonable, but I still think that a fence should = signal it's completion by itself. Because that releases us from the = burden to walk the list of emitted fences and heuristically check if any = of them is already signaled. Also it is pretty easy to move the callback outside of interrupt = context, but first things first. I'm going to write together a patchset = with everything that is already accepted, so we can stop mailing around = actually unrelated patches. Thanks for the comments, Christian.