Re: [RFC] remove DRM IRQ installation funcs

[Thomas H. <th...@tu...>]

Jesse Barnes wrote:
> On Tuesday, August 26, 2008 12:23 pm Thomas Hellström wrote:
>   
>> Jesse Barnes 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).
>>>       
>> 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()?
>>     
>
> Yeah that's definitely a possibility, thanks for looking at the via bits.  
> Though for kernel mode setting via will need to set that stuff up at load 
> time anyway, right?  How hard would it be to port that code?
>
> Thanks,
>   
It wouldn't be too hard  to port VIA I think, but it requires some 
careful thoughts and close interaction
with the 2D driver and thus would be a bit time-consuming. The situation 
is more complicated by the fact that there
are three open-source VIA driver (not counting VIA's own) hanging around. :)

/Thomas