1. 14 11月, 2013 1 次提交
  2. 09 11月, 2013 3 次提交
  3. 07 11月, 2013 1 次提交
    • J
      drm/i915: make backlight functions take a connector · 752aa88a
      Jesse Barnes 提交于
      On VLV/BYT, backlight controls a per-pipe, so when adjusting the
      backlight we need to pass the correct info.  So make the externally
      visible backlight functions take a connector argument, which can be used
      internally to figure out the pipe backlight to adjust.
      
      v2: make connector pipe lookup check for NULL crtc (Jani)
          fixup connector check in ASLE code (Jani)
      v3: make sure we take the mode config lock around lookups (Daniel)
      v4: fix double unlock in panel_get_brightness (Daniel)
      v5: push ASLE work into a work queue (Daniel)
      v6: separate ASLE work to a prep patch, rebase (Jani)
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      752aa88a
  4. 05 11月, 2013 1 次提交
  5. 01 11月, 2013 1 次提交
  6. 31 10月, 2013 2 次提交
  7. 29 10月, 2013 1 次提交
    • 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
  8. 22 10月, 2013 1 次提交
    • D
      drm/sysfs: sort out minor and connector device object lifetimes. · 5bdebb18
      Dave Airlie 提交于
      So drm was abusing device lifetimes, by having embedded device structures
      in the minor and connector it meant that the lifetime of the internal drm
      objects (drm_minor and drm_connector) were tied to the lifetime of the device
      files in sysfs, so if something kept those files opened the current code
      would kfree the objects and things would go downhill from there.
      
      Now in reality there is no need for these lifetimes to be so intertwined,
      especailly with hotplugging of devices where we wish to remove the sysfs
      and userspace facing pieces before we can unwind the internal objects due
      to open userspace files or mmaps, so split the objects out so the struct
      device is no longer embedded and do what fbdev does and just allocate
      and remove the sysfs inodes separately.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      5bdebb18
  9. 18 10月, 2013 1 次提交
  10. 15 10月, 2013 1 次提交
  11. 10 10月, 2013 3 次提交
  12. 09 10月, 2013 2 次提交
  13. 04 10月, 2013 2 次提交
  14. 01 10月, 2013 10 次提交
  15. 25 9月, 2013 1 次提交
  16. 17 9月, 2013 4 次提交
  17. 13 9月, 2013 1 次提交
  18. 06 9月, 2013 4 次提交