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

Reply via email to