[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Extract intel_encoder_has_connectors()

[Patchwork]

== Summary ==

Series 3540v1 drm/i915: Extract intel_encoder_has_connectors()
http://patchwork.freedesktop.org/api/1.0/series/3540/revisions/1/mbox/

Test kms_flip:
Subgroup basic-flip-vs-dpms:
dmesg-warn -> PASS   (ilk-hp8440p) UNSTABLE
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (skl-i5k-2) UNSTABLE
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (skl-i5k-2) UNSTABLE

bdw-nuci7total:162  pass:152  dwarn:0   dfail:0   fail:0   skip:10 
bdw-ultratotal:165  pass:152  dwarn:0   dfail:0   fail:0   skip:13 
bsw-nuc-2total:165  pass:134  dwarn:2   dfail:0   fail:0   skip:29 
byt-nuc  total:165  pass:140  dwarn:1   dfail:0   fail:0   skip:24 
hsw-gt2  total:165  pass:154  dwarn:0   dfail:0   fail:1   skip:10 
ilk-hp8440p  total:165  pass:116  dwarn:0   dfail:0   fail:1   skip:48 
ivb-t430stotal:165  pass:150  dwarn:0   dfail:0   fail:1   skip:14 
skl-i5k-2total:165  pass:149  dwarn:1   dfail:0   fail:0   skip:15 
snb-dellxps  total:165  pass:142  dwarn:0   dfail:0   fail:1   skip:22 
snb-x220ttotal:165  pass:142  dwarn:0   dfail:0   fail:2   skip:21 

Results at /archive/results/CI_IGT_test/Patchwork_1428/

631053ba117c294f0cdfe704718a040b4406a240 drm-intel-nightly: 
2016y-02m-17d-21h-05m-38s UTC integration manifest
739dffa23ebca5fb05f3bc1520a4b5ed4f215bac drm/i915: Extract 
intel_encoder_has_connectors()

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

Re: [Intel-gfx] [PATCH] drm/i915: Disable FDI RX before DDI_BUF_CTL

[Runyan, Arthur J]

Some bit rot there.  I'll fix the numbering.  Thanks for pointing it out.
I did keep the second, redundant, FDI RX disable in place to limit some closed 
source driver changes.  There is no downside to clearing bit 31 twice. 

>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Wednesday, February 17, 2016 9:37 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Paulo Zanoni; Runyan, Arthur J
>Subject: Re: [PATCH] drm/i915: Disable FDI RX before DDI_BUF_CTL
>
>On Tue, Dec 08, 2015 at 04:47:55PM +0200, ville.syrj...@linux.intel.com wrote:
>> From: Ville Syrjälä 
>>
>> Bspec is confused w.r.t. the HSW/BDW FDI disable sequence. It lists
>> FDI RX disable both as step 13 and step 18 in the sequence. But I dug
>> up an old BUN mail from Art that moved the FDI RX disable to happen
>> before DDI_BUF_CTL disable. That BUN did not renumber the steps and just
>> added a note:
>> "Workaround: Disable PCH FDI Receiver before disabling DDI_BUF_CTL."
>>
>> The BUN described the symptoms of the fixed issue as:
>> "PCH display underflow and a black screen on the analog CRT port that
>> happened after a FDI re-train"
>>
>> I suppose later someone tried to renumber the steps to match, but forgot
>> to remove the FDI RX disable from its old position in the sequence.
>>
>> They also forgot to update the note describing what should be done in
>> case of an FDI training failure. Currently it says:
>> "To retry FDI training, follow the Disable Sequence steps to Disable FDI,
>> but skip the steps related to clocks and PLLs (16, 19, and 20), ..."
>>
>> It should really say "17, 20, and 21" with the current sequence because
>> those are the steps that deal with PLLs and whatnot, after step 13 became
>> FDI RX disable. And had the step 18 FDI RX disable been removed, as I
>> suspect it should have, the note should actually say "17, 19, and 20".
>>
>> So, let's move the FDI RX disable to happen before DDI_BUF_CTL disable,
>> as that would appear to be the correct order based on the BUN.
>
>Ping. Art, I hear you're back now ;) Any thoughts on this change, and
>the slight mess in Bspec?
>
>
>>
>> Cc: Paulo Zanoni 
>> Cc: Art Runyan 
>> Signed-off-by: Ville Syrjälä 
>> ---
>>  drivers/gpu/drm/i915/intel_ddi.c | 18 --
>>  1 file changed, 12 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
>> b/drivers/gpu/drm/i915/intel_ddi.c
>> index 5d20c64d8566..a89a17b7bb76 100644
>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> @@ -687,6 +687,10 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
>>  break;
>>  }
>>
>> +rx_ctl_val &= ~FDI_RX_ENABLE;
>> +I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val);
>> +POSTING_READ(FDI_RX_CTL(PIPE_A));
>> +
>>  temp = I915_READ(DDI_BUF_CTL(PORT_E));
>>  temp &= ~DDI_BUF_CTL_ENABLE;
>>  I915_WRITE(DDI_BUF_CTL(PORT_E), temp);
>> @@ -701,10 +705,6 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
>>
>>  intel_wait_ddi_buf_idle(dev_priv, PORT_E);
>>
>> -rx_ctl_val &= ~FDI_RX_ENABLE;
>> -I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val);
>> -POSTING_READ(FDI_RX_CTL(PIPE_A));
>> -
>>  /* Reset FDI_RX_MISC pwrdn lanes */
>>  temp = I915_READ(FDI_RX_MISC(PIPE_A));
>>  temp &= ~(FDI_RX_PWRDN_LANE1_MASK |
>FDI_RX_PWRDN_LANE0_MASK);
>> @@ -3094,12 +3094,18 @@ void intel_ddi_fdi_disable(struct drm_crtc *crtc)
>>  struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
>>  uint32_t val;
>>
>> -intel_ddi_post_disable(intel_encoder);
>> -
>> +/*
>> + * Bspec lists this as both step 13 (before DDI_BUF_CTL disable)
>> + * and step 18 (after clearing PORT_CLK_SEL). Based on a BUN,
>> + * step 13 is the correct place for it. Step 18 is where it was
>> + * originally before the BUN.
>> + */
>>  val = I915_READ(FDI_RX_CTL(PIPE_A));
>>  val &= ~FDI_RX_ENABLE;
>>  I915_WRITE(FDI_RX_CTL(PIPE_A), val);
>>
>> +intel_ddi_post_disable(intel_encoder);
>> +
>>  val = I915_READ(FDI_RX_MISC(PIPE_A));
>>  val &= ~(FDI_RX_PWRDN_LANE1_MASK |
>FDI_RX_PWRDN_LANE0_MASK);
>>  val |= FDI_RX_PWRDN_LANE1_VAL(2) | FDI_RX_PWRDN_LANE0_VAL(2);
>> --
>> 2.4.10
>
>--
>Ville Syrjälä
>Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/6] drm/i915: enable CSC for pipe C

[Matt Roper]

On Tue, Feb 09, 2016 at 12:19:15PM +, Lionel Landwerlin wrote:
> Patch based on a previous series by Shashank Sharma.
> 
> v2: Update contributors

Is this patch actually necessary?  If I recall correctly, _MMIO_PIPE()
will support any number of pipes if the delta between register offsets
for each pipe is constant (in that case, you only need to know the
offset of the first two pipes' registers to calculate the offset of any
subsequent pipe's register).  I think _MMIO_PIPE3 is necessary only if
the difference between register offsets is non-constant and thus all
three offsets need to be specified individually.

Same comment for patch #4 of your series.


Matt

> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Lionel Landwerlin 
> Signed-off-by: Kumar, Kiran S 
> Signed-off-by: Kausal Malladi 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 40 +++-
>  1 file changed, 27 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 188ad5d..7ba8a99 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7634,19 +7634,33 @@ enum skl_disp_power_wells {
>  #define _PIPE_B_CSC_POSTOFF_ME   0x49144
>  #define _PIPE_B_CSC_POSTOFF_LO   0x49148
>  
> -#define PIPE_CSC_COEFF_RY_GY(pipe)   _MMIO_PIPE(pipe, 
> _PIPE_A_CSC_COEFF_RY_GY, _PIPE_B_CSC_COEFF_RY_GY)
> -#define PIPE_CSC_COEFF_BY(pipe)  _MMIO_PIPE(pipe, 
> _PIPE_A_CSC_COEFF_BY, _PIPE_B_CSC_COEFF_BY)
> -#define PIPE_CSC_COEFF_RU_GU(pipe)   _MMIO_PIPE(pipe, 
> _PIPE_A_CSC_COEFF_RU_GU, _PIPE_B_CSC_COEFF_RU_GU)
> -#define PIPE_CSC_COEFF_BU(pipe)  _MMIO_PIPE(pipe, 
> _PIPE_A_CSC_COEFF_BU, _PIPE_B_CSC_COEFF_BU)
> -#define PIPE_CSC_COEFF_RV_GV(pipe)   _MMIO_PIPE(pipe, 
> _PIPE_A_CSC_COEFF_RV_GV, _PIPE_B_CSC_COEFF_RV_GV)
> -#define PIPE_CSC_COEFF_BV(pipe)  _MMIO_PIPE(pipe, 
> _PIPE_A_CSC_COEFF_BV, _PIPE_B_CSC_COEFF_BV)
> -#define PIPE_CSC_MODE(pipe)  _MMIO_PIPE(pipe, _PIPE_A_CSC_MODE, 
> _PIPE_B_CSC_MODE)
> -#define PIPE_CSC_PREOFF_HI(pipe) _MMIO_PIPE(pipe, _PIPE_A_CSC_PREOFF_HI, 
> _PIPE_B_CSC_PREOFF_HI)
> -#define PIPE_CSC_PREOFF_ME(pipe) _MMIO_PIPE(pipe, _PIPE_A_CSC_PREOFF_ME, 
> _PIPE_B_CSC_PREOFF_ME)
> -#define PIPE_CSC_PREOFF_LO(pipe) _MMIO_PIPE(pipe, _PIPE_A_CSC_PREOFF_LO, 
> _PIPE_B_CSC_PREOFF_LO)
> -#define PIPE_CSC_POSTOFF_HI(pipe)_MMIO_PIPE(pipe, 
> _PIPE_A_CSC_POSTOFF_HI, _PIPE_B_CSC_POSTOFF_HI)
> -#define PIPE_CSC_POSTOFF_ME(pipe)_MMIO_PIPE(pipe, 
> _PIPE_A_CSC_POSTOFF_ME, _PIPE_B_CSC_POSTOFF_ME)
> -#define PIPE_CSC_POSTOFF_LO(pipe)_MMIO_PIPE(pipe, 
> _PIPE_A_CSC_POSTOFF_LO, _PIPE_B_CSC_POSTOFF_LO)
> +#define _PIPE_C_CSC_COEFF_RY_GY  0x49210
> +#define _PIPE_C_CSC_COEFF_BY 0x49214
> +#define _PIPE_C_CSC_COEFF_RU_GU  0x49218
> +#define _PIPE_C_CSC_COEFF_BU 0x4921c
> +#define _PIPE_C_CSC_COEFF_RV_GV  0x49220
> +#define _PIPE_C_CSC_COEFF_BV 0x49224
> +#define _PIPE_C_CSC_MODE 0x49228
> +#define _PIPE_C_CSC_PREOFF_HI0x49230
> +#define _PIPE_C_CSC_PREOFF_ME0x49234
> +#define _PIPE_C_CSC_PREOFF_LO0x49238
> +#define _PIPE_C_CSC_POSTOFF_HI   0x49240
> +#define _PIPE_C_CSC_POSTOFF_ME   0x49244
> +#define _PIPE_C_CSC_POSTOFF_LO   0x49248
> +
> +#define PIPE_CSC_COEFF_RY_GY(pipe)   _MMIO_PIPE3(pipe, 
> _PIPE_A_CSC_COEFF_RY_GY, _PIPE_B_CSC_COEFF_RY_GY, _PIPE_C_CSC_COEFF_RY_GY)
> +#define PIPE_CSC_COEFF_BY(pipe)  _MMIO_PIPE3(pipe, 
> _PIPE_A_CSC_COEFF_BY, _PIPE_B_CSC_COEFF_BY, _PIPE_C_CSC_COEFF_BY)
> +#define PIPE_CSC_COEFF_RU_GU(pipe)   _MMIO_PIPE3(pipe, 
> _PIPE_A_CSC_COEFF_RU_GU, _PIPE_B_CSC_COEFF_RU_GU, _PIPE_C_CSC_COEFF_RU_GU)
> +#define PIPE_CSC_COEFF_BU(pipe)  _MMIO_PIPE3(pipe, 
> _PIPE_A_CSC_COEFF_BU, _PIPE_B_CSC_COEFF_BU, _PIPE_C_CSC_COEFF_BU)
> +#define PIPE_CSC_COEFF_RV_GV(pipe)   _MMIO_PIPE3(pipe, 
> _PIPE_A_CSC_COEFF_RV_GV, _PIPE_B_CSC_COEFF_RV_GV, _PIPE_C_CSC_COEFF_RV_GV)
> +#define PIPE_CSC_COEFF_BV(pipe)  _MMIO_PIPE3(pipe, 
> _PIPE_A_CSC_COEFF_BV, _PIPE_B_CSC_COEFF_BV, _PIPE_C_CSC_COEFF_BV)
> +#define PIPE_CSC_MODE(pipe)  _MMIO_PIPE3(pipe, _PIPE_A_CSC_MODE, 
> _PIPE_B_CSC_MODE, _PIPE_C_CSC_MODE)
> +#define PIPE_CSC_PREOFF_HI(pipe) _MMIO_PIPE3(pipe, 
> _PIPE_A_CSC_PREOFF_HI, _PIPE_B_CSC_PREOFF_HI, _PIPE_C_CSC_PREOFF_HI)
> +#define PIPE_CSC_PREOFF_ME(pipe) _MMIO_PIPE3(pipe, 
> _PIPE_A_CSC_PREOFF_ME, _PIPE_B_CSC_PREOFF_ME, _PIPE_C_CSC_PREOFF_ME)
> +#define PIPE_CSC_PREOFF_LO(pipe) _MMIO_PIPE3(pipe, 
> _PIPE_A_CSC_PREOFF_LO, _PIPE_B_CSC_PREOFF_LO, _PIPE_C_CSC_PREOFF_LO)
> +#define PIPE_CSC_POSTOFF_HI(pipe)_MMIO_PIPE3(pipe, 
> _PIPE_A_CSC_POSTOFF_HI, _PIPE_B_CSC_POSTOFF_HI, _PIPE_C_CSC_POSTOFF_HI)
> +#define PIPE_CSC_POSTOFF_ME(pipe)_MMIO_PIPE3(pipe, 
> _PIPE_A_CSC_POSTOFF_ME, _PIPE_B_CSC_POSTOFF_ME, _PIPE_C_CSC_POSTOFF_ME)
> 

Re: [Intel-gfx] [PATCH 2/6] drm: introduce color correction properties

[Matt Roper]

On Tue, Feb 09, 2016 at 12:19:14PM +, Lionel Landwerlin wrote:
> Patch based on a previous series by Shashank Sharma.
> 
> v2: Register LUT size properties as range
> 
> v3: Fix round in drm_color_lut_get_value() helper
> More docs on how degamma/gamma properties are used
> 
> v4: Update contributors

A couple minor notes:
 * In the kerneldoc, you might want to spell out the first use of the
   acronyms for clarity.  I.e., Color Transformation Matrix, Lookup
   Table.
 * You might want to add DRM_DEBUG_KMS() calls to some of the error
   conditions (e.g., when the blob has an invalid size) so that it will
   be more apparent why we failed when looking at kernel logs.
 * Looks like one minor whitespace error, noted below.
 * One minor helper note below.

Aside from those,
Reviewed-by: Matt Roper 


Also, somewhere (probably as a followup patch to this series), I think
we need some kerneldoc text that describes the relationship between this
color management work and the old legacy gamma ioctl.  I.e., what
happens if you intermix calls to the legacy ioctl with updates to the
color manager properties.


Matt


> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Lionel Landwerlin 
> Signed-off-by: Kumar, Kiran S 
> Signed-off-by: Kausal Malladi 
...
> @@ -419,8 +472,47 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
>   ret = drm_atomic_set_mode_prop_for_crtc(state, mode);
>   drm_property_unreference_blob(mode);
>   return ret;
> - }
> - else if (crtc->funcs->atomic_set_property)
> + } else if (property == config->degamma_lut_property) {
> + bool replaced = false;
> + uint64_t lut_size = 0;
> +
> + ret = drm_object_property_get_value(>base,
> + config->degamma_lut_size_property,
> + _size);
> + if (ret == 0)
> + ret = drm_atomic_replace_property_blob_from_id(crtc,
> + >degamma_lut,
> + val,
> + lut_size * sizeof(struct drm_color_lut),
> + );
> + state->color_mgmt_changed = replaced;
> + return ret;
> + } else if (property == config->ctm_matrix_property) {
> + bool replaced = false;
> +
> + ret = drm_atomic_replace_property_blob_from_id(crtc,
> + >ctm_matrix,
> + val,
> + sizeof(struct drm_color_ctm),
> +);

Looks like there might be something off with the whitespace here.


> + state->color_mgmt_changed = replaced;
> + return ret;
> + } else if (property == config->gamma_lut_property) {
> + bool replaced = false;
> + uint64_t lut_size = 0;
> +
> + ret = drm_object_property_get_value(>base,
> + config->gamma_lut_size_property,
> + _size);
> + if (ret == 0)
> + ret = drm_atomic_replace_property_blob_from_id(crtc,
> + >gamma_lut,
> + val,
> + lut_size * sizeof(struct drm_color_lut),
> + );
> + state->color_mgmt_changed = replaced;
> + return ret;
> + } else if (crtc->funcs->atomic_set_property)
>   return crtc->funcs->atomic_set_property(crtc, state, property, 
> val);
>   else
>   return -EINVAL;
> @@ -456,6 +548,12 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
>   *val = state->active;
>   else if (property == config->prop_mode_id)
>   *val = (state->mode_blob) ? state->mode_blob->base.id : 0;
> + else if (property == config->degamma_lut_property)
> + *val = (state->degamma_lut) ? state->degamma_lut->base.id : 0;
> + else if (property == config->ctm_matrix_property)
> + *val = (state->ctm_matrix) ? state->ctm_matrix->base.id : 0;
> + else if (property == config->gamma_lut_property)
> + *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
>   else if (crtc->funcs->atomic_get_property)
>   return crtc->funcs->atomic_get_property(crtc, state, property, 
> val);
>   else
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 2b430b0..d13dfd8 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2513,10 +2513,17 @@ void 

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Extract out gamma table and CSC to their own file

[Matt Roper]

On Mon, Feb 01, 2016 at 03:18:32PM +, Lionel Landwerlin wrote:
> Signed-off-by: Lionel Landwerlin 

Given the patch headline and lack of commit message body, I expected
this to be pretty much a straight migration of the code between files
without other changes (aside from [un]static'ing of functions and such).
But it looks like there are a handful of non-movement changes here as
well.  Aside from the function renames (which might be worth noting in
the commit message), there are a couple of changes to gamma LUT loading
that look like they're a functional change on some platforms.  Assuming
those were intentional changes, those should probably be described in
the commit message, or else split into a separate patch so that they can
be reviewed more easily.

...
> +/** Loads the palette/gamma unit for the CRTC with the prepared values on  */

Preexisting mistake from the original code, but this isn't actually a
kerneldoc comment, so you might want to make this just a "/*" opener.

> +static void i9xx_load_legacy_gamma_lut(struct drm_crtc *crtc)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + enum pipe pipe = intel_crtc->pipe;
> + int i;
> + bool reenable_ips = false;
> +
> + if (HAS_GMCH_DISPLAY(dev)) {
> + if (intel_crtc->config->has_dsi_encoder)
> + assert_dsi_pll_enabled(dev_priv);
> + else
> + assert_pll_enabled(dev_priv, pipe);
> + }
> +
> + /* Workaround : Do not read or write the pipe palette/gamma data while
> +  * GAMMA_MODE is configured for split gamma and IPS_CTL has IPS enabled.
> +  */
> + if (IS_HASWELL(dev) && intel_crtc->config->ips_enabled &&
> + ((I915_READ(GAMMA_MODE(pipe)) & GAMMA_MODE_MODE_MASK) ==
> +  GAMMA_MODE_MODE_SPLIT)) {
> + hsw_disable_ips(intel_crtc);
> + reenable_ips = true;
> + }
> +
> + for (i = 0; i < 256; i++) {
> + uint32_t word = (intel_crtc->lut_r[i] << 16) |
> + (intel_crtc->lut_g[i] << 8) |
> + intel_crtc->lut_b[i];
> + if (HAS_GMCH_DISPLAY(dev))
> + I915_WRITE(PALETTE(pipe, i), word);
> + else
> + I915_WRITE(LGC_PALETTE(pipe, i), word);
> + }

This loop was re-written / re-organized from the original code, but
looks like it should still accomplish the same thing.

> +
> + I915_WRITE(GAMMA_MODE(intel_crtc->pipe), GAMMA_MODE_MODE_8BIT);

This wasn't in the original function, but rather moved from
haswell_set_pipeconf() so it was only called on a smaller subset of
platforms in the past.  Is that an intentional change, or a mistake?
You also seem to have dropped the POSTING_READ() that followed it.


Matt

> +
> + if (reenable_ips)
> + hsw_enable_ips(intel_crtc);
> +}
> +
> +void intel_color_load_gamma_lut(struct drm_crtc *crtc)
> +{
> + /* The clocks have to be on to load the palette. */
> + if (!crtc->state->active)
> + return;
> +
> + i9xx_load_legacy_gamma_lut(crtc);
> +}

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Possible 4.5 i915 Skylake regression

[Andy Lutomirski]

On Wed, Feb 17, 2016 at 8:18 AM, Daniel Vetter  wrote:
> On Tue, Feb 16, 2016 at 09:26:35AM -0800, Andy Lutomirski wrote:
>> On Tue, Feb 16, 2016 at 9:12 AM, Andy Lutomirski  wrote:
>> > On Tue, Feb 16, 2016 at 8:12 AM, Daniel Vetter  wrote:
>> >> On Mon, Feb 15, 2016 at 06:58:33AM -0800, Andy Lutomirski wrote:
>> >>> On Sun, Feb 14, 2016 at 6:59 PM, Andy Lutomirski  wrote:
>> >>> > Hi-
>> >>> >
>> >>> > On 4.5-rc3 on a Dell XPS 13 9350 (Skylake i915, no nvidia on this
>> >>> > model), shortly after resume, I saw a single black flash on the
>> >>> > screen.  The log said:
>> >>> >
>> >>> > [Feb13 07:05] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR*
>> >>> > CPU pipe A FIFO underrun
>> >>> >
>> >>> > I haven't seen this on 4.4.
>> >>> >
>> >>> > I'd be happy to dig up debugging info, but I don't know what would be
>> >>> > useful.  I have no i915 module options set.
>> >>>
>> >>> It's flashing quite frequently now, although I seem to get the
>> >>> underrun warning only once per resume.
>> >>
>> >> We shut up the warning irq source to avoid hijacking an entire cpu core
>> >> ;-)
>> >>
>> >> There's a fix from Matt right after 4.5-rc4 in Linus' branch. I'm hoping
>> >> that should help.
>> >
>> > Do you mean:
>> >
>> > commit e2e407dc093f530b771ee8bf8fe1be41e3cea8b3
>> > Author: Matt Roper 
>> > Date:   Mon Feb 8 11:05:28 2016 -0800
>> >
>> > drm/i915: Pretend cursor is always on for ILK-style WM calculations 
>> > (v2)
>> >
>> > If so, it didn't help.  I'm currently doing a full rebuild just in
>> > case I messed something up, though.
>> >
>>
>> Definitely not fixed.  It seems to be okay after a reboot until the
>> first suspend/resume.
>>
>> This happened after resuming.  Five cents says it's the root cause.
>
> That's interesting, but doesn't ring a bell unfortunately. Can you try to
> attempt a bisect?

I probably can, but it's very slow.  Is there a reasonably
straightforward way to instrument the watermark computation to see
what's going wrong?  I'm reasonably confident that the bug is in the
resume code or in something that only happens on resume, since I still
haven't seen underruns after rebooting before suspending.

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

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Check for DC state mismatch

[Vivi, Rodrigo]

I was going to merge here but I saw on patchwork we got some warnings
so I'm not sure they are only false positives or this is exactly what
this patches wants...

On Thu, 2016-02-11 at 12:43 +0200, Mika Kuoppala wrote:
> Patrik Jakobsson  writes:
> 
> > The DMC can incorrectly run off and allow DC states on it's own. We
> > don't know the root-cause for this yet but this patch makes it more
> > visible.
> > 
> > Signed-off-by: Patrik Jakobsson 
> 
> Yes, we definitely need much more state checking and hardening
> in this area.
> 
> Reviewed-by: Mika Kuoppala 
> 
> 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h | 1 +
> >  drivers/gpu/drm/i915/intel_csr.c| 2 ++
> >  drivers/gpu/drm/i915/intel_runtime_pm.c | 8 
> >  3 files changed, 11 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index e11eef1..7e33454 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -746,6 +746,7 @@ struct intel_csr {
> > uint32_t mmio_count;
> > i915_reg_t mmioaddr[8];
> > uint32_t mmiodata[8];
> > +   uint32_t dc_state;
> >  };
> >  
> >  #define DEV_INFO_FOR_EACH_FLAG(func, sep) \
> > diff --git a/drivers/gpu/drm/i915/intel_csr.c 
> > b/drivers/gpu/drm/i915/intel_csr.c
> > index 2a7ec31..b453fcc 100644
> > --- a/drivers/gpu/drm/i915/intel_csr.c
> > +++ b/drivers/gpu/drm/i915/intel_csr.c
> > @@ -243,6 +243,8 @@ void intel_csr_load_program(struct 
> > drm_i915_private *dev_priv)
> > I915_WRITE(dev_priv->csr.mmioaddr[i],
> >dev_priv->csr.mmiodata[i]);
> > }
> > +
> > +   dev_priv->csr.dc_state = 0;
> >  }
> >  
> >  static uint32_t *parse_csr_fw(struct drm_i915_private *dev_priv,
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index bbca527..e79674b 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -494,10 +494,18 @@ static void gen9_set_dc_state(struct 
> > drm_i915_private *dev_priv, uint32_t state)
> > val = I915_READ(DC_STATE_EN);
> > DRM_DEBUG_KMS("Setting DC state from %02x to %02x\n",
> >   val & mask, state);
> > +
> > +   /* Check if DMC is ignoring our DC state requests */
> > +   if ((val & mask) != dev_priv->csr.dc_state)
> > +   DRM_ERROR("DC state mismatch (0x%x -> 0x%x)\n",
> > + dev_priv->csr.dc_state, val & mask);
> > +
> > val &= ~mask;
> > val |= state;
> > I915_WRITE(DC_STATE_EN, val);
> > POSTING_READ(DC_STATE_EN);
> > +
> > +   dev_priv->csr.dc_state = val & mask;
> >  }
> >  
> >  void bxt_enable_dc9(struct drm_i915_private *dev_priv)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 0/2] Add i915_gem_object_vmap

[yu . dai]

From: Alex Dai 

There are several places in driver that a GEM object is mapped to kernel
virtual space. Now add a common function i915_gem_object_vmap to do the vmap
work for such use case.

Alex Dai (2):
  drm/i915: Add i915_gem_object_vmap to map GEM object to virtual space
  drm/i915/guc: Simplify code by keeping vmap of guc_client object

 drivers/gpu/drm/i915/i915_cmd_parser.c | 28 +---
 drivers/gpu/drm/i915/i915_drv.h|  3 ++
 drivers/gpu/drm/i915/i915_gem.c| 44 +
 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 15 ++---
 drivers/gpu/drm/i915/i915_guc_submission.c | 53 +-
 drivers/gpu/drm/i915/intel_guc.h   |  3 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c| 24 ++
 7 files changed, 70 insertions(+), 100 deletions(-)

-- 
2.5.0

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

[Intel-gfx] [PATCH 2/2] drm/i915/guc: Simplify code by keeping vmap of guc_client object

[yu . dai]

From: Alex Dai 

GuC client object is always pinned during its life cycle. We cache
the vmap of client object, which includes guc_process_desc, doorbell
and work queue. By doing so, we can simplify the code where driver
communicate with GuC.

As a result, this patch removes the kmap_atomic in wq_check_space,
where usleep_range could be called while kmap_atomic is held. This
fixes issue below.

