Re: [Intel-gfx] [PATCH 2/8] drm/i915/huc: Unified css_header struct for GuC and HuC

[Jeff McGee]

On Thu, Oct 13, 2016 at 08:45:45AM -0700, Jeff McGee wrote:
> On Mon, Oct 03, 2016 at 11:42:56AM -0700, Anusha Srivatsa wrote:
> > From: Peter Antoine 
> > 
> > HuC firmware css header has almost exactly same definition as GuC
> > firmware except for the sw_version. Also, add a new member fw_type
> > into intel_uc_fw to indicate what kind of fw it is. So, the loader
> > will pull right sw_version from header.
> > 
> > v2: rebased on-top of drm-intel-nightly
> > v3: rebased on-top of drm-intel-nightly (again).
> > v4: rebased + spaces.
> > v7: rebased.
> > v8: rebased.
> > 
> > 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/intel_guc.h|  4 
> >  drivers/gpu/drm/i915/intel_guc_fwif.h   | 16 ++---
> >  drivers/gpu/drm/i915/intel_guc_loader.c | 41 
> > ++---
> >  3 files changed, 45 insertions(+), 16 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_guc.h 
> > b/drivers/gpu/drm/i915/intel_guc.h
> > index b134a41..812e4ca 100644
> > --- a/drivers/gpu/drm/i915/intel_guc.h
> > +++ b/drivers/gpu/drm/i915/intel_guc.h
> > @@ -98,6 +98,9 @@ enum intel_uc_fw_status {
> > UC_FIRMWARE_SUCCESS
> >  };
> >  
> > +#define UC_FW_TYPE_GUC 0
> > +#define UC_FW_TYPE_HUC 1
> > +
> >  /*
> >   * This structure encapsulates all the data needed during the process
> >   * of fetching, caching, and loading the firmware image into the GuC.
> > @@ -115,6 +118,7 @@ struct intel_uc_fw {
> > uint16_t major_ver_found;
> > uint16_t minor_ver_found;
> >  
> > +   uint32_t fw_type;
> > uint32_t header_size;
> > uint32_t header_offset;
> > uint32_t rsa_size;
> > diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
> > b/drivers/gpu/drm/i915/intel_guc_fwif.h
> > index e40db2d..b38b6b4 100644
> > --- a/drivers/gpu/drm/i915/intel_guc_fwif.h
> > +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
> > @@ -154,7 +154,7 @@
> >   * The GuC firmware layout looks like this:
> >   *
> >   * +---+
> > - * |guc_css_header |
> > + * | uc_css_header |
> >   * |   |
> >   * | contains major/minor version  |
> >   * +---+
> > @@ -181,9 +181,16 @@
> >   * 3. Length info of each component can be found in header, in dwords.
> >   * 4. Modulus and exponent key are not required by driver. They may not 
> > appear
> >   *in fw. So driver will load a truncated firmware in this case.
> > + *
> > + * HuC firmware layout is same as GuC firmware.
> > + *
> > + * HuC firmware css header is different. However, the only difference is 
> > where
> > + * the version information is saved. The uc_css_header is unified to 
> > support
> > + * both. Driver should get HuC version from uc_css_header.huc_sw_version, 
> > while
> > + * uc_css_header.guc_sw_version for GuC.
> >   */
> >  
> > -struct guc_css_header {
> > +struct uc_css_header {
> > uint32_t module_type;
> > /* header_size includes all non-uCode bits, including css_header, rsa
> >  * key, modulus key and exponent data. */
> > @@ -214,7 +221,10 @@ struct guc_css_header {
> >  
> > char username[8];
> > char buildnumber[12];
> > -   uint32_t device_id;
> > +   union {
> > +   uint32_t device_id;
> > +   uint32_t huc_sw_version;
> > +   };
> > uint32_t guc_sw_version;
> > uint32_t prod_preprod_fw;
> > uint32_t reserved[12];
> 
> I propose renaming the device_id field in this union to
> 'guc_client_branch_version'. GuC uses this position to store a client
> version and branch version. I'm not sure where the 'device_id' term came
> from. We don't reference this currently but may need to in the future
> so might as well name it properly. At the very least we should probably
> make it guc_device_id, to help indicate that it applies to guc fw only.
> 
> In that same vein, can we make guc_sw_version into a union as below to
> reinforce the difference to huc?
> 
>   union {
>   uint32_t guc_sw_version;
>   uint32_t huc_reserved;
>   };
> 
> Jeff
> 

One correction. The branch version is considered the "major" and the
client version the "minor", so the better name for this field is
'guc_branch_client_version'.

> > diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
> > b/drivers/gpu/drm/i915/intel_guc_loader.c
> > index 493295d..0b863a1 100644
> > --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> > +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> > @@ -586,7 +586,7 @@ void intel_uc_fw_fetch(struct drm_device *dev, struct 
> > intel_uc_fw *uc_fw)
> > struct pci_dev *pdev = dev->pdev;
> > struct drm_i915_gem_object *obj;
> > 

Re: [Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2

[Yang, Libin]

Tested-by: Libin Yang 

Regards,
Libin


> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Dhinakaran Pandiyan
> Sent: Friday, October 14, 2016 2:04 AM
> To: intel-...@freedesktop.org
> Cc: Nikula, Jani ; Kp, Jeeja ;
> Libin Yang ; Pandiyan, Dhinakaran
> 
> Subject: [Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is
> enabled with 4 lanes and HBR2
> 
> According to BSpec, cdclk has to be not less than 432 MHz with DP audio
> enabled, port width x4, and link rate HBR2 (5.4 GHz)
> 
> Having a lower cdclk triggers pipe underruns, which then lead to displays
> continuously cycling off and on. This is essential for DP MST audio as the 
> link
> is trained at HBR2 and 4 lanes by default.
> 
> This should fix https://bugs.freedesktop.org/show_bug.cgi?id=97907
> 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 47
> +---
>  1 file changed, 43 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index cfcb03f..6a05183 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6603,14 +6603,43 @@ static int valleyview_modeset_calc_cdclk(struct
> drm_atomic_state *state)
>   return 0;
>  }
> 
> +static bool cdclk_min_for_dp_audio(struct drm_atomic_state *state) {
> +
> + struct drm_crtc_state *crtc_state;
> + struct drm_crtc *crtc;
> + int i;
> +
> + /* BSpec says "Do not use DisplayPort with CDCLK less than 432 MHz,
> +  * audio enabled, port width x4, and link rate HBR2 (5.4 GHz), or else
> +  * there may be audio corruption or screen corruption."
> +  */
> +
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + struct intel_crtc_state *pipe_config =
> + to_intel_crtc_state(crtc_state);
> +
> + return (intel_crtc_has_dp_encoder(pipe_config) &&
> + pipe_config->has_audio &&
> + pipe_config->port_clock == 54 &&
> + pipe_config->lane_count == 4);
> + }
> +
> + return false;
> +}
> +
>  static int bxt_modeset_calc_cdclk(struct drm_atomic_state *state)  {
>   int max_pixclk = ilk_max_pixel_rate(state);
> + int cdclk, min_cdclk = 0;
>   struct intel_atomic_state *intel_state =
>   to_intel_atomic_state(state);
> 
> - intel_state->cdclk = intel_state->dev_cdclk =
> - bxt_calc_cdclk(max_pixclk);
> + if (cdclk_min_for_dp_audio(state))
> + min_cdclk = bxt_calc_cdclk(432000);
> +
> + cdclk = bxt_calc_cdclk(max_pixclk);
> + intel_state->cdclk = intel_state->dev_cdclk = max(min_cdclk, cdclk);
> 
>   if (!intel_state->active_crtcs)
>   intel_state->dev_cdclk = bxt_calc_cdclk(0); @@ -10374,7
> +10403,10 @@ static int broadwell_modeset_calc_cdclk(struct
> drm_atomic_state *state)
>   struct drm_i915_private *dev_priv = to_i915(state->dev);
>   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
>   int max_pixclk = ilk_max_pixel_rate(state);
> - int cdclk;
> + int cdclk, min_cdclk = 0;
> +
> + if (cdclk_min_for_dp_audio(state))
> + min_cdclk = broadwell_calc_cdclk(432000);
> 
>   /*
>* FIXME should also account for plane ratio @@ -10382,6 +10414,8
> @@ static int broadwell_modeset_calc_cdclk(struct drm_atomic_state *state)
>*/
>   cdclk = broadwell_calc_cdclk(max_pixclk);
> 
> + cdclk = max(min_cdclk, cdclk);
> +
>   if (cdclk > dev_priv->max_cdclk_freq) {
>   DRM_DEBUG_KMS("requested cdclk (%d kHz) exceeds max
> (%d kHz)\n",
> cdclk, dev_priv->max_cdclk_freq); @@ -10411,7
> +10445,10 @@ static int skl_modeset_calc_cdclk(struct drm_atomic_state
> *state)
>   struct drm_i915_private *dev_priv = to_i915(state->dev);
>   const int max_pixclk = ilk_max_pixel_rate(state);
>   int vco = intel_state->cdclk_pll_vco;
> - int cdclk;
> + int cdclk, min_cdclk = 0;
> +
> + if (cdclk_min_for_dp_audio(state))
> + min_cdclk = skl_calc_cdclk(432000, vco);
> 
>   /*
>* FIXME should also account for plane ratio @@ -10419,6 +10456,8
> @@ static int skl_modeset_calc_cdclk(struct drm_atomic_state *state)
>*/
>   cdclk = skl_calc_cdclk(max_pixclk, vco);
> 
> + cdclk = max(min_cdclk, cdclk);
> +
>   /*
>* FIXME move the cdclk caclulation to
>* compute_config() so we can fail gracegully.
> --
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

[Jeff McGee]

On Mon, Oct 03, 2016 at 11:43:02AM -0700, Anusha Srivatsa wrote:
> From: Peter Antoine 
> 
> This patch will allow for getparams to return the status of the HuC.
> As the HuC has to be validated by the GuC this patch uses the validated
> status to show when the HuC is loaded and ready for use. You cannot use
> the loaded status as with the GuC as the HuC is verified after it is
> loaded and is not usable until it is verified.
> 
> v2: removed the forewakes as the registers are already force-woken.
>  (T.Ursulin)
> v4: rebased.
> v5: rebased.
> 
> Tested-by: Xiang Haihao 
> Signed-off-by: Anusha Srivatsa 
> Signed-off-by: Peter Antoine 
> ---
>  drivers/gpu/drm/i915/i915_drv.c |  4 
>  drivers/gpu/drm/i915/intel_huc.h|  2 +-
>  drivers/gpu/drm/i915/intel_huc_loader.c | 14 ++
>  include/uapi/drm/i915_drm.h |  1 +
>  4 files changed, 20 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index ff1c18d..0d7b290 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -49,6 +49,7 @@
>  #include "i915_trace.h"
>  #include "i915_vgpu.h"
>  #include "intel_drv.h"
> +#include "intel_huc.h"
>  #include "intel_guc.h"
>  
>  static struct drm_driver driver;
> @@ -343,6 +344,9 @@ static int i915_getparam(struct drm_device *dev, void 
> *data,
>   case I915_PARAM_HAS_GUC:
>   value = intel_is_guc_valid(dev_priv);
>   break;
> + case I915_PARAM_HAS_HUC:
> + value = intel_is_huc_valid(dev_priv);
> + break;
>   default:
>   DRM_DEBUG("Unknown parameter %d\n", param->param);
>   return -EINVAL;
> diff --git a/drivers/gpu/drm/i915/intel_huc.h 
> b/drivers/gpu/drm/i915/intel_huc.h
> index 946caa7..5eac625 100644
> --- a/drivers/gpu/drm/i915/intel_huc.h
> +++ b/drivers/gpu/drm/i915/intel_huc.h
> @@ -40,5 +40,5 @@ extern void intel_huc_init(struct drm_device *dev);
>  extern int intel_huc_load(struct drm_device *dev);
>  extern void intel_huc_auth(struct drm_device *dev);
>  extern void intel_huc_fini(struct drm_device *dev);
> -
> +extern int intel_is_huc_valid(struct drm_i915_private *dev_priv);
>  #endif
> diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c 
> b/drivers/gpu/drm/i915/intel_huc_loader.c
> index 87a6948..d574183 100644
> --- a/drivers/gpu/drm/i915/intel_huc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_huc_loader.c
> @@ -273,3 +273,17 @@ void intel_huc_fini(struct drm_device *dev)
>  
>   huc_fw->fetch_status = UC_FIRMWARE_NONE;
>  }
> +
> +/**
> + * intel_is_huc_valid() - Check to see if the HuC is fully loaded.
> + * @dev_priv:drm device to check.
> + *
> + * This function will return true if the guc has been loaded and
> + * has valid firmware. The simplest way of doing this is to check
> + * if the HuC has been validated, if so it must have been loaded.
> + */
> +int intel_is_huc_valid(struct drm_i915_private *dev_priv)
I'm still unclear on the 'intel' vs. 'i915' prefix usage. But it seems
that intel prefixed functions accept drm_device instead of drm_i915_private.

Also, need to see the userspace usage of this new GETPARAM.

> +{
> + return ((I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED) != 0);
> +}
> +
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index 629fb5e..d236520 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -389,6 +389,7 @@ typedef struct drm_i915_irq_wait {
>  #define I915_PARAM_MIN_EU_IN_POOL 39
>  #define I915_PARAM_MMAP_GTT_VERSION   40
>  #define I915_PARAM_HAS_GUC41
> +#define I915_PARAM_HAS_HUC42
>  
>  typedef struct drm_i915_getparam {
>   __s32 param;
> -- 
> 2.7.4
> 
> ___
> 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 7/8] drm/i915/get_params: Add GuC status to getparams

[Jeff McGee]

On Fri, Oct 07, 2016 at 09:11:03AM +0200, Daniel Vetter wrote:
> On Wed, Oct 05, 2016 at 01:51:14PM -0700, Rodrigo Vivi wrote:
> > 
> > 
> > Reviewed-by: Rodrigo Vivi 
> 
> This is new uabi. Where's the userspace?
> 
> Checking this is part of the review.
> -Daniel
> 
I'm not sure that GuC status is strictly needed by userspace. No
direct dependencies that I am aware of. HuC status is needed and that
is the subsequent patch.
-Jeff

> > 
> > On Mon, Oct 03, 2016 at 11:43:01AM -0700, Anusha Srivatsa wrote:
> > > From: Peter Antoine 
> > > 
> > > This patch returns the GuC status to the caller. It is used so
> > > that the userspace knows if the GuC has been loaded.
> > > 
> > > v4: rebase.
> > > v5: rebased.
> > > 
> > > Signed-off-by: Anusha Srivatsa 
> > > Signed-off-by: Peter Antoine 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.c |  4 
> > >  drivers/gpu/drm/i915/intel_guc.h|  2 +-
> > >  drivers/gpu/drm/i915/intel_guc_loader.c | 18 ++
> > >  include/uapi/drm/i915_drm.h |  1 +
> > >  4 files changed, 24 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > > b/drivers/gpu/drm/i915/i915_drv.c
> > > index 7af7bd6..ff1c18d 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > @@ -49,6 +49,7 @@
> > >  #include "i915_trace.h"
> > >  #include "i915_vgpu.h"
> > >  #include "intel_drv.h"
> > > +#include "intel_guc.h"
> > >  
> > >  static struct drm_driver driver;
> > >  
> > > @@ -339,6 +340,9 @@ static int i915_getparam(struct drm_device *dev, void 
> > > *data,
> > >*/
> > >   value = 1;
> > >   break;
> > > + case I915_PARAM_HAS_GUC:
> > > + value = intel_is_guc_valid(dev_priv);
> > > + break;
> > >   default:
> > >   DRM_DEBUG("Unknown parameter %d\n", param->param);
> > >   return -EINVAL;
> > > diff --git a/drivers/gpu/drm/i915/intel_guc.h 
> > > b/drivers/gpu/drm/i915/intel_guc.h
> > > index af76ffe..3a7fa7e 100644
> > > --- a/drivers/gpu/drm/i915/intel_guc.h
> > > +++ b/drivers/gpu/drm/i915/intel_guc.h
> > > @@ -168,5 +168,5 @@ int i915_guc_submission_enable(struct 
> > > drm_i915_private *dev_priv);
> > >  int i915_guc_wq_reserve(struct drm_i915_gem_request *rq);
> > >  void i915_guc_submission_disable(struct drm_i915_private *dev_priv);
> > >  void i915_guc_submission_fini(struct drm_i915_private *dev_priv);
> > > -
> > > +int intel_is_guc_valid(struct drm_i915_private *dev_priv);
> > >  #endif
> > > diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
> > > b/drivers/gpu/drm/i915/intel_guc_loader.c
> > > index 31a2b0a..5d2a703 100644
> > > --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> > > +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> > > @@ -801,3 +801,21 @@ void intel_guc_fini(struct drm_device *dev)
> > >  
> > >   guc_fw->fetch_status = UC_FIRMWARE_NONE;
> > >  }
> > > +
> > > +/**
> > > + * intel_is_guc_valid() - Check to see if the GuC is fully loaded.
> > > + * @dev: drm dedvice to check.
> > > + *
> > > + * This function will return true if the guc has been loaded and
> > > + * has valid firmware.
> > > + */
> > > +int intel_is_guc_valid(struct drm_i915_private *dev_priv)
> > > +{
> > > + struct intel_uc_fw *guc_fw = _priv->guc.guc_fw;
> > > +
> > > + if (guc_fw->load_status == UC_FIRMWARE_SUCCESS)
> > > + return 1;
> > > + else
> > > + return 0;
> > > +}
> > > +
> > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > > index 03725fe..629fb5e 100644
> > > --- a/include/uapi/drm/i915_drm.h
> > > +++ b/include/uapi/drm/i915_drm.h
> > > @@ -388,6 +388,7 @@ typedef struct drm_i915_irq_wait {
> > >  #define I915_PARAM_HAS_POOLED_EU  38
> > >  #define I915_PARAM_MIN_EU_IN_POOL 39
> > >  #define I915_PARAM_MMAP_GTT_VERSION   40
> > > +#define I915_PARAM_HAS_GUC41
> > >  
> > >  typedef struct drm_i915_getparam {
> > >   __s32 param;
> > > -- 
> > > 2.7.4
> > > 
> > > ___
> > > 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
> 
> -- 
> 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 mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/8] drm/i915/huc: Add BXT HuC Loading Support

[Jeff McGee]

On Mon, Oct 03, 2016 at 11:43:00AM -0700, Anusha Srivatsa wrote:
> From: Peter Antoine 
> 
> This patch adds the HuC Loading for the BXT.
> Version 1.7 of the HuC firmware.
> 
> v2: rebased.
> v3: rebased.
> changed file name to match the install package format.
> v7: rebased.
> v8: rebased.
> 
> Signed-off-by: Anusha Srivatsa 
> Signed-off-by: Peter Antoine 
> Reviewed-by: David Gordon 
> ---
>  drivers/gpu/drm/i915/intel_huc_loader.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c 
> b/drivers/gpu/drm/i915/intel_huc_loader.c
> index 1aaff67..87a6948 100644
> --- a/drivers/gpu/drm/i915/intel_huc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_huc_loader.c
> @@ -50,6 +50,9 @@
>  #define I915_SKL_HUC_UCODE "i915/skl_huc_ver01_07_1398.bin"
>  MODULE_FIRMWARE(I915_SKL_HUC_UCODE);
>  
> +#define I915_BXT_HUC_UCODE "i915/bxt_huc_ver01_07_1398.bin"
> +MODULE_FIRMWARE(I915_BXT_HUC_UCODE);
> +
This will need updating if the newer firmware version/name macros in
intel_guc_loader.c are adopted.

>  /**
>   * intel_huc_load_ucode() - DMA's the firmware
>   * @dev: the drm device
> @@ -158,6 +161,10 @@ void intel_huc_init(struct drm_device *dev)
>   fw_path = I915_SKL_HUC_UCODE;
>   huc_fw->major_ver_wanted = 1;
>   huc_fw->minor_ver_wanted = 7;
> + } else if (IS_BROXTON(dev_priv)) {
> + fw_path = I915_BXT_HUC_UCODE;
> + huc_fw->major_ver_wanted = 1;
> + huc_fw->minor_ver_wanted = 7;
>   }
>  
>   if (fw_path == NULL)
> -- 
> 2.7.4
> 
> ___
> 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 5/8] drm/i915/huc: Support HuC authentication

[Jeff McGee]

On Mon, Oct 03, 2016 at 11:42:59AM -0700, Anusha Srivatsa wrote:
> From: Peter Antoine 
> 
> The HuC authentication is done by host2guc call. The HuC RSA keys
> are sent to GuC for authentication.
> 
> v2: rebased on top of drm-intel-nightly.
> changed name format and upped version 1.7.
> v3: rebased on top of drm-intel-nightly.
> v4: changed wait_for_automic to wait_for
> v5: rebased.
> v7: rebased.
> v8: rebased.
> 
> 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/i915_guc_submission.c | 65 
> ++
>  drivers/gpu/drm/i915/intel_guc_fwif.h  |  1 +
>  drivers/gpu/drm/i915/intel_guc_loader.c|  2 +
>  3 files changed, 68 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
> b/drivers/gpu/drm/i915/i915_guc_submission.c
> index 4b92943..984b529 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include "i915_drv.h"
>  #include "intel_guc.h"
> +#include "intel_huc.h"
>  
>  /**
>   * DOC: GuC-based command submission
> @@ -1110,3 +,67 @@ int intel_guc_resume(struct drm_device *dev)
>  
>   return host2guc_action(guc, data, ARRAY_SIZE(data));
>  }
> +
> +/**
> + * intel_huc_auth() - authenticate ucode
> + * @dev: the drm device
> + *
> + * Triggers a HuC fw authentication request to the GuC via host-2-guc
> + * interface.
> + */
> +void intel_huc_auth(struct drm_device *dev)
This function is primarily a guc action and must be in i915_guc_submission.c
to use the static host2guc call. I think it would be clearer to name the
function intel_guc_auth_huc and place the prototype in intel_guc.h instead
of intel_huc.h where other wrappers of host2guc are prototyped.

> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct intel_guc *guc = _priv->guc;
> + struct intel_huc *huc = _priv->huc;
> + struct i915_vma *vma;
> + int ret;
> + u32 data[2];
> +
> + /* Bypass the case where there is no HuC firmware */
> + if (huc->huc_fw.fetch_status == UC_FIRMWARE_NONE ||
> + huc->huc_fw.load_status == UC_FIRMWARE_NONE)
> + return;
> +
> + if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS) {
> + DRM_ERROR("HuC: GuC fw wasn't loaded. Can't authenticate");
> + return;
> + }
> +
> + if (huc->huc_fw.load_status != UC_FIRMWARE_SUCCESS) {
> + DRM_ERROR("HuC: fw wasn't loaded. Nothing to authenticate");
> + return;
> + }
> +
> + vma = i915_gem_object_ggtt_pin(huc->huc_fw.uc_fw_obj, NULL, 0, 0, 0);
> + if (IS_ERR(vma)) {
> + DRM_DEBUG_DRIVER("pin failed %d\n", (int)PTR_ERR(vma));
> + return;
> + }
> +
> +
> + /* Invalidate GuC TLB to let GuC take the latest updates to GTT. */
> + I915_WRITE(GEN8_GTCR, GEN8_GTCR_INVALIDATE);
> +
> + /* Specify auth action and where public signature is. It's stored
> +  * at the beginning of the gem object, before the fw bits
Second sentence is wrong. RSA offset is after header and ucode. Please
just remove this sentence.

> +  */
> + data[0] = HOST2GUC_ACTION_AUTHENTICATE_HUC;
> + data[1] = i915_ggtt_offset(vma) + huc->huc_fw.rsa_offset;
> +
> + ret = host2guc_action(guc, data, ARRAY_SIZE(data));
> + if (ret) {
> + DRM_ERROR("HuC: GuC did not ack Auth request\n");
> + goto out;
> + }
> +
> + /* Check authentication status, it should be done by now */
> + ret = wait_for((I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED) > 0, 50);
> + if (ret) {
> + DRM_ERROR("HuC: Authentication failed\n");
> + goto out;
> + }
> +
> +out:
> + i915_vma_unpin(vma);
> +}
> diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
> b/drivers/gpu/drm/i915/intel_guc_fwif.h
> index b38b6b4..57e6466 100644
> --- a/drivers/gpu/drm/i915/intel_guc_fwif.h
> +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
> @@ -438,6 +438,7 @@ enum host2guc_action {
>   HOST2GUC_ACTION_ENTER_S_STATE = 0x501,
>   HOST2GUC_ACTION_EXIT_S_STATE = 0x502,
>   HOST2GUC_ACTION_SLPC_REQUEST = 0x3003,
> + HOST2GUC_ACTION_AUTHENTICATE_HUC = 0x4000,
>   HOST2GUC_ACTION_LIMIT
>  };
>  
> diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
> b/drivers/gpu/drm/i915/intel_guc_loader.c
> index 0d214b4..31a2b0a 100644
> --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> @@ -527,6 +527,8 @@ int intel_guc_setup(struct drm_device *dev)
>   intel_uc_fw_status_repr(guc_fw->fetch_status),
>   intel_uc_fw_status_repr(guc_fw->load_status));
>  
> + intel_huc_auth(dev);
> +
>   if 

Re: [Intel-gfx] [PATCH v2 05/10] drm/i915/gen9: Get rid of redundant watermark values

[Lyude Paul]

Your is SAGV related, and when we don't make the SAGV happy people's
machines usually hang. So I'm definitely for your patches getting
merged first


On Thu, 2016-10-13 at 17:07 -0300, Paulo Zanoni wrote:
> Em Qui, 2016-10-13 às 17:04 -0300, Paulo Zanoni escreveu:
> > 
> > Em Qui, 2016-10-13 às 15:39 +0200, Maarten Lankhorst escreveu:
> > > 
> > > 
> > > Op 08-10-16 om 02:11 schreef Lyude:
> > > > 
> > > > 
> > > > 
> > > > Now that we've make skl_wm_levels make a little more sense, we
> > > > can
> > > > remove all of the redundant wm information. Up until now we'd
> > > > been
> > > > storing two copies of all of the skl watermarks: one being the
> > > > skl_pipe_wm structs, the other being the global wm struct in
> > > > drm_i915_private containing the raw register values. This is
> > > > confusing
> > > > and problematic, since it means we're prone to accidentally
> > > > letting
> > > > the
> > > > two copies go out of sync. So, get rid of all of the functions
> > > > responsible for computing the register values and just use a
> > > > single
> > > > helper, skl_write_wm_level(), to convert and write the new
> > > > watermarks on
> > > > the fly.
> > > > 
> > > > Changes since v1:
> > > > - Fixup skl_write_wm_level()
> > > > - Fixup skl_wm_level_from_reg_val()
> > > > - Don't forget to copy *active to intel_crtc->wm.active.skl
> > > > 
> > > > Signed-off-by: Lyude 
> > > > Reviewed-by: Maarten Lankhorst  > > > om
> > > > > 
> > > > > 
> > > > Cc: Ville Syrjälä 
> > > > Cc: Paulo Zanoni 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.h  |   2 -
> > > >  drivers/gpu/drm/i915/intel_display.c |  14 ++-
> > > >  drivers/gpu/drm/i915/intel_drv.h |   6 +-
> > > >  drivers/gpu/drm/i915/intel_pm.c  | 204 ---
> > > > --
> > > > --
> > > > 
> > > >  drivers/gpu/drm/i915/intel_sprite.c  |   8 +-
> > > >  5 files changed, 90 insertions(+), 144 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index 0287c93..76583b2 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -1644,8 +1644,6 @@ struct skl_ddb_allocation {
> > > >  struct skl_wm_values {
> > > >     unsigned dirty_pipes;
> > > >     struct skl_ddb_allocation ddb;
> > > > -   uint32_t plane[I915_MAX_PIPES][I915_MAX_PLANES][8];
> > > > -   uint32_t plane_trans[I915_MAX_PIPES][I915_MAX_PLANES];
> > > >  };
> > > >  
> > > >  struct skl_wm_level {
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > index a71d05a..39400a0 100644
> > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > @@ -3378,6 +3378,8 @@ static void
> > > > skylake_update_primary_plane(struct drm_plane *plane,
> > > >     struct intel_crtc *intel_crtc =
> > > > to_intel_crtc(crtc_state-
> > > > > 
> > > > > 
> > > > > base.crtc);
> > > >     struct drm_framebuffer *fb = plane_state->base.fb;
> > > >     const struct skl_wm_values *wm = _priv-
> > > > > 
> > > > > 
> > > > > wm.skl_results;
> > > > +   const struct skl_plane_wm *p_wm =
> > > > +   _state->wm.skl.optimal.planes[0];
> > > >     int pipe = intel_crtc->pipe;
> > > >     u32 plane_ctl;
> > > >     unsigned int rotation = plane_state->base.rotation;
> > > > @@ -3414,7 +3416,7 @@ static void
> > > > skylake_update_primary_plane(struct drm_plane *plane,
> > > >     intel_crtc->adjusted_y = src_y;
> > > >  
> > > >     if (wm->dirty_pipes & drm_crtc_mask(_crtc-
> > > > >base))
> > > > -   skl_write_plane_wm(intel_crtc, wm, 0);
> > > > +   skl_write_plane_wm(intel_crtc, p_wm, >ddb,
> > > > 0);
> > > >  
> > > >     I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);
> > > >     I915_WRITE(PLANE_OFFSET(pipe, 0), (src_y << 16) |
> > > > src_x);
> > > > @@ -3448,6 +3450,8 @@ static void
> > > > skylake_disable_primary_plane(struct drm_plane *primary,
> > > >     struct drm_device *dev = crtc->dev;
> > > >     struct drm_i915_private *dev_priv = to_i915(dev);
> > > >     struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > > > +   struct intel_crtc_state *cstate =
> > > > to_intel_crtc_state(crtc->state);
> > > > +   const struct skl_plane_wm *p_wm = 
> > > > > 
> > > > > 
> > > > > wm.skl.optimal.planes[0];
> > > >     int pipe = intel_crtc->pipe;
> > > >  
> > > >     /*
> > > > @@ -3455,7 +3459,8 @@ static void
> > > > skylake_disable_primary_plane(struct drm_plane *primary,
> > > >      * plane's visiblity isn't actually changing neither
> > > > is
> > > > its watermarks.
> > > >      */
> > > >     if (!crtc->primary->state->visible)
> > > > -   skl_write_plane_wm(intel_crtc, _priv-
> > > > > 
> > > > > 

Re: [Intel-gfx] [PATCH 09/10] drm/i915/gen9: Actually verify WM levels in verify_wm_state()

[Paulo Zanoni]

Em Qui, 2016-10-13 às 18:15 -0300, Paulo Zanoni escreveu:
> Em Sex, 2016-10-07 às 20:11 -0400, Lyude escreveu:
> > 
> > Thanks to Paulo Zanoni for indirectly pointing this out.
> > 
> > Looks like we never actually added any code for checking whether or
> > not
> > we actually wrote watermark levels properly. Let's fix that.
> 
> Thanks for doing this!
> 
> Reviewed-by: Paulo Zanoni 
> 
> A check that would have prevented one of the bugs I solved would be
> "if
> plane is active, then level 0 must be enabled, and DDB partitioning
> size must be non-zero". I'll put this in my TODO list, but I won't
> complain if somebody does it first :)

Also, bikeshed: use %u instead of %d for the unsigned types
(plane_res_b, plane_res_l).

> 
> > 
> > 
> > Signed-off-by: Lyude 
> > Cc: Maarten Lankhorst 
> > Cc: Ville Syrjälä 
> > Cc: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 100
> > +--
> >  1 file changed, 84 insertions(+), 16 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 39400a0..2c682bc 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -13444,30 +13444,66 @@ static void verify_wm_state(struct
> > drm_crtc
> > *crtc,
> >     struct drm_device *dev = crtc->dev;
> >     struct drm_i915_private *dev_priv = to_i915(dev);
> >     struct skl_ddb_allocation hw_ddb, *sw_ddb;
> > -   struct skl_ddb_entry *hw_entry, *sw_entry;
> > +   struct skl_pipe_wm hw_wm, *sw_wm;
> > +   struct skl_plane_wm *hw_plane_wm, *sw_plane_wm;
> > +   struct skl_ddb_entry *hw_ddb_entry, *sw_ddb_entry;
> >     struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> >     const enum pipe pipe = intel_crtc->pipe;
> > -   int plane;
> > +   int plane, level, max_level = ilk_wm_max_level(dev);
> >  
> >     if (INTEL_INFO(dev)->gen < 9 || !new_state->active)
> >     return;
> >  
> > +   skl_pipe_wm_get_hw_state(crtc, _wm);
> > +   sw_wm = _crtc->wm.active.skl;
> > +
> >     skl_ddb_get_hw_state(dev_priv, _ddb);
> >     sw_ddb = _priv->wm.skl_hw.ddb;
> >  
> >     /* planes */
> >     for_each_plane(dev_priv, pipe, plane) {
> > -   hw_entry = _ddb.plane[pipe][plane];
> > -   sw_entry = _ddb->plane[pipe][plane];
> > +   hw_plane_wm = _wm.planes[plane];
> > +   sw_plane_wm = _wm->planes[plane];
> >  
> > -   if (skl_ddb_entry_equal(hw_entry, sw_entry))
> > -   continue;
> > +   /* Watermarks */
> > +   for (level = 0; level <= max_level; level++) {
> > +   if (skl_wm_level_equals(_plane_wm-
> > > 
> > > wm[level],
> > +   _plane_wm-
> > > 
> > > wm[level]))
> > +   continue;
> > +
> > +   DRM_ERROR("mismatch in WM pipe %c plane %d
> > level %d (expected e=%d b=%d l=%d, got e=%d b=%d l=%d)\n",
> > +     pipe_name(pipe), plane + 1,
> > level,
> > +     sw_plane_wm->wm[level].plane_en,
> > +     sw_plane_wm-
> > > 
> > > wm[level].plane_res_b,
> > +     sw_plane_wm-
> > > 
> > > wm[level].plane_res_l,
> > +     hw_plane_wm->wm[level].plane_en,
> > +     hw_plane_wm-
> > > 
> > > wm[level].plane_res_b,
> > +     hw_plane_wm-
> > > 
> > > wm[level].plane_res_l);
> > +   }
> >  
> > -   DRM_ERROR("mismatch in DDB state pipe %c plane %d
> > "
> > -     "(expected (%u,%u), found (%u,%u))\n",
> > -     pipe_name(pipe), plane + 1,
> > -     sw_entry->start, sw_entry->end,
> > -     hw_entry->start, hw_entry->end);
> > +   if (!skl_wm_level_equals(_plane_wm->trans_wm,
> > +    _plane_wm->trans_wm))
> > {
> > +   DRM_ERROR("mismatch in trans WM pipe %c
> > plane %d (expected e=%d b=%d l=%d, got e=%d b=%d l=%d)\n",
> > +     pipe_name(pipe), plane + 1,
> > +     sw_plane_wm->trans_wm.plane_en,
> > +     sw_plane_wm-
> > >trans_wm.plane_res_b,
> > +     sw_plane_wm-
> > >trans_wm.plane_res_l,
> > +     hw_plane_wm->trans_wm.plane_en,
> > +     hw_plane_wm-
> > >trans_wm.plane_res_b,
> > +     hw_plane_wm-
> > > 
> > > trans_wm.plane_res_l);
> > +   }
> > +
> > +   /* DDB */
> > +   hw_ddb_entry = _ddb.plane[pipe][plane];
> > +   sw_ddb_entry = _ddb->plane[pipe][plane];
> > +
> > +   if (!skl_ddb_entry_equal(hw_ddb_entry,
> > sw_ddb_entry)) {
> > +   

Re: [Intel-gfx] [PATCH 10/10] drm/i915/gen9: Don't wrap strings in verify_wm_state()

[Paulo Zanoni]

Em Sex, 2016-10-07 às 20:11 -0400, Lyude escreveu:

Bikesheding: it would be nice to write a commit message explaining why,
even if the message just tells the user to read
Documentation/CodingStyle.

Reviewed-by: Paulo Zanoni 

> Signed-off-by: Lyude 
> Cc: Maarten Lankhorst 
> Cc: Ville Syrjälä 
> Cc: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 2c682bc..6191baf 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13498,8 +13498,7 @@ static void verify_wm_state(struct drm_crtc
> *crtc,
>   sw_ddb_entry = _ddb->plane[pipe][plane];
>  
>   if (!skl_ddb_entry_equal(hw_ddb_entry,
> sw_ddb_entry)) {
> - DRM_ERROR("mismatch in DDB state pipe %c
> plane %d "
> -   "(expected (%u,%u), found
> (%u,%u))\n",
> + DRM_ERROR("mismatch in DDB state pipe %c
> plane %d (expected (%u,%u), found (%u,%u))\n",
>     pipe_name(pipe), plane + 1,
>     sw_ddb_entry->start, sw_ddb_entry-
> >end,
>     hw_ddb_entry->start, hw_ddb_entry-
> >end);
> @@ -13549,8 +13548,7 @@ static void verify_wm_state(struct drm_crtc
> *crtc,
>   sw_ddb_entry = _ddb->plane[pipe][PLANE_CURSOR];
>  
>   if (!skl_ddb_entry_equal(hw_ddb_entry,
> sw_ddb_entry)) {
> - DRM_ERROR("mismatch in DDB state pipe %c
> cursor "
> -   "(expected (%u,%u), found
> (%u,%u))\n",
> + DRM_ERROR("mismatch in DDB state pipe %c
> cursor (expected (%u,%u), found (%u,%u))\n",
>     pipe_name(pipe),
>     sw_ddb_entry->start, sw_ddb_entry-
> >end,
>     hw_ddb_entry->start, hw_ddb_entry-
> >end);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 09/10] drm/i915/gen9: Actually verify WM levels in verify_wm_state()

[Paulo Zanoni]

Em Sex, 2016-10-07 às 20:11 -0400, Lyude escreveu:
> Thanks to Paulo Zanoni for indirectly pointing this out.
> 
> Looks like we never actually added any code for checking whether or
> not
> we actually wrote watermark levels properly. Let's fix that.

Thanks for doing this!

Reviewed-by: Paulo Zanoni 

A check that would have prevented one of the bugs I solved would be "if
plane is active, then level 0 must be enabled, and DDB partitioning
size must be non-zero". I'll put this in my TODO list, but I won't
complain if somebody does it first :)

> 
> Signed-off-by: Lyude 
> Cc: Maarten Lankhorst 
> Cc: Ville Syrjälä 
> Cc: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 100
> +--
>  1 file changed, 84 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 39400a0..2c682bc 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13444,30 +13444,66 @@ static void verify_wm_state(struct drm_crtc
> *crtc,
>   struct drm_device *dev = crtc->dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   struct skl_ddb_allocation hw_ddb, *sw_ddb;
> - struct skl_ddb_entry *hw_entry, *sw_entry;
> + struct skl_pipe_wm hw_wm, *sw_wm;
> + struct skl_plane_wm *hw_plane_wm, *sw_plane_wm;
> + struct skl_ddb_entry *hw_ddb_entry, *sw_ddb_entry;
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>   const enum pipe pipe = intel_crtc->pipe;
> - int plane;
> + int plane, level, max_level = ilk_wm_max_level(dev);
>  
>   if (INTEL_INFO(dev)->gen < 9 || !new_state->active)
>   return;
>  
> + skl_pipe_wm_get_hw_state(crtc, _wm);
> + sw_wm = _crtc->wm.active.skl;
> +
>   skl_ddb_get_hw_state(dev_priv, _ddb);
>   sw_ddb = _priv->wm.skl_hw.ddb;
>  
>   /* planes */
>   for_each_plane(dev_priv, pipe, plane) {
> - hw_entry = _ddb.plane[pipe][plane];
> - sw_entry = _ddb->plane[pipe][plane];
> + hw_plane_wm = _wm.planes[plane];
> + sw_plane_wm = _wm->planes[plane];
>  
> - if (skl_ddb_entry_equal(hw_entry, sw_entry))
> - continue;
> + /* Watermarks */
> + for (level = 0; level <= max_level; level++) {
> + if (skl_wm_level_equals(_plane_wm-
> >wm[level],
> + _plane_wm-
> >wm[level]))
> + continue;
> +
> + DRM_ERROR("mismatch in WM pipe %c plane %d
> level %d (expected e=%d b=%d l=%d, got e=%d b=%d l=%d)\n",
> +   pipe_name(pipe), plane + 1, level,
> +   sw_plane_wm->wm[level].plane_en,
> +   sw_plane_wm-
> >wm[level].plane_res_b,
> +   sw_plane_wm-
> >wm[level].plane_res_l,
> +   hw_plane_wm->wm[level].plane_en,
> +   hw_plane_wm-
> >wm[level].plane_res_b,
> +   hw_plane_wm-
> >wm[level].plane_res_l);
> + }
>  
> - DRM_ERROR("mismatch in DDB state pipe %c plane %d "
> -   "(expected (%u,%u), found (%u,%u))\n",
> -   pipe_name(pipe), plane + 1,
> -   sw_entry->start, sw_entry->end,
> -   hw_entry->start, hw_entry->end);
> + if (!skl_wm_level_equals(_plane_wm->trans_wm,
> +  _plane_wm->trans_wm)) {
> + DRM_ERROR("mismatch in trans WM pipe %c
> plane %d (expected e=%d b=%d l=%d, got e=%d b=%d l=%d)\n",
> +   pipe_name(pipe), plane + 1,
> +   sw_plane_wm->trans_wm.plane_en,
> +   sw_plane_wm->trans_wm.plane_res_b,
> +   sw_plane_wm->trans_wm.plane_res_l,
> +   hw_plane_wm->trans_wm.plane_en,
> +   hw_plane_wm->trans_wm.plane_res_b,
> +   hw_plane_wm-
> >trans_wm.plane_res_l);
> + }
> +
> + /* DDB */
> + hw_ddb_entry = _ddb.plane[pipe][plane];
> + sw_ddb_entry = _ddb->plane[pipe][plane];
> +
> + if (!skl_ddb_entry_equal(hw_ddb_entry,
> sw_ddb_entry)) {
> + DRM_ERROR("mismatch in DDB state pipe %c
> plane %d "
> +   "(expected (%u,%u), found
> (%u,%u))\n",
> +   pipe_name(pipe), plane + 1,
> +   sw_ddb_entry->start, sw_ddb_entry-
> >end,
> +   hw_ddb_entry->start, hw_ddb_entry-
> >end);
> + 

Re: [Intel-gfx] Problem with emgd on fedora 18

[Matt Roper]

On Thu, Oct 13, 2016 at 03:28:05PM +0300, Jani Nikula wrote:
> On Thu, 13 Oct 2016, Anteja Vuk Macek  wrote:
> > Hi,
> > I work with Fedora 18 and I'm new in linux world. I have problem with emgd
> > driver. I put emgd driver in kernel and build kernel. Moduled is build like
> > loadable module. But problem is when I load driver , you can see photo
> > https://my.syncplicity.com/share/skvhanon0sxj5f8/IMG_20161011_104347 . What
> > I need to do to fix my problem with driver ?
> 
> This list is for the upstream Linux drm/i915 driver and related
> stuff. We don't support the emgd driver on this list. Generally we don't
> even have a clue here about emgd, but perhaps Matt can give you pointers
> if and where you can get support for it.
> 
> BR,
> Jani.

Hi Anteja,

It's hard to tell what's wrong just from the screenshot, but my first
guess would be a panel (monitor) timing misconfiguration.  EMGD isn't
really intended for traditional PC-style operation, but rather for use
in "embedded" devices (i.e., specialized appliance-like devices like
store kiosks, automobiles, casino gaming machines, etc.).  Embedded
devices generally have a permanently fixed hardware and software
configuration so EMGD defaults to pulling all kinds of configuration
information (including monitor timing data and such) from a special
configuration file rather than autoprobing; if that config file has the
wrong information, you can easily wind up with corrupt or
non-functioning displays.

You mentioned that you're new to Linux...are you building an embedded
device which you need EMGD's specific embedded functionality for?  If
so, I'll try to find you an appropriate support channel for you to get
help (I haven't worked with EMGD for a few years, so I probably can't
help with any specifics at this point).  If you're not building an
embedded device, then you'd probably be better off using the standard
opensource drivers that come as part of your Linux distribution (and
using as new of a distribution as possible to ensure that the drivers
that come with it are the latest, most up-to-date versions).


Matt

> 
> 
> >
> > Emgd driver version : 36.1.25_3900
> >
> > Best regards,
> >
> > Anteja Vuk - Macek
> > Software Engineer
> >
> > Dolotron d.o.o.
> > Ziskovec 141
> > HR-4 Cakovec
> > Croatia
> > Tel: ++385 (40) 865 205
> > Fax: ++385 (40) 865 732
> > mailto: anteja...@dolotron.com
> > _
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

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

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

[Jeff McGee]

On Thu, Oct 13, 2016 at 10:42:42AM -0700, Jeff McGee wrote:
> On Mon, Oct 03, 2016 at 11:42:57AM -0700, 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.
> > 
> > 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.c |   3 +
> >  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|  44 ++
> >  drivers/gpu/drm/i915/intel_huc_loader.c | 268 
> > 
> >  8 files changed, 327 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 e6fe004..6e99c51 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -53,6 +53,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.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 31b2b63..7af7bd6 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -613,6 +613,7 @@ static int i915_load_modeset_init(struct drm_device 
> > *dev)
> >  * working irqs for e.g. gmbus and dp aux transfers. */
> > intel_modeset_init(dev);
> >  
> > +   intel_huc_init(dev);
> > intel_guc_init(dev);
> >  
> > ret = i915_gem_init(dev);
> > @@ -638,6 +639,7 @@ static int i915_load_modeset_init(struct drm_device 
> > *dev)
> >  cleanup_gem:
> > i915_gem_fini(dev);
> >  cleanup_irq:
> > +   intel_huc_fini(dev);
> > intel_guc_fini(dev);
> > drm_irq_uninstall(dev);
> > intel_teardown_gmbus(dev);
> > @@ -1315,6 +1317,7 @@ void i915_driver_unload(struct drm_device *dev)
> > /* Flush any outstanding unpin_work. */
> > drain_workqueue(dev_priv->wq);
> >  
> > +   intel_huc_fini(dev);
> > intel_guc_fini(dev);
> > i915_gem_fini(dev);
> > intel_fbc_cleanup_cfb(dev_priv);
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index e0cb71c..625aa92 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -55,6 +55,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"
> >  
> > @@ -1766,6 +1767,7 @@ struct drm_i915_private {
> >  
> > struct intel_gvt gvt;
> >  
> > +   struct intel_huc huc;
> > struct intel_guc guc;
> >  
> > struct intel_csr csr;
> > @@ -2822,6 +2824,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)
> > 

Re: [Intel-gfx] [PATCH 08/10] drm/i915/gen9: Add skl_wm_level_equals()

[Paulo Zanoni]

Em Sex, 2016-10-07 às 20:11 -0400, Lyude escreveu:
> Helper we're going to be using for implementing verification of the
> wm
> levels in skl_verify_wm_level().
> 
> Signed-off-by: Lyude 

Reviewed-by: Paulo Zanoni 

> Cc: Maarten Lankhorst 
> Cc: Ville Syrjälä 
> Cc: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_drv.h |  2 ++
>  drivers/gpu/drm/i915/intel_pm.c  | 14 ++
>  2 files changed, 16 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 73a2d16d..3e6e9af 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1761,6 +1761,8 @@ void skl_pipe_wm_get_hw_state(struct drm_crtc
> *crtc,
>  bool intel_can_enable_sagv(struct drm_atomic_state *state);
>  int intel_enable_sagv(struct drm_i915_private *dev_priv);
>  int intel_disable_sagv(struct drm_i915_private *dev_priv);
> +bool skl_wm_level_equals(const struct skl_wm_level *l1,
> +  const struct skl_wm_level *l2);
>  bool skl_ddb_allocation_equals(const struct skl_ddb_allocation *old,
>      const struct skl_ddb_allocation *new,
>      enum pipe pipe);
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index 27a520ce..6af1587 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3853,6 +3853,20 @@ void skl_write_cursor_wm(struct intel_crtc
> *intel_crtc,
>   >plane[pipe][PLANE_CURSOR]);
>  }
>  
> +bool skl_wm_level_equals(const struct skl_wm_level *l1,
> +  const struct skl_wm_level *l2)
> +{
> + if (l1->plane_en != l2->plane_en)
> + return false;
> +
> + /* If both planes aren't enabled, the rest shouldn't matter
> */
> + if (!l1->plane_en)
> + return true;
> +
> + return (l1->plane_res_l == l2->plane_res_l &&
> + l1->plane_res_b == l2->plane_res_b);
> +}
> +
>  static inline bool skl_ddb_entries_overlap(const struct
> skl_ddb_entry *a,
>      const struct
> skl_ddb_entry *b)
>  {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/10] drm/i915/gen9: Make skl_pipe_wm_get_hw_state() reusable

[Paulo Zanoni]

Em Sex, 2016-10-07 às 20:11 -0400, Lyude escreveu:
> There's not much of a reason this should have the locations to read
> out
> the hardware state hardcoded, so allow the caller to specify the
> location and add this function to intel_drv.h. As well, we're going
> to
> need this function to be reusable for the next patch.
> 
> Signed-off-by: Lyude 
> Cc: Maarten Lankhorst 
> Cc: Ville Syrjälä 
> Cc: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_drv.h |  2 ++
>  drivers/gpu/drm/i915/intel_pm.c  | 27 +--
>  2 files changed, 19 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 958dc72..73a2d16d 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1756,6 +1756,8 @@ void ilk_wm_get_hw_state(struct drm_device
> *dev);
>  void skl_wm_get_hw_state(struct drm_device *dev);
>  void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,
>     struct skl_ddb_allocation *ddb /* out */);
> +void skl_pipe_wm_get_hw_state(struct drm_crtc *crtc,
> +   struct skl_pipe_wm *out);
>  bool intel_can_enable_sagv(struct drm_atomic_state *state);
>  int intel_enable_sagv(struct drm_i915_private *dev_priv);
>  int intel_disable_sagv(struct drm_i915_private *dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index 9e53ff7..27a520ce 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4287,15 +4287,13 @@ static inline void
> skl_wm_level_from_reg_val(uint32_t val,
>   PLANE_WM_LINES_MASK;
>  }
>  
> -static void skl_pipe_wm_get_hw_state(struct drm_crtc *crtc)
> +void skl_pipe_wm_get_hw_state(struct drm_crtc *crtc,
> +   struct skl_pipe_wm *out)
>  {
>   struct drm_device *dev = crtc->dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> - struct skl_wm_values *hw = _priv->wm.skl_hw;
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> - struct intel_crtc_state *cstate = to_intel_crtc_state(crtc-
> >state);
>   struct intel_plane *intel_plane;
> - struct skl_pipe_wm *active = >wm.skl.optimal;
>   struct skl_plane_wm *wm;
>   enum pipe pipe = intel_crtc->pipe;
>   int level, id, max_level = ilk_wm_max_level(dev);
> @@ -4303,7 +4301,7 @@ static void skl_pipe_wm_get_hw_state(struct
> drm_crtc *crtc)
>  
>   for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
>   id = skl_wm_plane_id(intel_plane);
> - wm = >wm.skl.optimal.planes[id];
> + wm = >planes[id];
>  
>   for (level = 0; level <= max_level; level++) {
>   if (id != PLANE_CURSOR)
> @@ -4325,20 +4323,29 @@ static void skl_pipe_wm_get_hw_state(struct
> drm_crtc *crtc)
>   if (!intel_crtc->active)
>   return;
>  
> - hw->dirty_pipes |= drm_crtc_mask(crtc);
> - active->linetime = I915_READ(PIPE_WM_LINETIME(pipe));
> - intel_crtc->wm.active.skl = *active;
> + out->linetime = I915_READ(PIPE_WM_LINETIME(pipe));
>  }
>  
>  void skl_wm_get_hw_state(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = to_i915(dev);
> + struct skl_wm_values *hw = _priv->wm.skl_hw;
>   struct skl_ddb_allocation *ddb = _priv->wm.skl_hw.ddb;
>   struct drm_crtc *crtc;
> + struct intel_crtc *intel_crtc;
> + struct intel_crtc_state *cstate;
>  
>   skl_ddb_get_hw_state(dev_priv, ddb);
> - list_for_each_entry(crtc, >mode_config.crtc_list, head)
> - skl_pipe_wm_get_hw_state(crtc);
> + list_for_each_entry(crtc, >mode_config.crtc_list, head)
> {
> + intel_crtc = to_intel_crtc(crtc);
> + cstate = to_intel_crtc_state(crtc->state);
> +
> + skl_pipe_wm_get_hw_state(crtc, 
> >wm.skl.optimal);
> + intel_crtc->wm.active.skl = cstate->wm.skl.optimal;

We're changing how the code behaves regarding intel_crtc-
>wm.active.skl. Previously we would only set it if intel_crtc->active
is true due to that return in skl_pipe_wm_get_hw_state(). Now we're
always setting it.

If this is some sort of fix it probably deserves to be in a separate
commit with a nice commit message.

> +
> + if (!intel_crtc->active)
> + hw->dirty_pipes |= drm_crtc_mask(crtc);

Same here: previously we would not set dirty_pipes in case !intel_crtc-
>active. Now we're doing the opposite. Didn't you mean "if (intel_crtc-
>active)" here?

> + }
>  
>   if (dev_priv->active_crtcs) {
>   /* Fully recompute DDB on first atomic commit */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/edid: Only print the bad edid when aborting

[Patchwork]

== Series Details ==

Series: drm/edid: Only print the bad edid when aborting
URL   : https://patchwork.freedesktop.org/series/13747/
State : warning

== Summary ==

Series 13747v1 drm/edid: Only print the bad edid when aborting
https://patchwork.freedesktop.org/api/1.0/series/13747/revisions/1/mbox/

Test drv_module_reload_basic:
skip   -> PASS   (fi-skl-6770hq)
Test kms_busy:
Subgroup basic-flip-default-b:
pass   -> DMESG-WARN (fi-skl-6700k)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-b-frame-sequence:
dmesg-warn -> PASS   (fi-ilk-650)
Test vgem_basic:
Subgroup unload:
skip   -> PASS   (fi-skl-6770hq)
skip   -> PASS   (fi-hsw-4770)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:184  dwarn:0   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:220  dwarn:2   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:230  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2710/

dbcf6fbb541e70fac7db669631958eab2e4e0d9c drm-intel-nightly: 
2016y-10m-13d-15h-31m-19s UTC integration manifest
88e63c4 drm/edid: Only print the bad edid when aborting

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

Re: [Intel-gfx] [PATCH v2 06/10] drm/i915/gen9: Add ddb changes to atomic debug output

[Paulo Zanoni]

Em Sex, 2016-10-07 às 20:11 -0400, Lyude escreveu:
> Finally, add some debugging output for ddb changes in the atomic
> debug
> output. This makes it a lot easier to spot bugs from incorrect ddb
> allocations.
> 
> Signed-off-by: Lyude 
> Reviewed-by: Maarten Lankhorst 
> Cc: Ville Syrjälä 
> Cc: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 57
> +
>  1 file changed, 57 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index 5cb537c..9e53ff7 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4040,6 +4040,61 @@ skl_copy_wm_for_pipe(struct skl_wm_values
> *dst,
>      sizeof(dst->ddb.plane[pipe]));
>  }
>  
> +static void
> +skl_print_wm_changes(const struct drm_atomic_state *state)
> +{
> + const struct drm_device *dev = state->dev;
> + const struct drm_i915_private *dev_priv = to_i915(dev);
> + const struct intel_atomic_state *intel_state =
> + to_intel_atomic_state(state);
> + const struct drm_crtc *crtc;
> + const struct drm_crtc_state *cstate;
> + const struct drm_plane *plane;
> + const struct intel_plane *intel_plane;
> + const struct drm_plane_state *pstate;
> + const struct skl_ddb_allocation *old_ddb = _priv-
> >wm.skl_hw.ddb;
> + const struct skl_ddb_allocation *new_ddb = _state-
> >wm_results.ddb;
> + enum pipe pipe;
> + int id;
> + int i, j;
> +
> + for_each_crtc_in_state(state, crtc, cstate, i) {
> + if (!crtc->state)
> + continue;

Why exactly do we have this check?

Everything else looks good. So with either an explanation or the check
removed in case it's not needed:
Reviewed-by: Paulo Zanoni 

> +
> + pipe = to_intel_crtc(crtc)->pipe;
> +
> + for_each_plane_in_state(state, plane, pstate, j) {
> + const struct skl_ddb_entry *old, *new;
> +
> + intel_plane = to_intel_plane(plane);
> + id = skl_wm_plane_id(intel_plane);
> + old = _ddb->plane[pipe][id];
> + new = _ddb->plane[pipe][id];
> +
> + if (intel_plane->pipe != pipe)
> + continue;
> +
> + if (skl_ddb_entry_equal(old, new))
> + continue;
> +
> + if (id != PLANE_CURSOR) {
> + DRM_DEBUG_ATOMIC("[PLANE:%d:plane
> %d%c] ddb (%d - %d) -> (%d - %d)\n",
> +  plane->base.id, id
> + 1,
> +  pipe_name(pipe),
> +  old->start, old-
> >end,
> +  new->start, new-
> >end);
> + } else {
> + DRM_DEBUG_ATOMIC("[PLANE:%d:cursor
> %c] ddb (%d - %d) -> (%d - %d)\n",
> +  plane->base.id,
> +  pipe_name(pipe),
> +  old->start, old-
> >end,
> +  new->start, new-
> >end);
> + }
> + }
> + }
> +}
> +
>  static int
>  skl_compute_wm(struct drm_atomic_state *state)
>  {
> @@ -4101,6 +4156,8 @@ skl_compute_wm(struct drm_atomic_state *state)
>   intel_cstate->update_wm_pre = true;
>   }
>  
> + skl_print_wm_changes(state);
> +
>   return 0;
>  }
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 05/10] drm/i915/gen9: Get rid of redundant watermark values

[Paulo Zanoni]

Em Qui, 2016-10-13 às 17:04 -0300, Paulo Zanoni escreveu:
> Em Qui, 2016-10-13 às 15:39 +0200, Maarten Lankhorst escreveu:
> > 
> > Op 08-10-16 om 02:11 schreef Lyude:
> > > 
> > > 
> > > Now that we've make skl_wm_levels make a little more sense, we
> > > can
> > > remove all of the redundant wm information. Up until now we'd
> > > been
> > > storing two copies of all of the skl watermarks: one being the
> > > skl_pipe_wm structs, the other being the global wm struct in
> > > drm_i915_private containing the raw register values. This is
> > > confusing
> > > and problematic, since it means we're prone to accidentally
> > > letting
> > > the
> > > two copies go out of sync. So, get rid of all of the functions
> > > responsible for computing the register values and just use a
> > > single
> > > helper, skl_write_wm_level(), to convert and write the new
> > > watermarks on
> > > the fly.
> > > 
> > > Changes since v1:
> > > - Fixup skl_write_wm_level()
> > > - Fixup skl_wm_level_from_reg_val()
> > > - Don't forget to copy *active to intel_crtc->wm.active.skl
> > > 
> > > Signed-off-by: Lyude 
> > > Reviewed-by: Maarten Lankhorst  > > >
> > > Cc: Ville Syrjälä 
> > > Cc: Paulo Zanoni 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.h  |   2 -
> > >  drivers/gpu/drm/i915/intel_display.c |  14 ++-
> > >  drivers/gpu/drm/i915/intel_drv.h |   6 +-
> > >  drivers/gpu/drm/i915/intel_pm.c  | 204 -
> > > --
> > > 
> > >  drivers/gpu/drm/i915/intel_sprite.c  |   8 +-
> > >  5 files changed, 90 insertions(+), 144 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 0287c93..76583b2 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -1644,8 +1644,6 @@ struct skl_ddb_allocation {
> > >  struct skl_wm_values {
> > >   unsigned dirty_pipes;
> > >   struct skl_ddb_allocation ddb;
> > > - uint32_t plane[I915_MAX_PIPES][I915_MAX_PLANES][8];
> > > - uint32_t plane_trans[I915_MAX_PIPES][I915_MAX_PLANES];
> > >  };
> > >  
> > >  struct skl_wm_level {
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index a71d05a..39400a0 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -3378,6 +3378,8 @@ static void
> > > skylake_update_primary_plane(struct drm_plane *plane,
> > >   struct intel_crtc *intel_crtc =
> > > to_intel_crtc(crtc_state-
> > > > 
> > > > base.crtc);
> > >   struct drm_framebuffer *fb = plane_state->base.fb;
> > >   const struct skl_wm_values *wm = _priv-
> > > > 
> > > > wm.skl_results;
> > > + const struct skl_plane_wm *p_wm =
> > > + _state->wm.skl.optimal.planes[0];
> > >   int pipe = intel_crtc->pipe;
> > >   u32 plane_ctl;
> > >   unsigned int rotation = plane_state->base.rotation;
> > > @@ -3414,7 +3416,7 @@ static void
> > > skylake_update_primary_plane(struct drm_plane *plane,
> > >   intel_crtc->adjusted_y = src_y;
> > >  
> > >   if (wm->dirty_pipes & drm_crtc_mask(_crtc->base))
> > > - skl_write_plane_wm(intel_crtc, wm, 0);
> > > + skl_write_plane_wm(intel_crtc, p_wm, >ddb,
> > > 0);
> > >  
> > >   I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);
> > >   I915_WRITE(PLANE_OFFSET(pipe, 0), (src_y << 16) |
> > > src_x);
> > > @@ -3448,6 +3450,8 @@ static void
> > > skylake_disable_primary_plane(struct drm_plane *primary,
> > >   struct drm_device *dev = crtc->dev;
> > >   struct drm_i915_private *dev_priv = to_i915(dev);
> > >   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > > + struct intel_crtc_state *cstate =
> > > to_intel_crtc_state(crtc->state);
> > > + const struct skl_plane_wm *p_wm = 
> > > > 
> > > > wm.skl.optimal.planes[0];
> > >   int pipe = intel_crtc->pipe;
> > >  
> > >   /*
> > > @@ -3455,7 +3459,8 @@ static void
> > > skylake_disable_primary_plane(struct drm_plane *primary,
> > >    * plane's visiblity isn't actually changing neither is
> > > its watermarks.
> > >    */
> > >   if (!crtc->primary->state->visible)
> > > - skl_write_plane_wm(intel_crtc, _priv-
> > > > 
> > > > wm.skl_results, 0);
> > > + skl_write_plane_wm(intel_crtc, p_wm,
> > > +    _priv-
> > > >wm.skl_results.ddb,
> > > 0);
> > >  
> > >   I915_WRITE(PLANE_CTL(pipe, 0), 0);
> > >   I915_WRITE(PLANE_SURF(pipe, 0), 0);
> > > @@ -10819,12 +10824,15 @@ static void i9xx_update_cursor(struct
> > > drm_crtc *crtc, u32 base,
> > >   struct drm_device *dev = crtc->dev;
> > >   struct drm_i915_private *dev_priv = to_i915(dev);
> > >   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > > + struct intel_crtc_state *cstate =
> > > to_intel_crtc_state(crtc->state);
> > >   const struct skl_wm_values *wm = _priv-
> > > > 
> > > > wm.skl_results;
> > > + const struct 

Re: [Intel-gfx] [PATCH v2 05/10] drm/i915/gen9: Get rid of redundant watermark values

[Paulo Zanoni]

Em Qui, 2016-10-13 às 15:39 +0200, Maarten Lankhorst escreveu:
> Op 08-10-16 om 02:11 schreef Lyude:
> > 
> > Now that we've make skl_wm_levels make a little more sense, we can
> > remove all of the redundant wm information. Up until now we'd been
> > storing two copies of all of the skl watermarks: one being the
> > skl_pipe_wm structs, the other being the global wm struct in
> > drm_i915_private containing the raw register values. This is
> > confusing
> > and problematic, since it means we're prone to accidentally letting
> > the
> > two copies go out of sync. So, get rid of all of the functions
> > responsible for computing the register values and just use a single
> > helper, skl_write_wm_level(), to convert and write the new
> > watermarks on
> > the fly.
> > 
> > Changes since v1:
> > - Fixup skl_write_wm_level()
> > - Fixup skl_wm_level_from_reg_val()
> > - Don't forget to copy *active to intel_crtc->wm.active.skl
> > 
> > Signed-off-by: Lyude 
> > Reviewed-by: Maarten Lankhorst 
> > Cc: Ville Syrjälä 
> > Cc: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  |   2 -
> >  drivers/gpu/drm/i915/intel_display.c |  14 ++-
> >  drivers/gpu/drm/i915/intel_drv.h |   6 +-
> >  drivers/gpu/drm/i915/intel_pm.c  | 204 ---
> > 
> >  drivers/gpu/drm/i915/intel_sprite.c  |   8 +-
> >  5 files changed, 90 insertions(+), 144 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 0287c93..76583b2 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1644,8 +1644,6 @@ struct skl_ddb_allocation {
> >  struct skl_wm_values {
> >     unsigned dirty_pipes;
> >     struct skl_ddb_allocation ddb;
> > -   uint32_t plane[I915_MAX_PIPES][I915_MAX_PLANES][8];
> > -   uint32_t plane_trans[I915_MAX_PIPES][I915_MAX_PLANES];
> >  };
> >  
> >  struct skl_wm_level {
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index a71d05a..39400a0 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -3378,6 +3378,8 @@ static void
> > skylake_update_primary_plane(struct drm_plane *plane,
> >     struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state-
> > >base.crtc);
> >     struct drm_framebuffer *fb = plane_state->base.fb;
> >     const struct skl_wm_values *wm = _priv-
> > >wm.skl_results;
> > +   const struct skl_plane_wm *p_wm =
> > +   _state->wm.skl.optimal.planes[0];
> >     int pipe = intel_crtc->pipe;
> >     u32 plane_ctl;
> >     unsigned int rotation = plane_state->base.rotation;
> > @@ -3414,7 +3416,7 @@ static void
> > skylake_update_primary_plane(struct drm_plane *plane,
> >     intel_crtc->adjusted_y = src_y;
> >  
> >     if (wm->dirty_pipes & drm_crtc_mask(_crtc->base))
> > -   skl_write_plane_wm(intel_crtc, wm, 0);
> > +   skl_write_plane_wm(intel_crtc, p_wm, >ddb, 0);
> >  
> >     I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);
> >     I915_WRITE(PLANE_OFFSET(pipe, 0), (src_y << 16) | src_x);
> > @@ -3448,6 +3450,8 @@ static void
> > skylake_disable_primary_plane(struct drm_plane *primary,
> >     struct drm_device *dev = crtc->dev;
> >     struct drm_i915_private *dev_priv = to_i915(dev);
> >     struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > +   struct intel_crtc_state *cstate =
> > to_intel_crtc_state(crtc->state);
> > +   const struct skl_plane_wm *p_wm = 
> > >wm.skl.optimal.planes[0];
> >     int pipe = intel_crtc->pipe;
> >  
> >     /*
> > @@ -3455,7 +3459,8 @@ static void
> > skylake_disable_primary_plane(struct drm_plane *primary,
> >      * plane's visiblity isn't actually changing neither is
> > its watermarks.
> >      */
> >     if (!crtc->primary->state->visible)
> > -   skl_write_plane_wm(intel_crtc, _priv-
> > >wm.skl_results, 0);
> > +   skl_write_plane_wm(intel_crtc, p_wm,
> > +      _priv->wm.skl_results.ddb,
> > 0);
> >  
> >     I915_WRITE(PLANE_CTL(pipe, 0), 0);
> >     I915_WRITE(PLANE_SURF(pipe, 0), 0);
> > @@ -10819,12 +10824,15 @@ static void i9xx_update_cursor(struct
> > drm_crtc *crtc, u32 base,
> >     struct drm_device *dev = crtc->dev;
> >     struct drm_i915_private *dev_priv = to_i915(dev);
> >     struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > +   struct intel_crtc_state *cstate =
> > to_intel_crtc_state(crtc->state);
> >     const struct skl_wm_values *wm = _priv-
> > >wm.skl_results;
> > +   const struct skl_plane_wm *p_wm =
> > +   >wm.skl.optimal.planes[PLANE_CURSOR];
> >     int pipe = intel_crtc->pipe;
> >     uint32_t cntl = 0;
> >  
> >     if (INTEL_GEN(dev_priv) >= 9 && wm->dirty_pipes &
> > drm_crtc_mask(crtc))
> > -   skl_write_cursor_wm(intel_crtc, wm);
> > +   skl_write_cursor_wm(intel_crtc, p_wm, 

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev3)

[Chris Wilson]

On Thu, Oct 13, 2016 at 06:47:24PM +, Saarinen, Jani wrote:
> > > == Series Details ==
> > >
> > > Series: drm/i915: Allocate intel_engine_cs structure only for the enabled
> > engines (rev3)
> > > URL   : https://patchwork.freedesktop.org/series/13435/
> > > State : warning
> > >
> > > == Summary ==
> > >
> > > Series 13435v3 drm/i915: Allocate intel_engine_cs structure only for
> > > the enabled engines
> > > https://patchwork.freedesktop.org/api/1.0/series/13435/revisions/3/mbo
> > > x/
> > >
> > > Test vgem_basic:
> > > Subgroup unload:
> > > pass   -> SKIP   (fi-skl-6260u)
> > > pass   -> SKIP   (fi-skl-6700hq)
> > > skip   -> PASS   (fi-skl-6700k)
> > >
> > Checked with Chris about the above failure.
> > He said that the above unload failure for vgem module can't be attributed to
> > the patch, most likely a CI framework issue.
> Yes, this test is still behaving badly especially with SKL systems but also 
> with bdw and kbl.

Are the test run in the order defined by fast-feedback.testlist ?
I intended the vgem unload test to be run as the first vgem testcase to
minimise the chance of a stray module leak. Can we define the order
within CI? Can we put comments into fast-feedback.testlist ?
-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] drm/edid: Only print the bad edid when aborting

[Chris Wilson]

Currently, if drm.debug is enabled, we get a DRM_ERROR message on the
intermediate edid reads. This causes transient failures in CI which
flags up the sporadic EDID read failures, which are recovered by
rereading the EDID automatically. This patch combines the reporting done
by drm_do_get_edid() itself with the bad block printing from
get_edid_block(), into a single warning associated with the connector
once all attempts to retrieve the EDID fail.

References: https://bugs.freedesktop.org/show_bug.cgi?id=98228
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/drm_edid.c | 82 +-
 1 file changed, 44 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ec77bd3e1f08..51dd10c65b53 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1260,6 +1260,26 @@ drm_do_probe_ddc_edid(void *data, u8 *buf, unsigned int 
block, size_t len)
return ret == xfers ? 0 : -1;
 }
 
+static void connector_add_bad_edid(struct drm_connector *connector,
+  u8 *block, int num)
+{
+   if (connector->bad_edid_counter++ && !(drm_debug & DRM_UT_KMS))
+   return;
+
+   if (drm_edid_is_zero(block, EDID_LENGTH)) {
+   dev_warn(connector->dev->dev,
+"%s: EDID block %d is all zeroes.\n",
+connector->name, num);
+   } else {
+   dev_warn(connector->dev->dev,
+"%s: EDID block %d invalid:\n",
+connector->name, num);
+   print_hex_dump(KERN_WARNING,
+  " \t", DUMP_PREFIX_NONE, 16, 1,
+  block, EDID_LENGTH, false);
+   }
+}
+
 /**
  * drm_do_get_edid - get EDID data using a custom EDID block read function
  * @connector: connector we're probing
@@ -1282,20 +1302,19 @@ struct edid *drm_do_get_edid(struct drm_connector 
*connector,
void *data)
 {
int i, j = 0, valid_extensions = 0;
-   u8 *block, *new;
-   bool print_bad_edid = !connector->bad_edid_counter || (drm_debug & 
DRM_UT_KMS);
+   u8 *edid, *new;
 
-   if ((block = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
+   if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
return NULL;
 
/* base block fetch */
for (i = 0; i < 4; i++) {
-   if (get_edid_block(data, block, 0, EDID_LENGTH))
+   if (get_edid_block(data, edid, 0, EDID_LENGTH))
goto out;
-   if (drm_edid_block_valid(block, 0, print_bad_edid,
+   if (drm_edid_block_valid(edid, 0, false,
 >edid_corrupt))
break;
-   if (i == 0 && drm_edid_is_zero(block, EDID_LENGTH)) {
+   if (i == 0 && drm_edid_is_zero(edid, EDID_LENGTH)) {
connector->null_edid_counter++;
goto carp;
}
@@ -1304,58 +1323,45 @@ struct edid *drm_do_get_edid(struct drm_connector 
*connector,
goto carp;
 
/* if there's no extensions, we're done */
-   if (block[0x7e] == 0)
-   return (struct edid *)block;
+   if (edid[0x7e] == 0)
+   return (struct edid *)edid;
 
-   new = krealloc(block, (block[0x7e] + 1) * EDID_LENGTH, GFP_KERNEL);
+   new = krealloc(edid, (edid[0x7e] + 1) * EDID_LENGTH, GFP_KERNEL);
if (!new)
goto out;
-   block = new;
+   edid = new;
+
+   for (j = 1; j <= edid[0x7e]; j++) {
+   u8 *block = edid + (valid_extensions + 1) * EDID_LENGTH;
 
-   for (j = 1; j <= block[0x7e]; j++) {
for (i = 0; i < 4; i++) {
-   if (get_edid_block(data,
- block + (valid_extensions + 1) * EDID_LENGTH,
- j, EDID_LENGTH))
+   if (get_edid_block(data, block, j, EDID_LENGTH))
goto out;
-   if (drm_edid_block_valid(block + (valid_extensions + 1)
-* EDID_LENGTH, j,
-print_bad_edid,
-NULL)) {
+   if (drm_edid_block_valid(block, j, false, NULL)) {
valid_extensions++;
break;
}
}
 
-   if (i == 4 && print_bad_edid) {
-   dev_warn(connector->dev->dev,
-"%s: Ignoring invalid EDID block %d.\n",
-connector->name, j);
-
-   connector->bad_edid_counter++;
-   }
+   if (i == 4)
+   connector_add_bad_edid(connector, block, j);
   

Re: [Intel-gfx] [RFC PATCH v2 4/8] drm/i915: Add support for enabling/disabling hdmi audio interrupts

[Pierre-Louis Bossart]

+/* Added for HDMI Audio */
+int i915_enable_hdmi_audio_int(struct drm_i915_private *dev_priv)
+{
+   unsigned long irqflags;
+   u32 imr, int_bit;
+   int pipe = -1;
+
+   spin_lock_irqsave(_priv->irq_lock, irqflags);
+
+   imr = I915_READ(VLV_IMR);
+
+   if (IS_CHERRYVIEW(_priv->drm)) {
+   pipe = PIPE_C;
+   int_bit = (pipe ? (I915_LPE_PIPE_B_INTERRUPT >>
+   ((pipe - 1) * 9)) :
+   I915_LPE_PIPE_A_INTERRUPT);


Either parametrize the I915_LPE_PIPE_INTERRUPT macro, or just have eg. a
switch here.


ok



But the bigger issue here is the mess with selecting the right bit. I
assume it should either depend on the pipe or port. I can't figure out
what is going on here.

And actually I don't understand why we even need this function. The
irqchip should take care to unmask all the interrupts when the audio
device does its request_irq.


agree, it's not clear to me either. I'll work with Jerome to figure out 
if/how this can be removed.




@@ -3364,6 +3425,14 @@ static void vlv_display_irq_postinstall(struct 
drm_i915_private *dev_priv)

WARN_ON(dev_priv->irq_mask != ~0);

+   if (IS_LPE_AUDIO_ENABLED(dev_priv)) {
+   u32 val = (I915_LPE_PIPE_A_INTERRUPT |
+   I915_LPE_PIPE_B_INTERRUPT |
+   I915_LPE_PIPE_C_INTERRUPT);


'val' seems like a rather pointless local variable.


+
+   enable_mask |= val;


indeed, will fix.

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

Re: [Intel-gfx] [RFC PATCH v2 1/8] drm/i915: setup bridge for HDMI LPE audio driver

[Pierre-Louis Bossart]

Thanks Ville for the review. A lot of the comments are related to the 
initial VED code we took pretty much as is, no issues to clean-up further.


BTW, it looks like Jerome's patches were stuck for 10+ days on the 
intel-gfx server for some reason so not everyone saw the initial post?



@@ -1141,7 +1141,13 @@ static void i915_driver_register(struct drm_i915_private 
*dev_priv)
if (IS_GEN5(dev_priv))
intel_gpu_ips_init(dev_priv);

-   i915_audio_component_init(dev_priv);
+   if (intel_lpe_audio_detect(dev_priv)) {
+   if (intel_lpe_audio_setup(dev_priv) < 0)
+   DRM_ERROR("failed to setup LPE Audio bridge\n");
+   }


I'd move all that into the lpe audio code. No need to have anything here
but a single function call IMO.


something like intel_lpe_audio_init() for symmetry with the hda 
component stuff, with both detection and setup handled internally?



+
+   if (!IS_LPE_AUDIO_ENABLED(dev_priv))


I don't like that too much. I think I would just make
that HAS_LPE_AUDIO(). The current IS_VLV||IS_CHV check can just be
inlined into the init function.


ok




 #define HAS_POOLED_EU(dev) (INTEL_INFO(dev)->has_pooled_eu)

+#define HAS_LPE_AUDIO(dev) (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev))
+#define IS_LPE_AUDIO_ENABLED(dev_priv) \
+   (__I915__(dev_priv)->lpe_audio.platdev != NULL)
+#define IS_LPE_AUDIO_IRQ_VALID(dev_priv) \
+   (__I915__(dev_priv)->lpe_audio.irq >= 0)


Seems useless. We should just not register the lpe audio thing if we
have no irq.


ok


--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1827,6 +1827,13 @@ static irqreturn_t valleyview_irq_handler(int irq, void 
*arg)
 * signalled in iir */
valleyview_pipestat_irq_ack(dev_priv, iir, pipe_stats);

+   if (IS_LPE_AUDIO_ENABLED(dev_priv))
+   if (IS_LPE_AUDIO_IRQ_VALID(dev_priv))


I think both of these checks can be removed. We won't unmask the
interrupts unless lpe is enabled, so the IIR bits will never be set in
that case.


+   if (iir & (I915_LPE_PIPE_A_INTERRUPT |
+   I915_LPE_PIPE_B_INTERRUPT |
+   I915_LPE_PIPE_C_INTERRUPT))
+   intel_lpe_audio_irq_handler(dev_priv);
+


ok.


/*
 * VLV_IIR is single buffered, and reflects the level
 * from PIPESTAT/PORT_HOTPLUG_STAT, hence clear it last.
@@ -1907,6 +1914,13 @@ static irqreturn_t cherryview_irq_handler(int irq, void 
*arg)
 * signalled in iir */
valleyview_pipestat_irq_ack(dev_priv, iir, pipe_stats);

+   if (IS_LPE_AUDIO_ENABLED(dev_priv))
+   if (IS_LPE_AUDIO_IRQ_VALID(dev_priv))
+   if (iir & (I915_LPE_PIPE_A_INTERRUPT |
+   I915_LPE_PIPE_B_INTERRUPT |
+   I915_LPE_PIPE_C_INTERRUPT))
+   intel_lpe_audio_irq_handler(dev_priv);
+


ditto


ok



+   platdev = platform_device_alloc("hdmi-lpe-audio", -1);
+   if (!platdev) {
+   ret = -ENOMEM;
+   DRM_ERROR("Failed to allocate LPE audio platform device\n");
+   goto err;
+   }
+
+   /* to work-around check_addr in nommu_map_sg() */


What's this about?


Dunno, this was in the original VED series that we used as a baseline. 
Unless someone has memories from that time, i'll just remove this comment.




+   DRM_DEBUG("%s: HDMI_AUDIO rsc.start[0] = 0x%x\n",
+   __func__, (int)(rsc[0].start));


__func__ pointless since DRM_DEBUG alreay adds it. Also saying
"rsc.start[0]" in the message doesn't tell anyone anything useful.
And I think irq numbers are usually printed in decimal.


Same, this was taken from the VED series, no issue to clean-up.




+
+   rsc[1].start= pci_resource_start(dev->pdev, 0) +
+   I915_HDMI_LPE_AUDIO_BASE;
+   rsc[1].end  = pci_resource_start(dev->pdev, 0) +
+   I915_HDMI_LPE_AUDIO_BASE + I915_HDMI_LPE_AUDIO_SIZE - 1;
+   rsc[1].flags= IORESOURCE_MEM;
+   rsc[1].name = "hdmi-lpe-audio-mmio";
+
+   DRM_DEBUG("%s: HDMI_AUDIO rsc.start[1] = 0x%x\n",
+   __func__, (int)(rsc[1].start));


Again "rsc[0].start" doesn't seem like anything useful to print in a
debug message. Don't see much point in the whole debug message TBH since
the start/end are fixed.


so are you saying we should remove the code or move the level to 
DRM_INFO - for extra verbose debug?





+
+   ret = platform_device_add_resources(platdev, rsc, 2);
+   if (ret) {
+   DRM_ERROR("Failed to add resource for platform device: %d\n",
+   ret);
+   goto 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2

[Patchwork]

== Series Details ==

Series: drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and 
HBR2
URL   : https://patchwork.freedesktop.org/series/13745/
State : success

== Summary ==

Series 13745v1 drm/i915/dp: Increase cdclk when DP audio is enabled with 4 
lanes and HBR2
https://patchwork.freedesktop.org/api/1.0/series/13745/revisions/1/mbox/

Test drv_module_reload_basic:
skip   -> PASS   (fi-skl-6770hq)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-b-frame-sequence:
dmesg-warn -> PASS   (fi-ilk-650)
Test vgem_basic:
Subgroup unload:
skip   -> PASS   (fi-hsw-4770)
skip   -> PASS   (fi-skl-6770hq)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:212  dwarn:2   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:184  dwarn:0   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:230  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2709/

dbcf6fbb541e70fac7db669631958eab2e4e0d9c drm-intel-nightly: 
2016y-10m-13d-15h-31m-19s UTC integration manifest
36d0d8d drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and 
HBR2

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev3)

[Saarinen, Jani]

> > == Series Details ==
> >
> > Series: drm/i915: Allocate intel_engine_cs structure only for the enabled
> engines (rev3)
> > URL   : https://patchwork.freedesktop.org/series/13435/
> > State : warning
> >
> > == Summary ==
> >
> > Series 13435v3 drm/i915: Allocate intel_engine_cs structure only for
> > the enabled engines
> > https://patchwork.freedesktop.org/api/1.0/series/13435/revisions/3/mbo
> > x/
> >
> > Test vgem_basic:
> > Subgroup unload:
> > pass   -> SKIP   (fi-skl-6260u)
> > pass   -> SKIP   (fi-skl-6700hq)
> > skip   -> PASS   (fi-skl-6700k)
> >
> Checked with Chris about the above failure.
> He said that the above unload failure for vgem module can't be attributed to
> the patch, most likely a CI framework issue.
Yes, this test is still behaving badly especially with SKL systems but also 
with bdw and kbl.

> 
> Best regards
> Akash
> 
> > fi-bdw-5557u total:248  pass:231  dwarn:0   dfail:0   fail:0   skip:17
> > fi-bsw-n3050 total:248  pass:204  dwarn:0   dfail:0   fail:0   skip:44
> > fi-bxt-t5700 total:248  pass:217  dwarn:0   dfail:0   fail:0   skip:31
> > fi-byt-j1900 total:248  pass:214  dwarn:1   dfail:0   fail:1   skip:32
> > fi-byt-n2820 total:248  pass:210  dwarn:0   dfail:0   fail:1   skip:37
> > fi-hsw-4770  total:248  pass:224  dwarn:0   dfail:0   fail:0   skip:24
> > fi-hsw-4770r total:248  pass:224  dwarn:0   dfail:0   fail:0   skip:24
> > fi-ilk-650   total:248  pass:185  dwarn:0   dfail:0   fail:2   skip:61
> > fi-ivb-3520m total:248  pass:221  dwarn:0   dfail:0   fail:0   skip:27
> > fi-ivb-3770  total:248  pass:207  dwarn:0   dfail:0   fail:0   skip:41
> > fi-kbl-7200u total:248  pass:222  dwarn:0   dfail:0   fail:0   skip:26
> > fi-skl-6260u total:248  pass:232  dwarn:0   dfail:0   fail:0   skip:16
> > fi-skl-6700hqtotal:248  pass:223  dwarn:1   dfail:0   fail:0   skip:24
> > fi-skl-6700k total:248  pass:222  dwarn:1   dfail:0   fail:0   skip:25
> > fi-skl-6770hqtotal:248  pass:231  dwarn:1   dfail:0   fail:1   skip:15
> > fi-snb-2520m total:248  pass:211  dwarn:0   dfail:0   fail:0   skip:37
> > fi-snb-2600  total:248  pass:209  dwarn:0   dfail:0   fail:0   skip:39
> >
> > Results at /archive/results/CI_IGT_test/Patchwork_2652/
> >
> > f35ed31aea66b3230c366fcba5f3456ae2cb956e drm-intel-nightly:
> > 2016y-10m-10d-11h-28m-51s UTC integration manifest 401facf drm/i915:
> > Allocate intel_engine_cs structure only for the enabled engines
> >

Jani Saarinen



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

Re: [Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2

[Ville Syrjälä]

On Thu, Oct 13, 2016 at 11:04:19AM -0700, Dhinakaran Pandiyan wrote:
> According to BSpec, cdclk has to be not less than 432 MHz with DP audio
> enabled, port width x4, and link rate HBR2 (5.4 GHz)
> 
> Having a lower cdclk triggers pipe underruns, which then lead to displays
> continuously cycling off and on. This is essential for DP MST audio as the
> link is trained at HBR2 and 4 lanes by default.
> 
> This should fix https://bugs.freedesktop.org/show_bug.cgi?id=97907
> 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 47 
> +---
>  1 file changed, 43 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index cfcb03f..6a05183 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6603,14 +6603,43 @@ static int valleyview_modeset_calc_cdclk(struct 
> drm_atomic_state *state)
>   return 0;
>  }
>  
> +static bool cdclk_min_for_dp_audio(struct drm_atomic_state *state)
> +{
> +
> + struct drm_crtc_state *crtc_state;
> + struct drm_crtc *crtc;
> + int i;
> +
> + /* BSpec says "Do not use DisplayPort with CDCLK less than 432 MHz,
> +  * audio enabled, port width x4, and link rate HBR2 (5.4 GHz), or else
> +  * there may be audio corruption or screen corruption."
> +  */
> +
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + struct intel_crtc_state *pipe_config =
> + to_intel_crtc_state(crtc_state);
> +
> + return (intel_crtc_has_dp_encoder(pipe_config) &&
> + pipe_config->has_audio &&
> + pipe_config->port_clock == 54 &&
> + pipe_config->lane_count == 4);
> + }

That's not good enough on account of crtcs not part of the state
potentially needing the workaround as well. However, since we only do
this when there's a modeset, I think we'll be covered by the
connection_mutex, and so we should be able to peek at the current state
of all crtcs without grabbing the corresponding crtc locks.

So I think we'd be OK with something like:

WARN_ON(!locked(connection_mutex));

for_each_intel_crtc() {
/*
 * Peeking at the current state is safe since
 * we can only get here while holding the
 * connection_mutex.
 */
crtc_state = intel_get_existing_crtc_state();
if (!crtc_state)
crtc_state = to_intel_crtc_state(crtc->base.state);

...
}

The other option would be to track the min cdclk for each pipe in the
top level state I suppose. We already do that for the pixel rate
actually so that we can calculate the cdclk to begin with. Hmm. Maybe
we should just switch to tracking the min cdclk per pipe instead of the
pixel rate. Or did we need to the pixel rate itself for something else,
Maarten?

Or we could perhaps replace the pixel rate/pixclk tracking with the peek
approach entirely. Not quite sure. Would have to read the entire thing
through.

> +
> + return false;
> +}
> +
>  static int bxt_modeset_calc_cdclk(struct drm_atomic_state *state)
>  {
>   int max_pixclk = ilk_max_pixel_rate(state);
> + int cdclk, min_cdclk = 0;
>   struct intel_atomic_state *intel_state =
>   to_intel_atomic_state(state);
>  
> - intel_state->cdclk = intel_state->dev_cdclk =
> - bxt_calc_cdclk(max_pixclk);
> + if (cdclk_min_for_dp_audio(state))
> + min_cdclk = bxt_calc_cdclk(432000);
> +
> + cdclk = bxt_calc_cdclk(max_pixclk);
> + intel_state->cdclk = intel_state->dev_cdclk = max(min_cdclk, cdclk);
>  
>   if (!intel_state->active_crtcs)
>   intel_state->dev_cdclk = bxt_calc_cdclk(0);
> @@ -10374,7 +10403,10 @@ static int broadwell_modeset_calc_cdclk(struct 
> drm_atomic_state *state)
>   struct drm_i915_private *dev_priv = to_i915(state->dev);
>   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
>   int max_pixclk = ilk_max_pixel_rate(state);
> - int cdclk;
> + int cdclk, min_cdclk = 0;
> +
> + if (cdclk_min_for_dp_audio(state))
> + min_cdclk = broadwell_calc_cdclk(432000);
>  
>   /*
>* FIXME should also account for plane ratio
> @@ -10382,6 +10414,8 @@ static int broadwell_modeset_calc_cdclk(struct 
> drm_atomic_state *state)
>*/
>   cdclk = broadwell_calc_cdclk(max_pixclk);
>  
> + cdclk = max(min_cdclk, cdclk);
> +
>   if (cdclk > dev_priv->max_cdclk_freq) {
>   DRM_DEBUG_KMS("requested cdclk (%d kHz) exceeds max (%d kHz)\n",
> cdclk, dev_priv->max_cdclk_freq);
> @@ -10411,7 +10445,10 @@ static int skl_modeset_calc_cdclk(struct 
> drm_atomic_state *state)
>   struct drm_i915_private *dev_priv = to_i915(state->dev);
>   const int max_pixclk = ilk_max_pixel_rate(state);
>

Re: [Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2

[Jim Bride]

On Thu, Oct 13, 2016 at 11:04:19AM -0700, Dhinakaran Pandiyan wrote:
> According to BSpec, cdclk has to be not less than 432 MHz with DP audio
> enabled, port width x4, and link rate HBR2 (5.4 GHz)
> 
> Having a lower cdclk triggers pipe underruns, which then lead to displays
> continuously cycling off and on. This is essential for DP MST audio as the
> link is trained at HBR2 and 4 lanes by default.
> 
> This should fix https://bugs.freedesktop.org/show_bug.cgi?id=97907
> 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 47 
> +---
>  1 file changed, 43 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index cfcb03f..6a05183 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6603,14 +6603,43 @@ static int valleyview_modeset_calc_cdclk(struct 
> drm_atomic_state *state)
>   return 0;
>  }
>  
> +static bool cdclk_min_for_dp_audio(struct drm_atomic_state *state)
> +{
> +
> + struct drm_crtc_state *crtc_state;
> + struct drm_crtc *crtc;
> + int i;
> +
> + /* BSpec says "Do not use DisplayPort with CDCLK less than 432 MHz,
> +  * audio enabled, port width x4, and link rate HBR2 (5.4 GHz), or else
> +  * there may be audio corruption or screen corruption."
> +  */

It's probably worth mentioning that this limitation really only applies for
SKL (at least that I can see) and BXT A (which I don't think we even care
about anymore since it's not a production part.)  Were we seeing underruns
on non-SKL platforms that increasing CDCLK fixed?   In any event, I'd rather
see this only implemented for SKL (see BDW code below) unless we've empirically
noticed a similar problem on BDW (or the B-Spec says something about this and I
missed it.)

Jim


> +
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + struct intel_crtc_state *pipe_config =
> + to_intel_crtc_state(crtc_state);
> +
> + return (intel_crtc_has_dp_encoder(pipe_config) &&
> + pipe_config->has_audio &&
> + pipe_config->port_clock == 54 &&
> + pipe_config->lane_count == 4);
> + }
> +
> + return false;
> +}
> +
>  static int bxt_modeset_calc_cdclk(struct drm_atomic_state *state)
>  {
>   int max_pixclk = ilk_max_pixel_rate(state);
> + int cdclk, min_cdclk = 0;
>   struct intel_atomic_state *intel_state =
>   to_intel_atomic_state(state);
>  
> - intel_state->cdclk = intel_state->dev_cdclk =
> - bxt_calc_cdclk(max_pixclk);
> + if (cdclk_min_for_dp_audio(state))
> + min_cdclk = bxt_calc_cdclk(432000);
> +
> + cdclk = bxt_calc_cdclk(max_pixclk);
> + intel_state->cdclk = intel_state->dev_cdclk = max(min_cdclk, cdclk);
>  
>   if (!intel_state->active_crtcs)
>   intel_state->dev_cdclk = bxt_calc_cdclk(0);
> @@ -10374,7 +10403,10 @@ static int broadwell_modeset_calc_cdclk(struct 
> drm_atomic_state *state)
>   struct drm_i915_private *dev_priv = to_i915(state->dev);
>   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
>   int max_pixclk = ilk_max_pixel_rate(state);
> - int cdclk;
> + int cdclk, min_cdclk = 0;
> +
> + if (cdclk_min_for_dp_audio(state))
> + min_cdclk = broadwell_calc_cdclk(432000);
>  
>   /*
>* FIXME should also account for plane ratio
> @@ -10382,6 +10414,8 @@ static int broadwell_modeset_calc_cdclk(struct 
> drm_atomic_state *state)
>*/
>   cdclk = broadwell_calc_cdclk(max_pixclk);
>  
> + cdclk = max(min_cdclk, cdclk);
> +
>   if (cdclk > dev_priv->max_cdclk_freq) {
>   DRM_DEBUG_KMS("requested cdclk (%d kHz) exceeds max (%d kHz)\n",
> cdclk, dev_priv->max_cdclk_freq);
> @@ -10411,7 +10445,10 @@ static int skl_modeset_calc_cdclk(struct 
> drm_atomic_state *state)
>   struct drm_i915_private *dev_priv = to_i915(state->dev);
>   const int max_pixclk = ilk_max_pixel_rate(state);
>   int vco = intel_state->cdclk_pll_vco;
> - int cdclk;
> + int cdclk, min_cdclk = 0;
> +
> + if (cdclk_min_for_dp_audio(state))
> + min_cdclk = skl_calc_cdclk(432000, vco);
>  
>   /*
>* FIXME should also account for plane ratio
> @@ -10419,6 +10456,8 @@ static int skl_modeset_calc_cdclk(struct 
> drm_atomic_state *state)
>*/
>   cdclk = skl_calc_cdclk(max_pixclk, vco);
>  
> + cdclk = max(min_cdclk, cdclk);
> +
>   /*
>* FIXME move the cdclk caclulation to
>* compute_config() so we can fail gracegully.
> -- 
> 2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Respect alternate_ddc_pin for all DDI ports

[Ville Syrjälä]

On Thu, Oct 13, 2016 at 11:06:55AM -0700, Jim Bride wrote:
> On Tue, Oct 11, 2016 at 08:52:46PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > The VBT provides the platform a way to mix and match the DDI ports vs.
> > GMBUS pins. Currently we only trust the VBT for DDI E, which I suppose
> > has no standard GMBUS pin assignment. However, there are machines out
> > there that use a non-standard mapping for the other ports as well.
> > Let's start trusting the VBT on this one for all ports on DDI platforms.
> > 
> > I've structured the code such that other platforms could easily start
> > using this as well, by simply filling in the ddi_port_info. IIRC there
> > may be CHV system that might actually need this.
> > 
> > v2: Include a commit message, include a debug message during init
> > 
> > Cc: sta...@vger.kernel.org
> > Cc: Maarten Maathuis 
> > Tested-by: Maarten Maatt show huis 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97877
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_hdmi.c | 84 
> > ++-
> >  1 file changed, 48 insertions(+), 36 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index 8d46f5836746..9ca86e901fc8 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -1799,6 +1799,50 @@ intel_hdmi_add_properties(struct intel_hdmi 
> > *intel_hdmi, struct drm_connector *c
> > intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> >  }
> >  
> > +static u8 intel_hdmi_ddc_pin(struct drm_i915_private *dev_priv,
> > +enum port port)
> > +{
> > +   const struct ddi_vbt_port_info *info =
> > +   _priv->vbt.ddi_port_info[port];
> > +   u8 ddc_pin;
> > +
> > +   if (info->alternate_ddc_pin) {
> > +   DRM_DEBUG_KMS("Using DDC pin 0x%x for port %c (VBT)\n",
> > + info->alternate_ddc_pin, port_name(port));
> > +   return info->alternate_ddc_pin;
> > +   }
> > +
> > +   switch (port) {
> > +   case PORT_B:
> > +   if (IS_BROXTON(dev_priv))
> > +   ddc_pin = GMBUS_PIN_1_BXT;
> > +   else
> > +   ddc_pin = GMBUS_PIN_DPB;
> > +   break;
> > +   case PORT_C:
> > +   if (IS_BROXTON(dev_priv))
> > +   ddc_pin = GMBUS_PIN_2_BXT;
> > +   else
> > +   ddc_pin = GMBUS_PIN_DPC;
> > +   break;
> > +   case PORT_D:
> > +   if (IS_CHERRYVIEW(dev_priv))
> > +   ddc_pin = GMBUS_PIN_DPD_CHV;
> > +   else
> > +   ddc_pin = GMBUS_PIN_DPD;
> 
> In the code removed below there's a specific case covering Broxton that
> isn't accounted for here.  Are we sure that we don't need that logic here?

Yeah, BXT doesn't have port D.

I guess we could split this up into a few platform specific functions that
could then have the MISSING_CASE() for the impossible ports. A bit like
the AUX ctl/data register setup functions we have. Do pople want that
level of paranoia here?

> 
> Jim
> 
> > +   break;
> > +   default:
> > +   MISSING_CASE(port);
> > +   ddc_pin = GMBUS_PIN_DPB;
> > +   break;
> > +   }
> > +
> > +   DRM_DEBUG_KMS("Using DDC pin 0x%x for port %c (platform default)\n",
> > + ddc_pin, port_name(port));
> > +
> > +   return ddc_pin;
> > +}
> > +
> >  void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port,
> >struct intel_connector *intel_connector)
> >  {
> > @@ -1808,7 +1852,6 @@ void intel_hdmi_init_connector(struct 
> > intel_digital_port *intel_dig_port,
> > struct drm_device *dev = intel_encoder->base.dev;
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > enum port port = intel_dig_port->port;
> > -   uint8_t alternate_ddc_pin;
> >  
> > DRM_DEBUG_KMS("Adding HDMI connector on port %c\n",
> >   port_name(port));
> > @@ -1826,12 +1869,10 @@ void intel_hdmi_init_connector(struct 
> > intel_digital_port *intel_dig_port,
> > connector->doublescan_allowed = 0;
> > connector->stereo_allowed = 1;
> >  
> > +   intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port);
> > +
> > switch (port) {
> > case PORT_B:
> > -   if (IS_BROXTON(dev_priv))
> > -   intel_hdmi->ddc_bus = GMBUS_PIN_1_BXT;
> > -   else
> > -   intel_hdmi->ddc_bus = GMBUS_PIN_DPB;
> > /*
> >  * On BXT A0/A1, sw needs to activate DDIA HPD logic and
> >  * interrupts to check the external panel connection.
> > @@ -1842,46 +1883,17 @@ void intel_hdmi_init_connector(struct 
> > intel_digital_port *intel_dig_port,
> > intel_encoder->hpd_pin = HPD_PORT_B;
> > 

Re: [Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2

[Paulo Zanoni]

Em Qui, 2016-10-13 às 11:04 -0700, Dhinakaran Pandiyan escreveu:
> According to BSpec, cdclk has to be not less than 432 MHz with DP
> audio
> enabled, port width x4, and link rate HBR2 (5.4 GHz)

This is just for pre-production hardware, and we don't implement
workarounds for pre-prod.


A quick research seems to indicate that our CDCLK must be at least
twice the frequency of the audio BCLK. Maybe this is what we need to
investigate/check?

Anyway, it looks like we're getting closer to the final bug fix.

> 
> Having a lower cdclk triggers pipe underruns, which then lead to
> displays
> continuously cycling off and on. This is essential for DP MST audio
> as the
> link is trained at HBR2 and 4 lanes by default.
> 
> This should fix https://bugs.freedesktop.org/show_bug.cgi?id=97907

Please use the "Bugzilla:" tag since there are some scripts and robots
that parse it and do stuff with it.


> 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 47
> +---
>  1 file changed, 43 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index cfcb03f..6a05183 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6603,14 +6603,43 @@ static int
> valleyview_modeset_calc_cdclk(struct drm_atomic_state *state)
>   return 0;
>  }
>  
> +static bool cdclk_min_for_dp_audio(struct drm_atomic_state *state)
> +{
> +
> + struct drm_crtc_state *crtc_state;
> + struct drm_crtc *crtc;
> + int i;
> +
> + /* BSpec says "Do not use DisplayPort with CDCLK less than
> 432 MHz,
> +  * audio enabled, port width x4, and link rate HBR2 (5.4
> GHz), or else
> +  * there may be audio corruption or screen corruption."
> +  */
> +
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + struct intel_crtc_state *pipe_config =
> + to_intel_crtc_state(crtc_state);
> +
> + return (intel_crtc_has_dp_encoder(pipe_config) &&
> + pipe_config->has_audio &&
> + pipe_config->port_clock == 54 &&
> + pipe_config->lane_count == 4);
> + }
> +
> + return false;
> +}
> +
>  static int bxt_modeset_calc_cdclk(struct drm_atomic_state *state)
>  {
>   int max_pixclk = ilk_max_pixel_rate(state);
> + int cdclk, min_cdclk = 0;
>   struct intel_atomic_state *intel_state =
>   to_intel_atomic_state(state);
>  
> - intel_state->cdclk = intel_state->dev_cdclk =
> - bxt_calc_cdclk(max_pixclk);
> + if (cdclk_min_for_dp_audio(state))
> + min_cdclk = bxt_calc_cdclk(432000);
> +
> + cdclk = bxt_calc_cdclk(max_pixclk);
> + intel_state->cdclk = intel_state->dev_cdclk = max(min_cdclk,
> cdclk);
>  
>   if (!intel_state->active_crtcs)
>   intel_state->dev_cdclk = bxt_calc_cdclk(0);
> @@ -10374,7 +10403,10 @@ static int
> broadwell_modeset_calc_cdclk(struct drm_atomic_state *state)
>   struct drm_i915_private *dev_priv = to_i915(state->dev);
>   struct intel_atomic_state *intel_state =
> to_intel_atomic_state(state);
>   int max_pixclk = ilk_max_pixel_rate(state);
> - int cdclk;
> + int cdclk, min_cdclk = 0;
> +
> + if (cdclk_min_for_dp_audio(state))
> + min_cdclk = broadwell_calc_cdclk(432000);
>  
>   /*
>    * FIXME should also account for plane ratio
> @@ -10382,6 +10414,8 @@ static int
> broadwell_modeset_calc_cdclk(struct drm_atomic_state *state)
>    */
>   cdclk = broadwell_calc_cdclk(max_pixclk);
>  
> + cdclk = max(min_cdclk, cdclk);
> +
>   if (cdclk > dev_priv->max_cdclk_freq) {
>   DRM_DEBUG_KMS("requested cdclk (%d kHz) exceeds max
> (%d kHz)\n",
>     cdclk, dev_priv->max_cdclk_freq);
> @@ -10411,7 +10445,10 @@ static int skl_modeset_calc_cdclk(struct
> drm_atomic_state *state)
>   struct drm_i915_private *dev_priv = to_i915(state->dev);
>   const int max_pixclk = ilk_max_pixel_rate(state);
>   int vco = intel_state->cdclk_pll_vco;
> - int cdclk;
> + int cdclk, min_cdclk = 0;
> +
> + if (cdclk_min_for_dp_audio(state))
> + min_cdclk = skl_calc_cdclk(432000, vco);
>  
>   /*
>    * FIXME should also account for plane ratio
> @@ -10419,6 +10456,8 @@ static int skl_modeset_calc_cdclk(struct
> drm_atomic_state *state)
>    */
>   cdclk = skl_calc_cdclk(max_pixclk, vco);
>  
> + cdclk = max(min_cdclk, cdclk);
> +
>   /*
>    * FIXME move the cdclk caclulation to
>    * compute_config() so we can fail gracegully.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Fix whitespace issues

[Jim Bride]

On Tue, Oct 11, 2016 at 08:52:48PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Fix the poorly indented port parameters to the aux ctl and data
> reg functions. This was fallout from the s/i915_mmio_reg_t/i915_reg_t/
> that happened during the review of commit f0f59a00a1c9 ("drm/i915:
> Type safe register read/write")
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Jim Bride 

> ---
>  drivers/gpu/drm/i915/intel_dp.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index b0753b272101..25cde7356b59 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1147,7 +1147,7 @@ static enum port intel_aux_port(struct drm_i915_private 
> *dev_priv,
>  }
>  
>  static i915_reg_t g4x_aux_ctl_reg(struct drm_i915_private *dev_priv,
> -enum port port)
> +   enum port port)
>  {
>   switch (port) {
>   case PORT_B:
> @@ -1161,7 +1161,7 @@ static i915_reg_t g4x_aux_ctl_reg(struct 
> drm_i915_private *dev_priv,
>  }
>  
>  static i915_reg_t g4x_aux_data_reg(struct drm_i915_private *dev_priv,
> - enum port port, int index)
> +enum port port, int index)
>  {
>   switch (port) {
>   case PORT_B:
> @@ -1175,7 +1175,7 @@ static i915_reg_t g4x_aux_data_reg(struct 
> drm_i915_private *dev_priv,
>  }
>  
>  static i915_reg_t ilk_aux_ctl_reg(struct drm_i915_private *dev_priv,
> -enum port port)
> +   enum port port)
>  {
>   switch (port) {
>   case PORT_A:
> @@ -1191,7 +1191,7 @@ static i915_reg_t ilk_aux_ctl_reg(struct 
> drm_i915_private *dev_priv,
>  }
>  
>  static i915_reg_t ilk_aux_data_reg(struct drm_i915_private *dev_priv,
> - enum port port, int index)
> +enum port port, int index)
>  {
>   switch (port) {
>   case PORT_A:
> @@ -1207,7 +1207,7 @@ static i915_reg_t ilk_aux_data_reg(struct 
> drm_i915_private *dev_priv,
>  }
>  
>  static i915_reg_t skl_aux_ctl_reg(struct drm_i915_private *dev_priv,
> -enum port port)
> +   enum port port)
>  {
>   switch (port) {
>   case PORT_A:
> @@ -1222,7 +1222,7 @@ static i915_reg_t skl_aux_ctl_reg(struct 
> drm_i915_private *dev_priv,
>  }
>  
>  static i915_reg_t skl_aux_data_reg(struct drm_i915_private *dev_priv,
> - enum port port, int index)
> +enum port port, int index)
>  {
>   switch (port) {
>   case PORT_A:
> @@ -1237,7 +1237,7 @@ static i915_reg_t skl_aux_data_reg(struct 
> drm_i915_private *dev_priv,
>  }
>  
>  static i915_reg_t intel_aux_ctl_reg(struct drm_i915_private *dev_priv,
> -  enum port port)
> + enum port port)
>  {
>   if (INTEL_INFO(dev_priv)->gen >= 9)
>   return skl_aux_ctl_reg(dev_priv, port);
> @@ -1248,7 +1248,7 @@ static i915_reg_t intel_aux_ctl_reg(struct 
> drm_i915_private *dev_priv,
>  }
>  
>  static i915_reg_t intel_aux_data_reg(struct drm_i915_private *dev_priv,
> -   enum port port, int index)
> +  enum port port, int index)
>  {
>   if (INTEL_INFO(dev_priv)->gen >= 9)
>   return skl_aux_data_reg(dev_priv, port, index);
> -- 
> 2.7.4
> 
> ___
> 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 3/4] drm/i915: Clean up DDI DDC/AUX CH sanitation

[Jim Bride]

On Tue, Oct 11, 2016 at 08:52:47PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Now that we use the AUX and GMBUS assignment from VBT for all ports,
> let's clean up the sanitization of the port information a bit.
> Previosuly we only did this for port E, and only complained about a
> non-standard assignment for the other ports. But as we know that
> non-standard assignments are a fact of life, let's expand the
> sanitization to all the ports.
> 
> v2: Include a commit message, fix up the comments a bit
> 
> Cc: sta...@vger.kernel.org
> Cc: Maarten Maathuis 
> Tested-by: Maarten Maathuis 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=97877
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Jim Bride 

> ---
>  drivers/gpu/drm/i915/intel_bios.c | 116 
> +++---
>  1 file changed, 71 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index 83667e8cdd6b..6d1ffa815e97 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1035,6 +1035,71 @@ static u8 translate_iboost(u8 val)
>   return mapping[val];
>  }
>  
> +static void sanitize_ddc_pin(struct drm_i915_private *dev_priv,
> +  enum port port)
> +{
> + const struct ddi_vbt_port_info *info =
> + _priv->vbt.ddi_port_info[port];
> + enum port p;
> +
> + for_each_port_masked(p, (1 << port) - 1) {
> + struct ddi_vbt_port_info *i = _priv->vbt.ddi_port_info[p];
> +
> + if (info->alternate_ddc_pin != i->alternate_ddc_pin)
> + continue;
> +
> + DRM_DEBUG_KMS("port %c trying to use the same DDC pin (0x%x) as 
> port %c, "
> +   "disabling port %c DVI/HDMI support\n",
> +   port_name(p), i->alternate_ddc_pin,
> +   port_name(port), port_name(p));
> +
> + /*
> +  * If we have multiple ports supposedly sharing the
> +  * pin, then dvi/hdmi couldn't exist on the shared
> +  * port. Otherwise they share the same ddc bin and
> +  * system couldn't communicate with them separately.
> +  *
> +  * Due to parsing the ports in alphabetical order,
> +  * a higher port will always clobber a lower one.
> +  */
> + i->supports_dvi = false;
> + i->supports_hdmi = false;
> + i->alternate_ddc_pin = 0;
> + }
> +}
> +
> +static void sanitize_aux_ch(struct drm_i915_private *dev_priv,
> + enum port port)
> +{
> + const struct ddi_vbt_port_info *info =
> + _priv->vbt.ddi_port_info[port];
> + enum port p;
> +
> + for_each_port_masked(p, (1 << port) - 1) {
> + struct ddi_vbt_port_info *i = _priv->vbt.ddi_port_info[p];
> +
> + if (info->alternate_aux_channel != i->alternate_aux_channel)
> + continue;
> +
> + DRM_DEBUG_KMS("port %c trying to use the same AUX CH (0x%x) as 
> port %c, "
> +   "disabling port %c DP support\n",
> +   port_name(p), i->alternate_aux_channel,
> +   port_name(port), port_name(p));
> +
> + /*
> +  * If we have multiple ports supposedlt sharing the
> +  * aux channel, then DP couldn't exist on the shared
> +  * port. Otherwise they share the same aux channel
> +  * and system couldn't communicate with them separately.
> +  *
> +  * Due to parsing the ports in alphabetical order,
> +  * a higher port will always clobber a lower one.
> +  */
> + i->supports_dp = false;
> + i->alternate_aux_channel = 0;
> + }
> +}
> +
>  static void parse_ddi_port(struct drm_i915_private *dev_priv, enum port port,
>  const struct bdb_header *bdb)
>  {
> @@ -1109,54 +1174,15 @@ static void parse_ddi_port(struct drm_i915_private 
> *dev_priv, enum port port,
>   DRM_DEBUG_KMS("Port %c is internal DP\n", port_name(port));
>  
>   if (is_dvi) {
> - if (port == PORT_E) {
> - info->alternate_ddc_pin = ddc_pin;
> - /* if DDIE share ddc pin with other port, then
> -  * dvi/hdmi couldn't exist on the shared port.
> -  * Otherwise they share the same ddc bin and system
> -  * couldn't communicate with them seperately. */
> - if (ddc_pin == DDC_PIN_B) {
> - 
> dev_priv->vbt.ddi_port_info[PORT_B].supports_dvi = 0;
> - 
> 

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Respect alternate_ddc_pin for all DDI ports

[Jim Bride]

On Tue, Oct 11, 2016 at 08:52:46PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> The VBT provides the platform a way to mix and match the DDI ports vs.
> GMBUS pins. Currently we only trust the VBT for DDI E, which I suppose
> has no standard GMBUS pin assignment. However, there are machines out
> there that use a non-standard mapping for the other ports as well.
> Let's start trusting the VBT on this one for all ports on DDI platforms.
> 
> I've structured the code such that other platforms could easily start
> using this as well, by simply filling in the ddi_port_info. IIRC there
> may be CHV system that might actually need this.
> 
> v2: Include a commit message, include a debug message during init
> 
> Cc: sta...@vger.kernel.org
> Cc: Maarten Maathuis 
> Tested-by: Maarten Maatt show huis 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97877
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_hdmi.c | 84 
> ++-
>  1 file changed, 48 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 8d46f5836746..9ca86e901fc8 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1799,6 +1799,50 @@ intel_hdmi_add_properties(struct intel_hdmi 
> *intel_hdmi, struct drm_connector *c
>   intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
>  }
>  
> +static u8 intel_hdmi_ddc_pin(struct drm_i915_private *dev_priv,
> +  enum port port)
> +{
> + const struct ddi_vbt_port_info *info =
> + _priv->vbt.ddi_port_info[port];
> + u8 ddc_pin;
> +
> + if (info->alternate_ddc_pin) {
> + DRM_DEBUG_KMS("Using DDC pin 0x%x for port %c (VBT)\n",
> +   info->alternate_ddc_pin, port_name(port));
> + return info->alternate_ddc_pin;
> + }
> +
> + switch (port) {
> + case PORT_B:
> + if (IS_BROXTON(dev_priv))
> + ddc_pin = GMBUS_PIN_1_BXT;
> + else
> + ddc_pin = GMBUS_PIN_DPB;
> + break;
> + case PORT_C:
> + if (IS_BROXTON(dev_priv))
> + ddc_pin = GMBUS_PIN_2_BXT;
> + else
> + ddc_pin = GMBUS_PIN_DPC;
> + break;
> + case PORT_D:
> + if (IS_CHERRYVIEW(dev_priv))
> + ddc_pin = GMBUS_PIN_DPD_CHV;
> + else
> + ddc_pin = GMBUS_PIN_DPD;

In the code removed below there's a specific case covering Broxton that
isn't accounted for here.  Are we sure that we don't need that logic here?

Jim

> + break;
> + default:
> + MISSING_CASE(port);
> + ddc_pin = GMBUS_PIN_DPB;
> + break;
> + }
> +
> + DRM_DEBUG_KMS("Using DDC pin 0x%x for port %c (platform default)\n",
> +   ddc_pin, port_name(port));
> +
> + return ddc_pin;
> +}
> +
>  void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port,
>  struct intel_connector *intel_connector)
>  {
> @@ -1808,7 +1852,6 @@ void intel_hdmi_init_connector(struct 
> intel_digital_port *intel_dig_port,
>   struct drm_device *dev = intel_encoder->base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   enum port port = intel_dig_port->port;
> - uint8_t alternate_ddc_pin;
>  
>   DRM_DEBUG_KMS("Adding HDMI connector on port %c\n",
> port_name(port));
> @@ -1826,12 +1869,10 @@ void intel_hdmi_init_connector(struct 
> intel_digital_port *intel_dig_port,
>   connector->doublescan_allowed = 0;
>   connector->stereo_allowed = 1;
>  
> + intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port);
> +
>   switch (port) {
>   case PORT_B:
> - if (IS_BROXTON(dev_priv))
> - intel_hdmi->ddc_bus = GMBUS_PIN_1_BXT;
> - else
> - intel_hdmi->ddc_bus = GMBUS_PIN_DPB;
>   /*
>* On BXT A0/A1, sw needs to activate DDIA HPD logic and
>* interrupts to check the external panel connection.
> @@ -1842,46 +1883,17 @@ void intel_hdmi_init_connector(struct 
> intel_digital_port *intel_dig_port,
>   intel_encoder->hpd_pin = HPD_PORT_B;
>   break;
>   case PORT_C:
> - if (IS_BROXTON(dev_priv))
> - intel_hdmi->ddc_bus = GMBUS_PIN_2_BXT;
> - else
> - intel_hdmi->ddc_bus = GMBUS_PIN_DPC;
>   intel_encoder->hpd_pin = HPD_PORT_C;
>   break;
>   case PORT_D:
> - if (WARN_ON(IS_BROXTON(dev_priv)))
> - intel_hdmi->ddc_bus = GMBUS_PIN_DISABLED;
> - else if 

Re: [Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)

[Paul Bolle]

[Adding Matt]

On Wed, 2016-10-12 at 14:08 +0300, Joonas Lahtinen wrote:
> Bisecting the offending commit between v4.8 and v4.8.1 would be a good
> start.

0) Why use a personal notebook when one can just post any half baked
idea to lkml?

1) I stumbled on https://bugzilla.redhat.com/show_bug.cgi?id=1361357 (s
ame hardware, rather similar trace).

2) That report was about the first Fedora (rawhide) kernel release
after this commit http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/co
mmit/?h=f25=7d2c2f2d91793b5da452bee9bea4fa32051c8608 ("Bring in
patch-series from drm-next to fix skl_update_other_pipe_wm issues").

3) That seventeen part series ended up in v4.8. The last commit of that
series is commit 5b483747a925 ("drm/i915: Remove wm_config from
dev_priv/intel_atomic_state").

4) So, with a little bit of luck, my bisect might only need to look at
those seventeen commits. Still, it will probably be next week before I
have a day or two to actually perform that bisect.

To be continued,


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

[Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2

[Dhinakaran Pandiyan]

According to BSpec, cdclk has to be not less than 432 MHz with DP audio
enabled, port width x4, and link rate HBR2 (5.4 GHz)

Having a lower cdclk triggers pipe underruns, which then lead to displays
continuously cycling off and on. This is essential for DP MST audio as the
link is trained at HBR2 and 4 lanes by default.

This should fix https://bugs.freedesktop.org/show_bug.cgi?id=97907

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_display.c | 47 +---
 1 file changed, 43 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index cfcb03f..6a05183 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6603,14 +6603,43 @@ static int valleyview_modeset_calc_cdclk(struct 
drm_atomic_state *state)
return 0;
 }
 
+static bool cdclk_min_for_dp_audio(struct drm_atomic_state *state)
+{
+
+   struct drm_crtc_state *crtc_state;
+   struct drm_crtc *crtc;
+   int i;
+
+   /* BSpec says "Do not use DisplayPort with CDCLK less than 432 MHz,
+* audio enabled, port width x4, and link rate HBR2 (5.4 GHz), or else
+* there may be audio corruption or screen corruption."
+*/
+
+   for_each_crtc_in_state(state, crtc, crtc_state, i) {
+   struct intel_crtc_state *pipe_config =
+   to_intel_crtc_state(crtc_state);
+
+   return (intel_crtc_has_dp_encoder(pipe_config) &&
+   pipe_config->has_audio &&
+   pipe_config->port_clock == 54 &&
+   pipe_config->lane_count == 4);
+   }
+
+   return false;
+}
+
 static int bxt_modeset_calc_cdclk(struct drm_atomic_state *state)
 {
int max_pixclk = ilk_max_pixel_rate(state);
+   int cdclk, min_cdclk = 0;
struct intel_atomic_state *intel_state =
to_intel_atomic_state(state);
 
-   intel_state->cdclk = intel_state->dev_cdclk =
-   bxt_calc_cdclk(max_pixclk);
+   if (cdclk_min_for_dp_audio(state))
+   min_cdclk = bxt_calc_cdclk(432000);
+
+   cdclk = bxt_calc_cdclk(max_pixclk);
+   intel_state->cdclk = intel_state->dev_cdclk = max(min_cdclk, cdclk);
 
if (!intel_state->active_crtcs)
intel_state->dev_cdclk = bxt_calc_cdclk(0);
@@ -10374,7 +10403,10 @@ static int broadwell_modeset_calc_cdclk(struct 
drm_atomic_state *state)
struct drm_i915_private *dev_priv = to_i915(state->dev);
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
int max_pixclk = ilk_max_pixel_rate(state);
-   int cdclk;
+   int cdclk, min_cdclk = 0;
+
+   if (cdclk_min_for_dp_audio(state))
+   min_cdclk = broadwell_calc_cdclk(432000);
 
/*
 * FIXME should also account for plane ratio
@@ -10382,6 +10414,8 @@ static int broadwell_modeset_calc_cdclk(struct 
drm_atomic_state *state)
 */
cdclk = broadwell_calc_cdclk(max_pixclk);
 
+   cdclk = max(min_cdclk, cdclk);
+
if (cdclk > dev_priv->max_cdclk_freq) {
DRM_DEBUG_KMS("requested cdclk (%d kHz) exceeds max (%d kHz)\n",
  cdclk, dev_priv->max_cdclk_freq);
@@ -10411,7 +10445,10 @@ static int skl_modeset_calc_cdclk(struct 
drm_atomic_state *state)
struct drm_i915_private *dev_priv = to_i915(state->dev);
const int max_pixclk = ilk_max_pixel_rate(state);
int vco = intel_state->cdclk_pll_vco;
-   int cdclk;
+   int cdclk, min_cdclk = 0;
+
+   if (cdclk_min_for_dp_audio(state))
+   min_cdclk = skl_calc_cdclk(432000, vco);
 
/*
 * FIXME should also account for plane ratio
@@ -10419,6 +10456,8 @@ static int skl_modeset_calc_cdclk(struct 
drm_atomic_state *state)
 */
cdclk = skl_calc_cdclk(max_pixclk, vco);
 
+   cdclk = max(min_cdclk, cdclk);
+
/*
 * FIXME move the cdclk caclulation to
 * compute_config() so we can fail gracegully.
-- 
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/4] drm/i915: Respect alternate_aux_channel for all DDI ports

[Jim Bride]

On Tue, Oct 11, 2016 at 08:52:45PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> The VBT provides the platform a way to mix and match the DDI ports vs.
> AUX channels. Currently we only trust the VBT for DDI E, which has no
> corresponding AUX channel of its own. However it is possible that some
> board might use some non-standard DDI vs. AUX port routing even for
> the other ports. Perhaps for signal routing reasons or something,
> So let's generalize this and trust the VBT for all ports.
> 
> For now we'll limit this to DDI platforms, as we trust the VBT a bit
> more there anyway when it comes to the DDI ports. I've structured
> the code in a way that would allow us to easily expand this to
> other platforms as well, by simply filling in the ddi_port_info.
> 
> v2: Drop whitespace changes, keep MISSING_CASE() for unknown
> aux ch assignment, include a commit message, include debug
> message during init
> 
> Cc: sta...@vger.kernel.org
> Cc: Maarten Maathuis 
> Tested-by: Maarten Maathuis 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=97877
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Jim Bride 

> ---
>  drivers/gpu/drm/i915/intel_dp.c | 71 
> +++--
>  1 file changed, 40 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 5992093e1814..b0753b272101 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1108,6 +1108,44 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct 
> drm_dp_aux_msg *msg)
>   return ret;
>  }
>  
> +static enum port intel_aux_port(struct drm_i915_private *dev_priv,
> + enum port port)
> +{
> + const struct ddi_vbt_port_info *info =
> + _priv->vbt.ddi_port_info[port];
> + enum port aux_port;
> +
> + if (!info->alternate_aux_channel) {
> + DRM_DEBUG_KMS("using AUX %c for port %c (platform default)\n",
> +   port_name(port), port_name(port));
> + return port;
> + }
> +
> + switch (info->alternate_aux_channel) {
> + case DP_AUX_A:
> + aux_port = PORT_A;
> + break;
> + case DP_AUX_B:
> + aux_port = PORT_B;
> + break;
> + case DP_AUX_C:
> + aux_port = PORT_C;
> + break;
> + case DP_AUX_D:
> + aux_port = PORT_D;
> + break;
> + default:
> + MISSING_CASE(info->alternate_aux_channel);
> + aux_port = PORT_A;
> + break;
> + }
> +
> + DRM_DEBUG_KMS("using AUX %c for port %c (VBT)\n",
> +   port_name(aux_port), port_name(port));
> +
> + return aux_port;
> +}
> +
>  static i915_reg_t g4x_aux_ctl_reg(struct drm_i915_private *dev_priv,
>  enum port port)
>  {
> @@ -1168,36 +1206,9 @@ static i915_reg_t ilk_aux_data_reg(struct 
> drm_i915_private *dev_priv,
>   }
>  }
>  
> -/*
> - * On SKL we don't have Aux for port E so we rely
> - * on VBT to set a proper alternate aux channel.
> - */
> -static enum port skl_porte_aux_port(struct drm_i915_private *dev_priv)
> -{
> - const struct ddi_vbt_port_info *info =
> - _priv->vbt.ddi_port_info[PORT_E];
> -
> - switch (info->alternate_aux_channel) {
> - case DP_AUX_A:
> - return PORT_A;
> - case DP_AUX_B:
> - return PORT_B;
> - case DP_AUX_C:
> - return PORT_C;
> - case DP_AUX_D:
> - return PORT_D;
> - default:
> - MISSING_CASE(info->alternate_aux_channel);
> - return PORT_A;
> - }
> -}
> -
>  static i915_reg_t skl_aux_ctl_reg(struct drm_i915_private *dev_priv,
>  enum port port)
>  {
> - if (port == PORT_E)
> - port = skl_porte_aux_port(dev_priv);
> -
>   switch (port) {
>   case PORT_A:
>   case PORT_B:
> @@ -1213,9 +1224,6 @@ static i915_reg_t skl_aux_ctl_reg(struct 
> drm_i915_private *dev_priv,
>  static i915_reg_t skl_aux_data_reg(struct drm_i915_private *dev_priv,
>   enum port port, int index)
>  {
> - if (port == PORT_E)
> - port = skl_porte_aux_port(dev_priv);
> -
>   switch (port) {
>   case PORT_A:
>   case PORT_B:
> @@ -1253,7 +1261,8 @@ static i915_reg_t intel_aux_data_reg(struct 
> drm_i915_private *dev_priv,
>  static void intel_aux_reg_init(struct intel_dp *intel_dp)
>  {
>   struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
> - enum port port = dp_to_dig_port(intel_dp)->port;
> + enum port port = intel_aux_port(dev_priv,
> + dp_to_dig_port(intel_dp)->port);
>   int i;
>  
>   

Re: [Intel-gfx] [PATCH 4/8] drm/i915/huc: Add debugfs for HuC loading status check

[Jeff McGee]

Reviewed-by: Jeff McGee 

On Mon, Oct 03, 2016 at 11:42:58AM -0700, Anusha Srivatsa wrote:
> From: Peter Antoine 
> 
> Add debugfs entry for HuC loading status check.
> 
> v2: rebase on-top of drm-intel-nightly.
> v3: rebased again.
> v7: rebased.
> v8: rebased.
> 
> 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/i915_debugfs.c | 31 +++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 44258a8..7bd0e23 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2413,6 +2413,36 @@ static int i915_llc(struct seq_file *m, void *data)
>   return 0;
>  }
>  
> +static int i915_huc_load_status_info(struct seq_file *m, void *data)
> +{
> + struct drm_i915_private *dev_priv = node_to_i915(m->private);
> + struct intel_uc_fw *huc_fw = _priv->huc.huc_fw;
> +
> + if (!HAS_HUC_UCODE(dev_priv))
> + return 0;
> +
> + seq_puts(m, "HuC firmware status:\n");
> + seq_printf(m, "\tpath: %s\n", huc_fw->uc_fw_path);
> + seq_printf(m, "\tfetch: %s\n",
> + intel_uc_fw_status_repr(huc_fw->fetch_status));
> + seq_printf(m, "\tload: %s\n",
> + intel_uc_fw_status_repr(huc_fw->load_status));
> + seq_printf(m, "\tversion wanted: %d.%d\n",
> + huc_fw->major_ver_wanted, huc_fw->minor_ver_wanted);
> + seq_printf(m, "\tversion found: %d.%d\n",
> + huc_fw->major_ver_found, huc_fw->minor_ver_found);
> + seq_printf(m, "\theader: offset is %d; size = %d\n",
> + huc_fw->header_offset, huc_fw->header_size);
> + seq_printf(m, "\tuCode: offset is %d; size = %d\n",
> + huc_fw->ucode_offset, huc_fw->ucode_size);
> + seq_printf(m, "\tRSA: offset is %d; size = %d\n",
> + huc_fw->rsa_offset, huc_fw->rsa_size);
> +
> + seq_printf(m, "\nHuC status 0x%08x:\n", I915_READ(HUC_STATUS2));
> +
> + return 0;
> +}
> +
>  static int i915_guc_load_status_info(struct seq_file *m, void *data)
>  {
>   struct drm_i915_private *dev_priv = node_to_i915(m->private);
> @@ -4427,6 +4457,7 @@ static const struct drm_info_list i915_debugfs_list[] = 
> {
>   {"i915_guc_info", i915_guc_info, 0},
>   {"i915_guc_load_status", i915_guc_load_status_info, 0},
>   {"i915_guc_log_dump", i915_guc_log_dump, 0},
> + {"i915_huc_load_status", i915_huc_load_status_info, 0},
>   {"i915_frequency_info", i915_frequency_info, 0},
>   {"i915_hangcheck_info", i915_hangcheck_info, 0},
>   {"i915_drpc_info", i915_drpc_info, 0},
> -- 
> 2.7.4
> 
> ___
> 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 3/8] drm/i915/huc: Add HuC fw loading support

[Jeff McGee]

On Mon, Oct 03, 2016 at 11:42:57AM -0700, 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.
> 
> 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.c |   3 +
>  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|  44 ++
>  drivers/gpu/drm/i915/intel_huc_loader.c | 268 
> 
>  8 files changed, 327 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 e6fe004..6e99c51 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -53,6 +53,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.c b/drivers/gpu/drm/i915/i915_drv.c
> index 31b2b63..7af7bd6 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -613,6 +613,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
>* working irqs for e.g. gmbus and dp aux transfers. */
>   intel_modeset_init(dev);
>  
> + intel_huc_init(dev);
>   intel_guc_init(dev);
>  
>   ret = i915_gem_init(dev);
> @@ -638,6 +639,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
>  cleanup_gem:
>   i915_gem_fini(dev);
>  cleanup_irq:
> + intel_huc_fini(dev);
>   intel_guc_fini(dev);
>   drm_irq_uninstall(dev);
>   intel_teardown_gmbus(dev);
> @@ -1315,6 +1317,7 @@ void i915_driver_unload(struct drm_device *dev)
>   /* Flush any outstanding unpin_work. */
>   drain_workqueue(dev_priv->wq);
>  
> + intel_huc_fini(dev);
>   intel_guc_fini(dev);
>   i915_gem_fini(dev);
>   intel_fbc_cleanup_cfb(dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e0cb71c..625aa92 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -55,6 +55,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"
>  
> @@ -1766,6 +1767,7 @@ struct drm_i915_private {
>  
>   struct intel_gvt gvt;
>  
> + struct intel_huc huc;
>   struct intel_guc guc;
>  
>   struct intel_csr csr;
> @@ -2822,6 +2824,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 

Re: [Intel-gfx] [PATCH] drm: Print device information again in debugfs

[Emil Velikov]

On 13 October 2016 at 15:13, Daniel Vetter  wrote:
> I was a bit over-eager in my cleanup in
>
> commit 95c081c17f284de50eaca60d4d55643a64d39019
> Author: Daniel Vetter 
> Date:   Tue Jun 21 10:54:12 2016 +0200
>
> drm: Move master pointer from drm_minor to drm_device
>
> Noticed by Chris Wilson.
>
> Fixes: 95c081c17f28 ("drm: Move master pointer from drm_minor to drm_device")
> Cc: Chris Wilson 
> Cc: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Emil Velikov 
> Cc: Julia Lawall 
> Signed-off-by: Daniel Vetter 
Oops ;-) Worth updating/dropping the "Called when ..." comment above
the function ? How about the rest of the file ?

Either way,
Reviewed-by: Emil Velikov 

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

Re: [Intel-gfx] [PATCH v2 4/4] drm: Add and handle new aspect ratios in DRM layer

[Jim Bride]

On Tue, Aug 09, 2016 at 08:25:50PM +0530, Shashank Sharma wrote:
> HDMI 2.0/CEA-861-F introduces two new aspect ratios:
> - 64:27
> - 256:135
> 
> This patch:
> -  Adds new DRM flags for to represent these new aspect ratios.
> -  Adds new cases to handle these aspect ratios while converting
> from user->kernel mode or vise versa.
> 
> V2: Rebase
> 
> Signed-off-by: Shashank Sharma 
> Reviewed-by: Sean Paul 
> Cc: Daniel Vetter 
> Cc: Emil Velikov 
> ---
>  drivers/gpu/drm/drm_modes.c | 12 
>  include/uapi/drm/drm_mode.h |  6 ++
>  2 files changed, 18 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 9d8f00d..ed1b07b 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1481,6 +1481,12 @@ void drm_mode_convert_to_umode(struct 
> drm_mode_modeinfo *out,
>   case HDMI_PICTURE_ASPECT_16_9:
>   out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
>   break;
> + case HDMI_PICTURE_ASPECT_64_27:
> + out->flags |= DRM_MODE_FLAG_PIC_AR_64_27;
> + break;
> + case DRM_MODE_PICTURE_ASPECT_256_135:
> + out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
> + break;
>   case HDMI_PICTURE_ASPECT_RESERVED:
>   default:
>   out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
> @@ -1542,6 +1548,12 @@ int drm_mode_convert_umode(struct drm_display_mode 
> *out,
>   case DRM_MODE_FLAG_PIC_AR_16_9:
>   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
>   break;
> + case DRM_MODE_FLAG_PIC_AR_64_27:
> + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
> + break;
> + case DRM_MODE_FLAG_PIC_AR_256_135:
> + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
> + break;
>   default:
>   out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
>   break;
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 77c869d6..4d3429b 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -81,6 +81,8 @@ extern "C" {
>  #define DRM_MODE_PICTURE_ASPECT_NONE 0
>  #define DRM_MODE_PICTURE_ASPECT_4_3  1
>  #define DRM_MODE_PICTURE_ASPECT_16_9 2
> +#define DRM_MODE_PICTURE_ASPECT_64_273
> +#define DRM_MODE_PICTURE_ASPECT_256_135  4

Minor nit here, but in my tree the '4' above doesn't line up
with the three previous definitions.  I downloaded the series as
a mbox from patchwork.

Jim

>  
>  /* Aspect ratio flag bitmask (4 bits 22:19) */
>  #define DRM_MODE_FLAG_PIC_AR_MASK(0x0F<<19)
> @@ -90,6 +92,10 @@ extern "C" {
>   (DRM_MODE_PICTURE_ASPECT_4_3<<19)
>  #define  DRM_MODE_FLAG_PIC_AR_16_9 \
>   (DRM_MODE_PICTURE_ASPECT_16_9<<19)
> +#define  DRM_MODE_FLAG_PIC_AR_64_27 \
> + (DRM_MODE_PICTURE_ASPECT_64_27<<19)
> +#define  DRM_MODE_FLAG_PIC_AR_256_135 \
> + (DRM_MODE_PICTURE_ASPECT_256_135<<19)
>  
>  /* DPMS flags */
>  /* bit compatible with the xorg definitions. */
> -- 
> 1.9.1
> 
> ___
> 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 v2 2/4] drm: Add aspect ratio parsing in DRM layer

[Jim Bride]

On Tue, Aug 09, 2016 at 08:25:48PM +0530, Shashank Sharma wrote:
> Current DRM layer functions don't parse aspect ratio information
> while converting a user mode->kernel mode or vice versa. This
> causes modeset to pick mode with wrong aspect ratio, eventually
> causing failures in HDMI compliance test cases, due to wrong VIC.
> 
> This patch adds aspect ratio information in DRM's mode conversion
> and mode comparision functions, to make sure kernel picks mode
> with right aspect ratio (as per the VIC).
> 
> V2: Addressed review comments from Sean:
> - Fix spellings/typo
> - No need to handle aspect ratio none
> - Add a break, for default case too
> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Lin, Jia 
> Signed-off-by: Akashdeep Sharma 

Reviewed-by: Jim Bride 

> 
> Cc: Daniel Vetter 
> Cc: Emil Velikov 
> ---
>  drivers/gpu/drm/drm_modes.c | 31 +++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index fc5040a..9d8f00d 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -969,6 +969,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct 
> drm_display_mode *mode1,
>   mode1->vsync_end == mode2->vsync_end &&
>   mode1->vtotal == mode2->vtotal &&
>   mode1->vscan == mode2->vscan &&
> + mode1->picture_aspect_ratio == mode2->picture_aspect_ratio &&
>   (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
>(mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
>   return true;
> @@ -1471,6 +1472,21 @@ void drm_mode_convert_to_umode(struct 
> drm_mode_modeinfo *out,
>   out->vrefresh = in->vrefresh;
>   out->flags = in->flags;
>   out->type = in->type;
> + out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
> +
> + switch (in->picture_aspect_ratio) {
> + case HDMI_PICTURE_ASPECT_4_3:
> + out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
> + break;
> + case HDMI_PICTURE_ASPECT_16_9:
> + out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
> + break;
> + case HDMI_PICTURE_ASPECT_RESERVED:
> + default:
> + out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
> + break;
> + }
> +
>   strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
>   out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
>  }
> @@ -1516,6 +1532,21 @@ int drm_mode_convert_umode(struct drm_display_mode 
> *out,
>   strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
>   out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
>  
> + /* Clearing picture aspect ratio bits from out flags */
> + out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
> +
> + switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
> + case DRM_MODE_FLAG_PIC_AR_4_3:
> + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
> + break;
> + case DRM_MODE_FLAG_PIC_AR_16_9:
> + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
> + break;
> + default:
> + out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> + break;
> + }
> +
>   out->status = drm_mode_validate_basic(out);
>   if (out->status != MODE_OK)
>   goto out;
> -- 
> 1.9.1
> 
> ___
> 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 v2 1/4] drm: add picture aspect ratio flags

[Jim Bride]

On Tue, Aug 09, 2016 at 08:25:47PM +0530, Shashank Sharma wrote:
> This patch adds drm flag bits for aspect ratio information
> 
> Currently drm flag bits don't have field for mode's picture
> aspect ratio. This field will help the driver to pick mode with
> right aspect ratio, and help in setting right VIC field in avi
> infoframes.
> 
> Signed-off-by: Shashank Sharma 

The changes make sense according to the relevant specs, and
although I don't have the HW to test them the code looks right.

Reviewed-by: Jim Bride 

> 
> V2: Addressed review comments from Sean
> - Changed PAR-> PIC_AR
> 
> Cc: Daniel Vetter 
> Cc: Emil Velikov 
> ---
>  include/uapi/drm/drm_mode.h | 18 +-
>  1 file changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 49a7265..77c869d6 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -77,6 +77,19 @@ extern "C" {
>  #define  DRM_MODE_FLAG_3D_TOP_AND_BOTTOM (7<<14)
>  #define  DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF  (8<<14)
>  
> +/* Picture aspect ratio options */
> +#define DRM_MODE_PICTURE_ASPECT_NONE 0
> +#define DRM_MODE_PICTURE_ASPECT_4_3  1
> +#define DRM_MODE_PICTURE_ASPECT_16_9 2
> +
> +/* Aspect ratio flag bitmask (4 bits 22:19) */
> +#define DRM_MODE_FLAG_PIC_AR_MASK(0x0F<<19)
> +#define  DRM_MODE_FLAG_PIC_AR_NONE \
> + (DRM_MODE_PICTURE_ASPECT_NONE<<19)
> +#define  DRM_MODE_FLAG_PIC_AR_4_3 \
> + (DRM_MODE_PICTURE_ASPECT_4_3<<19)
> +#define  DRM_MODE_FLAG_PIC_AR_16_9 \
> + (DRM_MODE_PICTURE_ASPECT_16_9<<19)
>  
>  /* DPMS flags */
>  /* bit compatible with the xorg definitions. */
> @@ -92,11 +105,6 @@ extern "C" {
>  #define DRM_MODE_SCALE_CENTER2 /* Centered, no scaling */
>  #define DRM_MODE_SCALE_ASPECT3 /* Full screen, preserve 
> aspect */
>  
> -/* Picture aspect ratio options */
> -#define DRM_MODE_PICTURE_ASPECT_NONE 0
> -#define DRM_MODE_PICTURE_ASPECT_4_3  1
> -#define DRM_MODE_PICTURE_ASPECT_16_9 2
> -
>  /* Dithering mode options */
>  #define DRM_MODE_DITHERING_OFF   0
>  #define DRM_MODE_DITHERING_ON1
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: Allocate intel_engine_cs structure only for the enabled 
engines (rev4)
URL   : https://patchwork.freedesktop.org/series/13435/
State : warning

== Summary ==

Series 13435v4 drm/i915: Allocate intel_engine_cs structure only for the 
enabled engines
https://patchwork.freedesktop.org/api/1.0/series/13435/revisions/4/mbox/

Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-b:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-b-frame-sequence:
dmesg-warn -> PASS   (fi-ilk-650)
Test vgem_basic:
Subgroup unload:
skip   -> PASS   (fi-skl-6770hq)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:212  dwarn:2   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:183  dwarn:1   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:229  dwarn:1   dfail:0   fail:1   skip:15 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2708/

dbcf6fbb541e70fac7db669631958eab2e4e0d9c drm-intel-nightly: 
2016y-10m-13d-15h-31m-19s UTC integration manifest
391ff6c drm/i915: Allocate intel_engine_cs structure only for the enabled 
engines

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatched INIT power domain disabling during suspend

[Imre Deak]

On to, 2016-10-13 at 15:21 +0300, Jani Nikula wrote:
> On Thu, 13 Oct 2016, Imre Deak  wrote:
> > Currently the display INIT power domain disabling/enabling happens in a
> > mismatched way in the suspend/resume_early hooks respectively. This can
> > leave display power wells incorrectly disabled in the resume hook if the
> > suspend sequence is aborted for some reason resulting in the
> > suspend/resume hooks getting called but the suspend_late/resume_early
> > hooks being skipped. In particular this change fixes "Unclaimed read
> > from register 0x1e1204" on BYT/BSW triggered from i915_drm_resume()->
> > intel_pps_unlock_regs_wa() when suspending with /sys/power/pm_test set
> > to devices.
> > 
> > Cc: Ville Syrjälä 
> > Cc: David Weinehall 
> > Signed-off-by: Imre Deak 
> 
> Fixes: ?

Fixes: 85e90679335f ("drm/i915: disable power wells on suspend")

> Cc: sta...@vger.kernel.org ?

It matters only for an error path which is rare (another device needs
to fail suspending between its suspend and suspend_late steps) and
pm_test. So I'd say this isn't for fixes or stable.

--Imre

> 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index e9b3bfc..5adabac 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1430,8 +1430,6 @@ static int i915_drm_suspend(struct drm_device
> > *dev)
> >  
> >     dev_priv->suspend_count++;
> >  
> > -   intel_display_set_init_power(dev_priv, false);
> > -
> >     intel_csr_ucode_suspend(dev_priv);
> >  
> >  out:
> > @@ -1449,6 +1447,8 @@ static int i915_drm_suspend_late(struct
> > drm_device *dev, bool hibernation)
> >  
> >     disable_rpm_wakeref_asserts(dev_priv);
> >  
> > +   intel_display_set_init_power(dev_priv, false);
> > +
> >     fw_csr = !IS_BROXTON(dev_priv) &&
> >     suspend_to_idle(dev_priv) && dev_priv-
> > >csr.dmc_payload;
> >     /*
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v11] drm/i915: Allocate intel_engine_cs structure only for the enabled engines

[akash . goel]

From: Akash Goel 

With the possibility of addition of many more number of rings in future,
the drm_i915_private structure could bloat as an array, of type
intel_engine_cs, is embedded inside it.
struct intel_engine_cs engine[I915_NUM_ENGINES];
Though this is still fine as generally there is only a single instance of
drm_i915_private structure used, but not all of the possible rings would be
enabled or active on most of the platforms. Some memory can be saved by
allocating intel_engine_cs structure only for the enabled/active engines.
Currently the engine/ring ID is kept static and dev_priv->engine[] is simply
indexed using the enums defined in intel_engine_id.
To save memory and continue using the static engine/ring IDs, 'engine' is
defined as an array of pointers.
struct intel_engine_cs *engine[I915_NUM_ENGINES];
dev_priv->engine[engine_ID] will be NULL for disabled engine instances.

There is a text size reduction of 928 bytes, from 1028200 to 1027272, for
i915.o file (but for i915.ko file text size remain same as 1193131 bytes).

v2:
- Remove the engine iterator field added in drm_i915_private structure,
  instead pass a local iterator variable to the for_each_engine**
  macros. (Chris)
- Do away with intel_engine_initialized() and instead directly use the
  NULL pointer check on engine pointer. (Chris)

v3:
- Remove for_each_engine_id() macro, as the updated macro for_each_engine()
  can be used in place of it. (Chris)
- Protect the access to Render engine Fault register with a NULL check, as
  engine specific init is done later in Driver load sequence.

v4:
- Use !!dev_priv->engine[VCS] style for the engine check in getparam. (Chris)
- Kill the superfluous init_engine_lists().

v5:
- Cleanup the intel_engines_init() & intel_engines_setup(), with respect to
  allocation of intel_engine_cs structure. (Chris)

v6:
- Rebase.

v7:
- Optimize the for_each_engine_masked() macro. (Chris)
- Change the type of 'iter' local variable to enum intel_engine_id. (Chris)
- Rebase.

v8: Rebase.

v9: Rebase.

v10:
- For index calculation use engine ID instead of pointer based arithmetic in
  intel_engine_sync_index() as engine pointers are not contiguous now (Chris)
- For appropriateness, rename local enum variable 'iter' to 'id'. (Joonas)
- Use for_each_engine macro for cleanup in intel_engines_init() and remove
  check for NULL engine pointer in cleanup() routines. (Joonas)

v11: Rebase.

Cc: Chris Wilson 
Signed-off-by: Akash Goel 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c |  3 +-
 drivers/gpu/drm/i915/i915_debugfs.c| 59 ++
 drivers/gpu/drm/i915/i915_drv.c| 11 +++---
 drivers/gpu/drm/i915/i915_drv.h| 22 ---
 drivers/gpu/drm/i915/i915_gem.c| 29 +++
 drivers/gpu/drm/i915/i915_gem_context.c| 15 +---
 drivers/gpu/drm/i915/i915_gem_evict.c  |  3 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  6 +--
 drivers/gpu/drm/i915/i915_gem_gtt.c| 14 +--
 drivers/gpu/drm/i915/i915_gem_request.c|  5 ++-
 drivers/gpu/drm/i915/i915_gpu_error.c  | 28 +++---
 drivers/gpu/drm/i915/i915_guc_submission.c | 12 +++---
 drivers/gpu/drm/i915/i915_irq.c| 46 ---
 drivers/gpu/drm/i915/intel_breadcrumbs.c   |  6 ++-
 drivers/gpu/drm/i915/intel_display.c   |  8 ++--
 drivers/gpu/drm/i915/intel_engine_cs.c | 26 +
 drivers/gpu/drm/i915/intel_guc_loader.c|  6 ++-
 drivers/gpu/drm/i915/intel_lrc.c   | 11 +++---
 drivers/gpu/drm/i915/intel_overlay.c   |  2 +-
 drivers/gpu/drm/i915/intel_pm.c| 17 ++---
 drivers/gpu/drm/i915/intel_ringbuffer.c| 15 
 drivers/gpu/drm/i915/intel_ringbuffer.h|  8 +---
 22 files changed, 194 insertions(+), 158 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 70980f8..f191d7b 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -1308,10 +1308,11 @@ int intel_engine_cmd_parser(struct intel_engine_cs 
*engine,
 int i915_cmd_parser_get_version(struct drm_i915_private *dev_priv)
 {
struct intel_engine_cs *engine;
+   enum intel_engine_id id;
bool active = false;
 
/* If the command parser is not enabled, report 0 - unsupported */
-   for_each_engine(engine, dev_priv) {
+   for_each_engine(engine, dev_priv, id) {
if (intel_engine_needs_cmd_parser(engine)) {
active = true;
break;
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2e312e0..b20c1cc 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -150,7 +150,7 @@ describe_obj(struct seq_file *m, struct 

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm: Print device information again in debugfs

[Patchwork]

== Series Details ==

Series: drm: Print device information again in debugfs
URL   : https://patchwork.freedesktop.org/series/13731/
State : warning

== Summary ==

Series 13731v1 drm: Print device information again in debugfs
https://patchwork.freedesktop.org/api/1.0/series/13731/revisions/1/mbox/

Test drv_module_reload_basic:
skip   -> PASS   (fi-skl-6770hq)
Test kms_pipe_crc_basic:
Subgroup bad-source:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-b-frame-sequence:
dmesg-warn -> PASS   (fi-ilk-650)
Test vgem_basic:
Subgroup unload:
skip   -> PASS   (fi-skl-6770hq)
skip   -> PASS   (fi-hsw-4770)
pass   -> SKIP   (fi-bdw-5557u)

fi-bdw-5557u total:246  pass:230  dwarn:0   dfail:0   fail:0   skip:16 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:213  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:183  dwarn:1   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:230  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2707/

dbcf6fbb541e70fac7db669631958eab2e4e0d9c drm-intel-nightly: 
2016y-10m-13d-15h-31m-19s UTC integration manifest
3d9d112 drm: Print device information again in debugfs

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev3)

[Tvrtko Ursulin]

On 13/10/2016 17:10, Goel, Akash wrote:



On 10/10/2016 6:03 PM, Patchwork wrote:

== Series Details ==

Series: drm/i915: Allocate intel_engine_cs structure only for the 
enabled engines (rev3)

URL   : https://patchwork.freedesktop.org/series/13435/
State : warning

== Summary ==

Series 13435v3 drm/i915: Allocate intel_engine_cs structure only for 
the enabled engines

https://patchwork.freedesktop.org/api/1.0/series/13435/revisions/3/mbox/

Test vgem_basic:
Subgroup unload:
pass   -> SKIP   (fi-skl-6260u)
pass   -> SKIP   (fi-skl-6700hq)
skip   -> PASS   (fi-skl-6700k)


Checked with Chris about the above failure.
He said that the above unload failure for vgem module can't be
attributed to the patch, most likely a CI framework issue.



I tried to merge it but due recent changes to error capture it doesn't 
apply any longer. Can you please rebase and resend?


Regards,

Tvrtko

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev3)

[Goel, Akash]

On 10/10/2016 6:03 PM, Patchwork wrote:

== Series Details ==

Series: drm/i915: Allocate intel_engine_cs structure only for the enabled 
engines (rev3)
URL   : https://patchwork.freedesktop.org/series/13435/
State : warning

== Summary ==

Series 13435v3 drm/i915: Allocate intel_engine_cs structure only for the 
enabled engines
https://patchwork.freedesktop.org/api/1.0/series/13435/revisions/3/mbox/

Test vgem_basic:
Subgroup unload:
pass   -> SKIP   (fi-skl-6260u)
pass   -> SKIP   (fi-skl-6700hq)
skip   -> PASS   (fi-skl-6700k)


Checked with Chris about the above failure.
He said that the above unload failure for vgem module can't be
attributed to the patch, most likely a CI framework issue.

Best regards
Akash


fi-bdw-5557u total:248  pass:231  dwarn:0   dfail:0   fail:0   skip:17
fi-bsw-n3050 total:248  pass:204  dwarn:0   dfail:0   fail:0   skip:44
fi-bxt-t5700 total:248  pass:217  dwarn:0   dfail:0   fail:0   skip:31
fi-byt-j1900 total:248  pass:214  dwarn:1   dfail:0   fail:1   skip:32
fi-byt-n2820 total:248  pass:210  dwarn:0   dfail:0   fail:1   skip:37
fi-hsw-4770  total:248  pass:224  dwarn:0   dfail:0   fail:0   skip:24
fi-hsw-4770r total:248  pass:224  dwarn:0   dfail:0   fail:0   skip:24
fi-ilk-650   total:248  pass:185  dwarn:0   dfail:0   fail:2   skip:61
fi-ivb-3520m total:248  pass:221  dwarn:0   dfail:0   fail:0   skip:27
fi-ivb-3770  total:248  pass:207  dwarn:0   dfail:0   fail:0   skip:41
fi-kbl-7200u total:248  pass:222  dwarn:0   dfail:0   fail:0   skip:26
fi-skl-6260u total:248  pass:232  dwarn:0   dfail:0   fail:0   skip:16
fi-skl-6700hqtotal:248  pass:223  dwarn:1   dfail:0   fail:0   skip:24
fi-skl-6700k total:248  pass:222  dwarn:1   dfail:0   fail:0   skip:25
fi-skl-6770hqtotal:248  pass:231  dwarn:1   dfail:0   fail:1   skip:15
fi-snb-2520m total:248  pass:211  dwarn:0   dfail:0   fail:0   skip:37
fi-snb-2600  total:248  pass:209  dwarn:0   dfail:0   fail:0   skip:39

Results at /archive/results/CI_IGT_test/Patchwork_2652/

f35ed31aea66b3230c366fcba5f3456ae2cb956e drm-intel-nightly: 
2016y-10m-10d-11h-28m-51s UTC integration manifest
401facf drm/i915: Allocate intel_engine_cs structure only for the enabled 
engines


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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Save megabytes of wasted sg entries

[Tvrtko Ursulin]

On 13/10/2016 16:33, Daniel Vetter wrote:

On Thu, Oct 13, 2016 at 11:24:46AM +, Saarinen, Jani wrote:

== Series Details ==

Series: Save megabytes of wasted sg entries
URL   : https://patchwork.freedesktop.org/series/13706/
State : failure

== Summary ==

Series 13706v1 Save megabytes of wasted sg entries
https://patchwork.freedesktop.org/api/1.0/series/13706/revisions/1/mbox/

Test gem_cs_tlb:
 Subgroup basic-default:
 pass   -> INCOMPLETE (fi-bsw-n3050)
 pass   -> INCOMPLETE (fi-byt-n2820)
 pass   -> INCOMPLETE (fi-hsw-4770r)
 pass   -> INCOMPLETE (fi-skl-6260u)
 pass   -> INCOMPLETE (fi-ivb-3770)
 pass   -> INCOMPLETE (fi-kbl-7200u)
 pass   -> INCOMPLETE (fi-skl-6700hq)
 pass   -> INCOMPLETE (fi-bdw-5557u)
 pass   -> INCOMPLETE (fi-ilk-650)
 pass   -> INCOMPLETE (fi-hsw-4770)
 pass   -> INCOMPLETE (fi-byt-j1900)
 pass   -> INCOMPLETE (fi-snb-2520m)
 pass   -> INCOMPLETE (fi-bxt-t5700)
 pass   -> INCOMPLETE (fi-ivb-3520m)

running: igt/gem_cs_tlb/basic-default

[014/246] pass: 14 -
Build timed out (after 18 minutes). Marking the build as aborted.

[   96.771613] gem_cs_tlb: starting subtest basic-default
[   96.773567] general protection fault:  [#1] PREEMPT SMP
[   96.773599] Modules linked in: snd_hda_intel i915 cdc_ncm usbnet mii 
x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul 
ghash_clmulni_intel lpc_ich snd_hda_codec_hdmi snd_hda_codec_realtek 
snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core snd_pcm mei_me mei 
sdhci_pci sdhci mmc_core e1000e ptp pps_core [last unloaded: i915]
[   96.773775] CPU: 1 PID: 8922 Comm: gem_cs_tlb Tainted: G U  
4.8.0-CI-Patchwork_2698+ #1
[   96.773806] Hardware name: LENOVO 2356GCG/2356GCG, BIOS G7ET31WW (1.13 ) 
07/02/2012
[   96.773833] task: 8801311ace40 task.stack: 880137654000
[   96.773854] RIP: 0010:[]  [] 
kfree+0x72/0x2e0
...

Please paste the full backtrace, it might throw a hint on what's going on.


It was just a RFC, I even labelled it as broken. Just wanted to send it 
out for feedback on the general approach since I was unsure when I will 
get back to debugging it.


It is most certainly a bug in my sg_table_trim implementation. :)

[   67.205081] general protection fault:  [#1] PREEMPT SMP
[   67.205115] Modules linked in: snd_hda_intel i915 intel_powerclamp coretemp 
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_hdmi 
snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec snd_hwdep 
snd_hda_core snd_pcm mei_me mei lpc_ich e1000e ptp pps_core [last unloaded: 
i915]
[   67.205284] CPU: 2 PID: 7725 Comm: gem_cs_tlb Tainted: G U  
4.8.0-CI-Patchwork_2698+ #1
[   67.205315] Hardware name: Hewlett-Packard HP Compaq 8100 Elite SFF 
PC/304Ah, BIOS 786H1 v01.05 06/09/2010
[   67.205347] task: 88020a68a600 task.stack: 880207708000
[   67.205370] RIP: 0010:[]  [] 
kfree+0x72/0x2e0
[   67.205404] RSP: 0018:88020770bc30  EFLAGS: 00010203
[   67.205425] RAX: ea00 RBX: 6b6b6b6b6b6b6b68 RCX: 0002
[   67.205450] RDX: 8002 RSI: 81c595f0 RDI: 88020a68ae28
[   67.205476] RBP: 88020770bc58 R08: ea0008239c20 R09: 0001
[   67.205501] R10:  R11:  R12: 87654321
[   67.205527] R13: 814392a6 R14: 01ad998dadadad80 R15: 
[   67.205553] FS:  7ff7454d4740() GS:88021bc8() 
knlGS:
[   67.205581] CS:  0010 DS:  ES:  CR0: 80050033
[   67.205602] CR2: 019273f8 CR3: 0002102a2000 CR4: 06e0
[   67.205627] Stack:
[   67.205638]  88020cc062c8 87654321 012f 
0036
[   67.205678]   88020770bc90 814392a6 
88020cc062c8
[   67.205717]  880208d8a420 00021292  
880209a35dc0
[   67.205757] Call Trace:
[   67.205772]  [] sg_trim_table+0x96/0xe0
[   67.205808]  [] i915_sg_complete+0x38/0x40 [i915]
[   67.205844]  [] i915_gem_object_get_pages_gtt+0xe5/0x340 
[i915]
[   67.205884]  [] i915_gem_object_get_pages+0x3c/0xb0 [i915]
[   67.205922]  [] 
i915_gem_object_set_to_gtt_domain+0x3b/0x290 [i915]
[   67.205963]  [] i915_gem_set_domain_ioctl+0x108/0x130 
[i915]
[   67.205991]  [] drm_ioctl+0x1f6/0x480
[   67.206024]  [] ? 
i915_gem_obj_prepare_shmem_write+0x170/0x170 [i915]
[   67.206054]  [] ? debug_lockdep_rcu_enabled+0x1d/0x20
[   67.206080]  [] do_vfs_ioctl+0x8e/0x690
[   67.206102]  [] ? trace_hardirqs_on_caller+0x122/0x1b0
[   67.206126]  [] SyS_ioctl+0x3c/0x70
[   67.206150]  [] entry_SYSCALL_64_fastpath+0x1c/0xac
[   67.206173] Code: 00 00 00 80 ff 77 00 00 49 01 de 48 0f 42 05 f6 db c3 00 49 

Re: [Intel-gfx] [PATCH v4 8/8] drm/i915/bxt: Enable IPC support

[Daniel Vetter]

On Thu, Oct 13, 2016 at 06:31:37PM +0530, Mahesh Kumar wrote:
> Hi,
> 
> 
> On Thursday 13 October 2016 04:49 PM, Maarten Lankhorst wrote:
> > Op 13-10-16 om 12:58 schreef Kumar, Mahesh:
> > > From: Mahesh Kumar 
> > > 
> > > This patch adds IPC support for platforms. This patch enables IPC
> > > only for BXT/KBL platform as for SKL recommendation is to keep is 
> > > disabled.
> > > IPC (Isochronous Priority Control) is the hardware feature, which
> > > dynamically controles the memory read priority of Display.
> > > 
> > > When IPC is enabled, plane read requests are sent at high priority until
> > > filling above the transition watermark, then the requests are sent at
> > > lower priority until dropping below the level 0 watermark.
> > > The lower priority requests allow other memory clients to have better
> > > memory access. When IPC is disabled, all plane read requests are sent at
> > > high priority.
> > > 
> > > Changes since V1:
> > >   - Remove commandline parameter to disable ipc
> > >   - Address Paulo's comments
> > > 
> > > Signed-off-by: Mahesh Kumar 
> > > ---
> > >   drivers/gpu/drm/i915/i915_drv.c  |  2 ++
> > >   drivers/gpu/drm/i915/i915_reg.h  |  1 +
> > >   drivers/gpu/drm/i915/intel_drv.h |  1 +
> > >   drivers/gpu/drm/i915/intel_pm.c  | 15 +++
> > >   4 files changed, 19 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > > b/drivers/gpu/drm/i915/i915_drv.c
> > > index b5f601c..58abbaa 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > @@ -1415,6 +1415,8 @@ int i915_driver_load(struct pci_dev *pdev, const 
> > > struct pci_device_id *ent)
> > >   intel_runtime_pm_enable(dev_priv);
> > > + intel_enable_ipc(dev_priv);
> > > +
> > >   /* Everything is in place, we can now relax! */
> > >   DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
> > >driver.name, driver.major, driver.minor, 
> > > driver.patchlevel,
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index a9c467c..c9ebf23 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -6144,6 +6144,7 @@ enum {
> > >   #define  DISP_FBC_WM_DIS(1<<15)
> > >   #define DISP_ARB_CTL2   _MMIO(0x45004)
> > >   #define  DISP_DATA_PARTITION_5_6(1<<6)
> > > +#define  DISP_IPC_ENABLE (1<<3)
> > >   #define DBUF_CTL_MMIO(0x45008)
> > >   #define  DBUF_POWER_REQUEST (1<<31)
> > >   #define  DBUF_POWER_STATE   (1<<30)
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index 2c1897b..45b0fa4 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -1766,6 +1766,7 @@ void skl_write_plane_wm(struct intel_crtc 
> > > *intel_crtc,
> > >   uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state 
> > > *pipe_config);
> > >   bool ilk_disable_lp_wm(struct drm_device *dev);
> > >   int sanitize_rc6_option(struct drm_i915_private *dev_priv, int 
> > > enable_rc6);
> > > +void intel_enable_ipc(struct drm_i915_private *dev_priv);
> > >   static inline int intel_enable_rc6(void)
> > >   {
> > >   return i915.enable_rc6;
> > > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > > b/drivers/gpu/drm/i915/intel_pm.c
> > > index 4263212..543aa5d 100644
> > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > @@ -4833,6 +4833,21 @@ void intel_update_watermarks(struct drm_crtc *crtc)
> > >   dev_priv->display.update_wm(crtc);
> > >   }
> > > +void intel_enable_ipc(struct drm_i915_private *dev_priv)
> > > +{
> > > + u32 val;
> > > +
> > > + /* enable IPC only for Broxton for now*/
> > > + if (!IS_BROXTON(dev_priv) || !IS_KABYLAKE(dev_priv))
> > > + return;
> > > +
> > This comment doesn't match the code.
> > Is it ok to enable IPC right away? Not when the driver is writing the first 
> > watermarks? (distrust_bios_wm)
> > And what about suspend/resume, should this flag be set again after resume?
> > 
> > ~Maarten
> hmm.. comment should have been Broxton/Kabylake.
> Yes we can enable IPC at any time. In future BIOS itself may enable IPC.
> (though I'm not sure about the behavior if WM programmed by BIOS are not
> correct)
> We don't reset (save/restore) this during suspend/resume, it's onetime
> programming.

The comment is also not really useful, since it's obvious from the code
what's going on. If you add a comment, explain _why_ you're doing
something. The _what_ should be clear from the code flow, if not you need
to refactor.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Use fence_write() from rpm resume

[Chris Wilson]

On Thu, Oct 13, 2016 at 05:28:13PM +0200, Daniel Vetter wrote:
> On Thu, Oct 13, 2016 at 04:25:18PM +0100, Chris Wilson wrote:
> > On Thu, Oct 13, 2016 at 05:10:21PM +0200, Daniel Vetter wrote:
> > > On Wed, Oct 12, 2016 at 12:16:33PM +0100, Chris Wilson wrote:
> > > > @@ -379,10 +389,17 @@ void i915_gem_restore_fences(struct drm_device 
> > > > *dev)
> > > >  * Commit delayed tiling changes if we have an object 
> > > > still
> > > >  * attached to the fence, otherwise just clear the 
> > > > fence.
> > > >  */
> > > > -   if (vma && !i915_gem_object_is_tiled(vma->obj))
> > > > +   if (vma && !i915_gem_object_is_tiled(vma->obj)) {
> > > > +   GEM_BUG_ON(!reg->dirty);
> > > > +   
> > > > GEM_BUG_ON(!list_empty(>obj->userfault_link));
> > > > +
> > > > +   list_move(>link, _priv->mm.fence_list);
> > > > +   vma->fence = NULL;
> > > > vma = NULL;
> > > > +   }
> > > >  
> > > > -   fence_update(reg, vma);
> > > > +   fence_write(reg, vma);
> > > > +   reg->vma = vma;
> > > 
> > > Same comments as with the userfault_list: Using rpm ordering to enforce
> > > consistency causes mild panic attacks here with me ;-)
> > > 
> > > Is the above (delayed tiling change commit) even possible here, at least
> > > for rpm resume? Same for system s/r (both s3 and s4) since the pagetables
> > > won't survive anyway. Can't we simply make this an impossibility?
> > 
> > We also use this from reset to rewrite the old fences, and we know there
> > we can hit the delayed fence write [4fc788f5ee3d]. It would also be
> > possible to hit it on suspend as well.
> > 
> > I've been thinking about whether we should be bothering to write the
> > fence registers with the correct value or just cancel the fences. But we
> > have to restore anything that is pinned, and we have to write something
> > into the fences (just to be safe), and if we have to write something we
> > may as well use the most recent information we have as that has a good
> > chance of being used again.
> > 
> > Long story short, I don't have a better idea for restoring or avoiding
> > the restore of fences.
> 
> What about a rpm_resume only version that just does a blind fence_write?
> It is something, and we can update the book-keeping once we do get to one
> of the real synchronization points again.
> 
> With that we can leave the versions for reset and system s/r alone ... Or
> is there trickery even with rpm going on?

For rpm suspend, we only zap the user's mmap and not mark the fence as
lost. I think that's the missing piece as to why this is not as simple as
it could be for rpm-resume. On rpm-resume we only need to restore pinned
fences, and fences should only be pinned for hw access, and so there
should never be any if we were rpm-suspended. (Assuming that all pinned
fences are active, which on the surface seems a reasonable assumption.)

If that holds true, we do not need this at all for runtime pm (we still
need it across full system suspend/reset) and just need to doctor the
existing scary i915_gem_release_all_mmaps() (aka
i915_gem_runtime_suspend()!) to both release the mmap and throw away the
fence tracing. At least then we only have one dragon nest.
-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/8] drm/i915/huc: Unified css_header struct for GuC and HuC

[Jeff McGee]

On Mon, Oct 03, 2016 at 11:42:56AM -0700, Anusha Srivatsa wrote:
> From: Peter Antoine 
> 
> HuC firmware css header has almost exactly same definition as GuC
> firmware except for the sw_version. Also, add a new member fw_type
> into intel_uc_fw to indicate what kind of fw it is. So, the loader
> will pull right sw_version from header.
> 
> v2: rebased on-top of drm-intel-nightly
> v3: rebased on-top of drm-intel-nightly (again).
> v4: rebased + spaces.
> v7: rebased.
> v8: rebased.
> 
> 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/intel_guc.h|  4 
>  drivers/gpu/drm/i915/intel_guc_fwif.h   | 16 ++---
>  drivers/gpu/drm/i915/intel_guc_loader.c | 41 
> ++---
>  3 files changed, 45 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_guc.h 
> b/drivers/gpu/drm/i915/intel_guc.h
> index b134a41..812e4ca 100644
> --- a/drivers/gpu/drm/i915/intel_guc.h
> +++ b/drivers/gpu/drm/i915/intel_guc.h
> @@ -98,6 +98,9 @@ enum intel_uc_fw_status {
>   UC_FIRMWARE_SUCCESS
>  };
>  
> +#define UC_FW_TYPE_GUC   0
> +#define UC_FW_TYPE_HUC   1
> +
>  /*
>   * This structure encapsulates all the data needed during the process
>   * of fetching, caching, and loading the firmware image into the GuC.
> @@ -115,6 +118,7 @@ struct intel_uc_fw {
>   uint16_t major_ver_found;
>   uint16_t minor_ver_found;
>  
> + uint32_t fw_type;
>   uint32_t header_size;
>   uint32_t header_offset;
>   uint32_t rsa_size;
> diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
> b/drivers/gpu/drm/i915/intel_guc_fwif.h
> index e40db2d..b38b6b4 100644
> --- a/drivers/gpu/drm/i915/intel_guc_fwif.h
> +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
> @@ -154,7 +154,7 @@
>   * The GuC firmware layout looks like this:
>   *
>   * +---+
> - * |guc_css_header |
> + * | uc_css_header |
>   * |   |
>   * | contains major/minor version  |
>   * +---+
> @@ -181,9 +181,16 @@
>   * 3. Length info of each component can be found in header, in dwords.
>   * 4. Modulus and exponent key are not required by driver. They may not 
> appear
>   *in fw. So driver will load a truncated firmware in this case.
> + *
> + * HuC firmware layout is same as GuC firmware.
> + *
> + * HuC firmware css header is different. However, the only difference is 
> where
> + * the version information is saved. The uc_css_header is unified to support
> + * both. Driver should get HuC version from uc_css_header.huc_sw_version, 
> while
> + * uc_css_header.guc_sw_version for GuC.
>   */
>  
> -struct guc_css_header {
> +struct uc_css_header {
>   uint32_t module_type;
>   /* header_size includes all non-uCode bits, including css_header, rsa
>* key, modulus key and exponent data. */
> @@ -214,7 +221,10 @@ struct guc_css_header {
>  
>   char username[8];
>   char buildnumber[12];
> - uint32_t device_id;
> + union {
> + uint32_t device_id;
> + uint32_t huc_sw_version;
> + };
>   uint32_t guc_sw_version;
>   uint32_t prod_preprod_fw;
>   uint32_t reserved[12];

I propose renaming the device_id field in this union to
'guc_client_branch_version'. GuC uses this position to store a client
version and branch version. I'm not sure where the 'device_id' term came
from. We don't reference this currently but may need to in the future
so might as well name it properly. At the very least we should probably
make it guc_device_id, to help indicate that it applies to guc fw only.

In that same vein, can we make guc_sw_version into a union as below to
reinforce the difference to huc?

union {
uint32_t guc_sw_version;
uint32_t huc_reserved;
};

Jeff

> diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
> b/drivers/gpu/drm/i915/intel_guc_loader.c
> index 493295d..0b863a1 100644
> --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> @@ -586,7 +586,7 @@ void intel_uc_fw_fetch(struct drm_device *dev, struct 
> intel_uc_fw *uc_fw)
>   struct pci_dev *pdev = dev->pdev;
>   struct drm_i915_gem_object *obj;
>   const struct firmware *fw;
> - struct guc_css_header *css;
> + struct uc_css_header *css;
>   size_t size;
>   int err;
>  
> @@ -603,19 +603,19 @@ void intel_uc_fw_fetch(struct drm_device *dev, struct 
> intel_uc_fw *uc_fw)
>   uc_fw->uc_fw_path, fw);
>  
>   /* Check the size of the blob before examining buffer contents */
> - if (fw->size < sizeof(struct guc_css_header)) {

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Save megabytes of wasted sg entries

[Daniel Vetter]

On Thu, Oct 13, 2016 at 11:24:46AM +, Saarinen, Jani wrote:
> > == Series Details ==
> > 
> > Series: Save megabytes of wasted sg entries
> > URL   : https://patchwork.freedesktop.org/series/13706/
> > State : failure
> > 
> > == Summary ==
> > 
> > Series 13706v1 Save megabytes of wasted sg entries
> > https://patchwork.freedesktop.org/api/1.0/series/13706/revisions/1/mbox/
> > 
> > Test gem_cs_tlb:
> > Subgroup basic-default:
> > pass   -> INCOMPLETE (fi-bsw-n3050)
> > pass   -> INCOMPLETE (fi-byt-n2820)
> > pass   -> INCOMPLETE (fi-hsw-4770r)
> > pass   -> INCOMPLETE (fi-skl-6260u)
> > pass   -> INCOMPLETE (fi-ivb-3770)
> > pass   -> INCOMPLETE (fi-kbl-7200u)
> > pass   -> INCOMPLETE (fi-skl-6700hq)
> > pass   -> INCOMPLETE (fi-bdw-5557u)
> > pass   -> INCOMPLETE (fi-ilk-650)
> > pass   -> INCOMPLETE (fi-hsw-4770)
> > pass   -> INCOMPLETE (fi-byt-j1900)
> > pass   -> INCOMPLETE (fi-snb-2520m)
> > pass   -> INCOMPLETE (fi-bxt-t5700)
> > pass   -> INCOMPLETE (fi-ivb-3520m)
> running: igt/gem_cs_tlb/basic-default
> 
> [014/246] pass: 14 - 
> Build timed out (after 18 minutes). Marking the build as aborted.
> 
> [   96.771613] gem_cs_tlb: starting subtest basic-default
> [   96.773567] general protection fault:  [#1] PREEMPT SMP
> [   96.773599] Modules linked in: snd_hda_intel i915 cdc_ncm usbnet mii 
> x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul 
> ghash_clmulni_intel lpc_ich snd_hda_codec_hdmi snd_hda_codec_realtek 
> snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core snd_pcm mei_me mei 
> sdhci_pci sdhci mmc_core e1000e ptp pps_core [last unloaded: i915]
> [   96.773775] CPU: 1 PID: 8922 Comm: gem_cs_tlb Tainted: G U  
> 4.8.0-CI-Patchwork_2698+ #1
> [   96.773806] Hardware name: LENOVO 2356GCG/2356GCG, BIOS G7ET31WW (1.13 ) 
> 07/02/2012
> [   96.773833] task: 8801311ace40 task.stack: 880137654000
> [   96.773854] RIP: 0010:[]  [] 
> kfree+0x72/0x2e0
> ...

Please paste the full backtrace, it might throw a hint on what's going on.
-Daniel

> 
> > 
> > fi-bdw-5557u total:15   pass:14   dwarn:0   dfail:0   fail:0   skip:0
> > fi-bsw-n3050 total:15   pass:14   dwarn:0   dfail:0   fail:0   skip:0
> > fi-bxt-t5700 total:15   pass:14   dwarn:0   dfail:0   fail:0   skip:0
> > fi-byt-j1900 total:15   pass:14   dwarn:0   dfail:0   fail:0   skip:0
> > fi-byt-n2820 total:15   pass:14   dwarn:0   dfail:0   fail:0   skip:0
> > fi-hsw-4770  total:15   pass:14   dwarn:0   dfail:0   fail:0   skip:0
> > fi-hsw-4770r total:15   pass:14   dwarn:0   dfail:0   fail:0   skip:0
> > fi-ilk-650   total:15   pass:14   dwarn:0   dfail:0   fail:0   skip:0
> > fi-ivb-3520m total:15   pass:14   dwarn:0   dfail:0   fail:0   skip:0
> > fi-ivb-3770  total:15   pass:14   dwarn:0   dfail:0   fail:0   skip:0
> > fi-kbl-7200u total:15   pass:14   dwarn:0   dfail:0   fail:0   skip:0
> > fi-skl-6260u total:15   pass:14   dwarn:0   dfail:0   fail:0   skip:0
> > fi-skl-6700hqtotal:15   pass:14   dwarn:0   dfail:0   fail:0   skip:0
> > fi-snb-2520m total:15   pass:14   dwarn:0   dfail:0   fail:0   skip:0
> > 
> > Results at /archive/results/CI_IGT_test/Patchwork_2698/
> > 
> > 75d9d28f7f5d0147ba35e956268c3a3c079dc754 drm-intel-nightly: 2016y-10m-
> > 13d-09h-14m-05s UTC integration manifest
> > ae958d3 drm/i915: Trim sg table after creating it
> > c393824 lib/scatterlist: Add sg_trim_table
> > 35fb691 drm/i915: Use i915_sg_create for dmabuf 215eb9b drm/i915: Use
> > i915_sg_create for rotated pages view
> > 845b775 drm/i915: Use i915_sg_create for partial views
> > 393cad6 drm/i915: Use i915_sg_create for userptr 0e4b44a drm/i915: Extract
> > sg creation into a helper
> > 
> 
> Jani Saarinen
> Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
> 
> 
> 
> ___
> 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 1/5] drm/i915: Use fence_write() from rpm resume

[Chris Wilson]

On Thu, Oct 13, 2016 at 05:10:21PM +0200, Daniel Vetter wrote:
> On Wed, Oct 12, 2016 at 12:16:33PM +0100, Chris Wilson wrote:
> > @@ -379,10 +389,17 @@ void i915_gem_restore_fences(struct drm_device *dev)
> >  * Commit delayed tiling changes if we have an object still
> >  * attached to the fence, otherwise just clear the fence.
> >  */
> > -   if (vma && !i915_gem_object_is_tiled(vma->obj))
> > +   if (vma && !i915_gem_object_is_tiled(vma->obj)) {
> > +   GEM_BUG_ON(!reg->dirty);
> > +   GEM_BUG_ON(!list_empty(>obj->userfault_link));
> > +
> > +   list_move(>link, _priv->mm.fence_list);
> > +   vma->fence = NULL;
> > vma = NULL;
> > +   }
> >  
> > -   fence_update(reg, vma);
> > +   fence_write(reg, vma);
> > +   reg->vma = vma;
> 
> Same comments as with the userfault_list: Using rpm ordering to enforce
> consistency causes mild panic attacks here with me ;-)
> 
> Is the above (delayed tiling change commit) even possible here, at least
> for rpm resume? Same for system s/r (both s3 and s4) since the pagetables
> won't survive anyway. Can't we simply make this an impossibility?

We also use this from reset to rewrite the old fences, and we know there
we can hit the delayed fence write [4fc788f5ee3d]. It would also be
possible to hit it on suspend as well.

I've been thinking about whether we should be bothering to write the
fence registers with the correct value or just cancel the fences. But we
have to restore anything that is pinned, and we have to write something
into the fences (just to be safe), and if we have to write something we
may as well use the most recent information we have as that has a good
chance of being used again.

Long story short, I don't have a better idea for restoring or avoiding
the restore of fences.
-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/3] drm/i915: Use RPM as the barrier for controlling user mmap access

[Daniel Vetter]

On Thu, Oct 13, 2016 at 04:15:23PM +0100, Chris Wilson wrote:
> On Thu, Oct 13, 2016 at 04:44:23PM +0200, Daniel Vetter wrote:
> > On Tue, Oct 11, 2016 at 03:37:58PM +0100, Chris Wilson wrote:
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > > b/drivers/gpu/drm/i915/i915_gem.c
> > > index 91910ffe0964..587a91af5a3f 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > @@ -1469,7 +1469,9 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void 
> > > *data,
> > >*/
> > >   if (!i915_gem_object_has_struct_page(obj) ||
> > >   cpu_write_needs_clflush(obj)) {
> > > + intel_runtime_pm_get(dev_priv);
> > >   ret = i915_gem_gtt_pwrite_fast(dev_priv, obj, args, file);
> > > + intel_runtime_pm_put(dev_priv);
> > 
> > I'd move the rpm_get/put into gtt_pwrite_fast - there's only one caller,
> > and it's in the spirit of this patch of moving the rpm get/put closer to
> > where we really need it.
> 
> What I've also done is move rpm_get/rpm_put into i915_gem_release_mmap()
> and split out the RPM-suspend only i915_gem_release_all_mmaps() (if I
> can think of a good name to better distinguish the two I'll do that as
> well). The benefit being is that instead of simply asserting in one that
> we hold the rpm-wakeref we take it.
> 
> i915_gem_runtime_suspend__mmaps() ?

Or maybe throw a ggtt in there for giggles, but yeah.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Use fence_write() from rpm resume

[Daniel Vetter]

On Thu, Oct 13, 2016 at 04:25:18PM +0100, Chris Wilson wrote:
> On Thu, Oct 13, 2016 at 05:10:21PM +0200, Daniel Vetter wrote:
> > On Wed, Oct 12, 2016 at 12:16:33PM +0100, Chris Wilson wrote:
> > > @@ -379,10 +389,17 @@ void i915_gem_restore_fences(struct drm_device *dev)
> > >* Commit delayed tiling changes if we have an object still
> > >* attached to the fence, otherwise just clear the fence.
> > >*/
> > > - if (vma && !i915_gem_object_is_tiled(vma->obj))
> > > + if (vma && !i915_gem_object_is_tiled(vma->obj)) {
> > > + GEM_BUG_ON(!reg->dirty);
> > > + GEM_BUG_ON(!list_empty(>obj->userfault_link));
> > > +
> > > + list_move(>link, _priv->mm.fence_list);
> > > + vma->fence = NULL;
> > >   vma = NULL;
> > > + }
> > >  
> > > - fence_update(reg, vma);
> > > + fence_write(reg, vma);
> > > + reg->vma = vma;
> > 
> > Same comments as with the userfault_list: Using rpm ordering to enforce
> > consistency causes mild panic attacks here with me ;-)
> > 
> > Is the above (delayed tiling change commit) even possible here, at least
> > for rpm resume? Same for system s/r (both s3 and s4) since the pagetables
> > won't survive anyway. Can't we simply make this an impossibility?
> 
> We also use this from reset to rewrite the old fences, and we know there
> we can hit the delayed fence write [4fc788f5ee3d]. It would also be
> possible to hit it on suspend as well.
> 
> I've been thinking about whether we should be bothering to write the
> fence registers with the correct value or just cancel the fences. But we
> have to restore anything that is pinned, and we have to write something
> into the fences (just to be safe), and if we have to write something we
> may as well use the most recent information we have as that has a good
> chance of being used again.
> 
> Long story short, I don't have a better idea for restoring or avoiding
> the restore of fences.

What about a rpm_resume only version that just does a blind fence_write?
It is something, and we can update the book-keeping once we do get to one
of the real synchronization points again.

With that we can leave the versions for reset and system s/r alone ... Or
is there trickery even with rpm going on?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [CI 4/6] drm/i915: Always use the GTT for error capture

[Chris Wilson]

On Thu, Oct 13, 2016 at 05:02:50PM +0200, Daniel Vetter wrote:
> On Wed, Oct 12, 2016 at 10:05:20AM +0100, Chris Wilson wrote:
> > Since the GTT provides universal access to any GPU page, we can use it
> > to reduce our plethora of read methods to just one. It also has the
> > important characteristic of being exactly what the GPU sees - if there
> > are incoherency problems, seeing the batch as executed (rather than as
> > trapped inside the cpu cache) is important.
> > 
> > Signed-off-by: Chris Wilson 
> > Reviewed-by: Joonas Lahtinen 
> 
> Meh, so much for me reading patches in order ;-)
> 
> Please reorder this one before the previous one and I'll be happy too.

Hmm, I actually thought this was. Shows what I remember about my
series.
-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] [RFC i-g-t PATCH 2/3] igt/gem_wait: Use new igt_dummyload api

[Daniel Vetter]

On Thu, Oct 13, 2016 at 10:49:39AM +0100, Chris Wilson wrote:
> On Thu, Oct 13, 2016 at 12:31:13PM +0300, Abdiel Janulgue wrote:
> > 
> > 
> > On 10/12/2016 03:07 PM, Chris Wilson wrote:
> > > On Wed, Oct 12, 2016 at 02:59:53PM +0300, Abdiel Janulgue wrote:
> > >> Signed-off-by: Abdiel Janulgue 
> > >> ---
> > >>  tests/gem_wait.c | 77 
> > >> +---
> > >>  1 file changed, 12 insertions(+), 65 deletions(-)
> > > 
> > > We can do so much better than a dummy load here. We can precisely
> > > control how long we want the object to be busy by using a recursive
> > > batch buffer (and terminating that batch at the exact moment we require).
> > > -Chris
> > > 
> > Hi Chris, I see you've posted a better solution to gem_wait. I could
> > drop this one and defer to yours instead. So for now, igt_dummyload has
> > dropped to only 1 customer at the moment: kms_flip.  Let me know whether
> > it's possible to upstream this dummyload api.
> 
> kms_flip would probably be better with a specific load rather than a
> dummy as well. The challenge is whether the flip works given various
> input states of the framebuffers, and the more control we have over
> those inputs the better.

Oh yeah, this is a pretty sweet idea with a spinning batch that we
manually terminate. Assuming it works everywhere I think this is a much
better approach, and by submitting different workloads we can always put
the delay workload exactly where we want.

Abdiel, can you pls update the JIRA to instead extract Chris' trick into a
library (pretty sure Chris can help with bikeshedding the interface to
make it all pretty) and then roll that one out? Being able to control the
time used by delay tasks down to jiffies is real sweet.

Also there might be some space to reuse this with Mika's hangcheck stuff,
not sure.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Use RPM as the barrier for controlling user mmap access

[Chris Wilson]

On Thu, Oct 13, 2016 at 04:44:23PM +0200, Daniel Vetter wrote:
> On Tue, Oct 11, 2016 at 03:37:58PM +0100, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 91910ffe0964..587a91af5a3f 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -1469,7 +1469,9 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void 
> > *data,
> >  */
> > if (!i915_gem_object_has_struct_page(obj) ||
> > cpu_write_needs_clflush(obj)) {
> > +   intel_runtime_pm_get(dev_priv);
> > ret = i915_gem_gtt_pwrite_fast(dev_priv, obj, args, file);
> > +   intel_runtime_pm_put(dev_priv);
> 
> I'd move the rpm_get/put into gtt_pwrite_fast - there's only one caller,
> and it's in the spirit of this patch of moving the rpm get/put closer to
> where we really need it.

What I've also done is move rpm_get/rpm_put into i915_gem_release_mmap()
and split out the RPM-suspend only i915_gem_release_all_mmaps() (if I
can think of a good name to better distinguish the two I'll do that as
well). The benefit being is that instead of simply asserting in one that
we hold the rpm-wakeref we take it.

i915_gem_runtime_suspend__mmaps() ?
-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] drm/i915: Assert we hold the CRTC powerwell for generating vblank interrupts

[Chris Wilson]

On Thu, Oct 13, 2016 at 04:17:07PM +0200, Daniel Vetter wrote:
> On Wed, Oct 12, 2016 at 07:21:44AM +0200, Maarten Lankhorst wrote:
> > I don't see a nice way to do this, it probably means we shouldn't do this 
> > at all..
> > Maybe have a function look at 
> > dev_priv->power_domains.domain_use_count[[POWER_DOMAIN_PIPE(pipe)] >= 1?
> > It's potentially racy but I don't see a nice way to check, apart from 
> > hoping we handle the drm vblank on/off
> > calls correctly.
> > 
> > The only other way I see is demidlayering vblank.
> 
> Or switch over power domains over to the core power domain stuff. There's
> a reason those are protected with spinlocks, so that you can do these
> kinds of checks ;-)

Why not both! They're on the wishlist somewhere.
-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/5] drm/i915: Use fence_write() from rpm resume

[Daniel Vetter]

On Wed, Oct 12, 2016 at 12:16:33PM +0100, Chris Wilson wrote:
> During rpm resume we restore the fences, but we do not have the
> protection of struct_mutex. This rules out updating the activity
> tracking on the fences, and requires us to rely on the rpm as the
> serialisation barrier instead.
> 
> [  350.298052] [drm:intel_runtime_resume [i915]] Resuming device
> [  350.308606]
> [  350.310520] ===
> [  350.315560] [ INFO: suspicious RCU usage. ]
> [  350.320554] 4.8.0-rc8-bsw-rapl+ #3133 Tainted: G U  W
> [  350.327208] ---
> [  350.331977] ../drivers/gpu/drm/i915/i915_gem_request.h:371 suspicious 
> rcu_dereference_protected() usage!
> [  350.342619]
> [  350.342619] other info that might help us debug this:
> [  350.342619]
> [  350.351593]
> [  350.351593] rcu_scheduler_active = 1, debug_locks = 0
> [  350.358952] 3 locks held by Xorg/320:
> [  350.363077]  #0:  (>mode_config.mutex){+.+.+.}, at: 
> [] drm_modeset_lock_all+0x3c/0xd0 [drm]
> [  350.375162]  #1:  (crtc_ww_class_acquire){+.+.+.}, at: 
> [] drm_modeset_lock_all+0x46/0xd0 [drm]
> [  350.387022]  #2:  (crtc_ww_class_mutex){+.+.+.}, at: [] 
> drm_modeset_lock+0x36/0x110 [drm]
> [  350.398236]
> [  350.398236] stack backtrace:
> [  350.403196] CPU: 1 PID: 320 Comm: Xorg Tainted: G U  W   
> 4.8.0-rc8-bsw-rapl+ #3133
> [  350.412457] Hardware name: Intel Corporation CHERRYVIEW C0 
> PLATFORM/Braswell CRB, BIOS BRAS.X64.X088.R00.1510270350 10/27/2015
> [  350.425212]   8801680a78c8 81332187 
> 88016c5c5000
> [  350.433611]  0001 8801680a78f8 810ca6da 
> 88016cc8b0f0
> [  350.442012]  88016cc8 88016cc8 880177ad 
> 8801680a7948
> [  350.450409] Call Trace:
> [  350.453165]  [] dump_stack+0x67/0x90
> [  350.458931]  [] lockdep_rcu_suspicious+0xea/0x120
> [  350.466002]  [] fence_update+0xbd/0x670 [i915]
> [  350.472766]  [] i915_gem_restore_fences+0x52/0x70 [i915]
> [  350.480496]  [] vlv_resume_prepare+0x72/0x570 [i915]
> [  350.487839]  [] intel_runtime_resume+0x102/0x210 [i915]
> [  350.495442]  [] pci_pm_runtime_resume+0x7f/0xb0
> [  350.502274]  [] ? pci_restore_standard_config+0x40/0x40
> [  350.509883]  [] __rpm_callback+0x35/0x70
> [  350.516037]  [] ? pci_restore_standard_config+0x40/0x40
> [  350.523646]  [] rpm_callback+0x24/0x80
> [  350.529604]  [] ? pci_restore_standard_config+0x40/0x40
> [  350.537212]  [] rpm_resume+0x4ad/0x740
> [  350.543161]  [] __pm_runtime_resume+0x51/0x80
> [  350.549824]  [] intel_runtime_pm_get+0x28/0x90 [i915]
> [  350.557265]  [] intel_display_power_get+0x23/0x50 [i915]
> [  350.565001]  [] intel_atomic_commit_tail+0xdfd/0x10b0 
> [i915]
> [  350.573106]  [] ? 
> drm_atomic_helper_swap_state+0x159/0x300 [drm_kms_helper]
> [  350.582659]  [] ? _raw_spin_unlock+0x31/0x50
> [  350.589205]  [] ? 
> drm_atomic_helper_swap_state+0x159/0x300 [drm_kms_helper]
> [  350.598787]  [] intel_atomic_commit+0x3b5/0x500 [i915]
> [  350.606319]  [] ? 
> drm_atomic_set_crtc_for_connector+0xcc/0x100 [drm]
> [  350.615209]  [] drm_atomic_commit+0x49/0x50 [drm]
> [  350.622242]  [] drm_atomic_helper_set_config+0x88/0xc0 
> [drm_kms_helper]
> [  350.631419]  [] drm_mode_set_config_internal+0x6c/0x120 
> [drm]
> [  350.639623]  [] drm_mode_setcrtc+0x22c/0x4d0 [drm]
> [  350.646760]  [] drm_ioctl+0x209/0x460 [drm]
> [  350.653217]  [] ? drm_mode_getcrtc+0x150/0x150 [drm]
> [  350.660536]  [] ? __lock_is_held+0x4a/0x70
> [  350.666885]  [] do_vfs_ioctl+0x93/0x6b0
> [  350.672939]  [] ? __fget+0x113/0x200
> [  350.678797]  [] ? __fget+0x5/0x200
> [  350.684361]  [] SyS_ioctl+0x44/0x80
> [  350.690030]  [] do_syscall_64+0x5b/0x120
> [  350.696184]  [] entry_SYSCALL64_slow_path+0x25/0x25
> 
> Note we also have to remember the lesson from commit 4fc788f5ee3d
> ("drm/i915: Flush delayed fence releases after reset") where we have to
> flush any changes to the fence on restore.
> 
> v2: Replace call to release user mmaps with an assertion that they have
> already been zapped.
> 
> Fixes: 49ef5294cda2 ("drm/i915: Move fence tracking from object to vma")
> Reported-by: Ville Syrjälä 
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 
> Cc: Joonas Lahtinen 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_gem_fence.c | 21 +++--
>  1 file changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_fence.c 
> b/drivers/gpu/drm/i915/i915_gem_fence.c
> index 8df1fa7234e8..f7081f4b5d22 100644
> --- a/drivers/gpu/drm/i915/i915_gem_fence.c
> +++ b/drivers/gpu/drm/i915/i915_gem_fence.c
> @@ -290,6 +290,8 @@ i915_vma_put_fence(struct i915_vma *vma)
>  {
>   struct drm_i915_fence_reg *fence = vma->fence;
>  
> + assert_rpm_wakelock_held(to_i915(vma->vm->dev));
> +
>   if (!fence)
>

Re: [Intel-gfx] [CI 3/6] drm/i915: Stop the machine whilst capturing the GPU crash dump

[Chris Wilson]

On Thu, Oct 13, 2016 at 04:57:39PM +0200, Daniel Vetter wrote:
> On Wed, Oct 12, 2016 at 10:05:19AM +0100, Chris Wilson wrote:
> > The error state is purposefully racy as we expect it to be called at any
> > time and so have avoided any locking whilst capturing the crash dump.
> > However, with multi-engine GPUs and multiple CPUs, those races can
> > manifest into OOPSes as we attempt to chase dangling pointers freed on
> > other CPUs. Under discussion are lots of ways to slow down normal
> > operation in order to protect the post-mortem error capture, but what it
> > we take the opposite approach and freeze the machine whilst the error
> > capture runs (note the GPU may still running, but as long as we don't
> > process any of the results the driver's bookkeeping will be static).
> > 
> > Note that by of itself, this is not a complete fix. It also depends on
> > the compiler barriers in list_add/list_del to prevent traversing the
> > lists into the void. We also depend that we only require state from
> > carefully controlled sources - i.e. all the state we require for
> > post-mortem debugging should be reachable from the request itself so
> > that we only have to worry about retrieving the request carefully. Once
> > we have the request, we know that all pointers from it are intact.
> > 
> > v2: Avoid drm_clflush_pages() inside stop_machine() as it may use
> > stop_machine() itself for its wbinvd fallback.
> 
> Hm, won't this hurt us real bad on any atom with ppgtt? Maybe a big check
> gen check with a scary comment about why we can't call drm_clflush_pages
> on old machines? Iirc gen3+ should all be able to flush without
> stop_machine.

:) Patch 2 switched to using coherent reads through the GTT for all.
Everyone is now equal (and the nice part about that was that it
uncovered the WC bug from kernel 4.0!)
-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] [CI 4/6] drm/i915: Always use the GTT for error capture

[Daniel Vetter]

On Wed, Oct 12, 2016 at 10:05:20AM +0100, Chris Wilson wrote:
> Since the GTT provides universal access to any GPU page, we can use it
> to reduce our plethora of read methods to just one. It also has the
> important characteristic of being exactly what the GPU sees - if there
> are incoherency problems, seeing the batch as executed (rather than as
> trapped inside the cpu cache) is important.
> 
> Signed-off-by: Chris Wilson 
> Reviewed-by: Joonas Lahtinen 

Meh, so much for me reading patches in order ;-)

Please reorder this one before the previous one and I'll be happy too.

> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.c   |  43 
>  drivers/gpu/drm/i915/i915_gem_gtt.h   |   2 +
>  drivers/gpu/drm/i915/i915_gpu_error.c | 120 
> --
>  3 files changed, 74 insertions(+), 91 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 0bb4232f66bc..2d846aa39ca5 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -2717,6 +2717,7 @@ int i915_gem_init_ggtt(struct drm_i915_private 
> *dev_priv)
>*/
>   struct i915_ggtt *ggtt = _priv->ggtt;
>   unsigned long hole_start, hole_end;
> + struct i915_hw_ppgtt *ppgtt;
>   struct drm_mm_node *entry;
>   int ret;
>  
> @@ -2724,6 +2725,15 @@ int i915_gem_init_ggtt(struct drm_i915_private 
> *dev_priv)
>   if (ret)
>   return ret;
>  
> + /* Reserve a mappable slot for our lockless error capture */
> + ret = drm_mm_insert_node_in_range_generic(>base.mm,
> +   >error_capture,
> +   4096, 0, -1,
> +   0, ggtt->mappable_end,
> +   0, 0);
> + if (ret)
> + return ret;
> +
>   /* Clear any non-preallocated blocks */
>   drm_mm_for_each_hole(entry, >base.mm, hole_start, hole_end) {
>   DRM_DEBUG_KMS("clearing unused GTT space: [%lx, %lx]\n",
> @@ -2738,25 +2748,21 @@ int i915_gem_init_ggtt(struct drm_i915_private 
> *dev_priv)
>  true);
>  
>   if (USES_PPGTT(dev_priv) && !USES_FULL_PPGTT(dev_priv)) {
> - struct i915_hw_ppgtt *ppgtt;
> -
>   ppgtt = kzalloc(sizeof(*ppgtt), GFP_KERNEL);
> - if (!ppgtt)
> - return -ENOMEM;
> + if (!ppgtt) {
> + ret = -ENOMEM;
> + goto err;
> + }
>  
>   ret = __hw_ppgtt_init(ppgtt, dev_priv);
> - if (ret) {
> - kfree(ppgtt);
> - return ret;
> - }
> + if (ret)
> + goto err_ppgtt;
>  
> - if (ppgtt->base.allocate_va_range)
> + if (ppgtt->base.allocate_va_range) {
>   ret = ppgtt->base.allocate_va_range(>base, 0,
>   ppgtt->base.total);
> - if (ret) {
> - ppgtt->base.cleanup(>base);
> - kfree(ppgtt);
> - return ret;
> + if (ret)
> + goto err_ppgtt_cleanup;
>   }
>  
>   ppgtt->base.clear_range(>base,
> @@ -2770,6 +2776,14 @@ int i915_gem_init_ggtt(struct drm_i915_private 
> *dev_priv)
>   }
>  
>   return 0;
> +
> +err_ppgtt_cleanup:
> + ppgtt->base.cleanup(>base);
> +err_ppgtt:
> + kfree(ppgtt);
> +err:
> + drm_mm_remove_node(>error_capture);
> + return ret;
>  }
>  
>  /**
> @@ -2788,6 +2802,9 @@ void i915_ggtt_cleanup_hw(struct drm_i915_private 
> *dev_priv)
>  
>   i915_gem_cleanup_stolen(_priv->drm);
>  
> + if (drm_mm_node_allocated(>error_capture))
> + drm_mm_remove_node(>error_capture);
> +
>   if (drm_mm_initialized(>base.mm)) {
>   intel_vgt_deballoon(dev_priv);
>  
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
> b/drivers/gpu/drm/i915/i915_gem_gtt.h
> index ec78be2f8c77..bd93fb8f99d2 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> @@ -450,6 +450,8 @@ struct i915_ggtt {
>   bool do_idle_maps;
>  
>   int mtrr;
> +
> + struct drm_mm_node error_capture;
>  };
>  
>  struct i915_hw_ppgtt {
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 159d6d7e0cee..b3b2e6c1c6c6 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -656,7 +656,7 @@ static void i915_error_object_free(struct 
> drm_i915_error_object *obj)
>   return;
>  
>   for (page = 0; page < obj->page_count; page++)
> - kfree(obj->pages[page]);
> + 

Re: [Intel-gfx] [PATCH] drm: Print device information again in debugfs

[Chris Wilson]

On Thu, Oct 13, 2016 at 04:13:44PM +0200, Daniel Vetter wrote:
> I was a bit over-eager in my cleanup in
> 
> commit 95c081c17f284de50eaca60d4d55643a64d39019
> Author: Daniel Vetter 
> Date:   Tue Jun 21 10:54:12 2016 +0200
> 
> drm: Move master pointer from drm_minor to drm_device
> 
> Noticed by Chris Wilson.
> 
> Fixes: 95c081c17f28 ("drm: Move master pointer from drm_minor to drm_device")
> Cc: Chris Wilson 
> Cc: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Emil Velikov 
> Cc: Julia Lawall 
> Signed-off-by: Daniel Vetter 
Tested-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] drm/i915: Skip unbinding large unmappable global buffers

[Chris Wilson]

On Thu, Oct 13, 2016 at 03:13:51PM +0100, Tvrtko Ursulin wrote:
> 
> On 13/10/2016 13:59, Chris Wilson wrote:
> >On Thu, Oct 13, 2016 at 12:29:44PM +0100, Tvrtko Ursulin wrote:
> >>On 13/10/2016 09:55, Chris Wilson wrote:
> >>>If the user requests a mappable binding to the global GTT, we will first
> >>>unbind an existing mapping if it doesn't match. We will unbind even if
> >>>there is no possibility that the object can fit in the mappable
> >>>aperture. This may lead to a ping-pong migration of the object, for
> >>>example igt/gem_exec_big.
> >>>
> >>>Testcase: igt/gem_exec_big
> >>>Signed-off-by: Chris Wilson 
> >>>---
> >>>  drivers/gpu/drm/i915/i915_gem.c | 19 ++-
> >>>  1 file changed, 18 insertions(+), 1 deletion(-)
> >>>
> >>>diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> >>>b/drivers/gpu/drm/i915/i915_gem.c
> >>>index 2f939f90984b..f33aa9bb95c0 100644
> >>>--- a/drivers/gpu/drm/i915/i915_gem.c
> >>>+++ b/drivers/gpu/drm/i915/i915_gem.c
> >>>@@ -3144,6 +3144,9 @@ search_free:
> >>>   goto err_unpin;
> >>>   }
> >>>+
> >>>+  GEM_BUG_ON(vma->node.start < start);
> >>>+  GEM_BUG_ON(vma->node.start + vma->node.size > end);
> >>>   }
> >>>   GEM_BUG_ON(!i915_gem_valid_gtt_space(vma, obj->cache_level));
> >>>@@ -3843,7 +3846,8 @@ i915_gem_object_ggtt_pin(struct drm_i915_gem_object 
> >>>*obj,
> >>>u64 alignment,
> >>>u64 flags)
> >>>  {
> >>>-  struct i915_address_space *vm = _i915(obj->base.dev)->ggtt.base;
> >>>+  struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
> >>>+  struct i915_address_space *vm = _priv->ggtt.base;
> >>>   struct i915_vma *vma;
> >>>   int ret;
> >>>@@ -3858,6 +3862,19 @@ i915_gem_object_ggtt_pin(struct drm_i915_gem_object 
> >>>*obj,
> >>>   (i915_vma_is_pinned(vma) || i915_vma_is_active(vma)))
> >>>   return ERR_PTR(-ENOSPC);
> >>>+  if (flags & PIN_MAPPABLE) {
> >>>+  u32 fence_size;
> >>>+
> >>>+  fence_size = i915_gem_get_ggtt_size(dev_priv, vma->size,
> >>>+  
> >>>i915_gem_object_get_tiling(obj));
> >>>+  if (fence_size > dev_priv->ggtt.mappable_end)
> >>>+  return ERR_PTR(-E2BIG);
> >>>+
> >>>+  if (flags & PIN_NONBLOCK &&
> >>>+  fence_size > dev_priv->ggtt.mappable_end / 2)
> >>>+  return ERR_PTR(-ENOSPC);
> >>One half of aperture is a magic number or something else?
> >Magic number. NONBLOCK means try, we have a fallback planned.
> >
> >It more or less comes from the old habit of having to assume that all
> >fences take up twice the space we expect due to alignment. And given
> >NONBLOCK means that we should have a better fallback than evicting the
> >majority of the aperture on a whim.
> 
> Ok I couldn't not think of any potential bad interactions.
> 
> If you add a comment explaining the reasoning:

Felt in the mood to write a few sentences. Hopefully they make sense in
the morning. Thanks,
-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] [CI 3/6] drm/i915: Stop the machine whilst capturing the GPU crash dump

[Daniel Vetter]

On Wed, Oct 12, 2016 at 10:05:19AM +0100, Chris Wilson wrote:
> The error state is purposefully racy as we expect it to be called at any
> time and so have avoided any locking whilst capturing the crash dump.
> However, with multi-engine GPUs and multiple CPUs, those races can
> manifest into OOPSes as we attempt to chase dangling pointers freed on
> other CPUs. Under discussion are lots of ways to slow down normal
> operation in order to protect the post-mortem error capture, but what it
> we take the opposite approach and freeze the machine whilst the error
> capture runs (note the GPU may still running, but as long as we don't
> process any of the results the driver's bookkeeping will be static).
> 
> Note that by of itself, this is not a complete fix. It also depends on
> the compiler barriers in list_add/list_del to prevent traversing the
> lists into the void. We also depend that we only require state from
> carefully controlled sources - i.e. all the state we require for
> post-mortem debugging should be reachable from the request itself so
> that we only have to worry about retrieving the request carefully. Once
> we have the request, we know that all pointers from it are intact.
> 
> v2: Avoid drm_clflush_pages() inside stop_machine() as it may use
> stop_machine() itself for its wbinvd fallback.

Hm, won't this hurt us real bad on any atom with ppgtt? Maybe a big check
gen check with a scary comment about why we can't call drm_clflush_pages
on old machines? Iirc gen3+ should all be able to flush without
stop_machine.

With that addressed you can upgrade to Reviewed-by: Daniel Vetter
, but I think Mika should ack this too.
-Daniel

> 
> Signed-off-by: Chris Wilson 
> Acked-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/Kconfig  |  1 +
>  drivers/gpu/drm/i915/i915_drv.h   |  2 ++
>  drivers/gpu/drm/i915/i915_gpu_error.c | 46 
> +--
>  3 files changed, 31 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 8844b99bd760..3eff42e4a441 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -4,6 +4,7 @@ config DRM_I915
>   depends on X86 && PCI
>   select INTEL_GTT
>   select INTERVAL_TREE
> + select STOP_MACHINE
>   # we need shmfs for the swappable backing store, and in particular
>   # the shmem_readpage() which depends upon tmpfs
>   select SHMEM
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 380590b30bbf..4199e8aa436a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -746,6 +746,8 @@ struct drm_i915_error_state {
>   struct kref ref;
>   struct timeval time;
>  
> + struct drm_i915_private *i915;
> +
>   char error_msg[128];
>   bool simulated;
>   int iommu;
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index c88c0d192a60..159d6d7e0cee 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -28,6 +28,7 @@
>   */
>  
>  #include 
> +#include 
>  #include "i915_drv.h"
>  
>  static const char *engine_str(int engine)
> @@ -744,14 +745,12 @@ i915_error_object_create(struct drm_i915_private 
> *dev_priv,
>  
>   dst->page_count = num_pages;
>   while (num_pages--) {
> - unsigned long flags;
>   void *d;
>  
>   d = kmalloc(PAGE_SIZE, GFP_ATOMIC);
>   if (d == NULL)
>   goto unwind;
>  
> - local_irq_save(flags);
>   if (use_ggtt) {
>   void __iomem *s;
>  
> @@ -770,15 +769,10 @@ i915_error_object_create(struct drm_i915_private 
> *dev_priv,
>  
>   page = i915_gem_object_get_page(src, i);
>  
> - drm_clflush_pages(, 1);
> -
>   s = kmap_atomic(page);
>   memcpy(d, s, PAGE_SIZE);
>   kunmap_atomic(s);
> -
> - drm_clflush_pages(, 1);
>   }
> - local_irq_restore(flags);
>  
>   dst->pages[i++] = d;
>   reloc_offset += PAGE_SIZE;
> @@ -1447,6 +1441,31 @@ static void i915_capture_gen_state(struct 
> drm_i915_private *dev_priv,
>  sizeof(error->device_info));
>  }
>  
> +static int capture(void *data)
> +{
> + struct drm_i915_error_state *error = data;
> +
> + /* Ensure that what we readback from memory matches what the GPU sees */
> + wbinvd();
> +
> + i915_capture_gen_state(error->i915, error);
> + i915_capture_reg_state(error->i915, error);
> + i915_gem_record_fences(error->i915, error);
> + i915_gem_record_rings(error->i915, error);
> + i915_capture_active_buffers(error->i915, error);
> + i915_capture_pinned_buffers(error->i915, 

Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general

[Jeff McGee]

Reviewed-by: Jeff McGee 

On Mon, Oct 03, 2016 at 11:42:55AM -0700, Anusha Srivatsa wrote:
> From: Peter Antoine 
> 
> Rename some of the GuC fw loading code to make them more general. We
> will utilise them for HuC loading as well.
>  s/intel_guc_fw/intel_uc_fw/g
>  s/GUC_FIRMWARE/UC_FIRMWARE/g
> 
> Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,
> such as 'guc' or 'guc_fw' either is renamed to 'uc' or removed for
> same purpose.
> 
> v2: rebased on top of nightly.
> reapplied the search/replace as upstream code as changed.
> v3: rebased again on drm-nightly.
> v4: removed G from messages in shared fw fetch function.
> v5: rebased.
> v7: rebased.
> v8: rebased.
> 
> Signed-off-by: Anusha Srivatsa 
> Signed-off-by: Alex Dai 
> Signed-off-by: Peter Antoine 
> Reviewed-by: Dave Gordon 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c|  12 +--
>  drivers/gpu/drm/i915/i915_guc_submission.c |   4 +-
>  drivers/gpu/drm/i915/intel_guc.h   |  39 
>  drivers/gpu/drm/i915/intel_guc_loader.c| 156 
> ++---
>  4 files changed, 106 insertions(+), 105 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 4fb9d82..44258a8 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2416,7 +2416,7 @@ static int i915_llc(struct seq_file *m, void *data)
>  static int i915_guc_load_status_info(struct seq_file *m, void *data)
>  {
>   struct drm_i915_private *dev_priv = node_to_i915(m->private);
> - struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
> + struct intel_uc_fw *guc_fw = _priv->guc.guc_fw;
>   u32 tmp, i;
>  
>   if (!HAS_GUC_UCODE(dev_priv))
> @@ -2424,15 +2424,15 @@ static int i915_guc_load_status_info(struct seq_file 
> *m, void *data)
>  
>   seq_printf(m, "GuC firmware status:\n");
>   seq_printf(m, "\tpath: %s\n",
> - guc_fw->guc_fw_path);
> + guc_fw->uc_fw_path);
>   seq_printf(m, "\tfetch: %s\n",
> - intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status));
> + intel_uc_fw_status_repr(guc_fw->fetch_status));
>   seq_printf(m, "\tload: %s\n",
> - intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
> + intel_uc_fw_status_repr(guc_fw->load_status));
>   seq_printf(m, "\tversion wanted: %d.%d\n",
> - guc_fw->guc_fw_major_wanted, guc_fw->guc_fw_minor_wanted);
> + guc_fw->major_ver_wanted, guc_fw->minor_ver_wanted);
>   seq_printf(m, "\tversion found: %d.%d\n",
> - guc_fw->guc_fw_major_found, guc_fw->guc_fw_minor_found);
> + guc_fw->major_ver_found, guc_fw->minor_ver_found);
>   seq_printf(m, "\theader: offset is %d; size = %d\n",
>   guc_fw->header_offset, guc_fw->header_size);
>   seq_printf(m, "\tuCode: offset is %d; size = %d\n",
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
> b/drivers/gpu/drm/i915/i915_guc_submission.c
> index 43358e1..4b92943 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -1072,7 +1072,7 @@ int intel_guc_suspend(struct drm_device *dev)
>   struct i915_gem_context *ctx;
>   u32 data[3];
>  
> - if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
> + if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS)
>   return 0;
>  
>   ctx = dev_priv->kernel_context;
> @@ -1098,7 +1098,7 @@ int intel_guc_resume(struct drm_device *dev)
>   struct i915_gem_context *ctx;
>   u32 data[3];
>  
> - if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
> + if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS)
>   return 0;
>  
>   ctx = dev_priv->kernel_context;
> diff --git a/drivers/gpu/drm/i915/intel_guc.h 
> b/drivers/gpu/drm/i915/intel_guc.h
> index b1ba869..b134a41 100644
> --- a/drivers/gpu/drm/i915/intel_guc.h
> +++ b/drivers/gpu/drm/i915/intel_guc.h
> @@ -91,29 +91,29 @@ struct i915_guc_client {
>   uint64_t submissions[I915_NUM_ENGINES];
>  };
>  
> -enum intel_guc_fw_status {
> - GUC_FIRMWARE_FAIL = -1,
> - GUC_FIRMWARE_NONE = 0,
> - GUC_FIRMWARE_PENDING,
> - GUC_FIRMWARE_SUCCESS
> +enum intel_uc_fw_status {
> + UC_FIRMWARE_FAIL = -1,
> + UC_FIRMWARE_NONE = 0,
> + UC_FIRMWARE_PENDING,
> + UC_FIRMWARE_SUCCESS
>  };
>  
>  /*
>   * This structure encapsulates all the data needed during the process
>   * of fetching, caching, and loading the firmware image into the GuC.
>   */
> -struct intel_guc_fw {
> - struct drm_device * guc_dev;
> - const char *guc_fw_path;
> - size_t  guc_fw_size;
> - struct drm_i915_gem_object *guc_fw_obj;
> - 

Re: [Intel-gfx] [maintainer-tools PATCH 6/6] dim: add command to check for dim updates

[Daniel Vetter]

On Tue, Oct 11, 2016 at 04:07:30PM +0300, Jani Nikula wrote:
> On Tue, 11 Oct 2016, Daniel Vetter  wrote:
> > On Tue, Oct 11, 2016 at 11:47:32AM +0300, Jani Nikula wrote:
> >> Add a command to check if the user is running an up-to-date version of
> >> dim.
> >> 
> >> Signed-off-by: Jani Nikula 
> >> ---
> >>  dim | 21 +
> >>  dim.rst |  4 
> >>  2 files changed, 25 insertions(+)
> >> 
> >> diff --git a/dim b/dim
> >> index bef7bb6c401b..5fb3a0fee7ff 100755
> >> --- a/dim
> >> +++ b/dim
> >> @@ -179,6 +179,27 @@ if [ "$subcommand" != "setup" -a "$subcommand" != 
> >> "help" -a "$subcommand" != "us
> >>xargs -n 1 echo | grep '^origin' | sed -e 's/^origin\///'`
> >>  fi
> >>  
> >> +function dim_uptodate
> >> +{
> >> +  local using="${BASH_SOURCE[0]}"
> >> +
> >> +  if [[ ! -e "$using" ]]; then
> >> +  echo "$dim: could not figure out the version being used 
> >> ($using)." >&2
> >> +  exit 1
> >> +  fi
> >> +
> >> +  if [[ ! -e "$DIM_PREFIX/maintainer-tools/.git" ]]; then
> >> +  echo "$dim: could not find the upstream repo for $dim." >&2
> >> +  exit 1
> >> +  fi
> >> +
> >> +  if ! git --git-dir=$DIM_PREFIX/maintainer-tools/.git show 
> >> origin/maintainer-tools:dim |\
> >> +  diff "$using" - >& /dev/null; then
> >> +  echo "$dim: not running upstream version of the script." >&2
> >> +  exit 1
> >> +  fi
> >> +}
> >
> > Should we run this at startup every once in a while? Something like
> >
> > if [[ "$((`date +%s` % 100))" -eq "0" ]] ; then
> > dim_uptodate
> > fi
> >
> > at the top? date-based rng tested, otherwise not ...
> 
> I had something like that in mind at first, but decided to be less
> obnoxious for starters. ;)

Oh, the real obnoxious version would auto-update dim if it's not
up-to-date ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Remove superfluous locking around userfault_list

[Daniel Vetter]

On Tue, Oct 11, 2016 at 03:37:59PM +0100, Chris Wilson wrote:
> Now that we have reduced the access to the list to either (a) under the
> struct_mutex whilst holding the RPM wakeref (so that concurrent writers to
> the list are serialised by struct_mutex) and (b) under the atomic
> runtime suspend (which cannot run concurrently with any other accessor due
> to the atomic nature of the runtime suspend) we can remove the extra
> locking around the list itself.
> 
> Signed-off-by: Chris Wilson 

So this is a bit a pet peeve of mine, but when changing locking schemes
I'm trying to make an as clear as possible distinction between locking
(which is just meant to protect the integrity of data structures, like
e.g. the userfault_list here). And anything else which manages lifetimes
and resources (all the get/put stuff we have) or ordering/sequence
(waiting, waking up other stuff and all that).

The reason for that is that with a BKL it is super easy to smash all these
things into one, but if you have locking that also keeps stuff alive and
guarantees ordering (or the other way round) it becomes nigh to impossible
to untangle.

Hence why I don't like this.
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_drv.h |  3 ---
>  drivers/gpu/drm/i915/i915_gem.c | 21 -
>  2 files changed, 4 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 72b3126c6c74..13ca968a760a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1359,9 +1359,6 @@ struct i915_gem_mm {
>*/
>   struct list_head unbound_list;
>  
> - /** Protects access to the userfault_list */
> - spinlock_t userfault_lock;
> -
>   /** List of all objects in gtt_space, currently mmaped by userspace.
>* All objects within this list must also be on bound_list.
>*/
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 587a91af5a3f..a268e804005c 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1853,9 +1853,7 @@ int i915_gem_fault(struct vm_area_struct *area, struct 
> vm_fault *vmf)
>   goto err_unpin;
>  
>   assert_rpm_wakelock_held(dev_priv);
> - spin_lock(_priv->mm.userfault_lock);
>   list_add(>userfault_link, _priv->mm.userfault_list);
> - spin_unlock(_priv->mm.userfault_lock);
>  
>  err_unpin:
>   __i915_vma_unpin(vma);
> @@ -1925,7 +1923,6 @@ void
>  i915_gem_release_mmap(struct drm_i915_gem_object *obj)
>  {
>   struct drm_i915_private *i915 = to_i915(obj->base.dev);
> - bool zap = false;
>  
>   /* Serialisation between user GTT access and our code depends upon
>* revoking the CPU's PTE whilst the mutex is held. The next user
> @@ -1937,15 +1934,10 @@ i915_gem_release_mmap(struct drm_i915_gem_object *obj)
>*/
>   assert_rpm_wakelock_held(i915);
>  
> - spin_lock(>mm.userfault_lock);
> - if (!list_empty(>userfault_link)) {
> - list_del_init(>userfault_link);
> - zap = true;
> - }
> - spin_unlock(>mm.userfault_lock);
> - if (!zap)
> + if (list_empty(>userfault_link))
>   return;
>  
> + list_del_init(>userfault_link);
>   drm_vma_node_unmap(>base.vma_node,
>  obj->base.dev->anon_inode->i_mapping);
>  
> @@ -1963,13 +1955,9 @@ void
>  i915_gem_release_all_mmaps(struct drm_i915_private *dev_priv)
>  {
>   struct drm_i915_gem_object *obj, *on;
> - struct list_head userfault_list;
> -
> - spin_lock(_priv->mm.userfault_lock);
> - list_replace_init(_priv->mm.userfault_list, _list);
> - spin_unlock(_priv->mm.userfault_lock);
>  
> - list_for_each_entry_safe(obj, on, _list, userfault_link)
> + list_for_each_entry_safe(obj, on,
> +  _priv->mm.userfault_list, userfault_link)
>   i915_gem_release_mmap(obj);
>  }
>  
> @@ -4457,7 +4445,6 @@ int i915_gem_init(struct drm_device *dev)
>   int ret;
>  
>   mutex_lock(>struct_mutex);
> - spin_lock_init(_priv->mm.userfault_lock);
>  
>   if (!i915.enable_execlists) {
>   dev_priv->gt.resume = intel_legacy_submission_resume;
> -- 
> 2.9.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Use RPM as the barrier for controlling user mmap access

[Daniel Vetter]

On Tue, Oct 11, 2016 at 03:37:58PM +0100, Chris Wilson wrote:
> We can remove the false coupling between RPM and struct mutex by the
> observation that we can use the RPM wakeref as the barrier around user
> mmap access. That is as we tear down the user's PTE atomically from
> within rpm suspend and then to fault in new PTE requires the rpm
> wakeref, means that no user access is possible through those PTE without
> RPM being awake. Having made that observation, we can then remove the
> presumption of having to take rpm outside of struct_mutex and so allow
> fine grained acquisition of a wakeref around hw access rather than
> having to remember to acquire the wakeref early on.
> 
> Signed-off-by: Chris Wilson 
> Cc: Imre Deak 
> Cc: Daniel Vetter 
> Cc: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c| 22 --
>  drivers/gpu/drm/i915/i915_drv.c| 19 ---
>  drivers/gpu/drm/i915/i915_gem.c| 14 +-
>  drivers/gpu/drm/i915/i915_gem_gtt.c| 17 +
>  drivers/gpu/drm/i915/i915_gem_tiling.c |  4 
>  drivers/gpu/drm/i915/intel_uncore.c|  6 +++---
>  6 files changed, 21 insertions(+), 61 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index d4ecc5283c2a..d4779abd89e3 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1400,14 +1400,9 @@ static int i915_hangcheck_info(struct seq_file *m, 
> void *unused)
>  static int ironlake_drpc_info(struct seq_file *m)
>  {
>   struct drm_i915_private *dev_priv = node_to_i915(m->private);
> - struct drm_device *dev = _priv->drm;
>   u32 rgvmodectl, rstdbyctl;
>   u16 crstandvid;
> - int ret;
>  
> - ret = mutex_lock_interruptible(>struct_mutex);
> - if (ret)
> - return ret;
>   intel_runtime_pm_get(dev_priv);
>  
>   rgvmodectl = I915_READ(MEMMODECTL);
> @@ -1415,7 +1410,6 @@ static int ironlake_drpc_info(struct seq_file *m)
>   crstandvid = I915_READ16(CRSTANDVID);
>  
>   intel_runtime_pm_put(dev_priv);
> - mutex_unlock(>struct_mutex);
>  
>   seq_printf(m, "HD boost: %s\n", yesno(rgvmodectl & MEMMODE_BOOST_EN));
>   seq_printf(m, "Boost freq: %d\n",
> @@ -2093,12 +2087,7 @@ static const char *swizzle_string(unsigned swizzle)
>  static int i915_swizzle_info(struct seq_file *m, void *data)
>  {
>   struct drm_i915_private *dev_priv = node_to_i915(m->private);
> - struct drm_device *dev = _priv->drm;
> - int ret;
>  
> - ret = mutex_lock_interruptible(>struct_mutex);
> - if (ret)
> - return ret;
>   intel_runtime_pm_get(dev_priv);
>  
>   seq_printf(m, "bit6 swizzle for X-tiling = %s\n",
> @@ -2138,7 +2127,6 @@ static int i915_swizzle_info(struct seq_file *m, void 
> *data)
>   seq_puts(m, "L-shaped memory detected\n");
>  
>   intel_runtime_pm_put(dev_priv);
> - mutex_unlock(>struct_mutex);
>  
>   return 0;
>  }
> @@ -4797,13 +4785,9 @@ i915_wedged_set(void *data, u64 val)
>   if (i915_reset_in_progress(_priv->gpu_error))
>   return -EAGAIN;
>  
> - intel_runtime_pm_get(dev_priv);
> -
>   i915_handle_error(dev_priv, val,
> "Manually setting wedged to %llu", val);
>  
> - intel_runtime_pm_put(dev_priv);
> -
>   return 0;
>  }
>  
> @@ -5038,22 +5022,16 @@ static int
>  i915_cache_sharing_get(void *data, u64 *val)
>  {
>   struct drm_i915_private *dev_priv = data;
> - struct drm_device *dev = _priv->drm;
>   u32 snpcr;
> - int ret;
>  
>   if (!(IS_GEN6(dev_priv) || IS_GEN7(dev_priv)))
>   return -ENODEV;
>  
> - ret = mutex_lock_interruptible(>struct_mutex);
> - if (ret)
> - return ret;
>   intel_runtime_pm_get(dev_priv);
>  
>   snpcr = I915_READ(GEN6_MBCUNIT_SNPCR);
>  
>   intel_runtime_pm_put(dev_priv);
> - mutex_unlock(>struct_mutex);
>  
>   *val = (snpcr & GEN6_MBC_SNPCR_MASK) >> GEN6_MBC_SNPCR_SHIFT;
>  
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 89d322215c84..31eee32fcf6d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -2313,24 +2313,6 @@ static int intel_runtime_suspend(struct device *kdev)
>  
>   DRM_DEBUG_KMS("Suspending device\n");
>  
> - /*
> -  * We could deadlock here in case another thread holding struct_mutex
> -  * calls RPM suspend concurrently, since the RPM suspend will wait
> -  * first for this RPM suspend to finish. In this case the concurrent
> -  * RPM resume will be followed by its RPM suspend counterpart. Still
> -  * for consistency return -EAGAIN, which will reschedule this suspend.
> -  */
> - if (!mutex_trylock(>struct_mutex)) {
> - 

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Move user fault tracking to a separate list

[Daniel Vetter]

On Tue, Oct 11, 2016 at 03:37:57PM +0100, Chris Wilson wrote:
> We want to decouple RPM and struct_mutex, but currently RPM has to walk
> the list of bound objects and remove userspace mmapping before we
> suspend (otherwise userspace may continue to access the GTT whilst it is
> powered down). This currently requires the struct_mutex to walk the
> bound_list, but if we move that to a separate list and lock we can take
> the first step towards removing the struct_mutex.
> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c   |  4 ++--
>  drivers/gpu/drm/i915/i915_drv.h   | 20 +++---
>  drivers/gpu/drm/i915/i915_gem.c   | 39 
> +++
>  drivers/gpu/drm/i915/i915_gem_evict.c |  2 +-
>  4 files changed, 46 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 358663e833d6..d4ecc5283c2a 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -186,11 +186,11 @@ describe_obj(struct seq_file *m, struct 
> drm_i915_gem_object *obj)
>   }
>   if (obj->stolen)
>   seq_printf(m, " (stolen: %08llx)", obj->stolen->start);
> - if (obj->pin_display || obj->fault_mappable) {
> + if (obj->pin_display || !list_empty(>userfault_link)) {
>   char s[3], *t = s;
>   if (obj->pin_display)
>   *t++ = 'p';
> - if (obj->fault_mappable)
> + if (!list_empty(>userfault_link))
>   *t++ = 'f';
>   *t = '\0';
>   seq_printf(m, " (%s mappable)", s);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index bf397b643cc0..72b3126c6c74 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1359,6 +1359,14 @@ struct i915_gem_mm {
>*/
>   struct list_head unbound_list;
>  
> + /** Protects access to the userfault_list */
> + spinlock_t userfault_lock;
> +
> + /** List of all objects in gtt_space, currently mmaped by userspace.
> +  * All objects within this list must also be on bound_list.
> +  */
> + struct list_head userfault_list;
> +
>   /** Usable portion of the GTT for GEM */
>   unsigned long stolen_base; /* limited to low memory (32-bit) */
>  
> @@ -2215,6 +2223,11 @@ struct drm_i915_gem_object {
>   struct drm_mm_node *stolen;
>   struct list_head global_list;
>  
> + /**
> +  * Whether the object is currently in the GGTT mmap.
> +  */
> + struct list_head userfault_link;
> +
>   /** Used in execbuf to temporarily hold a ref */
>   struct list_head obj_exec_link;
>  
> @@ -2242,13 +2255,6 @@ struct drm_i915_gem_object {
>*/
>   unsigned int madv:2;
>  
> - /**
> -  * Whether the current gtt mapping needs to be mappable (and isn't just
> -  * mappable by accident). Track pin and fault separate for a more
> -  * accurate mappable working set.
> -  */
> - unsigned int fault_mappable:1;
> -
>   /*
>* Is the object to be mapped as read-only to the GPU
>* Only honoured if hardware has relevant pte bit
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index fdd496e6c081..91910ffe0964 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1850,7 +1850,10 @@ int i915_gem_fault(struct vm_area_struct *area, struct 
> vm_fault *vmf)
>   if (ret)
>   goto err_unpin;
>  
> - obj->fault_mappable = true;
> + spin_lock(_priv->mm.userfault_lock);
> + list_add(>userfault_link, _priv->mm.userfault_list);
> + spin_unlock(_priv->mm.userfault_lock);

I think we need to add it to the list _before_ we start punching in new
ptes. At least if we want to decouple the locking and rpm refcounting a
lot more (which I think we should, I had magic locks that ensure ordering
on their own simply by being a BKL). But right now it's ok, so just a
bikeshed.

> +
>  err_unpin:
>   __i915_vma_unpin(vma);
>  err_unlock:
> @@ -1918,36 +1921,52 @@ err:
>  void
>  i915_gem_release_mmap(struct drm_i915_gem_object *obj)
>  {
> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
> + bool zap = false;
> +
>   /* Serialisation between user GTT access and our code depends upon
>* revoking the CPU's PTE whilst the mutex is held. The next user
>* pagefault then has to wait until we release the mutex.
> +  *
> +  * Note that RPM complicates somewhat by adding an additional
> +  * requirement that operations to the GGTT be made holding the RPM
> +  * wakeref.
>*/
>   lockdep_assert_held(>base.dev->struct_mutex);
>  
> - if (!obj->fault_mappable)
> + spin_lock(>mm.userfault_lock);
> + if (!list_empty(>userfault_link)) {
> + 

Re: [Intel-gfx] [PATCH] drm: Print device information again in debugfs

[Alex Deucher]

On Thu, Oct 13, 2016 at 10:13 AM, Daniel Vetter  wrote:
> I was a bit over-eager in my cleanup in
>
> commit 95c081c17f284de50eaca60d4d55643a64d39019
> Author: Daniel Vetter 
> Date:   Tue Jun 21 10:54:12 2016 +0200
>
> drm: Move master pointer from drm_minor to drm_device
>
> Noticed by Chris Wilson.
>
> Fixes: 95c081c17f28 ("drm: Move master pointer from drm_minor to drm_device")
> Cc: Chris Wilson 
> Cc: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Emil Velikov 
> Cc: Julia Lawall 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/drm_info.c | 4 
>  1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c
> index 1df2d33d0b40..ffb2ab389d1d 100644
> --- a/drivers/gpu/drm/drm_info.c
> +++ b/drivers/gpu/drm/drm_info.c
> @@ -54,9 +54,6 @@ int drm_name_info(struct seq_file *m, void *data)
>
> mutex_lock(>master_mutex);
> master = dev->master;
> -   if (!master)
> -   goto out_unlock;
> -
> seq_printf(m, "%s", dev->driver->name);
> if (dev->dev)
> seq_printf(m, " dev=%s", dev_name(dev->dev));
> @@ -65,7 +62,6 @@ int drm_name_info(struct seq_file *m, void *data)
> if (dev->unique)
> seq_printf(m, " unique=%s", dev->unique);
> seq_printf(m, "\n");
> -out_unlock:
> mutex_unlock(>master_mutex);
>
> return 0;
> --
> 2.9.3
>
> ___
> 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: Allow compaction upto SWIOTLB max segment size

[Konrad Rzeszutek Wilk]

On Wed, Oct 12, 2016 at 10:51:57PM +0100, Chris Wilson wrote:
> On Wed, Oct 12, 2016 at 05:19:14PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Mon, Oct 10, 2016 at 11:27:00PM +0100, Chris Wilson wrote:
> > > commit 1625e7e549c5 ("drm/i915: make compact dma scatter lists creation
> > > work with SWIOTLB backend") took a heavy handed approach to undo the
> > > scatterlist compaction in the face of SWIOTLB. (The compaction hit a bug
> > > whereby we tried to pass a segment larger than SWIOTLB could handle.) We
> > > can be a little more intelligent and try compacting the scatterlist up
> > > to the maximum SWIOTLB segment size (when using SWIOTLB).
> > > 
> > 
> > Won't this cause a bigger usage of the SWIOTLB bounce buffer ?
> 
> It won't change the frequency of the usage of the bounce buffer, if that
> is what you mean. Either you have intel-iommu and so will not go through
> swiotlb, or you are forced to use swiotlb even though the hw doesn't
> require it (swiotlb config is byzantium and always enabled unless you
> hack it out and can rejoice at the lower cpu usage).

Hahah. Wish that was possible.

Anyhow my concern was with it under Xen, since the page_to_pfn(page) != last_pfn
check is useless there (the PFNs may be contingous but underneath
the machine frame numbers may be discontingous).

And was thinking that this check should be moved to some form of 'DMA-API'
type check, but that screams to me lots of work.

Perhaps expose another swiotlb call to query the preferred size of the
segments. So that you can get the 128 under baremetal SWIOTLB but under Xen
it may expose 1.

But that should not hold up this patch, and can be a followup patch I can
write.

Anyhow for *this* patch:

Acked-by: Konrad Rzeszutek Wilk 

[as [xen,]swiotlb maintainer, in case you need this].
> -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] drm: Print device information again in debugfs

[Daniel Vetter]

I was a bit over-eager in my cleanup in

commit 95c081c17f284de50eaca60d4d55643a64d39019
Author: Daniel Vetter 
Date:   Tue Jun 21 10:54:12 2016 +0200

drm: Move master pointer from drm_minor to drm_device

Noticed by Chris Wilson.

Fixes: 95c081c17f28 ("drm: Move master pointer from drm_minor to drm_device")
Cc: Chris Wilson 
Cc: Chris Wilson 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Cc: Julia Lawall 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_info.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c
index 1df2d33d0b40..ffb2ab389d1d 100644
--- a/drivers/gpu/drm/drm_info.c
+++ b/drivers/gpu/drm/drm_info.c
@@ -54,9 +54,6 @@ int drm_name_info(struct seq_file *m, void *data)
 
mutex_lock(>master_mutex);
master = dev->master;
-   if (!master)
-   goto out_unlock;
-
seq_printf(m, "%s", dev->driver->name);
if (dev->dev)
seq_printf(m, " dev=%s", dev_name(dev->dev));
@@ -65,7 +62,6 @@ int drm_name_info(struct seq_file *m, void *data)
if (dev->unique)
seq_printf(m, " unique=%s", dev->unique);
seq_printf(m, "\n");
-out_unlock:
mutex_unlock(>master_mutex);
 
return 0;
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Merge duplicate gen4 and vlv/chv enable vblank callbacks

[Daniel Vetter]

On Fri, Oct 07, 2016 at 08:49:52PM +0100, Chris Wilson wrote:
> gen4/vlv/chv all use the same bits in pipestat to enable the vblank
> interrupt, so they can share the same callbacks to enable/disable.
> 
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 

Irrespective of patch 2 this seems nice. git made a mess of the diff, but
I think it all checks out.

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/i915_irq.c | 59 
> +++--
>  1 file changed, 28 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index bd6c8b0eeaef..1e43fe30da11 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2718,45 +2718,40 @@ void i915_handle_error(struct drm_i915_private 
> *dev_priv,
>  /* Called from drm generic code, passed 'crtc' which
>   * we use as a pipe index
>   */
> -static int i915_enable_vblank(struct drm_device *dev, unsigned int pipe)
> +static int i8xx_enable_vblank(struct drm_device *dev, unsigned int pipe)
>  {
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   unsigned long irqflags;
>  
>   spin_lock_irqsave(_priv->irq_lock, irqflags);
> - if (INTEL_INFO(dev)->gen >= 4)
> - i915_enable_pipestat(dev_priv, pipe,
> -  PIPE_START_VBLANK_INTERRUPT_STATUS);
> - else
> - i915_enable_pipestat(dev_priv, pipe,
> -  PIPE_VBLANK_INTERRUPT_STATUS);
> + i915_enable_pipestat(dev_priv, pipe, PIPE_VBLANK_INTERRUPT_STATUS);
>   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
>  
>   return 0;
>  }
>  
> -static int ironlake_enable_vblank(struct drm_device *dev, unsigned int pipe)
> +static int i965_enable_vblank(struct drm_device *dev, unsigned int pipe)
>  {
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   unsigned long irqflags;
> - uint32_t bit = (INTEL_INFO(dev)->gen >= 7) ? DE_PIPE_VBLANK_IVB(pipe) :
> -  DE_PIPE_VBLANK(pipe);
>  
>   spin_lock_irqsave(_priv->irq_lock, irqflags);
> - ilk_enable_display_irq(dev_priv, bit);
> + i915_enable_pipestat(dev_priv, pipe,
> +  PIPE_START_VBLANK_INTERRUPT_STATUS);
>   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
>  
>   return 0;
>  }
>  
> -static int valleyview_enable_vblank(struct drm_device *dev, unsigned int 
> pipe)
> +static int ironlake_enable_vblank(struct drm_device *dev, unsigned int pipe)
>  {
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   unsigned long irqflags;
> + uint32_t bit = INTEL_GEN(dev) >= 7 ?
> + DE_PIPE_VBLANK_IVB(pipe) : DE_PIPE_VBLANK(pipe);
>  
>   spin_lock_irqsave(_priv->irq_lock, irqflags);
> - i915_enable_pipestat(dev_priv, pipe,
> -  PIPE_START_VBLANK_INTERRUPT_STATUS);
> + ilk_enable_display_irq(dev_priv, bit);
>   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
>  
>   return 0;
> @@ -2777,38 +2772,36 @@ static int gen8_enable_vblank(struct drm_device *dev, 
> unsigned int pipe)
>  /* Called from drm generic code, passed 'crtc' which
>   * we use as a pipe index
>   */
> -static void i915_disable_vblank(struct drm_device *dev, unsigned int pipe)
> +static void i8xx_disable_vblank(struct drm_device *dev, unsigned int pipe)
>  {
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   unsigned long irqflags;
>  
>   spin_lock_irqsave(_priv->irq_lock, irqflags);
> - i915_disable_pipestat(dev_priv, pipe,
> -   PIPE_VBLANK_INTERRUPT_STATUS |
> -   PIPE_START_VBLANK_INTERRUPT_STATUS);
> + i915_disable_pipestat(dev_priv, pipe, PIPE_VBLANK_INTERRUPT_STATUS);
>   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
>  }
>  
> -static void ironlake_disable_vblank(struct drm_device *dev, unsigned int 
> pipe)
> +static void i965_disable_vblank(struct drm_device *dev, unsigned int pipe)
>  {
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   unsigned long irqflags;
> - uint32_t bit = (INTEL_INFO(dev)->gen >= 7) ? DE_PIPE_VBLANK_IVB(pipe) :
> -  DE_PIPE_VBLANK(pipe);
>  
>   spin_lock_irqsave(_priv->irq_lock, irqflags);
> - ilk_disable_display_irq(dev_priv, bit);
> + i915_disable_pipestat(dev_priv, pipe,
> +   PIPE_START_VBLANK_INTERRUPT_STATUS);
>   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
>  }
>  
> -static void valleyview_disable_vblank(struct drm_device *dev, unsigned int 
> pipe)
> +static void ironlake_disable_vblank(struct drm_device *dev, unsigned int 
> pipe)
>  {
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   unsigned long irqflags;
> + uint32_t bit = INTEL_GEN(dev) >= 7 ?
> + 

Re: [Intel-gfx] [PATCH] drm/i915: Assert we hold the CRTC powerwell for generating vblank interrupts

[Daniel Vetter]

On Wed, Oct 12, 2016 at 07:21:44AM +0200, Maarten Lankhorst wrote:
> Op 11-10-16 om 10:32 schreef Ville Syrjälä:
> > On Tue, Oct 11, 2016 at 09:45:45AM +0200, Maarten Lankhorst wrote:
> >> Op 11-10-16 om 08:55 schreef Ville Syrjälä:
> >>> On Tue, Oct 11, 2016 at 08:17:22AM +0200, Maarten Lankhorst wrote:
>  Op 10-10-16 om 13:56 schreef Ville Syrjälä:
> > On Mon, Oct 10, 2016 at 12:46:32PM +0100, Chris Wilson wrote:
> >> On Mon, Oct 10, 2016 at 02:42:01PM +0300, Ville Syrjälä wrote:
> >>> On Mon, Oct 10, 2016 at 12:34:54PM +0100, Chris Wilson wrote:
>  To enable the vblank itself, we need to have an RPM wakeref for the 
>  mmio
>  access, and whilst generating the vblank interrupts we continue to
>  require the rpm wakeref. The assumption is that the RPM wakeref is 
>  held
>  by the display powerwell held by the active pipe. As this chain was 
>  not
>  obvious to me chasing the drm_wait_vblank ioctl, document it with a 
>  WARN
>  during *_vblank_enable().
> 
>  v2: Check the display power well rather than digging inside the 
>  atomic
>  CRTC state.
> 
>  Signed-off-by: Chris Wilson 
>  Cc: Ville Syrjälä 
>  Cc: Maarten Lankhorst 
>  ---
>   drivers/gpu/drm/i915/i915_irq.c | 20 
>   1 file changed, 20 insertions(+)
> 
>  diff --git a/drivers/gpu/drm/i915/i915_irq.c 
>  b/drivers/gpu/drm/i915/i915_irq.c
>  index 1e43fe30da11..f0f17055dbb9 100644
>  --- a/drivers/gpu/drm/i915/i915_irq.c
>  +++ b/drivers/gpu/drm/i915/i915_irq.c
>  @@ -2715,6 +2715,14 @@ void i915_handle_error(struct 
>  drm_i915_private *dev_priv,
>   i915_reset_and_wakeup(dev_priv);
>   }
>   
>  +static void assert_pipe_is_awake(struct drm_i915_private *dev_priv,
>  + enum pipe pipe)
>  +{
>  +WARN_ON(IS_ENABLED(CONFIG_DRM_I915_DEBUG) &&
>  +!intel_display_power_is_enabled(dev_priv,
>  +
>  POWER_DOMAIN_PIPE(pipe)));
> >>> Uses a mutex. And having a power well enabled doesn't mean much. It
> >>> doesn't guarantee that vblanks work.
> >> Impasse. :|
> >>
> >> There should be no point in an explicit assert_rpm_wakeref here as the
> >> register access should catch an error there. Is there no safe way we 
> >> can
> >> assert the current state of the CRTC is correct for enabling vblanks?
> > crtc->active might be the closest thing, if we just ignore any locking.
> > Though it looks like that has gone a bit mad these days, what with being
> > set from the .crtc_enable() hooks but getting cleared outside the
> > .crtc_disable() hooks.
> >
>  I'm trying to kill crtc->active.
> >>> Because it's evil? I still don't see much problem in having a thing to
> >>> track the state of each pipe fairly accurately.
> >>>
>  Maybe you'd want to use dev_priv->active_crtcs, but that won't save you 
>  if you enable interrupts in between atomic commit and .crtc_disable
> >>> Nothing atomic based will work well because the state is not flipped at
> >>> the same time as the actual hardware state changes.
> >>>
>  Safest bet is to look at the power state I think.
> >>> I don't know which power state you mean, but I already shot down the
> >>> power domain thing.
> >>>
> >>>
> >> I would say use assert_pipe_enabled then.
> > Nope. That one frobs with power domains too these days.
> >
> I don't see a nice way to do this, it probably means we shouldn't do this at 
> all..
> Maybe have a function look at 
> dev_priv->power_domains.domain_use_count[[POWER_DOMAIN_PIPE(pipe)] >= 1?
> It's potentially racy but I don't see a nice way to check, apart from hoping 
> we handle the drm vblank on/off
> calls correctly.
> 
> The only other way I see is demidlayering vblank.

Or switch over power domains over to the core power domain stuff. There's
a reason those are protected with spinlocks, so that you can do these
kinds of checks ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Skip unbinding large unmappable global buffers

[Tvrtko Ursulin]

On 13/10/2016 13:59, Chris Wilson wrote:

On Thu, Oct 13, 2016 at 12:29:44PM +0100, Tvrtko Ursulin wrote:

On 13/10/2016 09:55, Chris Wilson wrote:

If the user requests a mappable binding to the global GTT, we will first
unbind an existing mapping if it doesn't match. We will unbind even if
there is no possibility that the object can fit in the mappable
aperture. This may lead to a ping-pong migration of the object, for
example igt/gem_exec_big.

Testcase: igt/gem_exec_big
Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_gem.c | 19 ++-
  1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2f939f90984b..f33aa9bb95c0 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3144,6 +3144,9 @@ search_free:
goto err_unpin;
}
+
+   GEM_BUG_ON(vma->node.start < start);
+   GEM_BUG_ON(vma->node.start + vma->node.size > end);
}
GEM_BUG_ON(!i915_gem_valid_gtt_space(vma, obj->cache_level));
@@ -3843,7 +3846,8 @@ i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj,
 u64 alignment,
 u64 flags)
  {
-   struct i915_address_space *vm = _i915(obj->base.dev)->ggtt.base;
+   struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
+   struct i915_address_space *vm = _priv->ggtt.base;
struct i915_vma *vma;
int ret;
@@ -3858,6 +3862,19 @@ i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj,
(i915_vma_is_pinned(vma) || i915_vma_is_active(vma)))
return ERR_PTR(-ENOSPC);
+   if (flags & PIN_MAPPABLE) {
+   u32 fence_size;
+
+   fence_size = i915_gem_get_ggtt_size(dev_priv, vma->size,
+   
i915_gem_object_get_tiling(obj));
+   if (fence_size > dev_priv->ggtt.mappable_end)
+   return ERR_PTR(-E2BIG);
+
+   if (flags & PIN_NONBLOCK &&
+   fence_size > dev_priv->ggtt.mappable_end / 2)
+   return ERR_PTR(-ENOSPC);

One half of aperture is a magic number or something else?

Magic number. NONBLOCK means try, we have a fallback planned.

It more or less comes from the old habit of having to assume that all
fences take up twice the space we expect due to alignment. And given
NONBLOCK means that we should have a better fallback than evicting the
majority of the aperture on a whim.


Ok I couldn't not think of any potential bad interactions.

If you add a comment explaining the reasoning:

Reviewed-by: Tvrtko Ursulin 

Regards,

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

Re: [Intel-gfx] [i-g-t PATCH 1/3] tests: add more checks for finding the debugfs in script based tests

[Chris Wilson]

On Thu, Oct 13, 2016 at 04:55:49PM +0300, Jani Nikula wrote:
> For whatever reason, I got a machine here where that file is empty (not
> talking about the size, but cating the file actually produces
> nothing). And I've got another machine where that is not the
> case. *scratches head*.

Appears to be Daniel's regression:

commit 95c081c17f284de50eaca60d4d55643a64d39019
Author: Daniel Vetter 
Date:   Tue Jun 21 10:54:12 2016 +0200

drm: Move master pointer from drm_minor to drm_device


Too bad my name's on it as well. :|
-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 i-g-t 1/5] tests: Use bash for debugfs_wedged and drm_lib.sh

[Daniel Vetter]

On Fri, Oct 07, 2016 at 10:15:19AM +0300, Joonas Lahtinen wrote:
> On to, 2016-10-06 at 16:36 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > debugfs_wedged and drm_lib.sh are already using bashism so switch
> > over
> > to using #!/bin/bash instead of #!/bin/sh.
> > 
> > Signed-off-by: Ville Syrjälä 
> 
> Just reminds me of my RFC to convert them all to #!/bin/sh. The final
> resolution was that all the scripts will be converted into C programs
> shortly, there was even a JIRA created for it, Daniel?

Still the plan, and I even had "volunteers" for it. Unfortunately they got
ACTed :(
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [i-g-t PATCH 1/3] tests: add more checks for finding the debugfs in script based tests

[Chris Wilson]

On Thu, Oct 13, 2016 at 04:55:49PM +0300, Jani Nikula wrote:
> On Thu, 13 Oct 2016, Chris Wilson  wrote:
> >> +  if [ -f $debugfs_path/dri/$minor/i915_error_state ] ; then
> >> +  i915_dfs_path=$debugfs_path/dri/$minor
> >
> > Thinking of how to wean ourselves off i915_error_state; how about
> 
> That's of course independent of this series.
> 
> > if [ grep -s i915 $debugfs_path/dri/$minor/name ]; then
> 
> For whatever reason, I got a machine here where that file is empty (not
> talking about the size, but cating the file actually produces
> nothing). And I've got another machine where that is not the
> case. *scratches head*.

Is the first i915.ko builtin?
-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 02/22] drm/i915: Shrink sdvo_cmd_names

[Daniel Vetter]

On Wed, Oct 05, 2016 at 01:33:29PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Pack the struct _sdvo_cmd_name to save 736 bytes of .rodata.
> 
> This is fine since the name pointers are used only for debug.
> 
> Signed-off-by: Tvrtko Ursulin 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/intel_sdvo.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index a061b0029797..9f352aac9526 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -307,7 +307,7 @@ static bool intel_sdvo_read_byte(struct intel_sdvo 
> *intel_sdvo, u8 addr, u8 *ch)
>  static const struct _sdvo_cmd_name {
>   u8 cmd;
>   const char *name;
> -} sdvo_cmd_names[] = {
> +} __attribute__ ((packed)) sdvo_cmd_names[] = {
>   SDVO_CMD_NAME_ENTRY(SDVO_CMD_RESET),
>   SDVO_CMD_NAME_ENTRY(SDVO_CMD_GET_DEVICE_CAPS),
>   SDVO_CMD_NAME_ENTRY(SDVO_CMD_GET_FIRMWARE_REV),
> -- 
> 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 igt 1/2] lib/igt_aux: Add support for various system suspend/resume options

[Daniel Vetter]

On Wed, Oct 05, 2016 at 12:04:52PM +0300, Imre Deak wrote:
>  /* suspend/hibernate and auto-resume system */
> -void igt_system_suspend_autoresume(void);
> -void igt_system_hibernate_autoresume(void);
> +
> +enum igt_suspend_state {
> + SUSPEND_STATE_FREEZE,
> + SUSPEND_STATE_MEM,
> + SUSPEND_STATE_DISK,
> +
> + SUSPEND_STATE_NUM,
> +};
> +
> +enum igt_suspend_test {
> + SUSPEND_TEST_NONE,
> + SUSPEND_TEST_FREEZER,
> + SUSPEND_TEST_DEVICES,
> + SUSPEND_TEST_PLATFORM,
> + SUSPEND_TEST_PROCESSORS,
> + SUSPEND_TEST_CORE,
> +
> + SUSPEND_TEST_NUM,
> +};

Please document them enums too. And link from the functions to the enums
(and make sure it works):

$ ./autogen.sh --enable-gtk-doc
$ make

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

[Intel-gfx] [PATCH igt] intel-ci: CI is missing any wait tests in BAT

[Chris Wilson]

Add the two basic gem_wait tests to the fast list, together they take a
total of 1s (when correctly functioning).

Signed-off-by: Chris Wilson 
---
 tests/intel-ci/fast-feedback.testlist | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/intel-ci/fast-feedback.testlist 
b/tests/intel-ci/fast-feedback.testlist
index f59ec98..853b911 100644
--- a/tests/intel-ci/fast-feedback.testlist
+++ b/tests/intel-ci/fast-feedback.testlist
@@ -126,6 +126,8 @@ igt@gem_sync@basic-store-each
 igt@gem_tiled_blits@basic
 igt@gem_tiled_fence_blits@basic
 igt@gem_tiled_pread_basic
+igt@gem_wait@basic-busy-all
+igt@gem_wait@basic-wait-all
 igt@gem_workarounds@basic-read
 igt@gvt_basic@invalid-placeholder-test
 igt@kms_addfb_basic@addfb25-bad-modifier
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH] drm/i915/guc: Sanitory checks for platform that dont have GuC

[Paulo Zanoni]

Em Qua, 2016-10-12 às 16:13 -0700, Anusha Srivatsa escreveu:
> i915.enable_guc_loading/submission=2 forces the usage of GuC.
> For platforms that do not have a GuC, asking the kernel to
> use a GuC should not result in an error state. Do extra checks
> to see if the platform even has a GuC or not, regardless of the
> kernel parameter.
> 
> v2: Based on Rodrigo's patch and Paulo's suggestion(Paulo, Rodrigo)
> v3: Correct the Indentation(Jani, Paulo)
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97573
> 
> Cc: Rodrigo Vivi 
> Cc: Zanoni Paulo 
> Cc: Jani Nikula 
> 
> Signed-off-by: Anusha Srivatsa 
> ---
>  drivers/gpu/drm/i915/intel_guc_loader.c | 16 ++--
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
> b/drivers/gpu/drm/i915/intel_guc_loader.c
> index 7ace96b..811080f 100644
> --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> @@ -718,12 +718,16 @@ void intel_guc_init(struct drm_device *dev)
>   struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
>   const char *fw_path;
>  
> - /* A negative value means "use platform default" */
> - if (i915.enable_guc_loading < 0)
> - i915.enable_guc_loading = HAS_GUC_UCODE(dev);
> - if (i915.enable_guc_submission < 0)
> - i915.enable_guc_submission = HAS_GUC_SCHED(dev);
> -
> + if (!HAS_GUC(dev)) {
> + i915.enable_guc_loading = 0;
> + i915.enable_guc_submission = 0;
> + } else {
> + /* A negative value means "use platform default" */
> + if (i915.enable_guc_loading < 0)
> + i915.enable_guc_loading =
> HAS_GUC_UCODE(dev);
> + if (i915.enable_guc_submission < 0)
> + i915.enable_guc_submission =
> HAS_GUC_SCHED(dev);
> + }

Well, the indentation is correct now, but this patch is still removing
the blank line that was supposed to be at this spot, despite the fact
that I pointed this problem in my two previous reviews... Please always
pay attention to the reviews and try to make sure you're actually
following them when submit new versions. It's a good idea if you can
learn the patch format and look at the patch files directly in order to
spot problems like this before submitting.

I know this sounds super annoying since I'm just complaining about
blank lines, but since I expect you to start contributing much more, I
think it's worth trying to teach the coding style that's used by
everybody so the next patches all come in the expected format.

Anyway, I suppose we could amend this fix while applying the patch?

If someone fixes that while applying, we can add:
Reviewed-by: Paulo Zanoni 

>   if (!HAS_GUC_UCODE(dev)) {
>   fw_path = NULL;
>   } else if (IS_SKYLAKE(dev)) {
___
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: Add entrypoints for mapping dplls to encoders and crtcs

[Daniel Vetter]

On Tue, Oct 04, 2016 at 03:32:17PM +0300, Ander Conselvan de Oliveira wrote:
> Abstract the platform specific bits of mapping the dplls under a
> platform independ entrypoints so the differences between platforms are
> contained in the dpll code. I.e., it removes IS_PLATFORM() macros from
> other parts of the code.
> 
> Signed-off-by: Ander Conselvan de Oliveira 
> 

Not really sure this is worth it. This is all highly platform specific,
adding abstraction just means even more hoops to jump through. But I
spotted one thing while reading this. I know you're trying to consolidate
the code here, but it feels a bit too much. At least I feel like the
interactions between dpll and other code (i.e. how they link to
encoders/crtc) is best left to that code. After all it's also that code
that decides what kind of dpll setting it wants, the dpll mgr just figures
out whether one is still available.
-Daniel



> ---
>  drivers/gpu/drm/i915/intel_ddi.c  |  51 ++
>  drivers/gpu/drm/i915/intel_display.c  | 124 +-
>  drivers/gpu/drm/i915/intel_dp_mst.c   |   4 +-
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 299 
> ++
>  drivers/gpu/drm/i915/intel_dpll_mgr.h |   7 +
>  drivers/gpu/drm/i915/intel_drv.h  |   4 +-
>  6 files changed, 334 insertions(+), 155 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 4077205..144fe5c 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -319,6 +319,19 @@ enum port intel_ddi_get_encoder_port(struct 
> intel_encoder *encoder)
>   }
>  }
>  
> +struct intel_encoder *
> +intel_ddi_get_port_encoder(struct drm_i915_private *dev_priv, enum port port)
> +{
> + struct intel_encoder *encoder;
> +
> + for_each_intel_encoder(_priv->drm, encoder) {
> + if (port == intel_ddi_get_encoder_port(encoder))
> + return encoder;
> + }
> +
> + return NULL;
> +}
> +
>  static const struct ddi_buf_trans *
>  bdw_get_buf_trans_edp(struct drm_i915_private *dev_priv, int *n_entries)
>  {
> @@ -582,11 +595,12 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>   struct intel_encoder *encoder;
> - u32 temp, i, rx_ctl_val, ddi_pll_sel;
> + u32 temp, i, rx_ctl_val;
>  
>   for_each_encoder_on_crtc(dev, crtc, encoder) {
>   WARN_ON(encoder->type != INTEL_OUTPUT_ANALOG);
>   intel_prepare_dp_ddi_buffers(encoder);
> + break;
>   }
>  
>   /* Set the FDI_RX_MISC pwrdn lanes and the 2 workarounds listed at the
> @@ -613,9 +627,7 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
>   I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val);
>  
>   /* Configure Port Clock Select */
> - ddi_pll_sel = hsw_pll_to_ddi_pll_sel(intel_crtc->config->shared_dpll);
> - I915_WRITE(PORT_CLK_SEL(PORT_E), ddi_pll_sel);
> - WARN_ON(ddi_pll_sel != PORT_CLK_SEL_SPLL);
> + intel_dpll_map_to_encoder(intel_crtc->config->shared_dpll, encoder);
>  
>   /* Start the training iterating through available voltages and emphasis,
>* testing each value twice. */
> @@ -1607,33 +1619,6 @@ uint32_t ddi_signal_levels(struct intel_dp *intel_dp)
>   return DDI_BUF_TRANS_SELECT(level);
>  }
>  
> -void intel_ddi_clk_select(struct intel_encoder *encoder,
> -   struct intel_shared_dpll *pll)
> -{
> - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - enum port port = intel_ddi_get_encoder_port(encoder);
> -
> - if (WARN_ON(!pll))
> - return;
> -
> - if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
> - uint32_t val;
> -
> - /* DDI -> PLL mapping  */
> - val = I915_READ(DPLL_CTRL2);
> -
> - val &= ~(DPLL_CTRL2_DDI_CLK_OFF(port) |
> - DPLL_CTRL2_DDI_CLK_SEL_MASK(port));
> - val |= (DPLL_CTRL2_DDI_CLK_SEL(pll->id, port) |
> - DPLL_CTRL2_DDI_SEL_OVERRIDE(port));
> -
> - I915_WRITE(DPLL_CTRL2, val);
> -
> - } else if (INTEL_INFO(dev_priv)->gen < 9) {
> - I915_WRITE(PORT_CLK_SEL(port), hsw_pll_to_ddi_pll_sel(pll));
> - }
> -}
> -
>  static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
>   int link_rate, uint32_t lane_count,
>   struct intel_shared_dpll *pll,
> @@ -1648,7 +1633,7 @@ static void intel_ddi_pre_enable_dp(struct 
> intel_encoder *encoder,
>   if (encoder->type == INTEL_OUTPUT_EDP)
>   intel_edp_panel_on(intel_dp);
>  
> - intel_ddi_clk_select(encoder, pll);
> + intel_dpll_map_to_encoder(pll, encoder);
>   intel_prepare_dp_ddi_buffers(encoder);
>   intel_ddi_init_dp_buf_reg(encoder);
>   

Re: [Intel-gfx] [i-g-t PATCH 1/3] tests: add more checks for finding the debugfs in script based tests

[Jani Nikula]

On Thu, 13 Oct 2016, Chris Wilson  wrote:
> On Thu, Oct 13, 2016 at 03:59:55PM +0300, Jani Nikula wrote:
>> While at it, make debugfs_path point at the debugfs root, not
>> dri. This'll be handy in future work.
>> 
>> Signed-off-by: Jani Nikula 
>> ---
>>  tests/drm_lib.sh | 16 ++--
>>  1 file changed, 10 insertions(+), 6 deletions(-)
>> 
>> diff --git a/tests/drm_lib.sh b/tests/drm_lib.sh
>> index 113da4c7d645..87e3ad0ab547 100755
>> --- a/tests/drm_lib.sh
>> +++ b/tests/drm_lib.sh
>> @@ -41,18 +41,22 @@ do_or_die() {
>>  $@ > /dev/null 2>&1 || (echo "FAIL: $@ ($?)" && exit $IGT_EXIT_FAILURE)
>>  }
>>  
>> -if [ -d /debug/dri ] ; then
>> -debugfs_path=/debug/dri
>> +if [ -d /sys/kernel/debug ]; then
>> +debugfs_path=/sys/kernel/debug
>> +elif [ -d /debug ]; then
>> +debugfs_path=/debug
>> +else
>> +skip "debugfs not found"
>>  fi
>>  
>> -if [ -d /sys/kernel/debug/dri ] ; then
>> -debugfs_path=/sys/kernel/debug/dri
>> +if [ ! -d $debugfs_path/dri ]; then
>> +skip "dri debugfs not found"
>>  fi
>>  
>>  i915_dfs_path=x
>>  for minor in `seq 0 16`; do
>> -if [ -f $debugfs_path/$minor/i915_error_state ] ; then
>> -i915_dfs_path=$debugfs_path/$minor
>> +if [ -f $debugfs_path/dri/$minor/i915_error_state ] ; then
>> +i915_dfs_path=$debugfs_path/dri/$minor
>
> Thinking of how to wean ourselves off i915_error_state; how about

That's of course independent of this series.

>   if [ grep -s i915 $debugfs_path/dri/$minor/name ]; then

For whatever reason, I got a machine here where that file is empty (not
talking about the size, but cating the file actually produces
nothing). And I've got another machine where that is not the
case. *scratches head*.

BR,
Jani.


>
> ?
> -Chris

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for New DDB Algo and WM fixes (rev4)

[Patchwork]

== Series Details ==

Series: New DDB Algo and WM fixes (rev4)
URL   : https://patchwork.freedesktop.org/series/1/
State : warning

== Summary ==

Series 1v4 New DDB Algo and WM fixes
https://patchwork.freedesktop.org/api/1.0/series/1/revisions/4/mbox/

Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (fi-hsw-4770)
Test kms_busy:
Subgroup basic-flip-default-b:
dmesg-warn -> PASS   (fi-hsw-4770)
Subgroup basic-flip-default-c:
dmesg-warn -> PASS   (fi-hsw-4770)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
dmesg-warn -> PASS   (fi-hsw-4770)
Subgroup basic-busy-flip-before-cursor-varying-size:
dmesg-warn -> PASS   (fi-hsw-4770)
Subgroup basic-flip-after-cursor-legacy:
dmesg-warn -> PASS   (fi-hsw-4770)
Subgroup basic-flip-after-cursor-varying-size:
dmesg-warn -> PASS   (fi-hsw-4770)
Test kms_pipe_crc_basic:
Subgroup bad-nb-words-3:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup bad-pipe:
dmesg-warn -> PASS   (fi-hsw-4770)
Subgroup hang-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-hsw-4770)
Subgroup hang-read-crc-pipe-c:
dmesg-warn -> PASS   (fi-hsw-4770)
Subgroup nonblocking-crc-pipe-a:
dmesg-warn -> PASS   (fi-hsw-4770)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
dmesg-warn -> PASS   (fi-hsw-4770)
Subgroup nonblocking-crc-pipe-b:
dmesg-warn -> PASS   (fi-hsw-4770)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
dmesg-warn -> PASS   (fi-hsw-4770)
Subgroup nonblocking-crc-pipe-c:
dmesg-warn -> PASS   (fi-hsw-4770)
Subgroup nonblocking-crc-pipe-c-frame-sequence:
dmesg-warn -> PASS   (fi-hsw-4770)
Subgroup read-crc-pipe-a:
dmesg-warn -> PASS   (fi-hsw-4770)
Subgroup read-crc-pipe-b:
dmesg-warn -> PASS   (fi-hsw-4770)
Subgroup read-crc-pipe-b-frame-sequence:
dmesg-warn -> PASS   (fi-hsw-4770)
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-skl-6700k)
dmesg-warn -> PASS   (fi-byt-j1900)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-byt-j1900)
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-hsw-4770)
Test pm_rpm:
Subgroup basic-rte:
pass   -> DMESG-WARN (fi-hsw-4770)
Test vgem_basic:
Subgroup unload:
skip   -> PASS   (fi-bdw-5557u)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:213  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:221  dwarn:3   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:183  dwarn:1   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:230  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2703/

ab76ad934eba2e427d4b1db1313a9f30a009c075 drm-intel-nightly: 
2016y-10m-13d-12h-30m-12s UTC integration manifest
5f867e4 drm/i915/skl+: use linetime latency instead of ddb size

___
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: Add dpll entrypoint for dumping hw state

[Daniel Vetter]

On Tue, Oct 04, 2016 at 03:32:16PM +0300, Ander Conselvan de Oliveira wrote:
> Remove the IS_PLATFORM() macros from intel_dump_pipe_config() and split
> that logic in platform specific implementations inside the dpll code,
> accessed through a platform independent interface.
> 
> Signed-off-by: Ander Conselvan de Oliveira 
> 

Real pretty ;-)

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/intel_display.c  | 35 +---
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 79 
> +++
>  drivers/gpu/drm/i915/intel_dpll_mgr.h |  3 ++
>  3 files changed, 84 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index e6fe85b..8ecaf18 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12744,6 +12744,7 @@ static void intel_dump_pipe_config(struct intel_crtc 
> *crtc,
>  const char *context)
>  {
>   struct drm_device *dev = crtc->base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
>   struct drm_plane *plane;
>   struct intel_plane *intel_plane;
>   struct intel_plane_state *state;
> @@ -12805,39 +12806,7 @@ static void intel_dump_pipe_config(struct intel_crtc 
> *crtc,
>   DRM_DEBUG_KMS("ips: %i\n", pipe_config->ips_enabled);
>   DRM_DEBUG_KMS("double wide: %i\n", pipe_config->double_wide);
>  
> - if (IS_BROXTON(dev)) {
> - DRM_DEBUG_KMS("dpll_hw_state: ebb0: 0x%x, ebb4: 0x%x,"
> -   "pll0: 0x%x, pll1: 0x%x, pll2: 0x%x, pll3: 0x%x, "
> -   "pll6: 0x%x, pll8: 0x%x, pll9: 0x%x, pll10: 0x%x, 
> pcsdw12: 0x%x\n",
> -   pipe_config->dpll_hw_state.ebb0,
> -   pipe_config->dpll_hw_state.ebb4,
> -   pipe_config->dpll_hw_state.pll0,
> -   pipe_config->dpll_hw_state.pll1,
> -   pipe_config->dpll_hw_state.pll2,
> -   pipe_config->dpll_hw_state.pll3,
> -   pipe_config->dpll_hw_state.pll6,
> -   pipe_config->dpll_hw_state.pll8,
> -   pipe_config->dpll_hw_state.pll9,
> -   pipe_config->dpll_hw_state.pll10,
> -   pipe_config->dpll_hw_state.pcsdw12);
> - } else if (IS_SKYLAKE(dev) || IS_KABYLAKE(dev)) {
> - DRM_DEBUG_KMS("dpll_hw_state: "
> -   "ctrl1: 0x%x, cfgcr1: 0x%x, cfgcr2: 0x%x\n",
> -   pipe_config->dpll_hw_state.ctrl1,
> -   pipe_config->dpll_hw_state.cfgcr1,
> -   pipe_config->dpll_hw_state.cfgcr2);
> - } else if (HAS_DDI(dev)) {
> - DRM_DEBUG_KMS("dpll_hw_state: wrpll: 0x%x spll: 0x%x\n",
> -   pipe_config->dpll_hw_state.wrpll,
> -   pipe_config->dpll_hw_state.spll);
> - } else {
> - DRM_DEBUG_KMS("dpll_hw_state: dpll: 0x%x, dpll_md: 0x%x, "
> -   "fp0: 0x%x, fp1: 0x%x\n",
> -   pipe_config->dpll_hw_state.dpll,
> -   pipe_config->dpll_hw_state.dpll_md,
> -   pipe_config->dpll_hw_state.fp0,
> -   pipe_config->dpll_hw_state.fp1);
> - }
> + intel_dpll_dump_hw_state(dev_priv, _config->dpll_hw_state);
>  
>   DRM_DEBUG_KMS("planes on this crtc\n");
>   list_for_each_entry(plane, >mode_config.plane_list, head) {
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 8c4efa9..9b02d9c 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -447,6 +447,17 @@ ibx_get_dpll(struct intel_crtc *crtc, struct 
> intel_crtc_state *crtc_state,
>   return pll;
>  }
>  
> +static void ibx_dump_hw_state(struct drm_i915_private *dev_priv,
> +   struct intel_dpll_hw_state *hw_state)
> +{
> + DRM_DEBUG_KMS("dpll_hw_state: dpll: 0x%x, dpll_md: 0x%x, "
> +   "fp0: 0x%x, fp1: 0x%x\n",
> +   hw_state->dpll,
> +   hw_state->dpll_md,
> +   hw_state->fp0,
> +   hw_state->fp1);
> +}
> +
>  static const struct intel_shared_dpll_funcs ibx_pch_dpll_funcs = {
>   .prepare = ibx_pch_dpll_prepare,
>   .enable = ibx_pch_dpll_enable,
> @@ -833,6 +844,13 @@ hsw_get_dpll(struct intel_crtc *crtc, struct 
> intel_crtc_state *crtc_state,
>   return pll;
>  }
>  
> +static void hsw_dump_hw_state(struct drm_i915_private *dev_priv,
> +   struct intel_dpll_hw_state *hw_state)
> +{
> + DRM_DEBUG_KMS("dpll_hw_state: wrpll: 0x%x spll: 0x%x\n",
> +   

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Update kerneldoc for intel_dpll_mgr.c

[Daniel Vetter]

On Tue, Oct 04, 2016 at 03:32:15PM +0300, Ander Conselvan de Oliveira wrote:
> The documentation for most of the non-static members and structs were
> missing. Fix that.
> 
> v2: Fix typos (Durga)
> 
> v3: Rebase.
> Fix make docs warnings.
> Document more.
> 
> Signed-off-by: Ander Conselvan de Oliveira 
> 

As mentioned in an earlier patch, I think we should also move
intel_atomic_get_shared_dpll_state from intel_atomic.c into
intel_dpll_mgr.c. Grouping functions by the data structures they touch
makes imo much more sense, than grouping them by topic. That way all the
dpll stuff is in one place.

> ---
>  Documentation/gpu/i915.rst|  12 +++
>  drivers/gpu/drm/i915/intel_dpll_mgr.c |  90 ++--
>  drivers/gpu/drm/i915/intel_dpll_mgr.h | 155 
> ++
>  3 files changed, 237 insertions(+), 20 deletions(-)
> 
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 87aaffc..c19e437 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -204,6 +204,18 @@ Video BIOS Table (VBT)
>  .. kernel-doc:: drivers/gpu/drm/i915/intel_vbt_defs.h
> :internal:
>  
> +Display PLLs
> +
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/intel_dpll_mgr.c
> +   :doc: Display PLLs
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/intel_dpll_mgr.c
> +   :internal:
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/intel_dpll_mgr.h
> +   :internal:
> +
>  Memory Management and Command Submission
>  
>  
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 9446446..8c4efa9 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -23,6 +23,25 @@
>  
>  #include "intel_drv.h"
>  
> +/**
> + * DOC: Display PLLs
> + *
> + * Display PLLs used for driving outputs vary by platform. While some have
> + * per-pipe or per-encoder dedicated PLLs, others allow the use of any PLL
> + * from a pool. In the latter scenario, it is possible that multiple pipes
> + * share a PLL if their configurations match.
> + *
> + * This file provides an abstraction over display PLLs. The function
> + * intel_shared_dpll_init() initializes the PLLs for the given platform.  The
> + * users of a PLL are tracked and that tracking is integrated with the atomic
> + * modest interface. During an atomic operation, a PLL can be requested for a
> + * given crtc and encoder configuration by calling intel_get_shared_dpll() 
> and

s/crtc/CRTC/ for consistency (abbreviations are all upercase), pls do that
on the entire doc.

> + * a previously used PLL can be released with intel_release_shared_dpll().
> + * Changes to the users are first staged in the atomic state, and then made
> + * effective by calling intel_shared_dpll_swap_state() during the atomic
> + * commit phase.
> + */
> +
>  struct intel_shared_dpll *
>  skl_find_link_pll(struct drm_i915_private *dev_priv, int clock)
>  {
> @@ -61,6 +80,14 @@ skl_find_link_pll(struct drm_i915_private *dev_priv, int 
> clock)
>   return pll;
>  }
>  
> +/**
> + * intel_get_shared_dpll_by_id - get a DPLL given its id
> + * @dev_priv: i915 device instance
> + * @id: pll id
> + *
> + * Returns:
> + * A pointer to the DPLL with @id
> + */
>  struct intel_shared_dpll *
>  intel_get_shared_dpll_by_id(struct drm_i915_private *dev_priv,
>   enum intel_dpll_id id)
> @@ -68,6 +95,14 @@ intel_get_shared_dpll_by_id(struct drm_i915_private 
> *dev_priv,
>   return _priv->shared_dplls[id];
>  }
>  
> +/**
> + * intel_get_shared_dpll_id - get the id of a DPLL
> + * @dev_priv: i915 device instance
> + * @pll: the DPLL
> + *
> + * Returns:
> + * The id of @pll
> + */
>  enum intel_dpll_id
>  intel_get_shared_dpll_id(struct drm_i915_private *dev_priv,
>struct intel_shared_dpll *pll)
> @@ -96,6 +131,13 @@ void assert_shared_dpll(struct drm_i915_private *dev_priv,
>   pll->name, onoff(state), onoff(cur_state));
>  }
>  
> +/**
> + * intel_prepare_shared_dpll - call a dpll's prepare hook
> + * @crtc: crtc which has a shared dpll
> + *
> + * This calls the PLL's prepare hook if it has one and if the PLL is not
> + * already enabled. The prepare hook is platform specific.
> + */
>  void intel_prepare_shared_dpll(struct intel_crtc *crtc)
>  {
>   struct drm_device *dev = crtc->base.dev;
> @@ -118,12 +160,10 @@ void intel_prepare_shared_dpll(struct intel_crtc *crtc)
>  }
>  
>  /**
> - * intel_enable_shared_dpll - enable PCH PLL
> - * @dev_priv: i915 private structure
> - * @pipe: pipe PLL to enable
> + * intel_enable_shared_dpll - enable a crtc's shared DPLL
> + * @crtc: crtc which has a shared DPLL
>   *
> - * The PCH PLL needs to be enabled before the PCH transcoder, since it
> - * drives the transcoder clock.
> + * Enable the shared DPLL used by @crtc.
>   */
>  void 

Re: [Intel-gfx] [PATCH v2 05/10] drm/i915/gen9: Get rid of redundant watermark values

[Maarten Lankhorst]

Op 08-10-16 om 02:11 schreef Lyude:
> Now that we've make skl_wm_levels make a little more sense, we can
> remove all of the redundant wm information. Up until now we'd been
> storing two copies of all of the skl watermarks: one being the
> skl_pipe_wm structs, the other being the global wm struct in
> drm_i915_private containing the raw register values. This is confusing
> and problematic, since it means we're prone to accidentally letting the
> two copies go out of sync. So, get rid of all of the functions
> responsible for computing the register values and just use a single
> helper, skl_write_wm_level(), to convert and write the new watermarks on
> the fly.
>
> Changes since v1:
> - Fixup skl_write_wm_level()
> - Fixup skl_wm_level_from_reg_val()
> - Don't forget to copy *active to intel_crtc->wm.active.skl
>
> Signed-off-by: Lyude 
> Reviewed-by: Maarten Lankhorst 
> Cc: Ville Syrjälä 
> Cc: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |   2 -
>  drivers/gpu/drm/i915/intel_display.c |  14 ++-
>  drivers/gpu/drm/i915/intel_drv.h |   6 +-
>  drivers/gpu/drm/i915/intel_pm.c  | 204 
> ---
>  drivers/gpu/drm/i915/intel_sprite.c  |   8 +-
>  5 files changed, 90 insertions(+), 144 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 0287c93..76583b2 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1644,8 +1644,6 @@ struct skl_ddb_allocation {
>  struct skl_wm_values {
>   unsigned dirty_pipes;
>   struct skl_ddb_allocation ddb;
> - uint32_t plane[I915_MAX_PIPES][I915_MAX_PLANES][8];
> - uint32_t plane_trans[I915_MAX_PIPES][I915_MAX_PLANES];
>  };
>  
>  struct skl_wm_level {
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index a71d05a..39400a0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3378,6 +3378,8 @@ static void skylake_update_primary_plane(struct 
> drm_plane *plane,
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
>   struct drm_framebuffer *fb = plane_state->base.fb;
>   const struct skl_wm_values *wm = _priv->wm.skl_results;
> + const struct skl_plane_wm *p_wm =
> + _state->wm.skl.optimal.planes[0];
>   int pipe = intel_crtc->pipe;
>   u32 plane_ctl;
>   unsigned int rotation = plane_state->base.rotation;
> @@ -3414,7 +3416,7 @@ static void skylake_update_primary_plane(struct 
> drm_plane *plane,
>   intel_crtc->adjusted_y = src_y;
>  
>   if (wm->dirty_pipes & drm_crtc_mask(_crtc->base))
> - skl_write_plane_wm(intel_crtc, wm, 0);
> + skl_write_plane_wm(intel_crtc, p_wm, >ddb, 0);
>  
>   I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);
>   I915_WRITE(PLANE_OFFSET(pipe, 0), (src_y << 16) | src_x);
> @@ -3448,6 +3450,8 @@ static void skylake_disable_primary_plane(struct 
> drm_plane *primary,
>   struct drm_device *dev = crtc->dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state);
> + const struct skl_plane_wm *p_wm = >wm.skl.optimal.planes[0];
>   int pipe = intel_crtc->pipe;
>  
>   /*
> @@ -3455,7 +3459,8 @@ static void skylake_disable_primary_plane(struct 
> drm_plane *primary,
>* plane's visiblity isn't actually changing neither is its watermarks.
>*/
>   if (!crtc->primary->state->visible)
> - skl_write_plane_wm(intel_crtc, _priv->wm.skl_results, 0);
> + skl_write_plane_wm(intel_crtc, p_wm,
> +_priv->wm.skl_results.ddb, 0);
>  
>   I915_WRITE(PLANE_CTL(pipe, 0), 0);
>   I915_WRITE(PLANE_SURF(pipe, 0), 0);
> @@ -10819,12 +10824,15 @@ static void i9xx_update_cursor(struct drm_crtc 
> *crtc, u32 base,
>   struct drm_device *dev = crtc->dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state);
>   const struct skl_wm_values *wm = _priv->wm.skl_results;
> + const struct skl_plane_wm *p_wm =
> + >wm.skl.optimal.planes[PLANE_CURSOR];
>   int pipe = intel_crtc->pipe;
>   uint32_t cntl = 0;
>  
>   if (INTEL_GEN(dev_priv) >= 9 && wm->dirty_pipes & drm_crtc_mask(crtc))
> - skl_write_cursor_wm(intel_crtc, wm);
> + skl_write_cursor_wm(intel_crtc, p_wm, >ddb);
>  
>   if (plane_state && plane_state->base.visible) {
>   cntl = MCURSOR_GAMMA_ENABLE;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index d684f4f..958dc72 100644
> --- 

Re: [Intel-gfx] [PATCH 4/7] drm/i915: Rename intel_shared_dpll->mode_set() to prepare()

[Daniel Vetter]

On Tue, Oct 04, 2016 at 03:32:14PM +0300, Ander Conselvan de Oliveira wrote:
> The hook is called from intel_prepare_shared_dpll(). The name doesn't
> make sense after all the changes to modeset code. So just call it
> prepare.
> 
> Signed-off-by: Ander Conselvan de Oliveira 
> 
> Reviewed-by: Durgadoss R 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 8 
>  drivers/gpu/drm/i915/intel_dpll_mgr.h | 2 +-
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index c88fc07..9446446 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -112,7 +112,7 @@ void intel_prepare_shared_dpll(struct intel_crtc *crtc)
>   WARN_ON(pll->on);
>   assert_shared_dpll_disabled(dev_priv, pll);
>  
> - pll->funcs.mode_set(dev_priv, pll);
> + pll->funcs.prepare(dev_priv, pll);
>   }
>   mutex_unlock(_priv->dpll_lock);
>  }
> @@ -302,8 +302,8 @@ static bool ibx_pch_dpll_get_hw_state(struct 
> drm_i915_private *dev_priv,
>   return val & DPLL_VCO_ENABLE;
>  }
>  
> -static void ibx_pch_dpll_mode_set(struct drm_i915_private *dev_priv,
> -   struct intel_shared_dpll *pll)
> +static void ibx_pch_dpll_prepare(struct drm_i915_private *dev_priv,
> +  struct intel_shared_dpll *pll)
>  {
>   I915_WRITE(PCH_FP0(pll->id), pll->state.hw_state.fp0);
>   I915_WRITE(PCH_FP1(pll->id), pll->state.hw_state.fp1);
> @@ -392,7 +392,7 @@ ibx_get_dpll(struct intel_crtc *crtc, struct 
> intel_crtc_state *crtc_state,
>  }
>  
>  static const struct intel_shared_dpll_funcs ibx_pch_dpll_funcs = {
> - .mode_set = ibx_pch_dpll_mode_set,
> + .prepare = ibx_pch_dpll_prepare,
>   .enable = ibx_pch_dpll_enable,
>   .disable = ibx_pch_dpll_disable,
>   .get_hw_state = ibx_pch_dpll_get_hw_state,
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.h 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.h
> index 6e3a0f1..9a7db65 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.h
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.h
> @@ -101,7 +101,7 @@ struct intel_shared_dpll_state {
>  struct intel_shared_dpll_funcs {
>   /* The mode_set hook is optional and should be used together with the
>* intel_prepare_shared_dpll function. */
> - void (*mode_set)(struct drm_i915_private *dev_priv,
> + void (*prepare)(struct drm_i915_private *dev_priv,
>struct intel_shared_dpll *pll);
>   void (*enable)(struct drm_i915_private *dev_priv,
>  struct intel_shared_dpll *pll);
> -- 
> 2.5.5
> 
> ___
> 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 3/7] drm/i915: Rename intel_shared_dpll_config to intel_shared_dpll_state

[Daniel Vetter]

On Tue, Oct 04, 2016 at 03:32:13PM +0300, Ander Conselvan de Oliveira wrote:
> Struct intel_shared_dpll_config is used to hold the state of the DPLL in
> the "atomic" sense, so call it state like everything else atomic.
> 
> Signed-off-by: Ander Conselvan de Oliveira 
> 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/i915_debugfs.c   | 12 +++
>  drivers/gpu/drm/i915/intel_atomic.c   |  6 ++--
>  drivers/gpu/drm/i915/intel_ddi.c  | 10 +++---
>  drivers/gpu/drm/i915/intel_display.c  | 22 ++--
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 68 
> +--
>  drivers/gpu/drm/i915/intel_dpll_mgr.h |  4 +--
>  drivers/gpu/drm/i915/intel_drv.h  |  4 +--
>  7 files changed, 63 insertions(+), 63 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index da71413..12b97af 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -3229,14 +3229,14 @@ static int i915_shared_dplls_info(struct seq_file *m, 
> void *unused)
>  
>   seq_printf(m, "DPLL%i: %s, id: %i\n", i, pll->name, pll->id);
>   seq_printf(m, " crtc_mask: 0x%08x, active: 0x%x, on: %s\n",
> -pll->config.crtc_mask, pll->active_mask, 
> yesno(pll->on));
> +pll->state.crtc_mask, pll->active_mask, 
> yesno(pll->on));
>   seq_printf(m, " tracked hardware state:\n");
> - seq_printf(m, " dpll:0x%08x\n", pll->config.hw_state.dpll);
> + seq_printf(m, " dpll:0x%08x\n", pll->state.hw_state.dpll);
>   seq_printf(m, " dpll_md: 0x%08x\n",
> -pll->config.hw_state.dpll_md);
> - seq_printf(m, " fp0: 0x%08x\n", pll->config.hw_state.fp0);
> - seq_printf(m, " fp1: 0x%08x\n", pll->config.hw_state.fp1);
> - seq_printf(m, " wrpll:   0x%08x\n", pll->config.hw_state.wrpll);
> +pll->state.hw_state.dpll_md);
> + seq_printf(m, " fp0: 0x%08x\n", pll->state.hw_state.fp0);
> + seq_printf(m, " fp1: 0x%08x\n", pll->state.hw_state.fp1);
> + seq_printf(m, " wrpll:   0x%08x\n", pll->state.hw_state.wrpll);
>   }
>   drm_modeset_unlock_all(dev);
>  
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
> b/drivers/gpu/drm/i915/intel_atomic.c
> index c5a1667..fa6dc43 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -267,7 +267,7 @@ int intel_atomic_setup_scalers(struct drm_device *dev,
>  
>  static void
>  intel_atomic_duplicate_dpll_state(struct drm_i915_private *dev_priv,
> -   struct intel_shared_dpll_config *shared_dpll)
> +   struct intel_shared_dpll_state *shared_dpll)
>  {
>   enum intel_dpll_id i;
>  
> @@ -275,11 +275,11 @@ intel_atomic_duplicate_dpll_state(struct 
> drm_i915_private *dev_priv,
>   for (i = 0; i < dev_priv->num_shared_dpll; i++) {
>   struct intel_shared_dpll *pll = _priv->shared_dplls[i];
>  
> - shared_dpll[i] = pll->config;
> + shared_dpll[i] = pll->state;
>   }
>  }
>  
> -struct intel_shared_dpll_config *
> +struct intel_shared_dpll_state *
>  intel_atomic_get_shared_dpll_state(struct drm_atomic_state *s)
>  {
>   struct intel_atomic_state *state = to_intel_atomic_state(s);
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 35f0b7c..4077205 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -992,7 +992,7 @@ static int bxt_calc_pll_link(struct drm_i915_private 
> *dev_priv,
>   return 0;
>  
>   pll = _priv->shared_dplls[dpll];
> - state = >config.hw_state;
> + state = >state.hw_state;
>  
>   clock.m1 = 2;
>   clock.m2 = (state->pll0 & PORT_PLL_M2_MASK) << 22;
> @@ -2401,7 +2401,7 @@ intel_ddi_get_link_dpll(struct intel_dp *intel_dp, int 
> clock)
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>   struct intel_shared_dpll *pll = NULL;
> - struct intel_shared_dpll_config tmp_pll_config;
> + struct intel_shared_dpll_state tmp_pll_state;
>   enum intel_dpll_id dpll_id;
>  
>   if (IS_BROXTON(dev_priv)) {
> @@ -2417,11 +2417,11 @@ intel_ddi_get_link_dpll(struct intel_dp *intel_dp, 
> int clock)
> pll->active_mask);
>   return NULL;
>   }
> - tmp_pll_config = pll->config;
> + tmp_pll_state = pll->state;
>   if (!bxt_ddi_dp_set_dpll_hw_state(clock,
> -   >config.hw_state)) {
> +   >state.hw_state)) {
>  

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Rename intel_shared_dpll_commit() to _swap_state()

[Daniel Vetter]

On Tue, Oct 04, 2016 at 03:32:12PM +0300, Ander Conselvan de Oliveira wrote:
> The function intel_shared_dpll_commit() performs the equivalent of
> drm_atomic_helper_swap_state() for the shared dpll state, which is not
> handled by the helpers. So rename it for consistency.
> 
> v2: Fix typo in the commit message. (Durga)
> v3: Rebase.
> Signed-off-by: Ander Conselvan de Oliveira 
> 
> Reviewed-by: Durgadoss R 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/intel_display.c  | 2 +-
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 2 +-
>  drivers/gpu/drm/i915/intel_dpll_mgr.h | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 28d9d3e..b8bfde0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14530,7 +14530,7 @@ static int intel_atomic_commit(struct drm_device *dev,
>   drm_atomic_helper_swap_state(state, true);
>   dev_priv->wm.distrust_bios_wm = false;
>   dev_priv->wm.skl_results = intel_state->wm_results;
> - intel_shared_dpll_commit(state);
> + intel_shared_dpll_swap_state(state);
>   intel_atomic_track_fbs(state);
>  
>   if (nonblock)
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index f1b3feb..15bf462 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -266,7 +266,7 @@ intel_reference_shared_dpll(struct intel_shared_dpll *pll,
>   shared_dpll[pll->id].crtc_mask |= 1 << crtc->pipe;
>  }
>  
> -void intel_shared_dpll_commit(struct drm_atomic_state *state)
> +void intel_shared_dpll_swap_state(struct drm_atomic_state *state)
>  {
>   struct drm_i915_private *dev_priv = to_i915(state->dev);
>   struct intel_shared_dpll_config *shared_dpll;
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.h 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.h
> index 99a82c9..06d61c5 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.h
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.h
> @@ -152,7 +152,7 @@ void intel_release_shared_dpll(struct intel_shared_dpll 
> *dpll,
>  void intel_prepare_shared_dpll(struct intel_crtc *crtc);
>  void intel_enable_shared_dpll(struct intel_crtc *crtc);
>  void intel_disable_shared_dpll(struct intel_crtc *crtc);
> -void intel_shared_dpll_commit(struct drm_atomic_state *state);
> +void intel_shared_dpll_swap_state(struct drm_atomic_state *state);
>  void intel_shared_dpll_init(struct drm_device *dev);
>  
>  /* BXT dpll related functions */
> -- 
> 2.5.5
> 
> ___
> 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 1/7] drm/i915: Introduce intel_release_shared_dpll()

[Daniel Vetter]

On Tue, Oct 04, 2016 at 03:32:11PM +0300, Ander Conselvan de Oliveira wrote:
> While the details of getting a shared dpll are wrapped by
> intel_get_shared_dpll(), the release was still hand rolled into the
> modeset code. Fix that by creating an entry point for releasing the
> pll and move that code there.
> 
> v2: Take old_dpll from crtc->state instead of crtc_state. (CI)
> Signed-off-by: Ander Conselvan de Oliveira 
> 
> ---
>  drivers/gpu/drm/i915/intel_display.c  |  6 +
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 41 
> +++
>  drivers/gpu/drm/i915/intel_dpll_mgr.h | 11 +++---
>  3 files changed, 22 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index a366656..28d9d3e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13768,7 +13768,6 @@ static void intel_modeset_clear_plls(struct 
> drm_atomic_state *state)
>  {
>   struct drm_device *dev = state->dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> - struct intel_shared_dpll_config *shared_dpll = NULL;
>   struct drm_crtc *crtc;
>   struct drm_crtc_state *crtc_state;
>   int i;
> @@ -13789,10 +13788,7 @@ static void intel_modeset_clear_plls(struct 
> drm_atomic_state *state)
>   if (!old_dpll)
>   continue;
>  
> - if (!shared_dpll)
> - shared_dpll = intel_atomic_get_shared_dpll_state(state);
> -
> - intel_shared_dpll_config_put(shared_dpll, old_dpll, intel_crtc);
> + intel_release_shared_dpll(old_dpll, intel_crtc, state);
>   }
>  }
>  
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 1c59ca5..f1b3feb 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -79,28 +79,6 @@ intel_get_shared_dpll_id(struct drm_i915_private *dev_priv,
>   return (enum intel_dpll_id) (pll - dev_priv->shared_dplls);
>  }
>  
> -void
> -intel_shared_dpll_config_get(struct intel_shared_dpll_config *config,
> -  struct intel_shared_dpll *pll,
> -  struct intel_crtc *crtc)
> -{
> - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - enum intel_dpll_id id = intel_get_shared_dpll_id(dev_priv, pll);
> -
> - config[id].crtc_mask |= 1 << crtc->pipe;
> -}
> -
> -void
> -intel_shared_dpll_config_put(struct intel_shared_dpll_config *config,
> -  struct intel_shared_dpll *pll,
> -  struct intel_crtc *crtc)
> -{
> - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - enum intel_dpll_id id = intel_get_shared_dpll_id(dev_priv, pll);
> -
> - config[id].crtc_mask &= ~(1 << crtc->pipe);
> -}
> -
>  /* For ILK+ */
>  void assert_shared_dpll(struct drm_i915_private *dev_priv,
>   struct intel_shared_dpll *pll,
> @@ -285,7 +263,7 @@ intel_reference_shared_dpll(struct intel_shared_dpll *pll,
>   DRM_DEBUG_DRIVER("using %s for pipe %c\n", pll->name,
>pipe_name(crtc->pipe));
>  
> - intel_shared_dpll_config_get(shared_dpll, pll, crtc);
> + shared_dpll[pll->id].crtc_mask |= 1 << crtc->pipe;
>  }
>  
>  void intel_shared_dpll_commit(struct drm_atomic_state *state)
> @@ -1900,3 +1878,20 @@ intel_get_shared_dpll(struct intel_crtc *crtc,
>  
>   return dpll_mgr->get_dpll(crtc, crtc_state, encoder);
>  }
> +
> +/**
> + * intel_release_shared_dpll - end use of DPLL by CRTC in atomic state
> + * @dpll: dpll in use by @crtc
> + * @crtc: crtc
> + * @state: atomic state
> + *
> + */
> +void intel_release_shared_dpll(struct intel_shared_dpll *dpll,
> +struct intel_crtc *crtc,
> +struct drm_atomic_state *state)
> +{
> + struct intel_shared_dpll_config *shared_dpll_config;
> +
> + shared_dpll_config = intel_atomic_get_shared_dpll_state(state);

I wonder whether we shouldn't move intel_atomic_get_shared_dpll_state into
intel_dpll_mgr.c too. That would further reduce the interfaces exported
from intel_dpll_mgr.[hc].

On this patch: Reviewed-by: Daniel Vetter 


> + shared_dpll_config[dpll->id].crtc_mask &= ~(1 << crtc->pipe);
> +}
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.h 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.h
> index f438535..99a82c9 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.h
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.h
> @@ -138,14 +138,6 @@ intel_get_shared_dpll_by_id(struct drm_i915_private 
> *dev_priv,
>  enum intel_dpll_id
>  intel_get_shared_dpll_id(struct drm_i915_private *dev_priv,
>struct intel_shared_dpll *pll);
> -void
> -intel_shared_dpll_config_get(struct intel_shared_dpll_config *config,
> -  

Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatched INIT power domain disabling during suspend

[Imre Deak]

On to, 2016-10-13 at 15:43 +0300, Ville Syrjälä wrote:
> On Thu, Oct 13, 2016 at 02:34:06PM +0300, Imre Deak wrote:
> > Currently the display INIT power domain disabling/enabling happens in a
> > mismatched way in the suspend/resume_early hooks respectively. This can
> > leave display power wells incorrectly disabled in the resume hook if the
> > suspend sequence is aborted for some reason resulting in the
> > suspend/resume hooks getting called but the suspend_late/resume_early
> > hooks being skipped. In particular this change fixes "Unclaimed read
> > from register 0x1e1204" on BYT/BSW triggered from i915_drm_resume()->
> > intel_pps_unlock_regs_wa() when suspending with /sys/power/pm_test set
> > to devices.
> > 
> > Cc: Ville Syrjälä 
> > Cc: David Weinehall 
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index e9b3bfc..5adabac 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1430,8 +1430,6 @@ static int i915_drm_suspend(struct drm_device *dev)
> >  
> >     dev_priv->suspend_count++;
> >  
> > -   intel_display_set_init_power(dev_priv, false);
> > -
> >     intel_csr_ucode_suspend(dev_priv);
> >  
> >  out:
> > @@ -1449,6 +1447,8 @@ static int i915_drm_suspend_late(struct drm_device 
> > *dev, bool hibernation)
> >  
> >     disable_rpm_wakeref_asserts(dev_priv);
> >  
> > +   intel_display_set_init_power(dev_priv, false);
> > +
> 
> Makes sense in most cases.
> Reviewed-by: Ville Syrjälä 
> 
> >     fw_csr = !IS_BROXTON(dev_priv) &&
> >     suspend_to_idle(dev_priv) && dev_priv->csr.dmc_payload;
> 
> However this part is quite confusing. We do the init_power_put
> unconditionally, but the init_power_get is done from the init_hw()
> which is conditional on this supend_to_idle special casing. So it seems
> quite assymmetrical, and I can no longer claim to understand it.

Yep, that's a problem of its own for the suspend-to-idle case, enabling the
INIT domain should be also unconditional and happen from this function.
I suppose this happened to work so far since it only applies to SKL where
nothing depended on the INIT domain, everything takes its own domain ref.
Will look into fixing this.

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

Re: [Intel-gfx] [i-g-t PATCH 1/3] tests: add more checks for finding the debugfs in script based tests

[Chris Wilson]

On Thu, Oct 13, 2016 at 03:59:55PM +0300, Jani Nikula wrote:
> While at it, make debugfs_path point at the debugfs root, not
> dri. This'll be handy in future work.
> 
> Signed-off-by: Jani Nikula 
> ---
>  tests/drm_lib.sh | 16 ++--
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/tests/drm_lib.sh b/tests/drm_lib.sh
> index 113da4c7d645..87e3ad0ab547 100755
> --- a/tests/drm_lib.sh
> +++ b/tests/drm_lib.sh
> @@ -41,18 +41,22 @@ do_or_die() {
>   $@ > /dev/null 2>&1 || (echo "FAIL: $@ ($?)" && exit $IGT_EXIT_FAILURE)
>  }
>  
> -if [ -d /debug/dri ] ; then
> - debugfs_path=/debug/dri
> +if [ -d /sys/kernel/debug ]; then
> + debugfs_path=/sys/kernel/debug
> +elif [ -d /debug ]; then
> + debugfs_path=/debug
> +else
> + skip "debugfs not found"
>  fi
>  
> -if [ -d /sys/kernel/debug/dri ] ; then
> - debugfs_path=/sys/kernel/debug/dri
> +if [ ! -d $debugfs_path/dri ]; then
> + skip "dri debugfs not found"
>  fi
>  
>  i915_dfs_path=x
>  for minor in `seq 0 16`; do
> - if [ -f $debugfs_path/$minor/i915_error_state ] ; then
> - i915_dfs_path=$debugfs_path/$minor
> + if [ -f $debugfs_path/dri/$minor/i915_error_state ] ; then
> + i915_dfs_path=$debugfs_path/dri/$minor

Thinking of how to wean ourselves off i915_error_state; how about

if [ grep -s i915 $debugfs_path/dri/$minor/name ]; then

?
-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] kms_atomic : Added subtest for Single Pipe DBUF validation

[Daniel Vetter]

On Tue, Oct 04, 2016 at 10:17:58AM +0530, meghanelogal wrote:
> Existing DDB algorithm divide the DDB wrt data rate,
> hence the planes with the less height but same width
> will be allocated less blocks and watermark are based
> on width which requires more DDB. With this data the flip
> may fail.
> 
> In new DDB algorithm, the DDB is divided based on
> watermark requirement.
> 
> In this subtest, dividing the htotal/200 will allocate
> ~2-4 blocks out of total(512/896), flip may fail with the
> exisiting algorithm.But with the new algorithm it will pass.
> 
> Signed-off-by: Megha Nelogal 

Please note that igt can be run on _any_ linux driver. If you are testing
for such a specific case like this one here, you definitely need to have
very specific platform checks in place, using igt_require.

But tbh I'm not sure this is all that useful 
-Daniel

> ---
>  tests/kms_atomic.c | 77 
> ++
>  1 file changed, 77 insertions(+)
> 
> diff --git a/tests/kms_atomic.c b/tests/kms_atomic.c
> index f27ee46..ff25644 100644
> --- a/tests/kms_atomic.c
> +++ b/tests/kms_atomic.c
> @@ -1280,6 +1280,60 @@ static void atomic_invalid_params(struct 
> kms_atomic_crtc_state *crtc,
>   do_ioctl_err(desc->fd, DRM_IOCTL_MODE_ATOMIC, , EFAULT);
>  }
>  
> +static void validate_dbuf(struct kms_atomic_crtc_state *crtc,
> + struct kms_atomic_plane_state **plane_array,
> + int plane_count)
> +{
> + int i;
> + struct kms_atomic_desc *desc = crtc->state->desc;
> +
> + /* for active crtc do modeset on the native resolution */
> + drmModeAtomicReq *req = drmModeAtomicAlloc();
> + struct drm_mode_modeinfo *mode = crtc->mode.data;
> + struct kms_atomic_plane_state plane;
> + struct igt_fb fb;
> +
> + crtc_populate_req(crtc, req);
> +
> + /* Add plane data to the structure...*/
> + uint32_t crtc_x = 0;
> + uint32_t crtc_y = 0;
> +
> + for (i = 0; i < plane_count; i++) {
> + plane = *plane_array[i];
> + uint32_t format = plane_get_igt_format();
> +
> + igt_require(format != 0);
> + plane.src_x = 0;
> + plane.src_y = 0;
> + plane.src_w = (mode->hdisplay / (1)) << 16;
> + plane.crtc_x = crtc_x;
> + plane.crtc_y = crtc_y;
> + plane.crtc_w = (mode->hdisplay) / (1);
> + plane.crtc_h = (mode->vdisplay) / (i + 1);
> +
> + plane.crtc_id = crtc->obj;
> +
> + if (i%2 == 0) {
> + plane.src_h = (mode->vdisplay / (1)) << 16;
> + plane.crtc_h = (mode->vdisplay) / (1);
> + }
> +
> + if (i%2 == 1) {
> + plane.src_h = ceil((mode->vdisplay / 200) << 16);
> + plane.crtc_h = ceil((mode->vdisplay / 200));
> + }
> +
> + plane.fb_id = igt_create_fb(plane.state->desc->fd,
> + plane.crtc_w, plane.crtc_h,
> + format, I915_TILING_NONE, );
> + plane_populate_req(, req);
> + }
> + do_atomic_commit(desc->fd, req, ATOMIC_RELAX_NONE);
> + drmModeAtomicFree(req);
> +}
> +
> +
>  igt_main
>  {
>   struct kms_atomic_desc desc;
> @@ -1373,6 +1427,29 @@ igt_main
>   atomic_state_free(scratch);
>   }
>  
> + igt_subtest("validate_dbuf") {
> + struct kms_atomic_state *scratch = atomic_state_dup(current);
> + struct kms_atomic_crtc_state *crtc = find_crtc(scratch, true);
> + struct kms_atomic_plane_state *plane;
> + struct kms_atomic_connector_state *connector =
> + find_connector(scratch, crtc);
> + struct kms_atomic_plane_state **plane_array = NULL;
> + /* Enabling Two planes */
> + plane_array = calloc(2, sizeof(struct kms_atomic_plane_state 
> *));
> + int plane_count = 0;
> +
> + igt_require(crtc);
> + plane = find_plane(scratch, PLANE_TYPE_PRIMARY, crtc);
> + igt_require(plane);
> + plane_array[plane_count] = plane; plane_count++;
> + plane = find_plane(scratch, PLANE_TYPE_OVERLAY, crtc);
> + igt_require(plane);
> + plane_array[plane_count] = plane; plane_count++;
> + igt_require(connector);
> + validate_dbuf(crtc, plane_array, plane_count);
> + atomic_state_free(scratch);
> + }
> +
>   atomic_state_free(current);
>  
>   igt_fixture
> -- 
> 1.9.1
> 

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

Re: [Intel-gfx] [PATCH] drm/i915: Unalias obj->phys_handle and obj->userptr

[Daniel Vetter]

On Mon, Oct 03, 2016 at 10:18:03AM +0300, Joonas Lahtinen wrote:
> On pe, 2016-09-30 at 18:31 +0100, Chris Wilson wrote:
> > We use obj->phys_handle to choose the pread/pwrite path, but as
> > obj->phys_handle is a union with obj->userptr, we then mistakenly use
> > the phys_handle path for userptr objects within pread/pwrite.
> > 
> > Testcase: igt/gem_userptr_blits/forbidden-operations
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97519
> > Signed-off-by: Chris Wilson 
> > Cc: sta...@vger.kernel.org
> 
> Reviewed-by: Joonas Lahtinen 

Commmented already on irc, but I totally panicked about this one. I think
we need an ops->pwrite.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/8] HuC Loading Patches

[Daniel Vetter]

On Thu, Sep 29, 2016 at 11:03:57AM -0700, Anusha Srivatsa wrote:
> These patches add HuC loading support. The userspace
> patches that check for a fully loaded HuC firmware and use
> it can be found at:
> https://lists.freedesktop.org/archives/libva/2016-September/004554.html
> https://lists.freedesktop.org/archives/libva/2016-September/004555.html
> 
> Peter Antoine (8):
>   drm/i915/guc: Make the GuC fw loading helper functions general
>   drm/i915/huc: Unified css_header struct for GuC and HuC
>   drm/i915/huc: Add HuC fw loading support
>   drm/i915/huc: Add debugfs for HuC loading status check
>   drm/i915/huc: Support HuC authentication
>   drm/i915/huc: Add BXT HuC Loading Support
>   drm/i915/get_params: Add GuC status to getparams
>   drm/i915/get_params: Add HuC status to getparams

So trouble with these is that both original authors (all of them) and
reviewers left intel. Which means we don't have anyone anymore who
understands this, and a big part of review is making sure that in the end
at least two people (author+reviewer) really understand the patches in
full detail.

In short we need to restart the review process here again before merging
:(
-Daniel

> 
>  drivers/gpu/drm/i915/Makefile  |   1 +
>  drivers/gpu/drm/i915/i915_debugfs.c|  43 -
>  drivers/gpu/drm/i915/i915_drv.c|  11 ++
>  drivers/gpu/drm/i915/i915_drv.h|   3 +
>  drivers/gpu/drm/i915/i915_guc_reg.h|   3 +
>  drivers/gpu/drm/i915/i915_guc_submission.c |  69 ++-
>  drivers/gpu/drm/i915/intel_guc.h   |  46 +++--
>  drivers/gpu/drm/i915/intel_guc_fwif.h  |  17 +-
>  drivers/gpu/drm/i915/intel_guc_loader.c| 215 -
>  drivers/gpu/drm/i915/intel_huc.h   |  44 +
>  drivers/gpu/drm/i915/intel_huc_loader.c| 289 
> +
>  include/uapi/drm/i915_drm.h|   2 +
>  12 files changed, 623 insertions(+), 120 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/intel_huc.h
>  create mode 100644 drivers/gpu/drm/i915/intel_huc_loader.c
> 
> -- 
> 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] port intel-gpu-tools to Wayland

[Daniel Vetter]

On Thu, Sep 29, 2016 at 04:45:34PM +0300, Jani Nikula wrote:
> 
> Oh, the list and Petri seem to have been dropped off the distribution,
> adding back. I don't have an answer on the rest. Petri?
> 
> On Thu, 29 Sep 2016, cornel panceac  wrote:
> > 2016-09-29 14:53 GMT+02:00 Jani Nikula :
> >
> >> On Thu, 29 Sep 2016, cornel panceac  wrote:
> >> > 2016-09-29 14:20 GMT+02:00 Jani Nikula :
> >> >
> >> >> On Thu, 29 Sep 2016, cornel panceac  wrote:
> >> >> > Is this the right mailing list to ask about intel-gpu-tools? I wonder
> >> if
> >> >> > anyone can help me port it to Wayland only, no X11.
> >> >>
> >> >> Please be more specific. Most of it is on top of libdrm, or just messing
> >> >> with the mmio directly, and independent of Wayland or X11.
> >> >>
> >> >
> >> > Looking in the sources, i see this:
> >> >
> >> > $ cat configure.ac | grep -i xorg
> >> > # Require X.Org macros 1.16 or later for XORG_TESTSET_CFLAG
> >> > m4_ifndef([XORG_MACROS_VERSION],
> >> >   [m4_fatal([must install xorg-macros 1.16 or later before
> >> running
> >> > autoconf/autogen])])
> >> > XORG_MACROS_VERSION(1.16)
> >> > XORG_DEFAULT_OPTIONS
> >> > XORG_TESTSET_CFLAG([THREAD_CFLAGS], [-pthread], [-mt])
> >> >
> >> > I would like to change the sources so that xorg is no longer a
> >> requirement.
> >>
> >> On my debian box, dpkg -s xutils-dev says, "Description: X Window System
> >> utility programs for development xutils-dev provides a set of utility
> >> programs shipped with the X Window System that do not require the X
> >> libraries; many of these programs are useful even on a system that does
> >> not have any X clients or X servers installed."
> >>
> >> I'm not sure if that is a real concern. Anything else?
> >>
> >
> > Thank you Jan, i'll try this and provide feedback. One more detail, i'm
> > trying to build it in Yocto, and in our project it complains that x11
> > DISTRO_FEATURE is missing (this is by design). Also, the version is 1.11.

we use x-utils for some of the build-system magic. It shouldn't be a
runtime depency afaik.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [patch] drm/i915: fix a read size argument

[walter harms]

Am 13.10.2016 10:55, schrieb Dan Carpenter:
> We want to read 3 bytes here, but because the parenthesis are in the
> wrong place we instead read:
> 
>   sizeof(intel_dp->edp_dpcd) == sizeof(intel_dp->edp_dpcd)
> 
> which is one byte.
> 
> Fixes: fe5a66f91c88 ("drm/i915: Read PSR caps/intermediate freqs/etc. only 
> once on eDP")
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 14a3cf0..ee8aa95 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3551,8 +3551,8 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
>   /* Read the eDP Display control capabilities registers */
>   if ((intel_dp->dpcd[DP_EDP_CONFIGURATION_CAP] & 
> DP_DPCD_DISPLAY_CONTROL_CAPABLE) &&
>   drm_dp_dpcd_read(_dp->aux, DP_EDP_DPCD_REV,
> -  intel_dp->edp_dpcd, sizeof(intel_dp->edp_dpcd) ==
> -  sizeof(intel_dp->edp_dpcd)))
> +  intel_dp->edp_dpcd, sizeof(intel_dp->edp_dpcd)) ==
> +  sizeof(intel_dp->edp_dpcd))



perhaps we can morph that into something more readable ? I would suggest:


if (intel_dp->dpcd[DP_EDP_CONFIGURATION_CAP] & DP_DPCD_DISPLAY_CONTROL_CAPABLE)
  {
size_t size=sizeof(intel_dp->edp_dpcd); /* == EDP_DISPLAY_CTL_CAP_SIZE */
int ret;

ret=drm_dp_dpcd_read(_dp->aux, 
DP_EDP_DPCD_REV,intel_dp->edp_dpcd,size);  

if (ret != size )
..

 }

this way it improves readability and reduces line length.


>   DRM_DEBUG_KMS("EDP DPCD : %*ph\n", (int) 
> sizeof(intel_dp->edp_dpcd),
> intel_dp->edp_dpcd);
>  
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Fix HDMI DPLL configuration

[Daniel Vetter]

On Mon, Sep 26, 2016 at 06:02:20PM +0300, Jani Nikula wrote:
> On Mon, 26 Sep 2016, Imre Deak  wrote:
> > a277ca7dc01d should've been a no-functional-change commit, but it
> > removed the initialization of the dpll_hw_state for HDMI outputs,
> > resulting in state mismatches and a failed modeset with blank
> > screen. Fix this by reinstating the dpll_hw_state initialization.
> >
> > Fixes: a277ca7dc01d ("drm/i915: Split bxt_ddi_pll_select()")
> > Signed-off-by: Imre Deak 
> 
> Cc: Manasi Navare 
> Cc: Ander Conselvan de Oliveira 
> Cc: Durgadoss R 
> Cc: Rodrigo Vivi 

Aka pls update your dim copy, it'll generate this automatically.
-Daniel

> 
> > ---
> >  drivers/gpu/drm/i915/intel_dpll_mgr.c | 21 -
> >  1 file changed, 16 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> > b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > index c26d18a..e8bf838 100644
> > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > @@ -1694,21 +1694,32 @@ bool bxt_ddi_dp_set_dpll_hw_state(int clock,
> > return bxt_ddi_set_dpll_hw_state(clock, _div, dpll_hw_state);
> >  }
> >  
> > +bool bxt_ddi_hdmi_set_dpll_hw_state(struct intel_crtc *intel_crtc,
> > +   struct intel_crtc_state *crtc_state,
> > +   int clock,
> > +   struct intel_dpll_hw_state *dpll_hw_state)
> > +{
> > +   struct bxt_clk_div clk_div = { };
> > +
> > +   bxt_ddi_hdmi_pll_dividers(intel_crtc, crtc_state, clock, _div);
> > +
> > +   return bxt_ddi_set_dpll_hw_state(clock, _div, dpll_hw_state);
> > +}
> > +
> >  static struct intel_shared_dpll *
> >  bxt_get_dpll(struct intel_crtc *crtc,
> > struct intel_crtc_state *crtc_state,
> > struct intel_encoder *encoder)
> >  {
> > -   struct bxt_clk_div clk_div = {0};
> > -   struct intel_dpll_hw_state dpll_hw_state = {0};
> > +   struct intel_dpll_hw_state dpll_hw_state = { };
> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > struct intel_digital_port *intel_dig_port;
> > struct intel_shared_dpll *pll;
> > int i, clock = crtc_state->port_clock;
> >  
> > -   if (encoder->type == INTEL_OUTPUT_HDMI
> > -   && !bxt_ddi_hdmi_pll_dividers(crtc, crtc_state,
> > - clock, _div))
> > +   if (encoder->type == INTEL_OUTPUT_HDMI &&
> > +   !bxt_ddi_hdmi_set_dpll_hw_state(crtc, crtc_state, clock,
> > +   _hw_state))
> > return NULL;
> >  
> > if ((encoder->type == INTEL_OUTPUT_DP ||
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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