Re: [Intel-gfx] [PATCH 9/9] drm/i915: Enable upfront link training support for HSW/BDW

[R, Durgadoss]

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Manasi Navare
> Sent: Wednesday, August 10, 2016 12:59 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 9/9] drm/i915: Enable upfront link training
> support for HSW/BDW
> 
> Get the PLLs for HSW/BDW using the platform specific function
> and add hooks for enabling upfront link training on HSW and BDW.
> 
> Signed-off-by: Manasi Navare 

Reviewed-by: Durgadoss R 

Thanks,
Durga

> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 2 ++
>  drivers/gpu/drm/i915/intel_dp.c  | 4 +++-
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index ed9ebca..fd0c538 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2410,6 +2410,8 @@ intel_ddi_get_link_dpll(struct intel_dp *intel_dp,
> int clock)
>   }
>   } else if (IS_SKYLAKE(dev_priv)) {
>   pll = skl_find_link_pll(dev_priv, clock);
> + } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> + pll = hsw_ddi_dp_get_dpll(encoder, clock);
>   }
>   return pll;
>  }
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index 572119e..25190fa 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5762,8 +5762,10 @@ intel_dp_init_connector(struct intel_digital_port
> *intel_dig_port,
> 
>   /* Initialize upfront link training vfunc for DP */
>   if (intel_encoder->type != INTEL_OUTPUT_EDP) {
> - if (IS_BROXTON(dev) || IS_SKYLAKE(dev))
> + if (IS_BROXTON(dev) || IS_SKYLAKE(dev) ||
> + IS_BROADWELL(dev) || IS_HASWELL(dev))
>   intel_dp->upfront_link_train =
> intel_ddi_upfront_link_train;
> +
>   }
> 
>   /* eDP only on port B and/or C on vlv/chv */
> --
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 8/9] drm/i915: Split hsw_get_dpll()

[R, Durgadoss]

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Manasi Navare
> Sent: Wednesday, August 10, 2016 12:59 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 8/9] drm/i915: Split hsw_get_dpll()
> 
> Split out the DisplayPort and HDMI pll setup code into separate
> functions and refactor the DP code that calculates the pll
> so that it doesn't depend on crtc state.
> This will be used for acquiring port pll when doing
> upfront link training.
> 
> Signed-off-by: Manasi Navare 

Reviewed-by: Durgadoss R 

Thanks,
Durga

