[Intel-gfx] [PATCH] Fix list empty check in i915_gem_evict_everything

[Zhiyuan Lv]

That seems to be a typo. The original code will override the previous
list empty check value in the loop. As the result, only the last vm in
vm_list impacts the empty check. The problem is fixed by using local
bool variable inside the loop.

Signed-off-by: Zhiyuan Lv 
---
 drivers/gpu/drm/i915/i915_gem_evict.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
b/drivers/gpu/drm/i915/i915_gem_evict.c
index d09e35e..a45cffa 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -255,10 +255,12 @@ i915_gem_evict_everything(struct drm_device *dev)
int ret;
 
list_for_each_entry(vm, &dev_priv->vm_list, global_link) {
-   lists_empty = (list_empty(&vm->inactive_list) &&
+   bool empty = (list_empty(&vm->inactive_list) &&
   list_empty(&vm->active_list));
-   if (!lists_empty)
+   if (!empty) {
lists_empty = false;
+   break;
+   }
}
 
if (lists_empty)
-- 
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 build warning on 32-bit

[Daniel Vetter]

On Mon, Aug 17, 2015 at 05:19:09PM +, Zanoni, Paulo R wrote:
> Em Sex, 2015-08-14 às 12:35 +0200, Thierry Reding escreveu:
> > From: Thierry Reding 
> > 
> > The gtt.stolen_size field is of type size_t, and so should be printed
> > using %zu to avoid build warnings on either 32-bit and 64-bit builds.
> 
> While the suggestion from Chris sounds good, this patch alone is
> already a fix, so:
> Reviewed-by: Paulo Zanoni 

Queued for -next, thanks for the patch.
-Daniel

> 
> > 
> > Signed-off-by: Thierry Reding 
> > ---
> >  drivers/gpu/drm/i915/i915_gem_stolen.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
> > b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > index a36cb95ec798..f361c4a56995 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > @@ -348,7 +348,7 @@ int i915_gem_init_stolen(struct drm_device *dev)
> >  * memory, so just consider the start. */
> > reserved_total = stolen_top - reserved_base;
> >  
> > -   DRM_DEBUG_KMS("Memory reserved for graphics device: %luK, 
> > usable: %luK\n",
> > +   DRM_DEBUG_KMS("Memory reserved for graphics device: %zuK, 
> > usable: %luK\n",
> >   dev_priv->gtt.stolen_size >> 10,
> >   (dev_priv->gtt.stolen_size - reserved_total) 
> > >> 10);
> >  
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/bxt: don't allow cached GEM mappings on A stepping

[Daniel Vetter]

On Fri, Aug 14, 2015 at 05:18:27PM +0100, Chris Wilson wrote:
> On Fri, Aug 14, 2015 at 06:43:30PM +0300, Imre Deak wrote:
> > Due to a coherency issue on BXT A steppings we can't guarantee a
> > coherent view of cached (CPU snooped) GPU mappings, so fail such
> > requests. User space is supposed to fall back to uncached mappings in
> > this case.
> > 
> > v2:
> > - limit the WA to A steppings, on later stepping this HW issue is fixed
> > v3:
> > - return error instead of trying to work around the issue in kernel,
> >   since that could confuse user space (Chris)
> > 
> > Testcast: igt/gem_store_dword_batches_loop/cached-mapping
> > Signed-off-by: Imre Deak 
> 
> I checked in the two userspaces where I have used snooping that both
> handle an error correctly, so
> 
> Reviewed-by: Chris Wilson 

Both patches applied, thanks.
-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

Re: [Intel-gfx] [PATCH 5/6 v3] drm/i915/skl: enable DDI-E hotplug

[Jani Nikula]

On Mon, 17 Aug 2015, Xiong Zhang  wrote:
> v2: fix one error found by checkpath.pl
> v3: Add one ignored break for switch-case. DDI-E hotplug
> function doesn't work after updating drm-intel tree,
> I checked the code and found this missing which isn't
> the root cause for broke DDI-E hp.  The broken
> DDI-E hp function is fixed by "Adding DDI_E power
> well domain".
>
> Signed-off-by: Xiong Zhang 
> Reviewed-by: Rodrigo Vivi 
> Tested-by: Timo Aaltonen 

Pushed to drm-intel-next-fixes.

BR,
Jani.

> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
>  drivers/gpu/drm/i915/i915_irq.c  | 48 
> +---
>  drivers/gpu/drm/i915/i915_reg.h  | 12 +
>  drivers/gpu/drm/i915/intel_display.c |  3 +++
>  drivers/gpu/drm/i915/intel_dp.c  |  3 +++
>  drivers/gpu/drm/i915/intel_hotplug.c |  3 +++
>  6 files changed, 66 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e0f3f05..5f6fd0b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -215,6 +215,7 @@ enum hpd_pin {
>   HPD_PORT_B,
>   HPD_PORT_C,
>   HPD_PORT_D,
> + HPD_PORT_E,
>   HPD_NUM_PINS
>  };
>  
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index a051045..8485bea 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -61,6 +61,13 @@ static const u32 hpd_cpt[HPD_NUM_PINS] = {
>   [HPD_PORT_D] = SDE_PORTD_HOTPLUG_CPT
>  };
>  
> +static const u32 hpd_spt[HPD_NUM_PINS] = {
> + [HPD_PORT_B] = SDE_PORTB_HOTPLUG_CPT,
> + [HPD_PORT_C] = SDE_PORTC_HOTPLUG_CPT,
> + [HPD_PORT_D] = SDE_PORTD_HOTPLUG_CPT,
> + [HPD_PORT_E] = SDE_PORTE_HOTPLUG_SPT
> +};
> +
>  static const u32 hpd_mask_i915[HPD_NUM_PINS] = {
>   [HPD_CRT] = CRT_HOTPLUG_INT_EN,
>   [HPD_SDVO_B] = SDVOB_HOTPLUG_INT_EN,
> @@ -1253,6 +1260,8 @@ static bool pch_port_hotplug_long_detect(enum port 
> port, u32 val)
>   return val & PORTC_HOTPLUG_LONG_DETECT;
>   case PORT_D:
>   return val & PORTD_HOTPLUG_LONG_DETECT;
> + case PORT_E:
> + return val & PORTE_HOTPLUG_LONG_DETECT;
>   default:
>   return false;
>   }
> @@ -1753,7 +1762,12 @@ static void cpt_irq_handler(struct drm_device *dev, 
> u32 pch_iir)
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   int pipe;
> - u32 hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_CPT;
> + u32 hotplug_trigger;
> +
> + if (HAS_PCH_SPT(dev))
> + hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_SPT;
> + else
> + hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_CPT;
>  
>   if (hotplug_trigger) {
>   u32 dig_hotplug_reg, pin_mask, long_mask;
> @@ -1761,9 +1775,23 @@ static void cpt_irq_handler(struct drm_device *dev, 
> u32 pch_iir)
>   dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
>   I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
>  
> - intel_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
> -dig_hotplug_reg, hpd_cpt,
> -pch_port_hotplug_long_detect);
> + if (HAS_PCH_SPT(dev)) {
> + intel_get_hpd_pins(&pin_mask, &long_mask,
> +hotplug_trigger,
> +dig_hotplug_reg, hpd_spt,
> +pch_port_hotplug_long_detect);
> +
> + /* detect PORTE HP event */
> + dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG2);
> + if (pch_port_hotplug_long_detect(PORT_E,
> +  dig_hotplug_reg))
> + long_mask |= 1 << HPD_PORT_E;
> + } else
> + intel_get_hpd_pins(&pin_mask, &long_mask,
> +hotplug_trigger,
> +dig_hotplug_reg, hpd_cpt,
> +pch_port_hotplug_long_detect);
> +
>   intel_hpd_irq_handler(dev, pin_mask, long_mask);
>   }
>  
> @@ -2985,6 +3013,11 @@ static void ibx_hpd_irq_setup(struct drm_device *dev)
>   for_each_intel_encoder(dev, intel_encoder)
>   if 
> (dev_priv->hotplug.stats[intel_encoder->hpd_pin].state == HPD_ENABLED)
>   enabled_irqs |= hpd_ibx[intel_encoder->hpd_pin];
> + } else if (HAS_PCH_SPT(dev)) {
> + hotplug_irqs = SDE_HOTPLUG_MASK_SPT;
> + for_each_intel_encoder(dev, intel_encoder)
> + if 
> (dev_priv->hotplug.stats[intel_encoder->hpd_pin].state == HPD_ENABLED)
> + enabled_irqs |= hpd_spt[intel_encoder->hpd_pin];
>   } else {
>   hotplug_irqs = SDE_HOTPLU

Re: [Intel-gfx] [PATCH] drm/i915: Fix build warning on 32-bit

[Jani Nikula]

On Wed, 26 Aug 2015, Daniel Vetter  wrote:
> On Mon, Aug 17, 2015 at 05:19:09PM +, Zanoni, Paulo R wrote:
>> Em Sex, 2015-08-14 às 12:35 +0200, Thierry Reding escreveu:
>> > From: Thierry Reding 
>> > 
>> > The gtt.stolen_size field is of type size_t, and so should be printed
>> > using %zu to avoid build warnings on either 32-bit and 64-bit builds.
>> 
>> While the suggestion from Chris sounds good, this patch alone is
>> already a fix, so:
>> Reviewed-by: Paulo Zanoni 
>
> Queued for -next, thanks for the patch.

Great. Also pushed to drm-intel-next-fixes.

Jani.


> -Daniel
>
>> 
>> > 
>> > Signed-off-by: Thierry Reding 
>> > ---
>> >  drivers/gpu/drm/i915/i915_gem_stolen.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> > 
>> > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
>> > b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> > index a36cb95ec798..f361c4a56995 100644
>> > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
>> > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> > @@ -348,7 +348,7 @@ int i915_gem_init_stolen(struct drm_device *dev)
>> > * memory, so just consider the start. */
>> >reserved_total = stolen_top - reserved_base;
>> >  
>> > -  DRM_DEBUG_KMS("Memory reserved for graphics device: %luK, 
>> > usable: %luK\n",
>> > +  DRM_DEBUG_KMS("Memory reserved for graphics device: %zuK, 
>> > usable: %luK\n",
>> >  dev_priv->gtt.stolen_size >> 10,
>> >  (dev_priv->gtt.stolen_size - reserved_total) 
>> > >> 10);
>> >  
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> 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] drm/i915/skl: Update DDI buffer translation programming.

[Jani Nikula]

On Tue, 25 Aug 2015, Rodrigo Vivi  wrote:
> SKL-Y can now use the same programming for all VccIO values after an 
> adjustment to I_boost.
> SKL-U DP table adjustments.
> 1.   Remove SKL Y 0.95V from "SKL H and S" columns in all tables.  The 
> other SKL Y column removes the "0.85V VccIO" so it now applies to all 
> voltages.
> 2.   DP table changes SKL U 400mV+0db dword 0 value from 2016h to 201Bh.
> 3.   DP table changes SKL U 600mv+0db dword 0 value from 2016h to 201Bh.
> 4.   DP table increases I_boost to level 3 for SKL Y 400mv+9.5db.
>
> v2: Fix compilation warnings as pointed by Paulo.
>
> Reference: Graphics Spec Change r97962
> Cc: Arthur Runyan 
> Signed-off-by: Rodrigo Vivi 
> Reviewed-by: Paulo Zanoni 

Pushed to drm-intel-next-fixes.

BR,
Jani.


> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 75 
> ++--
>  1 file changed, 25 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 56d778f..3b056c4 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -128,7 +128,7 @@ static const struct ddi_buf_trans 
> bdw_ddi_translations_hdmi[] = {
>   { 0x80FF, 0x001B0002, 0x0 },/* 9:   100010000   */
>  };
>  
> -/* Skylake H, S, and Skylake Y with 0.95V VccIO */
> +/* Skylake H and S */
>  static const struct ddi_buf_trans skl_ddi_translations_dp[] = {
>   { 0x2016, 0x00A0, 0x0 },
>   { 0x5012, 0x009B, 0x0 },
> @@ -143,23 +143,23 @@ static const struct ddi_buf_trans 
> skl_ddi_translations_dp[] = {
>  
>  /* Skylake U */
>  static const struct ddi_buf_trans skl_u_ddi_translations_dp[] = {
> - { 0x2016, 0x00A2, 0x0 },
> + { 0x201B, 0x00A2, 0x0 },
>   { 0x5012, 0x0088, 0x0 },
>   { 0x7011, 0x0087, 0x0 },
> - { 0x80009010, 0x00C7, 0x1 },/* Uses I_boost */
> - { 0x2016, 0x009D, 0x0 },
> + { 0x80009010, 0x00C7, 0x1 },/* Uses I_boost level 0x1 */
> + { 0x201B, 0x009D, 0x0 },
>   { 0x5012, 0x00C7, 0x0 },
>   { 0x7011, 0x00C7, 0x0 },
>   { 0x2016, 0x0088, 0x0 },
>   { 0x5012, 0x00C7, 0x0 },
>  };
>  
> -/* Skylake Y with 0.85V VccIO */
> -static const struct ddi_buf_trans skl_y_085v_ddi_translations_dp[] = {
> +/* Skylake Y */
> +static const struct ddi_buf_trans skl_y_ddi_translations_dp[] = {
>   { 0x0018, 0x00A2, 0x0 },
>   { 0x5012, 0x0088, 0x0 },
>   { 0x7011, 0x0087, 0x0 },
> - { 0x80009010, 0x00C7, 0x1 },/* Uses I_boost */
> + { 0x80009010, 0x00C7, 0x3 },/* Uses I_boost level 0x3 */
>   { 0x0018, 0x009D, 0x0 },
>   { 0x5012, 0x00C7, 0x0 },
>   { 0x7011, 0x00C7, 0x0 },
> @@ -168,7 +168,7 @@ static const struct ddi_buf_trans 
> skl_y_085v_ddi_translations_dp[] = {
>  };
>  
>  /*
> - * Skylake H and S, and Skylake Y with 0.95V VccIO
> + * Skylake H and S
>   * eDP 1.4 low vswing translation parameters
>   */
>  static const struct ddi_buf_trans skl_ddi_translations_edp[] = {
> @@ -202,10 +202,10 @@ static const struct ddi_buf_trans 
> skl_u_ddi_translations_edp[] = {
>  };
>  
>  /*
> - * Skylake Y with 0.95V VccIO
> + * Skylake Y
>   * eDP 1.4 low vswing translation parameters
>   */
> -static const struct ddi_buf_trans skl_y_085v_ddi_translations_edp[] = {
> +static const struct ddi_buf_trans skl_y_ddi_translations_edp[] = {
>   { 0x0018, 0x00A8, 0x0 },
>   { 0x4013, 0x00AB, 0x0 },
>   { 0x7011, 0x00A4, 0x0 },
> @@ -218,7 +218,7 @@ static const struct ddi_buf_trans 
> skl_y_085v_ddi_translations_edp[] = {
>   { 0x0018, 0x008A, 0x0 },
>  };
>  
> -/* Skylake H, S and U, and Skylake Y with 0.95V VccIO */
> +/* Skylake U, H and S */
>  static const struct ddi_buf_trans skl_ddi_translations_hdmi[] = {
>   { 0x0018, 0x00AC, 0x0 },
>   { 0x5012, 0x009D, 0x0 },
> @@ -233,8 +233,8 @@ static const struct ddi_buf_trans 
> skl_ddi_translations_hdmi[] = {
>   { 0x0018, 0x00C7, 0x0 },
>  };
>  
> -/* Skylake Y with 0.85V VccIO */
> -static const struct ddi_buf_trans skl_y_085v_ddi_translations_hdmi[] = {
> +/* Skylake Y */
> +static const struct ddi_buf_trans skl_y_ddi_translations_hdmi[] = {
>   { 0x0018, 0x00A1, 0x0 },
>   { 0x5012, 0x00DF, 0x0 },
>   { 0x7011, 0x0084, 0x0 },
> @@ -244,7 +244,7 @@ static const struct ddi_buf_trans 
> skl_y_085v_ddi_translations_hdmi[] = {
>   { 0x6013, 0x00C7, 0x0 },
>   { 0x0018, 0x008A, 0x0 },
>   { 0x3015, 0x00C7, 0x0 },/* Default */
> - { 0x80003015, 0x00C7, 0x7 },/* Uses I_boost */
> + { 0x80003015, 0x00C7, 0x7 },/* Uses I_boost level 0x7 */
>   { 0x0018, 0x00C7, 0x0 },
>  };
>  
> @@ -335,19 +335,11 @@ intel_dig_port_suppo

Re: [Intel-gfx] [PATCH] Fix list empty check in i915_gem_evict_everything

[Chris Wilson]

On Wed, Aug 26, 2015 at 03:01:26PM +0800, Zhiyuan Lv wrote:
> That seems to be a typo. The original code will override the previous
> list empty check value in the loop. As the result, only the last vm in
> vm_list impacts the empty check. The problem is fixed by using local
> bool variable inside the loop.

Or we could just delete the code entirely since it is no longer used
(except for a mistake in shrink-all).
-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] Partially revert "drm/i915: Use full atomic modeset."

[Maarten Lankhorst]

This partially reverts commit 74c090b1bdc57b1c9f1361908cca5a3d8a80fb08.

The DRIVER_ATOMIC cap cannot yet be exported because i915 lacks async
support.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_drv.c| 2 +-
 drivers/gpu/drm/i915/i915_drv.h| 1 +
 drivers/gpu/drm/i915/i915_params.c | 5 +
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 151263b433e6..1c8d16fe8b0b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1725,7 +1725,7 @@ static int __init i915_init(void)
 * to the atomic ioctl and the atomic properties.  Only plane 
operations on
 * a single CRTC will actually work.
 */
-   if (driver.driver_features & DRIVER_MODESET)
+   if (i915.nuclear_pageflip)
driver.driver_features |= DRIVER_ATOMIC;
 
return drm_pci_init(&driver, &i915_pci_driver);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 86e69f1ad3ee..69bd3fef9f17 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2615,6 +2615,7 @@ struct i915_params {
int use_mmio_flip;
int mmio_debug;
bool verbose_state_checks;
+   bool nuclear_pageflip;
int edp_vswing;
 };
 extern struct i915_params i915 __read_mostly;
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 5ae4b0aba564..05053e2e9ff0 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -51,6 +51,7 @@ struct i915_params i915 __read_mostly = {
.use_mmio_flip = 0,
.mmio_debug = 0,
.verbose_state_checks = 1,
+   .nuclear_pageflip = 0,
.edp_vswing = 0,
.enable_guc_submission = false,
.guc_log_level = -1,
@@ -177,6 +178,10 @@ module_param_named(verbose_state_checks, 
i915.verbose_state_checks, bool, 0600);
 MODULE_PARM_DESC(verbose_state_checks,
"Enable verbose logs (ie. WARN_ON()) in case of unexpected hw state 
conditions.");
 
+module_param_named_unsafe(nuclear_pageflip, i915.nuclear_pageflip, bool, 0600);
+MODULE_PARM_DESC(nuclear_pageflip,
+"Force atomic modeset functionality; asynchronous mode is not 
yet supported. (default: false).");
+
 /* WA to get away with the default setting in VBT for early platforms.Will be 
removed */
 module_param_named_unsafe(edp_vswing, i915.edp_vswing, int, 0400);
 MODULE_PARM_DESC(edp_vswing,
-- 
2.1.0

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

Re: [Intel-gfx] [PATCH] drm/i915: Clear PIPE.STAT before IIR on VLV/CHV

[Daniel Vetter]

On Fri, Aug 14, 2015 at 06:24:32PM +0100, Chris Wilson wrote:
> The PIPE.STAT register contains some interrupt status bits per pipe, and
> if assert cause the corresponding bit in the IIR to be asserted (thus
> raising an interrupt). When handling an interrupt, we should clear the
> PIPE.STAT generator first before clearing the IIR so that we do not miss
> events or cause spurious work.
> 
> This ordering was broken by
> 
> commit 27b6c122512ca30399bb1b39cc42eda83901f304
> Author: Oscar Mateo 
> Date:   Mon Jun 16 16:11:00 2014 +0100
> 
> drm/i915/chv: Ack interrupts before handling them (CHV)
> 
> commit 3ff60f89bc4836583f5bd195062f16c563bd97aa
> Author: Oscar Mateo 
> Date:   Mon Jun 16 16:10:58 2014 +0100
> 
> drm/i915/vlv: Ack interrupts before handling them (VLV)
> 
> in attempting to reduce the amount of work done between receiving an
> interrupt and acknowledging it. In light of this motivation, split the
> pipestat interrupt handler into two, one to acknowledge and clear the
> interrupt and a later pass to process it.
> 
> Signed-off-by: Chris Wilson 
> Cc: Oscar Mateo 
> Cc: Bob Beckett 
> Cc: Imre Deak 
> Cc: Daniel Vetter 

Oscar/Imre, where's your review on this?

Thanks, Daniel
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 55 
> +++--
>  1 file changed, 31 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 66064511cffb..92bdfe6f91d8 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1457,24 +1457,21 @@ static void gen6_rps_irq_handler(struct 
> drm_i915_private *dev_priv, u32 pm_iir)
>   }
>  }
>  
> -static bool intel_pipe_handle_vblank(struct drm_device *dev, enum pipe pipe)
> +static inline bool
> +intel_pipe_handle_vblank(struct drm_device *dev, enum pipe pipe)
>  {
> - if (!drm_handle_vblank(dev, pipe))
> - return false;
> -
> - return true;
> + return drm_handle_vblank(dev, pipe);
>  }
>  
> -static void valleyview_pipestat_irq_handler(struct drm_device *dev, u32 iir)
> +static void valleyview_pipestat_irq_get(struct drm_i915_private *dev_priv,
> + u32 iir, u32 *pipe_stats)
>  {
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - u32 pipe_stats[I915_MAX_PIPES] = { };
>   int pipe;
>  
>   spin_lock(&dev_priv->irq_lock);
>   for_each_pipe(dev_priv, pipe) {
> + u32 mask, val, iir_bit = 0;
>   int reg;
> - u32 mask, iir_bit = 0;
>  
>   /*
>* PIPESTAT bits get signalled even when the interrupt is
> @@ -1486,6 +1483,7 @@ static void valleyview_pipestat_irq_handler(struct 
> drm_device *dev, u32 iir)
>  
>   /* fifo underruns are filterered in the underrun handler. */
>   mask = PIPE_FIFO_UNDERRUN_STATUS;
> + mask |= PIPESTAT_INT_ENABLE_MASK;
>  
>   switch (pipe) {
>   case PIPE_A:
> @@ -1501,21 +1499,25 @@ static void valleyview_pipestat_irq_handler(struct 
> drm_device *dev, u32 iir)
>   if (iir & iir_bit)
>   mask |= dev_priv->pipestat_irq_mask[pipe];
>  
> - if (!mask)
> - continue;
> -
>   reg = PIPESTAT(pipe);
> - mask |= PIPESTAT_INT_ENABLE_MASK;
> - pipe_stats[pipe] = I915_READ(reg) & mask;
> + val = I915_READ(reg);
> + pipe_stats[pipe] |= val & mask;
>  
>   /*
>* Clear the PIPE*STAT regs before the IIR
>*/
> - if (pipe_stats[pipe] & (PIPE_FIFO_UNDERRUN_STATUS |
> - PIPESTAT_INT_STATUS_MASK))
> - I915_WRITE(reg, pipe_stats[pipe]);
> + if (val & (PIPE_FIFO_UNDERRUN_STATUS |
> +PIPESTAT_INT_STATUS_MASK))
> + I915_WRITE(reg, val);
>   }
>   spin_unlock(&dev_priv->irq_lock);
> +}
> +
> +static void valleyview_pipestat_irq_handler(struct drm_i915_private 
> *dev_priv,
> + u32 *pipe_stats)
> +{
> + struct drm_device *dev = dev_priv->dev;
> + int pipe;
>  
>   for_each_pipe(dev_priv, pipe) {
>   if (pipe_stats[pipe] & PIPE_START_VBLANK_INTERRUPT_STATUS &&
> @@ -1578,6 +1580,7 @@ static irqreturn_t valleyview_irq_handler(int irq, void 
> *arg)
>  {
>   struct drm_device *dev = arg;
>   struct drm_i915_private *dev_priv = dev->dev_private;
> + u32 pipe_stats[I915_MAX_PIPES] = {};
>   u32 iir, gt_iir, pm_iir;
>   irqreturn_t ret = IRQ_NONE;
>  
> @@ -1600,6 +1603,7 @@ static irqreturn_t valleyview_irq_handler(int irq, void 
> *arg)
>   /* Consume port before clearing IIR or we'll miss 
> events */
>   if (iir & I915_DISPLAY_PORT_INTERRUPT)
>   i9xx_hpd_irq_handler(dev);
> +  

Re: [Intel-gfx] [PATCH] drm/i915: fix driver's versions of WARN_ON & WARN_ON_ONCE

[shuang . he]

Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
Task id: 7223
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
ILK -2  302/302  300/302
SNB  315/315  315/315
IVB  336/336  336/336
BYT -2  283/283  281/283
HSW  378/378  378/378
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
*ILK  igt@kms_flip@flip-vs-dpms-interruptible  PASS(1)  DMESG_WARN(1)
*ILK  igt@kms_flip@wf_vblank-vs-modeset-interruptible  PASS(1)  
DMESG_WARN(1)
*BYT  igt@gem_partial_pwrite_pread@reads-uncached  PASS(1)  FAIL(1)
*BYT  igt@gem_tiled_partial_pwrite_pread@reads  PASS(1)  FAIL(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 07/16] drm/i915: disable FBC on FIFO underruns

[Daniel Vetter]

On Thu, Aug 20, 2015 at 06:00:02PM +0300, Ville Syrjälä wrote:
> On Thu, Aug 20, 2015 at 11:29:29AM -0300, Paulo Zanoni wrote:
> > 2015-08-20 10:58 GMT-03:00 Ville Syrjälä :
> > > Once it's otherwise known to be solid,
> > > then it might make sense, although a much cooler thing would be if we
> > > could actually detect when the display has failed entirely and recover
> > > it somehow.
> > >
> > > Oh and to make the protection mechanism actually kick in reliably you
> > > would somehow need to address the problems with the underrun interrupts.
> > 
> > Which problems?
> 
> The fact that we disable them as soon as one occurs, and even worse the
> error interrupt is a shared one on many platforms, so one underrun any
> pipe or some other unrelated error kills underrun detection everywhere.

E.g. on hsw with vga + hdmi/dp (which now happens easily since igt creates
a fake vga output, just run kms_pipe_crc_basic) underruns happen reliably
on modeset and then don't work anywhere. We also seem to fail to restore
them somehow :(
-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

Re: [Intel-gfx] [PATCH] drm/i915: Fix build warning on 32-bit

[Daniel Vetter]

On Wed, Aug 26, 2015 at 10:26:35AM +0300, Jani Nikula wrote:
> On Wed, 26 Aug 2015, Daniel Vetter  wrote:
> > On Mon, Aug 17, 2015 at 05:19:09PM +, Zanoni, Paulo R wrote:
> >> Em Sex, 2015-08-14 às 12:35 +0200, Thierry Reding escreveu:
> >> > From: Thierry Reding 
> >> > 
> >> > The gtt.stolen_size field is of type size_t, and so should be printed
> >> > using %zu to avoid build warnings on either 32-bit and 64-bit builds.
> >> 
> >> While the suggestion from Chris sounds good, this patch alone is
> >> already a fix, so:
> >> Reviewed-by: Paulo Zanoni 
> >
> > Queued for -next, thanks for the patch.
> 
> Great. Also pushed to drm-intel-next-fixes.

Oops, dropped again from dinq ;-)
-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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: restrict unclaimed register checking

[Chris Wilson]

On Tue, Aug 25, 2015 at 07:03:42PM -0300, Paulo Zanoni wrote:
> The unclaimed register bit is only triggered when someone touches the
> specified register range.
> 
> For the normal use case (with i915.mmio_debug=0), this commit will
> avoid the extra __raw_i915_read32() call for every register outside
> the specified range, at the expense of a few additional "if"
> statements.
> 
> Cc: Chris Wilson 
> Signed-off-by: Paulo Zanoni 


> @@ -612,7 +614,7 @@ hsw_unclaimed_reg_debug(struct drm_i915_private 
> *dev_priv, u32 reg, bool read,
>   const char *op = read ? "reading" : "writing to";
>   const char *when = before ? "before" : "after";
>  
> - if (!i915.mmio_debug)
> + if (!i915.mmio_debug || !UNCLAIMED_CHECK_RANGE(reg))
>   return;

Place the register check on the preceding line so that it is not
confused with checking the debug-enabled status. (Also you can argue
that reg will be register/cache-hot and so a cheaper test to do first
than loading a module parameter.)

>   if (__raw_i915_read32(dev_priv, FPGA_DBG) & FPGA_DBG_RM_NOCLAIM) {
> @@ -624,11 +626,11 @@ hsw_unclaimed_reg_debug(struct drm_i915_private 
> *dev_priv, u32 reg, bool read,
>  }
>  
>  static void
> -hsw_unclaimed_reg_detect(struct drm_i915_private *dev_priv)
> +hsw_unclaimed_reg_detect(struct drm_i915_private *dev_priv, u32 reg)
>  {
>   static bool mmio_debug_once = true;
>  
> - if (i915.mmio_debug || !mmio_debug_once)
> + if (i915.mmio_debug || !UNCLAIMED_CHECK_RANGE(reg) || !mmio_debug_once)
>   return;

The use is wrong here though because you never reviewed my patch to
enable the single-shot debugging from the interrupt handler to catch
invalid usage from elsewhere.
-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 13/16] drm/i915: don't use the first stolen page on Broadwell

[Daniel Vetter]

On Wed, Aug 19, 2015 at 02:55:34PM +0300, Ville Syrjälä wrote:
> On Sat, Aug 15, 2015 at 09:30:18AM +0100, Chris Wilson wrote:
> > On Fri, Aug 14, 2015 at 06:34:18PM -0300, Paulo Zanoni wrote:
> > > The spec says we just can't use it.
> > 
> > But what about when we inherit a framebuffer at that address?
> 
> Indeed. I asked the same question several times during the past attempts
> at this, and even tried to outline a potential solution at least once [1]

Paulo's only patching the insert_node_in_range allocator, for fbcon
takeover we use reserve_node. I think this patch seems to do what you want
it to do, no need for fancier schemes.
-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

Re: [Intel-gfx] drm/i915: Fix module initialisation.

[Daniel Vetter]

On Mon, Aug 17, 2015 at 12:00:38PM +0200, Maarten Lankhorst wrote:
> Set DRIVER_MODESET and DRIVER_ATOMIC by default. The driver is fully atomic.
> Remove the legacy suspend/resume, to fix a warning introduced by:
> 
> "drm: WARN_ON if a modeset driver uses legacy suspend/resume helpers"
> 
> and removing the .get_vblank_timestamp reset to NULL. It's a noop without UMS.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 1d887459e37f..411ba8ccecca 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1646,7 +1646,7 @@ static struct drm_driver driver = {
>*/
>   .driver_features =
>   DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM | DRIVER_PRIME |
> - DRIVER_RENDER,
> + DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC,

Nah, DRIVER_ATOMIC isn't quite there yet ...

>   .load = i915_driver_load,
>   .unload = i915_driver_unload,
>   .open = i915_driver_open,
> @@ -1655,10 +1655,6 @@ static struct drm_driver driver = {
>   .postclose = i915_driver_postclose,
>   .set_busid = drm_pci_set_busid,
>  
> - /* Used in place of i915_pm_ops for non-DRIVER_MODESET */
> - .suspend = i915_suspend_legacy,
> - .resume = i915_resume_legacy,

Can't we nuke the functions themselves now too?
-Daniel

> -
>  #if defined(CONFIG_DEBUG_FS)
>   .debugfs_init = i915_debugfs_init,
>   .debugfs_cleanup = i915_debugfs_cleanup,
> @@ -1701,7 +1697,6 @@ static int __init i915_init(void)
>* either the i915.modeset prarameter or by the
>* vga_text_mode_force boot option.
>*/
> - driver.driver_features |= DRIVER_MODESET;
>  
>   if (i915.modeset == 0)
>   driver.driver_features &= ~DRIVER_MODESET;
> @@ -1712,20 +1707,11 @@ static int __init i915_init(void)
>  #endif
>  
>   if (!(driver.driver_features & DRIVER_MODESET)) {
> - driver.get_vblank_timestamp = NULL;
>   /* Silently fail loading to not upset userspace. */
>   DRM_DEBUG_DRIVER("KMS and UMS disabled.\n");
>   return 0;
>   }
>  
> - /*
> -  * FIXME: Note that we're lying to the DRM core here so that we can get 
> access
> -  * to the atomic ioctl and the atomic properties.  Only plane 
> operations on
> -  * a single CRTC will actually work.
> -  */
> - if (driver.driver_features & DRIVER_MODESET)
> - driver.driver_features |= DRIVER_ATOMIC;
> -
>   return drm_pci_init(&driver, &i915_pci_driver);
>  }
>  
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH v3 2/4] drm/i915: implement sync_audio_rate callback

[Daniel Vetter]

On Mon, Aug 17, 2015 at 03:20:38PM +0300, Jani Nikula wrote:
> On Mon, 17 Aug 2015, libin.y...@intel.com wrote:
> > From: Libin Yang 
> >
> > HDMI audio may not work at some frequencies
> > with the HW provided N/CTS.
> >
> > This patch sets the proper N value for the
> > given audio sample rate at the impacted frequencies.
> > At other frequencies, it will use the N/CTS value
> > which HW provides.
> >
> > Signed-off-by: Libin Yang 
> > ---
> >  drivers/gpu/drm/i915/intel_audio.c | 117 
> > +
> >  1 file changed, 117 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index dc32cf4..27add6a 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -68,6 +68,31 @@ static const struct {
> > { 148500, AUD_CONFIG_PIXEL_CLOCK_HDMI_148500 },
> >  };
> >  
> > +/* HDMI N/CTS table */
> > +#define TMDS_297M 297000
> > +#define TMDS_296M DIV_ROUND_UP(297000 * 1000, 1001)
> > +static const struct {
> > +   int sample_rate;
> > +   int clock;
> > +   int n;
> > +   int cts;
> > +} aud_ncts[] = {
> > +   { 44100, TMDS_296M, 4459, 234375 },
> > +   { 44100, TMDS_297M, 4704, 247500 },
> > +   { 48000, TMDS_296M, 5824, 281250 },
> > +   { 48000, TMDS_297M, 5120, 247500 },
> > +   { 32000, TMDS_296M, 5824, 421875 },
> > +   { 32000, TMDS_297M, 3072, 222750 },
> > +   { 88200, TMDS_296M, 8918, 234375 },
> > +   { 88200, TMDS_297M, 9408, 247500 },
> > +   { 96000, TMDS_296M, 11648, 281250 },
> > +   { 96000, TMDS_297M, 10240, 247500 },
> > +   { 176400, TMDS_296M, 17836, 234375 },
> > +   { 176400, TMDS_297M, 18816, 247500 },
> > +   { 44100, TMDS_296M, 23296, 281250 },
> > +   { 44100, TMDS_297M, 20480, 247500 },
> > +};
> > +
> >  /* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */
> >  static u32 audio_config_hdmi_pixel_clock(struct drm_display_mode *mode)
> >  {
> > @@ -90,6 +115,31 @@ static u32 audio_config_hdmi_pixel_clock(struct 
> > drm_display_mode *mode)
> > return hdmi_audio_clock[i].config;
> >  }
> >  
> > +static int audio_config_get_n(struct drm_display_mode *mode, int rate)
> > +{
> > +   int i;
> > +
> > +   for (i = 0; i < ARRAY_SIZE(aud_ncts); i++) {
> > +   if ((rate == aud_ncts[i].sample_rate) &&
> > +   (mode->clock == aud_ncts[i].clock)) {
> > +   return aud_ncts[i].n;
> > +   }
> > +   }
> > +   return 0;
> > +}
> > +
> > +/* check whether N/CTS/M need be set manually */
> > +static bool audio_rate_need_prog(struct intel_crtc *crtc,
> > +   struct drm_display_mode *mode)
> > +{
> > +   if (((mode->clock == TMDS_297M) ||
> > +(mode->clock == TMDS_296M)) &&
> > +   intel_pipe_has_type(crtc, INTEL_OUTPUT_HDMI))
> > +   return true;
> > +   else
> > +   return false;
> > +}
> > +
> >  static bool intel_eld_uptodate(struct drm_connector *connector,
> >int reg_eldv, uint32_t bits_eldv,
> >int reg_elda, uint32_t bits_elda,
> > @@ -514,12 +564,79 @@ static int i915_audio_component_get_cdclk_freq(struct 
> > device *dev)
> > return ret;
> >  }
> >  
> > +static int i915_audio_component_sync_audio_rate(struct device *dev,
> > +   int port, int rate)
> > +{
> > +   struct drm_i915_private *dev_priv = dev_to_i915(dev);
> > +   struct drm_device *drm_dev = dev_priv->dev;
> > +   struct intel_encoder *intel_encoder;
> > +   struct intel_digital_port *intel_dig_port;
> > +   struct intel_crtc *crtc;
> > +   struct drm_display_mode *mode;
> > +   enum pipe pipe = -1;
> > +   u32 tmp;
> > +   int n_low, n_up, n;
> > +
> > +   /* 1. get the pipe */
> > +   for_each_intel_encoder(drm_dev, intel_encoder) {
> > +   intel_dig_port = enc_to_dig_port(&intel_encoder->base);
> 
> Mmmh, not all encoders are digital ports. enc_to_dig_port does a
> container_of, so you can't just check for NULL either. IOW, you need to
> check the encoder->type (and you only care about HDMI here).

encoder->type is changed at runtime thanks to ddi encoders. Also shouldn't
we care about dp audio too or am I confused?
-Daniel

> 
> > +   if (port == intel_dig_port->port) {
> > +   crtc = to_intel_crtc(intel_encoder->base.crtc);
> > +   if (!crtc) {
> > +   DRM_DEBUG_KMS("%s: crtc is NULL\n", __func__);
> > +   continue;
> > +   }
> > +   pipe = crtc->pipe;
> > +   break;
> > +   }
> > +   }
> > +
> > +   if (pipe == INVALID_PIPE) {
> > +   DRM_DEBUG_KMS("no pipe for the port %c\n", port_name(port));
> > +   return -ENODEV;
> > +   }
> > +   DRM_DEBUG_KMS("pipe %c connects port %c\n",
> > + pipe_name(pipe), port_name(port));
> > +   mode = &crtc->config->base.adjusted_mode;
> > +
> > +   

[Intel-gfx] [PATCH] drm/i915: Reduce frequency of unspecific HSW reg debugging

[Chris Wilson]

Delay the expensive read on the FPGA_DBG register from once per mmio to
once per forcewake section when we are doing the general wellbeing
check rather than the targetted error detection. This almost reduces
the overhead of the debug facility (for example when submitting execlists)
to zero whilst keeping the debug checks around.

v2: Enable one-shot mmio debugging from the interrupt check as well as a
safeguard to catch invalid display writes from outside the powerwell.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Mika Kuoppala 
Cc: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_uncore.c | 56 -
 1 file changed, 30 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 9d3c2e420d2b..05c50cc87d1d 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -149,6 +149,30 @@ fw_domains_put(struct drm_i915_private *dev_priv, enum 
forcewake_domains fw_doma
 }
 
 static void
+hsw_unclaimed_reg_detect(struct drm_i915_private *dev_priv)
+{
+   static bool mmio_debug_once = true;
+
+   if (i915.mmio_debug || !mmio_debug_once)
+   return;
+
+   if (__raw_i915_read32(dev_priv, FPGA_DBG) & FPGA_DBG_RM_NOCLAIM) {
+   DRM_DEBUG("Unclaimed register detected, "
+ "enabling oneshot unclaimed register reporting. "
+ "Please use i915.mmio_debug=N for more 
information.\n");
+   __raw_i915_write32(dev_priv, FPGA_DBG, FPGA_DBG_RM_NOCLAIM);
+   i915.mmio_debug = mmio_debug_once--;
+   }
+}
+
+static void
+fw_domains_put_debug(struct drm_i915_private *dev_priv, enum forcewake_domains 
fw_domains)
+{
+   hsw_unclaimed_reg_detect(dev_priv);
+   fw_domains_put(dev_priv, fw_domains);
+}
+
+static void
 fw_domains_posting_read(struct drm_i915_private *dev_priv)
 {
struct intel_uncore_forcewake_domain *d;
@@ -623,23 +647,6 @@ hsw_unclaimed_reg_debug(struct drm_i915_private *dev_priv, 
u32 reg, bool read,
}
 }
 
-static void
-hsw_unclaimed_reg_detect(struct drm_i915_private *dev_priv)
-{
-   static bool mmio_debug_once = true;
-
-   if (i915.mmio_debug || !mmio_debug_once)
-   return;
-
-   if (__raw_i915_read32(dev_priv, FPGA_DBG) & FPGA_DBG_RM_NOCLAIM) {
-   DRM_DEBUG("Unclaimed register detected, "
- "enabling oneshot unclaimed register reporting. "
- "Please use i915.mmio_debug=N for more 
information.\n");
-   __raw_i915_write32(dev_priv, FPGA_DBG, FPGA_DBG_RM_NOCLAIM);
-   i915.mmio_debug = mmio_debug_once--;
-   }
-}
-
 #define GEN2_READ_HEADER(x) \
u##x val = 0; \
assert_device_not_suspended(dev_priv);
@@ -891,7 +898,6 @@ hsw_write##x(struct drm_i915_private *dev_priv, off_t reg, 
u##x val, bool trace)
gen6_gt_check_fifodbg(dev_priv); \
} \
hsw_unclaimed_reg_debug(dev_priv, reg, false, false); \
-   hsw_unclaimed_reg_detect(dev_priv); \
GEN6_WRITE_FOOTER; \
 }
 
@@ -933,7 +939,6 @@ gen8_write##x(struct drm_i915_private *dev_priv, off_t reg, 
u##x val, bool trace
__force_wake_get(dev_priv, FORCEWAKE_RENDER); \
__raw_i915_write##x(dev_priv, reg, val); \
hsw_unclaimed_reg_debug(dev_priv, reg, false, false); \
-   hsw_unclaimed_reg_detect(dev_priv); \
GEN6_WRITE_FOOTER; \
 }
 
@@ -1182,6 +1187,10 @@ static void intel_uncore_fw_domains_init(struct 
drm_device *dev)
   FORCEWAKE, FORCEWAKE_ACK);
}
 
+   if (HAS_FPGA_DBG_UNCLAIMED(dev) &&
+   dev_priv->uncore.funcs.force_wake_put == fw_domains_put)
+   dev_priv->uncore.funcs.force_wake_put = fw_domains_put_debug;
+
/* All future platforms are expected to require complex power gating */
WARN_ON(dev_priv->uncore.fw_domains == 0);
 }
@@ -1545,11 +1554,6 @@ bool intel_has_gpu_reset(struct drm_device *dev)
 
 void intel_uncore_check_errors(struct drm_device *dev)
 {
-   struct drm_i915_private *dev_priv = dev->dev_private;
-
-   if (HAS_FPGA_DBG_UNCLAIMED(dev) &&
-   (__raw_i915_read32(dev_priv, FPGA_DBG) & FPGA_DBG_RM_NOCLAIM)) {
-   DRM_ERROR("Unclaimed register before interrupt\n");
-   __raw_i915_write32(dev_priv, FPGA_DBG, FPGA_DBG_RM_NOCLAIM);
-   }
+   if (HAS_FPGA_DBG_UNCLAIMED(dev))
+   hsw_unclaimed_reg_detect(to_i915(dev));
 }
-- 
2.5.0

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

[Intel-gfx] [PATCH 1/2] drm/i915: move intel_hrawclk() to intel_display.c

[Jani Nikula]

Make it available outside of intel_dp.c.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_display.c | 33 +
 drivers/gpu/drm/i915/intel_dp.c  | 34 --
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 3 files changed, 34 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index cba6299b3450..f25a847bcbc5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -135,6 +135,39 @@ intel_pch_rawclk(struct drm_device *dev)
return I915_READ(PCH_RAWCLK_FREQ) & RAWCLK_FREQ_MASK;
 }
 
+/* hrawclock is 1/4 the FSB frequency */
+int intel_hrawclk(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   uint32_t clkcfg;
+
+   /* There is no CLKCFG reg in Valleyview. VLV hrawclk is 200 MHz */
+   if (IS_VALLEYVIEW(dev))
+   return 200;
+
+   clkcfg = I915_READ(CLKCFG);
+   switch (clkcfg & CLKCFG_FSB_MASK) {
+   case CLKCFG_FSB_400:
+   return 100;
+   case CLKCFG_FSB_533:
+   return 133;
+   case CLKCFG_FSB_667:
+   return 166;
+   case CLKCFG_FSB_800:
+   return 200;
+   case CLKCFG_FSB_1067:
+   return 266;
+   case CLKCFG_FSB_1333:
+   return 333;
+   /* these two are just a guess; one of them might be right */
+   case CLKCFG_FSB_1600:
+   case CLKCFG_FSB_1600_ALT:
+   return 400;
+   default:
+   return 133;
+   }
+}
+
 static inline u32 /* units of 100MHz */
 intel_fdi_link_freq(struct drm_device *dev)
 {
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 67f0e291232f..0800d87e876c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -253,40 +253,6 @@ static void intel_dp_unpack_aux(uint32_t src, uint8_t 
*dst, int dst_bytes)
dst[i] = src >> ((3-i) * 8);
 }
 
-/* hrawclock is 1/4 the FSB frequency */
-static int
-intel_hrawclk(struct drm_device *dev)
-{
-   struct drm_i915_private *dev_priv = dev->dev_private;
-   uint32_t clkcfg;
-
-   /* There is no CLKCFG reg in Valleyview. VLV hrawclk is 200 MHz */
-   if (IS_VALLEYVIEW(dev))
-   return 200;
-
-   clkcfg = I915_READ(CLKCFG);
-   switch (clkcfg & CLKCFG_FSB_MASK) {
-   case CLKCFG_FSB_400:
-   return 100;
-   case CLKCFG_FSB_533:
-   return 133;
-   case CLKCFG_FSB_667:
-   return 166;
-   case CLKCFG_FSB_800:
-   return 200;
-   case CLKCFG_FSB_1067:
-   return 266;
-   case CLKCFG_FSB_1333:
-   return 333;
-   /* these two are just a guess; one of them might be right */
-   case CLKCFG_FSB_1600:
-   case CLKCFG_FSB_1600_ALT:
-   return 400;
-   default:
-   return 133;
-   }
-}
-
 static void
 intel_dp_init_panel_power_sequencer(struct drm_device *dev,
struct intel_dp *intel_dp);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 81b7d77a3c8b..ca475f2a5f7c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -993,6 +993,7 @@ void i915_audio_component_cleanup(struct drm_i915_private 
*dev_priv);
 extern const struct drm_plane_funcs intel_plane_funcs;
 bool intel_has_pending_fb_unpin(struct drm_device *dev);
 int intel_pch_rawclk(struct drm_device *dev);
+int intel_hrawclk(struct drm_device *dev);
 void intel_mark_busy(struct drm_device *dev);
 void intel_mark_idle(struct drm_device *dev);
 void intel_crtc_restore_mode(struct drm_crtc *crtc);
-- 
2.1.4

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

[Intel-gfx] [PATCH 2/2] drm/i915: initialize backlight max from VBT

[Jani Nikula]

Normally we determine the backlight PWM modulation frequency (which we
also use as backlight max value) from the backlight registers at module
load time, expecting the registers have been initialized by the BIOS. If
this is not the case, we fail.

The VBT contains the backlight modulation frequency in Hz. Add platform
specific functions to convert the frequency in Hz to backlight PWM
modulation frequency, and use them to initialize the backlight when the
registers are not initialized by the BIOS.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.h|   2 +
 drivers/gpu/drm/i915/i915_reg.h|   1 +
 drivers/gpu/drm/i915/intel_panel.c | 160 +++--
 3 files changed, 156 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5f6fd0b71bc9..e9def31618b5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -665,6 +665,8 @@ struct drm_i915_display_funcs {
  uint32_t level);
void (*disable_backlight)(struct intel_connector *connector);
void (*enable_backlight)(struct intel_connector *connector);
+   uint32_t (*backlight_hz_to_pwm)(struct intel_connector *connector,
+   uint32_t hz);
 };
 
 enum forcewake_domain_id {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 71f7ba886fb1..5f07af41a600 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6316,6 +6316,7 @@ enum skl_disp_power_wells {
 #define SOUTH_CHICKEN2 0xc2004
 #define  FDI_MPHY_IOSFSB_RESET_STATUS  (1<<13)
 #define  FDI_MPHY_IOSFSB_RESET_CTL (1<<12)
+#define  PWM_GRANULARITY   (1<<5)  /* LPT */
 #define  DPLS_EDP_PPS_FIX_DIS  (1<<0)
 
 #define _FDI_RXA_CHICKEN 0xc200c
diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index e2ab3f6ed022..edf523ff4610 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -1212,10 +1212,125 @@ static void intel_backlight_device_unregister(struct 
intel_connector *connector)
 #endif /* CONFIG_BACKLIGHT_CLASS_DEVICE */
 
 /*
- * Note: The setup hooks can't assume pipe is set!
+ * HSW/BDW: This value represents the period of the PWM stream in clock periods
+ * multiplied by 128 (default increment) or 16 (alternate increment, selected 
in
+ * LPT SOUTH_CHICKEN2 register bit 5).
  *
- * XXX: Query mode clock or hardware clock and program PWM modulation frequency
- * appropriately when it's 0. Use VBT and/or sane defaults.
+ * XXX: This only works when driving the PCH PWM. When driving the CPU PWM on
+ * the utility pin, the granularity needs to be determined by BLC_PWM_CTL bit
+ * 27.
+ */
+static u32 hsw_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz)
+{
+   struct drm_device *dev = connector->base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   u32 mul, clock;
+
+   if (I915_READ(SOUTH_CHICKEN2) & PWM_GRANULARITY)
+   mul = 16;
+   else
+   mul = 128;
+
+   if (dev_priv->pch_id == INTEL_PCH_LPT_DEVICE_ID_TYPE)
+   clock = MHz(135); /* LPT:H */
+   else
+   clock = MHz(24); /* LPT:LP */
+
+   return clock / (pwm_freq_hz * mul);
+}
+
+/*
+ * ILK/SNB/IVB: This value represents the period of the PWM stream in PCH
+ * display raw clocks multiplied by 128.
+ */
+static u32 pch_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz)
+{
+   struct drm_device *dev = connector->base.dev;
+   int clock = MHz(intel_pch_rawclk(dev));
+
+   return clock / (pwm_freq_hz * 128);
+}
+
+/*
+ * Gen2: This field determines the number of time base events (display core
+ * clock frequency/32) in total for a complete cycle of modulated backlight
+ * control.
+ *
+ * Gen3: A time base event equals the display core clock ([DevPNV] HRAW clock)
+ * divided by 32.
+ */
+static u32 i9xx_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz)
+{
+   struct drm_device *dev = connector->base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   int clock;
+
+   if (IS_PINEVIEW(dev))
+   clock = intel_hrawclk(dev);
+   else
+   clock = 1000 * dev_priv->display.get_display_clock_speed(dev);
+
+   return clock / (pwm_freq_hz * 32);
+}
+
+/*
+ * Gen4: This value represents the period of the PWM stream in display core
+ * clocks multiplied by 128.
+ */
+static u32 i965_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz)
+{
+   struct drm_device *dev = connector->base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   int clock = 1000 * dev_priv->display.get_display_clock_speed(dev);
+
+   return clock / (pwm_freq_hz * 128);
+}
+
+/*
+ * VLV: This value represents the period of the PWM stream in display core
+ * clocks ([DevCTG

[Intel-gfx] [PATCH 0/2] drm/i915: initialize backlight pwm from vbt if needed

[Jani Nikula]

This is a rebase of [1] and originally [2]. I haven't tried this in a
year and I have no idea if it works on SKL, and it's not implemented for
BXT. However there's renewed interest, so here's the rebase.

BR,
Jani.

[1] http://mid.gmane.org/cover.1431003197.git.jani.nik...@intel.com
[2] http://mid.gmane.org/cover.1389109881.git.jani.nik...@intel.com

Jani Nikula (2):
  drm/i915: move intel_hrawclk() to intel_display.c
  drm/i915: initialize backlight max from VBT

 drivers/gpu/drm/i915/i915_drv.h  |   2 +
 drivers/gpu/drm/i915/i915_reg.h  |   1 +
 drivers/gpu/drm/i915/intel_display.c |  33 
 drivers/gpu/drm/i915/intel_dp.c  |  34 
 drivers/gpu/drm/i915/intel_drv.h |   1 +
 drivers/gpu/drm/i915/intel_panel.c   | 160 +--
 6 files changed, 190 insertions(+), 41 deletions(-)

-- 
2.1.4

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

Re: [Intel-gfx] drm/i915: Fix module initialisation.

[Maarten Lankhorst]

Op 26-08-15 om 09:51 schreef Daniel Vetter:
> On Mon, Aug 17, 2015 at 12:00:38PM +0200, Maarten Lankhorst wrote:
>> Set DRIVER_MODESET and DRIVER_ATOMIC by default. The driver is fully atomic.
>> Remove the legacy suspend/resume, to fix a warning introduced by:
>>
>> "drm: WARN_ON if a modeset driver uses legacy suspend/resume helpers"
>>
>> and removing the .get_vblank_timestamp reset to NULL. It's a noop without 
>> UMS.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c 
>> b/drivers/gpu/drm/i915/i915_drv.c
>> index 1d887459e37f..411ba8ccecca 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.c
>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>> @@ -1646,7 +1646,7 @@ static struct drm_driver driver = {
>>   */
>>  .driver_features =
>>  DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM | DRIVER_PRIME |
>> -DRIVER_RENDER,
>> +DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC,
> Nah, DRIVER_ATOMIC isn't quite there yet ...
Indeed..
>>  .load = i915_driver_load,
>>  .unload = i915_driver_unload,
>>  .open = i915_driver_open,
>> @@ -1655,10 +1655,6 @@ static struct drm_driver driver = {
>>  .postclose = i915_driver_postclose,
>>  .set_busid = drm_pci_set_busid,
>>  
>> -/* Used in place of i915_pm_ops for non-DRIVER_MODESET */
>> -.suspend = i915_suspend_legacy,
>> -.resume = i915_resume_legacy,
> Can't we nuke the functions themselves now too?
>
vga switcheroo uses them.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Put back lane_count into intel_dp and add link_rate too

[Daniel Vetter]

On Tue, Aug 18, 2015 at 01:56:08PM +0200, Maarten Lankhorst wrote:
> Hey,
> 
> Op 17-08-15 om 17:05 schreef ville.syrj...@linux.intel.com:
> > From: Ville Syrjälä 
> >
> > With MST there won't be a crtc assigned to the main link encoder, so
> > trying to dig up the pipe_config from there is a recipe for an oops.
> >
> > Instead store the parameters (lane_count and link_rate) in the encoder,
> > and use those values during link training etc. Since those parameters
> > are now assigned only when the link is actually enabled,
> > .compute_config() won't clobber them as it did before.
> >
> > Hardware state readout is still bonkers though as we don't transfer the
> > link parameters from pipe_config intel_dp. We should do that during
> > encoder sanitation. But since we don't even do a proper job of reading
> > out the main link encoder state for MST there's littel point in
> > worrying about this now.
> >
> > Fixes a regression with MST caused by:
> >  commit 90a6b7b052b1aa17fbb98b049e9c8b7f729c35a7
> >  Author: Ville Syrjälä 
> >  Date:   Mon Jul 6 16:39:15 2015 +0300
> >
> > drm/i915: Move intel_dp->lane_count into pipe_config
> >
> > v2: Different apporoach that should keep intel_dp_check_mst_status()
> > somewhat less oopsy
> >
> > Cc: Maarten Lankhorst 
> > Reported-by: Maarten Lankhorst 
> > Signed-off-by: Ville Syrjälä 
> > ---
> Tested-by: Maarten Lankhorst 
> 
> Thanks, that seems to make MST work as expected again.

Queued for -next, thanks for the patch.
-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

Re: [Intel-gfx] [PATCH] Fix list empty check in i915_gem_evict_everything

[Zhiyuan Lv]

Hi Chris,

Thanks for the reply! Do you mean we could completely delete
i915_gem_evict_everything() and rely on others to do gem_retire_requests()?
Sorry that I am still learning the code :-)

Regards,
-Zhiyuan

On Wed, Aug 26, 2015 at 08:28:43AM +0100, Chris Wilson wrote:
> On Wed, Aug 26, 2015 at 03:01:26PM +0800, Zhiyuan Lv wrote:
> > That seems to be a typo. The original code will override the previous
> > list empty check value in the loop. As the result, only the last vm in
> > vm_list impacts the empty check. The problem is fixed by using local
> > bool variable inside the loop.
> 
> Or we could just delete the code entirely since it is no longer used
> (except for a mistake in shrink-all).
> -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: fix driver's versions of WARN_ON & WARN_ON_ONCE

[Daniel Vetter]

On Mon, Aug 17, 2015 at 01:45:01PM -0300, Paulo Zanoni wrote:
> 2015-08-17 13:30 GMT-03:00 Dave Gordon :
> > The current versions of these two macros don't work correctly if the
> > argument expression happens to contain a modulo operator (%) -- when
> > stringified, it gets interpreted as a printf formatting character!
> > With a specifically crafted parameter, this could probably cause a
> > kernel OOPS; consider WARN_ON(p%s) or WARN_ON(f %*pEp).
> >
> > Instead, we should use an explicit "%s" format, with the stringified
> > expression as the coresponding literal-string argument.
> 
> I suppose that was inspired by the recent IGT commit :)
> 
> Reviewed-by: Paulo Zanoni 

Queued for -next, thanks for the patch.
-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

Re: [Intel-gfx] [PATCH v3 2/4] drm/i915: implement sync_audio_rate callback

[Yang, Libin]

Hi Daniel,

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Wednesday, August 26, 2015 3:53 PM
> To: Jani Nikula
> Cc: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel-
> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch
> Subject: Re: [Intel-gfx] [PATCH v3 2/4] drm/i915: implement
> sync_audio_rate callback
> 
> On Mon, Aug 17, 2015 at 03:20:38PM +0300, Jani Nikula wrote:
> > On Mon, 17 Aug 2015, libin.y...@intel.com wrote:
> > > From: Libin Yang 
> > >
> > > HDMI audio may not work at some frequencies
> > > with the HW provided N/CTS.
> > >
> > > This patch sets the proper N value for the
> > > given audio sample rate at the impacted frequencies.
> > > At other frequencies, it will use the N/CTS value
> > > which HW provides.
> > >
> > > Signed-off-by: Libin Yang 
> > > ---
> > >  drivers/gpu/drm/i915/intel_audio.c | 117
> +
> > >  1 file changed, 117 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> b/drivers/gpu/drm/i915/intel_audio.c
> > > index dc32cf4..27add6a 100644
> > > --- a/drivers/gpu/drm/i915/intel_audio.c
> > > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > @@ -68,6 +68,31 @@ static const struct {
> > >   { 148500, AUD_CONFIG_PIXEL_CLOCK_HDMI_148500 },
> > >  };
> > >
> > > +/* HDMI N/CTS table */
> > > +#define TMDS_297M 297000
> > > +#define TMDS_296M DIV_ROUND_UP(297000 * 1000, 1001)
> > > +static const struct {
> > > + int sample_rate;
> > > + int clock;
> > > + int n;
> > > + int cts;
> > > +} aud_ncts[] = {
> > > + { 44100, TMDS_296M, 4459, 234375 },
> > > + { 44100, TMDS_297M, 4704, 247500 },
> > > + { 48000, TMDS_296M, 5824, 281250 },
> > > + { 48000, TMDS_297M, 5120, 247500 },
> > > + { 32000, TMDS_296M, 5824, 421875 },
> > > + { 32000, TMDS_297M, 3072, 222750 },
> > > + { 88200, TMDS_296M, 8918, 234375 },
> > > + { 88200, TMDS_297M, 9408, 247500 },
> > > + { 96000, TMDS_296M, 11648, 281250 },
> > > + { 96000, TMDS_297M, 10240, 247500 },
> > > + { 176400, TMDS_296M, 17836, 234375 },
> > > + { 176400, TMDS_297M, 18816, 247500 },
> > > + { 44100, TMDS_296M, 23296, 281250 },
> > > + { 44100, TMDS_297M, 20480, 247500 },
> > > +};
> > > +
> > >  /* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */
> > >  static u32 audio_config_hdmi_pixel_clock(struct
> drm_display_mode *mode)
> > >  {
> > > @@ -90,6 +115,31 @@ static u32
> audio_config_hdmi_pixel_clock(struct drm_display_mode *mode)
> > >   return hdmi_audio_clock[i].config;
> > >  }
> > >
> > > +static int audio_config_get_n(struct drm_display_mode *mode,
> int rate)
> > > +{
> > > + int i;
> > > +
> > > + for (i = 0; i < ARRAY_SIZE(aud_ncts); i++) {
> > > + if ((rate == aud_ncts[i].sample_rate) &&
> > > + (mode->clock == aud_ncts[i].clock)) {
> > > + return aud_ncts[i].n;
> > > + }
> > > + }
> > > + return 0;
> > > +}
> > > +
> > > +/* check whether N/CTS/M need be set manually */
> > > +static bool audio_rate_need_prog(struct intel_crtc *crtc,
> > > + struct drm_display_mode
> *mode)
> > > +{
> > > + if (((mode->clock == TMDS_297M) ||
> > > +  (mode->clock == TMDS_296M)) &&
> > > + intel_pipe_has_type(crtc, INTEL_OUTPUT_HDMI))
> > > + return true;
> > > + else
> > > + return false;
> > > +}
> > > +
> > >  static bool intel_eld_uptodate(struct drm_connector *connector,
> > >  int reg_eldv, uint32_t bits_eldv,
> > >  int reg_elda, uint32_t bits_elda,
> > > @@ -514,12 +564,79 @@ static int
> i915_audio_component_get_cdclk_freq(struct device *dev)
> > >   return ret;
> > >  }
> > >
> > > +static int i915_audio_component_sync_audio_rate(struct device
> *dev,
> > > + int port, int rate)
> > > +{
> > > + struct drm_i915_private *dev_priv = dev_to_i915(dev);
> > > + struct drm_device *drm_dev = dev_priv->dev;
> > > + struct intel_encoder *intel_encoder;
> > > + struct intel_digital_port *intel_dig_port;
> > > + struct intel_crtc *crtc;
> > > + struct drm_display_mode *mode;
> > > + enum pipe pipe = -1;
> > > + u32 tmp;
> > > + int n_low, n_up, n;
> > > +
> > > + /* 1. get the pipe */
> > > + for_each_intel_encoder(drm_dev, intel_encoder) {
> > > + intel_dig_port = enc_to_dig_port(&intel_encoder-
> >base);
> >
> > Mmmh, not all encoders are digital ports. enc_to_dig_port does a
> > container_of, so you can't just check for NULL either. IOW, you need
> to
> > check the encoder->type (and you only care about HDMI here).
> 
> encoder->type is changed at runtime thanks to ddi encoders. Also
> shouldn't
> we care about dp audio too or am I confused?

Do you have suggestion how to handle it as it is changed
at runtime? Need a lock or not?

For DP, because the 4K DP display is not stable, so we didn't
do the full test on DP and no patch is ready for DP currently.

Based on the very simple test on 

Re: [Intel-gfx] [PATCH 7/6] drm/i915/skl: DDI-E and DDI-A shares 4 lanes.

[Jani Nikula]

On Thu, 13 Aug 2015, "Jindal, Sonika"  wrote:
> On 8/13/2015 8:57 AM, Zhang, Xiong Y wrote:
>>> On Wed, 2015-08-12 at 02:20 +, Zhang, Xiong Y wrote:
> On Tue, 2015-08-11 at 07:05 +, Zhang, Xiong Y wrote:
>>> -Original Message-
>>> From: Vivi, Rodrigo
>>> Sent: Saturday, August 8, 2015 8:34 AM
>>> To: intel-gfx@lists.freedesktop.org
>>> Cc: Vivi, Rodrigo; Zhang, Xiong Y
>>> Subject: [PATCH 7/6] drm/i915/skl: DDI-E and DDI-A shares 4
>>> lanes.
>>>
>>> DDI-A and DDI-E shares the 4 lanes. So when DDI-E is present we
>>> need to configure lane count propperly for both.
>>>
>>> This was based on Sonika's
>>> [PATCH] drm/i915/skl: Select DDIA lane capability based upon vbt
>>>
>>> Credits-to: Sonika Jindal 
>>> Cc: Xiong Zhang 
>>> Signed-off-by: Rodrigo Vivi 
>>> ---
>>>   drivers/gpu/drm/i915/intel_ddi.c | 12 ++--
>>> drivers/gpu/drm/i915/intel_dp.c  |  8 +---
>>>   2 files changed, 15 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
>>> b/drivers/gpu/drm/i915/intel_ddi.c
>>> index 110d546..557cecf 100644
>>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>>> @@ -3178,7 +3178,15 @@ void intel_ddi_init(struct drm_device
>>> *dev, enum port port)
>>> struct intel_digital_port *intel_dig_port;
>>> struct intel_encoder *intel_encoder;
>>> struct drm_encoder *encoder;
>>> -   bool init_hdmi, init_dp;
>>> +   bool init_hdmi, init_dp, ddi_e_present;
>>> +
>>> +   /*
>>> +* On SKL we don't have a way to detect DDI-E so we
>>> rely
>>> on VBT.
>>> +*/
>>> +   ddie_present = IS_SKYLAKE(dev) &&
>>> +   (dev_priv
>>> ->vbt.ddi_port_info[PORT_E].supports_dp
>
>>> +dev_priv
>>> ->vbt.ddi_port_info[PORT_E].supports_dvi
>
>>> +dev_priv
>>> ->vbt.ddi_port_info[PORT_E].supports_hdmi);
>> [Zhang, Xiong Y]  ddie_present should be ddi_e_present
>>>
>>> init_hdmi = (dev_priv
>>> ->vbt.ddi_port_info[port].supports_dvi ||
>>>  dev_priv
>>> ->vbt.ddi_port_info[port].supports_hdmi);
>>> @@ -3210,7 +3218,7 @@ void intel_ddi_init(struct drm_device
>>> *dev, enum port port)
>>> intel_dig_port->port = port;
>>> intel_dig_port->saved_port_bits =
>>> I915_READ(DDI_BUF_CTL(port)) &
>>>
>>>   (DDI_BUF_PORT_REVERSAL |
>>> -  DDI_A_4_LANES);
>>> +  ddi_e_present ? 0 :
>>> DDI_A_4_LANES);
>> [Zhang, Xiong Y] Sonika's patch will set DDI-A to 4 lanes when
>> DDI-E doesn't exist, I think your patch will do nothing.
>
> Actually DDI_A_4_LANES is being already set unconditionally, so
> Sonika's patch has no effect.
 [Zhang, Xiong Y] No. Sonika's patch set DDI_A_4_LANES under many
 conditions.
 +  if (IS_SKYLAKE(dev) && port == PORT_A
 +  && !(val & DDI_BUF_CTL_ENABLE)
 +  && !dev_priv->vbt.ddi_e_used)
 +  I915_WRITE(DDI_BUF_CTL(port), val | DDI_A_4_LANES)
>
> saved_port_bits goes to intel_dp->DP that goes to DDI_BUF_CTL and
> also it is used to calculate the number of lanes.
>
> With this patch we stop setting DDI_A_4_LANES when ddi_e is present
> so DDI-A keeps with 2 lanes and let other 2 lanes for DDI-E
 [Zhang, Xiong Y] Yes, this patch will clear DDI_A_4_LANES when ddi_e
 is present.
 But this patch won't set DDI_A_4_LANES under following conditions
 which is purpose for Sonika patch 1. Bios fail to driver eDP and
 doesn't enable DDI_A buffer
>>>
>>> If DDI_A isn't enabled we don't need to set DDI_A_4_LANES
>> [Zhang, Xiong Y] From commit message on Sonika patch, she want to
>> set DDI_A_4_LANES on such case. Maybe she met such fail case on one high
>> resolution eDP screen. Let's Sonikia explain it.
>>>
 2. Bios clear DDI_A_4_LANES
 3. DDI_E isn't present
>>>
>>> I don't agree... This is already covered on current code. DDI_A_4_LANES is
>>> already being set when enabling DDI_A.
>>>
> As Zhang mentioned and as my commit message explains, my patch is needed 
> when bios failed to drive edp (In my case it was an intermediate 
> frequency supported panel which was set to 3.24 GHz and bios didn't have 
> support for intermediate frequencies), it will not enable DDIA in which 
> case, it will not set DDI_BUF_CTL and DDI Lane capability will remain 0 
> (which is DDIA with 2 lanes and DDIE with 2 lanes).
> So, since the native resolution of that panel was high and couldn't work 
> with 2 lanes.
> So, ideally we should not rely on bios to set the initial value and set 
> it based upon whether DDI_E is used or not.
> So, my patch has some effect :)

Rodr

Re: [Intel-gfx] drm/i915: Fix module initialisation.

[Daniel Vetter]

On Wed, Aug 26, 2015 at 09:57:45AM +0200, Maarten Lankhorst wrote:
> Op 26-08-15 om 09:51 schreef Daniel Vetter:
> > On Mon, Aug 17, 2015 at 12:00:38PM +0200, Maarten Lankhorst wrote:
> >>.load = i915_driver_load,
> >>.unload = i915_driver_unload,
> >>.open = i915_driver_open,
> >> @@ -1655,10 +1655,6 @@ static struct drm_driver driver = {
> >>.postclose = i915_driver_postclose,
> >>.set_busid = drm_pci_set_busid,
> >>  
> >> -  /* Used in place of i915_pm_ops for non-DRIVER_MODESET */
> >> -  .suspend = i915_suspend_legacy,
> >> -  .resume = i915_resume_legacy,
> > Can't we nuke the functions themselves now too?
> >
> vga switcheroo uses them.

Oh, missed that. In that case maybe rename it to _switcheroo or something?
That should probably have been done in fc49b3da0e1f2, yay for not renaming
functions when they're meaning changes ...
-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

Re: [Intel-gfx] [PATCH 01/15] drm/i915: Always program m2 fractional value on CHV

[Deepak]

On 08/17/2015 05:15 PM, Ville Syrjälä wrote:

On Mon, Aug 17, 2015 at 07:49:41AM +0530, Deepak wrote:


On 07/09/2015 02:15 AM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä 

When fractional m2 divider isn't used on CHV the fractional part
is ignore by the hardware. Despite that, program the fractional
value (0 in this case) to the hardware register just to keep
things a bit more consistent. Might at least make register dumps
a bit less confusing when there isn't some stale fractional part
hanging around.

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

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0b2ad76..3df9cb2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7393,8 +7393,7 @@ static void chv_prepare_pll(struct intel_crtc *crtc,
1 << DPIO_CHV_N_DIV_SHIFT);
   
   	/* M2 fraction division */

-   if (bestm2_frac)
-   vlv_dpio_write(dev_priv, pipe, CHV_PLL_DW2(port), bestm2_frac);
+   vlv_dpio_write(dev_priv, pipe, CHV_PLL_DW2(port), bestm2_frac);
   
   	/* M2 fraction division enable */

dpio_val = vlv_dpio_read(dev_priv, pipe, CHV_PLL_DW3(port));

Since we do not use fractional m2 driver in chv, can we remove other
bestm2_frac used in chv pll function?
like
if (bestm2_frac)
  dpio_val |= DPIO_CHV_FRAC_DIV_EN;

&
if (!bestm2_frac)
  dpio_val |= DPIO_CHV_INT_LOCK_THRESHOLD_SEL_COARSE;

Do we need this?

We do use the fractional divider, when it's not 0.


Ok thanks...
Reviewed-by: Deepak S 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 03/15] drm/i915: Add encoder->post_pll_disable() hooks and move CHV clock buffer disables there

[Deepak]

On 08/17/2015 05:23 PM, Ville Syrjälä wrote:

On Mon, Aug 17, 2015 at 09:46:01AM +0530, Deepak wrote:


On 07/09/2015 02:15 AM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä 

Move the CHV clock buffer disable from chv_disable_pll() to the new
encoder .post_pll_disable() hook. This is more symmetric since the
clock buffer enable happens from the .pre_pll_enable() hook.

We'll have more use for the new hook soon.

Signed-off-by: Ville Syrjälä 
---
   drivers/gpu/drm/i915/intel_display.c | 15 ---
   drivers/gpu/drm/i915/intel_dp.c  | 23 +++
   drivers/gpu/drm/i915/intel_drv.h |  1 +
   drivers/gpu/drm/i915/intel_hdmi.c| 23 +++
   4 files changed, 51 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3df9cb2..db518a7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1851,17 +1851,6 @@ static void chv_disable_pll(struct drm_i915_private 
*dev_priv, enum pipe pipe)
val &= ~DPIO_DCLKP_EN;
vlv_dpio_write(dev_priv, pipe, CHV_CMN_DW14(port), val);
   
-	/* disable left/right clock distribution */

-   if (pipe != PIPE_B) {
-   val = vlv_dpio_read(dev_priv, pipe, _CHV_CMN_DW5_CH0);
-   val &= ~(CHV_BUFLEFTENA1_MASK | CHV_BUFRIGHTENA1_MASK);
-   vlv_dpio_write(dev_priv, pipe, _CHV_CMN_DW5_CH0, val);
-   } else {
-   val = vlv_dpio_read(dev_priv, pipe, _CHV_CMN_DW1_CH1);
-   val &= ~(CHV_BUFLEFTENA2_MASK | CHV_BUFRIGHTENA2_MASK);
-   vlv_dpio_write(dev_priv, pipe, _CHV_CMN_DW1_CH1, val);
-   }
-
mutex_unlock(&dev_priv->sb_lock);
   }
   
@@ -6171,6 +6160,10 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)

i9xx_disable_pll(intel_crtc);
}
   
+	for_each_encoder_on_crtc(dev, crtc, encoder)

+   if (encoder->post_pll_disable)
+   encoder->post_pll_disable(encoder);
+

We call "vlv_force_pll_off" in vlv_power_sequencer_kick which call
chv_disablepll.
Should we add the "post_pll_disable"in force pll off?

Nope. .post_pll_disable() is the counterpart to .pre_pll_enable() which
we don't use either in the pps kick procedure.

Apparently we don't need to concern ourselves with the clock
channel/districtution setp to make the pps kick work. Well, it's either
that, or we've just been lucky and those end up being set up in a good
way by accident. But now that you mention it, I do start wonder a bit
how it really works. So this is probably something I should test more
thoroughly at some point.
Thanks Ville, Yes we need to do more testing around pps kick. for now 
changes looks fine with matching pre/post


Reviewed-by: Deepak S 

if (!IS_GEN2(dev))
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
   }
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 32d7e43..40b8430 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2906,6 +2906,28 @@ static void chv_dp_pre_pll_enable(struct intel_encoder 
*encoder)
mutex_unlock(&dev_priv->sb_lock);
   }
   
+static void chv_dp_post_pll_disable(struct intel_encoder *encoder)

+{
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   enum pipe pipe = to_intel_crtc(encoder->base.crtc)->pipe;
+   u32 val;
+
+   mutex_lock(&dev_priv->sb_lock);
+
+   /* disable left/right clock distribution */
+   if (pipe != PIPE_B) {
+   val = vlv_dpio_read(dev_priv, pipe, _CHV_CMN_DW5_CH0);
+   val &= ~(CHV_BUFLEFTENA1_MASK | CHV_BUFRIGHTENA1_MASK);
+   vlv_dpio_write(dev_priv, pipe, _CHV_CMN_DW5_CH0, val);
+   } else {
+   val = vlv_dpio_read(dev_priv, pipe, _CHV_CMN_DW1_CH1);
+   val &= ~(CHV_BUFLEFTENA2_MASK | CHV_BUFRIGHTENA2_MASK);
+   vlv_dpio_write(dev_priv, pipe, _CHV_CMN_DW1_CH1, val);
+   }
+
+   mutex_unlock(&dev_priv->sb_lock);
+}
+
   /*
* Native read with retry for link status and receiver capability reads for
* cases where the sink may still be asleep.
@@ -5931,6 +5953,7 @@ intel_dp_init(struct drm_device *dev, int output_reg, 
enum port port)
intel_encoder->pre_enable = chv_pre_enable_dp;
intel_encoder->enable = vlv_enable_dp;
intel_encoder->post_disable = chv_post_disable_dp;
+   intel_encoder->post_pll_disable = chv_dp_post_pll_disable;
} else if (IS_VALLEYVIEW(dev)) {
intel_encoder->pre_pll_enable = vlv_dp_pre_pll_enable;
intel_encoder->pre_enable = vlv_pre_enable_dp;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 4f3b708..42fa135 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -148,6 +148,7 @@ struct

Re: [Intel-gfx] [PATCH v5 1/4] drm/i915: Add audio sync_audio_rate callback

[Daniel Vetter]

On Tue, Aug 18, 2015 at 02:51:51PM +0800, libin.y...@intel.com wrote:
> From: Libin Yang 
> 
> Add the sync_audio_rate callback.
> 
> With the callback, audio driver can trigger
> i915 driver to set the proper N/CTS or N/M
> based on different sample rates.
> 
> Signed-off-by: Libin Yang 
> ---
>  include/drm/i915_component.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h
> index c9a8b64..aabebcb 100644
> --- a/include/drm/i915_component.h
> +++ b/include/drm/i915_component.h
> @@ -33,6 +33,7 @@ struct i915_audio_component {
>   void (*put_power)(struct device *);
>   void (*codec_wake_override)(struct device *, bool enable);
>   int (*get_cdclk_freq)(struct device *);
> + int (*sync_audio_rate)(struct device *, int port, int rate);

We're missing kerneldoc for this entire struct here, which isn't great.
This needs to be fixed. Please
- pull out the ops structure so it's not inlined (kerneldoc can't handle
  nested ops structures).
- please document all the callbacks with kerneldoc. In 4.3 we can have
  kerneldoc in-line in structures right above each member like this

  /**
   * @put_power:
   *
   * Longer text explaining this hook.
   */
  void (*put_power)(struct device *);

  For each hook please explain at least who calls it (gfx or audio) and
  where exactly it's called in the overall flow.
- Extended the overview doc section with references to the component/ops
  structure would be needed too.

And please make sure it all looks pretty with make htmldocs.

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

Re: [Intel-gfx] [PATCH v3 2/4] drm/i915: implement sync_audio_rate callback

[Jani Nikula]

On Wed, 26 Aug 2015, Daniel Vetter  wrote:
> On Mon, Aug 17, 2015 at 03:20:38PM +0300, Jani Nikula wrote:
>> On Mon, 17 Aug 2015, libin.y...@intel.com wrote:
>> > From: Libin Yang 
>> >
>> > HDMI audio may not work at some frequencies
>> > with the HW provided N/CTS.
>> >
>> > This patch sets the proper N value for the
>> > given audio sample rate at the impacted frequencies.
>> > At other frequencies, it will use the N/CTS value
>> > which HW provides.
>> >
>> > Signed-off-by: Libin Yang 
>> > ---
>> >  drivers/gpu/drm/i915/intel_audio.c | 117 
>> > +
>> >  1 file changed, 117 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_audio.c 
>> > b/drivers/gpu/drm/i915/intel_audio.c
>> > index dc32cf4..27add6a 100644
>> > --- a/drivers/gpu/drm/i915/intel_audio.c
>> > +++ b/drivers/gpu/drm/i915/intel_audio.c
>> > @@ -68,6 +68,31 @@ static const struct {
>> >{ 148500, AUD_CONFIG_PIXEL_CLOCK_HDMI_148500 },
>> >  };
>> >  
>> > +/* HDMI N/CTS table */
>> > +#define TMDS_297M 297000
>> > +#define TMDS_296M DIV_ROUND_UP(297000 * 1000, 1001)
>> > +static const struct {
>> > +  int sample_rate;
>> > +  int clock;
>> > +  int n;
>> > +  int cts;
>> > +} aud_ncts[] = {
>> > +  { 44100, TMDS_296M, 4459, 234375 },
>> > +  { 44100, TMDS_297M, 4704, 247500 },
>> > +  { 48000, TMDS_296M, 5824, 281250 },
>> > +  { 48000, TMDS_297M, 5120, 247500 },
>> > +  { 32000, TMDS_296M, 5824, 421875 },
>> > +  { 32000, TMDS_297M, 3072, 222750 },
>> > +  { 88200, TMDS_296M, 8918, 234375 },
>> > +  { 88200, TMDS_297M, 9408, 247500 },
>> > +  { 96000, TMDS_296M, 11648, 281250 },
>> > +  { 96000, TMDS_297M, 10240, 247500 },
>> > +  { 176400, TMDS_296M, 17836, 234375 },
>> > +  { 176400, TMDS_297M, 18816, 247500 },
>> > +  { 44100, TMDS_296M, 23296, 281250 },
>> > +  { 44100, TMDS_297M, 20480, 247500 },
>> > +};
>> > +
>> >  /* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */
>> >  static u32 audio_config_hdmi_pixel_clock(struct drm_display_mode *mode)
>> >  {
>> > @@ -90,6 +115,31 @@ static u32 audio_config_hdmi_pixel_clock(struct 
>> > drm_display_mode *mode)
>> >return hdmi_audio_clock[i].config;
>> >  }
>> >  
>> > +static int audio_config_get_n(struct drm_display_mode *mode, int rate)
>> > +{
>> > +  int i;
>> > +
>> > +  for (i = 0; i < ARRAY_SIZE(aud_ncts); i++) {
>> > +  if ((rate == aud_ncts[i].sample_rate) &&
>> > +  (mode->clock == aud_ncts[i].clock)) {
>> > +  return aud_ncts[i].n;
>> > +  }
>> > +  }
>> > +  return 0;
>> > +}
>> > +
>> > +/* check whether N/CTS/M need be set manually */
>> > +static bool audio_rate_need_prog(struct intel_crtc *crtc,
>> > +  struct drm_display_mode *mode)
>> > +{
>> > +  if (((mode->clock == TMDS_297M) ||
>> > +   (mode->clock == TMDS_296M)) &&
>> > +  intel_pipe_has_type(crtc, INTEL_OUTPUT_HDMI))
>> > +  return true;
>> > +  else
>> > +  return false;
>> > +}
>> > +
>> >  static bool intel_eld_uptodate(struct drm_connector *connector,
>> >   int reg_eldv, uint32_t bits_eldv,
>> >   int reg_elda, uint32_t bits_elda,
>> > @@ -514,12 +564,79 @@ static int 
>> > i915_audio_component_get_cdclk_freq(struct device *dev)
>> >return ret;
>> >  }
>> >  
>> > +static int i915_audio_component_sync_audio_rate(struct device *dev,
>> > +  int port, int rate)
>> > +{
>> > +  struct drm_i915_private *dev_priv = dev_to_i915(dev);
>> > +  struct drm_device *drm_dev = dev_priv->dev;
>> > +  struct intel_encoder *intel_encoder;
>> > +  struct intel_digital_port *intel_dig_port;
>> > +  struct intel_crtc *crtc;
>> > +  struct drm_display_mode *mode;
>> > +  enum pipe pipe = -1;
>> > +  u32 tmp;
>> > +  int n_low, n_up, n;
>> > +
>> > +  /* 1. get the pipe */
>> > +  for_each_intel_encoder(drm_dev, intel_encoder) {
>> > +  intel_dig_port = enc_to_dig_port(&intel_encoder->base);
>> 
>> Mmmh, not all encoders are digital ports. enc_to_dig_port does a
>> container_of, so you can't just check for NULL either. IOW, you need to
>> check the encoder->type (and you only care about HDMI here).
>
> encoder->type is changed at runtime thanks to ddi encoders. Also shouldn't
> we care about dp audio too or am I confused?

IIUC DP can take care of itself, we need the whole callback here to be
able to program HDMI N/CTS parameters.

BR,
Jani.




> -Daniel
>
>> 
>> > +  if (port == intel_dig_port->port) {
>> > +  crtc = to_intel_crtc(intel_encoder->base.crtc);
>> > +  if (!crtc) {
>> > +  DRM_DEBUG_KMS("%s: crtc is NULL\n", __func__);
>> > +  continue;
>> > +  }
>> > +  pipe = crtc->pipe;
>> > +  break;
>> > +  }
>> > +  }
>> > +
>> > +  if (pipe == INVALID_PIPE) {
>> > +  DRM_DEBUG_KMS("no pipe for the port %c\n", por

Re: [Intel-gfx] [PATCH i-g-t] kms_addfb_basic: Require fb modifiers for unused field tests

[Ander Conselvan De Oliveira]

On Mon, 2015-08-24 at 14:40 +0100, Thomas Wood wrote:
> On 20 August 2015 at 15:43, Ander Conselvan de Oliveira
>  wrote:
> > The drm core doesn't check unused fields of ADDFB2 for pre-FB_MODIFIERS
> > userspace, so require that and use the local version of the defines.
> > 
> > Signed-off-by: Ander Conselvan de Oliveira 
> > 
> > ---
> >  tests/kms_addfb_basic.c | 19 ++-
> >  1 file changed, 14 insertions(+), 5 deletions(-)
> > 
> > diff --git a/tests/kms_addfb_basic.c b/tests/kms_addfb_basic.c
> > index f10e12b..732d6dc 100644
> > --- a/tests/kms_addfb_basic.c
> > +++ b/tests/kms_addfb_basic.c
> > @@ -51,6 +51,7 @@ static void invalid_tests(int fd)
> > f.height = 512;
> > f.pixel_format = DRM_FORMAT_XRGB;
> > f.pitches[0] = 512*4;
> > +   f.flags = LOCAL_DRM_MODE_FB_MODIFIERS;
> > 
> > igt_fixture {
> > gem_bo = gem_create(fd, 1024*1024*4);
> > @@ -60,35 +61,43 @@ static void invalid_tests(int fd)
> > 
> > f.handles[0] = gem_bo;
> > 
> > -   igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_ADDFB2, &f) == 0);
> > +   igt_assert(drmIoctl(fd, LOCAL_DRM_IOCTL_MODE_ADDFB2, &f) == 
> > 0);
> 
> Missing igt_require_fb_modifiers()? Maybe this needs to be placed in a
> separate subtest to prevent unrelated tests failing or skipping?

Looks like I was too trigger-happy with my search and replace. That one doesn't 
need the LOCAL_
version. I'll re-spin and also update the commit message based on our IRC 
discussion.

Thanks,
Ander

> 
> 
> > igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_RMFB, &f.fb_id) == 
> > 0);
> > f.fb_id = 0;
> > }
> > 
> > igt_subtest("unused-handle") {
> > +   igt_require_fb_modifiers(fd);
> > +
> > f.handles[1] = gem_bo_small;
> > -   igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_ADDFB2, &f) == -1 &&
> > +   igt_assert(drmIoctl(fd, LOCAL_DRM_IOCTL_MODE_ADDFB2, &f) == 
> > -1 &&
> >errno == EINVAL);
> > f.handles[1] = 0;
> > }
> > 
> > igt_subtest("unused-pitches") {
> > +   igt_require_fb_modifiers(fd);
> > +
> > f.pitches[1] = 512;
> > -   igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_ADDFB2, &f) == -1 &&
> > +   igt_assert(drmIoctl(fd, LOCAL_DRM_IOCTL_MODE_ADDFB2, &f) == 
> > -1 &&
> >errno == EINVAL);
> > f.pitches[1] = 0;
> > }
> > 
> > igt_subtest("unused-offsets") {
> > +   igt_require_fb_modifiers(fd);
> > +
> > f.offsets[1] = 512;
> > -   igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_ADDFB2, &f) == -1 &&
> > +   igt_assert(drmIoctl(fd, LOCAL_DRM_IOCTL_MODE_ADDFB2, &f) == 
> > -1 &&
> >errno == EINVAL);
> > f.offsets[1] = 0;
> > }
> > 
> > igt_subtest("unused-modifier") {
> > +   igt_require_fb_modifiers(fd);
> > +
> > f.modifier[1] =  LOCAL_I915_FORMAT_MOD_X_TILED;
> > -   igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_ADDFB2, &f) == -1 &&
> > +   igt_assert(drmIoctl(fd, LOCAL_DRM_IOCTL_MODE_ADDFB2, &f) == 
> > -1 &&
> >errno == EINVAL);
> > f.modifier[1] = 0;
> > }
> > --
> > 2.4.3
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/15] drm/i915: Add vlv_dport_to_phy()

