Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 27 6月, 2013 3 次提交
  3. 20 5月, 2013 1 次提交
  5. 09 4月, 2013 1 次提交
  7. 04 1月, 2013 1 次提交
  9. 03 1月, 2013 1 次提交
  11. 23 10月, 2012 1 次提交
    • D
      drm: extract dp link train delay functions from radeon · 1a644cd4
      由 Daniel Vetter 提交于 
      This requires a few changes since that dpcd value is above the
range currently cached by radeon. I've check the dp specs, and
above 0xf there's a big gap and nothing that looks like we should
cache it while a given device is plugged in. It's also the same value
that i915.ko uses.

Hence extend the various dpcd arrays in the radeon driver, use
proper symbolic constants where applicable (one place overallocated
the dpcd array to 25 bytes). Then also drop the rd_interval cache -
radeon_dp_link_train_init re-reads the dpcd block, so the values we'll
consume in train_cr and train_ce will always be fresh.

To avoid needless diff-churn, #define the old size of dpcd as the new
one and keep it around.

v2: Alex Deucher noticed one place where I've forgotten to replace 8
with DP_RECEIVER_CAP_SIZE.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      1a644cd4
  13. 03 10月, 2012 2 次提交
  15. 27 9月, 2012 2 次提交
    • A
      drm/radeon: restore backlight level on resume · bced76f2
      由 Alex Deucher 提交于 
      Restore the backlight level on resume.  Some systems
need to explicitly restore the backlight level on
resume.

Fixes panel resume on my Trinity laptop and may fix the
following bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=43829
https://bugzilla.kernel.org/show_bug.cgi?id=46241Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      bced76f2
    • A
      drm/radeon: work around KMS modeset limitations in PLL allocation (v2) · 57b35e29
      由 Alex Deucher 提交于 
      Since the current KMS API sets the mode independantly on
each crtc, we may end up with resource conflicts.  The PLL
allocation is one of those cases.  In the following example
we have 3 crtcs in use driving 2 DVI connectors and 1 DP
connector.  On the initial kernel modeset for fbdev, the
display topology ends up as follows:

crtc0 -> DP-0
crtc1 -> DVI-0
crtc2 -> DVI-1

Because this is the first modeset, all of the PLLs are
available as none have been assigned.  So we end up with
the following:

crtc0 uses DCPLL
crtc1 uses PPLL2
crtc2 uses PPLL1

When X starts, it assigns a different topology:

crtc0 -> DVI-0
crtc1 -> DP-0
crtc2 -> DVI-1

However, since the KMS API is per crtc, we set the mode on each
crtc independantly.  When it comes time to set the mode on crtc0,
the topology for crtc1 and crtc2 are still intact.  crtc1 and
crtc2 are already assigned PPLL2 and PPLL1 so when it comes time
to set the mode on crtc0, crtc1 and crtc2 have not been torn down
yet, so there appears to be no PLLs available.  In reality, we
are reconfiguring the entire display topology, however, since
each crtc is handled independantly, we don't know that in the
driver at each crtc mode set time.

This patch checks to see if the same connector is being driven by
another crtc, and if so, uses the PLL already associated with it.

v2: store connector in the radeon crtc struct, simplify checking.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      57b35e29
  17. 21 9月, 2012 6 次提交
  19. 13 8月, 2012 1 次提交
  21. 20 7月, 2012 1 次提交
  23. 17 5月, 2012 2 次提交
  25. 03 5月, 2012 1 次提交
  27. 01 5月, 2012 2 次提交
  29. 24 4月, 2012 1 次提交
  31. 21 3月, 2012 1 次提交
  33. 07 3月, 2012 1 次提交
  35. 25 1月, 2012 3 次提交
  37. 16 11月, 2011 1 次提交
  39. 02 11月, 2011 4 次提交
  41. 10 10月, 2011 1 次提交
  43. 15 8月, 2011 1 次提交
  45. 04 8月, 2011 1 次提交
    • T
      drm/radeon: Extended DDC Probing for Connectors with Improperly Wired DDC... · e384fab8
      由 Thomas Reim 提交于 
      drm/radeon: Extended DDC Probing for Connectors with Improperly Wired DDC Lines (here: Asus M2A-VM HDMI)

    Some integrated ATI Radeon chipset implementations with add-on HDMI card
    (e. g. Asus M2A-VM HDMI) indicate the availability of a DDC even
    when the add-on card is not plugged in or HDMI is disabled in BIOS setup.
    In this case, drm_get_edid() and drm_edid_block_valid() periodically
    dump data and kernel errors into system log files and onto terminals.
    For these connectors DDC probing is extended by a check for a correct
    EDID header. Only in case a valid EDID header is also found, the
    (HDMI or DVI) connector will be used by the Radeon driver. This prevents
    the kernel driver from useless flooding of logs and terminal sessions with
    EDID dumps and error messages.
    This patch adds a flag 'requires_extended_probe' to the radeon_connector
    structure. In function radeon_connector_needs_extended_probe() this flag
    can be set on a chipset family/vendor/connector type specific basis.
    In addition, function radeon_ddc_probe() has been adapted to perform
    extended DDC probing if required by the connector's flag.
    Requires function drm_edid_header_is_valid() in DRM module provided by
    [PATCH] drm: Separate EDID Header Check from EDID Block Check.

    Tested for kernel 2.6.35, 2.6.38 and 3.0 on Asus M2A-VM HDMI board

    BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=668196
    BugLink: http://bugs.launchpad.net/bugs/7228066

Cc: <stable@kernel.org>
Signed-off-by: NThomas Reim <reimth@gmail.com>
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
Acked-by: NStephen Michaels <Stephen.Micheals@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      e384fab8
  47. 17 6月, 2011 1 次提交