Re: [Intel-gfx] [PATCH 3/5] drm/vblank: Do not update vblank count if interrupts are already disabled.

[Rodrigo Vivi]

On Fri, Jan 12, 2018 at 09:57:05PM +, Dhinakaran Pandiyan wrote:
> Updating vblank counts requires register reads and these reads may not
> return meaningful values if the device was in a low power state after
> vblank interrupts were last disabled. So, update the count only if vblank
> interrupts are enabled. Secondly, this means the registers should be read
> before disabling vblank interrupts.
> 
> v2: Don't check vblank->enabled outside it's lock (Chris)
> 
> Cc: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Michel Dänzer 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/drm_vblank.c | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index f2bf1f5dbaa5..2559d2d7b907 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -347,23 +347,25 @@ void drm_vblank_disable_and_save(struct drm_device 
> *dev, unsigned int pipe)
>   spin_lock_irqsave(>vblank_time_lock, irqflags);
>  
>   /*
> -  * Only disable vblank interrupts if they're enabled. This avoids
> -  * calling the ->disable_vblank() operation in atomic context with the
> -  * hardware potentially runtime suspended.
> +  * Update vblank count and disable vblank interrupts only if the
> +  * interrupts were enabled. This avoids calling the ->disable_vblank()
> +  * operation in atomic context with the hardware potentially runtime
> +  * suspended.
>*/
> - if (vblank->enabled) {
> - __disable_vblank(dev, pipe);
> - vblank->enabled = false;
> - }
> + if (!vblank->enabled)
> + goto out;
>  
>   /*
> -  * Always update the count and timestamp to maintain the
> +  * Update the count and timestamp to maintain the
>* appearance that the counter has been ticking all along until
>* this time. This makes the count account for the entire time
>* between drm_crtc_vblank_on() and drm_crtc_vblank_off().
>*/

I feel that this entire comment can be simply removed now...
The approach looks good and right to me so you can use

Reviewed-by: Rodrigo Vivi 

but please ping Ville to take a look here since he introduced this approach with
4dfd64862ff8 ("drm: Use vblank timestamps to guesstimate how many vblanks were 
missed")

>   drm_update_vblank_count(dev, pipe, false);
> + __disable_vblank(dev, pipe);
> + vblank->enabled = false;
>  
> +out:
>   spin_unlock_irqrestore(>vblank_time_lock, irqflags);
>  }
>  
> -- 
> 2.11.0
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] drm/vblank: Fix data type width for drm_crtc_arm_vblank_event()

[Rodrigo Vivi]

On Fri, Jan 12, 2018 at 09:57:04PM +, Dhinakaran Pandiyan wrote:
> Now that drm_vblank_count() returns all bits of the vblank count, update
> drm_crtc_arm_vblank_event() so that it queues the correct sequence.
> Otherwise, this leads to prolonged waits for a vblank sequence when the
> current count is >=2^32.

This could be probably squashed to the previous patch...
Specially if you apply the Fixes tag.

Anyways, in case you decide to go with 2 patches:

Reviewed-by: Rodrigo Vivi 

> 
> Cc: Keith Packard 
> Cc: Michel Dänzer 
> Cc: Daniel Vetter 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/drm_vblank.c | 4 ++--
>  include/drm/drm_vblank.h | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index 768a8e44d99b..f2bf1f5dbaa5 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -292,11 +292,11 @@ static u64 drm_vblank_count(struct drm_device *dev, 
> unsigned int pipe)
>   * This is mostly useful for hardware that can obtain the scanout position, 
> but
>   * doesn't have a hardware frame counter.
>   */
> -u32 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc)
> +u64 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc)
>  {
>   struct drm_device *dev = crtc->dev;
>   unsigned int pipe = drm_crtc_index(crtc);
> - u32 vblank;
> + u64 vblank;
>   unsigned long flags;
>  
>   WARN_ONCE(drm_debug & DRM_UT_VBL && !dev->driver->get_vblank_timestamp,
> diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
> index 848b463a0af5..a4c3b0a0a197 100644
> --- a/include/drm/drm_vblank.h
> +++ b/include/drm/drm_vblank.h
> @@ -179,7 +179,7 @@ void drm_crtc_wait_one_vblank(struct drm_crtc *crtc);
>  void drm_crtc_vblank_off(struct drm_crtc *crtc);
>  void drm_crtc_vblank_reset(struct drm_crtc *crtc);
>  void drm_crtc_vblank_on(struct drm_crtc *crtc);
> -u32 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc);
> +u64 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc);
>  
>  bool drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,
>  unsigned int pipe, int *max_error,
> -- 
> 2.11.0
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/5] drm/vblank: Fix return type for drm_vblank_count()

[Rodrigo Vivi]

On Fri, Jan 12, 2018 at 09:57:03PM +, Dhinakaran Pandiyan wrote:
> drm_vblank_count() has a u32 type returning what is a 64-bit vblank count.
> The effect of this is when drm_wait_vblank_ioctl() tries to widen the user
> space requested vblank sequence using this clipped 32-bit count(when the
> value is >= 2^32) as reference, the requested sequence remains a 32-bit
> value and gets queued like that. However, the code that checks if the
> requested sequence has passed compares this against the 64-bit vblank
> count.

Worth to mention and probably
Fixes: 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]")

btw, I spotted at least one more place even with the series applied.
32 current_vblank; at drm_mode_page_flip_ioctl...

so, probably worth to do a deeper check down to all paths...

anayway, for this patch:
Reviewed-by: Rodrigo Vivi 

> 
> Cc: Keith Packard 
> Cc: Michel Dänzer 
> Cc: Daniel Vetter 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/drm_vblank.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index 32d9bcf5be7f..768a8e44d99b 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -271,7 +271,7 @@ static void drm_update_vblank_count(struct drm_device 
> *dev, unsigned int pipe,
>   store_vblank(dev, pipe, diff, t_vblank, cur_vblank);
>  }
>  
> -static u32 drm_vblank_count(struct drm_device *dev, unsigned int pipe)
> +static u64 drm_vblank_count(struct drm_device *dev, unsigned int pipe)
>  {
>   struct drm_vblank_crtc *vblank = >vblank[pipe];
>  
> -- 
> 2.11.0
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Estimate and update missed vblanks.

[Rodrigo Vivi]

On Fri, Jan 12, 2018 at 09:57:07PM +, Dhinakaran Pandiyan wrote:
> The frame counter may have got reset between disabling and enabling vblank
> interrupts due to DMC putting the hardware to DC5/6 state if PSR was
> active. The frame counter also could have stalled if PSR is active in cases
> where there is no DMC. The frame counter resetting as a user visible impact
> of screen freezes. Use drm_vblank_restore() to compute missed vblanks
> in the duration for which vblank interrupts are disabled. There's no need
> particularly check if PSR was active in the interrupt disabled duration.
> 
> Enabling vblank interrupts wakes up the hardware from DC5/6 and prevents it
> from going back again as long as the there are pending interrupts. So, we
> don't have to explicity disallow DC5/6 after enabling vblank interrupts
> to keep the counter running.
> 
> Let's not apply this to CHV for now, as enabling interrupts does not
> prevent the hardware from activating PSR and thereby stalling the counter.
> 
> Cc: Rodrigo Vivi 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 3517c6548e2c..db3466ec6faa 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2956,6 +2956,9 @@ static int ironlake_enable_vblank(struct drm_device 
> *dev, unsigned int pipe)
>   ilk_enable_display_irq(dev_priv, bit);
>   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
>  
> + if (HAS_PSR(dev_priv))
> + drm_vblank_restore(dev, pipe);
> +

I don't believe we need this one here.

pre-gen9 platform has psr but not dmc, so the case
where we need to restore the counter doesn't exist.

>   return 0;
>  }
>  
> @@ -2968,6 +2971,9 @@ static int gen8_enable_vblank(struct drm_device *dev, 
> unsigned int pipe)
>   bdw_enable_pipe_irq(dev_priv, pipe, GEN8_PIPE_VBLANK);
>   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
>  
> + if (HAS_PSR(dev_priv))

HAS_PSR(dev_priv) && HAS_CSR(dev_priv)
maybe?
So it gets clear that it is not because PSR that we need to restore
the counter, but also don't do it when not needed.

> + drm_vblank_restore(dev, pipe);
> +
>   return 0;
>  }
>  
> -- 
> 2.11.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 series starting with [v7,1/6] drm/i915/guc: Move GuC WOPCM related code into separate files

[Patchwork]

== Series Details ==

Series: series starting with [v7,1/6] drm/i915/guc: Move GuC WOPCM related code 
into separate files
URL   : https://patchwork.freedesktop.org/series/36748/
State : failure

== Summary ==

Series 36748v1 series starting with [v7,1/6] drm/i915/guc: Move GuC WOPCM 
related code into separate files
https://patchwork.freedesktop.org/api/1.0/series/36748/revisions/1/mbox/

Test core_auth:
Subgroup basic-auth:
pass   -> SKIP   (fi-skl-gvtdvm)
Test core_prop_blob:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Test debugfs_test:
Subgroup read_all_entries:
dmesg-fail -> DMESG-WARN (fi-elk-e7500) fdo#103989
incomplete -> PASS   (fi-snb-2520m) fdo#103713
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6600u)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6700k2)
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> SKIP   (fi-skl-gvtdvm)
pass   -> DMESG-WARN (fi-bxt-dsi)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-kbl-7500u)
pass   -> DMESG-WARN (fi-kbl-7560u)
pass   -> DMESG-WARN (fi-kbl-7567u)
pass   -> DMESG-WARN (fi-kbl-r)
Test drv_getparams_basic:
Subgroup basic-eu-total:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-subslice-total:
pass   -> SKIP   (fi-skl-gvtdvm)
Test drv_hangman:
Subgroup error-state-basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_basic:
Subgroup bad-close:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup create-close:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup create-fd-close:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_busy:
Subgroup basic-busy-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-hang-default:
pass   -> SKIP   (fi-skl-gvtdvm) fdo#104108 +6
Test gem_close_race:
Subgroup basic-process:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-threads:
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6600u)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6700k2)
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> SKIP   (fi-skl-gvtdvm)
pass   -> DMESG-WARN (fi-bxt-dsi)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-kbl-7500u)
pass   -> DMESG-WARN (fi-kbl-7560u)
pass   -> DMESG-WARN (fi-kbl-7567u)
pass   -> DMESG-WARN (fi-kbl-r)
Test gem_cpu_reloc:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_cs_tlb:
Subgroup basic-default:
pass   -> DMESG-WARN (fi-skl-6600u)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> SKIP   (fi-skl-gvtdvm)
pass   -> DMESG-WARN (fi-bxt-dsi)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-kbl-7567u)
Test gem_ctx_create:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-files:
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6600u)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6700k2)
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> SKIP   (fi-skl-gvtdvm)
pass   -> DMESG-WARN (fi-bxt-dsi)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-kbl-7500u)
pass   -> DMESG-WARN (fi-kbl-7560u)
pass   -> DMESG-WARN (fi-kbl-7567u)
pass   -> DMESG-WARN (fi-kbl-r)
Test gem_ctx_exec:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_param:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_switch:
Subgroup basic-default:
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6600u)
WARNING: Long output truncated

d68aaa919e474b82f41514e5c3b87cb6dfe86f57 drm-tip: 2018y-01m-19d-05h-41m-44s UTC 
integration manifest
26a52553d057 HAX Enable GuC 

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Nuke intel_dp->channel_eq_status

[Rodrigo Vivi]

On Wed, Jan 17, 2018 at 07:21:48PM +, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> intel_dp->channel_eq_status is used in exactly one function, and we
> don't need it to persist between calls. So just go back to using a
> local variable instead.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/intel_dp_link_training.c | 6 +++---
>  drivers/gpu/drm/i915/intel_drv.h  | 1 -
>  2 files changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 05907fa8a553..1314f5d87d7d 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -248,6 +248,7 @@ intel_dp_link_training_channel_equalization(struct 
> intel_dp *intel_dp)
>   int tries;
>   u32 training_pattern;
>   uint8_t link_status[DP_LINK_STATUS_SIZE];
> + bool channel_eq = false;
>  
>   training_pattern = intel_dp_training_pattern(intel_dp);
>  
> @@ -259,7 +260,6 @@ intel_dp_link_training_channel_equalization(struct 
> intel_dp *intel_dp)
>   return false;
>   }
>  
> - intel_dp->channel_eq_status = false;
>   for (tries = 0; tries < 5; tries++) {
>  
>   drm_dp_link_train_channel_eq_delay(intel_dp->dpcd);
> @@ -279,7 +279,7 @@ intel_dp_link_training_channel_equalization(struct 
> intel_dp *intel_dp)
>  
>   if (drm_dp_channel_eq_ok(link_status,
>intel_dp->lane_count)) {
> - intel_dp->channel_eq_status = true;
> + channel_eq = true;
>   DRM_DEBUG_KMS("Channel EQ done. DP Training "
> "successful\n");
>   break;
> @@ -301,7 +301,7 @@ intel_dp_link_training_channel_equalization(struct 
> intel_dp *intel_dp)
>  
>   intel_dp_set_idle_link_train(intel_dp);
>  
> - return intel_dp->channel_eq_status;
> + return channel_eq;
>  
>  }
>  
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index ddf28a442cd7..1d018869ad02 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1045,7 +1045,6 @@ struct intel_dp {
>   bool link_mst;
>   bool has_audio;
>   bool detect_done;
> - bool channel_eq_status;
>   bool reset_link_params;
>   uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
>   uint8_t psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
> -- 
> 2.13.6
> 
> ___
> 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] ✗ Fi.CI.IGT: warning for drm/i915: Use the engine name directly in the error_state file (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Use the engine name directly in the error_state file (rev3)
URL   : https://patchwork.freedesktop.org/series/36215/
State : warning

== Summary ==

Test kms_frontbuffer_tracking:
Subgroup fbc-2p-scndscrn-pri-shrfb-draw-mmap-cpu:
pass   -> DMESG-WARN (shard-hsw)
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
skip   -> FAIL   (shard-snb) fdo#101623 +1
Test kms_flip:
Subgroup vblank-vs-suspend:
pass   -> FAIL   (shard-snb) fdo#102365
Subgroup vblank-vs-dpms-suspend:
pass   -> INCOMPLETE (shard-hsw) fdo#103540
Subgroup flip-vs-modeset-vs-hang:
pass   -> DMESG-WARN (shard-snb) fdo#103821
Test drv_suspend:
Subgroup sysfs-reader:
pass   -> SKIP   (shard-snb)
Test kms_setmode:
Subgroup invalid-clone-single-crtc-stealing:
warn   -> PASS   (shard-snb)
Test kms_chv_cursor_fail:
Subgroup pipe-a-64x64-left-edge:
skip   -> PASS   (shard-snb)

fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821

shard-hswtotal:2685 pass:1686 dwarn:2   dfail:0   fail:10  skip:985 
time:14788s
shard-snbtotal:2753 pass:1315 dwarn:2   dfail:0   fail:12  skip:1424 
time:7909s
Blacklisted hosts:
shard-apltotal:2731 pass:1692 dwarn:1   dfail:0   fail:22  skip:1015 
time:13607s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7714/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/4] drm/i915: II stage HDCP auth for repeater only

[C, Ramalingam]

> -Original Message-
> From: Sean Paul [mailto:seanp...@chromium.org]
> Sent: Friday, January 19, 2018 3:54 AM
> To: C, Ramalingam 
> Cc: intel-gfx@lists.freedesktop.org; seanp...@chromium.org;
> daniel.vet...@ffwll.ch; Vivi, Rodrigo ; Sharma,
> Shashank 
> Subject: Re: [PATCH 2/4] drm/i915: II stage HDCP auth for repeater only
> 
> On Thu, Jan 18, 2018 at 11:18:06AM +0530, Ramalingam C wrote:
> > Second stage of HDCP authentication required only if the HDCP sink is
> > a repeater.
> >
> > This patch imposes above condition on second stage HDCP authentication.
> 
> Hi Ram,
> This is already enforced in intel_hdcp_auth_downstream()

I am not able to locate any check for repeater capability at start of 
downstream auth.

I am not sure whether you are referring to number of downstream device count 
check.
That is valid after poll for ksv_fifo ready. We don't want to wait for 5Sec 
timeout in poll to detect the repeater cap.

And since the caller is handy with the flag for repeater cap, it is best to 
decide on the call for downstream auth itself.

Thanks
--Ram
> 
> Thanks,
> Sean
> 
> >
> > Signed-off-by: Ramalingam C 
> > ---
> >  drivers/gpu/drm/i915/intel_hdcp.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> > b/drivers/gpu/drm/i915/intel_hdcp.c
> > index 6ce6559897a6..b48c72cd0906 100644
> > --- a/drivers/gpu/drm/i915/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> > @@ -493,7 +493,10 @@ static int intel_hdcp_auth(struct intel_digital_port
> *intel_dig_port,
> >  * on those as well.
> >  */
> >
> > -   return intel_hdcp_auth_downstream(intel_dig_port, shim);
> > +   if (repeater_present)
> > +   return intel_hdcp_auth_downstream(intel_dig_port, shim);
> > +
> > +   return 0;
> >  }
> >
> >  static
> > --
> > 2.7.4
> >
> 
> --
> Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/4] HDCP1.4 implementation enhancement

[Sean Paul]

On Wed, Jan 17, 2018 at 9:48 PM, Ramalingam C  wrote:
> This series extends the HDCP1.4 support for few more intel platforms.
> And also addresses few gaps found in the base HDCP1.4 implementation w.r.t
> HDCP1.4 specification.
>

Thanks for the patches, Ram. I've applied them with a couple of
checkpatch fixes around alignment + an extra line.

Sean


> Ramalingam C (4):
>   drm/i915: Extending HDCP for HSW, BDW and BXT+
>   drm/i915: II stage HDCP auth for repeater only
>   drm/i915: Start repeater auth on READY/CP_IRQ
>   drm/i915: Check for downstream topology errors
>
>  drivers/gpu/drm/i915/i915_reg.h   |  1 +
>  drivers/gpu/drm/i915/intel_dp.c   |  2 +-
>  drivers/gpu/drm/i915/intel_drv.h  |  1 +
>  drivers/gpu/drm/i915/intel_hdcp.c | 65 
> ++-
>  drivers/gpu/drm/i915/intel_hdmi.c |  3 +-
>  include/drm/drm_hdcp.h|  2 ++
>  6 files changed, 57 insertions(+), 17 deletions(-)
>
> --
> 2.7.4
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v7 2/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

[Jackie Li]

GuC related exported functions should start with "intel_guc_"
prefix and pass intel_guc as the first parameter since its guc
related. Current guc_ggtt_offset() failed to follow this code
convention.

This patch renames the guc_ggtt_offset to intel_guc_ggtt_offset
and updates the related code to pass intel_guc pointer to
this function call. so that we have a unified coding style for
GuC code.

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/intel_guc.c| 12 +++-
 drivers/gpu/drm/i915/intel_guc.h| 10 --
 drivers/gpu/drm/i915/intel_guc_ads.c| 25 +
 drivers/gpu/drm/i915/intel_guc_ct.c |  5 +++--
 drivers/gpu/drm/i915/intel_guc_fw.c |  2 +-
 drivers/gpu/drm/i915/intel_guc_log.c|  2 +-
 drivers/gpu/drm/i915/intel_guc_submission.c | 10 +-
 drivers/gpu/drm/i915/intel_huc.c|  6 --
 8 files changed, 42 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index b8b6d4a..e70885b 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -264,8 +264,10 @@ void intel_guc_init_params(struct intel_guc *guc)
 
/* If GuC submission is enabled, set up additional parameters here */
if (USES_GUC_SUBMISSION(dev_priv)) {
-   u32 ads = guc_ggtt_offset(guc->ads_vma) >> PAGE_SHIFT;
-   u32 pgs = guc_ggtt_offset(dev_priv->guc.stage_desc_pool);
+   u32 ads = intel_guc_ggtt_offset(guc,
+   guc->ads_vma) >> PAGE_SHIFT;
+   u32 pgs = intel_guc_ggtt_offset(guc,
+   dev_priv->guc.stage_desc_pool);
u32 ctx_in_16 = GUC_MAX_STAGE_DESCRIPTORS / 16;
 
params[GUC_CTL_DEBUG] |= ads << GUC_ADS_ADDR_SHIFT;
@@ -413,7 +415,7 @@ int intel_guc_suspend(struct drm_i915_private *dev_priv)
data[0] = INTEL_GUC_ACTION_ENTER_S_STATE;
/* any value greater than GUC_POWER_D0 */
data[1] = GUC_POWER_D1;
-   data[2] = guc_ggtt_offset(guc->shared_data);
+   data[2] = intel_guc_ggtt_offset(guc, guc->shared_data);
 
return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
@@ -436,7 +438,7 @@ int intel_guc_reset_engine(struct intel_guc *guc,
data[3] = 0;
data[4] = 0;
data[5] = guc->execbuf_client->stage_id;
-   data[6] = guc_ggtt_offset(guc->shared_data);
+   data[6] = intel_guc_ggtt_offset(guc, guc->shared_data);
 
return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
@@ -458,7 +460,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv)
 
data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
data[1] = GUC_POWER_D0;
-   data[2] = guc_ggtt_offset(guc->shared_data);
+   data[2] = intel_guc_ggtt_offset(guc, guc->shared_data);
 
return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 9e0a97e..b7e2a18 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -101,13 +101,19 @@ static inline void intel_guc_notify(struct intel_guc *guc)
guc->notify(guc);
 }
 
-/*
+/* intel_guc_ggtt_offset() - Get the GGTT offset of @vma.
+ * @guc: intel guc.
+ * @vma: i915 graphics virtual memory area.
+ *
  * GuC does not allow any gfx GGTT address that falls into range [0, 
WOPCM_TOP),
  * which is reserved for Boot ROM, SRAM and WOPCM. Currently this top address 
is
  * 512K. In order to exclude 0-512K address space from GGTT, all gfx objects
  * used by GuC is pinned with PIN_OFFSET_BIAS along with size of WOPCM.
+ *
+ * Return: GGTT offset that meets the GuC gfx address requirement.
  */
-static inline u32 guc_ggtt_offset(struct i915_vma *vma)
+static inline u32 intel_guc_ggtt_offset(struct intel_guc *guc,
+   struct i915_vma *vma)
 {
u32 offset = i915_ggtt_offset(vma);
 
diff --git a/drivers/gpu/drm/i915/intel_guc_ads.c 
b/drivers/gpu/drm/i915/intel_guc_ads.c
index ac62753..7215594 100644
--- a/drivers/gpu/drm/i915/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/intel_guc_ads.c
@@ -113,17 +113,6 @@ int intel_guc_ads_create(struct intel_guc *guc)
blob->reg_state.white_list[engine->guc_id].count = 0;
}
 
-   /*
-* The GuC requires a "Golden Context" when it reinitialises
-* engines after a reset. Here we use the Render ring default
-* context, which must already exist and be pinned in the GGTT,
-* so its address won't change after we've told the GuC where
-* to find it. Note that we have to skip our header (1 page),
-* because our GuC shared data 

[Intel-gfx] [PATCH v7 1/6] drm/i915/guc: Move GuC WOPCM related code into separate files

[Jackie Li]

intel_guc_reg.h should only include definition for GuC registers
and related register bits. GuC WOPCM related values should not
be defined in intel_guc_reg.h

This patch creates a better file structure by moving GuC WOPCM
related definitions int to a new header intel_guc_wopcm.h
and moving GuC WOPCM related functions to a new source file
intel_guc_wopcm.c

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/Makefile  |  1 +
 drivers/gpu/drm/i915/intel_guc.c   | 11 
 drivers/gpu/drm/i915/intel_guc.h   |  2 +-
 drivers/gpu/drm/i915/intel_guc_reg.h   |  4 ---
 drivers/gpu/drm/i915/intel_guc_wopcm.c | 47 ++
 drivers/gpu/drm/i915/intel_guc_wopcm.h | 39 
 drivers/gpu/drm/i915/intel_uc.c|  2 +-
 drivers/gpu/drm/i915/intel_uc_fw.c |  2 +-
 8 files changed, 90 insertions(+), 18 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_guc_wopcm.c
 create mode 100644 drivers/gpu/drm/i915/intel_guc_wopcm.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 3bddd8a..1dc9988 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -88,6 +88,7 @@ i915-y += intel_uc.o \
  intel_guc_fw.o \
  intel_guc_log.o \
  intel_guc_submission.o \
+ intel_guc_wopcm.o \
  intel_huc.o
 
 # autogenerated null render state
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index ea30e7c..b8b6d4a 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -504,14 +504,3 @@ struct i915_vma *intel_guc_allocate_vma(struct intel_guc 
*guc, u32 size)
i915_gem_object_put(obj);
return vma;
 }
-
-u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv)
-{
-   u32 wopcm_size = GUC_WOPCM_TOP;
-
-   /* On BXT, the top of WOPCM is reserved for RC6 context */
-   if (IS_GEN9_LP(dev_priv))
-   wopcm_size -= BXT_GUC_WOPCM_RC6_RESERVED;
-
-   return wopcm_size;
-}
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 52856a9..9e0a97e 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -31,6 +31,7 @@
 #include "intel_guc_ct.h"
 #include "intel_guc_log.h"
 #include "intel_guc_reg.h"
+#include "intel_guc_wopcm.h"
 #include "intel_uc_fw.h"
 #include "i915_vma.h"
 
@@ -130,6 +131,5 @@ int intel_guc_auth_huc(struct intel_guc *guc, u32 
rsa_offset);
 int intel_guc_suspend(struct drm_i915_private *dev_priv);
 int intel_guc_resume(struct drm_i915_private *dev_priv);
 struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size);
-u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv);
 
 #endif
diff --git a/drivers/gpu/drm/i915/intel_guc_reg.h 
b/drivers/gpu/drm/i915/intel_guc_reg.h
index 19a9247..1f52fb8 100644
--- a/drivers/gpu/drm/i915/intel_guc_reg.h
+++ b/drivers/gpu/drm/i915/intel_guc_reg.h
@@ -68,7 +68,6 @@
 #define DMA_GUC_WOPCM_OFFSET   _MMIO(0xc340)
 #define   HUC_LOADING_AGENT_VCR  (0<<1)
 #define   HUC_LOADING_AGENT_GUC  (1<<1)
-#define   GUC_WOPCM_OFFSET_VALUE 0x8   /* 512KB */
 #define GUC_MAX_IDLE_COUNT _MMIO(0xC3E4)
 
 #define HUC_STATUS2 _MMIO(0xD3B0)
@@ -76,9 +75,6 @@
 
 /* Defines WOPCM space available to GuC firmware */
 #define GUC_WOPCM_SIZE _MMIO(0xc050)
-/* GuC addresses below GUC_WOPCM_TOP don't map through the GTT */
-#define   GUC_WOPCM_TOP  (0x80 << 12)  /* 512KB */
-#define   BXT_GUC_WOPCM_RC6_RESERVED (0x10 << 12)  /* 64KB  */
 
 /* GuC addresses above GUC_GGTT_TOP also don't map through the GTT */
 #define GUC_GGTT_TOP   0xFEE0
diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.c 
b/drivers/gpu/drm/i915/intel_guc_wopcm.c
new file mode 100644
index 000..87643a0
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c
@@ -0,0 +1,47 @@
+/*
+ * Copyright © 2017 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, 

[Intel-gfx] [PATCH v7 4/6] drm/i915/guc: Add WOPCM partitioning support for CNL

[Jackie Li]

CNL has different WOPCM size and hardware restriction on GuC
WOPCM size.

This patch returns the correct WOPCM reserved size on CNL and
adds the GuC WOPCM size check for CNL.

v6:
 - Extended HuC FW size check against GuC WOPCM size to all
   Gen9 and CNL A0 platforms

v7:
 - Fixed patch format issues

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: John Spotswood 
Cc: Jeff McGee 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/intel_guc_wopcm.c | 23 ++-
 drivers/gpu/drm/i915/intel_guc_wopcm.h |  4 
 2 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.c 
b/drivers/gpu/drm/i915/intel_guc_wopcm.c
index 0532714..ed3096c 100644
--- a/drivers/gpu/drm/i915/intel_guc_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c
@@ -33,6 +33,24 @@ static inline u32 guc_reserved_wopcm_size(struct intel_guc 
*guc)
if (IS_GEN9_LP(i915))
return BXT_WOPCM_RC6_RESERVED;
 
+   if (IS_GEN10(i915))
+   return CNL_WOPCM_RESERVED;
+
+   return 0;
+}
+
+/*
+ * On Gen9 & CNL A0, hardware requires GuC size to be larger than or equal to
+ * HuC kernel size.
+ */
+static inline int wopcm_huc_size_check(struct drm_i915_private *i915)
+{
+   struct intel_guc_wopcm *wopcm = >guc.wopcm;
+   u32 huc_size = intel_uc_fw_get_size(>huc.fw);
+
+   if (unlikely(wopcm->size - GUC_WOPCM_RESERVED < huc_size))
+   return -E2BIG;
+
return 0;
 }
 
@@ -55,7 +73,7 @@ static inline int gen9_wocpm_size_check(struct 
drm_i915_private *i915)
if (unlikely(delta < GEN9_GUC_WOPCM_DELTA))
return -E2BIG;
 
-   return 0;
+   return wopcm_huc_size_check(i915);
 }
 
 static inline int guc_wopcm_size_check(struct intel_guc *guc)
@@ -65,6 +83,9 @@ static inline int guc_wopcm_size_check(struct intel_guc *guc)
if (IS_GEN9(i915))
return gen9_wocpm_size_check(i915);
 