[Daniel Vetter]

On Wed, Jul 08, 2015 at 11:45:53PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Add vlv_dport_to_phy() and fix up the return values of
> vlv_dport_to_channel() and vlv_pipe_to_channel() to use
> the appropriate enums.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_drv.h | 18 --
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 42fa135..23d5e46 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -791,7 +791,7 @@ struct intel_dp_mst_encoder {
>   void *port; /* store this opaque as its illegal to dereference it */
>  };
>  
> -static inline int
> +static inline enum dpio_channel
>  vlv_dport_to_channel(struct intel_digital_port *dport)
>  {
>   switch (dport->port) {
> @@ -805,7 +805,21 @@ vlv_dport_to_channel(struct intel_digital_port *dport)
>   }
>  }
>  
> -static inline int
> +static inline enum dpio_phy
> +vlv_dport_to_phy(struct intel_digital_port *dport)
> +{
> + switch (dport->port) {
> + case PORT_B:
> + case PORT_C:
> + return DPIO_PHY0;
> + case PORT_D:
> + return DPIO_PHY1;
> + default:
> + BUG();

BUG considered harmful in modeset code. Can you pls replace this with
something that kills machines less reliable in a follow-up?
-Daniel

> + }
> +}
> +
> +static inline enum dpio_channel
>  vlv_pipe_to_channel(enum pipe pipe)
>  {
>   switch (pipe) {
> -- 
> 2.3.6
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] drm/i915: Pin the ifbdev for the info->system_base GGTT mmapping

[Deepak]

On 08/25/2015 10:18 PM, Chris Wilson wrote:

A long time ago (before 3.14) we relied on a permanent pinning of the
ifbdev to lock the fb in place inside the GGTT. However, the
introduction of stealing the BIOS framebuffer and reusing its address in
the GGTT for the fbdev has muddied waters and we use an inherited fb.
However, the inherited fb is only pinned whilst it is active and we no
longer have an explicit pin for the info->system_base mmapping used by
the fbdev. The result is that after some aperture pressure the fbdev may
be evicted, but we continue to write the fbcon into the same GGTT
address - overwriting anything else that may be put into that offset.
The effect is most pronounced across suspend/resume as
intel_fbdev_set_suspend() does a full clear over the whole scanout.


Yup this is a critical fix :) by keeping the internal FB pinned we avoid 
alloc of buffer within same FB GTT offset

