Re: [RFC] remove DRM IRQ installation funcs

[Jesse B. <jb...@vi...>]

On Tuesday, August 26, 2008 4:15 pm Dave Airlie wrote:
> On Wed, Aug 27, 2008 at 5:23 AM, Thomas Hellström
> >> 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.

Yeah, it would likely get ugly unless we were really careful about each 
driver; and I don't know enough about how the various 2D sides work to do 
that kind of audit myself.

And there's nothing to stop us from doing this carefully for each driver 
first, and only then ripping out the core code.  I think we could manage this 
in i915 fairly easily at least, but even then I don't think we'd want to do 
it until the vblank-rework stuff is upstream (which I'm working on now).

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center