+   if (IS_CNL_REVID(i915, CNL_REVID_A0, CNL_REVID_A0))
+   return wopcm_huc_size_check(i915);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.h 
b/drivers/gpu/drm/i915/intel_guc_wopcm.h
index 352cf3d..5306175 100644
--- a/drivers/gpu/drm/i915/intel_guc_wopcm.h
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.h
@@ -37,8 +37,12 @@ struct intel_guc;
 #define WOPCM_OFFSET_ALIGNMENT (0x4000)
 /* 8KB stack reserved for GuC FW*/
 #define GUC_WOPCM_STACK_RESERVED   (0x2000)
+/* 16KB reserved at the beginning of GuC WOPCM */
+#define GUC_WOPCM_RESERVED (0x4000)
 /* 24KB WOPCM reserved for RC6 CTX on BXT */
 #define BXT_WOPCM_RC6_RESERVED (0x6000)
+/* 36KB WOPCM reserved on CNL */
+#define CNL_WOPCM_RESERVED (0x9000)
 
 #define GEN9_GUC_WOPCM_DELTA   4
 #define GEN9_GUC_WOPCM_OFFSET  (0x24000)
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH 1/5] drm/vblank: Fix return type for drm_vblank_count()

[Pandiyan, Dhinakaran]

ping for review.

Let me know if there's anything that needs to be done, thanks!


On Fri, 2018-01-12 at 13:57 -0800, Dhinakaran Pandiyan wrote:
> drm_vblank_count() has a u32 type returning what is a 64-bit vblank count.
> The effect of this is when drm_wait_vblank_ioctl() tries to widen the user
> space requested vblank sequence using this clipped 32-bit count(when the
> value is >= 2^32) as reference, the requested sequence remains a 32-bit
> value and gets queued like that. However, the code that checks if the
> requested sequence has passed compares this against the 64-bit vblank
> count.
> 
> Cc: Keith Packard 
> Cc: Michel Dänzer 
> Cc: Daniel Vetter 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/drm_vblank.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index 32d9bcf5be7f..768a8e44d99b 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -271,7 +271,7 @@ static void drm_update_vblank_count(struct drm_device 
> *dev, unsigned int pipe,
>   store_vblank(dev, pipe, diff, t_vblank, cur_vblank);
>  }
>  
> -static u32 drm_vblank_count(struct drm_device *dev, unsigned int pipe)
> +static u64 drm_vblank_count(struct drm_device *dev, unsigned int pipe)
>  {
>   struct drm_vblank_crtc *vblank = >vblank[pipe];
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v7 5/6] drm/i915/guc: Check the locking status of GuC WOPCM registers

[Jackie Li]

GuC WOPCM registers are write-once registers. Current driver code
accesses these registers without checking the accessibility to these
registers, this will lead unpredictable driver behaviors if these
registers were touch by other components (such as faulty BIOS code).

This patch moves the GuC WOPCM register updating operations into
intel_guc_wopcm.c and adds checks before and after the write to GuC
WOPCM registers to make sure the driver is in a known state before
and after writing to these write-once registers.

v6:
 - Made sure module reloading won't bug the kernel while doing
   locking status checking

v7:
 - Fixed patch format issues

Cc: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/intel_guc.h   |  2 +-
 drivers/gpu/drm/i915/intel_guc_reg.h   |  4 +-
 drivers/gpu/drm/i915/intel_guc_wopcm.c | 91 --
 drivers/gpu/drm/i915/intel_guc_wopcm.h | 14 +-
 drivers/gpu/drm/i915/intel_uc.c|  5 +-
 5 files changed, 106 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index ea35911..7ed0c17 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -118,7 +118,7 @@ static inline u32 intel_guc_ggtt_offset(struct intel_guc 
*guc,
 {
u32 offset = i915_ggtt_offset(vma);
 
-   GEM_BUG_ON(!guc->wopcm.valid);
+   GEM_BUG_ON(!(guc->wopcm.flags & INTEL_GUC_WOPCM_VALID));
GEM_BUG_ON(offset < guc->wopcm.top);
GEM_BUG_ON(range_overflows_t(u64, offset, vma->size, GUC_GGTT_TOP));
 
diff --git a/drivers/gpu/drm/i915/intel_guc_reg.h 
b/drivers/gpu/drm/i915/intel_guc_reg.h
index 9109be7..ee2b33ba 100644
--- a/drivers/gpu/drm/i915/intel_guc_reg.h
+++ b/drivers/gpu/drm/i915/intel_guc_reg.h
@@ -66,6 +66,7 @@
 #define   UOS_MOVE   (1<<4)
 #define   START_DMA  (1<<0)
 #define DMA_GUC_WOPCM_OFFSET   _MMIO(0xc340)
+#define   DMA_GUC_WOPCM_OFFSET_MASK  (0xc000)
 #define   HUC_LOADING_AGENT_VCR  (0<<1)
 #define   HUC_LOADING_AGENT_GUC  (1<<1)
 #define GUC_MAX_IDLE_COUNT _MMIO(0xC3E4)
@@ -75,7 +76,8 @@
 
 /* Defines WOPCM space available to GuC firmware */
 #define GUC_WOPCM_SIZE _MMIO(0xc050)
-#define GUC_WOPCM_SIZE_MASK(0xf000)
+#define   GUC_WOPCM_SIZE_MASK(0xf000)
+#define GUC_WOPCM_REG_LOCKED   BIT(0)
 
 /* GuC addresses above GUC_GGTT_TOP also don't map through the GTT */
 #define GUC_GGTT_TOP   0xFEE0
diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.c 
b/drivers/gpu/drm/i915/intel_guc_wopcm.c
index ed3096c..236fc32 100644
--- a/drivers/gpu/drm/i915/intel_guc_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c
@@ -89,6 +89,53 @@ static inline int guc_wopcm_size_check(struct intel_guc *guc)
return 0;
 }
 
+static inline bool __reg_locked(struct drm_i915_private *dev_priv,
+   i915_reg_t reg)
+{
+   return !!(I915_READ(reg) & GUC_WOPCM_REG_LOCKED);
+}
+
+static inline bool guc_wopcm_locked(struct intel_guc *guc)
+{
+   struct drm_i915_private *i915 = guc_to_i915(guc);
+   bool size_reg_locked = __reg_locked(i915, GUC_WOPCM_SIZE);
+   bool offset_reg_locked = __reg_locked(i915, DMA_GUC_WOPCM_OFFSET);
+
+   return size_reg_locked && offset_reg_locked;
+}
+
+static inline void guc_wopcm_hw_update(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
+   /* GuC WOPCM registers should be unlocked at this point. */
+   GEM_BUG_ON(__reg_locked(dev_priv, GUC_WOPCM_SIZE));
+   GEM_BUG_ON(__reg_locked(dev_priv, DMA_GUC_WOPCM_OFFSET));
+
+   I915_WRITE(GUC_WOPCM_SIZE, guc->wopcm.size);
+   I915_WRITE(DMA_GUC_WOPCM_OFFSET,
+  guc->wopcm.offset | HUC_LOADING_AGENT_GUC);
+
+   GEM_BUG_ON(!__reg_locked(dev_priv, GUC_WOPCM_SIZE));
+   GEM_BUG_ON(!__reg_locked(dev_priv, DMA_GUC_WOPCM_OFFSET));
+}
+
+static inline bool guc_wopcm_regs_valid(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   u32 size, offset;
+   bool guc_loads_huc;
+
+   size = I915_READ(GUC_WOPCM_SIZE) & GUC_WOPCM_SIZE_MASK;
+   offset = I915_READ(DMA_GUC_WOPCM_OFFSET);
+
+   guc_loads_huc = !!(offset & HUC_LOADING_AGENT_GUC);
+   offset &= DMA_GUC_WOPCM_OFFSET_MASK;
+
+   return guc_loads_huc && (size == guc->wopcm.size) &&
+   (offset == guc->wopcm.offset);
+}
+
 /*
  * intel_guc_wopcm_init() - Initialize the GuC WOPCM partition.
  * @guc: intel guc.
@@ -107,8 +154,7 @@ int intel_guc_wopcm_init(struct intel_guc *guc, u32 
guc_fw_size,
u32 offset, size, top;
int err;
 
-   if (guc->wopcm.valid)
-   return 0;
+   

[Intel-gfx] [PATCH v7 3/6] drm/i915/guc: Implement dynamic GuC WOPCM offset and size

[Jackie Li]

Hardware may have specific restrictions on GuC WOPCM size
versus HuC firmware size. With static GuC WOPCM size,
there's no way to adjust the GuC WOPCM partition size based on
the actual HuC firmware size, so that GuC/HuC loading failure
would occur even if there was enough WOPCM space for both
GuC and HuC firmware.

This patch enables the dynamic calculation of the GuC WOPCM
aperture size used by GuC and HuC firmware. GuC WOPCM offset is
set to HuC size + reserved WOPCM size. GuC WOPCM size is set to
total WOPCM size - GuC WOPCM offset - RC6CTX size. In this case,
GuC WOPCM offset will be updated based on the size of HuC firmware
while GuC WOPCM size will be set to use all the remaining WOPCM space.

v2:
 - Removed intel_wopcm_init (Ville/Sagar/Joonas)
 - Renamed and Moved the intel_wopcm_partition into intel_guc (Sagar)
 - Removed unnecessary function calls (Joonas)
 - Init GuC WOPCM partition as soon as firmware fetching is completed

v3:
 - Fixed indentation issues (Chris)
 - Removed layering violation code (Chris/Michal)
 - Created separat files for GuC wopcm code  (Michal)
 - Used inline function to avoid code duplication (Michal)

v4:
 - Preset the GuC WOPCM top during early GuC init (Chris)
 - Fail intel_uc_init_hw() as soon as GuC WOPCM partitioning failed

v5:
 - Moved GuC DMA WOPCM register updating code into intel_guc_wopcm.c
 - Took care of the locking status before writing to GuC DMA
   Write-Once registers. (Joonas)

v6:
 - Made sure the GuC WOPCM size to be multiple of 4K (4K aligned)

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Sujaritha Sundaresan 
Cc: Daniele Ceraolo Spurio 
Cc: John Spotswood 
Cc: Oscar Mateo 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/i915_gem_context.c |   9 +--
 drivers/gpu/drm/i915/intel_guc.c|   5 +-
 drivers/gpu/drm/i915/intel_guc.h|  12 ++--
 drivers/gpu/drm/i915/intel_guc_reg.h|   1 +
 drivers/gpu/drm/i915/intel_guc_wopcm.c  | 108 +---
 drivers/gpu/drm/i915/intel_guc_wopcm.h  |  40 ++--
 drivers/gpu/drm/i915/intel_huc.c|   2 +-
 drivers/gpu/drm/i915/intel_uc.c |  11 +++-
 drivers/gpu/drm/i915/intel_uc_fw.c  |  11 +++-
 drivers/gpu/drm/i915/intel_uc_fw.h  |  16 +
 10 files changed, 183 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 648e753..b485794 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -312,12 +312,13 @@ __create_hw_context(struct drm_i915_private *dev_priv,
ctx->desc_template =
default_desc_template(dev_priv, dev_priv->mm.aliasing_ppgtt);
 
-   /* GuC requires the ring to be placed above GUC_WOPCM_TOP. If GuC is not
-* present or not in use we still need a small bias as ring wraparound
-* at offset 0 sometimes hangs. No idea why.
+   /*
+* GuC requires the ring to be placed above GuC WOPCM top. If GuC is not
+-   * present or not in use we still need a small bias as ring wraparound
+-   * at offset 0 sometimes hangs. No idea why.
 */
if (USES_GUC(dev_priv))
-   ctx->ggtt_offset_bias = GUC_WOPCM_TOP;
+   ctx->ggtt_offset_bias = dev_priv->guc.wopcm.top;
else
ctx->ggtt_offset_bias = I915_GTT_PAGE_SIZE;
 
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index e70885b..3521beb 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -64,6 +64,7 @@ void intel_guc_init_early(struct intel_guc *guc)
 {
intel_guc_fw_init_early(guc);
intel_guc_ct_init_early(>ct);
+   intel_guc_wopcm_init_early(>wopcm);
 
mutex_init(>send_mutex);
guc->send = intel_guc_send_nop;
@@ -473,7 +474,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv)
  * This is a wrapper to create an object for use with the GuC. In order to
  * use it inside the GuC, an object needs to be pinned lifetime, so we allocate
  * both some backing storage and a range inside the Global GTT. We must pin
- * it in the GGTT somewhere other than than [0, GUC_WOPCM_TOP) because that
+ * it in the GGTT somewhere other than than [0, GuC WOPCM top) because that
  * range is reserved inside GuC.
  *
  * Return: A i915_vma if successful, otherwise an ERR_PTR.
@@ -494,7 +495,7 @@ struct i915_vma *intel_guc_allocate_vma(struct intel_guc 
*guc, u32 size)
goto err;
 
ret = i915_vma_pin(vma, 0, PAGE_SIZE,
-  PIN_GLOBAL | PIN_OFFSET_BIAS | GUC_WOPCM_TOP);
+  PIN_GLOBAL | PIN_OFFSET_BIAS | 

[Intel-gfx] ✗ Fi.CI.IGT: warning for perf: Allow fine-grained PMU access control

[Patchwork]

== Series Details ==

Series: perf: Allow fine-grained PMU access control
URL   : https://patchwork.freedesktop.org/series/36723/
State : warning

== Summary ==

Test kms_flip:
Subgroup vblank-vs-modeset-suspend-interruptible:
pass   -> SKIP   (shard-hsw) fdo#103540
Test drv_suspend:
Subgroup sysfs-reader:
pass   -> SKIP   (shard-hsw)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
pass   -> FAIL   (shard-snb) fdo#101623
Test gem_exec_suspend:
Subgroup basic-s3:
skip   -> PASS   (shard-snb) fdo#103880
Test gem_eio:
Subgroup in-flight:
pass   -> DMESG-WARN (shard-snb) fdo#104058
Test perf:
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252

fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103880 https://bugs.freedesktop.org/show_bug.cgi?id=103880
fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-hswtotal:2676 pass:1678 dwarn:1   dfail:0   fail:10  skip:986 
time:14901s
shard-snbtotal:2753 pass:1317 dwarn:2   dfail:0   fail:11  skip:1423 
time:7963s
Blacklisted hosts:
shard-apltotal:2753 pass:1714 dwarn:1   dfail:0   fail:23  skip:1015 
time:14083s
shard-kbltotal:2745 pass:1831 dwarn:1   dfail:0   fail:22  skip:890 
time:10555s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7715/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v7 6/6] HAX Enable GuC Submission for CI

[Jackie Li]

Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c| 4 ++--
 drivers/gpu/drm/i915/i915_params.c | 2 +-
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 drivers/gpu/drm/i915/intel_guc_wopcm.c | 6 ++
 4 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 26dee5e..fed472a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3561,7 +3561,7 @@ int i915_ggtt_enable_hw(struct drm_i915_private *dev_priv)
 
 void i915_ggtt_enable_guc(struct drm_i915_private *i915)
 {
-   GEM_BUG_ON(i915->ggtt.invalidate != gen6_ggtt_invalidate);
+// GEM_BUG_ON(i915->ggtt.invalidate != gen6_ggtt_invalidate);
 
i915->ggtt.invalidate = guc_ggtt_invalidate;
 
@@ -3571,7 +3571,7 @@ void i915_ggtt_enable_guc(struct drm_i915_private *i915)
 void i915_ggtt_disable_guc(struct drm_i915_private *i915)
 {
/* We should only be called after i915_ggtt_enable_guc() */
-   GEM_BUG_ON(i915->ggtt.invalidate != guc_ggtt_invalidate);
+// GEM_BUG_ON(i915->ggtt.invalidate != guc_ggtt_invalidate);
 
i915->ggtt.invalidate = gen6_ggtt_invalidate;
 
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 0b553a8..b33d364 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -152,7 +152,7 @@ i915_param_named_unsafe(edp_vswing, int, 0400,
 i915_param_named_unsafe(enable_guc, int, 0400,
"Enable GuC load for GuC submission and/or HuC load. "
"Required functionality can be selected using bitmask values. "
-   "(-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load)");
+   "(-1=auto [default], 0=disable, 1=GuC submission, 2=HuC load)");
 
 i915_param_named(guc_log_level, int, 0400,
"GuC firmware logging level. Requires GuC to be loaded. "
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index c963603..53037b5 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@ struct drm_printer;
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
+   param(int, enable_guc, -1) \
param(int, guc_log_level, -1) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.c 
b/drivers/gpu/drm/i915/intel_guc_wopcm.c
index 236fc32..e972b7b 100644
--- a/drivers/gpu/drm/i915/intel_guc_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c
@@ -154,6 +154,9 @@ int intel_guc_wopcm_init(struct intel_guc *guc, u32 
guc_fw_size,
u32 offset, size, top;
int err;
 
+   DRM_DEBUG_DRIVER("guc_fw size %u, huc_fw_size %u\n", guc_fw_size,
+huc_fw_size);
+
GEM_BUG_ON(guc->wopcm.flags & INTEL_GUC_WOPCM_VALID);
 
if (!guc_fw_size)
@@ -213,6 +216,9 @@ void intel_guc_wopcm_init_hw(struct intel_guc *guc)
 {
u32 locked = guc_wopcm_locked(guc);
 
+   DRM_DEBUG_DRIVER("locked = %s, flags = %#x\n", yesno(locked),
+guc->wopcm.flags);
+
GEM_BUG_ON(!(guc->wopcm.flags & INTEL_GUC_WOPCM_VALID));
 
/*
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH 2/4] drm/i915: II stage HDCP auth for repeater only

[Sean Paul]

On Thu, Jan 18, 2018 at 7:50 PM, C, Ramalingam  wrote:
>> -Original Message-
>> From: Sean Paul [mailto:seanp...@chromium.org]
>> Sent: Friday, January 19, 2018 3:54 AM
>> To: C, Ramalingam 
>> Cc: intel-gfx@lists.freedesktop.org; seanp...@chromium.org;
>> daniel.vet...@ffwll.ch; Vivi, Rodrigo ; Sharma,
>> Shashank 
>> Subject: Re: [PATCH 2/4] drm/i915: II stage HDCP auth for repeater only
>>
>> On Thu, Jan 18, 2018 at 11:18:06AM +0530, Ramalingam C wrote:
>> > Second stage of HDCP authentication required only if the HDCP sink is
>> > a repeater.
>> >
>> > This patch imposes above condition on second stage HDCP authentication.
>>
>> Hi Ram,
>> This is already enforced in intel_hdcp_auth_downstream()
>
> I am not able to locate any check for repeater capability at start of 
> downstream auth.
>
> I am not sure whether you are referring to number of downstream device count 
> check.
> That is valid after poll for ksv_fifo ready. We don't want to wait for 5Sec 
> timeout in poll to detect the repeater cap.
>
> And since the caller is handy with the flag for repeater cap, it is best to 
> decide on the call for downstream auth itself.
>

Thanks for clarifying, makes sense with the other patches in the set.

Sean

> Thanks
> --Ram
>>
>> Thanks,
>> Sean
>>
>> >
>> > Signed-off-by: Ramalingam C 
>> > ---
>> >  drivers/gpu/drm/i915/intel_hdcp.c | 5 -
>> >  1 file changed, 4 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>> > b/drivers/gpu/drm/i915/intel_hdcp.c
>> > index 6ce6559897a6..b48c72cd0906 100644
>> > --- a/drivers/gpu/drm/i915/intel_hdcp.c
>> > +++ b/drivers/gpu/drm/i915/intel_hdcp.c
>> > @@ -493,7 +493,10 @@ static int intel_hdcp_auth(struct intel_digital_port
>> *intel_dig_port,
>> >  * on those as well.
>> >  */
>> >
>> > -   return intel_hdcp_auth_downstream(intel_dig_port, shim);
>> > +   if (repeater_present)
>> > +   return intel_hdcp_auth_downstream(intel_dig_port, shim);
>> > +
>> > +   return 0;
>> >  }
>> >
>> >  static
>> > --
>> > 2.7.4
>> >
>>
>> --
>> Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/4] drm/i915: II stage HDCP auth for repeater only

[Sean Paul]

On Thu, Jan 18, 2018 at 11:18:06AM +0530, Ramalingam C wrote:
> Second stage of HDCP authentication required only if the HDCP
> sink is a repeater.
> 
> This patch imposes above condition on second stage HDCP authentication.

Hi Ram,
This is already enforced in intel_hdcp_auth_downstream()

Thanks,
Sean

> 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/i915/intel_hdcp.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 6ce6559897a6..b48c72cd0906 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -493,7 +493,10 @@ static int intel_hdcp_auth(struct intel_digital_port 
> *intel_dig_port,
>* on those as well.
>*/
>  
> - return intel_hdcp_auth_downstream(intel_dig_port, shim);
> + if (repeater_present)
> + return intel_hdcp_auth_downstream(intel_dig_port, shim);
> +
> + return 0;
>  }
>  
>  static
> -- 
> 2.7.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] linux-next: Signed-off-by missing for commit in the drm-misc-fixes tree

[Thomas Hellstrom]

Hi, Stephen,

That would be me.
I've historically only added my signed-off-by:s on commits I've (co-) 
authored myself, as the committer info is already registered,


But I take it that's not the correct approach?
/Thomas



On 01/18/2018 09:23 PM, Stephen Rothwell wrote:

Hi all,

Commit

   8a510a5c7526 ("drm/vmwgfx: fix memory corruption with legacy/sou connectors")

is missing a Signed-off-by from its committer.



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

Re: [Intel-gfx] linux-next: Signed-off-by missing for commit in the drm-misc-fixes tree

[Stephen Rothwell]

Hi Thomas,

On Thu, 18 Jan 2018 22:18:48 +0100 Thomas Hellstrom  
wrote:
>
> That would be me.
> I've historically only added my signed-off-by:s on commits I've (co-) 
> authored myself, as the committer info is already registered,
> 
> But I take it that's not the correct approach?

Please read "Developer's Certificate of Origin 1.1" in
Documentation/process/submitting-patches.rst.  Basically, if you handle
the patch on its way to Linus (e.g. commit it to a branch of a git tree
that Linus (or someone else along the path) merges) then you need to
add a Signed-off-by tag.

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

Re: [Intel-gfx] [RFC v2 6/8] drm: Handle fbdev emulation in core

[Daniel Vetter]

[oops, this was stuck in my draft folder, sry]

On Thu, Jan 11, 2018 at 3:09 PM, Noralf Trønnes  wrote:
>
> Den 11.01.2018 08.45, skrev Daniel Vetter:
>>
>> On Wed, Jan 10, 2018 at 06:02:38PM +0100, Noralf Trønnes wrote:
>>>
>>> Den 09.01.2018 11.38, skrev Daniel Vetter:

 On Wed, Jan 03, 2018 at 11:21:08PM +0100, Noralf Trønnes wrote:
>
> Prepare for generic fbdev emulation by letting DRM core work directly
> with the fbdev compatibility layer. This is done by adding new fbdev
> helper vtable callbacks for restore, hotplug_event, unregister and
> release.
>
> Signed-off-by: Noralf Trønnes 

 No clue whether my idea is any good, but inspired by the bootsplash
 discussion, and the prospect that we might get other in-kernel drm/kms
 clients I'm wondering whether we should make this a bit more generic and
 tie it to drm_file?

 The idea would be to have a list of internal drm clients by putting all
 the internal drm_files onto a list (same way we do with the userspace
 ones). Then we'd just walk that list and call ->hotplug, ->unregister
 and
 ->release at the right places.

 ->restore would be a bit different, I guess for that we'd only call the
 ->restore callback of the very first kernel-internal client.

 With that we could then add/remove kernel-internal drm clients like
 normal
 userspace clients, which should make integration of emergency consoles,
 boot splashes and whatever else real easy. And I think it would be a lot
 cleaner than leaking fb_helper knowledge into the drm core, which feels
 a
 rather backwards.

 Otoh that feels a bit overengineered (but at least it shouldn't be a lot
 more code really). If the list is too much work we could start with 1
 drm_file * pointer for internal stuff (but would still need locking, so
 list_head is probably easier).

 Thoughts?
>>>
>>> I prefer to have a proper in-kernel client API from the get go, instead
>>> of fixing it up later. The reason I skipped spending time on it in this
>>> RFC, was that I didn't know if I was on the right track at the right time
>>> to get the necessary attention to make this dumb_buffer idea happen.
>>>
>>> With a drm_file centric approach, are you thinking something like this:
>>>
>>>   struct drm_device {
>>> +struct list_head filelist_internal;
>>>   };
>>>
>>> +struct drm_file_funcs {
>>> +int (*restore)(struct drm_file *file);
>>> +void (*hotplug)(struct drm_file *file);
>>> +void (*unregister)(struct drm_file *file);
>>
>> I guess we still need a cleanup callback here? For the usual two-stage
>> driver unload sequence of 1. unregister 2. cleanup.
>
>
> There's no need for a cleanup callback in this scenario.
> The client holds a ref on drm_device through drm_internal_open() and if
> it can't release the drm_file on .unregister, there won't be any cleanup.
> When the client is in a position to release drm_file (fb_close), it will
> do so and the ref is dropped.

But when will we clean up fbdev helper allocations and things like
that? If we do that through a ->release callback I think we can avoid
a few special cases.

Hm right, drm_file holds a full ref, so we won't ever enter that case.
That's annoying, since this means there's no clear place for us to
release stuff again  Should we perhaps try to drop the references
in ->unregister, but keep the drm_file on the list for ->release time?
I'd assume that trying to guess when exactly it's safe to release all
the fbdev allocated resources is otherwise going to be somewhat
tricky.

Or maybe I'm just seeing monsters when there's actually no problem at all :-)

> If for some reason we can't take a ref, then we need to use
> drm_device.open_count to avoid drm_device going away in drm_dev_unplug().

open_count also holds a drm_get_dev reference (but implicitly).
-Daniel

>
> Noralf.
>
>
>>
>>> +};
>>>
>>>   struct drm_file {
>>> +struct drm_device *dev;
>>> +const struct drm_file_funcs *funcs;
>>>   };
>>>
>>>   struct drm_file *drm_file_alloc(struct drm_minor *minor)
>>>   {
>>> +file->dev = dev;
>>>   }
>>>
>>> struct drm_file* drm_internal_open(struct drm_device *dev,
>>> const struct drm_file_funcs *funcs)
>>>  struct drm_file *file;
>>>  int ret;
>>>
>>>  if (!try_module_get(dev->driver->fops->owner))
>>>  return ERR_PTR(-ENODEV);
>>>
>>>  drm_dev_ref(dev);
>>>
>>>  file = drm_file_alloc(dev);
>>>  if (IS_ERR(file)) {
>>>  drm_dev_unref(dev);
>>>  module_put(dev->driver->fops->owner);
>>>  return file;
>>>  }
>>>
>>>  file->funcs = funcs;
>>>
>>>  mutex_lock(>filelist_mutex);
>>>  list_add(>lhead, >filelist_internal);
>>>  mutex_unlock(>filelist_mutex);
>>>
>>>  return file;
>>> }
>>>
>>> void drm_internal_release(struct drm_file *file)
>>> {
>>>  struct 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dp: Fix compilation of intel_dp_hdcp_check_link

[Patchwork]

== Series Details ==

Series: drm/i915/dp: Fix compilation of intel_dp_hdcp_check_link
URL   : https://patchwork.freedesktop.org/series/36707/
State : failure

== Summary ==

Test kms_flip:
Subgroup vblank-vs-modeset-suspend-interruptible:
pass   -> SKIP   (shard-snb)
pass   -> SKIP   (shard-hsw) fdo#103540
Subgroup 2x-vblank-vs-suspend-interruptible:
pass   -> INCOMPLETE (shard-hsw)
Subgroup flip-vs-modeset-vs-hang-interruptible:
dmesg-warn -> PASS   (shard-snb) fdo#104311
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
fail   -> PASS   (shard-snb) fdo#101623 +1
Test perf:
Subgroup polling:
pass   -> FAIL   (shard-hsw) fdo#102252
Test kms_draw_crc:
Subgroup draw-method-xrgb-mmap-cpu-untiled:
skip   -> PASS   (shard-snb)
Subgroup draw-method-rgb565-blt-untiled:
skip   -> PASS   (shard-snb)
Test kms_chv_cursor_fail:
Subgroup pipe-a-256x256-bottom-edge:
skip   -> PASS   (shard-snb)
Test kms_universal_plane:
Subgroup disable-primary-vs-flip-pipe-b:
skip   -> PASS   (shard-snb)
Test drv_suspend:
Subgroup sysfs-reader:
pass   -> SKIP   (shard-hsw)

fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#104311 https://bugs.freedesktop.org/show_bug.cgi?id=104311
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-hswtotal:2723 pass:1703 dwarn:1   dfail:0   fail:11  skip:1006 
time:14599s
shard-snbtotal:2753 pass:1318 dwarn:1   dfail:0   fail:10  skip:1424 
time:7892s
Blacklisted hosts:
shard-apltotal:2753 pass:1716 dwarn:1   dfail:0   fail:21  skip:1015 
time:13886s
shard-kbltotal:2745 pass:1829 dwarn:2   dfail:0   fail:22  skip:891 
time:10483s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7713/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] linux-next: Signed-off-by missing for commit in the drm-misc-fixes tree

[Stephen Rothwell]

Hi all,

Commit

  8a510a5c7526 ("drm/vmwgfx: fix memory corruption with legacy/sou connectors")

