Include request for reset-rework branch v3

[Dave Airlie]

On Wed, May 2, 2012 at 10:04 AM, Christian König
<deathsimple at vodafone.de> wrote:
> On 02.05.2012 06:04, Jerome Glisse wrote:
>>
>> On Wed, May 2, 2012 at 12:00 AM,<j.glisse at gmail.com>  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.

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.

Dave.