Re: [Intel-gfx] [PATCH] drm/i915/GuC: Combine the two kernel parameter into one

[Jeff McGee]

On Wed, Nov 09, 2016 at 11:11:07AM -0800, Anusha Srivatsa wrote:
> Replace i915.enable_guc_loading and i915.enable_guc_submission
> with a single parameter - i915.enable_guc. Where:
> 
> -1 : Platform default (Only load GuC)
> 0 : Do not use GuC
> 1 : Load GuC, do not use Command Submission through GuC
> 2 : Load and use GuC for Command Submission
> 
I think this approach could get ugly as we add more GuC functionality and
the list of combinations under this one parameter grows.

What is the issue we are trying to solve? I thought it was that folks
didn't like that we had an option to just load GuC and do nothing with it.
Can those folks please comment?

Jeff
> Cc: Tvrtko Ursulin 
> Cc: Jeff Mcgee 
> Cc: Rodrigo Vivi 
> Signed-off-by: Anusha Srivatsa 
> ---
>  drivers/gpu/drm/i915/i915_guc_submission.c | 16 +---
>  drivers/gpu/drm/i915/i915_params.c | 17 +
>  drivers/gpu/drm/i915/i915_params.h |  3 +--
>  drivers/gpu/drm/i915/intel_guc.h   |  2 ++
>  drivers/gpu/drm/i915/intel_guc_loader.c| 39 
> +++---
>  drivers/gpu/drm/i915/intel_lrc.c   | 14 ---
>  6 files changed, 56 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
> b/drivers/gpu/drm/i915/i915_guc_submission.c
> index 7809acf..a5ef268 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -1471,13 +1471,15 @@ int i915_guc_submission_init(struct drm_i915_private 
> *dev_priv)
>   const size_t poolsize = GUC_MAX_GPU_CONTEXTS * ctxsize;
>   const size_t gemsize = round_up(poolsize, PAGE_SIZE);
>   struct intel_guc *guc = _priv->guc;
> + struct intel_uc_fw *guc_fw = _priv->guc.guc_fw;
> +
>   struct i915_vma *vma;
>  
>   /* Wipe bitmap & delete client in case of reinitialisation */
>   bitmap_clear(guc->doorbell_bitmap, 0, GUC_MAX_DOORBELLS);
>   i915_guc_submission_disable(dev_priv);
>  
> - if (!i915.enable_guc_submission)
> + if (!guc_fw->enable_guc_submission)
>   return 0; /* not enabled  */
>  
>   if (guc->ctx_pool_vma)
> @@ -1629,7 +1631,9 @@ void i915_guc_capture_logs(struct drm_i915_private 
> *dev_priv)
>  
>  void i915_guc_flush_logs(struct drm_i915_private *dev_priv)
>  {
> - if (!i915.enable_guc_submission || (i915.guc_log_level < 0))
> + struct intel_uc_fw *guc_fw = _priv->guc.guc_fw;
> +
> + if (!guc_fw->enable_guc_submission || (i915.guc_log_level < 0))
>   return;
>  
>   /* First disable the interrupts, will be renabled afterwards */
> @@ -1649,7 +1653,9 @@ void i915_guc_flush_logs(struct drm_i915_private 
> *dev_priv)
>  
>  void i915_guc_unregister(struct drm_i915_private *dev_priv)
>  {
> - if (!i915.enable_guc_submission)
> + struct intel_uc_fw *guc_fw = _priv->guc.guc_fw;
> +
> + if (!guc_fw->enable_guc_submission)
>   return;
>  
>   mutex_lock(_priv->drm.struct_mutex);
> @@ -1659,7 +1665,9 @@ void i915_guc_unregister(struct drm_i915_private 
> *dev_priv)
>  
>  void i915_guc_register(struct drm_i915_private *dev_priv)
>  {
> - if (!i915.enable_guc_submission)
> + struct intel_uc_fw *guc_fw = _priv->guc.guc_fw;
> +
> + if (!guc_fw->enable_guc_submission)
>   return;
>  
>   mutex_lock(_priv->drm.struct_mutex);
> diff --git a/drivers/gpu/drm/i915/i915_params.c 
> b/drivers/gpu/drm/i915/i915_params.c
> index 629e433..4600f83 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -56,8 +56,7 @@ struct i915_params i915 __read_mostly = {
>   .verbose_state_checks = 1,
>   .nuclear_pageflip = 0,
>   .edp_vswing = 0,
> - .enable_guc_loading = 0,
> - .enable_guc_submission = 0,
> + .enable_guc = 0,
>   .guc_log_level = -1,
>   .enable_dp_mst = true,
>   .inject_load_failure = 0,
> @@ -215,15 +214,11 @@ MODULE_PARM_DESC(edp_vswing,
>"(0=use value from vbt [default], 1=low power swing(200mV),"
>"2=default swing(400mV))");
>  
> -module_param_named_unsafe(enable_guc_loading, i915.enable_guc_loading, int, 
> 0400);
> -MODULE_PARM_DESC(enable_guc_loading,
> - "Enable GuC firmware loading "
> - "(-1=auto, 0=never [default], 1=if available, 2=required)");
> -
> -module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission, 
> int, 0400);
> -MODULE_PARM_DESC(enable_guc_submission,
> - "Enable GuC submission "
> - "(-1=auto, 0=never [default], 1=if available, 2=required)");
> +module_param_named_unsafe(enable_guc, i915.enable_guc, int, 0400);
> +MODULE_PARM_DESC(enable_guc,
> + "Enable GuC firmware loading and loading and submission"
> + "(-1=auto [default], 0=do not use GuC, 1=load only,"
> + "2=loading and 

Re: [Intel-gfx] [PATCH 5/8] drm/i915/HuC: Add KBL huC loading Support

[Jeff McGee]

Reviewed-by: Jeff McGee 

On Thu, Nov 10, 2016 at 04:15:18PM -0800, Anusha Srivatsa wrote:
> This patch adds the support to load HuC on KBL
> Version 2.0
> 
> Cc: Jeff Mcgee 
> Signed-off-by: Anusha Srivatsa 
> ---
>  drivers/gpu/drm/i915/intel_huc_loader.c | 15 ++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c 
> b/drivers/gpu/drm/i915/intel_huc_loader.c
> index 5a7ce65..dab64ba 100644
> --- a/drivers/gpu/drm/i915/intel_huc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_huc_loader.c
> @@ -49,6 +49,10 @@
>  #define BXT_FW_MINOR 07
>  #define BXT_BLD_NUM 1398
>  
> +#define KBL_FW_MAJOR 02
> +#define KBL_FW_MINOR 00
> +#define KBL_BLD_NUM 1810
> +
>  #define HUC_FW_PATH(platform, major, minor, bld_num) \
>   "i915/" __stringify(platform) "_huc_ver" __stringify(major) "_" \
>   __stringify(minor) "_" __stringify(bld_num) ".bin"
> @@ -60,6 +64,11 @@ MODULE_FIRMWARE(I915_SKL_HUC_UCODE);
>  #define I915_BXT_HUC_UCODE HUC_FW_PATH(bxt, BXT_FW_MAJOR, \
>   BXT_FW_MINOR, BXT_BLD_NUM)
>  MODULE_FIRMWARE(I915_BXT_HUC_UCODE);
> +
> +#define I915_KBL_HUC_UCODE HUC_FW_PATH(kbl, KBL_FW_MAJOR, \
> + KBL_FW_MINOR, KBL_BLD_NUM)
> +MODULE_FIRMWARE(I915_KBL_HUC_UCODE);
> +
>  /**
>   * huc_ucode_xfer() - DMA's the firmware
>   * @dev_priv: the drm device
> @@ -171,8 +180,12 @@ void intel_huc_init(struct drm_device *dev)
>   fw_path = I915_BXT_HUC_UCODE;
>   huc_fw->major_ver_wanted = BXT_FW_MAJOR;
>   huc_fw->minor_ver_wanted = BXT_FW_MINOR;
> + } else if (IS_KABYLAKE(dev_priv)) {
> + fw_path = I915_KBL_HUC_UCODE;
> + huc_fw->major_ver_wanted = KBL_FW_MAJOR;
> + huc_fw->minor_ver_wanted = KBL_FW_MINOR;
>   }
> -
> + 
>   if (fw_path == NULL)
>   return;
>  
> -- 
> 2.7.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/huc: Add BXT HuC Loading Support

[Jeff McGee]

Reviewed-by: Jeff McGee 

On Thu, Nov 10, 2016 at 04:15:17PM -0800, Anusha Srivatsa wrote:
> This patch adds the HuC Loading for the BXT by using
> the updated file construction.
> 
> Version 1.7 of the HuC firmware.
> 
> Cc: Jeff Mcgee 
> Signed-off-by: Anusha Srivatsa 
> ---
>  drivers/gpu/drm/i915/intel_huc_loader.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c 
> b/drivers/gpu/drm/i915/intel_huc_loader.c
> index 8d2b6ab..5a7ce65 100644
> --- a/drivers/gpu/drm/i915/intel_huc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_huc_loader.c
> @@ -45,6 +45,10 @@
>  #define SKL_BLD_NUM 1398
>  #define I915_SKL_HUC_UCODE "i915/skl_huc_ver01_07_1398.bin"
>  
> +#define BXT_FW_MAJOR 01
> +#define BXT_FW_MINOR 07
> +#define BXT_BLD_NUM 1398
> +
>  #define HUC_FW_PATH(platform, major, minor, bld_num) \
>   "i915/" __stringify(platform) "_huc_ver" __stringify(major) "_" \
>   __stringify(minor) "_" __stringify(bld_num) ".bin"
> @@ -53,6 +57,9 @@
>   SKL_FW_MINOR, SKL_BLD_NUM)
>  MODULE_FIRMWARE(I915_SKL_HUC_UCODE);
>  
> +#define I915_BXT_HUC_UCODE HUC_FW_PATH(bxt, BXT_FW_MAJOR, \
> + BXT_FW_MINOR, BXT_BLD_NUM)
> +MODULE_FIRMWARE(I915_BXT_HUC_UCODE);
>  /**
>   * huc_ucode_xfer() - DMA's the firmware
>   * @dev_priv: the drm device
> @@ -160,7 +167,11 @@ void intel_huc_init(struct drm_device *dev)
>   fw_path = I915_SKL_HUC_UCODE;
>   huc_fw->major_ver_wanted = SKL_FW_MAJOR;
>   huc_fw->minor_ver_wanted = SKL_FW_MINOR;
> - }
> + } else if (IS_BROXTON(dev_priv)) {
> + fw_path = I915_BXT_HUC_UCODE;
> + huc_fw->major_ver_wanted = BXT_FW_MAJOR;
> + huc_fw->minor_ver_wanted = BXT_FW_MINOR;
> + }
>  
>   if (fw_path == NULL)
>   return;
> -- 
> 2.7.4
> 
___
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/huc: Add HuC fw loading support

[Jeff McGee]

On Fri, Nov 11, 2016 at 06:05:34PM -0800, Jeff McGee wrote:
> On Thu, Nov 10, 2016 at 04:15:16PM -0800, Anusha Srivatsa wrote:
> > From: Peter Antoine 
> > 
> > The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
> > is used for both cases.
> > 
> > HuC loading needs to be before GuC loading. The WOPCM setting must
> > be done early before loading any of them.
> > 
> > v2: rebased on-top of drm-intel-nightly.
> > removed if(HAS_GUC()) before the guc call. (D.Gordon)
> > update huc_version number of format.
> > v3: rebased to drm-intel-nightly, changed the file name format to
> > match the one in the huc package.
> > Changed dev->dev_private to to_i915()
> > v4: moved function back to where it was.
> > change wait_for_atomic to wait_for.
> > v5: rebased + comment changes.
> > v7: rebased.
> > v8: rebased.
> > v9: rebased. Changed the year in the copyright message to reflect
> > the right year.Correct the comments,remove the unwanted WARN message,
> > replace drm_gem_object_unreference() with i915_gem_object_put().Make the
> > prototypes in intel_huc.h non-extern.
> > v10: rebased. Update the file construction done by HuC. It is similar to
> > GuC.Adopted the approach used in-
> > https://patchwork.freedesktop.org/patch/104355/ 
> > 
> > Cc: Tvrtko Ursulin 
> > Tested-by: Xiang Haihao 
> > Signed-off-by: Anusha Srivatsa 
> > Signed-off-by: Alex Dai 
> > Signed-off-by: Peter Antoine 
> > Reviewed-by: Dave Gordon 
> > ---
> >  drivers/gpu/drm/i915/Makefile   |   1 +
> >  drivers/gpu/drm/i915/i915_drv.h |   3 +
> >  drivers/gpu/drm/i915/i915_guc_reg.h |   3 +
> >  drivers/gpu/drm/i915/intel_guc.h|   1 +
> >  drivers/gpu/drm/i915/intel_guc_loader.c |   6 +-
> >  drivers/gpu/drm/i915/intel_huc.h|  42 +
> >  drivers/gpu/drm/i915/intel_huc_loader.c | 270 
> > 
> >  7 files changed, 324 insertions(+), 2 deletions(-)
> >  create mode 100644 drivers/gpu/drm/i915/intel_huc.h
> >  create mode 100644 drivers/gpu/drm/i915/intel_huc_loader.c
> > 
> > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> > index 0857e50..c99b0ee 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -55,6 +55,7 @@ i915-y += i915_cmd_parser.o \
> >  
> >  # general-purpose microcontroller (GuC) support
> >  i915-y += intel_guc_loader.o \
> > + intel_huc_loader.o \
> >   i915_guc_submission.o
> >  
> >  # autogenerated null render state
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 30777de..ebef982 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -56,6 +56,7 @@
> >  #include "intel_bios.h"
> >  #include "intel_dpll_mgr.h"
> >  #include "intel_guc.h"
> > +#include "intel_huc.h"
> >  #include "intel_lrc.h"
> >  #include "intel_ringbuffer.h"
> >  
> > @@ -1804,6 +1805,7 @@ struct drm_i915_private {
> >  
> > struct intel_gvt *gvt;
> >  
> > +   struct intel_huc huc;
> > struct intel_guc guc;
> >  
> > struct intel_csr csr;
> > @@ -2928,6 +2930,7 @@ struct drm_i915_cmd_table {
> >  #define HAS_GUC(dev)   (INTEL_INFO(dev)->has_guc)
> >  #define HAS_GUC_UCODE(dev) (HAS_GUC(dev))
> >  #define HAS_GUC_SCHED(dev) (HAS_GUC(dev))
> > +#define HAS_HUC_UCODE(dev) (HAS_GUC(dev))
> >  
> >  #define HAS_RESOURCE_STREAMER(dev) (INTEL_INFO(dev)->has_resource_streamer)
> >  
> > diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h 
> > b/drivers/gpu/drm/i915/i915_guc_reg.h
> > index a47e1e4..64e942a 100644
> > --- a/drivers/gpu/drm/i915/i915_guc_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_guc_reg.h
> > @@ -61,9 +61,12 @@
> >  #define   DMA_ADDRESS_SPACE_GTT  (8 << 16)
> >  #define DMA_COPY_SIZE  _MMIO(0xc310)
> >  #define DMA_CTRL   _MMIO(0xc314)
> > +#define   HUC_UKERNEL(1<<9)
> >  #define   UOS_MOVE   (1<<4)
> >  #define   START_DMA  (1<<0)
> >  #define DMA_GUC_WOPCM_OFFSET   _MMIO(0xc340)
> > +#define   HUC_LOADING_AGENT_VCR  (0<<1)
> > +#define   HUC_LOADING_AGENT_GUC  (1<<1)
> >  #define   GUC_WOPCM_OFFSET_VALUE 0x8   /* 512KB */
> >  #define GUC_MAX_IDLE_COUNT _MMIO(0xC3E4)
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_guc.h 
> > b/drivers/gpu/drm/i915/intel_guc.h
> > index 45dfa40..ff6aba6 100644
> > --- a/drivers/gpu/drm/i915/intel_guc.h
> > +++ b/drivers/gpu/drm/i915/intel_guc.h
> > @@ -183,6 +183,7 @@ extern const char *intel_uc_fw_status_repr(enum 
> > intel_uc_fw_status status);
> >  extern int intel_guc_suspend(struct drm_device *dev);
> >  extern int intel_guc_resume(struct drm_device *dev);
> >  void 

Re: [Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support

[Jeff McGee]

On Thu, Nov 10, 2016 at 04:15:16PM -0800, Anusha Srivatsa wrote:
> From: Peter Antoine 
> 
> The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
> is used for both cases.
> 
> HuC loading needs to be before GuC loading. The WOPCM setting must
> be done early before loading any of them.
> 
> v2: rebased on-top of drm-intel-nightly.
> removed if(HAS_GUC()) before the guc call. (D.Gordon)
> update huc_version number of format.
> v3: rebased to drm-intel-nightly, changed the file name format to
> match the one in the huc package.
> Changed dev->dev_private to to_i915()
> v4: moved function back to where it was.
> change wait_for_atomic to wait_for.
> v5: rebased + comment changes.
> v7: rebased.
> v8: rebased.
> v9: rebased. Changed the year in the copyright message to reflect
> the right year.Correct the comments,remove the unwanted WARN message,
> replace drm_gem_object_unreference() with i915_gem_object_put().Make the
> prototypes in intel_huc.h non-extern.
> v10: rebased. Update the file construction done by HuC. It is similar to
> GuC.Adopted the approach used in-
> https://patchwork.freedesktop.org/patch/104355/ 
> 
> Cc: Tvrtko Ursulin 
> Tested-by: Xiang Haihao 
> Signed-off-by: Anusha Srivatsa 
> Signed-off-by: Alex Dai 
> Signed-off-by: Peter Antoine 
> Reviewed-by: Dave Gordon 
> ---
>  drivers/gpu/drm/i915/Makefile   |   1 +
>  drivers/gpu/drm/i915/i915_drv.h |   3 +
>  drivers/gpu/drm/i915/i915_guc_reg.h |   3 +
>  drivers/gpu/drm/i915/intel_guc.h|   1 +
>  drivers/gpu/drm/i915/intel_guc_loader.c |   6 +-
>  drivers/gpu/drm/i915/intel_huc.h|  42 +
>  drivers/gpu/drm/i915/intel_huc_loader.c | 270 
> 
>  7 files changed, 324 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/intel_huc.h
>  create mode 100644 drivers/gpu/drm/i915/intel_huc_loader.c
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 0857e50..c99b0ee 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -55,6 +55,7 @@ i915-y += i915_cmd_parser.o \
>  
>  # general-purpose microcontroller (GuC) support
>  i915-y += intel_guc_loader.o \
> +   intel_huc_loader.o \
> i915_guc_submission.o
>  
>  # autogenerated null render state
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 30777de..ebef982 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -56,6 +56,7 @@
>  #include "intel_bios.h"
>  #include "intel_dpll_mgr.h"
>  #include "intel_guc.h"
> +#include "intel_huc.h"
>  #include "intel_lrc.h"
>  #include "intel_ringbuffer.h"
>  
> @@ -1804,6 +1805,7 @@ struct drm_i915_private {
>  
>   struct intel_gvt *gvt;
>  
> + struct intel_huc huc;
>   struct intel_guc guc;
>  
>   struct intel_csr csr;
> @@ -2928,6 +2930,7 @@ struct drm_i915_cmd_table {
>  #define HAS_GUC(dev) (INTEL_INFO(dev)->has_guc)
>  #define HAS_GUC_UCODE(dev)   (HAS_GUC(dev))
>  #define HAS_GUC_SCHED(dev)   (HAS_GUC(dev))
> +#define HAS_HUC_UCODE(dev)   (HAS_GUC(dev))
>  
>  #define HAS_RESOURCE_STREAMER(dev) (INTEL_INFO(dev)->has_resource_streamer)
>  
> diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h 
> b/drivers/gpu/drm/i915/i915_guc_reg.h
> index a47e1e4..64e942a 100644
> --- a/drivers/gpu/drm/i915/i915_guc_reg.h
> +++ b/drivers/gpu/drm/i915/i915_guc_reg.h
> @@ -61,9 +61,12 @@
>  #define   DMA_ADDRESS_SPACE_GTT(8 << 16)
>  #define DMA_COPY_SIZE_MMIO(0xc310)
>  #define DMA_CTRL _MMIO(0xc314)
> +#define   HUC_UKERNEL  (1<<9)
>  #define   UOS_MOVE (1<<4)
>  #define   START_DMA(1<<0)
>  #define DMA_GUC_WOPCM_OFFSET _MMIO(0xc340)
> +#define   HUC_LOADING_AGENT_VCR(0<<1)
> +#define   HUC_LOADING_AGENT_GUC(1<<1)
>  #define   GUC_WOPCM_OFFSET_VALUE   0x8   /* 512KB */
>  #define GUC_MAX_IDLE_COUNT   _MMIO(0xC3E4)
>  
> diff --git a/drivers/gpu/drm/i915/intel_guc.h 
> b/drivers/gpu/drm/i915/intel_guc.h
> index 45dfa40..ff6aba6 100644
> --- a/drivers/gpu/drm/i915/intel_guc.h
> +++ b/drivers/gpu/drm/i915/intel_guc.h
> @@ -183,6 +183,7 @@ extern const char *intel_uc_fw_status_repr(enum 
> intel_uc_fw_status status);
>  extern int intel_guc_suspend(struct drm_device *dev);
>  extern int intel_guc_resume(struct drm_device *dev);
>  void intel_uc_fw_fetch(struct drm_device *dev, struct intel_uc_fw *uc_fw);
> +u32 guc_wopcm_size(struct drm_i915_private *dev_priv);
>  
>  /* i915_guc_submission.c */
>  int i915_guc_submission_init(struct drm_i915_private *dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
> 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: move allocation out of drm_get_format_name() (rev4)

[Patchwork]

== Series Details ==

Series: drm: move allocation out of drm_get_format_name() (rev4)
URL   : https://patchwork.freedesktop.org/series/14873/
State : success

== Summary ==

Series 14873v4 drm: move allocation out of drm_get_format_name()
https://patchwork.freedesktop.org/api/1.0/series/14873/revisions/4/mbox/


fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

75c991da15a4f67572515019e4fb8ed292457563 drm-intel-nightly: 
2016y-11m-11d-16h-22m-04s UTC integration manifest
3512576 drm: move allocation out of drm_get_format_name()

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2974/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v4] drm: move allocation out of drm_get_format_name()

[Eric Engestrom]

The function's behaviour was changed in 90844f00049e, without changing
its signature, causing people to keep using it the old way without
realising they were now leaking memory.
Rob Clark also noticed it was also allocating GFP_KERNEL memory in
atomic contexts, breaking them.

Instead of having to allocate GFP_ATOMIC memory and fixing the callers
to make them cleanup the memory afterwards, let's change the function's
signature by having the caller take care of the memory and passing it to
the function.
The new parameter is a single-field struct in order to enforce the size
of its buffer and help callers to correctly manage their memory.

Fixes: 90844f00049e ("drm: make drm_get_format_name thread-safe")
Cc: Rob Clark 
Cc: Christian König 
Acked-by: Christian König 
Acked-by: Rob Clark 
Acked-by: Sinclair Yeh  (vmwgfx)
Reviewed-by: Jani Nikula 
Suggested-by: Ville Syrjälä 
Signed-off-by: Eric Engestrom 
---
v4 - rebase on drm-next (d8c1abd968f1c880ad8c)
   - add missed `const` to the return value

v3 - fix "Fixes" tag, replace it with an actual commit message
   - collect ack & r-b

v2 - use single-field struct instead of typedef to let the compiler
 enforce the type (Christian König)
---
 include/drm/drm_fourcc.h| 10 +-
 drivers/gpu/drm/drm_fourcc.c| 14 +++--
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |  7 ++---
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |  7 ++---
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c   |  3 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |  7 ++---
 drivers/gpu/drm/drm_atomic.c| 10 +++---
 drivers/gpu/drm/drm_crtc.c  |  7 +++--
 drivers/gpu/drm/drm_framebuffer.c   |  7 +++--
 drivers/gpu/drm/drm_modeset_helper.c|  7 +++--
 drivers/gpu/drm/drm_plane.c |  7 +++--
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  7 ++---
 drivers/gpu/drm/i915/i915_debugfs.c | 10 +++---
 drivers/gpu/drm/i915/intel_atomic_plane.c   |  8 ++---
 drivers/gpu/drm/i915/intel_display.c| 41 ++---
 drivers/gpu/drm/radeon/atombios_crtc.c  | 14 -
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  3 +-
 17 files changed, 82 insertions(+), 87 deletions(-)

diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index dc0aafa..fcc08da 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -45,6 +45,14 @@ struct drm_format_info {
u8 vsub;
 };
 
+/**
+ * struct drm_format_name_buf - name of a DRM format
+ * @str: string buffer containing the format name
+ */
+struct drm_format_name_buf {
+   char str[32];
+};
+
 const struct drm_format_info *__drm_format_info(u32 format);
 const struct drm_format_info *drm_format_info(u32 format);
 uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth);
@@ -54,6 +62,6 @@ int drm_format_horz_chroma_subsampling(uint32_t format);
 int drm_format_vert_chroma_subsampling(uint32_t format);
 int drm_format_plane_width(int width, uint32_t format, int plane);
 int drm_format_plane_height(int height, uint32_t format, int plane);
-char *drm_get_format_name(uint32_t format) __malloc;
+const char *drm_get_format_name(uint32_t format, struct drm_format_name_buf 
*buf);
 
 #endif /* __DRM_FOURCC_H__ */
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index cbb8b77..90d2cc8 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -79,17 +79,13 @@ uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t 
depth)
 EXPORT_SYMBOL(drm_mode_legacy_fb_format);
 
 /**
- * drm_get_format_name - return a string for drm fourcc format
+ * drm_get_format_name - fill a string with a drm fourcc format's name
  * @format: format to compute name of
+ * @buf: caller-supplied buffer
- *
- * Note that the buffer returned by this function is owned by the caller
- * and will need to be freed using kfree().
  */
-char *drm_get_format_name(uint32_t format)
+const char *drm_get_format_name(uint32_t format, struct drm_format_name_buf 
*buf)
 {
-   char *buf = kmalloc(32, GFP_KERNEL);
-
-   snprintf(buf, 32,
+   snprintf(buf->str, sizeof(buf->str),
 "%c%c%c%c %s-endian (0x%08x)",
 printable_char(format & 0xff),
 printable_char((format >> 8) & 0xff),
@@ -98,7 +94,7 @@ char *drm_get_format_name(uint32_t format)
 format & DRM_FORMAT_BIG_ENDIAN ? "big" : "little",
 format);
 
-   return buf;
+   return buf->str;
 }
 EXPORT_SYMBOL(drm_get_format_name);
 
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 679dd73..65a954c 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ 

Re: [Intel-gfx] [PATCH igt v3 11/11] igt/gem_exec_parse: check oacontrol lri bad for >= v9

[Matthew Auld]

On 9 November 2016 at 16:16, Robert Bragg  wrote:
> OACONTROL is no longer white listed in the command parser so this checks
> at attempted LRI will be disallowed and (more importantly) checks that
> userspace doesn't get an EINVAL error for an attempted OACONTROL LRI.
> This is important becase Mesa application attempt OACONTROL LRIs while
> initializing and will abort for any execbuf error.
>
> Signed-off-by: Robert Bragg 
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 igt v3 10/11] igt/gem_exec_parse: update registers test for v >= 8

[Matthew Auld]

On 9 November 2016 at 16:16, Robert Bragg  wrote:
> This combines some parts of the recently added store_lri test with the
> registers test to be able to first load a distinguishable value before
> the LRI and explicitly read back the register to determine if the
> command succeeded or was a NOOP.
>
> For now though we won't look at OACONTROL without checking for version 9
> of the command parser.
>
> This updates the 'bad' test to check the OASTATUS2 register so that we
> can explicitly read back from the register to check it becomes a NOOP.
>
> This adds a struct test_lri for associating a mask with the init/test
> values so we ignore things like hw status bits that might interfere
> with the result.
>
> Signed-off-by: Robert Bragg 
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 igt v3 09/11] igt/gem_exec_parse: update hsw_load_register_reg for v >= 8

[Matthew Auld]

On 9 November 2016 at 16:16, Robert Bragg  wrote:
> This updates the checking of disallowed loads to set a distinguishable
> value before the load and explicitly check the load was a NOOP by
> reading back the final value.
>
> Signed-off-by: Robert Bragg 
> ---
>  tests/gem_exec_parse.c | 20 ++--
>  1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
> index d6a2885..f241ab7 100644
> --- a/tests/gem_exec_parse.c
> +++ b/tests/gem_exec_parse.c
> @@ -305,12 +305,17 @@ static void hsw_load_register_reg(void)
> };
> int fd;
> uint32_t handle;
> +   int parser_version;
> +   int bad_lrr_errno;
>
> /* Open again to get a non-master file descriptor */
> fd = drm_open_driver(DRIVER_INTEL);
>
> +   parser_version = command_parser_version(fd);
Ah, I was reading ahead, so move this to the fixture and re-use ?

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 igt v3 08/11] igt/gem_exec_parse: update cmd-crossing-page for >= v8

[Matthew Auld]

On 9 November 2016 at 16:15, Robert Bragg  wrote:
> Since an access violation won't return an error to userspace for v >= 8
> of the command parser this updates the cmd-crossing-page test to
> explicitly read back from SO_WRITE_OFFSET[0] to see that the command
> wasn't squashed to a NOOP.
>
> Signed-off-by: Robert Bragg 
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 igt v3 07/11] igt/gem_exec_parse: update bitmasks test for v >=8

[Matthew Auld]

On 9 November 2016 at 16:15, Robert Bragg  wrote:
> With v8 of the command parser (where we won't get an EINVAL for an
> access violation) this updates the bitmasks test to explicitly confirm
> that the command became a NOOP by reading back from where the QW_WRITE
> would have otherwise landed.
>
> Signed-off-by: Robert Bragg 
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 igt v3 05/11] igt/gem_exec_parse: req. v < 9 for oacontrol tracking test

[Matthew Auld]

On 9 November 2016 at 16:15, Robert Bragg  wrote:
> This limits testing the oacontrol tracking (required pairing of oa
> enable/disable per batch buffer) to version <= 8 of the command parser.
>
> Version 9 of the command parser removes all special handling for
> OACONTROL which is now going to be managed by i915-perf and not
> programmed from userspace.
>
> Signed-off-by: Robert Bragg 
Fancy cleaning up the open coded parser_version get param business in
the fixture, and also make it so we do it only once ?

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 igt v3 04/11] igt/gem_exec_parse: update hsw_load_register_reg

[Matthew Auld]

On 9 November 2016 at 16:15, Robert Bragg  wrote:
> This generalises hsw_load_register_reg to loop through an array of
> allowed and disallowed registers and to use the exec_batch[_patched]
> utilities.
>
> Signed-off-by: Robert Bragg 
> ---
>  tests/gem_exec_parse.c | 139 
> +++--
>  1 file changed, 66 insertions(+), 73 deletions(-)
>
> diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
> index c530bb6..2fea060 100644
> --- a/tests/gem_exec_parse.c
> +++ b/tests/gem_exec_parse.c
> @@ -34,8 +34,11 @@
>  #define I915_PARAM_CMD_PARSER_VERSION   28
>  #endif
>
> -#define OACONTROL 0x2360
> +#define ARRAY_LEN(A) (sizeof(A) / sizeof(A[0]))
We have ARRAY_SIZE.

> +
>  #define DERRMR 0x44050
> +#define OACONTROL 0x2360
> +#define SO_WRITE_OFFSET_0 0x5280
>
>  #define HSW_CS_GPR(n) (0x2600 + 8*(n))
>  #define HSW_CS_GPR0 HSW_CS_GPR(0)
> @@ -65,8 +68,8 @@ static int command_parser_version(int fd)
> return -1;
>  }
>
> -static void exec_batch_patched(int fd, uint32_t cmd_bo, uint32_t *cmds,
> -  int size, int patch_offset, uint64_t 
> expected_value)
> +static uint64_t __exec_batch_patched(int fd, uint32_t cmd_bo, uint32_t *cmds,
> +int size, int patch_offset)
>  {
> struct drm_i915_gem_execbuffer2 execbuf;
> struct drm_i915_gem_exec_object2 obj[2];
> @@ -100,9 +103,19 @@ static void exec_batch_patched(int fd, uint32_t cmd_bo, 
> uint32_t *cmds,
> gem_sync(fd, cmd_bo);
>
> gem_read(fd,target_bo, 0, _value, sizeof(actual_value));
> -   igt_assert_eq(expected_value, actual_value);
>
> gem_close(fd, target_bo);
> +
> +   return actual_value;
> +}
> +
> +static void exec_batch_patched(int fd, uint32_t cmd_bo, uint32_t *cmds,
> +  int size, int patch_offset,
> +  uint64_t expected_value)
> +{
> +   igt_assert_eq(__exec_batch_patched(fd, cmd_bo, cmds,
> +  size, patch_offset),
> + expected_value);
Formatting seems off.

Seems reasonable so:
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 igt v3 03/11] igt/gem_exec_parse: move hsw_load_register_reg down

[Matthew Auld]

On 9 November 2016 at 16:15, Robert Bragg  wrote:
> No functional change, just moving hsw_load_regster_reg test code down
s/regster/register
> below the execbuf utilities in preparation for updating to use them.
>
> Signed-off-by: Robert Bragg 
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 igt v3 02/11] igt/gem_exec_parse: some minor cleanups

[Matthew Auld]

On 9 November 2016 at 16:15, Robert Bragg  wrote:
> This normalizes the execbuf utilities in this file to all use memset to
> clear obj, reloc and execbuf structures and set them up in the same
> order. As I was debugging some unpredictable test failures I was getting
> unsure that all these structures were being fully initialized.
>
> The same I915_GEM_DOMAIN_COMMAND domain is now used with all relocs.
>
> The register/command defines have been moved to the top of the file to
> be available to all tests/utilities.
>
> The handle + fd variables are now static.
>
> Signed-off-by: Robert Bragg 
Okay seems reasonable.

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 v2] drm/i915/dp: Update connector status for DP MST hotplugs

[Daniel Vetter]

On Mon, Nov 07, 2016 at 04:27:30PM -0800, Dhinakaran Pandiyan wrote:
> Hotplugging a monitor in DP MST configuration triggers short pulses.
> Although the short pulse handling path ends up in the MST hotplug function,
> we do not perform a detect before sending the hotplug uvent. This leads to
> the connector status not being updated when the userspace calls
> DRM_IOCTL_MODE_GETCONNECTOR.
> 
> So, let's call the connector function ->detect() to update the connector
> status before sending the uevent.
> 
> v2: Update connector status inside mode_config mutex (Ville)
> 
> Signed-off-by: Dhinakaran Pandiyan 

quick comments from me on irc:

 dhnkrn, really tricky I think
 dhnkrn, also feels wrong from an entire design pov
 I'd expect the topology manager could tell us from which exact 
downstream port the short pulse came
 which means we should be able to get at that connector without taking 
the global lock
 i.e. at least avoid the for_each_connector
 on the detect itself, I need to think
 but we might need to essentially postpone the ->detect work to the 
hotplug worker
 except that it's not a direct hpd from our chip
 but a downstream one
 this is going to be fun
 Hmm .. Does updating the connector status need the lock or is it the 
detect() ?
 yup
 and we might need to do additional dpcd transactions (e.g. for load 
detect probing on downstream ports)
 or at least edid reads
 both recurse back into dp mst helper code like ville said
 dhnkrn, so instead of doing the detect work from the hotplug code
 put them on some list
 need to be careful in case they are already there
 list only protected with dedicated lock
 then launch the hpd worker
 and walk that list from there, with the mode_config.mutex to do the 
full-on probe
 we can't call ->detect from dig_port_work, and walking the entire 
connector list in there is also not a good idea imo
 dhnkrn, but that's just my preliminary analysis from like 10 minutes 
of thinking and checking what ville raised
 needs more thought probably
 dhnkrn, to clarify your question: both connector->status and calling 
->detect need mode_config.mutex
 that mutex is what protects output probe state ccr: i might 
have udev configured incorrectly then

Cheers, Daniel
> ---
>  drivers/gpu/drm/i915/intel_dp_mst.c | 22 +-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 3ffbd69..8e36a96 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -492,8 +492,28 @@ static void intel_dp_mst_hotplug(struct 
> drm_dp_mst_topology_mgr *mgr)
>   struct intel_dp *intel_dp = container_of(mgr, struct intel_dp, mst_mgr);
>   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>   struct drm_device *dev = intel_dig_port->base.base.dev;
> + struct intel_connector *intel_connector;
> + bool changed = false;
> + enum drm_connector_status old_status;
> + struct drm_mode_config *mode_config = >mode_config;
> +
> + mutex_lock(_config->mutex);
> + for_each_intel_connector(dev, intel_connector) {
> + struct drm_connector *connector = &(intel_connector->base);
> +
> + if (intel_connector->mst_port != intel_dp)
> + continue;
> +
> + old_status = connector->status;
> + connector->status = connector->funcs->detect(connector, false);
> +
> + if (old_status != connector->status)
> + changed = true;
> + }
> + mutex_unlock(_config->mutex);
>  
> - drm_kms_helper_hotplug_event(dev);
> + if (changed)
> + drm_kms_helper_hotplug_event(dev);
>  }
>  
>  static const struct drm_dp_mst_topology_cbs mst_cbs = {
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH v2] drm/i915/dp: Update connector status for DP MST hotplugs