is missing a Signed-off-by from its committer.

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/bios: add DP max link rate to VBT child device struct (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/bios: add DP max link rate to VBT child device struct (rev2)
URL   : https://patchwork.freedesktop.org/series/36701/
State : failure

== Summary ==

Warning: bzip Patchwork_7712/shard-hsw1/results34.json.bz2 wasn't in correct 
JSON format
Test perf:
Subgroup blocking:
pass   -> FAIL   (shard-hsw) fdo#102252
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
fail   -> PASS   (shard-snb) fdo#101623
Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw)
Subgroup flip-vs-modeset-vs-hang-interruptible:
dmesg-warn -> PASS   (shard-snb) fdo#104311
Subgroup plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368
Test kms_flip_event_leak:
pass   -> SKIP   (shard-snb)
Test kms_draw_crc:
Subgroup draw-method-xrgb-mmap-cpu-untiled:
skip   -> PASS   (shard-snb)
Subgroup draw-method-rgb565-blt-untiled:
skip   -> PASS   (shard-snb)
Test kms_chv_cursor_fail:
Subgroup pipe-a-256x256-bottom-edge:
skip   -> PASS   (shard-snb)
Test kms_universal_plane:
Subgroup disable-primary-vs-flip-pipe-b:
skip   -> PASS   (shard-snb)
Test drv_suspend:
Subgroup sysfs-reader:
pass   -> SKIP   (shard-hsw)

fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#104311 https://bugs.freedesktop.org/show_bug.cgi?id=104311
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368

shard-hswtotal:2676 pass:1679 dwarn:1   dfail:0   fail:12  skip:983 
time:15183s
shard-snbtotal:2753 pass:1317 dwarn:1   dfail:0   fail:11  skip:1424 
time:7929s
Blacklisted hosts:
shard-apltotal:2753 pass:1716 dwarn:1   dfail:0   fail:21  skip:1015 
time:13942s
shard-kbltotal:2745 pass:1829 dwarn:1   dfail:0   fail:24  skip:890 
time:10330s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7712/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/bios: add DP max link rate to VBT child device struct

[Rodrigo Vivi]

On Thu, Jan 18, 2018 at 08:12:18PM +, Rodrigo Vivi wrote:
> On Thu, Jan 18, 2018 at 03:33:10PM +, Jani Nikula wrote:
> > Update VBT defs to reflect revision 216. While at it, default the
> > expected child device struct size to sizeof the size rather than a
> > hardcoded value.
> > 
> > v2: Fix bit order (David)
> > 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: Jani Nikula 
> 
> Reviewed-by: Rodrigo Vivi 

and merged... thanks

> 
> 
> > ---
> >  drivers/gpu/drm/i915/intel_bios.c | 8 +---
> >  drivers/gpu/drm/i915/intel_vbt_defs.h | 2 ++
> >  2 files changed, 7 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> > b/drivers/gpu/drm/i915/intel_bios.c
> > index 51108ffc28d1..b820d595ebc8 100644
> > --- a/drivers/gpu/drm/i915/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/intel_bios.c
> > @@ -1323,11 +1323,13 @@ parse_general_definitions(struct drm_i915_private 
> > *dev_priv,
> > expected_size = LEGACY_CHILD_DEVICE_CONFIG_SIZE;
> > } else if (bdb->version == 195) {
> > expected_size = 37;
> > -   } else if (bdb->version <= 197) {
> > +   } else if (bdb->version <= 215) {
> > expected_size = 38;
> > +   } else if (bdb->version <= 216) {
> > +   expected_size = 39;
> > } else {
> > -   expected_size = 38;
> > -   BUILD_BUG_ON(sizeof(*child) < 38);
> > +   expected_size = sizeof(*child);
> > +   BUILD_BUG_ON(sizeof(*child) < 39);
> > DRM_DEBUG_DRIVER("Expected child device config size for VBT 
> > version %u not known; assuming %u\n",
> >  bdb->version, expected_size);
> > }
> > diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h 
> > b/drivers/gpu/drm/i915/intel_vbt_defs.h
> > index e3d7745a9151..98dff6058d3c 100644
> > --- a/drivers/gpu/drm/i915/intel_vbt_defs.h
> > +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
> > @@ -412,6 +412,8 @@ struct child_device_config {
> > u16 dp_gpio_pin_num;/* 195 */
> > u8 dp_iboost_level:4;   /* 196 */
> > u8 hdmi_iboost_level:4; /* 196 */
> > +   u8 dp_max_link_rate:2;  /* 216 CNL+ */
> > +   u8 dp_max_link_rate_reserved:6; /* 216 */
> >  } __packed;
> >  
> >  struct bdb_general_definitions {
> > -- 
> > 2.11.0
> > 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/bios: add DP max link rate to VBT child device struct

[Rodrigo Vivi]

On Thu, Jan 18, 2018 at 03:33:10PM +, Jani Nikula wrote:
> Update VBT defs to reflect revision 216. While at it, default the
> expected child device struct size to sizeof the size rather than a
> hardcoded value.
> 
> v2: Fix bit order (David)
> 
> Cc: Rodrigo Vivi 
> Signed-off-by: Jani Nikula 

Reviewed-by: Rodrigo Vivi 


> ---
>  drivers/gpu/drm/i915/intel_bios.c | 8 +---
>  drivers/gpu/drm/i915/intel_vbt_defs.h | 2 ++
>  2 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index 51108ffc28d1..b820d595ebc8 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1323,11 +1323,13 @@ parse_general_definitions(struct drm_i915_private 
> *dev_priv,
>   expected_size = LEGACY_CHILD_DEVICE_CONFIG_SIZE;
>   } else if (bdb->version == 195) {
>   expected_size = 37;
> - } else if (bdb->version <= 197) {
> + } else if (bdb->version <= 215) {
>   expected_size = 38;
> + } else if (bdb->version <= 216) {
> + expected_size = 39;
>   } else {
> - expected_size = 38;
> - BUILD_BUG_ON(sizeof(*child) < 38);
> + expected_size = sizeof(*child);
> + BUILD_BUG_ON(sizeof(*child) < 39);
>   DRM_DEBUG_DRIVER("Expected child device config size for VBT 
> version %u not known; assuming %u\n",
>bdb->version, expected_size);
>   }
> diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h 
> b/drivers/gpu/drm/i915/intel_vbt_defs.h
> index e3d7745a9151..98dff6058d3c 100644
> --- a/drivers/gpu/drm/i915/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
> @@ -412,6 +412,8 @@ struct child_device_config {
>   u16 dp_gpio_pin_num;/* 195 */
>   u8 dp_iboost_level:4;   /* 196 */
>   u8 hdmi_iboost_level:4; /* 196 */
> + u8 dp_max_link_rate:2;  /* 216 CNL+ */
> + u8 dp_max_link_rate_reserved:6; /* 216 */
>  } __packed;
>  
>  struct bdb_general_definitions {
> -- 
> 2.11.0
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/cnl: apply Display WA #1178 to fix type C dongles

[Rodrigo Vivi]

On Thu, Jan 18, 2018 at 07:39:51PM +, Rodrigo Vivi wrote:
> On Tue, Nov 28, 2017 at 10:05:53PM +, Lucas De Marchi wrote:
> > Display WA #1178 is meant to fix Aux channel voltage swing too low with
> > some type C dongles. Although it is for type C, HW engineers reported
> > that it can be applied to all external ports even if they are not going
> > to type C.
> > 
> > For CNL we apply the workaround every time Aux B, C and D are powering
> > up since they will lose the configuration when powered down.
> > 
> > v2: Use common tag for WA
> > 
> > Cc: Rodrigo Vivi 
> > Cc: Arthur J Runyan 
> > Cc: Ville Syrjälä 
> > Signed-off-by: Lucas De Marchi 
> 
> we got all confirmations that we need. Thanks Art.
> 
> Reviewed-by: Rodrigo Vivi 

merged. Thanks for the patch.

> 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h | 11 +++
> >  drivers/gpu/drm/i915/intel_runtime_pm.c |  9 +
> >  2 files changed, 20 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 09bf043c1c2e..0214327d8af7 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -8335,6 +8335,17 @@ enum skl_power_gate {
> >  #define  SKL_PW_TO_PG(pw)  ((pw) - SKL_DISP_PW_1 + SKL_PG1)
> >  #define  SKL_FUSE_PG_DIST_STATUS(pg)   (1 << (27 - (pg)))
> >  
> > +#define _CNL_AUX_REG_IDX(pw)   ((pw - 1) >> 4)
> > +#define _CNL_AUX_ANAOVRD1_B0x162250
> > +#define _CNL_AUX_ANAOVRD1_C0x162210
> > +#define _CNL_AUX_ANAOVRD1_D0x1622D0
> > +#define CNL_AUX_ANAOVRD1(pw)   
> > _MMIO(_PICK(_CNL_AUX_REG_IDX(pw), \
> > +   _CNL_AUX_ANAOVRD1_B, \
> > +   _CNL_AUX_ANAOVRD1_C, \
> > +   _CNL_AUX_ANAOVRD1_D))
> > +#define   CNL_AUX_ANAOVRD1_ENABLE  (1<<16)
> > +#define   CNL_AUX_ANAOVRD1_LDO_BYPASS  (1<<23)
> > +
> >  /* Per-pipe DDI Function Control */
> >  #define _TRANS_DDI_FUNC_CTL_A  0x60400
> >  #define _TRANS_DDI_FUNC_CTL_B  0x61400
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index 8315499452dc..29f14e724f41 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -388,6 +388,15 @@ static void hsw_power_well_enable(struct 
> > drm_i915_private *dev_priv,
> > I915_WRITE(HSW_PWR_WELL_CTL_DRIVER(id), val | HSW_PWR_WELL_CTL_REQ(id));
> > hsw_wait_for_power_well_enable(dev_priv, power_well);
> >  
> > +   /* Display WA #1178: cnl */
> > +   if (IS_CANNONLAKE(dev_priv) &&
> > +   (id == CNL_DISP_PW_AUX_B || id == CNL_DISP_PW_AUX_C ||
> > +id == CNL_DISP_PW_AUX_D)) {
> > +   val = I915_READ(CNL_AUX_ANAOVRD1(id));
> > +   val |= CNL_AUX_ANAOVRD1_ENABLE | CNL_AUX_ANAOVRD1_LDO_BYPASS;
> > +   I915_WRITE(CNL_AUX_ANAOVRD1(id), val);
> > +   }
> > +
> > if (wait_fuses)
> > gen9_wait_for_power_well_fuses(dev_priv, pg);
> >  
> > -- 
> > 2.14.3
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: vbt defs typo fixes

[Patchwork]

== Series Details ==

Series: drm/i915: vbt defs typo fixes
URL   : https://patchwork.freedesktop.org/series/36702/
State : warning

== Summary ==

Warning: bzip Patchwork_7711/shard-hsw6/results34.json.bz2 wasn't in correct 
JSON format
Test kms_flip:
Subgroup plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368
Subgroup flip-vs-modeset-vs-hang-interruptible:
dmesg-warn -> PASS   (shard-snb) fdo#104311
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-spr-indfb-draw-mmap-wc:
pass   -> SKIP   (shard-snb) fdo#101623 +2
Test kms_draw_crc:
Subgroup draw-method-xrgb-mmap-cpu-untiled:
skip   -> PASS   (shard-snb)
Subgroup draw-method-rgb565-blt-untiled:
skip   -> PASS   (shard-snb)
Test kms_chv_cursor_fail:
Subgroup pipe-a-256x256-bottom-edge:
skip   -> PASS   (shard-snb)
Test kms_universal_plane:
Subgroup disable-primary-vs-flip-pipe-b:
skip   -> PASS   (shard-snb)
Test drv_suspend:
Subgroup sysfs-reader:
pass   -> SKIP   (shard-hsw)

fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#104311 https://bugs.freedesktop.org/show_bug.cgi?id=104311
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623

shard-hswtotal:2676 pass:1681 dwarn:1   dfail:0   fail:10  skip:983 
time:15243s
shard-snbtotal:2753 pass:1318 dwarn:1   dfail:0   fail:10  skip:1424 
time:7913s
Blacklisted hosts:
shard-apltotal:2753 pass:1715 dwarn:1   dfail:0   fail:22  skip:1015 
time:13891s
shard-kbltotal:2745 pass:1827 dwarn:1   dfail:0   fail:23  skip:893 
time:10351s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7711/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/cnl: apply Display WA #1178 to fix type C dongles

[Rodrigo Vivi]

On Tue, Nov 28, 2017 at 10:05:53PM +, Lucas De Marchi wrote:
> Display WA #1178 is meant to fix Aux channel voltage swing too low with
> some type C dongles. Although it is for type C, HW engineers reported
> that it can be applied to all external ports even if they are not going
> to type C.
> 
> For CNL we apply the workaround every time Aux B, C and D are powering
> up since they will lose the configuration when powered down.
> 
> v2: Use common tag for WA
> 
> Cc: Rodrigo Vivi 
> Cc: Arthur J Runyan 
> Cc: Ville Syrjälä 
> Signed-off-by: Lucas De Marchi 

we got all confirmations that we need. Thanks Art.

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/i915_reg.h | 11 +++
>  drivers/gpu/drm/i915/intel_runtime_pm.c |  9 +
>  2 files changed, 20 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 09bf043c1c2e..0214327d8af7 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8335,6 +8335,17 @@ enum skl_power_gate {
>  #define  SKL_PW_TO_PG(pw)((pw) - SKL_DISP_PW_1 + SKL_PG1)
>  #define  SKL_FUSE_PG_DIST_STATUS(pg) (1 << (27 - (pg)))
>  
> +#define _CNL_AUX_REG_IDX(pw) ((pw - 1) >> 4)
> +#define _CNL_AUX_ANAOVRD1_B  0x162250
> +#define _CNL_AUX_ANAOVRD1_C  0x162210
> +#define _CNL_AUX_ANAOVRD1_D  0x1622D0
> +#define CNL_AUX_ANAOVRD1(pw) _MMIO(_PICK(_CNL_AUX_REG_IDX(pw), \
> + _CNL_AUX_ANAOVRD1_B, \
> + _CNL_AUX_ANAOVRD1_C, \
> + _CNL_AUX_ANAOVRD1_D))
> +#define   CNL_AUX_ANAOVRD1_ENABLE(1<<16)
> +#define   CNL_AUX_ANAOVRD1_LDO_BYPASS(1<<23)
> +
>  /* Per-pipe DDI Function Control */
>  #define _TRANS_DDI_FUNC_CTL_A0x60400
>  #define _TRANS_DDI_FUNC_CTL_B0x61400
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 8315499452dc..29f14e724f41 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -388,6 +388,15 @@ static void hsw_power_well_enable(struct 
> drm_i915_private *dev_priv,
>   I915_WRITE(HSW_PWR_WELL_CTL_DRIVER(id), val | HSW_PWR_WELL_CTL_REQ(id));
>   hsw_wait_for_power_well_enable(dev_priv, power_well);
>  
> + /* Display WA #1178: cnl */
> + if (IS_CANNONLAKE(dev_priv) &&
> + (id == CNL_DISP_PW_AUX_B || id == CNL_DISP_PW_AUX_C ||
> +  id == CNL_DISP_PW_AUX_D)) {
> + val = I915_READ(CNL_AUX_ANAOVRD1(id));
> + val |= CNL_AUX_ANAOVRD1_ENABLE | CNL_AUX_ANAOVRD1_LDO_BYPASS;
> + I915_WRITE(CNL_AUX_ANAOVRD1(id), val);
> + }
> +
>   if (wait_fuses)
>   gen9_wait_for_power_well_fuses(dev_priv, pg);
>  
> -- 
> 2.14.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for perf: Allow fine-grained PMU access control

[Patchwork]

== Series Details ==

Series: perf: Allow fine-grained PMU access control
URL   : https://patchwork.freedesktop.org/series/36723/
State : success

== Summary ==

Series 36723v1 perf: Allow fine-grained PMU access control
https://patchwork.freedesktop.org/api/1.0/series/36723/revisions/1/mbox/

Test kms_force_connector_basic:
Subgroup prune-stale-modes:
skip   -> PASS   (fi-snb-2520m)

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:419s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:426s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:379s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:483s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:482s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:481s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:464s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:456s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:275s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:515s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:392s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:398s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:413s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:451s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:415s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:458s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:497s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:451s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:499s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:584s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:426s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:511s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:529s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:485s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:470s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:433s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:523s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:400s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:568s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:473s
fi-skl-guc   total:288  pass:214  dwarn:46  dfail:0   fail:0   skip:28  
time:413s

a9c74eaa2b1cf3a3aa9f0efcfde34c0f4fefe8ac drm-tip: 2018y-01m-18d-18h-18m-07s UTC 
integration manifest
05467a39a151 perf: Allow fine-grained PMU access control

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7715/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC] perf: Allow fine-grained PMU access control

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

For situations where sysadmins might want to allow different level of
of access control for different PMUs, we start creating per-PMU
perf_event_paranoid controls in sysfs.

These work in equivalent fashion as the existing perf_event_paranoid
sysctl, which now becomes the parent control for each PMU.

On PMU registration the global/parent value will be inherited by each PMU,
as it will be propagated to all registered PMUs when the sysctl is
updated.

At any later point individual PMU access controls, located in
/device//perf_event_paranoid, can be adjusted to achieve
fine grained access control.

Signed-off-by: Tvrtko Ursulin 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: linux-ker...@vger.kernel.org
---
 arch/x86/events/intel/bts.c |  2 +-
 arch/x86/events/intel/core.c|  2 +-
 arch/x86/events/intel/p4.c  |  2 +-
 include/linux/perf_event.h  | 18 +---
 kernel/events/core.c| 99 ++---
 kernel/sysctl.c |  4 +-
 kernel/trace/trace_event_perf.c |  6 ++-
 7 files changed, 105 insertions(+), 28 deletions(-)

diff --git a/arch/x86/events/intel/bts.c b/arch/x86/events/intel/bts.c
index 24ffa1e88cf9..e416c9e2400a 100644
--- a/arch/x86/events/intel/bts.c
+++ b/arch/x86/events/intel/bts.c
@@ -555,7 +555,7 @@ static int bts_event_init(struct perf_event *event)
 * Note that the default paranoia setting permits unprivileged
 * users to profile the kernel.
 */
-   if (event->attr.exclude_kernel && perf_paranoid_kernel() &&
+   if (event->attr.exclude_kernel && perf_paranoid_kernel(event->pmu) &&
!capable(CAP_SYS_ADMIN))
return -EACCES;
 
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 731153a4681e..d623db13f212 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3009,7 +3009,7 @@ static int intel_pmu_hw_config(struct perf_event *event)
if (x86_pmu.version < 3)
return -EINVAL;
 
-   if (perf_paranoid_cpu() && !capable(CAP_SYS_ADMIN))
+   if (perf_paranoid_cpu(event->pmu) && !capable(CAP_SYS_ADMIN))
return -EACCES;
 
event->hw.config |= ARCH_PERFMON_EVENTSEL_ANY;
diff --git a/arch/x86/events/intel/p4.c b/arch/x86/events/intel/p4.c
index d32c0eed38ca..878451ef1ace 100644
--- a/arch/x86/events/intel/p4.c
+++ b/arch/x86/events/intel/p4.c
@@ -776,7 +776,7 @@ static int p4_validate_raw_event(struct perf_event *event)
 * the user needs special permissions to be able to use it
 */
if (p4_ht_active() && p4_event_bind_map[v].shared) {
-   if (perf_paranoid_cpu() && !capable(CAP_SYS_ADMIN))
+   if (perf_paranoid_cpu(event->pmu) && !capable(CAP_SYS_ADMIN))
return -EACCES;
}
 
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 7546822a1d74..1cb4e00d7f96 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -271,6 +271,9 @@ struct pmu {
/* number of address filters this PMU can do */
unsigned intnr_addr_filters;
 
+   /* fine grained access control */
+   int perf_event_paranoid;
+
/*
 * Fully disable/enable this PMU, can be used to protect from the PMI
 * as well as for lazy/batch writing of the MSRs.
@@ -1141,6 +1144,9 @@ extern int sysctl_perf_cpu_time_max_percent;
 
 extern void perf_sample_event_took(u64 sample_len_ns);
 
+extern int perf_proc_paranoid_handler(struct ctl_table *table, int write,
+   void __user *buffer, size_t *lenp,
+   loff_t *ppos);
 extern int perf_proc_update_handler(struct ctl_table *table, int write,
void __user *buffer, size_t *lenp,
loff_t *ppos);
@@ -1151,19 +1157,19 @@ extern int perf_cpu_time_max_percent_handler(struct 
ctl_table *table, int write,
 int perf_event_max_stack_handler(struct ctl_table *table, int write,
 void __user *buffer, size_t *lenp, loff_t 
*ppos);
 
-static inline bool perf_paranoid_tracepoint_raw(void)
+static inline bool perf_paranoid_tracepoint_raw(const struct pmu *pmu)
 {
-   return sysctl_perf_event_paranoid > -1;
+   return pmu->perf_event_paranoid > -1;
 }
 
-static inline bool perf_paranoid_cpu(void)
+static inline bool perf_paranoid_cpu(const struct pmu *pmu)
 {
-   return sysctl_perf_event_paranoid > 0;
+   return pmu->perf_event_paranoid > 0;
 }
 
-static inline bool perf_paranoid_kernel(void)
+static inline bool perf_paranoid_kernel(const struct pmu *pmu)
 {
-   return sysctl_perf_event_paranoid > 1;
+  

Re: [Intel-gfx] [PULL] gvt-next fixes for 4.16

[Rodrigo Vivi]

On Thu, Jan 18, 2018 at 02:23:13AM +, Zhenyu Wang wrote:
> On 2018.01.17 08:03:49 -0800, Rodrigo Vivi wrote:
> > > 
> > > Zhenyu Wang (2):
> > >   drm/i915/gvt: cancel virtual vblank timer when no vGPU exists
> > >   drm/i915/gvt: cancel scheduler timer when no vGPU exists
> > 
> > dim: ERROR: 0eb582541cfd7a17b6fcf9282c966c0e59efd02f is lacking mandatory 
> > review, aborting
> > 
> > Is it possible to get someone to quickly review it and fix the original 
> > commit, like last time?
> > 
> 
> yeah that two have been on gvt list for a while and seems people
> are fine with it and no regression for nightly test, I'll ask Zhi
> to ack and should be able to resend pull today. I need to update
> gvt tool to apply that rule as well.

Thanks for taking care of that. applied now.

> 
> thanks
> 
> -- 
> Open Source Technology Center, Intel ltd.
> 
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: expose RCS topology to userspace

[Patchwork]

== Series Details ==

Series: drm/i915: expose RCS topology to userspace
URL   : https://patchwork.freedesktop.org/series/36696/
State : failure

== Summary ==

Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
pass   -> FAIL   (shard-snb) fdo#101623
Test kms_flip:
Subgroup vblank-vs-suspend:
skip   -> PASS   (shard-snb) fdo#102365
Subgroup flip-vs-expired-vblank-interruptible:
pass   -> FAIL   (shard-snb)
Subgroup 2x-blt-wf_vblank-vs-dpms:
dmesg-warn -> PASS   (shard-hsw)
Test perf:
Subgroup invalid-open-flags:
pass   -> INCOMPLETE (shard-hsw)
Subgroup blocking:
pass   -> FAIL   (shard-hsw) fdo#102252
Test drv_suspend:
Subgroup sysfs-reader:
pass   -> SKIP   (shard-hsw)

fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-hswtotal:2731 pass:1712 dwarn:1   dfail:0   fail:11  skip:1005 
time:15233s
shard-snbtotal:2753 pass:1317 dwarn:1   dfail:0   fail:12  skip:1423 
time:7896s
Blacklisted hosts:
shard-apltotal:2753 pass:1714 dwarn:1   dfail:0   fail:23  skip:1015 
time:13842s
shard-kbltotal:2706 pass:1799 dwarn:1   dfail:0   fail:23  skip:881 
time:10288s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7710/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Use the engine name directly in the error_state file

[Chris Wilson]

Quoting Michel Thierry (2018-01-10 01:21:51)
> Instead of using local string names that we will have to keep
> maintaining, use the engine->name directly.
> 
> v2: Better invalid engine_id handling, capture_bo will not be able know
> the engine_id and end up with -1 (Michal).
> 
> Suggested-by: Michal Wajdeczko 
> Signed-off-by: Michel Thierry 
> Cc: Michal Wajdeczko 
> Cc: Chris Wilson 

Massaged the patch just ever so slightly and applied. Thanks for the
patch and review,
-Chris
___
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: Use the engine name directly in the error_state file (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Use the engine name directly in the error_state file (rev3)
URL   : https://patchwork.freedesktop.org/series/36215/
State : success

== Summary ==

Series 36215v3 drm/i915: Use the engine name directly in the error_state file
https://patchwork.freedesktop.org/api/1.0/series/36215/revisions/3/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-bdw-5557u) fdo#104162

fdo#104162 https://bugs.freedesktop.org/show_bug.cgi?id=104162

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:419s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:427s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:489s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:483s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:484s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:465s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:450s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:277s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:514s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:390s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:400s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:409s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:459s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:414s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:460s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:502s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:452s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:499s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:582s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:430s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:512s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:529s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:485s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:471s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:429s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:395s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:576s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:474s
fi-skl-guc   total:288  pass:214  dwarn:45  dfail:1   fail:0   skip:28  
time:419s

c742f2aed9f3a6bbd8de7f357eb11a6579de526a drm-tip: 2018y-01m-18d-17h-17m-33s UTC 
integration manifest
542fe01b9ef2 drm/i915: Use the engine name directly in the error_state file

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7714/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 09/10] drm/i915: Only signal from interrupt when requested

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-01-17 12:22:33)
> 
> On 15/01/2018 21:24, Chris Wilson wrote:
> > Avoid calling dma_fence_signal() from inside the interrupt if we haven't
> > enabled signaling on the request.
> > 
> > Signed-off-by: Chris Wilson 
> > ---
> >   drivers/gpu/drm/i915/i915_gem_request.c | 2 +-
> >   drivers/gpu/drm/i915/i915_irq.c | 3 ++-
> >   drivers/gpu/drm/i915/intel_ringbuffer.h | 5 ++---
> >   3 files changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> > b/drivers/gpu/drm/i915/i915_gem_request.c
> > index 08bbd56277e5..46848aef1648 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_request.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> > @@ -1214,7 +1214,7 @@ long i915_wait_request(struct drm_i915_gem_request 
> > *req,
> >   if (flags & I915_WAIT_LOCKED)
> >   add_wait_queue(errq, );
> >   
> > - intel_wait_init(, req);
> > + intel_wait_init();
> >   
> >   restart:
> >   do {
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index e5f76d580010..ea290f102784 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -1093,7 +1093,8 @@ static void notify_ring(struct intel_engine_cs 
> > *engine)
> >   if (i915_seqno_passed(seqno, wait->seqno)) {
> >   struct drm_i915_gem_request *waiter = wait->request;
> >   
> > - if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
> > + if (waiter &&
> > + !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
> > >fence.flags) &&
> >   intel_wait_check_request(wait, waiter))
> >   rq = i915_gem_request_get(waiter);
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
> > b/drivers/gpu/drm/i915/intel_ringbuffer.h
> > index f406d0ff4612..cea2092d25d9 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> > @@ -874,11 +874,10 @@ static inline u32 
> > intel_hws_preempt_done_address(struct intel_engine_cs *engine)
> >   /* intel_breadcrumbs.c -- user interrupt bottom-half for waiters */
> >   int intel_engine_init_breadcrumbs(struct intel_engine_cs *engine);
> >   
> > -static inline void intel_wait_init(struct intel_wait *wait,
> > -struct drm_i915_gem_request *rq)
> > +static inline void intel_wait_init(struct intel_wait *wait)
> >   {
> >   wait->tsk = current;
> > - wait->request = rq;
> > + wait->request = NULL;
> 
> Unless it is in this patch series, I can't see that this now leaves any 
> code path which sets wait->request?

The signaler is now the only entity that sets up wait.request.
 
> It's strange anyway - is this guarding against null ptr deref or what?

Uninitialized pointer deref in the irq handler, yup.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/10] drm/i915: Reduce spinlock hold time during notify_ring() interrupt

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-01-17 10:45:16)
> 
> On 15/01/2018 21:24, Chris Wilson wrote:
> > - if (wakeup)
> > - wake_up_process(wait->tsk);
> > + tsk = wait->tsk;
> > + } else {
> > + if (engine->irq_seqno_barrier &&
> > + i915_seqno_passed(seqno, wait->seqno - 1))
> 
> Hm what is this about? Why -1 on platforms with coherency issues and not 
> some other number? Needs a comment as minimum but still is a behaviour 
> change which I did not immediately figure out how it goes with the 
> commit message. If it is some additional optimization it needs to be 
> split out into a separate patch.

It's a finger in the air statement that I don't expect to be more than
one seqno behind in the interrupt-vs-breadcrumb race. So far I haven't
been disappointed.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/10] drm/i915: Reduce spinlock hold time during notify_ring() interrupt

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-01-17 10:45:16)
> 
> On 15/01/2018 21:24, Chris Wilson wrote:
> > By taking advantage of the RCU protection of the task struct, we can find
> > the appropriate signaler under the spinlock and then release the spinlock
> > before waking the task and signaling the fence.
> > 
> > Signed-off-by: Chris Wilson 
> > ---
> >   drivers/gpu/drm/i915/i915_irq.c | 29 +++--
> >   1 file changed, 19 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 3517c6548e2c..0b272501b738 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -1065,21 +1065,24 @@ static void ironlake_rps_change_irq_handler(struct 
> > drm_i915_private *dev_priv)
> >   
> >   static void notify_ring(struct intel_engine_cs *engine)
> >   {
> > + const u32 seqno = intel_engine_get_seqno(engine);
> >   struct drm_i915_gem_request *rq = NULL;
> > + struct task_struct *tsk = NULL;
> >   struct intel_wait *wait;
> >   
> > - if (!engine->breadcrumbs.irq_armed)
> > + if (unlikely(!engine->breadcrumbs.irq_armed))
> >   return;
> 
> It isn't unlikely in GuC mode, just sayin'...

Already taken care of, guc now "pins" the irq as opposed to arming it. So
we should be able to equate irq_armed to mean "has waiters".
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Shrink the GEM kmem_caches upon idling

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-01-17 10:18:38)
> 
> On 16/01/2018 17:36, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-01-16 17:25:25)
> >>
> >> On 16/01/2018 15:21, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2018-01-16 15:12:43)
> 
>  On 16/01/2018 13:05, Chris Wilson wrote:
> > +
> > + if (!new_requests_since_last_retire(dev_priv)) {
> > + __i915_gem_free_work(_priv->mm.free_work);
> >>
> >> ... you wouldn't want to pull this up under the struct mutex section? It
> >> would need a different flavour of a function to be called, and some
> >> refactoring of the existing ones.
> > 
> > "Some". I don't think that improves anything?
> > 
> > The statement of intent to me is that we only throw away the caches and
> > excess memory if and only if we are idle. The presumption is that under
> > active conditions those caches are important, but if we are about to
> > sleep for long periods of time, we should be proactive in releasing
> > resources.
> > 
> > I can hear you about to ask if we could add a timer and wake up in 10s to
> > prove we were idle!
> 
> No, pointless since this proposal already runs outside this guarantee, 
> and anyway, this was or the other there is potential to disrupt the next 
> client.
> 
> How about sticking in a break on new_request_since_last_retire() into 
> __i915_gem_free_work()? Would that defeat the backlog cleaning? Maybe 
> conditional only when called from the idle handler?

__i915_gem_free_work() is a distraction, since it is just clearing the
backlog of freed objects and shouldn't be affecting the cache
optimisations for the next/concurrent client. Let me try rearranging the
flow here.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/guc: Change values for i915_guc_log_control

[Chris Wilson]

Quoting Chris Wilson (2018-01-18 17:21:57)
> Quoting Sagar Arun Kamble (2018-01-12 05:53:28)
> > 
> > 
> > On 1/11/2018 8:54 PM, Michal Wajdeczko wrote:
> > > Today we have format mismatch between read/write operations
> > > of i915_guc_log_control entry. For read we return (0, 1..4)
> > > that represents disable/verbosity levels, but for write we
> > > force user to follow internal structure format (0,1,9,11,13).
> > 0x0, 0x1, 0x11, 0x21, 0x31
> > > Let's hide internals from the user and accept same values
> > > as we support for read and related guc_log_level modparam.
> > >
> > > Signed-off-by: Michal Wajdeczko 
> > > Cc: Sagar Arun Kamble 
> > > Cc: Daniele Ceraolo Spurio 
> > > Cc: Tvrtko Ursulin 
> > > Cc: Joonas Lahtinen 
> > > Cc: Chris Wilson 
> > Reviewed-by: Sagar Arun Kamble 
> 
> Thanks for the patches and review, pushed.

Oh darn it,

   30.062893] ==
