1. 06 12月, 2017 1 次提交
  2. 23 11月, 2017 1 次提交
    • V
      drm/edid: Allow HDMI infoframe without VIC or S3D · f1781e9b
      Ville Syrjälä 提交于
      Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from
      3D to 2D mode in a timely fashion if the source simply stops sending the
      HDMI infoframe. The suggested workaround is to keep sending the
      infoframe even when strictly not necessary (ie. no VIC and no S3D).
      HDMI 1.4 does allow for this behaviour, stating that sending the
      infoframe is optional in this case.
      
      The infoframe was first specified in HDMI 1.4, so in theory sinks
      predating that may not appreciate us sending an uknown infoframe
      their way. To avoid regressions let's try to determine if the sink
      supports the infoframe or not. Unfortunately there's no direct way
      to do that, so instead we'll just check if we managed to parse any
      HDMI 1.4 4k or stereo modes from the EDID, and if so we assume the
      sink will accept the infoframe. Also if the EDID contains the HDMI
      2.0 HDMI Forum VSDB we can assume the sink is prepared to receive
      the infoframe.
      
      v2: Fix getting has_hdmi_infoframe from display_info
          Always fail constructing the infoframe if the display
          possibly can't handle it
      
      Cc: Shashank Sharma <shashank.sharma@intel.com>
      Cc: Andrzej Hajda <a.hajda@samsung.com>
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NShashank Sharma <shashank.sharma@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171113170427.4150-3-ville.syrjala@linux.intel.com
      f1781e9b
  3. 21 11月, 2017 1 次提交
  4. 07 11月, 2017 1 次提交
  5. 08 8月, 2017 2 次提交
    • D
      drm: Nuke drm_atomic_helper_connector_dpms · 7d902c05
      Daniel Vetter 提交于
      It's dead code, the core handles all this directly now.
      
      The only special case is nouveau and tda988x which used one function
      for both legacy modeset code and -nv50 atomic world instead of 2
      vtables. But amounts to exactly the same.
      
      v2: Rebase over the panel/brideg refactorings in stm/ltdc.
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Cc: Archit Taneja <architt@codeaurora.org>
      Cc: Andrzej Hajda <a.hajda@samsung.com>
      Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
      Cc: Peter Senna Tschudin <peter.senna@collabora.com>
      Cc: Martin Donnelly <martin.donnelly@ge.com>
      Cc: Martyn Welch <martyn.welch@collabora.co.uk>
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Sean Paul <seanpaul@chromium.org>
      Cc: David Airlie <airlied@linux.ie>
      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: Kukjin Kim <kgene@kernel.org>
      Cc: Krzysztof Kozlowski <krzk@kernel.org>
      Cc: Stefan Agner <stefan@agner.ch>
      Cc: Alison Wang <alison.wang@freescale.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Philipp Zabel <p.zabel@pengutronix.de>
      Cc: CK Hu <ck.hu@mediatek.com>
      Cc: Matthias Brugger <matthias.bgg@gmail.com>
      Cc: Neil Armstrong <narmstrong@baylibre.com>
      Cc: Carlo Caione <carlo@caione.org>
      Cc: Kevin Hilman <khilman@baylibre.com>
      Cc: Marek Vasut <marex@denx.de>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Eric Anholt <eric@anholt.net>
      Cc: Mark Yao <mark.yao@rock-chips.com>
      Cc: Heiko Stuebner <heiko@sntech.de>
      Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
      Cc: Vincent Abriou <vincent.abriou@st.com>
      Cc: Yannick Fertre <yannick.fertre@st.com>
      Cc: Philippe Cornu <philippe.cornu@st.com>
      Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
      Cc: Chen-Yu Tsai <wens@csie.org>
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Cc: Jonathan Hunter <jonathanh@nvidia.com>
      Cc: Jyri Sarha <jsarha@ti.com>
      Cc: Gerd Hoffmann <kraxel@redhat.com>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Lars-Peter Clausen <lars@metafoo.de>
      Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Cc: Jeffy Chen <jeffy.chen@rock-chips.com>
      Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
      Cc: Yakir Yang <kuankuan.y@gmail.com>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: Jose Abreu <Jose.Abreu@synopsys.com>
      Cc: Romain Perier <romain.perier@collabora.com>
      Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
      Cc: Xinliang Liu <z.liuxinliang@hisilicon.com>
      Cc: Alexey Brodkin <abrodkin@synopsys.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Rongrong Zou <zourongrong@gmail.com>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Hai Li <hali@codeaurora.org>
      Cc: "Noralf Trønnes" <noralf@tronnes.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-samsung-soc@vger.kernel.org
      Cc: intel-gfx@lists.freedesktop.org
      Cc: linux-mediatek@lists.infradead.org
      Cc: linux-amlogic@lists.infradead.org
      Cc: nouveau@lists.freedesktop.org
      Cc: linux-renesas-soc@vger.kernel.org
      Cc: linux-rockchip@lists.infradead.org
      Cc: linux-tegra@vger.kernel.org
      Cc: virtualization@lists.linux-foundation.org
      Cc: zain wang <wzz@rock-chips.com>
      Cc: Baoyou Xie <baoyou.xie@linaro.org>
      Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
      Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170725080122.20548-8-daniel.vetter@ffwll.chAcked-by: NNeil Armstrong <narmstrong@baylibre.com>
      Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
      Acked-by: NPhilipp Zabel <p.zabel@pengutronix.de>
      Acked-by: NArchit Taneja <architt@codeaurora.org>
      Tested-by: Philippe Cornu <philippe.cornu@st.com> (on stm)
      Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Acked-by: NShawn Guo <shawnguo@kernel.org>
      Acked-by: NShawn Guo <shawnguo@kernel.org>
      Acked-by: NNoralf Trønnes <noralf@tronnes.org>
      Acked-by: NVincent Abriou <vincent.abriou@st.com>
      7d902c05
    • D
      drm: Nuke drm_atomic_helper_connector_set_property · 482b0e3c
      Daniel Vetter 提交于
      It's dead code, the core handles all this directly now. This also
      allows us to unexport drm_atomic_helper_connector_set_property.
      
      The only special case is nouveau which used one function for both
      pre-nv50 legacy modeset code and post-nv50 atomic world instead of 2
      vtables. But amounts to exactly the same.
      
      What is rather strange here is how few drivers set this up, I suspect
      the earlier patch to handle properties in the core did end up fixing a
      pile of possible issues.
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Sean Paul <seanpaul@chromium.org>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
      Cc: Vincent Abriou <vincent.abriou@st.com>
      Cc: Eric Anholt <eric@anholt.net>
      Cc: intel-gfx@lists.freedesktop.org
      Cc: nouveau@lists.freedesktop.org
      Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170725080122.20548-7-daniel.vetter@ffwll.chAcked-by: NVincent Abriou <vincent.abriou@st.com>
      482b0e3c
  6. 15 7月, 2017 1 次提交
    • S
      drm: handle HDMI 2.0 VICs in AVI info-frames · 0c1f528c
      Shashank Sharma 提交于
      HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
      For any other mode, the VIC filed in AVI infoframes should be 0.
      HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
      extended to (VIC 1-107).
      
      This patch adds a bool input variable, which indicates if the connected
      sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
      HDMI 2.0 VIC to a HDMI 1.4 sink.
      
      This patch touches all drm drivers, who are callers of this function
      drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
      no change in current behavior, is_hdmi2 is kept as false.
      
      In case of I915 driver, this patch:
      - checks if the connected display is HDMI 2.0.
      - HDMI infoframes carry one of this two type of information:
      	- VIC for 4K modes for HDMI 1.4 sinks
      	- S3D information for S3D modes
        As CEA-861-F has already defined VICs for 4K videomodes, this
        patch doesn't allow sending HDMI infoframes for HDMI 2.0 sinks,
        until the mode is 3D.
      
      Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
      Cc: Jose Abreu <jose.abreu@synopsys.com>
      Cc: Andrzej Hajda <a.hajda@samsung.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      
      PS: This patch touches a few lines in few files, which were
      already above 80 char, so checkpatch gives 80 char warning again.
      - gpu/drm/omapdrm/omap_encoder.c
      - gpu/drm/i915/intel_sdvo.c
      
      V2: Rebase, Added r-b from Andrzej
      V3: Addressed review comment from Ville:
      	- Do not send VICs in both AVI-IF and HDMI-IF
      	  send only one of it.
      V4: Rebase
      V5: Added r-b from Neil.
          Addressed review comments from Ville
          - Do not block HDMI vendor IF, instead check for VIC while
            handling AVI infoframes
      V6: Rebase
      V7: Rebase
      Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
      Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
      Signed-off-by: NShashank Sharma <shashank.sharma@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-2-git-send-email-shashank.sharma@intel.comSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      0c1f528c
  7. 09 5月, 2017 2 次提交
  8. 10 4月, 2017 1 次提交
  9. 10 2月, 2017 2 次提交
  10. 27 1月, 2017 1 次提交
  11. 06 1月, 2017 1 次提交
  12. 18 12月, 2016 1 次提交
  13. 20 9月, 2016 4 次提交
  14. 01 7月, 2016 1 次提交
  15. 22 6月, 2016 2 次提交
  16. 09 6月, 2016 1 次提交
  17. 01 6月, 2016 1 次提交
  18. 26 2月, 2016 6 次提交
  19. 03 11月, 2015 4 次提交
  20. 03 8月, 2015 2 次提交
  21. 08 6月, 2015 1 次提交
  22. 19 3月, 2015 1 次提交
  23. 05 2月, 2015 1 次提交
  24. 28 1月, 2015 1 次提交
    • A
      drm/bridge: make bridge registration independent of drm flow · 3d3f8b1f
      Ajay Kumar 提交于
      Currently, third party bridge drivers(ptn3460) are dependent
      on the corresponding encoder driver init, since bridge driver
      needs a drm_device pointer to finish drm initializations.
      The encoder driver passes the drm_device pointer to the
      bridge driver. Because of this dependency, third party drivers
      like ptn3460 doesn't adhere to the driver model.
      
      In this patch, we reframe the bridge registration framework
      so that bridge initialization is split into 2 steps, and
      bridge registration happens independent of drm flow:
      --Step 1: gather all the bridge settings independent of drm and
      	  add the bridge onto a global list of bridges.
      --Step 2: when the encoder driver is probed, call drm_bridge_attach
      	  for the corresponding bridge so that the bridge receives
      	  drm_device pointer and continues with connector and other
      	  drm initializations.
      
      The old set of bridge helpers are removed, and a set of new helpers
      are added to accomplish the 2 step initialization.
      
      The bridge devices register themselves onto global list of bridges
      when they get probed by calling "drm_bridge_add".
      
      The parent encoder driver waits till the bridge is available
      in the lookup table(by calling "of_drm_find_bridge") and then
      continues with its initialization.
      
      The encoder driver should also call "drm_bridge_attach" to pass
      on the drm_device to the bridge object.
      
      drm_bridge_attach inturn calls "bridge->funcs->attach" so that
      bridge can continue with drm related initializations.
      Signed-off-by: NAjay Kumar <ajaykumar.rs@samsung.com>
      Acked-by: NInki Dae <inki.dae@samsung.com>
      Tested-by: NRahul Sharma <rahul.sharma@samsung.com>
      Tested-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
      Tested-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Tested-by: NSjoerd Simons <sjoerd.simons@collabora.co.uk>
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      3d3f8b1f