On Tue, Aug 26, 2008 at 9:36 PM, Jesse Barnes <[EMAIL PROTECTED]> wrote: > 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?
nouveau, mach64, xgi... > 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? > It is easy, but I'm realizing things might not be as easy for more intrusive changes. I'm merely pointing out that things don't seem to be wokring out when we have a lot of branches and global changes happen. In-development drivers are not fixed, other operating systems are not fixed, in-development features can conflict and so on... It really seems untractable, so it really seems to me need a single place where all the current DRM action happens and the merge to linux from there. Otherwise the open source graphics world will start to lose drivers and platform support. > 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... How is doing merges preventing us from working on a single tree ? It's two completely separate problems. > > 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). Ok, so to restate that clearly you'll break drivers that are not in mainstream linux routinely because you don't really care. Stephane ------------------------------------------------------------------------- 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