[Ville Syrjälä]

On Fri, Nov 11, 2016 at 08:43:53PM +, Pandiyan, Dhinakaran wrote:
> On Tue, 2016-11-08 at 13:04 +0200, Ville Syrjälä wrote:
> > On Mon, Nov 07, 2016 at 04:27:30PM -0800, Dhinakaran Pandiyan wrote:
> > > Hotplugging a monitor in DP MST configuration triggers short pulses.
> > > Although the short pulse handling path ends up in the MST hotplug 
> > > function,
> > > we do not perform a detect before sending the hotplug uvent. This leads to
> > > the connector status not being updated when the userspace calls
> > > DRM_IOCTL_MODE_GETCONNECTOR.
> > > 
> > > So, let's call the connector function ->detect() to update the connector
> > > status before sending the uevent.
> > > 
> > > v2: Update connector status inside mode_config mutex (Ville)
> > > 
> > > Signed-off-by: Dhinakaran Pandiyan 
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp_mst.c | 22 +-
> > >  1 file changed, 21 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> > > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > index 3ffbd69..8e36a96 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > @@ -492,8 +492,28 @@ static void intel_dp_mst_hotplug(struct 
> > > drm_dp_mst_topology_mgr *mgr)
> > >   struct intel_dp *intel_dp = container_of(mgr, struct intel_dp, mst_mgr);
> > >   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > >   struct drm_device *dev = intel_dig_port->base.base.dev;
> > > + struct intel_connector *intel_connector;
> > > + bool changed = false;
> > > + enum drm_connector_status old_status;
> > > + struct drm_mode_config *mode_config = >mode_config;
> > > +
> > > + mutex_lock(_config->mutex);
> > > + for_each_intel_connector(dev, intel_connector) {
> > > + struct drm_connector *connector = &(intel_connector->base);
> > > +
> > > + if (intel_connector->mst_port != intel_dp)
> > > + continue;
> > > +
> > > + old_status = connector->status;
> > > + connector->status = connector->funcs->detect(connector, false);
> > > +
> > > + if (old_status != connector->status)
> > > + changed = true;
> > > + }
> > > + mutex_unlock(_config->mutex);
> > 
> > To help reviewers it might be nice to have a short explanation of the
> > locking situation in the commit message, mainly why is it safe to simply
> > take mode_config.mutex here.
> > 
> 
> I can't convince myself this locking is correct yet.
> drm_dp_send_link_address(), one of the callers of this function is
> recursive.
> drm_dp_send_link_address()->drm_dp_add_port()->drm_dp_send_link_address()

Hmm. I wonder how deep that can get. As in is there an upper bound on
the stack usage...

> 
> I am wondering if hpd_pulse should return IRQ_NONE so that we can have
> ->detect() called from the hotplug work function. For this to work,
> we'll need to change drm_dp_mst_hpd_irq().

Does the topology manager do all the processing in a blocking fashion
from the dig_port_work, or does is schedule additional works and return
before they're done?

If it all happens from the dig_port_work, then I guess it should be
possible to just set some flag from the mst .hotplug() hook and check
that flag after all the processing is done to know whether the schedule
the a full detect work. I don't think you can just return IRQ_NONE from
the short pulse since that would schedule the full hotplug on the main
DP connector, not the MST one. In fact our current hotplug code entirely
skips MST connectors. But you could have a separate work perhaps just
to deal with the MST connectors, or we'd need to redo the main hotplug
handling in some way to handle MST connectors as well.

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

Re: [Intel-gfx] [PATCH 6/7] drm/i915/fbc: move from crtc_state->enable_fbc to plane_state->enable_fbc

[Paulo Zanoni]

Em Sex, 2016-11-11 às 22:24 +0200, Ville Syrjälä escreveu:
> On Fri, Nov 11, 2016 at 05:57:28PM -0200, Paulo Zanoni wrote:
> > 
> > Em Sex, 2016-11-11 às 21:13 +0200, Ville Syrjälä escreveu:
> > > 
> > > On Fri, Nov 11, 2016 at 05:01:54PM -0200, Paulo Zanoni wrote:
> > > > 
> > > > 
> > > > Em Sex, 2016-11-11 às 20:51 +0200, Ville Syrjälä escreveu:
> > > > > 
> > > > > 
> > > > > On Fri, Nov 11, 2016 at 02:57:40PM -0200, Paulo Zanoni wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Ville pointed out that intel_fbc_choose_crtc() is iterating
> > > > > > over
> > > > > > all
> > > > > > planes instead of just the primary planes. There are no
> > > > > > real
> > > > > > consequences of this problem for HSW+, and for the other
> > > > > > platforms
> > > > > > it
> > > > > > just means that in some obscure multi-screen cases we'll
> > > > > > keep
> > > > > > FBC
> > > > > > disabled when we could have enabled it. Still, iterating
> > > > > > over
> > > > > > all
> > > > > > planes doesn't seem to be the best thing to do.
> > > > > > 
> > > > > > My initial idea was to just add a check for plane->type and
> > > > > > be
> > > > > > done,
> > > > > > but then I realized that in commits not involving the
> > > > > > primary
> > > > > > plane
> > > > > > we
> > > > > > would reset crtc_state->enable_fbc back to false even when
> > > > > > FBC
> > > > > > is
> > > > > > enabled. That also wouldn't result in a bug due to the way
> > > > > > the
> > > > > > enable_fbc variable is checked, but, still, our code can be
> > > > > > better
> > > > > > than this.
> > > > > > 
> > > > > > So I went for the solution that involves tracking
> > > > > > enable_fbc in
> > > > > > the
> > > > > > primary plane state instead of the CRTC state. This way, if
> > > > > > a
> > > > > > commit
> > > > > > doesn't involve the primary plane for the CRTC we won't be
> > > > > > resetting
> > > > > > enable_fbc back to false, so the variable will always
> > > > > > reflect
> > > > > > the
> > > > > > reality. And this change also makes more sense since FBC is
> > > > > > actually
> > > > > > tied to the single plane and not the full pipe. As a bonus,
> > > > > > we
> > > > > > only
> > > > > > iterate over the CRTCs instead of iterating over all
> > > > > > planes.
> > > > > > 
> > > > > > Cc: Ville Syrjälä 
> > > > > > Reported-by: Ville Syrjälä 
> > > > > > Signed-off-by: Paulo Zanoni 
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/intel_drv.h |  4 ++--
> > > > > >  drivers/gpu/drm/i915/intel_fbc.c | 36 +++-
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > >  2 files changed, 21 insertions(+), 19 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > > > > b/drivers/gpu/drm/i915/intel_drv.h
> > > > > > index 003afb8..025cb74 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > > > > @@ -403,6 +403,8 @@ struct intel_plane_state {
> > > > > >     int scaler_id;
> > > > > >  
> > > > > >     struct drm_intel_sprite_colorkey ckey;
> > > > > > +
> > > > > > +   bool enable_fbc;
> > > > > >  };
> > > > > >  
> > > > > >  struct intel_initial_plane_config {
> > > > > > @@ -648,8 +650,6 @@ struct intel_crtc_state {
> > > > > >  
> > > > > >     bool ips_enabled;
> > > > > >  
> > > > > > -   bool enable_fbc;
> > > > > > -
> > > > > >     bool double_wide;
> > > > > >  
> > > > > >     bool dp_encoder_is_mst;
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> > > > > > b/drivers/gpu/drm/i915/intel_fbc.c
> > > > > > index b095175..fc4ac57 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > > > > > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > > > > > @@ -1055,16 +1055,17 @@ void intel_fbc_choose_crtc(struct
> > > > > > drm_i915_private *dev_priv,
> > > > > >        struct drm_atomic_state *state)
> > > > > >  {
> > > > > >     struct intel_fbc *fbc = _priv->fbc;
> > > > > > -   struct drm_plane *plane;
> > > > > > -   struct drm_plane_state *plane_state;
> > > > > > +   struct drm_crtc *crtc;
> > > > > > +   struct drm_crtc_state *crtc_state;
> > > > > >     bool crtc_chosen = false;
> > > > > >     int i;
> > > > > >  
> > > > > >     mutex_lock(>lock);
> > > > > >  
> > > > > > -   /* Does this atomic commit involve the CRTC
> > > > > > currently
> > > > > > tied
> > > > > > to FBC? */
> > > > > > +   /* Does this atomic commit involve the plane
> > > > > > currently
> > > > > > tied to FBC? */
> > > > > >     if (fbc->crtc &&
> > > > > > -   !drm_atomic_get_existing_crtc_state(state,
> > > > > > 
> > > > > > > 
> > > > > > > crtc-
> > > > > > > 
> > > > > > > base))
> > > > > > +   !drm_atomic_get_existing_plane_state(state,
> > > > > > +    fbc-
> > > > > > >crtc-
> > > > > > > 
> > > > > > > 
> > > > > > > base.primary))
> > > > > >     

Re: [Intel-gfx] [PATCH v2] drm/i915/dp: Update connector status for DP MST hotplugs

[Pandiyan, Dhinakaran]

On Tue, 2016-11-08 at 13:04 +0200, Ville Syrjälä wrote:
> On Mon, Nov 07, 2016 at 04:27:30PM -0800, Dhinakaran Pandiyan wrote:
> > Hotplugging a monitor in DP MST configuration triggers short pulses.
> > Although the short pulse handling path ends up in the MST hotplug function,
> > we do not perform a detect before sending the hotplug uvent. This leads to
> > the connector status not being updated when the userspace calls
> > DRM_IOCTL_MODE_GETCONNECTOR.
> > 
> > So, let's call the connector function ->detect() to update the connector
> > status before sending the uevent.
> > 
> > v2: Update connector status inside mode_config mutex (Ville)
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_mst.c | 22 +-
> >  1 file changed, 21 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index 3ffbd69..8e36a96 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -492,8 +492,28 @@ static void intel_dp_mst_hotplug(struct 
> > drm_dp_mst_topology_mgr *mgr)
> > struct intel_dp *intel_dp = container_of(mgr, struct intel_dp, mst_mgr);
> > struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > struct drm_device *dev = intel_dig_port->base.base.dev;
> > +   struct intel_connector *intel_connector;
> > +   bool changed = false;
> > +   enum drm_connector_status old_status;
> > +   struct drm_mode_config *mode_config = >mode_config;
> > +
> > +   mutex_lock(_config->mutex);
> > +   for_each_intel_connector(dev, intel_connector) {
> > +   struct drm_connector *connector = &(intel_connector->base);
> > +
> > +   if (intel_connector->mst_port != intel_dp)
> > +   continue;
> > +
> > +   old_status = connector->status;
> > +   connector->status = connector->funcs->detect(connector, false);
> > +
> > +   if (old_status != connector->status)
> > +   changed = true;
> > +   }
> > +   mutex_unlock(_config->mutex);
> 
> To help reviewers it might be nice to have a short explanation of the
> locking situation in the commit message, mainly why is it safe to simply
> take mode_config.mutex here.
> 

I can't convince myself this locking is correct yet.
drm_dp_send_link_address(), one of the callers of this function is
recursive.
drm_dp_send_link_address()->drm_dp_add_port()->drm_dp_send_link_address()

I am wondering if hpd_pulse should return IRQ_NONE so that we can have
->detect() called from the hotplug work function. For this to work,
we'll need to change drm_dp_mst_hpd_irq().


-DK

> >  
> > -   drm_kms_helper_hotplug_event(dev);
> > +   if (changed)
> > +   drm_kms_helper_hotplug_event(dev);
> >  }
> >  
> >  static const struct drm_dp_mst_topology_cbs mst_cbs = {
> > -- 
> > 2.7.4
> 

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST

[Pandiyan, Dhinakaran]

On Fri, 2016-11-11 at 19:41 +0200, Ville Syrjälä wrote:
> On Wed, Nov 09, 2016 at 09:32:30PM -0800, Dhinakaran Pandiyan wrote:
> > Not validating the the mode rate against link rate results not pruning
> > invalid modes. For e.g, HBR2 5.4 Gpbs 2 lane configuration does not
> > support 4k @ 60Hz. But, we do not reject this mode currently.
> > 
> > So, make use of the helpers in intel_dp in validate mode rates against
> > max. data rate of a configuration.
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c |  4 ++--
> >  drivers/gpu/drm/i915/intel_dp_mst.c | 12 +++-
> >  drivers/gpu/drm/i915/intel_drv.h|  2 ++
> >  3 files changed, 15 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 7a9e122..7a73e43 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -161,14 +161,14 @@ static u8 intel_dp_max_lane_count(struct intel_dp 
> > *intel_dp)
> > return min(source_max, sink_max);
> >  }
> >  
> > -static int
> > +int
> >  intel_dp_link_required(int pixel_clock, int bpp)
> >  {
> > /* pixel_clock is in kHz, divide bpp by 8 to return the value in kBps*/
> > return (pixel_clock * bpp + 7) / 8;
> >  }
> >  
> > -static int
> > +int
> >  intel_dp_max_data_rate(int max_link_clock, int max_lanes)
> >  {
> > /* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index 3ffbd69..38d2ce0 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -335,7 +335,17 @@ static enum drm_mode_status
> >  intel_dp_mst_mode_valid(struct drm_connector *connector,
> > struct drm_display_mode *mode)
> >  {
> > +   struct intel_connector *intel_connector = to_intel_connector(connector);
> > +   struct intel_dp *intel_dp = intel_connector->mst_port;
> > int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
> > +   int link_clock = intel_dp_max_link_rate(intel_dp);
> > +   int lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
> > +   int bpp = 24; /* MST uses fixed bpp */
> > +   int mode_rate;
> > +   int link_max_data_rate;
> > +
> > +   link_max_data_rate = intel_dp_max_data_rate(link_clock, lane_count);
> > +   mode_rate = intel_dp_link_required(mode->clock, bpp);
> >  
> > /* TODO - validate mode against available PBN for link */
> > if (mode->clock < 1)
> > @@ -344,7 +354,7 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
> > if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> > return MODE_H_ILLEGAL;
> >  
> > -   if (mode->clock > max_dotclk)
> > +   if (mode_rate > link_max_data_rate || mode->clock > max_dotclk)
> > return MODE_CLOCK_HIGH;
> >  
> > return MODE_OK;
> 
> You'll also want to fix intel_dp_mst_compute_config(). Actually that one
> should check against the remaining link bw, but we don't track that
> sufficiently well. Well, actually the topology manager does track it,
> but just not atomically so it's not good enough in its current form.
> 
> But as a first step just checking against the total link bw would be an
> improvement.
> 

I am trying to understand why drm_dp_find_vcpi_slots() returns a value
greater than 64  in the 2 lane HBR2, 4k@60Hz config. Will send out this
patch once that is clear.

-DK


> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index c2f3863..313419d 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1471,6 +1471,8 @@ bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> >  bool __intel_dp_read_desc(struct intel_dp *intel_dp,
> >   struct intel_dp_desc *desc);
> >  bool intel_dp_read_desc(struct intel_dp *intel_dp);
> > +int intel_dp_link_required(int pixel_clock, int bpp);
> > +int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
> >  
> >  /* intel_dp_aux_backlight.c */
> >  int intel_dp_aux_init_backlight_funcs(struct intel_connector 
> > *intel_connector);
> > -- 
> > 2.7.4
> 

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

Re: [Intel-gfx] [PATCH 1/2] drm/dp/i915: Fix DP link rate math

[Pandiyan, Dhinakaran]

On Fri, 2016-11-11 at 15:39 +0200, Ville Syrjälä wrote:
> On Wed, Nov 09, 2016 at 09:32:29PM -0800, Dhinakaran Pandiyan wrote:
> > We store DP link rates as link clock frequencies in kHz, just like all
> > other clock values. But, DP link rates in the DP Spec are expressed in
> > Gbps/lane, which seems to have led to some confusion.
> > 
> > E.g., for HBR2
> > Max. data rate = 5.4 Gbps/lane x 4 lane x 8/10 x 1/8 = 216 kBps
> > where, 8/10 is for channel encoding and 1/8 is for bit to Byte conversion
> > 
> > Using link clock frequency, like we do
> > Max. data rate = 54 kHz * 4 lanes = 216 kSymbols/s
> > Because, each symbol has 8 bit of data, this is 216 kBps
> > and there is no need to account for channel encoding here.
> > 
> > But, currently we do 54 kHz * 4 lanes * (8/10) = 1728000 kBps
> > 
> > Similarly, while computing the required link bandwidth for a mode,
> > there is a mysterious 1/10 term.
> > This should simply be pixel_clock kHz * bpp * 1/8  to give the final
> > result in kBps
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 28 +---
> >  1 file changed, 9 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 8f313c1..7a9e122 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -161,33 +161,23 @@ static u8 intel_dp_max_lane_count(struct intel_dp 
> > *intel_dp)
> > return min(source_max, sink_max);
> >  }
> >  
> > -/*
> > - * The units on the numbers in the next two are... bizarre.  Examples will
> > - * make it clearer; this one parallels an example in the eDP spec.
> > - *
> > - * intel_dp_max_data_rate for one lane of 2.7GHz evaluates as:
> > - *
> > - * 27 * 1 * 8 / 10 == 216000
> > - *
> > - * The actual data capacity of that configuration is 2.16Gbit/s, so the
> > - * units are decakilobits.  ->clock in a drm_display_mode is in kilohertz -
> > - * or equivalently, kilopixels per second - so for 1680x1050R it'd be
> > - * 119000.  At 18bpp that's 2142000 kilobits per second.
> > - *
> > - * Thus the strange-looking division by 10 in intel_dp_link_required, to
> > - * get the result in decakilobits instead of kilobits.
> > - */
> > -
> >  static int
> >  intel_dp_link_required(int pixel_clock, int bpp)
> >  {
> > -   return (pixel_clock * bpp + 9) / 10;
> > +   /* pixel_clock is in kHz, divide bpp by 8 to return the value in kBps*/
> 
> Probably best not to mix in the kBps unit here and instead just talk
> in terms of the symbol clock.
> 
> > +   return (pixel_clock * bpp + 7) / 8;
> 
> DIV_ROUND_UP()
> 
> >  }
> >  
> >  static int
> >  intel_dp_max_data_rate(int max_link_clock, int max_lanes)
> >  {
> > -   return (max_link_clock * max_lanes * 8) / 10;
> > +   /* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
> > +* link rate that is generally expressed in Gbps. Since, 8 bits data is
> > +* transmitted every LS_Clk per lane, there is no need to account for
> > +* the channel encoding that is done in the PHY layer here.
> > +*/
> > +
> > +   return (max_link_clock * max_lanes);
> 
> Useless parens.
> 
> 

Thanks for the review, will fix these two lines.

-DK
> >  }
> >  
> >  static int
> > -- 
> > 2.7.4
> 

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

Re: [Intel-gfx] [PATCH] intel: Add Geminilake PCI IDs

[Anuj Phogat]

On Thu, Nov 10, 2016 at 10:28 AM, Ben Widawsky
 wrote:
>
> From: Ben Widawsky 
>
> Signed-off-by: Ben Widawsky 
> ---
>  intel/intel_chipset.h | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> index 514f659..41fc0da 100644
> --- a/intel/intel_chipset.h
> +++ b/intel/intel_chipset.h
> @@ -218,6 +218,9 @@
>  #define PCI_CHIP_BROXTON_3 0x1A85
>  #define PCI_CHIP_BROXTON_4 0x5A85
>
> +#define PCI_CHIP_GLK   0x3184
> +#define PCI_CHIP_GLK_2X6   0x3185
> +
>  #define IS_MOBILE(devid)   ((devid) == PCI_CHIP_I855_GM || \
>  (devid) == PCI_CHIP_I915_GM || \
>  (devid) == PCI_CHIP_I945_GM || \
> @@ -446,9 +449,13 @@
>  (devid) == PCI_CHIP_BROXTON_3  || \
>  (devid) == PCI_CHIP_BROXTON_4)
>
> -#define IS_GEN9(devid) (IS_SKYLAKE(devid) || \
> -IS_BROXTON(devid) || \
> -IS_KABYLAKE(devid))
> +#define IS_GEMINILAKE(devid)   ((devid) == PCI_CHIP_GLK || \
> +(devid) == PCI_CHIP_GLK_2X6)
> +
> +#define IS_GEN9(devid) (IS_SKYLAKE(devid)  || \
> +IS_BROXTON(devid)  || \
> +IS_KABYLAKE(devid) || \
> +IS_GEMINILAKE(devid))
>
>  #define IS_9XX(dev)(IS_GEN3(dev) || \
>  IS_GEN4(dev) || \
> --
> 2.10.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

IDs cross checked in graphics specs.

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

Re: [Intel-gfx] [PATCH 6/7] drm/i915/fbc: move from crtc_state->enable_fbc to plane_state->enable_fbc

[Ville Syrjälä]

