From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Christian_K=F6nig?= Subject: Re: Re: Include request for reset-rework branch v3 Date: Wed, 02 May 2012 11:04:21 +0200 Message-ID: <4FA0F895.80701@vodafone.de> References: <1335931258-11756-1-git-send-email-j.glisse@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from outgoing.email.vodafone.de (outgoing.email.vodafone.de [139.7.28.128]) by gabe.freedesktop.org (Postfix) with ESMTP id 89F739E764 for ; Wed, 2 May 2012 02:04:27 -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: Jerome Glisse Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org 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 possible to release the resources acquired for a job immediately after the job is completed instead of waiting for the next allocation to happen. Cause then 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. Christian.