Jesse Barnes wrote: > On Tuesday, August 26, 2008 12:23 pm Thomas Hellström wrote: > >> Jesse Barnes wrote: >> >>> The DRM design includes ioctls to allow a userland driver to tell the >>> kernel driver when to register its interrupt handler and on what IRQ. >>> This is a really bad idea for several reasons, and fortunately I don't >>> think any DDX drivers take advantage of the "no, use this IRQ" aspect of >>> the API (and even if they did the kernel driver would have to ignore it). >>> >>> This patch removes the DRM support for those ioctls, making drivers just >>> register their interrupt handlers at load time. The patch is fairly >>> straightforward but there are still caveats, so each driver will need >>> careful review to make sure that userland drivers don't set up additional >>> state required for proper interrupt handling/enabling. It also means >>> drivers have to map registers at load time; the r128 bits in particular >>> looked funky in that regard so extra eyes there would be appreciated. >>> >>> I've only tested this patch so far on i915, where it's still slightly >>> broken; I was planning on fixing it once I've sync'd some more linux-core >>> changes into drm-next (namely the rest of the vblank-rework code). >>> >> Hi, >> >> I know this breaks via at least since the device is more or less dead >> until the X server programs the sequencer, so that >> would require a bunch of setup code at load time to fix. >> >> I agree it's a bad idea to keep the old irq ioctls, but why not get rid >> of the ioctls only and keep the old irq driver infrastructure and let >> the drivers call drm_irq_install() or drm_irq_uninstall() where fit, >> either in driver_load() / driver_unload() or driver_firstopen() / >> driver_lastclose()? >> > > Yeah that's definitely a possibility, thanks for looking at the via bits. > Though for kernel mode setting via will need to set that stuff up at load > time anyway, right? How hard would it be to port that code? > > Thanks, > It wouldn't be too hard to port VIA I think, but it requires some careful thoughts and close interaction with the 2D driver and thus would be a bit time-consuming. The situation is more complicated by the fact that there are three open-source VIA driver (not counting VIA's own) hanging around. :)
/Thomas ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
