Re: [Intel-gfx] [PATCH 1/4] drm/i915: don't block resume on fb console resume v2

Jesse Barnes writes: > v2: use console_trylock() to try to resume the console immediately > (Chris) This will cause other printks to stall if i915 grabs the lock first. Seems like a way to get random resume delays to me. -- keith.pack...@intel.com pgpas36b6iooM.pgp Description: PGP signature

Re: [Intel-gfx] [PATCH 1/2] PM: make VT switching to the suspend console optional

> that, but how would I even configure a VT split across two adapters > today? For vgacon we just route VGA to a single adapter, but I'm not con2fb /dev/fb1 /dev/tty1 > Dunno about suspend vs unload, how do we deal that in other drivers like > the disk driver for suspend for example? Overall

Re: [Intel-gfx] [PATCH 0/3] drm/i915: eDP scaling mode change support

Hi Jani, Sorry for the delay, our branches have diverged significantly, and it took me quite a while to merge your changes. On the bright sight, I've tested the patch on SandyBridge LDVS and IvyBridge eDP, and it works fine. Regards, Yuly. On Fri, Oct 26, 2012 at 9:44 AM, Paulo Zanoni wrote:

Re: [Intel-gfx] [PATCH 1/2] PM: make VT switching to the suspend console optional

On Fri, 2 Nov 2012 14:43:40 -0700 Jesse Barnes wrote: > KMS drivers can potentially restore the display configuration without > userspace help. Such drivers can set a new global, pm_vt_switch, to > false if they support this feature. In that case, the PM layer won't VT > switch to the suspend

Re: [Intel-gfx] [RFC] Suspend/resume without VT switches

On Friday, November 02, 2012 04:29:37 PM Jesse Barnes wrote: > On Fri, 02 Nov 2012 22:51:07 +0100 > "Rafael J. Wysocki" wrote: > > > On Friday, November 02, 2012 02:43:39 PM Jesse Barnes wrote: > > > I've lightly tested this with X and it definitely makes my > > > suspend/resume sequence a bit pr

Re: [Intel-gfx] [RFC] Suspend/resume without VT switches

On Friday, November 02, 2012 02:43:39 PM Jesse Barnes wrote: > I've lightly tested this with X and it definitely makes my > suspend/resume sequence a bit prettier. It should speed things up > trivally as well, but most of those gains come from other changes to the > i915 driver (posted earlier to

Re: [Intel-gfx] [PATCH 05/10] drm/i915: extract dev_priv fbc state into separate substruct

On Fri, Nov 02, 2012 at 12:09:46PM -0700, Jesse Barnes wrote: > On Fri, 2 Nov 2012 19:55:06 +0100 > Daniel Vetter wrote: > > > Unfortunately this makes it clearer that our fbc code is ... somewhat > > hackish > > and racy. > > > > Signed-off-by: Daniel Vetter Ok, I've dropped this one again