Am 23.07.2014 12:52, schrieb Daniel Vetter: > On Wed, Jul 23, 2014 at 12:13 PM, Christian K?nig > <christian.koenig at 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