Reviewed-by: Deepak S 


Signed-off-by: Chris Wilson 
Cc: "Goel, Akash" 
Cc: Daniel Vetter 
Cc: Jesse Barnes 
Cc: sta...@vger.kernel.org
---
  drivers/gpu/drm/i915/intel_fbdev.c | 15 +++
  1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index 96476d7d7ed2..082f2938ec97 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -215,6 +215,16 @@ static int intelfb_create(struct drm_fb_helper *helper,
obj = intel_fb->obj;
size = obj->base.size;
  
+	/* The fb constructor will have already pinned us (or inherited a

+* GGTT region from the BIOS) suitable for a scanout, so
+* this should just be a no-op and increment the pin count for the
+* fbdev mmapping. It does have a useful side-effect of validating
+* the pin for fbdev's use via a GGTT mmapping.
+*/
+   ret = i915_gem_object_ggtt_pin(obj, NULL, 0, PIN_MAPPABLE);
+   if (ret)
+   goto out_unlock;
+
info = drm_fb_helper_alloc_fbi(helper);
if (IS_ERR(info)) {
ret = PTR_ERR(info);
@@ -274,6 +284,9 @@ static int intelfb_create(struct drm_fb_helper *helper,
  out_destroy_fbi:
drm_fb_helper_release_fbi(helper);
  out_unpin:
+   /* Once for info->screen_base mmaping... */
+   i915_gem_object_ggtt_unpin(obj);
+   /* ...and once for the intel_fb */
i915_gem_object_ggtt_unpin(obj);
drm_gem_object_unreference(&obj->base);
  out_unlock:
@@ -514,6 +527,8 @@ static const struct drm_fb_helper_funcs 
intel_fb_helper_funcs = {
  static void intel_fbdev_destroy(struct drm_device *dev,
struct intel_fbdev *ifbdev)
  {
+   /* Release the pinning for the info->screen_base mmaping. */
+   i915_gem_object_ggtt_unpin(ifbdev->fb->obj);
  
  	drm_fb_helper_unregister_fbi(&ifbdev->helper);

drm_fb_helper_release_fbi(&ifbdev->helper);


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

Re: [Intel-gfx] [PATCH 08/15] drm/i915: Implement PHY lane power gating for CHV

[Daniel Vetter]

On Wed, Jul 08, 2015 at 11:45:54PM +0300, ville.syrj...@linux.intel.com wrote:
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index dab1da9..506a8cc 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -946,14 +946,19 @@ static void chv_dpio_cmn_power_well_enable(struct 
> drm_i915_private *dev_priv,
>  struct i915_power_well *power_well)
>  {
>   enum dpio_phy phy;
> + enum pipe pipe;
> + uint32_t tmp;
>  
>   WARN_ON_ONCE(power_well->data != PUNIT_POWER_WELL_DPIO_CMN_BC &&
>power_well->data != PUNIT_POWER_WELL_DPIO_CMN_D);
>  
> - if (power_well->data == PUNIT_POWER_WELL_DPIO_CMN_BC)
> + if (power_well->data == PUNIT_POWER_WELL_DPIO_CMN_BC) {
> + pipe = PIPE_A;
>   phy = DPIO_PHY0;
> - else
> + } else {
> + pipe = PIPE_C;
>   phy = DPIO_PHY1;
> + }
>  
>   /* since ref/cri clock was enabled */
>   udelay(1); /* >10ns for cmnreset, >0ns for sidereset */

I have some minor context conflicts in this hunk and the next one and it
looks like I'm missing a patch. Since I'm not sure what's going on here
please either rebase or tell me which series I'm missing.

Merged the first 7 patches from this series meanwhile, thanks.
-Daniel

> @@ -963,8 +968,26 @@ static void chv_dpio_cmn_power_well_enable(struct 
> drm_i915_private *dev_priv,
>   if (wait_for(I915_READ(DISPLAY_PHY_STATUS) & PHY_POWERGOOD(phy), 1))
>   DRM_ERROR("Display PHY %d is not power up\n", phy);
>  
> + mutex_lock(&dev_priv->sb_lock);
> +
> + /* Enable dynamic power down */
> + tmp = vlv_dpio_read(dev_priv, pipe, CHV_CMN_DW28);
> + tmp |= DPIO_DYNPWRDOWNEN_CH0 | DPIO_CL1POWERDOWNEN;
> + vlv_dpio_write(dev_priv, pipe, CHV_CMN_DW28, tmp);
> +
> + if (power_well->data == PUNIT_POWER_WELL_DPIO_CMN_BC) {
> + tmp = vlv_dpio_read(dev_priv, pipe, _CHV_CMN_DW6_CH1);
> + tmp |= DPIO_DYNPWRDOWNEN_CH1;
> + vlv_dpio_write(dev_priv, pipe, _CHV_CMN_DW6_CH1, tmp);
> + }
> +
> + mutex_unlock(&dev_priv->sb_lock);
> +
>   dev_priv->chv_phy_control |= PHY_COM_LANE_RESET_DEASSERT(phy);
>   I915_WRITE(DISPLAY_PHY_CONTROL, dev_priv->chv_phy_control);
> +
> + DRM_DEBUG_KMS("Enabled DPIO PHY%d (PHY_CONTROL=0x%08x)\n",
> +   phy, dev_priv->chv_phy_control);
>  }
>  
>  static void chv_dpio_cmn_power_well_disable(struct drm_i915_private 
> *dev_priv,
> @@ -988,6 +1011,35 @@ static void chv_dpio_cmn_power_well_disable(struct 
> drm_i915_private *dev_priv,
>   I915_WRITE(DISPLAY_PHY_CONTROL, dev_priv->chv_phy_control);
>  
>   vlv_set_power_well(dev_priv, power_well, false);
> +
> + DRM_DEBUG_KMS("Disabled DPIO PHY%d (PHY_CONTROL=0x%08x)\n",
> +   phy, dev_priv->chv_phy_control);
> +}
> +
> +void chv_phy_powergate_lanes(struct intel_encoder *encoder,
> +  bool override, unsigned int mask)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct i915_power_domains *power_domains = &dev_priv->power_domains;
> + enum dpio_phy phy = vlv_dport_to_phy(enc_to_dig_port(&encoder->base));
> + enum dpio_channel ch = 
> vlv_dport_to_channel(enc_to_dig_port(&encoder->base));
> +
> + mutex_lock(&power_domains->lock);
> +
> + dev_priv->chv_phy_control &= ~PHY_CH_POWER_DOWN_OVRD(0xf, phy, ch);
> + dev_priv->chv_phy_control |= PHY_CH_POWER_DOWN_OVRD(mask, phy, ch);
> +
> + if (override)
> + dev_priv->chv_phy_control |= PHY_CH_POWER_DOWN_OVRD_EN(phy, ch);
> + else
> + dev_priv->chv_phy_control &= ~PHY_CH_POWER_DOWN_OVRD_EN(phy, 
> ch);
> +
> + I915_WRITE(DISPLAY_PHY_CONTROL, dev_priv->chv_phy_control);
> +
> + DRM_DEBUG_KMS("Power gating DPIO PHY%d CH%d lanes 0x%x 
> (PHY_CONTROL=0x%08x)\n",
> +   phy, ch, mask, dev_priv->chv_phy_control);
> +
> + mutex_unlock(&power_domains->lock);
>  }
>  
>  static bool chv_pipe_power_well_enabled(struct drm_i915_private *dev_priv,
> @@ -1620,19 +1672,72 @@ static void chv_phy_control_init(struct 
> drm_i915_private *dev_priv)
>* DISPLAY_PHY_CONTROL can get corrupted if read. As a
>* workaround never ever read DISPLAY_PHY_CONTROL, and
>* instead maintain a shadow copy ourselves. Use the actual
> -  * power well state to reconstruct the expected initial
> -  * value.
> +  * power well state and lane status to reconstruct the
> +  * expected initial value.
>*/
>   dev_priv->chv_phy_control =
>   PHY_LDO_SEQ_DELAY(PHY_LDO_DELAY_600NS, DPIO_PHY0) |
>   PHY_LDO_SEQ_DELAY(PHY_LDO_DELAY_600NS, DPIO_PHY1) |
> - PHY_CH_POWER_MODE(PHY_CH_SU_PSR, DPIO_PHY0, DPIO_CH0) |
> - PHY_CH_POWER_MODE(PHY_CH_SU_PSR, DPIO_PHY0, DPIO_CH1) |
> -

[Intel-gfx] [PATCH v2 i-g-t] kms_addfb_basic: Require fb modifiers for unused field tests

[Ander Conselvan de Oliveira]

The drm core doesn't check unused fields of ADDFB2 for pre-FB_MODIFIERS
userspace, so use igt_require_fb_modifiers(). Also, the size of the
ioctl changed with the addition of the modifiers, so it is necessary to
use the LOCAL_ version of it, otherwise some data may get truncated.

v2: Improve commit message. (Thomas)
Remove one spurious change to use LOCAL_DRM_IOCTL_ADDFB2. (Thomas)

Signed-off-by: Ander Conselvan de Oliveira 

---
 tests/kms_addfb_basic.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/tests/kms_addfb_basic.c b/tests/kms_addfb_basic.c
index 38af334..9c3659d 100644
--- a/tests/kms_addfb_basic.c
+++ b/tests/kms_addfb_basic.c
@@ -63,30 +63,40 @@ static void invalid_tests(int fd)
f.fb_id = 0;
}
 
+   f.flags = LOCAL_DRM_MODE_FB_MODIFIERS;
+
igt_subtest("unused-handle") {
+   igt_require_fb_modifiers(fd);
+
f.handles[1] = gem_bo_small;
-   igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_ADDFB2, &f) == -1 &&
+   igt_assert(drmIoctl(fd, LOCAL_DRM_IOCTL_MODE_ADDFB2, &f) == -1 
&&
   errno == EINVAL);
f.handles[1] = 0;
}
 
igt_subtest("unused-pitches") {
+   igt_require_fb_modifiers(fd);
+
f.pitches[1] = 512;
-   igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_ADDFB2, &f) == -1 &&
+   igt_assert(drmIoctl(fd, LOCAL_DRM_IOCTL_MODE_ADDFB2, &f) == -1 
&&
   errno == EINVAL);
f.pitches[1] = 0;
}
 
igt_subtest("unused-offsets") {
+   igt_require_fb_modifiers(fd);
+
f.offsets[1] = 512;
-   igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_ADDFB2, &f) == -1 &&
+   igt_assert(drmIoctl(fd, LOCAL_DRM_IOCTL_MODE_ADDFB2, &f) == -1 
&&
   errno == EINVAL);
f.offsets[1] = 0;
}
 
igt_subtest("unused-modifier") {
+   igt_require_fb_modifiers(fd);
+
f.modifier[1] =  LOCAL_I915_FORMAT_MOD_X_TILED;
-   igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_ADDFB2, &f) == -1 &&
+   igt_assert(drmIoctl(fd, LOCAL_DRM_IOCTL_MODE_ADDFB2, &f) == -1 
&&
   errno == EINVAL);
f.modifier[1] = 0;
}
-- 
2.4.3

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

Re: [Intel-gfx] [PATCH v5 4/4] drm/i915: DVO pixel clock check

[Daniel Vetter]

On Fri, Aug 21, 2015 at 02:52:54PM +0300, Mika Kahola wrote:
> On Fri, 2015-08-21 at 13:58 +0300, Ville Syrjälä wrote:
> > On Tue, Aug 18, 2015 at 02:37:02PM +0300, Mika Kahola wrote:
> > > It is possible the we request to have a mode that has
> > > higher pixel clock than our HW can support. This patch
> > > checks if requested pixel clock is lower than the one
> > > supported by the HW. The requested mode is discarded
> > > if we cannot support the requested pixel clock.
> > > 
> > > This patch applies to DVO.
> > > 
> > > V2:
> > > - removed computation for max pixel clock
> > > 
> > > V3:
> > > - cleanup by removing unnecessary lines
> > > 
> > > V4:
> > > - clock check against max dotclock moved inside 'if (fixed_mode)'
> > > 
> > > V5:
> > > - dot clock check against fixed_mode clock when available
> > > 
> > > Signed-off-by: Mika Kahola 
> > 
> > Reviewed-by: Ville Syrjälä 
> > 
> Thanks Ville for the reviews!

Merged entire series, thanks.
-Daniel

> 
> -Mika-
> 
> > > ---
> > >  drivers/gpu/drm/i915/intel_dvo.c | 7 +++
> > >  1 file changed, 7 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dvo.c 
> > > b/drivers/gpu/drm/i915/intel_dvo.c
> > > index dc532bb..c80fe1f 100644
> > > --- a/drivers/gpu/drm/i915/intel_dvo.c
> > > +++ b/drivers/gpu/drm/i915/intel_dvo.c
> > > @@ -201,6 +201,8 @@ intel_dvo_mode_valid(struct drm_connector *connector,
> > >struct drm_display_mode *mode)
> > >  {
> > >   struct intel_dvo *intel_dvo = intel_attached_dvo(connector);
> > > + int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
> > > + int target_clock = mode->clock;
> > >  
> > >   if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> > >   return MODE_NO_DBLESCAN;
> > > @@ -212,8 +214,13 @@ intel_dvo_mode_valid(struct drm_connector *connector,
> > >   return MODE_PANEL;
> > >   if (mode->vdisplay > intel_dvo->panel_fixed_mode->vdisplay)
> > >   return MODE_PANEL;
> > > +
> > > + target_clock = intel_dvo->panel_fixed_mode->clock;
> > >   }
> > >  
> > > + if (target_clock > max_dotclk)
> > > + return MODE_CLOCK_HIGH;
> > > +
> > >   return intel_dvo->dev.dev_ops->mode_valid(&intel_dvo->dev, mode);
> > >  }
> > >  
> > > -- 
> > > 1.9.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

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

Re: [Intel-gfx] [PATCH v5 1/4] drm/i915: Add audio sync_audio_rate callback

[Yang, Libin]

Hi Daniel,

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Wednesday, August 26, 2015 4:18 PM
> To: Yang, Libin
> Cc: alsa-de...@alsa-project.org; ti...@suse.de; intel-
> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch;
> jani.nik...@linux.intel.com
> Subject: Re: [PATCH v5 1/4] drm/i915: Add audio sync_audio_rate
> callback
> 
> On Tue, Aug 18, 2015 at 02:51:51PM +0800, libin.y...@intel.com
> wrote:
> > From: Libin Yang 
> >
> > Add the sync_audio_rate callback.
> >
> > With the callback, audio driver can trigger
> > i915 driver to set the proper N/CTS or N/M
> > based on different sample rates.
> >
> > Signed-off-by: Libin Yang 
> > ---
> >  include/drm/i915_component.h | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/include/drm/i915_component.h
> b/include/drm/i915_component.h
> > index c9a8b64..aabebcb 100644
> > --- a/include/drm/i915_component.h
> > +++ b/include/drm/i915_component.h
> > @@ -33,6 +33,7 @@ struct i915_audio_component {
> > void (*put_power)(struct device *);
> > void (*codec_wake_override)(struct device *, bool
> enable);
> > int (*get_cdclk_freq)(struct device *);
> > +   int (*sync_audio_rate)(struct device *, int port, int
> rate);
> 
> We're missing kerneldoc for this entire struct here, which isn't great.
> This needs to be fixed. Please
> - pull out the ops structure so it's not inlined (kerneldoc can't handle
>   nested ops structures).
> - please document all the callbacks with kerneldoc. In 4.3 we can have
>   kerneldoc in-line in structures right above each member like this
> 
>   /**
>* @put_power:
>*
>* Longer text explaining this hook.
>*/
>   void (*put_power)(struct device *);
> 
>   For each hook please explain at least who calls it (gfx or audio) and
>   where exactly it's called in the overall flow.
> - Extended the overview doc section with references to the
> component/ops
>   structure would be needed too.
> 
> And please make sure it all looks pretty with make htmldocs.

Could we start another patch session for this task because,
as you know, this is a little independent on these patches?
What do you think?

Regards,
Libin

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

Re: [Intel-gfx] [PATCH] drm/i915: Split alloc from init for lrc

[Daniel Vetter]

On Tue, Aug 18, 2015 at 04:06:17PM +0100, Chris Wilson wrote:
> On Tue, Aug 18, 2015 at 03:55:07PM +0100, Nick Hoath wrote:
> > >This is the wrong location. Just kill set_seqno, the experiment has run
> > >its course and we now have a n igt to exercise seqno wraparound.
> > It has to be here as the seqno has to be initialised before it is
> > used to create requests for the initialisation.
> 
> It is the wrong location as init_hw() is called as part of resume and
> reset, both times where we don't want to actually touch seqno.

Hm I thought it also makes sure to update the hws to avoid the driver
getting confused, which is probably something we should be doing on resume
(since the hws is in stolen) because hibernate.
-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

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Add audio pin sense / ELD callback

[Daniel Vetter]

On Wed, Aug 19, 2015 at 10:48:55AM +0200, David Henningsson wrote:
> This callback will be called by the i915 driver to notify the hda
> driver that its HDMI information needs to be refreshed, i e,
> that audio output is now available (or unavailable) - usually as a
> result of a monitor being plugged in (or unplugged).
> 
> Signed-off-by: David Henningsson 
> ---
>  include/drm/i915_component.h | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h
> index c9a8b64..ab5bde37 100644
> --- a/include/drm/i915_component.h
> +++ b/include/drm/i915_component.h
> @@ -34,6 +34,18 @@ struct i915_audio_component {
>   void (*codec_wake_override)(struct device *, bool enable);
>   int (*get_cdclk_freq)(struct device *);
>   } *ops;
> +
> + const struct i915_audio_component_audio_ops {
> + void *audio_ptr;
> + /**
> +  * Call from i915 driver, notifying the HDA driver that
> +  * pin sense and/or ELD information has changed.
> +  * @audio_ptr:  HDA driver object
> +  * @port:   Which port has changed (PORTA / PORTB / 
> PORTC etc)
> +  * @port_mst_index: Index within that port, for DisplayPort 
> multistreaming
> +  */
> + void (*pin_eld_notify)(void *audio_ptr, int port, int 
> port_mst_index);
> + } *audio_ops;

This won't work as proper kerneldoc, but you get away with it since it's
not pulled into the drm.tmpl. See my comments for the new set_audio_rate
callback.
-Daniel

>  };
>  
>  #endif /* _I915_COMPONENT_H_ */
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 08/15] drm/i915: Add NV12 as supported format for primary plane

