Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 25 3月, 2019 1 次提交
  3. 07 2月, 2019 2 次提交
  5. 01 2月, 2019 2 次提交
  7. 24 1月, 2019 2 次提交
  9. 18 1月, 2019 2 次提交
  11. 16 1月, 2019 1 次提交
  13. 14 1月, 2019 1 次提交
  15. 12 1月, 2019 1 次提交
  17. 11 1月, 2019 1 次提交
    • V
      drm/edid: Pass connector to AVI infoframe functions · 13d0add3
      由 Ville Syrjälä 提交于 
      Make life easier for drivers by simply passing the connector
to drm_hdmi_avi_infoframe_from_display_mode() and
drm_hdmi_avi_infoframe_quant_range(). That way drivers don't
need to worry about is_hdmi2_sink mess.

v2: Make is_hdmi2_sink() return true for sil-sii8620
    Adapt to omap/vc4 changes

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com>
Cc: Archit Taneja <architt@codeaurora.org>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: CK Hu <ck.hu@mediatek.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Sandy Huang <hjc@rock-chips.com>
Cc: "Heiko Stübner" <heiko@sntech.de>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: amd-gfx@lists.freedesktop.org
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: linux-tegra@vger.kernel.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Acked-by: NRussell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190108172828.15184-1-ville.syrjala@linux.intel.com
      13d0add3
  19. 10 1月, 2019 1 次提交
  21. 09 1月, 2019 7 次提交
  23. 19 12月, 2018 1 次提交
  25. 30 11月, 2018 1 次提交
  27. 25 11月, 2018 1 次提交
  29. 20 11月, 2018 1 次提交
  31. 16 11月, 2018 1 次提交
  33. 05 11月, 2018 1 次提交
  35. 30 10月, 2018 4 次提交
  37. 29 10月, 2018 2 次提交
    • D
      drm/bridge: ti-sn65dsi86: Remove the mystery delay · c2bfc223
      由 Douglas Anderson 提交于 
      Let's solve the mystery of commit bf1178c9 ("drm/bridge:
ti-sn65dsi86: Add mystery delay to enable()").  Specifically the
reason we needed that mystery delay is that we weren't paying
attention to HPD.

Looking at the datasheet for the same panel that was tested for the
original commit, I see there's a timing "t3" that times from power on
to the aux channel being operational.  This time is specced as 0 - 200
ms.  The datasheet says that the aux channel is operational at exactly
the same time that HPD is asserted.

Scoping the signals on this board showed that HPD was asserted 84 ms
after power was asserted.  That very closely matches the magic 70 ms
delay that we had.  ...and actually, in my testing the 70 ms wasn't
quite enough of a delay and some percentage of the time the display
didn't come up until I bumped it to 100 ms (presumably 84 ms would
have worked too).

To solve this, we tried to hook up the HPD signal in the bridge.
...but in doing so we found that that the bridge didn't report that
HPD was asserted until ~280 ms after we powered it (!).  This is
explained by looking at the sn65dsi86 datasheet section "8.4.5.1 HPD
(Hot Plug/Unplug Detection)".  Reading there we see that the bridge
isn't even intended to report HPD until 100 ms after it's asserted.
...but that would have left us at 184 ms.  The extra 100 ms
(presumably) comes from this part in the datasheet:

> The HPD state machine operates off an internal ring oscillator. The
> ring oscillator frequency will vary [ ... ]. The min/max range in
> the HPD State Diagram refers to the possible times based off
> variation in the ring oscillator frequency.

Given that the 280 ms we'll end up delaying if we hook up HPD is
_slower_ than the 200 ms we could just hardcode, for now we'll solve
the problem by just hardcoding a 200 ms delay in the panel driver
using the patch in this series ("drm/panel: simple: Support panels
with HPD where HPD isn't connected").

If we later find a panel that needs to use this bridge where we need
HPD then we'll have to come up with some new code to handle it.  Given
the silly debouncing in the bridge chip, though, it seems unlikely.

One last note is that I tried to solve this through another way: In
ti_sn_bridge_enable() I tried to use various combinations of
dp_dpcd_writeb() and dp_dpcd_readb() to detect when the aux channel
was up.  In theory that would let me detect _exactly_ when I could
continue and do link training.  Unfortunately even if I did an aux
transfer w/out waiting I couldn't see any errors.  Possibly I could
keep looping over link training until it came back with success, but
that seemed a little overly hacky to me.
Reviewed-by: NSean Paul <sean@poorly.run>
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-4-dianders@chromium.org
      c2bfc223
    • E
      drm/bridge: analogix_dp: Fix misleading indentation reported by smatch · 29305d7e
      由 Enric Balletbo i Serra 提交于 
      This patch avoids that building the bridge/analogix source code with
smatch triggers complaints about inconsistent indenting. It also fixes
a typo in DRM_ERROR message, attch is replaced for attach.
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016095336.15656-1-enric.balletbo@collabora.com
      29305d7e
  39. 06 10月, 2018 1 次提交
    • D
      drm/atomic-helper: Unexport drm_atomic_helper_best_encoder · 297e30b5
      由 Daniel Vetter 提交于 
      It's the default. The exported version was kinda a transition state,
before we made this the default.

To stop new atomic drivers from using it (instead of just relying on
the default) let's unexport it.

v2: rename the default implementation to a more fitting name and add a
comment (Laurent)
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: David Airlie <airlied@linux.ie>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Archit Taneja <architt@codeaurora.org>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Jernej Skrabec <jernej.skrabec@siol.net>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Pierre-Hugues Husson <phh@phh.me>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181004202446.22905-3-daniel.vetter@ffwll.ch
      297e30b5
  41. 28 9月, 2018 1 次提交
  43. 25 9月, 2018 1 次提交
  45. 13 9月, 2018 1 次提交
  47. 27 8月, 2018 1 次提交
  49. 16 8月, 2018 1 次提交
  51. 15 8月, 2018 1 次提交