From: Alan H. <al...@fa...> - 2005-06-17 18:38:55
|
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. |