[   30.062894] WARNING: possible circular locking dependency detected
[   30.062895] 4.15.0-rc8-CI-CI_DRM_3648+ #1 Tainted: G U  
[   30.062896] --
[   30.062897] debugfs_test/1268 is trying to acquire lock:
[   30.062898]  (>struct_mutex){+.+.}, at: [] 
i915_mutex_lock_interruptible+0x47/0x130 [i915]
[   30.062921] 
   but task is already holding lock:
[   30.062921]  (>mmap_sem){}, at: [] 
__do_page_fault+0x106/0x560
[   30.062924] 
   which lock already depends on the new lock.

[   30.062925] 
   the existing dependency chain (in reverse order) is:
[   30.062926] 
   -> #3 (>mmap_sem){}:
[   30.062930]_copy_to_user+0x1e/0x70
[   30.062932]filldir+0x8c/0xf0
[   30.062934]dcache_readdir+0xeb/0x160
[   30.062935]iterate_dir+0xdc/0x140
[   30.062936]SyS_getdents+0xa0/0x130
[   30.062938]entry_SYSCALL_64_fastpath+0x22/0x8f
[   30.062939] 
   -> #2 (>s_type->i_mutex_key#3){}:
[   30.062942]start_creating+0x59/0x110
[   30.062944]__debugfs_create_file+0x2e/0xe0
[   30.062946]relay_create_buf_file+0x62/0x80
[   30.062947]relay_late_setup_files+0x84/0x250
[   30.062967]guc_log_late_setup+0x52/0x110 [i915]
[   30.062985]i915_guc_log_register+0x3a/0x60 [i915]
[   30.062997]i915_driver_load+0x7b6/0x1720 [i915]
[   30.063014]i915_pci_probe+0x2e/0x90 [i915]
[   30.063017]pci_device_probe+0x9c/0x120
[   30.063018]driver_probe_device+0x2a3/0x480
[   30.063020]__driver_attach+0xd9/0xe0
[   30.063021]bus_for_each_dev+0x57/0x90
[   30.063022]bus_add_driver+0x168/0x260
[   30.063023]driver_register+0x52/0xc0
[   30.063024]do_one_initcall+0x39/0x150
[   30.063025]do_init_module+0x56/0x1ef
[   30.063026]load_module+0x231c/0x2d70
[   30.063027]SyS_finit_module+0xa5/0xe0
[   30.063028]do_syscall_64+0x59/0x1a0
[   30.063030]return_from_SYSCALL_64+0x0/0x75
[   30.063030] 
   -> #1 (relay_channels_mutex){+.+.}:
[   30.063034]relay_open+0x12c/0x2b0
[   30.063051]guc_log_runtime_create+0xa0/0x220 [i915]
[   30.063067]intel_guc_log_create+0xec/0x1c0 [i915]
[   30.063083]intel_guc_init+0x5d/0x100 [i915]
[   30.063100]intel_uc_init+0x29/0xa0 [i915]
[   30.063116]i915_gem_init+0x18a/0x540 [i915]
[   30.063128]i915_driver_load+0xaa9/0x1720 [i915]
[   30.063140]i915_pci_probe+0x2e/0x90 [i915]
[   30.063141]pci_device_probe+0x9c/0x120
[   30.063143]driver_probe_device+0x2a3/0x480
[   30.063144]__driver_attach+0xd9/0xe0
[   30.063145]bus_for_each_dev+0x57/0x90
[   30.063146]bus_add_driver+0x168/0x260
[   30.063147]driver_register+0x52/0xc0
[   30.063148]do_one_initcall+0x39/0x150
[   30.063149]do_init_module+0x56/0x1ef
[   30.063150]load_module+0x231c/0x2d70
[   30.063151]SyS_finit_module+0xa5/0xe0
[   30.063152]do_syscall_64+0x59/0x1a0
[   30.063153]return_from_SYSCALL_64+0x0/0x75
[   30.063154] 
   -> #0 (>struct_mutex){+.+.}:
[   30.063156]__mutex_lock+0x81/0x9b0
[   30.063172]i915_mutex_lock_interruptible+0x47/0x130 [i915]
[   30.063187]i915_gem_fault+0x201/0x790 [i915]
[   30.063190]__do_fault+0x15/0x70
[   30.063191]__handle_mm_fault+0x677/0xdc0
[   30.063193]handle_mm_fault+0x14f/0x2f0
[   30.063194]__do_page_fault+0x2d1/0x560
[   30.063195]page_fault+0x4c/0x60
[   30.063196] 
   other info that might help us debug this:

[   30.063197] Chain exists of:
 >struct_mutex --> 

[Intel-gfx] [CI] drm/i915: Use the engine name directly in the error_state file

[Chris Wilson]

From: Michel Thierry 

Instead of using local string names that we will have to keep
maintaining, use the engine->name directly.

v2: Better invalid engine_id handling, capture_bo will not be able know
the engine_id and end up with -1 (Michal).

Suggested-by: Michal Wajdeczko 
Signed-off-by: Michel Thierry 
Cc: Michal Wajdeczko 
Cc: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20180110012151.28261-1-michel.thie...@intel.com
[ickle: minor massaging of function names]
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 36 ++-
 1 file changed, 23 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 06577574296b..a81351d9e3a6 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -34,16 +34,25 @@
 
 #include "i915_drv.h"
 
-static const char *engine_str(int engine)
-{
-   switch (engine) {
-   case RCS: return "render";
-   case VCS: return "bsd";
-   case BCS: return "blt";
-   case VECS: return "vebox";
-   case VCS2: return "bsd2";
-   default: return "";
-   }
+static inline const struct intel_engine_cs *
+engine_lookup(const struct drm_i915_private *i915, unsigned int id)
+{
+   if (id >= I915_NUM_ENGINES)
+   return NULL;
+
+   return i915->engine[id];
+}
+
+static inline const char *
+__engine_name(const struct intel_engine_cs *engine)
+{
+   return engine ? engine->name : "";
+}
+
+static const char *
+engine_name(const struct drm_i915_private *i915, unsigned int id)
+{
+   return __engine_name(engine_lookup(i915, id));
 }
 
 static const char *tiling_flag(int tiling)
@@ -345,7 +354,7 @@ static void print_error_buffers(struct 
drm_i915_error_state_buf *m,
err_puts(m, purgeable_flag(err->purgeable));
err_puts(m, err->userptr ? " userptr" : "");
err_puts(m, err->engine != -1 ? " " : "");
-   err_puts(m, engine_str(err->engine));
+   err_puts(m, engine_name(m->i915, err->engine));
err_puts(m, i915_cache_level_str(m->i915, err->cache_level));
 
if (err->name)
@@ -415,7 +424,8 @@ static void error_print_engine(struct 
drm_i915_error_state_buf *m,
 {
int n;
 
-   err_printf(m, "%s command stream:\n", engine_str(ee->engine_id));
+   err_printf(m, "%s command stream:\n",
+  engine_name(m->i915, ee->engine_id));
err_printf(m, "  IDLE?: %s\n", yesno(ee->idle));
err_printf(m, "  START: 0x%08x\n", ee->start);
err_printf(m, "  HEAD:  0x%08x [0x%08x]\n", ee->head, ee->rq_head);
@@ -635,7 +645,7 @@ int i915_error_state_to_str(struct drm_i915_error_state_buf 
*m,
if (error->engine[i].hangcheck_stalled &&
error->engine[i].context.pid) {
err_printf(m, "Active process (on ring %s): %s [%d], 
score %d\n",
-  engine_str(i),
+  engine_name(m->i915, i),
   error->engine[i].context.comm,
   error->engine[i].context.pid,
   error->engine[i].context.ban_score);
-- 
2.15.1

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

Re: [Intel-gfx] [PATCH v6 20/99] ida: Convert to XArray

[John Paul Adrian Glaubitz]

Hi Matthew!

On 01/17/2018 09:20 PM, Matthew Wilcox wrote:
> Use the xarray infrstructure like we used the radix tree infrastructure.
> This lets us get rid of idr_get_free() from the radix tree code.

There's a typo: infrstructure => infratructure

Cheers,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] intel: Future-proof ring names for aubinator_error_decode

[Chris Wilson]

Quoting Michel Thierry (2018-01-18 16:44:18)
> On 1/17/2018 7:47 AM, Chris Wilson wrote:
> > The kernel is moving to a $class$instance naming scheme in preparation
> > for accommodating more rings in the future in a consistent manner. It is
> > already using the naming scheme internally, and now we are looking at
> > updating some soft-ABI such as the error state to use the new naming
> > scheme. This of course means we need to teach aubinator_error_decode how
> > to map both sets of ring names onto its register maps.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Michel Thierry 
> > Cc: Michal Wajdeczko 
> > Cc: Tvrtko Ursulin 
> > Cc: Lionel Landwerlin 
> > Cc: Kenneth Graunke 
> > ---
> >   src/intel/tools/aubinator_error_decode.c | 122 
> > +--
> >   1 file changed, 98 insertions(+), 24 deletions(-)
> > 
> > diff --git a/src/intel/tools/aubinator_error_decode.c 
> > b/src/intel/tools/aubinator_error_decode.c
> > index 9dd70790e1..01c6a7a365 100644
> > --- a/src/intel/tools/aubinator_error_decode.c
> > +++ b/src/intel/tools/aubinator_error_decode.c
> > @@ -74,40 +74,95 @@ print_register(struct gen_spec *spec, const char *name, 
> > uint32_t reg)
> >   }
> >   
> >   struct ring_register_mapping {
> > -   const char *ring_name;
> > +   unsigned ring_class;
> > +   unsigned ring_instance;
> >  const char *register_name;
> >   };
> >   
> > +enum {
> > +   RCS,
> > +   BCS,
> > +   VCS,
> > +   VECS,
> > +};
> > +
> >   static const struct ring_register_mapping acthd_registers[] = {
> > -   { "blt", "BCS_ACTHD_UDW" },
> > -   { "bsd", "VCS_ACTHD_UDW" },
> > -   { "bsd2", "VCS2_ACTHD_UDW" },
> > -   { "render", "ACTHD_UDW" },
> > -   { "vebox", "VECS_ACTHD_UDW" },
> > +   { BCS, 0, "BCS_ACTHD_UDW" },
> > +   { VCS, 0, "VCS_ACTHD_UDW" },
> > +   { VCS, 1, "VCS2_ACTHD_UDW" },
> > +   { RCS, 0, "ACTHD_UDW" },
> > +   { VECS, 0, "VECS_ACTHD_UDW" },
> >   };
> >   
> >   static const struct ring_register_mapping ctl_registers[] = {
> > -   { "blt", "BCS_RING_BUFFER_CTL" },
> > -   { "bsd", "VCS_RING_BUFFER_CTL" },
> > -   { "bsd2", "VCS2_RING_BUFFER_CTL" },
> > -   { "render", "RCS_RING_BUFFER_CTL" },
> > -   { "vebox", "VECS_RING_BUFFER_CTL" },
> > +   { BCS, 0, "BCS_RING_BUFFER_CTL" },
> > +   { VCS, 0, "VCS_RING_BUFFER_CTL" },
> > +   { VCS, 1, "VCS2_RING_BUFFER_CTL" },
> > +   { RCS, 0, "RCS_RING_BUFFER_CTL" },
> > +   { VECS, 0,  "VECS_RING_BUFFER_CTL" },
> >   };
> >   
> >   static const struct ring_register_mapping fault_registers[] = {
> > -   { "blt", "BCS_FAULT_REG" },
> > -   { "bsd", "VCS_FAULT_REG" },
> > -   { "render", "RCS_FAULT_REG" },
> > -   { "vebox", "VECS_FAULT_REG" },
> > +   { BCS, 0, "BCS_FAULT_REG" },
> > +   { VCS, 0, "VCS_FAULT_REG" },
> > +   { RCS, 0, "RCS_FAULT_REG" },
> > +   { VECS, 0, "VECS_FAULT_REG" },
> >   };
> >   
> > +static int ring_name_to_class(const char *ring_name,
> > +  unsigned int *class)
> > +{
> > +   static const char *class_names[] = {
> > +  [RCS] = "rcs",
> > +  [BCS] = "bcs",
> > +  [VCS] = "vcs",
> > +  [VECS] = "vecs",
> > +   };
> 
> This will match the new names in the error state, e.g.
> 
> rcs0 command stream:
> ...
> bcs0 command stream:
> ...
> vcs0 command stream:
> ...
> vcs1 command stream:
> ...
> vecs0 command stream:
> ...
> 
> > +   for (size_t i = 0; i < ARRAY_SIZE(class_names); i++) {
> > +  if (strcmp(ring_name, class_names[i]))
> > + continue;
> > +
> > +  *class = i;
> > +  return atoi(ring_name + strlen(class_names[i]));
> > +   }
> > +
> > +   static const struct {
> > +  const char *name;
> > +  unsigned int class;
> > +  int instance;
> > +   } legacy_names[] = {
> > +  { "render", RCS, 0 },
> > +  { "blt", BCS, 0 },
> > +  { "bsd", VCS, 0 },
> > +  { "bsd2", VCS, 1 },
> > +  { "vebox", VECS, 0 },
> > +   };
> 
> And these are the current ones, so also
> 
> Reviewed-by: Michel Thierry 

Thanks for sanity checking my string handling, pushed.
We should be ready now to use the new naming scheme in the error state,
I believe.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/guc: Change values for i915_guc_log_control

[Chris Wilson]

Quoting Sagar Arun Kamble (2018-01-12 05:53:28)
> 
> 
> On 1/11/2018 8:54 PM, Michal Wajdeczko wrote:
> > Today we have format mismatch between read/write operations
> > of i915_guc_log_control entry. For read we return (0, 1..4)
> > that represents disable/verbosity levels, but for write we
> > force user to follow internal structure format (0,1,9,11,13).
> 0x0, 0x1, 0x11, 0x21, 0x31
> > Let's hide internals from the user and accept same values
> > as we support for read and related guc_log_level modparam.
> >
> > Signed-off-by: Michal Wajdeczko 
> > Cc: Sagar Arun Kamble 
> > Cc: Daniele Ceraolo Spurio 
> > Cc: Tvrtko Ursulin 
> > Cc: Joonas Lahtinen 
> > Cc: Chris Wilson 
> Reviewed-by: Sagar Arun Kamble 

Thanks for the patches and review, pushed.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Avoid waitboosting on the active request (rev3)

[Chris Wilson]

Quoting Patchwork (2018-01-18 16:56:55)
> == Series Details ==
> 
> Series: drm/i915: Avoid waitboosting on the active request (rev3)
> URL   : https://patchwork.freedesktop.org/series/36453/
> State : success
> 
> == Summary ==
> 
> Test kms_frontbuffer_tracking:
> Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
> pass   -> FAIL   (shard-snb) fdo#101623 +1
> Test kms_flip:
> Subgroup vblank-vs-modeset-suspend-interruptible:
> pass   -> SKIP   (shard-hsw) fdo#103540
> Subgroup plain-flip-ts-check:
> fail   -> PASS   (shard-hsw) fdo#100368

Added Joonas' r-b from earlier, and pushed. Thanks all,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] drm-misc-next-fixes

[Gustavo Padovan]

Hi Dave,

A few fixes for 4.16. Please pull. Thanks.

drm-misc-next-fixes-2018-01-18:
Fixes for 4.16:

Fixes one Kconfig issue and a enable some panels to work properly.
There is also a fix of error code return in sun4i.
The following changes since commit a1c55bccf6004ec9fbcf892328f9658767aa22bb:

  drm/panel: lvds: Add support for the power-supply property (2018-01-05 
10:00:14 +0100)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2018-01-18

for you to fetch changes up to 341a0ffceaa44660c43d219a3b2569ebbd7d3ad1:

  drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig 
(2018-01-17 10:10:18 +0100)


Fixes for 4.16:

Fixes one Kconfig issue and a enable some panels to work properly.
There is also a fix of error code return in sun4i.


Dan Carpenter (1):
  drm/sun4i: Fix error code in sun4i_tcon_bind()

Hans de Goede (1):
  drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig

Maxime Ripard (1):
  drm/panel: lvds: Handle the optional regulator case properly

 drivers/gpu/drm/Kconfig|  8 
 drivers/gpu/drm/panel/panel-lvds.c | 11 +--
 drivers/gpu/drm/sun4i/sun4i_tcon.c |  2 +-
 3 files changed, 14 insertions(+), 7 deletions(-)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 00/99] XArray version 6

[Matthew Wilcox]

On Thu, Jan 18, 2018 at 05:56:12PM +0100, David Sterba wrote:
> On Thu, Jan 18, 2018 at 08:48:43AM -0800, Matthew Wilcox wrote:
> > Thank you!  I shall attempt to debug.  Was this with a btrfs root
> > filesystem?  I'm most suspicious of those patches right now, since they've
> > received next to no testing.  I'm going to put together a smaller patchset
> > which just does the page cache conversion and nothing else in the hope
> > that we can get that merged this year.
> 
> No, the root is ext3 and there was no btrfs filesytem mounted at the
> time.

Found it; I was missing a prerequisite patch.  New (smaller) patch series
coming soon.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/dp: Fix compilation of intel_dp_hdcp_check_link

[Sean Paul]

On Thu, Jan 18, 2018 at 04:10:25PM +, Chris Wilson wrote:
> drivers/gpu/drm/i915/intel_dp.c: In function ‘intel_dp_hdcp_check_link’:
> drivers/gpu/drm/i915/intel_dp.c:5191:26: error: ?: using integer constants in 
> boolean context [-Werror=int-in-bool-context]
>return ret >= 0 ? -EIO : ret;
> 
> Fixes: 20f24d776d1b ("drm/i915: Implement HDCP for DisplayPort")
> Signed-off-by: Chris Wilson 

Thanks for the patch! Applied to the topic branch.

Sean

> Cc: Daniel Vetter 
> Cc: Ramalingam C 
> Cc: Sean Paul 
> Cc: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 68229f53d5b8..0f2290c7bede 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5184,12 +5184,14 @@ bool intel_dp_hdcp_check_link(struct 
> intel_digital_port *intel_dig_port)
>  {
>   ssize_t ret;
>   u8 bstatus;
> +
>   ret = drm_dp_dpcd_read(_dig_port->dp.aux, DP_AUX_HDCP_BSTATUS,
>  , 1);
>   if (ret != 1) {
>   DRM_ERROR("Read bstatus from DP/AUX failed (%zd)\n", ret);
> - return ret >= 0 ? -EIO : ret;
> + return false;
>   }
> +
>   return !(bstatus & (DP_BSTATUS_LINK_FAILURE | DP_BSTATUS_REAUTH_REQ));
>  }
>  
> -- 
> 2.15.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 00/99] XArray version 6

[David Sterba]

On Thu, Jan 18, 2018 at 08:48:43AM -0800, Matthew Wilcox wrote:
> Thank you!  I shall attempt to debug.  Was this with a btrfs root
> filesystem?  I'm most suspicious of those patches right now, since they've
> received next to no testing.  I'm going to put together a smaller patchset
> which just does the page cache conversion and nothing else in the hope
> that we can get that merged this year.

No, the root is ext3 and there was no btrfs filesytem mounted at the
time.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Avoid waitboosting on the active request (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Avoid waitboosting on the active request (rev3)
URL   : https://patchwork.freedesktop.org/series/36453/
State : success

== Summary ==

Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
pass   -> FAIL   (shard-snb) fdo#101623 +1
Test kms_flip:
Subgroup vblank-vs-modeset-suspend-interruptible:
pass   -> SKIP   (shard-hsw) fdo#103540
Subgroup plain-flip-ts-check:
fail   -> PASS   (shard-hsw) fdo#100368

fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368

shard-hswtotal:2753 pass:1725 dwarn:1   dfail:0   fail:10  skip:1016 
time:15283s
shard-snbtotal:2753 pass:1318 dwarn:1   dfail:0   fail:11  skip:1423 
time:7925s
Blacklisted hosts:
shard-apltotal:2753 pass:1716 dwarn:1   dfail:0   fail:21  skip:1015 
time:14045s
shard-kbltotal:2745 pass:1830 dwarn:1   dfail:0   fail:22  skip:891 
time:10410s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7708/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 00/99] XArray version 6

[Matthew Wilcox]

On Thu, Jan 18, 2018 at 05:07:50PM +0100, David Sterba wrote:
> On Wed, Jan 17, 2018 at 12:20:24PM -0800, Matthew Wilcox wrote:
> > From: Matthew Wilcox 
> > 
> > This version of the XArray has no known bugs.
> 
> I've booted this patchset on 2 boxes, both had random problems during
> boot. On one I was not able to diagnose what went wrong. On the other
> one the system booted up to userspace and failed to set up networking.
> Serial console worked and the network service complained about wrong
> format of /usr/share/wicked/schema/team.xml . That's supposed to be a
> text file, though hexdump showed me lots of zeros. Trimmed output:
> 
>   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
> *
> (similar output here)
> *
> 0a10  00 00 00 00 00 00 00 00  11 03 00 00 00 00 00 00  ||
> 0a20  20 8b 7f 01 00 00 00 00  a0 84 7d 01 00 00 00 00  | .}.|
> 0a30  00 00 00 00 00 00 00 00  10 89 7f 01 00 00 00 00  ||
> 0a40  a0 84 7d 01 00 00 00 00  00 00 00 00 00 00 00 00  |..}.|
> 0a50  80 8a 7f 01 00 00 00 00  e0 cf 7d 01 00 00 00 00  |..}.|
> 0a60  00 00 00 00 00 00 00 00  60 8a 7f 01 00 00 00 00  |`...|
> 0a70  a0 84 7d 01 00 00 00 00  00 00 00 00 00 00 00 00  |..}.|
> 0a80  30 89 7f 01 00 00 00 00  a0 84 7d 01 00 00 00 00  |0.}.|
> 0a90  00 00 00 00 00 00 00 00  60 f2 7f 01 00 00 00 00  |`...|
> 0aa0  40 fd 7e 01 00 00 00 00  00 00 00 00 00 00 00 00  |@.~.|
> 0ab0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
> *
> 1000  3e 0a 20 20 3c 2f 6d 65  74 68 6f 64 3e 0a 3c 2f  |>.  . 1010  73 65 72 76 69 63 65 3e  0a   |service>.|
> 
> There's something at the end of the file that does look like a xml fragment.
> The file size is 4121. This looks to me like exactly the first page of the 
> file
> was not read correctly.
> 
> The xml file is supposed to be read-only during startup, so there was no write
> in flight. 'rpm -Vv' reported only this file corrupted. Booting to other
> kernels was fine, network up, and the file was ok again. So the
> corruption happened only in memory, which leads me to conclusion that
> there is an unknown bug in your patchset.

Thank you!  I shall attempt to debug.  Was this with a btrfs root
filesystem?  I'm most suspicious of those patches right now, since they've
received next to no testing.  I'm going to put together a smaller patchset
which just does the page cache conversion and nothing else in the hope
that we can get that merged this year.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] intel: Future-proof ring names for aubinator_error_decode

[Michel Thierry]

On 1/17/2018 7:47 AM, Chris Wilson wrote:

The kernel is moving to a $class$instance naming scheme in preparation
for accommodating more rings in the future in a consistent manner. It is
already using the naming scheme internally, and now we are looking at
updating some soft-ABI such as the error state to use the new naming
scheme. This of course means we need to teach aubinator_error_decode how
to map both sets of ring names onto its register maps.

Signed-off-by: Chris Wilson 
Cc: Michel Thierry 
Cc: Michal Wajdeczko 
Cc: Tvrtko Ursulin 
Cc: Lionel Landwerlin 
Cc: Kenneth Graunke 
---
  src/intel/tools/aubinator_error_decode.c | 122 +--
  1 file changed, 98 insertions(+), 24 deletions(-)

diff --git a/src/intel/tools/aubinator_error_decode.c 
b/src/intel/tools/aubinator_error_decode.c
index 9dd70790e1..01c6a7a365 100644
--- a/src/intel/tools/aubinator_error_decode.c
+++ b/src/intel/tools/aubinator_error_decode.c
@@ -74,40 +74,95 @@ print_register(struct gen_spec *spec, const char *name, 
uint32_t reg)
  }
  
  struct ring_register_mapping {

-   const char *ring_name;
+   unsigned ring_class;
+   unsigned ring_instance;
 const char *register_name;
  };
  
+enum {

+   RCS,
+   BCS,
+   VCS,
+   VECS,
+};
+
  static const struct ring_register_mapping acthd_registers[] = {
-   { "blt", "BCS_ACTHD_UDW" },
-   { "bsd", "VCS_ACTHD_UDW" },
-   { "bsd2", "VCS2_ACTHD_UDW" },
-   { "render", "ACTHD_UDW" },
-   { "vebox", "VECS_ACTHD_UDW" },
+   { BCS, 0, "BCS_ACTHD_UDW" },
+   { VCS, 0, "VCS_ACTHD_UDW" },
+   { VCS, 1, "VCS2_ACTHD_UDW" },
+   { RCS, 0, "ACTHD_UDW" },
+   { VECS, 0, "VECS_ACTHD_UDW" },
  };
  
  static const struct ring_register_mapping ctl_registers[] = {

-   { "blt", "BCS_RING_BUFFER_CTL" },
-   { "bsd", "VCS_RING_BUFFER_CTL" },
-   { "bsd2", "VCS2_RING_BUFFER_CTL" },
-   { "render", "RCS_RING_BUFFER_CTL" },
-   { "vebox", "VECS_RING_BUFFER_CTL" },
+   { BCS, 0, "BCS_RING_BUFFER_CTL" },
+   { VCS, 0, "VCS_RING_BUFFER_CTL" },
+   { VCS, 1, "VCS2_RING_BUFFER_CTL" },
+   { RCS, 0, "RCS_RING_BUFFER_CTL" },
+   { VECS, 0,  "VECS_RING_BUFFER_CTL" },
  };
  
  static const struct ring_register_mapping fault_registers[] = {

-   { "blt", "BCS_FAULT_REG" },
-   { "bsd", "VCS_FAULT_REG" },
-   { "render", "RCS_FAULT_REG" },
-   { "vebox", "VECS_FAULT_REG" },
+   { BCS, 0, "BCS_FAULT_REG" },
+   { VCS, 0, "VCS_FAULT_REG" },
+   { RCS, 0, "RCS_FAULT_REG" },
+   { VECS, 0, "VECS_FAULT_REG" },
  };
  