On Fri, Nov 11, 2016 at 05:57:28PM -0200, Paulo Zanoni wrote:
> Em Sex, 2016-11-11 às 21:13 +0200, Ville Syrjälä escreveu:
> > On Fri, Nov 11, 2016 at 05:01:54PM -0200, Paulo Zanoni wrote:
> > > 
> > > Em Sex, 2016-11-11 às 20:51 +0200, Ville Syrjälä escreveu:
> > > > 
> > > > On Fri, Nov 11, 2016 at 02:57:40PM -0200, Paulo Zanoni wrote:
> > > > > 
> > > > > 
> > > > > Ville pointed out that intel_fbc_choose_crtc() is iterating
> > > > > over
> > > > > all
> > > > > planes instead of just the primary planes. There are no real
> > > > > consequences of this problem for HSW+, and for the other
> > > > > platforms
> > > > > it
> > > > > just means that in some obscure multi-screen cases we'll keep
> > > > > FBC
> > > > > disabled when we could have enabled it. Still, iterating over
> > > > > all
> > > > > planes doesn't seem to be the best thing to do.
> > > > > 
> > > > > My initial idea was to just add a check for plane->type and be
> > > > > done,
> > > > > but then I realized that in commits not involving the primary
> > > > > plane
> > > > > we
> > > > > would reset crtc_state->enable_fbc back to false even when FBC
> > > > > is
> > > > > enabled. That also wouldn't result in a bug due to the way the
> > > > > enable_fbc variable is checked, but, still, our code can be
> > > > > better
> > > > > than this.
> > > > > 
> > > > > So I went for the solution that involves tracking enable_fbc in
> > > > > the
> > > > > primary plane state instead of the CRTC state. This way, if a
> > > > > commit
> > > > > doesn't involve the primary plane for the CRTC we won't be
> > > > > resetting
> > > > > enable_fbc back to false, so the variable will always reflect
> > > > > the
> > > > > reality. And this change also makes more sense since FBC is
> > > > > actually
> > > > > tied to the single plane and not the full pipe. As a bonus, we
> > > > > only
> > > > > iterate over the CRTCs instead of iterating over all planes.
> > > > > 
> > > > > Cc: Ville Syrjälä 
> > > > > Reported-by: Ville Syrjälä 
> > > > > Signed-off-by: Paulo Zanoni 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_drv.h |  4 ++--
> > > > >  drivers/gpu/drm/i915/intel_fbc.c | 36 +++-
> > > > > 
> > > > > 
> > > > >  2 files changed, 21 insertions(+), 19 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > > > b/drivers/gpu/drm/i915/intel_drv.h
> > > > > index 003afb8..025cb74 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > > > @@ -403,6 +403,8 @@ struct intel_plane_state {
> > > > >   int scaler_id;
> > > > >  
> > > > >   struct drm_intel_sprite_colorkey ckey;
> > > > > +
> > > > > + bool enable_fbc;
> > > > >  };
> > > > >  
> > > > >  struct intel_initial_plane_config {
> > > > > @@ -648,8 +650,6 @@ struct intel_crtc_state {
> > > > >  
> > > > >   bool ips_enabled;
> > > > >  
> > > > > - bool enable_fbc;
> > > > > -
> > > > >   bool double_wide;
> > > > >  
> > > > >   bool dp_encoder_is_mst;
> > > > > diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> > > > > b/drivers/gpu/drm/i915/intel_fbc.c
> > > > > index b095175..fc4ac57 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > > > > @@ -1055,16 +1055,17 @@ void intel_fbc_choose_crtc(struct
> > > > > drm_i915_private *dev_priv,
> > > > >      struct drm_atomic_state *state)
> > > > >  {
> > > > >   struct intel_fbc *fbc = _priv->fbc;
> > > > > - struct drm_plane *plane;
> > > > > - struct drm_plane_state *plane_state;
> > > > > + struct drm_crtc *crtc;
> > > > > + struct drm_crtc_state *crtc_state;
> > > > >   bool crtc_chosen = false;
> > > > >   int i;
> > > > >  
> > > > >   mutex_lock(>lock);
> > > > >  
> > > > > - /* Does this atomic commit involve the CRTC currently
> > > > > tied
> > > > > to FBC? */
> > > > > + /* Does this atomic commit involve the plane currently
> > > > > tied to FBC? */
> > > > >   if (fbc->crtc &&
> > > > > - !drm_atomic_get_existing_crtc_state(state, 
> > > > > >crtc-
> > > > > > 
> > > > > > base))
> > > > > + !drm_atomic_get_existing_plane_state(state,
> > > > > +  fbc->crtc-
> > > > > > 
> > > > > > base.primary))
> > > > >   goto out;
> > > > >  
> > > > >   if (!intel_fbc_can_enable(dev_priv))
> > > > > @@ -1074,25 +1075,26 @@ void intel_fbc_choose_crtc(struct
> > > > > drm_i915_private *dev_priv,
> > > > >    * plane. We could go for fancier schemes such as
> > > > > checking
> > > > > the plane
> > > > >    * size, but this would just affect the few platforms
> > > > > that
> > > > > don't tie FBC
> > > > >    * to pipe or plane A. */
> > > > > - for_each_plane_in_state(state, plane, plane_state, i)
> > > > > 

Re: [Intel-gfx] [PATCH 6/7] drm/i915/fbc: move from crtc_state->enable_fbc to plane_state->enable_fbc

[Paulo Zanoni]

Em Sex, 2016-11-11 às 21:13 +0200, Ville Syrjälä escreveu:
> On Fri, Nov 11, 2016 at 05:01:54PM -0200, Paulo Zanoni wrote:
> > 
> > Em Sex, 2016-11-11 às 20:51 +0200, Ville Syrjälä escreveu:
> > > 
> > > On Fri, Nov 11, 2016 at 02:57:40PM -0200, Paulo Zanoni wrote:
> > > > 
> > > > 
> > > > Ville pointed out that intel_fbc_choose_crtc() is iterating
> > > > over
> > > > all
> > > > planes instead of just the primary planes. There are no real
> > > > consequences of this problem for HSW+, and for the other
> > > > platforms
> > > > it
> > > > just means that in some obscure multi-screen cases we'll keep
> > > > FBC
> > > > disabled when we could have enabled it. Still, iterating over
> > > > all
> > > > planes doesn't seem to be the best thing to do.
> > > > 
> > > > My initial idea was to just add a check for plane->type and be
> > > > done,
> > > > but then I realized that in commits not involving the primary
> > > > plane
> > > > we
> > > > would reset crtc_state->enable_fbc back to false even when FBC
> > > > is
> > > > enabled. That also wouldn't result in a bug due to the way the
> > > > enable_fbc variable is checked, but, still, our code can be
> > > > better
> > > > than this.
> > > > 
> > > > So I went for the solution that involves tracking enable_fbc in
> > > > the
> > > > primary plane state instead of the CRTC state. This way, if a
> > > > commit
> > > > doesn't involve the primary plane for the CRTC we won't be
> > > > resetting
> > > > enable_fbc back to false, so the variable will always reflect
> > > > the
> > > > reality. And this change also makes more sense since FBC is
> > > > actually
> > > > tied to the single plane and not the full pipe. As a bonus, we
> > > > only
> > > > iterate over the CRTCs instead of iterating over all planes.
> > > > 
> > > > Cc: Ville Syrjälä 
> > > > Reported-by: Ville Syrjälä 
> > > > Signed-off-by: Paulo Zanoni 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_drv.h |  4 ++--
> > > >  drivers/gpu/drm/i915/intel_fbc.c | 36 +++-
> > > > 
> > > > 
> > > >  2 files changed, 21 insertions(+), 19 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > > b/drivers/gpu/drm/i915/intel_drv.h
> > > > index 003afb8..025cb74 100644
> > > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > > @@ -403,6 +403,8 @@ struct intel_plane_state {
> > > >     int scaler_id;
> > > >  
> > > >     struct drm_intel_sprite_colorkey ckey;
> > > > +
> > > > +   bool enable_fbc;
> > > >  };
> > > >  
> > > >  struct intel_initial_plane_config {
> > > > @@ -648,8 +650,6 @@ struct intel_crtc_state {
> > > >  
> > > >     bool ips_enabled;
> > > >  
> > > > -   bool enable_fbc;
> > > > -
> > > >     bool double_wide;
> > > >  
> > > >     bool dp_encoder_is_mst;
> > > > diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> > > > b/drivers/gpu/drm/i915/intel_fbc.c
> > > > index b095175..fc4ac57 100644
> > > > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > > > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > > > @@ -1055,16 +1055,17 @@ void intel_fbc_choose_crtc(struct
> > > > drm_i915_private *dev_priv,
> > > >        struct drm_atomic_state *state)
> > > >  {
> > > >     struct intel_fbc *fbc = _priv->fbc;
> > > > -   struct drm_plane *plane;
> > > > -   struct drm_plane_state *plane_state;
> > > > +   struct drm_crtc *crtc;
> > > > +   struct drm_crtc_state *crtc_state;
> > > >     bool crtc_chosen = false;
> > > >     int i;
> > > >  
> > > >     mutex_lock(>lock);
> > > >  
> > > > -   /* Does this atomic commit involve the CRTC currently
> > > > tied
> > > > to FBC? */
> > > > +   /* Does this atomic commit involve the plane currently
> > > > tied to FBC? */
> > > >     if (fbc->crtc &&
> > > > -   !drm_atomic_get_existing_crtc_state(state, 
> > > > >crtc-
> > > > > 
> > > > > base))
> > > > +   !drm_atomic_get_existing_plane_state(state,
> > > > +    fbc->crtc-
> > > > > 
> > > > > base.primary))
> > > >     goto out;
> > > >  
> > > >     if (!intel_fbc_can_enable(dev_priv))
> > > > @@ -1074,25 +1075,26 @@ void intel_fbc_choose_crtc(struct
> > > > drm_i915_private *dev_priv,
> > > >      * plane. We could go for fancier schemes such as
> > > > checking
> > > > the plane
> > > >      * size, but this would just affect the few platforms
> > > > that
> > > > don't tie FBC
> > > >      * to pipe or plane A. */
> > > > -   for_each_plane_in_state(state, plane, plane_state, i)
> > > > {
> > > > -   struct intel_plane_state *intel_plane_state =
> > > > -   to_intel_plane_state(plane_state);
> > > > -   struct intel_crtc_state *intel_crtc_state;
> > > > -   struct intel_crtc *crtc =
> > 

Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset

[Cheng, Tony]

In case of link training failure and requiring user space to set a lower mode, 
would full mode set address it?  How do we make user mode select lower 
resolution?

For example 4k@60Hz monitor, and link training at 4 lane HBR2 fails and 
fallback to 4 lanes HBR, 4k@60 is no longer doable.  I would think preventing 
user mode from seeing 4K@60Hz from the start is a easier and more robust 
solution and requiring user mode to have logic to decide how to fallback.

-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] 
Sent: Friday, November 11, 2016 11:44 AM
To: Cheng, Tony 
Cc: Deucher, Alexander ; 'Jani Nikula' 
; Manasi Navare ; 
dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; Wentland, 
Harry ; Peres, Martin 
Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset

On Fri, Nov 11, 2016 at 04:21:58PM +, Cheng, Tony wrote:
> For HDMI, you can yank the cable, plug back in, HDMI will light up without 
> user mode or kernel mode doing anything.
> 
> For DP this is not possible, someone will have to retrain the link when 
> plugging back in or DP will not light up.  We see that on Ubuntu if someone 
> unplug display and plug it back into same connector, we do not get KMS so in 
> this case.  It appears there is some optimizations somewhere in user mode 
> stack which I am not familiar with yet.  dal added workaround to retrain the 
> link to light it back up (after the test training at end of detection).

The link should get retrained as the driver should check the link state on HPD 
and retrain if it's not good. At least that's what we do in i915. Of course if 
it's not the same display that got plugged back, the retraining might fail. The 
new property can help with that case as userspace would then attempt a full 
modeset after the failed link training.

> 
> >From user mode perspective I think it make sense to keep CRTC running, so 
> >vblank is still going so UMD isn't impacted.   As regard to connector and 
> >encoder does it matter if kernel mode change state without user mode 
> >knowing?  It seems to me those are more informational to UMD as UMD doesn't 
> >act on them.
> 
> windows does not know link state and all link management is hidden behind 
> kernel driver.   

If the user visible state doesn't change in any way, then the kernel could try 
to manage it all internally.

> 
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Friday, November 11, 2016 9:05 AM
> To: Cheng, Tony 
> Cc: Deucher, Alexander ; 'Jani Nikula' 
> ; Manasi Navare 
> ; dri-de...@lists.freedesktop.org; 
> intel-gfx@lists.freedesktop.org; Wentland, Harry 
> ; Peres, Martin 
> Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure 
> during modeset
> 
> On Thu, Nov 10, 2016 at 06:51:40PM +, Cheng, Tony wrote:
> > Amdgpu dal implementation will do a test link training at end of detection 
> > to verify we can achieve the capability reported in DPCD.  We then report 
> > mode base on result of test training.
> > 
> > AMD hardware (at least the generations supported by amdgpu) is able to link 
> > train without timing being setup (DP encoder and CRTC is decoupled).  Do we 
> > have limitation from other vendors where you need timing to be there before 
> > you can link train?
> 
> I can't recall the specifics for all of our supported platforms, but at least 
> I have the recollection that it would be the case yes.
> 
> The other problem wiyh this apporach is that even if you don't need the crtc, 
> you still need the link itself. What happens if the link is still active 
> since userspace just didn't bother to shut it down when the cable was yanked? 
> Can you keep the crtc going but stop it from feeding the link in a way that 
> userspace won't be able to notice? The kms design has always been pretty much 
> that policy is in userspace, and thus the kernel shouldn't shut down crtcs 
> unless explicitly asked to do so.
> 
> > 
> > We can also past DP1.2 link layer compliance with this approach.
> > 
> > -Original Message-
> > From: Deucher, Alexander
> > Sent: Thursday, November 10, 2016 1:43 PM
> > To: 'Jani Nikula' ; Manasi Navare 
> > ; dri-de...@lists.freedesktop.org; 
> > intel-gfx@lists.freedesktop.org; Wentland, Harry 
> > ; Cheng, Tony 
> > Cc: Dave Airlie ; Peres, Martin 
> > 
> > Subject: RE: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure 
> > during modeset
> > 
> > Adding Harry and Tony from our display team to review.
> > 
> > > 

Re: [Intel-gfx] [PATCH 6/7] drm/i915/fbc: move from crtc_state->enable_fbc to plane_state->enable_fbc

[Ville Syrjälä]

On Fri, Nov 11, 2016 at 05:01:54PM -0200, Paulo Zanoni wrote:
> Em Sex, 2016-11-11 às 20:51 +0200, Ville Syrjälä escreveu:
> > On Fri, Nov 11, 2016 at 02:57:40PM -0200, Paulo Zanoni wrote:
> > > 
> > > Ville pointed out that intel_fbc_choose_crtc() is iterating over
> > > all
> > > planes instead of just the primary planes. There are no real
> > > consequences of this problem for HSW+, and for the other platforms
> > > it
> > > just means that in some obscure multi-screen cases we'll keep FBC
> > > disabled when we could have enabled it. Still, iterating over all
> > > planes doesn't seem to be the best thing to do.
> > > 
> > > My initial idea was to just add a check for plane->type and be
> > > done,
> > > but then I realized that in commits not involving the primary plane
> > > we
> > > would reset crtc_state->enable_fbc back to false even when FBC is
> > > enabled. That also wouldn't result in a bug due to the way the
> > > enable_fbc variable is checked, but, still, our code can be better
> > > than this.
> > > 
> > > So I went for the solution that involves tracking enable_fbc in the
> > > primary plane state instead of the CRTC state. This way, if a
> > > commit
> > > doesn't involve the primary plane for the CRTC we won't be
> > > resetting
> > > enable_fbc back to false, so the variable will always reflect the
> > > reality. And this change also makes more sense since FBC is
> > > actually
> > > tied to the single plane and not the full pipe. As a bonus, we only
> > > iterate over the CRTCs instead of iterating over all planes.
> > > 
> > > Cc: Ville Syrjälä 
> > > Reported-by: Ville Syrjälä 
> > > Signed-off-by: Paulo Zanoni 
> > > ---
> > >  drivers/gpu/drm/i915/intel_drv.h |  4 ++--
> > >  drivers/gpu/drm/i915/intel_fbc.c | 36 +++-
> > > 
> > >  2 files changed, 21 insertions(+), 19 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index 003afb8..025cb74 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -403,6 +403,8 @@ struct intel_plane_state {
> > >   int scaler_id;
> > >  
> > >   struct drm_intel_sprite_colorkey ckey;
> > > +
> > > + bool enable_fbc;
> > >  };
> > >  
> > >  struct intel_initial_plane_config {
> > > @@ -648,8 +650,6 @@ struct intel_crtc_state {
> > >  
> > >   bool ips_enabled;
> > >  
> > > - bool enable_fbc;
> > > -
> > >   bool double_wide;
> > >  
> > >   bool dp_encoder_is_mst;
> > > diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> > > b/drivers/gpu/drm/i915/intel_fbc.c
> > > index b095175..fc4ac57 100644
> > > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > > @@ -1055,16 +1055,17 @@ void intel_fbc_choose_crtc(struct
> > > drm_i915_private *dev_priv,
> > >      struct drm_atomic_state *state)
> > >  {
> > >   struct intel_fbc *fbc = _priv->fbc;
> > > - struct drm_plane *plane;
> > > - struct drm_plane_state *plane_state;
> > > + struct drm_crtc *crtc;
> > > + struct drm_crtc_state *crtc_state;
> > >   bool crtc_chosen = false;
> > >   int i;
> > >  
> > >   mutex_lock(>lock);
> > >  
> > > - /* Does this atomic commit involve the CRTC currently tied
> > > to FBC? */
> > > + /* Does this atomic commit involve the plane currently
> > > tied to FBC? */
> > >   if (fbc->crtc &&
> > > - !drm_atomic_get_existing_crtc_state(state, >crtc-
> > > >base))
> > > + !drm_atomic_get_existing_plane_state(state,
> > > +  fbc->crtc-
> > > >base.primary))
> > >   goto out;
> > >  
> > >   if (!intel_fbc_can_enable(dev_priv))
> > > @@ -1074,25 +1075,26 @@ void intel_fbc_choose_crtc(struct
> > > drm_i915_private *dev_priv,
> > >    * plane. We could go for fancier schemes such as checking
> > > the plane
> > >    * size, but this would just affect the few platforms that
> > > don't tie FBC
> > >    * to pipe or plane A. */
> > > - for_each_plane_in_state(state, plane, plane_state, i) {
> > > - struct intel_plane_state *intel_plane_state =
> > > - to_intel_plane_state(plane_state);
> > > - struct intel_crtc_state *intel_crtc_state;
> > > - struct intel_crtc *crtc =
> > > to_intel_crtc(plane_state->crtc);
> > > + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> > > + struct intel_plane_state *plane_state =
> > > to_intel_plane_state(
> > > + drm_atomic_get_existing_plane_state(state,
> > > + crtc-
> > > >primary));
> > > + struct intel_crtc *intel_crtc =
> > > to_intel_crtc(crtc);
> > >  
> > > - if (!intel_plane_state->base.visible)
> > > + if (!plane_state)
> > >   continue;
> > >  
> > > - if (fbc_on_pipe_a_only(dev_priv) && crtc->pipe !=
> > > PIPE_A)
> > > + if 

Re: [Intel-gfx] [PATCH 6/7] drm/i915/fbc: move from crtc_state->enable_fbc to plane_state->enable_fbc

[Paulo Zanoni]

Em Sex, 2016-11-11 às 20:51 +0200, Ville Syrjälä escreveu:
> On Fri, Nov 11, 2016 at 02:57:40PM -0200, Paulo Zanoni wrote:
> > 
> > Ville pointed out that intel_fbc_choose_crtc() is iterating over
> > all
> > planes instead of just the primary planes. There are no real
> > consequences of this problem for HSW+, and for the other platforms
> > it
> > just means that in some obscure multi-screen cases we'll keep FBC
> > disabled when we could have enabled it. Still, iterating over all
> > planes doesn't seem to be the best thing to do.
> > 
> > My initial idea was to just add a check for plane->type and be
> > done,
> > but then I realized that in commits not involving the primary plane
> > we
> > would reset crtc_state->enable_fbc back to false even when FBC is
> > enabled. That also wouldn't result in a bug due to the way the
> > enable_fbc variable is checked, but, still, our code can be better
> > than this.
> > 
> > So I went for the solution that involves tracking enable_fbc in the
> > primary plane state instead of the CRTC state. This way, if a
> > commit
> > doesn't involve the primary plane for the CRTC we won't be
> > resetting
> > enable_fbc back to false, so the variable will always reflect the
> > reality. And this change also makes more sense since FBC is
> > actually
> > tied to the single plane and not the full pipe. As a bonus, we only
> > iterate over the CRTCs instead of iterating over all planes.
> > 
> > Cc: Ville Syrjälä 
> > Reported-by: Ville Syrjälä 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/intel_drv.h |  4 ++--
> >  drivers/gpu/drm/i915/intel_fbc.c | 36 +++-
> > 
> >  2 files changed, 21 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 003afb8..025cb74 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -403,6 +403,8 @@ struct intel_plane_state {
> >     int scaler_id;
> >  
> >     struct drm_intel_sprite_colorkey ckey;
> > +
> > +   bool enable_fbc;
> >  };
> >  
> >  struct intel_initial_plane_config {
> > @@ -648,8 +650,6 @@ struct intel_crtc_state {
> >  
> >     bool ips_enabled;
> >  
> > -   bool enable_fbc;
> > -
> >     bool double_wide;
> >  
> >     bool dp_encoder_is_mst;
> > diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> > b/drivers/gpu/drm/i915/intel_fbc.c
> > index b095175..fc4ac57 100644
> > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > @@ -1055,16 +1055,17 @@ void intel_fbc_choose_crtc(struct
> > drm_i915_private *dev_priv,
> >        struct drm_atomic_state *state)
> >  {
> >     struct intel_fbc *fbc = _priv->fbc;
> > -   struct drm_plane *plane;
> > -   struct drm_plane_state *plane_state;
> > +   struct drm_crtc *crtc;
> > +   struct drm_crtc_state *crtc_state;
> >     bool crtc_chosen = false;
> >     int i;
> >  
> >     mutex_lock(>lock);
> >  
> > -   /* Does this atomic commit involve the CRTC currently tied
> > to FBC? */
> > +   /* Does this atomic commit involve the plane currently
> > tied to FBC? */
> >     if (fbc->crtc &&
> > -   !drm_atomic_get_existing_crtc_state(state, >crtc-
> > >base))
> > +   !drm_atomic_get_existing_plane_state(state,
> > +    fbc->crtc-
> > >base.primary))
> >     goto out;
> >  
> >     if (!intel_fbc_can_enable(dev_priv))
> > @@ -1074,25 +1075,26 @@ void intel_fbc_choose_crtc(struct
> > drm_i915_private *dev_priv,
> >      * plane. We could go for fancier schemes such as checking
> > the plane
> >      * size, but this would just affect the few platforms that
> > don't tie FBC
> >      * to pipe or plane A. */
> > -   for_each_plane_in_state(state, plane, plane_state, i) {
> > -   struct intel_plane_state *intel_plane_state =
> > -   to_intel_plane_state(plane_state);
> > -   struct intel_crtc_state *intel_crtc_state;
> > -   struct intel_crtc *crtc =
> > to_intel_crtc(plane_state->crtc);
> > +   for_each_crtc_in_state(state, crtc, crtc_state, i) {
> > +   struct intel_plane_state *plane_state =
> > to_intel_plane_state(
> > +   drm_atomic_get_existing_plane_state(state,
> > +   crtc-
> > >primary));
> > +   struct intel_crtc *intel_crtc =
> > to_intel_crtc(crtc);
> >  
> > -   if (!intel_plane_state->base.visible)
> > +   if (!plane_state)
> >     continue;
> >  
> > -   if (fbc_on_pipe_a_only(dev_priv) && crtc->pipe !=
> > PIPE_A)
> > +   if (!plane_state->base.visible)
> >     continue;
> >  
> > -   if (fbc_on_plane_a_only(dev_priv) && crtc->plane
> > != PLANE_A)
> > +   if (fbc_on_pipe_a_only(dev_priv) && intel_crtc-
> > >pipe != 

Re: [Intel-gfx] [PATCH 6/7] drm/i915/fbc: move from crtc_state->enable_fbc to plane_state->enable_fbc

[Ville Syrjälä]

On Fri, Nov 11, 2016 at 02:57:40PM -0200, Paulo Zanoni wrote:
> Ville pointed out that intel_fbc_choose_crtc() is iterating over all
> planes instead of just the primary planes. There are no real
> consequences of this problem for HSW+, and for the other platforms it
> just means that in some obscure multi-screen cases we'll keep FBC
> disabled when we could have enabled it. Still, iterating over all
> planes doesn't seem to be the best thing to do.
> 
> My initial idea was to just add a check for plane->type and be done,
> but then I realized that in commits not involving the primary plane we
> would reset crtc_state->enable_fbc back to false even when FBC is
> enabled. That also wouldn't result in a bug due to the way the
> enable_fbc variable is checked, but, still, our code can be better
> than this.
> 
> So I went for the solution that involves tracking enable_fbc in the
> primary plane state instead of the CRTC state. This way, if a commit
> doesn't involve the primary plane for the CRTC we won't be resetting
> enable_fbc back to false, so the variable will always reflect the
> reality. And this change also makes more sense since FBC is actually
> tied to the single plane and not the full pipe. As a bonus, we only
> iterate over the CRTCs instead of iterating over all planes.
> 
> Cc: Ville Syrjälä 
> Reported-by: Ville Syrjälä 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_drv.h |  4 ++--
>  drivers/gpu/drm/i915/intel_fbc.c | 36 +++-
>  2 files changed, 21 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 003afb8..025cb74 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -403,6 +403,8 @@ struct intel_plane_state {
>   int scaler_id;
>  
>   struct drm_intel_sprite_colorkey ckey;
> +
> + bool enable_fbc;
>  };
>  
>  struct intel_initial_plane_config {
> @@ -648,8 +650,6 @@ struct intel_crtc_state {
>  
>   bool ips_enabled;
>  
> - bool enable_fbc;
> -
>   bool double_wide;
>  
>   bool dp_encoder_is_mst;
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> b/drivers/gpu/drm/i915/intel_fbc.c
> index b095175..fc4ac57 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -1055,16 +1055,17 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
> *dev_priv,
>  struct drm_atomic_state *state)
>  {
>   struct intel_fbc *fbc = _priv->fbc;
> - struct drm_plane *plane;
> - struct drm_plane_state *plane_state;
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *crtc_state;
>   bool crtc_chosen = false;
>   int i;
>  
>   mutex_lock(>lock);
>  
> - /* Does this atomic commit involve the CRTC currently tied to FBC? */
> + /* Does this atomic commit involve the plane currently tied to FBC? */
>   if (fbc->crtc &&
> - !drm_atomic_get_existing_crtc_state(state, >crtc->base))
> + !drm_atomic_get_existing_plane_state(state,
> +  fbc->crtc->base.primary))
>   goto out;
>  
>   if (!intel_fbc_can_enable(dev_priv))
> @@ -1074,25 +1075,26 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
> *dev_priv,
>* plane. We could go for fancier schemes such as checking the plane
>* size, but this would just affect the few platforms that don't tie FBC
>* to pipe or plane A. */
> - for_each_plane_in_state(state, plane, plane_state, i) {
> - struct intel_plane_state *intel_plane_state =
> - to_intel_plane_state(plane_state);
> - struct intel_crtc_state *intel_crtc_state;
> - struct intel_crtc *crtc = to_intel_crtc(plane_state->crtc);
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + struct intel_plane_state *plane_state = to_intel_plane_state(
> + drm_atomic_get_existing_plane_state(state,
> + crtc->primary));
> + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>  
> - if (!intel_plane_state->base.visible)
> + if (!plane_state)
>   continue;
>  
> - if (fbc_on_pipe_a_only(dev_priv) && crtc->pipe != PIPE_A)
> + if (!plane_state->base.visible)
>   continue;
>  
> - if (fbc_on_plane_a_only(dev_priv) && crtc->plane != PLANE_A)
> + if (fbc_on_pipe_a_only(dev_priv) && intel_crtc->pipe != PIPE_A)
>   continue;
>  
> - intel_crtc_state = to_intel_crtc_state(
> - drm_atomic_get_existing_crtc_state(state, >base));
> + if (fbc_on_plane_a_only(dev_priv) &&
> + intel_crtc->plane != 

Re: [Intel-gfx] [PATCH 2/7] drm/i915/fbc: replace a loop with drm_atomic_get_existing_crtc_state()

[Ville Syrjälä]

On Fri, Nov 11, 2016 at 05:46:16PM +, Chris Wilson wrote:
> On Fri, Nov 11, 2016 at 02:57:36PM -0200, Paulo Zanoni wrote:
> > Much simpler. Thanks to Ville for pointing this.
> > 
> > Cc: Ville Syrjälä 
> > Reported-by: Ville Syrjälä 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/intel_fbc.c | 17 +++--
> >  1 file changed, 7 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> > b/drivers/gpu/drm/i915/intel_fbc.c
> > index ded77bd..b53b884 100644
> > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > @@ -1071,7 +1071,7 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
> > *dev_priv,
> > struct drm_plane *plane;
> > struct drm_plane_state *plane_state;
> > bool fbc_crtc_present = false;
> > -   int i, j;
> > +   int i;
> >  
> > mutex_lock(>lock);
> >  
> > @@ -1092,6 +1092,7 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
> > *dev_priv,
> > for_each_plane_in_state(state, plane, plane_state, i) {
> > struct intel_plane_state *intel_plane_state =
> > to_intel_plane_state(plane_state);
> > +   struct intel_crtc_state *intel_crtc_state;
> >  
> > if (!intel_plane_state->base.visible)
> > continue;
> > @@ -1099,16 +1100,12 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
> > *dev_priv,
> > if (!intel_fbc_can_choose(to_intel_crtc(plane_state->crtc)))
> > continue;
> >  
> > -   for_each_crtc_in_state(state, crtc, crtc_state, j) {
> > -   struct intel_crtc_state *intel_crtc_state =
> > -   to_intel_crtc_state(crtc_state);
> > -
> > -   if (plane_state->crtc != crtc)
> > -   continue;
> > +   intel_crtc_state = to_intel_crtc_state(
> > +   drm_atomic_get_existing_crtc_state(state,
> > +  plane_state->crtc));
> 
> My knowledge of atomic api is not good enough to say whether this can
> return NULL at this point.

If the plane is part of the state, then plane_state->crtc will be part
of the state as well.

Reviewed-by: Ville Syrjälä 

Just to reaffirm I wanted to point out what
drm_atomic_set_crtc_for_plane() does, but looks like that one was
written with the assumption that it could fail, which is not correct
since drm_atomic_get_plane_state() will always add the current crtc
to the state, and drm_atomic_set_crtc_for_plane() will always add the
new crtc to the state.

drm_atomic_set_crtc_for_connector() is written in the way I was
expecting, so I think I'll fire off a patch for
drm_atomic_set_crtc_for_plane() to follow the same pattern.

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

Re: [Intel-gfx] [RFC i-g-t 0/4] intel-gpu-tools: Add support for the Chamelium

[Lyude Paul]

Alright, quick question: should we be going with your branch then or
mine?

On Wed, 2016-11-09 at 16:09 +0100, Tomeu Vizoso wrote:
> Hi Lyude,
> 
> I think this looks very good.
> 
> On 8 November 2016 at 01:05, Lyude  wrote:
> > 
> > 
> >  - While writing this patch series, I found that quite a few of the
> > RPC calls
> >    for chameleond don't work as expected. For instance, I have had
> > absolutely
> >    no luck getting CRCs from any of the display types that the
> > chamelium
> >    supports.
> 
> When I looked at this a few months ago, frame CRCs were working just
> fine. I was using libsoup, so maybe there's some problem with the
> unpacking of the checksum?

I'm pretty sure it's on the chameleond side of things. Using the test
server application in chameleond's source shows the same issue. 
> 
> > 
> > This isn't a huge deal though, since we usually just use the
> >    native CRC read back on the GPU anyway.
> 
> I'm not completely sure what you mean by that, but not all graphic
> pipelines are able to provide frame CRCs so I think this Chamelium
> work will be very useful when running tests that do check frame CRCs.
I wasn't aware of that, thanks for letting me know

> 
> Regards,
> 
> Tomeu
> 
> > 
> > 
> >  - Among other things that are broken with the chameleon, video
> > signal
> >    detection for DisplayPort is one of them. After the first
> > plug/unplug cycle,
> >    the DisplayPort receiver gets stuck and gives the wrong results
> > for
> >    WaitForInputStable. Luckily I've already got a fix I'll be
> > submitting to the
> >    ChromeOS guys when I get around to setting up their homebrew git
> > tools:
> > 
> > https://github.com/Lyude/chameleond/tree/wip/chameleon-fixe
> > s
> > 
> >    For now, expect the dp-display tests to fail without those
> > patches.
> > 
> > Lyude (4):
> >   igt_aux: Add igt_skip_without_suspend_support()
> >   igt_aux: Add igt_set_autoresume_delay()
> >   igt_aux: Add some list helpers from wayland
> >   Add support for hotplug testing with the Chamelium
> > 
> >  configure.ac   |  13 +
> >  lib/Makefile.am|  10 +-
> >  lib/igt.h  |   1 +
> >  lib/igt_aux.c  |  94 
> >  lib/igt_aux.h  |  41 
> >  lib/igt_chamelium.c| 628
> > +
> >  lib/igt_chamelium.h|  77 ++
> >  lib/igt_kms.c  | 107 +
> >  lib/igt_kms.h  |  13 +-
> >  scripts/run-tests.sh   |   4 +-
> >  tests/Makefile.am  |   5 +-
> >  tests/Makefile.sources |   1 +
> >  tests/chamelium.c  | 549
> > ++
> >  13 files changed, 1538 insertions(+), 5 deletions(-)
> >  create mode 100644 lib/igt_chamelium.c
> >  create mode 100644 lib/igt_chamelium.h
> >  create mode 100644 tests/chamelium.c
> > 
> > --
> > 2.7.4
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
-- 
Cheers,
Lyude
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Update i915_driver_load kerneldoc

[Chris Wilson]

On Thu, Nov 10, 2016 at 03:36:34PM +0200, Joonas Lahtinen wrote:
> Update i915_driver_load kerneldoc to match code.
> 
> Cc: Chris Wilson 
> Signed-off-by: Joonas Lahtinen 
Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/7] drm/i915/fbc: replace a loop with drm_atomic_get_existing_crtc_state()

[Chris Wilson]

On Fri, Nov 11, 2016 at 02:57:36PM -0200, Paulo Zanoni wrote:
> Much simpler. Thanks to Ville for pointing this.
> 
> Cc: Ville Syrjälä 
> Reported-by: Ville Syrjälä 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_fbc.c | 17 +++--
>  1 file changed, 7 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> b/drivers/gpu/drm/i915/intel_fbc.c
> index ded77bd..b53b884 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -1071,7 +1071,7 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
> *dev_priv,
>   struct drm_plane *plane;
>   struct drm_plane_state *plane_state;
>   bool fbc_crtc_present = false;
> - int i, j;
> + int i;
>  
>   mutex_lock(>lock);
>  
> @@ -1092,6 +1092,7 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
> *dev_priv,
>   for_each_plane_in_state(state, plane, plane_state, i) {
>   struct intel_plane_state *intel_plane_state =
>   to_intel_plane_state(plane_state);
> + struct intel_crtc_state *intel_crtc_state;
>  
>   if (!intel_plane_state->base.visible)
>   continue;
> @@ -1099,16 +1100,12 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
> *dev_priv,
>   if (!intel_fbc_can_choose(to_intel_crtc(plane_state->crtc)))
>   continue;
>  
> - for_each_crtc_in_state(state, crtc, crtc_state, j) {
> - struct intel_crtc_state *intel_crtc_state =
> - to_intel_crtc_state(crtc_state);
> -
> - if (plane_state->crtc != crtc)
> - continue;
> + intel_crtc_state = to_intel_crtc_state(
> + drm_atomic_get_existing_crtc_state(state,
> +plane_state->crtc));

My knowledge of atomic api is not good enough to say whether this can
return NULL at this point.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
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: Assuming non-DP++ port if dvo_port is HDMI and there's no AUX ch specified in the VBT

[Patchwork]

== Series Details ==

Series: drm/i915: Assuming non-DP++ port if dvo_port is HDMI and there's no AUX 
ch specified in the VBT
URL   : https://patchwork.freedesktop.org/series/15187/
State : success

== Summary ==

Series 15187v1 drm/i915: Assuming non-DP++ port if dvo_port is HDMI and there's 
no AUX ch specified in the VBT
https://patchwork.freedesktop.org/api/1.0/series/15187/revisions/1/mbox/


fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

75c991da15a4f67572515019e4fb8ed292457563 drm-intel-nightly: 
2016y-11m-11d-16h-22m-04s UTC integration manifest
1506878 drm/i915: Assuming non-DP++ port if dvo_port is HDMI and there's no AUX 
ch specified in the VBT

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2973/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/7] drm/i915/fbc: use drm_atomic_get_existing_crtc_state when appropriate

[Chris Wilson]

On Fri, Nov 11, 2016 at 02:57:39PM -0200, Paulo Zanoni wrote:
> Use drm_atomic_get_existing_crtc_state() instead of looping through
> the CRTC states and checking if the FBC CRTC is there.
> 
> Signed-off-by: Paulo Zanoni 
Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST

[Ville Syrjälä]

On Wed, Nov 09, 2016 at 09:32:30PM -0800, Dhinakaran Pandiyan wrote:
> Not validating the the mode rate against link rate results not pruning
> invalid modes. For e.g, HBR2 5.4 Gpbs 2 lane configuration does not
> support 4k @ 60Hz. But, we do not reject this mode currently.
> 
> So, make use of the helpers in intel_dp in validate mode rates against
> max. data rate of a configuration.
> 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_dp.c |  4 ++--
>  drivers/gpu/drm/i915/intel_dp_mst.c | 12 +++-
>  drivers/gpu/drm/i915/intel_drv.h|  2 ++
>  3 files changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 7a9e122..7a73e43 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -161,14 +161,14 @@ static u8 intel_dp_max_lane_count(struct intel_dp 
> *intel_dp)
>   return min(source_max, sink_max);
>  }
>  
> -static int
> +int
>  intel_dp_link_required(int pixel_clock, int bpp)
>  {
>   /* pixel_clock is in kHz, divide bpp by 8 to return the value in kBps*/
>   return (pixel_clock * bpp + 7) / 8;
>  }
>  
> -static int
> +int
>  intel_dp_max_data_rate(int max_link_clock, int max_lanes)
>  {
>   /* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 3ffbd69..38d2ce0 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -335,7 +335,17 @@ static enum drm_mode_status
>  intel_dp_mst_mode_valid(struct drm_connector *connector,
>   struct drm_display_mode *mode)
>  {
> + struct intel_connector *intel_connector = to_intel_connector(connector);
> + struct intel_dp *intel_dp = intel_connector->mst_port;
>   int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
> + int link_clock = intel_dp_max_link_rate(intel_dp);
> + int lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
> + int bpp = 24; /* MST uses fixed bpp */
> + int mode_rate;
> + int link_max_data_rate;
> +
> + link_max_data_rate = intel_dp_max_data_rate(link_clock, lane_count);
> + mode_rate = intel_dp_link_required(mode->clock, bpp);
>  
>   /* TODO - validate mode against available PBN for link */
>   if (mode->clock < 1)
> @@ -344,7 +354,7 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
>   if (mode->flags & DRM_MODE_FLAG_DBLCLK)
>   return MODE_H_ILLEGAL;
>  
> - if (mode->clock > max_dotclk)
> + if (mode_rate > link_max_data_rate || mode->clock > max_dotclk)
>   return MODE_CLOCK_HIGH;
>  
>   return MODE_OK;

You'll also want to fix intel_dp_mst_compute_config(). Actually that one
should check against the remaining link bw, but we don't track that
sufficiently well. Well, actually the topology manager does track it,
but just not atomically so it's not good enough in its current form.

But as a first step just checking against the total link bw would be an
improvement.

> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index c2f3863..313419d 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1471,6 +1471,8 @@ bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
>  bool __intel_dp_read_desc(struct intel_dp *intel_dp,
> struct intel_dp_desc *desc);
>  bool intel_dp_read_desc(struct intel_dp *intel_dp);
> +int intel_dp_link_required(int pixel_clock, int bpp);
> +int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
>  
>  /* intel_dp_aux_backlight.c */
>  int intel_dp_aux_init_backlight_funcs(struct intel_connector 
> *intel_connector);
> -- 
> 2.7.4

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

Re: [Intel-gfx] [PATCH 3/7] drm/i915/fbc: extract intel_fbc_can_enable()

[Chris Wilson]

On Fri, Nov 11, 2016 at 02:57:37PM -0200, Paulo Zanoni wrote:
> Extract that part of the code to a new function and call this function
> only once during intel_fbc_choose_crtc() instead of once per plane.
> Those checks are independent from planes/CRTCs.
> 
> Signed-off-by: Paulo Zanoni 
Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/7] drm/i915/fbc: move the intel_fbc_can_choose() call out of the loop

[Chris Wilson]

On Fri, Nov 11, 2016 at 02:57:35PM -0200, Paulo Zanoni wrote:
> We can just call it earlier, so do it. The goal of the loop is to get
> the plane's CRTC state, and we don't need it in order to call
> intel_fbc_can_choose().
> 
> Signed-off-by: Paulo Zanoni 
Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/7] drm/i915/fbc: inline intel_fbc_can_choose()

[Chris Wilson]

On Fri, Nov 11, 2016 at 02:57:38PM -0200, Paulo Zanoni wrote:
> It only has two checks now, so it makes sense to just move the code to
> the caller.
> 
> Also take this opportunity to make no_fbc_reason make more sense: now
> we'll only list "no suitable CRTC for FBC" instead of maybe giving a
> reason why the last CRTC we checked was not selected, and we'll more
> consistently set the reason (e.g., if no primary planes are visible).

That seems a reasonable justification for the change.
 
> Signed-off-by: Paulo Zanoni 
Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 7/7] drm/i915/fbc: convert intel_fbc.c to use INTEL_GEN()

[Chris Wilson]

On Fri, Nov 11, 2016 at 02:57:41PM -0200, Paulo Zanoni wrote:
> Because it's shorter, easier to read, newer and cooler. And I don't
> think anybody else has pending FBC patches right now, so the conflicts
> should be minimal.
> 
> Signed-off-by: Paulo Zanoni 
Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/dp: Update connector status for DP MST hotplugs

[Ville Syrjälä]

On Mon, Nov 07, 2016 at 04:27:30PM -0800, Dhinakaran Pandiyan wrote:
> Hotplugging a monitor in DP MST configuration triggers short pulses.
> Although the short pulse handling path ends up in the MST hotplug function,
> we do not perform a detect before sending the hotplug uvent. This leads to
> the connector status not being updated when the userspace calls
> DRM_IOCTL_MODE_GETCONNECTOR.
> 
> So, let's call the connector function ->detect() to update the connector
> status before sending the uevent.
> 
> v2: Update connector status inside mode_config mutex (Ville)
> 
> Signed-off-by: Dhinakaran Pandiyan 

Possibly 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98306

> ---
>  drivers/gpu/drm/i915/intel_dp_mst.c | 22 +-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 3ffbd69..8e36a96 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -492,8 +492,28 @@ static void intel_dp_mst_hotplug(struct 
> drm_dp_mst_topology_mgr *mgr)
>   struct intel_dp *intel_dp = container_of(mgr, struct intel_dp, mst_mgr);
>   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>   struct drm_device *dev = intel_dig_port->base.base.dev;
> + struct intel_connector *intel_connector;
> + bool changed = false;
> + enum drm_connector_status old_status;
> + struct drm_mode_config *mode_config = >mode_config;
> +
> + mutex_lock(_config->mutex);
> + for_each_intel_connector(dev, intel_connector) {
> + struct drm_connector *connector = &(intel_connector->base);
> +
> + if (intel_connector->mst_port != intel_dp)
> + continue;
> +
> + old_status = connector->status;
> + connector->status = connector->funcs->detect(connector, false);
> +
> + if (old_status != connector->status)
> + changed = true;
> + }
> + mutex_unlock(_config->mutex);
>  
> - drm_kms_helper_hotplug_event(dev);
> + if (changed)
> + drm_kms_helper_hotplug_event(dev);
>  }
>  
>  static const struct drm_dp_mst_topology_cbs mst_cbs = {
> -- 
> 2.7.4

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for FBC atomic cleanups

[Patchwork]

== Series Details ==

Series: FBC atomic cleanups
URL   : https://patchwork.freedesktop.org/series/15185/
State : warning

== Summary ==

Series 15185v1 FBC atomic cleanups
https://patchwork.freedesktop.org/api/1.0/series/15185/revisions/1/mbox/

Test kms_force_connector_basic:
Subgroup prune-stale-modes:
pass   -> DMESG-WARN (fi-snb-2520m)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:244  pass:211  dwarn:1   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

75c991da15a4f67572515019e4fb8ed292457563 drm-intel-nightly: 
2016y-11m-11d-16h-22m-04s UTC integration manifest
e56bcbe drm/i915/fbc: convert intel_fbc.c to use INTEL_GEN()
a505f19 drm/i915/fbc: move from crtc_state->enable_fbc to 
plane_state->enable_fbc
71616cd drm/i915/fbc: use drm_atomic_get_existing_crtc_state when appropriate
eefbce6 drm/i915/fbc: inline intel_fbc_can_choose()
df9b237 drm/i915/fbc: extract intel_fbc_can_enable()
a1fff0e drm/i915/fbc: replace a loop with drm_atomic_get_existing_crtc_state()
c4c0a75 drm/i915/fbc: move the intel_fbc_can_choose() call out of the loop

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2972/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Assuming non-DP++ port if dvo_port is HDMI and there's no AUX ch specified in the VBT

[ville . syrjala]

From: Ville Syrjälä 

My heuristic for detecting type 1 DVI DP++ adaptors based on the VBT
port information apparently didn't survive the reality of buggy VBTs.
In this particular case we have a machine with a natice HDMI port, but
the VBT telsl us it's a DP++ port based on its capabilities.

The dvo_port information in VBT does claim that we're dealing with a
HDMI port though, but we have other machines which do the same even
when they actually have DP++ ports. So that piece of information alone
isn't sufficient to tell the two apart.

After staring at a bunch of VBTs from various machines, I have to
conclude that the only other semi-reliable clue we can use is the
presence of the AUX channel in the VBT. On this particular machine
AUX channel is specified as zero, whereas on some of the other machines
which listed the DP++ port as HDMI have a non-zero AUX channel.

I've also seen VBTs which have dvo_port a DP but have a zero AUX
channel. I believe those we need to treat as DP ports, so we'll limit
the AUX channel check to just the cases where dvo_port is HDMI.

If we encounter any more serious failures with this heuristic I think
we'll have to have to throw it out entirely. But that could mean that
there is a risk of type 1 DVI dongle users getting greeted by a
black screen, so I'd rather not go there unless absolutely necessary.

Cc: Daniel Otero 
Cc: sta...@vger.kernel.org
Tested-by: Daniel Otero 
Fixes: d61992565bd3 ("drm/i915: Determine DP++ type 1 DVI adaptor presence 
based on VBT")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97994
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_bios.c | 32 
 drivers/gpu/drm/i915/intel_vbt_defs.h |  3 ++-
 2 files changed, 26 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 5ab646ef8c9f..33ed05186810 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1147,7 +1147,7 @@ static void parse_ddi_port(struct drm_i915_private 
*dev_priv, enum port port,
if (!child)
return;
 
-   aux_channel = child->raw[25];
+   aux_channel = child->common.aux_channel;
ddc_pin = child->common.ddc_pin;
 
is_dvi = child->common.device_type & DEVICE_TYPE_TMDS_DVI_SIGNALING;
@@ -1677,7 +1677,8 @@ bool intel_bios_is_port_edp(struct drm_i915_private 
*dev_priv, enum port port)
return false;
 }
 
-bool intel_bios_is_port_dp_dual_mode(struct drm_i915_private *dev_priv, enum 
port port)
+static bool child_dev_is_dp_dual_mode(const union child_device_config *p_child,
+ enum port port)
 {
static const struct {
u16 dp, hdmi;
@@ -1691,22 +1692,37 @@ bool intel_bios_is_port_dp_dual_mode(struct 
drm_i915_private *dev_priv, enum por
[PORT_D] = { DVO_PORT_DPD, DVO_PORT_HDMID, },
[PORT_E] = { DVO_PORT_DPE, DVO_PORT_HDMIE, },
};
-   int i;
 
if (port == PORT_A || port >= ARRAY_SIZE(port_mapping))
return false;
 
-   if (!dev_priv->vbt.child_dev_num)
+   if ((p_child->common.device_type & DEVICE_TYPE_DP_DUAL_MODE_BITS) !=
+   (DEVICE_TYPE_DP_DUAL_MODE & DEVICE_TYPE_DP_DUAL_MODE_BITS))
+   return false;
+
+   if (p_child->common.dvo_port == port_mapping[port].dp)
+   return true;
+
+   /* Only accept a HDMI dvo_port as DP++ if it has an AUX channel */
+   if (p_child->common.dvo_port == port_mapping[port].hdmi &&
+   p_child->common.aux_channel != 0)
+   return true;
+
+   return false;
+}
+
+bool intel_bios_is_port_dp_dual_mode(struct drm_i915_private *dev_priv, enum 
port port)
+{
+   int i;
+
+   if (port == PORT_A)
return false;
 
for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
const union child_device_config *p_child =
_priv->vbt.child_dev[i];
 
-   if ((p_child->common.dvo_port == port_mapping[port].dp ||
-p_child->common.dvo_port == port_mapping[port].hdmi) &&
-   (p_child->common.device_type & 
DEVICE_TYPE_DP_DUAL_MODE_BITS) ==
-   (DEVICE_TYPE_DP_DUAL_MODE & DEVICE_TYPE_DP_DUAL_MODE_BITS))
+   if (child_dev_is_dp_dual_mode(p_child, port))
return true;
}
 
diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h 
b/drivers/gpu/drm/i915/intel_vbt_defs.h
index 68db9621f1f0..8886cab19f98 100644
--- a/drivers/gpu/drm/i915/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
@@ -280,7 +280,8 @@ struct common_child_dev_config {
u8 dp_support:1;
u8 tmds_support:1;
u8 support_reserved:5;
-   u8 not_common3[12];
+   u8 aux_channel;
+   u8 not_common3[11];
  

[Intel-gfx] [PATCH 7/7] drm/i915/fbc: convert intel_fbc.c to use INTEL_GEN()

[Paulo Zanoni]

Because it's shorter, easier to read, newer and cooler. And I don't
think anybody else has pending FBC patches right now, so the conflicts
should be minimal.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index fc4ac57..b15c2c3 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -48,17 +48,17 @@ static inline bool fbc_supported(struct drm_i915_private 
*dev_priv)
 
 static inline bool fbc_on_pipe_a_only(struct drm_i915_private *dev_priv)
 {
-   return IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 8;
+   return IS_HASWELL(dev_priv) || INTEL_GEN(dev_priv) >= 8;
 }
 
 static inline bool fbc_on_plane_a_only(struct drm_i915_private *dev_priv)
 {
-   return INTEL_INFO(dev_priv)->gen < 4;
+   return INTEL_GEN(dev_priv) < 4;
 }
 
 static inline bool no_fbc_on_multiple_pipes(struct drm_i915_private *dev_priv)
 {
-   return INTEL_INFO(dev_priv)->gen <= 3;
+   return INTEL_GEN(dev_priv) <= 3;
 }
 
 /*
@@ -351,7 +351,7 @@ static void gen7_fbc_activate(struct drm_i915_private 
*dev_priv)
 
 static bool intel_fbc_hw_is_active(struct drm_i915_private *dev_priv)
 {
-   if (INTEL_INFO(dev_priv)->gen >= 5)
+   if (INTEL_GEN(dev_priv) >= 5)
return ilk_fbc_is_active(dev_priv);
else if (IS_GM45(dev_priv))
return g4x_fbc_is_active(dev_priv);
@@ -365,9 +365,9 @@ static void intel_fbc_hw_activate(struct drm_i915_private 
*dev_priv)
 
fbc->active = true;
 
-   if (INTEL_INFO(dev_priv)->gen >= 7)
+   if (INTEL_GEN(dev_priv) >= 7)
gen7_fbc_activate(dev_priv);
-   else if (INTEL_INFO(dev_priv)->gen >= 5)
+   else if (INTEL_GEN(dev_priv) >= 5)
ilk_fbc_activate(dev_priv);
else if (IS_GM45(dev_priv))
g4x_fbc_activate(dev_priv);
@@ -381,7 +381,7 @@ static void intel_fbc_hw_deactivate(struct drm_i915_private 
*dev_priv)
 
fbc->active = false;
 
-   if (INTEL_INFO(dev_priv)->gen >= 5)
+   if (INTEL_GEN(dev_priv) >= 5)
ilk_fbc_deactivate(dev_priv);
else if (IS_GM45(dev_priv))
g4x_fbc_deactivate(dev_priv);
@@ -561,7 +561,7 @@ static int find_compression_threshold(struct 
drm_i915_private *dev_priv,
 
ret = i915_gem_stolen_insert_node_in_range(dev_priv, node, size >>= 1,
   4096, 0, end);
-   if (ret && INTEL_INFO(dev_priv)->gen <= 4) {
+   if (ret && INTEL_GEN(dev_priv) <= 4) {
return 0;
} else if (ret) {
compression_threshold <<= 1;
@@ -594,7 +594,7 @@ static int intel_fbc_alloc_cfb(struct intel_crtc *crtc)
 
fbc->threshold = ret;
 
-   if (INTEL_INFO(dev_priv)->gen >= 5)
+   if (INTEL_GEN(dev_priv) >= 5)
I915_WRITE(ILK_DPFC_CB_BASE, fbc->compressed_fb.start);
else if (IS_GM45(dev_priv)) {
I915_WRITE(DPFC_CB_BASE, fbc->compressed_fb.start);
@@ -708,10 +708,10 @@ static bool intel_fbc_hw_tracking_covers_screen(struct 
intel_crtc *crtc)
struct intel_fbc *fbc = _priv->fbc;
unsigned int effective_w, effective_h, max_w, max_h;
 
-   if (INTEL_INFO(dev_priv)->gen >= 8 || IS_HASWELL(dev_priv)) {
+   if (INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv)) {
max_w = 4096;
max_h = 4096;
-   } else if (IS_G4X(dev_priv) || INTEL_INFO(dev_priv)->gen >= 5) {
+   } else if (IS_G4X(dev_priv) || INTEL_GEN(dev_priv) >= 5) {
max_w = 4096;
max_h = 2048;
} else {
@@ -812,7 +812,7 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
fbc->no_fbc_reason = "framebuffer not tiled or fenced";
return false;
}
-   if (INTEL_INFO(dev_priv)->gen <= 4 && !IS_G4X(dev_priv) &&
+   if (INTEL_GEN(dev_priv) <= 4 && !IS_G4X(dev_priv) &&
cache->plane.rotation != DRM_ROTATE_0) {
fbc->no_fbc_reason = "rotation unsupported";
return false;
@@ -1377,7 +1377,7 @@ void intel_fbc_init(struct drm_i915_private *dev_priv)
}
 
/* This value was pulled out of someone's hat */
-   if (INTEL_INFO(dev_priv)->gen <= 4 && !IS_GM45(dev_priv))
+   if (INTEL_GEN(dev_priv) <= 4 && !IS_GM45(dev_priv))
I915_WRITE(FBC_CONTROL, 500 << FBC_CTL_INTERVAL_SHIFT);
 
/* We still don't have any sort of hardware state readout for FBC, so
-- 
2.7.4

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

[Intel-gfx] [PATCH 3/7] drm/i915/fbc: extract intel_fbc_can_enable()

[Paulo Zanoni]

Extract that part of the code to a new function and call this function
only once during intel_fbc_choose_crtc() instead of once per plane.
Those checks are independent from planes/CRTCs.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index b53b884..7381011 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -854,9 +854,8 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
return true;
 }
 
-static bool intel_fbc_can_choose(struct intel_crtc *crtc)
+static bool intel_fbc_can_enable(struct drm_i915_private *dev_priv)
 {
-   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_fbc *fbc = _priv->fbc;
 
if (intel_vgpu_active(dev_priv)) {
@@ -874,6 +873,14 @@ static bool intel_fbc_can_choose(struct intel_crtc *crtc)
return false;
}
 
+   return true;
+}
+
+static bool intel_fbc_can_choose(struct intel_crtc *crtc)
+{
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   struct intel_fbc *fbc = _priv->fbc;
+
if (fbc_on_pipe_a_only(dev_priv) && crtc->pipe != PIPE_A) {
fbc->no_fbc_reason = "no enabled pipes can have FBC";
return false;
@@ -1085,6 +1092,9 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
*dev_priv,
if (!fbc_crtc_present && fbc->crtc != NULL)
goto out;
 
+   if (!intel_fbc_can_enable(dev_priv))
+   goto out;
+
/* Simply choose the first CRTC that is compatible and has a visible
 * plane. We could go for fancier schemes such as checking the plane
 * size, but this would just affect the few platforms that don't tie FBC
-- 
2.7.4

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

[Intel-gfx] [PATCH 0/7] FBC atomic cleanups

[Paulo Zanoni]

Ville pointed out two ugly defects in the FBC code, and while trying
to fix them I spotted a few extra things. No real-world bugs fixed
here, but IMHO the code is much easier to read now.

Paulo Zanoni (7):
  drm/i915/fbc: move the intel_fbc_can_choose() call out of the loop
  drm/i915/fbc: replace a loop with drm_atomic_get_existing_crtc_state()
  drm/i915/fbc: extract intel_fbc_can_enable()
  drm/i915/fbc: inline intel_fbc_can_choose()
  drm/i915/fbc: use drm_atomic_get_existing_crtc_state when appropriate
  drm/i915/fbc: move from crtc_state->enable_fbc to
plane_state->enable_fbc
  drm/i915/fbc: convert intel_fbc.c to use INTEL_GEN()

 drivers/gpu/drm/i915/intel_drv.h |  4 +-
 drivers/gpu/drm/i915/intel_fbc.c | 97 ++--
 2 files changed, 46 insertions(+), 55 deletions(-)

-- 
2.7.4

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

[Intel-gfx] [PATCH 4/7] drm/i915/fbc: inline intel_fbc_can_choose()

[Paulo Zanoni]

It only has two checks now, so it makes sense to just move the code to
the caller.

Also take this opportunity to make no_fbc_reason make more sense: now
we'll only list "no suitable CRTC for FBC" instead of maybe giving a
reason why the last CRTC we checked was not selected, and we'll more
consistently set the reason (e.g., if no primary planes are visible).

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 33 +++--
 1 file changed, 11 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 7381011..89d5612 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -876,24 +876,6 @@ static bool intel_fbc_can_enable(struct drm_i915_private 
*dev_priv)
return true;
 }
 
-static bool intel_fbc_can_choose(struct intel_crtc *crtc)
-{
-   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   struct intel_fbc *fbc = _priv->fbc;
-
-   if (fbc_on_pipe_a_only(dev_priv) && crtc->pipe != PIPE_A) {
-   fbc->no_fbc_reason = "no enabled pipes can have FBC";
-   return false;
-   }
-
-   if (fbc_on_plane_a_only(dev_priv) && crtc->plane != PLANE_A) {
-   fbc->no_fbc_reason = "no enabled planes can have FBC";
-   return false;
-   }
-
-   return true;
-}
-
 static void intel_fbc_get_reg_params(struct intel_crtc *crtc,
 struct intel_fbc_reg_params *params)
 {
@@ -1077,7 +1059,7 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
*dev_priv,
struct drm_crtc_state *crtc_state;
struct drm_plane *plane;
struct drm_plane_state *plane_state;
-   bool fbc_crtc_present = false;
+   bool fbc_crtc_present = false, crtc_chosen = false;
int i;
 
mutex_lock(>lock);
@@ -1103,21 +1085,28 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
*dev_priv,
struct intel_plane_state *intel_plane_state =
to_intel_plane_state(plane_state);
struct intel_crtc_state *intel_crtc_state;
+   struct intel_crtc *crtc = to_intel_crtc(plane_state->crtc);
 
if (!intel_plane_state->base.visible)
continue;
 
-   if (!intel_fbc_can_choose(to_intel_crtc(plane_state->crtc)))
+   if (fbc_on_pipe_a_only(dev_priv) && crtc->pipe != PIPE_A)
+   continue;
+
+   if (fbc_on_plane_a_only(dev_priv) && crtc->plane != PLANE_A)
continue;
 
intel_crtc_state = to_intel_crtc_state(
-   drm_atomic_get_existing_crtc_state(state,
-  plane_state->crtc));
+   drm_atomic_get_existing_crtc_state(state, >base));
 
intel_crtc_state->enable_fbc = true;
+   crtc_chosen = true;
break;
}
 
+   if (!crtc_chosen)
+   fbc->no_fbc_reason = "no suitable CRTC for FBC";
+
 out:
mutex_unlock(>lock);
 }
-- 
2.7.4

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

[Intel-gfx] [PATCH 5/7] drm/i915/fbc: use drm_atomic_get_existing_crtc_state when appropriate

[Paulo Zanoni]

Use drm_atomic_get_existing_crtc_state() instead of looping through
the CRTC states and checking if the FBC CRTC is there.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 89d5612..b095175 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -1055,23 +1055,16 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
*dev_priv,
   struct drm_atomic_state *state)
 {
struct intel_fbc *fbc = _priv->fbc;
-   struct drm_crtc *crtc;
-   struct drm_crtc_state *crtc_state;
struct drm_plane *plane;
struct drm_plane_state *plane_state;
-   bool fbc_crtc_present = false, crtc_chosen = false;
+   bool crtc_chosen = false;
int i;
 
mutex_lock(>lock);
 
-   for_each_crtc_in_state(state, crtc, crtc_state, i) {
-   if (fbc->crtc == to_intel_crtc(crtc)) {
-   fbc_crtc_present = true;
-   break;
-   }
-   }
-   /* This atomic commit doesn't involve the CRTC currently tied to FBC. */
-   if (!fbc_crtc_present && fbc->crtc != NULL)
+   /* Does this atomic commit involve the CRTC currently tied to FBC? */
+   if (fbc->crtc &&
+   !drm_atomic_get_existing_crtc_state(state, >crtc->base))
goto out;
 
if (!intel_fbc_can_enable(dev_priv))
-- 
2.7.4

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

[Intel-gfx] [PATCH 2/7] drm/i915/fbc: replace a loop with drm_atomic_get_existing_crtc_state()

[Paulo Zanoni]

Much simpler. Thanks to Ville for pointing this.

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

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index ded77bd..b53b884 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -1071,7 +1071,7 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
*dev_priv,
struct drm_plane *plane;
struct drm_plane_state *plane_state;
bool fbc_crtc_present = false;
-   int i, j;
+   int i;
 
mutex_lock(>lock);
 
@@ -1092,6 +1092,7 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
*dev_priv,
for_each_plane_in_state(state, plane, plane_state, i) {
struct intel_plane_state *intel_plane_state =
to_intel_plane_state(plane_state);
+   struct intel_crtc_state *intel_crtc_state;
 
if (!intel_plane_state->base.visible)
continue;
@@ -1099,16 +1100,12 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
*dev_priv,
if (!intel_fbc_can_choose(to_intel_crtc(plane_state->crtc)))
continue;
 
-   for_each_crtc_in_state(state, crtc, crtc_state, j) {
-   struct intel_crtc_state *intel_crtc_state =
-   to_intel_crtc_state(crtc_state);
-
-   if (plane_state->crtc != crtc)
-   continue;
+   intel_crtc_state = to_intel_crtc_state(
+   drm_atomic_get_existing_crtc_state(state,
+  plane_state->crtc));
 
-   intel_crtc_state->enable_fbc = true;
-   goto out;
-   }
+   intel_crtc_state->enable_fbc = true;
+   break;
}
 
 out:
-- 
2.7.4

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

[Intel-gfx] [PATCH 1/7] drm/i915/fbc: move the intel_fbc_can_choose() call out of the loop

[Paulo Zanoni]

We can just call it earlier, so do it. The goal of the loop is to get
the plane's CRTC state, and we don't need it in order to call
intel_fbc_can_choose().

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index e230d48..ded77bd 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -1096,6 +1096,9 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
*dev_priv,
if (!intel_plane_state->base.visible)
continue;
 
+   if (!intel_fbc_can_choose(to_intel_crtc(plane_state->crtc)))
+   continue;
+
for_each_crtc_in_state(state, crtc, crtc_state, j) {
struct intel_crtc_state *intel_crtc_state =
to_intel_crtc_state(crtc_state);
@@ -1103,9 +1106,6 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
*dev_priv,
if (plane_state->crtc != crtc)
continue;
 
-   if (!intel_fbc_can_choose(to_intel_crtc(crtc)))
-   break;
-
intel_crtc_state->enable_fbc = true;
goto out;
}
-- 
2.7.4

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

[Intel-gfx] [PATCH 6/7] drm/i915/fbc: move from crtc_state->enable_fbc to plane_state->enable_fbc

[Paulo Zanoni]

Ville pointed out that intel_fbc_choose_crtc() is iterating over all
planes instead of just the primary planes. There are no real
consequences of this problem for HSW+, and for the other platforms it
just means that in some obscure multi-screen cases we'll keep FBC
disabled when we could have enabled it. Still, iterating over all
planes doesn't seem to be the best thing to do.

My initial idea was to just add a check for plane->type and be done,
but then I realized that in commits not involving the primary plane we
would reset crtc_state->enable_fbc back to false even when FBC is
enabled. That also wouldn't result in a bug due to the way the
enable_fbc variable is checked, but, still, our code can be better
than this.

So I went for the solution that involves tracking enable_fbc in the
primary plane state instead of the CRTC state. This way, if a commit
doesn't involve the primary plane for the CRTC we won't be resetting
enable_fbc back to false, so the variable will always reflect the
reality. And this change also makes more sense since FBC is actually
tied to the single plane and not the full pipe. As a bonus, we only
iterate over the CRTCs instead of iterating over all planes.

Cc: Ville Syrjälä 
Reported-by: Ville Syrjälä 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_drv.h |  4 ++--
 drivers/gpu/drm/i915/intel_fbc.c | 36 +++-
 2 files changed, 21 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 003afb8..025cb74 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -403,6 +403,8 @@ struct intel_plane_state {
int scaler_id;
 
struct drm_intel_sprite_colorkey ckey;
+
+   bool enable_fbc;
 };
 
 struct intel_initial_plane_config {
@@ -648,8 +650,6 @@ struct intel_crtc_state {
 
bool ips_enabled;
 
-   bool enable_fbc;
-
bool double_wide;
 
bool dp_encoder_is_mst;
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index b095175..fc4ac57 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -1055,16 +1055,17 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
*dev_priv,
   struct drm_atomic_state *state)
 {
struct intel_fbc *fbc = _priv->fbc;
-   struct drm_plane *plane;
-   struct drm_plane_state *plane_state;
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
bool crtc_chosen = false;
int i;
 
mutex_lock(>lock);
 
-   /* Does this atomic commit involve the CRTC currently tied to FBC? */
+   /* Does this atomic commit involve the plane currently tied to FBC? */
if (fbc->crtc &&
-   !drm_atomic_get_existing_crtc_state(state, >crtc->base))
+   !drm_atomic_get_existing_plane_state(state,
+fbc->crtc->base.primary))
goto out;
 
if (!intel_fbc_can_enable(dev_priv))
@@ -1074,25 +1075,26 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
*dev_priv,
 * plane. We could go for fancier schemes such as checking the plane
 * size, but this would just affect the few platforms that don't tie FBC
 * to pipe or plane A. */
-   for_each_plane_in_state(state, plane, plane_state, i) {
-   struct intel_plane_state *intel_plane_state =
-   to_intel_plane_state(plane_state);
-   struct intel_crtc_state *intel_crtc_state;
-   struct intel_crtc *crtc = to_intel_crtc(plane_state->crtc);
+   for_each_crtc_in_state(state, crtc, crtc_state, i) {
+   struct intel_plane_state *plane_state = to_intel_plane_state(
+   drm_atomic_get_existing_plane_state(state,
+   crtc->primary));
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
 
-   if (!intel_plane_state->base.visible)
+   if (!plane_state)
continue;
 
-   if (fbc_on_pipe_a_only(dev_priv) && crtc->pipe != PIPE_A)
+   if (!plane_state->base.visible)
continue;
 
-   if (fbc_on_plane_a_only(dev_priv) && crtc->plane != PLANE_A)
+   if (fbc_on_pipe_a_only(dev_priv) && intel_crtc->pipe != PIPE_A)
continue;
 
-   intel_crtc_state = to_intel_crtc_state(
-   drm_atomic_get_existing_crtc_state(state, >base));
+   if (fbc_on_plane_a_only(dev_priv) &&
+   intel_crtc->plane != PLANE_A)
+   continue;
 
-   intel_crtc_state->enable_fbc = true;
+   plane_state->enable_fbc = true;
crtc_chosen = true;
 

Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset

[Ville Syrjälä]

On Fri, Nov 11, 2016 at 04:21:58PM +, Cheng, Tony wrote:
> For HDMI, you can yank the cable, plug back in, HDMI will light up without 
> user mode or kernel mode doing anything.
> 
> For DP this is not possible, someone will have to retrain the link when 
> plugging back in or DP will not light up.  We see that on Ubuntu if someone 
> unplug display and plug it back into same connector, we do not get KMS so in 
> this case.  It appears there is some optimizations somewhere in user mode 
> stack which I am not familiar with yet.  dal added workaround to retrain the 
> link to light it back up (after the test training at end of detection).

The link should get retrained as the driver should check the link
state on HPD and retrain if it's not good. At least that's what we do in
i915. Of course if it's not the same display that got plugged back,
the retraining might fail. The new property can help with that
case as userspace would then attempt a full modeset after the failed
link training.

> 
> >From user mode perspective I think it make sense to keep CRTC running, so 
> >vblank is still going so UMD isn't impacted.   As regard to connector and 
> >encoder does it matter if kernel mode change state without user mode 
> >knowing?  It seems to me those are more informational to UMD as UMD doesn't 
> >act on them.
> 
> windows does not know link state and all link management is hidden behind 
> kernel driver.   

If the user visible state doesn't change in any way, then the kernel could
try to manage it all internally.

> 
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] 
> Sent: Friday, November 11, 2016 9:05 AM
> To: Cheng, Tony 
> Cc: Deucher, Alexander ; 'Jani Nikula' 
> ; Manasi Navare ; 
> dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; Wentland, 
> Harry ; Peres, Martin 
> Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during 
> modeset
> 
> On Thu, Nov 10, 2016 at 06:51:40PM +, Cheng, Tony wrote:
> > Amdgpu dal implementation will do a test link training at end of detection 
> > to verify we can achieve the capability reported in DPCD.  We then report 
> > mode base on result of test training.
> > 
> > AMD hardware (at least the generations supported by amdgpu) is able to link 
> > train without timing being setup (DP encoder and CRTC is decoupled).  Do we 
> > have limitation from other vendors where you need timing to be there before 
> > you can link train?
> 
> I can't recall the specifics for all of our supported platforms, but at least 
> I have the recollection that it would be the case yes.
> 
> The other problem wiyh this apporach is that even if you don't need the crtc, 
> you still need the link itself. What happens if the link is still active 
> since userspace just didn't bother to shut it down when the cable was yanked? 
> Can you keep the crtc going but stop it from feeding the link in a way that 
> userspace won't be able to notice? The kms design has always been pretty much 
> that policy is in userspace, and thus the kernel shouldn't shut down crtcs 
> unless explicitly asked to do so.
> 
> > 
> > We can also past DP1.2 link layer compliance with this approach.
> > 
> > -Original Message-
> > From: Deucher, Alexander
> > Sent: Thursday, November 10, 2016 1:43 PM
> > To: 'Jani Nikula' ; Manasi Navare 
> > ; dri-de...@lists.freedesktop.org; 
> > intel-gfx@lists.freedesktop.org; Wentland, Harry 
> > ; Cheng, Tony 
> > Cc: Dave Airlie ; Peres, Martin 
> > 
> > Subject: RE: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure 
> > during modeset
> > 
> > Adding Harry and Tony from our display team to review.
> > 
> > > -Original Message-
> > > From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> > > Sent: Thursday, November 10, 2016 1:20 PM
> > > To: Manasi Navare; dri-de...@lists.freedesktop.org; intel- 
> > > g...@lists.freedesktop.org
> > > Cc: Dave Airlie; Peres, Martin; Deucher, Alexander
> > > Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure 
> > > during modeset
> > > 
> > > On Thu, 10 Nov 2016, Manasi Navare  wrote:
> > > > Link training failure is handled by lowering the link rate first 
> > > > until it reaches the minimum and keeping the lane count maximum 
> > > > and then lowering the lane count until it reaches minimim. These 
> > > > fallback values are saved and hotplug uevent is sent to the 
> > > > userspace after setting the connector link status property to BAD.
> > > > Userspace should triiger another modeset on a uevent and if link 
> > > > status property is BAD. This will retrain the link at fallback values.
> > > > This is 

Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset

[Cheng, Tony]

For HDMI, you can yank the cable, plug back in, HDMI will light up without user 
mode or kernel mode doing anything.

For DP this is not possible, someone will have to retrain the link when 
plugging back in or DP will not light up.  We see that on Ubuntu if someone 
unplug display and plug it back into same connector, we do not get KMS so in 
this case.  It appears there is some optimizations somewhere in user mode stack 
which I am not familiar with yet.  dal added workaround to retrain the link to 
light it back up (after the test training at end of detection).

From user mode perspective I think it make sense to keep CRTC running, so 
vblank is still going so UMD isn't impacted.   As regard to connector and 
encoder does it matter if kernel mode change state without user mode knowing?  
It seems to me those are more informational to UMD as UMD doesn't act on them.

windows does not know link state and all link management is hidden behind 
kernel driver.   

-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] 
Sent: Friday, November 11, 2016 9:05 AM
To: Cheng, Tony 
Cc: Deucher, Alexander ; 'Jani Nikula' 
; Manasi Navare ; 
dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; Wentland, 
Harry ; Peres, Martin 
Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset

On Thu, Nov 10, 2016 at 06:51:40PM +, Cheng, Tony wrote:
> Amdgpu dal implementation will do a test link training at end of detection to 
> verify we can achieve the capability reported in DPCD.  We then report mode 
> base on result of test training.
> 
> AMD hardware (at least the generations supported by amdgpu) is able to link 
> train without timing being setup (DP encoder and CRTC is decoupled).  Do we 
> have limitation from other vendors where you need timing to be there before 
> you can link train?

I can't recall the specifics for all of our supported platforms, but at least I 
have the recollection that it would be the case yes.

The other problem wiyh this apporach is that even if you don't need the crtc, 
you still need the link itself. What happens if the link is still active since 
userspace just didn't bother to shut it down when the cable was yanked? Can you 
keep the crtc going but stop it from feeding the link in a way that userspace 
won't be able to notice? The kms design has always been pretty much that policy 
is in userspace, and thus the kernel shouldn't shut down crtcs unless 
explicitly asked to do so.

> 
> We can also past DP1.2 link layer compliance with this approach.
> 
> -Original Message-
> From: Deucher, Alexander
> Sent: Thursday, November 10, 2016 1:43 PM
> To: 'Jani Nikula' ; Manasi Navare 
> ; dri-de...@lists.freedesktop.org; 
> intel-gfx@lists.freedesktop.org; Wentland, Harry 
> ; Cheng, Tony 
> Cc: Dave Airlie ; Peres, Martin 
> 
> Subject: RE: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure 
> during modeset
> 
> Adding Harry and Tony from our display team to review.
> 
> > -Original Message-
> > From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> > Sent: Thursday, November 10, 2016 1:20 PM
> > To: Manasi Navare; dri-de...@lists.freedesktop.org; intel- 
> > g...@lists.freedesktop.org
> > Cc: Dave Airlie; Peres, Martin; Deucher, Alexander
> > Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure 
> > during modeset
> > 
> > On Thu, 10 Nov 2016, Manasi Navare  wrote:
> > > Link training failure is handled by lowering the link rate first 
> > > until it reaches the minimum and keeping the lane count maximum 
> > > and then lowering the lane count until it reaches minimim. These 
> > > fallback values are saved and hotplug uevent is sent to the 
> > > userspace after setting the connector link status property to BAD.
> > > Userspace should triiger another modeset on a uevent and if link 
> > > status property is BAD. This will retrain the link at fallback values.
> > > This is repeated until the link is successfully trained.
> > >
> > > This has been validated to pass DP compliance.
> > 
> > This cover letter and the commit messages do a good job of 
> > explaining what the patches do. However, you're lacking the crucial 
> > information of
> > *why* we need userspace cooperation to handle link training failures 
> > on DP mode setting, and *why* a new connector property is a good 
> > solution for this.
> > 
> > Here goes, including some alternative approaches we've considered 
> > (and even tried):
> > 
> > At the time userspace does setcrtc, we've already promised the mode 
> > would work. The promise is based on the theoretical capabilities of 
> > the link, but it's 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: Only wait upon the execution timeline when unlocked

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/2] drm/i915: Only wait upon the execution 
timeline when unlocked
URL   : https://patchwork.freedesktop.org/series/15171/
State : success

== Summary ==

Series 15171v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/15171/revisions/1/mbox/


fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

89ecd3a96ba0279c7006cdb06cf1151993f2fe19 drm-intel-nightly: 
2016y-11m-11d-14h-59m-36s UTC integration manifest
394a91b drm/i915: Stop skipping the final clflush back to system pages
502dd4e drm/i915: Only wait upon the execution timeline when unlocked

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2971/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] dim: Improve the error output when rebuild-nightly fails

[Daniel Vetter]

On Fri, Nov 11, 2016 at 03:37:04PM +0200, Jani Nikula wrote:
> On Fri, 11 Nov 2016, Daniel Vetter  wrote:
> > Joonas rightly complained that the current output is useless and just
> > confuses.
> >
> > Cc: Joonas Lahtinen 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  dim | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/dim b/dim
> > index dcdc19a9c82d..eba20509cda8 100755
> > --- a/dim
> > +++ b/dim
> > @@ -325,9 +325,11 @@ function update_linux_next # branch next next-fixes 
> > fixes
> >  
> >  function check_conflicts
> >  {
> > -   if git diff | grep '\(<<<\|===\|>>>\\)' ; then
> > +   if git diff | grep '\(<<<\|===\|>>>\\)' &> 
> > /dev/null ; then
> 
> grep -q instead of redirecting to /dev/null?

Will do.
-Daniel

> 
> > if [ -n "$1" ]; then
> > -   echo $*
> > +   echoerr $*
> > +   echoerr "See the section \"Resolving Conflicts when 
> > Rebuilding drm-intel-nightly\""
> > +   echoerr "in the drm-intel.rst documentation for how to 
> > handle this situation."
> > fi
> > exit 1
> > fi
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

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

[Intel-gfx] i915: LVDS display (or LVDS->DVI) via eDP as 2nd display

[Stefan Roese]

Hi!

I'm currently trying to enable the 2nd display on our Bay Trail
Atom E3845 SoC. This is on the Congatec SoM "conga-QA3":

http://www.congatec.com/en/products/qseven/conga-qa3.html

On this SoM, the eDP is converted to LVDS via an NXP PTN3460
and available as LVDS on the baseboard. My current setup is that
the 1st display is connected to HDMI1. This works just fine.
In the production version I would like to use a LVDS display
connected via eDP from the Bay Trail Atom. Since we don't have
this LVDS display yet, I'm currently testing with this
LVDS -> DVI adapter board:

http://www.congatec.com/de/produkte/zubehoer/conga-ldvi.html

So my current setup for this 2nd display is:

eDP -> LVDS -> DVI

which does not work.

Here my xrandr output:

Screen 0: minimum 8 x 8, current 1920 x 1200, maximum 32767 x 32767
DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
HDMI1 connected primary 1920x1200+0+0 (normal left inverted right x axis y 
axis) 597mm x 336mm
   1920x1200 59.95* 
   1920x1080 60.00  
   1600x1200 60.00  
   1680x1050 59.88  
   1280x1024 75.0260.02  
   1280x800  59.91  
   1152x864  75.00  
   1024x768  75.0360.00  
   800x600   75.0060.32  
   640x480   75.0059.94  
   720x400   70.08  
HDMI2 disconnected (normal left inverted right x axis y axis)
VGA1 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)


When I now try to add and enable DP1 (this is the correct port for
the eDP, right?), then I get these errors / warnings:

sudo xrandr -d :0 --output DP1 --addmode DP1 640x480
sudo dmesg -c
[  189.049312] [drm:vlv_pipe_set_fifo_size.isra.24] Pipe A FIFO split 511 / 511 
/ 511
[  189.049322] [drm:vlv_update_wm] Setting FIFO watermarks - A: plane=391, 
cursor=63, sprite0=0, sprite1=0, SR: plane=903, cursor=0 level=0 cxsr=1
[  189.050924] [drm:vlv_pipe_set_fifo_size.isra.24] Pipe A FIFO split 511 / 511 
/ 511
[  189.050934] [drm:vlv_update_wm] Setting FIFO watermarks - A: plane=391, 
cursor=0, sprite0=0, sprite1=0, SR: plane=903, cursor=0 level=0 cxsr=1

sudo xrandr -d :0 --output DP1 --mode 640x480 --right-of HDMI1
sudo dmesg -c
[  206.066238] [drm:vlv_pipe_set_fifo_size.isra.24] Pipe A FIFO split 511 / 511 
/ 511
[  206.066248] [drm:vlv_update_wm] Setting FIFO watermarks - A: plane=391, 
cursor=63, sprite0=0, sprite1=0, SR: plane=903, cursor=0 level=0 cxsr=1
[  206.075015] [drm:drm_mode_addfb2] [FB:47]
[  206.075208] [drm:drm_mode_setcrtc] [CRTC:26:pipe A]
[  206.075238] [drm:drm_mode_setcrtc] [CONNECTOR:41:HDMI-A-1]
[  206.076190] [drm:drm_mode_setcrtc] [CRTC:26:pipe A]
[  206.076196] [drm:drm_mode_setcrtc] [CONNECTOR:41:HDMI-A-1]
[  206.082714] [drm:vlv_pipe_set_fifo_size.isra.24] Pipe A FIFO split 511 / 511 
/ 511
[  206.082723] [drm:vlv_update_wm] Setting FIFO watermarks - A: plane=391, 
cursor=0, sprite0=0, sprite1=0, SR: plane=903, cursor=0 level=0 cxsr=1
[  206.083919] [drm:drm_mode_setcrtc] [CRTC:31:pipe B]
[  206.083927] [drm:drm_mode_setcrtc] [CONNECTOR:37:DP-1]
[  206.083946] [drm:intel_atomic_check] [CONNECTOR:37:DP-1] checking for sink 
bpp constrains
[  206.083949] [drm:intel_atomic_check] clamping display bpp (was 30) to 
default limit of 24
[  206.083952] [ cut here ]
[  206.083957] WARNING: CPU: 2 PID: 1953 at drivers/gpu/drm/i915/intel_dp.c:146 
intel_dp_max_link_bw.isra.8+0x28/0x50
[  206.083958] invalid max DP link bw val 0, using 1.62Gbps
[  206.083959] Modules linked in:
[  206.083965] CPU: 2 PID: 1953 Comm: Xorg Not tainted 4.9.0-rc4+ #5
[  206.083966] Hardware name: congatec 
conga-qeval20-qa3-e3845/conga-qeval20-qa3-e3845, BIOS 
2016.09.01-00021-ga2921da-dirty 09/30/2016
[  206.083968]  c90001de7a10 8132b928 c90001de7a60 

[  206.083973]  c90001de7a50 81059b66 00920007 
88017a48f0e0
[  206.083978]  c90001de7b50 0001 0004 
88017a48d000
[  206.083982] Call Trace:
[  206.083988]  [] dump_stack+0x4d/0x65
[  206.083992]  [] __warn+0xc6/0xe0
[  206.083995]  [] warn_slowpath_fmt+0x4a/0x50
[  206.083998]  [] intel_dp_max_link_bw.isra.8+0x28/0x50
[  206.084001]  [] intel_dp_common_rates+0x28/0xc0
[  206.084004]  [] intel_dp_compute_config+0x82/0x6e0
[  206.084008]  [] intel_atomic_check+0x2ff/0x10b0
[  206.084012]  [] drm_atomic_check_only+0x45b/0x580
[  206.084015]  [] ? 
drm_atomic_set_crtc_for_connector+0xbb/0xf0
[  206.084018]  [] drm_atomic_commit+0x12/0x50
[  206.084021]  [] drm_atomic_helper_set_config+0x7c/0xb0
[  206.084024]  [] drm_mode_set_config_internal+0x60/0x110
[  206.084027]  [] drm_mode_setcrtc+0x3bd/0x480
[  206.084031]  [] drm_ioctl+0x1e1/0x470
[  206.084034]  [] ? drm_mode_getcrtc+0x140/0x140
[  206.084039]  [] do_vfs_ioctl+0x8d/0x590
[  206.084042]  [] ? recalc_sigpending+0x15/0x40
[  206.084045]  [] SyS_ioctl+0x74/0x80
[  206.084049]  [] 

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Implement Link Rate fallback on Link training failure

[Manasi Navare]

On Fri, Nov 11, 2016 at 11:41:22AM +0200, Jani Nikula wrote:
> On Thu, 10 Nov 2016, Daniel Vetter  wrote:
> > On Wed, Nov 09, 2016 at 08:42:08PM -0800, Manasi Navare wrote:
> >> @@ -5692,6 +5751,39 @@ static bool intel_edp_init_connector(struct 
> >> intel_dp *intel_dp,
> >>return false;
> >>  }
> >>  
> >> +static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
> >> +{
> >> +  struct intel_connector *intel_connector;
> >> +  struct drm_connector *connector;
> >> +  struct drm_display_mode *mode;
> >> +  bool verbose_prune = true;
> >> +
> >> +  intel_connector = container_of(work, typeof(*intel_connector),
> >> + modeset_retry_work);
> >> +  connector = _connector->base;
> >> +
> >> +  /* Grab the locks before changing connector property*/
> >> +  mutex_lock(>dev->mode_config.mutex);
> >> +  DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
> >> +connector->name);
> >> +  list_for_each_entry(mode, >modes, head) {
> >> +  mode->status = intel_dp_mode_valid(connector,
> >> + mode);
> >> +  }
> >> +  drm_mode_prune_invalid(connector->dev, >modes,
> >> + verbose_prune);
> >> +
> >> +  /* Set connector link status to BAD and send a Uevent to notify
> >> +   * userspace to do a modeset.
> >> +   */
> >> +  intel_dp_set_link_status_property(connector,
> >> +DRM_MODE_LINK_STATUS_BAD);
> >> +  mutex_unlock(>dev->mode_config.mutex);
> >> +
> >> +  /* Send Hotplug uevent so userspace can reprobe */
> >> +  drm_kms_helper_hotplug_event(connector->dev);
> >
> > One downside of keeping all the signalling logic here in i915 is that we
> > don't have a good spot to put the kerneldoc for this new link status
> > property within drm_connector.c for others to easily spot. My suggestion
> > would be to extract function with the following rough pseudo-code:
> 
> Thanks for this. I wanted Manasi to keep the work struct and function
> within i915, but I fell short of coming up with this division.
> 
> BR,
> Jani.
> 
>

Jani, so we ar elooking at two functions going in core,
1. that does mode validation and pruning
2. set link status property

These should be in a separate patch right after declaring the
drm connector property, what do you think?

Regards
Manasi

 
> 
> >
> > drm_connector_set_link_status(connector, status)
> > {
> > mutex_lock(mode_config.mutex);
> >
> > /* what intel_dp_set_link_status_property() does */
> > 
> > mutex_unlock(mode_config.mutex);
> > drm_kms_helper_hotplug_event()
> > }
> >
> > Within intel_dp_modeset_retry_work_fn we'd then first need to drop the
> > lock, and then call this function. The lock drop is a bit ugly,
> > but:
> > - it doesn't matter from a performance pov, this is a slow, asynchronous
> >   work.
> > - it doesn't matter for correctnes, the only thing we need is to drop the
> >   lock before calling drm_kms_helper_hotplug_event, and that we update the
> >   link status and the mode list before that too.
> > - long term I expect that properties will get separate locks to protect
> >   their values, and restrict mode_config.mutex to just mode probing. Which
> >   means drm_connnector_set_link_status will use a different lock anyway.
> > - it nicely encapsulates stuff imo.
> >
> > Kerneldoc for drm_connector_set_link_status should mention that this needs
> > to be run from some async work item, and ofc have the full explanation
> > (maybe even quote some pseudo-code, see e.g. drm_modeset_lock.c comments)
> > of how this should be used.
> >
> > Since this is late-stage polish definitely wait for more feedback and for
> > the design to fully settle first.
> > -Daniel
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/glk: Reuse broxton code for geminilake

[kbuild test robot]

Hi Ander,

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-2016]
[cannot apply to v4.9-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ander-Conselvan-de-Oliveira/drm-i915-glk-Reuse-broxton-code-for-geminilake/2016-215001
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-x006-201645 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from include/linux/agp_backend.h:33,
from include/drm/drmP.h:35,
from drivers/gpu/drm/i915/intel_mocs.h:52,
from drivers/gpu/drm/i915/intel_mocs.c:23:
   drivers/gpu/drm/i915/intel_mocs.c: In function 'get_mocs_settings':
>> drivers/gpu/drm/i915/intel_mocs.c:185:13: error: implicit declaration of 
>> function 'IS_GEN9_LP' [-Werror=implicit-function-declaration]
 } else if (IS_GEN9_LP(dev_priv)) {
^
   include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> drivers/gpu/drm/i915/intel_mocs.c:185:9: note: in expansion of macro 'if'
 } else if (IS_GEN9_LP(dev_priv)) {
^~
   Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_reg.h:i915_mmio_reg_offset
   Cyclomatic Complexity 1 
drivers/gpu/drm/i915/intel_ringbuffer.h:intel_ring_emit
   Cyclomatic Complexity 1 
drivers/gpu/drm/i915/intel_ringbuffer.h:intel_ring_emit_reg
   Cyclomatic Complexity 1 
drivers/gpu/drm/i915/intel_ringbuffer.h:intel_ring_advance
   Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_drv.h:to_i915
   Cyclomatic Complexity 1 drivers/gpu/drm/i915/intel_mocs.c:l3cc_combine
   Cyclomatic Complexity 9 drivers/gpu/drm/i915/intel_mocs.c:mocs_register
   Cyclomatic Complexity 23 drivers/gpu/drm/i915/intel_mocs.c:get_mocs_settings
   Cyclomatic Complexity 9 
drivers/gpu/drm/i915/intel_mocs.c:emit_mocs_control_table
   Cyclomatic Complexity 11 
drivers/gpu/drm/i915/intel_mocs.c:emit_mocs_l3cc_table
   Cyclomatic Complexity 8 
drivers/gpu/drm/i915/intel_mocs.c:intel_mocs_init_engine
   Cyclomatic Complexity 6 
drivers/gpu/drm/i915/intel_mocs.c:intel_mocs_init_l3cc_table
   Cyclomatic Complexity 6 
drivers/gpu/drm/i915/intel_mocs.c:intel_rcs_context_init_mocs
   cc1: all warnings being treated as errors
--
   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/drm/drm_dp_helper.h:26,
from drivers/gpu/drm/i915/intel_bios.c:28:
   drivers/gpu/drm/i915/intel_bios.c: In function 
'intel_bios_is_port_hpd_inverted':
>> drivers/gpu/drm/i915/intel_bios.c:1768:20: error: implicit declaration of 
>> function 'IS_GEN9_LP' [-Werror=implicit-function-declaration]
 if (WARN_ON_ONCE(!IS_GEN9_LP(dev_priv)))
   ^
   include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> drivers/gpu/drm/i915/intel_bios.c:1768:2: note: in expansion of macro 'if'
 if (WARN_ON_ONCE(!IS_GEN9_LP(dev_priv)))
 ^~
>> drivers/gpu/drm/i915/i915_drv.h:95:25: note: in expansion of macro 
>> 'WARN_ONCE'
#define WARN_ON_ONCE(x) WARN_ONCE((x), "%s", "WARN_ON_ONCE(" __stringify(x) 
")")
^
>> drivers/gpu/drm/i915/intel_bios.c:1768:6: note: in expansion of macro 
>> 'WARN_ON_ONCE'
 if (WARN_ON_ONCE(!IS_GEN9_LP(dev_priv)))
 ^~~~
   Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:fls
   Cyclomatic Complexity 1 include/linux/log2.h:__ilog2_u32
   Cyclomatic Complexity 1 include/asm-generic/getorder.h:__get_order
   Cyclomatic Complexity 56 include/linux/slab.h:kmalloc_index
   Cyclomatic Complexity 67 include/linux/slab.h:kmalloc_large
   Cyclomatic Complexity 9 include/linux/slab.h:kmalloc
   Cyclomatic Complexity 17 include/linux/slab.h:kmalloc_array
   Cyclomatic Complexity 1 include/linux/slab.h:kcalloc
   Cyclomatic Complexity 1 include/linux/slab.h:kzalloc
   Cyclomatic Complexity 1 driver

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Implement Link Rate fallback on Link training failure

[Manasi Navare]

On Fri, Nov 11, 2016 at 04:08:26PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 10, 2016 at 09:58:31PM +0100, Daniel Vetter wrote:
> > On Wed, Nov 09, 2016 at 08:42:08PM -0800, Manasi Navare wrote:
> > > @@ -5692,6 +5751,39 @@ static bool intel_edp_init_connector(struct 
> > > intel_dp *intel_dp,
> > >   return false;
> > >  }
> > >  
> > > +static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
> > > +{
> > > + struct intel_connector *intel_connector;
> > > + struct drm_connector *connector;
> > > + struct drm_display_mode *mode;
> > > + bool verbose_prune = true;
> > > +
> > > + intel_connector = container_of(work, typeof(*intel_connector),
> > > +modeset_retry_work);
> > > + connector = _connector->base;
> > > +
> > > + /* Grab the locks before changing connector property*/
> > > + mutex_lock(>dev->mode_config.mutex);
> > > + DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
> > > +   connector->name);
> > > + list_for_each_entry(mode, >modes, head) {
> > > + mode->status = intel_dp_mode_valid(connector,
> > > +mode);
> > > + }
> > > + drm_mode_prune_invalid(connector->dev, >modes,
> > > +verbose_prune);
> > > +
> > > + /* Set connector link status to BAD and send a Uevent to notify
> > > +  * userspace to do a modeset.
> > > +  */
> > > + intel_dp_set_link_status_property(connector,
> > > +   DRM_MODE_LINK_STATUS_BAD);
> > > + mutex_unlock(>dev->mode_config.mutex);
> > > +
> > > + /* Send Hotplug uevent so userspace can reprobe */
> > > + drm_kms_helper_hotplug_event(connector->dev);
> > 
> > One downside of keeping all the signalling logic here in i915 is that we
> > don't have a good spot to put the kerneldoc for this new link status
> > property within drm_connector.c for others to easily spot. My suggestion
> > would be to extract function with the following rough pseudo-code:
> > 
> > drm_connector_set_link_status(connector, status)
> > {
> > mutex_lock(mode_config.mutex);
> > 
> > /* what intel_dp_set_link_status_property() does */
> > 
> > mutex_unlock(mode_config.mutex);
> > drm_kms_helper_hotplug_event()
> > }
> > 
> > Within intel_dp_modeset_retry_work_fn we'd then first need to drop the
> > lock, and then call this function. The lock drop is a bit ugly,
> > but:
> 
> The mode re-validation should be done in the core as well. Not sure if
> we could just stuff it all into one place, and then there would be no
> need for any lock dropping.
>

I can move the moderevalidation to the core as well, but then the function name
has to be something else than just drm_set_link_status_property(),cant think
of a name that combines mode revalidation and setting link sttaus property,
any suggestions?

Manasi 
> > - it doesn't matter from a performance pov, this is a slow, asynchronous
> >   work.
> > - it doesn't matter for correctnes, the only thing we need is to drop the
> >   lock before calling drm_kms_helper_hotplug_event, and that we update the
> >   link status and the mode list before that too.
> > - long term I expect that properties will get separate locks to protect
> >   their values, and restrict mode_config.mutex to just mode probing. Which
> >   means drm_connnector_set_link_status will use a different lock anyway.
> > - it nicely encapsulates stuff imo.
> > 
> > Kerneldoc for drm_connector_set_link_status should mention that this needs
> > to be run from some async work item, and ofc have the full explanation
> > (maybe even quote some pseudo-code, see e.g. drm_modeset_lock.c comments)
> > of how this should be used.
> > 
> > Since this is late-stage polish definitely wait for more feedback and for
> > the design to fully settle first.
> > -Daniel
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Ville Syrjälä
> Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/glk: Reuse broxton code for geminilake

[kbuild test robot]

Hi Ander,

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-2016]
[cannot apply to v4.9-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ander-Conselvan-de-Oliveira/drm-i915-glk-Reuse-broxton-code-for-geminilake/2016-223125
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-i1-201645 (attached as .config)
compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/intel_pm.c: In function 'gen6_set_rps_thresholds':
>> drivers/gpu/drm/i915/intel_pm.c:4888:2: error: implicit declaration of 
>> function 'IS_GEN9_LP' [-Werror=implicit-function-declaration]
 I915_WRITE(GEN6_RP_UP_EI,
 ^
   cc1: some warnings being treated as errors

vim +/IS_GEN9_LP +4888 drivers/gpu/drm/i915/intel_pm.c

dd75fdc8 Chris Wilson 2013-09-25  4882  /* Downclock if less 
than 60% busy over 32ms */
8a586437 Akash Goel   2015-03-06  4883  ei_down = 32000;
8a586437 Akash Goel   2015-03-06  4884  threshold_down = 60;
8a586437 Akash Goel   2015-03-06  4885  break;
8a586437 Akash Goel   2015-03-06  4886  }
8a586437 Akash Goel   2015-03-06  4887  
8a586437 Akash Goel   2015-03-06 @4888  I915_WRITE(GEN6_RP_UP_EI,
8a586437 Akash Goel   2015-03-06  4889 
GT_INTERVAL_FROM_US(dev_priv, ei_up));
8a586437 Akash Goel   2015-03-06  4890  I915_WRITE(GEN6_RP_UP_THRESHOLD,
a72b5623 Chris Wilson 2016-07-02  4891 
GT_INTERVAL_FROM_US(dev_priv,

:: The code at line 4888 was first introduced by commit
:: 8a5864377b12b7c0a7a8e20cb33ef7ccc679d657 drm/i915/skl: Restructured the 
gen6_set_rps_thresholds function

:: TO: Akash Goel <akash.g...@intel.com>
:: CC: Daniel Vetter <daniel.vet...@ffwll.ch>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for Compact userptr object backing store allocation (rev5)

[Patchwork]

== Series Details ==

Series: Compact userptr object backing store allocation (rev5)
URL   : https://patchwork.freedesktop.org/series/15151/
State : success

== Summary ==

Series 15151v5 Compact userptr object backing store allocation
https://patchwork.freedesktop.org/api/1.0/series/15151/revisions/5/mbox/


fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

7b290828029bfbbb50b1b907b197adc3f30e0d22 drm-intel-nightly: 
2016y-11m-11d-13h-18m-42s UTC integration manifest
a0e6725 drm/i915: Use __sg_alloc_table_from_pages for userptr allocations
db3cf46 lib/scatterlist: Introduce and export __sg_alloc_table_from_pages
872b7d5 lib/scatterlist: Avoid potential scatterlist entry overflow
e1ecd31 lib/scatterlist: Fix offset type in sg_alloc_table_from_pages

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2970/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH v2 0/8] Add support for Legacy Hdmi audio

[Mark Brown]

On Thu, Nov 10, 2016 at 10:35:09AM -0600, Pierre-Louis Bossart wrote:
> On 11/9/16 7:19 AM, Mark Brown wrote:

> > None of which is at all unusal.  The Intel hardware really doesn't seem
> > like the sort of special snowflake that people appear to believe it to
> > be.

> I am not sure if this reply was British humor, sarcasm or a proposal? Again

I'm not particularly trying to be funny here, I'm just saying that
without having seen any of the code involved (I got CCed in part way
through this thread...) this sounds like fairly normal HDMI hardware so
it's hard to understand why it can't use the framework code (perhaps
with a bit of extension).  It does seem to be an unfortunate pattern
with HDMI in particular that people seem to see their hardware as
needing to use a separate implementation of everything which gets a bit
frustrating.

> the hardware for Baytrail and Cherrytrail is very simple, the display
> subsystem exposes a DMA interface with a 4 descriptors pointing to buffers
> in system memory and a window of registers to enable DMA transfers and
> signal interrupts for DMA events. Rather than adding ALSA related code in
> the i915 driver, the proposal is to create a subdevice that is given access
> to the relevant register window and a matching driver in sound/x86 that
> would take care of creating a card and implementing ALSA-related
> initializations and buffer/periods management. The interaction between the

That all sounds totally sensible - I think the only real issue here is
exactly what the ALSA subdevice ends up looking like.

> two gfx and audio parts is based on a very limited set of pdata variables
> and callbacks. From the gfx perspective this minimizes the code changes and
> dependencies on ALSA.

Sure, and that's what the hdmi-codec interface was supposed to be doing
as well.

> The hdmi-codec interface seems to assume an ASoC implementation which seems
> over-engineered in this case. There is no specific power management issues,
> no real need for cpu- or codec-dai and not physical link such as I2S/SPDIF.
> The only thing that seems directly useful if the pdata part which I already
> had. If I missed anything I am all ears.

If it's doing the same thing as hdmi-codec then simply not adding
another implementation of essentially the same thing ought to be a win.

If the problem is that it's a bit too much work to fill in the dummy
DAIs then let's just make it easier to instantiate them and a
simple-card to tie everything together.

> Note that I am not trying to solve HDAudio-gfx interaction, just to get
> audio support for baytrail and cherrytrail compute sticks in the mainline.
> I've been porting patches to help users since 4.4, starting from the work
> Canonical did and internal patches, and it gets tiring. At this point I am

Like I say I've not seen these patches (if they're not currently ASoC
patches that's not surprising), I don't know why they've not been
accepted so I can't really comment on that.

> looking for either agreement to proceed with the solution suggested in these
> patches which works fine with minimal impacts to either the drm or alsa
> domains, or an actual useful/pragmatic counter-proposal. If there is a grand
> plan of transition to a unified TBD interface for all HDMI cases then I
> would ask that this is done in a second step after the audio functionality
> is added.

Like I say there's probably room for some helpers for setting this up in
simpler cases but even without them it is very common to end up with
dummy ASoC devices so I'm not sure I'd say they're impractical.  It'd be
good to at least have a concrete assessment of why it's unreasonably
difficult.

I don't have a particularly strong opinion either way on merging the
current code as it is, if there's a commitment to fixing it up then
that's the main thing.


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

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for dev_priv cleanup continuation (rev3)

[Tvrtko Ursulin]

On 10/11/2016 09:42, Tvrtko Ursulin wrote:

On 09/11/2016 12:45, Patchwork wrote:

== Series Details ==

Series: dev_priv cleanup continuation (rev3)
URL   : https://patchwork.freedesktop.org/series/14844/
State : success

== Summary ==

Series 14844v3 dev_priv cleanup continuation
https://patchwork.freedesktop.org/api/1.0/series/14844/revisions/3/mbox/


fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0
skip:15
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0
skip:40
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0
skip:28
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0
skip:32
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0
skip:20
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0
skip:20
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0
skip:53
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0
skip:22
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0
skip:22
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0
skip:22
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0
skip:14
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0
skip:21
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0
skip:21
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0
skip:32
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0
skip:33

972b631c86ecf25d43d16b3617672f481a5cbd08 drm-intel-nightly:
2016y-11m-09d-10h-46m-28s UTC integration manifest
afa7665 drm/i915: Convert i915_drv.c to INTEL_GEN
4ee340c drm/i915: Pass dev_priv to INTEL_INFO everywhere apart from
the gen use
b15872b drm/i915: Further assorted dev_priv cleanups
2b8c634 drm/i915: More assorted dev_priv cleanups
0e86e55 drm/i915: Assorted dev_priv cleanups


Ready for merging and just looking for some maintainer acks.

This is not a very disruptive series so should be fine.

After this the only remaining bit of work is to convert everyone to
INTEL_GEN which I planned to do per file with no strict schedule. One
file this week, another next and so on.

When that is done the __I915__ magic can be removed.

Afterwards we can follow up with looking at which local functions can be
converted to take dev_priv instead of dev, where applicable.


Merged to dinq now since Daniel acked it on #intel-gfx.

Many thanks David for reviewing these boring patches, again!

Regards,

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

[Intel-gfx] [CI 2/2] drm/i915: Stop skipping the final clflush back to system pages

[Chris Wilson]

When we release the shmem backing storage, we make sure that the pages
are coherent with the cpu cache. However, our clflush routine was
skipping the flush as the object had no pages at release time. Fix this by
explicitly flushing the sg_table we are decoupling.

Fixes: 03ac84f1830e ("drm/i915: Pass around sg_table to get_pages/put_pages 
backend")
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 16a9f5d257cf..3b5092a106de 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -220,7 +220,8 @@ i915_gem_object_get_pages_phys(struct drm_i915_gem_object 
*obj)
 }
 
 static void
-__i915_gem_object_release_shmem(struct drm_i915_gem_object *obj)
+__i915_gem_object_release_shmem(struct drm_i915_gem_object *obj,
+   struct sg_table *pages)
 {
GEM_BUG_ON(obj->mm.madv == __I915_MADV_PURGED);
 
@@ -228,7 +229,7 @@ __i915_gem_object_release_shmem(struct drm_i915_gem_object 
*obj)
obj->mm.dirty = false;
 
if ((obj->base.read_domains & I915_GEM_DOMAIN_CPU) == 0)
-   i915_gem_clflush_object(obj, false);
+   drm_clflush_sg(pages);
 
obj->base.read_domains = I915_GEM_DOMAIN_CPU;
obj->base.write_domain = I915_GEM_DOMAIN_CPU;
@@ -238,7 +239,7 @@ static void
 i915_gem_object_put_pages_phys(struct drm_i915_gem_object *obj,
   struct sg_table *pages)
 {
-   __i915_gem_object_release_shmem(obj);
+   __i915_gem_object_release_shmem(obj, pages);
 
if (obj->mm.dirty) {
struct address_space *mapping = obj->base.filp->f_mapping;
@@ -2150,7 +2151,7 @@ i915_gem_object_put_pages_gtt(struct drm_i915_gem_object 
*obj,
struct sgt_iter sgt_iter;
struct page *page;
 
-   __i915_gem_object_release_shmem(obj);
+   __i915_gem_object_release_shmem(obj, pages);
 
i915_gem_gtt_finish_pages(obj, pages);
 
-- 
2.10.2

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

[Intel-gfx] [CI 1/2] drm/i915: Only wait upon the execution timeline when unlocked

[Chris Wilson]

In order to walk the list of all timelines, we currently require the
struct_mutex. We are sometimes called prior to the struct_mutex being
taken by the caller (i.e !I915_WAIT_LOCKED) in which case we can only
trust the global execution timelines (as these are owned by the device).
This means in the unlocked phase we can only wait upon the currently
executing requests and not all queued.

[  175.743243] general protection fault:  [#1] SMP
[  175.743263] Modules linked in: nls_iso8859_1 intel_rapl x86_pkg_temp_thermal 
coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul 
ghash_clmulni_intel iwlwifi aesni_intel aes_x86_64 lrw snd_soc_rt5640 gf128mul 
snd_soc_rl6231 snd_soc_core glue_helper snd_compress snd_pcm_dmaengine 
snd_hda_codec_hdmi ablk_helper snd_hda_codec_realtek cryptd 
snd_hda_codec_generic serio_raw cfg80211 snd_hda_intel snd_hda_codec 
ir_lirc_codec snd_hda_core lirc_dev snd_hwdep snd_pcm lpc_ich mei_me mei 
snd_seq_midi shpchp snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device 
snd_timer rc_rc6_mce acpi_als nuvoton_cir kfifo_buf rc_core snd industrialio 
snd_soc_sst_acpi soundcore snd_soc_sst_match i2c_designware_platform 8250_dw 
i2c_designware_core dw_dmac spi_pxa2xx_platform mac_hid acpi_pad parport_pc 
ppdev lp parport
[  175.743509]  autofs4 i915 e1000e psmouse ptp pps_core xhci_pci ehci_pci ahci 
xhci_hcd ehci_hcd libahci video sdhci_acpi sdhci i2c_hid hid
[  175.743560] CPU: 2 PID: 2386 Comm: wtdg_monitor.sh Tainted: G U  
4.9.0-rc4-nightly+ #2
[  175.743581] Hardware name:  /NUC5i7RYB, BIOS 
RYBDWi35.86A.0358.2016.0606.1423 06/06/2016
[  175.743603] task: 88024509ba80 task.stack: c9007bd18000
[  175.743618] RIP: 0010:[]  [] 
i915_gem_wait_for_idle+0x3b/0x140 [i915]
[  175.743660] RSP: :c9007bd1b9b8  EFLAGS: 00010297
[  175.743674] RAX: 88024489d248 RBX:  RCX: 
[  175.743691] RDX:  RSI:  RDI: 880244898000
[  175.743708] RBP: c9007bd1b9f0 R08:  R09: 0001
[  175.743724] R10: 0028eaf42792 R11: 0001 R12: dead0100
[  175.743741] R13: dead0148 R14: c9007bd1ba5f R15: 0005
[  175.743758] FS:  7f2638330700() GS:880256d0() 
knlGS:
[  175.743777] CS:  0010 DS:  ES:  CR0: 80050033
[  175.743791] CR2: 7f885c8cea40 CR3: 0002416b5000 CR4: 003406e0
[  175.743808] Stack:
[  175.743816]  88024489d248 4509ba80 880244898000 
88024509ba80
[  175.743840]  8b69 c9007bd1ba5f c9007bd1ba5e 
c9007bd1ba28
[  175.743863]  a01b661d   
880244898000
[  175.743886] Call Trace:
[  175.743906]  [] 
i915_gem_shrinker_lock_uninterruptible.constprop.5+0x5d/0xc0 [i915]
[  175.743937]  [] i915_gem_shrinker_oom+0x30/0x1b0 [i915]
[  175.743955]  [] notifier_call_chain+0x49/0x70
[  175.743971]  [] __blocking_notifier_call_chain+0x4d/0x70
[  175.743988]  [] blocking_notifier_call_chain+0x16/0x20
[  175.744005]  [] out_of_memory+0x22c/0x480
[  175.744020]  [] __alloc_pages_slowpath+0x851/0x8ec
[  175.744037]  [] __alloc_pages_nodemask+0x2c1/0x310
[  175.744054]  [] alloc_pages_current+0x88/0x120
[  175.744070]  [] __page_cache_alloc+0xb4/0xc0
[  175.744086]  [] filemap_fault+0x29a/0x500
[  175.744101]  [] ext4_filemap_fault+0x36/0x50
[  175.744117]  [] __do_fault+0x6a/0xe0
[  175.744131]  [] handle_mm_fault+0xd0e/0x1330
[  175.744147]  [] __do_page_fault+0x23c/0x4d0
[  175.744162]  [] do_page_fault+0x30/0x80
[  175.744177]  [] page_fault+0x28/0x30
[  175.744191] Code: 41 57 41 56 41 55 41 54 53 48 83 ec 10 4c 8b a7 48 52 00 
00 89 75 d4 48 89 45 c8 49 39 c4 74 78 4d 8d 6c 24 48 41 bf 05 00 00 00 <49> 8b 
5d 00 48 85 db 74 50 8b 83 20 01 00 00 85 c0 74 15 48 8b
[  175.744320] RIP  [] i915_gem_wait_for_idle+0x3b/0x140 
[i915]
[  175.744351]  RSP 

Fixes: 80b204bce8f2 ("drm/i915: Enable multiple timelines")
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d51fb5d96dc2..16a9f5d257cf 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2934,11 +2934,20 @@ static int wait_for_timeline(struct i915_gem_timeline 
*tl, unsigned int flags)
 
 int i915_gem_wait_for_idle(struct drm_i915_private *i915, unsigned int flags)
 {
-   struct i915_gem_timeline *tl;
int ret;
 
-   list_for_each_entry(tl, >gt.timelines, link) {
-   ret = wait_for_timeline(tl, flags);
+   if (flags & I915_WAIT_LOCKED) {
+   struct i915_gem_timeline *tl;
+
+   lockdep_assert_held(>drm.struct_mutex);
+
+

[Intel-gfx] ✓ Fi.CI.BAT: success for Geminilake enabling (rev2)

[Patchwork]

== Series Details ==

Series: Geminilake enabling (rev2)
URL   : https://patchwork.freedesktop.org/series/15118/
State : success

== Summary ==

Series 15118v2 Geminilake enabling
https://patchwork.freedesktop.org/api/1.0/series/15118/revisions/2/mbox/


fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

7b290828029bfbbb50b1b907b197adc3f30e0d22 drm-intel-nightly: 
2016y-11m-11d-13h-18m-42s UTC integration manifest
5e4b76b drm/i915/glk: Configure number of sprite planes properly
ff6061e drm/i915/glk: Implement core display init/uninit sequence for geminilake
ab20ac43 drm/i915/glk: Allow dotclock up to 2 * cdclk on geminilake
3b702ad drm/i915/glk: Reuse broxton's cdclk code for GLK
2845b00 drm/i915/glk: Update Port PLL enable sequence for Geminilkae
a723276 drm/i915/glk: Set DCC delay range 2 in PLL enable sequence
d970945 drm/i915/glk: Implement Geminilake DDI init sequence
f7e6b49 drm/i915/glk: Add power wells for Geminilake
0ad651c1 drm/i915/glk: Set DDI PHY lane lane optimization for Geminilake too
f415efb drm/i915/glk: Force DDI initialization.
78881dd drm/i915/glk: Reuse broxton code for geminilake
171b4ba drm/i915/glk: Add a IS_GEN9_LP() macro
4c69daa drm/i915/glk: Add Geminilake PCI IDs
55ff300 drm/i915/glk: Introduce Geminilake platform definition
668846a drm/i915: Create a common GEN9_LP_FEATURE.

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2969/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCHv3 i-g-t] lib: substitute cxt BAN_PERIOD with BANNABLE

[Mika Kuoppala]

Chris Wilson  writes:

> On Fri, Nov 11, 2016 at 03:55:03PM +0200, Mika Kuoppala wrote:
>> Context BAN_PERIOD will get depracated so subsitute it with BANNABLE
>> property. Make ctx param test to accept both variants for now
>> until kernel changes have landed, to not break BAT.
>> 
>> v2: check against - EINVAL on get/set ban as it can return -EPERM
>> v3: better naming for get/set (Chris)
>> 
>> Cc: Chris Wilson 
>> Signed-off-by: Mika Kuoppala 
>
> There's a small assumption of symmetry between the get/set paths, but it
> looks ok as a transitional patch.
> Reviewed-by: Chris Wilson 

Pushed. Thanks for review.

-Mika


> -Chris
>
> -- 
> Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/5] dim: autodetect remotes, first part for dim_setup

[Daniel Vetter]

The goals here are multiple:
- simpler configuration through autodetection
- allows seamless upgrading to git worktree for the aux checkouts
- eventually I want to split up drm-misc into a separate remote ...

And yes this is just a start.

v2: Print errors to stderr, otherwise they can't be seen when directly
assigning the result of get_remote_name to a variable.

v3: Rebased to pull the cleanup patches ahead of the dim rework.

v4: Rebase to put the dim rework at the end of the series.

v5: s/get_remote_name/url_to_remote/ to align with Jani.

Signed-off-by: Daniel Vetter 
---
 dim | 94 +
 1 file changed, 40 insertions(+), 54 deletions(-)

diff --git a/dim b/dim
index afa552a77cb1..be3be7bc73d0 100755
--- a/dim
+++ b/dim
@@ -1095,8 +1095,36 @@ function dim_update_branches
update_rerere_cache
 }
 
+function setup_aux_checkout # name remote
+{
+   local name=$1
+   local remote_url=$2
+   local dir=$3
+   local remote
+
+   echo "Setting up $dir ..."
+
+   if [ ! -d $dir ]; then
+   git clone --reference=$DIM_PREFIX/$DIM_DRM_INTEL/.git 
$remote_url $dir
+   cd $dir
+   git config remote.origin.url $remote_url
+   echo "$DIM_PREFIX/$DIM_DRM_INTEL/.git/objects" > 
.git/objects/info/alternates
+   git repack -a -d -l
+   remote=origin
+   else
+   cd $dir
+   remote=`url_to_remote $remote_url`
+   fi
+   if [[ `git branch --list $name` == "" ]] ; then
+   git checkout -t $remote/$name
+   fi
+   cd ..
+}
+
 function dim_setup
 {
+   local remote
+
if [ ! -d $DIM_PREFIX ]; then
echoerr "Directory $DIM_PREFIX doesn't exist."
echoerr "Please set up your repository directory with"
@@ -1115,76 +1143,34 @@ function dim_setup
exit 1
fi
cd $DIM_DRM_INTEL
-   if ! git remote -v | grep "^origin[[:space:]]" | grep 
$linux_upstream_git > /dev/null; then
-   echo "please set up remote origin for $linux_upstream_git"
-   exit 1
-   fi
-   if ! git remote -v | grep "^$DIM_DRM_INTEL_REMOTE[[:space:]]" | grep 
$drm_intel_ssh > /dev/null; then
-   echo "please set up remote $DIM_DRM_INTEL_REMOTE for 
$drm_intel_ssh with:"
-   echo "git remote add $DIM_DRM_INTEL_REMOTE $drm_intel_ssh"
-   echo "or update your configuration."
-   exit 1
-   fi
-   if ! git remote -v | grep "^$DIM_DRM_UPSTREAM_REMOTE[[:space:]]" | grep 
$drm_upstream_git > /dev/null; then
-   echo "please set up remote $DIM_DRM_UPSTREAM_REMOTE for 
$drm_upstream_git with:"
-   echo "git remote add $DIM_DRM_UPSTREAM_REMOTE 
$drm_upstream_git"
-   echo "or update your configuration."
-   exit 1
-   fi
-   cd ..
 
-   echo "Setting up maintainer-tools ..."
-   if [ ! -d maintainer-tools ]; then
-   git clone --reference=$DIM_PREFIX/$DIM_DRM_INTEL/.git 
$drm_intel_ssh maintainer-tools
-   fi
-   cd maintainer-tools
-   git config remote.origin.url $drm_intel_ssh
-   echo "$DIM_PREFIX/$DIM_DRM_INTEL/.git/objects" > 
.git/objects/info/alternates
-   git repack -a -d -l
-   if [[ `git branch --list maintainer-tools` == "" ]] > /dev/null ; then
-   git checkout -t origin/maintainer-tools
-   fi
-   cd ..
+   # check remote configuration
+   remote=`url_to_remote $linux_upstream_git`
+   remote=`url_to_remote $drm_intel_ssh`
+   remote=`url_to_remote $drm_upstream_git`
 
-   echo "Setting up drm-intel-rerere ..."
-   if [ ! -d drm-intel-rerere ]; then
-   git clone --reference=$DIM_PREFIX/$DIM_DRM_INTEL/.git 
$drm_intel_ssh drm-intel-rerere
-   fi
-   cd drm-intel-rerere
-   git config remote.origin.url $drm_intel_ssh
-   echo "$DIM_PREFIX/$DIM_DRM_INTEL/.git/objects" > 
.git/objects/info/alternates
-   git repack -a -d -l
-   if [[ `git branch --list rerere-cache` == "" ]] ; then
-   git checkout -t origin/rerere-cache
-   fi
cd ..
 
-   echo "Setting up drm-intel-nightly ..."
-   if [ ! -d drm-intel-nightly ]; then
-   git clone --reference=$DIM_PREFIX/$DIM_DRM_INTEL/.git 
$drm_intel_ssh drm-intel-nightly
-   fi
+   setup_aux_checkout maintainer-tools $drm_intel_ssh maintainer-tools
+
+   setup_aux_checkout rerere-cache $drm_intel_ssh drm-intel-rerere
+
+   setup_aux_checkout drm-intel-nightly $drm_intel_ssh drm-intel-nightly
cd drm-intel-nightly
-   mkdir -p .git/rr-cache
-   git config remote.origin.url $drm_intel_ssh
-   echo "$DIM_PREFIX/$DIM_DRM_INTEL/.git/objects" > 
.git/objects/info/alternates
-   git repack -a -d -l
-   if [[ `git branch --list drm-intel-nightly` == "" ]] ; 

[Intel-gfx] [PATCH 5/5] dim: Improve the error output when rebuild-nightly fails

[Daniel Vetter]

Joonas rightly complained that the current output is useless and just
confuses.

v2: Bikeshed stuff some more.

Cc: Joonas Lahtinen 
Signed-off-by: Daniel Vetter 
---
 dim | 30 --
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/dim b/dim
index 30aa8485e50b..16235642ef19 100755
--- a/dim
+++ b/dim
@@ -261,18 +261,18 @@ function update_linux_next
 {
cd $DIM_PREFIX/drm-intel-nightly
 
-   local remote=${drm_tip_repos[drm-intel]}
+   local nightly_origin=${drm_tip_repos[drm-intel]}
 
# always update drm-intel-fixes
echo -n "Pushing drm-intel-fixes to for-linux-next-fixes... "
-   git push $DRY_RUN $remote +$remote/drm-intel-fixes:for-linux-next-fixes 
>& /dev/null
+   git push $DRY_RUN $nightly_origin 
+$nightly_origin/drm-intel-fixes:for-linux-next-fixes >& /dev/null
echo "Done."
 
-   if git merge-base --is-ancestor $remote/drm-intel-next-fixes 
$remote/drm-intel-fixes ; then
+   if git merge-base --is-ancestor $nightly_origin/drm-intel-next-fixes 
$nightly_origin/drm-intel-fixes ; then
# -fixes has caught up to dinf, i.e. we're out of the merge
# window. Push the next queue.
echo -n "Out of merge window. Pushing drm-intel-next-queued to 
for-linux-next... "
-   git push $DRY_RUN $remote 
+$remote/drm-intel-next-queued:for-linux-next >& /dev/null
+   git push $DRY_RUN $nightly_origin 
+$nightly_origin/drm-intel-next-queued:for-linux-next >& /dev/null
echo "Done."
else
# dinf is ahead of -fixes, i.e. drm-next has already closed for
@@ -280,17 +280,19 @@ function update_linux_next
# for the current -next cycle. Push dinf
 
echo -n "Pushing drm-intel-next-fixes to for-linux-next... "
-   git push $DRY_RUN $remote 
+$remote/drm-intel-next-fixes:for-linux-next >& /dev/null
+   git push $DRY_RUN $nightly_origin 
+$nightly_origin/drm-intel-next-fixes:for-linux-next >& /dev/null
echo "Done."
fi
 }
 
-function check_conflicts
+function check_conflicts # tree
 {
-   if git diff | grep '\(<<<\|===\|>>>\\)' ; then
-   if [ -n "$1" ]; then
-   echo $*
-   fi
+   if git diff | grep '\(<<<\|===\|>>>\\)' &> 
/dev/null ; then
+   # we need an empty line to make it look pretty
+   echoerr ""
+   echoerr "FAILURE: Could not merge $1"
+   echoerr "See the section \"Resolving Conflicts when Rebuilding 
drm-intel-nightly\""
+   echoerr "in the drm-intel.rst documentation for how to handle 
this situation."
exit 1
fi
true
@@ -388,7 +390,7 @@ function dim_rebuild_nightly
echo -n "Applying manual fixup patch for 
$integration_branch merge... "
patch -p1 -i $fixup_file
fi
-   check_conflicts "Fail: conflict merging $tree"
+   check_conflicts "$repo/$branch"
git add -u
 
# because we filter out fast-forward merges there will
@@ -408,10 +410,10 @@ function dim_rebuild_nightly
git commit --quiet -m "$integration_branch: $time integration manifest"
echo "Done."
 
-   local nightly_remote=${drm_tip_repos[drm-intel]}
+   local nightly_origin=${drm_tip_repos[drm-intel]}
 
echo -n "Pushing $integration_branch... "
-   git push $DRY_RUN $nightly_remote +HEAD >& /dev/null && echo "Done."
+   git push $DRY_RUN $nightly_origin +HEAD >& /dev/null && echo "Done."
 
echo -n "Updating rerere cache... "
cd $rerere
@@ -426,7 +428,7 @@ function dim_rebuild_nightly
echo -n "Nothing changed. "
fi
echo -n "Pushing rerere cache... "
-   git push $DRY_RUN $nightly_remote HEAD >& /dev/null && echo 
"Done."
+   git push $DRY_RUN $nightly_origin HEAD >& /dev/null && echo 
"Done."
else
echo "Fail: Branch setup for the rerere-cache is borked."
exit 1
-- 
2.10.2

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

[Intel-gfx] [PATCH 1/5] dim: Fixup remove-branch for working-trees

[Daniel Vetter]

When there's a working-tree checkout we need to remove that first,
before removing the branch. git complains otherwise. Not sure,
but this might be a recently added more strict test for the git
worktree support, at least I believe the "branch still checkout out
in $dir" warning is new-ish.

v2: Move to the front, also include the git worktree prune call to
clean up the potential mess.

Fixes: f507c9230d31 ("dim: abstract dim_{create,remove}_branch")
Signed-off-by: Daniel Vetter 
---
 dim | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/dim b/dim
index 66ea0dd918b3..afa552a77cb1 100755
--- a/dim
+++ b/dim
@@ -673,12 +673,14 @@ function dim_remove_branch
 
cd $DIM_PREFIX/$DIM_DRM_INTEL
 
-   if ! $DRY git branch -d $branch ; then
-   warn_or_fail "Can't remove $branch in working repo"
-   fi
-
if [[ -d $DIM_PREFIX/$branch ]] ; then
rm -R $DIM_PREFIX/$branch
+   git worktree prune &> /dev/null || true
+   fi
+
+   if [[ `git branch --list $branch`  != "" ]] &&
+  ! $DRY git branch -d $branch  ; then
+   warn_or_fail "Can't remove $branch in working repo"
fi
 
cd $DIM_PREFIX/drm-intel-nightly
-- 
2.10.2

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

[Intel-gfx] [PATCH 4/5] dim: autodetect branches in rebuild-nightly

[Daniel Vetter]

Needs new url-mapping information in nightly.conf to work properly. Only
leftover bit from my original patch after rebasing is to abstract away
the remote for the integration tree.

v2:
- Fix typo when calling rr_cache_dir. Oops.
- Use cut -f 1 instead of sed/regex horrors (jani).

v3: Fix bug that resulted in nesting rr-cache directories.

v4: Rebasing.

v5: Resurrect $repo (as $remote) printing when fetching branches,
originally from my patch.

v6: Use remote instead of origin local variables, to be more
consistent. Picked up from Jani.

Signed-off-by: Daniel Vetter 
---
 dim | 23 ++-
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/dim b/dim
index 5d6cc37eb374..30aa8485e50b 100755
--- a/dim
+++ b/dim
@@ -261,16 +261,18 @@ function update_linux_next
 {
cd $DIM_PREFIX/drm-intel-nightly
 
+   local remote=${drm_tip_repos[drm-intel]}
+
# always update drm-intel-fixes
echo -n "Pushing drm-intel-fixes to for-linux-next-fixes... "
-   git push $DRY_RUN origin +origin/drm-intel-fixes:for-linux-next-fixes 
>& /dev/null
+   git push $DRY_RUN $remote +$remote/drm-intel-fixes:for-linux-next-fixes 
>& /dev/null
echo "Done."
 
-   if git merge-base --is-ancestor origin/drm-intel-next-fixes 
origin/drm-intel-fixes ; then
+   if git merge-base --is-ancestor $remote/drm-intel-next-fixes 
$remote/drm-intel-fixes ; then
# -fixes has caught up to dinf, i.e. we're out of the merge
# window. Push the next queue.
echo -n "Out of merge window. Pushing drm-intel-next-queued to 
for-linux-next... "
-   git push $DRY_RUN origin 
+origin/drm-intel-next-queued:for-linux-next >& /dev/null
+   git push $DRY_RUN $remote 
+$remote/drm-intel-next-queued:for-linux-next >& /dev/null
echo "Done."
else
# dinf is ahead of -fixes, i.e. drm-next has already closed for
@@ -278,7 +280,7 @@ function update_linux_next
# for the current -next cycle. Push dinf
 
echo -n "Pushing drm-intel-next-fixes to for-linux-next... "
-   git push $DRY_RUN origin 
+origin/drm-intel-next-fixes:for-linux-next >& /dev/null
+   git push $DRY_RUN $remote 
+$remote/drm-intel-next-fixes:for-linux-next >& /dev/null
echo "Done."
fi
 }
@@ -346,9 +348,10 @@ function dim_rebuild_nightly
exit 1
fi
 
-   for url in "${drm_tip_repos[@]}"; do
+   for repo in "${!drm_tip_repos[@]}"; do
+   local url=${drm_tip_repos[$repo]}
local remote=$(url_to_remote $url)
-   echo -n "Fetching $remote... "
+   echo -n "Fetching $repo (as $remote) ... "
# git fetch returns 128 if there's nothing to be fetched
git fetch $remote >& /dev/null || true
echo "Done."
@@ -369,8 +372,8 @@ function dim_rebuild_nightly
fi
 
if [ $first == 1 ] ; then
+   git reset --hard $sha1 &> /dev/null
echo "Reset. Done."
-   git reset --hard $sha1 >& /dev/null
first=0
elif git merge --rerere-autoupdate --ff-only $sha1 >& /dev/null 
; then
# nothing to do if just fast-forward
@@ -405,8 +408,10 @@ function dim_rebuild_nightly
git commit --quiet -m "$integration_branch: $time integration manifest"
echo "Done."
 
+   local nightly_remote=${drm_tip_repos[drm-intel]}
+
echo -n "Pushing $integration_branch... "
-   git push $DRY_RUN origin +HEAD >& /dev/null && echo "Done."
+   git push $DRY_RUN $nightly_remote +HEAD >& /dev/null && echo "Done."
 
echo -n "Updating rerere cache... "
cd $rerere
@@ -421,7 +426,7 @@ function dim_rebuild_nightly
echo -n "Nothing changed. "
fi
echo -n "Pushing rerere cache... "
-   git push $DRY_RUN origin HEAD >& /dev/null && echo "Done."
+   git push $DRY_RUN $nightly_remote HEAD >& /dev/null && echo 
"Done."
else
echo "Fail: Branch setup for the rerere-cache is borked."
exit 1
-- 
2.10.2

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

[Intel-gfx] [PATCH 3/5] dim: support git worktree for aux checkouts

[Daniel Vetter]

If available by default. This saves quite a pile of disk-space that
imo making it the default is justified.

Note that this will break the rebuild-nightly script for now,
follow-up patches will fix that.

v2: Rebase to put the dim rework at the end of the series.

Signed-off-by: Daniel Vetter 
---
 dim | 36 +++-
 1 file changed, 27 insertions(+), 9 deletions(-)

diff --git a/dim b/dim
index be3be7bc73d0..5d6cc37eb374 100755
--- a/dim
+++ b/dim
@@ -294,11 +294,20 @@ function check_conflicts
true
 }
 
+function rr_cache_dir
+{
+   if [ -d $DIM_PREFIX/drm-intel-nightly/.git/rr-cache/ ] ; then
+   echo $DIM_PREFIX/drm-intel-nightly/.git/rr-cache/
+   else
+   echo $DIM_PREFIX/$DIM_DRM_INTEL/.git/rr-cache/
+   fi
+}
+
 function update_rerere_cache
 {
cd $DIM_PREFIX/drm-intel-rerere/
git pull
-   cp rr-cache/* $DIM_PREFIX/drm-intel-nightly/.git/rr-cache/ -r
+   cp rr-cache/* `rr_cache_dir` -r
cd -
 }
 
@@ -306,7 +315,7 @@ function dim_revert_rerere
 {
cd $DIM_PREFIX/drm-intel-rerere/
git revert $1
-   rm $DIM_PREFIX/drm-intel-nightly/.git/rr-cache/ -Rf
+   rm `rr_cache_dir`/* -Rf
 }
 
 function dim_rebuild_nightly
@@ -403,7 +412,7 @@ function dim_rebuild_nightly
cd $rerere
if git branch --list rerere-cache | grep '\*' >& /dev/null ; then
git pull >& /dev/null
-   cp $DIM_PREFIX/$integration_branch/.git/rr-cache/* rr-cache -r
+   cp `rr_cache_dir`/* rr-cache -r
git add *.patch >& /dev/null || true
git add rr-cache/* > /dev/null
if git commit -m "$time: $integration_branch rerere cache 
update" >& /dev/null; then
@@ -1105,12 +1114,21 @@ function setup_aux_checkout # name remote
echo "Setting up $dir ..."
 
if [ ! -d $dir ]; then
-   git clone --reference=$DIM_PREFIX/$DIM_DRM_INTEL/.git 
$remote_url $dir
-   cd $dir
-   git config remote.origin.url $remote_url
-   echo "$DIM_PREFIX/$DIM_DRM_INTEL/.git/objects" > 
.git/objects/info/alternates
-   git repack -a -d -l
-   remote=origin
+   if git help worktree &> /dev/null ; then
+   cd $DIM_PREFIX/$DIM_DRM_INTEL
+   remote=`url_to_remote $remote_url`
+   if [[ `git branch --list $name` == "" ]] ; then
+   git branch --track $name $remote/$name
+   fi
+   git worktree add ../$dir $name
+   else
+   git clone --reference=$DIM_PREFIX/$DIM_DRM_INTEL/.git 
$remote_url $dir
+   cd $dir
+   git config remote.origin.url $remote_url
+   echo "$DIM_PREFIX/$DIM_DRM_INTEL/.git/objects" > 
.git/objects/info/alternates
+   git repack -a -d -l
+   remote=origin
+   fi
else
cd $dir
remote=`url_to_remote $remote_url`
-- 
2.10.2

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

[Intel-gfx] [PATCH i-g-t] lib: Pass I915_TILING_NONE if Yf or Ys

[Tomeu Vizoso]

The kernel expects that BOs for framebuffers with
I915_FORMAT_MOD_Yf_TILED will have I915_TILING_NONE.

Fixes: 050c00d53f39 ("lib: Pass I915_TILING_Y to the kernel if Yf or Ys")
Cc: Tvrtko Ursulin 
Signed-off-by: Tomeu Vizoso 
---
 lib/ioctl_wrappers.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index eabf3ee3abe6..8b75b9d4a6cb 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -158,8 +158,9 @@ int __gem_set_tiling(int fd, uint32_t handle, uint32_t 
tiling, uint32_t stride)
 
igt_require_intel(fd);
 
+   /* The kernel doesn't know about these tiling modes, expects NONE */
if (tiling == I915_TILING_Yf || tiling == I915_TILING_Ys)
-   tiling = I915_TILING_Y;
+   tiling = I915_TILING_NONE;
 
memset(, 0, sizeof(st));
do {
-- 
2.7.4

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

[Intel-gfx] [PATCH v3 3/4] lib/scatterlist: Introduce and export __sg_alloc_table_from_pages

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Drivers like i915 benefit from being able to control the maxium
size of the sg coallesced segment while building the scatter-
gather list.

Introduce and export the __sg_alloc_table_from_pages function
which will allow it that control.

v2: Reorder parameters. (Chris Wilson)
v3: Fix incomplete reordering in v2.

Signed-off-by: Tvrtko Ursulin 
Cc: Masahiro Yamada 
Cc: linux-ker...@vger.kernel.org
Cc: Chris Wilson 
---
 include/linux/scatterlist.h | 11 +
 lib/scatterlist.c   | 55 ++---
 2 files changed, 49 insertions(+), 17 deletions(-)

diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index c981bee1a3ae..16b740afeed2 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -261,10 +261,13 @@ void sg_free_table(struct sg_table *);
 int __sg_alloc_table(struct sg_table *, unsigned int, unsigned int,
 struct scatterlist *, gfp_t, sg_alloc_fn *);
 int sg_alloc_table(struct sg_table *, unsigned int, gfp_t);
-int sg_alloc_table_from_pages(struct sg_table *sgt,
-   struct page **pages, unsigned int n_pages,
-   unsigned int offset, unsigned long size,
-   gfp_t gfp_mask);
+int __sg_alloc_table_from_pages(struct sg_table *sgt, struct page **pages,
+   unsigned int n_pages, unsigned int offset,
+   unsigned long size, unsigned int max_segment,
+   gfp_t gfp_mask);
+int sg_alloc_table_from_pages(struct sg_table *sgt, struct page **pages,
+ unsigned int n_pages, unsigned int offset,
+ unsigned long size, gfp_t gfp_mask);
 
 size_t sg_copy_buffer(struct scatterlist *sgl, unsigned int nents, void *buf,
  size_t buflen, off_t skip, bool to_buffer);
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index de15f369b317..7f4d637d3606 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -370,14 +370,15 @@ int sg_alloc_table(struct sg_table *table, unsigned int 
nents, gfp_t gfp_mask)
 EXPORT_SYMBOL(sg_alloc_table);
 
 /**
- * sg_alloc_table_from_pages - Allocate and initialize an sg table from
- *an array of pages
- * @sgt:   The sg table header to use
- * @pages: Pointer to an array of page pointers
- * @n_pages:   Number of pages in the pages array
- * @offset: Offset from start of the first page to the start of a buffer
- * @size:   Number of valid bytes in the buffer (after offset)
- * @gfp_mask:  GFP allocation mask
+ * __sg_alloc_table_from_pages - Allocate and initialize an sg table from
+ *  an array of pages
+ * @sgt:The sg table header to use
+ * @pages:  Pointer to an array of page pointers
+ * @n_pages:Number of pages in the pages array
+ * @offset:  Offset from start of the first page to the start of a buffer
+ * @size:Number of valid bytes in the buffer (after offset)
+ * @max_segment: Maximum size of a single scatterlist node in bytes
+ * @gfp_mask:   GFP allocation mask
  *
  *  Description:
  *Allocate and initialize an sg table from a list of pages. Contiguous
@@ -389,12 +390,11 @@ EXPORT_SYMBOL(sg_alloc_table);
  * Returns:
  *   0 on success, negative error on failure
  */
-int sg_alloc_table_from_pages(struct sg_table *sgt,
-   struct page **pages, unsigned int n_pages,
-   unsigned int offset, unsigned long size,
-   gfp_t gfp_mask)
+int __sg_alloc_table_from_pages(struct sg_table *sgt, struct page **pages,
+   unsigned int n_pages, unsigned int offset,
+   unsigned long size, unsigned int max_segment,
+   gfp_t gfp_mask)
 {
-   const unsigned int max_segment = UINT_MAX;
unsigned int seg_len, chunks;
unsigned int i;
unsigned int cur_page;
@@ -444,6 +444,35 @@ int sg_alloc_table_from_pages(struct sg_table *sgt,
 
return 0;
 }
+EXPORT_SYMBOL(__sg_alloc_table_from_pages);
+
+/**
+ * sg_alloc_table_from_pages - Allocate and initialize an sg table from
+ *an array of pages
+ * @sgt:The sg table header to use
+ * @pages:  Pointer to an array of page pointers
+ * @n_pages:Number of pages in the pages array
+ * @offset:  Offset from start of the first page to the start of a buffer
+ * @size:Number of valid bytes in the buffer (after offset)
+ * @gfp_mask:   GFP allocation mask
+ *
+ *  Description:
+ *Allocate and initialize an sg table from a list of pages. Contiguous
+ *ranges of the pages are squashed into a single scatterlist node. A user
+ *may provide an offset at a start and a size of valid data in a buffer
+ *specified by the page array. The returned sg table is released by
+ *

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Implement Link Rate fallback on Link training failure

[Ville Syrjälä]

On Thu, Nov 10, 2016 at 09:58:31PM +0100, Daniel Vetter wrote:
> On Wed, Nov 09, 2016 at 08:42:08PM -0800, Manasi Navare wrote:
> > @@ -5692,6 +5751,39 @@ static bool intel_edp_init_connector(struct intel_dp 
> > *intel_dp,
> > return false;
> >  }
> >  
> > +static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
> > +{
> > +   struct intel_connector *intel_connector;
> > +   struct drm_connector *connector;
> > +   struct drm_display_mode *mode;
> > +   bool verbose_prune = true;
> > +
> > +   intel_connector = container_of(work, typeof(*intel_connector),
> > +  modeset_retry_work);
> > +   connector = _connector->base;
> > +
> > +   /* Grab the locks before changing connector property*/
> > +   mutex_lock(>dev->mode_config.mutex);
> > +   DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
> > + connector->name);
> > +   list_for_each_entry(mode, >modes, head) {
> > +   mode->status = intel_dp_mode_valid(connector,
> > +  mode);
> > +   }
> > +   drm_mode_prune_invalid(connector->dev, >modes,
> > +  verbose_prune);
> > +
> > +   /* Set connector link status to BAD and send a Uevent to notify
> > +* userspace to do a modeset.
> > +*/
> > +   intel_dp_set_link_status_property(connector,
> > + DRM_MODE_LINK_STATUS_BAD);
> > +   mutex_unlock(>dev->mode_config.mutex);
> > +
> > +   /* Send Hotplug uevent so userspace can reprobe */
> > +   drm_kms_helper_hotplug_event(connector->dev);
> 
> One downside of keeping all the signalling logic here in i915 is that we
> don't have a good spot to put the kerneldoc for this new link status
> property within drm_connector.c for others to easily spot. My suggestion
> would be to extract function with the following rough pseudo-code:
> 
> drm_connector_set_link_status(connector, status)
> {
>   mutex_lock(mode_config.mutex);
> 
>   /* what intel_dp_set_link_status_property() does */
>   
>   mutex_unlock(mode_config.mutex);
>   drm_kms_helper_hotplug_event()
> }
> 
> Within intel_dp_modeset_retry_work_fn we'd then first need to drop the
> lock, and then call this function. The lock drop is a bit ugly,
> but:

The mode re-validation should be done in the core as well. Not sure if
we could just stuff it all into one place, and then there would be no
need for any lock dropping.

> - it doesn't matter from a performance pov, this is a slow, asynchronous
>   work.
> - it doesn't matter for correctnes, the only thing we need is to drop the
>   lock before calling drm_kms_helper_hotplug_event, and that we update the
>   link status and the mode list before that too.
> - long term I expect that properties will get separate locks to protect
>   their values, and restrict mode_config.mutex to just mode probing. Which
>   means drm_connnector_set_link_status will use a different lock anyway.
> - it nicely encapsulates stuff imo.
> 
> Kerneldoc for drm_connector_set_link_status should mention that this needs
> to be run from some async work item, and ofc have the full explanation
> (maybe even quote some pseudo-code, see e.g. drm_modeset_lock.c comments)
> of how this should be used.
> 
> Since this is late-stage polish definitely wait for more feedback and for
> the design to fully settle first.
> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCHv3 i-g-t] lib: substitute cxt BAN_PERIOD with BANNABLE

[Mika Kuoppala]

Mika Kuoppala  writes:

> Context BAN_PERIOD will get depracated so subsitute it with BANNABLE
> property. Make ctx param test to accept both variants for now
> until kernel changes have landed, to not break BAT.
>

The kernel parts are in:
https://cgit.freedesktop.org/~miku/drm-intel/log/?h=hangcheck
https://cgit.freedesktop.org/~miku/drm-intel/commit/?h=hangcheck=9f3c978720a82f3043060b5e43cfd7d4fa79f2bd

-Mika

> v2: check against - EINVAL on get/set ban as it can return -EPERM
> v3: better naming for get/set (Chris)
>
> Cc: Chris Wilson 
> Signed-off-by: Mika Kuoppala 
> ---
>  lib/igt_gt.c  | 77 
> ++-
>  lib/ioctl_wrappers.c  | 16 +--
>  lib/ioctl_wrappers.h  |  3 +-
>  tests/gem_ctx_param.c |  9 --
>  4 files changed, 68 insertions(+), 37 deletions(-)
>
> diff --git a/lib/igt_gt.c b/lib/igt_gt.c
> index a165932..468c771 100644
> --- a/lib/igt_gt.c
> +++ b/lib/igt_gt.c
> @@ -119,11 +119,43 @@ void igt_require_hang_ring(int fd, int ring)
>   igt_skip("hang injection disabled by user");
>  
>   gem_require_ring(fd, ring);
> - gem_context_require_ban_period(fd);
> + gem_context_require_bannable(fd);
>   if (!igt_check_boolean_env_var("IGT_HANG_WITHOUT_RESET", false))
>   igt_require(has_gpu_reset(fd));
>  }
>  
> +static unsigned context_get_ban(int fd, unsigned ctx)
> +{
> + struct local_i915_gem_context_param param;
> +
> + param.param = LOCAL_CONTEXT_PARAM_BANNABLE;
> + param.value = 0;
> + param.size = 0;
> +
> + if (__gem_context_get_param(fd, ) == -EINVAL) {
> + igt_assert(param.value == 0);
> + param.param = LOCAL_CONTEXT_PARAM_BAN_PERIOD;
> + gem_context_get_param(fd, );
> + }
> +
> + return param.value;
> +}
> +
> +static void context_set_ban(int fd, unsigned ctx, unsigned ban)
> +{
> + struct local_i915_gem_context_param param;
> +
> + param.value = ban;
> + param.size = 0;
> + param.param = LOCAL_CONTEXT_PARAM_BANNABLE;
> +
> + if(__gem_context_set_param(fd, ) == -EINVAL) {
> + igt_assert(param.value == ban);
> + param.param = LOCAL_CONTEXT_PARAM_BAN_PERIOD;
> + gem_context_set_param(fd, );
> + }
> +}
> +
>  igt_hang_t igt_allow_hang(int fd, unsigned ctx, unsigned flags)
>  {
>   struct local_i915_gem_context_param param;
> @@ -131,7 +163,7 @@ igt_hang_t igt_allow_hang(int fd, unsigned ctx, unsigned 
> flags)
>  
>   if (!igt_check_boolean_env_var("IGT_HANG", true))
>   igt_skip("hang injection disabled by user");
> - gem_context_require_ban_period(fd);
> + gem_context_require_bannable(fd);
>   if (!igt_check_boolean_env_var("IGT_HANG_WITHOUT_RESET", false))
>   igt_require(has_gpu_reset(fd));
>  
> @@ -148,16 +180,9 @@ igt_hang_t igt_allow_hang(int fd, unsigned ctx, unsigned 
> flags)
>   __gem_context_set_param(fd, );
>   }
>  
> - param.param = LOCAL_CONTEXT_PARAM_BAN_PERIOD;
> - param.value = 0;
> - gem_context_get_param(fd, );
> - ban = param.value;
> -
> - if ((flags & HANG_ALLOW_BAN) == 0) {
> - param.param = LOCAL_CONTEXT_PARAM_BAN_PERIOD;
> - param.value = 0;
> - gem_context_set_param(fd, );
> - }
> + ban = context_get_ban(fd, ctx);
> + if ((flags & HANG_ALLOW_BAN) == 0)
> + context_set_ban(fd, ctx, 0);
>  
>   return (struct igt_hang){ 0, ctx, ban, flags };
>  }
> @@ -166,13 +191,11 @@ void igt_disallow_hang(int fd, igt_hang_t arg)
>  {
>   struct local_i915_gem_context_param param;
>  
> - param.context = arg.ctx;
> - param.size = 0;
> - param.param = LOCAL_CONTEXT_PARAM_BAN_PERIOD;
> - param.value = arg.ban;
> - gem_context_set_param(fd, );
> + context_set_ban(fd, arg.ctx, arg.ban);
>  
>   if ((arg.flags & HANG_ALLOW_CAPTURE) == 0) {
> + param.context = arg.ctx;
> + param.size = 0;
>   param.param = LOCAL_CONTEXT_PARAM_NO_ERROR_CAPTURE;
>   param.value = 0;
>   if (__gem_context_set_param(fd, ))
> @@ -227,16 +250,10 @@ igt_hang_t igt_hang_ctx(int fd,
>   __gem_context_set_param(fd, );
>   }
>  
> - param.param = LOCAL_CONTEXT_PARAM_BAN_PERIOD;
> - param.value = 0;
> - gem_context_get_param(fd, );
> - ban = param.value;
> + ban = context_get_ban(fd, ctx);
>  
> - if ((flags & HANG_ALLOW_BAN) == 0) {
> - param.param = LOCAL_CONTEXT_PARAM_BAN_PERIOD;
> - param.value = 0;
> - gem_context_set_param(fd, );
> - }
> + if ((flags & HANG_ALLOW_BAN) == 0)
> + context_set_ban(fd, ctx, 0);
>  
>   memset(, 0, sizeof(reloc));
>   memset(, 0, sizeof(exec));
> @@ -323,13 +340,11 @@ void igt_post_hang_ring(int fd, igt_hang_t arg)
>  

Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset

[Ville Syrjälä]

On Thu, Nov 10, 2016 at 06:51:40PM +, Cheng, Tony wrote:
> Amdgpu dal implementation will do a test link training at end of detection to 
> verify we can achieve the capability reported in DPCD.  We then report mode 
> base on result of test training.
> 
> AMD hardware (at least the generations supported by amdgpu) is able to link 
> train without timing being setup (DP encoder and CRTC is decoupled).  Do we 
> have limitation from other vendors where you need timing to be there before 
> you can link train?

I can't recall the specifics for all of our supported platforms, but at
least I have the recollection that it would be the case yes.

The other problem wiyh this apporach is that even if you don't need the
crtc, you still need the link itself. What happens if the link is still
active since userspace just didn't bother to shut it down when the cable
was yanked? Can you keep the crtc going but stop it from feeding the
link in a way that userspace won't be able to notice? The kms design has
always been pretty much that policy is in userspace, and thus the kernel
shouldn't shut down crtcs unless explicitly asked to do so.

> 
> We can also past DP1.2 link layer compliance with this approach.
> 
> -Original Message-
> From: Deucher, Alexander 
> Sent: Thursday, November 10, 2016 1:43 PM
> To: 'Jani Nikula' ; Manasi Navare 
> ; dri-de...@lists.freedesktop.org; 
> intel-gfx@lists.freedesktop.org; Wentland, Harry ; 
> Cheng, Tony 
> Cc: Dave Airlie ; Peres, Martin 
> Subject: RE: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during 
> modeset
> 
> Adding Harry and Tony from our display team to review.
> 
> > -Original Message-
> > From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> > Sent: Thursday, November 10, 2016 1:20 PM
> > To: Manasi Navare; dri-de...@lists.freedesktop.org; intel- 
> > g...@lists.freedesktop.org
> > Cc: Dave Airlie; Peres, Martin; Deucher, Alexander
> > Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure 
> > during modeset
> > 
> > On Thu, 10 Nov 2016, Manasi Navare  wrote:
> > > Link training failure is handled by lowering the link rate first 
> > > until it reaches the minimum and keeping the lane count maximum and 
> > > then lowering the lane count until it reaches minimim. These 
> > > fallback values are saved and hotplug uevent is sent to the 
> > > userspace after setting the connector link status property to BAD. 
> > > Userspace should triiger another modeset on a uevent and if link 
> > > status property is BAD. This will retrain the link at fallback values.
> > > This is repeated until the link is successfully trained.
> > >
> > > This has been validated to pass DP compliance.
> > 
> > This cover letter and the commit messages do a good job of explaining 
> > what the patches do. However, you're lacking the crucial information 
> > of
> > *why* we need userspace cooperation to handle link training failures 
> > on DP mode setting, and *why* a new connector property is a good 
> > solution for this.
> > 
> > Here goes, including some alternative approaches we've considered (and 
> > even tried):
> > 
> > At the time userspace does setcrtc, we've already promised the mode 
> > would work. The promise is based on the theoretical capabilities of 
> > the link, but it's possible we can't reach this in practice. The DP 
> > spec describes how the link should be reduced, but we can't reduce the 
> > link below the requirements of the mode. Black screen follows.
> > 
> > One idea would be to have setcrtc return a failure. However, it is my 
> > understanding that it already should not fail as the atomic checks 
> > have passed [citation needed]. It would also conflict with the idea of 
> > making setcrtc asynchronous in the future, returning before the actual 
> > mode setting and link training.
> > 
> > Another idea is to train the link "upfront" at hotplug time, before 
> > pruning the mode list, so that we can do the pruning based on 
> > practical not theoretical capabilities. However, the changes for link 
> > training are pretty drastic, all for the sake of error handling and DP 
> > compliance, when the most common happy day scenario is the current 
> > approach of link training at mode setting time, using the optimal 
> > parameters for the mode. It is also not certain all hardware could do 
> > this without the pipe on; not even all our hardware can do this. Some 
> > of this can be solved, but not trivially.
> > 
> > Both of the above ideas also fail to address link degradation *during* 
> > operation.
> > 
> > So the idea presented in these patches is to do this in a way that a) 
> > changes the current happy day scenario as little as possible, to avoid 
> > regressions, b) can be implemented the same way by all drm drivers, c) 
> > is still opt-in for the 

Re: [Intel-gfx] [PATCHv3 i-g-t] lib: substitute cxt BAN_PERIOD with BANNABLE

[Chris Wilson]

On Fri, Nov 11, 2016 at 03:55:03PM +0200, Mika Kuoppala wrote:
> Context BAN_PERIOD will get depracated so subsitute it with BANNABLE
> property. Make ctx param test to accept both variants for now
> until kernel changes have landed, to not break BAT.
> 
> v2: check against - EINVAL on get/set ban as it can return -EPERM
> v3: better naming for get/set (Chris)
> 
> Cc: Chris Wilson 
> Signed-off-by: Mika Kuoppala 

There's a small assumption of symmetry between the get/set paths, but it
looks ok as a transitional patch.
Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
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/glk: Reuse broxton code for geminilake

[Patchwork]

== Series Details ==

Series: drm/i915/glk: Reuse broxton code for geminilake
URL   : https://patchwork.freedesktop.org/series/15167/
State : failure

== Summary ==

make[4]: *** Waiting for unfinished jobs
  LD  drivers/usb/gadget/udc/udc-core.o
  LD  drivers/spi/built-in.o
  LD  drivers/usb/gadget/udc/built-in.o
  LD  drivers/usb/gadget/built-in.o
  LD [M]  drivers/net/ethernet/intel/igbvf/igbvf.o
  AR  lib/lib.a
cc1: all warnings being treated as errors
  LD  drivers/video/fbdev/core/fb.o
cc1: all warnings being treated as errors
scripts/Makefile.build:290: recipe for target 
'drivers/gpu/drm/i915/intel_mocs.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_mocs.o] Error 1
scripts/Makefile.build:290: recipe for target 'drivers/gpu/drm/i915/i915_irq.o' 
failed
make[4]: *** [drivers/gpu/drm/i915/i915_irq.o] Error 1
  LD  drivers/video/fbdev/core/built-in.o
  EXPORTS lib/lib-ksyms.o
cc1: all warnings being treated as errors
scripts/Makefile.build:290: recipe for target 
'drivers/gpu/drm/i915/intel_bios.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_bios.o] Error 1
  LD  drivers/tty/serial/8250/8250_base.o
cc1: all warnings being treated as errors
scripts/Makefile.build:290: recipe for target 
'drivers/gpu/drm/i915/intel_runtime_pm.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_runtime_pm.o] Error 1
cc1: all warnings being treated as errors
  LD  drivers/tty/serial/8250/built-in.o
  LD  lib/built-in.o
scripts/Makefile.build:290: recipe for target 
'drivers/gpu/drm/i915/intel_i2c.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_i2c.o] Error 1
  LD  drivers/tty/serial/built-in.o
  LD  drivers/thermal/thermal_sys.o
  LD  drivers/thermal/built-in.o
  LD [M]  drivers/net/ethernet/intel/e1000/e1000.o
  LD  drivers/video/fbdev/built-in.o
  LD  fs/btrfs/btrfs.o
  LD  drivers/scsi/sd_mod.o
  LD  drivers/scsi/built-in.o
cc1: all warnings being treated as errors
scripts/Makefile.build:290: recipe for target 
'drivers/gpu/drm/i915/intel_panel.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_panel.o] Error 1
  LD  fs/btrfs/built-in.o
cc1: all warnings being treated as errors
cc1: all warnings being treated as errors
scripts/Makefile.build:290: recipe for target 
'drivers/gpu/drm/i915/intel_dsi.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_dsi.o] Error 1
scripts/Makefile.build:290: recipe for target 
'drivers/gpu/drm/i915/intel_ddi.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_ddi.o] Error 1
cc1: all warnings being treated as errors
  LD  drivers/video/console/built-in.o
  LD  drivers/md/md-mod.o
  LD  drivers/video/built-in.o
  LD  drivers/md/built-in.o
scripts/Makefile.build:290: recipe for target 
'drivers/gpu/drm/i915/intel_hdmi.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_hdmi.o] Error 1
cc1: all warnings being treated as errors
scripts/Makefile.build:290: recipe for target 
'drivers/gpu/drm/i915/intel_dpll_mgr.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_dpll_mgr.o] Error 1
  CC  arch/x86/kernel/cpu/capflags.o
  LD  arch/x86/kernel/cpu/built-in.o
  LD  arch/x86/kernel/built-in.o
  LD  drivers/usb/core/usbcore.o
  LD  drivers/usb/core/built-in.o
  LD  arch/x86/built-in.o
  LD  net/ipv4/built-in.o
  LD  drivers/tty/vt/built-in.o
  LD  drivers/tty/built-in.o
  LD  net/core/built-in.o
  LD  net/built-in.o
cc1: all warnings being treated as errors
scripts/Makefile.build:290: recipe for target 
'drivers/gpu/drm/i915/i915_gem_gtt.o' failed
make[4]: *** [drivers/gpu/drm/i915/i915_gem_gtt.o] Error 1
  LD  drivers/usb/host/xhci-hcd.o
  LD  fs/ext4/ext4.o
  LD [M]  drivers/net/ethernet/intel/igb/igb.o
  LD  fs/ext4/built-in.o
  LD  fs/built-in.o
  LD  drivers/usb/host/built-in.o
cc1: all warnings being treated as errors
  LD  drivers/usb/built-in.o
  LD [M]  drivers/net/ethernet/intel/e1000e/e1000e.o
scripts/Makefile.build:290: recipe for target 
'drivers/gpu/drm/i915/i915_debugfs.o' failed
make[4]: *** [drivers/gpu/drm/i915/i915_debugfs.o] Error 1
cc1: all warnings being treated as errors
scripts/Makefile.build:290: recipe for target 'drivers/gpu/drm/i915/intel_dp.o' 
failed
make[4]: *** [drivers/gpu/drm/i915/intel_dp.o] Error 1
cc1: all warnings being treated as errors
scripts/Makefile.build:290: recipe for target 'drivers/gpu/drm/i915/intel_pm.o' 
failed
make[4]: *** [drivers/gpu/drm/i915/intel_pm.o] Error 1
  LD  drivers/net/ethernet/built-in.o
  LD  drivers/net/built-in.o
cc1: all warnings being treated as errors
scripts/Makefile.build:290: recipe for target 
'drivers/gpu/drm/i915/intel_display.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_display.o] Error 1
scripts/Makefile.build:475: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:475: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:475: 

Re: [Intel-gfx] [PATCH] Implement Limited Video Range

[Ville Syrjälä]

On Fri, Nov 11, 2016 at 09:53:35AM +0100, Peter Frühberger wrote:
> Hi,
> 
> I was implementing this suggestion today and I think that will confuse
> users and also devs maintaining that code. Out of the following reason:
> compress_color_range can be true or false, it does not reference a mode,
> but an additional setting that only influences color clamping / scaling.
> 
> What do we expect if someone runs in Full Range and has
> compress_color_range set to true? Also what do we expect if someone runs in
> Limited Range and additionally set this flag to true? In some cases it
> would do nothing and was not transparent.

I didn't mean you should add a new property for this. Just an internal
flag.

> 
> In my original patch I implemented a new mode, which was: Video Range
> 16:235. That meant: Tell Limited info frame, don't alter any colors. It was
> a combination of two things: limited info frame + compress_color_range =
> false;
> 
> The driver code mainly uses: intel_hdmi->limited_color_range to distinguish
> if colors should be clamped or not. Therefore if the above value was set,
> that just needed setting to false.
> 
> I think if we decide for a compress_color_range bool, it should not work as
> an entire new mode but as an option to alter current mode, meaning
> something not set via "BroadCast RGB".
> 
> Any thoughts on that matter?
> 
> On Wed, Nov 9, 2016 at 9:25 PM, Ville Syrjälä  > wrote:
> 
> > On Wed, Nov 09, 2016 at 09:11:58PM +0100, Peter Frühberger wrote:
> > > I am currently not sure what the way forward should be.
> > >
> > > We are successfully implementing this patch in e.g. LibreELEC an embedded
> > > distribution for home theater pcs. But through current bug reports - I am
> > > not sure, if we should give such functionality to the user, that is
> > > overwritten on a lower level, e.g. it does not what the user expects.
> > >
> > > E.g. since some time displays are driven with 10 or 12 bit from the intel
> > > driver, image data is dithered, scaled back and forth without being
> > > transparent for the user. In fact we have some users with hdmi capture
> > > cards, coming back to us if some decoded values of their video stuff does
> > > not match.
> >
> > Re-reading what was written (can't remember anymore obviously), I think
> > what both me and Daniel were after was a cleaner separation of the
> > "what should the infoframe say?" and "how should we mangle the color
> > data?".
> >
> > Daniel's "limit_color_range" is a wee bit too similar looking to
> > "limited_color_range" for my liking. So how about we go with something
> > like "bool compress_color_range". It also conveys the fact that we're
> > not just clamping things. Any objections/thoughts/better ideas?
> >
> > >
> > > Best regards
> > > Peter
> > >
> > > On Mon, Nov 30, 2015 at 3:11 PM, Ville Syrjälä <
> > > ville.syrj...@linux.intel.com> wrote:
> > >
> > > > On Mon, Nov 30, 2015 at 09:43:32AM +0100, Daniel Vetter wrote:
> > > > > On Mon, Nov 30, 2015 at 08:08:48AM +0100, Peter Frühberger wrote:
> > > > > > (Resent cause of moderation)
> > > > > >
> > > > > > This implements a highly needed feature in a minimal non
> > instructive
> > > > way.
> > > > > > Consider a Limited Range display (like most TVs) where you want to
> > > > watch a
> > > > > > decoded video. The TV is set to limited range and the intel driver
> > also
> > > > > > uses full scaling Limited 16:235 mode, e.g. if you display the gray
> > > > value
> > > > > > 16 - the driver will postprocess it to something like ~ 22.
> > > > > >
> > > > > > The following happens currently in linux intel video world:
> > > > > > Video is decoded with e.g. vaapi, the decoded surface is either
> > used
> > > > via
> > > > > > EGL directly in Limited Range. Limited Range processing takes place
> > > > and at
> > > > > > the end while rendering the intel driver will scale down the
> > limited
> > > > range
> > > > > > data again as it cannot distunguish of the data it gets when e.g.
> > > > rendering
> > > > > > with OpenGL like we succesfully do in kodi.
> > > > > >
> > > > > > Another use case is vaapi when using the old vaCopySurfaceGLX
> > > > > > (vaPutSurface) which would automatically use BT601 / BT709 matrix
> > to
> > > > > > upscale the content without any dithering to Full Range RGB. Later
> > on
> > > > this
> > > > > > is scaled down again with the Limited 16:235 setting and output.
> > > > Quality
> > > > > > degrades two times.
> > > > > >
> > > > > > Users and applications widely used want to make sure that colors
> > > > appear on
> > > > > > screen like they were processed after the last processing step. In
> > > > video
> > > > > > case two use cases make sense:
> > > > > >
> > > > > > a) scaling limited range to full range with dithering applied when
> > you
> > > > need
> > > > > > to output fullrange
> > > > > > b) already having limited range and outputting that without any
> > further
> > > > > > touching by the driver

[Intel-gfx] [PATCHv3 i-g-t] lib: substitute cxt BAN_PERIOD with BANNABLE

[Mika Kuoppala]

Context BAN_PERIOD will get depracated so subsitute it with BANNABLE
property. Make ctx param test to accept both variants for now
until kernel changes have landed, to not break BAT.

v2: check against - EINVAL on get/set ban as it can return -EPERM
v3: better naming for get/set (Chris)

Cc: Chris Wilson 
Signed-off-by: Mika Kuoppala 
---
 lib/igt_gt.c  | 77 ++-
 lib/ioctl_wrappers.c  | 16 +--
 lib/ioctl_wrappers.h  |  3 +-
 tests/gem_ctx_param.c |  9 --
 4 files changed, 68 insertions(+), 37 deletions(-)

diff --git a/lib/igt_gt.c b/lib/igt_gt.c
index a165932..468c771 100644
--- a/lib/igt_gt.c
+++ b/lib/igt_gt.c
@@ -119,11 +119,43 @@ void igt_require_hang_ring(int fd, int ring)
igt_skip("hang injection disabled by user");
 
gem_require_ring(fd, ring);
-   gem_context_require_ban_period(fd);
+   gem_context_require_bannable(fd);
if (!igt_check_boolean_env_var("IGT_HANG_WITHOUT_RESET", false))
igt_require(has_gpu_reset(fd));
 }
 
+static unsigned context_get_ban(int fd, unsigned ctx)
+{
+   struct local_i915_gem_context_param param;
+
+   param.param = LOCAL_CONTEXT_PARAM_BANNABLE;
+   param.value = 0;
+   param.size = 0;
+
+   if (__gem_context_get_param(fd, ) == -EINVAL) {
+   igt_assert(param.value == 0);
+   param.param = LOCAL_CONTEXT_PARAM_BAN_PERIOD;
+   gem_context_get_param(fd, );
+   }
+
+   return param.value;
+}
+
+static void context_set_ban(int fd, unsigned ctx, unsigned ban)
+{
+   struct local_i915_gem_context_param param;
+
+   param.value = ban;
+   param.size = 0;
+   param.param = LOCAL_CONTEXT_PARAM_BANNABLE;
+
+   if(__gem_context_set_param(fd, ) == -EINVAL) {
+   igt_assert(param.value == ban);
+   param.param = LOCAL_CONTEXT_PARAM_BAN_PERIOD;
+   gem_context_set_param(fd, );
+   }
+}
+
 igt_hang_t igt_allow_hang(int fd, unsigned ctx, unsigned flags)
 {
struct local_i915_gem_context_param param;
@@ -131,7 +163,7 @@ igt_hang_t igt_allow_hang(int fd, unsigned ctx, unsigned 
flags)
 
if (!igt_check_boolean_env_var("IGT_HANG", true))
igt_skip("hang injection disabled by user");
-   gem_context_require_ban_period(fd);
+   gem_context_require_bannable(fd);
if (!igt_check_boolean_env_var("IGT_HANG_WITHOUT_RESET", false))
igt_require(has_gpu_reset(fd));
 
@@ -148,16 +180,9 @@ igt_hang_t igt_allow_hang(int fd, unsigned ctx, unsigned 
flags)
__gem_context_set_param(fd, );
}
 
-   param.param = LOCAL_CONTEXT_PARAM_BAN_PERIOD;
-   param.value = 0;
-   gem_context_get_param(fd, );
-   ban = param.value;
-
-   if ((flags & HANG_ALLOW_BAN) == 0) {
-   param.param = LOCAL_CONTEXT_PARAM_BAN_PERIOD;
-   param.value = 0;
-   gem_context_set_param(fd, );
-   }
+   ban = context_get_ban(fd, ctx);
+   if ((flags & HANG_ALLOW_BAN) == 0)
+   context_set_ban(fd, ctx, 0);
 
return (struct igt_hang){ 0, ctx, ban, flags };
 }
@@ -166,13 +191,11 @@ void igt_disallow_hang(int fd, igt_hang_t arg)
 {
struct local_i915_gem_context_param param;
 
-   param.context = arg.ctx;
-   param.size = 0;
-   param.param = LOCAL_CONTEXT_PARAM_BAN_PERIOD;
-   param.value = arg.ban;
-   gem_context_set_param(fd, );
+   context_set_ban(fd, arg.ctx, arg.ban);
 
if ((arg.flags & HANG_ALLOW_CAPTURE) == 0) {
+   param.context = arg.ctx;
+   param.size = 0;
param.param = LOCAL_CONTEXT_PARAM_NO_ERROR_CAPTURE;
param.value = 0;
if (__gem_context_set_param(fd, ))
@@ -227,16 +250,10 @@ igt_hang_t igt_hang_ctx(int fd,
__gem_context_set_param(fd, );
}
 
-   param.param = LOCAL_CONTEXT_PARAM_BAN_PERIOD;
-   param.value = 0;
-   gem_context_get_param(fd, );
-   ban = param.value;
+   ban = context_get_ban(fd, ctx);
 
-   if ((flags & HANG_ALLOW_BAN) == 0) {
-   param.param = LOCAL_CONTEXT_PARAM_BAN_PERIOD;
-   param.value = 0;
-   gem_context_set_param(fd, );
-   }
+   if ((flags & HANG_ALLOW_BAN) == 0)
+   context_set_ban(fd, ctx, 0);
 
memset(, 0, sizeof(reloc));
memset(, 0, sizeof(exec));
@@ -323,13 +340,11 @@ void igt_post_hang_ring(int fd, igt_hang_t arg)
   I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
gem_close(fd, arg.handle);
 
-   param.context = arg.ctx;
-   param.size = 0;
-   param.param = LOCAL_CONTEXT_PARAM_BAN_PERIOD;
-   param.value = arg.ban;
-   gem_context_set_param(fd, );
+   context_set_ban(fd, arg.ctx, arg.ban);
 
if ((arg.flags & HANG_ALLOW_CAPTURE) == 0) {
+  

Re: [Intel-gfx] i915: LVDS display (or LVDS->DVI) via eDP as 2nd display

[Ville Syrjälä]

On Fri, Nov 11, 2016 at 02:19:36PM +0100, Stefan Roese wrote:
> Hi!
> 
> I'm currently trying to enable the 2nd display on our Bay Trail
> Atom E3845 SoC. This is on the Congatec SoM "conga-QA3":
> 
> http://www.congatec.com/en/products/qseven/conga-qa3.html
> 
> On this SoM, the eDP is converted to LVDS via an NXP PTN3460
> and available as LVDS on the baseboard. My current setup is that
> the 1st display is connected to HDMI1. This works just fine.
> In the production version I would like to use a LVDS display
> connected via eDP from the Bay Trail Atom. Since we don't have
> this LVDS display yet, I'm currently testing with this
> LVDS -> DVI adapter board:
> 
> http://www.congatec.com/de/produkte/zubehoer/conga-ldvi.html
> 
> So my current setup for this 2nd display is:
> 
> eDP -> LVDS -> DVI
> 
> which does not work.
> 
> Here my xrandr output:
> 
> Screen 0: minimum 8 x 8, current 1920 x 1200, maximum 32767 x 32767
> DP1 disconnected (normal left inverted right x axis y axis)
> DP2 disconnected (normal left inverted right x axis y axis)
> HDMI1 connected primary 1920x1200+0+0 (normal left inverted right x axis y 
> axis) 597mm x 336mm
>1920x1200 59.95* 
>1920x1080 60.00  
>1600x1200 60.00  
>1680x1050 59.88  
>1280x1024 75.0260.02  
>1280x800  59.91  
>1152x864  75.00  
>1024x768  75.0360.00  
>800x600   75.0060.32  
>640x480   75.0059.94  
>720x400   70.08  
> HDMI2 disconnected (normal left inverted right x axis y axis)
> VGA1 disconnected (normal left inverted right x axis y axis)
> VIRTUAL1 disconnected (normal left inverted right x axis y axis)
> 
> 
> When I now try to add and enable DP1 (this is the correct port for
> the eDP, right?), then I get these errors / warnings:

Not sure how the panel power for the LVDS output is hooked up, but if it
depends on the panel power pin from the soc, then you'll need to modify
the VBT to indicate that the port is really an eDP port as opposed to a
regular DP port (see intel_bios_is_port_edp()). Or you can of course just
hack up the driver to behave as if the VBT had indicated an eDP port
(good enough to confirm the theory at least).

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

Re: [Intel-gfx] [PATCH v2] drm/i915/glk: Reuse broxton code for geminilake

[Ander Conselvan De Oliveira]

Resent with proper --in-reply-to . Please ignore.

On Fri, 2016-11-11 at 15:31 +0200, Ander Conselvan de Oliveira wrote:
> Geminilake is mostly backwards compatible with broxton, so change most
> of the IS_BROXTON() checks to IS_GEN9_LP(). Differences between the
> platforms will be implemented in follow-up patches.
> 
> v2: Don't reuse broxton's path in intel_update_max_cdclk().
> Don't set plane count as in broxton.
> 
> v3: Rebase
> 
> v4: Include the check intel_bios_is_port_hpd_inverted().
> Commit message.
> 
> v5: Leave i915_dmc_info() out; glk's csr version != bxt's. (Rodrigo)
> 
> Signed-off-by: Ander Conselvan de Oliveira  com>
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 10 +-
>  drivers/gpu/drm/i915/i915_gem_gtt.c |  8 
>  drivers/gpu/drm/i915/i915_irq.c | 10 +-
>  drivers/gpu/drm/i915/i915_reg.h |  4 ++--
>  drivers/gpu/drm/i915/intel_bios.c   |  2 +-
>  drivers/gpu/drm/i915/intel_ddi.c| 10 +-
>  drivers/gpu/drm/i915/intel_display.c|  8 
>  drivers/gpu/drm/i915/intel_dp.c | 20 ++--
>  drivers/gpu/drm/i915/intel_dpll_mgr.c   |  2 +-
>  drivers/gpu/drm/i915/intel_dsi.c| 28 ++--
>  drivers/gpu/drm/i915/intel_dsi_pll.c| 12 ++--
>  drivers/gpu/drm/i915/intel_hdmi.c   |  6 +++---
>  drivers/gpu/drm/i915/intel_i2c.c|  4 ++--
>  drivers/gpu/drm/i915/intel_mocs.c   |  2 +-
>  drivers/gpu/drm/i915/intel_panel.c  |  2 +-
>  drivers/gpu/drm/i915/intel_pm.c |  6 +++---
>  drivers/gpu/drm/i915/intel_runtime_pm.c |  6 +++---
>  17 files changed, 70 insertions(+), 70 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index b681d42..5d349d6 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1128,7 +1128,7 @@ static int i915_frequency_info(struct seq_file *m, void
> *unused)
>   int max_freq;
>  
>   rp_state_limits = I915_READ(GEN6_RP_STATE_LIMITS);
> - if (IS_BROXTON(dev_priv)) {
> + if (IS_GEN9_LP(dev_priv)) {
>   rp_state_cap = I915_READ(BXT_RP_STATE_CAP);
>   gt_perf_status = I915_READ(BXT_GT_PERF_STATUS);
>   } else {
> @@ -1224,7 +1224,7 @@ static int i915_frequency_info(struct seq_file *m, void
> *unused)
>   seq_printf(m, "Down threshold: %d%%\n",
>      dev_priv->rps.down_threshold);
>  
> - max_freq = (IS_BROXTON(dev_priv) ? rp_state_cap >> 0 :
> + max_freq = (IS_GEN9_LP(dev_priv) ? rp_state_cap >> 0 :
>   rp_state_cap >> 16) & 0xff;
>   max_freq *= (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv) ?
>    GEN9_FREQ_SCALER : 1);
> @@ -1237,7 +1237,7 @@ static int i915_frequency_info(struct seq_file *m, void
> *unused)
>   seq_printf(m, "Nominal (RP1) frequency: %dMHz\n",
>      intel_gpu_freq(dev_priv, max_freq));
>  
> - max_freq = (IS_BROXTON(dev_priv) ? rp_state_cap >> 16 :
> + max_freq = (IS_GEN9_LP(dev_priv) ? rp_state_cap >> 16 :
>   rp_state_cap >> 0) & 0xff;
>   max_freq *= (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv) ?
>    GEN9_FREQ_SCALER : 1);
> @@ -5185,7 +5185,7 @@ static void gen9_sseu_device_status(struct
> drm_i915_private *dev_priv,
>   u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2];
>  
>   /* BXT has a single slice and at most 3 subslices. */
> - if (IS_BROXTON(dev_priv)) {
> + if (IS_GEN9_LP(dev_priv)) {
>   s_max = 1;
>   ss_max = 3;
>   }
> @@ -5219,7 +5219,7 @@ static void gen9_sseu_device_status(struct
> drm_i915_private *dev_priv,
>   for (ss = 0; ss < ss_max; ss++) {
>   unsigned int eu_cnt;
>  
> - if (IS_BROXTON(dev_priv)) {
> + if (IS_GEN9_LP(dev_priv)) {
>   if (!(s_reg[s] & (GEN9_PGCTL_SS_ACK(ss
>   /* skip disabled subslice */
>   continue;
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index a5fafa3..36483a2 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -377,7 +377,7 @@ static void kunmap_page_dma(struct drm_i915_private
> *dev_priv, void *vaddr)
>   /* There are only few exceptions for gen >=6. chv and bxt.
>    * And we are not sure about the latter so play safe for now.
>    */
> - if (IS_CHERRYVIEW(dev_priv) || IS_BROXTON(dev_priv))
> + if (IS_CHERRYVIEW(dev_priv) || IS_GEN9_LP(dev_priv))
>   drm_clflush_virt_range(vaddr, PAGE_SIZE);
>  
>   kunmap_atomic(vaddr);
> 

[Intel-gfx] [PATCH v2] drm/i915/glk: Reuse broxton code for geminilake

[Ander Conselvan de Oliveira]

Geminilake is mostly backwards compatible with broxton, so change most
of the IS_BROXTON() checks to IS_GEN9_LP(). Differences between the
platforms will be implemented in follow-up patches.

v2: Don't reuse broxton's path in intel_update_max_cdclk().
Don't set plane count as in broxton.

v3: Rebase

v4: Include the check intel_bios_is_port_hpd_inverted().
Commit message.

v5: Leave i915_dmc_info() out; glk's csr version != bxt's. (Rodrigo)

Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/i915_debugfs.c | 10 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c |  8 
 drivers/gpu/drm/i915/i915_irq.c | 10 +-
 drivers/gpu/drm/i915/i915_reg.h |  4 ++--
 drivers/gpu/drm/i915/intel_bios.c   |  2 +-
 drivers/gpu/drm/i915/intel_ddi.c| 10 +-
 drivers/gpu/drm/i915/intel_display.c|  8 
 drivers/gpu/drm/i915/intel_dp.c | 20 ++--
 drivers/gpu/drm/i915/intel_dpll_mgr.c   |  2 +-
 drivers/gpu/drm/i915/intel_dsi.c| 28 ++--
 drivers/gpu/drm/i915/intel_dsi_pll.c| 12 ++--
 drivers/gpu/drm/i915/intel_hdmi.c   |  6 +++---
 drivers/gpu/drm/i915/intel_i2c.c|  4 ++--
 drivers/gpu/drm/i915/intel_mocs.c   |  2 +-
 drivers/gpu/drm/i915/intel_panel.c  |  2 +-
 drivers/gpu/drm/i915/intel_pm.c |  6 +++---
 drivers/gpu/drm/i915/intel_runtime_pm.c |  6 +++---
 17 files changed, 70 insertions(+), 70 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index b681d42..5d349d6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1128,7 +1128,7 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
int max_freq;
 
rp_state_limits = I915_READ(GEN6_RP_STATE_LIMITS);
-   if (IS_BROXTON(dev_priv)) {
+   if (IS_GEN9_LP(dev_priv)) {
rp_state_cap = I915_READ(BXT_RP_STATE_CAP);
gt_perf_status = I915_READ(BXT_GT_PERF_STATUS);
} else {
@@ -1224,7 +1224,7 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
seq_printf(m, "Down threshold: %d%%\n",
   dev_priv->rps.down_threshold);
 
-   max_freq = (IS_BROXTON(dev_priv) ? rp_state_cap >> 0 :
+   max_freq = (IS_GEN9_LP(dev_priv) ? rp_state_cap >> 0 :
rp_state_cap >> 16) & 0xff;
max_freq *= (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv) ?
 GEN9_FREQ_SCALER : 1);
@@ -1237,7 +1237,7 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
seq_printf(m, "Nominal (RP1) frequency: %dMHz\n",
   intel_gpu_freq(dev_priv, max_freq));
 
-   max_freq = (IS_BROXTON(dev_priv) ? rp_state_cap >> 16 :
+   max_freq = (IS_GEN9_LP(dev_priv) ? rp_state_cap >> 16 :
rp_state_cap >> 0) & 0xff;
max_freq *= (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv) ?
 GEN9_FREQ_SCALER : 1);
@@ -5185,7 +5185,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2];
 
/* BXT has a single slice and at most 3 subslices. */
-   if (IS_BROXTON(dev_priv)) {
+   if (IS_GEN9_LP(dev_priv)) {
s_max = 1;
ss_max = 3;
}
@@ -5219,7 +5219,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
for (ss = 0; ss < ss_max; ss++) {
unsigned int eu_cnt;
 
-   if (IS_BROXTON(dev_priv)) {
+   if (IS_GEN9_LP(dev_priv)) {
if (!(s_reg[s] & (GEN9_PGCTL_SS_ACK(ss
/* skip disabled subslice */
continue;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index a5fafa3..36483a2 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -377,7 +377,7 @@ static void kunmap_page_dma(struct drm_i915_private 
*dev_priv, void *vaddr)
/* There are only few exceptions for gen >=6. chv and bxt.
 * And we are not sure about the latter so play safe for now.
 */
-   if (IS_CHERRYVIEW(dev_priv) || IS_BROXTON(dev_priv))
+   if (IS_CHERRYVIEW(dev_priv) || IS_GEN9_LP(dev_priv))
drm_clflush_virt_range(vaddr, PAGE_SIZE);
 
kunmap_atomic(vaddr);
@@ -2946,7 +2946,7 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 
size)
 * resort to an uncached mapping. The WC issue is easily caught by the
 * readback check when writing GTT PTE entries.
 */
-   if 

Re: [Intel-gfx] [PATCH] drm/i915: Only wait upon the execution timeline when unlocked

[Chris Wilson]

On Fri, Nov 11, 2016 at 03:23:49PM +0200, Joonas Lahtinen wrote:
> On to, 2016-11-10 at 17:36 +, Chris Wilson wrote:
> > In order to walk the list of all timelines, we currently require the
> > struct_mutex. We are sometimes called prior to the struct_mutex being
> > taken by the caller (i.e !I915_WAIT_LOCKED) in which case we can only
> > trust the global execution timelines (as these are owned by the device).
> > This means in the unlocked phase we can only wait upon the currently
> > executing requests and not all queued.
> > 
> > [  175.743243] general protection fault:  [#1] SMP
> > [  175.743263] Modules linked in: nls_iso8859_1 intel_rapl 
> > x86_pkg_temp_thermal coretemp kvm_intel kvm irqbypass crct10dif_pclmul 
> > crc32_pclmul ghash_clmulni_intel iwlwifi aesni_intel aes_x86_64 lrw 
> > snd_soc_rt5640 gf128mul snd_soc_rl6231 snd_soc_core glue_helper 
> > snd_compress snd_pcm_dmaengine snd_hda_codec_hdmi ablk_helper 
> > snd_hda_codec_realtek cryptd snd_hda_codec_generic serio_raw cfg80211 
> > snd_hda_intel snd_hda_codec ir_lirc_codec snd_hda_core lirc_dev snd_hwdep 
> > snd_pcm lpc_ich mei_me mei snd_seq_midi shpchp snd_seq_midi_event 
> > snd_rawmidi snd_seq snd_seq_device snd_timer rc_rc6_mce acpi_als 
> > nuvoton_cir kfifo_buf rc_core snd industrialio snd_soc_sst_acpi soundcore 
> > snd_soc_sst_match i2c_designware_platform 8250_dw i2c_designware_core 
> > dw_dmac spi_pxa2xx_platform mac_hid acpi_pad parport_pc ppdev lp parport
> > [  175.743509]  autofs4 i915 e1000e psmouse ptp pps_core xhci_pci ehci_pci 
> > ahci xhci_hcd ehci_hcd libahci video sdhci_acpi sdhci i2c_hid hid
> > [  175.743560] CPU: 2 PID: 2386 Comm: wtdg_monitor.sh Tainted: G U  
> > 4.9.0-rc4-nightly+ #2
> > [  175.743581] Hardware name:  /NUC5i7RYB, BIOS 
> > RYBDWi35.86A.0358.2016.0606.1423 06/06/2016
> > [  175.743603] task: 88024509ba80 task.stack: c9007bd18000
> > [  175.743618] RIP: 0010:[]  [] 
> > i915_gem_wait_for_idle+0x3b/0x140 [i915]
> > [  175.743660] RSP: :c9007bd1b9b8  EFLAGS: 00010297
> > [  175.743674] RAX: 88024489d248 RBX:  RCX: 
> > 
> > [  175.743691] RDX:  RSI:  RDI: 
> > 880244898000
> > [  175.743708] RBP: c9007bd1b9f0 R08:  R09: 
> > 0001
> > [  175.743724] R10: 0028eaf42792 R11: 0001 R12: 
> > dead0100
> > [  175.743741] R13: dead0148 R14: c9007bd1ba5f R15: 
> > 0005
> > [  175.743758] FS:  7f2638330700() GS:880256d0() 
> > knlGS:
> > [  175.743777] CS:  0010 DS:  ES:  CR0: 80050033
> > [  175.743791] CR2: 7f885c8cea40 CR3: 0002416b5000 CR4: 
> > 003406e0
> > [  175.743808] Stack:
> > [  175.743816]  88024489d248 4509ba80 880244898000 
> > 88024509ba80
> > [  175.743840]  8b69 c9007bd1ba5f c9007bd1ba5e 
> > c9007bd1ba28
> > [  175.743863]  a01b661d   
> > 880244898000
> > [  175.743886] Call Trace:
> > [  175.743906]  [] 
> > i915_gem_shrinker_lock_uninterruptible.constprop.5+0x5d/0xc0 [i915]
> > [  175.743937]  [] i915_gem_shrinker_oom+0x30/0x1b0 [i915]
> > [  175.743955]  [] notifier_call_chain+0x49/0x70
> > [  175.743971]  [] 
> > __blocking_notifier_call_chain+0x4d/0x70
> > [  175.743988]  [] blocking_notifier_call_chain+0x16/0x20
> > [  175.744005]  [] out_of_memory+0x22c/0x480
> > [  175.744020]  [] __alloc_pages_slowpath+0x851/0x8ec
> > [  175.744037]  [] __alloc_pages_nodemask+0x2c1/0x310
> > [  175.744054]  [] alloc_pages_current+0x88/0x120
> > [  175.744070]  [] __page_cache_alloc+0xb4/0xc0
> > [  175.744086]  [] filemap_fault+0x29a/0x500
> > [  175.744101]  [] ext4_filemap_fault+0x36/0x50
> > [  175.744117]  [] __do_fault+0x6a/0xe0
> > [  175.744131]  [] handle_mm_fault+0xd0e/0x1330
> > [  175.744147]  [] __do_page_fault+0x23c/0x4d0
> > [  175.744162]  [] do_page_fault+0x30/0x80
> > [  175.744177]  [] page_fault+0x28/0x30
> > [  175.744191] Code: 41 57 41 56 41 55 41 54 53 48 83 ec 10 4c 8b a7 48 52 
> > 00 00 89 75 d4 48 89 45 c8 49 39 c4 74 78 4d 8d 6c 24 48 41 bf 05 00 00 00 
> > <49> 8b 5d 00 48 85 db 74 50 8b 83 20 01 00 00 85 c0 74 15 48 8b
> > [  175.744320] RIP  [] i915_gem_wait_for_idle+0x3b/0x140 
> > [i915]
> > [  175.744351]  RSP 
> > 
> > Fixes: 80b204bce8f2 ("drm/i915: Enable multiple timelines")
> > > Signed-off-by: Chris Wilson 
> > > Cc: Joonas Lahtinen 
> 
> Reviewed-by: Joonas Lahtinen 

I was expecting at least a little fight over the lack of presentation of
possible alternatives in the commitlog!

It is obviously not an ideal unlocked wait_for_idle, but for its couple
of users it seems a reasonable compromise to going full on struct_mutexless.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [Intel-gfx] [PATCH 1/2] shmem: Support for registration of driver/file owner specific ops

[Chris Wilson]

On Thu, Nov 10, 2016 at 09:52:34PM +0530, Goel, Akash wrote:
> 
> 
> On 11/10/2016 11:06 AM, Hugh Dickins wrote:
> >On Fri, 4 Nov 2016, akash.g...@intel.com wrote:
> >>Cc: Hugh Dickins 
> >>Cc: linux...@kvack.org
> >>Cc: linux-ker...@vger.linux.org
> >>Signed-off-by: Sourab Gupta 
> >>Signed-off-by: Akash Goel 
> >>Reviewed-by: Chris Wilson 
> >
> >That doesn't seem quite right: the From line above implies that Chris
> >wrote it, and should be first Signer; but perhaps the From line is wrong.
> >
> Chris only wrote this patch initially, will do the required correction.

Akash is being modest. I gave him an idea I had been toying with to help
reduce premature oom, he is the one who deserves credit for turning it
into a functional patch and putting it into production.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/dp/i915: Fix DP link rate math

[Ville Syrjälä]

On Wed, Nov 09, 2016 at 09:32:29PM -0800, Dhinakaran Pandiyan wrote:
> We store DP link rates as link clock frequencies in kHz, just like all
> other clock values. But, DP link rates in the DP Spec are expressed in
> Gbps/lane, which seems to have led to some confusion.
> 
> E.g., for HBR2
> Max. data rate = 5.4 Gbps/lane x 4 lane x 8/10 x 1/8 = 216 kBps
> where, 8/10 is for channel encoding and 1/8 is for bit to Byte conversion
> 
> Using link clock frequency, like we do
> Max. data rate = 54 kHz * 4 lanes = 216 kSymbols/s
> Because, each symbol has 8 bit of data, this is 216 kBps
> and there is no need to account for channel encoding here.
> 
> But, currently we do 54 kHz * 4 lanes * (8/10) = 1728000 kBps
> 
> Similarly, while computing the required link bandwidth for a mode,
> there is a mysterious 1/10 term.
> This should simply be pixel_clock kHz * bpp * 1/8  to give the final
> result in kBps
> 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 28 +---
>  1 file changed, 9 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 8f313c1..7a9e122 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -161,33 +161,23 @@ static u8 intel_dp_max_lane_count(struct intel_dp 
> *intel_dp)
>   return min(source_max, sink_max);
>  }
>  
> -/*
> - * The units on the numbers in the next two are... bizarre.  Examples will
> - * make it clearer; this one parallels an example in the eDP spec.
> - *
> - * intel_dp_max_data_rate for one lane of 2.7GHz evaluates as:
> - *
> - * 27 * 1 * 8 / 10 == 216000
> - *
> - * The actual data capacity of that configuration is 2.16Gbit/s, so the
> - * units are decakilobits.  ->clock in a drm_display_mode is in kilohertz -
> - * or equivalently, kilopixels per second - so for 1680x1050R it'd be
> - * 119000.  At 18bpp that's 2142000 kilobits per second.
> - *
> - * Thus the strange-looking division by 10 in intel_dp_link_required, to
> - * get the result in decakilobits instead of kilobits.
> - */
> -
>  static int
>  intel_dp_link_required(int pixel_clock, int bpp)
>  {
> - return (pixel_clock * bpp + 9) / 10;
> + /* pixel_clock is in kHz, divide bpp by 8 to return the value in kBps*/

Probably best not to mix in the kBps unit here and instead just talk
in terms of the symbol clock.

> + return (pixel_clock * bpp + 7) / 8;

DIV_ROUND_UP()

>  }
>  
>  static int
>  intel_dp_max_data_rate(int max_link_clock, int max_lanes)
>  {
> - return (max_link_clock * max_lanes * 8) / 10;
> + /* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
> +  * link rate that is generally expressed in Gbps. Since, 8 bits data is
> +  * transmitted every LS_Clk per lane, there is no need to account for
> +  * the channel encoding that is done in the PHY layer here.
> +  */
> +
> + return (max_link_clock * max_lanes);

Useless parens.


>  }
>  
>  static int
> -- 
> 2.7.4

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

Re: [Intel-gfx] [PATCH] dim: Improve the error output when rebuild-nightly fails

[Jani Nikula]

On Fri, 11 Nov 2016, Daniel Vetter  wrote:
> Joonas rightly complained that the current output is useless and just
> confuses.
>
> Cc: Joonas Lahtinen 
> Signed-off-by: Daniel Vetter 
> ---
>  dim | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/dim b/dim
> index dcdc19a9c82d..eba20509cda8 100755
> --- a/dim
> +++ b/dim
> @@ -325,9 +325,11 @@ function update_linux_next # branch next next-fixes fixes
>  
>  function check_conflicts
>  {
> - if git diff | grep '\(<<<\|===\|>>>\\)' ; then
> + if git diff | grep '\(<<<\|===\|>>>\\)' &> 
> /dev/null ; then

grep -q instead of redirecting to /dev/null?

>   if [ -n "$1" ]; then
> - echo $*
> + echoerr $*
> + echoerr "See the section \"Resolving Conflicts when 
> Rebuilding drm-intel-nightly\""
> + echoerr "in the drm-intel.rst documentation for how to 
> handle this situation."
>   fi
>   exit 1
>   fi

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

Re: [Intel-gfx] [PATCH 02/15] drm/i915/glk: Introduce Geminilake platform definition

[Ander Conselvan De Oliveira]

On Thu, 2016-11-10 at 09:03 -0800, Rodrigo Vivi wrote:
> Yep, it is probably better to merge Jani patch before while no platform
> is using that flag, but one way or another feel free to use:

Agreed. I'll send an updated version of the first two patches because of the
ddb_size that is wrong, so I can rebase while at it.

Ander

> 
> Reviewed-by: Rodrigo Vivi 
> 
> On Thu, Nov 10, 2016 at 06:40:29PM +0200, Jani Nikula wrote:
> > 
> > On Thu, 10 Nov 2016, Ander Conselvan de Oliveira  > a...@intel.com> wrote:
> > > 
> > > Geminilake is an Intel® Processor containing Intel® HD Graphics
> > > following Broxton.
> > > 
> > > Let's start by adding the platform definition. PCI IDs and plaform
> > > specific code will follow.
> > > 
> > > v2: Rebase (don't allow dev to be used with the new macro).
> > > Signed-off-by: Ander Conselvan de Oliveira  > > tel.com>
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.h | 2 ++
> > >  drivers/gpu/drm/i915/i915_pci.c | 6 ++
> > >  2 files changed, 8 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 4735b417..8a99e6e 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -667,6 +667,7 @@ struct intel_csr {
> > >   func(is_broadwell); \
> > >   func(is_skylake); \
> > >   func(is_broxton); \
> > > + func(is_geminilake); \
> > >   func(is_kabylake); \
> > >   func(is_preliminary); \
> > >   /* Keep has_* in alphabetical order */ \
> > > @@ -2756,6 +2757,7 @@ struct drm_i915_cmd_table {
> > >  #define IS_BROADWELL(dev_priv)   ((dev_priv)->info.is_broadwell)
> > >  #define IS_SKYLAKE(dev_priv) ((dev_priv)->info.is_skylake)
> > >  #define IS_BROXTON(dev_priv) ((dev_priv)->info.is_broxton)
> > > +#define IS_GEMINILAKE(dev_priv)  ((dev_priv)->info.is_geminilake)
> > >  #define IS_KABYLAKE(dev_priv)((dev_priv)->info.is_kabylake)
> > >  #define IS_MOBILE(dev_priv)  ((dev_priv)->info.is_mobile)
> > >  #define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \
> > > diff --git a/drivers/gpu/drm/i915/i915_pci.c
> > > b/drivers/gpu/drm/i915/i915_pci.c
> > > index b8cdda1..dc2ba3f 100644
> > > --- a/drivers/gpu/drm/i915/i915_pci.c
> > > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > > @@ -372,6 +372,12 @@ static const struct intel_device_info
> > > intel_broxton_info = {
> > >   GEN9_LP_FEATURES,
> > >  };
> > >  
> > > +static const struct intel_device_info intel_geminilake_info = {
> > > + .is_preliminary = 1,
> > I'd like to push [1] pretty soon now that Daniel gave his reviewed-by,
> > and we currently don't have anything in preliminary, until these patches
> > get merged. If you need to resend the series again for some other
> > reason, let me know so I'll push that first and you can rebase this
> > patch; it's rather trivial. Otherwise, I'll rebase my patch on top of
> > this series once it's been pushed. Sound okay?
> > 
> > BR
> > Jani.
> > 
> > 
> > [1] http://patchwork.freedesktop.org/patch/msgid/1477909108-18696-1-git-send
> > -email-jani.nik...@intel.com
> > 
> > 
> > > 
> > > + .is_geminilake = 1,
> > > + GEN9_LP_FEATURES,
> > > +};
> > > +
> > >  static const struct intel_device_info intel_kabylake_info = {
> > >   BDW_FEATURES,
> > >   .is_kabylake = 1,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915/glk: Reuse broxton code for geminilake

[Ander Conselvan de Oliveira]

Geminilake is mostly backwards compatible with broxton, so change most
of the IS_BROXTON() checks to IS_GEN9_LP(). Differences between the
platforms will be implemented in follow-up patches.

v2: Don't reuse broxton's path in intel_update_max_cdclk().
Don't set plane count as in broxton.

v3: Rebase

v4: Include the check intel_bios_is_port_hpd_inverted().
Commit message.

v5: Leave i915_dmc_info() out; glk's csr version != bxt's. (Rodrigo)

Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/i915_debugfs.c | 10 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c |  8 
 drivers/gpu/drm/i915/i915_irq.c | 10 +-
 drivers/gpu/drm/i915/i915_reg.h |  4 ++--
 drivers/gpu/drm/i915/intel_bios.c   |  2 +-
 drivers/gpu/drm/i915/intel_ddi.c| 10 +-
 drivers/gpu/drm/i915/intel_display.c|  8 
 drivers/gpu/drm/i915/intel_dp.c | 20 ++--
 drivers/gpu/drm/i915/intel_dpll_mgr.c   |  2 +-
 drivers/gpu/drm/i915/intel_dsi.c| 28 ++--
 drivers/gpu/drm/i915/intel_dsi_pll.c| 12 ++--
 drivers/gpu/drm/i915/intel_hdmi.c   |  6 +++---
 drivers/gpu/drm/i915/intel_i2c.c|  4 ++--
 drivers/gpu/drm/i915/intel_mocs.c   |  2 +-
 drivers/gpu/drm/i915/intel_panel.c  |  2 +-
 drivers/gpu/drm/i915/intel_pm.c |  6 +++---
 drivers/gpu/drm/i915/intel_runtime_pm.c |  6 +++---
 17 files changed, 70 insertions(+), 70 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index b681d42..5d349d6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1128,7 +1128,7 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
int max_freq;
 
rp_state_limits = I915_READ(GEN6_RP_STATE_LIMITS);
-   if (IS_BROXTON(dev_priv)) {
+   if (IS_GEN9_LP(dev_priv)) {
rp_state_cap = I915_READ(BXT_RP_STATE_CAP);
gt_perf_status = I915_READ(BXT_GT_PERF_STATUS);
} else {
@@ -1224,7 +1224,7 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
seq_printf(m, "Down threshold: %d%%\n",
   dev_priv->rps.down_threshold);
 
-   max_freq = (IS_BROXTON(dev_priv) ? rp_state_cap >> 0 :
+   max_freq = (IS_GEN9_LP(dev_priv) ? rp_state_cap >> 0 :
rp_state_cap >> 16) & 0xff;
max_freq *= (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv) ?
 GEN9_FREQ_SCALER : 1);
@@ -1237,7 +1237,7 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
seq_printf(m, "Nominal (RP1) frequency: %dMHz\n",
   intel_gpu_freq(dev_priv, max_freq));
 
-   max_freq = (IS_BROXTON(dev_priv) ? rp_state_cap >> 16 :
+   max_freq = (IS_GEN9_LP(dev_priv) ? rp_state_cap >> 16 :
rp_state_cap >> 0) & 0xff;
max_freq *= (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv) ?
 GEN9_FREQ_SCALER : 1);
@@ -5185,7 +5185,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2];
 
/* BXT has a single slice and at most 3 subslices. */
-   if (IS_BROXTON(dev_priv)) {
+   if (IS_GEN9_LP(dev_priv)) {
s_max = 1;
ss_max = 3;
}
@@ -5219,7 +5219,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
for (ss = 0; ss < ss_max; ss++) {
unsigned int eu_cnt;
 
-   if (IS_BROXTON(dev_priv)) {
+   if (IS_GEN9_LP(dev_priv)) {
if (!(s_reg[s] & (GEN9_PGCTL_SS_ACK(ss
/* skip disabled subslice */
continue;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index a5fafa3..36483a2 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -377,7 +377,7 @@ static void kunmap_page_dma(struct drm_i915_private 
*dev_priv, void *vaddr)
/* There are only few exceptions for gen >=6. chv and bxt.
 * And we are not sure about the latter so play safe for now.
 */
-   if (IS_CHERRYVIEW(dev_priv) || IS_BROXTON(dev_priv))
+   if (IS_CHERRYVIEW(dev_priv) || IS_GEN9_LP(dev_priv))
drm_clflush_virt_range(vaddr, PAGE_SIZE);
 
kunmap_atomic(vaddr);
@@ -2946,7 +2946,7 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 
size)
 * resort to an uncached mapping. The WC issue is easily caught by the
 * readback check when writing GTT PTE entries.
 */
-   if 

[Intel-gfx] ✗ Fi.CI.BAT: failure for Compact userptr object backing store allocation (rev4)

[Patchwork]

== Series Details ==

Series: Compact userptr object backing store allocation (rev4)
URL   : https://patchwork.freedesktop.org/series/15151/
State : failure

== Summary ==

Series 15151v4 Compact userptr object backing store allocation
https://patchwork.freedesktop.org/api/1.0/series/15151/revisions/4/mbox/

Test prime_vgem:
Subgroup basic-fence-flip:
pass   -> INCOMPLETE (fi-hsw-4770)
pass   -> INCOMPLETE (fi-bxt-t5700)
pass   -> INCOMPLETE (fi-skl-6700k)
pass   -> INCOMPLETE (fi-snb-2600)
pass   -> INCOMPLETE (fi-hsw-4770r)
pass   -> INCOMPLETE (fi-ivb-3770)
pass   -> INCOMPLETE (fi-bdw-5557u)
pass   -> INCOMPLETE (fi-snb-2520m)
pass   -> INCOMPLETE (fi-skl-6770hq)
pass   -> INCOMPLETE (fi-ilk-650)
Subgroup basic-fence-mmap:
pass   -> INCOMPLETE (fi-skl-6260u)
pass   -> INCOMPLETE (fi-skl-6700hq)
pass   -> INCOMPLETE (fi-bsw-n3050)
pass   -> INCOMPLETE (fi-byt-n2820)
pass   -> INCOMPLETE (fi-kbl-7200u)
Subgroup basic-gtt:
pass   -> DMESG-FAIL (fi-ivb-3520m)

fi-bdw-5557u total:226  pass:210  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:227  pass:186  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:226  pass:197  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:227  pass:194  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:226  pass:205  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:226  pass:205  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:226  pass:172  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:221  dwarn:0   dfail:1   fail:0   skip:22 
fi-ivb-3770  total:226  pass:203  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:227  pass:204  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:227  pass:212  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:227  pass:205  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:226  pass:203  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:226  pass:211  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:226  pass:193  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:226  pass:192  dwarn:0   dfail:0   fail:0   skip:33 

0ecf26a8d5fc565fca1da9d66f65863de5e00ead drm-intel-nightly: 
2016y-11m-11d-08h-21m-01s UTC integration manifest
95a3669 drm/i915: Use __sg_alloc_table_from_pages for userptr allocations
960a7ee lib/scatterlist: Introduce and export __sg_alloc_table_from_pages
4d3ae9c lib/scatterlist: Avoid potential scatterlist entry overflow
5dbb780 lib/scatterlist: Fix offset type in sg_alloc_table_from_pages

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2967/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] i915: LVDS display (or LVDS->DVI) via eDP as 2nd display

[Stefan Roese]

Hi!

I'm currently trying to enable the 2nd display on our Bay Trail
Atom E3845 SoC. This is on the Congatec SoM "conga-QA3":

http://www.congatec.com/en/products/qseven/conga-qa3.html

On this SoM, the eDP is converted to LVDS via an NXP PTN3460
and available as LVDS on the baseboard. My current setup is that
the 1st display is connected to HDMI1. This works just fine.
In the production version I would like to use a LVDS display
connected via eDP from the Bay Trail Atom. Since we don't have
this LVDS display yet, I'm currently testing with this
LVDS -> DVI adapter board:

http://www.congatec.com/de/produkte/zubehoer/conga-ldvi.html

So my current setup for this 2nd display is:

eDP -> LVDS -> DVI

which does not work.

Here my xrandr output:

Screen 0: minimum 8 x 8, current 1920 x 1200, maximum 32767 x 32767
DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
HDMI1 connected primary 1920x1200+0+0 (normal left inverted right x axis y 
axis) 597mm x 336mm
   1920x1200 59.95* 
   1920x1080 60.00  
   1600x1200 60.00  
   1680x1050 59.88  
   1280x1024 75.0260.02  
   1280x800  59.91  
   1152x864  75.00  
   1024x768  75.0360.00  
   800x600   75.0060.32  
   640x480   75.0059.94  
   720x400   70.08  
HDMI2 disconnected (normal left inverted right x axis y axis)
VGA1 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)


When I now try to add and enable DP1 (this is the correct port for
the eDP, right?), then I get these errors / warnings:

sudo xrandr -d :0 --output DP1 --addmode DP1 640x480
sudo dmesg -c
[  189.049312] [drm:vlv_pipe_set_fifo_size.isra.24] Pipe A FIFO split 511 / 511 
/ 511
[  189.049322] [drm:vlv_update_wm] Setting FIFO watermarks - A: plane=391, 
cursor=63, sprite0=0, sprite1=0, SR: plane=903, cursor=0 level=0 cxsr=1
[  189.050924] [drm:vlv_pipe_set_fifo_size.isra.24] Pipe A FIFO split 511 / 511 
/ 511
[  189.050934] [drm:vlv_update_wm] Setting FIFO watermarks - A: plane=391, 
cursor=0, sprite0=0, sprite1=0, SR: plane=903, cursor=0 level=0 cxsr=1

sudo xrandr -d :0 --output DP1 --mode 640x480 --right-of HDMI1
sudo dmesg -c
[  206.066238] [drm:vlv_pipe_set_fifo_size.isra.24] Pipe A FIFO split 511 / 511 
/ 511
[  206.066248] [drm:vlv_update_wm] Setting FIFO watermarks - A: plane=391, 
cursor=63, sprite0=0, sprite1=0, SR: plane=903, cursor=0 level=0 cxsr=1
[  206.075015] [drm:drm_mode_addfb2] [FB:47]
[  206.075208] [drm:drm_mode_setcrtc] [CRTC:26:pipe A]
[  206.075238] [drm:drm_mode_setcrtc] [CONNECTOR:41:HDMI-A-1]
[  206.076190] [drm:drm_mode_setcrtc] [CRTC:26:pipe A]
[  206.076196] [drm:drm_mode_setcrtc] [CONNECTOR:41:HDMI-A-1]
[  206.082714] [drm:vlv_pipe_set_fifo_size.isra.24] Pipe A FIFO split 511 / 511 
/ 511
[  206.082723] [drm:vlv_update_wm] Setting FIFO watermarks - A: plane=391, 
cursor=0, sprite0=0, sprite1=0, SR: plane=903, cursor=0 level=0 cxsr=1
[  206.083919] [drm:drm_mode_setcrtc] [CRTC:31:pipe B]
[  206.083927] [drm:drm_mode_setcrtc] [CONNECTOR:37:DP-1]
[  206.083946] [drm:intel_atomic_check] [CONNECTOR:37:DP-1] checking for sink 
bpp constrains
[  206.083949] [drm:intel_atomic_check] clamping display bpp (was 30) to 
default limit of 24
[  206.083952] [ cut here ]
[  206.083957] WARNING: CPU: 2 PID: 1953 at drivers/gpu/drm/i915/intel_dp.c:146 
intel_dp_max_link_bw.isra.8+0x28/0x50
[  206.083958] invalid max DP link bw val 0, using 1.62Gbps
[  206.083959] Modules linked in:
[  206.083965] CPU: 2 PID: 1953 Comm: Xorg Not tainted 4.9.0-rc4+ #5
[  206.083966] Hardware name: congatec 
conga-qeval20-qa3-e3845/conga-qeval20-qa3-e3845, BIOS 
2016.09.01-00021-ga2921da-dirty 09/30/2016
[  206.083968]  c90001de7a10 8132b928 c90001de7a60 

[  206.083973]  c90001de7a50 81059b66 00920007 
88017a48f0e0
[  206.083978]  c90001de7b50 0001 0004 
88017a48d000
[  206.083982] Call Trace:
[  206.083988]  [] dump_stack+0x4d/0x65
[  206.083992]  [] __warn+0xc6/0xe0
[  206.083995]  [] warn_slowpath_fmt+0x4a/0x50
[  206.083998]  [] intel_dp_max_link_bw.isra.8+0x28/0x50
[  206.084001]  [] intel_dp_common_rates+0x28/0xc0
[  206.084004]  [] intel_dp_compute_config+0x82/0x6e0
[  206.084008]  [] intel_atomic_check+0x2ff/0x10b0
[  206.084012]  [] drm_atomic_check_only+0x45b/0x580
[  206.084015]  [] ? 
drm_atomic_set_crtc_for_connector+0xbb/0xf0
[  206.084018]  [] drm_atomic_commit+0x12/0x50
[  206.084021]  [] drm_atomic_helper_set_config+0x7c/0xb0
[  206.084024]  [] drm_mode_set_config_internal+0x60/0x110
[  206.084027]  [] drm_mode_setcrtc+0x3bd/0x480
[  206.084031]  [] drm_ioctl+0x1e1/0x470
[  206.084034]  [] ? drm_mode_getcrtc+0x140/0x140
[  206.084039]  [] do_vfs_ioctl+0x8d/0x590
[  206.084042]  [] ? recalc_sigpending+0x15/0x40
[  206.084045]  [] SyS_ioctl+0x74/0x80
[  206.084049]  [] 

Re: [Intel-gfx] [PATCH] drm/i915: Only wait upon the execution timeline when unlocked

[Joonas Lahtinen]

On to, 2016-11-10 at 17:36 +, Chris Wilson wrote:
> In order to walk the list of all timelines, we currently require the
> struct_mutex. We are sometimes called prior to the struct_mutex being
> taken by the caller (i.e !I915_WAIT_LOCKED) in which case we can only
> trust the global execution timelines (as these are owned by the device).
> This means in the unlocked phase we can only wait upon the currently
> executing requests and not all queued.
> 
> [  175.743243] general protection fault:  [#1] SMP
> [  175.743263] Modules linked in: nls_iso8859_1 intel_rapl 
> x86_pkg_temp_thermal coretemp kvm_intel kvm irqbypass crct10dif_pclmul 
> crc32_pclmul ghash_clmulni_intel iwlwifi aesni_intel aes_x86_64 lrw 
> snd_soc_rt5640 gf128mul snd_soc_rl6231 snd_soc_core glue_helper snd_compress 
> snd_pcm_dmaengine snd_hda_codec_hdmi ablk_helper snd_hda_codec_realtek cryptd 
> snd_hda_codec_generic serio_raw cfg80211 snd_hda_intel snd_hda_codec 
> ir_lirc_codec snd_hda_core lirc_dev snd_hwdep snd_pcm lpc_ich mei_me mei 
> snd_seq_midi shpchp snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device 
> snd_timer rc_rc6_mce acpi_als nuvoton_cir kfifo_buf rc_core snd industrialio 
> snd_soc_sst_acpi soundcore snd_soc_sst_match i2c_designware_platform 8250_dw 
> i2c_designware_core dw_dmac spi_pxa2xx_platform mac_hid acpi_pad parport_pc 
> ppdev lp parport
> [  175.743509]  autofs4 i915 e1000e psmouse ptp pps_core xhci_pci ehci_pci 
> ahci xhci_hcd ehci_hcd libahci video sdhci_acpi sdhci i2c_hid hid
> [  175.743560] CPU: 2 PID: 2386 Comm: wtdg_monitor.sh Tainted: G U
>   4.9.0-rc4-nightly+ #2
> [  175.743581] Hardware name:  /NUC5i7RYB, BIOS 
> RYBDWi35.86A.0358.2016.0606.1423 06/06/2016
> [  175.743603] task: 88024509ba80 task.stack: c9007bd18000
> [  175.743618] RIP: 0010:[]  [] 
> i915_gem_wait_for_idle+0x3b/0x140 [i915]
> [  175.743660] RSP: :c9007bd1b9b8  EFLAGS: 00010297
> [  175.743674] RAX: 88024489d248 RBX:  RCX: 
> 
> [  175.743691] RDX:  RSI:  RDI: 
> 880244898000
> [  175.743708] RBP: c9007bd1b9f0 R08:  R09: 
> 0001
> [  175.743724] R10: 0028eaf42792 R11: 0001 R12: 
> dead0100
> [  175.743741] R13: dead0148 R14: c9007bd1ba5f R15: 
> 0005
> [  175.743758] FS:  7f2638330700() GS:880256d0() 
> knlGS:
> [  175.743777] CS:  0010 DS:  ES:  CR0: 80050033
> [  175.743791] CR2: 7f885c8cea40 CR3: 0002416b5000 CR4: 
> 003406e0
> [  175.743808] Stack:
> [  175.743816]  88024489d248 4509ba80 880244898000 
> 88024509ba80
> [  175.743840]  8b69 c9007bd1ba5f c9007bd1ba5e 
> c9007bd1ba28
> [  175.743863]  a01b661d   
> 880244898000
> [  175.743886] Call Trace:
> [  175.743906]  [] 
> i915_gem_shrinker_lock_uninterruptible.constprop.5+0x5d/0xc0 [i915]
> [  175.743937]  [] i915_gem_shrinker_oom+0x30/0x1b0 [i915]
> [  175.743955]  [] notifier_call_chain+0x49/0x70
> [  175.743971]  [] __blocking_notifier_call_chain+0x4d/0x70
> [  175.743988]  [] blocking_notifier_call_chain+0x16/0x20
> [  175.744005]  [] out_of_memory+0x22c/0x480
> [  175.744020]  [] __alloc_pages_slowpath+0x851/0x8ec
> [  175.744037]  [] __alloc_pages_nodemask+0x2c1/0x310
> [  175.744054]  [] alloc_pages_current+0x88/0x120
> [  175.744070]  [] __page_cache_alloc+0xb4/0xc0
> [  175.744086]  [] filemap_fault+0x29a/0x500
> [  175.744101]  [] ext4_filemap_fault+0x36/0x50
> [  175.744117]  [] __do_fault+0x6a/0xe0
> [  175.744131]  [] handle_mm_fault+0xd0e/0x1330
> [  175.744147]  [] __do_page_fault+0x23c/0x4d0
> [  175.744162]  [] do_page_fault+0x30/0x80
> [  175.744177]  [] page_fault+0x28/0x30
> [  175.744191] Code: 41 57 41 56 41 55 41 54 53 48 83 ec 10 4c 8b a7 48 52 00 
> 00 89 75 d4 48 89 45 c8 49 39 c4 74 78 4d 8d 6c 24 48 41 bf 05 00 00 00 <49> 
> 8b 5d 00 48 85 db 74 50 8b 83 20 01 00 00 85 c0 74 15 48 8b
> [  175.744320] RIP  [] i915_gem_wait_for_idle+0x3b/0x140 
> [i915]
> [  175.744351]  RSP 
> 
> Fixes: 80b204bce8f2 ("drm/i915: Enable multiple timelines")
> > Signed-off-by: Chris Wilson 
> > Cc: Joonas Lahtinen 

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] dim: Improve the error output when rebuild-nightly fails

[Daniel Vetter]

Joonas rightly complained that the current output is useless and just
confuses.

Cc: Joonas Lahtinen 
Signed-off-by: Daniel Vetter 
---
 dim | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/dim b/dim
index dcdc19a9c82d..eba20509cda8 100755
--- a/dim
+++ b/dim
@@ -325,9 +325,11 @@ function update_linux_next # branch next next-fixes fixes
 
 function check_conflicts
 {
-   if git diff | grep '\(<<<\|===\|>>>\\)' ; then
+   if git diff | grep '\(<<<\|===\|>>>\\)' &> 
/dev/null ; then
if [ -n "$1" ]; then
-   echo $*
+   echoerr $*
+   echoerr "See the section \"Resolving Conflicts when 
Rebuilding drm-intel-nightly\""
+   echoerr "in the drm-intel.rst documentation for how to 
handle this situation."
fi
exit 1
fi
-- 
2.10.2

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

Re: [Intel-gfx] [i-g-t PATCH v1 08/14] lib: Add igt_create_bo_with_dimensions

[Tomeu Vizoso]

On 11 November 2016 at 12:33, Tvrtko Ursulin
 wrote:
>
> On 11/11/2016 11:23, Tomeu Vizoso wrote:
>>
>> On 11/10/2016 05:23 PM, Tvrtko Ursulin wrote:
>>>
>>>
>>> On 10/11/2016 13:17, Tomeu Vizoso wrote:

 On 1 November 2016 at 16:44, Tvrtko Ursulin 
 wrote:
>
>
> Hi,
>
>
>
> On 02/03/16 14:00, Tomeu Vizoso wrote:
>>
>>
>> igt_create_bo_with_dimensions() is intended to abstract differences
>> between drivers in buffer object creation.
>>
>> The driver-specific ioctls will be called if the driver that is being
>> tested can satisfy the needs of the calling subtest, or it will be
>> skipped otherwise.
>>
>> Signed-off-by: Tomeu Vizoso 
>> ---
>>
>>  lib/igt_fb.c | 83
>> ++--
>>  lib/igt_fb.h |  6 +
>>  2 files changed, 65 insertions(+), 24 deletions(-)
>>
>> diff --git a/lib/igt_fb.c b/lib/igt_fb.c
>> index cd1605308308..0a3526f4e4ea 100644
>> --- a/lib/igt_fb.c
>> +++ b/lib/igt_fb.c
>> @@ -174,30 +174,66 @@ void igt_calc_fb_size(int fd, int width, int
>> height,
>> int bpp, uint64_t tiling,
>> *size_ret = size;
>>  }
>>
>> +int igt_create_bo_with_dimensions(int fd, int width, int height,
>> + uint32_t format, uint64_t modifier,
>> + unsigned stride, unsigned *size_ret,
>> + unsigned *stride_ret, bool *is_dumb)
>> +{
>> +   int bpp = igt_drm_format_to_bpp(format);
>> +   int bo;
>> +
>> +   igt_assert((modifier && stride) || (!modifier && !stride));
>> +
>> +   if (modifier) {
>> +   unsigned size, calculated_stride;
>> +
>> +   igt_calc_fb_size(fd, width, height, bpp, modifier,
>> ,
>> +_stride);
>> +   if (stride == 0)
>> +   stride = calculated_stride;
>> +
>> +   if (is_dumb)
>> +   *is_dumb = false;
>> +
>> +   if (is_i915_device(fd)) {
>> +
>> +   bo = gem_create(fd, size);
>> +   gem_set_tiling(fd, bo, modifier, stride);
>
>
>
> This is broken, gem_set_tiling does not take a fb modifier but an
> object
> tiling mode.
>
> You can demonstrate the failure if you got a Skylake system with:
>
> tests/kms_flip_tiling --r flip-changes-tiling-Yf


 Hi,

 that subtest fails occasionally here due to CRC issues, but the one
 that fails due to the tiling constant passed to gem_set_tiling is
 flip-Yf-tiled.

 Have fixed it by converting the modifier to a tiling mode, but I also
 needed to make sure that we don't pass to the kernel the Yf or Ys
 constants as the kernel doesn't know about those.

 Both fixes have been pushed already.
>>>
>>>
>>> With the two patches you pushed flip-changes-tiling-Yf is still broken
>>> due the tiling mode mismatch, not the CRC.
>>>
>>> Perhaps you tested with all three patches you posted today?
>>
>>
>> Just before pushing I tested with this:
>>
>> IGT-Version: 1.16-g050c00d (x86_64) (Linux: 4.5.5-300.fc24.x86_64 x86_64)
>>
>> So I can only think of a difference in the hw causing a different
>> codepath to execute (it's a i3-6100U), or a difference in the kernel.
>>
>> This is a remote box and I don't have yet all the infrastructure in
>> place so I could monitor the boot, nor power cycle it, so I cannot test
>> with a newer kernel yet.
>>
>> If you can confirm that we should be passing I915_TILING_NONE to
>> set_tiling when the FB has I915_FORMAT_MOD_Yf_TILED, I can fix that, but
>> I would also like to understand why the test is failing for you.
>
>
> It should definitely be I915_TILING_NONE. If you look at the i915 code,
> intel_display.c/intel_framebuffer_init will reject attempts to add a
> framebuffer where object tiling does not match the framebuffer modifier. And
> the intel_fb_modifier_to_tiling helper translates the Yf/Ys modifiers to
> NONE tiling.

Cool, will do that change now.

> So I have no idea how it could have possibly worked for you. :)

Yeah, I'm curious as well, will check in a bit.

Thanks,

Tomeu


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

Re: [Intel-gfx] [PATCH] drm/i915: Only poll DW3_A when init DDI PHY for ports B and C.

[Imre Deak]

On to, 2016-11-10 at 17:03 -0800, Rodrigo Vivi wrote:
> According to Bspec we need to
> "Poll for PORT_REF_DW3_A grc_done == 1b"
> only on ports B and C initialization sequence when
> copying rcomp from port A.
> 
> So let's follow the spec and only poll for that case
> and not on every port A initialization.
> 
> Cc: Imre Deak 
> Cc: Ander Conselvan de Oliveira 
> Signed-off-by: Rodrigo Vivi 

The current code isn't against the spec, we just wait for the
calibration to complete earlier. This way we also wait in case only
port A is enabled which is imo safer to do before a subsequent modeset
on port A. But yes, the spec suggests the HW will handle the wait for
this - only port A - case internally, so we can move the wait later to
reduce somewhat the init time:

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/intel_dpio_phy.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c 
> b/drivers/gpu/drm/i915/intel_dpio_phy.c
> index 7a8e82d..277b1aa 100644
> --- a/drivers/gpu/drm/i915/intel_dpio_phy.c
> +++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
> @@ -367,6 +367,9 @@ static void _bxt_ddi_phy_init(struct drm_i915_private 
> *dev_priv,
>  
>   if (phy_info->rcomp_phy != -1) {
>   uint32_t grc_code;
> +
> + bxt_phy_wait_grc_done(dev_priv, phy_info->rcomp_phy);
> +
>   /*
>    * PHY0 isn't connected to an RCOMP resistor so copy over
>    * the corresponding calibrated value from PHY1, and disable
> @@ -387,10 +390,6 @@ static void _bxt_ddi_phy_init(struct drm_i915_private 
> *dev_priv,
>   val = I915_READ(BXT_PHY_CTL_FAMILY(phy));
>   val |= COMMON_RESET_DIS;
>   I915_WRITE(BXT_PHY_CTL_FAMILY(phy), val);
> -
> - if (phy_info->rcomp_phy == -1)
> - bxt_phy_wait_grc_done(dev_priv, phy);
> -
>  }
>  
>  void bxt_ddi_phy_uninit(struct drm_i915_private *dev_priv, enum dpio_phy phy)
___
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: Stop skipping the final clflush back to system pages

[Joonas Lahtinen]

On to, 2016-11-10 at 15:07 +, Chris Wilson wrote:
> When we release the shmem backing storage, we make sure that the pages
> are coherent with the cpu cache. However, our clflush routine was
> skipping the flush as the object had no pages at release time. Fix this by
> explicitly flushing the sg_table we are decoupling.
> 
> Fixes: 03ac84f1830e ("drm/i915: Pass around sg_table to get_pages/put_pages 
> backend")
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] lib: substitute cxt BAN_PERIOD with BANNABLE

[Mika Kuoppala]

Context BAN_PERIOD will get depracated so subsitute it with BANNABLE
property. Make ctx param test to accept both variants for now
until kernel changes have landed, to not break BAT.

v: check against - EINVAL on get/set ban as it can return -EPERM

Cc: Chris Wilson 
Signed-off-by: Mika Kuoppala 
---
 lib/igt_gt.c  | 78 +++
 lib/ioctl_wrappers.c  | 16 +--
 lib/ioctl_wrappers.h  |  3 +-
 tests/gem_ctx_param.c |  9 --
 4 files changed, 69 insertions(+), 37 deletions(-)

diff --git a/lib/igt_gt.c b/lib/igt_gt.c
index a165932..eea9aa8 100644
--- a/lib/igt_gt.c
+++ b/lib/igt_gt.c
@@ -119,11 +119,44 @@ void igt_require_hang_ring(int fd, int ring)
igt_skip("hang injection disabled by user");
 
gem_require_ring(fd, ring);
-   gem_context_require_ban_period(fd);
+   gem_context_require_bannable(fd);
if (!igt_check_boolean_env_var("IGT_HANG_WITHOUT_RESET", false))
igt_require(has_gpu_reset(fd));
 }
 
+static unsigned igt_get_ban(int fd, unsigned ctx)
+{
+   struct local_i915_gem_context_param param;
+
+   param.param = LOCAL_CONTEXT_PARAM_BANNABLE;
+   param.value = 0;
+   param.size = 0;
+
+   if (__gem_context_get_param(fd, ) == -EINVAL) {
+   igt_assert(param.value == 0);
+   param.param = LOCAL_CONTEXT_PARAM_BAN_PERIOD;
+   gem_context_get_param(fd, );
+   }
+
+   return param.value;
+}
+
+static void igt_set_ban(int fd, unsigned ctx, unsigned ban)
+{
+   struct local_i915_gem_context_param param;
+
+   param.value = ban;
+   param.size = 0;
+   param.param = LOCAL_CONTEXT_PARAM_BANNABLE;
+
+   if(__gem_context_set_param(fd, ) == -EINVAL) {
+   igt_assert(param.value == ban);
+   param.param = LOCAL_CONTEXT_PARAM_BAN_PERIOD;
+
+   gem_context_set_param(fd, );
+   }
+}
+
 igt_hang_t igt_allow_hang(int fd, unsigned ctx, unsigned flags)
 {
struct local_i915_gem_context_param param;
@@ -131,7 +164,7 @@ igt_hang_t igt_allow_hang(int fd, unsigned ctx, unsigned 
flags)
 
if (!igt_check_boolean_env_var("IGT_HANG", true))
igt_skip("hang injection disabled by user");
-   gem_context_require_ban_period(fd);
+   gem_context_require_bannable(fd);
if (!igt_check_boolean_env_var("IGT_HANG_WITHOUT_RESET", false))
igt_require(has_gpu_reset(fd));
 
@@ -148,16 +181,9 @@ igt_hang_t igt_allow_hang(int fd, unsigned ctx, unsigned 
flags)
__gem_context_set_param(fd, );
}
 
-   param.param = LOCAL_CONTEXT_PARAM_BAN_PERIOD;
-   param.value = 0;
-   gem_context_get_param(fd, );
-   ban = param.value;
-
-   if ((flags & HANG_ALLOW_BAN) == 0) {
-   param.param = LOCAL_CONTEXT_PARAM_BAN_PERIOD;
-   param.value = 0;
-   gem_context_set_param(fd, );
-   }
+   ban = igt_get_ban(fd, ctx);
+   if ((flags & HANG_ALLOW_BAN) == 0)
+   igt_set_ban(fd, ctx, 0);
 
return (struct igt_hang){ 0, ctx, ban, flags };
 }
@@ -166,13 +192,11 @@ void igt_disallow_hang(int fd, igt_hang_t arg)
 {
struct local_i915_gem_context_param param;
 
-   param.context = arg.ctx;
-   param.size = 0;
-   param.param = LOCAL_CONTEXT_PARAM_BAN_PERIOD;
-   param.value = arg.ban;
-   gem_context_set_param(fd, );
+   igt_set_ban(fd, arg.ctx, arg.ban);
 
if ((arg.flags & HANG_ALLOW_CAPTURE) == 0) {
+   param.context = arg.ctx;
+   param.size = 0;
param.param = LOCAL_CONTEXT_PARAM_NO_ERROR_CAPTURE;
param.value = 0;
if (__gem_context_set_param(fd, ))
@@ -227,16 +251,10 @@ igt_hang_t igt_hang_ctx(int fd,
__gem_context_set_param(fd, );
}
 
-   param.param = LOCAL_CONTEXT_PARAM_BAN_PERIOD;
-   param.value = 0;
-   gem_context_get_param(fd, );
-   ban = param.value;
+   ban = igt_get_ban(fd, ctx);
 
-   if ((flags & HANG_ALLOW_BAN) == 0) {
-   param.param = LOCAL_CONTEXT_PARAM_BAN_PERIOD;
-   param.value = 0;
-   gem_context_set_param(fd, );
-   }
+   if ((flags & HANG_ALLOW_BAN) == 0)
+   igt_set_ban(fd, ctx, 0);
 
memset(, 0, sizeof(reloc));
memset(, 0, sizeof(exec));
@@ -323,13 +341,11 @@ void igt_post_hang_ring(int fd, igt_hang_t arg)
   I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
gem_close(fd, arg.handle);
 
-   param.context = arg.ctx;
-   param.size = 0;
-   param.param = LOCAL_CONTEXT_PARAM_BAN_PERIOD;
-   param.value = arg.ban;
-   gem_context_set_param(fd, );
+   igt_set_ban(fd, arg.ctx, arg.ban);
 
if ((arg.flags & HANG_ALLOW_CAPTURE) == 0) {
+   param.context = arg.ctx;
+   param.size = 0;
   

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Split out i915_vma.c (rev4)

[Joonas Lahtinen]

On pe, 2016-11-11 at 11:47 +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Split out i915_vma.c (rev4)
> URL   : https://patchwork.freedesktop.org/series/15095/
> State : warning
> 
> == Summary ==
> 
> Series 15095v4 drm/i915: Split out i915_vma.c
> https://patchwork.freedesktop.org/api/1.0/series/15095/revisions/4/mbox/
> 
> Test kms_pipe_crc_basic:
> Subgroup suspend-read-crc-pipe-a:
> pass   -> DMESG-WARN (fi-skl-6770hq)
> 

Pushed the patch, Jani already noted the Bugzilla entries.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v4 4/4] drm/i915: Use __sg_alloc_table_from_pages for userptr allocations

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

With the addition of __sg_alloc_table_from_pages we can control
the maximum coallescing size and eliminate a separate path for
allocating backing store here.

Similar to 871dfbd67d4e ("drm/i915: Allow compaction upto
SWIOTLB max segment size") this enables more compact sg lists to
be created and so has a beneficial effect on workloads with many
and/or large objects of this class.

v2:
 * Rename helper to i915_sg_segment_size and fix swiotlb override.
 * Commit message update.

v3:
 * Actually include the swiotlb override fix.

v4:
 * Regroup parameters a bit. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
Reviewed-by: Chris Wilson  (v2)
---
 drivers/gpu/drm/i915/i915_drv.h | 11 +++
 drivers/gpu/drm/i915/i915_gem.c | 15 +--
 drivers/gpu/drm/i915/i915_gem_userptr.c | 29 +++--
 3 files changed, 19 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 30777dee3f9c..38a555c9c44b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -4175,4 +4175,15 @@ int remap_io_mapping(struct vm_area_struct *vma,
__T;\
 })
 
+static inline unsigned int i915_sg_segment_size(void)
+{
+#if IS_ENABLED(CONFIG_SWIOTLB)
+   unsigned int nr_tbl = swiotlb_nr_tbl();
+
+   return nr_tbl > 0 ? nr_tbl << IO_TLB_SHIFT : UINT_MAX;
+#else
+   return UINT_MAX;
+#endif
+}
+
 #endif
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1c20edba7f2a..cb4c188a395c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2223,15 +2223,6 @@ void __i915_gem_object_put_pages(struct 
drm_i915_gem_object *obj,
mutex_unlock(>mm.lock);
 }
 
-static unsigned int swiotlb_max_size(void)
-{
-#if IS_ENABLED(CONFIG_SWIOTLB)
-   return rounddown(swiotlb_nr_tbl() << IO_TLB_SHIFT, PAGE_SIZE);
-#else
-   return 0;
-#endif
-}
-
 static void i915_sg_trim(struct sg_table *orig_st)
 {
struct sg_table new_st;
@@ -2267,7 +2258,7 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object 
*obj)
struct sgt_iter sgt_iter;
struct page *page;
unsigned long last_pfn = 0; /* suppress gcc warning */
-   unsigned int max_segment;
+   unsigned int max_segment = rounddown(i915_sg_segment_size(), PAGE_SIZE);
int ret;
gfp_t gfp;
 
@@ -2278,10 +2269,6 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object 
*obj)
GEM_BUG_ON(obj->base.read_domains & I915_GEM_GPU_DOMAINS);
GEM_BUG_ON(obj->base.write_domain & I915_GEM_GPU_DOMAINS);
 
-   max_segment = swiotlb_max_size();
-   if (!max_segment)
-   max_segment = rounddown(UINT_MAX, PAGE_SIZE);
-
st = kmalloc(sizeof(*st), GFP_KERNEL);
if (st == NULL)
return ERR_PTR(-ENOMEM);
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 64261639f547..f3fcb2d1bde9 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -390,36 +390,21 @@ struct get_pages_work {
struct task_struct *task;
 };
 
-#if IS_ENABLED(CONFIG_SWIOTLB)
-#define swiotlb_active() swiotlb_nr_tbl()
-#else
-#define swiotlb_active() 0
-#endif
-
 static int
 st_set_pages(struct sg_table **st, struct page **pvec, int num_pages)
 {
-   struct scatterlist *sg;
-   int ret, n;
+   int ret;
 
*st = kmalloc(sizeof(**st), GFP_KERNEL);
if (*st == NULL)
return -ENOMEM;
 
-   if (swiotlb_active()) {
-   ret = sg_alloc_table(*st, num_pages, GFP_KERNEL);
-   if (ret)
-   goto err;
-
-   for_each_sg((*st)->sgl, sg, num_pages, n)
-   sg_set_page(sg, pvec[n], PAGE_SIZE, 0);
-   } else {
-   ret = sg_alloc_table_from_pages(*st, pvec, num_pages,
-   0, num_pages << PAGE_SHIFT,
-   GFP_KERNEL);
-   if (ret)
-   goto err;
-   }
+   ret = __sg_alloc_table_from_pages(*st, pvec, num_pages,
+ 0, num_pages << PAGE_SHIFT,
+ i915_sg_segment_size(),
+ GFP_KERNEL);
+   if (ret)
+   goto err;
 
return 0;
 
-- 
2.7.4

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