1. 02 11月, 2013 13 次提交
  2. 01 11月, 2013 1 次提交
    • L
      i915: fix compiler warning · 0baab4fd
      Linus Torvalds 提交于
      The last i915 drm update brought with it this annoying warning
      
        drivers/gpu/drm/i915/intel_crt.c: In function ‘intel_crt_get_config’:
        drivers/gpu/drm/i915/intel_crt.c:110:21: warning: unused variable ‘dev’ [-Wunused-variable]
          struct drm_device *dev = encoder->base.dev;
                             ^
      
      introduced by commit 7195a50b ("drm/i915: Add HSW CRT output readout
      support").
      
      Remove the offending pointless variable.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0baab4fd
  3. 31 10月, 2013 6 次提交
  4. 30 10月, 2013 3 次提交
  5. 29 10月, 2013 4 次提交
    • D
      drm/i915: Fix the PPT fdi lane bifurcate state handling on ivb · 1fbc0d78
      Daniel Vetter 提交于
      Originally I've thought that this is leftover hw state dirt from the
      BIOS. But after way too much helpless flailing around on my part I've
      noticed that the actual bug is when we change the state of an already
      active pipe.
      
      For example when we change the fdi lines from 2 to 3 without switching
      off outputs in-between we'll never see the crucial on->off transition
      in the ->modeset_global_resources hook the current logic relies on.
      
      Patch version 2 got this right by instead also checking whether the
      pipe is indeed active. But that in turn broke things when pipes have
      been turned off through dpms since the bifurcate enabling is done in
      the ->crtc_mode_set callback.
      
      To address this issues discussed with Ville in the patch review move
      the setting of the bifurcate bit into the ->crtc_enable hook. That way
      we won't wreak havoc with this state when userspace puts all other
      outputs into dpms off state. This also moves us forward with our
      overall goal to unify the modeset and dpms on paths (which we need to
      have to allow runtime pm in the dpms off state).
      
      Unfortunately this requires us to move the bifurcate helpers around a
      bit.
      
      Also update the commit message, I've misanalyzed the bug rather badly.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70507Tested-by: NJan-Michael Brummer <jan.brummer@tabos.org>
      Cc: stable@vger.kernel.org
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      1fbc0d78
    • R
      drm/i915: No LVDS hardware on Intel D410PT and D425KT · 645378d8
      Rob Pearce 提交于
      The Intel D410PT(LW) and D425KT Mini-ITX desktop boards both show up as
      having LVDS but the hardware is not populated. This patch adds them to
      the list of such systems. Patch is against 3.11.4
      
      v2: Patch revised to match the D425KT exactly as the D425KTW does have
      LVDS.  According to Intel's documentation, the D410PTL and D410PLTW
      don't.
      Signed-off-by: NRob Pearce <rob@flitspace.org.uk>
      Cc: stable@vger.kernel.org
      [danvet: Pimp commit message to my liking and add cc: stable.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      645378d8
    • J
      drm/i915/dp: workaround BIOS eDP bpp clamping issue · c6cd2ee2
      Jani Nikula 提交于
      This isn't a real fix to the problem, but rather a stopgap measure while
      trying to find a proper solution.
      
      There are several laptops out there that fail to light up the eDP panel
      in UEFI boot mode. They seem to be mostly IVB machines, including but
      apparently not limited to Dell XPS 13, Asus TX300, Asus UX31A, Asus
      UX32VD, Acer Aspire S7. They seem to work in CSM or legacy boot.
      
      The difference between UEFI and CSM is that the BIOS provides a
      different VBT to the kernel. The UEFI VBT typically specifies 18 bpp and
      1.62 GHz link for eDP, while CSM VBT has 24 bpp and 2.7 GHz link. We end
      up clamping to 18 bpp in UEFI mode, which we can fit in the 1.62 Ghz
      link, and for reasons yet unknown fail to light up the panel.
      
      Dithering from 24 to 18 bpp itself seems to work; if we use 18 bpp with
      2.7 GHz link, the eDP panel lights up. So essentially this is a link
      speed issue, and *not* a bpp clamping issue.
      
      The bug raised its head since
      commit 657445fe
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Sat May 4 10:09:18 2013 +0200
      
          Revert "drm/i915: revert eDP bpp clamping code changes"
      
      which started clamping bpp *before* computing the link requirements, and
      thus affecting the required bandwidth. Clamping after the computations
      kept the link at 2.7 GHz.
      
      Even though the BIOS tells us to use 18 bpp through the VBT, it happily
      boots up at 24 bpp and 2.7 GHz itself! Use this information to
      selectively ignore the VBT provided value.
      
      We can't ignore the VBT eDP bpp altogether, as there are other laptops
      that do require the clamping to be used due to EDID reporting higher bpp
      than the panel can support.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59841
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67950Tested-by: NUlf Winkelvos <ulf@winkelvos.de>
      Tested-by: Njkp <jkp@iki.fi>
      CC: stable@vger.kernel.org
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      c6cd2ee2
    • V
      drm/i915: Add HSW CRT output readout support · 7195a50b
      Ville Syrjälä 提交于
      Call intel_ddi_get_config() to get the pipe_bpp settings from
      DDI.
      
      The sync polarity settings from DDI are irrelevant for CRT
      output, so override them with data from the ADPA register.
      
      Note: This is already merged in drm-intel-next-queued as
      
      commit 6801c18c
      Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Date:   Tue Sep 24 14:24:05 2013 +0300
      
          drm/i915: Add HSW CRT output readout support
      
      but is required for the following edp bpp bugfix.
      
      v2: Extract intel_crt_get_flags()
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69691Tested-by: NQingshuai Tian <qingshuai.tian@intel.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7195a50b
  6. 28 10月, 2013 1 次提交
  7. 26 10月, 2013 3 次提交
    • N
      vhost/scsi: Fix incorrect usage of get_user_pages_fast write parameter · 60a01f55
      Nicholas Bellinger 提交于
      This patch addresses a long-standing bug where the get_user_pages_fast()
      write parameter used for setting the underlying page table entry permission
      bits was incorrectly set to write=1 for data_direction=DMA_TO_DEVICE, and
      passed into get_user_pages_fast() via vhost_scsi_map_iov_to_sgl().
      
      However, this parameter is intended to signal WRITEs to pinned userspace
      PTEs for the virtio-scsi DMA_FROM_DEVICE -> READ payload case, and *not*
      for the virtio-scsi DMA_TO_DEVICE -> WRITE payload case.
      
      This bug would manifest itself as random process segmentation faults on
      KVM host after repeated vhost starts + stops and/or with lots of vhost
      endpoints + LUNs.
      
      Cc: Stefan Hajnoczi <stefanha@redhat.com>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: Asias He <asias@redhat.com>
      Cc: <stable@vger.kernel.org> # 3.6+
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      60a01f55
    • W
      target/pscsi: fix return value check · 58932e96
      Wei Yongjun 提交于
      In case of error, the function scsi_host_lookup() returns NULL
      pointer not ERR_PTR(). The IS_ERR() test in the return value check
      should be replaced with NULL test.
      Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      58932e96
    • D
      mtd: gpmi: fix ECC regression · 031e2777
      David Woodhouse 提交于
      The "legacy" ECC layout used until 3.12-rc1 uses all the OOB area by
      computing the ECC strength and ECC step size ourselves.
      
      Commit 2febcdf8 ("mtd: gpmi: set the BCHs geometry with the ecc info")
      makes the driver use the ECC info (ECC strength and ECC step size)
      provided by the MTD code, and creates a different NAND ECC layout
      for the BCH, and use the new ECC layout. This causes a regression:
      
         We can not mount the ubifs which was created by the old NAND ECC layout.
      
      This patch fixes this issue by reverting to the legacy ECC layout.
      
      We will probably introduce a new device-tree property to indicate that
      the new ECC layout can be used. For now though, for the imminent 3.12
      release, we just unconditionally revert to the 3.11 behaviour.
      
      This leaves a harmless cosmetic warning about an unused function. At
      this point in the cycle I really don't care.
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      Acked-by: NHuang Shijie <b32955@freescale.com>
      Acked-by: NMarek Vasut <marex@denx.de>
      Tested-by: NMarek Vasut <marex@denx.de>
      031e2777
  8. 25 10月, 2013 8 次提交
  9. 24 10月, 2013 1 次提交