1. 21 Jan, 2021 6 commits
  2. 19 Jan, 2021 12 commits
    • Lyude Paul's avatar
      drm/dp: Revert "drm/dp: Introduce EDID-based quirks" · 7c553f8b
      Lyude Paul authored
      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: default avatarLyude Paul <lyude@redhat.com>
      Acked-by: default avatarJani 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
    • Lyude Paul's avatar
      drm/i915/dp: Allow forcing specific interfaces through enable_dpcd_backlight · 2227816e
      Lyude Paul authored
      Since we now support controlling panel backlights through DPCD using
      both the standard VESA interface, and Intel's proprietary HDR backlight
      interface, we should allow the user to be able to explicitly choose
      between one or the other in the event that we're wrong about panels
      reliably reporting support for the Intel HDR interface.
      
      So, this commit adds support for this by introducing two new
      enable_dpcd_backlight options: 2 which forces i915 to only probe for the
      VESA interface, and 3 which forces i915 to only probe for the Intel
      backlight interface (might be useful if we find panels in the wild that
      report the VESA interface in their VBT, but actually only support the
      Intel backlight interface).
      
      v3:
      * Rebase
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: default avatarJani Nikula <jani.nikula@intel.com>
      Cc: thaytan@noraisin.net
      Cc: Vasily Khoruzhick <anarsoul@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210114221709.2261452-5-lyude@redhat.com
      2227816e
    • Lyude Paul's avatar
      drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now) · 4a8d7990
      Lyude Paul authored
      So-recently a bunch of laptops on the market have started using DPCD
      backlight controls instead of the traditional DDI backlight controls.
      Originally we thought we had this handled by adding VESA backlight
      control support to i915, but the story ended up being a lot more
      complicated then that.
      
      Simply put-there's two main backlight interfaces Intel can see in the
      wild. Intel's proprietary HDR backlight interface, and the standard VESA
      backlight interface. Note that many panels have been observed to report
      support for both backlight interfaces, but testing has shown far more
      panels work with the Intel HDR backlight interface at the moment.
      Additionally, the VBT appears to be capable of reporting support for the
      VESA backlight interface but not the Intel HDR interface which needs to
      be probed by setting the right magic OUI.
      
      On top of that however, there's also actually two different variants of
      the Intel HDR backlight interface. The first uses the AUX channel for
      controlling the brightness of the screen in both SDR and HDR mode, and
      the second only uses the AUX channel for setting the brightness level in
      HDR mode - relying on PWM for setting the brightness level in SDR mode.
      
      For the time being we've been using EDIDs to maintain a list of quirks
      for panels that safely do support the VESA backlight interface. Adding
      support for Intel's HDR backlight interface in addition however, should
      finally allow us to auto-detect eDP backlight controls properly so long
      as we probe like so:
      
      * If the panel's VBT reports VESA backlight support, assume it really
        does support it
      * If the panel's VBT reports DDI backlight controls:
        * First probe for Intel's HDR backlight interface
        * If that fails, probe for VESA's backlight interface
        * If that fails, assume no DPCD backlight control
      * If the panel's VBT reports any other backlight type: just assume it
        doesn't have DPCD backlight controls
      
      Changes since v4:
      * Fix checkpatch issues
      Changes since v3:
      * Stop using drm_device and use drm_i915_private instead
      * Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail
        to read the current backlight mode from the DPCD
      * s/uint8_t/u8/
      * Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight()
      * Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs()
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: default avatarJani Nikula <jani.nikula@intel.com>
      Cc: thaytan@noraisin.net
      Cc: Vasily Khoruzhick <anarsoul@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210114221709.2261452-4-lyude@redhat.com
      4a8d7990
    • Lyude Paul's avatar
      drm/i915: Keep track of pwm-related backlight hooks separately · a575c00e
      Lyude Paul authored
      Currently, every different type of backlight hook that i915 supports is
      pretty straight forward - you have a backlight, probably through PWM
      (but maybe DPCD), with a single set of platform-specific hooks that are
      used for controlling it.
      
      HDR backlights, in particular VESA and Intel's HDR backlight
      implementations, can end up being more complicated. With Intel's
      proprietary interface, HDR backlight controls always run through the
      DPCD. When the backlight is in SDR backlight mode however, the driver
      may need to bypass the TCON and control the backlight directly through
      PWM.
      
      So, in order to support this we'll need to split our backlight callbacks
      into two groups: a set of high-level backlight control callbacks in
      intel_panel, and an additional set of pwm-specific backlight control
      callbacks. This also implies a functional changes for how these
      callbacks are used:
      
      * We now keep track of two separate backlight level ranges, one for the
        high-level backlight, and one for the pwm backlight range
      * We also keep track of backlight enablement and PWM backlight
        enablement separately
      * Since the currently set backlight level might not be the same as the
        currently programmed PWM backlight level, we stop setting
        panel->backlight.level with the currently programmed PWM backlight
        level in panel->backlight.pwm_funcs->setup(). Instead, we rely
        on the higher level backlight control functions to retrieve the
        current PWM backlight level (in this case, intel_pwm_get_backlight()).
        Note that there are still a few PWM backlight setup callbacks that
        do actually need to retrieve the current PWM backlight level, although
        we no longer save this value in panel->backlight.level like before.
      
      Additionally, we drop the call to lpt_get_backlight() in
      lpt_setup_backlight(), and avoid unconditionally writing the PWM value that
      we get from it and only write it back if we're in CPU mode, and switching
      to PCH mode. The reason for this is because in the original codepath for
      this, it was expected that the intel_panel_bl_funcs->setup() hook would be
      responsible for fetching the initial backlight level. On lpt systems, the
      only time we could ever be in PCH backlight mode is during the initial
      driver load - meaning that outside of the setup() hook, lpt_get_backlight()
      will always be the callback used for retrieving the current backlight
      level. After this patch we still need to fetch and write-back the PCH
      backlight value if we're switching from CPU mode to PCH, but because
      intel_pwm_setup_backlight() will retrieve the backlight level after setup()
      using the get() hook, which always ends up being lpt_get_backlight(). Thus
      - an additional call to lpt_get_backlight() in lpt_setup_backlight() is
      made redundant.
      
      v9:
      * Drop the intel_panel_invert_pwm_level() call in lpt_setup_backlight()
      * Remove leftover detritus from lpt_setup_backlight()
      v8:
      * Go back to getting initial brightness level with
        intel_pwm_get_backlight(), the other fix we had was definitely wrong.
      v7:
      * Use panel->backlight.pwm_funcs->get() to get the backlight level in
        intel_pwm_setup_backlight(), lest we upset lockdep
      * Rebase
      * Rename intel_panel_sanitize_pwm_level() to intel_panel_invert_pwm_level()
      v6:
      * Make sure to grab connection_mutex before calling
        intel_pwm_get_backlight() in intel_pwm_setup_backlight()
      v5:
      * Fix indenting warnings from checkpatch
      v4:
      * Fix commit message
      * Remove outdated comment in intel_panel.c
      * Rename pwm_(min|max) to pwm_level_(min|max)
      * Use intel_pwm_get_backlight() in intel_pwm_setup_backlight() instead of
        indirection
      * Don't move intel_dp_aux_init_bcklight_funcs() call to bottom of
        intel_panel_init_backlight_funcs() quite yet
      v3:
      * Reuse intel_panel_bl_funcs() for pwm_funcs
      * Explain why we drop lpt_get_backlight()
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: default avatarJani Nikula <jani.nikula@intel.com>
      Cc: thaytan@noraisin.net
      Cc: Vasily Khoruzhick <anarsoul@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210114221709.2261452-3-lyude@redhat.com
      a575c00e
    • Ville Syrjälä's avatar
      drm/i915: Reuse the async_flip() hook for the async flip disable w/a · 68fd1faa
      Ville Syrjälä authored
      On some platforms we need to trigger an extra async flip with
      the async flip bit disabled, and then wait for the next vblank
      until the async flip bit off state will actually latch.
      
      Currently the w/a is just open coded for skl+ universal planes.
      Instead of doing that lets reuse the .async_flip() hook for this
      purpose since it needs to write the exact same set of registers.
      In order to do this we'll just have the caller pass in the state
      of the async flip bit explicitly.
      
      Cc: Karthik B S <karthik.b.s@intel.com>
      Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-8-ville.syrjala@linux.intel.comReviewed-by: default avatarKarthik B S <karthik.b.s@intel.com>
      68fd1faa
    • Ville Syrjälä's avatar
      drm/i915: Move the async_flip bit setup into the .async_flip() hook · 6cc3bb75
      Ville Syrjälä authored
      Set up the async flip PLANE_CTL bit directly in the
      .async_flip() hook. Neither .update_plane() nor .disable_plane()
      ever need to set this so having it done by skl_plane_ctl_crtc()
      is rather pointless.
      
      Cc: Karthik B S <karthik.b.s@intel.com>
      Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-7-ville.syrjala@linux.intel.comReviewed-by: default avatarKarthik B S <karthik.b.s@intel.com>
      6cc3bb75
    • Ville Syrjälä's avatar
      drm/i915: Add plane vfuncs to enable/disable flip_done interrupt · 8693ee2e
      Ville Syrjälä authored
      Prepare for more platforms with async flip support by turning
      the flip_done interrupt enable/disable into plane vfuncs.
      
      Cc: Karthik B S <karthik.b.s@intel.com>
      Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-6-ville.syrjala@linux.intel.comReviewed-by: default avatarKarthik B S <karthik.b.s@intel.com>
      8693ee2e
    • Ville Syrjälä's avatar
      drm/i915: Generalize the async flip capability check · 30b61720
      Ville Syrjälä authored
      Only assign the plane->async_flip() vfunc when the plane supports
      async flips. For now we keep this artificially limited to the primary
      plane since thats the only thing the legacy page flip uapi can target
      and there is no async flip support in the atomic uapi yet.
      
      Cc: Karthik B S <karthik.b.s@intel.com>
      Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-5-ville.syrjala@linux.intel.comReviewed-by: default avatarKarthik B S <karthik.b.s@intel.com>
      30b61720
    • Ville Syrjälä's avatar
      drm/i915: Drop redundant parens · 33ef04fa
      Ville Syrjälä authored
      Drop the pointless extra parens.
      
      Cc: Karthik B S <karthik.b.s@intel.com>
      Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-4-ville.syrjala@linux.intel.comReviewed-by: default avatarKarthik B S <karthik.b.s@intel.com>
      33ef04fa
    • Ville Syrjälä's avatar
      drm/i915: Fix the PHY compliance test vs. hotplug mishap · 699390f7
      Ville Syrjälä authored
      I accidentally added the compliance test hacks only to
      intel_dp_hotplug() which doesn't even get used on any DDI
      platform. Put the same crap into intel_ddi_hotplug().
      
      Cc: Imre Deak <imre.deak@intel.com>
      Fixes: 193af12c ("drm/i915: Shove the PHY test into the hotplug work")
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210114205046.8247-7-ville.syrjala@linux.intel.comReviewed-by: default avatarImre Deak <imre.deak@intel.com>
      699390f7
    • Ville Syrjälä's avatar
      drm/i915: Fix the training pattern debug print · 60920148
      Ville Syrjälä authored
      Currently we claim to use TPS7 when using TPS4. That is just
      confusing, so let's fix the debug print.
      
      And while we're touching this let's add the customary
      encoder id/name as well.
      
      v2: Add MISSING_CASE() (Manasi)
      Reviewed-by: default avatarManasi Navare <manasi.d.navare@intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210114205046.8247-2-ville.syrjala@linux.intel.com
      60920148
    • Ville Syrjälä's avatar
      drm/i915: Disable TRAINING_PATTERN_SET before stopping the TPS transmission · 147819f6
      Ville Syrjälä authored
      DP spec says:
      "The Source device shall start sending the idle pattern after
       it has cleared the Training_Pattern byte in the DPCD."
      
      Currently we do these in operations in the opposite order.
      Swap them around to match the spec.
      
      Cc: Imre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210118162107.18424-1-ville.syrjala@linux.intel.comReviewed-by: default avatarImre Deak <imre.deak@intel.com>
      147819f6
  3. 18 Jan, 2021 1 commit
  4. 15 Jan, 2021 10 commits
  5. 14 Jan, 2021 11 commits