Re: [Intel-gfx] [v7][PATCH 00/12] drm/i915: adding state checker for gamma lut values

2019-08-15 Thread Sharma, Swati2
Hi Jani,

I was involved in other activities. Will resume work on this now. 

Thanks and Regards,
Swati

-Original Message-
From: Jani Nikula  
Sent: Thursday, August 15, 2019 1:44 PM
To: Sharma, Swati2 ; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [v7][PATCH 00/12] drm/i915: adding state checker for 
gamma lut values

On Wed, 29 May 2019, Swati Sharma  wrote:
> In this patch series, added state checker to validate gamma and will 
> be extended to validate degamma lut values aswell.
> This reads hardware state, and compares the originally requested state 
> to the state read from hardware.

What happened to this patch series?

BR,
Jani.

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

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Dynamically allocate s0ix struct for VLV

2019-08-15 Thread Lucas De Marchi
On Thu, Aug 15, 2019 at 6:24 PM Daniele Ceraolo Spurio
 wrote:
>
> This is only required for a single platform so no need to reserve the
> memory on all of them.
>
> This removes the last direct dependency of i915_drv.h on i915_reg.h
> (apart from the i915_reg_t definition).
>
> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Imre Deak 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 107 +---
>  drivers/gpu/drm/i915/i915_drv.h |  64 +--
>  2 files changed, 100 insertions(+), 71 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 2541a3a1c229..1723b2ddfccd 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -80,6 +80,68 @@
>
>  static struct drm_driver driver;
>
> +struct vlv_s0ix_state {
> +   /* GAM */
> +   u32 wr_watermark;
> +   u32 gfx_prio_ctrl;
> +   u32 arb_mode;
> +   u32 gfx_pend_tlb0;
> +   u32 gfx_pend_tlb1;
> +   u32 lra_limits[GEN7_LRA_LIMITS_REG_NUM];
> +   u32 media_max_req_count;
> +   u32 gfx_max_req_count;
> +   u32 render_hwsp;
> +   u32 ecochk;
> +   u32 bsd_hwsp;
> +   u32 blt_hwsp;
> +   u32 tlb_rd_addr;
> +
> +   /* MBC */
> +   u32 g3dctl;
> +   u32 gsckgctl;
> +   u32 mbctl;
> +
> +   /* GCP */
> +   u32 ucgctl1;
> +   u32 ucgctl3;
> +   u32 rcgctl1;
> +   u32 rcgctl2;
> +   u32 rstctl;
> +   u32 misccpctl;
> +
> +   /* GPM */
> +   u32 gfxpause;
> +   u32 rpdeuhwtc;
> +   u32 rpdeuc;
> +   u32 ecobus;
> +   u32 pwrdwnupctl;
> +   u32 rp_down_timeout;
> +   u32 rp_deucsw;
> +   u32 rcubmabdtmr;
> +   u32 rcedata;
> +   u32 spare2gh;
> +
> +   /* Display 1 CZ domain */
> +   u32 gt_imr;
> +   u32 gt_ier;
> +   u32 pm_imr;
> +   u32 pm_ier;
> +   u32 gt_scratch[GEN7_GT_SCRATCH_REG_NUM];
> +
> +   /* GT SA CZ domain */
> +   u32 tilectl;
> +   u32 gt_fifoctl;
> +   u32 gtlc_wake_ctrl;
> +   u32 gtlc_survive;
> +   u32 pmwgicz;
> +
> +   /* Display 2 CZ domain */
> +   u32 gu_ctl0;
> +   u32 gu_ctl1;
> +   u32 pcbr;
> +   u32 clock_gate_dis2;
> +};
> +
>  static int i915_get_bridge_dev(struct drm_i915_private *dev_priv)
>  {
> int domain = pci_domain_nr(dev_priv->drm.pdev->bus);
> @@ -466,6 +528,28 @@ static void intel_detect_preproduction_hw(struct 
> drm_i915_private *dev_priv)
> }
>  }
>
> +static int vlv_alloc_s0ix_state(struct drm_i915_private *i915)
> +{
> +   if (!IS_VALLEYVIEW(i915))
> +   return 0;
> +
> +   /* we write all the values in the structure, so no need to zero it 
> out */
> +   i915->s0ix_state = kmalloc(sizeof(struct vlv_s0ix_state), GFP_KERNEL);
> +   if (!i915->s0ix_state)
> +   return -ENOMEM;
> +
> +   return 0;
> +}
> +
> +static void vlv_free_s0ix_state(struct drm_i915_private *i915)
> +{
> +   if (!i915->s0ix_state)
> +   return;
> +
> +   kfree(i915->s0ix_state);
> +   i915->s0ix_state = NULL;
> +}
> +
>  /**
>   * i915_driver_early_probe - setup state not requiring device access
>   * @dev_priv: device private
> @@ -508,13 +592,17 @@ static int i915_driver_early_probe(struct 
> drm_i915_private *dev_priv)
> if (ret < 0)
> return ret;
>
> +   ret = vlv_alloc_s0ix_state(dev_priv);
> +   if (ret < 0)
> +   goto err_workqueues;
> +
> intel_wopcm_init_early(_priv->wopcm);
>
> intel_gt_init_early(_priv->gt, dev_priv);
>
> ret = i915_gem_init_early(dev_priv);
> if (ret < 0)
> -   goto err_workqueues;
> +   goto err_gt;
>
> /* This must be called before any calls to HAS_PCH_* */
> intel_detect_pch(dev_priv);
> @@ -536,8 +624,10 @@ static int i915_driver_early_probe(struct 
> drm_i915_private *dev_priv)
>
>  err_gem:
> i915_gem_cleanup_early(dev_priv);
> -err_workqueues:
> +err_gt:
> intel_gt_driver_late_release(_priv->gt);
> +   vlv_free_s0ix_state(dev_priv);
> +err_workqueues:
> i915_workqueues_cleanup(dev_priv);
> return ret;
>  }
> @@ -553,6 +643,7 @@ static void i915_driver_late_release(struct 
> drm_i915_private *dev_priv)
> intel_power_domains_cleanup(dev_priv);
> i915_gem_cleanup_early(dev_priv);
> intel_gt_driver_late_release(_priv->gt);
> +   vlv_free_s0ix_state(dev_priv);
> i915_workqueues_cleanup(dev_priv);
>
> pm_qos_remove_request(_priv->sb_qos);
> @@ -2137,7 +2228,7 @@ static int i915_pm_restore(struct device *kdev)
>   */
>  static void vlv_save_gunit_s0ix_state(struct drm_i915_private *dev_priv)
>  {
> -   struct vlv_s0ix_state *s = _priv->vlv_s0ix_state;
> +   struct vlv_s0ix_state *s = dev_priv->s0ix_state;
> int i;
>
> /* GAM 0x4000-0x4770 */
> @@ -2147,7 +2238,7 @@ static void vlv_save_gunit_s0ix_state(struct 

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Move gmbus definitions out of i915_reg.h

2019-08-15 Thread Lucas De Marchi
On Thu, Aug 15, 2019 at 6:24 PM Daniele Ceraolo Spurio
 wrote:
>
> They're not related to registers, so move them to the more appropriate
> intel_gmbus.h
>
> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/display/intel_gmbus.h | 22 ++
>  drivers/gpu/drm/i915/i915_drv.h|  1 +
>  drivers/gpu/drm/i915/i915_reg.h| 22 +-
>  3 files changed, 24 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.h 
> b/drivers/gpu/drm/i915/display/intel_gmbus.h
> index d989085b8d22..b96212b85425 100644
> --- a/drivers/gpu/drm/i915/display/intel_gmbus.h
> +++ b/drivers/gpu/drm/i915/display/intel_gmbus.h
> @@ -11,6 +11,28 @@
>  struct drm_i915_private;
>  struct i2c_adapter;
>
> +#define GMBUS_PIN_DISABLED 0
> +#define GMBUS_PIN_SSC  1
> +#define GMBUS_PIN_VGADDC   2
> +#define GMBUS_PIN_PANEL3
> +#define GMBUS_PIN_DPD_CHV  3 /* HDMID_CHV */
> +#define GMBUS_PIN_DPC  4 /* HDMIC */
> +#define GMBUS_PIN_DPB  5 /* SDVO, HDMIB */
> +#define GMBUS_PIN_DPD  6 /* HDMID */
> +#define GMBUS_PIN_RESERVED 7 /* 7 reserved */
> +#define GMBUS_PIN_1_BXT1 /* BXT+ (atom) and CNP+ (big core) 
> */
> +#define GMBUS_PIN_2_BXT2
> +#define GMBUS_PIN_3_BXT3
> +#define GMBUS_PIN_4_CNP4
> +#define GMBUS_PIN_9_TC1_ICP9
> +#define GMBUS_PIN_10_TC2_ICP   10
> +#define GMBUS_PIN_11_TC3_ICP   11
> +#define GMBUS_PIN_12_TC4_ICP   12
> +#define GMBUS_PIN_13_TC5_TGP   13
> +#define GMBUS_PIN_14_TC6_TGP   14
> +
> +#define GMBUS_NUM_PINS 15 /* including 0 */
> +
>  int intel_gmbus_setup(struct drm_i915_private *dev_priv);
>  void intel_gmbus_teardown(struct drm_i915_private *dev_priv);
>  bool intel_gmbus_is_valid_pin(struct drm_i915_private *dev_priv,
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index c4406a60f3e4..c6722d54ccd5 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -68,6 +68,7 @@
>  #include "display/intel_display_power.h"
>  #include "display/intel_dpll_mgr.h"
>  #include "display/intel_frontbuffer.h"
> +#include "display/intel_gmbus.h"

if it wasn't GMBUS_NUM_PINS we could include-what-you-use rather than
adding the include here.
Alternative would be to leave the GMBUS_NUM_PINS here, which would be
ugly. Or dynamically allocate
the array, that would deserve a more careful thought.

Reviewed-by: Lucas De Marchi 

Lucas De Marchi

>  #include "display/intel_opregion.h"
>
>  #include "gem/i915_gem_context_types.h"
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 827795262d68..ea2f0fa2402d 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3207,27 +3207,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>  #define   GMBUS_RATE_1MHZ  (3 << 8) /* reserved on Pineview */
>  #define   GMBUS_HOLD_EXT   (1 << 7) /* 300ns hold time, rsvd on Pineview 
> */
>  #define   GMBUS_BYTE_CNT_OVERRIDE (1 << 6)
> -#define   GMBUS_PIN_DISABLED   0
> -#define   GMBUS_PIN_SSC1
> -#define   GMBUS_PIN_VGADDC 2
> -#define   GMBUS_PIN_PANEL  3
> -#define   GMBUS_PIN_DPD_CHV3 /* HDMID_CHV */
> -#define   GMBUS_PIN_DPC4 /* HDMIC */
> -#define   GMBUS_PIN_DPB5 /* SDVO, HDMIB */
> -#define   GMBUS_PIN_DPD6 /* HDMID */
> -#define   GMBUS_PIN_RESERVED   7 /* 7 reserved */
> -#define   GMBUS_PIN_1_BXT  1 /* BXT+ (atom) and CNP+ (big core) */
> -#define   GMBUS_PIN_2_BXT  2
> -#define   GMBUS_PIN_3_BXT  3
> -#define   GMBUS_PIN_4_CNP  4
> -#define   GMBUS_PIN_9_TC1_ICP  9
> -#define   GMBUS_PIN_10_TC2_ICP 10
> -#define   GMBUS_PIN_11_TC3_ICP 11
> -#define   GMBUS_PIN_12_TC4_ICP 12
> -#define   GMBUS_PIN_13_TC5_TGP 13
> -#define   GMBUS_PIN_14_TC6_TGP 14
> -
> -#define   GMBUS_NUM_PINS   15 /* including 0 */
> +
>  #define GMBUS1 _MMIO(dev_priv->gpio_mmio_base + 0x5104) /* 
> command/status */
>  #define   GMBUS_SW_CLR_INT (1 << 31)
>  #define   GMBUS_SW_RDY (1 << 30)
> --
> 2.22.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Lucas De Marchi
___
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/selftest/buddy: fixup igt_buddy_alloc_range

2019-08-15 Thread Patchwork
== Series Details ==

Series: drm/i915/selftest/buddy: fixup igt_buddy_alloc_range
URL   : https://patchwork.freedesktop.org/series/65256/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6711_full -> Patchwork_14029_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_14029_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_schedule@preempt-other-chain-bsd:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#111325]) +3 similar 
issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb5/igt@gem_exec_sched...@preempt-other-chain-bsd.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14029/shard-iclb4/igt@gem_exec_sched...@preempt-other-chain-bsd.html

  * igt@gem_exec_schedule@promotion-bsd1:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276]) +19 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb4/igt@gem_exec_sched...@promotion-bsd1.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14029/shard-iclb7/igt@gem_exec_sched...@promotion-bsd1.html

  * igt@i915_pm_rpm@system-suspend-modeset:
- shard-skl:  [PASS][5] -> [INCOMPLETE][6] ([fdo#104108] / 
[fdo#107807])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-skl4/igt@i915_pm_...@system-suspend-modeset.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14029/shard-skl3/igt@i915_pm_...@system-suspend-modeset.html

  * igt@i915_suspend@debugfs-reader:
- shard-apl:  [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +2 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-apl5/igt@i915_susp...@debugfs-reader.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14029/shard-apl2/igt@i915_susp...@debugfs-reader.html

  * igt@kms_cursor_legacy@cursor-vs-flip-varying-size:
- shard-apl:  [PASS][9] -> [INCOMPLETE][10] ([fdo#103927]) +2 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-apl1/igt@kms_cursor_leg...@cursor-vs-flip-varying-size.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14029/shard-apl1/igt@kms_cursor_leg...@cursor-vs-flip-varying-size.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl:  [PASS][11] -> [FAIL][12] ([fdo#105363])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-skl5/igt@kms_f...@flip-vs-expired-vblank-interruptible.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14029/shard-skl2/igt@kms_f...@flip-vs-expired-vblank-interruptible.html
- shard-glk:  [PASS][13] -> [FAIL][14] ([fdo#105363]) +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-glk7/igt@kms_f...@flip-vs-expired-vblank-interruptible.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14029/shard-glk5/igt@kms_f...@flip-vs-expired-vblank-interruptible.html

  * igt@kms_flip@plain-flip-fb-recreate:
- shard-skl:  [PASS][15] -> [FAIL][16] ([fdo#100368])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-skl7/igt@kms_f...@plain-flip-fb-recreate.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14029/shard-skl3/igt@kms_f...@plain-flip-fb-recreate.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-pri-indfb-multidraw:
- shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb3/igt@kms_frontbuffer_track...@fbcpsr-1p-pri-indfb-multidraw.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14029/shard-iclb6/igt@kms_frontbuffer_track...@fbcpsr-1p-pri-indfb-multidraw.html

  * igt@kms_psr2_su@page_flip:
- shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109642] / [fdo#111068])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb2/igt@kms_psr2_su@page_flip.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14029/shard-iclb8/igt@kms_psr2_su@page_flip.html

  * igt@kms_psr@psr2_primary_mmap_cpu:
- shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +1 similar 
issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14029/shard-iclb8/igt@kms_psr@psr2_primary_mmap_cpu.html

  
 Possible fixes 

  * igt@gem_ctx_shared@exec-single-timeline-bsd:
- shard-iclb: [SKIP][23] ([fdo#110841]) -> [PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb4/igt@gem_ctx_sha...@exec-single-timeline-bsd.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14029/shard-iclb7/igt@gem_ctx_sha...@exec-single-timeline-bsd.html

  * igt@gem_exec_balancer@smoke:
- 

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Move engine IDs out of i915_reg.h

2019-08-15 Thread Lucas De Marchi
On Thu, Aug 15, 2019 at 6:23 PM Daniele Ceraolo Spurio
 wrote:
>
> To remove the dependency between the GT headers and i915_reg.h, move the
> definition of the engine IDs/classes to intel_engine_types.h
>
> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Chris Wilson 
> Cc: Tvrtko Ursulin 

Reviewed-by: Lucas De Marchi 

Lucas De Marchi

> ---
>  drivers/gpu/drm/i915/gt/intel_engine_types.h | 20 +++
>  drivers/gpu/drm/i915/gt/intel_gt_types.h |  1 +
>  drivers/gpu/drm/i915/i915_reg.h  | 27 +++-
>  3 files changed, 24 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
> b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> index a0f372807dd4..8f10c5ffd68d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> @@ -26,6 +26,26 @@
>  #include "intel_wakeref.h"
>  #include "intel_workarounds_types.h"
>
> +/* Legacy HW Engine ID */
> +
> +#define RCS0_HW0
> +#define VCS0_HW1
> +#define BCS0_HW2
> +#define VECS0_HW   3
> +#define VCS1_HW4
> +#define VCS2_HW6
> +#define VCS3_HW7
> +#define VECS1_HW   12
> +
> +/* Gen11+ HW Engine class + instance */
> +#define RENDER_CLASS   0
> +#define VIDEO_DECODE_CLASS 1
> +#define VIDEO_ENHANCEMENT_CLASS2
> +#define COPY_ENGINE_CLASS  3
> +#define OTHER_CLASS4
> +#define MAX_ENGINE_CLASS   4
> +#define MAX_ENGINE_INSTANCE3
> +
>  #define I915_MAX_SLICES3
>  #define I915_MAX_SUBSLICES 8
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h 
> b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> index adab4d2c29ac..81f9de45ab36 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> @@ -16,6 +16,7 @@
>  #include "uc/intel_uc.h"
>
>  #include "i915_vma.h"
> +#include "intel_engine_types.h"
>  #include "intel_reset_types.h"
>  #include "intel_wakeref.h"
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 14165d619175..827795262d68 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -272,30 +272,6 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>  #define _MASKED_BIT_ENABLE(a)  ({ typeof(a) _a = (a); _MASKED_FIELD(_a, _a); 
> })
>  #define _MASKED_BIT_DISABLE(a) (_MASKED_FIELD((a), 0))
>
> -/* Engine ID */
> -
> -#define RCS0_HW0
> -#define VCS0_HW1
> -#define BCS0_HW2
> -#define VECS0_HW   3
> -#define VCS1_HW4
> -#define VCS2_HW6
> -#define VCS3_HW7
> -#define VECS1_HW   12
> -
> -/* Engine class */
> -
> -#define RENDER_CLASS   0
> -#define VIDEO_DECODE_CLASS 1
> -#define VIDEO_ENHANCEMENT_CLASS2
> -#define COPY_ENGINE_CLASS  3
> -#define OTHER_CLASS4
> -#define MAX_ENGINE_CLASS   4
> -
> -#define OTHER_GUC_INSTANCE 0
> -#define OTHER_GTPM_INSTANCE1
> -#define MAX_ENGINE_INSTANCE3
> -
>  /* PCI config space */
>
>  #define MCHBAR_I915 0x44
> @@ -7505,6 +7481,9 @@ enum {
>  #define  GEN11_INTR_ENGINE_CLASS(x)(((x) & GENMASK(18, 16)) >> 16)
>  #define  GEN11_INTR_ENGINE_INSTANCE(x) (((x) & GENMASK(25, 20)) >> 20)
>  #define  GEN11_INTR_ENGINE_INTR(x) ((x) & 0x)
> +/* irq instances for OTHER_CLASS */
> +#define OTHER_GUC_INSTANCE 0
> +#define OTHER_GTPM_INSTANCE1
>
>  #define GEN11_INTR_IDENTITY_REG(x) _MMIO(0x190060 + ((x) * 4))
>
> --
> 2.22.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



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

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Move i915_power_well_id out of i915_reg.h

2019-08-15 Thread Lucas De Marchi
On Thu, Aug 15, 2019 at 6:24 PM Daniele Ceraolo Spurio
 wrote:
>
> It has nothing to do with registers, so move it to the more appropriate
> intel_display_power.h
>
> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Imre Deak 
> ---
>  .../drm/i915/display/intel_display_power.c|  1 +
>  .../drm/i915/display/intel_display_power.h| 21 +++
>  drivers/gpu/drm/i915/display/intel_hdcp.c |  1 +
>  drivers/gpu/drm/i915/i915_reg.h   | 21 ---
>  4 files changed, 23 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 374b75602141..1caae2f61216 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -13,6 +13,7 @@
>  #include "intel_cdclk.h"
>  #include "intel_combo_phy.h"
>  #include "intel_csr.h"
> +#include "intel_display_power.h"
>  #include "intel_display_types.h"
>  #include "intel_dpio_phy.h"
>  #include "intel_hotplug.h"
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h 
> b/drivers/gpu/drm/i915/display/intel_display_power.h
> index 97f2562fc5d3..a50605b8b1ad 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.h
> @@ -92,6 +92,27 @@ enum intel_display_power_domain {
> POWER_DOMAIN_NUM,
>  };
>
> +/*
> + * i915_power_well_id:
> + *
> + * IDs used to look up power wells. Power wells accessed directly bypassing
> + * the power domains framework must be assigned a unique ID. The rest of 
> power
> + * wells must be assigned DISP_PW_ID_NONE.
> + */
> +enum i915_power_well_id {
> +   DISP_PW_ID_NONE,
> +
> +   VLV_DISP_PW_DISP2D,
> +   BXT_DISP_PW_DPIO_CMN_A,
> +   VLV_DISP_PW_DPIO_CMN_BC,
> +   GLK_DISP_PW_DPIO_CMN_C,
> +   CHV_DISP_PW_DPIO_CMN_D,
> +   HSW_DISP_PW_GLOBAL,
> +   SKL_DISP_PW_MISC_IO,
> +   SKL_DISP_PW_1,
> +   SKL_DISP_PW_2,
> +};
> +
>  #define POWER_DOMAIN_PIPE(pipe) ((pipe) + POWER_DOMAIN_PIPE_A)
>  #define POWER_DOMAIN_PIPE_PANEL_FITTER(pipe) \
> ((pipe) + POWER_DOMAIN_PIPE_A_PANEL_FITTER)
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index dc4aaec2e04c..0beb954b5318 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -14,6 +14,7 @@
>  #include 
>
>  #include "i915_reg.h"
> +#include "intel_display_power.h"
>  #include "intel_display_types.h"
>  #include "intel_hdcp.h"
>  #include "intel_sideband.h"
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 2b7ccebf6550..14165d619175 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1163,27 +1163,6 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>  #define PUNIT_REG_ISPSSPM0 0x39
>  #define PUNIT_REG_ISPSSPM1 0x3a
>
> -/*
> - * i915_power_well_id:
> - *
> - * IDs used to look up power wells. Power wells accessed directly bypassing
> - * the power domains framework must be assigned a unique ID. The rest of 
> power
> - * wells must be assigned DISP_PW_ID_NONE.
> - */
> -enum i915_power_well_id {
> -   DISP_PW_ID_NONE,
> -
> -   VLV_DISP_PW_DISP2D,
> -   BXT_DISP_PW_DPIO_CMN_A,
> -   VLV_DISP_PW_DPIO_CMN_BC,
> -   GLK_DISP_PW_DPIO_CMN_C,
> -   CHV_DISP_PW_DPIO_CMN_D,
> -   HSW_DISP_PW_GLOBAL,
> -   SKL_DISP_PW_MISC_IO,
> -   SKL_DISP_PW_1,
> -   SKL_DISP_PW_2,
> -};

drivers/gpu/drm/i915/display/intel_hdcp.c also uses this enum, so it
should also include the header
in which it's defined.

other than that
Reviewed-by: Lucas De Marchi 

Lucas De Marchi

> -
>  #define PUNIT_REG_PWRGT_CTRL   0x60
>  #define PUNIT_REG_PWRGT_STATUS 0x61
>  #define   PUNIT_PWRGT_MASK(pw_idx) (3 << ((pw_idx) * 2))
> --
> 2.22.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



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

Re: [Intel-gfx] linux-next: build warning after merge of the drm-misc tree

2019-08-15 Thread Sam Ravnborg
Hi Stephen.

On Fri, Aug 16, 2019 at 01:31:32PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
> 
> warning: same module names found:
>   drivers/video/fbdev/omap2/omapfb/displays/panel-nec-nl8048hl11.ko
>   drivers/gpu/drm/panel/panel-nec-nl8048hl11.ko
> warning: same module names found:
>   drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.ko
>   drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.ko
> warning: same module names found:
>   drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.ko
>   drivers/gpu/drm/panel/panel-sony-acx565akm.ko
> warning: same module names found:
>   drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.ko
>   drivers/gpu/drm/panel/panel-tpo-td028ttec1.ko
> warning: same module names found:
>   drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.ko
>   drivers/gpu/drm/panel/panel-tpo-td043mtea1.ko
> 
> Introduced by commits
> 
>   df439abe6501 ("drm/panel: Add driver for the NEC NL8048HL11 panel")
>   c9cf4c2a3bd3 ("drm/panel: Add driver for the Sharp LS037V7DW01 panel")
>   1c8fc3f0c5d2 ("drm/panel: Add driver for the Sony ACX565AKM panel")
>   415b8dd08711 ("drm/panel: Add driver for the Toppoly TD028TTEC1 panel")
>   dc2e1e5b2799 ("drm/panel: Add driver for the Toppoly TD043MTEA1 panel")

Ups, had not seen this one coming.
We are in the process of removing the drivers in 
drivers/video/fbdev/omap2/omapfb/
and decided to introduce the new drivers early to get them out of a
longer patch series.

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

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915/icl: Implement gen11 flush including tile cache (rev2)

2019-08-15 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915/icl: Implement gen11 flush 
including tile cache (rev2)
URL   : https://patchwork.freedesktop.org/series/65226/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6711_full -> Patchwork_14028_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_14028_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_async@concurrent-writes-bsd:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#111325]) +4 similar 
issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb7/igt@gem_exec_as...@concurrent-writes-bsd.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14028/shard-iclb2/igt@gem_exec_as...@concurrent-writes-bsd.html

  * igt@gem_exec_schedule@promotion-bsd1:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276]) +21 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb4/igt@gem_exec_sched...@promotion-bsd1.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14028/shard-iclb7/igt@gem_exec_sched...@promotion-bsd1.html

  * igt@gem_tiled_swapping@non-threaded:
- shard-kbl:  [PASS][5] -> [DMESG-WARN][6] ([fdo#108686])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-kbl3/igt@gem_tiled_swapp...@non-threaded.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14028/shard-kbl7/igt@gem_tiled_swapp...@non-threaded.html

  * igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-apl:  [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +2 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-apl8/igt@kms_cursor_...@pipe-c-cursor-suspend.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14028/shard-apl5/igt@kms_cursor_...@pipe-c-cursor-suspend.html

  * igt@kms_cursor_legacy@2x-long-nonblocking-modeset-vs-cursor-atomic:
- shard-glk:  [PASS][9] -> [FAIL][10] ([fdo#106509] / [fdo#107409])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-glk9/igt@kms_cursor_leg...@2x-long-nonblocking-modeset-vs-cursor-atomic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14028/shard-glk7/igt@kms_cursor_leg...@2x-long-nonblocking-modeset-vs-cursor-atomic.html

  * igt@kms_cursor_legacy@cursor-vs-flip-atomic:
- shard-hsw:  [PASS][11] -> [FAIL][12] ([fdo#103355])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-hsw2/igt@kms_cursor_leg...@cursor-vs-flip-atomic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14028/shard-hsw6/igt@kms_cursor_leg...@cursor-vs-flip-atomic.html

  * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
- shard-glk:  [PASS][13] -> [FAIL][14] ([fdo#105363])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-glk9/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14028/shard-glk8/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
- shard-skl:  [PASS][15] -> [INCOMPLETE][16] ([fdo#109507])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-skl9/igt@kms_f...@flip-vs-suspend-interruptible.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14028/shard-skl5/igt@kms_f...@flip-vs-suspend-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt:
- shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167]) +4 similar 
issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb7/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-blt.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14028/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-blt.html

  * igt@kms_psr@psr2_cursor_plane_move:
- shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +1 similar 
issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb2/igt@kms_psr@psr2_cursor_plane_move.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14028/shard-iclb1/igt@kms_psr@psr2_cursor_plane_move.html

  
 Possible fixes 

  * igt@gem_ctx_shared@exec-single-timeline-bsd:
- shard-iclb: [SKIP][21] ([fdo#110841]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb4/igt@gem_ctx_sha...@exec-single-timeline-bsd.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14028/shard-iclb5/igt@gem_ctx_sha...@exec-single-timeline-bsd.html

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [SKIP][23] ([fdo#110854]) -> [PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb6/igt@gem_exec_balan...@smoke.html
   

[Intel-gfx] linux-next: build warning after merge of the drm-misc tree

2019-08-15 Thread Stephen Rothwell
Hi all,

After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

warning: same module names found:
  drivers/video/fbdev/omap2/omapfb/displays/panel-nec-nl8048hl11.ko
  drivers/gpu/drm/panel/panel-nec-nl8048hl11.ko
warning: same module names found:
  drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.ko
  drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.ko
warning: same module names found:
  drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.ko
  drivers/gpu/drm/panel/panel-sony-acx565akm.ko
warning: same module names found:
  drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.ko
  drivers/gpu/drm/panel/panel-tpo-td028ttec1.ko
warning: same module names found:
  drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.ko
  drivers/gpu/drm/panel/panel-tpo-td043mtea1.ko

Introduced by commits

  df439abe6501 ("drm/panel: Add driver for the NEC NL8048HL11 panel")
  c9cf4c2a3bd3 ("drm/panel: Add driver for the Sharp LS037V7DW01 panel")
  1c8fc3f0c5d2 ("drm/panel: Add driver for the Sony ACX565AKM panel")
  415b8dd08711 ("drm/panel: Add driver for the Toppoly TD028TTEC1 panel")
  dc2e1e5b2799 ("drm/panel: Add driver for the Toppoly TD043MTEA1 panel")

-- 
Cheers,
Stephen Rothwell


pgpnl74XI_fNm.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Linux Kernel 5.2.8 (uvc or i915? <<<)

2019-08-15 Thread Randy Dunlap
[adding mailing lists etc. with Nathaniel's test info]


On 8/15/19 7:21 PM, Nathaniel Russell wrote:
> Well i surpressed the uvcvideo driver and you are right Randy it
> definitely is not the uvcvideo driver. There is something going on in
> the i915 driver.
> 
> 
> On 8/15/19, Randy Dunlap  wrote:
>> On 8/15/19 6:15 PM, Nathaniel Russell wrote:
>>> I would really like help with the kernel error with my uvcvideo driver.
>>>
>>
>> Hi again.
>>
>> What makes you think that the problem is related to the uvcvideo driver?
>> Does some previous kernel version work correctly?  If so, what version(s)?
>>
>>
>> Does this warning message only happen when the uvcvideo driver is being
>> loaded?
>> Can you suppress loading of the uvcvideo driver to find out?
>>
>> Most of the problems/errors/warnings that I see are related to the i915
>> driver:
>>
>> [   13.032341] timed out waiting for port C ready: got 0x20, expected 0xe0
>> [   13.032872] WARNING: CPU: 1 PID: 239 at
>> drivers/gpu/drm/i915/intel_display.c:1597 vlv_wait_port_ready+0x99/0xe0
>> [i915]
>> [   13.033632] RIP: 0010:vlv_wait_port_ready+0x99/0xe0 [i915]
>>
>> although there are a few uvcvideo warnings:
>> [   13.039305] uvcvideo 1-5:1.0: Entity type for entity Extension 4 was not
>> initialized!
>> [   13.039318] uvcvideo 1-5:1.0: Entity type for entity Extension 3 was not
>> initialized!
>> [   13.039330] uvcvideo 1-5:1.0: Entity type for entity Processing 2 was not
>> initialized!
>> [   13.039339] uvcvideo 1-5:1.0: Entity type for entity Camera 1 was not
>> initialized!
>>
>>
>> Laurent, do you see any uvc issues here?  Any ideas/suggestions?
>>
>>
>> @intel-gfx:  any ideas about what is going on here with the i915 driver?
>>
>>
>>
>> Original message to lkml:
>> https://lore.kernel.org/lkml/CAONH+Jm-O6=dq+k2n5pntnmg2sq1kcvnfluwevh6w82opef...@mail.gmail.com/T/#u
>>
>> Previous message for 5.1.21 kernel:
>> https://lore.kernel.org/lkml/CAONH+JkTFujY9vEyNNuem+9rJ2qBKkf-PbKk9=DBSVEp6kW=y...@mail.gmail.com/
>>
>>
>> thanks.
>> --
>> ~Randy
>>


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

Re: [Intel-gfx] [PATCH 1/3] drm/i915/tgl: Introduce initial Tigerlake Workarounds

2019-08-15 Thread Lucas De Marchi

On Tue, Aug 13, 2019 at 11:07:54AM -0700, Radhakrishna Sripada wrote:

On Thu, Jul 25, 2019 at 05:02:24PM -0700, Lucas De Marchi wrote:

From: Michel Thierry 

Inherit workarounds from previous platforms that are still valid for
Tigerlake.

  WaPipelineFlushCoherentLines:tgl (changed register but has same name)
  WaSendPushConstantsFromMMIO:tgl
  WaAllowUMDToModifySamplerMode:tgl
  WaRsForcewakeAddDelayForAck:tgl

Cc: Daniele Ceraolo Spurio 
Signed-off-by: Michel Thierry 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/gt/intel_lrc.c |  2 ++
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 40 +++--
 drivers/gpu/drm/i915/i915_reg.h |  3 ++
 drivers/gpu/drm/i915/intel_pm.c |  4 ++-
 drivers/gpu/drm/i915/intel_uncore.c |  2 +-
 5 files changed, 46 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 884dfc1cb033..893c58df8be0 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2069,6 +2069,8 @@ static int intel_init_workaround_bb(struct 
intel_engine_cs *engine)
return 0;

switch (INTEL_GEN(engine->i915)) {
+   case 12:
+   return 0;
case 11:
return 0;
case 10:
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 704ace01e7f5..a6eb9c6e87ec 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -569,6 +569,11 @@ static void icl_ctx_workarounds_init(struct 
intel_engine_cs *engine,
  GEN11_SAMPLER_ENABLE_HEADLESS_MSG);
 }

+static void tgl_ctx_workarounds_init(struct intel_engine_cs *engine,
+struct i915_wa_list *wal)
+{
+}
+
 static void
 __intel_engine_init_ctx_wa(struct intel_engine_cs *engine,
   struct i915_wa_list *wal,
@@ -581,7 +586,9 @@ __intel_engine_init_ctx_wa(struct intel_engine_cs *engine,

wa_init_start(wal, name, engine->name);

-   if (IS_GEN(i915, 11))
+   if (IS_GEN(i915, 12))
+   tgl_ctx_workarounds_init(engine, wal);
+   else if (IS_GEN(i915, 11))
icl_ctx_workarounds_init(engine, wal);
else if (IS_CANNONLAKE(i915))
cnl_ctx_workarounds_init(engine, wal);
@@ -890,10 +897,17 @@ icl_gt_workarounds_init(struct drm_i915_private *i915, 
struct i915_wa_list *wal)
GAMT_CHKN_DISABLE_L3_COH_PIPE);
 }

+static void
+tgl_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list 
*wal)
+{
+}
+
 static void
 gt_init_workarounds(struct drm_i915_private *i915, struct i915_wa_list *wal)
 {
-   if (IS_GEN(i915, 11))
+   if (IS_GEN(i915, 12))
+   tgl_gt_workarounds_init(i915, wal);
+   else if (IS_GEN(i915, 11))
icl_gt_workarounds_init(i915, wal);
else if (IS_CANNONLAKE(i915))
cnl_gt_workarounds_init(i915, wal);
@@ -1183,6 +1197,17 @@ static void icl_whitelist_build(struct intel_engine_cs 
*engine)
}
 }

+static void tgl_whitelist_build(struct intel_engine_cs *engine)
+{
+   struct i915_wa_list *w = >whitelist;
+
+   /* WaSendPushConstantsFromMMIO:tgl */
+   whitelist_reg(w, COMMON_SLICE_CHICKEN2);
+
+   /* WaAllowUMDToModifySamplerMode:tgl */
+   whitelist_reg(w, GEN10_SAMPLER_MODE);

Are there user space consumers for the above 2 workarounds?
ICL does not seem to carry them.


I don't think so. At least *I* was not involved with any. My main
interest here was actually to add the infra for TGL (aka remove the
warning) and inherit the WAs carried over from ICL. If they are not
valid for ICL because there is not user, could you send a patch for ICL?

I will send a new patch without these.

thanks
Lucas De Marchi



- Radhakrishna(RK) Sripada

+}
+
 void intel_engine_init_whitelist(struct intel_engine_cs *engine)
 {
struct drm_i915_private *i915 = engine->i915;
@@ -1190,7 +1215,9 @@ void intel_engine_init_whitelist(struct intel_engine_cs 
*engine)

wa_init_start(w, "whitelist", engine->name);

-   if (IS_GEN(i915, 11))
+   if (IS_GEN(i915, 12))
+   tgl_whitelist_build(engine);
+   else if (IS_GEN(i915, 11))
icl_whitelist_build(engine);
else if (IS_CANNONLAKE(i915))
cnl_whitelist_build(engine);
@@ -1240,6 +1267,13 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, 
struct i915_wa_list *wal)
 {
struct drm_i915_private *i915 = engine->i915;

+   if (IS_GEN(i915, 12)) {
+   /* WaPipelineFlushCoherentLines:tgl */
+   wa_write_or(wal,
+   GEN12_L3SQCREG2,
+   GEN12_LQSC_FLUSH_COHERENT_LINES);
+   }
+
if (IS_GEN(i915, 11)) {
/* This is not an Wa. Enable for better image quality */
  

[Intel-gfx] ✓ Fi.CI.BAT: success for Some more display uncore prep work

2019-08-15 Thread Patchwork
== Series Details ==

Series: Some more display uncore prep work
URL   : https://patchwork.freedesktop.org/series/65281/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6714 -> Patchwork_14043


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14043/

Known issues


  Here are the changes found in Patchwork_14043 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_flink_basic@bad-flink:
- fi-icl-u3:  [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +1 
similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-icl-u3/igt@gem_flink_ba...@bad-flink.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14043/fi-icl-u3/igt@gem_flink_ba...@bad-flink.html

  
 Possible fixes 

  * igt@gem_mmap_gtt@basic-small-bo-tiledx:
- fi-icl-u3:  [DMESG-WARN][3] ([fdo#107724]) -> [PASS][4] +1 
similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-icl-u3/igt@gem_mmap_...@basic-small-bo-tiledx.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14043/fi-icl-u3/igt@gem_mmap_...@basic-small-bo-tiledx.html

  * igt@kms_busy@basic-flip-a:
- fi-kbl-7567u:   [SKIP][5] ([fdo#109271] / [fdo#109278]) -> [PASS][6] 
+2 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14043/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-blb-e6850:   [INCOMPLETE][7] ([fdo#107718]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14043/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278


Participating hosts (52 -> 46)
--

  Missing(6): fi-kbl-soraka fi-byt-squawks fi-bsw-cyan fi-icl-y 
fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6714 -> Patchwork_14043

  CI-20190529: 20190529
  CI_DRM_6714: 9198974f9fa309c4c74197365844971e0940b227 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5138: b9abe0bf6c478c4f6cac56bff286d6926ad8c0ab @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_14043: a2070d35d167f5323e8cdbdf74c569ddcdc5a112 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

a2070d35d167 drm/i915: Wrappers for display register waits
6eac8d3be838 drm/i915: Introduce i915_reg_types.h
d24c490ba03f drm/i915: Dynamically allocate s0ix struct for VLV
2fd5c6189863 drm/i915: Move gmbus definitions out of i915_reg.h
54c3dc873f33 drm/i915: Move engine IDs out of i915_reg.h
683fe77978b3 drm/i915: Move i915_power_well_id out of i915_reg.h

== Logs ==

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

Re: [Intel-gfx] Linux Kernel 5.2.8 (uvc or i915?)

2019-08-15 Thread Randy Dunlap
On 8/15/19 6:15 PM, Nathaniel Russell wrote:
> I would really like help with the kernel error with my uvcvideo driver.
> 

Hi again.

What makes you think that the problem is related to the uvcvideo driver?
Does some previous kernel version work correctly?  If so, what version(s)?


Does this warning message only happen when the uvcvideo driver is being loaded?
Can you suppress loading of the uvcvideo driver to find out?

Most of the problems/errors/warnings that I see are related to the i915 driver:

[   13.032341] timed out waiting for port C ready: got 0x20, expected 0xe0
[   13.032872] WARNING: CPU: 1 PID: 239 at 
drivers/gpu/drm/i915/intel_display.c:1597 vlv_wait_port_ready+0x99/0xe0 [i915]
[   13.033632] RIP: 0010:vlv_wait_port_ready+0x99/0xe0 [i915]

although there are a few uvcvideo warnings:
[   13.039305] uvcvideo 1-5:1.0: Entity type for entity Extension 4 was not 
initialized!
[   13.039318] uvcvideo 1-5:1.0: Entity type for entity Extension 3 was not 
initialized!
[   13.039330] uvcvideo 1-5:1.0: Entity type for entity Processing 2 was not 
initialized!
[   13.039339] uvcvideo 1-5:1.0: Entity type for entity Camera 1 was not 
initialized!


Laurent, do you see any uvc issues here?  Any ideas/suggestions?


@intel-gfx:  any ideas about what is going on here with the i915 driver?



Original message to lkml:
https://lore.kernel.org/lkml/CAONH+Jm-O6=dq+k2n5pntnmg2sq1kcvnfluwevh6w82opef...@mail.gmail.com/T/#u

Previous message for 5.1.21 kernel:
https://lore.kernel.org/lkml/CAONH+JkTFujY9vEyNNuem+9rJ2qBKkf-PbKk9=DBSVEp6kW=y...@mail.gmail.com/


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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Some more display uncore prep work

2019-08-15 Thread Patchwork
== Series Details ==

Series: Some more display uncore prep work
URL   : https://patchwork.freedesktop.org/series/65281/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
683fe77978b3 drm/i915: Move i915_power_well_id out of i915_reg.h
54c3dc873f33 drm/i915: Move engine IDs out of i915_reg.h
2fd5c6189863 drm/i915: Move gmbus definitions out of i915_reg.h
d24c490ba03f drm/i915: Dynamically allocate s0ix struct for VLV
-:98: CHECK:ALLOC_SIZEOF_STRUCT: Prefer kmalloc(sizeof(*i915->s0ix_state)...) 
over kmalloc(sizeof(struct vlv_s0ix_state)...)
#98: FILE: drivers/gpu/drm/i915/i915_drv.c:537:
+   i915->s0ix_state = kmalloc(sizeof(struct vlv_s0ix_state), GFP_KERNEL);

total: 0 errors, 0 warnings, 1 checks, 256 lines checked
6eac8d3be838 drm/i915: Introduce i915_reg_types.h
-:1369: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#1369: 
new file mode 100644

-:1374: WARNING:SPDX_LICENSE_TAG: Improper SPDX comment style for 
'drivers/gpu/drm/i915/i915_reg_types.h', please use '/*' instead
#1374: FILE: drivers/gpu/drm/i915/i915_reg_types.h:1:
+// SPDX-License-Identifier: MIT

-:1374: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#1374: FILE: drivers/gpu/drm/i915/i915_reg_types.h:1:
+// SPDX-License-Identifier: MIT

-:1481: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__n' - possible 
side-effects?
#1481: FILE: drivers/gpu/drm/i915/i915_reg_types.h:108:
+#define REG_BIT(__n)   \
+   ((u32)(BIT(__n) +   \
+  BUILD_BUG_ON_ZERO(__is_constexpr(__n) && \
+((__n) < 0 || (__n) > 31

-:1495: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__high' - possible 
side-effects?
#1495: FILE: drivers/gpu/drm/i915/i915_reg_types.h:122:
+#define REG_GENMASK(__high, __low) \
+   ((u32)(GENMASK(__high, __low) + \
+  BUILD_BUG_ON_ZERO(__is_constexpr(__high) &&  \
+__is_constexpr(__low) &&   \
+((__low) < 0 || (__high) > 31 || (__low) > 
(__high)

-:1495: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__low' - possible 
side-effects?
#1495: FILE: drivers/gpu/drm/i915/i915_reg_types.h:122:
+#define REG_GENMASK(__high, __low) \
+   ((u32)(GENMASK(__high, __low) + \
+  BUILD_BUG_ON_ZERO(__is_constexpr(__high) &&  \
+__is_constexpr(__low) &&   \
+((__low) < 0 || (__high) > 31 || (__low) > 
(__high)

-:1504: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__x' - possible 
side-effects?
#1504: FILE: drivers/gpu/drm/i915/i915_reg_types.h:131:
+#define IS_POWER_OF_2(__x) ((__x) && (((__x) & ((__x) - 1)) == 0))

-:1516: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__mask' - possible 
side-effects?
#1516: FILE: drivers/gpu/drm/i915/i915_reg_types.h:143:
+#define REG_FIELD_PREP(__mask, __val)  
\
+   ((u32)typeof(__mask))(__val) << __bf_shf(__mask)) & (__mask)) + 
\
+  BUILD_BUG_ON_ZERO(!__is_constexpr(__mask)) + \
+  BUILD_BUG_ON_ZERO((__mask) == 0 || (__mask) > U32_MAX) + 
\
+  BUILD_BUG_ON_ZERO(!IS_POWER_OF_2((__mask) + (1ULL << 
__bf_shf(__mask + \
+  BUILD_BUG_ON_ZERO(__builtin_choose_expr(__is_constexpr(__val), 
(~((__mask) >> __bf_shf(__mask)) & (__val)), 0

-:1516: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__val' - possible 
side-effects?
#1516: FILE: drivers/gpu/drm/i915/i915_reg_types.h:143:
+#define REG_FIELD_PREP(__mask, __val)  
\
+   ((u32)typeof(__mask))(__val) << __bf_shf(__mask)) & (__mask)) + 
\
+  BUILD_BUG_ON_ZERO(!__is_constexpr(__mask)) + \
+  BUILD_BUG_ON_ZERO((__mask) == 0 || (__mask) > U32_MAX) + 
\
+  BUILD_BUG_ON_ZERO(!IS_POWER_OF_2((__mask) + (1ULL << 
__bf_shf(__mask + \
+  BUILD_BUG_ON_ZERO(__builtin_choose_expr(__is_constexpr(__val), 
(~((__mask) >> __bf_shf(__mask)) & (__val)), 0

-:1521: WARNING:LONG_LINE: line over 100 characters
#1521: FILE: drivers/gpu/drm/i915/i915_reg_types.h:148:
+  BUILD_BUG_ON_ZERO(__builtin_choose_expr(__is_constexpr(__val), 
(~((__mask) >> __bf_shf(__mask)) & (__val)), 0

-:1541: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__a' - possible 
side-effects?
#1541: FILE: drivers/gpu/drm/i915/i915_reg_types.h:168:
+#define _PICK_EVEN(__index, __a, __b) ((__a) + (__index) * ((__b) - (__a)))

-:1551: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'mask' - possible 
side-effects?
#1551: FILE: drivers/gpu/drm/i915/i915_reg_types.h:178:
+#define 

[Intel-gfx] [PATCH 1/6] drm/i915: Move i915_power_well_id out of i915_reg.h

2019-08-15 Thread Daniele Ceraolo Spurio
It has nothing to do with registers, so move it to the more appropriate
intel_display_power.h

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Imre Deak 
---
 .../drm/i915/display/intel_display_power.c|  1 +
 .../drm/i915/display/intel_display_power.h| 21 +++
 drivers/gpu/drm/i915/display/intel_hdcp.c |  1 +
 drivers/gpu/drm/i915/i915_reg.h   | 21 ---
 4 files changed, 23 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 374b75602141..1caae2f61216 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -13,6 +13,7 @@
 #include "intel_cdclk.h"
 #include "intel_combo_phy.h"
 #include "intel_csr.h"
+#include "intel_display_power.h"
 #include "intel_display_types.h"
 #include "intel_dpio_phy.h"
 #include "intel_hotplug.h"
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h 
b/drivers/gpu/drm/i915/display/intel_display_power.h
index 97f2562fc5d3..a50605b8b1ad 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.h
+++ b/drivers/gpu/drm/i915/display/intel_display_power.h
@@ -92,6 +92,27 @@ enum intel_display_power_domain {
POWER_DOMAIN_NUM,
 };
 
+/*
+ * i915_power_well_id:
+ *
+ * IDs used to look up power wells. Power wells accessed directly bypassing
+ * the power domains framework must be assigned a unique ID. The rest of power
+ * wells must be assigned DISP_PW_ID_NONE.
+ */
+enum i915_power_well_id {
+   DISP_PW_ID_NONE,
+
+   VLV_DISP_PW_DISP2D,
+   BXT_DISP_PW_DPIO_CMN_A,
+   VLV_DISP_PW_DPIO_CMN_BC,
+   GLK_DISP_PW_DPIO_CMN_C,
+   CHV_DISP_PW_DPIO_CMN_D,
+   HSW_DISP_PW_GLOBAL,
+   SKL_DISP_PW_MISC_IO,
+   SKL_DISP_PW_1,
+   SKL_DISP_PW_2,
+};
+
 #define POWER_DOMAIN_PIPE(pipe) ((pipe) + POWER_DOMAIN_PIPE_A)
 #define POWER_DOMAIN_PIPE_PANEL_FITTER(pipe) \
((pipe) + POWER_DOMAIN_PIPE_A_PANEL_FITTER)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index dc4aaec2e04c..0beb954b5318 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -14,6 +14,7 @@
 #include 
 
 #include "i915_reg.h"
+#include "intel_display_power.h"
 #include "intel_display_types.h"
 #include "intel_hdcp.h"
 #include "intel_sideband.h"
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2b7ccebf6550..14165d619175 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1163,27 +1163,6 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define PUNIT_REG_ISPSSPM0 0x39
 #define PUNIT_REG_ISPSSPM1 0x3a
 
-/*
- * i915_power_well_id:
- *
- * IDs used to look up power wells. Power wells accessed directly bypassing
- * the power domains framework must be assigned a unique ID. The rest of power
- * wells must be assigned DISP_PW_ID_NONE.
- */
-enum i915_power_well_id {
-   DISP_PW_ID_NONE,
-
-   VLV_DISP_PW_DISP2D,
-   BXT_DISP_PW_DPIO_CMN_A,
-   VLV_DISP_PW_DPIO_CMN_BC,
-   GLK_DISP_PW_DPIO_CMN_C,
-   CHV_DISP_PW_DPIO_CMN_D,
-   HSW_DISP_PW_GLOBAL,
-   SKL_DISP_PW_MISC_IO,
-   SKL_DISP_PW_1,
-   SKL_DISP_PW_2,
-};
-
 #define PUNIT_REG_PWRGT_CTRL   0x60
 #define PUNIT_REG_PWRGT_STATUS 0x61
 #define   PUNIT_PWRGT_MASK(pw_idx) (3 << ((pw_idx) * 2))
-- 
2.22.0

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

[Intel-gfx] [PATCH 2/6] drm/i915: Move engine IDs out of i915_reg.h

2019-08-15 Thread Daniele Ceraolo Spurio
To remove the dependency between the GT headers and i915_reg.h, move the
definition of the engine IDs/classes to intel_engine_types.h

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_engine_types.h | 20 +++
 drivers/gpu/drm/i915/gt/intel_gt_types.h |  1 +
 drivers/gpu/drm/i915/i915_reg.h  | 27 +++-
 3 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index a0f372807dd4..8f10c5ffd68d 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -26,6 +26,26 @@
 #include "intel_wakeref.h"
 #include "intel_workarounds_types.h"
 
+/* Legacy HW Engine ID */
+
+#define RCS0_HW0
+#define VCS0_HW1
+#define BCS0_HW2
+#define VECS0_HW   3
+#define VCS1_HW4
+#define VCS2_HW6
+#define VCS3_HW7
+#define VECS1_HW   12
+
+/* Gen11+ HW Engine class + instance */
+#define RENDER_CLASS   0
+#define VIDEO_DECODE_CLASS 1
+#define VIDEO_ENHANCEMENT_CLASS2
+#define COPY_ENGINE_CLASS  3
+#define OTHER_CLASS4
+#define MAX_ENGINE_CLASS   4
+#define MAX_ENGINE_INSTANCE3
+
 #define I915_MAX_SLICES3
 #define I915_MAX_SUBSLICES 8
 
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h 
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index adab4d2c29ac..81f9de45ab36 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -16,6 +16,7 @@
 #include "uc/intel_uc.h"
 
 #include "i915_vma.h"
+#include "intel_engine_types.h"
 #include "intel_reset_types.h"
 #include "intel_wakeref.h"
 
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 14165d619175..827795262d68 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -272,30 +272,6 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define _MASKED_BIT_ENABLE(a)  ({ typeof(a) _a = (a); _MASKED_FIELD(_a, _a); })
 #define _MASKED_BIT_DISABLE(a) (_MASKED_FIELD((a), 0))
 
-/* Engine ID */
-
-#define RCS0_HW0
-#define VCS0_HW1
-#define BCS0_HW2
-#define VECS0_HW   3
-#define VCS1_HW4
-#define VCS2_HW6
-#define VCS3_HW7
-#define VECS1_HW   12
-
-/* Engine class */
-
-#define RENDER_CLASS   0
-#define VIDEO_DECODE_CLASS 1
-#define VIDEO_ENHANCEMENT_CLASS2
-#define COPY_ENGINE_CLASS  3
-#define OTHER_CLASS4
-#define MAX_ENGINE_CLASS   4
-
-#define OTHER_GUC_INSTANCE 0
-#define OTHER_GTPM_INSTANCE1
-#define MAX_ENGINE_INSTANCE3
-
 /* PCI config space */
 
 #define MCHBAR_I915 0x44
@@ -7505,6 +7481,9 @@ enum {
 #define  GEN11_INTR_ENGINE_CLASS(x)(((x) & GENMASK(18, 16)) >> 16)
 #define  GEN11_INTR_ENGINE_INSTANCE(x) (((x) & GENMASK(25, 20)) >> 20)
 #define  GEN11_INTR_ENGINE_INTR(x) ((x) & 0x)
+/* irq instances for OTHER_CLASS */
+#define OTHER_GUC_INSTANCE 0
+#define OTHER_GTPM_INSTANCE1
 
 #define GEN11_INTR_IDENTITY_REG(x) _MMIO(0x190060 + ((x) * 4))
 
-- 
2.22.0

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

[Intel-gfx] [PATCH 6/6] drm/i915: Wrappers for display register waits

2019-08-15 Thread Daniele Ceraolo Spurio
To reduce the number of explicit dev_priv->uncore calls in the display
code ahead of the introduction of dev_priv->de_uncore, this patch
introduces a wrapper for one of the main usages of it, the register
waits. When we transition to the new uncore, we can just update the
wrapper to point to the appropriate structure.

Since the vast majority of waits are on a set or clear of a bit or mask,
add set & clear flavours of the wrapper to simplify the code.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Jani Nikula 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/icl_dsi.c| 11 +--
 drivers/gpu/drm/i915/display/intel_cdclk.c| 18 +
 drivers/gpu/drm/i915/display/intel_crt.c  | 17 ++--
 drivers/gpu/drm/i915/display/intel_ddi.c  |  6 +-
 drivers/gpu/drm/i915/display/intel_display.c  | 45 +++
 .../drm/i915/display/intel_display_power.c| 32 +++-
 drivers/gpu/drm/i915/display/intel_dp.c   | 10 +--
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  7 +-
 drivers/gpu/drm/i915/display/intel_dpio_phy.c |  5 +-
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 44 +++---
 drivers/gpu/drm/i915/display/intel_fbc.c  |  4 +-
 drivers/gpu/drm/i915/display/intel_hdcp.c | 32 +++-
 drivers/gpu/drm/i915/display/intel_lvds.c |  6 +-
 drivers/gpu/drm/i915/display/intel_psr.c  |  5 +-
 drivers/gpu/drm/i915/display/vlv_dsi.c| 80 ++-
 drivers/gpu/drm/i915/display/vlv_dsi_pll.c| 14 +---
 drivers/gpu/drm/i915/i915_drv.h   | 11 +++
 17 files changed, 112 insertions(+), 235 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 27b031a1774f..8e887c2a572b 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -899,10 +899,8 @@ static void gen11_dsi_enable_transcoder(struct 
intel_encoder *encoder)
I915_WRITE(PIPECONF(dsi_trans), tmp);
 
/* wait for transcoder to be enabled */
-   if (intel_wait_for_register(_priv->uncore,
-   PIPECONF(dsi_trans),
-   I965_PIPECONF_ACTIVE,
-   I965_PIPECONF_ACTIVE, 10))
+   if (intel_de_wait_for_set(dev_priv, PIPECONF(dsi_trans),
+ I965_PIPECONF_ACTIVE, 10))
DRM_ERROR("DSI transcoder not enabled\n");
}
 }
@@ -1081,9 +1079,8 @@ static void gen11_dsi_disable_transcoder(struct 
intel_encoder *encoder)
I915_WRITE(PIPECONF(dsi_trans), tmp);
 
/* wait for transcoder to be disabled */
-   if (intel_wait_for_register(_priv->uncore,
-   PIPECONF(dsi_trans),
-   I965_PIPECONF_ACTIVE, 0, 50))
+   if (intel_de_wait_for_clear(dev_priv, PIPECONF(dsi_trans),
+   I965_PIPECONF_ACTIVE, 50))
DRM_ERROR("DSI trancoder not disabled\n");
}
 }
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index a02e8404d6ec..2c38a58db4bb 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -970,9 +970,7 @@ static void skl_dpll0_enable(struct drm_i915_private 
*dev_priv, int vco)
 
I915_WRITE(LCPLL1_CTL, I915_READ(LCPLL1_CTL) | LCPLL_PLL_ENABLE);
 
-   if (intel_wait_for_register(_priv->uncore,
-   LCPLL1_CTL, LCPLL_PLL_LOCK, LCPLL_PLL_LOCK,
-   5))
+   if (intel_de_wait_for_set(dev_priv, LCPLL1_CTL, LCPLL_PLL_LOCK, 5))
DRM_ERROR("DPLL0 not locked\n");
 
dev_priv->cdclk.hw.vco = vco;
@@ -984,9 +982,7 @@ static void skl_dpll0_enable(struct drm_i915_private 
*dev_priv, int vco)
 static void skl_dpll0_disable(struct drm_i915_private *dev_priv)
 {
I915_WRITE(LCPLL1_CTL, I915_READ(LCPLL1_CTL) & ~LCPLL_PLL_ENABLE);
-   if (intel_wait_for_register(_priv->uncore,
-   LCPLL1_CTL, LCPLL_PLL_LOCK, 0,
-   1))
+   if (intel_de_wait_for_clear(dev_priv, LCPLL1_CTL, LCPLL_PLL_LOCK, 1))
DRM_ERROR("Couldn't disable DPLL0\n");
 
dev_priv->cdclk.hw.vco = 0;
@@ -1310,9 +1306,7 @@ static void bxt_de_pll_disable(struct drm_i915_private 
*dev_priv)
I915_WRITE(BXT_DE_PLL_ENABLE, 0);
 
/* Timeout 200us */
-   if (intel_wait_for_register(_priv->uncore,
-   BXT_DE_PLL_ENABLE, BXT_DE_PLL_LOCK, 0,
-   1))
+   if (intel_de_wait_for_clear(dev_priv, BXT_DE_PLL_ENABLE, 
BXT_DE_PLL_LOCK, 1))
DRM_ERROR("timeout waiting for DE PLL unlock\n");
 
dev_priv->cdclk.hw.vco = 0;
@@ -1331,11 +1325,7 @@ static void 

[Intel-gfx] [PATCH 0/6] Some more display uncore prep work

2019-08-15 Thread Daniele Ceraolo Spurio
Since we want to tag registers as belonging to display, I believe it'd
be nice to move them to a dedicated header in the display folder and
include just that in .c files, to make sure we get the split right.
The first 4 patches of the series prepare i915_drv.h for being able to
not use definition from i915_reg.h (apart from i915_reg_t) and the
include is then replaced.

The last patch adds some wrappers to hide usage dev_priv->uncore in
register waits in the display code, to make it simpler to replace it
later.

I initially wanted to send this series together with the register move,
but that is proving to be more complex than anticipated due to the mess
in i915_reg.h, so I believe it warrants its own separate series
(assuming I do manage to sort the file out in the end).

Cc: Chris Wilson 
Cc: Jani Nikula 
Cc: Ville Syrjälä 

Daniele Ceraolo Spurio (6):
  drm/i915: Move i915_power_well_id out of i915_reg.h
  drm/i915: Move engine IDs out of i915_reg.h
  drm/i915: Move gmbus definitions out of i915_reg.h
  drm/i915: Dynamically allocate s0ix struct for VLV
  drm/i915: Introduce i915_reg_types.h
  drm/i915: Wrappers for display register waits

 Documentation/gpu/i915.rst|   4 +-
 drivers/gpu/drm/i915/display/icl_dsi.c|  12 +-
 drivers/gpu/drm/i915/display/intel_atomic.c   |   1 +
 drivers/gpu/drm/i915/display/intel_audio.c|   1 +
 drivers/gpu/drm/i915/display/intel_bw.c   |   1 +
 drivers/gpu/drm/i915/display/intel_cdclk.c|  19 +-
 drivers/gpu/drm/i915/display/intel_color.c|   1 +
 .../gpu/drm/i915/display/intel_combo_phy.c|   1 +
 drivers/gpu/drm/i915/display/intel_crt.c  |  18 +-
 drivers/gpu/drm/i915/display/intel_crt.h  |   2 +-
 drivers/gpu/drm/i915/display/intel_ddi.c  |   7 +-
 drivers/gpu/drm/i915/display/intel_display.c  |  46 +--
 .../drm/i915/display/intel_display_power.c|  34 +--
 .../drm/i915/display/intel_display_power.h|  23 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |  11 +-
 drivers/gpu/drm/i915/display/intel_dp.h   |   2 +-
 .../drm/i915/display/intel_dp_link_training.c |   1 +
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |   8 +-
 drivers/gpu/drm/i915/display/intel_dpio_phy.c |   6 +-
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c |  45 +--
 drivers/gpu/drm/i915/display/intel_dsi.c  |   1 +
 drivers/gpu/drm/i915/display/intel_dsi_vbt.c  |   1 +
 drivers/gpu/drm/i915/display/intel_dvo.c  |   1 +
 drivers/gpu/drm/i915/display/intel_dvo_dev.h  |   2 +-
 drivers/gpu/drm/i915/display/intel_fbc.c  |   5 +-
 .../drm/i915/display/intel_fifo_underrun.c|   1 +
 drivers/gpu/drm/i915/display/intel_gmbus.c|   1 +
 drivers/gpu/drm/i915/display/intel_gmbus.h|  22 ++
 drivers/gpu/drm/i915/display/intel_hdcp.c |  33 +--
 drivers/gpu/drm/i915/display/intel_hdmi.c |   1 +
 drivers/gpu/drm/i915/display/intel_hdmi.h |   2 +-
 .../gpu/drm/i915/display/intel_lpe_audio.c|   1 +
 drivers/gpu/drm/i915/display/intel_lspcon.c   |   1 +
 drivers/gpu/drm/i915/display/intel_lvds.c |   7 +-
 drivers/gpu/drm/i915/display/intel_lvds.h |   2 +-
 drivers/gpu/drm/i915/display/intel_opregion.c |   1 +
 drivers/gpu/drm/i915/display/intel_panel.c|   1 +
 drivers/gpu/drm/i915/display/intel_pipe_crc.c |   1 +
 drivers/gpu/drm/i915/display/intel_psr.c  |   6 +-
 drivers/gpu/drm/i915/display/intel_sdvo.c |   1 +
 drivers/gpu/drm/i915/display/intel_sdvo.h |   2 +-
 drivers/gpu/drm/i915/display/intel_sprite.c   |   1 +
 drivers/gpu/drm/i915/display/intel_tc.c   |   1 +
 drivers/gpu/drm/i915/display/intel_tv.c   |   1 +
 drivers/gpu/drm/i915/display/intel_vdsc.c |   1 +
 drivers/gpu/drm/i915/display/vlv_dsi.c|  81 ++
 drivers/gpu/drm/i915/display/vlv_dsi_pll.c|  15 +-
 drivers/gpu/drm/i915/gem/i915_gem_context.c   |   1 +
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|   1 +
 drivers/gpu/drm/i915/gem/i915_gem_mman.c  |   1 +
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c|   1 +
 drivers/gpu/drm/i915/gem/i915_gem_tiling.c|   1 +
 .../drm/i915/gem/selftests/i915_gem_context.c |   1 +
 drivers/gpu/drm/i915/gt/intel_engine.h|   2 +-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |   1 +
 drivers/gpu/drm/i915/gt/intel_engine_types.h  |  20 ++
 drivers/gpu/drm/i915/gt/intel_gt.c|   1 +
 drivers/gpu/drm/i915/gt/intel_gt_irq.c|   1 +
 drivers/gpu/drm/i915/gt/intel_gt_types.h  |   1 +
 drivers/gpu/drm/i915/gt/intel_hangcheck.c |   1 +
 drivers/gpu/drm/i915/gt/intel_lrc.c   |   1 +
 drivers/gpu/drm/i915/gt/intel_mocs.c  |   1 +
 drivers/gpu/drm/i915/gt/intel_reset.c |   1 +
 drivers/gpu/drm/i915/gt/intel_ringbuffer.c|   1 +
 drivers/gpu/drm/i915/gt/intel_sseu.c  |   1 +
 drivers/gpu/drm/i915/gt/intel_workarounds.c   |   1 +
 .../gpu/drm/i915/gt/intel_workarounds_types.h |   2 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c |   1 +
 drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h|   2 +-
 

[Intel-gfx] [PATCH 4/6] drm/i915: Dynamically allocate s0ix struct for VLV

2019-08-15 Thread Daniele Ceraolo Spurio
This is only required for a single platform so no need to reserve the
memory on all of them.

This removes the last direct dependency of i915_drv.h on i915_reg.h
(apart from the i915_reg_t definition).

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Imre Deak 
---
 drivers/gpu/drm/i915/i915_drv.c | 107 +---
 drivers/gpu/drm/i915/i915_drv.h |  64 +--
 2 files changed, 100 insertions(+), 71 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 2541a3a1c229..1723b2ddfccd 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -80,6 +80,68 @@
 
 static struct drm_driver driver;
 
+struct vlv_s0ix_state {
+   /* GAM */
+   u32 wr_watermark;
+   u32 gfx_prio_ctrl;
+   u32 arb_mode;
+   u32 gfx_pend_tlb0;
+   u32 gfx_pend_tlb1;
+   u32 lra_limits[GEN7_LRA_LIMITS_REG_NUM];
+   u32 media_max_req_count;
+   u32 gfx_max_req_count;
+   u32 render_hwsp;
+   u32 ecochk;
+   u32 bsd_hwsp;
+   u32 blt_hwsp;
+   u32 tlb_rd_addr;
+
+   /* MBC */
+   u32 g3dctl;
+   u32 gsckgctl;
+   u32 mbctl;
+
+   /* GCP */
+   u32 ucgctl1;
+   u32 ucgctl3;
+   u32 rcgctl1;
+   u32 rcgctl2;
+   u32 rstctl;
+   u32 misccpctl;
+
+   /* GPM */
+   u32 gfxpause;
+   u32 rpdeuhwtc;
+   u32 rpdeuc;
+   u32 ecobus;
+   u32 pwrdwnupctl;
+   u32 rp_down_timeout;
+   u32 rp_deucsw;
+   u32 rcubmabdtmr;
+   u32 rcedata;
+   u32 spare2gh;
+
+   /* Display 1 CZ domain */
+   u32 gt_imr;
+   u32 gt_ier;
+   u32 pm_imr;
+   u32 pm_ier;
+   u32 gt_scratch[GEN7_GT_SCRATCH_REG_NUM];
+
+   /* GT SA CZ domain */
+   u32 tilectl;
+   u32 gt_fifoctl;
+   u32 gtlc_wake_ctrl;
+   u32 gtlc_survive;
+   u32 pmwgicz;
+
+   /* Display 2 CZ domain */
+   u32 gu_ctl0;
+   u32 gu_ctl1;
+   u32 pcbr;
+   u32 clock_gate_dis2;
+};
+
 static int i915_get_bridge_dev(struct drm_i915_private *dev_priv)
 {
int domain = pci_domain_nr(dev_priv->drm.pdev->bus);
@@ -466,6 +528,28 @@ static void intel_detect_preproduction_hw(struct 
drm_i915_private *dev_priv)
}
 }
 
+static int vlv_alloc_s0ix_state(struct drm_i915_private *i915)
+{
+   if (!IS_VALLEYVIEW(i915))
+   return 0;
+
+   /* we write all the values in the structure, so no need to zero it out 
*/
+   i915->s0ix_state = kmalloc(sizeof(struct vlv_s0ix_state), GFP_KERNEL);
+   if (!i915->s0ix_state)
+   return -ENOMEM;
+
+   return 0;
+}
+
+static void vlv_free_s0ix_state(struct drm_i915_private *i915)
+{
+   if (!i915->s0ix_state)
+   return;
+
+   kfree(i915->s0ix_state);
+   i915->s0ix_state = NULL;
+}
+
 /**
  * i915_driver_early_probe - setup state not requiring device access
  * @dev_priv: device private
@@ -508,13 +592,17 @@ static int i915_driver_early_probe(struct 
drm_i915_private *dev_priv)
if (ret < 0)
return ret;
 
+   ret = vlv_alloc_s0ix_state(dev_priv);
+   if (ret < 0)
+   goto err_workqueues;
+
intel_wopcm_init_early(_priv->wopcm);
 
intel_gt_init_early(_priv->gt, dev_priv);
 
ret = i915_gem_init_early(dev_priv);
if (ret < 0)
-   goto err_workqueues;
+   goto err_gt;
 
/* This must be called before any calls to HAS_PCH_* */
intel_detect_pch(dev_priv);
@@ -536,8 +624,10 @@ static int i915_driver_early_probe(struct drm_i915_private 
*dev_priv)
 
 err_gem:
i915_gem_cleanup_early(dev_priv);
-err_workqueues:
+err_gt:
intel_gt_driver_late_release(_priv->gt);
+   vlv_free_s0ix_state(dev_priv);
+err_workqueues:
i915_workqueues_cleanup(dev_priv);
return ret;
 }
@@ -553,6 +643,7 @@ static void i915_driver_late_release(struct 
drm_i915_private *dev_priv)
intel_power_domains_cleanup(dev_priv);
i915_gem_cleanup_early(dev_priv);
intel_gt_driver_late_release(_priv->gt);
+   vlv_free_s0ix_state(dev_priv);
i915_workqueues_cleanup(dev_priv);
 
pm_qos_remove_request(_priv->sb_qos);
@@ -2137,7 +2228,7 @@ static int i915_pm_restore(struct device *kdev)
  */
 static void vlv_save_gunit_s0ix_state(struct drm_i915_private *dev_priv)
 {
-   struct vlv_s0ix_state *s = _priv->vlv_s0ix_state;
+   struct vlv_s0ix_state *s = dev_priv->s0ix_state;
int i;
 
/* GAM 0x4000-0x4770 */
@@ -2147,7 +2238,7 @@ static void vlv_save_gunit_s0ix_state(struct 
drm_i915_private *dev_priv)
s->gfx_pend_tlb0= I915_READ(GEN7_GFX_PEND_TLB0);
s->gfx_pend_tlb1= I915_READ(GEN7_GFX_PEND_TLB1);
 
-   for (i = 0; i < ARRAY_SIZE(s->lra_limits); i++)
+   for (i = 0; i < GEN7_LRA_LIMITS_REG_NUM; i++)
s->lra_limits[i] = I915_READ(GEN7_LRA_LIMITS(i));
 
s->media_max_req_count  = 

[Intel-gfx] [PATCH 3/6] drm/i915: Move gmbus definitions out of i915_reg.h

2019-08-15 Thread Daniele Ceraolo Spurio
They're not related to registers, so move them to the more appropriate
intel_gmbus.h

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_gmbus.h | 22 ++
 drivers/gpu/drm/i915/i915_drv.h|  1 +
 drivers/gpu/drm/i915/i915_reg.h| 22 +-
 3 files changed, 24 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.h 
b/drivers/gpu/drm/i915/display/intel_gmbus.h
index d989085b8d22..b96212b85425 100644
--- a/drivers/gpu/drm/i915/display/intel_gmbus.h
+++ b/drivers/gpu/drm/i915/display/intel_gmbus.h
@@ -11,6 +11,28 @@
 struct drm_i915_private;
 struct i2c_adapter;
 
+#define GMBUS_PIN_DISABLED 0
+#define GMBUS_PIN_SSC  1
+#define GMBUS_PIN_VGADDC   2
+#define GMBUS_PIN_PANEL3
+#define GMBUS_PIN_DPD_CHV  3 /* HDMID_CHV */
+#define GMBUS_PIN_DPC  4 /* HDMIC */
+#define GMBUS_PIN_DPB  5 /* SDVO, HDMIB */
+#define GMBUS_PIN_DPD  6 /* HDMID */
+#define GMBUS_PIN_RESERVED 7 /* 7 reserved */
+#define GMBUS_PIN_1_BXT1 /* BXT+ (atom) and CNP+ (big core) */
+#define GMBUS_PIN_2_BXT2
+#define GMBUS_PIN_3_BXT3
+#define GMBUS_PIN_4_CNP4
+#define GMBUS_PIN_9_TC1_ICP9
+#define GMBUS_PIN_10_TC2_ICP   10
+#define GMBUS_PIN_11_TC3_ICP   11
+#define GMBUS_PIN_12_TC4_ICP   12
+#define GMBUS_PIN_13_TC5_TGP   13
+#define GMBUS_PIN_14_TC6_TGP   14
+
+#define GMBUS_NUM_PINS 15 /* including 0 */
+
 int intel_gmbus_setup(struct drm_i915_private *dev_priv);
 void intel_gmbus_teardown(struct drm_i915_private *dev_priv);
 bool intel_gmbus_is_valid_pin(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c4406a60f3e4..c6722d54ccd5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -68,6 +68,7 @@
 #include "display/intel_display_power.h"
 #include "display/intel_dpll_mgr.h"
 #include "display/intel_frontbuffer.h"
+#include "display/intel_gmbus.h"
 #include "display/intel_opregion.h"
 
 #include "gem/i915_gem_context_types.h"
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 827795262d68..ea2f0fa2402d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3207,27 +3207,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define   GMBUS_RATE_1MHZ  (3 << 8) /* reserved on Pineview */
 #define   GMBUS_HOLD_EXT   (1 << 7) /* 300ns hold time, rsvd on Pineview */
 #define   GMBUS_BYTE_CNT_OVERRIDE (1 << 6)
-#define   GMBUS_PIN_DISABLED   0
-#define   GMBUS_PIN_SSC1
-#define   GMBUS_PIN_VGADDC 2
-#define   GMBUS_PIN_PANEL  3
-#define   GMBUS_PIN_DPD_CHV3 /* HDMID_CHV */
-#define   GMBUS_PIN_DPC4 /* HDMIC */
-#define   GMBUS_PIN_DPB5 /* SDVO, HDMIB */
-#define   GMBUS_PIN_DPD6 /* HDMID */
-#define   GMBUS_PIN_RESERVED   7 /* 7 reserved */
-#define   GMBUS_PIN_1_BXT  1 /* BXT+ (atom) and CNP+ (big core) */
-#define   GMBUS_PIN_2_BXT  2
-#define   GMBUS_PIN_3_BXT  3
-#define   GMBUS_PIN_4_CNP  4
-#define   GMBUS_PIN_9_TC1_ICP  9
-#define   GMBUS_PIN_10_TC2_ICP 10
-#define   GMBUS_PIN_11_TC3_ICP 11
-#define   GMBUS_PIN_12_TC4_ICP 12
-#define   GMBUS_PIN_13_TC5_TGP 13
-#define   GMBUS_PIN_14_TC6_TGP 14
-
-#define   GMBUS_NUM_PINS   15 /* including 0 */
+
 #define GMBUS1 _MMIO(dev_priv->gpio_mmio_base + 0x5104) /* 
command/status */
 #define   GMBUS_SW_CLR_INT (1 << 31)
 #define   GMBUS_SW_RDY (1 << 30)
-- 
2.22.0

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

[Intel-gfx] [PATCH 5/6] drm/i915: Introduce i915_reg_types.h

2019-08-15 Thread Daniele Ceraolo Spurio
With the introduction of display uncore, we want to categorize registers
between display and non-display. To help us getting it right, it will
be useful to move the display registers to a new file that can be used
without including i915_reg.h. To allow that, move all the basic register
type definitions and helpers to i915_reg_types.h and include that
instead of i915_reg.h from header files in the driver. We'll then
be able to replace i915_reg.h with the new display-only header in
display files and make sure the registers are correctly
compartmentalized.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Jani Nikula 
Cc: Chris Wilson 
---
 Documentation/gpu/i915.rst|   4 +-
 drivers/gpu/drm/i915/display/icl_dsi.c|   1 +
 drivers/gpu/drm/i915/display/intel_atomic.c   |   1 +
 drivers/gpu/drm/i915/display/intel_audio.c|   1 +
 drivers/gpu/drm/i915/display/intel_bw.c   |   1 +
 drivers/gpu/drm/i915/display/intel_cdclk.c|   1 +
 drivers/gpu/drm/i915/display/intel_color.c|   1 +
 .../gpu/drm/i915/display/intel_combo_phy.c|   1 +
 drivers/gpu/drm/i915/display/intel_crt.c  |   1 +
 drivers/gpu/drm/i915/display/intel_crt.h  |   2 +-
 drivers/gpu/drm/i915/display/intel_ddi.c  |   1 +
 drivers/gpu/drm/i915/display/intel_display.c  |   1 +
 .../drm/i915/display/intel_display_power.c|   1 +
 .../drm/i915/display/intel_display_power.h|   2 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |   1 +
 drivers/gpu/drm/i915/display/intel_dp.h   |   2 +-
 .../drm/i915/display/intel_dp_link_training.c |   1 +
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |   1 +
 drivers/gpu/drm/i915/display/intel_dpio_phy.c |   1 +
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c |   1 +
 drivers/gpu/drm/i915/display/intel_dsi.c  |   1 +
 drivers/gpu/drm/i915/display/intel_dsi_vbt.c  |   1 +
 drivers/gpu/drm/i915/display/intel_dvo.c  |   1 +
 drivers/gpu/drm/i915/display/intel_dvo_dev.h  |   2 +-
 drivers/gpu/drm/i915/display/intel_fbc.c  |   1 +
 .../drm/i915/display/intel_fifo_underrun.c|   1 +
 drivers/gpu/drm/i915/display/intel_gmbus.c|   1 +
 drivers/gpu/drm/i915/display/intel_hdmi.c |   1 +
 drivers/gpu/drm/i915/display/intel_hdmi.h |   2 +-
 .../gpu/drm/i915/display/intel_lpe_audio.c|   1 +
 drivers/gpu/drm/i915/display/intel_lspcon.c   |   1 +
 drivers/gpu/drm/i915/display/intel_lvds.c |   1 +
 drivers/gpu/drm/i915/display/intel_lvds.h |   2 +-
 drivers/gpu/drm/i915/display/intel_opregion.c |   1 +
 drivers/gpu/drm/i915/display/intel_panel.c|   1 +
 drivers/gpu/drm/i915/display/intel_pipe_crc.c |   1 +
 drivers/gpu/drm/i915/display/intel_psr.c  |   1 +
 drivers/gpu/drm/i915/display/intel_sdvo.c |   1 +
 drivers/gpu/drm/i915/display/intel_sdvo.h |   2 +-
 drivers/gpu/drm/i915/display/intel_sprite.c   |   1 +
 drivers/gpu/drm/i915/display/intel_tc.c   |   1 +
 drivers/gpu/drm/i915/display/intel_tv.c   |   1 +
 drivers/gpu/drm/i915/display/intel_vdsc.c |   1 +
 drivers/gpu/drm/i915/display/vlv_dsi.c|   1 +
 drivers/gpu/drm/i915/display/vlv_dsi_pll.c|   1 +
 drivers/gpu/drm/i915/gem/i915_gem_context.c   |   1 +
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|   1 +
 drivers/gpu/drm/i915/gem/i915_gem_mman.c  |   1 +
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c|   1 +
 drivers/gpu/drm/i915/gem/i915_gem_tiling.c|   1 +
 .../drm/i915/gem/selftests/i915_gem_context.c |   1 +
 drivers/gpu/drm/i915/gt/intel_engine.h|   2 +-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |   1 +
 drivers/gpu/drm/i915/gt/intel_gt.c|   1 +
 drivers/gpu/drm/i915/gt/intel_gt_irq.c|   1 +
 drivers/gpu/drm/i915/gt/intel_hangcheck.c |   1 +
 drivers/gpu/drm/i915/gt/intel_lrc.c   |   1 +
 drivers/gpu/drm/i915/gt/intel_mocs.c  |   1 +
 drivers/gpu/drm/i915/gt/intel_reset.c |   1 +
 drivers/gpu/drm/i915/gt/intel_ringbuffer.c|   1 +
 drivers/gpu/drm/i915/gt/intel_sseu.c  |   1 +
 drivers/gpu/drm/i915/gt/intel_workarounds.c   |   1 +
 .../gpu/drm/i915/gt/intel_workarounds_types.h |   2 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c |   1 +
 drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h|   2 +-
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c |   1 +
 drivers/gpu/drm/i915/gt/uc/intel_huc.h|   2 +-
 drivers/gpu/drm/i915/gvt/aperture_gm.c|   1 +
 drivers/gpu/drm/i915/gvt/cmd_parser.c |   1 +
 drivers/gpu/drm/i915/gvt/display.c|   1 +
 drivers/gpu/drm/i915/gvt/dmabuf.c |   1 +
 drivers/gpu/drm/i915/gvt/edid.c   |   1 +
 drivers/gpu/drm/i915/gvt/fb_decoder.c |   1 +
 drivers/gpu/drm/i915/gvt/gtt.c|   1 +
 drivers/gpu/drm/i915/gvt/handlers.c   |   1 +
 drivers/gpu/drm/i915/gvt/interrupt.c  |   1 +
 drivers/gpu/drm/i915/gvt/mmio.c   |   1 +
 drivers/gpu/drm/i915/gvt/mmio_context.c   |   1 +
 drivers/gpu/drm/i915/gvt/scheduler.c  |   1 +
 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/uc: Add explicit DISABLED state for firmware

2019-08-15 Thread Patchwork
== Series Details ==

Series: drm/i915/uc: Add explicit DISABLED state for firmware
URL   : https://patchwork.freedesktop.org/series/65278/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6714 -> Patchwork_14042


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_14042 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_14042, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14042/

Known issues


  Here are the changes found in Patchwork_14042 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850:   [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14042/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html

  * igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: [PASS][3] -> [DMESG-WARN][4] ([fdo#106387])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-ilk-650/igt@prime_v...@basic-fence-flip.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14042/fi-ilk-650/igt@prime_v...@basic-fence-flip.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#106387]: https://bugs.freedesktop.org/show_bug.cgi?id=106387
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718


Participating hosts (52 -> 23)
--

  ERROR: It appears as if the changes made in Patchwork_14042 prevented too 
many machines from booting.

  Missing(29): fi-kbl-soraka fi-skl-6770hq fi-icl-u2 fi-skl-6260u 
fi-bxt-j4205 fi-icl-u3 fi-icl-y fi-skl-lmem fi-icl-dsi fi-skl-6600u fi-cml-u 
fi-cml-u2 fi-icl-u4 fi-bxt-dsi fi-glk-dsi fi-skl-6700k2 fi-kbl-r fi-kbl-7567u 
fi-skl-gvtdvm fi-cfl-8700k fi-byt-squawks fi-bsw-cyan fi-whl-u fi-kbl-x1275 
fi-cfl-8109u fi-skl-iommu fi-kbl-8809g fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6714 -> Patchwork_14042

  CI-20190529: 20190529
  CI_DRM_6714: 9198974f9fa309c4c74197365844971e0940b227 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5138: b9abe0bf6c478c4f6cac56bff286d6926ad8c0ab @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_14042: 2129de239b7fd2c44691a754e78c289fbca39af8 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

2129de239b7f drm/i915/uc: Add explicit DISABLED state for firmware

== Logs ==

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

Re: [Intel-gfx] [PATCH 2/5] drm/i915/wopcm: Check WOPCM layout separately from calculations

2019-08-15 Thread Daniele Ceraolo Spurio



On 8/15/19 5:21 PM, Michal Wajdeczko wrote:
On Fri, 16 Aug 2019 02:10:26 +0200, Daniele Ceraolo Spurio 
 wrote:





On 8/15/19 2:48 PM, Michal Wajdeczko wrote:

We can do WOPCM partitioning using rough estimates and limits
and perform detailed check as separate step.
 v2: oops! s/max/min
 Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
---
  drivers/gpu/drm/i915/intel_wopcm.c | 105 -
  1 file changed, 74 insertions(+), 31 deletions(-)
 diff --git a/drivers/gpu/drm/i915/intel_wopcm.c 
b/drivers/gpu/drm/i915/intel_wopcm.c

index 2975e00f57f5..39f2764ca3a8 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -87,7 +87,8 @@ void intel_wopcm_init_early(struct intel_wopcm *wopcm)
  else
  wopcm->size = GEN9_WOPCM_SIZE;
  -    DRM_DEBUG_DRIVER("WOPCM size: %uKiB\n", wopcm->size / 1024);
+    DRM_DEV_DEBUG_DRIVER(i915->drm.dev, "WOPCM: size %uKiB\n",
+ wopcm->size / SZ_1K);
  }
    static inline u32 context_reserved_size(struct drm_i915_private 
*i915)
@@ -138,9 +139,9 @@ static inline int gen9_check_huc_fw_fits(u32 
guc_wopcm_size, u32 huc_fw_size)

  return 0;
  }
  -static inline int check_hw_restriction(struct drm_i915_private *i915,
-   u32 guc_wopcm_base, u32 guc_wopcm_size,
-   u32 huc_fw_size)
+static inline bool check_hw_restrictions(struct drm_i915_private *i915,
+ u32 guc_wopcm_base, u32 guc_wopcm_size,
+ u32 huc_fw_size)
  {
  int err = 0;
  @@ -151,7 +152,64 @@ static inline int check_hw_restriction(struct 
drm_i915_private *i915,
  (IS_GEN(i915, 9) || IS_CNL_REVID(i915, CNL_REVID_A0, 
CNL_REVID_A0)))

  err = gen9_check_huc_fw_fits(guc_wopcm_size, huc_fw_size);
  -    return err;
+    return !err;
+}
+
+static inline bool __check_layout(struct drm_i915_private *i915, u32 
wopcm_size,

+  u32 guc_wopcm_base, u32 guc_wopcm_size,
+  u32 guc_fw_size, u32 huc_fw_size)
+{
+    const u32 ctx_rsvd = context_reserved_size(i915);
+    u32 size;
+
+    if (unlikely(guc_wopcm_base > wopcm_size)) {
+    dev_err(i915->drm.dev,
+    "WOPCM: invalid GuC region base: %uK > %uK\n",
+    guc_wopcm_base / SZ_1K, wopcm_size / SZ_1K);
+    return false;
+    }
+
+    size = wopcm_size - ctx_rsvd;
+    if (unlikely(guc_wopcm_base > size)) {
+    dev_err(i915->drm.dev,
+    "WOPCM: invalid GuC region base: %uK > %uK\n",
+    guc_wopcm_base / SZ_1K, size / SZ_1K);
+    return false;
+    }
+
+    if (unlikely(guc_wopcm_size > wopcm_size)) {
+    dev_err(i915->drm.dev,
+    "WOPCM: invalid GuC region size: %uK > %uK\n",
+    guc_wopcm_size / SZ_1K, wopcm_size / SZ_1K);
+    return false;
+    }
+
+    size = wopcm_size - guc_wopcm_base - ctx_rsvd;
+    if (unlikely(guc_wopcm_size > size)) {
+    dev_err(i915->drm.dev,
+    "WOPCM: invalid GuC region size: %uK > %uK\n",
+    guc_wopcm_size / SZ_1K, size / SZ_1K);
+    return false;
+    }



I think we can consolidate all the checks above in just:

wopcm_guc_max = wopcm_size - ctx_rsvd;
if (range_overflows(guc_wopcm_base, guc_wopcm_size, wopcm_guc_max)
    return false;


if we consolidate, then it will be hard to tell what went wrong.
with separate logs we can find which check failed (they all are
unlikely, but still possible)



As long as we print guc_wopcm_base, guc_wopcm_size and wopcm_guc_max on 
error we should be able to easily see what's going wrong, it's easy to 
see if guc_wopcm_base or guc_wopcm_size are greater than wopcm_guc_max, 
which covers 3 of the 4 checks above.






+
+    size = guc_fw_size + GUC_WOPCM_RESERVED + GUC_WOPCM_STACK_RESERVED;
+    if (unlikely(guc_wopcm_size < size)) {
+    dev_err(i915->drm.dev, "WOPCM: no space for %s: %uK < %uK\n",
+    intel_uc_fw_type_repr(INTEL_UC_FW_TYPE_GUC),
+    guc_wopcm_size / SZ_1K, size / SZ_1K);
+    return false;
+    }
+
+    size = huc_fw_size + WOPCM_RESERVED_SIZE;
+    if (unlikely(guc_wopcm_base < size)) {
+    dev_err(i915->drm.dev, "WOPCM: no space for %s: %uK < %uK\n",
+    intel_uc_fw_type_repr(INTEL_UC_FW_TYPE_HUC),
+    guc_wopcm_base / SZ_1K, size / SZ_1K);
+    return false;
+    }
+
+    return check_hw_restrictions(i915, guc_wopcm_base, guc_wopcm_size,
+ huc_fw_size);
  }
    /**
@@ -172,8 +230,6 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
  u32 ctx_rsvd = context_reserved_size(i915);
  u32 guc_wopcm_base;
  u32 guc_wopcm_size;
-    u32 guc_wopcm_rsvd;
-    int err;
    if (!guc_fw_size)
  return;
@@ -183,39 +239,26 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
  GEM_BUG_ON(wopcm->guc.size);
  GEM_BUG_ON(guc_fw_size >= wopcm->size);
  GEM_BUG_ON(huc_fw_size >= wopcm->size);
+    GEM_BUG_ON(ctx_rsvd + 

Re: [Intel-gfx] [PATCH 2/5] drm/i915/wopcm: Check WOPCM layout separately from calculations

2019-08-15 Thread Michal Wajdeczko
On Fri, 16 Aug 2019 02:10:26 +0200, Daniele Ceraolo Spurio  
 wrote:





On 8/15/19 2:48 PM, Michal Wajdeczko wrote:

We can do WOPCM partitioning using rough estimates and limits
and perform detailed check as separate step.
 v2: oops! s/max/min
 Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
---
  drivers/gpu/drm/i915/intel_wopcm.c | 105 -
  1 file changed, 74 insertions(+), 31 deletions(-)
 diff --git a/drivers/gpu/drm/i915/intel_wopcm.c  
b/drivers/gpu/drm/i915/intel_wopcm.c

index 2975e00f57f5..39f2764ca3a8 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -87,7 +87,8 @@ void intel_wopcm_init_early(struct intel_wopcm *wopcm)
else
wopcm->size = GEN9_WOPCM_SIZE;
  - DRM_DEBUG_DRIVER("WOPCM size: %uKiB\n", wopcm->size / 1024);
+   DRM_DEV_DEBUG_DRIVER(i915->drm.dev, "WOPCM: size %uKiB\n",
+wopcm->size / SZ_1K);
  }
static inline u32 context_reserved_size(struct drm_i915_private  
*i915)
@@ -138,9 +139,9 @@ static inline int gen9_check_huc_fw_fits(u32  
guc_wopcm_size, u32 huc_fw_size)

return 0;
  }
  -static inline int check_hw_restriction(struct drm_i915_private *i915,
-  u32 guc_wopcm_base, u32 guc_wopcm_size,
-  u32 huc_fw_size)
+static inline bool check_hw_restrictions(struct drm_i915_private *i915,
+u32 guc_wopcm_base, u32 guc_wopcm_size,
+u32 huc_fw_size)
  {
int err = 0;
  @@ -151,7 +152,64 @@ static inline int check_hw_restriction(struct  
drm_i915_private *i915,
  	(IS_GEN(i915, 9) || IS_CNL_REVID(i915, CNL_REVID_A0,  
CNL_REVID_A0)))

err = gen9_check_huc_fw_fits(guc_wopcm_size, huc_fw_size);
  - return err;
+   return !err;
+}
+
+static inline bool __check_layout(struct drm_i915_private *i915, u32  
wopcm_size,

+ u32 guc_wopcm_base, u32 guc_wopcm_size,
+ u32 guc_fw_size, u32 huc_fw_size)
+{
+   const u32 ctx_rsvd = context_reserved_size(i915);
+   u32 size;
+
+   if (unlikely(guc_wopcm_base > wopcm_size)) {
+   dev_err(i915->drm.dev,
+   "WOPCM: invalid GuC region base: %uK > %uK\n",
+   guc_wopcm_base / SZ_1K, wopcm_size / SZ_1K);
+   return false;
+   }
+
+   size = wopcm_size - ctx_rsvd;
+   if (unlikely(guc_wopcm_base > size)) {
+   dev_err(i915->drm.dev,
+   "WOPCM: invalid GuC region base: %uK > %uK\n",
+   guc_wopcm_base / SZ_1K, size / SZ_1K);
+   return false;
+   }
+
+   if (unlikely(guc_wopcm_size > wopcm_size)) {
+   dev_err(i915->drm.dev,
+   "WOPCM: invalid GuC region size: %uK > %uK\n",
+   guc_wopcm_size / SZ_1K, wopcm_size / SZ_1K);
+   return false;
+   }
+
+   size = wopcm_size - guc_wopcm_base - ctx_rsvd;
+   if (unlikely(guc_wopcm_size > size)) {
+   dev_err(i915->drm.dev,
+   "WOPCM: invalid GuC region size: %uK > %uK\n",
+   guc_wopcm_size / SZ_1K, size / SZ_1K);
+   return false;
+   }



I think we can consolidate all the checks above in just:

wopcm_guc_max = wopcm_size - ctx_rsvd;
if (range_overflows(guc_wopcm_base, guc_wopcm_size, wopcm_guc_max)
return false;


if we consolidate, then it will be hard to tell what went wrong.
with separate logs we can find which check failed (they all are
unlikely, but still possible)





+
+   size = guc_fw_size + GUC_WOPCM_RESERVED + GUC_WOPCM_STACK_RESERVED;
+   if (unlikely(guc_wopcm_size < size)) {
+   dev_err(i915->drm.dev, "WOPCM: no space for %s: %uK < %uK\n",
+   intel_uc_fw_type_repr(INTEL_UC_FW_TYPE_GUC),
+   guc_wopcm_size / SZ_1K, size / SZ_1K);
+   return false;
+   }
+
+   size = huc_fw_size + WOPCM_RESERVED_SIZE;
+   if (unlikely(guc_wopcm_base < size)) {
+   dev_err(i915->drm.dev, "WOPCM: no space for %s: %uK < %uK\n",
+   intel_uc_fw_type_repr(INTEL_UC_FW_TYPE_HUC),
+   guc_wopcm_base / SZ_1K, size / SZ_1K);
+   return false;
+   }
+
+   return check_hw_restrictions(i915, guc_wopcm_base, guc_wopcm_size,
+huc_fw_size);
  }
/**
@@ -172,8 +230,6 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
u32 ctx_rsvd = context_reserved_size(i915);
u32 guc_wopcm_base;
u32 guc_wopcm_size;
-   u32 guc_wopcm_rsvd;
-   int err;
if (!guc_fw_size)
return;
@@ -183,39 +239,26 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gen11: Allow usage of all GPIO pins (rev2)

2019-08-15 Thread Patchwork
== Series Details ==

Series: drm/i915/gen11: Allow usage of all GPIO pins (rev2)
URL   : https://patchwork.freedesktop.org/series/65261/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6714 -> Patchwork_14041


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_14041 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_14041, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14041/

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_14041:

### IGT changes ###

 Possible regressions 

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-skl-6700k2:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-skl-6700k2/igt@kms_chamel...@common-hpd-after-suspend.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14041/fi-skl-6700k2/igt@kms_chamel...@common-hpd-after-suspend.html

  
 Warnings 

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-skl-6700k2:  [FAIL][3] ([fdo#111407]) -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-skl-6700k2/igt@kms_chamel...@hdmi-hpd-fast.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14041/fi-skl-6700k2/igt@kms_chamel...@hdmi-hpd-fast.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@kms_chamelium@dp-hpd-fast:
- {fi-icl-u4}:[FAIL][5] ([fdo#111045]) -> [FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-icl-u4/igt@kms_chamel...@dp-hpd-fast.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14041/fi-icl-u4/igt@kms_chamel...@dp-hpd-fast.html

  
Known issues


  Here are the changes found in Patchwork_14041 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_reloc@basic-gtt:
- fi-icl-u3:  [PASS][7] -> [DMESG-WARN][8] ([fdo#107724])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-icl-u3/igt@gem_exec_re...@basic-gtt.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14041/fi-icl-u3/igt@gem_exec_re...@basic-gtt.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6260u:   [PASS][9] -> [INCOMPLETE][10] ([fdo#107807])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-skl-6260u/igt@i915_pm_...@module-reload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14041/fi-skl-6260u/igt@i915_pm_...@module-reload.html

  * igt@kms_busy@basic-flip-a:
- fi-skl-iommu:   [PASS][11] -> [SKIP][12] ([fdo#109271] / 
[fdo#109278]) +2 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-skl-iommu/igt@kms_b...@basic-flip-a.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14041/fi-skl-iommu/igt@kms_b...@basic-flip-a.html
- fi-skl-6260u:   [PASS][13] -> [SKIP][14] ([fdo#109271] / 
[fdo#109278]) +2 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-skl-6260u/igt@kms_b...@basic-flip-a.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14041/fi-skl-6260u/igt@kms_b...@basic-flip-a.html
- fi-bdw-gvtdvm:  [PASS][15] -> [SKIP][16] ([fdo#109271] / 
[fdo#109278]) +2 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-bdw-gvtdvm/igt@kms_b...@basic-flip-a.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14041/fi-bdw-gvtdvm/igt@kms_b...@basic-flip-a.html

  * igt@kms_busy@basic-flip-b:
- fi-bdw-5557u:   [PASS][17] -> [SKIP][18] ([fdo#109271] / 
[fdo#109278]) +2 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-bdw-5557u/igt@kms_b...@basic-flip-b.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14041/fi-bdw-5557u/igt@kms_b...@basic-flip-b.html
- fi-skl-gvtdvm:  [PASS][19] -> [SKIP][20] ([fdo#109271] / 
[fdo#109278]) +2 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-skl-gvtdvm/igt@kms_b...@basic-flip-b.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14041/fi-skl-gvtdvm/igt@kms_b...@basic-flip-b.html
- fi-cfl-guc: [PASS][21] -> [SKIP][22] ([fdo#109271] / 
[fdo#109278]) +2 similar issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-cfl-guc/igt@kms_b...@basic-flip-b.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14041/fi-cfl-guc/igt@kms_b...@basic-flip-b.html
- fi-cfl-8700k:   [PASS][23] -> [SKIP][24] ([fdo#109271] / 
[fdo#109278]) +2 similar issues
   [23]: 

Re: [Intel-gfx] [PATCH 3/5] drm/i915/wopcm: Try to use already locked WOPCM layout

2019-08-15 Thread Daniele Ceraolo Spurio



On 8/15/19 10:12 AM, Michal Wajdeczko wrote:

If WOPCM layout is already locked in HW we shouldn't continue
with our own partitioning as it could be likely different and
we will be unable to enforce it and fail. Instead we should try
to reuse what is already programmed, maybe there will be a fit.

This should enable us to reload driver with slightly different
HuC firmware (or even without HuC) without need to reboot.

v2: reordered/rebased

Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
Cc: Michal Winiarski 


Reviewed-by: Daniele Ceraolo Spurio 

Daniele


---
  drivers/gpu/drm/i915/intel_wopcm.c | 29 +++--
  1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_wopcm.c 
b/drivers/gpu/drm/i915/intel_wopcm.c
index 3ac05055bb08..ea02efb653a7 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -212,6 +212,21 @@ static inline bool __check_layout(struct drm_i915_private 
*i915, u32 wopcm_size,
 huc_fw_size);
  }
  
+static bool __wopcm_regs_locked(struct intel_uncore *uncore,

+   u32 *guc_wopcm_base, u32 *guc_wopcm_size)
+{
+   u32 reg_base = intel_uncore_read(uncore, DMA_GUC_WOPCM_OFFSET);
+   u32 reg_size = intel_uncore_read(uncore, GUC_WOPCM_SIZE);
+
+   if (!(reg_size & GUC_WOPCM_SIZE_LOCKED) ||
+   !(reg_base & GUC_WOPCM_OFFSET_VALID))
+   return false;
+
+   *guc_wopcm_base = reg_base & GUC_WOPCM_OFFSET_MASK;
+   *guc_wopcm_size = reg_size & GUC_WOPCM_SIZE_MASK;
+   return true;
+}
+
  /**
   * intel_wopcm_init() - Initialize the WOPCM structure.
   * @wopcm: pointer to intel_wopcm.
@@ -225,8 +240,9 @@ static inline bool __check_layout(struct drm_i915_private 
*i915, u32 wopcm_size,
  void intel_wopcm_init(struct intel_wopcm *wopcm)
  {
struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
-   u32 guc_fw_size = intel_uc_fw_get_upload_size(>gt.uc.guc.fw);
-   u32 huc_fw_size = intel_uc_fw_get_upload_size(>gt.uc.huc.fw);
+   struct intel_gt *gt = >gt;
+   u32 guc_fw_size = intel_uc_fw_get_upload_size(>uc.guc.fw);
+   u32 huc_fw_size = intel_uc_fw_get_upload_size(>uc.huc.fw);
u32 ctx_rsvd = context_reserved_size(i915);
u32 guc_wopcm_base;
u32 guc_wopcm_size;
@@ -244,6 +260,14 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
if (i915_inject_probe_failure(i915))
return;
  
+	if (__wopcm_regs_locked(gt->uncore, _wopcm_base, _wopcm_size)) {

+   DRM_DEV_DEBUG_DRIVER(i915->drm.dev,
+"GuC WOPCM is already locked [%uK, %uK)\n",
+guc_wopcm_base / SZ_1K,
+guc_wopcm_size / SZ_1K);
+   goto check;
+   }
+
guc_wopcm_base = ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
   GUC_WOPCM_OFFSET_ALIGNMENT);
guc_wopcm_base = max(wopcm->size - ctx_rsvd, guc_wopcm_base);
@@ -254,6 +278,7 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
 "Calculated GuC WOPCM Region: [%uKiB, %uKiB)\n",
 guc_wopcm_base / SZ_1K, guc_wopcm_size / SZ_1K);
  
+check:

if (__check_layout(i915, wopcm->size, guc_wopcm_base, guc_wopcm_size,
   guc_fw_size, huc_fw_size)) {
wopcm->guc.base = guc_wopcm_base;


___
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: Convert a few more bland dmesg info to be device specific

2019-08-15 Thread Patchwork
== Series Details ==

Series: drm/i915: Convert a few more bland dmesg info to be device specific
URL   : https://patchwork.freedesktop.org/series/65253/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6711_full -> Patchwork_14027_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_14027_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_schedule@fifo-bsd1:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276]) +13 similar 
issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb4/igt@gem_exec_sched...@fifo-bsd1.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14027/shard-iclb6/igt@gem_exec_sched...@fifo-bsd1.html

  * igt@gem_exec_schedule@preempt-other-chain-bsd:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +3 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb5/igt@gem_exec_sched...@preempt-other-chain-bsd.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14027/shard-iclb2/igt@gem_exec_sched...@preempt-other-chain-bsd.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
- shard-skl:  [PASS][5] -> [INCOMPLETE][6] ([fdo#109507])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-skl9/igt@kms_f...@flip-vs-suspend-interruptible.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14027/shard-skl3/igt@kms_f...@flip-vs-suspend-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-pwrite:
- shard-snb:  [PASS][7] -> [SKIP][8] ([fdo#109271])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-snb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-pwrite.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14027/shard-snb4/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-pwrite.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite:
- shard-iclb: [PASS][9] -> [FAIL][10] ([fdo#103167]) +5 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-pwrite.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14027/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-pwrite.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-apl:  [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +2 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-apl5/igt@kms_frontbuffer_track...@fbc-suspend.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14027/shard-apl1/igt@kms_frontbuffer_track...@fbc-suspend.html

  * igt@kms_psr2_su@page_flip:
- shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109642] / [fdo#111068])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb2/igt@kms_psr2_su@page_flip.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14027/shard-iclb4/igt@kms_psr2_su@page_flip.html

  * igt@kms_psr@psr2_primary_mmap_cpu:
- shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +2 similar 
issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14027/shard-iclb4/igt@kms_psr@psr2_primary_mmap_cpu.html

  
 Possible fixes 

  * igt@gem_ctx_shared@exec-single-timeline-bsd:
- shard-iclb: [SKIP][17] ([fdo#110841]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb4/igt@gem_ctx_sha...@exec-single-timeline-bsd.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14027/shard-iclb6/igt@gem_ctx_sha...@exec-single-timeline-bsd.html

  * igt@gem_exec_schedule@preempt-queue-bsd1:
- shard-iclb: [SKIP][19] ([fdo#109276]) -> [PASS][20] +11 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb7/igt@gem_exec_sched...@preempt-queue-bsd1.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14027/shard-iclb4/igt@gem_exec_sched...@preempt-queue-bsd1.html

  * igt@gem_exec_schedule@reorder-wide-bsd:
- shard-iclb: [SKIP][21] ([fdo#111325]) -> [PASS][22] +1 similar 
issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb4/igt@gem_exec_sched...@reorder-wide-bsd.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14027/shard-iclb3/igt@gem_exec_sched...@reorder-wide-bsd.html

  * igt@gem_tiled_swapping@non-threaded:
- shard-glk:  [DMESG-WARN][23] ([fdo#108686]) -> [PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-glk6/igt@gem_tiled_swapp...@non-threaded.html
   [24]: 

Re: [Intel-gfx] [PATCH 2/5] drm/i915/wopcm: Check WOPCM layout separately from calculations

2019-08-15 Thread Daniele Ceraolo Spurio



On 8/15/19 2:48 PM, Michal Wajdeczko wrote:

We can do WOPCM partitioning using rough estimates and limits
and perform detailed check as separate step.

v2: oops! s/max/min

Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
---
  drivers/gpu/drm/i915/intel_wopcm.c | 105 -
  1 file changed, 74 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_wopcm.c 
b/drivers/gpu/drm/i915/intel_wopcm.c
index 2975e00f57f5..39f2764ca3a8 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -87,7 +87,8 @@ void intel_wopcm_init_early(struct intel_wopcm *wopcm)
else
wopcm->size = GEN9_WOPCM_SIZE;
  
-	DRM_DEBUG_DRIVER("WOPCM size: %uKiB\n", wopcm->size / 1024);

+   DRM_DEV_DEBUG_DRIVER(i915->drm.dev, "WOPCM: size %uKiB\n",
+wopcm->size / SZ_1K);
  }
  
  static inline u32 context_reserved_size(struct drm_i915_private *i915)

@@ -138,9 +139,9 @@ static inline int gen9_check_huc_fw_fits(u32 
guc_wopcm_size, u32 huc_fw_size)
return 0;
  }
  
-static inline int check_hw_restriction(struct drm_i915_private *i915,

-  u32 guc_wopcm_base, u32 guc_wopcm_size,
-  u32 huc_fw_size)
+static inline bool check_hw_restrictions(struct drm_i915_private *i915,
+u32 guc_wopcm_base, u32 guc_wopcm_size,
+u32 huc_fw_size)
  {
int err = 0;
  
@@ -151,7 +152,64 @@ static inline int check_hw_restriction(struct drm_i915_private *i915,

(IS_GEN(i915, 9) || IS_CNL_REVID(i915, CNL_REVID_A0, CNL_REVID_A0)))
err = gen9_check_huc_fw_fits(guc_wopcm_size, huc_fw_size);
  
-	return err;

+   return !err;
+}
+
+static inline bool __check_layout(struct drm_i915_private *i915, u32 
wopcm_size,
+ u32 guc_wopcm_base, u32 guc_wopcm_size,
+ u32 guc_fw_size, u32 huc_fw_size)
+{
+   const u32 ctx_rsvd = context_reserved_size(i915);
+   u32 size;
+
+   if (unlikely(guc_wopcm_base > wopcm_size)) {
+   dev_err(i915->drm.dev,
+   "WOPCM: invalid GuC region base: %uK > %uK\n",
+   guc_wopcm_base / SZ_1K, wopcm_size / SZ_1K);
+   return false;
+   }
+
+   size = wopcm_size - ctx_rsvd;
+   if (unlikely(guc_wopcm_base > size)) {
+   dev_err(i915->drm.dev,
+   "WOPCM: invalid GuC region base: %uK > %uK\n",
+   guc_wopcm_base / SZ_1K, size / SZ_1K);
+   return false;
+   }
+
+   if (unlikely(guc_wopcm_size > wopcm_size)) {
+   dev_err(i915->drm.dev,
+   "WOPCM: invalid GuC region size: %uK > %uK\n",
+   guc_wopcm_size / SZ_1K, wopcm_size / SZ_1K);
+   return false;
+   }
+
+   size = wopcm_size - guc_wopcm_base - ctx_rsvd;
+   if (unlikely(guc_wopcm_size > size)) {
+   dev_err(i915->drm.dev,
+   "WOPCM: invalid GuC region size: %uK > %uK\n",
+   guc_wopcm_size / SZ_1K, size / SZ_1K);
+   return false;
+   }



I think we can consolidate all the checks above in just:

wopcm_guc_max = wopcm_size - ctx_rsvd;
if (range_overflows(guc_wopcm_base, guc_wopcm_size, wopcm_guc_max)
return false;



+
+   size = guc_fw_size + GUC_WOPCM_RESERVED + GUC_WOPCM_STACK_RESERVED;
+   if (unlikely(guc_wopcm_size < size)) {
+   dev_err(i915->drm.dev, "WOPCM: no space for %s: %uK < %uK\n",
+   intel_uc_fw_type_repr(INTEL_UC_FW_TYPE_GUC),
+   guc_wopcm_size / SZ_1K, size / SZ_1K);
+   return false;
+   }
+
+   size = huc_fw_size + WOPCM_RESERVED_SIZE;
+   if (unlikely(guc_wopcm_base < size)) {
+   dev_err(i915->drm.dev, "WOPCM: no space for %s: %uK < %uK\n",
+   intel_uc_fw_type_repr(INTEL_UC_FW_TYPE_HUC),
+   guc_wopcm_base / SZ_1K, size / SZ_1K);
+   return false;
+   }
+
+   return check_hw_restrictions(i915, guc_wopcm_base, guc_wopcm_size,
+huc_fw_size);
  }
  
  /**

@@ -172,8 +230,6 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
u32 ctx_rsvd = context_reserved_size(i915);
u32 guc_wopcm_base;
u32 guc_wopcm_size;
-   u32 guc_wopcm_rsvd;
-   int err;
  
  	if (!guc_fw_size)

return;
@@ -183,39 +239,26 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
GEM_BUG_ON(wopcm->guc.size);
GEM_BUG_ON(guc_fw_size >= wopcm->size);
GEM_BUG_ON(huc_fw_size >= wopcm->size);
+   GEM_BUG_ON(ctx_rsvd + WOPCM_RESERVED_SIZE >= wopcm->size);
  
  	if (i915_inject_probe_failure(i915))


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gen11: Add Wa_1604278689:icl,ehl

2019-08-15 Thread Patchwork
== Series Details ==

Series: drm/i915/gen11: Add Wa_1604278689:icl,ehl
URL   : https://patchwork.freedesktop.org/series/65276/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6714 -> Patchwork_14040


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_14040 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_14040, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14040/

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_14040:

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live_hangcheck:
- fi-icl-u3:  [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-icl-u3/igt@i915_selftest@live_hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14040/fi-icl-u3/igt@i915_selftest@live_hangcheck.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_selftest@live_hangcheck:
- {fi-icl-dsi}:   [PASS][3] -> [DMESG-FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14040/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html
- {fi-icl-u4}:[PASS][5] -> [DMESG-FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-icl-u4/igt@i915_selftest@live_hangcheck.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14040/fi-icl-u4/igt@i915_selftest@live_hangcheck.html

  
Known issues


  Here are the changes found in Patchwork_14040 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_create@basic-files:
- fi-icl-u2:  [PASS][7] -> [INCOMPLETE][8] ([fdo#107713] / 
[fdo#109100])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-icl-u2/igt@gem_ctx_cre...@basic-files.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14040/fi-icl-u2/igt@gem_ctx_cre...@basic-files.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-apl-guc: [PASS][9] -> [DMESG-WARN][10] ([fdo#108566])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14040/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  * igt@prime_vgem@basic-fence-mmap:
- fi-icl-u3:  [PASS][11] -> [DMESG-WARN][12] ([fdo#107724])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-icl-u3/igt@prime_v...@basic-fence-mmap.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14040/fi-icl-u3/igt@prime_v...@basic-fence-mmap.html

  
 Possible fixes 

  * igt@gem_mmap_gtt@basic-small-bo-tiledx:
- fi-icl-u3:  [DMESG-WARN][13] ([fdo#107724]) -> [PASS][14] +1 
similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-icl-u3/igt@gem_mmap_...@basic-small-bo-tiledx.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14040/fi-icl-u3/igt@gem_mmap_...@basic-small-bo-tiledx.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-blb-e6850:   [INCOMPLETE][15] ([fdo#107718]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14040/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
  [fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100


Participating hosts (52 -> 44)
--

  Missing(8): fi-kbl-soraka fi-bxt-dsi fi-byt-squawks fi-bsw-cyan fi-icl-y 
fi-icl-guc fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6714 -> Patchwork_14040

  CI-20190529: 20190529
  CI_DRM_6714: 9198974f9fa309c4c74197365844971e0940b227 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5138: b9abe0bf6c478c4f6cac56bff286d6926ad8c0ab @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_14040: 

[Intel-gfx] [PATCH] drm/i915/uc: Add explicit DISABLED state for firmware

2019-08-15 Thread Michal Wajdeczko
We really need to have separate NOT_SUPPORTED state (for
lack of hardware support) and DISABLED state (to indicate
user decision) as we will have to take special steps even
if GuC firmware is now disabled but hardware exists and
could have been previously used.

Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc.h|  7 -
 drivers/gpu/drm/i915/gt/uc/intel_huc.h|  7 -
 drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c |  2 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc.c | 33 ---
 drivers/gpu/drm/i915/gt/uc/intel_uc.h | 17 +++-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  |  6 +++--
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h  | 22 ++-
 drivers/gpu/drm/i915/i915_drv.h   |  2 +-
 8 files changed, 68 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 4999db965685..2b2f046d3cc3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -154,7 +154,12 @@ struct i915_vma *intel_guc_allocate_vma(struct intel_guc 
*guc, u32 size);
 
 static inline bool intel_guc_is_supported(struct intel_guc *guc)
 {
-   return intel_uc_fw_supported(>fw);
+   return intel_uc_fw_is_supported(>fw);
+}
+
+static inline bool intel_guc_is_enabled(struct intel_guc *guc)
+{
+   return intel_uc_fw_is_enabled(>fw);
 }
 
 static inline bool intel_guc_is_running(struct intel_guc *guc)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
index f8a4557c8d6d..644c059fe01d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
@@ -38,7 +38,12 @@ static inline int intel_huc_sanitize(struct intel_huc *huc)
 
 static inline bool intel_huc_is_supported(struct intel_huc *huc)
 {
-   return intel_uc_fw_supported(>fw);
+   return intel_uc_fw_is_supported(>fw);
+}
+
+static inline bool intel_huc_is_enabled(struct intel_huc *huc)
+{
+   return intel_uc_fw_is_enabled(>fw);
 }
 
 static inline bool intel_huc_is_authenticated(struct intel_huc *huc)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
index 96feca99322a..74602487ed67 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
@@ -35,7 +35,7 @@ void intel_huc_fw_init_early(struct intel_huc *huc)
struct drm_i915_private *i915 = gt->i915;
 
intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_HUC,
-  intel_uc_supports_guc(uc),
+  intel_uc_uses_guc(uc),
   INTEL_INFO(i915)->platform, INTEL_REVID(i915));
 }
 
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 0dc2b0cf4604..b375db468c9c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -45,17 +45,17 @@ static void __confirm_options(struct intel_uc *uc)
DRM_DEV_DEBUG_DRIVER(i915->drm.dev,
 "enable_guc=%d (guc:%s submission:%s huc:%s)\n",
 i915_modparams.enable_guc,
-yesno(intel_uc_supports_guc(uc)),
-yesno(intel_uc_supports_guc_submission(uc)),
-yesno(intel_uc_supports_huc(uc)));
+yesno(intel_uc_uses_guc(uc)),
+yesno(intel_uc_uses_guc_submission(uc)),
+yesno(intel_uc_uses_huc(uc)));
 
if (i915_modparams.enable_guc == -1)
return;
 
if (i915_modparams.enable_guc == 0) {
-   GEM_BUG_ON(intel_uc_supports_guc(uc));
-   GEM_BUG_ON(intel_uc_supports_guc_submission(uc));
-   GEM_BUG_ON(intel_uc_supports_huc(uc));
+   GEM_BUG_ON(intel_uc_uses_guc(uc));
+   GEM_BUG_ON(intel_uc_uses_guc_submission(uc));
+   GEM_BUG_ON(intel_uc_uses_huc(uc));
return;
}
 
@@ -266,23 +266,23 @@ void intel_uc_fetch_firmwares(struct intel_uc *uc)
struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
int err;
 
-   if (!intel_uc_supports_guc(uc))
+   if (!intel_uc_uses_guc(uc))
return;
 
err = intel_uc_fw_fetch(>guc.fw, i915);
if (err)
return;
 
-   if (intel_uc_supports_huc(uc))
+   if (intel_uc_uses_huc(uc))
intel_uc_fw_fetch(>huc.fw, i915);
 }
 
 void intel_uc_cleanup_firmwares(struct intel_uc *uc)
 {
-   if (!intel_uc_supports_guc(uc))
+   if (!intel_uc_uses_guc(uc))
return;
 
-   if (intel_uc_supports_huc(uc))
+   if (intel_uc_uses_huc(uc))
intel_uc_fw_cleanup_fetch(>huc.fw);
 
intel_uc_fw_cleanup_fetch(>guc.fw);
@@ -304,7 +304,7 @@ int intel_uc_init(struct 

[Intel-gfx] ✓ Fi.CI.BAT: success for More WOPCM fixes (rev2)

2019-08-15 Thread Patchwork
== Series Details ==

Series: More WOPCM fixes (rev2)
URL   : https://patchwork.freedesktop.org/series/65263/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6714 -> Patchwork_14039


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14039/

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_14039:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@kms_chamelium@dp-hpd-fast:
- {fi-icl-u4}:[FAIL][1] ([fdo#111045]) -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-icl-u4/igt@kms_chamel...@dp-hpd-fast.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14039/fi-icl-u4/igt@kms_chamel...@dp-hpd-fast.html

  
Known issues


  Here are the changes found in Patchwork_14039 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850:   [PASS][3] -> [INCOMPLETE][4] ([fdo#107718])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14039/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_mmap_gtt@basic-write-no-prefault:
- fi-icl-u3:  [PASS][5] -> [DMESG-WARN][6] ([fdo#107724])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-icl-u3/igt@gem_mmap_...@basic-write-no-prefault.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14039/fi-icl-u3/igt@gem_mmap_...@basic-write-no-prefault.html

  * igt@i915_selftest@live_reset:
- fi-icl-u3:  [PASS][7] -> [INCOMPLETE][8] ([fdo#107713])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-icl-u3/igt@i915_selftest@live_reset.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14039/fi-icl-u3/igt@i915_selftest@live_reset.html

  
 Possible fixes 

  * igt@gem_mmap_gtt@basic-small-bo-tiledx:
- fi-icl-u3:  [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10] +1 
similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-icl-u3/igt@gem_mmap_...@basic-small-bo-tiledx.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14039/fi-icl-u3/igt@gem_mmap_...@basic-small-bo-tiledx.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2:  [FAIL][11] ([fdo#103167]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14039/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045


Participating hosts (52 -> 45)
--

  Missing(7): fi-kbl-soraka fi-bsw-n3050 fi-byt-squawks fi-bsw-cyan 
fi-icl-y fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6714 -> Patchwork_14039

  CI-20190529: 20190529
  CI_DRM_6714: 9198974f9fa309c4c74197365844971e0940b227 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5138: b9abe0bf6c478c4f6cac56bff286d6926ad8c0ab @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_14039: d727532eb785fa217ac6eb741c7c3b89e0020bfd @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

d727532eb785 drm/i915/wopmc: Fix SPDX tag location
e6fc80efe0f1 drm/i915/wopcm: Update error messages
fd23026c80a2 drm/i915/wopcm: Try to use already locked WOPCM layout
46c8a54fc7c0 drm/i915/wopcm: Check WOPCM layout separately from calculations
577566a6c0cf drm/i915/uc: Move FW size sanity check back to fetch

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14039/
___
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/dp/dsc: Add Support for all BPCs supported by TGL (rev4)

2019-08-15 Thread Patchwork
== Series Details ==

Series: drm/dp/dsc: Add Support for all BPCs supported by TGL (rev4)
URL   : https://patchwork.freedesktop.org/series/63526/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6713 -> Patchwork_14038


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14038/

Known issues


  Here are the changes found in Patchwork_14038 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_create@basic-files:
- fi-bxt-dsi: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/fi-bxt-dsi/igt@gem_ctx_cre...@basic-files.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14038/fi-bxt-dsi/igt@gem_ctx_cre...@basic-files.html
- fi-apl-guc: [PASS][3] -> [INCOMPLETE][4] ([fdo#103927])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/fi-apl-guc/igt@gem_ctx_cre...@basic-files.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14038/fi-apl-guc/igt@gem_ctx_cre...@basic-files.html

  * igt@gem_ctx_switch@rcs0:
- fi-icl-u2:  [PASS][5] -> [INCOMPLETE][6] ([fdo#107713])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/fi-icl-u2/igt@gem_ctx_swi...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14038/fi-icl-u2/igt@gem_ctx_swi...@rcs0.html

  * igt@kms_busy@basic-flip-a:
- fi-kbl-7567u:   [PASS][7] -> [SKIP][8] ([fdo#109271] / [fdo#109278]) 
+2 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14038/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3:  [PASS][9] -> [FAIL][10] ([fdo#103167])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14038/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html

  
 Possible fixes 

  * igt@gem_ctx_create@basic:
- fi-icl-u3:  [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/fi-icl-u3/igt@gem_ctx_cre...@basic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14038/fi-icl-u3/igt@gem_ctx_cre...@basic.html

  * igt@gem_exec_suspend@basic-s3:
- fi-skl-6260u:   [INCOMPLETE][13] ([fdo#104108]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/fi-skl-6260u/igt@gem_exec_susp...@basic-s3.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14038/fi-skl-6260u/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm:  [DMESG-FAIL][15] ([fdo#08]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14038/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy:   [DMESG-WARN][17] ([fdo#102614]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14038/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08


Participating hosts (50 -> 46)
--

  Additional (2): fi-byt-j1900 fi-bwr-2160 
  Missing(6): fi-kbl-soraka fi-byt-squawks fi-bsw-cyan fi-icl-y 
fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6713 -> Patchwork_14038

  CI-20190529: 20190529
  CI_DRM_6713: 12afcdd96e32c94a34c0205304772f754b668f8d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5138: b9abe0bf6c478c4f6cac56bff286d6926ad8c0ab @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_14038: 273e6a2bf6e0f19cb2e29fb9450254ab83243bd4 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==


[Intel-gfx] [PATCH] drm/i915/gen11: Allow usage of all GPIO pins

2019-08-15 Thread Matt Roper
Our pin mapping tables for ICP and MCC currently only list the standard
GPIO pins used for various output ports.  Even through ICP's standard
pin usage only utilizes pins 1, 2, and 9-12, and MCC's standard pin
usage only uses pins 1, 2, and 9, these platforms do still have GPIO
registers to address pins in the range 1-3 and 9-14.  OEM's may remap
GPIO usage in non-standard ways (and provide the actual mapping via VBT
settings), so we shouldn't exclude pins on these platforms just because
they aren't part of the standard mappings.

TGP's standard pin tables contains all the possible pins, so let's
rename them to "icp" and use them for all PCH >= PCH_ICP.  This will
prevent intel_gmbus_is_valid_pin from rejecting non-standard pin usage
that an OEM specifies via the VBT.

Note that this will cause pin 9 to be labeled as "tc1" instead of "dpc"
in debug messages on platforms with the MCC PCH, but that may actually
help avoid confusion since the text strings will now be the same on all
gen11+ platforms instead of being different on just EHL.

v2: Drop now-unused MCC_DDC_BUS_DDI_* names.

Bspec: 8417
Cc: José Roberto de Souza 
Cc: Lucas De Marchi 
Cc: Vivek Kasireddy 
Cc: Jani Nikula 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/display/intel_bios.c | 23 +---
 drivers/gpu/drm/i915/display/intel_gmbus.c| 27 ++-
 drivers/gpu/drm/i915/display/intel_vbt_defs.h |  3 ---
 3 files changed, 3 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index b416b394b641..ed608f2df130 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -1341,21 +1341,6 @@ static const u8 cnp_ddc_pin_map[] = {
 };
 
 static const u8 icp_ddc_pin_map[] = {
-   [ICL_DDC_BUS_DDI_A] = GMBUS_PIN_1_BXT,
-   [ICL_DDC_BUS_DDI_B] = GMBUS_PIN_2_BXT,
-   [ICL_DDC_BUS_PORT_1] = GMBUS_PIN_9_TC1_ICP,
-   [ICL_DDC_BUS_PORT_2] = GMBUS_PIN_10_TC2_ICP,
-   [ICL_DDC_BUS_PORT_3] = GMBUS_PIN_11_TC3_ICP,
-   [ICL_DDC_BUS_PORT_4] = GMBUS_PIN_12_TC4_ICP,
-};
-
-static const u8 mcc_ddc_pin_map[] = {
-   [MCC_DDC_BUS_DDI_A] = GMBUS_PIN_1_BXT,
-   [MCC_DDC_BUS_DDI_B] = GMBUS_PIN_2_BXT,
-   [MCC_DDC_BUS_DDI_C] = GMBUS_PIN_9_TC1_ICP,
-};
-
-static const u8 tgp_ddc_pin_map[] = {
[ICL_DDC_BUS_DDI_A] = GMBUS_PIN_1_BXT,
[ICL_DDC_BUS_DDI_B] = GMBUS_PIN_2_BXT,
[TGL_DDC_BUS_DDI_C] = GMBUS_PIN_3_BXT,
@@ -1372,13 +1357,7 @@ static u8 map_ddc_pin(struct drm_i915_private *dev_priv, 
u8 vbt_pin)
const u8 *ddc_pin_map;
int n_entries;
 
-   if (HAS_PCH_TGP(dev_priv)) {
-   ddc_pin_map = tgp_ddc_pin_map;
-   n_entries = ARRAY_SIZE(tgp_ddc_pin_map);
-   } else if (HAS_PCH_MCC(dev_priv)) {
-   ddc_pin_map = mcc_ddc_pin_map;
-   n_entries = ARRAY_SIZE(mcc_ddc_pin_map);
-   } else if (HAS_PCH_ICP(dev_priv)) {
+   if (INTEL_PCH_ID(dev_priv) >= PCH_ICP) {
ddc_pin_map = icp_ddc_pin_map;
n_entries = ARRAY_SIZE(icp_ddc_pin_map);
} else if (HAS_PCH_CNP(dev_priv)) {
diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c 
b/drivers/gpu/drm/i915/display/intel_gmbus.c
index 1e27b18aa3fc..3ac8a5c0b4b5 100644
--- a/drivers/gpu/drm/i915/display/intel_gmbus.c
+++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
@@ -80,21 +80,6 @@ static const struct gmbus_pin gmbus_pins_cnp[] = {
 };
 
 static const struct gmbus_pin gmbus_pins_icp[] = {
-   [GMBUS_PIN_1_BXT] = { "dpa", GPIOB },
-   [GMBUS_PIN_2_BXT] = { "dpb", GPIOC },
-   [GMBUS_PIN_9_TC1_ICP] = { "tc1", GPIOJ },
-   [GMBUS_PIN_10_TC2_ICP] = { "tc2", GPIOK },
-   [GMBUS_PIN_11_TC3_ICP] = { "tc3", GPIOL },
-   [GMBUS_PIN_12_TC4_ICP] = { "tc4", GPIOM },
-};
-
-static const struct gmbus_pin gmbus_pins_mcc[] = {
-   [GMBUS_PIN_1_BXT] = { "dpa", GPIOB },
-   [GMBUS_PIN_2_BXT] = { "dpb", GPIOC },
-   [GMBUS_PIN_9_TC1_ICP] = { "dpc", GPIOJ },
-};
-
-static const struct gmbus_pin gmbus_pins_tgp[] = {
[GMBUS_PIN_1_BXT] = { "dpa", GPIOB },
[GMBUS_PIN_2_BXT] = { "dpb", GPIOC },
[GMBUS_PIN_3_BXT] = { "dpc", GPIOD },
@@ -110,11 +95,7 @@ static const struct gmbus_pin gmbus_pins_tgp[] = {
 static const struct gmbus_pin *get_gmbus_pin(struct drm_i915_private *dev_priv,
 unsigned int pin)
 {
-   if (HAS_PCH_TGP(dev_priv))
-   return _pins_tgp[pin];
-   else if (HAS_PCH_MCC(dev_priv))
-   return _pins_mcc[pin];
-   else if (HAS_PCH_ICP(dev_priv))
+   if (INTEL_PCH_ID(dev_priv) >= PCH_ICP)
return _pins_icp[pin];
else if (HAS_PCH_CNP(dev_priv))
return _pins_cnp[pin];
@@ -133,11 +114,7 @@ bool intel_gmbus_is_valid_pin(struct drm_i915_private 
*dev_priv,
 {
unsigned int size;
 
-   if (HAS_PCH_TGP(dev_priv))
-   size = 

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915/icl: Implement gen11 flush including tile cache

2019-08-15 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915/icl: Implement gen11 flush 
including tile cache
URL   : https://patchwork.freedesktop.org/series/65226/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6711_full -> Patchwork_14025_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_14025_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@drm_import_export@flink:
- shard-apl:  [PASS][1] -> [INCOMPLETE][2] ([fdo#103927])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-apl4/igt@drm_import_exp...@flink.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14025/shard-apl2/igt@drm_import_exp...@flink.html

  * igt@gem_exec_schedule@preempt-contexts-bsd2:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276]) +17 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb2/igt@gem_exec_sched...@preempt-contexts-bsd2.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14025/shard-iclb7/igt@gem_exec_sched...@preempt-contexts-bsd2.html

  * igt@gem_exec_schedule@preempt-other-chain-bsd:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#111325]) +3 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb5/igt@gem_exec_sched...@preempt-other-chain-bsd.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14025/shard-iclb1/igt@gem_exec_sched...@preempt-other-chain-bsd.html

  * igt@gem_softpin@noreloc-s3:
- shard-apl:  [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +3 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-apl6/igt@gem_soft...@noreloc-s3.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14025/shard-apl7/igt@gem_soft...@noreloc-s3.html
- shard-skl:  [PASS][9] -> [INCOMPLETE][10] ([fdo#104108])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-skl5/igt@gem_soft...@noreloc-s3.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14025/shard-skl3/igt@gem_soft...@noreloc-s3.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
- shard-hsw:  [PASS][11] -> [INCOMPLETE][12] ([fdo#103540])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-hsw2/igt@kms_f...@flip-vs-suspend-interruptible.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14025/shard-hsw1/igt@kms_f...@flip-vs-suspend-interruptible.html

  * igt@kms_flip@plain-flip-fb-recreate-interruptible:
- shard-glk:  [PASS][13] -> [FAIL][14] ([fdo#100368])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-glk8/igt@kms_f...@plain-flip-fb-recreate-interruptible.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14025/shard-glk8/igt@kms_f...@plain-flip-fb-recreate-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-render:
- shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167]) +1 similar 
issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb4/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-render.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14025/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-render.html

  * igt@kms_psr@psr2_cursor_plane_move:
- shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +1 similar 
issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb2/igt@kms_psr@psr2_cursor_plane_move.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14025/shard-iclb7/igt@kms_psr@psr2_cursor_plane_move.html

  
 Possible fixes 

  * igt@gem_ctx_shared@exec-single-timeline-bsd:
- shard-iclb: [SKIP][19] ([fdo#110841]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb4/igt@gem_ctx_sha...@exec-single-timeline-bsd.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14025/shard-iclb6/igt@gem_ctx_sha...@exec-single-timeline-bsd.html

  * igt@gem_exec_schedule@preempt-queue-bsd1:
- shard-iclb: [SKIP][21] ([fdo#109276]) -> [PASS][22] +7 similar 
issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb7/igt@gem_exec_sched...@preempt-queue-bsd1.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14025/shard-iclb2/igt@gem_exec_sched...@preempt-queue-bsd1.html

  * igt@gem_exec_schedule@reorder-wide-bsd:
- shard-iclb: [SKIP][23] ([fdo#111325]) -> [PASS][24] +3 similar 
issues
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb4/igt@gem_exec_sched...@reorder-wide-bsd.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14025/shard-iclb3/igt@gem_exec_sched...@reorder-wide-bsd.html

  * 

Re: [Intel-gfx] [PATCH] drm/i915/gen11: Add Wa_1604278689:icl,ehl

2019-08-15 Thread Matt Roper
On Thu, Aug 15, 2019 at 11:19:36PM +0100, Chris Wilson wrote:
> Quoting Matt Roper (2019-08-15 22:58:59)
> > From the bspec:
> > 
> > "SW must always program the FBC_RT_BASE_ADDR_REGISTER_* register
> > in Render Engine to a reserved value (0x_) such that the
> > programmed value doesn’t match the render target surface address
> > programmed. This would disable render engine from generating
> > modify messages to FBC unit in display."
> > 
> > Bspec: 11388
> > Bspec: 33451
> > Cc: José Roberto de Souza 
> > Signed-off-by: Matt Roper 
> > ---
> >  drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++
> >  drivers/gpu/drm/i915/i915_reg.h | 1 +
> >  2 files changed, 7 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > index 704ace01e7f5..29b50e2c0627 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > @@ -567,6 +567,12 @@ static void icl_ctx_workarounds_init(struct 
> > intel_engine_cs *engine,
> > /* allow headerless messages for preemptible GPGPU context */
> > WA_SET_BIT_MASKED(GEN10_SAMPLER_MODE,
> >   GEN11_SAMPLER_ENABLE_HEADLESS_MSG);
> > +
> > +   /* Wa_1604278689:icl,ehl */
> > +   wa_write_masked_or(wal, IVB_FBC_RT_BASE_UPPER,
> > +  0, /* write-only register; skip validation */
> > +  0x);
> > +   wa_write(wal, IVB_FBC_RT_BASE, 0x);
> 
> It's part of the context?
> -Chris

The register definitions say "This Register is saved and restored as
part of Context" so I think so?  But that does seem to be different than
how we used to program this register back before commit b339088d8
("drm/i915: Don't write IVB_FBC_RT_BASE") so maybe I'm misinterpreting?


Matt

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

Re: [Intel-gfx] [PATCH] drm/i915/gen11: Add Wa_1604278689:icl,ehl

2019-08-15 Thread Chris Wilson
Quoting Matt Roper (2019-08-15 22:58:59)
> From the bspec:
> 
> "SW must always program the FBC_RT_BASE_ADDR_REGISTER_* register
> in Render Engine to a reserved value (0x_) such that the
> programmed value doesn’t match the render target surface address
> programmed. This would disable render engine from generating
> modify messages to FBC unit in display."
> 
> Bspec: 11388
> Bspec: 33451
> Cc: José Roberto de Souza 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++
>  drivers/gpu/drm/i915/i915_reg.h | 1 +
>  2 files changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 704ace01e7f5..29b50e2c0627 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -567,6 +567,12 @@ static void icl_ctx_workarounds_init(struct 
> intel_engine_cs *engine,
> /* allow headerless messages for preemptible GPGPU context */
> WA_SET_BIT_MASKED(GEN10_SAMPLER_MODE,
>   GEN11_SAMPLER_ENABLE_HEADLESS_MSG);
> +
> +   /* Wa_1604278689:icl,ehl */
> +   wa_write_masked_or(wal, IVB_FBC_RT_BASE_UPPER,
> +  0, /* write-only register; skip validation */
> +  0x);
> +   wa_write(wal, IVB_FBC_RT_BASE, 0x);

It's part of the context?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

2019-08-15 Thread Andrew Morton
On Thu, 15 Aug 2019 10:44:29 +0200 Michal Hocko  wrote:

> > I continue to struggle with this.  It introduces a new kernel state
> > "running preemptibly but must not call schedule()".  How does this make
> > any sense?
> > 
> > Perhaps a much, much more detailed description of the oom_reaper
> > situation would help out.
>  
> The primary point here is that there is a demand of non blockable mmu
> notifiers to be called when the oom reaper tears down the address space.
> As the oom reaper is the primary guarantee of the oom handling forward
> progress it cannot be blocked on anything that might depend on blockable
> memory allocations. These are not really easy to track because they
> might be indirect - e.g. notifier blocks on a lock which other context
> holds while allocating memory or waiting for a flusher that needs memory
> to perform its work. If such a blocking state happens that we can end up
> in a silent hang with an unusable machine.
> Now we hope for reasonable implementations of mmu notifiers (strong
> words I know ;) and this should be relatively simple and effective catch
> all tool to detect something suspicious is going on.
> 
> Does that make the situation more clear?

Yes, thanks, much.  Maybe a code comment along the lines of

  This is on behalf of the oom reaper, specifically when it is
  calling the mmu notifiers.  The problem is that if the notifier were
  to block on, for example, mutex_lock() and if the process which holds
  that mutex were to perform a sleeping memory allocation, the oom
  reaper is now blocked on completion of that memory allocation.

btw, do we need task_struct.non_block_count?  Perhaps the oom reaper
thread could set a new PF_NONBLOCK (which would be more general than
PF_OOM_REAPER).  If we run out of PF_ flags, use (current == oom_reaper_th).

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/4] drm/i915/gt: Track timeline activeness in enter/exit

2019-08-15 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/4] drm/i915/gt: Track timeline activeness in 
enter/exit
URL   : https://patchwork.freedesktop.org/series/65274/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6713 -> Patchwork_14037


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14037/

Known issues


  Here are the changes found in Patchwork_14037 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_param@basic:
- fi-bxt-dsi: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/fi-bxt-dsi/igt@gem_ctx_pa...@basic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14037/fi-bxt-dsi/igt@gem_ctx_pa...@basic.html

  * igt@i915_module_load@reload:
- fi-blb-e6850:   [PASS][3] -> [INCOMPLETE][4] ([fdo#107718])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/fi-blb-e6850/igt@i915_module_l...@reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14037/fi-blb-e6850/igt@i915_module_l...@reload.html

  * igt@kms_busy@basic-flip-a:
- fi-kbl-7567u:   [PASS][5] -> [SKIP][6] ([fdo#109271] / [fdo#109278]) 
+2 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14037/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3:  [PASS][7] -> [FAIL][8] ([fdo#103167])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14037/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html

  * igt@vgem_basic@second-client:
- fi-icl-u3:  [PASS][9] -> [DMESG-WARN][10] ([fdo#107724])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/fi-icl-u3/igt@vgem_ba...@second-client.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14037/fi-icl-u3/igt@vgem_ba...@second-client.html

  
 Possible fixes 

  * igt@gem_ctx_create@basic:
- fi-icl-u3:  [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/fi-icl-u3/igt@gem_ctx_cre...@basic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14037/fi-icl-u3/igt@gem_ctx_cre...@basic.html

  * igt@gem_exec_suspend@basic-s3:
- fi-skl-6260u:   [INCOMPLETE][13] ([fdo#104108]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/fi-skl-6260u/igt@gem_exec_susp...@basic-s3.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14037/fi-skl-6260u/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm:  [DMESG-FAIL][15] ([fdo#08]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14037/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy:   [DMESG-WARN][17] ([fdo#102614]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14037/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
- fi-icl-u2:  [FAIL][19] ([fdo#103167]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14037/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
  [fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08


Participating hosts (50 -> 46)
--

  Additional (2): fi-byt-j1900 fi-bwr-2160 
  Missing(6): fi-kbl-soraka fi-byt-squawks fi-bsw-cyan fi-icl-y 
fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * 

[Intel-gfx] [PATCH] drm/i915/gen11: Add Wa_1604278689:icl,ehl

2019-08-15 Thread Matt Roper
From the bspec:

"SW must always program the FBC_RT_BASE_ADDR_REGISTER_* register
in Render Engine to a reserved value (0x_) such that the
programmed value doesn’t match the render target surface address
programmed. This would disable render engine from generating
modify messages to FBC unit in display."

Bspec: 11388
Bspec: 33451
Cc: José Roberto de Souza 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++
 drivers/gpu/drm/i915/i915_reg.h | 1 +
 2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 704ace01e7f5..29b50e2c0627 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -567,6 +567,12 @@ static void icl_ctx_workarounds_init(struct 
intel_engine_cs *engine,
/* allow headerless messages for preemptible GPGPU context */
WA_SET_BIT_MASKED(GEN10_SAMPLER_MODE,
  GEN11_SAMPLER_ENABLE_HEADLESS_MSG);
+
+   /* Wa_1604278689:icl,ehl */
+   wa_write_masked_or(wal, IVB_FBC_RT_BASE_UPPER,
+  0, /* write-only register; skip validation */
+  0x);
+   wa_write(wal, IVB_FBC_RT_BASE, 0x);
 }
 
 static void
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index def6dbdc7e2e..14af1b1dc0d3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3214,6 +3214,7 @@ enum i915_power_well_id {
 
 /* Framebuffer compression for Ivybridge */
 #define IVB_FBC_RT_BASE_MMIO(0x7020)
+#define IVB_FBC_RT_BASE_UPPER  _MMIO(0x7024)
 
 #define IPS_CTL_MMIO(0x43408)
 #define   IPS_ENABLE   (1 << 31)
-- 
2.20.1

___
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: Replace PIN_NONFAULT with calls to PIN_NOEVICT (rev2)

2019-08-15 Thread Patchwork
== Series Details ==

Series: drm/i915: Replace PIN_NONFAULT with calls to PIN_NOEVICT (rev2)
URL   : https://patchwork.freedesktop.org/series/65222/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6711_full -> Patchwork_14024_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_14024_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_async@concurrent-writes-bsd:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#111325]) +3 similar 
issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb7/igt@gem_exec_as...@concurrent-writes-bsd.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14024/shard-iclb4/igt@gem_exec_as...@concurrent-writes-bsd.html

  * igt@gem_exec_schedule@preempt-contexts-bsd2:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276]) +14 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb2/igt@gem_exec_sched...@preempt-contexts-bsd2.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14024/shard-iclb5/igt@gem_exec_sched...@preempt-contexts-bsd2.html

  * igt@kms_cursor_crc@pipe-b-cursor-suspend:
- shard-skl:  [PASS][5] -> [INCOMPLETE][6] ([fdo#110741])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-skl9/igt@kms_cursor_...@pipe-b-cursor-suspend.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14024/shard-skl3/igt@kms_cursor_...@pipe-b-cursor-suspend.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl:  [PASS][7] -> [FAIL][8] ([fdo#105363])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-skl5/igt@kms_f...@flip-vs-expired-vblank-interruptible.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14024/shard-skl8/igt@kms_f...@flip-vs-expired-vblank-interruptible.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-blt:
- shard-iclb: [PASS][9] -> [FAIL][10] ([fdo#103167])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb1/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-blt.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14024/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-blt.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
- shard-apl:  [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +1 
similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-apl4/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-c.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14024/shard-apl5/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-c.html

  * igt@kms_psr@psr2_cursor_plane_move:
- shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109441]) +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb2/igt@kms_psr@psr2_cursor_plane_move.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14024/shard-iclb5/igt@kms_psr@psr2_cursor_plane_move.html

  * igt@kms_vblank@pipe-c-wait-busy-hang:
- shard-hsw:  [PASS][15] -> [INCOMPLETE][16] ([fdo#103540])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-hsw6/igt@kms_vbl...@pipe-c-wait-busy-hang.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14024/shard-hsw5/igt@kms_vbl...@pipe-c-wait-busy-hang.html

  
 Possible fixes 

  * igt@gem_exec_schedule@in-order-bsd:
- shard-iclb: [SKIP][17] ([fdo#111325]) -> [PASS][18] +2 similar 
issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb2/igt@gem_exec_sched...@in-order-bsd.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14024/shard-iclb5/igt@gem_exec_sched...@in-order-bsd.html

  * igt@gem_workarounds@suspend-resume-context:
- shard-apl:  [INCOMPLETE][19] ([fdo#103927]) -> [PASS][20] +6 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-apl1/igt@gem_workarou...@suspend-resume-context.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14024/shard-apl6/igt@gem_workarou...@suspend-resume-context.html

  * igt@i915_suspend@fence-restore-tiled2untiled:
- shard-apl:  [DMESG-WARN][21] ([fdo#108566]) -> [PASS][22] +3 
similar issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-apl7/igt@i915_susp...@fence-restore-tiled2untiled.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14024/shard-apl7/igt@i915_susp...@fence-restore-tiled2untiled.html

  * igt@kms_cursor_crc@pipe-b-cursor-256x256-random:
- shard-skl:  [FAIL][23] ([fdo#103232]) -> [PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-skl4/igt@kms_cursor_...@pipe-b-cursor-256x256-random.html
   [24]: 

[Intel-gfx] [PATCH 2/5] drm/i915/wopcm: Check WOPCM layout separately from calculations

2019-08-15 Thread Michal Wajdeczko
We can do WOPCM partitioning using rough estimates and limits
and perform detailed check as separate step.

v2: oops! s/max/min

Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_wopcm.c | 105 -
 1 file changed, 74 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_wopcm.c 
b/drivers/gpu/drm/i915/intel_wopcm.c
index 2975e00f57f5..39f2764ca3a8 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -87,7 +87,8 @@ void intel_wopcm_init_early(struct intel_wopcm *wopcm)
else
wopcm->size = GEN9_WOPCM_SIZE;
 
-   DRM_DEBUG_DRIVER("WOPCM size: %uKiB\n", wopcm->size / 1024);
+   DRM_DEV_DEBUG_DRIVER(i915->drm.dev, "WOPCM: size %uKiB\n",
+wopcm->size / SZ_1K);
 }
 
 static inline u32 context_reserved_size(struct drm_i915_private *i915)
@@ -138,9 +139,9 @@ static inline int gen9_check_huc_fw_fits(u32 
guc_wopcm_size, u32 huc_fw_size)
return 0;
 }
 
-static inline int check_hw_restriction(struct drm_i915_private *i915,
-  u32 guc_wopcm_base, u32 guc_wopcm_size,
-  u32 huc_fw_size)
+static inline bool check_hw_restrictions(struct drm_i915_private *i915,
+u32 guc_wopcm_base, u32 guc_wopcm_size,
+u32 huc_fw_size)
 {
int err = 0;
 
@@ -151,7 +152,64 @@ static inline int check_hw_restriction(struct 
drm_i915_private *i915,
(IS_GEN(i915, 9) || IS_CNL_REVID(i915, CNL_REVID_A0, CNL_REVID_A0)))
err = gen9_check_huc_fw_fits(guc_wopcm_size, huc_fw_size);
 
-   return err;
+   return !err;
+}
+
+static inline bool __check_layout(struct drm_i915_private *i915, u32 
wopcm_size,
+ u32 guc_wopcm_base, u32 guc_wopcm_size,
+ u32 guc_fw_size, u32 huc_fw_size)
+{
+   const u32 ctx_rsvd = context_reserved_size(i915);
+   u32 size;
+
+   if (unlikely(guc_wopcm_base > wopcm_size)) {
+   dev_err(i915->drm.dev,
+   "WOPCM: invalid GuC region base: %uK > %uK\n",
+   guc_wopcm_base / SZ_1K, wopcm_size / SZ_1K);
+   return false;
+   }
+
+   size = wopcm_size - ctx_rsvd;
+   if (unlikely(guc_wopcm_base > size)) {
+   dev_err(i915->drm.dev,
+   "WOPCM: invalid GuC region base: %uK > %uK\n",
+   guc_wopcm_base / SZ_1K, size / SZ_1K);
+   return false;
+   }
+
+   if (unlikely(guc_wopcm_size > wopcm_size)) {
+   dev_err(i915->drm.dev,
+   "WOPCM: invalid GuC region size: %uK > %uK\n",
+   guc_wopcm_size / SZ_1K, wopcm_size / SZ_1K);
+   return false;
+   }
+
+   size = wopcm_size - guc_wopcm_base - ctx_rsvd;
+   if (unlikely(guc_wopcm_size > size)) {
+   dev_err(i915->drm.dev,
+   "WOPCM: invalid GuC region size: %uK > %uK\n",
+   guc_wopcm_size / SZ_1K, size / SZ_1K);
+   return false;
+   }
+
+   size = guc_fw_size + GUC_WOPCM_RESERVED + GUC_WOPCM_STACK_RESERVED;
+   if (unlikely(guc_wopcm_size < size)) {
+   dev_err(i915->drm.dev, "WOPCM: no space for %s: %uK < %uK\n",
+   intel_uc_fw_type_repr(INTEL_UC_FW_TYPE_GUC),
+   guc_wopcm_size / SZ_1K, size / SZ_1K);
+   return false;
+   }
+
+   size = huc_fw_size + WOPCM_RESERVED_SIZE;
+   if (unlikely(guc_wopcm_base < size)) {
+   dev_err(i915->drm.dev, "WOPCM: no space for %s: %uK < %uK\n",
+   intel_uc_fw_type_repr(INTEL_UC_FW_TYPE_HUC),
+   guc_wopcm_base / SZ_1K, size / SZ_1K);
+   return false;
+   }
+
+   return check_hw_restrictions(i915, guc_wopcm_base, guc_wopcm_size,
+huc_fw_size);
 }
 
 /**
@@ -172,8 +230,6 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
u32 ctx_rsvd = context_reserved_size(i915);
u32 guc_wopcm_base;
u32 guc_wopcm_size;
-   u32 guc_wopcm_rsvd;
-   int err;
 
if (!guc_fw_size)
return;
@@ -183,39 +239,26 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
GEM_BUG_ON(wopcm->guc.size);
GEM_BUG_ON(guc_fw_size >= wopcm->size);
GEM_BUG_ON(huc_fw_size >= wopcm->size);
+   GEM_BUG_ON(ctx_rsvd + WOPCM_RESERVED_SIZE >= wopcm->size);
 
if (i915_inject_probe_failure(i915))
return;
 
guc_wopcm_base = ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
   GUC_WOPCM_OFFSET_ALIGNMENT);
-   if ((guc_wopcm_base + ctx_rsvd) >= wopcm->size) {
-   DRM_ERROR("GuC WOPCM base (%uKiB) is too 

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for More WOPCM fixes

2019-08-15 Thread Michal Wajdeczko
On Thu, 15 Aug 2019 19:52:44 +0200, Patchwork  
 wrote:



== Series Details ==

Series: More WOPCM fixes
URL   : https://patchwork.freedesktop.org/series/65263/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6712 -> Patchwork_14032


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_14032 absolutely need to  
be

  verified manually.
 If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_14032, please notify your bug team to allow  
them
  to document this new failure mode, which will reduce false positives  
in CI.


  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/

Possible new issues
---

  Here are the unknown changes that may have been introduced in  
Patchwork_14032:


### IGT changes ###

 Possible regressions 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-cfl-guc: [PASS][1] -> [FAIL][2]
   [1]:  
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-cfl-guc/igt@i915_pm_...@basic-pci-d3-state.html
   [2]:  
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-cfl-guc/igt@i915_pm_...@basic-pci-d3-state.html

- fi-skl-guc: [PASS][3] -> [FAIL][4]
   [3]:  
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-skl-guc/igt@i915_pm_...@basic-pci-d3-state.html
   [4]:  
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-skl-guc/igt@i915_pm_...@basic-pci-d3-state.html

- fi-apl-guc: [PASS][5] -> [FAIL][6]
   [5]:  
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-apl-guc/igt@i915_pm_...@basic-pci-d3-state.html
   [6]:  
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-apl-guc/igt@i915_pm_...@basic-pci-d3-state.html




<7>[   12.007665] i915 :00:02.0: [drm:intel_wopcm_init [i915]]  
Calculated GuC WOPCM Region: [2012KiB, 0KiB)

<3>[   12.007668] i915 :00:02.0: WOPCM: no space for GuC: 0K < 400K

due to trivia min/max mistake
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] Revert "ALSA: hda - Drop unsol event handler for Intel HDMI codecs"

2019-08-15 Thread Chris Wilson
Quoting Takashi Iwai (2019-08-15 20:42:14)
[snip]
> 
> Gah, that's a breakage by the commit ee5f85d9290f ("ALSA: hda: Add
> codec on bus address table lately").  Please revert it in your tree,
> I'll do it same on sound git tree now.

Thanks for taking care of it!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [v3] drm/dp/dsc: Add Support for all BPCs supported by TGL

2019-08-15 Thread Anusha Srivatsa
DSC engine on ICL supports only 8 and 10 BPC as the input
BPC. But DSC engine in TGL supports 8, 10 and 12 BPC.
Add 12 BPC support for DSC while calculating compression
configuration.

v2: Remove the separate define TGL_DP_DSC_MAX_SUPPORTED_BPC
and use the value directly.(More such defines can be removed
as part of future patches). (Ville)

v3: Use values directly instead of accessing the defines
everytime for min and max DSC BPC.

Cc: Ville Syrjälä 
Cc: Manasi Navare 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 4884c87c8ed7..f9d2438d7da9 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -70,8 +70,6 @@
 
 /* DP DSC small joiner has 2 FIFOs each of 640 x 6 bytes */
 #define DP_DSC_MAX_SMALL_JOINER_RAM_BUFFER 61440
-#define DP_DSC_MIN_SUPPORTED_BPC   8
-#define DP_DSC_MAX_SUPPORTED_BPC   10
 
 /* DP DSC throughput values used for slice count calculations KPixels/s */
 #define DP_DSC_PEAK_PIXEL_RATE 272
@@ -1915,11 +1913,17 @@ static int intel_dp_dsc_compute_config(struct intel_dp 
*intel_dp,
if (!intel_dp_supports_dsc(intel_dp, pipe_config))
return -EINVAL;
 
-   dsc_max_bpc = min_t(u8, DP_DSC_MAX_SUPPORTED_BPC,
-   conn_state->max_requested_bpc);
+   /* Max DSC Input BPC for ICL is 10 and for TGL+ is 12 */
+   if (INTEL_GEN(dev_priv) >= 12)
+   dsc_max_bpc = min_t(u8, 12, conn_state->max_requested_bpc);
+   else
+   dsc_max_bpc = min_t(u8, 10,
+   conn_state->max_requested_bpc);
 
pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, dsc_max_bpc);
-   if (pipe_bpp < DP_DSC_MIN_SUPPORTED_BPC * 3) {
+
+   /* Min Input BPC for ICL+ is 8 */
+   if (pipe_bpp < 8 * 3) {
DRM_DEBUG_KMS("No DSC support for less than 8bpc\n");
return -EINVAL;
}
-- 
2.22.1

___
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: Move tasklet kicking to __i915_request_queue caller

2019-08-15 Thread Patchwork
== Series Details ==

Series: drm/i915: Move tasklet kicking to __i915_request_queue caller
URL   : https://patchwork.freedesktop.org/series/65221/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6711_full -> Patchwork_14022_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_14022_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_async@concurrent-writes-bsd:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#111325]) +3 similar 
issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb7/igt@gem_exec_as...@concurrent-writes-bsd.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14022/shard-iclb1/igt@gem_exec_as...@concurrent-writes-bsd.html

  * igt@gem_exec_schedule@fifo-bsd1:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276]) +10 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb4/igt@gem_exec_sched...@fifo-bsd1.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14022/shard-iclb8/igt@gem_exec_sched...@fifo-bsd1.html

  * igt@gem_tiled_swapping@non-threaded:
- shard-apl:  [PASS][5] -> [DMESG-WARN][6] ([fdo#108686])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-apl2/igt@gem_tiled_swapp...@non-threaded.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14022/shard-apl4/igt@gem_tiled_swapp...@non-threaded.html

  * igt@i915_pm_rps@min-max-config-idle:
- shard-apl:  [PASS][7] -> [INCOMPLETE][8] ([fdo#103927]) +1 
similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-apl7/igt@i915_pm_...@min-max-config-idle.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14022/shard-apl6/igt@i915_pm_...@min-max-config-idle.html

  * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic:
- shard-hsw:  [PASS][9] -> [FAIL][10] ([fdo#105767])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-hsw5/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14022/shard-hsw4/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html

  * igt@kms_cursor_legacy@cursor-vs-flip-atomic:
- shard-hsw:  [PASS][11] -> [FAIL][12] ([fdo#103355])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-hsw2/igt@kms_cursor_leg...@cursor-vs-flip-atomic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14022/shard-hsw6/igt@kms_cursor_leg...@cursor-vs-flip-atomic.html

  * igt@kms_fbcon_fbt@psr-suspend:
- shard-skl:  [PASS][13] -> [INCOMPLETE][14] ([fdo#104108])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-skl7/igt@kms_fbcon_...@psr-suspend.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14022/shard-skl7/igt@kms_fbcon_...@psr-suspend.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl:  [PASS][15] -> [FAIL][16] ([fdo#105363])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-skl5/igt@kms_f...@flip-vs-expired-vblank-interruptible.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14022/shard-skl8/igt@kms_f...@flip-vs-expired-vblank-interruptible.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
- shard-skl:  [PASS][17] -> [INCOMPLETE][18] ([fdo#109507])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-skl9/igt@kms_f...@flip-vs-suspend-interruptible.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14022/shard-skl7/igt@kms_f...@flip-vs-suspend-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-apl:  [PASS][19] -> [DMESG-WARN][20] ([fdo#108566]) +8 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-apl5/igt@kms_frontbuffer_track...@fbc-suspend.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14022/shard-apl6/igt@kms_frontbuffer_track...@fbc-suspend.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite:
- shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#103167]) +6 similar 
issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14022/shard-iclb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html

  * igt@kms_psr2_su@page_flip:
- shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109642] / [fdo#111068])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/shard-iclb2/igt@kms_psr2_su@page_flip.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14022/shard-iclb1/igt@kms_psr2_su@page_flip.html

  * igt@kms_psr@no_drrs:
- 

[Intel-gfx] [CI 3/4] drm/i915/gt: Guard timeline pinning without relying on struct_mutex

2019-08-15 Thread Chris Wilson
In preparation for removing struct_mutex from around context retirement,
we need to make timeline pinning and unpinning safe. Since multiple
engines/contexts can share a single timeline, we cannot rely on
borrowing the context mutex (otherwise we could state that the timeline
is only pinned/unpinned inside the context pin/unpin and so guarded by
it). However, we only perform a sequence of atomic operations inside the
timeline pin/unpin and the sequence of those operations is safe for a
concurrent unpin / pin, so we can relax the struct_mutex requirement.

Signed-off-by: Chris Wilson 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/gt/intel_timeline.c  | 27 +--
 .../gpu/drm/i915/gt/intel_timeline_types.h|  2 +-
 drivers/gpu/drm/i915/gt/mock_engine.c |  6 ++---
 3 files changed, 16 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c 
b/drivers/gpu/drm/i915/gt/intel_timeline.c
index 355dfc52c804..7b476cd55dac 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline.c
+++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
@@ -211,9 +211,9 @@ int intel_timeline_init(struct intel_timeline *timeline,
void *vaddr;
 
kref_init(>kref);
+   atomic_set(>pin_count, 0);
 
timeline->gt = gt;
-   timeline->pin_count = 0;
 
timeline->has_initial_breadcrumb = !hwsp;
timeline->hwsp_cacheline = NULL;
@@ -280,7 +280,7 @@ void intel_timelines_init(struct drm_i915_private *i915)
 
 void intel_timeline_fini(struct intel_timeline *timeline)
 {
-   GEM_BUG_ON(timeline->pin_count);
+   GEM_BUG_ON(atomic_read(>pin_count));
GEM_BUG_ON(!list_empty(>requests));
 
if (timeline->hwsp_cacheline)
@@ -314,33 +314,31 @@ int intel_timeline_pin(struct intel_timeline *tl)
 {
int err;
 
-   if (tl->pin_count++)
+   if (atomic_add_unless(>pin_count, 1, 0))
return 0;
-   GEM_BUG_ON(!tl->pin_count);
-   GEM_BUG_ON(tl->active_count);
 
err = i915_vma_pin(tl->hwsp_ggtt, 0, 0, PIN_GLOBAL | PIN_HIGH);
if (err)
-   goto unpin;
+   return err;
 
tl->hwsp_offset =
i915_ggtt_offset(tl->hwsp_ggtt) +
offset_in_page(tl->hwsp_offset);
 
cacheline_acquire(tl->hwsp_cacheline);
+   if (atomic_fetch_inc(>pin_count)) {
+   cacheline_release(tl->hwsp_cacheline);
+   __i915_vma_unpin(tl->hwsp_ggtt);
+   }
 
return 0;
-
-unpin:
-   tl->pin_count = 0;
-   return err;
 }
 
 void intel_timeline_enter(struct intel_timeline *tl)
 {
struct intel_gt_timelines *timelines = >gt->timelines;
 
-   GEM_BUG_ON(!tl->pin_count);
+   GEM_BUG_ON(!atomic_read(>pin_count));
if (tl->active_count++)
return;
GEM_BUG_ON(!tl->active_count); /* overflow? */
@@ -372,7 +370,7 @@ void intel_timeline_exit(struct intel_timeline *tl)
 
 static u32 timeline_advance(struct intel_timeline *tl)
 {
-   GEM_BUG_ON(!tl->pin_count);
+   GEM_BUG_ON(!atomic_read(>pin_count));
GEM_BUG_ON(tl->seqno & tl->has_initial_breadcrumb);
 
return tl->seqno += 1 + tl->has_initial_breadcrumb;
@@ -523,11 +521,10 @@ int intel_timeline_read_hwsp(struct i915_request *from,
 
 void intel_timeline_unpin(struct intel_timeline *tl)
 {
-   GEM_BUG_ON(!tl->pin_count);
-   if (--tl->pin_count)
+   GEM_BUG_ON(!atomic_read(>pin_count));
+   if (!atomic_dec_and_test(>pin_count))
return;
 
-   GEM_BUG_ON(tl->active_count);
cacheline_release(tl->hwsp_cacheline);
 
__i915_vma_unpin(tl->hwsp_ggtt);
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline_types.h 
b/drivers/gpu/drm/i915/gt/intel_timeline_types.h
index b1a9f0c54bf0..2b1baf2fcc8e 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_timeline_types.h
@@ -41,7 +41,7 @@ struct intel_timeline {
 * but the pin_count is protected by a combination of serialisation
 * from the intel_context caller plus internal atomicity.
 */
-   unsigned int pin_count;
+   atomic_t pin_count;
unsigned int active_count;
 
const u32 *hwsp_seqno;
diff --git a/drivers/gpu/drm/i915/gt/mock_engine.c 
b/drivers/gpu/drm/i915/gt/mock_engine.c
index a63dd8a42cd4..54a11dde3076 100644
--- a/drivers/gpu/drm/i915/gt/mock_engine.c
+++ b/drivers/gpu/drm/i915/gt/mock_engine.c
@@ -34,13 +34,13 @@
 
 static void mock_timeline_pin(struct intel_timeline *tl)
 {
-   tl->pin_count++;
+   atomic_inc(>pin_count);
 }
 
 static void mock_timeline_unpin(struct intel_timeline *tl)
 {
-   GEM_BUG_ON(!tl->pin_count);
-   tl->pin_count--;
+   GEM_BUG_ON(!atomic_read(>pin_count));
+   atomic_dec(>pin_count);
 }
 
 static struct intel_ring *mock_ring(struct intel_engine_cs *engine)
-- 
2.23.0.rc1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

[Intel-gfx] [CI 1/4] drm/i915/gt: Track timeline activeness in enter/exit

2019-08-15 Thread Chris Wilson
Lift moving the timeline to/from the active_list on enter/exit in order
to shorten the active tracking span in comparison to the existing
pin/unpin.

Signed-off-by: Chris Wilson 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/gem/i915_gem_pm.c|  1 -
 drivers/gpu/drm/i915/gt/intel_context.c   |  2 +
 drivers/gpu/drm/i915/gt/intel_engine_pm.c |  2 +
 drivers/gpu/drm/i915/gt/intel_lrc.c   |  4 +
 drivers/gpu/drm/i915/gt/intel_timeline.c  | 98 +++
 drivers/gpu/drm/i915/gt/intel_timeline.h  |  3 +-
 .../gpu/drm/i915/gt/intel_timeline_types.h| 18 
 drivers/gpu/drm/i915/gt/selftest_timeline.c   |  2 -
 8 files changed, 64 insertions(+), 66 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 17e3618241c5..92e53c25424c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -37,7 +37,6 @@ static void i915_gem_park(struct drm_i915_private *i915)
for_each_engine(engine, i915, id)
call_idle_barriers(engine); /* cleanup after wedging */
 
-   intel_timelines_park(i915);
i915_vma_parked(i915);
 
i915_globals_park();
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index 77833f1558a9..9114953bf920 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -280,10 +280,12 @@ int __init i915_global_context_init(void)
 void intel_context_enter_engine(struct intel_context *ce)
 {
intel_engine_pm_get(ce->engine);
+   intel_timeline_enter(ce->timeline);
 }
 
 void intel_context_exit_engine(struct intel_context *ce)
 {
+   intel_timeline_exit(ce->timeline);
intel_engine_pm_put(ce->engine);
 }
 
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c 
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 49ad02c3720f..f3f0109f9e22 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -66,6 +66,8 @@ static bool switch_to_kernel_context(struct intel_engine_cs 
*engine)
/* Context switch failed, hope for the best! Maybe reset? */
return true;
 
+   intel_timeline_enter(rq->timeline);
+
/* Check again on the next retirement. */
engine->wakeref_serial = engine->serial + 1;
i915_request_add_active_barriers(rq);
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index a5d9b902d6e3..b4c2662dbc75 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -3306,6 +3306,8 @@ static void virtual_context_enter(struct intel_context 
*ce)
 
for (n = 0; n < ve->num_siblings; n++)
intel_engine_pm_get(ve->siblings[n]);
+
+   intel_timeline_enter(ce->timeline);
 }
 
 static void virtual_context_exit(struct intel_context *ce)
@@ -3313,6 +3315,8 @@ static void virtual_context_exit(struct intel_context *ce)
struct virtual_engine *ve = container_of(ce, typeof(*ve), context);
unsigned int n;
 
+   intel_timeline_exit(ce->timeline);
+
for (n = 0; n < ve->num_siblings; n++)
intel_engine_pm_put(ve->siblings[n]);
 }
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c 
b/drivers/gpu/drm/i915/gt/intel_timeline.c
index 6daa9eb59e19..4af0b9801d91 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline.c
+++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
@@ -278,64 +278,11 @@ void intel_timelines_init(struct drm_i915_private *i915)
timelines_init(>gt);
 }
 
-static void timeline_add_to_active(struct intel_timeline *tl)
-{
-   struct intel_gt_timelines *gt = >gt->timelines;
-
-   mutex_lock(>mutex);
-   list_add(>link, >active_list);
-   mutex_unlock(>mutex);
-}
-
-static void timeline_remove_from_active(struct intel_timeline *tl)
-{
-   struct intel_gt_timelines *gt = >gt->timelines;
-
-   mutex_lock(>mutex);
-   list_del(>link);
-   mutex_unlock(>mutex);
-}
-
-static void timelines_park(struct intel_gt *gt)
-{
-   struct intel_gt_timelines *timelines = >timelines;
-   struct intel_timeline *timeline;
-
-   mutex_lock(>mutex);
-   list_for_each_entry(timeline, >active_list, link) {
-   /*
-* All known fences are completed so we can scrap
-* the current sync point tracking and start afresh,
-* any attempt to wait upon a previous sync point
-* will be skipped as the fence was signaled.
-*/
-   i915_syncmap_free(>sync);
-   }
-   mutex_unlock(>mutex);
-}
-
-/**
- * intel_timelines_park - called when the driver idles
- * @i915: the drm_i915_private device
- *
- * When the driver is completely idle, we know that all of our sync points
- * have been signaled and our tracking is then entirely redundant. Any request
- * to wait upon an older 

[Intel-gfx] [CI 2/4] drm/i915/gt: Convert timeline tracking to spinlock

2019-08-15 Thread Chris Wilson
Convert the active_list manipulation of timelines to use spinlocks so
that we can perform the updates from underneath a quick interrupt
callback, if need be.

Signed-off-by: Chris Wilson 
Matthew Auld 
---
 drivers/gpu/drm/i915/gt/intel_gt_types.h |  2 +-
 drivers/gpu/drm/i915/gt/intel_reset.c| 10 --
 drivers/gpu/drm/i915/gt/intel_timeline.c | 12 +---
 drivers/gpu/drm/i915/i915_gem.c  | 14 +++---
 4 files changed, 21 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h 
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index adab4d2c29ac..143b2d78c2cc 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -40,7 +40,7 @@ struct intel_gt {
struct intel_uc uc;
 
struct intel_gt_timelines {
-   struct mutex mutex; /* protects list */
+   spinlock_t lock; /* protects active_list */
struct list_head active_list;
 
/* Pack multiple timelines' seqnos into the same page */
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c 
b/drivers/gpu/drm/i915/gt/intel_reset.c
index ec85740de942..077716442c90 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -811,7 +811,7 @@ static bool __intel_gt_unset_wedged(struct intel_gt *gt)
 *
 * No more can be submitted until we reset the wedged bit.
 */
-   mutex_lock(>mutex);
+   spin_lock(>lock);
list_for_each_entry(tl, >active_list, link) {
struct i915_request *rq;
 
@@ -819,6 +819,8 @@ static bool __intel_gt_unset_wedged(struct intel_gt *gt)
if (!rq)
continue;
 
+   spin_unlock(>lock);
+
/*
 * All internal dependencies (i915_requests) will have
 * been flushed by the set-wedge, but we may be stuck waiting
@@ -828,8 +830,12 @@ static bool __intel_gt_unset_wedged(struct intel_gt *gt)
 */
dma_fence_default_wait(>fence, false, MAX_SCHEDULE_TIMEOUT);
i915_request_put(rq);
+
+   /* Restart iteration after droping lock */
+   spin_lock(>lock);
+   tl = list_entry(>active_list, typeof(*tl), link);
}
-   mutex_unlock(>mutex);
+   spin_unlock(>lock);
 
intel_gt_sanitize(gt, false);
 
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c 
b/drivers/gpu/drm/i915/gt/intel_timeline.c
index 4af0b9801d91..355dfc52c804 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline.c
+++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
@@ -266,7 +266,7 @@ static void timelines_init(struct intel_gt *gt)
 {
struct intel_gt_timelines *timelines = >timelines;
 
-   mutex_init(>mutex);
+   spin_lock_init(>lock);
INIT_LIST_HEAD(>active_list);
 
spin_lock_init(>hwsp_lock);
@@ -345,9 +345,9 @@ void intel_timeline_enter(struct intel_timeline *tl)
return;
GEM_BUG_ON(!tl->active_count); /* overflow? */
 
-   mutex_lock(>mutex);
+   spin_lock(>lock);
list_add(>link, >active_list);
-   mutex_unlock(>mutex);
+   spin_unlock(>lock);
 }
 
 void intel_timeline_exit(struct intel_timeline *tl)
@@ -358,9 +358,9 @@ void intel_timeline_exit(struct intel_timeline *tl)
if (--tl->active_count)
return;
 
-   mutex_lock(>mutex);
+   spin_lock(>lock);
list_del(>link);
-   mutex_unlock(>mutex);
+   spin_unlock(>lock);
 
/*
 * Since this timeline is idle, all bariers upon which we were waiting
@@ -548,8 +548,6 @@ static void timelines_fini(struct intel_gt *gt)
 
GEM_BUG_ON(!list_empty(>active_list));
GEM_BUG_ON(!list_empty(>hwsp_free_list));
-
-   mutex_destroy(>mutex);
 }
 
 void intel_timelines_fini(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b4c39a06fee5..07da7d5f855a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -897,18 +897,18 @@ static long
 wait_for_timelines(struct drm_i915_private *i915,
   unsigned int flags, long timeout)
 {
-   struct intel_gt_timelines *gt = >gt.timelines;
+   struct intel_gt_timelines *timelines = >gt.timelines;
struct intel_timeline *tl;
 
-   mutex_lock(>mutex);
-   list_for_each_entry(tl, >active_list, link) {
+   spin_lock(>lock);
+   list_for_each_entry(tl, >active_list, link) {
struct i915_request *rq;
 
rq = i915_active_request_get_unlocked(>last_request);
if (!rq)
continue;
 
-   mutex_unlock(>mutex);
+   spin_unlock(>lock);
 
/*
 * "Race-to-idle".
@@ -928,10 +928,10 @@ wait_for_timelines(struct drm_i915_private *i915,
return timeout;
 
/* 

[Intel-gfx] [CI 4/4] drm/i915: Protect request retirement with timeline->mutex

2019-08-15 Thread Chris Wilson
Forgo the struct_mutex requirement for request retirement as we have
been transitioning over to only using the timeline->mutex for
controlling the lifetime of a request on that timeline.

Signed-off-by: Chris Wilson 
Reviewed-by: Matthew Auld 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 183 ++
 drivers/gpu/drm/i915/gt/intel_context.h   |  18 +-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |   1 -
 drivers/gpu/drm/i915/gt/intel_engine_types.h  |   3 -
 drivers/gpu/drm/i915/gt/intel_gt.c|   2 -
 drivers/gpu/drm/i915/gt/intel_gt_types.h  |   2 -
 drivers/gpu/drm/i915/gt/intel_lrc.c   |   1 +
 drivers/gpu/drm/i915/gt/intel_ringbuffer.c|  19 +-
 drivers/gpu/drm/i915/gt/mock_engine.c |   1 -
 drivers/gpu/drm/i915/gt/selftest_context.c|   9 +-
 drivers/gpu/drm/i915/i915_request.c   | 156 +++
 drivers/gpu/drm/i915/i915_request.h   |   3 -
 12 files changed, 209 insertions(+), 189 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 91512cc6d7a6..1263b02011f4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -735,63 +735,6 @@ static int eb_select_context(struct i915_execbuffer *eb)
return 0;
 }
 
-static struct i915_request *__eb_wait_for_ring(struct intel_ring *ring)
-{
-   struct i915_request *rq;
-
-   /*
-* Completely unscientific finger-in-the-air estimates for suitable
-* maximum user request size (to avoid blocking) and then backoff.
-*/
-   if (intel_ring_update_space(ring) >= PAGE_SIZE)
-   return NULL;
-
-   /*
-* Find a request that after waiting upon, there will be at least half
-* the ring available. The hysteresis allows us to compete for the
-* shared ring and should mean that we sleep less often prior to
-* claiming our resources, but not so long that the ring completely
-* drains before we can submit our next request.
-*/
-   list_for_each_entry(rq, >request_list, ring_link) {
-   if (__intel_ring_space(rq->postfix,
-  ring->emit, ring->size) > ring->size / 2)
-   break;
-   }
-   if (>ring_link == >request_list)
-   return NULL; /* weird, we will check again later for real */
-
-   return i915_request_get(rq);
-}
-
-static int eb_wait_for_ring(const struct i915_execbuffer *eb)
-{
-   struct i915_request *rq;
-   int ret = 0;
-
-   /*
-* Apply a light amount of backpressure to prevent excessive hogs
-* from blocking waiting for space whilst holding struct_mutex and
-* keeping all of their resources pinned.
-*/
-
-   rq = __eb_wait_for_ring(eb->context->ring);
-   if (rq) {
-   mutex_unlock(>i915->drm.struct_mutex);
-
-   if (i915_request_wait(rq,
- I915_WAIT_INTERRUPTIBLE,
- MAX_SCHEDULE_TIMEOUT) < 0)
-   ret = -EINTR;
-
-   i915_request_put(rq);
-
-   mutex_lock(>i915->drm.struct_mutex);
-   }
-
-   return ret;
-}
-
 static int eb_lookup_vmas(struct i915_execbuffer *eb)
 {
struct radix_tree_root *handles_vma = >gem_context->handles_vma;
@@ -2132,10 +2075,75 @@ static const enum intel_engine_id user_ring_map[] = {
[I915_EXEC_VEBOX]   = VECS0
 };
 
-static int eb_pin_context(struct i915_execbuffer *eb, struct intel_context *ce)
+static struct i915_request *eb_throttle(struct intel_context *ce)
+{
+   struct intel_ring *ring = ce->ring;
+   struct intel_timeline *tl = ce->timeline;
+   struct i915_request *rq;
+
+   /*
+* Completely unscientific finger-in-the-air estimates for suitable
+* maximum user request size (to avoid blocking) and then backoff.
+*/
+   if (intel_ring_update_space(ring) >= PAGE_SIZE)
+   return NULL;
+
+   /*
+* Find a request that after waiting upon, there will be at least half
+* the ring available. The hysteresis allows us to compete for the
+* shared ring and should mean that we sleep less often prior to
+* claiming our resources, but not so long that the ring completely
+* drains before we can submit our next request.
+*/
+   list_for_each_entry(rq, >requests, link) {
+   if (rq->ring != ring)
+   continue;
+
+   if (__intel_ring_space(rq->postfix,
+  ring->emit, ring->size) > ring->size / 2)
+   break;
+   }
+   if (>link == >requests)
+   return NULL; /* weird, we will check again later for real */
+
+   return i915_request_get(rq);
+}
+
+static int
+__eb_pin_context(struct 

[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "ALSA: hda: Add codec on bus address table lately"

2019-08-15 Thread Patchwork
== Series Details ==

Series: Revert "ALSA: hda: Add codec on bus address table lately"
URL   : https://patchwork.freedesktop.org/series/65271/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6712 -> Patchwork_14036


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14036/

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_14036:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@kms_chamelium@hdmi-hpd-fast:
- {fi-icl-u4}:[FAIL][1] ([fdo#111045]) -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-icl-u4/igt@kms_chamel...@hdmi-hpd-fast.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14036/fi-icl-u4/igt@kms_chamel...@hdmi-hpd-fast.html

  
Known issues


  Here are the changes found in Patchwork_14036 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@kms_busy@basic-flip-c:
- fi-skl-6770hq:  [PASS][3] -> [SKIP][4] ([fdo#109271] / [fdo#109278]) 
+2 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-skl-6770hq/igt@kms_b...@basic-flip-c.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14036/fi-skl-6770hq/igt@kms_b...@basic-flip-c.html

  * igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6770hq:  [PASS][5] -> [SKIP][6] ([fdo#109271]) +23 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14036/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html

  * igt@prime_vgem@basic-busy-default:
- fi-icl-u3:  [PASS][7] -> [DMESG-WARN][8] ([fdo#107724]) +2 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-icl-u3/igt@prime_v...@basic-busy-default.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14036/fi-icl-u3/igt@prime_v...@basic-busy-default.html

  
 Possible fixes 

  * igt@gem_ctx_switch@rcs0:
- {fi-icl-guc}:   [INCOMPLETE][9] ([fdo#107713]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-icl-guc/igt@gem_ctx_swi...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14036/fi-icl-guc/igt@gem_ctx_swi...@rcs0.html

  * igt@i915_module_load@reload:
- fi-kbl-8809g:   [INCOMPLETE][11] ([fdo#103665]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-kbl-8809g/igt@i915_module_l...@reload.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14036/fi-kbl-8809g/igt@i915_module_l...@reload.html
- fi-blb-e6850:   [INCOMPLETE][13] ([fdo#107718]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-blb-e6850/igt@i915_module_l...@reload.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14036/fi-blb-e6850/igt@i915_module_l...@reload.html
- fi-byt-j1900:   [INCOMPLETE][15] ([fdo#102657]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-byt-j1900/igt@i915_module_l...@reload.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14036/fi-byt-j1900/igt@i915_module_l...@reload.html
- fi-kbl-r:   [INCOMPLETE][17] -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-kbl-r/igt@i915_module_l...@reload.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14036/fi-kbl-r/igt@i915_module_l...@reload.html
- fi-apl-guc: [INCOMPLETE][19] ([fdo#103927]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-apl-guc/igt@i915_module_l...@reload.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14036/fi-apl-guc/igt@i915_module_l...@reload.html
- {fi-icl-dsi}:   [INCOMPLETE][21] ([fdo#107713]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-icl-dsi/igt@i915_module_l...@reload.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14036/fi-icl-dsi/igt@i915_module_l...@reload.html
- fi-whl-u:   [INCOMPLETE][23] -> [PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-whl-u/igt@i915_module_l...@reload.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14036/fi-whl-u/igt@i915_module_l...@reload.html
- fi-pnv-d510:[INCOMPLETE][25] ([fdo#110740]) -> [PASS][26]
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-pnv-d510/igt@i915_module_l...@reload.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14036/fi-pnv-d510/igt@i915_module_l...@reload.html
- fi-skl-6600u:   [INCOMPLETE][27] ([fdo#104108] / [k.org#204565]) -> 
[PASS][28]
   [27]: 

Re: [Intel-gfx] [PATCH v3 hmm 08/11] drm/radeon: use mmu_notifier_get/put for struct radeon_mn

2019-08-15 Thread Jason Gunthorpe
On Thu, Aug 15, 2019 at 10:28:21AM +0200, Christian König wrote:
> Am 07.08.19 um 01:15 schrieb Jason Gunthorpe:
> > From: Jason Gunthorpe 
> > 
> > radeon is using a device global hash table to track what mmu_notifiers
> > have been registered on struct mm. This is better served with the new
> > get/put scheme instead.
> > 
> > radeon has a bug where it was not blocking notifier release() until all
> > the BO's had been invalidated. This could result in a use after free of
> > pages the BOs. This is tied into a second bug where radeon left the
> > notifiers running endlessly even once the interval tree became
> > empty. This could result in a use after free with module unload.
> > 
> > Both are fixed by changing the lifetime model, the BOs exist in the
> > interval tree with their natural lifetimes independent of the mm_struct
> > lifetime using the get/put scheme. The release runs synchronously and just
> > does invalidate_start across the entire interval tree to create the
> > required DMA fence.
> > 
> > Additions to the interval tree after release are already impossible as
> > only current->mm is used during the add.
> > 
> > Signed-off-by: Jason Gunthorpe 
> 
> Acked-by: Christian König 

Thanks!

> But I'm wondering if we shouldn't completely drop radeon userptr support.
> It's just to buggy,

I would not object :)

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

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

2019-08-15 Thread Daniel Vetter
On Thu, Aug 15, 2019 at 10:27 PM Jason Gunthorpe  wrote:
> On Thu, Aug 15, 2019 at 10:16:43PM +0200, Daniel Vetter wrote:
> > So if someone can explain to me how that works with lockdep I can of
> > course implement it. But afaics that doesn't exist (I tried to explain
> > that somewhere else already), and I'm no really looking forward to
> > hacking also on lockdep for this little series.
>
> Hmm, kind of looks like it is done by calling preempt_disable()

Yup. That was v1, then came the suggestion that disabling preemption
is maybe not the best thing (the oom reaper could still run for a long
time comparatively, if it's cleaning out gigabytes of process memory
or what not, hence this dedicated debug infrastructure).

> Probably the debug option is CONFIG_DEBUG_PREEMPT, not lockdep?

CONFIG_DEBUG_ATOMIC_SLEEP. Like in my patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/8] drm/i915: Protect request retirement with timeline->mutex

2019-08-15 Thread Chris Wilson
Quoting Matthew Auld (2019-08-15 21:33:07)
> On Wed, 14 Aug 2019 at 10:28, Chris Wilson  wrote:
> >
> > Forgo the struct_mutex requirement for request retirement as we have
> > been transitioning over to only using the timeline->mutex for
> > controlling the lifetime of a request on that timeline.
> >
> > Signed-off-by: Chris Wilson 
> > ---
> >  .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 183 ++
> >  drivers/gpu/drm/i915/gt/intel_context.h   |  18 +-
> >  drivers/gpu/drm/i915/gt/intel_engine_cs.c |   1 -
> >  drivers/gpu/drm/i915/gt/intel_engine_types.h  |   3 -
> >  drivers/gpu/drm/i915/gt/intel_gt.c|   2 -
> >  drivers/gpu/drm/i915/gt/intel_gt_types.h  |   2 -
> >  drivers/gpu/drm/i915/gt/intel_lrc.c   |   1 +
> >  drivers/gpu/drm/i915/gt/intel_ringbuffer.c|  19 +-
> >  drivers/gpu/drm/i915/gt/mock_engine.c |   1 -
> >  drivers/gpu/drm/i915/gt/selftest_context.c|   9 +-
> >  drivers/gpu/drm/i915/i915_request.c   | 156 +++
> >  drivers/gpu/drm/i915/i915_request.h   |   3 -
> >  12 files changed, 209 insertions(+), 189 deletions(-)
> >
> 
> >  bool i915_retire_requests(struct drm_i915_private *i915)
> >  {
> > -   struct intel_ring *ring, *tmp;
> > +   struct intel_gt_timelines *timelines = >gt.timelines;
> > +   struct intel_timeline *tl, *tn;
> > +   LIST_HEAD(free);
> > +
> > +   spin_lock(>lock);
> > +   list_for_each_entry_safe(tl, tn, >active_list, link) {
> > +   if (!mutex_trylock(>mutex))
> > +   continue;
> >
> > -   lockdep_assert_held(>drm.struct_mutex);
> > +   intel_timeline_get(tl);
> > +   GEM_BUG_ON(!tl->active_count);
> > +   tl->active_count++; /* pin the list element */
> > +   spin_unlock(>lock);
> >
> > -   list_for_each_entry_safe(ring, tmp,
> > ->gt.active_rings, active_link) {
> > -   intel_ring_get(ring); /* last rq holds reference! */
> > -   ring_retire_requests(ring);
> > -   intel_ring_put(ring);
> > +   retire_requests(tl);
> > +
> > +   spin_lock(>lock);
> > +
> > +   /* Restart iteration after dropping lock */
> > +   list_safe_reset_next(tl, tn, link);
> 
> That's a new one.

I was quite chuffed with that loop, all the pinning across the lock
dropping to ensure the list stayed intact and we could resume from where
we left off.

And if all goes to plan, we should be rarely using this loop!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 7/8] drm/i915: Extract intel_frontbuffer active tracking

2019-08-15 Thread Matthew Auld
On Wed, 14 Aug 2019 at 10:27, Chris Wilson  wrote:
>
> Move the active tracking for the frontbuffer operations out of the
> i915_gem_object and into its own first class (refcounted) object. In the
> process of detangling, we switch from low level request tracking to the
> easier i915_active -- with the plan that this avoids any potential
> atomic callbacks as the frontbuffer tracking wishes to sleep as it
> flushes.
>
> Signed-off-by: Chris Wilson 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/8] drm/i915: Protect request retirement with timeline->mutex

2019-08-15 Thread Matthew Auld
On Wed, 14 Aug 2019 at 10:28, Chris Wilson  wrote:
>
> Forgo the struct_mutex requirement for request retirement as we have
> been transitioning over to only using the timeline->mutex for
> controlling the lifetime of a request on that timeline.
>
> Signed-off-by: Chris Wilson 
> ---
>  .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 183 ++
>  drivers/gpu/drm/i915/gt/intel_context.h   |  18 +-
>  drivers/gpu/drm/i915/gt/intel_engine_cs.c |   1 -
>  drivers/gpu/drm/i915/gt/intel_engine_types.h  |   3 -
>  drivers/gpu/drm/i915/gt/intel_gt.c|   2 -
>  drivers/gpu/drm/i915/gt/intel_gt_types.h  |   2 -
>  drivers/gpu/drm/i915/gt/intel_lrc.c   |   1 +
>  drivers/gpu/drm/i915/gt/intel_ringbuffer.c|  19 +-
>  drivers/gpu/drm/i915/gt/mock_engine.c |   1 -
>  drivers/gpu/drm/i915/gt/selftest_context.c|   9 +-
>  drivers/gpu/drm/i915/i915_request.c   | 156 +++
>  drivers/gpu/drm/i915/i915_request.h   |   3 -
>  12 files changed, 209 insertions(+), 189 deletions(-)
>

>  bool i915_retire_requests(struct drm_i915_private *i915)
>  {
> -   struct intel_ring *ring, *tmp;
> +   struct intel_gt_timelines *timelines = >gt.timelines;
> +   struct intel_timeline *tl, *tn;
> +   LIST_HEAD(free);
> +
> +   spin_lock(>lock);
> +   list_for_each_entry_safe(tl, tn, >active_list, link) {
> +   if (!mutex_trylock(>mutex))
> +   continue;
>
> -   lockdep_assert_held(>drm.struct_mutex);
> +   intel_timeline_get(tl);
> +   GEM_BUG_ON(!tl->active_count);
> +   tl->active_count++; /* pin the list element */
> +   spin_unlock(>lock);
>
> -   list_for_each_entry_safe(ring, tmp,
> ->gt.active_rings, active_link) {
> -   intel_ring_get(ring); /* last rq holds reference! */
> -   ring_retire_requests(ring);
> -   intel_ring_put(ring);
> +   retire_requests(tl);
> +
> +   spin_lock(>lock);
> +
> +   /* Restart iteration after dropping lock */
> +   list_safe_reset_next(tl, tn, link);

That's a new one.

"Several hours later",
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

2019-08-15 Thread Daniel Vetter
On Thu, Aug 15, 2019 at 9:35 PM Michal Hocko  wrote:
>
> On Thu 15-08-19 16:18:10, Jason Gunthorpe wrote:
> > On Thu, Aug 15, 2019 at 09:05:25PM +0200, Michal Hocko wrote:
> >
> > > This is what you claim and I am saying that fs_reclaim is about a
> > > restricted reclaim context and it is an ugly hack. It has proven to
> > > report false positives. Maybe it can be extended to a generic reclaim.
> > > I haven't tried that. Do not aim to try it.
> >
> > Okay, great, I think this has been very helpful, at least for me,
> > thanks. I did not know fs_reclaim was so problematic, or the special
> > cases about OOM 'reclaim'.
>
> I am happy that this is more clear now.
>
> > On this patch, I have no general objection to enforcing drivers to be
> > non-blocking, I'd just like to see it done with the existing lockdep
> > can't sleep detection rather than inventing some new debugging for it.
> >
> > I understand this means the debugging requires lockdep enabled and
> > will not run in production, but I'm of the view that is OK and in line
> > with general kernel practice.
>
> Yes and I do agree with this in general.

So if someone can explain to me how that works with lockdep I can of
course implement it. But afaics that doesn't exist (I tried to explain
that somewhere else already), and I'm no really looking forward to
hacking also on lockdep for this little series.

> > The last detail is I'm still unclear what a GFP flags a blockable
> > invalidate_range_start() should use. Is GFP_KERNEL OK?
>
> I hope I will not make this muddy again ;)
> invalidate_range_start in the blockable mode can use/depend on any sleepable
> allocation allowed in the context it is called from. So in other words
> it is no different from any other function in the kernel that calls into
> allocator. As the API is missing gfp context then I hope it is not
> called from any restricted contexts (except from the oom which we have
> !blockable for).

Hm, that's new to me. I thought mmu notifiers very much can be called
from direct reclaim paths, so you have to be extremely careful with
getting back into that one. At least the lockdep splats I remember
also tend to have fs_reclaim in there, that's where all the fun comes
from.

> > Lockdep has
> > complained on that in past due to fs_reclaim - how do you know if it
> > is a false positive?
>
> I would have to see the specific lockdep splat.

I guess the lockdep annotation for invalidate_range_start carries the
same risks as the fs_reclaim annotation. Still feels like worth it.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] Revert "ALSA: hda: Add codec on bus address table lately"

2019-08-15 Thread Takashi Iwai
This reverts commit ee5f85d9290f ("ALSA: hda: Add codec on bus address
table lately").  The commit caused several regression since I've
overlooked that the function doesn't manage only the caddr_tbl but
also the codec linked list that is referred indirectly in the other
drivers.

Revert for now to make everything back to work.

Fixes: ee5f85d9290f ("ALSA: hda: Add codec on bus address table lately")
Reported-by: Chris Wilson 
Signed-off-by: Takashi Iwai 
---
 sound/hda/hdac_device.c | 21 +
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/sound/hda/hdac_device.c b/sound/hda/hdac_device.c
index bf83d7062ef6..9f3e37511408 100644
--- a/sound/hda/hdac_device.c
+++ b/sound/hda/hdac_device.c
@@ -61,6 +61,10 @@ int snd_hdac_device_init(struct hdac_device *codec, struct 
hdac_bus *bus,
pm_runtime_get_noresume(>dev);
atomic_set(>in_pm, 0);
 
+   err = snd_hdac_bus_add_device(bus, codec);
+   if (err < 0)
+   goto error;
+
/* fill parameters */
codec->vendor_id = snd_hdac_read_parm(codec, AC_NODE_ROOT,
  AC_PAR_VENDOR_ID);
@@ -139,22 +143,15 @@ int snd_hdac_device_register(struct hdac_device *codec)
err = device_add(>dev);
if (err < 0)
return err;
-   err = snd_hdac_bus_add_device(codec->bus, codec);
-   if (err < 0)
-   goto error;
mutex_lock(>widget_lock);
err = hda_widget_sysfs_init(codec);
mutex_unlock(>widget_lock);
-   if (err < 0)
-   goto error_remove;
+   if (err < 0) {
+   device_del(>dev);
+   return err;
+   }
 
return 0;
-
- error_remove:
-   snd_hdac_bus_remove_device(codec->bus, codec);
- error:
-   device_del(>dev);
-   return err;
 }
 EXPORT_SYMBOL_GPL(snd_hdac_device_register);
 
@@ -168,8 +165,8 @@ void snd_hdac_device_unregister(struct hdac_device *codec)
mutex_lock(>widget_lock);
hda_widget_sysfs_exit(codec);
mutex_unlock(>widget_lock);
-   snd_hdac_bus_remove_device(codec->bus, codec);
device_del(>dev);
+   snd_hdac_bus_remove_device(codec->bus, codec);
}
 }
 EXPORT_SYMBOL_GPL(snd_hdac_device_unregister);
-- 
2.16.4

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

Re: [Intel-gfx] [PATCH 4/8] drm/i915/gt: Guard timeline pinning with its own mutex

2019-08-15 Thread Chris Wilson
Quoting Matthew Auld (2019-08-15 20:19:58)
> On Wed, 14 Aug 2019 at 10:28, Chris Wilson  wrote:
> >
> > In preparation for removing struct_mutex from around context retirement,
> > we need to make timeline pinning safe. Since multiple engines/contexts
> > can share a single timeline, it needs to be protected by a mutex.
> >
> > Signed-off-by: Chris Wilson 
> 
> With a more accurate commit message,
> Reviewed-by: Matthew Auld 

Cruel.

In preparation for removing struct_mutex from around context retirement,
we need to make timeline pinning and unpinning safe. Since multiple
engines/contexts can share a single timeline, we cannot rely on
borrowing the context mutex (otherwise we could state that the timeline
is only pinned/unpinned inside the context pin/unpin and so guarded by
it). However, we only perform a sequence of atomic operations inside the
timeline pin/unpin and the sequence of those operations is safe for a
concurrent unpin / pin, so we can relax the struct_mutex requirement.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] Revert "ALSA: hda - Drop unsol event handler for Intel HDMI codecs"

2019-08-15 Thread Takashi Iwai
On Thu, 15 Aug 2019 20:15:51 +0200,
Chris Wilson wrote:
> 
> In the recent snd merge of
> 
> ddf7cb83b0f4 ALSA: hda: Unexport a few more stuff
> 53eff75e5f4d ALSA: hda: Drop export of snd_hdac_bus_add/remove_device()
> ee5f85d9290f ALSA: hda: Add codec on bus address table lately
> f2dbe87c5ac1 ALSA: hda - Drop unsol event handler for Intel HDMI codecs
> 
> module unload dies on all a couple of machines with
> 
> <1> [281.912684] BUG: kernel NULL pointer dereference, address: 
> 
> <1> [281.912697] #PF: supervisor read access in kernel mode
> <1> [281.912703] #PF: error_code(0x) - not-present page
> <6> [281.912709] PGD 0 P4D 0
> <4> [281.912714] Oops:  [#1] PREEMPT SMP PTI
> <4> [281.912721] CPU: 3 PID: 2842 Comm: i915_module_loa Tainted: G U  
>   5.3.0-rc4-CI-CI_DRM_6712+ #1
> <4> [281.912730] Hardware name: Hewlett-Packard HP EliteBook 8440p/172A, BIOS 
> 68CCU Ver. F.24 09/13/2013
> <4> [281.912744] RIP: 0010:__list_del_entry_valid+0x25/0x90
> <4> [281.912751] Code: c3 0f 1f 40 00 48 8b 07 48 b9 00 01 00 00 00 00 ad de 
> 48 8b 57 08 48 39 c8 74 26 48 b9 22 01 00 00 00 00 ad de 48 39 ca 74 2e <48> 
> 8b 32 48 39 fe 75 3a 48 8b 50 08 48 39 f2 75 48 b8 01 00 00 00
> <4> [281.912767] RSP: 0018:c972bca8 EFLAGS: 00010217
> <4> [281.912774] RAX:  RBX: 88812f8933f8 RCX: 
> dead0122
> <4> [281.912782] RDX:  RSI: 88812f8933f8 RDI: 
> 88812f8938a8
> <4> [281.912789] RBP: 88812e7ce7e8 R08:  R09: 
> 
> <4> [281.912796] R10:  R11:  R12: 
> 88812f8938a8
> <4> [281.912803] R13: 88812c8722a8 R14: c972bf08 R15: 
> 888129761df8
> <4> [281.912811] FS:  7fb4913a9e40() GS:888133b8() 
> knlGS:
> <4> [281.912819] CS:  0010 DS:  ES:  CR0: 80050033
> <4> [281.912826] CR2:  CR3: 00012867a000 CR4: 
> 06e0
> <4> [281.912833] Call Trace:
> <4> [281.912844]  snd_hdac_bus_remove_device+0x2e/0xb0 [snd_hda_core]
> <4> [281.912854]  snd_hdac_device_exit+0x31/0x60 [snd_hda_core]
> <4> [281.912866]  snd_hda_codec_dev_release+0x24/0x50 [snd_hda_codec]
> <4> [281.912876]  device_release+0x22/0x80
> <4> [281.912883]  kobject_put+0x86/0x1b0
> <4> [281.912891]  snd_hda_codec_dev_free+0x5c/0x60 [snd_hda_codec]
> <4> [281.912899]  __snd_device_free+0x4a/0x80
> <4> [281.912904]  snd_device_free_all+0x36/0x90
> <4> [281.912911]  release_card_device+0x14/0x60
> <4> [281.912917]  device_release+0x22/0x80
> <4> [281.912923]  kobject_put+0x86/0x1b0
> <4> [281.912928]  snd_card_free+0x60/0x90
> <4> [281.912939]  pci_device_remove+0x36/0xb0
> <4> [281.912946]  device_release_driver_internal+0xd3/0x1b0
> <4> [281.912953]  unbind_store+0xc3/0x120
> <4> [281.912962]  kernfs_fop_write+0x104/0x190
> <4> [281.912971]  vfs_write+0xbd/0x1d0
> <4> [281.912977]  ksys_write+0x8f/0xe0
> <4> [281.912984]  do_syscall_64+0x55/0x1c0
> 
> Cc: Takashi Iwai 

Gah, that's a breakage by the commit ee5f85d9290f ("ALSA: hda: Add
codec on bus address table lately").  Please revert it in your tree,
I'll do it same on sound git tree now.


thanks,

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

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

2019-08-15 Thread Michal Hocko
On Thu 15-08-19 16:18:10, Jason Gunthorpe wrote:
> On Thu, Aug 15, 2019 at 09:05:25PM +0200, Michal Hocko wrote:
> 
> > This is what you claim and I am saying that fs_reclaim is about a
> > restricted reclaim context and it is an ugly hack. It has proven to
> > report false positives. Maybe it can be extended to a generic reclaim.
> > I haven't tried that. Do not aim to try it.
> 
> Okay, great, I think this has been very helpful, at least for me,
> thanks. I did not know fs_reclaim was so problematic, or the special
> cases about OOM 'reclaim'. 

I am happy that this is more clear now.

> On this patch, I have no general objection to enforcing drivers to be
> non-blocking, I'd just like to see it done with the existing lockdep
> can't sleep detection rather than inventing some new debugging for it.
> 
> I understand this means the debugging requires lockdep enabled and
> will not run in production, but I'm of the view that is OK and in line
> with general kernel practice.

Yes and I do agree with this in general.

> The last detail is I'm still unclear what a GFP flags a blockable
> invalidate_range_start() should use. Is GFP_KERNEL OK?

I hope I will not make this muddy again ;)
invalidate_range_start in the blockable mode can use/depend on any sleepable
allocation allowed in the context it is called from. So in other words
it is no different from any other function in the kernel that calls into
allocator. As the API is missing gfp context then I hope it is not
called from any restricted contexts (except from the oom which we have
!blockable for).

> Lockdep has
> complained on that in past due to fs_reclaim - how do you know if it
> is a false positive?

I would have to see the specific lockdep splat.
-- 
Michal Hocko
SUSE Labs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] RFC: drm/i915: Switch obj->mm.lock lockdep annotations on its head

2019-08-15 Thread Tang, CQ


> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Daniel Vetter
> Sent: Wednesday, August 14, 2019 12:25 PM
> To: Intel Graphics Development 
> Cc: Daniel Vetter ; Vetter, Daniel
> 
> Subject: [Intel-gfx] [PATCH] RFC: drm/i915: Switch obj->mm.lock lockdep
> annotations on its head
> 
> The trouble with having a plain nesting flag for locks which do not naturally
> nest (unlike block devices and their partitions, which is the original 
> motivation
> for nesting levels) is that lockdep will never spot a true deadlock if you 
> screw
> up.
> 
> This patch is an attempt at trying better, by highlighting a bit more the 
> actual
> nature of the nesting that's going on. Essentially we have two kinds of
> objects:
> 
> - objects without pages allocated, which cannot be on any lru and are
>   hence inaccessible to the shrinker.
> 
> - objects which have pages allocated, which are on an lru, and which
>   the shrinker can decide to throw out.
> 
> For the former type of object, memory allcoations while holding
> obj->mm.lock are permissible. For the latter they are not. And
> get/put_pages transitions between the two types of objects.
> 
> This is still not entirely fool-proof since the rules might chance.
> But as long as we run such a code ever at runtime lockdep should be able to
> observe the inconsistency and complain (like with any other lockdep class
> that we've split up in multiple classes). But there are a few clear benefits:
> 
> - We can drop the nesting flag parameter from
>   __i915_gem_object_put_pages, because that function by definition is
>   never going allocate memory, and calling it on an object which
>   doesn't have its pages allocated would be a bug.
> 
> - We strictly catch more bugs, since there's not only one place in the
>   entire tree which is annotated with the special class. All the
>   other places that had explicit lockdep nesting annotations we're now
>   going to leave up to lockdep again.
> 
> - Specifically this catches stuff like calling get_pages from
>   put_pages (which isn't really a good idea, if we can call put_pages
>   so could the shrinker). I've seen patches do exactly that.
> 
> Of course I fully expect CI will show me for the fool I am with this one here 
> :-)
> 
> v2: There can only be one (lockdep only has a cache for the first subclass, 
> not
> for deeper ones, and we don't want to make these locks even slower). Still
> separate enums for better documentation.
> 
> Real fix: don forget about phys objs and pin_map(), and fix the shrinker to
> have the right annotations ... silly me.
> 
> v3: Forgot usertptr too ...

I eventually looked this patch. My question is on the shrinking calling stack:

Pin_pages(A)-->get_page(A)-->lock(objA->mm.lock, 
I915_MM_GET_PAGES)-->i915_gem_shrink()-->
Lock(struct_mutex)-->put_pages(B)-->lock(objB->mm.lock)

objA is locked with: mutex_lock_interruptible_nested(>mm.lock, 
I915_MM_GET_PAGES);

objB is locked with: mutex_lock(>mm.lock);
My understanding is that objB locking is equivalently to:
mutex_lock_nested(>mm.lock, I915_MM_NORMAL);

so you lock subclass=2 first on A, then lock subclass=0 next B, the reverse 
order.
Doesn't this cause a lockdep warning?   

--CQ


> 
> Cc: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Joonas Lahtinen 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_object.c   |  2 +-
>  drivers/gpu/drm/i915/gem/i915_gem_object.h   | 16 +---
>  drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 10 +-
>  drivers/gpu/drm/i915/gem/i915_gem_pages.c|  9 -
>  drivers/gpu/drm/i915/gem/i915_gem_phys.c |  2 +-
>  drivers/gpu/drm/i915/gem/i915_gem_shrinker.c |  5 ++---
>  drivers/gpu/drm/i915/gem/i915_gem_userptr.c  |  4 ++--
>  drivers/gpu/drm/i915/gem/selftests/huge_pages.c  | 12 ++--
>  8 files changed, 38 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> index 3929c3a6b281..a1a835539e09 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> @@ -191,7 +191,7 @@ static void __i915_gem_free_objects(struct
> drm_i915_private *i915,
>   GEM_BUG_ON(!list_empty(>lut_list));
> 
>   atomic_set(>mm.pages_pin_count, 0);
> - __i915_gem_object_put_pages(obj, I915_MM_NORMAL);
> + __i915_gem_object_put_pages(obj);
>   GEM_BUG_ON(i915_gem_object_has_pages(obj));
>   bitmap_free(obj->bit_17);
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> index 3714cf234d64..5ce511ca7fa8 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> @@ -281,11 +281,21 @@ i915_gem_object_unpin_pages(struct
> drm_i915_gem_object *obj)
> 
>  enum i915_mm_subclass { /* 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove i915 ggtt WA since GT E0 (rev3)

2019-08-15 Thread Patchwork
== Series Details ==

Series: drm/i915: Remove i915 ggtt WA since GT E0 (rev3)
URL   : https://patchwork.freedesktop.org/series/65160/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6710_full -> Patchwork_14021_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_14021_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110854])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb2/igt@gem_exec_balan...@smoke.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14021/shard-iclb6/igt@gem_exec_balan...@smoke.html

  * igt@gem_exec_reloc@basic-wc-active:
- shard-skl:  [PASS][3] -> [DMESG-WARN][4] ([fdo#106107])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-skl2/igt@gem_exec_re...@basic-wc-active.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14021/shard-skl9/igt@gem_exec_re...@basic-wc-active.html

  * igt@gem_exec_schedule@preempt-queue-bsd:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#111325])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb3/igt@gem_exec_sched...@preempt-queue-bsd.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14021/shard-iclb1/igt@gem_exec_sched...@preempt-queue-bsd.html

  * igt@gem_tiled_swapping@non-threaded:
- shard-apl:  [PASS][7] -> [DMESG-WARN][8] ([fdo#108686])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-apl1/igt@gem_tiled_swapp...@non-threaded.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14021/shard-apl4/igt@gem_tiled_swapp...@non-threaded.html

  * igt@i915_pm_rpm@dpms-mode-unset-lpsp:
- shard-iclb: [PASS][9] -> [INCOMPLETE][10] ([fdo#107713] / 
[fdo#108840])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb5/igt@i915_pm_...@dpms-mode-unset-lpsp.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14021/shard-iclb1/igt@i915_pm_...@dpms-mode-unset-lpsp.html

  * igt@kms_flip@2x-plain-flip-fb-recreate:
- shard-glk:  [PASS][11] -> [FAIL][12] ([fdo#100368])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-glk8/igt@kms_f...@2x-plain-flip-fb-recreate.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14021/shard-glk3/igt@kms_f...@2x-plain-flip-fb-recreate.html

  * igt@kms_flip@dpms-vs-vblank-race-interruptible:
- shard-glk:  [PASS][13] -> [FAIL][14] ([fdo#103060])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-glk6/igt@kms_f...@dpms-vs-vblank-race-interruptible.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14021/shard-glk9/igt@kms_f...@dpms-vs-vblank-race-interruptible.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl:  [PASS][15] -> [FAIL][16] ([fdo#105363])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-skl3/igt@kms_f...@flip-vs-expired-vblank-interruptible.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14021/shard-skl1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
- shard-kbl:  [PASS][17] -> [INCOMPLETE][18] ([fdo#103665])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-kbl3/igt@kms_f...@flip-vs-suspend-interruptible.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14021/shard-kbl7/igt@kms_f...@flip-vs-suspend-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw:
- shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +4 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14021/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-apl:  [PASS][21] -> [DMESG-WARN][22] ([fdo#108566]) +3 
similar issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-apl3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14021/shard-apl5/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes:
- shard-iclb: [PASS][23] -> [INCOMPLETE][24] ([fdo#107713] / 
[fdo#110042])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb8/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html
   [24]: 

Re: [Intel-gfx] [PATCH 5/4] dma-fence: Have dma_fence_signal call signal_locked

2019-08-15 Thread Chris Wilson
Quoting Chris Wilson (2019-08-15 20:03:13)
> Quoting Daniel Vetter (2019-08-15 19:48:42)
> > On Thu, Aug 15, 2019 at 8:46 PM Chris Wilson  
> > wrote:
> > > Quoting Daniel Vetter (2019-08-14 18:20:53)
> > > > On Sun, Aug 11, 2019 at 10:15:23AM +0100, Chris Wilson wrote:
> > > > > Now that dma_fence_signal always takes the spinlock to flush the
> > > > > cb_list, simply take the spinlock and call dma_fence_signal_locked() 
> > > > > to
> > > > > avoid code repetition.
> > > > >
> > > > > Suggested-by: Christian König 
> > > > > Signed-off-by: Chris Wilson 
> > > > > Cc: Christian König 
> > > >
> > > > Hm, I think this largely defeats the point of having the lockless signal
> > > > enabling trickery in dma_fence. Maybe that part isn't needed by anyone,
> > > > but feels like a thing that needs a notch more thought. And if we need 
> > > > it,
> > > > maybe a bit more cleanup.
> > >
> > > You mean dma_fence_enable_sw_signaling(). The only user appears to be to
> > > flush fences, which is actually the intent of always notifying the signal
> > > cb. By always doing the callbacks, we can avoid installing the interrupt
> > > and completely saturating CPUs with irqs, instead doing a batch in a
> > > leisurely timer callback if not flushed naturally.
> > 
> > Yeah I'm not against ditching this,
> 
> I was just thinking aloud working out what the current use case in ttm
> was for.
> 
> > but can't we ditch a lot more if
> > we just always take the spinlock in those paths now anyways? Kinda not
> > worth having the complexity anymore.
> 
> You would be able to drop the was_set from dma_fence_add_callback. Say
> 
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 59ac96ec7ba8..e566445134a2 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -345,38 +345,31 @@ int dma_fence_add_callback(struct dma_fence *fence, 
> struct dma_fence_cb *cb,
>dma_fence_func_t func)
>  {
> unsigned long flags;
> -   int ret = 0;
> -   bool was_set;
> +   int ret = -ENOENT;
> 
> if (WARN_ON(!fence || !func))
> return -EINVAL;
> 
> -   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags)) {
> -   INIT_LIST_HEAD(>node);
> +   INIT_LIST_HEAD(>node);
> +   cb->func = func;
> +
> +   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
> return -ENOENT;
> -   }
> 
> spin_lock_irqsave(fence->lock, flags);
> -
> -   was_set = test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
> -  >flags);
> -
> -   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
> -   ret = -ENOENT;
> -   else if (!was_set && fence->ops->enable_signaling) {
> +   if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags) &&
> +   !test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
> + >flags)) {
> trace_dma_fence_enable_signal(fence);
> 
> -   if (!fence->ops->enable_signaling(fence)) {
> +   if (!fence->ops->enable_signaling ||
> +   fence->ops->enable_signaling(fence)) {
> +   list_add_tail(>node, >cb_list);
> +   ret = 0;
> +   } else {
> dma_fence_signal_locked(fence);
> -   ret = -ENOENT;
> }
> }
> -
> -   if (!ret) {
> -   cb->func = func;
> -   list_add_tail(>node, >cb_list);
> -   } else
> -   INIT_LIST_HEAD(>node);
> spin_unlock_irqrestore(fence->lock, flags);
> 
> return ret;
> 
> Not a whole lot changes in terms of branches and serialising
> instructions. One less baffling sequence to worry about.

Fwiw,
Function old new   delta
dma_fence_add_callback   338 302 -36

Almost certainly more shaving if you stare.
-Chris
___
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 [v5] dma-fence: Propagate errors to dma-fence-array container (rev7)

2019-08-15 Thread Patchwork
== Series Details ==

Series: series starting with [v5] dma-fence: Propagate errors to 
dma-fence-array container (rev7)
URL   : https://patchwork.freedesktop.org/series/65027/
State : failure

== Summary ==

Applying: dma-fence: Propagate errors to dma-fence-array container
Using index info to reconstruct a base tree...
M   drivers/dma-buf/dma-fence-array.c
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.
Applying: dma-fence: Report the composite sync_file status
Using index info to reconstruct a base tree...
M   drivers/dma-buf/sync_file.c
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.
Applying: dma-fence: Refactor signaling for manual invocation
Using index info to reconstruct a base tree...
M   drivers/dma-buf/Makefile
M   drivers/dma-buf/dma-fence.c
M   drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
M   include/linux/dma-fence.h
Falling back to patching base and 3-way merge...
Auto-merging include/linux/dma-fence.h
Auto-merging drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
Auto-merging drivers/dma-buf/dma-fence.c
Auto-merging drivers/dma-buf/Makefile
CONFLICT (content): Merge conflict in drivers/dma-buf/Makefile
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch' to see the failed patch
Patch failed at 0003 dma-fence: Refactor signaling for manual invocation
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

Re: [Intel-gfx] [PATCH 4/8] drm/i915/gt: Guard timeline pinning with its own mutex

2019-08-15 Thread Matthew Auld
On Wed, 14 Aug 2019 at 10:28, Chris Wilson  wrote:
>
> In preparation for removing struct_mutex from around context retirement,
> we need to make timeline pinning safe. Since multiple engines/contexts
> can share a single timeline, it needs to be protected by a mutex.
>
> Signed-off-by: Chris Wilson 

With a more accurate commit message,
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/tgl: Enabling DSC on Pipe A for TGL

2019-08-15 Thread Tolakanahalli Pradeep, Madhumitha
On Thu, 2019-08-15 at 11:53 -0700, Manasi Navare wrote:
> On Thu, Aug 15, 2019 at 11:39:54AM -0700, Tolakanahalli Pradeep,
> Madhumitha wrote:
> > On Thu, 2019-08-15 at 11:24 -0700, Manasi Navare wrote:
> > > On Wed, Aug 14, 2019 at 04:51:17PM -0700, Madhumitha
> > > Tolakanahalli
> > > Pradeep wrote:
> > > > Removing restriction on Pipe A as TigerLake onwards, all the
> > > > pipes
> > > > support DSC.
> > > 
> > > May be elaborate this commit message a little bit something like:
> > > "On previous platforms, DSC was not supported on Pipe A while
> > > starting TGL, its is supported
> > > on all pipes. So remove the DSC and FEC restriction on Pipe A for
> > > TGL
> > > onwards.
> > > 
> > 
> > Alright, will update that for rev2.
> > 
> > > > 
> > > > Cc: Manasi Navare 
> > > > Signed-off-by: Madhumitha Tolakanahalli Pradeep <
> > > > madhumitha.tolakanahalli.prad...@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_dp.c | 16 
> > > >  1 file changed, 12 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > index 4884c87c8ed7..a5b50f93fac5 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > @@ -1739,8 +1739,12 @@ static bool
> > > > intel_dp_source_supports_fec(struct intel_dp *intel_dp,
> > > >  {
> > > > struct drm_i915_private *dev_priv =
> > > > dp_to_i915(intel_dp);
> > > >  
> > > > -   return INTEL_GEN(dev_priv) >= 11 &&
> > > > -   pipe_config->cpu_transcoder != TRANSCODER_A;
> > > > +   /* On TGL, DSC is supported on all Pipes */
> > > 
> > > FEC supported on all pipes
> > 
> > Oops, will change this.
> > 
> > > > +   if (INTEL_GEN(dev_priv) >= 12)
> > > > +   return true;
> > > > +   else
> > > > +   return INTEL_GEN(dev_priv) == 11 &&
> 
> Also here I think its better to use IS_GEN(dev_priv, 11)

Yes, that does make it clearer, I'll change it for v2.

> 
> > > > +   pipe_config->cpu_transcoder !=
> > > > TRANSCODER_A;
> > > >  }
> > > >  
> > > >  static bool intel_dp_supports_fec(struct intel_dp *intel_dp,
> > > > @@ -1755,8 +1759,12 @@ static bool
> > > > intel_dp_source_supports_dsc(struct intel_dp *intel_dp,
> > > >  {
> > > > struct drm_i915_private *dev_priv =
> > > > dp_to_i915(intel_dp);
> > > >  
> > > > -   return INTEL_GEN(dev_priv) >= 10 &&
> > > > -   pipe_config->cpu_transcoder != TRANSCODER_A;
> > > > +   /* On TGL, DSC is supported on all Pipes */
> > > > +   if (INTEL_GEN(dev_priv) >= 12)
> > > > +   return true;
> > > > +   else
> > > > +   return (INTEL_GEN(dev_priv) == 10 ||
> > > > INTEL_GEN(dev_priv) == 11) &&
> > > 
> > > Why cant you just use INTEL_GEN(dev_priv) >=10 ?
> > 
> > INTEL_GEN(dev_priv) >= 10 was the existing condition. With the new
> > condition added, there would be an overlapping set
> > ie INTEL_GEN(dev_priv) >= 10 would still be TRUE for GEN >= 12.
> > Though
> > this wouldn't affect the logic of the code, thought it would make
> > more
> > sense to sperate it out this way. 
> 
> But since we return for GEN >=12 , the only time it would fall to GEN
> >=10 is for 10 and 11
> so that should work, or you could use IS_GEN(dev_priv, 10) ||
> IS_GEN(dev_priv, 11)
> 
> But may be check with Lucas on what would be the preferred way

Yeah, it wouldn't affect the logic. I debated about it for a while too.

@Lucas, what do you think is the preferred way to implement this?

> 
> Manasi
> > 
> > > 
> > > Manasi
> > > 
> > > > +   pipe_config->cpu_transcoder !=
> > > > TRANSCODER_A;
> > > >  }
> > > >  
> > > >  static bool intel_dp_supports_dsc(struct intel_dp *intel_dp,
> > > > -- 
> > > > 2.17.1
> > > > 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] Revert "ALSA: hda - Drop unsol event handler for Intel HDMI codecs"

2019-08-15 Thread Chris Wilson
Quoting Chris Wilson (2019-08-15 19:15:51)
> In the recent snd merge of
> 
> ddf7cb83b0f4 ALSA: hda: Unexport a few more stuff
> 53eff75e5f4d ALSA: hda: Drop export of snd_hdac_bus_add/remove_device()
> ee5f85d9290f ALSA: hda: Add codec on bus address table lately
> f2dbe87c5ac1 ALSA: hda - Drop unsol event handler for Intel HDMI codecs
> 
> module unload dies on all a couple of machines with
> 
> <1> [281.912684] BUG: kernel NULL pointer dereference, address: 
> 
> <1> [281.912697] #PF: supervisor read access in kernel mode
> <1> [281.912703] #PF: error_code(0x) - not-present page
> <6> [281.912709] PGD 0 P4D 0
> <4> [281.912714] Oops:  [#1] PREEMPT SMP PTI
> <4> [281.912721] CPU: 3 PID: 2842 Comm: i915_module_loa Tainted: G U  
>   5.3.0-rc4-CI-CI_DRM_6712+ #1
> <4> [281.912730] Hardware name: Hewlett-Packard HP EliteBook 8440p/172A, BIOS 
> 68CCU Ver. F.24 09/13/2013
> <4> [281.912744] RIP: 0010:__list_del_entry_valid+0x25/0x90
> <4> [281.912751] Code: c3 0f 1f 40 00 48 8b 07 48 b9 00 01 00 00 00 00 ad de 
> 48 8b 57 08 48 39 c8 74 26 48 b9 22 01 00 00 00 00 ad de 48 39 ca 74 2e <48> 
> 8b 32 48 39 fe 75 3a 48 8b 50 08 48 39 f2 75 48 b8 01 00 00 00
> <4> [281.912767] RSP: 0018:c972bca8 EFLAGS: 00010217
> <4> [281.912774] RAX:  RBX: 88812f8933f8 RCX: 
> dead0122
> <4> [281.912782] RDX:  RSI: 88812f8933f8 RDI: 
> 88812f8938a8
> <4> [281.912789] RBP: 88812e7ce7e8 R08:  R09: 
> 
> <4> [281.912796] R10:  R11:  R12: 
> 88812f8938a8
> <4> [281.912803] R13: 88812c8722a8 R14: c972bf08 R15: 
> 888129761df8
> <4> [281.912811] FS:  7fb4913a9e40() GS:888133b8() 
> knlGS:
> <4> [281.912819] CS:  0010 DS:  ES:  CR0: 80050033
> <4> [281.912826] CR2:  CR3: 00012867a000 CR4: 
> 06e0
> <4> [281.912833] Call Trace:
> <4> [281.912844]  snd_hdac_bus_remove_device+0x2e/0xb0 [snd_hda_core]
> <4> [281.912854]  snd_hdac_device_exit+0x31/0x60 [snd_hda_core]
> <4> [281.912866]  snd_hda_codec_dev_release+0x24/0x50 [snd_hda_codec]
> <4> [281.912876]  device_release+0x22/0x80
> <4> [281.912883]  kobject_put+0x86/0x1b0
> <4> [281.912891]  snd_hda_codec_dev_free+0x5c/0x60 [snd_hda_codec]
> <4> [281.912899]  __snd_device_free+0x4a/0x80
> <4> [281.912904]  snd_device_free_all+0x36/0x90
> <4> [281.912911]  release_card_device+0x14/0x60
> <4> [281.912917]  device_release+0x22/0x80
> <4> [281.912923]  kobject_put+0x86/0x1b0
> <4> [281.912928]  snd_card_free+0x60/0x90
> <4> [281.912939]  pci_device_remove+0x36/0xb0
> <4> [281.912946]  device_release_driver_internal+0xd3/0x1b0
> <4> [281.912953]  unbind_store+0xc3/0x120
> <4> [281.912962]  kernfs_fop_write+0x104/0x190
> <4> [281.912971]  vfs_write+0xbd/0x1d0
> <4> [281.912977]  ksys_write+0x8f/0xe0
> <4> [281.912984]  do_syscall_64+0x55/0x1c0

It wasn't
f2dbe87c5ac1 ALSA: hda - Drop unsol event handler for Intel HDMI codecs
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

2019-08-15 Thread Michal Hocko
On Thu 15-08-19 15:24:48, Jason Gunthorpe wrote:
> On Thu, Aug 15, 2019 at 07:42:07PM +0200, Michal Hocko wrote:
> > On Thu 15-08-19 13:56:31, Jason Gunthorpe wrote:
> > > On Thu, Aug 15, 2019 at 06:00:41PM +0200, Michal Hocko wrote:
> > > 
> > > > > AFAIK 'GFP_NOWAIT' is characterized by the lack of __GFP_FS and
> > > > > __GFP_DIRECT_RECLAIM..
> > > > >
> > > > > This matches the existing test in __need_fs_reclaim() - so if you are
> > > > > OK with GFP_NOFS, aka __GFP_IO which triggers try_to_compact_pages(),
> > > > > allocations during OOM, then I think fs_reclaim already matches what
> > > > > you described?
> > > > 
> > > > No GFP_NOFS is equally bad. Please read my other email explaining what
> > > > the oom_reaper actually requires. In short no blocking on direct or
> > > > indirect dependecy on memory allocation that might sleep.
> > > 
> > > It is much easier to follow with some hints on code, so the true
> > > requirement is that the OOM repear not block on GFP_FS and GFP_IO
> > > allocations, great, that constraint is now clear.
> > 
> > I still do not get why do you put FS/IO into the picture. This is really
> > about __GFP_DIRECT_RECLAIM.
> 
> Like I said this is complicated, translating "no blocking on direct or
> indirect dependecy on memory allocation that might sleep" into GFP
> flags is hard for us outside the mm community.
> 
> So the contraint here is no __GFP_DIRECT_RECLAIM?

OK, I am obviously failing to explain that. Sorry about that. You are
right that this is not simple. Let me try again.

The context we are calling !blockable notifiers from has to finish in a
_finite_ amount of time (and swift is hugely appreciated by users of
otherwise non-responsive system that is under OOM). We are out of memory
so we cannot be blocked waiting for memory. Directly or indirectly (via
a lock, waiting for an event that needs memory to finish in general). So
you need to track dependency over more complicated contexts than the
direct call path (think of workqueue for example).

> I bring up FS/IO because that is what Tejun mentioned when I asked him
> about reclaim restrictions, and is what fs_reclaim_acquire() is
> already sensitive too. It is pretty confusing if we have places using
> the word 'reclaim' with different restrictions. :(

fs_reclaim has been invented to catch potential deadlocks when a
GFP_NO{FS/IO} allocation hits into fs/io reclaim. This is a subset of
the reclaim that we have. The oom context is more restricted and it
cannot depend on _any_ memory reclaim because by the time we have got to
this context all the reclaim has already failed and wait some more will
simply not help.

> > >CPU0 CPU1
> > > mutex_lock()
> > > kmalloc(GFP_KERNEL)
> > 
> > no I mean __GFP_DIRECT_RECLAIM here.
> > 
> > > mutex_unlock()
> > >   fs_reclaim_acquire()
> > >   mutex_lock() <- illegal: lock dep assertion
> > 
> > I cannot really comment on how that is achieveable by lockdep.
> 
> ??? I am trying to explain this is already done and working today. The
> above example will already fault with lockdep enabled.
> 
> This is existing debugging we can use and improve upon rather that
> invent new debugging.

This is what you claim and I am saying that fs_reclaim is about a
restricted reclaim context and it is an ugly hack. It has proven to
report false positives. Maybe it can be extended to a generic reclaim.
I haven't tried that. Do not aim to try it.
-- 
Michal Hocko
SUSE Labs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "ALSA: hda - Drop unsol event handler for Intel HDMI codecs"

2019-08-15 Thread Patchwork
== Series Details ==

Series: Revert "ALSA: hda - Drop unsol event handler for Intel HDMI codecs"
URL   : https://patchwork.freedesktop.org/series/65267/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6712 -> Patchwork_14034


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14034/

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_14034:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@kms_chamelium@hdmi-hpd-fast:
- {fi-icl-u4}:[FAIL][1] ([fdo#111045]) -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-icl-u4/igt@kms_chamel...@hdmi-hpd-fast.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14034/fi-icl-u4/igt@kms_chamel...@hdmi-hpd-fast.html

  
Known issues


  Here are the changes found in Patchwork_14034 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850:   [PASS][3] -> [INCOMPLETE][4] ([fdo#107718])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14034/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html

  
 Possible fixes 

  * igt@kms_chamelium@hdmi-edid-read:
- {fi-icl-u4}:[FAIL][5] ([fdo#111045]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14034/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
  [fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
  [fdo#111049]: https://bugs.freedesktop.org/show_bug.cgi?id=111049


Participating hosts (53 -> 42)
--

  Additional (1): fi-gdg-551 
  Missing(12): fi-kbl-soraka fi-ilk-m540 fi-bsw-n3050 fi-hsw-4200u 
fi-byt-squawks fi-bsw-cyan fi-hsw-4770 fi-pnv-d510 fi-icl-y fi-icl-guc 
fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6712 -> Patchwork_14034

  CI-20190529: 20190529
  CI_DRM_6712: cd7b3a5a9d3b20684a62b8c1a33707c162ee3629 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5138: b9abe0bf6c478c4f6cac56bff286d6926ad8c0ab @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_14034: d4ceec6bc2106009e318f4937bf0a86d07a5b969 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

d4ceec6bc210 Revert "ALSA: hda - Drop unsol event handler for Intel HDMI codecs"

== Logs ==

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

Re: [Intel-gfx] [PATCH 5/4] dma-fence: Have dma_fence_signal call signal_locked

2019-08-15 Thread Chris Wilson
Quoting Daniel Vetter (2019-08-15 19:48:42)
> On Thu, Aug 15, 2019 at 8:46 PM Chris Wilson  wrote:
> > Quoting Daniel Vetter (2019-08-14 18:20:53)
> > > On Sun, Aug 11, 2019 at 10:15:23AM +0100, Chris Wilson wrote:
> > > > Now that dma_fence_signal always takes the spinlock to flush the
> > > > cb_list, simply take the spinlock and call dma_fence_signal_locked() to
> > > > avoid code repetition.
> > > >
> > > > Suggested-by: Christian König 
> > > > Signed-off-by: Chris Wilson 
> > > > Cc: Christian König 
> > >
> > > Hm, I think this largely defeats the point of having the lockless signal
> > > enabling trickery in dma_fence. Maybe that part isn't needed by anyone,
> > > but feels like a thing that needs a notch more thought. And if we need it,
> > > maybe a bit more cleanup.
> >
> > You mean dma_fence_enable_sw_signaling(). The only user appears to be to
> > flush fences, which is actually the intent of always notifying the signal
> > cb. By always doing the callbacks, we can avoid installing the interrupt
> > and completely saturating CPUs with irqs, instead doing a batch in a
> > leisurely timer callback if not flushed naturally.
> 
> Yeah I'm not against ditching this,

I was just thinking aloud working out what the current use case in ttm
was for.

> but can't we ditch a lot more if
> we just always take the spinlock in those paths now anyways? Kinda not
> worth having the complexity anymore.

You would be able to drop the was_set from dma_fence_add_callback. Say

diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 59ac96ec7ba8..e566445134a2 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -345,38 +345,31 @@ int dma_fence_add_callback(struct dma_fence *fence, 
struct dma_fence_cb *cb,
   dma_fence_func_t func)
 {
unsigned long flags;
-   int ret = 0;
-   bool was_set;
+   int ret = -ENOENT;

if (WARN_ON(!fence || !func))
return -EINVAL;

-   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags)) {
-   INIT_LIST_HEAD(>node);
+   INIT_LIST_HEAD(>node);
+   cb->func = func;
+
+   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
return -ENOENT;
-   }

spin_lock_irqsave(fence->lock, flags);
-
-   was_set = test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
-  >flags);
-
-   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
-   ret = -ENOENT;
-   else if (!was_set && fence->ops->enable_signaling) {
+   if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags) &&
+   !test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
+ >flags)) {
trace_dma_fence_enable_signal(fence);

-   if (!fence->ops->enable_signaling(fence)) {
+   if (!fence->ops->enable_signaling ||
+   fence->ops->enable_signaling(fence)) {
+   list_add_tail(>node, >cb_list);
+   ret = 0;
+   } else {
dma_fence_signal_locked(fence);
-   ret = -ENOENT;
}
}
-
-   if (!ret) {
-   cb->func = func;
-   list_add_tail(>node, >cb_list);
-   } else
-   INIT_LIST_HEAD(>node);
spin_unlock_irqrestore(fence->lock, flags);

return ret;

Not a whole lot changes in terms of branches and serialising
instructions. One less baffling sequence to worry about.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/8] drm/i915/gt: Convert timeline tracking to spinlock

2019-08-15 Thread Matthew Auld
On Wed, 14 Aug 2019 at 10:27, Chris Wilson  wrote:
>
> Convert the list manipulation of active to use spinlocks so that we can
active_list

> perform the updates from underneath a quick interrupt callback.
>
> Signed-off-by: Chris Wilson 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/tgl: Enabling DSC on Pipe A for TGL

2019-08-15 Thread Manasi Navare
On Thu, Aug 15, 2019 at 11:39:54AM -0700, Tolakanahalli Pradeep, Madhumitha 
wrote:
> On Thu, 2019-08-15 at 11:24 -0700, Manasi Navare wrote:
> > On Wed, Aug 14, 2019 at 04:51:17PM -0700, Madhumitha Tolakanahalli
> > Pradeep wrote:
> > > Removing restriction on Pipe A as TigerLake onwards, all the pipes
> > > support DSC.
> > 
> > May be elaborate this commit message a little bit something like:
> > "On previous platforms, DSC was not supported on Pipe A while
> > starting TGL, its is supported
> > on all pipes. So remove the DSC and FEC restriction on Pipe A for TGL
> > onwards.
> > 
> 
> Alright, will update that for rev2.
> 
> > > 
> > > Cc: Manasi Navare 
> > > Signed-off-by: Madhumitha Tolakanahalli Pradeep <
> > > madhumitha.tolakanahalli.prad...@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_dp.c | 16 
> > >  1 file changed, 12 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index 4884c87c8ed7..a5b50f93fac5 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -1739,8 +1739,12 @@ static bool
> > > intel_dp_source_supports_fec(struct intel_dp *intel_dp,
> > >  {
> > >   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > >  
> > > - return INTEL_GEN(dev_priv) >= 11 &&
> > > - pipe_config->cpu_transcoder != TRANSCODER_A;
> > > + /* On TGL, DSC is supported on all Pipes */
> > 
> > FEC supported on all pipes
> 
> Oops, will change this.
> 
> > > + if (INTEL_GEN(dev_priv) >= 12)
> > > + return true;
> > > + else
> > > + return INTEL_GEN(dev_priv) == 11 &&

Also here I think its better to use IS_GEN(dev_priv, 11)

> > > + pipe_config->cpu_transcoder != TRANSCODER_A;
> > >  }
> > >  
> > >  static bool intel_dp_supports_fec(struct intel_dp *intel_dp,
> > > @@ -1755,8 +1759,12 @@ static bool
> > > intel_dp_source_supports_dsc(struct intel_dp *intel_dp,
> > >  {
> > >   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > >  
> > > - return INTEL_GEN(dev_priv) >= 10 &&
> > > - pipe_config->cpu_transcoder != TRANSCODER_A;
> > > + /* On TGL, DSC is supported on all Pipes */
> > > + if (INTEL_GEN(dev_priv) >= 12)
> > > + return true;
> > > + else
> > > + return (INTEL_GEN(dev_priv) == 10 ||
> > > INTEL_GEN(dev_priv) == 11) &&
> > 
> > Why cant you just use INTEL_GEN(dev_priv) >=10 ?
> 
> INTEL_GEN(dev_priv) >= 10 was the existing condition. With the new
> condition added, there would be an overlapping set
> ie INTEL_GEN(dev_priv) >= 10 would still be TRUE for GEN >= 12. Though
> this wouldn't affect the logic of the code, thought it would make more
> sense to sperate it out this way. 

But since we return for GEN >=12 , the only time it would fall to GEN >=10 is 
for 10 and 11
so that should work, or you could use IS_GEN(dev_priv, 10) || IS_GEN(dev_priv, 
11)

But may be check with Lucas on what would be the preferred way

Manasi
> 
> > 
> > Manasi
> > 
> > > + pipe_config->cpu_transcoder != TRANSCODER_A;
> > >  }
> > >  
> > >  static bool intel_dp_supports_dsc(struct intel_dp *intel_dp,
> > > -- 
> > > 2.17.1
> > > 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/tgl: Enabling DSC on Pipe A for TGL

2019-08-15 Thread Tolakanahalli Pradeep, Madhumitha
On Thu, 2019-08-15 at 11:24 -0700, Manasi Navare wrote:
> On Wed, Aug 14, 2019 at 04:51:17PM -0700, Madhumitha Tolakanahalli
> Pradeep wrote:
> > Removing restriction on Pipe A as TigerLake onwards, all the pipes
> > support DSC.
> 
> May be elaborate this commit message a little bit something like:
> "On previous platforms, DSC was not supported on Pipe A while
> starting TGL, its is supported
> on all pipes. So remove the DSC and FEC restriction on Pipe A for TGL
> onwards.
> 

Alright, will update that for rev2.

> > 
> > Cc: Manasi Navare 
> > Signed-off-by: Madhumitha Tolakanahalli Pradeep <
> > madhumitha.tolakanahalli.prad...@intel.com>
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp.c | 16 
> >  1 file changed, 12 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 4884c87c8ed7..a5b50f93fac5 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -1739,8 +1739,12 @@ static bool
> > intel_dp_source_supports_fec(struct intel_dp *intel_dp,
> >  {
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> >  
> > -   return INTEL_GEN(dev_priv) >= 11 &&
> > -   pipe_config->cpu_transcoder != TRANSCODER_A;
> > +   /* On TGL, DSC is supported on all Pipes */
> 
> FEC supported on all pipes

Oops, will change this.

> > +   if (INTEL_GEN(dev_priv) >= 12)
> > +   return true;
> > +   else
> > +   return INTEL_GEN(dev_priv) == 11 &&
> > +   pipe_config->cpu_transcoder != TRANSCODER_A;
> >  }
> >  
> >  static bool intel_dp_supports_fec(struct intel_dp *intel_dp,
> > @@ -1755,8 +1759,12 @@ static bool
> > intel_dp_source_supports_dsc(struct intel_dp *intel_dp,
> >  {
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> >  
> > -   return INTEL_GEN(dev_priv) >= 10 &&
> > -   pipe_config->cpu_transcoder != TRANSCODER_A;
> > +   /* On TGL, DSC is supported on all Pipes */
> > +   if (INTEL_GEN(dev_priv) >= 12)
> > +   return true;
> > +   else
> > +   return (INTEL_GEN(dev_priv) == 10 ||
> > INTEL_GEN(dev_priv) == 11) &&
> 
> Why cant you just use INTEL_GEN(dev_priv) >=10 ?

INTEL_GEN(dev_priv) >= 10 was the existing condition. With the new
condition added, there would be an overlapping set
ie INTEL_GEN(dev_priv) >= 10 would still be TRUE for GEN >= 12. Though
this wouldn't affect the logic of the code, thought it would make more
sense to sperate it out this way. 

> 
> Manasi
> 
> > +   pipe_config->cpu_transcoder != TRANSCODER_A;
> >  }
> >  
> >  static bool intel_dp_supports_dsc(struct intel_dp *intel_dp,
> > -- 
> > 2.17.1
> > 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/4] dma-fence: Have dma_fence_signal call signal_locked

2019-08-15 Thread Daniel Vetter
On Thu, Aug 15, 2019 at 8:46 PM Chris Wilson  wrote:
> Quoting Daniel Vetter (2019-08-14 18:20:53)
> > On Sun, Aug 11, 2019 at 10:15:23AM +0100, Chris Wilson wrote:
> > > Now that dma_fence_signal always takes the spinlock to flush the
> > > cb_list, simply take the spinlock and call dma_fence_signal_locked() to
> > > avoid code repetition.
> > >
> > > Suggested-by: Christian König 
> > > Signed-off-by: Chris Wilson 
> > > Cc: Christian König 
> >
> > Hm, I think this largely defeats the point of having the lockless signal
> > enabling trickery in dma_fence. Maybe that part isn't needed by anyone,
> > but feels like a thing that needs a notch more thought. And if we need it,
> > maybe a bit more cleanup.
>
> You mean dma_fence_enable_sw_signaling(). The only user appears to be to
> flush fences, which is actually the intent of always notifying the signal
> cb. By always doing the callbacks, we can avoid installing the interrupt
> and completely saturating CPUs with irqs, instead doing a batch in a
> leisurely timer callback if not flushed naturally.

Yeah I'm not against ditching this, but can't we ditch a lot more if
we just always take the spinlock in those paths now anyways? Kinda not
worth having the complexity anymore.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/4] dma-fence: Have dma_fence_signal call signal_locked

2019-08-15 Thread Chris Wilson
Quoting Daniel Vetter (2019-08-14 18:20:53)
> On Sun, Aug 11, 2019 at 10:15:23AM +0100, Chris Wilson wrote:
> > Now that dma_fence_signal always takes the spinlock to flush the
> > cb_list, simply take the spinlock and call dma_fence_signal_locked() to
> > avoid code repetition.
> > 
> > Suggested-by: Christian König 
> > Signed-off-by: Chris Wilson 
> > Cc: Christian König 
> 
> Hm, I think this largely defeats the point of having the lockless signal
> enabling trickery in dma_fence. Maybe that part isn't needed by anyone,
> but feels like a thing that needs a notch more thought. And if we need it,
> maybe a bit more cleanup.

You mean dma_fence_enable_sw_signaling(). The only user appears to be to
flush fences, which is actually the intent of always notifying the signal
cb. By always doing the callbacks, we can avoid installing the interrupt
and completely saturating CPUs with irqs, instead doing a batch in a
leisurely timer callback if not flushed naturally.
-Chris
___
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/tgl: disable DDIC

2019-08-15 Thread Patchwork
== Series Details ==

Series: drm/i915/tgl: disable DDIC
URL   : https://patchwork.freedesktop.org/series/65217/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6710_full -> Patchwork_14020_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_14020_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_shared@exec-single-timeline-bsd:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110841])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb3/igt@gem_ctx_sha...@exec-single-timeline-bsd.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/shard-iclb1/igt@gem_ctx_sha...@exec-single-timeline-bsd.html

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110854])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb2/igt@gem_exec_balan...@smoke.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/shard-iclb5/igt@gem_exec_balan...@smoke.html

  * igt@gem_exec_schedule@preempt-other-chain-bsd:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#111325]) +5 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb7/igt@gem_exec_sched...@preempt-other-chain-bsd.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/shard-iclb2/igt@gem_exec_sched...@preempt-other-chain-bsd.html

  * igt@i915_suspend@fence-restore-tiled2untiled:
- shard-apl:  [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +3 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-apl7/igt@i915_susp...@fence-restore-tiled2untiled.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/shard-apl5/igt@i915_susp...@fence-restore-tiled2untiled.html

  * igt@kms_fbcon_fbt@fbc-suspend:
- shard-skl:  [PASS][9] -> [INCOMPLETE][10] ([fdo#104108])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-skl4/igt@kms_fbcon_...@fbc-suspend.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/shard-skl1/igt@kms_fbcon_...@fbc-suspend.html

  * igt@kms_flip@2x-flip-vs-expired-vblank:
- shard-hsw:  [PASS][11] -> [FAIL][12] ([fdo#102887])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-hsw5/igt@kms_f...@2x-flip-vs-expired-vblank.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/shard-hsw2/igt@kms_f...@2x-flip-vs-expired-vblank.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render:
- shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103167]) +4 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb6/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/shard-iclb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl:  [PASS][15] -> [FAIL][16] ([fdo#108145] / [fdo#110403])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-skl2/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/shard-skl6/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html

  * igt@kms_psr@psr2_cursor_render:
- shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +2 similar 
issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/shard-iclb4/igt@kms_psr@psr2_cursor_render.html

  * igt@prime_busy@hang-bsd2:
- shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109276]) +15 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb4/igt@prime_b...@hang-bsd2.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/shard-iclb3/igt@prime_b...@hang-bsd2.html

  
 Possible fixes 

  * igt@gem_eio@reset-stress:
- shard-snb:  [FAIL][21] ([fdo#109661]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-snb2/igt@gem_...@reset-stress.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/shard-snb2/igt@gem_...@reset-stress.html

  * igt@gem_exec_async@concurrent-writes-bsd:
- shard-iclb: [SKIP][23] ([fdo#111325]) -> [PASS][24] +4 similar 
issues
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb2/igt@gem_exec_as...@concurrent-writes-bsd.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/shard-iclb6/igt@gem_exec_as...@concurrent-writes-bsd.html

  * igt@gem_exec_schedule@preempt-contexts-bsd2:
- shard-iclb: [SKIP][25] ([fdo#109276]) -> [PASS][26] +16 similar 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Revert "ALSA: hda - Drop unsol event handler for Intel HDMI codecs"

2019-08-15 Thread Patchwork
== Series Details ==

Series: Revert "ALSA: hda - Drop unsol event handler for Intel HDMI codecs"
URL   : https://patchwork.freedesktop.org/series/65267/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
d4ceec6bc210 Revert "ALSA: hda - Drop unsol event handler for Intel HDMI codecs"
-:9: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit ddf7cb83b0f4 ("ALSA: hda: 
Unexport a few more stuff")'
#9: 
ddf7cb83b0f4 ALSA: hda: Unexport a few more stuff

-:10: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 53eff75e5f4d ("ALSA: hda: Drop 
export of snd_hdac_bus_add/remove_device()")'
#10: 
53eff75e5f4d ALSA: hda: Drop export of snd_hdac_bus_add/remove_device()

-:11: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit ee5f85d9290f ("ALSA: hda: Add 
codec on bus address table lately")'
#11: 
ee5f85d9290f ALSA: hda: Add codec on bus address table lately

-:12: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit f2dbe87c5ac1 ("ALSA: hda - Drop 
unsol event handler for Intel HDMI codecs")'
#12: 
f2dbe87c5ac1 ALSA: hda - Drop unsol event handler for Intel HDMI codecs

-:16: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#16: 
<1> [281.912684] BUG: kernel NULL pointer dereference, address: 

-:83: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)

total: 5 errors, 1 warnings, 0 checks, 21 lines checked

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

Re: [Intel-gfx] [PATCH 2/8] drm/i915/gt: Track timeline activeness in enter/exit

2019-08-15 Thread Matthew Auld
On Wed, 14 Aug 2019 at 10:44, Chris Wilson  wrote:
>
> Lift moving the timeline to/from the active_list on enter/exit in order
> to shorten the active tracking span in comparison to the existing
> pin/unpin.
>
> Signed-off-by: Chris Wilson 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

2019-08-15 Thread Jerome Glisse
On Thu, Aug 15, 2019 at 03:01:59PM -0300, Jason Gunthorpe wrote:
> On Thu, Aug 15, 2019 at 01:39:22PM -0400, Jerome Glisse wrote:
> > On Thu, Aug 15, 2019 at 02:35:57PM -0300, Jason Gunthorpe wrote:
> > > On Thu, Aug 15, 2019 at 06:25:16PM +0200, Daniel Vetter wrote:
> > > 
> > > > I'm not really well versed in the details of our userptr, but both
> > > > amdgpu and i915 wait for the gpu to complete from
> > > > invalidate_range_start. Jerome has at least looked a lot at the amdgpu
> > > > one, so maybe he can explain what exactly it is we're doing ...
> > > 
> > > amdgpu is (wrongly) using hmm for something, I can't really tell what
> > > it is trying to do. The calls to dma_fence under the
> > > invalidate_range_start do not give me a good feeling.
> > > 
> > > However, i915 shows all the signs of trying to follow the registration
> > > cache model, it even has a nice comment in
> > > i915_gem_userptr_get_pages() explaining that the races it has don't
> > > matter because it is a user space bug to change the VA mapping in the
> > > first place. That just screams registration cache to me.
> > > 
> > > So it is fine to run HW that way, but if you do, there is no reason to
> > > fence inside the invalidate_range end. Just orphan the DMA buffer and
> > > clean it up & release the page pins when all DMA buffer refs go to
> > > zero. The next access to that VA should get a new DMA buffer with the
> > > right mapping.
> > > 
> > > In other words the invalidation should be very simple without
> > > complicated locking, or wait_event's. Look at hfi1 for example.
> > 
> > This would break the today usage model of uptr and it will
> > break userspace expectation ie if GPU is writting to that
> > memory and that memory then the userspace want to make sure
> > that it will see what the GPU write.
> 
> How exactly? This is holding the page pin, so the only way the VA
> mapping can be changed is via explicit user action.
> 
> ie:
> 
>gpu_write_something(va, size)
>mmap(.., va, size, MMAP_FIXED);
>gpu_wait_done()
> 
> This is racy and indeterminate with both models.
> 
> Based on the comment in i915 it appears to be going on the model that
> changes to the mmap by userspace when the GPU is working on it is a
> programming bug. This is reasonable, lots of systems use this kind of
> consistency model.

Well userspace process doing munmap(), mremap(), fork() and things like
that are a bug from the i915 kernel and userspace contract point of view.

But things like migration or reclaim are not cover under that contract
and for those the expectation is that CPU access to the same virtual address
should allow to get what was last written to it either by the GPU or the
CPU.

> 
> Since the driver seems to rely on a dma_fence to block DMA access, it
> looks to me like the kernel has full visibility to the
> 'gpu_write_something()' and 'gpu_wait_done()' markers.

So let's only consider the case where GPU wants to write to the memory
(the read only case is obviously right and not need any notifier in
fact) and like above the only thing we care about is reclaim or migration
(for instance because of some numa compaction) as the rest is cover by
i915 userspace contract.

So in the write case we do GUPfast(write=true) which will be "safe" from
any concurrent CPU page table update ie if GUPfast get a reference for
the page then any racing CPU page table update will not be able to migrate
or reclaim the page and thus the virtual address to page association will
be preserve.

This is only true because of GUPfast(), now if GUPfast() fails it will
fallback to the slow GUP case which make the same thing safe by taking
the page table lock.

Because of the reference on the page the i915 driver can forego the mmu
notifier end callback. The thing here is that taking a page reference
is pointless if we have better synchronization and tracking of mmu
notifier. Hence converting to hmm mirror allows to avoid taking a ref
on the page while still keeping the same functionality as of today.


> I think trying to use hmm_range_fault on HW that can't do HW page
> faulting and HW 'TLB shootdown' is a very, very bad idea. I fear that
> is what amd gpu is trying to do.
> 
> I haven't yet seen anything that looks like 'TLB shootdown' in i915??

GPU driver have complex usage pattern the tlb shootdown is implicit
once the GEM object associated with the uptr is invalidated it means
next time userspace submit command against that GEM object it will
have to re-validate it which means re-program the GPU page table to
point to the proper address (and re-call GUP).

So the whole GPU page table update is all hidden behind GEM function
like i915_gem_object_unbind() (or ttm invalidate for amd/radeon).

Technicaly those GPU do not support page faulting but because of the
way GPU works you know that you have frequent checkpoint where you
can unbind things. This is what is happening here.

Also not all GPU engines can handle page fault, this is true of all

Re: [Intel-gfx] [PATCH] drm/i915/tgl: Enabling DSC on Pipe A for TGL

2019-08-15 Thread Manasi Navare
On Wed, Aug 14, 2019 at 04:51:17PM -0700, Madhumitha Tolakanahalli Pradeep 
wrote:
> Removing restriction on Pipe A as TigerLake onwards, all the pipes support 
> DSC.

May be elaborate this commit message a little bit something like:
"On previous platforms, DSC was not supported on Pipe A while starting TGL, its 
is supported
on all pipes. So remove the DSC and FEC restriction on Pipe A for TGL onwards.

> 
> Cc: Manasi Navare 
> Signed-off-by: Madhumitha Tolakanahalli Pradeep 
> 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 16 
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 4884c87c8ed7..a5b50f93fac5 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1739,8 +1739,12 @@ static bool intel_dp_source_supports_fec(struct 
> intel_dp *intel_dp,
>  {
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>  
> - return INTEL_GEN(dev_priv) >= 11 &&
> - pipe_config->cpu_transcoder != TRANSCODER_A;
> + /* On TGL, DSC is supported on all Pipes */

    FEC supported on all pipes
> + if (INTEL_GEN(dev_priv) >= 12)
> + return true;
> + else
> + return INTEL_GEN(dev_priv) == 11 &&
> + pipe_config->cpu_transcoder != TRANSCODER_A;
>  }
>  
>  static bool intel_dp_supports_fec(struct intel_dp *intel_dp,
> @@ -1755,8 +1759,12 @@ static bool intel_dp_source_supports_dsc(struct 
> intel_dp *intel_dp,
>  {
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>  
> - return INTEL_GEN(dev_priv) >= 10 &&
> - pipe_config->cpu_transcoder != TRANSCODER_A;
> + /* On TGL, DSC is supported on all Pipes */
> + if (INTEL_GEN(dev_priv) >= 12)
> + return true;
> + else
> + return (INTEL_GEN(dev_priv) == 10 || INTEL_GEN(dev_priv) == 11) 
> &&

Why cant you just use INTEL_GEN(dev_priv) >=10 ?

Manasi

> + pipe_config->cpu_transcoder != TRANSCODER_A;
>  }
>  
>  static bool intel_dp_supports_dsc(struct intel_dp *intel_dp,
> -- 
> 2.17.1
> 
___
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/uc: Fini hw even if GuC is not running (rev2)

2019-08-15 Thread Patchwork
== Series Details ==

Series: drm/i915/uc: Fini hw even if GuC is not running (rev2)
URL   : https://patchwork.freedesktop.org/series/65140/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6712 -> Patchwork_14033


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14033/

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_14033:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@kms_chamelium@hdmi-hpd-fast:
- {fi-icl-u4}:[FAIL][1] ([fdo#111045]) -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-icl-u4/igt@kms_chamel...@hdmi-hpd-fast.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14033/fi-icl-u4/igt@kms_chamel...@hdmi-hpd-fast.html

  
Known issues


  Here are the changes found in Patchwork_14033 that come from known issues:

### IGT changes ###

 Possible fixes 

  * igt@gem_ctx_switch@rcs0:
- {fi-icl-guc}:   [INCOMPLETE][3] ([fdo#107713]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-icl-guc/igt@gem_ctx_swi...@rcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14033/fi-icl-guc/igt@gem_ctx_swi...@rcs0.html

  * igt@kms_chamelium@hdmi-edid-read:
- {fi-icl-u4}:[FAIL][5] ([fdo#111045]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14033/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
  [fdo#111049]: https://bugs.freedesktop.org/show_bug.cgi?id=111049


Participating hosts (53 -> 45)
--

  Additional (1): fi-gdg-551 
  Missing(9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks 
fi-bsw-cyan fi-hsw-4770 fi-icl-y fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6712 -> Patchwork_14033

  CI-20190529: 20190529
  CI_DRM_6712: cd7b3a5a9d3b20684a62b8c1a33707c162ee3629 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5138: b9abe0bf6c478c4f6cac56bff286d6926ad8c0ab @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_14033: ad7f85475cb7265026b2a977b38edc2d07311e63 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

ad7f85475cb7 drm/i915/uc: Fini hw even if GuC is not running

== Logs ==

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

[Intel-gfx] [PATCH] Revert "ALSA: hda - Drop unsol event handler for Intel HDMI codecs"

2019-08-15 Thread Chris Wilson
In the recent snd merge of

ddf7cb83b0f4 ALSA: hda: Unexport a few more stuff
53eff75e5f4d ALSA: hda: Drop export of snd_hdac_bus_add/remove_device()
ee5f85d9290f ALSA: hda: Add codec on bus address table lately
f2dbe87c5ac1 ALSA: hda - Drop unsol event handler for Intel HDMI codecs

module unload dies on all a couple of machines with

<1> [281.912684] BUG: kernel NULL pointer dereference, address: 
<1> [281.912697] #PF: supervisor read access in kernel mode
<1> [281.912703] #PF: error_code(0x) - not-present page
<6> [281.912709] PGD 0 P4D 0
<4> [281.912714] Oops:  [#1] PREEMPT SMP PTI
<4> [281.912721] CPU: 3 PID: 2842 Comm: i915_module_loa Tainted: G U
5.3.0-rc4-CI-CI_DRM_6712+ #1
<4> [281.912730] Hardware name: Hewlett-Packard HP EliteBook 8440p/172A, BIOS 
68CCU Ver. F.24 09/13/2013
<4> [281.912744] RIP: 0010:__list_del_entry_valid+0x25/0x90
<4> [281.912751] Code: c3 0f 1f 40 00 48 8b 07 48 b9 00 01 00 00 00 00 ad de 48 
8b 57 08 48 39 c8 74 26 48 b9 22 01 00 00 00 00 ad de 48 39 ca 74 2e <48> 8b 32 
48 39 fe 75 3a 48 8b 50 08 48 39 f2 75 48 b8 01 00 00 00
<4> [281.912767] RSP: 0018:c972bca8 EFLAGS: 00010217
<4> [281.912774] RAX:  RBX: 88812f8933f8 RCX: 
dead0122
<4> [281.912782] RDX:  RSI: 88812f8933f8 RDI: 
88812f8938a8
<4> [281.912789] RBP: 88812e7ce7e8 R08:  R09: 

<4> [281.912796] R10:  R11:  R12: 
88812f8938a8
<4> [281.912803] R13: 88812c8722a8 R14: c972bf08 R15: 
888129761df8
<4> [281.912811] FS:  7fb4913a9e40() GS:888133b8() 
knlGS:
<4> [281.912819] CS:  0010 DS:  ES:  CR0: 80050033
<4> [281.912826] CR2:  CR3: 00012867a000 CR4: 
06e0
<4> [281.912833] Call Trace:
<4> [281.912844]  snd_hdac_bus_remove_device+0x2e/0xb0 [snd_hda_core]
<4> [281.912854]  snd_hdac_device_exit+0x31/0x60 [snd_hda_core]
<4> [281.912866]  snd_hda_codec_dev_release+0x24/0x50 [snd_hda_codec]
<4> [281.912876]  device_release+0x22/0x80
<4> [281.912883]  kobject_put+0x86/0x1b0
<4> [281.912891]  snd_hda_codec_dev_free+0x5c/0x60 [snd_hda_codec]
<4> [281.912899]  __snd_device_free+0x4a/0x80
<4> [281.912904]  snd_device_free_all+0x36/0x90
<4> [281.912911]  release_card_device+0x14/0x60
<4> [281.912917]  device_release+0x22/0x80
<4> [281.912923]  kobject_put+0x86/0x1b0
<4> [281.912928]  snd_card_free+0x60/0x90
<4> [281.912939]  pci_device_remove+0x36/0xb0
<4> [281.912946]  device_release_driver_internal+0xd3/0x1b0
<4> [281.912953]  unbind_store+0xc3/0x120
<4> [281.912962]  kernfs_fop_write+0x104/0x190
<4> [281.912971]  vfs_write+0xbd/0x1d0
<4> [281.912977]  ksys_write+0x8f/0xe0
<4> [281.912984]  do_syscall_64+0x55/0x1c0

Cc: Takashi Iwai 
---
 sound/pci/hda/patch_hdmi.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index 933c7bf47ef6..2096993eaf28 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -2760,8 +2760,6 @@ static void i915_pin_cvt_fixup(struct hda_codec *codec,
 /* precondition and allocation for Intel codecs */
 static int alloc_intel_hdmi(struct hda_codec *codec)
 {
-   int err;
-
/* requires i915 binding */
if (!codec->bus->core.audio_component) {
codec_info(codec, "No i915 binding for Intel HDMI/DP codec\n");
@@ -2770,12 +2768,7 @@ static int alloc_intel_hdmi(struct hda_codec *codec)
return -ENODEV;
}
 
-   err = alloc_generic_hdmi(codec);
-   if (err < 0)
-   return err;
-   /* no need to handle unsol events */
-   codec->patch_ops.unsol_event = NULL;
-   return 0;
+   return alloc_generic_hdmi(codec);
 }
 
 /* parse and post-process for Intel codecs */
-- 
2.23.0.rc1

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

Re: [Intel-gfx] [PATCH v7 1/9] drm_dp_cec: add connector info support.

2019-08-15 Thread Lyude Paul
Reviewed-by: Lyude Paul 

On Wed, 2019-08-14 at 12:44 +0200, Dariusz Marcinkiewicz wrote:
> Pass the connector info to the CEC adapter. This makes it possible
> to associate the CEC adapter with the corresponding drm connector.
> 
> Signed-off-by: Dariusz Marcinkiewicz 
> Signed-off-by: Hans Verkuil 
> Tested-by: Hans Verkuil 
> ---
>  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  2 +-
>  drivers/gpu/drm/drm_dp_cec.c  | 25 ---
>  drivers/gpu/drm/i915/display/intel_dp.c   |  4 +--
>  drivers/gpu/drm/nouveau/nouveau_connector.c   |  3 +--
>  include/drm/drm_dp_helper.h   | 17 ++---
>  5 files changed, 27 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 16218a202b591..5ec14efd4d8cb 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -416,7 +416,7 @@ void amdgpu_dm_initialize_dp_connector(struct
> amdgpu_display_manager *dm,
>  
>   drm_dp_aux_register(>dm_dp_aux.aux);
>   drm_dp_cec_register_connector(>dm_dp_aux.aux,
> -   aconnector->base.name, dm->adev->dev);
> +   >base);
>   aconnector->mst_mgr.cbs = _mst_cbs;
>   drm_dp_mst_topology_mgr_init(
>   >mst_mgr,
> diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
> index b15cee85b702b..b457c16c3a8bb 100644
> --- a/drivers/gpu/drm/drm_dp_cec.c
> +++ b/drivers/gpu/drm/drm_dp_cec.c
> @@ -8,7 +8,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
>  
>  /*
> @@ -295,7 +297,10 @@ static void drm_dp_cec_unregister_work(struct work_struct
> *work)
>   */
>  void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
>  {
> - u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD;
> + struct drm_connector *connector = aux->cec.connector;
> + u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD |
> +CEC_CAP_CONNECTOR_INFO;
> + struct cec_connector_info conn_info;
>   unsigned int num_las = 1;
>   u8 cap;
>  
> @@ -344,13 +349,17 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
> struct edid *edid)
>  
>   /* Create a new adapter */
>   aux->cec.adap = cec_allocate_adapter(_dp_cec_adap_ops,
> -  aux, aux->cec.name, cec_caps,
> +  aux, connector->name, cec_caps,
>num_las);
>   if (IS_ERR(aux->cec.adap)) {
>   aux->cec.adap = NULL;
>   goto unlock;
>   }
> - if (cec_register_adapter(aux->cec.adap, aux->cec.parent)) {
> +
> + cec_fill_conn_info_from_drm(_info, connector);
> + cec_s_conn_info(aux->cec.adap, _info);
> +
> + if (cec_register_adapter(aux->cec.adap, connector->dev->dev)) {
>   cec_delete_adapter(aux->cec.adap);
>   aux->cec.adap = NULL;
>   } else {
> @@ -406,22 +415,20 @@ EXPORT_SYMBOL(drm_dp_cec_unset_edid);
>  /**
>   * drm_dp_cec_register_connector() - register a new connector
>   * @aux: DisplayPort AUX channel
> - * @name: name of the CEC device
> - * @parent: parent device
> + * @connector: drm connector
>   *
>   * A new connector was registered with associated CEC adapter name and
>   * CEC adapter parent device. After registering the name and parent
>   * drm_dp_cec_set_edid() is called to check if the connector supports
>   * CEC and to register a CEC adapter if that is the case.
>   */
> -void drm_dp_cec_register_connector(struct drm_dp_aux *aux, const char *name,
> -struct device *parent)
> +void drm_dp_cec_register_connector(struct drm_dp_aux *aux,
> +struct drm_connector *connector)
>  {
>   WARN_ON(aux->cec.adap);
>   if (WARN_ON(!aux->transfer))
>   return;
> - aux->cec.name = name;
> - aux->cec.parent = parent;
> + aux->cec.connector = connector;
>   INIT_DELAYED_WORK(>cec.unregister_work,
> drm_dp_cec_unregister_work);
>  }
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 1092499115760..de2486fe7bf2d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5497,7 +5497,6 @@ static int
>  intel_dp_connector_register(struct drm_connector *connector)
>  {
>   struct intel_dp *intel_dp = intel_attached_dp(connector);
> - struct drm_device *dev = connector->dev;
>   int ret;
>  
>   ret = intel_connector_register(connector);
> @@ -5512,8 +5511,7 @@ intel_dp_connector_register(struct drm_connector
> *connector)
>   intel_dp->aux.dev = connector->kdev;
>   ret = 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tgl: Enabling DSC on Pipe A for TGL

2019-08-15 Thread Patchwork
== Series Details ==

Series: drm/i915/tgl: Enabling DSC on Pipe A for TGL
URL   : https://patchwork.freedesktop.org/series/65216/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6710_full -> Patchwork_14019_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_14019_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_eio@in-flight-suspend:
- shard-apl:  [PASS][1] -> [DMESG-WARN][2] ([fdo#108566])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-apl5/igt@gem_...@in-flight-suspend.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/shard-apl7/igt@gem_...@in-flight-suspend.html

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110854])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb2/igt@gem_exec_balan...@smoke.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/shard-iclb3/igt@gem_exec_balan...@smoke.html

  * igt@gem_exec_schedule@preempt-other-chain-bsd:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#111325]) +3 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb7/igt@gem_exec_sched...@preempt-other-chain-bsd.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/shard-iclb4/igt@gem_exec_sched...@preempt-other-chain-bsd.html

  * igt@i915_suspend@sysfs-reader:
- shard-skl:  [PASS][7] -> [INCOMPLETE][8] ([fdo#104108])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-skl6/igt@i915_susp...@sysfs-reader.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/shard-skl6/igt@i915_susp...@sysfs-reader.html

  * igt@kms_cursor_legacy@cursor-vs-flip-atomic:
- shard-hsw:  [PASS][9] -> [FAIL][10] ([fdo#103355])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-hsw8/igt@kms_cursor_leg...@cursor-vs-flip-atomic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/shard-hsw4/igt@kms_cursor_leg...@cursor-vs-flip-atomic.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
- shard-kbl:  [PASS][11] -> [INCOMPLETE][12] ([fdo#103665])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-kbl3/igt@kms_f...@flip-vs-suspend-interruptible.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/shard-kbl6/igt@kms_f...@flip-vs-suspend-interruptible.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite:
- shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103167]) +4 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/shard-iclb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl:  [PASS][15] -> [FAIL][16] ([fdo#108145] / [fdo#110403])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-skl2/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html

  * igt@kms_plane_lowres@pipe-a-tiling-y:
- shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103166])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb8/igt@kms_plane_low...@pipe-a-tiling-y.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/shard-iclb7/igt@kms_plane_low...@pipe-a-tiling-y.html

  * igt@kms_psr@psr2_cursor_render:
- shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +2 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/shard-iclb5/igt@kms_psr@psr2_cursor_render.html

  * igt@prime_vgem@fence-wait-bsd2:
- shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109276]) +19 similar 
issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb2/igt@prime_v...@fence-wait-bsd2.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/shard-iclb5/igt@prime_v...@fence-wait-bsd2.html

  * igt@sw_sync@sync_multi_consumer:
- shard-apl:  [PASS][23] -> [INCOMPLETE][24] ([fdo#103927])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-apl3/igt@sw_sync@sync_multi_consumer.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/shard-apl5/igt@sw_sync@sync_multi_consumer.html

  
 Possible fixes 

  * igt@gem_eio@reset-stress:
- shard-snb:  [FAIL][25] ([fdo#109661]) -> [PASS][26]
   [25]: 

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

2019-08-15 Thread Jerome Glisse
On Thu, Aug 15, 2019 at 07:42:07PM +0200, Michal Hocko wrote:
> On Thu 15-08-19 13:56:31, Jason Gunthorpe wrote:
> > On Thu, Aug 15, 2019 at 06:00:41PM +0200, Michal Hocko wrote:
> > 
> > > > AFAIK 'GFP_NOWAIT' is characterized by the lack of __GFP_FS and
> > > > __GFP_DIRECT_RECLAIM..
> > > >
> > > > This matches the existing test in __need_fs_reclaim() - so if you are
> > > > OK with GFP_NOFS, aka __GFP_IO which triggers try_to_compact_pages(),
> > > > allocations during OOM, then I think fs_reclaim already matches what
> > > > you described?
> > > 
> > > No GFP_NOFS is equally bad. Please read my other email explaining what
> > > the oom_reaper actually requires. In short no blocking on direct or
> > > indirect dependecy on memory allocation that might sleep.
> > 
> > It is much easier to follow with some hints on code, so the true
> > requirement is that the OOM repear not block on GFP_FS and GFP_IO
> > allocations, great, that constraint is now clear.
> 
> I still do not get why do you put FS/IO into the picture. This is really
> about __GFP_DIRECT_RECLAIM.
> 
> > 
> > > If you can express that in the existing lockdep machinery. All
> > > fine. But then consider deployments where lockdep is no-no because
> > > of the overhead.
> > 
> > This is all for driver debugging. The point of lockdep is to find all
> > these paths without have to hit them as actual races, using debug
> > kernels.
> > 
> > I don't think we need this kind of debugging on production kernels?
> 
> Again, the primary motivation was a simple debugging aid that could be
> used without worrying about overhead. So lockdep is very often out of
> the question.
> 
> > > > The best we got was drivers tested the VA range and returned success
> > > > if they had no interest. Which is a big win to be sure, but it looks
> > > > like getting any more is not really posssible.
> > > 
> > > And that is already a great win! Because many notifiers only do care
> > > about particular mappings. Please note that backing off unconditioanlly
> > > will simply cause that the oom reaper will have to back off not doing
> > > any tear down anything.
> > 
> > Well, I'm working to propose that we do the VA range test under core
> > mmu notifier code that cannot block and then we simply remove the idea
> > of blockable from drivers using this new 'range notifier'. 
> > 
> > I think this pretty much solves the concern?
> 
> Well, my idea was that a range check and early bail out was a first step
> and then each specific notifier would be able to do a more specific
> check. I was not able to do the second step because that requires a deep
> understanding of the respective subsystem.
> 
> Really all I do care about is to reclaim as much memory from the
> oom_reaper context as possible. And that cannot really be an unbounded
> process. Quite contrary it should be as swift as possible. From my
> cursory look some notifiers are able to achieve their task without
> blocking or depending on memory just fine. So bailing out
> unconditionally on the range of interest would just put us back.

Agree, OOM just asking the question: can i unmap that page quickly ?
so that me (OOM) can swap it out. In many cases the driver need to
lookup something to see if at the time the memory is just not in use
and can be reclaim right away. So driver should have a path to
optimistically update its state to allow quick reclaim.


> > > > However, we could (probably even should) make the drivers fs_reclaim
> > > > safe.
> > > > 
> > > > If that is enough to guarantee progress of OOM, then lets consider
> > > > something like using current_gfp_context() to force PF_MEMALLOC_NOFS
> > > > allocation behavior on the driver callback and lockdep to try and keep
> > > > pushing on the the debugging, and dropping !blocking.
> > > 
> > > How are you going to enforce indirect dependency? E.g. a lock that is
> > > also used in other context which depend on sleepable memory allocation
> > > to move forward.
> > 
> > You mean like this:
> > 
> >CPU0 CPU1
> > mutex_lock()
> > kmalloc(GFP_KERNEL)
> 
> no I mean __GFP_DIRECT_RECLAIM here.
> 
> > mutex_unlock()
> >   fs_reclaim_acquire()
> >   mutex_lock() <- illegal: lock dep assertion
> 
> I cannot really comment on how that is achieveable by lockdep. I managed
> to forget details about FS/IO reclaim recursion tracking already and I
> do not have time to learn it again. It was quite a hack. Anyway, let me
> repeat that the primary motivation was a simple aid. Not something as
> poverful as lockdep.

I feel that the fs_reclaim_acquire() is just too heavy weight here. I
do think that Daniel patches improve the debugging situation without
burdening anything so i am in favor or merging that.

I do not think we should devote too much time into fs_reclaim(), our
time would be better spend in improving the 

[Intel-gfx] ✗ Fi.CI.BAT: failure for More WOPCM fixes

2019-08-15 Thread Patchwork
== Series Details ==

Series: More WOPCM fixes
URL   : https://patchwork.freedesktop.org/series/65263/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6712 -> Patchwork_14032


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_14032 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_14032, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_14032:

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-cfl-guc: [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-cfl-guc/igt@i915_pm_...@basic-pci-d3-state.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-cfl-guc/igt@i915_pm_...@basic-pci-d3-state.html
- fi-skl-guc: [PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-skl-guc/igt@i915_pm_...@basic-pci-d3-state.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-skl-guc/igt@i915_pm_...@basic-pci-d3-state.html
- fi-apl-guc: [PASS][5] -> [FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-apl-guc/igt@i915_pm_...@basic-pci-d3-state.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-apl-guc/igt@i915_pm_...@basic-pci-d3-state.html

  
 Warnings 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-kbl-guc: [SKIP][7] ([fdo#109271]) -> [FAIL][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@runner@aborted:
- fi-cfl-guc: [FAIL][9] ([fdo#110755]) -> [FAIL][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-cfl-guc/igt@run...@aborted.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-cfl-guc/igt@run...@aborted.html
- fi-apl-guc: [FAIL][11] ([fdo#110755]) -> [FAIL][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-apl-guc/igt@run...@aborted.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-apl-guc/igt@run...@aborted.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@gem_busy@busy-all:
- {fi-icl-guc}:   [PASS][13] -> [SKIP][14] +10 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-icl-guc/igt@gem_b...@busy-all.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-icl-guc/igt@gem_b...@busy-all.html

  * igt@gem_ctx_switch@rcs0:
- {fi-icl-guc}:   [INCOMPLETE][15] ([fdo#107713]) -> [SKIP][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-icl-guc/igt@gem_ctx_swi...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-icl-guc/igt@gem_ctx_swi...@rcs0.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- {fi-icl-guc}:   NOTRUN -> [FAIL][17]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-icl-guc/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@kms_busy@basic-flip-b:
- {fi-icl-guc}:   NOTRUN -> [SKIP][18] +67 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-icl-guc/igt@kms_b...@basic-flip-b.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- {fi-icl-u4}:[FAIL][19] ([fdo#111045]) -> [FAIL][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-icl-u4/igt@kms_chamel...@hdmi-hpd-fast.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-icl-u4/igt@kms_chamel...@hdmi-hpd-fast.html

  
Known issues


  Here are the changes found in Patchwork_14032 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_switch@legacy-render:
- fi-apl-guc: [PASS][21] -> [SKIP][22] ([fdo#109271]) +77 similar 
issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-apl-guc/igt@gem_ctx_swi...@legacy-render.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-apl-guc/igt@gem_ctx_swi...@legacy-render.html

  * igt@gem_ctx_switch@rcs0:
- fi-skl-guc: [PASS][23] -> [SKIP][24] ([fdo#109271]) +77 similar 
issues
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-skl-guc/igt@gem_ctx_swi...@rcs0.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-skl-guc/igt@gem_ctx_swi...@rcs0.html

  * 

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

2019-08-15 Thread Michal Hocko
On Thu 15-08-19 13:56:31, Jason Gunthorpe wrote:
> On Thu, Aug 15, 2019 at 06:00:41PM +0200, Michal Hocko wrote:
> 
> > > AFAIK 'GFP_NOWAIT' is characterized by the lack of __GFP_FS and
> > > __GFP_DIRECT_RECLAIM..
> > >
> > > This matches the existing test in __need_fs_reclaim() - so if you are
> > > OK with GFP_NOFS, aka __GFP_IO which triggers try_to_compact_pages(),
> > > allocations during OOM, then I think fs_reclaim already matches what
> > > you described?
> > 
> > No GFP_NOFS is equally bad. Please read my other email explaining what
> > the oom_reaper actually requires. In short no blocking on direct or
> > indirect dependecy on memory allocation that might sleep.
> 
> It is much easier to follow with some hints on code, so the true
> requirement is that the OOM repear not block on GFP_FS and GFP_IO
> allocations, great, that constraint is now clear.

I still do not get why do you put FS/IO into the picture. This is really
about __GFP_DIRECT_RECLAIM.

> 
> > If you can express that in the existing lockdep machinery. All
> > fine. But then consider deployments where lockdep is no-no because
> > of the overhead.
> 
> This is all for driver debugging. The point of lockdep is to find all
> these paths without have to hit them as actual races, using debug
> kernels.
> 
> I don't think we need this kind of debugging on production kernels?

Again, the primary motivation was a simple debugging aid that could be
used without worrying about overhead. So lockdep is very often out of
the question.

> > > The best we got was drivers tested the VA range and returned success
> > > if they had no interest. Which is a big win to be sure, but it looks
> > > like getting any more is not really posssible.
> > 
> > And that is already a great win! Because many notifiers only do care
> > about particular mappings. Please note that backing off unconditioanlly
> > will simply cause that the oom reaper will have to back off not doing
> > any tear down anything.
> 
> Well, I'm working to propose that we do the VA range test under core
> mmu notifier code that cannot block and then we simply remove the idea
> of blockable from drivers using this new 'range notifier'. 
> 
> I think this pretty much solves the concern?

Well, my idea was that a range check and early bail out was a first step
and then each specific notifier would be able to do a more specific
check. I was not able to do the second step because that requires a deep
understanding of the respective subsystem.

Really all I do care about is to reclaim as much memory from the
oom_reaper context as possible. And that cannot really be an unbounded
process. Quite contrary it should be as swift as possible. From my
cursory look some notifiers are able to achieve their task without
blocking or depending on memory just fine. So bailing out
unconditionally on the range of interest would just put us back.

> > > However, we could (probably even should) make the drivers fs_reclaim
> > > safe.
> > > 
> > > If that is enough to guarantee progress of OOM, then lets consider
> > > something like using current_gfp_context() to force PF_MEMALLOC_NOFS
> > > allocation behavior on the driver callback and lockdep to try and keep
> > > pushing on the the debugging, and dropping !blocking.
> > 
> > How are you going to enforce indirect dependency? E.g. a lock that is
> > also used in other context which depend on sleepable memory allocation
> > to move forward.
> 
> You mean like this:
> 
>CPU0 CPU1
> mutex_lock()
> kmalloc(GFP_KERNEL)

no I mean __GFP_DIRECT_RECLAIM here.

> mutex_unlock()
>   fs_reclaim_acquire()
>   mutex_lock() <- illegal: lock dep assertion

I cannot really comment on how that is achieveable by lockdep. I managed
to forget details about FS/IO reclaim recursion tracking already and I
do not have time to learn it again. It was quite a hack. Anyway, let me
repeat that the primary motivation was a simple aid. Not something as
poverful as lockdep.
-- 
Michal Hocko
SUSE Labs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 22/22] drm/i915/mst: Do not hardcoded the crtcs that encoder can connect

2019-08-15 Thread James Ausmus
On Thu, Jul 18, 2019 at 04:10:13PM +0300, Ville Syrjälä wrote:
> On Fri, Jul 12, 2019 at 06:09:40PM -0700, Lucas De Marchi wrote:
> > From: José Roberto de Souza 
> > 
> > Tiger Lake has up to 4 pipes so the mask would need to be 0xf instead of
> > 0x7. Do not hardcode the mask so it allows the fake MST encoders to
> > connect to all pipes no matter how many the platform has.
> > 
> > Iterating over all pipes to keep consistent with intel_ddi_init().
> > 
> > Cc: Lucas De Marchi 
> > Cc: Ville Syrjälä 
> > Signed-off-by: José Roberto de Souza 
> > Signed-off-by: Lucas De Marchi 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
> > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > index 60652ebbdf61..1b79b6befa92 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > @@ -586,6 +586,8 @@ intel_dp_create_fake_mst_encoder(struct 
> > intel_digital_port *intel_dig_port, enum
> > struct intel_dp_mst_encoder *intel_mst;
> > struct intel_encoder *intel_encoder;
> > struct drm_device *dev = intel_dig_port->base.base.dev;
> > +   struct drm_i915_private *dev_priv = to_i915(dev);
> > +   enum pipe pipe_iter;
> >  
> > intel_mst = kzalloc(sizeof(*intel_mst), GFP_KERNEL);
> >  
> > @@ -602,8 +604,9 @@ intel_dp_create_fake_mst_encoder(struct 
> > intel_digital_port *intel_dig_port, enum
> > intel_encoder->type = INTEL_OUTPUT_DP_MST;
> > intel_encoder->power_domain = intel_dig_port->base.power_domain;
> > intel_encoder->port = intel_dig_port->base.port;
> > -   intel_encoder->crtc_mask = 0x7;
> > intel_encoder->cloneable = 0;
> > +   for_each_pipe(dev_priv, pipe_iter)
> > +   intel_encoder->crtc_mask |= BIT(pipe_iter);
> 
> https://patchwork.freedesktop.org/patch/316555/?series=63399=1

Would it make sense to bring this patch in for now for TGL MST, until
that larger series can land?

-James

> 
> >  
> > intel_encoder->compute_config = intel_dp_mst_compute_config;
> > intel_encoder->disable = intel_mst_disable_dp;
> > -- 
> > 2.21.0
> 
> -- 
> Ville Syrjälä
> Intel
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

2019-08-15 Thread Jerome Glisse
On Thu, Aug 15, 2019 at 02:35:57PM -0300, Jason Gunthorpe wrote:
> On Thu, Aug 15, 2019 at 06:25:16PM +0200, Daniel Vetter wrote:
> 
> > I'm not really well versed in the details of our userptr, but both
> > amdgpu and i915 wait for the gpu to complete from
> > invalidate_range_start. Jerome has at least looked a lot at the amdgpu
> > one, so maybe he can explain what exactly it is we're doing ...
> 
> amdgpu is (wrongly) using hmm for something, I can't really tell what
> it is trying to do. The calls to dma_fence under the
> invalidate_range_start do not give me a good feeling.
> 
> However, i915 shows all the signs of trying to follow the registration
> cache model, it even has a nice comment in
> i915_gem_userptr_get_pages() explaining that the races it has don't
> matter because it is a user space bug to change the VA mapping in the
> first place. That just screams registration cache to me.
> 
> So it is fine to run HW that way, but if you do, there is no reason to
> fence inside the invalidate_range end. Just orphan the DMA buffer and
> clean it up & release the page pins when all DMA buffer refs go to
> zero. The next access to that VA should get a new DMA buffer with the
> right mapping.
> 
> In other words the invalidation should be very simple without
> complicated locking, or wait_event's. Look at hfi1 for example.

This would break the today usage model of uptr and it will
break userspace expectation ie if GPU is writting to that
memory and that memory then the userspace want to make sure
that it will see what the GPU write.

Yes i915 is broken in respect to not having a end notifier
and tracking active invalidation for a range but the GUP
side of thing kind of hide this bug and it shrinks the window
for bad to happen to something so small that i doubt anyone
could ever hit it (still a bug thought).

Cheers,
Jérôme
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

2019-08-15 Thread Jerome Glisse
On Thu, Aug 15, 2019 at 07:21:47PM +0200, Daniel Vetter wrote:
> On Thu, Aug 15, 2019 at 7:16 PM Jason Gunthorpe  wrote:
> >
> > On Thu, Aug 15, 2019 at 12:32:38PM -0400, Jerome Glisse wrote:
> > > On Thu, Aug 15, 2019 at 12:10:28PM -0300, Jason Gunthorpe wrote:
> > > > On Thu, Aug 15, 2019 at 04:43:38PM +0200, Daniel Vetter wrote:
> > > >
> > > > > You have to wait for the gpu to finnish current processing in
> > > > > invalidate_range_start. Otherwise there's no point to any of this
> > > > > really. So the wait_event/dma_fence_wait are unavoidable really.
> > > >
> > > > I don't envy your task :|
> > > >
> > > > But, what you describe sure sounds like a 'registration cache' model,
> > > > not the 'shadow pte' model of coherency.
> > > >
> > > > The key difference is that a regirstationcache is allowed to become
> > > > incoherent with the VMA's because it holds page pins. It is a
> > > > programming bug in userspace to change VA mappings via mmap/munmap/etc
> > > > while the device is working on that VA, but it does not harm system
> > > > integrity because of the page pin.
> > > >
> > > > The cache ensures that each initiated operation sees a DMA setup that
> > > > matches the current VA map when the operation is initiated and allows
> > > > expensive device DMA setups to be re-used.
> > > >
> > > > A 'shadow pte' model (ie hmm) *really* needs device support to
> > > > directly block DMA access - ie trigger 'device page fault'. ie the
> > > > invalidate_start should inform the device to enter a fault mode and
> > > > that is it.  If the device can't do that, then the driver probably
> > > > shouldn't persue this level of coherency. The driver would quickly get
> > > > into the messy locking problems like dma_fence_wait from a notifier.
> > >
> > > I think here we do not agree on the hardware requirement. For GPU
> > > we will always need to be able to wait for some GPU fence from inside
> > > the notifier callback, there is just no way around that for many of
> > > the GPUs today (i do not see any indication of that changing).
> >
> > I didn't say you couldn't wait, I was trying to say that the wait
> > should only be contigent on the HW itself. Ie you can wait on a GPU
> > page table lock, and you can wait on a GPU page table flush completion
> > via IRQ.
> >
> > What is troubling is to wait till some other thread gets a GPU command
> > completion and decr's a kref on the DMA buffer - which kinda looks
> > like what this dma_fence() stuff is all about. A driver like that
> > would have to be super careful to ensure consistent forward progress
> > toward dma ref == 0 when the system is under reclaim.
> >
> > ie by running it's entire IRQ flow under fs_reclaim locking.
> 
> This is correct. At least for i915 it's already a required due to our
> shrinker also having to do the same. I think amdgpu isn't bothering
> with that since they have vram for most of the stuff, and just limit
> system memory usage to half of all and forgo the shrinker. Probably
> not the nicest approach. Anyway, both do the same mmu_notifier dance,
> just want to explain that we've been living with this for longer
> already.
> 
> So yeah writing a gpu driver is not easy.
> 
> > > associated with the mm_struct. In all GPU driver so far it is a short
> > > lived lock and nothing blocking is done while holding it (it is just
> > > about updating page table directory really wether it is filling it or
> > > clearing it).
> >
> > The main blocking I expect in a shadow PTE flow is waiting for the HW
> > to complete invalidations of its PTE cache.
> >
> > > > It is important to identify what model you are going for as defining a
> > > > 'registration cache' coherence expectation allows the driver to skip
> > > > blocking in invalidate_range_start. All it does is invalidate the
> > > > cache so that future operations pick up the new VA mapping.
> > > >
> > > > Intel's HFI RDMA driver uses this model extensively, and I think it is
> > > > well proven, within some limitations of course.
> > > >
> > > > At least, 'registration cache' is the only use model I know of where
> > > > it is acceptable to skip invalidate_range_end.
> > >
> > > Here GPU are not in the registration cache model, i know it might looks
> > > like it because of GUP but GUP was use just because hmm did not exist
> > > at the time.
> >
> > It is not because of GUP, it is because of the lack of
> > invalidate_range_end. A driver cannot correctly implement the SPTE
> > model without invalidate_range_end, even if it holds the page pins via
> > GUP.
> >
> > So, I've been assuming the few drivers without invalidate_range_end
> > are trying to do registration caching, rather than assuming they are
> > broken.
> 
> I915 might just be broken. amdgpu does the full thing, using
> hmm_mirror. But still with dma_fence_wait.

Yeah i915 is broken but it never hurted anyone ;) I posted patch
a long time ago to convert it to hmm but i delayed that to until
i can get through making 

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

2019-08-15 Thread Daniel Vetter
On Thu, Aug 15, 2019 at 7:16 PM Jason Gunthorpe  wrote:
>
> On Thu, Aug 15, 2019 at 12:32:38PM -0400, Jerome Glisse wrote:
> > On Thu, Aug 15, 2019 at 12:10:28PM -0300, Jason Gunthorpe wrote:
> > > On Thu, Aug 15, 2019 at 04:43:38PM +0200, Daniel Vetter wrote:
> > >
> > > > You have to wait for the gpu to finnish current processing in
> > > > invalidate_range_start. Otherwise there's no point to any of this
> > > > really. So the wait_event/dma_fence_wait are unavoidable really.
> > >
> > > I don't envy your task :|
> > >
> > > But, what you describe sure sounds like a 'registration cache' model,
> > > not the 'shadow pte' model of coherency.
> > >
> > > The key difference is that a regirstationcache is allowed to become
> > > incoherent with the VMA's because it holds page pins. It is a
> > > programming bug in userspace to change VA mappings via mmap/munmap/etc
> > > while the device is working on that VA, but it does not harm system
> > > integrity because of the page pin.
> > >
> > > The cache ensures that each initiated operation sees a DMA setup that
> > > matches the current VA map when the operation is initiated and allows
> > > expensive device DMA setups to be re-used.
> > >
> > > A 'shadow pte' model (ie hmm) *really* needs device support to
> > > directly block DMA access - ie trigger 'device page fault'. ie the
> > > invalidate_start should inform the device to enter a fault mode and
> > > that is it.  If the device can't do that, then the driver probably
> > > shouldn't persue this level of coherency. The driver would quickly get
> > > into the messy locking problems like dma_fence_wait from a notifier.
> >
> > I think here we do not agree on the hardware requirement. For GPU
> > we will always need to be able to wait for some GPU fence from inside
> > the notifier callback, there is just no way around that for many of
> > the GPUs today (i do not see any indication of that changing).
>
> I didn't say you couldn't wait, I was trying to say that the wait
> should only be contigent on the HW itself. Ie you can wait on a GPU
> page table lock, and you can wait on a GPU page table flush completion
> via IRQ.
>
> What is troubling is to wait till some other thread gets a GPU command
> completion and decr's a kref on the DMA buffer - which kinda looks
> like what this dma_fence() stuff is all about. A driver like that
> would have to be super careful to ensure consistent forward progress
> toward dma ref == 0 when the system is under reclaim.
>
> ie by running it's entire IRQ flow under fs_reclaim locking.

This is correct. At least for i915 it's already a required due to our
shrinker also having to do the same. I think amdgpu isn't bothering
with that since they have vram for most of the stuff, and just limit
system memory usage to half of all and forgo the shrinker. Probably
not the nicest approach. Anyway, both do the same mmu_notifier dance,
just want to explain that we've been living with this for longer
already.

So yeah writing a gpu driver is not easy.

> > associated with the mm_struct. In all GPU driver so far it is a short
> > lived lock and nothing blocking is done while holding it (it is just
> > about updating page table directory really wether it is filling it or
> > clearing it).
>
> The main blocking I expect in a shadow PTE flow is waiting for the HW
> to complete invalidations of its PTE cache.
>
> > > It is important to identify what model you are going for as defining a
> > > 'registration cache' coherence expectation allows the driver to skip
> > > blocking in invalidate_range_start. All it does is invalidate the
> > > cache so that future operations pick up the new VA mapping.
> > >
> > > Intel's HFI RDMA driver uses this model extensively, and I think it is
> > > well proven, within some limitations of course.
> > >
> > > At least, 'registration cache' is the only use model I know of where
> > > it is acceptable to skip invalidate_range_end.
> >
> > Here GPU are not in the registration cache model, i know it might looks
> > like it because of GUP but GUP was use just because hmm did not exist
> > at the time.
>
> It is not because of GUP, it is because of the lack of
> invalidate_range_end. A driver cannot correctly implement the SPTE
> model without invalidate_range_end, even if it holds the page pins via
> GUP.
>
> So, I've been assuming the few drivers without invalidate_range_end
> are trying to do registration caching, rather than assuming they are
> broken.

I915 might just be broken. amdgpu does the full thing, using
hmm_mirror. But still with dma_fence_wait.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915/uc: Fini hw even if GuC is not running

2019-08-15 Thread Fernando Pacheco
We should not be skipping uc_fini_hw on finding GuC
is no longer running. There is plenty of hw and internal
state that can be cleaned up without having to communicate
with GuC.

v2: better to check if fw is available (Michal)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110943
Signed-off-by: Fernando Pacheco 
Cc: Daniele Ceraolo Spurio 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 0dc2b0cf4604..67dec7dcc26f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -521,7 +521,7 @@ void intel_uc_fini_hw(struct intel_uc *uc)
 {
struct intel_guc *guc = >guc;
 
-   if (!intel_guc_is_running(guc))
+   if (!intel_uc_fw_is_available(>fw))
return;
 
if (intel_uc_supports_guc_submission(uc))
-- 
2.22.1

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

[Intel-gfx] [PATCH 2/5] drm/i915/wopcm: Check WOPCM layout separately from calculations

2019-08-15 Thread Michal Wajdeczko
We can do WOPCM partitioning using rough estimates and limits
and perform detailed check as separate step.

Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_wopcm.c | 105 -
 1 file changed, 74 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_wopcm.c 
b/drivers/gpu/drm/i915/intel_wopcm.c
index 2975e00f57f5..3ac05055bb08 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -87,7 +87,8 @@ void intel_wopcm_init_early(struct intel_wopcm *wopcm)
else
wopcm->size = GEN9_WOPCM_SIZE;
 
-   DRM_DEBUG_DRIVER("WOPCM size: %uKiB\n", wopcm->size / 1024);
+   DRM_DEV_DEBUG_DRIVER(i915->drm.dev, "WOPCM: size %uKiB\n",
+wopcm->size / SZ_1K);
 }
 
 static inline u32 context_reserved_size(struct drm_i915_private *i915)
@@ -138,9 +139,9 @@ static inline int gen9_check_huc_fw_fits(u32 
guc_wopcm_size, u32 huc_fw_size)
return 0;
 }
 
-static inline int check_hw_restriction(struct drm_i915_private *i915,
-  u32 guc_wopcm_base, u32 guc_wopcm_size,
-  u32 huc_fw_size)
+static inline bool check_hw_restrictions(struct drm_i915_private *i915,
+u32 guc_wopcm_base, u32 guc_wopcm_size,
+u32 huc_fw_size)
 {
int err = 0;
 
@@ -151,7 +152,64 @@ static inline int check_hw_restriction(struct 
drm_i915_private *i915,
(IS_GEN(i915, 9) || IS_CNL_REVID(i915, CNL_REVID_A0, CNL_REVID_A0)))
err = gen9_check_huc_fw_fits(guc_wopcm_size, huc_fw_size);
 
-   return err;
+   return !err;
+}
+
+static inline bool __check_layout(struct drm_i915_private *i915, u32 
wopcm_size,
+ u32 guc_wopcm_base, u32 guc_wopcm_size,
+ u32 guc_fw_size, u32 huc_fw_size)
+{
+   const u32 ctx_rsvd = context_reserved_size(i915);
+   u32 size;
+
+   if (unlikely(guc_wopcm_base > wopcm_size)) {
+   dev_err(i915->drm.dev,
+   "WOPCM: invalid GuC region base: %uK > %uK\n",
+   guc_wopcm_base / SZ_1K, wopcm_size / SZ_1K);
+   return false;
+   }
+
+   size = wopcm_size - ctx_rsvd;
+   if (unlikely(guc_wopcm_base > size)) {
+   dev_err(i915->drm.dev,
+   "WOPCM: invalid GuC region base: %uK > %uK\n",
+   guc_wopcm_base / SZ_1K, size / SZ_1K);
+   return false;
+   }
+
+   if (unlikely(guc_wopcm_size > wopcm_size)) {
+   dev_err(i915->drm.dev,
+   "WOPCM: invalid GuC region size: %uK > %uK\n",
+   guc_wopcm_size / SZ_1K, wopcm_size / SZ_1K);
+   return false;
+   }
+
+   size = wopcm_size - guc_wopcm_base - ctx_rsvd;
+   if (unlikely(guc_wopcm_size > size)) {
+   dev_err(i915->drm.dev,
+   "WOPCM: invalid GuC region size: %uK > %uK\n",
+   guc_wopcm_size / SZ_1K, size / SZ_1K);
+   return false;
+   }
+
+   size = guc_fw_size + GUC_WOPCM_RESERVED + GUC_WOPCM_STACK_RESERVED;
+   if (unlikely(guc_wopcm_size < size)) {
+   dev_err(i915->drm.dev, "WOPCM: no space for %s: %uK < %uK\n",
+   intel_uc_fw_type_repr(INTEL_UC_FW_TYPE_GUC),
+   guc_wopcm_size / SZ_1K, size / SZ_1K);
+   return false;
+   }
+
+   size = huc_fw_size + WOPCM_RESERVED_SIZE;
+   if (unlikely(guc_wopcm_base < size)) {
+   dev_err(i915->drm.dev, "WOPCM: no space for %s: %uK < %uK\n",
+   intel_uc_fw_type_repr(INTEL_UC_FW_TYPE_HUC),
+   guc_wopcm_base / SZ_1K, size / SZ_1K);
+   return false;
+   }
+
+   return check_hw_restrictions(i915, guc_wopcm_base, guc_wopcm_size,
+huc_fw_size);
 }
 
 /**
@@ -172,8 +230,6 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
u32 ctx_rsvd = context_reserved_size(i915);
u32 guc_wopcm_base;
u32 guc_wopcm_size;
-   u32 guc_wopcm_rsvd;
-   int err;
 
if (!guc_fw_size)
return;
@@ -183,39 +239,26 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
GEM_BUG_ON(wopcm->guc.size);
GEM_BUG_ON(guc_fw_size >= wopcm->size);
GEM_BUG_ON(huc_fw_size >= wopcm->size);
+   GEM_BUG_ON(ctx_rsvd + WOPCM_RESERVED_SIZE >= wopcm->size);
 
if (i915_inject_probe_failure(i915))
return;
 
guc_wopcm_base = ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
   GUC_WOPCM_OFFSET_ALIGNMENT);
-   if ((guc_wopcm_base + ctx_rsvd) >= wopcm->size) {
-   DRM_ERROR("GuC WOPCM base (%uKiB) is too big.\n",
-   

[Intel-gfx] [PATCH 3/5] drm/i915/wopcm: Try to use already locked WOPCM layout

2019-08-15 Thread Michal Wajdeczko
If WOPCM layout is already locked in HW we shouldn't continue
with our own partitioning as it could be likely different and
we will be unable to enforce it and fail. Instead we should try
to reuse what is already programmed, maybe there will be a fit.

This should enable us to reload driver with slightly different
HuC firmware (or even without HuC) without need to reboot.

v2: reordered/rebased

Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
Cc: Michal Winiarski 
---
 drivers/gpu/drm/i915/intel_wopcm.c | 29 +++--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_wopcm.c 
b/drivers/gpu/drm/i915/intel_wopcm.c
index 3ac05055bb08..ea02efb653a7 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -212,6 +212,21 @@ static inline bool __check_layout(struct drm_i915_private 
*i915, u32 wopcm_size,
 huc_fw_size);
 }
 
+static bool __wopcm_regs_locked(struct intel_uncore *uncore,
+   u32 *guc_wopcm_base, u32 *guc_wopcm_size)
+{
+   u32 reg_base = intel_uncore_read(uncore, DMA_GUC_WOPCM_OFFSET);
+   u32 reg_size = intel_uncore_read(uncore, GUC_WOPCM_SIZE);
+
+   if (!(reg_size & GUC_WOPCM_SIZE_LOCKED) ||
+   !(reg_base & GUC_WOPCM_OFFSET_VALID))
+   return false;
+
+   *guc_wopcm_base = reg_base & GUC_WOPCM_OFFSET_MASK;
+   *guc_wopcm_size = reg_size & GUC_WOPCM_SIZE_MASK;
+   return true;
+}
+
 /**
  * intel_wopcm_init() - Initialize the WOPCM structure.
  * @wopcm: pointer to intel_wopcm.
@@ -225,8 +240,9 @@ static inline bool __check_layout(struct drm_i915_private 
*i915, u32 wopcm_size,
 void intel_wopcm_init(struct intel_wopcm *wopcm)
 {
struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
-   u32 guc_fw_size = intel_uc_fw_get_upload_size(>gt.uc.guc.fw);
-   u32 huc_fw_size = intel_uc_fw_get_upload_size(>gt.uc.huc.fw);
+   struct intel_gt *gt = >gt;
+   u32 guc_fw_size = intel_uc_fw_get_upload_size(>uc.guc.fw);
+   u32 huc_fw_size = intel_uc_fw_get_upload_size(>uc.huc.fw);
u32 ctx_rsvd = context_reserved_size(i915);
u32 guc_wopcm_base;
u32 guc_wopcm_size;
@@ -244,6 +260,14 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
if (i915_inject_probe_failure(i915))
return;
 
+   if (__wopcm_regs_locked(gt->uncore, _wopcm_base, _wopcm_size)) {
+   DRM_DEV_DEBUG_DRIVER(i915->drm.dev,
+"GuC WOPCM is already locked [%uK, %uK)\n",
+guc_wopcm_base / SZ_1K,
+guc_wopcm_size / SZ_1K);
+   goto check;
+   }
+
guc_wopcm_base = ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
   GUC_WOPCM_OFFSET_ALIGNMENT);
guc_wopcm_base = max(wopcm->size - ctx_rsvd, guc_wopcm_base);
@@ -254,6 +278,7 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
 "Calculated GuC WOPCM Region: [%uKiB, %uKiB)\n",
 guc_wopcm_base / SZ_1K, guc_wopcm_size / SZ_1K);
 
+check:
if (__check_layout(i915, wopcm->size, guc_wopcm_base, guc_wopcm_size,
   guc_fw_size, huc_fw_size)) {
wopcm->guc.base = guc_wopcm_base;
-- 
2.19.2

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

[Intel-gfx] [PATCH 4/5] drm/i915/wopcm: Update error messages

2019-08-15 Thread Michal Wajdeczko
All WOPCM error messages are device specific, so use
device specific error functions.

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_wopcm.c | 44 --
 1 file changed, 24 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_wopcm.c 
b/drivers/gpu/drm/i915/intel_wopcm.c
index ea02efb653a7..3b14dd5562ff 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -101,7 +101,8 @@ static inline u32 context_reserved_size(struct 
drm_i915_private *i915)
return 0;
 }
 
-static inline int gen9_check_dword_gap(u32 guc_wopcm_base, u32 guc_wopcm_size)
+static inline bool gen9_check_dword_gap(struct drm_i915_private *i915,
+   u32 guc_wopcm_base, u32 guc_wopcm_size)
 {
u32 offset;
 
@@ -113,16 +114,18 @@ static inline int gen9_check_dword_gap(u32 
guc_wopcm_base, u32 guc_wopcm_size)
offset = guc_wopcm_base + GEN9_GUC_WOPCM_OFFSET;
if (offset > guc_wopcm_size ||
(guc_wopcm_size - offset) < sizeof(u32)) {
-   DRM_ERROR("GuC WOPCM size %uKiB is too small. %uKiB needed.\n",
- guc_wopcm_size / 1024,
- (u32)(offset + sizeof(u32)) / 1024);
-   return -E2BIG;
+   dev_err(i915->drm.dev,
+   "WOPCM: invalid GuC region size: %uK < %uK\n",
+   guc_wopcm_size / SZ_1K,
+   (u32)(offset + sizeof(u32)) / SZ_1K);
+   return false;
}
 
-   return 0;
+   return true;
 }
 
-static inline int gen9_check_huc_fw_fits(u32 guc_wopcm_size, u32 huc_fw_size)
+static inline bool gen9_check_huc_fw_fits(struct drm_i915_private *i915,
+ u32 guc_wopcm_size, u32 huc_fw_size)
 {
/*
 * On Gen9 & CNL A0, hardware requires the total available GuC WOPCM
@@ -130,29 +133,30 @@ static inline int gen9_check_huc_fw_fits(u32 
guc_wopcm_size, u32 huc_fw_size)
 * firmware uploading would fail.
 */
if (huc_fw_size > guc_wopcm_size - GUC_WOPCM_RESERVED) {
-   DRM_ERROR("HuC FW (%uKiB) won't fit in GuC WOPCM (%uKiB).\n",
- huc_fw_size / 1024,
- (guc_wopcm_size - GUC_WOPCM_RESERVED) / 1024);
-   return -E2BIG;
+   dev_err(i915->drm.dev, "WOPCM: no space for %s: %uK < %uK\n",
+   intel_uc_fw_type_repr(INTEL_UC_FW_TYPE_HUC),
+   (guc_wopcm_size - GUC_WOPCM_RESERVED) / SZ_1K,
+   huc_fw_size / 1024);
+   return false;
}
 
-   return 0;
+   return true;
 }
 
 static inline bool check_hw_restrictions(struct drm_i915_private *i915,
 u32 guc_wopcm_base, u32 guc_wopcm_size,
 u32 huc_fw_size)
 {
-   int err = 0;
-
-   if (IS_GEN(i915, 9))
-   err = gen9_check_dword_gap(guc_wopcm_base, guc_wopcm_size);
+   if (IS_GEN(i915, 9) && !gen9_check_dword_gap(i915, guc_wopcm_base,
+guc_wopcm_size))
+   return false;
 
-   if (!err &&
-   (IS_GEN(i915, 9) || IS_CNL_REVID(i915, CNL_REVID_A0, CNL_REVID_A0)))
-   err = gen9_check_huc_fw_fits(guc_wopcm_size, huc_fw_size);
+   if ((IS_GEN(i915, 9) ||
+IS_CNL_REVID(i915, CNL_REVID_A0, CNL_REVID_A0)) &&
+   !gen9_check_huc_fw_fits(i915, guc_wopcm_size, huc_fw_size))
+   return false;
 
-   return !err;
+   return true;
 }
 
 static inline bool __check_layout(struct drm_i915_private *i915, u32 
wopcm_size,
-- 
2.19.2

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gen11: Allow usage of all GPIO pins

2019-08-15 Thread Patchwork
== Series Details ==

Series: drm/i915/gen11: Allow usage of all GPIO pins
URL   : https://patchwork.freedesktop.org/series/65261/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6712 -> Patchwork_14031


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_14031 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_14031, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14031/

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_14031:

### IGT changes ###

 Possible regressions 

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-skl-6700k2:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-skl-6700k2/igt@kms_chamel...@common-hpd-after-suspend.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14031/fi-skl-6700k2/igt@kms_chamel...@common-hpd-after-suspend.html

  
 Warnings 

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-skl-6700k2:  [FAIL][3] ([fdo#111407]) -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-skl-6700k2/igt@kms_chamel...@hdmi-hpd-fast.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14031/fi-skl-6700k2/igt@kms_chamel...@hdmi-hpd-fast.html

  
Known issues


  Here are the changes found in Patchwork_14031 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-hsw-4770:[PASS][5] -> [SKIP][6] ([fdo#109271])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-hsw-4770/igt@i915_pm_...@basic-pci-d3-state.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14031/fi-hsw-4770/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@kms_busy@basic-flip-a:
- fi-skl-iommu:   [PASS][7] -> [SKIP][8] ([fdo#109271] / [fdo#109278]) 
+2 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-skl-iommu/igt@kms_b...@basic-flip-a.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14031/fi-skl-iommu/igt@kms_b...@basic-flip-a.html
- fi-skl-6260u:   [PASS][9] -> [SKIP][10] ([fdo#109271] / [fdo#109278]) 
+2 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-skl-6260u/igt@kms_b...@basic-flip-a.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14031/fi-skl-6260u/igt@kms_b...@basic-flip-a.html
- fi-bdw-gvtdvm:  [PASS][11] -> [SKIP][12] ([fdo#109271] / 
[fdo#109278]) +2 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-bdw-gvtdvm/igt@kms_b...@basic-flip-a.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14031/fi-bdw-gvtdvm/igt@kms_b...@basic-flip-a.html

  * igt@kms_busy@basic-flip-b:
- fi-bdw-5557u:   [PASS][13] -> [SKIP][14] ([fdo#109271] / 
[fdo#109278]) +2 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-bdw-5557u/igt@kms_b...@basic-flip-b.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14031/fi-bdw-5557u/igt@kms_b...@basic-flip-b.html
- fi-skl-gvtdvm:  [PASS][15] -> [SKIP][16] ([fdo#109271] / 
[fdo#109278]) +2 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-skl-gvtdvm/igt@kms_b...@basic-flip-b.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14031/fi-skl-gvtdvm/igt@kms_b...@basic-flip-b.html
- fi-cfl-guc: [PASS][17] -> [SKIP][18] ([fdo#109271] / 
[fdo#109278]) +2 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-cfl-guc/igt@kms_b...@basic-flip-b.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14031/fi-cfl-guc/igt@kms_b...@basic-flip-b.html
- fi-cfl-8700k:   [PASS][19] -> [SKIP][20] ([fdo#109271] / 
[fdo#109278]) +2 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-cfl-8700k/igt@kms_b...@basic-flip-b.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14031/fi-cfl-8700k/igt@kms_b...@basic-flip-b.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-skl-6700k2:  [PASS][21] -> [FAIL][22] ([fdo#90]) +1 similar 
issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-skl-6700k2/igt@kms_chamel...@hdmi-crc-fast.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14031/fi-skl-6700k2/igt@kms_chamel...@hdmi-crc-fast.html

  * igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size:
- fi-skl-iommu:   [PASS][23] -> [SKIP][24] ([fdo#109271]) +23 similar 
issues
   [23]: 

[Intel-gfx] [PATCH 5/5] drm/i915/wopmc: Fix SPDX tag location

2019-08-15 Thread Michal Wajdeczko
Move SPDX tag to first line, and update year to 2019.

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_wopcm.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_wopcm.c 
b/drivers/gpu/drm/i915/intel_wopcm.c
index 3b14dd5562ff..53fe1003fba7 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -1,7 +1,6 @@
+// SPDX-License-Identifier: MIT
 /*
- * SPDX-License-Identifier: MIT
- *
- * Copyright © 2017-2018 Intel Corporation
+ * Copyright © 2017-2019 Intel Corporation
  */
 
 #include "intel_wopcm.h"
-- 
2.19.2

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

[Intel-gfx] [PATCH 0/5] More WOPCM fixes

2019-08-15 Thread Michal Wajdeczko
More WOPCM fixes

Michal Wajdeczko (4):
  drm/i915/wopcm: Check WOPCM layout separately from calculations
  drm/i915/wopcm: Try to use already locked WOPCM layout
  drm/i915/wopcm: Update error messages
  drm/i915/wopmc: Fix SPDX tag location

Michał Winiarski (1):
  drm/i915/uc: Move FW size sanity check back to fetch

 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c |  11 ++
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h |   7 +-
 drivers/gpu/drm/i915/intel_wopcm.c   | 191 +++
 3 files changed, 143 insertions(+), 66 deletions(-)

-- 
2.19.2

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

[Intel-gfx] [PATCH 1/5] drm/i915/uc: Move FW size sanity check back to fetch

2019-08-15 Thread Michal Wajdeczko
From: Michał Winiarski 

While we need to know WOPCM size to do this sanity check, it has more to
do with FW than with WOPCM. Let's move the check to fetch phase, it's
not like WOPCM is going to grow in the meantime.

v2: rebased
v3: use __intel_uc_fw_get_upload_size (Daniele)

Signed-off-by: Michał Winiarski 
Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
Cc: Jackie Li 
Cc: Joonas Lahtinen 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 11 +++
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h |  7 ++-
 drivers/gpu/drm/i915/intel_wopcm.c   | 14 ++
 3 files changed, 19 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index d056e1f4bd6d..f4a34ea579fd 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -265,6 +265,7 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct 
drm_i915_private *i915)
size_t size;
int err;
 
+   GEM_BUG_ON(!i915->wopcm.size);
GEM_BUG_ON(!intel_uc_fw_supported(uc_fw));
 
err = i915_inject_load_error(i915, -ENXIO);
@@ -324,6 +325,16 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct 
drm_i915_private *i915)
goto fail;
}
 
+   /* Sanity check whether this fw is not larger than whole WOPCM memory */
+   size = __intel_uc_fw_get_upload_size(uc_fw);
+   if (unlikely(size >= i915->wopcm.size)) {
+   dev_warn(dev, "%s firmware %s: invalid size: %zu > %zu\n",
+intel_uc_fw_type_repr(uc_fw->type), uc_fw->path,
+size, (size_t)i915->wopcm.size);
+   err = -E2BIG;
+   goto fail;
+   }
+
/* Get version numbers from the CSS header */
switch (uc_fw->type) {
case INTEL_UC_FW_TYPE_GUC:
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
index ce8e83128a95..6fa50273c2ce 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
@@ -173,6 +173,11 @@ static inline void intel_uc_fw_sanitize(struct intel_uc_fw 
*uc_fw)
intel_uc_fw_change_status(uc_fw, INTEL_UC_FIRMWARE_AVAILABLE);
 }
 
+static inline u32 __intel_uc_fw_get_upload_size(struct intel_uc_fw *uc_fw)
+{
+   return sizeof(struct uc_css_header) + uc_fw->ucode_size;
+}
+
 /**
  * intel_uc_fw_get_upload_size() - Get size of firmware needed to be uploaded.
  * @uc_fw: uC firmware.
@@ -186,7 +191,7 @@ static inline u32 intel_uc_fw_get_upload_size(struct 
intel_uc_fw *uc_fw)
if (!intel_uc_fw_is_available(uc_fw))
return 0;
 
-   return sizeof(struct uc_css_header) + uc_fw->ucode_size;
+   return __intel_uc_fw_get_upload_size(uc_fw);
 }
 
 void intel_uc_fw_init_early(struct intel_uc_fw *uc_fw,
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c 
b/drivers/gpu/drm/i915/intel_wopcm.c
index 2bda24200498..2975e00f57f5 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -181,22 +181,12 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
GEM_BUG_ON(!wopcm->size);
GEM_BUG_ON(wopcm->guc.base);
GEM_BUG_ON(wopcm->guc.size);
+   GEM_BUG_ON(guc_fw_size >= wopcm->size);
+   GEM_BUG_ON(huc_fw_size >= wopcm->size);
 
if (i915_inject_probe_failure(i915))
return;
 
-   if (guc_fw_size >= wopcm->size) {
-   DRM_ERROR("GuC FW (%uKiB) is too big to fit in WOPCM.",
- guc_fw_size / 1024);
-   return;
-   }
-
-   if (huc_fw_size >= wopcm->size) {
-   DRM_ERROR("HuC FW (%uKiB) is too big to fit in WOPCM.",
- huc_fw_size / 1024);
-   return;
-   }
-
guc_wopcm_base = ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
   GUC_WOPCM_OFFSET_ALIGNMENT);
if ((guc_wopcm_base + ctx_rsvd) >= wopcm->size) {
-- 
2.19.2

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

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

2019-08-15 Thread Jerome Glisse
On Thu, Aug 15, 2019 at 01:56:31PM -0300, Jason Gunthorpe wrote:
> On Thu, Aug 15, 2019 at 06:00:41PM +0200, Michal Hocko wrote:
> 
> > > AFAIK 'GFP_NOWAIT' is characterized by the lack of __GFP_FS and
> > > __GFP_DIRECT_RECLAIM..
> > >
> > > This matches the existing test in __need_fs_reclaim() - so if you are
> > > OK with GFP_NOFS, aka __GFP_IO which triggers try_to_compact_pages(),
> > > allocations during OOM, then I think fs_reclaim already matches what
> > > you described?
> > 
> > No GFP_NOFS is equally bad. Please read my other email explaining what
> > the oom_reaper actually requires. In short no blocking on direct or
> > indirect dependecy on memory allocation that might sleep.
> 
> It is much easier to follow with some hints on code, so the true
> requirement is that the OOM repear not block on GFP_FS and GFP_IO
> allocations, great, that constraint is now clear.
> 
> > If you can express that in the existing lockdep machinery. All
> > fine. But then consider deployments where lockdep is no-no because
> > of the overhead.
> 
> This is all for driver debugging. The point of lockdep is to find all
> these paths without have to hit them as actual races, using debug
> kernels.
> 
> I don't think we need this kind of debugging on production kernels?
> 
> > > The best we got was drivers tested the VA range and returned success
> > > if they had no interest. Which is a big win to be sure, but it looks
> > > like getting any more is not really posssible.
> > 
> > And that is already a great win! Because many notifiers only do care
> > about particular mappings. Please note that backing off unconditioanlly
> > will simply cause that the oom reaper will have to back off not doing
> > any tear down anything.
> 
> Well, I'm working to propose that we do the VA range test under core
> mmu notifier code that cannot block and then we simply remove the idea
> of blockable from drivers using this new 'range notifier'. 
> 
> I think this pretty much solves the concern?

I am not sure i follow what you propose here ? Like i pointed out in
another email for GPU we do need to be able to sleep (we might get
lucky and not need too but this is runtime thing) within notifier
range_start callback. This has been something allow by notifier since
it has been introduced in the kernel.

Cheers,
Jérôme
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  1   2   >