lkml.org 
[lkml]   [2014]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences
Am 23.07.2014 12:52, schrieb Daniel Vetter:
> On Wed, Jul 23, 2014 at 12:13 PM, Christian König
> <christian.koenig@amd.com> 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.

Christian.

> I guess for radeon we just have to add tons of insulation by punting
> all callbacks to work items so that radeon can do whatever it wants.
> Plus start a delayed_work based fallback when ->enable_signalling is
> called to make sure we work on platforms that lack interrupts.
> -Daniel

--
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/

\
 
 \ /
  Last update: 2014-07-23 15:22    [W:0.428 / U:0.468 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site