Re: [Intel-gfx] [PATCH 1/3] drm/i915: Enable FBC at Haswell.

2013-04-09 Thread Ville Syrjälä
On Mon, Apr 08, 2013 at 06:49:42PM -0300, Rodrigo Vivi wrote:
 This patch introduce Frame Buffer Compression (FBC) support for HSW.
 It adds a new function haswell_enable_fbc to avoid getting
 ironlake_enable_fbc messed with many IS_HASWELL checks.
 
 Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
 ---
  drivers/gpu/drm/i915/i915_drv.c |  1 +
  drivers/gpu/drm/i915/i915_reg.h |  6 ++
  drivers/gpu/drm/i915/intel_pm.c | 44 
 -
  3 files changed, 50 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
 index 0cfc778..88fd6fb 100644
 --- a/drivers/gpu/drm/i915/i915_drv.c
 +++ b/drivers/gpu/drm/i915/i915_drv.c
 @@ -291,6 +291,7 @@ static const struct intel_device_info 
 intel_haswell_m_info = {
   GEN7_FEATURES,
   .is_haswell = 1,
   .is_mobile = 1,
 + .has_fbc = 1,
  };
  
  static const struct pci_device_id pciidlist[] = {/* aka */
 diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
 index 5e91fbb..cb8e213 100644
 --- a/drivers/gpu/drm/i915/i915_reg.h
 +++ b/drivers/gpu/drm/i915/i915_reg.h
 @@ -849,6 +849,12 @@
  #define   SNB_CPU_FENCE_ENABLE   (129)
  #define DPFC_CPU_FENCE_OFFSET0x100104
  
 +/* Framebuffer compression for Haswell */
 +#define HSW_FBC_RT_BASE  0x7020
 +#define   HSW_FBC_RT_BASE_ADDR_SHIFT 12
 +
 +#define   HSW_DPFC_CTL_FENCE_EN  (128)
 +#define   HSW_DPFC_CTL_DISABLE_SLB_INIT  (115)
  
  /*
   * GPIO regs
 diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
 index 27f94cd..94e1c3a 100644
 --- a/drivers/gpu/drm/i915/intel_pm.c
 +++ b/drivers/gpu/drm/i915/intel_pm.c
 @@ -253,6 +253,43 @@ static bool ironlake_fbc_enabled(struct drm_device *dev)
   return I915_READ(ILK_DPFC_CONTROL)  DPFC_CTL_EN;
  }
  
 +static void haswell_enable_fbc(struct drm_crtc *crtc, unsigned long interval)
 +{
 + struct drm_device *dev = crtc-dev;
 + struct drm_i915_private *dev_priv = dev-dev_private;
 + struct drm_framebuffer *fb = crtc-fb;
 + struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
 + struct drm_i915_gem_object *obj = intel_fb-obj;
 + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
 + int plane = intel_crtc-plane == 0 ? DPFC_CTL_PLANEA : DPFC_CTL_PLANEB;
 + unsigned long stall_watermark = 200;
 + u32 dpfc_ctl;
 +
 + dpfc_ctl = I915_READ(ILK_DPFC_CONTROL);
 + dpfc_ctl |= (plane | DPFC_CTL_LIMIT_1X);

Accroding to BSpec FBC is always tied to plane A. Bit 30 is MBZ.

Maybe fix up plane C FBC support for IVB while you're poking at the
general direction?

 + dpfc_ctl |= (HSW_DPFC_CTL_FENCE_EN | obj-fence_reg);

The CPU fence field must be written with 0. SNB/IVB could do with the
same fix.

 + dpfc_ctl |= HSW_DPFC_CTL_DISABLE_SLB_INIT;
 + I915_WRITE(ILK_DPFC_RECOMP_CTL, DPFC_RECOMP_STALL_EN |
 +(stall_watermark  DPFC_RECOMP_STALL_WM_SHIFT) |
 +(interval  DPFC_RECOMP_TIMER_COUNT_SHIFT));
 + I915_WRITE(HSW_FBC_RT_BASE,
 +obj-gtt_offset  HSW_FBC_RT_BASE_ADDR_SHIFT |
 +ILK_FBC_RT_VALID);
 + /* enable it... */
 + I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN);
 +
 + if (obj-fence_reg != I915_FENCE_REG_NONE) {
 + I915_WRITE(SNB_DPFC_CTL_SA,
 +SNB_CPU_FENCE_ENABLE | obj-fence_reg);
 + I915_WRITE(DPFC_CPU_FENCE_OFFSET, crtc-y);
 + } else
 + I915_WRITE(SNB_DPFC_CTL_SA, ~SNB_CPU_FENCE_ENABLE);
 +
 + sandybridge_blit_fbc_update(dev);
 +
 + DRM_DEBUG_KMS(enabled fbc on plane %d\n, intel_crtc-plane);
 +}
 +
  bool intel_fbc_enabled(struct drm_device *dev)
  {
   struct drm_i915_private *dev_priv = dev-dev_private;
 @@ -4158,7 +4195,12 @@ void intel_init_pm(struct drm_device *dev)
   if (I915_HAS_FBC(dev)) {
   if (HAS_PCH_SPLIT(dev)) {
   dev_priv-display.fbc_enabled = ironlake_fbc_enabled;
 - dev_priv-display.enable_fbc = ironlake_enable_fbc;
 + if (IS_HASWELL(dev))
 + dev_priv-display.enable_fbc =
 + haswell_enable_fbc;
 + else
 + dev_priv-display.enable_fbc =
 + ironlake_enable_fbc;
   dev_priv-display.disable_fbc = ironlake_disable_fbc;
   } else if (IS_GM45(dev)) {
   dev_priv-display.fbc_enabled = g4x_fbc_enabled;
 -- 
 1.8.1.4
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


Re: [Intel-gfx] [PATCH 3/3] drm/i915: HSW FBC WaFbcDisableDpfcClockGating

2013-04-09 Thread Ville Syrjälä
On Mon, Apr 08, 2013 at 06:49:44PM -0300, Rodrigo Vivi wrote:
 Display register 46500h bit 23 must be set to 1b for the entire time that
 Frame Buffer Compression is enabled.

So should we enable it again after FBC is disabled to avoid wasting
power?

 
 Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
 ---
  drivers/gpu/drm/i915/i915_reg.h | 3 +++
  drivers/gpu/drm/i915/intel_pm.c | 2 ++
  2 files changed, 5 insertions(+)
 
 diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
 index 2340bc2..2ef0292 100644
 --- a/drivers/gpu/drm/i915/i915_reg.h
 +++ b/drivers/gpu/drm/i915/i915_reg.h
 @@ -863,6 +863,9 @@
_HSW_PIPE_SLICE_CHICKEN_1_A, + \
_HSW_PIPE_SLICE_CHICKEN_1_B)
  
 +#define HSW_CLKGATE_DISABLE_PART_1   0x46500
 +#define   HSW_DPFC_GATING_DISABLE(123)
 +
  /*
   * GPIO regs
   */
 diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
 index 0628a84..f2ce541 100644
 --- a/drivers/gpu/drm/i915/intel_pm.c
 +++ b/drivers/gpu/drm/i915/intel_pm.c
 @@ -281,6 +281,8 @@ static void haswell_enable_fbc(struct drm_crtc *crtc, 
 unsigned long interval)
   /* WaFbcAsynchFlipDisableFbcQueue */
   I915_WRITE(HSW_PIPE_SLICE_CHICKEN_1(intel_crtc-pipe),
  HSW_BYPASS_FBC_QUEUE);
 + /* WaFbcDisableDpfcClockGating */
 + I915_WRITE(HSW_CLKGATE_DISABLE_PART_1, HSW_DPFC_GATING_DISABLE);
  
   if (obj-fence_reg != I915_FENCE_REG_NONE) {
   I915_WRITE(SNB_DPFC_CTL_SA,
 -- 
 1.8.1.4
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


[Intel-gfx] [PATCH 1/2] drm/i915: IVB/HSW have 32 fence register

2013-04-09 Thread ville . syrjala
From: Ville Syrjälä ville.syrj...@linux.intel.com

Increase the number of fence registers to 32 on IVB/HSW. VLV however
only has 16 fence registers according to the docs.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_drv.h | 6 +++---
 drivers/gpu/drm/i915/i915_gem.c | 4 +++-
 drivers/gpu/drm/i915/i915_irq.c | 2 +-
 3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 69ddfd1..fa8ca2f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -195,9 +195,9 @@ struct drm_i915_master_private {
struct _drm_i915_sarea *sarea_priv;
 };
 #define I915_FENCE_REG_NONE -1
-#define I915_MAX_NUM_FENCES 16
-/* 16 fences + sign bit for FENCE_REG_NONE */
-#define I915_MAX_NUM_FENCE_BITS 5
+#define I915_MAX_NUM_FENCES 32
+/* 32 fences + sign bit for FENCE_REG_NONE */
+#define I915_MAX_NUM_FENCE_BITS 6
 
 struct drm_i915_fence_reg {
struct list_head lru_list;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 63c05dd..211ce8f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4184,7 +4184,9 @@ i915_gem_load(struct drm_device *dev)
if (!drm_core_check_feature(dev, DRIVER_MODESET))
dev_priv-fence_reg_start = 3;
 
-   if (INTEL_INFO(dev)-gen = 4 || IS_I945G(dev) || IS_I945GM(dev) || 
IS_G33(dev))
+   if (INTEL_INFO(dev)-gen = 7  !IS_VALLEYVIEW(dev))
+   dev_priv-num_fence_regs = 32;
+   else if (INTEL_INFO(dev)-gen = 4 || IS_I945G(dev) || IS_I945GM(dev) 
|| IS_G33(dev))
dev_priv-num_fence_regs = 16;
else
dev_priv-num_fence_regs = 8;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index fc35d52..985d1f5 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1217,7 +1217,7 @@ static void i915_gem_record_fences(struct drm_device *dev,
switch (INTEL_INFO(dev)-gen) {
case 7:
case 6:
-   for (i = 0; i  16; i++)
+   for (i = 0; i  dev_priv-num_fence_regs; i++)
error-fence[i] = I915_READ64(FENCE_REG_SANDYBRIDGE_0 + 
(i * 8));
break;
case 5:
-- 
1.8.1.5

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


[Intel-gfx] [PATCH 2/2] drm/i915: Increase max fence pitch limit to 256KB on IVB+

2013-04-09 Thread ville . syrjala
From: Ville Syrjälä ville.syrj...@linux.intel.com

BSpec contains several scattered notes which state that the maximum
fence stride was increased to 256KB on IVB.

Testing on real hardware agrees.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_gem_tiling.c | 9 ++---
 drivers/gpu/drm/i915/i915_reg.h| 1 +
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c 
b/drivers/gpu/drm/i915/i915_gem_tiling.c
index c807eb9..139d17d 100644
--- a/drivers/gpu/drm/i915/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
@@ -217,9 +217,12 @@ i915_tiling_ok(struct drm_device *dev, int stride, int 
size, int tiling_mode)
tile_width = 512;
 
/* check maximum stride  object size */
-   if (INTEL_INFO(dev)-gen = 4) {
-   /* i965 stores the end address of the gtt mapping in the fence
-* reg, so dont bother to check the size */
+   /* i965+ stores the end address of the gtt mapping in the fence
+* reg, so dont bother to check the size */
+   if (INTEL_INFO(dev)-gen = 7) {
+   if (stride / 128  GEN7_FENCE_MAX_PITCH_VAL)
+   return false;
+   } else if (INTEL_INFO(dev)-gen = 4) {
if (stride / 128  I965_FENCE_MAX_PITCH_VAL)
return false;
} else {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0e4b7fb..ec4e054 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -424,6 +424,7 @@
 
 #define FENCE_REG_SANDYBRIDGE_00x10
 #define   SANDYBRIDGE_FENCE_PITCH_SHIFT32
+#define   GEN7_FENCE_MAX_PITCH_VAL 0x0800
 
 /* control register for cpu gtt access */
 #define TILECTL0x101000
-- 
1.8.1.5

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


Re: [Intel-gfx] [PATCH 03/10] drm/i915: Map registers before GTT init

2013-04-09 Thread Daniel Vetter
On Mon, Apr 08, 2013 at 06:43:49PM -0700, Ben Widawsky wrote:
 This will allow us to read/write registers in GTT init.
 
 Signed-off-by: Ben Widawsky b...@bwidawsk.net
 ---
  drivers/gpu/drm/i915/i915_dma.c | 48 
 -
  1 file changed, 24 insertions(+), 24 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
 index 4a1a517..ad7f284 100644
 --- a/drivers/gpu/drm/i915/i915_dma.c
 +++ b/drivers/gpu/drm/i915/i915_dma.c
 @@ -1518,6 +1518,28 @@ int i915_driver_load(struct drm_device *dev, unsigned 
 long flags)
   goto free_priv;
   }
  
 + mmio_bar = IS_GEN2(dev) ? 1 : 0;
 + /* Before gen4, the registers and the GTT are behind different BARs.
 +  * However, from gen4 onwards, the registers and the GTT are shared
 +  * in the same BAR, so we want to restrict this ioremap from
 +  * clobbering the GTT which we want ioremap_wc instead. Fortunately,
 +  * the register BAR remains the same size for all the earlier
 +  * generations up to Ironlake.
 +  */
 + if (info-gen  5)
 + mmio_size = 512*1024;
 + else
 + mmio_size = 2*1024*1024;
 +
 + dev_priv-regs = pci_iomap(dev-pdev, mmio_bar, mmio_size);
 + if (!dev_priv-regs) {
 + DRM_ERROR(failed to map registers\n);
 + ret = -EIO;
 + goto put_gmch;

goto put_bridge is what I've fixed up here.

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

 + }
 +
 + intel_early_sanitize_regs(dev);
 +
   ret = i915_gem_gtt_init(dev);
   if (ret)
   goto put_bridge;
 @@ -1542,28 +1564,6 @@ int i915_driver_load(struct drm_device *dev, unsigned 
 long flags)
   if (IS_BROADWATER(dev) || IS_CRESTLINE(dev))
   dma_set_coherent_mask(dev-pdev-dev, DMA_BIT_MASK(32));
  
 - mmio_bar = IS_GEN2(dev) ? 1 : 0;
 - /* Before gen4, the registers and the GTT are behind different BARs.
 -  * However, from gen4 onwards, the registers and the GTT are shared
 -  * in the same BAR, so we want to restrict this ioremap from
 -  * clobbering the GTT which we want ioremap_wc instead. Fortunately,
 -  * the register BAR remains the same size for all the earlier
 -  * generations up to Ironlake.
 -  */
 - if (info-gen  5)
 - mmio_size = 512*1024;
 - else
 - mmio_size = 2*1024*1024;
 -
 - dev_priv-regs = pci_iomap(dev-pdev, mmio_bar, mmio_size);
 - if (!dev_priv-regs) {
 - DRM_ERROR(failed to map registers\n);
 - ret = -EIO;
 - goto put_gmch;
 - }
 -
 - intel_early_sanitize_regs(dev);
 -
   aperture_size = dev_priv-gtt.mappable_end;
  
   dev_priv-gtt.mappable =
 @@ -1686,10 +1686,10 @@ out_mtrrfree:
   dev_priv-mm.gtt_mtrr = -1;
   }
   io_mapping_free(dev_priv-gtt.mappable);
 -out_rmmap:
 - pci_iounmap(dev-pdev, dev_priv-regs);
  put_gmch:
   dev_priv-gtt.gtt_remove(dev);
 +out_rmmap:
 + pci_iounmap(dev-pdev, dev_priv-regs);
  put_bridge:
   pci_dev_put(dev_priv-bridge_dev);
  free_priv:
 -- 
 1.8.2.1
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915: The timeout for wait_timeout_ioctl is only valid upon success

2013-04-09 Thread Chris Wilson
As we only update and sanitize the return timeout value after a
successful wait, we should not assert that it is valid for any error
returns. Also, for consistency, we should only modify args-timeout_ns
upon success.

Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/i915_gem.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 63c05dd..da78cf7 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2377,7 +2377,7 @@ i915_gem_wait_ioctl(struct drm_device *dev, void *data, 
struct drm_file *file)
mutex_unlock(dev-struct_mutex);
 
ret = __wait_seqno(ring, seqno, reset_counter, true, timeout);
-   if (timeout) {
+   if (ret == 0  timeout) {
WARN_ON(!timespec_valid(timeout));
args-timeout_ns = timespec_to_ns(timeout);
}
-- 
1.7.10.4

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


Re: [Intel-gfx] [PATCH] drm/i915: The timeout for wait_timeout_ioctl is only valid upon success

2013-04-09 Thread Daniel Vetter
On Tue, Apr 09, 2013 at 09:58:15AM +0100, Chris Wilson wrote:
 As we only update and sanitize the return timeout value after a
 successful wait, we should not assert that it is valid for any error
 returns. Also, for consistency, we should only modify args-timeout_ns
 upon success.

Doesn't that break our -EAGAIN trickery?
-Daniel

 
 Cc: Ville Syrjälä ville.syrj...@linux.intel.com
 Cc: Ben Widawsky b...@bwidawsk.net
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 ---
  drivers/gpu/drm/i915/i915_gem.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
 index 63c05dd..da78cf7 100644
 --- a/drivers/gpu/drm/i915/i915_gem.c
 +++ b/drivers/gpu/drm/i915/i915_gem.c
 @@ -2377,7 +2377,7 @@ i915_gem_wait_ioctl(struct drm_device *dev, void *data, 
 struct drm_file *file)
   mutex_unlock(dev-struct_mutex);
  
   ret = __wait_seqno(ring, seqno, reset_counter, true, timeout);
 - if (timeout) {
 + if (ret == 0  timeout) {
   WARN_ON(!timespec_valid(timeout));
   args-timeout_ns = timespec_to_ns(timeout);
   }
 -- 
 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
+41 (0) 79 365 57 48 - 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 10/10] drm/i915: Allow PPGTT enable to fail

2013-04-09 Thread Daniel Vetter
On Mon, Apr 08, 2013 at 06:43:56PM -0700, Ben Widawsky wrote:
 From: Ben Widawsky benjamin.widaw...@intel.com
 
 I'm really not happy that we have to support this, but this will be the
 simplest way to handle cases where PPGTT init can fail, which I promise
 will be coming in the future.
 
 v2: Resolve conflicts due to patch series reordering.
 
 Signed-off-by: Ben Widawsky b...@bwidawsk.net (v1)
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

Queued all 10 patches for -next, thanks.
-Daniel

 ---
  drivers/gpu/drm/i915/i915_drv.c | 7 +--
  drivers/gpu/drm/i915/i915_drv.h | 2 +-
  drivers/gpu/drm/i915/i915_gem.c | 9 +++--
  drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ++-
  4 files changed, 15 insertions(+), 6 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
 index 70d10de..bddb9a5 100644
 --- a/drivers/gpu/drm/i915/i915_drv.c
 +++ b/drivers/gpu/drm/i915/i915_drv.c
 @@ -927,8 +927,11 @@ int i915_reset(struct drm_device *dev)
   ring-init(ring);
  
   i915_gem_context_init(dev);
 - if (dev_priv-mm.aliasing_ppgtt)
 - dev_priv-mm.aliasing_ppgtt-enable(dev);
 + if (dev_priv-mm.aliasing_ppgtt) {
 + ret = dev_priv-mm.aliasing_ppgtt-enable(dev);
 + if (ret)
 + i915_gem_cleanup_aliasing_ppgtt(dev);
 + }
  
   /*
* It would make sense to re-init all the other hw state, at
 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index c121321..f59a388 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -449,7 +449,7 @@ struct i915_hw_ppgtt {
  struct sg_table *st,
  unsigned int pg_start,
  enum i915_cache_level cache_level);
 - void (*enable)(struct drm_device *dev);
 + int (*enable)(struct drm_device *dev);
   void (*cleanup)(struct i915_hw_ppgtt *ppgtt);
  };
  
 diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
 index 8a73a68..da6d6de 100644
 --- a/drivers/gpu/drm/i915/i915_gem.c
 +++ b/drivers/gpu/drm/i915/i915_gem.c
 @@ -4029,8 +4029,13 @@ i915_gem_init_hw(struct drm_device *dev)
* contexts before PPGTT.
*/
   i915_gem_context_init(dev);
 - if (dev_priv-mm.aliasing_ppgtt)
 - dev_priv-mm.aliasing_ppgtt-enable(dev);
 + if (dev_priv-mm.aliasing_ppgtt) {
 + ret = dev_priv-mm.aliasing_ppgtt-enable(dev);
 + if (ret) {
 + i915_gem_cleanup_aliasing_ppgtt(dev);
 + DRM_INFO(PPGTT enable failed. This is not fatal, but 
 unexpected\n);
 + }
 + }
  
   return 0;
  }
 diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
 b/drivers/gpu/drm/i915/i915_gem_gtt.c
 index d32912e..11143b4 100644
 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
 +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
 @@ -75,7 +75,7 @@ static inline gen6_gtt_pte_t gen6_pte_encode(struct 
 drm_device *dev,
   return pte;
  }
  
 -static void gen6_ppgtt_enable(struct drm_device *dev)
 +static int gen6_ppgtt_enable(struct drm_device *dev)
  {
   drm_i915_private_t *dev_priv = dev-dev_private;
   uint32_t pd_offset;
 @@ -128,6 +128,7 @@ static void gen6_ppgtt_enable(struct drm_device *dev)
   I915_WRITE(RING_PP_DIR_DCLV(ring), PP_DIR_DCLV_2G);
   I915_WRITE(RING_PP_DIR_BASE(ring), pd_offset);
   }
 + return 0;
  }
  
  /* PPGTT support for Sandybdrige/Gen6 and later */
 -- 
 1.8.2.1
 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915: Always normalize return timeout for wait_timeout_ioctl

2013-04-09 Thread Chris Wilson
As we recompute the remaining timeout after waiting, there is a
potential for that timeout to be less than zero and so need sanitizing.
The timeout is always returned to userspace and validated, so we should
always perform the sanitation.

Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/i915_gem.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 63c05dd..fcf8492 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1045,6 +1045,7 @@ static int __wait_seqno(struct intel_ring_buffer *ring, 
u32 seqno,
if (timeout) {
struct timespec sleep_time = timespec_sub(now, before);
*timeout = timespec_sub(*timeout, sleep_time);
+   set_normalized_timespec(timeout, 0, 0);
}
 
switch (end) {
@@ -1053,8 +1054,6 @@ static int __wait_seqno(struct intel_ring_buffer *ring, 
u32 seqno,
case -ERESTARTSYS: /* Signal */
return (int)end;
case 0: /* Timeout */
-   if (timeout)
-   set_normalized_timespec(timeout, 0, 0);
return -ETIME;
default: /* Completed */
WARN_ON(end  0); /* We're not aware of other errors */
-- 
1.7.10.4

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


[Intel-gfx] [PATCH v3 0/7] Add HPD interrupt storm detection.

2013-04-09 Thread Egbert Eich
This set of patches contains the remaining bits to add IRQ strom detection and
disabling.
Daniel has asked me to send this batch as soon as possible even though this
latest batch has not yet been retested, yet.


Egbert Eich (7):
  drm/i915: Add HPD IRQ storm detection (v4)
  drm/i915: (re)init HPD interrupt storm statistics
  drm/i915: Mask out the HPD irq bits before setting them individually.
  drm/i915: Disable HPD interrupt on pin when irq storm is detected (v2)
  drm/i915: Add Reenable Timer to turn Hotplug Detection back on (v3)
  drm/i915: Add bit field to record which pins have received HPD events
(v2)
  drm/i915: Only reprobe display on encoder which has received an HPD
event

 drivers/gpu/drm/i915/i915_drv.h   |  12 ++
 drivers/gpu/drm/i915/i915_irq.c   | 224 ++
 drivers/gpu/drm/i915/intel_crt.c  |   6 +-
 drivers/gpu/drm/i915/intel_dp.c   |   1 -
 drivers/gpu/drm/i915/intel_drv.h  |   4 +
 drivers/gpu/drm/i915/intel_hdmi.c |   1 -
 drivers/gpu/drm/i915/intel_sdvo.c |   5 +-
 drivers/gpu/drm/i915/intel_tv.c   |   2 +-
 8 files changed, 221 insertions(+), 34 deletions(-)

-- 
1.8.1.4

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


[Intel-gfx] [PATCH v3 1/7] drm/i915: Add HPD IRQ storm detection (v4)

2013-04-09 Thread Egbert Eich
From: Egbert Eich e...@suse.de

Add a hotplug IRQ storm detection (triggered when a hotplug interrupt
fires more than 5 times / sec).
Rationale:
Despite of the many attempts to fix the problem with noisy hotplug
interrupt lines we are still seeing systems which have issues:
Once cause of noise seems to be bad routing of the hotplug line
on the board: cross talk from other signals seems to cause erronous
hotplug interrupts. This has been documented as an erratum for the
the i945GM chipset and thus hotplug support was disabled for this
chipset model but others seem to have this problem, too.

We have seen this issue on a G35 motherboard for example:
Even different motherboards of the same model seem to behave
differently: while some only see only around 10-100 interrupts/s
others seem to see 5k or more.
We've also observed a dependency on the selected video mode.

Also on certain laptops interrupt noise seems to occur duing
battery charging when the battery is at a certain charge levels.

Thus we add a simple algorithm here that detects an 'interrupt storm'
condition.

v2: Fixed comment.
v3: Reordered drm_i915_private: moved hpd state tracking to hotplug work stuff.
v4: Followed by Jesse Barnes to use a time_..() macro.

Signed-off-by: Egbert Eich e...@suse.de
Acked-by: Chris Wilson ch...@chris-wilson.co.uk
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
---
 drivers/gpu/drm/i915/i915_drv.h |  9 ++
 drivers/gpu/drm/i915/i915_irq.c | 66 +
 2 files changed, 63 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 44fca0b..83fc1a6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -929,6 +929,15 @@ typedef struct drm_i915_private {
 
struct work_struct hotplug_work;
bool enable_hotplug_processing;
+   struct {
+   unsigned long hpd_last_jiffies;
+   int hpd_cnt;
+   enum {
+   HPD_ENABLED = 0,
+   HPD_DISABLED = 1,
+   HPD_MARK_DISABLED = 2
+   } hpd_mark;
+   } hpd_stats[HPD_NUM_PINS];
 
int num_pch_pll;
int num_plane;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 4c5bdd0..32b5527 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -582,6 +582,37 @@ static void gen6_queue_rps_work(struct drm_i915_private 
*dev_priv,
queue_work(dev_priv-wq, dev_priv-rps.work);
 }
 
+#define HPD_STORM_DETECT_PERIOD 1000
+
+static inline void hotplug_irq_storm_detect(struct drm_device *dev,
+   u32 hotplug_trigger,
+   const u32 *hpd)
+{
+   drm_i915_private_t *dev_priv = dev-dev_private;
+   unsigned long irqflags;
+   int i;
+
+   spin_lock_irqsave(dev_priv-irq_lock, irqflags);
+
+   for (i = 1; i  HPD_NUM_PINS; i++) {
+   if ((hpd[i]  hotplug_trigger) 
+   dev_priv-hpd_stats[i].hpd_mark == HPD_ENABLED) {
+   if (!time_in_range(jiffies, 
dev_priv-hpd_stats[i].hpd_last_jiffies,
+ 
dev_priv-hpd_stats[i].hpd_last_jiffies
+ + 
msecs_to_jiffies(HPD_STORM_DETECT_PERIOD))) {
+   dev_priv-hpd_stats[i].hpd_last_jiffies = 
jiffies;
+   dev_priv-hpd_stats[i].hpd_cnt = 0;
+   } else if (dev_priv-hpd_stats[i].hpd_cnt  5) {
+   dev_priv-hpd_stats[i].hpd_mark = 
HPD_MARK_DISABLED;
+   DRM_DEBUG_KMS(HPD interrupt storm detected on  
PIN %d\n, i);
+   } else
+   dev_priv-hpd_stats[i].hpd_cnt++;
+   }
+   }
+
+   spin_unlock_irqrestore(dev_priv-irq_lock, irqflags);
+}
+
 static void gmbus_irq_handler(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = (drm_i915_private_t *) 
dev-dev_private;
@@ -650,13 +681,15 @@ static irqreturn_t valleyview_irq_handler(int irq, void 
*arg)
/* Consume port.  Then clear IIR or we'll miss events */
if (iir  I915_DISPLAY_PORT_INTERRUPT) {
u32 hotplug_status = I915_READ(PORT_HOTPLUG_STAT);
+   u32 hotplug_trigger = hotplug_status  
HOTPLUG_INT_STATUS_I915;
 
DRM_DEBUG_DRIVER(hotplug event received, stat 
0x%08x\n,
 hotplug_status);
-   if (hotplug_status  HOTPLUG_INT_STATUS_I915)
+   if (hotplug_trigger) {
+   hotplug_irq_storm_detect(dev, hotplug_trigger, 
hpd_status_i915);
queue_work(dev_priv-wq,
   dev_priv-hotplug_work);
-
+   

[Intel-gfx] [PATCH v3 2/7] drm/i915: (re)init HPD interrupt storm statistics

2013-04-09 Thread Egbert Eich
From: Egbert Eich e...@suse.de

When an encoder is shared on several connectors there is only
one hotplug line, thus this line needs to be shared among these
connectors.
If HPD detect only works reliably on a subset of those connectors,
we want to poll the others. Thus we need to make sure that storm
detection doesn't mess up the settings for those connectors.
Therefore we store the settings in the intel_connector struct and
restore them from there.
If nothing is set but the encoder has a hpd_pin set we assume this
connector is hotplug capable.
On init/reset we make sure the polled state of the connectors
is (re)set to the default value, the HPD interrupts are marked
enabled.

Signed-off-by: Egbert Eich e...@suse.de
---
 drivers/gpu/drm/i915/i915_irq.c   | 13 +
 drivers/gpu/drm/i915/intel_crt.c  |  6 ++
 drivers/gpu/drm/i915/intel_dp.c   |  1 -
 drivers/gpu/drm/i915/intel_drv.h  |  4 
 drivers/gpu/drm/i915/intel_hdmi.c |  1 -
 drivers/gpu/drm/i915/intel_sdvo.c |  5 ++---
 drivers/gpu/drm/i915/intel_tv.c   |  2 +-
 7 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 32b5527..5408a3a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3045,7 +3045,20 @@ void intel_irq_init(struct drm_device *dev)
 void intel_hpd_init(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
+   struct drm_mode_config *mode_config = dev-mode_config;
+   struct drm_connector *connector;
+   int i;
 
+   for (i = 1; i  HPD_NUM_PINS; i++) {
+   dev_priv-hpd_stats[i].hpd_cnt = 0;
+   dev_priv-hpd_stats[i].hpd_mark = HPD_ENABLED;
+   }
+   list_for_each_entry(connector, mode_config-connector_list, head) {
+   struct intel_connector *intel_connector = 
to_intel_connector(connector);
+   connector-polled = intel_connector-polled;
+   if (!connector-polled  I915_HAS_HOTPLUG(dev)  
intel_connector-encoder-hpd_pin  HPD_NONE)
+   connector-polled = DRM_CONNECTOR_POLL_HPD;
+   }
if (dev_priv-display.hpd_irq_setup)
dev_priv-display.hpd_irq_setup(dev);
 }
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 1ae2d7f..c063b9f 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -793,10 +793,8 @@ void intel_crt_init(struct drm_device *dev)
 
drm_sysfs_connector_add(connector);
 
-   if (I915_HAS_HOTPLUG(dev))
-   connector-polled = DRM_CONNECTOR_POLL_HPD;
-   else
-   connector-polled = DRM_CONNECTOR_POLL_CONNECT;
+   if (!I915_HAS_HOTPLUG(dev))
+   intel_connector-polled = DRM_CONNECTOR_POLL_CONNECT;
 
/*
 * Configure the automatic hotplug detection stuff
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 482b5e5..1e9b19a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2786,7 +2786,6 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
drm_connector_init(dev, connector, intel_dp_connector_funcs, type);
drm_connector_helper_add(connector, intel_dp_connector_helper_funcs);
 
-   connector-polled = DRM_CONNECTOR_POLL_HPD;
connector-interlace_allowed = true;
connector-doublescan_allowed = 0;
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d7bd031..a05fde7 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -171,6 +171,10 @@ struct intel_connector {
 
/* Cached EDID for eDP and LVDS. May hold ERR_PTR for invalid EDID. */
struct edid *edid;
+
+   /* since POLL and HPD connectors may use the same HPD line keep the 
native
+  state of connector-polled in case hotplug storm detection changes 
it */
+   u8 polled;
 };
 
 struct intel_crtc_config {
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index ee4a8da..8912201 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -998,7 +998,6 @@ void intel_hdmi_init_connector(struct intel_digital_port 
*intel_dig_port,
   DRM_MODE_CONNECTOR_HDMIA);
drm_connector_helper_add(connector, intel_hdmi_connector_helper_funcs);
 
-   connector-polled = DRM_CONNECTOR_POLL_HPD;
connector-interlace_allowed = 1;
connector-doublescan_allowed = 0;
 
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
b/drivers/gpu/drm/i915/intel_sdvo.c
index 298dc85..64b8b40 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -2276,7 +2276,6 @@ intel_sdvo_dvi_init(struct intel_sdvo *intel_sdvo, int 
device)
connector = intel_connector-base;
if (intel_sdvo_get_hotplug_support(intel_sdvo) 

[Intel-gfx] [PATCH v3 3/7] drm/i915: Mask out the HPD irq bits before setting them individually.

2013-04-09 Thread Egbert Eich
From: Egbert Eich e...@suse.de

To disable previously enabled HPD IRQs we need to reset them and
set the enabled ones individually.

Signed-off-by: Egbert Eich e...@suse.de
---
 drivers/gpu/drm/i915/i915_irq.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 5408a3a..a3f1ac4 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2117,9 +2117,11 @@ static void ibx_hpd_irq_setup(struct drm_device *dev)
u32 hotplug;
 
if (HAS_PCH_IBX(dev)) {
+   mask = ~SDE_HOTPLUG_MASK;
list_for_each_entry(intel_encoder, mode_config-encoder_list, 
base.head)
mask |= hpd_ibx[intel_encoder-hpd_pin];
} else {
+   mask = ~SDE_HOTPLUG_MASK_CPT;
list_for_each_entry(intel_encoder, mode_config-encoder_list, 
base.head)
mask |= hpd_cpt[intel_encoder-hpd_pin];
}
-- 
1.8.1.4

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


[Intel-gfx] [PATCH v3 6/7] drm/i915: Add bit field to record which pins have received HPD events (v2)

2013-04-09 Thread Egbert Eich
From: Egbert Eich e...@suse.de

This way it is possible to limit 're'-detect() of displays to connectors
which have received an HPD event.

v2: Reordered drm_i915_private: Move hpd_event_bits to hpd state tracking.

Signed-off-by: Egbert Eich e...@suse.de
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_irq.c | 10 ++
 2 files changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a3ed2e3..907e290 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -938,6 +938,7 @@ typedef struct drm_i915_private {
HPD_MARK_DISABLED = 2
} hpd_mark;
} hpd_stats[HPD_NUM_PINS];
+   u32 hpd_event_bits;
 #define I915_REENABLE_HOTPLUG_DELAY (2*60*1000)
struct timer_list hotplug_reenable_timer;
 
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 1a00533..92041b9 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -348,6 +348,7 @@ static void i915_hotplug_work_func(struct work_struct *work)
struct drm_connector *connector;
unsigned long irqflags;
bool connector_disabled = false;
+   u32 hpd_event_bits;
 
/* HPD irq before everything is fully set up. */
if (!dev_priv-enable_hotplug_processing)
@@ -357,6 +358,9 @@ static void i915_hotplug_work_func(struct work_struct *work)
DRM_DEBUG_KMS(running encoder hotplug functions\n);
 
spin_lock_irqsave(dev_priv-irq_lock, irqflags);
+
+   hpd_event_bits = dev_priv-hpd_event_bits;
+   dev_priv-hpd_event_bits = 0;
list_for_each_entry(connector, mode_config-connector_list, head) {
intel_connector = to_intel_connector(connector);
intel_encoder = intel_connector-encoder;
@@ -370,6 +374,10 @@ static void i915_hotplug_work_func(struct work_struct 
*work)
| DRM_CONNECTOR_POLL_DISCONNECT;
connector_disabled = true;
}
+   if (hpd_event_bits  (1  intel_encoder-hpd_pin)) {
+   DRM_DEBUG_KMS(Connector %s (pin %i) received hotplug 
event.\n,
+ drm_get_connector_name(connector), 
intel_encoder-hpd_pin);
+   }
}
if (connector_disabled) {
drm_kms_helper_poll_enable(dev); /* if there were no outputs to 
poll, poll is disabled */
@@ -626,6 +634,7 @@ static inline bool hotplug_irq_storm_detect(struct 
drm_device *dev,
for (i = 1; i  HPD_NUM_PINS; i++) {
if ((hpd[i]  hotplug_trigger) 
dev_priv-hpd_stats[i].hpd_mark == HPD_ENABLED) {
+   dev_priv-hpd_event_bits |= (1  i);
if (!time_in_range(jiffies, 
dev_priv-hpd_stats[i].hpd_last_jiffies,
  
dev_priv-hpd_stats[i].hpd_last_jiffies
  + 
msecs_to_jiffies(HPD_STORM_DETECT_PERIOD))) {
@@ -633,6 +642,7 @@ static inline bool hotplug_irq_storm_detect(struct 
drm_device *dev,
dev_priv-hpd_stats[i].hpd_cnt = 0;
} else if (dev_priv-hpd_stats[i].hpd_cnt  5) {
dev_priv-hpd_stats[i].hpd_mark = 
HPD_MARK_DISABLED;
+   dev_priv-hpd_event_bits = ~(1  i);
DRM_DEBUG_KMS(HPD interrupt storm detected on  
PIN %d\n, i);
ret = true;
} else
-- 
1.8.1.4

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


[Intel-gfx] [PATCH v3 7/7] drm/i915: Only reprobe display on encoder which has received an HPD event

2013-04-09 Thread Egbert Eich
From: Egbert Eich e...@suse.de

Instead of calling into the DRM helper layer to poll all connectors for
changes in connected displays probe only those connectors which have
received a hotplug event.

Signed-off-by: Egbert Eich e...@suse.de
---
 drivers/gpu/drm/i915/i915_irq.c | 37 +++--
 1 file changed, 31 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 92041b9..7788536 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -334,6 +334,24 @@ static int i915_get_vblank_timestamp(struct drm_device 
*dev, int pipe,
 crtc);
 }
 
+/**
+ * drm_helper_hpd_irq_single_connector_event() - call this function with 
mode_config.mutex lock held
+ */
+
+static int intel_hpd_irq_single_connector_event(struct drm_device *dev, struct 
drm_connector *connector)
+{
+   enum drm_connector_status old_status;
+
+   old_status = connector-status;
+
+   connector-status = connector-funcs-detect(connector, false);
+   DRM_DEBUG_KMS([CONNECTOR:%d:%s] status updated from %d to %d\n,
+ connector-base.id,
+ drm_get_connector_name(connector),
+ old_status, connector-status);
+   return (old_status != connector-status);
+}
+
 /*
  * Handle hotplug events outside the interrupt handler proper.
  */
@@ -348,6 +366,7 @@ static void i915_hotplug_work_func(struct work_struct *work)
struct drm_connector *connector;
unsigned long irqflags;
bool connector_disabled = false;
+   bool changed = false;
u32 hpd_event_bits;
 
/* HPD irq before everything is fully set up. */
@@ -387,14 +406,20 @@ static void i915_hotplug_work_func(struct work_struct 
*work)
 
spin_unlock_irqrestore(dev_priv-irq_lock, irqflags);
 
-   list_for_each_entry(intel_encoder, mode_config-encoder_list, 
base.head)
-   if (intel_encoder-hot_plug)
-   intel_encoder-hot_plug(intel_encoder);
-
+   list_for_each_entry(connector, mode_config-connector_list, head) {
+   intel_connector = to_intel_connector(connector);
+   intel_encoder = intel_connector-encoder;
+   if (hpd_event_bits  (1  intel_encoder-hpd_pin)) {
+   if (intel_encoder-hot_plug)
+   intel_encoder-hot_plug(intel_encoder);
+   if (intel_hpd_irq_single_connector_event(dev, 
connector))
+   changed = true;
+   }
+   }
mutex_unlock(mode_config-mutex);
 
-   /* Just fire off a uevent and let userspace tell us what to do */
-   drm_helper_hpd_irq_event(dev);
+   if (changed)
+   drm_kms_helper_hotplug_event(dev);
 }
 
 static void ironlake_handle_rps_change(struct drm_device *dev)
-- 
1.8.1.4

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


[Intel-gfx] [PATCH v3 5/7] drm/i915: Add Reenable Timer to turn Hotplug Detection back on (v3)

2013-04-09 Thread Egbert Eich
From: Egbert Eich e...@suse.de

We disable hoptplug detection when we encounter a hotplug event
storm. Still hotplug detection is required on some outputs (like
Display Port). The interrupt storm may be only temporary (on certain
Dell Laptops for instance it happens at certain charging states of
the system). Thus we enable it after a certain grace period (2 minutes).
Should the interrupt storm persist it will be detected immediately
and it will be disabled again.

v2: Reordered drm_i915_private: moved hotplug_reenable_timer to hpd state 
tracker.
v3: Clarified loop start value,
Removed superfluous test for Ivybridge and Haswell,
Restructured loop to avoid deep nesting (all suggested by Ville Syrjälä)

Signed-off-by: Egbert Eich e...@suse.de
---
 drivers/gpu/drm/i915/i915_drv.h |  2 ++
 drivers/gpu/drm/i915/i915_irq.c | 49 -
 2 files changed, 50 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 83fc1a6..a3ed2e3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -938,6 +938,8 @@ typedef struct drm_i915_private {
HPD_MARK_DISABLED = 2
} hpd_mark;
} hpd_stats[HPD_NUM_PINS];
+#define I915_REENABLE_HOTPLUG_DELAY (2*60*1000)
+   struct timer_list hotplug_reenable_timer;
 
int num_pch_pll;
int num_plane;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d0e6f6d..1a00533 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -371,8 +371,11 @@ static void i915_hotplug_work_func(struct work_struct 
*work)
connector_disabled = true;
}
}
-   if (connector_disabled)
+   if (connector_disabled) {
drm_kms_helper_poll_enable(dev); /* if there were no outputs to 
poll, poll is disabled */
+   mod_timer(dev_priv-hotplug_reenable_timer,
+ jiffies + 
msecs_to_jiffies(I915_REENABLE_HOTPLUG_DELAY));
+   }
 
spin_unlock_irqrestore(dev_priv-irq_lock, irqflags);
 
@@ -2348,6 +2351,8 @@ static void valleyview_irq_uninstall(struct drm_device 
*dev)
if (!dev_priv)
return;
 
+   del_timer_sync(dev_priv-hotplug_reenable_timer);
+
for_each_pipe(pipe)
I915_WRITE(PIPESTAT(pipe), 0x);
 
@@ -2369,6 +2374,8 @@ static void ironlake_irq_uninstall(struct drm_device *dev)
if (!dev_priv)
return;
 
+   del_timer_sync(dev_priv-hotplug_reenable_timer);
+
I915_WRITE(HWSTAM, 0x);
 
I915_WRITE(DEIMR, 0x);
@@ -2745,6 +2752,8 @@ static void i915_irq_uninstall(struct drm_device * dev)
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
int pipe;
 
+   del_timer_sync(dev_priv-hotplug_reenable_timer);
+
if (I915_HAS_HOTPLUG(dev)) {
I915_WRITE(PORT_HOTPLUG_EN, 0);
I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
@@ -2989,6 +2998,8 @@ static void i965_irq_uninstall(struct drm_device * dev)
if (!dev_priv)
return;
 
+   del_timer_sync(dev_priv-hotplug_reenable_timer);
+
I915_WRITE(PORT_HOTPLUG_EN, 0);
I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
 
@@ -3004,6 +3015,40 @@ static void i965_irq_uninstall(struct drm_device * dev)
I915_WRITE(IIR, I915_READ(IIR));
 }
 
+static void i915_reenable_hotplug_timer_func(unsigned long data)
+{
+   drm_i915_private_t *dev_priv = (drm_i915_private_t *)data;
+   struct drm_device *dev = dev_priv-dev;
+   struct drm_mode_config *mode_config = dev-mode_config;
+   unsigned long irqflags;
+   int i;
+
+   spin_lock_irqsave(dev_priv-irq_lock, irqflags);
+   for (i = (HPD_NONE + 1); i  HPD_NUM_PINS; i++) {
+   struct drm_connector *connector;
+
+   if (dev_priv-hpd_stats[i].hpd_mark != HPD_MARK_DISABLED)
+   continue;
+
+   dev_priv-hpd_stats[i].hpd_mark = HPD_ENABLED;
+
+   list_for_each_entry(connector, mode_config-connector_list, 
head) {
+   struct intel_connector *intel_connector = 
to_intel_connector(connector);
+
+   if (intel_connector-encoder-hpd_pin == i) {
+   if (connector-polled != 
intel_connector-polled)
+   DRM_DEBUG_DRIVER(Reenabling HPD on 
connector %s\n,
+
drm_get_connector_name(connector));
+   connector-polled = intel_connector-polled;
+   if (!connector-polled)
+   connector-polled = 
DRM_CONNECTOR_POLL_HPD;
+   }
+   }
+   dev_priv-display.hpd_irq_setup(dev);
+ 

[Intel-gfx] [PATCH v3 4/7] drm/i915: Disable HPD interrupt on pin when irq storm is detected (v2)

2013-04-09 Thread Egbert Eich
From: Egbert Eich e...@suse.de

This patch disables hotplug interrupts if an 'interrupt storm'
has been detected.
Noise on the interrupt line renders the hotplug interrupt useless:
each hotplug event causes the devices to be rescanned which will
will only increase the system load.
Thus disable the hotplug interrupts and fall back to periodic
device polling.

v2: Fixed cleanup typo.

Signed-off-by: Egbert Eich e...@suse.de
---
 drivers/gpu/drm/i915/i915_irq.c | 71 +++--
 1 file changed, 54 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a3f1ac4..d0e6f6d 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -88,7 +88,8 @@ static const u32 hpd_status_i915[] = { /* i915 and valleyview 
are the same */
[HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
 };
 
-
+static void ibx_hpd_irq_setup(struct drm_device *dev);
+static void i915_hpd_irq_setup(struct drm_device *dev);
 
 /* For display hotplug interrupt */
 static void
@@ -342,7 +343,11 @@ static void i915_hotplug_work_func(struct work_struct 
*work)
hotplug_work);
struct drm_device *dev = dev_priv-dev;
struct drm_mode_config *mode_config = dev-mode_config;
-   struct intel_encoder *encoder;
+   struct intel_connector *intel_connector;
+   struct intel_encoder *intel_encoder;
+   struct drm_connector *connector;
+   unsigned long irqflags;
+   bool connector_disabled = false;
 
/* HPD irq before everything is fully set up. */
if (!dev_priv-enable_hotplug_processing)
@@ -351,9 +356,29 @@ static void i915_hotplug_work_func(struct work_struct 
*work)
mutex_lock(mode_config-mutex);
DRM_DEBUG_KMS(running encoder hotplug functions\n);
 
-   list_for_each_entry(encoder, mode_config-encoder_list, base.head)
-   if (encoder-hot_plug)
-   encoder-hot_plug(encoder);
+   spin_lock_irqsave(dev_priv-irq_lock, irqflags);
+   list_for_each_entry(connector, mode_config-connector_list, head) {
+   intel_connector = to_intel_connector(connector);
+   intel_encoder = intel_connector-encoder;
+   if (intel_encoder-hpd_pin  HPD_NONE 
+   dev_priv-hpd_stats[intel_encoder-hpd_pin].hpd_mark == 
HPD_MARK_DISABLED 
+   connector-polled == DRM_CONNECTOR_POLL_HPD) {
+   pr_warn(HPD interrupt storm detected on connector %s 
disabling\n,
+   drm_get_connector_name(connector));
+   dev_priv-hpd_stats[intel_encoder-hpd_pin].hpd_mark = 
HPD_DISABLED;
+   connector-polled = DRM_CONNECTOR_POLL_CONNECT
+   | DRM_CONNECTOR_POLL_DISCONNECT;
+   connector_disabled = true;
+   }
+   }
+   if (connector_disabled)
+   drm_kms_helper_poll_enable(dev); /* if there were no outputs to 
poll, poll is disabled */
+
+   spin_unlock_irqrestore(dev_priv-irq_lock, irqflags);
+
+   list_for_each_entry(intel_encoder, mode_config-encoder_list, 
base.head)
+   if (intel_encoder-hot_plug)
+   intel_encoder-hot_plug(intel_encoder);
 
mutex_unlock(mode_config-mutex);
 
@@ -584,13 +609,14 @@ static void gen6_queue_rps_work(struct drm_i915_private 
*dev_priv,
 
 #define HPD_STORM_DETECT_PERIOD 1000
 
-static inline void hotplug_irq_storm_detect(struct drm_device *dev,
+static inline bool hotplug_irq_storm_detect(struct drm_device *dev,
u32 hotplug_trigger,
const u32 *hpd)
 {
drm_i915_private_t *dev_priv = dev-dev_private;
unsigned long irqflags;
int i;
+   bool ret = false;
 
spin_lock_irqsave(dev_priv-irq_lock, irqflags);
 
@@ -605,12 +631,15 @@ static inline void hotplug_irq_storm_detect(struct 
drm_device *dev,
} else if (dev_priv-hpd_stats[i].hpd_cnt  5) {
dev_priv-hpd_stats[i].hpd_mark = 
HPD_MARK_DISABLED;
DRM_DEBUG_KMS(HPD interrupt storm detected on  
PIN %d\n, i);
+   ret = true;
} else
dev_priv-hpd_stats[i].hpd_cnt++;
}
}
 
spin_unlock_irqrestore(dev_priv-irq_lock, irqflags);
+
+   return ret;
 }
 
 static void gmbus_irq_handler(struct drm_device *dev)
@@ -686,7 +715,8 @@ static irqreturn_t valleyview_irq_handler(int irq, void 
*arg)
DRM_DEBUG_DRIVER(hotplug event received, stat 
0x%08x\n,
 hotplug_status);
if (hotplug_trigger) {
-   hotplug_irq_storm_detect(dev, hotplug_trigger, 

Re: [Intel-gfx] [PATCH] drm/i915: Always normalize return timeout for wait_timeout_ioctl

2013-04-09 Thread Ville Syrjälä
On Tue, Apr 09, 2013 at 10:13:23AM +0100, Chris Wilson wrote:
 As we recompute the remaining timeout after waiting, there is a
 potential for that timeout to be less than zero and so need sanitizing.
 The timeout is always returned to userspace and validated, so we should
 always perform the sanitation.
 
 Cc: Ville Syrjälä ville.syrj...@linux.intel.com
 Cc: Ben Widawsky b...@bwidawsk.net
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 ---
  drivers/gpu/drm/i915/i915_gem.c |3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
 index 63c05dd..fcf8492 100644
 --- a/drivers/gpu/drm/i915/i915_gem.c
 +++ b/drivers/gpu/drm/i915/i915_gem.c
 @@ -1045,6 +1045,7 @@ static int __wait_seqno(struct intel_ring_buffer *ring, 
 u32 seqno,
   if (timeout) {
   struct timespec sleep_time = timespec_sub(now, before);
   *timeout = timespec_sub(*timeout, sleep_time);
 + set_normalized_timespec(timeout, 0, 0);

This will just set timeout = {0,0}, no?

And timespec_sub() should already return a normalized timespec, so I
guess the warning would just trigger when sleep_time  timeout. So we
should maybe just check for that case, and only then set timeout={0,0}?

   }
  
   switch (end) {
 @@ -1053,8 +1054,6 @@ static int __wait_seqno(struct intel_ring_buffer *ring, 
 u32 seqno,
   case -ERESTARTSYS: /* Signal */
   return (int)end;
   case 0: /* Timeout */
 - if (timeout)
 - set_normalized_timespec(timeout, 0, 0);
   return -ETIME;
   default: /* Completed */
   WARN_ON(end  0); /* We're not aware of other errors */
 -- 
 1.7.10.4

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


[Intel-gfx] [PATCH v2] drm/i915: IVB/HSW have 32 fence register

2013-04-09 Thread ville . syrjala
From: Ville Syrjälä ville.syrj...@linux.intel.com

Increase the number of fence registers to 32 on IVB/HSW. VLV however
only has 16 fence registers according to the docs.

Increasing the number of fences was attempted before [1], but there was
some uncertainty about the maximum CPU fence number for FBC. Since then
BSpec has been updated to state that there are in fact 32 fence registers,
and the CPU fence number field in the SNB_DPFC_CTL_SA register is 5 bits,
and the CPU fence number field in the ILK_DPFC_CONTROL register must be
zero. So now it all makes sense.

[1] http://lists.freedesktop.org/archives/intel-gfx/2011-October/012865.html

v2: Include some background information based on the previous attempt

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_drv.h | 6 +++---
 drivers/gpu/drm/i915/i915_gem.c | 4 +++-
 drivers/gpu/drm/i915/i915_irq.c | 2 +-
 3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 69ddfd1..fa8ca2f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -195,9 +195,9 @@ struct drm_i915_master_private {
struct _drm_i915_sarea *sarea_priv;
 };
 #define I915_FENCE_REG_NONE -1
-#define I915_MAX_NUM_FENCES 16
-/* 16 fences + sign bit for FENCE_REG_NONE */
-#define I915_MAX_NUM_FENCE_BITS 5
+#define I915_MAX_NUM_FENCES 32
+/* 32 fences + sign bit for FENCE_REG_NONE */
+#define I915_MAX_NUM_FENCE_BITS 6
 
 struct drm_i915_fence_reg {
struct list_head lru_list;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 63c05dd..211ce8f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4184,7 +4184,9 @@ i915_gem_load(struct drm_device *dev)
if (!drm_core_check_feature(dev, DRIVER_MODESET))
dev_priv-fence_reg_start = 3;
 
-   if (INTEL_INFO(dev)-gen = 4 || IS_I945G(dev) || IS_I945GM(dev) || 
IS_G33(dev))
+   if (INTEL_INFO(dev)-gen = 7  !IS_VALLEYVIEW(dev))
+   dev_priv-num_fence_regs = 32;
+   else if (INTEL_INFO(dev)-gen = 4 || IS_I945G(dev) || IS_I945GM(dev) 
|| IS_G33(dev))
dev_priv-num_fence_regs = 16;
else
dev_priv-num_fence_regs = 8;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index fc35d52..985d1f5 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1217,7 +1217,7 @@ static void i915_gem_record_fences(struct drm_device *dev,
switch (INTEL_INFO(dev)-gen) {
case 7:
case 6:
-   for (i = 0; i  16; i++)
+   for (i = 0; i  dev_priv-num_fence_regs; i++)
error-fence[i] = I915_READ64(FENCE_REG_SANDYBRIDGE_0 + 
(i * 8));
break;
case 5:
-- 
1.8.1.5

___
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: Increase max fence pitch limit to 256KB on IVB+

2013-04-09 Thread Daniel Vetter
On Tue, Apr 09, 2013 at 11:45:05AM +0300, ville.syrj...@linux.intel.com wrote:
 From: Ville Syrjälä ville.syrj...@linux.intel.com
 
 BSpec contains several scattered notes which state that the maximum
 fence stride was increased to 256KB on IVB.
 
 Testing on real hardware agrees.
 
 Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
 ---
  drivers/gpu/drm/i915/i915_gem_tiling.c | 9 ++---
  drivers/gpu/drm/i915/i915_reg.h| 1 +
  2 files changed, 7 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c 
 b/drivers/gpu/drm/i915/i915_gem_tiling.c
 index c807eb9..139d17d 100644
 --- a/drivers/gpu/drm/i915/i915_gem_tiling.c
 +++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
 @@ -217,9 +217,12 @@ i915_tiling_ok(struct drm_device *dev, int stride, int 
 size, int tiling_mode)
   tile_width = 512;
  
   /* check maximum stride  object size */
 - if (INTEL_INFO(dev)-gen = 4) {
 - /* i965 stores the end address of the gtt mapping in the fence
 -  * reg, so dont bother to check the size */
 + /* i965+ stores the end address of the gtt mapping in the fence
 +  * reg, so dont bother to check the size */
 + if (INTEL_INFO(dev)-gen = 7) {

I've thought that his does not apply to vlv? Or has that now changed?
-Daniel

 + if (stride / 128  GEN7_FENCE_MAX_PITCH_VAL)
 + return false;
 + } else if (INTEL_INFO(dev)-gen = 4) {
   if (stride / 128  I965_FENCE_MAX_PITCH_VAL)
   return false;
   } else {
 diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
 index 0e4b7fb..ec4e054 100644
 --- a/drivers/gpu/drm/i915/i915_reg.h
 +++ b/drivers/gpu/drm/i915/i915_reg.h
 @@ -424,6 +424,7 @@
  
  #define FENCE_REG_SANDYBRIDGE_0  0x10
  #define   SANDYBRIDGE_FENCE_PITCH_SHIFT  32
 +#define   GEN7_FENCE_MAX_PITCH_VAL   0x0800
  
  /* control register for cpu gtt access */
  #define TILECTL  0x101000
 -- 
 1.8.1.5
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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: Increase max fence pitch limit to 256KB on IVB+

2013-04-09 Thread Ville Syrjälä
On Tue, Apr 09, 2013 at 01:54:01PM +0200, Daniel Vetter wrote:
 On Tue, Apr 09, 2013 at 11:45:05AM +0300, ville.syrj...@linux.intel.com wrote:
  From: Ville Syrjälä ville.syrj...@linux.intel.com
  
  BSpec contains several scattered notes which state that the maximum
  fence stride was increased to 256KB on IVB.
  
  Testing on real hardware agrees.
  
  Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
  ---
   drivers/gpu/drm/i915/i915_gem_tiling.c | 9 ++---
   drivers/gpu/drm/i915/i915_reg.h| 1 +
   2 files changed, 7 insertions(+), 3 deletions(-)
  
  diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c 
  b/drivers/gpu/drm/i915/i915_gem_tiling.c
  index c807eb9..139d17d 100644
  --- a/drivers/gpu/drm/i915/i915_gem_tiling.c
  +++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
  @@ -217,9 +217,12 @@ i915_tiling_ok(struct drm_device *dev, int stride, int 
  size, int tiling_mode)
  tile_width = 512;
   
  /* check maximum stride  object size */
  -   if (INTEL_INFO(dev)-gen = 4) {
  -   /* i965 stores the end address of the gtt mapping in the fence
  -* reg, so dont bother to check the size */
  +   /* i965+ stores the end address of the gtt mapping in the fence
  +* reg, so dont bother to check the size */
  +   if (INTEL_INFO(dev)-gen = 7) {
 
 I've thought that his does not apply to vlv? Or has that now changed?

The docs are telling me that VLV also has 256KB max stride.

 -Daniel
 
  +   if (stride / 128  GEN7_FENCE_MAX_PITCH_VAL)
  +   return false;
  +   } else if (INTEL_INFO(dev)-gen = 4) {
  if (stride / 128  I965_FENCE_MAX_PITCH_VAL)
  return false;
  } else {
  diff --git a/drivers/gpu/drm/i915/i915_reg.h 
  b/drivers/gpu/drm/i915/i915_reg.h
  index 0e4b7fb..ec4e054 100644
  --- a/drivers/gpu/drm/i915/i915_reg.h
  +++ b/drivers/gpu/drm/i915/i915_reg.h
  @@ -424,6 +424,7 @@
   
   #define FENCE_REG_SANDYBRIDGE_00x10
   #define   SANDYBRIDGE_FENCE_PITCH_SHIFT32
  +#define   GEN7_FENCE_MAX_PITCH_VAL 0x0800
   
   /* control register for cpu gtt access */
   #define TILECTL0x101000
  -- 
  1.8.1.5
  
  ___
  Intel-gfx mailing list
  Intel-gfx@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/intel-gfx
 
 -- 
 Daniel Vetter
 Software Engineer, Intel Corporation
 +41 (0) 79 365 57 48 - http://blog.ffwll.ch

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


[Intel-gfx] [PATCH 2/2] drm: prime: fix lookup of existing imports for self imported buffers

2013-04-09 Thread Imre Deak
Since atm we don't take a reference on the dma buf pointer when we add
it to the import lookup table the dma buf can vanish leaving the stale
pointer behind. This can in turn lead to returning stale GEM handles
when userspace imports a newly exported buffer.

Fix this by keeping a reference on the dma buffer whenever we have a
pointer to it in the lookup table.

Reference: https://bugs.freedesktop.org/show_bug.cgi?id=59229

Signed-off-by: Imre Deak imre.d...@intel.com
---
 drivers/gpu/drm/drm_prime.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index bba45f6..e4e1a69 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -501,6 +501,7 @@ int drm_prime_add_imported_buf_handle(struct 
drm_prime_file_private *prime_fpriv
if (!member)
return -ENOMEM;
 
+   get_dma_buf(dma_buf);
member-dma_buf = dma_buf;
member-handle = handle;
list_add(member-entry, prime_fpriv-head);
@@ -529,6 +530,7 @@ void drm_prime_remove_imported_buf_handle(struct 
drm_prime_file_private *prime_f
mutex_lock(prime_fpriv-lock);
list_for_each_entry_safe(member, safe, prime_fpriv-head, entry) {
if (member-dma_buf == dma_buf) {
+   dma_buf_put(dma_buf);
list_del(member-entry);
kfree(member);
}
-- 
1.7.10.4

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


[Intel-gfx] [PATCH 1/2] drm: prime: fix refcounting on the dmabuf import error path

2013-04-09 Thread Imre Deak
In commit be8a42ae60 we inroduced a refcount problem, where on the
drm_gem_prime_fd_to_handle() error path we'll call dma_buf_put() for
self imported dma buffers.

Fix this by taking a reference on the dma buffer in the .gem_import
hook instead of assuming the caller had taken one. Besides fixing the
bug this is also more logical.

Signed-off-by: Imre Deak imre.d...@intel.com
---
 drivers/gpu/drm/drm_prime.c|8 +++-
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |4 +++-
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |5 -
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |1 -
 drivers/gpu/drm/udl/udl_gem.c  |4 
 5 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 25d0218..bba45f6 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -268,7 +268,6 @@ struct drm_gem_object *drm_gem_prime_import(struct 
drm_device *dev,
 * refcount on gem itself instead of f_count of dmabuf.
 */
drm_gem_object_reference(obj);
-   dma_buf_put(dma_buf);
return obj;
}
}
@@ -277,6 +276,8 @@ struct drm_gem_object *drm_gem_prime_import(struct 
drm_device *dev,
if (IS_ERR(attach))
return ERR_PTR(PTR_ERR(attach));
 
+   get_dma_buf(dma_buf);
+
sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
if (IS_ERR_OR_NULL(sgt)) {
ret = PTR_ERR(sgt);
@@ -297,6 +298,8 @@ fail_unmap:
dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
 fail_detach:
dma_buf_detach(dma_buf, attach);
+   dma_buf_put(dma_buf);
+
return ERR_PTR(ret);
 }
 EXPORT_SYMBOL(drm_gem_prime_import);
@@ -339,6 +342,9 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
goto fail;
 
mutex_unlock(file_priv-prime.lock);
+
+   dma_buf_put(dma_buf);
+
return 0;
 
 fail:
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c 
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index ba0a3aa..ff7f2a8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -235,7 +235,6 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct 
drm_device *drm_dev,
 * refcount on gem itself instead of f_count of dmabuf.
 */
drm_gem_object_reference(obj);
-   dma_buf_put(dma_buf);
return obj;
}
}
@@ -244,6 +243,7 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct 
drm_device *drm_dev,
if (IS_ERR(attach))
return ERR_PTR(-EINVAL);
 
+   get_dma_buf(dma_buf);
 
sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
if (IS_ERR_OR_NULL(sgt)) {
@@ -298,6 +298,8 @@ err_unmap_attach:
dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
 err_buf_detach:
dma_buf_detach(dma_buf, attach);
+   dma_buf_put(dma_buf);
+
return ERR_PTR(ret);
 }
 
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index c6dfc14..30485e9 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -272,7 +272,6 @@ struct drm_gem_object *i915_gem_prime_import(struct 
drm_device *dev,
 * refcount on gem itself instead of f_count of dmabuf.
 */
drm_gem_object_reference(obj-base);
-   dma_buf_put(dma_buf);
return obj-base;
}
}
@@ -282,6 +281,8 @@ struct drm_gem_object *i915_gem_prime_import(struct 
drm_device *dev,
if (IS_ERR(attach))
return ERR_CAST(attach);
 
+   get_dma_buf(dma_buf);
+
obj = i915_gem_object_alloc(dev);
if (obj == NULL) {
ret = -ENOMEM;
@@ -301,5 +302,7 @@ struct drm_gem_object *i915_gem_prime_import(struct 
drm_device *dev,
 
 fail_detach:
dma_buf_detach(dma_buf, attach);
+   dma_buf_put(dma_buf);
+
return ERR_PTR(ret);
 }
diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c 
b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
index ac74d1b..1bdf7e1 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
@@ -212,7 +212,6 @@ struct drm_gem_object *omap_gem_prime_import(struct 
drm_device *dev,
 * refcount on gem itself instead of f_count of dmabuf.
 */
drm_gem_object_reference(obj);
-   dma_buf_put(buffer);
return obj;
}
}
diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
index 3816270..ef034fa 100644
--- 

[Intel-gfx] [PATCH i-g-t 2/3] tests: Use gem_available_fences()

2013-04-09 Thread ville . syrjala
From: Ville Syrjälä ville.syrj...@linux.intel.com

lib/drmtest.c provides gem_available_fences(). Use it where
appropriate.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 tests/gem_fence_thrash.c   | 8 ++--
 tests/gem_fenced_exec_thrash.c | 8 ++--
 tests/gem_stress.c | 8 ++--
 3 files changed, 6 insertions(+), 18 deletions(-)

diff --git a/tests/gem_fence_thrash.c b/tests/gem_fence_thrash.c
index 01fd0f6..e1cfc4e 100644
--- a/tests/gem_fence_thrash.c
+++ b/tests/gem_fence_thrash.c
@@ -169,19 +169,15 @@ static int run_test(int threads_per_fence, void *f, int 
tiling,
int surfaces_per_thread)
 {
struct test t;
-   drm_i915_getparam_t gp;
pthread_t *threads;
int n, num_fences, num_threads;
-   int ret;
 
t.fd = drm_open_any();
t.tiling = tiling;
t.num_surfaces = surfaces_per_thread;
 
-   gp.param = I915_PARAM_NUM_FENCES_AVAIL;
-   gp.value = num_fences;
-   ret = ioctl(t.fd, DRM_IOCTL_I915_GETPARAM, gp);
-   assert (ret == 0);
+   num_fences = gem_available_fences(t.fd);
+   assert (num_fences  0);
 
num_threads = threads_per_fence * num_fences;
 
diff --git a/tests/gem_fenced_exec_thrash.c b/tests/gem_fenced_exec_thrash.c
index b17eba2..ca88c53 100644
--- a/tests/gem_fenced_exec_thrash.c
+++ b/tests/gem_fenced_exec_thrash.c
@@ -88,13 +88,9 @@ batch_create (int fd)
 
 static int get_num_fences(int fd)
 {
-   drm_i915_getparam_t gp;
-   int ret, val;
+   int val;
 
-   gp.param = I915_PARAM_NUM_FENCES_AVAIL;
-   gp.value = val;
-   ret = drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, gp);
-   assert (ret == 0);
+   val = gem_available_fences(fd);
 
printf (total %d fences\n, val);
assert(val  4);
diff --git a/tests/gem_stress.c b/tests/gem_stress.c
index 54597af..9b31a69 100644
--- a/tests/gem_stress.c
+++ b/tests/gem_stress.c
@@ -605,13 +605,9 @@ static void copy_tiles(unsigned *permutation)
 
 static int get_num_fences(void)
 {
-   drm_i915_getparam_t gp;
-   int ret, val;
+   int val;
 
-   gp.param = I915_PARAM_NUM_FENCES_AVAIL;
-   gp.value = val;
-   ret = drmIoctl(drm_fd, DRM_IOCTL_I915_GETPARAM, gp);
-   assert (ret == 0);
+   val = gem_available_fences(drm_fd);
 
printf (total %d fences\n, val);
assert(val  4);
-- 
1.8.1.5

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


[Intel-gfx] [PATCH i-g-t 3/3] tests/gem_tiling_max_stride: Add a test for max fence stride

2013-04-09 Thread ville . syrjala
From: Ville Syrjälä ville.syrj...@linux.intel.com

gem_tiling_max_stride writes a data pattern to an X-tiled buffer using
the maximum supported stride, reads the data back as linear, and
verifies that the data didn't get scrambled on the way.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 tests/Makefile.am |   1 +
 tests/gem_tiling_max_stride.c | 118 ++
 2 files changed, 119 insertions(+)
 create mode 100644 tests/gem_tiling_max_stride.c

diff --git a/tests/Makefile.am b/tests/Makefile.am
index f8758cd..e147e4e 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -99,6 +99,7 @@ TESTS_progs = \
gem_ctx_bad_exec \
gem_ctx_basic \
gem_reg_read \
+   gem_tiling_max_stride \
$(NOUVEAU_TESTS) \
prime_self_import \
prime_udl \
diff --git a/tests/gem_tiling_max_stride.c b/tests/gem_tiling_max_stride.c
new file mode 100644
index 000..3ba8c10
--- /dev/null
+++ b/tests/gem_tiling_max_stride.c
@@ -0,0 +1,118 @@
+/*
+ * Copyright © 2013 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.
+ *
+ * Authors:
+ *Ville Syrjälä ville.syrj...@linux.intel.com
+ *
+ */
+
+#include unistd.h
+#include stdlib.h
+#include stdio.h
+#include string.h
+#include assert.h
+#include fcntl.h
+#include inttypes.h
+#include errno.h
+#include sys/stat.h
+#include sys/ioctl.h
+#include sys/mman.h
+#include drm.h
+#include i915_drm.h
+#include drmtest.h
+#include intel_gpu_tools.h
+
+/**
+ * Testcase: Check that max fence stride works
+ */
+
+int main(int argc, char *argv[])
+{
+   int fd;
+   uint32_t *ptr;
+   uint32_t *data;
+   uint32_t handle;
+   uint32_t stride;
+   uint32_t size;
+   uint32_t devid;
+   int i = 0, x, y;
+   int tile_width = 512;
+   int tile_height = 8;
+
+   fd = drm_open_any();
+
+   devid = intel_get_drm_devid(fd);
+
+   if (intel_gen(devid) = 7)
+   stride = 256 * 1024;
+   else if (intel_gen(devid) = 4)
+   stride = 128 * 1024;
+   else {
+   tile_width = 128;
+   tile_height = 16;
+   stride = 8 * 1024;
+   }
+
+   size = stride * tile_height;
+
+   data = malloc(size);
+   assert(data);
+
+   /* Fill each line with the line number */
+   for (y = 0; y  tile_height; y++) {
+   for (x = 0; x  stride / 4; x++)
+   data[i++] = y;
+   }
+
+   handle = gem_create(fd, size);
+
+   ptr = gem_mmap(fd, handle, size, PROT_READ | PROT_WRITE);
+   assert(ptr);
+
+   gem_set_tiling(fd, handle, I915_TILING_X, stride);
+
+   gem_set_domain(fd, handle, I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
+
+   memcpy(ptr, data, size);
+
+   memset(data, 0, size);
+
+   gem_set_tiling(fd, handle, I915_TILING_NONE, 0);
+
+   memcpy(data, ptr, size);
+
+   /* Check that each tile contains the expected pattern */
+   for (i = 0; i  size / 4; ) {
+   for (y = 0; y  tile_height; y++) {
+   for (x = 0; x  tile_width / 4; x++) {
+   assert(y == data[i]);
+   i++;
+   }
+   }
+   }
+
+   munmap(ptr, size);
+
+   close(fd);
+
+   return 0;
+}
-- 
1.8.1.5

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


Re: [Intel-gfx] [PATCH i-g-t 1/3] tests/gem_fenced_exec_thrash: Increase MAX_FENCES to 32

2013-04-09 Thread Chris Wilson
On Tue, Apr 09, 2013 at 03:25:37PM +0300, ville.syrj...@linux.intel.com wrote:
 From: Ville Syrjälä ville.syrj...@linux.intel.com
 
 IVB+ supports 32 fence registers, bump the maximum in the test.

Then again the test is only relevant for gen2/3 (and 1), and I don't
forsee the use of fences for GPU surface tiling being resurrected. On
the other hand, the test makes sure that future gpus ignore the old
restrictions.

One feature request for the test: feed in  max_fences expect
ENOSPC/EDEADLCK on gen2/3.
-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 i-g-t 3/3] tests/gem_tiling_max_stride: Add a test for max fence stride

2013-04-09 Thread Chris Wilson
On Tue, Apr 09, 2013 at 03:25:39PM +0300, ville.syrj...@linux.intel.com wrote:
 From: Ville Syrjälä ville.syrj...@linux.intel.com
 
 gem_tiling_max_stride writes a data pattern to an X-tiled buffer using
 the maximum supported stride, reads the data back as linear, and
 verifies that the data didn't get scrambled on the way.

And please also check that stride  max is rejected.
-Chris

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


[Intel-gfx] [PATCH i-g-t v2] tests/gem_tiling_max_stride: Add a test for max fence stride

2013-04-09 Thread ville . syrjala
From: Ville Syrjälä ville.syrj...@linux.intel.com

gem_tiling_max_stride writes a data pattern to an X-tiled buffer using
the maximum supported stride, reads the data back as linear, and
verifies that the data didn't get scrambled on the way.

The test also checks that some invalid stride values are rejected
properly.

v2: Check invalid strides

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 tests/Makefile.am |   1 +
 tests/gem_tiling_max_stride.c | 141 ++
 2 files changed, 142 insertions(+)
 create mode 100644 tests/gem_tiling_max_stride.c

diff --git a/tests/Makefile.am b/tests/Makefile.am
index f8758cd..e147e4e 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -99,6 +99,7 @@ TESTS_progs = \
gem_ctx_bad_exec \
gem_ctx_basic \
gem_reg_read \
+   gem_tiling_max_stride \
$(NOUVEAU_TESTS) \
prime_self_import \
prime_udl \
diff --git a/tests/gem_tiling_max_stride.c b/tests/gem_tiling_max_stride.c
new file mode 100644
index 000..42b68e5
--- /dev/null
+++ b/tests/gem_tiling_max_stride.c
@@ -0,0 +1,141 @@
+/*
+ * Copyright © 2013 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.
+ *
+ * Authors:
+ *Ville Syrjälä ville.syrj...@linux.intel.com
+ *
+ */
+
+#include unistd.h
+#include stdlib.h
+#include stdio.h
+#include string.h
+#include assert.h
+#include fcntl.h
+#include inttypes.h
+#include errno.h
+#include sys/stat.h
+#include sys/ioctl.h
+#include sys/mman.h
+#include drm.h
+#include i915_drm.h
+#include drmtest.h
+#include intel_gpu_tools.h
+
+static void test_invalid_tiling(int fd, uint32_t handle, int tiling, int 
stride)
+{
+   struct drm_i915_gem_set_tiling st;
+   int ret;
+
+   memset(st, 0, sizeof(st));
+   do {
+   st.handle = handle;
+   st.tiling_mode = tiling;
+   st.stride = tiling ? stride : 0;
+
+   ret = ioctl(fd, DRM_IOCTL_I915_GEM_SET_TILING, st);
+   } while (ret == -1  (errno == EINTR || errno == EAGAIN));
+   assert(ret == -1  errno == EINVAL);
+}
+
+/**
+ * Testcase: Check that max fence stride works
+ */
+
+int main(int argc, char *argv[])
+{
+   int fd;
+   uint32_t *ptr;
+   uint32_t *data;
+   uint32_t handle;
+   uint32_t stride;
+   uint32_t size;
+   uint32_t devid;
+   int i = 0, x, y;
+   int tile_width = 512;
+   int tile_height = 8;
+
+   fd = drm_open_any();
+
+   devid = intel_get_drm_devid(fd);
+
+   if (intel_gen(devid) = 7)
+   stride = 256 * 1024;
+   else if (intel_gen(devid) = 4)
+   stride = 128 * 1024;
+   else {
+   tile_width = 128;
+   tile_height = 16;
+   stride = 8 * 1024;
+   }
+
+   size = stride * tile_height;
+
+   data = malloc(size);
+   assert(data);
+
+   /* Fill each line with the line number */
+   for (y = 0; y  tile_height; y++) {
+   for (x = 0; x  stride / 4; x++)
+   data[i++] = y;
+   }
+
+   handle = gem_create(fd, size);
+
+   ptr = gem_mmap(fd, handle, size, PROT_READ | PROT_WRITE);
+   assert(ptr);
+
+   test_invalid_tiling(fd, handle, I915_TILING_X, stride - 1);
+   test_invalid_tiling(fd, handle, I915_TILING_X, stride + 1);
+   test_invalid_tiling(fd, handle, I915_TILING_X, stride + 127);
+   test_invalid_tiling(fd, handle, I915_TILING_X, stride + 128);
+   test_invalid_tiling(fd, handle, I915_TILING_X, stride + tile_width);
+   test_invalid_tiling(fd, handle, I915_TILING_X, stride * 2);
+
+   gem_set_tiling(fd, handle, I915_TILING_X, stride);
+
+   gem_set_domain(fd, handle, I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
+
+   memcpy(ptr, data, size);
+
+   memset(data, 0, size);
+
+   gem_set_tiling(fd, handle, I915_TILING_NONE, 

Re: [Intel-gfx] [PATCH] drm/i915: Better overclock support

2013-04-09 Thread Mika Kuoppala
Ben Widawsky b...@bwidawsk.net writes:

 Most importantly this will allow users to set overclock frequencies in
 sysfs. Previously the max was limited by the RP0 max as opposed to the
 overclock max. This is useful if one wants to either limit the max
 overclock frequency, or set the minimum frequency to be in the overclock
 range. It also fixes an issue where if one sets the max frequency to be
 below the overclock max, they wouldn't be able to set back the proper
 overclock max.

 In addition I've added a couple of other bits:
 Show the overclock freq. as max in sysfs
 Print the overclock max in debugfs.
 Print a warning if the user sets the min frequency to be in the
 overclock range.

 In this patch I've decided to store the hw_max when we read it from the
 pcode at init. The reason I do this is the pcode reads can fail, and are
 slow.

 Reported-by: freezer?
 Signed-off-by: Ben Widawsky b...@bwidawsk.net
 ---
  drivers/gpu/drm/i915/i915_debugfs.c |  3 +++
  drivers/gpu/drm/i915/i915_drv.h |  1 +
  drivers/gpu/drm/i915/i915_sysfs.c   | 12 
  drivers/gpu/drm/i915/intel_pm.c |  3 ++-
  4 files changed, 14 insertions(+), 5 deletions(-)

 diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
 b/drivers/gpu/drm/i915/i915_debugfs.c
 index 7df8351..f081bb3 100644
 --- a/drivers/gpu/drm/i915/i915_debugfs.c
 +++ b/drivers/gpu/drm/i915/i915_debugfs.c
 @@ -1006,6 +1006,9 @@ static int i915_cur_delayinfo(struct seq_file *m, void 
 *unused)
   max_freq = rp_state_cap  0xff;
   seq_printf(m, Max non-overclocked (RP0) frequency: %dMHz\n,
  max_freq * GT_FREQUENCY_MULTIPLIER);
 +
 + seq_printf(m, Max overclocked frequency: %dMHz\n,
 +dev_priv-rps.hw_max * GT_FREQUENCY_MULTIPLIER);
   } else {
   seq_printf(m, no P-state info available\n);
   }
 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index 1657d873..9b53b39c 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -648,6 +648,7 @@ struct intel_gen6_power_mgmt {
   u8 cur_delay;
   u8 min_delay;
   u8 max_delay;
 + u8 hw_max;
  
   struct delayed_work delayed_resume_work;
  
 diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
 b/drivers/gpu/drm/i915/i915_sysfs.c
 index a3a3e22..5faf1a7 100644
 --- a/drivers/gpu/drm/i915/i915_sysfs.c
 +++ b/drivers/gpu/drm/i915/i915_sysfs.c
 @@ -226,7 +226,7 @@ static ssize_t gt_max_freq_mhz_show(struct device *kdev, 
 struct device_attribute
   int ret;
  
   mutex_lock(dev_priv-rps.hw_lock);
 - ret = dev_priv-rps.max_delay * GT_FREQUENCY_MULTIPLIER;
 + ret = dev_priv-rps.hw_max * GT_FREQUENCY_MULTIPLIER;
   mutex_unlock(dev_priv-rps.hw_lock);
  
   return snprintf(buf, PAGE_SIZE, %d\n, ret);
 @@ -251,7 +251,7 @@ static ssize_t gt_max_freq_mhz_store(struct device *kdev,
   mutex_lock(dev_priv-rps.hw_lock);
  
   rp_state_cap = I915_READ(GEN6_RP_STATE_CAP);
 - hw_max = (rp_state_cap  0xff);
 + hw_max = dev_priv-rps.hw_max;
   hw_min = ((rp_state_cap  0xff)  16);
  
   if (val  hw_min || val  hw_max || val  dev_priv-rps.min_delay) {
 @@ -290,7 +290,7 @@ static ssize_t gt_min_freq_mhz_store(struct device *kdev,
   struct drm_minor *minor = container_of(kdev, struct drm_minor, kdev);
   struct drm_device *dev = minor-dev;
   struct drm_i915_private *dev_priv = dev-dev_private;
 - u32 val, rp_state_cap, hw_max, hw_min;
 + u32 val, rp_state_cap, hw_max, hw_min, non_oc_max;
   ssize_t ret;
  
   ret = kstrtou32(buf, 0, val);
 @@ -302,7 +302,8 @@ static ssize_t gt_min_freq_mhz_store(struct device *kdev,
   mutex_lock(dev_priv-rps.hw_lock);
  
   rp_state_cap = I915_READ(GEN6_RP_STATE_CAP);
 - hw_max = (rp_state_cap  0xff);
 + hw_max = dev_priv-rps.hw_max;
 + non_oc_max = (rp_state_cap  0xff);
   hw_min = ((rp_state_cap  0xff)  16);
  
   if (val  hw_min || val  hw_max || val  dev_priv-rps.max_delay) {
 @@ -310,6 +311,9 @@ static ssize_t gt_min_freq_mhz_store(struct device *kdev,
   return -EINVAL;
   }
  
 + if (val  non_oc_max)
 + DRM_DEBUG(User selected overclocked frequency for min\n);
 +
   if (dev_priv-rps.cur_delay  val)
   gen6_set_rps(dev_priv-dev, val);
  
 diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
 index ce3db2c..2edb743 100644
 --- a/drivers/gpu/drm/i915/intel_pm.c
 +++ b/drivers/gpu/drm/i915/intel_pm.c
 @@ -2555,7 +2555,7 @@ static void gen6_enable_rps(struct drm_device *dev)
   gt_perf_status = I915_READ(GEN6_GT_PERF_STATUS);
  
   /* In units of 100MHz */

Not a problem with this patch but the above comment should be
fixed as the freq is in units of 50Mhz right?

 - dev_priv-rps.max_delay = rp_state_cap  0xff;
 + dev_priv-rps.hw_max = dev_priv-rps.max_delay = rp_state_cap  0xff;
   dev_priv-rps.min_delay = 

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Don't default to overclock max

2013-04-09 Thread Mika Kuoppala
Ben Widawsky b...@bwidawsk.net writes:

 Requested-by: Daniel Vetter daniel.vet...@ffwll.ch
 Signed-off-by: Ben Widawsky b...@bwidawsk.net
 ---
  drivers/gpu/drm/i915/intel_pm.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
 index 2edb743..c81921b 100644
 --- a/drivers/gpu/drm/i915/intel_pm.c
 +++ b/drivers/gpu/drm/i915/intel_pm.c
 @@ -2632,11 +2632,10 @@ static void gen6_enable_rps(struct drm_device *dev)
   pcu_mbox = 0;
   ret = sandybridge_pcode_read(dev_priv, GEN6_READ_OC_PARAMS, 
 pcu_mbox);
   if (!ret  (pcu_mbox  (131))) { /* OC supported */
 - DRM_DEBUG_DRIVER(overclocking supported, adjusting 
 frequency max from %dMHz to %dMHz\n,
 + DRM_DEBUG_DRIVER(Overclocking supported. Max: %dMHz, 
 Overclock max: %dMHz\n,
(dev_priv-rps.max_delay  0xff) * 50,
(pcu_mbox  0xff) * 50);
Minor nitpick:  
Use GT_FREQUENCY_MULTIPLIER instead of 50

   dev_priv-rps.hw_max = pcu_mbox  0xff;
 - dev_priv-rps.max_delay = pcu_mbox  0xff;
   }
   } else {
   DRM_DEBUG_DRIVER(Failed to set the min frequency\n);
 -- 
 1.8.2

Reviewed-by: Mika Kuoppala mika.kuopp...@intel.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915: ensure single initialization and cleanup of backlight device

2013-04-09 Thread Jani Nikula
Backlight cleanup in the eDP connector destroy callback caused the
backlight device to be removed on some systems that first initialized LVDS
and then attempted to initialize eDP. Prevent multiple backlight
initializations, and ensure backlight cleanup is only done once by moving
it to modeset cleanup.

A small wrinkle is the introduced asymmetry in backlight
setup/cleanup. This could be solved by adding refcounting, but it seems
overkill considering that there should only ever be one backlight device.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55701
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/i915/intel_display.c |3 +++
 drivers/gpu/drm/i915/intel_dp.c  |5 +
 drivers/gpu/drm/i915/intel_lvds.c|1 -
 drivers/gpu/drm/i915/intel_panel.c   |7 ++-
 4 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 04d91cc..2ea5102 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9408,6 +9408,9 @@ void intel_modeset_cleanup(struct drm_device *dev)
/* flush any delayed tasks or pending work */
flush_scheduled_work();
 
+   /* destroy backlight, if any, before the connectors */
+   intel_panel_destroy_backlight(dev);
+
drm_mode_config_cleanup(dev);
 
intel_cleanup_overlay(dev);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 482b5e5..452bae6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2470,17 +2470,14 @@ done:
 static void
 intel_dp_destroy(struct drm_connector *connector)
 {
-   struct drm_device *dev = connector-dev;
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct intel_connector *intel_connector = to_intel_connector(connector);
 
if (!IS_ERR_OR_NULL(intel_connector-edid))
kfree(intel_connector-edid);
 
-   if (is_edp(intel_dp)) {
-   intel_panel_destroy_backlight(dev);
+   if (is_edp(intel_dp))
intel_panel_fini(intel_connector-panel);
-   }
 
drm_sysfs_connector_remove(connector);
drm_connector_cleanup(connector);
diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index ca2d903..f36f1ba 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -631,7 +631,6 @@ static void intel_lvds_destroy(struct drm_connector 
*connector)
if (!IS_ERR_OR_NULL(lvds_connector-base.edid))
kfree(lvds_connector-base.edid);
 
-   intel_panel_destroy_backlight(connector-dev);
intel_panel_fini(lvds_connector-base.panel);
 
drm_sysfs_connector_remove(connector);
diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 7874cec..eb5e6e9 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -428,6 +428,9 @@ int intel_panel_setup_backlight(struct drm_connector 
*connector)
 
intel_panel_init_backlight(dev);
 
+   if (WARN_ON(dev_priv-backlight.device))
+   return -ENODEV;
+
memset(props, 0, sizeof(props));
props.type = BACKLIGHT_RAW;
props.brightness = dev_priv-backlight.level;
@@ -453,8 +456,10 @@ int intel_panel_setup_backlight(struct drm_connector 
*connector)
 void intel_panel_destroy_backlight(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
-   if (dev_priv-backlight.device)
+   if (dev_priv-backlight.device) {
backlight_device_unregister(dev_priv-backlight.device);
+   dev_priv-backlight.device = NULL;
+   }
 }
 #else
 int intel_panel_setup_backlight(struct drm_connector *connector)
-- 
1.7.9.5

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


Re: [Intel-gfx] [PATCH i-g-t v2] tests/gem_tiling_max_stride: Add a test for max fence stride

2013-04-09 Thread Chris Wilson
On Tue, Apr 09, 2013 at 04:41:42PM +0300, ville.syrj...@linux.intel.com wrote:
 From: Ville Syrjälä ville.syrj...@linux.intel.com
 
 gem_tiling_max_stride writes a data pattern to an X-tiled buffer using
 the maximum supported stride, reads the data back as linear, and
 verifies that the data didn't get scrambled on the way.
 
 The test also checks that some invalid stride values are rejected
 properly.
 
 v2: Check invalid strides

tile_width is 512 on gen3, and 128 on gen2 for X-tiling and the
tile_height is 8 and 16 respectively.

For test_tiling(), just test both tiling modes, and include a
tile_width/2 and (max-tile_width+1). Otherwise those negative tests look
good.
-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] attempting to build with Ubuntu 8.04

2013-04-09 Thread don munro
Hi,
For various reasons, I'm trying to build an Intel driver to run on a QM67
system but with Ubuntu 8.04.4

Kernel 2.6.24-32-generic
Intel 2010Q4

Basically, I've got other hardware depending on Ubuntu 8.04 as the
manufacturer stopped supporting Linux at that point.

The question is am I wasting my time even trying this?
Thanks in advance.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH i-g-t v4] tests/gem_tiling_max_stride: Add a test for max fence stride

2013-04-09 Thread ville . syrjala
From: Ville Syrjälä ville.syrj...@linux.intel.com

gem_tiling_max_stride writes a data pattern to an X-tiled buffer using
the maximum supported stride, reads the data back as linear, and
verifies that the data didn't get scrambled on the way.

The test also checks that some invalid stride values are rejected
properly.

v2: Check invalid strides
v3: Check invalid stride with Y-tiling
Include a few more invalid stride values
Fix gen3 X-tile size
v4: A few more invalid strides :)
Drop the useless memset()

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 tests/Makefile.am |   1 +
 tests/gem_tiling_max_stride.c | 153 ++
 2 files changed, 154 insertions(+)
 create mode 100644 tests/gem_tiling_max_stride.c

diff --git a/tests/Makefile.am b/tests/Makefile.am
index f8758cd..e147e4e 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -99,6 +99,7 @@ TESTS_progs = \
gem_ctx_bad_exec \
gem_ctx_basic \
gem_reg_read \
+   gem_tiling_max_stride \
$(NOUVEAU_TESTS) \
prime_self_import \
prime_udl \
diff --git a/tests/gem_tiling_max_stride.c b/tests/gem_tiling_max_stride.c
new file mode 100644
index 000..21daab0
--- /dev/null
+++ b/tests/gem_tiling_max_stride.c
@@ -0,0 +1,153 @@
+/*
+ * Copyright © 2013 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.
+ *
+ * Authors:
+ *Ville Syrjälä ville.syrj...@linux.intel.com
+ *
+ */
+
+#include unistd.h
+#include stdlib.h
+#include stdio.h
+#include string.h
+#include assert.h
+#include fcntl.h
+#include inttypes.h
+#include errno.h
+#include limits.h
+#include sys/stat.h
+#include sys/ioctl.h
+#include sys/mman.h
+#include drm.h
+#include i915_drm.h
+#include drmtest.h
+#include intel_gpu_tools.h
+
+static void do_test_invalid_tiling(int fd, uint32_t handle, int tiling, int 
stride)
+{
+   struct drm_i915_gem_set_tiling st;
+   int ret;
+
+   memset(st, 0, sizeof(st));
+   do {
+   st.handle = handle;
+   st.tiling_mode = tiling;
+   st.stride = tiling ? stride : 0;
+
+   ret = ioctl(fd, DRM_IOCTL_I915_GEM_SET_TILING, st);
+   } while (ret == -1  (errno == EINTR || errno == EAGAIN));
+   assert(ret == -1  errno == EINVAL);
+}
+
+static void test_invalid_tiling(int fd, uint32_t handle, int stride)
+{
+   do_test_invalid_tiling(fd, handle, I915_TILING_X, stride);
+   do_test_invalid_tiling(fd, handle, I915_TILING_Y, stride);
+}
+
+/**
+ * Testcase: Check that max fence stride works
+ */
+
+int main(int argc, char *argv[])
+{
+   int fd;
+   uint32_t *ptr;
+   uint32_t *data;
+   uint32_t handle;
+   uint32_t stride;
+   uint32_t size;
+   uint32_t devid;
+   int i = 0, x, y;
+   int tile_width = 512;
+   int tile_height = 8;
+
+   fd = drm_open_any();
+
+   devid = intel_get_drm_devid(fd);
+
+   if (intel_gen(devid) = 7)
+   stride = 256 * 1024;
+   else if (intel_gen(devid) = 4)
+   stride = 128 * 1024;
+   else {
+   if (IS_GEN2(devid)) {
+   tile_width = 128;
+   tile_height = 16;
+   }
+   stride = 8 * 1024;
+   }
+
+   size = stride * tile_height;
+
+   data = malloc(size);
+   assert(data);
+
+   /* Fill each line with the line number */
+   for (y = 0; y  tile_height; y++) {
+   for (x = 0; x  stride / 4; x++)
+   data[i++] = y;
+   }
+
+   handle = gem_create(fd, size);
+
+   ptr = gem_mmap(fd, handle, size, PROT_READ | PROT_WRITE);
+   assert(ptr);
+
+   test_invalid_tiling(fd, handle, 0);
+   test_invalid_tiling(fd, handle, 64);
+   test_invalid_tiling(fd, handle, stride - 1);
+   test_invalid_tiling(fd, handle, stride + 1);
+   

[Intel-gfx] [PATCH] drm/i915: Reject fence stride=0 on gen4+

2013-04-09 Thread ville . syrjala
From: Ville Syrjälä ville.syrj...@linux.intel.com

Our checks for an invalid fence stride forgot to guard against
zero stride on gen4+. Fix it.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_gem_tiling.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c 
b/drivers/gpu/drm/i915/i915_gem_tiling.c
index 139d17d..16ff6e7 100644
--- a/drivers/gpu/drm/i915/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
@@ -240,6 +240,8 @@ i915_tiling_ok(struct drm_device *dev, int stride, int 
size, int tiling_mode)
 
/* 965+ just needs multiples of tile width */
if (INTEL_INFO(dev)-gen = 4) {
+   if (stride  tile_width)
+   return false;
if (stride  (tile_width - 1))
return false;
return true;
-- 
1.8.1.5

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


Re: [Intel-gfx] [PATCH v2] drm/i915: use lower aux clock divider on non-ULT HSW

2013-04-09 Thread Paulo Zanoni
Hi

2013/4/9 Jani Nikula jani.nik...@intel.com:
 Workaround to avoid intermittent aux channel failures, per spec change.

 v2: Don't mess with cpu dp aux divider (Paulo Zanoni)

 Signed-off-by: Jani Nikula jani.nik...@intel.com

 ---

 Untested.
 ---
  drivers/gpu/drm/i915/intel_dp.c |8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
 index 482b5e5..f8474d1 100644
 --- a/drivers/gpu/drm/i915/intel_dp.c
 +++ b/drivers/gpu/drm/i915/intel_dp.c
 @@ -353,10 +353,14 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
 aux_clock_divider = 200; /* SNB  IVB eDP input clock 
 at 400Mhz */
 else
 aux_clock_divider = 225; /* eDP input clock at 450Mhz 
 */
 -   } else if (HAS_PCH_SPLIT(dev))
 +   } else  if (dev_priv-pch_id == INTEL_PCH_LPT_DEVICE_ID_TYPE) {

There's a space and a tab between else and if, but I guess Daniel
will fix this :)

Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com

 +   /* Workaround for non-ULT HSW */
 +   aux_clock_divider = 74;
 +   } else if (HAS_PCH_SPLIT(dev)) {
 aux_clock_divider = DIV_ROUND_UP(intel_pch_rawclk(dev), 2);
 -   else
 +   } else {
 aux_clock_divider = intel_hrawclk(dev) / 2;
 +   }

 if (IS_GEN6(dev))
 precharge = 3;
 --
 1.7.10.4




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


Re: [Intel-gfx] [PATCH v2] drm/i915: use lower aux clock divider on non-ULT HSW

2013-04-09 Thread Daniel Vetter
On Tue, Apr 09, 2013 at 11:49:45AM -0300, Paulo Zanoni wrote:
 Hi
 
 2013/4/9 Jani Nikula jani.nik...@intel.com:
  Workaround to avoid intermittent aux channel failures, per spec change.
 
  v2: Don't mess with cpu dp aux divider (Paulo Zanoni)
 
  Signed-off-by: Jani Nikula jani.nik...@intel.com
 
  ---
 
  Untested.
  ---
   drivers/gpu/drm/i915/intel_dp.c |8 ++--
   1 file changed, 6 insertions(+), 2 deletions(-)
 
  diff --git a/drivers/gpu/drm/i915/intel_dp.c 
  b/drivers/gpu/drm/i915/intel_dp.c
  index 482b5e5..f8474d1 100644
  --- a/drivers/gpu/drm/i915/intel_dp.c
  +++ b/drivers/gpu/drm/i915/intel_dp.c
  @@ -353,10 +353,14 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
  aux_clock_divider = 200; /* SNB  IVB eDP input 
  clock at 400Mhz */
  else
  aux_clock_divider = 225; /* eDP input clock at 
  450Mhz */
  -   } else if (HAS_PCH_SPLIT(dev))
  +   } else  if (dev_priv-pch_id == INTEL_PCH_LPT_DEVICE_ID_TYPE) {
 
 There's a space and a tab between else and if, but I guess Daniel
 will fix this :)

Done.

 Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com

Queued for -next, thanks for the patch.
-Daniel
 
  +   /* Workaround for non-ULT HSW */
  +   aux_clock_divider = 74;
  +   } else if (HAS_PCH_SPLIT(dev)) {
  aux_clock_divider = DIV_ROUND_UP(intel_pch_rawclk(dev), 2);
  -   else
  +   } else {
  aux_clock_divider = intel_hrawclk(dev) / 2;
  +   }
 
  if (IS_GEN6(dev))
  precharge = 3;
  --
  1.7.10.4
 
 
 
 
 --
 Paulo Zanoni
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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: Reject fence stride=0 on gen4+

2013-04-09 Thread Daniel Vetter
On Tue, Apr 09, 2013 at 05:46:45PM +0300, ville.syrj...@linux.intel.com wrote:
 From: Ville Syrjälä ville.syrj...@linux.intel.com
 
 Our checks for an invalid fence stride forgot to guard against
 zero stride on gen4+. Fix it.
 
 Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com

This duplicates the tiny stride check a bit with the gen2/3 code. What
about


diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c 
b/drivers/gpu/drm/i915/i915_gem_tiling.c
index c807eb9..b56185f 100644
--- a/drivers/gpu/drm/i915/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
@@ -235,6 +235,9 @@ i915_tiling_ok(struct drm_device *dev, int stride, int 
size, int tiling_mode)
}
}
 
+   if (stride  tile_width)
+   return false;
+
/* 965+ just needs multiples of tile width */
if (INTEL_INFO(dev)-gen = 4) {
if (stride  (tile_width - 1))
@@ -243,9 +246,6 @@ i915_tiling_ok(struct drm_device *dev, int stride, int 
size, int tiling_mode)
}
 
/* Pre-965 needs power of two tile widths */
-   if (stride  tile_width)
-   return false;
-
if (stride  (stride - 1))
return false;
 
instead?
-Daniel

 ---
  drivers/gpu/drm/i915/i915_gem_tiling.c | 2 ++
  1 file changed, 2 insertions(+)
 
 diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c 
 b/drivers/gpu/drm/i915/i915_gem_tiling.c
 index 139d17d..16ff6e7 100644
 --- a/drivers/gpu/drm/i915/i915_gem_tiling.c
 +++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
 @@ -240,6 +240,8 @@ i915_tiling_ok(struct drm_device *dev, int stride, int 
 size, int tiling_mode)
  
   /* 965+ just needs multiples of tile width */
   if (INTEL_INFO(dev)-gen = 4) {
 + if (stride  tile_width)
 + return false;
   if (stride  (tile_width - 1))
   return false;
   return true;
 -- 
 1.8.1.5
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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: Reject fence stride=0 on gen4+

2013-04-09 Thread Ville Syrjälä
On Tue, Apr 09, 2013 at 05:01:18PM +0200, Daniel Vetter wrote:
 On Tue, Apr 09, 2013 at 05:46:45PM +0300, ville.syrj...@linux.intel.com wrote:
  From: Ville Syrjälä ville.syrj...@linux.intel.com
  
  Our checks for an invalid fence stride forgot to guard against
  zero stride on gen4+. Fix it.
  
  Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
 
 This duplicates the tiny stride check a bit with the gen2/3 code. What
 about
 
 
 diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c 
 b/drivers/gpu/drm/i915/i915_gem_tiling.c
 index c807eb9..b56185f 100644
 --- a/drivers/gpu/drm/i915/i915_gem_tiling.c
 +++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
 @@ -235,6 +235,9 @@ i915_tiling_ok(struct drm_device *dev, int stride, int 
 size, int tiling_mode)
   }
   }
  
 + if (stride  tile_width)
 + return false;
 +
   /* 965+ just needs multiples of tile width */
   if (INTEL_INFO(dev)-gen = 4) {
   if (stride  (tile_width - 1))
 @@ -243,9 +246,6 @@ i915_tiling_ok(struct drm_device *dev, int stride, int 
 size, int tiling_mode)
   }
  
   /* Pre-965 needs power of two tile widths */
 - if (stride  tile_width)
 - return false;
 -
   if (stride  (stride - 1))
   return false;
  
 instead?

Looks OK. The same idea occured to me, but only after hitting enter.

 -Daniel
 
  ---
   drivers/gpu/drm/i915/i915_gem_tiling.c | 2 ++
   1 file changed, 2 insertions(+)
  
  diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c 
  b/drivers/gpu/drm/i915/i915_gem_tiling.c
  index 139d17d..16ff6e7 100644
  --- a/drivers/gpu/drm/i915/i915_gem_tiling.c
  +++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
  @@ -240,6 +240,8 @@ i915_tiling_ok(struct drm_device *dev, int stride, int 
  size, int tiling_mode)
   
  /* 965+ just needs multiples of tile width */
  if (INTEL_INFO(dev)-gen = 4) {
  +   if (stride  tile_width)
  +   return false;
  if (stride  (tile_width - 1))
  return false;
  return true;
  -- 
  1.8.1.5
  
  ___
  Intel-gfx mailing list
  Intel-gfx@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/intel-gfx
 
 -- 
 Daniel Vetter
 Software Engineer, Intel Corporation
 +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 
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 1/3] drm/i915: Add ECOBITS_SNB_BIT

2013-04-09 Thread Imre Deak
On Thu, 2013-04-04 at 15:13 +0300, ville.syrj...@linux.intel.com wrote:
 From: Ville Syrjälä ville.syrj...@linux.intel.com
 
 GAC_ECO_BITS has a bit similar to GAM_ECOCHK's ECOCHK_SNB_BIT. Add
 the define, and enable it on SNB.
 
 Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com

On the series:
Reviewed-by: Imre Deak imre.d...@intel.com

 ---
  drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ++-
  drivers/gpu/drm/i915/i915_reg.h | 1 +
  2 files changed, 3 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
 b/drivers/gpu/drm/i915/i915_gem_gtt.c
 index 24a23b3..593137b 100644
 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
 +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
 @@ -312,7 +312,8 @@ void i915_gem_init_ppgtt(struct drm_device *dev)
   uint32_t ecochk, gab_ctl, ecobits;
  
   ecobits = I915_READ(GAC_ECO_BITS);
 - I915_WRITE(GAC_ECO_BITS, ecobits | ECOBITS_PPGTT_CACHE64B);
 + I915_WRITE(GAC_ECO_BITS, ecobits | ECOBITS_SNB_BIT |
 +  ECOBITS_PPGTT_CACHE64B);
  
   gab_ctl = I915_READ(GAB_CTL);
   I915_WRITE(GAB_CTL, gab_ctl | GAB_CTL_CONT_AFTER_PAGEFAULT);
 diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
 index 058686c..4b8fd4d 100644
 --- a/drivers/gpu/drm/i915/i915_reg.h
 +++ b/drivers/gpu/drm/i915/i915_reg.h
 @@ -127,6 +127,7 @@
  #define   ECOCHK_PPGTT_CACHE4B   (0x03)
  
  #define GAC_ECO_BITS 0x14090
 +#define   ECOBITS_SNB_BIT(113)
  #define   ECOBITS_PPGTT_CACHE64B (38)
  #define   ECOBITS_PPGTT_CACHE4B  (08)
  


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


Re: [Intel-gfx] commit drm/i915: disable shared panel fitter for pipe breaks resolution switching

2013-04-09 Thread Daniel Vetter
Can you please quickly test whether the below patch changes anything
in the behaviour?

diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8809813..974ae32 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4715,7 +4715,7 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,

i9xx_set_pipeconf(intel_crtc);

-   intel_enable_pipe(dev_priv, pipe, false);
+   //intel_enable_pipe(dev_priv, pipe, false);

intel_wait_for_vblank(dev, pipe);



On Mon, Apr 8, 2013 at 7:38 PM, Hans de Bruin jmdebr...@xmsnet.nl wrote:
 On 04/07/2013 08:56 PM, Daniel Vetter wrote:

 On Sun, Mar 10, 2013 at 06:02:32PM +0100, Hans de Bruin wrote:

 On 03/06/2013 11:37 PM, Daniel Vetter wrote:

 On Wed, Mar 6, 2013 at 7:39 PM, Hans de Bruin jmdebr...@xmsnet.nl
 wrote:

 On 03/06/2013 03:00 PM, Daniel Vetter wrote:


 Hi Hans,

 Can you please test with 3.9-rc1? That contains an additional patch
 which might prevent the regression. Specifically

 commit 9d6d9f19e8146fa24903cb561e204a22232740e3
 Author: Mika Kuoppala mika.kuopp...@linux.intel.com
 Date:   Fri Feb 8 16:35:38 2013 +0200

   drm/i915: clean up panel fitter handling in lvds



 Today's kernel still contains the bug.


 Hm, I've just retested latest drm-intel-nightly which should have the
 same set of relevant patches, and I couldn't reproduce your issue.
 Low-res modes on the lvds panel seem to correctly scale up here on my
 945gm.

 Can you pls retest with latest -nightly from
 http://cgit.freedesktop.org/~danvet/drm-intel ?

 Also please attach the output of xrandr --verbose when running with a
 reduced mode.


 tested:
 http://cgit.freedesktop.org/~danvet/drm-intel
 commit d08a6eb2690b1ac6f0582feb41c2ccbea945285f
 Date:   Thu Mar 7 22:54:25 2013 +0100

 The problem is still there


 my previous post contained  the  xrandr output whiteout the verbose.
 Doe you want my to repost with the verbose option?


 Sorry for the long delay in taking again a look at this. I've tried to
 reproduce this on my various machines similar to yours, but totally
 failed. Also, a bunch of people with matching machines to yours actually
 claim that the 2 commits which regress for you actually fix up lvds panel
 fiting for them. So I'm a bit lost as to what's going on here.

 Can you please try the below debug patch on top of latest 3.9-rc kernels?

 Please boot that kernel with drm.debug=0xe added to your kernel cmdline,
 reproduce the issue (preferrably with xrandr --output LVDS --mode ...) and
 then attach the complete dmesg. This will enable lots of debugging, so
 please make sure you grab everything starting from when i915.ko loads.


 ok, here is de dmesg.

 --
 Hans






--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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: Don't default to overclock max

2013-04-09 Thread Daniel Vetter
On Tue, Apr 09, 2013 at 04:44:28PM +0300, Mika Kuoppala wrote:
 Ben Widawsky b...@bwidawsk.net writes:
 
  Requested-by: Daniel Vetter daniel.vet...@ffwll.ch
  Signed-off-by: Ben Widawsky b...@bwidawsk.net
  ---
   drivers/gpu/drm/i915/intel_pm.c | 3 +--
   1 file changed, 1 insertion(+), 2 deletions(-)
 
  diff --git a/drivers/gpu/drm/i915/intel_pm.c 
  b/drivers/gpu/drm/i915/intel_pm.c
  index 2edb743..c81921b 100644
  --- a/drivers/gpu/drm/i915/intel_pm.c
  +++ b/drivers/gpu/drm/i915/intel_pm.c
  @@ -2632,11 +2632,10 @@ static void gen6_enable_rps(struct drm_device *dev)
  pcu_mbox = 0;
  ret = sandybridge_pcode_read(dev_priv, GEN6_READ_OC_PARAMS, 
  pcu_mbox);
  if (!ret  (pcu_mbox  (131))) { /* OC supported */
  -   DRM_DEBUG_DRIVER(overclocking supported, adjusting 
  frequency max from %dMHz to %dMHz\n,
  +   DRM_DEBUG_DRIVER(Overclocking supported. Max: %dMHz, 
  Overclock max: %dMHz\n,
   (dev_priv-rps.max_delay  0xff) * 50,
   (pcu_mbox  0xff) * 50);
 Minor nitpick:  
 Use GT_FREQUENCY_MULTIPLIER instead of 50

I've ignored that one for now ...

 
  dev_priv-rps.hw_max = pcu_mbox  0xff;
  -   dev_priv-rps.max_delay = pcu_mbox  0xff;
  }
  } else {
  DRM_DEBUG_DRIVER(Failed to set the min frequency\n);
  -- 
  1.8.2
 
 Reviewed-by: Mika Kuoppala mika.kuopp...@intel.com

Mika clarified that he indeed reviewed v2 of patch 1 but replied to the
wrong one. Both merged, thanks for the patches.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2] drm/i915: Reject fence stride=0 on gen4+

2013-04-09 Thread ville . syrjala
From: Ville Syrjälä ville.syrj...@linux.intel.com

Our checks for an invalid fence stride forgot to guard against
zero stride on gen4+. Fix it.

v2: Avoid duplicated code (danvet)

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_gem_tiling.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c 
b/drivers/gpu/drm/i915/i915_gem_tiling.c
index 139d17d..537545b 100644
--- a/drivers/gpu/drm/i915/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
@@ -238,6 +238,9 @@ i915_tiling_ok(struct drm_device *dev, int stride, int 
size, int tiling_mode)
}
}
 
+   if (stride  tile_width)
+   return false;
+
/* 965+ just needs multiples of tile width */
if (INTEL_INFO(dev)-gen = 4) {
if (stride  (tile_width - 1))
@@ -246,9 +249,6 @@ i915_tiling_ok(struct drm_device *dev, int stride, int 
size, int tiling_mode)
}
 
/* Pre-965 needs power of two tile widths */
-   if (stride  tile_width)
-   return false;
-
if (stride  (stride - 1))
return false;
 
-- 
1.8.1.5

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


Re: [Intel-gfx] [PATCH v2] drm/i915: Reject fence stride=0 on gen4+

2013-04-09 Thread Daniel Vetter
On Tue, Apr 09, 2013 at 08:09:13PM +0300, ville.syrj...@linux.intel.com wrote:
 From: Ville Syrjälä ville.syrj...@linux.intel.com
 
 Our checks for an invalid fence stride forgot to guard against
 zero stride on gen4+. Fix it.
 
 v2: Avoid duplicated code (danvet)
 
 Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Queued for -next, thanks for the patch.
-Daniel
 ---
  drivers/gpu/drm/i915/i915_gem_tiling.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c 
 b/drivers/gpu/drm/i915/i915_gem_tiling.c
 index 139d17d..537545b 100644
 --- a/drivers/gpu/drm/i915/i915_gem_tiling.c
 +++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
 @@ -238,6 +238,9 @@ i915_tiling_ok(struct drm_device *dev, int stride, int 
 size, int tiling_mode)
   }
   }
  
 + if (stride  tile_width)
 + return false;
 +
   /* 965+ just needs multiples of tile width */
   if (INTEL_INFO(dev)-gen = 4) {
   if (stride  (tile_width - 1))
 @@ -246,9 +249,6 @@ i915_tiling_ok(struct drm_device *dev, int stride, int 
 size, int tiling_mode)
   }
  
   /* Pre-965 needs power of two tile widths */
 - if (stride  tile_width)
 - return false;
 -
   if (stride  (stride - 1))
   return false;
  
 -- 
 1.8.1.5
 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] commit drm/i915: disable shared panel fitter for pipe breaks resolution switching

2013-04-09 Thread Hans de Bruin

On 04/09/2013 06:40 PM, Daniel Vetter wrote:

Can you please quickly test whether the below patch changes anything
in the behaviour?

diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8809813..974ae32 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4715,7 +4715,7 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,

 i9xx_set_pipeconf(intel_crtc);

-   intel_enable_pipe(dev_priv, pipe, false);
+   //intel_enable_pipe(dev_priv, pipe, false);

 intel_wait_for_vblank(dev, pipe);






for some reason the diff did not work. Here a snippet of my modified 
intel_display.c:



...
/* pipesrc and dspsize control the size that is scaled from,
 * which should always be the user's requested size.
 */
I915_WRITE(DSPSIZE(plane),
   ((mode-vdisplay - 1)  16) |
   (mode-hdisplay - 1));
I915_WRITE(DSPPOS(plane), 0);

I915_WRITE(PIPECONF(pipe), pipeconf);
POSTING_READ(PIPECONF(pipe));
//intel_enable_pipe(dev_priv, pipe, false);

intel_wait_for_vblank(dev, pipe);

I915_WRITE(DSPCNTR(plane), dspcntr);
POSTING_READ(DSPCNTR(plane));
...

The screen still does not scale.


By the way, I have had this problem before: 
https://bugzilla.kernel.org/show_bug.cgi?id=43071


--
Hans





On Mon, Apr 8, 2013 at 7:38 PM, Hans de Bruin jmdebr...@xmsnet.nl wrote:

On 04/07/2013 08:56 PM, Daniel Vetter wrote:


On Sun, Mar 10, 2013 at 06:02:32PM +0100, Hans de Bruin wrote:


On 03/06/2013 11:37 PM, Daniel Vetter wrote:


On Wed, Mar 6, 2013 at 7:39 PM, Hans de Bruin jmdebr...@xmsnet.nl
wrote:


On 03/06/2013 03:00 PM, Daniel Vetter wrote:



Hi Hans,

Can you please test with 3.9-rc1? That contains an additional patch
which might prevent the regression. Specifically

commit 9d6d9f19e8146fa24903cb561e204a22232740e3
Author: Mika Kuoppala mika.kuopp...@linux.intel.com
Date:   Fri Feb 8 16:35:38 2013 +0200

   drm/i915: clean up panel fitter handling in lvds




Today's kernel still contains the bug.



Hm, I've just retested latest drm-intel-nightly which should have the
same set of relevant patches, and I couldn't reproduce your issue.
Low-res modes on the lvds panel seem to correctly scale up here on my
945gm.

Can you pls retest with latest -nightly from
http://cgit.freedesktop.org/~danvet/drm-intel ?

Also please attach the output of xrandr --verbose when running with a
reduced mode.



tested:
http://cgit.freedesktop.org/~danvet/drm-intel
commit d08a6eb2690b1ac6f0582feb41c2ccbea945285f
Date:   Thu Mar 7 22:54:25 2013 +0100

The problem is still there


my previous post contained  the  xrandr output whiteout the verbose.
Doe you want my to repost with the verbose option?



Sorry for the long delay in taking again a look at this. I've tried to
reproduce this on my various machines similar to yours, but totally
failed. Also, a bunch of people with matching machines to yours actually
claim that the 2 commits which regress for you actually fix up lvds panel
fiting for them. So I'm a bit lost as to what's going on here.

Can you please try the below debug patch on top of latest 3.9-rc kernels?

Please boot that kernel with drm.debug=0xe added to your kernel cmdline,
reproduce the issue (preferrably with xrandr --output LVDS --mode ...) and
then attach the complete dmesg. This will enable lots of debugging, so
please make sure you grab everything starting from when i915.ko loads.



ok, here is de dmesg.

--
Hans







--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch



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


Re: [Intel-gfx] commit drm/i915: disable shared panel fitter for pipe breaks resolution switching

2013-04-09 Thread Hans de Bruin

On 04/09/2013 07:42 PM, Hans de Bruin wrote:

On 04/09/2013 06:40 PM, Daniel Vetter wrote:

Can you please quickly test whether the below patch changes anything
in the behaviour?

diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8809813..974ae32 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4715,7 +4715,7 @@ static int i9xx_crtc_mode_set(struct drm_crtc
*crtc,

 i9xx_set_pipeconf(intel_crtc);

-   intel_enable_pipe(dev_priv, pipe, false);
+   //intel_enable_pipe(dev_priv, pipe, false);

 intel_wait_for_vblank(dev, pipe);






for some reason the diff did not work. Here a snippet of my modified
intel_display.c:


...
 /* pipesrc and dspsize control the size that is scaled from,
  * which should always be the user's requested size.
  */
 I915_WRITE(DSPSIZE(plane),
((mode-vdisplay - 1)  16) |
(mode-hdisplay - 1));
 I915_WRITE(DSPPOS(plane), 0);

 I915_WRITE(PIPECONF(pipe), pipeconf);
 POSTING_READ(PIPECONF(pipe));
 //intel_enable_pipe(dev_priv, pipe, false);

 intel_wait_for_vblank(dev, pipe);

 I915_WRITE(DSPCNTR(plane), dspcntr);
 POSTING_READ(DSPCNTR(plane));
...

The screen still does not scale.


By the way, I have had this problem before:
https://bugzilla.kernel.org/show_bug.cgi?id=43071


sorry my mistake that one did scale, but just was not alligned properly.

--
Hans

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


Re: [Intel-gfx] commit drm/i915: disable shared panel fitter for pipe breaks resolution switching

2013-04-09 Thread Daniel Vetter
On Tue, Apr 9, 2013 at 7:51 PM, Hans de Bruin jmdebr...@xmsnet.nl wrote:
  /* pipesrc and dspsize control the size that is scaled from,
   * which should always be the user's requested size.
   */
  I915_WRITE(DSPSIZE(plane),
 ((mode-vdisplay - 1)  16) |
 (mode-hdisplay - 1));
  I915_WRITE(DSPPOS(plane), 0);

  I915_WRITE(PIPECONF(pipe), pipeconf);
  POSTING_READ(PIPECONF(pipe));
  //intel_enable_pipe(dev_priv, pipe, false);

  intel_wait_for_vblank(dev, pipe);

  I915_WRITE(DSPCNTR(plane), dspcntr);
  POSTING_READ(DSPCNTR(plane));
 ...

 The screen still does not scale.


 By the way, I have had this problem before:
 https://bugzilla.kernel.org/show_bug.cgi?id=43071


 sorry my mistake that one did scale, but just was not alligned properly.

Now I'm confused, please clarify: Did the patch help a bit? Can you
pls describe more precisely what not aligned properly means? Have
you checked whether changing the scaling mode xrandr property helps?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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: HSW FBC WaFbcDisableDpfcClockGating

2013-04-09 Thread Rodrigo Vivi
On Tue, Apr 9, 2013 at 5:37 AM, Ville Syrjälä ville.syrj...@linux.intel.com
 wrote:

 On Mon, Apr 08, 2013 at 06:49:44PM -0300, Rodrigo Vivi wrote:
  Display register 46500h bit 23 must be set to 1b for the entire time that
  Frame Buffer Compression is enabled.

 So should we enable it again after FBC is disabled to avoid wasting
 power?


I didn't take the opposite direction because it wasn't explicit.
I tested to enabled it again after FBC is disabled but I didn't see any
difference.
So, you suggestion is to enable back anyway?



 
  Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
  ---
   drivers/gpu/drm/i915/i915_reg.h | 3 +++
   drivers/gpu/drm/i915/intel_pm.c | 2 ++
   2 files changed, 5 insertions(+)
 
  diff --git a/drivers/gpu/drm/i915/i915_reg.h
 b/drivers/gpu/drm/i915/i915_reg.h
  index 2340bc2..2ef0292 100644
  --- a/drivers/gpu/drm/i915/i915_reg.h
  +++ b/drivers/gpu/drm/i915/i915_reg.h
  @@ -863,6 +863,9 @@
 _HSW_PIPE_SLICE_CHICKEN_1_A,
 + \
 _HSW_PIPE_SLICE_CHICKEN_1_B)
 
  +#define HSW_CLKGATE_DISABLE_PART_1   0x46500
  +#define   HSW_DPFC_GATING_DISABLE(123)
  +
   /*
* GPIO regs
*/
  diff --git a/drivers/gpu/drm/i915/intel_pm.c
 b/drivers/gpu/drm/i915/intel_pm.c
  index 0628a84..f2ce541 100644
  --- a/drivers/gpu/drm/i915/intel_pm.c
  +++ b/drivers/gpu/drm/i915/intel_pm.c
  @@ -281,6 +281,8 @@ static void haswell_enable_fbc(struct drm_crtc
 *crtc, unsigned long interval)
/* WaFbcAsynchFlipDisableFbcQueue */
I915_WRITE(HSW_PIPE_SLICE_CHICKEN_1(intel_crtc-pipe),
   HSW_BYPASS_FBC_QUEUE);
  + /* WaFbcDisableDpfcClockGating */
  + I915_WRITE(HSW_CLKGATE_DISABLE_PART_1, HSW_DPFC_GATING_DISABLE);
 
if (obj-fence_reg != I915_FENCE_REG_NONE) {
I915_WRITE(SNB_DPFC_CTL_SA,
  --
  1.8.1.4
 
  ___
  Intel-gfx mailing list
  Intel-gfx@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/intel-gfx

 --
 Ville Syrjälä
 Intel OTC




-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH i-g-t v4] tests/gem_tiling_max_stride: Add a test for max fence stride

2013-04-09 Thread Chris Wilson
On Tue, Apr 09, 2013 at 05:45:37PM +0300, ville.syrj...@linux.intel.com wrote:
 From: Ville Syrjälä ville.syrj...@linux.intel.com
 
 gem_tiling_max_stride writes a data pattern to an X-tiled buffer using
 the maximum supported stride, reads the data back as linear, and
 verifies that the data didn't get scrambled on the way.
 
 The test also checks that some invalid stride values are rejected
 properly.
 
 v2: Check invalid strides
 v3: Check invalid stride with Y-tiling
 Include a few more invalid stride values
 Fix gen3 X-tile size
 v4: A few more invalid strides :)
 Drop the useless memset()
 
 Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com

I think I've exhausted my wishlist, and congrats on finding the bug, so
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
-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 1/3] drm/i915: Enable FBC at Haswell.

2013-04-09 Thread Rodrigo Vivi
On Tue, Apr 9, 2013 at 5:35 AM, Ville Syrjälä ville.syrj...@linux.intel.com
 wrote:

 On Mon, Apr 08, 2013 at 06:49:42PM -0300, Rodrigo Vivi wrote:
  This patch introduce Frame Buffer Compression (FBC) support for HSW.
  It adds a new function haswell_enable_fbc to avoid getting
  ironlake_enable_fbc messed with many IS_HASWELL checks.
 
  Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
  ---
   drivers/gpu/drm/i915/i915_drv.c |  1 +
   drivers/gpu/drm/i915/i915_reg.h |  6 ++
   drivers/gpu/drm/i915/intel_pm.c | 44
 -
   3 files changed, 50 insertions(+), 1 deletion(-)
 
  diff --git a/drivers/gpu/drm/i915/i915_drv.c
 b/drivers/gpu/drm/i915/i915_drv.c
  index 0cfc778..88fd6fb 100644
  --- a/drivers/gpu/drm/i915/i915_drv.c
  +++ b/drivers/gpu/drm/i915/i915_drv.c
  @@ -291,6 +291,7 @@ static const struct intel_device_info
 intel_haswell_m_info = {
GEN7_FEATURES,
.is_haswell = 1,
.is_mobile = 1,
  + .has_fbc = 1,
   };
 
   static const struct pci_device_id pciidlist[] = {/* aka */
  diff --git a/drivers/gpu/drm/i915/i915_reg.h
 b/drivers/gpu/drm/i915/i915_reg.h
  index 5e91fbb..cb8e213 100644
  --- a/drivers/gpu/drm/i915/i915_reg.h
  +++ b/drivers/gpu/drm/i915/i915_reg.h
  @@ -849,6 +849,12 @@
   #define   SNB_CPU_FENCE_ENABLE   (129)
   #define DPFC_CPU_FENCE_OFFSET0x100104
 
  +/* Framebuffer compression for Haswell */
  +#define HSW_FBC_RT_BASE  0x7020
  +#define   HSW_FBC_RT_BASE_ADDR_SHIFT 12
  +
  +#define   HSW_DPFC_CTL_FENCE_EN  (128)
  +#define   HSW_DPFC_CTL_DISABLE_SLB_INIT  (115)
 
   /*
* GPIO regs
  diff --git a/drivers/gpu/drm/i915/intel_pm.c
 b/drivers/gpu/drm/i915/intel_pm.c
  index 27f94cd..94e1c3a 100644
  --- a/drivers/gpu/drm/i915/intel_pm.c
  +++ b/drivers/gpu/drm/i915/intel_pm.c
  @@ -253,6 +253,43 @@ static bool ironlake_fbc_enabled(struct drm_device
 *dev)
return I915_READ(ILK_DPFC_CONTROL)  DPFC_CTL_EN;
   }
 
  +static void haswell_enable_fbc(struct drm_crtc *crtc, unsigned long
 interval)
  +{
  + struct drm_device *dev = crtc-dev;
  + struct drm_i915_private *dev_priv = dev-dev_private;
  + struct drm_framebuffer *fb = crtc-fb;
  + struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
  + struct drm_i915_gem_object *obj = intel_fb-obj;
  + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
  + int plane = intel_crtc-plane == 0 ? DPFC_CTL_PLANEA :
 DPFC_CTL_PLANEB;
  + unsigned long stall_watermark = 200;
  + u32 dpfc_ctl;
  +
  + dpfc_ctl = I915_READ(ILK_DPFC_CONTROL);
  + dpfc_ctl |= (plane | DPFC_CTL_LIMIT_1X);

 Accroding to BSpec FBC is always tied to plane A. Bit 30 is MBZ.


Yeah, you are right. I'm going to add a verification at  begining like:
 if (intel_crtc-plane != PLANE_A) {
dev_priv-no_fbc_reason = FBC_BAD_PLANE;
return;
}


 Maybe fix up plane C FBC support for IVB while you're poking at the
 general direction?


Actually I wasn't trying general directions since I splited it out. It was
just bad copy and paste actually.



  + dpfc_ctl |= (HSW_DPFC_CTL_FENCE_EN | obj-fence_reg);

 The CPU fence field must be written with 0. SNB/IVB could do with the
 same fix.


Where did you get this restriction for HSW? Should we write 0 or not touch
by removing lis line?


Thanks for all your comments!



  + dpfc_ctl |= HSW_DPFC_CTL_DISABLE_SLB_INIT;
  + I915_WRITE(ILK_DPFC_RECOMP_CTL, DPFC_RECOMP_STALL_EN |
  +(stall_watermark  DPFC_RECOMP_STALL_WM_SHIFT) |
  +(interval  DPFC_RECOMP_TIMER_COUNT_SHIFT));
  + I915_WRITE(HSW_FBC_RT_BASE,
  +obj-gtt_offset  HSW_FBC_RT_BASE_ADDR_SHIFT |
  +ILK_FBC_RT_VALID);
  + /* enable it... */
  + I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN);
  +
  + if (obj-fence_reg != I915_FENCE_REG_NONE) {
  + I915_WRITE(SNB_DPFC_CTL_SA,
  +SNB_CPU_FENCE_ENABLE | obj-fence_reg);
  + I915_WRITE(DPFC_CPU_FENCE_OFFSET, crtc-y);
  + } else
  + I915_WRITE(SNB_DPFC_CTL_SA, ~SNB_CPU_FENCE_ENABLE);
  +
  + sandybridge_blit_fbc_update(dev);
  +
  + DRM_DEBUG_KMS(enabled fbc on plane %d\n, intel_crtc-plane);
  +}
  +
   bool intel_fbc_enabled(struct drm_device *dev)
   {
struct drm_i915_private *dev_priv = dev-dev_private;
  @@ -4158,7 +4195,12 @@ void intel_init_pm(struct drm_device *dev)
if (I915_HAS_FBC(dev)) {
if (HAS_PCH_SPLIT(dev)) {
dev_priv-display.fbc_enabled =
 ironlake_fbc_enabled;
  - dev_priv-display.enable_fbc = ironlake_enable_fbc;
  + if (IS_HASWELL(dev))
  + dev_priv-display.enable_fbc =
  + haswell_enable_fbc;
  + else
  + dev_priv-display.enable_fbc =
  +

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Increase max fence pitch limit to 256KB on IVB+

2013-04-09 Thread Daniel Vetter
On Tue, Apr 09, 2013 at 03:03:28PM +0300, Ville Syrjälä wrote:
 On Tue, Apr 09, 2013 at 01:54:01PM +0200, Daniel Vetter wrote:
  On Tue, Apr 09, 2013 at 11:45:05AM +0300, ville.syrj...@linux.intel.com 
  wrote:
   From: Ville Syrjälä ville.syrj...@linux.intel.com
   
   BSpec contains several scattered notes which state that the maximum
   fence stride was increased to 256KB on IVB.
   
   Testing on real hardware agrees.
   
   Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
   ---
drivers/gpu/drm/i915/i915_gem_tiling.c | 9 ++---
drivers/gpu/drm/i915/i915_reg.h| 1 +
2 files changed, 7 insertions(+), 3 deletions(-)
   
   diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c 
   b/drivers/gpu/drm/i915/i915_gem_tiling.c
   index c807eb9..139d17d 100644
   --- a/drivers/gpu/drm/i915/i915_gem_tiling.c
   +++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
   @@ -217,9 +217,12 @@ i915_tiling_ok(struct drm_device *dev, int stride, 
   int size, int tiling_mode)
 tile_width = 512;

 /* check maximum stride  object size */
   - if (INTEL_INFO(dev)-gen = 4) {
   - /* i965 stores the end address of the gtt mapping in the fence
   -  * reg, so dont bother to check the size */
   + /* i965+ stores the end address of the gtt mapping in the fence
   +  * reg, so dont bother to check the size */
   + if (INTEL_INFO(dev)-gen = 7) {
  
  I've thought that his does not apply to vlv? Or has that now changed?
 
 The docs are telling me that VLV also has 256KB max stride.

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

 
  -Daniel
  
   + if (stride / 128  GEN7_FENCE_MAX_PITCH_VAL)
   + return false;
   + } else if (INTEL_INFO(dev)-gen = 4) {
 if (stride / 128  I965_FENCE_MAX_PITCH_VAL)
 return false;
 } else {
   diff --git a/drivers/gpu/drm/i915/i915_reg.h 
   b/drivers/gpu/drm/i915/i915_reg.h
   index 0e4b7fb..ec4e054 100644
   --- a/drivers/gpu/drm/i915/i915_reg.h
   +++ b/drivers/gpu/drm/i915/i915_reg.h
   @@ -424,6 +424,7 @@

#define FENCE_REG_SANDYBRIDGE_0  0x10
#define   SANDYBRIDGE_FENCE_PITCH_SHIFT  32
   +#define   GEN7_FENCE_MAX_PITCH_VAL   0x0800

/* control register for cpu gtt access */
#define TILECTL  0x101000
   -- 
   1.8.1.5
   
   ___
   Intel-gfx mailing list
   Intel-gfx@lists.freedesktop.org
   http://lists.freedesktop.org/mailman/listinfo/intel-gfx
  
  -- 
  Daniel Vetter
  Software Engineer, Intel Corporation
  +41 (0) 79 365 57 48 - http://blog.ffwll.ch
 
 -- 
 Ville Syrjälä
 Intel OTC

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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 i-g-t v4] tests/gem_tiling_max_stride: Add a test for max fence stride

2013-04-09 Thread Daniel Vetter
On Tue, Apr 09, 2013 at 07:06:32PM +0100, Chris Wilson wrote:
 On Tue, Apr 09, 2013 at 05:45:37PM +0300, ville.syrj...@linux.intel.com wrote:
  From: Ville Syrjälä ville.syrj...@linux.intel.com
  
  gem_tiling_max_stride writes a data pattern to an X-tiled buffer using
  the maximum supported stride, reads the data back as linear, and
  verifies that the data didn't get scrambled on the way.
  
  The test also checks that some invalid stride values are rejected
  properly.
  
  v2: Check invalid strides
  v3: Check invalid stride with Y-tiling
  Include a few more invalid stride values
  Fix gen3 X-tile size
  v4: A few more invalid strides :)
  Drop the useless memset()
  
  Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
 
 I think I've exhausted my wishlist, and congrats on finding the bug, so
 Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk

Merged all three patches, thanks a lot for supplying paranoid igt cases.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915: don't check inconsistent modeset state when force-restoring

2013-04-09 Thread Daniel Vetter
It will be only consistent once we've restored all the crtcs. Since a
bunch of other callers also want to just restore a single crtc, add a
boolean to disable checking only where it doesn't make sense.

Note that intel_modeset_setup_hw_state already has a call to
intel_modeset_check_state at the end, so we don't reduce the amount of
checking.

v2: Try harder not to create a big patch (Chris).

References: https://lkml.org/lkml/2013/3/16/60
Cc: Tomas Melin tomas.me...@iki.fi
Cc: Richard Cochran richardcoch...@gmail.com
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/intel_display.c |   34 +++---
 1 file changed, 27 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 8809813..2959fb8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7916,9 +7916,9 @@ intel_modeset_check_state(struct drm_device *dev)
}
 }
 
-int intel_set_mode(struct drm_crtc *crtc,
-  struct drm_display_mode *mode,
-  int x, int y, struct drm_framebuffer *fb)
+static int __intel_set_mode(struct drm_crtc *crtc,
+   struct drm_display_mode *mode,
+   int x, int y, struct drm_framebuffer *fb)
 {
struct drm_device *dev = crtc-dev;
drm_i915_private_t *dev_priv = dev-dev_private;
@@ -8012,8 +8012,6 @@ done:
if (ret  crtc-enabled) {
crtc-hwmode = *saved_hwmode;
crtc-mode = *saved_mode;
-   } else {
-   intel_modeset_check_state(dev);
}
 
 out:
@@ -8022,9 +8020,25 @@ out:
return ret;
 }
 
+int intel_set_mode(struct drm_crtc *crtc,
+struct drm_display_mode *mode,
+int x, int y, struct drm_framebuffer *fb)
+{
+   int ret;
+
+   ret = __intel_set_mode(crtc, mode, x, y, fb);
+
+   if (ret == 0)
+   intel_modeset_check_state(crtc-dev);
+
+   return ret;
+}
+
 void intel_crtc_restore_mode(struct drm_crtc *crtc)
 {
-   intel_set_mode(crtc, crtc-mode, crtc-x, crtc-y, crtc-fb);
+   __intel_set_mode(crtc, crtc-mode, crtc-x, crtc-y, crtc-fb);
+
+   intel_modeset_check_state(crtc-dev);
 }
 
 #undef for_each_intel_crtc_masked
@@ -9333,10 +9347,16 @@ setup_pipes:
}
 
if (force_restore) {
+   /* 
+* We need to use raw interfaces for restoring state to avoid
+* checking (bogus) intermediate states.
+*/
for_each_pipe(pipe) {
struct drm_crtc *crtc =
dev_priv-pipe_to_crtc_mapping[pipe];
-   intel_crtc_restore_mode(crtc);
+
+   __intel_set_mode(crtc, crtc-mode, crtc-x, crtc-y,
+crtc-fb);
}
list_for_each_entry(plane, dev-mode_config.plane_list, head)
intel_plane_restore(plane);
-- 
1.7.10.4

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


[Intel-gfx] [PATCH 0/3] Few SNB RC6 Init fixes

2013-04-09 Thread Rodrigo Vivi
This series is an attempt to fix many hang bugs we have at SNB with RC6.
https://bugzilla.kernel.org/show_bug.cgi?id=43267

Reporter of this 43267 mentioned that one ugly patch of mine fixed his hangs.
That patch was wrong and probably regressing some other stuff already fixed
by Chris. At that patch there was also useless things like asking gpu to
generate interrupts we don't process.

So my guess is that some or all of these 3 patches are fixing actual bugs.
Manly the second and third one.

Rodrigo Vivi (3):
  drm/i915: SNB RC6: Fix Turbo Disable.
  drm/i915: RC6 Fix Write Min Frequency Table.
  drm/i915: SNB RC6: Fix RP_CONTROL Init.

 drivers/gpu/drm/i915/i915_reg.h | 4 ++--
 drivers/gpu/drm/i915/intel_pm.c | 6 --
 2 files changed, 6 insertions(+), 4 deletions(-)

-- 
1.8.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/i915: SNB RC6: Fix Turbo Disable.

2013-04-09 Thread Rodrigo Vivi
According to SNB GT PM Programming Guide Turbo, page 8, GEN6_RPNSWREQ (A008)
bit [31] must be set as 0 meaning Turbo Disable.

Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
 drivers/gpu/drm/i915/i915_reg.h | 2 +-
 drivers/gpu/drm/i915/intel_pm.c | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5e91fbb..fc4f542f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4220,7 +4220,7 @@
 #define  GEN7_L3BANK2X_CLOCK_GATE_DISABLE  (125)
 
 #define GEN6_RPNSWREQ  0xA008
-#define   GEN6_TURBO_DISABLE   (131)
+#define   GEN6_TURBO_DISABLE   (031)
 #define   GEN6_FREQUENCY(x)((x)25)
 #define   HSW_FREQUENCY(x) ((x)24)
 #define   GEN6_OFFSET(x)   ((x)19)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 27f94cd..e3ba13d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2465,6 +2465,7 @@ void gen6_set_rps(struct drm_device *dev, u8 val)
   HSW_FREQUENCY(val));
else
I915_WRITE(GEN6_RPNSWREQ,
+  GEN6_TURBO_DISABLE |
   GEN6_FREQUENCY(val) |
   GEN6_OFFSET(0) |
   GEN6_AGGRESSIVE_TURBO);
@@ -2612,6 +2613,7 @@ static void gen6_enable_rps(struct drm_device *dev)
   HSW_FREQUENCY(12));
} else {
I915_WRITE(GEN6_RPNSWREQ,
+  GEN6_TURBO_DISABLE |
   GEN6_FREQUENCY(10) |
   GEN6_OFFSET(0) |
   GEN6_AGGRESSIVE_TURBO);
-- 
1.8.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: RC6 Fix Write Min Frequency Table.

2013-04-09 Thread Rodrigo Vivi
According to SNB GT PM Programming Guide page 9,
Write Min Frequency Table is 09h

Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
 drivers/gpu/drm/i915/i915_reg.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fc4f542f..5dcc09e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4305,7 +4305,7 @@
 #define GEN6_PCODE_MAILBOX 0x138124
 #define   GEN6_PCODE_READY (131)
 #define   GEN6_READ_OC_PARAMS  0xc
-#define   GEN6_PCODE_WRITE_MIN_FREQ_TABLE  0x8
+#define   GEN6_PCODE_WRITE_MIN_FREQ_TABLE  0x9
 #define   GEN6_PCODE_READ_MIN_FREQ_TABLE   0x9
 #define  GEN6_PCODE_WRITE_RC6VIDS  0x4
 #define  GEN6_PCODE_READ_RC6VIDS   0x5
-- 
1.8.1.4

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


[Intel-gfx] [PATCH 3/3] drm/i915: SNB RC6: Fix RP_CONTROL Init.

2013-04-09 Thread Rodrigo Vivi
According to SNB GT PM Programming Guide page 8 RP_CONTROL (A024) must be
set according this:
 * bits [10:9] = 01 - Use Normal or Video Turbo frequency req.
 * bits [2:0] = 010 - Down=Busy Min Average (EI)

Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
 drivers/gpu/drm/i915/intel_pm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e3ba13d..d88e58c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2634,11 +2634,11 @@ static void gen6_enable_rps(struct drm_device *dev)
I915_WRITE(GEN6_RP_IDLE_HYSTERSIS, 10);
I915_WRITE(GEN6_RP_CONTROL,
   GEN6_RP_MEDIA_TURBO |
-  GEN6_RP_MEDIA_HW_NORMAL_MODE |
+  GEN6_RP_MEDIA_HW_MODE |
   GEN6_RP_MEDIA_IS_GFX |
   GEN6_RP_ENABLE |
   GEN6_RP_UP_BUSY_AVG |
-  (IS_HASWELL(dev) ? GEN7_RP_DOWN_IDLE_AVG : 
GEN6_RP_DOWN_IDLE_CONT));
+  GEN7_RP_DOWN_IDLE_AVG);
 
ret = sandybridge_pcode_write(dev_priv, 
GEN6_PCODE_WRITE_MIN_FREQ_TABLE, 0);
if (!ret  (IS_GEN6(dev) || IS_IVYBRIDGE(dev))) {
-- 
1.8.1.4

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


Re: [Intel-gfx] [PATCH 2/2] drm: prime: fix lookup of existing imports for self imported buffers

2013-04-09 Thread Dave Airlie
 Since atm we don't take a reference on the dma buf pointer when we add
 it to the import lookup table the dma buf can vanish leaving the stale
 pointer behind. This can in turn lead to returning stale GEM handles
 when userspace imports a newly exported buffer.


I sent a bunch of patches to prime months ago, maybe go back and dig them out

they might fix some of these issues,

I think danvet bikeshedded my will to care at the time due to lack of
proper locking,
the fact is the patches didn't change the locking, but I could
probably go back and find them.

Hopefully you haven't gone and reinvented that work.

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


Re: [Intel-gfx] [PATCH v3 03/16] drm/i915: reference count for i915_hw_contexts

2013-04-09 Thread Chris Wilson
On Thu, Apr 04, 2013 at 06:32:35PM +0300, Mika Kuoppala wrote:
 In preparation to do analysis of which context was
 guilty of gpu hung, store kreffed context pointer
 into request struct.
 
 This allows us to inspect contexts when gpu is reset
 even if those contexts would already be released
 by userspace.
 
 v2: track i915_hw_context pointers instead of using ctx_ids
 (from Chris Wilson)
 
 v3 (Ben): Get rid of do_release() and handle refcounting more compactly.
 (recommended by Chis)
 
 v4: kref_* put inside static inlines (Daniel Vetter)
 remove code duplication on freeing context (Chris Wilson)
 
 Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com (v2)
 Signed-off-by: Ben Widawsky b...@bwidawsk.net (v3)
 Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com (v4)
 ---
 @@ -511,7 +520,7 @@ int i915_gem_context_destroy_ioctl(struct drm_device 
 *dev, void *data,
   return -ENOENT;
   }
  
 - do_destroy(ctx);
 + i915_gem_context_unreference(ctx);

This needs to remove the ctx from the idr as well as dropping the
reference associated with the id.
-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] drm/i915: reference count for i915_hw_contexts

2013-04-09 Thread Ben Widawsky
From: Mika Kuoppala mika.kuopp...@linux.intel.com

In preparation to do analysis of which context was
guilty of gpu hung, store kreffed context pointer
into request struct.

This allows us to inspect contexts when gpu is reset
even if those contexts would already be released
by userspace.

v2: track i915_hw_context pointers instead of using ctx_ids
(from Chris Wilson)

v3 (Ben): Get rid of do_release() and handle refcounting more compactly.
(recommended by Chis)

v4: kref_* put inside static inlines (Daniel Vetter)
remove code duplication on freeing context (Chris Wilson)

v5: idr_remove and ctx-file_priv = NULL in destroy ioctl (Chris)
This actually will cause a problem if one destroys a context and later
refers to the idea of the context (multiple contexts may have the same
id, but only 1 will exist in the idr).

Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com (v2)
Signed-off-by: Ben Widawsky b...@bwidawsk.net (v3)
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com (v4)
Signed-off-by: Ben Widawsky b...@bwidawsk.net (v5)
---
 drivers/gpu/drm/i915/i915_drv.h| 20 ++--
 drivers/gpu/drm/i915/i915_gem.c| 27 ---
 drivers/gpu/drm/i915/i915_gem_context.c| 21 -
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  7 ---
 4 files changed, 58 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 00a0da8..156c5a0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -456,6 +456,7 @@ struct i915_hw_ppgtt {
 /* This must match up with the value previously used for execbuf2.rsvd1. */
 #define DEFAULT_CONTEXT_ID 0
 struct i915_hw_context {
+   struct kref ref;
int id;
bool is_initialized;
struct drm_i915_file_private *file_priv;
@@ -1261,6 +1262,9 @@ struct drm_i915_gem_request {
/** Postion in the ringbuffer of the end of the request */
u32 tail;
 
+   /** Context related to this request */
+   struct i915_hw_context *ctx;
+
/** Time at which this request was emitted, in jiffies. */
unsigned long emitted_jiffies;
 
@@ -1648,9 +1652,10 @@ int __must_check i915_gpu_idle(struct drm_device *dev);
 int __must_check i915_gem_idle(struct drm_device *dev);
 int _i915_add_request(struct intel_ring_buffer *ring,
  u32 *seqno,
- struct drm_file *file);
+ struct drm_file *file,
+ struct i915_hw_context *ctx);
 #define i915_add_request(ring, seqno) \
-   _i915_add_request(ring, seqno, NULL)
+   _i915_add_request(ring, seqno, NULL, NULL)
 int __must_check i915_wait_seqno(struct intel_ring_buffer *ring,
 uint32_t seqno);
 int i915_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf);
@@ -1694,6 +1699,17 @@ void i915_gem_context_close(struct drm_device *dev, 
struct drm_file *file);
 struct i915_hw_context * __must_check
 i915_switch_context(struct intel_ring_buffer *ring,
struct drm_file *file, int to_id);
+void i915_gem_context_free(struct kref *ctx_ref);
+static inline void i915_gem_context_reference(struct i915_hw_context *ctx)
+{
+   kref_get(ctx-ref);
+}
+
+static inline void i915_gem_context_unreference(struct i915_hw_context *ctx)
+{
+   kref_put(ctx-ref, i915_gem_context_free);
+}
+
 int i915_gem_context_create_ioctl(struct drm_device *dev, void *data,
  struct drm_file *file);
 int i915_gem_context_destroy_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4e8d7b2..98b04db 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2001,7 +2001,8 @@ i915_gem_get_seqno(struct drm_device *dev, u32 *seqno)
 
 int _i915_add_request(struct intel_ring_buffer *ring,
  u32 *out_seqno,
- struct drm_file *file)
+ struct drm_file *file,
+ struct i915_hw_context *ctx)
 {
drm_i915_private_t *dev_priv = ring-dev-dev_private;
struct drm_i915_gem_request *request;
@@ -2041,6 +2042,11 @@ int _i915_add_request(struct intel_ring_buffer *ring,
request-seqno = intel_ring_get_seqno(ring);
request-ring = ring;
request-tail = request_ring_position;
+   request-ctx = ctx;
+
+   if (request-ctx)
+   i915_gem_context_reference(ctx);
+
request-emitted_jiffies = jiffies;
was_empty = list_empty(ring-request_list);
list_add_tail(request-list, ring-request_list);
@@ -2093,6 +2099,17 @@ i915_gem_request_remove_from_client(struct 
drm_i915_gem_request *request)
spin_unlock(file_priv-mm.lock);
 }
 
+static void i915_gem_free_request(struct drm_i915_gem_request *request)
+{
+   list_del(request-list);
+   

[Intel-gfx] [PATCH] drm/i915: Remove stale code

2013-04-09 Thread Ben Widawsky
Looks like a some remnant from a rebase.

Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
 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 b77e98c..50df194 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -815,7 +815,6 @@ int i915_gem_gtt_init(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
struct i915_gtt *gtt = dev_priv-gtt;
-   unsigned long gtt_size;
int ret;
 
if (INTEL_INFO(dev)-gen = 5) {
@@ -833,8 +832,6 @@ int i915_gem_gtt_init(struct drm_device *dev)
if (ret)
return ret;
 
-   gtt_size = (dev_priv-gtt.total  PAGE_SHIFT) * sizeof(gen6_gtt_pte_t);
-
/* GMADR is the PCI mmio aperture into the global GTT. */
DRM_INFO(Memory usable by graphics device = %zdM\n,
 dev_priv-gtt.total  20);
-- 
1.8.2.1

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