+static int ring_name_to_class(const char *ring_name,

+  unsigned int *class)
+{
+   static const char *class_names[] = {
+  [RCS] = "rcs",
+  [BCS] = "bcs",
+  [VCS] = "vcs",
+  [VECS] = "vecs",
+   };


This will match the new names in the error state, e.g.

rcs0 command stream:
...
bcs0 command stream:
...
vcs0 command stream:
...
vcs1 command stream:
...
vecs0 command stream:
...


+   for (size_t i = 0; i < ARRAY_SIZE(class_names); i++) {
+  if (strcmp(ring_name, class_names[i]))
+ continue;
+
+  *class = i;
+  return atoi(ring_name + strlen(class_names[i]));
+   }
+
+   static const struct {
+  const char *name;
+  unsigned int class;
+  int instance;
+   } legacy_names[] = {
+  { "render", RCS, 0 },
+  { "blt", BCS, 0 },
+  { "bsd", VCS, 0 },
+  { "bsd2", VCS, 1 },
+  { "vebox", VECS, 0 },
+   };


And these are the current ones, so also

Reviewed-by: Michel Thierry 


+   for (size_t i = 0; i < ARRAY_SIZE(legacy_names); i++) {
+  if (strcmp(ring_name, legacy_names[i].name))
+ continue;
+
+  *class = legacy_names[i].class;
+  return legacy_names[i].instance;
+   }
+
+   return -1;
+}
+
  static const char *
  register_name_from_ring(const struct ring_register_mapping *mapping,
  unsigned nb_mapping,
  const char *ring_name)
  {
+   unsigned int class;
+   int instance;
+
+   instance = ring_name_to_class(ring_name, );
+   if (instance < 0)
+  return NULL;
+
 for (unsigned i = 0; i < nb_mapping; i++) {
-  if (strcmp(mapping[i].ring_name, ring_name) == 0)
+  if (mapping[i].ring_class == class &&
+  mapping[i].ring_instance == instance)
   return mapping[i].register_name;
 }
 return NULL;
@@ -117,16 +172,35 @@ static const char *
  instdone_register_for_ring(const struct gen_device_info *devinfo,
 const char *ring_name)
  {
-   if (strcmp(ring_name, "blt") == 0)
-  return "BCS_INSTDONE";
-   else if (strcmp(ring_name, "vebox") == 0)
-  return "VECS_INSTDONE";
-   else if (strcmp(ring_name, "bsd") == 0)
-  return "VCS_INSTDONE";
-   else if (strcmp(ring_name, "render") == 0) {
+   unsigned int class;
+   int instance;
+
+   instance = 

Re: [Intel-gfx] [PATCH] drm/i915: vbt defs typo fixes

[Adam Jackson]

On Thu, 2018-01-18 at 17:06 +0200, Jani Nikula wrote:
> No more sing-a-ling.
> 
> Reported-by: Adam Jackson 

Why'd you omit the typos I reported in tools/intel_vbt_decode.c ?

- ajax
___
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/bios: add DP max link rate to VBT child device struct (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/bios: add DP max link rate to VBT child device struct (rev2)
URL   : https://patchwork.freedesktop.org/series/36701/
State : success

== Summary ==

Series 36701v2 drm/i915/bios: add DP max link rate to VBT child device struct
https://patchwork.freedesktop.org/api/1.0/series/36701/revisions/2/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test kms_chamelium:
Subgroup dp-crc-fast:
dmesg-fail -> PASS   (fi-kbl-7500u) fdo#103841

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:420s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:429s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:483s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:485s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:490s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:465s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:466s
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:277s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:511s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:398s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:399s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:411s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:456s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:418s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:462s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:501s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:454s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:500s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:588s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:428s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:507s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:535s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:487s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:476s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:432s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:525s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:398s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:576s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:469s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:420s

2c42c3d90f29dc7e0914c7b4498f4da93f0e5ac8 drm-tip: 2018y-01m-18d-15h-19m-38s UTC 
integration manifest
ee2e24cadbf7 drm/i915/bios: add DP max link rate to VBT child device struct

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7712/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 7/7] drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON

[Sharma, Shashank]

Regards

Shashank


On 1/18/2018 3:00 PM, Maarten Lankhorst wrote:

Op 18-01-18 om 07:27 schreef Sharma, Shashank:

Regards

Shashank


On 1/17/2018 11:57 PM, Ville Syrjälä wrote:

On Fri, Jan 05, 2018 at 03:15:35PM +0530, Shashank Sharma wrote:

LSPCON chips can generate YCBCR outputs, if asked nicely :).

In order to generate YCBCR 4:2:0 outputs, a source must:
- send YCBCR 4:4:4 signals to LSPCON
- program color space as 4:2:0 in AVI infoframes

Whereas for YCBCR 4:4:4 outputs, the source must:
- send YCBCR 4:4:4 signals to LSPCON
- program color space as 4:4:4 in AVI infoframes

So for both 4:2:0 as well as 4:4:4 outputs, we are driving the
pipe for YCBCR 4:4:4 output, but AVI infoframe's color space
information indicates LSPCON FW to start scaling down from YCBCR
4:4:4 and generate YCBCR 4:2:0 output. As the scaling is done by
LSPCON device, we need not to reserve a scaler for 4:2:0 outputs.

V2: rebase
V3: Addressed review comments from Ville
  - add enum crtc_output_format instead of bool ycbcr420
  - use crtc_output_format=4:4:4 for modeset of LSPCON 4:2:0 output
cases in this way we will have YCBCR 4:4:4 framework ready (except
the ABI part)

Cc: Ville Syrjala 
Cc: Maarten Lankhorst 
Signed-off-by: Shashank Sharma 
---
   drivers/gpu/drm/i915/i915_reg.h |  2 ++
   drivers/gpu/drm/i915/intel_ddi.c|  7 +++
   drivers/gpu/drm/i915/intel_dp.c | 10 ++
   drivers/gpu/drm/i915/intel_drv.h|  2 ++
   drivers/gpu/drm/i915/intel_lspcon.c | 28 
   5 files changed, 49 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 966e4df..45ee264 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8547,6 +8547,8 @@ enum skl_power_gate {
   #define TRANS_MSA_MISC(tran) _MMIO_TRANS2(tran, _TRANSA_MSA_MISC)
 #define  TRANS_MSA_SYNC_CLK(1<<0)
+#define  TRANS_MSA_SAMPLING_444(2<<1)
+#define  TRANS_MSA_CLRSP_YCBCR(2<<3)
   #define  TRANS_MSA_6_BPC(0<<5)
   #define  TRANS_MSA_8_BPC(1<<5)
   #define  TRANS_MSA_10_BPC(2<<5)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 7b89f2a..7616f6f 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1499,6 +1499,13 @@ void intel_ddi_set_pipe_settings(const struct 
intel_crtc_state *crtc_state)
   break;
   }
   +/*
+ * As per DP 1.2 spec section 2.3.4.3 while sending
+ * YCBCR 444 signals we should program MSA MISC1/0 fields with
+ * colorspace information.
+ */
+if (crtc_state->output_format == CRTC_OUTPUT_YCBCR444)
+temp |= TRANS_MSA_SAMPLING_444 | TRANS_MSA_CLRSP_YCBCR;

This fails to state that we're indicating BT.601 encoding. I think we
should spell that out explicitly.

Agree, I will add this in comments.

   I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp);
   }
   diff --git a/drivers/gpu/drm/i915/intel_dp.c 
b/drivers/gpu/drm/i915/intel_dp.c
index 35c5299..3bf82ea 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1613,6 +1613,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
   struct drm_display_mode *adjusted_mode = 
_config->base.adjusted_mode;
   struct intel_dp *intel_dp = enc_to_intel_dp(>base);
+struct intel_lspcon *lspcon = enc_to_intel_lspcon(>base);
   enum port port = encoder->port;
   struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc);
   struct intel_connector *intel_connector = intel_dp->attached_connector;
@@ -1642,6 +1643,15 @@ intel_dp_compute_config(struct intel_encoder *encoder,
   if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv) && port != PORT_A)
   pipe_config->has_pch_encoder = true;
   +if (lspcon->active) {
+struct drm_connector *connector = _connector->base;
+
+if (lspcon_ycbcr420_config(connector, pipe_config)) {
+pipe_config->output_format = CRTC_OUTPUT_YCBCR444;

I think I'd like to see all compute_config hooks explicitly set the
outout_format (to RGB usually obviously).

That's the one I was talking about in previous patch. If we keep 
output_format_RGB = 0, we need
not to do this, as reset of the pipe_config will automatically make it RGB.

+lspcon->output_format = CRTC_OUTPUT_YCBCR420;

You should not modify any non-atomic state like that in compute_config.

Please help me to understand this better, Can you elaborate a bit more on:
- Why is this a non-atomic state ?

Because lspcon->output_format is modified even if a commit is TEST_ONLY..

This will break if you do a nonblocking modeset vs TEST_ONLY, it could commit the 
wrong lspcon->output_format. :)

- What is the right place we should modify it ?

[Intel-gfx] [PATCH] drm/i915/dp: Fix compilation of intel_dp_hdcp_check_link

[Chris Wilson]

drivers/gpu/drm/i915/intel_dp.c: In function ‘intel_dp_hdcp_check_link’:
drivers/gpu/drm/i915/intel_dp.c:5191:26: error: ?: using integer constants in 
boolean context [-Werror=int-in-bool-context]
   return ret >= 0 ? -EIO : ret;

Fixes: 20f24d776d1b ("drm/i915: Implement HDCP for DisplayPort")
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Ramalingam C 
Cc: Sean Paul 
Cc: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dp.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 68229f53d5b8..0f2290c7bede 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5184,12 +5184,14 @@ bool intel_dp_hdcp_check_link(struct intel_digital_port 
*intel_dig_port)
 {
ssize_t ret;
u8 bstatus;
+
ret = drm_dp_dpcd_read(_dig_port->dp.aux, DP_AUX_HDCP_BSTATUS,
   , 1);
if (ret != 1) {
DRM_ERROR("Read bstatus from DP/AUX failed (%zd)\n", ret);
-   return ret >= 0 ? -EIO : ret;
+   return false;
}
+
return !(bstatus & (DP_BSTATUS_LINK_FAILURE | DP_BSTATUS_REAUTH_REQ));
 }
 
-- 
2.15.1

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

Re: [Intel-gfx] [PATCH v6 00/99] XArray version 6

[David Sterba]

On Wed, Jan 17, 2018 at 12:20:24PM -0800, Matthew Wilcox wrote:
> From: Matthew Wilcox 
> 
> This version of the XArray has no known bugs.

I've booted this patchset on 2 boxes, both had random problems during
boot. On one I was not able to diagnose what went wrong. On the other
one the system booted up to userspace and failed to set up networking.
Serial console worked and the network service complained about wrong
format of /usr/share/wicked/schema/team.xml . That's supposed to be a
text file, though hexdump showed me lots of zeros. Trimmed output:

  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
(similar output here)
*
0a10  00 00 00 00 00 00 00 00  11 03 00 00 00 00 00 00  ||
0a20  20 8b 7f 01 00 00 00 00  a0 84 7d 01 00 00 00 00  | .}.|
0a30  00 00 00 00 00 00 00 00  10 89 7f 01 00 00 00 00  ||
0a40  a0 84 7d 01 00 00 00 00  00 00 00 00 00 00 00 00  |..}.|
0a50  80 8a 7f 01 00 00 00 00  e0 cf 7d 01 00 00 00 00  |..}.|
0a60  00 00 00 00 00 00 00 00  60 8a 7f 01 00 00 00 00  |`...|
0a70  a0 84 7d 01 00 00 00 00  00 00 00 00 00 00 00 00  |..}.|
0a80  30 89 7f 01 00 00 00 00  a0 84 7d 01 00 00 00 00  |0.}.|
0a90  00 00 00 00 00 00 00 00  60 f2 7f 01 00 00 00 00  |`...|
0aa0  40 fd 7e 01 00 00 00 00  00 00 00 00 00 00 00 00  |@.~.|
0ab0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
1000  3e 0a 20 20 3c 2f 6d 65  74 68 6f 64 3e 0a 3c 2f  |>.  ..|

There's something at the end of the file that does look like a xml fragment.
The file size is 4121. This looks to me like exactly the first page of the file
was not read correctly.

The xml file is supposed to be read-only during startup, so there was no write
in flight. 'rpm -Vv' reported only this file corrupted. Booting to other
kernels was fine, network up, and the file was ok again. So the
corruption happened only in memory, which leads me to conclusion that
there is an unknown bug in your patchset.
___
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: vbt defs typo fixes

[Patchwork]

== Series Details ==

Series: drm/i915: vbt defs typo fixes
URL   : https://patchwork.freedesktop.org/series/36702/
State : success

== Summary ==

Series 36702v1 drm/i915: vbt defs typo fixes
https://patchwork.freedesktop.org/api/1.0/series/36702/revisions/1/mbox/

Test kms_chamelium:
Subgroup dp-crc-fast:
dmesg-fail -> PASS   (fi-kbl-7500u) fdo#103841

fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:418s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:425s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:374s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:486s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:486s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:484s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:464s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:462s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:277s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:507s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:390s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:400s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:410s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:459s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:423s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:459s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:499s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:456s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:502s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:586s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:426s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:517s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:527s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:485s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:494s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:431s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:526s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:396s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:565s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:470s
fi-skl-guc   total:288  pass:259  dwarn:0   dfail:0   fail:1   skip:28  
time:418s

2c42c3d90f29dc7e0914c7b4498f4da93f0e5ac8 drm-tip: 2018y-01m-18d-15h-19m-38s UTC 
integration manifest
ce05759810f7 drm/i915: vbt defs typo fixes

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7711/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v9 6/6] drm/i915: expose rcs topology through query uAPI

[Lionel Landwerlin]

On 18/01/18 15:36, Chris Wilson wrote:

Quoting Lionel Landwerlin (2018-01-18 15:22:27)

On 18/01/18 15:18, Chris Wilson wrote:

Quoting Lionel Landwerlin (2018-01-18 14:45:31)

+static int query_slice_info(struct drm_i915_private *dev_priv,
+   struct drm_i915_query_item *query_item)
+{
+   const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+   struct drm_i915_query_slice_info slice_info;
+
+   if (query_item->flags != 0)
+   return -EINVAL;
+
+   if (sseu->max_slices == 0)
+   return -ENODEV;

So conclusion was to cancel all queries and not report a 0-length result
for unsupported? :)
-Chris


Looking at GETPARAM, some queries return ENODEV if not supported (look
at SLICE_MASK, so did the same here).
Error are now reported in the s32 length field of the query item.
Unless you've screwed up the pointer to the items, in which case you'll
get an error through the ioctl() return value.

Does that sounds sensible?

It does, my fault for overlooking you had made the change. And even
added it to the ioctl comments, making me look twice as bad ;)
-Chris

One could hope that one day we have better tools than emails to review 
changes :)


Cheers,

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

Re: [Intel-gfx] [PATCH v3 7/7] drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON

[Sharma, Shashank]

Regards

Shashank


On 1/18/2018 9:05 PM, Ville Syrjälä wrote:

On Thu, Jan 18, 2018 at 09:00:50PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 1/18/2018 7:33 PM, Ville Syrjälä wrote:

On Thu, Jan 18, 2018 at 11:57:09AM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 1/17/2018 11:57 PM, Ville Syrjälä wrote:

On Fri, Jan 05, 2018 at 03:15:35PM +0530, Shashank Sharma wrote:

LSPCON chips can generate YCBCR outputs, if asked nicely :).

In order to generate YCBCR 4:2:0 outputs, a source must:
- send YCBCR 4:4:4 signals to LSPCON
- program color space as 4:2:0 in AVI infoframes

Whereas for YCBCR 4:4:4 outputs, the source must:
- send YCBCR 4:4:4 signals to LSPCON
- program color space as 4:4:4 in AVI infoframes

So for both 4:2:0 as well as 4:4:4 outputs, we are driving the
pipe for YCBCR 4:4:4 output, but AVI infoframe's color space
information indicates LSPCON FW to start scaling down from YCBCR
4:4:4 and generate YCBCR 4:2:0 output. As the scaling is done by
LSPCON device, we need not to reserve a scaler for 4:2:0 outputs.

V2: rebase
V3: Addressed review comments from Ville
   - add enum crtc_output_format instead of bool ycbcr420
   - use crtc_output_format=4:4:4 for modeset of LSPCON 4:2:0 output
 cases in this way we will have YCBCR 4:4:4 framework ready (except
 the ABI part)

Cc: Ville Syrjala 
Cc: Maarten Lankhorst 
Signed-off-by: Shashank Sharma 
---
drivers/gpu/drm/i915/i915_reg.h |  2 ++
drivers/gpu/drm/i915/intel_ddi.c|  7 +++
drivers/gpu/drm/i915/intel_dp.c | 10 ++
drivers/gpu/drm/i915/intel_drv.h|  2 ++
drivers/gpu/drm/i915/intel_lspcon.c | 28 
5 files changed, 49 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 966e4df..45ee264 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8547,6 +8547,8 @@ enum skl_power_gate {
#define TRANS_MSA_MISC(tran) _MMIO_TRANS2(tran, _TRANSA_MSA_MISC)

#define  TRANS_MSA_SYNC_CLK		(1<<0)

+#define  TRANS_MSA_SAMPLING_444(2<<1)
+#define  TRANS_MSA_CLRSP_YCBCR (2<<3)
#define  TRANS_MSA_6_BPC(0<<5)
#define  TRANS_MSA_8_BPC(1<<5)
#define  TRANS_MSA_10_BPC   (2<<5)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 7b89f2a..7616f6f 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1499,6 +1499,13 @@ void intel_ddi_set_pipe_settings(const struct 
intel_crtc_state *crtc_state)
break;
}

+	/*

+* As per DP 1.2 spec section 2.3.4.3 while sending
+* YCBCR 444 signals we should program MSA MISC1/0 fields with
+* colorspace information.
+*/
+   if (crtc_state->output_format == CRTC_OUTPUT_YCBCR444)
+   temp |= TRANS_MSA_SAMPLING_444 | TRANS_MSA_CLRSP_YCBCR;

This fails to state that we're indicating BT.601 encoding. I think we
should spell that out explicitly.

Agree, I will add this in comments.

I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp);
}

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c

index 35c5299..3bf82ea 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1613,6 +1613,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct drm_display_mode *adjusted_mode = 
_config->base.adjusted_mode;
struct intel_dp *intel_dp = enc_to_intel_dp(>base);
+   struct intel_lspcon *lspcon = enc_to_intel_lspcon(>base);
enum port port = encoder->port;
struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc);
struct intel_connector *intel_connector = intel_dp->attached_connector;
@@ -1642,6 +1643,15 @@ intel_dp_compute_config(struct intel_encoder *encoder,
if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv) && port != PORT_A)
pipe_config->has_pch_encoder = true;

+	if (lspcon->active) {

+   struct drm_connector *connector = _connector->base;
+
+   if (lspcon_ycbcr420_config(connector, pipe_config)) {
+   pipe_config->output_format = CRTC_OUTPUT_YCBCR444;

I think I'd like to see all compute_config hooks explicitly set the
outout_format (to RGB usually obviously).

That's the one I was talking about in previous patch. If we keep
output_format_RGB = 0, we need
not to do this, as reset of the pipe_config will automatically make it RGB.

IMO either we have INVALID=0 so that we use it to catch readout
fails, or we have no INVALID. Other options make little sense to me.

Its a minor thing, and doesn't really matter. I can change this.

+   lspcon->output_format = 

Re: [Intel-gfx] [PATCH] drm/i915/bios: add DP max link rate to VBT child device struct

[Ville Syrjälä]

On Thu, Jan 18, 2018 at 05:31:45PM +0200, Jani Nikula wrote:
> On Thu, 18 Jan 2018, David Weinehall  wrote:
> > On Thu, Jan 18, 2018 at 05:04:59PM +0200, Jani Nikula wrote:
> >> Update VBT defs to reflect revision 216. While at it, default the
> >> expected child device struct size to sizeof the size rather than a
> >> hardcoded value.
> >> 
> >> Cc: Rodrigo Vivi 
> >> Signed-off-by: Jani Nikula 
> >
> >
> >> ---
> >>  drivers/gpu/drm/i915/intel_bios.c | 8 +---
> >>  drivers/gpu/drm/i915/intel_vbt_defs.h | 2 ++
> >>  2 files changed, 7 insertions(+), 3 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> >> b/drivers/gpu/drm/i915/intel_bios.c
> >> index 51108ffc28d1..b820d595ebc8 100644
> >> --- a/drivers/gpu/drm/i915/intel_bios.c
> >> +++ b/drivers/gpu/drm/i915/intel_bios.c
> >> @@ -1323,11 +1323,13 @@ parse_general_definitions(struct drm_i915_private 
> >> *dev_priv,
> >>expected_size = LEGACY_CHILD_DEVICE_CONFIG_SIZE;
> >>} else if (bdb->version == 195) {
> >>expected_size = 37;
> >> -  } else if (bdb->version <= 197) {
> >> +  } else if (bdb->version <= 215) {
> >>expected_size = 38;
> >> +  } else if (bdb->version <= 216) {
> >> +  expected_size = 39;
> >>} else {
> >> -  expected_size = 38;
> >> -  BUILD_BUG_ON(sizeof(*child) < 38);
> >> +  expected_size = sizeof(*child);
> >> +  BUILD_BUG_ON(sizeof(*child) < 39);
> >>DRM_DEBUG_DRIVER("Expected child device config size for VBT 
> >> version %u not known; assuming %u\n",
> >> bdb->version, expected_size);
> >>}
> >> diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h 
> >> b/drivers/gpu/drm/i915/intel_vbt_defs.h
> >> index e3d7745a9151..bbb173e116b3 100644
> >> --- a/drivers/gpu/drm/i915/intel_vbt_defs.h
> >> +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
> >> @@ -412,6 +412,8 @@ struct child_device_config {
> >>u16 dp_gpio_pin_num;/* 195 */
> >>u8 dp_iboost_level:4;   /* 196 */
> >>u8 hdmi_iboost_level:4; /* 196 */
> >> +  u8 dp_max_link_rate_reserved:6; /* 216 */
> >> +  u8 dp_max_link_rate:2;  /* 216 CNL+ */
> >
> > Isn't the bitorder wrong here?
> 
> *facepalm*

Maybe we should add a comment specifying how we expect them
bitfields to work here. I can never remember which way they go.

-- 
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 v9 6/6] drm/i915: expose rcs topology through query uAPI

[Chris Wilson]

Quoting Lionel Landwerlin (2018-01-18 15:22:27)
> On 18/01/18 15:18, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2018-01-18 14:45:31)
> >> +static int query_slice_info(struct drm_i915_private *dev_priv,
> >> +   struct drm_i915_query_item *query_item)
> >> +{
> >> +   const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
> >> +   struct drm_i915_query_slice_info slice_info;
> >> +
> >> +   if (query_item->flags != 0)
> >> +   return -EINVAL;
> >> +
> >> +   if (sseu->max_slices == 0)
> >> +   return -ENODEV;
> > So conclusion was to cancel all queries and not report a 0-length result
> > for unsupported? :)
> > -Chris
> >
> Looking at GETPARAM, some queries return ENODEV if not supported (look 
> at SLICE_MASK, so did the same here).
> Error are now reported in the s32 length field of the query item.
> Unless you've screwed up the pointer to the items, in which case you'll 
> get an error through the ioctl() return value.
> 
> Does that sounds sensible?

It does, my fault for overlooking you had made the change. And even
added it to the ioctl comments, making me look twice as bad ;)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 7/7] drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON

[Ville Syrjälä]

On Thu, Jan 18, 2018 at 09:00:50PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 1/18/2018 7:33 PM, Ville Syrjälä wrote:
> > On Thu, Jan 18, 2018 at 11:57:09AM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 1/17/2018 11:57 PM, Ville Syrjälä wrote:
> >>> On Fri, Jan 05, 2018 at 03:15:35PM +0530, Shashank Sharma wrote:
>  LSPCON chips can generate YCBCR outputs, if asked nicely :).
> 
>  In order to generate YCBCR 4:2:0 outputs, a source must:
>  - send YCBCR 4:4:4 signals to LSPCON
>  - program color space as 4:2:0 in AVI infoframes
> 
>  Whereas for YCBCR 4:4:4 outputs, the source must:
>  - send YCBCR 4:4:4 signals to LSPCON
>  - program color space as 4:4:4 in AVI infoframes
> 
>  So for both 4:2:0 as well as 4:4:4 outputs, we are driving the
>  pipe for YCBCR 4:4:4 output, but AVI infoframe's color space
>  information indicates LSPCON FW to start scaling down from YCBCR
>  4:4:4 and generate YCBCR 4:2:0 output. As the scaling is done by
>  LSPCON device, we need not to reserve a scaler for 4:2:0 outputs.
> 
>  V2: rebase
>  V3: Addressed review comments from Ville
>    - add enum crtc_output_format instead of bool ycbcr420
>    - use crtc_output_format=4:4:4 for modeset of LSPCON 4:2:0 output
>  cases in this way we will have YCBCR 4:4:4 framework ready 
>  (except
>  the ABI part)
> 
>  Cc: Ville Syrjala 
>  Cc: Maarten Lankhorst 
>  Signed-off-by: Shashank Sharma 
>  ---
> drivers/gpu/drm/i915/i915_reg.h |  2 ++
> drivers/gpu/drm/i915/intel_ddi.c|  7 +++
> drivers/gpu/drm/i915/intel_dp.c | 10 ++
> drivers/gpu/drm/i915/intel_drv.h|  2 ++
> drivers/gpu/drm/i915/intel_lspcon.c | 28 
> 5 files changed, 49 insertions(+)
> 
>  diff --git a/drivers/gpu/drm/i915/i915_reg.h 
>  b/drivers/gpu/drm/i915/i915_reg.h
>  index 966e4df..45ee264 100644
>  --- a/drivers/gpu/drm/i915/i915_reg.h
>  +++ b/drivers/gpu/drm/i915/i915_reg.h
>  @@ -8547,6 +8547,8 @@ enum skl_power_gate {
> #define TRANS_MSA_MISC(tran) _MMIO_TRANS2(tran, _TRANSA_MSA_MISC)
> 
> #define  TRANS_MSA_SYNC_CLK   (1<<0)
>  +#define  TRANS_MSA_SAMPLING_444(2<<1)
>  +#define  TRANS_MSA_CLRSP_YCBCR  (2<<3)
> #define  TRANS_MSA_6_BPC  (0<<5)
> #define  TRANS_MSA_8_BPC  (1<<5)
> #define  TRANS_MSA_10_BPC (2<<5)
>  diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
>  b/drivers/gpu/drm/i915/intel_ddi.c
>  index 7b89f2a..7616f6f 100644
>  --- a/drivers/gpu/drm/i915/intel_ddi.c
>  +++ b/drivers/gpu/drm/i915/intel_ddi.c
>  @@ -1499,6 +1499,13 @@ void intel_ddi_set_pipe_settings(const struct 
>  intel_crtc_state *crtc_state)
>   break;
>   }
> 
>  +/*
>  + * As per DP 1.2 spec section 2.3.4.3 while sending
>  + * YCBCR 444 signals we should program MSA MISC1/0 fields with
>  + * colorspace information.
>  + */
>  +if (crtc_state->output_format == CRTC_OUTPUT_YCBCR444)
>  +temp |= TRANS_MSA_SAMPLING_444 | TRANS_MSA_CLRSP_YCBCR;
> >>> This fails to state that we're indicating BT.601 encoding. I think we
> >>> should spell that out explicitly.
> >> Agree, I will add this in comments.
>   I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp);
> }
> 
>  diff --git a/drivers/gpu/drm/i915/intel_dp.c 
>  b/drivers/gpu/drm/i915/intel_dp.c
>  index 35c5299..3bf82ea 100644
>  --- a/drivers/gpu/drm/i915/intel_dp.c
>  +++ b/drivers/gpu/drm/i915/intel_dp.c
>  @@ -1613,6 +1613,7 @@ intel_dp_compute_config(struct intel_encoder 
>  *encoder,
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   struct drm_display_mode *adjusted_mode = 
>  _config->base.adjusted_mode;
>   struct intel_dp *intel_dp = enc_to_intel_dp(>base);
>  +struct intel_lspcon *lspcon = 
>  enc_to_intel_lspcon(>base);
>   enum port port = encoder->port;
>   struct intel_crtc *intel_crtc = 
>  to_intel_crtc(pipe_config->base.crtc);
>   struct intel_connector *intel_connector = 
>  intel_dp->attached_connector;
>  @@ -1642,6 +1643,15 @@ intel_dp_compute_config(struct intel_encoder 
>  *encoder,
>   if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv) && port != 
>  PORT_A)
>   pipe_config->has_pch_encoder = true;
> 
>  +if (lspcon->active) {
>  +struct drm_connector *connector = 
>  

Re: [Intel-gfx] [PATCH v3 7/7] drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON

[Sharma, Shashank]

Regards

Shashank


On 1/18/2018 7:33 PM, Ville Syrjälä wrote:

On Thu, Jan 18, 2018 at 11:57:09AM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 1/17/2018 11:57 PM, Ville Syrjälä wrote:

On Fri, Jan 05, 2018 at 03:15:35PM +0530, Shashank Sharma wrote:

LSPCON chips can generate YCBCR outputs, if asked nicely :).

In order to generate YCBCR 4:2:0 outputs, a source must:
- send YCBCR 4:4:4 signals to LSPCON
- program color space as 4:2:0 in AVI infoframes

Whereas for YCBCR 4:4:4 outputs, the source must:
- send YCBCR 4:4:4 signals to LSPCON
- program color space as 4:4:4 in AVI infoframes

