On 2002.04.21 17:41 Felix K�hling wrote: > On Sun, 21 Apr 2002 09:36:35 +0100 > Jos� Fonseca <[EMAIL PROTECTED]> wrote: > > ... > > I had a look at the radeon and r128 drivers. They both don't lock when > switching the mode. But in LeaveVT and EnterVT they do > RADEONCP_STOP/R128CCE_STOP after DRILock and RADEONCP_START/R128CCE_START > before DRIUnlock respectively. I don't know what they do. In the r128 > case it boils down to an ioctl DRM_IOCTL_R128_CCE_START/STOP in > programs/Xserver/hw/xfree86/os-support/linux/drm/xf86drmR128.c. I havn't > looked into the kernel drm stuff yet. Can anyone enlighten us in the > meantime? >
The DRM_IOCTL_R128_CCE_START/STOP boils down to the r128_do_cce_start/(flush+idle+stop). In other words they send the remaining commands, wait for them to be finished, and stop the engine. The analogous thing of CCE in Mach64 is DMA, but at this moment there is no real DMA, every command is sent to card by the DRM in the moment of receival. So there is nothing to stop. I've been reading the "Hardware Locking for the DRI" document (http://dri.sourceforge.net/doc/hardware_locking_low_level.html) to have a better understandment of the locking mechanism. Of course that is somewhat outdated. Jens once said: "This document is in decent shape. However, we don't use hardware locking very much for DMA based drivers; and it's really a infrastructure design justification. Not recommended for 1st time driver writers; better for developer wanting to extend the infrastructure and needing a low overhead lock." Bottom line: I still didn't figured out how the locking is guaranteed. The existing problem seems to be related to the context switch. I guess that I'll have plenty of question for tomorrow meeting. > > You could attempt to do something like (with root): > > > > at now + 1 minutes > > killall -9 X > > ^D > > > > and you got 1 minutes to do the testing. If everything worked allright, > > > you could still stop the job. Check "at" manpage for details. > > Yeah, I thought about that, too. But it is always hard to know how much > time you need for your test. And in the end it might be faster to reboot > the machine :). Thanks, anyway. > Yeah. Another annoying thing that also happens frequentely when things go wrong is that the VT gets trashed, and doesn't matter if you reset X or not, since you never will be able to VT switch again until a reboot. > > Felix > Jos� Fonseca _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