> ---
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 90 ++
> -
>  drivers/gpu/drm/i915/intel_dpll_mgr.h |  6 +++
>  2 files changed, 63 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index e5c025e..93f7aae 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -705,11 +705,65 @@ hsw_ddi_calculate_wrpll(int clock /* in Hz */,
>   *r2_out = best.r2;
>  }
> 
> +static struct intel_shared_dpll *hsw_ddi_hdmi_get_dpll(int clock,
> +struct intel_crtc *crtc,
> +struct intel_crtc_state
> *crtc_state)
> +{
> + struct intel_shared_dpll *pll;
> + uint32_t val;
> + unsigned p, n2, r2;
> +
> + hsw_ddi_calculate_wrpll(clock * 1000, , , );
> +
> + val = WRPLL_PLL_ENABLE | WRPLL_PLL_LCPLL |
> +   WRPLL_DIVIDER_REFERENCE(r2) |
> WRPLL_DIVIDER_FEEDBACK(n2) |
> +   WRPLL_DIVIDER_POST(p);
> +
> + crtc_state->dpll_hw_state.wrpll = val;
> +
> + pll = intel_find_shared_dpll(crtc, crtc_state,
> +  DPLL_ID_WRPLL1, DPLL_ID_WRPLL2);
> +
> + if (!pll)
> + return NULL;
> +
> + return pll;
> +}
> +
> +struct intel_shared_dpll *hsw_ddi_dp_get_dpll(struct intel_encoder
> *encoder,
> +   int clock)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_shared_dpll *pll;
> + enum intel_dpll_id pll_id;
> +
> + switch (clock / 2) {
> + case 81000:
> + pll_id = DPLL_ID_LCPLL_810;
> + break;
> + case 135000:
> + pll_id = DPLL_ID_LCPLL_1350;
> + break;
> + case 27:
> + pll_id = DPLL_ID_LCPLL_2700;
> + break;
> + default:
> + DRM_DEBUG_KMS("Invalid clock for DP: %d\n", clock);
> + return NULL;
> + }
> +
> + pll = intel_get_shared_dpll_by_id(dev_priv, pll_id);
> +
> + if (!pll)
> + return NULL;
> +
> + return pll;
> +}
> +
>  static struct intel_shared_dpll *
>  hsw_get_dpll(struct intel_crtc *crtc, struct intel_crtc_state *crtc_state,
>struct intel_encoder *encoder)
>  {
> - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>   struct intel_shared_dpll *pll;
>   int clock = crtc_state->port_clock;
> 
> @@ -717,41 +771,12 @@ hsw_get_dpll(struct intel_crtc *crtc, struct
> intel_crtc_state *crtc_state,
>  sizeof(crtc_state->dpll_hw_state));
> 
>   if (encoder->type == INTEL_OUTPUT_HDMI) {
> - uint32_t val;
> - unsigned p, n2, r2;
> -
> - hsw_ddi_calculate_wrpll(clock * 1000, , , );
> -
> - val = WRPLL_PLL_ENABLE | WRPLL_PLL_LCPLL |
> -   WRPLL_DIVIDER_REFERENCE(r2) |
> WRPLL_DIVIDER_FEEDBACK(n2) |
> -   WRPLL_DIVIDER_POST(p);
> -
> - crtc_state->dpll_hw_state.wrpll = val;
> -
> - pll = intel_find_shared_dpll(crtc, crtc_state,
> -  DPLL_ID_WRPLL1,
> DPLL_ID_WRPLL2);
> + pll = hsw_ddi_hdmi_get_dpll(clock, crtc, crtc_state);
> 
>   } else if (encoder->type == INTEL_OUTPUT_DP ||
>  encoder->type == INTEL_OUTPUT_DP_MST ||
>  encoder->type == INTEL_OUTPUT_EDP) {
> - enum intel_dpll_id pll_id;
> -
> - switch (clock / 2) {
> - case 81000:
> - pll_id = DPLL_ID_LCPLL_810;
> - break;
> - case 135000:
> - pll_id = DPLL_ID_LCPLL_1350;
> - break;
> - case 27:
> - pll_id = DPLL_ID_LCPLL_2700;
> - break;
> - default:
> - DRM_DEBUG_KMS("Invalid clock for DP: %d\n",
> clock);
> - return NULL;
> - }
> -
> - pll = intel_get_shared_dpll_by_id(dev_priv, pll_id);
> + pll = hsw_ddi_dp_get_dpll(encoder, clock);
> 
>   } else if (encoder->type == INTEL_OUTPUT_ANALOG) {
>   if (WARN_ON(crtc_state->port_clock / 2 != 135000))

Re: [Intel-gfx] [PATCH 7/9] drm/i915/dp: Enable upfront link training on SKL

[R, Durgadoss]

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Manasi Navare
> Sent: Wednesday, August 10, 2016 12:59 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 7/9] drm/i915/dp: Enable upfront link training on
> SKL
> 
> From: Jim Bride 
> 
> Split the PLL selection code out of the BXT upfront link training
> implementation and into a stand-alone function in order to allow
> for the implementation of a platform neutral upfront link training
> function, and then enable upfront link training for Skylake.
> 
> Signed-off-by: Jim Bride 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c  | 58 -
> --
>  drivers/gpu/drm/i915/intel_dp.c   |  4 +--
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 38 +++
>  drivers/gpu/drm/i915/intel_dpll_mgr.h |  2 ++
>  drivers/gpu/drm/i915/intel_drv.h  |  4 ++-
>  5 files changed, 85 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 3921230..ed9ebca 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2378,8 +2378,43 @@ intel_ddi_init_hdmi_connector(struct
> intel_digital_port *intel_dig_port)
>   return connector;
>  }
> 
> +struct intel_shared_dpll *
> +intel_ddi_get_link_dpll(struct intel_dp *intel_dp, int clock)
> +{
> + struct intel_connector *connector = intel_dp->attached_connector;
> + struct intel_encoder *encoder = connector->encoder;
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct intel_shared_dpll *pll = NULL;
> + struct intel_shared_dpll_config tmp_pll_config;
> + enum intel_dpll_id dpll_id;
> 
> -bool intel_bxt_upfront_link_train(struct intel_dp *intel_dp,
> + if (IS_BROXTON(dev_priv)) {
> + dpll_id =  (enum intel_dpll_id)dig_port->port;
> + /*
> +  * Select the required PLL. This works for platforms where
> +  * there is no shared DPLL.
> +  */
> + pll = _priv->shared_dplls[dpll_id];
> + if (WARN_ON(pll->active_mask)) {
> +
> + DRM_ERROR("Shared DPLL in use.
> active_mask:%x\n",
> +   pll->active_mask);
> + pll = NULL;
> + }
> + tmp_pll_config = pll->config;
> + if (!bxt_ddi_dp_set_dpll_hw_state(clock,
> +   >config.hw_state)) {
> + DRM_ERROR("Could not setup DPLL\n");
> + pll->config = tmp_pll_config;
> + }
> + } else if (IS_SKYLAKE(dev_priv)) {
> + pll = skl_find_link_pll(dev_priv, clock);
> + }
> + return pll;
> +}
> +
> +bool intel_ddi_upfront_link_train(struct intel_dp *intel_dp,
> int clock, uint8_t lane_count,
> bool link_mst)
>  {
> @@ -2388,28 +2423,15 @@ bool intel_bxt_upfront_link_train(struct intel_dp
> *intel_dp,
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   struct intel_shared_dpll *pll;
>   struct intel_shared_dpll_config tmp_pll_config;
> - struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> - enum intel_dpll_id dpll_id = (enum intel_dpll_id)dig_port->port;
> 
> - /*
> -  * FIXME: Works only for BXT.
> -  * Select the required PLL. This works for platforms where
> -  * there is no shared DPLL.
> -  */
> - pll = _priv->shared_dplls[dpll_id];
> - if (WARN_ON(pll->active_mask)) {
> - DRM_ERROR("Shared DPLL already in use.
> active_mask:%x\n", pll->active_mask);
> + pll = intel_ddi_get_link_dpll(intel_dp, clock);
> + if (pll == NULL) {
> + DRM_ERROR("Could not find DPLL for link training.\n");
>   return false;
>   }
> -
> +
>   tmp_pll_config = pll->config;
> 
> - if (!bxt_ddi_dp_set_dpll_hw_state(clock, >config.hw_state)) {
> - DRM_ERROR("Could not setup DPLL\n");
> - pll->config = tmp_pll_config;
> - return false;
> - }
> -
>   /* Enable PLL followed by port */
>   pll->funcs.enable(dev_priv, pll);
>   intel_ddi_pre_enable_dp(encoder, clock, lane_count, pll, link_mst);
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index 4c03e28..572119e 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5762,8 +5762,8 @@ intel_dp_init_connector(struct intel_digital_port
> *intel_dig_port,
> 
>   /* Initialize upfront link training vfunc for DP */
>   if (intel_encoder->type != INTEL_OUTPUT_EDP) {
> - if (IS_BROXTON(dev))
> - intel_dp->upfront_link_train =
> 

Re: [Intel-gfx] [PATCHv7 5/5] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

[R, Durgadoss]

Hi Ville,

Thanks for looking at it..

> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Wednesday, July 27, 2016 3:28 PM
> To: R, Durgadoss <durgados...@intel.com>
> Cc: intel-gfx@lists.freedesktop.org; Conselvan De Oliveira, Ander
> <ander.conselvan.de.olive...@intel.com>; Bride, Jim <jim.br...@intel.com>;
> Navare, Manasi D <manasi.d.nav...@intel.com>
> Subject: Re: [PATCHv7 5/5] drm/i915/dp: Enable Upfront link training for
> typeC DP support on BXT
> 
> On Wed, Jul 13, 2016 at 04:15:44PM +0530, Durgadoss R wrote:
> > To support USB type C alternate DP mode, the display driver needs to
> > know the number of lanes required by the DP panel as well as number
> > of lanes that can be supported by the type-C cable. Sometimes, the
> > type-C cable may limit the bandwidth even if Panel can support
> > more lanes. To address these scenarios, the display driver will
> > start link training with max lanes, and if that fails, the driver
> > falls back to x2 lanes; and repeats this procedure for all
> > bandwidth/lane configurations.
> >
> > * Since link training is done before modeset only the port
> >   (and not pipe/planes) and its associated PLLs are enabled.
> > * On DP hotplug: Directly start link training on the DP encoder.
> > * On Connected boot scenarios: When booted with an LFP and a DP,
> >   sometimes BIOS brings up DP. In these cases, we disable the
> >   crtc and then do upfront link training; and bring it back up.
> > * All local changes made for upfront link training are reset
> >   to their previous values once it is done; so that the
> >   subsequent modeset is not aware of these changes.
> >
> > Changes since v6:
> > * Fix some initialization bugs on link_rate (Jim Bride)
> > * Use link_rate (and not link_bw) for upfront (Ville)
> > * Make intel_dp_upfront*() as a vfunc (Ander)
> > * The train_set_valid variable in intel_dp was removed due to
> >   issues in fast link training. So, to indicate the link train
> >   status, move the channel_eq inside intel_dp.
> > Changes since v5:
> > * Moved retry logic in upfront to intel_dp.c so that it
> >   can be used for all platforms.
> > Changes since v4:
> > * Removed usage of crtc_state in upfront link training;
> >   Hence no need to find free crtc to do upfront now.
> > * Re-enable crtc if it was disabled for upfront.
> > * Use separate variables to track max lane count
> >   and link rate found by upfront, without modifying
> >   the original DPCD read from panel.
> > Changes since v3:
> > * Fixed a return value on BXT check
> > * Reworked on top of bxt_ddi_pll_select split from Ander
> > * Renamed from ddi_upfront to bxt_upfront since the
> >   upfront logic includes BXT specific functions for now.
> > Changes since v2:
> > * Rebased on top of latest dpll_mgr.c code and
> >   latest HPD related clean ups.
> > * Corrected return values from upfront (Ander)
> > * Corrected atomic locking for upfront in intel_dp.c (Ville)
> > Changes since v1:
> > *  all pll related functions inside ddi.c
> >
> > Signed-off-by: Durgadoss R <durgados...@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c  |  45 
> >  drivers/gpu/drm/i915/intel_dp.c   | 155
> +-
> >  drivers/gpu/drm/i915/intel_dp_link_training.c |   7 +-
> >  drivers/gpu/drm/i915/intel_drv.h  |  15 +++
> >  4 files changed, 213 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> > index ab1745a..3bad01b 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -2356,6 +2356,51 @@ intel_ddi_init_hdmi_connector(struct
> intel_digital_port *intel_dig_port)
> > return connector;
> >  }
> >
> > +bool intel_bxt_upfront_link_train(struct intel_dp *intel_dp,
> > +   int clock, uint8_t lane_count)
> > +{
> > +   struct intel_connector *connector = intel_dp->attached_connector;
> > +   struct intel_encoder *encoder = connector->encoder;
> > +   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > +   struct intel_shared_dpll *pll;
> > +   struct intel_shared_dpll_config tmp_pll_config;
> > +   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > +   enum intel_dpll_id dpll_id = (enum intel_dpll_id)dig_port->port;
> > +
> > +   /*
> > +* FIXME: Works only for BXT.

Re: [Intel-gfx] [PATCHv7 5/5] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

[R, Durgadoss]

> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Wednesday, July 27, 2016 3:28 PM
> To: R, Durgadoss <durgados...@intel.com>
> Cc: intel-gfx@lists.freedesktop.org; Conselvan De Oliveira, Ander
> <ander.conselvan.de.olive...@intel.com>; Bride, Jim <jim.br...@intel.com>;
> Navare, Manasi D <manasi.d.nav...@intel.com>
> Subject: Re: [PATCHv7 5/5] drm/i915/dp: Enable Upfront link training for
> typeC DP support on BXT
> 
> On Wed, Jul 13, 2016 at 04:15:44PM +0530, Durgadoss R wrote:
> > To support USB type C alternate DP mode, the display driver needs to
> > know the number of lanes required by the DP panel as well as number
> > of lanes that can be supported by the type-C cable. Sometimes, the
> > type-C cable may limit the bandwidth even if Panel can support
> > more lanes. To address these scenarios, the display driver will
> > start link training with max lanes, and if that fails, the driver
> > falls back to x2 lanes; and repeats this procedure for all
> > bandwidth/lane configurations.
> >
> > * Since link training is done before modeset only the port
> >   (and not pipe/planes) and its associated PLLs are enabled.
> > * On DP hotplug: Directly start link training on the DP encoder.
> > * On Connected boot scenarios: When booted with an LFP and a DP,
> >   sometimes BIOS brings up DP. In these cases, we disable the
> >   crtc and then do upfront link training; and bring it back up.
> > * All local changes made for upfront link training are reset
> >   to their previous values once it is done; so that the
> >   subsequent modeset is not aware of these changes.
> >
> > Changes since v6:
> > * Fix some initialization bugs on link_rate (Jim Bride)
> > * Use link_rate (and not link_bw) for upfront (Ville)
> > * Make intel_dp_upfront*() as a vfunc (Ander)
> > * The train_set_valid variable in intel_dp was removed due to
> >   issues in fast link training. So, to indicate the link train
> >   status, move the channel_eq inside intel_dp.
> > Changes since v5:
> > * Moved retry logic in upfront to intel_dp.c so that it
> >   can be used for all platforms.
> > Changes since v4:
> > * Removed usage of crtc_state in upfront link training;
> >   Hence no need to find free crtc to do upfront now.
> > * Re-enable crtc if it was disabled for upfront.
> > * Use separate variables to track max lane count
> >   and link rate found by upfront, without modifying
> >   the original DPCD read from panel.
> > Changes since v3:
> > * Fixed a return value on BXT check
> > * Reworked on top of bxt_ddi_pll_select split from Ander
> > * Renamed from ddi_upfront to bxt_upfront since the
> >   upfront logic includes BXT specific functions for now.
> > Changes since v2:
> > * Rebased on top of latest dpll_mgr.c code and
> >   latest HPD related clean ups.
> > * Corrected return values from upfront (Ander)
> > * Corrected atomic locking for upfront in intel_dp.c (Ville)
> > Changes since v1:
> > *  all pll related functions inside ddi.c
> >
> > Signed-off-by: Durgadoss R <durgados...@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c  |  45 
> >  drivers/gpu/drm/i915/intel_dp.c   | 155
> +-
> >  drivers/gpu/drm/i915/intel_dp_link_training.c |   7 +-
> >  drivers/gpu/drm/i915/intel_drv.h  |  15 +++
> >  4 files changed, 213 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> > index ab1745a..3bad01b 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -2356,6 +2356,51 @@ intel_ddi_init_hdmi_connector(struct
> intel_digital_port *intel_dig_port)
> > return connector;
> >  }
> >
> > +bool intel_bxt_upfront_link_train(struct intel_dp *intel_dp,
> > +   int clock, uint8_t lane_count)
> > +{
> > +   struct intel_connector *connector = intel_dp->attached_connector;
> > +   struct intel_encoder *encoder = connector->encoder;
> > +   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > +   struct intel_shared_dpll *pll;
> > +   struct intel_shared_dpll_config tmp_pll_config;
> > +   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > +   enum intel_dpll_id dpll_id = (enum intel_dpll_id)dig_port->port;
> > +
> > +   /*
> > +* FIXME: Works only for BXT.
> > +* Select the re

Re: [Intel-gfx] [PATCHv6 5/5] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

[R, Durgadoss]

> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Wednesday, May 25, 2016 9:05 PM
> To: R, Durgadoss <durgados...@intel.com>
> Cc: intel-gfx@lists.freedesktop.org; Conselvan De Oliveira, Ander
> <ander.conselvan.de.olive...@intel.com>
> Subject: Re: [Intel-gfx] [PATCHv6 5/5] drm/i915/dp: Enable Upfront link
> training for typeC DP support on BXT
> 
> On Fri, May 20, 2016 at 02:29:02PM +0530, Durgadoss R wrote:
> > To support USB type C alternate DP mode, the display driver needs to
> > know the number of lanes required by the DP panel as well as number
> > of lanes that can be supported by the type-C cable. Sometimes, the
> > type-C cable may limit the bandwidth even if Panel can support
> > more lanes. To address these scenarios, the display driver will
> > start link training with max lanes, and if that fails, the driver
> > falls back to x2 lanes; and repeats this procedure for all
> > bandwidth/lane configurations.
> >
> > * Since link training is done before modeset only the port
> >   (and not pipe/planes) and its associated PLLs are enabled.
> > * On DP hotplug: Directly start link training on the DP encoder.
> > * On Connected boot scenarios: When booted with an LFP and a DP,
> >   sometimes BIOS brings up DP. In these cases, we disable the
> >   crtc and then do upfront link training; and bring it back up.
> > * All local changes made for upfront link training are reset
> >   to their previous values once it is done; so that the
> >   subsequent modeset is not aware of these changes.
> >
> > Changes since v5:
> > * Moved retry logic in upfront to intel_dp.c so that it
> >   can be used for all platforms.
> > Changes since v4:
> > * Removed usage of crtc_state in upfront link training;
> >   Hence no need to find free crtc to do upfront now.
> > * Re-enable crtc if it was disabled for upfront.
> > * Use separate variables to track max lane count
> >   and link rate found by upfront, without modifying
> >   the original DPCD read from panel.
> > Changes since v3:
> > * Fixed a return value on BXT check
> > * Reworked on top of bxt_ddi_pll_select split from Ander
> > * Renamed from ddi_upfront to bxt_upfront since the
> >   upfront logic includes BXT specific functions for now.
> > Changes since v2:
> > * Rebased on top of latest dpll_mgr.c code and
> >   latest HPD related clean ups.
> > * Corrected return values from upfront (Ander)
> > * Corrected atomic locking for upfront in intel_dp.c (Ville)
> > Changes since v1:
> > *  all pll related functions inside ddi.c
> >
> > Signed-off-by: Durgadoss R <durgados...@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c |  45 ++
> >  drivers/gpu/drm/i915/intel_dp.c  | 179
> +--
> >  drivers/gpu/drm/i915/intel_drv.h |   8 ++
> >  3 files changed, 226 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> > index 7e6331a..8d224bf 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -2330,6 +2330,51 @@ intel_ddi_init_hdmi_connector(struct
> intel_digital_port *intel_dig_port)
> > return connector;
> >  }
> >
> > +bool intel_bxt_upfront_link_train(struct intel_dp *intel_dp,
> > +   int clock, uint8_t lane_count)
> > +{
> > +   struct intel_connector *connector = intel_dp->attached_connector;
> > +   struct intel_encoder *encoder = connector->encoder;
> > +   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > +   struct intel_shared_dpll *pll;
> > +   struct intel_shared_dpll_config tmp_pll_config;
> > +   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > +   enum intel_dpll_id dpll_id = (enum intel_dpll_id)dig_port->port;
> > +
> > +   /*
> > +* FIXME: Works only for BXT.
> > +* Select the required PLL. This works for platforms where
> > +* there is no shared DPLL.
> > +*/
> > +   pll = _priv->shared_dplls[dpll_id];
> > +   if (WARN_ON(pll->active_mask)) {
> > +   DRM_ERROR("Shared DPLL already in use.
> active_mask:%x\n", pll->active_mask);
> > +   return false;
> > +   }
> > +
> > +   tmp_pll_config = pll->config;
> > +
> > +   if (!bxt_ddi_dp_set_dpll_hw_state(clock, >config.hw_state)) {
> > +   DRM_ERROR("Could not setup DPLL\n");
> > +

Re: [Intel-gfx] [PATCH v2] drm/i915: Remove ddi_pll_sel from intel_crtc_state

[R, Durgadoss]

> -Original Message-
> From: Conselvan De Oliveira, Ander
> Sent: Tuesday, May 24, 2016 1:03 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: R, Durgadoss <durgados...@intel.com>; Conselvan De Oliveira, Ander
> <ander.conselvan.de.olive...@intel.com>
> Subject: [PATCH v2] drm/i915: Remove ddi_pll_sel from intel_crtc_state
> 
> The value of ddi_pll_sel is derived from the selection of shared dpll,
> so just calculate the final value when necessary.
> 
> v2: Actually remove it from crtc state and delete remaining usages. (CI)
> 

Looks good to me,

Reviewed-by: Durgadoss R <durgados...@intel.com>

Thanks,
Durga

> Signed-off-by: Ander Conselvan de Oliveira 
> <ander.conselvan.de.olive...@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_ddi.c  | 45 ++--
> ---
>  drivers/gpu/drm/i915/intel_display.c  | 43 +++--
>  drivers/gpu/drm/i915/intel_dp_mst.c   |  3 ++-
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 27 -
>  drivers/gpu/drm/i915/intel_drv.h  |  8 +--
>  5 files changed, 45 insertions(+), 81 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 1cbdd66..2ee5c4c 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -531,6 +531,27 @@ static void intel_wait_ddi_buf_idle(struct
> drm_i915_private *dev_priv,
>   DRM_ERROR("Timeout waiting for DDI BUF %c idle bit\n",
> port_name(port));
>  }
> 
> +static uint32_t hsw_pll_to_ddi_pll_sel(struct intel_shared_dpll *pll)
> +{
> + switch (pll->id) {
> + case DPLL_ID_WRPLL1:
> + return PORT_CLK_SEL_WRPLL1;
> + case DPLL_ID_WRPLL2:
> + return PORT_CLK_SEL_WRPLL2;
> + case DPLL_ID_SPLL:
> + return PORT_CLK_SEL_SPLL;
> + case DPLL_ID_LCPLL_810:
> + return PORT_CLK_SEL_LCPLL_810;
> + case DPLL_ID_LCPLL_1350:
> + return PORT_CLK_SEL_LCPLL_1350;
> + case DPLL_ID_LCPLL_2700:
> + return PORT_CLK_SEL_LCPLL_2700;
> + default:
> + MISSING_CASE(pll->id);
> + return PORT_CLK_SEL_NONE;
> + }
> +}
> +
>  /* Starting with Haswell, different DDI ports can work in FDI mode for
>   * connection to the PCH-located connectors. For this, it is necessary to 
> train
>   * both the DDI port and PCH receiver for the desired DDI buffer settings.
> @@ -546,7 +567,7 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>   struct intel_encoder *encoder;
> - u32 temp, i, rx_ctl_val;
> + u32 temp, i, rx_ctl_val, ddi_pll_sel;
> 
>   for_each_encoder_on_crtc(dev, crtc, encoder) {
>   WARN_ON(encoder->type != INTEL_OUTPUT_ANALOG);
> @@ -577,8 +598,9 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
>   I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val);
> 
>   /* Configure Port Clock Select */
> - I915_WRITE(PORT_CLK_SEL(PORT_E), intel_crtc->config-
> >ddi_pll_sel);
> - WARN_ON(intel_crtc->config->ddi_pll_sel != PORT_CLK_SEL_SPLL);
> + ddi_pll_sel = hsw_pll_to_ddi_pll_sel(intel_crtc->config-
> >shared_dpll);
> + I915_WRITE(PORT_CLK_SEL(PORT_E), ddi_pll_sel);
> + WARN_ON(ddi_pll_sel != PORT_CLK_SEL_SPLL);
> 
>   /* Start the training iterating through available voltages and
> emphasis,
>* testing each value twice. */
> @@ -855,7 +877,7 @@ static void skl_ddi_clock_get(struct intel_encoder
> *encoder,
>   int link_clock = 0;
>   uint32_t dpll_ctl1, dpll;
> 
> - dpll = pipe_config->ddi_pll_sel;
> + dpll = intel_get_shared_dpll_id(dev_priv, pipe_config->shared_dpll);
> 
>   dpll_ctl1 = I915_READ(DPLL_CTRL1);
> 
> @@ -903,7 +925,7 @@ static void hsw_ddi_clock_get(struct intel_encoder
> *encoder,
>   int link_clock = 0;
>   u32 val, pll;
> 
> - val = pipe_config->ddi_pll_sel;
> + val = hsw_pll_to_ddi_pll_sel(pipe_config->shared_dpll);
>   switch (val & PORT_CLK_SEL_MASK) {
>   case PORT_CLK_SEL_LCPLL_810:
>   link_clock = 81000;
> @@ -1568,13 +1590,15 @@ uint32_t ddi_signal_levels(struct intel_dp
> *intel_dp)
>  }
> 
>  void intel_ddi_clk_select(struct intel_encoder *encoder,
> -   const struct intel_crtc_state *pipe_config)
> +   struct intel_shared_dpll *pll)
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   enum port port = inte

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Update kerneldoc for intel_dpll_mgr.c

[R, Durgadoss]

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Ander Conselvan de Oliveira
> Sent: Friday, May 20, 2016 8:24 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Conselvan De Oliveira, Ander 
> Subject: [Intel-gfx] [PATCH 4/4] drm/i915: Update kerneldoc for
> intel_dpll_mgr.c
> 
> The documentation for most of the non-static members and structs were
> missing. Fix that.
> 
> Cc: Daniel Vetter 
> Signed-off-by: Ander Conselvan de Oliveira
> 
> ---
>  Documentation/DocBook/gpu.tmpl|  7 +++
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 88
> +--
>  drivers/gpu/drm/i915/intel_dpll_mgr.h | 83
> +
>  3 files changed, 163 insertions(+), 15 deletions(-)
> 
> diff --git a/Documentation/DocBook/gpu.tmpl
> b/Documentation/DocBook/gpu.tmpl
> index 7586bf75..b96875d 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -3355,6 +3355,13 @@ int num_ioctls;
>  !Idrivers/gpu/drm/i915/intel_bios.c
>  !Idrivers/gpu/drm/i915/intel_vbt_defs.h
>
> +
> +  
> + Display PLLs
> +!Pdrivers/gpu/drm/i915/intel_dpll_mgr.c Display PLLs
> +!Idrivers/gpu/drm/i915/intel_dpll_mgr.c
> +!Idrivers/gpu/drm/i915/intel_dpll_mgr.h
> +  
>  
> 
>  
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 26c9955..bcfe7a9 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -23,6 +23,33 @@
> 
>  #include "intel_drv.h"
> 
> +/**
> + * DOC: Display PLLs
> + *
> + * Display PLLs used for driving outputs vary by platform. While some have
> + * per-pipe or per-encoder dedicated PLLs, others allow the use of any PLL
> + * from a pool. In the latter scenario, it is possible that multiple pipes
> + * share a PLL if their configurations match.
> + *
> + * This file provides an abstraction over display PLLs. The function
> + * intel_shared_dpll_init() initializes the PLLs for the given platform.  The
> + * users of a PLL are tracked and that tracking is integrated with the atomic
> + * modest interface. During an atomic operation, a PLL can be requested for
> a
> + * given crtc and encoder configuration by calling intel_get_shared_dpll()
> and
> + * a previously used PLL can be released with intel_release_shared_dpll().
> + * Changes to the users are first staged in the atomic state, and then made
> + * effective by calling intel_shared_dpll_swap_state() during the atomic
> + * commit phase.
> + */
> +
> +/**
> + * intel_get_shared_dpll_by_id - get a DPLL given its id
> + * @dev_priv: i915 device instance
> + * @id: pll id
> + *
> + * Returns:
> + * A pointer the DPLL with @id

A pointer 'to' the DPLL...

> + */
>  struct intel_shared_dpll *
>  intel_get_shared_dpll_by_id(struct drm_i915_private *dev_priv,
>   enum intel_dpll_id id)
> @@ -30,6 +57,14 @@ intel_get_shared_dpll_by_id(struct drm_i915_private
> *dev_priv,
>   return _priv->shared_dplls[id];
>  }
> 
> +/**
> + * intel_get_shared_dpll_id - get the id of a DPLL
> + * @dev_priv: i915 device instance
> + * @pll: the DPLL
> + *
> + * Returns:
> + * The id of @pll
> + */
>  enum intel_dpll_id
>  intel_get_shared_dpll_id(struct drm_i915_private *dev_priv,
>struct intel_shared_dpll *pll)
> @@ -58,6 +93,13 @@ void assert_shared_dpll(struct drm_i915_private
> *dev_priv,
>   pll->name, onoff(state), onoff(cur_state));
>  }
> 
> +/**
> + * intel_prepare_shared_dpll - call a dpll's prepare hook
> + * @crtc: crtc which has a shared dpll
> + *
> + * This calls the PLL's prepare hook if it has one and if the PLL is not
> + * already enabled. The prepare hook is platform specific.
> + */
>  void intel_prepare_shared_dpll(struct intel_crtc *crtc)
>  {
>   struct drm_device *dev = crtc->base.dev;
> @@ -80,12 +122,10 @@ void intel_prepare_shared_dpll(struct intel_crtc
> *crtc)
>  }
> 
>  /**
> - * intel_enable_shared_dpll - enable PCH PLL
> - * @dev_priv: i915 private structure
> - * @pipe: pipe PLL to enable
> + * intel_enable_shared_dpll - enable a crtc's shared DPLL
> + * @crtc: crtc which has a shared DPLL
>   *
> - * The PCH PLL needs to be enabled before the PCH transcoder, since it
> - * drives the transcoder clock.
> + * Enable the shared DPLL used by @crtc.
>   */
>  void intel_enable_shared_dpll(struct intel_crtc *crtc)
>  {
> @@ -126,6 +166,12 @@ out:
>   mutex_unlock(_priv->dpll_lock);
>  }
> 
> +/**
> + * intel_disable_shared_dpll - disable a crtc's shared DPLL
> + * @crtc: crtc which has a shared DPLL
> + *
> + * Disable the shared DPLL used by @crtc.
> + */
>  void intel_disable_shared_dpll(struct intel_crtc *crtc)
>  {
>   struct drm_device *dev = crtc->base.dev;
> @@ -228,6 +274,16 @@ intel_reference_shared_dpll(struct
> intel_shared_dpll 

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Rename intel_shared_dpll_commit() to _swap_state()

[R, Durgadoss]

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Ander Conselvan de Oliveira
> Sent: Friday, May 20, 2016 8:24 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Conselvan De Oliveira, Ander 
> Subject: [Intel-gfx] [PATCH 2/4] drm/i915: Rename
> intel_shared_dpll_commit() to _swap_state()
> 
> The function intel_shared_dpll_commit() performs the equivalent of
> drm_atomic_helper_swap_state() for the shared dpll state, which id not

s/id/is

> handled by the helpers. So rename it for consistency.
> 

Reviewed-by: Durgadoss R 

Thanks,
Durga

> Signed-off-by: Ander Conselvan de Oliveira 
> 
> ---
>  drivers/gpu/drm/i915/intel_display.c  | 2 +-
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 2 +-
>  drivers/gpu/drm/i915/intel_dpll_mgr.h | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index fe9b00c..dbb982aa 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13006,7 +13006,7 @@ static int intel_atomic_commit(struct drm_device
> *dev,
>   drm_atomic_helper_swap_state(dev, state);
>   dev_priv->wm.distrust_bios_wm = false;
>   dev_priv->wm.skl_results = intel_state->wm_results;
> - intel_shared_dpll_commit(state);
> + intel_shared_dpll_swap_state(state);
> 
>   if (intel_state->modeset) {
>   memcpy(dev_priv->min_pixclk, intel_state->min_pixclk,
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index a3293cf..27bbc46 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -228,7 +228,7 @@ intel_reference_shared_dpll(struct intel_shared_dpll
> *pll,
>   shared_dpll[pll->id].crtc_mask |= 1 << crtc->pipe;
>  }
> 
> -void intel_shared_dpll_commit(struct drm_atomic_state *state)
> +void intel_shared_dpll_swap_state(struct drm_atomic_state *state)
>  {
>   struct drm_i915_private *dev_priv = to_i915(state->dev);
>   struct intel_shared_dpll_config *shared_dpll;
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.h
> b/drivers/gpu/drm/i915/intel_dpll_mgr.h
> index b93eed8..929ff7d 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.h
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.h
> @@ -151,7 +151,7 @@ void intel_release_shared_dpll(struct intel_crtc *crtc,
>  void intel_prepare_shared_dpll(struct intel_crtc *crtc);
>  void intel_enable_shared_dpll(struct intel_crtc *crtc);
>  void intel_disable_shared_dpll(struct intel_crtc *crtc);
> -void intel_shared_dpll_commit(struct drm_atomic_state *state);
> +void intel_shared_dpll_swap_state(struct drm_atomic_state *state);
>  void intel_shared_dpll_init(struct drm_device *dev);
> 
> 
> --
> 2.5.5
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Introduce intel_release_shared_dpll()

[R, Durgadoss]

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Ander Conselvan de Oliveira
> Sent: Friday, May 20, 2016 8:24 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Conselvan De Oliveira, Ander 
> Subject: [Intel-gfx] [PATCH 1/4] drm/i915: Introduce
> intel_release_shared_dpll()
> 
> While the details of getting a shared dpll are wrapped by
> intel_get_shared_dpll(), the release was still hand rolled into the
> modeset code. Fix that by creating an entry point for releasing the
> pll and move that code there.
> 

Reviewed-by: Durgadoss R 

Thanks,
Durga

> Signed-off-by: Ander Conselvan de Oliveira 
> 
> ---
>  drivers/gpu/drm/i915/intel_display.c  | 13 ++
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 45 +
> --
>  drivers/gpu/drm/i915/intel_dpll_mgr.h | 10 ++--
>  3 files changed, 26 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index a500f08..fe9b00c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12419,7 +12419,6 @@ static void intel_modeset_clear_plls(struct
> drm_atomic_state *state)
>  {
>   struct drm_device *dev = state->dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> - struct intel_shared_dpll_config *shared_dpll = NULL;
>   struct drm_crtc *crtc;
>   struct drm_crtc_state *crtc_state;
>   int i;
> @@ -12429,21 +12428,13 @@ static void intel_modeset_clear_plls(struct
> drm_atomic_state *state)
> 
>   for_each_crtc_in_state(state, crtc, crtc_state, i) {
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> - struct intel_shared_dpll *old_dpll =
> - to_intel_crtc_state(crtc->state)->shared_dpll;
> 
>   if (!needs_modeset(crtc_state))
>   continue;
> 
> + intel_release_shared_dpll(intel_crtc,
> +   to_intel_crtc_state(crtc_state));
>   to_intel_crtc_state(crtc_state)->shared_dpll = NULL;
> -
> - if (!old_dpll)
> - continue;
> -
> - if (!shared_dpll)
> - shared_dpll =
> intel_atomic_get_shared_dpll_state(state);
> -
> - intel_shared_dpll_config_put(shared_dpll, old_dpll,
> intel_crtc);
>   }
>  }
> 
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 0aac3ec..a3293cf 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -41,28 +41,6 @@ intel_get_shared_dpll_id(struct drm_i915_private
> *dev_priv,
>   return (enum intel_dpll_id) (pll - dev_priv->shared_dplls);
>  }
> 
> -void
> -intel_shared_dpll_config_get(struct intel_shared_dpll_config *config,
> -  struct intel_shared_dpll *pll,
> -  struct intel_crtc *crtc)
> -{
> - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - enum intel_dpll_id id = intel_get_shared_dpll_id(dev_priv, pll);
> -
> - config[id].crtc_mask |= 1 << crtc->pipe;
> -}
> -
> -void
> -intel_shared_dpll_config_put(struct intel_shared_dpll_config *config,
> -  struct intel_shared_dpll *pll,
> -  struct intel_crtc *crtc)
> -{
> - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - enum intel_dpll_id id = intel_get_shared_dpll_id(dev_priv, pll);
> -
> - config[id].crtc_mask &= ~(1 << crtc->pipe);
> -}
> -
>  /* For ILK+ */
>  void assert_shared_dpll(struct drm_i915_private *dev_priv,
>   struct intel_shared_dpll *pll,
> @@ -247,7 +225,7 @@ intel_reference_shared_dpll(struct intel_shared_dpll
> *pll,
>   DRM_DEBUG_DRIVER("using %s for pipe %c\n", pll->name,
>pipe_name(crtc->pipe));
> 
> - intel_shared_dpll_config_get(shared_dpll, pll, crtc);
> + shared_dpll[pll->id].crtc_mask |= 1 << crtc->pipe;
>  }
> 
>  void intel_shared_dpll_commit(struct drm_atomic_state *state)
> @@ -1784,3 +1762,24 @@ intel_get_shared_dpll(struct intel_crtc *crtc,
> 
>   return dpll_mgr->get_dpll(crtc, crtc_state, encoder);
>  }
> +
> +/**
> + * intel_release_shared_dpll - releases a shared DPLL from a crtc atomic
> state
> + * @crtc: crtc
> + * @crtc_state: atomic stat for @crtc
> + *
> + */
> +void intel_release_shared_dpll(struct intel_crtc *crtc,
> +struct intel_crtc_state *crtc_state)
> +{
> + struct intel_shared_dpll_config *shared_dpll_config;
> + struct intel_shared_dpll *dpll = crtc_state->shared_dpll;
> +
> + if (!dpll)
> + return;
> +
> + shared_dpll_config =
> + intel_atomic_get_shared_dpll_state(crtc_state-
> >base.state);
> +
> + 

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Rename intel_shared_dpll->mode_set() to prepare()

[R, Durgadoss]

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Ander Conselvan de Oliveira
> Sent: Friday, May 20, 2016 8:24 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Conselvan De Oliveira, Ander 
> Subject: [Intel-gfx] [PATCH 3/4] drm/i915: Rename intel_shared_dpll-
> >mode_set() to prepare()
> 
> The hook is called from intel_prepare_shared_dpll(). The name doesn't
> make sense after all the changes to modeset code. So just call it
> prepare.
> 
Makes sense,

Reviewed-by: Durgadoss R 

Thanks,
Durga

> Signed-off-by: Ander Conselvan de Oliveira 
> 
> ---
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 8 
>  drivers/gpu/drm/i915/intel_dpll_mgr.h | 2 +-
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 27bbc46..26c9955 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -74,7 +74,7 @@ void intel_prepare_shared_dpll(struct intel_crtc *crtc)
>   WARN_ON(pll->on);
>   assert_shared_dpll_disabled(dev_priv, pll);
> 
> - pll->funcs.mode_set(dev_priv, pll);
> + pll->funcs.prepare(dev_priv, pll);
>   }
>   mutex_unlock(_priv->dpll_lock);
>  }
> @@ -264,8 +264,8 @@ static bool ibx_pch_dpll_get_hw_state(struct
> drm_i915_private *dev_priv,
>   return val & DPLL_VCO_ENABLE;
>  }
> 
> -static void ibx_pch_dpll_mode_set(struct drm_i915_private *dev_priv,
> -   struct intel_shared_dpll *pll)
> +static void ibx_pch_dpll_prepare(struct drm_i915_private *dev_priv,
> +  struct intel_shared_dpll *pll)
>  {
>   I915_WRITE(PCH_FP0(pll->id), pll->config.hw_state.fp0);
>   I915_WRITE(PCH_FP1(pll->id), pll->config.hw_state.fp1);
> @@ -354,7 +354,7 @@ ibx_get_dpll(struct intel_crtc *crtc, struct
> intel_crtc_state *crtc_state,
>  }
> 
>  static const struct intel_shared_dpll_funcs ibx_pch_dpll_funcs = {
> - .mode_set = ibx_pch_dpll_mode_set,
> + .prepare = ibx_pch_dpll_prepare,
>   .enable = ibx_pch_dpll_enable,
>   .disable = ibx_pch_dpll_disable,
>   .get_hw_state = ibx_pch_dpll_get_hw_state,
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.h
> b/drivers/gpu/drm/i915/intel_dpll_mgr.h
> index 929ff7d..087e6b1 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.h
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.h
> @@ -101,7 +101,7 @@ struct intel_shared_dpll_config {
>  struct intel_shared_dpll_funcs {
>   /* The mode_set hook is optional and should be used together with
> the
>* intel_prepare_shared_dpll function. */
> - void (*mode_set)(struct drm_i915_private *dev_priv,
> + void (*prepare)(struct drm_i915_private *dev_priv,
>struct intel_shared_dpll *pll);
>   void (*enable)(struct drm_i915_private *dev_priv,
>  struct intel_shared_dpll *pll);
> --
> 2.5.5
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCHv4 3/3] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

[R, Durgadoss]

Hi Ander,

Thanks for looking at it.
Few queries below..

> -Original Message-
> From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
> Sent: Friday, May 6, 2016 6:39 PM
> To: R, Durgadoss <durgados...@intel.com>; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCHv4 3/3] drm/i915/dp: Enable Upfront link
> training for typeC DP support on BXT
> 
> On Mon, 2016-04-18 at 19:01 +0530, Durgadoss R wrote:
> > To support USB type C alternate DP mode, the display driver needs to
> > know the number of lanes required by the DP panel as well as number
> > of lanes that can be supported by the type-C cable. Sometimes, the
> > type-C cable may limit the bandwidth even if Panel can support
> > more lanes. To address these scenarios, the display driver will
> > start link training with max lanes, and if that fails, the driver
> > falls back to x2 lanes; and repeats this procedure for all
> > bandwidth/lane configurations.
> >
> > * Since link training is done before modeset only the port
> >   (and not pipe/planes) and its associated PLLs are enabled.
> > * On DP hotplug: Directly start link training on the crtc
> >   associated with the DP encoder.
> > * On Connected boot scenarios: When booted with an LFP and a DP,
> >   typically, BIOS brings up DP. In these cases, we disable the
> >   crtc and then do upfront link training; and let the subsequent
> >   modeset re-enable the crtc.
> > * All local changes made for upfront link training are reset
> >   to their previous values once it is done; so that the
> >   subsequent modeset is not aware of these changes.
> >
> > Changes since v3:
> > * Fixed a return value on BXT check
> > * Reworked on top of bxt_ddi_pll_select split from Ander
> > * Renamed from ddi_upfront to bxt_upfront since the
> >   upfront logic includes BXT specific functions for now.
> > Changes since v2:
> > * Rebased on top of latest dpll_mgr.c code and
> >   latest HPD related clean ups.
> > * Corrected return values from upfront (Ander)
> > * Corrected atomic locking for upfront in intel_dp.c (Ville)
> > Changes since v1:
> > *  all pll related functions inside ddi.c
> >
> > Signed-off-by: Durgadoss R <durgados...@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c |  73 
> >  drivers/gpu/drm/i915/intel_dp.c  | 180
> > ++-
> >  drivers/gpu/drm/i915/intel_drv.h |   5 ++
> >  3 files changed, 256 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 96234c5..f7fa3db 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -2268,6 +2268,79 @@ intel_ddi_init_hdmi_connector(struct
> intel_digital_port
> > *intel_dig_port)
> >     return connector;
> >  }
> >
> > +int intel_bxt_upfront_link_train(struct intel_dp *intel_dp,
> > +   struct intel_crtc *crtc)
> > +{
> > +   struct intel_connector *connector = intel_dp->attached_connector;
> > +   struct intel_encoder *encoder = connector->encoder;
> > +   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > +   struct intel_shared_dpll *pll;
> > +   struct intel_shared_dpll_config tmp_pll_config;
> > +   struct bxt_clk_div clk_div = {0};
> > +   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > +   enum intel_dpll_id dpll_id = (enum intel_dpll_id)dig_port->port;
> > +   uint8_t link_bw, lane_count;
> > +
> > +   if (WARN_ON(!crtc))
> > +   return -EINVAL;
> > +
> > +   /* Initialize with Max Link rate & lane count supported by panel */
> > +   link_bw =  intel_dp->dpcd[DP_MAX_LINK_RATE];
> > +   lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
> 
> What if the panel supports HBR3? We should use the maximum common rate

Ok, today that will add one more iteration of Link training before going
down to a supported rate. 

> between source and sink. And it would be nice if those details where in 
> intel_dp.c.
> Ideally, the platform specific part would take link rate and lane count as
> arguments and just do the pll/encoder enabling/disabling.

May be with the new {link_bw/lane_count}_upfront variables in intel_dp 
structure,
we could do this easily. Will try this implementation and see how it comes up.

> 
> > +
> > +   mutex_lock(_priv->dpll_lock);
> > +   /*
> > +    * FIXME: Works only for BXT.
> > +    * Select the required PLL. This works for 

Re: [Intel-gfx] [PATCHv4 1/3] drm/i915: Make finding unused crtc as a generic function

[R, Durgadoss]

> -Original Message-
> From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
> Sent: Friday, May 6, 2016 6:38 PM
> To: R, Durgadoss <durgados...@intel.com>; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCHv4 1/3] drm/i915: Make finding unused crtc as
> a generic function
> 
> On Mon, 2016-04-18 at 19:01 +0530, Durgadoss R wrote:
> > Looping over the crtc list and finding an unused crtc has other users
> > like upfront link training. Hence move it to
> 
> "will have", since this patch precedes the upfront link training one.
> 
> > a common function to re-use the logic.
> >
> > v4:
> > * Added ERR_PTR as a return value in kernel Doc comment (Ander)
> > v3:
> > * Added kernel Doc and removed an invalid comment (Ander)
> > * Rebased on top of latest code which includes locking
> >   for state->enable usage.
> > v2:
> > * Made this as a separate function instead of having it
> >   inside upfront link train code.
> >
> > Signed-off-by: Durgadoss R <durgados...@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 74
> > +
> > ---
> >  drivers/gpu/drm/i915/intel_drv.h |  2 +
> >  2 files changed, 45 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 4cca155..a6df48b 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -10404,6 +10404,43 @@ static int
> > intel_modeset_setup_plane_state(struct
> > drm_atomic_state *state,
> >     return 0;
> >  }
> >
> > +/**
> > + * intel_get_unused_crtc - Find an unused crtc for the given encoder
> > + * @encoder: drm_encoder structure
> > + * @ctx: ctx pointer to use with locking
> > + *
> > + * This function tries to find an unused crtc that can drive
> > + * the given encoder. Returns NULL or ERR_PTR on failure.
> 
> This NULL or ERR_PTR makes for an awkward interface. I wonder if it should
> just return ERR_PTR(-EBUSY) or even ERR_PTR(-EINVAL) if there is no free
> crtc. It's no big deal though.
> 
> Also, in the success case crtc->mutex is kept locked. That should be added to
> the documentation above.
>

Ok, Will make the failure case as return (-EINVAL).
 
> > + */
> > +struct drm_crtc *intel_get_unused_crtc(struct drm_encoder *encoder,
> > +   struct drm_modeset_acquire_ctx *ctx) {
> > +   struct drm_crtc *possible_crtc;
> > +   struct drm_crtc *crtc = NULL;
> > +   struct drm_device *dev = encoder->dev;
> > +   int ret, i = -1;
> > +
> > +   for_each_crtc(dev, possible_crtc) {
> > +   i++;
> > +   if (!(encoder->possible_crtcs & (1 << i)))
> > +   continue;
> > +
> > +   ret = drm_modeset_lock(_crtc->mutex, ctx);
> > +   if (ret)
> > +   return ERR_PTR(ret);
> > +
> > +   if (possible_crtc->state->enable) {
> > +   drm_modeset_unlock(_crtc->mutex);
> > +   continue;
> > +   }
> > +
> > +   crtc = possible_crtc;
> > +   break;
> 
> This could be replaced with "return possible_crtc;". No need for the extra
> assignment and break.
> 
> I see that in patch 3 you have a debug message for when this returns NULL. It
> would make sense to move that debug here.

Sure, will add it here..

Thanks,
Durga

> 
> Ander
> 
> > +   }
> > +
> > +   return crtc;
> > +}
> > +
> >  bool intel_get_load_detect_pipe(struct drm_connector *connector,
> >     struct drm_display_mode *mode,
> >     struct intel_load_detect_pipe *old, @@ -
> 10412,7 +10449,6 @@ bool
> > intel_get_load_detect_pipe(struct drm_connector *connector,
> >     struct intel_crtc *intel_crtc;
> >     struct intel_encoder *intel_encoder =
> >     intel_attached_encoder(connector);
> > -   struct drm_crtc *possible_crtc;
> >     struct drm_encoder *encoder = _encoder->base;
> >     struct drm_crtc *crtc = NULL;
> >     struct drm_device *dev = encoder->dev; @@ -10421,7 +10457,7 @@
> bool
> > intel_get_load_detect_pipe(struct drm_connector *connector,
> >     struct drm_atomic_state *state = NULL, *restore_state = NULL;
> >     struct drm_connector_state *connector_state;
> >     struct intel_crtc_state *crtc_state;
> > -   int ret, i 

Re: [Intel-gfx] [PATCHv3 2/4] drm/i915: Store the dpll config in crtc_state->shared_dpll

[R, Durgadoss]

>-Original Message-
>From: Conselvan De Oliveira, Ander
>Sent: Monday, April 11, 2016 6:07 PM
>To: intel-gfx@lists.freedesktop.org; R, Durgadoss <durgados...@intel.com>
>Cc: ville.syrj...@linux.intel.com
>Subject: Re: [PATCHv3 2/4] drm/i915: Store the dpll config in 
>crtc_state->shared_dpll
>
>On Wed, 2016-04-06 at 17:23 +0530, Durgadoss R wrote:
>> Currently, the required shared dpll is saved in the crtc_state.
>> Similarly, this patch saves the dpll config values also, so that
>> these values (through crtc_state->shared_dpll->config.hw_state)
>> can be used for upfront link training.
>>
>> Signed-off-by: Durgadoss R <durgados...@intel.com>
>> ---
>>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
>> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
>> index 1175eeb..cad10f2 100644
>> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
>> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
>> @@ -248,6 +248,7 @@ intel_reference_shared_dpll(struct intel_shared_dpll 
>> *pll,
>>   pipe_name(crtc->pipe));
>>
>>  intel_shared_dpll_config_get(shared_dpll, pll, crtc);
>> +crtc_state->shared_dpll->config = shared_dpll[i];
>
>This overwrites the state stored in dev_priv->shared_dpll[i].config, so it 
>means
>we loose the current state set in the hardware. If the atomic check fails after
>this, the software tracking of the hw state gets messed up.

But we need the computed dpll_state and crtc_mask set for pll enabling.
So, the only other way I see is to call shared_dpll_commit() in ddi_upfront() 
code
after we do get_shared_dpll(). 
What do you think of this ?

Or any other options ?

Thanks,
Durga

>
>Ander
>
>>  }
>>
>>  void intel_shared_dpll_commit(struct drm_atomic_state *state)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCHv3 1/4] drm/i915: Make finding unused crtc as a generic function

[R, Durgadoss]

>-Original Message-
>From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
>Sent: Monday, April 11, 2016 6:06 PM
>To: R, Durgadoss <durgados...@intel.com>; intel-gfx@lists.freedesktop.org
>Cc: ville.syrj...@linux.intel.com
>Subject: Re: [PATCHv3 1/4] drm/i915: Make finding unused crtc as a generic 
>function
>
>On Wed, 2016-04-06 at 17:23 +0530, Durgadoss R wrote:
>> Looping over the crtc list and finding an unused crtc
>> has other users like upfront link training. Hence move it to
>> a common function to re-use the logic.
>>
>> v3:
>> * Added kernel Doc and removed an invalid comment (Ander)
>> * Rebased on top of latest code which includes locking
>>   for state->enable usage.
>> v2:
>> * Made this as a separate function instead of having it
>>   inside upfront link train code.
>>
>> Signed-off-by: Durgadoss R <durgados...@intel.com>
>> ---
>>  drivers/gpu/drm/i915/intel_display.c | 74 
>> +--
>> -
>>  drivers/gpu/drm/i915/intel_drv.h |  2 +
>>  2 files changed, 45 insertions(+), 31 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index e6b5ee5..3c1fbcd 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -10366,6 +10366,43 @@ static int intel_modeset_setup_plane_state(struct
>> drm_atomic_state *state,
>>  return 0;
>>  }
>>
>> +/**
>> + * intel_get_unused_crtc - Find an unused crtc for the given encoder
>> + * @encoder: drm_encoder structure
>> + * @ctx: ctx pointer to use with locking
>> + *
>> + * This function tries to find an unused crtc that can drive
>> + * the given encoder. Returns NULL on failure.
>
>This doesn't match the code below, since it now returns an unused crtc or an
>ERR_PTR. It never returns NULL.

If the 'state->enable'  is set for all crtcs, then I think it can return a NULL.
Anyway, will fix the comment so say "Null or an error pointer" on failure.

Thanks,
Durga

>
>Ander
>
>> + */
>> +struct drm_crtc *intel_get_unused_crtc(struct drm_encoder *encoder,
>> +struct drm_modeset_acquire_ctx *ctx)
>> +{
>> +struct drm_crtc *possible_crtc;
>> +struct drm_crtc *crtc = NULL;
>> +struct drm_device *dev = encoder->dev;
>> +int ret, i = -1;
>> +
>> +for_each_crtc(dev, possible_crtc) {
>> +i++;
>> +if (!(encoder->possible_crtcs & (1 << i)))
>> +continue;
>> +
>> +ret = drm_modeset_lock(_crtc->mutex, ctx);
>> +if (ret)
>> +return ERR_PTR(ret);
>> +
>> +if (possible_crtc->state->enable) {
>> +drm_modeset_unlock(_crtc->mutex);
>> +continue;
>> +}
>> +
>> +crtc = possible_crtc;
>> +break;
>> +}
>> +
>> +return crtc;
>> +}
>> +
>>  bool intel_get_load_detect_pipe(struct drm_connector *connector,
>>  struct drm_display_mode *mode,
>>  struct intel_load_detect_pipe *old,
>> @@ -10374,7 +10411,6 @@ bool intel_get_load_detect_pipe(struct drm_connector
>> *connector,
>>  struct intel_crtc *intel_crtc;
>>  struct intel_encoder *intel_encoder =
>>  intel_attached_encoder(connector);
>> -struct drm_crtc *possible_crtc;
>>  struct drm_encoder *encoder = _encoder->base;
>>  struct drm_crtc *crtc = NULL;
>>  struct drm_device *dev = encoder->dev;
>> @@ -10383,7 +10419,7 @@ bool intel_get_load_detect_pipe(struct drm_connector
>> *connector,
>>  struct drm_atomic_state *state = NULL, *restore_state = NULL;
>>  struct drm_connector_state *connector_state;
>>  struct intel_crtc_state *crtc_state;
>> -int ret, i = -1;
>> +int ret;
>>
>>  DRM_DEBUG_KMS("[CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
>>connector->base.id, connector->name,
>> @@ -10413,39 +10449,15 @@ retry:
>>  ret = drm_modeset_lock(>mutex, ctx);
>>  if (ret)
>>  goto fail;
>> -
>> -/* Make sure the crtc and connector are running */
>> -goto found;
>> -}
>> -
>> -/* Find an unused one (if possible) */
>> -for_each

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Add locking to pll updates.

[R, Durgadoss]

Hi Maarten,

>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
>Maarten Lankhorst
>Sent: Monday, February 29, 2016 6:22 PM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH 4/4] drm/i915: Add locking to pll updates.
>
>With async modesets this is no longer protected with connection_mutex,
>so ensure that each pll has its own lock. The pll configuration state
>is still protected; it's only the pll updates that need locking against
>concurrency.
>
>Signed-off-by: Maarten Lankhorst 
>---
> drivers/gpu/drm/i915/i915_drv.h  |  3 ++-
> drivers/gpu/drm/i915/intel_ddi.c |  4 
> drivers/gpu/drm/i915/intel_display.c | 34 --
> 3 files changed, 30 insertions(+), 11 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
>index c7401b50818c..e20dae7b1fa9 100644
>--- a/drivers/gpu/drm/i915/i915_drv.h
>+++ b/drivers/gpu/drm/i915/i915_drv.h
>@@ -391,9 +391,10 @@ struct intel_shared_dpll_config {
>
> struct intel_shared_dpll {
>   struct intel_shared_dpll_config config;
>+  struct mutex lock;
>
>   unsigned active_mask; /* mask of active CRTCs (i.e. DPMS on) */
>-  bool on; /* is the PLL actually active? Disabled during modeset */
>+  bool on, prepared; /* is the PLL actually active? Disabled during 
>modeset */
>   const char *name;
>   /* should match the index in the dev_priv->shared_dplls array */
>   enum intel_dpll_id id;
>diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
>b/drivers/gpu/drm/i915/intel_ddi.c
>index 21a9b83f3bfc..e23be6e1b846 100644
>--- a/drivers/gpu/drm/i915/intel_ddi.c
>+++ b/drivers/gpu/drm/i915/intel_ddi.c
>@@ -2514,6 +2514,7 @@ static void hsw_shared_dplls_init(struct 
>drm_i915_private *dev_priv)
>   dev_priv->num_shared_dpll = 3;
>
>   for (i = 0; i < 2; i++) {
>+  mutex_init(_priv->shared_dplls[i].lock);
>   dev_priv->shared_dplls[i].id = i;
>   dev_priv->shared_dplls[i].name = hsw_ddi_pll_names[i];
>   dev_priv->shared_dplls[i].disable = hsw_ddi_wrpll_disable;
>@@ -2523,6 +2524,7 @@ static void hsw_shared_dplls_init(struct 
>drm_i915_private *dev_priv)
>   }
>
>   /* SPLL is special, but needs to be initialized anyway.. */
>+  mutex_init(_priv->shared_dplls[i].lock);
>   dev_priv->shared_dplls[i].id = i;
>   dev_priv->shared_dplls[i].name = hsw_ddi_pll_names[i];
>   dev_priv->shared_dplls[i].disable = hsw_ddi_spll_disable;
>@@ -2650,6 +2652,7 @@ static void skl_shared_dplls_init(struct 
>drm_i915_private *dev_priv)
>   dev_priv->num_shared_dpll = 3;
>
>   for (i = 0; i < dev_priv->num_shared_dpll; i++) {
>+  mutex_init(_priv->shared_dplls[i].lock);
>   dev_priv->shared_dplls[i].id = i;
>   dev_priv->shared_dplls[i].name = skl_ddi_pll_names[i];
>   dev_priv->shared_dplls[i].disable = skl_ddi_pll_disable;
>@@ -2978,6 +2981,7 @@ static void bxt_shared_dplls_init(struct 
>drm_i915_private *dev_priv)
>   dev_priv->num_shared_dpll = 3;
>
>   for (i = 0; i < dev_priv->num_shared_dpll; i++) {
>+  mutex_init(_priv->shared_dplls[i].lock);
>   dev_priv->shared_dplls[i].id = i;
>   dev_priv->shared_dplls[i].name = bxt_ddi_pll_names[i];
>   dev_priv->shared_dplls[i].disable = bxt_ddi_pll_disable;
>diff --git a/drivers/gpu/drm/i915/intel_display.c 
>b/drivers/gpu/drm/i915/intel_display.c
>index 6f2dd3192bac..6b17b77106d2 100644
>--- a/drivers/gpu/drm/i915/intel_display.c
>+++ b/drivers/gpu/drm/i915/intel_display.c
>@@ -1865,14 +1865,18 @@ static void intel_prepare_shared_dpll(struct 
>intel_crtc *crtc)
>   if (WARN_ON(pll == NULL))
>   return;
>
>-  WARN_ON(!pll->config.crtc_mask);
>-  if (pll->active_mask == 0) {
>+  mutex_lock(>lock);
>+  if (pll->active_mask == 0 && !pll->prepared) {
>   DRM_DEBUG_DRIVER("setting up %s\n", pll->name);
>+
>+  pll->prepared = true;
>   WARN_ON(pll->on);
>+
>   assert_shared_dpll_disabled(dev_priv, pll);
>
>   pll->mode_set(dev_priv, pll);
>   }
>+  mutex_unlock(>lock);
> }
>
> /**
>@@ -1903,18 +1907,22 @@ static void intel_enable_shared_dpll(struct intel_crtc 
>*crtc)
> pll->name, hweight32(pll->active_mask), pll->on,

Don't we need the lock for this access of 'active_mask' and the WARN_ON() 
before also ?

Thanks,
Durga

> crtc->base.base.id);
>
>+  mutex_lock(>lock);
>   pll->active_mask |= crtc_mask;
>
>   if (pll->active_mask != crtc_mask) {
>   WARN_ON(!pll->on);
>   assert_shared_dpll_enabled(dev_priv, pll);
>-  return;
>+  goto out;
>   }
>   WARN_ON(pll->on);
>
>   DRM_DEBUG_KMS("enabling %s\n", pll->name);
>   pll->enable(dev_priv, pll);
>   

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Move pll power state to crtc power domains.

[R, Durgadoss]

>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
>Maarten Lankhorst
>Sent: Monday, February 29, 2016 6:22 PM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH 3/4] drm/i915: Move pll power state to crtc power 
>domains.
>
>Signed-off-by: Maarten Lankhorst 
>---
> drivers/gpu/drm/i915/intel_display.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_display.c 
>b/drivers/gpu/drm/i915/intel_display.c
>index 6e3b8a1f7dd3..6f2dd3192bac 100644
>--- a/drivers/gpu/drm/i915/intel_display.c
>+++ b/drivers/gpu/drm/i915/intel_display.c
>@@ -1912,8 +1912,6 @@ static void intel_enable_shared_dpll(struct intel_crtc 
>*crtc)
>   }
>   WARN_ON(pll->on);
>
>-  intel_display_power_get(dev_priv, POWER_DOMAIN_PLLS);
>-

Looking from upfront link train perspective, my initial thought was that
direct users of this _enable/disable_shared_dpll may have issues..
But then realized, before we get to _dpll functions, we do a get on
Port power domains, so, hopefully, that should keep us going.

So,
Reviewed-by: Durgadoss R 

Thanks,
Durga

>   DRM_DEBUG_KMS("enabling %s\n", pll->name);
>   pll->enable(dev_priv, pll);
>   pll->on = true;
>@@ -1952,8 +1950,6 @@ static void intel_disable_shared_dpll(struct intel_crtc 
>*crtc)
>   DRM_DEBUG_KMS("disabling %s\n", pll->name);
>   pll->disable(dev_priv, pll);
>   pll->on = false;
>-
>-  intel_display_power_put(dev_priv, POWER_DOMAIN_PLLS);
> }
>
> static void ironlake_enable_pch_transcoder(struct drm_i915_private *dev_priv,
>@@ -5347,6 +5343,9 @@ static unsigned long get_crtc_power_domains(struct 
>drm_crtc *crtc,
>   mask |= BIT(intel_display_port_power_domain(intel_encoder));
>   }
>
>+  if (crtc_state->shared_dpll != DPLL_ID_PRIVATE)
>+  mask |= BIT(POWER_DOMAIN_PLLS);
>+
>   return mask;
> }
>
>@@ -15775,9 +15774,6 @@ static void intel_modeset_readout_hw_state(struct 
>drm_device *dev)
>
>   DRM_DEBUG_KMS("%s hw state readout: crtc_mask 0x%08x, on %i\n",
> pll->name, pll->config.crtc_mask, pll->on);
>-
>-  if (pll->config.crtc_mask)
>-  intel_display_power_get(dev_priv, POWER_DOMAIN_PLLS);
>   }
>
>   for_each_intel_encoder(dev, encoder) {
>--
>2.1.0
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Perform dpll commit first.

[R, Durgadoss]

Hi Maarten,

>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
>Maarten Lankhorst
>Sent: Monday, February 29, 2016 6:22 PM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH 2/4] drm/i915: Perform dpll commit first.
>
>Warn for the wrong mask in enable only. Disable will have the wrong mask now
>because the new state is committed before disabling the old state.
>
>Signed-off-by: Maarten Lankhorst 
>---
> drivers/gpu/drm/i915/intel_display.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_display.c 
>b/drivers/gpu/drm/i915/intel_display.c
>index 5dd59cae9f06..6e3b8a1f7dd3 100644
>--- a/drivers/gpu/drm/i915/intel_display.c
>+++ b/drivers/gpu/drm/i915/intel_display.c
>@@ -1893,7 +1893,7 @@ static void intel_enable_shared_dpll(struct intel_crtc 
>*crtc)
>   if (WARN_ON(pll == NULL))
>   return;
>
>-  if (WARN_ON(pll->config.crtc_mask == 0))
>+  if (WARN_ON(!(pll->config.crtc_mask & (1 << 
>drm_crtc_index(>base)

Since we have crtc_mask initialized from patch 1, Why not use the same after 
the '&' ?

Thanks,
Durga

>   return;
>
>   if (WARN_ON(pll->active_mask & crtc_mask))
>@@ -1933,9 +1933,6 @@ static void intel_disable_shared_dpll(struct intel_crtc 
>*crtc)
>   if (pll == NULL)
>   return;
>
>-  if (WARN_ON(!(pll->config.crtc_mask & crtc_mask)))
>-  return;
>-
>   if (WARN_ON(!(pll->active_mask & crtc_mask)))
>   return;
>
>@@ -13521,7 +13518,8 @@ static int intel_atomic_commit(struct drm_device *dev,
>   }
>
>   drm_atomic_helper_swap_state(dev, state);
>-  dev_priv->wm.config = to_intel_atomic_state(state)->wm_config;
>+  dev_priv->wm.config = intel_state->wm_config;
>+  intel_shared_dpll_commit(state);
>
>   if (intel_state->modeset) {
>   memcpy(dev_priv->min_pixclk, intel_state->min_pixclk,
>@@ -13573,8 +13571,6 @@ static int intel_atomic_commit(struct drm_device *dev,
>   intel_modeset_update_crtc_state(state);
>
>   if (intel_state->modeset) {
>-  intel_shared_dpll_commit(state);
>-
>   drm_atomic_helper_update_legacy_modeset_state(state->dev, 
> state);
>
>   if (dev_priv->display.modeset_commit_cdclk &&
>--
>2.1.0
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Use a crtc mask instead of a refcount for dpll functions.

[R, Durgadoss]

>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
>Maarten Lankhorst
>Sent: Monday, February 29, 2016 6:22 PM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH 1/4] drm/i915: Use a crtc mask instead of a 
>refcount for dpll functions.
>
>This makes it easier to verify correct dpll setup with only a single crtc.
>It it also useful to detect double dpll enable/disable.

s/it/is

Actually, a welcome change ;-)

Reviewed-by: Durgadoss R 

Thanks,
Durga

>
>Signed-off-by: Maarten Lankhorst 
>---
> drivers/gpu/drm/i915/i915_debugfs.c  |  2 +-
> drivers/gpu/drm/i915/i915_drv.h  |  2 +-
> drivers/gpu/drm/i915/intel_display.c | 68 
> 3 files changed, 40 insertions(+), 32 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
>b/drivers/gpu/drm/i915/i915_debugfs.c
>index c6e64e2c951e..200e45922587 100644
>--- a/drivers/gpu/drm/i915/i915_debugfs.c
>+++ b/drivers/gpu/drm/i915/i915_debugfs.c
>@@ -3211,7 +3211,7 @@ static int i915_shared_dplls_info(struct seq_file *m, 
>void *unused)
>
>   seq_printf(m, "DPLL%i: %s, id: %i\n", i, pll->name, pll->id);
>   seq_printf(m, " crtc_mask: 0x%08x, active: %d, on: %s\n",
>- pll->config.crtc_mask, pll->active, yesno(pll->on));
>+ pll->config.crtc_mask, hweight32(pll->active_mask), 
>yesno(pll->on));
>   seq_printf(m, " tracked hardware state:\n");
>   seq_printf(m, " dpll:0x%08x\n", pll->config.hw_state.dpll);
>   seq_printf(m, " dpll_md: 0x%08x\n",
>diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
>index 10480939159c..c7401b50818c 100644
>--- a/drivers/gpu/drm/i915/i915_drv.h
>+++ b/drivers/gpu/drm/i915/i915_drv.h
>@@ -392,7 +392,7 @@ struct intel_shared_dpll_config {
> struct intel_shared_dpll {
>   struct intel_shared_dpll_config config;
>
>-  int active; /* count of number of active CRTCs (i.e. DPMS on) */
>+  unsigned active_mask; /* mask of active CRTCs (i.e. DPMS on) */
>   bool on; /* is the PLL actually active? Disabled during modeset */
>   const char *name;
>   /* should match the index in the dev_priv->shared_dplls array */
>diff --git a/drivers/gpu/drm/i915/intel_display.c 
>b/drivers/gpu/drm/i915/intel_display.c
>index a5d61084ae98..5dd59cae9f06 100644
>--- a/drivers/gpu/drm/i915/intel_display.c
>+++ b/drivers/gpu/drm/i915/intel_display.c
>@@ -1866,7 +1866,7 @@ static void intel_prepare_shared_dpll(struct intel_crtc 
>*crtc)
>   return;
>
>   WARN_ON(!pll->config.crtc_mask);
>-  if (pll->active == 0) {
>+  if (pll->active_mask == 0) {
>   DRM_DEBUG_DRIVER("setting up %s\n", pll->name);
>   WARN_ON(pll->on);
>   assert_shared_dpll_disabled(dev_priv, pll);
>@@ -1888,6 +1888,7 @@ static void intel_enable_shared_dpll(struct intel_crtc 
>*crtc)
>   struct drm_device *dev = crtc->base.dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   struct intel_shared_dpll *pll = intel_crtc_to_shared_dpll(crtc);
>+  unsigned crtc_mask = 1 << drm_crtc_index(>base);
>
>   if (WARN_ON(pll == NULL))
>   return;
>@@ -1895,11 +1896,16 @@ static void intel_enable_shared_dpll(struct intel_crtc 
>*crtc)
>   if (WARN_ON(pll->config.crtc_mask == 0))
>   return;
>
>+  if (WARN_ON(pll->active_mask & crtc_mask))
>+  return;
>+
>   DRM_DEBUG_KMS("enable %s (active %d, on? %d) for crtc %d\n",
>-pll->name, pll->active, pll->on,
>+pll->name, hweight32(pll->active_mask), pll->on,
> crtc->base.base.id);
>
>-  if (pll->active++) {
>+  pll->active_mask |= crtc_mask;
>+
>+  if (pll->active_mask != crtc_mask) {
>   WARN_ON(!pll->on);
>   assert_shared_dpll_enabled(dev_priv, pll);
>   return;
>@@ -1918,30 +1924,33 @@ static void intel_disable_shared_dpll(struct 
>intel_crtc *crtc)
>   struct drm_device *dev = crtc->base.dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   struct intel_shared_dpll *pll = intel_crtc_to_shared_dpll(crtc);
>+  unsigned crtc_mask = 1 << drm_crtc_index(>base);
>
>   /* PCH only available on ILK+ */
>-  if (INTEL_INFO(dev)->gen < 5)
>+  if (INTEL_INFO(dev_priv)->gen < 5)
>   return;
>
>   if (pll == NULL)
>   return;
>
>-  if (WARN_ON(!(pll->config.crtc_mask & (1 << 
>drm_crtc_index(>base)
>+  if (WARN_ON(!(pll->config.crtc_mask & crtc_mask)))
>   return;
>
>-  DRM_DEBUG_KMS("disable %s (active %d, on? %d) for crtc %d\n",
>-pll->name, pll->active, pll->on,
>+  if (WARN_ON(!(pll->active_mask & crtc_mask)))
>+  return;
>+
>+  DRM_DEBUG_KMS("disable %s (active 

Re: [Intel-gfx] [PATCHv2 4/4] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

[R, Durgadoss]

Hi Ville,

>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Friday, February 12, 2016 10:43 PM
>To: R, Durgadoss <durgados...@intel.com>
>Cc: intel-gfx@lists.freedesktop.org; Conselvan De Oliveira, Ander
><ander.conselvan.de.olive...@intel.com>
>Subject: Re: [Intel-gfx] [PATCHv2 4/4] drm/i915/dp: Enable Upfront link 
>training for typeC DP support on
>BXT
>
>On Mon, Feb 01, 2016 at 07:27:53PM +0530, Durgadoss R wrote:
>> To support USB type C alternate DP mode, the display driver needs to
>> know the number of lanes required by the DP panel as well as number
>> of lanes that can be supported by the type-C cable. Sometimes, the
>> type-C cable may limit the bandwidth even if Panel can support
>> more lanes. To address these scenarios, the display driver will
>> start link training with max lanes, and if that fails, the driver
>> falls back to x2 lanes; and repeats this procedure for all
>> bandwidth/lane configurations.
>>
>> * Since link training is done before modeset only the port
>>   (and not pipe/planes) and its associated PLLs are enabled.
>> * On DP hotplug: Directly start link training on the crtc
>>   associated with the DP encoder.
>> * On Connected boot scenarios: When booted with an LFP and a DP,
>>   typically, BIOS brings up DP. In these cases, we disable the
>>   crtc, do upfront link training and then re-enable it back.
>> * All local changes made for upfront link training are reset
>>   to their previous values once it is done; so that the
>>   subsequent modeset is not aware of these changes.
>
>Glancing over this stuff, it doesn't look all that good on the locking
>front. Mainly there doesn't seem to locking.
>
>In general I'm not really convinced upfront link training is a very good
>idea if it needs a pipe. What happens if we fail to find a free pipe?
>
>I'd be much happier about this if we could make do without a pipe at

We actually don't enable/disable the pipe. We need the crtc structures
because values like port clock/link bw/dpll hw state are stored in
crtc->config structures. This is why we had to touch crtc related
data structures.

Ander has pulled the dpll_hw_states out of crtc structures and made them
independent. With this, things should improve.. I need to try this
implementation to see if we can/can't completely get away
with modifying crtc structures.

>least on some modern platforms and actually limit the feature to
>those platforms. PLLs are another concern, but I think modern platforms
>often have some kind of way to always get the standard DP frequencies
>from eg. the LCPLL.
>
>If we do go with the "hope you find a free pipe" approach, then it
>really needs to do that atomic locking stuff right. Otherwise I'd expect

Yes, we missed it. Ander pointed out the place where we need this
locking. So, we will re-work this.

Thanks,
Durga

>fireworks when someone plugs in a display while there's modeset
>happening.
>
>--
>Ville Syrjälä
>Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCHv2 2/4] drm/i915: Make finding unused crtc as a generic function

[R, Durgadoss]

>-Original Message-
>From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
>Sent: Friday, February 12, 2016 10:23 PM
>To: R, Durgadoss <durgados...@intel.com>; intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCHv2 2/4] drm/i915: Make finding unused crtc as a 
>generic function
>
>On Mon, 2016-02-01 at 19:27 +0530, Durgadoss R wrote:
>> Looping over the crtc list and finding an unused crtc
>> has users other than load_detect().
>
>Which other users? If there are other users they should be converted in this
>patch. If the use will only come in a future patch, please make that clear in
>the commit message.

Thanks for the comments, Will update this patch with comments,
And send as part of next version.

Thanks,
Durga

>
>> Hence move it to
>> a common function so that we can re-use the logic.
>>
>> Signed-off-by: Durgadoss R <durgados...@intel.com>
>> ---
>>  drivers/gpu/drm/i915/intel_display.c | 37 
>> ++-
>> -
>>  drivers/gpu/drm/i915/intel_drv.h |  1 +
>>  2 files changed, 24 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 92cd5c6..af50e61 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -10417,6 +10417,27 @@ static int intel_modeset_setup_plane_state(struct
>> drm_atomic_state *state,
>>  return 0;
>>  }
>>
>> +struct drm_crtc *intel_get_unused_crtc(struct drm_encoder *encoder)
>> +{
>
>This function is exported, so it needs some kernel doc.
>
>> +struct drm_crtc *possible_crtc;
>> +struct drm_crtc *crtc = NULL;
>> +struct drm_device *dev = encoder->dev;
>> +int i = -1;
>> +
>> +for_each_crtc(dev, possible_crtc) {
>> +i++;
>> +if (!(encoder->possible_crtcs & (1 << i)))
>> +continue;
>> +if (possible_crtc->state->enable)
>> +continue;
>> +
>> +crtc = possible_crtc;
>> +break;
>> +}
>> +
>> +return crtc;
>> +}
>> +
>>  bool intel_get_load_detect_pipe(struct drm_connector *connector,
>>  struct drm_display_mode *mode,
>>  struct intel_load_detect_pipe *old,
>> @@ -10425,7 +10446,6 @@ bool intel_get_load_detect_pipe(struct drm_connector
>> *connector,
>>  struct intel_crtc *intel_crtc;
>>  struct intel_encoder *intel_encoder =
>>  intel_attached_encoder(connector);
>> -struct drm_crtc *possible_crtc;
>>  struct drm_encoder *encoder = _encoder->base;
>>  struct drm_crtc *crtc = NULL;
>>  struct drm_device *dev = encoder->dev;
>> @@ -10434,7 +10454,7 @@ bool intel_get_load_detect_pipe(struct drm_connector
>> *connector,
>>  struct drm_atomic_state *state = NULL;
>>  struct drm_connector_state *connector_state;
>>  struct intel_crtc_state *crtc_state;
>> -int ret, i = -1;
>> +int ret;
>>
>>  DRM_DEBUG_KMS("[CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
>>connector->base.id, connector->name,
>> @@ -10476,21 +10496,10 @@ retry:
>>  return true;
>>  }
>>
>> -/* Find an unused one (if possible) */
>> -for_each_crtc(dev, possible_crtc) {
>> -i++;
>> -if (!(encoder->possible_crtcs & (1 << i)))
>> -continue;
>> -if (possible_crtc->state->enable)
>> -continue;
>> -
>> -crtc = possible_crtc;
>> -break;
>> -}
>> -
>>  /*
>>   * If we didn't find an unused CRTC, don't use any.
>>   */
>> +crtc = intel_get_unused_crtc(encoder);
>
>The comment above looks out of place now. It is pretty obvious anyway, so maybe
>just delete it.
>
>With those fixed, this is
>
>Reviewed-by: Ander Conselvan de Oliveira <conselv...@gmail.com>
>
>   if (!crtc) {
>>  DRM_DEBUG_KMS("no pipe available for load-detect\n");
>>  goto fail;
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index c7a6e32..9fe7c4b 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -1106,6 +1106,7 @@ bool intel_get_load_detect_pipe(struct drm_connector
>> *connector,
>>  void intel_release_load_detect_pipe(struct drm_connector *connector,
>>  struct intel_load_detect_pipe *old,
>>  struct drm_modeset_acquire_ctx *ctx);
>> +struct drm_crtc *intel_get_unused_crtc(struct drm_encoder *encoder);
>>  int intel_pin_and_fence_fb_obj(struct drm_plane *plane,
>> struct drm_framebuffer *fb,
>> const struct drm_plane_state *plane_state);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCHv2 4/4] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

[R, Durgadoss]

>-Original Message-
>From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
>Sent: Friday, February 12, 2016 10:13 PM
>To: R, Durgadoss <durgados...@intel.com>; intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCHv2 4/4] drm/i915/dp: Enable Upfront link 
>training for typeC DP support on
>BXT
>
>On Mon, 2016-02-01 at 19:27 +0530, Durgadoss R wrote:
>> To support USB type C alternate DP mode, the display driver needs to
>> know the number of lanes required by the DP panel as well as number
>> of lanes that can be supported by the type-C cable. Sometimes, the
>> type-C cable may limit the bandwidth even if Panel can support
>> more lanes. To address these scenarios, the display driver will
>> start link training with max lanes, and if that fails, the driver
>> falls back to x2 lanes; and repeats this procedure for all
>> bandwidth/lane configurations.
>>
>> * Since link training is done before modeset only the port
>>   (and not pipe/planes) and its associated PLLs are enabled.
>> * On DP hotplug: Directly start link training on the crtc
>>   associated with the DP encoder.
>> * On Connected boot scenarios: When booted with an LFP and a DP,
>>   typically, BIOS brings up DP. In these cases, we disable the
>>   crtc, do upfront link training and then re-enable it back.
>> * All local changes made for upfront link training are reset
>>   to their previous values once it is done; so that the
>>   subsequent modeset is not aware of these changes.
>>
>
>Please always include a changelog when sending a new version of a patch.

Sure, will add it in the next version.

>
>> Signed-off-by: Durgadoss R <durgados...@intel.com>
>> ---
>>  drivers/gpu/drm/i915/intel_ddi.c | 102 +
>>  drivers/gpu/drm/i915/intel_display.c |  38 ++-
>>  drivers/gpu/drm/i915/intel_dp.c  | 122 
>> ++
>> -
>>  drivers/gpu/drm/i915/intel_drv.h |  10 +++
>>  4 files changed, 270 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
>> b/drivers/gpu/drm/i915/intel_ddi.c
>> index 3fb9a03..cc5cad5 100644
>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> @@ -3217,6 +3217,108 @@ intel_ddi_init_hdmi_connector(struct
>> intel_digital_port *intel_dig_port)
>>  return connector;
>>  }
>>
>> +static void intel_ddi_commit_upfront_pll_config(struct intel_dp *intel_dp,
>> +struct intel_shared_dpll *pll)
>> +{
>> +struct intel_shared_dpll_config tmp_config;
>> +
>> +/*
>> + * The shared_dpll_config is computed in intel_get_shared_dpll().
>> + * It is committed to 'pll->config' here to be used in
>> + * intel_enable/disable_shared_dpll functions. Before committing.
>> + * save the existing config, so that once upfront link training is
>> + * done, the original value of 'pll->config' can be restored.
>> + */
>> +tmp_config = pll->config;
>> +pll->config = intel_dp->upfront_pll_config;
>> +intel_dp->upfront_pll_config = tmp_config;
>> +}
>> +
>> +static struct intel_shared_dpll *intel_ddi_select_upfront_pll_config(
>> +struct intel_dp *intel_dp, struct intel_crtc *crtc)
>> +{
>> +if (!intel_ddi_pll_select(crtc, crtc->config))
>> +return NULL;
>> +
>> +return intel_crtc_to_shared_dpll(crtc);
>> +}
>> +
>> +static void intel_ddi_clear_upfront_pll_config(struct intel_dp *intel_dp,
>> +struct intel_shared_dpll *pll)
>> +{
>> +pll->config = intel_dp->upfront_pll_config;
>> +}
>> +
>
>The shared pll interface is really getting in the way here. And BXT plls aren't
>even shared. We are jumping through hoops to get the pll that matches the given
>encoder and to call the code that calculates the dpll_hw_state based on the DP
>link rate. I'd like to get that interface fixed but I reckon it will be tricky
>to find something that works for all the platforms we support. That's the next
>thing on my todo list.
>
>If we have to live with some intermediary solution, I think it would be better
>to (almost) completely bypass the shared dpll stuff. First we would need to
>split bxt_ddi_pll_sel() so that we would have a function that takes the link
>bandwidth and spits out a dpll_hw_state without looking at crtc_state. Then we
>would just take the right pll based on dig_port->port, make sure it is not 
>being

Re: [Intel-gfx] [PATCH 5/7] drm/i915/dp: Add methods to update link train params

[R, Durgadoss]

>-Original Message-
>From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
>Sent: Monday, January 11, 2016 8:07 PM
>To: R, Durgadoss; intel-gfx@lists.freedesktop.org
>Subject: Re: [PATCH 5/7] drm/i915/dp: Add methods to update link train params
>
>On Fri, 2015-12-11 at 15:09 +0530, Durgadoss R wrote:
>> Retrying with reduced lanes/bw and updating the final
>> available lanes/bw to DPCD is needed for upfront link
>> train logic. Hence, this patch adds these methods
>> and exports them so that these can be called from
>> other files like ddi.c/display.c.
>>
>> Signed-off-by: Durgadoss R <durgados...@intel.com>
>> ---
>>  drivers/gpu/drm/i915/intel_dp.c  | 34 ++
>>  drivers/gpu/drm/i915/intel_drv.h |  2 ++
>>  2 files changed, 36 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c 
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index f335c92..d8f7830 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -1660,6 +1660,40 @@ void intel_dp_set_link_params(struct intel_dp
>> *intel_dp,
>>  intel_dp->lane_count = pipe_config->lane_count;
>>  }
>>
>> +void intel_dp_update_dpcd_params(struct intel_dp *intel_dp)
>> +{
>> +intel_dp->dpcd[DP_MAX_LANE_COUNT] &= ~DP_MAX_LANE_COUNT_MASK;
>> +intel_dp->dpcd[DP_MAX_LANE_COUNT] |=
>> +intel_dp->lane_count & DP_MAX_LANE_COUNT_MASK;
>> +
>> +intel_dp->dpcd[DP_MAX_LINK_RATE] =
>> +drm_dp_link_rate_to_bw_code(intel_dp->link_rate);
>> +}
>> +
>> +bool intel_dp_get_link_retry_params(uint8_t *lane_count, uint8_t *link_bw)
>> +{
>> +/*
>> + * As per DP1.3 Spec, retry all link rates for a particular
>> + * lane count value, before reducing number of lanes.
>> + */
>> +if (*link_bw == DP_LINK_BW_5_4) {
>> +*link_bw = DP_LINK_BW_2_7;
>> +} else if (*link_bw == DP_LINK_BW_2_7) {
>> +*link_bw = DP_LINK_BW_1_62;
>> +} else if (*lane_count == 4) {
>> +*lane_count = 2;
>> +*link_bw = DP_LINK_BW_5_4;
>> +} else if (*lane_count == 2) {
>> +*lane_count = 1;
>> +*link_bw = DP_LINK_BW_5_4;
>
>If the sink doesn't support 5.4 Gbps, shouldn't we skip that rate?
>
>Also, it would be easier to review these functions if they were in same patch
>were they are used.

Ok, will take care of this next version.

Thanks,
Durga

>
>Ander
>
>> +} else {
>> +/* Tried all combinations, so exit */
>> +return false;
>> +}
>> +
>> +return true;
>> +}
>> +
>>  static void intel_dp_prepare(struct intel_encoder *encoder)
>>  {
>>  struct drm_device *dev = encoder->base.dev;
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index faa91fc..5cefb0e 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -1233,6 +1233,8 @@ bool intel_dp_init_connector(struct intel_digital_port
>> *intel_dig_port,
>>   struct intel_connector *intel_connector);
>>  void intel_dp_set_link_params(struct intel_dp *intel_dp,
>>const struct intel_crtc_state *pipe_config);
>> +void intel_dp_update_dpcd_params(struct intel_dp *intel_dp);
>> +bool intel_dp_get_link_retry_params(uint8_t *lane_count, uint8_t *link_bw);
>>  void intel_dp_start_link_train(struct intel_dp *intel_dp);
>>  void intel_dp_stop_link_train(struct intel_dp *intel_dp);
>>  void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 7/7] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

[R, Durgadoss]

>-Original Message-
>From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
>Sent: Monday, January 11, 2016 8:46 PM
>To: R, Durgadoss; intel-gfx@lists.freedesktop.org
>Subject: Re: [PATCH 7/7] drm/i915/dp: Enable Upfront link training for typeC 
>DP support on BXT
>
>On Fri, 2015-12-11 at 15:09 +0530, Durgadoss R wrote:
>> To support USB type C alternate DP mode, the display driver needs to
>> know the number of lanes required by the DP panel as well as number
>> of lanes that can be supported by the type-C cable. Sometimes, the
>> type-C cable may limit the bandwidth even if Panel can support
>> more lanes. To address these scenarios, the display driver will
>> start link training with max lanes, and if that fails, the driver
>> falls back to x2 lanes; and repeats this procedure for all
>> bandwidth/lane configurations.
>>
>> * Since link training is done before modeset only the port
>>   (and not pipe/planes) and its associated PLLs are enabled.
>> * On DP hotplug: Directly start link training on the crtc
>>   associated with the DP encoder.
>> * On Connected boot scenarios: When booted with an LFP and a DP,
>>   typically, BIOS brings up DP. In these cases, we disable the
>>   crtc, do upfront link training and then re-enable it back.
>> * All local changes made for upfront link training are reset
>>   to their previous values once it is done; so that the
>>   subsequent modeset is not aware of these changes.
>>
>> Signed-off-by: Durgadoss R <durgados...@intel.com>
>> ---
>>  drivers/gpu/drm/i915/intel_ddi.c | 81
>> 
>>  drivers/gpu/drm/i915/intel_dp.c  | 77 +-
>>  drivers/gpu/drm/i915/intel_drv.h |  2 +
>>  3 files changed, 159 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
>> b/drivers/gpu/drm/i915/intel_ddi.c
>> index 632044a..43efc26 100644
>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> @@ -3274,6 +3274,87 @@ intel_ddi_init_hdmi_connector(struct 
>> intel_digital_port
>> *intel_dig_port)
>>  return connector;
>>  }
>>
>> +bool intel_ddi_upfront_link_train(struct intel_dp *intel_dp,
>> +struct intel_crtc *crtc)
>> +{
>> +struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>> +struct intel_connector *connector = intel_dp->attached_connector;
>> +struct intel_encoder *encoder = connector->encoder;
>> +struct drm_device *dev = encoder->base.dev;
>> +struct drm_i915_private *dev_priv = dev->dev_private;
>> +struct intel_shared_dpll *pll;
>> +struct drm_crtc *drm_crtc = NULL;
>> +struct intel_crtc_state *tmp_crtc_config;
>> +struct intel_dpll_hw_state tmp_dpll_hw_state;
>> +uint8_t link_bw, lane_count;
>> +
>> +if (!crtc) {
>> +drm_crtc = intel_get_unused_crtc(>base);
>> +if (!drm_crtc) {
>> +DRM_ERROR("No crtc for upfront link training\n");
>> +return false;
>> +}
>> +encoder->base.crtc = drm_crtc;
>> +crtc = to_intel_crtc(drm_crtc);
>> +}
>> +
>> +/* Initialize with Max Link rate & lane count supported by panel */
>> +link_bw =  intel_dp->dpcd[DP_MAX_LINK_RATE];
>> +lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
>> +
>> +/* Save the crtc->config */
>> +tmp_crtc_config = crtc->config;
>> +tmp_dpll_hw_state = crtc->config->dpll_hw_state;
>> +
>> +/* Select the shared DPLL to use for this port */
>> +intel_get_ddi_pll(dev_priv, dig_port->port, crtc->config);
>> +pll = intel_crtc_to_shared_dpll(crtc);
>> +if (!pll) {
>> +DRM_ERROR("Could not get shared DPLL\n");
>> +goto exit;
>> +}
>> +DRM_DEBUG_KMS("Using %s for pipe %c\n", pll->name, pipe_name(crtc
>> ->pipe));
>> +
>> +do {
>> +crtc->config->port_clock =
>> drm_dp_bw_code_to_link_rate(link_bw);
>> +crtc->config->lane_count = lane_count;
>> +if (!intel_ddi_pll_select(crtc, crtc->config, encoder,
>> false))
>> +goto exit;
>> +
>> +pll->config.crtc_mask |= (1 << crtc->pipe);
>> +pll->config.hw_state = crtc->config->dpll_hw_state;
>> +
>> +   

Re: [Intel-gfx] [PATCH 7/7] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

[R, Durgadoss]

>-Original Message-
>From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
>Sent: Monday, January 11, 2016 7:40 PM
>To: R, Durgadoss; intel-gfx@lists.freedesktop.org
>Subject: Re: [PATCH 7/7] drm/i915/dp: Enable Upfront link training for typeC 
>DP support on BXT
>
>On Tue, 2015-12-29 at 18:50 +, R, Durgadoss wrote:
>> Hi Ander,
>>
>> Thanks for looking into this..
>>
>> > -Original Message-
>> > From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
>> > Sent: Tuesday, December 29, 2015 10:52 PM
>> > To: R, Durgadoss; intel-gfx@lists.freedesktop.org
>> > Subject: Re: [PATCH 7/7] drm/i915/dp: Enable Upfront link training for 
>> > typeC
>> > DP support on BXT
>> >
>> > On Fri, 2015-12-11 at 15:09 +0530, Durgadoss R wrote:
>> > > To support USB type C alternate DP mode, the display driver needs to
>> > > know the number of lanes required by the DP panel as well as number
>> > > of lanes that can be supported by the type-C cable. Sometimes, the
>> > > type-C cable may limit the bandwidth even if Panel can support
>> > > more lanes. To address these scenarios, the display driver will
>> > > start link training with max lanes, and if that fails, the driver
>> > > falls back to x2 lanes; and repeats this procedure for all
>> > > bandwidth/lane configurations.
>> > >
>> > > * Since link training is done before modeset only the port
>> > >   (and not pipe/planes) and its associated PLLs are enabled.
>> > > * On DP hotplug: Directly start link training on the crtc
>> > >   associated with the DP encoder.
>> > > * On Connected boot scenarios: When booted with an LFP and a DP,
>> > >   typically, BIOS brings up DP. In these cases, we disable the
>> > >   crtc, do upfront link training and then re-enable it back.
>> > > * All local changes made for upfront link training are reset
>> > >   to their previous values once it is done; so that the
>> > >   subsequent modeset is not aware of these changes.
>> > >
>> > > Signed-off-by: Durgadoss R <durgados...@intel.com>
>> > > ---
>> > >  drivers/gpu/drm/i915/intel_ddi.c | 81
>> > > 
>> > >  drivers/gpu/drm/i915/intel_dp.c  | 77
>> > > +-
>> > >  drivers/gpu/drm/i915/intel_drv.h |  2 +
>> > >  3 files changed, 159 insertions(+), 1 deletion(-)
>> > >
>> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
>> > > b/drivers/gpu/drm/i915/intel_ddi.c
>> > > index 632044a..43efc26 100644
>> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
>> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> > > @@ -3274,6 +3274,87 @@ intel_ddi_init_hdmi_connector(struct
>> > > intel_digital_port
>> > > *intel_dig_port)
>> > >  return connector;
>> > >  }
>> > >
>> > > +bool intel_ddi_upfront_link_train(struct intel_dp *intel_dp,
>> > > +struct intel_crtc *crtc)
>> > > +{
>> > > +struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>> > > +struct intel_connector *connector = 
>> > > intel_dp->attached_connector;
>> > > +struct intel_encoder *encoder = connector->encoder;
>> > > +struct drm_device *dev = encoder->base.dev;
>> > > +struct drm_i915_private *dev_priv = dev->dev_private;
>> > > +struct intel_shared_dpll *pll;
>> > > +struct drm_crtc *drm_crtc = NULL;
>> > > +struct intel_crtc_state *tmp_crtc_config;
>> > > +struct intel_dpll_hw_state tmp_dpll_hw_state;
>> > > +uint8_t link_bw, lane_count;
>> > > +
>> > > +if (!crtc) {
>> > > +drm_crtc = intel_get_unused_crtc(>base);
>> > > +if (!drm_crtc) {
>> > > +DRM_ERROR("No crtc for upfront link 
>> > > training\n");
>> > > +return false;
>> > > +}
>> > > +encoder->base.crtc = drm_crtc;
>> > > +crtc = to_intel_crtc(drm_crtc);
>> > > +}
>> > > +
>> > > +/* Initialize with Max Link rate & lane count sup

Re: [Intel-gfx] [PATCH 7/7] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

[R, Durgadoss]

Hi Ander,

Thanks for looking into this..

>-Original Message-
>From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
>Sent: Tuesday, December 29, 2015 10:52 PM
>To: R, Durgadoss; intel-gfx@lists.freedesktop.org
>Subject: Re: [PATCH 7/7] drm/i915/dp: Enable Upfront link training for typeC 
>DP support on BXT
>
>On Fri, 2015-12-11 at 15:09 +0530, Durgadoss R wrote:
>> To support USB type C alternate DP mode, the display driver needs to
>> know the number of lanes required by the DP panel as well as number
>> of lanes that can be supported by the type-C cable. Sometimes, the
>> type-C cable may limit the bandwidth even if Panel can support
>> more lanes. To address these scenarios, the display driver will
>> start link training with max lanes, and if that fails, the driver
>> falls back to x2 lanes; and repeats this procedure for all
>> bandwidth/lane configurations.
>>
>> * Since link training is done before modeset only the port
>>   (and not pipe/planes) and its associated PLLs are enabled.
>> * On DP hotplug: Directly start link training on the crtc
>>   associated with the DP encoder.
>> * On Connected boot scenarios: When booted with an LFP and a DP,
>>   typically, BIOS brings up DP. In these cases, we disable the
>>   crtc, do upfront link training and then re-enable it back.
>> * All local changes made for upfront link training are reset
>>   to their previous values once it is done; so that the
>>   subsequent modeset is not aware of these changes.
>>
>> Signed-off-by: Durgadoss R <durgados...@intel.com>
>> ---
>>  drivers/gpu/drm/i915/intel_ddi.c | 81
>> 
>>  drivers/gpu/drm/i915/intel_dp.c  | 77 +-
>>  drivers/gpu/drm/i915/intel_drv.h |  2 +
>>  3 files changed, 159 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
>> b/drivers/gpu/drm/i915/intel_ddi.c
>> index 632044a..43efc26 100644
>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> @@ -3274,6 +3274,87 @@ intel_ddi_init_hdmi_connector(struct 
>> intel_digital_port
>> *intel_dig_port)
>>  return connector;
>>  }
>>
>> +bool intel_ddi_upfront_link_train(struct intel_dp *intel_dp,
>> +struct intel_crtc *crtc)
>> +{
>> +struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>> +struct intel_connector *connector = intel_dp->attached_connector;
>> +struct intel_encoder *encoder = connector->encoder;
>> +struct drm_device *dev = encoder->base.dev;
>> +struct drm_i915_private *dev_priv = dev->dev_private;
>> +struct intel_shared_dpll *pll;
>> +struct drm_crtc *drm_crtc = NULL;
>> +struct intel_crtc_state *tmp_crtc_config;
>> +struct intel_dpll_hw_state tmp_dpll_hw_state;
>> +uint8_t link_bw, lane_count;
>> +
>> +if (!crtc) {
>> +drm_crtc = intel_get_unused_crtc(>base);
>> +if (!drm_crtc) {
>> +DRM_ERROR("No crtc for upfront link training\n");
>> +return false;
>> +}
>> +encoder->base.crtc = drm_crtc;
>> +crtc = to_intel_crtc(drm_crtc);
>> +}
>> +
>> +/* Initialize with Max Link rate & lane count supported by panel */
>> +link_bw =  intel_dp->dpcd[DP_MAX_LINK_RATE];
>> +lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
>> +
>> +/* Save the crtc->config */
>> +tmp_crtc_config = crtc->config;
>
>> +tmp_dpll_hw_state = crtc->config->dpll_hw_state;
>> +
>> +/* Select the shared DPLL to use for this port */
>> +intel_get_ddi_pll(dev_priv, dig_port->port, crtc->config)
>
>This reads the current programmed DPLL from the hardware. Is there any reason 
>we
>can't trust the value that is in crtc->config already? I don't think this code
>would run before reading out and sanitizing the hardware state.

I was not sure of what will be the DPLL attached to crtc->config when the
crtc is found by 'get_unused_crtc' logic. So, we select the DPLL based
on port again..

>
>> ;
>> +pll = intel_crtc_to_shared_dpll(crtc);
>> +if (!pll) {
>> +DRM_ERROR("Could not get shared DPLL\n");
>> +goto exit;
>> +}
>> +DRM_DEBUG_KMS("Using %s for pipe %c\n", pll->name, pipe_name(crtc
>> ->pipe));
>> +
>> +do {
>

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Remove PSR Perf Counter for SKL+

[R, Durgadoss]

>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
>Rodrigo Vivi
>Sent: Thursday, November 19, 2015 6:10 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH 2/3] drm/i915: Remove PSR Perf Counter for SKL+
>
>Whenever DMC firmware put the HW into DC State a bunch
>of registers including this perf counter is reset to 0 and
>never restored.
>
>So, even with PSR active and working we could still read
>"Performance_Counter: 0" what will misslead people to believe
>PSR is broken.
>
>So, it is better to remove this counter information while
>we don't have a better way to track PSR residency.

Agreed..

Reviewed-by: Durgadoss R 

Thanks,
Durga

>
>Signed-off-by: Rodrigo Vivi 
>---
> drivers/gpu/drm/i915/i915_debugfs.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
>b/drivers/gpu/drm/i915/i915_debugfs.c
>index 038d5c6..71e1666 100644
>--- a/drivers/gpu/drm/i915/i915_debugfs.c
>+++ b/drivers/gpu/drm/i915/i915_debugfs.c
>@@ -2580,8 +2580,11 @@ static int i915_edp_psr_status(struct seq_file *m, void 
>*data)
>   }
>   seq_puts(m, "\n");
>
>-  /* CHV PSR has no kind of performance counter */
>-  if (HAS_DDI(dev)) {
>+  /*
>+   * VLV/CHV PSR has no kind of performance counter
>+   * SKL+ Perf counter is reset to 0 everytime DC state is entered
>+   */
>+  if (IS_HASWELL(dev) || IS_BROADWELL(dev)) {
>   psrperf = I915_READ(EDP_PSR_PERF_CNT) &
>   EDP_PSR_PERF_CNT_MASK;
>
>--
>2.4.3
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Also delay first activation for SKL+

[R, Durgadoss]

>-Original Message-
>From: Vivi, Rodrigo
>Sent: Thursday, November 19, 2015 6:10 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Vivi, Rodrigo; R, Durgadoss
>Subject: [PATCH 1/3] drm/i915: Also delay first activation for SKL+
>
>In certain platforms we face strange and different issues
>when activating PSR right after a modeset so quickly.
>So we delayed the first activation for the platforms
>where we saw the issues with 'commit d0ac896a477d
>("drm/i915: Delay first PSR activation.")'.
>
>So, let's apply the same delay on first activation
>for SKL+ so we avoid any kind of confusion and
>handle similar implentations in the same way.

Thanks for the quick change Rodrigo!! 

Reviewed-by: Durgadoss R <durgados...@intel.com>

Thanks,
Durga

>
>Cc: Durgadoss R <durgados...@intel.com>
>Signed-off-by: Rodrigo Vivi <rodrigo.v...@intel.com>
>---
> drivers/gpu/drm/i915/intel_psr.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_psr.c 
>b/drivers/gpu/drm/i915/intel_psr.c
>index 465d36b..38ea4d0 100644
>--- a/drivers/gpu/drm/i915/intel_psr.c
>+++ b/drivers/gpu/drm/i915/intel_psr.c
>@@ -420,9 +420,6 @@ void intel_psr_enable(struct intel_dp *intel_dp)
>
>   /* Enable PSR on the panel */
>   hsw_psr_enable_sink(intel_dp);
>-
>-  if (INTEL_INFO(dev)->gen >= 9)
>-  intel_psr_activate(intel_dp);
>   } else {
>   vlv_psr_setup_vsc(intel_dp);
>
>@@ -441,15 +438,14 @@ void intel_psr_enable(struct intel_dp *intel_dp)
>   /*
>* FIXME: Activation should happen immediately since this function
>* is just called after pipe is fully trained and enabled.
>-   * However on every platform we face issues when first activation
>+   * However on some platforms we face issues when first activation
>* follows a modeset so quickly.
>* - On VLV/CHV we get bank screen on first activation
>* - On HSW/BDW we get a recoverable frozen screen until next
>*   exit-activate sequence.
>*/
>-  if (INTEL_INFO(dev)->gen < 9)
>-  schedule_delayed_work(_priv->psr.work,
>-
>msecs_to_jiffies(intel_dp->panel_power_cycle_delay * 5));
>+  schedule_delayed_work(_priv->psr.work,
>+
>msecs_to_jiffies(intel_dp->panel_power_cycle_delay * 5));
>
>   dev_priv->psr.enabled = intel_dp;
> unlock:
>--
>2.4.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Delay first PSR activation.

[R, Durgadoss]

>-Original Message-
>From: Vivi, Rodrigo
>Sent: Friday, November 13, 2015 3:08 AM
>To: intel-gfx@lists.freedesktop.org; R, Durgadoss
>Subject: Re: [Intel-gfx] [PATCH 1/4] drm/i915: Delay first PSR activation.
>
>On Thu, 2015-11-12 at 13:50 +, R, Durgadoss wrote:
>> Hi Rodrigo,
>>
>> > -Original Message-
>> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
>> > Behalf Of Rodrigo Vivi
>> > Sent: Thursday, November 12, 2015 1:07 AM
>> > To: intel-gfx@lists.freedesktop.org
>> > Cc: Vivi, Rodrigo
>> > Subject: [Intel-gfx] [PATCH 1/4] drm/i915: Delay first PSR
>> > activation.
>> >
>> > When debuging the frozen screen caused by HW tracking with low
>> > power state I noticed that if we keep moving the mouse non stop
>> > you will miss the screen updates for a while. At least
>> > until we stop moving the mouse for a small time and move again.
>> >
>> > The actual enabling should happen immediately after
>> > Display Port enabling sequence finished with links trained and
>> > everything enabled. However we face many issues when enabling PSR
>> > right after a modeset.
>> >
>> > On VLV/CHV we face blank screens on this scenario and on HSW+
>> > we face a recoverable frozen screen, at least until next
>> > exit-activate sequence.
>> >
>> > Another workaround for the same issue here would be to increase
>> > re-enable idle time from 100 to 500 as we did for VLV/CHV.
>> > However this patch workaround this issue in a better
>> > way since it doesn't reduce PSR residency and also
>> > allow us to reduce the delay time between re-enables at least
>> > on VLV/CHV.
>> >
>> > This is also important to make the sysfs toggle working properly.
>> >
>> > Signed-off-by: Rodrigo Vivi <rodrigo.v...@intel.com>
>> > ---
>> > drivers/gpu/drm/i915/intel_psr.c | 18 --
>> > 1 file changed, 16 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
>> > b/drivers/gpu/drm/i915/intel_psr.c
>> > index 213581c..6b24c24 100644
>> > --- a/drivers/gpu/drm/i915/intel_psr.c
>> > +++ b/drivers/gpu/drm/i915/intel_psr.c
>> > @@ -427,6 +427,19 @@ void intel_psr_enable(struct intel_dp
>> > *intel_dp)
>> >vlv_psr_enable_source(intel_dp);
>> >}
>> >
>> > +  /*
>> > +   * FIXME: Activation should happen immediately since this
>> > function
>> > +   * is just called after pipe is fully trained and enabled.
>> > +   * However on every platform we face issues when first
>> > activation
>> > +   * follows a modeset so quickly.
>> > +   * - On VLV/CHV we get bank screen on first activation
>> > +   * - On HSW/BDW we get a recoverable frozen screen
>> > until next
>> > +   *   exit-activate sequence.
>> > +   */
>> > +  if (INTEL_INFO(dev)->gen < 9)
>> > +  schedule_delayed_work(_priv->psr.work,
>> > +msecs_to_jiffies(intel_dp
>> > ->panel_power_cycle_delay * 5));
>> > +
>> >dev_priv->psr.enabled = intel_dp;

Should we set this before scheduling the delayed work ?

>> > unlock:
>> >mutex_unlock(_priv->psr.lock);
>> > @@ -735,8 +748,9 @@ void intel_psr_flush(struct drm_device *dev,
>> >}
>> >
>> >if (!dev_priv->psr.active && !dev_priv
>> > ->psr.busy_frontbuffer_bits)
>> > -  schedule_delayed_work(_priv->psr.work,
>> > -msecs_to_jiffies(delay_ms));
>> > +  if (!work_busy(_priv->psr.work.work))
>> > +  schedule_delayed_work(_priv->psr.work,
>> > +
>> >  msecs_to_jiffies(delay_ms));
>>
>> Agree with the theory of the patch as such.. But, Is there any
>> specific reason for
>> the !work_busy() check here ?
>>
>> I believe when the later work runs, it will anyway bail out in
>> _activate
>> function, if it sees PSR_ENABLE bit set already. So, is this check
>> just to
>> prevent scheduling one more work item when there is one pending
>> already ? (or it helps in something else also ?)
>
>The !work_busy is to prevent that eventual _activate call reduce the
>first activation time.

Yes, this is what I understood from the code. Just wanted to confirm whether
you meant the same.

The othe

Re: [Intel-gfx] [PATCH 0/4] PSR Critical fixes

[R, Durgadoss]

>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
>Rodrigo Vivi
>Sent: Thursday, November 12, 2015 1:07 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH 0/4] PSR Critical fixes
>
>Let's split critical PSR fixes from the series that contains other
>reworks, stabilization and improvements.

That really helped in review ;-)

For patches 2,3,4 in this series:

Reviewed-by: Durgadoss R 

Thanks,
Durga

>
>The second patch in this series isn't considered critical in terms
>of functionality, but it depends on the first one and it can be consider
>a fix for PSR residency on VLV/CHV.
>
>Thanks,
>Rodrigo.
>
>Rodrigo Vivi (4):
>  drm/i915: Delay first PSR activation.
>  drm/i915: Reduce PSR re-activation time for VLV/CHV.
>  drm/i915: PSR: Don't Skip aux handshake on DP_PSR_NO_TRAIN_ON_EXIT.
>  drm/i915: Send TP1 TP2/3 even when panel claims no NO_TRAIN_ON_EXIT.
>
> drivers/gpu/drm/i915/intel_psr.c | 24 
> 1 file changed, 16 insertions(+), 8 deletions(-)
>
>--
>2.4.3
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Delay first PSR activation.

[R, Durgadoss]

Hi Rodrigo,

>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
>Rodrigo Vivi
>Sent: Thursday, November 12, 2015 1:07 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH 1/4] drm/i915: Delay first PSR activation.
>
>When debuging the frozen screen caused by HW tracking with low
>power state I noticed that if we keep moving the mouse non stop
>you will miss the screen updates for a while. At least
>until we stop moving the mouse for a small time and move again.
>
>The actual enabling should happen immediately after
>Display Port enabling sequence finished with links trained and
>everything enabled. However we face many issues when enabling PSR
>right after a modeset.
>
>On VLV/CHV we face blank screens on this scenario and on HSW+
>we face a recoverable frozen screen, at least until next
>exit-activate sequence.
>
>Another workaround for the same issue here would be to increase
>re-enable idle time from 100 to 500 as we did for VLV/CHV.
>However this patch workaround this issue in a better
>way since it doesn't reduce PSR residency and also
>allow us to reduce the delay time between re-enables at least
>on VLV/CHV.
>
>This is also important to make the sysfs toggle working properly.
>
>Signed-off-by: Rodrigo Vivi 
>---
> drivers/gpu/drm/i915/intel_psr.c | 18 --
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_psr.c 
>b/drivers/gpu/drm/i915/intel_psr.c
>index 213581c..6b24c24 100644
>--- a/drivers/gpu/drm/i915/intel_psr.c
>+++ b/drivers/gpu/drm/i915/intel_psr.c
>@@ -427,6 +427,19 @@ void intel_psr_enable(struct intel_dp *intel_dp)
>   vlv_psr_enable_source(intel_dp);
>   }
>
>+  /*
>+   * FIXME: Activation should happen immediately since this function
>+   * is just called after pipe is fully trained and enabled.
>+   * However on every platform we face issues when first activation
>+   * follows a modeset so quickly.
>+   * - On VLV/CHV we get bank screen on first activation
>+   * - On HSW/BDW we get a recoverable frozen screen until next
>+   *   exit-activate sequence.
>+   */
>+  if (INTEL_INFO(dev)->gen < 9)
>+  schedule_delayed_work(_priv->psr.work,
>+
>msecs_to_jiffies(intel_dp->panel_power_cycle_delay * 5));
>+
>   dev_priv->psr.enabled = intel_dp;
> unlock:
>   mutex_unlock(_priv->psr.lock);
>@@ -735,8 +748,9 @@ void intel_psr_flush(struct drm_device *dev,
>   }
>
>   if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits)
>-  schedule_delayed_work(_priv->psr.work,
>-msecs_to_jiffies(delay_ms));
>+  if (!work_busy(_priv->psr.work.work))
>+  schedule_delayed_work(_priv->psr.work,
>+msecs_to_jiffies(delay_ms));

Agree with the theory of the patch as such.. But, Is there any specific reason 
for
the !work_busy() check here ?

I believe when the later work runs, it will anyway bail out in _activate
function, if it sees PSR_ENABLE bit set already. So, is this check just to
prevent scheduling one more work item when there is one pending
already ? (or it helps in something else also ?)

Thanks,
Durga

>   mutex_unlock(_priv->psr.lock);
> }
>
>--
>2.4.3
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFCv2 DP-typeC 5/6] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

[R, Durgadoss]

>-Original Message-
>From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
>Sent: Wednesday, October 21, 2015 9:08 PM
>To: R, Durgadoss; intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [RFCv2 DP-typeC 5/6] drm/i915/dp: Enable Upfront link 
>training for typeC DP
>support on BXT
>
>On Wed, 2015-10-14 at 17:30 +0530, Durgadoss R wrote:
>> To support USB type C alternate DP mode, the display driver needs to
>> know the number of lanes required by the DP panel as well as number
>> of lanes that can be supported by the type-C cable. Sometimes, the
>> type-C cable may limit the bandwidth even if Panel can support
>> more lanes. To address these scenarios, the display driver will
>> start link training with max lanes, and if that fails, the driver
>> falls back to x2 lanes; and repeats this procedure for all
>> bandwidth/lane configurations.
>>
>> * Since link training is done before modeset only the port
>>   (and not pipe/planes) and its associated PLLs are enabled.
>> * Once link training is done, the port and its PLLs are disabled;
>>   so that the subsequent modeset is not aware of these changes.
>> * On DP hotplug: Directly start link training on the crtc
>>   associated with the DP encoder.
>> * On Connected boot scenarios: When booted with an LFP and a DP,
>>   typically, BIOS brings up DP. In these cases, we disable the
>>   crtc first and then start upfront link training. The crtc is
>>   re-enabled as part of a subsequent modeset.
>> * For BXT, ddi->enable/disable for DP only enable/disable
>>   audio codec and hence are not included in upfront link
>>   training sequence.
>> * As of now, this is tested only on BXT A1 platform, on
>>   kernel 4.2-rc2.
>>
>> Signed-off-by: Durgadoss R <durgados...@intel.com>
>> ---
>>  drivers/gpu/drm/i915/intel_ddi.c | 152
>> +++
>>  drivers/gpu/drm/i915/intel_dp.c  |  41 ++-
>>  drivers/gpu/drm/i915/intel_drv.h |   2 +
>>  3 files changed, 194 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
>> b/drivers/gpu/drm/i915/intel_ddi.c
>> index 8e4ea36..b3a9bff 100644
>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> @@ -3209,6 +3209,158 @@ intel_ddi_init_hdmi_connector(struct
>> intel_digital_port *intel_dig_port)
>>  return connector;
>>  }
>>
>> +bool intel_ddi_upfront_link_train(struct drm_device *dev,
>> +struct intel_dp *intel_dp, struct intel_crtc *crtc)
>> +{
>> +struct drm_i915_private *dev_priv = dev->dev_private;
>> +struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>> +struct intel_connector *connector = intel_dp->attached_connector;
>> +struct intel_encoder *tmp_encoder, *encoder = connector->encoder;
>> +struct intel_shared_dpll *pll;
>> +struct intel_crtc *tmp_crtc;
>> +struct drm_crtc *tmp_drm_crtc;
>> +uint8_t tmp_lane_count, tmp_link_bw;
>> +bool ret, found, valid_crtc = false;
>> +
>> +/* For now, we have only SKL and BXT supporting type-C */
>> +if (!IS_BROXTON(dev) || !IS_SKYLAKE(dev))
>> +return true;
>> +
>> +if (!connector || !encoder) {
>> +DRM_DEBUG_KMS("dp connector/encoder is NULL\n");
>> +return false;
>> +}
>> +
>> +/* If we already have a crtc, start link training directly */
>> +if (crtc) {
>> +valid_crtc = true;
>> +goto start_link_train;
>> +}
>> +
>> +/* Find an unused crtc and use it for link training */
>> +for_each_intel_crtc(dev, crtc) {
>> +if (intel_crtc_active(>base))
>> +continue;
>> +
>> +/* Make sure the new crtc will work with the encoder */
>> +if (drm_encoder_crtc_ok(>base, >base)) {
>> +found = true;
>> +
>> +/* Save the existing values */
>> +tmp_encoder = connector->new_encoder;
>> +tmp_crtc = encoder->new_crtc;
>> +tmp_drm_crtc = encoder->base.crtc;
>
>In which case are these different than NULL? I thought at this point there
>hasn't been a modeset in the hotplug case and you disable the crtc on the
>connected on boot case. This will also need to be rebased on atomic.

As far as I tested these, they are NULL in both Hotplug and connected boot
Cases. There was one issue during suspend/resume whe

Re: [Intel-gfx] [RFCv2 DP-typeC 2/6] drm/i915/dp: Reuse shared DPLL if it exists already

[R, Durgadoss]

>-Original Message-
>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>Sent: Wednesday, October 14, 2015 6:53 PM
>To: R, Durgadoss; intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [RFCv2 DP-typeC 2/6] drm/i915/dp: Reuse shared DPLL 
>if it exists already
>
>On Wed, 14 Oct 2015, Durgadoss R <durgados...@intel.com> wrote:
>> Do not call intel_get_shared_dpll() if there exists a
>> valid shared DPLL already.
>>
>> Signed-off-by: Durgadoss R <durgados...@intel.com>
>> ---
>>  drivers/gpu/drm/i915/intel_ddi.c | 70 
>> 
>>  drivers/gpu/drm/i915/intel_display.c |  2 +-
>>  drivers/gpu/drm/i915/intel_drv.h |  2 +-
>>  3 files changed, 42 insertions(+), 32 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
>> b/drivers/gpu/drm/i915/intel_ddi.c
>> index 9098c12..8e4ea36 100644
>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> @@ -1258,7 +1258,8 @@ hsw_ddi_calculate_wrpll(int clock /* in Hz */,
>>  static bool
>>  hsw_ddi_pll_select(struct intel_crtc *intel_crtc,
>> struct intel_crtc_state *crtc_state,
>> -   struct intel_encoder *intel_encoder)
>> +   struct intel_encoder *intel_encoder,
>> +   bool find_dpll)
>>  {
>>  int clock = crtc_state->port_clock;
>>
>> @@ -1278,14 +1279,16 @@ hsw_ddi_pll_select(struct intel_crtc *intel_crtc,
>>
>>  crtc_state->dpll_hw_state.wrpll = val;
>>
>> -pll = intel_get_shared_dpll(intel_crtc, crtc_state);
>> -if (pll == NULL) {
>> -DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
>> - pipe_name(intel_crtc->pipe));
>> -return false;
>> -}
>> +if (find_dpll) {
>> +pll = intel_get_shared_dpll(intel_crtc, crtc_state);
>> +if (pll == NULL) {
>> +DRM_DEBUG_DRIVER("failed to find PLL for pipe 
>> %c\n",
>> + pipe_name(intel_crtc->pipe));
>> +return false;
>> +}
>
>You have to do a *lot* of passing around parameters here. I wonder (and
>really, I don't know) if we could make intel_get_shared_dpll() grow
>smarts about reusing the pll with intel_crtc_to_shared_dpll() when it's
>there already.

Sure. I will try it out and do this change if it works without issues.

Thanks,
Durga

>
>BR,
>Jani.
>
>
>>
>> -crtc_state->ddi_pll_sel = PORT_CLK_SEL_WRPLL(pll->id);
>> +crtc_state->ddi_pll_sel = PORT_CLK_SEL_WRPLL(pll->id);
>> +}
>>  }
>>
>>  return true;
>> @@ -1540,7 +1543,8 @@ skip_remaining_dividers:
>>  static bool
>>  skl_ddi_pll_select(struct intel_crtc *intel_crtc,
>> struct intel_crtc_state *crtc_state,
>> -   struct intel_encoder *intel_encoder)
>> +   struct intel_encoder *intel_encoder,
>> +   bool find_dpll)
>>  {
>>  struct intel_shared_dpll *pll;
>>  uint32_t ctrl1, cfgcr1, cfgcr2;
>> @@ -1594,15 +1598,17 @@ skl_ddi_pll_select(struct intel_crtc *intel_crtc,
>>  crtc_state->dpll_hw_state.cfgcr1 = cfgcr1;
>>  crtc_state->dpll_hw_state.cfgcr2 = cfgcr2;
>>
>> -pll = intel_get_shared_dpll(intel_crtc, crtc_state);
>> -if (pll == NULL) {
>> -DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
>> - pipe_name(intel_crtc->pipe));
>> -return false;
>> -}
>> +if (find_dpll) {
>> +pll = intel_get_shared_dpll(intel_crtc, crtc_state);
>> +if (pll == NULL) {
>> +DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
>> + pipe_name(intel_crtc->pipe));
>> +return false;
>> +}
>>
>> -/* shared DPLL id 0 is DPLL 1 */
>> -crtc_state->ddi_pll_sel = pll->id + 1;
>> +/* shared DPLL id 0 is DPLL 1 */
>> +crtc_state->ddi_pll_sel = pll->id + 1;
>> +}
>>
>>  return true;
>>  }
>> @@ -1632,7 +1638,8 @@ static const struct bxt_clk_div bxt_dp_clk_val[] = {
>>  static bool
>>  bxt_ddi_pll_select(struct intel_crtc *intel_crtc,
>&g

Re: [Intel-gfx] [RFC DP-typeC 0/2] Support USB typeC based DP on BXT

[R, Durgadoss]

>-Original Message-
>From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
>Sent: Tuesday, September 29, 2015 2:35 PM
>To: R, Durgadoss
>Cc: Daniel Vetter; Jani Nikula; intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [RFC DP-typeC 0/2] Support USB typeC based DP on BXT
>
>On Mon, Sep 28, 2015 at 04:48:32PM +, R, Durgadoss wrote:
>> Hi Daniel,
>>
>> >-Original Message-
>> >From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel 
>> >Vetter
>> >Sent: Monday, September 28, 2015 1:50 PM
>> >To: R, Durgadoss
>> >Cc: Daniel Vetter; Jani Nikula; intel-gfx@lists.freedesktop.org
>> >Subject: Re: [Intel-gfx] [RFC DP-typeC 0/2] Support USB typeC based DP on 
>> >BXT
>> >
>> >On Fri, Sep 25, 2015 at 12:22:42PM +, R, Durgadoss wrote:
>> >> Hi Daniel,
>> >>
>> >> Thanks for having a look at it..
>> >>
>> >> >-Original Message-
>> >> >From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel 
>> >> >Vetter
>> >> >Sent: Wednesday, September 23, 2015 3:14 PM
>> >> >To: R, Durgadoss
>> >> >Cc: Jani Nikula; intel-gfx@lists.freedesktop.org
>> >> >Subject: Re: [Intel-gfx] [RFC DP-typeC 0/2] Support USB typeC based DP 
>> >> >on BXT
>> >> >
>> >> >On Wed, Sep 16, 2015 at 10:57:45AM +, R, Durgadoss wrote:
>> >> >> Hi Jani,
>> >> >>
>> >> >> >-Original Message-
>> >> >> >From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>> >> >> >Sent: Wednesday, September 16, 2015 3:18 PM
>> >> >> >To: R, Durgadoss; intel-gfx@lists.freedesktop.org
>> >> >> >Cc: R, Durgadoss
>> >> >> >Subject: Re: [RFC DP-typeC 0/2] Support USB typeC based DP on BXT
>> >> >> >
>> >> >> >On Tue, 15 Sep 2015, Durgadoss R <durgados...@intel.com> wrote:
>> >> >> >> This is an RFC series to start the review/discussion on approach
>> >> >> >> to support USB type C based DP panel.
>> >> >> >>
>> >> >> >> To support USB type C alternate DP mode, the display driver needs to
>> >> >> >> know the number of lanes required by the DP panel as well as number
>> >> >> >> of lanes that can be supported by the type-C cable. Sometimes, the
>> >> >> >> type-C cable may limit the bandwidth even if Panel can support
>> >> >> >> more lanes.
>> >> >> >>
>> >> >> >> The goal is to find out the number of lanes which can be supported
>> >> >> >> using a particular cable so that we can cap 'max_available_lanes'
>> >> >> >> to that number during modeset.
>> >> >> >>
>> >> >> >> These two patches are based on 4.2-rc2 and tested only on
>> >> >> >> a BXT A1 platform for now.
>> >> >> >>
>> >> >> >> Brief summary of the approach taken:
>> >> >> >> ---
>> >> >> >> 1.As soon as DP-hotplug is detected, driver starts link training
>> >> >> >>   with highest number of lanes/bandwidth possible. If it fails,
>> >> >> >>   driver retries link training with lane/2 for same bandwidth.
>> >> >> >>   We continue this procedure until we find a working configuration
>> >> >> >>   of lane/bandwidth values. This 'number of lanes' is then
>> >> >> >>   set as the 'max_available_lanes', so that the following
>> >> >> >>   intel_dp_compute_config() during modeset picks it up as
>> >> >> >>   max_lane_count (instead of 4 always, from DPCD).
>> >> >> >
>> >> >> >Would all of this work automatically if our link training sequence
>> >> >> >followed the DP spec to the letter wrt degrading the link on failures?
>> >> >>
>> >> >> That is one part of it.
>> >> >>
>> >> >> Our intention is also to filter out the modes that cannot be set
>> >> >> with 'max_available_lanes' through connector->mode_valid
>> >> >> callback, which uses these variables. Otherwise

Re: [Intel-gfx] [RFC DP-typeC 0/2] Support USB typeC based DP on BXT

[R, Durgadoss]

Hi Daniel,

>-Original Message-
>From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
>Sent: Monday, September 28, 2015 1:50 PM
>To: R, Durgadoss
>Cc: Daniel Vetter; Jani Nikula; intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [RFC DP-typeC 0/2] Support USB typeC based DP on BXT
>
>On Fri, Sep 25, 2015 at 12:22:42PM +, R, Durgadoss wrote:
>> Hi Daniel,
>>
>> Thanks for having a look at it..
>>
>> >-Original Message-
>> >From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel 
>> >Vetter
>> >Sent: Wednesday, September 23, 2015 3:14 PM
>> >To: R, Durgadoss
>> >Cc: Jani Nikula; intel-gfx@lists.freedesktop.org
>> >Subject: Re: [Intel-gfx] [RFC DP-typeC 0/2] Support USB typeC based DP on 
>> >BXT
>> >
>> >On Wed, Sep 16, 2015 at 10:57:45AM +, R, Durgadoss wrote:
>> >> Hi Jani,
>> >>
>> >> >-Original Message-
>> >> >From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>> >> >Sent: Wednesday, September 16, 2015 3:18 PM
>> >> >To: R, Durgadoss; intel-gfx@lists.freedesktop.org
>> >> >Cc: R, Durgadoss
>> >> >Subject: Re: [RFC DP-typeC 0/2] Support USB typeC based DP on BXT
>> >> >
>> >> >On Tue, 15 Sep 2015, Durgadoss R <durgados...@intel.com> wrote:
>> >> >> This is an RFC series to start the review/discussion on approach
>> >> >> to support USB type C based DP panel.
>> >> >>
>> >> >> To support USB type C alternate DP mode, the display driver needs to
>> >> >> know the number of lanes required by the DP panel as well as number
>> >> >> of lanes that can be supported by the type-C cable. Sometimes, the
>> >> >> type-C cable may limit the bandwidth even if Panel can support
>> >> >> more lanes.
>> >> >>
>> >> >> The goal is to find out the number of lanes which can be supported
>> >> >> using a particular cable so that we can cap 'max_available_lanes'
>> >> >> to that number during modeset.
>> >> >>
>> >> >> These two patches are based on 4.2-rc2 and tested only on
>> >> >> a BXT A1 platform for now.
>> >> >>
>> >> >> Brief summary of the approach taken:
>> >> >> ---
>> >> >> 1.As soon as DP-hotplug is detected, driver starts link training
>> >> >>   with highest number of lanes/bandwidth possible. If it fails,
>> >> >>   driver retries link training with lane/2 for same bandwidth.
>> >> >>   We continue this procedure until we find a working configuration
>> >> >>   of lane/bandwidth values. This 'number of lanes' is then
>> >> >>   set as the 'max_available_lanes', so that the following
>> >> >>   intel_dp_compute_config() during modeset picks it up as
>> >> >>   max_lane_count (instead of 4 always, from DPCD).
>> >> >
>> >> >Would all of this work automatically if our link training sequence
>> >> >followed the DP spec to the letter wrt degrading the link on failures?
>> >>
>> >> That is one part of it.
>> >>
>> >> Our intention is also to filter out the modes that cannot be set
>> >> with 'max_available_lanes' through connector->mode_valid
>> >> callback, which uses these variables. Otherwise, we risk failing
>> >> a modeset that uses higher resolutions than possible.
>> >>
>> >> Sorry, I should have also added this as part of the commit message.
>> >
>> >One approach to implement DP link training to the spec is that if things
>> >fail we enable the pipe anyway (since anything else would seriously
>> >surprise userspace, especially for async modesets, and lead to hangs in
>> >userspace if vblank interrupts don't happen). And then we generate a
>> >hotplug event to inform userspace that something change with the monitor
>> >configuration, to give userspace a chance to look at the filtered mode
>> >list and select a new config it likes.
>> >
>> >That approach would fit rather well into the overall framework of how
>> >detection/mode-config changes are done currently by keeping all the policy
>> >for selecting the precise mode config in userspace. Downside is that for
>> >usb type-C 

Re: [Intel-gfx] [RFC DP-typeC 0/2] Support USB typeC based DP on BXT

[R, Durgadoss]

Hi Daniel,

Thanks for having a look at it..

>-Original Message-
>From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
>Sent: Wednesday, September 23, 2015 3:14 PM
>To: R, Durgadoss
>Cc: Jani Nikula; intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [RFC DP-typeC 0/2] Support USB typeC based DP on BXT
>
>On Wed, Sep 16, 2015 at 10:57:45AM +, R, Durgadoss wrote:
>> Hi Jani,
>>
>> >-Original Message-
>> >From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>> >Sent: Wednesday, September 16, 2015 3:18 PM
>> >To: R, Durgadoss; intel-gfx@lists.freedesktop.org
>> >Cc: R, Durgadoss
>> >Subject: Re: [RFC DP-typeC 0/2] Support USB typeC based DP on BXT
>> >
>> >On Tue, 15 Sep 2015, Durgadoss R <durgados...@intel.com> wrote:
>> >> This is an RFC series to start the review/discussion on approach
>> >> to support USB type C based DP panel.
>> >>
>> >> To support USB type C alternate DP mode, the display driver needs to
>> >> know the number of lanes required by the DP panel as well as number
>> >> of lanes that can be supported by the type-C cable. Sometimes, the
>> >> type-C cable may limit the bandwidth even if Panel can support
>> >> more lanes.
>> >>
>> >> The goal is to find out the number of lanes which can be supported
>> >> using a particular cable so that we can cap 'max_available_lanes'
>> >> to that number during modeset.
>> >>
>> >> These two patches are based on 4.2-rc2 and tested only on
>> >> a BXT A1 platform for now.
>> >>
>> >> Brief summary of the approach taken:
>> >> ---
>> >> 1.As soon as DP-hotplug is detected, driver starts link training
>> >>   with highest number of lanes/bandwidth possible. If it fails,
>> >>   driver retries link training with lane/2 for same bandwidth.
>> >>   We continue this procedure until we find a working configuration
>> >>   of lane/bandwidth values. This 'number of lanes' is then
>> >>   set as the 'max_available_lanes', so that the following
>> >>   intel_dp_compute_config() during modeset picks it up as
>> >>   max_lane_count (instead of 4 always, from DPCD).
>> >
>> >Would all of this work automatically if our link training sequence
>> >followed the DP spec to the letter wrt degrading the link on failures?
>>
>> That is one part of it.
>>
>> Our intention is also to filter out the modes that cannot be set
>> with 'max_available_lanes' through connector->mode_valid
>> callback, which uses these variables. Otherwise, we risk failing
>> a modeset that uses higher resolutions than possible.
>>
>> Sorry, I should have also added this as part of the commit message.
>
>One approach to implement DP link training to the spec is that if things
>fail we enable the pipe anyway (since anything else would seriously
>surprise userspace, especially for async modesets, and lead to hangs in
>userspace if vblank interrupts don't happen). And then we generate a
>hotplug event to inform userspace that something change with the monitor
>configuration, to give userspace a chance to look at the filtered mode
>list and select a new config it likes.
>
>That approach would fit rather well into the overall framework of how
>detection/mode-config changes are done currently by keeping all the policy
>for selecting the precise mode config in userspace. Downside is that for
>usb type-C it would cause flicker since if we only have 2 lanes we'll
>always first try the high-res mode and fail. So I think in the end we need

Yes, agreed.

>both approaches. Wrt the rfc it would be great if we can make it at least
>somewhat platform-agnostic - anything on big core since hsw+ supports

By platform-agnostic,

do you mean to try and implement _upfront_link_train() 
for few more platforms since HSW+ to see how we can re-use common code
if any ?

If it is something else, please elaborate a bit more..

>enabling the DP port without enabling a pipe (because dp mst needs that),
>so could support your approach here too.

We have this kind of implementation tested in CHV and BXT.
Can I consider at least the BXT part as a sample for HSW+ platforms ?

Thanks,
Durga

>-Daniel
>--
>Daniel Vetter
>Software Engineer, Intel Corporation
>http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC DP-typeC 0/2] Support USB typeC based DP on BXT

[R, Durgadoss]

Hi Jani,

>-Original Message-
>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>Sent: Wednesday, September 16, 2015 3:18 PM
>To: R, Durgadoss; intel-gfx@lists.freedesktop.org
>Cc: R, Durgadoss
>Subject: Re: [RFC DP-typeC 0/2] Support USB typeC based DP on BXT
>
>On Tue, 15 Sep 2015, Durgadoss R <durgados...@intel.com> wrote:
>> This is an RFC series to start the review/discussion on approach
>> to support USB type C based DP panel.
>>
>> To support USB type C alternate DP mode, the display driver needs to
>> know the number of lanes required by the DP panel as well as number
>> of lanes that can be supported by the type-C cable. Sometimes, the
>> type-C cable may limit the bandwidth even if Panel can support
>> more lanes.
>>
>> The goal is to find out the number of lanes which can be supported
>> using a particular cable so that we can cap 'max_available_lanes'
>> to that number during modeset.
>>
>> These two patches are based on 4.2-rc2 and tested only on
>> a BXT A1 platform for now.
>>
>> Brief summary of the approach taken:
>> ---
>> 1.As soon as DP-hotplug is detected, driver starts link training
>>   with highest number of lanes/bandwidth possible. If it fails,
>>   driver retries link training with lane/2 for same bandwidth.
>>   We continue this procedure until we find a working configuration
>>   of lane/bandwidth values. This 'number of lanes' is then
>>   set as the 'max_available_lanes', so that the following
>>   intel_dp_compute_config() during modeset picks it up as
>>   max_lane_count (instead of 4 always, from DPCD).
>
>Would all of this work automatically if our link training sequence
>followed the DP spec to the letter wrt degrading the link on failures?

That is one part of it.

Our intention is also to filter out the modes that cannot be set
with 'max_available_lanes' through connector->mode_valid
callback, which uses these variables. Otherwise, we risk failing
a modeset that uses higher resolutions than possible.

Sorry, I should have also added this as part of the commit message.

Thanks,
Durga

>
>BR,
>Jani.
>
>
>>
>> 2.Since we do only link training on hotplug, only the port
>>   and its PLLs are enabled/disabled without touching pipe/
>>   planes etc.
>>
>> 3.For scenarios where we boot with DP connected (along with
>>   an LFP like MIPI/eDP) we disable the crtc and then start
>>   link training, since BIOS brings up DP. The crtc is
>>   enabled back during subsequent modeset. This needs some
>>   changes for latest -nightly branch since we do not have
>>   intel_crtc_control() anymore.
>>
>> 4.Since we are doing the link training on hotplug (as
>>   opposed to during modeset) we named the function
>>   '{chv/bxt/*}_upfront_link_train'. We can also think
>>   of a virtual func for this, inside intel_encoder.
>>
>> Durgadoss R (2):
>>   drm/i915/dp: Make bxt_ddi_pll_select non-static
>>   drm/i915/dp: Enable Upfront link training for type-C DP support
>>
>>  drivers/gpu/drm/i915/intel_ddi.c |  11 +--
>>  drivers/gpu/drm/i915/intel_display.c | 130 
>> +++
>>  drivers/gpu/drm/i915/intel_dp.c  |  22 ++
>>  drivers/gpu/drm/i915/intel_drv.h |   6 ++
>>  4 files changed, 165 insertions(+), 4 deletions(-)
>>
>> --
>> 1.9.1
>>
>
>--
>Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/6] drm/i915/bxt: Fix irq_port for eDP

[R, Durgadoss]

Hi Rodrigo,

I had to add this to get HDMI hotplug working on BXT.
As you might already know, we have the HPD pins A & B
swapped in BXT. And, we are using HPD_PORT_A as
'intel_encoder->hpd_pin' for HDMI on port B.

Without this, When an HPD on HDMI (port B) happens, the interrupt
is handled as an eDP (port A) interrupt in 'intel_hpd_irq_handler',
since hpd_pin for HDMI port B is set as PIN A.

Snippet:
---
is_dig_port = intel_hpd_pin_to_port(i, ) &&
   dev_priv->hotplug.irq_port[port];

---

The issue occurs only when we have eDP + HDMI combination.
MIPI + HDMI works well without this fix also.

And all these workarounds, are due to pin swap in
BXT A0/A1. We have this fix enclosed with that check as well.

I tried to few other changes, but this one was less intrusive
and easy to change (and notice the change).
Kindly let us know if you have better ideas.

Thanks,
Durga

From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Rodrigo Vivi
Sent: Thursday, September 10, 2015 12:54 AM
To: Jindal, Sonika; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 6/6] drm/i915/bxt: Fix irq_port for eDP

Nak: I don't believe we need this... Actually I believe we need the opposite... 
we need to enable HPD on port A for eDP errors handling...




On Fri, Sep 4, 2015 at 6:38 AM Sonika Jindal  wrote:
From: Durgadoss R 

Currently, HDMI hotplug with eDP as local panel is failing
because the HDMI hpd is detected as a long hpd for eDP; and is
thus rightfully ignored. But, it should really be handled as
an interrupt on port B for HDMI (due to BXT A1 platform having
HPD pins A and B swapped). This patch sets the irq_port[PORT_A]
to NULL in case eDP is on port A so that irq handler does not
treat it as a 'dig_port' interrupt.

Signed-off-by: Durgadoss R 
---
 drivers/gpu/drm/i915/intel_ddi.c |   15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 4823184..fec51df 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3218,15 +3218,20 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
                        goto err;

                intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
+               dev_priv->hotplug.irq_port[port] = intel_dig_port;
                /*
                 * On BXT A0/A1, sw needs to activate DDIA HPD logic and
                 * interrupts to check the external panel connection.
+                * If eDP is connected on port A, set irq_port to NULL
+                * so that we do not assume an interrupt here as a
+                * 'dig_port' interrupt.
                 */
-               if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) < BXT_REVID_B0)
-                                        && port == PORT_B)
-                       dev_priv->hotplug.irq_port[PORT_A] = intel_dig_port;
-               else
-                       dev_priv->hotplug.irq_port[port] = intel_dig_port;
+               if (IS_BROXTON(dev) && (INTEL_REVID(dev) < BXT_REVID_B0)) {
+                       if (port == PORT_B)
+                               dev_priv->hotplug.irq_port[PORT_A] = 
intel_dig_port;
+                       else if (intel_encoder->type == INTEL_OUTPUT_EDP)
+                               dev_priv->hotplug.irq_port[port] = NULL;
+               }
        }

        /* In theory we don't need the encoder->type check, but leave it just in
--
1.7.10.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/7] drm/i915: make g4x_digital_port_connected return boolean status

[R, Durgadoss]

-Original Message-
From: Nikula, Jani
Sent: Thursday, August 20, 2015 1:18 PM
To: intel-gfx@lists.freedesktop.org
Cc: R, Durgadoss; Ville Syrjälä; Nikula, Jani
Subject: [PATCH v2 2/7] drm/i915: make g4x_digital_port_connected return 
boolean status

We should not be hitting any of the default cases in
g4x_digital_port_connected, so add MISSING_CASE annotation and return
boolean status. The current behaviour is just cargo culting from the
days of yonder when the display port support was added to i915.


Reviewed-by: Durgadoss R durgados...@intel.com

Thanks,
Durga

Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c | 26 +++---
 1 file changed, 11 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4aa3d664765b..d35dc0711f9b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4518,14 +4518,14 @@ static bool ibx_digital_port_connected(struct 
drm_i915_private *dev_priv,
   return I915_READ(SDEISR)  bit;
 }

-static int g4x_digital_port_connected(struct drm_device *dev,
- struct intel_digital_port 
*intel_dig_port)
+static bool g4x_digital_port_connected(struct drm_device *dev,
+ struct intel_digital_port *port)
 {
   struct drm_i915_private *dev_priv = dev-dev_private;
   uint32_t bit;

   if (IS_VALLEYVIEW(dev)) {
-  switch (intel_dig_port-port) {
+  switch (port-port) {
   case PORT_B:
   bit = PORTB_HOTPLUG_LIVE_STATUS_VLV;
   break;
@@ -4536,10 +4536,11 @@ static int g4x_digital_port_connected(struct 
drm_device *dev,
   bit = PORTD_HOTPLUG_LIVE_STATUS_VLV;
   break;
   default:
-  return -EINVAL;
+  MISSING_CASE(port-port);
+  return false;
   }
   } else {
-  switch (intel_dig_port-port) {
+  switch (port-port) {
   case PORT_B:
   bit = PORTB_HOTPLUG_LIVE_STATUS_G4X;
   break;
@@ -4550,13 +4551,12 @@ static int g4x_digital_port_connected(struct 
drm_device *dev,
   bit = PORTD_HOTPLUG_LIVE_STATUS_G4X;
   break;
   default:
-  return -EINVAL;
+  MISSING_CASE(port-port);
+  return false;
   }
   }

-  if ((I915_READ(PORT_HOTPLUG_STAT)  bit) == 0)
-  return 0;
-  return 1;
+  return I915_READ(PORT_HOTPLUG_STAT)  bit;
 }

 static enum drm_connector_status
@@ -4577,7 +4577,6 @@ g4x_dp_detect(struct intel_dp *intel_dp)
 {
   struct drm_device *dev = intel_dp_to_dev(intel_dp);
   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
-  int ret;

   /* Can't disconnect eDP, but you can close the lid... */
   if (is_edp(intel_dp)) {
@@ -4589,10 +4588,7 @@ g4x_dp_detect(struct intel_dp *intel_dp)
   return status;
   }

-  ret = g4x_digital_port_connected(dev, intel_dig_port);
-  if (ret == -EINVAL)
-  return connector_status_unknown;
-  else if (ret == 0)
+  if (!g4x_digital_port_connected(dev, intel_dig_port))
   return connector_status_disconnected;

   return intel_dp_detect_dpcd(intel_dp);
@@ -5059,7 +5055,7 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
   if (!ibx_digital_port_connected(dev_priv, 
 intel_dig_port))
   goto mst_fail;
   } else {
-  if (g4x_digital_port_connected(dev, intel_dig_port) != 
1)
+  if (!g4x_digital_port_connected(dev, intel_dig_port))
   goto mst_fail;
   }

--
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 3/7] drm/i915: add MISSING_CASE annotation to ibx_digital_port_connected

[R, Durgadoss]

-Original Message-
From: Nikula, Jani
Sent: Thursday, August 20, 2015 1:18 PM
To: intel-gfx@lists.freedesktop.org
Cc: R, Durgadoss; Ville Syrjälä; Nikula, Jani
Subject: [PATCH v2 3/7] drm/i915: add MISSING_CASE annotation to 
ibx_digital_port_connected

With the case added for eDP on port A (always connected from this
function's point of view), we should not be hitting any of the default
cases in ibx_digital_port_connected, so add MISSING_CASE annotation.


For the entire v2 series,
Reviewed-by: Durgadoss R durgados...@intel.com

Thanks,
Durga

Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d35dc0711f9b..f08859471841 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4487,6 +4487,8 @@ static bool ibx_digital_port_connected(struct 
drm_i915_private *dev_priv,

   if (HAS_PCH_IBX(dev_priv-dev)) {
   switch (port-port) {
+  case PORT_A:
+  return true;
   case PORT_B:
   bit = SDE_PORTB_HOTPLUG;
   break;
@@ -4497,10 +4499,13 @@ static bool ibx_digital_port_connected(struct 
drm_i915_private *dev_priv,
   bit = SDE_PORTD_HOTPLUG;
   break;
   default:
-  return true;
+  MISSING_CASE(port-port);
+  return false;
   }
   } else {
   switch (port-port) {
+  case PORT_A:
+  return true;
   case PORT_B:
   bit = SDE_PORTB_HOTPLUG_CPT;
   break;
@@ -4511,7 +4516,8 @@ static bool ibx_digital_port_connected(struct 
drm_i915_private *dev_priv,
   bit = SDE_PORTD_HOTPLUG_CPT;
   break;
   default:
-  return true;
+  MISSING_CASE(port-port);
+  return false;
   }
   }

--
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] drm/i915: add common intel_digital_port_connected function

[R, Durgadoss]

-Original Message-
From: Nikula, Jani
Sent: Wednesday, August 19, 2015 6:04 PM
To: intel-gfx@lists.freedesktop.org
Cc: R, Durgadoss
Subject: Re: [PATCH 2/5] drm/i915: add common intel_digital_port_connected 
function

On Wed, 19 Aug 2015, Jani Nikula jani.nik...@intel.com wrote:
 Add a common intel_digital_port_connected() that splits out to functions
 for different platforms. No functional changes.

 Signed-off-by: Jani Nikula jani.nik...@intel.com
 ---
  drivers/gpu/drm/i915/intel_dp.c | 53 
 ++---
  1 file changed, 28 insertions(+), 25 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_dp.c 
 b/drivers/gpu/drm/i915/intel_dp.c
 index 4aa3d664765b..d48af8b0c84e 100644
 --- a/drivers/gpu/drm/i915/intel_dp.c
 +++ b/drivers/gpu/drm/i915/intel_dp.c
 @@ -4473,15 +4473,8 @@ edp_detect(struct intel_dp *intel_dp)
  return status;
  }

 -/*
 - * ibx_digital_port_connected - is the specified port connected?
 - * @dev_priv: i915 private structure
 - * @port: the port to test
 - *
 - * Returns true if @port is connected, false otherwise.
 - */
 -static bool ibx_digital_port_connected(struct drm_i915_private *dev_priv,
 -   struct intel_digital_port *port)
 +static int ibx_digital_port_connected(struct drm_i915_private *dev_priv,
 +  struct intel_digital_port *port)
  {
  u32 bit;

 @@ -4497,7 +4490,7 @@ static bool ibx_digital_port_connected(struct 
 drm_i915_private *dev_priv,
  bit = SDE_PORTD_HOTPLUG;
  break;
  default:
 -return true;
 +return 1;
  }
  } else {
  switch (port-port) {
 @@ -4511,20 +4504,19 @@ static bool ibx_digital_port_connected(struct 
 drm_i915_private *dev_priv,
  bit = SDE_PORTD_HOTPLUG_CPT;
  break;
  default:
 -return true;
 +return 1;

BTW a follow-up could look into making the ibx/cpt default cases return
-EINVAL like the g4x/vlv/bxt cases do.

But the default case for ibx/cpt currently return 1 .. meaning connected
as default result.. In this case, by returning -EINVAL,
won't we break existing users ?

or,
Can we add a WARN_ON()/MISSING_CASE() and then return -EINVAL ?

Thanks,
Durga


BR,
Jani.


  }
  }

 -return I915_READ(SDEISR)  bit;
 +return I915_READ(SDEISR)  bit ? 1 : 0;
  }

 -static int g4x_digital_port_connected(struct drm_device *dev,
 -   struct intel_digital_port 
 *intel_dig_port)
 +static int g4x_digital_port_connected(struct drm_i915_private *dev_priv,
 +  struct intel_digital_port *intel_dig_port)
  {
 -struct drm_i915_private *dev_priv = dev-dev_private;
  uint32_t bit;

 -if (IS_VALLEYVIEW(dev)) {
 +if (IS_VALLEYVIEW(dev_priv)) {
  switch (intel_dig_port-port) {
  case PORT_B:
  bit = PORTB_HOTPLUG_LIVE_STATUS_VLV;
 @@ -4559,6 +4551,22 @@ static int g4x_digital_port_connected(struct 
 drm_device *dev,
  return 1;
  }

 +/*
 + * intel_digital_port_connected - is the specified port connected?
 + * @dev_priv: i915 private structure
 + * @port: the port to test
 + *
 + * Returns a negative error code on errors, 1 for connected, 0 for 
 disconnected.
 + */
 +static int intel_digital_port_connected(struct drm_i915_private *dev_priv,
 +struct intel_digital_port *port)
 +{
 +if (HAS_PCH_SPLIT(dev_priv))
 +return ibx_digital_port_connected(dev_priv, port);
 +else
 +return g4x_digital_port_connected(dev_priv, port);
 +}
 +
  static enum drm_connector_status
  ironlake_dp_detect(struct intel_dp *intel_dp)
  {
 @@ -4566,7 +4574,7 @@ ironlake_dp_detect(struct intel_dp *intel_dp)
  struct drm_i915_private *dev_priv = dev-dev_private;
  struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);

 -if (!ibx_digital_port_connected(dev_priv, intel_dig_port))
 +if (intel_digital_port_connected(dev_priv, intel_dig_port) != 1)
  return connector_status_disconnected;

  return intel_dp_detect_dpcd(intel_dp);
 @@ -4589,7 +4597,7 @@ g4x_dp_detect(struct intel_dp *intel_dp)
  return status;
  }

 -ret = g4x_digital_port_connected(dev, intel_dig_port);
 +ret = intel_digital_port_connected(dev-dev_private, intel_dig_port);
  if (ret == -EINVAL)
  return connector_status_unknown;
  else if (ret == 0)
 @@ -5055,13 +5063,8 @@ intel_dp_hpd_pulse(struct intel_digital_port 
 *intel_dig_port, bool
long_hpd)
  /* indicate that we need to restart link training */
  intel_dp-train_set_valid = false;

 -if (HAS_PCH_SPLIT(dev)) {
 -if (!ibx_digital_port_connected(dev_priv, 
 intel_dig_port

Re: [Intel-gfx] [PATCH 1/5] drm/i915: move ibx_digital_port_connected to intel_dp.c

[R, Durgadoss]

-Original Message-
From: Nikula, Jani
Sent: Wednesday, August 19, 2015 6:01 PM
To: intel-gfx@lists.freedesktop.org
Cc: R, Durgadoss; Nikula, Jani
Subject: [PATCH 1/5] drm/i915: move ibx_digital_port_connected to intel_dp.c

The function can be made static there. No functional changes.


This clean up series looks good to me.

Reviewed-by: Durgadoss R durgados...@intel.com

Thanks,
Durga

Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/i915/intel_display.c | 45 --
 drivers/gpu/drm/i915/intel_dp.c  | 61 +++-
 drivers/gpu/drm/i915/intel_drv.h |  2 --
 3 files changed, 53 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f604ce1c528b..1a0670259cdf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1061,51 +1061,6 @@ static void intel_wait_for_pipe_off(struct intel_crtc 
*crtc)
   }
 }

-/*
- * ibx_digital_port_connected - is the specified port connected?
- * @dev_priv: i915 private structure
- * @port: the port to test
- *
- * Returns true if @port is connected, false otherwise.
- */
-bool ibx_digital_port_connected(struct drm_i915_private *dev_priv,
-  struct intel_digital_port *port)
-{
-  u32 bit;
-
-  if (HAS_PCH_IBX(dev_priv-dev)) {
-  switch (port-port) {
-  case PORT_B:
-  bit = SDE_PORTB_HOTPLUG;
-  break;
-  case PORT_C:
-  bit = SDE_PORTC_HOTPLUG;
-  break;
-  case PORT_D:
-  bit = SDE_PORTD_HOTPLUG;
-  break;
-  default:
-  return true;
-  }
-  } else {
-  switch (port-port) {
-  case PORT_B:
-  bit = SDE_PORTB_HOTPLUG_CPT;
-  break;
-  case PORT_C:
-  bit = SDE_PORTC_HOTPLUG_CPT;
-  break;
-  case PORT_D:
-  bit = SDE_PORTD_HOTPLUG_CPT;
-  break;
-  default:
-  return true;
-  }
-  }
-
-  return I915_READ(SDEISR)  bit;
-}
-
 static const char *state_string(bool enabled)
 {
   return enabled ? on : off;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d32ce4841654..4aa3d664765b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4473,17 +4473,49 @@ edp_detect(struct intel_dp *intel_dp)
   return status;
 }

-static enum drm_connector_status
-ironlake_dp_detect(struct intel_dp *intel_dp)
+/*
+ * ibx_digital_port_connected - is the specified port connected?
+ * @dev_priv: i915 private structure
+ * @port: the port to test
+ *
+ * Returns true if @port is connected, false otherwise.
+ */
+static bool ibx_digital_port_connected(struct drm_i915_private *dev_priv,
+ struct intel_digital_port *port)
 {
-  struct drm_device *dev = intel_dp_to_dev(intel_dp);
-  struct drm_i915_private *dev_priv = dev-dev_private;
-  struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+  u32 bit;

-  if (!ibx_digital_port_connected(dev_priv, intel_dig_port))
-  return connector_status_disconnected;
+  if (HAS_PCH_IBX(dev_priv-dev)) {
+  switch (port-port) {
+  case PORT_B:
+  bit = SDE_PORTB_HOTPLUG;
+  break;
+  case PORT_C:
+  bit = SDE_PORTC_HOTPLUG;
+  break;
+  case PORT_D:
+  bit = SDE_PORTD_HOTPLUG;
+  break;
+  default:
+  return true;
+  }
+  } else {
+  switch (port-port) {
+  case PORT_B:
+  bit = SDE_PORTB_HOTPLUG_CPT;
+  break;
+  case PORT_C:
+  bit = SDE_PORTC_HOTPLUG_CPT;
+  break;
+  case PORT_D:
+  bit = SDE_PORTD_HOTPLUG_CPT;
+  break;
+  default:
+  return true;
+  }
+  }

-  return intel_dp_detect_dpcd(intel_dp);
+  return I915_READ(SDEISR)  bit;
 }

 static int g4x_digital_port_connected(struct drm_device *dev,
@@ -4528,6 +4560,19 @@ static int g4x_digital_port_connected(struct drm_device 
*dev,
 }

 static enum drm_connector_status
+ironlake_dp_detect(struct intel_dp *intel_dp)
+{
+  struct drm_device *dev = intel_dp_to_dev(intel_dp);
+  struct drm_i915_private *dev_priv = dev-dev_private;
+  struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+
+  if (!ibx_digital_port_connected(dev_priv

Re: [Intel-gfx] [PATCH 0/4] i915 to call hda driver on HDMI plug/unplug

[R, Durgadoss]

Hi David,

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
David Henningsson
Sent: Tuesday, July 21, 2015 1:27 PM
To: alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; 
ti...@suse.de; Vetter, Daniel;
jani.nik...@linux.intel.com
Cc: Koul, Vinod; David Henningsson
Subject: [Intel-gfx] [PATCH 0/4] i915 to call hda driver on HDMI plug/unplug

This patch set aims to resolve three problems:

 * The first - and most serious one - is that the audio driver is not woken up
   properly when in power save modes, especially not when the HDA controller is
   in D3. By having the i915 driver call directly into the hda driver, the HDA
   driver is always notified that an HDMI hotplug event has happened.

 * Second, there is currently no way for userspace to match an HDMI audio 
 output
   with an HDMI video output. We fix this by sending connector_type and
   connector_type_id in the HDMI hotplug callback.

 * Third, writing ELD info to the hardware just so the HDA driver can read it
   from the hardware seems a bit inefficient. We could just pass that 
 information
   in the callback, too.

The patch in its current form fixes the first of these problems and provides 
most
of the infrastructure for the second and third problem.

The patch set is based on 4.2rc2 + my recent codec wakeup patch. So far, it has
been tested (and working) on one Skylake machine.

I believe you tested these patches with hda driver after few cycles of D3.
By any chance, did you also try this once after i915 driver's D3 cycle also ?
In this case, can the check_presence_and_report() function get the
pin presence and ELD valid bits read out properly..?

Thanks,
Durga


David Henningsson (4):
  drm/i915: Add audio hotplug info struct
  drm/i915: Call audio hotplug notify function
  ALSA: hda - Dispatch incoming HDMI hotplug i915 callback
  ALSA: hda - Wake the codec up on hotplug notify events

 drivers/gpu/drm/i915/i915_drv.h|1 +
 drivers/gpu/drm/i915/intel_audio.c |   46 
 include/drm/i915_component.h   |   19 +++
 include/sound/hdaudio.h|4 
 sound/hda/hdac_i915.c  |   24 +++
 sound/pci/hda/patch_hdmi.c |   22 -
 6 files changed, 115 insertions(+), 1 deletion(-)

--
1.7.9.5

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] Removing redundant is_edp_psr

[R, Durgadoss]

-Original Message-
From: Jindal, Sonika
Sent: Thursday, May 7, 2015 9:58 AM
To: intel-gfx@lists.freedesktop.org
Cc: Jindal, Sonika; R, Durgadoss
Subject: [PATCH] Removing redundant is_edp_psr

Since we already store the sink's psr status in dev_priv, use it.
Without this we were ignoring the case where sink supports psr2.

Looks like it is already updated in this patch from Rodrigo:
drm/i915: Add psr_ready on pipe_config
[https://tango.freedesktop.org/patch/45695/]

Thanks,
Durga


Cc: Durgadoss R durgados...@intel.com
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
 drivers/gpu/drm/i915/intel_psr.c |7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c 
b/drivers/gpu/drm/i915/intel_psr.c
index 27608ce..406d3ac 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -56,11 +56,6 @@
 #include intel_drv.h
 #include i915_drv.h

-static bool is_edp_psr(struct intel_dp *intel_dp)
-{
-  return intel_dp-psr_dpcd[0]  DP_PSR_IS_SUPPORTED;
-}
-
 static bool vlv_is_psr_active_on_pipe(struct drm_device *dev, int pipe)
 {
   struct drm_i915_private *dev_priv = dev-dev_private;
@@ -365,7 +360,7 @@ void intel_psr_enable(struct intel_dp *intel_dp)
   return;
   }

-  if (!is_edp_psr(intel_dp)) {
+  if (!dev_priv-psr.sink_support) {
   DRM_DEBUG_KMS(PSR not supported by this panel\n);
   return;
   }
--
1.7.10.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] drm/i915: PSR: Fix DP_PSR_NO_TRAIN_ON_EXIT logic

[R, Durgadoss]

-Original Message-
From: Vivi, Rodrigo
Sent: Friday, April 10, 2015 11:45 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo; R, Durgadoss; Runyan, Arthur J
Subject: [PATCH 2/5] drm/i915: PSR: Fix DP_PSR_NO_TRAIN_ON_EXIT logic

Since the beginning there is a missunderstanding on the meaning of this
dpcd bit.
This bit shouldn't indicate whether to use link standby or not, but just
be used to configure TP1, TP2 and TP3 times and tell hw aux should be skiped
since HW is the responsible one.

Even with help of frontbuffer tracking, HW is still fully responsible for
PSR exit logic with/without DP training.

DP_PSR_NO_TRAIN_ON_EXIT means the source doesn't need to do the training, but
it doesn't tell to avoid TP patterns, so we will send minimal TP1 and avoid
TP2. It also means that sink itself can take up to 5 idle frames for training.
6 in our case since we might be off by 1. So we also increment idle_frames by 4
here.

v2: Fix and improve commit message (Durga).
v3: Use minimal TP1 time avoiding TP2 and increase idle frame.

Cc: Durgadoss R durgados...@intel.com
Cc: Arthur Runyan arthur.j.run...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/intel_psr.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c 
b/drivers/gpu/drm/i915/intel_psr.c
index db95b39..0e3b652 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -264,11 +264,17 @@ static void hsw_psr_enable_source(struct intel_dp 
*intel_dp)
   uint32_t val = 0x0;
   const uint32_t link_entry_time = EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;

-  if (dev_priv-psr.link_standby) {
+  if (dev_priv-psr.link_standby)
   val |= EDP_PSR_LINK_STANDBY;
+
+  if (intel_dp-psr_dpcd[1]  DP_PSR_NO_TRAIN_ON_EXIT) {
+  /* It doesn't mean we shouldn't send TPS patters, so let's
+ send the minimal TP1 possible and skip TP2. */

We can fix the multi-line comment style though,

Reviewed-by: Durgadoss R durgados...@intel.com

Thanks,
Durga

+  val |= EDP_PSR_TP1_TIME_100us;
   val |= EDP_PSR_TP2_TP3_TIME_0us;
-  val |= EDP_PSR_TP1_TIME_0us;
   val |= EDP_PSR_SKIP_AUX_EXIT;
+  /* Sink should be able to train with the 5 or 6 idle patterns */
+  idle_frames += 4;
   }

   I915_WRITE(EDP_PSR_CTL(dev), val |
@@ -381,8 +387,7 @@ void intel_psr_enable(struct intel_dp *intel_dp)
   /* First we check VBT, but we must respect sink and source
* known restrictions */
   dev_priv-psr.link_standby = dev_priv-vbt.psr.full_link;
-  if ((intel_dp-psr_dpcd[1]  DP_PSR_NO_TRAIN_ON_EXIT) ||
-  (IS_BROADWELL(dev)  intel_dig_port-port != PORT_A))
+  if (IS_BROADWELL(dev)  intel_dig_port-port != PORT_A)
   dev_priv-psr.link_standby = true;

   dev_priv-psr.busy_frontbuffer_bits = 0;
--
2.1.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: PSR: Fix DP_PSR_NO_TRAIN_ON_EXIT logic

[R, Durgadoss]

-Original Message-
From: Vivi, Rodrigo
Sent: Friday, April 10, 2015 11:40 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo; R, Durgadoss; Runyan, Arthur J
Subject: [PATCH] drm/i915: PSR: Fix DP_PSR_NO_TRAIN_ON_EXIT logic

Since the beginning there is a missunderstanding on the meaning of this
dpcd bit.
This bit shouldn't indicate whether to use link standby or not, but just
be used to configure TP1, TP2 and TP3 times and tell hw aux should be skiped
since HW is the responsible one.

Even with help of frontbuffer tracking, HW is still fully responsible for
PSR exit logic with/without DP training.

DP_PSR_NO_TRAIN_ON_EXIT means the source doesn't need to do the training, but
it doesn't tell to avoid TP patterns, so we will send minimal TP1 and avoid
TP2. It also means that sink itself can take up to 5 idle frames for training.
6 in our case since we might be off by 1. So we also increment idle_frames by 4
here.

v2: Fix and improve commit message (Durga).
v3: Use minimal TP1 time avoiding TP2 and increase idle frame.

Cc: Durgadoss R durgados...@intel.com
Cc: Arthur Runyan arthur.j.run...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com

Reviewed-by: Durgadoss R durgados...@intel.com

Thanks,
Durga

---
 drivers/gpu/drm/i915/intel_psr.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c 
b/drivers/gpu/drm/i915/intel_psr.c
index db95b39..0e3b652 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -264,11 +264,17 @@ static void hsw_psr_enable_source(struct intel_dp 
*intel_dp)
   uint32_t val = 0x0;
   const uint32_t link_entry_time = EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;

-  if (dev_priv-psr.link_standby) {
+  if (dev_priv-psr.link_standby)
   val |= EDP_PSR_LINK_STANDBY;
+
+  if (intel_dp-psr_dpcd[1]  DP_PSR_NO_TRAIN_ON_EXIT) {
+  /* It doesn't mean we shouldn't send TPS patters, so let's
+ send the minimal TP1 possible and skip TP2. */
+  val |= EDP_PSR_TP1_TIME_100us;
   val |= EDP_PSR_TP2_TP3_TIME_0us;
-  val |= EDP_PSR_TP1_TIME_0us;
   val |= EDP_PSR_SKIP_AUX_EXIT;
+  /* Sink should be able to train with the 5 or 6 idle patterns */
+  idle_frames += 4;
   }

   I915_WRITE(EDP_PSR_CTL(dev), val |
@@ -381,8 +387,7 @@ void intel_psr_enable(struct intel_dp *intel_dp)
   /* First we check VBT, but we must respect sink and source
* known restrictions */
   dev_priv-psr.link_standby = dev_priv-vbt.psr.full_link;
-  if ((intel_dp-psr_dpcd[1]  DP_PSR_NO_TRAIN_ON_EXIT) ||
-  (IS_BROADWELL(dev)  intel_dig_port-port != PORT_A))
+  if (IS_BROADWELL(dev)  intel_dig_port-port != PORT_A)
   dev_priv-psr.link_standby = true;

   dev_priv-psr.busy_frontbuffer_bits = 0;
--
2.1.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: add i915 specific connector debugfs file for DPCD

[R, Durgadoss]

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Jani Nikula
Sent: Wednesday, April 1, 2015 1:45 PM
To: intel-gfx@lists.freedesktop.org
Cc: Nikula, Jani
Subject: [Intel-gfx] [PATCH v2] drm/i915: add i915 specific connector debugfs 
file for DPCD

Occasionally it would be interesting to read some of the DPCD registers
for debug purposes, without having to resort to logging. Add an i915
specific i915_dpcd debugfs file for DP and eDP connectors to dump parts
of the DPCD. Currently the DPCD addresses to be dumped are statically
configured, and more can be added trivially.

The implementation also makes it relatively easy to add other i915 and
connector specific debugfs files in the future, as necessary.

This is currently i915 specific just because there's no generic way to
do AUX transactions given just a drm_connector. However it's all pretty
straightforward to port to other drivers.

v2: Add more DPCD registers to dump.


Tested-by: Durgadoss R durgados...@intel.com

Thanks,
Durga

Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/i915/i915_debugfs.c | 96 +
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/intel_dp.c |  2 +
 3 files changed, 99 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 007c7d7d8295..7164aa7d5fd3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4780,3 +4780,99 @@ void i915_debugfs_cleanup(struct drm_minor *minor)
   drm_debugfs_remove_files(info_list, 1, minor);
   }
 }
+
+struct dpcd_block {
+  /* DPCD dump start address. */
+  unsigned int offset;
+  /* DPCD dump end address, inclusive. If unset, .size will be used. */
+  unsigned int end;
+  /* DPCD dump size. Used if .end is unset. If unset, defaults to 1. */
+  size_t size;
+  /* Only valid for eDP. */
+  bool edp;
+};
+
+static const struct dpcd_block i915_dpcd_debug[] = {
+  { .offset = DP_DPCD_REV, .size = DP_RECEIVER_CAP_SIZE },
+  { .offset = DP_PSR_SUPPORT, .end = DP_PSR_CAPS },
+  { .offset = DP_DOWNSTREAM_PORT_0, .size = 16 },
+  { .offset = DP_LINK_BW_SET, .end = DP_EDP_CONFIGURATION_SET },
+  { .offset = DP_SINK_COUNT, .end = DP_ADJUST_REQUEST_LANE2_3 },
+  { .offset = DP_SET_POWER },
+  { .offset = DP_EDP_DPCD_REV },
+  { .offset = DP_EDP_GENERAL_CAP_1, .end = DP_EDP_GENERAL_CAP_3 },
+  { .offset = DP_EDP_DISPLAY_CONTROL_REGISTER, .end =
DP_EDP_BACKLIGHT_FREQ_CAP_MAX_LSB },
+  { .offset = DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET, .end =
DP_EDP_DBC_MAXIMUM_BRIGHTNESS_SET },
+};
+
+static int i915_dpcd_show(struct seq_file *m, void *data)
+{
+  struct drm_connector *connector = m-private;
+  struct intel_dp *intel_dp =
+  enc_to_intel_dp(intel_attached_encoder(connector)-base);
+  uint8_t buf[16];
+  ssize_t err;
+  int i;
+
+  for (i = 0; i  ARRAY_SIZE(i915_dpcd_debug); i++) {
+  const struct dpcd_block *b = i915_dpcd_debug[i];
+  size_t size = b-end ? b-end - b-offset + 1 : (b-size ?: 1);
+
+  if (b-edp 
+  connector-connector_type != DRM_MODE_CONNECTOR_eDP)
+  continue;
+
+  /* low tech for now */
+  if (WARN_ON(size  sizeof(buf)))
+  continue;
+
+  err = drm_dp_dpcd_read(intel_dp-aux, b-offset, buf, size);
+  if (err = 0) {
+  DRM_ERROR(dpcd read (%zu bytes at %u) failed (%zd)\n,
+size, b-offset, err);
+  continue;
+  }
+
+  seq_printf(m, %04x: %*ph\n, b-offset, (int) size, buf);
+  };
+
+  return 0;
+}
+
+static int i915_dpcd_open(struct inode *inode, struct file *file)
+{
+  return single_open(file, i915_dpcd_show, inode-i_private);
+}
+
+static const struct file_operations i915_dpcd_fops = {
+  .owner = THIS_MODULE,
+  .open = i915_dpcd_open,
+  .read = seq_read,
+  .llseek = seq_lseek,
+  .release = single_release,
+};
+
+/**
+ * i915_debugfs_connector_add - add i915 specific connector debugfs files
+ * @connector: pointer to a registered drm_connector
+ *
+ * Cleanup will be done by drm_connector_unregister() through a call to
+ * drm_debugfs_connector_remove().
+ *
+ * Returns 0 on success, negative error codes on error.
+ */
+int i915_debugfs_connector_add(struct drm_connector *connector)
+{
+  struct dentry *root = connector-debugfs_entry;
+
+  /* The connector must have been registered beforehands. */
+  if (!root)
+  return -ENODEV;
+
+  if (connector-connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
+  connector-connector_type == DRM_MODE_CONNECTOR_eDP)
+  debugfs_create_file(i915_dpcd, S_IRUGO, root, connector,
+

Re: [Intel-gfx] [PATCH] drm/i915: Add debugfs to read any DPCD register

[R, Durgadoss]

-Original Message-
From: Nikula, Jani
Sent: Wednesday, April 8, 2015 1:34 PM
To: R, Durgadoss; intel-gfx@lists.freedesktop.org
Cc: R, Durgadoss
Subject: Re: [PATCH] drm/i915: Add debugfs to read any DPCD register

On Wed, 08 Apr 2015, Durgadoss R durgados...@intel.com wrote:
 This patch creates a connector specific debugfs
 interface to read any particular DPCD register.
 The DPCD register address (hex format) is written
 to 'i915_dpcd_addr' interface and the corresponding
 value can be read from 'i915_dpcd_val' interface.

 Example usage:
 echo 0x70  i915_dpcd_addr
 cat i915_dpcd_val
 DPCD[0x70]:0x1

I am still not overjoyed about the interface (because it has a state),
but I don't have anything better to suggest either. I'll defer to others
to make the taste judgement...

Review comments for the implementation inline.

BR,
Jani.



 Signed-off-by: Durgadoss R durgados...@intel.com
 ---
 This patch is based on top of Jani's patch:
 add i915 specific connector debugfs file for DPCD
 [https://freedesktop.org/patch/43332/]

Already committed.


  drivers/gpu/drm/i915/i915_debugfs.c | 102 
 +++-
  drivers/gpu/drm/i915/intel_drv.h|   1 +
  2 files changed, 102 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
 b/drivers/gpu/drm/i915/i915_debugfs.c
 index 10ca511..9951d84 100644
 --- a/drivers/gpu/drm/i915/i915_debugfs.c
 +++ b/drivers/gpu/drm/i915/i915_debugfs.c
 @@ -4865,6 +4865,101 @@ static const struct file_operations i915_dpcd_fops = 
 {
  .release = single_release,
  };

 +static ssize_t i915_dpcd_addr_write(struct file *file, const char __user 
 *ubuf,
 + size_t len, loff_t *offp)
 +{
 +struct seq_file *m = file-private_data;
 +struct drm_connector *connector = m-private;
 +struct intel_dp *intel_dp =
 +enc_to_intel_dp(intel_attached_encoder(connector)-base);
 +unsigned int reg_addr;
 +char tmp[16];
 +int ret;
 +
 +if (!intel_dp)
 +return -EINVAL;

I think it's highly unlikely this will be NULL. You're more likely to
oops above if something went wrong (see enc_to_intel_dp and
intel_attached_encoder). Also, -ENODEV?

Ok.. Will remove this check in next version..


 +
 +if (len = sizeof(tmp))
 +return -EINVAL;
 +
 +if (copy_from_user(tmp, ubuf, len))
 +return -EFAULT;
 +
 +tmp[len] = '\0';
 +
 +ret = sscanf(tmp, %x\n, reg_addr);

See kstrtouint.

 +if (ret == 0)
 +return -EINVAL;
 +
 +intel_dp-debugfs_dpcd_addr = reg_addr;
 +
 +return len;
 +}
 +
 +static int i915_dpcd_addr_show(struct seq_file *m, void *data)
 +{
 +struct drm_connector *connector = m-private;
 +struct intel_dp *intel_dp =
 +enc_to_intel_dp(intel_attached_encoder(connector)-base);
 +
 +if (!intel_dp)
 +return -EINVAL;

Same as above.

 +
 +seq_printf(m, 0x%x\n, intel_dp-debugfs_dpcd_addr);
 +
 +return 0;
 +}
 +
 +static int i915_dpcd_addr_open(struct inode *inode, struct file *file)
 +{
 +return single_open(file, i915_dpcd_addr_show, inode-i_private);
 +}
 +
 +static const struct file_operations i915_dpcd_addr_fops = {
 +.owner = THIS_MODULE,
 +.open = i915_dpcd_addr_open,
 +.read = seq_read,
 +.write = i915_dpcd_addr_write,
 +.llseek = seq_lseek,
 +.release = single_release,
 +};
 +
 +static int i915_dpcd_val_show(struct seq_file *m, void *data)
 +{
 +struct drm_connector *connector = m-private;
 +struct intel_dp *intel_dp =
 +enc_to_intel_dp(intel_attached_encoder(connector)-base);
 +unsigned int addr;
 +u8 buf[1];

Might be more obvious to just have u8 val, and use a pointer to
it. *shrug*.

 +int ret;
 +
 +if (!intel_dp)
 +return -EINVAL;

Same as above.

 +
 +addr = intel_dp-debugfs_dpcd_addr;
 +ret = drm_dp_dpcd_readb(intel_dp-aux, addr, buf);
 +if (ret  0) {
 +DRM_ERROR(dpcd read for 0x%x failed:%d\n, addr, ret);

I think there'll already be errors in the log at this point. This is
probably redundant.

 +return ret;
 +}
 +
 +seq_printf(m, DPCD[0x%x]:0x%x\n, addr, buf[0]);

For an interface better suited for tools than humans, I'd drop all the
fluff and just print the content. Maybe use 0x%02x for format.
 
I added this because we don't have locking constructs for
our state.

For tools, yes, I agree that just a value would do..

Thanks,
Durga


 +return 0;
 +}
 +
 +static int i915_dpcd_val_open(struct inode *inode, struct file *file)
 +{
 +return single_open(file, i915_dpcd_val_show, inode-i_private);
 +}
 +
 +static const struct file_operations i915_dpcd_val_fops = {
 +.owner = THIS_MODULE,
 +.open = i915_dpcd_val_open,
 +.read = seq_read,
 +.llseek = seq_lseek,
 +.release = single_release,
 +};
 +
  /**
   * i915_debugfs_connector_add - add i915 specific connector debugfs files
   * @connector: pointer to a registered

Re: [Intel-gfx] [PATCH v2] drm/i915: add i915 specific connector debugfs file for DPCD

[R, Durgadoss]

-Original Message-
From: Nikula, Jani
Sent: Wednesday, April 1, 2015 6:05 PM
To: R, Durgadoss; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: add i915 specific connector 
debugfs file for DPCD

On Wed, 01 Apr 2015, R, Durgadoss durgados...@intel.com wrote:
 Hi Jani,

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf 
Of Jani Nikula
Sent: Wednesday, April 1, 2015 1:45 PM
To: intel-gfx@lists.freedesktop.org
Cc: Nikula, Jani
Subject: [Intel-gfx] [PATCH v2] drm/i915: add i915 specific connector 
debugfs file for DPCD

Occasionally it would be interesting to read some of the DPCD registers
for debug purposes, without having to resort to logging. Add an i915
specific i915_dpcd debugfs file for DP and eDP connectors to dump parts
of the DPCD. Currently the DPCD addresses to be dumped are statically

 This is very much needed. I personally use a sysfs variation of something 
 like this.
 But I think we will never have a list that is sufficient for all cases of 
 debug.

 So, why not have one interface which takes the 'addr' and another
 one which returns the 'value' of the DPCD register 'addr'.

My main use case is for gathering debugging information from
end-users. I would like to have a simple and fairly fool proof way of
gathering the most relevant information in a dump like this. And we can
extend on it as needed.

Ok, agreed.


I don't think what you propose is user friendly (although it is powerful
for developers), and pretty much requires a script to ensure we do get
the data we want.

However these two are not mutually exclusive... this is the patch to do
what I want, please send us the patch doing what you want! :)

Sure...

Thanks,
Durga


BR,
Jani.


PS. Would we need to whitelist/blacklist the registers for your
approach?


 Something like below:

 i915_dpcd_addr
 i915_dpcd_val

 And we do:
 echo 0x100  i915_dpcd_addr

 and then:
 cat i915_dpcd_val
 [This fetches and prints the value of DPCD 0x100]

 Thanks,
 Durga

 ..
configured, and more can be added trivially.

The implementation also makes it relatively easy to add other i915 and
connector specific debugfs files in the future, as necessary.

This is currently i915 specific just because there's no generic way to
do AUX transactions given just a drm_connector. However it's all pretty
straightforward to port to other drivers.

v2: Add more DPCD registers to dump.

Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/i915/i915_debugfs.c | 96 
 +
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/intel_dp.c |  2 +
 3 files changed, 99 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 007c7d7d8295..7164aa7d5fd3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4780,3 +4780,99 @@ void i915_debugfs_cleanup(struct drm_minor *minor)
 drm_debugfs_remove_files(info_list, 1, minor);
 }
 }
+
+struct dpcd_block {
+/* DPCD dump start address. */
+unsigned int offset;
+/* DPCD dump end address, inclusive. If unset, .size will be used. */
+unsigned int end;
+/* DPCD dump size. Used if .end is unset. If unset, defaults to 1. */
+size_t size;
+/* Only valid for eDP. */
+bool edp;
+};
+
+static const struct dpcd_block i915_dpcd_debug[] = {
+{ .offset = DP_DPCD_REV, .size = DP_RECEIVER_CAP_SIZE },
+{ .offset = DP_PSR_SUPPORT, .end = DP_PSR_CAPS },
+{ .offset = DP_DOWNSTREAM_PORT_0, .size = 16 },
+{ .offset = DP_LINK_BW_SET, .end = DP_EDP_CONFIGURATION_SET },
+{ .offset = DP_SINK_COUNT, .end = DP_ADJUST_REQUEST_LANE2_3 },
+{ .offset = DP_SET_POWER },
+{ .offset = DP_EDP_DPCD_REV },
+{ .offset = DP_EDP_GENERAL_CAP_1, .end = DP_EDP_GENERAL_CAP_3 },
+{ .offset = DP_EDP_DISPLAY_CONTROL_REGISTER, .end =
DP_EDP_BACKLIGHT_FREQ_CAP_MAX_LSB },
+{ .offset = DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET, .end =
DP_EDP_DBC_MAXIMUM_BRIGHTNESS_SET },
+};
+
+static int i915_dpcd_show(struct seq_file *m, void *data)
+{
+struct drm_connector *connector = m-private;
+struct intel_dp *intel_dp =
+enc_to_intel_dp(intel_attached_encoder(connector)-base);
+uint8_t buf[16];
+ssize_t err;
+int i;
+
+for (i = 0; i  ARRAY_SIZE(i915_dpcd_debug); i++) {
+const struct dpcd_block *b = i915_dpcd_debug[i];
+size_t size = b-end ? b-end - b-offset + 1 : (b-size ?: 1);
+
+if (b-edp 
+connector-connector_type != DRM_MODE_CONNECTOR_eDP)
+continue;
+
+/* low tech for now */
+if (WARN_ON(size  sizeof(buf)))
+continue;
+
+err = drm_dp_dpcd_read(intel_dp-aux, b-offset, buf, size);
+if (err = 0) {
+DRM_ERROR(dpcd read (%zu bytes at %u) failed (%zd)\n

Re: [Intel-gfx] [PATCH v2] drm/i915: add i915 specific connector debugfs file for DPCD

[R, Durgadoss]

Hi Jani,

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Jani Nikula
Sent: Wednesday, April 1, 2015 1:45 PM
To: intel-gfx@lists.freedesktop.org
Cc: Nikula, Jani
Subject: [Intel-gfx] [PATCH v2] drm/i915: add i915 specific connector debugfs 
file for DPCD

Occasionally it would be interesting to read some of the DPCD registers
for debug purposes, without having to resort to logging. Add an i915
specific i915_dpcd debugfs file for DP and eDP connectors to dump parts
of the DPCD. Currently the DPCD addresses to be dumped are statically

This is very much needed. I personally use a sysfs variation of something like 
this.
But I think we will never have a list that is sufficient for all cases of debug.

So, why not have one interface which takes the 'addr' and another
one which returns the 'value' of the DPCD register 'addr'.
Something like below:

i915_dpcd_addr
i915_dpcd_val

And we do:
echo 0x100  i915_dpcd_addr

and then:
cat i915_dpcd_val
[This fetches and prints the value of DPCD 0x100]

Thanks,
Durga

..
configured, and more can be added trivially.

The implementation also makes it relatively easy to add other i915 and
connector specific debugfs files in the future, as necessary.

This is currently i915 specific just because there's no generic way to
do AUX transactions given just a drm_connector. However it's all pretty
straightforward to port to other drivers.

v2: Add more DPCD registers to dump.

Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/i915/i915_debugfs.c | 96 +
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/intel_dp.c |  2 +
 3 files changed, 99 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 007c7d7d8295..7164aa7d5fd3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4780,3 +4780,99 @@ void i915_debugfs_cleanup(struct drm_minor *minor)
   drm_debugfs_remove_files(info_list, 1, minor);
   }
 }
+
+struct dpcd_block {
+  /* DPCD dump start address. */
+  unsigned int offset;
+  /* DPCD dump end address, inclusive. If unset, .size will be used. */
+  unsigned int end;
+  /* DPCD dump size. Used if .end is unset. If unset, defaults to 1. */
+  size_t size;
+  /* Only valid for eDP. */
+  bool edp;
+};
+
+static const struct dpcd_block i915_dpcd_debug[] = {
+  { .offset = DP_DPCD_REV, .size = DP_RECEIVER_CAP_SIZE },
+  { .offset = DP_PSR_SUPPORT, .end = DP_PSR_CAPS },
+  { .offset = DP_DOWNSTREAM_PORT_0, .size = 16 },
+  { .offset = DP_LINK_BW_SET, .end = DP_EDP_CONFIGURATION_SET },
+  { .offset = DP_SINK_COUNT, .end = DP_ADJUST_REQUEST_LANE2_3 },
+  { .offset = DP_SET_POWER },
+  { .offset = DP_EDP_DPCD_REV },
+  { .offset = DP_EDP_GENERAL_CAP_1, .end = DP_EDP_GENERAL_CAP_3 },
+  { .offset = DP_EDP_DISPLAY_CONTROL_REGISTER, .end =
DP_EDP_BACKLIGHT_FREQ_CAP_MAX_LSB },
+  { .offset = DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET, .end =
DP_EDP_DBC_MAXIMUM_BRIGHTNESS_SET },
+};
+
+static int i915_dpcd_show(struct seq_file *m, void *data)
+{
+  struct drm_connector *connector = m-private;
+  struct intel_dp *intel_dp =
+  enc_to_intel_dp(intel_attached_encoder(connector)-base);
+  uint8_t buf[16];
+  ssize_t err;
+  int i;
+
+  for (i = 0; i  ARRAY_SIZE(i915_dpcd_debug); i++) {
+  const struct dpcd_block *b = i915_dpcd_debug[i];
+  size_t size = b-end ? b-end - b-offset + 1 : (b-size ?: 1);
+
+  if (b-edp 
+  connector-connector_type != DRM_MODE_CONNECTOR_eDP)
+  continue;
+
+  /* low tech for now */
+  if (WARN_ON(size  sizeof(buf)))
+  continue;
+
+  err = drm_dp_dpcd_read(intel_dp-aux, b-offset, buf, size);
+  if (err = 0) {
+  DRM_ERROR(dpcd read (%zu bytes at %u) failed (%zd)\n,
+size, b-offset, err);
+  continue;
+  }
+
+  seq_printf(m, %04x: %*ph\n, b-offset, (int) size, buf);
+  };
+
+  return 0;
+}
+
+static int i915_dpcd_open(struct inode *inode, struct file *file)
+{
+  return single_open(file, i915_dpcd_show, inode-i_private);
+}
+
+static const struct file_operations i915_dpcd_fops = {
+  .owner = THIS_MODULE,
+  .open = i915_dpcd_open,
+  .read = seq_read,
+  .llseek = seq_lseek,
+  .release = single_release,
+};
+
+/**
+ * i915_debugfs_connector_add - add i915 specific connector debugfs files
+ * @connector: pointer to a registered drm_connector
+ *
+ * Cleanup will be done by drm_connector_unregister() through a call to
+ * drm_debugfs_connector_remove().
+ *
+ * Returns 0 on success, negative error codes on error.
+ */
+int i915_debugfs_connector_add(struct 

Re: [Intel-gfx] [PATCH] drm/i915/skl: Enabling PSR2 SU with frame sync

[R, Durgadoss]

-Original Message-
From: Jindal, Sonika
Sent: Tuesday, March 31, 2015 11:29 AM
To: intel-gfx@lists.freedesktop.org
Cc: Jindal, Sonika; R, Durgadoss; Vivi, Rodrigo
Subject: [PATCH] drm/i915/skl: Enabling PSR2 SU with frame sync

We make use of HW tracking for Selective update region and enable frame sync on
sink. We use hardware's hardcoded data values for frame sync and GTC.

v2: Add 3200x2000 resolution restriction with PSR2, move psr2_support to 
i915_psr
struct, add aux_frame_sync to independently control aux frame sync, rename the
TP2 TIME macro for 2500us (Rodrigo, Siva)
v3: Moving the resolution restriction to intel_psr_enable so that we check it
only once(Durga)

Cc: Durgadoss R durgados...@intel.com
Cc: Rodrigo Vivi rodrigo.v...@intel.com

Reviewed-by: Durgadoss R durgados...@intel.com

Thanks,
Durga

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
 drivers/gpu/drm/i915/i915_drv.h  |2 ++
 drivers/gpu/drm/i915/i915_reg.h  |   14 ++
 drivers/gpu/drm/i915/intel_dp.c  |   15 +++
 drivers/gpu/drm/i915/intel_psr.c |   38 +-
 4 files changed, 68 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index eb38cd1..65d3dae 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -879,6 +879,8 @@ struct i915_psr {
   struct delayed_work work;
   unsigned busy_frontbuffer_bits;
   bool link_standby;
+  bool psr2_support;
+  bool aux_frame_sync;
 };

 enum intel_pch {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5b84ee6..0b42ef3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2745,6 +2745,20 @@ enum skl_disp_power_wells {
 #define   EDP_PSR_DEBUG_MASK_MEMUP(126)
 #define   EDP_PSR_DEBUG_MASK_HPD  (125)

+#define EDP_PSR2_CTL  0x6f900
+#define   EDP_PSR2_ENABLE (131)
+#define   EDP_SU_TRACK_ENABLE (130)
+#define   EDP_MAX_SU_DISABLE_TIME(t)  ((t)20)
+#define   EDP_MAX_SU_DISABLE_TIME_MASK(0x1f20)
+#define   EDP_PSR2_TP2_TIME_500   (08)
+#define   EDP_PSR2_TP2_TIME_100   (18)
+#define   EDP_PSR2_TP2_TIME_2500  (28)
+#define   EDP_PSR2_TP2_TIME_50(38)
+#define   EDP_PSR2_TP2_TIME_MASK  (38)
+#define   EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
+#define   EDP_PSR2_FRAME_BEFORE_SU_MASK   (0xf4)
+#define   EDP_PSR2_IDLE_MASK  0xf
+
 /* VGA port control */
 #define ADPA  0x61100
 #define PCH_ADPA0xe1100
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3967af1..b0ae45e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3786,6 +3786,21 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
   dev_priv-psr.sink_support = true;
   DRM_DEBUG_KMS(Detected EDP PSR Panel.\n);
   }
+
+  if (INTEL_INFO(dev)-gen = 9 
+  (intel_dp-psr_dpcd[0]  DP_PSR2_IS_SUPPORTED)) {
+  uint8_t frame_sync_cap;
+
+  dev_priv-psr.sink_support = true;
+  intel_dp_dpcd_read_wake(intel_dp-aux,
+  DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
+  frame_sync_cap, 1);
+  dev_priv-psr.aux_frame_sync = frame_sync_cap ? true : 
false;
+  /* PSR2 needs frame sync as well */
+  dev_priv-psr.psr2_support = 
dev_priv-psr.aux_frame_sync;
+  DRM_DEBUG_KMS(PSR2 %s on sink,
+  dev_priv-psr.psr2_support ? supported : not 
supported);
+  }
   }

   /* Training Pattern 3 support, both source and sink */
diff --git a/drivers/gpu/drm/i915/intel_psr.c 
b/drivers/gpu/drm/i915/intel_psr.c
index b9f40c2..8d9ae0b 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -117,6 +117,19 @@ static void vlv_psr_setup_vsc(struct intel_dp *intel_dp)
   I915_WRITE(VLV_VSCSDP(pipe), val);
 }

+static void skl_psr_setup_su_vsc(struct intel_dp *intel_dp)
+{
+  struct edp_vsc_psr psr_vsc;
+
+  /* Prepare VSC Header for SU as per EDP 1.4 spec, Table 6.11 */
+  memset(psr_vsc, 0, sizeof(psr_vsc));
+  psr_vsc.sdp_header.HB0 = 0;
+  psr_vsc.sdp_header.HB1 = 0x7;
+  psr_vsc.sdp_header.HB2 = 0x3;
+  psr_vsc.sdp_header.HB3 = 0xb;
+  intel_psr_write_vsc(intel_dp, psr_vsc);
+}
+
 static void hsw_psr_setup_vsc(struct intel_dp *intel_dp)
 {
   struct edp_vsc_psr psr_vsc;
@@ -165,6 +178,12 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
   drm_dp_dpcd_writeb(intel_dp-aux, DP_PSR_EN_CFG,
  DP_PSR_ENABLE  ~DP_PSR_MAIN_LINK_ACTIVE);

+  /* Enable AUX frame sync at sink

Re: [Intel-gfx] [PATCH] drm/i915/skl: Enabling PSR2 SU with frame sync

[R, Durgadoss]

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Sonika Jindal
Sent: Thursday, March 26, 2015 1:57 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH] drm/i915/skl: Enabling PSR2 SU with frame sync

We make use of HW tracking for Selective update region and enable frame sync on
sink. We use hardware's hardcoded data values for frame sync and GTC.

v2: Add 3200x2000 resolution restriction with PSR2, move psr2_support to 
i915_psr
struct, add aux_frame_sync to independently control aux frame sync, rename the
TP2 TIME macro for 2500us (Rodrigo, Siva)

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
 drivers/gpu/drm/i915/i915_drv.h  |2 ++
 drivers/gpu/drm/i915/i915_reg.h  |   14 ++
 drivers/gpu/drm/i915/intel_dp.c  |   15 +++
 drivers/gpu/drm/i915/intel_psr.c |   34 +-
 4 files changed, 64 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index eb38cd1..65d3dae 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -879,6 +879,8 @@ struct i915_psr {
   struct delayed_work work;
   unsigned busy_frontbuffer_bits;
   bool link_standby;
+  bool psr2_support;
+  bool aux_frame_sync;
 };

 enum intel_pch {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5b84ee6..0b42ef3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2745,6 +2745,20 @@ enum skl_disp_power_wells {
 #define   EDP_PSR_DEBUG_MASK_MEMUP(126)
 #define   EDP_PSR_DEBUG_MASK_HPD  (125)

+#define EDP_PSR2_CTL  0x6f900
+#define   EDP_PSR2_ENABLE (131)
+#define   EDP_SU_TRACK_ENABLE (130)
+#define   EDP_MAX_SU_DISABLE_TIME(t)  ((t)20)
+#define   EDP_MAX_SU_DISABLE_TIME_MASK(0x1f20)
+#define   EDP_PSR2_TP2_TIME_500   (08)
+#define   EDP_PSR2_TP2_TIME_100   (18)
+#define   EDP_PSR2_TP2_TIME_2500  (28)
+#define   EDP_PSR2_TP2_TIME_50(38)
+#define   EDP_PSR2_TP2_TIME_MASK  (38)
+#define   EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
+#define   EDP_PSR2_FRAME_BEFORE_SU_MASK   (0xf4)
+#define   EDP_PSR2_IDLE_MASK  0xf
+
 /* VGA port control */
 #define ADPA  0x61100
 #define PCH_ADPA0xe1100
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3967af1..b0ae45e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3786,6 +3786,21 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
   dev_priv-psr.sink_support = true;
   DRM_DEBUG_KMS(Detected EDP PSR Panel.\n);
   }
+
+  if (INTEL_INFO(dev)-gen = 9 
+  (intel_dp-psr_dpcd[0]  DP_PSR2_IS_SUPPORTED)) {
+  uint8_t frame_sync_cap;
+
+  dev_priv-psr.sink_support = true;
+  intel_dp_dpcd_read_wake(intel_dp-aux,
+  DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
+  frame_sync_cap, 1);
+  dev_priv-psr.aux_frame_sync = frame_sync_cap ? true : 
false;
+  /* PSR2 needs frame sync as well */
+  dev_priv-psr.psr2_support = 
dev_priv-psr.aux_frame_sync;
+  DRM_DEBUG_KMS(PSR2 %s on sink,
+  dev_priv-psr.psr2_support ? supported : not 
supported);
+  }
   }

   /* Training Pattern 3 support, both source and sink */
diff --git a/drivers/gpu/drm/i915/intel_psr.c 
b/drivers/gpu/drm/i915/intel_psr.c
index b9f40c2..d52623d 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -117,6 +117,19 @@ static void vlv_psr_setup_vsc(struct intel_dp *intel_dp)
   I915_WRITE(VLV_VSCSDP(pipe), val);
 }

+static void skl_psr_setup_su_vsc(struct intel_dp *intel_dp)
+{
+  struct edp_vsc_psr psr_vsc;
+
+  /* Prepare VSC Header for SU as per EDP 1.4 spec, Table 6.11 */
+  memset(psr_vsc, 0, sizeof(psr_vsc));
+  psr_vsc.sdp_header.HB0 = 0;
+  psr_vsc.sdp_header.HB1 = 0x7;
+  psr_vsc.sdp_header.HB2 = 0x3;
+  psr_vsc.sdp_header.HB3 = 0xb;
+  intel_psr_write_vsc(intel_dp, psr_vsc);
+}
+
 static void hsw_psr_setup_vsc(struct intel_dp *intel_dp)
 {
   struct edp_vsc_psr psr_vsc;
@@ -165,6 +178,12 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
   drm_dp_dpcd_writeb(intel_dp-aux, DP_PSR_EN_CFG,
  DP_PSR_ENABLE  ~DP_PSR_MAIN_LINK_ACTIVE);

+  /* Enable AUX frame sync at sink */
+  if (dev_priv-psr.aux_frame_sync)
+  drm_dp_dpcd_writeb(intel_dp-aux,
+  DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
+  

Re: [Intel-gfx] [PATCH 1/7] drm/i915: PSR: Remove wrong LINK_DISABLE.

[R, Durgadoss]

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Rodrigo Vivi
Sent: Saturday, February 28, 2015 6:56 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 1/7] drm/i915: PSR: Remove wrong LINK_DISABLE.

This wrong logic and useless define came from first versions and
came along with all rework. Just now I notice how ugly, wrong and
useless this is.

val is already defined as 0 anyway and logic is completelly wrong
and useless. So let's starting the link_standby fix with this
cleaning.


Reviewed-by: Durgadoss R durgados...@intel.com

Thanks,
Durga

Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/i915_reg.h  | 1 -
 drivers/gpu/drm/i915/intel_psr.c | 3 +--
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 55143cb..b95554d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2658,7 +2658,6 @@ enum skl_disp_power_wells {
 #define EDP_PSR_CTL(dev)  (EDP_PSR_BASE(dev) + 0)
 #define   EDP_PSR_ENABLE  (131)
 #define   BDW_PSR_SINGLE_FRAME(130)
-#define   EDP_PSR_LINK_DISABLE(027)
 #define   EDP_PSR_LINK_STANDBY(127)
 #define   EDP_PSR_MIN_LINK_ENTRY_TIME_MASK(325)
 #define   EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES (025)
diff --git a/drivers/gpu/drm/i915/intel_psr.c 
b/drivers/gpu/drm/i915/intel_psr.c
index b9f40c2..2e6831d 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -247,8 +247,7 @@ static void hsw_psr_enable_source(struct intel_dp 
*intel_dp)
   val |= EDP_PSR_TP2_TP3_TIME_0us;
   val |= EDP_PSR_TP1_TIME_0us;
   val |= EDP_PSR_SKIP_AUX_EXIT;
-  } else
-  val |= EDP_PSR_LINK_DISABLE;
+  }

   I915_WRITE(EDP_PSR_CTL(dev), val |
  (IS_BROADWELL(dev) ? 0 : link_entry_time) |
--
1.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/7] drm/i915: VLV/CHV PSR: Increase wait delay time before active PSR.

[R, Durgadoss]

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Rodrigo Vivi
Sent: Saturday, February 28, 2015 6:56 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 6/7] drm/i915: VLV/CHV PSR: Increase wait delay 
time before active PSR.

Since active function on VLV immediately activate PSR let's give more
time for idleness.

v2: Rebase over intel_psr.c and fix typo.
v3: Revival: Manual tests indicated that this is needed. With a short delay
there is a huge risk of getting blank screens when planes are being 
 enabled.
v4: Revival 2 with reasonable delay. 1/2 sec instead of 5. VBT is 10 sec but
actually time for link training what we aren't doing, but with only 100 sec
in some cases kms_psr_sink_crc manual was showing blank screen,
so let's use this for now. Also changed comment by a FIXME.


Reviewed-by: Durgadoss R durgados...@intel.com

Thanks,
Durga

Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/intel_psr.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c 
b/drivers/gpu/drm/i915/intel_psr.c
index c1ca923..3c1d2b3 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -648,6 +648,12 @@ void intel_psr_flush(struct drm_device *dev,
   struct drm_i915_private *dev_priv = dev-dev_private;
   struct drm_crtc *crtc;
   enum pipe pipe;
+  /* FIXME: kms_psr_sink_crc in manual mode shows black screen on
+   * the very first primary plane enabling. W/A is to delay
+   * the activate a bit more. On regular use 100 would be enough and
+   * better for good power savings.
+   */
+  int delay = msecs_to_jiffies(HAS_DDI(dev) ? 100 : 500);

   mutex_lock(dev_priv-psr.lock);
   if (!dev_priv-psr.enabled) {
@@ -680,7 +686,7 @@ void intel_psr_flush(struct drm_device *dev,

   if (!dev_priv-psr.active  !dev_priv-psr.busy_frontbuffer_bits)
   schedule_delayed_work(dev_priv-psr.work,
-msecs_to_jiffies(100));
+msecs_to_jiffies(delay));
   mutex_unlock(dev_priv-psr.lock);
 }

--
1.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/7] drm/i915: PSR: deprecate link_standby support for core platforms.

[R, Durgadoss]

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Rodrigo Vivi
Sent: Saturday, February 28, 2015 6:56 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 3/7] drm/i915: PSR: deprecate link_standby support 
for core platforms.

On Haswell and Broadwell with link in standby when exit event happens
between vblank and VSC packet, PSR exit on panel but DPA transmitter
still sends black pixel. hen this condition hits, panel will intermittently

s/hen/when

display black frame.

The known W/A for this case involve the of single_frame update
that isn't supported on Haswell and to be supported on Broadwell
3 other workarounds would be required. So it is better and safe to
just deprecate link_standby for now.

Also, link fully off saves more power than link_standby and afwk
no OEM is requesting link standby on VBT. There is no reason for that.

For Skylake let's just consider it behaves like Broadwell until
we prove otherwise.


Reviewed-by: Durgadoss R durgados...@intel.com

Thanks,
Durga

Reference: HSD: bdwgfx/1912559
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/i915_debugfs.c |  3 ---
 drivers/gpu/drm/i915/i915_drv.h |  1 -
 drivers/gpu/drm/i915/intel_psr.c| 25 -
 3 files changed, 8 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 94b3984..756bf4e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2281,9 +2281,6 @@ static int i915_edp_psr_status(struct seq_file *m, void 
*data)
   }
   seq_puts(m, \n);

-  seq_printf(m, Link standby: %s\n,
- yesno((bool)dev_priv-psr.link_standby));
-
   /* CHV PSR has no kind of performance counter */
   if (HAS_PSR(dev)  HAS_DDI(dev)) {
   psrperf = I915_READ(EDP_PSR_PERF_CNT(dev)) 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a1dd8bc..dfd044f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -863,7 +863,6 @@ struct i915_psr {
   bool active;
   struct delayed_work work;
   unsigned busy_frontbuffer_bits;
-  bool link_standby;
 };

 enum intel_pch {
diff --git a/drivers/gpu/drm/i915/intel_psr.c 
b/drivers/gpu/drm/i915/intel_psr.c
index 6c8e9e0..d2ff87d 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -157,14 +157,6 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp)

   aux_clock_divider = intel_dp-get_aux_clock_divider(intel_dp, 0);

-  /* Enable PSR in sink */
-  if (dev_priv-psr.link_standby)
-  drm_dp_dpcd_writeb(intel_dp-aux, DP_PSR_EN_CFG,
- DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE);
-  else
-  drm_dp_dpcd_writeb(intel_dp-aux, DP_PSR_EN_CFG,
- DP_PSR_ENABLE  ~DP_PSR_MAIN_LINK_ACTIVE);
-
   aux_data_reg = (INTEL_INFO(dev)-gen = 9) ?
   DPA_AUX_CH_DATA1 : EDP_PSR_AUX_DATA1(dev);
   aux_ctl_reg = (INTEL_INFO(dev)-gen = 9) ?
@@ -193,6 +185,8 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
  (precharge  DP_AUX_CH_CTL_PRECHARGE_2US_SHIFT) |
  (aux_clock_divider  DP_AUX_CH_CTL_BIT_CLOCK_2X_SHIFT));
   }
+
+  drm_dp_dpcd_writeb(intel_dp-aux, DP_PSR_EN_CFG, DP_PSR_ENABLE);
 }

 static void vlv_psr_enable_source(struct intel_dp *intel_dp)
@@ -242,9 +236,6 @@ static void hsw_psr_enable_source(struct intel_dp 
*intel_dp)
   uint32_t val = 0x0;
   const uint32_t link_entry_time = EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;

-  if (dev_priv-psr.link_standby)
-  val |= EDP_PSR_LINK_STANDBY;
-
   if (intel_dp-psr_dpcd[1]  DP_PSR_NO_TRAIN_ON_EXIT) {
   val |= EDP_PSR_TP2_TP3_TIME_0us;
   val |= EDP_PSR_TP1_TIME_0us;
@@ -295,6 +286,12 @@ static bool intel_psr_match_conditions(struct intel_dp 
*intel_dp)
   return false;
   }

+  if (!IS_VALLEYVIEW(dev)  ((dev_priv-vbt.psr.full_link) ||
+  (dig_port-port != PORT_A))){
+  DRM_DEBUG_KMS(PSR condition failed: Link Standby 
requested/needed but not
supported on this platform\n);
+  return false;
+  }
+
   dev_priv-psr.source_ok = true;
   return true;
 }
@@ -353,12 +350,6 @@ void intel_psr_enable(struct intel_dp *intel_dp)
   if (!intel_psr_match_conditions(intel_dp))
   goto unlock;

-  /* First we check VBT, but we must respect sink and source
-   * known restrictions */
-  dev_priv-psr.link_standby = dev_priv-vbt.psr.full_link;
-  if (IS_BROADWELL(dev)  intel_dig_port-port != PORT_A)
-  dev_priv-psr.link_standby = true;
-
   dev_priv-psr.busy_frontbuffer_bits = 0;

   if (HAS_DDI(dev)) {
--
1.9.3

Re: [Intel-gfx] [PATCH 7/7] drm/i915: Enable PSR by default.

[R, Durgadoss]

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Rodrigo Vivi
Sent: Saturday, February 28, 2015 6:56 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 7/7] drm/i915: Enable PSR by default.

With a reliable frontbuffer tracking and all instability corner cases solved
let's re-enabled PSR by default on all supported platforms.


Finally ;)

Reviewed-by: Durgadoss R durgados...@intel.com

Thanks,
Durga

Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/i915_params.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 44f2262..2c1a90e 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -38,7 +38,7 @@ struct i915_params i915 __read_mostly = {
   .enable_execlists = -1,
   .enable_hangcheck = true,
   .enable_ppgtt = -1,
-  .enable_psr = 0,
+  .enable_psr = 1,
   .preliminary_hw_support = 
 IS_ENABLED(CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT),
   .disable_power_well = 1,
   .enable_ips = 1,
@@ -127,7 +127,7 @@ MODULE_PARM_DESC(enable_execlists,
   (-1=auto [default], 0=disabled, 1=enabled));

 module_param_named(enable_psr, i915.enable_psr, int, 0600);
-MODULE_PARM_DESC(enable_psr, Enable PSR (default: false));
+MODULE_PARM_DESC(enable_psr, Enable PSR (default: true));

 module_param_named(preliminary_hw_support, i915.preliminary_hw_support, int, 
 0600);
 MODULE_PARM_DESC(preliminary_hw_support,
--
1.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/7] drm/i915: PSR: Fix DP_PSR_NO_TRAIN_ON_EXIT logic

[R, Durgadoss]

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Rodrigo Vivi
Sent: Saturday, February 28, 2015 6:56 AM
To: intel-gfx@lists.freedesktop.org
Cc: Runyan, Arthur J; Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 2/7] drm/i915: PSR: Fix DP_PSR_NO_TRAIN_ON_EXIT 
logic

Since the begining there is a missunderstanding on the meaning of this
dpcd bit.
This bit should'n indicate wheter to use link standby or not, but just

Shouldn't , whether

be used to configure TP1, TP2 and TP3 times and tell hw aux should be skiped
since HW is the responsible one.

Even with help of frontbuffer tracking to do exit HW tracking is still
fully responsible for this exit logic with DP training or not.

I think it will be better to rephrase this as something like below:
Even with help of frontbuffer tracking, HW is still fully responsible for
PSR exit logic with/without DP training


Cc: Arthur Runyan arthur.j.run...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/intel_psr.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c 
b/drivers/gpu/drm/i915/intel_psr.c
index 2e6831d..6c8e9e0 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -242,8 +242,10 @@ static void hsw_psr_enable_source(struct intel_dp 
*intel_dp)
   uint32_t val = 0x0;
   const uint32_t link_entry_time = EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;

-  if (dev_priv-psr.link_standby) {
+  if (dev_priv-psr.link_standby)
   val |= EDP_PSR_LINK_STANDBY;
+
+  if (intel_dp-psr_dpcd[1]  DP_PSR_NO_TRAIN_ON_EXIT) {

Shouldn't this 'if' check also include if (psr.link_standby) ?
Otherwise, even for link_disable cases we are configuring to 'skip
TPs'. Will this work ?

I see that in the next patch, you are removing this whole link_standby
thing. So, would leave it up to you to either add this check or not.

Thanks,
Durga

   val |= EDP_PSR_TP2_TP3_TIME_0us;
   val |= EDP_PSR_TP1_TIME_0us;
   val |= EDP_PSR_SKIP_AUX_EXIT;
@@ -354,8 +356,7 @@ void intel_psr_enable(struct intel_dp *intel_dp)
   /* First we check VBT, but we must respect sink and source
* known restrictions */
   dev_priv-psr.link_standby = dev_priv-vbt.psr.full_link;
-  if ((intel_dp-psr_dpcd[1]  DP_PSR_NO_TRAIN_ON_EXIT) ||
-  (IS_BROADWELL(dev)  intel_dig_port-port != PORT_A))
+  if (IS_BROADWELL(dev)  intel_dig_port-port != PORT_A)
   dev_priv-psr.link_standby = true;

   dev_priv-psr.busy_frontbuffer_bits = 0;
--
1.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/9] drm/i915: PSR link standby at debugfs

[R, Durgadoss]

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Rodrigo Vivi
Sent: Monday, January 12, 2015 11:45 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 6/9] drm/i915: PSR link standby at debugfs

It is useful to know at debug time if we are keeping main link on.

Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com

For patches, 4-6,
Reviewed-by: Durgadoss R durgados...@intel.com

Thanks,
Durga

---
 drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e515aad..0d11cbe 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2248,6 +2248,9 @@ static int i915_edp_psr_status(struct seq_file *m, void 
*data)
   }
   seq_puts(m, \n);

+  seq_printf(m, Link standby: %s\n,
+ yesno((bool)dev_priv-psr.link_standby));
+
   /* CHV PSR has no kind of performance counter */
   if (HAS_PSR(dev)  HAS_DDI(dev)) {
   psrperf = I915_READ(EDP_PSR_PERF_CNT(dev)) 
--
2.1.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/9] drm/i915: PSR HSW/BDW: Fix inverted logic at sink main_link_active bit.

[R, Durgadoss]

Hi Rodrigo,

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Rodrigo Vivi
Sent: Monday, January 12, 2015 11:45 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 3/9] drm/i915: PSR HSW/BDW: Fix inverted logic at 
sink main_link_active bit.

We have only two possible states with so many names and combinations that
might be confusing.

1 - Main link active / enabled / stand by / on
2 - Main link disabled / off / full off

In this case, I think we should use 'link_active' instead of 'link_standby'
since 'active' is what is used by the eDP spec and most of our PSR
macros. But, I believe we can have this as a separate patch.

For patches 1-3,
Reviewed-by: Durgadoss R durgados...@intel.com

Thanks,
Durga


Let's start organizing it by fixing a inverted logic when setting the sink bit.

Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/intel_psr.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c 
b/drivers/gpu/drm/i915/intel_psr.c
index 3dd8886..0af89db 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -163,10 +163,10 @@ static void hsw_psr_enable_sink(struct intel_dp 
*intel_dp)
   /* Enable PSR in sink */
   if (intel_dp-psr_dpcd[1]  DP_PSR_NO_TRAIN_ON_EXIT || only_standby)
   drm_dp_dpcd_writeb(intel_dp-aux, DP_PSR_EN_CFG,
- DP_PSR_ENABLE  ~DP_PSR_MAIN_LINK_ACTIVE);
+ DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE);
   else
   drm_dp_dpcd_writeb(intel_dp-aux, DP_PSR_EN_CFG,
- DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE);
+ DP_PSR_ENABLE  ~DP_PSR_MAIN_LINK_ACTIVE);

   /* Setup AUX registers */
   for (i = 0; i  sizeof(aux_msg); i += 4)
--
2.1.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 7/9] drm/i915: PSR VLV/CHV: let's respect link_standby here as well.

[R, Durgadoss]

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Rodrigo Vivi
Sent: Monday, January 12, 2015 11:45 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 7/9] drm/i915: PSR VLV/CHV: let's respect 
link_standby here as well.

Let's respect vbt and panel for link_standby/on x link_disabled

Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/intel_psr.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c 
b/drivers/gpu/drm/i915/intel_psr.c
index 5ae193e..313347a 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -132,8 +132,17 @@ static void hsw_psr_setup_vsc(struct intel_dp *intel_dp)

 static void vlv_psr_enable_sink(struct intel_dp *intel_dp)
 {
-  drm_dp_dpcd_writeb(intel_dp-aux, DP_PSR_EN_CFG,
- DP_PSR_ENABLE);
+  struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+  struct drm_device *dev = dig_port-base.base.dev;
+  struct drm_i915_private *dev_priv = dev-dev_private;
+
+  /* Enable PSR in sink */
+  if (dev_priv-psr.link_standby)
+  drm_dp_dpcd_writeb(intel_dp-aux, DP_PSR_EN_CFG,
+ DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE);
+  else
+  drm_dp_dpcd_writeb(intel_dp-aux, DP_PSR_EN_CFG,
+ DP_PSR_ENABLE  ~DP_PSR_MAIN_LINK_ACTIVE);
 }

 static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
@@ -183,11 +192,12 @@ static void vlv_psr_enable_source(struct intel_dp 
*intel_dp)
   struct drm_i915_private *dev_priv = dev-dev_private;
   struct drm_crtc *crtc = dig_port-base.base.crtc;
   enum pipe pipe = to_intel_crtc(crtc)-pipe;
+  bool standby = dev_priv-psr.link_standby;

   /* Transition from PSR_state 0 to PSR_state 1, i.e. PSR Inactive */
   I915_WRITE(VLV_PSRCTL(pipe),
  VLV_EDP_PSR_MODE_SW_TIMER |
- VLV_EDP_PSR_SRC_TRANSMITTER_STATE |
+ standby ? VLV_EDP_PSR_SRC_TRANSMITTER_STATE : 0 |

Apart from VBT, this also depends on the Panel DPCD 71h.
If bit 0 of 71h is 0, we may need Link training to exit PSR,
If main link is off.

So, unless we try it out on various panels and
are confident about it, I suggest we keep this
TRANSMITTER_STATE to 1.

Thanks,
Durga

  VLV_EDP_PSR_ENABLE);
 }

--
2.1.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 8/9] drm/i915: PSR: respect vbt time for link trains when available.

[R, Durgadoss]

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Rodrigo Vivi
Sent: Monday, January 12, 2015 11:45 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 8/9] drm/i915: PSR: respect vbt time for link 
trains when available.

If link is off we need to give enough time for source to do link train.
This time is usually set at VBT.

VBT tp time comse in multiple of hundreds.

s/comes/comes


Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/intel_psr.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c 
b/drivers/gpu/drm/i915/intel_psr.c
index 313347a..d1c2c31 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -603,6 +603,10 @@ void intel_psr_flush(struct drm_device *dev,
   struct drm_i915_private *dev_priv = dev-dev_private;
   struct drm_crtc *crtc;
   enum pipe pipe;
+  bool link_on = dev_priv-psr.link_standby;
+  int tp = 100 * dev_priv-vbt.psr.tp2_tp3_wakeup_time +
+   100 * dev_priv-vbt.psr.tp1_wakeup_time;
+  int delay = tp  !link_on ? tp : 100;

May be we should WARN/DRM_ERR on link_on is false but still tp is 0 ?

With this, for patches 8-9,

Reviewed-by: Durgadoss R durgados...@intel.com

Thanks,
Durga


   mutex_lock(dev_priv-psr.lock);
   if (!dev_priv-psr.enabled) {
@@ -635,7 +639,7 @@ void intel_psr_flush(struct drm_device *dev,

   if (!dev_priv-psr.active  !dev_priv-psr.busy_frontbuffer_bits)
   schedule_delayed_work(dev_priv-psr.work,
-msecs_to_jiffies(100));
+msecs_to_jiffies(delay));
   mutex_unlock(dev_priv-psr.lock);
 }

--
2.1.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 15/15] drm/i915: Enable PSR for Baytrail and Braswell.

[R, Durgadoss]

-Original Message-
From: Rodrigo Vivi [mailto:rodrigo.v...@gmail.com]
Sent: Thursday, November 20, 2014 10:55 PM
To: Vivi, Rodrigo; R, Durgadoss; Zanoni, Paulo R; Daniel Vetter
Cc: intel-gfx
Subject: Re: [Intel-gfx] [PATCH 15/15] drm/i915: Enable PSR for Baytrail and 
Braswell.

Daniel, I think this is the only one of this series with pending
reviewed-by right?

Durga or Paulo, could you please help me on this?

Thank you,
Rodrigo.

On Fri, Nov 14, 2014 at 8:52 AM, Rodrigo Vivi rodrigo.v...@intel.com wrote:
 This patch is the last in series of VLV/CHV PSR,
 that finnaly enable psr by adding it to HAS_PSR

Finally,

 and calling the proper enable and disable
 functions on the right places.

 Although it is still disabled by default.

 v2: Rebase over intel_psr and merge Durgadoss's fixes.

 Cc: Durgadoss R durgados...@intel.com
 Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com

With that,

Reviewed-by: Durgadoss R durgados...@intel.com

Thanks,
Durga

 ---
  drivers/gpu/drm/i915/i915_drv.h | 3 ++-
  drivers/gpu/drm/i915/intel_dp.c | 4 
  2 files changed, 6 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/i915/i915_drv.h 
 b/drivers/gpu/drm/i915/i915_drv.h
 index 573f084..4020653 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -2267,7 +2267,8 @@ struct drm_i915_cmd_table {

  #define HAS_DDI(dev)   (INTEL_INFO(dev)-has_ddi)
  #define HAS_FPGA_DBG_UNCLAIMED(dev)(INTEL_INFO(dev)-has_fpga_dbg)
 -#define HAS_PSR(dev)   (IS_HASWELL(dev) || IS_BROADWELL(dev))
 +#define HAS_PSR(dev)   (IS_HASWELL(dev) || IS_BROADWELL(dev) || \
 +IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev))
  #define HAS_RUNTIME_PM(dev)(IS_GEN6(dev) || IS_HASWELL(dev) || \
  IS_BROADWELL(dev) || IS_VALLEYVIEW(dev))
  #define HAS_RC6(dev)   (INTEL_INFO(dev)-gen = 6)
 diff --git a/drivers/gpu/drm/i915/intel_dp.c 
 b/drivers/gpu/drm/i915/intel_dp.c
 index 98f7ecd..d53a0c9 100644
 --- a/drivers/gpu/drm/i915/intel_dp.c
 +++ b/drivers/gpu/drm/i915/intel_dp.c
 @@ -2075,6 +2075,9 @@ static void intel_disable_dp(struct intel_encoder 
 *encoder)
 if (crtc-config.has_audio)
 intel_audio_codec_disable(encoder);

 +   if (HAS_PSR(dev)  !HAS_DDI(dev))
 +   intel_psr_disable(intel_dp);
 +
 /* Make sure the panel is off before trying to change the mode. But 
 also
  * ensure that we have vdd while we switch off the panel. */
 intel_edp_panel_vdd_on(intel_dp);
 @@ -2299,6 +2302,7 @@ static void vlv_enable_dp(struct intel_encoder 
 *encoder)
 struct intel_dp *intel_dp = enc_to_intel_dp(encoder-base);

 intel_edp_backlight_on(intel_dp);
 +   intel_psr_enable(intel_dp);
  }

  static void g4x_pre_enable_dp(struct intel_encoder *encoder)
 --
 1.9.3

 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx



--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 11/15] drm/i915: PSR VLV/CHV: Introduce setup, enable and disable functions

[R, Durgadoss]

-Original Message-
From: Rodrigo Vivi [mailto:rodrigo.v...@gmail.com]
Sent: Wednesday, November 19, 2014 11:51 PM
To: R, Durgadoss
Cc: Vivi, Rodrigo; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 11/15] drm/i915: PSR VLV/CHV: Introduce setup, 
enable and disable
functions

On Tue, Nov 18, 2014 at 10:32 AM, R, Durgadoss durgados...@intel.com wrote:
-Original Message-
From: Vivi, Rodrigo
Sent: Friday, November 14, 2014 10:23 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo; R, Durgadoss
Subject: [PATCH 11/15] drm/i915: PSR VLV/CHV: Introduce setup, enable and 
disable functions

The biggest difference from HSW/BDW PSR here is that VLV enable_source
function enables PSR but let it in Inactive state. So it might be called
on early stage along with setup and enable_sink ones.

v2: Rebase over intel_psr.c;
Remove docs from static functions;
Merge vlv_psr_active_on_pipe;
Timeout for psr transition is 250us;
Remove SRC_TRASMITTER_STATE;

 With SRC_TRANSMITTER_STATE not set to 1
 explicitly, if entry/exit works, I would like to know what DPCD
 register 71h is reading in your panel ?

 I would expect bit 0 of 71h to be 1.
 Is it the case ?

no. It is always 0.

DP_PSR_CAPS = 0xA

0xA ? could be.. but surprising how exit works
Without doing link training..
May be we are looking at 01h..?, but your
Description seems fine .. it is DP_PSR_CAPS.
Can we double check once ?

eDP spec v1.3 claims default setup time is 330 us.
So, I would expect bits[1:3] to be 0 (usually)

This is the DPCD hex dump from 00h to 0xf in the
Panels that I use: {from dmesg}
DPCD: 11 0a 84 41 00 00 01 c0 02 03 00 00 00 0b 00


 Can we check once ?

 Thanks,
 Durga

What do you suggest? get SRC_TRANSMITTER_STATE back?

Yes. The reason I say is because not all panels come with
a 1 in that bit and ideally panels with a 0 in that bit 71h[0]
are supposed to require link training after PSR exit
when the main link is off. The main link will be off if we do
not set the SRC_TRANSMITTER_STATE bit to 1.

So, removing it is not safe in my opinion. I would suggest
Keeping it there. And also, the same bit in the DPCD as well.

Thanks,
Durga




Cc: Durgadoss R durgados...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/intel_psr.c | 154 
 ---
 1 file changed, 129 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c 
b/drivers/gpu/drm/i915/intel_psr.c
index c296a89..bdb28f2 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -81,6 +81,17 @@ bool intel_psr_is_enabled(struct drm_device *dev)
   return (bool)dev_priv-psr.enabled;
 }

+static bool vlv_is_psr_active_on_pipe(struct drm_device *dev, int pipe)
+{
+  struct drm_i915_private *dev_priv = dev-dev_private;
+  uint32_t val;
+
+  val = I915_READ(VLV_PSRSTAT(pipe)) 
+VLV_EDP_PSR_CURR_STATE_MASK;
+  return (val == VLV_EDP_PSR_ACTIVE_NORFB_UP) ||
+ (val == VLV_EDP_PSR_ACTIVE_SF_UPDATE);
+}
+
 static void intel_psr_write_vsc(struct intel_dp *intel_dp,
   struct edp_vsc_psr *vsc_psr)
 {
@@ -110,7 +121,23 @@ static void intel_psr_write_vsc(struct intel_dp 
*intel_dp,
   POSTING_READ(ctl_reg);
 }

-static void intel_psr_setup_vsc(struct intel_dp *intel_dp)
+static void vlv_psr_setup_vsc(struct intel_dp *intel_dp)
+{
+  struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+  struct drm_device *dev = intel_dig_port-base.base.dev;
+  struct drm_i915_private *dev_priv = dev-dev_private;
+  struct drm_crtc *crtc = intel_dig_port-base.base.crtc;
+  enum pipe pipe = to_intel_crtc(crtc)-pipe;
+  uint32_t val;
+
+  /* VLV auto-generate VSC package as per EDP 1.3 spec, Table 3.10 */
+  val  = I915_READ(VLV_VSCSDP(pipe));
+  val = ~VLV_EDP_PSR_SDP_FREQ_MASK;
+  val |= VLV_EDP_PSR_SDP_FREQ_EVFRAME;
+  I915_WRITE(VLV_VSCSDP(pipe), val);
+}
+
+static void hsw_psr_setup_vsc(struct intel_dp *intel_dp)
 {
   struct edp_vsc_psr psr_vsc;

@@ -123,7 +150,13 @@ static void intel_psr_setup_vsc(struct intel_dp 
*intel_dp)
   intel_psr_write_vsc(intel_dp, psr_vsc);
 }

-static void intel_psr_enable_sink(struct intel_dp *intel_dp)
+static void vlv_psr_enable_sink(struct intel_dp *intel_dp)
+{
+  drm_dp_dpcd_writeb(intel_dp-aux, DP_PSR_EN_CFG,
+ DP_PSR_ENABLE);
+}
+
+static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
 {
   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
   struct drm_device *dev = dig_port-base.base.dev;
@@ -167,7 +200,21 @@ static void intel_psr_enable_sink(struct intel_dp 
*intel_dp)
  (aux_clock_divider  DP_AUX_CH_CTL_BIT_CLOCK_2X_SHIFT));
 }

-static void intel_psr_enable_source(struct intel_dp *intel_dp)
+static void vlv_psr_enable_source(struct intel_dp *intel_dp)
+{
+  struct intel_digital_port

Re: [Intel-gfx] [PATCH] drm/i915: VLV/CHV PSR Software timer mode

[R, Durgadoss]

-Original Message-
From: Vivi, Rodrigo
Sent: Wednesday, November 19, 2014 9:08 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo; R, Durgadoss
Subject: [PATCH] drm/i915: VLV/CHV PSR Software timer mode

This patch introduces exit/activate functions for PSR
on VLV+. Since on VLV+ HW cannot track frame updates and force PSR
exit let's use fully SW tracking available.

v2: Rebase over intel_psr.c;
Remove Single Frame update transitioning from state 3 to 5 directly;
Fake a software invalidation for sprites and cursor so we don't miss
any screen update;

v3: As pointed out by Durgadoss msecs_to_jiffies used on wait_for only uses 
int,
so let's use 1 instead. Althought the 1/4 of this is needed for the
transition let's use 1 for simplicity;
Also fix comments as suggested by Durgadoss

Cc: Durgadoss R durgados...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com

1 ms for transition looks fine..

Reviewed-by: Durgadoss R durgados...@intel.com

Thanks,
Durga

---
 drivers/gpu/drm/i915/intel_psr.c | 97 ++--
 1 file changed, 84 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c 
b/drivers/gpu/drm/i915/intel_psr.c
index 30f341a..dd0e6e0 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -195,6 +195,23 @@ static void vlv_psr_enable_source(struct intel_dp 
*intel_dp)
  VLV_EDP_PSR_ENABLE);
 }

+static void vlv_psr_activate(struct intel_dp *intel_dp)
+{
+  struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+  struct drm_device *dev = dig_port-base.base.dev;
+  struct drm_i915_private *dev_priv = dev-dev_private;
+  struct drm_crtc *crtc = dig_port-base.base.crtc;
+  enum pipe pipe = to_intel_crtc(crtc)-pipe;
+
+  /* Let's do the transition from PSR_state 1 to PSR_state 2
+   * that is PSR transition to active - static frame transmission.
+   * Then Hardware is responsible for the transition to PSR_state 3
+   * that is PSR active - no Remote Frame Buffer (RFB) update.
+   */
+  I915_WRITE(VLV_PSRCTL(pipe), I915_READ(VLV_PSRCTL(pipe)) |
+ VLV_EDP_PSR_ACTIVE_ENTRY);
+}
+
 static void hsw_psr_enable_source(struct intel_dp *intel_dp)
 {
   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
@@ -283,12 +300,16 @@ static void intel_psr_activate(struct intel_dp *intel_dp)
   WARN_ON(dev_priv-psr.active);
   lockdep_assert_held(dev_priv-psr.lock);

-  /* Enable/Re-enable PSR on the host
-   * On HSW+ after we enable PSR on source it will activate it
-   * as soon as it match configure idle_frame count. So
-   * we just actually enable it here on activation time.
-   */
-  hsw_psr_enable_source(intel_dp);
+  /* Enable/Re-enable PSR on the host */
+  if (HAS_DDI(dev))
+  /* On HSW+ after we enable PSR on source it will activate it
+   * as soon as it match configure idle_frame count. So
+   * we just actually enable it here on activation time.
+   */
+  hsw_psr_enable_source(intel_dp);
+  else
+  vlv_psr_activate(intel_dp);
+
   dev_priv-psr.active = true;
 }

@@ -436,18 +457,27 @@ static void intel_psr_work(struct work_struct *work)
   struct drm_i915_private *dev_priv =
   container_of(work, typeof(*dev_priv), psr.work.work);
   struct intel_dp *intel_dp = dev_priv-psr.enabled;
+  struct drm_crtc *crtc = dp_to_dig_port(intel_dp)-base.base.crtc;
+  enum pipe pipe = to_intel_crtc(crtc)-pipe;

   /* We have to make sure PSR is ready for re-enable
* otherwise it keeps disabled until next full enable/disable cycle.
* PSR might take some time to get fully disabled
* and be ready for re-enable.
*/
-  if (wait_for((I915_READ(EDP_PSR_STATUS_CTL(dev_priv-dev)) 
-EDP_PSR_STATUS_STATE_MASK) == 0, 50)) {
-  DRM_ERROR(Timed out waiting for PSR Idle for re-enable\n);
-  return;
+  if (HAS_DDI(dev_priv-dev)) {
+  if (wait_for((I915_READ(EDP_PSR_STATUS_CTL(dev_priv-dev)) 
+EDP_PSR_STATUS_STATE_MASK) == 0, 50)) {
+  DRM_ERROR(Timed out waiting for PSR Idle for 
re-enable\n);
+  return;
+  }
+  } else {
+  if (wait_for((I915_READ(VLV_PSRSTAT(pipe)) 
+VLV_EDP_PSR_IN_TRANS) == 0, 1)) {
+  DRM_ERROR(Timed out waiting for PSR Idle for 
re-enable\n);
+  return;
+  }
   }
-
   mutex_lock(dev_priv-psr.lock);
   intel_dp = dev_priv-psr.enabled;

@@ -470,17 +500,47 @@ unlock:
 static void intel_psr_exit(struct drm_device *dev)
 {
   struct drm_i915_private *dev_priv = dev-dev_private;
+  struct intel_dp *intel_dp = dev_priv-psr.enabled;
+  struct drm_crtc *crtc

Re: [Intel-gfx] [PATCH] drm/i915: PSR VLV/CHV: Introduce setup, enable and disable functions

[R, Durgadoss]

-Original Message-
From: Vivi, Rodrigo
Sent: Wednesday, November 19, 2014 9:07 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo; R, Durgadoss
Subject: [PATCH] drm/i915: PSR VLV/CHV: Introduce setup, enable and disable 
functions

The biggest difference from HSW/BDW PSR here is that VLV enable_source
function enables PSR but let it in Inactive state. So it might be called
on early stage along with setup and enable_sink ones.

v2: Rebase over intel_psr.c;
Remove docs from static functions;
Merge vlv_psr_active_on_pipe;
Timeout for psr transition is 250us;
Remove SRC_TRASMITTER_STATE;

v3: Rebase after is_psr_enabled function got removed;
Get SRC_TRANSMITTER_STATE back to be on the safe side since
default for panels is to require link training on exit when
main link off;
As pointed out by Durgadoss msecs_to_jiffies used on wait_for only uses 
 int,
so let's use 1 instead. Althought the 1/4 of this is needed for the
transition let's use 1 for simplicity;

Cc: Durgadoss R durgados...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/intel_psr.c | 155 ---
 1 file changed, 130 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c 
b/drivers/gpu/drm/i915/intel_psr.c
index 576ad02..30f341a 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -61,6 +61,17 @@ static bool is_edp_psr(struct intel_dp *intel_dp)
   return intel_dp-psr_dpcd[0]  DP_PSR_IS_SUPPORTED;
 }

+static bool vlv_is_psr_active_on_pipe(struct drm_device *dev, int pipe)
+{
+  struct drm_i915_private *dev_priv = dev-dev_private;
+  uint32_t val;
+
+  val = I915_READ(VLV_PSRSTAT(pipe)) 
+VLV_EDP_PSR_CURR_STATE_MASK;
+  return (val == VLV_EDP_PSR_ACTIVE_NORFB_UP) ||
+ (val == VLV_EDP_PSR_ACTIVE_SF_UPDATE);
+}
+
 static void intel_psr_write_vsc(struct intel_dp *intel_dp,
   struct edp_vsc_psr *vsc_psr)
 {
@@ -90,7 +101,23 @@ static void intel_psr_write_vsc(struct intel_dp *intel_dp,
   POSTING_READ(ctl_reg);
 }

-static void intel_psr_setup_vsc(struct intel_dp *intel_dp)
+static void vlv_psr_setup_vsc(struct intel_dp *intel_dp)
+{
+  struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+  struct drm_device *dev = intel_dig_port-base.base.dev;
+  struct drm_i915_private *dev_priv = dev-dev_private;
+  struct drm_crtc *crtc = intel_dig_port-base.base.crtc;
+  enum pipe pipe = to_intel_crtc(crtc)-pipe;
+  uint32_t val;
+
+  /* VLV auto-generate VSC package as per EDP 1.3 spec, Table 3.10 */
+  val  = I915_READ(VLV_VSCSDP(pipe));
+  val = ~VLV_EDP_PSR_SDP_FREQ_MASK;
+  val |= VLV_EDP_PSR_SDP_FREQ_EVFRAME;
+  I915_WRITE(VLV_VSCSDP(pipe), val);
+}
+
+static void hsw_psr_setup_vsc(struct intel_dp *intel_dp)
 {
   struct edp_vsc_psr psr_vsc;

@@ -103,7 +130,13 @@ static void intel_psr_setup_vsc(struct intel_dp *intel_dp)
   intel_psr_write_vsc(intel_dp, psr_vsc);
 }

-static void intel_psr_enable_sink(struct intel_dp *intel_dp)
+static void vlv_psr_enable_sink(struct intel_dp *intel_dp)
+{
+  drm_dp_dpcd_writeb(intel_dp-aux, DP_PSR_EN_CFG,
+ DP_PSR_ENABLE);
+}
+
+static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
 {
   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
   struct drm_device *dev = dig_port-base.base.dev;
@@ -147,7 +180,22 @@ static void intel_psr_enable_sink(struct intel_dp 
*intel_dp)
  (aux_clock_divider  DP_AUX_CH_CTL_BIT_CLOCK_2X_SHIFT));
 }

-static void intel_psr_enable_source(struct intel_dp *intel_dp)
+static void vlv_psr_enable_source(struct intel_dp *intel_dp)
+{
+  struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+  struct drm_device *dev = dig_port-base.base.dev;
+  struct drm_i915_private *dev_priv = dev-dev_private;
+  struct drm_crtc *crtc = dig_port-base.base.crtc;
+  enum pipe pipe = to_intel_crtc(crtc)-pipe;
+
+  /* Transition from PSR_state 0 to PSR_state 1, i.e. PSR Inactive */
+  I915_WRITE(VLV_PSRCTL(pipe),
+ VLV_EDP_PSR_MODE_SW_TIMER |
+ VLV_EDP_PSR_SRC_TRANSMITTER_STATE |

This looks safe for now.

Reviewed-by: Durgadoss R durgados...@intel.com

Thanks,
Durga

+ VLV_EDP_PSR_ENABLE);
+}
+
+static void hsw_psr_enable_source(struct intel_dp *intel_dp)
 {
   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
   struct drm_device *dev = dig_port-base.base.dev;
@@ -225,7 +273,7 @@ static bool intel_psr_match_conditions(struct intel_dp 
*intel_dp)
   return true;
 }

-static void intel_psr_do_enable(struct intel_dp *intel_dp)
+static void intel_psr_activate(struct intel_dp *intel_dp)
 {
   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
   struct drm_device *dev = intel_dig_port

Re: [Intel-gfx] [PATCH] drm/i915: Remove intel_psr_is_enabled function.

[R, Durgadoss]

-Original Message-
From: Vivi, Rodrigo
Sent: Wednesday, November 19, 2014 9:05 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo; Daniel Vetter; R, Durgadoss
Subject: [PATCH] drm/i915: Remove intel_psr_is_enabled function.

This function was in use to check if psr feature got enabled.
However on HSW and BDW we currently force psr exit by disabling

s/psr/PSR

EDP_PSR_ENABLE bit at EDP_PSR_CTL(dev). So this function was actually
returning the active/inactive state that is different from the enable/disable
meaning and had the risk of false negative.

But anyway this check with DRRS was dangerous, since DRRS could try to get 
enabled
before PSR gets there. So let's just remove it for now.
A propper syncronization mechanism must be implemented later probably
using pipe config.

Proper synchronization..

With that,

Reviewed-by: Durgadoss R durgados...@intel.com

Thanks,
Durga


Cc: Daniel Vetter dan...@ffwll.ch
Cc: Durgadoss R durgados...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c  |  9 ++---
 drivers/gpu/drm/i915/intel_drv.h |  1 -
 drivers/gpu/drm/i915/intel_psr.c | 10 --
 3 files changed, 2 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 46731da..5be6f5e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4761,14 +4761,9 @@ void intel_dp_set_drrs_state(struct drm_device *dev, 
int refresh_rate)
   }

   /*
-   * FIXME: This needs proper synchronization with psr state. But really
-   * hard to tell without seeing the user of this function of this code.
-   * Check locking and ordering once that lands.
+   * FIXME: This needs proper synchronization with psr state for some
+   * platforms that cannot have PSR and DRRS enabled at the same time.
*/
-  if (INTEL_INFO(dev)-gen  8  intel_psr_is_enabled(dev)) {
-  DRM_DEBUG_KMS(DRRS is disabled as PSR is enabled\n);
-  return;
-  }

   encoder = intel_attached_encoder(intel_connector-base);
   intel_dp = enc_to_intel_dp(encoder-base);
diff --git a/drivers/gpu/drm/i915/intel_drv.h 
b/drivers/gpu/drm/i915/intel_drv.h
index d1f9b63..7feded0 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1113,7 +1113,6 @@ void intel_backlight_unregister(struct drm_device *dev);


 /* intel_psr.c */
-bool intel_psr_is_enabled(struct drm_device *dev);
 void intel_psr_enable(struct intel_dp *intel_dp);
 void intel_psr_disable(struct intel_dp *intel_dp);
 void intel_psr_invalidate(struct drm_device *dev,
diff --git a/drivers/gpu/drm/i915/intel_psr.c 
b/drivers/gpu/drm/i915/intel_psr.c
index 843762a..576ad02 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -61,16 +61,6 @@ static bool is_edp_psr(struct intel_dp *intel_dp)
   return intel_dp-psr_dpcd[0]  DP_PSR_IS_SUPPORTED;
 }

-bool intel_psr_is_enabled(struct drm_device *dev)
-{
-  struct drm_i915_private *dev_priv = dev-dev_private;
-
-  if (!HAS_PSR(dev))
-  return false;
-
-  return I915_READ(EDP_PSR_CTL(dev))  EDP_PSR_ENABLE;
-}
-
 static void intel_psr_write_vsc(struct intel_dp *intel_dp,
   struct edp_vsc_psr *vsc_psr)
 {
--
1.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/15] drm/i915: Introduce intel_psr.c

[R, Durgadoss]

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Rodrigo Vivi
Sent: Friday, November 14, 2014 10:22 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 02/15] drm/i915: Introduce intel_psr.c

No functional changes. Just cleaning and reorganizing it.

v2: Rebase it puting it to begin of psr rework. This helps to blame easily
at least latest changes.

Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/intel_ddi.c |   4 +-
 drivers/gpu/drm/i915/intel_display.c |   2 +-
 drivers/gpu/drm/i915/intel_dp.c  | 381 +
 drivers/gpu/drm/i915/intel_drv.h |  21 +-
 drivers/gpu/drm/i915/intel_frontbuffer.c |   4 +-
 drivers/gpu/drm/i915/intel_psr.c | 408 +++
 7 files changed, 428 insertions(+), 393 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_psr.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 891e584..e4083e4 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -51,6 +51,7 @@ i915-y += intel_audio.o \
 intel_frontbuffer.o \
 intel_modes.o \
 intel_overlay.o \
+intel_psr.o \
 intel_sideband.o \
 intel_sprite.o
 i915-$(CONFIG_ACPI)   += intel_acpi.o intel_opregion.o
diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
b/drivers/gpu/drm/i915/intel_ddi.c
index 68703ce..a5a8acd 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1228,7 +1228,7 @@ static void intel_enable_ddi(struct intel_encoder 
*intel_encoder)
   intel_dp_stop_link_train(intel_dp);

   intel_edp_backlight_on(intel_dp);
-  intel_edp_psr_enable(intel_dp);
+  intel_psr_enable(intel_dp);
   }

   if (intel_crtc-config.has_audio) {
@@ -1254,7 +1254,7 @@ static void intel_disable_ddi(struct intel_encoder 
*intel_encoder)
   if (type == INTEL_OUTPUT_EDP) {
   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);

-  intel_edp_psr_disable(intel_dp);
+  intel_psr_disable(intel_dp);
   intel_edp_backlight_off(intel_dp);
   }
 }
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 4706856..2ca6939 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12310,7 +12310,7 @@ static void intel_setup_outputs(struct drm_device *dev)
   if (SUPPORTS_TV(dev))
   intel_tv_init(dev);

-  intel_edp_psr_init(dev);
+  intel_psr_init(dev);

   for_each_intel_encoder(dev, encoder) {
   encoder-base.possible_crtcs = encoder-crtc_mask;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 01834cd..98f7ecd 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2066,385 +2066,6 @@ static void intel_dp_get_config(struct intel_encoder 
*encoder,
   }
 }

-static bool is_edp_psr(struct intel_dp *intel_dp)
-{
-  return intel_dp-psr_dpcd[0]  DP_PSR_IS_SUPPORTED;
-}
-
-static bool intel_edp_is_psr_enabled(struct drm_device *dev)
-{
-  struct drm_i915_private *dev_priv = dev-dev_private;
-
-  if (!HAS_PSR(dev))
-  return false;
-
-  return I915_READ(EDP_PSR_CTL(dev))  EDP_PSR_ENABLE;
-}
-
-static void intel_edp_psr_write_vsc(struct intel_dp *intel_dp,
-  struct edp_vsc_psr *vsc_psr)
-{
-  struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
-  struct drm_device *dev = dig_port-base.base.dev;
-  struct drm_i915_private *dev_priv = dev-dev_private;
-  struct intel_crtc *crtc = to_intel_crtc(dig_port-base.base.crtc);
-  u32 ctl_reg = HSW_TVIDEO_DIP_CTL(crtc-config.cpu_transcoder);
-  u32 data_reg = HSW_TVIDEO_DIP_VSC_DATA(crtc-config.cpu_transcoder);
-  uint32_t *data = (uint32_t *) vsc_psr;
-  unsigned int i;
-
-  /* As per BSPec (Pipe Video Data Island Packet), we need to disable
- the video DIP being updated before program video DIP data buffer
- registers for DIP being updated. */
-  I915_WRITE(ctl_reg, 0);
-  POSTING_READ(ctl_reg);
-
-  for (i = 0; i  VIDEO_DIP_VSC_DATA_SIZE; i += 4) {
-  if (i  sizeof(struct edp_vsc_psr))
-  I915_WRITE(data_reg + i, *data++);
-  else
-  I915_WRITE(data_reg + i, 0);
-  }
-
-  I915_WRITE(ctl_reg, VIDEO_DIP_ENABLE_VSC_HSW);
-  POSTING_READ(ctl_reg);
-}
-
-static void intel_edp_psr_setup_vsc(struct intel_dp *intel_dp)
-{
-  struct edp_vsc_psr psr_vsc;
-
-  /* Prepare VSC packet as per EDP 1.3 spec, Table 3.10 */
-  memset(psr_vsc, 0, sizeof(psr_vsc));
-  psr_vsc.sdp_header.HB0 = 0;
-  psr_vsc.sdp_header.HB1 = 

Re: [Intel-gfx] [PATCH 03/15] drm/i915: Add PSR docbook

[R, Durgadoss]

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Rodrigo Vivi
Sent: Friday, November 14, 2014 10:22 PM
To: intel-gfx@lists.freedesktop.org
Cc: Daniel Vetter; Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 03/15] drm/i915: Add PSR docbook

Let's document PSR a bit. No functional changes.

v2: Add actual DocBook entry and accept Daniel's improvements.

Cc: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 Documentation/DocBook/drm.tmpl   |  5 +++
 drivers/gpu/drm/i915/intel_psr.c | 73 
 2 files changed, 78 insertions(+)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 9449cd6..a1168a8 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -3893,6 +3893,11 @@ int num_ioctls;/synopsis
 !Idrivers/gpu/drm/i915/intel_audio.c
   /sect2
   sect2
+  titlePanel Self Refresh PSR (PSR/SRD)/title
+!Pdrivers/gpu/drm/i915/intel_psr.c Panel Self Refresh (PSR/SRD)
+!Idrivers/gpu/drm/i915/intel_psr.c
+  /sect2
+  sect2
 titleDPIO/title
 !Pdrivers/gpu/drm/i915/i915_reg.h DPIO
   table id=dpiox2
diff --git a/drivers/gpu/drm/i915/intel_psr.c 
b/drivers/gpu/drm/i915/intel_psr.c
index 7b3ed91..716b8a9 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -21,6 +21,36 @@
  * DEALINGS IN THE SOFTWARE.
  */

+/**
+ * DOC: Panel Self Refresh (PSR/SRD)
+ *
+ * Since Haswell Display controller supports Panel Self-Refresh on display
+ * panels witch have a remote frame buffer (RFB) implemented according to PSR

s/witch/which ;)

oh, I see that this is already merged, anyway..

Thanks,
Durga

+ * spec in eDP1.3. PSR feature allows the display to go to lower standby 
states
+ * when system is idle but display is on as it eliminates display refresh
+ * request to DDR memory completely as long as the frame buffer for that
+ * display is unchanged.
+ *
+ * Panel Self Refresh must be supported by both Hardware (source) and
+ * Panel (sink).
+ *
+ * PSR saves power by caching the framebuffer in the panel RFB, which allows 
us
+ * to power down the link and memory controller. For DSI panels the same idea
+ * is called manual mode.
+ *
+ * The implementation uses the hardware-based PSR support which automatically
+ * enters/exits self-refresh mode. The hardware takes care of sending the
+ * required DP aux message and could even retrain the link (that part isn't
+ * enabled yet though). The hardware also keeps track of any frontbuffer
+ * changes to know when to exit self-refresh mode again. Unfortunately that
+ * part doesn't work too well, hence why the i915 PSR support uses the
+ * software frontbuffer tracking to make sure it doesn't miss a screen
+ * update. For this integration intel_psr_invalidate() and intel_psr_flush()
+ * get called by the frontbuffer tracking code. Note that because of locking
+ * issues the self-refresh re-enable code is done from a work queue, which
+ * must be correctly synchronized/cancelled when shutting down the pipe.
+ */
+
 #include drm/drmP.h

 #include intel_drv.h
@@ -217,6 +247,12 @@ static void intel_psr_do_enable(struct intel_dp *intel_dp)
   dev_priv-psr.active = true;
 }

+/**
+ * intel_psr_enable - Enable PSR
+ * @intel_dp: Intel DP
+ *
+ * This function can only be called after the pipe is fully trained and 
enabled.
+ */
 void intel_psr_enable(struct intel_dp *intel_dp)
 {
   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
@@ -258,6 +294,12 @@ unlock:
   mutex_unlock(dev_priv-psr.lock);
 }

+/**
+ * intel_psr_disable - Disable PSR
+ * @intel_dp: Intel DP
+ *
+ * This function needs to be called before disabling pipe.
+ */
 void intel_psr_disable(struct intel_dp *intel_dp)
 {
   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
@@ -342,6 +384,18 @@ static void intel_psr_exit(struct drm_device *dev)

 }

+/**
+ * intel_psr_invalidate - Invalidade PSR
+ * @dev: DRM device
+ * @frontbuffer_bits: frontbuffer plane tracking bits
+ *
+ * Since the hardware frontbuffer tracking has gaps we need to integrate
+ * with the software frontbuffer tracking. This function gets called every
+ * time frontbuffer rendering starts and a buffer gets dirtied. PSR must be
+ * disabled if the frontbuffer mask contains a buffer relevant to PSR.
+ *
+ * Dirty frontbuffers relevant to PSR are tracked in busy_frontbuffer_bits.
+ */
 void intel_psr_invalidate(struct drm_device *dev,
 unsigned frontbuffer_bits)
 {
@@ -366,6 +420,18 @@ void intel_psr_invalidate(struct drm_device *dev,
   mutex_unlock(dev_priv-psr.lock);
 }

+/**
+ * intel_psr_flush - Flush PSR
+ * @dev: DRM device
+ * @frontbuffer_bits: frontbuffer plane tracking bits
+ *
+ * Since the hardware frontbuffer tracking has gaps we need to integrate
+ * with the software frontbuffer tracking. This function gets called 

Re: [Intel-gfx] [PATCH 06/15] drm/i915: PSR get full link off x standby from VBT

[R, Durgadoss]

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Rodrigo Vivi
Sent: Friday, November 14, 2014 10:23 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 06/15] drm/i915: PSR get full link off x standby 
from VBT

OEMs can specify if full_link might be always enabled, i.e. only_standby
over VBT.

Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com

I have not looked at/tried these VBT bits myself. If that's ok then,

For patches 4,5,6:
Reviewed-by: Durgadoss R durgados...@intel.com

Thanks,
Durga

---
 drivers/gpu/drm/i915/intel_psr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c 
b/drivers/gpu/drm/i915/intel_psr.c
index 576568e..e706c9d 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -120,7 +120,7 @@ static void intel_psr_enable_sink(struct intel_dp 
*intel_dp)
   struct drm_i915_private *dev_priv = dev-dev_private;
   uint32_t aux_clock_divider;
   int precharge = 0x3;
-  bool only_standby = false;
+  bool only_standby = dev_priv-vbt.psr.full_link;
   static const uint8_t aux_msg[] = {
   [0] = DP_AUX_NATIVE_WRITE  4,
   [1] = DP_SET_POWER  8,
--
1.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 08/15] drm/i915: remove PSR BDW single frame update.

[R, Durgadoss]

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Rodrigo Vivi
Sent: Friday, November 14, 2014 10:23 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 08/15] drm/i915: remove PSR BDW single frame 
update.

Single frame update is a feature available on BDW for PSR that allows
Source to send Sink only one frame and get it updated. Usually useful
when page fliping. However with our frontbuffer tracking where we force

flipping

psr exit on flips we don't need this feature.

Also after it got added here many workaround was added to documentation
to mask some bits when using single frame update. So the safest thing
is to just stop using it.

Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com

Again, I have not looked at the BDW spec. But the commit message
sounds reasonable. So,

Reviewed-by: Durgadoss R durgados...@intel.com

Thanks,
Durga

---
 drivers/gpu/drm/i915/intel_psr.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c 
b/drivers/gpu/drm/i915/intel_psr.c
index 4cfe7a4..66d24c2 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -180,7 +180,6 @@ static void intel_psr_enable_source(struct intel_dp 
*intel_dp)
   val |= EDP_PSR_LINK_STANDBY;
   val |= EDP_PSR_TP2_TP3_TIME_0us;
   val |= EDP_PSR_TP1_TIME_0us;
-  val |= IS_BROADWELL(dev) ? BDW_PSR_SINGLE_FRAME : 0;
   } else
   val |= EDP_PSR_LINK_DISABLE;

--
1.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 09/15] drm/i915: Fix intel_psr_is_enabled function and document it.

[R, Durgadoss]

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Rodrigo Vivi
Sent: Friday, November 14, 2014 10:23 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 09/15] drm/i915: Fix intel_psr_is_enabled function 
and document it.

This function can be used to check if psr feature got enabled.
However on HSW and BDW we currently force psr exit by disabling
EDP_PSR_ENABLE bit at EDP_PSR_CTL(dev). So this function was actually
returning the active/inactive state that is different from the enable/disable
meaning and had the risk of false negative.

So let's just return the presence of intel_dp at dev_priv-psr.enabled.

It would be more easy to just check this presence directly but let's keep
it more organized.

Agreed, but shouldn't we protect it using psr.lock ?

Thanks,
Durga


Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/intel_psr.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c 
b/drivers/gpu/drm/i915/intel_psr.c
index 66d24c2..c296a89 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -61,6 +61,16 @@ static bool is_edp_psr(struct intel_dp *intel_dp)
   return intel_dp-psr_dpcd[0]  DP_PSR_IS_SUPPORTED;
 }

+/**
+ * intel_psr_is_enabled - Is PSR enabled?
+ * @dev: DRM Device
+ *
+ * This function can be used to verify if PSR feature is enabled.
+ * Since on Haswell+ we force the exit by disabling
+ * EDP_PSR_ENABLE bit at EDP_PSR_CTL(dev)
+ * the most reliable way to export if psr feature is enabled is to
+ * check the presence of intel_dp at dev_priv-psr.enabled.
+ */
 bool intel_psr_is_enabled(struct drm_device *dev)
 {
   struct drm_i915_private *dev_priv = dev-dev_private;
@@ -68,7 +78,7 @@ bool intel_psr_is_enabled(struct drm_device *dev)
   if (!HAS_PSR(dev))
   return false;

-  return I915_READ(EDP_PSR_CTL(dev))  EDP_PSR_ENABLE;
+  return (bool)dev_priv-psr.enabled;
 }

 static void intel_psr_write_vsc(struct intel_dp *intel_dp,
--
1.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 10/15] drm/i915: Add PSR registers for PSR VLV/CHV.

[R, Durgadoss]

-Original Message-
From: Vivi, Rodrigo
Sent: Friday, November 14, 2014 10:23 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo; R, Durgadoss
Subject: [PATCH 10/15] drm/i915: Add PSR registers for PSR VLV/CHV.

Baytrail (Valleyview) and Braswell (Cherryview) uses a complete different
implementation of PSR that we currently have supported for
Haswell and Broadwell. So let's start by adding registers definitions.

I usually don't like commit that adds just registers without using,
but after I put all in one commit I realized that no one would want
to take the AR to review it so I decided to split in order to make
reviewer's life easier. Only last commit in this series will actually
enable the PSR on intel enable panel path.

But as it happens currently with HSW/BDW the plan is to let it
disabled by default (protected by kernel parameter)
while we are able to fully validate it.

v2: Remove a unused bit definition that isn't used on vlv and
reserved on chv as pointed out by Durgadoss.

Cc: Durgadoss R durgados...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com

Reviewed-by: Durgadoss R durgados...@intel.com

Thanks,
Durga

---
 drivers/gpu/drm/i915/i915_reg.h | 36 
 1 file changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 35cfc16..667a923 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2511,6 +2511,42 @@ enum punit_power_well {
 #define PIPESRC(trans) _TRANSCODER2(trans, _PIPEASRC)
 #define PIPE_MULT(trans) _TRANSCODER2(trans, _PIPE_MULT_A)

+/* VLV eDP PSR registers */
+#define _PSRCTLA  (VLV_DISPLAY_BASE + 0x60090)
+#define _PSRCTLB  (VLV_DISPLAY_BASE + 0x61090)
+#define  VLV_EDP_PSR_ENABLE   (10)
+#define  VLV_EDP_PSR_RESET(11)
+#define  VLV_EDP_PSR_MODE_MASK(72)
+#define  VLV_EDP_PSR_MODE_HW_TIMER(13)
+#define  VLV_EDP_PSR_MODE_SW_TIMER(12)
+#define  VLV_EDP_PSR_SINGLE_FRAME_UPDATE  (17)
+#define  VLV_EDP_PSR_ACTIVE_ENTRY (18)
+#define  VLV_EDP_PSR_SRC_TRANSMITTER_STATE(19)
+#define  VLV_EDP_PSR_DBL_FRAME(110)
+#define  VLV_EDP_PSR_FRAME_COUNT_MASK (0xff16)
+#define  VLV_EDP_PSR_IDLE_FRAME_SHIFT 16
+#define VLV_PSRCTL(pipe) _PIPE(pipe, _PSRCTLA, _PSRCTLB)
+
+#define _VSCSDPA  (VLV_DISPLAY_BASE + 0x600a0)
+#define _VSCSDPB  (VLV_DISPLAY_BASE + 0x610a0)
+#define  VLV_EDP_PSR_SDP_FREQ_MASK(330)
+#define  VLV_EDP_PSR_SDP_FREQ_ONCE(131)
+#define  VLV_EDP_PSR_SDP_FREQ_EVFRAME (130)
+#define VLV_VSCSDP(pipe)  _PIPE(pipe, _VSCSDPA, _VSCSDPB)
+
+#define _PSRSTATA (VLV_DISPLAY_BASE + 0x60094)
+#define _PSRSTATB (VLV_DISPLAY_BASE + 0x61094)
+#define  VLV_EDP_PSR_LAST_STATE_MASK  (73)
+#define  VLV_EDP_PSR_CURR_STATE_MASK  7
+#define  VLV_EDP_PSR_DISABLED (00)
+#define  VLV_EDP_PSR_INACTIVE (10)
+#define  VLV_EDP_PSR_IN_TRANS_TO_ACTIVE   (20)
+#define  VLV_EDP_PSR_ACTIVE_NORFB_UP  (30)
+#define  VLV_EDP_PSR_ACTIVE_SF_UPDATE (40)
+#define  VLV_EDP_PSR_EXIT (50)
+#define  VLV_EDP_PSR_IN_TRANS (17)
+#define VLV_PSRSTAT(pipe) _PIPE(pipe, _PSRSTATA, _PSRSTATB)
+
 /* HSW+ eDP PSR registers */
 #define EDP_PSR_BASE(dev)   (IS_HASWELL(dev) ? 0x64800 : 
 0x6f800)
 #define EDP_PSR_CTL(dev)  (EDP_PSR_BASE(dev) + 0)
--
1.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 11/15] drm/i915: PSR VLV/CHV: Introduce setup, enable and disable functions

[R, Durgadoss]

-Original Message-
From: Vivi, Rodrigo
Sent: Friday, November 14, 2014 10:23 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo; R, Durgadoss
Subject: [PATCH 11/15] drm/i915: PSR VLV/CHV: Introduce setup, enable and 
disable functions

The biggest difference from HSW/BDW PSR here is that VLV enable_source
function enables PSR but let it in Inactive state. So it might be called
on early stage along with setup and enable_sink ones.

v2: Rebase over intel_psr.c;
Remove docs from static functions;
Merge vlv_psr_active_on_pipe;
Timeout for psr transition is 250us;
Remove SRC_TRASMITTER_STATE;

With SRC_TRANSMITTER_STATE not set to 1
explicitly, if entry/exit works, I would like to know what DPCD
register 71h is reading in your panel ?

I would expect bit 0 of 71h to be 1.
Is it the case ? Can we check once ?

Thanks,
Durga


Cc: Durgadoss R durgados...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/intel_psr.c | 154 ---
 1 file changed, 129 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c 
b/drivers/gpu/drm/i915/intel_psr.c
index c296a89..bdb28f2 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -81,6 +81,17 @@ bool intel_psr_is_enabled(struct drm_device *dev)
   return (bool)dev_priv-psr.enabled;
 }

+static bool vlv_is_psr_active_on_pipe(struct drm_device *dev, int pipe)
+{
+  struct drm_i915_private *dev_priv = dev-dev_private;
+  uint32_t val;
+
+  val = I915_READ(VLV_PSRSTAT(pipe)) 
+VLV_EDP_PSR_CURR_STATE_MASK;
+  return (val == VLV_EDP_PSR_ACTIVE_NORFB_UP) ||
+ (val == VLV_EDP_PSR_ACTIVE_SF_UPDATE);
+}
+
 static void intel_psr_write_vsc(struct intel_dp *intel_dp,
   struct edp_vsc_psr *vsc_psr)
 {
@@ -110,7 +121,23 @@ static void intel_psr_write_vsc(struct intel_dp *intel_dp,
   POSTING_READ(ctl_reg);
 }

-static void intel_psr_setup_vsc(struct intel_dp *intel_dp)
+static void vlv_psr_setup_vsc(struct intel_dp *intel_dp)
+{
+  struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+  struct drm_device *dev = intel_dig_port-base.base.dev;
+  struct drm_i915_private *dev_priv = dev-dev_private;
+  struct drm_crtc *crtc = intel_dig_port-base.base.crtc;
+  enum pipe pipe = to_intel_crtc(crtc)-pipe;
+  uint32_t val;
+
+  /* VLV auto-generate VSC package as per EDP 1.3 spec, Table 3.10 */
+  val  = I915_READ(VLV_VSCSDP(pipe));
+  val = ~VLV_EDP_PSR_SDP_FREQ_MASK;
+  val |= VLV_EDP_PSR_SDP_FREQ_EVFRAME;
+  I915_WRITE(VLV_VSCSDP(pipe), val);
+}
+
+static void hsw_psr_setup_vsc(struct intel_dp *intel_dp)
 {
   struct edp_vsc_psr psr_vsc;

@@ -123,7 +150,13 @@ static void intel_psr_setup_vsc(struct intel_dp *intel_dp)
   intel_psr_write_vsc(intel_dp, psr_vsc);
 }

-static void intel_psr_enable_sink(struct intel_dp *intel_dp)
+static void vlv_psr_enable_sink(struct intel_dp *intel_dp)
+{
+  drm_dp_dpcd_writeb(intel_dp-aux, DP_PSR_EN_CFG,
+ DP_PSR_ENABLE);
+}
+
+static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
 {
   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
   struct drm_device *dev = dig_port-base.base.dev;
@@ -167,7 +200,21 @@ static void intel_psr_enable_sink(struct intel_dp 
*intel_dp)
  (aux_clock_divider  DP_AUX_CH_CTL_BIT_CLOCK_2X_SHIFT));
 }

-static void intel_psr_enable_source(struct intel_dp *intel_dp)
+static void vlv_psr_enable_source(struct intel_dp *intel_dp)
+{
+  struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+  struct drm_device *dev = dig_port-base.base.dev;
+  struct drm_i915_private *dev_priv = dev-dev_private;
+  struct drm_crtc *crtc = dig_port-base.base.crtc;
+  enum pipe pipe = to_intel_crtc(crtc)-pipe;
+
+  /* Transition from PSR_state 0 to PSR_state 1, i.e. PSR Inactive */
+  I915_WRITE(VLV_PSRCTL(pipe),
+ VLV_EDP_PSR_MODE_SW_TIMER |
+ VLV_EDP_PSR_ENABLE);
+}
+
+static void hsw_psr_enable_source(struct intel_dp *intel_dp)
 {
   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
   struct drm_device *dev = dig_port-base.base.dev;
@@ -247,7 +294,7 @@ static bool intel_psr_match_conditions(struct intel_dp 
*intel_dp)
   return true;
 }

-static void intel_psr_do_enable(struct intel_dp *intel_dp)
+static void intel_psr_activate(struct intel_dp *intel_dp)
 {
   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
   struct drm_device *dev = intel_dig_port-base.base.dev;
@@ -257,9 +304,12 @@ static void intel_psr_do_enable(struct intel_dp *intel_dp)
   WARN_ON(dev_priv-psr.active);
   lockdep_assert_held(dev_priv-psr.lock);

-  /* Enable/Re-enable PSR on the host */
-  intel_psr_enable_source(intel_dp);
-
+  /* Enable/Re-enable PSR on the host

Re: [Intel-gfx] [PATCH 12/15] drm/i915: VLV/CHV PSR Software timer mode

[R, Durgadoss]

-Original Message-
From: Vivi, Rodrigo
Sent: Friday, November 14, 2014 10:23 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo; R, Durgadoss
Subject: [PATCH 12/15] drm/i915: VLV/CHV PSR Software timer mode

This patch introduces exit/activate functions for PSR
on VLV+. Since on VLV+ HW cannot track frame updates and force PSR
exit let's use fully SW tracking available.

v2: Rebase over intel_psr.c;
Remove Single Frame update transitioning from state 3 to 5 directly;
Fake a software invalidation for sprites and cursor so we don't miss
any screen update;

Cc: Durgadoss R durgados...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/intel_psr.c | 96 ++--
 1 file changed, 83 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c 
b/drivers/gpu/drm/i915/intel_psr.c
index bdb28f2..b2a4ee7 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -214,6 +214,23 @@ static void vlv_psr_enable_source(struct intel_dp 
*intel_dp)
  VLV_EDP_PSR_ENABLE);
 }

+static void vlv_psr_activate(struct intel_dp *intel_dp)
+{
+  struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+  struct drm_device *dev = dig_port-base.base.dev;
+  struct drm_i915_private *dev_priv = dev-dev_private;
+  struct drm_crtc *crtc = dig_port-base.base.crtc;
+  enum pipe pipe = to_intel_crtc(crtc)-pipe;
+
+  /* Let's do the transition from PSR_state 1 to PSR_state 2
+   * that is PSR transition to active - static frame transmission.
+   * Then Hardware is responsible for the transition to PSR_state 3
+   * that is PSR active - no Remote Frame Buffer (RFB) update.
+   */
+  I915_WRITE(VLV_PSRCTL(pipe), I915_READ(VLV_PSRCTL(pipe)) |
+ VLV_EDP_PSR_ACTIVE_ENTRY);
+}
+
 static void hsw_psr_enable_source(struct intel_dp *intel_dp)
 {
   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
@@ -304,12 +321,16 @@ static void intel_psr_activate(struct intel_dp *intel_dp)
   WARN_ON(dev_priv-psr.active);
   lockdep_assert_held(dev_priv-psr.lock);

-  /* Enable/Re-enable PSR on the host
-   * On HSW+ after we enable PSR on source it will activate it
-   * as soon as it match configure idle_frame count. So
-   * we just actually enable it here on activation time.
-   */
-  hsw_psr_enable_source(intel_dp);
+  /* Enable/Re-enable PSR on the host */
+  if (HAS_DDI(dev))
+  /* On HSW+ after we enable PSR on source it will activate it
+   * as soon as it match configure idle_frame count. So
+   * we just actually enable it here on activation time.
+   */
+  hsw_psr_enable_source(intel_dp);
+  else
+  vlv_psr_activate(intel_dp);
+
   dev_priv-psr.active = true;
 }

@@ -457,18 +478,27 @@ static void intel_psr_work(struct work_struct *work)
   struct drm_i915_private *dev_priv =
   container_of(work, typeof(*dev_priv), psr.work.work);
   struct intel_dp *intel_dp = dev_priv-psr.enabled;
+  struct drm_crtc *crtc = dp_to_dig_port(intel_dp)-base.base.crtc;
+  enum pipe pipe = to_intel_crtc(crtc)-pipe;

   /* We have to make sure PSR is ready for re-enable
* otherwise it keeps disabled until next full enable/disable cycle.
* PSR might take some time to get fully disabled
* and be ready for re-enable.
*/
-  if (wait_for((I915_READ(EDP_PSR_STATUS_CTL(dev_priv-dev)) 
-EDP_PSR_STATUS_STATE_MASK) == 0, 50)) {
-  DRM_ERROR(Timed out waiting for PSR Idle for re-enable\n);
-  return;
+  if (HAS_DDI(dev_priv-dev)) {
+  if (wait_for((I915_READ(EDP_PSR_STATUS_CTL(dev_priv-dev)) 
+EDP_PSR_STATUS_STATE_MASK) == 0, 50)) {
+  DRM_ERROR(Timed out waiting for PSR Idle for 
re-enable\n);
+  return;
+  }
+  } else {
+  if (wait_for((I915_READ(VLV_PSRSTAT(pipe)) 
+VLV_EDP_PSR_IN_TRANS) == 0, 0.250)) {

I didn't know wait_for takes floats ;)

+  DRM_ERROR(Timed out waiting for PSR Idle for 
re-enable\n);
+  return;
+  }
   }
-
   mutex_lock(dev_priv-psr.lock);
   intel_dp = dev_priv-psr.enabled;

@@ -491,17 +521,47 @@ unlock:
 static void intel_psr_exit(struct drm_device *dev)
 {
   struct drm_i915_private *dev_priv = dev-dev_private;
+  struct intel_dp *intel_dp = dev_priv-psr.enabled;
+  struct drm_crtc *crtc = dp_to_dig_port(intel_dp)-base.base.crtc;
+  enum pipe pipe = to_intel_crtc(crtc)-pipe;
+  u32 val;

-  if (dev_priv-psr.active) {
-  u32 val = I915_READ(EDP_PSR_CTL(dev));
+  if (!dev_priv-psr.active)
+  return;
+
+  if (HAS_DDI(dev

Re: [Intel-gfx] [PATCH 13/15] drm/i915: VLV/CHV PSR: Increase wait delay time before active PSR.

[R, Durgadoss]

-Original Message-
From: Vivi, Rodrigo
Sent: Friday, November 14, 2014 10:23 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo; R, Durgadoss
Subject: [PATCH 13/15] drm/i915: VLV/CHV PSR: Increase wait delay time before 
active PSR.

Since active function on VLV immediately activate PSR let's give more
time for idleness.

v2: Rebase over intel_psr.c and fix typo.

Cc: Durgadoss R durgados...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/intel_psr.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c 
b/drivers/gpu/drm/i915/intel_psr.c
index b2a4ee7..fe7b0f6 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -618,6 +618,11 @@ void intel_psr_flush(struct drm_device *dev,
   struct drm_i915_private *dev_priv = dev-dev_private;
   struct drm_crtc *crtc;
   enum pipe pipe;
+  /* On HSW/BDW Hardware controls idle_frames to go to PSR entry state
+   * However on VLV we go to PSR active state with psr work. So let's

s/psr/PSR

Reviewed-by: Durgadoss R durgados...@intel.com

Thanks,
Durga

+   * wait more time and let the user experience smooth enough.
+   */
+  int delay = msecs_to_jiffies(HAS_DDI(dev) ? 100 : 5000);

   mutex_lock(dev_priv-psr.lock);
   if (!dev_priv-psr.enabled) {
@@ -651,7 +656,7 @@ void intel_psr_flush(struct drm_device *dev,

   if (!dev_priv-psr.active  !dev_priv-psr.busy_frontbuffer_bits)
   schedule_delayed_work(dev_priv-psr.work,
-msecs_to_jiffies(100));
+msecs_to_jiffies(delay));
   mutex_unlock(dev_priv-psr.lock);
 }

--
1.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 14/15] drm/i915: VLV/CHV PSR debugfs.

[R, Durgadoss]

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Rodrigo Vivi
Sent: Friday, November 14, 2014 10:23 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 14/15] drm/i915: VLV/CHV PSR debugfs.

Add debugfs support for Valleyview and Cherryview considering that
we have PSR per pipe and  we don't have any kind of
performance counter as we have on other platforms that support PSR.

Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/i915_debugfs.c | 34 +-
 1 file changed, 29 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 319da61..d9b27f8 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2126,6 +2126,8 @@ static int i915_edp_psr_status(struct seq_file *m, void 
*data)
   struct drm_device *dev = node-minor-dev;
   struct drm_i915_private *dev_priv = dev-dev_private;
   u32 psrperf = 0;
+  u32 stat[3];
+  enum pipe pipe;
   bool enabled = false;

   intel_runtime_pm_get(dev_priv);
@@ -2140,14 +2142,36 @@ static int i915_edp_psr_status(struct seq_file *m, 
void *data)
   seq_printf(m, Re-enable work scheduled: %s\n,
  yesno(work_busy(dev_priv-psr.work.work)));

-  enabled = HAS_PSR(dev) 
-  I915_READ(EDP_PSR_CTL(dev))  EDP_PSR_ENABLE;
-  seq_printf(m, HW Enabled  Active bit: %s\n, yesno(enabled));
+  if (HAS_PSR(dev)) {
+  if (HAS_DDI(dev))
+  enabled = I915_READ(EDP_PSR_CTL(dev))  EDP_PSR_ENABLE;
+  else {
+  for_each_pipe(dev_priv, pipe) {
+  stat[pipe] = I915_READ(VLV_PSRSTAT(pipe)) 
+  VLV_EDP_PSR_CURR_STATE_MASK;
+  if ((stat[pipe] == VLV_EDP_PSR_ACTIVE_NORFB_UP) 
||
+  (stat[pipe] == 
VLV_EDP_PSR_ACTIVE_SF_UPDATE))
+  enabled = true;
+  }
+  }
+  }

Reviewed-by: Durgadoss R durgados...@intel.com

Thanks,
Durga

+  seq_printf(m, HW Enabled  Active bit: %s, yesno(enabled));

-  if (HAS_PSR(dev))
+  if (!HAS_DDI(dev))
+  for_each_pipe(dev_priv, pipe) {
+  if ((stat[pipe] == VLV_EDP_PSR_ACTIVE_NORFB_UP) ||
+  (stat[pipe] == VLV_EDP_PSR_ACTIVE_SF_UPDATE))
+  seq_printf(m,  pipe %c, pipe_name(pipe));
+  }
+  seq_puts(m, \n);
+
+  /* CHV PSR has no kind of performance counter */
+  if (HAS_PSR(dev)  HAS_DDI(dev)) {
   psrperf = I915_READ(EDP_PSR_PERF_CNT(dev)) 
   EDP_PSR_PERF_CNT_MASK;
-  seq_printf(m, Performance_Counter: %u\n, psrperf);
+
+  seq_printf(m, Performance_Counter: %u\n, psrperf);
+  }
   mutex_unlock(dev_priv-psr.lock);

   intel_runtime_pm_put(dev_priv);
--
1.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/10] drm/i915: Add PSR registers for PSR VLV/CHV.

[R, Durgadoss]

Hi Rodrigo,

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Rodrigo Vivi
Sent: Wednesday, October 29, 2014 12:16 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 01/10] drm/i915: Add PSR registers for PSR VLV/CHV.

Baytrail (Valleyview) and Braswell (Cherryview) uses a complete different
implementation of PSR that we currently have supported for
Haswell and Broadwell. So let's start by adding registers definitions.

I usually don't like commit that adds just registers without using,
but after I put all in one commit I realized that no one would want
to take the AR to review it so I decided to split in order to make
reviewer's life easier. Only last commit in this series will actually
enable the PSR on intel enable panel path.

But as it happens currently with HSW/BDW the plan is to let it
disabled by default (protected by kernel parameter)
while we are able to fully validate it.

Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/i915_reg.h | 37
+
 1 file changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 77fce96..771780a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2509,6 +2509,43 @@ enum punit_power_well {
 #define PIPESRC(trans) _TRANSCODER2(trans, _PIPEASRC)
 #define PIPE_MULT(trans) _TRANSCODER2(trans, _PIPE_MULT_A)

+/* VLV eDP PSR registers */
+#define _PSRCTLA  (VLV_DISPLAY_BASE + 0x60090)
+#define _PSRCTLB  (VLV_DISPLAY_BASE + 0x61090)
+#define  VLV_EDP_PSR_ENABLE   (10)
+#define  VLV_EDP_PSR_RESET(11)
+#define  VLV_EDP_PSR_MODE_MASK(72)
+#define  VLV_EDP_PSR_MODE_HW_TIMER(13)
+#define  VLV_EDP_PSR_MODE_SW_TIMER(12)
+#define  VLV_EDP_PSR_SINGLE_FRAME_UPDATE  (17)
+#define  VLV_EDP_PSR_ACTIVE_ENTRY (18)
+#define  VLV_EDP_PSR_SRC_TRANSMITTER_STATE(19)
+#define  VLV_EDP_PSR_DBL_FRAME(110)
+#define  VLV_EDP_PSR_FRAME_COUNT_MASK (0xff16)
+#define  VLV_EDP_PSR_IDLE_FRAME_SHIFT 16
+#define  VLV_EDP_PSR_INT_TRANSITION   (124)

Bit 24 is Reserved for CHV.
The PSR interrupt bits for CHV are moved to pipe control registers.

[Looks like we do not use this bit anywhere in our code]

+#define VLV_PSRCTL(pipe) _PIPE(pipe, _PSRCTLA, _PSRCTLB)
+
+#define _VSCSDPA  (VLV_DISPLAY_BASE + 0x600a0)
+#define _VSCSDPB  (VLV_DISPLAY_BASE + 0x610a0)
+#define  VLV_EDP_PSR_SDP_FREQ_MASK(330)
+#define  VLV_EDP_PSR_SDP_FREQ_ONCE(131)
+#define  VLV_EDP_PSR_SDP_FREQ_EVFRAME (130)
+#define VLV_VSCSDP(pipe)  _PIPE(pipe, _VSCSDPA, _VSCSDPB)
+
+#define _PSRSTATA (VLV_DISPLAY_BASE + 0x60094)
+#define _PSRSTATB (VLV_DISPLAY_BASE + 0x61094)
+#define  VLV_EDP_PSR_LAST_STATE_MASK  (73)
+#define  VLV_EDP_PSR_CURR_STATE_MASK  7
+#define  VLV_EDP_PSR_DISABLED (00)
+#define  VLV_EDP_PSR_INACTIVE (10)
+#define  VLV_EDP_PSR_IN_TRANS_TO_ACTIVE   (20)
+#define  VLV_EDP_PSR_ACTIVE_NORFB_UP  (30)
+#define  VLV_EDP_PSR_ACTIVE_SF_UPDATE (40)
+#define  VLV_EDP_PSR_EXIT (50)
+#define  VLV_EDP_PSR_IN_TRANS (17)
+#define VLV_PSRSTAT(pipe) _PIPE(pipe, _PSRSTATA, _PSRSTATB)
+
 /* HSW+ eDP PSR registers */
 #define EDP_PSR_BASE(dev)   (IS_HASWELL(dev) ? 0x64800 : 
 0x6f800)
 #define EDP_PSR_CTL(dev)  (EDP_PSR_BASE(dev) + 0)
--
1.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/10] drm/i915: VLV PSR: Status/enabled function.

[R, Durgadoss]

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Rodrigo Vivi
Sent: Wednesday, October 29, 2014 12:16 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 02/10] drm/i915: VLV PSR: Status/enabled function.

VLV PSR support PSR per pipe, including the status. So we have to check
if it is enabled per pipe on status.

Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 82e47da..774eb6c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2076,7 +2076,26 @@ static bool is_edp_psr(struct intel_dp *intel_dp)
   return intel_dp-psr_dpcd[0]  DP_PSR_IS_SUPPORTED;
 }

-static bool intel_edp_is_psr_enabled(struct drm_device *dev)
+/**
+ * vlv_edp_is_psr_enabled_on_pipe
+ * @dev: DRM device
+ * @pipe: pipe to check for PSR status.
+ *
+ * VLV PSR implements PSR per pipe. This function allows to check if it is
+ * enabled on given pipe.
+ */
+static bool vlv_edp_is_psr_enabled_on_pipe(struct drm_device *dev, int pipe)
+{
+  struct drm_i915_private *dev_priv = dev-dev_private;
+  uint32_t val;
+
+  val = I915_READ(VLV_PSRSTAT(pipe)) 
+  VLV_EDP_PSR_CURR_STATE_MASK;
+  return (val == VLV_EDP_PSR_ACTIVE_NORFB_UP) ||
+  (val == VLV_EDP_PSR_ACTIVE_SF_UPDATE);
+}

I feel *_is_psr_active() would be a better name for this function,
given that we check for State 3 or 4.

(and not just bit 0 in control register)

Thanks,
Durga

+
+static bool hsw_edp_is_psr_enabled(struct drm_device *dev)
 {
   struct drm_i915_private *dev_priv = dev-dev_private;

@@ -5066,7 +5085,7 @@ void intel_dp_set_drrs_state(struct drm_device *dev,
int refresh_rate)
* hard to tell without seeing the user of this function of this code.
* Check locking and ordering once that lands.
*/
-  if (INTEL_INFO(dev)-gen  8  intel_edp_is_psr_enabled(dev)) {
+  if (IS_HASWELL(dev)  hsw_edp_is_psr_enabled(dev)) {
   DRM_DEBUG_KMS(DRRS is disabled as PSR is enabled\n);
   return;
   }
--
1.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 04/10] drm/i915: PSR VLV/CHV: Introduce setup, enable and disable functions

[R, Durgadoss]

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Rodrigo Vivi
Sent: Wednesday, October 29, 2014 12:16 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 04/10] drm/i915: PSR VLV/CHV: Introduce setup,
enable and disable functions

The biggest difference from HSW/BDW PSR here is that VLV enable_source
function enables PSR but let it in Inactive state. So it might be called
on early stage along with setup and enable_sink ones.

Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c | 161

 1 file changed, 145 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ac70b3a..335a711 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2134,7 +2134,44 @@ static void intel_edp_psr_write_vsc(struct intel_dp
*intel_dp,
   POSTING_READ(ctl_reg);
 }

-static void intel_edp_psr_setup_vsc(struct intel_dp *intel_dp)
+/**
+ * vlv_edp_psr_setup_vsc - Setup PSR related VSC aux registers on VLV+.
+ * @intel_dp: DP struct
+ *
+ * On VLV we don't need to generate VSC. It auto generates according
+ * EDP 1.3 spec, Table 3.10.
+ * HB0   - Secondary Data Packet ID = 0
+ * HB1   - Secondary Data Packet Type = 07h
+ * HB2   - Bits 4:0 = Revision Number = 02h
+ * Bits 7:5 = Reserved (all 0s)
+ * HB3   - Bits 4:0 Number of Valid Data Bytes = 08h
+ * Bits 7:5 Reserved
+ * DB0   - Bits 7:4 Stereo Interface Method Specific Paramenter
+ * Bits 3:0 Stereo Interface Method Code
+ * DB1   - Bit 0 - PSR State (0 when Inactive / 1 when Active)
+ * Bit 1 - Update RFB. (0 do not update RFB / 1 update RFB)
+ * Bit 2 - CRC Valid. VLV always send 0 which
+ *means CRC value in DB7:2 invalid
+ * Bits 7:3 - Reserved
+ * DB2-7 - CRC - don't care because DB1[2] always tells this is invalid.
+ */
+static void vlv_edp_psr_setup_vsc(struct intel_dp *intel_dp)
+{
+  struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+  struct drm_device *dev = intel_dig_port-base.base.dev;
+  struct drm_i915_private *dev_priv = dev-dev_private;
+  struct drm_crtc *crtc = intel_dig_port-base.base.crtc;
+  enum pipe pipe = to_intel_crtc(crtc)-pipe;
+  uint32_t val;
+
+  /* VLV auto-generate VSC package as per EDP 1.3 spec, Table 3.10 */
+  val  = I915_READ(VLV_VSCSDP(pipe));
+  val = ~VLV_EDP_PSR_SDP_FREQ_MASK;
+  val |= VLV_EDP_PSR_SDP_FREQ_EVFRAME;
+  I915_WRITE(VLV_VSCSDP(pipe), val);
+}
+
+static void hsw_edp_psr_setup_vsc(struct intel_dp *intel_dp)
 {
   struct edp_vsc_psr psr_vsc;

@@ -2147,7 +2184,20 @@ static void intel_edp_psr_setup_vsc(struct intel_dp
*intel_dp)
   intel_edp_psr_write_vsc(intel_dp, psr_vsc);
 }

-static void intel_edp_psr_enable_sink(struct intel_dp *intel_dp)
+/**
+ * vlv_edp_psr_enable_sink - Enable PSR on Panel for VLV.
+ * @intel_dp: DP struct
+ *
+ * This function enable PSR on Panel (Sink) side over DPCD write.
+ */
+static void vlv_edp_psr_enable_sink(struct intel_dp *intel_dp)
+{
+  /* Enable PSR in sink */
+  drm_dp_dpcd_writeb(intel_dp-aux, DP_PSR_EN_CFG,
+ DP_PSR_ENABLE);
+}
+
+static void hsw_edp_psr_enable_sink(struct intel_dp *intel_dp)
 {
   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
   struct drm_device *dev = dig_port-base.base.dev;
@@ -2191,7 +2241,28 @@ static void intel_edp_psr_enable_sink(struct intel_dp
*intel_dp)
  (aux_clock_divider  DP_AUX_CH_CTL_BIT_CLOCK_2X_SHIFT));
 }

-static void intel_edp_psr_enable_source(struct intel_dp *intel_dp)
+/**
+ * vlv_edp_psr_enable_source - Enable PSR on VLV without activate it.
+ * @intel_dp: DP struct
+ *
+ * This function do the transition from PSR_state 0 to PSR_state 1 that is
+ * PSR Inactive one..
+ */
+static void vlv_edp_psr_enable_source(struct intel_dp *intel_dp)
+{
+  struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+  struct drm_device *dev = dig_port-base.base.dev;
+  struct drm_i915_private *dev_priv = dev-dev_private;
+  struct drm_crtc *crtc = dig_port-base.base.crtc;
+  enum pipe pipe = to_intel_crtc(crtc)-pipe;
+
+  I915_WRITE(VLV_PSRCTL(pipe),
+ VLV_EDP_PSR_SRC_TRANSMITTER_STATE |

I see we are keeping the source active during PSR.
Making this '0' may provide better power savings,
but we need to manage a lot of hassle during PSR exit..
(like Link training, DPIO/PLL bring up etc..)

+ VLV_EDP_PSR_MODE_SW_TIMER |
+ VLV_EDP_PSR_ENABLE);
+}
+
+static void hsw_edp_psr_enable_source(struct intel_dp *intel_dp)
 {
   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
   struct drm_device *dev = dig_port-base.base.dev;
@@ -2276,7 +2347,7 @@ static void intel_edp_psr_do_enable(struct intel_dp

Re: [Intel-gfx] [PATCH 07/10] drm/i915: VLV/CHV PSR: Increase wait delay time before active PSR.

[R, Durgadoss]

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Rodrigo Vivi
Sent: Wednesday, October 29, 2014 12:16 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 07/10] drm/i915: VLV/CHV PSR: Increase wait delay
time before active PSR.

Since active function on VLV immediately activate PSR let's give more
time for idleness.

Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 6829ecb..ded73ae 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2666,6 +2666,11 @@ void intel_edp_psr_flush(struct drm_device *dev,
   struct drm_i915_private *dev_priv = dev-dev_private;
   struct drm_crtc *crtc;
   enum pipe pipe;
+  /* On HSW/BDW Hardware controls idle_frames to go to PSR entry state
+  * However on VLV we go to PSR active state with psr work. So let's
+  * wait more time and let the user experience smoth enough.

s/smoth/smooth

otherwise looks fine..

+  */
+  int delay = msecs_to_jiffies(HAS_DDI(dev) ? 100 : 5000);

   mutex_lock(dev_priv-psr.lock);
   if (!dev_priv-psr.enabled) {
@@ -2688,8 +2693,7 @@ void intel_edp_psr_flush(struct drm_device *dev,
   intel_edp_psr_exit(dev);

   if (!dev_priv-psr.active  !dev_priv-psr.busy_frontbuffer_bits)
-  schedule_delayed_work(dev_priv-psr.work,
-msecs_to_jiffies(100));
+  schedule_delayed_work(dev_priv-psr.work, delay);
   mutex_unlock(dev_priv-psr.lock);
 }

--
1.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/10] drm/i915: VLV/CHV PSR Software timer mode control

[R, Durgadoss]

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Rodrigo Vivi
Sent: Wednesday, October 29, 2014 12:16 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 06/10] drm/i915: VLV/CHV PSR Software timer mode
control

This patch introduces exit/activate functions for PSR
on VLV+. Since on VLV+ HW cannot track frame updates and force PSR
exit let's use fully SW tracking available.

Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c | 94
+++--
 1 file changed, 81 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 813537a..6829ecb 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2271,6 +2271,27 @@ static void vlv_edp_psr_enable_source(struct intel_dp
*intel_dp)
 }

 /**
+ * vlv_edp_psr_activate - Activate PSR on VLV
+ * @intel_dp: DP struct
+ *
+ * This function do the transition from PSR_state 1 to PSR_state 2 that is
+ * PSR transition to active - static frame transmission.
+ * Then Hardware is responsible for the transition to PSR_state 3 that is
+ * PSR active - no Remote Frame Buffer (RFB) update.
+ */
+static void vlv_edp_psr_activate(struct intel_dp *intel_dp)
+{
+  struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+  struct drm_device *dev = dig_port-base.base.dev;
+  struct drm_i915_private *dev_priv = dev-dev_private;
+  struct drm_crtc *crtc = dig_port-base.base.crtc;
+  enum pipe pipe = to_intel_crtc(crtc)-pipe;
+
+  I915_WRITE(VLV_PSRCTL(pipe), I915_READ(VLV_PSRCTL(pipe)) |
+ VLV_EDP_PSR_ACTIVE_ENTRY);
+}
+
+/**
  * hsw_edp_psr_enable_source - Enable PSR on Source.
  * @intel_dp: DP struct
  *
@@ -2370,12 +2391,15 @@ static void intel_edp_psr_activate(struct intel_dp
*intel_dp)
   WARN_ON(dev_priv-psr.active);
   lockdep_assert_held(dev_priv-psr.lock);

-  /* Enable/Re-enable PSR on the host
-   * On HSW/BDW after we enable PSR on source it will activate it
-   * as soon as it match configure idle_frame count. So
-   * we just actually enable it here on activation time.
-   */
-  hsw_edp_psr_enable_source(intel_dp);
+  /* Enable/Re-enable PSR on the host */
+  if (HAS_DDI(dev))
+  /* On HSW/BDW after we enable PSR on source it will activate it
+   * as soon as it match configure idle_frame count. So
+   * we just actually enable it here on activation time.
+   */
+  hsw_edp_psr_enable_source(intel_dp);
+  else
+  vlv_edp_psr_activate(intel_dp);

   dev_priv-psr.active = true;
 }
@@ -2514,18 +2538,30 @@ static void intel_edp_psr_work(struct work_struct
*work)
   struct drm_i915_private *dev_priv =
   container_of(work, typeof(*dev_priv), psr.work.work);
   struct intel_dp *intel_dp = dev_priv-psr.enabled;
+  struct drm_crtc *crtc = dp_to_dig_port(
+  dev_priv-psr.enabled)-base.base.crtc;
+  enum pipe pipe = to_intel_crtc(crtc)-pipe;

   /* We have to make sure PSR is ready for re-enable
* otherwise it keeps disabled until next full enable/disable cycle.
* PSR might take some time to get fully disabled
* and be ready for re-enable.
*/
-  if (wait_for((I915_READ(EDP_PSR_STATUS_CTL(dev_priv-dev)) 
-EDP_PSR_STATUS_STATE_MASK) == 0, 50)) {
-  DRM_ERROR(Timed out waiting for PSR Idle for re-enable\n);
-  return;
+  if (HAS_DDI(dev_priv-dev)) {
+  if (wait_for((I915_READ(EDP_PSR_STATUS_CTL(dev_priv-dev)) 
+EDP_PSR_STATUS_STATE_MASK) == 0, 50)) {
+  DRM_ERROR(Timed out waiting for PSR Idle for re-
enable\n);
+  return;
+  }
+  } else {
+  if (wait_for((I915_READ(VLV_PSRSTAT(pipe)) 
+VLV_EDP_PSR_IN_TRANS) == 0, 250)) {
+  DRM_ERROR(Timed out waiting for PSR Idle for re-
enable\n);
+  return;
+  }
   }

+
   mutex_lock(dev_priv-psr.lock);
   intel_dp = dev_priv-psr.enabled;

@@ -2555,17 +2591,49 @@ unlock:
 static void intel_edp_psr_exit(struct drm_device *dev)
 {
   struct drm_i915_private *dev_priv = dev-dev_private;
+  struct intel_dp *intel_dp = dev_priv-psr.enabled;
+  struct drm_crtc *crtc = dp_to_dig_port(intel_dp)-base.base.crtc;
+  enum pipe pipe = to_intel_crtc(crtc)-pipe;
+  u32 val;

-  if (dev_priv-psr.active) {
-  u32 val = I915_READ(EDP_PSR_CTL(dev));
+  if (!dev_priv-psr.active)
+  return;
+
+  if (HAS_DDI(dev)) {
+  val = I915_READ(EDP_PSR_CTL(dev));

   WARN_ON(!(val  EDP_PSR_ENABLE));

   I915_WRITE(EDP_PSR_CTL(dev), val  ~EDP_PSR_ENABLE);
+  } 

Re: [Intel-gfx] [PATCH 08/10] drm/i915: VLV/CHV PSR debugfs.

[R, Durgadoss]

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Rodrigo Vivi
Sent: Wednesday, October 29, 2014 12:16 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 08/10] drm/i915: VLV/CHV PSR debugfs.

Add debugfs support for Valleyview and Cherryview considering that
we have PSR per pipe and  we don't have any kind of
performance counter as we have on other platforms that support PSR.

Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/i915_debugfs.c | 34 +-
 1 file changed, 29 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index a79f83c..3edc20f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2126,6 +2126,8 @@ static int i915_edp_psr_status(struct seq_file *m, void 
*data)
   struct drm_device *dev = node-minor-dev;
   struct drm_i915_private *dev_priv = dev-dev_private;
   u32 psrperf = 0;
+  u32 stat[3];
+  enum pipe pipe;
   bool enabled = false;

   intel_runtime_pm_get(dev_priv);
@@ -2140,14 +2142,36 @@ static int i915_edp_psr_status(struct seq_file *m, 
void *data)
   seq_printf(m, Re-enable work scheduled: %s\n,
  yesno(work_busy(dev_priv-psr.work.work)));

-  enabled = HAS_PSR(dev) 
-  I915_READ(EDP_PSR_CTL(dev))  EDP_PSR_ENABLE;
-  seq_printf(m, HW Enabled  Active bit: %s\n, yesno(enabled));
+  if (HAS_PSR(dev)) {
+  if (HAS_DDI(dev))
+  enabled = I915_READ(EDP_PSR_CTL(dev))  EDP_PSR_ENABLE;
+  else {
+  for_each_pipe(dev_priv, pipe) {
+  stat[pipe] = I915_READ(VLV_PSRSTAT(pipe)) 
+  VLV_EDP_PSR_CURR_STATE_MASK;
+  if ((stat[pipe] == VLV_EDP_PSR_ACTIVE_NORFB_UP) 
||
+  (stat[pipe] == 
VLV_EDP_PSR_ACTIVE_SF_UPDATE))

I think it is better to include 'state 2' (transition to active) also here.
We almost always go to state3 from state 2, before exiting (to state 5)
Unless it is an 'abort' case.

+  enabled = true;
+  }
+  }
+  }
+  seq_printf(m, HW Enabled  Active bit: %s, yesno(enabled));

-  if (HAS_PSR(dev))
+  if (!HAS_DDI(dev))
+  for_each_pipe(dev_priv, pipe) {
+  if ((stat[pipe] == VLV_EDP_PSR_ACTIVE_NORFB_UP) ||
+  (stat[pipe] == VLV_EDP_PSR_ACTIVE_SF_UPDATE))
+  seq_printf(m,  pipe %c, pipe_name(pipe));
+  }
+  seq_puts(m, \n);
+
+  /* CHV PSR has no kind of performance counter */
+  if (HAS_PSR(dev)  HAS_DDI(dev)) {
   psrperf = I915_READ(EDP_PSR_PERF_CNT(dev)) 
   EDP_PSR_PERF_CNT_MASK;
-  seq_printf(m, Performance_Counter: %u\n, psrperf);
+
+  seq_printf(m, Performance_Counter: %u\n, psrperf);
+  }
   mutex_unlock(dev_priv-psr.lock);

   intel_runtime_pm_put(dev_priv);
--
1.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 10/10] drm/i915: Enable PSR for Baytrail and Braswell.

[R, Durgadoss]

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Rodrigo Vivi
Sent: Wednesday, October 29, 2014 12:16 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 10/10] drm/i915: Enable PSR for Baytrail and 
Braswell.

This patch is the last in series of VLV/CHV PSR,
that finnaly enable psr by adding it to HAS_PSR
and calling the propper enable and disable

s/propper/proper

functions on the right places.

Although it is still disabled by default.

Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/i915_drv.h | 3 ++-
 drivers/gpu/drm/i915/intel_dp.c | 4 
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6a73803..119977b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2184,7 +2184,8 @@ struct drm_i915_cmd_table {

 #define HAS_DDI(dev)  (INTEL_INFO(dev)-has_ddi)
 #define HAS_FPGA_DBG_UNCLAIMED(dev)   (INTEL_INFO(dev)-has_fpga_dbg)
-#define HAS_PSR(dev)  (IS_HASWELL(dev) || IS_BROADWELL(dev))
+#define HAS_PSR(dev)  (IS_HASWELL(dev) || IS_BROADWELL(dev) || \
+   IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev))
 #define HAS_RUNTIME_PM(dev)   (IS_GEN6(dev) || IS_HASWELL(dev) || \
IS_BROADWELL(dev) || IS_VALLEYVIEW(dev))
 #define HAS_RC6(dev)  (INTEL_INFO(dev)-gen = 6)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b93eb40..3cddf49 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2718,6 +2718,9 @@ static void intel_disable_dp(struct intel_encoder 
*encoder)
   struct intel_dp *intel_dp = enc_to_intel_dp(encoder-base);
   struct drm_device *dev = encoder-base.dev;

+  if (HAS_PSR(dev)  !HAS_DDI(dev))

I think you really meant an '' here.. No ??
[although this may work]

Thanks,
Durga

+  intel_edp_psr_disable(intel_dp);
+
   /* Make sure the panel is off before trying to change the mode. But also
* ensure that we have vdd while we switch off the panel. */
   intel_edp_panel_vdd_on(intel_dp);
@@ -2935,6 +2938,7 @@ static void vlv_enable_dp(struct intel_encoder *encoder)
   struct intel_dp *intel_dp = enc_to_intel_dp(encoder-base);

   intel_edp_backlight_on(intel_dp);
+  intel_edp_psr_enable(intel_dp);
 }

 static void g4x_pre_enable_dp(struct intel_encoder *encoder)
--
1.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx