[Intel-gfx] [PATCH 2/3] drm/i915: eDP Panel Power sequencing PP_DIV register changes

[Vandana Kannan]

BXT does not have PP_DIV register. Making changes to handle this.

Signed-off-by: Vandana Kannan 
Signed-off-by: Kumar, Mahesh 
---
 drivers/gpu/drm/i915/i915_reg.h |  2 ++
 drivers/gpu/drm/i915/i915_suspend.c |  8 --
 drivers/gpu/drm/i915/intel_dp.c | 56 +
 3 files changed, 52 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 36805b6..580f5cb 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6315,6 +6315,8 @@ enum skl_disp_power_wells {
 #define PCH_PP_CONTROL 0xc7204
 #define  PANEL_UNLOCK_REGS (0xabcd << 16)
 #define  PANEL_UNLOCK_MASK (0x << 16)
+#define  BXT_POWER_CYCLE_DELAY_MASK(0x1f0)
+#define  BXT_POWER_CYCLE_DELAY_SHIFT   4
 #define  EDP_FORCE_VDD (1 << 3)
 #define  EDP_BLC_ENABLE(1 << 2)
 #define  PANEL_POWER_RESET (1 << 1)
diff --git a/drivers/gpu/drm/i915/i915_suspend.c 
b/drivers/gpu/drm/i915/i915_suspend.c
index e91d637..24e0b06 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -48,7 +48,9 @@ static void i915_save_display(struct drm_device *dev)
dev_priv->regfile.savePP_CONTROL = I915_READ(PCH_PP_CONTROL);
dev_priv->regfile.savePP_ON_DELAYS = 
I915_READ(PCH_PP_ON_DELAYS);
dev_priv->regfile.savePP_OFF_DELAYS = 
I915_READ(PCH_PP_OFF_DELAYS);
-   dev_priv->regfile.savePP_DIVISOR = I915_READ(PCH_PP_DIVISOR);
+   if (!IS_BROXTON(dev))
+   dev_priv->regfile.savePP_DIVISOR =
+   I915_READ(PCH_PP_DIVISOR);
} else if (!IS_VALLEYVIEW(dev)) {
dev_priv->regfile.savePP_CONTROL = I915_READ(PP_CONTROL);
dev_priv->regfile.savePP_ON_DELAYS = I915_READ(PP_ON_DELAYS);
@@ -82,7 +84,9 @@ static void i915_restore_display(struct drm_device *dev)
if (!HAS_GMCH_DISPLAY(dev)) {
I915_WRITE(PCH_PP_ON_DELAYS, 
dev_priv->regfile.savePP_ON_DELAYS);
I915_WRITE(PCH_PP_OFF_DELAYS, 
dev_priv->regfile.savePP_OFF_DELAYS);
-   I915_WRITE(PCH_PP_DIVISOR, dev_priv->regfile.savePP_DIVISOR);
+   if (!IS_BROXTON(dev))
+   I915_WRITE(PCH_PP_DIVISOR,
+   dev_priv->regfile.savePP_DIVISOR);
I915_WRITE(PCH_PP_CONTROL, dev_priv->regfile.savePP_CONTROL);
} else if (!IS_VALLEYVIEW(dev)) {
I915_WRITE(PP_ON_DELAYS, dev_priv->regfile.savePP_ON_DELAYS);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 68e10c1..37514d3 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4954,8 +4954,8 @@ intel_dp_init_panel_power_sequencer(struct drm_device 
*dev,
struct drm_i915_private *dev_priv = dev->dev_private;
struct edp_power_seq cur, vbt, spec,
*final = &intel_dp->pps_delays;
-   u32 pp_on, pp_off, pp_div, pp;
-   int pp_ctrl_reg, pp_on_reg, pp_off_reg, pp_div_reg;
+   u32 pp_on, pp_off, pp_div = 0, pp_ctl = 0, pp;
+   int pp_ctrl_reg, pp_on_reg, pp_off_reg, pp_div_reg = 0;
 
lockdep_assert_held(&dev_priv->pps_mutex);
 
@@ -4964,10 +4964,16 @@ intel_dp_init_panel_power_sequencer(struct drm_device 
*dev,
return;
 
if (!HAS_GMCH_DISPLAY(dev)) {
+   /*
+* TODO: BXT has 2 sets of PPS registers.
+* Correct Register for Broxton need to be identified
+* using VBT. hardcoding for now
+*/
pp_ctrl_reg = PCH_PP_CONTROL;
pp_on_reg = PCH_PP_ON_DELAYS;
pp_off_reg = PCH_PP_OFF_DELAYS;
-   pp_div_reg = PCH_PP_DIVISOR;
+   if (!IS_BROXTON(dev))
+   pp_div_reg = PCH_PP_DIVISOR;
} else {
enum pipe pipe = vlv_power_sequencer_pipe(intel_dp);
 
@@ -4984,7 +4990,10 @@ intel_dp_init_panel_power_sequencer(struct drm_device 
*dev,
 
pp_on = I915_READ(pp_on_reg);
pp_off = I915_READ(pp_off_reg);
-   pp_div = I915_READ(pp_div_reg);
+   if (!IS_BROXTON(dev))
+   pp_div = I915_READ(pp_div_reg);
+   else
+   pp_ctl = I915_READ(pp_ctrl_reg);
 
/* Pull timing values out of registers */
cur.t1_t3 = (pp_on & PANEL_POWER_UP_DELAY_MASK) >>
@@ -4999,8 +5008,12 @@ intel_dp_init_panel_power_sequencer(struct drm_device 
*dev,
cur.t10 = (pp_off & PANEL_POWER_DOWN_DELAY_MASK) >>
PANEL_POWER_DOWN_DELAY_SHIFT;
 
-   cur.t11_t12 = ((pp_div & PANEL_POWER_CYCLE_DELAY_MASK) >>
-  PANEL_POWER_CYCLE_DELAY_SHIFT) * 1000;
+   if (IS_BROXTON(dev))
+   cur.t11_t12 = (((pp_ctl & BXT_POWER_CYCLE_DELAY_MASK) >>
+   BXT_POWER_CYCLE_DELAY_SHIFT) - 1) * 1000;
+   else

[Intel-gfx] [PATCH 3/3] drm/i915: eDP Panel Power sequencing add PPS reg set

[Vandana Kannan]

Second set of PPS registers have been defined but will be used when VBT
provides a selection between the 2 sets of registers.

Signed-off-by: Vandana Kannan 
Signed-off-by: A.Sunil Kamath 
---
 drivers/gpu/drm/i915/i915_reg.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 580f5cb..199a1747 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6345,6 +6345,12 @@ enum skl_disp_power_wells {
 #define  PANEL_POWER_CYCLE_DELAY_MASK  (0x1f)
 #define  PANEL_POWER_CYCLE_DELAY_SHIFT 0
 
+/* BXT PPS changes - 2nd set of PPS registers */
+#define BXT_PP_STATUS2 0xc7300
+#define BXT_PP_CONTROL20xc7304
+#define BXT_PP_ON_DELAYS2  0xc7308
+#define BXT_PP_OFF_DELAYS2 0xc730c
+
 #define PCH_DP_B   0xe4100
 #define PCH_DPB_AUX_CH_CTL 0xe4110
 #define PCH_DPB_AUX_CH_DATA1   0xe4114
-- 
2.0.1

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

[Intel-gfx] [PATCH 1/3] drm/i915: eDP Panel Power sequencing modify use of HAS_PCH_SPLIT

[Vandana Kannan]

Changes based on future platform readiness patches related to
HAS_PCH_SPLIT(). Use HAS_GMCH_DISPLAY() instead of HAS_PCH_SPLIT

Signed-off-by: Vandana Kannan 
Signed-off-by: A.Sunil Kamath 
---
 drivers/gpu/drm/i915/i915_suspend.c | 4 ++--
 drivers/gpu/drm/i915/intel_dp.c | 8 
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_suspend.c 
b/drivers/gpu/drm/i915/i915_suspend.c
index cf67f82..e91d637 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -44,7 +44,7 @@ static void i915_save_display(struct drm_device *dev)
dev_priv->regfile.saveLVDS = I915_READ(LVDS);
 
/* Panel power sequencer */
-   if (HAS_PCH_SPLIT(dev)) {
+   if (!HAS_GMCH_DISPLAY(dev)) {
dev_priv->regfile.savePP_CONTROL = I915_READ(PCH_PP_CONTROL);
dev_priv->regfile.savePP_ON_DELAYS = 
I915_READ(PCH_PP_ON_DELAYS);
dev_priv->regfile.savePP_OFF_DELAYS = 
I915_READ(PCH_PP_OFF_DELAYS);
@@ -79,7 +79,7 @@ static void i915_restore_display(struct drm_device *dev)
I915_WRITE(LVDS, dev_priv->regfile.saveLVDS & mask);
 
/* Panel power sequencer */
-   if (HAS_PCH_SPLIT(dev)) {
+   if (!HAS_GMCH_DISPLAY(dev)) {
I915_WRITE(PCH_PP_ON_DELAYS, 
dev_priv->regfile.savePP_ON_DELAYS);
I915_WRITE(PCH_PP_OFF_DELAYS, 
dev_priv->regfile.savePP_OFF_DELAYS);
I915_WRITE(PCH_PP_DIVISOR, dev_priv->regfile.savePP_DIVISOR);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 937ba31..68e10c1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -559,7 +559,7 @@ static u32 _pp_ctrl_reg(struct intel_dp *intel_dp)
 {
struct drm_device *dev = intel_dp_to_dev(intel_dp);
 
-   if (HAS_PCH_SPLIT(dev))
+   if (!HAS_GMCH_DISPLAY(dev))
return PCH_PP_CONTROL;
else
return VLV_PIPE_PP_CONTROL(vlv_power_sequencer_pipe(intel_dp));
@@ -569,7 +569,7 @@ static u32 _pp_stat_reg(struct intel_dp *intel_dp)
 {
struct drm_device *dev = intel_dp_to_dev(intel_dp);
 
-   if (HAS_PCH_SPLIT(dev))
+   if (!HAS_GMCH_DISPLAY(dev))
return PCH_PP_STATUS;
else
return VLV_PIPE_PP_STATUS(vlv_power_sequencer_pipe(intel_dp));
@@ -4963,7 +4963,7 @@ intel_dp_init_panel_power_sequencer(struct drm_device 
*dev,
if (final->t11_t12 != 0)
return;
 
-   if (HAS_PCH_SPLIT(dev)) {
+   if (!HAS_GMCH_DISPLAY(dev)) {
pp_ctrl_reg = PCH_PP_CONTROL;
pp_on_reg = PCH_PP_ON_DELAYS;
pp_off_reg = PCH_PP_OFF_DELAYS;
@@ -5063,7 +5063,7 @@ intel_dp_init_panel_power_sequencer_registers(struct 
drm_device *dev,
 
lockdep_assert_held(&dev_priv->pps_mutex);
 
-   if (HAS_PCH_SPLIT(dev)) {
+   if (!HAS_GMCH_DISPLAY(dev)) {
pp_on_reg = PCH_PP_ON_DELAYS;
pp_off_reg = PCH_PP_OFF_DELAYS;
pp_div_reg = PCH_PP_DIVISOR;
-- 
2.0.1

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

Re: [Intel-gfx] [PATCH 3/8] drivers/mfd: Add lookup table for Panel Control as GPIO signal

[Shobhit Kumar]

On 04/29/2015 07:57 PM, Lee Jones wrote:
> On Wed, 29 Apr 2015, Shobhit Kumar wrote:
> 
>> On some Intel SoC platforms, the panel enable/disable signals are
>> controlled by CRC PMIC. Add those control as a new GPIO in a lookup
>> table for gpio-crystalcove chip during CRC driver load
>>
>> v2: Make the lookup table static (Thierry)
>> Remove the lookup table during driver remove (Thierry)
>>
>> CC: Samuel Ortiz 
>> Cc: Linus Walleij 
>> Cc: Alexandre Courbot 
>> Cc: Thierry Reding 
>> Signed-off-by: Shobhit Kumar 
>> ---
>>  drivers/mfd/intel_soc_pmic_core.c | 17 +
>>  1 file changed, 17 insertions(+)
> 
> I have no idea what this stuff is, but it looks plausible.

The CRC PMIC controls the panel enable/disable signal using one of GPIO
like lines. It was agreed by Linus Walleij to go this way. The matching
crystalcove gpio changes are already merged in Linux next as -
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=e189ca56d91bbf1d3fe2f88ab6858bf919d42adf

This just adds a consumer lookup table for the gpio. Since we do not
have a DT or board files, and since this was part of CRC driver, just
added the lookup table during CRC driver load itself. Same is done for
PWM in a later patch.

Regards
Shobhit

> 
> For my own reference:
>   Acked-by: Lee Jones 
> 
>> diff --git a/drivers/mfd/intel_soc_pmic_core.c 
>> b/drivers/mfd/intel_soc_pmic_core.c
>> index 7b50b6b..f3d918e 100644
>> --- a/drivers/mfd/intel_soc_pmic_core.c
>> +++ b/drivers/mfd/intel_soc_pmic_core.c
>> @@ -24,8 +24,19 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include "intel_soc_pmic_core.h"
>>  
>> +/* Lookup table for the Panel Enable/Disable line as GPIO signals */
>> +static struct gpiod_lookup_table panel_gpio_table = {
>> +/* Intel GFX is consumer */
>> +.dev_id = ":00:02.0",
>> +.table = {
>> +/* Panel EN/DISABLE */
>> +GPIO_LOOKUP("gpio_crystalcove", 94, "panel", GPIO_ACTIVE_HIGH),
>> +},
>> +};
>> +
>>  static int intel_soc_pmic_find_gpio_irq(struct device *dev)
>>  {
>>  struct gpio_desc *desc;
>> @@ -85,6 +96,9 @@ static int intel_soc_pmic_i2c_probe(struct i2c_client *i2c,
>>  if (ret)
>>  dev_warn(dev, "Can't enable IRQ as wake source: %d\n", ret);
>>  
>> +/* Add lookup table binding for Panel Control to the GPIO Chip */
>> +gpiod_add_lookup_table(&panel_gpio_table);
>> +
>>  ret = mfd_add_devices(dev, -1, config->cell_dev,
>>config->n_cell_devs, NULL, 0,
>>regmap_irq_get_domain(pmic->irq_chip_data));
>> @@ -104,6 +118,9 @@ static int intel_soc_pmic_i2c_remove(struct i2c_client 
>> *i2c)
>>  
>>  regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data);
>>  
>> +/* Remove lookup table for Panel Control from the GPIO Chip */
>> +gpiod_remove_lookup_table(&panel_gpio_table);
>> +
>>  mfd_remove_devices(&i2c->dev);
>>  
>>  return 0;
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Clear vma->bound on unbinding

[Mika Kuoppala]

Unbinding doesn't always lead to unconditional destruction
of vma. This destruction avoidance happens if vma is part of
execbuffer relocation list or if vma is being considered for
eviction in i915_gem_evict_something().

For those other users, mark the vma unbound so that
the correct state of this vma is preserved.

Reported-by: Chris Wilson 
Cc: Chris Wilson 
Cc: Daniel Vetter 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e8f6f4c..c378f04 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3069,6 +3069,7 @@ int i915_vma_unbind(struct i915_vma *vma)
trace_i915_vma_unbind(vma);
 
vma->vm->unbind_vma(vma);
+   vma->bound = 0;
 
list_del_init(&vma->mm_list);
if (i915_is_ggtt(vma->vm)) {
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH] drm/i915/hdmi: check port in ibx_infoframe_enabled

[Jani Nikula]

On Wed, 29 Apr 2015, Jesse Barnes  wrote:
> On 04/29/2015 05:30 AM, Jani Nikula wrote:
>> Add port check for ibx similar to vlv in
>> 
>> commit 535afa2e9e3c1867460d6981d879b04d8b2b9ab3
>> Author: Jesse Barnes 
>> Date:   Wed Apr 15 16:52:29 2015 -0700
>> 
>> drm/i915/vlv: check port in infoframe_enabled v2
>> 
>> Signed-off-by: Jani Nikula 
>> ---
>>  drivers/gpu/drm/i915/intel_hdmi.c | 6 +-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
>> b/drivers/gpu/drm/i915/intel_hdmi.c
>> index 7774ca2b9bdf..65bc3867dda2 100644
>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
>> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>> @@ -223,10 +223,14 @@ static bool ibx_infoframe_enabled(struct drm_encoder 
>> *encoder)
>>  struct drm_device *dev = encoder->dev;
>>  struct drm_i915_private *dev_priv = dev->dev_private;
>>  struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
>> +struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
>>  int reg = TVIDEO_DIP_CTL(intel_crtc->pipe);
>>  u32 val = I915_READ(reg);
>>  
>> -return val & VIDEO_DIP_ENABLE;
>> +if (VIDEO_DIP_PORT(intel_dig_port->port) == (val & VIDEO_DIP_PORT_MASK))
>> +return val & VIDEO_DIP_ENABLE;
>> +
>> +return false;
>>  }
>>  
>>  static void cpt_write_infoframe(struct drm_encoder *encoder,
>> 
>
> Ah great, thanks Jani.  R-b for both.

Both pushed to drm-intel-next-queued, thanks for the review.

BR,
Jani.

>
> Jesse

-- 
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 3/3] drm/i915: eDP Panel Power sequencing add PPS reg set

[Jani Nikula]

On Thu, 30 Apr 2015, Vandana Kannan  wrote:
> Second set of PPS registers have been defined but will be used when VBT
> provides a selection between the 2 sets of registers.
>
> Signed-off-by: Vandana Kannan 
> Signed-off-by: A.Sunil Kamath 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 580f5cb..199a1747 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6345,6 +6345,12 @@ enum skl_disp_power_wells {
>  #define  PANEL_POWER_CYCLE_DELAY_MASK(0x1f)
>  #define  PANEL_POWER_CYCLE_DELAY_SHIFT   0
>  
> +/* BXT PPS changes - 2nd set of PPS registers */
> +#define BXT_PP_STATUS2   0xc7300
> +#define BXT_PP_CONTROL2  0xc7304
> +#define BXT_PP_ON_DELAYS20xc7308
> +#define BXT_PP_OFF_DELAYS2   0xc730c
> +
>  #define PCH_DP_B 0xe4100
>  #define PCH_DPB_AUX_CH_CTL   0xe4110
>  #define PCH_DPB_AUX_CH_DATA1 0xe4114

How about doing this patch first, with something like:

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 435c372d001e..a3af3526cb4f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6343,6 +6343,17 @@ enum skl_disp_power_wells {
 #define  PANEL_POWER_CYCLE_DELAY_MASK  (0x1f)
 #define  PANEL_POWER_CYCLE_DELAY_SHIFT 0
 
+/* BXT PPS changes - 2nd set of PPS registers */
+#define _BXT_PP_STATUS20xc7300
+#define _BXT_PP_CONTROL2   0xc7304
+#define _BXT_PP_ON_DELAYS2 0xc7308
+#define _BXT_PP_OFF_DELAYS20xc730c
+
+#define BXT_PP_STATUS(n)   ((!n) ? PCH_PP_STATUS : _BXT_PP_STATUS2)
+#define BXT_PP_CONTROL(n)  ((!n) ? PCH_PP_CONTROL : _BXT_PP_CONTROL2)
+#define BXT_PP_ON_DELAYS(n)((!n) ? PCH_PP_ON_DELAYS : _BXT_PP_ON_DELAYS2)
+#define BXT_PP_OFF_DELAYS(n)   ((!n) ? PCH_PP_OFF_DELAYS : _BXT_PP_OFF_DELAYS2)
+
 #define PCH_DP_B   0xe4100
 #define PCH_DPB_AUX_CH_CTL 0xe4110
 #define PCH_DPB_AUX_CH_DATA1   0xe4114

And you could use BXT_PP_* from the start. I believe this will add
clarity to the usage and pinpoint where you'll need to touch the code to
enable the 2nd power sequencer.


BR,
Jani.


> -- 
> 2.0.1
>
> ___
> 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 1/3] drm/i915: eDP Panel Power sequencing modify use of HAS_PCH_SPLIT

[Jani Nikula]

On Thu, 30 Apr 2015, Vandana Kannan  wrote:
> Changes based on future platform readiness patches related to
> HAS_PCH_SPLIT(). Use HAS_GMCH_DISPLAY() instead of HAS_PCH_SPLIT
>
> Signed-off-by: Vandana Kannan 
> Signed-off-by: A.Sunil Kamath 
> ---
>  drivers/gpu/drm/i915/i915_suspend.c | 4 ++--
>  drivers/gpu/drm/i915/intel_dp.c | 8 
>  2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_suspend.c 
> b/drivers/gpu/drm/i915/i915_suspend.c
> index cf67f82..e91d637 100644
> --- a/drivers/gpu/drm/i915/i915_suspend.c
> +++ b/drivers/gpu/drm/i915/i915_suspend.c
> @@ -44,7 +44,7 @@ static void i915_save_display(struct drm_device *dev)
>   dev_priv->regfile.saveLVDS = I915_READ(LVDS);
>  
>   /* Panel power sequencer */
> - if (HAS_PCH_SPLIT(dev)) {
> + if (!HAS_GMCH_DISPLAY(dev)) {
>   dev_priv->regfile.savePP_CONTROL = I915_READ(PCH_PP_CONTROL);
>   dev_priv->regfile.savePP_ON_DELAYS = 
> I915_READ(PCH_PP_ON_DELAYS);
>   dev_priv->regfile.savePP_OFF_DELAYS = 
> I915_READ(PCH_PP_OFF_DELAYS);
> @@ -79,7 +79,7 @@ static void i915_restore_display(struct drm_device *dev)
>   I915_WRITE(LVDS, dev_priv->regfile.saveLVDS & mask);
>  
>   /* Panel power sequencer */
> - if (HAS_PCH_SPLIT(dev)) {
> + if (!HAS_GMCH_DISPLAY(dev)) {
>   I915_WRITE(PCH_PP_ON_DELAYS, 
> dev_priv->regfile.savePP_ON_DELAYS);
>   I915_WRITE(PCH_PP_OFF_DELAYS, 
> dev_priv->regfile.savePP_OFF_DELAYS);
>   I915_WRITE(PCH_PP_DIVISOR, dev_priv->regfile.savePP_DIVISOR);

I don't think you should touch i915_suspend.c at all. We're trying to
get rid of this blind register save/restore, and make everything work in
the encoder/connector code. Do note that we already skip this for
vlv/chv power sequencer registers.

> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 937ba31..68e10c1 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -559,7 +559,7 @@ static u32 _pp_ctrl_reg(struct intel_dp *intel_dp)
>  {
>   struct drm_device *dev = intel_dp_to_dev(intel_dp);
>  
> - if (HAS_PCH_SPLIT(dev))
> + if (!HAS_GMCH_DISPLAY(dev))
>   return PCH_PP_CONTROL;
>   else
>   return VLV_PIPE_PP_CONTROL(vlv_power_sequencer_pipe(intel_dp));
> @@ -569,7 +569,7 @@ static u32 _pp_stat_reg(struct intel_dp *intel_dp)
>  {
>   struct drm_device *dev = intel_dp_to_dev(intel_dp);
>  
> - if (HAS_PCH_SPLIT(dev))
> + if (!HAS_GMCH_DISPLAY(dev))
>   return PCH_PP_STATUS;
>   else
>   return VLV_PIPE_PP_STATUS(vlv_power_sequencer_pipe(intel_dp));
> @@ -4963,7 +4963,7 @@ intel_dp_init_panel_power_sequencer(struct drm_device 
> *dev,
>   if (final->t11_t12 != 0)
>   return;
>  
> - if (HAS_PCH_SPLIT(dev)) {
> + if (!HAS_GMCH_DISPLAY(dev)) {
>   pp_ctrl_reg = PCH_PP_CONTROL;
>   pp_on_reg = PCH_PP_ON_DELAYS;
>   pp_off_reg = PCH_PP_OFF_DELAYS;
> @@ -5063,7 +5063,7 @@ intel_dp_init_panel_power_sequencer_registers(struct 
> drm_device *dev,
>  
>   lockdep_assert_held(&dev_priv->pps_mutex);
>  
> - if (HAS_PCH_SPLIT(dev)) {
> + if (!HAS_GMCH_DISPLAY(dev)) {
>   pp_on_reg = PCH_PP_ON_DELAYS;
>   pp_off_reg = PCH_PP_OFF_DELAYS;
>   pp_div_reg = PCH_PP_DIVISOR;

For the rest, I'd like you to do what I suggested in my reply to patch
3, i.e. add a new if (IS_BROXTON(dev)) at the top of each of these, with
BXT_PP_WHATEVER(0) as the register. Later on, we can add code to choose
the power sequencer, a bit similar to what vlv/chv do now (except there
it's based on pipe).

BR,
Jani.


> -- 
> 2.0.1
>
> ___
> 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 2/3] drm/i915: eDP Panel Power sequencing PP_DIV register changes

[Jani Nikula]

On Thu, 30 Apr 2015, Vandana Kannan  wrote:
> BXT does not have PP_DIV register. Making changes to handle this.
>
> Signed-off-by: Vandana Kannan 
> Signed-off-by: Kumar, Mahesh 
> ---
>  drivers/gpu/drm/i915/i915_reg.h |  2 ++
>  drivers/gpu/drm/i915/i915_suspend.c |  8 --
>  drivers/gpu/drm/i915/intel_dp.c | 56 
> +
>  3 files changed, 52 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 36805b6..580f5cb 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6315,6 +6315,8 @@ enum skl_disp_power_wells {
>  #define PCH_PP_CONTROL   0xc7204
>  #define  PANEL_UNLOCK_REGS   (0xabcd << 16)
>  #define  PANEL_UNLOCK_MASK   (0x << 16)
> +#define  BXT_POWER_CYCLE_DELAY_MASK  (0x1f0)
> +#define  BXT_POWER_CYCLE_DELAY_SHIFT 4
>  #define  EDP_FORCE_VDD   (1 << 3)
>  #define  EDP_BLC_ENABLE  (1 << 2)
>  #define  PANEL_POWER_RESET   (1 << 1)
> diff --git a/drivers/gpu/drm/i915/i915_suspend.c 
> b/drivers/gpu/drm/i915/i915_suspend.c
> index e91d637..24e0b06 100644
> --- a/drivers/gpu/drm/i915/i915_suspend.c
> +++ b/drivers/gpu/drm/i915/i915_suspend.c
> @@ -48,7 +48,9 @@ static void i915_save_display(struct drm_device *dev)
>   dev_priv->regfile.savePP_CONTROL = I915_READ(PCH_PP_CONTROL);
>   dev_priv->regfile.savePP_ON_DELAYS = 
> I915_READ(PCH_PP_ON_DELAYS);
>   dev_priv->regfile.savePP_OFF_DELAYS = 
> I915_READ(PCH_PP_OFF_DELAYS);
> - dev_priv->regfile.savePP_DIVISOR = I915_READ(PCH_PP_DIVISOR);
> + if (!IS_BROXTON(dev))
> + dev_priv->regfile.savePP_DIVISOR =
> + I915_READ(PCH_PP_DIVISOR);
>   } else if (!IS_VALLEYVIEW(dev)) {
>   dev_priv->regfile.savePP_CONTROL = I915_READ(PP_CONTROL);
>   dev_priv->regfile.savePP_ON_DELAYS = I915_READ(PP_ON_DELAYS);
> @@ -82,7 +84,9 @@ static void i915_restore_display(struct drm_device *dev)
>   if (!HAS_GMCH_DISPLAY(dev)) {
>   I915_WRITE(PCH_PP_ON_DELAYS, 
> dev_priv->regfile.savePP_ON_DELAYS);
>   I915_WRITE(PCH_PP_OFF_DELAYS, 
> dev_priv->regfile.savePP_OFF_DELAYS);
> - I915_WRITE(PCH_PP_DIVISOR, dev_priv->regfile.savePP_DIVISOR);
> + if (!IS_BROXTON(dev))
> + I915_WRITE(PCH_PP_DIVISOR,
> + dev_priv->regfile.savePP_DIVISOR);

Again, no need to do this in i915_suspend.c.

>   I915_WRITE(PCH_PP_CONTROL, dev_priv->regfile.savePP_CONTROL);
>   } else if (!IS_VALLEYVIEW(dev)) {
>   I915_WRITE(PP_ON_DELAYS, dev_priv->regfile.savePP_ON_DELAYS);
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 68e10c1..37514d3 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4954,8 +4954,8 @@ intel_dp_init_panel_power_sequencer(struct drm_device 
> *dev,
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   struct edp_power_seq cur, vbt, spec,
>   *final = &intel_dp->pps_delays;
> - u32 pp_on, pp_off, pp_div, pp;
> - int pp_ctrl_reg, pp_on_reg, pp_off_reg, pp_div_reg;
> + u32 pp_on, pp_off, pp_div = 0, pp_ctl = 0, pp;
> + int pp_ctrl_reg, pp_on_reg, pp_off_reg, pp_div_reg = 0;
>  
>   lockdep_assert_held(&dev_priv->pps_mutex);
>  
> @@ -4964,10 +4964,16 @@ intel_dp_init_panel_power_sequencer(struct drm_device 
> *dev,
>   return;
>  
>   if (!HAS_GMCH_DISPLAY(dev)) {
> + /*
> +  * TODO: BXT has 2 sets of PPS registers.
> +  * Correct Register for Broxton need to be identified
> +  * using VBT. hardcoding for now
> +  */

This comment really belongs in the previous patch, which would add the
if (IS_BROXTON(dev)) branch as I suggested.

>   pp_ctrl_reg = PCH_PP_CONTROL;
>   pp_on_reg = PCH_PP_ON_DELAYS;
>   pp_off_reg = PCH_PP_OFF_DELAYS;
> - pp_div_reg = PCH_PP_DIVISOR;
> + if (!IS_BROXTON(dev))
> + pp_div_reg = PCH_PP_DIVISOR;

And thus this is naturally included in the previous patch as well.

The rest will probably need some updates - maybe it needs to be fully
incorporated into the previous patch.

>   } else {
>   enum pipe pipe = vlv_power_sequencer_pipe(intel_dp);
>  
> @@ -4984,7 +4990,10 @@ intel_dp_init_panel_power_sequencer(struct drm_device 
> *dev,
>  
>   pp_on = I915_READ(pp_on_reg);
>   pp_off = I915_READ(pp_off_reg);
> - pp_div = I915_READ(pp_div_reg);
> + if (!IS_BROXTON(dev))
> + pp_div = I915_READ(pp_div_reg);
> + else
> + pp_ctl = I915_READ(pp_ctrl_reg);
>  
>   /* Pull timing values out of registers */
>   cur.t1_t3 = (pp_on & PANEL_POWER_UP_DELAY_MASK) >>
> @@ -4999,8 +

Re: [Intel-gfx] [PATCH 2/3] drm/i915: eDP Panel Power sequencing PP_DIV register changes

[David Weinehall]

On Thu, Apr 30, 2015 at 01:07:34PM +0530, Vandana Kannan wrote:
> BXT does not have PP_DIV register. Making changes to handle this.

[snip]

> + if (!IS_BROXTON(dev))
> + dev_priv->regfile.savePP_DIVISOR =
> + I915_READ(PCH_PP_DIVISOR);

In case some future products also lack this register this will quickly
end up messy.  Maybe it'd be better to add a HAS_PP_DIVISOR(dev) macro
or something like that?


Kind regards, David Weinehall
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: fix intel_prepare_ddi

[Jani Nikula]

On Mon, 27 Apr 2015, Damien Lespiau  wrote:
> On Fri, Apr 17, 2015 at 07:31:22PM +0300, Imre Deak wrote:
>> At the moment intel_prepare_ddi buffer will iterate through both MST and
>> CRT encoders, which is incorrect. Neither of these encoder types have an
>> embedding intel_digital_port object, so for these encoder types we will
>> use random data when dereferencing the corresponding
>> intel_digital_port->port field.
>> 
>> Introduced in
>> commit b403745c84592b26a0713e6944c2b109f6df5c82
>> Author: Damien Lespiau 
>> Date:   Mon Aug 4 22:01:33 2014 +0100
>> 
>> drm/i915: Iterate through the initialized DDIs to prepare their buffers
>> 
>> v2:
>> - fix getting at the port for MST encoders too
>> - make sure that intel_prepare_ddi_buffers() gets called for port E too
>>   (Paulo)
>> 
>> Signed-off-by: Imre Deak 
>
> Reviewed-by: Damien Lespiau 

Both pushed to drm-intel-next-queued, with the Bugzilla: tag moved to
2/2 which actually fixes the bug. Thanks for the patches and review.

BR,
Jani.


>
> -- 
> Damien
>
>> ---
>>  drivers/gpu/drm/i915/i915_drv.h  |  5 -
>>  drivers/gpu/drm/i915/intel_ddi.c | 28 ++--
>>  2 files changed, 18 insertions(+), 15 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 40ef672..c461b56 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -251,11 +251,6 @@ enum hpd_pin {
>>  &dev->mode_config.connector_list,   \
>>  base.head)
>>  
>> -#define for_each_digital_port(dev, digital_port)\
>> -list_for_each_entry(digital_port,   \
>> -&dev->mode_config.encoder_list, \
>> -base.base.head)
>> -
>>  #define for_each_encoder_on_crtc(dev, __crtc, intel_encoder) \
>>  list_for_each_entry((intel_encoder), &(dev)->mode_config.encoder_list, 
>> base.head) \
>>  if ((intel_encoder)->base.crtc == (__crtc))
>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
>> b/drivers/gpu/drm/i915/intel_ddi.c
>> index 903d395..9c1e74a 100644
>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> @@ -256,12 +256,11 @@ intel_dig_port_supports_hdmi(const struct 
>> intel_digital_port *intel_dig_port)
>>   * in either FDI or DP modes only, as HDMI connections will work with both
>>   * of those
>>   */
>> -static void intel_prepare_ddi_buffers(struct drm_device *dev,
>> -  struct intel_digital_port *intel_dig_port)
>> +static void intel_prepare_ddi_buffers(struct drm_device *dev, enum port 
>> port,
>> +  bool supports_hdmi)
>>  {
>>  struct drm_i915_private *dev_priv = dev->dev_private;
>>  u32 reg;
>> -int port = intel_dig_port->port;
>>  int i, n_hdmi_entries, n_dp_entries, n_edp_entries, hdmi_default_entry,
>>  size;
>>  int hdmi_level = dev_priv->vbt.ddi_port_info[port].hdmi_level_shift;
>> @@ -272,7 +271,7 @@ static void intel_prepare_ddi_buffers(struct drm_device 
>> *dev,
>>  const struct ddi_buf_trans *ddi_translations;
>>  
>>  if (IS_BROXTON(dev)) {
>> -if (!intel_dig_port_supports_hdmi(intel_dig_port))
>> +if (!supports_hdmi)
>>  return;
>>  
>>  /* Vswing programming for HDMI */
>> @@ -360,7 +359,7 @@ static void intel_prepare_ddi_buffers(struct drm_device 
>> *dev,
>>  reg += 4;
>>  }
>>  
>> -if (!intel_dig_port_supports_hdmi(intel_dig_port))
>> +if (!supports_hdmi)
>>  return;
>>  
>>  /* Choose a good default if VBT is badly populated */
>> @@ -380,18 +379,27 @@ static void intel_prepare_ddi_buffers(struct 
>> drm_device *dev,
>>   */
>>  void intel_prepare_ddi(struct drm_device *dev)
>>  {
>> -struct intel_digital_port *intel_dig_port;
>> +struct intel_encoder *intel_encoder;
>>  bool visited[I915_MAX_PORTS] = { 0, };
>>  
>>  if (!HAS_DDI(dev))
>>  return;
>>  
>> -for_each_digital_port(dev, intel_dig_port) {
>> -if (visited[intel_dig_port->port])
>> +for_each_intel_encoder(dev, intel_encoder) {
>> +struct intel_digital_port *intel_dig_port;
>> +enum port port;
>> +bool supports_hdmi;
>> +
>> +ddi_get_encoder_port(intel_encoder, &intel_dig_port, &port);
>> +
>> +if (visited[port])
>>  continue;
>>  
>> -intel_prepare_ddi_buffers(dev, intel_dig_port);
>> -visited[intel_dig_port->port] = true;
>> +supports_hdmi = intel_dig_port &&
>> +intel_dig_port_supports_hdmi(intel_dig_port);
>> +
>> +intel_prepare_ddi_buffers(dev, port, supports_hdmi);
>> +visited[port] = true;
>>  }
>>  }
>>  
>> -- 
>> 2.1.0
>> 
> ___
> Intel-gfx mailing lis

Re: [Intel-gfx] [PATCH] drm/i915: Add missing MacBook Pro models with dual channel LVDS

[Joonas Lahtinen]

On ke, 2015-04-29 at 17:21 +0300, Jani Nikula wrote:
> On Sun, 12 Apr 2015, Lukas Wunner  wrote:
> > Single channel LVDS maxes out at 112 MHz. All 17" models with i915
> > graphics had a resolution of 1920x1200 (193 MHz), necessitating dual
> > channel LVDS. The 15" pre-retina models had either 1440x900 (106 MHz)
> > or 1680x1050 (119 MHz), both versions used dual channel LVDS even
> > though the smaller one would have fit into a single channel.
> >
> > Signed-off-by: Lukas Wunner 
> > Tested-by: Lukas Wunner 
> 
> Acked-by: Jani Nikula 
> 
> > ---
> >  drivers/gpu/drm/i915/intel_lvds.c | 26 --
> >  1 file changed, 24 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
> > b/drivers/gpu/drm/i915/intel_lvds.c
> > index 071b96d..417ccab 100644
> > --- a/drivers/gpu/drm/i915/intel_lvds.c
> > +++ b/drivers/gpu/drm/i915/intel_lvds.c
> > @@ -812,12 +812,28 @@ static int intel_dual_link_lvds_callback(const struct 
> > dmi_system_id *id)
> >  static const struct dmi_system_id intel_dual_link_lvds[] = {
> > {
> > .callback = intel_dual_link_lvds_callback,
> > -   .ident = "Apple MacBook Pro (Core i5/i7 Series)",
> > +   .ident = "Apple MacBook Pro 15\" (2010)",
> > +   .matches = {
> > +   DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> > +   DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro6,2"),
> > +   },
> > +   },
> > +   {
> > +   .callback = intel_dual_link_lvds_callback,
> > +   .ident = "Apple MacBook Pro 15\" (2011)",
> > .matches = {
> > DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> > DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro8,2"),
> > },
> > },
> > +   {
> > +   .callback = intel_dual_link_lvds_callback,
> > +   .ident = "Apple MacBook Pro 15\" (2012)",
> > +   .matches = {
> > +   DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> > +   DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro9,1"),
> > +   },
> > +   },
> > { } /* terminating entry */
> >  };
> >  
> > @@ -847,6 +863,11 @@ static bool compute_is_dual_link_lvds(struct 
> > intel_lvds_encoder *lvds_encoder)
> > if (i915.lvds_channel_mode > 0)
> > return i915.lvds_channel_mode == 2;
> >  
> > +   /* single channel LVDS is limited to 112 kHz */

s/kHz/MHz/

> > +   if (lvds_encoder->attached_connector->base.panel.fixed_mode->clock
> > +   > 112999)
> > +   return true;
> > +
> > if (dmi_check_system(intel_dual_link_lvds))
> > return true;
> >  
> > @@ -1104,6 +1125,8 @@ void intel_lvds_init(struct drm_device *dev)
> >  out:
> > mutex_unlock(&dev->mode_config.mutex);
> >  
> > +   intel_panel_init(&intel_connector->panel, fixed_mode, downclock_mode);
> > +
> > lvds_encoder->is_dual_link = compute_is_dual_link_lvds(lvds_encoder);
> > DRM_DEBUG_KMS("detected %s-link lvds configuration\n",
> >   lvds_encoder->is_dual_link ? "dual" : "single");
> > @@ -1118,7 +1141,6 @@ out:
> > }
> > drm_connector_register(connector);
> >  
> > -   intel_panel_init(&intel_connector->panel, fixed_mode, downclock_mode);
> > intel_panel_setup_backlight(connector, INVALID_PIPE);
> >  
> > return;
> > -- 
> > 1.8.5.2 (Apple Git-48)
> >
> > ___
> > 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

[Intel-gfx] i915 GTT table setup

[Kuprik, Ilya V]

Hello, team!

I am working on intel GFX virtualization solution using host-mediated 
pass-through. I am currently trying to test virtualized card inside virtual 
platform (Simics simulator) by running Ubuntu with i915 driver inside. 
Underlying GFX is Haswell Gen7.5.

Simulator has artificial BIOS that sets some registers in GFX (BGSM BDSM GGC 
and some others) to provide address map and DRAM memory information to GFX 
driver.  But, when i915 is executing inside virtualized environment, it runs 
normally until GTT initial setup- and during GTT setup, driver fills GTT with 
0xf physical page frame numbers (so effectively invalid).

The same Ubuntu image works normally outside of virtualized environment (on 
real host), so I assume, problem is in some simulator issues.

Question is - what are prerequisites for i915 driver to properly setup GTT?  
Note, that address map information is set correctly in BGSM BDSM and GGC 
(simulator specifically takes care of it).
What other essential init steps do I miss?

Thanks for help

Ilya Kuprik
SSG Simics SoC modeling team, Moscow




Closed Joint Stock Company Intel A/O
Registered legal address: Krylatsky Hills Business Park, 
17 Krylatskaya Str., Bldg 4, Moscow 121614, 
Russian Federation

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Remove wait for for punit to updates freq.

[Deepak S]

On Wednesday 29 April 2015 03:56 PM, Ville Syrjälä wrote:

On Wed, Apr 29, 2015 at 08:20:20AM +0530, Deepak S wrote:


On Wednesday 29 April 2015 12:02 AM, Ville Syrjälä wrote:

On Tue, Apr 28, 2015 at 11:16:29AM -0700, Jesse Barnes wrote:

On 03/04/2015 08:08 PM, deepa...@linux.intel.com wrote:

From: Deepak S 

When GPU is idle on VLV, Request freq to punit should be good enough to
get the voltage back to VNN. Also, make sure gfx clock force applies
before requesting the freq fot vlv.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75244
suggested-by: Jesse Barnes 
Signed-off-by: Deepak S 
---
   drivers/gpu/drm/i915/intel_pm.c | 20 
   1 file changed, 4 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e710b43..2e1ed07 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3894,7 +3894,7 @@ static void valleyview_set_rps(struct drm_device *dev, u8 
val)
* * If Gfx is Idle, then
* 1. Mask Turbo interrupts
* 2. Bring up Gfx clock
- * 3. Change the freq to Rpn and wait till P-Unit updates freq
+ * 3. Request the freq to Rpn.
* 4. Clear the Force GFX CLK ON bit so that Gfx can down
* 5. Unmask Turbo interrupts
   */
@@ -3902,8 +3902,8 @@ static void vlv_set_rps_idle(struct drm_i915_private 
*dev_priv)
   {
struct drm_device *dev = dev_priv->dev;
   
-	/* CHV and latest VLV don't need to force the gfx clock */

-   if (IS_CHERRYVIEW(dev) || dev->pdev->revision >= 0xd) {
+   /* CHV don't need to force the gfx clock */
+   if (IS_CHERRYVIEW(dev)) {
valleyview_set_rps(dev_priv->dev, 
dev_priv->rps.min_freq_softlimit);
return;
}
@@ -3920,20 +3920,8 @@ static void vlv_set_rps_idle(struct drm_i915_private 
*dev_priv)
   gen6_sanitize_rps_pm_mask(dev_priv, ~0));
   
   	vlv_force_gfx_clock(dev_priv, true);

-
-   dev_priv->rps.cur_freq = dev_priv->rps.min_freq_softlimit;
-
-   vlv_punit_write(dev_priv, PUNIT_REG_GPU_FREQ_REQ,
-   dev_priv->rps.min_freq_softlimit);
-
-   if (wait_for(((vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS))
-   & GENFREQSTATUS) == 0, 100))
-   DRM_ERROR("timed out waiting for Punit\n");
-
+   valleyview_set_rps(dev_priv->dev, dev_priv->rps.min_freq_softlimit);
vlv_force_gfx_clock(dev_priv, false);
-
-   I915_WRITE(GEN6_PMINTRMSK,
-  gen6_rps_pm_mask(dev_priv, dev_priv->rps.cur_freq));
   }
   
   void gen6_rps_idle(struct drm_i915_private *dev_priv)



Yeah I think this is fine (may need a rebase though, you can keep my r-b
if you do that in case Jani doesn't want to deal with the merge conflicts).

Reviewed-by: Jesse Barnes 

The removal of the stepping check is still confusing me even if the
rest would be OK.


Stepping check was added latest BYT release. On older BYT stepping, We used to 
wait for punit to grant the freq in GT Idle case, (most of the cases punit is 
timing out :( )
We now make the gfx clock force apply to all VLV and then request the freq to 
RPn this should be good enough to get voltage to Vnn.

But we shouldn't need the gfx clock force for the latest VLV
stepping(s), and we certainly didn't do it before. So why do
it now?


Hi Ville, This is keep code common across all the VLV stepping. :)

Thanks
Deepak


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

Re: [Intel-gfx] [PATCH v4] drm/i915/chv: Set min freq to efficient frequency on chv

[Deepak S]

On Thursday 30 April 2015 01:23 AM, Ville Syrjälä wrote:

On Wed, Apr 29, 2015 at 06:31:56PM +0300, Ville Syrjälä wrote:

On Wed, Apr 29, 2015 at 08:23:21AM +0530, deepa...@linux.intel.com wrote:

From: Deepak S 

After feedback from the hardware team, now we set the GPU min/idel freq to RPe.
Punit is expecting us to operate GPU between Rpe & Rp0. If we drop the
frequency to RPn, punit is failing to change the input voltage to
minimum :(

So far I can't reproduce this problem on my BSW. In fact what I see
that the voltage at RPn is lower than the voltage at RPe, even while
we're in rc6.

without forcewake:
RPn -> 0x66
RPe -> 0x67
RP0 -> 0x69

with forcewake:
RPn -> 0x66
RPe -> 0x76
RP0 -> 0x9d

Also asking Punit to change the frequency after the GPU has gone to
rc6 does absolutely nothing (remind anyone of VLV?). I think I need to
retest my VLV C0 to see if my earlier observations there were accurate.
The shared Vnn rail does make it harder to observe this stuff on
VLV though.

I went back to my VLVs (had a B3 and C0 actually). And I'm seeing the
exact same behaviour on both, ie. requesting a new frequency from Punit
does nothing when the GPU is in rc6, and if I let it enter rc6 with a
high frequency Vnn also remains high. Previously I had thought that C0
fixed this, but now it definitely shows the same problem here. I must
have had some accidental forcewake somewhere when I originally tested
it,

So based on that, your other patch to remove the stepping check from
vlv_set_rps_idle() is in fact correct.

The question remains however what should we do with CHV. According to my
testing to get the minimum voltage we should keep RPn around, and we
should also do the vlv_set_rps_idle() workaround on CHV.

Oh and I also observed something else on VLV. Normally when entering rc6
the GPLL ref clock gets trunk gated at CCK (by Punit I assume). However
when using the vlv_gfx_clock_force() that doesn't happen. So I'm not
entirely sure the GPLL gets turned off properly in that case. Maybe we
should just use forcewake instead? Oh and BTW, CHV doesn't do the trunk
gating in either case. I'm not sure where to check if the GPLL is
actually running or not.


Hi Ville,

Thanks Ville for verifying on VLV and CHV. Its interesting to see when Idle,
Voltage not dropping to Vnn on CHV :( This was supposed to be fixed
in BSW/CHV :(. As you suggested it would be better to extend the VLV WA to
CHV also to make sure we drop the voltage when idle.

Below is the sequence I think we should follow (based  on your comments).
1. forcewake power wells
2. do gfx force clock on
3. request freq to punit
4. release gfx force clock on
5. release forcewake of power wells.

Please share your thoughts?

Thanks
Deepak


So based on my tests this patch feels a bit wrong.


Since Punit validates the rps range [RPe, RP0]. This patch
removes unused cherryview_rps_min_freq function.

v2: Change commit message

v3: set min_freq before idle_freq (chris)

v4: Squash 'Remove unused rps min function' patch

Signed-off-by: Deepak S 
Acked-by: Chris Wilson 
---
  drivers/gpu/drm/i915/intel_pm.c | 21 ++---
  1 file changed, 2 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a7516ed..78c89ff 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4715,24 +4715,6 @@ static int cherryview_rps_guar_freq(struct 
drm_i915_private *dev_priv)
return rp1;
  }
  
-static int cherryview_rps_min_freq(struct drm_i915_private *dev_priv)

-{
-   struct drm_device *dev = dev_priv->dev;
-   u32 val, rpn;
-
-   if (dev->pdev->revision >= 0x20) {
-   val = vlv_punit_read(dev_priv, FB_GFX_FMIN_AT_VMIN_FUSE);
-   rpn = ((val >> FB_GFX_FMIN_AT_VMIN_FUSE_SHIFT) &
-  FB_GFX_FREQ_FUSE_MASK);
-   } else { /* For pre-production hardware */
-   val = vlv_punit_read(dev_priv, PUNIT_GPU_STATUS_REG);
-   rpn = ((val >> PUNIT_GPU_STATIS_GFX_MIN_FREQ_SHIFT) &
-  PUNIT_GPU_STATUS_GFX_MIN_FREQ_MASK);
-   }
-
-   return rpn;
-}
-
  static int valleyview_rps_guar_freq(struct drm_i915_private *dev_priv)
  {
u32 val, rp1;
@@ -4984,7 +4966,8 @@ static void cherryview_init_gt_powersave(struct 
drm_device *dev)
 intel_gpu_freq(dev_priv, dev_priv->rps.rp1_freq),
 dev_priv->rps.rp1_freq);
  
-	dev_priv->rps.min_freq = cherryview_rps_min_freq(dev_priv);

+   /* PUnit validated range is only [RPe, RP0] */
+   dev_priv->rps.min_freq = dev_priv->rps.efficient_freq;
DRM_DEBUG_DRIVER("min GPU freq: %d MHz (%u)\n",
 intel_gpu_freq(dev_priv, dev_priv->rps.min_freq),
 dev_priv->rps.min_freq);
--
1.9.1

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

Re: [Intel-gfx] [PATCH 04/11] drm/i915: Extend GET_APERTURE ioctl to report available map space

[Joonas Lahtinen]

On ke, 2015-04-29 at 11:27 +0100, Chris Wilson wrote:
> On Wed, Jan 28, 2015 at 10:59:28AM +0100, Daniel Vetter wrote:
> > Do we have the libdrm patch for this too? Imo there's not much use in this
> > if mesa remains broken, especially since this is for gen2/3 ... most DE
> > use gl nowadays.
> 
> On the other hand, there is a bug report open for mesa being broken in
> how it determines the aperture size that is causing an X crash.
> So maybe I should fix it up anyway. Hard to do without such a patch.

If the patch is merged, it should be upgraded to loop through all the
VMA's in GGTT, not only the ones that present whole objects.

Just a matter of adding looping in place of the obj_to_ggtt call.

Also, the i915_gem_object_is_inactive seems to be there as a leftover
added function, never gets called.

Regards, Joonas

> -Chris
> 


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

Re: [Intel-gfx] [PATCH i-g-t] tests/gem_mmap_gtt: Use PAGE_SIZE instead of hard coded value

[Joonas Lahtinen]

On ma, 2015-04-27 at 20:43 +0100, Chris Wilson wrote:
> On Mon, Apr 27, 2015 at 06:35:54PM +0100, Thomas Wood wrote:
> > On 24 April 2015 at 08:38, Joonas Lahtinen
> >  wrote:
> > > Now that there is PAGE_SIZE define, use it.
> > 
> > Thanks, I've pushed this patch. I also noticed PAGE_SIZE gets defined
> > in several tests, so at some point it might be worth moving it into
> > the library.
> 
> Be wary of these though. PAGE_SIZE should only ever be used wrt to struct
> page and not GPU pages. If you must, please use GTT_PAGE_SIZE instead.

Do we have a platform/case where these are different? Just asking out of
curiosity :)

And the use above was to a mmaped area, which I think should be
considered to behave like CPU paged memory? Otherwise kind of defeats
mmap purpose.

Regards, Joonas

> -Chris
> 


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

Re: [Intel-gfx] [PATCH] drm/i915/gtt: Allocate va range only if vma is not bound

[Jani Nikula]

On Wed, 29 Apr 2015, Chris Wilson  wrote:
> On Wed, Apr 29, 2015 at 09:49:30AM +0300, Mika Kuoppala wrote:
>> When we have bound vma into an address space, the layout
>> of page table structures is immutable. So we can be absolutely
>> certain that if vma is already bound, there is no need to
>> (re)allocate a virtual address range for it.
>> 
>> v2: - add sanity checks and remove superfluous GLOBAL_BIND set
>> - we might do update for an unbound vma (Chris)
>> 
>> v3: s/u32/unsigned (Chris)
>
> Go back to v2. Sorry, seems like u32 is being used throughout this
> callchain and so needs to be fixed all together.

v2 pushed to drm-intel-next-queued, with

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

Thanks for the patch and review.

BR,
Jani.


> -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

-- 
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 12/17] drm/i915: Arm cmd parser with aliasng ppgtt only

[Jani Nikula]

On Wed, 15 Apr 2015, Daniel Vetter  wrote:
> On Wed, Apr 15, 2015 at 11:07:15AM +0100, Chris Wilson wrote:
>> On Wed, Apr 15, 2015 at 11:43:25AM +0200, Daniel Vetter wrote:
>> > On Tue, Apr 14, 2015 at 07:10:30PM +0100, Chris Wilson wrote:
>> > > On Tue, Apr 14, 2015 at 05:35:22PM +0200, Daniel Vetter wrote:
>> > > > With the binding regression from the original full ppgtt patches
>> > > > fixed we can throw the switch. Yay!
>> > > 
>> > > This changelog is misleading. The validation part of the command parser
>> > > has been running for some time, with people starting to notice the
>> > > performance regressions. What is being turned on here is the enabling
>> > > part to allow userspace to do more. So shouldn't that also be a bump in
>> > > the command parser version?
>> > 
>> > mesa has independent checks that the register writes go through, so just
>> > switching the cmd parser to permission granting mode should be all that's
>> > neeeded really.
>> 
>> But the issue is the hardware would allow the writes anyway, and that
>> this patch has no actual effect since mesa can already do pipelined
>> register writes (at least on ivb/byt).
>
> Yeah it's only interesting for hsw really.
>
>> > And yes the cmd parser is enabled already, I thought "to arm" does convey
>> > that it's now going from dummy mode to live.
>> 
>> "Arm cmd parser" reads to me as a passive actor (parser is just a reader
>> and doesn't suggest that it enables anything).
>> 
>> "Enable cmd parser to do secure batch promotion for aliasing ppgtt"
>> 
>> or perhaps
>> 
>> "Now witness the firepower of this fully ARMED and OPERATIONAL cmdparser"
>
> Yeah not my best commit summary ever. I'll go with the first suggestion.

Pushed to drm-intel-next-queued as "drm/i915: Enable cmd parser to do
secure batch promotion for aliasing ppgtt", with

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

and Mika's r-b. Thanks for the patch and review.


BR,
Jani.


> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> 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] drm/i915/gen8: page directories rework allocation

[Dan Carpenter]

Hi Michel,

The patch 69876bed7e00: "drm/i915/gen8: page directories rework
allocation" from Apr 8, 2015, has the following issue:

drivers/gpu/drm/i915/i915_gem_gtt.c:760
warn: too many zeroes

drivers/gpu/drm/i915/i915_gem_gtt.c
   746  static int gen8_ppgtt_alloc_page_directories(struct i915_hw_ppgtt 
*ppgtt,
   747   struct i915_page_directory_pointer 
*pdp,
   748   uint64_t start,
   749   uint64_t length,
   750   unsigned long *new_pds)
   751  {
   752  struct drm_device *dev = ppgtt->base.dev;
   753  struct i915_page_directory *pd;
   754  uint64_t temp;
   755  uint32_t pdpe;
   756  
   757  WARN_ON(!bitmap_empty(new_pds, GEN8_LEGACY_PDPES));
   758  
   759  /* FIXME: PPGTT container_of won't work for 64b */
   760  WARN_ON((start + length) > 0x8ULL);
 ^
This last zero was not intended.

   761  
   762  gen8_for_each_pdpe(pd, pdp, start, length, temp, pdpe) {
   763  if (pd)
   764  continue;
   765  
   766  pd = alloc_pd_single(dev);
   767  if (IS_ERR(pd))
   768  goto unwind_out;
   769  
   770  gen8_initialize_pd(&ppgtt->base, pd);
   771  pdp->page_directory[pdpe] = pd;
   772  set_bit(pdpe, new_pds);
   773  }
   774  
   775  return 0;
   776  
   777  unwind_out:
   778  for_each_set_bit(pdpe, new_pds, GEN8_LEGACY_PDPES)
   779  unmap_and_free_pd(pdp->page_directory[pdpe], dev);
   780  
   781  return -ENOMEM;
   782  }


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

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: DP link training optimization

[shuang . he]

Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
Task id: 6284
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  276/276  276/276
ILK  302/302  302/302
SNB  316/316  316/316
IVB  264/264  264/264
BYT -4  227/227  223/227
BDW  318/318  318/318
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
*BYT  igt@gem_dummy_reloc_loop@render  FAIL(1)PASS(8)  TIMEOUT(1)PASS(1)
*BYT  igt@gem_exec_parse@chained-batch  FAIL(1)PASS(2)  
DMESG_WARN(1)PASS(1)
(dmesg patch 
applied)drm:check_crtc_state[i915]]*ERROR*mismatch_in_has_infoframe(expected#,found#)@mismatch
 in has_infoframe .* found
WARNING:at_drivers/gpu/drm/i915/intel_display.c:#check_crtc_state[i915]()@WARNING:.*
 at .* check_crtc_state+0x
 BYT  igt@gem_pipe_control_store_loop@fresh-buffer  
FAIL(1)TIMEOUT(4)PASS(5)  TIMEOUT(2)
*BYT  igt@gem_userptr_blits@forked-unsync-interruptible  FAIL(1)PASS(2) 
 DMESG_WARN(1)
(dmesg patch 
applied)drm:check_crtc_state[i915]]*ERROR*mismatch_in_has_infoframe(expected#,found#)@mismatch
 in has_infoframe .* found
WARNING:at_drivers/gpu/drm/i915/intel_display.c:#check_crtc_state[i915]()@WARNING:.*
 at .* check_crtc_state+0x
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] drm-intel-fixes

[Jani Nikula]

Hi Dave, just one fix for v4.1-rc2. Plenty of travel last week all
around, I'm sure we'll find more to worry about...

BR,
Jani.

The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:

  Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-04-30

for you to fetch changes up to a04f90a33fab74789b91fc973012f11022d1:

  drm/i915/chv: Implement WaDisableShadowRegForCpd (2015-04-28 17:31:29 +0300)


Deepak S (1):
  drm/i915/chv: Implement WaDisableShadowRegForCpd

 drivers/gpu/drm/i915/i915_reg.h | 2 ++
 drivers/gpu/drm/i915/intel_uncore.c | 8 
 2 files changed, 10 insertions(+)

-- 
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 4/5] drm/i915: Add a partial GGTT view type

[Joonas Lahtinen]

On ma, 2015-04-27 at 15:50 +0100, Tvrtko Ursulin wrote:
> Hi,
> 
> On 04/24/2015 01:09 PM, Joonas Lahtinen wrote:
> >
> > Partial view type allows manipulating parts of huge BOs through the GGTT,
> > which was not previously possible due to constraint that whole object had
> > to be mapped for any access to it through GGTT.
> >
> > Signed-off-by: Joonas Lahtinen 
> > ---
> >   drivers/gpu/drm/i915/i915_gem_gtt.c |   46 
> > +++
> >   drivers/gpu/drm/i915/i915_gem_gtt.h |   15 ++--
> >   2 files changed, 59 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > index 5babbd3..5937d3d 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > @@ -2764,6 +2764,47 @@ err_st_alloc:
> > return ERR_PTR(ret);
> >   }
> >
> > +static struct sg_table *
> > +intel_partial_pages(const struct i915_ggtt_view *view,
> > +   struct drm_i915_gem_object *obj)
> > +{
> > +   struct sg_table *st;
> > +   struct scatterlist *sg;
> > +   struct sg_page_iter obj_sg_iter;
> > +   int ret;
> > +
> > +   st = kmalloc(sizeof(*st), GFP_KERNEL);
> > +   if (!st)
> > +   goto err_st_alloc;
> > +
> > +   ret = sg_alloc_table(st, view->params.partial.size, GFP_KERNEL);
> > +   if (ret)
> > +   goto err_sg_alloc;
> > +
> > +   sg = st->sgl;
> > +   st->nents = 0;
> 
> sg_alloc_table configures the sg_table so not needed I think. Although I 
> do see I am also doing it. :)
> 

I initially stripped it w/r your code, but I was so desperate debugging
the for_each_sg_page interface I tried everything ;)

Removed it.

> > +   for_each_sg_page(obj->pages->sgl, &obj_sg_iter, obj->pages->nents,
> > +   view->params.partial.offset)
> > +   {
> > +   if (st->nents >= view->params.partial.size)
> > +   break;
> > +
> > +   sg_set_page(sg, NULL, PAGE_SIZE, 0);
> > +   sg_dma_address(sg) = sg_page_iter_dma_address(&obj_sg_iter);
> > +   sg_dma_len(sg) = PAGE_SIZE;
> > +
> > +   sg = sg_next(sg);
> > +   st->nents++;
> > +   }
> 
> I suppose in this case (as opposed to rotated view) using 
> sg_alloc_table_from_pages() could produce a more compact table. With the 
> caveat of that it doesn't always work (see i915_gem_userptr.c/st_set_pages).
> 
> So maybe promote to driver public st_set_pages and call in on an array 
> of pages?
> 

Disregarded regards to your later mail.

> > +
> > +   return st;
> > +
> > +err_sg_alloc:
> > +   kfree(st);
> 
> Here you lose ret from sg_alloc_table.
> 

Good catch.

> > +err_st_alloc:
> > +   return ERR_PTR(-ENOMEM);
> > +}
> > +
> >   static int
> >   i915_get_ggtt_vma_pages(struct i915_vma *vma)
> >   {
> > @@ -2777,6 +2818,9 @@ i915_get_ggtt_vma_pages(struct i915_vma *vma)
> > else if (vma->ggtt_view.type == I915_GGTT_VIEW_ROTATED)
> > vma->ggtt_view.pages =
> > intel_rotate_fb_obj_pages(&vma->ggtt_view, vma->obj);
> > +   else if (vma->ggtt_view.type == I915_GGTT_VIEW_PARTIAL)
> > +   vma->ggtt_view.pages =
> > +   intel_partial_pages(&vma->ggtt_view, vma->obj);
> > else
> > WARN_ONCE(1, "GGTT view %u not implemented!\n",
> >   vma->ggtt_view.type);
> > @@ -2859,6 +2903,8 @@ i915_ggtt_view_size(struct drm_i915_gem_object *obj,
> > if (view->type == I915_GGTT_VIEW_NORMAL ||
> > view->type == I915_GGTT_VIEW_ROTATED) {
> > return obj->base.size;
> > +   } else if (view->type == I915_GGTT_VIEW_PARTIAL) {
> > +   return view->params.partial.size << PAGE_SHIFT;
> > } else {
> > WARN_ONCE(1, "GGTT view %u not implemented!\n", view->type);
> > return obj->base.size;
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
> > b/drivers/gpu/drm/i915/i915_gem_gtt.h
> > index 34b7cca..ab1ad8a 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> > @@ -117,7 +117,8 @@ typedef uint64_t gen8_pde_t;
> >
> >   enum i915_ggtt_view_type {
> > I915_GGTT_VIEW_NORMAL = 0,
> > -   I915_GGTT_VIEW_ROTATED
> > +   I915_GGTT_VIEW_ROTATED,
> > +   I915_GGTT_VIEW_PARTIAL,
> >   };
> >
> >   struct intel_rotation_info {
> > @@ -130,6 +131,13 @@ struct intel_rotation_info {
> >   struct i915_ggtt_view {
> > enum i915_ggtt_view_type type;
> >
> > +   union {
> > +   struct {
> > +   pgoff_t offset;
> > +   size_t size;
> 
> Size is in pages right? Maybe it would be more self-documenting to use 
> some basic type like unsigned int or long since size_t, to me at least, 
> suggests bytes.
> 

Yeah, using unsigned long for offset and unsigned int for size, maps
more directly to the functions they're used with.

> > +   } partial;
> > +   } params;
> > +
> > struct sg_table *pages;
> >
> > union {
> > @@ -495,7 +503,10 @@ i915_gg

Re: [Intel-gfx] drm/i915: Don't use staged config for VLV cdclk calculations

[Dan Carpenter]

[ It seems a bit unfair to email you, but this is the patch that seems
  to actually trigger the warning.  Anyway, the intel-gfx list is also
  CC'd.]

Hello Ander Conselvan de Oliveira,

The patch 304603f47a74: "drm/i915: Don't use staged config for VLV
cdclk calculations" from Apr 2, 2015, leads to the following Smatch
warning:

drivers/gpu/drm/i915/intel_display.c:12850 intel_crtc_set_config()
error: we previously assumed 'pipe_config' could be null (see line 
12834)

drivers/gpu/drm/i915/intel_display.c
 12808  /* Compute whether we need a full modeset, only an fb base 
update or no
 12809   * change at all. In the future we might also check whether 
only the
 12810   * mode changed, e.g. for LVDS where we only change the panel 
fitter in
 12811   * such cases. */
 12812  intel_set_config_compute_mode_changes(set, config);

This call can set "config->mode_changed" to true.

 12813  
 12814  state = drm_atomic_state_alloc(dev);
 12815  if (!state) {
 12816  ret = -ENOMEM;
 12817  goto out_config;
 12818  }
 12819  
 12820  state->acquire_ctx = dev->mode_config.acquire_ctx;
 12821  
 12822  ret = intel_modeset_stage_output_state(dev, set, config, state);
 12823  if (ret)
 12824  goto fail;
 12825  
 12826  pipe_config = intel_modeset_compute_config(set->crtc, set->mode,
 12827 state,
 12828 &modeset_pipes,
 12829 &prepare_pipes,
 12830 &disable_pipes);
 12831  if (IS_ERR(pipe_config)) {
 12832  ret = PTR_ERR(pipe_config);
 12833  goto fail;
 12834  } else if (pipe_config) {
 12835  if (pipe_config->has_audio !=
 12836  to_intel_crtc(set->crtc)->config->has_audio)
 12837  config->mode_changed = true;
^^^
Here we also set it to true if pipe_config is non-NULL.

 12838  
 12839  /*
 12840   * Note we have an issue here with infoframes: current 
code
 12841   * only updates them on the full mode set path per hw
 12842   * requirements.  So here we should be checking for any
 12843   * required changes and forcing a mode set.
 12844   */
 12845  }
 12846  
 12847  intel_update_pipe_size(to_intel_crtc(set->crtc));
 12848  
 12849  if (config->mode_changed) {
 12850  ret = intel_set_mode_pipes(set->crtc, set->mode,
 12851 set->x, set->y, set->fb, 
pipe_config,

^^^
Before this patch, then Smatch didn't print a warning because there were
some paths which didn't dereference pipe_config.  The code here seems to
assume that if ->mode_changed is true then pipe_config is non-NULL but
my concern is that it's not considering the call to
intel_set_config_compute_mode_changes().

It's a weird thing that when you look at the code without considering
cross function analysis the code looks correct but when you do cross
function analysis it is very subtle.

 12852 modeset_pipes, prepare_pipes,
 12853 disable_pipes);
 12854  } else if (config->fb_changed) {
 12855  struct intel_crtc *intel_crtc = 
to_intel_crtc(set->crtc);
 12856  struct drm_plane *primary = set->crtc->primary;
 12857  int vdisplay, hdisplay;
 12858  

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915: eDP Panel Power sequencing add PPS reg set

[Imre Deak]

On to, 2015-04-30 at 13:07 +0530, Vandana Kannan wrote:
> Second set of PPS registers have been defined but will be used when VBT
> provides a selection between the 2 sets of registers.
> 
> Signed-off-by: Vandana Kannan 
> Signed-off-by: A.Sunil Kamath 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 580f5cb..199a1747 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6345,6 +6345,12 @@ enum skl_disp_power_wells {
>  #define  PANEL_POWER_CYCLE_DELAY_MASK(0x1f)
>  #define  PANEL_POWER_CYCLE_DELAY_SHIFT   0
>  
> +/* BXT PPS changes - 2nd set of PPS registers */
> +#define BXT_PP_STATUS2   0xc7300
> +#define BXT_PP_CONTROL2  0xc7304
> +#define BXT_PP_ON_DELAYS20xc7308
> +#define BXT_PP_OFF_DELAYS2   0xc730c
> +

Can we add these in the (future) patch which takes them into use?

>  #define PCH_DP_B 0xe4100
>  #define PCH_DPB_AUX_CH_CTL   0xe4110
>  #define PCH_DPB_AUX_CH_DATA1 0xe4114


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

[Intel-gfx] [PATCH v2 0/5] Partial GGTT views

[Joonas Lahtinen]

This series adds partial GGTT views and uses them from the GTT mmap
fault handler for objects bigger than the whole aperture. This use case
was earlier early detected and rejected completely, so no previous code
paths are changed, only a new one is added. This allows to handle huge
objects (compared to aperture size) through mmap from user land.

And not only huge objects, but when objects are of regular size and
aperture is shrinked due to virtualization (like with vGT). XenGT is the
original and primary target for this initial partial GGTT view support,
where programs fail due to the GGTT being extremely small, but payloads
remain the same.

Tiling is not supported yet. The gem_mmap_gtt suite passes without
errors even when the mmap fault handler would be converted to
unconditionally use partial views.

Regards, Joonas

v2:
- Cleanups, and bump the activation treshold to only cover the code the
  code path that was previously early rejected.

Joonas Lahtinen (5):
  drm/i915: Do not clear mappings beyond VMA size
  drm/i915: Do not make assumptions on GGTT VMA sizes
  drm/i915: Consider object pinned if any VMA is pinned
  drm/i915: Add a partial GGTT view type
  drm/i915: Use partial view in mmap fault handler

 drivers/gpu/drm/i915/i915_gem.c | 179 +++-
 drivers/gpu/drm/i915/i915_gem_gtt.c |  76 ++-
 drivers/gpu/drm/i915/i915_gem_gtt.h |  19 +++-
 3 files changed, 204 insertions(+), 70 deletions(-)

-- 
1.9.3



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

Re: [Intel-gfx] [PATCH v4] drm/i915/chv: Set min freq to efficient frequency on chv

[Ville Syrjälä]

On Thu, Apr 30, 2015 at 03:42:42PM +0530, Deepak S wrote:
> 
> 
> On Thursday 30 April 2015 01:23 AM, Ville Syrjälä wrote:
> > On Wed, Apr 29, 2015 at 06:31:56PM +0300, Ville Syrjälä wrote:
> >> On Wed, Apr 29, 2015 at 08:23:21AM +0530, deepa...@linux.intel.com wrote:
> >>> From: Deepak S 
> >>>
> >>> After feedback from the hardware team, now we set the GPU min/idel freq 
> >>> to RPe.
> >>> Punit is expecting us to operate GPU between Rpe & Rp0. If we drop the
> >>> frequency to RPn, punit is failing to change the input voltage to
> >>> minimum :(
> >> So far I can't reproduce this problem on my BSW. In fact what I see
> >> that the voltage at RPn is lower than the voltage at RPe, even while
> >> we're in rc6.
> >>
> >> without forcewake:
> >> RPn -> 0x66
> >> RPe -> 0x67
> >> RP0 -> 0x69
> >>
> >> with forcewake:
> >> RPn -> 0x66
> >> RPe -> 0x76
> >> RP0 -> 0x9d
> >>
> >> Also asking Punit to change the frequency after the GPU has gone to
> >> rc6 does absolutely nothing (remind anyone of VLV?). I think I need to
> >> retest my VLV C0 to see if my earlier observations there were accurate.
> >> The shared Vnn rail does make it harder to observe this stuff on
> >> VLV though.
> > I went back to my VLVs (had a B3 and C0 actually). And I'm seeing the
> > exact same behaviour on both, ie. requesting a new frequency from Punit
> > does nothing when the GPU is in rc6, and if I let it enter rc6 with a
> > high frequency Vnn also remains high. Previously I had thought that C0
> > fixed this, but now it definitely shows the same problem here. I must
> > have had some accidental forcewake somewhere when I originally tested
> > it,
> >
> > So based on that, your other patch to remove the stepping check from
> > vlv_set_rps_idle() is in fact correct.
> >
> > The question remains however what should we do with CHV. According to my
> > testing to get the minimum voltage we should keep RPn around, and we
> > should also do the vlv_set_rps_idle() workaround on CHV.
> >
> > Oh and I also observed something else on VLV. Normally when entering rc6
> > the GPLL ref clock gets trunk gated at CCK (by Punit I assume). However
> > when using the vlv_gfx_clock_force() that doesn't happen. So I'm not
> > entirely sure the GPLL gets turned off properly in that case. Maybe we
> > should just use forcewake instead? Oh and BTW, CHV doesn't do the trunk
> > gating in either case. I'm not sure where to check if the GPLL is
> > actually running or not.
> >
> Hi Ville,
> 
> Thanks Ville for verifying on VLV and CHV. Its interesting to see when Idle,
> Voltage not dropping to Vnn on CHV :( This was supposed to be fixed
> in BSW/CHV :(.

Well it does drop, but not quite all the way if the current
frequency is above RPn.

I just tried to look at the energy numbers from RAPL a bit. Based
on that the difference in Vgg when forcewake is off is rather
insignificant, or the Vgg portion of the always-on well is so small
that it doesn't really matter.

With forcewake enabled I see a clear difference between RPn and
RPe though. But that might mostly matter for cases where would grab
forcewake without actually feeding any work to the GPU. That might
be rare enough to not make much of a difference in practice.

> As you suggested it would be better to extend the VLV WA to
> CHV also to make sure we drop the voltage when idle.
> 
> Below is the sequence I think we should follow (based  on your comments).
> 1. forcewake power wells
> 2. do gfx force clock on
> 3. request freq to punit
> 4. release gfx force clock on
> 5. release forcewake of power wells.
> 
> Please share your thoughts?

I'm thinking we shouldn't need the gfx clock force since forcewake
should already cause the clock to be enabled.

I've also not verified what happens if we drop the forcewake before
Punit has actually finished the frequency change. I'll try to hack
up some kind of test to see if I can make that happen.

> 
> Thanks
> Deepak
> 
> >> So based on my tests this patch feels a bit wrong.
> >>
> >>> Since Punit validates the rps range [RPe, RP0]. This patch
> >>> removes unused cherryview_rps_min_freq function.
> >>>
> >>> v2: Change commit message
> >>>
> >>> v3: set min_freq before idle_freq (chris)
> >>>
> >>> v4: Squash 'Remove unused rps min function' patch
> >>>
> >>> Signed-off-by: Deepak S 
> >>> Acked-by: Chris Wilson 
> >>> ---
> >>>   drivers/gpu/drm/i915/intel_pm.c | 21 ++---
> >>>   1 file changed, 2 insertions(+), 19 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> >>> b/drivers/gpu/drm/i915/intel_pm.c
> >>> index a7516ed..78c89ff 100644
> >>> --- a/drivers/gpu/drm/i915/intel_pm.c
> >>> +++ b/drivers/gpu/drm/i915/intel_pm.c
> >>> @@ -4715,24 +4715,6 @@ static int cherryview_rps_guar_freq(struct 
> >>> drm_i915_private *dev_priv)
> >>>   return rp1;
> >>>   }
> >>>   
> >>> -static int cherryview_rps_min_freq(struct drm_i915_private *dev_priv)
> >>> -{
> >>> - struct drm_device *dev = dev_priv->dev;
> >>> - u32 val

[Intel-gfx] [PATCH v2 2/5] drm/i915: Do not make assumptions on GGTT VMA sizes

[Joonas Lahtinen]

GGTT VMA sizes might be smaller than the whole object size due to
different GGTT views.

v2:
- Separate GGTT view constraint calculations from normal view
  constraint calculations (Chris Wilson)
v3:
- Do not bother with debug wording. (Tvrtko Ursulin)

Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Signed-off-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 103 +++-
 drivers/gpu/drm/i915/i915_gem_gtt.c |  23 
 drivers/gpu/drm/i915/i915_gem_gtt.h |   4 ++
 3 files changed, 92 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e8f6f4c..9717c9d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3497,7 +3497,8 @@ static bool i915_gem_valid_gtt_space(struct i915_vma *vma,
 }
 
 /**
- * Finds free space in the GTT aperture and binds the object there.
+ * Finds free space in the GTT aperture and binds the object or a view of it
+ * there.
  */
 static struct i915_vma *
 i915_gem_object_bind_to_vm(struct drm_i915_gem_object *obj,
@@ -3516,36 +3517,60 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object 
*obj,
struct i915_vma *vma;
int ret;
 
-   if(WARN_ON(i915_is_ggtt(vm) != !!ggtt_view))
-   return ERR_PTR(-EINVAL);
+   if (i915_is_ggtt(vm)) {
+   u32 view_size;
+
+   if (WARN_ON(!ggtt_view))
+   return ERR_PTR(-EINVAL);
 
-   fence_size = i915_gem_get_gtt_size(dev,
-  obj->base.size,
-  obj->tiling_mode);
-   fence_alignment = i915_gem_get_gtt_alignment(dev,
-obj->base.size,
-obj->tiling_mode, true);
-   unfenced_alignment =
-   i915_gem_get_gtt_alignment(dev,
-  obj->base.size,
-  obj->tiling_mode, false);
+   view_size = i915_ggtt_view_size(obj, ggtt_view);
+
+   fence_size = i915_gem_get_gtt_size(dev,
+  view_size,
+  obj->tiling_mode);
+   fence_alignment = i915_gem_get_gtt_alignment(dev,
+view_size,
+obj->tiling_mode,
+true);
+   unfenced_alignment = i915_gem_get_gtt_alignment(dev,
+   view_size,
+   
obj->tiling_mode,
+   false);
+   size = flags & PIN_MAPPABLE ? fence_size : view_size;
+   } else {
+   fence_size = i915_gem_get_gtt_size(dev,
+  obj->base.size,
+  obj->tiling_mode);
+   fence_alignment = i915_gem_get_gtt_alignment(dev,
+obj->base.size,
+obj->tiling_mode,
+true);
+   unfenced_alignment =
+   i915_gem_get_gtt_alignment(dev,
+  obj->base.size,
+  obj->tiling_mode,
+  false);
+   size = flags & PIN_MAPPABLE ? fence_size : obj->base.size;
+   }
 
if (alignment == 0)
alignment = flags & PIN_MAPPABLE ? fence_alignment :
unfenced_alignment;
if (flags & PIN_MAPPABLE && alignment & (fence_alignment - 1)) {
-   DRM_DEBUG("Invalid object alignment requested %u\n", alignment);
+   DRM_DEBUG("Invalid object (view type=%u) alignment requested 
%u\n",
+ ggtt_view ? ggtt_view->type : 0,
+ alignment);
return ERR_PTR(-EINVAL);
}
 
-   size = flags & PIN_MAPPABLE ? fence_size : obj->base.size;
-
-   /* If the object is bigger than the entire aperture, reject it early
-* before evicting everything in a vain attempt to find space.
+   /* If binding the object/GGTT view requires more space than the entire
+* aperture has, reject it early before evicting everything in a vain
+* attempt to find space.
 */
-   if (obj->base.size > end) {
-   DRM_DEBUG("Attempting to bind an object larger than the 
aperture: object=%zd > %s aperture=%lu\n",
- obj->base.siz

[Intel-gfx] [PATCH v2 1/5] drm/i915: Do not clear mappings beyond VMA size

[Joonas Lahtinen]

Do not to clear mappings outside the allocated VMA under any
circumstances. Only clear the smaller of VMA or object page count.

This is required to allow creating partial object VMAs which in
turn are needed for partial GGTT views.

Reviewed-by: Tvrtko Ursulin 
Signed-off-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 9d3852c..fc562c6 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1945,19 +1945,23 @@ static void ggtt_unbind_vma(struct i915_vma *vma)
struct drm_device *dev = vma->vm->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_i915_gem_object *obj = vma->obj;
+   const uint64_t size = min_t(uint64_t,
+   obj->base.size,
+   vma->node.size);
 
if (vma->bound & GLOBAL_BIND) {
vma->vm->clear_range(vma->vm,
 vma->node.start,
-obj->base.size,
+size,
 true);
}
 
if (dev_priv->mm.aliasing_ppgtt && vma->bound & LOCAL_BIND) {
struct i915_hw_ppgtt *appgtt = dev_priv->mm.aliasing_ppgtt;
+
appgtt->base.clear_range(&appgtt->base,
 vma->node.start,
-obj->base.size,
+size,
 true);
}
 }
-- 
1.9.3



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

[Intel-gfx] [PATCH v2 3/5] drm/i915: Consider object pinned if any VMA is pinned

[Joonas Lahtinen]

Do not skip special GGTT views when considering whether an object
is pinned or not.

Wrong behaviour was introduced in;

commit ec7adb6ee79c8c9fe64d63ad638a31cd62e55515
Author: Joonas Lahtinen 
Date:   Mon Mar 16 14:11:13 2015 +0200

drm/i915: Do not use ggtt_view with (aliasing) PPGTT

Cc: Daniel Vetter 
Cc: Tvrtko Ursulin 
Signed-off-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9717c9d..a020836 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5253,13 +5253,10 @@ unsigned long i915_gem_obj_size(struct 
drm_i915_gem_object *o,
 bool i915_gem_obj_is_pinned(struct drm_i915_gem_object *obj)
 {
struct i915_vma *vma;
-   list_for_each_entry(vma, &obj->vma_list, vma_link) {
-   if (i915_is_ggtt(vma->vm) &&
-   vma->ggtt_view.type != I915_GGTT_VIEW_NORMAL)
-   continue;
+   list_for_each_entry(vma, &obj->vma_list, vma_link)
if (vma->pin_count > 0)
return true;
-   }
+
return false;
 }
 
-- 
1.9.3



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

[Intel-gfx] [PATCH v2 4/5] drm/i915: Add a partial GGTT view type

[Joonas Lahtinen]

Partial view type allows manipulating parts of huge BOs through the GGTT,
which was not previously possible due to constraint that whole object had
to be mapped for any access to it through GGTT.

v2:
- Retain error value from sg_alloc_table (Tvrtko Ursulin)
- Do not zero already zeroed variable (Tvrtko Ursulin)
- Use more common variable types for page size/offset(Tvrtko Ursulin)

Cc: Tvrtko Ursulin 
Signed-off-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 45 +
 drivers/gpu/drm/i915/i915_gem_gtt.h | 15 +++--
 2 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 640584f..ba28a67 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2762,6 +2762,46 @@ err_st_alloc:
return ERR_PTR(ret);
 }
 
+static struct sg_table *
+intel_partial_pages(const struct i915_ggtt_view *view,
+   struct drm_i915_gem_object *obj)
+{
+   struct sg_table *st;
+   struct scatterlist *sg;
+   struct sg_page_iter obj_sg_iter;
+   int ret = -ENOMEM;
+
+   st = kmalloc(sizeof(*st), GFP_KERNEL);
+   if (!st)
+   goto err_st_alloc;
+
+   ret = sg_alloc_table(st, view->params.partial.size, GFP_KERNEL);
+   if (ret)
+   goto err_sg_alloc;
+
+   sg = st->sgl;
+   for_each_sg_page(obj->pages->sgl, &obj_sg_iter, obj->pages->nents,
+   view->params.partial.offset)
+   {
+   if (st->nents >= view->params.partial.size)
+   break;
+
+   sg_set_page(sg, NULL, PAGE_SIZE, 0);
+   sg_dma_address(sg) = sg_page_iter_dma_address(&obj_sg_iter);
+   sg_dma_len(sg) = PAGE_SIZE;
+
+   sg = sg_next(sg);
+   st->nents++;
+   }
+
+   return st;
+
+err_sg_alloc:
+   kfree(st);
+err_st_alloc:
+   return ERR_PTR(ret);
+}
+
 static int
 i915_get_ggtt_vma_pages(struct i915_vma *vma)
 {
@@ -2775,6 +2815,9 @@ i915_get_ggtt_vma_pages(struct i915_vma *vma)
else if (vma->ggtt_view.type == I915_GGTT_VIEW_ROTATED)
vma->ggtt_view.pages =
intel_rotate_fb_obj_pages(&vma->ggtt_view, vma->obj);
+   else if (vma->ggtt_view.type == I915_GGTT_VIEW_PARTIAL)
+   vma->ggtt_view.pages =
+   intel_partial_pages(&vma->ggtt_view, vma->obj);
else
WARN_ONCE(1, "GGTT view %u not implemented!\n",
  vma->ggtt_view.type);
@@ -2864,6 +2907,8 @@ i915_ggtt_view_size(struct drm_i915_gem_object *obj,
if (view->type == I915_GGTT_VIEW_NORMAL ||
view->type == I915_GGTT_VIEW_ROTATED) {
return obj->base.size;
+   } else if (view->type == I915_GGTT_VIEW_PARTIAL) {
+   return view->params.partial.size << PAGE_SHIFT;
} else {
WARN_ONCE(1, "GGTT view %u not implemented!\n", view->type);
return obj->base.size;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 34b7cca..96a9ef7 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -117,7 +117,8 @@ typedef uint64_t gen8_pde_t;
 
 enum i915_ggtt_view_type {
I915_GGTT_VIEW_NORMAL = 0,
-   I915_GGTT_VIEW_ROTATED
+   I915_GGTT_VIEW_ROTATED,
+   I915_GGTT_VIEW_PARTIAL,
 };
 
 struct intel_rotation_info {
@@ -130,6 +131,13 @@ struct intel_rotation_info {
 struct i915_ggtt_view {
enum i915_ggtt_view_type type;
 
+   union {
+   struct {
+   unsigned long offset;
+   unsigned int size;
+   } partial;
+   } params;
+
struct sg_table *pages;
 
union {
@@ -495,7 +503,10 @@ i915_ggtt_view_equal(const struct i915_ggtt_view *a,
if (WARN_ON(!a || !b))
return false;
 
-   return a->type == b->type;
+   if (a->type != b->type)
+   return false;
+
+   return !memcmp(&a->params, &b->params, sizeof(a->params));
 }
 
 size_t
-- 
1.9.3



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

[Intel-gfx] [PATCH v2 5/5] drm/i915: Use partial view in mmap fault handler

[Joonas Lahtinen]

Use partial view for huge BOs (bigger than the mappable aperture)
in fault handler so that they can be accessed without trying to make
room for them by evicting other objects.

v2:
- Only use partial views in the case where early rejection was
  previously done.
- Account variable type changes from previous reroll.

Cc: Chris Wilson 
Signed-off-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 69 +++--
 1 file changed, 46 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a020836..2f3fa0b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1635,6 +1635,7 @@ int i915_gem_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)
struct drm_i915_gem_object *obj = to_intel_bo(vma->vm_private_data);
struct drm_device *dev = obj->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
+   struct i915_ggtt_view view = i915_ggtt_view_normal;
pgoff_t page_offset;
unsigned long pfn;
int ret = 0;
@@ -1667,8 +1668,21 @@ int i915_gem_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)
goto unlock;
}
 
-   /* Now bind it into the GTT if needed */
-   ret = i915_gem_obj_ggtt_pin(obj, 0, PIN_MAPPABLE);
+   /* Use a partial view if the object is bigger than the aperture. */
+   if (obj->base.size >= dev_priv->gtt.mappable_end) {
+   static const unsigned int chunk_size = 256; // 1 MiB
+   memset(&view, 0, sizeof(view));
+   view.type = I915_GGTT_VIEW_PARTIAL;
+   view.params.partial.offset = rounddown(page_offset, chunk_size);
+   view.params.partial.size =
+   min_t(unsigned int,
+ chunk_size,
+ (vma->vm_end - vma->vm_start)/PAGE_SIZE -
+ view.params.partial.offset);
+   }
+
+   /* Now pin it into the GTT if needed */
+   ret = i915_gem_object_ggtt_pin(obj, &view, 0, PIN_MAPPABLE);
if (ret)
goto unlock;
 
@@ -1681,30 +1695,44 @@ int i915_gem_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)
goto unpin;
 
/* Finally, remap it using the new GTT offset */
-   pfn = dev_priv->gtt.mappable_base + i915_gem_obj_ggtt_offset(obj);
+   pfn = dev_priv->gtt.mappable_base +
+   i915_gem_obj_ggtt_offset_view(obj, &view);
pfn >>= PAGE_SHIFT;
 
-   if (!obj->fault_mappable) {
-   unsigned long size = min_t(unsigned long,
-  vma->vm_end - vma->vm_start,
-  obj->base.size);
-   int i;
+   if (unlikely(view.type == I915_GGTT_VIEW_PARTIAL)) {
+   unsigned long base = vma->vm_start +
+   (view.params.partial.offset << PAGE_SHIFT);
+   unsigned int i;
 
-   for (i = 0; i < size >> PAGE_SHIFT; i++) {
-   ret = vm_insert_pfn(vma,
-   (unsigned long)vma->vm_start + i * 
PAGE_SIZE,
-   pfn + i);
+   for (i = 0; i < view.params.partial.size; i++) {
+   ret = vm_insert_pfn(vma, base + i * PAGE_SIZE, pfn + i);
if (ret)
break;
}
-
obj->fault_mappable = true;
-   } else
-   ret = vm_insert_pfn(vma,
-   (unsigned long)vmf->virtual_address,
-   pfn + page_offset);
+   } else {
+   if (!obj->fault_mappable) {
+   unsigned long size = min_t(unsigned long,
+  vma->vm_end - vma->vm_start,
+  obj->base.size);
+   int i;
+
+   for (i = 0; i < size >> PAGE_SHIFT; i++) {
+   ret = vm_insert_pfn(vma,
+   (unsigned 
long)vma->vm_start + i * PAGE_SIZE,
+   pfn + i);
+   if (ret)
+   break;
+   }
+
+   obj->fault_mappable = true;
+   } else
+   ret = vm_insert_pfn(vma,
+   (unsigned long)vmf->virtual_address,
+   pfn + page_offset);
+   }
 unpin:
-   i915_gem_object_ggtt_unpin(obj);
+   i915_gem_object_ggtt_unpin_view(obj, &view);
 unlock:
mutex_unlock(&dev->struct_mutex);
 out:
@@ -1897,11 +1925,6 @@ i915_gem_mmap_gtt(struct drm_file *file,
goto unlock;
}
 
- 

Re: [Intel-gfx] [PATCH 3/3] drm/i915: eDP Panel Power sequencing add PPS reg set

[Jani Nikula]

On Thu, 30 Apr 2015, Imre Deak  wrote:
> On to, 2015-04-30 at 13:07 +0530, Vandana Kannan wrote:
>> Second set of PPS registers have been defined but will be used when VBT
>> provides a selection between the 2 sets of registers.
>> 
>> Signed-off-by: Vandana Kannan 
>> Signed-off-by: A.Sunil Kamath 
>> ---
>>  drivers/gpu/drm/i915/i915_reg.h | 6 ++
>>  1 file changed, 6 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h 
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index 580f5cb..199a1747 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -6345,6 +6345,12 @@ enum skl_disp_power_wells {
>>  #define  PANEL_POWER_CYCLE_DELAY_MASK   (0x1f)
>>  #define  PANEL_POWER_CYCLE_DELAY_SHIFT  0
>>  
>> +/* BXT PPS changes - 2nd set of PPS registers */
>> +#define BXT_PP_STATUS2  0xc7300
>> +#define BXT_PP_CONTROL2 0xc7304
>> +#define BXT_PP_ON_DELAYS2   0xc7308
>> +#define BXT_PP_OFF_DELAYS2  0xc730c
>> +
>
> Can we add these in the (future) patch which takes them into use?

See my review comment, we should use them off the bat.

BR,
Jani.

>
>>  #define PCH_DP_B0xe4100
>>  #define PCH_DPB_AUX_CH_CTL  0xe4110
>>  #define PCH_DPB_AUX_CH_DATA10xe4114
>
>
> ___
> 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 i-g-t] tests/gem_mmap_gtt: Use PAGE_SIZE instead of hard coded value

[Chris Wilson]

On Thu, Apr 30, 2015 at 01:28:46PM +0300, Joonas Lahtinen wrote:
> On ma, 2015-04-27 at 20:43 +0100, Chris Wilson wrote:
> > On Mon, Apr 27, 2015 at 06:35:54PM +0100, Thomas Wood wrote:
> > > On 24 April 2015 at 08:38, Joonas Lahtinen
> > >  wrote:
> > > > Now that there is PAGE_SIZE define, use it.
> > > 
> > > Thanks, I've pushed this patch. I also noticed PAGE_SIZE gets defined
> > > in several tests, so at some point it might be worth moving it into
> > > the library.
> > 
> > Be wary of these though. PAGE_SIZE should only ever be used wrt to struct
> > page and not GPU pages. If you must, please use GTT_PAGE_SIZE instead.
> 
> Do we have a platform/case where these are different? Just asking out of
> curiosity :)

Yes. We just haven't enabled big pages yet. The thought of getting globs
of 64k contiguous physical memory isn't too appealing, but like with
hugepages there are likely enough tasks that benefit.
 
> And the use above was to a mmaped area, which I think should be
> considered to behave like CPU paged memory? Otherwise kind of defeats
> mmap purpose.

I was making the observation just in case someone wanted to go through
the whole code base fixing up the hardcoded 4096 constants.
-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

[Intel-gfx] [PATCH i-g-t 2/2] kms_plane_scaling: Find the image regardless how the test is run

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

As it stands running the test like "sudo tests/kms_plane_scaling"
does not work.

Fix it by using the same method igt_paint_image uses.

Signed-off-by: Tvrtko Ursulin 
Cc: chandra konduru 
---
 tests/kms_plane_scaling.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/tests/kms_plane_scaling.c b/tests/kms_plane_scaling.c
index 00db5cb..8ff154f 100644
--- a/tests/kms_plane_scaling.c
+++ b/tests/kms_plane_scaling.c
@@ -202,6 +202,15 @@ static void iterate_plane_scaling(data_t *d, 
drmModeModeInfo *mode)
}
 }
 
+static cairo_status_t
+stdio_read_func(void *closure, unsigned char* data, unsigned int size)
+{
+   if (fread(data, 1, size, (FILE*)closure) != size)
+   return CAIRO_STATUS_READ_ERROR;
+
+   return CAIRO_STATUS_SUCCESS;
+}
+
 static void test_plane_scaling(data_t *d)
 {
igt_display_t *display = &d->display;
@@ -210,6 +219,7 @@ static void test_plane_scaling(data_t *d)
enum pipe pipe;
int valid_tests = 0;
int primary_plane_scaling = 0; /* For now */
+   FILE* f;
 
igt_require(d->display.has_universal_planes);
igt_require(d->num_scalers);
@@ -223,11 +233,15 @@ static void test_plane_scaling(data_t *d)
mode = igt_output_get_mode(output);
 
/* allocate fb2 with image size */
-   image = cairo_image_surface_create_from_png(FILE_NAME);
+
+   f = igt_fopen_data(FILE_NAME);
+   image = cairo_image_surface_create_from_png_stream(
+   &stdio_read_func, f);
igt_assert(cairo_surface_status(image) == CAIRO_STATUS_SUCCESS);
d->image_w = cairo_image_surface_get_width(image);
d->image_h = cairo_image_surface_get_height(image);
cairo_surface_destroy(image);
+   fclose(f);
 
d->fb_id2 = igt_create_fb(d->drm_fd,
d->image_w, d->image_h,
@@ -355,7 +369,6 @@ igt_simple_main
 
igt_skip_on_simulation();
 
-
data.drm_fd = drm_open_any();
igt_require_pipe_crc();
igt_display_init(&data.display, data.drm_fd);
-- 
2.3.5

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

[Intel-gfx] [PATCH i-g-t 1/2] igt_fb: Close the image file when we are done with it

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Signed-off-by: Tvrtko Ursulin 
---
 lib/igt_fb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/igt_fb.c b/lib/igt_fb.c
index 6dc22bb..eed5405 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -388,6 +388,8 @@ void igt_paint_image(cairo_t *cr, const char *filename,
cairo_surface_destroy(image);
 
cairo_restore(cr);
+
+   fclose(f);
 }
 
 /**
-- 
2.3.5

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

[Intel-gfx] [PATCH] drm/i915: Possible security hole in command parsing

[Rebecca N. Palmer]

i915_parse_cmds returns -EACCES on chained batches, which "tells the
caller to abort and dispatch the workload as a non-secure batch",
but the mechanism implementing that was broken when
flags |= I915_DISPATCH_SECURE was moved from i915_gem_execbuffer_parse
to i915_gem_do_execbuffer (17cabf571e50677d980e9ab2a43c5f11213003ae):
i915_gem_execbuffer_parse returns the original batch_obj in this case,
and i915_gem_do_execbuffer doesn't check for that.

Is this being made secure some other way (in which case the obsolete
comments should probably be removed), or is this a security hole?

Warning: this is my first kernel patch, and has not been tested yet.
Signed-off-by: Rebecca Palmer  

--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1398,7 +1398,7 @@ i915_gem_do_execbuffer(struct drm_device
 {
struct drm_i915_private *dev_priv = dev->dev_private;
struct eb_vmas *eb;
-   struct drm_i915_gem_object *batch_obj;
+   struct drm_i915_gem_object *batch_obj, *orig_batch_obj;
struct drm_i915_gem_exec_object2 shadow_exec_entry;
struct intel_engine_cs *ring;
struct intel_context *ctx;
@@ -1511,7 +1511,7 @@ i915_gem_do_execbuffer(struct drm_device
goto err;
 
/* take note of the batch buffer before we might reorder the lists */
-   batch_obj = eb_get_batch(eb);
+   orig_batch_obj = eb_get_batch(eb);
 
/* Move the objects en-masse into the GTT, evicting if necessary. */
need_relocs = (args->flags & I915_EXEC_NO_RELOC) == 0;
@@ -1533,7 +1533,7 @@ i915_gem_do_execbuffer(struct drm_device
}
 
/* Set the pending read domains for the batch buffer to COMMAND */
-   if (batch_obj->base.pending_write_domain) {
+   if (orig_batch_obj->base.pending_write_domain) {
DRM_DEBUG("Attempting to use self-modifying batch buffer\n");
ret = -EINVAL;
goto err;
@@ -1543,7 +1543,7 @@ i915_gem_do_execbuffer(struct drm_device
batch_obj = i915_gem_execbuffer_parse(ring,
  &shadow_exec_entry,
  eb,
- batch_obj,
+ orig_batch_obj,
  args->batch_start_offset,
  args->batch_len,
  file->is_master);
@@ -1559,7 +1559,7 @@ i915_gem_do_execbuffer(struct drm_device
 * don't want that set when the command parser is
 * enabled.
 */
-   if (USES_PPGTT(dev))
+   if (USES_PPGTT(dev) && batch_obj!=orig_batch_obj)
dispatch_flags |= I915_DISPATCH_SECURE;
 
exec_start = 0;

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

Re: [Intel-gfx] [PATCH v2 2/5] drm/i915: Do not make assumptions on GGTT VMA sizes

[Tvrtko Ursulin]

On 04/30/2015 12:19 PM, Joonas Lahtinen wrote:


GGTT VMA sizes might be smaller than the whole object size due to
different GGTT views.

v2:
- Separate GGTT view constraint calculations from normal view
   constraint calculations (Chris Wilson)
v3:
- Do not bother with debug wording. (Tvrtko Ursulin)

Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Signed-off-by: Joonas Lahtinen 
---
  drivers/gpu/drm/i915/i915_gem.c | 103 +++-
  drivers/gpu/drm/i915/i915_gem_gtt.c |  23 
  drivers/gpu/drm/i915/i915_gem_gtt.h |   4 ++
  3 files changed, 92 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e8f6f4c..9717c9d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3497,7 +3497,8 @@ static bool i915_gem_valid_gtt_space(struct i915_vma *vma,
  }

  /**
- * Finds free space in the GTT aperture and binds the object there.
+ * Finds free space in the GTT aperture and binds the object or a view of it
+ * there.
   */
  static struct i915_vma *
  i915_gem_object_bind_to_vm(struct drm_i915_gem_object *obj,
@@ -3516,36 +3517,60 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object 
*obj,
struct i915_vma *vma;
int ret;

-   if(WARN_ON(i915_is_ggtt(vm) != !!ggtt_view))
-   return ERR_PTR(-EINVAL);
+   if (i915_is_ggtt(vm)) {
+   u32 view_size;
+
+   if (WARN_ON(!ggtt_view))
+   return ERR_PTR(-EINVAL);

-   fence_size = i915_gem_get_gtt_size(dev,
-  obj->base.size,
-  obj->tiling_mode);
-   fence_alignment = i915_gem_get_gtt_alignment(dev,
-obj->base.size,
-obj->tiling_mode, true);
-   unfenced_alignment =
-   i915_gem_get_gtt_alignment(dev,
-  obj->base.size,
-  obj->tiling_mode, false);
+   view_size = i915_ggtt_view_size(obj, ggtt_view);
+
+   fence_size = i915_gem_get_gtt_size(dev,
+  view_size,
+  obj->tiling_mode);
+   fence_alignment = i915_gem_get_gtt_alignment(dev,
+view_size,
+obj->tiling_mode,
+true);
+   unfenced_alignment = i915_gem_get_gtt_alignment(dev,
+   view_size,
+   
obj->tiling_mode,
+   false);
+   size = flags & PIN_MAPPABLE ? fence_size : view_size;
+   } else {
+   fence_size = i915_gem_get_gtt_size(dev,
+  obj->base.size,
+  obj->tiling_mode);
+   fence_alignment = i915_gem_get_gtt_alignment(dev,
+obj->base.size,
+obj->tiling_mode,
+true);
+   unfenced_alignment =
+   i915_gem_get_gtt_alignment(dev,
+  obj->base.size,
+  obj->tiling_mode,
+  false);
+   size = flags & PIN_MAPPABLE ? fence_size : obj->base.size;
+   }


I do not like this almost identical branches - so I defer to Chris to 
okay that this is what he wanted.



if (alignment == 0)
alignment = flags & PIN_MAPPABLE ? fence_alignment :
unfenced_alignment;
if (flags & PIN_MAPPABLE && alignment & (fence_alignment - 1)) {
-   DRM_DEBUG("Invalid object alignment requested %u\n", alignment);
+   DRM_DEBUG("Invalid object (view type=%u) alignment requested 
%u\n",
+ ggtt_view ? ggtt_view->type : 0,
+ alignment);
return ERR_PTR(-EINVAL);
}

-   size = flags & PIN_MAPPABLE ? fence_size : obj->base.size;
-
-   /* If the object is bigger than the entire aperture, reject it early
-* before evicting everything in a vain attempt to find space.
+   /* If binding the object/GGTT view requires more space than the entire
+* aperture has, reject it early before evicting everything in a vain
+* attempt to find space.
 */
-   if (obj->base.size 

Re: [Intel-gfx] [PATCH v2 4/5] drm/i915: Add a partial GGTT view type

[Tvrtko Ursulin]

On 04/30/2015 12:20 PM, Joonas Lahtinen wrote:


Partial view type allows manipulating parts of huge BOs through the GGTT,
which was not previously possible due to constraint that whole object had
to be mapped for any access to it through GGTT.

v2:
- Retain error value from sg_alloc_table (Tvrtko Ursulin)
- Do not zero already zeroed variable (Tvrtko Ursulin)
- Use more common variable types for page size/offset(Tvrtko Ursulin)

Cc: Tvrtko Ursulin 
Signed-off-by: Joonas Lahtinen 
---
  drivers/gpu/drm/i915/i915_gem_gtt.c | 45 +
  drivers/gpu/drm/i915/i915_gem_gtt.h | 15 +++--
  2 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 640584f..ba28a67 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2762,6 +2762,46 @@ err_st_alloc:
return ERR_PTR(ret);
  }

+static struct sg_table *
+intel_partial_pages(const struct i915_ggtt_view *view,
+   struct drm_i915_gem_object *obj)
+{
+   struct sg_table *st;
+   struct scatterlist *sg;
+   struct sg_page_iter obj_sg_iter;
+   int ret = -ENOMEM;
+
+   st = kmalloc(sizeof(*st), GFP_KERNEL);
+   if (!st)
+   goto err_st_alloc;
+
+   ret = sg_alloc_table(st, view->params.partial.size, GFP_KERNEL);
+   if (ret)
+   goto err_sg_alloc;
+
+   sg = st->sgl;
+   for_each_sg_page(obj->pages->sgl, &obj_sg_iter, obj->pages->nents,
+   view->params.partial.offset)
+   {
+   if (st->nents >= view->params.partial.size)
+   break;
+
+   sg_set_page(sg, NULL, PAGE_SIZE, 0);
+   sg_dma_address(sg) = sg_page_iter_dma_address(&obj_sg_iter);
+   sg_dma_len(sg) = PAGE_SIZE;
+
+   sg = sg_next(sg);
+   st->nents++;
+   }
+
+   return st;
+
+err_sg_alloc:
+   kfree(st);
+err_st_alloc:
+   return ERR_PTR(ret);
+}
+
  static int
  i915_get_ggtt_vma_pages(struct i915_vma *vma)
  {
@@ -2775,6 +2815,9 @@ i915_get_ggtt_vma_pages(struct i915_vma *vma)
else if (vma->ggtt_view.type == I915_GGTT_VIEW_ROTATED)
vma->ggtt_view.pages =
intel_rotate_fb_obj_pages(&vma->ggtt_view, vma->obj);
+   else if (vma->ggtt_view.type == I915_GGTT_VIEW_PARTIAL)
+   vma->ggtt_view.pages =
+   intel_partial_pages(&vma->ggtt_view, vma->obj);
else
WARN_ONCE(1, "GGTT view %u not implemented!\n",
  vma->ggtt_view.type);
@@ -2864,6 +2907,8 @@ i915_ggtt_view_size(struct drm_i915_gem_object *obj,
if (view->type == I915_GGTT_VIEW_NORMAL ||
view->type == I915_GGTT_VIEW_ROTATED) {
return obj->base.size;
+   } else if (view->type == I915_GGTT_VIEW_PARTIAL) {
+   return view->params.partial.size << PAGE_SHIFT;
} else {
WARN_ONCE(1, "GGTT view %u not implemented!\n", view->type);
return obj->base.size;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 34b7cca..96a9ef7 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -117,7 +117,8 @@ typedef uint64_t gen8_pde_t;

  enum i915_ggtt_view_type {
I915_GGTT_VIEW_NORMAL = 0,
-   I915_GGTT_VIEW_ROTATED
+   I915_GGTT_VIEW_ROTATED,
+   I915_GGTT_VIEW_PARTIAL,
  };

  struct intel_rotation_info {
@@ -130,6 +131,13 @@ struct intel_rotation_info {
  struct i915_ggtt_view {
enum i915_ggtt_view_type type;

+   union {
+   struct {
+   unsigned long offset;
+   unsigned int size;
+   } partial;
+   } params;
+
struct sg_table *pages;

union {
@@ -495,7 +503,10 @@ i915_ggtt_view_equal(const struct i915_ggtt_view *a,
if (WARN_ON(!a || !b))
return false;

-   return a->type == b->type;
+   if (a->type != b->type)
+   return false;
+
+   return !memcmp(&a->params, &b->params, sizeof(a->params));


Still don't like this, would this be so bad:

if (a->type != PARTIAL)
return a->type == b->type;
else
return !memcmp(...)

?

Regards,

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

Re: [Intel-gfx] drm/i915/gen8: page directories rework allocation

[Dave Gordon]

On 30/04/15 11:47, Dan Carpenter wrote:
> Hi Michel,
> 
> The patch 69876bed7e00: "drm/i915/gen8: page directories rework
> allocation" from Apr 8, 2015, has the following issue:
> 
>   drivers/gpu/drm/i915/i915_gem_gtt.c:760
>   warn: too many zeroes
> 
> drivers/gpu/drm/i915/i915_gem_gtt.c
>746  static int gen8_ppgtt_alloc_page_directories(struct i915_hw_ppgtt 
> *ppgtt,
>747   struct 
> i915_page_directory_pointer *pdp,
>748   uint64_t start,
>749   uint64_t length,
>750   unsigned long *new_pds)
>751  {
>752  struct drm_device *dev = ppgtt->base.dev;
>753  struct i915_page_directory *pd;
>754  uint64_t temp;
>755  uint32_t pdpe;
>756  
>757  WARN_ON(!bitmap_empty(new_pds, GEN8_LEGACY_PDPES));
>758  
>759  /* FIXME: PPGTT container_of won't work for 64b */
>760  WARN_ON((start + length) > 0x8ULL);
>  ^
> This last zero was not intended.

Wouldn't (1ULL << 31) be clearer?

And shouldn't it be >= not > ?

Or perhaps,
/* FIXME: upper bound must not overflow 31 bits */
WARN_ON((start + length) & (~0ULL << 31));

Pick whichever you think is most comprehensible and least typo-prone!

.Dave.

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

Re: [Intel-gfx] [PATCH v2 5/5] drm/i915: Use partial view in mmap fault handler

[Tvrtko Ursulin]

On 04/30/2015 12:21 PM, Joonas Lahtinen wrote:


Use partial view for huge BOs (bigger than the mappable aperture)
in fault handler so that they can be accessed without trying to make
room for them by evicting other objects.

v2:
- Only use partial views in the case where early rejection was
   previously done.
- Account variable type changes from previous reroll.

Cc: Chris Wilson 
Signed-off-by: Joonas Lahtinen 
---
  drivers/gpu/drm/i915/i915_gem.c | 69 +++--
  1 file changed, 46 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a020836..2f3fa0b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1635,6 +1635,7 @@ int i915_gem_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)
struct drm_i915_gem_object *obj = to_intel_bo(vma->vm_private_data);
struct drm_device *dev = obj->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
+   struct i915_ggtt_view view = i915_ggtt_view_normal;
pgoff_t page_offset;
unsigned long pfn;
int ret = 0;
@@ -1667,8 +1668,21 @@ int i915_gem_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)
goto unlock;
}

-   /* Now bind it into the GTT if needed */
-   ret = i915_gem_obj_ggtt_pin(obj, 0, PIN_MAPPABLE);
+   /* Use a partial view if the object is bigger than the aperture. */
+   if (obj->base.size >= dev_priv->gtt.mappable_end) {
+   static const unsigned int chunk_size = 256; // 1 MiB
+   memset(&view, 0, sizeof(view));


I think you don't need to memset since you assigned normal view to it.


+   view.type = I915_GGTT_VIEW_PARTIAL;
+   view.params.partial.offset = rounddown(page_offset, chunk_size);
+   view.params.partial.size =
+   min_t(unsigned int,
+ chunk_size,
+ (vma->vm_end - vma->vm_start)/PAGE_SIZE -
+ view.params.partial.offset);
+   }
+
+   /* Now pin it into the GTT if needed */
+   ret = i915_gem_object_ggtt_pin(obj, &view, 0, PIN_MAPPABLE);


Next fault outside this partial view will create a new vma? Is there 
something which would remove the old one for that case? Or they are just 
allowed to accumulate?


Regards,

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

[Intel-gfx] [QA 2015/04/30 ww18] Testing report for `drm-intel-testing`

[Zheng, Jeff]

Summary
We covered the platforms: Skylake, Braswell, Broadwell, Haswell, Baytrail and 
SandyBridge. In this circle, 10 new bugs have been found in manual testing and 
6 new bugs have been found in nightly testing.
90239 - [SKL desktop] DP 
hotplug cause " CPU pipe A FIFO underrun" ERROR
90238 - [SKL desktop] HDMI 
"testdisplay -y" shows wrong picture on every interlaced scanning resolution
90237 - [SKL desktop] 
"testdisplay -a" causes Call Trace
90228 - [BSW] hotplug 
events floods
90227 - [BSW bisected] 
*ERROR* mismatch in has_infoframe (expected 1, found 0) when booting with HDMI 
monitor connected
90059 - [BYT/BSW 
bisected]Start up the machine with HDMI screen causes WARNING
90212 - [BDW-Y bisected] 
Screen flicker when start X with FBC enable
90225 - [BYT] Testdisplay 
cause abnormal output in dmesg when HDMI monitor is connected.
90236 - [HSW mobile 
Bisected] Screen is blank while run "mplayer -vo vaapi -va vaapi "
90253 - [SNB]System fails 
to suspend from second time


Test Environment
Kernel version: drm-intel-testing-2015-04-23 commit 
fdbbf0fbf554cf32525b21640cfb0dadb922ed7f

Quality Status
Platform

Status

SKL

3 new bugs found in SKL-H desktop. Besides S3/S3 fail to suspend that is 
general kernel issue.
90239 - [SKL desktop] DP 
hotplug cause " CPU pipe A FIFO underrun" ERROR
90238 - [SKL desktop] HDMI 
"testdisplay -y" shows wrong picture on every interlaced scanning resolution
90237 - [SKL desktop] 
"testdisplay -a" causes Call Trace
89792 - [BYT/BSW/SKL 
Debugfs] cat /sys/kernel/debug/dri/0/i915_sr_status showing self-refresh: 
disabled
89596 - [SKL]System output 
"ERROR" when it resumes from S4 connecting DP monitor
89594 - [SKL] DP monitor 
can't be lighted up with raw X on 4k resolution after hoplug
89055 [SKL 
mobile]"testdisplay -a "case causes Call Trace "at 
drivers/gpu/drm/i915/intel_pm.c"


BSW

With BIOS 61.3 and 68.1, eDP is black when booting with DP monitor connected. 
So QA tests with V59 BIOS.

The main issues found in manual testing are:

1.   Hotplug issues (89668, 89461)

2.   Testdisplay issues (89832,89606,89605)

3.   Dmesg ERROR(90227,89601)

4.   GPU hang(89600)


90228 - [BSW] hotplug 
events floods
90227 - [BSW bisected] 
*ERROR* mismatch in has_infoframe (expected 1, found 0) when booting with HDMI 
monitor connected
90059 - [BYT/BSW 
bisected]Start up the machine with HDMI screen causes WARNING
86684 - [BYT/BSW] 
igt/kms_psr_sink_crc subcases fail after PSR is enabled in kernel
89832 - [BSW] "testdisplay 
-a" shows black for some modes on ASUS PA238Q
89792 - [BYT/BSW/SKL 
Debugfs] cat /sys/kernel/debug/dri/0/i915_sr_status showing self-refresh: 
disabled
89668 [BSW] HDMI screen 
becomes black after replug HDMI cable
89606 [BSW] DVI screen is 
black on some modes when running testdisplay
89605 [BSW] testdisplay on 
3 pipe does not show in one monitor
89601 [BSW] Sometimes dmesg 
shows " *ERROR* EDID checksum is invalid" when connected with HDMI monitor
89600 [BSW] GPU hangs after 
S3 + S4
89585 - [BSW]HDMI 
resolution-2560x1440@60Hz can't be lighted up with non-reduced blanking
89461 - [BSW] replug 
HDMI/DP cable does not light up screen sometimes
88963 [BSW] DP screen is 
black when running testdisplay on some modes

Fixed bugs:
90006 - [BSW] ASUS PA238Q 
DP screen is black after system boots
90012

Re: [Intel-gfx] [PATCH] drm/i915: Preallocate request before access of the ring

[Dave Gordon]

On 29/04/15 17:10, yu@intel.com wrote:
> From: Alex Dai 
> 
> This is to avoid bad IO access caused by writing NOOP to wrap the
> ring buffer whilst ring is unpinned.
> 
> Signed-off-by: Alex Dai 
> ---
>  drivers/gpu/drm/i915/intel_lrc.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 732fd63..3e8fcfd 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -803,12 +803,12 @@ static int intel_logical_ring_begin(struct 
> intel_ringbuffer *ringbuf,
>   if (ret)
>   return ret;
>  
> - ret = logical_ring_prepare(ringbuf, ctx, num_dwords * sizeof(uint32_t));
> + /* Preallocate the olr before touching the ring */
> + ret = i915_gem_request_alloc(ring, ctx);
>   if (ret)
>   return ret;
>  
> - /* Preallocate the olr before touching the ring */
> - ret = i915_gem_request_alloc(ring, ctx);
> + ret = logical_ring_prepare(ringbuf, ctx, num_dwords * sizeof(uint32_t));
>   if (ret)
>   return ret;

Reviewed-by: Dave Gordon 

with input also from John Harrison , who
would like to point out that this will be superceded by the Anti-OLR
patches already posted. (In that model, the request will be allocated
much earlier, and passed around explicitly rather than dangling from the
context).

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

Re: [Intel-gfx] [PATCH v5 1/8] drm/i915/skl: Add support to load SKL CSR firmware.

[Imre Deak]

On ke, 2015-04-29 at 22:59 +0530, Animesh Manna wrote:
> From: "A.Sunil Kamath" 
> 
> Display Context Save and Restore support is needed for
> various SKL Display C states like DC5, DC6.
> 
> This implementation is added based on first version of DMC CSR program
> that we received from h/w team.
> 
> Here we are using request_firmware based design.
> Finally this firmware should end up in linux-firmware tree.
> 
> For SKL platform its mandatory to ensure that we load this
> csr program before enabling DC states like DC5/DC6.
> 
> As CSR program gets reset on various conditions, we should ensure
> to load it during boot and in future change to be added to load
> this system resume sequence too.
> 
> v1: Initial relese as RFC patch
> 
> v2: Design change as per Daniel, Damien and Shobit's review comments
> request firmware method followed.
> 
> v3: Some optimization and functional changes.
> Pulled register defines into drivers/gpu/drm/i915/i915_reg.h
> Used kmemdup to allocate and duplicate firmware content.
> Ensured to free allocated buffer.
> 
> v4: Modified as per review comments from Satheesh and Daniel
> Removed temporary buffer.
> Optimized number of writes by replacing I915_WRITE with I915_WRITE64.
> 
> v5:
> Modified as per review comemnts from Damien.
> - Changed name for functions and firmware.
> - Introduced HAS_CSR.
> - Reverted back previous change and used csr_buf with u8 size.
> - Using cpu_to_be64 for endianness change.
> 
> Modified as per review comments from Imre.
> - Modified registers and macro names to be a bit closer to bspec terminology
> and the existing register naming in the driver.
> - Early return for non SKL platforms in intel_load_csr_program function.
> - Added locking around CSR program load function as it may be called
> concurrently during system/runtime resume.
> - Releasing the fw before loading the program for consistency
> - Handled error path during f/w load.
> 
> v6: Modified as per review comments from Imre.
> - Corrected out_freecsr sequence.
> 
> v7: Modified as per review comments from Imre.
> Fail loading fw if fw->size%8!=0.
> 
> v8: Rebase to latest.
> 
> v9: Rebase on top of -nightly (Damien)
> 
> v10: Enabled support for dmc firmware ver 1.0.
> According to ver 1.0 in a single binary package all the firmware's that are
> required for different stepping's of the product will be stored. The package
> contains the css header, followed by the package header and the actual dmc
> firmwares. Package header contains the firmware/stepping mapping table and
> the corresponding firmware offsets to the individual binaries, within the
> package. Each individual program binary contains the header and the payload
> sections whose size is specified in the header section. This changes are done
> to extract the specific firmaware from the package. (Animesh)
> 
> v11: Modified as per review comemnts from Imre.
> - Added code comment from bpec for header structure elements.
> - Added __packed to avoid structure padding.
> - Added helper functions for stepping and substepping info.
> - Added code comment for CSR_MAX_FW_SIZE.
> - Disabled BXT firmware loading, will be enabled with dmc 1.0 support.
> - Changed skl_stepping_info based on bspec, earlier used from config DB.
> - Removed duplicate call of cpu_to_be* from intel_csr_load_program function.
> - Used cpu_to_be32 instead of cpu_to_be64 as firmware binary in dword aligned.
> - Added sanity check for header length.
> - Added sanity check for mmio address got from firmware binary.
> - kmalloc done separately for dmc header and dmc firmware. (Animesh)
> 
> v12: Modified as per review comemnts from Imre.
> - Corrected the typo error in skl stepping info structure.
> - Added out-of-bound access for skl_stepping_info.
> - Sanity check for mmio address modified.
> - Sanity check added for stepping and substeppig.
> - Modified the intel_dmc_info structure, cache only the required header info. 
> (Animesh)
> 
> v13: clarify firmware load error message.
> The reason for a firmware loading failure can be obscure if the driver
> is built-in. Provide an explanation to the user about the likely reason for
> the failure and how to resolve it. (Imre)
> 
> v14: Suggested by Jani.
> - fix s/I915/CONFIG_DRM_I915/ typo
> - add fw_path to the firmware object instead of using a static ptr (Jani)
> 
> v15:
> 1) Changed the firmware name as dmc_gen9.bin, everytime for a new firmware 
> version a symbolic link
> with same name will help not to build kernel again.
> 2) Changes done as per review comments from Imre.
> - Error check removed for intel_csr_ucode_init.
> - Moved csr-specific data structure to intel_csr.h and optimization done on 
> structure definition.
> - fw->data used directly for parsing the header info & memory allocation
> only done separately for payload. (Animesh)
> 
> v16:
> - No need for out_regs label in i915_driver_load(), so removed it.
> - Changed the firmware name as skl_dmc_ver1.bin, followed naming convention 
> _dmc_.bi

Re: [Intel-gfx] [PATCH v5 2/2] drm/i915/skl: Add DC5 Trigger Sequence

[Imre Deak]

On pe, 2015-04-17 at 19:46 +0530, Animesh Manna wrote:
> From: Suketu Shah 
> 
> Add triggers as per expectations mentioned in gen9_enable_dc5
> and gen9_disable_dc5 patch.
> 
> Also call POSTING_READ for every write to a register to ensure that
> its written immediately.
> 
> v1: Remove POSTING_READ calls as they've already been added in previous 
> patches.
> 
> v2: Rebase to move all runtime pm specific changes to intel_runtime_pm.c file.
> 
> Modified as per review comments from Imre:
> 1] Change variable name 'dc5_allowed' to 'dc5_enabled' to correspond to 
> relevant
>functions.
> 2] Move the check dc5_enabled in skl_set_power_well() to disable DC5 into
>gen9_disable_DC5 which is a more appropriate place.
> 3] Convert checks for 'pm.dc5_enabled' and 'pm.suspended' in 
> skl_set_power_well()
>to warnings. However, removing them for now as they'll be included in a 
> future patch
>asserting DC-state entry/exit criteria.
> 4] Enable DC5, only when CSR firmware is verified to be loaded. Create new 
> structure
>to track 'enabled' and 'deferred' status of DC5.
> 5] Ensure runtime PM reference is obtained, if CSR is not loaded, to avoid 
> entering
>runtime-suspend and release it when it's loaded.
> 6] Protect necessary CSR-related code with locks.
> 7] Move CSR-loading call to runtime PM initialization, as power domains 
> needed to be
>accessed during deferred DC5-enabling, are not initialized earlier.
> 
> v3: Rebase to latest.
> 
> Modified as per review comments from Imre:
> 1] Use blocking wait for CSR-loading to finish to enable DC5  for simplicity, 
> instead of
>deferring enabling DC5 until CSR is loaded.
> 2] Obtain runtime PM reference during CSR-loading initialization itself as 
> deferred DC5-
>enabling is removed and release it at the end of CSR-loading functionality.
> 3] Revert calling CSR-loading functionality to the beginning of i915 
> driver-load
>functionality to avoid any delay in loading.
> 4] Define another variable to track whether CSR-loading failed and use it to 
> avoid enabling
>DC5 if it's true.
> 5] Define CSR-load-status accessor functions for use later.
> 
> v4:
> 1] Disable DC5 before enabling PG2 instead of after it.
> 2] DC5 was being mistaken enabled even when CSR-loading timed-out. Fix that.
> 3] Enable DC5-related functionality using a macro.
> 4] Remove dc5_enabled tracking variable and its use as it's not needed now.
> 
> v5:
> 1] Mark CSR failed to load where necessary in finish_csr_load function.
> 2] Use mutex-protected accessor function to check if CSR loaded instead of 
> directly
>accessing the variable.
> 3] Prefix csr_load_status_get/set function names with intel_.
> 
> v6: rebase to latest.
> v7: Rebase on top of nightly (Damien)
> v8: Squashed the patch from Imre - added csr helper pointers to simplify the 
> code. (Imre)
> v9: After adding dmc ver 1.0 support rebased on top of nightly. (Animesh)
> v10: Added a enum for different csr states, suggested by Imre. (Animesh)
> 
> v11: Based on review comments from Imre, Damien and Daniel following changes 
> done
> - enum name chnaged to csr_state (singular form).
> - FW_UNINITIALIZED used as zeroth element in enum csr_state.
> - Prototype changed for helper function(set/get csr status), using enum 
> csr_state instead of bool.
> 
> v12: Based on review comment from Imre, introduced bool fw_loaded local to 
> finish_csr_load() which helps
> calling once to set the csr status. The same flag used to fail RPM if find 
> any issue during
> firmware loading.
> 
> Issue: VIZ-2819
> Signed-off-by: A.Sunil Kamath 
> Signed-off-by: Suketu Shah 
> Signed-off-by: Damien Lespiau 
> Signed-off-by: Imre Deak 
> Signed-off-by: Animesh Manna 

This adds some checkpatch warnings, but they are fixed later in the
patchset. As discussed earlier in the future let's avoid such rewrites
in the same patchset.

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/i915_drv.h |  7 ++
>  drivers/gpu/drm/i915/intel_csr.c| 42 
> +++--
>  drivers/gpu/drm/i915/intel_drv.h|  3 +++
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 33 ++
>  4 files changed, 83 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 90e47a9..670e407 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -667,6 +667,12 @@ struct intel_uncore {
>  #define for_each_fw_domain(domain__, dev_priv__, i__) \
>   for_each_fw_domain_mask(domain__, FORCEWAKE_ALL, dev_priv__, i__)
>  
> +enum csr_state {
> + FW_UNINITIALIZED = 0,
> + FW_LOADED,
> + FW_FAILED
> +};
> +
>  struct intel_csr {
>   const char *fw_path;
>   __be32 *dmc_payload;
> @@ -674,6 +680,7 @@ struct intel_csr {
>   uint32_t mmio_count;
>   uint32_t mmioaddr[8];
>   uint32_t mmiodata[8];
> + enum csr_state state;
>  };
>  
>  #define DEV_INFO_FO

Re: [Intel-gfx] [PATCH v4 3/8] drm/i915/skl: Implement enable/disable for Display C5 state.

[Imre Deak]

On to, 2015-04-16 at 14:22 +0530, Animesh Manna wrote:
> From: "A.Sunil Kamath" 
> 
> This patch just implements the basic enable and disable
> functions of DC5 state which is needed for both SKL and BXT.
> 
> Its important to load respective CSR program before calling
> enable, which anyways will happen as CSR program is executed
> during boot.
> 
> DC5 is a power saving state where hardware dynamically disables
> power well 1 and the CDCLK PLL and saves the associated registers.
> 
> DC5 can be entered when software allows it, power well 2 is
> disabled, and hardware detects that all pipes are disabled
> or pipe A is enabled with PSR active.
> 
> Its better to configure display engine to have power well 2 disabled before
> getting into DC5 enable function. Hence rpm framework will have to
> ensure to check status of power well 2 before calling gen9_enable_dc5.
> 
> Rather dc5 entry criteria should be decided based on power well 2 status.
> If disabled, then call gen9_enable_dc5.
> 
> v2: Replace HAS_ with IS_ check as per Daniel's review comments
> 
> v3: Cleared the bits dc5/dc6 enable of DC_STATE_EN register
> before setting them as per Satheesh's review comments.
> 
> v4: call POSTING_READ for every write to a register to ensure that
> its written immediately.
> 
> v5: Modified as per review comments from Imre.
> - Squashed register definitions into this patch.
> - Finetuned comments and functions.
> 
> v6:
> Avoid redundant writes in gen9_set_dc_state_debugmask_memory_up function.
> 
> v7:
> 1] Rebase to latest.
> 2] Move all runtime PM functions defined in intel_display.c to
>intel_runtime_pm.c.
> 
> v8: Rebased to drm-intel-nightly. (Animesh)
> 
> Issue: VIZ-2819
> Signed-off-by: A.Sunil Kamath 
> Signed-off-by: Damien Lespiau 
> Signed-off-by: Animesh Manna 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/i915_reg.h | 11 +
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 41 
> +++--
>  2 files changed, 50 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 596e8eb..dcb8528 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6792,6 +6792,17 @@ enum skl_disp_power_wells {
>  #define GET_CFG_CR1_REG(id) (DPLL1_CFGCR1 + (id - SKL_DPLL1) * 8)
>  #define GET_CFG_CR2_REG(id) (DPLL1_CFGCR2 + (id - SKL_DPLL1) * 8)
>  
> +/*
> +* SKL DC
> +*/
> +#define  DC_STATE_EN 0x45504
> +#define  DC_STATE_EN_UPTO_DC5(1<<0)
> +#define  DC_STATE_EN_UPTO_DC6(2<<0)
> +#define  DC_STATE_EN_UPTO_DC5_DC6_MASK   0x3
> +
> +#define  DC_STATE_DEBUG  0x45520
> +#define  DC_STATE_DEBUG_MASK_MEMORY_UP   (1<<1)
> +
>  /* Please see hsw_read_dcomp() and hsw_write_dcomp() before using this 
> register,
>   * since on HSW we can't write to it using I915_WRITE. */
>  #define D_COMP_HSW   (MCHBAR_MIRROR_BASE_SNB + 0x5F0C)
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 23f02a8..466ea69 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -321,14 +321,51 @@ static void hsw_set_power_well(struct drm_i915_private 
> *dev_priv,
>   SKL_DISPLAY_MISC_IO_POWER_DOMAINS)) |   \
>   BIT(POWER_DOMAIN_INIT))
>  
> +static void gen9_set_dc_state_debugmask_memory_up(
> + struct drm_i915_private *dev_priv)
> +{
> + uint32_t val;
> +
> + /* The below bit doesn't need to be cleared ever afterwards */
> + val = I915_READ(DC_STATE_DEBUG);
> + if (!(val & DC_STATE_DEBUG_MASK_MEMORY_UP)) {
> + val |= DC_STATE_DEBUG_MASK_MEMORY_UP;
> + I915_WRITE(DC_STATE_DEBUG, val);
> + POSTING_READ(DC_STATE_DEBUG);
> + }
> +}
> +
>  static void gen9_enable_dc5(struct drm_i915_private *dev_priv)
>  {
> - /* TODO: Implementation to be done. */
> + struct drm_device *dev = dev_priv->dev;
> + uint32_t val;
> +
> + WARN_ON(!IS_GEN9(dev));
> +
> + 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);
>  }
>  
>  static void gen9_disable_dc5(struct drm_i915_private *dev_priv)
>  {
> - /* TODO: Implementation to be done. */
> + struct drm_device *dev = dev_priv->dev;
> + uint32_t val;
> +
> + WARN_ON(!IS_GEN9(dev));
> +
> + 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);
>  }
>  
>  static void skl_set_power_well(struct drm_i915_private *dev_priv,


___
Intel-gfx mailing list
Intel

Re: [Intel-gfx] [PATCH v4 4/8] drm/i915/skl: Assert the requirements to enter or exit DC5.

[Imre Deak]

On to, 2015-04-16 at 14:22 +0530, Animesh Manna wrote:
> From: Suketu Shah 
> 
> Warn if the conditions to enter or exit DC5 are not satisfied such
> as support for runtime PM, state of power well, CSR loading etc.
> 
> v2: Removed camelcase in functions and variables.
> 
> v3: Do some minimal check to assert if CSR program is not loaded.
> 
> v4:
> 1] Used an appropriate function lookup_power_well() to identify power well,
> instead of using a magic number which can change in future.
> 2] Split the conditions further in assert_can_enable_DC5() and added more 
> checks.
> 3] Removed all WARNs from assert_can_disable_DC5 as they were unnecessary and 
> added two
>new ones.
> 4] Changed variable names as updated in earlier patches.
> 
> v5:
> 1] Change lookup_power_well function to take an int power well id.
> 2] Define a new intel_display_power_well_is_enabled helper function to check 
> whether a
>particular power well is enabled.
> 3] Use CSR-related mutex in assert_csr_loaded function.
> 
> v6: Remove use of dc5_enabled variable as it's no longer needed.
> 
> v7:
> 1] Rebase to latest.
> 2] Move all DC5-related functions from intel_display.c to intel_runtime_pm.c.
> 
> v8: After adding dmc ver 1.0 support rebased on top of nightly. (Animesh)
> 
> v9: Modified below changes based on review comments from Imre.
> - Moved intel_display_power_well_is_enabled() to intel_runtime_pm.c.
> - Removed mutex lock from assert_csr_loaded(). (Animesh)
> 
> Issue: VIZ-2819
> Signed-off-by: A.Sunil Kamath 
> Signed-off-by: Suketu Shah 
> Signed-off-by: Damien Lespiau 
> Signed-off-by: Animesh Manna 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/intel_csr.c|  9 ++
>  drivers/gpu/drm/i915/intel_drv.h|  1 +
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 51 
> +
>  3 files changed, 56 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_csr.c 
> b/drivers/gpu/drm/i915/intel_csr.c
> index fe6789f..d58effe 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -410,3 +410,12 @@ void intel_csr_ucode_fini(struct drm_device *dev)
>   intel_csr_load_status_set(dev_priv, FW_FAILED);
>   kfree(dev_priv->csr.dmc_payload);
>  }
> +
> +void assert_csr_loaded(struct drm_i915_private *dev_priv)
> +{
> + WARN((intel_csr_load_status_get(dev_priv) != FW_LOADED), "CSR is not 
> loaded.\n");
> + WARN(!I915_READ(CSR_PROGRAM_BASE),
> + "CSR program storage start is NULL\n");
> + WARN(!I915_READ(CSR_SSP_BASE), "CSR SSP Base Not fine\n");
> + WARN(!I915_READ(CSR_HTP_SKL), "CSR HTP Not fine\n");
> +}
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 25d7956..2eb0169 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1069,6 +1069,7 @@ void intel_csr_load_status_set(struct drm_i915_private 
> *dev_priv,
>   enum csr_state state);
>  void intel_csr_load_program(struct drm_device *dev);
>  void intel_csr_ucode_fini(struct drm_device *dev);
> +void assert_csr_loaded(struct drm_i915_private *dev_priv);
>  
>  /* intel_dp.c */
>  void intel_dp_init(struct drm_device *dev, int output_reg, enum port port);
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 466ea69..da8c18d 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -64,6 +64,9 @@
>i--)\
>   if ((power_well)->domains & (domain_mask))
>  
> +bool intel_display_power_well_is_enabled(struct drm_i915_private *dev_priv,
> + int power_well_id);
> +
>  /*
>   * We should only use the power well if we explicitly asked the hardware to
>   * enable it, so check if it's enabled and also check if we've requested it 
> to
> @@ -335,12 +338,39 @@ static void gen9_set_dc_state_debugmask_memory_up(
>   }
>  }
>  
> -static void gen9_enable_dc5(struct drm_i915_private *dev_priv)
> +static void assert_can_enable_dc5(struct drm_i915_private *dev_priv)
>  {
>   struct drm_device *dev = dev_priv->dev;
> + bool pg2_enabled = intel_display_power_well_is_enabled(dev_priv,
> + SKL_DISP_PW_2);
> +
> + WARN(!IS_SKYLAKE(dev), "Platform doesn't support DC5.\n");
> + WARN(!HAS_RUNTIME_PM(dev), "Runtime PM not enabled.\n");
> + WARN(pg2_enabled, "PG2 not disabled to enable DC5.\n");
> +
> + WARN((I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC5),
> + "DC5 already programmed to be enabled.\n");
> + WARN(dev_priv->pm.suspended,
> + "DC5 cannot be enabled, if platform is runtime-suspended.\n");
> +
> + assert_csr_loaded(dev_priv);
> +}
> +
> +static void assert_can_disable_dc5(struct drm_i915_private *dev_

Re: [Intel-gfx] [PATCH v3] drm/i915: Add missing MacBook Pro models with dual channel LVDS

[Lukas Wunner]

Single channel LVDS maxes out at 112 MHz. All 17" models with i915
graphics had a resolution of 1920x1200 (193 MHz), necessitating dual
channel LVDS. The 15" pre-retina models had either 1440x900 (106 MHz)
or 1680x1050 (119 MHz), both versions used dual channel LVDS even
though the smaller one would have fit into a single channel.

v2: Assume dual channel LVDS if the pixel clock necessitates it,
eliminating the need to hardcode 17" models, suggested by Jani Nikula.

v3: Fix typo, thanks Joonas Lahtinen.

Signed-off-by: Lukas Wunner 
Tested-by: Lukas Wunner 
Acked-by: Jani Nikula 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/i915/intel_lvds.c | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index 071b96d..417ccab 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -812,12 +812,28 @@ static int intel_dual_link_lvds_callback(const struct 
dmi_system_id *id)
 static const struct dmi_system_id intel_dual_link_lvds[] = {
{
.callback = intel_dual_link_lvds_callback,
-   .ident = "Apple MacBook Pro (Core i5/i7 Series)",
+   .ident = "Apple MacBook Pro 15\" (2010)",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro6,2"),
+   },
+   },
+   {
+   .callback = intel_dual_link_lvds_callback,
+   .ident = "Apple MacBook Pro 15\" (2011)",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro8,2"),
},
},
+   {
+   .callback = intel_dual_link_lvds_callback,
+   .ident = "Apple MacBook Pro 15\" (2012)",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro9,1"),
+   },
+   },
{ } /* terminating entry */
 };
 
@@ -847,6 +863,11 @@ static bool compute_is_dual_link_lvds(struct 
intel_lvds_encoder *lvds_encoder)
if (i915.lvds_channel_mode > 0)
return i915.lvds_channel_mode == 2;
 
+   /* single channel LVDS is limited to 112 MHz */
+   if (lvds_encoder->attached_connector->base.panel.fixed_mode->clock
+   > 112999)
+   return true;
+
if (dmi_check_system(intel_dual_link_lvds))
return true;
 
@@ -1104,6 +1125,8 @@ void intel_lvds_init(struct drm_device *dev)
 out:
mutex_unlock(&dev->mode_config.mutex);
 
+   intel_panel_init(&intel_connector->panel, fixed_mode, downclock_mode);
+
lvds_encoder->is_dual_link = compute_is_dual_link_lvds(lvds_encoder);
DRM_DEBUG_KMS("detected %s-link lvds configuration\n",
  lvds_encoder->is_dual_link ? "dual" : "single");
@@ -1118,7 +1141,6 @@ out:
}
drm_connector_register(connector);
 
-   intel_panel_init(&intel_connector->panel, fixed_mode, downclock_mode);
intel_panel_setup_backlight(connector, INVALID_PIPE);
 
return;
-- 
1.8.5.2 (Apple Git-48)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 5/8] drm/i915/skl: Add DC6 Trigger sequence.

[Imre Deak]

On to, 2015-04-16 at 14:22 +0530, Animesh Manna wrote:
> From: Suketu Shah 
> 
> Add triggers for DC6 as per details provided in skl_enable_dc6
> and skl_disable_dc6 implementations.
> 
> Also Call POSTING_READ for every write to a register to ensure
> it is written to immediately
> 
> v1: Remove POSTING_READ and intel_prepare_ddi calls as they've been added in 
> previous patches.
> 
> v2:
> 1] Remove check for backlight disabled as it should be the case by that time.
> 2] Mark DC5 as disabled when enabling DC6.
> 3] Return from DC5-disabling function early if DC5 is already be disabled 
> which can happen
>due to DC6-enabling earlier.
> 3] Ensure CSR firmware is loaded after resume from DC6 as corresponding 
> memory contents won't
>be retained after runtime-suspend.
> 4] Ensure that CSR isn't identified as loaded before CSR-loading program is 
> called during
>runtime-resume.
> 
> v3: Rebase to latest
> Modified as per review comments from Imre and after discussion with Art:
> 1] DC6 should be preferably enabled when PG2 is disabled by SW as the check 
> for PG1 being
>disabled is taken of by HW to enter DC6, and disabled when PG2 is enabled 
> respectively.
>This helps save more power, especially in the case when display is 
> disabled but GT is
>enabled. Accordingly, replacing DC5 trigger sequence with DC6 for SKL.
> 2] DC6 could be enabled from intel_runtime_suspend() function, if DC5 is 
> already enabled.
> 3] Move CSR-load-status setting code from intel_runtime_suspend function to a 
> new function.
> 
> v4:
> 1] Enable/disable DC6 only when toggling the power-well using a newly defined 
> macro ENABLE_DC6.
> 
> v5:
> 1] Load CSR on system resume too as firmware may be lost on system suspend 
> preventing
>enabling DC5, DC6.
> 2] DDI buffers shouldn't be programmed during driver-load/resume as it's 
> already done
>during modeset initialization then and also that the encoder list is still 
> uninitialized by
>then. Therefore, call intel_prepare_ddi function right after disabling DC6 
> but outside
>skl_disable_dc6 function and not during driver-load/resume.
> 
> v6:
> 1] Rebase to latest.
> 2] Move SKL_ENABLE_DC6 macro definition from intel_display.c to 
> intel_runtime_pm.c.
> 
> v7:
> 1) Refactored the code for removing the warning got from checkpatch.
> 2) After adding dmc ver 1.0 support rebased on top of nightly. (Animesh)
> 
> v8:
> - Reverted the changes done in v7.
> - Removed the condition check in skl_prepare_resune(). (Animesh)
> 
> Issue: VIZ-2819
> Signed-off-by: A.Sunil Kamath 
> Signed-off-by: Suketu Shah 
> Signed-off-by: Damien Lespiau 
> Signed-off-by: Animesh Manna 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 30 +++
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 43 
> +++--
>  2 files changed, 66 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index acd0e2b..0f590e3 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -594,6 +594,8 @@ static void intel_suspend_encoders(struct 
> drm_i915_private *dev_priv)
>  static int intel_suspend_complete(struct drm_i915_private *dev_priv);
>  static int vlv_resume_prepare(struct drm_i915_private *dev_priv,
> bool rpm_resume);
> +static int skl_resume_prepare(struct drm_i915_private *dev_priv);
> +
>  
>  static int i915_drm_suspend(struct drm_device *dev)
>  {
> @@ -808,6 +810,8 @@ static int i915_drm_resume_early(struct drm_device *dev)
>  
>   if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
>   hsw_disable_pc8(dev_priv);
> + else if (IS_SKYLAKE(dev_priv))
> + ret = skl_resume_prepare(dev_priv);
>  
>   intel_uncore_sanitize(dev);
>   intel_power_domains_init_hw(dev_priv);
> @@ -1022,6 +1026,19 @@ static int i915_pm_resume(struct device *dev)
>   return i915_drm_resume(drm_dev);
>  }
>  
> +static int skl_suspend_complete(struct drm_i915_private *dev_priv)
> +{
> + /* Enabling DC6 is not a hard requirement to enter runtime D3 */
> +
> + /*
> +  * This is to ensure that CSR isn't identified as loaded before
> +  * CSR-loading program is called during runtime-resume.
> +  */
> + intel_csr_load_status_set(dev_priv, FW_UNINITIALIZED);
> +
> + return 0;
> +}
> +
>  static int hsw_suspend_complete(struct drm_i915_private *dev_priv)
>  {
>   hsw_enable_pc8(dev_priv);
> @@ -1029,6 +1046,15 @@ static int hsw_suspend_complete(struct 
> drm_i915_private *dev_priv)
>   return 0;
>  }
>  
> +static int skl_resume_prepare(struct drm_i915_private *dev_priv)
> +{
> + struct drm_device *dev = dev_priv->dev;
> +
> + intel_csr_load_program(dev);
> +
> + return 0;
> +}
> +
>  /*
>   * Save all Gunit registers that may be lost after a D3 and a subsequent
>   * S0i[R123] transition. The list of registers needing a save/restore is
> @@ -1487,6 

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Select starting pipe bpp irrespective or the primary plane

[Paulo Zanoni]

2015-04-15 8:06 GMT-03:00 Ander Conselvan De Oliveira :
> Reviewed-by: Ander Conselvan de Oliveira 
>
> On Fri, 2015-04-10 at 16:22 +0200, Daniel Vetter wrote:
>> Since universal planes the primary plane might not be around, and it's
>> kinda silly to restrict the pipe bpp to the primary plane if we might
>> end up displaying a 10bpc video overlay. And with atomic we might very
>> well enable a pipe without a primary plane. So just use the platform
>> max as a starting point and then restrict appropriately.
>>
>> Of course this is all still a bit moot as long as we artificially
>> compress everything to max 8bpc because we don't use the hi-bpc gamma
>> tables.
>>
>> Signed-off-by: Daniel Vetter 

This commit makes the HDMI colors look very funny on my BDW machine. I
just boot it with HDMI (no eDP), and I get this:
http://people.freedesktop.org/~pzanoni/color-regression.jpg (the
original wallpaper only has gradients of blue). Although I like the
new wallpaper color scheme, I don't think most users will.

Reverting this commit (and also "drm/i915: Drop unecessary fb
arguments from function signatures" in order to make things compile
again) fixes the problem for me.

Since this is a major issue for me, I'd be happy to test patches.

>> ---
>>  drivers/gpu/drm/i915/intel_display.c | 61 
>> +++-
>>  1 file changed, 12 insertions(+), 49 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 11b958a56515..b1afd7d5e28c 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -5869,14 +5869,6 @@ static int intel_crtc_compute_config(struct 
>> intel_crtc *crtc,
>>   adjusted_mode->hsync_start == adjusted_mode->hdisplay)
>>   return -EINVAL;
>>
>> - if ((IS_G4X(dev) || IS_VALLEYVIEW(dev)) && pipe_config->pipe_bpp > 
>> 10*3) {
>> - pipe_config->pipe_bpp = 10*3; /* 12bpc is gen5+ */
>> - } else if (INTEL_INFO(dev)->gen <= 4 && pipe_config->pipe_bpp > 8*3) {
>> - /* only a 8bpc pipe, with 6bpc dither through the panel fitter
>> -  * for lvds. */
>> - pipe_config->pipe_bpp = 8*3;
>> - }
>> -
>>   if (HAS_IPS(dev))
>>   hsw_compute_ips_config(crtc, pipe_config);
>>
>> @@ -10503,7 +10495,6 @@ connected_sink_compute_bpp(struct intel_connector 
>> *connector,
>>
>>  static int
>>  compute_baseline_pipe_bpp(struct intel_crtc *crtc,
>> -   struct drm_framebuffer *fb,
>> struct intel_crtc_state *pipe_config)
>>  {
>>   struct drm_device *dev = crtc->base.dev;
>> @@ -10511,41 +10502,13 @@ compute_baseline_pipe_bpp(struct intel_crtc *crtc,
>>   struct intel_connector *connector;
>>   int bpp, i;
>>
>> - switch (fb->pixel_format) {
>> - case DRM_FORMAT_C8:
>> - bpp = 8*3; /* since we go through a colormap */
>> - break;
>> - case DRM_FORMAT_XRGB1555:
>> - case DRM_FORMAT_ARGB1555:
>> - /* checked in intel_framebuffer_init already */
>> - if (WARN_ON(INTEL_INFO(dev)->gen > 3))
>> - return -EINVAL;
>> - case DRM_FORMAT_RGB565:
>> - bpp = 6*3; /* min is 18bpp */
>> - break;
>> - case DRM_FORMAT_XBGR:
>> - case DRM_FORMAT_ABGR:
>> - /* checked in intel_framebuffer_init already */
>> - if (WARN_ON(INTEL_INFO(dev)->gen < 4))
>> - return -EINVAL;
>> - case DRM_FORMAT_XRGB:
>> - case DRM_FORMAT_ARGB:
>> - bpp = 8*3;
>> - break;
>> - case DRM_FORMAT_XRGB2101010:
>> - case DRM_FORMAT_ARGB2101010:
>> - case DRM_FORMAT_XBGR2101010:
>> - case DRM_FORMAT_ABGR2101010:
>> - /* checked in intel_framebuffer_init already */
>> - if (WARN_ON(INTEL_INFO(dev)->gen < 4))
>> - return -EINVAL;
>> + if ((IS_G4X(dev) || IS_VALLEYVIEW(dev)))
>>   bpp = 10*3;
>> - break;
>> - /* TODO: gen4+ supports 16 bpc floating point, too. */
>> - default:
>> - DRM_DEBUG_KMS("unsupported depth\n");
>> - return -EINVAL;
>> - }
>> + else if (INTEL_INFO(dev)->gen >= 5)
>> + bpp = 12*3;
>> + else
>> + bpp = 8*3;
>> +
>>
>>   pipe_config->pipe_bpp = bpp;
>>
>> @@ -10756,7 +10719,7 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
>>   struct intel_connector *connector;
>>   struct drm_connector_state *connector_state;
>>   struct intel_crtc_state *pipe_config;
>> - int plane_bpp, ret = -EINVAL;
>> + int base_bpp, ret = -EINVAL;
>>   int i;
>>   bool retry = true;
>>
>> @@ -10801,9 +10764,9 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
>>* plane pixel format and any sink constraints into account. Returns 
>> the
>>* source plane bpp so that dithering can be selecte

Re: [Intel-gfx] [PATCH v4 6/8] Implement enable/disable for Display C6 state

[Imre Deak]

On to, 2015-04-16 at 14:22 +0530, Animesh Manna wrote:
> From: "A.Sunil Kamath" 
> 
> This patch just implements the basic enable and disable
> functions of DC6 state which is needed for SKL platform.
> 
> Its important to load SKL CSR program before calling enable.
> 
> DC6 is a deeper power saving state where hardware dynamically
> disables power well 0 and saves the associated registers.
> DC6 can be entered when software allows it, the conditions
> for DC5 are met, and the PCU allows DC6.
> DC6 cannot be used if the backlight is being driven from the
> display utility pin.
> 
> Its better to configure display engine to have power well 2
> disabled before getting into DC6 enable function. Hence rpm
> framework will ensure to check status of power well 2 and DC5
> before calling skl_enable_dc6.
> 
> v2: Replace HAS_ with IS_ check as per Daniel's review comments
> 
> v3: Cleared the bits dc5/dc6 enable of DC_STATE_EN register
> before setting them as per Satheesh's review comments.
> 
> v4: No need to call gen9_disable_dc5 inside enable sequence of
> DC6, as its already take care above.
> 
> v5: call POSTING_READ for every write to a register to ensure that
> its written immediately.
> Call intel_prepare_ddi during DC6 exit as it's required on low-power exit.
> 
> v6: Protect DC6-enabling-disabling functionality with locks to synchronize
> with CSR-loading code.
> 
> v7: Remove grabbing CSR-related mutex in skl_enable/disable_dc6 functions as
> deferred DC5-enabling functionality is now removed.
> 
> v8: Remove 'Disabling DC5' from the debug comment during DC6 enabling as when
> DC6 is allowed, DC5 is not programmed at all.
> 
> v9:
> 1] Rebase to latest.
> 2] Move all DC6-related functions from intel_display.c to intel_runtime_pm.c.
> 
> v10: After adding dmc ver 1.0 support rebased on top of nightly. (Animesh)
> 
> Issue: VIZ-2819
> Signed-off-by: A.Sunil Kamath 
> Signed-off-by: Damien Lespiau 
> Signed-off-by: Animesh Manna 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 27 +--
>  1 file changed, 25 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 7e6908e..ba49795 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -400,12 +400,35 @@ static void gen9_disable_dc5(struct drm_i915_private 
> *dev_priv)
>  
>  static void skl_enable_dc6(struct drm_i915_private *dev_priv)
>  {
> - /* TODO: Implementation to be done. */
> + struct drm_device *dev = dev_priv->dev;
> + uint32_t val;
> +
> + WARN_ON(!IS_SKYLAKE(dev));
> +
> + 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);
>  }
>  
>  static void skl_disable_dc6(struct drm_i915_private *dev_priv)
>  {
> - /* TODO: Implementation to be done. */
> + struct drm_device *dev = dev_priv->dev;
> + uint32_t val;
> +
> + WARN_ON(!IS_SKYLAKE(dev));
> +
> + DRM_DEBUG_KMS("Disabling DC6\n");
> +
> + val = I915_READ(DC_STATE_EN);
> + val &= ~DC_STATE_EN_UPTO_DC6;
> + I915_WRITE(DC_STATE_EN, val);
> + POSTING_READ(DC_STATE_EN);
>  }
>  
>  static void skl_set_power_well(struct drm_i915_private *dev_priv,


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

Re: [Intel-gfx] [PATCH v4 8/8] drm/i915/skl: Enable runtime PM

[Imre Deak]

On to, 2015-04-16 at 14:22 +0530, Animesh Manna wrote:
> From: Suketu Shah 
> 
> Enable runtime PM for Skylake platform
> 
> v2: After adding dmc ver 1.0 support rebased on top of nightly. (Animesh)
> 
> Issue: VIZ-2819
> Signed-off-by: A.Sunil Kamath 
> Signed-off-by: Suketu Shah 
> Signed-off-by: Damien Lespiau 
> Signed-off-by: Animesh Manna 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/i915_drv.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 670e407..e8d27eb 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2442,7 +2442,8 @@ struct drm_i915_cmd_table {
>IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev) || \
>IS_SKYLAKE(dev))
>  #define HAS_RUNTIME_PM(dev)  (IS_GEN6(dev) || IS_HASWELL(dev) || \
> -  IS_BROADWELL(dev) || IS_VALLEYVIEW(dev))
> +  IS_BROADWELL(dev) || IS_VALLEYVIEW(dev) || \
> +  IS_SKYLAKE(dev))
>  #define HAS_RC6(dev) (INTEL_INFO(dev)->gen >= 6)
>  #define HAS_RC6p(dev)(INTEL_INFO(dev)->gen == 6 || 
> IS_IVYBRIDGE(dev))
>  


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

[Intel-gfx] [PATCH] drm/i915: Fix 32b overflow check in gen8_ppgtt_alloc_page_directories

[Michel Thierry]

The patch 69876bed7e008f5fe01538a2d47c09f2862129d0: "drm/i915/gen8:
page directories rework allocation" added an overflow warning, but the
mask had an extra 0. Use typo-prone option suggested by Dave instead.

This check will be unnecessary after gen8_alloc_va_range handles more
than 4 PDPs (48b addressing).

Reported-by: Dan Carpenter 
Cc: Dave Gordon 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 6fae6bd..6d894fc 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -756,8 +756,8 @@ static int gen8_ppgtt_alloc_page_directories(struct 
i915_hw_ppgtt *ppgtt,
 
WARN_ON(!bitmap_empty(new_pds, GEN8_LEGACY_PDPES));
 
-   /* FIXME: PPGTT container_of won't work for 64b */
-   WARN_ON((start + length) > 0x8ULL);
+   /* FIXME: upper bound must not overflow 31 bits  */
+   WARN_ON((start + length) & (~0ULL << 31));
 
gen8_for_each_pdpe(pd, pdp, start, length, temp, pdpe) {
if (pd)
-- 
2.1.1

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

Re: [Intel-gfx] [PATCH v4] drm/i915/chv: Set min freq to efficient frequency on chv

[Ville Syrjälä]

On Thu, Apr 30, 2015 at 02:19:07PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 30, 2015 at 03:42:42PM +0530, Deepak S wrote:
> > As you suggested it would be better to extend the VLV WA to
> > CHV also to make sure we drop the voltage when idle.
> > 
> > Below is the sequence I think we should follow (based  on your comments).
> > 1. forcewake power wells
> > 2. do gfx force clock on
> > 3. request freq to punit
> > 4. release gfx force clock on
> > 5. release forcewake of power wells.
> > 
> > Please share your thoughts?
> 
> I'm thinking we shouldn't need the gfx clock force since forcewake
> should already cause the clock to be enabled.
> 
> I've also not verified what happens if we drop the forcewake before
> Punit has actually finished the frequency change. I'll try to hack
> up some kind of test to see if I can make that happen.

OK, after some hacking I see that the forcewake is enough, and also
we don't seem to need to wait for the Punit to finish the frequency
change before dropping forcewake. It seems to finish the change even
after forcewake has been dropped.

Also for a bit of extra micro optimization we should perhaps wake up
the media well only, as that takes a lot less power than the render
well.

> 
> > 
> > Thanks
> > Deepak
> > 
> > >> So based on my tests this patch feels a bit wrong.
> > >>
> > >>> Since Punit validates the rps range [RPe, RP0]. This patch
> > >>> removes unused cherryview_rps_min_freq function.
> > >>>
> > >>> v2: Change commit message
> > >>>
> > >>> v3: set min_freq before idle_freq (chris)
> > >>>
> > >>> v4: Squash 'Remove unused rps min function' patch
> > >>>
> > >>> Signed-off-by: Deepak S 
> > >>> Acked-by: Chris Wilson 
> > >>> ---
> > >>>   drivers/gpu/drm/i915/intel_pm.c | 21 ++---
> > >>>   1 file changed, 2 insertions(+), 19 deletions(-)
> > >>>
> > >>> diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > >>> b/drivers/gpu/drm/i915/intel_pm.c
> > >>> index a7516ed..78c89ff 100644
> > >>> --- a/drivers/gpu/drm/i915/intel_pm.c
> > >>> +++ b/drivers/gpu/drm/i915/intel_pm.c
> > >>> @@ -4715,24 +4715,6 @@ static int cherryview_rps_guar_freq(struct 
> > >>> drm_i915_private *dev_priv)
> > >>> return rp1;
> > >>>   }
> > >>>   
> > >>> -static int cherryview_rps_min_freq(struct drm_i915_private *dev_priv)
> > >>> -{
> > >>> -   struct drm_device *dev = dev_priv->dev;
> > >>> -   u32 val, rpn;
> > >>> -
> > >>> -   if (dev->pdev->revision >= 0x20) {
> > >>> -   val = vlv_punit_read(dev_priv, 
> > >>> FB_GFX_FMIN_AT_VMIN_FUSE);
> > >>> -   rpn = ((val >> FB_GFX_FMIN_AT_VMIN_FUSE_SHIFT) &
> > >>> -  FB_GFX_FREQ_FUSE_MASK);
> > >>> -   } else { /* For pre-production hardware */
> > >>> -   val = vlv_punit_read(dev_priv, PUNIT_GPU_STATUS_REG);
> > >>> -   rpn = ((val >> PUNIT_GPU_STATIS_GFX_MIN_FREQ_SHIFT) &
> > >>> -  PUNIT_GPU_STATUS_GFX_MIN_FREQ_MASK);
> > >>> -   }
> > >>> -
> > >>> -   return rpn;
> > >>> -}
> > >>> -
> > >>>   static int valleyview_rps_guar_freq(struct drm_i915_private *dev_priv)
> > >>>   {
> > >>> u32 val, rp1;
> > >>> @@ -4984,7 +4966,8 @@ static void cherryview_init_gt_powersave(struct 
> > >>> drm_device *dev)
> > >>>  intel_gpu_freq(dev_priv, 
> > >>> dev_priv->rps.rp1_freq),
> > >>>  dev_priv->rps.rp1_freq);
> > >>>   
> > >>> -   dev_priv->rps.min_freq = cherryview_rps_min_freq(dev_priv);
> > >>> +   /* PUnit validated range is only [RPe, RP0] */
> > >>> +   dev_priv->rps.min_freq = dev_priv->rps.efficient_freq;
> > >>> DRM_DEBUG_DRIVER("min GPU freq: %d MHz (%u)\n",
> > >>>  intel_gpu_freq(dev_priv, 
> > >>> dev_priv->rps.min_freq),
> > >>>  dev_priv->rps.min_freq);
> > >>> -- 
> > >>> 1.9.1
> > >> -- 
> > >> Ville Syrjälä
> > >> Intel OTC
> > >> ___
> > >> Intel-gfx mailing list
> > >> Intel-gfx@lists.freedesktop.org
> > >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Ville Syrjälä
> Intel OTC

-- 
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 v3] drm/i915: Add missing MacBook Pro models with dual channel LVDS

[Ville Syrjälä]

On Thu, Apr 30, 2015 at 03:28:11PM +0200, Lukas Wunner wrote:
> Single channel LVDS maxes out at 112 MHz. All 17" models with i915
> graphics had a resolution of 1920x1200 (193 MHz), necessitating dual
> channel LVDS. The 15" pre-retina models had either 1440x900 (106 MHz)
> or 1680x1050 (119 MHz), both versions used dual channel LVDS even
> though the smaller one would have fit into a single channel.
> 
> v2: Assume dual channel LVDS if the pixel clock necessitates it,
> eliminating the need to hardcode 17" models, suggested by Jani Nikula.

I would suggest splitting that into a separate patch. Otherwise it's
going to harder to revert either change separately, should the need
arise. So that part is
Reviewed-by: Ville Syrjälä 

I have no clue about the Mac stuff so won't pretend to say anything
about that.

> 
> v3: Fix typo, thanks Joonas Lahtinen.
> 
> Signed-off-by: Lukas Wunner 
> Tested-by: Lukas Wunner 
> Acked-by: Jani Nikula 
> Cc: sta...@vger.kernel.org
> ---
>  drivers/gpu/drm/i915/intel_lvds.c | 26 --
>  1 file changed, 24 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
> b/drivers/gpu/drm/i915/intel_lvds.c
> index 071b96d..417ccab 100644
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -812,12 +812,28 @@ static int intel_dual_link_lvds_callback(const struct 
> dmi_system_id *id)
>  static const struct dmi_system_id intel_dual_link_lvds[] = {
>   {
>   .callback = intel_dual_link_lvds_callback,
> - .ident = "Apple MacBook Pro (Core i5/i7 Series)",
> + .ident = "Apple MacBook Pro 15\" (2010)",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro6,2"),
> + },
> + },
> + {
> + .callback = intel_dual_link_lvds_callback,
> + .ident = "Apple MacBook Pro 15\" (2011)",
>   .matches = {
>   DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
>   DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro8,2"),
>   },
>   },
> + {
> + .callback = intel_dual_link_lvds_callback,
> + .ident = "Apple MacBook Pro 15\" (2012)",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro9,1"),
> + },
> + },
>   { } /* terminating entry */
>  };
>  
> @@ -847,6 +863,11 @@ static bool compute_is_dual_link_lvds(struct 
> intel_lvds_encoder *lvds_encoder)
>   if (i915.lvds_channel_mode > 0)
>   return i915.lvds_channel_mode == 2;
>  
> + /* single channel LVDS is limited to 112 MHz */
> + if (lvds_encoder->attached_connector->base.panel.fixed_mode->clock
> + > 112999)
> + return true;
> +
>   if (dmi_check_system(intel_dual_link_lvds))
>   return true;
>  
> @@ -1104,6 +1125,8 @@ void intel_lvds_init(struct drm_device *dev)
>  out:
>   mutex_unlock(&dev->mode_config.mutex);
>  
> + intel_panel_init(&intel_connector->panel, fixed_mode, downclock_mode);
> +
>   lvds_encoder->is_dual_link = compute_is_dual_link_lvds(lvds_encoder);
>   DRM_DEBUG_KMS("detected %s-link lvds configuration\n",
> lvds_encoder->is_dual_link ? "dual" : "single");
> @@ -1118,7 +1141,6 @@ out:
>   }
>   drm_connector_register(connector);
>  
> - intel_panel_init(&intel_connector->panel, fixed_mode, downclock_mode);
>   intel_panel_setup_backlight(connector, INVALID_PIPE);
>  
>   return;
> -- 
> 1.8.5.2 (Apple Git-48)
> ___
> 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 i-g-t Fix a clang compile error.

[Dave Gordon]

On 27/04/15 17:20, Yunlian Jiang wrote:
> Thomas,
> Thanks for the review. This time I put the patch in the attachment so
> it should be applied cleanly.
>  I added Signed-off-by line too.
>   Thanks
> 
> From c2f6ecc1c8837abd87aa2da5510281a4833b2a27 Mon Sep 17 00:00:00 2001
> From: Yunlian Jiang 
> Date: Mon, 27 Apr 2015 09:14:33 -0700
> Subject: [PATCH 3432/3432] Remove struct per_thread_data to make it compile
>  with clang.
> 
> The bug enty is https://code.google.com/p/chromium/issues/detail?id=476001
> This patch makes clang happy.
> 
> Cc:Benjamin Widawsky 
> Cc:Thomas Wood 
> Signed-off-by: Yunlian Jiang 
> ---
>  debugger/eudb.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/debugger/eudb.c b/debugger/eudb.c
> index 0e810db..21405ef 100644
> --- a/debugger/eudb.c
> +++ b/debugger/eudb.c
> @@ -207,15 +207,11 @@ wait_for_attn(int timeout, int *out_bits) {
>  #define eu_tid(bit) eu_info->debuggees[bit].tid
>  static struct eu_state *
>  find_eu_shmem(int bit, volatile uint8_t *buf) {
> - struct per_thread_data {
> - uint8_t [dh.per_thread_scratch];
> - }__attribute__((packed)) *data;
>   struct eu_state *eu;
>   int mem_tid, mem_euid, i;
>  
> - data = (struct per_thread_data *)buf;
>   for(i = 0; i < eu_info->num_threads; i++) {
> - eu = (struct eu_state *)&data[i];
> + eu = (struct eu_state *)&data[i * dh.per_thread_scratc];

This line can't be right! AFAICS, you don't have anything called 'data'
in scope now (you deleted the declaration); also, there's an 'h' missing
right at the end, just before the closing ']' :(

Perhaps it should say:

+   eu = (struct eu_state *)&buf[i * dh.per_thread_scratch];

or even:

+   eu = (struct eu_state *)(buf + i*dh.per_thread_scratch);

.Dave.

>   mem_tid = eu->sr0 & 0x7;
>   mem_euid = (eu->sr0 >> 8) & 0xf;
>   if (mem_tid == eu_tid(bit) && mem_euid == eu_id(bit))
> -- 2.2.0.rc0.207.ga3a616c 



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

Re: [Intel-gfx] [PATCH-V3 1/2] drm/i915/audio: add codec wakeup override enabled/disable callback

[Takashi Iwai]

At Wed, 29 Apr 2015 17:49:25 +0800,
han...@intel.com wrote:
> 
> From: "Lu, Han" 
> 
> Add support for enabling codec wakeup override signal to allow
> re-enumeration of the controller on SKL after resume from low power state.
> 
> v3 by Jani: Simplify to only support toggling the appropriate chicken bit.
> 
> Signed-off-by: Lu, Han 
> Signed-off-by: Jani Nikula 

The patch series look OK to me.
But who will merge these?

I can merge these two patches to a branch so that it can be shared
between sound and i915 trees.  Of course, only when I get ack about
the first patch.


thanks,

Takashi

> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 36805b6..435c372 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6881,6 +6881,9 @@ enum skl_disp_power_wells {
>  #define   AUDIO_CP_READY(trans)  ((1 << 1) << ((trans) * 4))
>  #define   AUDIO_ELD_VALID(trans) ((1 << 0) << ((trans) * 4))
>  
> +#define HSW_AUD_CHICKENBIT   0x65f10
> +#define   SKL_AUD_CODEC_WAKE_SIGNAL  (1 << 15)
> +
>  /* HSW Power Wells */
>  #define HSW_PWR_WELL_BIOS0x45400 /* CTL1 */
>  #define HSW_PWR_WELL_DRIVER  0x45404 /* CTL2 */
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index f72e93a..ceb2328 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -474,6 +474,32 @@ static void i915_audio_component_put_power(struct device 
> *dev)
>   intel_display_power_put(dev_to_i915(dev), POWER_DOMAIN_AUDIO);
>  }
>  
> +static void i915_audio_component_codec_wake_override(struct device *dev,
> +  bool enable)
> +{
> + struct drm_i915_private *dev_priv = dev_to_i915(dev);
> + u32 tmp;
> +
> + if (!IS_SKYLAKE(dev_priv))
> + return;
> +
> + /*
> +  * Enable/disable generating the codec wake signal, overriding the
> +  * internal logic to generate the codec wake to controller.
> +  */
> + tmp = I915_READ(HSW_AUD_CHICKENBIT);
> + tmp &= ~SKL_AUD_CODEC_WAKE_SIGNAL;
> + I915_WRITE(HSW_AUD_CHICKENBIT, tmp);
> + usleep_range(1000, 1500);
> +
> + if (enable) {
> + tmp = I915_READ(HSW_AUD_CHICKENBIT);
> + tmp |= SKL_AUD_CODEC_WAKE_SIGNAL;
> + I915_WRITE(HSW_AUD_CHICKENBIT, tmp);
> + usleep_range(1000, 1500);
> + }
> +}
> +
>  /* Get CDCLK in kHz  */
>  static int i915_audio_component_get_cdclk_freq(struct device *dev)
>  {
> @@ -495,6 +521,7 @@ static const struct i915_audio_component_ops 
> i915_audio_component_ops = {
>   .owner  = THIS_MODULE,
>   .get_power  = i915_audio_component_get_power,
>   .put_power  = i915_audio_component_put_power,
> + .codec_wake_override = i915_audio_component_codec_wake_override,
>   .get_cdclk_freq = i915_audio_component_get_cdclk_freq,
>  };
>  
> diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h
> index 3e2f22e..c9a8b64 100644
> --- a/include/drm/i915_component.h
> +++ b/include/drm/i915_component.h
> @@ -31,6 +31,7 @@ struct i915_audio_component {
>   struct module *owner;
>   void (*get_power)(struct device *);
>   void (*put_power)(struct device *);
> + void (*codec_wake_override)(struct device *, bool enable);
>   int (*get_cdclk_freq)(struct device *);
>   } *ops;
>  };
> -- 
> 1.9.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix 32b overflow check in gen8_ppgtt_alloc_page_directories

[Ville Syrjälä]

On Thu, Apr 30, 2015 at 02:59:34PM +0100, Michel Thierry wrote:
> The patch 69876bed7e008f5fe01538a2d47c09f2862129d0: "drm/i915/gen8:
> page directories rework allocation" added an overflow warning, but the
> mask had an extra 0. Use typo-prone option suggested by Dave instead.
> 
> This check will be unnecessary after gen8_alloc_va_range handles more
> than 4 PDPs (48b addressing).
> 
> Reported-by: Dan Carpenter 
> Cc: Dave Gordon 
> Signed-off-by: Michel Thierry 
> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 6fae6bd..6d894fc 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -756,8 +756,8 @@ static int gen8_ppgtt_alloc_page_directories(struct 
> i915_hw_ppgtt *ppgtt,
>  
>   WARN_ON(!bitmap_empty(new_pds, GEN8_LEGACY_PDPES));
>  
> - /* FIXME: PPGTT container_of won't work for 64b */
> - WARN_ON((start + length) > 0x8ULL);
> + /* FIXME: upper bound must not overflow 31 bits  */
> + WARN_ON((start + length) & (~0ULL << 31));

Why is it 31 and not 32?

>  
>   gen8_for_each_pdpe(pd, pdp, start, length, temp, pdpe) {
>   if (pd)
> -- 
> 2.1.1
> 
> ___
> 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: checking IS_ERR() instead of NULL

[Dan Carpenter]

We switched from calling i915_gem_alloc_context_obj() to calling
i915_gem_alloc_object() so the error handling needs to be updated to
check for NULL instead of IS_ERR().

Fixes: 149c86e74fe4 ('drm/i915: Allocate context objects from stolen')
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 732fd63..0fa9209 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1895,10 +1895,9 @@ int intel_lr_context_deferred_create(struct 
intel_context *ctx,
context_size = round_up(get_lr_context_size(ring), 4096);
 
ctx_obj = i915_gem_alloc_object(dev, context_size);
-   if (IS_ERR(ctx_obj)) {
-   ret = PTR_ERR(ctx_obj);
-   DRM_DEBUG_DRIVER("Alloc LRC backing obj failed: %d\n", ret);
-   return ret;
+   if (!ctx_obj) {
+   DRM_DEBUG_DRIVER("Alloc LRC backing obj failed.\n");
+   return -ENOMEM;
}
 
if (is_global_default_ctx) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix 32b overflow check in gen8_ppgtt_alloc_page_directories

[Michel Thierry]

On 4/30/2015 3:22 PM, Ville Syrjälä wrote:

On Thu, Apr 30, 2015 at 02:59:34PM +0100, Michel Thierry wrote:

The patch 69876bed7e008f5fe01538a2d47c09f2862129d0: "drm/i915/gen8:
page directories rework allocation" added an overflow warning, but the
mask had an extra 0. Use typo-prone option suggested by Dave instead.

This check will be unnecessary after gen8_alloc_va_range handles more
than 4 PDPs (48b addressing).

Reported-by: Dan Carpenter 
Cc: Dave Gordon 
Signed-off-by: Michel Thierry 
---
  drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 6fae6bd..6d894fc 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -756,8 +756,8 @@ static int gen8_ppgtt_alloc_page_directories(struct 
i915_hw_ppgtt *ppgtt,

WARN_ON(!bitmap_empty(new_pds, GEN8_LEGACY_PDPES));

-   /* FIXME: PPGTT container_of won't work for 64b */
-   WARN_ON((start + length) > 0x8ULL);
+   /* FIXME: upper bound must not overflow 31 bits  */
+   WARN_ON((start + length) & (~0ULL << 31));


Why is it 31 and not 32?



Right, the check really should be (start + length) >= 0x1ULL.



gen8_for_each_pdpe(pd, pdp, start, length, temp, pdpe) {
if (pd)
--
2.1.1

___
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] drm/i915: checking IS_ERR() instead of NULL

[Chris Wilson]

On Thu, Apr 30, 2015 at 05:30:50PM +0300, Dan Carpenter wrote:
> We switched from calling i915_gem_alloc_context_obj() to calling
> i915_gem_alloc_object() so the error handling needs to be updated to
> check for NULL instead of IS_ERR().

I had a patch to change i915_gem_alloc_object() to report the correct
error rather than NULL - which can come in surprisingly handy at
times...
-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] drm/i915/gtt: Allocate va range only if vma is not bound

[shuang . he]

Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
Task id: 6285
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  276/276  276/276
ILK  302/302  302/302
SNB  316/316  316/316
IVB  264/264  264/264
BYT -4  227/227  223/227
BDW  318/318  318/318
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
 BYT  igt@gem_double_irq_loop  DMESG_WARN(1)PASS(3)  
DMESG_WARN(1)PASS(1)
(dmesg patch 
applied)drm:check_crtc_state[i915]]*ERROR*mismatch_in_has_infoframe(expected#,found#)@mismatch
 in has_infoframe .* found
WARNING:at_drivers/gpu/drm/i915/intel_display.c:#check_crtc_state[i915]()@WARNING:.*
 at .* check_crtc_state+0x
*BYT  igt@gem_dummy_reloc_loop@render  FAIL(1)PASS(9)  TIMEOUT(1)PASS(1)
 BYT  igt@gem_pipe_control_store_loop@fresh-buffer  
FAIL(1)TIMEOUT(4)PASS(6)  TIMEOUT(1)PASS(1)
*BYT  igt@gem_storedw_batches_loop@secure-dispatch  FAIL(1)PASS(2)  
DMESG_WARN(1)PASS(1)
(dmesg patch 
applied)drm:check_crtc_state[i915]]*ERROR*mismatch_in_has_infoframe(expected#,found#)@mismatch
 in has_infoframe .* found
WARNING:at_drivers/gpu/drm/i915/intel_display.c:#check_crtc_state[i915]()@WARNING:.*
 at .* check_crtc_state+0x
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [patch] drm/i915: checking IS_ERR() instead of NULL

[Dan Carpenter]

On Thu, Apr 30, 2015 at 03:43:02PM +0100, Chris Wilson wrote:
> On Thu, Apr 30, 2015 at 05:30:50PM +0300, Dan Carpenter wrote:
> > We switched from calling i915_gem_alloc_context_obj() to calling
> > i915_gem_alloc_object() so the error handling needs to be updated to
> > check for NULL instead of IS_ERR().
> 
> I had a patch to change i915_gem_alloc_object() to report the correct
> error rather than NULL - which can come in surprisingly handy at
> times...

That also works, of course.  Send it.  :)

regards,
dan carpenter

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix 32b overflow check in gen8_ppgtt_alloc_page_directories

[Dave Gordon]

On 30/04/15 15:33, Michel Thierry wrote:
> On 4/30/2015 3:22 PM, Ville Syrjälä wrote:
>> On Thu, Apr 30, 2015 at 02:59:34PM +0100, Michel Thierry wrote:
>>> The patch 69876bed7e008f5fe01538a2d47c09f2862129d0: "drm/i915/gen8:
>>> page directories rework allocation" added an overflow warning, but the
>>> mask had an extra 0. Use typo-prone option suggested by Dave instead.
>>>
>>> This check will be unnecessary after gen8_alloc_va_range handles more
>>> than 4 PDPs (48b addressing).
>>>
>>> Reported-by: Dan Carpenter 
>>> Cc: Dave Gordon 
>>> Signed-off-by: Michel Thierry 
>>> ---
>>>   drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++--
>>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
>>> b/drivers/gpu/drm/i915/i915_gem_gtt.c
>>> index 6fae6bd..6d894fc 100644
>>> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
>>> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
>>> @@ -756,8 +756,8 @@ static int
>>> gen8_ppgtt_alloc_page_directories(struct i915_hw_ppgtt *ppgtt,
>>>
>>>   WARN_ON(!bitmap_empty(new_pds, GEN8_LEGACY_PDPES));
>>>
>>> -/* FIXME: PPGTT container_of won't work for 64b */
>>> -WARN_ON((start + length) > 0x8ULL);
>>> +/* FIXME: upper bound must not overflow 31 bits  */
>>> +WARN_ON((start + length) & (~0ULL << 31));
>>
>> Why is it 31 and not 32?
> 
> Right, the check really should be (start + length) >= 0x1ULL.

Something with '32' in it might be more obvious and save anyone having
to count the zeroes ... and a comment that also mentioned the limit:

/* FIXME: for now, upper bound must fit in 32 bits  */

WARN_ON((start + length) >= (1ULL << 32))
WARN_ON((start + length) & (~0ULL << 32))
WARN_ON((start + length) >> 32) != 0)

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

Re: [Intel-gfx] [PATCH v2 5/5] drm/i915: Use partial view in mmap fault handler

[Tvrtko Ursulin]

On 04/30/2015 12:21 PM, Joonas Lahtinen wrote:


Use partial view for huge BOs (bigger than the mappable aperture)
in fault handler so that they can be accessed without trying to make
room for them by evicting other objects.

v2:
- Only use partial views in the case where early rejection was
   previously done.
- Account variable type changes from previous reroll.

Cc: Chris Wilson 
Signed-off-by: Joonas Lahtinen 
---
  drivers/gpu/drm/i915/i915_gem.c | 69 +++--
  1 file changed, 46 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a020836..2f3fa0b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1635,6 +1635,7 @@ int i915_gem_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)
struct drm_i915_gem_object *obj = to_intel_bo(vma->vm_private_data);
struct drm_device *dev = obj->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
+   struct i915_ggtt_view view = i915_ggtt_view_normal;
pgoff_t page_offset;
unsigned long pfn;
int ret = 0;
@@ -1667,8 +1668,21 @@ int i915_gem_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)
goto unlock;
}

-   /* Now bind it into the GTT if needed */
-   ret = i915_gem_obj_ggtt_pin(obj, 0, PIN_MAPPABLE);
+   /* Use a partial view if the object is bigger than the aperture. */
+   if (obj->base.size >= dev_priv->gtt.mappable_end) {
+   static const unsigned int chunk_size = 256; // 1 MiB
+   memset(&view, 0, sizeof(view));
+   view.type = I915_GGTT_VIEW_PARTIAL;
+   view.params.partial.offset = rounddown(page_offset, chunk_size);
+   view.params.partial.size =
+   min_t(unsigned int,
+ chunk_size,
+ (vma->vm_end - vma->vm_start)/PAGE_SIZE -
+ view.params.partial.offset);
+   }
+
+   /* Now pin it into the GTT if needed */
+   ret = i915_gem_object_ggtt_pin(obj, &view, 0, PIN_MAPPABLE);
if (ret)
goto unlock;

@@ -1681,30 +1695,44 @@ int i915_gem_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)
goto unpin;

/* Finally, remap it using the new GTT offset */
-   pfn = dev_priv->gtt.mappable_base + i915_gem_obj_ggtt_offset(obj);
+   pfn = dev_priv->gtt.mappable_base +
+   i915_gem_obj_ggtt_offset_view(obj, &view);
pfn >>= PAGE_SHIFT;

-   if (!obj->fault_mappable) {
-   unsigned long size = min_t(unsigned long,
-  vma->vm_end - vma->vm_start,
-  obj->base.size);
-   int i;
+   if (unlikely(view.type == I915_GGTT_VIEW_PARTIAL)) {
+   unsigned long base = vma->vm_start +
+   (view.params.partial.offset << PAGE_SHIFT);
+   unsigned int i;

-   for (i = 0; i < size >> PAGE_SHIFT; i++) {
-   ret = vm_insert_pfn(vma,
-   (unsigned long)vma->vm_start + i * 
PAGE_SIZE,
-   pfn + i);
+   for (i = 0; i < view.params.partial.size; i++) {
+   ret = vm_insert_pfn(vma, base + i * PAGE_SIZE, pfn + i);
if (ret)
break;
}
-
obj->fault_mappable = true;
-   } else
-   ret = vm_insert_pfn(vma,
-   (unsigned long)vmf->virtual_address,
-   pfn + page_offset);


If I read the diff correctly you don't have equivalent handling (as the 
normal view) for when the case when the pre-fault fails somewhere in the 
middle?


That means if that happens you'll call vm_insert_pfn on the whole range 
again - is that OK?


Regards,

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix 32b overflow check in gen8_ppgtt_alloc_page_directories

[Michel Thierry]

On 4/30/2015 3:53 PM, Dave Gordon wrote:

On 30/04/15 15:33, Michel Thierry wrote:

On 4/30/2015 3:22 PM, Ville Syrjälä wrote:

On Thu, Apr 30, 2015 at 02:59:34PM +0100, Michel Thierry wrote:

The patch 69876bed7e008f5fe01538a2d47c09f2862129d0: "drm/i915/gen8:
page directories rework allocation" added an overflow warning, but the
mask had an extra 0. Use typo-prone option suggested by Dave instead.

This check will be unnecessary after gen8_alloc_va_range handles more
than 4 PDPs (48b addressing).

Reported-by: Dan Carpenter 
Cc: Dave Gordon 
Signed-off-by: Michel Thierry 
---
   drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 6fae6bd..6d894fc 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -756,8 +756,8 @@ static int
gen8_ppgtt_alloc_page_directories(struct i915_hw_ppgtt *ppgtt,

   WARN_ON(!bitmap_empty(new_pds, GEN8_LEGACY_PDPES));

-/* FIXME: PPGTT container_of won't work for 64b */
-WARN_ON((start + length) > 0x8ULL);
+/* FIXME: upper bound must not overflow 31 bits  */
+WARN_ON((start + length) & (~0ULL << 31));


Why is it 31 and not 32?


Right, the check really should be (start + length) >= 0x1ULL.


Something with '32' in it might be more obvious and save anyone having
to count the zeroes ... and a comment that also mentioned the limit:

/* FIXME: for now, upper bound must fit in 32 bits  */

WARN_ON((start + length) >= (1ULL << 32))
WARN_ON((start + length) & (~0ULL << 32))
WARN_ON((start + length) >> 32) != 0)


Yes, I was planning to just replace _31_ with _32_ and avoid all those 
zeroes...




.Dave.


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

Re: [Intel-gfx] [PATCH] drm/i915: Fix 32b overflow check in gen8_ppgtt_alloc_page_directories

[Ville Syrjälä]

On Thu, Apr 30, 2015 at 03:53:29PM +0100, Dave Gordon wrote:
> On 30/04/15 15:33, Michel Thierry wrote:
> > On 4/30/2015 3:22 PM, Ville Syrjälä wrote:
> >> On Thu, Apr 30, 2015 at 02:59:34PM +0100, Michel Thierry wrote:
> >>> The patch 69876bed7e008f5fe01538a2d47c09f2862129d0: "drm/i915/gen8:
> >>> page directories rework allocation" added an overflow warning, but the
> >>> mask had an extra 0. Use typo-prone option suggested by Dave instead.
> >>>
> >>> This check will be unnecessary after gen8_alloc_va_range handles more
> >>> than 4 PDPs (48b addressing).
> >>>
> >>> Reported-by: Dan Carpenter 
> >>> Cc: Dave Gordon 
> >>> Signed-off-by: Michel Thierry 
> >>> ---
> >>>   drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++--
> >>>   1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> >>> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> >>> index 6fae6bd..6d894fc 100644
> >>> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> >>> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> >>> @@ -756,8 +756,8 @@ static int
> >>> gen8_ppgtt_alloc_page_directories(struct i915_hw_ppgtt *ppgtt,
> >>>
> >>>   WARN_ON(!bitmap_empty(new_pds, GEN8_LEGACY_PDPES));
> >>>
> >>> -/* FIXME: PPGTT container_of won't work for 64b */
> >>> -WARN_ON((start + length) > 0x8ULL);
> >>> +/* FIXME: upper bound must not overflow 31 bits  */
> >>> +WARN_ON((start + length) & (~0ULL << 31));
> >>
> >> Why is it 31 and not 32?
> > 
> > Right, the check really should be (start + length) >= 0x1ULL.
> 
> Something with '32' in it might be more obvious and save anyone having
> to count the zeroes ... and a comment that also mentioned the limit:
> 
>   /* FIXME: for now, upper bound must fit in 32 bits  */
> 
>   WARN_ON((start + length) >= (1ULL << 32))

This would match the '1ULL<<32' used in the ppgtt init.

>   WARN_ON((start + length) & (~0ULL << 32))
>   WARN_ON((start + length) >> 32) != 0)
> 
> .Dave.

-- 
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 v2] drm/i915: Fix 32b overflow check in gen8_ppgtt_alloc_page_directories

[Michel Thierry]

The patch 69876bed7e008f5fe01538a2d47c09f2862129d0: "drm/i915/gen8:
page directories rework allocation" added an overflow warning, but the
mask had an extra 0. Use typo-prone option suggested by Dave instead,
to check for (start + length) >= 0x1ULL.

This check will be unnecessary after gen8_alloc_va_range handles more
than 4 PDPs (48b addressing).

v2: Really check for 32b overflow (Ville)

Reported-by: Dan Carpenter 
Cc: Dave Gordon 
Cc: Ville Syrjälä 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 6fae6bd..3450cb5 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -756,8 +756,8 @@ static int gen8_ppgtt_alloc_page_directories(struct 
i915_hw_ppgtt *ppgtt,
 
WARN_ON(!bitmap_empty(new_pds, GEN8_LEGACY_PDPES));
 
-   /* FIXME: PPGTT container_of won't work for 64b */
-   WARN_ON((start + length) > 0x8ULL);
+   /* FIXME: upper bound must not overflow 32 bits  */
+   WARN_ON((start + length) >= (1ULL << 32));
 
gen8_for_each_pdpe(pd, pdp, start, length, temp, pdpe) {
if (pd)
-- 
2.1.1

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

[Intel-gfx] [PATCH 2/8] drm/i915/skl: Fix the CTRL typo in the DPLL_CRTL1 defines

[Damien Lespiau]

Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 +-
 drivers/gpu/drm/i915/i915_reg.h  | 18 +-
 drivers/gpu/drm/i915/intel_ddi.c | 26 +-
 drivers/gpu/drm/i915/intel_display.c |  6 +++---
 drivers/gpu/drm/i915/intel_dp.c  | 12 ++--
 5 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e8e8145..908c124 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -295,7 +295,7 @@ struct intel_dpll_hw_state {
/* skl */
/*
 * DPLL_CTRL1 has 6 bits for each each this DPLL. We store those in
-* lower part of crtl1 and they get shifted into position when writing
+* lower part of ctrl1 and they get shifted into position when writing
 * the register.  This allows us to easily compare the state to share
 * the DPLL.
 */
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e35d7f2..cebb614 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7135,16 +7135,16 @@ enum skl_disp_power_wells {
 #define DPLL_CTRL1 0x6C058
 #define  DPLL_CTRL1_HDMI_MODE(id)  (1<<((id)*6+5))
 #define  DPLL_CTRL1_SSC(id)(1<<((id)*6+4))
-#define  DPLL_CRTL1_LINK_RATE_MASK(id) (7<<((id)*6+1))
-#define  DPLL_CRTL1_LINK_RATE_SHIFT(id)((id)*6+1)
-#define  DPLL_CRTL1_LINK_RATE(linkrate, id)((linkrate)<<((id)*6+1))
+#define  DPLL_CTRL1_LINK_RATE_MASK(id) (7<<((id)*6+1))
+#define  DPLL_CTRL1_LINK_RATE_SHIFT(id)((id)*6+1)
+#define  DPLL_CTRL1_LINK_RATE(linkrate, id)((linkrate)<<((id)*6+1))
 #define  DPLL_CTRL1_OVERRIDE(id)   (1<<((id)*6))
-#define  DPLL_CRTL1_LINK_RATE_2700 0
-#define  DPLL_CRTL1_LINK_RATE_1350 1
-#define  DPLL_CRTL1_LINK_RATE_810  2
-#define  DPLL_CRTL1_LINK_RATE_1620 3
-#define  DPLL_CRTL1_LINK_RATE_1080 4
-#define  DPLL_CRTL1_LINK_RATE_2160 5
+#define  DPLL_CTRL1_LINK_RATE_2700 0
+#define  DPLL_CTRL1_LINK_RATE_1350 1
+#define  DPLL_CTRL1_LINK_RATE_810  2
+#define  DPLL_CTRL1_LINK_RATE_1620 3
+#define  DPLL_CTRL1_LINK_RATE_1080 4
+#define  DPLL_CTRL1_LINK_RATE_2160 5
 
 /* DPLL control2 */
 #define DPLL_CTRL2 0x6C05C
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 9c1e74a..d5bee8b 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -870,26 +870,26 @@ static void skl_ddi_clock_get(struct intel_encoder 
*encoder,
if (dpll_ctl1 & DPLL_CTRL1_HDMI_MODE(dpll)) {
link_clock = skl_calc_wrpll_link(dev_priv, dpll);
} else {
-   link_clock = dpll_ctl1 & DPLL_CRTL1_LINK_RATE_MASK(dpll);
-   link_clock >>= DPLL_CRTL1_LINK_RATE_SHIFT(dpll);
+   link_clock = dpll_ctl1 & DPLL_CTRL1_LINK_RATE_MASK(dpll);
+   link_clock >>= DPLL_CTRL1_LINK_RATE_SHIFT(dpll);
 
switch (link_clock) {
-   case DPLL_CRTL1_LINK_RATE_810:
+   case DPLL_CTRL1_LINK_RATE_810:
link_clock = 81000;
break;
-   case DPLL_CRTL1_LINK_RATE_1080:
+   case DPLL_CTRL1_LINK_RATE_1080:
link_clock = 108000;
break;
-   case DPLL_CRTL1_LINK_RATE_1350:
+   case DPLL_CTRL1_LINK_RATE_1350:
link_clock = 135000;
break;
-   case DPLL_CRTL1_LINK_RATE_1620:
+   case DPLL_CTRL1_LINK_RATE_1620:
link_clock = 162000;
break;
-   case DPLL_CRTL1_LINK_RATE_2160:
+   case DPLL_CTRL1_LINK_RATE_2160:
link_clock = 216000;
break;
-   case DPLL_CRTL1_LINK_RATE_2700:
+   case DPLL_CTRL1_LINK_RATE_2700:
link_clock = 27;
break;
default:
@@ -1294,13 +1294,13 @@ skl_ddi_pll_select(struct intel_crtc *intel_crtc,
 
switch (intel_dp->link_bw) {
case DP_LINK_BW_1_62:
-   ctrl1 |= DPLL_CRTL1_LINK_RATE(DPLL_CRTL1_LINK_RATE_810, 
0);
+   ctrl1 |= DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_810, 
0);
break;
case DP_LINK_BW_2_7:
-   ctrl1 |= 
DPLL_CRTL1_LINK_RATE(DPLL_CRTL1_LINK_RATE_1350, 0);
+   ctrl1 |= 
DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_1350, 0);
break;
case DP_LINK_BW_5_4:
-   ctrl1 |= 
DPLL_CRTL1_L

[Intel-gfx] [PATCH 7/8] drm/i915/skl: Change CDCLK behind PCU's back

[Damien Lespiau]

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

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9c8338f..2cbae9a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5525,6 +5525,7 @@ static void skl_set_cdclk(struct drm_i915_private 
*dev_priv, unsigned int freq)
 {
int ret;
u32 val, freq_select, freq_decimal, pcu_ack;
+   bool do_pcu_ack = true;
 
DRM_DEBUG_DRIVER("Changing CDCLK to %dKHz\n", freq);
 
@@ -5534,8 +5535,8 @@ static void skl_set_cdclk(struct drm_i915_private 
*dev_priv, unsigned int freq)
ret = sandybridge_pcode_read(dev_priv, SKL_PCODE_CDCLK_CONTROL, &val);
mutex_unlock(&dev_priv->rps.hw_lock);
if (ret || !(val & SKL_CDCLK_READY_FOR_CHANGE)) {
-   DRM_ERROR("failed to inform PCU about cdclk change\n");
-   return;
+   DRM_DEBUG_KMS("failed to inform PCU about cdclk change\n");
+   do_pcu_ack = false;
}
 
/* set CDCLK_CTL */
@@ -5567,6 +5568,9 @@ static void skl_set_cdclk(struct drm_i915_private 
*dev_priv, unsigned int freq)
I915_WRITE(CDCLK_CTL, freq_select | freq_decimal);
POSTING_READ(CDCLK_CTL);
 
+   if (!do_pcu_ack)
+   return;
+
/* inform PCU of the change */
mutex_lock(&dev_priv->rps.hw_lock);
sandybridge_pcode_write(dev_priv, SKL_PCODE_CDCLK_CONTROL, pcu_ack);
-- 
2.1.0

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

[Intel-gfx] [PATCH 8/8] drm/i915/skl: gen6+ platforms support runtime PM

[Damien Lespiau]

Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/i915/i915_drv.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f637667..25618fd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2422,8 +2422,7 @@ struct drm_i915_cmd_table {
 #define HAS_PSR(dev)   (IS_HASWELL(dev) || IS_BROADWELL(dev) || \
 IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev) || \
 IS_SKYLAKE(dev))
-#define HAS_RUNTIME_PM(dev)(IS_GEN6(dev) || IS_HASWELL(dev) || \
-IS_BROADWELL(dev) || IS_VALLEYVIEW(dev))
+#define HAS_RUNTIME_PM(dev)(INTEL_INFO(dev)->gen >= 6)
 #define HAS_RC6(dev)   (INTEL_INFO(dev)->gen >= 6)
 #define HAS_RC6p(dev)  (INTEL_INFO(dev)->gen == 6 || IS_IVYBRIDGE(dev))
 
-- 
2.1.0

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

[Intel-gfx] [PATCH 3/8] drm/i915: Re-order the PCU opcodes

[Damien Lespiau]

Let's keep that list sorted!

Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/i915/i915_reg.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index cebb614..880290d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6638,15 +6638,15 @@ enum skl_disp_power_wells {
 
 #define GEN6_PCODE_MAILBOX 0x138124
 #define   GEN6_PCODE_READY (1<<31)
-#define   GEN6_READ_OC_PARAMS  0xc
-#define   GEN6_PCODE_WRITE_MIN_FREQ_TABLE  0x8
-#define   GEN6_PCODE_READ_MIN_FREQ_TABLE   0x9
 #define  GEN6_PCODE_WRITE_RC6VIDS  0x4
 #define  GEN6_PCODE_READ_RC6VIDS   0x5
+#define GEN6_ENCODE_RC6_VID(mv)(((mv) - 245) / 5)
+#define GEN6_DECODE_RC6_VID(vids)  (((vids) * 5) + 245)
+#define   GEN6_PCODE_WRITE_MIN_FREQ_TABLE  0x8
+#define   GEN6_PCODE_READ_MIN_FREQ_TABLE   0x9
+#define   GEN6_READ_OC_PARAMS  0xc
 #define   GEN6_PCODE_READ_D_COMP   0x10
 #define   GEN6_PCODE_WRITE_D_COMP  0x11
-#define   GEN6_ENCODE_RC6_VID(mv)  (((mv) - 245) / 5)
-#define   GEN6_DECODE_RC6_VID(vids)(((vids) * 5) + 245)
 #define   HSW_PCODE_DE_WRITE_FREQ_REQ  0x17
 #define   DISPLAY_IPS_CONTROL  0x19
 #define  HSW_PCODE_DYNAMIC_DUTY_CYCLE_CONTROL  0x1A
-- 
2.1.0

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

[Intel-gfx] [PATCH 6/8] drm/i915/skl: Deinit/init the display at suspend/resume

[Damien Lespiau]

We need to re-init the display hardware when going out of suspend. This
includes:

  - Hooking the PCH to the reset logic
  - Restoring CDCDLK
  - Enabling the DDB power

Among those, only the CDCDLK one is a bit tricky. There's some
complexity in that:

  - DPLL0 (which is the source for CDCLK) has two VCOs, each with a set
of supported frequencies. As eDP also uses DPLL0 for its link rate,
once DPLL0 is on, we restrict the possible eDP link rates the chosen
VCO.
  - CDCLK also limits the bandwidth available to push pixels.
  - My current PCU firmware never ack the frequency change request

So, as a first step, this commit restore what the BIOS set, until I can
do more testing.


In case that's of interest for the reviewer, I've unit tested the
function that derives the decimal frequency field:

  #include 
  #include 
  #include 

  #define ARRAY_SIZE(x) (sizeof(x) / sizeof(*(x)))

  static const struct dpll_freq {
  unsigned int freq;
  unsigned int decimal;
  } freqs[] = {
  { .freq = 308570, .decimal = 0b01001100111},
  { .freq = 337500, .decimal = 0b0101011},
  { .freq = 432000, .decimal = 0b0110100},
  { .freq = 45, .decimal = 0b0111010},
  { .freq = 54, .decimal = 0b1110110},
  { .freq = 617140, .decimal = 0b1001101},
  { .freq = 675000, .decimal = 0b10101000100},
  };

  static void intbits(unsigned int v)
  {
  int i;

  for(i = 10; i >= 0; i--)
  putchar('0' + ((v >> i) & 1));
  }

  static unsigned int freq_decimal(unsigned int freq /* in kHz */)
  {
  unsigned int mhz, dot5;

  mhz = freq / 1000;
  dot5 = (freq - mhz * 1000) >= 500;

  return (mhz - 1) << 1 | dot5;
  }

  static void test_freq(const struct dpll_freq *entry)
  {
  unsigned int decimal = freq_decimal(entry->freq);

  printf("freq: %d, expected: ", entry->freq);
  intbits(entry->decimal);
  printf(", got: ");
  intbits(decimal);
  putchar('\n');

  assert(decimal == entry->decimal);
  }

  int main(int argc, char **argv)
  {
  int i;

  for (i = 0; i < ARRAY_SIZE(freqs); i++)
  test_freq(&freqs[i]);

  return 0;
  }

Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/i915/i915_drv.c  |  26 -
 drivers/gpu/drm/i915/i915_drv.h  |   1 +
 drivers/gpu/drm/i915/i915_reg.h  |   3 +
 drivers/gpu/drm/i915/intel_ddi.c |   2 +
 drivers/gpu/drm/i915/intel_display.c | 208 +++
 drivers/gpu/drm/i915/intel_drv.h |   2 +
 6 files changed, 240 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e70adfd..58db0c6 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -574,6 +574,7 @@ static void intel_suspend_encoders(struct drm_i915_private 
*dev_priv)
 static int intel_suspend_complete(struct drm_i915_private *dev_priv);
 static int vlv_resume_prepare(struct drm_i915_private *dev_priv,
  bool rpm_resume);
+static int skl_resume_prepare(struct drm_i915_private *dev_priv);
 
 static int i915_drm_suspend(struct drm_device *dev)
 {
@@ -781,6 +782,9 @@ static int i915_drm_resume_early(struct drm_device *dev)
 
if (IS_VALLEYVIEW(dev_priv))
ret = vlv_resume_prepare(dev_priv, false);
+   else if (IS_SKYLAKE(dev_priv))
+   ret = skl_resume_prepare(dev_priv);
+
if (ret)
DRM_ERROR("Resume prepare failed: %d,Continuing resume\n", ret);
 
@@ -1009,6 +1013,20 @@ static int hsw_suspend_complete(struct drm_i915_private 
*dev_priv)
return 0;
 }
 
+static int skl_suspend_complete(struct drm_i915_private *dev_priv)
+{
+   skl_display_suspend(dev_priv);
+
+   return 0;
+}
+
+static int skl_resume_prepare(struct drm_i915_private *dev_priv)
+{
+   skl_display_resume(dev_priv);
+
+   return 0;
+}
+
 static int bxt_suspend_complete(struct drm_i915_private *dev_priv)
 {
struct drm_device *dev = dev_priv->dev;
@@ -1500,7 +1518,9 @@ static int intel_runtime_resume(struct device *device)
if (IS_GEN6(dev_priv))
intel_init_pch_refclk(dev);
 
-   if (IS_BROXTON(dev))
+   if (IS_SKYLAKE(dev))
+   ret = skl_resume_prepare(dev_priv);
+   else if (IS_BROXTON(dev))
ret = bxt_resume_prepare(dev_priv);
else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
hsw_disable_pc8(dev_priv);
@@ -1534,7 +1554,9 @@ static int intel_suspend_complete(struct drm_i915_private 
*dev_priv)
struct drm_device *dev = dev_priv->dev;
int ret;
 
-   if (IS_BROXTON(dev))
+   if (IS_SKYLAKE(dev))
+   ret = skl_suspend_complete(dev_priv);
+   else if (IS_BROXTON(dev))
ret = bxt_suspend_complete(dev_priv);
else if (IS_H

[Intel-gfx] [PATCH 5/8] drm/i915/skl: Make the Misc I/O power well part of the PLLS domain

[Damien Lespiau]

The specs tell us to ungate PG1 and Misc I/O at display init. We'll use
the PLLS power domain to ensure those two power wells are up.

Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 6188e94..5b0bce5 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -309,6 +309,7 @@ static void hsw_set_power_well(struct drm_i915_private 
*dev_priv,
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 |  \
-- 
2.1.0

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

[Intel-gfx] [PATCH 1/8] drm/i915/skl: Add the INIT power domain to the MISC I/O power well

[Damien Lespiau]

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

diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 8fe2fde..6188e94 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -308,7 +308,8 @@ static void hsw_set_power_well(struct drm_i915_private 
*dev_priv,
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)
+   SKL_DISPLAY_POWERWELL_1_POWER_DOMAINS | \
+   BIT(POWER_DOMAIN_INIT))
 #define SKL_DISPLAY_ALWAYS_ON_POWER_DOMAINS (  \
(POWER_DOMAIN_MASK & ~(SKL_DISPLAY_POWERWELL_1_POWER_DOMAINS |  \
SKL_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
-- 
2.1.0

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

[Intel-gfx] [PATCH 4/8] drm/i915: Merge the GEN9 memory latency PCU opcode with its friends

[Damien Lespiau]

Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/i915/i915_reg.h | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 880290d..6d428a5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6642,6 +6642,11 @@ enum skl_disp_power_wells {
 #define  GEN6_PCODE_READ_RC6VIDS   0x5
 #define GEN6_ENCODE_RC6_VID(mv)(((mv) - 245) / 5)
 #define GEN6_DECODE_RC6_VID(vids)  (((vids) * 5) + 245)
+#define   GEN9_PCODE_READ_MEM_LATENCY  0x6
+#define GEN9_MEM_LATENCY_LEVEL_MASK0xFF
+#define GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT   8
+#define GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT   16
+#define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT   24
 #define   GEN6_PCODE_WRITE_MIN_FREQ_TABLE  0x8
 #define   GEN6_PCODE_READ_MIN_FREQ_TABLE   0x9
 #define   GEN6_READ_OC_PARAMS  0xc
@@ -6655,12 +6660,6 @@ enum skl_disp_power_wells {
 #define   GEN6_PCODE_FREQ_RING_RATIO_SHIFT 16
 #define GEN6_PCODE_DATA1   0x13812C
 
-#define   GEN9_PCODE_READ_MEM_LATENCY  0x6
-#define   GEN9_MEM_LATENCY_LEVEL_MASK  0xFF
-#define   GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT 8
-#define   GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT 16
-#define   GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT 24
-
 #define GEN6_GT_CORE_STATUS0x138060
 #define   GEN6_CORE_CPD_STATE_MASK (7<<4)
 #define   GEN6_RCn_MASK7
-- 
2.1.0

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

[Intel-gfx] [PATCH 0/8] SKL suspend/resume

[Damien Lespiau]

I had this series written on top of the DMC patches and waiting behind their
upstreaming. However Ubuntu wanted S3 support as they have some freeze dealine
coming soon. I rebase S3 support on top of -nightly then and smoke tested it,
seems to still work!

Things are not perfect, especially PC10 on display off is not happening, but
this could be for later.

-- 
Damien

Damien Lespiau (8):
  drm/i915/skl: Add the INIT power domain to the MISC I/O power well
  drm/i915/skl: Fix the CTRL typo in the DPLL_CRTL1 defines
  drm/i915: Re-order the PCU opcodes
  drm/i915: Merge the GEN9 memory latency PCU opcode with its friends
  drm/i915/skl: Make the Misc I/O power well part of the PLLS domain
  drm/i915/skl: Deinit/init the display at suspend/resume
  drm/i915/skl: Change CDCLK behind PCU's back
  drm/i915/skl: gen6+ platforms support runtime PM

 drivers/gpu/drm/i915/i915_drv.c |  26 +++-
 drivers/gpu/drm/i915/i915_drv.h |   6 +-
 drivers/gpu/drm/i915/i915_reg.h |  42 +++---
 drivers/gpu/drm/i915/intel_ddi.c|  28 ++--
 drivers/gpu/drm/i915/intel_display.c| 218 +++-
 drivers/gpu/drm/i915/intel_dp.c |  12 +-
 drivers/gpu/drm/i915/intel_drv.h|   2 +
 drivers/gpu/drm/i915/intel_runtime_pm.c |   4 +-
 8 files changed, 290 insertions(+), 48 deletions(-)

-- 
2.1.0

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

Re: [Intel-gfx] [PATCH 4/8] drm/i915: Move Displayport test request and sink IRQ logic to intel_dp_detect()

[Paulo Zanoni]

2015-04-20 19:27 GMT-03:00 Todd Previte :
> Due to changes in the driver and to support Displayport compliance testing,
> the test request and sink IRQ logic has been relocated from
> intel_dp_check_link_status to intel_dp_detect. This is because the bulk of the
> compliance tests that set the TEST_REQUEST bit in the DEVICE_IRQ field of the
> DPCD issue a long pulse / hot plug event to signify the start of the test.
> Currently, for a long pulse, intel_dp_check_link_status is not called for a
> long HPD pulse, so if test requests come in, they cannot be detected by the
> driver.
>
> Once located in the intel_dp_detect, in the regular hot plug event path,
> proper detection of Displayport compliance test requests occurs which then
> invokes the test handler to support them. Additionally, this places compliance
> testing in the normal operational paths, eliminating as much special case code
> as possible.
>
> The only change in intel_dp_check_link_status with this patch is that when
> the IRQ is the result of a test request from the sink, the test handler is not
> invoked during the short pulse path. Short pulse test requests are for a
> particular variety of tests (mainly link training) that will be implemented
> in the future. Once those tests are available, the test request handler will
> be called from here as well.
>
> V1:
> - Rewored the commit message to be more clear about the content and intent
>   of this patch
> - Restore IRQ detection logic to intel_dp_check_link_status(). Continue to
>   detect and clear sink IRQs in the short pulse case. Ignore test requests
>   in the short pulses for now since they are for future test implementations.

It took me a a while to realize the "duplicate" code paths are not
really duplicate because of the short vs long thing. But this looks
correct so: Reviewed-by: Paulo Zanoni 

But, later, we could certainly use a cleanup on intel_dp_hpd_pulse().

>
> Signed-off-by: Todd Previte 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 2ef05d7..b249ee8 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4156,7 +4156,7 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
>sink_irq_vector);
>
> if (sink_irq_vector & DP_AUTOMATED_TEST_REQUEST)
> -   intel_dp_handle_test_request(intel_dp);
> +   DRM_DEBUG_DRIVER("Test request in short pulse not 
> handled\n");
> if (sink_irq_vector & (DP_CP_IRQ | DP_SINK_SPECIFIC_IRQ))
> DRM_DEBUG_DRIVER("CP or sink specific irq 
> unhandled\n");
> }
> @@ -4386,6 +4386,7 @@ intel_dp_detect(struct drm_connector *connector, bool 
> force)
> enum drm_connector_status status;
> enum intel_display_power_domain power_domain;
> bool ret;
> +   u8 sink_irq_vector;
>
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
>   connector->base.id, connector->name);
> @@ -4428,6 +4429,20 @@ intel_dp_detect(struct drm_connector *connector, bool 
> force)
> intel_encoder->type = INTEL_OUTPUT_DISPLAYPORT;
> status = connector_status_connected;
>
> +   /* Try to read the source of the interrupt */
> +   if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
> +   intel_dp_get_sink_irq(intel_dp, &sink_irq_vector)) {
> +   /* Clear interrupt source */
> +   drm_dp_dpcd_writeb(&intel_dp->aux,
> +  DP_DEVICE_SERVICE_IRQ_VECTOR,
> +  sink_irq_vector);
> +
> +   if (sink_irq_vector & DP_AUTOMATED_TEST_REQUEST)
> +   intel_dp_handle_test_request(intel_dp);
> +   if (sink_irq_vector & (DP_CP_IRQ | DP_SINK_SPECIFIC_IRQ))
> +   DRM_DEBUG_DRIVER("CP or sink specific irq 
> unhandled\n");
> +   }
> +
>  out:
> intel_dp_power_put(intel_dp, power_domain);
> return status;
> --
> 1.9.1
>
> ___
> 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

[Intel-gfx] Question regarding gem_alive test case in intel-gpu-tools-1.7 suite

[Meng, David]

Hi Team:
Greetings.

I am new to send a question to this email list.  I am working on GPU driver for 
VMware ESXi kernel running on BDW system. The driver is based on the OTC 
graphics driver which is released with Linux 3.19.3.

When I tested the driver using the test case gem_alive from intel-gpu-tools 
-1.7, the result is always fail. The kernel driver complains that the object 
handle is 0.  By checking the gem_alive.c code, it is found the test case dose 
not create any gem object but tries to  use  DRM_IOCTL_I915_GEM_SW_FINISH ioctl 
call to finish a object.  As a result, it returns –ENOENT error.

I wonder is there any special kernel driver feature to be tested by this case?  
Or we expect it is always fail?

Thank you for any answer.

Regards,

David

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

Re: [Intel-gfx] [PATCH-V3 2/2] ALSA:hda - reset display codec when power on

[shuang . he]

Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
Task id: 6287
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  276/276  276/276
ILK  302/302  302/302
SNB  316/316  316/316
IVB  264/264  264/264
BYT -5  227/227  222/227
BDW  318/318  318/318
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
*BYT  igt@gem_dummy_reloc_loop@render  FAIL(1)PASS(10)  
TIMEOUT(1)PASS(1)
*BYT  igt@gem_exec_parse@bitmasks  FAIL(1)PASS(5)  DMESG_WARN(1)PASS(1)
(dmesg patch 
applied)drm:check_crtc_state[i915]]*ERROR*mismatch_in_has_infoframe(expected#,found#)@mismatch
 in has_infoframe .* found
WARNING:at_drivers/gpu/drm/i915/intel_display.c:#check_crtc_state[i915]()@WARNING:.*
 at .* check_crtc_state+0x
 BYT  igt@gem_pipe_control_store_loop@fresh-buffer  
FAIL(1)TIMEOUT(5)PASS(6)  TIMEOUT(1)PASS(1)
*BYT  igt@gem_tiled_pread  FAIL(1)PASS(3)  DMESG_WARN(1)PASS(1)
(dmesg patch 
applied)drm:check_crtc_state[i915]]*ERROR*mismatch_in_has_infoframe(expected#,found#)@mismatch
 in has_infoframe .* found
WARNING:at_drivers/gpu/drm/i915/intel_display.c:#check_crtc_state[i915]()@WARNING:.*
 at .* check_crtc_state+0x
*BYT  igt@gem_userptr_blits@forked-unsync-multifd-normal  FAIL(1)PASS(2)
  NO_RESULT(1)PASS(1)
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Implement the intel_dp_autotest_edid function for DP EDID complaince tests

[Paulo Zanoni]

2015-04-18 4:04 GMT-03:00 Todd Previte :
> Updates the EDID compliance test function to perform the analyze and react to
> the EDID data read as a result of a hot plug event. The results of this
> analysis are handed off to userspace so that the userspace app can set the
> display mode appropriately for the test result/response.
>
> The compliance_test_active flag now appears at the end of the individual
> test handling functions. This is so that the kernel-side operations can
> be completed without the risk of interruption from the userspace app
> that is polling on that flag.
>
> V2:
> - Addressed mailing list feedback
> - Removed excess debug messages
> - Removed extraneous comments
> - Fixed formatting issues (line length > 80)
> - Updated the debug message in compute_edid_checksum to output hex values
>   instead of decimal
> V3:
> - Addressed more list feedback
> - Added the test_active flag to the autotest function
> - Removed test_active flag from handler
> - Added failsafe check on the compliance test active flag
>   at the end of the test handler
> - Fixed checkpatch.pl issues
> V4:
> - Removed the checksum computation function and its use as it has been
>   rendered superfluous by changes to the core DRM EDID functions
> - Updated to use the raw header corruption detection mechanism
> - Moved the declaration of the test_data variable here
> V5:
> - Update test active flag variable name to match the change in the
>   first patch of the series.
> - Relocated the test active flag declaration and initialization
>   to this patch
> V6:
> - Updated to use the new flag for raw EDID header corruption
> - Removed the extra EDID read from the autotest function
> - Added the edid_checksum variable to struct intel_dp so that the
>   autotest function can write it to the sink device
> - Moved the update to the hpd_pulse function to another patch
> - Removed extraneous constants
> V7:
> - Fixed erroneous placement of the checksum assignment. In some cases
>   such as when the EDID read fails and is NULL, this causes a NULL ptr
>   dereference in the kernel. Bad news. Fixed now.
> V8:
> - Updated to support the kfree() on the EDID data added previously
> V9:
> - Updated for the long_hpd flag propagation
> V10:
> - Updated to use actual checksum from the EDID read that occurs during
>   normal hot plug path execution
> - Removed variables from intel_dp struct that are no longer needed
> - Updated the patch subject to more closely match the nature and contents
>   of the patch
>
> Signed-off-by: Todd Previte 
> ---
>  drivers/gpu/drm/i915/intel_dp.c  | 41 
> 
>  drivers/gpu/drm/i915/intel_drv.h |  2 ++
>  2 files changed, 43 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 55d1f5f..4c1f6a9 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -41,6 +41,12 @@
>
>  #define DP_LINK_CHECK_TIMEOUT  (10 * 1000)
>
> +/* Compliance test status bits  */
> +#define INTEL_DP_RESOLUTION_SHIFT_MASK 4

Now that you cleaned all the other stuff, can't we start at 0 instead
of 4? (of course, this would require a change to the user space tool)


> +#define INTEL_DP_RESOLUTION_PREFERRED  (1 << INTEL_DP_RESOLUTION_SHIFT_MASK)
> +#define INTEL_DP_RESOLUTION_STANDARD   (2 << INTEL_DP_RESOLUTION_SHIFT_MASK)
> +#define INTEL_DP_RESOLUTION_FAILSAFE   (3 << INTEL_DP_RESOLUTION_SHIFT_MASK)
> +
>  struct dp_link_dpll {
> int link_bw;
> struct dpll dpll;
> @@ -3994,6 +4000,38 @@ static uint8_t intel_dp_autotest_video_pattern(struct 
> intel_dp *intel_dp)
>  static uint8_t intel_dp_autotest_edid(struct intel_dp *intel_dp)
>  {
> uint8_t test_result = DP_TEST_NAK;
> +   uint32_t ret = 0;
> +   struct intel_connector *intel_connector = 
> intel_dp->attached_connector;
> +   struct drm_connector *connector = &intel_connector->base;
> +
> +   if (intel_connector->detect_edid == NULL ||
> +   connector->edid_corrupt == 1 ||
> +   intel_dp->aux.i2c_defer_count > 6) {
> +   /* Check for NACKs/DEFERs, use failsafe if detected
> +*  (DP CTS 1.2 Core Rev 1.1, 4.2.2.4, 4.2.2.5)
> +*/
> +   if (intel_dp->aux.i2c_nack_count > 0 ||
> +   intel_dp->aux.i2c_defer_count > 0)
> +   DRM_DEBUG_KMS("EDID read had %d NACKs, %d DEFERs\n",
> + intel_dp->aux.i2c_nack_count,
> + intel_dp->aux.i2c_defer_count);
> +   intel_dp->compliance_test_data = INTEL_DP_RESOLUTION_FAILSAFE;
> +   } else {
> +   ret = drm_dp_dpcd_write(&intel_dp->aux,
> +   DP_TEST_EDID_CHECKSUM,
> +   
> &intel_connector->detect_edid->checksum, 1);
> +   if (ret <= 0)
> +   DRM_DEBUG_DRIVER("Failed to write EDID che

Re: [Intel-gfx] [PATCH 2/5] drm: Add edid_corrupt flag for Displayport Link CTS 4.2.2.6

[Paulo Zanoni]

2015-04-22 17:20 GMT-03:00 Alex Deucher :
> On Tue, Apr 21, 2015 at 2:09 PM, Todd Previte  wrote:
>> Displayport compliance test 4.2.2.6 requires that a source device be capable 
>> of
>> detecting a corrupt EDID. The test specification states that the sink device
>> sets up the EDID with an invalid checksum. To do this, the sink sets up an
>> invalid EDID header, expecting the source device to generate the checksum and
>> compare it to the value stored in the last byte of the block data.
>>
>> Unfortunately, the DRM EDID reading and parsing functions are actually too 
>> good
>> in this case; the header is fixed before the checksum is computed and thus 
>> the
>> test never sees the invalid checksum. This results in a failure to pass the
>> compliance test.
>>
>> To correct this issue, when the EDID code detects that the header is invalid,
>> a flag is set to indicate that the EDID is corrupted. In this case, it sets
>> edid_corrupt flag and continues with its fix-up code. This flag is also set 
>> in
>> the case of a more seriously damaged header (fixup score less than the
>> threshold). For consistency, the edid_corrupt flag is also set when the
>> checksum is invalid as well.
>>
>> V2:
>> - Removed the static bool global
>> - Added a bool to the drm_connector struct to reaplce the static one for
>>   holding the status of raw edid header corruption detection
>> - Modified the function signature of the is_valid function to take an
>>   additional parameter to store the corruption detected value
>> - Fixed the other callers of the above is_valid function
>> V3:
>> - Updated the commit message to be more clear about what and why this
>>   patch does what it does.
>> - Added comment in code to clarify the operations there
>> - Removed compliance variable and check_link_status update; those
>>   have been moved to a later patch
>> - Removed variable assignment from the bottom of the test handler
>> V4:
>> - Removed i915 tag from subject line as the patch is not i915-specific
>> V5:
>> - Moved code causing a compilation error to this patch where the variable
>>   is actually declared
>> - Maintained blank lines / spacing so as to not contaminate the patch
>> V6:
>> - Removed extra debug messages
>> - Added documentation to for the added parameter on drm_edid_block_valid
>> - Fixed more whitespace issues in check_link_status
>> - Added a clear of the header_corrupt flag to the end of the test handler
>>   in intel_dp.c
>> - Changed the usage of the new function prototype in several places to use
>>   NULL where it is not needed by compliance testing
>> V7:
>> - Updated to account for long_pulse flag propagation
>> V8:
>> - Removed clearing of header_corrupt flag from the test handler in intel_dp.c
>> - Added clearing of header_corrupt flag in the drm_edid_block_valid function
>> V9:
>> - Renamed header_corrupt flag to edid_corrupt to more accurately reflect its
>>   value and purpose
>> - Updated commit message
>> V10:
>> - Updated for versioning and patch swizzle
>> - Revised the title to more accurately reflect the nature and contents of
>>   the patch
>> - Fixed formatting/whitespace problems
>> - Added set flag when computed checksum is invalid
>>
>> Signed-off-by: Todd Previte 
>> Cc: dri-de...@lists.freedesktop.org
>
> Seems reasonable.
>
> Reviewed-by: Alex Deucher 
Reviewed-by: Paulo Zanoni 
(since I made comments on the previous versions, this is my
documentation that the patch looks fine to me now)

>
>> ---
>>  drivers/gpu/drm/drm_edid.c  | 32 ++--
>>  drivers/gpu/drm/drm_edid_load.c |  7 +--
>>  include/drm/drm_crtc.h  |  8 +++-
>>  3 files changed, 38 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 53bc7a6..be6713c 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -1041,13 +1041,15 @@ static bool drm_edid_is_zero(const u8 *in_edid, int 
>> length)
>>   * @raw_edid: pointer to raw EDID block
>>   * @block: type of block to validate (0 for base, extension otherwise)
>>   * @print_bad_edid: if true, dump bad EDID blocks to the console
>> + * @edid_corrupt: if true, the header or checksum is invalid
>>   *
>>   * Validate a base or extension EDID block and optionally dump bad blocks to
>>   * the console.
>>   *
>>   * Return: True if the block is valid, false otherwise.
>>   */
>> -bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid)
>> +bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid,
>> + bool *edid_corrupt)
>>  {
>> u8 csum;
>> struct edid *edid = (struct edid *)raw_edid;
>> @@ -1060,11 +1062,22 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, 
>> bool print_bad_edid)
>>
>> if (block == 0) {
>> int score = drm_edid_header_is_valid(raw_edid);
>> -   if (score == 8) ;
>> -   else if (score >= edid_fixup) {
>> + 

Re: [Intel-gfx] Question regarding gem_alive test case in intel-gpu-tools-1.7 suite

[Chris Wilson]

On Thu, Apr 30, 2015 at 06:19:06PM +, Meng, David wrote:
>Hi Team:
> 
>Greetings.
> 
> 
> 
>I am new to send a question to this email list.  I am working on GPU
>driver for VMware ESXi kernel running on BDW system. The driver is based
>on the OTC graphics driver which is released with Linux 3.19.3.
> 
> 
> 
>When I tested the driver using the test case gem_alive from
>intel-gpu-tools -1.7, the result is always fail. The kernel driver
>complains that the object handle is 0.  By checking the gem_alive.c code,
>it is found the test case dose not create any gem object but tries to  use
> DRM_IOCTL_I915_GEM_SW_FINISH ioctl call to finish a object.  As a result,
>it returns –ENOENT error.
> 
> 
>I wonder is there any special kernel driver feature to be tested by this
>case?  Or we expect it is always fail?

The clue is in the various errno that is checked by gem_alive, and
consider how they can arise from various scenarios.

In short, the test can differentiate between a kernel deadlock, a GPU
hang and a functioning interface. It answers the question of whether
"GEM is alive".
-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 6/8] drivers/pwm: Add Crystalcove (CRC) PWM driver

[Paul Bolle]

On Wed, 2015-04-29 at 19:30 +0530, Shobhit Kumar wrote:
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
 
> +config PWM_CRC
> + bool "Intel Crystalcove (CRC) PWM support"
> + depends on X86 && INTEL_SOC_PMIC
> + help
> +   Generic PWM framework driver for Crystalcove (CRC) PMIC based PWM
> +   control.

> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile

> +obj-$(CONFIG_PWM_CRC)+= pwm-crc.o

PWM_CRC is a bool symbol. So pwm-crc.o can never be part of a module.

(If I'm wrong, and that object file can actually be part of a module,
you can stop reading here.)

> --- /dev/null
> +++ b/drivers/pwm/pwm-crc.c

> +#include 

Perhaps this include is not needed.

> +static const struct pwm_ops crc_pwm_ops = {
> + .config = crc_pwm_config,
> + .enable = crc_pwm_enable,
> + .disable = crc_pwm_disable,
> + .owner = THIS_MODULE,

For built-in only code THIS_MODULE is basically equivalent to NULL (see
include/linux/export.h). So I guess this line can be dropped.

> +};

> +static struct platform_driver crystalcove_pwm_driver = {
> + .probe = crystalcove_pwm_probe,
> + .remove = crystalcove_pwm_remove,
> + .driver = {
> + .name = "crystal_cove_pwm",
> + },
> +};
> +
> +module_platform_driver(crystalcove_pwm_driver);

Speaking from memory: for built-in only code this is equivalent to
calling 
platform_driver_register(&crystalcove_pwm_driver);

from a wrapper, and marking that wrapper with device_initcall().

> +MODULE_AUTHOR("Shobhit Kumar ");
> +MODULE_DESCRIPTION("Intel Crystal Cove PWM Driver");
> +MODULE_LICENSE("GPL v2");

These macros will be effectively preprocessed away for built-in only
code.


Paul Bolle

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

Re: [Intel-gfx] [PATCH] drm/i915/hdmi: fix vlv infoframe port check

[shuang . he]

Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
Task id: 6288
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  276/276  276/276
ILK  302/302  302/302
SNB  316/316  316/316
IVB  264/264  264/264
BYT -2  227/227  225/227
BDW  318/318  318/318
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
*BYT  igt@gem_dummy_reloc_loop@render  FAIL(1)PASS(11)  
TIMEOUT(1)PASS(1)
 BYT  igt@gem_pipe_control_store_loop@fresh-buffer  
FAIL(1)TIMEOUT(6)PASS(6)  TIMEOUT(1)PASS(1)
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 8/8] drm/i915: Backlight control using CRC PMIC based PWM driver

[shuang . he]

Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
Task id: 6290
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  276/276  276/276
ILK  301/301  301/301
SNB  316/316  316/316
IVB  342/342  342/342
BYT  286/286  286/286
BDW  321/321  321/321
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/hdmi: check port in ibx_infoframe_enabled

[shuang . he]

Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
Task id: 6289
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  276/276  276/276
ILK  302/302  302/302
SNB  316/316  316/316
IVB  264/264  264/264
BYT -3  227/227  224/227
BDW  318/318  318/318
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
*BYT  igt@gem_dummy_reloc_loop@render  FAIL(1)PASS(12)  
TIMEOUT(1)PASS(1)
 BYT  igt@gem_pipe_control_store_loop@fresh-buffer  
FAIL(1)TIMEOUT(7)PASS(6)  TIMEOUT(2)
*BYT  igt@gem_threaded_access_tiled  FAIL(1)PASS(4)  DMESG_WARN(1)
(dmesg patch 
applied)drm:check_crtc_state[i915]]*ERROR*mismatch_in_has_infoframe(expected#,found#)@mismatch
 in has_infoframe .* found
WARNING:at_drivers/gpu/drm/i915/intel_display.c:#check_crtc_state[i915]()@WARNING:.*
 at .* check_crtc_state+0x
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 02/11] drm/i915: Set scaler mode for NV12

[Chandra Konduru]

This patch sets appropriate scaler mode for NV12 format.
In this mode, skylake scaler does either chroma-upsampling or
chroma-upsampling and resolution scaling.

Signed-off-by: Chandra Konduru 
---
 drivers/gpu/drm/i915/intel_atomic.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index cb6d5f2..fe10f22 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -400,7 +400,10 @@ int intel_atomic_setup_scalers(struct drm_device *dev,
}
 
/* set scaler mode */
-   if (num_scalers_need == 1 && intel_crtc->pipe != PIPE_C) {
+   if (plane_state && plane_state->base.fb &&
+   plane_state->base.fb->pixel_format == DRM_FORMAT_NV12) {
+   scaler_state->scalers[*scaler_id].mode = 
PS_SCALER_MODE_NV12;
+   } else if (num_scalers_need == 1 && intel_crtc->pipe != PIPE_C) 
{
/*
 * when only 1 scaler is in use on either pipe A or B,
 * scaler 0 operates in high quality (HQ) mode.
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 03/11] drm/i915: Stage scaler request for NV12 as src format

[Chandra Konduru]

This patch stages a scaler request when input format
is NV12. The same scaler does both chroma-upsampling
and resolution scaling as needed.

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

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 22799fb..9d413a6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -,9 +,11 @@ skl_update_scaler_users(
rotation = DRM_ROTATE_0;
}
 
-   need_scaling = intel_rotation_90_or_270(rotation) ?
-   (src_h != dst_w || src_w != dst_h):
-   (src_w != dst_w || src_h != dst_h);
+   /* scaling is required when src dst sizes doesn't match or format is 
NV12 */
+   need_scaling = (src_w != dst_w || src_h != dst_h ||
+   (intel_rotation_90_or_270(rotation) &&
+   (src_h != dst_w || src_w != dst_h)) ||
+   (fb && fb->pixel_format == DRM_FORMAT_NV12));
 
/*
 * if plane is being disabled or scaler is no more required or force 
detach
@@ -4512,6 +4514,7 @@ skl_update_scaler_users(
case DRM_FORMAT_YVYU:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
+   case DRM_FORMAT_NV12:
break;
default:
DRM_DEBUG_KMS("PLANE:%d FB:%d unsupported scaling 
format 0x%x\n",
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 05/11] drm/i915: Upscale scaler max scale for NV12.

[Chandra Konduru]

This patch updates max supported scaler limits for NV12.

Signed-off-by: Chandra Konduru 
---
 drivers/gpu/drm/i915/intel_display.c |   12 
 drivers/gpu/drm/i915/intel_drv.h |3 ++-
 drivers/gpu/drm/i915/intel_sprite.c  |2 +-
 3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9d413a6..c235a66 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12893,7 +12893,8 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
 }
 
 int
-skl_max_scale(struct intel_crtc *intel_crtc, struct intel_crtc_state 
*crtc_state)
+skl_max_scale(struct intel_crtc *intel_crtc, struct intel_crtc_state 
*crtc_state,
+   uint32_t pixel_format)
 {
int max_scale;
struct drm_device *dev;
@@ -12913,11 +12914,13 @@ skl_max_scale(struct intel_crtc *intel_crtc, struct 
intel_crtc_state *crtc_state
 
/*
 * skl max scale is lower of:
-*close to 3 but not 3, -1 is for that purpose
+*close to 2 or 3 (NV12: 2, other formats: 3) but not equal,
+*  -1 is for that purpose
 *or
 *cdclk/crtc_clock
 */
-   max_scale = min((1 << 16) * 3 - 1, (1 << 8) * ((cdclk << 8) / 
crtc_clock));
+   max_scale = min((1 << 16) * (pixel_format == DRM_FORMAT_NV12 ? 2 : 3) - 
1,
+   (1 << 8) * ((cdclk << 8) / crtc_clock));
 
return max_scale;
 }
@@ -12947,7 +12950,8 @@ intel_check_primary_plane(struct drm_plane *plane,
 
if (INTEL_INFO(dev)->gen >= 9) {
min_scale = 1;
-   max_scale = skl_max_scale(intel_crtc, crtc_state);
+   max_scale = skl_max_scale(intel_crtc, crtc_state,
+   fb ? fb->pixel_format :0);
can_position = true;
}
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ccf89f8..fdd667d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1139,7 +1139,8 @@ void skl_detach_scalers(struct intel_crtc *intel_crtc);
 int skl_update_scaler_users(struct intel_crtc *intel_crtc,
struct intel_crtc_state *crtc_state, struct intel_plane *intel_plane,
struct intel_plane_state *plane_state, int force_detach);
-int skl_max_scale(struct intel_crtc *crtc, struct intel_crtc_state 
*crtc_state);
+int skl_max_scale(struct intel_crtc *crtc, struct intel_crtc_state *crtc_state,
+   uint32_t pixel_format);
 
 unsigned long intel_plane_obj_offset(struct intel_plane *intel_plane,
 struct drm_i915_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 5698a07..59846f8 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -901,7 +901,7 @@ intel_check_sprite_plane(struct drm_plane *plane,
 
if (INTEL_INFO(dev)->gen >= 9) {
min_scale = 1;
-   max_scale = skl_max_scale(intel_crtc, crtc_state);
+   max_scale = skl_max_scale(intel_crtc, crtc_state, 
fb->pixel_format);
}
 
drm_rect_rotate(src, fb->width << 16, fb->height << 16,
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 07/11] drm/i915: Add NV12 as supported format for sprite plane

[Chandra Konduru]

This patch adds NV12 to list of supported formats for
sprite plane.

Signed-off-by: Chandra Konduru 
Testcase: igt/kms_nv12
---
 drivers/gpu/drm/i915/intel_sprite.c |   23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 59846f8..aa2998f 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1207,6 +1207,19 @@ static uint32_t skl_plane_formats[] = {
DRM_FORMAT_VYUY,
 };
 
+static uint32_t skl_plane_formats_with_nv12[] = {
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_YUYV,
+   DRM_FORMAT_YVYU,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
+   DRM_FORMAT_NV12,
+};
+
 int
 intel_plane_init(struct drm_device *dev, enum pipe pipe, int plane)
 {
@@ -1278,8 +1291,14 @@ intel_plane_init(struct drm_device *dev, enum pipe pipe, 
int plane)
intel_plane->disable_plane = skl_disable_plane;
state->scaler_id = -1;
 
-   plane_formats = skl_plane_formats;
-   num_plane_formats = ARRAY_SIZE(skl_plane_formats);
+   if ((pipe == PIPE_A || pipe == PIPE_B) && (plane == 0)) {
+   plane_formats = skl_plane_formats_with_nv12;
+   num_plane_formats = 
ARRAY_SIZE(skl_plane_formats_with_nv12);
+   } else {
+   plane_formats = skl_plane_formats;
+   num_plane_formats = ARRAY_SIZE(skl_plane_formats) - 1;
+   }
+
break;
default:
kfree(intel_plane);
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 00/11] Skylake display NV12 feature addition

[Chandra Konduru]

This patch series adding NV12 support for Skylake display.
Feature is tested with igt/kms_nv12 testcase.
I will be sending the igt patches shortly.

Feature is unit tested for linear/X/Y/Yf formats in 0 and 180
orientations with combinations of 1, 2 or 3 planes enabled along
with scaling. Also negatively tested for enabling NV12 on unsupported
plane.

Chandra Konduru (11):
  drm/i915: Add register definitions for NV12 support
  drm/i915: Set scaler mode for NV12
  drm/i915: Stage scaler request for NV12 as src format
  drm/i915: Update format_is_yuv() to include NV12
  drm/i915: Upscale scaler max scale for NV12.
  drm/i915: Add NV12 as supported format for primary plane
  drm/i915: Add NV12 as supported format for sprite plane
  drm/i915: Add NV12 support to intel_framebuffer_init
  drm/i915: Update compute_baseline_bpp for NV12.
  drm/i915: Add NV12 to primary plane programming.
  drm/i915: Add NV12 to sprite plane programming.

 drivers/gpu/drm/i915/i915_reg.h   |   27 +++
 drivers/gpu/drm/i915/intel_atomic.c   |5 +-
 drivers/gpu/drm/i915/intel_atomic_plane.c |2 +
 drivers/gpu/drm/i915/intel_display.c  |  120 +++--
 drivers/gpu/drm/i915/intel_drv.h  |4 +-
 drivers/gpu/drm/i915/intel_sprite.c   |   59 --
 6 files changed, 201 insertions(+), 16 deletions(-)

-- 
1.7.9.5

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

[Intel-gfx] [PATCH 01/11] drm/i915: Add register definitions for NV12 support

[Chandra Konduru]

This patch adds register definitions for skylake
display NV12 support.

Signed-off-by: Chandra Konduru 
---
 drivers/gpu/drm/i915/i915_reg.h |   27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index aa2a0de..504d967 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5121,6 +5121,7 @@ enum skl_disp_power_wells {
 #define PS_SCALER_MODE_MASK (3 << 28)
 #define PS_SCALER_MODE_DYN  (0 << 28)
 #define PS_SCALER_MODE_HQ  (1 << 28)
+#define PS_SCALER_MODE_NV12 (2 << 28)
 #define PS_PLANE_SEL_MASK  (7 << 25)
 #define PS_PLANE_SEL(plane) ((plane + 1) << 25)
 #define PS_FILTER_MASK (3 << 23)
@@ -5224,6 +5225,32 @@ enum skl_disp_power_wells {
_ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A),   \
_ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B)
 
+
+/*
+ * Skylake  NV12 Register
+ */
+#define PLANE_AUX_DIST_1_A 0x701c0
+#define PLANE_AUX_DIST_2_A 0x702c0
+#define PLANE_AUX_DIST_1_B 0x711c0
+#define PLANE_AUX_DIST_2_B 0x712c0
+#define _PLANE_AUX_DIST_1(pipe)\
+   _PIPE(pipe, PLANE_AUX_DIST_1_A, PLANE_AUX_DIST_1_B)
+#define _PLANE_AUX_DIST_2(pipe)\
+   _PIPE(pipe, PLANE_AUX_DIST_2_A, PLANE_AUX_DIST_2_B)
+#define PLANE_AUX_DIST(pipe, plane)\
+   _PLANE(plane, _PLANE_AUX_DIST_1(pipe), _PLANE_AUX_DIST_2(pipe))
+
+#define PLANE_AUX_OFFSET_1_A   0x701c4
+#define PLANE_AUX_OFFSET_2_A   0x702c4
+#define PLANE_AUX_OFFSET_1_B   0x711c4
+#define PLANE_AUX_OFFSET_2_B   0x712c4
+#define _PLANE_AUX_OFFSET_1(pipe)  \
+   _PIPE(pipe, PLANE_AUX_OFFSET_1_A, PLANE_AUX_OFFSET_1_B)
+#define _PLANE_AUX_OFFSET_2(pipe)  \
+   _PIPE(pipe, PLANE_AUX_OFFSET_2_A, PLANE_AUX_OFFSET_2_B)
+#define PLANE_AUX_OFFSET(pipe, plane)  \
+   _PLANE(plane, _PLANE_AUX_OFFSET_1(pipe), _PLANE_AUX_OFFSET_2(pipe))
+
 /* legacy palette */
 #define _LGC_PALETTE_A   0x4a000
 #define _LGC_PALETTE_B   0x4a800
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 08/11] drm/i915: Add NV12 support to intel_framebuffer_init

[Chandra Konduru]

This patch adds NV12 as supported format to
intel_framebuffer_init and performs various checks.

Signed-off-by: Chandra Konduru 
Testcase: igt/kms_nv12
---
 drivers/gpu/drm/i915/intel_display.c |   27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d3773d2..6e693c4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13953,6 +13953,33 @@ static int intel_framebuffer_init(struct drm_device 
*dev,
return -EINVAL;
}
break;
+   case DRM_FORMAT_NV12:
+   if (INTEL_INFO(dev)->gen < 9) {
+   DRM_DEBUG("unsupported pixel format: %s\n",
+ drm_get_format_name(mode_cmd->pixel_format));
+   return -EINVAL;
+   }
+   if (!mode_cmd->offsets[1]) {
+   DRM_DEBUG("uv start offset not set\n");
+   return -EINVAL;
+   }
+   if (mode_cmd->pitches[0] != mode_cmd->pitches[1] ||
+   mode_cmd->handles[0] != mode_cmd->handles[1]) {
+   DRM_DEBUG("y and uv subplanes have different 
parameters\n");
+   return -EINVAL;
+   }
+   if (mode_cmd->modifier[1] == I915_FORMAT_MOD_Yf_TILED &&
+   (mode_cmd->offsets[1] & 0xFFF)) {
+   DRM_DEBUG("tile-Yf uv offset 0x%x isn't starting on new 
tile-row\n",
+   mode_cmd->offsets[1]);
+   return -EINVAL;
+   }
+   if (mode_cmd->modifier[1] == I915_FORMAT_MOD_Y_TILED &&
+   ((mode_cmd->offsets[1] % mode_cmd->pitches[1]) % 4)) {
+   DRM_DEBUG("tile-Y uv offset 0x%x isn't 4-line 
aligned\n",
+   mode_cmd->offsets[1]);
+   }
+   break;
default:
DRM_DEBUG("unsupported pixel format: %s\n",
  drm_get_format_name(mode_cmd->pixel_format));
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 09/11] drm/i915: Update compute_baseline_bpp for NV12.

[Chandra Konduru]

This patch updates baseline bpp when primary plane
is running with NV12. It is same as 8-bpc RGB formats
because NV12 also has 8-bits per channel.

Signed-off-by: Chandra Konduru 
---
 drivers/gpu/drm/i915/intel_display.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 6e693c4..e747766 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10845,6 +10845,7 @@ compute_baseline_pipe_bpp(struct intel_crtc *crtc,
return -EINVAL;
case DRM_FORMAT_XRGB:
case DRM_FORMAT_ARGB:
+   case DRM_FORMAT_NV12:
bpp = 8*3;
break;
case DRM_FORMAT_XRGB2101010:
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 11/11] drm/i915: Add NV12 to sprite plane programming.

[Chandra Konduru]

This patch is adding NV12 support to skylake sprite plane
programming. It is covering linear/X/Y/Yf tiling formats
for 0 and 180 rotations.

For 90/270 rotation, Y and UV subplanes should be treated
as separate surfaces and GTT remapping for rotation should
be done separately for each subplane. Once GEM adds support
for seperate remappings for two subplanes, 90/270 support
to be added to plane programming.

Signed-off-by: Chandra Konduru 
Testcase: igt/kms_nv12
---
 drivers/gpu/drm/i915/intel_sprite.c |   31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index aa2998f..2a03905 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -201,6 +201,8 @@ skl_update_plane(struct drm_plane *drm_plane, struct 
drm_crtc *crtc,
int x_offset, y_offset;
struct intel_crtc_state *crtc_state = to_intel_crtc(crtc)->config;
int scaler_id;
+   u32 aux_dist = 0, aux_x_offset = 0, aux_y_offset = 0, aux_stride = 0;
+   u32 tile_row_adjustment = 0;
 
plane_ctl = PLANE_CTL_ENABLE |
PLANE_CTL_PIPE_CSC_ENABLE;
@@ -247,24 +249,48 @@ skl_update_plane(struct drm_plane *drm_plane, struct 
drm_crtc *crtc,
plane_size = (src_w << 16) | src_h;
x_offset = stride * tile_height - y - (src_h + 1);
y_offset = x;
+
+   /*
+* TBD: For NV12 90/270 rotation, Y and UV subplanes should
+* be treated as separate surfaces and GTT remapping for
+* rotation should be done separately for each subplane.
+* Enable support once seperate remappings are available.
+*/
} else {
stride = fb->pitches[0] / stride_div;
plane_size = (src_h << 16) | src_w;
x_offset = x;
y_offset = y;
+   tile_height = PAGE_SIZE / stride_div;
+
+   if (fb->pixel_format == DRM_FORMAT_NV12) {
+   int height_in_mem = (fb->offsets[1]/fb->pitches[0]);
+   /*
+* If UV starts from middle of a page, then UV start 
should
+* be programmed to beginning of that page. And offset 
into that
+* page to be programmed into y-offset
+*/
+   tile_row_adjustment = height_in_mem % tile_height;
+   aux_dist = fb->pitches[0] * (height_in_mem - 
tile_row_adjustment);
+   aux_x_offset = DIV_ROUND_UP(x, 2);
+   aux_y_offset = DIV_ROUND_UP(y, 2) + tile_row_adjustment;
+   /* For tile-Yf, uv-subplane tile width is 2x of 
Y-subplane */
+   aux_stride = fb->modifier[0] == 
I915_FORMAT_MOD_Yf_TILED ?
+   stride / 2 : stride;
+   }
}
plane_offset = y_offset << 16 | x_offset;
 
I915_WRITE(PLANE_OFFSET(pipe, plane), plane_offset);
I915_WRITE(PLANE_STRIDE(pipe, plane), stride);
I915_WRITE(PLANE_SIZE(pipe, plane), plane_size);
+   I915_WRITE(PLANE_AUX_DIST(pipe, plane), aux_dist | aux_stride);
+   I915_WRITE(PLANE_AUX_OFFSET(pipe, plane), aux_y_offset<<16 | 
aux_x_offset);
 
/* program plane scaler */
if (scaler_id >= 0) {
uint32_t ps_ctrl = 0;
 
-   DRM_DEBUG_KMS("plane = %d PS_PLANE_SEL(plane) = 0x%x\n", plane,
-   PS_PLANE_SEL(plane));
ps_ctrl = PS_SCALER_EN | PS_PLANE_SEL(plane) |
crtc_state->scaler_state.scalers[scaler_id].mode;
I915_WRITE(SKL_PS_CTRL(pipe, scaler_id), ps_ctrl);
@@ -275,6 +301,7 @@ skl_update_plane(struct drm_plane *drm_plane, struct 
drm_crtc *crtc,
 
I915_WRITE(PLANE_POS(pipe, plane), 0);
} else {
+   WARN_ON(fb->pixel_format == DRM_FORMAT_NV12);
I915_WRITE(PLANE_POS(pipe, plane), (crtc_y << 16) | crtc_x);
}
 
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 06/11] drm/i915: Add NV12 as supported format for primary plane

[Chandra Konduru]

This patch adds NV12 to list of supported formats for
primary plane.

Signed-off-by: Chandra Konduru 
Testcase: igt/kms_nv12
---
 drivers/gpu/drm/i915/intel_display.c |   32 +++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index c235a66..d3773d2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -59,7 +59,7 @@ static const uint32_t intel_primary_formats_gen2[] = {
DRM_FORMAT_ARGB1555,
 };
 
-/* Primary plane formats for gen >= 4 */
+/* Primary plane formats for gen 4 to 8 */
 static const uint32_t intel_primary_formats_gen4[] = {
COMMON_PRIMARY_FORMATS, \
DRM_FORMAT_XBGR,
@@ -70,6 +70,28 @@ static const uint32_t intel_primary_formats_gen4[] = {
DRM_FORMAT_ABGR2101010,
 };
 
+/* Primary plane formats for gen >= 9 */
+static const uint32_t intel_primary_formats_gen9[] = {
+   COMMON_PRIMARY_FORMATS, \
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_XRGB2101010,
+   DRM_FORMAT_ARGB2101010,
+   DRM_FORMAT_XBGR2101010,
+   DRM_FORMAT_ABGR2101010,
+};
+
+static const uint32_t intel_primary_formats_with_nv12_gen9[] = {
+   COMMON_PRIMARY_FORMATS, \
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_XRGB2101010,
+   DRM_FORMAT_ARGB2101010,
+   DRM_FORMAT_XBGR2101010,
+   DRM_FORMAT_ABGR2101010,
+   DRM_FORMAT_NV12,
+};
+
 /* Cursor formats */
 static const uint32_t intel_cursor_formats[] = {
DRM_FORMAT_ARGB,
@@ -13204,6 +13226,14 @@ static struct drm_plane 
*intel_primary_plane_create(struct drm_device *dev,
if (INTEL_INFO(dev)->gen <= 3) {
intel_primary_formats = intel_primary_formats_gen2;
num_formats = ARRAY_SIZE(intel_primary_formats_gen2);
+   } else if (INTEL_INFO(dev)->gen >= 9) {
+   if (pipe == PIPE_A || pipe == PIPE_B) {
+   intel_primary_formats = 
intel_primary_formats_with_nv12_gen9;
+   num_formats = 
ARRAY_SIZE(intel_primary_formats_with_nv12_gen9);
+   } else {
+   intel_primary_formats = intel_primary_formats_gen9;
+   num_formats = ARRAY_SIZE(intel_primary_formats_gen9);
+   }
} else {
intel_primary_formats = intel_primary_formats_gen4;
num_formats = ARRAY_SIZE(intel_primary_formats_gen4);
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 04/11] drm/i915: Update format_is_yuv() to include NV12

[Chandra Konduru]

This patch adds NV12 to format_is_yuv() function
and made it available for both primary and sprite
planes.

Signed-off-by: Chandra Konduru 
---
 drivers/gpu/drm/i915/intel_drv.h|1 +
 drivers/gpu/drm/i915/intel_sprite.c |3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 8079865..ccf89f8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1376,6 +1376,7 @@ bool intel_pipe_update_start(struct intel_crtc *crtc,
 void intel_pipe_update_end(struct intel_crtc *crtc, u32 start_vbl_count);
 void intel_post_enable_primary(struct drm_crtc *crtc);
 void intel_pre_disable_primary(struct drm_crtc *crtc);
+bool format_is_yuv(uint32_t format);
 
 /* intel_tv.c */
 void intel_tv_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 68de97c..5698a07 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -39,7 +39,7 @@
 #include 
 #include "i915_drv.h"
 
-static bool
+bool
 format_is_yuv(uint32_t format)
 {
switch (format) {
@@ -47,6 +47,7 @@ format_is_yuv(uint32_t format)
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_YVYU:
+   case DRM_FORMAT_NV12:
return true;
default:
return false;
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 10/11] drm/i915: Add NV12 to primary plane programming.

[Chandra Konduru]

This patch is adding NV12 support to skylake primary plane
programming. It is covering linear/X/Y/Yf tiling formats
for 0 and 180 rotations.

For 90/270 rotation, Y and UV subplanes should be treated
as separate surfaces and GTT remapping for rotation should
be done separately for each subplane. Once GEM adds support
for seperate remappings for two subplanes, 90/270 support
to be added to plane programming.

Signed-off-by: Chandra Konduru 
Testcase: igt/kms_nv12
---
 drivers/gpu/drm/i915/intel_atomic_plane.c |2 ++
 drivers/gpu/drm/i915/intel_display.c  |   39 +
 2 files changed, 41 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index a27ee8c..84cd9fc 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -173,10 +173,12 @@ static int intel_plane_atomic_check(struct drm_plane 
*plane,
 * 90/270 is not allowed with RGB64 16:16:16:16,
 * RGB 16-bit 5:6:5, and Indexed 8-bit.
 * TBD: Add RGB64 case once its added in supported format list.
+* TBD: Remove NV12, once its 90/270 remapping is supported
 */
switch (state->fb->pixel_format) {
case DRM_FORMAT_C8:
case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_NV12:
DRM_DEBUG_KMS("Unsupported pixel format %s for 
90/270!\n",

drm_get_format_name(state->fb->pixel_format));
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e747766..c9d5cc9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3026,6 +3026,9 @@ u32 skl_plane_ctl_format(uint32_t pixel_format)
case DRM_FORMAT_VYUY:
plane_ctl_format = PLANE_CTL_FORMAT_YUV422 | 
PLANE_CTL_YUV422_VYUY;
break;
+   case DRM_FORMAT_NV12:
+   plane_ctl_format = PLANE_CTL_FORMAT_NV12;
+   break;
default:
BUG();
}
@@ -3095,6 +3098,8 @@ static void skylake_update_primary_plane(struct drm_crtc 
*crtc,
int src_x = 0, src_y = 0, src_w = 0, src_h = 0;
int dst_x = 0, dst_y = 0, dst_w = 0, dst_h = 0;
int scaler_id = -1;
+   u32 aux_dist = 0, aux_x_offset = 0, aux_y_offset = 0, aux_stride = 0;
+   u32 tile_row_adjustment = 0;
 
plane = crtc->primary;
plane_state = to_intel_plane_state(plane->state);
@@ -3152,11 +3157,35 @@ static void skylake_update_primary_plane(struct 
drm_crtc *crtc,
x_offset = stride * tile_height - y - src_h;
y_offset = x;
plane_size = (src_w - 1) << 16 | (src_h - 1);
+   /*
+* TBD: For NV12 90/270 rotation, Y and UV subplanes should
+* be treated as separate surfaces and GTT remapping for
+* rotation should be done separately for each subplane.
+* Enable support once seperate remappings are available.
+*/
} else {
stride = fb->pitches[0] / stride_div;
x_offset = x;
y_offset = y;
plane_size = (src_h - 1) << 16 | (src_w - 1);
+   tile_height = PAGE_SIZE / stride_div;
+
+   if (fb->pixel_format == DRM_FORMAT_NV12) {
+   int height_in_mem = (fb->offsets[1]/fb->pitches[0]);
+   /*
+* If UV starts from middle of a page, then UV start 
should
+* be programmed to beginning of that page. And offset 
into that
+* page to be programmed into y-offset
+*/
+   tile_row_adjustment = height_in_mem % tile_height;
+   aux_dist = fb->pitches[0] * (height_in_mem - 
tile_row_adjustment);
+   aux_x_offset = DIV_ROUND_UP(plane_state->src.x1, 2);
+   aux_y_offset = DIV_ROUND_UP(plane_state->src.y1, 2) +
+   tile_row_adjustment;
+   /* For tile-Yf, uv-subplane tile width is 2x of 
Y-subplane */
+   aux_stride = fb->modifier[0] == 
I915_FORMAT_MOD_Yf_TILED ?
+   stride / 2 : stride;
+   }
}
plane_offset = y_offset << 16 | x_offset;
 
@@ -3164,11 +3193,14 @@ static void skylake_update_primary_plane(struct 
drm_crtc *crtc,
I915_WRITE(PLANE_OFFSET(pipe, 0), plane_offset);
I915_WRITE(PLANE_SIZE(pipe, 0), plane_size);
I915_WRITE(PLANE_STRIDE(pipe, 0), stride);
+   I915_WRITE(PLANE_AUX_DIST(pipe, 0), aux_dist | aux_stride);
+   I915_WRITE(PLANE_AUX_OFFSET(pipe, 0), aux_y_offset << 16 | 
aux_x_offset);
 
if (scaler_id >= 0) {

Re: [Intel-gfx] [PATCH] drm/i915: Preallocate request before access of the ring

[shuang . he]

Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
Task id: 6292
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  276/276  276/276
ILK  302/302  302/302
SNB  316/316  316/316
IVB  264/264  264/264
BYT -3  227/227  224/227
BDW  318/318  318/318
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
*BYT  igt@gem_dummy_reloc_loop@render  FAIL(1)PASS(13)  
TIMEOUT(1)PASS(1)
*BYT  igt@gem_exec_parse@bitmasks  FAIL(1)PASS(6)  DMESG_WARN(1)PASS(1)
(dmesg patch 
applied)drm:check_crtc_state[i915]]*ERROR*mismatch_in_has_infoframe(expected#,found#)@mismatch
 in has_infoframe .* found
WARNING:at_drivers/gpu/drm/i915/intel_display.c:#check_crtc_state[i915]()@WARNING:.*
 at .* check_crtc_state+0x
 BYT  igt@gem_pipe_control_store_loop@fresh-buffer  
FAIL(1)TIMEOUT(7)PASS(7)  TIMEOUT(1)PASS(1)
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx