On Wed, 2008-08-27 at 09:15 +1000, Dave Airlie wrote: > On Wed, Aug 27, 2008 at 5:23 AM, Thomas Hellström > <[EMAIL PROTECTED]> 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()? > > > > 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 kinda prompted this topic to come back to life... I'm less concerned with the IRQ bits than I am with the vblank issue, but they are currently tied together. What I'm seeing right now, it that at least the intel ddx driver calls the irq_uninstall ioctl before calling pre_modeset ioctl during vt switch. The way the code is now, irq_uninstall calls vblank_cleanup and clears all of the structures and resets num_crtcs to 0. When it hits modeset_ioctl it tests for num_crtcs and thinks the vblank_init hasn't been called and bails out and doesn't properly enable vblank over the modeset. When returning from vt switch, it is doing the opposite. It calls modeset_ctl ioctl, num_crtcs is still 0, because vblank_init doesn't get called until the irq_install ioctl gets called. So, the short story is that after a vt switch, vlbanks aren't allowed to be disabled. I had a patch around here somewhere that only moved the vblank_init and cleanup routines to the driver load / unload routines. This put the entire responsibilty on the driver, while not touching the irq install / uninstall routines. IIRC, I actually sent that patch to this list... It will require very minor changes to the linux driver bits, just to call vblank_init/cleanup at the right places. IMO, this is the way to go... I don't want to rely on the ddx driver to DTRT any more than I have to... When I mentioned something about this originally, someone stated that it would be good to just install the handlers at load time, and get rid of pre/post install. I ran into problems when I tried to go down that path, so I just settled to only move the vblank bits... robert. > 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. > > Dave. > > ------------------------------------------------------------------------- > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/dri-devel -- Robert Noland <[EMAIL PROTECTED]> 2Hip Networks
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
