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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 that case seems pretty > esoteric... > > What do you mean about hand over to multiple frame buffers? You have a global but I can insmod i915 move the consoles off it and unload it (at least in theory - last time I tried it crashed at least on gma500 which I need to fix 8)) So you've got a global you can't just set back but need to adjust on unload. And you've got races like suspend as we are changing framebuffer which your code doesn't consider as you have no locking. If we push the logic into the vt layer we can pretty easily dump it under the vt locks. It's not the whole story as there are all sorts of things it doesn't handle but it does mean we can handle the case of "if we are switching from a vt which is on a device that doesn't need it for suspend then do nothing" properly, and we can make any future features work right I think all we need is consw to have a con_sw_suspend/con_sw_resume method and the framebuffer layer to let kms get at it. Alan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
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: > Hi > > 2012/10/26 Jani Nikula : > > [Dropped lkml, added intel-gfx] > > > > Hi Yuly, here's a slightly modified version of your patch, rebased on > > drm-intel-next-queued. I kept your authorship, but any new errors are > > totally mine... > > > > These are compile tested only; I'd appreciate if you could check it > > still does what it says on the box! > > I have nothing to add or remove. Tested on HSW eDP, used "xrandr" to > alternate the property values. Works fine. > > Being consistent on the default value between LVDS and eDP is > certainly a nice thing. > > For the 3 patches: > Reviewed-by: Paulo Zanoni > Tested-by: Paulo Zanoni > > > > > BR, > > Jani. > > > > > > Jani Nikula (1): > > drm/i915/lvds: move fitting mode from intel_lvds_connector to > > intel_panel > > > > Yuly Novikov (2): > > drm/i915/dp: allow configuring eDP panel fitting scaling mode > > drm/i915/dp: change eDP default scaling mode to respect aspect ratio > > > > drivers/gpu/drm/i915/intel_dp.c | 31 ++- > > drivers/gpu/drm/i915/intel_drv.h |1 + > > drivers/gpu/drm/i915/intel_lvds.c | 24 ++-- > > 3 files changed, 41 insertions(+), 15 deletions(-) > > > > -- > > 1.7.9.5 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > -- > Paulo Zanoni > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 console at suspend time and then back to the > original VT on resume, but rather leave things alone for a nicer looking > suspend and resume sequence. What if you are multi-head ? What are the locking rules for a suspend/kms module unload race, what happens when you load/unload and hand over multiple frame buffers ? What if you have vts split across two adapters ? Put me down as 100% in favour of the feature but we need to be a bit more careful about the implementation. The logic probably needs to be in the vt layer. I suspect we actually need a per vt flag for this, or a flag on the underlying object below the vt somewhere. So NAK for the implementation ACK for the idea. Alan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 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 intel-gfx). > > > > > > Any thoughts? > > > > I like the idea. > > > > > I suspect we'll have to be more defensive about the > > > resume configuration in case the BIOS did something weird, but overall I > > > think we should be able to do this one way or another. > > > > Perhaps patch [1/2] should be [2/2] and vice versa? :-) > > But then it wouldn't compile? I added the variable first, defaulting > to the current behavior, then made i915 support it and set the variable > to false there... At least, that's what I intended to do. OK So what happens if there are multiple graphics adapters in the system? Including such that aren't handled by i915? pm_vt_switch is global, so isn't there any problem with that? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 intel-gfx). > > Any thoughts? I like the idea. > I suspect we'll have to be more defensive about the > resume configuration in case the BIOS did something weird, but overall I > think we should be able to do this one way or another. Perhaps patch [1/2] should be [2/2] and vice versa? :-) Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 due to conflicts with Chris' stolen work. I've somehow thought I've merged the fbc related stolen patches already, but alas, no. If any other ongoing work conflicts too much with this, please yell (since I've probably just lost track of something somewhere). My apologies for this screw-up. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
