On Wed, Aug 27, 2008 at 5:23 AM, Thomas Hellström <[EMAIL PROTECTED]> 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()? >
This is the only practical solution that might work, however even doing this may prove to be a regression nightmare. Some userspace drivers write to the IRQ control registers themselves. I really think the practical solution is to look the other way, get modesetting drivers, and just ignore this functionality for drivers that own the card. Otherwise I fear actually getting this code upstream and working would be an outright regression-fest. Dave. ------------------------------------------------------------------------- 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