[   34.098798] BUG: scheduling while atomic: gem_close_race/1941/0x0002
[   34.098822] Modules linked in: hid_generic usbhid i915 asix usbnet libphy 
mii i2c_algo_bit drm_kms_helper cfbfillrect syscopyarea cfbimgblt sysfillrect 
sysimgblt fb_sys_fops cfbcopyarea drm coretemp i2c_hid hid video 
pinctrl_sunrisepoint pinctrl_intel acpi_pad nls_iso8859_1 e1000e ptp psmouse 
pps_core ahci libahci
[   34.098824] CPU: 0 PID: 1941 Comm: gem_close_race Tainted: G U  
4.4.0-160121+ #123
[   34.098824] Hardware name: Intel Corporation Skylake Client platform/Skylake 
AIO DDR3L RVP10, BIOS SKLSE2R1.R00.X100.B01.1509220551 09/22/2015
[   34.098825]  00013e40 880166c27a78 81280d02 
880172c13e40
[   34.098826]  880166c27a88 810c203a 880166c27ac8 
814ec808
[   34.098827]  88016b7c6000 880166c28000 000f4240 
0001
[   34.098827] Call Trace:
[   34.098831]  [] dump_stack+0x4b/0x79
[   34.098833]  [] __schedule_bug+0x41/0x4f
[   34.098834]  [] __schedule+0x5a8/0x690
[   34.098835]  [] schedule+0x37/0x80
[   34.098836]  [] schedule_hrtimeout_range_clock+0xad/0x130
[   34.098837]  [] ? hrtimer_init+0x10/0x10
[   34.098838]  [] ? schedule_hrtimeout_range_clock+0xa1/0x130
[   34.098839]  [] schedule_hrtimeout_range+0xe/0x10
[   34.098840]  [] usleep_range+0x3b/0x40
[   34.098853]  [] i915_guc_wq_check_space+0x119/0x210 [i915]
[   34.098861]  [] 
intel_logical_ring_alloc_request_extras+0x5c/0x70 [i915]
[   34.098869]  [] i915_gem_request_alloc+0x91/0x170 [i915]
[   34.098875]  [] 
i915_gem_do_execbuffer.isra.25+0xbc7/0x12a0 [i915]
[   34.098882]  [] ? 
i915_gem_object_get_pages_gtt+0x225/0x3c0 [i915]
[   34.098889]  [] ? i915_gem_pwrite_ioctl+0xd6/0x9f0 [i915]
[   34.098895]  [] i915_gem_execbuffer2+0xa8/0x250 [i915]
[   34.098900]  [] drm_ioctl+0x258/0x4f0 [drm]
[   34.098906]  [] ? i915_gem_execbuffer+0x340/0x340 [i915]
[   34.098908]  [] do_vfs_ioctl+0x2cd/0x4a0
[   34.098909]  [] ? __fget+0x72/0xb0
[   34.098910]  [] SyS_ioctl+0x3c/0x70
[   34.098911]  [] entry_SYSCALL_64_fastpath+0x12/0x6a
[   34.100208] [ cut here ]

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93847
Cc: Dave Gordon 
Cc: Daniel Vetter 
Cc: Tvrtko Ursulin 
Signed-off-by: Alex Dai 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 53 +-
 drivers/gpu/drm/i915/intel_guc.h   |  3 +-
 2 files changed, 18 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index d7543ef..3d6a1f7 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -195,11 +195,9 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
struct guc_process_desc *desc;
union guc_doorbell_qw db_cmp, db_exc, db_ret;
union guc_doorbell_qw *db;
-   void *base;
int attempt = 2, ret = -EAGAIN;
 
-   base = kmap_atomic(i915_gem_object_get_page(gc->client_obj, 0));
-   desc = base + gc->proc_desc_offset;
+   desc = gc->client_base + gc->proc_desc_offset;
 
/* Update the tail so it is visible to GuC */
desc->tail = gc->wq_tail;
@@ -215,7 +213,7 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
db_exc.cookie = 1;
 
/* pointer of current doorbell cacheline */
-   db = base + gc->doorbell_offset;
+   db = gc->client_base + gc->doorbell_offset;
 
while (attempt--) {
/* lets ring the doorbell */
@@ -244,10 +242,6 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
db_exc.cookie = 1;
}
 
-   /* Finally, update the cached copy of the GuC's WQ head */
-   gc->wq_head = desc->head;
-
-   kunmap_atomic(base);
return ret;
 }
 
@@ -341,10 +335,8 @@ static void guc_init_proc_desc(struct intel_guc *guc,
   struct i915_guc_client *client)
 {
struct guc_process_desc *desc;
-   void *base;
 
-   base = kmap_atomic(i915_gem_object_get_page(client->client_obj, 0));
-   desc = base + client->proc_desc_offset;
+   desc = client->client_base + client->proc_desc_offset;
 
memset(desc, 0, sizeof(*desc));
 
@@ -361,8 +353,6 @@ static void guc_init_proc_desc(struct intel_guc *guc,
desc->wq_size_bytes = client->wq_size;
desc->wq_status = WQ_STATUS_ACTIVE;
desc->priority = 

[Intel-gfx] [PATCH 1/2] drm/i915: Add i915_gem_object_vmap to map GEM object to virtual space

[yu . dai]

From: Alex Dai 

There are several places inside driver where a GEM object is mapped to
kernel virtual space. The mapping is either done for the whole object
or certain page range of it.

This patch introduces a function i915_gem_object_vmap to do such job.

Signed-off-by: Alex Dai 
Cc: Dave Gordon 
Cc: Daniel Vetter 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c  | 28 +
 drivers/gpu/drm/i915/i915_drv.h |  3 +++
 drivers/gpu/drm/i915/i915_gem.c | 44 +
 drivers/gpu/drm/i915/i915_gem_dmabuf.c  | 15 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.c | 24 ++
 5 files changed, 52 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 814d894..915e8c1 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -863,37 +863,11 @@ find_reg(const struct drm_i915_reg_descriptor *table,
 static u32 *vmap_batch(struct drm_i915_gem_object *obj,
   unsigned start, unsigned len)
 {
-   int i;
-   void *addr = NULL;
-   struct sg_page_iter sg_iter;
int first_page = start >> PAGE_SHIFT;
int last_page = (len + start + 4095) >> PAGE_SHIFT;
int npages = last_page - first_page;
-   struct page **pages;
-
-   pages = drm_malloc_ab(npages, sizeof(*pages));
-   if (pages == NULL) {
-   DRM_DEBUG_DRIVER("Failed to get space for pages\n");
-   goto finish;
-   }
-
-   i = 0;
-   for_each_sg_page(obj->pages->sgl, _iter, obj->pages->nents, 
first_page) {
-   pages[i++] = sg_page_iter_page(_iter);
-   if (i == npages)
-   break;
-   }
-
-   addr = vmap(pages, i, 0, PAGE_KERNEL);
-   if (addr == NULL) {
-   DRM_DEBUG_DRIVER("Failed to vmap pages\n");
-   goto finish;
-   }
 
-finish:
-   if (pages)
-   drm_free_large(pages);
-   return (u32*)addr;
+   return (u32*)i915_gem_object_vmap(obj, first_page, npages);
 }
 
 /* Returns a vmap'd pointer to dest_obj, which the caller must unmap */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6644c2e..5b00a6a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2899,6 +2899,9 @@ struct drm_i915_gem_object 
*i915_gem_object_create_from_data(
struct drm_device *dev, const void *data, size_t size);
 void i915_gem_free_object(struct drm_gem_object *obj);
 void i915_gem_vma_destroy(struct i915_vma *vma);
+void *i915_gem_object_vmap(struct drm_i915_gem_object *obj,
+  unsigned int first,
+  unsigned int npages);
 
 /* Flags used by pin/bind */
 #define PIN_MAPPABLE   (1<<0)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f68f346..a6f465b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5356,3 +5356,47 @@ fail:
drm_gem_object_unreference(>base);
return ERR_PTR(ret);
 }
+
+/**
+ * i915_gem_object_vmap - map a GEM obj into kernel virtual space
+ * @obj: the GEM obj to be mapped
+ * @first: index of the first page where mapping starts
+ * @npages: how many pages to be mapped, starting from first page
+ *
+ * Map a given page range of GEM obj into kernel virtual space. The caller must
+ * make sure the associated pages are gathered and pinned before calling this
+ * function. vunmap should be called after use.
+ *
+ * NULL will be returned if fails.
+ */
+void *i915_gem_object_vmap(struct drm_i915_gem_object *obj,
+  unsigned int first,
+  unsigned int npages)
+{
+   struct sg_page_iter sg_iter;
+   struct page **pages;
+   void *addr;
+   int i;
+
+   if (first + npages > obj->pages->nents) {
+   DRM_DEBUG_DRIVER("Invalid page count\n");
+   return NULL;
+   }
+
+   pages = drm_malloc_ab(npages, sizeof(*pages));
+   if (pages == NULL) {
+   DRM_DEBUG_DRIVER("Failed to get space for pages\n");
+   return NULL;
+   }
+
+   i = 0;
+   for_each_sg_page(obj->pages->sgl, _iter, npages, first)
+   pages[i++] = sg_page_iter_page(_iter);
+
+   addr = vmap(pages, npages, 0, PAGE_KERNEL);
+   if (addr == NULL)
+   DRM_DEBUG_DRIVER("Failed to vmap pages\n");
+   drm_free_large(pages);
+
+   return addr;
+}
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 1f3eef6..d269957 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -110,9 +110,7 @@ static void *i915_gem_dmabuf_vmap(struct 

Re: [Intel-gfx] [PATCH] drm/i915: Avoid vblank counter for gen9+

[Rodrigo Vivi]

On Tue, Feb 16, 2016 at 7:50 AM, Daniel Vetter  wrote:
> On Thu, Feb 11, 2016 at 09:00:47AM -0800, Rodrigo Vivi wrote:
>> Framecounter register is read-only so DMC cannot restore it
>> after exiting DC5 and DC6.
>>
>> Easiest way to go is to avoid the counter and use vblank
>> interruptions for this platform and for all the following
>> ones since DMC came to stay. At least while we can't change
>> this register to read-write.
>>
>> Signed-off-by: Rodrigo Vivi 
>
> Now my comments also in public:
> - Do we still get reasonable dc5 residency with this - it means we'll keep
>   vblank irq running forever.
>
> - I'm a bit unclear on what exactly this fixes - have you tested that
>   long-lasting vblank waits are still accurate? Just want to make sure we
>   don't just paper over the issue and desktops can still get stuck waiting
>   for a vblank.

apparently no... so please just ignore this patch for now... after a
while with that patch I was seeing the issue again...

>
> Just a bit suprised that the only problem is the framecounter, and not
> that vblanks stop happening too.
>
> We need to also know these details for the proper fix, which will involve
> grabbing power well references (might need a new one for vblank
> interrupts) to make sure.

Yeap, I liked this idea... so combining a power domain reference with
a vblank count restore once we know the dc off is blocked we could
workaround this case... something like:

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 25a8937..2b18778 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2743,7 +2743,10 @@ static int gen8_enable_vblank(struct drm_device
*dev, unsigned int pipe)
struct drm_i915_private *dev_priv = dev->dev_private;
unsigned long irqflags;

+   intel_display_power_get(dev_priv, POWER_DOMAIN_VBLANK);
+
spin_lock_irqsave(_priv->irq_lock, irqflags);
+   dev->vblank[pipe].last = g4x_get_vblank_counter(dev, pipe);
bdw_enable_pipe_irq(dev_priv, pipe, GEN8_PIPE_VBLANK);
spin_unlock_irqrestore(_priv->irq_lock, irqflags);

@@ -2796,6 +2799,8 @@ static void gen8_disable_vblank(struct
drm_device *dev, unsigned int pipe)
spin_lock_irqsave(_priv->irq_lock, irqflags);
bdw_disable_pipe_irq(dev_priv, pipe, GEN8_PIPE_VBLANK);
spin_unlock_irqrestore(_priv->irq_lock, irqflags);
+
+   intel_display_power_put(dev_priv, POWER_DOMAIN_VBLANK);
 }

where POWER_DOMAIN_VBLANK is part of:
#define SKL_DISPLAY_DC_OFF_POWER_DOMAINS (  \
BIT(POWER_DOMAIN_VBLANK) |  \


However I have my dmesg flooded by:


[   69.025562] BUG: sleeping function called from invalid context at
drivers/base/power/runtime.c:955
[   69.025576] in_atomic(): 1, irqs_disabled(): 1, pid: 995, name: Xorg
[   69.025582] Preemption disabled at:[]
drm_vblank_get+0x4e/0xd0

[   69.025619] CPU: 3 PID: 995 Comm: Xorg Tainted: G U  W
4.5.0-rc4+ #11
[   69.025628] Hardware name: Intel Corporation Kabylake Client
platform/Skylake U DDR3L RVP7, BIOS KBLSE2R1.R00.X019.B01.1512230743
12/23/2015
[   69.025637]   88003f0bfbb0 8148e983

[   69.025653]  880085b04200 88003f0bfbd0 81133ece
81d77f23
[   69.025667]  03bb 88003f0bfbf8 81133f89
88016913a098
[   69.025680] Call Trace:
[   69.025697]  [] dump_stack+0x65/0x92
[   69.025711]  [] ___might_sleep+0x10e/0x180
[   69.025722]  [] __might_sleep+0x49/0x80
[   69.025739]  [] __pm_runtime_resume+0x79/0x80
[   69.025841]  [] intel_runtime_pm_get+0x28/0x90 [i915]
[   69.025924]  [] intel_display_power_get+0x19/0x50 [i915]
[   69.025995]  [] gen8_enable_vblank+0x34/0xc0 [i915]
[   69.026016]  [] drm_vblank_enable+0x76/0xd0




Another thing that I search in the spec was for an Interrupt to know
when we came back from DC5 or DC6 or got power well re-enabled, so we
would be able to restore the drm last counter... but I couldn't find
any...


Any other idea?


>
> Cheers, Daniel
>
>> ---
>>  drivers/gpu/drm/i915/i915_irq.c | 7 +--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_irq.c 
>> b/drivers/gpu/drm/i915/i915_irq.c
>> index 25a8937..c294a4b 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.c
>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>> @@ -4556,7 +4556,10 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
>>
>>   pm_qos_add_request(_priv->pm_qos, PM_QOS_CPU_DMA_LATENCY, 
>> PM_QOS_DEFAULT_VALUE);
>>
>> - if (IS_GEN2(dev_priv)) {
>> + if (INTEL_INFO(dev_priv)->gen >= 9) {
>> + dev->max_vblank_count = 0;
>> + dev->driver->get_vblank_counter = g4x_get_vblank_counter;
>> + } else if (IS_GEN2(dev_priv)) {
>>   dev->max_vblank_count = 0;
>>   dev->driver->get_vblank_counter = i8xx_get_vblank_counter;
>>   } else if (IS_G4X(dev_priv) || 

Re: [Intel-gfx] [PATCH i-g-t v3] lib/igt_core.c: Expand --run-subtest functionality.

[Daniel Vetter]

On Wed, Feb 17, 2016 at 06:18:21PM +0100, Daniel Vetter wrote:
> On Thu, Feb 04, 2016 at 12:06:57PM +, Derek Morton wrote:
> > Added extended wildcard support when specifying --run-subtest.
> > 
> > Wildcard format is as specified in rfc3977 and the uwildmat() implementation
> > is taken from libinn.
> > See https://tools.ietf.org/html/rfc3977#section-4 for a description of
> > allowed wildcard expressions.
> > 
> > v2: Use comma as list separator (Ville Syrjala)
> > support both ^ and ! as not operators (Dave Gordon)
> > 
> > v3: Updated to use uwildmat() (Dave Gordon)
> > 
> > Signed-off-by: Derek Morton 
> 
> So really not happy that we perpetuate the interface differences in how
> igt is run between android and linux. But oh well, maybe this helps in
> getting the android team more on board with upstream igt tests than also
> reinventing those wheels.
> 
> Applied, thanks for the patch.

Ok, this breaks the normal partial match functionality, which is pretty
handy for running a few tests. New we need *foo* instead of foo. Can you
pls add a patch on top to restore that?

Thanks, Daniel

> -Daniel
> 
> > ---
> >  COPYING |  21 +++
> >  lib/Makefile.sources|   2 +
> >  lib/igt_core.c  |  17 +-
> >  lib/uwildmat/uwildmat.c | 474 
> > 
> >  lib/uwildmat/uwildmat.h |  24 +++
> >  5 files changed, 536 insertions(+), 2 deletions(-)
> >  create mode 100644 lib/uwildmat/uwildmat.c
> >  create mode 100644 lib/uwildmat/uwildmat.h
> > 
> > diff --git a/COPYING b/COPYING
> > index b8f6753..16375f2 100644
> > --- a/COPYING
> > +++ b/COPYING
> > @@ -106,3 +106,24 @@ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY 
> > CLAIM, DAMAGES OR OTHER
> >  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> >  FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> > DEALINGS
> >  IN THE SOFTWARE.
> > +
> > +Copyright (c) 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012,
> > +2013, 2014 by Internet Systems Consortium, Inc. ("ISC")
> > +Copyright (c) 1991, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001,
> > +2002, 2003 by The Internet Software Consortium and Rich Salz
> > +
> > +This code is derived from software contributed to the Internet Software
> > +Consortium by Rich Salz.
> > +
> > +Permission to use, copy, modify, and distribute this software for any
> > +purpose with or without fee is hereby granted, provided that the above
> > +copyright notice and this permission notice appear in all copies.
> > +
> > +THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
> > +REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> > +MERCHANTABILITY AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY
> > +SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> > +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> > +ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> > +OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> > +
> > diff --git a/lib/Makefile.sources b/lib/Makefile.sources
> > index 4999868..e33861e 100644
> > --- a/lib/Makefile.sources
> > +++ b/lib/Makefile.sources
> > @@ -60,6 +60,8 @@ libintel_tools_la_SOURCES =   \
> > igt_core.h  \
> > igt_draw.c  \
> > igt_draw.h  \
> > +   uwildmat/uwildmat.h \
> > +   uwildmat/uwildmat.c \
> > $(NULL)
> >  
> >  .PHONY: version.h.tmp
> > diff --git a/lib/igt_core.c b/lib/igt_core.c
> > index 6b69bb7..8e0bd2e 100644
> > --- a/lib/igt_core.c
> > +++ b/lib/igt_core.c
> > @@ -56,7 +56,7 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> > +#include 
> >  
> >  #include "drmtest.h"
> >  #include "intel_chipset.h"
> > @@ -209,6 +209,19 @@
> >   * intel gpu to be present). Then individual subtests can be run with
> >   * "--run-subtest". Usage help for tests with subtests can be obtained 
> > with the
> >   * "--help" command line option.
> > + *
> > + * A wildcard expression can be given to --run-subtest to specify a subset 
> > of
> > + * subtests to run. See https://tools.ietf.org/html/rfc3977#section-4 for a
> > + * description of allowed wildcard expressions.
> > + * Some examples of allowed wildcard expressions are:
> > + *
> > + * - '*basic*' match any subtest containing basic
> > + * - 'basic-???' match any subtest named basic- with 3 characters after -
> > + * - 'basic-[0-9]' match any subtest named basic- with a single number 
> > after -
> > + * - 'basic-[^0-9]' match any subtest named basic- with a single non 
> > numerical character after -
> > + * - 'basic*,advanced*' match any subtest starting basic or advanced
> > + * - '*,!basic*' match any subtest not starting basic
> > + * - 'basic*,!basic-render*' match any subtest starting basic but not 
> > starting basic-render
> >   */
> >  
> >  static unsigned int exit_handler_count;
> > @@ -814,7 

Re: [Intel-gfx] [PATCH v4 3/8] drm/i915: Kill off intel_crtc->atomic.wait_vblank, v4.

[Zanoni, Paulo R]

Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
> Currently we perform our own wait in post_plane_update,
> but the atomic core performs another one in wait_for_vblanks.
> This means that 2 vblanks are done when a fb is changed,
> which is a bit overkill.
> 
> Merge them by creating a helper function that takes a crtc mask
> for the planes to wait on.
> 
> The broadwell vblank workaround may look gone entirely but this is
> not the case. pipe_config->wm_changed is set to true
> when any plane is turned on, which forces a vblank wait.
> 
> Changes since v1:
> - Removing the double vblank wait on broadwell moved to its own
> commit.
> Changes since v2:
> - Move out POWER_DOMAIN_MODESET handling to its own commit.
> Changes since v3:
> - Do not wait for vblank on legacy cursor updates. (Ville)
> - Move broadwell vblank workaround comment to page_flip_finished.
> (Ville)
> Changes since v4:
> - Compile fix, legacy_cursor_flip -> *_update.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_atomic.c  |  1 +
>  drivers/gpu/drm/i915/intel_display.c | 86
> +++-
>  drivers/gpu/drm/i915/intel_drv.h |  2 +-
>  3 files changed, 67 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 4625f8a9ba12..8e579a8505ac 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -97,6 +97,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
>   crtc_state->disable_lp_wm = false;
>   crtc_state->disable_cxsr = false;
>   crtc_state->wm_changed = false;
> + crtc_state->fb_changed = false;
>  
>   return _state->base;
>  }
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 804f2c6f260d..4d4dddc1f970 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4785,9 +4785,6 @@ static void intel_post_plane_update(struct
> intel_crtc *crtc)
>   to_intel_crtc_state(crtc->base.state);
>   struct drm_device *dev = crtc->base.dev;
>  
> - if (atomic->wait_vblank)
> - intel_wait_for_vblank(dev, crtc->pipe);
> -
>   intel_frontbuffer_flip(dev, atomic->fb_bits);
>  
>   crtc->wm.cxsr_allowed = true;
> @@ -10902,6 +10899,12 @@ static bool page_flip_finished(struct
> intel_crtc *crtc)
>   return true;
>  
>   /*
> +  * BDW signals flip done immediately if the plane
> +  * is disabled, even if the plane enable is already
> +  * armed to occur at the next vblank :(
> +  */

Having this comment here is just... weird. I think it removes a lot of
the context that was present before.

> +
> + /*
>    * A DSPSURFLIVE check isn't enough in case the mmio and CS
> flips
>    * used the same base address. In that case the mmio flip
> might
>    * have completed, but the CS hasn't even executed the flip
> yet.
> @@ -11778,6 +11781,9 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
>   if (!was_visible && !visible)
>   return 0;
>  
> + if (fb != old_plane_state->base.fb)
> + pipe_config->fb_changed = true;
> +
>   turn_off = was_visible && (!visible || mode_changed);
>   turn_on = visible && (!was_visible || mode_changed);
>  
> @@ -11793,8 +11799,6 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
>  
>   /* must disable cxsr around plane enable/disable */
>   if (plane->type != DRM_PLANE_TYPE_CURSOR) {
> - if (is_crtc_enabled)
> - intel_crtc->atomic.wait_vblank =
> true;
>   pipe_config->disable_cxsr = true;
>   }

We could have killed the brackets here :)

>   } else if (intel_wm_need_update(plane, plane_state)) {
> @@ -11810,14 +11814,6 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
>   intel_crtc->atomic.post_enable_primary = turn_on;
>   intel_crtc->atomic.update_fbc = true;
>  
> - /*
> -  * BDW signals flip done immediately if the plane
> -  * is disabled, even if the plane enable is already
> -  * armed to occur at the next vblank :(
> -  */
> - if (turn_on && IS_BROADWELL(dev))
> - intel_crtc->atomic.wait_vblank = true;
> -
>   break;
>   case DRM_PLANE_TYPE_CURSOR:
>   break;
> @@ -11831,12 +11827,10 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
>   if (IS_IVYBRIDGE(dev) &&
>   needs_scaling(to_intel_plane_state(plane_state))
> &&
>   !needs_scaling(old_plane_state)) {
> - to_intel_crtc_state(crtc_state)-
> >disable_lp_wm = true;
> - } else if 

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Additional MIPI clock divider form B0 stepping onwards

[Jani Nikula]

On Mon, 15 Feb 2016, Deepak M  wrote:
> The MIPI clock calculations for the addtional clock
> are revised from B0 stepping onwards, the bit definitions
> have changed compared to old stepping.
>
> v2: Fixing compilation warning.
> v3: Retained the old Macros (Jani)
>
> Signed-off-by: Deepak M 

Reviewed-by: Jani Nikula 


> ---
>  drivers/gpu/drm/i915/i915_reg.h  | 96 
> +++-
>  drivers/gpu/drm/i915/intel_dsi_pll.c | 56 ++---
>  2 files changed, 89 insertions(+), 63 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 144586e..4e61b06 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7663,58 +7663,62 @@ enum skl_disp_power_wells {
>  #define  BXT_MIPI_DIV_SHIFT(port)\
>   _MIPI_PORT(port, BXT_MIPI1_DIV_SHIFT, \
>   BXT_MIPI2_DIV_SHIFT)
> -/* Var clock divider to generate TX source. Result must be < 39.5 M */
> -#define  BXT_MIPI1_ESCLK_VAR_DIV_MASK(0x3F << 26)
> -#define  BXT_MIPI2_ESCLK_VAR_DIV_MASK(0x3F << 10)
> -#define  BXT_MIPI_ESCLK_VAR_DIV_MASK(port)   \
> - _MIPI_PORT(port, BXT_MIPI1_ESCLK_VAR_DIV_MASK, \
> - BXT_MIPI2_ESCLK_VAR_DIV_MASK)
> -
> -#define  BXT_MIPI_ESCLK_VAR_DIV(port, val)   \
> - (val << BXT_MIPI_DIV_SHIFT(port))
> +
>  /* TX control divider to select actual TX clock output from (8x/var) */
> -#define  BXT_MIPI1_TX_ESCLK_SHIFT21
> -#define  BXT_MIPI2_TX_ESCLK_SHIFT5
> +#define  BXT_MIPI1_TX_ESCLK_SHIFT26
> +#define  BXT_MIPI2_TX_ESCLK_SHIFT10
>  #define  BXT_MIPI_TX_ESCLK_SHIFT(port)   \
>   _MIPI_PORT(port, BXT_MIPI1_TX_ESCLK_SHIFT, \
>   BXT_MIPI2_TX_ESCLK_SHIFT)
> -#define  BXT_MIPI1_TX_ESCLK_FIXDIV_MASK  (3 << 21)
> -#define  BXT_MIPI2_TX_ESCLK_FIXDIV_MASK  (3 << 5)
> +#define  BXT_MIPI1_TX_ESCLK_FIXDIV_MASK  (0x3F << 26)
> +#define  BXT_MIPI2_TX_ESCLK_FIXDIV_MASK  (0x3F << 10)
>  #define  BXT_MIPI_TX_ESCLK_FIXDIV_MASK(port) \
>   _MIPI_PORT(port, BXT_MIPI1_TX_ESCLK_FIXDIV_MASK, \
> - BXT_MIPI2_TX_ESCLK_FIXDIV_MASK)
> -#define  BXT_MIPI_TX_ESCLK_8XDIV_BY2(port)   \
> - (0x0 << BXT_MIPI_TX_ESCLK_SHIFT(port))
> -#define  BXT_MIPI_TX_ESCLK_8XDIV_BY4(port)   \
> - (0x1 << BXT_MIPI_TX_ESCLK_SHIFT(port))
> -#define  BXT_MIPI_TX_ESCLK_8XDIV_BY8(port)   \
> - (0x2 << BXT_MIPI_TX_ESCLK_SHIFT(port))
> -/* RX control divider to select actual RX clock output from 8x*/
> -#define  BXT_MIPI1_RX_ESCLK_SHIFT19
> -#define  BXT_MIPI2_RX_ESCLK_SHIFT3
> -#define  BXT_MIPI_RX_ESCLK_SHIFT(port)   \
> - _MIPI_PORT(port, BXT_MIPI1_RX_ESCLK_SHIFT, \
> - BXT_MIPI2_RX_ESCLK_SHIFT)
> -#define  BXT_MIPI1_RX_ESCLK_FIXDIV_MASK  (3 << 19)
> -#define  BXT_MIPI2_RX_ESCLK_FIXDIV_MASK  (3 << 3)
> -#define  BXT_MIPI_RX_ESCLK_FIXDIV_MASK(port) \
> - (3 << BXT_MIPI_RX_ESCLK_SHIFT(port))
> -#define  BXT_MIPI_RX_ESCLK_8X_BY2(port)  \
> - (1 << BXT_MIPI_RX_ESCLK_SHIFT(port))
> -#define  BXT_MIPI_RX_ESCLK_8X_BY3(port)  \
> - (2 << BXT_MIPI_RX_ESCLK_SHIFT(port))
> -#define  BXT_MIPI_RX_ESCLK_8X_BY4(port)  \
> - (3 << BXT_MIPI_RX_ESCLK_SHIFT(port))
> -/* BXT-A WA: Always prog DPHY dividers to 00 */
> -#define  BXT_MIPI1_DPHY_DIV_SHIFT16
> -#define  BXT_MIPI2_DPHY_DIV_SHIFT0
> -#define  BXT_MIPI_DPHY_DIV_SHIFT(port)   \
> - _MIPI_PORT(port, BXT_MIPI1_DPHY_DIV_SHIFT, \
> - BXT_MIPI2_DPHY_DIV_SHIFT)
> -#define  BXT_MIPI_1_DPHY_DIVIDER_MASK(3 << 16)
> -#define  BXT_MIPI_2_DPHY_DIVIDER_MASK(3 << 0)
> -#define  BXT_MIPI_DPHY_DIVIDER_MASK(port)\
> - (3 << BXT_MIPI_DPHY_DIV_SHIFT(port))
> + BXT_MIPI2_TX_ESCLK_FIXDIV_MASK)
> +#define  BXT_MIPI_TX_ESCLK_DIVIDER(port, val)\
> + ((val & 0x3F) << BXT_MIPI_TX_ESCLK_SHIFT(port))
> +/* RX upper control divider to select actual RX clock output from 8x*/
> +#define  BXT_MIPI1_RX_ESCLK_UPPER_SHIFT  21
> +#define  BXT_MIPI2_RX_ESCLK_UPPER_SHIFT  5
> +#define  BXT_MIPI_RX_ESCLK_UPPER_SHIFT(port) \
> + _MIPI_PORT(port, BXT_MIPI1_RX_ESCLK_UPPER_SHIFT, \
> + BXT_MIPI2_RX_ESCLK_UPPER_SHIFT)
> +#define  BXT_MIPI1_RX_ESCLK_UPPER_FIXDIV_MASK(3 << 21)
> +#define  

Re: [Intel-gfx] [PATCH v4 2/8] drm/i915: Unify power domain handling.

[Zanoni, Paulo R]

Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
> Right now there's separate power domain handling for update_pipe and
> modesets. Unify this and only grab POWER_DOMAIN_MODESET once.

I would have split this in two separate commits: one for
POWER_DOMAIN_MODESET, and the other for killing
intel_modeset_update_crtc_power_domains. Let's hope no one bisects
anything to this patch :)

With or without the split:
Reviewed-by: Paulo Zanoni 

> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 69 +-
> --
>  1 file changed, 24 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index b479ba6238d7..804f2c6f260d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5359,32 +5359,6 @@ static void modeset_put_power_domains(struct
> drm_i915_private *dev_priv,
>   intel_display_power_put(dev_priv, domain);
>  }
>  
> -static void modeset_update_crtc_power_domains(struct
> drm_atomic_state *state)
> -{
> - struct intel_atomic_state *intel_state =
> to_intel_atomic_state(state);
> - struct drm_device *dev = state->dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - unsigned long put_domains[I915_MAX_PIPES] = {};
> - struct drm_crtc_state *crtc_state;
> - struct drm_crtc *crtc;
> - int i;
> -
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> - if (needs_modeset(crtc->state))
> - put_domains[to_intel_crtc(crtc)->pipe] =
> - modeset_get_crtc_power_domains(crtc,
> - to_intel_crtc_state(crtc-
> >state));
> - }
> -
> - if (dev_priv->display.modeset_commit_cdclk &&
> - intel_state->dev_cdclk != dev_priv->cdclk_freq)
> - dev_priv->display.modeset_commit_cdclk(state);
> -
> - for (i = 0; i < I915_MAX_PIPES; i++)
> - if (put_domains[i])
> - modeset_put_power_domains(dev_priv,
> put_domains[i]);
> -}
> -
>  static int intel_compute_max_dotclk(struct drm_i915_private
> *dev_priv)
>  {
>   int max_cdclk_freq = dev_priv->max_cdclk_freq;
> @@ -13422,6 +13396,7 @@ static int intel_atomic_commit(struct
> drm_device *dev,
>   struct drm_crtc *crtc;
>   int ret = 0, i;
>   bool hw_check = intel_state->modeset;
> + unsigned long put_domains[I915_MAX_PIPES] = {};
>  
>   ret = intel_atomic_prepare_commit(dev, state, async);
>   if (ret) {
> @@ -13437,11 +13412,22 @@ static int intel_atomic_commit(struct
> drm_device *dev,
>      sizeof(intel_state->min_pixclk));
>   dev_priv->active_crtcs = intel_state->active_crtcs;
>   dev_priv->atomic_cdclk_freq = intel_state->cdclk;
> +
> + intel_display_power_get(dev_priv,
> POWER_DOMAIN_MODESET);
>   }
>  
>   for_each_crtc_in_state(state, crtc, crtc_state, i) {
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>  
> + if (needs_modeset(crtc->state) ||
> + to_intel_crtc_state(crtc->state)->update_pipe) {
> + hw_check = true;
> +
> + put_domains[to_intel_crtc(crtc)->pipe] =
> + modeset_get_crtc_power_domains(crtc,
> + to_intel_crtc_state(crtc-
> >state));
> + }
> +
>   if (!needs_modeset(crtc->state))
>   continue;
>  
> @@ -13474,7 +13460,10 @@ static int intel_atomic_commit(struct
> drm_device *dev,
>   intel_shared_dpll_commit(state);
>  
>   drm_atomic_helper_update_legacy_modeset_state(state-
> >dev, state);
> - modeset_update_crtc_power_domains(state);
> +
> + if (dev_priv->display.modeset_commit_cdclk &&
> + intel_state->dev_cdclk != dev_priv->cdclk_freq)
> + dev_priv-
> >display.modeset_commit_cdclk(state);
>   }
>  
>   /* Now enable the clocks, plane, pipe, and connectors that
> we set up. */
> @@ -13483,24 +13472,12 @@ static int intel_atomic_commit(struct
> drm_device *dev,
>   bool modeset = needs_modeset(crtc->state);
>   bool update_pipe = !modeset &&
>   to_intel_crtc_state(crtc->state)-
> >update_pipe;
> - unsigned long put_domains = 0;
> -
> - if (modeset)
> - intel_display_power_get(dev_priv,
> POWER_DOMAIN_MODESET);
>  
>   if (modeset && crtc->state->active) {
>   update_scanline_offset(to_intel_crtc(crtc));
>   dev_priv->display.crtc_enable(crtc);
>   }
>  
> - if (update_pipe) {
> - put_domains =
> modeset_get_crtc_power_domains(crtc,
> - 

[Intel-gfx] [PATCH 4/6] drm/i915: Make the LPT iclkip 20MHz case more generic

[ville . syrjala]

From: Ville Syrjälä 

The reason for spcial casing 20MHz in the iclkip calculations is that
it would overflow the 7 bit divisor value. Let's rewrite the special
case to check for just that, and bump up auxdiv when needed. This makes
the code work for freqeuencies close to but not exactly 20MHz. The real
lower limit for auxdiv=0 is actually:
17280/(0x7f+2)*64)=~20930 kHz, and below that we must resort to
auxdiv=1.

Actually this is all very theoretical since we limit the dotclock to
min 25MHz with CRT on all platforms. 25Mhz is actually the documented
limit in Bspec, so it seems we ought to never need to worry about the
auxdiv=1 case. But no harm in having it.

Cc: Paulo Zanoni 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 40 +---
 1 file changed, 19 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a3c959cd8b3b..5e7b22a31098 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3957,37 +3957,35 @@ static 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)
 {
-   struct drm_device *dev = crtc->dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_i915_private *dev_priv = to_i915(crtc->dev);
int clock = to_intel_crtc(crtc)->config->base.adjusted_mode.crtc_clock;
u32 divsel, phaseinc, auxdiv, phasedir = 0;
u32 temp;
 
lpt_disable_iclkip(dev_priv);
 
-   /* 20MHz is a corner case which is out of range for the 7-bit divisor */
-   if (clock == 2) {
-   auxdiv = 1;
-   divsel = 0x41;
-   phaseinc = 0x20;
-   } else {
-   /* The iCLK virtual clock root frequency is in MHz,
-* but the adjusted_mode->crtc_clock in in KHz. To get the
-* divisors, it is necessary to divide one by another, so we
-* convert the virtual clock precision to KHz here for higher
-* precision.
-*/
+   /* The iCLK virtual clock root frequency is in MHz,
+* but the adjusted_mode->crtc_clock in in KHz. To get the
+* divisors, it is necessary to divide one by another, so we
+* convert the virtual clock precision to KHz here for higher
+* precision.
+*/
+   for (auxdiv = 0; auxdiv < 2; auxdiv++) {
u32 iclk_virtual_root_freq = 172800 * 1000;
u32 iclk_pi_range = 64;
-   u32 desired_divisor, msb_divisor_value, pi_value;
+   u32 desired_divisor;
 
-   desired_divisor = DIV_ROUND_CLOSEST(iclk_virtual_root_freq, 
clock);
-   msb_divisor_value = desired_divisor / iclk_pi_range;
-   pi_value = desired_divisor % iclk_pi_range;
+   desired_divisor = DIV_ROUND_CLOSEST(iclk_virtual_root_freq,
+   clock << auxdiv);
+   divsel = (desired_divisor / iclk_pi_range) - 2;
+   phaseinc = desired_divisor % iclk_pi_range;
 
-   auxdiv = 0;
-   divsel = msb_divisor_value - 2;
-   phaseinc = pi_value;
+   /*
+* Near 20MHz is a corner case which is
+* out of range for the 7-bit divisor
+*/
+   if (divsel <= 0x7f)
+   break;
}
 
/* This should not happen with any sane values */
-- 
2.4.10

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

[Intel-gfx] [PATCH 3/6] drm/i915: Remove the SPLL==270Mhz assumption from intel_fdi_link_freq()

[ville . syrjala]

From: Ville Syrjälä 

Instead of assuming we've correctly set up SPLL to run at 270Mhz for
FDI, let's use the port_clock from pipe_config which should be what
we want. This would catch problems if someone misconfigures SPLL for
whatever reason.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 99001e117517..a3c959cd8b3b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -224,12 +224,15 @@ static void intel_update_czclk(struct drm_i915_private 
*dev_priv)
 }
 
 static inline u32 /* units of 100MHz */
-intel_fdi_link_freq(struct drm_i915_private *dev_priv)
+intel_fdi_link_freq(struct drm_i915_private *dev_priv,
+   const struct intel_crtc_state *pipe_config)
 {
-   if (IS_GEN5(dev_priv))
-   return (I915_READ(FDI_PLL_BIOS_0) & FDI_PLL_FB_CLOCK_MASK) + 2;
+   if (HAS_DDI(dev_priv))
+   return pipe_config->port_clock; /* SPLL */
+   else if (IS_GEN5(dev_priv))
+   return ((I915_READ(FDI_PLL_BIOS_0) & FDI_PLL_FB_CLOCK_MASK) + 
2) * 1;
else
-   return 27;
+   return 27;
 }
 
 static const intel_limit_t intel_limits_i8xx_dac = {
@@ -6588,7 +6591,7 @@ retry:
 * Hence the bw of each lane in terms of the mode signal
 * is:
 */
-   link_bw = intel_fdi_link_freq(to_i915(dev)) * MHz(100)/KHz(1)/10;
+   link_bw = intel_fdi_link_freq(to_i915(dev), pipe_config);
 
fdi_dotclock = adjusted_mode->crtc_clock;
 
@@ -10774,7 +10777,7 @@ static void ironlake_pch_clock_get(struct intel_crtc 
*crtc,
 * Calculate one based on the FDI configuration.
 */
pipe_config->base.adjusted_mode.crtc_clock =
-   intel_dotclock_calculate(intel_fdi_link_freq(dev_priv) * 1,
+   intel_dotclock_calculate(intel_fdi_link_freq(dev_priv, 
pipe_config),
 _config->fdi_m_n);
 }
 
@@ -12789,7 +12792,7 @@ static void intel_pipe_config_sanity_check(struct 
drm_i915_private *dev_priv,
   const struct intel_crtc_state 
*pipe_config)
 {
if (pipe_config->has_pch_encoder) {
-   int fdi_dotclock = 
intel_dotclock_calculate(intel_fdi_link_freq(dev_priv) * 1,
+   int fdi_dotclock = 
intel_dotclock_calculate(intel_fdi_link_freq(dev_priv, pipe_config),

_config->fdi_m_n);
int dotclock = pipe_config->base.adjusted_mode.crtc_clock;
 
-- 
2.4.10

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

[Intel-gfx] [PATCH 0/6] drm/i915: Some FDI related dotclock stuff

[ville . syrjala]

From: Ville Syrjälä 

Imre's SNB had a crappy BIOS that failed to configure the hardware
correctly when hooked up to a 4K monitor, which then resulted in
lots of noise from i915 when it was trying to make sense of the bad
state. That spurred me to reorganize the FDI dotclock vs. encoder
dotclock sanity check we have in the encoder .get_config() hooks.
And while doing that I figured we might as well try to read out
the actual VGA dotclock via sideband on HSW/BDW, which can then
be compared to the one compute from FDI parameters.

Apparently a BIOS update solved the problem for Imre, but I think
these patches still have some value by adding more thorough state
cross checking on HSW/BDW, and just moving out the sanity checks
from the state readout code makes quite a bit of sense to me, 
especially if we run into more buggy BIOSen. Though if people
prefer, I could respin these without that particular change,
ie. just keep the LPT-H dotclock readout and cross checking
essentially.

I also ended up fixing the port clock limits for CRT for various
platforms.

Ville Syrjälä (6):
  drm/i915: Dump ddi_pll_sel in hex instead of decimal on HSW/BDW
  drm/i915: Move the encoder vs. FDI dotclock check out from encoder
.get_config()
  drm/i915: Remove the SPLL==270Mhz assumption from
intel_fdi_link_freq()
  drm/i915: Make the LPT iclkip 20MHz case more generic
  drm/i915: Read out VGA dotclock properly on LPT
  drm/i915: Try to fix CRT port clock limits

 drivers/gpu/drm/i915/i915_reg.h  |   8 +-
 drivers/gpu/drm/i915/intel_crt.c |  30 
 drivers/gpu/drm/i915/intel_display.c | 143 +++
 drivers/gpu/drm/i915/intel_dp.c  |  11 +--
 drivers/gpu/drm/i915/intel_drv.h |   4 +-
 drivers/gpu/drm/i915/intel_hdmi.c|   3 -
 drivers/gpu/drm/i915/intel_lvds.c|   8 +-
 drivers/gpu/drm/i915/intel_sdvo.c|   4 +-
 8 files changed, 123 insertions(+), 88 deletions(-)

-- 
2.4.10

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

[Intel-gfx] [PATCH 6/6] drm/i915: Try to fix CRT port clock limits

[ville . syrjala]

From: Ville Syrjälä 

LPT/WPT-H are limited to max 180 MHz CRT dotclock. Most other platforms
have a limit of 350 MHz. Supposedly gen3 and gen4 go up to 400 MHz.

VLV is a bit special since the docs are poor. Supposedly the DAC
would be good up to 355 MHz, but currently we limit the DPLL to
270 MHz, so we'll have to limit the port clock to the same unless
we change the DPLL limits.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_crt.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 08964bbd7c82..6bdd4f4310f1 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -220,18 +220,26 @@ intel_crt_mode_valid(struct drm_connector *connector,
 {
struct drm_device *dev = connector->dev;
int max_dotclk = to_i915(dev)->max_dotclk_freq;
+   int max_clock;
 
-   int max_clock = 0;
if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
return MODE_NO_DBLESCAN;
 
if (mode->clock < 25000)
return MODE_CLOCK_LOW;
 
-   if (IS_GEN2(dev))
-   max_clock = 35;
-   else
+   if (HAS_PCH_LPT(dev))
+   max_clock = 18;
+   else if (IS_VALLEYVIEW(dev))
+   /*
+* 270 MHz due to current DPLL limits,
+* DAC limit supposedly 355 MHz.
+*/
+   max_clock = 27;
+   else if (IS_GEN3(dev) || IS_GEN4(dev))
max_clock = 40;
+   else
+   max_clock = 35;
if (mode->clock > max_clock)
return MODE_CLOCK_HIGH;
 
-- 
2.4.10

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

[Intel-gfx] [PATCH 5/6] drm/i915: Read out VGA dotclock properly on LPT

[ville . syrjala]

From: Ville Syrjälä 

Rather than assume the VGA dotclock is really the FDI based thing,
let's read out the real thing via iclkip, and after readout it'll
get to compare it with the FDI based number to make sure they're
in sync.

Cc: Paulo Zanoni 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h  |  8 ++--
 drivers/gpu/drm/i915/intel_crt.c |  4 
 drivers/gpu/drm/i915/intel_display.c | 37 
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 4 files changed, 48 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3774870477c1..a5f2c6e2edb2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7362,9 +7362,11 @@ enum skl_disp_power_wells {
 /* SBI offsets */
 #define  SBI_SSCDIVINTPHASE0x0200
 #define  SBI_SSCDIVINTPHASE6   0x0600
-#define   SBI_SSCDIVINTPHASE_DIVSEL_MASK   ((0x7f)<<1)
+#define   SBI_SSCDIVINTPHASE_DIVSEL_SHIFT  1
+#define   SBI_SSCDIVINTPHASE_DIVSEL_MASK   (0x7f<<1)
 #define   SBI_SSCDIVINTPHASE_DIVSEL(x) ((x)<<1)
-#define   SBI_SSCDIVINTPHASE_INCVAL_MASK   ((0x7f)<<8)
+#define   SBI_SSCDIVINTPHASE_INCVAL_SHIFT  8
+#define   SBI_SSCDIVINTPHASE_INCVAL_MASK   (0x7f<<8)
 #define   SBI_SSCDIVINTPHASE_INCVAL(x) ((x)<<8)
 #define   SBI_SSCDIVINTPHASE_DIR(x)((x)<<15)
 #define   SBI_SSCDIVINTPHASE_PROPAGATE (1<<0)
@@ -7374,6 +7376,8 @@ enum skl_disp_power_wells {
 #define   SBI_SSCCTL_PATHALT   (1<<3)
 #define   SBI_SSCCTL_DISABLE   (1<<0)
 #define  SBI_SSCAUXDIV60x0610
+#define   SBI_SSCAUXDIV_FINALDIV2SEL_SHIFT 4
+#define   SBI_SSCAUXDIV_FINALDIV2SEL_MASK  (1<<4)
 #define   SBI_SSCAUXDIV_FINALDIV2SEL(x)((x)<<4)
 #define  SBI_DBUFF00x2a00
 #define  SBI_GEN0  0x1f00
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index f4c88d93a164..08964bbd7c82 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -128,6 +128,8 @@ static void intel_crt_get_config(struct intel_encoder 
*encoder,
 static void hsw_crt_get_config(struct intel_encoder *encoder,
   struct intel_crtc_state *pipe_config)
 {
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+
intel_ddi_get_config(encoder, pipe_config);
 
pipe_config->base.adjusted_mode.flags &= ~(DRM_MODE_FLAG_PHSYNC |
@@ -135,6 +137,8 @@ static void hsw_crt_get_config(struct intel_encoder 
*encoder,
  DRM_MODE_FLAG_PVSYNC |
  DRM_MODE_FLAG_NVSYNC);
pipe_config->base.adjusted_mode.flags |= intel_crt_get_flags(encoder);
+
+   pipe_config->base.adjusted_mode.crtc_clock = lpt_get_iclkip(dev_priv);
 }
 
 /* Note: The caller is required to filter out dpms modes not supported by the
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5e7b22a31098..43cae2f8016d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4032,6 +4032,43 @@ static void lpt_program_iclkip(struct drm_crtc *crtc)
I915_WRITE(PIXCLK_GATE, PIXCLK_GATE_UNGATE);
 }
 
+int lpt_get_iclkip(struct drm_i915_private *dev_priv)
+{
+   u32 divsel, phaseinc, auxdiv;
+   u32 iclk_virtual_root_freq = 172800 * 1000;
+   u32 iclk_pi_range = 64;
+   u32 desired_divisor;
+   u32 temp;
+
+   if ((I915_READ(PIXCLK_GATE) & PIXCLK_GATE_UNGATE) == 0)
+   return 0;
+
+   mutex_lock(_priv->sb_lock);
+
+   temp = intel_sbi_read(dev_priv, SBI_SSCCTL6, SBI_ICLK);
+   if (temp & SBI_SSCCTL_DISABLE) {
+   mutex_unlock(_priv->sb_lock);
+   return 0;
+   }
+
+   temp = intel_sbi_read(dev_priv, SBI_SSCDIVINTPHASE6, SBI_ICLK);
+   divsel = (temp & SBI_SSCDIVINTPHASE_DIVSEL_MASK) >>
+   SBI_SSCDIVINTPHASE_DIVSEL_SHIFT;
+   phaseinc = (temp & SBI_SSCDIVINTPHASE_INCVAL_MASK) >>
+   SBI_SSCDIVINTPHASE_INCVAL_SHIFT;
+
+   temp = intel_sbi_read(dev_priv, SBI_SSCAUXDIV6, SBI_ICLK);
+   auxdiv = (temp & SBI_SSCAUXDIV_FINALDIV2SEL_MASK) >>
+   SBI_SSCAUXDIV_FINALDIV2SEL_SHIFT;
+
+   mutex_unlock(_priv->sb_lock);
+
+   desired_divisor = (divsel + 2) * iclk_pi_range + phaseinc;
+
+   return DIV_ROUND_CLOSEST(iclk_virtual_root_freq,
+desired_divisor << auxdiv);
+}
+
 static void ironlake_pch_transcoder_set_timings(struct intel_crtc *crtc,
enum pipe pch_transcoder)
 {
diff --git a/drivers/gpu/drm/i915/intel_drv.h 

[Intel-gfx] [PATCH 1/6] drm/i915: Dump ddi_pll_sel in hex instead of decimal on HSW/BDW

[ville . syrjala]

From: Ville Syrjälä 

On HSW/BDW ddi_pll_sel is the actual register value. Let's dump
it in hex so that people migth actually understand what it says.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index afcabe455ad1..f0f88061a9e5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12220,7 +12220,7 @@ static void intel_dump_pipe_config(struct intel_crtc 
*crtc,
  pipe_config->dpll_hw_state.cfgcr1,
  pipe_config->dpll_hw_state.cfgcr2);
} else if (HAS_DDI(dev)) {
-   DRM_DEBUG_KMS("ddi_pll_sel: %u; dpll_hw_state: wrpll: 0x%x 
spll: 0x%x\n",
+   DRM_DEBUG_KMS("ddi_pll_sel: 0x%x; dpll_hw_state: wrpll: 0x%x 
spll: 0x%x\n",
  pipe_config->ddi_pll_sel,
  pipe_config->dpll_hw_state.wrpll,
  pipe_config->dpll_hw_state.spll);
-- 
2.4.10

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

[Intel-gfx] [PATCH 2/6] drm/i915: Move the encoder vs. FDI dotclock check out from encoder .get_config()

[ville . syrjala]

From: Ville Syrjälä 

Currently we check if the encoder's idea of dotclock agrees with what
we calculated based on the FDI parameters. We do this in the encoder
.get_config() hooks, which isn't so nice in case the BIOS (or some other
outside party) made a mess of the state and we're just trying to take
over.

So as a prep step to being able sanitize such a bogus state, move the
the sanity check to just after we've read out the entire state. If
we then need to sanitize a bad state, it should be easier to move the
sanity check to occur after sanitation instead of before it.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_crt.c | 10 +--
 drivers/gpu/drm/i915/intel_display.c | 57 
 drivers/gpu/drm/i915/intel_dp.c  | 11 ++-
 drivers/gpu/drm/i915/intel_drv.h |  3 --
 drivers/gpu/drm/i915/intel_hdmi.c|  3 --
 drivers/gpu/drm/i915/intel_lvds.c|  8 +
 drivers/gpu/drm/i915/intel_sdvo.c|  4 +--
 7 files changed, 38 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index e686a91a416e..f4c88d93a164 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -120,17 +120,9 @@ static unsigned int intel_crt_get_flags(struct 
intel_encoder *encoder)
 static void intel_crt_get_config(struct intel_encoder *encoder,
 struct intel_crtc_state *pipe_config)
 {
-   struct drm_device *dev = encoder->base.dev;
-   int dotclock;
-
pipe_config->base.adjusted_mode.flags |= intel_crt_get_flags(encoder);
 
-   dotclock = pipe_config->port_clock;
-
-   if (HAS_PCH_SPLIT(dev))
-   ironlake_check_encoder_dotclock(pipe_config, dotclock);
-
-   pipe_config->base.adjusted_mode.crtc_clock = dotclock;
+   pipe_config->base.adjusted_mode.crtc_clock = pipe_config->port_clock;
 }
 
 static void hsw_crt_get_config(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f0f88061a9e5..99001e117517 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -224,12 +224,11 @@ static void intel_update_czclk(struct drm_i915_private 
*dev_priv)
 }
 
 static inline u32 /* units of 100MHz */
-intel_fdi_link_freq(struct drm_device *dev)
+intel_fdi_link_freq(struct drm_i915_private *dev_priv)
 {
-   if (IS_GEN5(dev)) {
-   struct drm_i915_private *dev_priv = dev->dev_private;
+   if (IS_GEN5(dev_priv))
return (I915_READ(FDI_PLL_BIOS_0) & FDI_PLL_FB_CLOCK_MASK) + 2;
-   } else
+   else
return 27;
 }
 
@@ -6589,7 +6588,7 @@ retry:
 * Hence the bw of each lane in terms of the mode signal
 * is:
 */
-   link_bw = intel_fdi_link_freq(dev) * MHz(100)/KHz(1)/10;
+   link_bw = intel_fdi_link_freq(to_i915(dev)) * MHz(100)/KHz(1)/10;
 
fdi_dotclock = adjusted_mode->crtc_clock;
 
@@ -6601,8 +6600,7 @@ retry:
intel_link_compute_m_n(pipe_config->pipe_bpp, lane, fdi_dotclock,
   link_bw, _config->fdi_m_n);
 
-   ret = ironlake_check_fdi_lanes(intel_crtc->base.dev,
-  intel_crtc->pipe, pipe_config);
+   ret = ironlake_check_fdi_lanes(dev, intel_crtc->pipe, pipe_config);
if (ret == -EINVAL && pipe_config->pipe_bpp > 6*3) {
pipe_config->pipe_bpp -= 2*3;
DRM_DEBUG_KMS("fdi link bw constraint, reducing pipe bpp to 
%i\n",
@@ -10765,19 +10763,18 @@ int intel_dotclock_calculate(int link_freq,
 static void ironlake_pch_clock_get(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(crtc->base.dev);
 
/* read out port_clock from the DPLL */
i9xx_crtc_clock_get(crtc, pipe_config);
 
/*
-* This value does not include pixel_multiplier.
-* We will check that port_clock and adjusted_mode.crtc_clock
-* agree once we know their relationship in the encoder's
-* get_config() function.
+* In case there is an active pipe without active ports,
+* we may need some idea for the dotclock anyway.
+* Calculate one based on the FDI configuration.
 */
pipe_config->base.adjusted_mode.crtc_clock =
-   intel_dotclock_calculate(intel_fdi_link_freq(dev) * 1,
+   intel_dotclock_calculate(intel_fdi_link_freq(dev_priv) * 1,
 _config->fdi_m_n);
 }
 
@@ -12788,6 +12785,24 @@ intel_pipe_config_compare(struct drm_device *dev,
return ret;
 }
 
+static void intel_pipe_config_sanity_check(struct drm_i915_private *dev_priv,
+  

[Intel-gfx] [PATCH] drm/i915: Extract intel_encoder_has_connectors()

[ville . syrjala]

From: Ville Syrjälä 

We have an open coded loop which tries to see if the encoder has any
connectors linked to it. Let's extract that to a helper similar to
intel_crtc_has_encoders().

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index afcabe455ad1..4071b75a7247 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15486,6 +15486,17 @@ static bool intel_crtc_has_encoders(struct intel_crtc 
*crtc)
return false;
 }
 
+static bool intel_encoder_has_connectors(struct intel_encoder *encoder)
+{
+   struct drm_device *dev = encoder->base.dev;
+   struct intel_connector *connector;
+
+   for_each_connector_on_encoder(dev, >base, connector)
+   return true;
+
+   return false;
+}
+
 static void intel_sanitize_crtc(struct intel_crtc *crtc)
 {
struct drm_device *dev = crtc->base.dev;
@@ -15596,7 +15607,6 @@ static void intel_sanitize_encoder(struct intel_encoder 
*encoder)
 {
struct intel_connector *connector;
struct drm_device *dev = encoder->base.dev;
-   bool active = false;
 
/* We need to check both for a crtc link (meaning that the
 * encoder is active and trying to read from a pipe) and the
@@ -15604,15 +15614,7 @@ static void intel_sanitize_encoder(struct 
intel_encoder *encoder)
bool has_active_crtc = encoder->base.crtc &&
to_intel_crtc(encoder->base.crtc)->active;
 
-   for_each_intel_connector(dev, connector) {
-   if (connector->base.encoder != >base)
-   continue;
-
-   active = true;
-   break;
-   }
-
-   if (active && !has_active_crtc) {
+   if (intel_encoder_has_connectors(encoder) && !has_active_crtc) {
DRM_DEBUG_KMS("[ENCODER:%d:%s] has active connectors but no 
active pipe!\n",
  encoder->base.base.id,
  encoder->base.name);
-- 
2.4.10

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

Re: [Intel-gfx] [PATCH v2] drm/atomic: Allow for holes in connector state, v2.

[Ville Syrjälä]

On Wed, Feb 17, 2016 at 08:32:05AM +0100, Maarten Lankhorst wrote:
> Because we record connector_mask using 1 << drm_connector_index now
> the connector_mask should stay the same even when other connectors
> are removed. This was not the case with MST, in that case when removing
> a connector all other connectors may change their index.
> 
> This is fixed by waiting until the first get_connector_state to allocate
> connector_state, and force reallocation when state is too small.
> 
> As a side effect connector arrays no longer have to be preallocated,
> and can be allocated on first use which means a less allocations in
> the page flip only path.
> 
> Changes since v1:
> - Whitespace. (Ville)
> - Call ida_remove when destroying the connector. (Ville)
> - u32 alloc -> int. (Ville)
> 
> Fixes: 14de6c44d149 ("drm/atomic: Remove drm_atomic_connectors_for_crtc.")
> Signed-off-by: Maarten Lankhorst 
> Cc: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_atomic.c| 44 +++--
>  drivers/gpu/drm/drm_atomic_helper.c |  2 +-
>  drivers/gpu/drm/drm_crtc.c  | 49 
> +++--
>  include/drm/drm_crtc.h  |  8 +-
>  4 files changed, 48 insertions(+), 55 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 8fb469c4e4b8..092620c6ff32 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -65,8 +65,6 @@ drm_atomic_state_init(struct drm_device *dev, struct 
> drm_atomic_state *state)
>*/
>   state->allow_modeset = true;
>  
> - state->num_connector = ACCESS_ONCE(dev->mode_config.num_connector);
> -
>   state->crtcs = kcalloc(dev->mode_config.num_crtc,
>  sizeof(*state->crtcs), GFP_KERNEL);
>   if (!state->crtcs)
> @@ -83,16 +81,6 @@ drm_atomic_state_init(struct drm_device *dev, struct 
> drm_atomic_state *state)
> sizeof(*state->plane_states), GFP_KERNEL);
>   if (!state->plane_states)
>   goto fail;
> - state->connectors = kcalloc(state->num_connector,
> - sizeof(*state->connectors),
> - GFP_KERNEL);
> - if (!state->connectors)
> - goto fail;
> - state->connector_states = kcalloc(state->num_connector,
> -   sizeof(*state->connector_states),
> -   GFP_KERNEL);
> - if (!state->connector_states)
> - goto fail;
>  
>   state->dev = dev;
>  
> @@ -823,19 +811,27 @@ drm_atomic_get_connector_state(struct drm_atomic_state 
> *state,
>  
>   index = drm_connector_index(connector);
>  
> - /*
> -  * Construction of atomic state updates can race with a connector
> -  * hot-add which might overflow. In this case flip the table and just
> -  * restart the entire ioctl - no one is fast enough to livelock a cpu
> -  * with physical hotplug events anyway.
> -  *
> -  * Note that we only grab the indexes once we have the right lock to
> -  * prevent hotplug/unplugging of connectors. So removal is no problem,
> -  * at most the array is a bit too large.
> -  */
>   if (index >= state->num_connector) {
> - DRM_DEBUG_ATOMIC("Hot-added connector would overflow state 
> array, restarting\n");
> - return ERR_PTR(-EAGAIN);
> + struct drm_connector **c;
> + struct drm_connector_state **cs;
> + int alloc = max(index + 1, config->num_connector);
> +
> + c = krealloc(state->connectors, alloc * 
> sizeof(*state->connectors), GFP_KERNEL);
> + if (!c)
> + return ERR_PTR(-ENOMEM);
> +
> + state->connectors = c;
> + memset(>connectors[state->num_connector], 0,
> +sizeof(*state->connectors) * (alloc - 
> state->num_connector));
> +
> + cs = krealloc(state->connector_states, alloc * 
> sizeof(*state->connector_states), GFP_KERNEL);
> + if (!cs)
> + return ERR_PTR(-ENOMEM);
> +
> + state->connector_states = cs;
> + memset(>connector_states[state->num_connector], 0,
> +sizeof(*state->connector_states) * (alloc - 
> state->num_connector));
> + state->num_connector = alloc;
>   }
>  
>   if (state->connector_states[index])
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 2b430b05f35d..4da4f2a49078 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1535,7 +1535,7 @@ void drm_atomic_helper_swap_state(struct drm_device 
> *dev,
>  {
>   int i;
>  
> - for (i = 0; i < dev->mode_config.num_connector; i++) {
> + for (i = 0; i < state->num_connector; i++) {
> 

Re: [Intel-gfx] [PATCH] drm/i915: Wait for vblank in i9xx_disable_crtc() for gen 2 only

[Daniel Vetter]

On Tue, Feb 16, 2016 at 07:53:45PM +0200, Ander Conselvan de Oliveira wrote:
> The wait for other gens was added in commit 564ed191f5d8 ("drm/i915:
> gmch: fix stuck primary plane due to memory self-refresh mode") since
> that's necessary when disabling cxsr. However, cxsr disabling was later
> moved to intel_pre_disable_primary() in commit 87d4300a7dbc ("drm/i915:
> Move intel_(pre_disable/post_enable)_primary to intel_display.c, and use
> it there.") and that function got its own vblank wait for cxsr in commit
> 262cd2e154c2 ("drm/i915: CHV DDR DVFS support and another watermark
> rewrite"). So remove the extra vblank wait from i9xx_crtc_distable().
> 
> Cc: Kalyan Kondapally 
> Signed-off-by: Ander Conselvan de Oliveira 
> 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 568eefc..3cb9383 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6317,10 +6317,9 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
>   /*
>* On gen2 planes are double buffered but the pipe isn't, so we must
>* wait for planes to fully turn off before disabling the pipe.
> -  * We also need to wait on all gmch platforms because of the
> -  * self-refresh mode constraint explained above.
>*/
> - intel_wait_for_vblank(dev, pipe);
> + if (IS_GEN2(dev))
> + intel_wait_for_vblank(dev, pipe);
>  
>   for_each_encoder_on_crtc(dev, crtc, encoder)
>   encoder->disable(encoder);
> -- 
> 2.4.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH v4 1/8] drm/i915: Pass crtc state to modeset_get_crtc_power_domains.

[Zanoni, Paulo R]

Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
> Use our newly created encoder_mask to iterate over the encoders.

As someone who was not paying attention to the discussion of the
previous patches related to this, I think it would be really good if
your commit message could tell me why we should use the newly created
encoder_mask instead of the current patch. What's bad about the current
version? Please sell me your patch. If you think the answer is trivial,
remember that it's not trivial to many people, and that random people
may find this patch through git-bisect and have to judge its
importance. Also, an explanation really helps the reviewers :)

The patch looks correct, so if you improve the commit message:
Reviewed-by: Paulo Zanoni 

> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 33 +-
> ---
>  1 file changed, 21 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 30d4db0d776f..b479ba6238d7 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5301,31 +5301,37 @@ intel_display_port_aux_power_domain(struct
> intel_encoder *intel_encoder)
>   }
>  }
>  
> -static unsigned long get_crtc_power_domains(struct drm_crtc *crtc)
> +static unsigned long get_crtc_power_domains(struct drm_crtc *crtc,
> + struct intel_crtc_state
> *crtc_state)
>  {
>   struct drm_device *dev = crtc->dev;
> - struct intel_encoder *intel_encoder;
> + struct drm_encoder *encoder;
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>   enum pipe pipe = intel_crtc->pipe;
>   unsigned long mask;
> - enum transcoder transcoder = intel_crtc->config-
> >cpu_transcoder;
> + enum transcoder transcoder = crtc_state->cpu_transcoder;
>  
> - if (!crtc->state->active)
> + if (!crtc_state->base.active)
>   return 0;
>  
>   mask = BIT(POWER_DOMAIN_PIPE(pipe));
>   mask |= BIT(POWER_DOMAIN_TRANSCODER(transcoder));
> - if (intel_crtc->config->pch_pfit.enabled ||
> - intel_crtc->config->pch_pfit.force_thru)
> + if (crtc_state->pch_pfit.enabled ||
> + crtc_state->pch_pfit.force_thru)
>   mask |= BIT(POWER_DOMAIN_PIPE_PANEL_FITTER(pipe));
>  
> - for_each_encoder_on_crtc(dev, crtc, intel_encoder)
> + drm_for_each_encoder_mask(encoder, dev, crtc_state-
> >base.encoder_mask) {
> + struct intel_encoder *intel_encoder =
> to_intel_encoder(encoder);
> +
>   mask |=
> BIT(intel_display_port_power_domain(intel_encoder));
> + }
>  
>   return mask;
>  }
>  
> -static unsigned long modeset_get_crtc_power_domains(struct drm_crtc
> *crtc)
> +static unsigned long
> +modeset_get_crtc_power_domains(struct drm_crtc *crtc,
> +    struct intel_crtc_state *crtc_state)
>  {
>   struct drm_i915_private *dev_priv = crtc->dev->dev_private;
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> @@ -5333,7 +5339,8 @@ static unsigned long
> modeset_get_crtc_power_domains(struct drm_crtc *crtc)
>   unsigned long domains, new_domains, old_domains;
>  
>   old_domains = intel_crtc->enabled_power_domains;
> - intel_crtc->enabled_power_domains = new_domains =
> get_crtc_power_domains(crtc);
> + intel_crtc->enabled_power_domains = new_domains =
> + get_crtc_power_domains(crtc, crtc_state);
>  
>   domains = new_domains & ~old_domains;
>  
> @@ -5365,7 +5372,8 @@ static void
> modeset_update_crtc_power_domains(struct drm_atomic_state *state)
>   for_each_crtc_in_state(state, crtc, crtc_state, i) {
>   if (needs_modeset(crtc->state))
>   put_domains[to_intel_crtc(crtc)->pipe] =
> - modeset_get_crtc_power_domains(crtc)
> ;
> + modeset_get_crtc_power_domains(crtc,
> + to_intel_crtc_state(crtc-
> >state));
>   }
>  
>   if (dev_priv->display.modeset_commit_cdclk &&
> @@ -13486,7 +13494,8 @@ static int intel_atomic_commit(struct
> drm_device *dev,
>   }
>  
>   if (update_pipe) {
> - put_domains =
> modeset_get_crtc_power_domains(crtc);
> + put_domains =
> modeset_get_crtc_power_domains(crtc,
> +   to_intel_crtc_state(cr
> tc->state));
>  
>   /* make sure intel_modeset_check_state runs
> */
>   hw_check = true;
> @@ -15830,7 +15839,7 @@ intel_modeset_setup_hw_state(struct
> drm_device *dev)
>   for_each_intel_crtc(dev, crtc) {
>   unsigned long put_domains;
>  
> - put_domains = modeset_get_crtc_power_domains(
> >base);
> + put_domains = 

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Simplify code by keeping kmap of guc_client object

[Yu Dai]

On 02/17/2016 08:04 AM, Daniel Vetter wrote:

On Tue, Feb 16, 2016 at 08:47:07AM -0800, Yu Dai wrote:
>
>
> On 02/15/2016 07:23 AM, Dave Gordon wrote:
> >On 12/02/16 13:03, Tvrtko Ursulin wrote:
> >>
> >> On 11/02/16 23:09, yu@intel.com wrote:
> >>> From: Alex Dai 
> >>>
> >>> GuC client object is always pinned during its life cycle. We cache
> >>> the kmap of its first page, which includes guc_process_desc and
> >>> doorbell. By doing so, we can simplify the code where we read from
> >>> this page to get where GuC is progressing on work queue; and the
> >>> code where driver program doorbell to send work queue item to GuC.
> >
> >There's still one k(un)map_atomic() pair, in guc_add_workqueue_item().
> >Maybe we could get rid of that one too? So instead of kmapping only the
> >first page of the client, we could vmap() all three pages and so not
> >need to kmap_atomic() the WQ pages on the fly.
> >
> >There's a handy vmap_obj() function we might use, except it's currently
> >static ...
> >
> >
> Yes, there is a vmap_obj we can use but it is static. Actually two,
> vmap_batch() in i915_cmd_parser.c and vmap_obj() in intel_ringbuffer.c.
> Maybe it is a good idea to make it global, so GuC can use it too.

There should be a vmap function somewhere in the dma-buf code too iirc.


Yes, i915_gem_dmabuf_vmap. Let me try to make a common helper function can be 
shared.

Alex

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

Re: [Intel-gfx] [PATCH] drm/i915: Disable FDI RX before DDI_BUF_CTL

[Ville Syrjälä]

On Tue, Dec 08, 2015 at 04:47:55PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Bspec is confused w.r.t. the HSW/BDW FDI disable sequence. It lists
> FDI RX disable both as step 13 and step 18 in the sequence. But I dug
> up an old BUN mail from Art that moved the FDI RX disable to happen
> before DDI_BUF_CTL disable. That BUN did not renumber the steps and just
> added a note:
> "Workaround: Disable PCH FDI Receiver before disabling DDI_BUF_CTL."
> 
> The BUN described the symptoms of the fixed issue as:
> "PCH display underflow and a black screen on the analog CRT port that
> happened after a FDI re-train"
> 
> I suppose later someone tried to renumber the steps to match, but forgot
> to remove the FDI RX disable from its old position in the sequence.
> 
> They also forgot to update the note describing what should be done in
> case of an FDI training failure. Currently it says:
> "To retry FDI training, follow the Disable Sequence steps to Disable FDI,
> but skip the steps related to clocks and PLLs (16, 19, and 20), ..."
> 
> It should really say "17, 20, and 21" with the current sequence because
> those are the steps that deal with PLLs and whatnot, after step 13 became
> FDI RX disable. And had the step 18 FDI RX disable been removed, as I
> suspect it should have, the note should actually say "17, 19, and 20".
> 
> So, let's move the FDI RX disable to happen before DDI_BUF_CTL disable,
> as that would appear to be the correct order based on the BUN.

Ping. Art, I hear you're back now ;) Any thoughts on this change, and
the slight mess in Bspec?


> 
> Cc: Paulo Zanoni 
> Cc: Art Runyan 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 5d20c64d8566..a89a17b7bb76 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -687,6 +687,10 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
>   break;
>   }
>  
> + rx_ctl_val &= ~FDI_RX_ENABLE;
> + I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val);
> + POSTING_READ(FDI_RX_CTL(PIPE_A));
> +
>   temp = I915_READ(DDI_BUF_CTL(PORT_E));
>   temp &= ~DDI_BUF_CTL_ENABLE;
>   I915_WRITE(DDI_BUF_CTL(PORT_E), temp);
> @@ -701,10 +705,6 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
>  
>   intel_wait_ddi_buf_idle(dev_priv, PORT_E);
>  
> - rx_ctl_val &= ~FDI_RX_ENABLE;
> - I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val);
> - POSTING_READ(FDI_RX_CTL(PIPE_A));
> -
>   /* Reset FDI_RX_MISC pwrdn lanes */
>   temp = I915_READ(FDI_RX_MISC(PIPE_A));
>   temp &= ~(FDI_RX_PWRDN_LANE1_MASK | FDI_RX_PWRDN_LANE0_MASK);
> @@ -3094,12 +3094,18 @@ void intel_ddi_fdi_disable(struct drm_crtc *crtc)
>   struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
>   uint32_t val;
>  
> - intel_ddi_post_disable(intel_encoder);
> -
> + /*
> +  * Bspec lists this as both step 13 (before DDI_BUF_CTL disable)
> +  * and step 18 (after clearing PORT_CLK_SEL). Based on a BUN,
> +  * step 13 is the correct place for it. Step 18 is where it was
> +  * originally before the BUN.
> +  */
>   val = I915_READ(FDI_RX_CTL(PIPE_A));
>   val &= ~FDI_RX_ENABLE;
>   I915_WRITE(FDI_RX_CTL(PIPE_A), val);
>  
> + intel_ddi_post_disable(intel_encoder);
> +
>   val = I915_READ(FDI_RX_MISC(PIPE_A));
>   val &= ~(FDI_RX_PWRDN_LANE1_MASK | FDI_RX_PWRDN_LANE0_MASK);
>   val |= FDI_RX_PWRDN_LANE1_VAL(2) | FDI_RX_PWRDN_LANE0_VAL(2);
> -- 
> 2.4.10

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/11] drm/i915: Framework for capturing command stream based OA reports

[Robert Bragg]

Hi Sourab,

As Sergio Martinez has started experimenting with this in gputop and
reported seeing lots of ENOSPC errors being reported when reading I had a
look into this and saw a few issues with how we check that there's data
available to read in command stream mode, and a I think there's a
possibility of incorrectly sorting the samples sometimes...

On Tue, Feb 16, 2016 at 5:27 AM,  wrote:

> From: Sourab Gupta 
>
>
> -static bool i915_oa_can_read(struct i915_perf_stream *stream)
> +static bool append_oa_rcs_sample(struct i915_perf_stream *stream,
> +struct i915_perf_read_state *read_state,
> +struct i915_perf_cs_data_node *node)
> +{
> +   struct drm_i915_private *dev_priv = stream->dev_priv;
> +   struct oa_sample_data data = { 0 };
> +   const u8 *report = dev_priv->perf.command_stream_buf.addr +
> +   node->offset;
> +   u32 sample_flags = stream->sample_flags;
> +   u32 report_ts;
> +
> +   /*
> +* Forward the periodic OA samples which have the timestamp lower
> +* than timestamp of this sample, before forwarding this sample.
> +* This ensures samples read by user are order acc. to their
> timestamps
> +*/
> +   report_ts = *(u32 *)(report + 4);
> +   dev_priv->perf.oa.ops.read(stream, read_state, report_ts);
> +
> +   if (sample_flags & SAMPLE_OA_SOURCE_INFO)
> +   data.source = I915_PERF_OA_EVENT_SOURCE_RCS;
> +
> +   if (sample_flags & SAMPLE_CTX_ID)
> +   data.ctx_id = node->ctx_id;
> +
> +   if (sample_flags & SAMPLE_OA_REPORT)
> +   data.report = report;
> +
> +   append_oa_sample(stream, read_state, );
> +
> +   return true;
> +}
> +
> +static void oa_rcs_append_reports(struct i915_perf_stream *stream,
> + struct i915_perf_read_state *read_state)
> +{
> +   struct drm_i915_private *dev_priv = stream->dev_priv;
> +   struct i915_perf_cs_data_node *entry, *next;
> +
> +   list_for_each_entry_safe(entry, next,
> +_priv->perf.node_list, link) {
> +   if (!i915_gem_request_completed(entry->request, true))
> +   break;
> +
> +   if (!append_oa_rcs_sample(stream, read_state, entry))
> +   break;
> +
> +   spin_lock(_priv->perf.node_list_lock);
> +   list_del(>link);
> +   spin_unlock(_priv->perf.node_list_lock);
> +
> +   i915_gem_request_unreference__unlocked(entry->request);
> +   kfree(entry);
> +   }
> +
> +   /* Flush any remaining periodic reports */
> +   dev_priv->perf.oa.ops.read(stream, read_state, U32_MAX);
>

I don't think we can flush all remaining periodic reports here - at least
not if we have any in-flight MI_RPC commands - in case the next request to
complete might have reports with earlier timestamps than some of these
periodic reports.

Even if we have periodic reports available I think we need to throttle
forwarding them based on the command stream requests completing.

This is something that userspace should understand when it explicitly
decides to use command stream mode in conjunction with periodic sampling.


> +}
> +
> +static bool command_stream_buf_is_empty(struct i915_perf_stream *stream)
>  {
> struct drm_i915_private *dev_priv = stream->dev_priv;
>
> -   return !dev_priv->perf.oa.ops.oa_buffer_is_empty(dev_priv);
> +   if (stream->cs_mode)
> +   return list_empty(_priv->perf.node_list);
> +   else
> +   return true;
>  }
>

I think this list_empty() check needs a lock around it, as it's called from
stream_have_data__unlocked().

Currently only checking list_empty() can lead to some false positives that
may confuse the current i915_perf_read() (the false positives come from not
checking that at least one entry->request has also completed).

False positives here will affect the error reporting in
i915_perf_read_locked(). The first thing i915_perf_read_locked() does is
check for available data so it can return -EAGAIN for non-blocking file
descriptors or block, waiting for data, for blocking fds. Once we believe
there is data then if stream->read() returns zero then that's translated to
a -ENOSPC error because we 'know' there's data but weren't able to copy
anything to the user's buffer because it wasn't large enough to hold a
complete record.


>
> -static int i915_oa_wait_unlocked(struct i915_perf_stream *stream)
> +static bool stream_have_data__unlocked(struct i915_perf_stream *stream)
>  {
> struct drm_i915_private *dev_priv = stream->dev_priv;
>
> @@ -397,8 +739,29 @@ static int i915_oa_wait_unlocked(struct
> i915_perf_stream *stream)
>  * can't be destroyed until completion (such as a read()) that
> ensures
>  * the device + OA buffer 

[Intel-gfx] [PATCH] drm/i915/skl: Add missing SKL ID

[Michał Winiarski]

Used by production device:
Intel(R) Iris(TM) Graphics P555

Signed-off-by: Michał Winiarski 
---
 include/drm/i915_pciids.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 9094599..9266c2c 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -281,6 +281,7 @@
INTEL_VGA_DEVICE(0x1926, info), /* ULT GT3 */ \
INTEL_VGA_DEVICE(0x1927, info), /* ULT GT3 */ \
INTEL_VGA_DEVICE(0x192B, info), /* Halo GT3 */ \
+   INTEL_VGA_DEVICE(0x192D, info), /* SRV GT3 */ \
INTEL_VGA_DEVICE(0x192A, info)  /* SRV GT3 */
 
 #define INTEL_SKL_GT4_IDS(info) \
-- 
2.7.1

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

Re: [Intel-gfx] [PATCH] drm/i915: Wait for vblank in i9xx_disable_crtc() for gen 2 only

[Jani Nikula]

On Wed, 17 Feb 2016, Daniel Vetter  wrote:
> On Wed, Feb 17, 2016 at 11:25:49AM +0200, Jani Nikula wrote:
>> On Tue, 16 Feb 2016, Ander Conselvan de Oliveira 
>>  wrote:
>> > The wait for other gens was added in commit 564ed191f5d8 ("drm/i915:
>> > gmch: fix stuck primary plane due to memory self-refresh mode") since
>> > that's necessary when disabling cxsr. However, cxsr disabling was later
>> > moved to intel_pre_disable_primary() in commit 87d4300a7dbc ("drm/i915:
>> > Move intel_(pre_disable/post_enable)_primary to intel_display.c, and use
>> > it there.") and that function got its own vblank wait for cxsr in commit
>> > 262cd2e154c2 ("drm/i915: CHV DDR DVFS support and another watermark
>> > rewrite"). So remove the extra vblank wait from i9xx_crtc_distable().
>> >
>> > Cc: Kalyan Kondapally 
>> > Signed-off-by: Ander Conselvan de Oliveira 
>> > 
>> 
>> Cc: fixes or stable? Fixes which commit exactly of all those?
>
> Why do we want to put a fix to remove a harmless roughly 16ms delay to
> stable? Or do I miss something here?

I missed something here. Nevermind, sorry for the noise. :)

BR,
Jani.


> -Daniel
>
>> 
>> BR,
>> Jani.
>> 
>> 
>> > ---
>> >  drivers/gpu/drm/i915/intel_display.c | 5 ++---
>> >  1 file changed, 2 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> > b/drivers/gpu/drm/i915/intel_display.c
>> > index 568eefc..3cb9383 100644
>> > --- a/drivers/gpu/drm/i915/intel_display.c
>> > +++ b/drivers/gpu/drm/i915/intel_display.c
>> > @@ -6317,10 +6317,9 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
>> >/*
>> > * On gen2 planes are double buffered but the pipe isn't, so we must
>> > * wait for planes to fully turn off before disabling the pipe.
>> > -   * We also need to wait on all gmch platforms because of the
>> > -   * self-refresh mode constraint explained above.
>> > */
>> > -  intel_wait_for_vblank(dev, pipe);
>> > +  if (IS_GEN2(dev))
>> > +  intel_wait_for_vblank(dev, pipe);
>> >  
>> >for_each_encoder_on_crtc(dev, crtc, encoder)
>> >encoder->disable(encoder);
>> 
>> -- 
>> Jani Nikula, Intel Open Source Technology Center
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t v3] lib/igt_core.c: Expand --run-subtest functionality.

[Daniel Vetter]

On Thu, Feb 04, 2016 at 12:06:57PM +, Derek Morton wrote:
> Added extended wildcard support when specifying --run-subtest.
> 
> Wildcard format is as specified in rfc3977 and the uwildmat() implementation
> is taken from libinn.
> See https://tools.ietf.org/html/rfc3977#section-4 for a description of
> allowed wildcard expressions.
> 
> v2: Use comma as list separator (Ville Syrjala)
> support both ^ and ! as not operators (Dave Gordon)
> 
> v3: Updated to use uwildmat() (Dave Gordon)
> 
> Signed-off-by: Derek Morton 

So really not happy that we perpetuate the interface differences in how
igt is run between android and linux. But oh well, maybe this helps in
getting the android team more on board with upstream igt tests than also
reinventing those wheels.

Applied, thanks for the patch.
-Daniel

> ---
>  COPYING |  21 +++
>  lib/Makefile.sources|   2 +
>  lib/igt_core.c  |  17 +-
>  lib/uwildmat/uwildmat.c | 474 
> 
>  lib/uwildmat/uwildmat.h |  24 +++
>  5 files changed, 536 insertions(+), 2 deletions(-)
>  create mode 100644 lib/uwildmat/uwildmat.c
>  create mode 100644 lib/uwildmat/uwildmat.h
> 
> diff --git a/COPYING b/COPYING
> index b8f6753..16375f2 100644
> --- a/COPYING
> +++ b/COPYING
> @@ -106,3 +106,24 @@ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY 
> CLAIM, DAMAGES OR OTHER
>  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>  FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
>  IN THE SOFTWARE.
> +
> +Copyright (c) 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012,
> +2013, 2014 by Internet Systems Consortium, Inc. ("ISC")
> +Copyright (c) 1991, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001,
> +2002, 2003 by The Internet Software Consortium and Rich Salz
> +
> +This code is derived from software contributed to the Internet Software
> +Consortium by Rich Salz.
> +
> +Permission to use, copy, modify, and distribute this software for any
> +purpose with or without fee is hereby granted, provided that the above
> +copyright notice and this permission notice appear in all copies.
> +
> +THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
> +REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> +MERCHANTABILITY AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY
> +SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> +ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> +OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> +
> diff --git a/lib/Makefile.sources b/lib/Makefile.sources
> index 4999868..e33861e 100644
> --- a/lib/Makefile.sources
> +++ b/lib/Makefile.sources
> @@ -60,6 +60,8 @@ libintel_tools_la_SOURCES = \
>   igt_core.h  \
>   igt_draw.c  \
>   igt_draw.h  \
> + uwildmat/uwildmat.h \
> + uwildmat/uwildmat.c \
>   $(NULL)
>  
>  .PHONY: version.h.tmp
> diff --git a/lib/igt_core.c b/lib/igt_core.c
> index 6b69bb7..8e0bd2e 100644
> --- a/lib/igt_core.c
> +++ b/lib/igt_core.c
> @@ -56,7 +56,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  #include "drmtest.h"
>  #include "intel_chipset.h"
> @@ -209,6 +209,19 @@
>   * intel gpu to be present). Then individual subtests can be run with
>   * "--run-subtest". Usage help for tests with subtests can be obtained with 
> the
>   * "--help" command line option.
> + *
> + * A wildcard expression can be given to --run-subtest to specify a subset of
> + * subtests to run. See https://tools.ietf.org/html/rfc3977#section-4 for a
> + * description of allowed wildcard expressions.
> + * Some examples of allowed wildcard expressions are:
> + *
> + * - '*basic*' match any subtest containing basic
> + * - 'basic-???' match any subtest named basic- with 3 characters after -
> + * - 'basic-[0-9]' match any subtest named basic- with a single number after 
> -
> + * - 'basic-[^0-9]' match any subtest named basic- with a single non 
> numerical character after -
> + * - 'basic*,advanced*' match any subtest starting basic or advanced
> + * - '*,!basic*' match any subtest not starting basic
> + * - 'basic*,!basic-render*' match any subtest starting basic but not 
> starting basic-render
>   */
>  
>  static unsigned int exit_handler_count;
> @@ -814,7 +827,7 @@ bool __igt_run_subtest(const char *subtest_name)
>   }
>  
>   if (run_single_subtest) {
> - if (fnmatch(run_single_subtest, subtest_name, 0) != 0)
> + if (uwildmat(subtest_name, run_single_subtest) == 0)
>   return false;
>   else
>   run_single_subtest_found = true;
> diff --git a/lib/uwildmat/uwildmat.c b/lib/uwildmat/uwildmat.c
> new file mode 100644
> index 000..2d34742
> --- /dev/null
> +++ 

Re: [Intel-gfx] [PATCH V7] drm/i915/skl: SKL CDCLK change on modeset tracking VCO

[Ville Syrjälä]

On Tue, Feb 16, 2016 at 09:44:55AM -0800, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor 
> 
> Set cdclk based on the max required pixel clock based on VCO
> selected. Track boot vco instead of boot cdclk.
> 
> The vco is now tracked at the atomic level and all CRTCs updated if
> the required vco is changed. Not tested with eDP v1.4 panels that
> require 8640 vco due to availability.
> 
> V1: initial version
> V2: add vco tracking in intel_dp_compute_config(), rename
> skl_boot_cdclk.
> V3: rebase, V2 feedback not possible as encoders are not aware of
> atomic.
> V4: track target vco is atomic state. modeset all CRTCs if vco changes
> V5: rename atomic variable, cleaner if/else logic, use existing vco if
> encoder does not return a new vco value. check_patch.pl cleanup
> V6: simplify logic in intel_modeset_checks.
> V7: reorder an IF for readability and whitespace fix.
> 
> Signed-off-by: Clint Taylor 
> Cc: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= 

Looks pretty good to me.
Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/i915_drv.h  |2 +-
>  drivers/gpu/drm/i915/intel_ddi.c |2 +-
>  drivers/gpu/drm/i915/intel_display.c |  102 
> +-
>  drivers/gpu/drm/i915/intel_dp.c  |6 +-
>  drivers/gpu/drm/i915/intel_drv.h |4 ++
>  5 files changed, 99 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 8216665..f65dd1a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1822,7 +1822,7 @@ struct drm_i915_private {
>   int num_fence_regs; /* 8 on pre-965, 16 otherwise */
>  
>   unsigned int fsb_freq, mem_freq, is_ddr3;
> - unsigned int skl_boot_cdclk;
> + unsigned int skl_vco_freq;
>   unsigned int cdclk_freq, max_cdclk_freq, atomic_cdclk_freq;
>   unsigned int max_dotclk_freq;
>   unsigned int hpll_freq;
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 6d5b09f..285adab 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2958,7 +2958,7 @@ void intel_ddi_pll_init(struct drm_device *dev)
>   int cdclk_freq;
>  
>   cdclk_freq = dev_priv->display.get_display_clock_speed(dev);
> - dev_priv->skl_boot_cdclk = cdclk_freq;
> + dev_priv->skl_vco_freq = skl_cdclk_get_vco(cdclk_freq);
>   if (skl_sanitize_cdclk(dev_priv))
>   DRM_DEBUG_KMS("Sanitized cdclk programmed by pre-os\n");
>   if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE))
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 9e2273b..e118ce0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5663,7 +5663,7 @@ static unsigned int skl_cdclk_decimal(unsigned int freq)
>   return (freq - 1000) / 500;
>  }
>  
> -static unsigned int skl_cdclk_get_vco(unsigned int freq)
> +unsigned int skl_cdclk_get_vco(unsigned int freq)
>  {
>   unsigned int i;
>  
> @@ -5821,17 +5821,21 @@ void skl_uninit_cdclk(struct drm_i915_private 
> *dev_priv)
>  
>  void skl_init_cdclk(struct drm_i915_private *dev_priv)
>  {
> - unsigned int required_vco;
> + unsigned int cdclk;
>  
>   /* DPLL0 not enabled (happens on early BIOS versions) */
>   if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE)) {
>   /* enable DPLL0 */
> - required_vco = skl_cdclk_get_vco(dev_priv->skl_boot_cdclk);
> - skl_dpll0_enable(dev_priv, required_vco);
> + if (dev_priv->skl_vco_freq != 8640)
> + dev_priv->skl_vco_freq = 8100;
> + skl_dpll0_enable(dev_priv, dev_priv->skl_vco_freq);
> + cdclk = ((dev_priv->skl_vco_freq == 8100) ? 337500 : 308570);
> + } else {
> + cdclk = dev_priv->cdclk_freq;
>   }
>  
> - /* set CDCLK to the frequency the BIOS chose */
> - skl_set_cdclk(dev_priv, dev_priv->skl_boot_cdclk);
> + /* set CDCLK to the lowest frequency, Modeset follows */
> + skl_set_cdclk(dev_priv, cdclk);
>  
>   /* enable DBUF power */
>   I915_WRITE(DBUF_CTL, I915_READ(DBUF_CTL) | DBUF_POWER_REQUEST);
> @@ -5847,7 +5851,7 @@ int skl_sanitize_cdclk(struct drm_i915_private 
> *dev_priv)
>  {
>   uint32_t lcpll1 = I915_READ(LCPLL1_CTL);
>   uint32_t cdctl = I915_READ(CDCLK_CTL);
> - int freq = dev_priv->skl_boot_cdclk;
> + int freq = dev_priv->cdclk_freq;
>  
>   /*
>* check if the pre-os intialized the display
> @@ -5871,11 +5875,7 @@ int skl_sanitize_cdclk(struct drm_i915_private 
> *dev_priv)
>   /* All well; nothing to sanitize */
>   return false;
>  sanitize:
> - /*
> -  * As of now initialize with 

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/skl: Ensure HW is powered during DDB HW state readout

[Imre Deak]

On ke, 2016-02-17 at 15:47 +, Patchwork wrote:
> == Summary ==
> 
> Series 3532v1 drm/i915/skl: Ensure HW is powered during DDB HW state
> readout
> http://patchwork.freedesktop.org/api/1.0/series/3532/revisions/1/mbox
> /
> 
> Test drv_hangman:
> Subgroup error-state-basic:
> incomplete -> PASS   (snb-dellxps)
> Test kms_flip:
> Subgroup basic-flip-vs-dpms:
> dmesg-warn -> PASS   (ilk-hp8440p) UNSTABLE
> Subgroup basic-flip-vs-modeset:
> pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE

Clearly unrelated, since the patch is SKL specific.

> Test kms_force_connector_basic:
> Subgroup force-load-detect:
> skip   -> FAIL   (ilk-hp8440p)

The same as above.

> Test pm_rpm:
> Subgroup basic-rte:
> pass   -> DMESG-WARN (bsw-nuc-2)

Ditto.

> 
> bdw-
> nuci7total:162  pass:152  dwarn:0   dfail:0   fail:0   skip:1
> 0 
> bdw-
> ultratotal:165  pass:152  dwarn:0   dfail:0   fail:0   skip:1
> 3 
> bsw-nuc-
> 2total:165  pass:134  dwarn:1   dfail:0   fail:1   skip:29 
> byt-
> nuc  total:165  pass:141  dwarn:0   dfail:0   fail:0   skip:2
> 4 
> hsw-
> gt2  total:165  pass:154  dwarn:0   dfail:0   fail:1   skip:1
> 0 
> ilk-
> hp8440p  total:165  pass:115  dwarn:1   dfail:0   fail:1   skip:4
> 8 
> ivb-
> t430stotal:165  pass:150  dwarn:0   dfail:0   fail:1   skip:1
> 4 
> skl-i5k-
> 2total:165  pass:149  dwarn:1   dfail:0   fail:0   skip:15 
> snb-
> dellxps  total:165  pass:142  dwarn:0   dfail:0   fail:1   skip:2
> 2 
> snb-
> x220ttotal:165  pass:142  dwarn:0   dfail:0   fail:2   skip:2
> 1 
> 
> Results at /archive/results/CI_IGT_test/Patchwork_1426/
> 
> a868b844abfbce5f574665319f51d397416ae49b drm-intel-nightly: 2016y-
> 02m-17d-14h-18m-14s UTC integration manifest
> c13931c633bfe7f522ffdd1c3b63378847863d49 drm/i915/skl: Ensure HW is
> powered during DDB HW state readout
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/skl: Ensure HW is powered during DDB HW state readout

[Imre Deak]

On ke, 2016-02-17 at 16:55 +0200, Jani Nikula wrote:
> On Wed, 17 Feb 2016, Imre Deak  wrote:
> > The assumption when adding the intel_display_power_is_enabled()
> > checks
> > was that if it returns success the power can't be turned off
> > afterwards
> > during the HW access, which is guaranteed by modeset locks. This
> > isn't
> > always true, so make sure we hold a dedicated reference for the
> > time of
> > the access.
> > 
> > Spotted-by: Mika Kuoppala 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93441
> > CC: Chris Wilson 
> > Signed-off-by: Imre Deak 
> 
> Cc: fixes or stable? Fixes which commit?

Hm, yes forgot about this. We need it in -fixes since it may fix DMC
functionality according to Mika. Imo no need for it in stable, since on
other platforms it wouldn't fix anything besides HW state checking.

I pushed the "drm/i915: add missing display power refs" patchset and
this patch rebased on -fixes to
https://github.com/ideak/linux/commits/display_power_get_if_enabled-for-fixes

--Imre

> BR,
> Jani.
> 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index b63cdb2..347d4df 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -2851,7 +2851,10 @@ void skl_ddb_get_hw_state(struct
> > drm_i915_private *dev_priv,
> >     memset(ddb, 0, sizeof(*ddb));
> >  
> >     for_each_pipe(dev_priv, pipe) {
> > -   if (!intel_display_power_is_enabled(dev_priv,
> > POWER_DOMAIN_PIPE(pipe)))
> > +   enum intel_display_power_domain power_domain;
> > +
> > +   power_domain = POWER_DOMAIN_PIPE(pipe);
> > +   if (!intel_display_power_get_if_enabled(dev_priv,
> > power_domain))
> >     continue;
> >  
> >     for_each_plane(dev_priv, pipe, plane) {
> > @@ -2863,6 +2866,8 @@ void skl_ddb_get_hw_state(struct
> > drm_i915_private *dev_priv,
> >     val = I915_READ(CUR_BUF_CFG(pipe));
> >     skl_ddb_entry_init_from_hw(
> > >plane[pipe][PLANE_CURSOR],
> >        val);
> > +
> > +   intel_display_power_put(dev_priv, power_domain);
> >     }
> >  }
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] [RFC] kernel/cpu: Use lockref for online CPU reference counting

[Peter Zijlstra]

On Wed, Feb 17, 2016 at 05:33:51PM +0100, Daniel Vetter wrote:
> On Wed, Feb 17, 2016 at 05:14:57PM +0100, Peter Zijlstra wrote:
> > On Wed, Feb 17, 2016 at 05:13:21PM +0100, Daniel Vetter wrote:
> > > And for context we're hitting this on CI in a bunch of our machines, which
> > 
> > What's CI ?
> 
> Continuous integration, aka our own farm of machines dedicated to running
> i915.ko testcases. Kinda like 0day (it does pre-merge testing on the m-l
> and also post-merge on our own little integration tree), but for just the
> graphics team and our needs.

So what patch triggered this new issue? Did cpufreq change or what?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] [RFC] kernel/cpu: Use lockref for online CPU reference counting

[Daniel Vetter]

On Wed, Feb 17, 2016 at 05:14:57PM +0100, Peter Zijlstra wrote:
> On Wed, Feb 17, 2016 at 05:13:21PM +0100, Daniel Vetter wrote:
> > And for context we're hitting this on CI in a bunch of our machines, which
> 
> What's CI ?

Continuous integration, aka our own farm of machines dedicated to running
i915.ko testcases. Kinda like 0day (it does pre-merge testing on the m-l
and also post-merge on our own little integration tree), but for just the
graphics team and our needs.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/fbc: enable FBC by default on HSW and BDW

[Daniel Vetter]

On Tue, Feb 16, 2016 at 06:47:21PM -0200, Paulo Zanoni wrote:
> These platforms should be fine now.
> 
> FBC can allow very significant power savings for screen-on idle
> systems, but it is worth mentioning that a lot of people won't get
> significant power savings by enabling this feature because they may
> have something else preventing the system from getting into the
> deepest sleep states. Examples may include a hungry wifi device or a
> max_performance SATA link power management policy. You can check your
> PC state residencies on the powertop "Idle stats" tab. I recommend
> trying to run "sudo powertop --auto-tune" and then seeing if the
> residencies improve.
> 
> Oh, and in case you - the person reading this commit message - found
> this commit through git bisect, please do the following:
>  - Check your dmesg and see if there are error messages mentioning
>underruns around the time your problem started happening.
>  - Download intel-gpu-tools, compile it, and run:
>$ sudo ./tests/kms_frontbuffer_tracking --run-subtest '*fbc-*' 2>&1 | tee 
> fbc.txt
>Then send us the fbc.txt file, especially if you get a failure.
>This will really maximize your chances of getting the bug fixed
>quickly.
>  - Try to find a reliable way to reproduce the problem, and tell us.
>  - Boot with drm.debug=0xe, reproduce the problem, then send us the
>dmesg file.
> 
> v2: Don't enable by default on SKL.
> 
> Signed-off-by: Paulo Zanoni 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/intel_fbc.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> b/drivers/gpu/drm/i915/intel_fbc.c
> index 3614a95..0f0492f 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -823,13 +823,15 @@ static bool intel_fbc_can_choose(struct intel_crtc 
> *crtc)
>  {
>   struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
>   struct intel_fbc *fbc = _priv->fbc;
> + bool enable_by_default = IS_HASWELL(dev_priv) ||
> +  IS_BROADWELL(dev_priv);
>  
>   if (intel_vgpu_active(dev_priv->dev)) {
>   fbc->no_fbc_reason = "VGPU is active";
>   return false;
>   }
>  
> - if (i915.enable_fbc < 0) {
> + if (i915.enable_fbc < 0 && !enable_by_default) {
>   fbc->no_fbc_reason = "disabled per chip default";
>   return false;
>   }
> -- 
> 2.7.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] drm/i915: Wait for vblank in i9xx_disable_crtc() for gen 2 only

[Daniel Vetter]

On Wed, Feb 17, 2016 at 11:25:49AM +0200, Jani Nikula wrote:
> On Tue, 16 Feb 2016, Ander Conselvan de Oliveira 
>  wrote:
> > The wait for other gens was added in commit 564ed191f5d8 ("drm/i915:
> > gmch: fix stuck primary plane due to memory self-refresh mode") since
> > that's necessary when disabling cxsr. However, cxsr disabling was later
> > moved to intel_pre_disable_primary() in commit 87d4300a7dbc ("drm/i915:
> > Move intel_(pre_disable/post_enable)_primary to intel_display.c, and use
> > it there.") and that function got its own vblank wait for cxsr in commit
> > 262cd2e154c2 ("drm/i915: CHV DDR DVFS support and another watermark
> > rewrite"). So remove the extra vblank wait from i9xx_crtc_distable().
> >
> > Cc: Kalyan Kondapally 
> > Signed-off-by: Ander Conselvan de Oliveira 
> > 
> 
> Cc: fixes or stable? Fixes which commit exactly of all those?

Why do we want to put a fix to remove a harmless roughly 16ms delay to
stable? Or do I miss something here?
-Daniel

> 
> BR,
> Jani.
> 
> 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 568eefc..3cb9383 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -6317,10 +6317,9 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
> > /*
> >  * On gen2 planes are double buffered but the pipe isn't, so we must
> >  * wait for planes to fully turn off before disabling the pipe.
> > -* We also need to wait on all gmch platforms because of the
> > -* self-refresh mode constraint explained above.
> >  */
> > -   intel_wait_for_vblank(dev, pipe);
> > +   if (IS_GEN2(dev))
> > +   intel_wait_for_vblank(dev, pipe);
> >  
> > for_each_encoder_on_crtc(dev, crtc, encoder)
> > encoder->disable(encoder);
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] Possible 4.5 i915 Skylake regression

[Daniel Vetter]

On Tue, Feb 16, 2016 at 09:26:35AM -0800, Andy Lutomirski wrote:
> On Tue, Feb 16, 2016 at 9:12 AM, Andy Lutomirski  wrote:
> > On Tue, Feb 16, 2016 at 8:12 AM, Daniel Vetter  wrote:
> >> On Mon, Feb 15, 2016 at 06:58:33AM -0800, Andy Lutomirski wrote:
> >>> On Sun, Feb 14, 2016 at 6:59 PM, Andy Lutomirski  wrote:
> >>> > Hi-
> >>> >
> >>> > On 4.5-rc3 on a Dell XPS 13 9350 (Skylake i915, no nvidia on this
> >>> > model), shortly after resume, I saw a single black flash on the
> >>> > screen.  The log said:
> >>> >
> >>> > [Feb13 07:05] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR*
> >>> > CPU pipe A FIFO underrun
> >>> >
> >>> > I haven't seen this on 4.4.
> >>> >
> >>> > I'd be happy to dig up debugging info, but I don't know what would be
> >>> > useful.  I have no i915 module options set.
> >>>
> >>> It's flashing quite frequently now, although I seem to get the
> >>> underrun warning only once per resume.
> >>
> >> We shut up the warning irq source to avoid hijacking an entire cpu core
> >> ;-)
> >>
> >> There's a fix from Matt right after 4.5-rc4 in Linus' branch. I'm hoping
> >> that should help.
> >
> > Do you mean:
> >
> > commit e2e407dc093f530b771ee8bf8fe1be41e3cea8b3
> > Author: Matt Roper 
> > Date:   Mon Feb 8 11:05:28 2016 -0800
> >
> > drm/i915: Pretend cursor is always on for ILK-style WM calculations (v2)
> >
> > If so, it didn't help.  I'm currently doing a full rebuild just in
> > case I messed something up, though.
> >
> 
> Definitely not fixed.  It seems to be okay after a reboot until the
> first suspend/resume.
> 
> This happened after resuming.  Five cents says it's the root cause.

That's interesting, but doesn't ring a bell unfortunately. Can you try to
attempt a bisect?

Thanks, Daniel

> 
> [  160.361200] WARNING: CPU: 2 PID: 2512 at
> drivers/gpu/drm/i915/intel_uncore.c:599
> hsw_unclaimed_reg_debug+0x69/0x90 [i915]()
> [  160.361209] Unclaimed register detected before writing to register 0x20a8
> [  160.361213] Modules linked in: rfcomm fuse ccm cmac xt_CHECKSUM
> ipt_MASQUERADE nf_nat_masquerade_ipv4 tun nf_conntrack_netbios_ns
> nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT nf_reject_ipv6
> xt_conntrack ebtable_filter ebtable_nat ebtable_broute bridge stp llc
> ebtables ip6table_raw ip6table_mangle ip6table_security ip6table_nat
> nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_filter
> ip6_tables iptable_raw iptable_mangle iptable_security iptable_nat
> nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack bnep
> arc4 iwlmvm mac80211 snd_hda_codec_hdmi snd_hda_codec_realtek
> hid_multitouch snd_hda_codec_generic iwlwifi snd_hda_intel intel_rapl
> snd_hda_codec x86_pkg_temp_thermal coretemp kvm_intel snd_hwdep
> cfg80211 snd_hda_core kvm snd_seq uvcvideo snd_seq_device
> i2c_designware_platform
> [  160.361385]  i2c_designware_core btusb snd_pcm videobuf2_vmalloc
> wmi_mof vfat dell_wmi fat videobuf2_memops btrtl btbcm btintel
> bluetooth dell_laptop dell_smbios dcdbas videobuf2_v4l2 snd_timer
> videobuf2_core rtsx_pci_ms snd irqbypass videodev memstick
> ghash_clmulni_intel joydev mei_me efi_pstore mei i2c_i801 soundcore
> efivars pcspkr idma64 shpchp virt_dma media rfkill intel_lpss_pci
> processor_thermal_device intel_soc_dts_iosf wmi acpi_als kfifo_buf
> int3403_thermal tpm_tis industrialio pinctrl_sunrisepoint tpm
> intel_hid int3400_thermal pinctrl_intel intel_lpss_acpi sparse_keymap
> int340x_thermal_zone acpi_thermal_rel intel_lpss nfsd acpi_pad
> auth_rpcgss nfs_acl lockd binfmt_misc grace sunrpc dm_crypt i915
> i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt
> fb_sys_fops drm rtsx_pci_sdmmc
> [  160.361548]  mmc_core crct10dif_pclmul crc32_pclmul crc32c_intel
> rtsx_pci serio_raw i2c_hid video
> [  160.361575] CPU: 2 PID: 2512 Comm: gnome-shell Not tainted
> 4.5.0-rc4-acpi+ #59
> [  160.361581] Hardware name: Dell Inc. XPS 13 9350/07TYC2, BIOS 1.1.9
> 12/18/2015
> [  160.361588]  0086 604232f7 88024d55ba60
> 81449d83
> [  160.361601]  88024d55baa8 a01e15e8 88024d55ba98
> 81094252
> [  160.361612]  88026f4d 20a8 88026f4d
> fefe
> [  160.361624] Call Trace:
> [  160.361644]  [] dump_stack+0x65/0x92
> [  160.361660]  [] warn_slowpath_common+0x82/0xc0
> [  160.361671]  [] warn_slowpath_fmt+0x5c/0x80
> [  160.361764]  [] hsw_unclaimed_reg_debug+0x69/0x90 [i915]
> [  160.361844]  [] gen9_write32+0x6e/0x390 [i915]
> [  160.361855]  [] ? preempt_count_add+0x85/0xd0
> [  160.361939]  [] gen8_logical_ring_get_irq+0x95/0xe0 
> [i915]
> [  160.362017]  [] __i915_wait_request+0x58b/0x650 [i915]
> [  160.362028]  [] ? wake_atomic_t_function+0x70/0x70
> [  160.362113]  []
> i915_gem_object_wait_rendering__nonblocking+0x16e/0x2c0 [i915]
> [  160.362200]  [] ? i915_gem_pwrite_ioctl+0xe4/0x9b0 [i915]
> [  160.362211]  [] ? preempt_count_add+0x85/0xd0
> [  

Re: [Intel-gfx] [PATCH] [RFC] kernel/cpu: Use lockref for online CPU reference counting

[Peter Zijlstra]

On Wed, Feb 17, 2016 at 05:13:21PM +0100, Daniel Vetter wrote:
> And for context we're hitting this on CI in a bunch of our machines, which

What's CI ?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] [RFC] kernel/cpu: Use lockref for online CPU reference counting

[Daniel Vetter]

On Wed, Feb 17, 2016 at 03:20:05PM +0100, Peter Zijlstra wrote:
> On Wed, Feb 17, 2016 at 02:47:31PM +0200, Joonas Lahtinen wrote:
> > On ti, 2016-02-16 at 12:07 +0100, Peter Zijlstra wrote:
> > > On Tue, Feb 16, 2016 at 12:51:03PM +0200, Joonas Lahtinen wrote:
> > > > Quoting my original patch;
> > > > 
> > > > "See the Bugzilla link for more details.
> > > 
> > > If its not in the Changelog it doesn't exist. Patches should be self
> > > contained and not refer to external sources for critical information.
> > 
> > The exact locking case in CPUfreq drivers causing a splat is described
> > in the patch. Details were already included, that's why term "more
> > details" was used.
> 
> Barely. What was not described was why you went to tinker with the
> hotplug lock instead of sanitizing cpufreq. Nor why your chosen solution
> is good.
> 
> > This is not exactly taking us closer to a fix, 
> 
> Why you think we can discuss fixes if you've not actually described your
> problem is beyond me.

Can we please stop the petty-fights while figuring out how to work out a
solution here, thanks.

And for context we're hitting this on CI in a bunch of our machines, which
means no more lockdep checking for us. Which is, at least for me, pretty
serious, and why we're throwing complete cpu-anything newbies at that code
trying to come up with some solution to unblock our CI efforts for the
intel gfx driver. Unfortunately our attempts at just disabling lots of
Kconfig symbols proofed futile, so ideas to avoid all that code highly
welcome.

As soon as CI stops hitting this we'll jump out of your inbox, if you want
so.

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

Re: [Intel-gfx] [PATCH 08/12] drm/i915: ensure the HW is powered when accessing the CRC HW block

[Daniel Vetter]

On Wed, Feb 17, 2016 at 02:20:49PM +0200, Imre Deak wrote:
> On ti, 2016-02-16 at 17:02 +0100, Daniel Vetter wrote:
> > On Fri, Feb 12, 2016 at 06:55:17PM +0200, Imre Deak wrote:
> > > The assumption when adding the intel_display_power_is_enabled()
> > > checks
> > > was that if it returns success the power can't be turned off
> > > afterwards
> > > during the HW access, which is guaranteed by modeset locks. This
> > > isn't
> > > always true, so make sure we hold a dedicated reference for the
> > > time of
> > > the access.
> > > 
> > > Signed-off-by: Imre Deak 
> > 
> > subject needs to be fixed to mention that this is for all the stuff
> > in
> > i915_debugfs.c.
> 
> Ah, yea i915_interrupt_info() is also changed, will updated that in the
> log.

Ah right makes sense. I thought I counted more to convert in
intel_display.c than what was in your patches, plus the error capture
stuff. And not converting error capture is indeed what we need to do ...
-Daniel

> 
> > With that fixed for patches 4-8:
> > 
> > Reviewed-by: Daniel Vetter 
> > 
> > 
> > > ---
> > >  drivers/gpu/drm/i915/i915_debugfs.c | 28 +--
> > > -
> > >  1 file changed, 21 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > index ec0c2a05e..9e19cf0 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -825,8 +825,11 @@ static int i915_interrupt_info(struct seq_file
> > > *m, void *data)
> > >   }
> > >  
> > >   for_each_pipe(dev_priv, pipe) {
> > > - if
> > > (!intel_display_power_is_enabled(dev_priv,
> > > - POWER_DOMAIN_PIPE(
> > > pipe))) {
> > > + enum intel_display_power_domain
> > > power_domain;
> > > +
> > > + power_domain = POWER_DOMAIN_PIPE(pipe);
> > > + if
> > > (!intel_display_power_get_if_enabled(dev_priv,
> > > + po
> > > wer_domain)) {
> > >   seq_printf(m, "Pipe %c power
> > > disabled\n",
> > >      pipe_name(pipe));
> > >   continue;
> > > @@ -840,6 +843,8 @@ static int i915_interrupt_info(struct seq_file
> > > *m, void *data)
> > >   seq_printf(m, "Pipe %c IER:\t%08x\n",
> > >      pipe_name(pipe),
> > >      I915_READ(GEN8_DE_PIPE_IER(pipe
> > > )));
> > > +
> > > + intel_display_power_put(dev_priv,
> > > power_domain);
> > >   }
> > >  
> > >   seq_printf(m, "Display Engine port interrupt
> > > mask:\t%08x\n",
> > > @@ -4004,6 +4009,7 @@ static int pipe_crc_set_source(struct
> > > drm_device *dev, enum pipe pipe,
> > >   struct intel_pipe_crc *pipe_crc = _priv-
> > > >pipe_crc[pipe];
> > >   struct intel_crtc *crtc =
> > > to_intel_crtc(intel_get_crtc_for_pipe(dev,
> > >   
> > > pipe));
> > > + enum intel_display_power_domain power_domain;
> > >   u32 val = 0; /* shut up gcc */
> > >   int ret;
> > >  
> > > @@ -4014,7 +4020,8 @@ static int pipe_crc_set_source(struct
> > > drm_device *dev, enum pipe pipe,
> > >   if (pipe_crc->source && source)
> > >   return -EINVAL;
> > >  
> > > - if (!intel_display_power_is_enabled(dev_priv,
> > > POWER_DOMAIN_PIPE(pipe))) {
> > > + power_domain = POWER_DOMAIN_PIPE(pipe);
> > > + if (!intel_display_power_get_if_enabled(dev_priv,
> > > power_domain)) {
> > >   DRM_DEBUG_KMS("Trying to capture CRC while pipe is
> > > off\n");
> > >   return -EIO;
> > >   }
> > > @@ -4031,7 +4038,7 @@ static int pipe_crc_set_source(struct
> > > drm_device *dev, enum pipe pipe,
> > >   ret = ivb_pipe_crc_ctl_reg(dev, pipe, ,
> > > );
> > >  
> > >   if (ret != 0)
> > > - return ret;
> > > + goto out;
> > >  
> > >   /* none -> real source transition */
> > >   if (source) {
> > > @@ -4043,8 +4050,10 @@ static int pipe_crc_set_source(struct
> > > drm_device *dev, enum pipe pipe,
> > >   entries = kcalloc(INTEL_PIPE_CRC_ENTRIES_NR,
> > >     sizeof(pipe_crc->entries[0]),
> > >     GFP_KERNEL);
> > > - if (!entries)
> > > - return -ENOMEM;
> > > + if (!entries) {
> > > + ret = -ENOMEM;
> > > + goto out;
> > > + }
> > >  
> > >   /*
> > >    * When IPS gets enabled, the pipe CRC changes.
> > > Since IPS gets
> > > @@ -4100,7 +4109,12 @@ static int pipe_crc_set_source(struct
> > > drm_device *dev, enum pipe pipe,
> > >   hsw_enable_ips(crtc);
> > >   }
> > >  
> > > - return 0;
> > > + ret = 0;
> > > +
> > > +out:
> > > + intel_display_power_put(dev_priv, power_domain);
> > > +
> > > + 

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Simplify code by keeping kmap of guc_client object

[Daniel Vetter]

On Tue, Feb 16, 2016 at 08:47:07AM -0800, Yu Dai wrote:
> 
> 
> On 02/15/2016 07:23 AM, Dave Gordon wrote:
> >On 12/02/16 13:03, Tvrtko Ursulin wrote:
> >>
> >> On 11/02/16 23:09, yu@intel.com wrote:
> >>> From: Alex Dai 
> >>>
> >>> GuC client object is always pinned during its life cycle. We cache
> >>> the kmap of its first page, which includes guc_process_desc and
> >>> doorbell. By doing so, we can simplify the code where we read from
> >>> this page to get where GuC is progressing on work queue; and the
> >>> code where driver program doorbell to send work queue item to GuC.
> >
> >There's still one k(un)map_atomic() pair, in guc_add_workqueue_item().
> >Maybe we could get rid of that one too? So instead of kmapping only the
> >first page of the client, we could vmap() all three pages and so not
> >need to kmap_atomic() the WQ pages on the fly.
> >
> >There's a handy vmap_obj() function we might use, except it's currently
> >static ...
> >
> >
> Yes, there is a vmap_obj we can use but it is static. Actually two,
> vmap_batch() in i915_cmd_parser.c and vmap_obj() in intel_ringbuffer.c.
> Maybe it is a good idea to make it global, so GuC can use it too.

There should be a vmap function somewhere in the dma-buf code too iirc.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/skl: Ensure HW is powered during DDB HW state readout

[Patchwork]

== Summary ==

Series 3532v1 drm/i915/skl: Ensure HW is powered during DDB HW state readout
http://patchwork.freedesktop.org/api/1.0/series/3532/revisions/1/mbox/

Test drv_hangman:
Subgroup error-state-basic:
incomplete -> PASS   (snb-dellxps)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
dmesg-warn -> PASS   (ilk-hp8440p) UNSTABLE
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Test kms_force_connector_basic:
Subgroup force-load-detect:
skip   -> FAIL   (ilk-hp8440p)
Test pm_rpm:
Subgroup basic-rte:
pass   -> DMESG-WARN (bsw-nuc-2)

bdw-nuci7total:162  pass:152  dwarn:0   dfail:0   fail:0   skip:10 
bdw-ultratotal:165  pass:152  dwarn:0   dfail:0   fail:0   skip:13 
bsw-nuc-2total:165  pass:134  dwarn:1   dfail:0   fail:1   skip:29 
byt-nuc  total:165  pass:141  dwarn:0   dfail:0   fail:0   skip:24 
hsw-gt2  total:165  pass:154  dwarn:0   dfail:0   fail:1   skip:10 
ilk-hp8440p  total:165  pass:115  dwarn:1   dfail:0   fail:1   skip:48 
ivb-t430stotal:165  pass:150  dwarn:0   dfail:0   fail:1   skip:14 
skl-i5k-2total:165  pass:149  dwarn:1   dfail:0   fail:0   skip:15 
snb-dellxps  total:165  pass:142  dwarn:0   dfail:0   fail:1   skip:22 
snb-x220ttotal:165  pass:142  dwarn:0   dfail:0   fail:2   skip:21 

Results at /archive/results/CI_IGT_test/Patchwork_1426/

a868b844abfbce5f574665319f51d397416ae49b drm-intel-nightly: 
2016y-02m-17d-14h-18m-14s UTC integration manifest
c13931c633bfe7f522ffdd1c3b63378847863d49 drm/i915/skl: Ensure HW is powered 
during DDB HW state readout

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

Re: [Intel-gfx] [v2] drm/atomic: Allow for holes in connector state, v2.

[Lyude]

Works perfectly, fixes the issues with MST over here.

Reviewed-by: Lyude 

On Wed, 2016-02-17 at 08:32 +0100, Maarten Lankhorst wrote:
> Because we record connector_mask using 1 << drm_connector_index now
> the connector_mask should stay the same even when other connectors
> are removed. This was not the case with MST, in that case when removing
> a connector all other connectors may change their index.
> 
> This is fixed by waiting until the first get_connector_state to allocate
> connector_state, and force reallocation when state is too small.
> 
> As a side effect connector arrays no longer have to be preallocated,
> and can be allocated on first use which means a less allocations in
> the page flip only path.
> 
> Changes since v1:
> - Whitespace. (Ville)
> - Call ida_remove when destroying the connector. (Ville)
> - u32 alloc -> int. (Ville)
> 
> Fixes: 14de6c44d149 ("drm/atomic: Remove drm_atomic_connectors_for_crtc.")
> Signed-off-by: Maarten Lankhorst 
> Cc: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_atomic.c| 44 +++--
>  drivers/gpu/drm/drm_atomic_helper.c |  2 +-
>  drivers/gpu/drm/drm_crtc.c  | 49 +++-
> -
>  include/drm/drm_crtc.h  |  8 +-
>  4 files changed, 48 insertions(+), 55 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 8fb469c4e4b8..092620c6ff32 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -65,8 +65,6 @@ drm_atomic_state_init(struct drm_device *dev, struct
> drm_atomic_state *state)
>    */
>   state->allow_modeset = true;
>  
> - state->num_connector = ACCESS_ONCE(dev->mode_config.num_connector);
> -
>   state->crtcs = kcalloc(dev->mode_config.num_crtc,
>      sizeof(*state->crtcs), GFP_KERNEL);
>   if (!state->crtcs)
> @@ -83,16 +81,6 @@ drm_atomic_state_init(struct drm_device *dev, struct
> drm_atomic_state *state)
>     sizeof(*state->plane_states),
> GFP_KERNEL);
>   if (!state->plane_states)
>   goto fail;
> - state->connectors = kcalloc(state->num_connector,
> - sizeof(*state->connectors),
> - GFP_KERNEL);
> - if (!state->connectors)
> - goto fail;
> - state->connector_states = kcalloc(state->num_connector,
> -   sizeof(*state->connector_states),
> -   GFP_KERNEL);
> - if (!state->connector_states)
> - goto fail;
>  
>   state->dev = dev;
>  
> @@ -823,19 +811,27 @@ drm_atomic_get_connector_state(struct drm_atomic_state
> *state,
>  
>   index = drm_connector_index(connector);
>  
> - /*
> -  * Construction of atomic state updates can race with a connector
> -  * hot-add which might overflow. In this case flip the table and just
> -  * restart the entire ioctl - no one is fast enough to livelock a cpu
> -  * with physical hotplug events anyway.
> -  *
> -  * Note that we only grab the indexes once we have the right lock to
> -  * prevent hotplug/unplugging of connectors. So removal is no
> problem,
> -  * at most the array is a bit too large.
> -  */
>   if (index >= state->num_connector) {
> - DRM_DEBUG_ATOMIC("Hot-added connector would overflow state
> array, restarting\n");
> - return ERR_PTR(-EAGAIN);
> + struct drm_connector **c;
> + struct drm_connector_state **cs;
> + int alloc = max(index + 1, config->num_connector);
> +
> + c = krealloc(state->connectors, alloc * sizeof(*state-
> >connectors), GFP_KERNEL);
> + if (!c)
> + return ERR_PTR(-ENOMEM);
> +
> + state->connectors = c;
> + memset(>connectors[state->num_connector], 0,
> +    sizeof(*state->connectors) * (alloc - state-
> >num_connector));
> +
> + cs = krealloc(state->connector_states, alloc * sizeof(*state-
> >connector_states), GFP_KERNEL);
> + if (!cs)
> + return ERR_PTR(-ENOMEM);
> +
> + state->connector_states = cs;
> + memset(>connector_states[state->num_connector], 0,
> +    sizeof(*state->connector_states) * (alloc - state-
> >num_connector));
> + state->num_connector = alloc;
>   }
>  
>   if (state->connector_states[index])
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 2b430b05f35d..4da4f2a49078 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1535,7 +1535,7 @@ void drm_atomic_helper_swap_state(struct drm_device
> *dev,
>  {
>   int i;
>  
> - for (i = 0; i < 

Re: [Intel-gfx] [PATCH] drm/i915/skl: Ensure HW is powered during DDB HW state readout

[Mika Kuoppala]

Imre Deak  writes:

> The assumption when adding the intel_display_power_is_enabled() checks
> was that if it returns success the power can't be turned off afterwards
> during the HW access, which is guaranteed by modeset locks. This isn't
> always true, so make sure we hold a dedicated reference for the time of
> the access.
>
> Spotted-by: Mika Kuoppala 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93441
> CC: Chris Wilson 
> Signed-off-by: Imre Deak 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/intel_pm.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index b63cdb2..347d4df 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2851,7 +2851,10 @@ void skl_ddb_get_hw_state(struct drm_i915_private 
> *dev_priv,
>   memset(ddb, 0, sizeof(*ddb));
>  
>   for_each_pipe(dev_priv, pipe) {
> - if (!intel_display_power_is_enabled(dev_priv, 
> POWER_DOMAIN_PIPE(pipe)))
> + enum intel_display_power_domain power_domain;
> +
> + power_domain = POWER_DOMAIN_PIPE(pipe);
> + if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
>   continue;
>  
>   for_each_plane(dev_priv, pipe, plane) {
> @@ -2863,6 +2866,8 @@ void skl_ddb_get_hw_state(struct drm_i915_private 
> *dev_priv,
>   val = I915_READ(CUR_BUF_CFG(pipe));
>   skl_ddb_entry_init_from_hw(>plane[pipe][PLANE_CURSOR],
>  val);
> +
> + intel_display_power_put(dev_priv, power_domain);
>   }
>  }
>  
> -- 
> 2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: Initialize MIPI DSI for BXT

[Patchwork]

== Summary ==

Series 3522v1 drm/i915/bxt: Initialize MIPI DSI for BXT
http://patchwork.freedesktop.org/api/1.0/series/3522/revisions/1/mbox/

Test drv_hangman:
Subgroup error-state-basic:
incomplete -> PASS   (snb-dellxps)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
fail   -> PASS   (bsw-nuc-2)
Test kms_force_connector_basic:
Subgroup force-load-detect:
skip   -> FAIL   (ilk-hp8440p)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (skl-i5k-2)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (skl-i5k-2)
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (bsw-nuc-2)
Test pm_rpm:
Subgroup basic-rte:
pass   -> DMESG-WARN (bsw-nuc-2)

bdw-nuci7total:162  pass:152  dwarn:0   dfail:0   fail:0   skip:10 
bsw-nuc-2total:165  pass:134  dwarn:2   dfail:0   fail:0   skip:29 
byt-nuc  total:165  pass:141  dwarn:0   dfail:0   fail:0   skip:24 
hsw-gt2  total:165  pass:154  dwarn:0   dfail:0   fail:1   skip:10 
ilk-hp8440p  total:165  pass:115  dwarn:1   dfail:0   fail:1   skip:48 
ivb-t430stotal:165  pass:150  dwarn:0   dfail:0   fail:1   skip:14 
skl-i5k-2total:165  pass:149  dwarn:1   dfail:0   fail:0   skip:15 
snb-dellxps  total:165  pass:142  dwarn:0   dfail:0   fail:1   skip:22 

Results at /archive/results/CI_IGT_test/Patchwork_1425/

a868b844abfbce5f574665319f51d397416ae49b drm-intel-nightly: 
2016y-02m-17d-14h-18m-14s UTC integration manifest
f957ea329c37adb14791f4971fce6601c5d07dfd drm/i915/bxt: Initialize MIPI DSI for 
BXT

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

Re: [Intel-gfx] [PATCH] drm/i915/skl: Ensure HW is powered during DDB HW state readout

[Jani Nikula]

On Wed, 17 Feb 2016, Imre Deak  wrote:
> The assumption when adding the intel_display_power_is_enabled() checks
> was that if it returns success the power can't be turned off afterwards
> during the HW access, which is guaranteed by modeset locks. This isn't
> always true, so make sure we hold a dedicated reference for the time of
> the access.
>
> Spotted-by: Mika Kuoppala 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93441
> CC: Chris Wilson 
> Signed-off-by: Imre Deak 

Cc: fixes or stable? Fixes which commit?

BR,
Jani.

> ---
>  drivers/gpu/drm/i915/intel_pm.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index b63cdb2..347d4df 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2851,7 +2851,10 @@ void skl_ddb_get_hw_state(struct drm_i915_private 
> *dev_priv,
>   memset(ddb, 0, sizeof(*ddb));
>  
>   for_each_pipe(dev_priv, pipe) {
> - if (!intel_display_power_is_enabled(dev_priv, 
> POWER_DOMAIN_PIPE(pipe)))
> + enum intel_display_power_domain power_domain;
> +
> + power_domain = POWER_DOMAIN_PIPE(pipe);
> + if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
>   continue;
>  
>   for_each_plane(dev_priv, pipe, plane) {
> @@ -2863,6 +2866,8 @@ void skl_ddb_get_hw_state(struct drm_i915_private 
> *dev_priv,
>   val = I915_READ(CUR_BUF_CFG(pipe));
>   skl_ddb_entry_init_from_hw(>plane[pipe][PLANE_CURSOR],
>  val);
> +
> + intel_display_power_put(dev_priv, power_domain);
>   }
>  }

-- 
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/skl: Ensure HW is powered during DDB HW state readout

[Imre Deak]

The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.

Spotted-by: Mika Kuoppala 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93441
CC: Chris Wilson 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_pm.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b63cdb2..347d4df 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2851,7 +2851,10 @@ void skl_ddb_get_hw_state(struct drm_i915_private 
*dev_priv,
memset(ddb, 0, sizeof(*ddb));
 
for_each_pipe(dev_priv, pipe) {
-   if (!intel_display_power_is_enabled(dev_priv, 
POWER_DOMAIN_PIPE(pipe)))
+   enum intel_display_power_domain power_domain;
+
+   power_domain = POWER_DOMAIN_PIPE(pipe);
+   if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
continue;
 
for_each_plane(dev_priv, pipe, plane) {
@@ -2863,6 +2866,8 @@ void skl_ddb_get_hw_state(struct drm_i915_private 
*dev_priv,
val = I915_READ(CUR_BUF_CFG(pipe));
skl_ddb_entry_init_from_hw(>plane[pipe][PLANE_CURSOR],
   val);
+
+   intel_display_power_put(dev_priv, power_domain);
}
 }
 
-- 
2.5.0

___
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: add missing display power refs (rev3)

[Imre Deak]

On ke, 2016-02-17 at 12:44 +, Patchwork wrote:
> == Summary ==
> 
> Series 3372v3 drm/i915: add missing display power refs
> http://patchwork.freedesktop.org/api/1.0/series/3372/revisions/3/mbox
> /
> 
> Test pm_rpm:
> Subgroup basic-pci-d3-state:
> dmesg-warn -> PASS   (bsw-nuc-2)
> 
> bsw-nuc-
> 2total:165  pass:136  dwarn:0   dfail:0   fail:0   skip:29 
> 
> Results at /archive/results/CI_IGT_test/Patchwork_1423/

I pushed the patchset to -dinq, thanks for the review.

--Imre

> e99a344c64936ee4a67459f22e5a72bc4ae470bf drm-intel-nightly: 2016y-
> 02m-17d-11h-25m-24s UTC integration manifest
> 6bac804f8e89ac717f5344b2797775cb943ae920 drm/i915/lvds: ensure the HW
> is powered during HW state readout
> 9909cd7334eed8d7e889020313ddc2d22ff278ab drm/i915/hdmi: ensure the HW
> is powered during HW state readout
> 9aa76ff07c56503d61712402e0079d3fe56c79b9 drm/i915/dsi: ensure the HW
> is powered during HW state readout
> 08f821a5cbc83b3c1f70f575365d70c2d23bdce7 drm/i915/dp: ensure the HW
> is powered during HW state readout
> d04bf77e309852d193e74b646e685c1bf20a2732 drm/i915: ensure the HW is
> powered when accessing the CRC HW block
> 4c00c62f648389fad9b892fd5079c4fe948e1125 drm/i915/ddi: ensure the HW
> is powered during HW state readout
> efdfa9f8dd45fa1a69eb51319ae052886dc0c815 drm/i915/crt: ensure the HW
> is powered during HW state readout
> e597521ee1a8ba7842db6cccf7cbc90bafcf0a90 drm/i915: ensure the HW is
> powered during HW access in assert_pipe
> 5210139ee20523d9aa76908c3196dd11a5ccfb2c drm/i915: ensure the HW is
> powered when disabling VGA
> 611b29445a5c346c2b1a3c65a257fe03e2fd881d drm/i915/ibx: ensure the HW
> is powered during PLL HW readout
> 2897bf36933467eb7cfddbd7e114a516187903d8 drm/i915: ensure the HW is
> powered during display pipe HW readout
> f7ae78f860cf13df1bdc2b3f35d43fa900efe689 drm/i915: add helper to get
> a display power ref if it was already enabled
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] [RFC] kernel/cpu: Use lockref for online CPU reference counting

[Peter Zijlstra]

On Wed, Feb 17, 2016 at 02:47:31PM +0200, Joonas Lahtinen wrote:
> On ti, 2016-02-16 at 12:07 +0100, Peter Zijlstra wrote:
> > On Tue, Feb 16, 2016 at 12:51:03PM +0200, Joonas Lahtinen wrote:
> > > Quoting my original patch;
> > > 
> > > "See the Bugzilla link for more details.
> > 
> > If its not in the Changelog it doesn't exist. Patches should be self
> > contained and not refer to external sources for critical information.
> 
> The exact locking case in CPUfreq drivers causing a splat is described
> in the patch. Details were already included, that's why term "more
> details" was used.

Barely. What was not described was why you went to tinker with the
hotplug lock instead of sanitizing cpufreq. Nor why your chosen solution
is good.

> This is not exactly taking us closer to a fix, 

Why you think we can discuss fixes if you've not actually described your
problem is beyond me.


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

[Intel-gfx] [PATCH RESEND FOR CI] drm/i915/bxt: Initialize MIPI DSI for BXT

[Jani Nikula]

From: Shashank Sharma 

This patch contains following changes:
1. Add BXT MIPI display address base.
2. Call dsi_init from display_setup function.

v2: Rebased on latest nightly branch

v3 by Jani: init dsi after ddi

Signed-off-by: Shashank Sharma 
Signed-off-by: Uma Shankar 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_reg.h  | 1 +
 drivers/gpu/drm/i915/intel_display.c | 2 ++
 drivers/gpu/drm/i915/intel_dsi.c | 2 ++
 3 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3774870477c1..17b3b7915c70 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1795,6 +1795,7 @@ enum skl_disp_power_wells {
 
 #define VLV_DISPLAY_BASE 0x18
 #define VLV_MIPI_BASE VLV_DISPLAY_BASE
+#define BXT_MIPI_BASE 0x6
 
 #define VLV_GU_CTL0_MMIO(VLV_DISPLAY_BASE + 0x2030)
 #define VLV_GU_CTL1_MMIO(VLV_DISPLAY_BASE + 0x2034)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index aedddaabc06b..63090e7cd489 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14411,6 +14411,8 @@ static void intel_setup_outputs(struct drm_device *dev)
intel_ddi_init(dev, PORT_A);
intel_ddi_init(dev, PORT_B);
intel_ddi_init(dev, PORT_C);
+
+   intel_dsi_init(dev);
} else if (HAS_DDI(dev)) {
int found;
 
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 378f879f4015..c28826a77f71 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -1117,6 +1117,8 @@ void intel_dsi_init(struct drm_device *dev)
 
if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev)) {
dev_priv->mipi_mmio_base = VLV_MIPI_BASE;
+   } else if (IS_BROXTON(dev)) {
+   dev_priv->mipi_mmio_base = BXT_MIPI_BASE;
} else {
DRM_ERROR("Unsupported Mipi device to reg base");
return;
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH i-g-t 4/4] tests/gem_scheduler: Add subtests to test batch priority behaviour

[Daniele Ceraolo Spurio]

On 12/02/16 09:38, Derek Morton wrote:

Add subtests to test each ring to check batch buffers of a higher
priority will be executed before batch buffers of a lower priority.

Signed-off-by: Derek Morton 
---
  tests/gem_scheduler.c | 34 --
  1 file changed, 28 insertions(+), 6 deletions(-)

diff --git a/tests/gem_scheduler.c b/tests/gem_scheduler.c
index 4824c13..febde01 100644
--- a/tests/gem_scheduler.c
+++ b/tests/gem_scheduler.c
@@ -39,7 +39,8 @@
  
  IGT_TEST_DESCRIPTION("Check scheduler behaviour. Basic tests ensure independant "

   "batch buffers of the same priority are executed in "
- "submission order. Read-read tests ensure "
+ "submission order. Priority tests ensure higher priority "
+ "batch buffers are executed first. Read-read tests ensure 
"
   "batch buffers with a read dependency to the same buffer 
"
   "object do not block each other. Write-write dependency "
   "tests ensure batch buffers with a write dependency to a 
"
@@ -61,11 +62,13 @@ struct ring {
  
  #define NBR_RINGS (sizeof(rings)/sizeof(struct ring))
  
-/* Basic test. Check batch buffers of the same priority and with no dependencies

- * are executed in the order they are submitted.
+/* If 'priority' is set false, check batch buffers of the same priority and 
with
+ * no dependencies are executed in the order they are submitted.
+ * If 'priority' is set true, check batch buffers of higher priority are
+ * executed before batch buffers of lower priority.
   */
  #define NBR_BASIC_FDs (3)
-static void run_test_basic(int in_flight, int ringid)
+static void run_test_basic(int in_flight, int ringid, bool priority)
  {
int fd[NBR_BASIC_FDs];
int loop;
@@ -95,6 +98,15 @@ static void run_test_basic(int in_flight, int ringid)
intel_batchbuffer_free(noop_bb);
}
  
+	if(priority) {

+   struct local_i915_gem_context_param param;
+   param.context = 0; /* Default context */
+   param.size = 0;
+   param.param = LOCAL_CONTEXT_PARAM_PRIORITY;
+   param.value = 1000;
+   gem_context_set_param(fd[2], );


It would be nice to repeat the test lowering the priority of the default 
ctx of fd[1] instead of increasing the priority of the default ctx of 
fd[2]. Maybe we could pass the priority value instead of a bool as 
parameter in the function and have 3 possible behaviors based on the 
value (0, positive, negative)


Regards,
Daniele


+   }
+
/* Create buffer objects */
delay_bo = drm_intel_bo_alloc(bufmgr[0], "delay bo", BATCH_SZ, 
BATCH_SZ);
igt_assert(delay_bo);
@@ -146,7 +158,12 @@ static void run_test_basic(int in_flight, int ringid)
igt_assert_f(igt_compare_timestamps(delay_buf[2], ts1_buf[0]),
 "Delay ts (0x%08" PRIx32 ") > TS1 ts (0x%08" PRIx32 ")\n",
 delay_buf[2], ts1_buf[0]);
-   igt_assert_f(igt_compare_timestamps(ts1_buf[0], ts2_buf[0]),
+   if(priority)
+   igt_assert_f(igt_compare_timestamps(ts2_buf[0], ts1_buf[0]),
+"TS2 ts (0x%08" PRIx32 ") > TS1 ts (0x%08" PRIx32 
")\n",
+ts2_buf[0], ts1_buf[0]);
+   else
+   igt_assert_f(igt_compare_timestamps(ts1_buf[0], ts2_buf[0]),
 "TS1 ts (0x%08" PRIx32 ") > TS2 ts (0x%08" PRIx32 ")\n",
 ts1_buf[0], ts2_buf[0]);
  
@@ -393,7 +410,12 @@ igt_main
  
  	for (loop=0; loop < NBR_RINGS; loop++)

igt_subtest_f("%s-basic", rings[loop].name) {
-   run_test_basic(in_flight, rings[loop].id);
+   run_test_basic(in_flight, rings[loop].id, false);
+   }
+
+   for (loop=0; loop < NBR_RINGS; loop++)
+   igt_subtest_f("%s-priority", rings[loop].name) {
+   run_test_basic(in_flight, rings[loop].id, true);
}
  
  	for (loop=0; loop < NBR_RINGS; loop++)


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

[Intel-gfx] [PATCH RESEND FOR CI] drm/i915/bxt: Remove DSP CLK_GATE programming for BXT

[Jani Nikula]

From: Uma Shankar 

DSP CLK_GATE registers are specific to BYT and CHT.
Avoid programming the same for BXT platform.

v2: Rebased on latest drm nightly branch.

v3: Fixed Jani's review comments

Signed-off-by: Uma Shankar 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 378f879f4015..e6efc26179bb 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -634,7 +634,6 @@ static void intel_dsi_post_disable(struct intel_encoder 
*encoder)
 {
struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
-   u32 val;
 
DRM_DEBUG_KMS("\n");
 
@@ -642,9 +641,13 @@ static void intel_dsi_post_disable(struct intel_encoder 
*encoder)
 
intel_dsi_clear_device_ready(encoder);
 
-   val = I915_READ(DSPCLK_GATE_D);
-   val &= ~DPOUNIT_CLOCK_GATE_DISABLE;
-   I915_WRITE(DSPCLK_GATE_D, val);
+   if (!IS_BROXTON(dev_priv)) {
+   u32 val;
+
+   val = I915_READ(DSPCLK_GATE_D);
+   val &= ~DPOUNIT_CLOCK_GATE_DISABLE;
+   I915_WRITE(DSPCLK_GATE_D, val);
+   }
 
drm_panel_unprepare(intel_dsi->panel);
 
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH i-g-t 3/4] igt/gem_ctx_param_basic: Updated to support scheduler priority interface

[Daniele Ceraolo Spurio]

On 12/02/16 09:38, Derek Morton wrote:

From: John Harrison 

The GPU scheduler has added an execution priority level to the context
object. There is an IOCTL interface to allow user apps/libraries to
set this priority. This patch updates the context paramter IOCTL test
to include the new interface.

For: VIZ-1587
Signed-off-by: John Harrison 
---
  lib/ioctl_wrappers.h|  1 +
  tests/gem_ctx_param_basic.c | 34 +-
  2 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/lib/ioctl_wrappers.h b/lib/ioctl_wrappers.h
index 4d913c5..f1ef739 100644
--- a/lib/ioctl_wrappers.h
+++ b/lib/ioctl_wrappers.h
@@ -106,6 +106,7 @@ struct local_i915_gem_context_param {
  #define LOCAL_CONTEXT_PARAM_BAN_PERIOD0x1
  #define LOCAL_CONTEXT_PARAM_NO_ZEROMAP0x2
  #define LOCAL_CONTEXT_PARAM_GTT_SIZE  0x3
+#define LOCAL_CONTEXT_PARAM_PRIORITY   0x4
uint64_t value;
  };
  void gem_context_require_ban_period(int fd);
diff --git a/tests/gem_ctx_param_basic.c b/tests/gem_ctx_param_basic.c
index b75800c..585a1a8 100644
--- a/tests/gem_ctx_param_basic.c
+++ b/tests/gem_ctx_param_basic.c
@@ -147,10 +147,42 @@ igt_main
TEST_SUCCESS(LOCAL_IOCTL_I915_GEM_CONTEXT_SETPARAM);
}
  
+	ctx_param.param = LOCAL_CONTEXT_PARAM_PRIORITY;

+
+   igt_subtest("priority-root-set") {
+   ctx_param.context = ctx;
+   ctx_param.value = 2048;
+   TEST_FAIL(LOCAL_IOCTL_I915_GEM_CONTEXT_SETPARAM, EINVAL);
+   ctx_param.value = -2048;
+   TEST_FAIL(LOCAL_IOCTL_I915_GEM_CONTEXT_SETPARAM, EINVAL);
+   ctx_param.value = 512;
+   TEST_SUCCESS(LOCAL_IOCTL_I915_GEM_CONTEXT_SETPARAM);
+   ctx_param.value = -512;
+   TEST_SUCCESS(LOCAL_IOCTL_I915_GEM_CONTEXT_SETPARAM);


in the latest scheduler patchset I've looked at the max and min priority 
values were exported through debugfs via 
i915_scheduler_priority_, so instead of using 512 and 2048 as 
valid and invalid priority values we could use the values returned by 
the debugfs forTEST_SUCCESS and the same values +/-1 for TEST_FAIL.


The patch as it is still LGTM, so with or without my suggested change:

Reviewed-by: Daniele Ceraolo Spurio 

Regards,
Daniele


+   ctx_param.value = 0;
+   TEST_SUCCESS(LOCAL_IOCTL_I915_GEM_CONTEXT_SETPARAM);
+   }
+
+   igt_subtest("priority-non-root-set") {
+   igt_fork(child, 1) {
+   igt_drop_root();
+
+   ctx_param.context = ctx;
+   ctx_param.value = 512;
+   TEST_FAIL(LOCAL_IOCTL_I915_GEM_CONTEXT_SETPARAM, EPERM);
+   ctx_param.value = -512;
+   TEST_SUCCESS(LOCAL_IOCTL_I915_GEM_CONTEXT_SETPARAM);
+   ctx_param.value = 0;
+   TEST_SUCCESS(LOCAL_IOCTL_I915_GEM_CONTEXT_SETPARAM);
+   }
+
+   igt_waitchildren();
+   }
+
/* NOTE: This testcase intentionally tests for the next free parameter
 * to catch ABI extensions. Don't "fix" this testcase without adding all
 * the tests for the new param first. */
-   ctx_param.param = LOCAL_CONTEXT_PARAM_GTT_SIZE + 1;
+   ctx_param.param = LOCAL_CONTEXT_PARAM_PRIORITY + 1;
  
  	igt_subtest("invalid-param-get") {

ctx_param.context = ctx;


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

Re: [Intel-gfx] [maintainer-tools RFC PATCH] dim: add cherry-pick-[next-]fixes subcommands

[Jani Nikula]

On Wed, 10 Feb 2016, Daniel Vetter  wrote:
> On Fri, Jan 29, 2016 at 09:40:32AM +0200, Jani Nikula wrote:
>> Add two new subcommands for cherry-picking fixes from dinq to
>> drm-intel-fixes and drm-intel-next-fixes. The only difference in the
>> subcommands is the assert branch check to ensure the user is on the
>> right branch.
>> 
>> The commands scan dinq for commits Cc'd to stable or drm-intel-fixes,
>> checks whether they've already been backported, attempts cherry-pick,
>> and asks for directions on failed cherry-pick.
>> 
>> It's still rough around the edges and slow as molasses due to unlimited
>> scan for backports (should just check a release or two back at most),
>> and an aborted run just starts over next time (though it should take the
>> freshly backported commits into account).
>> 
>> Signed-off-by: Jani Nikula 
>> 
>> ---
>> 
>> Undecided whether we should apply this already or not. It's crude, but I
>> use it.
>
> Imo add help text and push it. We can prettify later on. Oh and maybe bash
> completion too. Wrt speeding this up, have you looked at gregkh's
> toolchaing for stable kernels? It should be out there somewhere.

Added help and pushed.

BR,
Jani.


> -Daniel
>
>> ---
>>  dim | 49 +
>>  1 file changed, 49 insertions(+)
>> 
>> diff --git a/dim b/dim
>> index 203c6b60cf1b..c64f6e86af62 100755
>> --- a/dim
>> +++ b/dim
>> @@ -473,6 +473,55 @@ function dim_cherry_pick
>>  $DRY git cherry-pick $1
>>  }
>>  
>> +function dim_cherry_pick_branch
>> +{
>> +for commit in $(git log --reverse --format=format:%h 
>> --grep="drm-intel-fi...@lists.freedesktop.org" 
>> --grep="sta...@vger.kernel.org" 
>> origin/master..$DIM_DRM_INTEL_REMOTE/drm-intel-next-queued -- 
>> drivers/gpu/drm/i915); do
>> +echo "Considering $(git --no-pager log --oneline -1 $commit)"
>> +log=$(mktemp)
>> +# note *local* branches to account for unpushed ones
>> +git log drm-intel-fixes --oneline --grep="cherry picked .* 
>> $commit" > $log
>> +git log drm-intel-next-fixes --oneline --grep="cherry picked .* 
>> $commit" >> $log
>> +if [ "$(cat $log)" = "" ]; then
>> +if ! git cherry-pick -e -x -s $commit; then
>> +select choice in "Diff" "Resolve" "Skip" 
>> "Abort"; do
>> +case $choice in
>> +Diff)
>> +git diff
>> +;;
>> +Resolve)
>> +exit
>> +;;
>> +Skip)
>> +git cherry-pick --abort
>> +break
>> +;;
>> +Abort)
>> +git cherry-pick --abort
>> +exit
>> +;;
>> +esac
>> +done
>> +fi
>> +else
>> +echo "Already backported as:"
>> +sed 's/^/\t/' < $log
>> +fi
>> +rm -f $log
>> +done
>> +}
>> +
>> +function dim_cherry_pick_fixes
>> +{
>> +assert_branch drm-intel-fixes
>> +dim_cherry_pick_branch "$@"
>> +}
>> +
>> +function dim_cherry_pick_next_fixes
>> +{
>> +assert_branch drm-intel-next-fixes
>> +dim_cherry_pick_branch "$@"
>> +}
>> +
>>  dim_alias_ar=apply-resolved
>>  function dim_apply_resolved
>>  {
>> -- 
>> 2.1.4
>> 

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 003/190] drm/i915: Add an optional selection from i915 of CONFIG_MMU_NOTIFIER

[Daniel Vetter]

On Mon, Jan 11, 2016 at 09:16:14AM +, Chris Wilson wrote:
> userptr requires mmu-notifier for full unprivileged support. Most
> systems have mmu-notifier support already enabled as a requirement for
> virtualisation support, but we should make the option for i915 to take
> advantage of mmu-notifiers explicit (and enable by default so that
> regular userspace can take advantage of passing client memory to the
> GPU.)
> 
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Reviewed-by: Tvrtko Ursulin 

Queued for -next, thanks for the patch.
-Daniel

> ---
>  drivers/gpu/drm/i915/Kconfig | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index fcd77b27514d..b979295aab82 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -48,3 +48,14 @@ config DRM_I915_PRELIMINARY_HW_SUPPORT
> option changes the default for that module option.
>  
> If in doubt, say "N".
> +
> +config DRM_I915_USERPTR
> + bool "Always enable userptr support"
> + depends on DRM_I915
> + select MMU_NOTIFIER
> + default y
> + help
> +   This option selects CONFIG_MMU_NOTIFIER if it isn't already
> +   selected to enabled full userptr support.
> +
> +   If in doubt, say "Y".
> -- 
> 2.7.0.rc3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 01/21] drm/i915: Account for the size of the chroma plane for the rotated gtt view

[Joonas Lahtinen]

Hi,

On ma, 2016-02-15 at 22:54 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> The size of the rotated ggtt mapping ought to include the size of the
> chroma plane as well. Not a huge deal since we don't expose NV12 (or any
> pother planar format for that matter) yet.
> 
> Cc: Tvrtko Ursulin 
> Cc: Joonas Lahtinen 
> Fixes: 9e759ff1f4a0 ("drm/i915: Return correct size for rotated views")
> Signed-off-by: Ville Syrjälä 

A good catch. (That line even stays exactly below 80 character limit.)

Reviewed-by: Joonas Lahtinen 

> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 9127f8f3561c..4ccc8ec7003c 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -3636,7 +3636,7 @@ i915_ggtt_view_size(struct drm_i915_gem_object *obj,
>   if (view->type == I915_GGTT_VIEW_NORMAL) {
>   return obj->base.size;
>   } else if (view->type == I915_GGTT_VIEW_ROTATED) {
> - return view->params.rotated.size;
> + return view->params.rotated.size + view->params.rotated.size_uv;
>   } else if (view->type == I915_GGTT_VIEW_PARTIAL) {
>   return view->params.partial.size << PAGE_SHIFT;
>   } else {
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] [RFC] kernel/cpu: Use lockref for online CPU reference counting

[Joonas Lahtinen]

On ti, 2016-02-16 at 12:07 +0100, Peter Zijlstra wrote:
> On Tue, Feb 16, 2016 at 12:51:03PM +0200, Joonas Lahtinen wrote:
> > Quoting my original patch;
> > 
> > "See the Bugzilla link for more details.
> 
> If its not in the Changelog it doesn't exist. Patches should be self
> contained and not refer to external sources for critical information.

The exact locking case in CPUfreq drivers causing a splat is described
in the patch. Details were already included, that's why term "more
details" was used.

This is not exactly taking us closer to a fix, so I'd rather like to
discuss about the possibility of adding one more member to task_struct.
I added Oleg as CC to catch his attention to re-evaluate based on the
previous discussion in this thread.

Regards, Joonas

-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: add missing display power refs (rev3)

[Patchwork]

== Summary ==

Series 3372v3 drm/i915: add missing display power refs
http://patchwork.freedesktop.org/api/1.0/series/3372/revisions/3/mbox/

Test pm_rpm:
Subgroup basic-pci-d3-state:
dmesg-warn -> PASS   (bsw-nuc-2)

bsw-nuc-2total:165  pass:136  dwarn:0   dfail:0   fail:0   skip:29 

Results at /archive/results/CI_IGT_test/Patchwork_1423/

e99a344c64936ee4a67459f22e5a72bc4ae470bf drm-intel-nightly: 
2016y-02m-17d-11h-25m-24s UTC integration manifest
6bac804f8e89ac717f5344b2797775cb943ae920 drm/i915/lvds: ensure the HW is 
powered during HW state readout
9909cd7334eed8d7e889020313ddc2d22ff278ab drm/i915/hdmi: ensure the HW is 
powered during HW state readout
9aa76ff07c56503d61712402e0079d3fe56c79b9 drm/i915/dsi: ensure the HW is powered 
during HW state readout
08f821a5cbc83b3c1f70f575365d70c2d23bdce7 drm/i915/dp: ensure the HW is powered 
during HW state readout
d04bf77e309852d193e74b646e685c1bf20a2732 drm/i915: ensure the HW is powered 
when accessing the CRC HW block
4c00c62f648389fad9b892fd5079c4fe948e1125 drm/i915/ddi: ensure the HW is powered 
during HW state readout
efdfa9f8dd45fa1a69eb51319ae052886dc0c815 drm/i915/crt: ensure the HW is powered 
during HW state readout
e597521ee1a8ba7842db6cccf7cbc90bafcf0a90 drm/i915: ensure the HW is powered 
during HW access in assert_pipe
5210139ee20523d9aa76908c3196dd11a5ccfb2c drm/i915: ensure the HW is powered 
when disabling VGA
611b29445a5c346c2b1a3c65a257fe03e2fd881d drm/i915/ibx: ensure the HW is powered 
during PLL HW readout
2897bf36933467eb7cfddbd7e114a516187903d8 drm/i915: ensure the HW is powered 
during display pipe HW readout
f7ae78f860cf13df1bdc2b3f35d43fa900efe689 drm/i915: add helper to get a display 
power ref if it was already enabled

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

Re: [Intel-gfx] [PATCH i-g-t 2/4] tests/gem_scheduler: Add gem_scheduler test

[Daniele Ceraolo Spurio]

Hi,

first round of comments inline. A few things will probably have to 
change based on the comments on the previous patch in the series so I'll 
have a better look at the related logic once the new series is up.


Regards,
Daniele


On 12/02/16 09:38, Derek Morton wrote:

This is intended to test the scheduler behaviour is correct.
The subtests are
-basic
Tests that batch buffers of the same priority submitted to a ring
execute in the order they are submitted.
-read
Submits a batch buffer with a read dependency to a buffer object to
a ring which is held in the scheduler queue by a long running batch
buffer. Submit batch buffers to other rings that have a read dependency
to the same buffer object. Ensure they execute before the batch buffer
being held up behind the long running batch buffer.
-write
Submits a batch buffer with a write dependency to a buffer object to
a ring which is held in the scheduler queue by a long running batch
buffer. Submit batch buffers to other rings that have a write dependency
to the same buffer object. Submit batch buffers with no interdependencies
to all rings. Ensure the batch buffers that have write dependencies are
executed in submission order but the batch buffers without interdependencies
do not get held up.

Signed-off-by: Derek Morton 
---
  tests/Makefile.sources |   1 +
  tests/gem_scheduler.c  | 409 +
  2 files changed, 410 insertions(+)
  create mode 100644 tests/gem_scheduler.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index df92586..439f62c 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -66,6 +66,7 @@ TESTS_progs_M = \
gem_request_retire \
gem_reset_stats \
gem_ringfill \
+   gem_scheduler \
gem_set_tiling_vs_blt \
gem_softpin \
gem_stolen \
diff --git a/tests/gem_scheduler.c b/tests/gem_scheduler.c
new file mode 100644
index 000..4824c13
--- /dev/null
+++ b/tests/gem_scheduler.c
@@ -0,0 +1,409 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Derek Morton 
+ *
+ */
+
+#include "igt.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+IGT_TEST_DESCRIPTION("Check scheduler behaviour. Basic tests ensure independant 
"
+ "batch buffers of the same priority are executed in "
+ "submission order. Read-read tests ensure "
+ "batch buffers with a read dependency to the same buffer "
+ "object do not block each other. Write-write dependency "
+ "tests ensure batch buffers with a write dependency to a "
+ "buffer object will be executed in submission order but "
+ "will not block execution of other independant batch "
+ "buffers.");
+
+#define SEC_TO_NSEC (1000 * 1000 * 1000)
+
+struct ring {
+   const char *name;
+   int id;
+} rings[] = {
+   { "render", I915_EXEC_RENDER },
+   { "bsd",I915_EXEC_BSD },


Is BSD1/BSD2 difference of any importance for the tests?


+   { "blt",I915_EXEC_BLT },
+   { "vebox",  I915_EXEC_VEBOX },
+};


This is a slight duplication of intel_execution_engines. However, I'm 
not sure that intel_execution_engines is suitable here considering that 
it doesn't seem you want to check both the vanilla I915_EXEC_BSD case 
and the BSD1/BSD2 case



+
+#define NBR_RINGS (sizeof(rings)/sizeof(struct ring))
+
+/* Basic test. Check batch buffers of the same priority and with no 
dependencies
+ * are executed in the order they are submitted.
+ */
+#define NBR_BASIC_FDs (3)
+static void run_test_basic(int in_flight, int ringid)
+{
+   int fd[NBR_BASIC_FDs];
+   int loop;
+   

Re: [Intel-gfx] [PATCH 08/12] drm/i915: ensure the HW is powered when accessing the CRC HW block

[Imre Deak]

On ti, 2016-02-16 at 17:02 +0100, Daniel Vetter wrote:
> On Fri, Feb 12, 2016 at 06:55:17PM +0200, Imre Deak wrote:
> > The assumption when adding the intel_display_power_is_enabled()
> > checks
> > was that if it returns success the power can't be turned off
> > afterwards
> > during the HW access, which is guaranteed by modeset locks. This
> > isn't
> > always true, so make sure we hold a dedicated reference for the
> > time of
> > the access.
> > 
> > Signed-off-by: Imre Deak 
> 
> subject needs to be fixed to mention that this is for all the stuff
> in
> i915_debugfs.c.

Ah, yea i915_interrupt_info() is also changed, will updated that in the
log.

> With that fixed for patches 4-8:
> 
> Reviewed-by: Daniel Vetter 
> 
> 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 28 +--
> > -
> >  1 file changed, 21 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index ec0c2a05e..9e19cf0 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -825,8 +825,11 @@ static int i915_interrupt_info(struct seq_file
> > *m, void *data)
> >     }
> >  
> >     for_each_pipe(dev_priv, pipe) {
> > -   if
> > (!intel_display_power_is_enabled(dev_priv,
> > -   POWER_DOMAIN_PIPE(
> > pipe))) {
> > +   enum intel_display_power_domain
> > power_domain;
> > +
> > +   power_domain = POWER_DOMAIN_PIPE(pipe);
> > +   if
> > (!intel_display_power_get_if_enabled(dev_priv,
> > +   po
> > wer_domain)) {
> >     seq_printf(m, "Pipe %c power
> > disabled\n",
> >        pipe_name(pipe));
> >     continue;
> > @@ -840,6 +843,8 @@ static int i915_interrupt_info(struct seq_file
> > *m, void *data)
> >     seq_printf(m, "Pipe %c IER:\t%08x\n",
> >        pipe_name(pipe),
> >        I915_READ(GEN8_DE_PIPE_IER(pipe
> > )));
> > +
> > +   intel_display_power_put(dev_priv,
> > power_domain);
> >     }
> >  
> >     seq_printf(m, "Display Engine port interrupt
> > mask:\t%08x\n",
> > @@ -4004,6 +4009,7 @@ static int pipe_crc_set_source(struct
> > drm_device *dev, enum pipe pipe,
> >     struct intel_pipe_crc *pipe_crc = _priv-
> > >pipe_crc[pipe];
> >     struct intel_crtc *crtc =
> > to_intel_crtc(intel_get_crtc_for_pipe(dev,
> >     
> > pipe));
> > +   enum intel_display_power_domain power_domain;
> >     u32 val = 0; /* shut up gcc */
> >     int ret;
> >  
> > @@ -4014,7 +4020,8 @@ static int pipe_crc_set_source(struct
> > drm_device *dev, enum pipe pipe,
> >     if (pipe_crc->source && source)
> >     return -EINVAL;
> >  
> > -   if (!intel_display_power_is_enabled(dev_priv,
> > POWER_DOMAIN_PIPE(pipe))) {
> > +   power_domain = POWER_DOMAIN_PIPE(pipe);
> > +   if (!intel_display_power_get_if_enabled(dev_priv,
> > power_domain)) {
> >     DRM_DEBUG_KMS("Trying to capture CRC while pipe is
> > off\n");
> >     return -EIO;
> >     }
> > @@ -4031,7 +4038,7 @@ static int pipe_crc_set_source(struct
> > drm_device *dev, enum pipe pipe,
> >     ret = ivb_pipe_crc_ctl_reg(dev, pipe, ,
> > );
> >  
> >     if (ret != 0)
> > -   return ret;
> > +   goto out;
> >  
> >     /* none -> real source transition */
> >     if (source) {
> > @@ -4043,8 +4050,10 @@ static int pipe_crc_set_source(struct
> > drm_device *dev, enum pipe pipe,
> >     entries = kcalloc(INTEL_PIPE_CRC_ENTRIES_NR,
> >       sizeof(pipe_crc->entries[0]),
> >       GFP_KERNEL);
> > -   if (!entries)
> > -   return -ENOMEM;
> > +   if (!entries) {
> > +   ret = -ENOMEM;
> > +   goto out;
> > +   }
> >  
> >     /*
> >      * When IPS gets enabled, the pipe CRC changes.
> > Since IPS gets
> > @@ -4100,7 +4109,12 @@ static int pipe_crc_set_source(struct
> > drm_device *dev, enum pipe pipe,
> >     hsw_enable_ips(crtc);
> >     }
> >  
> > -   return 0;
> > +   ret = 0;
> > +
> > +out:
> > +   intel_display_power_put(dev_priv, power_domain);
> > +
> > +   return ret;
> >  }
> >  
> >  /*
> > -- 
> > 2.5.0
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 01/12] drm/i915: add helper to get a display power ref if it was already enabled

[Imre Deak]

We have many places in the code where we check if a given display power
domain is enabled and if so access registers backed by this power
domain. We assumed that some modeset lock will prevent the power
reference from vanishing in the middle of the HW access, but this
assumption doesn't always hold. In such cases we get either the wakeref
not held, or an unclaimed register access error message. To fix this in
a future-proof way that's independent of other locks wrap any such
access with a get_ref_if_enabled()/put_ref() pair.

Kudos to Ville and Joonas for the ideas of this new interface.

v2:
- init the power_domains ptr when declaring it everywhere (Joonas)
v3:
- don't report the device to be powered if runtime PM is disabled

CC: Mika Kuoppala 
CC: Chris Wilson 
CC: Joonas Lahtinen 
CC: Ville Syrjälä 
Signed-off-by: Imre Deak 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_drv.h|   3 +
 drivers/gpu/drm/i915/intel_runtime_pm.c | 124 ++--
 2 files changed, 106 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3cae376..f95f8b2 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1436,6 +1436,8 @@ bool __intel_display_power_is_enabled(struct 
drm_i915_private *dev_priv,
  enum intel_display_power_domain domain);
 void intel_display_power_get(struct drm_i915_private *dev_priv,
 enum intel_display_power_domain domain);
+bool intel_display_power_get_if_enabled(struct drm_i915_private *dev_priv,
+   enum intel_display_power_domain domain);
 void intel_display_power_put(struct drm_i915_private *dev_priv,
 enum intel_display_power_domain domain);
 
@@ -1522,6 +1524,7 @@ enable_rpm_wakeref_asserts(struct drm_i915_private 
*dev_priv)
enable_rpm_wakeref_asserts(dev_priv)
 
 void intel_runtime_pm_get(struct drm_i915_private *dev_priv);
+bool intel_runtime_pm_get_if_in_use(struct drm_i915_private *dev_priv);
 void intel_runtime_pm_get_noresume(struct drm_i915_private *dev_priv);
 void intel_runtime_pm_put(struct drm_i915_private *dev_priv);
 
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index bbca527..a2e367c 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1435,39 +1435,84 @@ static void chv_pipe_power_well_disable(struct 
drm_i915_private *dev_priv,
chv_set_pipe_power_well(dev_priv, power_well, false);
 }
 
-/**
- * intel_display_power_get - grab a power domain reference
- * @dev_priv: i915 device instance
- * @domain: power domain to reference
- *
- * This function grabs a power domain reference for @domain and ensures that 
the
- * power domain and all its parents are powered up. Therefore users should only
- * grab a reference to the innermost power domain they need.
- *
- * Any power domain reference obtained by this function must have a symmetric
- * call to intel_display_power_put() to release the reference again.
- */
-void intel_display_power_get(struct drm_i915_private *dev_priv,
-enum intel_display_power_domain domain)
+static void
+__intel_display_power_get_domain(struct drm_i915_private *dev_priv,
+enum intel_display_power_domain domain)
 {
-   struct i915_power_domains *power_domains;
+   struct i915_power_domains *power_domains = _priv->power_domains;
struct i915_power_well *power_well;
int i;
 
-   intel_runtime_pm_get(dev_priv);
-
-   power_domains = _priv->power_domains;
-
-   mutex_lock(_domains->lock);
-
for_each_power_well(i, power_well, BIT(domain), power_domains) {
if (!power_well->count++)
intel_power_well_enable(dev_priv, power_well);
}
 
power_domains->domain_use_count[domain]++;
+}
+
+/**
+ * intel_display_power_get - grab a power domain reference
+ * @dev_priv: i915 device instance
+ * @domain: power domain to reference
+ *
+ * This function grabs a power domain reference for @domain and ensures that 
the
+ * power domain and all its parents are powered up. Therefore users should only
+ * grab a reference to the innermost power domain they need.
+ *
+ * Any power domain reference obtained by this function must have a symmetric
+ * call to intel_display_power_put() to release the reference again.
+ */
+void intel_display_power_get(struct drm_i915_private *dev_priv,
+enum intel_display_power_domain domain)
+{
+   struct i915_power_domains *power_domains = _priv->power_domains;
+
+   intel_runtime_pm_get(dev_priv);
+
+   

Re: [Intel-gfx] [PATCH i-g-t v5] lib/igt_kms: Add COMIT_ATOMIC to igt_display_commit2()

[Pratik Vishwakarma]

Hi Maarten,

There will be no difference in execution based on ATOMIC client cap.
If it fails, the number of properties we receive is 2 (type and 
rotation) whereas if ATOMIC client cap is set, we actually receive all 
the supported atomic properties i.e. src_w,src_h etc.


We have added the return check in igt_atomic_commit.

We tested this patch by modifying the kms_rotation_crc test and found 
that this is required.

I will be submitting the kms_rotation_crc patch separately.

Let me know your thoughts on this.

P.S. I will submit a new patch with Jani's comments fix.

On Monday 15 February 2016 06:12 PM, Maarten Lankhorst wrote:

Op 12-02-16 om 11:34 schreef Pratik Vishwakarma:

From: Mayuresh Gharpure 

Co-Author : Marius Vlad 
Co-Author : Pratik Vishwakarma 

So far we have had only two commit styles, COMMIT_LEGACY
and COMMIT_UNIVERSAL. This patch adds another commit style
COMMIT_ATOMIC which makes use of drmModeAtomicCommit()

v2: (Marius)
i)Set CRTC_ID to zero while disabling plane
ii)Modified the log message in igt_atomic_prepare_plane_commit
https://patchwork.freedesktop.org/patch/71945/

v3: (Marius)Set FB_ID to zero while disabling plane
https://patchwork.freedesktop.org/patch/72179/

v4: (Maarten) Corrected the typo in commit message
https://patchwork.freedesktop.org/patch/72598/

v5: Added check for DRM_CLIENT_CAP_ATOMIC in igt_display_init
 (Marius)
i)Removed unused props from igt_display_init
ii)Removed unused ret. Changed function to void
iii)Declare the variable before checking if we have
DRM_CLIENT_CAP_ATOMIC.

Signed-off-by: Mayuresh Gharpure 
Signed-off-by: Pratik Vishwakarma 
---
  lib/igt_kms.c | 317 +-
  lib/igt_kms.h |  71 -
  2 files changed, 386 insertions(+), 2 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 90c8da7..8e201e8 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -145,6 +145,120 @@ const unsigned char* igt_kms_get_base_edid(void)
   *
   * Returns: an alternate edid block
   */
+static const char *igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
+   "SRC_X",
+   "SRC_Y",
+   "SRC_W",
+   "SRC_H",
+   "CRTC_X",
+   "CRTC_Y",
+   "CRTC_W",
+   "CRTC_H",
+   "FB_ID",
+   "CRTC_ID",
+   "type",
+   "rotation"
+};
+
+static const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
+   "background_color"
+};
+
+static const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
+   "scaling mode",
+   "DPMS"
+};
+
+/*
+ * Retrieve all the properies specified in props_name and store them into
+ * plane->atomic_props_plane.
+ */
+static void
+igt_atomic_fill_plane_props(igt_display_t *display, igt_plane_t *plane,
+   int num_props, const char **prop_names)
+{
+   drmModeObjectPropertiesPtr props;
+   int i, j, fd;
+
+   fd = display->drm_fd;
+
+   props = drmModeObjectGetProperties(fd, plane->drm_plane->plane_id, 
DRM_MODE_OBJECT_PLANE);
+   igt_assert(props);
+
+   for (i = 0; i < props->count_props; i++) {
+   drmModePropertyPtr prop =
+   drmModeGetProperty(fd, props->props[i]);
+
+   for (j = 0; j < num_props; j++) {
+   if (strcmp(prop->name, prop_names[j]) != 0)
+   continue;
+
+   plane->atomic_props_plane[j] = props->props[i];
+   break;
+   }
+
+   drmModeFreeProperty(prop);
+   }
+
+   drmModeFreeObjectProperties(props);
+}
+
+/*
+ * Retrieve all the properies specified in props_name and store them into
+ * config->atomic_props_crtc and config->atomic_props_connector.
+ */
+static void
+igt_atomic_fill_props(igt_display_t *display, igt_output_t *output,
+   int num_crtc_props, const char **crtc_prop_names,
+   int num_connector_props, const char **conn_prop_names)
+{
+   drmModeObjectPropertiesPtr props;
+   int i, j, fd;
+
+   fd = display->drm_fd;
+
+   props = drmModeObjectGetProperties(fd, output->config.crtc->crtc_id, 
DRM_MODE_OBJECT_CRTC);
+   igt_assert(props);
+
+   for (i = 0; i < props->count_props; i++) {
+   drmModePropertyPtr prop =
+   drmModeGetProperty(fd, props->props[i]);
+
+   for (j = 0; j < num_crtc_props; j++) {
+   if (strcmp(prop->name, crtc_prop_names[j]) != 0)
+   continue;
+
+   output->config.atomic_props_crtc[j] = props->props[i];
+   break;
+   }
+
+   drmModeFreeProperty(prop);
+   }
+
+   drmModeFreeObjectProperties(props);
+   props = NULL;

[Intel-gfx] [PATCH libdrm] intel/skl: Add missing SKL PCI IDs

[Michał Winiarski]

Used by production devices:
Intel(R) HD Graphics 510
Intel(R) HD Graphics 535
Intel(R) Iris(TM) Graphics 550
Intel(R) Iris(TM) Graphics P555

Signed-off-by: Michał Winiarski 
---
 intel/intel_chipset.h | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 35148e5..f52e149 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -168,6 +168,7 @@
 #define PCI_CHIP_SKYLAKE_DT_GT10x1902
 #define PCI_CHIP_SKYLAKE_ULT_GT1   0x1906
 #define PCI_CHIP_SKYLAKE_SRV_GT1   0x190A /* Reserved */
+#define PCI_CHIP_SKYLAKE_H_GT1 0x190B
 #define PCI_CHIP_SKYLAKE_ULX_GT1   0x190E /* Reserved */
 #define PCI_CHIP_SKYLAKE_DT_GT20x1912
 #define PCI_CHIP_SKYLAKE_FUSED0_GT20x1913 /* Reserved */
@@ -179,9 +180,12 @@
 #define PCI_CHIP_SKYLAKE_WKS_GT2   0x191D
 #define PCI_CHIP_SKYLAKE_ULX_GT2   0x191E
 #define PCI_CHIP_SKYLAKE_MOBILE_GT20x1921 /* Reserved */
-#define PCI_CHIP_SKYLAKE_GT3   0x1926
-#define PCI_CHIP_SKYLAKE_HALO_GT3  0x192B /* Reserved */
+#define PCI_CHIP_SKYLAKE_ULT_GT3_0 0x1923
+#define PCI_CHIP_SKYLAKE_ULT_GT3_1 0x1926
+#define PCI_CHIP_SKYLAKE_ULT_GT3_2 0x1927
 #define PCI_CHIP_SKYLAKE_SRV_GT4   0x192A
+#define PCI_CHIP_SKYLAKE_HALO_GT3  0x192B /* Reserved */
+#define PCI_CHIP_SKYLAKE_SRV_GT3   0x192D
 #define PCI_CHIP_SKYLAKE_DT_GT40x1932
 #define PCI_CHIP_SKYLAKE_SRV_GT4X  0x193A
 #define PCI_CHIP_SKYLAKE_H_GT4 0x193B
@@ -373,10 +377,11 @@
 #define IS_GEN8(devid) (IS_BROADWELL(devid) || \
 IS_CHERRYVIEW(devid))
 
-#define IS_SKL_GT1(devid)  ((devid) == PCI_CHIP_SKYLAKE_ULT_GT1|| \
-(devid) == PCI_CHIP_SKYLAKE_ULX_GT1|| \
-(devid) == PCI_CHIP_SKYLAKE_DT_GT1 || \
-(devid) == PCI_CHIP_SKYLAKE_SRV_GT1)
+#define IS_SKL_GT1(devid)  ((devid) == PCI_CHIP_SKYLAKE_DT_GT1 || \
+(devid) == PCI_CHIP_SKYLAKE_ULT_GT1|| \
+(devid) == PCI_CHIP_SKYLAKE_SRV_GT1|| \
+(devid) == PCI_CHIP_SKYLAKE_H_GT1  || \
+(devid) == PCI_CHIP_SKYLAKE_ULX_GT1)
 
 #define IS_SKL_GT2(devid)  ((devid) == PCI_CHIP_SKYLAKE_DT_GT2 || \
 (devid) == PCI_CHIP_SKYLAKE_FUSED0_GT2 || \
@@ -389,8 +394,11 @@
 (devid) == PCI_CHIP_SKYLAKE_ULX_GT2|| \
 (devid) == PCI_CHIP_SKYLAKE_MOBILE_GT2)
 
-#define IS_SKL_GT3(devid)  ((devid) == PCI_CHIP_SKYLAKE_GT3|| \
-(devid) == PCI_CHIP_SKYLAKE_HALO_GT3)
+#define IS_SKL_GT3(devid)  ((devid) == PCI_CHIP_SKYLAKE_ULT_GT3_0  || \
+(devid) == PCI_CHIP_SKYLAKE_ULT_GT3_1  || \
+(devid) == PCI_CHIP_SKYLAKE_ULT_GT3_2  || \
+(devid) == PCI_CHIP_SKYLAKE_HALO_GT3   || \
+(devid) == PCI_CHIP_SKYLAKE_SRV_GT3)
 
 #define IS_SKL_GT4(devid)  ((devid) == PCI_CHIP_SKYLAKE_SRV_GT4|| \
 (devid) == PCI_CHIP_SKYLAKE_DT_GT4 || \
-- 
2.7.1

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for Use more atomic state in i915.

[Patchwork]

== Summary ==

Series 3515v1 Use more atomic state in i915.
http://patchwork.freedesktop.org/api/1.0/series/3515/revisions/1/mbox/

Test gem_ringfill:
Subgroup basic-default-hang:
incomplete -> PASS   (snb-dellxps)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Test kms_force_connector_basic:
Subgroup force-load-detect:
fail   -> DMESG-FAIL (ilk-hp8440p)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (skl-i5k-2)
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (skl-i5k-2)
dmesg-warn -> PASS   (bsw-nuc-2)
Test pm_rpm:
Subgroup basic-pci-d3-state:
fail   -> PASS   (bdw-nuci7)
dmesg-warn -> PASS   (byt-nuc)
Subgroup basic-rte:
dmesg-warn -> PASS   (bsw-nuc-2)

bdw-nuci7total:162  pass:152  dwarn:0   dfail:0   fail:0   skip:10 
bdw-ultratotal:165  pass:152  dwarn:0   dfail:0   fail:0   skip:13 
bsw-nuc-2total:165  pass:136  dwarn:0   dfail:0   fail:0   skip:29 
byt-nuc  total:165  pass:141  dwarn:0   dfail:0   fail:0   skip:24 
hsw-brixbox  total:165  pass:151  dwarn:0   dfail:0   fail:0   skip:14 
ilk-hp8440p  total:165  pass:115  dwarn:1   dfail:1   fail:0   skip:48 
ivb-t430stotal:165  pass:150  dwarn:0   dfail:0   fail:1   skip:14 
skl-i5k-2total:165  pass:149  dwarn:1   dfail:0   fail:0   skip:15 
snb-dellxps  total:165  pass:142  dwarn:0   dfail:0   fail:1   skip:22 

Results at /archive/results/CI_IGT_test/Patchwork_1422/

bd0b1a9aa8b7fdb2e06a5cbf1756ef93de2fa3fd drm-intel-nightly: 
2016y-02m-16d-17h-53m-05s UTC integration manifest
63594c947569ab29b704e598a04309083e1eb97f drm/i915: Use atomic state in 
intel_fb_initial_config.
449a002e8dee4e01290e7681139584e28d0c3cc7 drm/i915: Use correct dpms for 
intel_enable_crt.
e215b05e035b783bfe00165be36a7045fb97e395 drm/i915: Use atomic state in tv load 
detection.
56c9d06492c8693240dcfdb0f9617fb5f8bb07f2 drm/i915: Use atomic state for load 
detect in crt.
8489191ff8deab10d5ddbea70cac18c69d019bd8 drm/i915: Use atomic state to obtain 
load detection crtc, v3.

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/atomic: Allow for holes in connector state, v2.

[Patchwork]

== Summary ==

Series 3514v1 drm/atomic: Allow for holes in connector state, v2.
http://patchwork.freedesktop.org/api/1.0/series/3514/revisions/1/mbox/

Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Test pm_rpm:
Subgroup basic-pci-d3-state:
dmesg-warn -> PASS   (byt-nuc)

byt-nuc  total:165  pass:141  dwarn:0   dfail:0   fail:0   skip:24 
ilk-hp8440p  total:165  pass:115  dwarn:1   dfail:0   fail:1   skip:48 
snb-x220ttotal:165  pass:142  dwarn:0   dfail:0   fail:2   skip:21 

Results at /archive/results/CI_IGT_test/Patchwork_1421/

bd0b1a9aa8b7fdb2e06a5cbf1756ef93de2fa3fd drm-intel-nightly: 
2016y-02m-16d-17h-53m-05s UTC integration manifest
d8fd198f83edf12cb2611f483585350a77a2ccb3 drm/atomic: Allow for holes in 
connector state, v2.

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

Re: [Intel-gfx] [PATCH i-g-t 1/4] lib/igt_bb_factory: Add igt_bb_factory library

[Daniele Ceraolo Spurio]

On 12/02/16 09:38, Derek Morton wrote:

Adds functions to create a number of different batch buffers to perform
several functions including:
Batch buffer which will run for a long duration to provide a delay on a
specified ring.
Function to calibrate the delay batch buffer to run for a specified period
of time.
Function to create a batch buffer which writes timestamps to a buffer object.
Function to compare timestamps allowing for wrapping of the values.

Intended for use by the gem_scheduler test initially but will be used by other
tests in development.

Signed-off-by: Derek Morton 
---
  lib/Makefile.sources |   2 +
  lib/igt.h|   1 +
  lib/igt_bb_factory.c | 401 +++
  lib/igt_bb_factory.h |  47 ++
  4 files changed, 451 insertions(+)
  create mode 100644 lib/igt_bb_factory.c
  create mode 100644 lib/igt_bb_factory.h

diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 4999868..c560b3e 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -7,6 +7,8 @@ libintel_tools_la_SOURCES = \
i915_reg.h  \
i915_pciids.h   \
igt.h   \
+   igt_bb_factory.c\
+   igt_bb_factory.h\
igt_debugfs.c   \
igt_debugfs.h   \
igt_aux.c   \
diff --git a/lib/igt.h b/lib/igt.h
index 3be2551..0f29420 100644
--- a/lib/igt.h
+++ b/lib/igt.h
@@ -36,6 +36,7 @@
  #include "igt_gt.h"
  #include "igt_kms.h"
  #include "igt_stats.h"
+#include "igt_bb_factory.h"
  #include "instdone.h"
  #include "intel_batchbuffer.h"
  #include "intel_chipset.h"
diff --git a/lib/igt_bb_factory.c b/lib/igt_bb_factory.c
new file mode 100644
index 000..eea63c6
--- /dev/null
+++ b/lib/igt_bb_factory.c
@@ -0,0 +1,401 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Derek Morton 
+ *
+ */
+
+#include "igt.h"
+#include "intel_batchbuffer.h"
+#include 
+#include 
+#include 
+
+#define SEC_TO_NSEC (1000 * 1000 * 1000)
+#define DWORDS_TO_BYTES(x) ((x)*4)
+
+#define MI_STORE_REGISTER_MEM(LENGTH)   ((0x024 << 23) | ((LENGTH - 2) & 0xff))
+#define MI_MATH(NrInst) ((0x01A << 23) | ((NrInst - 1) & 0x3f))
+#define MI_CONDITIONAL_BATCH_BUFFER_END ((0x036 << 23) | (1 << 21) | 2)
+#define MI_COPY_MEM_MEM ((0x02E << 23) | (3))
+
+#define ALU_LOAD(TO, FROM)  ((0x080 << 20) | ((TO) << 10) | (FROM))
+#define ALU_SUB ( 0x101 << 20)
+#define ALU_STORE(TO, FROM) ((0x180 << 20) | ((TO) << 10) | (FROM))
+
+#define TIMESTAMP_offset  (0x358) /* Elapsed time from system start */
+#define CTX_TIMESTAMP_offset  (0x3A8) /* Elapsed Time from context creation */
+#define ALU_GPU_R0_LSB_offset (0x600)
+#define ALU_GPU_R0_MSB_offset (0x604)
+#define ALU_GPU_R1_LSB_offset (0x608)
+#define ALU_GPU_R1_MSB_offset (0x60C)
+#define ALU_GPU_R2_LSB_offset (0x610)
+#define ALU_GPU_R2_MSB_offset (0x614)
+
+#define ALU_R0_ENCODING   (0x00)
+#define ALU_R1_ENCODING   (0x01)
+#define ALU_SRCA_ENCODING (0x20)
+#define ALU_SRCB_ENCODING (0x21)
+#define ALU_ACCU_ENCODING (0x31)
+
+/**
+ * SECTION:igt_bb_factory
+ * @short_description: Utility functions for creating batch buffers
+ * @title: Batch Buffer Factory
+ * @include: igt.h
+ *
+ * This library implements functions for creating batch buffers which may be
+ * useful to multiple tests.
+ */
+
+static void check_gen_8(int fd)
+{
+   static bool checked = false;
+   if(!checked) {
+   igt_require(intel_gen(intel_get_drm_devid(fd)) >= 8);
+   checked = true;
+   }
+}
+
+static int bb_address_size_dw(int fd)
+{
+   if (intel_gen(intel_get_drm_devid(fd)) >= 8)
+   return 2;
+   else
+   return 1;
+}
+
+static uint32_t 

Re: [Intel-gfx] [PATCH] drm/i915: Wait for vblank in i9xx_disable_crtc() for gen 2 only

[Jani Nikula]

On Tue, 16 Feb 2016, Ander Conselvan de Oliveira 
 wrote:
> The wait for other gens was added in commit 564ed191f5d8 ("drm/i915:
> gmch: fix stuck primary plane due to memory self-refresh mode") since
> that's necessary when disabling cxsr. However, cxsr disabling was later
> moved to intel_pre_disable_primary() in commit 87d4300a7dbc ("drm/i915:
> Move intel_(pre_disable/post_enable)_primary to intel_display.c, and use
> it there.") and that function got its own vblank wait for cxsr in commit
> 262cd2e154c2 ("drm/i915: CHV DDR DVFS support and another watermark
> rewrite"). So remove the extra vblank wait from i9xx_crtc_distable().
>
> Cc: Kalyan Kondapally 
> Signed-off-by: Ander Conselvan de Oliveira 
> 

Cc: fixes or stable? Fixes which commit exactly of all those?

BR,
Jani.


> ---
>  drivers/gpu/drm/i915/intel_display.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 568eefc..3cb9383 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6317,10 +6317,9 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
>   /*
>* On gen2 planes are double buffered but the pipe isn't, so we must
>* wait for planes to fully turn off before disabling the pipe.
> -  * We also need to wait on all gmch platforms because of the
> -  * self-refresh mode constraint explained above.
>*/
> - intel_wait_for_vblank(dev, pipe);
> + if (IS_GEN2(dev))
> + intel_wait_for_vblank(dev, pipe);
>  
>   for_each_encoder_on_crtc(dev, crtc, encoder)
>   encoder->disable(encoder);

-- 
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] ✗ Fi.CI.BAT: failure for drm/i915: avoid dereferencing NULL pointer when failing to pin global ctx

[Patchwork]

== Summary ==

Series 3513v1 drm/i915: avoid dereferencing NULL pointer when failing to pin 
global ctx
http://patchwork.freedesktop.org/api/1.0/series/3513/revisions/1/mbox/

Test gem_ringfill:
Subgroup basic-default-hang:
incomplete -> PASS   (snb-dellxps)
Test gem_sync:
Subgroup basic-bsd:
pass   -> DMESG-FAIL (hsw-brixbox)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (skl-i5k-2)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (skl-i5k-2)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (bsw-nuc-2)
Test pm_rpm:
Subgroup basic-pci-d3-state:
fail   -> PASS   (bdw-nuci7)
dmesg-warn -> PASS   (byt-nuc)
Subgroup basic-rte:
pass   -> DMESG-WARN (byt-nuc) UNSTABLE

bdw-nuci7total:162  pass:152  dwarn:0   dfail:0   fail:0   skip:10 
bdw-ultratotal:165  pass:152  dwarn:0   dfail:0   fail:0   skip:13 
bsw-nuc-2total:165  pass:135  dwarn:1   dfail:0   fail:0   skip:29 
byt-nuc  total:165  pass:140  dwarn:1   dfail:0   fail:0   skip:24 
hsw-brixbox  total:165  pass:150  dwarn:0   dfail:1   fail:0   skip:14 
ilk-hp8440p  total:165  pass:114  dwarn:2   dfail:0   fail:1   skip:48 
skl-i5k-2total:165  pass:149  dwarn:1   dfail:0   fail:0   skip:15 
snb-dellxps  total:165  pass:142  dwarn:0   dfail:0   fail:1   skip:22 
snb-x220ttotal:165  pass:142  dwarn:0   dfail:0   fail:2   skip:21 

Results at /archive/results/CI_IGT_test/Patchwork_1420/

bd0b1a9aa8b7fdb2e06a5cbf1756ef93de2fa3fd drm-intel-nightly: 
2016y-02m-16d-17h-53m-05s UTC integration manifest
095716fa2028d4894855925d6b7fe4f8dc7d9c5e drm/i915: avoid dereferencing NULL 
pointer when failing to pin global ctx

___
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 series starting with [1/2] drm/i915: drop write perm from module params which don't support changing

[Jani Nikula]

On Tue, 16 Feb 2016, Patchwork  wrote:
> == Summary ==
>
> Series 3477v1 Series without cover letter
> http://patchwork.freedesktop.org/api/1.0/series/3477/revisions/1/mbox/
>
> Test gem_ringfill:
> Subgroup basic-default-hang:
> incomplete -> PASS   (snb-dellxps)
> Test kms_flip:
> Subgroup basic-flip-vs-dpms:
> dmesg-warn -> PASS   (ilk-hp8440p) UNSTABLE
> Subgroup basic-flip-vs-modeset:
> pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
> Test kms_pipe_crc_basic:
> Subgroup suspend-read-crc-pipe-a:
> pass   -> INCOMPLETE (hsw-gt2)
> Test pm_rpm:
> Subgroup basic-pci-d3-state:
> dmesg-warn -> PASS   (byt-nuc)
> Subgroup basic-rte:
> pass   -> FAIL   (bdw-ultra)
> pass   -> DMESG-WARN (byt-nuc) UNSTABLE

I don't know what I should make of all this, none of it should have
anything to do with the patches.

BR,
Jani.


>
> bdw-nuci7total:162  pass:152  dwarn:0   dfail:0   fail:0   skip:10 
> bdw-ultratotal:165  pass:151  dwarn:0   dfail:0   fail:1   skip:13 
> bsw-nuc-2total:165  pass:135  dwarn:1   dfail:0   fail:0   skip:29 
> byt-nuc  total:165  pass:140  dwarn:1   dfail:0   fail:0   skip:24 
> hsw-brixbox  total:165  pass:151  dwarn:0   dfail:0   fail:0   skip:14 
> hsw-gt2  total:58   pass:55   dwarn:0   dfail:0   fail:1   skip:1  
> ilk-hp8440p  total:165  pass:114  dwarn:1   dfail:1   fail:1   skip:48 
> ivb-t430stotal:165  pass:150  dwarn:0   dfail:0   fail:1   skip:14 
> skl-i5k-2total:165  pass:150  dwarn:0   dfail:0   fail:0   skip:15 
> snb-dellxps  total:165  pass:142  dwarn:0   dfail:0   fail:1   skip:22 
>
> Results at /archive/results/CI_IGT_test/Patchwork_1412/
>
> 63cbdd1816fd78d404ed004b0f931c497625e0df drm-intel-nightly: 
> 2016y-02m-16d-09h-41m-02s UTC integration manifest
> 67e108f04e5a67306896102538eae3b511091e41 drm/i915: drop unused 
> i915.disable_vtd_wa module parameter
> 95ce71ac3648c5c7d6a783959a60ff5855490c3e drm/i915: drop write perm from 
> module params which don't support changing
>

-- 
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] ✗ Fi.CI.BAT: warning for drm/i915/fbc: enable FBC by default on HSW and BDW

[Patchwork]

== Summary ==

Series 3500v1 drm/i915/fbc: enable FBC by default on HSW and BDW
http://patchwork.freedesktop.org/api/1.0/series/3500/revisions/1/mbox/

Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-rte:
dmesg-warn -> PASS   (bsw-nuc-2)

bsw-nuc-2total:165  pass:134  dwarn:2   dfail:0   fail:0   skip:29 
byt-nuc  total:165  pass:140  dwarn:1   dfail:0   fail:0   skip:24 
ilk-hp8440p  total:165  pass:116  dwarn:0   dfail:0   fail:1   skip:48 

Results at /archive/results/CI_IGT_test/Patchwork_1419/

bd0b1a9aa8b7fdb2e06a5cbf1756ef93de2fa3fd drm-intel-nightly: 
2016y-02m-16d-17h-53m-05s UTC integration manifest
d6b61af1225d72afe8e72e8faf1140435266f8e7 drm/i915/fbc: enable FBC by default on 
HSW and BDW

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Wait for vblank in i9xx_disable_crtc() for gen 2 only

[Patchwork]

== Summary ==

Series 3496v1 drm/i915: Wait for vblank in i9xx_disable_crtc() for gen 2 only
http://patchwork.freedesktop.org/api/1.0/series/3496/revisions/1/mbox/

Test gem_ringfill:
Subgroup basic-default-hang:
incomplete -> PASS   (snb-dellxps)
Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (skl-i5k-2)
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (hsw-gt2)
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (skl-i5k-2)
dmesg-warn -> PASS   (bsw-nuc-2)
Test pm_rpm:
Subgroup basic-pci-d3-state:
fail   -> PASS   (bdw-nuci7)
Subgroup basic-rte:
dmesg-warn -> PASS   (bsw-nuc-2)

bdw-nuci7total:162  pass:152  dwarn:0   dfail:0   fail:0   skip:10 
bdw-ultratotal:165  pass:152  dwarn:0   dfail:0   fail:0   skip:13 
bsw-nuc-2total:165  pass:136  dwarn:0   dfail:0   fail:0   skip:29 
byt-nuc  total:165  pass:140  dwarn:1   dfail:0   fail:0   skip:24 
hsw-brixbox  total:165  pass:151  dwarn:0   dfail:0   fail:0   skip:14 
hsw-gt2  total:127  pass:118  dwarn:0   dfail:0   fail:0   skip:8  
ilk-hp8440p  total:165  pass:115  dwarn:1   dfail:0   fail:1   skip:48 
skl-i5k-2total:165  pass:149  dwarn:1   dfail:0   fail:0   skip:15 
snb-dellxps  total:165  pass:142  dwarn:0   dfail:0   fail:1   skip:22 

Results at /archive/results/CI_IGT_test/Patchwork_1418/

bd0b1a9aa8b7fdb2e06a5cbf1756ef93de2fa3fd drm-intel-nightly: 
2016y-02m-16d-17h-53m-05s UTC integration manifest
3623c71eeb82092a0774b8b959a6a367ffca46c2 drm/i915: Wait for vblank in 
i9xx_disable_crtc() for gen 2 only

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

[Intel-gfx] [RESEND PATCH 5/5] drm/i915: Use atomic state in intel_fb_initial_config.

[Maarten Lankhorst]

This is another step in removing legacy state.

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_fbdev.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index 09840f4380f9..97a91e631915 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -406,8 +406,8 @@ retry:
continue;
}
 
-   encoder = connector->encoder;
-   if (!encoder || WARN_ON(!encoder->crtc)) {
+   encoder = connector->state->best_encoder;
+   if (!encoder || WARN_ON(!connector->state->crtc)) {
if (connector->force > DRM_FORCE_OFF)
goto bail;
 
@@ -420,7 +420,7 @@ retry:
 
num_connectors_enabled++;
 
-   new_crtc = intel_fb_helper_crtc(fb_helper, encoder->crtc);
+   new_crtc = intel_fb_helper_crtc(fb_helper, 
connector->state->crtc);
 
/*
 * Make sure we're not trying to drive multiple connectors
@@ -466,17 +466,22 @@ retry:
 * usually contains. But since our current
 * code puts a mode derived from the post-pfit timings
 * into crtc->mode this works out correctly.
+*
+* This is crtc->mode and not crtc->state->mode for the
+* fastboot check to work correctly. crtc_state->mode 
has
+* I915_MODE_FLAG_INHERITED, which we clear to force 
check
+* state.
 */
DRM_DEBUG_KMS("looking for current mode on connector 
%s\n",
  connector->name);
-   modes[i] = >crtc->mode;
+   modes[i] = >state->crtc->mode;
}
crtcs[i] = new_crtc;
 
DRM_DEBUG_KMS("connector %s on pipe %c [CRTC:%d]: %dx%d%s\n",
  connector->name,
- pipe_name(to_intel_crtc(encoder->crtc)->pipe),
- encoder->crtc->base.id,
+ 
pipe_name(to_intel_crtc(connector->state->crtc)->pipe),
+ connector->state->crtc->base.id,
  modes[i]->hdisplay, modes[i]->vdisplay,
  modes[i]->flags & DRM_MODE_FLAG_INTERLACE ? "i" 
:"");
 
-- 
2.1.0

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

[Intel-gfx] [RESEND PATCH 0/5] Use more atomic state in i915.

[Maarten Lankhorst]

This is a resend to get the results from CI. The patches have been reviewed.

Maarten Lankhorst (5):
  drm/i915: Use atomic state to obtain load detection crtc, v3.
  drm/i915: Use atomic state for load detect in crt.
  drm/i915: Use atomic state in tv load detection.
  drm/i915: Use correct dpms for intel_enable_crt.
  drm/i915: Use atomic state in intel_fb_initial_config.

 drivers/gpu/drm/i915/intel_crt.c |  10 ++-
 drivers/gpu/drm/i915/intel_display.c | 132 ++-
 drivers/gpu/drm/i915/intel_drv.h |   4 +-
 drivers/gpu/drm/i915/intel_fbdev.c   |  17 +++--
 drivers/gpu/drm/i915/intel_tv.c  |  11 ++-
 5 files changed, 73 insertions(+), 101 deletions(-)

-- 
2.1.0

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

[Intel-gfx] [RESEND PATCH 3/5] drm/i915: Use atomic state in tv load detection.

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_tv.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index d21f75bda96e..6745bad5bff0 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -1182,10 +1182,9 @@ static int
 intel_tv_detect_type(struct intel_tv *intel_tv,
  struct drm_connector *connector)
 {
-   struct drm_encoder *encoder = _tv->base.base;
-   struct drm_crtc *crtc = encoder->crtc;
+   struct drm_crtc *crtc = connector->state->crtc;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   struct drm_device *dev = encoder->dev;
+   struct drm_device *dev = connector->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
u32 tv_ctl, save_tv_ctl;
u32 tv_dac, save_tv_dac;
@@ -1234,8 +1233,7 @@ intel_tv_detect_type(struct intel_tv *intel_tv,
I915_WRITE(TV_DAC, tv_dac);
POSTING_READ(TV_DAC);
 
-   intel_wait_for_vblank(intel_tv->base.base.dev,
- to_intel_crtc(intel_tv->base.base.crtc)->pipe);
+   intel_wait_for_vblank(dev, intel_crtc->pipe);
 
type = -1;
tv_dac = I915_READ(TV_DAC);
@@ -1265,8 +1263,7 @@ intel_tv_detect_type(struct intel_tv *intel_tv,
POSTING_READ(TV_CTL);
 
/* For unknown reasons the hw barfs if we don't do this vblank wait. */
-   intel_wait_for_vblank(intel_tv->base.base.dev,
- to_intel_crtc(intel_tv->base.base.crtc)->pipe);
+   intel_wait_for_vblank(dev, intel_crtc->pipe);
 
/* Restore interrupt config */
if (connector->polled & DRM_CONNECTOR_POLL_HPD) {
-- 
2.1.0

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

[Intel-gfx] [RESEND PATCH 1/5] drm/i915: Use atomic state to obtain load detection crtc, v3.

[Maarten Lankhorst]

Instead of restoring dpms and a flag for whether a temp fb is allocated 
duplicate
an atomic state before the new state is committed, and commit it the old state
in intel_release_load_detect_pipe.

Changes since v1:
- Use a real atomic state. (Ville)
Changes since v2:
- Do not preserve shared_dpll any more, no need to do so. (Ville)

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 132 ++-
 drivers/gpu/drm/i915/intel_drv.h |   4 +-
 2 files changed, 54 insertions(+), 82 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index aedddaabc06b..a959f7ca00cb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10334,6 +10334,7 @@ mode_fits_in_fbdev(struct drm_device *dev,
if (obj->base.size < mode->vdisplay * fb->pitches[0])
return NULL;
 
+   drm_framebuffer_reference(fb);
return fb;
 #else
return NULL;
@@ -10389,7 +10390,7 @@ bool intel_get_load_detect_pipe(struct drm_connector 
*connector,
struct drm_device *dev = encoder->dev;
struct drm_framebuffer *fb;
struct drm_mode_config *config = >mode_config;
-   struct drm_atomic_state *state = NULL;
+   struct drm_atomic_state *state = NULL, *restore_state = NULL;
struct drm_connector_state *connector_state;
struct intel_crtc_state *crtc_state;
int ret, i = -1;
@@ -10398,6 +10399,8 @@ bool intel_get_load_detect_pipe(struct drm_connector 
*connector,
  connector->base.id, connector->name,
  encoder->base.id, encoder->name);
 
+   old->restore_state = NULL;
+
 retry:
ret = drm_modeset_lock(>connection_mutex, ctx);
if (ret)
@@ -10414,24 +10417,15 @@ retry:
 */
 
/* See if we already have a CRTC for this connector */
-   if (encoder->crtc) {
-   crtc = encoder->crtc;
+   if (connector->state->crtc) {
+   crtc = connector->state->crtc;
 
ret = drm_modeset_lock(>mutex, ctx);
if (ret)
goto fail;
-   ret = drm_modeset_lock(>primary->mutex, ctx);
-   if (ret)
-   goto fail;
-
-   old->dpms_mode = connector->dpms;
-   old->load_detect_temp = false;
 
/* Make sure the crtc and connector are running */
-   if (connector->dpms != DRM_MODE_DPMS_ON)
-   connector->funcs->dpms(connector, DRM_MODE_DPMS_ON);
-
-   return true;
+   goto found;
}
 
/* Find an unused one (if possible) */
@@ -10439,8 +10433,15 @@ retry:
i++;
if (!(encoder->possible_crtcs & (1 << i)))
continue;
-   if (possible_crtc->state->enable)
+
+   ret = drm_modeset_lock(_crtc->mutex, ctx);
+   if (ret)
+   goto fail;
+
+   if (possible_crtc->state->enable) {
+   drm_modeset_unlock(_crtc->mutex);
continue;
+   }
 
crtc = possible_crtc;
break;
@@ -10454,23 +10455,22 @@ retry:
goto fail;
}
 
-   ret = drm_modeset_lock(>mutex, ctx);
-   if (ret)
-   goto fail;
+found:
+   intel_crtc = to_intel_crtc(crtc);
+
ret = drm_modeset_lock(>primary->mutex, ctx);
if (ret)
goto fail;
 
-   intel_crtc = to_intel_crtc(crtc);
-   old->dpms_mode = connector->dpms;
-   old->load_detect_temp = true;
-   old->release_fb = NULL;
-
state = drm_atomic_state_alloc(dev);
-   if (!state)
-   return false;
+   restore_state = drm_atomic_state_alloc(dev);
+   if (!state || !restore_state) {
+   ret = -ENOMEM;
+   goto fail;
+   }
 
state->acquire_ctx = ctx;
+   restore_state->acquire_ctx = ctx;
 
connector_state = drm_atomic_get_connector_state(state, connector);
if (IS_ERR(connector_state)) {
@@ -10478,7 +10478,9 @@ retry:
goto fail;
}
 
-   connector_state->crtc = crtc;
+   ret = drm_atomic_set_crtc_for_connector(connector_state, crtc);
+   if (ret)
+   goto fail;
 
crtc_state = intel_atomic_get_crtc_state(state, intel_crtc);
if (IS_ERR(crtc_state)) {
@@ -10502,7 +10504,6 @@ retry:
if (fb == NULL) {
DRM_DEBUG_KMS("creating tmp fb for load-detection\n");
fb = intel_framebuffer_create_for_mode(dev, mode, 24, 32);
-   old->release_fb = fb;
} else
DRM_DEBUG_KMS("reusing fbdev for load-detection framebuffer\n");
if (IS_ERR(fb)) {
@@ -10514,15 

[Intel-gfx] [RESEND PATCH 4/5] drm/i915: Use correct dpms for intel_enable_crt.

[Maarten Lankhorst]

With the conversion to atomic only on/off are still supported.
The rest is mapped to one of those, and when enable is called
DPMS_ON should be true.

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_crt.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 1e23e073dee9..ad825427e613 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -206,9 +206,7 @@ static void pch_post_disable_crt(struct intel_encoder 
*encoder)
 
 static void intel_enable_crt(struct intel_encoder *encoder)
 {
-   struct intel_crt *crt = intel_encoder_to_crt(encoder);
-
-   intel_crt_set_dpms(encoder, crt->connector->base.dpms);
+   intel_crt_set_dpms(encoder, DRM_MODE_DPMS_ON);
 }
 
 static enum drm_mode_status
-- 
2.1.0

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

[Intel-gfx] [RESEND PATCH 2/5] drm/i915: Use atomic state for load detect in crt.

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_crt.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index ad5dfabc452e..1e23e073dee9 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -473,11 +473,10 @@ static bool intel_crt_detect_ddc(struct drm_connector 
*connector)
 }
 
 static enum drm_connector_status
-intel_crt_load_detect(struct intel_crt *crt)
+intel_crt_load_detect(struct intel_crt *crt, uint32_t pipe)
 {
struct drm_device *dev = crt->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   uint32_t pipe = to_intel_crtc(crt->base.base.crtc)->pipe;
uint32_t save_bclrpat;
uint32_t save_vtotal;
uint32_t vtotal, vactive;
@@ -646,7 +645,8 @@ intel_crt_detect(struct drm_connector *connector, bool 
force)
if (intel_crt_detect_ddc(connector))
status = connector_status_connected;
else if (INTEL_INFO(dev)->gen < 4)
-   status = intel_crt_load_detect(crt);
+   status = intel_crt_load_detect(crt,
+   to_intel_crtc(connector->state->crtc)->pipe);
else
status = connector_status_unknown;
intel_release_load_detect_pipe(connector, , );
-- 
2.1.0

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