Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Jesse Barnes <jbarnes <at> virtuousgeek.org>
Subject: Re: [RFC] remove DRM IRQ installation funcs
Newsgroups: gmane.comp.video.dri.devel
Date: Tuesday 26th August 2008 19:36:09 UTC (over 9 years ago)
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=/
--
 
CD: 4ms