Re: [Intel-gfx] [PATCH 1/8] drm: Add crtc->name and use it in debug messages

[Jani Nikula]

On Thu, 12 Nov 2015, ville.syrj...@linux.intel.com wrote:
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 24c5434..ea00a69 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -677,6 +677,9 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
> struct drm_crtc *crtc,
>   crtc->dev = dev;
>   crtc->funcs = funcs;
>  
> + if (!crtc->name)
> + crtc->name = "";
> +

This, and the cleanup dance you have to do in patch 5/8, are my only
gripes with the series. I would prefer it if crtc->name and plane->name
were managed dynamically by the init/cleanup functions like
connector->name and encoder->name are. However those are easier because
the caller doesn't decide the name.

Do you think it would be too ugly to have this here:

crtc->name = kstrdup(crtc->name ? crtc->name : "", GFP_KERNEL);

It would of course be neater if the name was passed in as parameter, but
that would generate quite a bit of unnecessary churn.

If you are all "meh" I guess I can live with your approach too.

BR,
Jani.



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

[Intel-gfx] [PATCH maintainer-tools] dim: Remove git commit --amend from dim_apply

[Ander Conselvan de Oliveira]

Calling git --amend invokes the editor, which will not run if it relies
on the terminal for input. So don't do that from dim_apply.

Signed-off-by: Ander Conselvan de Oliveira 

---
 dim | 2 --
 1 file changed, 2 deletions(-)

diff --git a/dim b/dim
index db92c57..893906b 100755
--- a/dim
+++ b/dim
@@ -382,8 +382,6 @@ function dim_apply
if [ -n $message_id ]; then
commit_add_tag "Link" 
"http://patchwork.freedesktop.org/patch/msgid/$message_id;
fi
-
-   git commit --amend &
 }
 
 function magic_patch
-- 
2.4.3

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

Re: [Intel-gfx] [PATCH maintainer-tools] dim: Remove git commit --amend from dim_apply

[Chris Wilson]

On Fri, Nov 13, 2015 at 02:05:39PM +0200, Ander Conselvan de Oliveira wrote:
> Calling git --amend invokes the editor, which will not run if it relies
> on the terminal for input. So don't do that from dim_apply.
> 
> Signed-off-by: Ander Conselvan de Oliveira 
> 

Presumable the ammend is there for a good reason and removing it keeps
the state dirty? So maybe --amend --no-edit?
-Chris

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

Re: [Intel-gfx] [PATCH 06/10] drm/i915/skl: don't toggle PW1 and MISC power wells on-demand

[Patrik Jakobsson]

On Wed, Nov 04, 2015 at 07:24:15PM +0200, Imre Deak wrote:
> With the DMC firmware installed we don't need to handle HW resources
> that are handled automatically by the firmware. Besides beeing redundant
> this can also interfere with the firmware, possibly getting it into a
> broken/blocked state. The on-demand handling of PW1 was already half-way
> removed, MISC IO was still handled in this way. After the last patch we
> init/uninit these HW resources manually as part of the display core
> init/uninit sequence, so we can now remove the on-demand handling for
> these completely.
> 
> We still keep around the power wells (with no domains attached to them)
> since the manual toggling during display core init/uninit happens via
> the current API.

Did the "don't touch PW1 and Misc IO" also apply to BXT DMC? Need to make sure
we catch all of these fixes/changes in a BXT follow-up series later on.

Reviewed-by: Patrik Jakobsson 

> 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 36 
> +
>  1 file changed, 9 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index dce76ff..b9a0493 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -305,16 +305,6 @@ static void hsw_set_power_well(struct drm_i915_private 
> *dev_priv,
>   BIT(POWER_DOMAIN_AUDIO) |   \
>   BIT(POWER_DOMAIN_VGA) | \
>   BIT(POWER_DOMAIN_INIT))
> -#define SKL_DISPLAY_POWERWELL_1_POWER_DOMAINS (  \
> - SKL_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
> - BIT(POWER_DOMAIN_PLLS) |\
> - BIT(POWER_DOMAIN_PIPE_A) |  \
> - BIT(POWER_DOMAIN_TRANSCODER_EDP) |  \
> - BIT(POWER_DOMAIN_PIPE_A_PANEL_FITTER) | \
> - BIT(POWER_DOMAIN_PORT_DDI_A_2_LANES) |  \
> - BIT(POWER_DOMAIN_PORT_DDI_A_4_LANES) |  \
> - BIT(POWER_DOMAIN_AUX_A) |   \
> - BIT(POWER_DOMAIN_INIT))
>  #define SKL_DISPLAY_DDI_A_E_POWER_DOMAINS (  \
>   BIT(POWER_DOMAIN_PORT_DDI_A_2_LANES) |  \
>   BIT(POWER_DOMAIN_PORT_DDI_A_4_LANES) |  \
> @@ -332,18 +322,13 @@ static void hsw_set_power_well(struct drm_i915_private 
> *dev_priv,
>   BIT(POWER_DOMAIN_PORT_DDI_D_2_LANES) |  \
>   BIT(POWER_DOMAIN_PORT_DDI_D_4_LANES) |  \
>   BIT(POWER_DOMAIN_INIT))
> -#define SKL_DISPLAY_MISC_IO_POWER_DOMAINS (  \
> - SKL_DISPLAY_POWERWELL_1_POWER_DOMAINS | \
> - BIT(POWER_DOMAIN_PLLS) |\
> - BIT(POWER_DOMAIN_INIT))
>  #define SKL_DISPLAY_ALWAYS_ON_POWER_DOMAINS (\
> - (POWER_DOMAIN_MASK & ~(SKL_DISPLAY_POWERWELL_1_POWER_DOMAINS |  \
> + (POWER_DOMAIN_MASK & ~( \
>   SKL_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
>   SKL_DISPLAY_DDI_A_E_POWER_DOMAINS | \
>   SKL_DISPLAY_DDI_B_POWER_DOMAINS |   \
>   SKL_DISPLAY_DDI_C_POWER_DOMAINS |   \
> - SKL_DISPLAY_DDI_D_POWER_DOMAINS |   \
> - SKL_DISPLAY_MISC_IO_POWER_DOMAINS)) |   \
> + SKL_DISPLAY_DDI_D_POWER_DOMAINS)) | \
>   BIT(POWER_DOMAIN_INIT))
>  
>  #define BXT_DISPLAY_POWERWELL_2_POWER_DOMAINS (  \
> @@ -662,14 +647,9 @@ static void skl_set_power_well(struct drm_i915_private 
> *dev_priv,
>   }
>   } else {
>   if (enable_requested) {
> - if (IS_SKYLAKE(dev) &&
> - (power_well->data == SKL_DISP_PW_1))
> - DRM_DEBUG_KMS("Not Disabling PW1, dmc will 
> handle\n");
> - else {
> - I915_WRITE(HSW_PWR_WELL_DRIVER, tmp & 
> ~req_mask);
> - POSTING_READ(HSW_PWR_WELL_DRIVER);
> - DRM_DEBUG_KMS("Disabling %s\n", 
> power_well->name);
> - }
> + I915_WRITE(HSW_PWR_WELL_DRIVER, tmp & ~req_mask);
> + POSTING_READ(HSW_PWR_WELL_DRIVER);
> + DRM_DEBUG_KMS("Disabling %s\n", power_well->name);
>  
>   if (GEN9_ENABLE_DC5(dev) &&
>   power_well->data == SKL_DISP_PW_2)
> @@ -1741,13 +1721,15 @@ static struct i915_power_well skl_power_wells[] = {
>   },
>   {
>   .name = "power well 1",
> - .domains = SKL_DISPLAY_POWERWELL_1_POWER_DOMAINS,
> + /* Handled by the DMC firmware */
> + .domains = 0,
>   .ops = _power_well_ops,
>   .data = SKL_DISP_PW_1,
>   },
>   {
>   .name = "MISC IO power well",
> - .domains = 

Re: [Intel-gfx] [PATCH 07/10] drm/i915/gen9: simplify DC toggling code

[Patrik Jakobsson]

On Wed, Nov 04, 2015 at 07:24:16PM +0200, Imre Deak wrote:
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/i915_reg.h |  1 +
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 66 
> ++---
>  2 files changed, 29 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index c103f8d..e6d88f5 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7491,6 +7491,7 @@ enum skl_disp_power_wells {
>  
>  /* GEN9 DC */
>  #define DC_STATE_EN  0x45504
> +#define  DC_STATE_DISABLE0
>  #define  DC_STATE_EN_UPTO_DC5(1<<0)
>  #define  DC_STATE_EN_DC9 (1<<3)
>  #define  DC_STATE_EN_UPTO_DC6(2<<0)
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index b9a0493..f5fb003 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -401,32 +401,43 @@ static void assert_can_disable_dc9(struct 
> drm_i915_private *dev_priv)
> */
>  }
>  
> +static void gen9_set_dc_state(struct drm_i915_private *dev_priv, uint32_t 
> state)
> +{
> + uint32_t val;
> + uint32_t mask;
> +
> + mask = DC_STATE_EN_UPTO_DC5;
> + if (IS_BROXTON(dev_priv))
> + mask |= DC_STATE_EN_DC9;
> + else
> + mask |= DC_STATE_EN_UPTO_DC6;
> +
> + WARN_ON_ONCE(state & ~mask);
> +

I took the liberty to move gen9_set_dc_state_debugmask_memory_up() here in my
patch series. It'll get called if we try to enable DC5 or DC6 so we only have to
care about it at one place in the code. Perhaps we could even move it to
skl_display_core_init() if we do additional testing on when it needs to be
reset. Either way, not a biggie so let's ignore it for now.

Reviewed-by: Patrik Jakobsson 

> + val = I915_READ(DC_STATE_EN);
> + DRM_DEBUG_KMS("Setting DC state from %02x to %02x\n", val & mask, 
> state);
> + val &= ~mask;
> + val |= state;
> + I915_WRITE(DC_STATE_EN, val);
> + POSTING_READ(DC_STATE_EN);
> +}
> +
>  void bxt_enable_dc9(struct drm_i915_private *dev_priv)
>  {
> - uint32_t val;
> -
>   assert_can_enable_dc9(dev_priv);
>  
>   DRM_DEBUG_KMS("Enabling DC9\n");
>  
> - val = I915_READ(DC_STATE_EN);
> - val |= DC_STATE_EN_DC9;
> - I915_WRITE(DC_STATE_EN, val);
> - POSTING_READ(DC_STATE_EN);
> + gen9_set_dc_state(dev_priv, DC_STATE_EN_DC9);
>  }
>  
>  void bxt_disable_dc9(struct drm_i915_private *dev_priv)
>  {
> - uint32_t val;
> -
>   assert_can_disable_dc9(dev_priv);
>  
>   DRM_DEBUG_KMS("Disabling DC9\n");
>  
> - val = I915_READ(DC_STATE_EN);
> - val &= ~DC_STATE_EN_DC9;
> - I915_WRITE(DC_STATE_EN, val);
> - POSTING_READ(DC_STATE_EN);
> + gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
>  }
>  
>  static void gen9_set_dc_state_debugmask_memory_up(
> @@ -487,33 +498,22 @@ static void assert_can_disable_dc5(struct 
> drm_i915_private *dev_priv)
>  
>  static void gen9_enable_dc5(struct drm_i915_private *dev_priv)
>  {
> - uint32_t val;
> -
>   assert_can_enable_dc5(dev_priv);
>  
>   DRM_DEBUG_KMS("Enabling DC5\n");
>  
>   gen9_set_dc_state_debugmask_memory_up(dev_priv);
>  
> - val = I915_READ(DC_STATE_EN);
> - val &= ~DC_STATE_EN_UPTO_DC5_DC6_MASK;
> - val |= DC_STATE_EN_UPTO_DC5;
> - I915_WRITE(DC_STATE_EN, val);
> - POSTING_READ(DC_STATE_EN);
> + gen9_set_dc_state(dev_priv, DC_STATE_EN_UPTO_DC5);
>  }
>  
>  static void gen9_disable_dc5(struct drm_i915_private *dev_priv)
>  {
> - uint32_t val;
> -
>   assert_can_disable_dc5(dev_priv);
>  
>   DRM_DEBUG_KMS("Disabling DC5\n");
>  
> - val = I915_READ(DC_STATE_EN);
> - val &= ~DC_STATE_EN_UPTO_DC5;
> - I915_WRITE(DC_STATE_EN, val);
> - POSTING_READ(DC_STATE_EN);
> + gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
>  }
>  
>  static void assert_can_enable_dc6(struct drm_i915_private *dev_priv)
> @@ -545,33 +545,23 @@ static void assert_can_disable_dc6(struct 
> drm_i915_private *dev_priv)
>  
>  void skl_enable_dc6(struct drm_i915_private *dev_priv)
>  {
> - uint32_t val;
> -
>   assert_can_enable_dc6(dev_priv);
>  
>   DRM_DEBUG_KMS("Enabling DC6\n");
>  
>   gen9_set_dc_state_debugmask_memory_up(dev_priv);
>  
> - val = I915_READ(DC_STATE_EN);
> - val &= ~DC_STATE_EN_UPTO_DC5_DC6_MASK;
> - val |= DC_STATE_EN_UPTO_DC6;
> - I915_WRITE(DC_STATE_EN, val);
> - POSTING_READ(DC_STATE_EN);
> + gen9_set_dc_state(dev_priv, DC_STATE_EN_UPTO_DC6);
> +
>  }
>  
>  void skl_disable_dc6(struct drm_i915_private *dev_priv)
>  {
> - uint32_t val;
> -
>   assert_can_disable_dc6(dev_priv);
>  
>   DRM_DEBUG_KMS("Disabling DC6\n");
>  
> - val = I915_READ(DC_STATE_EN);
> - val &= ~DC_STATE_EN_UPTO_DC6;
> - 

Re: [Intel-gfx] [PATCH 08/10] drm/i915/skl: disable DC states before display core init/uninit

[Patrik Jakobsson]

On Wed, Nov 04, 2015 at 07:24:17PM +0200, Imre Deak wrote:
> We need to disable the DC states during display core init to sanitize
> the HW state we inherit from the BIOS. We need to disable it during
> display core uninit too, since the power well framework will leave it
> enabled (since we get to the display core uninit step with all power
> domains disabled already).
> 
> Signed-off-by: Imre Deak 

Reviewed-by: Patrik Jakobsson 

> ---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index f5fb003..3d500e1d 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -1900,6 +1900,8 @@ static void skl_display_core_init(struct 
> drm_i915_private *dev_priv,
>   struct i915_power_domains *power_domains = _priv->power_domains;
>   uint32_t val;
>  
> + gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
> +
>   /* enable PCH reset handshake */
>   val = I915_READ(HSW_NDE_RSTWRN_OPT);
>   I915_WRITE(HSW_NDE_RSTWRN_OPT, val | RESET_PCH_HANDSHAKE_ENABLE);
> @@ -1921,6 +1923,8 @@ static void skl_display_core_uninit(struct 
> drm_i915_private *dev_priv)
>  {
>   struct i915_power_domains *power_domains = _priv->power_domains;
>  
> + gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
> +
>   skl_uninit_cdclk(dev_priv);
>  
>   /* The spec doesn't call for removing the reset handshake flag */
> -- 
> 2.1.4
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 0/7] drm/i915: improve the RPM device suspended assert

[Jani Nikula]

On Thu, 12 Nov 2015, Imre Deak  wrote:
> This is v3 of [1]. I addressed the review comments from Ville and Chris
> and added an RPM atomic section check as well requested by Chris. I was
> also considering using lockdep for more coverage, but decided to leave
> that out for now, we can also add that later if needed.
>
> The patchset depends on Patrik's DC rework patchset [2].

Uh-oh, so now we have a reviewed series, except it depends on a series
that isn't ready, which has its own dependencies, and I've lost track of
all the series in flight by now... Imre, I trust you to move the review
of the dependencies forward, pinging people as necessary.

BR,
Jani.



>
> [1] http://lists.freedesktop.org/archives/intel-gfx/2015-November/079777.html
> [2]
> http://lists.freedesktop.org/archives/intel-gfx/2015-November/079758.html
>
> Imre Deak (7):
>   drm/i915: remove HAS_RUNTIME_PM check from RPM get/put/assert helpers
>   drm/i915: add assert_rpm_wakelock_held helper
>   drm/i915: use assert_rpm_wakelock_held instead of opencoding it
>   drm/i915: add support for checking if we hold an RPM reference
>   drm/i915: sanitize the asserts in the RPM get/put helpers
>   drm/i915: add support for checking RPM atomic sections
>   drm/i915: check that we are in an RPM atomic section in GGTT PTE
> updaters
>
>  drivers/gpu/drm/i915/i915_dma.c |  7 
>  drivers/gpu/drm/i915/i915_drv.c | 39 +--
>  drivers/gpu/drm/i915/i915_drv.h |  2 +
>  drivers/gpu/drm/i915/i915_gem_gtt.c | 33 
>  drivers/gpu/drm/i915/i915_irq.c | 12 +-
>  drivers/gpu/drm/i915/intel_drv.h| 67 
> +
>  drivers/gpu/drm/i915/intel_pm.c |  2 +
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 24 +---
>  drivers/gpu/drm/i915/intel_uncore.c | 19 +++---
>  9 files changed, 172 insertions(+), 33 deletions(-)
>
> -- 
> 2.5.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 05/10] drm/i915/skl: init/uninit display core as part of the HW power domain state

[Patrik Jakobsson]

On Wed, Nov 04, 2015 at 07:24:14PM +0200, Imre Deak wrote:
> We need to initialize the display core part early, before initializing
> the rest of the display power state. This is also described in the bspec
> termed "Display initialization sequence". Atm we run this sequence
> during driver loading after power domain HW state initialization which
> is too late and during runtime suspend/resume which is unneeded and can
> interere with DMC functionality which handles HW resources toggled
> by this init/uninit sequence automatically. The init sequence must be
> run as the first step of HW power state initialization and during
> system resume. The uninit sequence must be run during system suspend.
> 
> To address the above move the init sequence to the initial HW power
> state setup and the uninit sequence to a new power domains suspend
> function called during system suspend.
> 
> As part of the init sequence we also have to reprogram the DMC firmware
> as it's lost across a system suspend/resume cycle.
> 
> After this change CD clock initialization during driver loading will
> happen only later after other dependent HW/SW parts are initialized,
> while during system resume it will get initialized as the last step of
> the init sequence. This distinction can be removed by some refactoring
> of platform independent parts. I left this refactoring out from this
> series since I didn't want to change non-SKL parts. This is a TODO for
> later.
> 
> Signed-off-by: Imre Deak 

Reviewed-by: Patrik Jakobsson 

> ---
>  drivers/gpu/drm/i915/i915_dma.c |  2 +-
>  drivers/gpu/drm/i915/i915_drv.c |  9 ++
>  drivers/gpu/drm/i915/intel_display.c| 11 ---
>  drivers/gpu/drm/i915/intel_drv.h|  3 +-
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 55 
> +++--
>  5 files changed, 59 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 71e1323..6e9337f 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -396,7 +396,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
>   if (ret)
>   goto cleanup_vga_switcheroo;
>  
> - intel_power_domains_init_hw(dev_priv);
> + intel_power_domains_init_hw(dev_priv, false);
>  
>   intel_csr_ucode_init(dev_priv);
>  
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 858d58c..5a63f9a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -704,6 +704,8 @@ static int i915_drm_suspend_late(struct drm_device 
> *drm_dev, bool hibernation)
>   struct drm_i915_private *dev_priv = drm_dev->dev_private;
>   int ret;
>  
> + intel_power_domains_suspend(dev_priv);
> +
>   ret = intel_suspend_complete(dev_priv);
>  
>   if (ret) {
> @@ -861,7 +863,7 @@ static int i915_drm_resume_early(struct drm_device *dev)
>   hsw_disable_pc8(dev_priv);
>  
>   intel_uncore_sanitize(dev);
> - intel_power_domains_init_hw(dev_priv);
> + intel_power_domains_init_hw(dev_priv, true);
>  
>   return ret;
>  }
> @@ -1070,8 +1072,6 @@ static int i915_pm_resume(struct device *dev)
>  
>  static int skl_suspend_complete(struct drm_i915_private *dev_priv)
>  {
> - skl_uninit_cdclk(dev_priv);
> -
>   if (dev_priv->csr.dmc_payload)
>   skl_enable_dc6(dev_priv);
>  
> @@ -1122,9 +1122,6 @@ static int skl_resume_prepare(struct drm_i915_private 
> *dev_priv)
>   if (dev_priv->csr.dmc_payload)
>   skl_disable_dc6(dev_priv);
>  
> - skl_init_cdclk(dev_priv);
> - intel_csr_load_program(dev_priv);
> -
>   return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index ef2ebcd..d9ed128 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5701,23 +5701,12 @@ void skl_uninit_cdclk(struct drm_i915_private 
> *dev_priv)
>   if (wait_for(!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_LOCK), 1))
>   DRM_ERROR("Couldn't disable DPLL0\n");
>   }
> -
> - /* disable PG1 and Misc I/O */
> - skl_pw1_misc_io_fini(dev_priv);
>  }
>  
>  void skl_init_cdclk(struct drm_i915_private *dev_priv)
>  {
> - u32 val;
>   unsigned int required_vco;
>  
> - /* enable PCH reset handshake */
> - val = I915_READ(HSW_NDE_RSTWRN_OPT);
> - I915_WRITE(HSW_NDE_RSTWRN_OPT, val | RESET_PCH_HANDSHAKE_ENABLE);
> -
> - /* enable PG1 and Misc I/O */
> - skl_pw1_misc_io_init(dev_priv);
> -
>   /* DPLL0 not enabled (happens on early BIOS versions) */
>   if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE)) {
>   /* enable DPLL0 */
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 3d9d1d3..e0476c3 100644
> --- 

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Delay first PSR activation.

[R, Durgadoss]

>-Original Message-
>From: Vivi, Rodrigo
>Sent: Friday, November 13, 2015 3:08 AM
>To: intel-gfx@lists.freedesktop.org; R, Durgadoss
>Subject: Re: [Intel-gfx] [PATCH 1/4] drm/i915: Delay first PSR activation.
>
>On Thu, 2015-11-12 at 13:50 +, R, Durgadoss wrote:
>> Hi Rodrigo,
>>
>> > -Original Message-
>> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
>> > Behalf Of Rodrigo Vivi
>> > Sent: Thursday, November 12, 2015 1:07 AM
>> > To: intel-gfx@lists.freedesktop.org
>> > Cc: Vivi, Rodrigo
>> > Subject: [Intel-gfx] [PATCH 1/4] drm/i915: Delay first PSR
>> > activation.
>> >
>> > When debuging the frozen screen caused by HW tracking with low
>> > power state I noticed that if we keep moving the mouse non stop
>> > you will miss the screen updates for a while. At least
>> > until we stop moving the mouse for a small time and move again.
>> >
>> > The actual enabling should happen immediately after
>> > Display Port enabling sequence finished with links trained and
>> > everything enabled. However we face many issues when enabling PSR
>> > right after a modeset.
>> >
>> > On VLV/CHV we face blank screens on this scenario and on HSW+
>> > we face a recoverable frozen screen, at least until next
>> > exit-activate sequence.
>> >
>> > Another workaround for the same issue here would be to increase
>> > re-enable idle time from 100 to 500 as we did for VLV/CHV.
>> > However this patch workaround this issue in a better
>> > way since it doesn't reduce PSR residency and also
>> > allow us to reduce the delay time between re-enables at least
>> > on VLV/CHV.
>> >
>> > This is also important to make the sysfs toggle working properly.
>> >
>> > Signed-off-by: Rodrigo Vivi 
>> > ---
>> > drivers/gpu/drm/i915/intel_psr.c | 18 --
>> > 1 file changed, 16 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
>> > b/drivers/gpu/drm/i915/intel_psr.c
>> > index 213581c..6b24c24 100644
>> > --- a/drivers/gpu/drm/i915/intel_psr.c
>> > +++ b/drivers/gpu/drm/i915/intel_psr.c
>> > @@ -427,6 +427,19 @@ void intel_psr_enable(struct intel_dp
>> > *intel_dp)
>> >vlv_psr_enable_source(intel_dp);
>> >}
>> >
>> > +  /*
>> > +   * FIXME: Activation should happen immediately since this
>> > function
>> > +   * is just called after pipe is fully trained and enabled.
>> > +   * However on every platform we face issues when first
>> > activation
>> > +   * follows a modeset so quickly.
>> > +   * - On VLV/CHV we get bank screen on first activation
>> > +   * - On HSW/BDW we get a recoverable frozen screen
>> > until next
>> > +   *   exit-activate sequence.
>> > +   */
>> > +  if (INTEL_INFO(dev)->gen < 9)
>> > +  schedule_delayed_work(_priv->psr.work,
>> > +msecs_to_jiffies(intel_dp
>> > ->panel_power_cycle_delay * 5));
>> > +
>> >dev_priv->psr.enabled = intel_dp;

Should we set this before scheduling the delayed work ?

>> > unlock:
>> >mutex_unlock(_priv->psr.lock);
>> > @@ -735,8 +748,9 @@ void intel_psr_flush(struct drm_device *dev,
>> >}
>> >
>> >if (!dev_priv->psr.active && !dev_priv
>> > ->psr.busy_frontbuffer_bits)
>> > -  schedule_delayed_work(_priv->psr.work,
>> > -msecs_to_jiffies(delay_ms));
>> > +  if (!work_busy(_priv->psr.work.work))
>> > +  schedule_delayed_work(_priv->psr.work,
>> > +
>> >  msecs_to_jiffies(delay_ms));
>>
>> Agree with the theory of the patch as such.. But, Is there any
>> specific reason for
>> the !work_busy() check here ?
>>
>> I believe when the later work runs, it will anyway bail out in
>> _activate
>> function, if it sees PSR_ENABLE bit set already. So, is this check
>> just to
>> prevent scheduling one more work item when there is one pending
>> already ? (or it helps in something else also ?)
>
>The !work_busy is to prevent that eventual _activate call reduce the
>first activation time.

Yes, this is what I understood from the code. Just wanted to confirm whether
you meant the same.

The other thing I am thinking is:
Inside intel_psr_enable() we call _activate() for DDI platforms & gen>=9.
For others, we schedule a work.

May be we should have only the worker thread do _activate() for every
Platform .. I believe this would simplify things a lot. Not sure whether this
Will impact gen>=9 platforms in any way..

Anyway, we can have that as a separate change if required and valid.
So, for this patch:
Reviewed-by: Durgadoss R 

Thanks,
Durga

>
>for instance:
>
>0s - we enable and schedule first activation to 2.5s
>1s - we got a page flip that flushed fb tracking and called
>psr_activation to 0.1s
>1.1s - psr is activated
>
>while we want
>
>0s - we enable and schedule first activation to 2.5s
>1s - we got a page
>flip that flushed fb tracking and called psr_activation to 0.1s # just
>ignore and move ahead since we are 

Re: [Intel-gfx] [PATCH 0/4] PSR Critical fixes

[Ville Syrjälä]

On Wed, Nov 11, 2015 at 11:37:06AM -0800, Rodrigo Vivi wrote:
> Let's split critical PSR fixes from the series that contains other
> reworks, stabilization and improvements.
> 
> The second patch in this series isn't considered critical in terms
> of functionality, but it depends on the first one and it can be consider
> a fix for PSR residency on VLV/CHV.

FYI I recently glanced at the psr code and a few things that left me
scratching my head:
- hsw_psr_enable_sink() frobs at the AUX registers without holding the hw_mutex.
  On SKL+ it seems to use the normal AUX registers here. Before it used
  the special PSR registers, so that may have been OK, but the SKL+
  thing seems rather questionable.
- intel_psr_enable() calls intel_psr_activate() on SKL+ but not on
  HSW/BDW. I'm thinking there should be a comment there to make it clear
  why, if it's even correct.

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

Re: [Intel-gfx] [PATCH maintainer-tools] dim: Replace git commit --amend from dim_apply with dimrc option

[Jani Nikula]

On Fri, 13 Nov 2015, Ander Conselvan de Oliveira 
 wrote:
> Introduce DIM_POST_APPLY_ACTION to dimrc that allows the user to specify
> a command to be run after a patch is applied. Use eval so enviroment
> variables can be overriden with the option. For example:
>
> DIM_POST_APPLY_ACTION="EDITOR=\"gedit -w\" git commit --amend"
>
> Signed-off-by: Ander Conselvan de Oliveira 
> 
> ---
>  dim  | 2 +-
>  dimrc.sample | 3 +++
>  2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/dim b/dim
> index db92c57..b7c7ef7 100755
> --- a/dim
> +++ b/dim
> @@ -383,7 +383,7 @@ function dim_apply
>   commit_add_tag "Link" 
> "http://patchwork.freedesktop.org/patch/msgid/$message_id;
>   fi
>  
> - git commit --amend &
> + eval $DRY $DIM_POST_APPLY_ACTION
>  }
>  
>  function magic_patch
> diff --git a/dimrc.sample b/dimrc.sample
> index 5687eaf..9f30cb2 100644
> --- a/dimrc.sample
> +++ b/dimrc.sample
> @@ -21,3 +21,6 @@
>  # Mail User Agent supporting a subset of mutt(1) command line options:
>  # [-s subject] [-i file] [-c cc-addr] to-addr [...]
>  #DIM_MUA=mutt
> +
> +# Command to run after dim apply
> +#DIM_POST_APPLY_ACTION=git commit --amend

There's a comment earlier that says "Defaults are in the comments
below." I'm fine with changing the default here.


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

[Intel-gfx] [PATCH v3 6/9] drm/i915: Set crtc->name to "pipe A", "pipe B", etc.

[ville . syrjala]

From: Ville Syrjälä 

v2: Fix intel_crtc leak on failure to allocate the name
Use a local 'name' variable to make things easier
v3: Pass the name as a function arguemnt to drm_crtc_init_with_planes() (Jani)

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

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 77496ef..5032fac 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10723,7 +10723,6 @@ static void intel_crtc_destroy(struct drm_crtc *crtc)
}
 
drm_crtc_cleanup(crtc);
-
kfree(intel_crtc);
 }
 