[Daniel Vetter]

On Wed, Aug 19, 2015 at 06:02:29PM -0700, Chandra Konduru wrote:
> This patch adds NV12 to list of supported formats for
> primary plane.
> 
> v2:
> -Rebased (me)
> 
> Signed-off-by: Chandra Konduru 
> Testcase: igt/kms_nv12

I think it's time to unify the separate primary/cursor code we have for
skl and just use the sprite one everywhere. Doesn't need to happen
necessarily before this patch series, but really needs to happen rather
sooner than later. We've already broken some of the scaler tests because
we had to hack away the 3rd plane because we couldn't remove the cursor
stuff due to some oddball (and undebugged) reason. Iirc Damien has some
patches somewhere for this.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_display.c |   22 --
>  1 file changed, 20 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index b1d9edf..e4a6a91 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -74,6 +74,19 @@ static const uint32_t skl_primary_formats[] = {
>   DRM_FORMAT_XBGR2101010,
>  };
>  
> +/* Primary plane formats for gen >= 9 with NV12 */
> +static const uint32_t skl_primary_formats_with_nv12[] = {
> + DRM_FORMAT_C8,
> + DRM_FORMAT_RGB565,
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_XBGR,
> + DRM_FORMAT_ARGB,
> + DRM_FORMAT_ABGR,
> + DRM_FORMAT_XRGB2101010,
> + DRM_FORMAT_XBGR2101010,
> + DRM_FORMAT_NV12,
> +};
> +
>  /* Cursor formats */
>  static const uint32_t intel_cursor_formats[] = {
>   DRM_FORMAT_ARGB,
> @@ -13606,8 +13619,13 @@ static struct drm_plane 
> *intel_primary_plane_create(struct drm_device *dev,
>   primary->plane = !pipe;
>  
>   if (INTEL_INFO(dev)->gen >= 9) {
> - intel_primary_formats = skl_primary_formats;
> - num_formats = ARRAY_SIZE(skl_primary_formats);
> + if (pipe == PIPE_A || pipe == PIPE_B) {
> + intel_primary_formats = skl_primary_formats_with_nv12;
> + num_formats = ARRAY_SIZE(skl_primary_formats_with_nv12);
> + } else {
> + intel_primary_formats = skl_primary_formats;
> + num_formats = ARRAY_SIZE(skl_primary_formats);
> + }
>   } else if (INTEL_INFO(dev)->gen >= 4) {
>   intel_primary_formats = i965_primary_formats;
>   num_formats = ARRAY_SIZE(i965_primary_formats);
> -- 
> 1.7.9.5
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 14/15] drm/i915: skl nv12 workarounds

[Daniel Vetter]

On Wed, Aug 19, 2015 at 06:02:35PM -0700, Chandra Konduru wrote:
> Adding driver workarounds for nv12.
> 
> Signed-off-by: Chandra Konduru 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |   20 
>  drivers/gpu/drm/i915/intel_csr.c |2 +-
>  drivers/gpu/drm/i915/intel_display.c |   31 +++
>  drivers/gpu/drm/i915/intel_drv.h |1 +
>  drivers/gpu/drm/i915/intel_sprite.c  |7 +++
>  5 files changed, 60 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index c4d732f..3192837 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5354,6 +5354,26 @@ enum skl_disp_power_wells {
>  #define PLANE_NV12_BUF_CFG(pipe, plane)  \
>   _PLANE(plane, _PLANE_NV12_BUF_CFG_1(pipe), _PLANE_NV12_BUF_CFG_2(pipe))
>  
> +/*
> + * Skylake Chicken registers
> + */
> +#define _CHICKEN_PIPESL_A  0x420B0
> +#define _CHICKEN_PIPESL_B  0x420B4
> +#define _CHICKEN_PIPESL_C  0x420B8
> +#define  DISABLE_STREAMER_FIX  (1 << 22)
> +#define CHICKEN_PIPESL(pipe) _PIPE(pipe, _CHICKEN_PIPESL_A, 
> _CHICKEN_PIPESL_B)
> +
> +#define CHICKEN_DCPR_1 0x46430
> +#define IDLE_WAKEMEM_MASK  (1 << 13)
> +
> +#define CLKGATE_DIS_PSL_A0x46520
> +#define CLKGATE_DIS_PSL_B0x46524
> +#define CLKGATE_DIS_PSL_C0x46528
> +#define DUPS1_GATING_DIS (1 << 15)
> +#define DUPS2_GATING_DIS (1 << 19)
> +#define DUPS3_GATING_DIS (1 << 23)
> +#define CLKGATE_DIS_PSL(pipe)  _PIPE(pipe, CLKGATE_DIS_PSL_A, 
> CLKGATE_DIS_PSL_B)
> +
>  /* SKL new cursor registers */
>  #define _CUR_BUF_CFG_A   0x7017c
>  #define _CUR_BUF_CFG_B   0x7117c
> diff --git a/drivers/gpu/drm/i915/intel_csr.c 
> b/drivers/gpu/drm/i915/intel_csr.c
> index ba1ae03..559a7f5 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -181,7 +181,7 @@ static const struct stepping_info skl_stepping_info[] = {
>   {'G', '0'}, {'H', '0'}, {'I', '0'}
>  };
>  
> -static char intel_get_stepping(struct drm_device *dev)
> +char intel_get_stepping(struct drm_device *dev)

I guess we should have a new home for this now that it's used outside of
intel_csr.c Plus kerneldoc, as usual.

>  {
>   if (IS_SKYLAKE(dev) && (dev->pdev->revision <
>   ARRAY_SIZE(skl_stepping_info)))
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 419660d..2158b8f 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3196,6 +3196,16 @@ static void skylake_update_primary_plane(struct 
> drm_crtc *crtc,
>   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);
>  
> + DRM_DEBUG_KMS("KCM: is_skl = %d is_bxt = %d\n",
> + IS_SKYLAKE(dev), IS_BROXTON(dev));
> +

Wa comments are missing here. Also generally we do 1 wa per commit.
-Daniel

> + if (((IS_SKYLAKE(dev) && intel_get_stepping(dev) == 'C') ||
> + (IS_BROXTON(dev) && intel_get_stepping(dev) == 'A')) &&
> + fb->pixel_format == DRM_FORMAT_NV12) {
> + I915_WRITE(CHICKEN_PIPESL(pipe),
> + I915_READ(CHICKEN_PIPESL(pipe)) | 
> DISABLE_STREAMER_FIX);
> + }
> +
>   if (scaler_id >= 0) {
>   uint32_t ps_ctrl = 0;
>  
> @@ -5004,6 +5014,21 @@ static bool hsw_crtc_supports_ips(struct intel_crtc 
> *crtc)
>   return HAS_IPS(crtc->base.dev) && crtc->pipe == PIPE_A;
>  }
>  
> +
> +static void skl_wa_clkgate(struct drm_i915_private *dev_priv,
> + int pipe, int enable)
> +{
> + if (pipe == PIPE_A || pipe == PIPE_B) {
> + if (enable)
> + I915_WRITE(CLKGATE_DIS_PSL(pipe),
> + DUPS1_GATING_DIS | DUPS2_GATING_DIS);
> + else
> + I915_WRITE(CLKGATE_DIS_PSL(pipe),
> + I915_READ(CLKGATE_DIS_PSL(pipe) &
> + ~(DUPS1_GATING_DIS|DUPS2_GATING_DIS)));
> + }
> +}
> +
>  static void haswell_crtc_enable(struct drm_crtc *crtc)
>  {
>   struct drm_device *dev = crtc->dev;
> @@ -5094,6 +5119,9 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)
>   intel_wait_for_vblank(dev, hsw_workaround_pipe);
>   intel_wait_for_vblank(dev, hsw_workaround_pipe);
>   }
> +
> + /* workaround for NV12 */
> + skl_wa_clkgate(dev_priv, pipe, 1);
>  }
>  
>  static void ironlake_pfit_disable(struct intel_crtc *crtc)
> @@ -5211,6 +5239,9 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)
>  
>   intel_crtc->active = false;
>   intel_update_watermarks(crtc);
> +
> + /* workaround for NV12 */
> + skl_wa_clkgate(dev_priv, in

Re: [Intel-gfx] [PATCH 3/4] drm/fb-helper: Add module option to disable fbdev emulation

[Archit Taneja]

On 08/26/2015 10:42 AM, Archit Taneja wrote:



On 08/25/2015 07:15 PM, Daniel Vetter wrote:

Faster than recompiling.

Note that restore_fbdev_mode_unlocked is a bit special and the only
one which returns an error code when fbdev isn't there - i915 needs
that one to not fall over with some additional fbcon related restore
code. Everyone else just ignores the return value or only prints a
DRM_DEBUG level message.


Reviewed-by:Archit Taneja 



With the module param, and the drivers should see the following state(
based on the truth table below):

module param | config option
   true  |true   -> real helper funcs called, driver
allocated drm_fb_helper is correctly
populated.

   false |true   -> real helper funcs called, but bailed
out early, driver allocated
drm_fb_helper is non-NULL, but we won't
end up using it.

X|false  -> stub functions called, drm_fb_helper is
NULL

I wonder if the 2nd combination could leave space for errors in other
drivers. Drivers tend to check whether the fb_helper struct is NULL
or not, and make decisions based on that. If the decisions are to
just call a drm_fb_helper function, then we're okay. If they do 
something more than that, then we could have an issue.


I'll prepare the remainder of 'Step 2' part of the series over this,
and we can test to check if we don't hit any corner cases.

Archit





Signed-off-by: Daniel Vetter 
---
  drivers/gpu/drm/drm_fb_helper.c | 29 +
  1 file changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c
b/drivers/gpu/drm/drm_fb_helper.c
index 83aacb0cc9df..8259dec1de1f 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -39,6 +39,11 @@
  #include 
  #include 

+static bool drm_fbdev_emulation = true;
+module_param_named(fbdev_emulation, drm_fbdev_emulation, bool, 0600);
+MODULE_PARM_DESC(fbdev_emulation,
+ "Enable legacy fbdev emulation [default=true]");
+
  static LIST_HEAD(kernel_fb_helper_list);

  /**
@@ -99,6 +104,9 @@ int drm_fb_helper_single_add_all_connectors(struct
drm_fb_helper *fb_helper)
  struct drm_connector *connector;
  int i;

+if (!drm_fbdev_emulation)
+return 0;
+
  mutex_lock(&dev->mode_config.mutex);
  drm_for_each_connector(connector, dev) {
  struct drm_fb_helper_connector *fb_helper_connector;
@@ -129,6 +137,9 @@ int drm_fb_helper_add_one_connector(struct
drm_fb_helper *fb_helper, struct drm_
  struct drm_fb_helper_connector **temp;
  struct drm_fb_helper_connector *fb_helper_connector;

+if (!drm_fbdev_emulation)
+return 0;
+
  WARN_ON(!mutex_is_locked(&fb_helper->dev->mode_config.mutex));
  if (fb_helper->connector_count + 1 >
fb_helper->connector_info_alloc_count) {
  temp = krealloc(fb_helper->connector_info, sizeof(struct
drm_fb_helper_connector *) * (fb_helper->connector_count + 1),
GFP_KERNEL);
@@ -184,6 +195,9 @@ int drm_fb_helper_remove_one_connector(struct
drm_fb_helper *fb_helper,
  struct drm_fb_helper_connector *fb_helper_connector;
  int i, j;

+if (!drm_fbdev_emulation)
+return 0;
+
  WARN_ON(!mutex_is_locked(&fb_helper->dev->mode_config.mutex));

  for (i = 0; i < fb_helper->connector_count; i++) {
@@ -375,6 +389,9 @@ int
drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper
*fb_helper)
  bool do_delayed
  int ret;

+if (!drm_fbdev_emulation)
+return -ENODEV;
+
  drm_modeset_lock_all(dev);
  ret = restore_fbdev_mode(fb_helper);

@@ -591,6 +608,9 @@ int drm_fb_helper_init(struct drm_device *dev,
  struct drm_crtc *crtc;
  int i;

+if (!drm_fbdev_emulation)
+return 0;
+
  if (!max_conn_count)
  return -EINVAL;

@@ -713,6 +733,9 @@ EXPORT_SYMBOL(drm_fb_helper_release_fbi);

  void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
  {
+if (!drm_fbdev_emulation)
+return;
+
  if (!list_empty(&fb_helper->kernel_fb_list)) {
  list_del(&fb_helper->kernel_fb_list);
  if (list_empty(&kernel_fb_helper_list)) {
@@ -1933,6 +1956,9 @@ int drm_fb_helper_initial_config(struct
drm_fb_helper *fb_helper, int bpp_sel)
  struct drm_device *dev = fb_helper->dev;
  int count = 0;

+if (!drm_fbdev_emulation)
+return 0;
+
  mutex_lock(&dev->mode_config.mutex);
  count = drm_fb_helper_probe_connector_modes(fb_helper,
  dev->mode_config.max_width,
@@ -1976,6 +2002,9 @@ int drm_fb_helper_hotplug_event(struct
drm_fb_helper *fb_helper)
  struct drm_device *dev = fb_helper->dev;
  u32 max_width, max_height;

+if (!drm_fbdev_emulation)
+return 0;
+
  mutex_lock(&fb_helper->dev->mode_config.mutex);
  if (!fb_helper->fb || !drm_fb_helpe

Re: [Intel-gfx] [PATCH i-g-t 2/2] Adding kms_nv12 to test display NV12 feature

[Daniel Vetter]

On Wed, Aug 19, 2015 at 06:05:25PM -0700, Chandra Konduru wrote:
> From: chandra konduru 
> 
> This patch adds kms_nv12 test case. It covers testing NV12
> in linear/tile-X/tile-Y tiling formats in 0/90/180/270
> orientations. For each tiling format, it tests several
> combinations of planes and its scaling.
> 
> v2:
> -Added 90/270 tests (me)
> -took out crc test as it isn't adding much value due to chroma upsampling (me)
> 
> v3:
> -Make --list-subtests option work (Tvrtko)
> -Make nv12 unsupported test run properly either as a sub test
>  or along with all other tests (me)
> -Added nv12 fb with invalid params (Daniel)
> 
> Signed-off-by: chandra konduru 
> ---
>  tests/.gitignore   |   1 +
>  tests/Makefile.sources |   1 +
>  tests/kms_nv12.c   | 759 
> +
>  3 files changed, 761 insertions(+)
>  create mode 100644 tests/kms_nv12.c
> 
> diff --git a/tests/.gitignore b/tests/.gitignore
> index d6d05ff..2de4712 100644
> --- a/tests/.gitignore
> +++ b/tests/.gitignore
> @@ -155,6 +155,7 @@ kms_setmode
>  kms_sink_crc_basic
>  kms_universal_plane
>  kms_vblank
> +kms_nv12
>  pm_backlight
>  pm_lpsp
>  pm_rc6_residency
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index ef69299..a7804fa 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -85,6 +85,7 @@ TESTS_progs_M = \
>   kms_crtc_background_color \
>   kms_plane_scaling \
>   kms_panel_fitting \
> + kms_nv12 \
>   pm_backlight \
>   pm_lpsp \
>   pm_rpm \
> diff --git a/tests/kms_nv12.c b/tests/kms_nv12.c
> new file mode 100644
> index 000..9f90a85
> --- /dev/null
> +++ b/tests/kms_nv12.c
> @@ -0,0 +1,759 @@
> +/*
> + * Copyright © 2013,2014 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "drmtest.h"
> +#include "igt_debugfs.h"
> +#include "igt_kms.h"
> +#include "igt_core.h"
> +#include "intel_chipset.h"
> +#include "ioctl_wrappers.h"
> +
> +IGT_TEST_DESCRIPTION("Test display NV12 support");
> +
> +uint32_t devid;
> +typedef struct {
> + int drm_fd;
> + igt_display_t display;
> + int num_scalers;
> + int num_planes;
> +
> + struct igt_fb fb1;
> + struct igt_fb fb1_nv12;
> + struct igt_fb fb2;
> + struct igt_fb fb2_nv12;
> + struct igt_fb fb3;
> + struct igt_fb fb3_nv12;
> + int fb_id1;
> + int fb_id1_nv12;
> + int fb_id2;
> + int fb_id2_nv12;
> + int fb_id3;
> + int fb_id3_nv12;
> +
> + igt_plane_t *plane1;
> + igt_plane_t *plane2;
> + igt_plane_t *plane3;
> +
> + uint64_t tiled;
> + int rotation;
> +} data_t;
> +
> +typedef struct {
> + int width;
> + int height;
> +} res_t;
> +
> +#define IMG_FILE  "1080p-left.png"
> +
> +static void
> +paint_pattern(data_t *d, struct igt_fb *fb, uint16_t w, uint16_t h)
> +{
> + cairo_t *cr;
> +
> + cr = igt_get_cairo_ctx(d->drm_fd, fb);
> + igt_paint_test_pattern(cr, w, h);
> + cairo_destroy(cr);
> +}
> +
> +static void
> +paint_image(data_t *d, struct igt_fb *fb, uint16_t w, uint16_t h)
> +{
> + cairo_t *cr;
> +
> + cr = igt_get_cairo_ctx(d->drm_fd, fb);
> + igt_paint_image(cr, IMG_FILE, 0, 0, w, h);
> + cairo_destroy(cr);
> +}
> +
> +static void prepare_crtc(data_t *data, igt_output_t *output, enum pipe pipe,
> + igt_plane_t *plane, drmModeModeInfo *mode, enum 
> igt_commit_style s)
> +{
> + igt_display_t *display = &data->display;
> +
> + igt_output_set_pipe(output, pipe);
> +
> + /* before allocating, free if any older fb */
> + if (data->fb_id1) {
> + igt_remove_fb(data->drm_fd, &data->fb1);
> + data->fb_id1 = 0;
> + }
> +
> + /* allocate fb for plane 1 */
> + data->fb_id1 = igt_create_fb(data->drm_fd,
> + 

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Enable full ppgtt for vgpu

[Daniel Vetter]

On Thu, Aug 20, 2015 at 01:57:13PM +0300, Joonas Lahtinen wrote:
> On to, 2015-08-20 at 15:45 +0800, Zhiyuan Lv wrote:
> > The full ppgtt is supported in Intel GVT-g device model. So the
> > restriction can be removed.
> > 
> > Signed-off-by: Zhiyuan Lv 
> > Signed-off-by: Zhi Wang 
> 
> Reviewed-by: Joonas Lahtinen 
> 
> > ---
> >  drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ---
> >  1 file changed, 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > index ed10e77..823005c 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > @@ -108,9 +108,6 @@ static int sanitize_enable_ppgtt(struct 
> > drm_device *dev, int enable_ppgtt)
> > has_aliasing_ppgtt = INTEL_INFO(dev)->gen >= 6;
> > has_full_ppgtt = INTEL_INFO(dev)->gen >= 7;
> >  
> > -   if (intel_vgpu_active(dev))
> > -   has_full_ppgtt = false; /* emulation is too hard */

Don't we need a feature check for the virtual gpu here? Or at least a
platform check? Seems like the backwards/forwards compat story isn't too
thought out yet here. Note that the kernel of the host and the guest might
not be the same at all, much less the kvm part.
-Daniel

> > -
> > /*
> >  * We don't allow disabling PPGTT for gen9+ as it's a 
> > requirement for
> >  * execlists, the sole mechanism available to submit work.
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] drm/i915: Split alloc from init for lrc

[Chris Wilson]

On Wed, Aug 26, 2015 at 10:32:01AM +0200, Daniel Vetter wrote:
> On Tue, Aug 18, 2015 at 04:06:17PM +0100, Chris Wilson wrote:
> > On Tue, Aug 18, 2015 at 03:55:07PM +0100, Nick Hoath wrote:
> > > >This is the wrong location. Just kill set_seqno, the experiment has run
> > > >its course and we now have a n igt to exercise seqno wraparound.
> > > It has to be here as the seqno has to be initialised before it is
> > > used to create requests for the initialisation.
> > 
> > It is the wrong location as init_hw() is called as part of resume and
> > reset, both times where we don't want to actually touch seqno.
> 
> Hm I thought it also makes sure to update the hws to avoid the driver
> getting confused, which is probably something we should be doing on resume
> (since the hws is in stolen) because hibernate.

The hws page can't be in stolen since we need CPU access to it and the
powers-that-be have said no.
-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 3/7] drm/i915: Always enable execlists on BDW for vgpu

[Daniel Vetter]

On Mon, Aug 24, 2015 at 03:36:46PM +0300, Joonas Lahtinen wrote:
> On pe, 2015-08-21 at 10:24 +0800, Zhiyuan Lv wrote:
> > Hi Joonas,
> > 
> > Thanks for the review! And my reply inline.
> > 
> > Regards,
> > -Zhiyuan
> > 
> > On Thu, Aug 20, 2015 at 02:23:11PM +0300, Joonas Lahtinen wrote:
> > > Hi,
> > > 
> > > On to, 2015-08-20 at 17:40 +0800, Zhiyuan Lv wrote:
> > > > On Thu, Aug 20, 2015 at 10:22:37AM +0100, Chris Wilson wrote:
> > > > > On Thu, Aug 20, 2015 at 04:55:08PM +0800, Zhiyuan Lv wrote:
> > > > > > Hi Chris,
> > > > > > 
> > > > > > On Thu, Aug 20, 2015 at 09:34:05AM +0100, Chris Wilson wrote:
> > > > > > > On Thu, Aug 20, 2015 at 03:45:20PM +0800, Zhiyuan Lv wrote:
> > > > > > > > Broadwell hardware supports both ring buffer mode and 
> > > > > > > > execlist mode.
> > > > > > > > When i915 runs inside a VM with Intel GVT-g, we allow 
> > > > > > > > execlist mode
> > > > > > > > only. The reason is that GVT-g does not support the 
> > > > > > > > dynamic 
> > > > > > > > mode
> > > > > > > > switch between ring buffer mode and execlist mode when 
> > > > > > > > running
> > > > > > > > multiple virtual machines. Consider that ring buffer mode 
> > > > > > > > is 
> > > > > > > > legacy
> > > > > > > > mode, it makes sense to drop it inside virtual machines.
> > > > > > > 
> > > > > > > If that is the case, you should query the host as to what 
> > > > > > > mode 
> > > > > > > it is
> > > > > > > running.
> > > > > > 
> > > > > > Thanks for the reply! You mean we query the host mode, then 
> > > > > > tell 
> > > > > > the
> > > > > > guest driver inside VM, so that it could use the same mode as 
> > > > > > host
> > > > > > right? That might be a little complicated, and the only 
> > > > > > benefit 
> > > > > > is to
> > > > > > support legacy ring buffer mode ...
> > > > > 
> > > > > The only benefit being that the guest works no matter what the 
> > > > > host
> > > > > does?
> > > > 
> > > > Supporting ring buffer mode may need more work in GVT-g. When we 
> > > > started to
> > > > enable BDW support, ring buffer mode used to work but was not 
> > > > well 
> > > > tested. And
> > > > the inter-VM switch (all in ringbuffer mode) may be tricker 
> > > > comparing 
> > > > with
> > > > driver context switch with "MI_SET_CONTEXT", because we need to 
> > > > switch ring
> > > > buffer whereas driver does not. Regarding this, the EXECLIST mode 
> > > > looks
> > > > cleaner. In order to support that, we may have to: 1, change more 
> > > > LRI 
> > > > commands
> > > > to MMIO in current driver; 2, more testing/debugging of inter-VM 
> > > > context
> > > > switch flow.
> > > > 
> > > > Based on that, I think we should really make statement that "ring 
> > > > buffer mode"
> > > > is not supported by GVT-g on BDW :-)
> > > > 
> > > 
> > > I think just move the vpgu test even before test for GEN9 just 
> > > making
> > > it return true on intel_vgpu_active(dev) and add a comment that
> > > currently vGPU only supports execlist command submission, and then 
> > > add
> > 
> > Will do. Thanks!
> > 
> > > an error early in the init in some appropriate spot if
> > > intel_vgpu_active is true but logical ring context are not 
> > > available
> > > (which would practically mean GEN < 8).
> > > 
> > > Does that sound OK?
> > 
> > Ring buffer mode for Haswell with vgpu is still supported. So 
> > probably I have
> > the check like below? Thanks!
> > 
> 
> Ah sorry, I missed that.
> 
> > @@ -332,6 +332,12 @@ int i915_gem_context_init(struct drm_device 
> > *dev)
> > if (WARN_ON(dev_priv->ring[RCS].default_context))
> > return 0;
> >  
> > +   if (intel_vgpu_active(dev)) {
> > +   if (WARN_ON(HAS_LOGICAL_RING_CONTEXTS(dev) &&
> > +   !i915.enable_execlist))
> > +   return 0;
> > +   }
> > +
> 
> This looks fine to me. Maybe comment might be in place stating that
> support is not yet implemented, but could be.

You should fail this instead so that i915.ko knows that the render side of
the gpu doesn't work. And maybe just DRM_INFO with a useful informational
notice?

Also same comment here: Don't we need to coordinate this a bit better with
the host?
-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

[Intel-gfx] [PATCH 1/3] drm/i915: During shrink_all we only need to idle the GPU

[Chris Wilson]

We can forgo an evict-everything here as the shrinker operation itself
will unbind any vma as required. If we explicitly idle the GPU through a
switch to the default context, we not only create a request in an
illegal context (e.g. whilst shrinking during execbuf with a request
already allocated), but switching to the default context will not free
up the memory backing the active contexts - unless in the unlikely
situation that context had already been closed (and just kept arrive by
being the current context). The saving is near zero and the danger real.

Note that the double flush used here to protect against retire_requests
being a transitive cache of small data structures.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index f6ecbda2c604..33e90e8a2e8a 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -158,9 +158,16 @@ i915_gem_shrink(struct drm_i915_private *dev_priv,
  */
 unsigned long i915_gem_shrink_all(struct drm_i915_private *dev_priv)
 {
-   i915_gem_evict_everything(dev_priv->dev);
-   return i915_gem_shrink(dev_priv, LONG_MAX,
-  I915_SHRINK_BOUND | I915_SHRINK_UNBOUND);
+   unsigned long count;
+
+   count = i915_gem_shrink(dev_priv, LONG_MAX,
+   I915_SHRINK_BOUND | I915_SHRINK_UNBOUND);
+
+   /* Use a double call to retire to flush any staged frees  */
+   i915_gem_retire_requests(dev_priv->dev);
+   i915_gem_retire_requests(dev_priv->dev);
+
+   return count;
 }
 
 static bool i915_gem_shrinker_lock(struct drm_device *dev, bool *unlock)
-- 
2.5.0

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

[Intel-gfx] [PATCH 2/3] drm/i915: Remove dead i915_gem_evict_everything()

[Chris Wilson]

With UMS gone, we no longer use it during suspend. And with the last
user removed from the shrinker, we can remove the dead code.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h   |  1 -
 drivers/gpu/drm/i915/i915_gem_evict.c | 45 ---
 2 files changed, 46 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 55611d81ec6c..1e117f573ee1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3127,7 +3127,6 @@ int __must_check i915_gem_evict_something(struct 
drm_device *dev,
  unsigned long end,
  unsigned flags);
 int i915_gem_evict_vm(struct i915_address_space *vm, bool do_idle);
-int i915_gem_evict_everything(struct drm_device *dev);
 
 /* belongs in i915_gem_gtt.h */
 static inline void i915_gem_chipset_flush(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
b/drivers/gpu/drm/i915/i915_gem_evict.c
index d09e35ed9c9a..d71a133ceff5 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -237,48 +237,3 @@ int i915_gem_evict_vm(struct i915_address_space *vm, bool 
do_idle)
 
return 0;
 }
-
-/**
- * i915_gem_evict_everything - Try to evict all objects
- * @dev: Device to evict objects for
- *
- * This functions tries to evict all gem objects from all address spaces. Used
- * by the shrinker as a last-ditch effort and for suspend, before releasing the
- * backing storage of all unbound objects.
- */
-int
-i915_gem_evict_everything(struct drm_device *dev)
-{
-   struct drm_i915_private *dev_priv = dev->dev_private;
-   struct i915_address_space *vm, *v;
-   bool lists_empty = true;
-   int ret;
-
-   list_for_each_entry(vm, &dev_priv->vm_list, global_link) {
-   lists_empty = (list_empty(&vm->inactive_list) &&
-  list_empty(&vm->active_list));
-   if (!lists_empty)
-   lists_empty = false;
-   }
-
-   if (lists_empty)
-   return -ENOSPC;
-
-   trace_i915_gem_evict_everything(dev);
-
-   /* The gpu_idle will flush everything in the write domain to the
-* active list. Then we must move everything off the active list
-* with retire requests.
-*/
-   ret = i915_gpu_idle(dev);
-   if (ret)
-   return ret;
-
-   i915_gem_retire_requests(dev);
-
-   /* Having flushed everything, unbind() should never raise an error */
-   list_for_each_entry_safe(vm, v, &dev_priv->vm_list, global_link)
-   WARN_ON(i915_gem_evict_vm(vm, false));
-
-   return 0;
-}
-- 
2.5.0

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

[Intel-gfx] [PATCH 3/3] drm/i915: Avoid GPU stalls from kswapd

[Chris Wilson]

Exclude active GPU pages from the purview of the background shrinker
(kswapd), as these cause uncontrollable GPU stalls. Given that the
shrinker is rerun until the freelists are satisfied, we should have
opportunity in subsequent passes to recover the pages once idle. If the
machine does run out of memory entirely, we have the forced idling in the
oom-notifier as a means of releasing all the pages we can before an oom
is prematurely executed.

Signed-off-by: Chris Wilson 
Reviewed-by: Damien Lespiau 
---
 drivers/gpu/drm/i915/i915_drv.h  | 1 +
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 9 +++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1e117f573ee1..ad61982fcaa3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3158,6 +3158,7 @@ unsigned long i915_gem_shrink(struct drm_i915_private 
*dev_priv,
 #define I915_SHRINK_PURGEABLE 0x1
 #define I915_SHRINK_UNBOUND 0x2
 #define I915_SHRINK_BOUND 0x4
+#define I915_SHRINK_ACTIVE 0x8
 unsigned long i915_gem_shrink_all(struct drm_i915_private *dev_priv);
 void i915_gem_shrinker_init(struct drm_i915_private *dev_priv);
 
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 33e90e8a2e8a..ef2cc4714e9e 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -123,6 +123,9 @@ i915_gem_shrink(struct drm_i915_private *dev_priv,
obj->madv != I915_MADV_DONTNEED)
continue;
 
+   if ((flags & I915_SHRINK_ACTIVE) == 0 && obj->active)
+   continue;
+
drm_gem_object_reference(&obj->base);
 
/* For the unbound phase, this should be a no-op! */
@@ -161,7 +164,9 @@ unsigned long i915_gem_shrink_all(struct drm_i915_private 
*dev_priv)
unsigned long count;
 
count = i915_gem_shrink(dev_priv, LONG_MAX,
-   I915_SHRINK_BOUND | I915_SHRINK_UNBOUND);
+   I915_SHRINK_BOUND |
+   I915_SHRINK_UNBOUND |
+   I915_SHRINK_ACTIVE);
 
/* Use a double call to retire to flush any staged frees  */
i915_gem_retire_requests(dev_priv->dev);
@@ -220,7 +225,7 @@ i915_gem_shrinker_count(struct shrinker *shrinker, struct 
shrink_control *sc)
count += obj->base.size >> PAGE_SHIFT;
 
list_for_each_entry(obj, &dev_priv->mm.bound_list, global_list) {
-   if (obj->pages_pin_count == num_vma_bound(obj))
+   if (!obj->active && obj->pages_pin_count == num_vma_bound(obj))
count += obj->base.size >> PAGE_SHIFT;
}
 
-- 
2.5.0

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

[Intel-gfx] [PATCH 2/2] drm/i915: Do not enable IPS with the primary plane disabled.

[Maarten Lankhorst]

This fixes kms_universal_plane.universal-plane-pipe-A-functional.

IPS gets enabled even though the primary plane is disabled. This is
not supported, and results in warnings like below:

[ cut here ]
WARNING: CPU: 0 PID: 1707 at drivers/gpu/drm/i915/intel_display.c:1354
assert_plane.constprop.66+0x70/0xa0 [i915]()
plane A assertion failure (expected on, current off)
Modules linked in: i915
CPU: 0 PID: 1707 Comm: kms_universal_p Tainted: GW
4.2.0-rc2-patser+ #4288
Hardware name: NUC5i7RYB,
BIOS RYBDWi35.86A.0246.2015.0309.1355 03/09/2015
 c01d3278 8800ccc37c88 816f6e74 8000
 8800ccc37cd8 8800ccc37cc8 8107bfe1 8800ccc37ca8
  880117aa4520 8800d7435388 8800d517
Call Trace:
 [] dump_stack+0x4f/0x7b
 [] warn_slowpath_common+0x81/0xc0
 [] warn_slowpath_fmt+0x41/0x50
 [] assert_plane.constprop.66+0x70/0xa0 [i915]
 [] hsw_enable_ips+0x50/0x150 [i915]
 [] display_crc_ctl_write+0x623/0xbf0 [i915]
 [] __vfs_write+0x23/0xe0
 [] ? __sb_start_write+0x44/0xf0
 [] ? security_file_permission+0x38/0xc0
 [] vfs_write+0xa4/0x190
 [] ? do_setitimer+0x12e/0x220
 [] SyS_write+0x41/0xa0
 [] entry_SYSCALL_64_fastpath+0x12/0x6a
---[ end trace 264b7f8804a754c3 ]---

This can be fixed easily by checking primary->visible.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index caf1382116de..9abf70cb3525 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3799,7 +3799,13 @@ static int pipe_crc_set_source(struct drm_device *dev, 
enum pipe pipe,
 * user space can't make reliable use of the CRCs, so let's just
 * completely disable it.
 */
-   hsw_disable_ips(crtc);
+
+   if (HAS_IPS(dev) && pipe == PIPE_A) {
+   drm_modeset_lock(&crtc->base.primary->mutex, NULL);
+   if 
(to_intel_plane_state(crtc->base.primary->state)->visible)
+   hsw_disable_ips(crtc);
+   drm_modeset_unlock(&crtc->base.primary->mutex);
+   }
 
spin_lock_irq(&pipe_crc->lock);
kfree(pipe_crc->entries);
@@ -3843,8 +3849,12 @@ static int pipe_crc_set_source(struct drm_device *dev, 
enum pipe pipe,
vlv_undo_pipe_scramble_reset(dev, pipe);
else if (IS_HASWELL(dev) && pipe == PIPE_A)
hsw_undo_trans_edp_pipe_A_crc_wa(dev);
-
-   hsw_enable_ips(crtc);
+   else if (HAS_IPS(dev) && pipe == PIPE_A) {
+   drm_modeset_lock(&crtc->base.primary->mutex, NULL);
+   if 
(to_intel_plane_state(crtc->base.primary->state)->visible)
+   hsw_enable_ips(crtc);
+   drm_modeset_unlock(&crtc->base.primary->mutex);
+   }
}
 
return 0;
-- 
2.1.0

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

Re: [Intel-gfx] About the iGVT-g's requirement to pin guest contexts in VM

[Daniel Vetter]

On Tue, Aug 25, 2015 at 08:17:05AM +0800, Zhiyuan Lv wrote:
> Hi Chris,
> 
> On Mon, Aug 24, 2015 at 11:23:13AM +0100, Chris Wilson wrote:
> > On Mon, Aug 24, 2015 at 06:04:28PM +0800, Zhiyuan Lv wrote:
> > > Hi Chris,
> > > 
> > > On Thu, Aug 20, 2015 at 09:36:00AM +0100, Chris Wilson wrote:
> > > > On Thu, Aug 20, 2015 at 03:45:21PM +0800, Zhiyuan Lv wrote:
> > > > > Intel GVT-g will perform EXECLIST context shadowing and ring buffer
> > > > > shadowing. The shadow copy is created when guest creates a context.
> > > > > If a context changes its LRCA address, the hypervisor is hard to know
> > > > > whether it is a new context or not. We always pin context objects to
> > > > > global GTT to make life easier.
> > > > 
> > > > Nak. Please explain why we need to workaround a bug in the host. We
> > > > cannot pin the context as that breaks userspace (e.g. synmark) who can
> > > > and will try to use more contexts than we have room.
> > > 
> > > Could you have a look at below reasons and kindly give us your inputs?
> > > 
> > > 1, Due to the GGTT partitioning, the global graphics memory available
> > > inside virtual machines is much smaller than native case. We cannot
> > > support some graphics memory intensive workloads anyway. So it looks
> > > affordable to just pin contexts which do not take much GGTT.
> > 
> > Wrong. It exposes the guest to a trivial denial-of-service attack. A
> 
> Inside a VM, indeed.
> 
> > smaller GGTT does not actually limit clients (there is greater aperture
> > pressure and some paths are less likely but an individual client will
> > function just fine).
> >  
> > > 2, Our hypervisor needs to change i915 guest context in the shadow
> > > context implementation. That part will be tricky if the context is not
> > > always pinned. One scenario is that when a context finishes running,
> > > we need to copy shadow context, which has been updated by hardware, to
> > > guest context. The hypervisor knows context finishing by context
> > > interrupt, but that time shrinker may have unpin the context and its
> > > backing storage may have been swap-out. Such copy may fail. 
> > 
> > That is just a bug in your code. Firstly allowing swapout on an object
> > you still are using, secondly not being able to swapin.
> 
> As Zhi replied in another email, we do not have the knowledge of guest
> driver's swap operations. If we cannot pin context, we may have to ask
> guest driver not to swap out context pages. Do you think that would be
> the right way to go? Thanks!

It doesn't matter at all - if the guest unpins the ctx and puts something
else in there before the host tells it that the ctx is completed, that's a
bug in the guest. Same with real hw, we guarantee that the context stays
around for long enough.

Also you obviously have to complete the copying from shadow->guest ctx
before you send the irq to the guest to signal ctx completion. Which means
there's really no overall problem here from a design pov, the only thing
you have to do is fix up bugs in the host code (probably you should just
write through the ggtt).
-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

[Intel-gfx] [PATCH 1/2] drm/i915: Do not turn off IPS twice.

[Maarten Lankhorst]

This is done through pre_disable_primary and hsw_disable_ips.
They're both set on the same conditions, so leave the check of
disable_ips in pre_disable_primary.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 16 +---
 drivers/gpu/drm/i915/intel_drv.h |  1 -
 2 files changed, 1 insertion(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index af0bcfee4771..b01e89487784 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4790,9 +4790,6 @@ static void intel_pre_plane_update(struct intel_crtc 
*crtc)
if (atomic->disable_fbc)
intel_fbc_disable_crtc(crtc);
 
-   if (crtc->atomic.disable_ips)
-   hsw_disable_ips(crtc);
-
if (atomic->pre_disable_primary)
intel_pre_disable_primary(&crtc->base);
 
@@ -11726,19 +11723,8 @@ int intel_plane_atomic_calc_changes(struct 
drm_crtc_state *crtc_state,
intel_crtc->atomic.pre_disable_primary = turn_off;
intel_crtc->atomic.post_enable_primary = turn_on;
 
-   if (turn_off) {
-   /*
-* FIXME: Actually if we will still have any other
-* plane enabled on the pipe we could let IPS enabled
-* still, but for now lets consider that when we make
-* primary invisible by setting DSPCNTR to 0 on
-* update_primary_plane function IPS needs to be
-* disable.
-*/
-   intel_crtc->atomic.disable_ips = true;
-
+   if (turn_off)
intel_crtc->atomic.disable_fbc = true;
-   }
 
/*
 * FBC does not work on some platforms for rotated
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3b00d00c0bc0..379485f744ef 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -493,7 +493,6 @@ struct intel_crtc_atomic_commit {
/* Sleepable operations to perform before commit */
bool wait_for_flips;
bool disable_fbc;
-   bool disable_ips;
bool disable_cxsr;
bool pre_disable_primary;
bool update_wm_pre, update_wm_post;
-- 
2.1.0

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

Re: [Intel-gfx] [PATCH v2 0/7] drm/i915: clean up *_digital_port_connected

[Daniel Vetter]

On Thu, Aug 20, 2015 at 10:47:35AM +0300, Jani Nikula wrote:
> v2 with missing cases handled and intel_digital_port_connected return
> value changed to bool. Mostly it's just the addition of patches 2 and 3,
> and rebase of the rest.

Pulled in entire series, thanks.
-Daniel

> 
> BR,
> Jani.
> 
> 
> Jani Nikula (7):
>   drm/i915: move ibx_digital_port_connected to intel_dp.c
>   drm/i915: make g4x_digital_port_connected return boolean status
>   drm/i915: add MISSING_CASE annotation to ibx_digital_port_connected
>   drm/i915: add common intel_digital_port_connected function
>   drm/i915: split ibx_digital_port_connected to ibx and cpt variants
>   drm/i915: split g4x_digital_port_connected to g4x and vlv variants
>   drm/i915/bxt: Use correct live status register for BXT platform
> 
>  drivers/gpu/drm/i915/intel_display.c |  45 
>  drivers/gpu/drm/i915/intel_dp.c  | 199 
> +--
>  drivers/gpu/drm/i915/intel_drv.h |   2 -
>  3 files changed, 145 insertions(+), 101 deletions(-)
> 
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] drm/i915: Check DP link status on long hpd too

[Daniel Vetter]

On Fri, Aug 21, 2015 at 09:40:12AM +0300, Jani Nikula wrote:
> On Thu, 20 Aug 2015, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > We are no longer checkling the DP link status on long hpd. We used to do
> > that from the .hot_plug() handler, but it was removed when MST got
> > introduced.
> >
> > If there's no userspace we now fail to retrain the link if the sink
> > power is toggled (or cable yanked and replugged), meaning the user is
> > left staring at a blank screen. With the retraining put back that should
> > be fixed.
> >
> > Also remove the leftover comment that referred to the old retraining
> > from .hot_plug().
> >
> > Fixes a regression introduced in:
> > commit 0e32b39ceed665bfa4a77a4bc307b6652b991632
> > Author: Dave Airlie 
> > Date:   Fri May 2 14:02:48 2014 +1000
> >
> > drm/i915: add DP 1.2 MST support (v0.7)
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89453
> 
> Tested-by: Palmer Dabbelt 

Reviewed-by: Daniel Vetter 

> 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91407
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89461
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89594
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85641
> > Cc: Dave Airlie 
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 11 +--
> >  1 file changed, 5 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index d32ce48..b014158 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -5024,9 +5024,12 @@ intel_dp_hpd_pulse(struct intel_digital_port 
> > *intel_dig_port, bool long_hpd)
> >  
> > intel_dp_probe_oui(intel_dp);
> >  
> > -   if (!intel_dp_probe_mst(intel_dp))
> > +   if (!intel_dp_probe_mst(intel_dp)) {
> > +   drm_modeset_lock(&dev->mode_config.connection_mutex, 
> > NULL);
> > +   intel_dp_check_link_status(intel_dp);
> > +   drm_modeset_unlock(&dev->mode_config.connection_mutex);
> > goto mst_fail;
> > -
> > +   }
> > } else {
> > if (intel_dp->is_mst) {
> > if (intel_dp_check_mst_status(intel_dp) == -EINVAL)
> > @@ -5034,10 +5037,6 @@ intel_dp_hpd_pulse(struct intel_digital_port 
> > *intel_dig_port, bool long_hpd)
> > }
> >  
> > if (!intel_dp->is_mst) {
> > -   /*
> > -* we'll check the link status via the normal hot plug 
> > path later -
> > -* but for short hpds we should check it now
> > -*/
> > drm_modeset_lock(&dev->mode_config.connection_mutex, 
> > NULL);
> > intel_dp_check_link_status(intel_dp);
> > drm_modeset_unlock(&dev->mode_config.connection_mutex);
> > -- 
> > 2.4.6
> >
> > ___
> > 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

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

Re: [Intel-gfx] [PATCH] drm/i915: Use dpcd read wake for sink crc calls.

[Daniel Vetter]

On Thu, Aug 20, 2015 at 04:12:00PM -0700, Rodrigo Vivi wrote:
> From: Rodrigo Vivi 
> 
> Let's use a native read with retry as suggested per spec to
> fix Sink CRC on SKL when PSR is enabled.
> 
> With PSR enabled panel is probably taking more time to wake
> and dpcd read is faling.
> 
> Cc: Sonika Jindal 
> Signed-off-by: Rodrigo Vivi 

Seems like we should just move the trickery we do in our own version into
the dp helpers in the core if this is needed all over the place?

At least in i915 we use it everywhere and it doesn't seem actively harmful
really ... Maybe the only exception would be the i2c-over-dp_aux code.
-Daniel
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index d32ce48..34f5e33 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4037,7 +4037,8 @@ static int intel_dp_sink_crc_stop(struct intel_dp 
> *intel_dp)
>   u8 buf;
>   int ret = 0;
>  
> - if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK, &buf) < 0) {
> + if (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_TEST_SINK,
> + &buf, 1) < 0) {
>   DRM_DEBUG_KMS("Sink CRC couldn't be stopped properly\n");
>   ret = -EIO;
>   goto out;
> @@ -4069,7 +4070,8 @@ static int intel_dp_sink_crc_start(struct intel_dp 
> *intel_dp)
>   return ret;
>   }
>  
> - if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK_MISC, &buf) < 0)
> + if (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_TEST_SINK_MISC,
> + &buf, 1) < 0)
>   return -EIO;
>  
>   if (!(buf & DP_TEST_CRC_SUPPORTED))
> @@ -4077,7 +4079,7 @@ static int intel_dp_sink_crc_start(struct intel_dp 
> *intel_dp)
>  
>   intel_dp->sink_crc.last_count = buf & DP_TEST_COUNT_MASK;
>  
> - if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK, &buf) < 0)
> + if (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_TEST_SINK, &buf, 1) < 0)
>   return -EIO;
>  
>   hsw_disable_ips(intel_crtc);
> @@ -4109,8 +4111,8 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 
> *crc)
>   do {
>   intel_wait_for_vblank(dev, intel_crtc->pipe);
>  
> - if (drm_dp_dpcd_readb(&intel_dp->aux,
> -   DP_TEST_SINK_MISC, &buf) < 0) {
> + if (intel_dp_dpcd_read_wake(&intel_dp->aux,
> + DP_TEST_SINK_MISC, &buf, 1) < 0) {
>   ret = -EIO;
>   goto stop;
>   }
> @@ -4123,7 +4125,8 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 
> *crc)
>   if (count == 0)
>   intel_dp->sink_crc.last_count = 0;
>  
> - if (drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_CRC_R_CR, crc, 6) 
> < 0) {
> + if (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_TEST_CRC_R_CR,
> + crc, 6) < 0) {
>   ret = -EIO;
>   goto stop;
>   }
> -- 
> 2.1.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH v5 1/4] drm/i915: Add audio sync_audio_rate callback

