Re: [Intel-gfx] [RESEND-CI v4 11/15] drm/i915: prepare scaler for YCBCR420 modeset

[Ander Conselvan De Oliveira]

On Fri, 2017-06-30 at 17:29 +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 6/30/2017 5:04 PM, Ander Conselvan De Oliveira wrote:
> > On Fri, 2017-06-30 at 11:20 +0530, Sharma, Shashank wrote:
> > > Regards
> > > 
> > > Shashank
> > > 
> > > 
> > > On 6/27/2017 5:46 PM, Ander Conselvan De Oliveira wrote:
> > > > On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
> > > > > To get a YCBCR420 output from intel platforms, we need one
> > > > > scaler to scale down YCBCR444 samples to YCBCR420 samples.
> > > > > 
> > > > > This patch:
> > > > > - Does scaler allocation for HDMI ycbcr420 outputs.
> > > > > - Programs PIPE_MISC register for ycbcr420 output.
> > > > > - Adds a new scaler user "HDMI output" to plug-into existing
> > > > > scaler framework. This output type is identified using bit
> > > > > 30 of the scaler users bitmap.
> > > > > 
> > > > > V2: rebase
> > > > > V3: rebase
> > > > > V4: rebase
> > > > > 
> > > > > Cc: Ville Syrjala <ville.syrj...@linux.intel.com>
> > > > > Cc: Ander Conselvan De Oliveira 
> > > > > <ander.conselvan.de.olive...@intel.com>
> > > > > Signed-off-by: Shashank Sharma <shashank.sha...@intel.com>
> > > > > ---
> > > > >drivers/gpu/drm/i915/intel_atomic.c  |  6 ++
> > > > >drivers/gpu/drm/i915/intel_display.c | 26 
> > > > > ++
> > > > >drivers/gpu/drm/i915/intel_drv.h | 10 +-
> > > > >drivers/gpu/drm/i915/intel_hdmi.c| 10 ++
> > > > >drivers/gpu/drm/i915/intel_panel.c   |  3 ++-
> > > > >5 files changed, 53 insertions(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
> > > > > b/drivers/gpu/drm/i915/intel_atomic.c
> > > > > index 36d4e63..a8c9ac5 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_atomic.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_atomic.c
> > > > > @@ -264,6 +264,12 @@ int intel_atomic_setup_scalers(struct 
> > > > > drm_i915_private *dev_priv,
> > > > >
> > > > >   /* panel fitter case: assign as a crtc scaler */
> > > > >   scaler_id = _state->scaler_id;
> > > > > + } else if (i == SKL_HDMI_OUTPUT_INDEX) {
> > > > > + name = "HDMI-OUTPUT";
> > > > > + idx = intel_crtc->base.base.id;
> > > > > +
> > > > > + /* hdmi output case: needs a pipe scaler */
> > > > > + scaler_id = _state->scaler_id;
> > > > >   } else {
> > > > >   name = "PLANE";
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > > index da29536..983f581 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > > @@ -4626,6 +4626,11 @@ skl_update_scaler(struct intel_crtc_state 
> > > > > *crtc_state, bool force_detach,
> > > > >*/
> > > > >   need_scaling = src_w != dst_w || src_h != dst_h;
> > > > >
> > > > > + if (crtc_state->hdmi_output == DRM_HDMI_OUTPUT_YCBCR420
> > > > > + && scaler_user == SKL_HDMI_OUTPUT_INDEX)
> > > > 
> > > > Is it really necessary to check for both? If it is, what's the point of 
> > > > creating
> > > > SKL_HDMI_OUTPUT_INDEX?
> > > 
> > > Yes, else this will affect scaler update for planes, as this function
> > > gets called to update the plane scalers too, at that time the output
> > > will be still valid (as its at CRTC level), but the
> > > scaler user would be different.
> > 
> > Right, so there is a need to check for scaler_user == HDMI_OUTPUT. But then
> > wouldn't it be a bug if hdmi_output != YCBCR420 ?  Point is, if the caller 
> > asked
> > for a HDMI_OUTPUT scaler hopefully it knows what its doing, no need to 
> > second
> >

Re: [Intel-gfx] [RESEND-CI v4 15/15] drm/i915/glk: set HDMI 2.0 identifier

[Ander Conselvan De Oliveira]

On Fri, 2017-06-30 at 17:47 +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 6/30/2017 5:37 PM, Ander Conselvan De Oliveira wrote:
> > On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
> > > This patch sets the is_hdmi2_src identifier in drm connector
> > > for GLK platform. GLK contains a native HDMI 2.0 controller.
> > > This identifier will help the EDID handling functions to save
> > > lot of work which is specific to HDMI 2.0 sources.
> > > 
> > > V3: Added this patch
> > > V4: Rebase
> > > 
> > > Signed-off-by: Shashank Sharma <shashank.sha...@intel.com>
> > 
> > This and patches 12 and 14 look fine to me. I'm not sure about the patch 
> > split,
> > maybe they should be squashed together in the end? And perhaps patch 10 and 
> > 13
> > too if the refactor I proposed are separate prep patches.
> 
> In fact this is exactly how I prepared at the first place, keeping all 
> the crtc/pipe level changes together.
> But then I thought the patch might be touching too many things, and 
> might be too big or complex for
> review, that's why I had split into 3-4 small patches :-)
> >   But anyway, you can
> > use
> > 
> > Reviewed-by: Ander Conselvan de Oliveira <conselv...@gmail.com>
> > 
> > on those if you want.
> 
> Thanks, I guess this applies for 12,14,10,13 and 15 (with a separate 
> patch for CSC coeff handling).
> Please correct me if I misunderstood.

This applies to 12, 14 and 15.

Ander

> 
> - Shashank
> > 
> > 
> > > ---
> > >   drivers/gpu/drm/i915/intel_hdmi.c | 3 +++
> > >   1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> > > b/drivers/gpu/drm/i915/intel_hdmi.c
> > > index 3bd9af3..0d9d088 100644
> > > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > > @@ -1979,6 +1979,9 @@ void intel_hdmi_init_connector(struct 
> > > intel_digital_port *intel_dig_port,
> > >   connector->doublescan_allowed = 0;
> > >   connector->stereo_allowed = 1;
> > >   
> > > + if (IS_GEMINILAKE(dev_priv))
> > > + connector->ycbcr_420_allowed = true;
> > > +
> > >   intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port);
> > >   
> > >   switch (port) {
> 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RESEND-CI v4 15/15] drm/i915/glk: set HDMI 2.0 identifier

[Ander Conselvan De Oliveira]

On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
> This patch sets the is_hdmi2_src identifier in drm connector
> for GLK platform. GLK contains a native HDMI 2.0 controller.
> This identifier will help the EDID handling functions to save
> lot of work which is specific to HDMI 2.0 sources.
> 
> V3: Added this patch
> V4: Rebase
> 
> Signed-off-by: Shashank Sharma <shashank.sha...@intel.com>

This and patches 12 and 14 look fine to me. I'm not sure about the patch split,
maybe they should be squashed together in the end? And perhaps patch 10 and 13
too if the refactor I proposed are separate prep patches. But anyway, you can
use

Reviewed-by: Ander Conselvan de Oliveira <conselv...@gmail.com>

on those if you want.


> ---
>  drivers/gpu/drm/i915/intel_hdmi.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 3bd9af3..0d9d088 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1979,6 +1979,9 @@ void intel_hdmi_init_connector(struct 
> intel_digital_port *intel_dig_port,
>   connector->doublescan_allowed = 0;
>   connector->stereo_allowed = 1;
>  
> + if (IS_GEMINILAKE(dev_priv))
> + connector->ycbcr_420_allowed = true;
> +
>   intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port);
>  
>   switch (port) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RESEND-CI v4 11/15] drm/i915: prepare scaler for YCBCR420 modeset

[Ander Conselvan De Oliveira]

On Fri, 2017-06-30 at 11:20 +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 6/27/2017 5:46 PM, Ander Conselvan De Oliveira wrote:
> > On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
> > > To get a YCBCR420 output from intel platforms, we need one
> > > scaler to scale down YCBCR444 samples to YCBCR420 samples.
> > > 
> > > This patch:
> > > - Does scaler allocation for HDMI ycbcr420 outputs.
> > > - Programs PIPE_MISC register for ycbcr420 output.
> > > - Adds a new scaler user "HDMI output" to plug-into existing
> > >scaler framework. This output type is identified using bit
> > >30 of the scaler users bitmap.
> > > 
> > > V2: rebase
> > > V3: rebase
> > > V4: rebase
> > > 
> > > Cc: Ville Syrjala <ville.syrj...@linux.intel.com>
> > > Cc: Ander Conselvan De Oliveira <ander.conselvan.de.olive...@intel.com>
> > > Signed-off-by: Shashank Sharma <shashank.sha...@intel.com>
> > > ---
> > >   drivers/gpu/drm/i915/intel_atomic.c  |  6 ++
> > >   drivers/gpu/drm/i915/intel_display.c | 26 ++
> > >   drivers/gpu/drm/i915/intel_drv.h | 10 +-
> > >   drivers/gpu/drm/i915/intel_hdmi.c| 10 ++
> > >   drivers/gpu/drm/i915/intel_panel.c   |  3 ++-
> > >   5 files changed, 53 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
> > > b/drivers/gpu/drm/i915/intel_atomic.c
> > > index 36d4e63..a8c9ac5 100644
> > > --- a/drivers/gpu/drm/i915/intel_atomic.c
> > > +++ b/drivers/gpu/drm/i915/intel_atomic.c
> > > @@ -264,6 +264,12 @@ int intel_atomic_setup_scalers(struct 
> > > drm_i915_private *dev_priv,
> > >   
> > >   /* panel fitter case: assign as a crtc scaler */
> > >   scaler_id = _state->scaler_id;
> > > + } else if (i == SKL_HDMI_OUTPUT_INDEX) {
> > > + name = "HDMI-OUTPUT";
> > > + idx = intel_crtc->base.base.id;
> > > +
> > > + /* hdmi output case: needs a pipe scaler */
> > > + scaler_id = _state->scaler_id;
> > >   } else {
> > >   name = "PLANE";
> > >   
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index da29536..983f581 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -4626,6 +4626,11 @@ skl_update_scaler(struct intel_crtc_state 
> > > *crtc_state, bool force_detach,
> > >*/
> > >   need_scaling = src_w != dst_w || src_h != dst_h;
> > >   
> > > + if (crtc_state->hdmi_output == DRM_HDMI_OUTPUT_YCBCR420
> > > + && scaler_user == SKL_HDMI_OUTPUT_INDEX)
> > 
> > Is it really necessary to check for both? If it is, what's the point of 
> > creating
> > SKL_HDMI_OUTPUT_INDEX?
> 
> Yes, else this will affect scaler update for planes, as this function 
> gets called to update the plane scalers too, at that time the output 
> will be still valid (as its at CRTC level), but the
> scaler user would be different.

Right, so there is a need to check for scaler_user == HDMI_OUTPUT. But then
wouldn't it be a bug if hdmi_output != YCBCR420 ?  Point is, if the caller asked
for a HDMI_OUTPUT scaler hopefully it knows what its doing, no need to second
guess it.

> > 
> > > + /* YCBCR 444 -> 420 conversion needs a scaler */
> > > + need_scaling = true;
> > > +
> > >   /*
> > >* if plane is being disabled or scaler is no more required or 
> > > force detach
> > >*  - free scaler binded to this plane/crtc
> > > @@ -4673,6 +4678,26 @@ skl_update_scaler(struct intel_crtc_state 
> > > *crtc_state, bool force_detach,
> > >   }
> > >   
> > >   /**
> > > + * skl_update_scaler_hdmi_output - Stages update to scaler state for 
> > > HDMI.
> > > + * HDMI YCBCR 420 output needs a scaler, for downsampling.
> > > + *
> > > + * @state: crtc's scaler state
> > > + *
> > > + * Return
> > > + * 0 - scaler_usage updated successfully
> > > + *error - requested scaling cannot be supported or other error 
> > > condition
> > >

Re: [Intel-gfx] [RESEND-CI v4 13/15] drm/i915: prepare csc unit for YCBCR HDMI output

[Ander Conselvan De Oliveira]

On Fri, 2017-06-30 at 11:33 +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 6/29/2017 5:38 PM, Ander Conselvan De Oliveira wrote:
> > On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
> > > To support ycbcr HDMI output, we need a pipe CSC block to
> > > do the RGB->YCBCR conversion, as the blender output is in RGB.
> > > 
> > > Current Intel platforms have only one pipe CSC unit, so
> > > we can either do color correction using it, or we can perform
> > > RGB->YCBCR conversion.
> > > 
> > > This function adds a csc handler, to perform RGB->YCBCR conversion
> > > as per recommended spec values.
> > 
> > Please do a full reference to the "spec", including name, version and 
> > relevant
> > section.
> 
> Sure, will add more details.
> > > V2: Rebase
> > > V3: Rebase
> > > V4: Rebase
> > > 
> > > Cc: Ville Syrjala <ville.syrj...@linux.intel.com>
> > > Cc: Daniel Vetter <daniel.vet...@intel.com>
> > > Cc: Ander Conselvan De Oliveira <ander.conselvan.de.olive...@intel.com>
> > > Signed-off-by: Shashank Sharma <shashank.sha...@intel.com>
> > > ---
> > >   drivers/gpu/drm/i915/intel_color.c   | 47 
> > > +++-
> > >   drivers/gpu/drm/i915/intel_display.c | 32 
> > >   2 files changed, 78 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_color.c 
> > > b/drivers/gpu/drm/i915/intel_color.c
> > > index 306c6b0..12d5f21 100644
> > > --- a/drivers/gpu/drm/i915/intel_color.c
> > > +++ b/drivers/gpu/drm/i915/intel_color.c
> > > @@ -41,6 +41,19 @@
> > >   
> > >   #define LEGACY_LUT_LENGTH   (sizeof(struct drm_color_lut) * 
> > > 256)
> > >   
> > > +/* Post offset values for RGB->YCBCR conversion */
> > > +#define POSTOFF_RGB_TO_YUV_HI 0x800
> > > +#define POSTOFF_RGB_TO_YUV_ME 0x100
> > > +#define POSTOFF_RGB_TO_YUV_LO 0x800
> > > +
> > > +/* Direct spec values for RGB->YUV conversion matrix */
> > > +#define CSC_RGB_TO_YUV_RU_GU 0x2ba809d8
> > > +#define CSC_RGB_TO_YUV_BU 0x37e8
> > > +#define CSC_RGB_TO_YUV_RY_GY 0x1e089cc0
> > > +#define CSC_RGB_TO_YUV_BY 0xb528
> > > +#define CSC_RGB_TO_YUV_RV_GV 0xbce89ad8
> > > +#define CSC_RGB_TO_YUV_BV 0x1e08
> > > +
> > 
> > Not a big fan or hardcoding this in the register format. We already have the
> > code for converting a number to the right format for the register in
> > i915_load_csc_matrix(). I think it would make more sense to extract the code
> > that actually writes the matrix out of that function, so it would just
> > unconditionally use a matrix and coefficients passed as arguments. Then the
> > values above would be defined in the format expected for this new function.
> 
> Actually I had a small discussion on this with Ville, and we think that 
> the current CSC multiplication code is not correct.
> So if CTM and limited color range is applied together, we might not be 
> getting the right values. So not planning to
> reuse that code. I think while sending the BT2020 patches, we will add a 
> fix for that part too, but right now not working on it.

I wasn't talking about the matrix multiplication, but creating a function to
write any given matrix into the CSC. That way, the above could be hardcoded in a
more human readable format.

This issue is independent from fixing the matrix multiplication. I'm talking
specifically about the code below:

/*
 * Convert fixed point S31.32 input to format supported by the
 * hardware.
 */
for (i = 0; i < ARRAY_SIZE(coeffs); i++) {
uint64_t abs_coeff = ((1ULL << 63) - 1) & input[i];

/*
 * Clamp input value to min/max supported by
 * hardware.
 */
abs_coeff = clamp_val(abs_coeff, 0, CTM_COEFF_4_0 - 1);

/* sign bit */
if (CTM_COEFF_NEGATIVE(input[i]))
coeffs[i] |= 1 << 15;

if (abs_coeff < CTM_COEFF_0_125)
coeffs[i] |= (3 << 12) |
I9XX_CSC_COEFF_FP(abs_coeff, 12);
else if (abs_coeff < CTM_COEFF_0_25)
coeffs[i] |= (2 << 12) |

Re: [Intel-gfx] [RESEND-CI v4 13/15] drm/i915: prepare csc unit for YCBCR HDMI output

[Ander Conselvan De Oliveira]

On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
> To support ycbcr HDMI output, we need a pipe CSC block to
> do the RGB->YCBCR conversion, as the blender output is in RGB.
> 
> Current Intel platforms have only one pipe CSC unit, so
> we can either do color correction using it, or we can perform
> RGB->YCBCR conversion.
> 
> This function adds a csc handler, to perform RGB->YCBCR conversion
> as per recommended spec values.

Please do a full reference to the "spec", including name, version and relevant
section.

> 
> V2: Rebase
> V3: Rebase
> V4: Rebase
> 
> Cc: Ville Syrjala <ville.syrj...@linux.intel.com>
> Cc: Daniel Vetter <daniel.vet...@intel.com>
> Cc: Ander Conselvan De Oliveira <ander.conselvan.de.olive...@intel.com>
> Signed-off-by: Shashank Sharma <shashank.sha...@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_color.c   | 47 
> +++-
>  drivers/gpu/drm/i915/intel_display.c | 32 
>  2 files changed, 78 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_color.c 
> b/drivers/gpu/drm/i915/intel_color.c
> index 306c6b0..12d5f21 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -41,6 +41,19 @@
>  
>  #define LEGACY_LUT_LENGTH(sizeof(struct drm_color_lut) * 256)
>  
> +/* Post offset values for RGB->YCBCR conversion */
> +#define POSTOFF_RGB_TO_YUV_HI 0x800
> +#define POSTOFF_RGB_TO_YUV_ME 0x100
> +#define POSTOFF_RGB_TO_YUV_LO 0x800
> +
> +/* Direct spec values for RGB->YUV conversion matrix */
> +#define CSC_RGB_TO_YUV_RU_GU 0x2ba809d8
> +#define CSC_RGB_TO_YUV_BU 0x37e8
> +#define CSC_RGB_TO_YUV_RY_GY 0x1e089cc0
> +#define CSC_RGB_TO_YUV_BY 0xb528
> +#define CSC_RGB_TO_YUV_RV_GV 0xbce89ad8
> +#define CSC_RGB_TO_YUV_BV 0x1e08
> +

Not a big fan or hardcoding this in the register format. We already have the
code for converting a number to the right format for the register in
i915_load_csc_matrix(). I think it would make more sense to extract the code
that actually writes the matrix out of that function, so it would just
unconditionally use a matrix and coefficients passed as arguments. Then the
values above would be defined in the format expected for this new function.

>  /*
>   * Extract the CSC coefficient from a CTM coefficient (in U32.32 fixed point
>   * format). This macro takes the coefficient we want transformed and the
> @@ -91,6 +104,35 @@ static void ctm_mult_by_limited(uint64_t *result, int64_t 
> *input)
>   }
>  }
>  
> +void i9xx_load_ycbcr_conversion_matrix(struct intel_crtc *intel_crtc)
> +{
> + int pipe = intel_crtc->pipe;
> + struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
> +
> + /* We don't use high values for conversion */
> + I915_WRITE(PIPE_CSC_PREOFF_HI(pipe), 0);
> + I915_WRITE(PIPE_CSC_PREOFF_ME(pipe), 0);
> + I915_WRITE(PIPE_CSC_PREOFF_LO(pipe), 0);
> +
> + /* Program direct spec values for RGB to YCBCR conversion matrix */
> + I915_WRITE(PIPE_CSC_COEFF_RU_GU(pipe), CSC_RGB_TO_YUV_RU_GU);
> + I915_WRITE(PIPE_CSC_COEFF_BU(pipe), CSC_RGB_TO_YUV_BU);
> +
> + I915_WRITE(PIPE_CSC_COEFF_RY_GY(pipe), CSC_RGB_TO_YUV_RY_GY);
> + I915_WRITE(PIPE_CSC_COEFF_BY(pipe), CSC_RGB_TO_YUV_BY);
> +
> + I915_WRITE(PIPE_CSC_COEFF_RV_GV(pipe), CSC_RGB_TO_YUV_RV_GV);
> + I915_WRITE(PIPE_CSC_COEFF_BV(pipe), CSC_RGB_TO_YUV_BV);
> +
> + /* Spec postoffset values */
> + I915_WRITE(PIPE_CSC_POSTOFF_HI(pipe), POSTOFF_RGB_TO_YUV_HI);
> + I915_WRITE(PIPE_CSC_POSTOFF_ME(pipe), POSTOFF_RGB_TO_YUV_ME);
> + I915_WRITE(PIPE_CSC_POSTOFF_LO(pipe), POSTOFF_RGB_TO_YUV_LO);
> +
> + /* CSC mode before gamma */
> + I915_WRITE(PIPE_CSC_MODE(pipe), 0);
> +}
> +
>  /* Set up the pipe CSC unit. */
>  static void i9xx_load_csc_matrix(struct drm_crtc_state *crtc_state)
>  {
> @@ -101,7 +143,10 @@ static void i9xx_load_csc_matrix(struct drm_crtc_state 
> *crtc_state)
>   uint16_t coeffs[9] = { 0, };
>   struct intel_crtc_state *intel_crtc_state = 
> to_intel_crtc_state(crtc_state);
>  
> - if (crtc_state->ctm) {
> + if (intel_crtc_state->hdmi_output > DRM_HDMI_OUTPUT_DEFAULT_RGB) {
> + i9xx_load_ycbcr_conversion_matrix(intel_crtc);
> + return;
> + } else if (crtc_state->ctm) {

Hmm, I'm not sure this is the right place to check for this condition. I mean,
we shouldn't allow the modeset to happen in this case.

>   struct drm_color_ctm *ctm =
>   (struct drm_color_ctm *)crtc_state->ctm->d

Re: [Intel-gfx] [RESEND-CI v4 11/15] drm/i915: prepare scaler for YCBCR420 modeset

[Ander Conselvan De Oliveira]

On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
> To get a YCBCR420 output from intel platforms, we need one
> scaler to scale down YCBCR444 samples to YCBCR420 samples.
> 
> This patch:
> - Does scaler allocation for HDMI ycbcr420 outputs.
> - Programs PIPE_MISC register for ycbcr420 output.
> - Adds a new scaler user "HDMI output" to plug-into existing
>   scaler framework. This output type is identified using bit
>   30 of the scaler users bitmap.
> 
> V2: rebase
> V3: rebase
> V4: rebase
> 
> Cc: Ville Syrjala <ville.syrj...@linux.intel.com>
> Cc: Ander Conselvan De Oliveira <ander.conselvan.de.olive...@intel.com>
> Signed-off-by: Shashank Sharma <shashank.sha...@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_atomic.c  |  6 ++
>  drivers/gpu/drm/i915/intel_display.c | 26 ++
>  drivers/gpu/drm/i915/intel_drv.h | 10 +-
>  drivers/gpu/drm/i915/intel_hdmi.c| 10 ++
>  drivers/gpu/drm/i915/intel_panel.c   |  3 ++-
>  5 files changed, 53 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 36d4e63..a8c9ac5 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -264,6 +264,12 @@ int intel_atomic_setup_scalers(struct drm_i915_private 
> *dev_priv,
>  
>   /* panel fitter case: assign as a crtc scaler */
>   scaler_id = _state->scaler_id;
> + } else if (i == SKL_HDMI_OUTPUT_INDEX) {
> + name = "HDMI-OUTPUT";
> + idx = intel_crtc->base.base.id;
> +
> + /* hdmi output case: needs a pipe scaler */
> + scaler_id = _state->scaler_id;
>   } else {
>   name = "PLANE";
>  
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index da29536..983f581 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4626,6 +4626,11 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
> bool force_detach,
>*/
>   need_scaling = src_w != dst_w || src_h != dst_h;
>  
> + if (crtc_state->hdmi_output == DRM_HDMI_OUTPUT_YCBCR420
> + && scaler_user == SKL_HDMI_OUTPUT_INDEX)

Is it really necessary to check for both? If it is, what's the point of creating
SKL_HDMI_OUTPUT_INDEX?


> + /* YCBCR 444 -> 420 conversion needs a scaler */
> + need_scaling = true;
> +
>   /*
>* if plane is being disabled or scaler is no more required or force 
> detach
>*  - free scaler binded to this plane/crtc
> @@ -4673,6 +4678,26 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
> bool force_detach,
>  }
>  
>  /**
> + * skl_update_scaler_hdmi_output - Stages update to scaler state for HDMI.
> + * HDMI YCBCR 420 output needs a scaler, for downsampling.
> + *
> + * @state: crtc's scaler state
> + *
> + * Return
> + * 0 - scaler_usage updated successfully
> + *error - requested scaling cannot be supported or other error condition
> + */
> +int skl_update_scaler_crtc_hdmi_output(struct intel_crtc_state *state)
> +{
> + const struct drm_display_mode *mode = >base.adjusted_mode;
> +
> + return skl_update_scaler(state, !state->base.active,
> + SKL_HDMI_OUTPUT_INDEX, >scaler_state.scaler_id,
> + state->pipe_src_w, state->pipe_src_h,
> + mode->crtc_hdisplay, mode->crtc_vdisplay);
> +}
> +
> +/**
>   * skl_update_scaler_crtc - Stages update to scaler state for a given crtc.
>   *
>   * @state: crtc's scaler state
> @@ -8058,6 +8083,7 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
>  {
>   struct drm_i915_private *dev_priv = to_i915(crtc->dev);
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + enum drm_hdmi_output_type hdmi_out = intel_crtc->config->hdmi_output;
>  
>   if (IS_BROADWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 9) {
>   u32 val = 0;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 38fe56c..2206aa8 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -471,7 +471,8 @@ struct intel_crtc_scaler_state {
>*
>* If a bit is set, a user is using a scaler.
>* Here user can be a plane or crtc as defined below:
> -  *   bits 0-30 - plane (bit position is index from drm_plane_index)
> +

Re: [Intel-gfx] [PATCH v4 10/15] drm/i915: add compute-config for YCBCR outputs

[Ander Conselvan De Oliveira]

On Wed, 2017-06-21 at 21:19 +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 6/20/2017 7:50 PM, Ander Conselvan De Oliveira wrote:
> > On Mon, 2017-06-19 at 21:38 +0530, Shashank Sharma wrote:
> > > This patch checks encoder level support for HDMI YCBCR outputs.
> > > HDMI output mode is a connector property, this patch checks if
> > > source and sink can support the HDMI output type selected by user.
> > > And if they both can, it commits the hdmi output type into crtc state,
> > > for further staging in driver.
> > > 
> > > V2: Split the patch into two, kept helper functions in DRM layer.
> > > V3: Changed the compute_config function based on new DRM API.
> > > V4: Rebase
> > > 
> > > Cc: Ville Syrjala <ville.syrj...@linux.intel.com>
> > > Cc: Daniel Vetter <daniel.vet...@intel.com>
> > > Cc: Ander Conselvan De Oliveira <ander.conselvan.de.olive...@intel.com>
> > > Signed-off-by: Shashank Sharma <shashank.sha...@intel.com>
> > > ---
> > >   drivers/gpu/drm/i915/intel_display.c |  1 +
> > >   drivers/gpu/drm/i915/intel_drv.h |  3 ++
> > >   drivers/gpu/drm/i915/intel_hdmi.c| 93 
> > > ++--
> > >   3 files changed, 94 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index f9bf0d5..da29536 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -11930,6 +11930,7 @@ intel_pipe_config_compare(struct drm_i915_private 
> > > *dev_priv,
> > >   PIPE_CONF_CHECK_I(hdmi_scrambling);
> > >   PIPE_CONF_CHECK_I(hdmi_high_tmds_clock_ratio);
> > >   PIPE_CONF_CHECK_I(has_infoframe);
> > > + PIPE_CONF_CHECK_I(hdmi_output);
> > >   
> > >   PIPE_CONF_CHECK_I(has_audio);
> > >   
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index 1727350..38fe56c 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -780,6 +780,9 @@ struct intel_crtc_state {
> > >   
> > >   /* HDMI High TMDS char rate ratio */
> > >   bool hdmi_high_tmds_clock_ratio;
> > > +
> > > + /* HDMI output type */
> > > + enum drm_hdmi_output_type hdmi_output;
> > >   };
> > >   
> > >   struct intel_crtc {
> > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> > > b/drivers/gpu/drm/i915/intel_hdmi.c
> > > index 170abc4..22da5cd 100644
> > > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > > @@ -1317,7 +1317,8 @@ intel_hdmi_mode_valid(struct drm_connector 
> > > *connector,
> > >   return status;
> > >   }
> > >   
> > > -static bool hdmi_12bpc_possible(struct intel_crtc_state *crtc_state)
> > > +static bool hdmi_12bpc_possible(struct intel_crtc_state *crtc_state,
> > > + enum drm_hdmi_output_type hdmi_out)
> > >   {
> > >   struct drm_i915_private *dev_priv =
> > >   to_i915(crtc_state->base.crtc->dev);
> > > @@ -1329,6 +1330,16 @@ static bool hdmi_12bpc_possible(struct 
> > > intel_crtc_state *crtc_state)
> > >   if (HAS_GMCH_DISPLAY(dev_priv))
> > >   return false;
> > >   
> > > + if (hdmi_out == DRM_HDMI_OUTPUT_YCBCR422) {
> > > + /*
> > > +  * HDMI spec says YCBCR422 is 12bpc, but its not a deep
> > > +  * color format. So respect the spec, and not allow this
> > > +  * to be deep color
> > > +  */
> > > + DRM_DEBUG_KMS("Not allowing deep color for YCBCR422 output\n");
> > > + return false;
> > > + }
> > > +
> > 
> > I suppose this is about the remark in section 6.2.4 of the HDMI 1.4 spec. 
> > If I'm
> > interpreting that correctly, the relevant information for us is that the 
> > TMDS
> > clock doesn't need to be multiplied by 1.5, unlike other 12 bpc scenarios.
> > 
> > To me it seems misleading to say 12 bpc is not possible in that case. I'm
> > wondering if it makes more sense to split this in two parts:
> > 
> >   (i)  What is the TMDS clock scaling for a given output f

Re: [Intel-gfx] [PATCH v4 10/15] drm/i915: add compute-config for YCBCR outputs

[Ander Conselvan De Oliveira]

On Mon, 2017-06-19 at 21:38 +0530, Shashank Sharma wrote:
> This patch checks encoder level support for HDMI YCBCR outputs.
> HDMI output mode is a connector property, this patch checks if
> source and sink can support the HDMI output type selected by user.
> And if they both can, it commits the hdmi output type into crtc state,
> for further staging in driver.
> 
> V2: Split the patch into two, kept helper functions in DRM layer.
> V3: Changed the compute_config function based on new DRM API.
> V4: Rebase
> 
> Cc: Ville Syrjala <ville.syrj...@linux.intel.com>
> Cc: Daniel Vetter <daniel.vet...@intel.com>
> Cc: Ander Conselvan De Oliveira <ander.conselvan.de.olive...@intel.com>
> Signed-off-by: Shashank Sharma <shashank.sha...@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_display.c |  1 +
>  drivers/gpu/drm/i915/intel_drv.h |  3 ++
>  drivers/gpu/drm/i915/intel_hdmi.c| 93 
> ++--
>  3 files changed, 94 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index f9bf0d5..da29536 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11930,6 +11930,7 @@ intel_pipe_config_compare(struct drm_i915_private 
> *dev_priv,
>   PIPE_CONF_CHECK_I(hdmi_scrambling);
>   PIPE_CONF_CHECK_I(hdmi_high_tmds_clock_ratio);
>   PIPE_CONF_CHECK_I(has_infoframe);
> + PIPE_CONF_CHECK_I(hdmi_output);
>  
>   PIPE_CONF_CHECK_I(has_audio);
>  
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 1727350..38fe56c 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -780,6 +780,9 @@ struct intel_crtc_state {
>  
>   /* HDMI High TMDS char rate ratio */
>   bool hdmi_high_tmds_clock_ratio;
> +
> + /* HDMI output type */
> + enum drm_hdmi_output_type hdmi_output;
>  };
>  
>  struct intel_crtc {
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 170abc4..22da5cd 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1317,7 +1317,8 @@ intel_hdmi_mode_valid(struct drm_connector *connector,
>   return status;
>  }
>  
> -static bool hdmi_12bpc_possible(struct intel_crtc_state *crtc_state)
> +static bool hdmi_12bpc_possible(struct intel_crtc_state *crtc_state,
> + enum drm_hdmi_output_type hdmi_out)
>  {
>   struct drm_i915_private *dev_priv =
>   to_i915(crtc_state->base.crtc->dev);
> @@ -1329,6 +1330,16 @@ static bool hdmi_12bpc_possible(struct 
> intel_crtc_state *crtc_state)
>   if (HAS_GMCH_DISPLAY(dev_priv))
>   return false;
>  
> + if (hdmi_out == DRM_HDMI_OUTPUT_YCBCR422) {
> + /*
> +  * HDMI spec says YCBCR422 is 12bpc, but its not a deep
> +  * color format. So respect the spec, and not allow this
> +  * to be deep color
> +  */
> + DRM_DEBUG_KMS("Not allowing deep color for YCBCR422 output\n");
> + return false;
> + }
> +

I suppose this is about the remark in section 6.2.4 of the HDMI 1.4 spec. If I'm
interpreting that correctly, the relevant information for us is that the TMDS
clock doesn't need to be multiplied by 1.5, unlike other 12 bpc scenarios.

To me it seems misleading to say 12 bpc is not possible in that case. I'm
wondering if it makes more sense to split this in two parts:

 (i)  What is the TMDS clock scaling for a given output format?
 (ii) Is the format and scaled TMDS clock supported by the source and the sink?


>   /*
>* HDMI 12bpc affects the clocks, so it's only possible
>* when not cloning with other encoder types.
> @@ -1342,6 +1353,12 @@ static bool hdmi_12bpc_possible(struct 
> intel_crtc_state *crtc_state)
>   if (connector_state->crtc != crtc_state->base.crtc)
>   continue;
>  
> + if (hdmi_out == DRM_HDMI_OUTPUT_YCBCR420) {
> + if (!(info->hdmi.y420_dc_modes &
> + DRM_EDID_YCBCR420_DC_36))
> + return false;
> + }
> +
>   if ((info->edid_hdmi_dc_modes & DRM_EDID_HDMI_DC_36) == 0)
>   return false;
>   }
> @@ -1354,6 +1371,65 @@ static bool hdmi_12bpc_possible(struct 
> intel_crtc_state *crtc_state)
>   return true;
>  }
>  
> +static u8
> +intel_hdmi_get_src_output_support(struct drm_connector *connector)
> +{
> + 

Re: [Intel-gfx] [PATCH] Revert "drm/i915/skl: New ddb allocation algorithm"

[Ander Conselvan De Oliveira]

On Wed, 2017-06-14 at 14:16 -0700, Matt Roper wrote:
> On Wed, Jun 14, 2017 at 02:47:06PM +0300, Ander Conselvan De Oliveira wrote:
> > On Tue, 2017-06-13 at 12:06 -0700, Rodrigo Vivi wrote:
> > > On Tue, Jun 13, 2017 at 11:07 AM, Matt Roper <matthew.d.ro...@intel.com> 
> > > wrote:
> > > > On Tue, Jun 13, 2017 at 10:52:30AM -0700, Rodrigo Vivi wrote:
> > > > > This reverts commit bb9d85f6e9de8fef5236c076530eab67a2f2431b.
> > > > > 
> > > > > New ddb allocation algorithm is a show stopper on my SKL system.
> > > > > 
> > > > > Besides not be able to get external DP 4k@60 (through USB type C),
> > > > > It fully hang my screen when unplugging the USB type C.
> > > > > 
> > > > > Cc: Mahesh Kumar <mahesh1.ku...@intel.com>
> > > > > Cc: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> > > > > Cc: Matt Roper <matthew.d.ro...@intel.com>
> > > > > Signed-off-by: Rodrigo Vivi <rodrigo.v...@intel.com>
> > > > 
> > > > Is there a bugzilla entry with details/logs from the failure we can
> > > > refer to?
> > > 
> > > nope, since I know it was working few weeks ago and then stopped
> > > working I went directly
> > > to bisect so I could get my system usable quickly again.
> > > 
> > > But yes, I need to open a proper bugzilla and provide logs.
> > > Should we revert first and grab logs latter or we are going to try to
> > > analyse logs and fix?
> > > 
> > > Anyways this is a big show stopper so I believe we revert at least
> > > before next pull request.
> > 
> > This patch also causes artifacts in dual screen setups. All the scanlines 
> > below
> > the mouse cursor are wrong, sometimes containing a shade of gray and others
> > repeating the image above. I've seen this in APL and GLK using DSI+HDMI,
> > eDP+HDMI and DSI+DP. In the DP case, however, the screen goes blank and 
> > reports
> > lack of signal.
> > 
> > I've noticed fifo underrun messages. I compared the ddb allocation in GLK 
> > with a
> > working and non-working kernel, but they were the same.
> > 
> > Ander
> 
> Acknowledged-by: Matt Roper <matthew.d.ro...@intel.com>
> 
> for the revert, unless Mahesh or Maarten have an idea for an immediate
> fix that can be merged instead.
> 
> Let us know when you've had a chance to file a bugzilla with logs and
> such so that we can investigate in more detail.

I filed this one:

https://bugs.freedesktop.org/show_bug.cgi?id=101441

Ander

> 
> 
> Matt
> 
> > 
> > > 
> > > When you say you can't get DP 4k@60, are you seeing messages
> > > > in dmesg about the setup being outside system watermark limitations or
> > > > are you just getting a black screen?
> > > 
> > > just getting a blank screen on DP when plugging usb-c and a locked-up
> > > screen on eDP when removing usb-c.
> > > 
> > > > 
> > > > 
> > > > Matt
> > > > 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_pm.c | 257 
> > > > > +++-
> > > > >  1 file changed, 98 insertions(+), 159 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > > index aa9d8ce..dc4275d 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > > @@ -4140,41 +4140,13 @@ int skl_check_pipe_max_pixel_rate(struct 
> > > > > intel_crtc *intel_crtc,
> > > > >   minimum[PLANE_CURSOR] = skl_cursor_allocation(num_active);
> > > > >  }
> > > > > 
> > > > > -static void
> > > > > -skl_enable_plane_wm_levels(const struct drm_i915_private *dev_priv,
> > > > > -uint16_t plane_ddb,
> > > > > -uint16_t max_level,
> > > > > -struct skl_plane_wm *wm)
> > > > > -{
> > > > > - int level;
> > > > > - /*
> > > > > -  * Now enable all levels in WM structure which can be enabled
> > > > > -  * using current DDB allocation
> > > > > -  */
> > > > > - for (level = ilk_wm_max_level(dev_priv); level >= 0; leve

Re: [Intel-gfx] [PATCH] Revert "drm/i915/skl: New ddb allocation algorithm"

[Ander Conselvan De Oliveira]

On Thu, 2017-06-15 at 09:44 +0530, Mahesh Kumar wrote:
> Hi Ander,
> 
> 
> On Wednesday 14 June 2017 05:17 PM, Ander Conselvan De Oliveira wrote:
> > On Tue, 2017-06-13 at 12:06 -0700, Rodrigo Vivi wrote:
> > > On Tue, Jun 13, 2017 at 11:07 AM, Matt Roper <matthew.d.ro...@intel.com> 
> > > wrote:
> > > > On Tue, Jun 13, 2017 at 10:52:30AM -0700, Rodrigo Vivi wrote:
> > > > > This reverts commit bb9d85f6e9de8fef5236c076530eab67a2f2431b.
> > > > > 
> > > > > New ddb allocation algorithm is a show stopper on my SKL system.
> > > > > 
> > > > > Besides not be able to get external DP 4k@60 (through USB type C),
> > > > > It fully hang my screen when unplugging the USB type C.
> > > > > 
> > > > > Cc: Mahesh Kumar <mahesh1.ku...@intel.com>
> > > > > Cc: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> > > > > Cc: Matt Roper <matthew.d.ro...@intel.com>
> > > > > Signed-off-by: Rodrigo Vivi <rodrigo.v...@intel.com>
> > > > 
> > > > Is there a bugzilla entry with details/logs from the failure we can
> > > > refer to?
> > > 
> > > nope, since I know it was working few weeks ago and then stopped
> > > working I went directly
> > > to bisect so I could get my system usable quickly again.
> > > 
> > > But yes, I need to open a proper bugzilla and provide logs.
> > > Should we revert first and grab logs latter or we are going to try to
> > > analyse logs and fix?
> > > 
> > > Anyways this is a big show stopper so I believe we revert at least
> > > before next pull request.
> > 
> > This patch also causes artifacts in dual screen setups. All the scanlines 
> > below
> > the mouse cursor are wrong, sometimes containing a shade of gray and others
> > repeating the image above. I've seen this in APL and GLK using DSI+HDMI,
> > eDP+HDMI and DSI+DP. In the DP case, however, the screen goes blank and 
> > reports
> > lack of signal.
> > 
> > I've noticed fifo underrun messages. I compared the ddb allocation in GLK 
> > with a
> > working and non-working kernel, but they were the same.
> 
> your observation looks like one we observed in one of the Linux variant 
> program.
> There was an configuration where lower WM-level having higher DDB 
> requirement than higher levels. Which was leading to lower WM levels 
> getting disabled.
> 
> Can you please try with following patch to see if it's solving the problem.
> 
> https://patchwork.freedesktop.org/patch/161571/

I tested that in my GLK, but it didn't help. Still getting artifacts following
the mouse cursor.

Ander

> Rodrigo,
> 
> Can you please also check if this is the same reason for your failure. 
> I'm arranging for a system with SKL+USB type-C DP 4K@60 & eDP. will 
> debug this further.
> 
> -Mahesh
> 
> > 
> > Ander
> > > When you say you can't get DP 4k@60, are you seeing messages
> > > > in dmesg about the setup being outside system watermark limitations or
> > > > are you just getting a black screen?
> > > 
> > > just getting a blank screen on DP when plugging usb-c and a locked-up
> > > screen on eDP when removing usb-c.
> > > 
> > > > 
> > > > Matt
> > > > 
> > > > > ---
> > > > >   drivers/gpu/drm/i915/intel_pm.c | 257 
> > > > > +++-
> > > > >   1 file changed, 98 insertions(+), 159 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > > index aa9d8ce..dc4275d 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > > @@ -4140,41 +4140,13 @@ int skl_check_pipe_max_pixel_rate(struct 
> > > > > intel_crtc *intel_crtc,
> > > > >minimum[PLANE_CURSOR] = skl_cursor_allocation(num_active);
> > > > >   }
> > > > > 
> > > > > -static void
> > > > > -skl_enable_plane_wm_levels(const struct drm_i915_private *dev_priv,
> > > > > -uint16_t plane_ddb,
> > > > > -uint16_t max_level,
> > > > > -struct skl_plane_wm *wm)
> > > > > -{
> > > > > - int level;
> > > > >

Re: [Intel-gfx] [PATCH] Revert "drm/i915/skl: New ddb allocation algorithm"

[Ander Conselvan De Oliveira]

On Tue, 2017-06-13 at 12:06 -0700, Rodrigo Vivi wrote:
> On Tue, Jun 13, 2017 at 11:07 AM, Matt Roper  
> wrote:
> > On Tue, Jun 13, 2017 at 10:52:30AM -0700, Rodrigo Vivi wrote:
> > > This reverts commit bb9d85f6e9de8fef5236c076530eab67a2f2431b.
> > > 
> > > New ddb allocation algorithm is a show stopper on my SKL system.
> > > 
> > > Besides not be able to get external DP 4k@60 (through USB type C),
> > > It fully hang my screen when unplugging the USB type C.
> > > 
> > > Cc: Mahesh Kumar 
> > > Cc: Maarten Lankhorst 
> > > Cc: Matt Roper 
> > > Signed-off-by: Rodrigo Vivi 
> > 
> > Is there a bugzilla entry with details/logs from the failure we can
> > refer to?
> 
> nope, since I know it was working few weeks ago and then stopped
> working I went directly
> to bisect so I could get my system usable quickly again.
> 
> But yes, I need to open a proper bugzilla and provide logs.
> Should we revert first and grab logs latter or we are going to try to
> analyse logs and fix?
> 
> Anyways this is a big show stopper so I believe we revert at least
> before next pull request.

This patch also causes artifacts in dual screen setups. All the scanlines below
the mouse cursor are wrong, sometimes containing a shade of gray and others
repeating the image above. I've seen this in APL and GLK using DSI+HDMI,
eDP+HDMI and DSI+DP. In the DP case, however, the screen goes blank and reports
lack of signal.

I've noticed fifo underrun messages. I compared the ddb allocation in GLK with a
working and non-working kernel, but they were the same.

Ander

> 
> When you say you can't get DP 4k@60, are you seeing messages
> > in dmesg about the setup being outside system watermark limitations or
> > are you just getting a black screen?
> 
> just getting a blank screen on DP when plugging usb-c and a locked-up
> screen on eDP when removing usb-c.
> 
> > 
> > 
> > Matt
> > 
> > > ---
> > >  drivers/gpu/drm/i915/intel_pm.c | 257 
> > > +++-
> > >  1 file changed, 98 insertions(+), 159 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > > b/drivers/gpu/drm/i915/intel_pm.c
> > > index aa9d8ce..dc4275d 100644
> > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > @@ -4140,41 +4140,13 @@ int skl_check_pipe_max_pixel_rate(struct 
> > > intel_crtc *intel_crtc,
> > >   minimum[PLANE_CURSOR] = skl_cursor_allocation(num_active);
> > >  }
> > > 
> > > -static void
> > > -skl_enable_plane_wm_levels(const struct drm_i915_private *dev_priv,
> > > -uint16_t plane_ddb,
> > > -uint16_t max_level,
> > > -struct skl_plane_wm *wm)
> > > -{
> > > - int level;
> > > - /*
> > > -  * Now enable all levels in WM structure which can be enabled
> > > -  * using current DDB allocation
> > > -  */
> > > - for (level = ilk_wm_max_level(dev_priv); level >= 0; level--) {
> > > - struct skl_wm_level *level_wm = >wm[level];
> > > -
> > > - if (level > max_level || level_wm->plane_res_b == 0
> > > -   || level_wm->plane_res_l >= 31
> > > -   || level_wm->plane_res_b >= 
> > > plane_ddb) {
> > > - level_wm->plane_en = false;
> > > - level_wm->plane_res_b = 0;
> > > - level_wm->plane_res_l = 0;
> > > - } else {
> > > - level_wm->plane_en = true;
> > > - }
> > > - }
> > > -}
> > > -
> > >  static int
> > >  skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
> > > -   struct skl_pipe_wm *pipe_wm,
> > > struct skl_ddb_allocation *ddb /* out */)
> > >  {
> > >   struct drm_atomic_state *state = cstate->base.state;
> > >   struct drm_crtc *crtc = cstate->base.crtc;
> > >   struct drm_device *dev = crtc->dev;
> > > - struct drm_i915_private *dev_priv = to_i915(dev);
> > >   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > >   enum pipe pipe = intel_crtc->pipe;
> > >   struct skl_ddb_entry *alloc = >wm.skl.ddb;
> > > @@ -4187,9 +4159,6 @@ int skl_check_pipe_max_pixel_rate(struct intel_crtc 
> > > *intel_crtc,
> > >   unsigned plane_data_rate[I915_MAX_PLANES] = {};
> > >   unsigned plane_y_data_rate[I915_MAX_PLANES] = {};
> > >   uint16_t total_min_blocks = 0;
> > > - uint16_t total_level_ddb;
> > > - uint16_t plane_blocks = 0;
> > > - int max_level, level;
> > > 
> > >   /* Clear the partitioning for disabled planes. */
> > >   memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
> > > @@ -4228,48 +4197,10 @@ int skl_check_pipe_max_pixel_rate(struct 
> > > intel_crtc *intel_crtc,
> > >   return -EINVAL;
> > >   }
> > > 
> > 

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/glk: Remove the alpha_support flag

[Ander Conselvan De Oliveira]

On Fri, 2017-06-09 at 08:43 +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/glk: Remove the alpha_support flag
> URL   : https://patchwork.freedesktop.org/series/25471/
> State : failure
> 
> == Summary ==
> 
> Series 25471v1 drm/i915/glk: Remove the alpha_support flag
> https://patchwork.freedesktop.org/api/1.0/series/25471/revisions/1/mbox/
> 
> Test gem_exec_flush:
> Subgroup basic-uc-pro-default:
> pass   -> INCOMPLETE (fi-skl-6700hq)

This cannot be caused by this patch which only touches GLK. So pushed, thanks
for reviewing.

Ander

> Test gem_exec_suspend:
> Subgroup basic-s4-devices:
> dmesg-warn -> PASS   (fi-kbl-r) fdo#100125
> 
> fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125
> 
> fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
> time:443s
> fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
> time:435s
> fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
> time:584s
> fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
> time:511s
> fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
> time:483s
> fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
> time:474s
> fi-glk-2atotal:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
> time:586s
> fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time:433s
> fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time:420s
> fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
> time:419s
> fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:496s
> fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:466s
> fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:467s
> fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time:596s
> fi-kbl-r total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:573s
> fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time:465s
> fi-skl-6700hqtotal:53   pass:45   dwarn:0   dfail:0   fail:0   skip:7  
> fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
> time:462s
> fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time:501s
> fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
> time:439s
> fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
> time:533s
> fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
> time:398s
> 
> 5b363842b49a66879d4c67d652923fb04e44b271 drm-tip: 2017y-06m-08d-20h-34m-37s 
> UTC integration manifest
> df26255 drm/i915/glk: Remove the alpha_support flag
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4923/
> ___
> 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

[Intel-gfx] [PATCH] drm/i915/glk: Remove the alpha_support flag

[Ander Conselvan de Oliveira]

Geminilake is now included in CI, making it part of the pre-merge
criteria. The support should be in good enough shape, so let's remove
the alpha_support flag.

Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
---
 drivers/gpu/drm/i915/i915_pci.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 224f5f9..642b7c2 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -400,7 +400,6 @@ static const struct intel_device_info intel_broxton_info = {
 static const struct intel_device_info intel_geminilake_info = {
GEN9_LP_FEATURES,
.platform = INTEL_GEMINILAKE,
-   .is_alpha_support = 1,
.ddb_size = 1024,
.color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
 };
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915/glk: WA#0893: Also apply memory bw wa to Geminilake.

[Ander Conselvan De Oliveira]

On Fri, 2017-05-26 at 16:23 -0700, Rodrigo Vivi wrote:
> According to spec this WA is needed for every gen9.

Actually GLK has a gen10 display, so the gen9 workarounds don't apply.

Ander

> 
> Cc:Arthur Runyan <arthur.j.run...@intel.com>
> Cc: Ander Conselvan de Oliveira <ander.conselvan.de.olive...@intel.com>
> Signed-off-by: Rodrigo Vivi <rodrigo.v...@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 5abeb3f..7a5f2e4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2904,9 +2904,8 @@ static inline struct scatterlist *__sg_next(struct 
> scatterlist *sg)
>  #define NEEDS_WaRsDisableCoarsePowerGating(dev_priv) \
>   (IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
>  
> -/* WA#0893 */
> -#define NEEDS_WaIncreaseMemoryBW(dev_priv)   (IS_GEN9_BC(dev_priv) || \
> -  IS_BROXTON(dev_priv))
> +/* WA#0893: GEN9:ALL */
> +#define NEEDS_WaIncreaseMemoryBW(dev_priv)   (IS_GEN9(dev_priv))
>  
>  /*
>   * dp aux and gmbus irq on gen4 seems to be able to generate legacy 
> interrupts
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 55/67] drm/i915/gen10: implement gen 10 watermarks calculations

[Ander Conselvan De Oliveira]

On Thu, 2017-04-06 at 12:15 -0700, Rodrigo Vivi wrote:
> From: Paulo Zanoni 
> 
> They're slightly different than the gen 9 calculations.

I missed this at first, but GLK should follow the gen10 watermark programming as
it has a gen10 display.

> 
> TODO: before upstraming this, check if the spec is still the same.
> 
> Signed-off-by: Paulo Zanoni 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 27 ---
>  1 file changed, 20 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 0194d55..b07369a 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3692,8 +3692,9 @@ void skl_ddb_get_hw_state(struct drm_i915_private 
> *dev_priv,
>   * should allow pixel_rate up to ~2 GHz which seems sufficient since max
>   * 2xcdclk is 1350 MHz and the pixel rate should never exceed that.
>  */
> -static uint_fixed_16_16_t skl_wm_method1(uint32_t pixel_rate, uint8_t cpp,
> -  uint32_t latency)
> +static uint_fixed_16_16_t
> +skl_wm_method1(const struct drm_i915_private *dev_priv, uint32_t pixel_rate,
> +uint8_t cpp, uint32_t latency)
>  {
>   uint32_t wm_intermediate_val;
>   uint_fixed_16_16_t ret;
> @@ -3703,6 +3704,10 @@ static uint_fixed_16_16_t skl_wm_method1(uint32_t 
> pixel_rate, uint8_t cpp,
>  
>   wm_intermediate_val = latency * pixel_rate * cpp;
>   ret = fixed_16_16_div_round_up_u64(wm_intermediate_val, 1000 * 512);
> +
> + if (INTEL_GEN(dev_priv) >= 10)

|| IS_GLK

> + ret.val += 1 << 16;
> +
>   return ret;
>  }
>  
> @@ -3836,11 +3841,15 @@ static int skl_compute_plane_wm(const struct 
> drm_i915_private *dev_priv,
>  
>   plane_bytes_per_line = width * cpp;
>   if (y_tiled) {
> - interm_pbpl = DIV_ROUND_UP(plane_bytes_per_line *
> -y_min_scanlines, 512);
> + interm_pbpl = plane_bytes_per_line * y_min_scanlines;
> +
> + if (INTEL_GEN(dev_priv) >= 10)
> + interm_pbpl++;
> +
> + interm_pbpl = DIV_ROUND_UP(interm_pbpl, 512);

If I'm reading the spec right, the +1 should be done after the division by 512.

>   plane_blocks_per_line =
> fixed_16_16_div_round_up(interm_pbpl, y_min_scanlines);
> - } else if (x_tiled) {
> + } else if (x_tiled && INTEL_GEN(dev_priv) == 9) {

&& !IS_GLK

>   interm_pbpl = DIV_ROUND_UP(plane_bytes_per_line, 512);
>   plane_blocks_per_line = u32_to_fixed_16_16(interm_pbpl);
>   } else {
> @@ -3848,7 +3857,7 @@ static int skl_compute_plane_wm(const struct 
> drm_i915_private *dev_priv,
>   plane_blocks_per_line = u32_to_fixed_16_16(interm_pbpl);
>   }
>  
> - method1 = skl_wm_method1(plane_pixel_rate, cpp, latency);
> + method1 = skl_wm_method1(dev_priv, plane_pixel_rate, cpp, latency);
>   method2 = skl_wm_method2(plane_pixel_rate,
>cstate->base.adjusted_mode.crtc_htotal,
>latency,
> @@ -3865,7 +3874,11 @@ static int skl_compute_plane_wm(const struct 
> drm_i915_private *dev_priv,
>   selected_result = method2;
>   else if ((ddb_allocation /
>   fixed_16_16_to_u32_round_up(plane_blocks_per_line)) >= 
> 1)
> - selected_result = min_fixed_16_16(method1, method2);
> + if (INTEL_GEN(dev_priv) == 9)

&& !IS_GLK
> + selected_result = min_fixed_16_16(method1,
> +   method2);
> + else
> + selected_result = method2;
>   else
>   selected_result = method1;
>   }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Work around for underrun when enabling pipe scaler in GLK

[Ander Conselvan De Oliveira]

On Wed, 2017-05-24 at 13:57 +0530, Mahesh Kumar wrote:
> Hi,
> 
> 
> On Monday 08 May 2017 02:20 PM, Ander Conselvan de Oliveira wrote:
> > In Geminilake, a FIFO underrun happens the first time a pipe scaler is
> > enabled after boot/resume from suspend. Disabling DPF clock gating in
> > the respective CLKGATE_DIS_PSL register prior to enabling the scaler
> > works around the issue.
> 
> Is BSpec link or workaround number available for this?

This is not a documented workaround yet, still need input from hw engineers.

Ander


> 
> -Mahesh
> > Signed-off-by: Ander Conselvan de Oliveira 
> > <ander.conselvan.de.olive...@intel.com>
> > ---
> >   drivers/gpu/drm/i915/i915_reg.h  |  8 
> >   drivers/gpu/drm/i915/intel_display.c | 17 +
> >   2 files changed, 25 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 524fdfd..3157c39 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -3424,6 +3424,14 @@ enum {
> >   #define   PWM2_GATING_DIS (1 << 14)
> >   #define   PWM1_GATING_DIS (1 << 13)
> >   
> > +#define _CLKGATE_DIS_PSL_A 0x46520
> > +#define _CLKGATE_DIS_PSL_B 0x46524
> > +#define _CLKGATE_DIS_PSL_C 0x46528
> > +#define   DPF_GATING_DIS   (1 << 10)
> > +
> > +#define CLKGATE_DIS_PSL(pipe) \
> > +   _MMIO_PIPE(pipe, _CLKGATE_DIS_PSL_A, _CLKGATE_DIS_PSL_B)
> > +
> >   /*
> >* Display engine regs
> >*/
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 85b9e2f5..c24acdd 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -3176,6 +3176,7 @@ static void skl_detach_scaler(struct intel_crtc 
> > *intel_crtc, int id)
> >   static void skl_detach_scalers(struct intel_crtc *intel_crtc)
> >   {
> > struct intel_crtc_scaler_state *scaler_state;
> > +   struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
> > int i;
> >   
> > scaler_state = _crtc->config->scaler_state;
> > @@ -3185,6 +3186,14 @@ static void skl_detach_scalers(struct intel_crtc 
> > *intel_crtc)
> > if (!scaler_state->scalers[i].in_use)
> > skl_detach_scaler(intel_crtc, i);
> > }
> > +
> > +   if (IS_GEMINILAKE(dev_priv)) {
> > +   u32 tmp;
> > +
> > +   tmp = I915_READ(CLKGATE_DIS_PSL(intel_crtc->pipe));
> > +   tmp &= ~DPF_GATING_DIS;
> > +   I915_WRITE(CLKGATE_DIS_PSL(intel_crtc->pipe), tmp);
> > +   }
> >   }
> >   
> >   u32 skl_plane_stride(const struct drm_framebuffer *fb, int plane,
> > @@ -4763,6 +4772,14 @@ static void skylake_pfit_enable(struct intel_crtc 
> > *crtc)
> > if (WARN_ON(crtc->config->scaler_state.scaler_id < 0))
> > return;
> >   
> > +   if (IS_GEMINILAKE(dev_priv)) {
> > +   u32 tmp;
> > +
> > +   tmp = I915_READ(CLKGATE_DIS_PSL(crtc->pipe));
> > +   tmp |= DPF_GATING_DIS;
> > +   I915_WRITE(CLKGATE_DIS_PSL(crtc->pipe), tmp);
> > +   }
> > +
> > id = scaler_state->scaler_id;
> > I915_WRITE(SKL_PS_CTRL(pipe, id), PS_SCALER_EN |
> > PS_FILTER_MEDIUM | scaler_state->scalers[id].mode);
> 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/huc: Update GLK HuC version

[Ander Conselvan De Oliveira]

On Thu, 2017-05-18 at 18:06 +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/huc: Update GLK HuC version
> URL   : https://patchwork.freedesktop.org/series/24641/
> State : success

Pushed, thanks for the patch.

Ander

> 
> == Summary ==
> 
> Series 24641v1 drm/i915/huc: Update GLK HuC version
> https://patchwork.freedesktop.org/api/1.0/series/24641/revisions/1/mbox/
> 
> fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
> time:444s
> fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
> time:433s
> fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
> time:581s
> fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
> time:518s
> fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
> time:493s
> fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
> time:489s
> fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time:414s
> fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time:410s
> fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
> time:421s
> fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:490s
> fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:458s
> fi-kbl-7500u total:278  pass:255  dwarn:5   dfail:0   fail:0   skip:18  
> time:461s
> fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time:461s
> fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
> time:583s
> fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
> time:470s
> fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time:494s
> fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
> time:438s
> fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
> time:529s
> fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
> time:405s
> 
> ab08cb2750e769d074b2f147c8298ccd0cd08340 drm-tip: 2017y-05m-18d-15h-36m-17s 
> UTC integration manifest
> bd58365 drm/i915/huc: Update GLK HuC version
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4746/
> ___
> 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] drm/i915/huc: Update GLK HuC version

[Ander Conselvan De Oliveira]

On Thu, 2017-05-18 at 10:47 -0700, Anusha Srivatsa wrote:
> Update version of HuC from 01.07.1748 to the
> version 02.00.1748
> 
> Cc: Ander Conselvan <ander.conselvan.de.olive...@intel.com>
> Cc: John Spotswood <john.a.spotsw...@intel.com>
> Signed-off-by: Anusha Srivatsa <anusha.sriva...@intel.com>

Reviewed-by: Ander Conselvan de Oliveira <conselv...@gmail.com>

> ---
>  drivers/gpu/drm/i915/intel_huc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_huc.c 
> b/drivers/gpu/drm/i915/intel_huc.c
> index 88b4cf3..f5eb18d0e 100644
> --- a/drivers/gpu/drm/i915/intel_huc.c
> +++ b/drivers/gpu/drm/i915/intel_huc.c
> @@ -52,8 +52,8 @@
>  #define KBL_HUC_FW_MINOR 00
>  #define KBL_BLD_NUM 1810
>  
> -#define GLK_HUC_FW_MAJOR 01
> -#define GLK_HUC_FW_MINOR 07
> +#define GLK_HUC_FW_MAJOR 02
> +#define GLK_HUC_FW_MINOR 00
>  #define GLK_BLD_NUM 1748
>  
>  #define HUC_FW_PATH(platform, major, minor, bld_num) \
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 12/67] drm/i915/cnl: Introduce initial Cannonlake Workarounds.

[Ander Conselvan De Oliveira]

On Thu, 2017-04-06 at 12:15 -0700, Rodrigo Vivi wrote:
> Let's inherit workarounds from previous platforms that
> according to wa_database and BSpec are still valid for
> Cannonlake.
> 
> v2: Add missed workarounds.
> v3: Rebase
> 
> Cc: Mika Kuoppala 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.c|  4 ++--
>  drivers/gpu/drm/i915/i915_reg.h|  6 +
>  drivers/gpu/drm/i915/intel_engine_cs.c | 26 
>  drivers/gpu/drm/i915/intel_lrc.c   |  1 +
>  drivers/gpu/drm/i915/intel_pm.c| 44 
> +-
>  5 files changed, 73 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 8bab4ae..3c8457d 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -1881,12 +1881,12 @@ static void gtt_write_workarounds(struct 
> drm_i915_private *dev_priv)
>* called on driver load and after a GPU reset, so you can place
>* workarounds here even if they get overwritten by GPU reset.
>*/
> - /* WaIncreaseDefaultTLBEntries:chv,bdw,skl,bxt,kbl,glk */
> + /* WaIncreaseDefaultTLBEntries:chv,bdw,skl,bxt,kbl,glk,cnl */
>   if (IS_BROADWELL(dev_priv))
>   I915_WRITE(GEN8_L3_LRA_1_GPGPU, 
> GEN8_L3_LRA_1_GPGPU_DEFAULT_VALUE_BDW);
>   else if (IS_CHERRYVIEW(dev_priv))
>   I915_WRITE(GEN8_L3_LRA_1_GPGPU, 
> GEN8_L3_LRA_1_GPGPU_DEFAULT_VALUE_CHV);
> - else if (IS_GEN9_BC(dev_priv))
> + else if (IS_GEN9_BC(dev_priv) || IS_GEN10(dev_priv))
>   I915_WRITE(GEN8_L3_LRA_1_GPGPU, 
> GEN9_L3_LRA_1_GPGPU_DEFAULT_VALUE_SKL);
>   else if (IS_GEN9_LP(dev_priv))
>   I915_WRITE(GEN8_L3_LRA_1_GPGPU, 
> GEN9_L3_LRA_1_GPGPU_DEFAULT_VALUE_BXT);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index efbbeb8..a09a0d7 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3424,6 +3424,12 @@ enum {
>  #define   PWM1_GATING_DIS(1 << 13)
>  
>  /*
> + * GEN10 clock gating regs
> + */
> +#define SLICE_UNIT_LEVEL_CLKGATE _MMIO(0x94d4)
> +#define  SARBUNIT_CLKGATE_DIS(1 << 5)
> +
> +/*
>   * Display engine regs
>   */
>  
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 854e8e0..da819a7 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -946,6 +946,30 @@ static int bxt_init_workarounds(struct intel_engine_cs 
> *engine)
>   return 0;
>  }
>  
> +static int cnl_init_workarounds(struct intel_engine_cs *engine)
> +{
> + struct drm_i915_private *dev_priv = engine->i915;
> + int ret;
> +
> + /* WaInPlaceDecompressionHang:cnl */
> + WA_SET_BIT(GEN9_GAMT_ECO_REG_RW_IA,
> +GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
> +
> + /* WaEnablePreemptionGranularityControlByUMD:cnl */
> + ret= wa_ring_whitelist_reg(engine, GEN8_CS_CHICKEN1);
> + if (ret)
> + return ret;
> +
> + /* WaAllowUMDToModifyHDCChicken1:cnl (pre-prod) */
> + if (IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_A0)) {
> + ret = wa_ring_whitelist_reg(engine, GEN8_HDC_CHICKEN1);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
>  static int kbl_init_workarounds(struct intel_engine_cs *engine)
>  {
>   struct drm_i915_private *dev_priv = engine->i915;
> @@ -1032,6 +1056,8 @@ int init_workarounds_ring(struct intel_engine_cs 
> *engine)
>   err = kbl_init_workarounds(engine);
>   else if (IS_GEMINILAKE(dev_priv))
>   err =  glk_init_workarounds(engine);
> + else if (IS_CANNONLAKE(dev_priv))
> + err = cnl_init_workarounds(engine);
>   else
>   err = 0;
>   if (err)
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 0dc1cc4..23e2bed 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1093,6 +1093,7 @@ static int intel_init_workaround_bb(struct 
> intel_engine_cs *engine)
>   return -EINVAL;
>  
>   switch (INTEL_GEN(engine->i915)) {
> + case 10:
>   case 9:
>   wa_bb_fn[0] = gen9_init_indirectctx_bb;
>   wa_bb_fn[1] = gen9_init_perctx_bb;
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 55e1e88..b6ecab9 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -58,24 +58,24 @@
>  
>  static void gen9_init_clock_gating(struct drm_i915_private *dev_priv)
>  {
> - /* See Bspec note for PSR2_CTL bit 31, Wa#828:skl,bxt,kbl */
> + /* See Bspec note for PSR2_CTL bit 31, Wa#828:skl,bxt,kbl,cnl */
>   I915_WRITE(CHICKEN_PAR1_1,
>  

Re: [Intel-gfx] [PATCH 07/11] drm/i915/skl+: Fail the flip if ddb min requirement exceeds pipe allocation

[Ander Conselvan De Oliveira]

On Mon, 2017-05-08 at 17:18 +0530, Mahesh Kumar wrote:
> DDB minimum requirement may exceed the allocated DDB for CRTC/Pipe. This
> patch make changes to fail the flip if minimum requirement for pipe
> exceeds the total ddb allocated to the pipe.
> Previously it succeeded but making alloc_size a negative value. Which
> will make later calculations for plane ddb allocation bogus & may lead
> to screen corruption or system hang.

When sending a new version of a patch, please list the changes from the previous
version here. For example:

v2: Improve commit message.

v3: ...

> Signed-off-by: Mahesh Kumar <mahesh1.ku...@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 2a4e9d89cd6f..0ace94d67432 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3591,6 +3591,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
>   int num_active;
>   unsigned plane_data_rate[I915_MAX_PLANES] = {};
>   unsigned plane_y_data_rate[I915_MAX_PLANES] = {};
> + uint16_t total_min_blocks = 0;
>  
>   /* Clear the partitioning for disabled planes. */
>   memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
> @@ -3618,10 +3619,18 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
>*/
>  
>   for_each_plane_id_on_crtc(intel_crtc, plane_id) {
> - alloc_size -= minimum[plane_id];
> - alloc_size -= y_minimum[plane_id];
> + total_min_blocks += minimum[plane_id];
> + total_min_blocks += y_minimum[plane_id];
>   }
>  
> + if ((total_min_blocks > alloc_size)) {
> + DRM_DEBUG_KMS("Requested display configuration exceeds system 
> DDB limitations");
> + DRM_DEBUG_KMS("minimum required %d/%d\n", total_min_blocks,
> + alloc_size);
> +     return-EINVAL;
> + }

The comments I made earlier [1] are still valid. With those fixed and a
changelog in the commit message,

Reviewed-by: Ander Conselvan de Oliveira <conselv...@gmail.com>

[1] https://lists.freedesktop.org/archives/intel-gfx/2017-April/125764.html
> +
> + alloc_size -= total_min_blocks;
>   ddb->plane[pipe][PLANE_CURSOR].start = alloc->end - 
> minimum[PLANE_CURSOR];
>   ddb->plane[pipe][PLANE_CURSOR].end = alloc->end;
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Work around for underrun when enabling pipe scaler in GLK

[Ander Conselvan de Oliveira]

In Geminilake, a FIFO underrun happens the first time a pipe scaler is
enabled after boot/resume from suspend. Disabling DPF clock gating in
the respective CLKGATE_DIS_PSL register prior to enabling the scaler
works around the issue.

Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
---
 drivers/gpu/drm/i915/i915_reg.h  |  8 
 drivers/gpu/drm/i915/intel_display.c | 17 +
 2 files changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 524fdfd..3157c39 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3424,6 +3424,14 @@ enum {
 #define   PWM2_GATING_DIS  (1 << 14)
 #define   PWM1_GATING_DIS  (1 << 13)
 
+#define _CLKGATE_DIS_PSL_A 0x46520
+#define _CLKGATE_DIS_PSL_B 0x46524
+#define _CLKGATE_DIS_PSL_C 0x46528
+#define   DPF_GATING_DIS   (1 << 10)
+
+#define CLKGATE_DIS_PSL(pipe) \
+   _MMIO_PIPE(pipe, _CLKGATE_DIS_PSL_A, _CLKGATE_DIS_PSL_B)
+
 /*
  * Display engine regs
  */
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 85b9e2f5..c24acdd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3176,6 +3176,7 @@ static void skl_detach_scaler(struct intel_crtc 
*intel_crtc, int id)
 static void skl_detach_scalers(struct intel_crtc *intel_crtc)
 {
struct intel_crtc_scaler_state *scaler_state;
+   struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
int i;
 
scaler_state = _crtc->config->scaler_state;
@@ -3185,6 +3186,14 @@ static void skl_detach_scalers(struct intel_crtc 
*intel_crtc)
if (!scaler_state->scalers[i].in_use)
skl_detach_scaler(intel_crtc, i);
}
+
+   if (IS_GEMINILAKE(dev_priv)) {
+   u32 tmp;
+
+   tmp = I915_READ(CLKGATE_DIS_PSL(intel_crtc->pipe));
+   tmp &= ~DPF_GATING_DIS;
+   I915_WRITE(CLKGATE_DIS_PSL(intel_crtc->pipe), tmp);
+   }
 }
 
 u32 skl_plane_stride(const struct drm_framebuffer *fb, int plane,
@@ -4763,6 +4772,14 @@ static void skylake_pfit_enable(struct intel_crtc *crtc)
if (WARN_ON(crtc->config->scaler_state.scaler_id < 0))
return;
 
+   if (IS_GEMINILAKE(dev_priv)) {
+   u32 tmp;
+
+   tmp = I915_READ(CLKGATE_DIS_PSL(crtc->pipe));
+   tmp |= DPF_GATING_DIS;
+   I915_WRITE(CLKGATE_DIS_PSL(crtc->pipe), tmp);
+   }
+
id = scaler_state->scaler_id;
I915_WRITE(SKL_PS_CTRL(pipe, id), PS_SCALER_EN |
PS_FILTER_MEDIUM | scaler_state->scalers[id].mode);
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH 33/67] drm/i915: Configure DPLL's for Cannonlake

[Ander Conselvan De Oliveira]

On Thu, 2017-04-06 at 12:15 -0700, Rodrigo Vivi wrote:
> From: "Kahola, Mika" <mika.kah...@intel.com>
> 
> DPLL's are defined in DPCLKA_CFGCR0 register (0x6C200). Let's use these
> definitions when computing dpll's for ddi ports.
> 
> v2: (Rodrigo) Remove register that was defined in another patch with
> fixed name and more bits.
> 
> Signed-off-by: Kahola, Mika <mika.kah...@intel.com>
> Signed-off-by: Rodrigo Vivi <rodrigo.v...@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_display.c | 20 +++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 87d2822..4d0ae98 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8850,6 +8850,22 @@ static int haswell_crtc_compute_clock(struct 
> intel_crtc *crtc,
>   return 0;
>  }
>  
> +static void cannonlake_get_ddi_pll(struct drm_i915_private *dev_priv,
> +enum port port,
> +struct intel_crtc_state *pipe_config)
> +{
> + enum intel_dpll_id id;
> + u32 temp;
> +
> + temp = I915_READ(DPCLKA_CFGCR0) & DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port);
> + id = temp >> (port * 2);

Maybe use DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT which was defined in the previous
patch?

Also, might make sense to squash this with the next patch, but anyway,

Reviewed-by: Ander Conselvan de Oliveira <conselv...@gmail.com>


> +
> + if (WARN_ON(id < SKL_DPLL0 || id > SKL_DPLL2))
> + return;
> +
> + pipe_config->shared_dpll = intel_get_shared_dpll_by_id(dev_priv, id);
> +}
> +
>  static void bxt_get_ddi_pll(struct drm_i915_private *dev_priv,
>   enum port port,
>   struct intel_crtc_state *pipe_config)
> @@ -9037,7 +9053,9 @@ static void haswell_get_ddi_port_state(struct 
> intel_crtc *crtc,
>  
>   port = (tmp & TRANS_DDI_PORT_MASK) >> TRANS_DDI_PORT_SHIFT;
>  
> - if (IS_GEN9_BC(dev_priv))
> + if (IS_CANNONLAKE(dev_priv))
> + cannonlake_get_ddi_pll(dev_priv, port, pipe_config);
> + else if (IS_GEN9_BC(dev_priv))
>   skylake_get_ddi_pll(dev_priv, port, pipe_config);
>   else if (IS_GEN9_LP(dev_priv))
>   bxt_get_ddi_pll(dev_priv, port, pipe_config);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 32/67] drm/i915/cnl: DDI - PLL mapping

[Ander Conselvan De Oliveira]

On Thu, 2017-04-06 at 12:15 -0700, Rodrigo Vivi wrote:
> One of the steps for PLL (un)initialization is to (un)map
> the correspondent DDI that is actually using that PLL.
> 
> So, let's do this step following the places already stablished
> and used so far, although spec put this as part of PLL
> initialization sequences.
> 
> v2: Use proper prefix on bits names as suggested by Ander.
> v3: Add missed "~". Without that the logic was inverted
> so we were disabling interrupts.
> Credits-to: Clinton
> Credits-to: Art
> v4: Spec is getting updated to do DDI -> PLL mapping
> and clock on in 2 separated reg writes. (Paulo)
> Also update bits definitions to use space
> (1 << 1) instead of (1<<1). (Paulo)
> 
> Cc: Paulo Zanoni <paulo.r.zan...@intel.com>
> Cc: Art Runyan <arthur.j.run...@intel.com>
> Cc: Clint Taylor <clinton.a.tay...@intel.com>
> Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
> Cc: Kahola, Mika <mika.kah...@intel.com>
> Cc: Ander Conselvan De Oliveira <ander.conselvan.de.olive...@intel.com>
> Signed-off-by: Rodrigo Vivi <rodrigo.v...@intel.com>
> Reviewed-by: Kahola, Mika <mika.kah...@intel.com>
> Signed-off-by: Rodrigo Vivi <rodrigo.v...@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  9 +
>  drivers/gpu/drm/i915/intel_ddi.c | 23 ---
>  2 files changed, 29 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 3cfc65f..dcb8e21 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8150,6 +8150,15 @@ enum {
>  #define DPLL_CFGCR1(id)  _MMIO_PIPE((id) - SKL_DPLL1, _DPLL1_CFGCR1, 
> _DPLL2_CFGCR1)
>  #define DPLL_CFGCR2(id)  _MMIO_PIPE((id) - SKL_DPLL1, _DPLL1_CFGCR2, 
> _DPLL2_CFGCR2)
>  
> +/*
> + * CNL Clocks
> + */
> +#define DPCLKA_CFGCR0_MMIO(0x6C200)
> +#define  DPCLKA_CFGCR0_DDI_CLK_OFF(port) (1 << ((port)+10))
> +#define  DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port)(3 << ((port)*2))
> +#define  DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port)   ((port)*2)
> +#define  DPCLKA_CFGCR0_DDI_CLK_SEL(pll, port)((pll) << ((port)*2))
> +
>  /* BXT display engine PLL */
>  #define BXT_DE_PLL_CTL   _MMIO(0x6d000)
>  #define   BXT_DE_PLL_RATIO(x)(x) /* {60,65,100} * 
> 19.2MHz */
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 0914ad9..2a901bf 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1621,13 +1621,27 @@ static void intel_ddi_clk_select(struct intel_encoder 
> *encoder,
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   enum port port = intel_ddi_get_encoder_port(encoder);
> + uint32_t val;
>  
>   if (WARN_ON(!pll))
>   return;
>  
> - if (IS_GEN9_BC(dev_priv)) {
> - uint32_t val;
> + if (IS_CANNONLAKE(dev_priv)) {
> + /* Configure DPCLKA_CFGCR0 to map the DPLL to the DDI. */
> + val = I915_READ(DPCLKA_CFGCR0);
> + val |= DPCLKA_CFGCR0_DDI_CLK_SEL(pll->id, port);
> + I915_WRITE(DPCLKA_CFGCR0, val);
>  
> + /*
> +  * Configure DPCLKA_CFGCR0 to turn on the clock for the DDI.
> +  * This step and the step before must be done with separate
> +  * register writes.
> +  */
> + val = I915_READ(DPCLKA_CFGCR0);
> + val &= ~(DPCLKA_CFGCR0_DDI_CLK_OFF(port) |
> +  DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port));

val |= DPCLKA_CFGCR0_DDI_CLK_SEL(pll->id, port); ?

Or clearing the clock select to zero has no effect here?

Ander

> + I915_WRITE(DPCLKA_CFGCR0, val);
> + } else if (IS_GEN9_BC(dev_priv)) {
>   /* DDI -> PLL mapping  */
>   val = I915_READ(DPLL_CTRL2);
>  
> @@ -1763,7 +1777,10 @@ static void intel_ddi_post_disable(struct 
> intel_encoder *intel_encoder,
>   if (dig_port)
>   intel_display_power_put(dev_priv, 
> dig_port->ddi_io_power_domain);
>  
> - if (IS_GEN9_BC(dev_priv))
> + if (IS_CANNONLAKE(dev_priv))
> + I915_WRITE(DPCLKA_CFGCR0, I915_READ(DPCLKA_CFGCR0) |
> +DPCLKA_CFGCR0_DDI_CLK_OFF(port));
> + else if (IS_GEN9_BC(dev_priv))
>   I915_WRITE(DPLL_CTRL2, (I915_READ(DPLL_CTRL2) |
>   DPLL_CTRL2_DDI_CLK_OFF(port)));
>   else if (INTEL_GEN(dev_priv) < 9)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 32/67] drm/i915/cnl: DDI - PLL mapping

[Ander Conselvan De Oliveira]

On Fri, 2017-04-07 at 18:12 -0300, Paulo Zanoni wrote:
> Em Qui, 2017-04-06 às 12:15 -0700, Rodrigo Vivi escreveu:
> > One of the steps for PLL (un)initialization is to (un)map
> > the correspondent DDI that is actually using that PLL.
> > 
> > So, let's do this step following the places already stablished
> > and used so far, although spec put this as part of PLL
> > initialization sequences.
> > 
> > v2: Use proper prefix on bits names as suggested by Ander.
> > v3: Add missed "~". Without that the logic was inverted
> > so we were disabling interrupts.
> > Credits-to: Clinton
> > Credits-to: Art
> > v4: Spec is getting updated to do DDI -> PLL mapping
> > and clock on in 2 separated reg writes. (Paulo)
> > Also update bits definitions to use space
> > (1 << 1) instead of (1<<1). (Paulo)
> > 
> > Cc: Paulo Zanoni <paulo.r.zan...@intel.com>
> > Cc: Art Runyan <arthur.j.run...@intel.com>
> > Cc: Clint Taylor <clinton.a.tay...@intel.com>
> > Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
> > Cc: Kahola, Mika <mika.kah...@intel.com>
> > Cc: Ander Conselvan De Oliveira <ander.conselvan.de.olive...@intel.co
> > m>
> > Signed-off-by: Rodrigo Vivi <rodrigo.v...@intel.com>
> > Reviewed-by: Kahola, Mika <mika.kah...@intel.com>
> > Signed-off-by: Rodrigo Vivi <rodrigo.v...@intel.com>
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h  |  9 +
> >  drivers/gpu/drm/i915/intel_ddi.c | 23 ---
> >  2 files changed, 29 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 3cfc65f..dcb8e21 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -8150,6 +8150,15 @@ enum {
> >  #define DPLL_CFGCR1(id)_MMIO_PIPE((id) - SKL_DPLL1,
> > _DPLL1_CFGCR1, _DPLL2_CFGCR1)
> >  #define DPLL_CFGCR2(id)_MMIO_PIPE((id) - SKL_DPLL1,
> > _DPLL1_CFGCR2, _DPLL2_CFGCR2)
> >  
> > +/*
> > + * CNL Clocks
> > + */
> > +#define DPCLKA_CFGCR0  _MMIO(0x6C200)
> > +#define  DPCLKA_CFGCR0_DDI_CLK_OFF(port)   (1 << ((port)+10))
> > +#define  DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port)  (3 <<
> > ((port)*2))
> > +#define  DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port) ((port)*2)
> > +#define  DPCLKA_CFGCR0_DDI_CLK_SEL(pll, port)  ((pll) <<
> > ((port)*2))
> > +
> >  /* BXT display engine PLL */
> >  #define BXT_DE_PLL_CTL _MMIO(0x6d000)
> >  #define   BXT_DE_PLL_RATIO(x)  (x) /*
> > {60,65,100} * 19.2MHz */
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 0914ad9..2a901bf 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1621,13 +1621,27 @@ static void intel_ddi_clk_select(struct
> > intel_encoder *encoder,
> >  {
> >     struct drm_i915_private *dev_priv = to_i915(encoder-
> > > base.dev);
> > 
> >     enum port port = intel_ddi_get_encoder_port(encoder);
> > +   uint32_t val;
> >  
> >     if (WARN_ON(!pll))
> >     return;
> >  
> > -   if (IS_GEN9_BC(dev_priv)) {
> > -   uint32_t val;
> > +   if (IS_CANNONLAKE(dev_priv)) {
> > +   /* Configure DPCLKA_CFGCR0 to map the DPLL to the
> > DDI. */
> > +   val = I915_READ(DPCLKA_CFGCR0);
> > +   val |= DPCLKA_CFGCR0_DDI_CLK_SEL(pll->id, port);
> > +   I915_WRITE(DPCLKA_CFGCR0, val);
> 
> A question to the Atomic Lords: don't we need some sort of locking
> around this register since it's used by all ports/clocks? I suppose
> dev_priv->dpll_lock would do...
> 
> Maybe the same would apply for gen9_bc.

If there are modesets happening in parallel for different crtcs, then some
locking is needed. dpll_lock seems like the right call, that's what's used to
avoid the same problem with the enable/disable hooks.

Btw, I think this patch shows why something like [1] might be a good idea.

[1] https://patchwork.freedesktop.org/patch/113598/
> 
> >  
> > +   /*
> > +    * Configure DPCLKA_CFGCR0 to turn on the clock for
> > the DDI.
> > +    * This step and the step before must be done with
> > separate
> > +    * register writes.
> > +    */
> > +   val = I915_READ(DPCLKA_CFGCR0);
> > +   val &= ~(DPCLKA

Re: [Intel-gfx] [PATCH 16/67] drm/i915/cnl: Cannonlake has 4 planes (3 sprites) per pipe

[Ander Conselvan De Oliveira]

On Thu, 2017-04-06 at 12:15 -0700, Rodrigo Vivi wrote:
> From: James Irwin <james.ir...@intel.com>
> 
> Issue: VIZ-4525
> 
> Reviewed-by: Damien Lespiau <damien.lesp...@intel.com>
> Signed-off-by: James Irwin <james.ir...@intel.com>
> Signed-off-by: Damien Lespiau <damien.lesp...@intel.com>

Reviewed-by: Ander Conselvan de Oliveira <conselv...@gmail.com>

> ---
>  drivers/gpu/drm/i915/intel_device_info.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
> b/drivers/gpu/drm/i915/intel_device_info.c
> index 6b09a82..3cc8cdb 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -328,7 +328,7 @@ void intel_device_info_runtime_init(struct 
> drm_i915_private *dev_priv)
>* we don't expose the topmost plane at all to prevent ABI breakage
>* down the line.
>*/
> - if (IS_GEMINILAKE(dev_priv))
> + if (IS_GEN10(dev_priv) || IS_GEMINILAKE(dev_priv))
>   for_each_pipe(dev_priv, pipe)
>   info->num_sprites[pipe] = 3;
>   else if (IS_BROXTON(dev_priv)) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/67] drm/i915/cnl: Introduce Cannonlake platform defition.

[Ander Conselvan De Oliveira]

On Thu, 2017-04-06 at 12:15 -0700, Rodrigo Vivi wrote:
> Cannonlake is a Intel® Processor containing Intel® HD Graphics
> following Kabylake.
> 
> It is Gen10.
> 
> Let's start by adding the platform definition based on previous
> platforms but yet as alpha_support.
> 
> On following patches we will start adding PCI IDs and the
> platform specific changes.
> 
> Signed-off-by: Rodrigo Vivi <rodrigo.v...@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_drv.h  | 3 +++
>  drivers/gpu/drm/i915/i915_pci.c  | 8 
>  drivers/gpu/drm/i915/intel_device_info.c | 1 +
>  3 files changed, 12 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 2685f12..a357862 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -887,6 +887,7 @@ enum intel_platform {
>   INTEL_BROXTON,
>   INTEL_KABYLAKE,
>   INTEL_GEMINILAKE,
> + INTEL_CANNONLAKE,
>   INTEL_MAX_PLATFORMS
>  };
>  
> @@ -2751,6 +2752,7 @@ static inline struct scatterlist *__sg_next(struct 
> scatterlist *sg)
>  #define IS_BROXTON(dev_priv) ((dev_priv)->info.platform == INTEL_BROXTON)
>  #define IS_KABYLAKE(dev_priv)((dev_priv)->info.platform == 
> INTEL_KABYLAKE)
>  #define IS_GEMINILAKE(dev_priv)  ((dev_priv)->info.platform == 
> INTEL_GEMINILAKE)
> +#define IS_CANNONLAKE(dev_priv)  ((dev_priv)->info.platform == 
> INTEL_CANNONLAKE)
>  #define IS_MOBILE(dev_priv)  ((dev_priv)->info.is_mobile)
>  #define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \
>   (INTEL_DEVID(dev_priv) & 0xFF00) == 0x0C00)
> @@ -2842,6 +2844,7 @@ static inline struct scatterlist *__sg_next(struct 
> scatterlist *sg)
>  #define IS_GEN7(dev_priv)(!!((dev_priv)->info.gen_mask & BIT(6)))
>  #define IS_GEN8(dev_priv)(!!((dev_priv)->info.gen_mask & BIT(7)))
>  #define IS_GEN9(dev_priv)(!!((dev_priv)->info.gen_mask & BIT(8)))
> +#define IS_GEN10(dev_priv)   (!!((dev_priv)->info.gen_mask & BIT(9)))
>  
>  #define IS_LP(dev_priv)  (INTEL_INFO(dev_priv)->is_lp)
>  #define IS_GEN9_LP(dev_priv) (IS_GEN9(dev_priv) && IS_LP(dev_priv))
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index f87b0c4..a2a4b2f 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -431,6 +431,14 @@
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
>  };
>  
> +static const struct intel_device_info intel_cannonlake_info = {
> + BDW_FEATURES,
> + .is_alpha_support = 1,
> + .platform = INTEL_CANNONLAKE,
> + .gen = 10,
> + .ddb_size = 896,
> +};
> +

I think it makes sense to squash patch 17 with this one. No point in adding
.ddb_size with the wrong value. If there's a reason not squash, I'd say is
better to leave this as zero, so that the WARN_ON(ddb_size == 0) in intel_pm.c
will remind us to fix it. With one of these suggestions,

Reviewed-by: Ander Conselvan de Oliveira <conselv...@gmail.com>

>  /*
>   * Make sure any device matches here are from most specific to most
>   * general.  For example, since the Quanta match is based on the subsystem
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
> b/drivers/gpu/drm/i915/intel_device_info.c
> index 7d01dfe..6b09a82 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -51,6 +51,7 @@
>   PLATFORM_NAME(BROXTON),
>   PLATFORM_NAME(KABYLAKE),
>   PLATFORM_NAME(GEMINILAKE),
> + PLATFORM_NAME(CANNONLAKE),
>  };
>  #undef PLATFORM_NAME
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messages

[Ander Conselvan De Oliveira]

On Fri, 2017-04-28 at 12:44 +, Chauhan, Madhav wrote:
> > -Original Message-
> > From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
> > Sent: Friday, April 28, 2017 2:28 PM
> > To: Chauhan, Madhav <madhav.chau...@intel.com>; intel-
> > g...@lists.freedesktop.org
> > Cc: Deepak M <m.dee...@intel.com>; Nikula, Jani <jani.nik...@intel.com>;
> > Vetter, Daniel <daniel.vet...@intel.com>; Jani Nikula
> > <jani.nik...@linux.intel.com>; drm-intel-fi...@lists.freedesktop.org
> > Subject: Re: [PATCH] drm/i915/glk: Fix DSI "*ERROR* ULPS is still active"
> > messages
> > 
> > On Fri, 2017-04-28 at 08:50 +, Chauhan, Madhav wrote:
> > > > -Original Message-
> > > > From: Conselvan De Oliveira, Ander
> > > > Sent: Friday, April 28, 2017 1:32 PM
> > > > To: intel-gfx@lists.freedesktop.org
> > > > Cc: Conselvan De Oliveira, Ander
> > > > <ander.conselvan.de.olive...@intel.com>;
> > > > Deepak M <m.dee...@intel.com>; Chauhan, Madhav
> > > > <madhav.chau...@intel.com>; Nikula, Jani <jani.nik...@intel.com>;
> > > > Vetter, Daniel <daniel.vet...@intel.com>; Jani Nikula
> > > > <jani.nik...@linux.intel.com>; drm-intel-fi...@lists.freedesktop.org
> > > > Subject: [PATCH] drm/i915/glk: Fix DSI "*ERROR* ULPS is still active"
> > > > messages
> > > > 
> > > > The sequence in glk_dsi_device_ready() enters ULPS then waits until
> > > > it is
> > > > *not* active to then disable it. The correct sequence according to
> > > > the spec is to enter ULPS then wait until the GLK_ULPS_NOT_ACTIVE
> > > > bit is zero, i.e., ULPS is active, and then disable ULPS.
> > > > 
> > > > Fixing the codition gets rid of the following spurious error messages:
> > > 
> > > Please correct the typo error to "condition", otherwise looks good.
> > > Thanks for catching this.
> > 
> > If you upgrade the above statement to a Reviewed-by, I can fix the typo 
> > while
> > merging?
> > 
> > Ander
> > 
> > > 
> > > > 
> > > > [drm:glk_dsi_device_ready [i915]] *ERROR* ULPS is still active
> > > > 
> > > > Fixes: 4644848369c0 ("drm/i915/glk: Add MIPIIO Enable/disable
> > > > sequence")
> > > > Cc: Deepak M <m.dee...@intel.com>
> > > > Cc: Madhav Chauhan <madhav.chau...@intel.com>
> > > > Cc: Jani Nikula <jani.nik...@intel.com>
> > > > Cc: Daniel Vetter <daniel.vet...@intel.com>
> > > > Cc: Jani Nikula <jani.nik...@linux.intel.com>
> > > > Cc: intel-gfx@lists.freedesktop.org
> > > > Cc: <drm-intel-fi...@lists.freedesktop.org>
> > > > Signed-off-by: Ander Conselvan de Oliveira
> > > > <ander.conselvan.de.olive...@intel.com>
> 
> Reviewed-by: Madhav Chauhan <madhav.chau...@intel.com>

Pushed with the typo fixed. Thanks for reviewing.

Ander

> 
> 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_dsi.c | 7 +++
> > > >  1 file changed, 3 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> > > > b/drivers/gpu/drm/i915/intel_dsi.c
> > > > index 3ffe8b1..fc0ef49 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dsi.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dsi.c
> > > > @@ -410,11 +410,10 @@ static void glk_dsi_device_ready(struct
> > > > intel_encoder *encoder)
> > > > val |= (ULPS_STATE_ENTER | DEVICE_READY);
> > > > I915_WRITE(MIPI_DEVICE_READY(port), val);
> > > > 
> > > > -   /* Wait for ULPS Not active */
> > > > +   /* Wait for ULPS active */
> > > > if (intel_wait_for_register(dev_priv,
> > > > -   MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE,
> > > > -   GLK_ULPS_NOT_ACTIVE, 20))
> > > > -   DRM_ERROR("ULPS is still active\n");
> > > > +   MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE, 0,
> > > > 20))
> > > > +   DRM_ERROR("ULPS not active\n");
> > > > 
> > > > /* Exit ULPS */
> > > > val = I915_READ(MIPI_DEVICE_READY(port));
> > > > --
> > > > 2.9.3
> > > 
> > > 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messages

[Ander Conselvan De Oliveira]

On Fri, 2017-04-28 at 08:50 +, Chauhan, Madhav wrote:
> > -Original Message-
> > From: Conselvan De Oliveira, Ander
> > Sent: Friday, April 28, 2017 1:32 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Conselvan De Oliveira, Ander <ander.conselvan.de.olive...@intel.com>;
> > Deepak M <m.dee...@intel.com>; Chauhan, Madhav
> > <madhav.chau...@intel.com>; Nikula, Jani <jani.nik...@intel.com>; Vetter,
> > Daniel <daniel.vet...@intel.com>; Jani Nikula <jani.nik...@linux.intel.com>;
> > drm-intel-fi...@lists.freedesktop.org
> > Subject: [PATCH] drm/i915/glk: Fix DSI "*ERROR* ULPS is still active"
> > messages
> > 
> > The sequence in glk_dsi_device_ready() enters ULPS then waits until it is
> > *not* active to then disable it. The correct sequence according to the spec 
> > is
> > to enter ULPS then wait until the GLK_ULPS_NOT_ACTIVE bit is zero, i.e., 
> > ULPS
> > is active, and then disable ULPS.
> > 
> > Fixing the codition gets rid of the following spurious error messages:
> 
> Please correct the typo error to "condition", otherwise looks good.
> Thanks for catching this.

If you upgrade the above statement to a Reviewed-by, I can fix the typo while
merging?

Ander

> 
> > 
> > [drm:glk_dsi_device_ready [i915]] *ERROR* ULPS is still active
> > 
> > Fixes: 4644848369c0 ("drm/i915/glk: Add MIPIIO Enable/disable sequence")
> > Cc: Deepak M <m.dee...@intel.com>
> > Cc: Madhav Chauhan <madhav.chau...@intel.com>
> > Cc: Jani Nikula <jani.nik...@intel.com>
> > Cc: Daniel Vetter <daniel.vet...@intel.com>
> > Cc: Jani Nikula <jani.nik...@linux.intel.com>
> > Cc: intel-gfx@lists.freedesktop.org
> > Cc: <drm-intel-fi...@lists.freedesktop.org>
> > Signed-off-by: Ander Conselvan de Oliveira
> > <ander.conselvan.de.olive...@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_dsi.c | 7 +++
> >  1 file changed, 3 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> > b/drivers/gpu/drm/i915/intel_dsi.c
> > index 3ffe8b1..fc0ef49 100644
> > --- a/drivers/gpu/drm/i915/intel_dsi.c
> > +++ b/drivers/gpu/drm/i915/intel_dsi.c
> > @@ -410,11 +410,10 @@ static void glk_dsi_device_ready(struct
> > intel_encoder *encoder)
> > val |= (ULPS_STATE_ENTER | DEVICE_READY);
> > I915_WRITE(MIPI_DEVICE_READY(port), val);
> > 
> > -   /* Wait for ULPS Not active */
> > +   /* Wait for ULPS active */
> > if (intel_wait_for_register(dev_priv,
> > -   MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE,
> > -   GLK_ULPS_NOT_ACTIVE, 20))
> > -   DRM_ERROR("ULPS is still active\n");
> > +   MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE, 0,
> > 20))
> > +   DRM_ERROR("ULPS not active\n");
> > 
> > /* Exit ULPS */
> > val = I915_READ(MIPI_DEVICE_READY(port));
> > --
> > 2.9.3
> 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messages

[Ander Conselvan de Oliveira]

The sequence in glk_dsi_device_ready() enters ULPS then waits until it is
*not* active to then disable it. The correct sequence according to the
spec is to enter ULPS then wait until the GLK_ULPS_NOT_ACTIVE bit is
zero, i.e., ULPS is active, and then disable ULPS.

Fixing the codition gets rid of the following spurious error messages:

[drm:glk_dsi_device_ready [i915]] *ERROR* ULPS is still active

Fixes: 4644848369c0 ("drm/i915/glk: Add MIPIIO Enable/disable sequence")
Cc: Deepak M <m.dee...@intel.com>
Cc: Madhav Chauhan <madhav.chau...@intel.com>
Cc: Jani Nikula <jani.nik...@intel.com>
Cc: Daniel Vetter <daniel.vet...@intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <drm-intel-fi...@lists.freedesktop.org>
Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
---
 drivers/gpu/drm/i915/intel_dsi.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 3ffe8b1..fc0ef49 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -410,11 +410,10 @@ static void glk_dsi_device_ready(struct intel_encoder 
*encoder)
val |= (ULPS_STATE_ENTER | DEVICE_READY);
I915_WRITE(MIPI_DEVICE_READY(port), val);
 
-   /* Wait for ULPS Not active */
+   /* Wait for ULPS active */
if (intel_wait_for_register(dev_priv,
-   MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE,
-   GLK_ULPS_NOT_ACTIVE, 20))
-   DRM_ERROR("ULPS is still active\n");
+   MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE, 0, 20))
+   DRM_ERROR("ULPS not active\n");
 
/* Exit ULPS */
val = I915_READ(MIPI_DEVICE_READY(port));
-- 
2.9.3

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

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/glk: Don't allow 12 bpc when htotal is too big

[Ander Conselvan De Oliveira]

On Mon, 2017-04-24 at 11:22 +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/glk: Don't allow 12 bpc when htotal is too big
> URL   : https://patchwork.freedesktop.org/series/23451/
> State : success

Pushed, thanks for reviewing.

Ander

> 
> == Summary ==
> 
> Series 23451v1 drm/i915/glk: Don't allow 12 bpc when htotal is too big
> https://patchwork.freedesktop.org/api/1.0/series/23451/revisions/1/mbox/
> 
> Test gem_exec_flush:
> Subgroup basic-batch-kernel-default-uc:
> fail   -> PASS   (fi-snb-2600) fdo#17
> 
> fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
> 
> fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
> time:429s
> fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
> time:430s
> fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
> time:576s
> fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
> time:506s
> fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
> time:564s
> fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
> time:490s
> fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
> time:493s
> fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time:415s
> fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time:410s
> fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
> time:425s
> fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:494s
> fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:464s
> fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:461s
> fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time:562s
> fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time:450s
> fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
> time:575s
> fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
> time:457s
> fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time:497s
> fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
> time:429s
> fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
> time:529s
> fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
> time:398s
> 
> 9fb4b60bfa8c532ad6eda05af002c6b2f090d97f drm-tip: 2017y-04m-24d-09h-40m-53s 
> UTC integration manifest
> 7fa2f63 drm/i915/glk: Don't allow 12 bpc when htotal is too big
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4536/
> ___
> 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] drm/i915/glk: Don't allow 12 bpc when htotal is too big

[Ander Conselvan De Oliveira]

On Mon, 2017-04-24 at 16:49 +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 4/24/2017 4:17 PM, Ander Conselvan de Oliveira wrote:
> > Display workaround #1139 for Geminilake instructs us to restrict HDMI
> > to 8 bpc when htotal is greater than 5460. Otherwise, the pipe is unable
> > to generate a proper signal and is left in a state where corruption is
> > seen with other modes.
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100440
> > Cc: Shashank Sharma <shashank.sha...@intel.com>
> > Signed-off-by: Ander Conselvan de Oliveira 
> > <ander.conselvan.de.olive...@intel.com>
> > ---
> >   drivers/gpu/drm/i915/intel_hdmi.c | 5 +
> >   1 file changed, 5 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index 6efc3cb..52f0b2d 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -1327,6 +1327,11 @@ static bool hdmi_12bpc_possible(struct 
> > intel_crtc_state *crtc_state)
> > return false;
> > }
> >   
> > +   /* Display Wa #1139 */
> > +   if (IS_GLK_REVID(dev_priv, 0, GLK_REVID_A1) &&
> > +   crtc_state->base.adjusted_mode.htotal > 5460)
> 
> Small inputs:
> - We might wanna extend this for CNL too, as the WAR is valid for it 
> too. I am not sure it should be this same patch or not.

None of the CNL patches landed yet, so I think we should include this in the
patch/series that enables hdmi 2.0 clocks for it.

> - We need to modify this check not to affect the YCBCR 420 modes, as 
> there won't be any change between the timings of a YCBCR mode and a
>normal mode (apart from a flag), but htotal should be valid in YCBCR 
> 420 case. But I can handle this part while sending second patch set of
>YCBCR 420 handling.

Thanks.

> - Also, should we reject 12BPC totally, or just clamp htotal to max 
> possible (5460) and go ahead? Ville ?

Since this is only up to GLK A1, I don't think it is worth the trouble.

Ander

> 
> In any case, please feel free to use:
> Reviewed-by: Shashank Sharma <shashank.sha...@intel.com>
> > +   return false;
> > +
> > return true;
> >   }
> >   
> 
> ___
> 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 58/67] drm/i915/cnl: Cannonlake color init.

[Ander Conselvan De Oliveira]

On Tue, 2017-04-25 at 05:29 +, Vivi, Rodrigo wrote:
> > On Apr 24, 2017, at 10:57 AM, Ville Syrjälä  
> > wrote:
> > 
> > > On Thu, Apr 06, 2017 at 12:15:54PM -0700, Rodrigo Vivi wrote:
> > > Cannonlake has same color setup as Geminilake.
> > > Legacy color load luts doesn't work anymore on Cannonlake+.
> > 
> > Not sure what that means. The legacy 8bpc LUT i no longer there?

As far as I can tell the legacy 8bpc LUT is still there in CNL, but I might be
reading the spec wrong. 

> > The code still depends on that working, and we also still expose the C8
> > format which at least used to depend on the legacy LUT.
> 
> Not sure... what I tried to say is that by using old sequences available for 
> luts we just get black screen... while in previous platforms I remember that 
> old setup sequences working while we didn't have the new ones...

That's probably the pre-CSC gamma table. It doesn't have its own enable bit and
instead it is enabled whenever CSC is (which we always do). But since the
default value for that table is all zeroes, enabling CSC without setting it up
causes black screens.

Ander

> 
> > 
> > > 
> > > Signed-off-by: Rodrigo Vivi 
> > > ---
> > > drivers/gpu/drm/i915/i915_pci.c  | 1 +
> > > drivers/gpu/drm/i915/intel_color.c   | 2 +-
> > > drivers/gpu/drm/i915/intel_display.c | 4 ++--
> > > drivers/gpu/drm/i915/intel_sprite.c  | 2 +-
> > > 4 files changed, 5 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_pci.c 
> > > b/drivers/gpu/drm/i915/i915_pci.c
> > > index bace848..1e8e0ac 100644
> > > --- a/drivers/gpu/drm/i915/i915_pci.c
> > > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > > @@ -438,6 +438,7 @@
> > >.gen = 10,
> > >.ddb_size = 1024,
> > >.has_csr = 1,
> > > +.color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
> > > };
> > > 
> > > /*
> > > diff --git a/drivers/gpu/drm/i915/intel_color.c 
> > > b/drivers/gpu/drm/i915/intel_color.c
> > > index 306c6b0..f85d575 100644
> > > --- a/drivers/gpu/drm/i915/intel_color.c
> > > +++ b/drivers/gpu/drm/i915/intel_color.c
> > > @@ -615,7 +615,7 @@ void intel_color_init(struct drm_crtc *crtc)
> > >   IS_BROXTON(dev_priv)) {
> > >dev_priv->display.load_csc_matrix = i9xx_load_csc_matrix;
> > >dev_priv->display.load_luts = broadwell_load_luts;
> > > -} else if (IS_GEMINILAKE(dev_priv)) {
> > > +} else if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
> > >dev_priv->display.load_csc_matrix = i9xx_load_csc_matrix;
> > >dev_priv->display.load_luts = glk_load_luts;
> > >} else {
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 3adee22..697c112 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -3302,7 +3302,7 @@ u32 skl_plane_ctl(const struct intel_crtc_state 
> > > *crtc_state,
> > > 
> > >plane_ctl = PLANE_CTL_ENABLE;
> > > 
> > > -if (!IS_GEMINILAKE(dev_priv)) {
> > > +if (!IS_GEMINILAKE(dev_priv) && !IS_CANNONLAKE(dev_priv)) {
> > >plane_ctl |=
> > >PLANE_CTL_PIPE_GAMMA_ENABLE |
> > >PLANE_CTL_PIPE_CSC_ENABLE |
> > > @@ -3359,7 +3359,7 @@ static void skylake_update_primary_plane(struct 
> > > drm_plane *plane,
> > > 
> > >spin_lock_irqsave(_priv->uncore.lock, irqflags);
> > > 
> > > -if (IS_GEMINILAKE(dev_priv)) {
> > > +if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
> > >I915_WRITE_FW(PLANE_COLOR_CTL(pipe, plane_id),
> > >  PLANE_COLOR_PIPE_GAMMA_ENABLE |
> > >  PLANE_COLOR_PIPE_CSC_ENABLE |
> > > diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> > > b/drivers/gpu/drm/i915/intel_sprite.c
> > > index f7d4314..a002c1a 100644
> > > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > > @@ -240,7 +240,7 @@ void intel_pipe_update_end(struct intel_crtc *crtc, 
> > > struct intel_flip_work *work
> > > 
> > >spin_lock_irqsave(_priv->uncore.lock, irqflags);
> > > 
> > > -if (IS_GEMINILAKE(dev_priv)) {
> > > +if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
> > >I915_WRITE_FW(PLANE_COLOR_CTL(pipe, plane_id),
> > >  PLANE_COLOR_PIPE_GAMMA_ENABLE |
> > >  PLANE_COLOR_PIPE_CSC_ENABLE |
> > > -- 
> > > 1.9.1
> > > 
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
> > -- 
> > Ville Syrjälä
> > Intel OTC
> 
> ___
> 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

Re: [Intel-gfx] [PATCH] drm/i915/glk: Don't allow 12 bpc when htotal is too big

[Ander Conselvan De Oliveira]

On Mon, 2017-04-24 at 13:47 +0300, Ander Conselvan de Oliveira wrote:
> Display workaround #1139 for Geminilake instructs us to restrict HDMI
> to 8 bpc when htotal is greater than 5460. Otherwise, the pipe is unable
> to generate a proper signal and is left in a state where corruption is
> seen with other modes.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100440
> Cc: Shashank Sharma <shashank.sha...@intel.com>
> Signed-off-by: Ander Conselvan de Oliveira 
> <ander.conselvan.de.olive...@intel.com>

Perhaps this should have

Fixes: 14292b7ff86f ("drm/i915: allow HDMI 2.0 clock rates")

since it is only after that patch that the issue would be exposed, even though
is not the cause for it. Jani?

Ander

> ---
>  drivers/gpu/drm/i915/intel_hdmi.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 6efc3cb..52f0b2d 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1327,6 +1327,11 @@ static bool hdmi_12bpc_possible(struct 
> intel_crtc_state *crtc_state)
>   return false;
>   }
>  
> + /* Display Wa #1139 */
> + if (IS_GLK_REVID(dev_priv, 0, GLK_REVID_A1) &&
> + crtc_state->base.adjusted_mode.htotal > 5460)
> + return false;
> +
>   return true;
>  }
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/glk: Don't allow 12 bpc when htotal is too big

[Ander Conselvan de Oliveira]

Display workaround #1139 for Geminilake instructs us to restrict HDMI
to 8 bpc when htotal is greater than 5460. Otherwise, the pipe is unable
to generate a proper signal and is left in a state where corruption is
seen with other modes.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100440
Cc: Shashank Sharma <shashank.sha...@intel.com>
Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
---
 drivers/gpu/drm/i915/intel_hdmi.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 6efc3cb..52f0b2d 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1327,6 +1327,11 @@ static bool hdmi_12bpc_possible(struct intel_crtc_state 
*crtc_state)
return false;
}
 
+   /* Display Wa #1139 */
+   if (IS_GLK_REVID(dev_priv, 0, GLK_REVID_A1) &&
+   crtc_state->base.adjusted_mode.htotal > 5460)
+   return false;
+
return true;
 }
 
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t v3] lib/igt_kms: Force outputs to use full range RGB

[Ander Conselvan de Oliveira]

In at least SKL and GLK (possibly other devices too), using a cursor
plane to scan out an fb might result in a different pipe crc than when
using a regular plane at the same position with the same fb while using
the CSC logic to limit the color range. The differences could be caused
by the cursor plane being limited to 8 bpc while the regular planes
support higher bit depths, leading to slightly different values to be
used internally. This is evidenced by the failures happening with
specific color values, 0.5 for example, but that's mostly speculation.

To avoid misterious failures caused by limited range rgb, force all
tests to use full range. It is still possible for tests to override this
if necessary.

v2: Add more details to the commit message.
v3: Force all tests to use full range.
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
---
 lib/igt_kms.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 5811414..9f72913 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1455,10 +1455,15 @@ static void igt_output_refresh(igt_output_t *output)
   -1);
}
 
-   if (output->config.connector)
+   if (output->config.connector) {
igt_atomic_fill_connector_props(display, output,
IGT_NUM_CONNECTOR_PROPS, igt_connector_prop_names);
 
+   kmstest_set_connector_broadcast_rgb(display->drm_fd,
+   output->config.connector,
+   BROADCAST_RGB_FULL);
+   }
+
if (output->use_override_mode)
output->config.default_mode = output->override_mode;
 
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH 5/8] drm/i915/skl+: ddb min requirement may exceed allocation

[Ander Conselvan De Oliveira]

On Tue, 2017-02-28 at 17:01 +0530, Mahesh Kumar wrote:
> DDB minimum requirement may also exceed the allocated DDB for CRTC.
> Instead of directly deducting from alloc_size, check against
> total_min_ddb requirement. if exceeding fail the flip.

Instead of doing a low level description of the code change, including variable
names and whatnot, use this space to describe in a high level what the patch
does and why it is necessary. For instance, in this particular case the patch
changes the modeset to fail when there isn't enough ddb for the given
configuration. Previously it succeeded, but the plane ddb allocations would be
bogus because of the negative value of alloc_size, leading to screen corruption
and system hangs.

Do I understand correctly that this patch is independent from the rest of the
series? Might make sense to merge it earlier, since the bug is there with the
old ddb allocation algorithm too.

> 
> Signed-off-by: Mahesh Kumar 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 76c98614..24e9e5d69833 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3380,6 +3380,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
>   int num_active;
>   unsigned plane_data_rate[I915_MAX_PLANES] = {};
>   unsigned plane_y_data_rate[I915_MAX_PLANES] = {};
> + uint16_t total_min_blocks = 0;
>  
>   /* Clear the partitioning for disabled planes. */
>   memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
> @@ -3407,10 +3408,18 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
>*/
>  
>   for_each_plane_id_on_crtc(intel_crtc, plane_id) {
> - alloc_size -= minimum[plane_id];
> - alloc_size -= y_minimum[plane_id];
> + total_min_blocks += minimum[plane_id];
> + total_min_blocks += y_minimum[plane_id];
>   }
>  
> + if ((total_min_blocks > alloc_size)) {

One '(' is enough.

> + DRM_DEBUG_KMS("Requested display configuration exceeds system 
> DDB limitations");
> + DRM_DEBUG_KMS("minimum required %d/%d\n", total_min_blocks,
> + alloc_size);
> + return-EINVAL;

Space between return and -EINVAL please.

Ander

> + }
> +
> + alloc_size -= total_min_blocks;
>   ddb->plane[pipe][PLANE_CURSOR].start = alloc->end - 
> minimum[PLANE_CURSOR];
>   ddb->plane[pipe][PLANE_CURSOR].end = alloc->end;
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t v2] kms_cursor_crc: Force the test to run in full RGB range

[Ander Conselvan de Oliveira]

In at least SKL and GLK (possibly other devices too), using a cursor
plane to scan out an fb might result in a different pipe crc than when
using a regular plane at the same position with the same fb while using
the CSC logic to limit the color range. The differences could be caused
by the cursor plane being limited to 8 bpc while the regular planes
support higher bit depths, leading to slightly different values to be
used internally. This is evidenced by the failures happening with
specific color values, 0.5 for example, but that's mostly speculation.

v2: Add more details to the commit message.
Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
---
 tests/kms_cursor_crc.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/tests/kms_cursor_crc.c b/tests/kms_cursor_crc.c
index 206f852..1208d90 100644
--- a/tests/kms_cursor_crc.c
+++ b/tests/kms_cursor_crc.c
@@ -372,6 +372,14 @@ static void run_test(data_t *data, void (*testfunc)(data_t 
*), int cursor_w, int
  kmstest_pipe_name(data->pipe),
  igt_output_name(output));
 
+   /*
+* Force test to use full range RGB. Limited range causes CRC
+* mismatches in SKL and GLK.
+*/
+   kmstest_set_connector_broadcast_rgb(data->drm_fd,
+   
data->output->config.connector,
+   BROADCAST_RGB_FULL);
+
testfunc(data);
 
igt_info("\n%s on pipe %s, connector %s: PASSED\n\n",
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t] lib/debugfs: Close dir before returning open debugs file

[Ander Conselvan de Oliveira]

The function igt_debugfs_open() would not close the debugfs dir before
returning. Tests that do a lot of pipe CRC comparaions, such as
kms_cursor_crc,  would eventually fail.

(kms_cursor_crc:3853) igt-debugfs-CRITICAL: Test assertion failure function 
igt_pipe_crc_do_start, file igt_debugfs.c:387:
(kms_cursor_crc:3853) igt-debugfs-CRITICAL: Failed assertion: err == 0
(kms_cursor_crc:3853) igt-debugfs-CRITICAL: Last errno: 24, Too many open files
(kms_cursor_crc:3853) igt-debugfs-CRITICAL: error: -24 != 0

83884e97e187 ("Restore "lib: Open debugfs files for the given DRM device"")
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
---
 lib/igt_debugfs.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
index d64694c..fb6d521 100644
--- a/lib/igt_debugfs.c
+++ b/lib/igt_debugfs.c
@@ -212,13 +212,17 @@ int igt_debugfs_dir(int device)
  */
 int igt_debugfs_open(int device, const char *filename, int mode)
 {
-   int dir;
+   int dir, ret;
 
dir = igt_debugfs_dir(device);
if (dir < 0)
return dir;
 
-   return openat(dir, filename, mode);
+   ret = openat(dir, filename, mode);
+
+   close(dir);
+
+   return ret;
 }
 
 /**
-- 
2.9.3

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

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/GuC/GLK: Load GuC on GLK

[Ander Conselvan De Oliveira]

On Thu, 2017-03-30 at 20:43 +, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [1/2] drm/i915/GuC/GLK: Load GuC on GLK
> URL   : https://patchwork.freedesktop.org/series/22237/
> State : success

Pushed to dinq. Thanks for the patches and reviews!

Ander

> 
> == Summary ==
> 
> Series 22237v1 Series without cover letter
> https://patchwork.freedesktop.org/api/1.0/series/22237/revisions/1/mbox/
> 
> Test gem_exec_suspend:
> Subgroup basic-s4-devices:
> pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125
> 
> fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125
> 
> fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
> time: 427s
> fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
> time: 425s
> fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
> time: 568s
> fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
> time: 507s
> fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
> time: 547s
> fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
> time: 487s
> fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
> time: 490s
> fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time: 409s
> fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time: 404s
> fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
> time: 422s
> fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time: 482s
> fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time: 469s
> fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time: 451s
> fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
> time: 570s
> fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time: 455s
> fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
> time: 578s
> fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
> time: 457s
> fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time: 488s
> fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
> time: 434s
> fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
> time: 530s
> fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
> time: 408s
> 
> d217cd61ada383a577dc686dd74f77856695ec84 drm-tip: 2017y-03m-30d-18h-24m-46s 
> UTC integration manifest
> 3362b59 drm/i915/GLK/HuC: Load HuC on GLK
> 1657e54 drm/i915/GuC/GLK: Load GuC on GLK
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4368/
> ___
> 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

[Intel-gfx] [PATCH i-g-t 1/2] kms_cursor_crc: Force the test to run in full RGB range

[Ander Conselvan de Oliveira]

In at least SKL and GLK (possibly other devices too), using a cursor
plane to scan out an fb might result in a different pipe crc than when
using a regular plane at the same position with the same fb. The
differences could be caused by the cursor plane being limited to 8 bpc
while the regular planes support higher bit depths, since the failures
happens with specific color values, but that's speculation.

Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
---
 tests/kms_cursor_crc.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/tests/kms_cursor_crc.c b/tests/kms_cursor_crc.c
index 206f852..1208d90 100644
--- a/tests/kms_cursor_crc.c
+++ b/tests/kms_cursor_crc.c
@@ -372,6 +372,14 @@ static void run_test(data_t *data, void (*testfunc)(data_t 
*), int cursor_w, int
  kmstest_pipe_name(data->pipe),
  igt_output_name(output));
 
+   /*
+* Force test to use full range RGB. Limited range causes CRC
+* mismatches in SKL and GLK.
+*/
+   kmstest_set_connector_broadcast_rgb(data->drm_fd,
+   
data->output->config.connector,
+   BROADCAST_RGB_FULL);
+
testfunc(data);
 
igt_info("\n%s on pipe %s, connector %s: PASSED\n\n",
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t 2/2] kms_cursor_limited: Test crc matches between cursor and overlay planes

[Ander Conselvan de Oliveira]

This test actually *fails* in GLK and possibly SKL and others too. When
using limited range, the pipe crc when using the cursor plane is
different than the one when using an overlay plane, although the fb and
plane position is the same.

Since this test fails it should probably not be merged, but it is here
to prove the point of the previous patch.

Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
---
 tests/Makefile.sources |   1 +
 tests/kms_cursor_limited.c | 175 +
 2 files changed, 176 insertions(+)
 create mode 100644 tests/kms_cursor_limited.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 45c21a0..c7d36f6 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -99,6 +99,7 @@ TESTS_progs_M = \
kms_chv_cursor_fail \
kms_cursor_crc \
kms_cursor_legacy \
+   kms_cursor_limited \
kms_draw_crc \
kms_fbc_crc \
kms_fbcon_fbt \
diff --git a/tests/kms_cursor_limited.c b/tests/kms_cursor_limited.c
new file mode 100644
index 000..88c130c
--- /dev/null
+++ b/tests/kms_cursor_limited.c
@@ -0,0 +1,175 @@
+#include "igt.h"
+
+typedef struct {
+   int drm_fd;
+   igt_display_t display;
+   struct igt_fb primary_fb;
+   struct igt_fb fb;
+   int fb_w, fb_h;
+   igt_output_t *output;
+   enum pipe pipe;
+   igt_pipe_crc_t *pipe_crc;
+} data_t;
+
+static void cursor_enable(data_t *data)
+{
+   igt_output_t *output = data->output;
+   igt_plane_t *cursor;
+
+   cursor = igt_output_get_plane_type(output, DRM_PLANE_TYPE_CURSOR);
+   igt_plane_set_fb(cursor, >fb);
+   igt_plane_set_size(cursor, data->fb_w, data->fb_h);
+}
+
+static void cursor_disable(data_t *data)
+{
+   igt_output_t *output = data->output;
+   igt_plane_t *cursor;
+
+   cursor = igt_output_get_plane_type(output, DRM_PLANE_TYPE_CURSOR);
+   igt_plane_set_fb(cursor, NULL);
+}
+
+static void overlay_enable(data_t *data)
+{
+   igt_output_t *output = data->output;
+   igt_plane_t *overlay;
+
+   overlay = igt_output_get_plane_type(output, DRM_PLANE_TYPE_OVERLAY);
+   igt_plane_set_fb(overlay, >fb);
+   igt_plane_set_size(overlay, data->fb_w, data->fb_h);
+}
+
+static void overlay_disable(data_t *data)
+{
+   igt_output_t *output = data->output;
+   igt_plane_t *overlay;
+
+   overlay = igt_output_get_plane_type(output, DRM_PLANE_TYPE_OVERLAY);
+   igt_plane_set_fb(overlay, NULL);
+}
+
+static void create_fb(data_t *data)
+{
+   uint32_t fb_id;
+
+   fb_id = igt_create_color_fb(data->drm_fd, data->fb_w, data->fb_h,
+   DRM_FORMAT_ARGB,
+   LOCAL_DRM_FORMAT_MOD_NONE,
+   0.5, 0.5, 0.5,
+   >fb);
+   igt_assert(fb_id);
+}
+
+static void prepare_crtc(data_t *data, igt_output_t *output, int w, int h)
+{
+   drmModeModeInfo *mode;
+   igt_display_t *display = >display;
+   igt_plane_t *primary;
+
+   /* select the pipe we want to use */
+   igt_output_set_pipe(output, data->pipe);
+   cursor_disable(data);
+
+   /* create and set the primary plane fb */
+   mode = igt_output_get_mode(output);
+   igt_create_color_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
+   DRM_FORMAT_XRGB,
+   LOCAL_DRM_FORMAT_MOD_NONE,
+   0.0, 0.0, 0.0,
+   >primary_fb);
+
+   primary = igt_output_get_plane_type(output, DRM_PLANE_TYPE_PRIMARY);
+   igt_plane_set_fb(primary, >primary_fb);
+
+   igt_display_commit(display);
+
+   /* create the pipe_crc object for this pipe */
+   if (data->pipe_crc)
+   igt_pipe_crc_free(data->pipe_crc);
+
+   data->pipe_crc = igt_pipe_crc_new(data->drm_fd, data->pipe,
+ INTEL_PIPE_CRC_SOURCE_AUTO);
+
+   data->fb_w = w;
+   data->fb_h = h;
+   create_fb(data);
+
+   /* make sure cursor is disabled */
+   cursor_disable(data);
+   igt_wait_for_vblank(data->drm_fd, data->pipe);
+}
+
+static void do_single_test(data_t *data)
+{
+   igt_display_t *display = >display;
+   igt_pipe_crc_t *pipe_crc = data->pipe_crc;
+   igt_crc_t cursor_crc, overlay_crc;
+   igt_plane_t *cursor, *overlay;
+
+   cursor_enable(data);
+   cursor = igt_output_get_plane_type(data->output, DRM_PLANE_TYPE_CURSOR);
+   igt_plane_set_position(cursor, 0, 0);
+   igt_display_commit(display);
+   igt_wait_for_vblank(data->drm_fd, data->pipe);
+   igt_pipe_crc_collect_crc(pipe_crc, _crc);
+
+   cursor_disable(data);
+   overlay_enable(data);
+   overlay = igt_output_get_pla

Re: [Intel-gfx] [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk workaround

[Ander Conselvan De Oliveira]

On Tue, 2017-04-04 at 10:27 +, Chauhan, Madhav wrote:
> > -Original Message-
> > From: Nikula, Jani
> > Sent: Tuesday, April 4, 2017 3:48 PM
> > To: Ander Conselvan De Oliveira <conselv...@gmail.com>; intel-
> > g...@lists.freedesktop.org
> > Cc: Chauhan, Madhav <madhav.chau...@intel.com>; Ville Syrjälä
> > <ville.syrj...@linux.intel.com>
> > Subject: Re: [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk
> > workaround
> > 
> > On Tue, 04 Apr 2017, Ander Conselvan De Oliveira <conselv...@gmail.com>
> > wrote:
> > > On Tue, 2017-04-04 at 11:40 +0300, Jani Nikula wrote:
> > > > On Tue, 04 Apr 2017, Ander Conselvan De Oliveira
> > 
> > <conselv...@gmail.com> wrote:
> > > > > On Tue, 2017-04-04 at 11:15 +0300, Jani Nikula wrote:
> > > > > > From: Madhav Chauhan <madhav.chau...@intel.com>
> > > > > > 
> > > > > > As per BSPEC, valid cdclk values for glk are 79.2, 158.4, 316.8 Mhz.
> > > > > > Practically we can achive only 99% of these cdclk values (HW team
> > > > > > checking on this). So cdclk should be calculated for the given
> > > > > > pixclk as per that otherwise it may lead to screen corruption for 
> > > > > > some
> > 
> > scenarios.
> > > > > > 
> > > > > > v2: Rebased to new CDLCK code framework
> > > > > > v3: Addressed review comments from Ander/Jani
> > > > > > - Add comment in code about 99% usage of CDCLK
> > > > > > - Calculate max dot clock as well with 99% limit
> > > > > > v4 by Jani:
> > > > > > - drop superfluous whitespace change
> > > > > > - rewrite code comments to clarify
> > > > > > 
> > > > > > Cc: Ander Conselvan de Oliveira
> > > > > > <ander.conselvan.de.olive...@intel.com>
> > > > > > Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
> > > > > > Signed-off-by: Madhav Chauhan <madhav.chau...@intel.com>
> > > > > > Signed-off-by: Jani Nikula <jani.nik...@intel.com>
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/intel_cdclk.c | 16 +---
> > > > > >  1 file changed, 13 insertions(+), 3 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
> > > > > > b/drivers/gpu/drm/i915/intel_cdclk.c
> > > > > > index dd3ad52b7dfe..763010f8ad89 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_cdclk.c
> > > > > > +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> > > > > > @@ -1071,9 +1071,15 @@ static int bxt_calc_cdclk(int max_pixclk)
> > > > > > 
> > > > > >  static int glk_calc_cdclk(int max_pixclk)  {
> > > > > > -   if (max_pixclk > 2 * 158400)
> > > > > > +   /*
> > > > > > +* FIXME: Avoid using a pixel clock that is more than 99% of 
> > > > > > the cdclk
> > > > > > +* as a temporary workaround. Use a higher cdclk instead. (Note
> > > > > > +that
> > > > > 
> > > > > Temporary workaround for what? Neither the comment nor the commit
> > > > > message explicitly lists the scenario that triggers this issue.
> > > > 
> > > > Frankly I did not know what to write.
> > > 
> > > 
> > > > There are issues with pixel clocks
> > > > near cdclk that shouldn't happen. People are looking into this, but
> > > > in the mean time dodge the issues by using higher cdclk. The issue
> > > > should not be encoder specific, but in practice this has only been
> > > > seen with DSI because there were some modes with pixel clocks that
> > > > are near the cdclk.
> > > 
> > > The above plus the model number of the DSI panel with which the issue
> > > has been seen would be good enough IMO.
> > 
> > Madhav?
> 
> Issue is generic (valid for DP/HDMI) not just MIPI DSI specific. Particular 
> DSI panel 
> exposing this issue as described below:
> 1. For  panel (19X12) required pixclk is 157100 KHZ
> 2. glk_calc_cdclk returns 79200 KHZ for this pixclk. For 2PPC it will be 
> 158400 KHZ
> 3. Practically 100% of the cdclk can’t be achieved, so 99% of 158400 KHZ  = 
> 156816 which is less than the desired pixlclk.
>  This cau

Re: [Intel-gfx] [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk workaround

[Ander Conselvan De Oliveira]

On Tue, 2017-04-04 at 11:40 +0300, Jani Nikula wrote:
> On Tue, 04 Apr 2017, Ander Conselvan De Oliveira <conselv...@gmail.com> wrote:
> > On Tue, 2017-04-04 at 11:15 +0300, Jani Nikula wrote:
> > > From: Madhav Chauhan <madhav.chau...@intel.com>
> > > 
> > > As per BSPEC, valid cdclk values for glk are 79.2, 158.4, 316.8 Mhz.
> > > Practically we can achive only 99% of these cdclk values (HW team
> > > checking on this). So cdclk should be calculated for the given pixclk as
> > > per that otherwise it may lead to screen corruption for some scenarios.
> > > 
> > > v2: Rebased to new CDLCK code framework
> > > v3: Addressed review comments from Ander/Jani
> > > - Add comment in code about 99% usage of CDCLK
> > > - Calculate max dot clock as well with 99% limit
> > > v4 by Jani:
> > > - drop superfluous whitespace change
> > > - rewrite code comments to clarify
> > > 
> > > Cc: Ander Conselvan de Oliveira <ander.conselvan.de.olive...@intel.com>
> > > Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
> > > Signed-off-by: Madhav Chauhan <madhav.chau...@intel.com>
> > > Signed-off-by: Jani Nikula <jani.nik...@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/intel_cdclk.c | 16 +---
> > >  1 file changed, 13 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> > > b/drivers/gpu/drm/i915/intel_cdclk.c
> > > index dd3ad52b7dfe..763010f8ad89 100644
> > > --- a/drivers/gpu/drm/i915/intel_cdclk.c
> > > +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> > > @@ -1071,9 +1071,15 @@ static int bxt_calc_cdclk(int max_pixclk)
> > >  
> > >  static int glk_calc_cdclk(int max_pixclk)
> > >  {
> > > - if (max_pixclk > 2 * 158400)
> > > + /*
> > > +  * FIXME: Avoid using a pixel clock that is more than 99% of the cdclk
> > > +  * as a temporary workaround. Use a higher cdclk instead. (Note that
> > 
> > Temporary workaround for what? Neither the comment nor the commit message
> > explicitly lists the scenario that triggers this issue.
> 
> Frankly I did not know what to write. 


> There are issues with pixel clocks
> near cdclk that shouldn't happen. People are looking into this, but in
> the mean time dodge the issues by using higher cdclk. The issue should
> not be encoder specific, but in practice this has only been seen with
> DSI because there were some modes with pixel clocks that are near the
> cdclk.

The above plus the model number of the DSI panel with which the issue has been
seen would be good enough IMO.

Ander


> > With that fixed,
> > 
> > Reviewed-by: Ander Conselvan de Oliveira <conselv...@gmail.com>
> > 
> > > +  * intel_compute_max_dotclk() limits the max pixel clock to 99% of max
> > > +  * cdclk.)
> > > +  */
> > > + if (max_pixclk > DIV_ROUND_UP(2 * 158400 * 99, 100))
> > >   return 316800;
> > > - else if (max_pixclk > 2 * 79200)
> > > + else if (max_pixclk > DIV_ROUND_UP(2 * 79200 * 99, 100))
> > >   return 158400;
> > >   else
> > >   return 79200;
> > > @@ -1664,7 +1670,11 @@ static int intel_compute_max_dotclk(struct 
> > > drm_i915_private *dev_priv)
> > >   int max_cdclk_freq = dev_priv->max_cdclk_freq;
> > >  
> > >   if (IS_GEMINILAKE(dev_priv))
> > > - return 2 * max_cdclk_freq;
> > > + /*
> > > +  * FIXME: Limiting to 99% as a temporary workaround. See
> > > +  * glk_calc_cdclk() for details.
> > > +  */
> > > + return 2 * max_cdclk_freq * 99 / 100;
> > >   else if (INTEL_INFO(dev_priv)->gen >= 9 ||
> > >IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> > >   return max_cdclk_freq;
> 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk workaround

[Ander Conselvan De Oliveira]

On Tue, 2017-04-04 at 11:15 +0300, Jani Nikula wrote:
> From: Madhav Chauhan <madhav.chau...@intel.com>
> 
> As per BSPEC, valid cdclk values for glk are 79.2, 158.4, 316.8 Mhz.
> Practically we can achive only 99% of these cdclk values (HW team
> checking on this). So cdclk should be calculated for the given pixclk as
> per that otherwise it may lead to screen corruption for some scenarios.
> 
> v2: Rebased to new CDLCK code framework
> v3: Addressed review comments from Ander/Jani
> - Add comment in code about 99% usage of CDCLK
> - Calculate max dot clock as well with 99% limit
> v4 by Jani:
> - drop superfluous whitespace change
> - rewrite code comments to clarify
> 
> Cc: Ander Conselvan de Oliveira <ander.conselvan.de.olive...@intel.com>
> Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
> Signed-off-by: Madhav Chauhan <madhav.chau...@intel.com>
> Signed-off-by: Jani Nikula <jani.nik...@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_cdclk.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index dd3ad52b7dfe..763010f8ad89 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -1071,9 +1071,15 @@ static int bxt_calc_cdclk(int max_pixclk)
>  
>  static int glk_calc_cdclk(int max_pixclk)
>  {
> - if (max_pixclk > 2 * 158400)
> + /*
> +  * FIXME: Avoid using a pixel clock that is more than 99% of the cdclk
> +  * as a temporary workaround. Use a higher cdclk instead. (Note that

Temporary workaround for what? Neither the comment nor the commit message
explicitly lists the scenario that triggers this issue.

With that fixed,

Reviewed-by: Ander Conselvan de Oliveira <conselv...@gmail.com>

> +  * intel_compute_max_dotclk() limits the max pixel clock to 99% of max
> +  * cdclk.)
> +  */
> + if (max_pixclk > DIV_ROUND_UP(2 * 158400 * 99, 100))
>   return 316800;
> - else if (max_pixclk > 2 * 79200)
> + else if (max_pixclk > DIV_ROUND_UP(2 * 79200 * 99, 100))
>   return 158400;
>   else
>   return 79200;
> @@ -1664,7 +1670,11 @@ static int intel_compute_max_dotclk(struct 
> drm_i915_private *dev_priv)
>   int max_cdclk_freq = dev_priv->max_cdclk_freq;
>  
>   if (IS_GEMINILAKE(dev_priv))
> - return 2 * max_cdclk_freq;
> + /*
> +  * FIXME: Limiting to 99% as a temporary workaround. See
> +  * glk_calc_cdclk() for details.
> +  */
> + return 2 * max_cdclk_freq * 99 / 100;
>   else if (INTEL_INFO(dev_priv)->gen >= 9 ||
>IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
>   return max_cdclk_freq;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] lib/dummyload: Handle timeout in a new thread instead of signal handler

[Ander Conselvan De Oliveira]

On Mon, 2017-03-27 at 12:23 +0100, Chris Wilson wrote:
> On Mon, Mar 27, 2017 at 02:08:28PM +0300, Ander Conselvan de Oliveira wrote:
> > Currently, the main thread needs to wakeup to run the signal handler
> > that ends a spin batch. When testing whether a function call succesfully
> > waits for a batch to complete, this behavior is undesired. It actually
> > invalidates the test.
> > 
> > Fix this by spawning a new thread to handle the timeout.
> > 
> > v2: Get rid of mutexes. (Chris)
> > Cc: Chris Wilson <ch...@chris-wilson.co.uk>
> > Signed-off-by: Ander Conselvan de Oliveira 
> > <ander.conselvan.de.olive...@intel.com>
> 
> Lvgtm,
> Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk>

Patch pushed to master. Thanks for reviewing.


> I hoping that this isn't implemented as a signal to the parent thread... :)

At least glibc creates a separate thread for this:

https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/timer_c
reate.c;h=48a703c0651e929f12feb4f194675bcf71694981;hb=HEAD#l100

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

[Intel-gfx] [PATCH i-g-t] lib/dummyload: Handle timeout in a new thread instead of signal handler

[Ander Conselvan de Oliveira]

Currently, the main thread needs to wakeup to run the signal handler
that ends a spin batch. When testing whether a function call succesfully
waits for a batch to complete, this behavior is undesired. It actually
invalidates the test.

Fix this by spawning a new thread to handle the timeout.

v2: Get rid of mutexes. (Chris)
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
---
 lib/igt_dummyload.c | 45 ++---
 lib/igt_dummyload.h |  1 -
 2 files changed, 6 insertions(+), 40 deletions(-)

diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index 019c1fb..b25e023 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -174,27 +174,11 @@ igt_spin_batch_new(int fd, int engine, unsigned int 
dep_handle)
return spin;
 }
 
-static void clear_sig_handler(int sig)
+static void notify(union sigval arg)
 {
-   struct sigaction act;
+   igt_spin_t *spin = arg.sival_ptr;
 
-   memset(, 0, sizeof(act));
-   act.sa_handler = SIG_DFL;
-   igt_assert(sigaction(sig, , NULL) == 0);
-}
-
-static void sig_handler(int sig, siginfo_t *info, void *arg)
-{
-   struct igt_spin *iter;
-
-   igt_list_for_each(iter, _list, link) {
-   if (iter->signo == info->si_signo) {
-   igt_spin_batch_end(iter);
-   return;
-   }
-   }
-
-   clear_sig_handler(sig);
+   igt_spin_batch_end(spin);
 }
 
 /**
@@ -208,10 +192,8 @@ static void sig_handler(int sig, siginfo_t *info, void 
*arg)
  */
 void igt_spin_batch_set_timeout(igt_spin_t *spin, int64_t ns)
 {
-   static int spin_signo = 48; /* Midpoint of SIGRTMIN, SIGRTMAX */
timer_t timer;
struct sigevent sev;
-   struct sigaction act, oldact;
struct itimerspec its;
 
igt_assert(ns > 0);
@@ -220,25 +202,13 @@ void igt_spin_batch_set_timeout(igt_spin_t *spin, int64_t 
ns)
 
igt_assert(!spin->timer);
 
-   /* SIGRTMAX is used by valgrind, SIGRTMAX - 1 by igt_fork_hang_detector 
*/
-   if (spin_signo >= SIGRTMAX - 2)
-   spin_signo = SIGRTMIN;
-   spin->signo = ++spin_signo;
-
memset(, 0, sizeof(sev));
-   sev.sigev_notify = SIGEV_SIGNAL | SIGEV_THREAD_ID;
-   sev.sigev_notify_thread_id = gettid();
-   sev.sigev_signo = spin->signo;
+   sev.sigev_notify = SIGEV_THREAD;
+   sev.sigev_value.sival_ptr = spin;
+   sev.sigev_notify_function = notify;
igt_assert(timer_create(CLOCK_MONOTONIC, , ) == 0);
igt_assert(timer);
 
-   memset(, 0, sizeof(oldact));
-   memset(, 0, sizeof(act));
-   act.sa_sigaction = sig_handler;
-   act.sa_flags = SA_SIGINFO;
-   igt_assert(sigaction(spin->signo, , ) == 0);
-   igt_assert(oldact.sa_sigaction == NULL);
-
memset(, 0, sizeof(its));
its.it_value.tv_sec = ns / NSEC_PER_SEC;
its.it_value.tv_nsec = ns % NSEC_PER_SEC;
@@ -260,9 +230,6 @@ void igt_spin_batch_end(igt_spin_t *spin)
 
*spin->batch = MI_BATCH_BUFFER_END;
__sync_synchronize();
-
-   if (spin->signo)
-   clear_sig_handler(spin->signo);
 }
 
 /**
diff --git a/lib/igt_dummyload.h b/lib/igt_dummyload.h
index 2adfadf..41125e3 100644
--- a/lib/igt_dummyload.h
+++ b/lib/igt_dummyload.h
@@ -33,7 +33,6 @@
 typedef struct igt_spin {
unsigned int handle;
timer_t timer;
-   int signo;
struct igt_list link;
uint32_t *batch;
 } igt_spin_t;
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t] lib/dummyload: Handle timeout in a new thread instead of signal handler

[Ander Conselvan de Oliveira]

Currently, the main thread needs to wakeup to run the signal handler
that ends a spin batch. When testing whether a function call succesfully
waits for a batch to complete, this behavior is undesired. It actually
invalidates the test.

Fix this by spawning a new thread to handle the timeout.

Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
---
 lib/igt_dummyload.c | 55 +
 lib/igt_dummyload.h |  3 ++-
 2 files changed, 19 insertions(+), 39 deletions(-)

diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index 019c1fb..38b1930 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -24,6 +24,7 @@
 
 #include "igt.h"
 #include "igt_dummyload.h"
+#include 
 #include 
 #include 
 #include 
@@ -166,6 +167,8 @@ igt_spin_batch_new(int fd, int engine, unsigned int 
dep_handle)
spin = calloc(1, sizeof(struct igt_spin));
igt_assert(spin);
 
+   pthread_mutex_init(>mutex, NULL);
+
emit_recursive_batch(spin, fd, engine, dep_handle);
igt_assert(gem_bo_busy(fd, spin->handle));
 
@@ -174,27 +177,11 @@ igt_spin_batch_new(int fd, int engine, unsigned int 
dep_handle)
return spin;
 }
 
-static void clear_sig_handler(int sig)
-{
-   struct sigaction act;
-
-   memset(, 0, sizeof(act));
-   act.sa_handler = SIG_DFL;
-   igt_assert(sigaction(sig, , NULL) == 0);
-}
-
-static void sig_handler(int sig, siginfo_t *info, void *arg)
+static void notify(union sigval arg)
 {
-   struct igt_spin *iter;
+   igt_spin_t *spin = arg.sival_ptr;
 
-   igt_list_for_each(iter, _list, link) {
-   if (iter->signo == info->si_signo) {
-   igt_spin_batch_end(iter);
-   return;
-   }
-   }
-
-   clear_sig_handler(sig);
+   igt_spin_batch_end(spin);
 }
 
 /**
@@ -208,43 +195,33 @@ static void sig_handler(int sig, siginfo_t *info, void 
*arg)
  */
 void igt_spin_batch_set_timeout(igt_spin_t *spin, int64_t ns)
 {
-   static int spin_signo = 48; /* Midpoint of SIGRTMIN, SIGRTMAX */
timer_t timer;
struct sigevent sev;
-   struct sigaction act, oldact;
struct itimerspec its;
 
+   pthread_mutex_lock(>mutex);
+
igt_assert(ns > 0);
if (!spin)
return;
 
igt_assert(!spin->timer);
 
-   /* SIGRTMAX is used by valgrind, SIGRTMAX - 1 by igt_fork_hang_detector 
*/
-   if (spin_signo >= SIGRTMAX - 2)
-   spin_signo = SIGRTMIN;
-   spin->signo = ++spin_signo;
-
memset(, 0, sizeof(sev));
-   sev.sigev_notify = SIGEV_SIGNAL | SIGEV_THREAD_ID;
-   sev.sigev_notify_thread_id = gettid();
-   sev.sigev_signo = spin->signo;
+   sev.sigev_notify = SIGEV_THREAD;
+   sev.sigev_value.sival_ptr = spin;
+   sev.sigev_notify_function = notify;
igt_assert(timer_create(CLOCK_MONOTONIC, , ) == 0);
igt_assert(timer);
 
-   memset(, 0, sizeof(oldact));
-   memset(, 0, sizeof(act));
-   act.sa_sigaction = sig_handler;
-   act.sa_flags = SA_SIGINFO;
-   igt_assert(sigaction(spin->signo, , ) == 0);
-   igt_assert(oldact.sa_sigaction == NULL);
-
memset(, 0, sizeof(its));
its.it_value.tv_sec = ns / NSEC_PER_SEC;
its.it_value.tv_nsec = ns % NSEC_PER_SEC;
igt_assert(timer_settime(timer, 0, , NULL) == 0);
 
spin->timer = timer;
+
+   pthread_mutex_unlock(>mutex);
 }
 
 /**
@@ -258,11 +235,12 @@ void igt_spin_batch_end(igt_spin_t *spin)
if (!spin)
return;
 
+   pthread_mutex_lock(>mutex);
+
*spin->batch = MI_BATCH_BUFFER_END;
__sync_synchronize();
 
-   if (spin->signo)
-   clear_sig_handler(spin->signo);
+   pthread_mutex_unlock(>mutex);
 }
 
 /**
@@ -287,6 +265,7 @@ void igt_spin_batch_free(int fd, igt_spin_t *spin)
gem_munmap(spin->batch, BATCH_SIZE);
 
gem_close(fd, spin->handle);
+   pthread_mutex_destroy(>mutex);
free(spin);
 }
 
diff --git a/lib/igt_dummyload.h b/lib/igt_dummyload.h
index 2adfadf..8fdc3fe 100644
--- a/lib/igt_dummyload.h
+++ b/lib/igt_dummyload.h
@@ -31,11 +31,12 @@
 #include "igt_aux.h"
 
 typedef struct igt_spin {
+   pthread_mutex_t mutex;
unsigned int handle;
timer_t timer;
-   int signo;
struct igt_list link;
uint32_t *batch;
+
 } igt_spin_t;
 
 igt_spin_t *igt_spin_batch_new(int fd, int engine, unsigned int dep_handle);
-- 
2.9.3

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

Re: [Intel-gfx] [i-g-t PATCH 2/2] igt/kms_flip: Fix set_dpms called with an idle bo

[Ander Conselvan De Oliveira]

On Thu, 2016-12-01 at 11:23 +, Chris Wilson wrote:
> On Thu, Dec 01, 2016 at 12:58:46PM +0200, Abdiel Janulgue wrote:
> > Signed-off-by: Abdiel Janulgue 

How is the bug that this commit fixes triggered? Reverting this change seems to
fix [1] which, if I understand correctly, is caused by the atomic commit of
set_dpms() to be waiting for the dummy write to the frontbuffer complete, while 
the spin batch never ends since the test is blocked and so doesn't handle the
timer signal. 


[1] https://bugs.freedesktop.org/show_bug.cgi?id=100261

Thanks,
Ander

> > ---
> >  tests/kms_flip.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/tests/kms_flip.c b/tests/kms_flip.c
> > index 289335a..f744b3d 100644
> > --- a/tests/kms_flip.c
> > +++ b/tests/kms_flip.c
> > @@ -757,9 +757,9 @@ static unsigned int run_test_step(struct test_output *o)
> >  
> > if (o->flags & TEST_DPMS) {
> > if (spin_rcs)
> > -   igt_spin_batch_end(spin_rcs);
> > +   igt_spin_batch_set_timeout(spin_rcs, NSEC_PER_SEC);
> > if (spin_bcs)
> > -   igt_spin_batch_end(spin_bcs);
> > +   igt_spin_batch_set_timeout(spin_bcs, NSEC_PER_SEC);
> > set_dpms(o, DRM_MODE_DPMS_ON);
> > }
> 
> Reviewed-by: Chris Wilson 
> -Chris
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Fix SKL cursor watermarks

[Ander Conselvan De Oliveira]

On Wed, 2017-03-22 at 10:01 +0100, Maarten Lankhorst wrote:
> Op 14-03-17 om 16:10 schreef ville.syrj...@linux.intel.com:
> > From: Ville Syrjälä <ville.syrj...@linux.intel.com>
> > 
> > Use intel_wm_plane_visible() to determine cursor visibility for SKL+
> > also. Previously SKL+ would check the actual visibility which now
> > conflicts with the assumptions in intel_legacy_cursor_update().
> > 
> > We also change SKL+ to compute the cursor watermarks based on the
> > unclipped cursor size, just as we do on all the other platforms.
> > Using the clipped size could now result in garbage results.
> > 
> > Testcase: igt/kms_chv_cursor_fail
> > Fixes: a5509abda48e ("drm/i915: Fix legacy cursor vs. watermarks for 
> > ILK-BDW")
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100195
> > Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
> 
> For patch 1 & 2:
> 
> Reviewed-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> 
> Should be the right way to fix it. :)

In intel_legacy_cursor_update(), I see the comment below,

/*
 * If any parameters change that may affect watermarks,
 * take the slowpath. Only changing fb or position should be
 * in the fastpath.
 */

followed by a bunch of checks on the plane size and fb. My understanding is that
the bug was caused by those assumptions being out of sync with the actual
watermark code. So IMO, a more proper way to fix this would be to have
intel_legacy_cursor_update() call into watermark code to ask if it can proceed
or not, instead of making assumptions of what can cause watermarks to change.

But since the duplicated assumptions were there before, this fix doesn't make
the overall situation any worse.

Acked-by: Ander Conselvan de Oliveira <conselv...@gmail.com>

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix legacy cursor vs. watermarks for ILK-BDW

[Ander Conselvan De Oliveira]

On Thu, 2017-03-02 at 16:58 +0200, Ville Syrjälä wrote:
> On Sat, Feb 25, 2017 at 04:31:04PM +0100, Maarten Lankhorst wrote:
> > Op 24-02-17 om 14:11 schreef Ville Syrjälä:
> > > On Mon, Feb 20, 2017 at 03:30:58PM +0100, Maarten Lankhorst wrote:
> > > > Op 20-02-17 om 14:38 schreef Ville Syrjälä:
> > > > > On Mon, Feb 20, 2017 at 10:04:06AM +0100, Maarten Lankhorst wrote:
> > > > > > Op 17-02-17 om 16:01 schreef ville.syrj...@linux.intel.com:
> > > > > > > From: Ville Syrjälä 
> > > > > > > 
> > > > > > > In order to make cursor updates actually safe wrt. watermark 
> > > > > > > programming
> > > > > > > we have to clear the legacy_cursor_update flag in the atomic 
> > > > > > > state. That
> > > > > > > will cause the regular atomic update path to do the necessary 
> > > > > > > vblank
> > > > > > > wait after the plane update if needed, otherwise the vblank wait 
> > > > > > > would
> > > > > > > be skipped and we'd feed the optimal watermarks to the hardware 
> > > > > > > before
> > > > > > > the plane update has actually happened.
> > > > > > > 
> > > > > > > To make the slow vs. fast path determination in
> > > > > > > intel_legacy_cursor_update() a little simpler we can ignore the 
> > > > > > > actual
> > > > > > > visibility of the plane (which can only get computed once we've 
> > > > > > > already
> > > > > > > chosen out path) and instead we simply check whether the fb is 
> > > > > > > being
> > > > > > > set or cleared by the user. This means a fully clipped but 
> > > > > > > logically
> > > > > > > visible cursor will be considered visible as far as watermark
> > > > > > > programming is concerned. We can do that for the cursor since 
> > > > > > > it's a
> > > > > > > fixed size plane and the clipped size doesn't play a role in the
> > > > > > > watermark computation.
> > > > > > > 
> > > > > > > This should fix underruns that can occur when the cursor gets
> > > > > > > enable/disabled or the size gets changed. Hopefully it's good 
> > > > > > > enough
> > > > > > > that only pure cursor movement and flips go through unthrottled.
> > > > > > > 
> > > > > > > Cc: Maarten Lankhorst 
> > > > > > > Cc: Daniel Vetter 
> > > > > > > Cc: Uwe Kleine-König 
> > > > > > > Reported-by: Uwe Kleine-König 
> > > > > > > Fixes: f79f26921ee1 ("drm/i915: Add a cursor hack to allow 
> > > > > > > converting legacy page flip to atomic, v3.")
> > > > > > > Signed-off-by: Ville Syrjälä 
> > > > > > > ---
> > > > > > >  drivers/gpu/drm/i915/intel_display.c | 29 
> > > > > > > ++---
> > > > > > >  drivers/gpu/drm/i915/intel_pm.c  | 20 
> > > > > > >  2 files changed, 30 insertions(+), 19 deletions(-)
> > > > > > > 
> > > > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > > > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > > > > index b05d9c85384b..356ac04093e8 100644
> > > > > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > > > > @@ -13031,6 +13031,17 @@ static int intel_atomic_commit(struct 
> > > > > > > drm_device *dev,
> > > > > > >   struct drm_i915_private *dev_priv = to_i915(dev);
> > > > > > >   int ret = 0;
> > > > > > >  
> > > > > > > + /*
> > > > > > > +  * The intel_legacy_cursor_update() fast path takes care
> > > > > > > +  * of avoiding the vblank waits for simple cursor
> > > > > > > +  * movement and flips. For cursor on/off and size changes,
> > > > > > > +  * we want to perform the vblank waits so that watermark
> > > > > > > +  * updates happen during the correct frames. Gen9+ have
> > > > > > > +  * double buffered watermarks and so shouldn't need this.
> > > > > > > +  */
> > > > > > > + if (INTEL_GEN(dev_priv) < 9)
> > > > > > > + state->legacy_cursor_update = false;
> > > > > > 
> > > > > > Could we perhaps add a check in ilk_compute_pipe_wm which unsets 
> > > > > > the legacy_cursor_update flag so we keep things unsynced as much as 
> > > > > > possible?
> > > > > 
> > > > > I'd have to sprinkle that stuff everywhere but the SKL code
> > > > > eventually. Seems a little pointless when I can just plop it
> > > > > there.
> > > > 
> > > > Ah indeed. Lets hope it doesn't slow things down too much.
> > > > > > >   ret = drm_atomic_helper_setup_commit(state, nonblock);
> > > > > > >   if (ret)
> > > > > > >   return ret;
> > > > > > > @@ -13455,8 +13466,7 @@ intel_legacy_cursor_update(struct 
> > > > > > > drm_plane *plane,
> > > > > > >   old_plane_state->src_h != src_h ||
> > > > > > >   old_plane_state->crtc_w != crtc_w ||
> > > > > > >   old_plane_state->crtc_h != crtc_h ||
> > > > > > > - !old_plane_state->visible ||
> > > > > > > - old_plane_state->fb->modifier != fb->modifier)
> > > > > > > + !old_plane_state->fb != !fb)
> > > > > > >   goto 

[Intel-gfx] [PATCH v2] drm/i915/glk: Enable pooled EUs for Geminilake

[Ander Conselvan de Oliveira]

Geminilake also supports pooled EUs. Enable it.

It is unclear if the recommendation to disable it for 2x6 configurations
from commit e015dd69b2cf ("drm/i915/bxt: Add WaEnablePooledEuFor2x6")
should also apply to GLK, but it is applied anyway to be on the safe
side. That restriction can be lifted later if determined not to impact
performance.

The extra restriction should not impact user space either. The only user
space that uses this feature is Beignet, and it only does so for 3x6
devices. See See Beignet's commit 6901899ec90a ("Runtime: set the sub
slice according to kernel pooled EU configure.").

v2: Improve commit message. (Mika, Roy)

Cc: Arun Siluvery <arun.siluv...@intel.com>
Cc: Mika Kuoppala <mika.kuopp...@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Cc: Yang Rong <rong.r.y...@intel.com>
Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
---
 drivers/gpu/drm/i915/intel_device_info.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 9fc6ab7..7d01dfe 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -197,8 +197,10 @@ static void gen9_sseu_info_init(struct drm_i915_private 
*dev_priv)
IS_GEN9_LP(dev_priv) && sseu_subslice_total(sseu) > 1;
sseu->has_eu_pg = sseu->eu_per_subslice > 2;
 
-   if (IS_BROXTON(dev_priv)) {
+   if (IS_GEN9_LP(dev_priv)) {
 #define IS_SS_DISABLED(ss) (!(sseu->subslice_mask & BIT(ss)))
+   info->has_pooled_eu = hweight8(sseu->subslice_mask) == 3;
+
/*
 * There is a HW issue in 2x6 fused down parts that requires
 * Pooled EU to be enabled as a WA. The pool configuration
@@ -206,9 +208,8 @@ static void gen9_sseu_info_init(struct drm_i915_private 
*dev_priv)
 * doesn't affect if the device has all 3 subslices enabled.
 */
/* WaEnablePooledEuFor2x6:bxt */
-   info->has_pooled_eu = ((hweight8(sseu->subslice_mask) == 3) ||
-  (hweight8(sseu->subslice_mask) == 2 &&
-   INTEL_REVID(dev_priv) < BXT_REVID_C0));
+   info->has_pooled_eu |= (hweight8(sseu->subslice_mask) == 2 &&
+   IS_BXT_REVID(dev_priv, 0, 
BXT_REVID_B_LAST));
 
sseu->min_eu_in_pool = 0;
if (info->has_pooled_eu) {
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH v3] drm: Add DPCD definitions for DP 1.4 DSC feature

[Ander Conselvan De Oliveira]

On Tue, 2017-03-14 at 13:01 -0700, Manasi Navare wrote:
> From: "Navare, Manasi D" 
> 
> Display stream compression is supported on DP 1.4 DP
> devices. This patch adds the corersponding DPCD
> register definitions for DSC.
> 
> v3:
> * Add some SHIFTS and MASKS for uniformity (Jani Nikula)
> v2:
> * Rebased on drm-tip
> 
> Signed-off-by: Manasi Navare 
> Cc: Jani Nikula 
> Cc: Paulo Zanoni 
> Cc: dri-de...@lists.freedesktop.org
> ---
>  include/drm/drm_dp_helper.h | 105 
> 
>  1 file changed, 105 insertions(+)
> 
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index c0bd0d7..e1fb04f 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -179,6 +179,111 @@
>  
>  #define DP_GUID  0x030   /* 1.2 */
>  
> +#define DP_DSC_SUPPORT  0x060   /* DP 1.4 */
> +# define DP_DSC_DECOMPRESSION_IS_SUPPORTED  (1 << 0)
> +
> +#define DP_DSC_REV  0x061
> +# define DP_DSC_MAJOR_MASK  (0xf << 0)
> +# define DP_DSC_MINOR_MASK  (0xf << 4)
> +# define DP_DSC_MAJOR_SHIFT 0
> +# define DP_DSC_MINOR_SHIFT 4
> +
> +#define DP_DSC_RC_BUF_BLK_SIZE  0x062
> +# define DP_DSC_RC_BUF_BLK_SIZE_1   0x0
> +# define DP_DSC_RC_BUF_BLK_SIZE_4   0x1
> +# define DP_DSC_RC_BUF_BLK_SIZE_16  0x2
> +# define DP_DSC_RC_BUF_BLK_SIZE_64  0x3
> +
> +#define DP_DSC_RC_BUF_SIZE  0x063
> +
> +#define DP_DSC_SLICE_CAP_1  0x064
> +# define DP_DSC_1_PER_DP_DSC_SINK   (1 << 0)
> +# define DP_DSC_2_PER_DP_DSC_SINK   (1 << 1)
> +# define DP_DSC_4_PER_DP_DSC_SINK   (1 << 3)
> +# define DP_DSC_6_PER_DP_DSC_SINK   (1 << 4)
> +# define DP_DSC_8_PER_DP_DSC_SINK   (1 << 5)
> +# define DP_DSC_10_PER_DP_DSC_SINK  (1 << 6)
> +# define DP_DSC_12_PER_DP_DSC_SINK  (1 << 7)
> +
> +#define DP_DSC_LINE_BUF_BIT_DEPTH   0x065
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_MASK (0xf << 0)
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_90x0
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_10   0x1
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_11   0x2
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_12   0x3
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_13   0x4
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_14   0x5
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_15   0x6
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_16   0x7
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_80x8
> +
> +#define DP_DSC_BLK_PREDICTION_SUPPORT   0x066
> +# define DP_DSC_BLK_PREDICTION_IS_SUPPORTED (1 << 0)
> +
> +#define DP_DSC_MAX_BITS_PER_PIXEL_LOW   0x067   /* eDP 1.4 */
> +
> +#define DP_DSC_MAX_BITS_PER_PIXEL_HI0x068   /* eDP 1.4 */
> +
> +#define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069
> +# define DP_DSC_RGB (1 << 0)
> +# define DP_DSC_YCbCr444(1 << 1)
> +# define DP_DSC_YCbCr422_Simple (1 << 2)
> +# define DP_DSC_YCbCr422_Native (1 << 3)
> +# define DP_DSC_YCbCr420_Native (1 << 4)
> +
> +#define DP_DSC_DEC_COLOR_DEPTH_CAP  0x06A
> +# define DP_DSC_8_BPC   (1 << 1)
> +# define DP_DSC_10_BPC  (1 << 2)
> +# define DP_DSC_12_BPC  (1 << 3)
> +
> +#define DP_DSC_PEAK_THROUGHPUT  0x06B
> +# define DP_DSC_THROUGHPUT_MODE_0_MASK  (0xf << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_SHIFT 0
> +# define DP_DSC_THROUGHPUT_MODE_0_340   (1 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_400   (2 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_450   (3 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_500   (4 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_550   (5 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_600   (6 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_650   (7 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_700   (8 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_750   (9 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_800   (10 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_850   (11 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_900   (12 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_950   (13 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_1000  (14 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_1_MASK  (0xf << 4)
> +# define DP_DSC_THROUGHPUT_MODE_1_SHIFT 4
> +# define DP_DSC_THROUGHPUT_MODE_1_340   (1 << 4)
> +# define DP_DSC_THROUGHPUT_MODE_1_400   (2 << 4)
> +# define DP_DSC_THROUGHPUT_MODE_1_450   (3 << 4)
> +# define DP_DSC_THROUGHPUT_MODE_1_500   (4 << 4)
> +# define DP_DSC_THROUGHPUT_MODE_1_550   (5 << 4)
> +# define DP_DSC_THROUGHPUT_MODE_1_600   (6 << 4)
> +# define DP_DSC_THROUGHPUT_MODE_1_650   (7 << 4)
> +# define 

Re: [Intel-gfx] [PATCH] drm/i915/glk: CDCLK calculation changes for glk

[Ander Conselvan De Oliveira]

On Thu, 2017-03-16 at 15:10 +0200, Jani Nikula wrote:
> On Thu, 16 Mar 2017, "Chauhan, Madhav"  wrote:
> > > -Original Message-
> > > From: Nikula, Jani
> > > Sent: Thursday, February 16, 2017 9:03 PM
> > > To: Chauhan, Madhav ; intel-
> > > g...@lists.freedesktop.org
> > > Cc: Conselvan De Oliveira, Ander ;
> > > Shankar, Uma ; Mukherjee, Indranil
> > > ; Sharma, Shashank
> > > ; Chauhan, Madhav
> > > ; ville.syrj...@linux.intel.com
> > > Subject: Re: [PATCH] drm/i915/glk: CDCLK calculation changes for glk
> > > 
> > > On Thu, 16 Feb 2017, Madhav Chauhan 
> > > wrote:
> > > > As per BSPEC, valid cdclk values for glk are 79.2, 158.4, 316.8 Mhz.
> > > > Practically we can achive only 99% of these cdclk values(HW team
> > > > checking on this). So cdclk should be calculated for the given pixclk
> > > > as per that otherwise it may lead to screen corruption for some 
> > > > scenarios.
> > > > 
> > > > v2: Rebased to new CDLCK code framework
> > > > 
> > > > Signed-off-by: Madhav Chauhan 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_cdclk.c | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
> > > > b/drivers/gpu/drm/i915/intel_cdclk.c
> > > > index d643c0c..834df68 100644
> > > > --- a/drivers/gpu/drm/i915/intel_cdclk.c
> > > > +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> > > > @@ -1071,9 +1071,9 @@ static int bxt_calc_cdclk(int max_pixclk)
> > > > 
> > > >  static int glk_calc_cdclk(int max_pixclk)  {
> > > > -   if (max_pixclk > 2 * 158400)
> > > > +   if (max_pixclk > DIV_ROUND_UP(2 * 158400 * 99, 100))
> > > 
> > > Where do we ensure we don't use pixel clock 312841..316800? Clearly we
> > > shouldn't use that because we can't guarantee it works, right?
> > 
> > Why do we need to ensure that ?? Can you please elaborate more on this?  
> > Here we are finding one of  the defined CDCLK value for a pixel clock
> 
> I probably had some great idea a month ago when I wrote that, but I can
> no longer remember what it was. :(

I'm not sure if that is what you meant, but if the hardware can't handle it,
intel_compute_max_dotclk() needs to take the 99% limitation into account too.
I.e., max dot clock would be .99 * 2 *  316800 = 627264.

Ander

> 
> BR,
> Jani.
> 
> 
> > > 
> > > Before we get the spec update to confirm what to do, I think we need a
> > > comment here explaining what's going on.
> > 
> > Will add the following comment, if that's fine, will send the rebased patch:
> > "For GLK platform, only 99% of the defined CDCLK value can be achieved 
> >   So calculate pixel clock on that basis"
> > 
> > Regards,
> > Madhav
> > > 
> > > BR,
> > > Jani.
> > > 
> > > > return 316800;
> > > > -   else if (max_pixclk > 2 * 79200)
> > > > +   else if (max_pixclk > DIV_ROUND_UP(2 * 79200 * 99, 100))
> > > > return 158400;
> > > > else
> > > > return 79200;
> > > 
> > > --
> > > Jani Nikula, Intel Open Source Technology Center
> 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/glk: Remove MODULE_FIRMWARE() tag from Geminilake's DMC

[Ander Conselvan de Oliveira]

Geminilake's DMC is not yet available in the linux-firmware repository.
To prevent userspace tools such as mkinitramfs to complain about
missing firmware, remove the MODULE_FIRMWARE() tag for now.

Fixes: dbb28b5c3d3c ("drm/i915/DMC/GLK: Load DMC on GLK")
Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
Cc: Anusha Srivatsa <anusha.sriva...@intel.com>
Cc: Daniel Vetter <daniel.vet...@intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <drm-intel-fi...@lists.freedesktop.org>
Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
Acked-by: Jani Nikula <jani.nik...@intel.com>
Link: 
http://patchwork.freedesktop.org/patch/msgid/20170306085651.14008-1-ander.conselvan.de.olive...@intel.com
(cherry picked from commit d9321a03efcda867b3a8c6327e01808516f0acd7)
---
 drivers/gpu/drm/i915/intel_csr.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 0085bc7..de219b7 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -35,7 +35,6 @@
  */
 
 #define I915_CSR_GLK "i915/glk_dmc_ver1_01.bin"
-MODULE_FIRMWARE(I915_CSR_GLK);
 #define GLK_CSR_VERSION_REQUIRED   CSR_VERSION(1, 1)
 
 #define I915_CSR_KBL "i915/kbl_dmc_ver1_01.bin"
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH i-g-t] kms_cursor_crc: Add a subtest with a 256x256 gradient cursor

[Ander Conselvan De Oliveira]

On Fri, 2017-03-10 at 12:27 +0200, Ander Conselvan De Oliveira wrote:
> On Fri, 2017-03-10 at 12:18 +0200, Ander Conselvan de Oliveira wrote:
> > Some of the kms_cursor_crc subtests where failing on Geminilake. The
> > root cause was an error on programming the pre-CSC gamma tables, which
> > led to small rounding errors that, although not sufficient to change the
> > image as captured at 8bpc with the Chamelium, were enough to generate a
> > different CRC. It is not clear why the rounding is different when the
> > cursor is enabled, but this was caught by chance, since the cursor would
> > only be exercised with limited color combinations.
> > 
> > To improve coverage, add a test that uses a gradient covering all
> > possible 8bit values for a channel.
> > 
> > Signed-off-by: Ander Conselvan de Oliveira 
> > <ander.conselvan.de.olive...@intel.com>
> > ---
> >  tests/kms_cursor_crc.c | 42 ++
> >  1 file changed, 38 insertions(+), 4 deletions(-)
> > 
> > diff --git a/tests/kms_cursor_crc.c b/tests/kms_cursor_crc.c
> > index 4851e18..0b232bf 100644
> > --- a/tests/kms_cursor_crc.c
> > +++ b/tests/kms_cursor_crc.c
> > @@ -87,6 +87,8 @@ static void draw_cursor(cairo_t *cr, int x, int y, int 
> > cw, int ch)
> > igt_paint_color_alpha(cr, x + wl, y + ht, wr, hb, 0.5, 0.5, 0.5, 1.0);
> >  }
> >  
> > +typedef void(*draw_cursor_cb)(cairo_t *cr, int x, int y, int cw, int ch);
> > +
> >  static void cursor_enable(data_t *data)
> >  {
> > igt_output_t *output = data->output;
> > @@ -107,7 +109,8 @@ static void cursor_disable(data_t *data)
> >  }
> >  
> >  
> > -static void do_single_test(data_t *data, int x, int y)
> > +static void do_single_test_with_cursor_cb(data_t *data, int x, int y,
> > + draw_cursor_cb cursor_cb)
> >  {
> > igt_display_t *display = >display;
> > igt_pipe_crc_t *pipe_crc = data->pipe_crc;
> > @@ -151,7 +154,7 @@ static void do_single_test(data_t *data, int x, int y)
> > igt_display_commit(display);
> >  
> > /* Now render the same in software and collect crc */
> > -   draw_cursor(cr, x, y, data->curw, data->curh);
> > +   cursor_cb(cr, x, y, data->curw, data->curh);
> > igt_display_commit(display);
> >  
> > igt_wait_for_vblank(data->drm_fd, data->pipe);
> > @@ -162,6 +165,11 @@ static void do_single_test(data_t *data, int x, int y)
> > igt_paint_color(cr, 0, 0, data->screenw, data->screenh, 0.0, 0.0, 0.0);
> >  }
> >  
> > +static void do_single_test(data_t *data, int x, int y)
> > +{
> > +   do_single_test_with_cursor_cb(data, x, y, draw_cursor);
> > +}
> > +
> >  static void do_fail_test(data_t *data, int x, int y, int expect)
> >  {
> > igt_display_t *display = >display;
> > @@ -386,7 +394,8 @@ static void run_test(data_t *data, void 
> > (*testfunc)(data_t *), int cursor_w, int
> > igt_require_f(valid_tests, "no valid crtc/connector combinations 
> > found\n");
> >  }
> >  
> > -static void create_cursor_fb(data_t *data, int cur_w, int cur_h)
> > +static void create_cursor_fb_with_cb(data_t *data, int cur_w, int cur_h,
> > +draw_cursor_cb cursor_cb)
> >  {
> > cairo_t *cr;
> > uint32_t fb_id;
> > @@ -406,10 +415,15 @@ static void create_cursor_fb(data_t *data, int cur_w, 
> > int cur_h)
> > igt_assert(fb_id);
> >  
> > cr = igt_get_cairo_ctx(data->drm_fd, >fb);
> > -   draw_cursor(cr, 0, 0, cur_w, cur_h);
> > +   cursor_cb(cr, 0, 0, cur_w, cur_h);
> > igt_assert(cairo_status(cr) == 0);
> >  }
> >  
> > +static void create_cursor_fb(data_t *data, int cur_w, int cur_h)
> > +{
> > +   create_cursor_fb_with_cb(data, cur_w, cur_h, draw_cursor);
> > +}
> > +
> >  static bool has_nonsquare_cursors(uint32_t devid)
> >  {
> > /*
> > @@ -506,6 +520,23 @@ static void test_rapid_movement(data_t *data)
> >  
> >  }
> >  
> > +static void draw_cursor_gradient(cairo_t *cr, int x, int y, int cw, int ch)
> > +{
> > +   cairo_set_antialias(cr, CAIRO_ANTIALIAS_NONE);
> > +   igt_paint_color_gradient(cr, x, y, cw, ch, 1.0, 1.0, 1.0);
> > +}
> > +
> > +static void test_cursor_colors(data_t *data)
> > +{
> > +   int cursor_w = data->curw;
> > +   int cursor_h = data->curh;
> > +
> > +   create_cursor_fb_with_cb(d

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/glk: Improve rounding caused by pre-CSC gamma tables

[Ander Conselvan De Oliveira]

On Fri, 2017-03-10 at 13:18 +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/glk: Improve rounding caused by pre-CSC gamma tables
> URL   : https://patchwork.freedesktop.org/series/21049/
> State : success

Pushed. Thanks for reviewing.

Ander

> 
> == Summary ==
> 
> Series 21049v1 drm/i915/glk: Improve rounding caused by pre-CSC gamma tables
> https://patchwork.freedesktop.org/api/1.0/series/21049/revisions/1/mbox/
> 
> fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
> time: 459s
> fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
> time: 610s
> fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
> time: 536s
> fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
> time: 596s
> fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
> time: 508s
> fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
> time: 504s
> fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time: 444s
> fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time: 436s
> fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
> time: 437s
> fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time: 508s
> fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time: 500s
> fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
> time: 479s
> fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time: 510s
> fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
> time: 591s
> fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
> time: 498s
> fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time: 558s
> fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
> time: 556s
> fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
> time: 426s
> 
> d8d69f76555feef19e3e4b601378446604d90da5 drm-tip: 2017y-03m-10d-11h-50m-04s 
> UTC integration manifest
> f2f76a8 drm/i915/glk: Improve rounding caused by pre-CSC gamma tables
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4134/
> ___
> 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 v10 5/6] drm/i915: enable scrambling

[Ander Conselvan De Oliveira]

On Mon, 2017-03-13 at 16:54 +0530, Shashank Sharma wrote:
> Geminilake platform sports a native HDMI 2.0 controller, and is
> capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
> mendates scrambling for these higher clocks, for reduced RF footprint.
> 
> This patch checks if the monitor supports scrambling, and if required,
> enables it during the modeset.
> 
> V2: Addressed review comments from Ville:
>  - Do not track scrambling status in DRM layer, track somewhere in
>driver like in intel_crtc_state.
>  - Don't talk to monitor at such a low layer, set monitor scrambling
>in intel_enable_ddi() before enabling the port.
> 
> V3: Addressed review comments from Jani
>  - In comments, function names, use "sink" instead of "monitor",
>so that the implementation could be close to the language of
>HDMI spec.
> 
> V4: Addressed review comment from Maarten
>  - scrambling -> hdmi_scrambling
>  - high_tmds_clock_ratio -> hdmi_high_tmds_clock_ratio
> 
> V5: Addressed review comments from Ville and Ander
>  - Do not modifiy the crtc_state after compute_config. Move all
>scrambling and tmds_clock_ratio calcutations to compute_config.
>  - While setting scrambling for source/sink, do not check the
>conditions again, just go by the crtc_state flags. This will
>simplyfy the condition checks.
> 
> V6: Addressed review comments from Ville
>  - Do not add IS_GLK check in disable/enable function, instead add it
>in compute_config, while setting state flags.
>  - Remove unnecessary paranthesis.
>  - Simplyfy handle_sink_scrambling function as suggested.
>  - Add readout code for scrambling status in get_ddi_config and add a
>check for the same in pipe_config_compare.
> 
> V7: Addressed review comments from Ander/Ville
>  - No separate function for source scrambling, make it inline
>  - Align the last line of the macro TRANS_DDI_HDMI_SCRAMBLING_MASK
>  - Do not add platform check while setting source scrambling
>  - Use pipe_config instead of crtc->config to set sink scrambling
>  - To readout scrambling status, Compare with SCRAMBLING_MASK
>not any of its bits
>  - Remove platform check in intel_pipe_config_compare while checking
>scrambling status
> 
> V8: Fixed mege conflict, Addressed review comments from Ander
>  - Remove the desciption/comment about scrambling fom the caller, move
>it to the function
>  - Move the IS_GLK check into scrambling function
>  - Fix alignment
> 
> V9: Fixed review comments from Ville, Ander
>  - Pass the scrambling state variables as bool input to the sink_scrambling
>function and let the disable call be unconditional.
>  - Fix alignments in function calls and debug messages.
>  - Add kernel doc for function intel_hdmi_handle_sink_scrambling
> 
> V10: Rebase
> Signed-off-by: Shashank Sharma <shashank.sha...@intel.com>

Reviewed-by: Ander Conselvan de Oliveira <conselv...@gmail.com>

> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  7 
>  drivers/gpu/drm/i915/intel_ddi.c | 23 +
>  drivers/gpu/drm/i915/intel_display.c |  3 ++
>  drivers/gpu/drm/i915/intel_drv.h | 10 ++
>  drivers/gpu/drm/i915/intel_hdmi.c| 63 
> 
>  5 files changed, 106 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 19d42e8..a1aae7a 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7831,7 +7831,14 @@ enum {
>  #define  TRANS_DDI_EDP_INPUT_B_ONOFF (5<<12)
>  #define  TRANS_DDI_EDP_INPUT_C_ONOFF (6<<12)
>  #define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC   (1<<8)
> +#define  TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7)
> +#define  TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
>  #define  TRANS_DDI_BFI_ENABLE(1<<4)
> +#define  TRANS_DDI_HIGH_TMDS_CHAR_RATE   (1<<4)
> +#define  TRANS_DDI_HDMI_SCRAMBLING   (1<<0)
> +#define  TRANS_DDI_HDMI_SCRAMBLING_MASK (TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE 
> \
> + | TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ \
> + | TRANS_DDI_HDMI_SCRAMBLING)
>  
>  /* DisplayPort Transport Control */
>  #define _DP_TP_CTL_A 0x64040
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index ee341ef..169d2b4 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1309,6 +1309,11 @@ void intel_ddi_enable_transcoder_func(const struct 
> intel_crtc_state *crtc_state)
>   temp |= TRANS_DDI_MODE_SELECT_HDMI;
>   

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove intel_ prefix from encoder variables in intel_ddi.c

[Ander Conselvan De Oliveira]

On Thu, 2017-03-09 at 17:17 +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Remove intel_ prefix from encoder variables in intel_ddi.c
> URL   : https://patchwork.freedesktop.org/series/20992/
> State : success

Pushed to drm-intel-next-queued. Thanks for the patch.

Ander

> 
> == Summary ==
> 
> Series 20992v1 drm/i915: Remove intel_ prefix from encoder variables in 
> intel_ddi.c
> https://patchwork.freedesktop.org/api/1.0/series/20992/revisions/1/mbox/
> 
> Test gem_exec_flush:
> Subgroup basic-batch-kernel-default-uc:
> incomplete -> PASS   (fi-skl-6700k) fdo#100130
> pass   -> FAIL   (fi-snb-2600) fdo#17
> Test gem_exec_suspend:
> Subgroup basic-s4-devices:
> pass   -> DMESG-WARN (fi-bxt-t5700) fdo#100125
> 
> fdo#100130 https://bugs.freedesktop.org/show_bug.cgi?id=100130
> fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
> fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125
> 
> fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
> time: 463s
> fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
> time: 607s
> fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
> time: 534s
> fi-bxt-t5700 total:278  pass:257  dwarn:1   dfail:0   fail:0   skip:20  
> time: 609s
> fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
> time: 505s
> fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
> time: 502s
> fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time: 445s
> fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time: 433s
> fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
> time: 434s
> fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time: 507s
> fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time: 488s
> fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
> time: 478s
> fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time: 505s
> fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
> time: 591s
> fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
> time: 500s
> fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time: 546s
> fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
> time: 552s
> fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
> time: 424s
> 
> 510c200742ced5a91d07e48220b669a3c9b30c0c drm-tip: 2017y-03m-09d-15h-21m-14s 
> UTC integration manifest
> 4f73f19 drm/i915: Remove intel_ prefix from encoder variables in intel_ddi.c
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4118/
> ___
> 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 i-g-t] kms_cursor_crc: Add a subtest with a 256x256 gradient cursor

[Ander Conselvan De Oliveira]

On Fri, 2017-03-10 at 12:18 +0200, Ander Conselvan de Oliveira wrote:
> Some of the kms_cursor_crc subtests where failing on Geminilake. The
> root cause was an error on programming the pre-CSC gamma tables, which
> led to small rounding errors that, although not sufficient to change the
> image as captured at 8bpc with the Chamelium, were enough to generate a
> different CRC. It is not clear why the rounding is different when the
> cursor is enabled, but this was caught by chance, since the cursor would
> only be exercised with limited color combinations.
> 
> To improve coverage, add a test that uses a gradient covering all
> possible 8bit values for a channel.
> 
> Signed-off-by: Ander Conselvan de Oliveira 
> <ander.conselvan.de.olive...@intel.com>
> ---
>  tests/kms_cursor_crc.c | 42 ++
>  1 file changed, 38 insertions(+), 4 deletions(-)
> 
> diff --git a/tests/kms_cursor_crc.c b/tests/kms_cursor_crc.c
> index 4851e18..0b232bf 100644
> --- a/tests/kms_cursor_crc.c
> +++ b/tests/kms_cursor_crc.c
> @@ -87,6 +87,8 @@ static void draw_cursor(cairo_t *cr, int x, int y, int cw, 
> int ch)
>   igt_paint_color_alpha(cr, x + wl, y + ht, wr, hb, 0.5, 0.5, 0.5, 1.0);
>  }
>  
> +typedef void(*draw_cursor_cb)(cairo_t *cr, int x, int y, int cw, int ch);
> +
>  static void cursor_enable(data_t *data)
>  {
>   igt_output_t *output = data->output;
> @@ -107,7 +109,8 @@ static void cursor_disable(data_t *data)
>  }
>  
>  
> -static void do_single_test(data_t *data, int x, int y)
> +static void do_single_test_with_cursor_cb(data_t *data, int x, int y,
> +   draw_cursor_cb cursor_cb)
>  {
>   igt_display_t *display = >display;
>   igt_pipe_crc_t *pipe_crc = data->pipe_crc;
> @@ -151,7 +154,7 @@ static void do_single_test(data_t *data, int x, int y)
>   igt_display_commit(display);
>  
>   /* Now render the same in software and collect crc */
> - draw_cursor(cr, x, y, data->curw, data->curh);
> + cursor_cb(cr, x, y, data->curw, data->curh);
>   igt_display_commit(display);
>  
>   igt_wait_for_vblank(data->drm_fd, data->pipe);
> @@ -162,6 +165,11 @@ static void do_single_test(data_t *data, int x, int y)
>   igt_paint_color(cr, 0, 0, data->screenw, data->screenh, 0.0, 0.0, 0.0);
>  }
>  
> +static void do_single_test(data_t *data, int x, int y)
> +{
> + do_single_test_with_cursor_cb(data, x, y, draw_cursor);
> +}
> +
>  static void do_fail_test(data_t *data, int x, int y, int expect)
>  {
>   igt_display_t *display = >display;
> @@ -386,7 +394,8 @@ static void run_test(data_t *data, void 
> (*testfunc)(data_t *), int cursor_w, int
>   igt_require_f(valid_tests, "no valid crtc/connector combinations 
> found\n");
>  }
>  
> -static void create_cursor_fb(data_t *data, int cur_w, int cur_h)
> +static void create_cursor_fb_with_cb(data_t *data, int cur_w, int cur_h,
> +  draw_cursor_cb cursor_cb)
>  {
>   cairo_t *cr;
>   uint32_t fb_id;
> @@ -406,10 +415,15 @@ static void create_cursor_fb(data_t *data, int cur_w, 
> int cur_h)
>   igt_assert(fb_id);
>  
>   cr = igt_get_cairo_ctx(data->drm_fd, >fb);
> - draw_cursor(cr, 0, 0, cur_w, cur_h);
> + cursor_cb(cr, 0, 0, cur_w, cur_h);
>   igt_assert(cairo_status(cr) == 0);
>  }
>  
> +static void create_cursor_fb(data_t *data, int cur_w, int cur_h)
> +{
> + create_cursor_fb_with_cb(data, cur_w, cur_h, draw_cursor);
> +}
> +
>  static bool has_nonsquare_cursors(uint32_t devid)
>  {
>   /*
> @@ -506,6 +520,23 @@ static void test_rapid_movement(data_t *data)
>  
>  }
>  
> +static void draw_cursor_gradient(cairo_t *cr, int x, int y, int cw, int ch)
> +{
> + cairo_set_antialias(cr, CAIRO_ANTIALIAS_NONE);
> + igt_paint_color_gradient(cr, x, y, cw, ch, 1.0, 1.0, 1.0);
> +}
> +
> +static void test_cursor_colors(data_t *data)
> +{
> + int cursor_w = data->curw;
> + int cursor_h = data->curh;
> +
> + create_cursor_fb_with_cb(data, cursor_w, cursor_h,
> +  draw_cursor_gradient);
> + do_single_test_with_cursor_cb(data, 0, 0, draw_cursor_gradient);
> + igt_remove_fb(data->drm_fd, >fb);
> +}
> +
>  static void run_test_generic(data_t *data)
>  {
>   int cursor_size;
> @@ -613,6 +644,9 @@ igt_main
>   igt_subtest_f("cursor-size-change")
>   run_test(, test_cursor_size, cursor_width, cursor_height);
>  
> + igt_subtest_f("gradient-cursor")

Just realized this needs an igt_require(max_cursor_[wh] >= 256).

Ander

> + run_test(, test_cursor_colors, 256, 256);
> +
>   run_test_generic();
>  
>   igt_fixture {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] kms_cursor_crc: Add a subtest with a 256x256 gradient cursor

[Ander Conselvan de Oliveira]

Some of the kms_cursor_crc subtests where failing on Geminilake. The
root cause was an error on programming the pre-CSC gamma tables, which
led to small rounding errors that, although not sufficient to change the
image as captured at 8bpc with the Chamelium, were enough to generate a
different CRC. It is not clear why the rounding is different when the
cursor is enabled, but this was caught by chance, since the cursor would
only be exercised with limited color combinations.

To improve coverage, add a test that uses a gradient covering all
possible 8bit values for a channel.

Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
---
 tests/kms_cursor_crc.c | 42 ++
 1 file changed, 38 insertions(+), 4 deletions(-)

diff --git a/tests/kms_cursor_crc.c b/tests/kms_cursor_crc.c
index 4851e18..0b232bf 100644
--- a/tests/kms_cursor_crc.c
+++ b/tests/kms_cursor_crc.c
@@ -87,6 +87,8 @@ static void draw_cursor(cairo_t *cr, int x, int y, int cw, 
int ch)
igt_paint_color_alpha(cr, x + wl, y + ht, wr, hb, 0.5, 0.5, 0.5, 1.0);
 }
 
+typedef void(*draw_cursor_cb)(cairo_t *cr, int x, int y, int cw, int ch);
+
 static void cursor_enable(data_t *data)
 {
igt_output_t *output = data->output;
@@ -107,7 +109,8 @@ static void cursor_disable(data_t *data)
 }
 
 
-static void do_single_test(data_t *data, int x, int y)
+static void do_single_test_with_cursor_cb(data_t *data, int x, int y,
+ draw_cursor_cb cursor_cb)
 {
igt_display_t *display = >display;
igt_pipe_crc_t *pipe_crc = data->pipe_crc;
@@ -151,7 +154,7 @@ static void do_single_test(data_t *data, int x, int y)
igt_display_commit(display);
 
/* Now render the same in software and collect crc */
-   draw_cursor(cr, x, y, data->curw, data->curh);
+   cursor_cb(cr, x, y, data->curw, data->curh);
igt_display_commit(display);
 
igt_wait_for_vblank(data->drm_fd, data->pipe);
@@ -162,6 +165,11 @@ static void do_single_test(data_t *data, int x, int y)
igt_paint_color(cr, 0, 0, data->screenw, data->screenh, 0.0, 0.0, 0.0);
 }
 
+static void do_single_test(data_t *data, int x, int y)
+{
+   do_single_test_with_cursor_cb(data, x, y, draw_cursor);
+}
+
 static void do_fail_test(data_t *data, int x, int y, int expect)
 {
igt_display_t *display = >display;
@@ -386,7 +394,8 @@ static void run_test(data_t *data, void (*testfunc)(data_t 
*), int cursor_w, int
igt_require_f(valid_tests, "no valid crtc/connector combinations 
found\n");
 }
 
-static void create_cursor_fb(data_t *data, int cur_w, int cur_h)
+static void create_cursor_fb_with_cb(data_t *data, int cur_w, int cur_h,
+draw_cursor_cb cursor_cb)
 {
cairo_t *cr;
uint32_t fb_id;
@@ -406,10 +415,15 @@ static void create_cursor_fb(data_t *data, int cur_w, int 
cur_h)
igt_assert(fb_id);
 
cr = igt_get_cairo_ctx(data->drm_fd, >fb);
-   draw_cursor(cr, 0, 0, cur_w, cur_h);
+   cursor_cb(cr, 0, 0, cur_w, cur_h);
igt_assert(cairo_status(cr) == 0);
 }
 
+static void create_cursor_fb(data_t *data, int cur_w, int cur_h)
+{
+   create_cursor_fb_with_cb(data, cur_w, cur_h, draw_cursor);
+}
+
 static bool has_nonsquare_cursors(uint32_t devid)
 {
/*
@@ -506,6 +520,23 @@ static void test_rapid_movement(data_t *data)
 
 }
 
+static void draw_cursor_gradient(cairo_t *cr, int x, int y, int cw, int ch)
+{
+   cairo_set_antialias(cr, CAIRO_ANTIALIAS_NONE);
+   igt_paint_color_gradient(cr, x, y, cw, ch, 1.0, 1.0, 1.0);
+}
+
+static void test_cursor_colors(data_t *data)
+{
+   int cursor_w = data->curw;
+   int cursor_h = data->curh;
+
+   create_cursor_fb_with_cb(data, cursor_w, cursor_h,
+draw_cursor_gradient);
+   do_single_test_with_cursor_cb(data, 0, 0, draw_cursor_gradient);
+   igt_remove_fb(data->drm_fd, >fb);
+}
+
 static void run_test_generic(data_t *data)
 {
int cursor_size;
@@ -613,6 +644,9 @@ igt_main
igt_subtest_f("cursor-size-change")
run_test(, test_cursor_size, cursor_width, cursor_height);
 
+   igt_subtest_f("gradient-cursor")
+   run_test(, test_cursor_colors, 256, 256);
+
run_test_generic();
 
igt_fixture {
-- 
2.9.3

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

[Intel-gfx] [PATCH] drm/i915/glk: Improve rounding caused by pre-CSC gamma tables

[Ander Conselvan de Oliveira]

The 33rd entry in the pre-CSC gamma table in Geminilake can represent a
value of 1.0 as 17 bits fixed point with one integer bit. However, the
table was generated such that the value of 1.0 would be 0. with
all the intervals scaled accordingly. For instance, 0.5 mapped to
0.7fff instead of 0.8000.

For a reason that is not clear to the author, the rounding seems to be
different when a cursor plane is used, leading to some seemingly random
failures of the kms_cursor_crc igt tests. The differences weren't
perceptible at 8bpc with images captured by a Chamelium device, but did
cause CRC mismatches.

Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
---
 drivers/gpu/drm/i915/intel_color.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index b9e5266d..306c6b0 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -465,14 +465,14 @@ static void glk_load_degamma_lut(struct drm_crtc_state 
*state)
 *  different values per channel, so this just loads a linear table.
 */
for (i = 0; i < lut_size; i++) {
-   uint32_t v = (i * ((1 << 16) - 1)) / (lut_size - 1);
+   uint32_t v = (i * (1 << 16)) / (lut_size - 1);
 
I915_WRITE(PRE_CSC_GAMC_DATA(pipe), v);
}
 
/* Clamp values > 1.0. */
while (i++ < 35)
-   I915_WRITE(PRE_CSC_GAMC_DATA(pipe), (1 << 16) - 1);
+   I915_WRITE(PRE_CSC_GAMC_DATA(pipe), (1 << 16));
 }
 
 static void glk_load_luts(struct drm_crtc_state *state)
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH] drm/i915: cleanup patch for intel_ddi.c

[Ander Conselvan De Oliveira]

The summary should say what the clean up is about. For example:

drm/i915: Remove intel_ prefix from encoder variables in intel_ddi.c

With that fixed,

Reviewed-by: Ander Conselvan de Oliveira <conselv...@gmail.com>

On Thu, 2017-03-09 at 16:28 +0530, Shashank Sharma wrote:
> In I915 driver, there are many places where variable name for
> intel_encoder object is given as 'intel_encoder' whereas it would
> make more sense in many places to call it just 'encoder'.
> 
> This patch does a similar cleanup in file intel_ddi.c.
> 
> PS: There are few functions where both drm_encoder and intel_encoder
> are present. For such functions, this patch does nothing.
> 
> Suggested-by: Ander Conselvan De Oliveira <conselv...@gmail.com>
> Signed-off-by: Shashank Sharma <shashank.sha...@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 66 
> 
>  1 file changed, 33 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 0467676..ee341ef 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -821,11 +821,11 @@ void intel_ddi_init_dp_buf_reg(struct intel_encoder 
> *encoder)
>  intel_ddi_get_crtc_encoder(struct intel_crtc *crtc)
>  {
>   struct drm_device *dev = crtc->base.dev;
> - struct intel_encoder *intel_encoder, *ret = NULL;
> + struct intel_encoder *encoder, *ret = NULL;
>   int num_encoders = 0;
>  
> - for_each_encoder_on_crtc(dev, >base, intel_encoder) {
> - ret = intel_encoder;
> + for_each_encoder_on_crtc(dev, >base, encoder) {
> + ret = encoder;
>   num_encoders++;
>   }
>  
> @@ -1130,12 +1130,12 @@ void intel_ddi_clock_get(struct intel_encoder 
> *encoder,
>  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 *encoder)
>  {
>   struct intel_shared_dpll *pll;
>  
>   pll = intel_get_shared_dpll(intel_crtc, crtc_state,
> - intel_encoder);
> + encoder);
>   if (!pll)
>   DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
>pipe_name(intel_crtc->pipe));
> @@ -1146,11 +1146,11 @@ void intel_ddi_clock_get(struct intel_encoder 
> *encoder,
>  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 *encoder)
>  {
>   struct intel_shared_dpll *pll;
>  
> - pll = intel_get_shared_dpll(intel_crtc, crtc_state, intel_encoder);
> + pll = intel_get_shared_dpll(intel_crtc, crtc_state, encoder);
>   if (pll == NULL) {
>   DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
>pipe_name(intel_crtc->pipe));
> @@ -1163,9 +1163,9 @@ void intel_ddi_clock_get(struct intel_encoder *encoder,
>  static bool
>  bxt_ddi_pll_select(struct intel_crtc *intel_crtc,
>  struct intel_crtc_state *crtc_state,
> -struct intel_encoder *intel_encoder)
> +struct intel_encoder *encoder)
>  {
> - return !!intel_get_shared_dpll(intel_crtc, crtc_state, intel_encoder);
> + return !!intel_get_shared_dpll(intel_crtc, crtc_state, encoder);
>  }
>  
>  /*
> @@ -1179,27 +1179,27 @@ bool intel_ddi_pll_select(struct intel_crtc 
> *intel_crtc,
> struct intel_crtc_state *crtc_state)
>  {
>   struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
> - struct intel_encoder *intel_encoder =
> + struct intel_encoder *encoder =
>   intel_ddi_get_crtc_new_encoder(crtc_state);
>  
>   if (IS_GEN9_BC(dev_priv))
>   return skl_ddi_pll_select(intel_crtc, crtc_state,
> -   intel_encoder);
> +   encoder);
>   else if (IS_GEN9_LP(dev_priv))
>   return bxt_ddi_pll_select(intel_crtc, crtc_state,
> -   intel_encoder);
> +   encoder);
>   else
>   return hsw_ddi_pll_select(intel_crtc, crtc_state,
> -   intel_encoder);
> +   encoder);
>  }
>  
>  void intel_ddi_set_pipe_settings(const struct intel_crtc_state *crtc_state)
>  {
>

Re: [Intel-gfx] [PATCH v8 5/6] drm/i915: enable scrambling

[Ander Conselvan De Oliveira]

On Wed, 2017-03-08 at 19:07 +0530, Shashank Sharma wrote:
>  Geminilake platform sports a native HDMI 2.0 controller, and is
>  capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
>  mendates scrambling for these higher clocks, for reduced RF footprint.
> 
>  This patch checks if the monitor supports scrambling, and if required,
>  enables it during the modeset.
> 
>  V2: Addressed review comments from Ville:
>  - Do not track scrambling status in DRM layer, track somewhere in
>driver like in intel_crtc_state.
>  - Don't talk to monitor at such a low layer, set monitor scrambling
>in intel_enable_ddi() before enabling the port.
> 
>  V3: Addressed review comments from Jani
>  - In comments, function names, use "sink" instead of "monitor",
>so that the implementation could be close to the language of
>HDMI spec.
> 
> V4: Addressed review comment from Maarten
>  - scrambling -> hdmi_scrambling
>  - high_tmds_clock_ratio -> hdmi_high_tmds_clock_ratio
> 
> V5: Addressed review comments from Ville and Ander
>  - Do not modifiy the crtc_state after compute_config. Move all
>scrambling and tmds_clock_ratio calcutations to compute_config.
>  - While setting scrambling for source/sink, do not check the
>conditions again, just go by the crtc_state flags. This will
>simplyfy the condition checks.
> 
> V6: Addressed review comments from Ville
>  - Do not add IS_GLK check in disable/enable function, instead add it
>in compute_config, while setting state flags.
>  - Remove unnecessary paranthesis.
>  - Simplyfy handle_sink_scrambling function as suggested.
>  - Add readout code for scrambling status in get_ddi_config and add a
>check for the same in pipe_config_compare.
> 
> V7: Addressed review comments from Ander/Ville
>  - No separate function for source scrambling, make it inline
>  - Align the last line of the macro TRANS_DDI_HDMI_SCRAMBLING_MASK
>  - Do not add platform check while setting source scrambling
>  - Use pipe_config instead of crtc->config to set sink scrambling
>  - To readout scrambling status, Compare with SCRAMBLING_MASK
>not any of its bits
>  - Remove platform check in intel_pipe_config_compare while checking
>scrambling status
> 
> V8: Fixed mege conflict, Addressed review comments from Ander
>  - Remove the desciption/comment about scrambling fom the caller, move
>it to the function
>  - Move the IS_GLK check into scrambling function
>  - Fix alignment
> 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  7 
>  drivers/gpu/drm/i915/intel_ddi.c | 19 +++
>  drivers/gpu/drm/i915/intel_display.c |  3 ++
>  drivers/gpu/drm/i915/intel_drv.h | 10 ++
>  drivers/gpu/drm/i915/intel_hdmi.c| 62 
> 
>  5 files changed, 101 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index cc843f9..2d50fdc 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7830,7 +7830,14 @@ enum {
>  #define  TRANS_DDI_EDP_INPUT_B_ONOFF (5<<12)
>  #define  TRANS_DDI_EDP_INPUT_C_ONOFF (6<<12)
>  #define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC   (1<<8)
> +#define  TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7)
> +#define  TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
>  #define  TRANS_DDI_BFI_ENABLE(1<<4)
> +#define  TRANS_DDI_HIGH_TMDS_CHAR_RATE   (1<<4)
> +#define  TRANS_DDI_HDMI_SCRAMBLING   (1<<0)
> +#define  TRANS_DDI_HDMI_SCRAMBLING_MASK (TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE 
> \
> + | TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ \
> + | TRANS_DDI_HDMI_SCRAMBLING)
>  
>  /* DisplayPort Transport Control */
>  #define _DP_TP_CTL_A 0x64040
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 0467676..b3e4c4a 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1309,6 +1309,11 @@ void intel_ddi_enable_transcoder_func(const struct 
> intel_crtc_state *crtc_state)
>   temp |= TRANS_DDI_MODE_SELECT_HDMI;
>   else
>   temp |= TRANS_DDI_MODE_SELECT_DVI;
> +
> + if (crtc_state->hdmi_scrambling)
> + temp |= TRANS_DDI_HDMI_SCRAMBLING_MASK;
> + if (crtc_state->hdmi_high_tmds_clock_ratio)
> + temp |= TRANS_DDI_HIGH_TMDS_CHAR_RATE;
>   } else if (type == INTEL_OUTPUT_ANALOG) {
>   temp |= TRANS_DDI_MODE_SELECT_FDI;
>   temp |= (crtc_state->fdi_lanes - 1) << 1;
> @@ -1882,6 +1887,9 @@ static void intel_enable_ddi(struct intel_encoder 
> *intel_encoder,
>   struct intel_digital_port *intel_dig_port =
>   enc_to_dig_port(encoder);
>  
> + intel_hdmi_handle_sink_scrambling(intel_encoder,
> + 

Re: [Intel-gfx] [PATCH v7 5/6] drm/i915: enable scrambling

[Ander Conselvan De Oliveira]

On Fri, 2017-03-03 at 21:58 +0530, Shashank Sharma wrote:
> Geminilake platform sports a native HDMI 2.0 controller, and is
> capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
> mendates scrambling for these higher clocks, for reduced RF footprint.
> 
> This patch checks if the monitor supports scrambling, and if required,
> enables it during the modeset.
> 
> V2: Addressed review comments from Ville:
> - Do not track scrambling status in DRM layer, track somewhere in
>   driver like in intel_crtc_state.
> - Don't talk to monitor at such a low layer, set monitor scrambling
>   in intel_enable_ddi() before enabling the port.
> 
> V3: Addressed review comments from Jani
>  - In comments, function names, use "sink" instead of "monitor",
>so that the implementation could be close to the language of
>HDMI spec.
> 
> V4: Addressed review comment from Maarten
>  - scrambling -> hdmi_scrambling
>high_tmds_clock_ratio -> hdmi_high_tmds_clock_ratio
> 
> V5: Addressed review comments from Ville and Ander
>  - Do not modifiy the crtc_state after compute_config. Move all
>scrambling and tmds_clock_ratio calcutations to compute_config.
>  - While setting scrambling for source/sink, do not check the
>conditions again, just go by the crtc_state flags. This will
>simplyfy the condition checks.
> 
> V6: Addressed review comments from Ville
>  - Do not add IS_GLK check in disable/enable function, instead add it
>in compute_config, while setting state flags.
>  - Remove unnecessary paranthesis.
>  - Simplyfy handle_sink_scrambling function as suggested.
>  - Add readout code for scrambling status in get_ddi_config and add a
>check for the same in pipe_config_compare.
> 
> V7: Addressed review comments from Ander/Ville
>  - No separate function for source scrambling, make it inline
>  - Align the last line of the macro TRANS_DDI_HDMI_SCRAMBLING_MASK
>  - Do not add platform check while setting source scrambling
>  - Use pipe_config instead of crtc->config to set sink scrambling
>  - To readout scrambling status, Compare with SCRAMBLING_MASK
>not any of its bits
>  - Remove platform check in intel_pipe_config_compare while checking
>scrambling status
> 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  7 +
>  drivers/gpu/drm/i915/intel_ddi.c | 33 +++
>  drivers/gpu/drm/i915/intel_display.c |  3 +++
>  drivers/gpu/drm/i915/intel_drv.h | 10 +++
>  drivers/gpu/drm/i915/intel_hdmi.c| 52 
> 
>  5 files changed, 105 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 4906ce4d..bfd988b 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7824,7 +7824,14 @@ enum {
>  #define  TRANS_DDI_EDP_INPUT_B_ONOFF (5<<12)
>  #define  TRANS_DDI_EDP_INPUT_C_ONOFF (6<<12)
>  #define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC   (1<<8)
> +#define  TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7)
> +#define  TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
>  #define  TRANS_DDI_BFI_ENABLE(1<<4)
> +#define  TRANS_DDI_HIGH_TMDS_CHAR_RATE   (1<<4)
> +#define  TRANS_DDI_HDMI_SCRAMBLING   (1<<0)
> +#define  TRANS_DDI_HDMI_SCRAMBLING_MASK (TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE 
> \
> + | TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ \
> + | TRANS_DDI_HDMI_SCRAMBLING)
>  
>  /* DisplayPort Transport Control */
>  #define _DP_TP_CTL_A 0x64040
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index a7c08d7..2159b2b 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1311,6 +1311,11 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc 
> *crtc)
>   temp |= TRANS_DDI_MODE_SELECT_HDMI;
>   else
>   temp |= TRANS_DDI_MODE_SELECT_DVI;
> +
> + if (intel_crtc->config->hdmi_scrambling)
> + temp |= TRANS_DDI_HDMI_SCRAMBLING_MASK;
> + if (intel_crtc->config->hdmi_high_tmds_clock_ratio)
> + temp |= TRANS_DDI_HIGH_TMDS_CHAR_RATE;
>   } else if (type == INTEL_OUTPUT_ANALOG) {
>   temp |= TRANS_DDI_MODE_SELECT_FDI;
>   temp |= (intel_crtc->config->fdi_lanes - 1) << 1;
> @@ -1885,6 +1890,20 @@ static void intel_enable_ddi(struct intel_encoder 
> *intel_encoder,
>   struct intel_digital_port *intel_dig_port =
>   enc_to_dig_port(encoder);
>  
> + if (IS_GEMINILAKE(dev_priv)) {
> + /*
> +  * GLK sports a native HDMI 2.0 controller. If required
> +  * clock rate is > 340 Mhz && scrambling is supported
> +  * by sink, enable scrambling before enabling the
> +  * 

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/: DMC 1.04 for Geminilake

[Ander Conselvan De Oliveira]

On Wed, 2017-02-22 at 21:22 +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/: DMC 1.04 for Geminilake
> URL   : https://patchwork.freedesktop.org/series/20091/
> State : warning
> 
> == Summary ==
> 
> Series 20091v1 drm/i915/: DMC 1.04 for Geminilake
> https://patchwork.freedesktop.org/api/1.0/series/20091/revisions/1/mbox/
> 
> Test prime_vgem:
> Subgroup basic-fence-flip:
> pass   -> DMESG-WARN (fi-byt-n2820)

Same backtrace happened in CI runs 2281 and 2293. Filed new bug:

https://bugs.freedesktop.org/show_bug.cgi?id=100094


Pushed to drm-intel-next-queued. Thanks for the patch.

Ander

> fi-bdw-5557u total:253  pass:242  dwarn:0   dfail:0   fail:0   skip:11 
> fi-bsw-n3050 total:253  pass:214  dwarn:0   dfail:0   fail:0   skip:39 
> fi-bxt-j4205 total:253  pass:234  dwarn:0   dfail:0   fail:0   skip:19 
> fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
> fi-byt-j1900 total:253  pass:226  dwarn:0   dfail:0   fail:0   skip:27 
> fi-byt-n2820 total:253  pass:221  dwarn:1   dfail:0   fail:0   skip:31 
> fi-hsw-4770  total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
> fi-hsw-4770r total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
> fi-ilk-650   total:253  pass:203  dwarn:0   dfail:0   fail:0   skip:50 
> fi-ivb-3520m total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
> fi-ivb-3770  total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
> fi-kbl-7500u total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
> fi-skl-6260u total:253  pass:243  dwarn:0   dfail:0   fail:0   skip:10 
> fi-skl-6700hqtotal:253  pass:236  dwarn:0   dfail:0   fail:0   skip:17 
> fi-skl-6700k total:253  pass:231  dwarn:4   dfail:0   fail:0   skip:18 
> fi-skl-6770hqtotal:253  pass:243  dwarn:0   dfail:0   fail:0   skip:10 
> fi-snb-2520m total:253  pass:225  dwarn:0   dfail:0   fail:0   skip:28 
> fi-snb-2600  total:253  pass:224  dwarn:0   dfail:0   fail:0   skip:29 
> 
> bf89ec45d0822835b03910371ac0baf46c4efa2d drm-tip: 2017y-02m-22d-14h-30m-04s 
> UTC integration manifest
> 9708322 drm/i915/: DMC 1.04 for Geminilake
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3939/
> ___
> 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] drm/i915/: DMC 1.04 for Geminilake

[Ander Conselvan De Oliveira]

On Wed, 2017-02-22 at 11:55 -0800, Anusha Srivatsa wrote:
> There is a nre version of DMC available for GLK.
> 
> The release notes mentions:
> This FW has the fix to remove the hang conditions due to
> some debug related issues.
> 
> Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
> Signed-off-by: Anusha Srivatsa <anusha.sriva...@intel.com>

Reviewed-by: Ander Conselvan de Oliveira <conselv...@gmail.com>

> ---
>  drivers/gpu/drm/i915/intel_csr.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_csr.c 
> b/drivers/gpu/drm/i915/intel_csr.c
> index 14659c7..34aa9fa 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -34,9 +34,9 @@
>   * low-power state and comes back to normal.
>   */
>  
> -#define I915_CSR_GLK "i915/glk_dmc_ver1_03.bin"
> +#define I915_CSR_GLK "i915/glk_dmc_ver1_04.bin"
>  MODULE_FIRMWARE(I915_CSR_GLK);
> -#define GLK_CSR_VERSION_REQUIRED CSR_VERSION(1, 3)
> +#define GLK_CSR_VERSION_REQUIRED CSR_VERSION(1, 4)
>  
>  #define I915_CSR_KBL "i915/kbl_dmc_ver1_01.bin"
>  MODULE_FIRMWARE(I915_CSR_KBL);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/glk: Remove MODULE_FIRMWARE() tag from Geminilake's DMC

[Ander Conselvan De Oliveira]

On Mon, 2017-03-06 at 10:24 +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/glk: Remove MODULE_FIRMWARE() tag from Geminilake's DMC
> URL   : https://patchwork.freedesktop.org/series/20744/
> State : success

Pushed to drm-intel-next-queued.

Thanks,
Ander

> 
> == Summary ==
> 
> Series 20744v1 drm/i915/glk: Remove MODULE_FIRMWARE() tag from Geminilake's 
> DMC
> https://patchwork.freedesktop.org/api/1.0/series/20744/revisions/1/mbox/
> 
> Test gem_exec_suspend:
> Subgroup basic-s3:
> incomplete -> PASS   (fi-skl-6260u) fdo#99803
> 
> fdo#99803 https://bugs.freedesktop.org/show_bug.cgi?id=99803
> 
> fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
> fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
> fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
> fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20 
> fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
> fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
> fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
> fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
> fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
> fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
> fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
> fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
> fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
> fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
> fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
> fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
> fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 
> 
> f95d0140659ff38d30dd1b94e78003bda556f897 drm-tip: 2017y-03m-06d-08h-57m-41s 
> UTC integration manifest
> 3593b34 drm/i915/glk: Remove MODULE_FIRMWARE() tag from Geminilake's DMC
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4067/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/glk: Remove MODULE_FIRMWARE() tag from Geminilake's DMC

[Ander Conselvan de Oliveira]

Geminilake's DMC is not yet available in the linux-firmware repository.
To prevent userspace tools such as mkinitramfs to complain about
missing firmware, remove the MODULE_FIRMWARE() tag for now.

Fixes: dbb28b5c3d3c ("drm/i915/DMC/GLK: Load DMC on GLK")
Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
Cc: Anusha Srivatsa <anusha.sriva...@intel.com>
Cc: Daniel Vetter <daniel.vet...@intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <drm-intel-fi...@lists.freedesktop.org>
Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
---
 drivers/gpu/drm/i915/intel_csr.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 14659c7..02a9025 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -35,7 +35,6 @@
  */
 
 #define I915_CSR_GLK "i915/glk_dmc_ver1_03.bin"
-MODULE_FIRMWARE(I915_CSR_GLK);
 #define GLK_CSR_VERSION_REQUIRED   CSR_VERSION(1, 3)
 
 #define I915_CSR_KBL "i915/kbl_dmc_ver1_01.bin"
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH] drm/915/glk: Enable pooled EUs for Geminilake

[Ander Conselvan De Oliveira]

On Tue, 2017-02-28 at 06:25 +, Yang, Rong R wrote:
> We suggest GLK could disable pooled EUs for 2x6 configurations too.

This patch does that. I tried to say that in the commit message but now that I
re-read I see it doesn't really say it.

> As I understand, 2x6 a pool must consist of a complete subslice, 12EUs, right?

That's my understanding too.

Ander

> If so, only 64K SLM are valid, I am afraid it may affect some case's 
> performance.
> 
> > -Original Message-
> > From: Conselvan De Oliveira, Ander
> > Sent: Friday, February 24, 2017 21:13
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Conselvan De Oliveira, Ander <ander.conselvan.de.olive...@intel.com>;
> > Arun Siluvery <arun.siluv...@intel.com>; Kuoppala, Mika
> > <mika.kuopp...@intel.com>; Ursulin, Tvrtko <tvrtko.ursu...@intel.com>;
> > Yang, Rong R <rong.r.y...@intel.com>
> > Subject: [PATCH] drm/915/glk: Enable pooled EUs for Geminilake
> > 
> > Geminilake also supports pooled EUs. Enable it.
> > 
> > It is unclear if the recommendation to disable it for 2x6 configurations 
> > from
> > commit e015dd69b2cf ("drm/i915/bxt: Add WaEnablePooledEuFor2x6")
> > should also apply to GLK, but the only userspace that uses this only cares
> > about the 3x6 configuration. See Beignet's commit 6901899ec90a
> > ("Runtime: set the sub slice according to kernel pooled EU configure.").
> > 
> > Cc: Arun Siluvery <arun.siluv...@intel.com>
> > Cc: Mika Kuoppala <mika.kuopp...@intel.com>
> > Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
> > Cc: Yang Rong <rong.r.y...@intel.com>
> > Signed-off-by: Ander Conselvan de Oliveira
> > <ander.conselvan.de.olive...@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_device_info.c | 9 +
> >  1 file changed, 5 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> > b/drivers/gpu/drm/i915/intel_device_info.c
> > index 2e1fd85..198752d 100644
> > --- a/drivers/gpu/drm/i915/intel_device_info.c
> > +++ b/drivers/gpu/drm/i915/intel_device_info.c
> > @@ -195,8 +195,10 @@ static void gen9_sseu_info_init(struct
> > drm_i915_private *dev_priv)
> > IS_GEN9_LP(dev_priv) && sseu_subslice_total(sseu) > 1;
> > sseu->has_eu_pg = sseu->eu_per_subslice > 2;
> > 
> > -   if (IS_BROXTON(dev_priv)) {
> > +   if (IS_GEN9_LP(dev_priv)) {
> >  #define IS_SS_DISABLED(ss) (!(sseu->subslice_mask & BIT(ss)))
> > +   info->has_pooled_eu = hweight8(sseu->subslice_mask) == 3;
> > +
> > /*
> >  * There is a HW issue in 2x6 fused down parts that requires
> >  * Pooled EU to be enabled as a WA. The pool configuration
> > @@ -204,9 +206,8 @@ static void gen9_sseu_info_init(struct
> > drm_i915_private *dev_priv)
> >  * doesn't affect if the device has all 3 subslices enabled.
> >  */
> > /* WaEnablePooledEuFor2x6:bxt */
> > -   info->has_pooled_eu = ((hweight8(sseu->subslice_mask) ==
> > 3) ||
> > -  (hweight8(sseu->subslice_mask) == 2 &&
> > -   INTEL_REVID(dev_priv) <
> > BXT_REVID_C0));
> > +   info->has_pooled_eu |= (hweight8(sseu->subslice_mask) ==
> > 2 &&
> > +   IS_BXT_REVID(dev_priv, 0,
> > BXT_REVID_B_LAST));
> > 
> > sseu->min_eu_in_pool = 0;
> > if (info->has_pooled_eu) {
> > --
> > 2.9.3
> 
> ___
> 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 v6 5/6] drm/i915: enable scrambling

[Ander Conselvan De Oliveira]

On Fri, 2017-03-03 at 17:33 +0530, Sharma, Shashank wrote:
> Thanks for the review Ander. My comments inline.
> 
> Shashank
> 
> On 3/3/2017 3:22 PM, Ander Conselvan De Oliveira wrote:
> > On Fri, 2017-03-03 at 11:59 +0530, Shashank Sharma wrote:
> > > Geminilake platform sports a native HDMI 2.0 controller, and is
> > > capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
> > > mendates scrambling for these higher clocks, for reduced RF footprint.
> > > 
> > > This patch checks if the monitor supports scrambling, and if required,
> > > enables it during the modeset.
> > > 
> > > V2: Addressed review comments from Ville:
> > > - Do not track scrambling status in DRM layer, track somewhere in
> > >driver like in intel_crtc_state.
> > > - Don't talk to monitor at such a low layer, set monitor scrambling
> > >in intel_enable_ddi() before enabling the port.
> > > 
> > > V3: Addressed review comments from Jani
> > >   - In comments, function names, use "sink" instead of "monitor",
> > > so that the implementation could be close to the language of
> > > HDMI spec.
> > > 
> > > V4: Addressed review comment from Maarten
> > >   - scrambling -> hdmi_scrambling
> > > high_tmds_clock_ratio -> hdmi_high_tmds_clock_ratio
> > > 
> > > V5: Addressed review comments from Ville and Ander
> > >   - Do not modifiy the crtc_state after compute_config. Move all
> > > scrambling and tmds_clock_ratio calcutations to compute_config.
> > >   - While setting scrambling for source/sink, do not check the
> > > conditions again, just go by the crtc_state flags. This will
> > > simplyfy the condition checks.
> > > 
> > > V6: Addressed review comments from Ville
> > >   - Do not add IS_GLK check in disable/enable function, instead add it
> > > in compute_config, while setting state flags.
> > >   - Remove unnecessary paranthesis.
> > >   - Simplyfy handle_sink_scrambling function as suggested.
> > >   - Add readout code for scrambling status in get_ddi_config and add a
> > > check for the same in pipe_config_compare.
> > > 
> > > Signed-off-by: Shashank Sharma <shashank.sha...@intel.com>
> > > ---
> > >   drivers/gpu/drm/i915/i915_reg.h  |  7 
> > >   drivers/gpu/drm/i915/intel_ddi.c | 33 
> > >   drivers/gpu/drm/i915/intel_display.c |  5 +++
> > >   drivers/gpu/drm/i915/intel_drv.h | 14 +++
> > >   drivers/gpu/drm/i915/intel_hdmi.c| 74 
> > > 
> > >   5 files changed, 133 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 4906ce4d..f7891ac 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -7824,7 +7824,14 @@ enum {
> > >   #define  TRANS_DDI_EDP_INPUT_B_ONOFF(5<<12)
> > >   #define  TRANS_DDI_EDP_INPUT_C_ONOFF(6<<12)
> > >   #define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC  (1<<8)
> > > +#define  TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7)
> > > +#define  TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
> > >   #define  TRANS_DDI_BFI_ENABLE   (1<<4)
> > > +#define  TRANS_DDI_HIGH_TMDS_CHAR_RATE   (1<<4)
> > > +#define  TRANS_DDI_HDMI_SCRAMBLING   (1<<0)
> > > +#define  TRANS_DDI_HDMI_SCRAMBLING_MASK 
> > > (TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE \
> > > + | TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ \
> > > + | TRANS_DDI_HDMI_SCRAMBLING)
> > 
> > Last line is misaligned.
> 
> Ok.
> > >   
> > >   /* DisplayPort Transport Control */
> > >   #define _DP_TP_CTL_A0x64040
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index a7c08d7..d0c6927 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -1311,6 +1311,11 @@ void intel_ddi_enable_transcoder_func(struct 
> > > drm_crtc *crtc)
> > >   temp |= TRANS_DDI_MODE_SELECT_HDMI;
> > >   else
> > >   temp |= TRANS_DDI_MODE_SELECT_DVI;
> > > +
> > > + if (IS_GEMIN

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Implement BXT and GLK cdclk restriction based on Azalia BCLK

[Ander Conselvan De Oliveira]

On Tue, 2017-02-28 at 18:57 -0800, Dhinakaran Pandiyan wrote:
> According to BSpec, "The CD clock frequency must be at least twice the
> frequency of the Azalia BCLK." and BCLK is configured to 96 MHz by
> default. BXT and GLK both have cdclk frequencies that are less han 192 MHz,
> so apply the check conditionally for these platforms.
> 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_cdclk.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index 8fc0f72..89027fa 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -1444,6 +1444,8 @@ static int intel_min_cdclk(struct drm_atomic_state 
> *state)
>   struct intel_crtc_state *crtc_state;
>  
>   crtc_state = to_intel_crtc_state(cstate);
> + if (!crtc_state->has_audio)
> + continue;
>  
>   /* According to BSpec, "Do not use DisplayPort with CDCLK less
>* than 432 MHz, audio enabled, port width x4, and link rate
> @@ -1452,7 +1454,6 @@ static int intel_min_cdclk(struct drm_atomic_state 
> *state)
>* for GLK is at 316.8 MHz
>*/
>   if (intel_crtc_has_dp_encoder(crtc_state) &&
> - crtc_state->has_audio &&
>   crtc_state->port_clock >= 54 &&
>   crtc_state->lane_count == 4) {
>   if (IS_GEMINILAKE(dev_priv))
> @@ -1460,6 +1461,13 @@ static int intel_min_cdclk(struct drm_atomic_state 
> *state)
>   else if (IS_BROADWELL(dev_priv) || IS_GEN9(dev_priv))
>   min_cdclk = 432000;
>   }
> +
> + /* According to BSpec, "The CD clock frequency must be at least
> +  * twice the frequency of the Azalia BCLK." and BCLK is 96 MHz
> +  * by default.
> +  */
> + if (IS_BROXTON(dev_priv) || IS_GEMINILAKE(dev_priv))
> + min_cdclk = max(min_cdclk, 2 * 96000);

Hmm, my assumption from reviewing patch 1 of "this returns a valid cdclk" is
broken here. Maybe with the idea of splitting the calc_cdclk_state() in two from
my comment to Paulo's series this could be just:

min_cdclk = max(min_cdcdlk, choose_cdclk(2 * 96000));

?

On second thought, it does make sense for this kind of platform specific
restrictions to be dealt with in platform specific hook, so duplicating that in
calc_cdclk_state() is not that bad?

Ander


>   }
>  
>   return min_cdclk;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915/glk: Apply cdclk workaround for DP audio

[Ander Conselvan De Oliveira]

On Tue, 2017-02-28 at 18:57 -0800, Dhinakaran Pandiyan wrote:
> Implement GLK cdclk restriction for DP audio, similar to what's implemented
> for BDW and other GEN9 platforms. The cdclk restriction has been
> refactored out of max. pixel clock computation as the 1:1 relationship
> between pixel clock and cdclk frequency does not hold for GLK.
> 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_cdclk.c | 83 
> --
>  1 file changed, 52 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index d643c0c..8fc0f72 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -1069,11 +1069,11 @@ static int bxt_calc_cdclk(int max_pixclk)
>   return 144000;
>  }
>  
> -static int glk_calc_cdclk(int max_pixclk)
> +static int glk_calc_cdclk(int max_pixclk, int min_cdclk)
>  {
> - if (max_pixclk > 2 * 158400)
> + if (max_pixclk > 2 * 158400 || min_cdclk > 158400)
>   return 316800;
> - else if (max_pixclk > 2 * 79200)
> + else if (max_pixclk > 2 * 79200 || min_cdclk > 79200)
>   return 158400;
>   else
>   return 79200;
> @@ -1367,7 +1367,7 @@ void bxt_init_cdclk(struct drm_i915_private *dev_priv)
>*   Need to make this change after VBT has changes for BXT.
>*/
>   if (IS_GEMINILAKE(dev_priv)) {
> - cdclk_state.cdclk = glk_calc_cdclk(0);
> + cdclk_state.cdclk = glk_calc_cdclk(0, 0);
>   cdclk_state.vco = glk_de_pll_vco(dev_priv, cdclk_state.cdclk);
>   } else {
>   cdclk_state.cdclk = bxt_calc_cdclk(0);
> @@ -1432,28 +1432,37 @@ void intel_set_cdclk(struct drm_i915_private 
> *dev_priv,
>   dev_priv->display.set_cdclk(dev_priv, cdclk_state);
>  }
>  
> -static int bdw_adjust_min_pipe_pixel_rate(struct intel_crtc_state 
> *crtc_state,
> -   int pixel_rate)
> +static int intel_min_cdclk(struct drm_atomic_state *state)
>  {
> - struct drm_i915_private *dev_priv =
> - to_i915(crtc_state->base.crtc->dev);
> + struct drm_i915_private *dev_priv = to_i915(state->dev);
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *cstate;
> + int i;
> + int min_cdclk = 0;
>  
> - /* pixel rate mustn't exceed 95% of cdclk with IPS on BDW */
> - if (IS_BROADWELL(dev_priv) && crtc_state->ips_enabled)
> - pixel_rate = DIV_ROUND_UP(pixel_rate * 100, 95);
> + for_each_crtc_in_state(state, crtc, cstate, i) {
> + struct intel_crtc_state *crtc_state;
>  
> - /* BSpec says "Do not use DisplayPort with CDCLK less than
> -  * 432 MHz, audio enabled, port width x4, and link rate
> -  * HBR2 (5.4 GHz), or else there may be audio corruption or
> -  * screen corruption."
> -  */
> - if (intel_crtc_has_dp_encoder(crtc_state) &&
> - crtc_state->has_audio &&
> - crtc_state->port_clock >= 54 &&
> - crtc_state->lane_count == 4)
> - pixel_rate = max(432000, pixel_rate);
> + crtc_state = to_intel_crtc_state(cstate);
> +
> + /* According to BSpec, "Do not use DisplayPort with CDCLK less
> +  * than 432 MHz, audio enabled, port width x4, and link rate
> +  * HBR2 (5.4 GHz), or else there may be audio corruption or
> +  * screen corruption." for BDW and GEN9. The cdclk restriction
> +  * for GLK is at 316.8 MHz
> +  */
> + if (intel_crtc_has_dp_encoder(crtc_state) &&
> + crtc_state->has_audio &&
> + crtc_state->port_clock >= 54 &&
> + crtc_state->lane_count == 4) {
> + if (IS_GEMINILAKE(dev_priv))
> + min_cdclk = 316800;
> + else if (IS_BROADWELL(dev_priv) || IS_GEN9(dev_priv))
> + min_cdclk = 432000;
> + }
> + }
>  
> - return pixel_rate;
> + return min_cdclk;
>  }
>  
>  /* compute the max rate for new configuration */
> @@ -1481,10 +1490,9 @@ static int intel_max_pixel_rate(struct 
> drm_atomic_state *state)
>  
>   pixel_rate = crtc_state->pixel_rate;
>  
> - if (IS_BROADWELL(dev_priv) || IS_GEN9(dev_priv))
> - pixel_rate =
> - bdw_adjust_min_pipe_pixel_rate(crtc_state,
> -pixel_rate);
> + /* pixel rate mustn't exceed 95% of cdclk with IPS on BDW */
> + if (IS_BROADWELL(dev_priv) && crtc_state->ips_enabled)
> + pixel_rate = DIV_ROUND_UP(pixel_rate * 100, 95);
>  
>   intel_state->min_pixclk[i] = pixel_rate;
>   }
> @@ -1531,13 +1539,17 @@ static int bdw_modeset_calc_cdclk(struct 
> 

Re: [Intel-gfx] [PATCH 1/3] drm/i915: unify the x_modeset_calc_cdclk() functions

[Ander Conselvan De Oliveira]

On Mon, 2017-02-20 at 17:00 -0300, Paulo Zanoni wrote:
> There's a lot of duplicated platform-independent logic in the current
> modeset_calc_cdclk() functions. Adding cdclk support for more
> platforms will only add more copies of this code.
> 
> To solve this problem, in this patch we create a new function called
> intel_modeset_calc_cdclk() which unifies the platform-independent
> logic, and we also create a new vfunc called calc_cdclk_state(), which
> is responsible to contain only the platform-dependent code.
> 
> The code is now smaller and support for new platforms should be easier
> and not require duplicated platform-independent code.
> 
> v2: Previously I had 2 different patches addressing these problems,
> but wiht Ville's suggestion I think it makes more sense to keep
> everything in a single patch (Ville).
> 
> Cc: Ville Syrjälä 
> Cc: Rodrigo Vivi 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |   4 +-
>  drivers/gpu/drm/i915/intel_cdclk.c   | 187 
> ++-
>  drivers/gpu/drm/i915/intel_display.c |   6 +-
>  drivers/gpu/drm/i915/intel_drv.h |   1 +
>  4 files changed, 60 insertions(+), 138 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 4e7046d..f1c35c7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -644,7 +644,9 @@ struct drm_i915_display_funcs {
>   struct intel_crtc_state *cstate);
>   int (*compute_global_watermarks)(struct drm_atomic_state *state);
>   void (*update_wm)(struct intel_crtc *crtc);
> - int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
> + void (*calc_cdclk_state)(struct drm_i915_private *dev_priv,
> +  int max_pixclk,
> +  struct intel_cdclk_state *cdclk_state);
>   /* Returns the active state of the crtc, and if the crtc is active,
>* fills out the pipe-config with the hw state. */
>   bool (*get_pipe_config)(struct intel_crtc *,
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index d643c0c..dd6fe25 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -1496,148 +1496,69 @@ static int intel_max_pixel_rate(struct 
> drm_atomic_state *state)
>   return max_pixel_rate;
>  }
>  
> -static int vlv_modeset_calc_cdclk(struct drm_atomic_state *state)
> +static void vlv_calc_cdclk_state(struct drm_i915_private *dev_priv,
> +  int max_pixclk,
> +  struct intel_cdclk_state *cdclk_state)
>  {
> - struct drm_i915_private *dev_priv = to_i915(state->dev);
> - int max_pixclk = intel_max_pixel_rate(state);
> - struct intel_atomic_state *intel_state =
> - to_intel_atomic_state(state);
> - int cdclk;
> -
> - cdclk = vlv_calc_cdclk(dev_priv, max_pixclk);
> -
> - if (cdclk > dev_priv->max_cdclk_freq) {
> - DRM_DEBUG_KMS("requested cdclk (%d kHz) exceeds max (%d kHz)\n",
> -   cdclk, dev_priv->max_cdclk_freq);
> - return -EINVAL;
> - }
> -
> - intel_state->cdclk.logical.cdclk = cdclk;
> -
> - if (!intel_state->active_crtcs) {
> - cdclk = vlv_calc_cdclk(dev_priv, 0);
> -
> - intel_state->cdclk.actual.cdclk = cdclk;
> - } else {
> - intel_state->cdclk.actual =
> - intel_state->cdclk.logical;
> - }
> -
> - return 0;
> + cdclk_state->cdclk = vlv_calc_cdclk(dev_priv, max_pixclk);
>  }
>  
> -static int bdw_modeset_calc_cdclk(struct drm_atomic_state *state)
> +static void bdw_calc_cdclk_state(struct drm_i915_private *dev_priv,
> +  int max_pixclk,
> +  struct intel_cdclk_state *cdclk_state)
>  {
> - struct drm_i915_private *dev_priv = to_i915(state->dev);
> - struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
> - int max_pixclk = intel_max_pixel_rate(state);
> - int cdclk;
> -
> - /*
> -  * FIXME should also account for plane ratio
> -  * once 64bpp pixel formats are supported.
> -  */
> - cdclk = bdw_calc_cdclk(max_pixclk);
> -
> - if (cdclk > dev_priv->max_cdclk_freq) {
> - DRM_DEBUG_KMS("requested cdclk (%d kHz) exceeds max (%d kHz)\n",
> -   cdclk, dev_priv->max_cdclk_freq);
> - return -EINVAL;
> - }
> -
> - intel_state->cdclk.logical.cdclk = cdclk;
> -
> - if (!intel_state->active_crtcs) {
> - cdclk = bdw_calc_cdclk(0);
> -
> - intel_state->cdclk.actual.cdclk = cdclk;
> - } else {
> - intel_state->cdclk.actual =
> - intel_state->cdclk.logical;
> - }
> -
> - return 0;
> + 

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Try to fix MST regression with DDI IO power domains (rev5)

[Ander Conselvan De Oliveira]

On Thu, 2017-03-02 at 13:48 +, Patchwork wrote:
> == Series Details ==
> 
> Series: Try to fix MST regression with DDI IO power domains (rev5)
> URL   : https://patchwork.freedesktop.org/series/20345/
> State : failure
> 
> == Summary ==
> 
> Series 20345v5 Try to fix MST regression with DDI IO power domains
> https://patchwork.freedesktop.org/api/1.0/series/20345/revisions/5/mbox/
> 
> Test drv_module_reload:
> Subgroup basic-reload-final:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup basic-reload-inject:
> pass   -> DMESG-WARN (fi-ilk-650)

This also happened in CI 2274. Filed a new bug:

https://bugs.freedesktop.org/show_bug.cgi?id=100045

> Test gem_busy:
> Subgroup basic-hang-default:
> pass   -> FAIL   (fi-hsw-4770r)

Happened also in CI 2272. Filed new bug:

https://bugs.freedesktop.org/show_bug.cgi?id=100046

> Test kms_flip:
> Subgroup basic-flip-vs-wf_vblank:
> fail   -> PASS   (fi-skl-6700hq) fdo#99739
> 
> fdo#99739 https://bugs.freedesktop.org/show_bug.cgi?id=99739
> 
> fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
> fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
> fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
> fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20 
> fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
> fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
> fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
> fi-hsw-4770r total:278  pass:261  dwarn:0   dfail:0   fail:1   skip:16 
> fi-ilk-650   total:278  pass:226  dwarn:2   dfail:0   fail:0   skip:50 
> fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
> fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
> fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
> fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
> fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
> fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
> fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
> fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
> fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 
> 
> de1ba88fe7549a65913589682a70b4f8a40dd726 drm-tip: 2017y-03m-02d-12h-46m-44s 
> UTC integration manifest
> 871034e drm/i915: Remove duplicate DDI enabling logic from MST path
> b3f5275 drm/i915: Remove direct usages of intel_crtc->config from DDI code
> 92f221a drm/i915: Pass intel_crtc to DDI functions called from crtc en/disable
> fcfd827 drm/i915: Pass pipe_config to fdi_link_train() functions
> b395618 drm/i915: Pass pipe_config to pch_enable() functions
> fd6e546 drm/i915: Pass intel_crtc to intel_lpt_pch_enable()
> 4f4c870 drm/i915: Pass intel_crtc to fdi_link_train() hooks
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4034/
> ___
> 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 v6 5/6] drm/i915: enable scrambling

[Ander Conselvan De Oliveira]

On Fri, 2017-03-03 at 11:59 +0530, Shashank Sharma wrote:
> Geminilake platform sports a native HDMI 2.0 controller, and is
> capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
> mendates scrambling for these higher clocks, for reduced RF footprint.
> 
> This patch checks if the monitor supports scrambling, and if required,
> enables it during the modeset.
> 
> V2: Addressed review comments from Ville:
> - Do not track scrambling status in DRM layer, track somewhere in
>   driver like in intel_crtc_state.
> - Don't talk to monitor at such a low layer, set monitor scrambling
>   in intel_enable_ddi() before enabling the port.
> 
> V3: Addressed review comments from Jani
>  - In comments, function names, use "sink" instead of "monitor",
>so that the implementation could be close to the language of
>HDMI spec.
> 
> V4: Addressed review comment from Maarten
>  - scrambling -> hdmi_scrambling
>high_tmds_clock_ratio -> hdmi_high_tmds_clock_ratio
> 
> V5: Addressed review comments from Ville and Ander
>  - Do not modifiy the crtc_state after compute_config. Move all
>scrambling and tmds_clock_ratio calcutations to compute_config.
>  - While setting scrambling for source/sink, do not check the
>conditions again, just go by the crtc_state flags. This will
>simplyfy the condition checks.
> 
> V6: Addressed review comments from Ville
>  - Do not add IS_GLK check in disable/enable function, instead add it
>in compute_config, while setting state flags.
>  - Remove unnecessary paranthesis.
>  - Simplyfy handle_sink_scrambling function as suggested.
>  - Add readout code for scrambling status in get_ddi_config and add a
>check for the same in pipe_config_compare.
> 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  7 
>  drivers/gpu/drm/i915/intel_ddi.c | 33 
>  drivers/gpu/drm/i915/intel_display.c |  5 +++
>  drivers/gpu/drm/i915/intel_drv.h | 14 +++
>  drivers/gpu/drm/i915/intel_hdmi.c| 74 
> 
>  5 files changed, 133 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 4906ce4d..f7891ac 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7824,7 +7824,14 @@ enum {
>  #define  TRANS_DDI_EDP_INPUT_B_ONOFF (5<<12)
>  #define  TRANS_DDI_EDP_INPUT_C_ONOFF (6<<12)
>  #define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC   (1<<8)
> +#define  TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7)
> +#define  TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
>  #define  TRANS_DDI_BFI_ENABLE(1<<4)
> +#define  TRANS_DDI_HIGH_TMDS_CHAR_RATE   (1<<4)
> +#define  TRANS_DDI_HDMI_SCRAMBLING   (1<<0)
> +#define  TRANS_DDI_HDMI_SCRAMBLING_MASK (TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE 
> \
> + | TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ \
> + | TRANS_DDI_HDMI_SCRAMBLING)

Last line is misaligned.

>  
>  /* DisplayPort Transport Control */
>  #define _DP_TP_CTL_A 0x64040
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index a7c08d7..d0c6927 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1311,6 +1311,11 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc 
> *crtc)
>   temp |= TRANS_DDI_MODE_SELECT_HDMI;
>   else
>   temp |= TRANS_DDI_MODE_SELECT_DVI;
> +
> + if (IS_GEMINILAKE(dev_priv))
> + temp = intel_hdmi_handle_source_scrambling(
> + intel_encoder,
> + intel_crtc->config, temp);

This whole hunk could just be:

+   if (config->hdmi_scrambling)
+   hdmi_config |= TRANS_DDI_HDMI_SCRAMBLING_MASK;
+
+   if (config->hdmi_high_tmds_clock_ratio)
+   hdmi_config |= TRANS_DDI_HIGH_TMDS_CHAR_RATE;

No need to check for GLK here, since the compute config code already did.

>   } else if (type == INTEL_OUTPUT_ANALOG) {
>   temp |= TRANS_DDI_MODE_SELECT_FDI;
>   temp |= (intel_crtc->config->fdi_lanes - 1) << 1;
> @@ -1885,6 +1890,21 @@ static void intel_enable_ddi(struct intel_encoder 
> *intel_encoder,
>   struct intel_digital_port *intel_dig_port =
>   enc_to_dig_port(encoder);
>  
> + if (IS_GEMINILAKE(dev_priv)) {
> + struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
> + /*
> +  * GLK sports a native HDMI 2.0 controller. If required
> +  * clock rate is > 340 Mhz && scrambling is supported
> +  * by sink, enable scrambling before enabling the
> +  * HDMI 2.0 port. The sink can choose to disable the
> +  * scrambling if it doesn't 

Re: [Intel-gfx] [PATCH v5 5/6] drm/i915: enable scrambling

[Ander Conselvan De Oliveira]

On Thu, 2017-03-02 at 08:25 +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 3/1/2017 8:41 PM, Ville Syrjälä wrote:
> > On Tue, Feb 28, 2017 at 02:09:09PM +0530, Shashank Sharma wrote:
> > > Geminilake platform sports a native HDMI 2.0 controller, and is
> > > capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
> > > mendates scrambling for these higher clocks, for reduced RF footprint.
> > > 
> > > This patch checks if the monitor supports scrambling, and if required,
> > > enables it during the modeset.
> > > 
> > > V2: Addressed review comments from Ville:
> > > - Do not track scrambling status in DRM layer, track somewhere in
> > >driver like in intel_crtc_state.
> > > - Don't talk to monitor at such a low layer, set monitor scrambling
> > >in intel_enable_ddi() before enabling the port.
> > > 
> > > V3: Addressed review comments from Jani
> > >   - In comments, function names, use "sink" instead of "monitor",
> > > so that the implementation could be close to the language of
> > > HDMI spec.
> > > 
> > > V4: Addressed review comment from Maarten
> > >   - scrambling -> hdmi_scrambling
> > > high_tmds_clock_ratio -> hdmi_high_tmds_clock_ratio
> > > 
> > > V5: Addressed review comments from Ville and Ander
> > >   - Do not modifiy the crtc_state after compute_config. Move all
> > > scrambling and tmds_clock_ratio calcutations to compute_config.
> > >   - While setting scrambling for source/sink, do not check the
> > > conditions again, just go by the crtc_state flags. This will
> > > simplyfy the condition checks.
> > > 
> > > Signed-off-by: Shashank Sharma 
> > > ---
> > >   drivers/gpu/drm/i915/i915_reg.h   |  4 ++
> > >   drivers/gpu/drm/i915/intel_ddi.c  | 29 
> > >   drivers/gpu/drm/i915/intel_drv.h  | 14 ++
> > >   drivers/gpu/drm/i915/intel_hdmi.c | 98 
> > > +++
> > >   4 files changed, 145 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index ce6f096..1759b64 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -7824,7 +7824,11 @@ enum {
> > >   #define  TRANS_DDI_EDP_INPUT_B_ONOFF(5<<12)
> > >   #define  TRANS_DDI_EDP_INPUT_C_ONOFF(6<<12)
> > >   #define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC  (1<<8)
> > > +#define  TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7)
> > > +#define  TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
> > >   #define  TRANS_DDI_BFI_ENABLE   (1<<4)
> > > +#define  TRANS_DDI_HIGH_TMDS_CHAR_RATE   (1<<4)
> > > +#define  TRANS_DDI_HDMI_SCRAMBLING   (1<<0)
> > >   
> > >   /* DisplayPort Transport Control */
> > >   #define _DP_TP_CTL_A0x64040
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index a7c08d7..24bc3a8 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -1311,6 +1311,11 @@ void intel_ddi_enable_transcoder_func(struct 
> > > drm_crtc *crtc)
> > >   temp |= TRANS_DDI_MODE_SELECT_HDMI;
> > >   else
> > >   temp |= TRANS_DDI_MODE_SELECT_DVI;
> > > +
> > > + if (IS_GEMINILAKE(dev_priv))
> > > + temp = intel_hdmi_handle_source_scrambling(
> > > + intel_encoder,
> > > + intel_crtc->config, temp);
> > >   } else if (type == INTEL_OUTPUT_ANALOG) {
> > >   temp |= TRANS_DDI_MODE_SELECT_FDI;
> > >   temp |= (intel_crtc->config->fdi_lanes - 1) << 1;
> > > @@ -1885,6 +1890,21 @@ static void intel_enable_ddi(struct intel_encoder 
> > > *intel_encoder,
> > >   struct intel_digital_port *intel_dig_port =
> > >   enc_to_dig_port(encoder);
> > >   
> > > + if (IS_GEMINILAKE(dev_priv)) {
> > > + struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
> > > + /*
> > > +  * GLK sports a native HDMI 2.0 controller. If required
> > > +  * clock rate is > 340 Mhz && scrambling is supported
> > > +  * by sink, enable scrambling before enabling the
> > > +  * HDMI 2.0 port. The sink can choose to disable the
> > > +  * scrambling if it doesn't detect a scrambled within
> > > +  * 100 ms.
> > > +  */
> > > + intel_hdmi_handle_sink_scrambling(intel_encoder,
> > > + conn_state->connector,
> > > + crtc->config, true);
> > > + }
> > > +
> > >   /* In HDMI/DVI mode, the port width, and swing/emphasis 
> > > values
> > >* are ignored so nothing special needs to be done 
> > > besides
> > >* enabling 

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for i915/HuC: Add an extra check for platforms that do not have HUC

[Ander Conselvan De Oliveira]

On Thu, 2017-03-02 at 11:17 +, Patchwork wrote:
> == Series Details ==
> 
> Series: i915/HuC: Add an extra check for platforms that do not have HUC
> URL   : https://patchwork.freedesktop.org/series/20482/
> State : success

Pushed. Thanks for the patch.

Ander

> 
> == Summary ==
> 
> Series 20482v1 i915/HuC: Add an extra check for platforms that do not have HUC
> https://patchwork.freedesktop.org/api/1.0/series/20482/revisions/1/mbox/
> 
> Test pm_rpm:
> Subgroup basic-pci-d3-state:
> incomplete -> PASS   (fi-byt-n2820) fdo#99740
> 
> fdo#99740 https://bugs.freedesktop.org/show_bug.cgi?id=99740
> 
> fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
> fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
> fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
> fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20 
> fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
> fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
> fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
> fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
> fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
> fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
> fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
> fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
> fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
> fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
> fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
> fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
> fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
> fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 
> 
> b3c4a574937b2256a716b23037c8b94ffebd7c8a drm-tip: 2017y-03m-02d-08h-59m-08s 
> UTC integration manifest
> 51adfd1 i915/HuC: Add an extra check for platforms that do not have HUC
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4030/
> ___
> 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] i915/HuC: Add an extra check for platforms that do not have HUC

[Ander Conselvan De Oliveira]

On Wed, 2017-03-01 at 11:58 -0800, Anusha Srivatsa wrote:
> Return silently without producing much noise on platforms
> that have a HuC but the firmware is absent.

Matches what's done for GuC.

Reviewed-by: Ander Conselvan de Oliveira <conselv...@gmail.com>

> Cc: Ander Conselvan De Oliveira <ander.conselvan.de.olive...@intel.com>
> Cc: Rodrigo Vivi <rodrigo.v...@itel.com>
> Signed-off-by: Anusha Srivatsa <anusha.sriva...@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_huc.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_huc.c 
> b/drivers/gpu/drm/i915/intel_huc.c
> index c28543d..e660109 100644
> --- a/drivers/gpu/drm/i915/intel_huc.c
> +++ b/drivers/gpu/drm/i915/intel_huc.c
> @@ -181,12 +181,14 @@ void intel_huc_init(struct drm_i915_private *dev_priv)
>   }
>  
>   huc_fw->path = fw_path;
> +
> + if (huc_fw->path == NULL)
> + return;
> +
>   huc_fw->fetch_status = INTEL_UC_FIRMWARE_PENDING;
>  
>   DRM_DEBUG_DRIVER("HuC firmware pending, path %s\n", fw_path);
>  
> - WARN(huc_fw->path == NULL, "HuC present but no fw path\n");
> -
>   intel_uc_fw_fetch(dev_priv, huc_fw);
>  }
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 7/7] drm/i915: Remove duplicate DDI enabling logic from MST path

[Ander Conselvan de Oliveira]

The logic to enable a DDI in intel_mst_pre_enable_dp() is essentially
the same as in intel_ddi_pre_enable_dp(). So reuse the latter function
by calling the post_disable hook on the intel_dig_port instead of
duplicating that code.

v2: Don't oops because of a NULL encoder->crtc. (Ville)
v3: Warn for MST + PORT_E too. (Ville)
Cc: Imre Deak <imre.d...@intel.com>
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_ddi.c|  2 ++
 drivers/gpu/drm/i915/intel_dp_mst.c | 23 +++
 2 files changed, 5 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ebccd48..0467676 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1713,6 +1713,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
enum port port = intel_ddi_get_encoder_port(encoder);
struct intel_digital_port *dig_port = enc_to_dig_port(>base);
 
+   WARN_ON(link_mst && (port == PORT_A || port == PORT_E));
+
intel_dp_set_link_params(intel_dp, link_rate, lane_count,
 link_mst);
if (encoder->type == INTEL_OUTPUT_EDP)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index a8334e1..094cbdc 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -159,26 +159,9 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
*encoder,
 
DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
 
-   if (intel_dp->active_mst_links == 0) {
-   intel_ddi_clk_select(_dig_port->base,
-pipe_config->shared_dpll);
-
-   intel_display_power_get(dev_priv,
-   intel_dig_port->ddi_io_power_domain);
-
-   intel_prepare_dp_ddi_buffers(_dig_port->base);
-   intel_dp_set_link_params(intel_dp,
-pipe_config->port_clock,
-pipe_config->lane_count,
-true);
-
-   intel_ddi_init_dp_buf_reg(_dig_port->base);
-
-   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
-
-   intel_dp_start_link_train(intel_dp);
-   intel_dp_stop_link_train(intel_dp);
-   }
+   if (intel_dp->active_mst_links == 0)
+   intel_dig_port->base.pre_enable(_dig_port->base,
+   pipe_config, NULL);
 
ret = drm_dp_mst_allocate_vcpi(_dp->mst_mgr,
   connector->port,
-- 
2.9.3

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

[Intel-gfx] [PATCH v3 5/7] drm/i915: Pass intel_crtc to DDI functions called from crtc en/disable

[Ander Conselvan de Oliveira]

Pass intel_crtc to functions intel_ddi_enable_transcoder_func(),
intel_ddi_set_pipe_settings() and intel_ddi_set_vc_payload_alloc(),
instead of the generic crtc type. By changing the functions
intel_ddi_get_crtc_encoder() so that it receives an intel_crtc
parameter, there is no need for the drm_crtc in the callers.

Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_ddi.c | 62 
 drivers/gpu/drm/i915/intel_display.c |  8 ++---
 drivers/gpu/drm/i915/intel_drv.h |  6 ++--
 3 files changed, 34 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index a320378..0db526e 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -818,21 +818,20 @@ void intel_ddi_init_dp_buf_reg(struct intel_encoder 
*encoder)
 }
 
 static struct intel_encoder *
-intel_ddi_get_crtc_encoder(struct drm_crtc *crtc)
+intel_ddi_get_crtc_encoder(struct intel_crtc *crtc)
 {
-   struct drm_device *dev = crtc->dev;
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct drm_device *dev = crtc->base.dev;
struct intel_encoder *intel_encoder, *ret = NULL;
int num_encoders = 0;
 
-   for_each_encoder_on_crtc(dev, crtc, intel_encoder) {
+   for_each_encoder_on_crtc(dev, >base, intel_encoder) {
ret = intel_encoder;
num_encoders++;
}
 
if (num_encoders != 1)
WARN(1, "%d encoders on crtc for pipe %c\n", num_encoders,
-pipe_name(intel_crtc->pipe));
+pipe_name(crtc->pipe));
 
BUG_ON(ret == NULL);
return ret;
@@ -1194,12 +1193,11 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc,
  intel_encoder);
 }
 
-void intel_ddi_set_pipe_settings(struct drm_crtc *crtc)
+void intel_ddi_set_pipe_settings(struct intel_crtc *crtc)
 {
-   struct drm_i915_private *dev_priv = to_i915(crtc->dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
-   enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
+   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
int type = intel_encoder->type;
uint32_t temp;
 
@@ -1207,7 +1205,7 @@ void intel_ddi_set_pipe_settings(struct drm_crtc *crtc)
WARN_ON(transcoder_is_dsi(cpu_transcoder));
 
temp = TRANS_MSA_SYNC_CLK;
-   switch (intel_crtc->config->pipe_bpp) {
+   switch (crtc->config->pipe_bpp) {
case 18:
temp |= TRANS_MSA_6_BPC;
break;
@@ -1227,12 +1225,10 @@ void intel_ddi_set_pipe_settings(struct drm_crtc *crtc)
}
 }
 
-void intel_ddi_set_vc_payload_alloc(struct drm_crtc *crtc, bool state)
+void intel_ddi_set_vc_payload_alloc(struct intel_crtc *crtc, bool state)
 {
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   struct drm_device *dev = crtc->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
uint32_t temp;
temp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
if (state == true)
@@ -1242,14 +1238,12 @@ void intel_ddi_set_vc_payload_alloc(struct drm_crtc 
*crtc, bool state)
I915_WRITE(TRANS_DDI_FUNC_CTL(cpu_transcoder), temp);
 }
 
-void intel_ddi_enable_transcoder_func(struct drm_crtc *crtc)
+void intel_ddi_enable_transcoder_func(struct intel_crtc *crtc)
 {
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
-   struct drm_device *dev = crtc->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   enum pipe pipe = intel_crtc->pipe;
-   enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   enum pipe pipe = crtc->pipe;
+   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
enum port port = intel_ddi_get_encoder_port(intel_encoder);
int type = intel_encoder->type;
uint32_t temp;
@@ -1258,7 +1252,7 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc 
*crtc)
temp = TRANS_DDI_FUNC_ENABLE;
temp |= TRANS_DDI_SELECT_PORT(port);
 
-   switch (intel_crtc->config->pipe_bpp) {

[Intel-gfx] [PATCH v3 6/7] drm/i915: Remove direct usages of intel_crtc->config from DDI code

[Ander Conselvan de Oliveira]

Remove direct usages of intel_crtc->config from the DDI code. Functions
that didn't yet take a pipe_config as an argument were coverted to do
so.

v2: s/pipe_config/const crtc_state/ (Ville)
  - take crtc from crtc_state. (Ville)
Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_ddi.c | 62 +++-
 drivers/gpu/drm/i915/intel_display.c | 12 +++
 drivers/gpu/drm/i915/intel_drv.h | 11 ---
 3 files changed, 44 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 0db526e..ebccd48 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1193,11 +1193,12 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc,
  intel_encoder);
 }
 
-void intel_ddi_set_pipe_settings(struct intel_crtc *crtc)
+void intel_ddi_set_pipe_settings(const struct intel_crtc_state *crtc_state)
 {
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
-   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
+   enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
int type = intel_encoder->type;
uint32_t temp;
 
@@ -1205,7 +1206,7 @@ void intel_ddi_set_pipe_settings(struct intel_crtc *crtc)
WARN_ON(transcoder_is_dsi(cpu_transcoder));
 
temp = TRANS_MSA_SYNC_CLK;
-   switch (crtc->config->pipe_bpp) {
+   switch (crtc_state->pipe_bpp) {
case 18:
temp |= TRANS_MSA_6_BPC;
break;
@@ -1225,10 +1226,12 @@ void intel_ddi_set_pipe_settings(struct intel_crtc 
*crtc)
}
 }
 
-void intel_ddi_set_vc_payload_alloc(struct intel_crtc *crtc, bool state)
+void intel_ddi_set_vc_payload_alloc(const struct intel_crtc_state *crtc_state,
+   bool state)
 {
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
+   enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
uint32_t temp;
temp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
if (state == true)
@@ -1238,12 +1241,13 @@ void intel_ddi_set_vc_payload_alloc(struct intel_crtc 
*crtc, bool state)
I915_WRITE(TRANS_DDI_FUNC_CTL(cpu_transcoder), temp);
 }
 
-void intel_ddi_enable_transcoder_func(struct intel_crtc *crtc)
+void intel_ddi_enable_transcoder_func(const struct intel_crtc_state 
*crtc_state)
 {
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
-   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
+   enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
enum port port = intel_ddi_get_encoder_port(intel_encoder);
int type = intel_encoder->type;
uint32_t temp;
@@ -1252,7 +1256,7 @@ void intel_ddi_enable_transcoder_func(struct intel_crtc 
*crtc)
temp = TRANS_DDI_FUNC_ENABLE;
temp |= TRANS_DDI_SELECT_PORT(port);
 
-   switch (crtc->config->pipe_bpp) {
+   switch (crtc_state->pipe_bpp) {
case 18:
temp |= TRANS_DDI_BPC_6;
break;
@@ -1269,9 +1273,9 @@ void intel_ddi_enable_transcoder_func(struct intel_crtc 
*crtc)
BUG();
}
 
-   if (crtc->config->base.adjusted_mode.flags & DRM_MODE_FLAG_PVSYNC)
+   if (crtc_state->base.adjusted_mode.flags & DRM_MODE_FLAG_PVSYNC)
temp |= TRANS_DDI_PVSYNC;
-   if (crtc->config->base.adjusted_mode.flags & DRM_MODE_FLAG_PHSYNC)
+   if (crtc_state->base.adjusted_mode.flags & DRM_MODE_FLAG_PHSYNC)
temp |= TRANS_DDI_PHSYNC;
 
if (cpu_transcoder == TRANSCODER_EDP) {
@@ -1282,8 +1286,8 @@ void intel_ddi_enable_transcoder_func(struct intel_crtc 
*crtc)
 * using motion blur mitigation (which we don't
 * support). */
if (IS_HASWELL(dev_priv) &&
-   (crtc->config->pch_pfit.enabled ||
-crtc->config->pch_pfit.force_thru))
+   (crtc_state->pch_pfit.enabled ||
+crtc_state->pch_pfit.force_thru))
   

[Intel-gfx] [PATCH v3 4/7] drm/i915: Pass pipe_config to fdi_link_train() functions

[Ander Conselvan de Oliveira]

It is preferred to pass pipe_config to functions instead of accessing
crtc->config directly. Follow suit and pass pipe_config to the fdi link
train functions.

v2: Add const; s/pipe_config/crtc_state/ (Ville)
Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_drv.h  |  3 ++-
 drivers/gpu/drm/i915/intel_ddi.c |  9 +
 drivers/gpu/drm/i915/intel_display.c | 19 +++
 drivers/gpu/drm/i915/intel_drv.h |  3 ++-
 4 files changed, 20 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b2be1a4..9b2a46a6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -669,7 +669,8 @@ struct drm_i915_display_funcs {
   struct intel_encoder *encoder,
   const struct drm_display_mode 
*adjusted_mode);
void (*audio_codec_disable)(struct intel_encoder *encoder);
-   void (*fdi_link_train)(struct intel_crtc *crtc);
+   void (*fdi_link_train)(struct intel_crtc *crtc,
+  const struct intel_crtc_state *crtc_state);
void (*init_clock_gating)(struct drm_i915_private *dev_priv);
int (*queue_flip)(struct drm_device *dev, struct drm_crtc *crtc,
  struct drm_framebuffer *fb,
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 111f660..a320378 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -674,7 +674,8 @@ static uint32_t hsw_pll_to_ddi_pll_sel(struct 
intel_shared_dpll *pll)
  * DDI A (which is used for eDP)
  */
 
-void hsw_fdi_link_train(struct intel_crtc *crtc)
+void hsw_fdi_link_train(struct intel_crtc *crtc,
+   const struct intel_crtc_state *crtc_state)
 {
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -700,7 +701,7 @@ void hsw_fdi_link_train(struct intel_crtc *crtc)
/* Enable the PCH Receiver FDI PLL */
rx_ctl_val = dev_priv->fdi_rx_config | FDI_RX_ENHANCE_FRAME_ENABLE |
 FDI_RX_PLL_ENABLE |
-FDI_DP_PORT_WIDTH(crtc->config->fdi_lanes);
+FDI_DP_PORT_WIDTH(crtc_state->fdi_lanes);
I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val);
POSTING_READ(FDI_RX_CTL(PIPE_A));
udelay(220);
@@ -710,7 +711,7 @@ void hsw_fdi_link_train(struct intel_crtc *crtc)
I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val);
 
/* Configure Port Clock Select */
-   ddi_pll_sel = hsw_pll_to_ddi_pll_sel(crtc->config->shared_dpll);
+   ddi_pll_sel = hsw_pll_to_ddi_pll_sel(crtc_state->shared_dpll);
I915_WRITE(PORT_CLK_SEL(PORT_E), ddi_pll_sel);
WARN_ON(ddi_pll_sel != PORT_CLK_SEL_SPLL);
 
@@ -730,7 +731,7 @@ void hsw_fdi_link_train(struct intel_crtc *crtc)
 * port reversal bit */
I915_WRITE(DDI_BUF_CTL(PORT_E),
   DDI_BUF_CTL_ENABLE |
-  ((crtc->config->fdi_lanes - 1) << 1) |
+  ((crtc_state->fdi_lanes - 1) << 1) |
   DDI_BUF_TRANS_SELECT(i / 2));
POSTING_READ(DDI_BUF_CTL(PORT_E));
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9dc6a1b..e516a2d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3689,7 +3689,8 @@ static void intel_fdi_normal_train(struct intel_crtc 
*crtc)
 }
 
 /* The FDI link training functions for ILK/Ibexpeak. */
-static void ironlake_fdi_link_train(struct intel_crtc *crtc)
+static void ironlake_fdi_link_train(struct intel_crtc *crtc,
+   const struct intel_crtc_state *crtc_state)
 {
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -3714,7 +3715,7 @@ static void ironlake_fdi_link_train(struct intel_crtc 
*crtc)
reg = FDI_TX_CTL(pipe);
temp = I915_READ(reg);
temp &= ~FDI_DP_PORT_WIDTH_MASK;
-   temp |= FDI_DP_PORT_WIDTH(crtc->config->fdi_lanes);
+   temp |= FDI_DP_PORT_WIDTH(crtc_state->fdi_lanes);
temp &= ~FDI_LINK_TRAIN_NONE;
temp |= FDI_LINK_TRAIN_PATTERN_1;
I915_WRITE(reg, temp | FDI_TX_ENABLE);
@@ -3789,7 +3790,8 @@ static const int snb_b_fdi_train_param[] = {
 };
 
 /* The FDI link training functions for SNB/Cougarpoint. */
-static void gen6_fdi_link_train(struct intel_crtc *crtc)
+static void gen6_fdi_link_train(struct intel_crtc *crtc,
+   const struct intel_crtc_state *crtc_state)
 {
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to

[Intel-gfx] [PATCH v3 3/7] drm/i915: Pass pipe_config to pch_enable() functions

[Ander Conselvan de Oliveira]

Using crtc->config directly is being removed in favor of passing a
pipe_config. Follow the trend and pass pipe_config to pch_enable()
functions.

v2: s/pipe_config/crtc_state/ (Ville)
  - constify crtc_state. (Ville)
  - take crtc from crtc_state. (Ville)
Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_display.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index bfb99c6..9dc6a1b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4456,8 +4456,9 @@ intel_trans_dp_port_sel(struct intel_crtc *crtc)
  *   - DP transcoding bits
  *   - transcoder
  */
-static void ironlake_pch_enable(struct intel_crtc *crtc)
+static void ironlake_pch_enable(const struct intel_crtc_state *crtc_state)
 {
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
int pipe = crtc->pipe;
@@ -4484,7 +4485,7 @@ static void ironlake_pch_enable(struct intel_crtc *crtc)
temp = I915_READ(PCH_DPLL_SEL);
temp |= TRANS_DPLL_ENABLE(pipe);
sel = TRANS_DPLLB_SEL(pipe);
-   if (crtc->config->shared_dpll ==
+   if (crtc_state->shared_dpll ==
intel_get_shared_dpll_by_id(dev_priv, DPLL_ID_PCH_PLL_B))
temp |= sel;
else
@@ -4509,9 +4510,9 @@ static void ironlake_pch_enable(struct intel_crtc *crtc)
 
/* For PCH DP, enable TRANS_DP_CTL */
if (HAS_PCH_CPT(dev_priv) &&
-   intel_crtc_has_dp_encoder(crtc->config)) {
+   intel_crtc_has_dp_encoder(crtc_state)) {
const struct drm_display_mode *adjusted_mode =
-   >config->base.adjusted_mode;
+   _state->base.adjusted_mode;
u32 bpc = (I915_READ(PIPECONF(pipe)) & PIPECONF_BPC_MASK) >> 5;
i915_reg_t reg = TRANS_DP_CTL(pipe);
temp = I915_READ(reg);
@@ -4546,10 +4547,11 @@ static void ironlake_pch_enable(struct intel_crtc *crtc)
ironlake_enable_pch_transcoder(dev_priv, pipe);
 }
 
-static void lpt_pch_enable(struct intel_crtc *crtc)
+static void lpt_pch_enable(const struct intel_crtc_state *crtc_state)
 {
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
+   enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
 
assert_pch_transcoder_disabled(dev_priv, TRANSCODER_A);
 
@@ -5283,7 +5285,7 @@ static void ironlake_crtc_enable(struct intel_crtc_state 
*pipe_config,
intel_enable_pipe(intel_crtc);
 
if (intel_crtc->config->has_pch_encoder)
-   ironlake_pch_enable(intel_crtc);
+   ironlake_pch_enable(pipe_config);
 
assert_vblank_disabled(crtc);
drm_crtc_vblank_on(crtc);
@@ -5393,7 +5395,7 @@ static void haswell_crtc_enable(struct intel_crtc_state 
*pipe_config,
intel_enable_pipe(intel_crtc);
 
if (intel_crtc->config->has_pch_encoder)
-   lpt_pch_enable(intel_crtc);
+   lpt_pch_enable(pipe_config);
 
if (intel_crtc_has_type(intel_crtc->config, INTEL_OUTPUT_DP_MST))
intel_ddi_set_vc_payload_alloc(crtc, true);
-- 
2.9.3

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

[Intel-gfx] [PATCH v3 2/7] drm/i915: Pass intel_crtc to intel_lpt_pch_enable()

[Ander Conselvan de Oliveira]

The function intel_lpt_pch_enable() needs an intel_crtc so pass that
instead of the generic crtc type.

Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_display.c | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5ed7fb1..bfb99c6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4250,10 +4250,10 @@ void lpt_disable_iclkip(struct drm_i915_private 
*dev_priv)
 }
 
 /* Program iCLKIP clock to the desired frequency */
-static void lpt_program_iclkip(struct drm_crtc *crtc)
+static void lpt_program_iclkip(struct intel_crtc *crtc)
 {
-   struct drm_i915_private *dev_priv = to_i915(crtc->dev);
-   int clock = to_intel_crtc(crtc)->config->base.adjusted_mode.crtc_clock;
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   int clock = crtc->config->base.adjusted_mode.crtc_clock;
u32 divsel, phaseinc, auxdiv, phasedir = 0;
u32 temp;
 
@@ -4546,19 +4546,17 @@ static void ironlake_pch_enable(struct intel_crtc *crtc)
ironlake_enable_pch_transcoder(dev_priv, pipe);
 }
 
-static void lpt_pch_enable(struct drm_crtc *crtc)
+static void lpt_pch_enable(struct intel_crtc *crtc)
 {
-   struct drm_device *dev = crtc->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
 
assert_pch_transcoder_disabled(dev_priv, TRANSCODER_A);
 
lpt_program_iclkip(crtc);
 
/* Set transcoder timing. */
-   ironlake_pch_transcoder_set_timings(intel_crtc, PIPE_A);
+   ironlake_pch_transcoder_set_timings(crtc, PIPE_A);
 
lpt_enable_pch_transcoder(dev_priv, cpu_transcoder);
 }
@@ -5395,7 +5393,7 @@ static void haswell_crtc_enable(struct intel_crtc_state 
*pipe_config,
intel_enable_pipe(intel_crtc);
 
if (intel_crtc->config->has_pch_encoder)
-   lpt_pch_enable(crtc);
+   lpt_pch_enable(intel_crtc);
 
if (intel_crtc_has_type(intel_crtc->config, INTEL_OUTPUT_DP_MST))
intel_ddi_set_vc_payload_alloc(crtc, true);
-- 
2.9.3

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

[Intel-gfx] [PATCH v3 0/7] Try to fix MST regression with DDI IO power domains

[Ander Conselvan de Oliveira]

Improve the clean ups, as requested by Ville:

  - s/pipe_config/crtc_state/
  - constify crtc_state
  - only pass state instead of crtc and state


Ander Conselvan de Oliveira (7):
  drm/i915: Pass intel_crtc to fdi_link_train() hooks
  drm/i915: Pass intel_crtc to intel_lpt_pch_enable()
  drm/i915: Pass pipe_config to pch_enable() functions
  drm/i915: Pass pipe_config to fdi_link_train() functions
  drm/i915: Pass intel_crtc to DDI functions called from crtc en/disable
  drm/i915: Remove direct usages of intel_crtc->config from DDI code
  drm/i915: Remove duplicate DDI enabling logic from MST path

 drivers/gpu/drm/i915/i915_drv.h  |   3 +-
 drivers/gpu/drm/i915/intel_ddi.c | 104 +--
 drivers/gpu/drm/i915/intel_display.c | 100 +
 drivers/gpu/drm/i915/intel_dp_mst.c  |  23 +---
 drivers/gpu/drm/i915/intel_drv.h |  14 +++--
 5 files changed, 112 insertions(+), 132 deletions(-)

-- 
2.9.3

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

[Intel-gfx] [PATCH v3 1/7] drm/i915: Pass intel_crtc to fdi_link_train() hooks

[Ander Conselvan de Oliveira]

The implementation of the fdi_link_train() hooks need an intel_crtc so
just pass that instead of the generic crtc type.

Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 +-
 drivers/gpu/drm/i915/intel_ddi.c | 13 
 drivers/gpu/drm/i915/intel_display.c | 63 +---
 drivers/gpu/drm/i915/intel_drv.h |  2 +-
 4 files changed, 37 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 26f36b0..b2be1a4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -669,7 +669,7 @@ struct drm_i915_display_funcs {
   struct intel_encoder *encoder,
   const struct drm_display_mode 
*adjusted_mode);
void (*audio_codec_disable)(struct intel_encoder *encoder);
-   void (*fdi_link_train)(struct drm_crtc *crtc);
+   void (*fdi_link_train)(struct intel_crtc *crtc);
void (*init_clock_gating)(struct drm_i915_private *dev_priv);
int (*queue_flip)(struct drm_device *dev, struct drm_crtc *crtc,
  struct drm_framebuffer *fb,
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index a7c08d7..111f660 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -674,15 +674,14 @@ static uint32_t hsw_pll_to_ddi_pll_sel(struct 
intel_shared_dpll *pll)
  * DDI A (which is used for eDP)
  */
 
-void hsw_fdi_link_train(struct drm_crtc *crtc)
+void hsw_fdi_link_train(struct intel_crtc *crtc)
 {
-   struct drm_device *dev = crtc->dev;
+   struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_encoder *encoder;
u32 temp, i, rx_ctl_val, ddi_pll_sel;
 
-   for_each_encoder_on_crtc(dev, crtc, encoder) {
+   for_each_encoder_on_crtc(dev, >base, encoder) {
WARN_ON(encoder->type != INTEL_OUTPUT_ANALOG);
intel_prepare_dp_ddi_buffers(encoder);
}
@@ -701,7 +700,7 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
/* Enable the PCH Receiver FDI PLL */
rx_ctl_val = dev_priv->fdi_rx_config | FDI_RX_ENHANCE_FRAME_ENABLE |
 FDI_RX_PLL_ENABLE |
-FDI_DP_PORT_WIDTH(intel_crtc->config->fdi_lanes);
+FDI_DP_PORT_WIDTH(crtc->config->fdi_lanes);
I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val);
POSTING_READ(FDI_RX_CTL(PIPE_A));
udelay(220);
@@ -711,7 +710,7 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val);
 
/* Configure Port Clock Select */
-   ddi_pll_sel = hsw_pll_to_ddi_pll_sel(intel_crtc->config->shared_dpll);
+   ddi_pll_sel = hsw_pll_to_ddi_pll_sel(crtc->config->shared_dpll);
I915_WRITE(PORT_CLK_SEL(PORT_E), ddi_pll_sel);
WARN_ON(ddi_pll_sel != PORT_CLK_SEL_SPLL);
 
@@ -731,7 +730,7 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
 * port reversal bit */
I915_WRITE(DDI_BUF_CTL(PORT_E),
   DDI_BUF_CTL_ENABLE |
-  ((intel_crtc->config->fdi_lanes - 1) << 1) |
+  ((crtc->config->fdi_lanes - 1) << 1) |
   DDI_BUF_TRANS_SELECT(i / 2));
POSTING_READ(DDI_BUF_CTL(PORT_E));
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 99e8d9c..5ed7fb1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3647,12 +3647,11 @@ static void intel_update_pipe_config(struct intel_crtc 
*crtc,
}
 }
 
-static void intel_fdi_normal_train(struct drm_crtc *crtc)
+static void intel_fdi_normal_train(struct intel_crtc *crtc)
 {
-   struct drm_device *dev = crtc->dev;
+   struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   int pipe = intel_crtc->pipe;
+   int pipe = crtc->pipe;
i915_reg_t reg;
u32 temp;
 
@@ -3690,12 +3689,11 @@ static void intel_fdi_normal_train(struct drm_crtc 
*crtc)
 }
 
 /* The FDI link training functions for ILK/Ibexpeak. */
-static void ironlake_fdi_link_train(struct drm_crtc *crtc)
+static void ironlake_fdi_link_train(struct intel_crtc *crtc)
 {
-   struct drm_device *dev = crtc->dev;
+   struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   int pipe = intel_crtc->pi

[Intel-gfx] [PATCH] drm/i915: Pass pipe_config to fdi_link_train() functions

[Ander Conselvan de Oliveira]

It is preferred to pass pipe_config to functions instead of accessing
crtc->config directly. Follow suit and pass pipe_config to the fdi link
train functions.

v2: Add const; s/pipe_config/crtc_state/ (Ville)
Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
---
 drivers/gpu/drm/i915/i915_drv.h  |  3 ++-
 drivers/gpu/drm/i915/intel_ddi.c |  9 +
 drivers/gpu/drm/i915/intel_display.c | 19 +++
 drivers/gpu/drm/i915/intel_drv.h |  3 ++-
 4 files changed, 20 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b2be1a4..9b2a46a6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -669,7 +669,8 @@ struct drm_i915_display_funcs {
   struct intel_encoder *encoder,
   const struct drm_display_mode 
*adjusted_mode);
void (*audio_codec_disable)(struct intel_encoder *encoder);
-   void (*fdi_link_train)(struct intel_crtc *crtc);
+   void (*fdi_link_train)(struct intel_crtc *crtc,
+  const struct intel_crtc_state *crtc_state);
void (*init_clock_gating)(struct drm_i915_private *dev_priv);
int (*queue_flip)(struct drm_device *dev, struct drm_crtc *crtc,
  struct drm_framebuffer *fb,
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 111f660..a320378 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -674,7 +674,8 @@ static uint32_t hsw_pll_to_ddi_pll_sel(struct 
intel_shared_dpll *pll)
  * DDI A (which is used for eDP)
  */
 
-void hsw_fdi_link_train(struct intel_crtc *crtc)
+void hsw_fdi_link_train(struct intel_crtc *crtc,
+   const struct intel_crtc_state *crtc_state)
 {
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -700,7 +701,7 @@ void hsw_fdi_link_train(struct intel_crtc *crtc)
/* Enable the PCH Receiver FDI PLL */
rx_ctl_val = dev_priv->fdi_rx_config | FDI_RX_ENHANCE_FRAME_ENABLE |
 FDI_RX_PLL_ENABLE |
-FDI_DP_PORT_WIDTH(crtc->config->fdi_lanes);
+FDI_DP_PORT_WIDTH(crtc_state->fdi_lanes);
I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val);
POSTING_READ(FDI_RX_CTL(PIPE_A));
udelay(220);
@@ -710,7 +711,7 @@ void hsw_fdi_link_train(struct intel_crtc *crtc)
I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val);
 
/* Configure Port Clock Select */
-   ddi_pll_sel = hsw_pll_to_ddi_pll_sel(crtc->config->shared_dpll);
+   ddi_pll_sel = hsw_pll_to_ddi_pll_sel(crtc_state->shared_dpll);
I915_WRITE(PORT_CLK_SEL(PORT_E), ddi_pll_sel);
WARN_ON(ddi_pll_sel != PORT_CLK_SEL_SPLL);
 
@@ -730,7 +731,7 @@ void hsw_fdi_link_train(struct intel_crtc *crtc)
 * port reversal bit */
I915_WRITE(DDI_BUF_CTL(PORT_E),
   DDI_BUF_CTL_ENABLE |
-  ((crtc->config->fdi_lanes - 1) << 1) |
+  ((crtc_state->fdi_lanes - 1) << 1) |
   DDI_BUF_TRANS_SELECT(i / 2));
POSTING_READ(DDI_BUF_CTL(PORT_E));
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9dc6a1b..e516a2d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3689,7 +3689,8 @@ static void intel_fdi_normal_train(struct intel_crtc 
*crtc)
 }
 
 /* The FDI link training functions for ILK/Ibexpeak. */
-static void ironlake_fdi_link_train(struct intel_crtc *crtc)
+static void ironlake_fdi_link_train(struct intel_crtc *crtc,
+   const struct intel_crtc_state *crtc_state)
 {
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -3714,7 +3715,7 @@ static void ironlake_fdi_link_train(struct intel_crtc 
*crtc)
reg = FDI_TX_CTL(pipe);
temp = I915_READ(reg);
temp &= ~FDI_DP_PORT_WIDTH_MASK;
-   temp |= FDI_DP_PORT_WIDTH(crtc->config->fdi_lanes);
+   temp |= FDI_DP_PORT_WIDTH(crtc_state->fdi_lanes);
temp &= ~FDI_LINK_TRAIN_NONE;
temp |= FDI_LINK_TRAIN_PATTERN_1;
I915_WRITE(reg, temp | FDI_TX_ENABLE);
@@ -3789,7 +3790,8 @@ static const int snb_b_fdi_train_param[] = {
 };
 
 /* The FDI link training functions for SNB/Cougarpoint. */
-static void gen6_fdi_link_train(struct intel_crtc *crtc)
+static void gen6_fdi_link_train(struct intel_crtc *crtc,
+   const struct intel_crtc_state *crtc_state)
 {
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -3812,7 +3814,7 @@ static void gen6_fdi_lin

[Intel-gfx] [PATCH] drm/i915: Pass pipe_config to pch_enable() functions

[Ander Conselvan de Oliveira]

Using crtc->config directly is being removed in favor of passing a
pipe_config. Follow the trend and pass pipe_config to pch_enable()
functions.

v2: s/pipe_config/crtc_state/ (Ville)
  - constify crtc_state. (Ville)
  - take crtc from crtc_state. (Ville)
Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_display.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index bfb99c6..9dc6a1b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4456,8 +4456,9 @@ intel_trans_dp_port_sel(struct intel_crtc *crtc)
  *   - DP transcoding bits
  *   - transcoder
  */
-static void ironlake_pch_enable(struct intel_crtc *crtc)
+static void ironlake_pch_enable(const struct intel_crtc_state *crtc_state)
 {
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
int pipe = crtc->pipe;
@@ -4484,7 +4485,7 @@ static void ironlake_pch_enable(struct intel_crtc *crtc)
temp = I915_READ(PCH_DPLL_SEL);
temp |= TRANS_DPLL_ENABLE(pipe);
sel = TRANS_DPLLB_SEL(pipe);
-   if (crtc->config->shared_dpll ==
+   if (crtc_state->shared_dpll ==
intel_get_shared_dpll_by_id(dev_priv, DPLL_ID_PCH_PLL_B))
temp |= sel;
else
@@ -4509,9 +4510,9 @@ static void ironlake_pch_enable(struct intel_crtc *crtc)
 
/* For PCH DP, enable TRANS_DP_CTL */
if (HAS_PCH_CPT(dev_priv) &&
-   intel_crtc_has_dp_encoder(crtc->config)) {
+   intel_crtc_has_dp_encoder(crtc_state)) {
const struct drm_display_mode *adjusted_mode =
-   >config->base.adjusted_mode;
+   _state->base.adjusted_mode;
u32 bpc = (I915_READ(PIPECONF(pipe)) & PIPECONF_BPC_MASK) >> 5;
i915_reg_t reg = TRANS_DP_CTL(pipe);
temp = I915_READ(reg);
@@ -4546,10 +4547,11 @@ static void ironlake_pch_enable(struct intel_crtc *crtc)
ironlake_enable_pch_transcoder(dev_priv, pipe);
 }
 
-static void lpt_pch_enable(struct intel_crtc *crtc)
+static void lpt_pch_enable(const struct intel_crtc_state *crtc_state)
 {
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
+   enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
 
assert_pch_transcoder_disabled(dev_priv, TRANSCODER_A);
 
@@ -5283,7 +5285,7 @@ static void ironlake_crtc_enable(struct intel_crtc_state 
*pipe_config,
intel_enable_pipe(intel_crtc);
 
if (intel_crtc->config->has_pch_encoder)
-   ironlake_pch_enable(intel_crtc);
+   ironlake_pch_enable(pipe_config);
 
assert_vblank_disabled(crtc);
drm_crtc_vblank_on(crtc);
@@ -5393,7 +5395,7 @@ static void haswell_crtc_enable(struct intel_crtc_state 
*pipe_config,
intel_enable_pipe(intel_crtc);
 
if (intel_crtc->config->has_pch_encoder)
-   lpt_pch_enable(intel_crtc);
+   lpt_pch_enable(pipe_config);
 
if (intel_crtc_has_type(intel_crtc->config, INTEL_OUTPUT_DP_MST))
intel_ddi_set_vc_payload_alloc(crtc, true);
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH v2 1/8] drm/i915: Enable DDI IO power domains in the DP MST path

[Ander Conselvan De Oliveira]

On Wed, 2017-03-01 at 16:13 +0200, Ander Conselvan de Oliveira wrote:
> Commit 62b695662a24 ("drm/i915: Only enable DDI IO power domains after
> enabling DPLL") changed how the DDI IO power domains get enabled, but
> neglected the need to enable those domains when enabling a DP connector
> with MST enabled, leading to
> 
> Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast 
> exception handler
> 
> Fixes: 62b695662a24 ("drm/i915: Only enable DDI IO power domains after 
> enabling DPLL")
> Cc: David Weinehall <david.weineh...@linux.intel.com>
> Cc: Imre Deak <imre.d...@intel.com>
> Cc: Ander Conselvan de Oliveira <ander.conselvan.de.olive...@intel.com>
> Cc: David Weinehall <david.weineh...@linux.intel.com>
> Cc: Daniel Vetter <daniel.vet...@intel.com>
> Cc: Jani Nikula <jani.nik...@linux.intel.com>
> Cc: intel-gfx@lists.freedesktop.org
> Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
> Reported-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
> Signed-off-by: Ander Conselvan de Oliveira 
> <ander.conselvan.de.olive...@intel.com>

This was already

Reviewed-by: Imre Deak <imre.d...@intel.com>

Pushed this one so the regression is fixed. Thanks for reviewing.

Ander

> ---
>  drivers/gpu/drm/i915/intel_dp_mst.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index d94fd4b..a8334e1 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -163,6 +163,9 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
> *encoder,
>   intel_ddi_clk_select(_dig_port->base,
>pipe_config->shared_dpll);
>  
> + intel_display_power_get(dev_priv,
> + intel_dig_port->ddi_io_power_domain);
> +
>   intel_prepare_dp_ddi_buffers(_dig_port->base);
>   intel_dp_set_link_params(intel_dp,
>pipe_config->port_clock,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 1/8] drm/i915: Enable DDI IO power domains in the DP MST path

[Ander Conselvan de Oliveira]

Commit 62b695662a24 ("drm/i915: Only enable DDI IO power domains after
enabling DPLL") changed how the DDI IO power domains get enabled, but
neglected the need to enable those domains when enabling a DP connector
with MST enabled, leading to

Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast 
exception handler

Fixes: 62b695662a24 ("drm/i915: Only enable DDI IO power domains after enabling 
DPLL")
Cc: David Weinehall <david.weineh...@linux.intel.com>
Cc: Imre Deak <imre.d...@intel.com>
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.olive...@intel.com>
Cc: David Weinehall <david.weineh...@linux.intel.com>
Cc: Daniel Vetter <daniel.vet...@intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
Reported-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
---
 drivers/gpu/drm/i915/intel_dp_mst.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index d94fd4b..a8334e1 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -163,6 +163,9 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
*encoder,
intel_ddi_clk_select(_dig_port->base,
 pipe_config->shared_dpll);
 
+   intel_display_power_get(dev_priv,
+   intel_dig_port->ddi_io_power_domain);
+
intel_prepare_dp_ddi_buffers(_dig_port->base);
intel_dp_set_link_params(intel_dp,
 pipe_config->port_clock,
-- 
2.9.3

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

[Intel-gfx] [PATCH v2 8/8] drm/i915: Remove duplicate DDI enabling logic from MST path

[Ander Conselvan de Oliveira]

The logic to enable a DDI in intel_mst_pre_enable_dp() is essentially
the same as in intel_ddi_pre_enable_dp(). So reuse the latter function
by calling the post_disable hook on the intel_dig_port instead of
duplicating that code.

v2: Don't oops because of a NULL encoder->crtc. (Ville)
Cc: Imre Deak <imre.d...@intel.com>
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
---
 drivers/gpu/drm/i915/intel_ddi.c|  2 ++
 drivers/gpu/drm/i915/intel_dp_mst.c | 23 +++
 2 files changed, 5 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 2f26c75..208500a 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1714,6 +1714,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
enum port port = intel_ddi_get_encoder_port(encoder);
struct intel_digital_port *dig_port = enc_to_dig_port(>base);
 
+   WARN_ON(link_mst && port == PORT_A);
+
intel_dp_set_link_params(intel_dp, link_rate, lane_count,
 link_mst);
if (encoder->type == INTEL_OUTPUT_EDP)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index a8334e1..094cbdc 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -159,26 +159,9 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
*encoder,
 
DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
 
-   if (intel_dp->active_mst_links == 0) {
-   intel_ddi_clk_select(_dig_port->base,
-pipe_config->shared_dpll);
-
-   intel_display_power_get(dev_priv,
-   intel_dig_port->ddi_io_power_domain);
-
-   intel_prepare_dp_ddi_buffers(_dig_port->base);
-   intel_dp_set_link_params(intel_dp,
-pipe_config->port_clock,
-pipe_config->lane_count,
-true);
-
-   intel_ddi_init_dp_buf_reg(_dig_port->base);
-
-   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
-
-   intel_dp_start_link_train(intel_dp);
-   intel_dp_stop_link_train(intel_dp);
-   }
+   if (intel_dp->active_mst_links == 0)
+   intel_dig_port->base.pre_enable(_dig_port->base,
+   pipe_config, NULL);
 
ret = drm_dp_mst_allocate_vcpi(_dp->mst_mgr,
   connector->port,
-- 
2.9.3

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

[Intel-gfx] [PATCH v2 5/8] drm/i915: Pass pipe_config to fdi_link_train() functions

[Ander Conselvan de Oliveira]

It is preferred to pass pipe_config to functions instead of accessing
crtc->config directly. Follow suit and pass pipe_config to the fdi link
train functions.

Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
---
 drivers/gpu/drm/i915/i915_drv.h  |  3 ++-
 drivers/gpu/drm/i915/intel_ddi.c |  9 +
 drivers/gpu/drm/i915/intel_display.c | 19 +++
 drivers/gpu/drm/i915/intel_drv.h |  3 ++-
 4 files changed, 20 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8b11cdf..82d3d16 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -669,7 +669,8 @@ struct drm_i915_display_funcs {
   struct intel_encoder *encoder,
   const struct drm_display_mode 
*adjusted_mode);
void (*audio_codec_disable)(struct intel_encoder *encoder);
-   void (*fdi_link_train)(struct intel_crtc *crtc);
+   void (*fdi_link_train)(struct intel_crtc *crtc,
+  struct intel_crtc_state *pipe_config);
void (*init_clock_gating)(struct drm_i915_private *dev_priv);
int (*queue_flip)(struct drm_device *dev, struct drm_crtc *crtc,
  struct drm_framebuffer *fb,
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 111f660..ccff024 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -674,7 +674,8 @@ static uint32_t hsw_pll_to_ddi_pll_sel(struct 
intel_shared_dpll *pll)
  * DDI A (which is used for eDP)
  */
 
-void hsw_fdi_link_train(struct intel_crtc *crtc)
+void hsw_fdi_link_train(struct intel_crtc *crtc,
+   struct intel_crtc_state *pipe_config)
 {
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -700,7 +701,7 @@ void hsw_fdi_link_train(struct intel_crtc *crtc)
/* Enable the PCH Receiver FDI PLL */
rx_ctl_val = dev_priv->fdi_rx_config | FDI_RX_ENHANCE_FRAME_ENABLE |
 FDI_RX_PLL_ENABLE |
-FDI_DP_PORT_WIDTH(crtc->config->fdi_lanes);
+FDI_DP_PORT_WIDTH(pipe_config->fdi_lanes);
I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val);
POSTING_READ(FDI_RX_CTL(PIPE_A));
udelay(220);
@@ -710,7 +711,7 @@ void hsw_fdi_link_train(struct intel_crtc *crtc)
I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val);
 
/* Configure Port Clock Select */
-   ddi_pll_sel = hsw_pll_to_ddi_pll_sel(crtc->config->shared_dpll);
+   ddi_pll_sel = hsw_pll_to_ddi_pll_sel(pipe_config->shared_dpll);
I915_WRITE(PORT_CLK_SEL(PORT_E), ddi_pll_sel);
WARN_ON(ddi_pll_sel != PORT_CLK_SEL_SPLL);
 
@@ -730,7 +731,7 @@ void hsw_fdi_link_train(struct intel_crtc *crtc)
 * port reversal bit */
I915_WRITE(DDI_BUF_CTL(PORT_E),
   DDI_BUF_CTL_ENABLE |
-  ((crtc->config->fdi_lanes - 1) << 1) |
+  ((pipe_config->fdi_lanes - 1) << 1) |
   DDI_BUF_TRANS_SELECT(i / 2));
POSTING_READ(DDI_BUF_CTL(PORT_E));
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index aea302b..16822ef 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3689,7 +3689,8 @@ static void intel_fdi_normal_train(struct intel_crtc 
*crtc)
 }
 
 /* The FDI link training functions for ILK/Ibexpeak. */
-static void ironlake_fdi_link_train(struct intel_crtc *crtc)
+static void ironlake_fdi_link_train(struct intel_crtc *crtc,
+   struct intel_crtc_state *pipe_config)
 {
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -3714,7 +3715,7 @@ static void ironlake_fdi_link_train(struct intel_crtc 
*crtc)
reg = FDI_TX_CTL(pipe);
temp = I915_READ(reg);
temp &= ~FDI_DP_PORT_WIDTH_MASK;
-   temp |= FDI_DP_PORT_WIDTH(crtc->config->fdi_lanes);
+   temp |= FDI_DP_PORT_WIDTH(pipe_config->fdi_lanes);
temp &= ~FDI_LINK_TRAIN_NONE;
temp |= FDI_LINK_TRAIN_PATTERN_1;
I915_WRITE(reg, temp | FDI_TX_ENABLE);
@@ -3789,7 +3790,8 @@ static const int snb_b_fdi_train_param[] = {
 };
 
 /* The FDI link training functions for SNB/Cougarpoint. */
-static void gen6_fdi_link_train(struct intel_crtc *crtc)
+static void gen6_fdi_link_train(struct intel_crtc *crtc,
+   struct intel_crtc_state *pipe_config)
 {
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -3812,7 +3814,7 @@ static void gen6_fdi_link_train(struct intel_crtc *crtc)
reg = FDI_TX_CTL(pipe);
   

[Intel-gfx] [PATCH v2 7/8] drm/i915: Remove direct usages of intel_crtc->config from DDI code

[Ander Conselvan de Oliveira]

Remove direct usages of intel_crtc->config from the DDI code. Functions
that didn't yet take a pipe_config as an argument were coverted to do
so.

Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
---
 drivers/gpu/drm/i915/intel_ddi.c | 61 +++-
 drivers/gpu/drm/i915/intel_display.c | 12 +++
 drivers/gpu/drm/i915/intel_drv.h | 16 +++---
 3 files changed, 49 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 5e21bb5..2f26c75 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1193,11 +1193,12 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc,
  intel_encoder);
 }
 
-void intel_ddi_set_pipe_settings(struct intel_crtc *crtc)
+void intel_ddi_set_pipe_settings(struct intel_crtc *crtc,
+struct intel_crtc_state *pipe_config)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
-   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
+   enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
int type = intel_encoder->type;
uint32_t temp;
 
@@ -1205,7 +1206,7 @@ void intel_ddi_set_pipe_settings(struct intel_crtc *crtc)
WARN_ON(transcoder_is_dsi(cpu_transcoder));
 
temp = TRANS_MSA_SYNC_CLK;
-   switch (crtc->config->pipe_bpp) {
+   switch (pipe_config->pipe_bpp) {
case 18:
temp |= TRANS_MSA_6_BPC;
break;
@@ -1225,10 +1226,12 @@ void intel_ddi_set_pipe_settings(struct intel_crtc 
*crtc)
}
 }
 
-void intel_ddi_set_vc_payload_alloc(struct intel_crtc *crtc, bool state)
+void intel_ddi_set_vc_payload_alloc(struct intel_crtc *crtc,
+   struct intel_crtc_state *pipe_config,
+   bool state)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
+   enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
uint32_t temp;
temp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
if (state == true)
@@ -1238,12 +1241,13 @@ void intel_ddi_set_vc_payload_alloc(struct intel_crtc 
*crtc, bool state)
I915_WRITE(TRANS_DDI_FUNC_CTL(cpu_transcoder), temp);
 }
 
-void intel_ddi_enable_transcoder_func(struct intel_crtc *crtc)
+void intel_ddi_enable_transcoder_func(struct intel_crtc *crtc,
+ struct intel_crtc_state *pipe_config)
 {
struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
-   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
+   enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
enum port port = intel_ddi_get_encoder_port(intel_encoder);
int type = intel_encoder->type;
uint32_t temp;
@@ -1252,7 +1256,7 @@ void intel_ddi_enable_transcoder_func(struct intel_crtc 
*crtc)
temp = TRANS_DDI_FUNC_ENABLE;
temp |= TRANS_DDI_SELECT_PORT(port);
 
-   switch (crtc->config->pipe_bpp) {
+   switch (pipe_config->pipe_bpp) {
case 18:
temp |= TRANS_DDI_BPC_6;
break;
@@ -1269,9 +1273,9 @@ void intel_ddi_enable_transcoder_func(struct intel_crtc 
*crtc)
BUG();
}
 
-   if (crtc->config->base.adjusted_mode.flags & DRM_MODE_FLAG_PVSYNC)
+   if (pipe_config->base.adjusted_mode.flags & DRM_MODE_FLAG_PVSYNC)
temp |= TRANS_DDI_PVSYNC;
-   if (crtc->config->base.adjusted_mode.flags & DRM_MODE_FLAG_PHSYNC)
+   if (pipe_config->base.adjusted_mode.flags & DRM_MODE_FLAG_PHSYNC)
temp |= TRANS_DDI_PHSYNC;
 
if (cpu_transcoder == TRANSCODER_EDP) {
@@ -1282,8 +1286,8 @@ void intel_ddi_enable_transcoder_func(struct intel_crtc 
*crtc)
 * using motion blur mitigation (which we don't
 * support). */
if (IS_HASWELL(dev_priv) &&
-   (crtc->config->pch_pfit.enabled ||
-crtc->config->pch_pfit.force_thru))
+   (pipe_config->pch_pfit.enabled ||
+pipe_config->pch_pfit.force_thru))
temp |= TRANS_DDI_EDP_INPUT_A_ONOFF;
else
temp |= TRANS_DDI_EDP_INPUT_A_ON;
@@ -1301,20 +1305,20 @@ void intel_ddi_enable_transcoder

[Intel-gfx] [PATCH v2 3/8] drm/i915: Pass intel_crtc to intel_lpt_pch_enable()

[Ander Conselvan de Oliveira]

The function intel_lpt_pch_enable() needs an intel_crtc so pass that
instead of the generic crtc type.

Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
---
 drivers/gpu/drm/i915/intel_display.c | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index c627f7e..45415f0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4250,10 +4250,10 @@ void lpt_disable_iclkip(struct drm_i915_private 
*dev_priv)
 }
 
 /* Program iCLKIP clock to the desired frequency */
-static void lpt_program_iclkip(struct drm_crtc *crtc)
+static void lpt_program_iclkip(struct intel_crtc *crtc)
 {
-   struct drm_i915_private *dev_priv = to_i915(crtc->dev);
-   int clock = to_intel_crtc(crtc)->config->base.adjusted_mode.crtc_clock;
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   int clock = crtc->config->base.adjusted_mode.crtc_clock;
u32 divsel, phaseinc, auxdiv, phasedir = 0;
u32 temp;
 
@@ -4546,19 +4546,17 @@ static void ironlake_pch_enable(struct intel_crtc *crtc)
ironlake_enable_pch_transcoder(dev_priv, pipe);
 }
 
-static void lpt_pch_enable(struct drm_crtc *crtc)
+static void lpt_pch_enable(struct intel_crtc *crtc)
 {
-   struct drm_device *dev = crtc->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
 
assert_pch_transcoder_disabled(dev_priv, TRANSCODER_A);
 
lpt_program_iclkip(crtc);
 
/* Set transcoder timing. */
-   ironlake_pch_transcoder_set_timings(intel_crtc, PIPE_A);
+   ironlake_pch_transcoder_set_timings(crtc, PIPE_A);
 
lpt_enable_pch_transcoder(dev_priv, cpu_transcoder);
 }
@@ -5395,7 +5393,7 @@ static void haswell_crtc_enable(struct intel_crtc_state 
*pipe_config,
intel_enable_pipe(intel_crtc);
 
if (intel_crtc->config->has_pch_encoder)
-   lpt_pch_enable(crtc);
+   lpt_pch_enable(intel_crtc);
 
if (intel_crtc_has_type(intel_crtc->config, INTEL_OUTPUT_DP_MST))
intel_ddi_set_vc_payload_alloc(crtc, true);
-- 
2.9.3

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

[Intel-gfx] [PATCH v2 2/8] drm/i915: Pass intel_crtc to fdi_link_train() hooks

[Ander Conselvan de Oliveira]

The implementation of the fdi_link_train() hooks need an intel_crtc so
just pass that instead of the generic crtc type.

Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 +-
 drivers/gpu/drm/i915/intel_ddi.c | 13 
 drivers/gpu/drm/i915/intel_display.c | 63 +---
 drivers/gpu/drm/i915/intel_drv.h |  2 +-
 4 files changed, 37 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bc9283b..8b11cdf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -669,7 +669,7 @@ struct drm_i915_display_funcs {
   struct intel_encoder *encoder,
   const struct drm_display_mode 
*adjusted_mode);
void (*audio_codec_disable)(struct intel_encoder *encoder);
-   void (*fdi_link_train)(struct drm_crtc *crtc);
+   void (*fdi_link_train)(struct intel_crtc *crtc);
void (*init_clock_gating)(struct drm_i915_private *dev_priv);
int (*queue_flip)(struct drm_device *dev, struct drm_crtc *crtc,
  struct drm_framebuffer *fb,
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index a7c08d7..111f660 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -674,15 +674,14 @@ static uint32_t hsw_pll_to_ddi_pll_sel(struct 
intel_shared_dpll *pll)
  * DDI A (which is used for eDP)
  */
 
-void hsw_fdi_link_train(struct drm_crtc *crtc)
+void hsw_fdi_link_train(struct intel_crtc *crtc)
 {
-   struct drm_device *dev = crtc->dev;
+   struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_encoder *encoder;
u32 temp, i, rx_ctl_val, ddi_pll_sel;
 
-   for_each_encoder_on_crtc(dev, crtc, encoder) {
+   for_each_encoder_on_crtc(dev, >base, encoder) {
WARN_ON(encoder->type != INTEL_OUTPUT_ANALOG);
intel_prepare_dp_ddi_buffers(encoder);
}
@@ -701,7 +700,7 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
/* Enable the PCH Receiver FDI PLL */
rx_ctl_val = dev_priv->fdi_rx_config | FDI_RX_ENHANCE_FRAME_ENABLE |
 FDI_RX_PLL_ENABLE |
-FDI_DP_PORT_WIDTH(intel_crtc->config->fdi_lanes);
+FDI_DP_PORT_WIDTH(crtc->config->fdi_lanes);
I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val);
POSTING_READ(FDI_RX_CTL(PIPE_A));
udelay(220);
@@ -711,7 +710,7 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val);
 
/* Configure Port Clock Select */
-   ddi_pll_sel = hsw_pll_to_ddi_pll_sel(intel_crtc->config->shared_dpll);
+   ddi_pll_sel = hsw_pll_to_ddi_pll_sel(crtc->config->shared_dpll);
I915_WRITE(PORT_CLK_SEL(PORT_E), ddi_pll_sel);
WARN_ON(ddi_pll_sel != PORT_CLK_SEL_SPLL);
 
@@ -731,7 +730,7 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
 * port reversal bit */
I915_WRITE(DDI_BUF_CTL(PORT_E),
   DDI_BUF_CTL_ENABLE |
-  ((intel_crtc->config->fdi_lanes - 1) << 1) |
+  ((crtc->config->fdi_lanes - 1) << 1) |
   DDI_BUF_TRANS_SELECT(i / 2));
POSTING_READ(DDI_BUF_CTL(PORT_E));
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7673d5d..c627f7e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3647,12 +3647,11 @@ static void intel_update_pipe_config(struct intel_crtc 
*crtc,
}
 }
 
-static void intel_fdi_normal_train(struct drm_crtc *crtc)
+static void intel_fdi_normal_train(struct intel_crtc *crtc)
 {
-   struct drm_device *dev = crtc->dev;
+   struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   int pipe = intel_crtc->pipe;
+   int pipe = crtc->pipe;
i915_reg_t reg;
u32 temp;
 
@@ -3690,12 +3689,11 @@ static void intel_fdi_normal_train(struct drm_crtc 
*crtc)
 }
 
 /* The FDI link training functions for ILK/Ibexpeak. */
-static void ironlake_fdi_link_train(struct drm_crtc *crtc)
+static void ironlake_fdi_link_train(struct intel_crtc *crtc)
 {
-   struct drm_device *dev = crtc->dev;
+   struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   int pipe = intel_crtc->pipe;
+   int pipe = crtc->pipe;
i915_reg_t reg;
   

[Intel-gfx] [PATCH v2 0/8] Try to fix MST regression with DDI IO power domains

[Ander Conselvan de Oliveira]

Hi,

Here's a v2 of the fix for the regression caused by the recent DDI IO
power domain changes. This time with moar patches and actual testing.
The new patches remove the usage of crtc->config from intel_ddi.c and
that also removes the oops with encoder->crtc being NULL.

Ander Conselvan de Oliveira (8):
  drm/i915: Enable DDI IO power domains in the DP MST path
  drm/i915: Pass intel_crtc to fdi_link_train() hooks
  drm/i915: Pass intel_crtc to intel_lpt_pch_enable()
  drm/i915: Pass pipe_config to pch_enable() functions
  drm/i915: Pass pipe_config to fdi_link_train() functions
  drm/i915: Pass intel_crtc to DDI functions called from crtc en/disable
  drm/i915: Remove direct usages of intel_crtc->config from DDI code
  drm/i915: Remove duplicate DDI enabling logic from MST path

 drivers/gpu/drm/i915/i915_drv.h  |   3 +-
 drivers/gpu/drm/i915/intel_ddi.c | 103 +--
 drivers/gpu/drm/i915/intel_display.c | 100 +-
 drivers/gpu/drm/i915/intel_dp_mst.c  |  20 +--
 drivers/gpu/drm/i915/intel_drv.h |  19 +--
 5 files changed, 117 insertions(+), 128 deletions(-)

-- 
2.9.3

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

[Intel-gfx] [PATCH v2 6/8] drm/i915: Pass intel_crtc to DDI functions called from crtc en/disable

[Ander Conselvan de Oliveira]

Pass intel_crtc to functions intel_ddi_enable_transcoder_func(),
intel_ddi_set_pipe_settings() and intel_ddi_set_vc_payload_alloc(),
instead of the generic crtc type. By changing the functions
intel_ddi_get_crtc_encoder() so that it receives an intel_crtc
parameter, there is no need for the drm_crtc in the callers.

Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
---
 drivers/gpu/drm/i915/intel_ddi.c | 62 
 drivers/gpu/drm/i915/intel_display.c |  8 ++---
 drivers/gpu/drm/i915/intel_drv.h |  6 ++--
 3 files changed, 34 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ccff024..5e21bb5 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -818,21 +818,20 @@ void intel_ddi_init_dp_buf_reg(struct intel_encoder 
*encoder)
 }
 
 static struct intel_encoder *
-intel_ddi_get_crtc_encoder(struct drm_crtc *crtc)
+intel_ddi_get_crtc_encoder(struct intel_crtc *crtc)
 {
-   struct drm_device *dev = crtc->dev;
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct drm_device *dev = crtc->base.dev;
struct intel_encoder *intel_encoder, *ret = NULL;
int num_encoders = 0;
 
-   for_each_encoder_on_crtc(dev, crtc, intel_encoder) {
+   for_each_encoder_on_crtc(dev, >base, intel_encoder) {
ret = intel_encoder;
num_encoders++;
}
 
if (num_encoders != 1)
WARN(1, "%d encoders on crtc for pipe %c\n", num_encoders,
-pipe_name(intel_crtc->pipe));
+pipe_name(crtc->pipe));
 
BUG_ON(ret == NULL);
return ret;
@@ -1194,12 +1193,11 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc,
  intel_encoder);
 }
 
-void intel_ddi_set_pipe_settings(struct drm_crtc *crtc)
+void intel_ddi_set_pipe_settings(struct intel_crtc *crtc)
 {
-   struct drm_i915_private *dev_priv = to_i915(crtc->dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
-   enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
+   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
int type = intel_encoder->type;
uint32_t temp;
 
@@ -1207,7 +1205,7 @@ void intel_ddi_set_pipe_settings(struct drm_crtc *crtc)
WARN_ON(transcoder_is_dsi(cpu_transcoder));
 
temp = TRANS_MSA_SYNC_CLK;
-   switch (intel_crtc->config->pipe_bpp) {
+   switch (crtc->config->pipe_bpp) {
case 18:
temp |= TRANS_MSA_6_BPC;
break;
@@ -1227,12 +1225,10 @@ void intel_ddi_set_pipe_settings(struct drm_crtc *crtc)
}
 }
 
-void intel_ddi_set_vc_payload_alloc(struct drm_crtc *crtc, bool state)
+void intel_ddi_set_vc_payload_alloc(struct intel_crtc *crtc, bool state)
 {
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   struct drm_device *dev = crtc->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
uint32_t temp;
temp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
if (state == true)
@@ -1242,14 +1238,12 @@ void intel_ddi_set_vc_payload_alloc(struct drm_crtc 
*crtc, bool state)
I915_WRITE(TRANS_DDI_FUNC_CTL(cpu_transcoder), temp);
 }
 
-void intel_ddi_enable_transcoder_func(struct drm_crtc *crtc)
+void intel_ddi_enable_transcoder_func(struct intel_crtc *crtc)
 {
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
-   struct drm_device *dev = crtc->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   enum pipe pipe = intel_crtc->pipe;
-   enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   enum pipe pipe = crtc->pipe;
+   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
enum port port = intel_ddi_get_encoder_port(intel_encoder);
int type = intel_encoder->type;
uint32_t temp;
@@ -1258,7 +1252,7 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc 
*crtc)
temp = TRANS_DDI_FUNC_ENABLE;
temp |= TRANS_DDI_SELECT_PORT(port);
 
-   switch (intel_crtc->config->pipe_bpp) {
+   switch (crtc->config->pipe_bpp) {
case 18:
  

[Intel-gfx] [PATCH v2 4/8] drm/i915: Pass pipe_config to pch_enable() functions

[Ander Conselvan de Oliveira]

Using crtc->config directly is being removed in favor of passing a
pipe_config. Follow the trend and pass pipe_config to pch_enable()
functions.

Signed-off-by: Ander Conselvan de Oliveira 
<ander.conselvan.de.olive...@intel.com>
---
 drivers/gpu/drm/i915/intel_display.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 45415f0..aea302b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4456,7 +4456,8 @@ intel_trans_dp_port_sel(struct intel_crtc *crtc)
  *   - DP transcoding bits
  *   - transcoder
  */
-static void ironlake_pch_enable(struct intel_crtc *crtc)
+static void ironlake_pch_enable(struct intel_crtc *crtc,
+   struct intel_crtc_state *pipe_config)
 {
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -4484,7 +4485,7 @@ static void ironlake_pch_enable(struct intel_crtc *crtc)
temp = I915_READ(PCH_DPLL_SEL);
temp |= TRANS_DPLL_ENABLE(pipe);
sel = TRANS_DPLLB_SEL(pipe);
-   if (crtc->config->shared_dpll ==
+   if (pipe_config->shared_dpll ==
intel_get_shared_dpll_by_id(dev_priv, DPLL_ID_PCH_PLL_B))
temp |= sel;
else
@@ -4509,9 +4510,9 @@ static void ironlake_pch_enable(struct intel_crtc *crtc)
 
/* For PCH DP, enable TRANS_DP_CTL */
if (HAS_PCH_CPT(dev_priv) &&
-   intel_crtc_has_dp_encoder(crtc->config)) {
+   intel_crtc_has_dp_encoder(pipe_config)) {
const struct drm_display_mode *adjusted_mode =
-   >config->base.adjusted_mode;
+   _config->base.adjusted_mode;
u32 bpc = (I915_READ(PIPECONF(pipe)) & PIPECONF_BPC_MASK) >> 5;
i915_reg_t reg = TRANS_DP_CTL(pipe);
temp = I915_READ(reg);
@@ -4546,10 +4547,11 @@ static void ironlake_pch_enable(struct intel_crtc *crtc)
ironlake_enable_pch_transcoder(dev_priv, pipe);
 }
 
-static void lpt_pch_enable(struct intel_crtc *crtc)
+static void lpt_pch_enable(struct intel_crtc *crtc,
+  struct intel_crtc_state *pipe_config)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
+   enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
 
assert_pch_transcoder_disabled(dev_priv, TRANSCODER_A);
 
@@ -5283,7 +5285,7 @@ static void ironlake_crtc_enable(struct intel_crtc_state 
*pipe_config,
intel_enable_pipe(intel_crtc);
 
if (intel_crtc->config->has_pch_encoder)
-   ironlake_pch_enable(intel_crtc);
+   ironlake_pch_enable(intel_crtc, pipe_config);
 
assert_vblank_disabled(crtc);
drm_crtc_vblank_on(crtc);
@@ -5393,7 +5395,7 @@ static void haswell_crtc_enable(struct intel_crtc_state 
*pipe_config,
intel_enable_pipe(intel_crtc);
 
if (intel_crtc->config->has_pch_encoder)
-   lpt_pch_enable(intel_crtc);
+   lpt_pch_enable(intel_crtc, pipe_config);
 
if (intel_crtc_has_type(intel_crtc->config, INTEL_OUTPUT_DP_MST))
intel_ddi_set_vc_payload_alloc(crtc, true);
-- 
2.9.3

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Try to fix MST regression with DDI IO power domains

[Ander Conselvan De Oliveira]

On Tue, 2017-02-28 at 07:53 +, Patchwork wrote:
> == Series Details ==
> 
> Series: Try to fix MST regression with DDI IO power domains
> URL   : https://patchwork.freedesktop.org/series/20345/
> State : failure
> 
> == Summary ==
> 
> Series 20345v1 Try to fix MST regression with DDI IO power domains
> https://patchwork.freedesktop.org/api/1.0/series/20345/revisions/1/mbox/
> 
> Test gem_exec_flush:
> Subgroup basic-batch-kernel-default-uc:
> pass   -> FAIL   (fi-snb-2600)

I filed a bug for this one, it happened a couple of times in the past CI rounds.

https://bugs.freedesktop.org/show_bug.cgi?id=17


> Test gem_exec_parallel:
> Subgroup basic:
> pass   -> DMESG-WARN (fi-skl-6700hq)

I'm not sure what to make of this:

[  276.628178] BUG: spinlock already unlocked on CPU#6, gem_exec_parall/6632
[  276.628185]  lock: 0x8801a0f53220, .magic: dead4ead, .owner: /-1, 
.owner_cpu: -1
[  276.628190] CPU: 6 PID: 6632 Comm: gem_exec_parall Not tainted 
4.10.0-CI-Patchwork_3992+ #1
[  276.628193] Hardware name: TOSHIBA SATELLITE P50-C/06F4  
  , BIOS 1.20 10/08/2015
[  276.628197] Call Trace:
[  276.628198]  
[  276.628202]  dump_stack+0x67/0x92
[  276.628205]  spin_dump+0x73/0xc0
[  276.628208]  do_raw_spin_unlock+0x79/0xb0
[  276.628212]  _raw_spin_unlock_irqrestore+0x27/0x60
[  276.628216]  dma_fence_signal+0x160/0x230
[  276.628242]  notify_ring+0xae/0x2e0 [i915]
[  276.628255]  ? ibx_hpd_irq_handler+0xc0/0xc0 [i915]
[  276.628269]  gen8_gt_irq_handler+0x219/0x290 [i915]
[  276.628283]  gen8_irq_handler+0x8e/0x6b0 [i915]
[  276.628286]  __handle_irq_event_percpu+0x58/0x370
[  276.628289]  handle_irq_event_percpu+0x1e/0x50
[  276.628292]  handle_irq_event+0x34/0x60
[  276.628294]  handle_edge_irq+0xbe/0x150
[  276.628299]  handle_irq+0x15/0x20
[  276.628302]  do_IRQ+0x63/0x130
[  276.628306]  common_interrupt+0x90/0x90
[  276.628310] RIP: 0010:osq_lock+0x77/0x110
[  276.628313] RSP: 0018:c90009113a80 EFLAGS: 0246 ORIG_RAX: 
ffad
[  276.628318] RAX:  RBX: 880281d98d40 RCX: 88022181d758
[  276.628322] RDX: 88022181cf40 RSI: 81c65a58 RDI: 81c73840
[  276.628325] RBP: c90009113a98 R08: 3f352d81 R09: 3e2d9cbd
[  276.628329] R10: 0001 R11: 0001 R12: 880281c18d40
[  276.628333] R13: 88026ab400b0 R14:  R15: 88026ab40070
[  276.628336]  
[  276.628340]  mutex_optimistic_spin+0xf4/0x2a0
[  276.628343]  ? mutex_optimistic_spin+0x39/0x2a0
[  276.628362]  ? i915_mutex_lock_interruptible+0x39/0x140 [i915]
[  276.628366]  mutex_lock_interruptible_nested+0xa9/0x920
[  276.628399]  ? i915_mutex_lock_interruptible+0x39/0x140 [i915]
[  276.628416]  ? i915_mutex_lock_interruptible+0x39/0x140 [i915]
[  276.628433]  i915_mutex_lock_interruptible+0x39/0x140 [i915]
[  276.628437]  ? __pm_runtime_resume+0x56/0x80
[  276.628453]  i915_gem_do_execbuffer.isra.15+0x419/0x1ba0 [i915]
[  276.628457]  ? __lock_acquire+0x449/0x1b50
[  276.628461]  ? __might_fault+0x3e/0x90
[  276.628464]  ? __might_fault+0x87/0x90
[  276.628467]  ? __might_fault+0x3e/0x90
[  276.628482]  i915_gem_execbuffer2+0xb5/0x220 [i915]
[  276.628487]  drm_ioctl+0x200/0x450
[  276.628502]  ? i915_gem_execbuffer+0x330/0x330 [i915]
[  276.628507]  do_vfs_ioctl+0x90/0x6e0
[  276.628510]  ? __fget+0x108/0x200
[  276.628513]  ? expand_files+0x2b0/0x2b0
[  276.628517]  SyS_ioctl+0x3c/0x70
[  276.628520]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[  276.628523] RIP: 0033:0x7f5914d87357
[  276.628526] RSP: 002b:7f58ed475bf8 EFLAGS: 0246 ORIG_RAX: 
0010
[  276.628531] RAX: ffda RBX: 81474ff3 RCX: 7f5914d87357
[  276.628534] RDX: 7f58ed475c70 RSI: 40406469 RDI: 0003
[  276.628538] RBP: c90009113f88 R08: 0040 R09: 03f7
[  276.628541] R10:  R11: 0246 R12: 
[  276.628545] R13: 0003 R14: 40406469 R15: 024105f0
[  276.628549]  ? __this_cpu_preempt_check+0x13/0x20


Ander

> fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
> fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
> fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
> fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
> fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
> fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
> fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
> fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
> fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
> fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
> fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0