Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 23 5月, 2016 3 次提交
    • V
      drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed · 0c2fb7c6
      由 Ville Syrjälä 提交于 
      To save a bit of power, let's try to turn off the TMDS output buffers
in DP++ adaptors when we're not driving the port.

v2: Let's not forget DDI, toss in a debug message while at it
v3: Just do the TMDS output control based on adaptor type. With the
    helper getting passed the type, we wouldn't actually have to
    check at all in the driver, but the check eliminates the debug
    output more honest

Cc: stable@vger.kernel.org
Cc: Tore Anderson <tore@fud.no>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1462216105-20881-4-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NShashank Sharma <shashank.sharma@intel.com>
(cherry picked from commit b2ccb822)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      0c2fb7c6
    • V
      drm/i915: Respect DP++ adaptor TMDS clock limit · c578d152
      由 Ville Syrjälä 提交于 
      Try to detect the max TMDS clock limit for the DP++ adaptor (if any)
and take it into account when checking the port clock.

Note that as with the sink (HDMI vs. DVI) TMDS clock limit we'll ignore
the adaptor TMDS clock limit in the modeset path, in case users are
already "overclocking" their TMDS links. One subtle change here is that
we'll have to respect the adaptor TMDS clock limit when we decide whether
to do 12bpc or 8bpc, otherwise we might end up picking 12bpc and
accidentally driving the TMDS link out of spec even when the user chose
a mode that fits wihting the limits at 8bpc. This means you can't
"overclock" your DP++ dongle at 12bpc anymore, but you can continue to
do so at 8bpc.

Note that for simplicity we'll use the I2C access method for all dual
mode adaptors including type 2. Otherwise we'd have to start mixing
DP AUX and HDMI together. In the future we may need to do that if we
come across any board designs that don't hook up the DDC pins to the
DP++ connectors. Such boards would obviously only work with type 2
dual mode adaptors, and not type 1.

v2: Store adaptor type under indel_hdmi->dp_dual_mode
    Deal with DRM_DP_DUAL_MODE_UNKNOWN
    Pass adaptor type to drm_dp_dual_mode_max_tmds_clock(),
    and use it for type1 adaptors as well

Cc: stable@vger.kernel.org
Reported-by: NTore Anderson <tore@fud.no>
Fixes: 7a0baa62 ("Revert "drm/i915: Disable 12bpc hdmi for now"")
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1462216105-20881-3-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NShashank Sharma <shashank.sharma@intel.com>
(cherry picked from commit b1ba124d)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      c578d152
    • V
      drm: Add helper for DP++ adaptors · b3daa5ef
      由 Ville Syrjälä 提交于 
      Add a helper which aids in the identification of DP dual mode
(aka. DP++) adaptors. There are several types of adaptors
specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI

Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 adaptors
may go as high as 300MHz and they provide a register informing the
source device what the actual limit is. Supposedly also type 1 adaptors
may optionally implement this register. This TMDS clock limit is the
main reason why we need to identify these adaptors.

Type 1 adaptors provide access to their internal registers and the sink
DDC bus through I2C. Type 2 adaptors provide this access both via I2C
and I2C-over-AUX. A type 2 source device may choose to implement either
of these methods. If a source device implements the I2C-over-AUX
method, then the driver will obviously need specific support for such
adaptors since the port is driven like an HDMI port, but DDC
communication happes over the AUX channel.

This helper should be enough to identify the adaptor type (some
type 1 DVI adaptors may be a slight exception) and the maximum TMDS
clock limit. Another feature that may be available is control over
the TMDS output buffers on the adaptor, possibly allowing for some
power saving when the TMDS link is down.

Other user controllable features that may be available in the adaptors
are downstream i2c bus speed control when using i2c-over-aux, and
some control over the CEC pin. I chose not to provide any helper
functions for those since I have no use for them in i915 at this time.
The rest of the registers in the adaptor are mostly just information,
eg. IEEE OUI, hardware and firmware revision, etc.

v2: Pass adaptor type to helper functions to ease driver implementation
    Fix a bunch of typoes (Paulo)
    Add DRM_DP_DUAL_MODE_UNKNOWN for the case where we don't (yet) know
    the type (Paulo)
    Reject 0x00 and 0xff DP_DUAL_MODE_MAX_TMDS_CLOCK values (Paulo)
    Adjust drm_dp_dual_mode_detect() type2 vs. type1 detection to
    ease future LSPCON enabling
    Remove the unused DP_DUAL_MODE_LAST_RESERVED define
v3: Fix kernel doc function argument descriptions (Jani)
    s/NONE/UNKNOWN/ in drm_dp_dual_mode_detect() docs
    Add kernel doc for enum drm_dp_dual_mode_type
    Actually build the docs
    Fix more typoes
v4: Adjust code indentation of type2 adaptor detection (Shashank)
    Add debug messages for failurs cases (Shashank)
v5: EXPORT_SYMBOL(drm_dp_dual_mode_read) (Paulo)

Cc: stable@vger.kernel.org
Cc: Tore Anderson <tore@fud.no>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> (v4)
Link: http://patchwork.freedesktop.org/patch/msgid/1462542412-25533-1-git-send-email-ville.syrjala@linux.intel.com
(cherry picked from commit ede53344)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      b3daa5ef
  3. 25 4月, 2016 1 次提交
  5. 24 4月, 2016 3 次提交
  7. 23 4月, 2016 2 次提交
    • V
      drm/i915: Make RPS EI/thresholds multiple of 25 on SNB-BDW · 8a292d01
      由 Ville Syrjälä 提交于 
      Somehow my SNB GT1 (Dell XPS 8300) gets very unhappy around
GPU hangs if the RPS EI/thresholds aren't suitably aligned.
It seems like scheduling/timer interupts stop working somehow
and things get stuck eg. in usleep_range().

I bisected the problem down to
commit 8a586437 ("drm/i915/skl: Restructured the gen6_set_rps_thresholds function")
I observed that before all the values were at least multiples of 25,
but afterwards they are not. And rounding things up to the next multiple
of 25 does seem to help, so lets' do that. I also tried roundup(..., 5)
but that wasn't sufficient. Also I have no idea if we might need this sort of
thing on gen9+ as well.

These are the original EI/thresholds:
 LOW_POWER
  GEN6_RP_UP_EI          12500
  GEN6_RP_UP_THRESHOLD   11800
  GEN6_RP_DOWN_EI        25000
  GEN6_RP_DOWN_THRESHOLD 21250
 BETWEEN
  GEN6_RP_UP_EI          10250
  GEN6_RP_UP_THRESHOLD    9225
  GEN6_RP_DOWN_EI        25000
  GEN6_RP_DOWN_THRESHOLD 18750
 HIGH_POWER
  GEN6_RP_UP_EI           8000
  GEN6_RP_UP_THRESHOLD    6800
  GEN6_RP_DOWN_EI        25000
  GEN6_RP_DOWN_THRESHOLD 15000

These are after 8a586437:
 LOW_POWER
  GEN6_RP_UP_EI          12500
  GEN6_RP_UP_THRESHOLD   11875
  GEN6_RP_DOWN_EI        25000
  GEN6_RP_DOWN_THRESHOLD 21250
 BETWEEN
  GEN6_RP_UP_EI          10156
  GEN6_RP_UP_THRESHOLD    9140
  GEN6_RP_DOWN_EI        25000
  GEN6_RP_DOWN_THRESHOLD 18750
 HIGH_POWER
  GEN6_RP_UP_EI           7812
  GEN6_RP_UP_THRESHOLD    6640
  GEN6_RP_DOWN_EI        25000
  GEN6_RP_DOWN_THRESHOLD 15000

And these are what we have after this patch:
 LOW_POWER
  GEN6_RP_UP_EI          12500
  GEN6_RP_UP_THRESHOLD   11875
  GEN6_RP_DOWN_EI        25000
  GEN6_RP_DOWN_THRESHOLD 21250
 BETWEEN
  GEN6_RP_UP_EI          10175
  GEN6_RP_UP_THRESHOLD    9150
  GEN6_RP_DOWN_EI        25000
  GEN6_RP_DOWN_THRESHOLD 18750
 HIGH_POWER
  GEN6_RP_UP_EI           7825
  GEN6_RP_UP_THRESHOLD    6650
  GEN6_RP_DOWN_EI        25000
  GEN6_RP_DOWN_THRESHOLD 15000

Cc: stable@vger.kernel.org
Cc: Akash Goel <akash.goel@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Testcase: igt/kms_pipe_crc_basic/hang-read-crc-pipe-B
Fixes: 8a586437 ("drm/i915/skl: Restructured the gen6_set_rps_thresholds function")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1461159836-9108-1-git-send-email-ville.syrjala@linux.intel.comAcked-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NPatrik Jakobsson <patrik.jakobsson@linux.intel.com>
      8a292d01
    • S
      drm/i915: Fake HDMI live status · 4f4a8185
      由 Shashank Sharma 提交于 
      This patch does the following:
- Fakes live status of HDMI as connected (even if that's not).
  While testing certain (monitor + cable) combinations with
  various intel  platforms, it seems that live status register
  doesn't work reliably on some older devices. So limit the
  live_status check for HDMI detection, only for platforms
  from gen7 onwards.

V2: restrict faking live_status to certain platforms
V3: (Ville)
   - keep the debug message for !live_status case
   - fix indentation of comment
   - remove "warning" from the debug message

    (Jani)
   - Change format of fix details in the commit message

Fixes: 237ed86c ("drm/i915: Check live status before reading edid")
Cc: stable@vger.kernel.org # v4.4
Suggested-by: NVille Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: NShashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1461237606-16491-1-git-send-email-shashank.sharma@intel.comSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      4f4a8185
  9. 22 4月, 2016 9 次提交
  11. 21 4月, 2016 1 次提交
  13. 20 4月, 2016 10 次提交
  15. 19 4月, 2016 11 次提交