1. 27 6月, 2013 7 次提交
  2. 26 6月, 2013 20 次提交
  3. 12 6月, 2013 5 次提交
  4. 11 6月, 2013 6 次提交
  5. 10 6月, 2013 2 次提交
    • K
      xen/tmem: Don't over-write tmem_frontswap_poolid after tmem_frontswap_init set it. · b2c75c44
      Konrad Rzeszutek Wilk 提交于
      Commit 10a7a077 ("xen: tmem: enable Xen
      tmem shim to be built/loaded as a module") allows the tmem module
      to be loaded any time. For this work the frontswap API had to
      be able to asynchronously to call tmem_frontswap_init before
      or after the swap image had been set. That was added in git
      commit 905cd0e1
      ("mm: frontswap: lazy initialization to allow tmem backends to build/run as modules").
      
      Which means we could do this (The common case):
      
       modprobe tmem		[so calls frontswap_register_ops, no ->init]
      			 modifies tmem_frontswap_poolid = -1
       swapon /dev/xvda1	[__frontswap_init, calls -> init, tmem_frontswap_poolid is
      			 < 0 so tmem hypercall done]
      
      Or the failing one:
      
       swapon /dev/xvda1	[calls __frontswap_init, sets the need_init bitmap]
       modprobe tmem		[calls frontswap_register_ops, -->init calls, finds out
      			tmem_frontswap_poolid is 0, does not make a hypercall.
      			Later in the module_init, sets tmem_frontswap_poolid=-1]
      
      Which meant that in the failing case we would not call the hypercall
      to initialize the pool and never be able to make any frontswap
      backend calls.
      
      Moving the frontswap_register_ops after setting the tmem_frontswap_poolid
      fixes it.
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Reviewed-by: NBob Liu <bob.liu@oracle.com>
      b2c75c44
    • D
      drm/i915: prefer VBT modes for SVDO-LVDS over EDID · c3456fb3
      Daniel Vetter 提交于
      In
      
      commit 53d3b4d7
      Author: Egbert Eich <eich@suse.de>
      Date:   Tue Jun 4 17:13:21 2013 +0200
      
          drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC
      
      Egbert Eich fixed a long-standing bug where we simply used a
      non-working i2c controller to read the EDID for SDVO-LVDS panels.
      Unfortunately some machines seem to not be able to cope with the mode
      provided in the EDID. Specifically they seem to not be able to cope
      with a 4x pixel mutliplier instead of a 2x one, which seems to have
      been worked around by slightly changing the panels native mode in the
      VBT so that the dotclock is just barely above 50MHz.
      
      Since it took forever to notice the breakage it's fairly safe to
      assume that at least for SDVO-LVDS panels the VBT contains fairly sane
      data. So just switch around the order and use VBT modes first.
      
      v2: Also add EDID modes just in case, and spell Egbert correctly.
      
      v3: Elaborate a bit more about what's going on on Chris' machine.
      
      Cc: Egbert Eich <eich@suse.de>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65524
      Cc: stable@vger.kernel.org
      Reported-and-tested-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      c3456fb3