So for both 4:2:0 as well as 4:4:4 outputs, we are driving the
pipe for YCBCR 4:4:4 output, but AVI infoframe's color space
information indicates LSPCON FW to start scaling down from YCBCR
4:4:4 and generate YCBCR 4:2:0 output. As the scaling is done by
LSPCON device, we need not to reserve a scaler for 4:2:0 outputs.

V2: rebase
V3: Addressed review comments from Ville
  - add enum crtc_output_format instead of bool ycbcr420
  - use crtc_output_format=4:4:4 for modeset of LSPCON 4:2:0 output
cases in this way we will have YCBCR 4:4:4 framework ready (except
the ABI part)

Cc: Ville Syrjala 
Cc: Maarten Lankhorst 
Signed-off-by: Shashank Sharma 
---
   drivers/gpu/drm/i915/i915_reg.h |  2 ++
   drivers/gpu/drm/i915/intel_ddi.c|  7 +++
   drivers/gpu/drm/i915/intel_dp.c | 10 ++
   drivers/gpu/drm/i915/intel_drv.h|  2 ++
   drivers/gpu/drm/i915/intel_lspcon.c | 28 
   5 files changed, 49 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 966e4df..45ee264 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8547,6 +8547,8 @@ enum skl_power_gate {
   #define TRANS_MSA_MISC(tran) _MMIO_TRANS2(tran, _TRANSA_MSA_MISC)
   
   #define  TRANS_MSA_SYNC_CLK		(1<<0)

+#define  TRANS_MSA_SAMPLING_444(2<<1)
+#define  TRANS_MSA_CLRSP_YCBCR (2<<3)
   #define  TRANS_MSA_6_BPC (0<<5)
   #define  TRANS_MSA_8_BPC (1<<5)
   #define  TRANS_MSA_10_BPC(2<<5)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 7b89f2a..7616f6f 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1499,6 +1499,13 @@ void intel_ddi_set_pipe_settings(const struct 
intel_crtc_state *crtc_state)
break;
}
   
+	/*

+* As per DP 1.2 spec section 2.3.4.3 while sending
+* YCBCR 444 signals we should program MSA MISC1/0 fields with
+* colorspace information.
+*/
+   if (crtc_state->output_format == CRTC_OUTPUT_YCBCR444)
+   temp |= TRANS_MSA_SAMPLING_444 | TRANS_MSA_CLRSP_YCBCR;

This fails to state that we're indicating BT.601 encoding. I think we
should spell that out explicitly.

Agree, I will add this in comments.

I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp);
   }
   
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c

index 35c5299..3bf82ea 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1613,6 +1613,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct drm_display_mode *adjusted_mode = 
_config->base.adjusted_mode;
struct intel_dp *intel_dp = enc_to_intel_dp(>base);
+   struct intel_lspcon *lspcon = enc_to_intel_lspcon(>base);
enum port port = encoder->port;
struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc);
struct intel_connector *intel_connector = intel_dp->attached_connector;
@@ -1642,6 +1643,15 @@ intel_dp_compute_config(struct intel_encoder *encoder,
if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv) && port != PORT_A)
pipe_config->has_pch_encoder = true;
   
