On Fri, Jun 17, 2005 at 09:35:31AM +1000, Benjamin Herrenschmidt wrote: > On Thu, 2005-06-16 at 21:29 +0100, Dave Airlie wrote: > > > The DRM drivers know what is important but they don't know when > > > suspend/VT swap is happening because there is only one set of kernel > > > hooks and the fbdev driver is attached to them. The scheme where a > > > texture copy is kept in system RAM doesn't depend on the DRM driver > > > having suspend/VT swap hooks since it is able to rebuild VRAM at any > > > point. > > > > > > > Take a look at the _pm code in current DRM CVS it uses sysdev to hook > > suspend/resume for DRM... I'm not too happy about this going into > > upstream yet, but I'm willing to give it a try... > > A sysdev is the wrong approach imho. These are very low level, run with > interrupts off, and have ordering issues, I'd rather avoid them. Also, > at the point your sysdev suspend is called, it's likely that the video > card will already be in D3 state -> no access to vram.
Ben, Can you provide more detail here ? The current situation is that when fbdev is loaded the DRM falls back to using the sysdev approach. If fbdev isn't loaded it takes direct control as the DRM becomes a real PCI driver and accesses the PCI functions for suspend/resume directly. What's the alternative to sysdev in the current model when fbdev is loaded ?? Also, can you explain the ordering issues ?? Thanks, Alan. ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel