[Intel-gfx] [PATCH] drm/i915/skl: Handle eDP from generic crtc_compute_clock vfunc
Damien Lespiau
damien.lespiau at intel.com
Wed May 13 09:56:17 PDT 2015
On Wed, May 13, 2015 at 05:40:44PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>
> Since commit 4978cc93d9ac240b435ce60431aef24239b4c270 started clearing
> dpll state and recomputing it via crtc_compute_clock (and probably some
> other commit which triggered pipe config checking), modesetting is now
> constantly triggering warnings about dpll_hw_state.ctrl1 mismatch.
>
> Reason is crtc_compute_clock calls skl_ddi_pll_select which does not do
> anything for eDP, leaving the ctrl1 state at the default of zero.
>
> This potentially hacky fix makes skl_ddi_pll_select call
> skl_edp_set_pll_config which fixes the problem for me.
>
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> Cc: Damien Lespiau <damien.lespiau at intel.com>
> Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira at intel.com>
> Cc: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
> Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
> Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
Nop! (at least I really don't think so).
As discussed on IRC, on DDI platforms, the (e)DP compute_config() does
the private DPLL selection, and the ddi_pll_select() does the the same
for shared DPLLs (I'm not saying that the end result we want, just how
it works today). That split comes from the introduction of shared_dpll
in the DDI PLL selection last summer.
Anyway, this means that, for SKL, dpll_hw_state is touched by the
encoder's compute_config() for (e)DP.
I think we could just remove the memset() in 4978cc93 (maybe?), or try
to unify a bit better and only have one place where we do PLL selection
(which I assume is part of the bigger atomic plan). Not
skl_edp_set_pll_config() in both compute_config() and ddi_pll_select()
though.
--
Damien
> ---
>
> Big CC list so no one misses the chance of saying how this is not the
> right fix. :) But that is OK, I was just annoyed by the constant stream
> of warnings obscuring real problems.
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 4 +++-
> drivers/gpu/drm/i915/intel_dp.c | 2 +-
> drivers/gpu/drm/i915/intel_drv.h | 3 +++
> 3 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
> index 807e15d..e5b7723 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1306,8 +1306,10 @@ skl_ddi_pll_select(struct intel_crtc *intel_crtc,
> }
>
> cfgcr1 = cfgcr2 = 0;
> - } else /* eDP */
> + } else /* eDP */ {
> + skl_edp_set_pll_config(crtc_state, clock);
> return true;
> + }
>
> crtc_state->dpll_hw_state.ctrl1 = ctrl1;
> crtc_state->dpll_hw_state.cfgcr1 = cfgcr1;
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 75bccd6..13b5b0e 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1092,7 +1092,7 @@ intel_dp_connector_unregister(struct intel_connector *intel_connector)
> intel_connector_unregister(intel_connector);
> }
>
> -static void
> +void
> skl_edp_set_pll_config(struct intel_crtc_state *pipe_config, int link_clock)
> {
> u32 ctrl1;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index aa77af7..6e26644 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1193,6 +1193,9 @@ void intel_edp_drrs_invalidate(struct drm_device *dev,
> unsigned frontbuffer_bits);
> void intel_edp_drrs_flush(struct drm_device *dev, unsigned frontbuffer_bits);
>
> +void
> +skl_edp_set_pll_config(struct intel_crtc_state *pipe_config, int link_clock);
> +
> /* intel_dp_mst.c */
> int intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port, int conn_id);
> void intel_dp_mst_encoder_cleanup(struct intel_digital_port *intel_dig_port);
> --
> 2.4.0
>
More information about the Intel-gfx
mailing list