+	if (lspcon->active) {

+   struct drm_connector *connector = _connector->base;
+
+   if (lspcon_ycbcr420_config(connector, pipe_config)) {
+   pipe_config->output_format = CRTC_OUTPUT_YCBCR444;

I think I'd like to see all compute_config hooks explicitly set the
outout_format (to RGB usually obviously).

That's the one I was talking about in previous patch. If we keep
output_format_RGB = 0, we need
not to do this, as reset of the pipe_config will automatically make it RGB.

IMO either we have INVALID=0 so that we use it to catch readout
fails, or we have no INVALID. Other options make little sense to me.

Its a minor thing, and doesn't really matter. I can change this.

+   lspcon->output_format = CRTC_OUTPUT_YCBCR420;

You should not modify any non-atomic state like that in compute_config.

Please help me to understand this better, Can you 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: expose RCS topology to userspace

[Patchwork]

== Series Details ==

Series: drm/i915: expose RCS topology to userspace
URL   : https://patchwork.freedesktop.org/series/36696/
State : success

== Summary ==

Series 36696v1 drm/i915: expose RCS topology to userspace
https://patchwork.freedesktop.org/api/1.0/series/36696/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
pass   -> DMESG-FAIL (fi-elk-e7500) fdo#103989
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:422s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:427s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:374s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:489s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:282s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:485s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:493s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:470s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:459s
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:277s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:517s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:393s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:402s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:411s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:448s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:418s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:457s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:499s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:455s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:506s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:582s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:434s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:511s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:531s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:490s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:491s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:434s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:403s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:573s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:474s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:418s

88e8ed1dc6915fcc801fba00955ef83853942f62 drm-tip: 2018y-01m-18d-14h-19m-46s UTC 
integration manifest
3a4d9e4e691e drm/i915: expose rcs topology through query uAPI
8d15a5ac9362 drm/i915: add query uAPI
7a9757bcc564 drm/i915: add rcs topology to error state
2db7c14bff41 drm/i915/debugfs: add rcs topology entry
b28cd91603d5 drm/i915/debugfs: reuse max slice/subslices already stored in sseu
dff5d7cb8214 drm/i915: store all subslice masks

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7710/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915/bios: add DP max link rate to VBT child device struct

[Jani Nikula]

Update VBT defs to reflect revision 216. While at it, default the
expected child device struct size to sizeof the size rather than a
hardcoded value.

v2: Fix bit order (David)

Cc: Rodrigo Vivi 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_bios.c | 8 +---
 drivers/gpu/drm/i915/intel_vbt_defs.h | 2 ++
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 51108ffc28d1..b820d595ebc8 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1323,11 +1323,13 @@ parse_general_definitions(struct drm_i915_private 
*dev_priv,
expected_size = LEGACY_CHILD_DEVICE_CONFIG_SIZE;
} else if (bdb->version == 195) {
expected_size = 37;
-   } else if (bdb->version <= 197) {
+   } else if (bdb->version <= 215) {
expected_size = 38;
+   } else if (bdb->version <= 216) {
+   expected_size = 39;
} else {
-   expected_size = 38;
-   BUILD_BUG_ON(sizeof(*child) < 38);
+   expected_size = sizeof(*child);
+   BUILD_BUG_ON(sizeof(*child) < 39);
DRM_DEBUG_DRIVER("Expected child device config size for VBT 
version %u not known; assuming %u\n",
 bdb->version, expected_size);
}
diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h 
b/drivers/gpu/drm/i915/intel_vbt_defs.h
index e3d7745a9151..98dff6058d3c 100644
--- a/drivers/gpu/drm/i915/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
@@ -412,6 +412,8 @@ struct child_device_config {
u16 dp_gpio_pin_num;/* 195 */
u8 dp_iboost_level:4;   /* 196 */
u8 hdmi_iboost_level:4; /* 196 */
+   u8 dp_max_link_rate:2;  /* 216 CNL+ */
+   u8 dp_max_link_rate_reserved:6; /* 216 */
 } __packed;
 
 struct bdb_general_definitions {
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH] drm/i915/bios: add DP max link rate to VBT child device struct

[Jani Nikula]

On Thu, 18 Jan 2018, David Weinehall  wrote:
> On Thu, Jan 18, 2018 at 05:04:59PM +0200, Jani Nikula wrote:
>> Update VBT defs to reflect revision 216. While at it, default the
>> expected child device struct size to sizeof the size rather than a
>> hardcoded value.
>> 
>> Cc: Rodrigo Vivi 
>> Signed-off-by: Jani Nikula 
>
>
>> ---
>>  drivers/gpu/drm/i915/intel_bios.c | 8 +---
>>  drivers/gpu/drm/i915/intel_vbt_defs.h | 2 ++
>>  2 files changed, 7 insertions(+), 3 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
>> b/drivers/gpu/drm/i915/intel_bios.c
>> index 51108ffc28d1..b820d595ebc8 100644
>> --- a/drivers/gpu/drm/i915/intel_bios.c
>> +++ b/drivers/gpu/drm/i915/intel_bios.c
>> @@ -1323,11 +1323,13 @@ parse_general_definitions(struct drm_i915_private 
>> *dev_priv,
>>  expected_size = LEGACY_CHILD_DEVICE_CONFIG_SIZE;
>>  } else if (bdb->version == 195) {
>>  expected_size = 37;
>> -} else if (bdb->version <= 197) {
>> +} else if (bdb->version <= 215) {
>>  expected_size = 38;
>> +} else if (bdb->version <= 216) {
>> +expected_size = 39;
>>  } else {
>> -expected_size = 38;
>> -BUILD_BUG_ON(sizeof(*child) < 38);
>> +expected_size = sizeof(*child);
>> +BUILD_BUG_ON(sizeof(*child) < 39);
>>  DRM_DEBUG_DRIVER("Expected child device config size for VBT 
>> version %u not known; assuming %u\n",
>>   bdb->version, expected_size);
>>  }
>> diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h 
>> b/drivers/gpu/drm/i915/intel_vbt_defs.h
>> index e3d7745a9151..bbb173e116b3 100644
>> --- a/drivers/gpu/drm/i915/intel_vbt_defs.h
>> +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
>> @@ -412,6 +412,8 @@ struct child_device_config {
>>  u16 dp_gpio_pin_num;/* 195 */
>>  u8 dp_iboost_level:4;   /* 196 */
>>  u8 hdmi_iboost_level:4; /* 196 */
>> +u8 dp_max_link_rate_reserved:6; /* 216 */
>> +u8 dp_max_link_rate:2;  /* 216 CNL+ */
>
> Isn't the bitorder wrong here?

*facepalm*

>
>>  } __packed;
>>  
>>  struct bdb_general_definitions {
>> -- 
>> 2.11.0
>> 
>> ___
>> 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 v9 6/6] drm/i915: expose rcs topology through query uAPI

[Lionel Landwerlin]

On 18/01/18 15:18, Chris Wilson wrote:

Quoting Lionel Landwerlin (2018-01-18 14:45:31)

+static int query_slice_info(struct drm_i915_private *dev_priv,
+   struct drm_i915_query_item *query_item)
+{
+   const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+   struct drm_i915_query_slice_info slice_info;
+
+   if (query_item->flags != 0)
+   return -EINVAL;
+
+   if (sseu->max_slices == 0)
+   return -ENODEV;

So conclusion was to cancel all queries and not report a 0-length result
for unsupported? :)
-Chris

Looking at GETPARAM, some queries return ENODEV if not supported (look 
at SLICE_MASK, so did the same here).

Error are now reported in the s32 length field of the query item.
Unless you've screwed up the pointer to the items, in which case you'll 
get an error through the ioctl() return value.


Does that sounds sensible?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v9 6/6] drm/i915: expose rcs topology through query uAPI

[Chris Wilson]

Quoting Lionel Landwerlin (2018-01-18 14:45:31)
> +static int query_slice_info(struct drm_i915_private *dev_priv,
> +   struct drm_i915_query_item *query_item)
> +{
> +   const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
> +   struct drm_i915_query_slice_info slice_info;
> +
> +   if (query_item->flags != 0)
> +   return -EINVAL;
> +
> +   if (sseu->max_slices == 0)
> +   return -ENODEV;

So conclusion was to cancel all queries and not report a 0-length result
for unsupported? :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: vbt defs typo fixes

[David Weinehall]

On Thu, Jan 18, 2018 at 05:06:13PM +0200, Jani Nikula wrote:
> No more sing-a-ling.

LOL, well spotted.

> Reported-by: Adam Jackson 
> Signed-off-by: Jani Nikula 

Reviewed-by: David Weinehall 

> ---
>  drivers/gpu/drm/i915/intel_vbt_defs.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h 
> b/drivers/gpu/drm/i915/intel_vbt_defs.h
> index bbb173e116b3..fa4f67d3f261 100644
> --- a/drivers/gpu/drm/i915/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
> @@ -227,7 +227,7 @@ struct bdb_general_features {
>  #define DEVICE_TYPE_COMPOSITE_OUTPUT (1 << 9)
>  #define DEVICE_TYPE_DUAL_CHANNEL (1 << 8)
>  #define DEVICE_TYPE_HIGH_SPEED_LINK  (1 << 6)
> -#define DEVICE_TYPE_LVDS_SINGALING   (1 << 5)
> +#define DEVICE_TYPE_LVDS_SIGNALING   (1 << 5)
>  #define DEVICE_TYPE_TMDS_DVI_SIGNALING   (1 << 4)
>  #define DEVICE_TYPE_VIDEO_SIGNALING  (1 << 3)
>  #define DEVICE_TYPE_DISPLAYPORT_OUTPUT   (1 << 2)
> @@ -243,7 +243,7 @@ struct bdb_general_features {
>DEVICE_TYPE_MIPI_OUTPUT |  \
>DEVICE_TYPE_COMPOSITE_OUTPUT | \
>DEVICE_TYPE_DUAL_CHANNEL | \
> -  DEVICE_TYPE_LVDS_SINGALING |   \
> +  DEVICE_TYPE_LVDS_SIGNALING |   \
>DEVICE_TYPE_TMDS_DVI_SIGNALING |   \
>DEVICE_TYPE_VIDEO_SIGNALING |  \
>DEVICE_TYPE_DISPLAYPORT_OUTPUT |   \
> @@ -253,7 +253,7 @@ struct bdb_general_features {
>   (DEVICE_TYPE_INTERNAL_CONNECTOR |   \
>DEVICE_TYPE_MIPI_OUTPUT |  \
>DEVICE_TYPE_COMPOSITE_OUTPUT | \
> -  DEVICE_TYPE_LVDS_SINGALING |   \
> +  DEVICE_TYPE_LVDS_SIGNALING |   \
>DEVICE_TYPE_TMDS_DVI_SIGNALING |   \
>DEVICE_TYPE_VIDEO_SIGNALING |  \
>DEVICE_TYPE_DISPLAYPORT_OUTPUT |   \
> -- 
> 2.11.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v8 6/6] drm/i915: expose rcs topology through query uAPI

[Lionel Landwerlin]

On 18/01/18 12:46, Tvrtko Ursulin wrote:


On 17/01/2018 15:39, Lionel Landwerlin wrote:

With the introduction of asymmetric slices in CNL, we cannot rely on
the previous SUBSLICE_MASK getparam to tell userspace what subslices
are available. Here we introduce a more detailed way of querying the
Gen's GPU topology that doesn't aggregate numbers.

This is essential for monitoring parts of the GPU with the OA unit,
because counters need to be normalized to the number of
EUs/subslices/slices. The current aggregated numbers like EU_TOTAL do
not gives us sufficient information.

As a bonus we can draw representations of the GPU :

 https://imgur.com/a/vuqpa

v2: Rename uapi struct s/_mask/_info/ (Tvrtko)
 Report max_slice/subslice/eus_per_subslice rather than strides 
(Tvrtko)

 Add uapi macros to read data from *_info structs (Tvrtko)

v3: Use !!(v & DRM_I915_BIT()) for uapi macros instead of custom 
shifts (Tvrtko)


v4: factorize query item writting (Tvrtko)
 tweak uapi struct/define names (Tvrtko)

v5: Replace ALIGN() macro (Chris)

v6: Updated uapi comments (Tvrtko)
 Moved flags != 0 checks into vfuncs (Tvrtko)

Signed-off-by: Lionel Landwerlin 
---
  drivers/gpu/drm/i915/i915_query.c | 105 
++

  include/uapi/drm/i915_drm.h   |  68 
  2 files changed, 173 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_query.c 
b/drivers/gpu/drm/i915/i915_query.c

index 5aa886313cf9..5d1386db8e7b 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -25,8 +25,113 @@
  #include "i915_drv.h"
  #include 
  +static int copy_query_data(struct drm_i915_query_item *query_item,
+   const void *item_ptr, u32 item_length,
+   const void *data_ptr, u32 data_length)
+{
+    u32 total_length = item_length + data_length;
+
+    BUG_ON(add_overflows(item_length, data_length));


Please change to if (WARN_ON_ONCE(...)) return -EINVAL;. Or even 
GEM_WARN_ON. This can only happen during development so is enough.


Thanks, done.




+
+    if (query_item->length == 0)
+    return total_length;
+
+    if (query_item->length < total_length)
+    return -EINVAL;


Did we talk about whether this check should be != or < yet? != would 
sound safer to me, or you want to allow extending the queries in the 
future and keeping the same id?


Like Chris said :)




+
+    if (copy_to_user(u64_to_user_ptr(query_item->data_ptr),
+ item_ptr, item_length))
+    return -EFAULT;
+
+    if (copy_to_user(u64_to_user_ptr(query_item->data_ptr + 
item_length),

+ data_ptr, data_length))
+    return -EFAULT;
+
+    return total_length;
+}
+
+static int query_slice_info(struct drm_i915_private *dev_priv,
+    struct drm_i915_query_item *query_item)
+{
+    const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+    struct drm_i915_query_slice_info slice_info;
+
+    if (query_item->flags != 0)
+    return -EINVAL;
+
+    if (sseu->max_slices == 0)
+    return -ENODEV;
+
+    /*
+ * If we ever change the internal slice mask data type, we'll 
need to

+ * update this function.
+ */
+    BUILD_BUG_ON(sizeof(u8) != sizeof(sseu->slice_mask));
+
+    memset(_info, 0, sizeof(slice_info));
+    slice_info.max_slices = sseu->max_slices;
+
+    return copy_query_data(query_item, _info, sizeof(slice_info),
+   >slice_mask, sizeof(sseu->slice_mask));
+}
+
+static int query_subslice_info(struct drm_i915_private *dev_priv,
+   struct drm_i915_query_item *query_item)
+{
+    const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+    struct drm_i915_query_subslice_info subslice_info;
+    u32 data_length;
+
+    if (query_item->flags != 0)
+    return -EINVAL;
+
+    if (sseu->max_slices == 0)
+    return -ENODEV;
+
+    memset(_info, 0, sizeof(subslice_info));
+    subslice_info.max_slices = sseu->max_slices;
+    subslice_info.max_subslices = sseu->max_subslices;
+
+    data_length = subslice_info.max_slices *
+    DIV_ROUND_UP(subslice_info.max_subslices,
+ sizeof(sseu->subslice_mask[0]) * BITS_PER_BYTE);
+
+    return copy_query_data(query_item,
+   _info, sizeof(subslice_info),
+   sseu->subslice_mask, data_length);
+}
+
+static int query_eu_info(struct drm_i915_private *dev_priv,
+ struct drm_i915_query_item *query_item)
+{
+    const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+    struct drm_i915_query_eu_info eu_info;
+    u32 data_length;
+
+    if (query_item->flags != 0)
+    return -EINVAL;
+
+    if (sseu->max_slices == 0)
+    return -ENODEV;
+
+    memset(_info, 0, sizeof(eu_info));
+    eu_info.max_slices = sseu->max_slices;
+    eu_info.max_subslices = sseu->max_subslices;
+    eu_info.max_eus_per_subslice = sseu->max_eus_per_subslice;
+
+    data_length = eu_info.max_slices * 

Re: [Intel-gfx] [PATCH] drm/i915: vbt defs typo fixes

[Chris Wilson]

Quoting Jani Nikula (2018-01-18 15:06:13)
> No more sing-a-ling.
> 
> Reported-by: Adam Jackson 
> Signed-off-by: Jani Nikula 
You're-my-ding-a-ling-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/bios: add DP max link rate to VBT child device struct

[David Weinehall]

On Thu, Jan 18, 2018 at 05:04:59PM +0200, Jani Nikula wrote:
> Update VBT defs to reflect revision 216. While at it, default the
> expected child device struct size to sizeof the size rather than a
> hardcoded value.
> 
> Cc: Rodrigo Vivi 
> Signed-off-by: Jani Nikula 


> ---
>  drivers/gpu/drm/i915/intel_bios.c | 8 +---
>  drivers/gpu/drm/i915/intel_vbt_defs.h | 2 ++
>  2 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index 51108ffc28d1..b820d595ebc8 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1323,11 +1323,13 @@ parse_general_definitions(struct drm_i915_private 
> *dev_priv,
>   expected_size = LEGACY_CHILD_DEVICE_CONFIG_SIZE;
>   } else if (bdb->version == 195) {
>   expected_size = 37;
> - } else if (bdb->version <= 197) {
> + } else if (bdb->version <= 215) {
>   expected_size = 38;
> + } else if (bdb->version <= 216) {
> + expected_size = 39;
>   } else {
> - expected_size = 38;
> - BUILD_BUG_ON(sizeof(*child) < 38);
> + expected_size = sizeof(*child);
> + BUILD_BUG_ON(sizeof(*child) < 39);
>   DRM_DEBUG_DRIVER("Expected child device config size for VBT 
> version %u not known; assuming %u\n",
>bdb->version, expected_size);
>   }
> diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h 
> b/drivers/gpu/drm/i915/intel_vbt_defs.h
> index e3d7745a9151..bbb173e116b3 100644
> --- a/drivers/gpu/drm/i915/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
> @@ -412,6 +412,8 @@ struct child_device_config {
>   u16 dp_gpio_pin_num;/* 195 */
>   u8 dp_iboost_level:4;   /* 196 */
>   u8 hdmi_iboost_level:4; /* 196 */
> + u8 dp_max_link_rate_reserved:6; /* 216 */
> + u8 dp_max_link_rate:2;  /* 216 CNL+ */

Isn't the bitorder wrong here?

>  } __packed;
>  
>  struct bdb_general_definitions {
> -- 
> 2.11.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] drm/i915: vbt defs typo fixes

[Jani Nikula]

No more sing-a-ling.

Reported-by: Adam Jackson 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_vbt_defs.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h 
b/drivers/gpu/drm/i915/intel_vbt_defs.h
index bbb173e116b3..fa4f67d3f261 100644
--- a/drivers/gpu/drm/i915/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
@@ -227,7 +227,7 @@ struct bdb_general_features {
 #define DEVICE_TYPE_COMPOSITE_OUTPUT   (1 << 9)
 #define DEVICE_TYPE_DUAL_CHANNEL   (1 << 8)
 #define DEVICE_TYPE_HIGH_SPEED_LINK(1 << 6)
-#define DEVICE_TYPE_LVDS_SINGALING (1 << 5)
+#define DEVICE_TYPE_LVDS_SIGNALING (1 << 5)
 #define DEVICE_TYPE_TMDS_DVI_SIGNALING (1 << 4)
 #define DEVICE_TYPE_VIDEO_SIGNALING(1 << 3)
 #define DEVICE_TYPE_DISPLAYPORT_OUTPUT (1 << 2)
@@ -243,7 +243,7 @@ struct bdb_general_features {
 DEVICE_TYPE_MIPI_OUTPUT |  \
 DEVICE_TYPE_COMPOSITE_OUTPUT | \
 DEVICE_TYPE_DUAL_CHANNEL | \
-DEVICE_TYPE_LVDS_SINGALING |   \
+DEVICE_TYPE_LVDS_SIGNALING |   \
 DEVICE_TYPE_TMDS_DVI_SIGNALING |   \
 DEVICE_TYPE_VIDEO_SIGNALING |  \
 DEVICE_TYPE_DISPLAYPORT_OUTPUT |   \
@@ -253,7 +253,7 @@ struct bdb_general_features {
(DEVICE_TYPE_INTERNAL_CONNECTOR |   \
 DEVICE_TYPE_MIPI_OUTPUT |  \
 DEVICE_TYPE_COMPOSITE_OUTPUT | \
-DEVICE_TYPE_LVDS_SINGALING |   \
+DEVICE_TYPE_LVDS_SIGNALING |   \
 DEVICE_TYPE_TMDS_DVI_SIGNALING |   \
 DEVICE_TYPE_VIDEO_SIGNALING |  \
 DEVICE_TYPE_DISPLAYPORT_OUTPUT |   \
-- 
2.11.0

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

[Intel-gfx] [PATCH] drm/i915/bios: add DP max link rate to VBT child device struct

[Jani Nikula]

Update VBT defs to reflect revision 216. While at it, default the
expected child device struct size to sizeof the size rather than a
hardcoded value.

Cc: Rodrigo Vivi 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_bios.c | 8 +---
 drivers/gpu/drm/i915/intel_vbt_defs.h | 2 ++
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 51108ffc28d1..b820d595ebc8 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1323,11 +1323,13 @@ parse_general_definitions(struct drm_i915_private 
*dev_priv,
expected_size = LEGACY_CHILD_DEVICE_CONFIG_SIZE;
} else if (bdb->version == 195) {
expected_size = 37;
-   } else if (bdb->version <= 197) {
+   } else if (bdb->version <= 215) {
expected_size = 38;
+   } else if (bdb->version <= 216) {
+   expected_size = 39;
} else {
-   expected_size = 38;
-   BUILD_BUG_ON(sizeof(*child) < 38);
+   expected_size = sizeof(*child);
+   BUILD_BUG_ON(sizeof(*child) < 39);
DRM_DEBUG_DRIVER("Expected child device config size for VBT 
version %u not known; assuming %u\n",
 bdb->version, expected_size);
}
diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h 
b/drivers/gpu/drm/i915/intel_vbt_defs.h
index e3d7745a9151..bbb173e116b3 100644
--- a/drivers/gpu/drm/i915/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
@@ -412,6 +412,8 @@ struct child_device_config {
u16 dp_gpio_pin_num;/* 195 */
u8 dp_iboost_level:4;   /* 196 */
u8 hdmi_iboost_level:4; /* 196 */
+   u8 dp_max_link_rate_reserved:6; /* 216 */
+   u8 dp_max_link_rate:2;  /* 216 CNL+ */
 } __packed;
 
 struct bdb_general_definitions {
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH 15/15] drm/i915: Add NV12 support to intel_framebuffer_init

[Maarten Lankhorst]

Op 18-01-18 om 15:21 schreef Maarten Lankhorst:
> Op 20-01-18 om 22:45 schreef Vidya Srinivas:
>> From: Chandra Konduru 
>>
>> This patch adds NV12 as supported format
>> to intel_framebuffer_init and performs various checks.
>>
>> v2:
>> -Fix an issue in checks added (Chandra Konduru)
>>
>> v3: rebased (me)
>>
>> v4: Review comments by Ville addressed
>> Added platform check for NV12 in intel_framebuffer_init
>> Removed offset checks for NV12 case
>>
>> v5: Addressed review comments by Clinton A Taylor
>> This NV12 support only correctly works on SKL.
>> Plane color space conversion is different on GLK and later platforms
>> causing the colors to display incorrectly.
>> Ville's plane color space property patch series
>> in review will fix this issue.
>> - Restricted the NV12 case in intel_framebuffer_init to
>> SKL and BXT only.
>>
>> v6: Rebased (me)
>>
>> v7: Addressed review comments by Ville
>> Restricting the NV12 to BXT for now.
>>
>> v8: Rebased (me)
>> Restricting the NV12 changes to BXT and KBL for now.
>>
>> v9: Rebased (me)
>>
>> Tested-by: Clinton Taylor 
>> Reviewed-by: Clinton Taylor 
>> Signed-off-by: Chandra Konduru 
>> Signed-off-by: Nabendu Maiti 
>> Signed-off-by: Vidya Srinivas 
>> ---
>>  drivers/gpu/drm/i915/intel_display.c | 8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 88bc750..db42448 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -14005,6 +14005,14 @@ static int intel_framebuffer_init(struct 
>> intel_framebuffer *intel_fb,
>>  goto err;
>>  }
>>  break;
>> +case DRM_FORMAT_NV12:
>> +if (!IS_BROXTON(dev_priv) && !IS_KABYLAKE(dev_priv)) {
>> +DRM_DEBUG_KMS("unsupported pixel format: %s\n",
>> +  drm_get_format_name(mode_cmd->pixel_format,
>> +_name));
>> +goto err;
>> +}
>> +break;
> I started implementing the IGT side of this but as far as I can tell, the 
> specification will allow you to set different handles for each plane. But 
> intel doesn't support this right now..
>
> Could this assumption be fixed first? There's nothing stopping the drm core 
> or applications from having separate buffer objects, and for blitting it 
> would make sense to have a R8 plane for Y', and a R8G8 plane for Cb'Cr'
>
> Probably needs i915 to compile with something like below, then handling all 
> corner cases..
Never mind, seems this is a hardware limitation that bo for plane2 must be 
higher mapped than plane1 so having separate bo's won't do much. And there was 
already a check for handles[i] == handles[0].
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v9 5/6] drm/i915: add query uAPI

[Lionel Landwerlin]

There are a number of information that are readable from hardware
registers and that we would like to make accessible to userspace. One
particular example is the topology of the execution units (how are
execution units grouped in subslices and slices and also which ones
have been fused off for die recovery).

At the moment the GET_PARAM ioctl covers some basic needs, but
generally is only able to return a single value for each defined
parameter. This is a bit problematic with topology descriptions which
are array/maps of available units.

This change introduces a new ioctl that can deal with requests to fill
structures of potentially variable lengths. The user is expected fill
a query with length fields set at 0 on the first call, the kernel then
sets the length fields to the their expected values. A second call to
the kernel with length fields at their expected values will trigger a
copy of the data to the pointed memory locations.

The scope of this uAPI is only to provide information to userspace,
not to allow configuration of the device.

v2: Simplify dispatcher code iteration (Tvrtko)
Tweak uapi drm_i915_query_item structure (Tvrtko)

v3: Rename pad fields into flags (Chris)
Return error on flags field != 0 (Chris)
Only copy length back to userspace in drm_i915_query_item (Chris)

v4: Use array of functions instead of switch (Chris)

v5: More comments in uapi (Tvrtko)
Return query item errors in length field (All)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/Makefile |  1 +
 drivers/gpu/drm/i915/i915_drv.c   |  1 +
 drivers/gpu/drm/i915/i915_drv.h   |  3 ++
 drivers/gpu/drm/i915/i915_query.c | 67 +++
 include/uapi/drm/i915_drm.h   | 37 +
 5 files changed, 109 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/i915_query.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 3bddd8a06806..b0415a3e2d59 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -69,6 +69,7 @@ i915-y += i915_cmd_parser.o \
  i915_gem_timeline.o \
  i915_gem_userptr.o \
  i915_gemfs.o \
+ i915_query.o \
  i915_trace_points.o \
  i915_vma.o \
  intel_breadcrumbs.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a4cf6858e39c..e7098cf07ef5 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2826,6 +2826,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, 
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_PERF_ADD_CONFIG, i915_perf_add_config_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_PERF_REMOVE_CONFIG, 
i915_perf_remove_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_QUERY, i915_query_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
 };
 
 static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 317953484fec..b7ca9588b993 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3622,6 +3622,9 @@ extern void i915_perf_fini(struct drm_i915_private 
*dev_priv);
 extern void i915_perf_register(struct drm_i915_private *dev_priv);
 extern void i915_perf_unregister(struct drm_i915_private *dev_priv);
 
+/* i915_query.c */
+int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file 
*file);
+
 /* i915_suspend.c */
 extern int i915_save_state(struct drm_i915_private *dev_priv);
 extern int i915_restore_state(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_query.c 
b/drivers/gpu/drm/i915/i915_query.c
new file mode 100644
index ..5aa886313cf9
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -0,0 +1,67 @@
+/*
+ * Copyright © 2017 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 

[Intel-gfx] [PATCH v9 4/6] drm/i915: add rcs topology to error state

[Lionel Landwerlin]

This might be useful information for developers looking at an error
state.

v2: Place topology towards the end of the error state (Chris)

v3: Reuse common printing code (Michal)

v4: Make this a one-liner (Chris)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 06577574296b..5920a1bb1828 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -568,6 +568,7 @@ static void err_print_capabilities(struct 
drm_i915_error_state_buf *m,
struct drm_printer p = i915_error_printer(m);
 
intel_device_info_dump_flags(info, );
+   intel_device_info_dump_topology(>sseu, );
 }
 
 static void err_print_params(struct drm_i915_error_state_buf *m,
-- 
2.15.1

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

[Intel-gfx] [PATCH v9 6/6] drm/i915: expose rcs topology through query uAPI

[Lionel Landwerlin]

With the introduction of asymmetric slices in CNL, we cannot rely on
the previous SUBSLICE_MASK getparam to tell userspace what subslices
are available. Here we introduce a more detailed way of querying the
Gen's GPU topology that doesn't aggregate numbers.

This is essential for monitoring parts of the GPU with the OA unit,
because counters need to be normalized to the number of
EUs/subslices/slices. The current aggregated numbers like EU_TOTAL do
not gives us sufficient information.

As a bonus we can draw representations of the GPU :

https://imgur.com/a/vuqpa

v2: Rename uapi struct s/_mask/_info/ (Tvrtko)
Report max_slice/subslice/eus_per_subslice rather than strides (Tvrtko)
Add uapi macros to read data from *_info structs (Tvrtko)

v3: Use !!(v & DRM_I915_BIT()) for uapi macros instead of custom shifts (Tvrtko)

v4: factorize query item writting (Tvrtko)
tweak uapi struct/define names (Tvrtko)

v5: Replace ALIGN() macro (Chris)

v6: Updated uapi comments (Tvrtko)
Moved flags != 0 checks into vfuncs (Tvrtko)

v7: Use access_ok() before copying anything, to avoid overflows (Chris)
Switch BUG_ON() to GEM_WARN_ON() (Tvrtko)

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_query.c | 110 ++
 include/uapi/drm/i915_drm.h   |  68 +++
 2 files changed, 178 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_query.c 
b/drivers/gpu/drm/i915/i915_query.c
index 5aa886313cf9..ff87ec8a321a 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -25,8 +25,118 @@
 #include "i915_drv.h"
 #include 
 
+static int copy_query_data(struct drm_i915_query_item *query_item,
+  const void *item_ptr, u32 item_length,
+  const void *data_ptr, u32 data_length)
+{
+   u32 total_length = item_length + data_length;
+
+   if (GEM_WARN_ON(add_overflows(item_length, data_length)))
+   return -EINVAL;
+
+   if (query_item->length == 0)
+   return total_length;
+
+   if (query_item->length < total_length)
+   return -EINVAL;
+
+   if (!access_ok(VERIFY_WRITE, u64_to_user_ptr(query_item->data_ptr),
+  total_length))
+   return -EFAULT;
+
+   if (__copy_to_user(u64_to_user_ptr(query_item->data_ptr),
+  item_ptr, item_length))
+   return -EFAULT;
+
+   if (__copy_to_user(u64_to_user_ptr(query_item->data_ptr + item_length),
+  data_ptr, data_length))
+   return -EFAULT;
+
+   return total_length;
+}
+
+static int query_slice_info(struct drm_i915_private *dev_priv,
+   struct drm_i915_query_item *query_item)
+{
+   const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+   struct drm_i915_query_slice_info slice_info;
+
+   if (query_item->flags != 0)
+   return -EINVAL;
+
+   if (sseu->max_slices == 0)
+   return -ENODEV;
+
+   /*
+* If we ever change the internal slice mask data type, we'll need to
+* update this function.
+*/
+   BUILD_BUG_ON(sizeof(u8) != sizeof(sseu->slice_mask));
+
+   memset(_info, 0, sizeof(slice_info));
+   slice_info.max_slices = sseu->max_slices;
+
+   return copy_query_data(query_item, _info, sizeof(slice_info),
+  >slice_mask, sizeof(sseu->slice_mask));
+}
+
+static int query_subslice_info(struct drm_i915_private *dev_priv,
+  struct drm_i915_query_item *query_item)
+{
+   const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+   struct drm_i915_query_subslice_info subslice_info;
+   u32 data_length;
+
+   if (query_item->flags != 0)
+   return -EINVAL;
+
+   if (sseu->max_slices == 0)
+   return -ENODEV;
+
+   memset(_info, 0, sizeof(subslice_info));
+   subslice_info.max_slices = sseu->max_slices;
+   subslice_info.max_subslices = sseu->max_subslices;
+
+   data_length = subslice_info.max_slices *
+   DIV_ROUND_UP(subslice_info.max_subslices,
+sizeof(sseu->subslice_mask[0]) * BITS_PER_BYTE);
+
+   return copy_query_data(query_item,
+  _info, sizeof(subslice_info),
+  sseu->subslice_mask, data_length);
+}
+
+static int query_eu_info(struct drm_i915_private *dev_priv,
+struct drm_i915_query_item *query_item)
+{
+   const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+   struct drm_i915_query_eu_info eu_info;
+   u32 data_length;
+
+   if (query_item->flags != 0)
+   return -EINVAL;
+
+   if (sseu->max_slices == 0)
+   return -ENODEV;
+
+   memset(_info, 0, sizeof(eu_info));
+   eu_info.max_slices = sseu->max_slices;
+   

[Intel-gfx] [PATCH v9 3/6] drm/i915/debugfs: add rcs topology entry

[Lionel Landwerlin]

While the end goal is to make this information available to userspace
through a new ioctl, there is no reason we can't display it in a human
readable fashion through debugfs.

slice0: 3 subslice(s) (0x7):
subslice0: 8 EUs (0xff)
subslice1: 8 EUs (0xff)
subslice2: 8 EUs (0xff)
subslice3: 0 EUs (0x0)
slice1: 3 subslice(s) (0x7):
subslice0: 8 EUs (0xff)
subslice1: 8 EUs (0xff)
subslice2: 8 EUs (0xff)
subslice3: 0 EUs (0x0)
slice2: 3 subslice(s) (0x7):
subslice0: 8 EUs (0xff)
subslice1: 8 EUs (0xff)
subslice2: 8 EUs (0xff)
subslice3: 0 EUs (0x0)

v2: Reformat debugfs printing (Tvrtko)
Use the new EU mask helper (Tvrtko)

v3: Move printing code to intel_device_info.c to be shared with error
state (Michal)

Suggested-by: Chris Wilson 
Signed-off-by: Lionel Landwerlin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 11 +++
 drivers/gpu/drm/i915/intel_device_info.c | 25 +
 drivers/gpu/drm/i915/intel_device_info.h |  2 ++
 3 files changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e41a19b7d7bb..c3a44a54a0ba 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3166,6 +3166,16 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
return 0;
 }
 
+static int i915_rcs_topology(struct seq_file *m, void *unused)
+{
+   struct drm_i915_private *dev_priv = node_to_i915(m->private);
+   struct drm_printer p = drm_seq_file_printer(m);
+
+   intel_device_info_dump_topology(_INFO(dev_priv)->sseu, );
+
+   return 0;
+}
+
 static int i915_shrinker_info(struct seq_file *m, void *unused)
 {
struct drm_i915_private *i915 = node_to_i915(m->private);
@@ -4696,6 +4706,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_dmc_info", i915_dmc_info, 0},
{"i915_display_info", i915_display_info, 0},
{"i915_engine_info", i915_engine_info, 0},
+   {"i915_rcs_topology", i915_rcs_topology, 0},
{"i915_shrinker_info", i915_shrinker_info, 0},
{"i915_shared_dplls_info", i915_shared_dplls_info, 0},
{"i915_dp_mst_info", i915_dp_mst_info, 0},
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index ed14994527fc..bc08a5ef0ba2 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -123,6 +123,31 @@ void intel_device_info_dump(const struct intel_device_info 
*info,
intel_device_info_dump_flags(info, p);
 }
 
+void intel_device_info_dump_topology(const struct sseu_dev_info *sseu,
+struct drm_printer *p)
+{
+   int s, ss;
+
+   if (sseu->max_slices == 0) {
+   drm_printf(p, "Unavailable\n");
+   return;
+   }
+
+   for (s = 0; s < sseu->max_slices; s++) {
+   drm_printf(p, "slice%d: %u subslice(s) (0x%hhx):\n",
+  s, hweight8(sseu->subslice_mask[s]),
+  sseu->subslice_mask[s]);
+
+   for (ss = 0; ss < sseu->max_subslices; ss++) {
+   u8 enabled_eus = sseu_get_eus(sseu, s, ss);
+
+   drm_printf(p, "\tsubslice%d: %u EUs (0x%hhx)\n",
+  ss, hweight8(enabled_eus), enabled_eus);
+   }
+   }
+}
+
+
 static u16 compute_eu_total(const struct sseu_dev_info *sseu)
 {
u16 i, total = 0;
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 36e0df87862d..701888162944 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -220,5 +220,7 @@ void intel_device_info_dump_flags(const struct 
intel_device_info *info,
  struct drm_printer *p);
 void intel_device_info_dump_runtime(const struct intel_device_info *info,
struct drm_printer *p);
+void intel_device_info_dump_topology(const struct sseu_dev_info *sseu,
+struct drm_printer *p);
 
 #endif
-- 
2.15.1

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

[Intel-gfx] [PATCH v9 2/6] drm/i915/debugfs: reuse max slice/subslices already stored in sseu

[Lionel Landwerlin]

Now that we have that information in topology fields, let's just reused it.

v2: Style tweaks (Tvrtko)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 27 +++
 1 file changed, 11 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 684551114965..e41a19b7d7bb 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4304,11 +4304,11 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
 struct sseu_dev_info *sseu)
 {
const struct intel_device_info *info = INTEL_INFO(dev_priv);
-   int s_max = 6, ss_max = 4;
int s, ss;
-   u32 s_reg[s_max], eu_reg[2 * s_max], eu_mask[2];
+   u32 s_reg[info->sseu.max_slices];
+   u32 eu_reg[2 * info->sseu.max_subslices], eu_mask[2];
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
/*
 * FIXME: Valid SS Mask respects the spec and read
 * only valid bits for those registers, excluding reserverd
@@ -4330,7 +4330,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
 GEN9_PGCTL_SSB_EU210_ACK |
 GEN9_PGCTL_SSB_EU311_ACK;
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
/* skip disabled slice */
continue;
@@ -4338,7 +4338,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->slice_mask |= BIT(s);
sseu->subslice_mask[s] = info->sseu.subslice_mask[s];
 
-   for (ss = 0; ss < ss_max; ss++) {
+   for (ss = 0; ss < info->sseu.max_subslices; ss++) {
unsigned int eu_cnt;
 
if (!(s_reg[s] & (GEN9_PGCTL_SS_ACK(ss
@@ -4358,17 +4358,12 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
 static void gen9_sseu_device_status(struct drm_i915_private *dev_priv,
struct sseu_dev_info *sseu)
 {
-   int s_max = 3, ss_max = 4;
+   const struct intel_device_info *info = INTEL_INFO(dev_priv);
int s, ss;
-   u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2];
-
-   /* BXT has a single slice and at most 3 subslices. */
-   if (IS_GEN9_LP(dev_priv)) {
-   s_max = 1;
-   ss_max = 3;
-   }
+   u32 s_reg[info->sseu.max_slices];
+   u32 eu_reg[2 * info->sseu.max_subslices], eu_mask[2];
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
s_reg[s] = I915_READ(GEN9_SLICE_PGCTL_ACK(s));
eu_reg[2*s] = I915_READ(GEN9_SS01_EU_PGCTL_ACK(s));
eu_reg[2*s + 1] = I915_READ(GEN9_SS23_EU_PGCTL_ACK(s));
@@ -4383,7 +4378,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
 GEN9_PGCTL_SSB_EU210_ACK |
 GEN9_PGCTL_SSB_EU311_ACK;
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
/* skip disabled slice */
continue;
@@ -4394,7 +4389,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->subslice_mask[s] =
INTEL_INFO(dev_priv)->sseu.subslice_mask[s];
 
-   for (ss = 0; ss < ss_max; ss++) {
+   for (ss = 0; ss < info->sseu.max_subslices; ss++) {
unsigned int eu_cnt;
 
if (IS_GEN9_LP(dev_priv)) {
-- 
2.15.1

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

[Intel-gfx] [PATCH v9 1/6] drm/i915: store all subslice masks

[Lionel Landwerlin]

Up to now, subslice mask was assumed to be uniform across slices. But
starting with Cannonlake, slices can be asymmetric (for example slice0
has different number of subslices as slice1+). This change stores all
subslices masks for all slices rather than having a single mask that
applies to all slices.

v2: Rework how we store total numbers in sseu_dev_info (Tvrtko)
Fix CHV eu masks, was reading disabled as enabled (Tvrtko)
Readability changes (Tvrtko)
Add EU index helper (Tvrtko)

v3: Turn ALIGN(v, 8) / 8 into DIV_ROUND_UP(v, BITS_PER_BYTE) (Tvrtko)
Reuse sseu_eu_idx() for setting eu_mask on CHV (Tvrtko)
Reformat debug prints for subslices (Tvrtko)

v4: Change eu_mask helper into sseu_set_eus() (Tvrtko)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  25 ++--
 drivers/gpu/drm/i915/i915_drv.c  |   2 +-
 drivers/gpu/drm/i915/intel_device_info.c | 201 +++
 drivers/gpu/drm/i915/intel_device_info.h |  47 +++-
 drivers/gpu/drm/i915/intel_lrc.c |   2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h  |   2 +-
 6 files changed, 216 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index cc659b4b2a45..684551114965 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4289,7 +4289,7 @@ static void cherryview_sseu_device_status(struct 
drm_i915_private *dev_priv,
continue;
 
sseu->slice_mask = BIT(0);
-   sseu->subslice_mask |= BIT(ss);
+   sseu->subslice_mask[0] |= BIT(ss);
eu_cnt = ((sig1[ss] & CHV_EU08_PG_ENABLE) ? 0 : 2) +
 ((sig1[ss] & CHV_EU19_PG_ENABLE) ? 0 : 2) +
 ((sig1[ss] & CHV_EU210_PG_ENABLE) ? 0 : 2) +
@@ -4336,7 +4336,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
continue;
 
sseu->slice_mask |= BIT(s);
-   sseu->subslice_mask = info->sseu.subslice_mask;
+   sseu->subslice_mask[s] = info->sseu.subslice_mask[s];
 
for (ss = 0; ss < ss_max; ss++) {
unsigned int eu_cnt;
@@ -4391,8 +4391,8 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->slice_mask |= BIT(s);
 
if (IS_GEN9_BC(dev_priv))
-   sseu->subslice_mask =
-   INTEL_INFO(dev_priv)->sseu.subslice_mask;
+   sseu->subslice_mask[s] =
+   INTEL_INFO(dev_priv)->sseu.subslice_mask[s];
 
for (ss = 0; ss < ss_max; ss++) {
unsigned int eu_cnt;
@@ -4402,7 +4402,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
/* skip disabled subslice */
continue;
 
-   sseu->subslice_mask |= BIT(ss);
+   sseu->subslice_mask[s] |= BIT(ss);
}
 
eu_cnt = 2 * hweight32(eu_reg[2*s + ss/2] &
@@ -4424,9 +4424,12 @@ static void broadwell_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->slice_mask = slice_info & GEN8_LSLICESTAT_MASK;
 
if (sseu->slice_mask) {
-   sseu->subslice_mask = INTEL_INFO(dev_priv)->sseu.subslice_mask;
sseu->eu_per_subslice =
INTEL_INFO(dev_priv)->sseu.eu_per_subslice;
+   for (s = 0; s < fls(sseu->slice_mask); s++) {
+   sseu->subslice_mask[s] =
+   INTEL_INFO(dev_priv)->sseu.subslice_mask[s];
+   }
sseu->eu_total = sseu->eu_per_subslice *
 sseu_subslice_total(sseu);
 
@@ -4445,6 +4448,7 @@ static void i915_print_sseu_info(struct seq_file *m, bool 
is_available_info,
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
const char *type = is_available_info ? "Available" : "Enabled";
+   int s;
 
seq_printf(m, "  %s Slice Mask: %04x\n", type,
   sseu->slice_mask);
@@ -4452,10 +4456,11 @@ static void i915_print_sseu_info(struct seq_file *m, 
bool is_available_info,
   hweight8(sseu->slice_mask));
seq_printf(m, "  %s Subslice Total: %u\n", type,
   sseu_subslice_total(sseu));
-   seq_printf(m, "  %s Subslice Mask: %04x\n", type,
-  sseu->subslice_mask);
-   seq_printf(m, "  %s Subslice Per Slice: %u\n", type,
-  hweight8(sseu->subslice_mask));
+   for (s = 0; s < fls(sseu->slice_mask); s++) {
+   seq_printf(m, "  %s Slice%i %u subslices, mask=%04x\n", type,
+   

[Intel-gfx] [PATCH v9 0/6] drm/i915: expose RCS topology to userspace

[Lionel Landwerlin]

Hi all,

This looks like the last iteration :)

Cheers,

Lionel Landwerlin (6):
  drm/i915: store all subslice masks
  drm/i915/debugfs: reuse max slice/subslices already stored in sseu
  drm/i915/debugfs: add rcs topology entry
  drm/i915: add rcs topology to error state
  drm/i915: add query uAPI
  drm/i915: expose rcs topology through query uAPI

 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/i915_debugfs.c  |  63 +
 drivers/gpu/drm/i915/i915_drv.c  |   3 +-
 drivers/gpu/drm/i915/i915_drv.h  |   3 +
 drivers/gpu/drm/i915/i915_gpu_error.c|   1 +
 drivers/gpu/drm/i915/i915_query.c| 177 
 drivers/gpu/drm/i915/intel_device_info.c | 226 ---
 drivers/gpu/drm/i915/intel_device_info.h |  49 ++-
 drivers/gpu/drm/i915/intel_lrc.c |   2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h  |   2 +-
 include/uapi/drm/i915_drm.h  | 105 ++
 11 files changed, 553 insertions(+), 79 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_query.c

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

[Intel-gfx] [RFC PATCH] igt/core: Initial simple interleaved kmsg filtering

[Daniel Vetter]

Needs to be beefed up so that dmesg warning (and worse) are re-emmitted
as IGT_LOG_WARN. But only if they match one of our filters (which we
should probably allow to be extended, e.g. depending upon which driver
has been openened). This also requires that we at least parse the
basic of kmsg lines (adjusting the timestamp to match our own would be
real cool).

v2:
- Seek to the end of the kmsg buffer before starting the capturing.
- Increase linebuffer to avoid dmesg drowning out all the tests
  messages.

v3: Unlazy slightly and implement semi-correct kmsg parsing.

Signed-off-by: Daniel Vetter 
---
 lib/igt_core.c | 56 +++-
 1 file changed, 55 insertions(+), 1 deletion(-)

diff --git a/lib/igt_core.c b/lib/igt_core.c
index aaafc1df6b46..bcdc8abb41a7 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -293,7 +293,7 @@ static const char *command_str;
 
 static char* igt_debug_log_domain_filter;
 static struct {
-   char *entries[256];
+   char *entries[2000];
uint8_t start, end;
 } log_buffer;
 static pthread_mutex_t log_buffer_mutex = PTHREAD_MUTEX_INITIALIZER;
@@ -581,6 +581,58 @@ static void oom_adjust_for_doom(void)
 
 }
 
+static void *kmsg_capture(void *arg)
+{
+   int kmsg_capture_fd = (uintptr_t) arg;
+   FILE *kmsg_file = fdopen(kmsg_capture_fd, "r");
+   char *line = NULL;
+   size_t line_len = 0;
+   ssize_t read;
+
+   while ((read = getline(, _len, kmsg_file))) {
+   unsigned flags;
+   unsigned long long seq, ts_usec;
+   char continuation;
+   enum igt_log_level level;
+
+   sscanf(line, "%u,%llu,%llu,%c;", ,
+  , _usec, );
+
+   if ((flags & 0x7) <= 4)
+   level = IGT_LOG_WARN;
+   else
+   level = IGT_LOG_DEBUG;
+
+   igt_log("dmesg", level, "[%llu.%06llu], %s",
+   ts_usec / 100,
+   ts_usec % 100,
+   index(line, ';') + 1);
+   }
+
+   igt_warn("ran out of dmesg, this shouldn't happen\n");
+
+   return NULL;
+}
+
+static void start_kmsg_recording(void)
+{
+   static pthread_t kmsg_capture_thread;
+   int kmsg_capture_fd;
+
+   kmsg_capture_fd = open("/dev/kmsg",
+  O_RDONLY | O_CLOEXEC);
+
+   if (kmsg_capture_fd < 0) {
+   igt_info("no dmesg capturing\n");
+   return;
+   }
+
+   lseek(kmsg_capture_fd, 0, SEEK_END);
+
+   pthread_create(_capture_thread, NULL,
+  kmsg_capture, (void *)(uintptr_t) kmsg_capture_fd);
+}
+
 #ifdef HAVE_GLIB
 static void common_init_config(void)
 {
@@ -814,6 +866,8 @@ out:
kmsg(KERN_INFO "[IGT] %s: executing\n", command_str);
print_version();
 
+   start_kmsg_recording();
+
sync();
oom_adjust_for_doom();
ftrace_dump_on_oops(true);
-- 
2.14.3

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

Re: [Intel-gfx] [PATCH v6 85/99] btrfs: Remove unused spinlock

[David Sterba]

On Wed, Jan 17, 2018 at 12:21:49PM -0800, Matthew Wilcox wrote:
> From: Matthew Wilcox 
> 
> The reada_lock in struct btrfs_device was only initialised, and not
> actually used.  That's good because there's another lock also called
> reada_lock in the btrfs_fs_info that was quite heavily used.  Remove
> this one.
> 
> Signed-off-by: Matthew Wilcox 

I'll pick this one now, thanks.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Add tracking for CDCLK bypass frequency

[Imre Deak]

On Wed, Jan 17, 2018 at 07:56:22PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 17, 2018 at 07:25:08PM +0200, Imre Deak wrote:
> > The CDCLK bypass frequency can vary on upcoming platforms, so prepare
> > for that now by tracking its value in the CDCLK state.
> > 
> > Currently on BDW+ the bypass frequency is always the reference clock and
> > I didn't bother with earlier platforms since it's not all that clear
> > what's the bypass clock on those.
> > 
> > I also didn't bother adding support for changing this frequency, since
> > atm I don't see any need for it.
> > 
> > Suggested-by: Ville Syrjälä 
> > Cc: Ville Syrjälä 
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h|  2 +-
> >  drivers/gpu/drm/i915/intel_cdclk.c | 35 ++-
> >  2 files changed, 19 insertions(+), 18 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index c42015b05b47..49ccfc397feb 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1791,7 +1791,7 @@ struct i915_oa_ops {
> >  };
> >  
> >  struct intel_cdclk_state {
> > -   unsigned int cdclk, vco, ref;
> > +   unsigned int cdclk, vco, ref, bypass;
> > u8 voltage_level;
> >  };
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> > b/drivers/gpu/drm/i915/intel_cdclk.c
> > index ca36321eafac..f46a61d423a1 100644
> > --- a/drivers/gpu/drm/i915/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> > @@ -858,7 +858,7 @@ static void skl_get_cdclk(struct drm_i915_private 
> > *dev_priv,
> >  
> > skl_dpll0_update(dev_priv, cdclk_state);
> >  
> > -   cdclk_state->cdclk = cdclk_state->ref;
> > +   cdclk_state->cdclk = cdclk_state->bypass = cdclk_state->ref;
> 
> My first instinct would have been to populate bypass in the PLL
> readout function. I guess I just think of the bypass clock more
> as a feature of the PLL. But I suppose it really doesn't matter
> where we do this.
> 
> Reviewed-by: Ville Syrjälä 

My thinking was that it's CDCLK choosing either the PLL output or the
bypass clock as a source (while refclk is connected directly both to
the PLL and the CDCLK as a source); but yes doesn't matter in practice
where it's inited, I leave it as-is for now.

Thanks for the review, pushed to drm-tip.

--Imre

> 
> >  
> > if (cdclk_state->vco == 0)
> > goto out;
> > @@ -1006,7 +1006,7 @@ static void skl_set_cdclk(struct drm_i915_private 
> > *dev_priv,
> > /* Choose frequency for this cdclk */
> > switch (cdclk) {
> > default:
> > -   WARN_ON(cdclk != dev_priv->cdclk.hw.ref);
> > +   WARN_ON(cdclk != dev_priv->cdclk.hw.bypass);
> > WARN_ON(vco != 0);
> > /* fall through */
> > case 308571:
> > @@ -1085,7 +1085,7 @@ static void skl_sanitize_cdclk(struct 
> > drm_i915_private *dev_priv)
> >  
> > /* Is PLL enabled and locked ? */
> > if (dev_priv->cdclk.hw.vco == 0 ||
> > -   dev_priv->cdclk.hw.cdclk == dev_priv->cdclk.hw.ref)
> > +   dev_priv->cdclk.hw.cdclk == dev_priv->cdclk.hw.bypass)
> > goto sanitize;
> >  
> > /* DPLL okay; verify the cdclock
> > @@ -1159,7 +1159,7 @@ void skl_uninit_cdclk(struct drm_i915_private 
> > *dev_priv)
> >  {
> > struct intel_cdclk_state cdclk_state = dev_priv->cdclk.hw;
> >  
> > -   cdclk_state.cdclk = cdclk_state.ref;
> > +   cdclk_state.cdclk = cdclk_state.bypass;
> > cdclk_state.vco = 0;
> > cdclk_state.voltage_level = skl_calc_voltage_level(cdclk_state.cdclk);
> >  
> > @@ -1199,7 +1199,7 @@ static int bxt_de_pll_vco(struct drm_i915_private 
> > *dev_priv, int cdclk)
> >  {
> > int ratio;
> >  
> > -   if (cdclk == dev_priv->cdclk.hw.ref)
> > +   if (cdclk == dev_priv->cdclk.hw.bypass)
> > return 0;
> >  
> > switch (cdclk) {
> > @@ -1224,7 +1224,7 @@ static int glk_de_pll_vco(struct drm_i915_private 
> > *dev_priv, int cdclk)
> >  {
> > int ratio;
> >  
> > -   if (cdclk == dev_priv->cdclk.hw.ref)
> > +   if (cdclk == dev_priv->cdclk.hw.bypass)
> > return 0;
> >  
> > switch (cdclk) {
> > @@ -1268,7 +1268,7 @@ static void bxt_get_cdclk(struct drm_i915_private 
> > *dev_priv,
> >  
> > bxt_de_pll_update(dev_priv, cdclk_state);
> >  
> > -   cdclk_state->cdclk = cdclk_state->ref;
> > +   cdclk_state->cdclk = cdclk_state->bypass = cdclk_state->ref;
> >  
> > if (cdclk_state->vco == 0)
> > goto out;
> > @@ -1352,7 +1352,7 @@ static void bxt_set_cdclk(struct drm_i915_private 
> > *dev_priv,
> > /* cdclk = vco / 2 / div{1,1.5,2,4} */
> > switch (DIV_ROUND_CLOSEST(vco, cdclk)) {
> > default:
> > -   WARN_ON(cdclk != dev_priv->cdclk.hw.ref);
> > +   WARN_ON(cdclk != dev_priv->cdclk.hw.bypass);
> > WARN_ON(vco != 0);
> > /* fall through */
> >   

Re: [Intel-gfx] [PATCH 15/15] drm/i915: Add NV12 support to intel_framebuffer_init

[Maarten Lankhorst]

Op 20-01-18 om 22:45 schreef Vidya Srinivas:
> From: Chandra Konduru 
>
> This patch adds NV12 as supported format
> to intel_framebuffer_init and performs various checks.
>
> v2:
> -Fix an issue in checks added (Chandra Konduru)
>
> v3: rebased (me)
>
> v4: Review comments by Ville addressed
> Added platform check for NV12 in intel_framebuffer_init
> Removed offset checks for NV12 case
>
> v5: Addressed review comments by Clinton A Taylor
> This NV12 support only correctly works on SKL.
> Plane color space conversion is different on GLK and later platforms
> causing the colors to display incorrectly.
> Ville's plane color space property patch series
> in review will fix this issue.
> - Restricted the NV12 case in intel_framebuffer_init to
> SKL and BXT only.
>
> v6: Rebased (me)
>
> v7: Addressed review comments by Ville
> Restricting the NV12 to BXT for now.
>
> v8: Rebased (me)
> Restricting the NV12 changes to BXT and KBL for now.
>
> v9: Rebased (me)
>
> Tested-by: Clinton Taylor 
> Reviewed-by: Clinton Taylor 
> Signed-off-by: Chandra Konduru 
> Signed-off-by: Nabendu Maiti 
> Signed-off-by: Vidya Srinivas 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 88bc750..db42448 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14005,6 +14005,14 @@ static int intel_framebuffer_init(struct 
> intel_framebuffer *intel_fb,
>   goto err;
>   }
>   break;
> + case DRM_FORMAT_NV12:
> + if (!IS_BROXTON(dev_priv) && !IS_KABYLAKE(dev_priv)) {
> + DRM_DEBUG_KMS("unsupported pixel format: %s\n",
> +   drm_get_format_name(mode_cmd->pixel_format,
> + _name));
> + goto err;
> + }
> + break;
I started implementing the IGT side of this but as far as I can tell, the 
specification will allow you to set different handles for each plane. But intel 
doesn't support this right now..

Could this assumption be fixed first? There's nothing stopping the drm core or 
applications from having separate buffer objects, and for blitting it would 
make sense to have a R8 plane for Y', and a R8G8 plane for Cb'Cr'

Probably needs i915 to compile with something like below, then handling all 
corner cases..
---
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 39c3bfa74d67..4eeb94fbfdd6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -186,7 +186,7 @@ enum intel_output_type {
 
 struct intel_framebuffer {
struct drm_framebuffer base;
-   struct drm_i915_gem_object *obj;
+   struct drm_i915_gem_object *objs[2];
struct intel_rotation_info rot_info;
 
/* for each plane in the normal GTT view */
@@ -996,7 +996,7 @@ struct cxsr_latency {
 #define to_intel_framebuffer(x) container_of(x, struct intel_framebuffer, base)
 #define to_intel_plane(x) container_of(x, struct intel_plane, base)
 #define to_intel_plane_state(x) container_of(x, struct intel_plane_state, base)
-#define intel_fb_obj(x) (x ? to_intel_framebuffer(x)->obj : NULL)
+#define intel_fb_obj(x, n) (x ? to_intel_framebuffer(x)->objs[n] : NULL)
 
 struct intel_hdmi {
i915_reg_t hdmi_reg;

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

Re: [Intel-gfx] [PATCH v3 7/7] drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON

[Ville Syrjälä]

On Thu, Jan 18, 2018 at 11:57:09AM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 1/17/2018 11:57 PM, Ville Syrjälä wrote:
> > On Fri, Jan 05, 2018 at 03:15:35PM +0530, Shashank Sharma wrote:
> >> LSPCON chips can generate YCBCR outputs, if asked nicely :).
> >>
> >> In order to generate YCBCR 4:2:0 outputs, a source must:
> >> - send YCBCR 4:4:4 signals to LSPCON
> >> - program color space as 4:2:0 in AVI infoframes
> >>
> >> Whereas for YCBCR 4:4:4 outputs, the source must:
> >> - send YCBCR 4:4:4 signals to LSPCON
> >> - program color space as 4:4:4 in AVI infoframes
> >>
> >> So for both 4:2:0 as well as 4:4:4 outputs, we are driving the
> >> pipe for YCBCR 4:4:4 output, but AVI infoframe's color space
> >> information indicates LSPCON FW to start scaling down from YCBCR
> >> 4:4:4 and generate YCBCR 4:2:0 output. As the scaling is done by
> >> LSPCON device, we need not to reserve a scaler for 4:2:0 outputs.
> >>
> >> V2: rebase
> >> V3: Addressed review comments from Ville
> >>  - add enum crtc_output_format instead of bool ycbcr420
> >>  - use crtc_output_format=4:4:4 for modeset of LSPCON 4:2:0 output
> >>cases in this way we will have YCBCR 4:4:4 framework ready (except
> >>the ABI part)
> >>
> >> Cc: Ville Syrjala 
> >> Cc: Maarten Lankhorst 
> >> Signed-off-by: Shashank Sharma 
> >> ---
> >>   drivers/gpu/drm/i915/i915_reg.h |  2 ++
> >>   drivers/gpu/drm/i915/intel_ddi.c|  7 +++
> >>   drivers/gpu/drm/i915/intel_dp.c | 10 ++
> >>   drivers/gpu/drm/i915/intel_drv.h|  2 ++
> >>   drivers/gpu/drm/i915/intel_lspcon.c | 28 
> >>   5 files changed, 49 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> >> b/drivers/gpu/drm/i915/i915_reg.h
> >> index 966e4df..45ee264 100644
> >> --- a/drivers/gpu/drm/i915/i915_reg.h
> >> +++ b/drivers/gpu/drm/i915/i915_reg.h
> >> @@ -8547,6 +8547,8 @@ enum skl_power_gate {
> >>   #define TRANS_MSA_MISC(tran) _MMIO_TRANS2(tran, _TRANSA_MSA_MISC)
> >>   
> >>   #define  TRANS_MSA_SYNC_CLK  (1<<0)
> >> +#define  TRANS_MSA_SAMPLING_444(2<<1)
> >> +#define  TRANS_MSA_CLRSP_YCBCR(2<<3)
> >>   #define  TRANS_MSA_6_BPC (0<<5)
> >>   #define  TRANS_MSA_8_BPC (1<<5)
> >>   #define  TRANS_MSA_10_BPC(2<<5)
> >> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> >> b/drivers/gpu/drm/i915/intel_ddi.c
> >> index 7b89f2a..7616f6f 100644
> >> --- a/drivers/gpu/drm/i915/intel_ddi.c
> >> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> >> @@ -1499,6 +1499,13 @@ void intel_ddi_set_pipe_settings(const struct 
> >> intel_crtc_state *crtc_state)
> >>break;
> >>}
> >>   
> >> +  /*
> >> +   * As per DP 1.2 spec section 2.3.4.3 while sending
> >> +   * YCBCR 444 signals we should program MSA MISC1/0 fields with
> >> +   * colorspace information.
> >> +   */
> >> +  if (crtc_state->output_format == CRTC_OUTPUT_YCBCR444)
> >> +  temp |= TRANS_MSA_SAMPLING_444 | TRANS_MSA_CLRSP_YCBCR;
> > This fails to state that we're indicating BT.601 encoding. I think we
> > should spell that out explicitly.
> Agree, I will add this in comments.
> >>I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp);
> >>   }
> >>   
> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> >> b/drivers/gpu/drm/i915/intel_dp.c
> >> index 35c5299..3bf82ea 100644
> >> --- a/drivers/gpu/drm/i915/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >> @@ -1613,6 +1613,7 @@ intel_dp_compute_config(struct intel_encoder 
> >> *encoder,
> >>struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> >>struct drm_display_mode *adjusted_mode = 
> >> _config->base.adjusted_mode;
> >>struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> >> +  struct intel_lspcon *lspcon = enc_to_intel_lspcon(>base);
> >>enum port port = encoder->port;
> >>struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc);
> >>struct intel_connector *intel_connector = intel_dp->attached_connector;
> >> @@ -1642,6 +1643,15 @@ intel_dp_compute_config(struct intel_encoder 
> >> *encoder,
> >>if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv) && port != PORT_A)
> >>pipe_config->has_pch_encoder = true;
> >>   
> >> +  if (lspcon->active) {
> >> +  struct drm_connector *connector = _connector->base;
> >> +
> >> +  if (lspcon_ycbcr420_config(connector, pipe_config)) {
> >> +  pipe_config->output_format = CRTC_OUTPUT_YCBCR444;
> > I think I'd like to see all compute_config hooks explicitly set the
> > outout_format (to RGB usually obviously).
> That's the one I was talking about in previous patch. If we keep 
> output_format_RGB = 0, we need
> not to do this, as reset of the pipe_config will automatically make it RGB.

IMO either we have INVALID=0 so that we use it to catch readout
fails, or we have 

[Intel-gfx] ✓ Fi.CI.BAT: success for khungtaskd: Kick stuck processes

[Patchwork]

== Series Details ==

Series: khungtaskd: Kick stuck processes
URL   : https://patchwork.freedesktop.org/series/36677/
State : success

== Summary ==

Series 36677v1 khungtaskd: Kick stuck processes
https://patchwork.freedesktop.org/api/1.0/series/36677/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-fail -> DMESG-WARN (fi-elk-e7500) fdo#103989
incomplete -> PASS   (fi-snb-2520m) fdo#103713 +1
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:418s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:424s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:486s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:486s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:473s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:452s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:276s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:512s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:392s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:410s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:410s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:461s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:411s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:457s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:503s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:453s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:503s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:582s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:431s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:508s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:529s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:484s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:484s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:399s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:563s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:466s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:418s

68669ade8e500355455124fe96b34614ddc1777b drm-tip: 2018y-01m-18d-12h-01m-38s UTC 
integration manifest
8e187851b2da khungtaskd: Kick stuck processes

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7709/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC PATCH 5/5] lib/core: report subtests that hit an igt_warning as WARNING

[Daniel Vetter]

This is another piece of prep work to push the detection of dmesg
warnings into igt itself, so that we can correctly report dmesg
issue on a per-subtest basis even when running the entire binary.

Signed-off-by: Daniel Vetter 
---
 lib/igt_core.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/lib/igt_core.c b/lib/igt_core.c
index 65b394581e8f..d61d32295bb2 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -1021,6 +1021,7 @@ void __igt_subtest_group_restore(int save)
 static bool skipped_one = false;
 static bool succeeded_one = false;
 static bool failed_one = false;
+static bool warned = false;
 
 static void exit_subtest(const char *) __attribute__((noreturn));
 static void exit_subtest(const char *result)
@@ -1037,6 +1038,7 @@ static void exit_subtest(const char *result)
igt_terminate_spin_batches();
 
in_subtest = NULL;
+   warned = false;
siglongjmp(igt_subtest_jmpbuf, 1);
 }
 
@@ -1126,7 +1128,7 @@ void igt_success(void)
 {
succeeded_one = true;
if (in_subtest)
-   exit_subtest("SUCCESS");
+   exit_subtest(warned ? "WARNING" : "SUCCESS");
 }
 
 /**
@@ -2120,6 +2122,9 @@ void igt_vlog(const char *domain, enum igt_log_level 
level, const char *format,
if (list_subtests && level <= IGT_LOG_WARN)
return;
 
+   if (level >= IGT_LOG_WARN)
+   warned = true;
+
if (vasprintf(, format, args) == -1)
return;
 
-- 
2.14.3

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

[Intel-gfx] [RFC PATCH 4/5] igt/core: Initial simple interleaved kmsg filtering

[Daniel Vetter]

Needs to be beefed up so that dmesg warning (and worse) are re-emmitted
as IGT_LOG_WARN. But only if they match one of our filters (which we
should probably allow to be extended, e.g. depending upon which driver
has been openened). This also requires that we at least parse the
basic of kmsg lines (adjusting the timestamp to match our own would be
real cool).

v2:
- Seek to the end of the kmsg buffer before starting the capturing.
- Increase linebuffer to avoid dmesg drowning out all the tests
  messages.

Signed-off-by: Daniel Vetter 
---
 lib/igt_core.c | 41 -
 1 file changed, 40 insertions(+), 1 deletion(-)

diff --git a/lib/igt_core.c b/lib/igt_core.c
index aaafc1df6b46..65b394581e8f 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -293,7 +293,7 @@ static const char *command_str;
 
 static char* igt_debug_log_domain_filter;
 static struct {
-   char *entries[256];
+   char *entries[2000];
uint8_t start, end;
 } log_buffer;
 static pthread_mutex_t log_buffer_mutex = PTHREAD_MUTEX_INITIALIZER;
@@ -581,6 +581,43 @@ static void oom_adjust_for_doom(void)
 
 }
 
+static void *kmsg_capture(void *arg)
+{
+   int kmsg_capture_fd = (uintptr_t) arg;
+   FILE *kmsg_file = fdopen(kmsg_capture_fd, "r");
+   char *line = NULL;
+   size_t line_len = 0;
+   ssize_t read;
+
+   while ((read = getline(, _len, kmsg_file))) {
+   /* FIXME: Set IGT_LOG_WARN for dmesg-warnings */
+   igt_log("dmesg", IGT_LOG_DEBUG, "%i, %s", line[0], line+1);
+   }
+
+   igt_warn("ran out of dmesg, this shouldn't happen\n");
+
+   return NULL;
+}
+
+static void start_kmsg_recording(void)
+{
+   static pthread_t kmsg_capture_thread;
+   int kmsg_capture_fd;
+
+   kmsg_capture_fd = open("/dev/kmsg",
+  O_RDONLY | O_CLOEXEC);
+
+   if (kmsg_capture_fd < 0) {
+   igt_info("no dmesg capturing\n");
+   return;
+   }
+
+   lseek(kmsg_capture_fd, 0, SEEK_END);
+
+   pthread_create(_capture_thread, NULL,
+  kmsg_capture, (void *)(uintptr_t) kmsg_capture_fd);
+}
+
 #ifdef HAVE_GLIB
 static void common_init_config(void)
 {
@@ -814,6 +851,8 @@ out:
kmsg(KERN_INFO "[IGT] %s: executing\n", command_str);
print_version();
 
+   start_kmsg_recording();
+
sync();
oom_adjust_for_doom();
ftrace_dump_on_oops(true);
-- 
2.14.3

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

[Intel-gfx] [RFC PATCH 1/5] tests/sw_sync: use igt_fork_helper

[Daniel Vetter]

I'll need to wrap a bit of magic around all the fork() calls in our
tests. Simplest way to get there is to roll out the existing helpers,
which even saves a bit of boilerplate code.

Cc: Robert Foss 
Signed-off-by: Daniel Vetter 
---
 tests/sw_sync.c | 54 ++
 1 file changed, 18 insertions(+), 36 deletions(-)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 20dfbbb98f58..24974a2f5e4e 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -175,6 +175,7 @@ static void test_sync_busy_fork_unixsocket(void)
int timeline;
int skip = 0;
int sv[2];
+   struct igt_helper_process proc;
 
 
timeline = sw_sync_timeline_create();
@@ -185,9 +186,7 @@ static void test_sync_busy_fork_unixsocket(void)
goto out;
}
 
-   switch (fork()) {
-   case 0:
-   {
+   igt_fork_helper() {
/* Child process */
int socket = sv[1];
int socket_timeline;
@@ -213,17 +212,8 @@ static void test_sync_busy_fork_unixsocket(void)
 
/* Advance timeline from 0 -> 1 */
sw_sync_timeline_inc(socket_timeline, 1);
-
-   _Exit(0);
-   break;
-   }
-   case -1:
-   {
-   /* Failed fork */
-   skip = 1;
-   break;
}
-   default:
+
{
/* Parent process */
int socket = sv[0];
@@ -252,15 +242,14 @@ static void test_sync_busy_fork_unixsocket(void)
 
if (sendmsg(socket, , 0) < 0) {
skip = 1;
-   goto out;
+   } else {
+   igt_assert_f(sync_fence_wait(fence, 2*1000) == 0,
+"Fence not signaled (timeline value 1 
fence seqno 1)\n");
}
-
-   igt_assert_f(sync_fence_wait(fence, 2*1000) == 0,
-"Fence not signaled (timeline value 1 fence seqno 
1)\n");
-   break;
-   }
}
 
+   igt_stop_helper();
+
 out:
close(fence);
close(timeline);
@@ -272,32 +261,25 @@ static void test_sync_busy_fork(void)
int fence;
int timeline;
int skip = 0;
+   struct igt_helper_process proc;
 
timeline = sw_sync_timeline_create();
fence = sw_sync_timeline_create_fence(timeline, 1);
 
-   switch (fork()) {
-   case 0:
-   /* Child process */
+   igt_fork_helper() {
usleep(1*1000*1000);
/* Advance timeline from 0 -> 1 */
sw_sync_timeline_inc(timeline, 1);
-   _Exit(0);
-   break;
-   case -1:
-   /* Failed fork */
-   skip = 1;
-   break;
-   default:
-   /* Parent process */
-   igt_assert_f(sync_fence_wait(fence, 0) == -ETIME,
-"Fence signaled (it should not have been signalled 
yet)\n");
-
-   igt_assert_f(sync_fence_wait(fence, 2*1000) == 0,
-"Fence not signaled (timeline value 1 fence seqno 
1)\n");
-   break;
}
 
+   igt_assert_f(sync_fence_wait(fence, 0) == -ETIME,
+"Fence signaled (it should not have been signalled 
yet)\n");
+
+   igt_assert_f(sync_fence_wait(fence, 2*1000) == 0,
+"Fence not signaled (timeline value 1 fence seqno 1)\n");
+
+   igt_stop_helper();
+
close(fence);
close(timeline);
igt_require(!skip);
-- 
2.14.3

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

[Intel-gfx] [RFC PATCH 2/5] lib/core: make logging pthread vs. fork safe

[Daniel Vetter]

fork() is a pretty thing in a multithreaded program, it's essentially
as bad as handling signals: When we fork the memory snapshot we can
interrupts all other threads at any place, including while they're
holding mutexes and other fun stuff.

libc itself has some internal fork handlers to clear caches and make
sure locks stay in a safe place (we've had plenty of fun with e.g. the
pid/tid caches when a signal happens too fast).

I want to put dmesg capture into igt, into a separate thread (so that
dmesg capture nicely interleaves what the test is doing, +/- races),
and stuff all the dmesg output into the igt logger. Which means we
need to make sure that the log_buffer_mutex is in a predictable state.

Since we have 2 calls to fork() extract a little helper for this.

v2: Stop using fflush(NULL) - somehow this manages to hit a bug in
libc when using a FILE in a separate thread (for capturing dmesg).
Instead explicitly flush stderr and stdout only.

Signed-off-by: Daniel Vetter 
---
 lib/igt_core.c | 25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/lib/igt_core.c b/lib/igt_core.c
index 558a538d35e8..8e7f0da8a44b 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -1518,6 +1518,21 @@ static void fork_helper_exit_handler(int sig)
assert(helper_process_count == 0);
 }
 
+static pid_t __igt_fork_wrapper(void)
+{
+   pid_t ret;
+
+   /* ensure any buffers are flushed before fork */
+   fflush(stdout);
+   fflush(stderr);
+
+   pthread_mutex_lock(_buffer_mutex);
+   ret = fork();
+   pthread_mutex_unlock(_buffer_mutex);
+
+   return ret;
+}
+
 bool __igt_fork_helper(struct igt_helper_process *proc)
 {
pid_t pid;
@@ -1540,10 +1555,7 @@ bool __igt_fork_helper(struct igt_helper_process *proc)
tmp_count = exit_handler_count;
exit_handler_count = 0;
 
-   /* ensure any buffers are flushed before fork */
-   fflush(NULL);
-
-   switch (pid = fork()) {
+   switch (pid = __igt_fork_wrapper()) {
case -1:
exit_handler_count = tmp_count;
igt_assert(0);
@@ -1642,10 +1654,7 @@ bool __igt_fork(void)
igt_assert(test_children);
}
 
-   /* ensure any buffers are flushed before fork */
-   fflush(NULL);
-
-   switch (test_children[num_test_children++] = fork()) {
+   switch (test_children[num_test_children++] = __igt_fork_wrapper()) {
case -1:
igt_assert(0);
case 0:
-- 
2.14.3

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

[Intel-gfx] [RFC PATCH 3/5] lib/core: Don't hide non-debug message when filtering for a debug log domain

[Daniel Vetter]

I think this is the more sensible semantics, since this allows you to
still follow what's going on with the test at a high level, while
filtering for a specific (or multiple specific) debug log domains.

For non-debug messages log-domains technically exist, but we're not
making much use of them really.

Signed-off-by: Daniel Vetter 
---
 lib/igt_core.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/igt_core.c b/lib/igt_core.c
index 8e7f0da8a44b..aaafc1df6b46 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -291,7 +291,7 @@ enum {
 static int igt_exitcode = IGT_EXIT_SUCCESS;
 static const char *command_str;
 
-static char* igt_log_domain_filter;
+static char* igt_debug_log_domain_filter;
 static struct {
char *entries[256];
uint8_t start, end;
@@ -757,7 +757,7 @@ static int common_init(int *argc, char **argv,
case OPT_DEBUG:
igt_log_level = IGT_LOG_DEBUG;
if (optarg && strlen(optarg) > 0)
-   igt_log_domain_filter = strdup(optarg);
+   igt_debug_log_domain_filter = strdup(optarg);
break;
case OPT_LIST_SUBTESTS:
if (!run_single_subtest)
@@ -2104,12 +2104,12 @@ void igt_vlog(const char *domain, enum igt_log_level 
level, const char *format,
goto out;
 
/* check domain filter */
-   if (igt_log_domain_filter) {
+   if (level == IGT_LOG_DEBUG && igt_debug_log_domain_filter) {
/* if null domain and filter is not "application", return */
-   if (!domain && strcmp(igt_log_domain_filter, "application"))
+   if (!domain && strcmp(igt_debug_log_domain_filter, 
"application"))
goto out;
/* else if domain and filter do not match, return */
-   else if (domain && strcmp(igt_log_domain_filter, domain))
+   else if (domain && strcmp(igt_debug_log_domain_filter, domain))
goto out;
}
 
-- 
2.14.3

___
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: Avoid waitboosting on the active request (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Avoid waitboosting on the active request (rev3)
URL   : https://patchwork.freedesktop.org/series/36453/
State : success

== Summary ==

Series 36453v3 drm/i915: Avoid waitboosting on the active request
https://patchwork.freedesktop.org/api/1.0/series/36453/revisions/3/mbox/

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:424s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:427s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:491s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:484s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:465s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:452s
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:276s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:509s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:396s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:399s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:413s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:458s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:411s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:460s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:496s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:454s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:503s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:578s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:440s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:508s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:529s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:487s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:488s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:432s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:531s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:403s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:573s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:475s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:420s
fi-bxt-j4205 failed to collect. IGT log at Patchwork_7708/fi-bxt-j4205/igt.log

68669ade8e500355455124fe96b34614ddc1777b drm-tip: 2018y-01m-18d-12h-01m-38s UTC 
integration manifest
8acc1a2efd04 drm/i915: Avoid waitboosting on the active request

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7708/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for HDCP1.4 implementation enhancement

[Patchwork]

== Series Details ==

Series: HDCP1.4 implementation enhancement
URL   : https://patchwork.freedesktop.org/series/36671/
State : success

== Summary ==

Test gem_tiled_swapping:
Subgroup non-threaded:
incomplete -> DMESG-FAIL (shard-hsw) fdo#104218 +1
Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
pass   -> SKIP   (shard-snb) fdo#103375 +1
Subgroup cursor-128x128-suspend:
skip   -> PASS   (shard-hsw) fdo#103540
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-shrfb-pgflip-blt:
skip   -> PASS   (shard-snb) fdo#101623 +1
Test kms_atomic_interruptible:
Subgroup legacy-setmode:
skip   -> PASS   (shard-snb)
Test pm_rc6_residency:
Subgroup rc6-accuracy:
skip   -> PASS   (shard-snb)
Test perf:
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252

fdo#104218 https://bugs.freedesktop.org/show_bug.cgi?id=104218
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-hswtotal:2680 pass:1674 dwarn:1   dfail:1   fail:11  skip:991 
time:14906s
shard-snbtotal:2675 pass:1287 dwarn:1   dfail:0   fail:10  skip:1377 
time:7570s
Blacklisted hosts:
shard-apltotal:2753 pass:1716 dwarn:1   dfail:0   fail:21  skip:1015 
time:13811s
shard-kbltotal:2735 pass:1811 dwarn:10  dfail:0   fail:23  skip:890 
time:10516s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7706/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v8 6/6] drm/i915: expose rcs topology through query uAPI

[Tvrtko Ursulin]

On 18/01/2018 13:04, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-01-18 12:46:55)


On 17/01/2018 15:39, Lionel Landwerlin wrote:

+
+ if (query_item->length == 0)
+ return total_length;
+
+ if (query_item->length < total_length)
+ return -EINVAL;


Did we talk about whether this check should be != or < yet? != would
sound safer to me, or you want to allow extending the queries in the
future and keeping the same id?


This is me, because I like read(buf, len) style behaviour that lets me
pass in a preallocated buffer that should be big enough without having
to worry and do a 2-pass approach to find out the length of the buffer
to allocate first. '!=' style I have found much more painful to handle in
userspace.


Yeah that's fine by me. Doesn't preclude kernel returning you some new 
fields you don't know about either.


Regards,

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

[Intel-gfx] [CI] drm/i915: Avoid waitboosting on the active request

[Chris Wilson]

Watching a light workload on Baytrail (running glxgears and a 1080p
decode), instead of the system remaining at low frequency, the glxgears
would regularly trigger waitboosting after which it would have to spend
a few seconds throttling back down. In this case, the waitboosting is
counter productive as the minimal wait for glxgears doesn't prevent it
from functioning correctly and delivering frames on time. In this case,
glxgears happens to almost always be waiting on the current request,
which we already expect to complete quickly (see i915_spin_request) and
so avoiding the waitboost on the active request and spinning instead
provides the best latency without overcommitting to upclocking.
However, if the system falls behind we still force the waitboost.
Similarly, we will also trigger upclocking if we detect the system is
not delivering frames on time - again using a mechanism that tries to
detect a miss and not preemptively upclock.

v2: Also skip boosting for after missed vblank if the desired request is
already active.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
Cc: Radoslaw Szwichtenberg 
---
 drivers/gpu/drm/i915/i915_gem.c |  7 +++
 drivers/gpu/drm/i915/i915_gem_request.h | 13 +
 drivers/gpu/drm/i915/intel_display.c|  8 +++-
 3 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b2ba685cb144..7f0684ccc724 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -369,7 +369,8 @@ i915_gem_object_wait_fence(struct dma_fence *fence,
if (i915_gem_request_completed(rq))
goto out;
 
-   /* This client is about to stall waiting for the GPU. In many cases
+   /*
+* This client is about to stall waiting for the GPU. In many cases
 * this is undesirable and limits the throughput of the system, as
 * many clients cannot continue processing user input/output whilst
 * blocked. RPS autotuning may take tens of milliseconds to respond
@@ -384,11 +385,9 @@ i915_gem_object_wait_fence(struct dma_fence *fence,
 * forcing the clocks too high for the whole system, we only allow
 * each client to waitboost once in a busy period.
 */
-   if (rps_client) {
+   if (rps_client && !i915_gem_request_started(rq)) {
if (INTEL_GEN(rq->i915) >= 6)
gen6_rps_boost(rq, rps_client);
-   else
-   rps_client = NULL;
}
 
timeout = i915_wait_request(rq, flags, timeout);
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
b/drivers/gpu/drm/i915/i915_gem_request.h
index 6c607f8dbf92..2236e9188c5c 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -329,6 +329,19 @@ i915_gem_request_completed(const struct 
drm_i915_gem_request *req)
return __i915_gem_request_completed(req, seqno);
 }
 
+static inline bool
+i915_gem_request_started(const struct drm_i915_gem_request *req)
+{
+   u32 seqno;
+
+   seqno = i915_gem_request_global_seqno(req);
+   if (!seqno)
+   return false;
+
+   return i915_seqno_passed(intel_engine_get_seqno(req->engine),
+seqno - 1);
+}
+
 static inline bool i915_priotree_signaled(const struct i915_priotree *pt)
 {
const struct drm_i915_gem_request *rq =
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 221e3a183d36..6b080e221004 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12519,7 +12519,13 @@ static int do_rps_boost(struct wait_queue_entry *_wait,
struct wait_rps_boost *wait = container_of(_wait, typeof(*wait), wait);
struct drm_i915_gem_request *rq = wait->request;
 
-   gen6_rps_boost(rq, NULL);
+   /*
+* If we missed the vblank, but the request is already running it
+* is reasonable to assume that it will complete before the next
+* vblank without our intervention, so leave RPS alone.
+*/
+   if (!i915_gem_request_started(rq))
+   gen6_rps_boost(rq, NULL);
i915_gem_request_put(rq);
 
drm_crtc_vblank_put(wait->crtc);
-- 
2.15.1

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

Re: [Intel-gfx] [PATCH v8 6/6] drm/i915: expose rcs topology through query uAPI

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-01-18 12:46:55)
> 
> On 17/01/2018 15:39, Lionel Landwerlin wrote:
> > +
> > + if (query_item->length == 0)
> > + return total_length;
> > +
> > + if (query_item->length < total_length)
> > + return -EINVAL;
> 
> Did we talk about whether this check should be != or < yet? != would 
> sound safer to me, or you want to allow extending the queries in the 
> future and keeping the same id?

This is me, because I like read(buf, len) style behaviour that lets me
pass in a preallocated buffer that should be big enough without having
to worry and do a 2-pass approach to find out the length of the buffer
to allocate first. '!=' style I have found much more painful to handle in
userspace.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx