1. 09 10月, 2018 3 次提交
    • L
      drm/i915: Fix intel_dp_mst_best_encoder() · a9f9ca33
      Lyude Paul 提交于
      Currently, i915 appears to rely on blocking modesets on
      no-longer-present MSTB ports by simply returning NULL for
      ->best_encoder(), which in turn causes any new atomic commits that don't
      disable the CRTC to fail. This is wrong however, since we still want to
      allow userspace to disable CRTCs on no-longer-present MSTB ports by
      changing the DPMS state to off and this still requires that we retrieve
      an encoder.
      
      So, fix this by always returning a valid encoder regardless of the state
      of the MST port.
      
      Changes since v1:
      - Remove mst atomic helper, since this got replaced with a much simpler
        solution
      Signed-off-by: NLyude Paul <lyude@redhat.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Link: https://patchwork.freedesktop.org/patch/msgid/20181008232437.5571-6-lyude@redhat.com
      a9f9ca33
    • L
      drm/i915: Skip vcpi allocation for MSTB ports that are gone · f67207d7
      Lyude Paul 提交于
      Since we need to be able to allow DPMS on->off prop changes after an MST
      port has disappeared from the system, we need to be able to make sure we
      can compute a config for the resulting atomic commit. Currently this is
      impossible when the port has disappeared, since the VCPI slot searching
      we try to do in intel_dp_mst_compute_config() will fail with -EINVAL.
      
      Since the only commits we want to allow on no-longer-present MST ports
      are ones that shut off display hardware, we already know that no VCPI
      allocations are needed. So, hardcode the VCPI slot count to 0 when
      intel_dp_mst_compute_config() is called on an MST port that's gone.
      
      Changes since V4:
      - Don't use mst_port_gone at all, just check whether or not the drm
        connector is registered - Daniel Vetter
      Signed-off-by: NLyude Paul <lyude@redhat.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Link: https://patchwork.freedesktop.org/patch/msgid/20181008232437.5571-5-lyude@redhat.com
      f67207d7
    • L
      drm/i915: Don't unset intel_connector->mst_port · 6ed5bb1f
      Lyude Paul 提交于
      Currently we set intel_connector->mst_port to NULL to signify that the
      MST port has been removed from the system so that we can prevent further
      action on the port such as connector probes, mode probing, etc.
      However, we're going to need access to intel_connector->mst_port in
      order to fixup ->best_encoder() so that it can always return the correct
      encoder for an MST port to prevent legacy DPMS prop changes from
      failing. This should be safe, so instead keep intel_connector->mst_port
      always set and instead just check the status of
      drm_connector->regustered to signify whether or not the connector has
      disappeared from the system.
      
      Changes since v2:
      - Add a comment to mst_port_gone (Jani Nikula)
      - Change mst_port_gone to a u8 instead of a bool, per the kernel bot.
        Apparently bool is discouraged in structs these days
      Changes since v4:
      - Don't use mst_port_gone at all! Just check if the connector is
        registered or not - Daniel Vetter
      Signed-off-by: NLyude Paul <lyude@redhat.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Link: https://patchwork.freedesktop.org/patch/msgid/20181008232437.5571-4-lyude@redhat.com
      6ed5bb1f
  2. 19 9月, 2018 1 次提交
  3. 01 9月, 2018 1 次提交
  4. 26 7月, 2018 1 次提交
  5. 21 7月, 2018 1 次提交
  6. 14 7月, 2018 2 次提交
  7. 05 7月, 2018 1 次提交
  8. 29 6月, 2018 1 次提交
  9. 19 6月, 2018 1 次提交
  10. 14 6月, 2018 1 次提交
  11. 08 4月, 2018 1 次提交
    • L
      drm/i915/dp: Send DPCD ON for MST before phy_up · be1c63c8
      Lyude Paul 提交于
      When doing a modeset where the sink is transitioning from D3 to D0 , it
      would sometimes be possible for the initial power_up_phy() to start
      timing out. This would only be observed in the last action before the
      sink went into D3 mode was intel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We
      originally thought this might be an issue with us accidentally shutting
      off the aux block when putting the sink into D3, but since the DP spec
      mandates that sinks must wake up within 1ms while we have 100ms to
      respond to an ESI irq, this didn't really add up. Turns out that the
      problem is more subtle then that:
      
      It turns out that the timeout is from us not enabling DPMS on the MST
      hub before actually trying to initiate sideband communications. This
      would cause the first sideband communication (power_up_phy()), to start
      timing out because the sink wasn't ready to respond. Afterwards, we
      would call intel_dp_sink_dpms(DRM_MODE_DPMS_ON) in
      intel_ddi_pre_enable_dp(), which would actually result in waking up the
      sink so that sideband requests would work again.
      
      Since DPMS is what lets us actually bring the hub up into a state where
      sideband communications become functional again, we just need to make
      sure to enable DPMS on the display before attempting to perform sideband
      communications.
      
      Changes since v1:
      - Remove comment above if (!intel_dp->is_mst) - vsryjala
      - Move intel_dp_sink_dpms() for MST into intel_dp_post_disable_mst() to
        keep enable/disable paths symmetrical
      - Improve commit message - dhnkrn
      Changes since v2:
      - Only send DPMS off when we're disabling the last sink, and only send
        DPMS on when we're enabling the first sink - dhnkrn
      Changes since v3:
      - Check against is_mst, not intel_dp->is_mst - dhnkrn/vsyrjala
      Signed-off-by: NLyude Paul <lyude@redhat.com>
      Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Tested-by: NLaura Abbott <labbott@redhat.com>
      Cc: stable@vger.kernel.org
      Fixes: ad260ab3 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.")
      Link: https://patchwork.freedesktop.org/patch/msgid/20180407011053.22437-1-lyude@redhat.com
      be1c63c8
  12. 10 11月, 2017 1 次提交
    • V
      drm/i915: Nuke intel_digital_port->port · 8f4f2797
      Ville Syrjälä 提交于
      Remove intel_digital_port->port and replace its users with
      intel_encoder->port. intel_encoder->port is a superset of
      intel_digital_port->port, and it works correctly even for
      MST encoders.
      
      v2: Eliminate a few dp_to_dig_port()->base.port cases too (DK)
      
      Performed with cocci:
      @@
      @@
      struct intel_digital_port {
             ...
      -       enum port port;
             ...
      }
      
      @@
      struct intel_digital_port *D;
      expression E;
      @@
      - D->port = E;
      
      @@
      struct intel_digital_port *D;
      @@
      - D->port
      + D->base.port
      
      @
      expression E;
      @@
      (
      - dp_to_dig_port(E)->port
      + dp_to_dig_port(E)->base.port
      |
      - enc_to_dig_port(E)->port
      + to_intel_encoder(E)->port
      )
      
      @@
      expression E;
      @@
      - to_intel_encoder(&E->base)
      + E
      
      @@
      struct intel_digital_port *D;
      identifier I, M;
      @@
        I = &D->base
      <...
      (
      - D->base.M
      + I->M
      |
      - &D->base
      + I
      )
      ...>
      
      @@
      identifier D;
      expression E;
      identifier M;
      @@
       D = enc_to_dig_port(&E->base)
      <...
      (
      - D->base.M
      + E->M
      |
      - &D->base
      + E
      )
      ...>
      
      @@
      identifier D, DP;
      expression E;
      identifier M;
      @@
       DP = enc_to_intel_dp(&E->base)
      <...
      (
      - dp_to_dig_port(DP)->base.M
      + E->M
      |
      - &dp_to_dig_port(DP)->base
      + E
      )
      ...>
      
      @@
      expression E;
      identifier M;
      @@
      (
      - enc_to_dig_port(&E->base)->base.M
      + E->M
      |
      - enc_to_dig_port(&E->base)->base
      + E
      |
      - enc_to_mst(&E->base)->primary->base.port
      + E->port
      )
      
      @@
      expression E;
      identifier D;
      @@
      - struct intel_digital_port *D = E;
      ... when != D
      
      Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Acked-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171109152434.32074-1-ville.syrjala@linux.intel.com
      8f4f2797
  13. 01 11月, 2017 1 次提交
  14. 31 10月, 2017 3 次提交
  15. 28 10月, 2017 1 次提交
  16. 25 10月, 2017 1 次提交
    • V
      drm/i915: Adjust system agent voltage on CNL if required by DDI ports · 53e9bf5e
      Ville Syrjälä 提交于
      On CNL we may need to bump up the system agent voltage not only due
      to CDCLK but also when driving DDI port with a sufficiently high clock.
      To that end start tracking the minimum acceptable voltage for each crtc.
      We do the tracking via crtcs because we don't have any kind of encoder
      state. Also there's no downside to doing it this way, and it matches how
      we track cdclk requirements on account of pixel rate.
      
      v2: Allow disabled crtcs to use the min voltage
          Add IS_CNL check to intel_ddi_compute_min_voltage() since
          we're using CNL specific values there
          s/intel_compute_min_voltage/cnl_compute_min_voltage/ since
          the function makes hw specific assumptions about the voltage
          values
      v3: Drop the test hack leftovers from skl_modeset_calc_cdclk()
      v4: s/voltage/voltage_level/ (Rodrigo)
          Replace DPLL DVFS FIXMEs with an explanation why we don't
          do anything there (Rodrigo)
      
      Cc: Mika Kahola <mika.kahola@intel.com>
      Cc: Manasi Navare <manasi.d.navare@intel.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171024095216.1638-9-ville.syrjala@linux.intel.com
      53e9bf5e
  17. 17 10月, 2017 1 次提交
  18. 13 10月, 2017 1 次提交
  19. 05 10月, 2017 1 次提交
  20. 25 9月, 2017 2 次提交
  21. 22 8月, 2017 1 次提交
  22. 11 8月, 2017 1 次提交
  23. 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
  24. 06 7月, 2017 2 次提交
  25. 29 5月, 2017 1 次提交
  26. 04 5月, 2017 1 次提交
  27. 12 4月, 2017 2 次提交
  28. 11 4月, 2017 1 次提交
  29. 23 3月, 2017 1 次提交
  30. 03 3月, 2017 1 次提交
  31. 02 3月, 2017 1 次提交