@@ -14026,15 +14025,16 @@ static void skl_init_scalers(struct drm_device *dev, 
struct intel_crtc *intel_cr
 static void intel_crtc_init(struct drm_device *dev, int pipe)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
-   struct intel_crtc *intel_crtc;
+   struct intel_crtc *intel_crtc = NULL;
struct intel_crtc_state *crtc_state = NULL;
struct drm_plane *primary = NULL;
struct drm_plane *cursor = NULL;
+   char name[16];
int i, ret;
 
intel_crtc = kzalloc(sizeof(*intel_crtc), GFP_KERNEL);
-   if (intel_crtc == NULL)
-   return;
+   if (!intel_crtc)
+   goto fail;
 
crtc_state = kzalloc(sizeof(*crtc_state), GFP_KERNEL);
if (!crtc_state)
@@ -14043,6 +14043,9 @@ static void intel_crtc_init(struct drm_device *dev, int 
pipe)
intel_crtc->base.state = _state->base;
crtc_state->base.crtc = _crtc->base;
 
+   ret = snprintf(name, sizeof(name), "pipe %c", pipe_name(pipe));
+   WARN_ON(ret >= sizeof(name));
+
/* initialize shared scalers */
if (INTEL_INFO(dev)->gen >= 9) {
if (pipe == PIPE_C)
@@ -14062,7 +14065,7 @@ static void intel_crtc_init(struct drm_device *dev, int 
pipe)
goto fail;
 
ret = drm_crtc_init_with_planes(dev, _crtc->base, primary,
-   cursor, _crtc_funcs, "");
+   cursor, _crtc_funcs, name);
if (ret)
goto fail;
 
-- 
2.4.10

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

[Intel-gfx] [PATCH 4/9] drm/i915: Use crtc->name in debug messages

[ville . syrjala]

From: Ville Syrjälä 

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 55 
 drivers/gpu/drm/i915/intel_fbdev.c   |  5 ++--
 2 files changed, 33 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d1db57d..6fac133 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4220,8 +4220,9 @@ struct intel_shared_dpll *intel_get_shared_dpll(struct 
intel_crtc *crtc,
i = (enum intel_dpll_id) crtc->pipe;
pll = _priv->shared_dplls[i];
 
-   DRM_DEBUG_KMS("CRTC:%d using pre-allocated %s\n",
- crtc->base.base.id, pll->name);
+   DRM_DEBUG_KMS("[CRTC:%d:%s] using pre-allocated %s\n",
+ crtc->base.base.id, crtc->base.name,
+ pll->name);
 
WARN_ON(shared_dpll[i].crtc_mask);
 
@@ -4241,8 +4242,9 @@ struct intel_shared_dpll *intel_get_shared_dpll(struct 
intel_crtc *crtc,
/* 1:1 mapping between ports and PLLs */
i = (enum intel_dpll_id)intel_dig_port->port;
pll = _priv->shared_dplls[i];
-   DRM_DEBUG_KMS("CRTC:%d using pre-allocated %s\n",
-   crtc->base.base.id, pll->name);
+   DRM_DEBUG_KMS("[CRTC:%d:%s] using pre-allocated %s\n",
+ crtc->base.base.id, crtc->base.name,
+ pll->name);
WARN_ON(shared_dpll[i].crtc_mask);
 
goto found;
@@ -4258,9 +4260,9 @@ struct intel_shared_dpll *intel_get_shared_dpll(struct 
intel_crtc *crtc,
if (memcmp(_state->dpll_hw_state,
   _dpll[i].hw_state,
   sizeof(crtc_state->dpll_hw_state)) == 0) {
-   DRM_DEBUG_KMS("CRTC:%d sharing existing %s (crtc mask 
0x%08x, ative %d)\n",
- crtc->base.base.id, pll->name,
- shared_dpll[i].crtc_mask,
+   DRM_DEBUG_KMS("[CRTC:%d:%s] sharing existing %s (crtc 
mask 0x%08x, ative %d)\n",
+ crtc->base.base.id, crtc->base.name,
+ pll->name, shared_dpll[i].crtc_mask,
  pll->active);
goto found;
}
@@ -4270,8 +4272,9 @@ struct intel_shared_dpll *intel_get_shared_dpll(struct 
intel_crtc *crtc,
for (i = 0; i < dev_priv->num_shared_dpll; i++) {
pll = _priv->shared_dplls[i];
if (shared_dpll[i].crtc_mask == 0) {
-   DRM_DEBUG_KMS("CRTC:%d allocated %s\n",
- crtc->base.base.id, pll->name);
+   DRM_DEBUG_KMS("[CRTC:%d:%s] allocated %s\n",
+ crtc->base.base.id, crtc->base.name,
+ pll->name);
goto found;
}
}
@@ -4398,8 +4401,9 @@ int skl_update_scaler_crtc(struct intel_crtc_state *state)
struct intel_crtc *intel_crtc = to_intel_crtc(state->base.crtc);
const struct drm_display_mode *adjusted_mode = 
>base.adjusted_mode;
 
-   DRM_DEBUG_KMS("Updating scaler for [CRTC:%i] scaler_user index %u.%u\n",
- intel_crtc->base.base.id, intel_crtc->pipe, 
SKL_CRTC_INDEX);
+   DRM_DEBUG_KMS("Updating scaler for [CRTC:%d:%s] scaler_user index 
%u.%u\n",
+ intel_crtc->base.base.id, intel_crtc->base.name,
+ intel_crtc->pipe, SKL_CRTC_INDEX);
 
return skl_update_scaler(state, !state->base.active, SKL_CRTC_INDEX,
>scaler_state.scaler_id, DRM_ROTATE_0,
@@ -11643,13 +11647,13 @@ int intel_plane_atomic_calc_changes(struct 
drm_crtc_state *crtc_state,
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_plane_state *old_plane_state =
to_intel_plane_state(plane->state);
-   int idx = intel_crtc->base.base.id, ret;
int i = drm_plane_index(plane);
bool mode_changed = needs_modeset(crtc_state);
bool was_crtc_enabled = crtc->state->active;
bool is_crtc_enabled = crtc_state->active;
bool turn_off, turn_on, visible, was_visible;
struct drm_framebuffer *fb = plane_state->fb;
+   int ret;
 
if (crtc_state && INTEL_INFO(dev)->gen >= 9 &&
plane->type != DRM_PLANE_TYPE_CURSOR) {
@@ -11675,7 +11679,9 @@ int intel_plane_atomic_calc_changes(struct 
drm_crtc_state *crtc_state,
turn_off = was_visible && (!visible || mode_changed);
turn_on = visible && (!was_visible || mode_changed);
 
-   DRM_DEBUG_ATOMIC("[CRTC:%i] has [PLANE:%i] with fb %i\n", idx,
+   

[Intel-gfx] [PATCH v2 3/9] drm: Add plane->name and use it in debug prints

[ville . syrjala]

From: Ville Syrjälä 

v2: kstrdup() the name passed by the caller (Jani)

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_atomic.c| 12 ++--
 drivers/gpu/drm/drm_atomic_helper.c |  4 ++--
 drivers/gpu/drm/drm_crtc.c  | 11 ++-
 include/drm/drm_crtc.h  |  2 ++
 4 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 2944655..df84060 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -543,8 +543,8 @@ drm_atomic_get_plane_state(struct drm_atomic_state *state,
state->planes[index] = plane;
plane_state->state = state;
 
-   DRM_DEBUG_ATOMIC("Added [PLANE:%d] %p state to %p\n",
-plane->base.id, plane_state, state);
+   DRM_DEBUG_ATOMIC("Added [PLANE:%d:%s] %p state to %p\n",
+plane->base.id, plane->name, plane_state, state);
 
if (plane_state->crtc) {
struct drm_crtc_state *crtc_state;
@@ -755,8 +755,8 @@ static int drm_atomic_plane_check(struct drm_plane *plane,
}
 
if (plane_switching_crtc(state->state, plane, state)) {
-   DRM_DEBUG_ATOMIC("[PLANE:%d] switching CRTC directly\n",
-plane->base.id);
+   DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC directly\n",
+plane->base.id, plane->name);
return -EINVAL;
}
 
@@ -1229,8 +1229,8 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
for_each_plane_in_state(state, plane, plane_state, i) {
ret = drm_atomic_plane_check(plane, plane_state);
if (ret) {
-   DRM_DEBUG_ATOMIC("[PLANE:%d] atomic core check 
failed\n",
-plane->base.id);
+   DRM_DEBUG_ATOMIC("[PLANE:%d:%s] atomic core check 
failed\n",
+plane->base.id, plane->name);
return ret;
}
}
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index fc90af50..387d95c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -503,8 +503,8 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
 
ret = funcs->atomic_check(plane, plane_state);
if (ret) {
-   DRM_DEBUG_ATOMIC("[PLANE:%d] atomic driver check 
failed\n",
-plane->base.id);
+   DRM_DEBUG_ATOMIC("[PLANE:%d:%s] atomic driver check 
failed\n",
+plane->base.id, plane->name);
return ret;
}
}
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 399ded5..29f5a2a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1174,9 +1174,15 @@ int drm_universal_plane_init(struct drm_device *dev, 
struct drm_plane *plane,
struct drm_mode_config *config = >mode_config;
int ret;
 
+   plane->name = kstrdup(name, GFP_KERNEL);
+   if (!plane->name)
+   return -ENOMEM;
+
ret = drm_mode_object_get(dev, >base, DRM_MODE_OBJECT_PLANE);
-   if (ret)
+   if (ret) {
+   kfree(plane->name);
return ret;
+   }
 
drm_modeset_lock_init(>mutex);
 
@@ -1188,6 +1194,7 @@ int drm_universal_plane_init(struct drm_device *dev, 
struct drm_plane *plane,
if (!plane->format_types) {
DRM_DEBUG_KMS("out of memory when allocating plane\n");
drm_mode_object_put(dev, >base);
+   kfree(plane->name);
return -ENOMEM;
}
 
@@ -1281,6 +1288,8 @@ void drm_plane_cleanup(struct drm_plane *plane)
if (plane->state && plane->funcs->atomic_destroy_state)
plane->funcs->atomic_destroy_state(plane, plane->state);
 
+   kfree(plane->name);
+
memset(plane, 0, sizeof(*plane));
 }
 EXPORT_SYMBOL(drm_plane_cleanup);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 4d47a73..5c1c583 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -848,6 +848,8 @@ struct drm_plane {
struct drm_device *dev;
struct list_head head;
 
+   char *name;
+
struct drm_modeset_lock mutex;
 
struct drm_mode_object base;
-- 
2.4.10

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

[Intel-gfx] [PATCH v3 0/9] drm: Give crtcs and planes actual names (v3)

[ville . syrjala]

From: Ville Syrjälä 

Another attempt to give crtcs and planes human friendly names. This time I
pulled out coccinelle and added a 'name' parameter to all the crtc and plane
init functions. Third time's the charm, eh?

Previous series at:
http://lists.freedesktop.org/archives/dri-devel/2015-November/094331.html
http://lists.freedesktop.org/archives/dri-devel/2015-November/094359.html

Pushed to:
git://github.com/vsyrjala/linux.git crtc_plane_name_3

Ville Syrjälä (9):
  drm: Pass 'name' to crtc and plane init functions
  drm: Add crtc->name and use it in debug messages
  drm: Add plane->name and use it in debug prints
  drm/i915: Use crtc->name in debug messages
  drm/i915: Use plane->name in debug prints
  drm/i915: Set crtc->name to "pipe A", "pipe B", etc.
  drm/i915: Fix plane init failure paths
  drm/i915: Don't leak primary/cursor planes on crtc init failure
  drm/i915: Give meaningful names to all the planes

 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |   3 +-
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |   3 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |   3 +-
 drivers/gpu/drm/armada/armada_crtc.c|   4 +-
 drivers/gpu/drm/armada/armada_overlay.c |   2 +-
 drivers/gpu/drm/ast/ast_mode.c  |   2 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c  |   2 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c |   2 +-
 drivers/gpu/drm/bochs/bochs_kms.c   |   2 +-
 drivers/gpu/drm/cirrus/cirrus_mode.c|   2 +-
 drivers/gpu/drm/drm_atomic.c|  53 +++
 drivers/gpu/drm/drm_atomic_helper.c |  60 
 drivers/gpu/drm/drm_crtc.c  |  35 -
 drivers/gpu/drm/drm_crtc_helper.c   |  24 +--
 drivers/gpu/drm/drm_plane_helper.c  |   7 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c|   2 +-
 drivers/gpu/drm/exynos/exynos_drm_plane.c   |   2 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c  |   2 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c |   2 +-
 drivers/gpu/drm/gma500/psb_intel_display.c  |   2 +-
 drivers/gpu/drm/i915/intel_display.c| 196 +++-
 drivers/gpu/drm/i915/intel_fbdev.c  |   5 +-
 drivers/gpu/drm/i915/intel_sprite.c |  45 --
 drivers/gpu/drm/imx/imx-drm-core.c  |   2 +-
 drivers/gpu/drm/imx/ipuv3-plane.c   |   2 +-
 drivers/gpu/drm/mgag200/mgag200_mode.c  |   2 +-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c|   3 +-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c   |   3 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c|   3 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |   2 +-
 drivers/gpu/drm/nouveau/dispnv04/crtc.c |   2 +-
 drivers/gpu/drm/nouveau/dispnv04/overlay.c  |   4 +-
 drivers/gpu/drm/nouveau/nv50_display.c  |   2 +-
 drivers/gpu/drm/omapdrm/omap_crtc.c |   2 +-
 drivers/gpu/drm/omapdrm/omap_plane.c|   2 +-
 drivers/gpu/drm/qxl/qxl_display.c   |   2 +-
 drivers/gpu/drm/radeon/radeon_display.c |   2 +-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |   2 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.c |   2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   6 +-
 drivers/gpu/drm/shmobile/shmob_drm_crtc.c   |   2 +-
 drivers/gpu/drm/shmobile/shmob_drm_plane.c  |   2 +-
 drivers/gpu/drm/sti/sti_crtc.c  |   2 +-
 drivers/gpu/drm/sti/sti_cursor.c|   2 +-
 drivers/gpu/drm/sti/sti_gdp.c   |   2 +-
 drivers/gpu/drm/sti/sti_hqvdp.c |   2 +-
 drivers/gpu/drm/tegra/dc.c  |  10 +-
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c|   2 +-
 drivers/gpu/drm/udl/udl_modeset.c   |   2 +-
 drivers/gpu/drm/vc4/vc4_crtc.c  |   2 +-
 drivers/gpu/drm/vc4/vc4_plane.c |   2 +-
 drivers/gpu/drm/virtio/virtgpu_display.c|   2 +-
 drivers/gpu/drm/virtio/virtgpu_plane.c  |   2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c |   2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c|   2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c|   2 +-
 include/drm/drm_crtc.h  |  12 +-
 include/drm/drm_plane_helper.h  |   2 +-
 58 files changed, 329 insertions(+), 228 deletions(-)

-- 
2.4.10

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

[Intel-gfx] [PATCH 5/9] drm/i915: Use plane->name in debug prints

[ville . syrjala]

From: Ville Syrjälä 

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

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 6fac133..77496ef 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4433,9 +4433,9 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,
 
bool force_detach = !fb || !plane_state->visible;
 
-   DRM_DEBUG_KMS("Updating scaler for [PLANE:%d] scaler_user index 
%u.%u\n",
- intel_plane->base.base.id, intel_crtc->pipe,
- drm_plane_index(_plane->base));
+   DRM_DEBUG_KMS("Updating scaler for [PLANE:%d:%s] scaler_user index 
%u.%u\n",
+ intel_plane->base.base.id, intel_plane->base.name,
+ intel_crtc->pipe, drm_plane_index(_plane->base));
 
ret = skl_update_scaler(crtc_state, force_detach,
drm_plane_index(_plane->base),
@@ -4451,8 +4451,9 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,
 
/* check colorkey */
if (plane_state->ckey.flags != I915_SET_COLORKEY_NONE) {
-   DRM_DEBUG_KMS("[PLANE:%d] scaling with color key not allowed",
- intel_plane->base.base.id);
+   DRM_DEBUG_KMS("[PLANE:%d:%s] scaling with color key not 
allowed",
+ intel_plane->base.base.id,
+ intel_plane->base.name);
return -EINVAL;
}
 
@@ -4471,8 +4472,9 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,
case DRM_FORMAT_VYUY:
break;
default:
-   DRM_DEBUG_KMS("[PLANE:%d] FB:%d unsupported scaling format 
0x%x\n",
-   intel_plane->base.base.id, fb->base.id, 
fb->pixel_format);
+   DRM_DEBUG_KMS("[PLANE:%d:%s] FB:%d unsupported scaling format 
0x%x\n",
+ intel_plane->base.base.id, intel_plane->base.name,
+ fb->base.id, fb->pixel_format);
return -EINVAL;
}
 
@@ -11679,13 +11681,15 @@ int intel_plane_atomic_calc_changes(struct 
drm_crtc_state *crtc_state,
turn_off = was_visible && (!visible || mode_changed);
turn_on = visible && (!was_visible || mode_changed);
 
-   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] has [PLANE:%i] with fb %i\n",
+   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] has [PLANE:%d:%s] with fb %i\n",
 intel_crtc->base.base.id,
 intel_crtc->base.name,
-plane->base.id, fb ? fb->base.id : -1);
+plane->base.id, plane->name,
+fb ? fb->base.id : -1);
 
-   DRM_DEBUG_ATOMIC("[PLANE:%i] visible %i -> %i, off %i, on %i, ms %i\n",
-plane->base.id, was_visible, visible,
+   DRM_DEBUG_ATOMIC("[PLANE:%d:%s] visible %i -> %i, off %i, on %i, ms 
%i\n",
+plane->base.id, plane->name,
+was_visible, visible,
 turn_off, turn_on, mode_changed);
 
if (turn_on) {
@@ -12088,18 +12092,20 @@ static void intel_dump_pipe_config(struct intel_crtc 
*crtc,
state = to_intel_plane_state(plane->state);
fb = state->base.fb;
if (!fb) {
-   DRM_DEBUG_KMS("%s PLANE:%d plane: %u.%u idx: %d "
-   "disabled, scaler_id = %d\n",
+   DRM_DEBUG_KMS("%s [PLANE:%d:%s] plane: %u.%u idx: %d "
+ "disabled, scaler_id = %d\n",
plane->type == DRM_PLANE_TYPE_CURSOR ? "CURSOR" 
: "STANDARD",
-   plane->base.id, intel_plane->pipe,
+   plane->base.id, plane->name,
+   intel_plane->pipe,
(crtc->base.primary == plane) ? 0 : 
intel_plane->plane + 1,
drm_plane_index(plane), state->scaler_id);
continue;
}
 
-   DRM_DEBUG_KMS("%s PLANE:%d plane: %u.%u idx: %d enabled",
+   DRM_DEBUG_KMS("%s [PLANE:%d:%s] plane: %u.%u idx: %d enabled",
plane->type == DRM_PLANE_TYPE_CURSOR ? "CURSOR" : 
"STANDARD",
-   plane->base.id, intel_plane->pipe,
+   plane->base.id, plane->name,
+   intel_plane->pipe,
crtc->base.primary == plane ? 0 : intel_plane->plane + 
1,
drm_plane_index(plane));
DRM_DEBUG_KMS("\tFB:%d, fb = %ux%u format = 0x%x",
-- 
2.4.10

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Add support for stealing purgable stolen pages

[Tvrtko Ursulin]

Hi,

On 11/11/15 10:36, ankitprasad.r.sha...@intel.com wrote:

From: Chris Wilson 

If we run out of stolen memory when trying to allocate an object, see if
we can reap enough purgeable objects to free up enough contiguous free
space for the allocation. This is in principle very much like evicting
objects to free up enough contiguous space in the vma when binding
a new object - and you will be forgiven for thinking that the code looks
very similar.

At the moment, we do not allow userspace to allocate objects in stolen,
so there is neither the memory pressure to trigger stolen eviction nor
any purgeable objects inside the stolen arena. However, this will change
in the near future, and so better management and defragmentation of
stolen memory will become a real issue.

v2: Remember to remove the drm_mm_node.

v3: Rebased to the latest drm-intel-nightly (Ankit)

v4: corrected if-else braces format (Tvrtko/kerneldoc)

v5: Rebased to the latest drm-intel-nightly (Ankit)
Added a seperate list to maintain purgable objects from stolen memory
region (Chris/Daniel)

v6: Compiler optimization (merging 2 single loops into one for() loop),
corrected code for object eviction, retire_requests before starting
object eviction (Chris)

v7: Added kernel doc for i915_gem_object_create_stolen()

v8: Check for struct_mutex lock before creating object from stolen
region (Tvrtko)

Testcase: igt/gem_stolen

Signed-off-by: Chris Wilson 
Signed-off-by: Ankitprasad Sharma 
---
  drivers/gpu/drm/i915/i915_debugfs.c|   6 +-
  drivers/gpu/drm/i915/i915_drv.h|  17 +++-
  drivers/gpu/drm/i915/i915_gem.c|  16 
  drivers/gpu/drm/i915/i915_gem_stolen.c | 170 +
  drivers/gpu/drm/i915/intel_pm.c|   4 +-
  5 files changed, 188 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 5659d4c..89b0fec 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -174,7 +174,7 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object 
*obj)
seq_puts(m, ")");
}
if (obj->stolen)
-   seq_printf(m, " (stolen: %08llx)", obj->stolen->start);
+   seq_printf(m, " (stolen: %08llx)", obj->stolen->base.start);
if (obj->pin_display || obj->fault_mappable) {
char s[3], *t = s;
if (obj->pin_display)
@@ -253,9 +253,9 @@ static int obj_rank_by_stolen(void *priv,
struct drm_i915_gem_object *b =
container_of(B, struct drm_i915_gem_object, obj_exec_link);

-   if (a->stolen->start < b->stolen->start)
+   if (a->stolen->base.start < b->stolen->base.start)
return -1;
-   if (a->stolen->start > b->stolen->start)
+   if (a->stolen->base.start > b->stolen->base.start)
return 1;
return 0;
  }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9c731f6..2c75c32 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -841,6 +841,12 @@ struct i915_ctx_hang_stats {
bool banned;
  };

+struct i915_stolen_node {
+   struct drm_mm_node base;
+   struct list_head mm_link;
+   struct drm_i915_gem_object *obj;
+};
+
  /* This must match up with the value previously used for execbuf2.rsvd1. */
  #define DEFAULT_CONTEXT_HANDLE 0

@@ -1252,6 +1258,13 @@ struct i915_gem_mm {
 */
struct list_head unbound_list;

+   /**
+* List of stolen objects that have been marked as purgeable and
+* thus available for reaping if we need more space for a new
+* allocation. Ordered by time of marking purgeable.
+*/
+   struct list_head stolen_list;
+
/** Usable portion of the GTT for GEM */
unsigned long stolen_base; /* limited to low memory (32-bit) */

@@ -2032,7 +2045,7 @@ struct drm_i915_gem_object {
struct list_head vma_list;

/** Stolen memory for this object, instead of being backed by shmem. */
-   struct drm_mm_node *stolen;
+   struct i915_stolen_node *stolen;
struct list_head global_list;

struct list_head ring_list[I915_NUM_RINGS];
@@ -2040,6 +2053,7 @@ struct drm_i915_gem_object {
struct list_head obj_exec_link;

struct list_head batch_pool_link;
+   struct list_head tmp_link;


Could you put a comment describing if it is safe or not for potential 
other users to use tmp_link, or with what considerations?


Or alternatively use a dedicated name so it will be obvious it is for 
stolen list only?



/**
 * This is set if the object is on the active lists (has pending
@@ -2156,6 +2170,7 @@ struct drm_i915_gem_object {
};
  };
  #define to_intel_bo(x) container_of(x, struct drm_i915_gem_object, base)
+#define I915_BO_IS_ACTIVE(__obj) (__obj->active)


Do you need this macro, 

Re: [Intel-gfx] [PATCH maintainer-tools] dim: Remove git commit --amend from dim_apply

[Ander Conselvan De Oliveira]

On Fri, 2015-11-13 at 15:07 +, Tvrtko Ursulin wrote:
> On 13/11/15 14:40, Ander Conselvan De Oliveira wrote:
> > On Fri, 2015-11-13 at 12:31 +, Tvrtko Ursulin wrote:
> > > On 13/11/15 12:16, Chris Wilson wrote:
> > > > On Fri, Nov 13, 2015 at 02:05:39PM +0200, Ander Conselvan de Oliveira
> > > > wrote:
> > > > > Calling git --amend invokes the editor, which will not run if it
> > > > > relies
> > > > > on the terminal for input. So don't do that from dim_apply.
> > > > > 
> > > > > Signed-off-by: Ander Conselvan de Oliveira <
> > > > > ander.conselvan.de.olive...@intel.com>
> > > > 
> > > > Presumable the ammend is there for a good reason and removing it keeps
> > > > the state dirty? So maybe --amend --no-edit?
> > > 
> > > In either case can also consider "test -t 0" which is like isatty(0).
> > 
> > I think that will always evaluate to false since you are supposed to cat the
> > mbox to dim apply.
> 
> Question is then how does it work for Daniel. :)

If I understood correctly he uses gvim, which doesn't run on a terminal.

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

Re: [Intel-gfx] [PATCH maintainer-tools] dim: Replace git commit --amend from dim_apply with dimrc option

[Lukas Wunner]

Hi Ander,

On Fri, Nov 13, 2015 at 05:05:09PM +0200, Ander Conselvan de Oliveira wrote:
> Introduce DIM_POST_APPLY_ACTION to dimrc that allows the user to specify
> a command to be run after a patch is applied. Use eval so enviroment
> variables can be overriden with the option. For example:
> 
> DIM_POST_APPLY_ACTION="EDITOR=\"gedit -w\" git commit --amend"

So an attacker wishing to smuggle a backdoor into the Linux kernel
only needs to find a way to modify that environment variable on
an Intel developers' machine.

If dim is invoked with $EDITOR set, this should be inherited to
child processes anyway, so it seems unnecessary to call eval.

Just my 2 cents,

Lukas

> 
> Signed-off-by: Ander Conselvan de Oliveira 
> 
> ---
>  dim  | 2 +-
>  dimrc.sample | 3 +++
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/dim b/dim
> index db92c57..b7c7ef7 100755
> --- a/dim
> +++ b/dim
> @@ -383,7 +383,7 @@ function dim_apply
>   commit_add_tag "Link" 
> "http://patchwork.freedesktop.org/patch/msgid/$message_id;
>   fi
>  
> - git commit --amend &
> + eval $DRY $DIM_POST_APPLY_ACTION
>  }
>  
>  function magic_patch
> diff --git a/dimrc.sample b/dimrc.sample
> index 5687eaf..9f30cb2 100644
> --- a/dimrc.sample
> +++ b/dimrc.sample
> @@ -21,3 +21,6 @@
>  # Mail User Agent supporting a subset of mutt(1) command line options:
>  # [-s subject] [-i file] [-c cc-addr] to-addr [...]
>  #DIM_MUA=mutt
> +
> +# Command to run after dim apply
> +#DIM_POST_APPLY_ACTION=git commit --amend
> -- 
> 2.4.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 00/13] Yet another FBC series, v3 part 1

[Daniel Stone]

Hey,

On 13 November 2015 at 16:36, Zanoni, Paulo R  wrote:
> Em Sex, 2015-11-13 às 15:49 +, Daniel Stone escreveu:
>> On 4 November 2015 at 19:10, Paulo Zanoni 
>> wrote:
>> > So Ville pointed a problem on patch 02/26 of the previous series,
>> > and the nice
>> > fix for that would make me rebase most of the subsequent patches.
>> > In order to
>> > avoid blocking the other patches on the review of patch 02 and in
>> > order to avoid
>> > having to rebase everything again and again during this I decided
>> > to change the
>> > order of the patches on the series and try to get a smaller chunk
>> > of patches
>> > merged before moving on to the others.
>> >
>> > These first 13 patches are somewhat trivial and are mostly just
>> > moving code
>> > around, with only one or two simple bug fixes. If you wonder why
>> > some of these
>> > changes are needed, please go check the complete series (the short
>> > answer is:
>> > most of the changes are needed for the new model with
>> > enable/disable +
>> > activate/deactivate).
>> >
>> > After all these patches are merged I'll resend the rest.
>>
>> This series is missing 01/26 of your previous series (make
>> no_fbc_reason a string).
>
> It was already merged when I resent:
>
> http://cgit.freedesktop.org/drm-intel/commit/?id=bf6189c6f062b5cd6ca0d4
> 6754e4c3064643f48c

Sorry, missed that somehow!

Cheers,
Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Fix GT frequency rounding

[Mika Kuoppala]

When we set and later readback a frequency value through
sysfs interface, igt/pm_rpm assumes that we get same value back
if it matches hw granularity.

On bxt we have found out that this is not always the case.
Currently frequency - hw ratio - frequency conversions round down,
with few exceptions on platforms that have more specific conversions.
On bxt the supported range can be for example from 100Mhz to 650Mhz.
Midpoint is then calculated by test to be 375 which pm_rps uses to find a
closest hw supported frequency. That is 366 (ratio 22),
which it then writes back. But as the rounding down kicks in,
driver actually sets 350 instead of 366, as 366 is 2/3 below 22 * 50/3.

Fix this by rounding to closest instead of rounding down in
freq-ratio-freq conversions.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92768
Testcase: igt/pm_rps/basic-api
Tested-by: Bob Paauwe 
Cc: Bob Paauwe 
Signed-off-by: Imre Deak 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_pm.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 647c0ff..740623f 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7139,7 +7139,8 @@ static int chv_freq_opcode(struct drm_i915_private 
*dev_priv, int val)
 int intel_gpu_freq(struct drm_i915_private *dev_priv, int val)
 {
if (IS_GEN9(dev_priv->dev))
-   return (val * GT_FREQUENCY_MULTIPLIER) / GEN9_FREQ_SCALER;
+   return DIV_ROUND_CLOSEST(val * GT_FREQUENCY_MULTIPLIER,
+GEN9_FREQ_SCALER);
else if (IS_CHERRYVIEW(dev_priv->dev))
return chv_gpu_freq(dev_priv, val);
else if (IS_VALLEYVIEW(dev_priv->dev))
@@ -7151,13 +7152,14 @@ int intel_gpu_freq(struct drm_i915_private *dev_priv, 
int val)
 int intel_freq_opcode(struct drm_i915_private *dev_priv, int val)
 {
if (IS_GEN9(dev_priv->dev))
-   return (val * GEN9_FREQ_SCALER) / GT_FREQUENCY_MULTIPLIER;
+   return DIV_ROUND_CLOSEST(val * GEN9_FREQ_SCALER,
+GT_FREQUENCY_MULTIPLIER);
else if (IS_CHERRYVIEW(dev_priv->dev))
return chv_freq_opcode(dev_priv, val);
else if (IS_VALLEYVIEW(dev_priv->dev))
return byt_freq_opcode(dev_priv, val);
else
-   return val / GT_FREQUENCY_MULTIPLIER;
+   return DIV_ROUND_CLOSEST(val, GT_FREQUENCY_MULTIPLIER);
 }
 
 struct request_boost {
-- 
2.5.0

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

[Intel-gfx] [PATCH maintainer-tools] dim: Replace git commit --amend from dim_apply with dimrc option

[Ander Conselvan de Oliveira]

Introduce DIM_POST_APPLY_ACTION to dimrc that allows the user to specify
a command to be run after a patch is applied. Use eval so enviroment
variables can be overriden with the option. For example:

DIM_POST_APPLY_ACTION="EDITOR=\"gedit -w\" git commit --amend"

Signed-off-by: Ander Conselvan de Oliveira 

---
 dim  | 2 +-
 dimrc.sample | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/dim b/dim
index db92c57..b7c7ef7 100755
--- a/dim
+++ b/dim
@@ -383,7 +383,7 @@ function dim_apply
commit_add_tag "Link" 
"http://patchwork.freedesktop.org/patch/msgid/$message_id;
fi
 
-   git commit --amend &
+   eval $DRY $DIM_POST_APPLY_ACTION
 }
 
 function magic_patch
diff --git a/dimrc.sample b/dimrc.sample
index 5687eaf..9f30cb2 100644
--- a/dimrc.sample
+++ b/dimrc.sample
@@ -21,3 +21,6 @@
 # Mail User Agent supporting a subset of mutt(1) command line options:
 # [-s subject] [-i file] [-c cc-addr] to-addr [...]
 #DIM_MUA=mutt
+
+# Command to run after dim apply
+#DIM_POST_APPLY_ACTION=git commit --amend
-- 
2.4.3

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

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Broxton doesn't use gen9 scaling for rps frequencies.

[Imre Deak]

On to, 2015-11-12 at 10:14 -0800, Bob Paauwe wrote:
> On Thu, 12 Nov 2015 10:35:00 +0200
> Imre Deak  wrote:
> 
> > On Wed, 2015-11-11 at 13:36 -0800, Bob Paauwe wrote:
> > > On Tue, 10 Nov 2015 11:04:22 +0200
> > > Mika Kuoppala  wrote:
> > > 
> > > > Bob Paauwe  writes:
> > > > 
> > > > > Signed-off-by: Bob Paauwe 
> > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92768
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_pm.c | 4 ++--
> > > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > > index 647c0ff..fc5097f 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > > @@ -7138,7 +7138,7 @@ static int chv_freq_opcode(struct
> > > > > drm_i915_private *dev_priv, int val)
> > > > >  
> > > > >  int intel_gpu_freq(struct drm_i915_private *dev_priv, int
> > > > > val)
> > > > >  {
> > > > > - if (IS_GEN9(dev_priv->dev))
> > > > > + if (IS_GEN9(dev_priv->dev) && !IS_BROXTON(dev_priv
> > > > > ->dev))
> > > > >   return (val * GT_FREQUENCY_MULTIPLIER) /
> > > > >  GEN9_FREQ_SCALER;
> > > > 
> > > > Documentation disagrees with this patch. The units are 16.67Mhz
> > > > thus we should use 50/3.
> > > > 
> > > > -Mika
> > > 
> > > I'm not sure I trust the documentation in this case.  Elsewhere,
> > > in
> > > gen6_init_rps_frequencies() we use GEN9_FREQ_SCALER for SKL only,
> > > not for BXT.
> > 
> > On SKL the frequency _capability_ register uses 50MHz units, but
> > the
> > frequency _request_ register uses 16.67MHz units. We store the
> > frequency
> > limits in 16.67MHz units in rps.rp*_freq, hence the use of
> > GEN9_FREQ_SCALER in gen6_init_rps_frequencies(). When requesting a
> > frequency we only use GEN9_FREQ_SCALER to get the 16.67MHz constant
> > value.
> > 
> > On BXT both the capability and request registers use 16.67MHz
> > units, so
> > we don't need to convert in gen6_init_rps_frequencies(), but we
> > still
> > use GEN9_FREQ_SCALER when requesting the frequency to get the
> > 16.67MHz
> > constant value.
> > Confusing like hell, but it works.
> 
> That makes it a bit less confusing, thanks!   Is this all documented
> somewhere?  I'd like to read up on it so if you have any pointers
> please send me an email.

For SKL:
RP_STATE_CAP in configdb (offset 0x5998)
RP_FREQ_NORMAL in bspec (0xA008)

For BXT:
GRAPHICS_FREQUENCY_CAPABILITIES in configdb (offset 0x8170)
RP_FREQ_NORMAL in bspec (0xA008)

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

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Clarify plane state during CRTC state dumps

[Ville Syrjälä]

On Thu, Nov 12, 2015 at 04:31:57PM -0800, Matt Roper wrote:
> During state dumping, list planes that have an FB but are invisible
> (e.g., because they're offscreen or clipped by other planes) as "not
> visible" rather than "enabled."  While we're at it, throw the bpp value
> into the debugging output.
> 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 7bbcb98..d994f52 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12102,13 +12102,15 @@ static void intel_dump_pipe_config(struct 
> intel_crtc *crtc,
>   continue;
>   }
>  
> - DRM_DEBUG_KMS("%s PLANE:%d plane: %u.%u idx: %d enabled",
> + DRM_DEBUG_KMS("%s PLANE:%d plane: %u.%u idx: %d %s",
>   plane->type == DRM_PLANE_TYPE_CURSOR ? "CURSOR" : 
> "STANDARD",
>   plane->base.id, intel_plane->pipe,
>   crtc->base.primary == plane ? 0 : intel_plane->plane + 
> 1,
> - drm_plane_index(plane));
> - DRM_DEBUG_KMS("\tFB:%d, fb = %ux%u format = 0x%x",
> - fb->base.id, fb->width, fb->height, fb->pixel_format);
> + drm_plane_index(plane),
> + state->visible ? "enabled" : "not visible");
> + DRM_DEBUG_KMS("\tFB:%d, fb = %ux%u format = 0x%x bpp = %d",
> + fb->base.id, fb->width, fb->height, fb->pixel_format,
> + fb->bits_per_pixel);

Let's try to avoid bits_per_pixel shall we. It's not even populated for
YCbCr formats. We print the format here already so I think it should be
enough. But we should dump in using drm_get_format_name().

>   DRM_DEBUG_KMS("\tscaler:%d src (%u, %u) %ux%u dst (%u, %u) 
> %ux%u\n",
>   state->scaler_id,
>   state->src.x1 >> 16, state->src.y1 >> 16,
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Intel-gfx] [PATCH] drm/i915: Fix crtc_y assignment in intel_find_initial_plane_obj()

[ville . syrjala]

From: Ville Syrjälä 

Let's set crtc_y to 0 instead of setting src_y twice.

Multiple assignments in one statement is a good way to hide bugs.
Please don't do that.

Cc: Maarten Lankhorst 
Fixes: be5651f2d581 ("drm/i915: Update missing properties in 
find_initial_plane_obj")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d7c8a0f..e3db46d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2640,11 +2640,13 @@ intel_find_initial_plane_obj(struct intel_crtc 
*intel_crtc,
return;
 
 valid_fb:
-   plane_state->src_x = plane_state->src_y = 0;
+   plane_state->src_x = 0;
+   plane_state->src_y = 0;
plane_state->src_w = fb->width << 16;
plane_state->src_h = fb->height << 16;
 
-   plane_state->crtc_x = plane_state->src_y = 0;
+   plane_state->crtc_x = 0;
+   plane_state->crtc_y = 0;
plane_state->crtc_w = fb->width;
plane_state->crtc_h = fb->height;
 
-- 
2.4.10

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

[Intel-gfx] [PATCH 1/9] drm: Pass 'name' to crtc and plane init functions

[ville . syrjala]

From: Ville Syrjälä 

Allow the driver to pass a crtc and plane names to the crtc and plane
init functions. Will be used later to populate the crtc and plane name
that gets printed in debug messages.

Done with coccinelle for the most part. It choked on
msm/mdp/mdp5/mdp5_plane.c like so:
"BAD:!  enum drm_plane_type type;"
No idea how to deal with that, so I just fixed that up by hand.

@@
identifier dev, crtc, funcs;
@@
 int drm_crtc_init(struct drm_device *dev,
   struct drm_crtc *crtc,
   const struct drm_crtc_funcs *funcs
+  ,const char *name
   )
 { ... }

@@
identifier dev, crtc, funcs;
@@
 int drm_crtc_init(struct drm_device *dev,
   struct drm_crtc *crtc,
   const struct drm_crtc_funcs *funcs
+  ,const char *name
   );

@@
identifier dev, crtc, primary, cursor, funcs;
@@
 int drm_crtc_init_with_planes(struct drm_device *dev,
   struct drm_crtc *crtc,
   struct drm_plane *primary, struct drm_plane 
*cursor,
   const struct drm_crtc_funcs *funcs
+  ,const char *name
   )
 { ... }

@@
identifier dev, crtc, primary, cursor, funcs;
@@
 int drm_crtc_init_with_planes(struct drm_device *dev,
   struct drm_crtc *crtc,
   struct drm_plane *primary, struct drm_plane 
*cursor,
   const struct drm_crtc_funcs *funcs
+  ,const char *name
   );

@@
typedef uint32_t;
identifier dev, plane, possible_crtcs, funcs, formats, format_count, is_primary;
@@
 int drm_plane_init(struct drm_device *dev,
struct drm_plane *plane,
unsigned long possible_crtcs,
const struct drm_plane_funcs *funcs,
const uint32_t *formats,
unsigned int format_count,
bool is_primary
+   ,const char *name
)
 { ... }

@@
identifier dev, plane, possible_crtcs, funcs, formats, format_count, is_primary;
@@
 int drm_plane_init(struct drm_device *dev,
struct drm_plane *plane,
unsigned long possible_crtcs,
const struct drm_plane_funcs *funcs,
const uint32_t *formats,
unsigned int format_count,
bool is_primary
+   ,const char *name
);

@@
identifier dev, plane, possible_crtcs, funcs, formats, format_count, type;
@@
 int drm_universal_plane_init(struct drm_device *dev,
  struct drm_plane *plane,
  unsigned long possible_crtcs,
  const struct drm_plane_funcs *funcs,
  const uint32_t *formats,
  unsigned int format_count,
  enum drm_plane_type type
+ ,const char *name
  )
 { ... }

@@
identifier dev, plane, possible_crtcs, funcs, formats, format_count, type;
@@
 int drm_universal_plane_init(struct drm_device *dev,
  struct drm_plane *plane,
  unsigned long possible_crtcs,
  const struct drm_plane_funcs *funcs,
  const uint32_t *formats,
  unsigned int format_count,
  enum drm_plane_type type
+ ,const char *name
  );

@@
expression E1, E2, E3;
@@
 drm_crtc_init(E1, E2, E3
+  ,""
   )

@@
expression E1, E2, E3, E4, E5;
@@
 drm_crtc_init_with_planes(E1, E2, E3, E4, E5
+  ,""
   )

@@
expression E1, E2, E3, E4, E5, E6, E7;
@@
 drm_plane_init(E1, E2, E3, E4, E5, E6, E7
+   ,""
)

@@
expression E1, E2, E3, E4, E5, E6, E7;
@@
 drm_universal_plane_init(E1, E2, E3, E4, E5, E6, E7
+ ,""
  )

@@
@@
 int drm_crtc_init(...)
 {
...
return drm_crtc_init_with_planes(...,
- ""
+ name
 );
...
 }

@@
@@
 int drm_plane_init(...)
 {
...
return drm_universal_plane_init(...,
- ""
+ name
 );
...
 }

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |  3 ++-
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |  3 ++-
 

[Intel-gfx] [PATCH 8/9] drm/i915: Don't leak primary/cursor planes on crtc init failure

[ville . syrjala]

From: Ville Syrjälä 

Call intel_plane_destroy() instead of drm_plane_cleanup() so that we
also free the plane struct itself when bailing out of the crtc init.

And make intel_plane_destroy() NULL tolerant to avoid having to check
for it in the caller.

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

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 694b126..de1c5fdf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13780,9 +13780,11 @@ static void intel_finish_crtc_commit(struct drm_crtc 
*crtc,
  */
 void intel_plane_destroy(struct drm_plane *plane)
 {
-   struct intel_plane *intel_plane = to_intel_plane(plane);
+   if (!plane)
+   return;
+
drm_plane_cleanup(plane);
-   kfree(intel_plane);
+   kfree(to_intel_plane(plane));
 }
 
 const struct drm_plane_funcs intel_plane_funcs = {
@@ -14118,10 +14120,8 @@ static void intel_crtc_init(struct drm_device *dev, 
int pipe)
return;
 
 fail:
-   if (primary)
-   drm_plane_cleanup(primary);
-   if (cursor)
-   drm_plane_cleanup(cursor);
+   intel_plane_destroy(primary);
+   intel_plane_destroy(cursor);
kfree(crtc_state);
kfree(intel_crtc);
 }
-- 
2.4.10

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

[Intel-gfx] [PATCH v2 7/9] drm/i915: Fix plane init failure paths

[ville . syrjala]

From: Ville Syrjälä 

Deal with errors from drm_universal_plane_init() in primary and cursor
plane init paths (sprites were already covered). Also make the code
neater by using goto for error handling.

v2: Rebased due to drm_universal_plane_init() 'name' parameter

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 64 ++--
 drivers/gpu/drm/i915/intel_sprite.c  | 34 +++
 2 files changed, 60 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5032fac..694b126 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13800,20 +13800,19 @@ const struct drm_plane_funcs intel_plane_funcs = {
 static struct drm_plane *intel_primary_plane_create(struct drm_device *dev,
int pipe)
 {
-   struct intel_plane *primary;
-   struct intel_plane_state *state;
+   struct intel_plane *primary = NULL;
+   struct intel_plane_state *state = NULL;
const uint32_t *intel_primary_formats;
unsigned int num_formats;
+   int ret;
 
primary = kzalloc(sizeof(*primary), GFP_KERNEL);
-   if (primary == NULL)
-   return NULL;
+   if (!primary)
+   goto fail;
 
state = intel_create_plane_state(>base);
-   if (!state) {
-   kfree(primary);
-   return NULL;
-   }
+   if (!state)
+   goto fail;
primary->base.state = >base;
 
primary->can_scale = false;
@@ -13842,10 +13841,12 @@ static struct drm_plane 
*intel_primary_plane_create(struct drm_device *dev,
num_formats = ARRAY_SIZE(i8xx_primary_formats);
}
 
-   drm_universal_plane_init(dev, >base, 0,
-_plane_funcs,
-intel_primary_formats, num_formats,
-DRM_PLANE_TYPE_PRIMARY, "");
+   ret = drm_universal_plane_init(dev, >base, 0,
+  _plane_funcs,
+  intel_primary_formats, num_formats,
+  DRM_PLANE_TYPE_PRIMARY, "");
+   if (ret)
+   goto fail;
 
if (INTEL_INFO(dev)->gen >= 4)
intel_create_rotation_property(dev, primary);
@@ -13853,6 +13854,12 @@ static struct drm_plane 
*intel_primary_plane_create(struct drm_device *dev,
drm_plane_helper_add(>base, _plane_helper_funcs);
 
return >base;
+
+fail:
+   kfree(state);
+   kfree(primary);
+
+   return NULL;
 }
 
 void intel_create_rotation_property(struct drm_device *dev, struct intel_plane 
*plane)
@@ -13957,18 +13964,17 @@ update:
 static struct drm_plane *intel_cursor_plane_create(struct drm_device *dev,
   int pipe)
 {
-   struct intel_plane *cursor;
-   struct intel_plane_state *state;
+   struct intel_plane *cursor = NULL;
+   struct intel_plane_state *state = NULL;
+   int ret;
 
cursor = kzalloc(sizeof(*cursor), GFP_KERNEL);
-   if (cursor == NULL)
-   return NULL;
+   if (!cursor)
+   goto fail;
 
state = intel_create_plane_state(>base);
-   if (!state) {
-   kfree(cursor);
-   return NULL;
-   }
+   if (!state)
+   goto fail;
cursor->base.state = >base;
 
cursor->can_scale = false;
@@ -13980,11 +13986,13 @@ static struct drm_plane 
*intel_cursor_plane_create(struct drm_device *dev,
cursor->commit_plane = intel_commit_cursor_plane;
cursor->disable_plane = intel_disable_cursor_plane;
 
-   drm_universal_plane_init(dev, >base, 0,
-_plane_funcs,
-intel_cursor_formats,
-ARRAY_SIZE(intel_cursor_formats),
-DRM_PLANE_TYPE_CURSOR, "");
+   ret = drm_universal_plane_init(dev, >base, 0,
+  _plane_funcs,
+  intel_cursor_formats,
+  ARRAY_SIZE(intel_cursor_formats),
+  DRM_PLANE_TYPE_CURSOR, "");
+   if (ret)
+   goto fail;
 
if (INTEL_INFO(dev)->gen >= 4) {
if (!dev->mode_config.rotation_property)
@@ -14004,6 +14012,12 @@ static struct drm_plane 
*intel_cursor_plane_create(struct drm_device *dev,
drm_plane_helper_add(>base, _plane_helper_funcs);
 
return >base;
+
+fail:
+   kfree(state);
+   kfree(cursor);
+
+   return NULL;
 }
 
 static void skl_init_scalers(struct drm_device *dev, struct intel_crtc 
*intel_crtc,
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 

[Intel-gfx] [PATCH v2 2/9] drm: Add crtc->name and use it in debug messages

[ville . syrjala]

From: Ville Syrjälä 

v2: kstrdup() the name passed by the caller (Jani)

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_atomic.c| 41 ++-
 drivers/gpu/drm/drm_atomic_helper.c | 56 +++--
 drivers/gpu/drm/drm_crtc.c  | 15 --
 drivers/gpu/drm/drm_crtc_helper.c   | 24 
 include/drm/drm_crtc.h  |  2 ++
 5 files changed, 77 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7bb3845..2944655 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -288,8 +288,8 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
state->crtcs[index] = crtc;
crtc_state->state = state;
 
-   DRM_DEBUG_ATOMIC("Added [CRTC:%d] %p state to %p\n",
-crtc->base.id, crtc_state, state);
+   DRM_DEBUG_ATOMIC("Added [CRTC:%d:%s] %p state to %p\n",
+crtc->base.id, crtc->name, crtc_state, state);
 
return crtc_state;
 }
@@ -480,8 +480,8 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
 */
 
if (state->active && !state->enable) {
-   DRM_DEBUG_ATOMIC("[CRTC:%d] active without enabled\n",
-crtc->base.id);
+   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] active without enabled\n",
+crtc->base.id, crtc->name);
return -EINVAL;
}
 
@@ -490,15 +490,15 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
 * be able to trigger. */
if (drm_core_check_feature(crtc->dev, DRIVER_ATOMIC) &&
WARN_ON(state->enable && !state->mode_blob)) {
-   DRM_DEBUG_ATOMIC("[CRTC:%d] enabled without mode blob\n",
-crtc->base.id);
+   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] enabled without mode blob\n",
+crtc->base.id, crtc->name);
return -EINVAL;
}
 
if (drm_core_check_feature(crtc->dev, DRIVER_ATOMIC) &&
WARN_ON(!state->enable && state->mode_blob)) {
-   DRM_DEBUG_ATOMIC("[CRTC:%d] disabled with mode blob\n",
-crtc->base.id);
+   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] disabled with mode blob\n",
+crtc->base.id, crtc->name);
return -EINVAL;
}
 
@@ -980,8 +980,8 @@ drm_atomic_set_crtc_for_plane(struct drm_plane_state 
*plane_state,
}
 
if (crtc)
-   DRM_DEBUG_ATOMIC("Link plane state %p to [CRTC:%d]\n",
-plane_state, crtc->base.id);
+   DRM_DEBUG_ATOMIC("Link plane state %p to [CRTC:%d:%s]\n",
+plane_state, crtc->base.id, crtc->name);
else
DRM_DEBUG_ATOMIC("Link plane state %p to [NOCRTC]\n",
 plane_state);
@@ -1048,8 +1048,8 @@ drm_atomic_set_crtc_for_connector(struct 
drm_connector_state *conn_state,
conn_state->crtc = crtc;
 
if (crtc)
-   DRM_DEBUG_ATOMIC("Link connector state %p to [CRTC:%d]\n",
-conn_state, crtc->base.id);
+   DRM_DEBUG_ATOMIC("Link connector state %p to [CRTC:%d:%s]\n",
+conn_state, crtc->base.id, crtc->name);
else
DRM_DEBUG_ATOMIC("Link connector state %p to [NOCRTC]\n",
 conn_state);
@@ -1088,8 +1088,8 @@ drm_atomic_add_affected_connectors(struct 
drm_atomic_state *state,
if (ret)
return ret;
 
-   DRM_DEBUG_ATOMIC("Adding all current connectors for [CRTC:%d] to %p\n",
-crtc->base.id, state);
+   DRM_DEBUG_ATOMIC("Adding all current connectors for [CRTC:%d:%s] to 
%p\n",
+crtc->base.id, crtc->name, state);
 
/*
 * Changed connectors are already in @state, so only need to look at the
@@ -1169,8 +1169,9 @@ drm_atomic_connectors_for_crtc(struct drm_atomic_state 
*state,
num_connected_connectors++;
}
 
-   DRM_DEBUG_ATOMIC("State %p has %i connectors for [CRTC:%d]\n",
-state, num_connected_connectors, crtc->base.id);
+   DRM_DEBUG_ATOMIC("State %p has %i connectors for [CRTC:%d:%s]\n",
+state, num_connected_connectors,
+crtc->base.id, crtc->name);
 
return num_connected_connectors;
 }
@@ -1237,8 +1238,8 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
for_each_crtc_in_state(state, crtc, crtc_state, i) {
ret = drm_atomic_crtc_check(crtc, crtc_state);
if (ret) {
-   DRM_DEBUG_ATOMIC("[CRTC:%d] atomic core check failed\n",
-   

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Setup clipped src/dest coordinates during FB reconstruction

[Ville Syrjälä]

On Thu, Nov 12, 2015 at 04:31:59PM -0800, Matt Roper wrote:
> Plane state objects contain two copies of src/dest coordinates:  the
> original (requested by userspace) coordinates in the base
> drm_plane_state object, and a second, clipped copy (i.e., what we
> actually want to program to the hardware) in intel_plane_state.  We've
> only been setting up the former set of values during boot time FB
> reconstruction, but we should really be initializing both.
> 
> Note that the code here probably still needs some more work.  We seem to
> be making two questionable assumptions:
>  * BIOS will program the primary plane to the entire display size
>(potentially false on gen9+ platforms where the primary plane can be
>windowed)

We don't actually assume that on SKL+. We read out the plane size
register and use that to set the initial fb dimensions. Although if
the BIOS uses a scaled plane, we will get the wrong answer since then
the plane size register will contain the dst size, not the src.

>  * The BIOS fb size actually matches the plane/display size.  It seems
>that there's nothing stopping the BIOS from overallocating the FB
>(potentially to do an extended mode FB that spans multiple displays),
>so setting our src/dest coordinates to the FB size here may not
>always be right.

I suppose we could have some kind of post-process step after the readout
to see if all the planes actually scan out from different parts of the
same fb. But that seems rather unlikely to me.

The other assumption we do is that the BIOS sets up GTT to 1:1
map the stolen memory. Not sure if some BIOSen would for instance
try to avoid the first page of stolen on gen8 (with EFI it should be
doable I suppose, with VGA probably not), or maybe sets up a 90/270
rotated mapping instead. I have one BYT tablet where the BIOS uses
180 degree rotation, so even 90/270 degree rotation is not totally
out of the question I think.

> 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 9fa041c..3145c9d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2601,6 +2601,8 @@ intel_find_initial_plane_obj(struct intel_crtc 
> *intel_crtc,
>   struct drm_i915_gem_object *obj;
>   struct drm_plane *primary = intel_crtc->base.primary;
>   struct drm_plane_state *plane_state = primary->state;
> + struct intel_plane_state *intel_state =
> + to_intel_plane_state(plane_state);
>   struct drm_framebuffer *fb;
>  
>   if (!plane_config->fb)
> @@ -2648,6 +2650,15 @@ valid_fb:
>   plane_state->crtc_w = fb->width;
>   plane_state->crtc_h = fb->height;
>  
> + intel_state->src.x1 = plane_state->src_x;
> + intel_state->src.y1 = plane_state->src_y;
> + intel_state->src.x2 = plane_state->src_x + plane_state->src_w;
> + intel_state->src.y2 = plane_state->src_y + plane_state->src_h;
> + intel_state->dst.x1 = plane_state->crtc_x;
> + intel_state->dst.y1 = plane_state->crtc_y;
> + intel_state->dst.x2 = plane_state->crtc_x + plane_state->crtc_w;
> + intel_state->dst.y2 = plane_state->crtc_y + plane_state->crtc_h;

Patch looks sane.
Reviewed-by: Ville Syrjälä 

> +
>   obj = intel_fb_obj(fb);
>   if (obj->tiling_mode != I915_TILING_NONE)
>   dev_priv->preserve_bios_swizzle = true;
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 00/13] Yet another FBC series, v3 part 1

[Daniel Stone]

Hi Paulo,

On 4 November 2015 at 19:10, Paulo Zanoni  wrote:
> So Ville pointed a problem on patch 02/26 of the previous series, and the nice
> fix for that would make me rebase most of the subsequent patches. In order to
> avoid blocking the other patches on the review of patch 02 and in order to 
> avoid
> having to rebase everything again and again during this I decided to change 
> the
> order of the patches on the series and try to get a smaller chunk of patches
> merged before moving on to the others.
>
> These first 13 patches are somewhat trivial and are mostly just moving code
> around, with only one or two simple bug fixes. If you wonder why some of these
> changes are needed, please go check the complete series (the short answer is:
> most of the changes are needed for the new model with enable/disable +
> activate/deactivate).
>
> After all these patches are merged I'll resend the rest.

This series is missing 01/26 of your previous series (make
no_fbc_reason a string).

Cheers,
Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] igt/igt_kms: Introduce get_first_connected_output (v2)

[Thomas Wood]

On 5 November 2015 at 01:34, Vivek Kasireddy  wrote:
> In some cases, we just need one valid (connected) output to perform
> a test. This macro can help in these situations by not having to
> put the test code inside a for loop that iterates over all the outputs.
>
> v2: Added a brief documentation for this macro.

The new macro is no longer being used anywhere. Is there a new patch
that uses the macro?


Also, if re-sending the patch, please make sure it is tagged correctly
as described in:

http://lists.freedesktop.org/archives/intel-gfx/2015-November/079712.html

This also explains how to manage the version tag in the subject line.


>
> Suggested-by: Matt Roper 
> Cc: Thomas Wood 
> Signed-off-by: Vivek Kasireddy 
> ---
>  lib/igt_kms.h | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/lib/igt_kms.h b/lib/igt_kms.h
> index 09c08aa..91fa206 100644
> --- a/lib/igt_kms.h
> +++ b/lib/igt_kms.h
> @@ -278,6 +278,18 @@ void igt_wait_for_vblank(int drm_fd, enum pipe pipe);
> for (int i__ = 0; (plane) = &(display)->pipes[(pipe)].planes[i__], \
>  i__ < (display)->pipes[(pipe)].n_planes; i__++)
>
> +/**
> + * get_first_connected_output:
> + * @display: Initialized igt_display_t type object
> + * @output: igt_output_t type object
> + *
> + * Returns: First valid (connected) output.
> + */
> +#define get_first_connected_output(display, output)\
> +   for (int i__ = 0;  i__ < (display)->n_outputs; i__++)   \
> +   if ((output = &(display)->outputs[i__]), output->valid) \
> +   break
> +
>  /*
>   * Can be used with igt_output_set_pipe() to mean we don't care about the 
> pipe
>   * that should drive this output
> --
> 2.4.3
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 00/13] Yet another FBC series, v3 part 1

[Zanoni, Paulo R]

Em Sex, 2015-11-13 às 15:49 +, Daniel Stone escreveu:
> Hi Paulo,
> 
> On 4 November 2015 at 19:10, Paulo Zanoni 
> wrote:
> > So Ville pointed a problem on patch 02/26 of the previous series,
> > and the nice
> > fix for that would make me rebase most of the subsequent patches.
> > In order to
> > avoid blocking the other patches on the review of patch 02 and in
> > order to avoid
> > having to rebase everything again and again during this I decided
> > to change the
> > order of the patches on the series and try to get a smaller chunk
> > of patches
> > merged before moving on to the others.
> > 
> > These first 13 patches are somewhat trivial and are mostly just
> > moving code
> > around, with only one or two simple bug fixes. If you wonder why
> > some of these
> > changes are needed, please go check the complete series (the short
> > answer is:
> > most of the changes are needed for the new model with
> > enable/disable +
> > activate/deactivate).
> > 
> > After all these patches are merged I'll resend the rest.
> 
> This series is missing 01/26 of your previous series (make
> no_fbc_reason a string).

It was already merged when I resent:

http://cgit.freedesktop.org/drm-intel/commit/?id=bf6189c6f062b5cd6ca0d4
6754e4c3064643f48c


> 
> Cheers,
> Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 9/9] drm/i915: Give meaningful names to all the planes

[ville . syrjala]

From: Ville Syrjälä 

Let's name our planes in a way that makes sense wrt. the spec:
- skl+ -> "plane 1A", "plane 2A", "plane 1C", "cursor A" etc.
- g4x+ -> "primary A", "primary B", "sprite A", "cursor C" etc.
- pre-g4x -> "plane A", "cursor B" etc.

v2: Rebase on top of the fixed/cleaned error paths
Use a local 'name' variable to make things easier
v3: Pass the name as a function argument to drm_universal_plane_init() (Jani)

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 20 ++--
 drivers/gpu/drm/i915/intel_sprite.c  | 11 ++-
 2 files changed, 28 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index de1c5fdf..d7c8a0f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13804,6 +13804,7 @@ static struct drm_plane 
*intel_primary_plane_create(struct drm_device *dev,
 {
struct intel_plane *primary = NULL;
struct intel_plane_state *state = NULL;
+   char name[16];
const uint32_t *intel_primary_formats;
unsigned int num_formats;
int ret;
@@ -13832,6 +13833,17 @@ static struct drm_plane 
*intel_primary_plane_create(struct drm_device *dev,
if (HAS_FBC(dev) && INTEL_INFO(dev)->gen < 4)
primary->plane = !pipe;
 
+   if (INTEL_INFO(dev)->gen >= 9)
+   ret = snprintf(name, sizeof(name), "plane 1%c",
+  pipe_name(pipe));
+   else if (INTEL_INFO(dev)->gen >= 5 || IS_G4X(dev))
+   ret = snprintf(name, sizeof(name), "primary %c",
+  pipe_name(pipe));
+   else
+   ret = snprintf(name, sizeof(name), "plane %c",
+  plane_name(primary->plane));
+   WARN_ON(ret >= sizeof(name));
+
if (INTEL_INFO(dev)->gen >= 9) {
intel_primary_formats = skl_primary_formats;
num_formats = ARRAY_SIZE(skl_primary_formats);
@@ -13846,7 +13858,7 @@ static struct drm_plane 
*intel_primary_plane_create(struct drm_device *dev,
ret = drm_universal_plane_init(dev, >base, 0,
   _plane_funcs,
   intel_primary_formats, num_formats,
-  DRM_PLANE_TYPE_PRIMARY, "");
+  DRM_PLANE_TYPE_PRIMARY, name);
if (ret)
goto fail;
 
@@ -13968,6 +13980,7 @@ static struct drm_plane 
*intel_cursor_plane_create(struct drm_device *dev,
 {
struct intel_plane *cursor = NULL;
struct intel_plane_state *state = NULL;
+   char name[16];
int ret;
 
cursor = kzalloc(sizeof(*cursor), GFP_KERNEL);
@@ -13988,11 +14001,14 @@ static struct drm_plane 
*intel_cursor_plane_create(struct drm_device *dev,
cursor->commit_plane = intel_commit_cursor_plane;
cursor->disable_plane = intel_disable_cursor_plane;
 
+   ret = snprintf(name, sizeof(name), "cursor %c", pipe_name(pipe));
+   WARN_ON(ret >= sizeof(name));
+
ret = drm_universal_plane_init(dev, >base, 0,
   _plane_funcs,
   intel_cursor_formats,
   ARRAY_SIZE(intel_cursor_formats),
-  DRM_PLANE_TYPE_CURSOR, "");
+  DRM_PLANE_TYPE_CURSOR, name);
if (ret)
goto fail;
 
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index aa60970..dc2acba 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1040,6 +1040,7 @@ intel_plane_init(struct drm_device *dev, enum pipe pipe, 
int plane)
 {
struct intel_plane *intel_plane = NULL;
struct intel_plane_state *state = NULL;
+   char name[16];
unsigned long possible_crtcs;
const uint32_t *plane_formats;
int num_plane_formats;
@@ -1123,12 +1124,20 @@ intel_plane_init(struct drm_device *dev, enum pipe 
pipe, int plane)
intel_plane->check_plane = intel_check_sprite_plane;
intel_plane->commit_plane = intel_commit_sprite_plane;
 
+   if (INTEL_INFO(dev)->gen >= 9)
+   ret = snprintf(name, sizeof(name), "plane %d%c",
+  plane + 2, pipe_name(pipe));
+   else
+   ret = snprintf(name, sizeof(name), "sprite %c",
+  sprite_name(pipe, plane));
+   WARN_ON(ret >= sizeof(name));
+
possible_crtcs = (1 << pipe);
 
ret = drm_universal_plane_init(dev, _plane->base, possible_crtcs,
   _plane_funcs,
   plane_formats, num_plane_formats,
-  DRM_PLANE_TYPE_OVERLAY, "");
+ 

[Intel-gfx] [PATCH igt 01/10] lib/igt_fb: fix fb->size when provided by the user

[Paulo Zanoni]

I want to have a little more control over the size of the buffers in
kms_frontbuffer_tracking, so I decided to start calling
igt_create_fb_with_bo_size() instead of igt_create_fb(). The problem
is that create_bo_for_fb() returns its own calculated size as size_ret
instead of the actual used size.

So we fix this by returning the actual size, the one used in
gem_create instead of the calculated size that's not used anywhere.

Signed-off-by: Paulo Zanoni 
---
 lib/igt_fb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/igt_fb.c b/lib/igt_fb.c
index 13a6a34..c70fb2c 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -116,7 +116,7 @@ static int create_bo_for_fb(int fd, int width, int height, 
int bpp,
ret = __gem_set_tiling(fd, gem_handle, I915_TILING_X, stride);
 
*stride_ret = stride;
-   *size_ret = size;
+   *size_ret = bo_size;
*gem_handle_ret = gem_handle;
 
return ret;
-- 
2.6.2

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

[Intel-gfx] [PATCH igt 06/10] kms_frontbuffer_tracking: do page flips using the planes API

[Paulo Zanoni]

Add a new FLIP_PLANES enum so we can do "page flips" using it too. The
goal is to exercise the fast modeset paths on the Kernel.

Signed-off-by: Paulo Zanoni 
---
 tests/kms_frontbuffer_tracking.c | 36 
 1 file changed, 36 insertions(+)

diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index 74acc73..994bb4a 100644
--- a/tests/kms_frontbuffer_tracking.c
+++ b/tests/kms_frontbuffer_tracking.c
@@ -122,6 +122,7 @@ enum flip_type {
FLIP_PAGEFLIP,
FLIP_PAGEFLIP_EVENT,
FLIP_MODESET,
+   FLIP_PLANES,
 };
 
 enum color {
@@ -2194,6 +2195,31 @@ static void wait_flip_event(void)
}
 }
 
+static void set_prim_plane_for_params(struct modeset_params *params)
+{
+   int rc, i, crtc_index = -1;
+   uint32_t plane_id = 0;
+
+   for (i = 0; i < drm.res->count_crtcs; i++)
+   if (drm.res->crtcs[i] == params->crtc_id)
+   crtc_index = i;
+   igt_assert(crtc_index >= 0);
+
+   for (i = 0; i < drm.plane_res->count_planes; i++)
+   if ((drm.planes[i]->possible_crtcs & (1 << crtc_index)) &&
+   drm.plane_types[i] == DRM_PLANE_TYPE_PRIMARY)
+   plane_id = drm.planes[i]->plane_id;
+   igt_assert(plane_id);
+
+   rc = drmModeSetPlane(drm.fd, plane_id, params->crtc_id,
+params->fb.fb->fb_id, 0, 0, 0,
+params->mode->hdisplay,
+params->mode->vdisplay,
+params->fb.x << 16, params->fb.y << 16,
+params->fb.w << 16, params->fb.h << 16);
+   igt_assert(rc == 0);
+}
+
 static void page_flip_for_params(struct modeset_params *params,
 enum flip_type type)
 {
@@ -2215,6 +2241,9 @@ static void page_flip_for_params(struct modeset_params 
*params,
case FLIP_MODESET:
set_mode_for_params(params);
break;
+   case FLIP_PLANES:
+   set_prim_plane_for_params(params);
+   break;
default:
igt_assert(false);
}
@@ -3184,6 +3213,13 @@ int main(int argc, char *argv[])
  igt_draw_get_method_name(t.method))
flip_subtest(, FLIP_MODESET);
 
+   igt_subtest_f("%s-%s-%s-%s-plflip-%s",
+ feature_str(t.feature),
+ pipes_str(t.pipes),
+ screen_str(t.screen),
+ fbs_str(t.fbs),
+ igt_draw_get_method_name(t.method))
+   flip_subtest(, FLIP_PLANES);
TEST_MODE_ITER_END
 
TEST_MODE_ITER_BEGIN(t)
-- 
2.6.2

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

[Intel-gfx] [PATCH igt 00/10] igt_fb buffer sizes + kms_frontbuffer_tracking

[Paulo Zanoni]

Hello

I've been carrying some local IGT patches that reduced the size of buffers
created by igt_create_fb() so they would fit the stolen memory, but when I
decided to test the tree without them, I concluded the lack of sane sizes was
even causing test failures. So here's my attempt to fix this. This series alone
should help reducing the number of kms_frontbuffer_tracking failures seen by QA.

The last few patches make the FBC tests a little harder. They are all based on
the feedback I got from the last patches I sent.

Thanks,
Paulo

Paulo Zanoni (10):
  lib/igt_fb: fix fb->size when provided by the user
  lib/igt_fb: fix igt_create_fb_with_bo_size() documentation
  lib/igt_fb: fix open-coded ALIGN()
  lib/igt_fb: also pass the stride to igt_create_fb_with_bo_size()
  kms_frontbuffer_tracking: set our own size for the FBs we create
  kms_frontbuffer_tracking: do page flips using the planes API
  kms_frontbuffer_tracking: move flip_type to struct test_mode
  kms_frontbuffer_tracking: expand badstride and stridechange
  kms_frontbuffer_tracking: assert the stride changes at stridechange()
  kms_frontbuffer_tracking: add tilingchange subtest

 lib/igt_fb.c |  31 +++---
 lib/igt_fb.h |   3 +-
 tests/kms_flip.c |   2 +-
 tests/kms_frontbuffer_tracking.c | 220 ---
 4 files changed, 204 insertions(+), 52 deletions(-)

-- 
2.6.2

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

[Intel-gfx] [PATCH igt 10/10] kms_frontbuffer_tracking: add tilingchange subtest

[Paulo Zanoni]

During the review of a recent FBC patch, Ville pointed a problem that
happens when we use the page flip IOCTL to switch between buffers that
have different tiling formats. This test should catch the problem
introduced by that patch - which was not merged, by the way, so the
test should be passing.

Signed-off-by: Paulo Zanoni 
---
 tests/kms_frontbuffer_tracking.c | 48 
 1 file changed, 48 insertions(+)

diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index 5f6f3f1..63a2a0d 100644
--- a/tests/kms_frontbuffer_tracking.c
+++ b/tests/kms_frontbuffer_tracking.c
@@ -3006,6 +3006,51 @@ static void stridechange_subtest(const struct test_mode 
*t)
igt_remove_fb(drm.fd, _fb);
 }
 
+/**
+ * tilingchange - alternate between tiled and untiled in multiple ways
+ *
+ * METHOD
+ *   This test alternates between tiled and untiled frontbuffers of the same
+ *   size and format through multiple different APIs: the page flip IOCTL,
+ *   normal modesets and the plane APIs.
+ *
+ * EXPECTED RESULTS
+ *   FBC gets properly disabled for the untiled FB and reenabled for the
+ *   tiled FB.
+ *
+ * FAILURES
+ *   Bad Kernels may somehow leave FBC enabled, which can cause FIFO underruns
+ *   that lead to CRC assertion failures.
+ */
+static void tilingchange_subtest(const struct test_mode *t)
+{
+   struct igt_fb new_fb, *old_fb;
+   struct modeset_params *params = pick_params(t);
+   enum flip_type flip_type;
+
+   prepare_subtest(t, NULL);
+
+   old_fb = params->fb.fb;
+
+   create_fb(t->format, params->fb.fb->width, params->fb.fb->height,
+ LOCAL_DRM_FORMAT_MOD_NONE, t->plane, _fb);
+   fill_fb(_fb, COLOR_PRIM_BG);
+
+   for (flip_type = 0; flip_type < FLIP_COUNT; flip_type++) {
+   igt_debug("Flip type: %d\n", flip_type);
+
+   /* Set a buffer with no tiling. */
+   params->fb.fb = _fb;
+   page_flip_for_params(params, flip_type);
+   do_assertions(ASSERT_FBC_DISABLED);
+
+   /* Put FBC back in a working state. */
+   params->fb.fb = old_fb;
+   page_flip_for_params(params, flip_type);
+   do_assertions(0);
+   }
+}
+
 static int opt_handler(int option, int option_index, void *data)
 {
switch (option) {
@@ -3395,6 +3440,9 @@ int main(int argc, char *argv[])
 
igt_subtest_f("%s-stridechange", feature_str(t.feature))
stridechange_subtest();
+
+   igt_subtest_f("%s-tilingchange", feature_str(t.feature))
+   tilingchange_subtest();
}
 
if (t.feature & FEATURE_PSR)
-- 
2.6.2

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

[Intel-gfx] [PATCH igt 05/10] kms_frontbuffer_tracking: set our own size for the FBs we create

[Paulo Zanoni]

If we just call igt_create_fb(), the automatic size calculated by
create_bo_for_fb() may be way too big for the FBC CFB, and this will
result in SKIPs due to not enough stolen memroy. So in order to avoid
that, let's compute our own sizes.

Besides this, I want to make sure that both the untiled and X tiled -
and, in the future, Y tiled - buffers have the same size for the same
width/height/format. This will allow better control over the failure
paths exercised by our tests: when we try to flip from tiled to
untiled, we'll be sure that the change in buffer size does not cause
the wrong error path to be executed.

Signed-off-by: Paulo Zanoni 
---
 tests/kms_frontbuffer_tracking.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index ee72532..74acc73 100644
--- a/tests/kms_frontbuffer_tracking.c
+++ b/tests/kms_frontbuffer_tracking.c
@@ -479,6 +479,7 @@ static void create_fb(enum pixel_format pformat, int width, 
int height,
  uint64_t tiling, int plane, struct igt_fb *fb)
 {
uint32_t format;
+   unsigned int buf_size, pixel_size, stride;
 
switch (pformat) {
case FORMAT_RGB888:
@@ -508,7 +509,21 @@ static void create_fb(enum pixel_format pformat, int 
width, int height,
igt_assert(false);
}
 
-   igt_create_fb(drm.fd, width, height, format, tiling, fb);
+   /* We want all frontbuffers with the same width/weight/format to have
+* the same size regardless of tiling. Besides, the automatic size from
+* intel_create_fb() is too big and may lead to many SKIPs due to not
+* enough stolen memory. */
+   pixel_size = igt_drm_format_to_bpp(format) / 8;
+   if (plane == PLANE_CUR) {
+   stride = ALIGN(width * pixel_size, 64);
+   buf_size = stride * height;
+   } else {
+   stride = ALIGN(width * pixel_size, 512);
+   buf_size = stride * ALIGN(height, 32);
+   }
+
+   igt_create_fb_with_bo_size(drm.fd, width, height, format, tiling, fb,
+  buf_size, stride);
 }
 
 static uint32_t pick_color(struct igt_fb *fb, enum color ecolor)
-- 
2.6.2

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

[Intel-gfx] [PATCH igt 03/10] lib/igt_fb: fix open-coded ALIGN()

[Paulo Zanoni]

Maybe this will help someone's life in the future.

Signed-off-by: Paulo Zanoni 
---
 lib/igt_fb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/igt_fb.c b/lib/igt_fb.c
index 088bc0d..2818c9f 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -104,7 +104,7 @@ static int create_bo_for_fb(int fd, int width, int height, 
int bpp,
;
} else {
/* Scan-out has a 64 byte alignment restriction */
-   stride = (width * (bpp / 8) + 63) & ~63;
+   stride = ALIGN(width * (bpp / 8), 64);
size = stride * height;
}
 
-- 
2.6.2

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

[Intel-gfx] [PATCH igt 04/10] lib/igt_fb: also pass the stride to igt_create_fb_with_bo_size()

[Paulo Zanoni]

If the caller is going to specify a custom size, it's likely that he
will also specify a custom stride. The automatic stride picked by
create_bo_for_fb() is too huge for tiled buffers, so if the caller
wants smaller buffers, then he'll need a smaller stride too, otherwise
the Kernel will reject the addfb IOCTL due to stride * height being
bigger than the size.

I want to make tests/kms_frontbuffer_tracking use
igt_create_fb_with_bo_size() so I can provide smaller buffers that
will fit into the CFB. I'm also planning to make all frontbuffers with
the same width/height/format have the same stride and size regardless
of tiling method so I can exercise specific code paths.

Signed-off-by: Paulo Zanoni 
---
 lib/igt_fb.c | 25 -
 lib/igt_fb.h |  3 ++-
 tests/kms_flip.c |  2 +-
 3 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/lib/igt_fb.c b/lib/igt_fb.c
index 2818c9f..3ea9915 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -76,9 +76,8 @@ static struct format_desc_struct {
 /* helpers to create nice-looking framebuffers */
 static int create_bo_for_fb(int fd, int width, int height, int bpp,
uint64_t tiling, unsigned bo_size,
-   uint32_t *gem_handle_ret,
-   unsigned *size_ret,
-   unsigned *stride_ret)
+   unsigned bo_stride, uint32_t *gem_handle_ret,
+   unsigned *size_ret, unsigned *stride_ret)
 {
uint32_t gem_handle;
int size, ret = 0;
@@ -110,12 +109,16 @@ static int create_bo_for_fb(int fd, int width, int 
height, int bpp,
 
if (bo_size == 0)
bo_size = size;
+   if (bo_stride == 0)
+   bo_stride = stride;
+
gem_handle = gem_create(fd, bo_size);
 
if (tiling == LOCAL_I915_FORMAT_MOD_X_TILED)
-   ret = __gem_set_tiling(fd, gem_handle, I915_TILING_X, stride);
+   ret = __gem_set_tiling(fd, gem_handle, I915_TILING_X,
+  bo_stride);
 
-   *stride_ret = stride;
+   *stride_ret = bo_stride;
*size_ret = bo_size;
*gem_handle_ret = gem_handle;
 
@@ -401,6 +404,7 @@ void igt_paint_image(cairo_t *cr, const char *filename,
  * @tiling: tiling layout of the framebuffer (as framebuffer modifier)
  * @fb: pointer to an #igt_fb structure
  * @bo_size: size of the backing bo (0 for automatic size)
+ * @bo_stride: stride of the backing bo (0 for automatic stride)
  *
  * This function allocates a gem buffer object suitable to back a framebuffer
  * with the requested properties and then wraps it up in a drm framebuffer
@@ -415,7 +419,8 @@ void igt_paint_image(cairo_t *cr, const char *filename,
 unsigned int
 igt_create_fb_with_bo_size(int fd, int width, int height,
   uint32_t format, uint64_t tiling,
-  struct igt_fb *fb, unsigned bo_size)
+  struct igt_fb *fb, unsigned bo_size,
+  unsigned bo_stride)
 {
uint32_t fb_id;
int bpp;
@@ -427,7 +432,8 @@ igt_create_fb_with_bo_size(int fd, int width, int height,
igt_debug("%s(width=%d, height=%d, format=0x%x [bpp=%d], 
tiling=0x%"PRIx64", size=%d)\n",
  __func__, width, height, format, bpp, tiling, bo_size);
do_or_die(create_bo_for_fb(fd, width, height, bpp, tiling, bo_size,
-  >gem_handle, >size, >stride));
+  bo_stride, >gem_handle, >size,
+  >stride));
 
igt_debug("%s(handle=%d, pitch=%d)\n",
  __func__, fb->gem_handle, fb->stride);
@@ -485,7 +491,8 @@ igt_create_fb_with_bo_size(int fd, int width, int height,
 unsigned int igt_create_fb(int fd, int width, int height, uint32_t format,
   uint64_t tiling, struct igt_fb *fb)
 {
-   return igt_create_fb_with_bo_size(fd, width, height, format, tiling, 
fb, 0);
+   return igt_create_fb_with_bo_size(fd, width, height, format, tiling, fb,
+ 0, 0);
 }
 
 /**
@@ -714,7 +721,7 @@ static void create_cairo_surface__blit(int fd, struct 
igt_fb *fb)
 */
bpp = igt_drm_format_to_bpp(fb->drm_format);
ret = create_bo_for_fb(fd, fb->width, fb->height, bpp,
-   LOCAL_DRM_FORMAT_MOD_NONE, 0,
+   LOCAL_DRM_FORMAT_MOD_NONE, 0, 0,
>linear.handle,
>linear.size,
>linear.stride);
diff --git a/lib/igt_fb.h b/lib/igt_fb.h
index a07acd2..37892b5 100644
--- a/lib/igt_fb.h
+++ b/lib/igt_fb.h
@@ -72,7 +72,8 @@ enum igt_text_align {
 unsigned int
 igt_create_fb_with_bo_size(int fd, int width, int height,
   uint32_t format, uint64_t tiling,
- 

[Intel-gfx] [PATCH igt 08/10] kms_frontbuffer_tracking: expand badstride and stridechange

[Paulo Zanoni]

Make those subtests try to change the stride using multiple APIs so we
can catch errors that affect full modesets, fast modesets and page
flips.

Signed-off-by: Paulo Zanoni 
---
 tests/kms_frontbuffer_tracking.c | 52 
 1 file changed, 48 insertions(+), 4 deletions(-)

diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index 25e6afd..436f1ec 100644
--- a/tests/kms_frontbuffer_tracking.c
+++ b/tests/kms_frontbuffer_tracking.c
@@ -2898,24 +2898,47 @@ static void try_invalid_strides(void)
  */
 static void badstride_subtest(const struct test_mode *t)
 {
-   struct igt_fb wide_fb;
+   struct igt_fb wide_fb, *old_fb;
struct modeset_params *params = pick_params(t);
+   int rc;
 
try_invalid_strides();
 
prepare_subtest(t, NULL);
 
+   old_fb = params->fb.fb;
+
create_fb(t->format, params->fb.fb->width + 4096, params->fb.fb->height,
  LOCAL_I915_FORMAT_MOD_X_TILED, t->plane, _fb);
igt_assert(wide_fb.stride > 16384);
 
fill_fb(_fb, COLOR_PRIM_BG);
 
+   /* Try a simple modeset with the new fb. */
params->fb.fb = _fb;
set_mode_for_params(params);
+   do_assertions(ASSERT_FBC_DISABLED);
+
+   /* Go back to the old fb so FBC works again. */
+   params->fb.fb = old_fb;
+   set_mode_for_params(params);
+   do_assertions(0);
 
+   /* We're doing the equivalent of a modeset, but with the planes API. */
+   params->fb.fb = _fb;
+   set_prim_plane_for_params(params);
do_assertions(ASSERT_FBC_DISABLED);
 
+   params->fb.fb = old_fb;
+   set_mode_for_params(params);
+   do_assertions(0);
+
+   /* We can't use the page flip IOCTL to flip to a buffer with a different
+* stride. */
+   rc = drmModePageFlip(drm.fd, params->crtc_id, wide_fb.fb_id, 0, NULL);
+   igt_assert(rc == -EINVAL);
+   do_assertions(0);
+
igt_remove_fb(drm.fd, _fb);
 }
 
@@ -2941,22 +2964,43 @@ static void badstride_subtest(const struct test_mode *t)
  */
 static void stridechange_subtest(const struct test_mode *t)
 {
-   struct igt_fb new_fb;
+   struct igt_fb new_fb, *old_fb;
struct modeset_params *params = pick_params(t);
+   int rc;
 
prepare_subtest(t, NULL);
 
+   old_fb = params->fb.fb;
+
create_fb(t->format, params->fb.fb->width + 512, params->fb.fb->height,
  LOCAL_I915_FORMAT_MOD_X_TILED, t->plane, _fb);
fill_fb(_fb, COLOR_PRIM_BG);
 
+   /* We can't assert that FBC will be enabled since there may not be
+* enough space for the CFB, but we can check the CRC. */
params->fb.fb = _fb;
set_mode_for_params(params);
+   do_assertions(DONT_ASSERT_FEATURE_STATUS);
 
-   /* We can't assert that FBC will be enabled since there may not be
-* enough space for the CFB, but we can check the CRC. */
+   /* Go back to the fb that can have FBC. */
+   params->fb.fb = old_fb;
+   set_mode_for_params(params);
+   do_assertions(0);
+
+   /* This operation is the same as above, but with the planes API. */
+   params->fb.fb = _fb;
+   set_prim_plane_for_params(params);
do_assertions(DONT_ASSERT_FEATURE_STATUS);
 
+   params->fb.fb = old_fb;
+   set_prim_plane_for_params(params);
+   do_assertions(0);
+
+   /* We just can't page flip with a new stride. */
+   rc = drmModePageFlip(drm.fd, params->crtc_id, new_fb.fb_id, 0, NULL);
+   igt_assert(rc == -EINVAL);
+   do_assertions(0);
+
igt_remove_fb(drm.fd, _fb);
 }
 
-- 
2.6.2

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

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Support for pread/pwrite from/to non shmem backed objects

[Tvrtko Ursulin]

On 11/11/15 10:36, ankitprasad.r.sha...@intel.com wrote:

From: Ankitprasad Sharma 

This patch adds support for extending the pread/pwrite functionality
for objects not backed by shmem. The access will be made through
gtt interface. This will cover objects backed by stolen memory as well
as other non-shmem backed objects.

v2: Drop locks around slow_user_access, prefault the pages before
access (Chris)

v3: Rebased to the latest drm-intel-nightly (Ankit)

v4: Moved page base & offset calculations outside the copy loop,
corrected data types for size and offset variables, corrected if-else
braces format (Tvrtko/kerneldocs)

v5: Enabled pread/pwrite for all non-shmem backed objects including
without tiling restrictions (Ankit)

v6: Using pwrite_fast for non-shmem backed objects as well (Chris)

v7: Updated commit message (Tvrtko)


Since v6 you have also renamed i915_gem_gtt_read to i915_gem_gtt_copy 
and added the pwrite slow path so the commit should say that.




Testcase: igt/gem_stolen

Signed-off-by: Ankitprasad Sharma 
---
  drivers/gpu/drm/i915/i915_gem.c | 146 +---
  1 file changed, 122 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2d8c9e0..e0b9502 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -614,6 +614,99 @@ shmem_pread_slow(struct page *page, int shmem_page_offset, 
int page_length,
return ret ? - EFAULT : 0;
  }

+static inline uint64_t
+slow_user_access(struct io_mapping *mapping,
+uint64_t page_base, int page_offset,
+char __user *user_data,
+int length, bool pwrite)
+{
+   void __iomem *vaddr_inatomic;
+   void *vaddr;
+   uint64_t unwritten;
+
+   vaddr_inatomic = io_mapping_map_wc(mapping, page_base);
+   /* We can use the cpu mem copy function because this is X86. */
+   vaddr = (void __force *)vaddr_inatomic + page_offset;
+   if (pwrite)
+   unwritten = __copy_from_user(vaddr, user_data, length);
+   else
+   unwritten = __copy_to_user(user_data, vaddr, length);
+
+   io_mapping_unmap(vaddr_inatomic);
+   return unwritten;
+}
+
+static int
+i915_gem_gtt_copy(struct drm_device *dev,
+  struct drm_i915_gem_object *obj, uint64_t size,
+  uint64_t data_offset, uint64_t data_ptr)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   char __user *user_data;
+   uint64_t remain;
+   uint64_t offset, page_base;
+   int page_offset, page_length, ret = 0;
+
+   ret = i915_gem_obj_ggtt_pin(obj, 0, PIN_MAPPABLE);
+   if (ret)
+   goto out;
+
+   ret = i915_gem_object_set_to_gtt_domain(obj, false);
+   if (ret)
+   goto out_unpin;
+
+   ret = i915_gem_object_put_fence(obj);
+   if (ret)
+   goto out_unpin;
+
+   user_data = to_user_ptr(data_ptr);
+   remain = size;
+   offset = i915_gem_obj_ggtt_offset(obj) + data_offset;
+
+   mutex_unlock(>struct_mutex);
+   if (likely(!i915.prefault_disable))
+   ret = fault_in_multipages_writeable(user_data, remain);
+
+   /*
+* page_offset = offset within page
+* page_base = page offset within aperture
+*/
+   page_offset = offset_in_page(offset);
+   page_base = offset & PAGE_MASK;
+
+   while (remain > 0) {
+   /* page_length = bytes to copy for this page */
+   page_length = remain;
+   if ((page_offset + remain) > PAGE_SIZE)
+   page_length = PAGE_SIZE - page_offset;
+
+   /* This is a slow read/write as it tries to read from
+* and write to user memory which may result into page
+* faults
+*/
+   ret = slow_user_access(dev_priv->gtt.mappable, page_base,
+  page_offset, user_data,
+  page_length, false);
+
+   if (ret) {
+   ret = -EFAULT;
+   break;
+   }
+
+   remain -= page_length;
+   user_data += page_length;
+   page_base += page_length;
+   page_offset = 0;
+   }
+
+   mutex_lock(>struct_mutex);
+
+out_unpin:
+   i915_gem_object_ggtt_unpin(obj);
+out:
+   return ret;
+}
+
  static int
  i915_gem_shmem_pread(struct drm_device *dev,
 struct drm_i915_gem_object *obj,
@@ -737,17 +830,14 @@ i915_gem_pread_ioctl(struct drm_device *dev, void *data,
goto out;
}

-   /* prime objects have no backing filp to GEM pread/pwrite
-* pages from.
-*/
-   if (!obj->base.filp) {
-   ret = -EINVAL;
-   goto out;
-   }
-

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Add support for mapping an object page by page

[Tvrtko Ursulin]

Hi,

On 09/11/15 10:56, ankitprasad.r.sha...@intel.com wrote:

From: Chris Wilson 

Introduced a new vm specfic callback insert_page() to program a single pte in
ggtt or ppgtt. This allows us to map a single page in to the mappable aperture
space. This can be iterated over to access the whole object by using space as
meagre as page size.

Signed-off-by: Chris Wilson 
Signed-off-by: Ankitprasad Sharma 
---
  drivers/char/agp/intel-gtt.c|  9 +++
  drivers/gpu/drm/i915/i915_gem_gtt.c | 49 +
  drivers/gpu/drm/i915/i915_gem_gtt.h |  5 
  include/drm/intel-gtt.h |  3 +++
  4 files changed, 66 insertions(+)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 1341a94..7c68576 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -838,6 +838,15 @@ static bool i830_check_flags(unsigned int flags)
return false;
  }

+void intel_gtt_insert_page(dma_addr_t addr,
+  unsigned int pg,
+  unsigned int flags)
+{
+   intel_private.driver->write_entry(addr, pg, flags);
+   wmb();
+}
+EXPORT_SYMBOL(intel_gtt_insert_page);
+
  void intel_gtt_insert_sg_entries(struct sg_table *st,
 unsigned int pg_start,
 unsigned int flags)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 016739e..9fd1f857 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2345,6 +2345,23 @@ static void gen8_set_pte(void __iomem *addr, gen8_pte_t 
pte)
  #endif
  }

+static void gen8_ggtt_insert_page(struct i915_address_space *vm,
+ dma_addr_t addr,
+ uint64_t offset,
+ enum i915_cache_level level,
+ u32 unused)
+{


I am not sure about the interface consistency. insert_entries works on a 
sg and this would now need a DMA address which is encapsulated in the 
former.


How about extending insert_pages to take a page_offset and size in 
pages? The latter could default to obj size if zero.



+   struct drm_i915_private *dev_priv = to_i915(vm->dev);
+   gen8_pte_t __iomem *pte =
+   (gen8_pte_t __iomem *)dev_priv->gtt.gsm +
+   (offset >> PAGE_SHIFT);
+
+   gen8_set_pte(pte, gen8_pte_encode(addr, level, true));
+   wmb();
+
+   I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);


gen8_ggtt_insert_entries doesn't do the wmb() but does a posting read on 
GFX_FLSH_CNTL_GEN6. Why is that difference?


Regards,

Tvrtko

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

Re: [Intel-gfx] [PATCH maintainer-tools] dim: Remove git commit --amend from dim_apply

[Tvrtko Ursulin]

On 13/11/15 14:40, Ander Conselvan De Oliveira wrote:

On Fri, 2015-11-13 at 12:31 +, Tvrtko Ursulin wrote:

On 13/11/15 12:16, Chris Wilson wrote:

On Fri, Nov 13, 2015 at 02:05:39PM +0200, Ander Conselvan de Oliveira wrote:

Calling git --amend invokes the editor, which will not run if it relies
on the terminal for input. So don't do that from dim_apply.

Signed-off-by: Ander Conselvan de Oliveira <
ander.conselvan.de.olive...@intel.com>


Presumable the ammend is there for a good reason and removing it keeps
the state dirty? So maybe --amend --no-edit?


In either case can also consider "test -t 0" which is like isatty(0).


I think that will always evaluate to false since you are supposed to cat the
mbox to dim apply.


Question is then how does it work for Daniel. :)

Regards,

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

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Dump pipe config after initial FB is reconstructed

[Ville Syrjälä]

On Thu, Nov 12, 2015 at 04:31:58PM -0800, Matt Roper wrote:
> We dump during HW state readout, but that's too early to reflect how the
> primary plane is actually configured.

Hmm. Would be nice if we could read out everything at the same place,
and then saniitize later.

And maybe we could introduce some kind of NOP FB for planes where we
haven't yet reconstructed the BIOS FB (or are unable to do so). That
way the plane sanitize could be exactly like a normal modeset?

> 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index d994f52..9fa041c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15118,6 +15118,9 @@ void intel_modeset_init(struct drm_device *dev)
>* just get the first one.
>*/
>   intel_find_initial_plane_obj(crtc, _config);
> +
> + intel_dump_pipe_config(crtc, crtc->config,
> +"[state after init fb reconstruction]");
>   }
>  }
>  
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Intel-gfx] [PATCH igt 02/10] lib/igt_fb: fix igt_create_fb_with_bo_size() documentation

[Paulo Zanoni]

If we pass zero as the bo_size we won't get the minimum needed size,
we'll just get a size that works. The size is decided by
create_bo_for_fb(). The selected size is really not minimal for tiled
objects.

Signed-off-by: Paulo Zanoni 
---
 lib/igt_fb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/igt_fb.c b/lib/igt_fb.c
index c70fb2c..088bc0d 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -400,7 +400,7 @@ void igt_paint_image(cairo_t *cr, const char *filename,
  * @format: drm fourcc pixel format code
  * @tiling: tiling layout of the framebuffer (as framebuffer modifier)
  * @fb: pointer to an #igt_fb structure
- * @bo_size: size of the backing bo (0 for minimum needed size)
+ * @bo_size: size of the backing bo (0 for automatic size)
  *
  * This function allocates a gem buffer object suitable to back a framebuffer
  * with the requested properties and then wraps it up in a drm framebuffer
-- 
2.6.2

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

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Delay first PSR activation.

[Vivi, Rodrigo]

On Fri, 2015-11-13 at 09:09 +, R, Durgadoss wrote:
> > -Original Message-
> > From: Vivi, Rodrigo
> > Sent: Friday, November 13, 2015 3:08 AM
> > To: intel-gfx@lists.freedesktop.org; R, Durgadoss
> > Subject: Re: [Intel-gfx] [PATCH 1/4] drm/i915: Delay first PSR 
> > activation.
> > 
> > On Thu, 2015-11-12 at 13:50 +, R, Durgadoss wrote:
> > > Hi Rodrigo,
> > > 
> > > > -Original Message-
> > > > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org
> > > > ] On
> > > > Behalf Of Rodrigo Vivi
> > > > Sent: Thursday, November 12, 2015 1:07 AM
> > > > To: intel-gfx@lists.freedesktop.org
> > > > Cc: Vivi, Rodrigo
> > > > Subject: [Intel-gfx] [PATCH 1/4] drm/i915: Delay first PSR
> > > > activation.
> > > > 
> > > > When debuging the frozen screen caused by HW tracking with low
> > > > power state I noticed that if we keep moving the mouse non stop
> > > > you will miss the screen updates for a while. At least
> > > > until we stop moving the mouse for a small time and move again.
> > > > 
> > > > The actual enabling should happen immediately after
> > > > Display Port enabling sequence finished with links trained and
> > > > everything enabled. However we face many issues when enabling 
> > > > PSR
> > > > right after a modeset.
> > > > 
> > > > On VLV/CHV we face blank screens on this scenario and on HSW+
> > > > we face a recoverable frozen screen, at least until next
> > > > exit-activate sequence.
> > > > 
> > > > Another workaround for the same issue here would be to increase
> > > > re-enable idle time from 100 to 500 as we did for VLV/CHV.
> > > > However this patch workaround this issue in a better
> > > > way since it doesn't reduce PSR residency and also
> > > > allow us to reduce the delay time between re-enables at least
> > > > on VLV/CHV.
> > > > 
> > > > This is also important to make the sysfs toggle working 
> > > > properly.
> > > > 
> > > > Signed-off-by: Rodrigo Vivi 
> > > > ---
> > > > drivers/gpu/drm/i915/intel_psr.c | 18 --
> > > > 1 file changed, 16 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > > b/drivers/gpu/drm/i915/intel_psr.c
> > > > index 213581c..6b24c24 100644
> > > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > > @@ -427,6 +427,19 @@ void intel_psr_enable(struct intel_dp
> > > > *intel_dp)
> > > > vlv_psr_enable_source(intel_dp);
> > > > }
> > > > 
> > > > +   /*
> > > > +* FIXME: Activation should happen immediately since 
> > > > this
> > > > function
> > > > +* is just called after pipe is fully trained and 
> > > > enabled.
> > > > +* However on every platform we face issues when first
> > > > activation
> > > > +* follows a modeset so quickly.
> > > > +* - On VLV/CHV we get bank screen on first 
> > > > activation
> > > > +* - On HSW/BDW we get a recoverable frozen screen
> > > > until next
> > > > +*   exit-activate sequence.
> > > > +*/
> > > > +   if (INTEL_INFO(dev)->gen < 9)
> > > > +   schedule_delayed_work(_priv->psr.work,
> > > > +
> > > >  msecs_to_jiffies(intel_dp
> > > > ->panel_power_cycle_delay * 5));
> > > > +
> > > > dev_priv->psr.enabled = intel_dp;
> 
> Should we set this before scheduling the delayed work ?
> 
> > > > unlock:
> > > > mutex_unlock(_priv->psr.lock);
> > > > @@ -735,8 +748,9 @@ void intel_psr_flush(struct drm_device 
> > > > *dev,
> > > > }
> > > > 
> > > > if (!dev_priv->psr.active && !dev_priv
> > > > ->psr.busy_frontbuffer_bits)
> > > > -   schedule_delayed_work(_priv->psr.work,
> > > > -
> > > >  msecs_to_jiffies(delay_ms));
> > > > +   if (!work_busy(_priv->psr.work.work))
> > > > +   schedule_delayed_work(_priv
> > > > ->psr.work,
> > > > +
> > > >  msecs_to_jiffies(delay_ms));
> > > 
> > > Agree with the theory of the patch as such.. But, Is there any
> > > specific reason for
> > > the !work_busy() check here ?
> > > 
> > > I believe when the later work runs, it will anyway bail out in
> > > _activate
> > > function, if it sees PSR_ENABLE bit set already. So, is this 
> > > check
> > > just to
> > > prevent scheduling one more work item when there is one pending
> > > already ? (or it helps in something else also ?)
> > 
> > The !work_busy is to prevent that eventual _activate call reduce 
> > the
> > first activation time.
> 
> Yes, this is what I understood from the code. Just wanted to confirm 
> whether
> you meant the same.
> 
> The other thing I am thinking is:
> Inside intel_psr_enable() we call _activate() for DDI platforms & 
> gen>=9.
> For others, we schedule a work.
> 
> May be we should have only the worker thread do _activate() for every
> Platform .. I believe this would simplify 

Re: [Intel-gfx] [PATCH] drm/i915: Fix GT frequency rounding

[Ville Syrjälä]

On Fri, Nov 13, 2015 at 07:29:41PM +0200, Mika Kuoppala wrote:
> When we set and later readback a frequency value through
> sysfs interface, igt/pm_rpm assumes that we get same value back
> if it matches hw granularity.
> 
> On bxt we have found out that this is not always the case.
> Currently frequency - hw ratio - frequency conversions round down,
> with few exceptions on platforms that have more specific conversions.
> On bxt the supported range can be for example from 100Mhz to 650Mhz.
> Midpoint is then calculated by test to be 375 which pm_rps uses to find a
> closest hw supported frequency. That is 366 (ratio 22),
> which it then writes back. But as the rounding down kicks in,
> driver actually sets 350 instead of 366, as 366 is 2/3 below 22 * 50/3.
> 
> Fix this by rounding to closest instead of rounding down in
> freq-ratio-freq conversions.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92768
> Testcase: igt/pm_rps/basic-api
> Tested-by: Bob Paauwe 
> Cc: Bob Paauwe 
> Signed-off-by: Imre Deak 
> Signed-off-by: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 647c0ff..740623f 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -7139,7 +7139,8 @@ static int chv_freq_opcode(struct drm_i915_private 
> *dev_priv, int val)
>  int intel_gpu_freq(struct drm_i915_private *dev_priv, int val)
>  {
>   if (IS_GEN9(dev_priv->dev))
> - return (val * GT_FREQUENCY_MULTIPLIER) / GEN9_FREQ_SCALER;
> + return DIV_ROUND_CLOSEST(val * GT_FREQUENCY_MULTIPLIER,
> +  GEN9_FREQ_SCALER);
>   else if (IS_CHERRYVIEW(dev_priv->dev))
>   return chv_gpu_freq(dev_priv, val);
>   else if (IS_VALLEYVIEW(dev_priv->dev))
> @@ -7151,13 +7152,14 @@ int intel_gpu_freq(struct drm_i915_private *dev_priv, 
> int val)
>  int intel_freq_opcode(struct drm_i915_private *dev_priv, int val)
>  {
>   if (IS_GEN9(dev_priv->dev))
> - return (val * GEN9_FREQ_SCALER) / GT_FREQUENCY_MULTIPLIER;
> + return DIV_ROUND_CLOSEST(val * GEN9_FREQ_SCALER,
> +  GT_FREQUENCY_MULTIPLIER);
>   else if (IS_CHERRYVIEW(dev_priv->dev))
>   return chv_freq_opcode(dev_priv, val);
>   else if (IS_VALLEYVIEW(dev_priv->dev))
>   return byt_freq_opcode(dev_priv, val);
>   else
> - return val / GT_FREQUENCY_MULTIPLIER;
> + return DIV_ROUND_CLOSEST(val, GT_FREQUENCY_MULTIPLIER);

lgtm

Reviewed-by: Ville Syrjälä 

>  }
>  
>  struct request_boost {
> -- 
> 2.5.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [RFC] Docs: drm: Move KMS properties table out to source files

[Graham Whaley]

On Mon, 2015-09-28 at 11:33 -0600, Jonathan Corbet wrote:
> On Mon, 28 Sep 2015 10:36:59 +0100
> Graham Whaley  wrote:
> 
> > I've still not thought of a way of tweaking the kernel-doc and
> > pandoc
> > processing to work around this either, as they are done as
> > different
> > passes/phases that neither has knowledge about the others
> > requirements.
> > 
> > As it stands, I'm failing to find a method to break out the DRM
> > table
> > into markdown tables that I believe works, fundamentally due to
> > this
> > 'incompatibility' between the kernel-doc and pandoc_markdown
> > processing
> > phases around the highlight processing.
> 
> This sort of thing is why I'm increasingly nervous about this one-off
> mix
> of doc-generation tools we're putting together.  Sigh.

Hi Jon, all. Just to note, I've not forgotten about this. I was hoping
to bump into you at ELCE/LinuxCon Dublin to maybe chat over it Jon -
but I think you were not there. I see you did a talk on this topic at
the kernel summit though, and have read through your lwn.net article
and the string of replies.

> 
> One possibility might be to have kernel-doc understand some sort of
> table
> notation of its own and make it do the right thing.
> 
> Another might be to have kernel-doc format unconditionally to
> markdown
> (or ReST, or something) all the time, then have the secondary
> processor
> handle everything from there.  A bigger change, obviously.  Probably
> not
> something anybody wants to face, but we may reach a point where we
> need
> to consider having less than three independent formatting tools in
> the
> mix.  I *may* get a chance to mess with this idea in the next week or
> so,
> but no promises.
> 
The whole idea of moving this more towards some KISS philosophy rather
than further away is obviously appealing :-) I'm guessing you didn't
find any time yet?
I've been staring at the workflow of docproc and kernel-doc to try and
wrap my head better around exactly how it works at present.
Did you have thoughts on how moving kernel-doc to produce markdown all
the time would work in practice? Presumably we'd then have to put a
markdown->docbook processor between docproc and kernel-doc (be that
pandoc or something else). That may then solve the mixing of docbook
and markdown inside of kernel-doc that I saw with the highlighting
expansion.
I'll see if I can find some time to play with the idea - but please let
me know if that was not what you had in mind.

 Graham

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix crtc_y assignment in intel_find_initial_plane_obj()

[Jani Nikula]

On Fri, 13 Nov 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
>
> Let's set crtc_y to 0 instead of setting src_y twice.
>
> Multiple assignments in one statement is a good way to hide bugs.
> Please don't do that.
>
> Cc: Maarten Lankhorst 
> Fixes: be5651f2d581 ("drm/i915: Update missing properties in 
> find_initial_plane_obj")

Cc: sta...@vger.kernel.org # v4.3+

right?


> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index d7c8a0f..e3db46d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2640,11 +2640,13 @@ intel_find_initial_plane_obj(struct intel_crtc 
> *intel_crtc,
>   return;
>  
>  valid_fb:
> - plane_state->src_x = plane_state->src_y = 0;
> + plane_state->src_x = 0;
> + plane_state->src_y = 0;
>   plane_state->src_w = fb->width << 16;
>   plane_state->src_h = fb->height << 16;
>  
> - plane_state->crtc_x = plane_state->src_y = 0;
> + plane_state->crtc_x = 0;
> + plane_state->crtc_y = 0;
>   plane_state->crtc_w = fb->width;
>   plane_state->crtc_h = fb->height;

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

[Intel-gfx] [PATCH 05/12] drm/i915: introduce intel_fbc_{enable, disable}

[Paulo Zanoni]

The goal is to call FBC enable/disable only once per modeset, while
activate/deactivate/update will be called multiple times.

The enable() function will be responsible for deciding if a CRTC will
have FBC on it and then it will "lock" FBC on this CRTC: it won't be
possible to change FBC's CRTC until disable(). With this, all checks
and resource acquisition that only need to be done once per modeset
can be moved from update() to enable(). And then the update(),
activate() and deactivate() code will also get simpler since they
won't need to worry about the CRTC being changed.

The disable() function will do the reverse operation of enable(). One
of its features is that it should only be called while the pipe is
already off. This guarantees that FBC is stopped and nothing is
using the CFB.

With this, the activate() and deactivate() functions just start and
temporarily stop FBC. They are the ones touching the hardware enable
bit, so HW state reflects dev_priv->crtc.active.

The last function remaining is update(). A lot of times I thought
about renaming update() to activate() or try_to_activate() since it's
called when we want to activate FBC. The thing is that update() may
not only decide to activate FBC, but also deactivate or keep it on the
same state, so I'll leave this name for now.

Moving code to enable() and disable() will also help in case we decide
to move FBC to pipe_config or something else later.

The current patch only puts the very basic code on enable() and
disable(). The next commits will take care of moving more stuff from
update() to the new functions.

v2:
  - Rebase.
  - Improve commit message (Chris).
v3: Rebase after changing the patch order.
v4: Rebase again after upstream changes.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h  |   1 +
 drivers/gpu/drm/i915/intel_display.c |  16 ++-
 drivers/gpu/drm/i915/intel_drv.h |   2 +
 drivers/gpu/drm/i915/intel_fbc.c | 196 +--
 4 files changed, 157 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6464006..92bb8e1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -914,6 +914,7 @@ struct i915_fbc {
 
bool false_color;
 
+   bool enabled;
bool active;
 
struct intel_fbc_work {
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a1e032a..2fe7c25 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4789,7 +4789,7 @@ static void intel_pre_plane_update(struct intel_crtc 
*crtc)
struct intel_crtc_atomic_commit *atomic = >atomic;
 
if (atomic->disable_fbc)
-   intel_fbc_disable_crtc(crtc);
+   intel_fbc_deactivate(crtc);
 
if (crtc->atomic.disable_ips)
hsw_disable_ips(crtc);
@@ -4897,6 +4897,8 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)
if (intel_crtc->config->has_pch_encoder)
intel_wait_for_vblank(dev, pipe);
intel_set_pch_fifo_underrun_reporting(dev_priv, pipe, true);
+
+   intel_fbc_enable(intel_crtc);
 }
 
 /* IPS only exists on ULT machines and is tied to pipe A. */
@@ -5004,6 +5006,8 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)
intel_wait_for_vblank(dev, hsw_workaround_pipe);
intel_wait_for_vblank(dev, hsw_workaround_pipe);
}
+
+   intel_fbc_enable(intel_crtc);
 }
 
 static void ironlake_pfit_disable(struct intel_crtc *crtc, bool force)
@@ -5072,6 +5076,8 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc)
}
 
intel_set_pch_fifo_underrun_reporting(dev_priv, pipe, true);
+
+   intel_fbc_disable_crtc(intel_crtc);
 }
 
 static void haswell_crtc_disable(struct drm_crtc *crtc)
@@ -5123,6 +5129,8 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)
if (intel_crtc->config->has_pch_encoder)
intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
  true);
+
+   intel_fbc_disable_crtc(intel_crtc);
 }
 
 static void i9xx_pfit_enable(struct intel_crtc *crtc)
@@ -6188,6 +6196,8 @@ static void i9xx_crtc_enable(struct drm_crtc *crtc)
 
for_each_encoder_on_crtc(dev, crtc, encoder)
encoder->enable(encoder);
+
+   intel_fbc_enable(intel_crtc);
 }
 
 static void i9xx_pfit_disable(struct intel_crtc *crtc)
@@ -6250,6 +6260,8 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
 
if (!IS_GEN2(dev))
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
+
+   intel_fbc_disable_crtc(intel_crtc);
 }
 
 static void intel_crtc_disable_noatomic(struct drm_crtc *crtc)
@@ -11523,7 +11535,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
  to_intel_plane(primary)->frontbuffer_bit);
  

[Intel-gfx] [PATCH 03/12] drm/i915: pass the crtc as an argument to intel_fbc_update()

[Paulo Zanoni]

There's no need to reevaluate the status of every single crtc when a
single crtc changes its state.

With this, we're cutting the case where due to a change in pipe B,
intel_fbc_update() is called, then intel_fbc_find_crtc() concludes FBC
should be enabled on pipe A, then it completely rechecks the state of
pipe A only to conclude FBC should remain enabled on pipe A. If any
change on pipe A triggers a need to recompute whether FBC is valid on
pipe A, then at some point someone is going to call
intel_fbc_update(PIPE_A).

The addition of intel_fbc_deactivate() is necessary so we keep track
of the previously selected CRTC when we do invalidate/flush. We're
also going to continue the enable/disable/activate/deactivate concept
in the next patches.

v2: Rebase.
v3: Rebase after changing the patch order.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_display.c |  3 +-
 drivers/gpu/drm/i915/intel_drv.h |  2 +-
 drivers/gpu/drm/i915/intel_fbc.c | 68 +++-
 3 files changed, 31 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b5f7493..1040705 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4761,7 +4761,6 @@ static void intel_post_plane_update(struct intel_crtc 
*crtc)
 {
struct intel_crtc_atomic_commit *atomic = >atomic;
struct drm_device *dev = crtc->base.dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
 
if (atomic->wait_vblank)
intel_wait_for_vblank(dev, crtc->pipe);
@@ -4775,7 +4774,7 @@ static void intel_post_plane_update(struct intel_crtc 
*crtc)
intel_update_watermarks(>base);
 
if (atomic->update_fbc)
-   intel_fbc_update(dev_priv);
+   intel_fbc_update(crtc);
 
if (atomic->post_enable_primary)
intel_post_enable_primary(>base);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 523e553..91458fb 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1323,7 +1323,7 @@ static inline void intel_fbdev_restore_mode(struct 
drm_device *dev)
 
 /* intel_fbc.c */
 bool intel_fbc_enabled(struct drm_i915_private *dev_priv);
-void intel_fbc_update(struct drm_i915_private *dev_priv);
+void intel_fbc_update(struct intel_crtc *crtc);
 void intel_fbc_init(struct drm_i915_private *dev_priv);
 void intel_fbc_disable(struct drm_i915_private *dev_priv);
 void intel_fbc_disable_crtc(struct intel_crtc *crtc);
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index bc9cd33..dae994d 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -429,7 +429,7 @@ static void intel_fbc_schedule_enable(struct intel_crtc 
*crtc)
schedule_delayed_work(>work, msecs_to_jiffies(50));
 }
 
-static void __intel_fbc_disable(struct drm_i915_private *dev_priv)
+static void intel_fbc_deactivate(struct drm_i915_private *dev_priv)
 {
WARN_ON(!mutex_is_locked(_priv->fbc.lock));
 
@@ -437,6 +437,11 @@ static void __intel_fbc_disable(struct drm_i915_private 
*dev_priv)
 
if (dev_priv->fbc.enabled)
dev_priv->fbc.disable_fbc(dev_priv);
+}
+
+static void __intel_fbc_disable(struct drm_i915_private *dev_priv)
+{
+   intel_fbc_deactivate(dev_priv);
dev_priv->fbc.crtc = NULL;
 }
 
@@ -501,24 +506,6 @@ static bool crtc_is_valid(struct intel_crtc *crtc)
return true;
 }
 
-static struct drm_crtc *intel_fbc_find_crtc(struct drm_i915_private *dev_priv)
-{
-   struct drm_crtc *crtc = NULL, *tmp_crtc;
-   enum pipe pipe;
-
-   for_each_pipe(dev_priv, pipe) {
-   tmp_crtc = dev_priv->pipe_to_crtc_mapping[pipe];
-
-   if (crtc_is_valid(to_intel_crtc(tmp_crtc)))
-   crtc = tmp_crtc;
-   }
-
-   if (!crtc)
-   return NULL;
-
-   return crtc;
-}
-
 static bool multiple_pipes_ok(struct drm_i915_private *dev_priv)
 {
enum pipe pipe;
@@ -804,21 +791,28 @@ static bool intel_fbc_hw_tracking_covers_screen(struct 
intel_crtc *crtc)
 
 /**
  * __intel_fbc_update - enable/disable FBC as needed, unlocked
- * @dev_priv: i915 device instance
+ * @crtc: the CRTC that triggered the update
  *
  * This function completely reevaluates the status of FBC, then enables,
  * disables or maintains it on the same state.
  */
-static void __intel_fbc_update(struct drm_i915_private *dev_priv)
+static void __intel_fbc_update(struct intel_crtc *crtc)
 {
-   struct drm_crtc *drm_crtc = NULL;
-   struct intel_crtc *crtc;
+   struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
struct drm_framebuffer *fb;
struct drm_i915_gem_object *obj;
const struct drm_display_mode *adjusted_mode;
 
WARN_ON(!mutex_is_locked(_priv->fbc.lock));
 
+   if 

[Intel-gfx] [PATCH 04/12] drm/i915: introduce is_active/activate/deactivate to the FBC terminology

[Paulo Zanoni]

The long term goal is to have enable/disable as the higher level
functions and activate/deactivate as the lower level functions, just
like we do for PSR and for the CRTC. This way, we'll run enable and
disable once per modeset, while update, activate and deactivate will
be run many times. With this, we can move the checks and code that
need to run only once per modeset to enable(), making the code simpler
and possibly a little faster.

This patch is just the first step on the conversion: it starts by
converting the current low level functions from enable/disable to
activate/deactivate. This patch by itself has no benefits other than
making review and rebase easier. Please see the next patches for more
details on the conversion.

v2:
  - Rebase.
  - Improve commit message (Chris).
v3: Rebase after changing the patch order.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |   2 +-
 drivers/gpu/drm/i915/i915_drv.h  |  10 ++-
 drivers/gpu/drm/i915/intel_display.c |   4 +-
 drivers/gpu/drm/i915/intel_drv.h |   2 +-
 drivers/gpu/drm/i915/intel_fbc.c | 114 +--
 drivers/gpu/drm/i915/intel_pm.c  |   2 +-
 6 files changed, 66 insertions(+), 68 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index d6d69f4..b05e8f3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1639,7 +1639,7 @@ static int i915_fbc_status(struct seq_file *m, void 
*unused)
intel_runtime_pm_get(dev_priv);
mutex_lock(_priv->fbc.lock);
 
-   if (intel_fbc_enabled(dev_priv))
+   if (intel_fbc_is_active(dev_priv))
seq_puts(m, "FBC enabled\n");
else
seq_printf(m, "FBC disabled: %s\n",
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 317414b..6464006 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -914,9 +914,7 @@ struct i915_fbc {
 
bool false_color;
 
-   /* Tracks whether the HW is actually enabled, not whether the feature is
-* possible. */
-   bool enabled;
+   bool active;
 
struct intel_fbc_work {
struct delayed_work work;
@@ -925,9 +923,9 @@ struct i915_fbc {
 
const char *no_fbc_reason;
 
-   bool (*fbc_enabled)(struct drm_i915_private *dev_priv);
-   void (*enable_fbc)(struct intel_crtc *crtc);
-   void (*disable_fbc)(struct drm_i915_private *dev_priv);
+   bool (*is_active)(struct drm_i915_private *dev_priv);
+   void (*activate)(struct intel_crtc *crtc);
+   void (*deactivate)(struct drm_i915_private *dev_priv);
 };
 
 /**
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 1040705..a1e032a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3176,8 +3176,8 @@ intel_pipe_set_base_atomic(struct drm_crtc *crtc, struct 
drm_framebuffer *fb,
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
 
-   if (dev_priv->fbc.disable_fbc)
-   dev_priv->fbc.disable_fbc(dev_priv);
+   if (dev_priv->fbc.deactivate)
+   dev_priv->fbc.deactivate(dev_priv);
 
dev_priv->display.update_primary_plane(crtc, fb, x, y);
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 91458fb..285db57 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1322,7 +1322,7 @@ static inline void intel_fbdev_restore_mode(struct 
drm_device *dev)
 #endif
 
 /* intel_fbc.c */
-bool intel_fbc_enabled(struct drm_i915_private *dev_priv);
+bool intel_fbc_is_active(struct drm_i915_private *dev_priv);
 void intel_fbc_update(struct intel_crtc *crtc);
 void intel_fbc_init(struct drm_i915_private *dev_priv);
 void intel_fbc_disable(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index dae994d..1650060 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -43,7 +43,7 @@
 
 static inline bool fbc_supported(struct drm_i915_private *dev_priv)
 {
-   return dev_priv->fbc.enable_fbc != NULL;
+   return dev_priv->fbc.activate != NULL;
 }
 
 static inline bool fbc_on_pipe_a_only(struct drm_i915_private *dev_priv)
@@ -64,11 +64,11 @@ static unsigned int get_crtc_fence_y_offset(struct 
intel_crtc *crtc)
return crtc->base.y - crtc->adjusted_y;
 }
 
-static void i8xx_fbc_disable(struct drm_i915_private *dev_priv)
+static void i8xx_fbc_deactivate(struct drm_i915_private *dev_priv)
 {
u32 fbc_ctl;
 
-   dev_priv->fbc.enabled = false;
+   dev_priv->fbc.active = false;
 
/* Disable compression */
fbc_ctl = I915_READ(FBC_CONTROL);
@@ -84,10 +84,10 @@ static void i8xx_fbc_disable(struct drm_i915_private 

[Intel-gfx] [PATCH 01/12] drm/i915: fix the CFB size check

[Paulo Zanoni]

In function find_compression_threshold() we try to over-allocate CFB
space in order to reduce reallocations and fragmentation, and we're
not considering that at the CFB size check. Consider it.

There is also a longer-term plan to kill
dev_priv->fbc.uncompressed_size, but this will come later.

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

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 11fc528..611672f 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -720,7 +720,8 @@ static int intel_fbc_setup_cfb(struct intel_crtc *crtc)
size = intel_fbc_calculate_cfb_size(crtc);
cpp = drm_format_plane_cpp(fb->pixel_format, 0);
 
-   if (size <= dev_priv->fbc.uncompressed_size)
+   if (dev_priv->fbc.compressed_fb.allocated &&
+   size <= dev_priv->fbc.compressed_fb.size * dev_priv->fbc.threshold)
return 0;
 
/* Release any current block */
-- 
2.6.2

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

[Intel-gfx] [PATCH 00/12] Yet another FBC series, v3 part 2

[Paulo Zanoni]

Hi

Here are other 12 patches from the last series of 26 which I sent two weeks ago.
The only things missing are the patch that does the flip optimizations - since
it had a bug caught by Ville - and a patch requested by Chris related to getting
framebuffer references or proving we don't need them. I'm leaving these to a
next patch series, since my plans for them includes multiple patches.

Thanks,
Paulo

Paulo Zanoni (12):
  drm/i915: fix the CFB size check
  drm/i915: set dev_priv->fbc.crtc before scheduling the enable work
  drm/i915: pass the crtc as an argument to intel_fbc_update()
  drm/i915: introduce is_active/activate/deactivate to the FBC
terminology
  drm/i915: introduce intel_fbc_{enable,disable}
  drm/i915: alloc/free the FBC CFB during enable/disable
  drm/i915: check for FBC planes in the same place as the pipes
  drm/i915: use a single intel_fbc_work struct
  drm/i915: wait for a vblank instead of 50ms when enabling FBC
  drm/i915: kill fbc.uncompressed_size
  drm/i915: get rid of FBC {,de}activation messages
  drm/i915: only nuke FBC when a drawing operation triggers a flush

 drivers/gpu/drm/i915/i915_debugfs.c  |   2 +-
 drivers/gpu/drm/i915/i915_drv.h  |  17 +-
 drivers/gpu/drm/i915/intel_display.c |  23 +-
 drivers/gpu/drm/i915/intel_drv.h |   6 +-
 drivers/gpu/drm/i915/intel_fbc.c | 602 +++
 drivers/gpu/drm/i915/intel_pm.c  |   2 +-
 6 files changed, 351 insertions(+), 301 deletions(-)

-- 
2.6.2

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

[Intel-gfx] [PATCH 09/12] drm/i915: wait for a vblank instead of 50ms when enabling FBC

[Paulo Zanoni]

Instead of waiting for 50ms, just wait until the next vblank, since
it's the minimum requirement.

This moves PC7 residency on my specific BDW machine running Cinnamon
from 60-70% to 84-89%. Without FBC, I get 20-25%. I'm using a
3200x1800 eDP panel. Notice: this was the case when the patch was
originally proposed, the order of the FBC patches changed since then,
so the actual numbers might be slightly different now.

v2:
  - Rebase after changing the patch order.
  - Update the commit message.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 +-
 drivers/gpu/drm/i915/intel_fbc.c | 12 +++-
 2 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9418bd5..ea08714 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -919,9 +919,9 @@ struct i915_fbc {
 
struct intel_fbc_work {
bool scheduled;
+   u32 scheduled_vblank;
struct work_struct work;
struct drm_framebuffer *fb;
-   unsigned long enable_jiffies;
} work;
 
const char *no_fbc_reason;
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index aa82075..72de8a1 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -391,7 +391,6 @@ static void intel_fbc_work_fn(struct work_struct *__work)
container_of(__work, struct drm_i915_private, fbc.work.work);
struct intel_fbc_work *work = _priv->fbc.work;
struct intel_crtc *crtc = dev_priv->fbc.crtc;
-   unsigned long delay_jiffies = msecs_to_jiffies(50);
 
 retry:
/* Delay the actual enabling to let pageflipping cease and the
@@ -400,14 +399,9 @@ retry:
 * vblank to pass after disabling the FBC before we attempt
 * to modify the control registers.
 *
-* A more complicated solution would involve tracking vblanks
-* following the termination of the page-flipping sequence
-* and indeed performing the enable as a co-routine and not
-* waiting synchronously upon the vblank.
-*
 * WaFbcWaitForVBlankBeforeEnable:ilk,snb
 */
-   wait_remaining_ms_from_jiffies(work->enable_jiffies, delay_jiffies);
+   intel_wait_for_vblank(dev_priv->dev, crtc->pipe);
 
mutex_lock(_priv->fbc.lock);
 
@@ -416,7 +410,7 @@ retry:
goto out;
 
/* Were we delayed again while this function was sleeping? */
-   if (time_after(work->enable_jiffies + delay_jiffies, jiffies)) {
+   if (drm_crtc_vblank_get(>base) == work->scheduled_vblank) {
mutex_unlock(_priv->fbc.lock);
goto retry;
}
@@ -449,7 +443,7 @@ static void intel_fbc_schedule_activation(struct intel_crtc 
*crtc)
 * jiffy count. */
work->fb = crtc->base.primary->fb;
work->scheduled = true;
-   work->enable_jiffies = jiffies;
+   work->scheduled_vblank = drm_crtc_vblank_count(>base);
 
schedule_work(>work);
 }
-- 
2.6.2

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

[Intel-gfx] [PATCH 10/12] drm/i915: kill fbc.uncompressed_size

[Paulo Zanoni]

Directly call intel_fbc_calculate_cfb_size() in the only place that
actually needs it, and use the proper check before removing the stolen
node. IMHO, this change makes our code easier to understand.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 -
 drivers/gpu/drm/i915/intel_fbc.c | 13 -
 2 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ea08714..43649c5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -901,7 +901,6 @@ struct i915_fbc {
/* This is always the inner lock when overlapping with struct_mutex and
 * it's the outer lock when overlapping with stolen_lock. */
struct mutex lock;
-   unsigned long uncompressed_size;
unsigned threshold;
unsigned int fb_id;
unsigned int possible_framebuffer_bits;
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 72de8a1..d18eb80 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -139,7 +139,7 @@ static void i8xx_fbc_activate(struct intel_crtc *crtc)
dev_priv->fbc.active = true;
 
/* Note: fbc.threshold == 1 for i8xx */
-   cfb_pitch = dev_priv->fbc.uncompressed_size / FBC_LL_SIZE;
+   cfb_pitch = intel_fbc_calculate_cfb_size(crtc, fb) / FBC_LL_SIZE;
if (fb->pitches[0] < cfb_pitch)
cfb_pitch = fb->pitches[0];
 
@@ -626,8 +626,6 @@ static int intel_fbc_alloc_cfb(struct intel_crtc *crtc)
   dev_priv->mm.stolen_base + compressed_llb->start);
}
 
-   dev_priv->fbc.uncompressed_size = size;
-
DRM_DEBUG_KMS("reserved %llu bytes of contiguous stolen space for FBC, 
threshold: %d\n",
  dev_priv->fbc.compressed_fb.size,
  dev_priv->fbc.threshold);
@@ -644,18 +642,15 @@ err_llb:
 
 static void __intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv)
 {
-   if (dev_priv->fbc.uncompressed_size == 0)
-   return;
-
-   i915_gem_stolen_remove_node(dev_priv, _priv->fbc.compressed_fb);
+   if (dev_priv->fbc.compressed_fb.allocated)
+   i915_gem_stolen_remove_node(dev_priv,
+   _priv->fbc.compressed_fb);
 
if (dev_priv->fbc.compressed_llb) {
i915_gem_stolen_remove_node(dev_priv,
dev_priv->fbc.compressed_llb);
kfree(dev_priv->fbc.compressed_llb);
}
-
-   dev_priv->fbc.uncompressed_size = 0;
 }
 
 void intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv)
-- 
2.6.2

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix GT frequency rounding

[Bob Paauwe]

On Fri, 13 Nov 2015 19:29:41 +0200
Mika Kuoppala  wrote:

> When we set and later readback a frequency value through
> sysfs interface, igt/pm_rpm assumes that we get same value back
> if it matches hw granularity.
> 
> On bxt we have found out that this is not always the case.
> Currently frequency - hw ratio - frequency conversions round down,
> with few exceptions on platforms that have more specific conversions.
> On bxt the supported range can be for example from 100Mhz to 650Mhz.
> Midpoint is then calculated by test to be 375 which pm_rps uses to find a
> closest hw supported frequency. That is 366 (ratio 22),
> which it then writes back. But as the rounding down kicks in,
> driver actually sets 350 instead of 366, as 366 is 2/3 below 22 * 50/3.
> 
> Fix this by rounding to closest instead of rounding down in
> freq-ratio-freq conversions.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92768
> Testcase: igt/pm_rps/basic-api
> Tested-by: Bob Paauwe 
> Cc: Bob Paauwe 
> Signed-off-by: Imre Deak 
> Signed-off-by: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 647c0ff..740623f 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -7139,7 +7139,8 @@ static int chv_freq_opcode(struct drm_i915_private 
> *dev_priv, int val)
>  int intel_gpu_freq(struct drm_i915_private *dev_priv, int val)
>  {
>   if (IS_GEN9(dev_priv->dev))
> - return (val * GT_FREQUENCY_MULTIPLIER) / GEN9_FREQ_SCALER;
> + return DIV_ROUND_CLOSEST(val * GT_FREQUENCY_MULTIPLIER,
> +  GEN9_FREQ_SCALER);
>   else if (IS_CHERRYVIEW(dev_priv->dev))
>   return chv_gpu_freq(dev_priv, val);
>   else if (IS_VALLEYVIEW(dev_priv->dev))
> @@ -7151,13 +7152,14 @@ int intel_gpu_freq(struct drm_i915_private *dev_priv, 
> int val)
>  int intel_freq_opcode(struct drm_i915_private *dev_priv, int val)
>  {
>   if (IS_GEN9(dev_priv->dev))
> - return (val * GEN9_FREQ_SCALER) / GT_FREQUENCY_MULTIPLIER;
> + return DIV_ROUND_CLOSEST(val * GEN9_FREQ_SCALER,
> +  GT_FREQUENCY_MULTIPLIER);
>   else if (IS_CHERRYVIEW(dev_priv->dev))
>   return chv_freq_opcode(dev_priv, val);
>   else if (IS_VALLEYVIEW(dev_priv->dev))
>   return byt_freq_opcode(dev_priv, val);
>   else
> - return val / GT_FREQUENCY_MULTIPLIER;
> + return DIV_ROUND_CLOSEST(val, GT_FREQUENCY_MULTIPLIER);
>  }
>  
>  struct request_boost {

Reviewed-by: Bob Paauwe 

-- 
--
Bob Paauwe  
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp.  Folsom, CA
(916) 356-6193

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix crtc_y assignment in intel_find_initial_plane_obj()

[Ville Syrjälä]

On Fri, Nov 13, 2015 at 07:36:08PM +0200, Jani Nikula wrote:
> On Fri, 13 Nov 2015, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > Let's set crtc_y to 0 instead of setting src_y twice.
> >
> > Multiple assignments in one statement is a good way to hide bugs.
> > Please don't do that.
> >
> > Cc: Maarten Lankhorst 
> > Fixes: be5651f2d581 ("drm/i915: Update missing properties in 
> > find_initial_plane_obj")
> 
> Cc: sta...@vger.kernel.org # v4.3+
> 
> right?

I think the state is kzalloc()ed, so there's probably no real bug here.
Should have mentioned that in the commit message I suppose.

> 
> 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index d7c8a0f..e3db46d 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -2640,11 +2640,13 @@ intel_find_initial_plane_obj(struct intel_crtc 
> > *intel_crtc,
> > return;
> >  
> >  valid_fb:
> > -   plane_state->src_x = plane_state->src_y = 0;
> > +   plane_state->src_x = 0;
> > +   plane_state->src_y = 0;
> > plane_state->src_w = fb->width << 16;
> > plane_state->src_h = fb->height << 16;
> >  
> > -   plane_state->crtc_x = plane_state->src_y = 0;
> > +   plane_state->crtc_x = 0;
> > +   plane_state->crtc_y = 0;
> > plane_state->crtc_w = fb->width;
> > plane_state->crtc_h = fb->height;
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

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

Re: [Intel-gfx] [PATCH 04/31] drm/i915: Handle actual IPS enabled state.

[Ville Syrjälä]

On Fri, Nov 13, 2015 at 06:20:00PM +, Daniel Stone wrote:
> Hi Rodrigo,
> 
> On 5 November 2015 at 18:49, Rodrigo Vivi  wrote:
> > With this we know if IPS is actually enabled.
> > It might not be activated on BDW since Hardware take
> > the decision and do its transition. However we have
> > the visibility of the state on our driver what we didn't
> > had until this patch. At least on BDW.
> >
> > Since ips_ready means that ips will be enabled and ips_disable()
> > checks for the state of our enabled/disabled state machine
> > we can remove that FIXME that was there for crtc_load_lut
> > workaround for Haswell.
> >
> > With this state machine and ips being disabled from
> > different places and many times when testcases with sink_crtc
> > for instance it is better to have it protected with its own mutex lock.
> > Ohterwise we cannot guarantee consitent ips.enabled state with the
> > register bit.
> 
> Thinking about this, I have two comments (and second Chris's
> similar-ish comment about PSR):
> 
> Should this perhaps be a CRTC property rather than a device property?
> Is it tied to a particular pipe, or can it move away from pipe A?
> 
> Secondly, having a vblank wait to enable IPS is pretty unfortunate, as
> it makes modesets take longer. I like the PSR enable being split away
> from the modeset sequence, so perhaps we could do something like:
> 
> enum ips_state {
>   IPS_DISABLED = 0, /**< unsupported or explicitly disabled by module param */
>   IPS_READY, /**< IPS can be enabled if a suitable state is applied to
> the CRTC (planes enabled, cdclk not exceeding 95% on BDW) */
>   IPS_ARMED, /**< suitable configuration applied; IPS pending activation */
>   IPS_ACTIVE
> };
> 
> Having this on the CRTC state means that we could walk through the
> following process:
>   - IPS_READY set on suitable platforms when not explictly disabled
>   - modeset arrives: atomic_check examines conditions and changes
> state from IPS_READY to IPS_ARMED
>   - next pageflip arrives and changes state from IPS_ARMED to
> IPS_ACTIVE, activates IPS
> 
> Being a member of the CRTC state means that anyone duplicating the
> pipe's CRTC state could discover the IPS status like that, and
> eliminates the need for a second mutex.
> 
> Maybe that's not the best approach, but I think we need to find a way
> to take the synchronous vblank wait out of the modeset path. Using a
> workqueue is another option, but synchronisation would need to be
> quite carefully handled.

Long time ago I posted a patch to make ips enable asynchronously from
a vblank work.

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

Re: [Intel-gfx] Fixing i915/opregion issues with firmware which lists more then 8 output devices

[Jani Nikula]

On Fri, 06 Nov 2015, Hans de Goede  wrote:
> Hi,
>
> On 06-11-15 11:19, Jani Nikula wrote:
>> On Thu, 05 Nov 2015, Hans de Goede  wrote:
>>> Hi,
>>>
>>> As discussed in the past, the i915 opregion code does not do the
>>> right thing wrt the CADL field when there are more then 8 outputs,
>>> this is causing issues on many different types of Asus laptops.
>>>
>>> This thread has details and a number of attempts to fix this:
>>>
>>> https://lkml.org/lkml/2014/2/11/1032
>>>
>>> This is impacting many users, here is an incomplete list of bug reports:
>>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=70241
>>> https://bugzilla.kernel.org/show_bug.cgi?id=88941
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1144866
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1277785
>>>
>>> And I'm pretty sure that is just the tip of the iceberg, some users
>>> have even analyzed their BIOS AML code and come up with an AML
>>> hack in an attempt to fix this:
>>>
>>> http://blog.yjwong.name/fixing-display-backlight-hotkeys-on-asus-n550jk/
>>>
>>> It would be really great of someone from Intel could step up and start
>>> working on a proper fix for this.
>>
>> Hans, thanks for bringing this up again.
>>
>> IIUC this would require something along the lines of:
>>
>> - Properly map acpi video bus children and DRM connectors in
>>intel_didl_outputs(). This is likely the hardest part. Save the
>>display ids in struct intel_connector.
>>
>> - Replace intel_setup_cadls() with functions to add/remove display ids
>>from opregion CADL.
>>
>> - Call the above functions as part of the modeset sequence (either from
>>intel_display.c or from the encoder hooks, whichever is best) to keep
>>CADL up-to-date about active outputs. Here, getting DP MST right is
>>probably the hard one.
>>
>> If the mapping goes wrong, and some id that used to be in CADL with the
>> current code gets dropped, this may regress. That's the biggest risk,
>> really.
>>
>> For the backlight/hotkey stuff, the minimal fix may be to keep the
>> stupid static initialization of the CADL in intel_setup_cadls() like we
>> have now, but ensuring the embedded displays are included in the list.
>
> This is what Aaron's first attempt at fixing this more or less did:
>
> https://lkml.org/lkml/2014/2/11/1032
>
> Unless someone actually steps up to do a proper fix for this *now*,
> maybe the i915 driver needs to incorporate a slightly revised / improved
> version of that patch as a work around for now ?

I dug into this a bit. (Well, more than just a bit. Friday night, doing
ACPI dumps and deciphering AML. What was I thinking?)

It seems that part of the problem is caused by

commit 3143751ff51a163b77f7efd389043e038f3e008e
Author: Zhang Rui 
Date:   Mon Mar 29 15:12:16 2010 +0800

drm/i915: set DIDL using the ACPI video output device _ADR method return.

which apparently caters for buggy bioses. The relevant bug report is
[1].

IIUC, the graphics driver is supposed to set up the IDs (so that would
take care of the "hardest part" above). On a couple of modern machines
that I checked, the above commit causes i915 to ask the AML code using
_ADR, which looks at DIDL, which is what we're trying to initialize so
it's zero, and then AML pulls IDs out of thin air, also for devices that
don't really exist because AML doesn't know.

I'll probably submit a patch doing a revert of the above, if only to
test. But we'll still have to figure out something for the regressions
it probably causes for the buggy machines. *sigh*.

This just reinforces my opinion that adding hacks to fix some broken
machines is not worth it. The no regressions rule turns the hacks into a
nightmare when it breaks good hardware.


BR,
Jani.


[1] https://bugzilla.kernel.org/show_bug.cgi?id=15054


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

Re: [Intel-gfx] [PATCH 0/4] PSR Critical fixes

[Vivi, Rodrigo]

On Fri, 2015-11-13 at 17:08 +0200, Ville Syrjälä wrote:
> On Wed, Nov 11, 2015 at 11:37:06AM -0800, Rodrigo Vivi wrote:
> > Let's split critical PSR fixes from the series that contains other
> > reworks, stabilization and improvements.
> > 
> > The second patch in this series isn't considered critical in terms
> > of functionality, but it depends on the first one and it can be 
> > consider
> > a fix for PSR residency on VLV/CHV.
> 
> FYI I recently glanced at the psr code and a few things that left me
> scratching my head:

Thanks for spotting this.

> - hsw_psr_enable_sink() frobs at the AUX registers without holding 
> the hw_mutex.
>   On SKL+ it seems to use the normal AUX registers here. Before it 
> used
>   the special PSR registers, so that may have been OK, but the SKL+
>   thing seems rather questionable.

Yes, I agree. I'll take a look.

> - intel_psr_enable() calls intel_psr_activate() on SKL+ but not on
>   HSW/BDW. I'm thinking there should be a comment there to make it 
> clear
>   why, if it's even correct.

Indeed. Also Durga when reviewing mentioned it would be good to make
only worker calling _activate(). So I will follow-up with a patch to
fix this.


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

Re: [Intel-gfx] [PATCH v2 10/12] drm/i915/gen9: Turn DC handling into a power well

[Imre Deak]

On to, 2015-11-12 at 15:30 +0200, Imre Deak wrote:
> On to, 2015-11-12 at 13:24 +0100, Patrik Jakobsson wrote:
> > On Wed, Nov 11, 2015 at 08:57:19PM +0200, Imre Deak wrote:
> > > On ma, 2015-11-09 at 16:48 +0100, Patrik Jakobsson wrote:
> > > > Handle DC off as a power well where enabling the power well
> > > > will
> > > > prevent
> > > > the DMC to enter selected DC states (required around modesets
> > > > and
> > > > Aux
> > > > A). Disabling the power well will allow DC states again. For
> > > > now
> > > > the
> > > > highest DC state is DC6 for Skylake and DC5 for Broxton but
> > > > will
> > > > be
> > > > configurable for Skylake in a later patch.
> > > > 
> > > > v2: Check both DC5 and DC6 bits in power well enabled function
> > > > (Ville)
> > > > 
> > > > Signed-off-by: Patrik Jakobsson <
> > > > patrik.jakobs...@linux.intel.com
> > > > > 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.c |   6 --
> > > >  drivers/gpu/drm/i915/i915_reg.h |   1 +
> > > >  drivers/gpu/drm/i915/intel_display.c|   6 ++
> > > >  drivers/gpu/drm/i915/intel_runtime_pm.c | 110
> > > > +++-
> > > >  4 files changed, 88 insertions(+), 35 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > > b/drivers/gpu/drm/i915/i915_drv.c
> > > > index 5a63f9a..0c7f435 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > > @@ -1072,9 +1072,6 @@ static int i915_pm_resume(struct device
> > > > *dev)
> > > >  
> > > >  static int skl_suspend_complete(struct drm_i915_private
> > > > *dev_priv)
> > > >  {
> > > > -   if (dev_priv->csr.dmc_payload)
> > > > -   skl_enable_dc6(dev_priv);
> > > > -
> > > > return 0;
> > > >  }
> > > >  
> > > > @@ -1119,9 +1116,6 @@ static int bxt_resume_prepare(struct
> > > > drm_i915_private *dev_priv)
> > > >  
> > > >  static int skl_resume_prepare(struct drm_i915_private
> > > > *dev_priv)
> > > >  {
> > > > -   if (dev_priv->csr.dmc_payload)
> > > > -   skl_disable_dc6(dev_priv);
> > > > -
> > > > return 0;
> > > >  }
> > > >  
> > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > > b/drivers/gpu/drm/i915/i915_reg.h
> > > > index 31b3a84..df445ba 100644
> > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > @@ -636,6 +636,7 @@ enum skl_disp_power_wells {
> > > >  
> > > > /* Not actual bit groups. Used as IDs for
> > > > lookup_power_well() */
> > > > SKL_DISP_PW_ALWAYS_ON,
> > > > +   SKL_DISP_PW_DC_OFF,
> > > 
> > > Imo it would be less confusing to call it DC3 power well. Looking
> > > at th
> > > e DC spec, DC4 is only a transitory state to DC5/6, so what we
> > > expect
> > > when we disable DC6/5 is DC3 or shallower power states (DC2/1/0).
> > 
> > I've been changing the name quite a few times but settled on "DC
> > off"
> > to keep it
> > generic. The main mechanism for the power well is to prevent any DC
> > states that
> > can cause us problems during certain operations (i.e. modeset). The
> > DC states we
> > need to block could change or be different between platforms. For
> > that reason I
> > would prefer not to be as specific with the naming.
> 
> All the power well names are platform specific so it would be logical
> and more meaningful to give this one a platform specific name too.
> Also
> 'DC off' is kind of a double negation leading to debug messages like
> 'enable DC off' which isn't that nice. But now that I think of it my
> idea isn't that great either. 'enable DC3' is confusing too, one
> could
> think we enable some power saving state at that point, which is not
> the
> case. So let's keep things as-is for now at least:
> 
> Reviewed-by: Imre Deak 

I noticed some issue only now, when testing it more:

> > >   };
> > > >  
> > > >  #define SKL_POWER_WELL_STATE(pw) (1 << ((pw) * 2))
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > index 649ac34..856d801 100644
> > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > @@ -13320,6 +13320,9 @@ static int intel_atomic_commit(struct
> > > > drm_device *dev,
> > > > to_intel_crtc_state(crtc->state)
> > > > ->update_pipe;
> > > > unsigned long put_domains = 0;
> > > >  
> > > > +   if (modeset)
> > > > +   intel_display_power_get(dev_priv,
> > > > POWER_DOMAIN_MODESET);
> > > > +
> > > > if (modeset && crtc->state->active) {
> > > > update_scanline_offset(to_intel_crtc(c
> > > > rt
> > > > c));
> > > > dev_priv->display.crtc_enable(crtc);
> > > > @@ -13343,6 +13346,9 @@ static int intel_atomic_commit(struct
> > > > drm_device *dev,
> > > > modeset_put_power_domains(dev_priv,
> > > > put_domains);
> > > 

Re: [Intel-gfx] [PATCH 04/31] drm/i915: Handle actual IPS enabled state.

[Daniel Stone]

Hi Rodrigo,

On 5 November 2015 at 18:49, Rodrigo Vivi  wrote:
> With this we know if IPS is actually enabled.
> It might not be activated on BDW since Hardware take
> the decision and do its transition. However we have
> the visibility of the state on our driver what we didn't
> had until this patch. At least on BDW.
>
> Since ips_ready means that ips will be enabled and ips_disable()
> checks for the state of our enabled/disabled state machine
> we can remove that FIXME that was there for crtc_load_lut
> workaround for Haswell.
>
> With this state machine and ips being disabled from
> different places and many times when testcases with sink_crtc
> for instance it is better to have it protected with its own mutex lock.
> Ohterwise we cannot guarantee consitent ips.enabled state with the
> register bit.

Thinking about this, I have two comments (and second Chris's
similar-ish comment about PSR):

Should this perhaps be a CRTC property rather than a device property?
Is it tied to a particular pipe, or can it move away from pipe A?

Secondly, having a vblank wait to enable IPS is pretty unfortunate, as
it makes modesets take longer. I like the PSR enable being split away
from the modeset sequence, so perhaps we could do something like:

enum ips_state {
  IPS_DISABLED = 0, /**< unsupported or explicitly disabled by module param */
  IPS_READY, /**< IPS can be enabled if a suitable state is applied to
the CRTC (planes enabled, cdclk not exceeding 95% on BDW) */
  IPS_ARMED, /**< suitable configuration applied; IPS pending activation */
  IPS_ACTIVE
};

Having this on the CRTC state means that we could walk through the
following process:
  - IPS_READY set on suitable platforms when not explictly disabled
  - modeset arrives: atomic_check examines conditions and changes
state from IPS_READY to IPS_ARMED
  - next pageflip arrives and changes state from IPS_ARMED to
IPS_ACTIVE, activates IPS

Being a member of the CRTC state means that anyone duplicating the
pipe's CRTC state could discover the IPS status like that, and
eliminates the need for a second mutex.

Maybe that's not the best approach, but I think we need to find a way
to take the synchronous vblank wait out of the modeset path. Using a
workqueue is another option, but synchronisation would need to be
quite carefully handled.

Cheers,
Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 02/12] drm/i915: set dev_priv->fbc.crtc before scheduling the enable work

[Paulo Zanoni]

This thing where we need to get the crtc either from the work
structure or the fbc structure itself is confusing and unnecessary.
Set fbc.crtc right when scheduling the enable work so we can always
use it.

The problem is not what gets passed and how to retrieve it. The
problem is that when we're in the other parts of the code we always
have to keep in mind that if FBC is already enabled we have to get the
CRTC from place A, if FBC is scheduled we have to get the CRTC from
place B, and if it's disabled there's no CRTC. Having a single place
to retrieve the CRTC from allows us to treat the "is enabled" and "is
scheduled" cases as the same case, reducing the mistake surface. I
guess I should add this to the commit message.

Besides the immediate advantages, this is also going to make one of
the next commits much simpler. And even later, when we introduce
enable/disable + activate/deactivate, this will be even simpler as
we'll set the CRTC at enable time. So all the
activate/deactivate/update code can just look at the single CRTC
variable regardless of the current state.

v2: Improve commit message (Chris).
v3: Rebase after changing the patch order.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 -
 drivers/gpu/drm/i915/intel_fbc.c | 22 +-
 2 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 71bd1dc..317414b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -920,7 +920,6 @@ struct i915_fbc {
 
struct intel_fbc_work {
struct delayed_work work;
-   struct intel_crtc *crtc;
struct drm_framebuffer *fb;
} *fbc_work;
 
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 611672f..bc9cd33 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -334,14 +334,13 @@ bool intel_fbc_enabled(struct drm_i915_private *dev_priv)
return dev_priv->fbc.enabled;
 }
 
-static void intel_fbc_enable(struct intel_crtc *crtc,
-const struct drm_framebuffer *fb)
+static void intel_fbc_enable(const struct drm_framebuffer *fb)
 {
-   struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
+   struct drm_i915_private *dev_priv = fb->dev->dev_private;
+   struct intel_crtc *crtc = dev_priv->fbc.crtc;
 
dev_priv->fbc.enable_fbc(crtc);
 
-   dev_priv->fbc.crtc = crtc;
dev_priv->fbc.fb_id = fb->base.id;
dev_priv->fbc.y = crtc->base.y;
 }
@@ -351,8 +350,8 @@ static void intel_fbc_work_fn(struct work_struct *__work)
struct intel_fbc_work *work =
container_of(to_delayed_work(__work),
 struct intel_fbc_work, work);
-   struct drm_i915_private *dev_priv = work->crtc->base.dev->dev_private;
-   struct drm_framebuffer *crtc_fb = work->crtc->base.primary->fb;
+   struct drm_i915_private *dev_priv = work->fb->dev->dev_private;
+   struct drm_framebuffer *crtc_fb = dev_priv->fbc.crtc->base.primary->fb;
 
mutex_lock(_priv->fbc.lock);
if (work == dev_priv->fbc.fbc_work) {
@@ -360,7 +359,7 @@ static void intel_fbc_work_fn(struct work_struct *__work)
 * the prior work.
 */
if (crtc_fb == work->fb)
-   intel_fbc_enable(work->crtc, work->fb);
+   intel_fbc_enable(work->fb);
 
dev_priv->fbc.fbc_work = NULL;
}
@@ -400,15 +399,15 @@ static void intel_fbc_schedule_enable(struct intel_crtc 
*crtc)
WARN_ON(!mutex_is_locked(_priv->fbc.lock));
 
intel_fbc_cancel_work(dev_priv);
+   dev_priv->fbc.crtc = crtc;
 
work = kzalloc(sizeof(*work), GFP_KERNEL);
if (work == NULL) {
DRM_ERROR("Failed to allocate FBC work structure\n");
-   intel_fbc_enable(crtc, crtc->base.primary->fb);
+   intel_fbc_enable(crtc->base.primary->fb);
return;
}
 
-   work->crtc = crtc;
work->fb = crtc->base.primary->fb;
INIT_DELAYED_WORK(>work, intel_fbc_work_fn);
 
@@ -984,11 +983,8 @@ void intel_fbc_invalidate(struct drm_i915_private 
*dev_priv,
 
mutex_lock(_priv->fbc.lock);
 
-   if (dev_priv->fbc.enabled)
+   if (dev_priv->fbc.enabled || dev_priv->fbc.fbc_work)
fbc_bits = INTEL_FRONTBUFFER_PRIMARY(dev_priv->fbc.crtc->pipe);
-   else if (dev_priv->fbc.fbc_work)
-   fbc_bits = INTEL_FRONTBUFFER_PRIMARY(
-   dev_priv->fbc.fbc_work->crtc->pipe);
else
fbc_bits = dev_priv->fbc.possible_framebuffer_bits;
 
-- 
2.6.2

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

Re: [Intel-gfx] [PATCH 04/31] drm/i915: Handle actual IPS enabled state.

[Daniel Stone]

Hi,

On 13 November 2015 at 18:38, Ville Syrjälä
 wrote:
> On Fri, Nov 13, 2015 at 06:20:00PM +, Daniel Stone wrote:
>> Maybe that's not the best approach, but I think we need to find a way
>> to take the synchronous vblank wait out of the modeset path. Using a
>> workqueue is another option, but synchronisation would need to be
>> quite carefully handled.
>
> Long time ago I posted a patch to make ips enable asynchronously from
> a vblank work.

Too long ago for my mail client, it seems ... got a link handy?

Cheers,
Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 12/12] drm/i915: only nuke FBC when a drawing operation triggers a flush

[Paulo Zanoni]

There's no need to stop and restart FBC: a nuke should be fine.

v2: Make it simpler (Chris).
v3: Rewrite the patch again due to patch order changes.

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

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index b80f232..207cf23 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -923,8 +923,12 @@ void intel_fbc_flush(struct drm_i915_private *dev_priv,
dev_priv->fbc.busy_bits &= ~frontbuffer_bits;
 
if (!dev_priv->fbc.busy_bits && dev_priv->fbc.enabled) {
-   __intel_fbc_deactivate(dev_priv);
-   __intel_fbc_update(dev_priv->fbc.crtc);
+   if (origin != ORIGIN_FLIP && dev_priv->fbc.active) {
+   intel_fbc_recompress(dev_priv);
+   } else {
+   __intel_fbc_deactivate(dev_priv);
+   __intel_fbc_update(dev_priv->fbc.crtc);
+   }
}
 
mutex_unlock(_priv->fbc.lock);
-- 
2.6.2

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

[Intel-gfx] [PATCH 06/12] drm/i915: alloc/free the FBC CFB during enable/disable

[Paulo Zanoni]

One of the problems with the current code is that it frees the CFB and
releases its drm_mm node as soon as we flip FBC's enable bit. This is
bad because after we disable FBC the hardware may still use the CFB
for the rest of the frame, so in theory we should only release the
drm_mm node one frame after we disable FBC. Otherwise, a stolen memory
allocation done right after an FBC disable may result in either
corrupted memory for the new owner of that memory region or corrupted
screen/underruns in case the new owner changes it while the hardware
is still reading it. This case is not exactly easy to reproduce since
we currently don't do a lot of stolen memory allocations, but I see
patches on the mailing list trying to expose stolen memory to user
space, so races will be possible.

I thought about three different approaches to solve this, and they all
have downsides.

The first approach would be to simply use multiple drm_mm nodes and
freeing the unused ones only after a frame has passed. The problem
with this approach is that since stolen memory is rather small,
there's a risk we just won't be able to allocate a new CFB from stolen
if the previous one was not freed yet. This could happen in case we
quickly disable FBC from pipe A and decide to enable it on pipe B, or
just if we change pipe A's fb stride while FBC is enabled.

The second approach would be similar to the first one, but maintaining
a single drm_mm node and keeping track of when it can be reused. This
would remove the disadvantage of not having enough space for two
nodes, but would create the new problem where we may not be able to
enable FBC at the point intel_fbc_update() is called, so we would have
to add more code to retry updating FBC after the time has passed. And
that can quickly get too complex since we can get invalidate, flush,
disable and other calls in the middle of the wait.

Both solutions above - and also the current code - have the problem
that we unnecessarily free+realloc FBC during invalidate+flush
operations even if the CFB size doesn't change.

The third option would be to move the allocation/deallocation to
enable/disable. This makes sure that the pipe is always disabled when
we allocate/deallocate the CFB, so there's no risk that the FBC
hardware may read or write to the memory right after it is freed from
drm_mm. The downside is that it is possible for user space to change
the buffer stride without triggering a disable/enable - only
deactivate/activate -, so we'll have to handle this case somehow, even
though it is uncommon - see igt's kms_frontbuffer_tracking test,
fbc-stridechange subtest. It could be possible to implement a way to
free+alloc the CFB during said stride change, but it would involve a
lot of book-keeping - exactly as mentioned above - just for a rare
case, so for now I'll keep it simple and just deactivate FBC. Besides,
we may not even need to disable FBC since we do CFB over-allocation.

v2: Rebase after changing the patch order.

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

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 719fcf6..d496a7a 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -64,6 +64,46 @@ static unsigned int get_crtc_fence_y_offset(struct 
intel_crtc *crtc)
return crtc->base.y - crtc->adjusted_y;
 }
 
+/*
+ * For SKL+, the plane source size used by the hardware is based on the value 
we
+ * write to the PLANE_SIZE register. For BDW-, the hardware looks at the value
+ * we wrote to PIPESRC.
+ */
+static void intel_fbc_get_plane_source_size(struct intel_crtc *crtc,
+   int *width, int *height)
+{
+   struct intel_plane_state *plane_state =
+   to_intel_plane_state(crtc->base.primary->state);
+   int w, h;
+
+   if (intel_rotation_90_or_270(plane_state->base.rotation)) {
+   w = drm_rect_height(_state->src) >> 16;
+   h = drm_rect_width(_state->src) >> 16;
+   } else {
+   w = drm_rect_width(_state->src) >> 16;
+   h = drm_rect_height(_state->src) >> 16;
+   }
+
+   if (width)
+   *width = w;
+   if (height)
+   *height = h;
+}
+
+static int intel_fbc_calculate_cfb_size(struct intel_crtc *crtc,
+   struct drm_framebuffer *fb)
+{
+   struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
+   int lines;
+
+   intel_fbc_get_plane_source_size(crtc, NULL, );
+   if (INTEL_INFO(dev_priv)->gen >= 7)
+   lines = min(lines, 2048);
+
+   /* Hardware needs the full buffer stride, not just the active area. */
+   return lines * fb->pitches[0];
+}
+
 static void i8xx_fbc_deactivate(struct drm_i915_private *dev_priv)
 {
u32 fbc_ctl;

[Intel-gfx] [PATCH 11/12] drm/i915: get rid of FBC {, de}activation messages

[Paulo Zanoni]

When running Cinnamon I see way too many pairs of these messages: many
per second. Get rid of them as they're just telling us FBC is working
as expected. We already have the messages for enable/disable, so we
don't really need messages for activation/deactivation.

v2: Rebase after changing the patch order.

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

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index d18eb80..b80f232 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -123,8 +123,6 @@ static void i8xx_fbc_deactivate(struct drm_i915_private 
*dev_priv)
DRM_DEBUG_KMS("FBC idle timed out\n");
return;
}
-
-   DRM_DEBUG_KMS("deactivated FBC\n");
 }
 
 static void i8xx_fbc_activate(struct intel_crtc *crtc)
@@ -172,9 +170,6 @@ static void i8xx_fbc_activate(struct intel_crtc *crtc)
fbc_ctl |= (cfb_pitch & 0xff) << FBC_CTL_STRIDE_SHIFT;
fbc_ctl |= obj->fence_reg;
I915_WRITE(FBC_CONTROL, fbc_ctl);
-
-   DRM_DEBUG_KMS("activated FBC, pitch %d, yoff %d, plane %c\n",
- cfb_pitch, crtc->base.y, plane_name(crtc->plane));
 }
 
 static bool i8xx_fbc_is_active(struct drm_i915_private *dev_priv)
@@ -202,8 +197,6 @@ static void g4x_fbc_activate(struct intel_crtc *crtc)
 
/* enable it... */
I915_WRITE(DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN);
-
-   DRM_DEBUG_KMS("activated fbc on plane %c\n", plane_name(crtc->plane));
 }
 
 static void g4x_fbc_deactivate(struct drm_i915_private *dev_priv)
@@ -217,8 +210,6 @@ static void g4x_fbc_deactivate(struct drm_i915_private 
*dev_priv)
if (dpfc_ctl & DPFC_CTL_EN) {
dpfc_ctl &= ~DPFC_CTL_EN;
I915_WRITE(DPFC_CONTROL, dpfc_ctl);
-
-   DRM_DEBUG_KMS("deactivated FBC\n");
}
 }
 
@@ -278,8 +269,6 @@ static void ilk_fbc_activate(struct intel_crtc *crtc)
}
 
intel_fbc_recompress(dev_priv);
-
-   DRM_DEBUG_KMS("activated fbc on plane %c\n", plane_name(crtc->plane));
 }
 
 static void ilk_fbc_deactivate(struct drm_i915_private *dev_priv)
@@ -293,8 +282,6 @@ static void ilk_fbc_deactivate(struct drm_i915_private 
*dev_priv)
if (dpfc_ctl & DPFC_CTL_EN) {
dpfc_ctl &= ~DPFC_CTL_EN;
I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl);
-
-   DRM_DEBUG_KMS("deactivated FBC\n");
}
 }
 
@@ -357,8 +344,6 @@ static void gen7_fbc_activate(struct intel_crtc *crtc)
I915_WRITE(DPFC_CPU_FENCE_OFFSET, get_crtc_fence_y_offset(crtc));
 
intel_fbc_recompress(dev_priv);
-
-   DRM_DEBUG_KMS("activated fbc on plane %c\n", plane_name(crtc->plane));
 }
 
 /**
-- 
2.6.2

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

[Intel-gfx] [PATCH 07/12] drm/i915: check for FBC planes in the same place as the pipes

[Paulo Zanoni]

This moves the pre-gen4 check from update() to enable(). The HAS_DDI
in the original code is not needed since only gen 2/3 have the plane
swapping code.

v2: Rebase.

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

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index d496a7a..a0784d0 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -514,6 +514,9 @@ static bool crtc_can_fbc(struct intel_crtc *crtc)
if (fbc_on_pipe_a_only(dev_priv) && crtc->pipe != PIPE_A)
return false;
 
+   if (INTEL_INFO(dev_priv)->gen < 4 && crtc->plane != PLANE_A)
+   return false;
+
return true;
 }
 
@@ -802,12 +805,6 @@ static void __intel_fbc_update(struct intel_crtc *crtc)
goto out_disable;
}
 
-   if ((INTEL_INFO(dev_priv)->gen < 4 || HAS_DDI(dev_priv)) &&
-   crtc->plane != PLANE_A) {
-   set_no_fbc_reason(dev_priv, "FBC unsupported on plane");
-   goto out_disable;
-   }
-
/* The use of a CPU fence is mandatory in order to detect writes
 * by the CPU to the scanout and trigger updates to the FBC.
 */
-- 
2.6.2

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

Re: [Intel-gfx] [PATCH 07/12] drm/i915: check for FBC planes in the same place as the pipes

[Chris Wilson]

On Fri, Nov 13, 2015 at 05:53:39PM -0200, Paulo Zanoni wrote:
> This moves the pre-gen4 check from update() to enable(). The HAS_DDI
> in the original code is not needed since only gen 2/3 have the plane
> swapping code.
> 
> v2: Rebase.
> 
> Signed-off-by: Paulo Zanoni 

Reviewed-by: Chris Wilson 

> ---
>  drivers/gpu/drm/i915/intel_fbc.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> b/drivers/gpu/drm/i915/intel_fbc.c
> index d496a7a..a0784d0 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -514,6 +514,9 @@ static bool crtc_can_fbc(struct intel_crtc *crtc)
>   if (fbc_on_pipe_a_only(dev_priv) && crtc->pipe != PIPE_A)
>   return false;
>  
> + if (INTEL_INFO(dev_priv)->gen < 4 && crtc->plane != PLANE_A)
> + return false;

Nit: you know what would really put the icing on the cake here,
if (fbc_on_plane_a_only(dev_priv) && crtc->plane != PLANE_A)
return false;
-Chris

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

Re: [Intel-gfx] [PATCH 09/12] drm/i915: wait for a vblank instead of 50ms when enabling FBC

[Zanoni, Paulo R]

Em Sex, 2015-11-13 às 21:03 +, Chris Wilson escreveu:
> On Fri, Nov 13, 2015 at 05:53:41PM -0200, Paulo Zanoni wrote:
> > Instead of waiting for 50ms, just wait until the next vblank, since
> > it's the minimum requirement.
> > 
> > This moves PC7 residency on my specific BDW machine running
> > Cinnamon
> > from 60-70% to 84-89%. Without FBC, I get 20-25%. I'm using a
> > 3200x1800 eDP panel. Notice: this was the case when the patch was
> > originally proposed, the order of the FBC patches changed since
> > then,
> > so the actual numbers might be slightly different now.
> > 
> > v2:
> >   - Rebase after changing the patch order.
> >   - Update the commit message.
> > 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  |  2 +-
> >  drivers/gpu/drm/i915/intel_fbc.c | 12 +++-
> >  2 files changed, 4 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 9418bd5..ea08714 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -919,9 +919,9 @@ struct i915_fbc {
> >  
> >     struct intel_fbc_work {
> >     bool scheduled;
> > +   u32 scheduled_vblank;
> >     struct work_struct work;
> >     struct drm_framebuffer *fb;
> > -   unsigned long enable_jiffies;
> >     } work;
> >  
> >     const char *no_fbc_reason;
> > diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> > b/drivers/gpu/drm/i915/intel_fbc.c
> > index aa82075..72de8a1 100644
> > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > @@ -391,7 +391,6 @@ static void intel_fbc_work_fn(struct
> > work_struct *__work)
> >     container_of(__work, struct drm_i915_private,
> > fbc.work.work);
> >     struct intel_fbc_work *work = _priv->fbc.work;
> >     struct intel_crtc *crtc = dev_priv->fbc.crtc;
> > -   unsigned long delay_jiffies = msecs_to_jiffies(50);
> >  
> >  retry:
> >     /* Delay the actual enabling to let pageflipping cease and
> > the
> > @@ -400,14 +399,9 @@ retry:
> >      * vblank to pass after disabling the FBC before we
> > attempt
> >      * to modify the control registers.
> >      *
> > -    * A more complicated solution would involve tracking
> > vblanks
> > -    * following the termination of the page-flipping sequence
> > -    * and indeed performing the enable as a co-routine and
> > not
> > -    * waiting synchronously upon the vblank.
> > -    *
> >      * WaFbcWaitForVBlankBeforeEnable:ilk,snb
> >      */
> > -   wait_remaining_ms_from_jiffies(work->enable_jiffies,
> > delay_jiffies);
> > +   intel_wait_for_vblank(dev_priv->dev, crtc->pipe);
> >  
> >     mutex_lock(_priv->fbc.lock);
> >  
> > @@ -416,7 +410,7 @@ retry:
> >     goto out;
> >  
> >     /* Were we delayed again while this function was sleeping?
> > */
> > -   if (time_after(work->enable_jiffies + delay_jiffies,
> > jiffies)) {
> > +   if (drm_crtc_vblank_get(>base) == work-
> > >scheduled_vblank) {
> >     mutex_unlock(_priv->fbc.lock);
> >     goto retry;
> >     }
> > @@ -449,7 +443,7 @@ static void
> > intel_fbc_schedule_activation(struct intel_crtc *crtc)
> >      * jiffy count. */
> >     work->fb = crtc->base.primary->fb;
> >     work->scheduled = true;
> > -   work->enable_jiffies = jiffies;
> > +   work->scheduled_vblank = drm_crtc_vblank_count(
> > >base);
> 
> Isn't the frame counter only incrementing whilst the vblank IRQ is
> enabled? Ville?

At the work function we call intel_wait_for_vblank(), which calls
drm_wait_one_vblank(), which calls drm_vblank_get().

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

Re: [Intel-gfx] [PATCH 09/12] drm/i915: wait for a vblank instead of 50ms when enabling FBC

[ch...@chris-wilson.co.uk]

On Fri, Nov 13, 2015 at 09:17:04PM +, Zanoni, Paulo R wrote:
> Em Sex, 2015-11-13 às 21:03 +, Chris Wilson escreveu:
> > On Fri, Nov 13, 2015 at 05:53:41PM -0200, Paulo Zanoni wrote:
> > > Instead of waiting for 50ms, just wait until the next vblank, since
> > > it's the minimum requirement.
> > > 
> > > This moves PC7 residency on my specific BDW machine running
> > > Cinnamon
> > > from 60-70% to 84-89%. Without FBC, I get 20-25%. I'm using a
> > > 3200x1800 eDP panel. Notice: this was the case when the patch was
> > > originally proposed, the order of the FBC patches changed since
> > > then,
> > > so the actual numbers might be slightly different now.
> > > 
> > > v2:
> > >   - Rebase after changing the patch order.
> > >   - Update the commit message.
> > > 
> > > Signed-off-by: Paulo Zanoni 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.h  |  2 +-
> > >  drivers/gpu/drm/i915/intel_fbc.c | 12 +++-
> > >  2 files changed, 4 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 9418bd5..ea08714 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -919,9 +919,9 @@ struct i915_fbc {
> > >  
> > >   struct intel_fbc_work {
> > >   bool scheduled;
> > > + u32 scheduled_vblank;
> > >   struct work_struct work;
> > >   struct drm_framebuffer *fb;
> > > - unsigned long enable_jiffies;
> > >   } work;
> > >  
> > >   const char *no_fbc_reason;
> > > diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> > > b/drivers/gpu/drm/i915/intel_fbc.c
> > > index aa82075..72de8a1 100644
> > > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > > @@ -391,7 +391,6 @@ static void intel_fbc_work_fn(struct
> > > work_struct *__work)
> > >   container_of(__work, struct drm_i915_private,
> > > fbc.work.work);
> > >   struct intel_fbc_work *work = _priv->fbc.work;
> > >   struct intel_crtc *crtc = dev_priv->fbc.crtc;
> > > - unsigned long delay_jiffies = msecs_to_jiffies(50);
> > >  
> > >  retry:
> > >   /* Delay the actual enabling to let pageflipping cease and
> > > the
> > > @@ -400,14 +399,9 @@ retry:
> > >    * vblank to pass after disabling the FBC before we
> > > attempt
> > >    * to modify the control registers.
> > >    *
> > > -  * A more complicated solution would involve tracking
> > > vblanks
> > > -  * following the termination of the page-flipping sequence
> > > -  * and indeed performing the enable as a co-routine and
> > > not
> > > -  * waiting synchronously upon the vblank.
> > > -  *
> > >    * WaFbcWaitForVBlankBeforeEnable:ilk,snb
> > >    */
> > > - wait_remaining_ms_from_jiffies(work->enable_jiffies,
> > > delay_jiffies);
> > > + intel_wait_for_vblank(dev_priv->dev, crtc->pipe);
> > >  
> > >   mutex_lock(_priv->fbc.lock);
> > >  
> > > @@ -416,7 +410,7 @@ retry:
> > >   goto out;
> > >  
> > >   /* Were we delayed again while this function was sleeping?
> > > */
> > > - if (time_after(work->enable_jiffies + delay_jiffies,
> > > jiffies)) {
> > > + if (drm_crtc_vblank_get(>base) == work-
> > > >scheduled_vblank) {
> > >   mutex_unlock(_priv->fbc.lock);
> > >   goto retry;
> > >   }
> > > @@ -449,7 +443,7 @@ static void
> > > intel_fbc_schedule_activation(struct intel_crtc *crtc)
> > >    * jiffy count. */
> > >   work->fb = crtc->base.primary->fb;
> > >   work->scheduled = true;
> > > - work->enable_jiffies = jiffies;
> > > + work->scheduled_vblank = drm_crtc_vblank_count(
> > > >base);
> > 
> > Isn't the frame counter only incrementing whilst the vblank IRQ is
> > enabled? Ville?
> 
> At the work function we call intel_wait_for_vblank(), which calls
> drm_wait_one_vblank(), which calls drm_vblank_get().

And drm_vblank_put...
-Chris

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

Re: [Intel-gfx] [PATCH 04/12] drm/i915: introduce is_active/activate/deactivate to the FBC terminology

[Chris Wilson]

On Fri, Nov 13, 2015 at 05:53:36PM -0200, Paulo Zanoni wrote:
> The long term goal is to have enable/disable as the higher level
> functions and activate/deactivate as the lower level functions, just
> like we do for PSR and for the CRTC. This way, we'll run enable and
> disable once per modeset, while update, activate and deactivate will
> be run many times. With this, we can move the checks and code that
> need to run only once per modeset to enable(), making the code simpler
> and possibly a little faster.
> 
> This patch is just the first step on the conversion: it starts by
> converting the current low level functions from enable/disable to
> activate/deactivate. This patch by itself has no benefits other than
> making review and rebase easier. Please see the next patches for more
> details on the conversion.
> 
> v2:
>   - Rebase.
>   - Improve commit message (Chris).
> v3: Rebase after changing the patch order.
> 
> Signed-off-by: Paulo Zanoni 
Reviewed-by: Chris Wilson 
-Chris

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

Re: [Intel-gfx] [PATCH 10/12] drm/i915: kill fbc.uncompressed_size

[Chris Wilson]

On Fri, Nov 13, 2015 at 05:53:42PM -0200, Paulo Zanoni wrote:
> Directly call intel_fbc_calculate_cfb_size() in the only place that
> actually needs it, and use the proper check before removing the stolen
> node. IMHO, this change makes our code easier to understand.
> 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  1 -
>  drivers/gpu/drm/i915/intel_fbc.c | 13 -
>  2 files changed, 4 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index ea08714..43649c5 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -901,7 +901,6 @@ struct i915_fbc {
>   /* This is always the inner lock when overlapping with struct_mutex and
>* it's the outer lock when overlapping with stolen_lock. */
>   struct mutex lock;
> - unsigned long uncompressed_size;
>   unsigned threshold;
>   unsigned int fb_id;
>   unsigned int possible_framebuffer_bits;
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> b/drivers/gpu/drm/i915/intel_fbc.c
> index 72de8a1..d18eb80 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -139,7 +139,7 @@ static void i8xx_fbc_activate(struct intel_crtc *crtc)
>   dev_priv->fbc.active = true;
>  
>   /* Note: fbc.threshold == 1 for i8xx */
> - cfb_pitch = dev_priv->fbc.uncompressed_size / FBC_LL_SIZE;
> + cfb_pitch = intel_fbc_calculate_cfb_size(crtc, fb) / FBC_LL_SIZE;
>   if (fb->pitches[0] < cfb_pitch)
>   cfb_pitch = fb->pitches[0];
>  
> @@ -626,8 +626,6 @@ static int intel_fbc_alloc_cfb(struct intel_crtc *crtc)
>  dev_priv->mm.stolen_base + compressed_llb->start);
>   }
>  
> - dev_priv->fbc.uncompressed_size = size;
> -
>   DRM_DEBUG_KMS("reserved %llu bytes of contiguous stolen space for FBC, 
> threshold: %d\n",
> dev_priv->fbc.compressed_fb.size,
> dev_priv->fbc.threshold);
> @@ -644,18 +642,15 @@ err_llb:
>  
>  static void __intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv)
>  {
> - if (dev_priv->fbc.uncompressed_size == 0)
> - return;
> -
> - i915_gem_stolen_remove_node(dev_priv, _priv->fbc.compressed_fb);
> + if (dev_priv->fbc.compressed_fb.allocated)

if (drm_mm_node_allocated(_priv->fb.compressed_fb)) right?

We've been pretty consistent in using drm_mm_node_allocated() so we may
as well stick with the rigour.

With that,
Reviewed-by: Chris Wilson 
-Chris

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

Re: [Intel-gfx] [PATCH 11/12] drm/i915: get rid of FBC {, de}activation messages

[Chris Wilson]

On Fri, Nov 13, 2015 at 05:53:43PM -0200, Paulo Zanoni wrote:
> When running Cinnamon I see way too many pairs of these messages: many
> per second. Get rid of them as they're just telling us FBC is working
> as expected. We already have the messages for enable/disable, so we
> don't really need messages for activation/deactivation.
> 
> v2: Rebase after changing the patch order.
> 
> Signed-off-by: Paulo Zanoni 

Fair enough, at this granularity logging isn't the best method of
evaluating behaviour and the outer enable/disable should give enough
hints for debugging.
Reviwed-by: Chris Wilson 
-Chris

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

Re: [Intel-gfx] [PATCH 06/12] drm/i915: alloc/free the FBC CFB during enable/disable

[Chris Wilson]

On Fri, Nov 13, 2015 at 05:53:38PM -0200, Paulo Zanoni wrote:
> One of the problems with the current code is that it frees the CFB and
> releases its drm_mm node as soon as we flip FBC's enable bit. This is
> bad because after we disable FBC the hardware may still use the CFB
> for the rest of the frame, so in theory we should only release the
> drm_mm node one frame after we disable FBC. Otherwise, a stolen memory
> allocation done right after an FBC disable may result in either
> corrupted memory for the new owner of that memory region or corrupted
> screen/underruns in case the new owner changes it while the hardware
> is still reading it. This case is not exactly easy to reproduce since
> we currently don't do a lot of stolen memory allocations, but I see
> patches on the mailing list trying to expose stolen memory to user
> space, so races will be possible.
> 
> I thought about three different approaches to solve this, and they all
> have downsides.
> 
> The first approach would be to simply use multiple drm_mm nodes and
> freeing the unused ones only after a frame has passed. The problem
> with this approach is that since stolen memory is rather small,
> there's a risk we just won't be able to allocate a new CFB from stolen
> if the previous one was not freed yet. This could happen in case we
> quickly disable FBC from pipe A and decide to enable it on pipe B, or
> just if we change pipe A's fb stride while FBC is enabled.
> 
> The second approach would be similar to the first one, but maintaining
> a single drm_mm node and keeping track of when it can be reused. This
> would remove the disadvantage of not having enough space for two
> nodes, but would create the new problem where we may not be able to
> enable FBC at the point intel_fbc_update() is called, so we would have
> to add more code to retry updating FBC after the time has passed. And
> that can quickly get too complex since we can get invalidate, flush,
> disable and other calls in the middle of the wait.
> 
> Both solutions above - and also the current code - have the problem
> that we unnecessarily free+realloc FBC during invalidate+flush
> operations even if the CFB size doesn't change.
> 
> The third option would be to move the allocation/deallocation to
> enable/disable. This makes sure that the pipe is always disabled when
> we allocate/deallocate the CFB, so there's no risk that the FBC
> hardware may read or write to the memory right after it is freed from
> drm_mm. The downside is that it is possible for user space to change
> the buffer stride without triggering a disable/enable - only
> deactivate/activate -, so we'll have to handle this case somehow, even
> though it is uncommon - see igt's kms_frontbuffer_tracking test,
> fbc-stridechange subtest. It could be possible to implement a way to
> free+alloc the CFB during said stride change, but it would involve a
> lot of book-keeping - exactly as mentioned above - just for a rare
> case, so for now I'll keep it simple and just deactivate FBC. Besides,
> we may not even need to disable FBC since we do CFB over-allocation.

It's not really that rare. Starting a fullscreen client that covers a
single monitor in a multi-monitor setup will trigger a change in stride
on one of the CRTC (the monitors will be flipped independently).

Not that actually affects your argument, just presenting a use-case that
exists in the wild today.
-Chris

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

Re: [Intel-gfx] [PATCH 09/12] drm/i915: wait for a vblank instead of 50ms when enabling FBC

[Ville Syrjälä]

On Fri, Nov 13, 2015 at 11:20:19PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 13, 2015 at 09:03:43PM +, Chris Wilson wrote:
> > On Fri, Nov 13, 2015 at 05:53:41PM -0200, Paulo Zanoni wrote:
> > > Instead of waiting for 50ms, just wait until the next vblank, since
> > > it's the minimum requirement.
> > > 
> > > This moves PC7 residency on my specific BDW machine running Cinnamon
> > > from 60-70% to 84-89%. Without FBC, I get 20-25%. I'm using a
> > > 3200x1800 eDP panel. Notice: this was the case when the patch was
> > > originally proposed, the order of the FBC patches changed since then,
> > > so the actual numbers might be slightly different now.
> > > 
> > > v2:
> > >   - Rebase after changing the patch order.
> > >   - Update the commit message.
> > > 
> > > Signed-off-by: Paulo Zanoni 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.h  |  2 +-
> > >  drivers/gpu/drm/i915/intel_fbc.c | 12 +++-
> > >  2 files changed, 4 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 9418bd5..ea08714 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -919,9 +919,9 @@ struct i915_fbc {
> > >  
> > >   struct intel_fbc_work {
> > >   bool scheduled;
> > > + u32 scheduled_vblank;
> > >   struct work_struct work;
> > >   struct drm_framebuffer *fb;
> > > - unsigned long enable_jiffies;
> > >   } work;
> > >  
> > >   const char *no_fbc_reason;
> > > diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> > > b/drivers/gpu/drm/i915/intel_fbc.c
> > > index aa82075..72de8a1 100644
> > > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > > @@ -391,7 +391,6 @@ static void intel_fbc_work_fn(struct work_struct 
> > > *__work)
> > >   container_of(__work, struct drm_i915_private, fbc.work.work);
> > >   struct intel_fbc_work *work = _priv->fbc.work;
> > >   struct intel_crtc *crtc = dev_priv->fbc.crtc;
> > > - unsigned long delay_jiffies = msecs_to_jiffies(50);
> > >  
> > >  retry:
> > >   /* Delay the actual enabling to let pageflipping cease and the
> > > @@ -400,14 +399,9 @@ retry:
> > >* vblank to pass after disabling the FBC before we attempt
> > >* to modify the control registers.
> > >*
> > > -  * A more complicated solution would involve tracking vblanks
> > > -  * following the termination of the page-flipping sequence
> > > -  * and indeed performing the enable as a co-routine and not
> > > -  * waiting synchronously upon the vblank.
> > > -  *
> > >* WaFbcWaitForVBlankBeforeEnable:ilk,snb
> > >*/
> > > - wait_remaining_ms_from_jiffies(work->enable_jiffies, delay_jiffies);
> > > + intel_wait_for_vblank(dev_priv->dev, crtc->pipe);
> > >  
> > >   mutex_lock(_priv->fbc.lock);
> > >  
> > > @@ -416,7 +410,7 @@ retry:
> > >   goto out;
> > >  
> > >   /* Were we delayed again while this function was sleeping? */
> > > - if (time_after(work->enable_jiffies + delay_jiffies, jiffies)) {
> > > + if (drm_crtc_vblank_get(>base) == work->scheduled_vblank) {
> > >   mutex_unlock(_priv->fbc.lock);
> > >   goto retry;
> > >   }
> > > @@ -449,7 +443,7 @@ static void intel_fbc_schedule_activation(struct 
> > > intel_crtc *crtc)
> > >* jiffy count. */
> > >   work->fb = crtc->base.primary->fb;
> > >   work->scheduled = true;
> > > - work->enable_jiffies = jiffies;
> > > + work->scheduled_vblank = drm_crtc_vblank_count(>base);
> > 
> > Isn't the frame counter only incrementing whilst the vblank IRQ is
> > enabled? Ville?
> 
> I see a "+ if (drm_crtc_vblank_get(" earlier.

Hmm. Actually it's doing
"drm_crtc_vblank_get(>base) == work->scheduled_vblank)"
which looks rather like nonsense.

Not sure what the intention here was...

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

[Intel-gfx] [PATCH 1/2] lib/kbl: move KBL check from IS_SKYLAKE() to IS_GEN9()

[Wayne Boyer]

Remove the KBL check from IS_SKYLAKE() following the kernel definition.
Then, add the KBL check to IS_GEN9().

The idea is to avoid confusion.  On the kernel side, the mix of SKY
and KBL was nacked so the platforms are split.

Signed-off-by: Wayne Boyer 
---
 lib/intel_chipset.h | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/lib/intel_chipset.h b/lib/intel_chipset.h
index 6fcc244..f9fcdd6 100644
--- a/lib/intel_chipset.h
+++ b/lib/intel_chipset.h
@@ -434,8 +434,7 @@ void intel_check_pch(void);
 IS_KBL_GT2(devid) || \
 IS_KBL_GT3(devid))
 
-#define IS_SKYLAKE(devid)  (IS_KABYLAKE(devid) || \
-IS_SKL_GT1(devid) || \
+#define IS_SKYLAKE(devid)  (IS_SKL_GT1(devid) || \
 IS_SKL_GT2(devid) || \
 IS_SKL_GT3(devid))
 
@@ -443,7 +442,9 @@ void intel_check_pch(void);
 (devid) == PCI_CHIP_BROXTON_1 || \
 (devid) == PCI_CHIP_BROXTON_2)
 
-#define IS_GEN9(devid) (IS_SKYLAKE(devid) || IS_BROXTON(devid))
+#define IS_GEN9(devid) (IS_KABYLAKE(devid) || \
+IS_SKYLAKE(devid) || \
+IS_BROXTON(devid))
 
 #define IS_965(devid)  (IS_GEN4(devid) || \
 IS_GEN5(devid) || \
-- 
1.9.1

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

[Intel-gfx] [PATCH 2/2] lib/kbl: Add Kabylake GT4 PCI IDs

[Wayne Boyer]

Add the Kabylake GT4 PCI IDs as defined in this kernel patch.

commit 8b10c0cf21ec84618d4bf02c73c0543500ece68d
Author: Deepak S 
Date:   Wed Oct 28 12:21:12 2015 -0700
drm/i915/kbl: Add Kabylake GT4 PCI ID

Signed-off-by: Wayne Boyer 
---
 lib/intel_chipset.h | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/lib/intel_chipset.h b/lib/intel_chipset.h
index f9fcdd6..19fa02f 100644
--- a/lib/intel_chipset.h
+++ b/lib/intel_chipset.h
@@ -217,13 +217,17 @@ void intel_check_pch(void);
 #define PCI_CHIP_KABYLAKE_DT_GT2   0x5912
 #define PCI_CHIP_KABYLAKE_DT_GT1_5 0x5917
 #define PCI_CHIP_KABYLAKE_DT_GT1   0x5902
+#define PCI_CHIP_KABYLAKE_DT_GT4   0x5932
 #define PCI_CHIP_KABYLAKE_HALO_GT2 0x591B
 #define PCI_CHIP_KABYLAKE_HALO_GT3 0x592B
 #define PCI_CHIP_KABYLAKE_HALO_GT1 0x590B
+#define PCI_CHIP_KABYLAKE_HALO_GT4 0x593B
 #define PCI_CHIP_KABYLAKE_SRV_GT2  0x591A
 #define PCI_CHIP_KABYLAKE_SRV_GT3  0x592A
+#define PCI_CHIP_KABYLAKE_SRV_GT4  0x593A
 #define PCI_CHIP_KABYLAKE_SRV_GT1  0x590A
 #define PCI_CHIP_KABYLAKE_WKS_GT2  0x591D
+#define PCI_CHIP_KABYLAKE_WKS_GT4  0x593D
 
 #define PCI_CHIP_BROXTON_0 0x0A84
 #define PCI_CHIP_BROXTON_1 0x1A84
@@ -430,9 +434,15 @@ void intel_check_pch(void);
 (devid) == PCI_CHIP_KABYLAKE_HALO_GT3|| \
 (devid) == PCI_CHIP_KABYLAKE_SRV_GT3)
 
+#define IS_KBL_GT4(devid)  ((devid) == PCI_CHIP_KABYLAKE_DT_GT4|| \
+(devid) == PCI_CHIP_KABYLAKE_HALO_GT4|| \
+(devid) == PCI_CHIP_KABYLAKE_SRV_GT4|| \
+(devid) == PCI_CHIP_KABYLAKE_WKS_GT4)
+
 #define IS_KABYLAKE(devid) (IS_KBL_GT1(devid) || \
 IS_KBL_GT2(devid) || \
-IS_KBL_GT3(devid))
+IS_KBL_GT3(devid) || \
+IS_KBL_GT4(devid))
 
 #define IS_SKYLAKE(devid)  (IS_SKL_GT1(devid) || \
 IS_SKL_GT2(devid) || \
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 04/31] drm/i915: Handle actual IPS enabled state.

[Daniel Stone]

On 13 November 2015 at 20:28, Ville Syrjälä
 wrote:
> On Fri, Nov 13, 2015 at 06:55:18PM +, Daniel Stone wrote:
>> On 13 November 2015 at 18:38, Ville Syrjälä
>>  wrote:
>> > On Fri, Nov 13, 2015 at 06:20:00PM +, Daniel Stone wrote:
>> >> Maybe that's not the best approach, but I think we need to find a way
>> >> to take the synchronous vblank wait out of the modeset path. Using a
>> >> workqueue is another option, but synchronisation would need to be
>> >> quite carefully handled.
>> >
>> > Long time ago I posted a patch to make ips enable asynchronously from
>> > a vblank work.
>>
>> Too long ago for my mail client, it seems ... got a link handy?
>
> http://lists.freedesktop.org/archives/intel-gfx/2014-June/047626.html

+struct intel_vblank_notify {

Oh dear ...

Cheers,
Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/12] drm/i915: set dev_priv->fbc.crtc before scheduling the enable work

[Chris Wilson]

On Fri, Nov 13, 2015 at 05:53:34PM -0200, Paulo Zanoni wrote:
> This thing where we need to get the crtc either from the work
> structure or the fbc structure itself is confusing and unnecessary.
> Set fbc.crtc right when scheduling the enable work so we can always
> use it.
> 
> The problem is not what gets passed and how to retrieve it. The
> problem is that when we're in the other parts of the code we always
> have to keep in mind that if FBC is already enabled we have to get the
> CRTC from place A, if FBC is scheduled we have to get the CRTC from
> place B, and if it's disabled there's no CRTC. Having a single place
> to retrieve the CRTC from allows us to treat the "is enabled" and "is
> scheduled" cases as the same case, reducing the mistake surface. I
> guess I should add this to the commit message.
> 
> Besides the immediate advantages, this is also going to make one of
> the next commits much simpler. And even later, when we introduce
> enable/disable + activate/deactivate, this will be even simpler as
> we'll set the CRTC at enable time. So all the
> activate/deactivate/update code can just look at the single CRTC
> variable regardless of the current state.
> 
> v2: Improve commit message (Chris).
> v3: Rebase after changing the patch order.
> 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  1 -
>  drivers/gpu/drm/i915/intel_fbc.c | 22 +-
>  2 files changed, 9 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 71bd1dc..317414b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -920,7 +920,6 @@ struct i915_fbc {
>  
>   struct intel_fbc_work {
>   struct delayed_work work;
> - struct intel_crtc *crtc;
>   struct drm_framebuffer *fb;
>   } *fbc_work;
>  
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> b/drivers/gpu/drm/i915/intel_fbc.c
> index 611672f..bc9cd33 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -334,14 +334,13 @@ bool intel_fbc_enabled(struct drm_i915_private 
> *dev_priv)
>   return dev_priv->fbc.enabled;
>  }
>  
> -static void intel_fbc_enable(struct intel_crtc *crtc,
> -  const struct drm_framebuffer *fb)
> +static void intel_fbc_enable(const struct drm_framebuffer *fb)
>  {
> - struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
> + struct drm_i915_private *dev_priv = fb->dev->dev_private;
> + struct intel_crtc *crtc = dev_priv->fbc.crtc;

This is confusing me. I think of FBC in terms of the CRTC/pipe, and the
fb just describes the plane currently bound to the primary. You've
pushed everywhere else to also work on the CRTC, I think it would be
consistent here to pass crtc and then use fbc.fb_id =
crtc->primary->fb->id.

Have I missed something in the later patches that explains the choice
here?
-Chris

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

Re: [Intel-gfx] [PATCH 09/12] drm/i915: wait for a vblank instead of 50ms when enabling FBC

[Chris Wilson]

On Fri, Nov 13, 2015 at 05:53:41PM -0200, Paulo Zanoni wrote:
> Instead of waiting for 50ms, just wait until the next vblank, since
> it's the minimum requirement.
> 
> This moves PC7 residency on my specific BDW machine running Cinnamon
> from 60-70% to 84-89%. Without FBC, I get 20-25%. I'm using a
> 3200x1800 eDP panel. Notice: this was the case when the patch was
> originally proposed, the order of the FBC patches changed since then,
> so the actual numbers might be slightly different now.
> 
> v2:
>   - Rebase after changing the patch order.
>   - Update the commit message.
> 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  2 +-
>  drivers/gpu/drm/i915/intel_fbc.c | 12 +++-
>  2 files changed, 4 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 9418bd5..ea08714 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -919,9 +919,9 @@ struct i915_fbc {
>  
>   struct intel_fbc_work {
>   bool scheduled;
> + u32 scheduled_vblank;
>   struct work_struct work;
>   struct drm_framebuffer *fb;
> - unsigned long enable_jiffies;
>   } work;
>  
>   const char *no_fbc_reason;
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> b/drivers/gpu/drm/i915/intel_fbc.c
> index aa82075..72de8a1 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -391,7 +391,6 @@ static void intel_fbc_work_fn(struct work_struct *__work)
>   container_of(__work, struct drm_i915_private, fbc.work.work);
>   struct intel_fbc_work *work = _priv->fbc.work;
>   struct intel_crtc *crtc = dev_priv->fbc.crtc;
> - unsigned long delay_jiffies = msecs_to_jiffies(50);
>  
>  retry:
>   /* Delay the actual enabling to let pageflipping cease and the
> @@ -400,14 +399,9 @@ retry:
>* vblank to pass after disabling the FBC before we attempt
>* to modify the control registers.
>*
> -  * A more complicated solution would involve tracking vblanks
> -  * following the termination of the page-flipping sequence
> -  * and indeed performing the enable as a co-routine and not
> -  * waiting synchronously upon the vblank.
> -  *
>* WaFbcWaitForVBlankBeforeEnable:ilk,snb
>*/
> - wait_remaining_ms_from_jiffies(work->enable_jiffies, delay_jiffies);
> + intel_wait_for_vblank(dev_priv->dev, crtc->pipe);
>  
>   mutex_lock(_priv->fbc.lock);
>  
> @@ -416,7 +410,7 @@ retry:
>   goto out;
>  
>   /* Were we delayed again while this function was sleeping? */
> - if (time_after(work->enable_jiffies + delay_jiffies, jiffies)) {
> + if (drm_crtc_vblank_get(>base) == work->scheduled_vblank) {
>   mutex_unlock(_priv->fbc.lock);
>   goto retry;
>   }
> @@ -449,7 +443,7 @@ static void intel_fbc_schedule_activation(struct 
> intel_crtc *crtc)
>* jiffy count. */
>   work->fb = crtc->base.primary->fb;
>   work->scheduled = true;
> - work->enable_jiffies = jiffies;
> + work->scheduled_vblank = drm_crtc_vblank_count(>base);

Isn't the frame counter only incrementing whilst the vblank IRQ is
enabled? Ville?
-Chris

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

Re: [Intel-gfx] [PATCH 03/12] drm/i915: pass the crtc as an argument to intel_fbc_update()

[Chris Wilson]

On Fri, Nov 13, 2015 at 05:53:35PM -0200, Paulo Zanoni wrote:
> There's no need to reevaluate the status of every single crtc when a
> single crtc changes its state.
> 
> With this, we're cutting the case where due to a change in pipe B,
> intel_fbc_update() is called, then intel_fbc_find_crtc() concludes FBC
> should be enabled on pipe A, then it completely rechecks the state of
> pipe A only to conclude FBC should remain enabled on pipe A. If any
> change on pipe A triggers a need to recompute whether FBC is valid on
> pipe A, then at some point someone is going to call
> intel_fbc_update(PIPE_A).
> 
> The addition of intel_fbc_deactivate() is necessary so we keep track
> of the previously selected CRTC when we do invalidate/flush. We're
> also going to continue the enable/disable/activate/deactivate concept
> in the next patches.
> 
> v2: Rebase.
> v3: Rebase after changing the patch order.
> 
> Signed-off-by: Paulo Zanoni 
Reviewed-by: Chris Wilson 
-Chris

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

Re: [Intel-gfx] [PATCH 05/12] drm/i915: introduce intel_fbc_{enable, disable}

[Chris Wilson]

On Fri, Nov 13, 2015 at 05:53:37PM -0200, Paulo Zanoni wrote:
> The goal is to call FBC enable/disable only once per modeset, while
> activate/deactivate/update will be called multiple times.
> 
> The enable() function will be responsible for deciding if a CRTC will
> have FBC on it and then it will "lock" FBC on this CRTC: it won't be
> possible to change FBC's CRTC until disable(). With this, all checks
> and resource acquisition that only need to be done once per modeset
> can be moved from update() to enable(). And then the update(),
> activate() and deactivate() code will also get simpler since they
> won't need to worry about the CRTC being changed.
> 
> The disable() function will do the reverse operation of enable(). One
> of its features is that it should only be called while the pipe is
> already off. This guarantees that FBC is stopped and nothing is
> using the CFB.
> 
> With this, the activate() and deactivate() functions just start and
> temporarily stop FBC. They are the ones touching the hardware enable
> bit, so HW state reflects dev_priv->crtc.active.
> 
> The last function remaining is update(). A lot of times I thought
> about renaming update() to activate() or try_to_activate() since it's
> called when we want to activate FBC. The thing is that update() may
> not only decide to activate FBC, but also deactivate or keep it on the
> same state, so I'll leave this name for now.
> 
> Moving code to enable() and disable() will also help in case we decide
> to move FBC to pipe_config or something else later.
> 
> The current patch only puts the very basic code on enable() and
> disable(). The next commits will take care of moving more stuff from
> update() to the new functions.
> 
> v2:
>   - Rebase.
>   - Improve commit message (Chris).
> v3: Rebase after changing the patch order.
> v4: Rebase again after upstream changes.
> 
> Signed-off-by: Paulo Zanoni 
Reviewed-by: Chris Wilson 
-Chris

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

Re: [Intel-gfx] [PATCH 04/31] drm/i915: Handle actual IPS enabled state.

[Ville Syrjälä]

On Fri, Nov 13, 2015 at 06:55:18PM +, Daniel Stone wrote:
> Hi,
> 
> On 13 November 2015 at 18:38, Ville Syrjälä
>  wrote:
> > On Fri, Nov 13, 2015 at 06:20:00PM +, Daniel Stone wrote:
> >> Maybe that's not the best approach, but I think we need to find a way
> >> to take the synchronous vblank wait out of the modeset path. Using a
> >> workqueue is another option, but synchronisation would need to be
> >> quite carefully handled.
> >
> > Long time ago I posted a patch to make ips enable asynchronously from
> > a vblank work.
> 
> Too long ago for my mail client, it seems ... got a link handy?

http://lists.freedesktop.org/archives/intel-gfx/2014-June/047626.html

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

Re: [Intel-gfx] [PATCH 02/12] drm/i915: set dev_priv->fbc.crtc before scheduling the enable work

[Paulo Zanoni]

2015-11-13 18:56 GMT-02:00 Chris Wilson :
> On Fri, Nov 13, 2015 at 05:53:34PM -0200, Paulo Zanoni wrote:
>> This thing where we need to get the crtc either from the work
>> structure or the fbc structure itself is confusing and unnecessary.
>> Set fbc.crtc right when scheduling the enable work so we can always
>> use it.
>>
>> The problem is not what gets passed and how to retrieve it. The
>> problem is that when we're in the other parts of the code we always
>> have to keep in mind that if FBC is already enabled we have to get the
>> CRTC from place A, if FBC is scheduled we have to get the CRTC from
>> place B, and if it's disabled there's no CRTC. Having a single place
>> to retrieve the CRTC from allows us to treat the "is enabled" and "is
>> scheduled" cases as the same case, reducing the mistake surface. I
>> guess I should add this to the commit message.
>>
>> Besides the immediate advantages, this is also going to make one of
>> the next commits much simpler. And even later, when we introduce
>> enable/disable + activate/deactivate, this will be even simpler as
>> we'll set the CRTC at enable time. So all the
>> activate/deactivate/update code can just look at the single CRTC
>> variable regardless of the current state.
>>
>> v2: Improve commit message (Chris).
>> v3: Rebase after changing the patch order.
>>
>> Signed-off-by: Paulo Zanoni 
>> ---
>>  drivers/gpu/drm/i915/i915_drv.h  |  1 -
>>  drivers/gpu/drm/i915/intel_fbc.c | 22 +-
>>  2 files changed, 9 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 71bd1dc..317414b 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -920,7 +920,6 @@ struct i915_fbc {
>>
>>   struct intel_fbc_work {
>>   struct delayed_work work;
>> - struct intel_crtc *crtc;
>>   struct drm_framebuffer *fb;
>>   } *fbc_work;
>>
>> diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
>> b/drivers/gpu/drm/i915/intel_fbc.c
>> index 611672f..bc9cd33 100644
>> --- a/drivers/gpu/drm/i915/intel_fbc.c
>> +++ b/drivers/gpu/drm/i915/intel_fbc.c
>> @@ -334,14 +334,13 @@ bool intel_fbc_enabled(struct drm_i915_private 
>> *dev_priv)
>>   return dev_priv->fbc.enabled;
>>  }
>>
>> -static void intel_fbc_enable(struct intel_crtc *crtc,
>> -  const struct drm_framebuffer *fb)
>> +static void intel_fbc_enable(const struct drm_framebuffer *fb)
>>  {
>> - struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
>> + struct drm_i915_private *dev_priv = fb->dev->dev_private;
>> + struct intel_crtc *crtc = dev_priv->fbc.crtc;
>
> This is confusing me. I think of FBC in terms of the CRTC/pipe, and the
> fb just describes the plane currently bound to the primary. You've
> pushed everywhere else to also work on the CRTC, I think it would be
> consistent here to pass crtc and then use fbc.fb_id =
> crtc->primary->fb->id.
>
> Have I missed something in the later patches that explains the choice
> here?

You are right that this is confusing. This is basically an artifact
from the previous FBC design that I overlooked. I guess during the
conversion, my thinking was "well, the arguments are the stuff we
store in the work struct, and since we don't store the CRTC anymore,
let's remove it and keep passing the FB since it's still part of the
work struct". Now that you bring this under a different perspective, I
see the problem. We don't even need to pass these things as arguments
since we do check that work->fb is equal to crtc->fb.

I just hope you let me address this with follow-up patches. Function
intel_fbc_activate() was created because there were 2 callers: one for
the case there the work_fn happens, another for the case where we
failed to allocate the work_fn. Later in the series there's only one
caller because there's no allocation anymore, so the best way to fix
is probably to just move those 3 lines to the place of the only
caller.

You also requested me to grab references of fbc.fb_id, and I have some
evil plans to completely kill it, which would even reduce those 3
lines further.

Thanks,
Paulo

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



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

Re: [Intel-gfx] [PATCH 09/12] drm/i915: wait for a vblank instead of 50ms when enabling FBC

[Ville Syrjälä]

On Fri, Nov 13, 2015 at 09:03:43PM +, Chris Wilson wrote:
> On Fri, Nov 13, 2015 at 05:53:41PM -0200, Paulo Zanoni wrote:
> > Instead of waiting for 50ms, just wait until the next vblank, since
> > it's the minimum requirement.
> > 
> > This moves PC7 residency on my specific BDW machine running Cinnamon
> > from 60-70% to 84-89%. Without FBC, I get 20-25%. I'm using a
> > 3200x1800 eDP panel. Notice: this was the case when the patch was
> > originally proposed, the order of the FBC patches changed since then,
> > so the actual numbers might be slightly different now.
> > 
> > v2:
> >   - Rebase after changing the patch order.
> >   - Update the commit message.
> > 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  |  2 +-
> >  drivers/gpu/drm/i915/intel_fbc.c | 12 +++-
> >  2 files changed, 4 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 9418bd5..ea08714 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -919,9 +919,9 @@ struct i915_fbc {
> >  
> > struct intel_fbc_work {
> > bool scheduled;
> > +   u32 scheduled_vblank;
> > struct work_struct work;
> > struct drm_framebuffer *fb;
> > -   unsigned long enable_jiffies;
> > } work;
> >  
> > const char *no_fbc_reason;
> > diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> > b/drivers/gpu/drm/i915/intel_fbc.c
> > index aa82075..72de8a1 100644
> > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > @@ -391,7 +391,6 @@ static void intel_fbc_work_fn(struct work_struct 
> > *__work)
> > container_of(__work, struct drm_i915_private, fbc.work.work);
> > struct intel_fbc_work *work = _priv->fbc.work;
> > struct intel_crtc *crtc = dev_priv->fbc.crtc;
> > -   unsigned long delay_jiffies = msecs_to_jiffies(50);
> >  
> >  retry:
> > /* Delay the actual enabling to let pageflipping cease and the
> > @@ -400,14 +399,9 @@ retry:
> >  * vblank to pass after disabling the FBC before we attempt
> >  * to modify the control registers.
> >  *
> > -* A more complicated solution would involve tracking vblanks
> > -* following the termination of the page-flipping sequence
> > -* and indeed performing the enable as a co-routine and not
> > -* waiting synchronously upon the vblank.
> > -*
> >  * WaFbcWaitForVBlankBeforeEnable:ilk,snb
> >  */
> > -   wait_remaining_ms_from_jiffies(work->enable_jiffies, delay_jiffies);
> > +   intel_wait_for_vblank(dev_priv->dev, crtc->pipe);
> >  
> > mutex_lock(_priv->fbc.lock);
> >  
> > @@ -416,7 +410,7 @@ retry:
> > goto out;
> >  
> > /* Were we delayed again while this function was sleeping? */
> > -   if (time_after(work->enable_jiffies + delay_jiffies, jiffies)) {
> > +   if (drm_crtc_vblank_get(>base) == work->scheduled_vblank) {
> > mutex_unlock(_priv->fbc.lock);
> > goto retry;
> > }
> > @@ -449,7 +443,7 @@ static void intel_fbc_schedule_activation(struct 
> > intel_crtc *crtc)
> >  * jiffy count. */
> > work->fb = crtc->base.primary->fb;
> > work->scheduled = true;
> > -   work->enable_jiffies = jiffies;
> > +   work->scheduled_vblank = drm_crtc_vblank_count(>base);
> 
> Isn't the frame counter only incrementing whilst the vblank IRQ is
> enabled? Ville?

I see a "+ if (drm_crtc_vblank_get(" earlier.

That said, drm_crtc_vblank_count() is racy. The reader may race with
the vblank irq handler after the start of vblank has already been
passed, thus sampling a stale value, and then actually not waiting
until the next vblank.

It's more of a problem on gen2/3 which didn't have the "start of
vblank" interrupt and instead rely on the "frame start" interrupt.
There's at least one (well, almost) scanline between the two events.

I've been meaning to add another function to the vblank code that
could be called between the drm_vblank_get() and drm_crtc_vblank_count()
to make sure the sampled count is really up to date. I'd use that on
gen2 at least since it lacks the hw counter. For the other platforms,
it ought to be easier to just use the hw counter everywhere since
that increments atomically with the start of vblank and doesn't suffer
from this race.

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

Re: [Intel-gfx] [PATCH 09/12] drm/i915: wait for a vblank instead of 50ms when enabling FBC

[Zanoni, Paulo R]

Em Sex, 2015-11-13 às 23:26 +0200, Ville Syrjälä escreveu:
> On Fri, Nov 13, 2015 at 11:20:19PM +0200, Ville Syrjälä wrote:
> > On Fri, Nov 13, 2015 at 09:03:43PM +, Chris Wilson wrote:
> > > On Fri, Nov 13, 2015 at 05:53:41PM -0200, Paulo Zanoni wrote:
> > > > Instead of waiting for 50ms, just wait until the next vblank,
> > > > since
> > > > it's the minimum requirement.
> > > > 
> > > > This moves PC7 residency on my specific BDW machine running
> > > > Cinnamon
> > > > from 60-70% to 84-89%. Without FBC, I get 20-25%. I'm using a
> > > > 3200x1800 eDP panel. Notice: this was the case when the patch
> > > > was
> > > > originally proposed, the order of the FBC patches changed since
> > > > then,
> > > > so the actual numbers might be slightly different now.
> > > > 
> > > > v2:
> > > >   - Rebase after changing the patch order.
> > > >   - Update the commit message.
> > > > 
> > > > Signed-off-by: Paulo Zanoni 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.h  |  2 +-
> > > >  drivers/gpu/drm/i915/intel_fbc.c | 12 +++-
> > > >  2 files changed, 4 insertions(+), 10 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index 9418bd5..ea08714 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -919,9 +919,9 @@ struct i915_fbc {
> > > >  
> > > >     struct intel_fbc_work {
> > > >     bool scheduled;
> > > > +   u32 scheduled_vblank;
> > > >     struct work_struct work;
> > > >     struct drm_framebuffer *fb;
> > > > -   unsigned long enable_jiffies;
> > > >     } work;
> > > >  
> > > >     const char *no_fbc_reason;
> > > > diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> > > > b/drivers/gpu/drm/i915/intel_fbc.c
> > > > index aa82075..72de8a1 100644
> > > > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > > > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > > > @@ -391,7 +391,6 @@ static void intel_fbc_work_fn(struct
> > > > work_struct *__work)
> > > >     container_of(__work, struct drm_i915_private,
> > > > fbc.work.work);
> > > >     struct intel_fbc_work *work = _priv->fbc.work;
> > > >     struct intel_crtc *crtc = dev_priv->fbc.crtc;
> > > > -   unsigned long delay_jiffies = msecs_to_jiffies(50);
> > > >  
> > > >  retry:
> > > >     /* Delay the actual enabling to let pageflipping cease
> > > > and the
> > > > @@ -400,14 +399,9 @@ retry:
> > > >      * vblank to pass after disabling the FBC before we
> > > > attempt
> > > >      * to modify the control registers.
> > > >      *
> > > > -    * A more complicated solution would involve tracking
> > > > vblanks
> > > > -    * following the termination of the page-flipping
> > > > sequence
> > > > -    * and indeed performing the enable as a co-routine
> > > > and not
> > > > -    * waiting synchronously upon the vblank.
> > > > -    *
> > > >      * WaFbcWaitForVBlankBeforeEnable:ilk,snb
> > > >      */
> > > > -   wait_remaining_ms_from_jiffies(work->enable_jiffies,
> > > > delay_jiffies);
> > > > +   intel_wait_for_vblank(dev_priv->dev, crtc->pipe);
> > > >  
> > > >     mutex_lock(_priv->fbc.lock);
> > > >  
> > > > @@ -416,7 +410,7 @@ retry:
> > > >     goto out;
> > > >  
> > > >     /* Were we delayed again while this function was
> > > > sleeping? */
> > > > -   if (time_after(work->enable_jiffies + delay_jiffies,
> > > > jiffies)) {
> > > > +   if (drm_crtc_vblank_get(>base) == work-
> > > > >scheduled_vblank) {
> > > >     mutex_unlock(_priv->fbc.lock);
> > > >     goto retry;
> > > >     }
> > > > @@ -449,7 +443,7 @@ static void
> > > > intel_fbc_schedule_activation(struct intel_crtc *crtc)
> > > >      * jiffy count. */
> > > >     work->fb = crtc->base.primary->fb;
> > > >     work->scheduled = true;
> > > > -   work->enable_jiffies = jiffies;
> > > > +   work->scheduled_vblank = drm_crtc_vblank_count(
> > > > >base);
> > > 
> > > Isn't the frame counter only incrementing whilst the vblank IRQ
> > > is
> > > enabled? Ville?
> > 
> > I see a "+ if (drm_crtc_vblank_get(" earlier.
> 
> Hmm. Actually it's doing
> "drm_crtc_vblank_get(>base) == work->scheduled_vblank)"
> which looks rather like nonsense.
> 
> Not sure what the intention here was...

Ouch. The intent was for that to be another call for
drm_crtc_vblank_count().

The code in discussion is completely based on the drm_wait_one_vblank()
code: call drm_vblank_count(), then call it again until it returns
something different. The difference is that we actually call
drm_wait_one_vblank() in the middle of the process, and that
scheduled_vblank may also be updated in the meantime, so so may have to
call drm_wait_one_vblank() again.

> 
___
Intel-gfx mailing list

Re: [Intel-gfx] [PATCH 02/12] drm/i915: set dev_priv->fbc.crtc before scheduling the enable work

[Chris Wilson]

On Fri, Nov 13, 2015 at 07:13:40PM -0200, Paulo Zanoni wrote:
> 2015-11-13 18:56 GMT-02:00 Chris Wilson :
> > On Fri, Nov 13, 2015 at 05:53:34PM -0200, Paulo Zanoni wrote:
> >> This thing where we need to get the crtc either from the work
> >> structure or the fbc structure itself is confusing and unnecessary.
> >> Set fbc.crtc right when scheduling the enable work so we can always
> >> use it.
> >>
> >> The problem is not what gets passed and how to retrieve it. The
> >> problem is that when we're in the other parts of the code we always
> >> have to keep in mind that if FBC is already enabled we have to get the
> >> CRTC from place A, if FBC is scheduled we have to get the CRTC from
> >> place B, and if it's disabled there's no CRTC. Having a single place
> >> to retrieve the CRTC from allows us to treat the "is enabled" and "is
> >> scheduled" cases as the same case, reducing the mistake surface. I
> >> guess I should add this to the commit message.
> >>
> >> Besides the immediate advantages, this is also going to make one of
> >> the next commits much simpler. And even later, when we introduce
> >> enable/disable + activate/deactivate, this will be even simpler as
> >> we'll set the CRTC at enable time. So all the
> >> activate/deactivate/update code can just look at the single CRTC
> >> variable regardless of the current state.
> >>
> >> v2: Improve commit message (Chris).
> >> v3: Rebase after changing the patch order.
> >>
> >> Signed-off-by: Paulo Zanoni 
> >> ---
> >>  drivers/gpu/drm/i915/i915_drv.h  |  1 -
> >>  drivers/gpu/drm/i915/intel_fbc.c | 22 +-
> >>  2 files changed, 9 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >> b/drivers/gpu/drm/i915/i915_drv.h
> >> index 71bd1dc..317414b 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.h
> >> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> @@ -920,7 +920,6 @@ struct i915_fbc {
> >>
> >>   struct intel_fbc_work {
> >>   struct delayed_work work;
> >> - struct intel_crtc *crtc;
> >>   struct drm_framebuffer *fb;
> >>   } *fbc_work;
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> >> b/drivers/gpu/drm/i915/intel_fbc.c
> >> index 611672f..bc9cd33 100644
> >> --- a/drivers/gpu/drm/i915/intel_fbc.c
> >> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> >> @@ -334,14 +334,13 @@ bool intel_fbc_enabled(struct drm_i915_private 
> >> *dev_priv)
> >>   return dev_priv->fbc.enabled;
> >>  }
> >>
> >> -static void intel_fbc_enable(struct intel_crtc *crtc,
> >> -  const struct drm_framebuffer *fb)
> >> +static void intel_fbc_enable(const struct drm_framebuffer *fb)
> >>  {
> >> - struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
> >> + struct drm_i915_private *dev_priv = fb->dev->dev_private;
> >> + struct intel_crtc *crtc = dev_priv->fbc.crtc;
> >
> > This is confusing me. I think of FBC in terms of the CRTC/pipe, and the
> > fb just describes the plane currently bound to the primary. You've
> > pushed everywhere else to also work on the CRTC, I think it would be
> > consistent here to pass crtc and then use fbc.fb_id =
> > crtc->primary->fb->id.
> >
> > Have I missed something in the later patches that explains the choice
> > here?
> 
> You are right that this is confusing. This is basically an artifact
> from the previous FBC design that I overlooked. I guess during the
> conversion, my thinking was "well, the arguments are the stuff we
> store in the work struct, and since we don't store the CRTC anymore,
> let's remove it and keep passing the FB since it's still part of the
> work struct". Now that you bring this under a different perspective, I
> see the problem. We don't even need to pass these things as arguments
> since we do check that work->fb is equal to crtc->fb.
> 
> I just hope you let me address this with follow-up patches. Function
> intel_fbc_activate() was created because there were 2 callers: one for
> the case there the work_fn happens, another for the case where we
> failed to allocate the work_fn. Later in the series there's only one
> caller because there's no allocation anymore, so the best way to fix
> is probably to just move those 3 lines to the place of the only
> caller.
> 
> You also requested me to grab references of fbc.fb_id, and I have some
> evil plans to completely kill it, which would even reduce those 3
> lines further.

If you have it in hand, the rest seems fine, so
Reviewed-by: Chris Wilson 
-Chris

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

Re: [Intel-gfx] [PATCH 01/12] drm/i915: fix the CFB size check

[Chris Wilson]

On Fri, Nov 13, 2015 at 05:53:33PM -0200, Paulo Zanoni wrote:
> In function find_compression_threshold() we try to over-allocate CFB
> space in order to reduce reallocations and fragmentation, and we're
> not considering that at the CFB size check. Consider it.
> 
> There is also a longer-term plan to kill
> dev_priv->fbc.uncompressed_size, but this will come later.
> 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_fbc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> b/drivers/gpu/drm/i915/intel_fbc.c
> index 11fc528..611672f 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -720,7 +720,8 @@ static int intel_fbc_setup_cfb(struct intel_crtc *crtc)
>   size = intel_fbc_calculate_cfb_size(crtc);
>   cpp = drm_format_plane_cpp(fb->pixel_format, 0);
>  
> - if (size <= dev_priv->fbc.uncompressed_size)
> + if (dev_priv->fbc.compressed_fb.allocated &&
> + size <= dev_priv->fbc.compressed_fb.size * dev_priv->fbc.threshold)
>   return 0;

Hmm, not sure if it would be worth just clearing compressed_fb.size after
remove.

But at any rate, you want to use
drm_mm_node_allocated(_fb).

With that minor change,
Reviewed-by: Chris Wilson 
-Chris

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

Re: [Intel-gfx] [PATCH 12/12] drm/i915: only nuke FBC when a drawing operation triggers a flush

[Chris Wilson]

On Fri, Nov 13, 2015 at 05:53:44PM -0200, Paulo Zanoni wrote:

drm/i915: Only trigger a FBC recompress after flushing a drawing operation

> There's no need to stop and restart FBC: a nuke should be fine.

There's no need to stop and restart FBC, which is quite expensive as we
have to revalidate the CRTC state and reallocate resources, after flushing
a drawing operation (as the CRTC state hasn't changed). A nuke (recompress)
should be fine.

> v2: Make it simpler (Chris).
> v3: Rewrite the patch again due to patch order changes.
> 
> Signed-off-by: Paulo Zanoni 

If you can make the changelog understandable,
Reviewed-by: Chris Wilson 
-Chris

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

Re: [Intel-gfx] [PATCH 09/12] drm/i915: wait for a vblank instead of 50ms when enabling FBC

[Ville Syrjälä]

On Fri, Nov 13, 2015 at 09:38:50PM +, Zanoni, Paulo R wrote:
> Em Sex, 2015-11-13 às 23:26 +0200, Ville Syrjälä escreveu:
> > On Fri, Nov 13, 2015 at 11:20:19PM +0200, Ville Syrjälä wrote:
> > > On Fri, Nov 13, 2015 at 09:03:43PM +, Chris Wilson wrote:
> > > > On Fri, Nov 13, 2015 at 05:53:41PM -0200, Paulo Zanoni wrote:
> > > > > Instead of waiting for 50ms, just wait until the next vblank,
> > > > > since
> > > > > it's the minimum requirement.
> > > > > 
> > > > > This moves PC7 residency on my specific BDW machine running
> > > > > Cinnamon
> > > > > from 60-70% to 84-89%. Without FBC, I get 20-25%. I'm using a
> > > > > 3200x1800 eDP panel. Notice: this was the case when the patch
> > > > > was
> > > > > originally proposed, the order of the FBC patches changed since
> > > > > then,
> > > > > so the actual numbers might be slightly different now.
> > > > > 
> > > > > v2:
> > > > >   - Rebase after changing the patch order.
> > > > >   - Update the commit message.
> > > > > 
> > > > > Signed-off-by: Paulo Zanoni 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/i915_drv.h  |  2 +-
> > > > >  drivers/gpu/drm/i915/intel_fbc.c | 12 +++-
> > > > >  2 files changed, 4 insertions(+), 10 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > > index 9418bd5..ea08714 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > @@ -919,9 +919,9 @@ struct i915_fbc {
> > > > >  
> > > > >   struct intel_fbc_work {
> > > > >   bool scheduled;
> > > > > + u32 scheduled_vblank;
> > > > >   struct work_struct work;
> > > > >   struct drm_framebuffer *fb;
> > > > > - unsigned long enable_jiffies;
> > > > >   } work;
> > > > >  
> > > > >   const char *no_fbc_reason;
> > > > > diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> > > > > b/drivers/gpu/drm/i915/intel_fbc.c
> > > > > index aa82075..72de8a1 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > > > > @@ -391,7 +391,6 @@ static void intel_fbc_work_fn(struct
> > > > > work_struct *__work)
> > > > >   container_of(__work, struct drm_i915_private,
> > > > > fbc.work.work);
> > > > >   struct intel_fbc_work *work = _priv->fbc.work;
> > > > >   struct intel_crtc *crtc = dev_priv->fbc.crtc;
> > > > > - unsigned long delay_jiffies = msecs_to_jiffies(50);
> > > > >  
> > > > >  retry:
> > > > >   /* Delay the actual enabling to let pageflipping cease
> > > > > and the
> > > > > @@ -400,14 +399,9 @@ retry:
> > > > >    * vblank to pass after disabling the FBC before we
> > > > > attempt
> > > > >    * to modify the control registers.
> > > > >    *
> > > > > -  * A more complicated solution would involve tracking
> > > > > vblanks
> > > > > -  * following the termination of the page-flipping
> > > > > sequence
> > > > > -  * and indeed performing the enable as a co-routine
> > > > > and not
> > > > > -  * waiting synchronously upon the vblank.
> > > > > -  *
> > > > >    * WaFbcWaitForVBlankBeforeEnable:ilk,snb
> > > > >    */
> > > > > - wait_remaining_ms_from_jiffies(work->enable_jiffies,
> > > > > delay_jiffies);
> > > > > + intel_wait_for_vblank(dev_priv->dev, crtc->pipe);
> > > > >  
> > > > >   mutex_lock(_priv->fbc.lock);
> > > > >  
> > > > > @@ -416,7 +410,7 @@ retry:
> > > > >   goto out;
> > > > >  
> > > > >   /* Were we delayed again while this function was
> > > > > sleeping? */
> > > > > - if (time_after(work->enable_jiffies + delay_jiffies,
> > > > > jiffies)) {
> > > > > + if (drm_crtc_vblank_get(>base) == work-
> > > > > >scheduled_vblank) {
> > > > >   mutex_unlock(_priv->fbc.lock);
> > > > >   goto retry;
> > > > >   }
> > > > > @@ -449,7 +443,7 @@ static void
> > > > > intel_fbc_schedule_activation(struct intel_crtc *crtc)
> > > > >    * jiffy count. */
> > > > >   work->fb = crtc->base.primary->fb;
> > > > >   work->scheduled = true;
> > > > > - work->enable_jiffies = jiffies;
> > > > > + work->scheduled_vblank = drm_crtc_vblank_count(
> > > > > >base);
> > > > 
> > > > Isn't the frame counter only incrementing whilst the vblank IRQ
> > > > is
> > > > enabled? Ville?
> > > 
> > > I see a "+ if (drm_crtc_vblank_get(" earlier.
> > 
> > Hmm. Actually it's doing
> > "drm_crtc_vblank_get(>base) == work->scheduled_vblank)"
> > which looks rather like nonsense.
> > 
> > Not sure what the intention here was...
> 
> Ouch. The intent was for that to be another call for
> drm_crtc_vblank_count().
> 
> The code in discussion is completely based on the drm_wait_one_vblank()
> code: call drm_vblank_count(), then call it again until it returns
> something different. The difference is that we actually call
> 

[Intel-gfx] [Regression report] Weekly regression report WW46

[jairo . daniel . miramontes . caton]

WW46 Regression report

There was no new reported regressions this week.


Actual Regressions:
+---+---+++
| BugId | Summary   | Created on | Bisect |
+---+---+++
| 72782 | [945GM bisected] screen blank on S3 resume on | 2013-12-17 | Yes|
| 81537 | [snb dp regression] dp retry forever due to s | 2014-07-19 | No |
| 84855 | [ILK regression]igt kms_rotation_crc/sprite-r | 2014-10-10 | No |
| 84974 | [VLV eDP-LVDS bisected] powerdomains: Screen  | 2014-10-14 | Yes|
| 87131 | [PNV regression] igt/gem_exec_lut_handle take | 2014-12-09 | No |
| 87480 | [SNB/IVB/HSW/BYT bisected]igt/kms_force_conne | 2014-12-19 | Yes|
| 87662 | [ALL 3.18 Bisected] DVI --rotation inverted c | 2014-12-24 | Yes|
| 87725 | [BDW Bisected] OglBatch7 performance reduced  | 2014-12-26 | Yes|
| 87726 | [BDW Bisected] OglDrvCtx performance reduced  | 2014-12-26 | Yes|
| 88012 | [bisected BYT] complete freeze after: drm/i91 | 2015-01-04 | Yes|
| 88124 | i915: regression: after DP connected monitor  | 2015-01-06 | No |
| 88325 | screen brightness regression on resume| 2015-01-12 | No |
| 88439 | [BDW Bisected]igt/gem_reloc_vs_gpu/forked-fau | 2015-01-15 | Yes|
| 89334 | [945 regression] 4.0-rc1 kernel GPU hang:  ec | 2015-02-26 | No |
| 89629 | [i965 regression]igt/kms_rotation_crc/sprite- | 2015-03-18 | No |
| 89632 | [i965 regression]igt/kms_universal_plane/univ | 2015-03-18 | No |
| 89728 | [HSW/BDW/BSW/SKL bisected] igt/pm_rps/ subcas | 2015-03-23 | Yes|
| 89872 | [ HSW Bisected ] VGA was white screen when re | 2015-04-02 | Yes|
| 90112 | [BSW bisected] OglGSCloth/Lightsmark/CS/ Port | 2015-04-20 | Yes|
| 90134 | [BSW Bisected]GFXBench3_gl_driver/GFXBench3_g | 2015-04-22 | Yes|
| 90368 | [SNB bisected igt/kms_3d has hardcoded expect | 2015-05-08 | Yes|
| 90546 | [HSW/BDW/BSW/SKL bisected]igt/pm_rpm/drm-reso | 2015-05-21 | Yes|
| 90732 | [BDW/BSW Bisected]igt/gem_reloc_vs_gpu/forked | 2015-05-29 | Yes|
| 90808 | [BDW Bisected]igt/gem_ctx_param_basic/invalid | 2015-06-02 | Yes|
| 90994 | [BDW regression] pm_rpm subtests fail and giv | 2015-06-16 | No |
| 91378 | [hsw dp regression] 06ea66b6 (5.4GHz link clo | 2015-07-17 | No |
| 91592 | [pnv regression] OOPS on boot | 2015-08-09 | No |
| 91844 | [HSW Regression] intel_do_flush_locked failed | 2015-09-02 | No |
| 91952 | [Bisected Regression] Blank screen from boot  | 2015-09-10 | Yes|
| 91959 | [865g 3.19 regression] Desktop image is disto | 2015-09-10 | No |
| 91974 | [bisected] unrecoverable black screen after k | 2015-09-11 | Yes|
| 92050 | [regression]/bug introduced by commit [0e572f | 2015-09-19 | No |
| 92083 | [regression] [git pull] drm for 4.3   | 2015-09-23 | No |
| 92096 | regression/bug introduced by commit [0e572fe7 | 2015-09-24 | No |
| 92174 | PROBLEM: Intel VGA output busticated on 4.3-r | 2015-09-29 | No |
| 92211 | [All Regression] [IGT Basic] igt/pm_rpm/basic | 2015-10-01 | No |
| 92237 | Horrible noise (audio) via DisplayPort [regre | 2015-10-02 | No |
| 92355 | [SKL Regression] igt/kms_fbc_crc cause DUT cr | 2015-10-09 | No |
| 92414 | [Intel-gfx] As of kernel 4.3-rc1 system will  | 2015-10-10 | Yes|
| 92483 | [regression] Can only go to console (fbcon/fb | 2015-10-15 | No |
| 92502 | [SKL] [Regression] igt/kms_flip/2x-flip-vs-ex | 2015-10-16 | No |
| 92575 | [4.2 regression] Massive graphics corruption  | 2015-10-21 | No |
| 92655 | [i915] LVDS screen half garbled. unable to bi | 2015-10-23 | Yes|
| 92707 | [BSW] [IGT Basic] [Regression] igt / pm_backl | 2015-10-28 | No |
| 92718 | [REGRESSION] 4.3.0-rc7 - Multiple identical k | 2015-10-29 | No |
| 92737 | [SKL BSW] [Regression] [IGT Basic] igt/gem_ct | 2015-10-30 | No |
+---+---+++
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] igt/igt_kms: Introduce get_first_connected_output (v2)

[Vivek Kasireddy]

On Fri, 13 Nov 2015 15:59:21 +
Thomas Wood  wrote:

> On 5 November 2015 at 01:34, Vivek Kasireddy
>  wrote:
> > In some cases, we just need one valid (connected) output to perform
> > a test. This macro can help in these situations by not having to
> > put the test code inside a for loop that iterates over all the
> > outputs.
> >
> > v2: Added a brief documentation for this macro.
> 
> The new macro is no longer being used anywhere. Is there a new patch
> that uses the macro?
> 

Hi Thomas,
I wanted to have this patch merged before I updated the tests to use
the macro.

> 
> Also, if re-sending the patch, please make sure it is tagged correctly
> as described in:
> 
> http://lists.freedesktop.org/archives/intel-gfx/2015-November/079712.html
> 
> This also explains how to manage the version tag in the subject line.

Thanks for the link; I wasn't aware of it. Do you want me to resend the
patch in this format?

Thanks and Regards,
Vivek

> 
> 
> >
> > Suggested-by: Matt Roper 
> > Cc: Thomas Wood 
> > Signed-off-by: Vivek Kasireddy 
> > ---
> >  lib/igt_kms.h | 12 
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/lib/igt_kms.h b/lib/igt_kms.h
> > index 09c08aa..91fa206 100644
> > --- a/lib/igt_kms.h
> > +++ b/lib/igt_kms.h
> > @@ -278,6 +278,18 @@ void igt_wait_for_vblank(int drm_fd, enum pipe
> > pipe); for (int i__ = 0; (plane) =
> > &(display)->pipes[(pipe)].planes[i__], \ i__ <
> > (display)->pipes[(pipe)].n_planes; i__++)
> >
> > +/**
> > + * get_first_connected_output:
> > + * @display: Initialized igt_display_t type object
> > + * @output: igt_output_t type object
> > + *
> > + * Returns: First valid (connected) output.
> > + */
> > +#define get_first_connected_output(display, output)\
> > +   for (int i__ = 0;  i__ < (display)->n_outputs; i__++)   \
> > +   if ((output = &(display)->outputs[i__]),
> > output->valid) \
> > +   break
> > +
> >  /*
> >   * Can be used with igt_output_set_pipe() to mean we don't care
> > about the pipe
> >   * that should drive this output
> > --
> > 2.4.3
> >

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

[Intel-gfx] [PATCH] drm/i915: PSR: Let's rely more on frontbuffer tracking.

[Rodrigo Vivi]

The ultimate goal here is to remove the dependency we
currently have on audio driver power to get PSR working.

With audio driver runtime PM disabled the Hardware tracking
believes graphics is fully active and prevent PSR Entry, or
in other words continuously exit PSR.

When we introduced PSR we let LPSP masked allowing us
to get PSR independtly from the audio runtime PM. However
in one of the attempts to get PSR enabled by default one
user reported one specific case where he would miss
screen updates if scrolling the firefox in a Gnome
environment when i915 runtime pm was enabled. So for
this specific case that (I could never create an i-g-t
test case) we decided to remove the LPSP mask and
let HW tracking taking care of this case. So, we
started depending on audio driver again.

An alternative solution that makes us indepent and also
solve this case is to fully rely on our frontbuffer
tracking that is really mature right now.

From the frontbuffer tracking perspective the flush means
invalidate and flush. But without this patch for HSW, BDW
and SKL we just do the invalidate part when the flush wasn't
originated by a page flip because we were trusting the HW
tracking for the flip case, that is exactly the case with
firefox scrolling on gnome.

So let's rely more on frontbuffer tracking and do the
invalidation regardless the origin as expected and for
all platforms.

v2: Improve commit message as suggested by Paulo.

Cc: Paulo Zanoni 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_psr.c | 22 +++---
 1 file changed, 3 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index e5b3fce..b0e343c 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -711,25 +711,9 @@ void intel_psr_flush(struct drm_device *dev,
frontbuffer_bits &= INTEL_FRONTBUFFER_ALL_MASK(pipe);
dev_priv->psr.busy_frontbuffer_bits &= ~frontbuffer_bits;
 
-   if (HAS_DDI(dev)) {
-   /*
-* By definition every flush should mean invalidate + flush,
-* however on core platforms let's minimize the
-* disable/re-enable so we can avoid the invalidate when flip
-* originated the flush.
-*/
-   if (frontbuffer_bits && origin != ORIGIN_FLIP)
-   intel_psr_exit(dev);
-   } else {
-   /*
-* On Valleyview and Cherryview we don't use hardware tracking
-* so any plane updates or cursor moves don't result in a PSR
-* invalidating. Which means we need to manually fake this in
-* software for all flushes.
-*/
-   if (frontbuffer_bits)
-   intel_psr_exit(dev);
-   }
+   /* By definition flush = invalidate + flush */
+   if (frontbuffer_bits)
+   intel_psr_exit(dev);
 
if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits)
schedule_delayed_work(_priv->psr.work,
-- 
2.4.3

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

[Intel-gfx] [PATCH igt] tools/aubdump: Link with -ldl.

[Matt Turner]

aubdump.c uses dlsym(), so it needs to link with -ldl. Otherwise:

/bin/sh: symbol lookup error: /usr/lib64/intel_aubdump.so: undefined symbol: 
dlsym

Signed-off-by: Matt Turner 
---
 tools/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/Makefile.am b/tools/Makefile.am
index 8e454b4..90a8ec1 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -14,7 +14,7 @@ module_LTLIBRARIES = intel_aubdump.la
 moduledir = $(libdir)
 intel_aubdump_la_LDFLAGS = -module -avoid-version -no-undefined
 intel_aubdump_la_SOURCES = aubdump.c intel_aub.h
-intel_aubdump_la_LIBADD = $(top_builddir)/lib/libintel_tools.la
+intel_aubdump_la_LIBADD = $(top_builddir)/lib/libintel_tools.la -ldl
 
 bin_SCRIPTS = intel_aubdump
 CLEANFILES = $(bin_SCRIPTS)
-- 
2.4.9

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

Re: [Intel-gfx] [PATCH 10/10] drm/i915/skl: remove redundant DDI/IRQ reinitialization during PW1 enabling

[Patrik Jakobsson]

On Wed, Nov 04, 2015 at 07:24:19PM +0200, Imre Deak wrote:
> We don't need to reinit DDI and IRQs during PW1 enabling any more, since
> we don't toggle PW1 on-demand any more. We enable PW1 only as part of
> the display core init sequence and after this we initialize both DDI and
> IRQs later in the init sequence. So remove these init steps from the
> power well code.
> 
> Signed-off-by: Imre Deak 

Reviewed-by: Patrik Jakobsson 

> ---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 3d500e1d..5a36dd5 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -244,12 +244,6 @@ static void skl_power_well_post_enable(struct 
> drm_i915_private *dev_priv,
>   gen8_irq_power_well_post_enable(dev_priv,
>   1 << PIPE_C | 1 << PIPE_B);
>   }
> -
> - if (power_well->data == SKL_DISP_PW_1) {
> - if (!dev_priv->power_domains.initializing)
> - intel_prepare_ddi(dev);
> - gen8_irq_power_well_post_enable(dev_priv, 1 << PIPE_A);
> - }
>  }
>  
>  static void hsw_set_power_well(struct drm_i915_private *dev_priv,
> -- 
> 2.1.4
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 09/10] drm/i915/skl: make sure LCPLL is disabled when uniniting CDCLK

[Patrik Jakobsson]

On Wed, Nov 04, 2015 at 07:24:18PM +0200, Imre Deak wrote:
> Suppressing LCPLL disabling was added to avoid interfering with the DMC
> firmware. It is not needed any more since we uninit CDCLK now with the
> DMC deactivated (DC states disabled). We also must disable it during system
> suspend as part of the Bspec "Display uninit sequence".
> 
> Signed-off-by: Imre Deak 

Reviewed-by: Patrik Jakobsson 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 14 --
>  1 file changed, 4 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index d9ed128..d0fec07 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5691,16 +5691,10 @@ void skl_uninit_cdclk(struct drm_i915_private 
> *dev_priv)
>   if (I915_READ(DBUF_CTL) & DBUF_POWER_STATE)
>   DRM_ERROR("DBuf power disable timeout\n");
>  
> - /*
> -  * DMC assumes ownership of LCPLL and will get confused if we touch it.
> -  */
> - if (dev_priv->csr.dmc_payload) {
> - /* disable DPLL0 */
> - I915_WRITE(LCPLL1_CTL, I915_READ(LCPLL1_CTL) &
> - ~LCPLL_PLL_ENABLE);
> - if (wait_for(!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_LOCK), 1))
> - DRM_ERROR("Couldn't disable DPLL0\n");
> - }
> + /* disable DPLL0 */
> + I915_WRITE(LCPLL1_CTL, I915_READ(LCPLL1_CTL) & ~LCPLL_PLL_ENABLE);
> + if (wait_for(!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_LOCK), 1))
> + DRM_ERROR("Couldn't disable DPLL0\n");
>  }
>  
>  void skl_init_cdclk(struct drm_i915_private *dev_priv)
> -- 
> 2.1.4
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx