On Friday, March 6, 2009 5:55:52 pm Keith Packard wrote: > On Fri, 2009-03-06 at 15:19 -0800, Eric Anholt wrote: > > Given that these functions aren't actually hooked up to anything, I'm > > not sure if there's any value here. It sounds like we're going to go to > > using the resume_force_mode function for suspend/resume, which means > > we'd never use these. > > I'm concerned that our mode setting code doesn't hit all of the same > registers that the suspend/resume code does. There are a pile of > registers which the BIOS may whack, and which will not be reset > correctly unless we save their values before the system is suspended the > first time. > > Otherwise, I love the 'just set the mode' plan. Any chance we can strip > the suspend/resume code down to registers which our mode setting code > *doesn't* save/restore? Or merge suitable 'restorish' bits into the mode > setting path so that the other registers are set in the normal mode > setting path?
Yeah, I think that's the direction we should be heading. The top leve suspend/resume routines should handle global GPU state (and possibly save/restore a GPU context), but beyond that we just set a mode, which should take care of the rest. That means we can get rid of all the output specific save/restore routines as a bonus. -- Jesse Barnes, Intel Open Source Technology Center ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
