lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 23 Jul 2014 12:52:50 +0200 From: Daniel Vetter <daniel.vetter@...ll.ch> To: Christian König <christian.koenig@....com> Cc: Maarten Lankhorst <maarten.lankhorst@...onical.com>, Christian König <deathsimple@...afone.de>, Thomas Hellstrom <thellstrom@...are.com>, nouveau <nouveau@...ts.freedesktop.org>, LKML <linux-kernel@...r.kernel.org>, dri-devel <dri-devel@...ts.freedesktop.org>, Ben Skeggs <bskeggs@...hat.com>, "Deucher, Alexander" <alexander.deucher@....com> Subject: Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences On Wed, Jul 23, 2014 at 12:13 PM, Christian König <christian.koenig@....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. 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 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists