On Tuesday, August 26, 2008 12:03 pm Stephane Marchesin wrote: > On Tue, Aug 26, 2008 at 8:57 PM, Jesse Barnes <[EMAIL PROTECTED]> 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). > > This patch breaks a couple of drivers. Is this an oversight, or does > the "new development model" mean that we break drivers that are not in > linux each time ?
1) this is an RFC that hasn't been pushed anywhere yet, so nothing is actually broken by it 2) this patch is against the drm-next Linux tree, so any breakage is limited to the drivers there But I assume you're talking about nouveau? Does it have any funky requirements wrt IRQ registration? Or would it be relatively easy to move its interrupt handler registration and IRQ setup to the load routine? As for the "new development model"... Things are actually worse than I thought. There are some fairly large differences between linux-core and upstream, some of which have been in linux-core for a long time. It's one thing to have an out-of-tree development process but another entirely to let stuff rot for months & years there. It just adds to the already huge set of driver combinations we have to worry about and support... So drm-next is all I care about anymore. I'm trying to sync the last couple of years worth of development to that tree so I can start ignoring linux-core entirely. It's just too disconnected from upstream Linux for me to worry about (note that this doesn't mean I don't care about BSD compat; I want to make sure sharing is still reasonably easy, but if anything I'd like the merges to go from drm-next -> linux-core rather than the other way around for my development). -- Jesse Barnes, Intel Open Source Technology Center ------------------------------------------------------------------------- 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
