Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 28 4月, 2021 3 次提交
  3. 31 3月, 2021 1 次提交
  5. 20 1月, 2021 1 次提交
    • L
      drm/dp: Revert "drm/dp: Introduce EDID-based quirks" · 7c553f8b
      由 Lyude Paul 提交于 
      This reverts commit 0883ce81. Originally
these quirks were added because of the issues with using the eDP
backlight interfaces on certain laptop panels, which made it impossible
to properly probe for DPCD backlight support without having a whitelist
for panels that we know have working VESA backlight control interfaces
over DPCD. As well, it should be noted it was impossible to use the
normal sink OUI for recognizing these panels as none of them actually
filled out their OUIs, hence needing to resort to checking EDIDs.

At the time we weren't really sure why certain panels had issues with
DPCD backlight controls, but we eventually figured out that there was a
second interface that these problematic laptop panels actually did work
with and advertise properly: Intel's proprietary backlight interface for
HDR panels. So far the testing we've done hasn't brought any panels to
light that advertise this interface and don't support it properly, which
means we finally have a real solution to this problem.

As a result, we now have no need for the force DPCD backlight quirk, and
furthermore this also removes the need for any kind of EDID quirk
checking in DRM. So, let's just revert it for now since we were the only
driver using this.

v3:
* Rebase
v2:
* Fix indenting error picked up by checkpatch in
  intel_edp_init_connector()
Signed-off-by: NLyude Paul <lyude@redhat.com>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Cc: thaytan@noraisin.net
Cc: Vasily Khoruzhick <anarsoul@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210114221709.2261452-6-lyude@redhat.com
      7c553f8b
  7. 18 1月, 2021 1 次提交
  9. 22 12月, 2020 4 次提交
  11. 17 11月, 2020 1 次提交
  13. 27 10月, 2020 2 次提交
  15. 13 10月, 2020 1 次提交
  17. 12 10月, 2020 1 次提交
  19. 23 9月, 2020 1 次提交
  21. 17 9月, 2020 7 次提交
  23. 01 9月, 2020 4 次提交
  25. 24 8月, 2020 1 次提交
  27. 11 8月, 2020 1 次提交
  29. 10 7月, 2020 1 次提交
  31. 02 7月, 2020 1 次提交
  33. 10 6月, 2020 1 次提交
  35. 21 5月, 2020 1 次提交
  37. 18 5月, 2020 1 次提交
  39. 14 5月, 2020 1 次提交
  41. 08 4月, 2020 1 次提交
  43. 19 3月, 2020 1 次提交
  45. 04 3月, 2020 3 次提交
    • L
      drm/i915: Force DPCD backlight mode for some Dell CML 2020 panels · ba518bbd
      由 Lyude Paul 提交于 
      According to Dell, trying to match their panels via OUI is not reliable
enough and we've been told that we should check against the EDID
instead. As well, Dell seems to have some panels that are actually
intended to switch between using PWM for backlight controls and DPCD for
backlight controls depending on whether or not the panel is in HDR or
SDR mode. Yikes.

Regardless, we need to add quirks for these so that DPCD backlight
controls get enabled by default, since without additional driver support
that's the only form of brightness control that will work. Hopefully in
the future we can remove these quirks once we have a better way of
probing for this.

Changes since v1:
* Add one more EDID per Dell's request
* Remove model number (which is possibly wrong) and replace with Dell
  CML 2020 systems
Signed-off-by: NLyude Paul <lyude@redhat.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200211183358.157448-4-lyude@redhat.comReviewed-by: NAdam Jackson <ajax@redhat.com>
      ba518bbd
    • L
      drm/i915: Force DPCD backlight mode on X1 Extreme 2nd Gen 4K AMOLED panel · 17f5d579
      由 Lyude Paul 提交于 
      The X1 Extreme is one of the systems that lies about which backlight
interface that it uses in its VBIOS as PWM backlight controls don't work
at all on this machine. It's possible that this panel could be one of
the infamous ones that can switch between PWM mode and DPCD backlight
control mode, but we haven't gotten any more details on this from Lenovo
just yet. For the time being though, making sure the backlight 'just
works' is a bit more important.

So, add a quirk to force DPCD backlight controls on for these systems
based on EDID (since this panel doesn't appear to fill in the device ID).
Hopefully in the future we'll figure out a better way of probing this.

Changes since v2:
* The bugzilla URL is deprecated, bug reporting happens on gitlab now.
  Update the messages we print to reflect this
* Also, take the opportunity to move FDO_BUG_URL out of i915_utils.c and
  into i915_utils.h so that other places which print things that aren't
  traditional errors but are worth filing bugs about, can actually use
  it.
Signed-off-by: NLyude Paul <lyude@redhat.com>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303215320.93491-1-lyude@redhat.com
      17f5d579
    • L
      drm/dp: Introduce EDID-based quirks · 0883ce81
      由 Lyude Paul 提交于 
      The whole point of using OUIs is so that we can recognize certain
devices and potentially apply quirks for them. Normally this should work
quite well, but there appears to be quite a number of laptop panels out
there that will fill the OUI but not the device ID. As such, for devices
like this I can't imagine it's a very good idea to try relying on OUIs
for applying quirks. As well, some laptop vendors have confirmed to us
that their panels have this exact issue.

So, let's introduce the ability to apply DP quirks based on EDID
identification. We reuse the same quirk bits for OUI-based quirks, so
that callers can simply check all possible quirks using
drm_dp_has_quirk().
Signed-off-by: NLyude Paul <lyude@redhat.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200211183358.157448-2-lyude@redhat.com
      0883ce81