[Daniel Vetter]

On Wed, Aug 26, 2015 at 08:29:09AM +, Yang, Libin wrote:
> Hi Daniel,
> 
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> > Daniel Vetter
> > Sent: Wednesday, August 26, 2015 4:18 PM
> > To: Yang, Libin
> > Cc: alsa-de...@alsa-project.org; ti...@suse.de; intel-
> > g...@lists.freedesktop.org; daniel.vet...@ffwll.ch;
> > jani.nik...@linux.intel.com
> > Subject: Re: [PATCH v5 1/4] drm/i915: Add audio sync_audio_rate
> > callback
> > 
> > On Tue, Aug 18, 2015 at 02:51:51PM +0800, libin.y...@intel.com
> > wrote:
> > > From: Libin Yang 
> > >
> > > Add the sync_audio_rate callback.
> > >
> > > With the callback, audio driver can trigger
> > > i915 driver to set the proper N/CTS or N/M
> > > based on different sample rates.
> > >
> > > Signed-off-by: Libin Yang 
> > > ---
> > >  include/drm/i915_component.h | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/include/drm/i915_component.h
> > b/include/drm/i915_component.h
> > > index c9a8b64..aabebcb 100644
> > > --- a/include/drm/i915_component.h
> > > +++ b/include/drm/i915_component.h
> > > @@ -33,6 +33,7 @@ struct i915_audio_component {
> > >   void (*put_power)(struct device *);
> > >   void (*codec_wake_override)(struct device *, bool
> > enable);
> > >   int (*get_cdclk_freq)(struct device *);
> > > + int (*sync_audio_rate)(struct device *, int port, int
> > rate);
> > 
> > We're missing kerneldoc for this entire struct here, which isn't great.
> > This needs to be fixed. Please
> > - pull out the ops structure so it's not inlined (kerneldoc can't handle
> >   nested ops structures).
> > - please document all the callbacks with kerneldoc. In 4.3 we can have
> >   kerneldoc in-line in structures right above each member like this
> > 
> >   /**
> >* @put_power:
> >*
> >* Longer text explaining this hook.
> >*/
> >   void (*put_power)(struct device *);
> > 
> >   For each hook please explain at least who calls it (gfx or audio) and
> >   where exactly it's called in the overall flow.
> > - Extended the overview doc section with references to the
> > component/ops
> >   structure would be needed too.
> > 
> > And please make sure it all looks pretty with make htmldocs.
> 
> Could we start another patch session for this task because,
> as you know, this is a little independent on these patches?
> What do you think?

Nowadays I want proper docs for new features, and for places where we
missed them thus far they need to be backfilled. Also there's some good
confusion in the review about how this all works together, so better docs
seem called for no matter what to get this in. Instead of just adding all
the explanations to commit messages only I figured it's better to do them
as kerneldoc.
-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

Re: [Intel-gfx] [PATCH 4/7] drm/i915: PSR: Mask LPSP hw tracking back again.

[Daniel Vetter]

On Thu, Aug 20, 2015 at 05:55:41PM -0700, Rodrigo Vivi wrote:
> At the beginning it was masked to allow PSR at all.
> Than it got removed later by my
> commit 09108b90f040 ("drm/i915: PSR: Remove Low Power HW tracking mask.")
> in order to trying fixing one case reported at intel-gfx mailing list
> where we were missing screen updates when runtime_pm was enabled.
> 
> However I verified that other patch that makes flush to force
> invalidate also fixes this issue by itself.
> commit 169de1316c1e ("drm/i915: PSR: Flush means invalidate + flush")
> 
> Mainly now that we are relying more on frontbuffer tracking it is a
> good idea to mask this hw tracking again.
> 
> But besides all this above it is important to hightligh that with LPSP
> unmasked we started seeing some screen freezings as reported at fd.o.
> 
> This patch fixes the unrecoverable frozen screens reported:
> 
> Reference: https://bugs.freedesktop.org/show_bug.cgi?id=91436
> Reference: https://bugs.freedesktop.org/show_bug.cgi?id=91437
> 
> Cc: Ivan Mitev 
> Signed-off-by: Rodrigo Vivi 

Not sure whether you missed it, but did you look into pipe A interrupts
when the screen freezes? Apparently we should try to do manual link
training in that case, and failing to do so with a PSR panel pretty much
fits the description of frozen panel.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_psr.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 63bbab2..d02d4e2 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -398,9 +398,14 @@ void intel_psr_enable(struct intel_dp *intel_dp)
>   skl_psr_setup_su_vsc(intel_dp);
>   }
>  
> - /* Avoid continuous PSR exit by masking memup and hpd */
> + /*
> +  * Per Spec: Avoid continuous PSR exit by masking MEMUP and HPD.
> +  * Also mask LPSP to avoid dependency on other drivers that
> +  * might block runtime_pm besides preventing other hw tracking
> +  * issues now we can rely on frontbuffer tracking.
> +  */
>   I915_WRITE(EDP_PSR_DEBUG_CTL(dev), EDP_PSR_DEBUG_MASK_MEMUP |
> -EDP_PSR_DEBUG_MASK_HPD);
> +EDP_PSR_DEBUG_MASK_HPD | EDP_PSR_DEBUG_MASK_LPSP);
>  
>   /* Enable PSR on the panel */
>   hsw_psr_enable_sink(intel_dp);
> -- 
> 2.4.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] drm/i915: Flush pipecontrol post-sync writes

[Daniel Vetter]

On Fri, Aug 21, 2015 at 04:08:41PM +0100, Chris Wilson wrote:
> In order to flush the results from in-batch pipecontrol writes (used for
> example in glQuery) before declaring the batch complete (and so declaring
> the query results coherent), we need to set the FlushEnable bit in our
> flushing pipecontrol. The FlushEnable bit "waits until all previous
> writes of immediate data from post-sync circles are complete before
> executing the next command".
> 
> Signed-off-by: Chris Wilson 
> Cc: sta...@vger.kernel.org

Do we have an igt/piglit failing somewhere (igt kinda preferred) or a
bugzilla or why is this cc: stable?
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_lrc.c| 1 +
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 2 ++
>  2 files changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 01cf0ca21990..e0c19d75b196 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1771,6 +1771,7 @@ static int gen8_emit_flush_render(struct 
> drm_i915_gem_request *request,
>   if (flush_domains) {
>   flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
>   flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
> + flags |= PIPE_CONTROL_FLUSH_ENABLE;
>   }
>  
>   if (invalidate_domains) {
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index c2392f6c4204..551af7399ca1 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -330,6 +330,7 @@ gen7_render_ring_flush(struct drm_i915_gem_request *req,
>   if (flush_domains) {
>   flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
>   flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
> + flags |= PIPE_CONTROL_FLUSH_ENABLE;
>   }
>   if (invalidate_domains) {
>   flags |= PIPE_CONTROL_TLB_INVALIDATE;
> @@ -401,6 +402,7 @@ gen8_render_ring_flush(struct drm_i915_gem_request *req,
>   if (flush_domains) {
>   flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
>   flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
> + flags |= PIPE_CONTROL_FLUSH_ENABLE;
>   }
>   if (invalidate_domains) {
>   flags |= PIPE_CONTROL_TLB_INVALIDATE;
> -- 
> 2.5.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Make some string arrays const

[Daniel Vetter]

On Fri, Aug 21, 2015 at 06:50:03PM +0100, Chris Wilson wrote:
> On Fri, Aug 21, 2015 at 08:45:29PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > Most of our char* arrays are markes as const already, but a few slipped
> > through the cracks. Fix it.
> > 
> > Signed-off-by: Ville Syrjälä 
> 
> All 3, Reviewed-by: Chris Wilson 

All merged to dinq, thanks.
-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

Re: [Intel-gfx] [PATCH 0/3] Reduce the time for which 'struct_mutex' is held

[Daniel Vetter]

On Mon, Aug 24, 2015 at 05:28:13PM +0530, ankitprasad.r.sha...@intel.com wrote:
> From: Ankitprasad Sharma 
> 
> We are trying to reduce the time for which the global 'struct_mutex'
> is locked. Execbuffer ioctl is one place where it is generally held
> for the longest time. And sometimes because of this occasional 
> glitches/flickers are observed in 60 fps playback (due to miss of
> V-blank intervals) as page flip calls gets blocked/delayed because the
> 'struct_mutex' is already locked.
> 
> For this, we have exposed two new flags in GEM_CREATE ioctl, to pre-populate
> the object with system memory pages and also do an immediate clflush for the
> new pages.
> 
> The third patch too tries to reduce the 'struct_mutex' lock time by
> moving only those objects to CPU domain in put_pages(), that can either
> be used in the future or had a CPU mapping.
> 
> This series is based on an earlier series of Stolen Memory patches,
> extending the GEM_CREATE ioctl further
> http://lists.freedesktop.org/archives/intel-gfx/2015-July/072199.html
> 
> Ankitprasad Sharma (2):
>   drm/i915: Support for pre-populating the object with system pages
>   drm/i915: Support for the clflush of pre-populated pages
> 
> Chris Wilson (1):
>   drm/i915: Only move to the CPU write domain if keeping the GTT pages

Usual broken maintainer record: Needs igt and userspace. And for the case
of the put_pages optimization probably really nasty igt.
-Daniel

> 
>  drivers/gpu/drm/i915/i915_dma.c |   2 +-
>  drivers/gpu/drm/i915/i915_drv.h |   5 ++
>  drivers/gpu/drm/i915/i915_gem.c | 116 
> ++--
>  include/uapi/drm/i915_drm.h |  12 ++---
>  4 files changed, 101 insertions(+), 34 deletions(-)
> 
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Increase maximum polling time to 50ms for forcewake request/clear ack

[Daniel Vetter]

On Sun, Aug 23, 2015 at 05:52:47PM +0530, Sagar Arun Kamble wrote:
> On BXT, We Observe timeout for forcewake request completion with 2ms polling 
> period as given here:
> [drm:fw_domains_get] ERROR render: timed out waiting for forcewake ack 
> request.
> Polling for 50ms is recommended to avoid these timeouts.
> 
> Change-Id: Ie715b0069a3049606e9602bc5e97a6511890864d
> Signed-off-by: Sagar Arun Kamble 

Probably needs cc: stable plus a pile of bugzilla links all over ...
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_uncore.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 9d3c2e4..2df03b1 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -27,7 +27,7 @@
>  
>  #include 
>  
> -#define FORCEWAKE_ACK_TIMEOUT_MS 2
> +#define FORCEWAKE_ACK_TIMEOUT_MS 50
>  
>  #define __raw_i915_read8(dev_priv__, reg__) readb((dev_priv__)->regs + 
> (reg__))
>  #define __raw_i915_write8(dev_priv__, reg__, val__) writeb(val__, 
> (dev_priv__)->regs + (reg__))
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] drm/i915: Flush pipecontrol post-sync writes

[Chris Wilson]

On Wed, Aug 26, 2015 at 11:16:34AM +0200, Daniel Vetter wrote:
> On Fri, Aug 21, 2015 at 04:08:41PM +0100, Chris Wilson wrote:
> > In order to flush the results from in-batch pipecontrol writes (used for
> > example in glQuery) before declaring the batch complete (and so declaring
> > the query results coherent), we need to set the FlushEnable bit in our
> > flushing pipecontrol. The FlushEnable bit "waits until all previous
> > writes of immediate data from post-sync circles are complete before
> > executing the next command".
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: sta...@vger.kernel.org
> 
> Do we have an igt/piglit failing somewhere (igt kinda preferred) or a
> bugzilla or why is this cc: stable?

I get GPU hangs on byt without flushing these writes (running ue4).
piglit has examples where the flush is required for correct rendering.
-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 4/5] Documentation: drm: Convert KMS Properties HTML table to CALS

[Daniel Vetter]

On Tue, Aug 25, 2015 at 05:10:54PM +0100, Graham Whaley wrote:
> On Tue, 2015-08-25 at 16:29 +0200, Daniel Vetter wrote:
> > On Tue, Aug 25, 2015 at 10:26:44AM +0100, Graham Whaley wrote:
> > > The KMS Properties table is in HTML format, which is not supported
> > > for building pdfdocs, resulting in the following types of errors:
> > > 
> > >  jade:/Documentation/DocBook/drm.xml:34413:15:E: there is no
> > > attribute
> > >  "border"
> > >  jade:/Documentation/DocBook/drm.xml:34413:31:E: there is no
> > > attribute
> > >  "cellpadding"
> > >  jade:/Documentation/DocBook/drm.xml:34413:47:E: there is no
> > > attribute
> > >  "cellspacing"
> > >  jade:/Documentation/DocBook/drm.xml:34414:7:E: document type does
> > > not
> > >  allow element "tbody" here
> > > 
> > > Convert the table over to a CALS format table
> > 
> > Hm, long-term plan was to move this table into DOC: comments in the
> > source-code using markdown, which we now have (at least in
> > drm-intel-nightly and also planned to be merged into 4.4). Since this
> > is
> > both a lot of churn I'd like to get there in just 1 step ...
> > -Daniel
> First - I've just noted an erroneous debug comment (or two) left in
> this patch as well, so looks like I will have to re-issue the series
> anyway.
> 
> OK. I guess this comes down to a matter of timing...
> From Danilos patch of: f6d6913 (drm/doc: Convert to markdown)
> we can see markdown does not natively support tables, and we'd have to
> make this a fixed width layout like the one in that patch I suspect.
> Danilo - any advice on how you did that other table conversion? I just
> did a pandoc docbook->markdown_github and it looks some way there - but
> of course seems to have not honored the multi-column items, of which
> there are a few. It's probably not too bad to fix up by hand - I'll see
> if I can get that to work...
> Any clue to where in the source file DOC: sections it would want to
> live if I get it formatted - I don't see an obvious !include near the
> table in the .tmpl file to piggyback.

Yeah it's a bit more involved and probably a bigger series. We might even
want to split up this table into per-feature stuff since the current one
doesn't really scale. Otoh that can be done later on.

What I'd do is split it into sections (generic, i915, ...) so that we can
avoid the row-spanning as much as possible, and then just place it
somewhere into drm_crtc.c - that's the grab-bag for all things modeset
(which properties are a part of). Maybe longer-term we want to split out a
drm_properties.c or something like that with the pile of support code we
have already, plus this kerneldoc.
-Daniel
> 
> Graham
> > 
> > > 
> > > Signed-off-by: Graham Whaley 
> > > ---
> > >  Documentation/DocBook/drm.tmpl | 1866 
> > > 
> > >  1 file changed, 937 insertions(+), 929 deletions(-)
> > > 
> > > diff --git a/Documentation/DocBook/drm.tmpl
> > > b/Documentation/DocBook/drm.tmpl
> > > index 2e05a79..e5bfdd8 100644
> > > --- a/Documentation/DocBook/drm.tmpl
> > > +++ b/Documentation/DocBook/drm.tmpl
> > > @@ -2580,935 +2580,943 @@ void intel_crt_init(struct drm_device
> > > *dev)
> > >and an initial instance value.
> > >  
> > >  
> > > - Existing KMS Properties
> > > - 
> > > - The following table gives description of drm properties
> > > exposed by various
> > > - modules/drivers.
> > > - 
> > > - 
> > > - 
> > > - 
> > > - Owner Module/Drivers
> > > - Group
> > > - Property Name
> > > - Type
> > > - Property Values
> > > - Object attached
> > > - Description/Restrictions
> > > - 
> > > - 
> > > - DRM
> > > - Generic
> > > - “rotation”
> > > - BITMASK
> > > - { 0, "rotate-0" },
> > > - { 1, "rotate-90" },
> > > - { 2, "rotate-180" },
> > > - { 3, "rotate-270" },
> > > - { 4, "reflect-x" },
> > > - { 5, "reflect-y" }
> > > - CRTC, Plane
> > > - rotate-(degrees) rotates the image by
> > > the specified amount in degrees
> > > - in counter clockwise direction. reflect-x and reflect-y
> > > reflects the
> > > - image along the specified axis prior to rotation
> > > - 
> > > - 
> > > - Connector
> > > - “EDID”
> > > - BLOB | IMMUTABLE
> > > - 0
> > > - Connector
> > > - Contains id of edid blob ptr
> > > object.
> > > - 
> > > - 
> > > - “DPMS”
> > > - ENUM
> > > - { “On”, “Standby”, “Suspend”, “Off”
> > > }
> > > - Connector
> > > - Contains DPMS operation mode value.
> > > - 
> > > - 
> > > - “PATH”
> > > - BLOB | IMMUTABLE
> > > - 0
> > > - Connector
> > > - Contains topology path to a
> > > connector.
> > > - 
> > > - 
> > > - “TILE”
> > > - BLOB | IMMUTABLE
> > > - 0
> > > - Connector
> > > - Contains tiling information for a
> > > connector.
> > > - 
> > > - 
> > > - “CRTC_ID”
> > > - OBJECT
> > > - DRM_MODE_OBJECT_CRTC
> > > - Connector
> > > - CRTC that connector is attached to
> > > (atomic)
> > > - 
> > > - 
> > > - Plane
> > > - “type”
> > > - ENUM | IMMUTABLE
> > > - { "Overlay", "Primary", "Cursor" }
> > > - Plane
> > > - Plane type
> > > - 
> > >

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Retry for live status

[Daniel Vetter]

On Tue, Aug 25, 2015 at 05:31:33PM +0530, Sonika Jindal wrote:
> Some monitors take time in setting the live status.
> So retry for few times if this is a connect HPD
> 
> Signed-off-by: Sonika Jindal 

Why was this bugfix not part of the original series? Now I have to retest
on my ivb to figure out whether maybe this one here is the issue ...

Also how exactly does this work? I thought the hpd bits control whether we
get an interrupt, not the other way round? Why exactly does this help?
Definitely needs a lot more explanation.

Also this seems to break bisect, since before the preceeding patch to
check hpd status we just retried edid reading for a while.

This kind of hacking doesn't really convince me that hpd status is
working, just that our own testing isn't good enough to catch all
real-world issues.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_hdmi.c |   15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 59518b4..239d70d 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1415,6 +1415,7 @@ void intel_hdmi_probe(struct intel_encoder 
> *intel_encoder)
>   struct intel_connector *intel_connector =
>   intel_hdmi->attached_connector;
>   bool live_status = false;
> + unsigned int retry = 3;
>  
>   /*
>* Sometimes DDI ports are enumerated as DP as well as HDMI and
> @@ -1425,6 +1426,20 @@ void intel_hdmi_probe(struct intel_encoder 
> *intel_encoder)
>   return;
>  
>   live_status = intel_hdmi_live_status(hdmi_to_dig_port(intel_hdmi));
> + if (!intel_connector->detect_edid && live_status == false) {
> + /*
> +  * Hotplug had occurred and old status was disconnected,
> +  * so it might be possible that live status is not set,
> +  * so retry for few times
> +  */
> + do {
> + mdelay(10);
> + live_status = 
> intel_hdmi_live_status(hdmi_to_dig_port(intel_hdmi));
> + if (live_status)
> + break;
> + } while (retry--);
> + }
> +
>   /*
>* We are here, means there is a hotplug or a force
>* detection. Clear the cached EDID and probe the
> -- 
> 1.7.10.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915: read sink_count dpcd always

[Jani Nikula]

On Tue, 25 Aug 2015, Sivakumar Thulasimani  
wrote:
> From: "Thulasimani,Sivakumar" 
>
> This patch reads sink_count dpcd always and removes its
> read operation based on values in downstream port dpcd. Also
> we should read it irrespective of current status of sink.

Having to write "also" in a commit message is a good hint to stop and
think about whether that should be a separate patch. Maybe it should be,
here too?

BR,
Jani.

>
> SINK_COUNT dpcd is not dependent on DOWNSTREAM_PORT_PRESENT dpcd.
> SINK_COUNT denotes if a display is attached, while
> DOWNSTREAM_PORT_PRESET indicates how many ports are available
> in the dongle where display can be attached. so it is possible
> for sink count to change irrespective of value in downstream
> port dpcd.
>
> Here is a table of possible values and scenarios
>
> sink_countdownstream_port
>   present
> 0 0   no display is attached
> 0 1   dongle is connected without display
> 1 0   display connected directly
> 1 1   display connected through dongle
>
> Signed-off-by: Sivakumar Thulasimani 
> ---
>  drivers/gpu/drm/i915/intel_dp.c |   33 ++---
>  1 file changed, 14 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 8a66a44..9e4e27d 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3898,6 +3898,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>   struct drm_device *dev = dig_port->base.base.dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   uint8_t rev;
> + uint8_t reg;
>  
>   if (intel_dp_dpcd_read_wake(&intel_dp->aux, 0x000, intel_dp->dpcd,
>   sizeof(intel_dp->dpcd)) < 0)
> @@ -3908,6 +3909,13 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>   if (intel_dp->dpcd[DP_DPCD_REV] == 0)
>   return false; /* DPCD not present */
>  
> + if (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_SINK_COUNT,
> + ®, 1) < 0)
> + return false;
> +
> + if (!DP_GET_SINK_COUNT(reg))
> + return false;
> +
>   /* Check if the panel supports PSR */
>   memset(intel_dp->psr_dpcd, 0, sizeof(intel_dp->psr_dpcd));
>   if (is_edp(intel_dp)) {
> @@ -4374,12 +4382,6 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
>  
>   WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
>  
> - if (!intel_encoder->base.crtc)
> - return;
> -
> - if (!to_intel_crtc(intel_encoder->base.crtc)->active)
> - return;
> -
>   /* Try to read receiver status if the link appears to be up */
>   if (!intel_dp_get_link_status(intel_dp, link_status)) {
>   return;
> @@ -4390,6 +4392,12 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
>   return;
>   }
>  
> + if (!intel_encoder->base.crtc)
> + return;
> +
> + if (!to_intel_crtc(intel_encoder->base.crtc)->active)
> + return;
> +
>   /* 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)) {
> @@ -4427,19 +4435,6 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
>   if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
>   return connector_status_connected;
>  
> - /* If we're HPD-aware, SINK_COUNT changes dynamically */
> - if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
> - intel_dp->downstream_ports[0] & DP_DS_PORT_HPD) {
> - uint8_t reg;
> -
> - if (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_SINK_COUNT,
> - ®, 1) < 0)
> - return connector_status_unknown;
> -
> - return DP_GET_SINK_COUNT(reg) ? connector_status_connected
> -   : connector_status_disconnected;
> - }
> -
>   /* If no HPD, poke DDC gently */
>   if (drm_probe_ddc(&intel_dp->aux.ddc))
>   return connector_status_connected;
> -- 
> 1.7.9.5
>

-- 
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: force full detect on sink count change

[Jani Nikula]

On Tue, 25 Aug 2015, Sivakumar Thulasimani  
wrote:
> From: "Thulasimani,Sivakumar" 
>
> This patch checks for changes in sink count between short pulse
> hpds and forces full detect when there is a change. This will
> result in compliance test case 4.2.2.8 passing since it tests
> for this behavior.
>
> This will allow both detection of hotplug and unplug of panels
> through dongles that give only short pulse for such events.
>
> Signed-off-by: Sivakumar Thulasimani 
> ---
>  drivers/gpu/drm/i915/intel_dp.c |   20 
>  1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 834f513..eb3ab41 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4370,26 +4370,34 @@ go_again:
>   *  4. Check link status on receipt of hot-plug interrupt
>   */
>  static void
> -intel_dp_check_link_status(struct intel_dp *intel_dp)
> +intel_dp_check_link_status(struct intel_dp *intel_dp, bool 
> *perform_full_detect)

You could turn perform_full_detect into a boolean return value which
this function doesn't have.

>  {
>   struct drm_device *dev = intel_dp_to_dev(intel_dp);
>   struct intel_encoder *intel_encoder = &dp_to_dig_port(intel_dp)->base;
>   struct intel_crtc *crtc =
>   to_intel_crtc(dp_to_dig_port(intel_dp)->base.base.crtc);
>   u8 sink_irq_vector;
> + u8 old_sink_count = intel_dp->sink_count;
> + u8 ret;

Isn't this a bool, really?

>   u8 link_status[DP_LINK_STATUS_SIZE];
>  
>   WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
>  
> + *perform_full_detect = false;
> +
>   /* Try to read receiver status if the link appears to be up */
>   if (!intel_dp_get_link_status(intel_dp, link_status)) {
>   return;
>   }
>  
>   /* Now read the DPCD to see if it's actually running */
> - if (!intel_dp_get_dpcd(intel_dp)) {
> + ret = intel_dp_get_dpcd(intel_dp);
> +
> + if (old_sink_count != intel_dp->sink_count)
> + *perform_full_detect = true;

Can't trust intel_dp->sink_count without checking the return value. So I
guess you can call intel_dp_get_dpcd the way it's done now, and move the
sink count check below it.

BR,
Jani.

> +
> + if (!ret)
>   return;
> - }
>  
>   if (!intel_encoder->base.crtc)
>   return;
> @@ -5031,13 +5039,17 @@ intel_dp_hpd_pulse(struct intel_digital_port 
> *intel_dig_port, bool long_hpd)
>   }
>  
>   if (!intel_dp->is_mst) {
> + bool full_detect;
>   /*
>* we'll check the link status via the normal hot plug 
> path later -
>* but for short hpds we should check it now
>*/
>   drm_modeset_lock(&dev->mode_config.connection_mutex, 
> NULL);
> - intel_dp_check_link_status(intel_dp);
> + intel_dp_check_link_status(intel_dp, &full_detect);
>   drm_modeset_unlock(&dev->mode_config.connection_mutex);
> +
> + if (full_detect)
> + goto put_power;
>   }
>   }
>  
> -- 
> 1.7.9.5
>

-- 
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/4] drm/i915: Retry for live status

[Jindal, Sonika]

HPD bits control the interrupt but the live status (with some monitors) takes 
time to get set.
We had experienced this with VLV and CHV with few monitors.
So Android code always has this retry for live status.

Yes, this was not added in the previous series because we planned to add the 
next set of optimization a little while later.
But this seems to be an important one.

It will be great if you can try it with your ivb. But for that you would need 
to first change the gen check and add a call to check live status for ivb.

Regards,
Sonika
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Wednesday, August 26, 2015 3:10 PM
To: Jindal, Sonika
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 4/4] drm/i915: Retry for live status

On Tue, Aug 25, 2015 at 05:31:33PM +0530, Sonika Jindal wrote:
> Some monitors take time in setting the live status.
> So retry for few times if this is a connect HPD
> 
> Signed-off-by: Sonika Jindal 

Why was this bugfix not part of the original series? Now I have to retest on my 
ivb to figure out whether maybe this one here is the issue ...

Also how exactly does this work? I thought the hpd bits control whether we get 
an interrupt, not the other way round? Why exactly does this help?
Definitely needs a lot more explanation.

Also this seems to break bisect, since before the preceeding patch to check hpd 
status we just retried edid reading for a while.

This kind of hacking doesn't really convince me that hpd status is working, 
just that our own testing isn't good enough to catch all real-world issues.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_hdmi.c |   15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 59518b4..239d70d 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1415,6 +1415,7 @@ void intel_hdmi_probe(struct intel_encoder 
> *intel_encoder)
>   struct intel_connector *intel_connector =
>   intel_hdmi->attached_connector;
>   bool live_status = false;
> + unsigned int retry = 3;
>  
>   /*
>* Sometimes DDI ports are enumerated as DP as well as HDMI and @@ 
> -1425,6 +1426,20 @@ void intel_hdmi_probe(struct intel_encoder *intel_encoder)
>   return;
>  
>   live_status = intel_hdmi_live_status(hdmi_to_dig_port(intel_hdmi));
> + if (!intel_connector->detect_edid && live_status == false) {
> + /*
> +  * Hotplug had occurred and old status was disconnected,
> +  * so it might be possible that live status is not set,
> +  * so retry for few times
> +  */
> + do {
> + mdelay(10);
> + live_status = 
> intel_hdmi_live_status(hdmi_to_dig_port(intel_hdmi));
> + if (live_status)
> + break;
> + } while (retry--);
> + }
> +
>   /*
>* We are here, means there is a hotplug or a force
>* detection. Clear the cached EDID and probe the
> --
> 1.7.10.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915: read sink_count dpcd always

[Sivakumar Thulasimani]

On 8/26/2015 3:17 PM, Jani Nikula wrote:

On Tue, 25 Aug 2015, Sivakumar Thulasimani  
wrote:

From: "Thulasimani,Sivakumar" 

This patch reads sink_count dpcd always and removes its
read operation based on values in downstream port dpcd. Also
we should read it irrespective of current status of sink.

Having to write "also" in a commit message is a good hint to stop and
think about whether that should be a separate patch. Maybe it should be,
here too?

BR,
Jani.

:) i thought about it since that part of the message was added last, since
without those changes this patch will not be "read sink_count always".

will split it into two patches and rename them accordingly.

SINK_COUNT dpcd is not dependent on DOWNSTREAM_PORT_PRESENT dpcd.
SINK_COUNT denotes if a display is attached, while
DOWNSTREAM_PORT_PRESET indicates how many ports are available
in the dongle where display can be attached. so it is possible
for sink count to change irrespective of value in downstream
port dpcd.

Here is a table of possible values and scenarios

sink_count  downstream_port
present
0   0   no display is attached
0   1   dongle is connected without display
1   0   display connected directly
1   1   display connected through dongle

Signed-off-by: Sivakumar Thulasimani 
---
  drivers/gpu/drm/i915/intel_dp.c |   33 ++---
  1 file changed, 14 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8a66a44..9e4e27d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3898,6 +3898,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
struct drm_device *dev = dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
uint8_t rev;
+   uint8_t reg;
  
  	if (intel_dp_dpcd_read_wake(&intel_dp->aux, 0x000, intel_dp->dpcd,

sizeof(intel_dp->dpcd)) < 0)
@@ -3908,6 +3909,13 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
if (intel_dp->dpcd[DP_DPCD_REV] == 0)
return false; /* DPCD not present */
  
+	if (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_SINK_COUNT,

+   ®, 1) < 0)
+   return false;
+
+   if (!DP_GET_SINK_COUNT(reg))
+   return false;
+
/* Check if the panel supports PSR */
memset(intel_dp->psr_dpcd, 0, sizeof(intel_dp->psr_dpcd));
if (is_edp(intel_dp)) {
@@ -4374,12 +4382,6 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
  
  	WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
  
-	if (!intel_encoder->base.crtc)

-   return;
-
-   if (!to_intel_crtc(intel_encoder->base.crtc)->active)
-   return;
-
/* Try to read receiver status if the link appears to be up */
if (!intel_dp_get_link_status(intel_dp, link_status)) {
return;
@@ -4390,6 +4392,12 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
return;
}
  
+	if (!intel_encoder->base.crtc)

+   return;
+
+   if (!to_intel_crtc(intel_encoder->base.crtc)->active)
+   return;
+
/* 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)) {
@@ -4427,19 +4435,6 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
return connector_status_connected;
  
-	/* If we're HPD-aware, SINK_COUNT changes dynamically */

-   if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
-   intel_dp->downstream_ports[0] & DP_DS_PORT_HPD) {
-   uint8_t reg;
-
-   if (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_SINK_COUNT,
-   ®, 1) < 0)
-   return connector_status_unknown;
-
-   return DP_GET_SINK_COUNT(reg) ? connector_status_connected
- : connector_status_disconnected;
-   }
-
/* If no HPD, poke DDC gently */
if (drm_probe_ddc(&intel_dp->aux.ddc))
return connector_status_connected;
--
1.7.9.5



--
regards,
Sivakumar

___
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: force full detect on sink count change

[Sivakumar Thulasimani]

On 8/26/2015 3:32 PM, Jani Nikula wrote:

On Tue, 25 Aug 2015, Sivakumar Thulasimani  
wrote:

From: "Thulasimani,Sivakumar" 

This patch checks for changes in sink count between short pulse
hpds and forces full detect when there is a change. This will
result in compliance test case 4.2.2.8 passing since it tests
for this behavior.

This will allow both detection of hotplug and unplug of panels
through dongles that give only short pulse for such events.

Signed-off-by: Sivakumar Thulasimani 
---
  drivers/gpu/drm/i915/intel_dp.c |   20 
  1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 834f513..eb3ab41 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4370,26 +4370,34 @@ go_again:
   *  4. Check link status on receipt of hot-plug interrupt
   */
  static void
-intel_dp_check_link_status(struct intel_dp *intel_dp)
+intel_dp_check_link_status(struct intel_dp *intel_dp, bool 
*perform_full_detect)

You could turn perform_full_detect into a boolean return value which
this function doesn't have.

sure will do.



  {
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct intel_encoder *intel_encoder = &dp_to_dig_port(intel_dp)->base;
struct intel_crtc *crtc =
to_intel_crtc(dp_to_dig_port(intel_dp)->base.base.crtc);
u8 sink_irq_vector;
+   u8 old_sink_count = intel_dp->sink_count;
+   u8 ret;

Isn't this a bool, really?


u8 link_status[DP_LINK_STATUS_SIZE];
  
  	WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
  
+	*perform_full_detect = false;

+
/* Try to read receiver status if the link appears to be up */
if (!intel_dp_get_link_status(intel_dp, link_status)) {
return;
}
  
  	/* Now read the DPCD to see if it's actually running */

-   if (!intel_dp_get_dpcd(intel_dp)) {
+   ret = intel_dp_get_dpcd(intel_dp);
+
+   if (old_sink_count != intel_dp->sink_count)
+   *perform_full_detect = true;

Can't trust intel_dp->sink_count without checking the return value. So I
guess you can call intel_dp_get_dpcd the way it's done now, and move the
sink count check below it.

BR,
Jani.


sure will fix this.



+
+   if (!ret)
return;
-   }
  
  	if (!intel_encoder->base.crtc)

return;
@@ -5031,13 +5039,17 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
}
  
  		if (!intel_dp->is_mst) {

+   bool full_detect;
/*
 * we'll check the link status via the normal hot plug 
path later -
 * but for short hpds we should check it now
 */
drm_modeset_lock(&dev->mode_config.connection_mutex, 
NULL);
-   intel_dp_check_link_status(intel_dp);
+   intel_dp_check_link_status(intel_dp, &full_detect);
drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+   if (full_detect)
+   goto put_power;
}
}
  
--

1.7.9.5



--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH] intel-gpu-tools: Fixes-compiler-warnings-about-wrong-function-type

[Thomas Wood]

On 24 August 2015 at 10:59, Stefan Dirsch  wrote:
> Hi
>
> Find a simple buildfix against current intel-gpu-tools git sources attached.

I assume the compiler warning is about uninitialised values and unused
variables? It looks like the Makefile is not using the debug cflags so
these warning do not appear by default.

intel_null_state_gen.c appears to assume the
gen*_setup_null_render_state functions have return values in the
extern declarations, so this could do with fixing too.


>
> Thanks,
> Stefan
>
> Public Key available
> --
> Stefan Dirsch (Res. & Dev.)   SUSE LINUX GmbH
> Tel: 0911-740 53 0Maxfeldstraße 5
> FAX: 0911-740 53 479  D-90409 Nürnberg
> http://www.suse.deGermany
> ---
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham
> Norton, HRB 21284 (AG Nürnberg)
> ---
>
> ___
> 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 v5 1/4] drm/i915: Add audio sync_audio_rate callback

[Yang, Libin]

Hi Daniel,

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Wednesday, August 26, 2015 5:08 PM
> To: Yang, Libin
> Cc: Daniel Vetter; alsa-de...@alsa-project.org; ti...@suse.de; intel-
> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch;
> jani.nik...@linux.intel.com
> Subject: Re: [PATCH v5 1/4] drm/i915: Add audio sync_audio_rate
> callback
> 
> On Wed, Aug 26, 2015 at 08:29:09AM +, Yang, Libin wrote:
> > Hi Daniel,
> >
> > > -Original Message-
> > > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> > > Daniel Vetter
> > > Sent: Wednesday, August 26, 2015 4:18 PM
> > > To: Yang, Libin
> > > Cc: alsa-de...@alsa-project.org; ti...@suse.de; intel-
> > > g...@lists.freedesktop.org; daniel.vet...@ffwll.ch;
> > > jani.nik...@linux.intel.com
> > > Subject: Re: [PATCH v5 1/4] drm/i915: Add audio sync_audio_rate
> > > callback
> > >
> > > On Tue, Aug 18, 2015 at 02:51:51PM +0800, libin.y...@intel.com
> > > wrote:
> > > > From: Libin Yang 
> > > >
> > > > Add the sync_audio_rate callback.
> > > >
> > > > With the callback, audio driver can trigger
> > > > i915 driver to set the proper N/CTS or N/M
> > > > based on different sample rates.
> > > >
> > > > Signed-off-by: Libin Yang 
> > > > ---
> > > >  include/drm/i915_component.h | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/include/drm/i915_component.h
> > > b/include/drm/i915_component.h
> > > > index c9a8b64..aabebcb 100644
> > > > --- a/include/drm/i915_component.h
> > > > +++ b/include/drm/i915_component.h
> > > > @@ -33,6 +33,7 @@ struct i915_audio_component {
> > > > void (*put_power)(struct device *);
> > > > void (*codec_wake_override)(struct device *, bool
> > > enable);
> > > > int (*get_cdclk_freq)(struct device *);
> > > > +   int (*sync_audio_rate)(struct device *, int port, int
> > > rate);
> > >
> > > We're missing kerneldoc for this entire struct here, which isn't
> great.
> > > This needs to be fixed. Please
> > > - pull out the ops structure so it's not inlined (kerneldoc can't
> handle
> > >   nested ops structures).
> > > - please document all the callbacks with kerneldoc. In 4.3 we can
> have
> > >   kerneldoc in-line in structures right above each member like this
> > >
> > >   /**
> > >* @put_power:
> > >*
> > >* Longer text explaining this hook.
> > >*/
> > >   void (*put_power)(struct device *);
> > >
> > >   For each hook please explain at least who calls it (gfx or audio)
> and
> > >   where exactly it's called in the overall flow.
> > > - Extended the overview doc section with references to the
> > > component/ops
> > >   structure would be needed too.
> > >
> > > And please make sure it all looks pretty with make htmldocs.
> >
> > Could we start another patch session for this task because,
> > as you know, this is a little independent on these patches?
> > What do you think?
> 
> Nowadays I want proper docs for new features, and for places where
> we
> missed them thus far they need to be backfilled. Also there's some
> good
> confusion in the review about how this all works together, so better
> docs
> seem called for no matter what to get this in. Instead of just adding all
> the explanations to commit messages only I figured it's better to do
> them
> as kerneldoc.

Yes, I agree and I will add it for the sync_audio_rate function
in the next version.

Regards,
Libin

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

Re: [Intel-gfx] [PATCH 13/16] drm/i915: don't use the first stolen page on Broadwell

[Ville Syrjälä]

On Wed, Aug 26, 2015 at 09:48:51AM +0200, Daniel Vetter wrote:
> On Wed, Aug 19, 2015 at 02:55:34PM +0300, Ville Syrjälä wrote:
> > On Sat, Aug 15, 2015 at 09:30:18AM +0100, Chris Wilson wrote:
> > > On Fri, Aug 14, 2015 at 06:34:18PM -0300, Paulo Zanoni wrote:
> > > > The spec says we just can't use it.
> > > 
> > > But what about when we inherit a framebuffer at that address?
> > 
> > Indeed. I asked the same question several times during the past attempts
> > at this, and even tried to outline a potential solution at least once [1]
> 
> Paulo's only patching the insert_node_in_range allocator, for fbcon
> takeover we use reserve_node. I think this patch seems to do what you want
> it to do, no need for fancier schemes.

Hmm. Indeed. It's a somewhat surprising place to find such a check, but
it does solve the preallocated vs. normal issue. It does mean we may
end up with some corruption in the fbdev bo but I suppose that's short
lived enough that we can ignore it.

It could use a comment as to why we put the check there instead of
totally removing the first page from the stolen mm. Otherwise someone
might decide to clean it up and break things. Also lacking the w/a name
and some explanation why it's needed. And as I mentioned before, CHV
needs to be included. SKL/BXT only have it listed for early steppings,
so I think we can ignore those.

-- 
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 3/3] drm/i915: force full detect on sink count change

[Sivakumar Thulasimani]

On 8/26/2015 3:32 PM, Jani Nikula wrote:

On Tue, 25 Aug 2015, Sivakumar Thulasimani  
wrote:

From: "Thulasimani,Sivakumar" 

This patch checks for changes in sink count between short pulse
hpds and forces full detect when there is a change. This will
result in compliance test case 4.2.2.8 passing since it tests
for this behavior.

This will allow both detection of hotplug and unplug of panels
through dongles that give only short pulse for such events.

Signed-off-by: Sivakumar Thulasimani 
---
  drivers/gpu/drm/i915/intel_dp.c |   20 
  1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 834f513..eb3ab41 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4370,26 +4370,34 @@ go_again:
   *  4. Check link status on receipt of hot-plug interrupt
   */
  static void
-intel_dp_check_link_status(struct intel_dp *intel_dp)
+intel_dp_check_link_status(struct intel_dp *intel_dp, bool 
*perform_full_detect)

You could turn perform_full_detect into a boolean return value which
this function doesn't have.

ok thinking a few mins brings back the reason for this change :).

we return from this function for the following reasons,
> dpcd read failed
> sink count change
> crtc is not active
> ATR was requested and it was handled/ignored
> link status was good or if bad we retrained it.
and it might have passed or failed.

lets say i return true or false. what does that mean ?

i'll need full detection only if display was already present and is not 
anymore

which can be due to
 dpcd read failure while the display was enabled ? (basically sink 
count change from 1 to 0)

or sink count changed from 0 to 1.

so it is better to have an explicit parameter rather than




  {
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct intel_encoder *intel_encoder = &dp_to_dig_port(intel_dp)->base;
struct intel_crtc *crtc =
to_intel_crtc(dp_to_dig_port(intel_dp)->base.base.crtc);
u8 sink_irq_vector;
+   u8 old_sink_count = intel_dp->sink_count;
+   u8 ret;

Isn't this a bool, really?


u8 link_status[DP_LINK_STATUS_SIZE];
  
  	WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
  
+	*perform_full_detect = false;

+
/* Try to read receiver status if the link appears to be up */
if (!intel_dp_get_link_status(intel_dp, link_status)) {
return;
}
  
  	/* Now read the DPCD to see if it's actually running */

-   if (!intel_dp_get_dpcd(intel_dp)) {
+   ret = intel_dp_get_dpcd(intel_dp);
+
+   if (old_sink_count != intel_dp->sink_count)
+   *perform_full_detect = true;

Can't trust intel_dp->sink_count without checking the return value. So I
guess you can call intel_dp_get_dpcd the way it's done now, and move the
sink count check below it.

BR,
Jani.


+
+   if (!ret)
return;
-   }
  
  	if (!intel_encoder->base.crtc)

return;
@@ -5031,13 +5039,17 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
}
  
  		if (!intel_dp->is_mst) {

+   bool full_detect;
/*
 * we'll check the link status via the normal hot plug 
path later -
 * but for short hpds we should check it now
 */
drm_modeset_lock(&dev->mode_config.connection_mutex, 
NULL);
-   intel_dp_check_link_status(intel_dp);
+   intel_dp_check_link_status(intel_dp, &full_detect);
drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+   if (full_detect)
+   goto put_power;
}
}
  
--

1.7.9.5



--
regards,
Sivakumar

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

[Intel-gfx] [DMC_REDESIGN_V2 01/14] drm/i915/gen9: csr_init after runtime pm enable

[Animesh Manna]

Skl is fully dependent on dmc for going to low power state (dc5/dc6).
This requires a trigger from rpm. To ensure the dmc firmware
is available for runtime pm support rpm-reference-count is used
by not releasing the rpm reference if firmware loading is
not completed.

So moved the intel_csr_ucode_init call after runtime pm enable.

Cc: Daniel Vetter 
Cc: Damien Lespiau 
Cc: Imre Deak 
Cc: Sunil Kamath 
Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/i915_dma.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 2193cc2..48b9792 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -885,9 +885,6 @@ int i915_driver_load(struct drm_device *dev, unsigned long 
flags)
 
intel_uncore_init(dev);
 
-   /* Load CSR Firmware for SKL */
-   intel_csr_ucode_init(dev);
-
ret = i915_gem_gtt_init(dev);
if (ret)
goto out_freecsr;
@@ -1035,6 +1032,9 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
 
i915_audio_component_init(dev_priv);
 
+   /* Load CSR Firmware for SKL */
+   intel_csr_ucode_init(dev);
+
return 0;
 
 out_power_well:
-- 
2.0.2

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

[Intel-gfx] [DMC_REDESIGN_V2 02/14] drm/i915: use correct power domain for csr loading

[Animesh Manna]

From: Daniel Vetter 

Grabbing a runtime pm reference with intel_runtime_pm_get will only
prevent device D3. But dmc firmware is required even earlier (namely
for the skl power well 2).

Hence we need to grab a rpm reference higher up in the hierarchy. For
simplicity just grab the _INIT display power well. That's a bit too
much, but since the firmware loading task should completely fairly
quickly this won't be a real problem really.

Cc: Damien Lespiau 
Cc: Imre Deak 
Cc: Sunil Kamath 
Signed-off-by: Daniel Vetter 
Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/intel_csr.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 682cc26..75a775b 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -393,7 +393,7 @@ static void finish_csr_load(const struct firmware *fw, void 
*context)
DRM_DEBUG_KMS("Finished loading %s\n", dev_priv->csr.fw_path);
 out:
if (fw_loaded)
-   intel_runtime_pm_put(dev_priv);
+   intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
else
intel_csr_load_status_set(dev_priv, FW_FAILED);
 
@@ -430,7 +430,7 @@ void intel_csr_ucode_init(struct drm_device *dev)
 * Obtain a runtime pm reference, until CSR is loaded,
 * to avoid entering runtime-suspend.
 */
-   intel_runtime_pm_get(dev_priv);
+   intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
 
/* CSR supported for platform, load firmware */
ret = request_firmware_nowait(THIS_MODULE, true, csr->fw_path,
-- 
2.0.2

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

[Intel-gfx] [DMC_REDESIGN_V2 00/14] Redesign dmc firmware loading.

[Animesh Manna]

This patch series has the changes done to redesign the dmc firmware
loading flow. This is continuation of the below patch series after
addressing review comments from Daniel.

v1: http://lists.freedesktop.org/archives/intel-gfx/2015-August/072921.html

v2: 
- After rebasing based on below patch series.
http://lists.freedesktop.org/archives/intel-gfx/2015-August/072870.html
- Two more patches added in this patch series from older patch series.
http://lists.freedesktop.org/archives/intel-gfx/2015-July/071163.html

Animesh Manna (5):
  drm/i915/gen9: csr_init after runtime pm enable
  drm/i915/bxt: release rpm reference if csr firmware failed to load.
  drm/i915/gen9: Use flush_work to synchronize with dmc loader
  drm/i915/skl: Removed assert for csr-fw-loading check during disabling
dc6
  drm/i915/gen9: Corrected the sanity check of mmio address range for
csr.

Daniel Vetter (9):
  drm/i915: use correct power domain for csr loading
  drm/i915/gen9: move assert_csr_loaded into intel_rpm.c
  drm/i915/gen9: Remove csr.state, csr_lock and related code.
  drm/i915/gen9: Align line continuations in intel_csr.c.
  drm/i915/gen9: Simplify csr loading failure printing.
  drm/i915/gen9: extract parse_csr_fw
  drm/i915/gen9: Don't try to load garbage dmc firmware on resume
  drm/i915/gen9: Use dev_priv in csr functions
  drm/i915: Use request_firmware and our own async work

 drivers/gpu/drm/i915/i915_dma.c |  11 +-
 drivers/gpu/drm/i915/i915_drv.c |  39 +-
 drivers/gpu/drm/i915/i915_drv.h |  12 +-
 drivers/gpu/drm/i915/i915_reg.h |  16 +++
 drivers/gpu/drm/i915/intel_csr.c| 211 
 drivers/gpu/drm/i915/intel_drv.h|  10 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c |  26 ++--
 7 files changed, 114 insertions(+), 211 deletions(-)

-- 
2.0.2

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

[Intel-gfx] [DMC_REDESIGN_V2 06/14] drm/i915/gen9: Align line continuations in intel_csr.c.

[Animesh Manna]

From: Daniel Vetter 

Standard is to align continuations of parameter lists and if
conditions to the opening ( in i915 and drm code.

Apply this across the entire file since it was sticking out a bit too
much.

Also align register definitions while at it.

Cc: Damien Lespiau 
Cc: Imre Deak 
Cc: Sunil Kamath 
Signed-off-by: Daniel Vetter 
Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/i915_reg.h  |  2 +-
 drivers/gpu/drm/i915/intel_csr.c | 42 
 2 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b6bde0c..30147f5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7405,7 +7405,7 @@ enum skl_disp_power_wells {
 /* MMIO address range for CSR program (0x8 - 0x82FFF) */
 #define CSR_MAX_FW_SIZE0x2FFF
 #define CSR_DEFAULT_FW_OFFSET  0x
-#define CSR_MMIO_START_RANGE   0x8
+#define CSR_MMIO_START_RANGE   0x8
 #define CSR_MMIO_END_RANGE 0x8
 
 /* Please see hsw_read_dcomp() and hsw_write_dcomp() before using this 
register,
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index ee2079b..00e9fbf 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -160,15 +160,15 @@ struct stepping_info {
 };
 
 static const struct stepping_info skl_stepping_info[] = {
-   {'A', '0'}, {'B', '0'}, {'C', '0'},
-   {'D', '0'}, {'E', '0'}, {'F', '0'},
-   {'G', '0'}, {'H', '0'}, {'I', '0'}
+   {'A', '0'}, {'B', '0'}, {'C', '0'},
+   {'D', '0'}, {'E', '0'}, {'F', '0'},
+   {'G', '0'}, {'H', '0'}, {'I', '0'}
 };
 
 static char intel_get_stepping(struct drm_device *dev)
 {
if (IS_SKYLAKE(dev) && (dev->pdev->revision <
-   ARRAY_SIZE(skl_stepping_info)))
+   ARRAY_SIZE(skl_stepping_info)))
return skl_stepping_info[dev->pdev->revision].stepping;
else
return -ENODATA;
@@ -177,7 +177,7 @@ static char intel_get_stepping(struct drm_device *dev)
 static char intel_get_substepping(struct drm_device *dev)
 {
if (IS_SKYLAKE(dev) && (dev->pdev->revision <
-   ARRAY_SIZE(skl_stepping_info)))
+   ARRAY_SIZE(skl_stepping_info)))
return skl_stepping_info[dev->pdev->revision].substepping;
else
return -ENODATA;
@@ -214,11 +214,11 @@ void intel_csr_load_program(struct drm_device *dev)
fw_size = dev_priv->csr.dmc_fw_size;
for (i = 0; i < fw_size; i++)
I915_WRITE(CSR_PROGRAM_BASE + i * 4,
-   payload[i]);
+  payload[i]);
 
for (i = 0; i < dev_priv->csr.mmio_count; i++) {
I915_WRITE(dev_priv->csr.mmioaddr[i],
-   dev_priv->csr.mmiodata[i]);
+  dev_priv->csr.mmiodata[i]);
}
 }
 
@@ -250,20 +250,20 @@ static void finish_csr_load(const struct firmware *fw, 
void *context)
/* Extract CSS Header information*/
css_header = (struct intel_css_header *)fw->data;
if (sizeof(struct intel_css_header) !=
-   (css_header->header_len * 4)) {
+   (css_header->header_len * 4)) {
DRM_ERROR("Firmware has wrong CSS header length %u bytes\n",
-   (css_header->header_len * 4));
+ (css_header->header_len * 4));
goto out;
}
readcount += sizeof(struct intel_css_header);
 
/* Extract Package Header information*/
package_header = (struct intel_package_header *)
-   &fw->data[readcount];
+   &fw->data[readcount];
if (sizeof(struct intel_package_header) !=
-   (package_header->header_len * 4)) {
+   (package_header->header_len * 4)) {
DRM_ERROR("Firmware has wrong package header length %u bytes\n",
-   (package_header->header_len * 4));
+ (package_header->header_len * 4));
goto out;
}
readcount += sizeof(struct intel_package_header);
@@ -271,7 +271,7 @@ static void finish_csr_load(const struct firmware *fw, void 
*context)
/* Search for dmc_offset to find firware binary. */
for (i = 0; i < package_header->num_entries; i++) {
if (package_header->fw_info[i].substepping == '*' &&
-   stepping == package_header->fw_info[i].stepping) {
+   stepping == package_header->fw_info[i].stepping) {
dmc_offset = package_header->fw_info[i].offset;
break;
} else if (stepping == package_header->fw_info[i].stepping &&
@@ -279,7 +279,7 @@ static void finish_csr_load(const str

[Intel-gfx] [DMC_REDESIGN_V2 04/14] drm/i915/gen9: move assert_csr_loaded into intel_rpm.c

[Animesh Manna]

From: Daniel Vetter 

Avoids non-static functions since all the callers are in intel_rpm.c.
Only thing we need for that is to move the register definitions into
i915_reg.h.

Cc: Damien Lespiau 
Cc: Imre Deak 
Cc: Sunil Kamath 
Signed-off-by: Daniel Vetter 
Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/i915_reg.h | 16 
 drivers/gpu/drm/i915/intel_csr.c| 25 -
 drivers/gpu/drm/i915/intel_drv.h|  1 -
 drivers/gpu/drm/i915/intel_runtime_pm.c |  8 
 4 files changed, 24 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1fa0554..b6bde0c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7392,6 +7392,22 @@ enum skl_disp_power_wells {
 #define  DC_STATE_DEBUG  0x45520
 #define  DC_STATE_DEBUG_MASK_MEMORY_UP (1<<1)
 
+/*
+* SKL CSR registers for DC5 and DC6
+*/
+#define CSR_PROGRAM_BASE   0x8
+#define CSR_SSP_BASE_ADDR_GEN9 0x2FC0
+#define CSR_HTP_ADDR_SKL   0x00500034
+#define CSR_SSP_BASE   0x8F074
+#define CSR_HTP_SKL0x8F004
+#define CSR_LAST_WRITE 0x8F034
+#define CSR_LAST_WRITE_VALUE   0xc003b400
+/* MMIO address range for CSR program (0x8 - 0x82FFF) */
+#define CSR_MAX_FW_SIZE0x2FFF
+#define CSR_DEFAULT_FW_OFFSET  0x
+#define CSR_MMIO_START_RANGE   0x8
+#define CSR_MMIO_END_RANGE 0x8
+
 /* 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_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index be388da..9153764 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -45,22 +45,6 @@
 
 MODULE_FIRMWARE(I915_CSR_SKL);
 
-/*
-* SKL CSR registers for DC5 and DC6
-*/
-#define CSR_PROGRAM_BASE   0x8
-#define CSR_SSP_BASE_ADDR_GEN9 0x2FC0
-#define CSR_HTP_ADDR_SKL   0x00500034
-#define CSR_SSP_BASE   0x8F074
-#define CSR_HTP_SKL0x8F004
-#define CSR_LAST_WRITE 0x8F034
-#define CSR_LAST_WRITE_VALUE   0xc003b400
-/* MMIO address range for CSR program (0x8 - 0x82FFF) */
-#define CSR_MAX_FW_SIZE0x2FFF
-#define CSR_DEFAULT_FW_OFFSET  0x
-#define CSR_MMIO_START_RANGE   0x8
-#define CSR_MMIO_END_RANGE 0x8
-
 struct intel_css_header {
/* 0x09 for DMC */
uint32_t module_type;
@@ -461,12 +445,3 @@ void intel_csr_ucode_fini(struct drm_device *dev)
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 9cb7d4e..c178ae8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1157,7 +1157,6 @@ 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 340f386..71832dc 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -455,6 +455,14 @@ static void gen9_set_dc_state_debugmask_memory_up(
}
 }
 
+static void assert_csr_loaded(struct drm_i915_private *dev_priv)
+{
+   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");
+}
+
 static void assert_can_enable_dc5(struct drm_i915_private *dev_priv)
 {
struct drm_device *dev = dev_priv->dev;
-- 
2.0.2

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

[Intel-gfx] [DMC_REDESIGN_V2 05/14] drm/i915/gen9: Remove csr.state, csr_lock and related code.

[Animesh Manna]

From: Daniel Vetter 

This removes two anti-patterns:
- Locking shouldn't be used to synchronize with async work (of any
  form, whether callbacks, workers or other threads). This is what the
  mutex_lock/unlock seems to have been for in intel_csr_load_program.
  Instead ordering should be ensured with the generic
  wait_for_completion()/complete(). Or more specific functions
  provided by the core kernel like e.g.
  flush_work()/cancel_work_sync() in the case of synchronizing with a
  work item.

- Don't invent own completion like the following code did with the
  (already removed) wait_for(csr_load_status_get()) pattern - it's
  really hard to get these right when you want them to be _really_
  correct (and be fast) in all cases. Furthermore it's easier to read
  code using the well-known primitives than new ones using
  non-standard names.

Cc: Damien Lespiau 
Cc: Imre Deak 
Cc: Sunil Kamath 
Signed-off-by: Daniel Vetter 
Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/i915_dma.c |  1 -
 drivers/gpu/drm/i915/i915_drv.c | 13 ++
 drivers/gpu/drm/i915/i915_drv.h | 10 ---
 drivers/gpu/drm/i915/intel_csr.c| 46 +
 drivers/gpu/drm/i915/intel_drv.h|  3 ---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 17 ++--
 6 files changed, 5 insertions(+), 85 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 48b9792..aa3cdcf 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -839,7 +839,6 @@ int i915_driver_load(struct drm_device *dev, unsigned long 
flags)
spin_lock_init(&dev_priv->mmio_flip_lock);
mutex_init(&dev_priv->sb_lock);
mutex_init(&dev_priv->modeset_restore_lock);
-   mutex_init(&dev_priv->csr_lock);
 
intel_pm_setup(dev);
 
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index fa66162..1ddf3a9 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1013,19 +1013,11 @@ static int i915_pm_resume(struct device *dev)
 
 static int skl_suspend_complete(struct drm_i915_private *dev_priv)
 {
-   enum csr_state state;
/* Enabling DC6 is not a hard requirement to enter runtime D3 */
 
skl_uninit_cdclk(dev_priv);
 
-   /* TODO: wait for a completion event or
-* similar here instead of busy
-* waiting using wait_for function.
-*/
-   wait_for((state = intel_csr_load_status_get(dev_priv)) !=
-   FW_UNINITIALIZED, 1000);
-   if (state == FW_LOADED)
-   skl_enable_dc6(dev_priv);
+   skl_enable_dc6(dev_priv);
 
return 0;
 }
@@ -1073,8 +1065,7 @@ static int skl_resume_prepare(struct drm_i915_private 
*dev_priv)
 {
struct drm_device *dev = dev_priv->dev;
 
-   if (intel_csr_load_status_get(dev_priv) == FW_LOADED)
-   skl_disable_dc6(dev_priv);
+   skl_disable_dc6(dev_priv);
 
skl_init_cdclk(dev_priv);
intel_csr_load_program(dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e0f3f05..9f01c72 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -736,12 +736,6 @@ 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;
uint32_t *dmc_payload;
@@ -749,7 +743,6 @@ struct intel_csr {
uint32_t mmio_count;
uint32_t mmioaddr[8];
uint32_t mmiodata[8];
-   enum csr_state state;
 };
 
 #define DEV_INFO_FOR_EACH_FLAG(func, sep) \
@@ -1714,9 +1707,6 @@ struct drm_i915_private {
 
struct intel_csr csr;
 
-   /* Display CSR-related protection */
-   struct mutex csr_lock;
-
struct intel_gmbus gmbus[GMBUS_NUM_PINS];
 
/** gmbus_mutex protects against concurrent usage of the single hw gmbus
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 9153764..ee2079b 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -184,40 +184,6 @@ static char intel_get_substepping(struct drm_device *dev)
 }
 
 /**
- * intel_csr_load_status_get() - to get firmware loading status.
- * @dev_priv: i915 device.
- *
- * This function helps to get the firmware loading status.
- *
- * Return: Firmware loading status.
- */
-enum csr_state intel_csr_load_status_get(struct drm_i915_private *dev_priv)
-{
-   enum csr_state state;
-
-   mutex_lock(&dev_priv->csr_lock);
-   state = dev_priv->csr.state;
-   mutex_unlock(&dev_priv->csr_lock);
-
-   return state;
-}
-
-/**
- * intel_csr_load_status_set() - help to set firmware loading status.
- * @dev_priv: i915 device.
- * @state: enumeration of firmware loa

[Intel-gfx] [DMC_REDESIGN_V2 08/14] drm/i915/gen9: extract parse_csr_fw

[Animesh Manna]

From: Daniel Vetter 

The loader function will get a bit more complicated soon, extract the
parsing code to make the control flow clearer. While doing that just
use dev_priv->csr.dmc_payload as the indicator for whether it all
suceeded or not.

Cc: Damien Lespiau 
Cc: Imre Deak 
Cc: Sunil Kamath 
Signed-off-by: Daniel Vetter 
Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/intel_csr.c | 48 +---
 1 file changed, 30 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 9d4b37b..9971794 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -222,9 +222,9 @@ void intel_csr_load_program(struct drm_device *dev)
}
 }
 
-static void finish_csr_load(const struct firmware *fw, void *context)
+static uint32_t *parse_csr_fw(struct drm_i915_private *dev_priv,
+ const struct firmware *fw)
 {
-   struct drm_i915_private *dev_priv = context;
struct drm_device *dev = dev_priv->dev;
struct intel_css_header *css_header;
struct intel_package_header *package_header;
@@ -235,14 +235,13 @@ static void finish_csr_load(const struct firmware *fw, 
void *context)
uint32_t dmc_offset = CSR_DEFAULT_FW_OFFSET, readcount = 0, nbytes;
uint32_t i;
uint32_t *dmc_payload;
-   bool fw_loaded = false;
 
if (!fw)
-   goto out;
+   return NULL;
 
if ((stepping == -ENODATA) || (substepping == -ENODATA)) {
DRM_ERROR("Unknown stepping info, firmware loading failed\n");
-   goto out;
+   return NULL;
}
 
/* Extract CSS Header information*/
@@ -251,7 +250,7 @@ static void finish_csr_load(const struct firmware *fw, void 
*context)
(css_header->header_len * 4)) {
DRM_ERROR("Firmware has wrong CSS header length %u bytes\n",
  (css_header->header_len * 4));
-   goto out;
+   return NULL;
}
readcount += sizeof(struct intel_css_header);
 
@@ -262,7 +261,7 @@ static void finish_csr_load(const struct firmware *fw, void 
*context)
(package_header->header_len * 4)) {
DRM_ERROR("Firmware has wrong package header length %u bytes\n",
  (package_header->header_len * 4));
-   goto out;
+   return NULL;
}
readcount += sizeof(struct intel_package_header);
 
@@ -282,7 +281,7 @@ static void finish_csr_load(const struct firmware *fw, void 
*context)
}
if (dmc_offset == CSR_DEFAULT_FW_OFFSET) {
DRM_ERROR("Firmware not supported for %c stepping\n", stepping);
-   goto out;
+   return NULL;
}
readcount += dmc_offset;
 
@@ -291,7 +290,7 @@ static void finish_csr_load(const struct firmware *fw, void 
*context)
if (sizeof(struct intel_dmc_header) != (dmc_header->header_len)) {
DRM_ERROR("Firmware has wrong dmc header length %u bytes\n",
  (dmc_header->header_len));
-   goto out;
+   return NULL;
}
readcount += sizeof(struct intel_dmc_header);
 
@@ -299,7 +298,7 @@ static void finish_csr_load(const struct firmware *fw, void 
*context)
if (dmc_header->mmio_count > ARRAY_SIZE(csr->mmioaddr)) {
DRM_ERROR("Firmware has wrong mmio count %u\n",
  dmc_header->mmio_count);
-   goto out;
+   return NULL;
}
csr->mmio_count = dmc_header->mmio_count;
for (i = 0; i < dmc_header->mmio_count; i++) {
@@ -307,7 +306,7 @@ static void finish_csr_load(const struct firmware *fw, void 
*context)
dmc_header->mmioaddr[i] > CSR_MMIO_END_RANGE) {
DRM_ERROR(" Firmware has wrong mmio address 0x%x\n",
  dmc_header->mmioaddr[i]);
-   goto out;
+   return NULL;
}
csr->mmioaddr[i] = dmc_header->mmioaddr[i];
csr->mmiodata[i] = dmc_header->mmiodata[i];
@@ -317,26 +316,39 @@ static void finish_csr_load(const struct firmware *fw, 
void *context)
nbytes = dmc_header->fw_size * 4;
if (nbytes > CSR_MAX_FW_SIZE) {
DRM_ERROR("CSR firmware too big (%u) bytes\n", nbytes);
-   goto out;
+   return NULL;
}
csr->dmc_fw_size = dmc_header->fw_size;
 
-   csr->dmc_payload = kmalloc(nbytes, GFP_KERNEL);
-   if (!csr->dmc_payload) {
+   dmc_payload = kmalloc(nbytes, GFP_KERNEL);
+   if (!dmc_payload) {
DRM_ERROR("Memory allocation failed for dmc payload\n");
-   goto out;
+   return NULL;
}
 
-   dmc_payload = csr->dmc_payload;
memcpy(dmc_payload, &fw->data[readcou

[Intel-gfx] [DMC_REDESIGN_V2 11/14] drm/i915: Use request_firmware and our own async work

[Animesh Manna]

From: Daniel Vetter 

Two benefits:
- We can use FW_LOADER_USERSPACE_FALLBACK.
- We can use flush_work to synchronize with the oustanding worker,
  which is a notch more obvious what it does than having a special
  completion.

The next patch will properly synchronize against the async loader in
the resume and unload code.

Cc: Damien Lespiau 
Cc: Imre Deak 
Cc: Sunil Kamath 
Signed-off-by: Daniel Vetter 
Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_csr.c | 19 +++
 2 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6241b49..5c34a9f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -737,6 +737,7 @@ struct intel_uncore {
for_each_fw_domain_mask(domain__, FORCEWAKE_ALL, dev_priv__, i__)
 
 struct intel_csr {
+   struct work_struct work;
const char *fw_path;
uint32_t *dmc_payload;
uint32_t dmc_fw_size;
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index b369ea4..f22b368 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -330,10 +330,16 @@ static uint32_t *parse_csr_fw(struct drm_i915_private 
*dev_priv,
return dmc_payload;
 }
 
-static void finish_csr_load(const struct firmware *fw, void *context)
+static void csr_load_work_fn(struct work_struct *work)
 {
-   struct drm_i915_private *dev_priv = context;
+   struct drm_i915_private *dev_priv;
+   const struct firmware *fw;
+   int ret;
+
+   dev_priv = container_of(work, typeof(*dev_priv), csr.work);
 
+   ret = request_firmware(&fw, dev_priv->csr.fw_path,
+  &dev_priv->dev->pdev->dev);
if (!fw)
goto out;
 
@@ -364,7 +370,8 @@ out:
 void intel_csr_ucode_init(struct drm_i915_private *dev_priv)
 {
struct intel_csr *csr = &dev_priv->csr;
-   int ret;
+
+   INIT_WORK(&dev_priv->csr.work, csr_load_work_fn);
 
if (!HAS_CSR(dev_priv))
return;
@@ -384,11 +391,7 @@ void intel_csr_ucode_init(struct drm_i915_private 
*dev_priv)
 */
intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
 
-   /* CSR supported for platform, load firmware */
-   ret = request_firmware_nowait(THIS_MODULE, true, csr->fw_path,
- &dev_priv->dev->pdev->dev,
- GFP_KERNEL, dev_priv,
- finish_csr_load);
+   schedule_work(&dev_priv->csr.work);
 }
 
 /**
-- 
2.0.2

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

[Intel-gfx] [DMC_REDESIGN_V2 14/14] drm/i915/gen9: Corrected the sanity check of mmio address range for csr.

[Animesh Manna]

Condition check for out of boundary for csr address space is corrected
(Thanks to David Binderman for suggestion).

Cc: Imre Deak 
Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/intel_csr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 3ddf598..477e769 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -301,7 +301,7 @@ static uint32_t *parse_csr_fw(struct drm_i915_private 
*dev_priv,
}
csr->mmio_count = dmc_header->mmio_count;
for (i = 0; i < dmc_header->mmio_count; i++) {
-   if (dmc_header->mmioaddr[i] < CSR_MMIO_START_RANGE &&
+   if (dmc_header->mmioaddr[i] < CSR_MMIO_START_RANGE ||
dmc_header->mmioaddr[i] > CSR_MMIO_END_RANGE) {
DRM_ERROR(" Firmware has wrong mmio address 0x%x\n",
  dmc_header->mmioaddr[i]);
-- 
2.0.2

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

[Intel-gfx] [DMC_REDESIGN_V2 03/14] drm/i915/bxt: release rpm reference if csr firmware failed to load.

[Animesh Manna]

Note that for bxt without dmc, display engine can go to lowest
possible state (dc9), so releasing the rpm reference.

Cc: Daniel Vetter 
Cc: Damien Lespiau 
Cc: Imre Deak 
Cc: Sunil Kamath 
Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/intel_csr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 75a775b..be388da 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -392,7 +392,7 @@ static void finish_csr_load(const struct firmware *fw, void 
*context)
 
DRM_DEBUG_KMS("Finished loading %s\n", dev_priv->csr.fw_path);
 out:
-   if (fw_loaded)
+   if (fw_loaded || IS_BROXTON(dev))
intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
else
intel_csr_load_status_set(dev_priv, FW_FAILED);
-- 
2.0.2

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

[Intel-gfx] [DMC_REDESIGN_V2 07/14] drm/i915/gen9: Simplify csr loading failure printing.

[Animesh Manna]

From: Daniel Vetter 

If we really want to we can be more verbose here, but we really don't
need an entire function for this.

Cc: Damien Lespiau 
Cc: Imre Deak 
Cc: Sunil Kamath 
Signed-off-by: Daniel Vetter 
Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/i915_drv.c  | 20 
 drivers/gpu/drm/i915/i915_drv.h  |  1 -
 drivers/gpu/drm/i915/intel_csr.c |  8 +++-
 3 files changed, 3 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1ddf3a9..3cdd319 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -537,26 +537,6 @@ bool i915_semaphore_is_enabled(struct drm_device *dev)
return true;
 }
 
-void i915_firmware_load_error_print(const char *fw_path, int err)
-{
-   DRM_ERROR("failed to load firmware %s (%d)\n", fw_path, err);
-
-   /*
-* If the reason is not known assume -ENOENT since that's the most
-* usual failure mode.
-*/
-   if (!err)
-   err = -ENOENT;
-
-   if (!(IS_BUILTIN(CONFIG_DRM_I915) && err == -ENOENT))
-   return;
-
-   DRM_ERROR(
- "The driver is built-in, so to load the firmware you need to\n"
- "include it either in the kernel (see CONFIG_EXTRA_FIRMWARE) or\n"
- "in your initrd/initramfs image.\n");
-}
-
 static void intel_suspend_encoders(struct drm_i915_private *dev_priv)
 {
struct drm_device *dev = dev_priv->dev;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9f01c72..6241b49 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2654,7 +2654,6 @@ extern unsigned long i915_mch_val(struct drm_i915_private 
*dev_priv);
 extern unsigned long i915_gfx_val(struct drm_i915_private *dev_priv);
 extern void i915_update_gfx_val(struct drm_i915_private *dev_priv);
 int vlv_force_gfx_clock(struct drm_i915_private *dev_priv, bool on);
-void i915_firmware_load_error_print(const char *fw_path, int err);
 
 /* intel_hotplug.c */
 void intel_hpd_irq_handler(struct drm_device *dev, u32 pin_mask, u32 
long_mask);
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 00e9fbf..9d4b37b 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -237,10 +237,8 @@ static void finish_csr_load(const struct firmware *fw, 
void *context)
uint32_t *dmc_payload;
bool fw_loaded = false;
 
-   if (!fw) {
-   i915_firmware_load_error_print(csr->fw_path, 0);
+   if (!fw)
goto out;
-   }
 
if ((stepping == -ENODATA) || (substepping == -ENODATA)) {
DRM_ERROR("Unknown stepping info, firmware loading failed\n");
@@ -340,6 +338,8 @@ static void finish_csr_load(const struct firmware *fw, void 
*context)
 out:
if (fw_loaded || IS_BROXTON(dev))
intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
+   else
+   DRM_ERROR("Failed to load DMC firmware, disabling rpm\n");
 
release_firmware(fw);
 }
@@ -380,8 +380,6 @@ void intel_csr_ucode_init(struct drm_device *dev)
  &dev_priv->dev->pdev->dev,
  GFP_KERNEL, dev_priv,
  finish_csr_load);
-   if (ret)
-   i915_firmware_load_error_print(csr->fw_path, ret);
 }
 
 /**
-- 
2.0.2

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

[Intel-gfx] [DMC_REDESIGN_V2 09/14] drm/i915/gen9: Don't try to load garbage dmc firmware on resume

[Animesh Manna]

From: Daniel Vetter 

We need to make sure we don't put garbage into the hw if dmc firmware
loading failed mid-thru.

Cc: Damien Lespiau 
Cc: Imre Deak 
Cc: Sunil Kamath 
Signed-off-by: Daniel Vetter 
Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/intel_csr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 9971794..9ed513c 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -208,7 +208,7 @@ void intel_csr_load_program(struct drm_device *dev)
 * This condition will help to check if csr address space is reset/
 * not loaded.
 */
-   if (I915_READ(CSR_PROGRAM_BASE))
+   if ((!dev_priv->csr.dmc_payload) || I915_READ(CSR_PROGRAM_BASE))
return;
 
fw_size = dev_priv->csr.dmc_fw_size;
-- 
2.0.2

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

[Intel-gfx] [DMC_REDESIGN_V2 10/14] drm/i915/gen9: Use dev_priv in csr functions

[Animesh Manna]

From: Daniel Vetter 

As all csr firmware related opertion are not using any
any data structures of drm framework level, so better to
use dev_priv instead of dev. it's a new style! :)

Cc: Damien Lespiau 
Cc: Imre Deak 
Cc: Sunil Kamath 
Signed-off-by: Daniel Vetter 
Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/i915_dma.c  |  6 +++---
 drivers/gpu/drm/i915/i915_drv.c  |  4 +---
 drivers/gpu/drm/i915/intel_csr.c | 29 -
 drivers/gpu/drm/i915/intel_drv.h |  6 +++---
 4 files changed, 19 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index aa3cdcf..d4a7725 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1032,7 +1032,7 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
i915_audio_component_init(dev_priv);
 
/* Load CSR Firmware for SKL */
-   intel_csr_ucode_init(dev);
+   intel_csr_ucode_init(dev_priv);
 
return 0;
 
@@ -1060,7 +1060,7 @@ out_mtrrfree:
 out_gtt:
i915_global_gtt_cleanup(dev);
 out_freecsr:
-   intel_csr_ucode_fini(dev);
+   intel_csr_ucode_fini(dev_priv);
intel_uncore_fini(dev);
pci_iounmap(dev->pdev, dev_priv->regs);
 put_bridge:
@@ -1142,7 +1142,7 @@ int i915_driver_unload(struct drm_device *dev)
intel_fbc_cleanup_cfb(dev_priv);
i915_gem_cleanup_stolen(dev);
 
-   intel_csr_ucode_fini(dev);
+   intel_csr_ucode_fini(dev_priv);
 
intel_teardown_gmbus(dev);
intel_teardown_mchbar(dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3cdd319..daaf72d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1043,12 +1043,10 @@ static int bxt_resume_prepare(struct drm_i915_private 
*dev_priv)
 
 static int skl_resume_prepare(struct drm_i915_private *dev_priv)
 {
-   struct drm_device *dev = dev_priv->dev;
-
skl_disable_dc6(dev_priv);
 
skl_init_cdclk(dev_priv);
-   intel_csr_load_program(dev);
+   intel_csr_load_program(dev_priv);
 
return 0;
 }
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 9ed513c..b369ea4 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -185,19 +185,18 @@ static char intel_get_substepping(struct drm_device *dev)
 
 /**
  * intel_csr_load_program() - write the firmware from memory to register.
- * @dev: drm device.
+ * @dev_priv: i915 drm device.
  *
  * CSR firmware is read from a .bin file and kept in internal memory one time.
  * Everytime display comes back from low power state this function is called to
  * copy the firmware from internal memory to registers.
  */
-void intel_csr_load_program(struct drm_device *dev)
+void intel_csr_load_program(struct drm_i915_private *dev_priv)
 {
-   struct drm_i915_private *dev_priv = dev->dev_private;
u32 *payload = dev_priv->csr.dmc_payload;
uint32_t i, fw_size;
 
-   if (!IS_GEN9(dev)) {
+   if (!IS_GEN9(dev_priv)) {
DRM_ERROR("No CSR support available for this platform\n");
return;
}
@@ -334,7 +333,6 @@ static uint32_t *parse_csr_fw(struct drm_i915_private 
*dev_priv,
 static void finish_csr_load(const struct firmware *fw, void *context)
 {
struct drm_i915_private *dev_priv = context;
-   struct drm_device *dev = dev_priv->dev;
 
if (!fw)
goto out;
@@ -344,11 +342,11 @@ static void finish_csr_load(const struct firmware *fw, 
void *context)
goto out;
 
/* load csr program during system boot, as needed for DC states */
-   intel_csr_load_program(dev);
+   intel_csr_load_program(dev_priv);
 
DRM_DEBUG_KMS("Finished loading %s\n", dev_priv->csr.fw_path);
 out:
-   if (dev_priv->csr.dmc_payload || IS_BROXTON(dev))
+   if (dev_priv->csr.dmc_payload || IS_BROXTON(dev_priv))
intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
else
DRM_ERROR("Failed to load DMC firmware, disabling rpm\n");
@@ -358,21 +356,20 @@ out:
 
 /**
  * intel_csr_ucode_init() - initialize the firmware loading.
- * @dev: drm device.
+ * @dev_priv: i915 drm device.
  *
  * This function is called at the time of loading the display driver to read
  * firmware from a .bin file and copied into a internal memory.
  */
-void intel_csr_ucode_init(struct drm_device *dev)
+void intel_csr_ucode_init(struct drm_i915_private *dev_priv)
 {
-   struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_csr *csr = &dev_priv->csr;
int ret;
 
-   if (!HAS_CSR(dev))
+   if (!HAS_CSR(dev_priv))
return;
 
-   if (IS_SKYLAKE(dev))
+   if (IS_SKYLAKE(dev_priv))
csr->fw_path = I915_CSR_SKL;
else {
DRM_ERROR("Unexpected: no known CSR firmware for platform\n");
@@ -396,

[Intel-gfx] [DMC_REDESIGN_V2 12/14] drm/i915/gen9: Use flush_work to synchronize with dmc loader

[Animesh Manna]

During driver unload to ensure we dont have any pending task,
flush_work added to complete firmware loading task.

v1: Initial version.

v2: As per review comments from Daniel,
Removed flush_work from skl_set_power_well. As we have taken
power well refernece and rpm count during firmware loading
by using display_power_domain_get/put - this will always
ensure rpm will be blocked if firmware is not loaded.

Cc: Daniel Vetter 
Cc: Damien Lespiau 
Cc: Imre Deak 
Cc: Sunil Kamath 
Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/i915_drv.c  | 2 --
 drivers/gpu/drm/i915/intel_csr.c | 2 ++
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index daaf72d..e16f8a8 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -993,8 +993,6 @@ static int i915_pm_resume(struct device *dev)
 
 static int skl_suspend_complete(struct drm_i915_private *dev_priv)
 {
-   /* Enabling DC6 is not a hard requirement to enter runtime D3 */
-
skl_uninit_cdclk(dev_priv);
 
skl_enable_dc6(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index f22b368..3ddf598 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -406,6 +406,8 @@ void intel_csr_ucode_fini(struct drm_i915_private *dev_priv)
if (!HAS_CSR(dev_priv))
return;
 
+   flush_work(&dev_priv->csr.work);
+
kfree(dev_priv->csr.dmc_payload);
 }
 
-- 
2.0.2

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

[Intel-gfx] [DMC_REDESIGN_V2 13/14] drm/i915/skl: Removed assert for csr-fw-loading check during disabling dc6

[Animesh Manna]

As during disabling dc6 no need to check for csr firmware
loading status, so removed the assert call (Requested by Damien).

Cc: Damien Lespiau 
Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 3ffebb7..7089411 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -551,7 +551,6 @@ static void assert_can_disable_dc6(struct drm_i915_private 
*dev_priv)
if (dev_priv->power_domains.initializing)
return;
 
-   assert_csr_loaded(dev_priv);
WARN(!(I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC6),
"DC6 already programmed to be disabled.\n");
 }
-- 
2.0.2

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

[Intel-gfx] [PATCH 3/3] drm/i915/dp: move TPS3 logic to where it's used

[Jani Nikula]

There is no need to have a separate flag for tps3 as the information is
only used at one location. Move the logic there to make it easier to
follow.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dp.c  | 31 +--
 drivers/gpu/drm/i915/intel_drv.h |  1 -
 2 files changed, 17 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 60dca34d2f0f..cc97d5d7fe5e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3746,13 +3746,25 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
 void
 intel_dp_complete_link_train(struct intel_dp *intel_dp)
 {
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   struct drm_device *dev = dig_port->base.base.dev;
bool channel_eq = false;
int tries, cr_tries;
uint32_t DP = intel_dp->DP;
uint32_t training_pattern = DP_TRAINING_PATTERN_2;
 
-   /* Training Pattern 3 for HBR2 or 1.2 devices that support it*/
-   if (intel_dp->link_rate == 54 || intel_dp->use_tps3)
+   /*
+* Training Pattern 3 for HBR2 or 1.2 devices that support it.
+*
+* Intel platforms that support HBR2 also support TPS3. TPS3 support is
+* also mandatory for downstream devices that support HBR2.
+*
+* Due to WaDisableHBR2 SKL < B0 is the only exception where TPS3 is
+* supported but still not enabled.
+*/
+   if (intel_dp->link_rate == 54 ||
+   (intel_dp_source_supports_hbr2(dev) &&
+drm_dp_tps3_supported(intel_dp->dpcd)))
training_pattern = DP_TRAINING_PATTERN_3;
 
/* channel equalization */
@@ -3934,18 +3946,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
}
}
 
-   /* Training Pattern 3 support, Intel platforms that support HBR2 alone
-* have support for TP3 hence that check is used along with dpcd check
-* to ensure TP3 can be enabled.
-* SKL < B0: due it's WaDisableHBR2 is the only exception where TP3 is
-* supported but still not enabled.
-*/
-   if (drm_dp_tps3_supported(intel_dp->dpcd) &&
-   intel_dp_source_supports_hbr2(dev)) {
-   intel_dp->use_tps3 = true;
-   DRM_DEBUG_KMS("Displayport TPS3 supported\n");
-   } else
-   intel_dp->use_tps3 = false;
+   DRM_DEBUG_KMS("Display Port TPS3 support: source %s, sink %s\n",
+ intel_dp_source_supports_hbr2(dev) ? "yes" : "no",
+ drm_dp_tps3_supported(intel_dp->dpcd) ? "yes" : "no");
 
/* Intermediate frequency support */
if (is_edp(intel_dp) &&
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 71a2e18d9f50..1de68b2cdae6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -743,7 +743,6 @@ struct intel_dp {
enum pipe pps_pipe;
struct edp_power_seq pps_delays;
 
-   bool use_tps3;
bool can_mst; /* this port supports mst */
bool is_mst;
int active_mst_links;
-- 
2.1.4

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

[Intel-gfx] [PATCH 1/3] drm/dp: add drm_dp_tps3_supported helper

[Jani Nikula]

Cc: Thierry Reding 
Signed-off-by: Jani Nikula 
---
 include/drm/drm_dp_helper.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 499e9f625aef..8c52d0ef1fc9 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -634,6 +634,13 @@ drm_dp_enhanced_frame_cap(const u8 
dpcd[DP_RECEIVER_CAP_SIZE])
(dpcd[DP_MAX_LANE_COUNT] & DP_ENHANCED_FRAME_CAP);
 }
 
+static inline bool
+drm_dp_tps3_supported(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+   return dpcd[DP_DPCD_REV] >= 0x12 &&
+   dpcd[DP_MAX_LANE_COUNT] & DP_TPS3_SUPPORTED;
+}
+
 /*
  * DisplayPort AUX channel
  */
-- 
2.1.4

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

[Intel-gfx] [PATCH 2/3] drm/i915/dp: use the drm dp helper for determining sink tps3 support

[Jani Nikula]

No functional changes.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dp.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f10a4724b841..60dca34d2f0f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3940,8 +3940,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
 * SKL < B0: due it's WaDisableHBR2 is the only exception where TP3 is
 * supported but still not enabled.
 */
-   if (intel_dp->dpcd[DP_DPCD_REV] >= 0x12 &&
-   intel_dp->dpcd[DP_MAX_LANE_COUNT] & DP_TPS3_SUPPORTED &&
+   if (drm_dp_tps3_supported(intel_dp->dpcd) &&
intel_dp_source_supports_hbr2(dev)) {
intel_dp->use_tps3 = true;
DRM_DEBUG_KMS("Displayport TPS3 supported\n");
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH 3/4] drm/fb-helper: Add module option to disable fbdev emulation

[Daniel Vetter]

On Wed, Aug 26, 2015 at 02:14:37PM +0530, Archit Taneja wrote:
> 
> 
> On 08/26/2015 10:42 AM, Archit Taneja wrote:
> >
> >
> >On 08/25/2015 07:15 PM, Daniel Vetter wrote:
> >>Faster than recompiling.
> >>
> >>Note that restore_fbdev_mode_unlocked is a bit special and the only
> >>one which returns an error code when fbdev isn't there - i915 needs
> >>that one to not fall over with some additional fbcon related restore
> >>code. Everyone else just ignores the return value or only prints a
> >>DRM_DEBUG level message.
> >
> >Reviewed-by:Archit Taneja 
> 
> 
> With the module param, and the drivers should see the following state(
> based on the truth table below):
> 
> module param | config option
>true  |true   -> real helper funcs called, driver
> allocated drm_fb_helper is correctly
> populated.
> 
>false |true   -> real helper funcs called, but bailed
> out early, driver allocated
> drm_fb_helper is non-NULL, but we won't
> end up using it.

Hm I tried to give drivers the same semantics here as with the stub
functions. Where did I screw up? The goal really was to match the end
result for drivers ...
-Daniel

> X|false  -> stub functions called, drm_fb_helper is
> NULL
> 
> I wonder if the 2nd combination could leave space for errors in other
> drivers. Drivers tend to check whether the fb_helper struct is NULL
> or not, and make decisions based on that. If the decisions are to
> just call a drm_fb_helper function, then we're okay. If they do something
> more than that, then we could have an issue.
> 
> I'll prepare the remainder of 'Step 2' part of the series over this,
> and we can test to check if we don't hit any corner cases.

> 
> Archit
> 
> >
> >>
> >>Signed-off-by: Daniel Vetter 
> >>---
> >>  drivers/gpu/drm/drm_fb_helper.c | 29 +
> >>  1 file changed, 29 insertions(+)
> >>
> >>diff --git a/drivers/gpu/drm/drm_fb_helper.c
> >>b/drivers/gpu/drm/drm_fb_helper.c
> >>index 83aacb0cc9df..8259dec1de1f 100644
> >>--- a/drivers/gpu/drm/drm_fb_helper.c
> >>+++ b/drivers/gpu/drm/drm_fb_helper.c
> >>@@ -39,6 +39,11 @@
> >>  #include 
> >>  #include 
> >>
> >>+static bool drm_fbdev_emulation = true;
> >>+module_param_named(fbdev_emulation, drm_fbdev_emulation, bool, 0600);
> >>+MODULE_PARM_DESC(fbdev_emulation,
> >>+ "Enable legacy fbdev emulation [default=true]");
> >>+
> >>  static LIST_HEAD(kernel_fb_helper_list);
> >>
> >>  /**
> >>@@ -99,6 +104,9 @@ int drm_fb_helper_single_add_all_connectors(struct
> >>drm_fb_helper *fb_helper)
> >>  struct drm_connector *connector;
> >>  int i;
> >>
> >>+if (!drm_fbdev_emulation)
> >>+return 0;
> >>+
> >>  mutex_lock(&dev->mode_config.mutex);
> >>  drm_for_each_connector(connector, dev) {
> >>  struct drm_fb_helper_connector *fb_helper_connector;
> >>@@ -129,6 +137,9 @@ int drm_fb_helper_add_one_connector(struct
> >>drm_fb_helper *fb_helper, struct drm_
> >>  struct drm_fb_helper_connector **temp;
> >>  struct drm_fb_helper_connector *fb_helper_connector;
> >>
> >>+if (!drm_fbdev_emulation)
> >>+return 0;
> >>+
> >>  WARN_ON(!mutex_is_locked(&fb_helper->dev->mode_config.mutex));
> >>  if (fb_helper->connector_count + 1 >
> >>fb_helper->connector_info_alloc_count) {
> >>  temp = krealloc(fb_helper->connector_info, sizeof(struct
> >>drm_fb_helper_connector *) * (fb_helper->connector_count + 1),
> >>GFP_KERNEL);
> >>@@ -184,6 +195,9 @@ int drm_fb_helper_remove_one_connector(struct
> >>drm_fb_helper *fb_helper,
> >>  struct drm_fb_helper_connector *fb_helper_connector;
> >>  int i, j;
> >>
> >>+if (!drm_fbdev_emulation)
> >>+return 0;
> >>+
> >>  WARN_ON(!mutex_is_locked(&fb_helper->dev->mode_config.mutex));
> >>
> >>  for (i = 0; i < fb_helper->connector_count; i++) {
> >>@@ -375,6 +389,9 @@ int
> >>drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper
> >>*fb_helper)
> >>  bool do_delayed
> >>  int ret;
> >>
> >>+if (!drm_fbdev_emulation)
> >>+return -ENODEV;
> >>+
> >>  drm_modeset_lock_all(dev);
> >>  ret = restore_fbdev_mode(fb_helper);
> >>
> >>@@ -591,6 +608,9 @@ int drm_fb_helper_init(struct drm_device *dev,
> >>  struct drm_crtc *crtc;
> >>  int i;
> >>
> >>+if (!drm_fbdev_emulation)
> >>+return 0;
> >>+
> >>  if (!max_conn_count)
> >>  return -EINVAL;
> >>
> >>@@ -713,6 +733,9 @@ EXPORT_SYMBOL(drm_fb_helper_release_fbi);
> >>
> >>  void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
> >>  {
> >>+if (!drm_fbdev_emulation)
> >>+return;
> >>+
> >>  if (!list_empty(&fb_helper->kernel_fb_list)) {
> >>  list_del(&fb_helper->kernel_fb_list);
> >>  if (list_empty(&kernel_fb_helper_list)) {
> 

Re: [Intel-gfx] [PATCH] drm/fb-helper: Use -errno return in restore_mode_unlocked

[Daniel Vetter]

On Tue, Aug 25, 2015 at 03:20:02PM -0400, Rob Clark wrote:
> On Tue, Aug 25, 2015 at 11:20 AM, Daniel Vetter  
> wrote:
> > Using bool and returning true upon error is very uncommon. Also an int
> > return value is actually what all the callers which did check it seem
> > to have expected.
> >
> > v2: Restore hunk misplaced in a rebase, spotted by Rob.
> >
> > Cc: Rob Clark 
> > Signed-off-by: Daniel Vetter 
> 
> Reviewed-by: Rob Clark 

Merged the first 2 patches from this series to drm-misc, thanks for your
review.
-Daniel

> 
> 
> > ---
> >  drivers/gpu/drm/drm_fb_helper.c | 19 +++
> >  include/drm/drm_fb_helper.h |  6 +++---
> >  2 files changed, 14 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 418d299f3b12..859134e0d72d 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -320,11 +320,10 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
> >  }
> >  EXPORT_SYMBOL(drm_fb_helper_debug_leave);
> >
> > -static bool restore_fbdev_mode(struct drm_fb_helper *fb_helper)
> > +static int restore_fbdev_mode(struct drm_fb_helper *fb_helper)
> >  {
> > struct drm_device *dev = fb_helper->dev;
> > struct drm_plane *plane;
> > -   bool error = false;
> > int i;
> >
> > drm_warn_on_modeset_not_all_locked(dev);
> > @@ -348,14 +347,15 @@ static bool restore_fbdev_mode(struct drm_fb_helper 
> > *fb_helper)
> > if (crtc->funcs->cursor_set) {
> > ret = crtc->funcs->cursor_set(crtc, NULL, 0, 0, 0);
> > if (ret)
> > -   error = true;
> > +   return ret;
> > }
> >
> > ret = drm_mode_set_config_internal(mode_set);
> > if (ret)
> > -   error = true;
> > +   return ret;
> > }
> > -   return error;
> > +
> > +   return 0;
> >  }
> >
> >  /**
> > @@ -365,12 +365,15 @@ static bool restore_fbdev_mode(struct drm_fb_helper 
> > *fb_helper)
> >   * This should be called from driver's drm ->lastclose callback
> >   * when implementing an fbcon on top of kms using this helper. This 
> > ensures that
> >   * the user isn't greeted with a black screen when e.g. X dies.
> > + *
> > + * RETURNS:
> > + * Zero if everything went ok, negative error code otherwise.
> >   */
> > -bool drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper 
> > *fb_helper)
> > +int drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper 
> > *fb_helper)
> >  {
> > struct drm_device *dev = fb_helper->dev;
> > -   bool ret;
> > -   bool do_delayed = false;
> > +   bool do_delayed;
> > +   int ret;
> >
> > drm_modeset_lock_all(dev);
> > ret = restore_fbdev_mode(fb_helper);
> > diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> > index dbab4622b58f..67de1f10008e 100644
> > --- a/include/drm/drm_fb_helper.h
> > +++ b/include/drm/drm_fb_helper.h
> > @@ -136,7 +136,7 @@ int drm_fb_helper_set_par(struct fb_info *info);
> >  int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
> > struct fb_info *info);
> >
> > -bool drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper 
> > *fb_helper);
> > +int drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper 
> > *fb_helper);
> >
> >  struct fb_info *drm_fb_helper_alloc_fbi(struct drm_fb_helper *fb_helper);
> >  void drm_fb_helper_unregister_fbi(struct drm_fb_helper *fb_helper);
> > @@ -226,10 +226,10 @@ static inline int drm_fb_helper_check_var(struct 
> > fb_var_screeninfo *var,
> > return 0;
> >  }
> >
> > -static inline bool
> > +static inline int
> >  drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper)
> >  {
> > -   return true;
> > +   return 0;
> >  }
> >
> >  static inline struct fb_info *
> > --
> > 1.8.3.1
> >

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

Re: [Intel-gfx] [PATCH 3/4] drm/fb-helper: Add module option to disable fbdev emulation

[Daniel Vetter]

On Wed, Aug 26, 2015 at 01:34:58PM +0200, Daniel Vetter wrote:
> On Wed, Aug 26, 2015 at 02:14:37PM +0530, Archit Taneja wrote:
> > 
> > 
> > On 08/26/2015 10:42 AM, Archit Taneja wrote:
> > >
> > >
> > >On 08/25/2015 07:15 PM, Daniel Vetter wrote:
> > >>Faster than recompiling.
> > >>
> > >>Note that restore_fbdev_mode_unlocked is a bit special and the only
> > >>one which returns an error code when fbdev isn't there - i915 needs
> > >>that one to not fall over with some additional fbcon related restore
> > >>code. Everyone else just ignores the return value or only prints a
> > >>DRM_DEBUG level message.
> > >
> > >Reviewed-by:Archit Taneja 
> > 
> > 
> > With the module param, and the drivers should see the following state(
> > based on the truth table below):
> > 
> > module param | config option
> >true  |true   -> real helper funcs called, driver
> > allocated drm_fb_helper is correctly
> > populated.
> > 
> >false |true   -> real helper funcs called, but bailed
> > out early, driver allocated
> > drm_fb_helper is non-NULL, but we won't
> > end up using it.
> 
> Hm I tried to give drivers the same semantics here as with the stub
> functions. Where did I screw up? The goal really was to match the end
> result for drivers ...

Note that at least for i915 we can't make it perfectly equal since i915
compiles out a few more things with FBDEV_EMULATION=n than just the stubs.
Long-term we might want to push some of that into helpers too perhaps.
-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

Re: [Intel-gfx] [PATCH 1/3] drm/i915: read sink_count dpcd always

[Ville Syrjälä]

On Tue, Aug 25, 2015 at 05:20:36PM +0530, Sivakumar Thulasimani wrote:
> From: "Thulasimani,Sivakumar" 
> 
> This patch reads sink_count dpcd always and removes its
> read operation based on values in downstream port dpcd. Also
> we should read it irrespective of current status of sink.
> 
> SINK_COUNT dpcd is not dependent on DOWNSTREAM_PORT_PRESENT dpcd.
> SINK_COUNT denotes if a display is attached, while
> DOWNSTREAM_PORT_PRESET indicates how many ports are available
> in the dongle where display can be attached. so it is possible
> for sink count to change irrespective of value in downstream
> port dpcd.
> 
> Here is a table of possible values and scenarios
> 
> sink_countdownstream_port
>   present
> 0 0   no display is attached
> 0 1   dongle is connected without display
> 1 0   display connected directly
> 1 1   display connected through dongle
> 
> Signed-off-by: Sivakumar Thulasimani 
> ---
>  drivers/gpu/drm/i915/intel_dp.c |   33 ++---
>  1 file changed, 14 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 8a66a44..9e4e27d 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3898,6 +3898,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>   struct drm_device *dev = dig_port->base.base.dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   uint8_t rev;
> + uint8_t reg;
>  
>   if (intel_dp_dpcd_read_wake(&intel_dp->aux, 0x000, intel_dp->dpcd,
>   sizeof(intel_dp->dpcd)) < 0)
> @@ -3908,6 +3909,13 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>   if (intel_dp->dpcd[DP_DPCD_REV] == 0)
>   return false; /* DPCD not present */
>  
> + if (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_SINK_COUNT,
> + ®, 1) < 0)
> + return false;
> +
> + if (!DP_GET_SINK_COUNT(reg))
> + return false;
> +
>   /* Check if the panel supports PSR */
>   memset(intel_dp->psr_dpcd, 0, sizeof(intel_dp->psr_dpcd));
>   if (is_edp(intel_dp)) {
> @@ -4374,12 +4382,6 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
>  
>   WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
>  
> - if (!intel_encoder->base.crtc)
> - return;
> -
> - if (!to_intel_crtc(intel_encoder->base.crtc)->active)
> - return;
> -

I don't like trying to overload intel_dp_check_link_status() to do other
stuff besides link retraining. The sink irq stuff already snuck in
somehow, but I think we should pull it out and try to make the function
names match what they do.

The entire DP hpd locking also needs more though. We now grab the
connection_mutex for the retraining to prevent racing against modeset,
but it doesn't prevent racing against ->detect(). And for MST we take
no locks whatsoever, even for the retraining (I have a patch for that
that I'll send out soon).

>   /* Try to read receiver status if the link appears to be up */
>   if (!intel_dp_get_link_status(intel_dp, link_status)) {
>   return;
> @@ -4390,6 +4392,12 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
>   return;
>   }
>  
> + if (!intel_encoder->base.crtc)
> + return;
> +
> + if (!to_intel_crtc(intel_encoder->base.crtc)->active)
> + return;
> +
>   /* 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)) {
> @@ -4427,19 +4435,6 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
>   if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
>   return connector_status_connected;
>  
> - /* If we're HPD-aware, SINK_COUNT changes dynamically */
> - if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
> - intel_dp->downstream_ports[0] & DP_DS_PORT_HPD) {
> - uint8_t reg;
> -
> - if (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_SINK_COUNT,
> - ®, 1) < 0)
> - return connector_status_unknown;
> -
> - return DP_GET_SINK_COUNT(reg) ? connector_status_connected
> -   : connector_status_disconnected;
> - }
> -
>   /* If no HPD, poke DDC gently */
>   if (drm_probe_ddc(&intel_dp->aux.ddc))
>   return connector_status_connected;
> -- 
> 1.7.9.5

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

[Intel-gfx] Request Linux Graphic Driver for Intel GMA 3150

[David Ho]

Hello Linux Graphic Team members,

 

REQUEST

May I please request support for driver of Intel GMA 3150 for Ubuntu 14.04.3
32 bit (Trusty Tahr)?

I installed "Intel Graphic Installer for Linux" from 01.org, but it stops at
the very first step saying "Distribution not supported".

 

BACKGROUND

After fresh install of 14.04, the mouse pointer is not showing up and the
display change (when scrolling, moving between windows, etc) is very slow
(even only for regular application, never tried to watch video yet). I
concluded that this is the driver issue.

I must install it for around 20 PCs.

Please help me to get the correct driver.

 

Thank you.

 

Regards,

David Ho

 

 

-Original Message-
From: Chacn Limn, DanielX [mailto:danielx.chacn.l...@intel.com] 
Sent: 21 Agustus 2015 22:05
To: hupernikao...@gmail.com
Cc: Becerra Ruiz, Lilia; Flores Perez, Jimena; Diaz, Victor H
Subject: RE: [Contact] Intel GMA 3150 for Ubuntu 14.04.3Trusty Tahr 32bit

 

Hi David,

Thank you for contacting us.

 

For help or more information about Linux Graphics drivers please contact the
Team in charge through their mailing list:

  intel-gfx@lists.freedesktop.org

 

Regards,

Daniel.

 

[.MESSAGES TRUNCATED]

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

[Intel-gfx] [PATCH] drm/i915: Set the map-and-fenceable flag for preallocated objects

[Chris Wilson]

As we mark the preallocated objects as bound, we should also flag them
correctly as being map-and-fenceable (if appropriate!) so that latter
users do not get confused and try and rebind the pinned vma in order to
get a map-and-fenceable binding.

Signed-off-by: Chris Wilson 
Cc: "Goel, Akash" 
Cc: Daniel Vetter 
Cc: Jesse Barnes 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem.c | 43 +
 drivers/gpu/drm/i915/i915_gem_gtt.c |  1 +
 3 files changed, 26 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 55611d81ec6c..ec731e6db126 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2798,6 +2798,7 @@ i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj,
 
 int i915_vma_bind(struct i915_vma *vma, enum i915_cache_level cache_level,
  u32 flags);
+void __i915_vma_set_map_and_fenceable(struct i915_vma *vma);
 int __must_check i915_vma_unbind(struct i915_vma *vma);
 int i915_gem_object_put_pages(struct drm_i915_gem_object *obj);
 void i915_gem_release_all_mmaps(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 407b6b3576ae..39571e67f9a5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3980,6 +3980,29 @@ i915_vma_misplaced(struct i915_vma *vma, uint32_t 
alignment, uint64_t flags)
return false;
 }
 
+void __i915_vma_set_map_and_fenceable(struct i915_vma *vma)
+{
+   struct drm_i915_gem_object *obj = vma->obj;
+   bool mappable, fenceable;
+   u32 fence_size, fence_alignment;
+
+   fence_size = i915_gem_get_gtt_size(obj->base.dev,
+  obj->base.size,
+  obj->tiling_mode);
+   fence_alignment = i915_gem_get_gtt_alignment(obj->base.dev,
+obj->base.size,
+obj->tiling_mode,
+true);
+
+   fenceable = (vma->node.size == fence_size &&
+(vma->node.start & (fence_alignment - 1)) == 0);
+
+   mappable = (vma->node.start + fence_size <=
+   to_i915(obj->base.dev)->gtt.mappable_end);
+
+   obj->map_and_fenceable = mappable && fenceable;
+}
+
 static int
 i915_gem_object_do_pin(struct drm_i915_gem_object *obj,
   struct i915_address_space *vm,
@@ -4047,25 +4070,7 @@ i915_gem_object_do_pin(struct drm_i915_gem_object *obj,
 
if (ggtt_view && ggtt_view->type == I915_GGTT_VIEW_NORMAL &&
(bound ^ vma->bound) & GLOBAL_BIND) {
-   bool mappable, fenceable;
-   u32 fence_size, fence_alignment;
-
-   fence_size = i915_gem_get_gtt_size(obj->base.dev,
-  obj->base.size,
-  obj->tiling_mode);
-   fence_alignment = i915_gem_get_gtt_alignment(obj->base.dev,
-obj->base.size,
-obj->tiling_mode,
-true);
-
-   fenceable = (vma->node.size == fence_size &&
-(vma->node.start & (fence_alignment - 1)) == 0);
-
-   mappable = (vma->node.start + fence_size <=
-   dev_priv->gtt.mappable_end);
-
-   obj->map_and_fenceable = mappable && fenceable;
-
+   __i915_vma_set_map_and_fenceable(vma);
WARN_ON(flags & PIN_MAPPABLE && !obj->map_and_fenceable);
}
 
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4a76807143b1..112d84c32257 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2586,6 +2586,7 @@ static int i915_gem_setup_global_gtt(struct drm_device 
*dev,
return ret;
}
vma->bound |= GLOBAL_BIND;
+   __i915_vma_set_map_and_fenceable(vma);
}
 
/* Clear any non-preallocated blocks */
-- 
2.5.0

___
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: read sink_count dpcd always

[Sivakumar Thulasimani]

On 8/26/2015 5:21 PM, Ville Syrjälä wrote:

On Tue, Aug 25, 2015 at 05:20:36PM +0530, Sivakumar Thulasimani wrote:

From: "Thulasimani,Sivakumar" 

This patch reads sink_count dpcd always and removes its
read operation based on values in downstream port dpcd. Also
we should read it irrespective of current status of sink.

SINK_COUNT dpcd is not dependent on DOWNSTREAM_PORT_PRESENT dpcd.
SINK_COUNT denotes if a display is attached, while
DOWNSTREAM_PORT_PRESET indicates how many ports are available
in the dongle where display can be attached. so it is possible
for sink count to change irrespective of value in downstream
port dpcd.

Here is a table of possible values and scenarios

sink_count  downstream_port
present
0   0   no display is attached
0   1   dongle is connected without display
1   0   display connected directly
1   1   display connected through dongle

Signed-off-by: Sivakumar Thulasimani 
---
  drivers/gpu/drm/i915/intel_dp.c |   33 ++---
  1 file changed, 14 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8a66a44..9e4e27d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3898,6 +3898,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
struct drm_device *dev = dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
uint8_t rev;
+   uint8_t reg;
  
  	if (intel_dp_dpcd_read_wake(&intel_dp->aux, 0x000, intel_dp->dpcd,

sizeof(intel_dp->dpcd)) < 0)
@@ -3908,6 +3909,13 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
if (intel_dp->dpcd[DP_DPCD_REV] == 0)
return false; /* DPCD not present */
  
+	if (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_SINK_COUNT,

+   ®, 1) < 0)
+   return false;
+
+   if (!DP_GET_SINK_COUNT(reg))
+   return false;
+
/* Check if the panel supports PSR */
memset(intel_dp->psr_dpcd, 0, sizeof(intel_dp->psr_dpcd));
if (is_edp(intel_dp)) {
@@ -4374,12 +4382,6 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
  
  	WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
  
-	if (!intel_encoder->base.crtc)

-   return;
-
-   if (!to_intel_crtc(intel_encoder->base.crtc)->active)
-   return;
-

I don't like trying to overload intel_dp_check_link_status() to do other
stuff besides link retraining. The sink irq stuff already snuck in
somehow, but I think we should pull it out and try to make the function
names match what they do.

The entire DP hpd locking also needs more though. We now grab the
connection_mutex for the retraining to prevent racing against modeset,
but it doesn't prevent racing against ->detect(). And for MST we take
no locks whatsoever, even for the retraining (I have a patch for that
that I'll send out soon).
Agree, i am still thinking on how to extract the Automated test request 
part so

we can avoid having same code twice in intel_dp_detect() and in
intel_dp_check_link_status. if your patch also cleans up this function i can
rebase on top of it.

/* Try to read receiver status if the link appears to be up */
if (!intel_dp_get_link_status(intel_dp, link_status)) {
return;
@@ -4390,6 +4392,12 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
return;
}
  
+	if (!intel_encoder->base.crtc)

+   return;
+
+   if (!to_intel_crtc(intel_encoder->base.crtc)->active)
+   return;
+
/* 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)) {
@@ -4427,19 +4435,6 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
return connector_status_connected;
  
-	/* If we're HPD-aware, SINK_COUNT changes dynamically */

-   if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
-   intel_dp->downstream_ports[0] & DP_DS_PORT_HPD) {
-   uint8_t reg;
-
-   if (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_SINK_COUNT,
-   ®, 1) < 0)
-   return connector_status_unknown;
-
-   return DP_GET_SINK_COUNT(reg) ? connector_status_connected
- : connector_status_disconnected;
-   }
-
/* If no HPD, poke DDC gently */
if (drm_probe_ddc(&intel_dp->aux.ddc))
return connector_status_connected;
--
1.7.9.5


--
regards,
Sivakumar

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedes

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Support DDI lane reversal for DP

[Sivakumar Thulasimani]

On 8/18/2015 1:36 AM, Benjamin Tissoires wrote:

On Aug 14 2015 or thereabouts, Stéphane Marchesin wrote:

On Wed, Aug 5, 2015 at 12:34 PM, Benjamin Tissoires
 wrote:

On Jul 30 2015 or thereabouts, Sivakumar Thulasimani wrote:


On 7/29/2015 8:52 PM, Benjamin Tissoires wrote:

On Jul 29 2015 or thereabouts, Sivakumar Thulasimani wrote:

why not detect reverse in intel_dp_detect/intel_hpd_pulse ? that way you can
identify both lane count and reversal state without touching anything in the
link training code. i am yet to upstream my changes for CHT that i can share
if required that does the same in intel_dp_detect without touching any line
in link training path.

With my current limited knowledge of the dp hotplug (and i915 driver) I
am not sure we could detect the reversed state without trying to train 1
lane only. I'd be glad to look at your changes and test them on my
system if you think that could help having a cleaner solution.

Cheers,
Benjamin

No, what i recommended was to do link training but in intel_dp_detect. Since
USB Type C cable
also has its own lane count restriction (it can have different lane count
than the one supported
by panel) you might have to figure that out as well. so both reversal and
lane count detection
can be done outside the modeset path and keep the code free of type C
changes outside
detection path.

Please find below the code to do the same. Do not waste time trying to apply
this directly on
nightly since this is based on a local tree and because this is pre- atomic
changes code, so you
might have to modify chv_upfront_link_train to work on top of the latest
nightly code. we
are supposed to upstream this and is in my todo list.


[original patch snipped...]

Hi Sivakumar,

So I managed to manually re-apply your patch on top of
drm-intel-nightly, and tried to port it to make Broadwell working too.
It works OK if the system is already boot without any external DP used.
In this case, the detection works and I can see my external monitor
working properly.

However, if the monitor is cold plugged, the cpu/GPU hangs and I can not
understand why. I think I enabled all that is mentioned in the PRM to be
able to train the DP link, but I am obviously missing something else.
Can you have a look?


Hi Benjamin,

I would recommend against this approach. Some adapters will claim that
they recovered a clock even when it isn't on the lanes you enabled,
which means that the reversal detection doesn't always work. The only
reliable way to do this is to go talk to the Chrome OS EC (you can
find these patches later in the Chrome OS tree). It's not as generic,
but we might be able to abstract that logic, maybe.


Hi Stéphane,

This is a very good news. I was afraid we would not have access to the
hardware controller because the Intel controller hub spec was not
public.

I will try to have a look at it, but the latest chromeos branch (3.18)
seems to differ quite a lot from the upstream one. Anyway, fingers
crossed.

Cheers,
Benjamin

Hi Benjamin/Stéphan,
All Intel platforms (at-least those i inquired about) handle lane 
reversal in HW.
your statement that link training will pass even on reversed lane seems 
to point

to the same fact. in such a scenario why should the encoder/connector care
if the lane is reversed or not ?

--
regards,
Sivakumar

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