|| ||Jesse Barnes <jbarnes-AT-virtuousgeek.org>|
|| ||"Stephane Marchesin" <marchesin-AT-icps.u-strasbg.fr>|
|| ||Re: [RFC] remove DRM IRQ installation funcs|
|| ||Tue, 26 Aug 2008 12:36:09 -0700|
On Tuesday, August 26, 2008 12:03 pm Stephane Marchesin wrote:
> On Tue, Aug 26, 2008 at 8:57 PM, Jesse Barnes <firstname.lastname@example.org>
> > 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
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
to post comments)