Re: [Intel-gfx] [PATCH 4/7] drm/i915: Helper function to determine GGTT view from plane state

2015-03-23 Thread Joonas Lahtinen
On ma, 2015-03-23 at 11:10 +, Tvrtko Ursulin wrote:
 From: Tvrtko Ursulin tvrtko.ursu...@intel.com
 
 For now only default implementation defaulting to normal view.
 
 v2: Some code review cleanups. (Joonas Lahtinen)
 
 Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Reviewed-by: Joonas Lahtinen joonas.lahti...@linux.intel.com (v2)
 ---
  drivers/gpu/drm/i915/intel_display.c | 25 ++---
  1 file changed, 22 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 4d8a397..d3fa09b 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -2288,6 +2288,15 @@ intel_fb_align_height(struct drm_device *dev, unsigned 
 int height,
  fb_format_modifier));
  }
  
 +static int
 +intel_fill_fb_ggtt_view(struct i915_ggtt_view *view, struct drm_framebuffer 
 *fb,
 + const struct drm_plane_state *plane_state)
 +{
 + *view = i915_ggtt_view_normal;
 +
 + return 0;
 +}
 +
  int
  intel_pin_and_fence_fb_obj(struct drm_plane *plane,
  struct drm_framebuffer *fb,
 @@ -2297,6 +2306,7 @@ intel_pin_and_fence_fb_obj(struct drm_plane *plane,
   struct drm_device *dev = fb-dev;
   struct drm_i915_private *dev_priv = dev-dev_private;
   struct drm_i915_gem_object *obj = intel_fb_obj(fb);
 + struct i915_ggtt_view view;
   u32 alignment;
   int ret;
  
 @@ -2333,6 +2343,10 @@ intel_pin_and_fence_fb_obj(struct drm_plane *plane,
   return -EINVAL;
   }
  
 + ret = intel_fill_fb_ggtt_view(view, fb, plane_state);
 + if (ret)
 + return ret;
 +
   /* Note that the w/a also requires 64 PTE of padding following the
* bo. We currently fill all unused PTE with the shadow page and so
* we should always have valid PTE following the scanout preventing
 @@ -2352,7 +2366,7 @@ intel_pin_and_fence_fb_obj(struct drm_plane *plane,
  
   dev_priv-mm.interruptible = false;
   ret = i915_gem_object_pin_to_display_plane(obj, alignment, pipelined,
 -i915_ggtt_view_normal);
 +view);
   if (ret)
   goto err_interruptible;
  
 @@ -2372,7 +2386,7 @@ intel_pin_and_fence_fb_obj(struct drm_plane *plane,
   return 0;
  
  err_unpin:
 - i915_gem_object_unpin_from_display_plane(obj, i915_ggtt_view_normal);
 + i915_gem_object_unpin_from_display_plane(obj, view);
  err_interruptible:
   dev_priv-mm.interruptible = true;
   intel_runtime_pm_put(dev_priv);
 @@ -2383,11 +2397,16 @@ static void intel_unpin_fb_obj(struct drm_framebuffer 
 *fb,
  const struct drm_plane_state *plane_state)
  {
   struct drm_i915_gem_object *obj = intel_fb_obj(fb);
 + struct i915_ggtt_view view;
 + int ret;
  
   WARN_ON(!mutex_is_locked(obj-base.dev-struct_mutex));
  
 + ret = intel_fill_fb_ggtt_view(view, fb, plane_state);
 + WARN_ONCE(ret, Couldn't get view from plane state!);
 +
   i915_gem_object_unpin_fence(obj);
 - i915_gem_object_unpin_from_display_plane(obj, i915_ggtt_view_normal);
 + i915_gem_object_unpin_from_display_plane(obj, view);
  }
  
  /* Computes the linear offset to the base tile and adjusts x, y. bytes per 
 pixel


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


[Intel-gfx] [PATCH i-g-t 2/9] lib: Allow 32bit addresses for IOSF-SB registers

2015-03-23 Thread ville . syrjala
From: Ville Syrjälä ville.syrj...@linux.intel.com

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 lib/intel_io.h   | 8 
 lib/intel_iosf.c | 8 
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/lib/intel_io.h b/lib/intel_io.h
index 8293353..04aa3fd 100644
--- a/lib/intel_io.h
+++ b/lib/intel_io.h
@@ -53,10 +53,10 @@ void intel_flisdsi_reg_write(uint32_t reg, uint32_t val);
 uint32_t intel_iosf_sb_read(uint32_t port, uint32_t reg);
 void intel_iosf_sb_write(uint32_t port, uint32_t reg, uint32_t val);
 
-int intel_punit_read(uint8_t addr, uint32_t *val);
-int intel_punit_write(uint8_t addr, uint32_t val);
-int intel_nc_read(uint8_t addr, uint32_t *val);
-int intel_nc_write(uint8_t addr, uint32_t val);
+int intel_punit_read(uint32_t addr, uint32_t *val);
+int intel_punit_write(uint32_t addr, uint32_t val);
+int intel_nc_read(uint32_t addr, uint32_t *val);
+int intel_nc_write(uint32_t addr, uint32_t val);
 
 /* register maps from intel_reg_map.c */
 #ifndef __GTK_DOC_IGNORE__
diff --git a/lib/intel_iosf.c b/lib/intel_iosf.c
index 01577cd..df1cdc0 100644
--- a/lib/intel_iosf.c
+++ b/lib/intel_iosf.c
@@ -73,7 +73,7 @@ static int vlv_sideband_rw(uint32_t port, uint8_t opcode, 
uint32_t addr,
  * Returns:
  * 0 when the register access succeeded, negative errno code on failure.
  */
-int intel_punit_read(uint8_t addr, uint32_t *val)
+int intel_punit_read(uint32_t addr, uint32_t *val)
 {
return vlv_sideband_rw(IOSF_PORT_PUNIT, SB_CRRDDA_NP, addr, val);
 }
@@ -88,7 +88,7 @@ int intel_punit_read(uint8_t addr, uint32_t *val)
  * Returns:
  * 0 when the register access succeeded, negative errno code on failure.
  */
-int intel_punit_write(uint8_t addr, uint32_t val)
+int intel_punit_write(uint32_t addr, uint32_t val)
 {
return vlv_sideband_rw(IOSF_PORT_PUNIT, SB_CRWRDA_NP, addr, val);
 }
@@ -103,7 +103,7 @@ int intel_punit_write(uint8_t addr, uint32_t val)
  * Returns:
  * 0 when the register access succeeded, negative errno code on failure.
  */
-int intel_nc_read(uint8_t addr, uint32_t *val)
+int intel_nc_read(uint32_t addr, uint32_t *val)
 {
return vlv_sideband_rw(IOSF_PORT_NC, SB_CRRDDA_NP, addr, val);
 }
@@ -118,7 +118,7 @@ int intel_nc_read(uint8_t addr, uint32_t *val)
  * Returns:
  * 0 when the register access succeeded, negative errno code on failure.
  */
-int intel_nc_write(uint8_t addr, uint32_t val)
+int intel_nc_write(uint32_t addr, uint32_t val)
 {
return vlv_sideband_rw(IOSF_PORT_NC, SB_CRWRDA_NP, addr, val);
 }
-- 
2.0.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/9] toos/intel_iosf_sb_*: Fix DPIO IOSF SB port number

2015-03-23 Thread ville . syrjala
From: Ville Syrjälä ville.syrj...@linux.intel.com

The correct port is 0x12, not 0x13 which is actually GPIO_NC.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 tools/intel_iosf_sb_read.c  | 2 +-
 tools/intel_iosf_sb_write.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/intel_iosf_sb_read.c b/tools/intel_iosf_sb_read.c
index 8f35e50..03bf007 100644
--- a/tools/intel_iosf_sb_read.c
+++ b/tools/intel_iosf_sb_read.c
@@ -55,7 +55,7 @@ int main(int argc, char *argv[])
else if (!strcasecmp(argv[1], nc))
port = 0x11;
else if (!strcasecmp(argv[1], dpio))
-   port = 0x13;
+   port = 0x12;
else if (!strcasecmp(argv[1], gpio_nc))
port = 0x13;
else if (!strcasecmp(argv[1], cck))
diff --git a/tools/intel_iosf_sb_write.c b/tools/intel_iosf_sb_write.c
index 8d06380..13c738f 100644
--- a/tools/intel_iosf_sb_write.c
+++ b/tools/intel_iosf_sb_write.c
@@ -54,7 +54,7 @@ int main(int argc, char** argv)
else if (!strcasecmp(argv[1], nc))
port = 0x11;
else if (!strcasecmp(argv[1], dpio))
-   port = 0x13;
+   port = 0x12;
else if (!strcasecmp(argv[1], gpio_nc))
port = 0x13;
else if (!strcasecmp(argv[1], cck))
-- 
2.0.5

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


[Intel-gfx] [PATCH i-g-t 6/9] tools/intel_iosf_sb_*: Use getopt() to parse the options

2015-03-23 Thread ville . syrjala
From: Ville Syrjälä ville.syrj...@linux.intel.com

I want to add some command line options so switch to getopt() to make
that easier.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 tools/intel_iosf_sb_read.c  | 45 ---
 tools/intel_iosf_sb_write.c | 51 -
 2 files changed, 78 insertions(+), 18 deletions(-)

diff --git a/tools/intel_iosf_sb_read.c b/tools/intel_iosf_sb_read.c
index 51b0d11..abe7fb5 100644
--- a/tools/intel_iosf_sb_read.c
+++ b/tools/intel_iosf_sb_read.c
@@ -70,30 +70,59 @@ static int iosf_sb_port_parse(const char *name)
 
 static void usage(const char *name)
 {
-   printf(Warning : This program will work only on Valleyview\n
-  Usage: %s port reg\n
-  \t port/reg : in 0x format\n,
-  name);
+   int i;
+
+   printf(Warning : This program will work only on 
Valleyview/Cherryview\n
+  Usage: %s [-h] [--] port reg\n
+  \t -h : Show this help text\n
+  \t port : , name);
+   for (i = 0; i  ARRAY_SIZE(iosf_sb_ports); i++)
+   printf(%s,, iosf_sb_ports[i].name);
+   printf( or in hex\n
+  \t reg : in hex\n);
 }
 
 int main(int argc, char *argv[])
 {
uint32_t port, reg, val;
struct pci_device *dev = intel_get_pci_device();
+   int i, nregs;
+   const char *name;
 
-   if (argc != 3 || !(IS_VALLEYVIEW(dev-device_id) || 
IS_CHERRYVIEW(dev-device_id))) {
+   if (!IS_VALLEYVIEW(dev-device_id) 
+   !IS_CHERRYVIEW(dev-device_id)) {
usage(argv[0]);
return 1;
}
 
-   port = iosf_sb_port_parse(argv[1]);
+   for (;;) {
+   int c = getopt(argc, argv, h);
+
+   if (c == -1)
+   break;
+
+   switch (c) {
+   case 'h':
+   usage(argv[0]);
+   return 0;
+   }
+   }
+
+   nregs = argc - optind;
+   if (nregs  1) {
+   usage(argv[0]);
+   return 2;
+   }
 
-   reg = strtoul(argv[2], NULL, 16);
+   i = optind;
+   name = argv[i++];
+   port = iosf_sb_port_parse(name);
 
intel_register_access_init(dev, 0);
 
+   reg = strtoul(argv[i], NULL, 16);
val = intel_iosf_sb_read(port, reg);
-   printf(0x%02x(%s)/0x%04x : 0x%08x\n, port, argv[1], reg, val);
+   printf(0x%02x(%s)/0x%04x : 0x%08x\n, port, name, reg, val);
 
intel_register_access_fini();
 
diff --git a/tools/intel_iosf_sb_write.c b/tools/intel_iosf_sb_write.c
index f6aa8f1..d0ba4d3 100644
--- a/tools/intel_iosf_sb_write.c
+++ b/tools/intel_iosf_sb_write.c
@@ -69,36 +69,67 @@ static int iosf_sb_port_parse(const char *name)
 
 static void usage(const char *name)
 {
-   printf(Warning : This program will work only on Valleyview\n
-  Usage: %s port reg val\n
-  \t port/reg/val : in 0x format\n,
-  name);
+   int i;
+
+   printf(Warning : This program will work only on 
Valleyview/Cherryview\n
+  Usage: %s [-h] [--] port reg val\n
+  \t -h : Show this help text\n
+  \t port : , name);
+   for (i = 0; i  ARRAY_SIZE(iosf_sb_ports); i++)
+   printf(%s,, iosf_sb_ports[i].name);
+   printf( or in hex\n
+  \t reg : in hex\n
+  \t val : in hex\n);
 }
 
 int main(int argc, char** argv)
 {
uint32_t port, reg, val, tmp;
struct pci_device *dev = intel_get_pci_device();
+   int i, nregs;
+   const char *name;
 
-   if (argc != 4 || !(IS_VALLEYVIEW(dev-device_id) || 
IS_CHERRYVIEW(dev-device_id))) {
+   if (!IS_VALLEYVIEW(dev-device_id) 
+   !IS_CHERRYVIEW(dev-device_id)) {
usage(argv[0]);
return 1;
}
 
-   port = iosf_sb_port_parse(argv[1]);
+   for (;;) {
+   int c = getopt(argc, argv, h);
+
+   if (c == -1)
+   break;
+
+   switch (c) {
+   case 'h':
+   usage(argv[0]);
+   return 0;
+   }
+   }
+
+   nregs = argc - optind;
+   if (nregs  2) {
+   usage(argv[0]);
+   return 2;
+   }
+
+   i = optind;
+   name = argv[i++];
+   port = iosf_sb_port_parse(name);
 
-   reg = strtoul(argv[2], NULL, 16);
-   val = strtoul(argv[3], NULL, 16);
+   reg = strtoul(argv[i], NULL, 16);
+   val = strtoul(argv[i+1], NULL, 16);
 
intel_register_access_init(dev, 0);
 
tmp = intel_iosf_sb_read(port, reg);
-   printf(0x%02x(%s)/0x%04x before : 0x%08x\n, port, argv[1], reg, tmp);
+   printf(0x%02x(%s)/0x%04x before : 0x%08x\n, port, name, reg, tmp);
 
intel_iosf_sb_write(port, reg, val);
 
tmp = intel_iosf_sb_read(port, reg);
-   

[Intel-gfx] [PATCH i-g-t 8/9] tools/intel_iosf_sb_read: Add -c command line option like intel_reg_read

2015-03-23 Thread ville . syrjala
From: Ville Syrjälä ville.syrj...@linux.intel.com

Add a command line option '-c count' that can be used to read set of
consecutive registers without having to specify the offset for each of
them.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 tools/intel_iosf_sb_read.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/tools/intel_iosf_sb_read.c b/tools/intel_iosf_sb_read.c
index 48a22be..2b0704a 100644
--- a/tools/intel_iosf_sb_read.c
+++ b/tools/intel_iosf_sb_read.c
@@ -73,8 +73,9 @@ static void usage(const char *name)
int i;
 
printf(Warning : This program will work only on 
Valleyview/Cherryview\n
-  Usage: %s [-h] [--] port reg [reg ...]\n
+  Usage: %s [-h] [-c count] [--] port reg [reg ...]\n
   \t -h : Show this help text\n
+  \t -c count : how many consecutive registers to read\n
   \t port : , name);
for (i = 0; i  ARRAY_SIZE(iosf_sb_ports); i++)
printf(%s,, iosf_sb_ports[i].name);
@@ -86,7 +87,7 @@ int main(int argc, char *argv[])
 {
uint32_t port, reg, val;
struct pci_device *dev = intel_get_pci_device();
-   int i, nregs;
+   int i, nregs, count = 1;
const char *name;
 
if (!IS_VALLEYVIEW(dev-device_id) 
@@ -105,6 +106,13 @@ int main(int argc, char *argv[])
case 'h':
usage(argv[0]);
return 0;
+   case 'c':
+   count = strtol(optarg, NULL, 0);
+   if (count  1) {
+   usage(argv[0]);
+   return 3;
+   }
+   break;
}
}
 
@@ -121,10 +129,15 @@ int main(int argc, char *argv[])
intel_register_access_init(dev, 0);
 
for (; i  argc; i++) {
+   int j;
+
reg = strtoul(argv[i], NULL, 16);
 
-   val = intel_iosf_sb_read(port, reg);
-   printf(0x%02x(%s)/0x%04x : 0x%08x\n, port, name, reg, val);
+   for (j = 0; j  count; j++) {
+   val = intel_iosf_sb_read(port, reg);
+   printf(0x%02x(%s)/0x%04x : 0x%08x\n, port, name, reg, 
val);
+   reg += 4;
+   }
}
 
intel_register_access_fini();
-- 
2.0.5

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


[Intel-gfx] [PATCH i-g-t 1/9] lib: Change IOSF SB devfn to 0.0

2015-03-23 Thread ville . syrjala
From: Ville Syrjälä ville.syrj...@linux.intel.com

The devfn field in the IOSF SB messages is only relevant when there's a
real PCI bus or some other multifunction device behind a single port.
Otherwise the port number itself is enough to uniquely identify the
target. In fact some IOSF SB targets reject the access when devfn is not
0.0 (eg. GPIO_NC on BYT).

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 lib/intel_iosf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/intel_iosf.c b/lib/intel_iosf.c
index 27134a0..01577cd 100644
--- a/lib/intel_iosf.c
+++ b/lib/intel_iosf.c
@@ -28,7 +28,7 @@ static int vlv_sideband_rw(uint32_t port, uint8_t opcode, 
uint32_t addr,
 
bar = 0;
be = 0xf;
-   devfn = 16;
+   devfn = 0;
 
cmd = (devfn  IOSF_DEVFN_SHIFT) | (opcode  IOSF_OPCODE_SHIFT) |
(port  IOSF_PORT_SHIFT) | (be  IOSF_BYTE_ENABLES_SHIFT) |
-- 
2.0.5

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


[Intel-gfx] [PATCH v2] drm/i915: Compare GGTT view structs instead of types

2015-03-23 Thread Joonas Lahtinen
Preparatory code to decrease amount of conflicts between rotated and
partial views code.

To allow for views where the view type is not defined by the view type only,
like it is in stereo or rotated 90 degree view, change the semantic to require
the whole view structure for comparison. This allows including parameters like
offset to be included in the view which is useful for eg. partial views.

Signed-off-by: Joonas Lahtinen joonas.lahti...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_drv.h |  8 
 drivers/gpu/drm/i915/i915_gem.c | 26 ++
 drivers/gpu/drm/i915/i915_gem_gtt.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_gtt.h |  7 +++
 4 files changed, 26 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index eb38cd1..712f55e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2791,19 +2791,19 @@ void i915_gem_restore_fences(struct drm_device *dev);
 
 unsigned long
 i915_gem_obj_ggtt_offset_view(struct drm_i915_gem_object *o,
- enum i915_ggtt_view_type view);
+ const struct i915_ggtt_view *view);
 unsigned long
 i915_gem_obj_offset(struct drm_i915_gem_object *o,
struct i915_address_space *vm);
 static inline unsigned long
 i915_gem_obj_ggtt_offset(struct drm_i915_gem_object *o)
 {
-   return i915_gem_obj_ggtt_offset_view(o, I915_GGTT_VIEW_NORMAL);
+   return i915_gem_obj_ggtt_offset_view(o, i915_ggtt_view_normal);
 }
 
 bool i915_gem_obj_bound_any(struct drm_i915_gem_object *o);
 bool i915_gem_obj_ggtt_bound_view(struct drm_i915_gem_object *o,
- enum i915_ggtt_view_type view);
+ const struct i915_ggtt_view *view);
 bool i915_gem_obj_bound(struct drm_i915_gem_object *o,
struct i915_address_space *vm);
 
@@ -2851,7 +2851,7 @@ i915_vm_to_ppgtt(struct i915_address_space *vm)
 
 static inline bool i915_gem_obj_ggtt_bound(struct drm_i915_gem_object *obj)
 {
-   return i915_gem_obj_ggtt_bound_view(obj, I915_GGTT_VIEW_NORMAL);
+   return i915_gem_obj_ggtt_bound_view(obj, i915_ggtt_view_normal);
 }
 
 static inline unsigned long
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 84e2a23..34aa7c0 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2978,7 +2978,7 @@ int i915_vma_unbind(struct i915_vma *vma)
 */
 
if (i915_is_ggtt(vma-vm) 
-   vma-ggtt_view.type == I915_GGTT_VIEW_NORMAL) {
+   i915_ggtt_view_equal(vma-ggtt_view, i915_ggtt_view_normal)) {
i915_gem_object_finish_gtt(obj);
 
/* release the fence reg _after_ flushing */
@@ -4122,7 +4122,7 @@ i915_gem_object_do_pin(struct drm_i915_gem_object *obj,
 
if (i915_vma_misplaced(vma, alignment, flags)) {
unsigned long offset;
-   offset = ggtt_view ? i915_gem_obj_ggtt_offset_view(obj, 
ggtt_view-type) :
+   offset = ggtt_view ? i915_gem_obj_ggtt_offset_view(obj, 
ggtt_view) :
 i915_gem_obj_offset(obj, vm);
WARN(vma-pin_count,
 bo is already pinned in %s with incorrect 
alignment:
@@ -4524,7 +4524,7 @@ struct i915_vma *i915_gem_obj_to_vma(struct 
drm_i915_gem_object *obj,
struct i915_vma *vma;
list_for_each_entry(vma, obj-vma_list, vma_link) {
if (i915_is_ggtt(vma-vm) 
-   vma-ggtt_view.type != I915_GGTT_VIEW_NORMAL)
+   !i915_ggtt_view_equal(vma-ggtt_view, 
i915_ggtt_view_normal))
continue;
if (vma-vm == vm)
return vma;
@@ -4542,7 +4542,8 @@ struct i915_vma *i915_gem_obj_to_ggtt_view(struct 
drm_i915_gem_object *obj,
return ERR_PTR(-EINVAL);
 
list_for_each_entry(vma, obj-vma_list, vma_link)
-   if (vma-vm == ggtt  vma-ggtt_view.type == view-type)
+   if (vma-vm == ggtt 
+   i915_ggtt_view_equal(vma-ggtt_view, view))
return vma;
return NULL;
 }
@@ -5086,7 +5087,7 @@ i915_gem_obj_offset(struct drm_i915_gem_object *o,
 
list_for_each_entry(vma, o-vma_list, vma_link) {
if (i915_is_ggtt(vma-vm) 
-   vma-ggtt_view.type != I915_GGTT_VIEW_NORMAL)
+   !i915_ggtt_view_equal(vma-ggtt_view, 
i915_ggtt_view_normal))
continue;
if (vma-vm == vm)
return vma-node.start;
@@ -5099,13 +5100,14 @@ i915_gem_obj_offset(struct drm_i915_gem_object *o,
 
 unsigned long
 i915_gem_obj_ggtt_offset_view(struct drm_i915_gem_object *o,
- enum i915_ggtt_view_type view)
+ const struct 

Re: [Intel-gfx] [PATCH v2] drm/i915: Compare GGTT view structs instead of types

2015-03-23 Thread Tvrtko Ursulin


On 03/23/2015 12:51 PM, Joonas Lahtinen wrote:

Preparatory code to decrease amount of conflicts between rotated and
partial views code.

To allow for views where the view type is not defined by the view type only,
like it is in stereo or rotated 90 degree view, change the semantic to require
the whole view structure for comparison. This allows including parameters like
offset to be included in the view which is useful for eg. partial views.

Signed-off-by: Joonas Lahtinen joonas.lahti...@linux.intel.com
---
  drivers/gpu/drm/i915/i915_drv.h |  8 
  drivers/gpu/drm/i915/i915_gem.c | 26 ++
  drivers/gpu/drm/i915/i915_gem_gtt.c |  2 +-
  drivers/gpu/drm/i915/i915_gem_gtt.h |  7 +++
  4 files changed, 26 insertions(+), 17 deletions(-)


No objections for this version! :)

Reviewed-by: Tvrtko Ursulin tvrtko.ursu...@intel.com

Regards,

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


Re: [Intel-gfx] [PATCH 5/7] drm/i915/skl: Support secondary (rotated) frame buffer mapping

2015-03-23 Thread Joonas Lahtinen
On ma, 2015-03-23 at 11:10 +, Tvrtko Ursulin wrote:
 From: Tvrtko Ursulin tvrtko.ursu...@intel.com
 
 90/270 rotated scanout needs a rotated GTT view of the framebuffer.
 
 This is put in a separate VMA with a dedicated ggtt view and wired such that
 it is created when a framebuffer is pinned to a 90/270 rotated plane.
 
 Rotation is only possible with Yb/Yf buffers and error is propagated to
 user space in case of a mismatch.
 
 Special rotated page view is constructed at the VMA creation time by
 borrowing the DMA addresses from obj-pages.
 
 v2:
 * Do not bother with pages for rotated sg list, just populate the DMA
   addresses. (Daniel Vetter)
 * Checkpatch cleanup.
 
 v3:
 * Rebased on top of new plane handling (create rotated mapping when
   setting the rotation property).
 * Unpin rotated VMA on unpinning from display plane.
 * Simplify rotation check using bitwise AND. (Chris Wilson)
 
 v4:
 * Fix unpinning of optional rotated mapping so it is really considered
   to be optional.
 
 v5:
* Rebased for fb modifier changes.
* Rebased for atomic commit.
* Only pin needed view for display. (Ville Syrjälä, Daniel Vetter)
 
 v6:
* Rebased after preparatory work has been extracted out. (Daniel Vetter)
 
 v7:
* Slightly simplified tiling geometry calculation.
* Moved rotated GGTT view implementation into i915_gem_gtt.c (Daniel 
 Vetter)
 
 v8:
* Do not use i915_gem_obj_size to get object size since that actually
  returns the size of an VMA which may not exist.
* Rebased for ggtt view changes.
 
 v9:
* Rebased after code review changes on the preceding patches.
* Tidy function definitions. (Joonas Lahtinen)
 
 For: VIZ-4726
 Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
 Reviewed-by: Michel Thierry michel.thie...@intel.com (v4)

Reviewed-by: Joonas Lahtinen joonas.lahti...@linux.intel.com (v9)

 ---
  drivers/gpu/drm/i915/i915_gem.c  |   4 +-
  drivers/gpu/drm/i915/i915_gem_gtt.c  | 117 
 +--
  drivers/gpu/drm/i915/i915_gem_gtt.h  |  12 
  drivers/gpu/drm/i915/intel_display.c |  27 +++-
  drivers/gpu/drm/i915/intel_drv.h |   4 ++
  5 files changed, 158 insertions(+), 6 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
 index 73b2638..b6d4b07 100644
 --- a/drivers/gpu/drm/i915/i915_gem.c
 +++ b/drivers/gpu/drm/i915/i915_gem.c
 @@ -3908,7 +3908,9 @@ i915_gem_object_pin_to_display_plane(struct 
 drm_i915_gem_object *obj,
* (e.g. libkms for the bootup splash), we have to ensure that we
* always use map_and_fenceable for all scanout buffers.
*/
 - ret = i915_gem_object_ggtt_pin(obj, view, alignment, PIN_MAPPABLE);
 + ret = i915_gem_object_ggtt_pin(obj, view, alignment,
 +view-type == I915_GGTT_VIEW_NORMAL ?
 +PIN_MAPPABLE : 0);
   if (ret)
   goto err_unpin_display;
  
 diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
 b/drivers/gpu/drm/i915/i915_gem_gtt.c
 index 645c363..fc56c11 100644
 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
 +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
 @@ -2500,15 +2500,119 @@ i915_gem_obj_lookup_or_create_ggtt_vma(struct 
 drm_i915_gem_object *obj,
  
  }
  
 +static void
 +rotate_pages(dma_addr_t *in, unsigned int width, unsigned int height,
 +  struct sg_table *st)
 +{
 + unsigned int column, row;
 + unsigned int src_idx;
 + struct scatterlist *sg = st-sgl;
 +
 + st-nents = 0;
 +
 + for (column = 0; column  width; column++) {
 + src_idx = width * (height - 1) + column;
 + for (row = 0; row  height; row++) {
 + st-nents++;
 + /* We don't need the pages, but need to initialize
 +  * the entries so the sg list can be happily traversed.
 +  * The only thing we need are DMA addresses.
 +  */
 + sg_set_page(sg, NULL, PAGE_SIZE, 0);
 + sg_dma_address(sg) = in[src_idx];
 + sg_dma_len(sg) = PAGE_SIZE;
 + sg = sg_next(sg);
 + src_idx -= width;
 + }
 + }
 +}
 +
 +static struct sg_table *
 +intel_rotate_fb_obj_pages(struct i915_ggtt_view *ggtt_view,
 +   struct drm_i915_gem_object *obj)
 +{
 + struct drm_device *dev = obj-base.dev;
 + struct intel_rotation_info *rot_info = ggtt_view-rotation_info;
 + unsigned long size, pages, rot_pages;
 + struct sg_page_iter sg_iter;
 + unsigned long i;
 + dma_addr_t *page_addr_list;
 + struct sg_table *st;
 + unsigned int tile_pitch, tile_height;
 + unsigned int width_pages, height_pages;
 + int ret = ENOMEM;
 +
 + pages = obj-base.size / PAGE_SIZE;
 +
 + /* Calculate tiling geometry. */
 + tile_height = intel_tile_height(dev, 

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Use GGTT view when (un)pinning objects to planes

2015-03-23 Thread Joonas Lahtinen
On ma, 2015-03-23 at 11:10 +, Tvrtko Ursulin wrote:
 From: Tvrtko Ursulin tvrtko.ursu...@intel.com
 
 To support frame buffer rotation we need to be able to pass on the information
 on what kind of GGTT view is required for display.
 
 This patch just adds the parameter and makes all the callers default to the
 normal view.
 
 v2: Rebased for ggtt view changes.
 v3: Don't limit PIN_MAPPABLE to normal views just yet. (Joonas Lahtinen)
 
 Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Reviewed-by: Joonas Lahtinen joonas.lahti...@linux.intel.com (v3)
 ---
  drivers/gpu/drm/i915/i915_drv.h  | 14 +++---
  drivers/gpu/drm/i915/i915_gem.c  | 20 
  drivers/gpu/drm/i915/intel_display.c |  7 ---
  drivers/gpu/drm/i915/intel_overlay.c |  3 ++-
  4 files changed, 29 insertions(+), 15 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index eb38cd1..e7ed5b3 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -2765,8 +2765,10 @@ i915_gem_object_set_to_cpu_domain(struct 
 drm_i915_gem_object *obj, bool write);
  int __must_check
  i915_gem_object_pin_to_display_plane(struct drm_i915_gem_object *obj,
u32 alignment,
 -  struct intel_engine_cs *pipelined);
 -void i915_gem_object_unpin_from_display_plane(struct drm_i915_gem_object 
 *obj);
 +  struct intel_engine_cs *pipelined,
 +  const struct i915_ggtt_view *view);
 +void i915_gem_object_unpin_from_display_plane(struct drm_i915_gem_object 
 *obj,
 +   const struct i915_ggtt_view 
 *view);
  int i915_gem_object_attach_phys(struct drm_i915_gem_object *obj,
   int align);
  int i915_gem_open(struct drm_device *dev, struct drm_file *file);
 @@ -2875,7 +2877,13 @@ i915_gem_object_ggtt_unbind(struct drm_i915_gem_object 
 *obj)
   return i915_vma_unbind(i915_gem_obj_to_ggtt(obj));
  }
  
 -void i915_gem_object_ggtt_unpin(struct drm_i915_gem_object *obj);
 +void i915_gem_object_ggtt_unpin_view(struct drm_i915_gem_object *obj,
 +  const struct i915_ggtt_view *view);
 +static inline void
 +i915_gem_object_ggtt_unpin(struct drm_i915_gem_object *obj)
 +{
 + i915_gem_object_ggtt_unpin_view(obj, i915_ggtt_view_normal);
 +}
  
  /* i915_gem_context.c */
  int __must_check i915_gem_context_init(struct drm_device *dev);
 diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
 index 84e2a23..73b2638 100644
 --- a/drivers/gpu/drm/i915/i915_gem.c
 +++ b/drivers/gpu/drm/i915/i915_gem.c
 @@ -3871,7 +3871,8 @@ static bool is_pin_display(struct drm_i915_gem_object 
 *obj)
  int
  i915_gem_object_pin_to_display_plane(struct drm_i915_gem_object *obj,
u32 alignment,
 -  struct intel_engine_cs *pipelined)
 +  struct intel_engine_cs *pipelined,
 +  const struct i915_ggtt_view *view)
  {
   u32 old_read_domains, old_write_domain;
   bool was_pin_display;
 @@ -3907,7 +3908,7 @@ i915_gem_object_pin_to_display_plane(struct 
 drm_i915_gem_object *obj,
* (e.g. libkms for the bootup splash), we have to ensure that we
* always use map_and_fenceable for all scanout buffers.
*/
 - ret = i915_gem_obj_ggtt_pin(obj, alignment, PIN_MAPPABLE);
 + ret = i915_gem_object_ggtt_pin(obj, view, alignment, PIN_MAPPABLE);
   if (ret)
   goto err_unpin_display;
  
 @@ -3935,9 +3936,11 @@ err_unpin_display:
  }
  
  void
 -i915_gem_object_unpin_from_display_plane(struct drm_i915_gem_object *obj)
 +i915_gem_object_unpin_from_display_plane(struct drm_i915_gem_object *obj,
 +  const struct i915_ggtt_view *view)
  {
 - i915_gem_object_ggtt_unpin(obj);
 + i915_gem_object_ggtt_unpin_view(obj, view);
 +
   obj-pin_display = is_pin_display(obj);
  }
  
 @@ -4214,15 +4217,16 @@ i915_gem_object_ggtt_pin(struct drm_i915_gem_object 
 *obj,
  }
  
  void
 -i915_gem_object_ggtt_unpin(struct drm_i915_gem_object *obj)
 +i915_gem_object_ggtt_unpin_view(struct drm_i915_gem_object *obj,
 + const struct i915_ggtt_view *view)
  {
 - struct i915_vma *vma = i915_gem_obj_to_ggtt(obj);
 + struct i915_vma *vma = i915_gem_obj_to_ggtt_view(obj, view);
  
   BUG_ON(!vma);
   BUG_ON(vma-pin_count == 0);
 - BUG_ON(!i915_gem_obj_ggtt_bound(obj));
 + BUG_ON(!i915_gem_obj_ggtt_bound_view(obj, view-type));
  
 - if (--vma-pin_count == 0)
 + if (--vma-pin_count == 0  view-type == I915_GGTT_VIEW_NORMAL)
   obj-pin_mappable = false;
  }
  
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 3b9ce89..39380f4 100644
 --- 

[Intel-gfx] [PATCH i-g-t 2/2] tools/intel_watermark: Tool to decode watermark registers

2015-03-23 Thread ville . syrjala
From: Ville Syrjälä ville.syrj...@linux.intel.com

The watermark registers on the gmch platform are a bit of a mess. Add
a tool to make some sense of them. While at it decode the ilk-bdw wm
registers as well. SKL+ is left out for now since it's a very different
beast.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 tools/Makefile.sources  |   3 +-
 tools/intel_watermark.c | 898 
 2 files changed, 900 insertions(+), 1 deletion(-)
 create mode 100644 tools/intel_watermark.c

diff --git a/tools/Makefile.sources b/tools/Makefile.sources
index 44b9e9c..6ca1228 100644
--- a/tools/Makefile.sources
+++ b/tools/Makefile.sources
@@ -32,7 +32,8 @@ bin_PROGRAMS =\
intel_reg_write \
intel_stepping  \
intel_vga_read  \
-   intel_vga_write
+   intel_vga_write \
+   intel_watermark
 
 dist_bin_SCRIPTS = intel_gpu_abrt
 
diff --git a/tools/intel_watermark.c b/tools/intel_watermark.c
new file mode 100644
index 000..e5dee46
--- /dev/null
+++ b/tools/intel_watermark.c
@@ -0,0 +1,898 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+#include unistd.h
+#include stdlib.h
+#include stdio.h
+#include stdbool.h
+#include err.h
+#include string.h
+#include intel_io.h
+#include intel_chipset.h
+
+static uint32_t display_base;
+static uint32_t devid;
+
+#define ARRAY_SIZE(a) (sizeof(a)/sizeof((a)[0]))
+
+static uint32_t read_reg(uint32_t addr)
+{
+   return *(volatile uint32_t *)((volatile char*)mmio + display_base + 
addr);
+}
+
+struct gmch_wm {
+   int wm, wm1, dl, fifo, fbc, burst;
+   bool dl_prec, valid;
+};
+
+enum plane {
+   PRI_HPLL_SR,
+   CUR_HPLL_SR,
+   PRI_SR,
+   CUR_SR,
+   PRI_A,
+   CUR_A,
+   SPR_A,
+   SPR_B,
+   PRI_B,
+   CUR_B,
+   SPR_C,
+   SPR_D,
+   PRI_C,
+   CUR_C,
+   SPR_E,
+   SPR_F,
+   MAX_PLANE,
+};
+
+#define NAME(x) [x] = #x
+
+static const char * const plane_name[] = {
+   NAME(PRI_HPLL_SR),
+   NAME(CUR_HPLL_SR),
+   NAME(PRI_SR),
+   NAME(CUR_SR),
+   NAME(PRI_A),
+   NAME(CUR_A),
+   NAME(SPR_A),
+   NAME(SPR_B),
+   NAME(PRI_B),
+   NAME(CUR_B),
+   NAME(SPR_C),
+   NAME(SPR_D),
+   NAME(PRI_C),
+   NAME(CUR_C),
+   NAME(SPR_E),
+   NAME(SPR_F),
+};
+
+struct ilk_wm_level {
+   int primary, sprite, cursor, latency, fbc;
+   bool enabled, sprite_enabled;
+   bool primary_trickle_feed_dis, sprite_trickle_feed_dis;
+};
+
+struct ilk_wm {
+   struct ilk_wm_level pipe[3];
+   struct ilk_wm_level lp[3];
+};
+
+#define MASK(size) ((1  (size)) - 1)
+
+#define REG_DECODE1(x, shift, size) \
+   (((x)  (shift))  MASK(size))
+
+#define REG_DECODE2(lo, shift_lo, size_lo, hi, shift_hi, size_hi) \
+   lo)  (shift_lo))  MASK(size_lo)) | \
+hi)  (shift_hi))  MASK(size_hi))  (size_lo)))
+
+static const char pipe_name(int pipe)
+{
+   return 'A' + pipe;
+}
+
+static const char *endis(bool enabled)
+{
+   return enabled ? enabled : disabled;
+}
+
+static int is_gen7_plus(uint32_t d)
+{
+   return !(IS_GEN5(d) || IS_GEN6(d));
+}
+
+static int is_hsw_plus(uint32_t d)
+{
+   return !(IS_GEN5(d) || IS_GEN6(d) || IS_IVYBRIDGE(d));
+}
+
+static void ilk_wm_dump(void)
+{
+   int i;
+   uint32_t dspcntr[3];
+   uint32_t spcntr[3];
+   uint32_t wm_pipe[3];
+   uint32_t wm_lp[3];
+   uint32_t wm_lp_spr[3];
+   uint32_t arb_ctl, arb_ctl2, wm_misc = 0;
+   int num_pipes = is_gen7_plus(devid) ? 3 : 2;
+   struct ilk_wm wm = {};
+
+   intel_register_access_init(intel_get_pci_device(), 0);
+
+   for (i = 0; i  num_pipes; i++) {
+   dspcntr[i] = read_reg(0x70180 + 

[Intel-gfx] [PATCH i-g-t 9/9] tools/intel_iosf_sb_read: Support different register strides

2015-03-23 Thread ville . syrjala
From: Ville Syrjälä ville.syrj...@linux.intel.com

Some IOSF SB units ogranize their registers in a pecualiar way. Even
though the registers are 32 bits wide, the register offsets only
increment by one when going from one register to the next. Correctly
deal with this when dumping several consecutive registers.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 tools/intel_iosf_sb_read.c | 32 ++--
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/tools/intel_iosf_sb_read.c b/tools/intel_iosf_sb_read.c
index 2b0704a..f188cda 100644
--- a/tools/intel_iosf_sb_read.c
+++ b/tools/intel_iosf_sb_read.c
@@ -35,16 +35,17 @@
 static const struct iosf_sb_port {
const char *name;
uint8_t port;
+   uint8_t reg_stride;
 } iosf_sb_ports[] = {
-   { bunit,   0x03, },
-   { cck, 0x14, },
-   { ccu, 0xa9, },
-   { dpio,0x12, },
-   { dpio2,   0x1a, },
-   { flisdsi, 0x1b, },
-   { gpio_nc, 0x13, },
-   { nc,  0x11, },
-   { punit,   0x04, },
+   { bunit,   0x03, 1, },
+   { cck, 0x14, 1, },
+   { ccu, 0xa9, 4, },
+   { dpio,0x12, 4, },
+   { dpio2,   0x1a, 4, },
+   { flisdsi, 0x1b, 1, },
+   { gpio_nc, 0x13, 4, },
+   { nc,  0x11, 4, },
+   { punit,   0x04, 1, },
 };
 
 static int iosf_sb_port_compare(const void *a, const void *b)
@@ -55,16 +56,19 @@ static int iosf_sb_port_compare(const void *a, const void 
*b)
return strcasecmp(name, p-name);
 }
 
-static int iosf_sb_port_parse(const char *name)
+static int iosf_sb_port_parse(const char *name, int *reg_stride)
 {
const struct iosf_sb_port *p;
 
p = bsearch(name, iosf_sb_ports, ARRAY_SIZE(iosf_sb_ports),
sizeof(iosf_sb_ports[0]),
iosf_sb_port_compare);
-   if (p)
+   if (p) {
+   *reg_stride = p-reg_stride;
return p-port;
+   }
 
+   *reg_stride = 4;
return strtoul(name, NULL, 16);
 }
 
@@ -87,7 +91,7 @@ int main(int argc, char *argv[])
 {
uint32_t port, reg, val;
struct pci_device *dev = intel_get_pci_device();
-   int i, nregs, count = 1;
+   int i, nregs, count = 1, reg_stride;
const char *name;
 
if (!IS_VALLEYVIEW(dev-device_id) 
@@ -124,7 +128,7 @@ int main(int argc, char *argv[])
 
i = optind;
name = argv[i++];
-   port = iosf_sb_port_parse(name);
+   port = iosf_sb_port_parse(name, reg_stride);
 
intel_register_access_init(dev, 0);
 
@@ -136,7 +140,7 @@ int main(int argc, char *argv[])
for (j = 0; j  count; j++) {
val = intel_iosf_sb_read(port, reg);
printf(0x%02x(%s)/0x%04x : 0x%08x\n, port, name, reg, 
val);
-   reg += 4;
+   reg += reg_stride;
}
}
 
-- 
2.0.5

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


[Intel-gfx] [PATCH i-g-t 5/9] tools/intel_iosf_sb_*: Replace if ladder with an array and bsearch()

2015-03-23 Thread ville . syrjala
From: Ville Syrjälä ville.syrj...@linux.intel.com

Replace the silly strcasecmp() if ladder with and array that maps the
unit names to port numbers. And keep the thing sorted so we can do
the lookup with bsearch() for extra speed :)

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 tools/intel_iosf_sb_read.c  | 59 ++---
 tools/intel_iosf_sb_write.c | 59 ++---
 2 files changed, 78 insertions(+), 40 deletions(-)

diff --git a/tools/intel_iosf_sb_read.c b/tools/intel_iosf_sb_read.c
index 03bf007..51b0d11 100644
--- a/tools/intel_iosf_sb_read.c
+++ b/tools/intel_iosf_sb_read.c
@@ -29,6 +29,44 @@
 #include string.h
 #include intel_io.h
 #include intel_chipset.h
+#include drmtest.h
+
+/* keep sorted by name for bsearch() */
+static const struct iosf_sb_port {
+   const char *name;
+   uint8_t port;
+} iosf_sb_ports[] = {
+   { bunit,   0x03, },
+   { cck, 0x14, },
+   { ccu, 0xa9, },
+   { dpio,0x12, },
+   { dpio2,   0x1a, },
+   { flisdsi, 0x1b, },
+   { gpio_nc, 0x13, },
+   { nc,  0x11, },
+   { punit,   0x04, },
+};
+
+static int iosf_sb_port_compare(const void *a, const void *b)
+{
+   const char *name = a;
+   const struct iosf_sb_port *p = b;
+
+   return strcasecmp(name, p-name);
+}
+
+static int iosf_sb_port_parse(const char *name)
+{
+   const struct iosf_sb_port *p;
+
+   p = bsearch(name, iosf_sb_ports, ARRAY_SIZE(iosf_sb_ports),
+   sizeof(iosf_sb_ports[0]),
+   iosf_sb_port_compare);
+   if (p)
+   return p-port;
+
+   return strtoul(name, NULL, 16);
+}
 
 static void usage(const char *name)
 {
@@ -48,26 +86,7 @@ int main(int argc, char *argv[])
return 1;
}
 
-   if (!strcasecmp(argv[1], bunit))
-   port = 0x03;
-   else if (!strcasecmp(argv[1], punit))
-   port = 0x04;
-   else if (!strcasecmp(argv[1], nc))
-   port = 0x11;
-   else if (!strcasecmp(argv[1], dpio))
-   port = 0x12;
-   else if (!strcasecmp(argv[1], gpio_nc))
-   port = 0x13;
-   else if (!strcasecmp(argv[1], cck))
-   port = 0x14;
-   else if (!strcasecmp(argv[1], ccu))
-   port = 0xa9;
-   else if (!strcasecmp(argv[1], dpio2))
-   port = 0x1a;
-   else if (!strcasecmp(argv[1], flisdsi))
-   port = 0x1b;
-   else
-   port = strtoul(argv[1], NULL, 16);
+   port = iosf_sb_port_parse(argv[1]);
 
reg = strtoul(argv[2], NULL, 16);
 
diff --git a/tools/intel_iosf_sb_write.c b/tools/intel_iosf_sb_write.c
index 13c738f..f6aa8f1 100644
--- a/tools/intel_iosf_sb_write.c
+++ b/tools/intel_iosf_sb_write.c
@@ -28,6 +28,44 @@
 #include string.h
 #include intel_io.h
 #include intel_chipset.h
+#include drmtest.h
+
+/* keep sorted by name for bsearch() */
+static const struct iosf_sb_port {
+   const char *name;
+   uint8_t port;
+} iosf_sb_ports[] = {
+   { bunit,   0x03, },
+   { cck, 0x14, },
+   { ccu, 0xa9, },
+   { dpio,0x12, },
+   { dpio2,   0x1a, },
+   { flisdsi, 0x1b, },
+   { gpio_nc, 0x13, },
+   { nc,  0x11, },
+   { punit,   0x04, },
+};
+
+static int iosf_sb_port_compare(const void *a, const void *b)
+{
+   const char *name = a;
+   const struct iosf_sb_port *p = b;
+
+   return strcasecmp(name, p-name);
+}
+
+static int iosf_sb_port_parse(const char *name)
+{
+   const struct iosf_sb_port *p;
+
+   p = bsearch(name, iosf_sb_ports, ARRAY_SIZE(iosf_sb_ports),
+   sizeof(iosf_sb_ports[0]),
+   iosf_sb_port_compare);
+   if (p)
+   return p-port;
+
+   return strtoul(name, NULL, 16);
+}
 
 static void usage(const char *name)
 {
@@ -47,26 +85,7 @@ int main(int argc, char** argv)
return 1;
}
 
-   if (!strcasecmp(argv[1], bunit))
-   port = 0x03;
-   else if (!strcasecmp(argv[1], punit))
-   port = 0x04;
-   else if (!strcasecmp(argv[1], nc))
-   port = 0x11;
-   else if (!strcasecmp(argv[1], dpio))
-   port = 0x12;
-   else if (!strcasecmp(argv[1], gpio_nc))
-   port = 0x13;
-   else if (!strcasecmp(argv[1], cck))
-   port = 0x14;
-   else if (!strcasecmp(argv[1], ccu))
-   port = 0xa9;
-   else if (!strcasecmp(argv[1], dpio2))
-   port = 0x1a;
-   else if (!strcasecmp(argv[1], flisdsi))
-   port = 0x1b;
-   else
-   port = strtoul(argv[1], NULL, 16);
+   port = iosf_sb_port_parse(argv[1]);
 
reg = strtoul(argv[2], NULL, 16);
val = strtoul(argv[3], NULL, 16);
-- 
2.0.5

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

[Intel-gfx] [PATCH i-g-t 4/9] tools: Remove intel_dpio_{read, write} tools

2015-03-23 Thread ville . syrjala
From: Ville Syrjälä ville.syrj...@linux.intel.com

intel_dpio_{read,write} as redundant as intel_iosf_sb_{read,write}
handle the same task.

The difference between the tools was the opcode used to read/write the
registers, but with DPIO both opcodes work just fine, so there's no need
for both sets of tools.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 tools/Makefile.sources   |  2 --
 tools/intel_dpio_read.c  | 69 ---
 tools/intel_dpio_write.c | 70 
 3 files changed, 141 deletions(-)
 delete mode 100644 tools/intel_dpio_read.c
 delete mode 100644 tools/intel_dpio_write.c

diff --git a/tools/Makefile.sources b/tools/Makefile.sources
index b16af8a..44b9e9c 100644
--- a/tools/Makefile.sources
+++ b/tools/Makefile.sources
@@ -9,8 +9,6 @@ bin_PROGRAMS =  \
intel_bios_dumper   \
intel_bios_reader   \
intel_display_poller\
-   intel_dpio_read \
-   intel_dpio_write\
intel_dump_decode   \
intel_error_decode  \
intel_forcewaked\
diff --git a/tools/intel_dpio_read.c b/tools/intel_dpio_read.c
deleted file mode 100644
index 20561d2..000
--- a/tools/intel_dpio_read.c
+++ /dev/null
@@ -1,69 +0,0 @@
-/*
- * Copyright © 2012 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:
- * Vijay Purushothaman vijay.a.purushotha...@intel.com
- *
- */
-
-#include unistd.h
-#include stdlib.h
-#include stdio.h
-#include err.h
-#include string.h
-#include intel_io.h
-#include intel_chipset.h
-
-static void usage(char *cmdname)
-{
-   printf(Warning : This program will work only on Valleyview\n);
-   printf(Usage: %s [addr]\n, cmdname);
-   printf(\t addr : in 0x format\n);
-}
-
-int main(int argc, char** argv)
-{
-   int ret = 0;
-   uint32_t reg, val;
-   char *cmdname = strdup(argv[0]);
-   struct pci_device *dev = intel_get_pci_device();
-
-   if (argc != 2 || !(IS_VALLEYVIEW(dev-device_id) || 
IS_CHERRYVIEW(dev-device_id))) {
-   usage(cmdname);
-   ret = 1;
-   goto out;
-   }
-
-   sscanf(argv[1], 0x%x, reg);
-
-   intel_register_access_init(dev, 0);
-
-   val = intel_dpio_reg_read(reg, 0);
-
-   printf(0x%04x : 0x%08x\n, reg, val);
-
-   intel_register_access_fini();
-
-out:
-   free(cmdname);
-   return ret;
-}
diff --git a/tools/intel_dpio_write.c b/tools/intel_dpio_write.c
deleted file mode 100644
index 45cc95f..000
--- a/tools/intel_dpio_write.c
+++ /dev/null
@@ -1,70 +0,0 @@
-/*
- * Copyright © 2012 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.
- 

[Intel-gfx] [PATCH i-g-t 1/2] lib: Add i854 PCI ID

2015-03-23 Thread ville . syrjala
From: Ville Syrjälä ville.syrj...@linux.intel.com

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 lib/intel_chipset.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/intel_chipset.h b/lib/intel_chipset.h
index e3ce603..bd1b9ed 100644
--- a/lib/intel_chipset.h
+++ b/lib/intel_chipset.h
@@ -59,6 +59,7 @@ void intel_check_pch(void);
 
 #define PCI_CHIP_I830_M0x3577
 #define PCI_CHIP_845_G 0x2562
+#define PCI_CHIP_I854_G0x358e
 #define PCI_CHIP_I855_GM   0x3582
 #define PCI_CHIP_I865_G0x2572
 
@@ -245,6 +246,7 @@ void intel_check_pch(void);
 
 #define IS_GEN2(devid) ((devid) == PCI_CHIP_I830_M || \
 (devid) == PCI_CHIP_845_G || \
+(devid) == PCI_CHIP_I854_G || \
 (devid) == PCI_CHIP_I855_GM || \
 (devid) == PCI_CHIP_I865_G)
 
-- 
2.0.5

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


[Intel-gfx] [PATCH i-g-t 7/9] tools/intel_iosf_sb_*: Support reading/writing multiple registers at once

2015-03-23 Thread ville . syrjala
From: Ville Syrjälä ville.syrj...@linux.intel.com

Allow the user to specify a list of registers to read, and register/value
pairs to write.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 tools/intel_iosf_sb_read.c  | 13 -
 tools/intel_iosf_sb_write.c | 20 ++--
 2 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/tools/intel_iosf_sb_read.c b/tools/intel_iosf_sb_read.c
index abe7fb5..48a22be 100644
--- a/tools/intel_iosf_sb_read.c
+++ b/tools/intel_iosf_sb_read.c
@@ -73,7 +73,7 @@ static void usage(const char *name)
int i;
 
printf(Warning : This program will work only on 
Valleyview/Cherryview\n
-  Usage: %s [-h] [--] port reg\n
+  Usage: %s [-h] [--] port reg [reg ...]\n
   \t -h : Show this help text\n
   \t port : , name);
for (i = 0; i  ARRAY_SIZE(iosf_sb_ports); i++)
@@ -96,7 +96,7 @@ int main(int argc, char *argv[])
}
 
for (;;) {
-   int c = getopt(argc, argv, h);
+   int c = getopt(argc, argv, hc:);
 
if (c == -1)
break;
@@ -120,9 +120,12 @@ int main(int argc, char *argv[])
 
intel_register_access_init(dev, 0);
 
-   reg = strtoul(argv[i], NULL, 16);
-   val = intel_iosf_sb_read(port, reg);
-   printf(0x%02x(%s)/0x%04x : 0x%08x\n, port, name, reg, val);
+   for (; i  argc; i++) {
+   reg = strtoul(argv[i], NULL, 16);
+
+   val = intel_iosf_sb_read(port, reg);
+   printf(0x%02x(%s)/0x%04x : 0x%08x\n, port, name, reg, val);
+   }
 
intel_register_access_fini();
 
diff --git a/tools/intel_iosf_sb_write.c b/tools/intel_iosf_sb_write.c
index d0ba4d3..eb6700d 100644
--- a/tools/intel_iosf_sb_write.c
+++ b/tools/intel_iosf_sb_write.c
@@ -72,7 +72,7 @@ static void usage(const char *name)
int i;
 
printf(Warning : This program will work only on 
Valleyview/Cherryview\n
-  Usage: %s [-h] [--] port reg val\n
+  Usage: %s [-h] [--] port reg val [reg val ...]\n
   \t -h : Show this help text\n
   \t port : , name);
for (i = 0; i  ARRAY_SIZE(iosf_sb_ports); i++)
@@ -118,18 +118,18 @@ int main(int argc, char** argv)
name = argv[i++];
port = iosf_sb_port_parse(name);
 
-   reg = strtoul(argv[i], NULL, 16);
-   val = strtoul(argv[i+1], NULL, 16);
-
intel_register_access_init(dev, 0);
 
-   tmp = intel_iosf_sb_read(port, reg);
-   printf(0x%02x(%s)/0x%04x before : 0x%08x\n, port, name, reg, tmp);
-
-   intel_iosf_sb_write(port, reg, val);
+   for (; i  argc; i += 2) {
+   reg = strtoul(argv[i], NULL, 16);
+   val = strtoul(argv[i+1], NULL, 16);
 
-   tmp = intel_iosf_sb_read(port, reg);
-   printf(0x%02x(%s)/0x%04x after  : 0x%08x\n, port, name, reg, tmp);
+   tmp = intel_iosf_sb_read(port, reg);
+   printf(0x%02x(%s)/0x%04x before : 0x%08x\n, port, name, reg, 
tmp);
+   intel_iosf_sb_write(port, reg, val);
+   tmp = intel_iosf_sb_read(port, reg);
+   printf(0x%02x(%s)/0x%04x after  : 0x%08x\n, port, name, reg, 
tmp);
+   }
 
intel_register_access_fini();
 
-- 
2.0.5

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


[Intel-gfx] [PATCH 4/7] drm/i915: Helper function to determine GGTT view from plane state

2015-03-23 Thread Tvrtko Ursulin
From: Tvrtko Ursulin tvrtko.ursu...@intel.com

For now only default implementation defaulting to normal view.

v2: Some code review cleanups. (Joonas Lahtinen)

Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
 drivers/gpu/drm/i915/intel_display.c | 25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 4d8a397..d3fa09b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2288,6 +2288,15 @@ intel_fb_align_height(struct drm_device *dev, unsigned 
int height,
   fb_format_modifier));
 }
 
+static int
+intel_fill_fb_ggtt_view(struct i915_ggtt_view *view, struct drm_framebuffer 
*fb,
+   const struct drm_plane_state *plane_state)
+{
+   *view = i915_ggtt_view_normal;
+
+   return 0;
+}
+
 int
 intel_pin_and_fence_fb_obj(struct drm_plane *plane,
   struct drm_framebuffer *fb,
@@ -2297,6 +2306,7 @@ intel_pin_and_fence_fb_obj(struct drm_plane *plane,
struct drm_device *dev = fb-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+   struct i915_ggtt_view view;
u32 alignment;
int ret;
 
@@ -2333,6 +2343,10 @@ intel_pin_and_fence_fb_obj(struct drm_plane *plane,
return -EINVAL;
}
 
+   ret = intel_fill_fb_ggtt_view(view, fb, plane_state);
+   if (ret)
+   return ret;
+
/* Note that the w/a also requires 64 PTE of padding following the
 * bo. We currently fill all unused PTE with the shadow page and so
 * we should always have valid PTE following the scanout preventing
@@ -2352,7 +2366,7 @@ intel_pin_and_fence_fb_obj(struct drm_plane *plane,
 
dev_priv-mm.interruptible = false;
ret = i915_gem_object_pin_to_display_plane(obj, alignment, pipelined,
-  i915_ggtt_view_normal);
+  view);
if (ret)
goto err_interruptible;
 
@@ -2372,7 +2386,7 @@ intel_pin_and_fence_fb_obj(struct drm_plane *plane,
return 0;
 
 err_unpin:
-   i915_gem_object_unpin_from_display_plane(obj, i915_ggtt_view_normal);
+   i915_gem_object_unpin_from_display_plane(obj, view);
 err_interruptible:
dev_priv-mm.interruptible = true;
intel_runtime_pm_put(dev_priv);
@@ -2383,11 +2397,16 @@ static void intel_unpin_fb_obj(struct drm_framebuffer 
*fb,
   const struct drm_plane_state *plane_state)
 {
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+   struct i915_ggtt_view view;
+   int ret;
 
WARN_ON(!mutex_is_locked(obj-base.dev-struct_mutex));
 
+   ret = intel_fill_fb_ggtt_view(view, fb, plane_state);
+   WARN_ONCE(ret, Couldn't get view from plane state!);
+
i915_gem_object_unpin_fence(obj);
-   i915_gem_object_unpin_from_display_plane(obj, i915_ggtt_view_normal);
+   i915_gem_object_unpin_from_display_plane(obj, view);
 }
 
 /* Computes the linear offset to the base tile and adjusts x, y. bytes per 
pixel
-- 
2.3.2

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


[Intel-gfx] [PATCH 2/7] drm/i915: Use GGTT view when (un)pinning objects to planes

2015-03-23 Thread Tvrtko Ursulin
From: Tvrtko Ursulin tvrtko.ursu...@intel.com

To support frame buffer rotation we need to be able to pass on the information
on what kind of GGTT view is required for display.

This patch just adds the parameter and makes all the callers default to the
normal view.

v2: Rebased for ggtt view changes.
v3: Don't limit PIN_MAPPABLE to normal views just yet. (Joonas Lahtinen)

Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
 drivers/gpu/drm/i915/i915_drv.h  | 14 +++---
 drivers/gpu/drm/i915/i915_gem.c  | 20 
 drivers/gpu/drm/i915/intel_display.c |  7 ---
 drivers/gpu/drm/i915/intel_overlay.c |  3 ++-
 4 files changed, 29 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index eb38cd1..e7ed5b3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2765,8 +2765,10 @@ i915_gem_object_set_to_cpu_domain(struct 
drm_i915_gem_object *obj, bool write);
 int __must_check
 i915_gem_object_pin_to_display_plane(struct drm_i915_gem_object *obj,
 u32 alignment,
-struct intel_engine_cs *pipelined);
-void i915_gem_object_unpin_from_display_plane(struct drm_i915_gem_object *obj);
+struct intel_engine_cs *pipelined,
+const struct i915_ggtt_view *view);
+void i915_gem_object_unpin_from_display_plane(struct drm_i915_gem_object *obj,
+ const struct i915_ggtt_view 
*view);
 int i915_gem_object_attach_phys(struct drm_i915_gem_object *obj,
int align);
 int i915_gem_open(struct drm_device *dev, struct drm_file *file);
@@ -2875,7 +2877,13 @@ i915_gem_object_ggtt_unbind(struct drm_i915_gem_object 
*obj)
return i915_vma_unbind(i915_gem_obj_to_ggtt(obj));
 }
 
-void i915_gem_object_ggtt_unpin(struct drm_i915_gem_object *obj);
+void i915_gem_object_ggtt_unpin_view(struct drm_i915_gem_object *obj,
+const struct i915_ggtt_view *view);
+static inline void
+i915_gem_object_ggtt_unpin(struct drm_i915_gem_object *obj)
+{
+   i915_gem_object_ggtt_unpin_view(obj, i915_ggtt_view_normal);
+}
 
 /* i915_gem_context.c */
 int __must_check i915_gem_context_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 84e2a23..73b2638 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3871,7 +3871,8 @@ static bool is_pin_display(struct drm_i915_gem_object 
*obj)
 int
 i915_gem_object_pin_to_display_plane(struct drm_i915_gem_object *obj,
 u32 alignment,
-struct intel_engine_cs *pipelined)
+struct intel_engine_cs *pipelined,
+const struct i915_ggtt_view *view)
 {
u32 old_read_domains, old_write_domain;
bool was_pin_display;
@@ -3907,7 +3908,7 @@ i915_gem_object_pin_to_display_plane(struct 
drm_i915_gem_object *obj,
 * (e.g. libkms for the bootup splash), we have to ensure that we
 * always use map_and_fenceable for all scanout buffers.
 */
-   ret = i915_gem_obj_ggtt_pin(obj, alignment, PIN_MAPPABLE);
+   ret = i915_gem_object_ggtt_pin(obj, view, alignment, PIN_MAPPABLE);
if (ret)
goto err_unpin_display;
 
@@ -3935,9 +3936,11 @@ err_unpin_display:
 }
 
 void
-i915_gem_object_unpin_from_display_plane(struct drm_i915_gem_object *obj)
+i915_gem_object_unpin_from_display_plane(struct drm_i915_gem_object *obj,
+const struct i915_ggtt_view *view)
 {
-   i915_gem_object_ggtt_unpin(obj);
+   i915_gem_object_ggtt_unpin_view(obj, view);
+
obj-pin_display = is_pin_display(obj);
 }
 
@@ -4214,15 +4217,16 @@ i915_gem_object_ggtt_pin(struct drm_i915_gem_object 
*obj,
 }
 
 void
-i915_gem_object_ggtt_unpin(struct drm_i915_gem_object *obj)
+i915_gem_object_ggtt_unpin_view(struct drm_i915_gem_object *obj,
+   const struct i915_ggtt_view *view)
 {
-   struct i915_vma *vma = i915_gem_obj_to_ggtt(obj);
+   struct i915_vma *vma = i915_gem_obj_to_ggtt_view(obj, view);
 
BUG_ON(!vma);
BUG_ON(vma-pin_count == 0);
-   BUG_ON(!i915_gem_obj_ggtt_bound(obj));
+   BUG_ON(!i915_gem_obj_ggtt_bound_view(obj, view-type));
 
-   if (--vma-pin_count == 0)
+   if (--vma-pin_count == 0  view-type == I915_GGTT_VIEW_NORMAL)
obj-pin_mappable = false;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3b9ce89..39380f4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2350,7 +2350,8 @@ intel_pin_and_fence_fb_obj(struct drm_plane *plane,

[Intel-gfx] [PATCH 6/7] drm/i915/skl: Query display address through a wrapper

2015-03-23 Thread Tvrtko Ursulin
From: Tvrtko Ursulin tvrtko.ursu...@intel.com

Need to do this in order to support 90/270 rotated display.

v2: Pass in drm_plane instead of plane index to intel_obj_display_address.

v3:
* Renamed intel_obj_display_address to intel_plane_obj_offset.
  (Chris Wilson)
* Simplified rotation check to bitwise AND. (Chris Wilson)

v4:
* Extracted 90/270 rotation check into a helper function. (Michel Thierry)

v5:
* Rebased for ggtt view changes.

For: VIZ-4545
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Reviewed-by: Michel Thierry michel.thie...@intel.com
Reviewed-by: Joonas Lahtinen joonas.lahti...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_display.c | 23 +--
 drivers/gpu/drm/i915/intel_drv.h |  9 +
 drivers/gpu/drm/i915/intel_sprite.c  |  5 -
 3 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f605b09..d1f9099 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2301,8 +2301,7 @@ intel_fill_fb_ggtt_view(struct i915_ggtt_view *view, 
struct drm_framebuffer *fb,
if (!plane_state)
return 0;
 
-   if (!(plane_state-rotation 
-   (BIT(DRM_ROTATE_90) | BIT(DRM_ROTATE_270
+   if (!intel_rotation_90_or_270(plane_state-rotation))
return 0;
 
*view = rotated_view;
@@ -2900,6 +2899,17 @@ u32 intel_fb_stride_alignment(struct drm_device *dev, 
uint64_t fb_modifier,
}
 }
 
+unsigned long intel_plane_obj_offset(struct intel_plane *intel_plane,
+struct drm_i915_gem_object *obj)
+{
+   enum i915_ggtt_view_type view = I915_GGTT_VIEW_NORMAL;
+
+   if (intel_rotation_90_or_270(intel_plane-base.state-rotation))
+   view = I915_GGTT_VIEW_ROTATED;
+
+   return i915_gem_obj_ggtt_offset_view(obj, view);
+}
+
 static void skylake_update_primary_plane(struct drm_crtc *crtc,
 struct drm_framebuffer *fb,
 int x, int y)
@@ -2910,6 +2920,7 @@ static void skylake_update_primary_plane(struct drm_crtc 
*crtc,
struct drm_i915_gem_object *obj;
int pipe = intel_crtc-pipe;
u32 plane_ctl, stride_div;
+   unsigned long surf_addr;
 
if (!intel_crtc-primary_enabled) {
I915_WRITE(PLANE_CTL(pipe, 0), 0);
@@ -2976,16 +2987,16 @@ static void skylake_update_primary_plane(struct 
drm_crtc *crtc,
obj = intel_fb_obj(fb);
stride_div = intel_fb_stride_alignment(dev, fb-modifier[0],
   fb-pixel_format);
+   surf_addr = intel_plane_obj_offset(to_intel_plane(crtc-primary), obj);
 
I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);
-
I915_WRITE(PLANE_POS(pipe, 0), 0);
I915_WRITE(PLANE_OFFSET(pipe, 0), (y  16) | x);
I915_WRITE(PLANE_SIZE(pipe, 0),
   (intel_crtc-config-pipe_src_h - 1)  16 |
   (intel_crtc-config-pipe_src_w - 1));
I915_WRITE(PLANE_STRIDE(pipe, 0), fb-pitches[0] / stride_div);
-   I915_WRITE(PLANE_SURF(pipe, 0), i915_gem_obj_ggtt_offset(obj));
+   I915_WRITE(PLANE_SURF(pipe, 0), surf_addr);
 
POSTING_READ(PLANE_SURF(pipe, 0));
 }
@@ -10079,8 +10090,8 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
if (ret)
goto cleanup_pending;
 
-   work-gtt_offset =
-   i915_gem_obj_ggtt_offset(obj) + intel_crtc-dspaddr_offset;
+   work-gtt_offset = intel_plane_obj_offset(to_intel_plane(primary), obj)
+ + intel_crtc-dspaddr_offset;
 
if (use_mmio_flip(ring, obj)) {
ret = intel_queue_mmio_flip(dev, crtc, fb, obj, ring,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cb00bd0..db0e7bf 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -988,6 +988,12 @@ unsigned int
 intel_tile_height(struct drm_device *dev, uint32_t pixel_format,
  uint64_t fb_format_modifier);
 
+static inline bool
+intel_rotation_90_or_270(unsigned int rotation)
+{
+   return rotation  (BIT(DRM_ROTATE_90) | BIT(DRM_ROTATE_270));
+}
+
 /* shared dpll functions */
 struct intel_shared_dpll *intel_crtc_to_shared_dpll(struct intel_crtc *crtc);
 void assert_shared_dpll(struct drm_i915_private *dev_priv,
@@ -1042,6 +1048,9 @@ void intel_mode_from_pipe_config(struct drm_display_mode 
*mode,
 void intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc);
 void intel_modeset_preclose(struct drm_device *dev, struct drm_file *file);
 
+unsigned long intel_plane_obj_offset(struct intel_plane *intel_plane,
+struct drm_i915_gem_object *obj);
+
 /* intel_dp.c */
 void intel_dp_init(struct drm_device *dev, int output_reg, enum port port);
 bool 

[Intel-gfx] [PATCH v5 0/7] Skylake 90/270 display rotation

2015-03-23 Thread Tvrtko Ursulin
From: Tvrtko Ursulin tvrtko.ursu...@intel.com

Display engine on Skylake can scan out specially prepared frame buffers
rotated by 90 or 270 degrees.

This adds partial support for this and will need some patches from Sonika to
complete the feature.

Going by looking pretty comment by Daniel Vetter (on IRC) I think this is now
ready for detailed review.

v2:
   * Individual review comments.
   * Main patch split into four smaller ones.

v3:
   * Dropped the DRM core patch since it has been merged.
   * Refactored tile height helper a bit.
   * Moved rotated GGTT view code into i915_gem_gtt.c

v4:
   * Rebased for ggtt view API changes.

v5:
   * Addressing review comments.
   * Added R-B tags.

Tvrtko Ursulin (7):
  drm/i915/skl: Extract tile height code into a helper function
  drm/i915: Use GGTT view when (un)pinning objects to planes
  drm/i915: Pass in plane state when (un)pinning frame buffers
  drm/i915: Helper function to determine GGTT view from plane state
  drm/i915/skl: Support secondary (rotated) frame buffer mapping
  drm/i915/skl: Query display address through a wrapper
  drm/i915/skl: Take 90/270 rotation into account in watermark
calculations

 drivers/gpu/drm/i915/i915_drv.h  |  14 +++-
 drivers/gpu/drm/i915/i915_gem.c  |  22 +++--
 drivers/gpu/drm/i915/i915_gem_gtt.c  | 117 +-
 drivers/gpu/drm/i915/i915_gem_gtt.h  |  12 +++
 drivers/gpu/drm/i915/intel_display.c | 158 +++
 drivers/gpu/drm/i915/intel_drv.h |  25 +-
 drivers/gpu/drm/i915/intel_fbdev.c   |   2 +-
 drivers/gpu/drm/i915/intel_overlay.c |   3 +-
 drivers/gpu/drm/i915/intel_pm.c  |  18 +++-
 drivers/gpu/drm/i915/intel_sprite.c  |  10 +--
 10 files changed, 320 insertions(+), 61 deletions(-)

-- 
2.3.2

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


[Intel-gfx] [PATCH 7/7] drm/i915/skl: Take 90/270 rotation into account in watermark calculations

2015-03-23 Thread Tvrtko Ursulin
From: Tvrtko Ursulin tvrtko.ursu...@intel.com

v2: Pass in rotation info to sprite plane updates as well.

v3: Use helper to determine 90/270 rotation. (Michel Thierry)

v4: Rebased for fb modifiers and atomic changes.

For: VIZ-4546
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Reviewed-by: Michel Thierry michel.thie...@intel.com (v3)
Reviewed-by: Joonas Lahtinen joonas.lahti...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_display.c | 27 +++
 drivers/gpu/drm/i915/intel_drv.h |  4 
 drivers/gpu/drm/i915/intel_pm.c  | 18 +-
 drivers/gpu/drm/i915/intel_sprite.c  |  5 +
 4 files changed, 45 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d1f9099..35cdb48 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12034,6 +12034,28 @@ static void intel_shared_dpll_init(struct drm_device 
*dev)
 }
 
 /**
+ * intel_wm_need_update - Check whether watermarks need updating
+ * @plane: drm plane
+ * @state: new plane state
+ *
+ * Check current plane state versus the new one to determine whether
+ * watermarks need to be recalculated.
+ *
+ * Returns true or false.
+ */
+bool intel_wm_need_update(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+   /* Update watermarks on tiling changes. */
+   if (!plane-state-fb || !state-fb ||
+   plane-state-fb-modifier[0] != state-fb-modifier[0] ||
+   plane-state-rotation != state-rotation)
+   return true;
+
+   return false;
+}
+
+/**
  * intel_prepare_plane_fb - Prepare fb for usage on plane
  * @plane: drm plane to prepare for
  * @fb: framebuffer to prepare for presentation
@@ -12179,10 +12201,7 @@ intel_check_primary_plane(struct drm_plane *plane,
 
intel_crtc-atomic.update_fbc = true;
 
-   /* Update watermarks on tiling changes. */
-   if (!plane-state-fb || !state-base.fb ||
-   plane-state-fb-modifier[0] !=
-   state-base.fb-modifier[0])
+   if (intel_wm_need_update(plane, state-base))
intel_crtc-atomic.update_wm = true;
}
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index db0e7bf..811a1db 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -501,6 +501,7 @@ struct intel_plane_wm_parameters {
bool enabled;
bool scaled;
u64 tiling;
+   unsigned int rotation;
 };
 
 struct intel_plane {
@@ -994,6 +995,9 @@ intel_rotation_90_or_270(unsigned int rotation)
return rotation  (BIT(DRM_ROTATE_90) | BIT(DRM_ROTATE_270));
 }
 
+bool intel_wm_need_update(struct drm_plane *plane,
+ struct drm_plane_state *state);
+
 /* shared dpll functions */
 struct intel_shared_dpll *intel_crtc_to_shared_dpll(struct intel_crtc *crtc);
 void assert_shared_dpll(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e18f0fd..753a3af 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2840,6 +2840,7 @@ static void skl_compute_wm_pipe_parameters(struct 
drm_crtc *crtc,
}
p-plane[0].horiz_pixels = intel_crtc-config-pipe_src_w;
p-plane[0].vert_pixels = intel_crtc-config-pipe_src_h;
+   p-plane[0].rotation = crtc-primary-state-rotation;
 
fb = crtc-cursor-state-fb;
if (fb) {
@@ -2897,7 +2898,21 @@ static bool skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
 
if (p_params-tiling == I915_FORMAT_MOD_Y_TILED ||
p_params-tiling == I915_FORMAT_MOD_Yf_TILED) {
-   uint32_t y_tile_minimum = plane_blocks_per_line * 4;
+   uint32_t min_scanlines = 4;
+   uint32_t y_tile_minimum;
+   if (intel_rotation_90_or_270(p_params-rotation)) {
+   switch (p_params-bytes_per_pixel) {
+   case 1:
+   min_scanlines = 16;
+   break;
+   case 2:
+   min_scanlines = 8;
+   break;
+   case 8:
+   WARN(1, Unsupported pixel depth for rotation);
+   };
+   }
+   y_tile_minimum = plane_blocks_per_line * min_scanlines;
selected_result = max(method2, y_tile_minimum);
} else {
if ((ddb_allocation / plane_blocks_per_line) = 1)
@@ -3357,6 +3372,7 @@ skl_update_sprite_wm(struct drm_plane *plane, struct 
drm_crtc *crtc,
 */
if (fb)
intel_plane-wm.tiling = fb-modifier[0];
+   intel_plane-wm.rotation = plane-state-rotation;
 

[Intel-gfx] [PATCH 5/7] drm/i915/skl: Support secondary (rotated) frame buffer mapping

2015-03-23 Thread Tvrtko Ursulin
From: Tvrtko Ursulin tvrtko.ursu...@intel.com

90/270 rotated scanout needs a rotated GTT view of the framebuffer.

This is put in a separate VMA with a dedicated ggtt view and wired such that
it is created when a framebuffer is pinned to a 90/270 rotated plane.

Rotation is only possible with Yb/Yf buffers and error is propagated to
user space in case of a mismatch.

Special rotated page view is constructed at the VMA creation time by
borrowing the DMA addresses from obj-pages.

v2:
* Do not bother with pages for rotated sg list, just populate the DMA
  addresses. (Daniel Vetter)
* Checkpatch cleanup.

v3:
* Rebased on top of new plane handling (create rotated mapping when
  setting the rotation property).
* Unpin rotated VMA on unpinning from display plane.
* Simplify rotation check using bitwise AND. (Chris Wilson)

v4:
* Fix unpinning of optional rotated mapping so it is really considered
  to be optional.

v5:
   * Rebased for fb modifier changes.
   * Rebased for atomic commit.
   * Only pin needed view for display. (Ville Syrjälä, Daniel Vetter)

v6:
   * Rebased after preparatory work has been extracted out. (Daniel Vetter)

v7:
   * Slightly simplified tiling geometry calculation.
   * Moved rotated GGTT view implementation into i915_gem_gtt.c (Daniel Vetter)

v8:
   * Do not use i915_gem_obj_size to get object size since that actually
 returns the size of an VMA which may not exist.
   * Rebased for ggtt view changes.

v9:
   * Rebased after code review changes on the preceding patches.
   * Tidy function definitions. (Joonas Lahtinen)

For: VIZ-4726
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Reviewed-by: Michel Thierry michel.thie...@intel.com (v4)
---
 drivers/gpu/drm/i915/i915_gem.c  |   4 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c  | 117 +--
 drivers/gpu/drm/i915/i915_gem_gtt.h  |  12 
 drivers/gpu/drm/i915/intel_display.c |  27 +++-
 drivers/gpu/drm/i915/intel_drv.h |   4 ++
 5 files changed, 158 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 73b2638..b6d4b07 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3908,7 +3908,9 @@ i915_gem_object_pin_to_display_plane(struct 
drm_i915_gem_object *obj,
 * (e.g. libkms for the bootup splash), we have to ensure that we
 * always use map_and_fenceable for all scanout buffers.
 */
-   ret = i915_gem_object_ggtt_pin(obj, view, alignment, PIN_MAPPABLE);
+   ret = i915_gem_object_ggtt_pin(obj, view, alignment,
+  view-type == I915_GGTT_VIEW_NORMAL ?
+  PIN_MAPPABLE : 0);
if (ret)
goto err_unpin_display;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 645c363..fc56c11 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2500,15 +2500,119 @@ i915_gem_obj_lookup_or_create_ggtt_vma(struct 
drm_i915_gem_object *obj,
 
 }
 
+static void
+rotate_pages(dma_addr_t *in, unsigned int width, unsigned int height,
+struct sg_table *st)
+{
+   unsigned int column, row;
+   unsigned int src_idx;
+   struct scatterlist *sg = st-sgl;
+
+   st-nents = 0;
+
+   for (column = 0; column  width; column++) {
+   src_idx = width * (height - 1) + column;
+   for (row = 0; row  height; row++) {
+   st-nents++;
+   /* We don't need the pages, but need to initialize
+* the entries so the sg list can be happily traversed.
+* The only thing we need are DMA addresses.
+*/
+   sg_set_page(sg, NULL, PAGE_SIZE, 0);
+   sg_dma_address(sg) = in[src_idx];
+   sg_dma_len(sg) = PAGE_SIZE;
+   sg = sg_next(sg);
+   src_idx -= width;
+   }
+   }
+}
+
+static struct sg_table *
+intel_rotate_fb_obj_pages(struct i915_ggtt_view *ggtt_view,
+ struct drm_i915_gem_object *obj)
+{
+   struct drm_device *dev = obj-base.dev;
+   struct intel_rotation_info *rot_info = ggtt_view-rotation_info;
+   unsigned long size, pages, rot_pages;
+   struct sg_page_iter sg_iter;
+   unsigned long i;
+   dma_addr_t *page_addr_list;
+   struct sg_table *st;
+   unsigned int tile_pitch, tile_height;
+   unsigned int width_pages, height_pages;
+   int ret = ENOMEM;
+
+   pages = obj-base.size / PAGE_SIZE;
+
+   /* Calculate tiling geometry. */
+   tile_height = intel_tile_height(dev, rot_info-pixel_format,
+   rot_info-fb_modifier);
+   tile_pitch = PAGE_SIZE / tile_height;
+   width_pages = 

[Intel-gfx] [PATCH 3/7] drm/i915: Pass in plane state when (un)pinning frame buffers

2015-03-23 Thread Tvrtko Ursulin
From: Tvrtko Ursulin tvrtko.ursu...@intel.com

Plane state carries the rotation information which is needed for determining
the appropriate GGTT view type.

This just adds the parameter with the actual usage coming in future patches.

Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Reviewed-by: Joonas Lahtinen joonas.lahti...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_display.c | 18 --
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 drivers/gpu/drm/i915/intel_fbdev.c   |  2 +-
 3 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 39380f4..4d8a397 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2291,6 +2291,7 @@ intel_fb_align_height(struct drm_device *dev, unsigned 
int height,
 int
 intel_pin_and_fence_fb_obj(struct drm_plane *plane,
   struct drm_framebuffer *fb,
+  const struct drm_plane_state *plane_state,
   struct intel_engine_cs *pipelined)
 {
struct drm_device *dev = fb-dev;
@@ -2378,8 +2379,11 @@ err_interruptible:
return ret;
 }
 
-static void intel_unpin_fb_obj(struct drm_i915_gem_object *obj)
+static void intel_unpin_fb_obj(struct drm_framebuffer *fb,
+  const struct drm_plane_state *plane_state)
 {
+   struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+
WARN_ON(!mutex_is_locked(obj-base.dev-struct_mutex));
 
i915_gem_object_unpin_fence(obj);
@@ -9318,7 +9322,7 @@ static void intel_unpin_work_fn(struct work_struct 
*__work)
enum pipe pipe = to_intel_crtc(work-crtc)-pipe;
 
mutex_lock(dev-struct_mutex);
-   intel_unpin_fb_obj(intel_fb_obj(work-old_fb));
+   intel_unpin_fb_obj(work-old_fb, work-crtc-primary-state);
drm_gem_object_unreference(work-pending_flip_obj-base);
 
intel_fbc_update(dev);
@@ -10026,7 +10030,8 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
ring = dev_priv-ring[RCS];
}
 
-   ret = intel_pin_and_fence_fb_obj(crtc-primary, fb, ring);
+   ret = intel_pin_and_fence_fb_obj(crtc-primary, fb,
+crtc-primary-state, ring);
if (ret)
goto cleanup_pending;
 
@@ -10066,7 +10071,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
return 0;
 
 cleanup_unpin:
-   intel_unpin_fb_obj(obj);
+   intel_unpin_fb_obj(fb, crtc-primary-state);
 cleanup_pending:
atomic_dec(intel_crtc-unpin_work_count);
mutex_unlock(dev-struct_mutex);
@@ -12022,7 +12027,7 @@ intel_prepare_plane_fb(struct drm_plane *plane,
if (ret)
DRM_DEBUG_KMS(failed to attach phys object\n);
} else {
-   ret = intel_pin_and_fence_fb_obj(plane, fb, NULL);
+   ret = intel_pin_and_fence_fb_obj(plane, fb, new_state, NULL);
}
 
if (ret == 0)
@@ -12054,7 +12059,7 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
if (plane-type != DRM_PLANE_TYPE_CURSOR ||
!INTEL_INFO(dev)-cursor_needs_physical) {
mutex_lock(dev-struct_mutex);
-   intel_unpin_fb_obj(obj);
+   intel_unpin_fb_obj(fb, old_state);
mutex_unlock(dev-struct_mutex);
}
 }
@@ -13940,6 +13945,7 @@ void intel_modeset_gem_init(struct drm_device *dev)
 
if (intel_pin_and_fence_fb_obj(c-primary,
   c-primary-fb,
+  c-primary-state,
   NULL)) {
DRM_ERROR(failed to pin boot fb on pipe %d\n,
  to_intel_crtc(c)-pipe);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e974dd6..a0df556 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -959,6 +959,7 @@ void intel_release_load_detect_pipe(struct drm_connector 
*connector,
struct intel_load_detect_pipe *old);
 int intel_pin_and_fence_fb_obj(struct drm_plane *plane,
   struct drm_framebuffer *fb,
+  const struct drm_plane_state *plane_state,
   struct intel_engine_cs *pipelined);
 struct drm_framebuffer *
 __intel_framebuffer_create(struct drm_device *dev,
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index 757c0d2..4e7e7da 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -151,7 +151,7 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
}
 
/* Flush everything out, we'll be doing GTT only from now on */
-   ret = intel_pin_and_fence_fb_obj(NULL, fb, NULL);
+   ret = 

Re: [Intel-gfx] [PATCH 46/49] drm/i915: Iterate through the initialized DDIs to prepare their buffers

2015-03-23 Thread Sivakumar Thulasimani



On 3/17/2015 3:10 PM, Imre Deak wrote:

From: Damien Lespiau damien.lesp...@intel.com

Not every DDIs is necessarily connected can be strapped off and, in the
future, we'll have platforms with a different number of default DDI
ports. So, let's only call intel_prepare_ddi_buffers() on DDI ports that
are actually detected.

We also use the opportunity to give a struct intel_digital_port to
intel_prepare_ddi_buffers() as we'll need it in a following patch to
query if the port supports HMDI or not.

On my HSW machine this removes the initialization of a couple of
(unused) DDIs.

Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
  drivers/gpu/drm/i915/i915_drv.h  |  4 
  drivers/gpu/drm/i915/intel_ddi.c | 16 
  2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e4dd4bba..e6402b0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -251,6 +251,10 @@ enum hpd_pin {
dev-mode_config.connector_list,\
base.head)
  
+#define for_each_digital_port(dev, digital_port)		\

+   list_for_each_entry(digital_port,   \
+   dev-mode_config.encoder_list,  \
+   base.base.head)
  
  #define for_each_encoder_on_crtc(dev, __crtc, intel_encoder) \

list_for_each_entry((intel_encoder), (dev)-mode_config.encoder_list, 
base.head) \
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ff62054..5c18018 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -189,10 +189,12 @@ enum port intel_ddi_get_encoder_port(struct intel_encoder 
*intel_encoder)
   * in either FDI or DP modes only, as HDMI connections will work with both
   * of those
   */
-static void intel_prepare_ddi_buffers(struct drm_device *dev, enum port port)
+static void intel_prepare_ddi_buffers(struct drm_device *dev,
+ struct intel_digital_port *intel_dig_port)
  {
struct drm_i915_private *dev_priv = dev-dev_private;
u32 reg;
+   int port = intel_dig_port-port;
int i, n_hdmi_entries, n_dp_entries, n_edp_entries, hdmi_default_entry,
size;
int hdmi_level = dev_priv-vbt.ddi_port_info[port].hdmi_level_shift;
@@ -307,13 +309,19 @@ static void intel_prepare_ddi_buffers(struct drm_device 
*dev, enum port port)
   */
  void intel_prepare_ddi(struct drm_device *dev)
  {
-   int port;
+   struct intel_digital_port *intel_dig_port;
+   bool visited[I915_MAX_PORTS] = { 0, };
  
  	if (!HAS_DDI(dev))

return;
  
-	for (port = PORT_A; port = PORT_E; port++)

-   intel_prepare_ddi_buffers(dev, port);
+   for_each_digital_port(dev, intel_dig_port) {
+   if (visited[intel_dig_port-port])
+   continue;
+
+   intel_prepare_ddi_buffers(dev, intel_dig_port);
+   visited[intel_dig_port-port] = true;
+   }
  }
  
  static void intel_wait_ddi_buf_idle(struct drm_i915_private *dev_priv,

is visited[] for handling MST scenarios ?if so looks good to me.
Reviewed-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com

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


Re: [Intel-gfx] [PATCH 47/49] drm/i915: Don't write the HDMI buffer translation entry when not needed

2015-03-23 Thread Sivakumar Thulasimani

Reviewed-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com

On 3/17/2015 3:10 PM, Imre Deak wrote:

From: Damien Lespiau damien.lesp...@intel.com

We don't actually need to write the HDMI entry on DDIs that have no
chance to be used as HDMI ports.

While this patch shouldn't change the current behaviour, it makes
further enabling work easier as we'll have an eDP table filling the full
10 entries.

v2: Rely on the logic from intel_ddi_init() to figure out if the DDI port
 supports HDMI or not (Paulo).

Suggested-by: Satheeshakrishna M satheeshakrishn...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
  drivers/gpu/drm/i915/intel_ddi.c | 9 +
  1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 5c18018..5aa4dab 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -182,6 +182,12 @@ enum port intel_ddi_get_encoder_port(struct intel_encoder 
*intel_encoder)
}
  }
  
+static bool

+intel_dig_port_supports_hdmi(const struct intel_digital_port *intel_dig_port)
+{
+   return intel_dig_port-hdmi.hdmi_reg;
+}
+
  /*
   * Starting with Haswell, DDI port buffers must be programmed with correct
   * values in advance. The buffer values are different for FDI and DP modes,
@@ -292,6 +298,9 @@ static void intel_prepare_ddi_buffers(struct drm_device 
*dev,
reg += 4;
}
  
+	if (!intel_dig_port_supports_hdmi(intel_dig_port))

+   return;
+
/* Choose a good default if VBT is badly populated */
if (hdmi_level == HDMI_LEVEL_SHIFT_UNKNOWN ||
hdmi_level = n_hdmi_entries)


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


[Intel-gfx] [PATCH 1/7] drm/i915/skl: Extract tile height code into a helper function

2015-03-23 Thread Tvrtko Ursulin
From: Tvrtko Ursulin tvrtko.ursu...@intel.com

It will be used in a later patch and also convert all height parameters
from int to unsigned int.

v2: Rebased for fb modifiers.
v3: Fixed v2 rebase.
v4:
   * Height should be unsigned int.
   * Make it take pixel_format for consistency and simplicity.

Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Reviewed-by: Michel Thierry michel.thie...@intel.com (v1)
Reviewed-by: Joonas Lahtinen joonas.lahti...@linux.intel.com (v4)
---
 drivers/gpu/drm/i915/intel_display.c | 43 +---
 drivers/gpu/drm/i915/intel_drv.h |  7 +++---
 2 files changed, 29 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 60230dc..3b9ce89 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2233,13 +2233,12 @@ static bool need_vtd_wa(struct drm_device *dev)
return false;
 }
 
-int
-intel_fb_align_height(struct drm_device *dev, int height,
- uint32_t pixel_format,
- uint64_t fb_format_modifier)
+static unsigned int
+intel_tile_height(struct drm_device *dev, uint32_t pixel_format,
+ uint64_t fb_format_modifier)
 {
-   int tile_height;
-   uint32_t bits_per_pixel;
+   unsigned int tile_height;
+   uint32_t pixel_bytes;
 
switch (fb_format_modifier) {
case DRM_FORMAT_MOD_NONE:
@@ -2252,20 +2251,20 @@ intel_fb_align_height(struct drm_device *dev, int 
height,
tile_height = 32;
break;
case I915_FORMAT_MOD_Yf_TILED:
-   bits_per_pixel = drm_format_plane_cpp(pixel_format, 0) * 8;
-   switch (bits_per_pixel) {
+   pixel_bytes = drm_format_plane_cpp(pixel_format, 0);
+   switch (pixel_bytes) {
default:
-   case 8:
+   case 1:
tile_height = 64;
break;
-   case 16:
-   case 32:
+   case 2:
+   case 4:
tile_height = 32;
break;
-   case 64:
+   case 8:
tile_height = 16;
break;
-   case 128:
+   case 16:
WARN_ONCE(1,
  128-bit pixels are not supported for 
display!);
tile_height = 16;
@@ -2278,7 +2277,15 @@ intel_fb_align_height(struct drm_device *dev, int height,
break;
}
 
-   return ALIGN(height, tile_height);
+   return tile_height;
+}
+
+unsigned int
+intel_fb_align_height(struct drm_device *dev, unsigned int height,
+ uint32_t pixel_format, uint64_t fb_format_modifier)
+{
+   return ALIGN(height, intel_tile_height(dev, pixel_format,
+  fb_format_modifier));
 }
 
 int
@@ -6811,7 +6818,7 @@ i9xx_get_initial_plane_config(struct intel_crtc *crtc,
u32 val, base, offset;
int pipe = crtc-pipe, plane = crtc-plane;
int fourcc, pixel_format;
-   int aligned_height;
+   unsigned int aligned_height;
struct drm_framebuffer *fb;
struct intel_framebuffer *intel_fb;
 
@@ -7849,7 +7856,7 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc,
u32 val, base, offset, stride_mult, tiling;
int pipe = crtc-pipe;
int fourcc, pixel_format;
-   int aligned_height;
+   unsigned int aligned_height;
struct drm_framebuffer *fb;
struct intel_framebuffer *intel_fb;
 
@@ -7957,7 +7964,7 @@ ironlake_get_initial_plane_config(struct intel_crtc *crtc,
u32 val, base, offset;
int pipe = crtc-pipe;
int fourcc, pixel_format;
-   int aligned_height;
+   unsigned int aligned_height;
struct drm_framebuffer *fb;
struct intel_framebuffer *intel_fb;
 
@@ -12883,7 +12890,7 @@ static int intel_framebuffer_init(struct drm_device 
*dev,
  struct drm_mode_fb_cmd2 *mode_cmd,
  struct drm_i915_gem_object *obj)
 {
-   int aligned_height;
+   unsigned int aligned_height;
int ret;
u32 pitch_limit, stride_alignment;
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d2a4de0..e974dd6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -901,9 +901,10 @@ void intel_frontbuffer_flip(struct drm_device *dev,
intel_frontbuffer_flush(dev, frontbuffer_bits);
 }
 
-int intel_fb_align_height(struct drm_device *dev, int height,
- uint32_t pixel_format,
- uint64_t fb_format_modifier);
+unsigned int intel_fb_align_height(struct drm_device *dev,
+  unsigned int height,
+   

Re: [Intel-gfx] [RFC 3/4] drm/i915: Interrupt driven fences

2015-03-23 Thread John Harrison

On 23/03/2015 09:22, Daniel Vetter wrote:

On Fri, Mar 20, 2015 at 09:11:35PM +, Chris Wilson wrote:

On Fri, Mar 20, 2015 at 05:48:36PM +, john.c.harri...@intel.com wrote:

From: John Harrison john.c.harri...@intel.com

The intended usage model for struct fence is that the signalled status should be
set on demand rather than polled. That is, there should not be a need for a
'signaled' function to be called everytime the status is queried. Instead,
'something' should be done to enable a signal callback from the hardware which
will update the state directly. In the case of requests, this is the seqno
update interrupt. The idea is that this callback will only be enabled on demand
when something actually tries to wait on the fence.

This change removes the polling test and replaces it with the callback scheme.
To avoid race conditions where signals can be sent before anyone is waiting for
them, it does not implement the callback on demand feature. When the GPU
scheduler arrives, it will need to know about the completion of every single
request anyway. So it is far simpler to not put in complex and messy anti-race
code in the first place given that it will not be needed in the future.

Instead, each fence is added to a 'please poke me' list at the start of
i915_add_request(). This happens before the commands to generate the seqno
interrupt are added to the ring thus is guaranteed to be race free. The
interrupt handler then scans through the 'poke me' list when a new seqno pops
out and signals any matching fence/request. The fence is then removed from the
list so the entire request stack does not need to be scanned every time.

No. Please let's not go back to the bad old days of generating an interrupt
per batch, and doing a lot more work inside the interrupt handler.

Yeah, enable_signalling should be the place where we grab the interrupt
reference. Also that we shouldn't call this unconditionally, that pretty
much defeats the point of that fastpath optimization.

Another complication is missed interrupts. If we detect those and someone
calls enable_signalling then we need to fire up a timer to wake up once
per jiffy and save stuck fences. To avoid duplication with the threaded
wait code we could remove the fallback wakeups from there and just rely on
that timer everywhere.
-Daniel


As has been discussed many times in many forums, the scheduler requires 
notification of each batch buffer's completion. It needs to know so that 
it can submit new work, keep dependencies of outstanding work up to 
date, etc.


Android is similar. With the native sync API, Android wants to be 
signaled about the completion of everything. Every single batch buffer 
submission comes with a request for a sync point that will be poked when 
that buffer completes. The kernel has no way of knowing which buffers 
are actually going to be waited on. There is no driver call anymore. 
User land simply waits on a file descriptor.


I don't see how we can get away without generating an interrupt per batch.

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


Re: [Intel-gfx] [PATCH 1/4] kernel.h: Implement DIV_ROUND_CLOSEST_ULL

2015-03-23 Thread Jeff Epler
On Fri, Mar 20, 2015 at 11:14:40AM +, Javi Merino wrote:
 +/*
 + * Same as above but for u64 dividends.  divisor must be a 32-bit
 + * number.
 + */
 +#define DIV_ROUND_CLOSEST_ULL(x, divisor)(   \
 +{\
 + unsigned long long _tmp = (x) + (divisor) / 2;  \
 + do_div(_tmp, divisor);  \
 + _tmp;   \
 +}\
 +)

The macro evaluates 'divisor' twice.

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


Re: [Intel-gfx] [PATCH 4/4] media: cxd2820r: use DIV_ROUND_CLOSEST_ULL()

2015-03-23 Thread Antti Palosaari

On 03/20/2015 01:14 PM, Javi Merino wrote:

Now that the kernel provides DIV_ROUND_CLOSEST_ULL(), drop the internal
implementation and use the kernel one.

Cc: Antti Palosaari cr...@iki.fi
Cc: Mauro Carvalho Chehab mche...@osg.samsung.com
Signed-off-by: Javi Merino javi.mer...@arm.com


Acked-by: Antti Palosaari cr...@iki.fi
Reviewed-by: Antti Palosaari cr...@iki.fi


Antti


---
I've only compile-tested it, I don't have the hardware to run it.

  drivers/media/dvb-frontends/cxd2820r_c.c| 2 +-
  drivers/media/dvb-frontends/cxd2820r_core.c | 6 --
  drivers/media/dvb-frontends/cxd2820r_priv.h | 2 --
  drivers/media/dvb-frontends/cxd2820r_t.c| 2 +-
  drivers/media/dvb-frontends/cxd2820r_t2.c   | 2 +-
  5 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/media/dvb-frontends/cxd2820r_c.c 
b/drivers/media/dvb-frontends/cxd2820r_c.c
index 149fdca3fb44..72b0e2db3aab 100644
--- a/drivers/media/dvb-frontends/cxd2820r_c.c
+++ b/drivers/media/dvb-frontends/cxd2820r_c.c
@@ -79,7 +79,7 @@ int cxd2820r_set_frontend_c(struct dvb_frontend *fe)

num = if_freq / 1000; /* Hz = kHz */
num *= 0x4000;
-   if_ctl = 0x4000 - cxd2820r_div_u64_round_closest(num, 41000);
+   if_ctl = 0x4000 - DIV_ROUND_CLOSEST_ULL(num, 41000);
buf[0] = (if_ctl  8)  0x3f;
buf[1] = (if_ctl  0)  0xff;

diff --git a/drivers/media/dvb-frontends/cxd2820r_core.c 
b/drivers/media/dvb-frontends/cxd2820r_core.c
index 422e84bbb008..490e090048ef 100644
--- a/drivers/media/dvb-frontends/cxd2820r_core.c
+++ b/drivers/media/dvb-frontends/cxd2820r_core.c
@@ -244,12 +244,6 @@ error:
return ret;
  }

-/* 64 bit div with round closest, like DIV_ROUND_CLOSEST but 64 bit */
-u32 cxd2820r_div_u64_round_closest(u64 dividend, u32 divisor)
-{
-   return div_u64(dividend + (divisor / 2), divisor);
-}
-
  static int cxd2820r_set_frontend(struct dvb_frontend *fe)
  {
struct cxd2820r_priv *priv = fe-demodulator_priv;
diff --git a/drivers/media/dvb-frontends/cxd2820r_priv.h 
b/drivers/media/dvb-frontends/cxd2820r_priv.h
index 7ff5f60c83e1..4b428959b16e 100644
--- a/drivers/media/dvb-frontends/cxd2820r_priv.h
+++ b/drivers/media/dvb-frontends/cxd2820r_priv.h
@@ -64,8 +64,6 @@ int cxd2820r_wr_reg_mask(struct cxd2820r_priv *priv, u32 reg, 
u8 val,
  int cxd2820r_wr_regs(struct cxd2820r_priv *priv, u32 reginfo, u8 *val,
int len);

-u32 cxd2820r_div_u64_round_closest(u64 dividend, u32 divisor);
-
  int cxd2820r_wr_regs(struct cxd2820r_priv *priv, u32 reginfo, u8 *val,
int len);

diff --git a/drivers/media/dvb-frontends/cxd2820r_t.c 
b/drivers/media/dvb-frontends/cxd2820r_t.c
index 51401d036530..008cb2ac8480 100644
--- a/drivers/media/dvb-frontends/cxd2820r_t.c
+++ b/drivers/media/dvb-frontends/cxd2820r_t.c
@@ -103,7 +103,7 @@ int cxd2820r_set_frontend_t(struct dvb_frontend *fe)

num = if_freq / 1000; /* Hz = kHz */
num *= 0x100;
-   if_ctl = cxd2820r_div_u64_round_closest(num, 41000);
+   if_ctl = DIV_ROUND_CLOSEST_ULL(num, 41000);
buf[0] = ((if_ctl  16)  0xff);
buf[1] = ((if_ctl   8)  0xff);
buf[2] = ((if_ctl   0)  0xff);
diff --git a/drivers/media/dvb-frontends/cxd2820r_t2.c 
b/drivers/media/dvb-frontends/cxd2820r_t2.c
index 9c0c4f42175c..35fe364c7182 100644
--- a/drivers/media/dvb-frontends/cxd2820r_t2.c
+++ b/drivers/media/dvb-frontends/cxd2820r_t2.c
@@ -120,7 +120,7 @@ int cxd2820r_set_frontend_t2(struct dvb_frontend *fe)

num = if_freq / 1000; /* Hz = kHz */
num *= 0x100;
-   if_ctl = cxd2820r_div_u64_round_closest(num, 41000);
+   if_ctl = DIV_ROUND_CLOSEST_ULL(num, 41000);
buf[0] = ((if_ctl  16)  0xff);
buf[1] = ((if_ctl   8)  0xff);
buf[2] = ((if_ctl   0)  0xff);



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


Re: [Intel-gfx] [PATCH 4/4] media: cxd2820r: use DIV_ROUND_CLOSEST_ULL()

2015-03-23 Thread Alex Elder
On 03/20/2015 12:27 PM, Javi Merino wrote:
 On Fri, Mar 20, 2015 at 01:51:36PM +, Alex Elder wrote:
 On 03/20/2015 06:14 AM, Javi Merino wrote:
 Now that the kernel provides DIV_ROUND_CLOSEST_ULL(), drop the internal
 implementation and use the kernel one.

 Cc: Antti Palosaari cr...@iki.fi
 Cc: Mauro Carvalho Chehab mche...@osg.samsung.com
 Signed-off-by: Javi Merino javi.mer...@arm.com
 ---
 I've only compile-tested it, I don't have the hardware to run it.

  drivers/media/dvb-frontends/cxd2820r_c.c| 2 +-
  drivers/media/dvb-frontends/cxd2820r_core.c | 6 --
  drivers/media/dvb-frontends/cxd2820r_priv.h | 2 --
  drivers/media/dvb-frontends/cxd2820r_t.c| 2 +-
  drivers/media/dvb-frontends/cxd2820r_t2.c   | 2 +-
  5 files changed, 3 insertions(+), 11 deletions(-)

 diff --git a/drivers/media/dvb-frontends/cxd2820r_c.c 
 b/drivers/media/dvb-frontends/cxd2820r_c.c
 index 149fdca3fb44..72b0e2db3aab 100644
 --- a/drivers/media/dvb-frontends/cxd2820r_c.c
 +++ b/drivers/media/dvb-frontends/cxd2820r_c.c
 @@ -79,7 +79,7 @@ int cxd2820r_set_frontend_c(struct dvb_frontend *fe)
  
 num = if_freq / 1000; /* Hz = kHz */
 num *= 0x4000;
 -   if_ctl = 0x4000 - cxd2820r_div_u64_round_closest(num, 41000);
 +   if_ctl = 0x4000 - DIV_ROUND_CLOSEST_ULL(num, 41000);
 buf[0] = (if_ctl  8)  0x3f;
 buf[1] = (if_ctl  0)  0xff;
  
 diff --git a/drivers/media/dvb-frontends/cxd2820r_core.c 
 b/drivers/media/dvb-frontends/cxd2820r_core.c
 index 422e84bbb008..490e090048ef 100644
 --- a/drivers/media/dvb-frontends/cxd2820r_core.c
 +++ b/drivers/media/dvb-frontends/cxd2820r_core.c
 @@ -244,12 +244,6 @@ error:
 return ret;
  }
  
 -/* 64 bit div with round closest, like DIV_ROUND_CLOSEST but 64 bit */
 -u32 cxd2820r_div_u64_round_closest(u64 dividend, u32 divisor)
 -{
 -   return div_u64(dividend + (divisor / 2), divisor);
 -}

 Technically, I'd say this has a bug, because the result
 needs to be 64 bits wide or your results might be much
 different from what might be desired.

 Practically though, I'm pretty sure all callers provide
 values that ensure the result is valid.
 
 All the callers are substituted in this patch so we can make sure that
 they are all correct.
 
 I only call attention because this patch changes the return
 type of the function that gets called to do the calculation.
 
 I'm not sure I follow.  Do you mean that this:
 
   if_ctl = 0x4000 - DIV_ROUND_CLOSEST_ULL(num, 41000);
 
 Should actually be:
 
   if_ctl = 0x4000 - (u32)DIV_ROUND_CLOSEST_ULL(num, 41000);

I'm merely stating that your change includes changing the
type of the value returned (cxd2820r_div_u64_round_closest()
returns u32, DIV_ROUND_CLOSEST_ULL() returns U64).  So
in that respect, your patch is not completely trivial.

That said, as you point out (and I also did a quick check)
it does not seem to be an issue here.

The bug (if you call it that) existed before your patch, and
I am not suggesting you change anything.  Just hoping for
a verification that the different return type does not
lead to any problems.  I'm convinced.

-Alex



 ?
 
 if_ctl is a u16 so I don't think you gain anything by doing that.
 
 -
  static int cxd2820r_set_frontend(struct dvb_frontend *fe)
  {
 struct cxd2820r_priv *priv = fe-demodulator_priv;
 diff --git a/drivers/media/dvb-frontends/cxd2820r_priv.h 
 b/drivers/media/dvb-frontends/cxd2820r_priv.h
 index 7ff5f60c83e1..4b428959b16e 100644
 --- a/drivers/media/dvb-frontends/cxd2820r_priv.h
 +++ b/drivers/media/dvb-frontends/cxd2820r_priv.h
 @@ -64,8 +64,6 @@ int cxd2820r_wr_reg_mask(struct cxd2820r_priv *priv, u32 
 reg, u8 val,
  int cxd2820r_wr_regs(struct cxd2820r_priv *priv, u32 reginfo, u8 *val,
 int len);
  
 -u32 cxd2820r_div_u64_round_closest(u64 dividend, u32 divisor);
 -
  int cxd2820r_wr_regs(struct cxd2820r_priv *priv, u32 reginfo, u8 *val,
 int len);
  
 diff --git a/drivers/media/dvb-frontends/cxd2820r_t.c 
 b/drivers/media/dvb-frontends/cxd2820r_t.c
 index 51401d036530..008cb2ac8480 100644
 --- a/drivers/media/dvb-frontends/cxd2820r_t.c
 +++ b/drivers/media/dvb-frontends/cxd2820r_t.c
 @@ -103,7 +103,7 @@ int cxd2820r_set_frontend_t(struct dvb_frontend *fe)
  
 num = if_freq / 1000; /* Hz = kHz */
 num *= 0x100;
 -   if_ctl = cxd2820r_div_u64_round_closest(num, 41000);
 +   if_ctl = DIV_ROUND_CLOSEST_ULL(num, 41000);
 
 if_ctl is a u32, so you get the same behavior that you were getting
 before: the downcasting of u64 to u32 happened in
 cxd2820r_div_u64_round_closest(), now it happens here.
 
 buf[0] = ((if_ctl  16)  0xff);
 buf[1] = ((if_ctl   8)  0xff);
 buf[2] = ((if_ctl   0)  0xff);
 diff --git a/drivers/media/dvb-frontends/cxd2820r_t2.c 
 b/drivers/media/dvb-frontends/cxd2820r_t2.c
 index 9c0c4f42175c..35fe364c7182 100644
 --- a/drivers/media/dvb-frontends/cxd2820r_t2.c
 +++ b/drivers/media/dvb-frontends/cxd2820r_t2.c
 @@ -120,7 +120,7 @@ int cxd2820r_set_frontend_t2(struct dvb_frontend 

Re: [Intel-gfx] [PATCH 4/4] media: cxd2820r: use DIV_ROUND_CLOSEST_ULL()

2015-03-23 Thread Alex Elder
On 03/20/2015 06:14 AM, Javi Merino wrote:
 Now that the kernel provides DIV_ROUND_CLOSEST_ULL(), drop the internal
 implementation and use the kernel one.
 
 Cc: Antti Palosaari cr...@iki.fi
 Cc: Mauro Carvalho Chehab mche...@osg.samsung.com
 Signed-off-by: Javi Merino javi.mer...@arm.com
 ---
 I've only compile-tested it, I don't have the hardware to run it.
 
  drivers/media/dvb-frontends/cxd2820r_c.c| 2 +-
  drivers/media/dvb-frontends/cxd2820r_core.c | 6 --
  drivers/media/dvb-frontends/cxd2820r_priv.h | 2 --
  drivers/media/dvb-frontends/cxd2820r_t.c| 2 +-
  drivers/media/dvb-frontends/cxd2820r_t2.c   | 2 +-
  5 files changed, 3 insertions(+), 11 deletions(-)
 
 diff --git a/drivers/media/dvb-frontends/cxd2820r_c.c 
 b/drivers/media/dvb-frontends/cxd2820r_c.c
 index 149fdca3fb44..72b0e2db3aab 100644
 --- a/drivers/media/dvb-frontends/cxd2820r_c.c
 +++ b/drivers/media/dvb-frontends/cxd2820r_c.c
 @@ -79,7 +79,7 @@ int cxd2820r_set_frontend_c(struct dvb_frontend *fe)
  
   num = if_freq / 1000; /* Hz = kHz */
   num *= 0x4000;
 - if_ctl = 0x4000 - cxd2820r_div_u64_round_closest(num, 41000);
 + if_ctl = 0x4000 - DIV_ROUND_CLOSEST_ULL(num, 41000);
   buf[0] = (if_ctl  8)  0x3f;
   buf[1] = (if_ctl  0)  0xff;
  
 diff --git a/drivers/media/dvb-frontends/cxd2820r_core.c 
 b/drivers/media/dvb-frontends/cxd2820r_core.c
 index 422e84bbb008..490e090048ef 100644
 --- a/drivers/media/dvb-frontends/cxd2820r_core.c
 +++ b/drivers/media/dvb-frontends/cxd2820r_core.c
 @@ -244,12 +244,6 @@ error:
   return ret;
  }
  
 -/* 64 bit div with round closest, like DIV_ROUND_CLOSEST but 64 bit */
 -u32 cxd2820r_div_u64_round_closest(u64 dividend, u32 divisor)
 -{
 - return div_u64(dividend + (divisor / 2), divisor);
 -}

Technically, I'd say this has a bug, because the result
needs to be 64 bits wide or your results might be much
different from what might be desired.

Practically though, I'm pretty sure all callers provide
values that ensure the result is valid.

I only call attention because this patch changes the return
type of the function that gets called to do the calculation.

-Alex

 -
  static int cxd2820r_set_frontend(struct dvb_frontend *fe)
  {
   struct cxd2820r_priv *priv = fe-demodulator_priv;
 diff --git a/drivers/media/dvb-frontends/cxd2820r_priv.h 
 b/drivers/media/dvb-frontends/cxd2820r_priv.h
 index 7ff5f60c83e1..4b428959b16e 100644
 --- a/drivers/media/dvb-frontends/cxd2820r_priv.h
 +++ b/drivers/media/dvb-frontends/cxd2820r_priv.h
 @@ -64,8 +64,6 @@ int cxd2820r_wr_reg_mask(struct cxd2820r_priv *priv, u32 
 reg, u8 val,
  int cxd2820r_wr_regs(struct cxd2820r_priv *priv, u32 reginfo, u8 *val,
   int len);
  
 -u32 cxd2820r_div_u64_round_closest(u64 dividend, u32 divisor);
 -
  int cxd2820r_wr_regs(struct cxd2820r_priv *priv, u32 reginfo, u8 *val,
   int len);
  
 diff --git a/drivers/media/dvb-frontends/cxd2820r_t.c 
 b/drivers/media/dvb-frontends/cxd2820r_t.c
 index 51401d036530..008cb2ac8480 100644
 --- a/drivers/media/dvb-frontends/cxd2820r_t.c
 +++ b/drivers/media/dvb-frontends/cxd2820r_t.c
 @@ -103,7 +103,7 @@ int cxd2820r_set_frontend_t(struct dvb_frontend *fe)
  
   num = if_freq / 1000; /* Hz = kHz */
   num *= 0x100;
 - if_ctl = cxd2820r_div_u64_round_closest(num, 41000);
 + if_ctl = DIV_ROUND_CLOSEST_ULL(num, 41000);
   buf[0] = ((if_ctl  16)  0xff);
   buf[1] = ((if_ctl   8)  0xff);
   buf[2] = ((if_ctl   0)  0xff);
 diff --git a/drivers/media/dvb-frontends/cxd2820r_t2.c 
 b/drivers/media/dvb-frontends/cxd2820r_t2.c
 index 9c0c4f42175c..35fe364c7182 100644
 --- a/drivers/media/dvb-frontends/cxd2820r_t2.c
 +++ b/drivers/media/dvb-frontends/cxd2820r_t2.c
 @@ -120,7 +120,7 @@ int cxd2820r_set_frontend_t2(struct dvb_frontend *fe)
  
   num = if_freq / 1000; /* Hz = kHz */
   num *= 0x100;
 - if_ctl = cxd2820r_div_u64_round_closest(num, 41000);
 + if_ctl = DIV_ROUND_CLOSEST_ULL(num, 41000);
   buf[0] = ((if_ctl  16)  0xff);
   buf[1] = ((if_ctl   8)  0xff);
   buf[2] = ((if_ctl   0)  0xff);
 

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


[Intel-gfx] [PATCH 2/4] clk: bcm/kona: use DIV_ROUND_CLOSEST_ULL()

2015-03-23 Thread Javi Merino
Now that the kernel provides DIV_ROUND_CLOSEST_ULL(), drop the internal
implementation and use the kernel one.

Cc: Mike Turquette mturque...@linaro.org
Cc: Stephen Boyd sb...@codeaurora.org
Cc: Alex Elder el...@linaro.org
Signed-off-by: Javi Merino javi.mer...@arm.com
---
I've only compile-tested this, I don't have the hardware to test it.

 drivers/clk/bcm/clk-kona.c | 28 +++-
 drivers/clk/bcm/clk-kona.h |  1 -
 2 files changed, 7 insertions(+), 22 deletions(-)

diff --git a/drivers/clk/bcm/clk-kona.c b/drivers/clk/bcm/clk-kona.c
index 05abae89262e..a0ef4f75d457 100644
--- a/drivers/clk/bcm/clk-kona.c
+++ b/drivers/clk/bcm/clk-kona.c
@@ -15,6 +15,7 @@
 #include clk-kona.h
 
 #include linux/delay.h
+#include linux/kernel.h
 
 /*
  * Policies affect the frequencies of bus clocks provided by a
@@ -51,21 +52,6 @@ static inline u32 bitfield_replace(u32 reg_val, u32 shift, 
u32 width, u32 val)
 
 /* Divider and scaling helpers */
 
-/*
- * Implement DIV_ROUND_CLOSEST() for 64-bit dividend and both values
- * unsigned.  Note that unlike do_div(), the remainder is discarded
- * and the return value is the quotient (not the remainder).
- */
-u64 do_div_round_closest(u64 dividend, unsigned long divisor)
-{
-   u64 result;
-
-   result = dividend + ((u64)divisor  1);
-   (void)do_div(result, divisor);
-
-   return result;
-}
-
 /* Convert a divider into the scaled divisor value it represents. */
 static inline u64 scaled_div_value(struct bcm_clk_div *div, u32 reg_div)
 {
@@ -87,7 +73,7 @@ u64 scaled_div_build(struct bcm_clk_div *div, u32 div_value, 
u32 billionths)
combined = (u64)div_value * BILLION + billionths;
combined = div-u.s.frac_width;
 
-   return do_div_round_closest(combined, BILLION);
+   return DIV_ROUND_CLOSEST_ULL(combined, BILLION);
 }
 
 /* The scaled minimum divisor representable by a divider */
@@ -731,7 +717,7 @@ static unsigned long clk_recalc_rate(struct ccu_data *ccu,
scaled_rate = scale_rate(pre_div, parent_rate);
scaled_rate = scale_rate(div, scaled_rate);
scaled_div = divider_read_scaled(ccu, pre_div);
-   scaled_parent_rate = do_div_round_closest(scaled_rate,
+   scaled_parent_rate = DIV_ROUND_CLOSEST_ULL(scaled_rate,
scaled_div);
} else  {
scaled_parent_rate = scale_rate(div, parent_rate);
@@ -743,7 +729,7 @@ static unsigned long clk_recalc_rate(struct ccu_data *ccu,
 * rate.
 */
scaled_div = divider_read_scaled(ccu, div);
-   result = do_div_round_closest(scaled_parent_rate, scaled_div);
+   result = DIV_ROUND_CLOSEST_ULL(scaled_parent_rate, scaled_div);
 
return (unsigned long)result;
 }
@@ -790,7 +776,7 @@ static long round_rate(struct ccu_data *ccu, struct 
bcm_clk_div *div,
scaled_rate = scale_rate(pre_div, parent_rate);
scaled_rate = scale_rate(div, scaled_rate);
scaled_pre_div = divider_read_scaled(ccu, pre_div);
-   scaled_parent_rate = do_div_round_closest(scaled_rate,
+   scaled_parent_rate = DIV_ROUND_CLOSEST_ULL(scaled_rate,
scaled_pre_div);
} else {
scaled_parent_rate = scale_rate(div, parent_rate);
@@ -802,7 +788,7 @@ static long round_rate(struct ccu_data *ccu, struct 
bcm_clk_div *div,
 * the best we can do.
 */
if (!divider_is_fixed(div)) {
-   best_scaled_div = do_div_round_closest(scaled_parent_rate,
+   best_scaled_div = DIV_ROUND_CLOSEST_ULL(scaled_parent_rate,
rate);
min_scaled_div = scaled_div_min(div);
max_scaled_div = scaled_div_max(div);
@@ -815,7 +801,7 @@ static long round_rate(struct ccu_data *ccu, struct 
bcm_clk_div *div,
}
 
/* OK, figure out the resulting rate */
-   result = do_div_round_closest(scaled_parent_rate, best_scaled_div);
+   result = DIV_ROUND_CLOSEST_ULL(scaled_parent_rate, best_scaled_div);
 
if (scaled_div)
*scaled_div = best_scaled_div;
diff --git a/drivers/clk/bcm/clk-kona.h b/drivers/clk/bcm/clk-kona.h
index 2537b3072910..6849a64baf6d 100644
--- a/drivers/clk/bcm/clk-kona.h
+++ b/drivers/clk/bcm/clk-kona.h
@@ -503,7 +503,6 @@ extern struct clk_ops kona_peri_clk_ops;
 
 /* Externally visible functions */
 
-extern u64 do_div_round_closest(u64 dividend, unsigned long divisor);
 extern u64 scaled_div_max(struct bcm_clk_div *div);
 extern u64 scaled_div_build(struct bcm_clk_div *div, u32 div_value,
u32 billionths);
-- 
1.9.1

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


Re: [Intel-gfx] [PATCH 1/4] kernel.h: Implement DIV_ROUND_CLOSEST_ULL

2015-03-23 Thread Javi Merino
On Fri, Mar 20, 2015 at 06:19:26PM +, Emil Velikov wrote:
 On 20 March 2015 at 11:14, Javi Merino javi.mer...@arm.com wrote:
  We have grown a number of different implementations of
  DIV_ROUND_CLOSEST_ULL throughout the kernel.  Move the i915 one to
  kernel.h so that it can be reused.
 
  Cc: Daniel Vetter daniel.vet...@intel.com
  Cc: Jani Nikula jani.nik...@linux.intel.com
  Cc: David Airlie airl...@linux.ie
  Cc: Darrick J. Wong djw...@us.ibm.com
  Cc: Guenter Roeck li...@roeck-us.net
  Cc: Andrew Morton a...@linux-foundation.org
  Signed-off-by: Javi Merino javi.mer...@arm.com
  ---
   drivers/gpu/drm/i915/intel_drv.h |  4 +---
   include/linux/kernel.h   | 11 +++
   2 files changed, 12 insertions(+), 3 deletions(-)
 
  diff --git a/drivers/gpu/drm/i915/intel_drv.h 
  b/drivers/gpu/drm/i915/intel_drv.h
  index eef79ccd0b7c..346e28fdd7dd 100644
  --- a/drivers/gpu/drm/i915/intel_drv.h
  +++ b/drivers/gpu/drm/i915/intel_drv.h
  @@ -28,6 +28,7 @@
   #include linux/async.h
   #include linux/i2c.h
   #include linux/hdmi.h
  +#include linux/kernel.h
 Hi Javi,
 
 Small suggestion - can we include the header only where needed ?
 i915/intel_panel.c seems to be the only user of DIV_ROUND_CLOSEST
 which will need an update.
 
 Somewhat trivial pick but it will prevent ~40 unnecessary dives in kernel.h.

Sure, I'll fix it in the next version of the series.

Cheers,
Javi

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


Re: [Intel-gfx] [PATCH 1/4] kernel.h: Implement DIV_ROUND_CLOSEST_ULL

2015-03-23 Thread Alex Elder
On 03/20/2015 06:14 AM, Javi Merino wrote:
 We have grown a number of different implementations of
 DIV_ROUND_CLOSEST_ULL throughout the kernel.  Move the i915 one to
 kernel.h so that it can be reused.
 
 Cc: Daniel Vetter daniel.vet...@intel.com
 Cc: Jani Nikula jani.nik...@linux.intel.com
 Cc: David Airlie airl...@linux.ie
 Cc: Darrick J. Wong djw...@us.ibm.com
 Cc: Guenter Roeck li...@roeck-us.net
 Cc: Andrew Morton a...@linux-foundation.org
 Signed-off-by: Javi Merino javi.mer...@arm.com
 ---
  drivers/gpu/drm/i915/intel_drv.h |  4 +---
  include/linux/kernel.h   | 11 +++
  2 files changed, 12 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_drv.h 
 b/drivers/gpu/drm/i915/intel_drv.h
 index eef79ccd0b7c..346e28fdd7dd 100644
 --- a/drivers/gpu/drm/i915/intel_drv.h
 +++ b/drivers/gpu/drm/i915/intel_drv.h
 @@ -28,6 +28,7 @@
  #include linux/async.h
  #include linux/i2c.h
  #include linux/hdmi.h
 +#include linux/kernel.h
  #include drm/i915_drm.h
  #include i915_drv.h
  #include drm/drm_crtc.h
 @@ -36,9 +37,6 @@
  #include drm/drm_dp_mst_helper.h
  #include drm/drm_rect.h
  
 -#define DIV_ROUND_CLOSEST_ULL(ll, d) \
 -({ unsigned long long _tmp = (ll)+(d)/2; do_div(_tmp, d); _tmp; })
 -
  /**
   * _wait_for - magic (register) wait macro
   *
 diff --git a/include/linux/kernel.h b/include/linux/kernel.h
 index d6d630d31ef3..f7d744e9d275 100644
 --- a/include/linux/kernel.h
 +++ b/include/linux/kernel.h
 @@ -103,6 +103,17 @@
   (((__x) - ((__d) / 2)) / (__d));\
  }\
  )
 +/*
 + * Same as above but for u64 dividends.  divisor must be a 32-bit
 + * number.
 + */
 +#define DIV_ROUND_CLOSEST_ULL(x, divisor)(   \
 +{\
 + unsigned long long _tmp = (x) + (divisor) / 2;  \
 + do_div(_tmp, divisor);  \
 + _tmp;   \
 +}\
 +)

Since you are stipulating the types of the arguments, this
should be defined as a static inline function instead.

DIV_ROUND_CLOSEST() could conceivably handle a 64-bit
dividend properly, although that macro is already a bit
hard to look at.

-Alex

  
  /*
   * Multiplies an integer by a fraction, while avoiding unnecessary
 

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


Re: [Intel-gfx] [PATCH 4/4] media: cxd2820r: use DIV_ROUND_CLOSEST_ULL()

2015-03-23 Thread Javi Merino
On Fri, Mar 20, 2015 at 01:51:36PM +, Alex Elder wrote:
 On 03/20/2015 06:14 AM, Javi Merino wrote:
  Now that the kernel provides DIV_ROUND_CLOSEST_ULL(), drop the internal
  implementation and use the kernel one.
  
  Cc: Antti Palosaari cr...@iki.fi
  Cc: Mauro Carvalho Chehab mche...@osg.samsung.com
  Signed-off-by: Javi Merino javi.mer...@arm.com
  ---
  I've only compile-tested it, I don't have the hardware to run it.
  
   drivers/media/dvb-frontends/cxd2820r_c.c| 2 +-
   drivers/media/dvb-frontends/cxd2820r_core.c | 6 --
   drivers/media/dvb-frontends/cxd2820r_priv.h | 2 --
   drivers/media/dvb-frontends/cxd2820r_t.c| 2 +-
   drivers/media/dvb-frontends/cxd2820r_t2.c   | 2 +-
   5 files changed, 3 insertions(+), 11 deletions(-)
  
  diff --git a/drivers/media/dvb-frontends/cxd2820r_c.c 
  b/drivers/media/dvb-frontends/cxd2820r_c.c
  index 149fdca3fb44..72b0e2db3aab 100644
  --- a/drivers/media/dvb-frontends/cxd2820r_c.c
  +++ b/drivers/media/dvb-frontends/cxd2820r_c.c
  @@ -79,7 +79,7 @@ int cxd2820r_set_frontend_c(struct dvb_frontend *fe)
   
  num = if_freq / 1000; /* Hz = kHz */
  num *= 0x4000;
  -   if_ctl = 0x4000 - cxd2820r_div_u64_round_closest(num, 41000);
  +   if_ctl = 0x4000 - DIV_ROUND_CLOSEST_ULL(num, 41000);
  buf[0] = (if_ctl  8)  0x3f;
  buf[1] = (if_ctl  0)  0xff;
   
  diff --git a/drivers/media/dvb-frontends/cxd2820r_core.c 
  b/drivers/media/dvb-frontends/cxd2820r_core.c
  index 422e84bbb008..490e090048ef 100644
  --- a/drivers/media/dvb-frontends/cxd2820r_core.c
  +++ b/drivers/media/dvb-frontends/cxd2820r_core.c
  @@ -244,12 +244,6 @@ error:
  return ret;
   }
   
  -/* 64 bit div with round closest, like DIV_ROUND_CLOSEST but 64 bit */
  -u32 cxd2820r_div_u64_round_closest(u64 dividend, u32 divisor)
  -{
  -   return div_u64(dividend + (divisor / 2), divisor);
  -}
 
 Technically, I'd say this has a bug, because the result
 needs to be 64 bits wide or your results might be much
 different from what might be desired.
 
 Practically though, I'm pretty sure all callers provide
 values that ensure the result is valid.

All the callers are substituted in this patch so we can make sure that
they are all correct.

 I only call attention because this patch changes the return
 type of the function that gets called to do the calculation.

I'm not sure I follow.  Do you mean that this:

if_ctl = 0x4000 - DIV_ROUND_CLOSEST_ULL(num, 41000);

Should actually be:

if_ctl = 0x4000 - (u32)DIV_ROUND_CLOSEST_ULL(num, 41000);

?

if_ctl is a u16 so I don't think you gain anything by doing that.

  -
   static int cxd2820r_set_frontend(struct dvb_frontend *fe)
   {
  struct cxd2820r_priv *priv = fe-demodulator_priv;
  diff --git a/drivers/media/dvb-frontends/cxd2820r_priv.h 
  b/drivers/media/dvb-frontends/cxd2820r_priv.h
  index 7ff5f60c83e1..4b428959b16e 100644
  --- a/drivers/media/dvb-frontends/cxd2820r_priv.h
  +++ b/drivers/media/dvb-frontends/cxd2820r_priv.h
  @@ -64,8 +64,6 @@ int cxd2820r_wr_reg_mask(struct cxd2820r_priv *priv, u32 
  reg, u8 val,
   int cxd2820r_wr_regs(struct cxd2820r_priv *priv, u32 reginfo, u8 *val,
  int len);
   
  -u32 cxd2820r_div_u64_round_closest(u64 dividend, u32 divisor);
  -
   int cxd2820r_wr_regs(struct cxd2820r_priv *priv, u32 reginfo, u8 *val,
  int len);
   
  diff --git a/drivers/media/dvb-frontends/cxd2820r_t.c 
  b/drivers/media/dvb-frontends/cxd2820r_t.c
  index 51401d036530..008cb2ac8480 100644
  --- a/drivers/media/dvb-frontends/cxd2820r_t.c
  +++ b/drivers/media/dvb-frontends/cxd2820r_t.c
  @@ -103,7 +103,7 @@ int cxd2820r_set_frontend_t(struct dvb_frontend *fe)
   
  num = if_freq / 1000; /* Hz = kHz */
  num *= 0x100;
  -   if_ctl = cxd2820r_div_u64_round_closest(num, 41000);
  +   if_ctl = DIV_ROUND_CLOSEST_ULL(num, 41000);

if_ctl is a u32, so you get the same behavior that you were getting
before: the downcasting of u64 to u32 happened in
cxd2820r_div_u64_round_closest(), now it happens here.

  buf[0] = ((if_ctl  16)  0xff);
  buf[1] = ((if_ctl   8)  0xff);
  buf[2] = ((if_ctl   0)  0xff);
  diff --git a/drivers/media/dvb-frontends/cxd2820r_t2.c 
  b/drivers/media/dvb-frontends/cxd2820r_t2.c
  index 9c0c4f42175c..35fe364c7182 100644
  --- a/drivers/media/dvb-frontends/cxd2820r_t2.c
  +++ b/drivers/media/dvb-frontends/cxd2820r_t2.c
  @@ -120,7 +120,7 @@ int cxd2820r_set_frontend_t2(struct dvb_frontend *fe)
   
  num = if_freq / 1000; /* Hz = kHz */
  num *= 0x100;
  -   if_ctl = cxd2820r_div_u64_round_closest(num, 41000);
  +   if_ctl = DIV_ROUND_CLOSEST_ULL(num, 41000);

Same here if_ctl is a u32.

Cheers,
Javi

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


[Intel-gfx] [PATCH 1/4] kernel.h: Implement DIV_ROUND_CLOSEST_ULL

2015-03-23 Thread Javi Merino
We have grown a number of different implementations of
DIV_ROUND_CLOSEST_ULL throughout the kernel.  Move the i915 one to
kernel.h so that it can be reused.

Cc: Daniel Vetter daniel.vet...@intel.com
Cc: Jani Nikula jani.nik...@linux.intel.com
Cc: David Airlie airl...@linux.ie
Cc: Darrick J. Wong djw...@us.ibm.com
Cc: Guenter Roeck li...@roeck-us.net
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Javi Merino javi.mer...@arm.com
---
 drivers/gpu/drm/i915/intel_drv.h |  4 +---
 include/linux/kernel.h   | 11 +++
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index eef79ccd0b7c..346e28fdd7dd 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -28,6 +28,7 @@
 #include linux/async.h
 #include linux/i2c.h
 #include linux/hdmi.h
+#include linux/kernel.h
 #include drm/i915_drm.h
 #include i915_drv.h
 #include drm/drm_crtc.h
@@ -36,9 +37,6 @@
 #include drm/drm_dp_mst_helper.h
 #include drm/drm_rect.h
 
-#define DIV_ROUND_CLOSEST_ULL(ll, d)   \
-({ unsigned long long _tmp = (ll)+(d)/2; do_div(_tmp, d); _tmp; })
-
 /**
  * _wait_for - magic (register) wait macro
  *
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index d6d630d31ef3..f7d744e9d275 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -103,6 +103,17 @@
(((__x) - ((__d) / 2)) / (__d));\
 }  \
 )
+/*
+ * Same as above but for u64 dividends.  divisor must be a 32-bit
+ * number.
+ */
+#define DIV_ROUND_CLOSEST_ULL(x, divisor)( \
+{  \
+   unsigned long long _tmp = (x) + (divisor) / 2;  \
+   do_div(_tmp, divisor);  \
+   _tmp;   \
+}  \
+)
 
 /*
  * Multiplies an integer by a fraction, while avoiding unnecessary
-- 
1.9.1

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


[Intel-gfx] [PATCH 3/4] cpuidle: menu: use DIV_ROUND_CLOSEST_ULL()

2015-03-23 Thread Javi Merino
Now that the kernel provides DIV_ROUND_CLOSEST_ULL(), drop the internal
implementation and use the kernel one.

Cc: Rafael J. Wysocki rafael.j.wyso...@intel.com
Cc: Mel Gorman mgor...@suse.de
Cc: Stephen Hemminger shemmin...@linux-foundation.org
Signed-off-by: Javi Merino javi.mer...@arm.com
---
 drivers/cpuidle/governors/menu.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index 40580794e23d..b8a5fa15ca24 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -190,12 +190,6 @@ static DEFINE_PER_CPU(struct menu_device, menu_devices);
 
 static void menu_update(struct cpuidle_driver *drv, struct cpuidle_device 
*dev);
 
-/* This implements DIV_ROUND_CLOSEST but avoids 64 bit division */
-static u64 div_round64(u64 dividend, u32 divisor)
-{
-   return div_u64(dividend + (divisor / 2), divisor);
-}
-
 /*
  * Try detecting repeating patterns by keeping track of the last 8
  * intervals, and checking if the standard deviation of that set
@@ -317,7 +311,7 @@ static int menu_select(struct cpuidle_driver *drv, struct 
cpuidle_device *dev)
 * operands are 32 bits.
 * Make sure to round up for half microseconds.
 */
-   data-predicted_us = div_round64((uint64_t)data-next_timer_us *
+   data-predicted_us = 
DIV_ROUND_CLOSEST_ULL((uint64_t)data-next_timer_us *
 data-correction_factor[data-bucket],
 RESOLUTION * DECAY);
 
-- 
1.9.1

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


[Intel-gfx] [PATCH 0/4] Consolidate DIV_ROUND_CLOSEST_ULL()

2015-03-23 Thread Javi Merino
The kernel has grown a number of different implementations of
DIV_ROUND_CLOSEST_ULL().  That is, a macro that does the same as
DIV_ROUND_CLOSEST() but with the first operand being an unsigned long
long.  That means that you have to do the division using do_div()
instead of using the C division operator '/'.

This series move the implementation in
drivers/gpu/drm/i915/intel_drv.h to linux/kernel.h and then removes
the other similar implementations of the same code in
drivers/clk/bcm/clk-kona.h, drivers/cpuidle/governors/menu.c and
drivers/media/dvb-frontends/cxd2820r_priv.h in favor of the one in
kernel.h

Javi Merino (4):
  kernel.h: Implement DIV_ROUND_CLOSEST_ULL
  clk: bcm/kona: use DIV_ROUND_CLOSEST_ULL()
  cpuidle: menu: use DIV_ROUND_CLOSEST_ULL()
  media: cxd2820r: use DIV_ROUND_CLOSEST_ULL()

 drivers/clk/bcm/clk-kona.c  | 28 +++-
 drivers/clk/bcm/clk-kona.h  |  1 -
 drivers/cpuidle/governors/menu.c|  8 +---
 drivers/gpu/drm/i915/intel_drv.h|  4 +---
 drivers/media/dvb-frontends/cxd2820r_c.c|  2 +-
 drivers/media/dvb-frontends/cxd2820r_core.c |  6 --
 drivers/media/dvb-frontends/cxd2820r_priv.h |  2 --
 drivers/media/dvb-frontends/cxd2820r_t.c|  2 +-
 drivers/media/dvb-frontends/cxd2820r_t2.c   |  2 +-
 include/linux/kernel.h  | 11 +++
 10 files changed, 23 insertions(+), 43 deletions(-)

-- 
1.9.1

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


Re: [Intel-gfx] [PATCH 03/49] drm/i915/bxt: Add IS_BROXTON macro

2015-03-23 Thread Sivakumar Thulasimani

Reviewed-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com

On 3/17/2015 3:09 PM, Imre Deak wrote:

From: Satheeshakrishna M satheeshakrishn...@intel.com

Adding IS_BROXTON macro for broxton specific implementation.

Signed-off-by: Satheeshakrishna M satheeshakrishn...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
  drivers/gpu/drm/i915/i915_drv.h | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 81f60b4..eba53c3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2305,6 +2305,7 @@ struct drm_i915_cmd_table {
  #define IS_HASWELL(dev)   (INTEL_INFO(dev)-is_haswell)
  #define IS_BROADWELL(dev) (!INTEL_INFO(dev)-is_valleyview  
IS_GEN8(dev))
  #define IS_SKYLAKE(dev)   (INTEL_INFO(dev)-is_skylake)
+#define IS_BROXTON(dev)(!INTEL_INFO(dev)-is_skylake  IS_GEN9(dev))
  #define IS_MOBILE(dev)(INTEL_INFO(dev)-is_mobile)
  #define IS_HSW_EARLY_SDV(dev) (IS_HASWELL(dev)  \
 (INTEL_DEVID(dev)  0xFF00) == 0x0C00)


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


[Intel-gfx] About gpu reset on gen8

2015-03-23 Thread Wang, Zhi A
Hi Gurus:
 I just noticed that gpu reset has been slightly changed on gen8. New 
registers: 20d0/120d0/220d0… named RESET_CTRL were introduced to issue a CS 
stop context switching ACK sequence(set bit 0 then polling bit 1) before 
issuing a engine reset. I’m wondering if full gpu reset also need this sequence 
or a full gpu reset has already covered this process…Anyone can teach me 
something? :)Thanks.
 
 Thanks,
 Zhi.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 7/7] drm/i915/skl: Take 90/270 rotation into account in watermark calculations

2015-03-23 Thread Daniel Vetter
On Mon, Mar 23, 2015 at 11:10:38AM +, Tvrtko Ursulin wrote:
 From: Tvrtko Ursulin tvrtko.ursu...@intel.com
 
 v2: Pass in rotation info to sprite plane updates as well.
 
 v3: Use helper to determine 90/270 rotation. (Michel Thierry)
 
 v4: Rebased for fb modifiers and atomic changes.
 
 For: VIZ-4546
 Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
 Reviewed-by: Michel Thierry michel.thie...@intel.com (v3)
 Reviewed-by: Joonas Lahtinen joonas.lahti...@linux.intel.com

Merged the entire series, thanks. I noticed though that we don't yet
expose 90/270 rotation to userspace, I guess that'll happen when the
tests/userspace are ready?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 7/7] drm/i915/skl: Take 90/270 rotation into account in watermark calculations

2015-03-23 Thread Tvrtko Ursulin


On 03/23/2015 02:12 PM, Daniel Vetter wrote:

On Mon, Mar 23, 2015 at 11:10:38AM +, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin tvrtko.ursu...@intel.com

v2: Pass in rotation info to sprite plane updates as well.

v3: Use helper to determine 90/270 rotation. (Michel Thierry)

v4: Rebased for fb modifiers and atomic changes.

For: VIZ-4546
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Reviewed-by: Michel Thierry michel.thie...@intel.com (v3)
Reviewed-by: Joonas Lahtinen joonas.lahti...@linux.intel.com


Merged the entire series, thanks. I noticed though that we don't yet
expose 90/270 rotation to userspace, I guess that'll happen when the
tests/userspace are ready?


Thank you!

And correct - Sonika has a patch series which needs to be rebased on top 
of this and which actually adds plane programming and exposes the plane 
properties. Plus kms_rotation_crc extensions of course.


Regards,

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


Re: [Intel-gfx] [PATCH 2/7] drm/i915: Use GGTT view when (un)pinning objects to planes

2015-03-23 Thread Daniel Vetter
On Mon, Mar 23, 2015 at 03:07:58PM +0200, Joonas Lahtinen wrote:
 On ma, 2015-03-23 at 11:10 +, Tvrtko Ursulin wrote:
  @@ -4214,15 +4217,16 @@ i915_gem_object_ggtt_pin(struct drm_i915_gem_object 
  *obj,
   }
   
   void
  -i915_gem_object_ggtt_unpin(struct drm_i915_gem_object *obj)
  +i915_gem_object_ggtt_unpin_view(struct drm_i915_gem_object *obj,
  +   const struct i915_ggtt_view *view)
   {
  -   struct i915_vma *vma = i915_gem_obj_to_ggtt(obj);
  +   struct i915_vma *vma = i915_gem_obj_to_ggtt_view(obj, view);
   
  BUG_ON(!vma);
  BUG_ON(vma-pin_count == 0);
  -   BUG_ON(!i915_gem_obj_ggtt_bound(obj));
  +   BUG_ON(!i915_gem_obj_ggtt_bound_view(obj, view-type));

Just an side: I really don't like BUG_ON since it kills machines and makes
debugging needlessly harder. If you run into them and it's not guaranteed
that the kernel will oops anyway please convert to WARN_ON. I've done that
while applying (and left the !vma check as-is since that's the only one
taht catches a real oops).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [git pull] drm fixes

2015-03-23 Thread Josh Boyer
On Fri, Mar 20, 2015 at 5:49 PM, Dave Airlie airl...@linux.ie wrote:

 Hi Linus,

 a bunch of fixes across drivers,
 radeon: disable two ended allocation for now, it breaks some stuff
 amdkfd: misc fixes
 nouveau: fix irq loop problem, add basic support for GM206 (new hw)
 i915: fix some WARNs people were seeing
 exynos: fix some iommu interactions causing boot failures

 In other news I've some problem with my git tree and git request-pull
 [airlied@dreadlord-bne-redhat-com linux]$ git request-pull linus/master origin
 warn: No match for commit 8265d4486d5c2448a1c645fdc20d4e62873d9c3d found at 
 origin
 warn: Are you sure you pushed 'HEAD' there?

 is happening when I just had my branch on drm-fixes, I've made it master
 to generate this pull request so the branch name isn't missing, this
 might be due to my attempt to remove my own master branch, using
 git symbolic-ref HEAD refs/heads/drm-next, so I'll have to regen it next
 week I suppose.

snip


 Damien Lespiau (1):
   drm/i915: Make sure the primary plane is enabled before reading out the 
 fb state

 Xi Ruoyao (1):
   drm/i915: Ensure plane-state-fb stays in sync with plane-fb

I have a machine that no longer boots in a headless manner with -rc5.
It's an Celeron based NUC device.  I blacklisted the i915 driver and
it boots fine, then I ran insmod manually and got the backtrace below.
This machine only has HDMI output on it.  If I have it connected (even
if the monitor is set to display some other input) it will boot fine,
but the backtrace is still present.  I'm going to guess the machine
hangs in headless because X causes some further issues in the
headless case.

Linux v4.0-rc4-199-gb314acaccd7e gets this splat in the headless state:

[  +0.39] WARNING: CPU: 0 PID: 63 at
drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object+0x2e5/0x320
[i915]()
[  +0.02] WARN_ON(obj-frontbuffer_bits)

which is what I thought one of these commits was supposed to fix.  I
don't see that in -rc5, but then we have these other issues.

josh

Backtrace via 'insmod i915.ko.xz' in headless state with 4.0-rc5:

[  +0.063764] vgaarb: device changed decodes:
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[  +0.007099] [ cut here ]
[  +0.37] WARNING: CPU: 1 PID: 1486 at include/linux/kref.h:47
drm_framebuffer_reference+0x7a/0x90 [drm]()
[  +0.03] Modules linked in: i915(+) ip6t_rpfilter ip6t_REJECT
nf_reject_ipv6 xt_conntrack bnep iTCO_wdt iTCO_vendor_support
ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
ip6table_mangle ip6table_security ip6table_raw ip6table_filter
ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw arc4
iwlmvm mac80211 intel_rapl coretemp kvm_intel kvm iwlwifi btusb
bluetooth i2c_algo_bit cfg80211 drm_kms_helper crct10dif_pclmul
snd_hda_codec_hdmi crc32_pclmul crc32c_intel ghash_clmulni_intel
snd_hda_codec_realtek vfat snd_hda_codec_generic snd_intel_sst_acpi
fat serio_raw snd_intel_sst_core snd_hda_intel i2c_i801 drm
snd_soc_sst_mfld_platform snd_hda_controller
[  +0.46]  r8169 lpc_ich snd_soc_rt5640 snd_hda_codec mfd_core
snd_soc_rl6231 mii mei_txe ir_lirc_codec ir_xmp_decoder
ir_mce_kbd_decoder lirc_dev snd_soc_core ir_sharp_decoder shpchp
ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder mei ir_rc6_decoder
ir_rc5_decoder ir_nec_decoder snd_compress snd_pcm_dmaengine snd_hwdep
snd_seq snd_seq_device iosf_mbi rc_rc6_mce snd_pcm ite_cir snd_timer
rc_core dw_dmac snd dw_dmac_core regmap_i2c i2c_hid
i2c_designware_platform soundcore rfkill_gpio i2c_designware_core
rfkill snd_soc_sst_acpi nfsd auth_rpcgss nfs_acl lockd grace sunrpc
sdhci_acpi video sdhci mmc_core
[  +0.51] CPU: 1 PID: 1486 Comm: insmod Not tainted
4.0.0-0.rc5.git0.1.fc23.x86_64 #1
[  +0.04] Hardware name:
\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x
\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x/DN2820FYK,
BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
[  +0.03]   ee312e2f 8800b7e03688
8177ac09
[  +0.04]    8800b7e036c8
8109c78a
[  +0.04]  8800b7e036b8 880234b46d80 880228ef4f00
88021a54
[  +0.05] Call Trace:
[  +0.09]  [8177ac09] dump_stack+0x45/0x57
[  +0.06]  

Re: [Intel-gfx] drm/i915: Track GEN6 page table usage

2015-03-23 Thread Dan Carpenter
Hello Ben Widawsky,

The patch 678d96fbb3b5: drm/i915: Track GEN6 page table usage from
Mar 16, 2015, leads to the following static checker warning:

drivers/gpu/drm/i915/i915_gem_gtt.c:363 alloc_pt_single()
error: passing non negative 1 to ERR_PTR

drivers/gpu/drm/i915/i915_gem_gtt.c
   292  
   293  /**
   294   * i915_dma_map_single() - Create a dma mapping for a page 
table/dir/etc.
   295   * @px: Page table/dir/etc to get a DMA map for
   296   * @dev:drm device
   297   *
   298   * Page table allocations are unified across all gens. They always 
require a
   299   * single 4k allocation, as well as a DMA mapping. If we keep the 
structs
   300   * symmetric here, the simple macro covers us for every page table type.
   301   *
   302   * Return: 0 if success.
   303   */
   304  #define i915_dma_map_single(px, dev) \
   305  i915_dma_map_page_single((px)-page, (dev), (px)-daddr)
   306  
   307  static inline int i915_dma_map_page_single(struct page *page,
   308 struct drm_device *dev,
   309 dma_addr_t *daddr)
   310  {
   311  struct device *device = dev-pdev-dev;
   312  
   313  *daddr = dma_map_page(device, page, 0, 4096, 
PCI_DMA_BIDIRECTIONAL);
   314  return dma_mapping_error(device, *daddr);
   ^
This function returns 1 on failure but the callers expect a negative
error code.

   315  }

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


Re: [Intel-gfx] drm/i915: Initialize all contexts

2015-03-23 Thread Dan Carpenter
Hello Ben Widawsky,

This is a semi-automatic email about new static checker warnings.

The patch 6702cf16e0ba: drm/i915: Initialize all contexts from Mar 
16, 2015, leads to the following Smatch complaint:

drivers/gpu/drm/i915/i915_gem_context.c:730 do_switch()
 error: we previously assumed 'to-ppgtt' could be null (see line 713)

drivers/gpu/drm/i915/i915_gem_context.c
   712   * occur when this occurs. */
   713  } else if (to-ppgtt 
   ^
Patch introduces a new NULL check.

   714  test_and_clear_bit(ring-id, 
to-ppgtt-pd_dirty_rings))
   715  hw_flags |= MI_FORCE_RESTORE;
   716  
   717  /* We should never emit switch_mm more than once */
   718  WARN_ON(needs_pd_load_pre(ring, to) 
   719  needs_pd_load_post(ring, to, hw_flags));
   720  
   721  ret = mi_set_context(ring, to, hw_flags);
   722  if (ret)
   723  goto unpin_out;
   724  
   725  /* GEN8 does *not* require an explicit reload if the PDPs have 
been
   726   * setup, and we do not wish to move them.
   727   */
   728  if (needs_pd_load_post(ring, to, hw_flags)) {
   729  trace_switch_mm(ring, to);
   730  ret = to-ppgtt-switch_mm(to-ppgtt, ring);
  ^^^
Existing unchecked dereference.

   731  /* The hardware context switch is emitted, but we 
haven't
   732   * actually changed the state - so it's probably safe 
to bail

regards,
dan carpenter
___
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: eDP DRRS limited to only one panel at a time

2015-03-23 Thread Ramalingam C

Hi Siva,

Since the same structure will be used to implement DRRS on DSI also we 
have placed it at i915_dev_priv.

I am working on the RFC for the DRRS on DSI.

On Tuesday 24 March 2015 07:33 AM, Sivakumar Thulasimani wrote:
since drrs struct is used primarily in intel_dp.c file alone can it be 
moved to intel_dp ?


On 3/23/2015 11:12 PM, Ramalingam C wrote:

In case of multiple eDP panels, only one can have
the DRRS enabled on it.

In future eDP DRRS will be extended for multiple panels.

Signed-off-by: Ramalingam C ramalinga...@intel.com
---
  drivers/gpu/drm/i915/intel_dp.c |5 +
  1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c 
b/drivers/gpu/drm/i915/intel_dp.c

index 0b26df9..ec40d19 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5311,6 +5311,11 @@ intel_dp_drrs_init(struct intel_connector 
*intel_connector,

  return NULL;
  }
  +if (dev_priv-drrs.type == SEAMLESS_DRRS_SUPPORT) {
+DRM_DEBUG_KMS(DRRS already enabled on previous connector\n);
+return NULL;
+}
+
  INIT_DELAYED_WORK(dev_priv-drrs.work, 
intel_edp_drrs_downclock_work);

mutex_init(dev_priv-drrs.mutex);




--
Ram

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


Re: [Intel-gfx] [PATCH] drm/i915/skl: Enabling PSR2 SU with frame sync

2015-03-23 Thread Vivi, Rodrigo
On Mon, 2015-03-23 at 10:14 +0100, Daniel Vetter wrote:
 On Fri, Mar 20, 2015 at 11:26:19PM +, Vivi, Rodrigo wrote:
  Hi Sonika,
  
  on the previous email I forgot to tell that we also need to add
  somewhere a check to avoid PSR for resolutions bigger than 3200x2000.
  
  Although most of displays that we have that support psr are 3200x1800 it
  is better to think a way to protect now than later.
 
 Is that a restriction just for PSR2 (because the hw doesn't have more
 space for line checksums) or also for the existing PSR code? If it's just
 for PSR2 we can easily extend the check Sonika is adding in this patch to
 also check for that and it's all done.

Spec just list this limitation on PSR2.

 -Daniel
 
  
  Thanks,
  Rodrigo.
  
  On Fri, 2015-03-20 at 11:27 +0530, Sonika Jindal wrote:
   We make use of HW tracking for Selective update region and enable frame 
   sync on
   sink. We use hardware's hardcoded data values for frame sync and GTC.
   
   Signed-off-by: Sonika Jindal sonika.jin...@intel.com
   ---
drivers/gpu/drm/i915/i915_reg.h  |   14 ++
drivers/gpu/drm/i915/intel_dp.c  |   16 
drivers/gpu/drm/i915/intel_drv.h |2 ++
drivers/gpu/drm/i915/intel_psr.c |   30 +-
4 files changed, 61 insertions(+), 1 deletion(-)
   
   diff --git a/drivers/gpu/drm/i915/i915_reg.h 
   b/drivers/gpu/drm/i915/i915_reg.h
   index 5b84ee6..7e4f6f0 100644
   --- a/drivers/gpu/drm/i915/i915_reg.h
   +++ b/drivers/gpu/drm/i915/i915_reg.h
   @@ -2745,6 +2745,20 @@ enum skl_disp_power_wells {
#define   EDP_PSR_DEBUG_MASK_MEMUP   (126)
#define   EDP_PSR_DEBUG_MASK_HPD (125)

   +#define EDP_PSR2_CTL 0x6f900
   +#define   EDP_PSR2_ENABLE(131)
   +#define   EDP_SU_TRACK_ENABLE(130)
   +#define   EDP_MAX_SU_DISABLE_TIME(t) ((t)20)
   +#define   EDP_MAX_SU_DISABLE_TIME_MASK   (0x1f20)
   +#define   EDP_PSR2_TP2_TIME_500  (08)
   +#define   EDP_PSR2_TP2_TIME_100  (18)
   +#define   EDP_PSR2_TP2_TIME_250  (28)
   +#define   EDP_PSR2_TP2_TIME_50   (38)
   +#define   EDP_PSR2_TP2_TIME_MASK (38)
   +#define   EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
   +#define   EDP_PSR2_FRAME_BEFORE_SU_MASK  (0xf4)
   +#define   EDP_PSR2_IDLE_MASK 0xf
   +
/* VGA port control */
#define ADPA 0x61100
#define PCH_ADPA0xe1100
   diff --git a/drivers/gpu/drm/i915/intel_dp.c 
   b/drivers/gpu/drm/i915/intel_dp.c
   index 3967af1..dedd8ad 100644
   --- a/drivers/gpu/drm/i915/intel_dp.c
   +++ b/drivers/gpu/drm/i915/intel_dp.c
   @@ -3786,6 +3786,22 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
 dev_priv-psr.sink_support = true;
 DRM_DEBUG_KMS(Detected EDP PSR Panel.\n);
 }
   +
   + if (INTEL_INFO(dev)-gen = 9 
   + (intel_dp-psr_dpcd[0]  DP_PSR2_IS_SUPPORTED)) {
   + uint8_t frame_sync_cap;
   +
   + dev_priv-psr.sink_support = true;
   + intel_dp_dpcd_read_wake(intel_dp-aux,
   + DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
   + frame_sync_cap, 1);
   + /* PSR2 needs frame sync as well */
   + if (frame_sync_cap) {
   + DRM_DEBUG_KMS(PSR2 supported on sink);
   + intel_dp-psr2_support = true;
   + } else
   + intel_dp-psr2_support = false;
   + }
 }

 /* Training Pattern 3 support, both source and sink */
   diff --git a/drivers/gpu/drm/i915/intel_drv.h 
   b/drivers/gpu/drm/i915/intel_drv.h
   index 8bb18e5..ed1b0a5 100644
   --- a/drivers/gpu/drm/i915/intel_drv.h
   +++ b/drivers/gpu/drm/i915/intel_drv.h
   @@ -663,6 +663,8 @@ struct intel_dp {
 struct intel_dp_mst_encoder *mst_encoders[I915_MAX_PIPES];
 struct drm_dp_mst_topology_mgr mst_mgr;

   + bool psr2_support;
   +
 uint32_t (*get_aux_clock_divider)(struct intel_dp *dp, int index);
 /*
  * This function returns the value we have to program the AUX_CTL
   diff --git a/drivers/gpu/drm/i915/intel_psr.c 
   b/drivers/gpu/drm/i915/intel_psr.c
   index b9f40c2..99dbc73 100644
   --- a/drivers/gpu/drm/i915/intel_psr.c
   +++ b/drivers/gpu/drm/i915/intel_psr.c
   @@ -117,6 +117,19 @@ static void vlv_psr_setup_vsc(struct intel_dp 
   *intel_dp)
 I915_WRITE(VLV_VSCSDP(pipe), val);
}

   +static void skl_psr_setup_su_vsc(struct intel_dp *intel_dp)
   +{
   + struct edp_vsc_psr psr_vsc;
   +
   + /* Prepare VSC Header for SU as per EDP 1.4 spec, Table 6.11 */
   + memset(psr_vsc, 0, sizeof(psr_vsc));
   + psr_vsc.sdp_header.HB0 = 0;
   + psr_vsc.sdp_header.HB1 = 0x7;
   + psr_vsc.sdp_header.HB2 = 0x3;
   + psr_vsc.sdp_header.HB3 = 0xb;
   + intel_psr_write_vsc(intel_dp, psr_vsc);
   +}
   +
static void 

[Intel-gfx] [PATCH] drm/i915: make unsupported fb modifier message DRM_DEBUG

2015-03-23 Thread Jesse Barnes
Or users can just spam the log all they want.

References: https://bugs.freedesktop.org/show_bug.cgi?id=89628
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
 drivers/gpu/drm/i915/intel_display.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 589addf..c48e2d7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12831,8 +12831,8 @@ static int intel_framebuffer_init(struct drm_device 
*dev,
case I915_FORMAT_MOD_X_TILED:
break;
default:
-   DRM_ERROR(Unsupported fb modifier 0x%llx!\n,
-   mode_cmd-modifier[0]);
+   DRM_DEBUG(Unsupported fb modifier 0x%llx!\n,
+ mode_cmd-modifier[0]);
return -EINVAL;
}
 
-- 
1.9.1

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


Re: [Intel-gfx] [PATCH 2/5] drm/i915: Re-adjusting rc6 promotional timer for chv

2015-03-23 Thread Paulo Zanoni
2015-02-26 12:16 GMT-03:00  deepa...@linux.intel.com:
 From: Deepak S deepa...@linux.intel.com

 After feedback from the hardware team we are changing the RC6
 promotional timer to increase the power saving without
 changing performance.

I can't really say whether this is really what we want since I didn't
do any measurements, but the patch seems to do what it says, so:
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com


 Signed-off-by: Deepak S deepa...@linux.intel.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 7dcb5b6..90cb6c9 100644
 --- a/drivers/gpu/drm/i915/intel_pm.c
 +++ b/drivers/gpu/drm/i915/intel_pm.c
 @@ -4799,8 +4799,8 @@ static void cherryview_enable_rps(struct drm_device 
 *dev)
 I915_WRITE(RING_MAX_IDLE(ring-mmio_base), 10);
 I915_WRITE(GEN6_RC_SLEEP, 0);

 -   /* TO threshold set to 1750 us ( 0x557 * 1.28 us) */
 -   I915_WRITE(GEN6_RC6_THRESHOLD, 0x557);
 +   /* TO threshold set to 500 us ( 0x186 * 1.28 us) */
 +   I915_WRITE(GEN6_RC6_THRESHOLD, 0x186);

 /* allows RC6 residency counter to work */
 I915_WRITE(VLV_COUNTER_CONTROL,
 --
 1.9.1

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



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


Re: [Intel-gfx] [PATCH 7/7] drm/i915: Enable PSR by default.

2015-03-23 Thread Rodrigo Vivi
Hi Daniel,

Is something missing to enable it by default?

Thanks,
Rodrigo.

On Sun, Mar 15, 2015 at 10:31 PM, R, Durgadoss durgados...@intel.com wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Rodrigo Vivi
Sent: Saturday, February 28, 2015 6:56 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 7/7] drm/i915: Enable PSR by default.

With a reliable frontbuffer tracking and all instability corner cases solved
let's re-enabled PSR by default on all supported platforms.


 Finally ;)

 Reviewed-by: Durgadoss R durgados...@intel.com

 Thanks,
 Durga

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

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 44f2262..2c1a90e 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -38,7 +38,7 @@ struct i915_params i915 __read_mostly = {
   .enable_execlists = -1,
   .enable_hangcheck = true,
   .enable_ppgtt = -1,
-  .enable_psr = 0,
+  .enable_psr = 1,
   .preliminary_hw_support = 
 IS_ENABLED(CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT),
   .disable_power_well = 1,
   .enable_ips = 1,
@@ -127,7 +127,7 @@ MODULE_PARM_DESC(enable_execlists,
   (-1=auto [default], 0=disabled, 1=enabled));

 module_param_named(enable_psr, i915.enable_psr, int, 0600);
-MODULE_PARM_DESC(enable_psr, Enable PSR (default: false));
+MODULE_PARM_DESC(enable_psr, Enable PSR (default: true));

 module_param_named(preliminary_hw_support, i915.preliminary_hw_support, int, 
 0600);
 MODULE_PARM_DESC(preliminary_hw_support,
--
1.9.3

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



-- 
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] commit 319c1d420a0b (Ensure plane-state-fb stays in sync with plane-fb) cause various errors

2015-03-23 Thread Jani Nikula

[adding more people and intel-gfx, original message with backtrace at
http://mid.gmane.org/550eed22.9070...@gmail.com]

On Mon, 23 Mar 2015, François Valenduc francoisvalen...@gmail.com wrote:
 Le 23/03/15 09:52, Jani Nikula a écrit :
 On Sun, 22 Mar 2015, François Valenduc francoisvalen...@gmail.com wrote:
 It seems commit 7ce42ae67c49204c0b2252edd06f7920e0a51037 causes
 several errors.
 It seems I don't have this commit. Which tree is this?

 I also admit to being pretty bad at associating commit ids with the
 actual commits, especially so for commit ids I don't have. It would be
 helpful to include the title of the commit too. ;)

 BR,
 Jani.


 Sorry, the id I gave was the one of the revert I made in my local tree.
 The problematic commit is the following:

 commit 319c1d420a0b62d9dbb88104afebaabc968cdbfa
 Author: Xi Ruoyao xry...@outlook.com
 Date:   Thu Mar 12 20:16:32 2015 +0800

 drm/i915: Ensure plane-state-fb stays in sync with plane-fb

 This is a commit which has been merged in the mainline kernel tree
 between 4.0-rc4 and 4.0-rc5.


 Sincerely yours,

 François Valenduc

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


Re: [Intel-gfx] [PATCH v4] drm/i915: Optimistically spin for the request completion

2015-03-23 Thread Daniel Vetter
On Fri, Mar 20, 2015 at 04:31:29PM +, Tvrtko Ursulin wrote:
 
 On 03/20/2015 04:19 PM, Chris Wilson wrote:
 On Fri, Mar 20, 2015 at 04:01:52PM +, Tvrtko Ursulin wrote:
 
 On 03/20/2015 02:36 PM, Chris Wilson wrote:
 This provides a nice boost to mesa in swap bound scenarios (as mesa
 throttles itself to the previous frame and given the scenario that will
 complete shortly). It will also provide a good boost to systems running
 with semaphores disabled and so frequently waiting on the GPU as it
 switches rings. In the most favourable of microbenchmarks, this can
 increase performance by around 15% - though in practice improvements
 will be marginal and rarely noticeable.
 
 v2: Account for user timeouts
 v3: Limit the spinning to a single jiffie (~1us) at most. On an
 otherwise idle system, there is no scheduler contention and so without a
 limit we would spin until the GPU is ready.
 v4: Drop forcewake - the lazy coherent access doesn't require it, and we
 have no reason to believe that the forcewake itself improves seqno
 coherency - it only adds delay.
 
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Cc: Daniel Vetter daniel.vet...@ffwll.ch
 Cc: Tvrtko Ursulin tvrtko.ursu...@linux.intel.com
 Cc: Eero Tamminen eero.t.tammi...@intel.com
 Cc: Rantala, Valtteri valtteri.rant...@intel.com
 
 Still against a toggle switch like a simple module parameter?
 
 Yes. I'd much rather tackle the corner cases than ignore them.
 
 I'll say it once more then leave it be - my point of view is that module
 param does not mean ignoring any issues. It rather means that, if
 pathological use case if found in the field, you can provide a better user
 experience and then work in parallel in coming with improvements.
 
 Your view is probably that if there is a toggle, someone somewhere will put
 on some wiki yeah if that happens just put this in modprobe.conf and there
 won't even be a bug report.

This is generally what indeed happens. We've suffered for years from
google returning outdated wiki pages with clever suggestions ...

Nowadays all mod params are generally of the kernel tainting kind to
increase the odds that we get bug reports. I still don't really like them.

 It is a downside yes, but to me much better than finding a bad corner case
 and then saying Yeah, please recompile your kernel, or downgrade your
 kernel and wait for X weeks/months until the fix propagates.

I agree but only for stuff that causes crashes and hangs. There a module
option makes sense for quicker debug. For general tuning I don't really
want them - the kernel should get things right, period.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] tests/kms_psr_sink_crc: Make render visible to human eyes

2015-03-23 Thread Daniel Vetter
On Mon, Mar 23, 2015 at 09:35:27AM +0100, Daniel Vetter wrote:
 On Fri, Mar 20, 2015 at 05:43:40PM +, Vivi, Rodrigo wrote:
  On Fri, 2015-03-20 at 10:54 +0100, Daniel Vetter wrote:
   On Thu, Mar 19, 2015 at 06:24:24PM -0700, Rodrigo Vivi wrote:
This will allow manual tests when crc isn't available.

v2: Remove unused and non-sense buf-size and decrease buf-stride a 
bit as suggested by Daniel.
   
   buf-size isn't nonsense really, it does seem to match what we've
   allocated. But it also seems unused in the rendercpy functions I've
   checked. Imo you should keep that line
  
  oh sure, bad phrase the value 4 was nonsense.
  But if I increases that it fails. Without setting it works.
  What do you think?
 
 If just keeping that line makes the test work there's something _really_
 fishy going on. If it persists after git clean -dfx and full recompile I'd
 dig into it, since this really doesn't make sense.

valgrined might be the best tool for a first attempt at figuring out
what's wrong.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Keep ring-active_list and ring-requests_list consistent

2015-03-23 Thread Daniel Vetter
On Wed, Mar 18, 2015 at 06:19:22PM +, Chris Wilson wrote:
 If we retire requests last, we may use a later seqno and so clear
 the requests lists without clearing the active list, leading to
 confusion. Hence we should retire requests first for consistency with
 the early return. The order used to be important as the lifecycle for
 the object on the active list was determined by request-seqno. However,
 the requests themselves are now reference counted removing the
 constraint from the order of retirement.
 
 Fixes regression from
 
 commit 1b5a433a4dd967b125131da42b89b5cc0d5b1f57
 Author: John Harrison john.c.harri...@intel.com
 Date:   Mon Nov 24 18:49:42 2014 +
 
 drm/i915: Convert 'i915_seqno_passed' calls into 
 'i915_gem_request_completed
 '
 
 and a
 
   WARNING: CPU: 0 PID: 1383 at drivers/gpu/drm/i915/i915_gem_evict.c:279 
 i915_gem_evict_vm+0x10c/0x140()
   WARN_ON(!list_empty(vm-active_list))
 
 Identified by updating WATCH_LISTS:
 
   [drm:i915_verify_lists] *ERROR* blitter ring: active list not empty, 
 but no requests
   WARNING: CPU: 0 PID: 681 at drivers/gpu/drm/i915/i915_gem.c:2751 
 i915_gem_retire_requests_ring+0x149/0x230()
   WARN_ON(i915_verify_lists(ring-dev))
 
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Cc: John Harrison john.c.harri...@intel.com
 Cc: Daniel Vetter daniel.vet...@ffwll.ch

In case it's burried too much in the thread:

Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch

Addadendum for the commit:

Note that this is only a problem in evict_vm where the following happens
after a retire_request has cleaned out all requests, but not all active
bo:
- intel_ring_idle called from i915_gpu_idle notices that no requests are
  outstanding and immediately returns.
- i915_gem_retire_requests_ring called from i915_gem_retire_requests also
  immediately returns when there's no request, still leaving the bo on the
  active list.
- evict_vm hits the WARN_ON(!list_empty(vm-active_list)) after evicting
  all active objects that there's still stuff left that shouldn't be
  there.

Chris, is that an accurate enough description for Jani to add to the
patch?
-Daniel
 ---
  drivers/gpu/drm/i915/i915_gem.c | 38 +-
  1 file changed, 21 insertions(+), 17 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
 index 092f25cfb8d5..7a9589f38bbc 100644
 --- a/drivers/gpu/drm/i915/i915_gem.c
 +++ b/drivers/gpu/drm/i915/i915_gem.c
 @@ -2660,24 +2660,11 @@ i915_gem_retire_requests_ring(struct intel_engine_cs 
 *ring)
  
   WARN_ON(i915_verify_lists(ring-dev));
  
 - /* Move any buffers on the active list that are no longer referenced
 -  * by the ringbuffer to the flushing/inactive lists as appropriate,
 -  * before we free the context associated with the requests.
 + /* Retire requests first as we use it above for the early return.
 +  * If we retire requests last, we may use a later seqno and so clear
 +  * the requests lists without clearing the active list, leading to
 +  * confusion.
*/
 - while (!list_empty(ring-active_list)) {
 - struct drm_i915_gem_object *obj;
 -
 - obj = list_first_entry(ring-active_list,
 -   struct drm_i915_gem_object,
 -   ring_list);
 -
 - if (!i915_gem_request_completed(obj-last_read_req, true))
 - break;
 -
 - i915_gem_object_move_to_inactive(obj);
 - }
 -
 -
   while (!list_empty(ring-request_list)) {
   struct drm_i915_gem_request *request;
  
 @@ -2700,6 +2687,23 @@ i915_gem_retire_requests_ring(struct intel_engine_cs 
 *ring)
   i915_gem_free_request(request);
   }
  
 + /* Move any buffers on the active list that are no longer referenced
 +  * by the ringbuffer to the flushing/inactive lists as appropriate,
 +  * before we free the context associated with the requests.
 +  */
 + while (!list_empty(ring-active_list)) {
 + struct drm_i915_gem_object *obj;
 +
 + obj = list_first_entry(ring-active_list,
 +   struct drm_i915_gem_object,
 +   ring_list);
 +
 + if (!i915_gem_request_completed(obj-last_read_req, true))
 + break;
 +
 + i915_gem_object_move_to_inactive(obj);
 + }
 +
   if (unlikely(ring-trace_irq_req 
i915_gem_request_completed(ring-trace_irq_req, true))) {
   ring-irq_put(ring);
 -- 
 2.1.4
 

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


Re: [Intel-gfx] [PATCH] drm/i915/skl: Enabling PSR2 SU with frame sync

2015-03-23 Thread Daniel Vetter
On Fri, Mar 20, 2015 at 11:26:19PM +, Vivi, Rodrigo wrote:
 Hi Sonika,
 
 on the previous email I forgot to tell that we also need to add
 somewhere a check to avoid PSR for resolutions bigger than 3200x2000.
 
 Although most of displays that we have that support psr are 3200x1800 it
 is better to think a way to protect now than later.

Is that a restriction just for PSR2 (because the hw doesn't have more
space for line checksums) or also for the existing PSR code? If it's just
for PSR2 we can easily extend the check Sonika is adding in this patch to
also check for that and it's all done.
-Daniel

 
 Thanks,
 Rodrigo.
 
 On Fri, 2015-03-20 at 11:27 +0530, Sonika Jindal wrote:
  We make use of HW tracking for Selective update region and enable frame 
  sync on
  sink. We use hardware's hardcoded data values for frame sync and GTC.
  
  Signed-off-by: Sonika Jindal sonika.jin...@intel.com
  ---
   drivers/gpu/drm/i915/i915_reg.h  |   14 ++
   drivers/gpu/drm/i915/intel_dp.c  |   16 
   drivers/gpu/drm/i915/intel_drv.h |2 ++
   drivers/gpu/drm/i915/intel_psr.c |   30 +-
   4 files changed, 61 insertions(+), 1 deletion(-)
  
  diff --git a/drivers/gpu/drm/i915/i915_reg.h 
  b/drivers/gpu/drm/i915/i915_reg.h
  index 5b84ee6..7e4f6f0 100644
  --- a/drivers/gpu/drm/i915/i915_reg.h
  +++ b/drivers/gpu/drm/i915/i915_reg.h
  @@ -2745,6 +2745,20 @@ enum skl_disp_power_wells {
   #define   EDP_PSR_DEBUG_MASK_MEMUP (126)
   #define   EDP_PSR_DEBUG_MASK_HPD   (125)
   
  +#define EDP_PSR2_CTL   0x6f900
  +#define   EDP_PSR2_ENABLE  (131)
  +#define   EDP_SU_TRACK_ENABLE  (130)
  +#define   EDP_MAX_SU_DISABLE_TIME(t)   ((t)20)
  +#define   EDP_MAX_SU_DISABLE_TIME_MASK (0x1f20)
  +#define   EDP_PSR2_TP2_TIME_500(08)
  +#define   EDP_PSR2_TP2_TIME_100(18)
  +#define   EDP_PSR2_TP2_TIME_250(28)
  +#define   EDP_PSR2_TP2_TIME_50 (38)
  +#define   EDP_PSR2_TP2_TIME_MASK   (38)
  +#define   EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
  +#define   EDP_PSR2_FRAME_BEFORE_SU_MASK(0xf4)
  +#define   EDP_PSR2_IDLE_MASK   0xf
  +
   /* VGA port control */
   #define ADPA   0x61100
   #define PCH_ADPA0xe1100
  diff --git a/drivers/gpu/drm/i915/intel_dp.c 
  b/drivers/gpu/drm/i915/intel_dp.c
  index 3967af1..dedd8ad 100644
  --- a/drivers/gpu/drm/i915/intel_dp.c
  +++ b/drivers/gpu/drm/i915/intel_dp.c
  @@ -3786,6 +3786,22 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
  dev_priv-psr.sink_support = true;
  DRM_DEBUG_KMS(Detected EDP PSR Panel.\n);
  }
  +
  +   if (INTEL_INFO(dev)-gen = 9 
  +   (intel_dp-psr_dpcd[0]  DP_PSR2_IS_SUPPORTED)) {
  +   uint8_t frame_sync_cap;
  +
  +   dev_priv-psr.sink_support = true;
  +   intel_dp_dpcd_read_wake(intel_dp-aux,
  +   DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
  +   frame_sync_cap, 1);
  +   /* PSR2 needs frame sync as well */
  +   if (frame_sync_cap) {
  +   DRM_DEBUG_KMS(PSR2 supported on sink);
  +   intel_dp-psr2_support = true;
  +   } else
  +   intel_dp-psr2_support = false;
  +   }
  }
   
  /* Training Pattern 3 support, both source and sink */
  diff --git a/drivers/gpu/drm/i915/intel_drv.h 
  b/drivers/gpu/drm/i915/intel_drv.h
  index 8bb18e5..ed1b0a5 100644
  --- a/drivers/gpu/drm/i915/intel_drv.h
  +++ b/drivers/gpu/drm/i915/intel_drv.h
  @@ -663,6 +663,8 @@ struct intel_dp {
  struct intel_dp_mst_encoder *mst_encoders[I915_MAX_PIPES];
  struct drm_dp_mst_topology_mgr mst_mgr;
   
  +   bool psr2_support;
  +
  uint32_t (*get_aux_clock_divider)(struct intel_dp *dp, int index);
  /*
   * This function returns the value we have to program the AUX_CTL
  diff --git a/drivers/gpu/drm/i915/intel_psr.c 
  b/drivers/gpu/drm/i915/intel_psr.c
  index b9f40c2..99dbc73 100644
  --- a/drivers/gpu/drm/i915/intel_psr.c
  +++ b/drivers/gpu/drm/i915/intel_psr.c
  @@ -117,6 +117,19 @@ static void vlv_psr_setup_vsc(struct intel_dp 
  *intel_dp)
  I915_WRITE(VLV_VSCSDP(pipe), val);
   }
   
  +static void skl_psr_setup_su_vsc(struct intel_dp *intel_dp)
  +{
  +   struct edp_vsc_psr psr_vsc;
  +
  +   /* Prepare VSC Header for SU as per EDP 1.4 spec, Table 6.11 */
  +   memset(psr_vsc, 0, sizeof(psr_vsc));
  +   psr_vsc.sdp_header.HB0 = 0;
  +   psr_vsc.sdp_header.HB1 = 0x7;
  +   psr_vsc.sdp_header.HB2 = 0x3;
  +   psr_vsc.sdp_header.HB3 = 0xb;
  +   intel_psr_write_vsc(intel_dp, psr_vsc);
  +}
  +
   static void hsw_psr_setup_vsc(struct intel_dp *intel_dp)
   {
  struct edp_vsc_psr psr_vsc;
  @@ -165,6 +178,12 @@ static void hsw_psr_enable_sink(struct 

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

2015-03-23 Thread Daniel Vetter
On Sun, Mar 22, 2015 at 03:41:04PM +, Chris Wilson wrote:
 Delay the expensive read on the FPGA_DBG register from once per mmio to
 once per forcewake section when we are doing the general wellbeing
 check rather than the targetted error detection. This almost reduces
 the overhead of the debug facility (for example when submitting execlists)
 to zero whilst keeping the debug checks around.
 
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Cc: Mika Kuoppala mika.kuopp...@intel.com
 Cc: Paulo Zanoni paulo.r.zan...@intel.com

Unfortunately the unclaimed reg stuff is most useful for debugging display
power well issues (it catches those while nothing else really does), and
this removes that facility. Can't we do tricks with using raw reads/writes
for forcewaked registers or something like that?
-Daniel

 ---
  drivers/gpu/drm/i915/intel_uncore.c | 47 
 -
  1 file changed, 26 insertions(+), 21 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
 b/drivers/gpu/drm/i915/intel_uncore.c
 index ab5cc94588e1..6b065592aede 100644
 --- a/drivers/gpu/drm/i915/intel_uncore.c
 +++ b/drivers/gpu/drm/i915/intel_uncore.c
 @@ -149,6 +149,30 @@ fw_domains_put(struct drm_i915_private *dev_priv, enum 
 forcewake_domains fw_doma
  }
  
  static void
 +hsw_unclaimed_reg_detect(struct drm_i915_private *dev_priv)
 +{
 + static bool mmio_debug_once = true;
 +
 + if (i915.mmio_debug || !mmio_debug_once)
 + return;
 +
 + if (__raw_i915_read32(dev_priv, FPGA_DBG)  FPGA_DBG_RM_NOCLAIM) {
 + DRM_DEBUG(Unclaimed register detected, 
 +   enabling oneshot unclaimed register reporting. 
 +   Please use i915.mmio_debug=N for more 
 information.\n);
 + __raw_i915_write32(dev_priv, FPGA_DBG, FPGA_DBG_RM_NOCLAIM);
 + i915.mmio_debug = mmio_debug_once--;
 + }
 +}
 +
 +static void
 +fw_domains_put_debug(struct drm_i915_private *dev_priv, enum 
 forcewake_domains fw_domains)
 +{
 + hsw_unclaimed_reg_detect(dev_priv);
 + fw_domains_put(dev_priv, fw_domains);
 +}
 +
 +static void
  fw_domains_posting_read(struct drm_i915_private *dev_priv)
  {
   struct intel_uncore_forcewake_domain *d;
 @@ -561,23 +585,6 @@ hsw_unclaimed_reg_debug(struct drm_i915_private 
 *dev_priv, u32 reg, bool read,
   }
  }
  
 -static void
 -hsw_unclaimed_reg_detect(struct drm_i915_private *dev_priv)
 -{
 - static bool mmio_debug_once = true;
 -
 - if (i915.mmio_debug || !mmio_debug_once)
 - return;
 -
 - if (__raw_i915_read32(dev_priv, FPGA_DBG)  FPGA_DBG_RM_NOCLAIM) {
 - DRM_DEBUG(Unclaimed register detected, 
 -   enabling oneshot unclaimed register reporting. 
 -   Please use i915.mmio_debug=N for more 
 information.\n);
 - __raw_i915_write32(dev_priv, FPGA_DBG, FPGA_DBG_RM_NOCLAIM);
 - i915.mmio_debug = mmio_debug_once--;
 - }
 -}
 -
  #define GEN2_READ_HEADER(x) \
   u##x val = 0; \
   assert_device_not_suspended(dev_priv);
 @@ -829,7 +836,6 @@ hsw_write##x(struct drm_i915_private *dev_priv, off_t 
 reg, u##x val, bool trace)
   gen6_gt_check_fifodbg(dev_priv); \
   } \
   hsw_unclaimed_reg_debug(dev_priv, reg, false, false); \
 - hsw_unclaimed_reg_detect(dev_priv); \
   GEN6_WRITE_FOOTER; \
  }
  
 @@ -871,7 +877,6 @@ gen8_write##x(struct drm_i915_private *dev_priv, off_t 
 reg, u##x val, bool trace
   __force_wake_get(dev_priv, FORCEWAKE_RENDER); \
   __raw_i915_write##x(dev_priv, reg, val); \
   hsw_unclaimed_reg_debug(dev_priv, reg, false, false); \
 - hsw_unclaimed_reg_detect(dev_priv); \
   GEN6_WRITE_FOOTER; \
  }
  
 @@ -1043,7 +1048,7 @@ static void intel_uncore_fw_domains_init(struct 
 drm_device *dev)
  
   if (IS_GEN9(dev)) {
   dev_priv-uncore.funcs.force_wake_get = fw_domains_get;
 - dev_priv-uncore.funcs.force_wake_put = fw_domains_put;
 + dev_priv-uncore.funcs.force_wake_put = fw_domains_put_debug;
   fw_domain_init(dev_priv, FW_DOMAIN_ID_RENDER,
  FORCEWAKE_RENDER_GEN9,
  FORCEWAKE_ACK_RENDER_GEN9);
 @@ -1066,7 +1071,7 @@ static void intel_uncore_fw_domains_init(struct 
 drm_device *dev)
   } else if (IS_HASWELL(dev) || IS_BROADWELL(dev)) {
   dev_priv-uncore.funcs.force_wake_get =
   fw_domains_get_with_thread_status;
 - dev_priv-uncore.funcs.force_wake_put = fw_domains_put;
 + dev_priv-uncore.funcs.force_wake_put = fw_domains_put_debug;
   fw_domain_init(dev_priv, FW_DOMAIN_ID_RENDER,
  FORCEWAKE_MT, FORCEWAKE_ACK_HSW);
   } else if (IS_IVYBRIDGE(dev)) {
 -- 
 2.1.4
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 

Re: [Intel-gfx] [PATCH 09/49] drm/i915/bxt: Broxton raises the maximum number of planes to 4

2015-03-23 Thread Antti Koskipää
Reviewed-by: Antti Koskipää antti.koski...@linux.intel.com

On 03/17/2015 11:39 AM, Imre Deak wrote:
 From: Damien Lespiau damien.lesp...@intel.com
 
 Pipe A and b have 4 planes.
 
 Signed-off-by: Damien Lespiau damien.lesp...@intel.com
 ---
  drivers/gpu/drm/i915/i915_drv.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index eba53c3..8fb7cc0 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -130,7 +130,7 @@ enum transcoder {
   *
   * This value doesn't count the cursor plane.
   */
 -#define I915_MAX_PLANES  3
 +#define I915_MAX_PLANES  4
  
  enum plane {
   PLANE_A = 0,
 

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


[Intel-gfx] [PATCH] tests/gem_tiled_swapping: Fix up L-shaped testing

2015-03-23 Thread Daniel Vetter
I've fumbled this, resulting in this this skipping everywhere.
Unfortunately no QA test report for this regression ...

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 tests/gem_tiled_swapping.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/gem_tiled_swapping.c b/tests/gem_tiled_swapping.c
index 2361dfcf76a3..072bf9a528fb 100644
--- a/tests/gem_tiled_swapping.c
+++ b/tests/gem_tiled_swapping.c
@@ -169,7 +169,7 @@ static void check_memory_layout(void)
igt_assert(tiling_debugfs_file);
 
while (getline(line, sz, tiling_debugfs_file)  0) {
-   if (strstr(line, L-shaped) != 0)
+   if (strstr(line, L-shaped) == NULL)
continue;
 
igt_skip(L-shaped memory configuration detected\n);
-- 
1.9.3

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


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

2015-03-23 Thread Daniel Vetter
Hi Dave,

drm-intel-next-2015-03-13-rebased:
- EU count report param for gen9+ (Jeff McGee)
- piles of pll/wm/... fixes for chv, finally out of preliminary hw support
  (Ville, Vijay)
- gen9 rps support from Akash
- more work to move towards atomic from Matt, Ander and others
- runtime pm support for skl (Damien)
- edp1.4 intermediate link clock support (Sonika)
- use frontbuffer tracking for fbc (Paulo)
- remove ilk rc6 (John Harrison)
- a bunch of smaller things and fixes all over

Includes backmerge because git rerere couldn't keep up any more. And full
rebase because at first I accidentally based this on top of the broken
merge and didn't notice (since we pull in drm-next too for -nightly).

Cheers, Daniel


The following changes since commit 03be70050c85768e9ce7c0d0887110d1b629e127:

  Merge tag 'topic/drm-misc-2015-03-10' of 
git://anongit.freedesktop.org/drm-intel into drm-next (2015-03-11 12:15:06 
+1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2015-03-13-merge

for you to fetch changes up to 0f9e9cd61f46c07246e30871fd638ffeaca3c576:

  Merge tag 'drm-intel-fixes-2015-03-19' into drm-intel-next (2015-03-20 
11:44:34 +0100)


Aaro Koskinen (1):
  ARM: OMAP: enable TWL4030_USB in omap2plus_defconfig

Ahmed S. Darwish (2):
  can: kvaser_usb: Avoid double free on URB submission failures
  can: kvaser_usb: Read all messages in a bulk-in URB buffer

Akash Goel (11):
  drm/i915/skl: Added new macros
  drm/i915/skl: Updated intel_gpu_freq() and intel_freq_opcode()
  drm/i915/skl: Updated the gen6_init_rps_frequencies function
  drm/i915/skl: Updated the gen6_set_rps function
  drm/i915/skl: Restructured the gen6_set_rps_thresholds function
  drm/i915/skl: Updated the gen6_rps_limits function
  drm/i915/skl: Updated the gen9_enable_rps function
  drm/i915/skl: Updated the act_freq_mhz_show sysfs function
  drm/i915/skl: Updated the i915_frequency_info debugfs function
  drm/i915/skl: Enabling processing of Turbo interrupts
  drm/i915/skl: Enable the RPS interrupts programming

Al Viro (8):
  new helper: dup_iter()
  move iov_iter.c from mm/ to lib/
  gadget/function/f_fs.c: close leaks
  gadget/function/f_fs.c: use put iov_iter into io_data
  gadget/function/f_fs.c: switch to -{read,write}_iter()
  gadgetfs: use-after-free in -aio_read()
  gadget: switch ep_io_operations to -read_iter/-write_iter
  gadgetfs: get rid of flipping -f_op in ep_config()

Alan Stern (1):
  gadgetfs: really get rid of switching -f_op

Alexander Drozdov (1):
  ipv4: ip_check_defrag should not assume that skb_network_offset is zero

Alexander Stein (1):
  ARM: at91/dt: at91sam9263: Fixup sram1 device tree node

Alexander Sverdlin (1):
  spi: pl022: Fix race in giveback() leading to driver lock-up

Alexandre Belloni (4):
  ARM: at91: pm: fix at91rm9200 standby
  ARM: at91: pm: fix SRAM allocation
  ARM: at91/defconfig: add at91rm9200 ethernet support
  ARM: at91: debug: fix non MMU debug

Alexey Brodkin (1):
  stmmac: check IRQ availability early on probe

Alexey Kardashevskiy (1):
  vfio-pci: Add missing break to enable VFIO_PCI_ERR_IRQ_INDEX

Ameen Ali (1):
  s390/dcss: array index 'i' is used before limits check.

Ander Conselvan de Oliveira (4):
  drm/i915: Set crtc backpointer when duplicating crtc state
  drm/i915: Add a for_each_intel_connector macro
  drm/i915: Improve staged config logging
  drm/i915: Simplify the way BC bifurcation state consistency is kept

Andrey Ryabinin (2):
  kasan, module, vmalloc: rework shadow allocation for modules
  kasan, module: move MODULE_ALIGN macro into linux/moduleloader.h

Andrzej Hajda (1):
  ARM: dts: add display power domain for exynos5250

Andy Shevchenko (3):
  spi: dw-pci: correct number of chip selects
  spi: dw: revisit FIFO size detection again
  spi: dw-mid: avoid potential NULL dereference

Anthony Harivel (1):
  ARM: at91/defconfig: remove CONFIG_SYSFS_DEPRECATED

Ard Biesheuvel (2):
  efi/arm64: use UEFI for system reset and poweroff
  arm64: put __boot_cpu_mode label after alignment instead of before

Arnd Bergmann (11):
  Input: sun4i-ts - add thermal driver dependency
  Merge tag 'samsung-fixes-dt' of 
git://git.kernel.org/.../kgene/linux-samsung into fixes
  Merge tag 'samsung-fixes-1' of 
git://git.kernel.org/.../kgene/linux-samsung into fixes
  Merge tag 'at91-fixes' of git://git.kernel.org/.../nferre/linux-at91 into 
fixes
  ARM: fix typos in smc91x platform data
  of: unittest: fix I2C dependency
  Merge tag 'socfpga_fixes_for_v4.0' of 
git://git.rocketboards.org/linux-socfpga-next into fixes
  Merge tag 'at91-fixes2' of git://git.kernel.org/.../nferre/linux-at91 
into fixes
  Merge tag 'fixes-v4.0-rc2' of 

Re: [Intel-gfx] [PATCH v4] drm/i915: Optimistically spin for the request completion

2015-03-23 Thread Daniel Vetter
On Fri, Mar 20, 2015 at 10:59:50PM +, Chris Wilson wrote:
 On Fri, Mar 20, 2015 at 04:19:02PM +, Chris Wilson wrote:
  I guess one test would be to see how many 1x1 [xN overdraw, say 1x1
  Window, but rendering internally at 1080p] clients we can run in
  parallel whilst hitting 60fps. And then whether allowing multiple
  spinners helps or hinders.
 
 I was thinking of a nice easy test that could demonstrate any advantage
 for spinning over waiting, and realised we already had such an igt. The
 trick is that it has to generate sufficient GPU load to actually require
 a wait, but not too high a GPU load such that we can see the impact from
 slow completion.
 
 I present igt/gem_exec_blt (modified to repeat the measurement and do an
 average over several runs):
 
 Time to blt 16384 bytes x  1:21.000µs - 5.800µs
 Time to blt 16384 bytes x  2:11.500µs - 4.500µs
 Time to blt 16384 bytes x  4: 6.750µs - 3.750µs
 Time to blt 16384 bytes x  8: 4.950µs - 3.375µs
 Time to blt 16384 bytes x 16: 3.825µs - 3.175µs
 Time to blt 16384 bytes x 32: 3.356µs - 3.000µs 
 Time to blt 16384 bytes x 64: 3.259µs - 2.909µs
 Time to blt 16384 bytes x128: 3.083µs - 3.095µs
 Time to blt 16384 bytes x256: 3.104µs - 2.979µs
 Time to blt 16384 bytes x512: 3.080µs - 3.089µs
 Time to blt 16384 bytes x   1024: 3.077µs - 3.040µs 
 Time to blt 16384 bytes x   2048: 3.127µs - 3.304µs
 Time to blt 16384 bytes x   4096: 3.279µs - 3.265µs

We probably need to revisit this when the scheduler lands - that one will
want to keep a short queue and generally will block for some request to
complete.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v4] drm/i915: Optimistically spin for the request completion

2015-03-23 Thread Chris Wilson
On Mon, Mar 23, 2015 at 09:31:38AM +0100, Daniel Vetter wrote:
 On Fri, Mar 20, 2015 at 10:59:50PM +, Chris Wilson wrote:
  On Fri, Mar 20, 2015 at 04:19:02PM +, Chris Wilson wrote:
   I guess one test would be to see how many 1x1 [xN overdraw, say 1x1
   Window, but rendering internally at 1080p] clients we can run in
   parallel whilst hitting 60fps. And then whether allowing multiple
   spinners helps or hinders.
  
  I was thinking of a nice easy test that could demonstrate any advantage
  for spinning over waiting, and realised we already had such an igt. The
  trick is that it has to generate sufficient GPU load to actually require
  a wait, but not too high a GPU load such that we can see the impact from
  slow completion.
  
  I present igt/gem_exec_blt (modified to repeat the measurement and do an
  average over several runs):
  
  Time to blt 16384 bytes x  1:21.000µs - 5.800µs
  Time to blt 16384 bytes x  2:11.500µs - 4.500µs
  Time to blt 16384 bytes x  4: 6.750µs - 3.750µs
  Time to blt 16384 bytes x  8: 4.950µs - 3.375µs
  Time to blt 16384 bytes x 16: 3.825µs - 3.175µs
  Time to blt 16384 bytes x 32: 3.356µs - 3.000µs 
  Time to blt 16384 bytes x 64: 3.259µs - 2.909µs
  Time to blt 16384 bytes x128: 3.083µs - 3.095µs
  Time to blt 16384 bytes x256: 3.104µs - 2.979µs
  Time to blt 16384 bytes x512: 3.080µs - 3.089µs
  Time to blt 16384 bytes x   1024: 3.077µs - 3.040µs 
  Time to blt 16384 bytes x   2048: 3.127µs - 3.304µs
  Time to blt 16384 bytes x   4096: 3.279µs - 3.265µs
 
 We probably need to revisit this when the scheduler lands - that one will
 want to keep a short queue and generally will block for some request to
 complete.

Speaking of which, execlists! You may have noticed that I
surreptitiously choose hsw to avoid the execlists overhead...

I was messing around over the weekend looking at the submission overhead
on bdw-u:
   -nightly  +spin +hax  execlists=0
  x1:  23.600µs  18.400µs  15.200µs  6.800µs
  x2:  19.700µs  16.500µs  15.900µs  5.000µs
  x4:  15.600µs  12.250µs  12.500µs  4.450µs
  x8:  13.575µs  11.000µs  11.650µs  4.050µs
 x16:  10.812µs   9.738µs   9.875µs  3.900µs
 x32:   9.281µs   8.613µs   9.406µs  3.750µs
 x64:   8.088µs   7.988µs   8.806µs  3.703µs
x128:   7.683µs   7.838µs   8.617µs  3.647µs
x256:   9.481µs   7.301µs   8.091µs  3.409µs
x512:   5.579µs   5.992µs   6.177µs  3.561µs
   x1024:  10.093µs   3.963µs   4.187µs  3.531µs
   x2048:  11.497µs   3.794µs   3.873µs  3.477µs
   x4096:   8.926µs   5.269µs   3.813µs  3.461µs

The hax are to remove the extra atomic ops and spinlocks imposed by
execlists. Steady state seems to be roughly on a par with the difference
appearing to be interrupt latency + extra register writes. What's
interesting is the latency caused by the ELSP submission mechanism to an
idle GPU, a hard floor for us. It may even be worth papering over it by
starting execlists from a tasklet.

I do feel this sort of information is missing from the execlists
merge...
-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] [RFC 3/4] drm/i915: Interrupt driven fences

2015-03-23 Thread Daniel Vetter
On Fri, Mar 20, 2015 at 09:11:35PM +, Chris Wilson wrote:
 On Fri, Mar 20, 2015 at 05:48:36PM +, john.c.harri...@intel.com wrote:
  From: John Harrison john.c.harri...@intel.com
  
  The intended usage model for struct fence is that the signalled status 
  should be
  set on demand rather than polled. That is, there should not be a need for a
  'signaled' function to be called everytime the status is queried. Instead,
  'something' should be done to enable a signal callback from the hardware 
  which
  will update the state directly. In the case of requests, this is the seqno
  update interrupt. The idea is that this callback will only be enabled on 
  demand
  when something actually tries to wait on the fence.
  
  This change removes the polling test and replaces it with the callback 
  scheme.
  To avoid race conditions where signals can be sent before anyone is waiting 
  for
  them, it does not implement the callback on demand feature. When the GPU
  scheduler arrives, it will need to know about the completion of every single
  request anyway. So it is far simpler to not put in complex and messy 
  anti-race
  code in the first place given that it will not be needed in the future.
  
  Instead, each fence is added to a 'please poke me' list at the start of
  i915_add_request(). This happens before the commands to generate the seqno
  interrupt are added to the ring thus is guaranteed to be race free. The
  interrupt handler then scans through the 'poke me' list when a new seqno 
  pops
  out and signals any matching fence/request. The fence is then removed from 
  the
  list so the entire request stack does not need to be scanned every time.
 
 No. Please let's not go back to the bad old days of generating an interrupt
 per batch, and doing a lot more work inside the interrupt handler.

Yeah, enable_signalling should be the place where we grab the interrupt
reference. Also that we shouldn't call this unconditionally, that pretty
much defeats the point of that fastpath optimization.

Another complication is missed interrupts. If we detect those and someone
calls enable_signalling then we need to fire up a timer to wake up once
per jiffy and save stuck fences. To avoid duplication with the threaded
wait code we could remove the fallback wakeups from there and just rely on
that timer everywhere.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 06/49] drm/i915/bxt: Broxton has 3 sprite planes on pipe A/B, 2 on pipe C

2015-03-23 Thread Antti Koskipää
Reviewed-by: Antti Koskipää antti.koski...@linux.intel.com

On 03/17/2015 11:39 AM, Imre Deak wrote:
 From: Damien Lespiau damien.lesp...@intel.com
 
 v2: Rebase on top of the for_each_pipe() change adding dev_priv as first
 argument.
 
 Signed-off-by: Damien Lespiau damien.lesp...@intel.com
 ---
  drivers/gpu/drm/i915/i915_dma.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
 index d49ed68..a94a970 100644
 --- a/drivers/gpu/drm/i915/i915_dma.c
 +++ b/drivers/gpu/drm/i915/i915_dma.c
 @@ -585,7 +585,11 @@ static void intel_device_info_runtime_init(struct 
 drm_device *dev)
  
   info = (struct intel_device_info *)dev_priv-info;
  
 - if (IS_VALLEYVIEW(dev) || INTEL_INFO(dev)-gen == 9)
 + if (IS_BROXTON(dev)) {
 + info-num_sprites[PIPE_A] = 3;
 + info-num_sprites[PIPE_B] = 3;
 + info-num_sprites[PIPE_C] = 2;
 + } else if (IS_VALLEYVIEW(dev) || INTEL_INFO(dev)-gen == 9)
   for_each_pipe(dev_priv, pipe)
   info-num_sprites[pipe] = 2;
   else
 

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


Re: [Intel-gfx] [PATCH] drm/i915/skl: Enabling PSR2 SU with frame sync

2015-03-23 Thread Sivakumar Thulasimani



On 3/20/2015 11:27 AM, Sonika Jindal wrote:

+#define   EDP_MAX_SU_DISABLE_TIME_MASK (0x1f20)
+#define   EDP_PSR2_TP2_TIME_500(08)
+#define   EDP_PSR2_TP2_TIME_100(18)
+#define   EDP_PSR2_TP2_TIME_250(28)
Better to make all values inline, 500us  100us should make 2.5ms to 
2500 . please correct it.



+   uint8_t frame_sync_cap;
+
+   dev_priv-psr.sink_support = true;
+   intel_dp_dpcd_read_wake(intel_dp-aux,
+   DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
+   frame_sync_cap, 1);
+   /* PSR2 needs frame sync as well */
+   if (frame_sync_cap) {
+   DRM_DEBUG_KMS(PSR2 supported on sink);
+   intel_dp-psr2_support = true;
+   } else
+   intel_dp-psr2_support = false;
+   }
}
  
  	/* Training Pattern 3 support, both source and sink */

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 8bb18e5..ed1b0a5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -663,6 +663,8 @@ struct intel_dp {
struct intel_dp_mst_encoder *mst_encoders[I915_MAX_PIPES];
struct drm_dp_mst_topology_mgr mst_mgr;
  
+	bool psr2_support;

+
uint32_t (*get_aux_clock_divider)(struct intel_dp *dp, int index);
/*
 * This function returns the value we have to program the AUX_CTL
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index b9f40c2..99dbc73 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -117,6 +117,19 @@ static void vlv_psr_setup_vsc(struct intel_dp *intel_dp)
I915_WRITE(VLV_VSCSDP(pipe), val);
  }
  
+static void skl_psr_setup_su_vsc(struct intel_dp *intel_dp)

+{
+   struct edp_vsc_psr psr_vsc;
+
+   /* Prepare VSC Header for SU as per EDP 1.4 spec, Table 6.11 */
+   memset(psr_vsc, 0, sizeof(psr_vsc));
+   psr_vsc.sdp_header.HB0 = 0;
+   psr_vsc.sdp_header.HB1 = 0x7;
+   psr_vsc.sdp_header.HB2 = 0x3;
+   psr_vsc.sdp_header.HB3 = 0xb;
+   intel_psr_write_vsc(intel_dp, psr_vsc);
+}
+
  static void hsw_psr_setup_vsc(struct intel_dp *intel_dp)
  {
struct edp_vsc_psr psr_vsc;
@@ -165,6 +178,12 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
drm_dp_dpcd_writeb(intel_dp-aux, DP_PSR_EN_CFG,
   DP_PSR_ENABLE  ~DP_PSR_MAIN_LINK_ACTIVE);
  
+	/* Enable AUX frame sync at sink */

+   if (intel_dp-psr2_support)
+   drm_dp_dpcd_writeb(intel_dp-aux,
+   DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
+   DP_AUX_FRAME_SYNC_ENABLE);
+
aux_data_reg = (INTEL_INFO(dev)-gen = 9) ?
DPA_AUX_CH_DATA1 : EDP_PSR_AUX_DATA1(dev);
aux_ctl_reg = (INTEL_INFO(dev)-gen = 9) ?
@@ -183,8 +202,10 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
val |= DP_AUX_CH_CTL_TIME_OUT_1600us;
val = ~DP_AUX_CH_CTL_MESSAGE_SIZE_MASK;
val |= (sizeof(aux_msg)  DP_AUX_CH_CTL_MESSAGE_SIZE_SHIFT);
-   /* Use hardcoded data values for PSR */
+   /* Use hardcoded data values for PSR, frame sync and GTC */
val = ~DP_AUX_CH_CTL_PSR_DATA_AUX_REG_SKL;
+   val = ~DP_AUX_CH_CTL_FS_DATA_AUX_REG_SKL;
+   val = ~DP_AUX_CH_CTL_GTC_DATA_AUX_REG_SKL;
I915_WRITE(aux_ctl_reg, val);
} else {
I915_WRITE(aux_ctl_reg,
@@ -255,6 +276,10 @@ static void hsw_psr_enable_source(struct intel_dp 
*intel_dp)
   max_sleep_time  EDP_PSR_MAX_SLEEP_TIME_SHIFT |
   idle_frames  EDP_PSR_IDLE_FRAME_SHIFT |
   EDP_PSR_ENABLE);
+
+   if (intel_dp-psr2_support)
+   I915_WRITE(EDP_PSR2_CTL, EDP_PSR2_ENABLE |
+   EDP_SU_TRACK_ENABLE | EDP_PSR2_TP2_TIME_100);
  }
  
  static bool intel_psr_match_conditions(struct intel_dp *intel_dp)

@@ -364,6 +389,9 @@ void intel_psr_enable(struct intel_dp *intel_dp)
if (HAS_DDI(dev)) {
hsw_psr_setup_vsc(intel_dp);
  
+		if (intel_dp-psr2_support)

+   skl_psr_setup_su_vsc(intel_dp);
+
/* Avoid continuous PSR exit by masking memup and hpd */
I915_WRITE(EDP_PSR_DEBUG_CTL(dev), EDP_PSR_DEBUG_MASK_MEMUP |
   EDP_PSR_DEBUG_MASK_HPD | EDP_PSR_DEBUG_MASK_LPSP);


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


Re: [Intel-gfx] [PATCH] drm/i915/skl: Enabling PSR2 SU with frame sync

2015-03-23 Thread sonika


On Saturday 21 March 2015 04:56 AM, Vivi, Rodrigo wrote:

Hi Sonika,

on the previous email I forgot to tell that we also need to add
somewhere a check to avoid PSR for resolutions bigger than 3200x2000.

Yes, I will add that check before enabling PSR2.

Although most of displays that we have that support psr are 3200x1800 it
is better to think a way to protect now than later.

Thanks,
Rodrigo.

On Fri, 2015-03-20 at 11:27 +0530, Sonika Jindal wrote:

We make use of HW tracking for Selective update region and enable frame sync on
sink. We use hardware's hardcoded data values for frame sync and GTC.

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
  drivers/gpu/drm/i915/i915_reg.h  |   14 ++
  drivers/gpu/drm/i915/intel_dp.c  |   16 
  drivers/gpu/drm/i915/intel_drv.h |2 ++
  drivers/gpu/drm/i915/intel_psr.c |   30 +-
  4 files changed, 61 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5b84ee6..7e4f6f0 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2745,6 +2745,20 @@ enum skl_disp_power_wells {
  #define   EDP_PSR_DEBUG_MASK_MEMUP(126)
  #define   EDP_PSR_DEBUG_MASK_HPD  (125)
  
+#define EDP_PSR2_CTL			0x6f900

+#define   EDP_PSR2_ENABLE  (131)
+#define   EDP_SU_TRACK_ENABLE  (130)
+#define   EDP_MAX_SU_DISABLE_TIME(t)   ((t)20)
+#define   EDP_MAX_SU_DISABLE_TIME_MASK (0x1f20)
+#define   EDP_PSR2_TP2_TIME_500(08)
+#define   EDP_PSR2_TP2_TIME_100(18)
+#define   EDP_PSR2_TP2_TIME_250(28)
+#define   EDP_PSR2_TP2_TIME_50 (38)
+#define   EDP_PSR2_TP2_TIME_MASK   (38)
+#define   EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
+#define   EDP_PSR2_FRAME_BEFORE_SU_MASK(0xf4)
+#define   EDP_PSR2_IDLE_MASK   0xf
+
  /* VGA port control */
  #define ADPA  0x61100
  #define PCH_ADPA0xe1100
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3967af1..dedd8ad 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3786,6 +3786,22 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
dev_priv-psr.sink_support = true;
DRM_DEBUG_KMS(Detected EDP PSR Panel.\n);
}
+
+   if (INTEL_INFO(dev)-gen = 9 
+   (intel_dp-psr_dpcd[0]  DP_PSR2_IS_SUPPORTED)) {
+   uint8_t frame_sync_cap;
+
+   dev_priv-psr.sink_support = true;
+   intel_dp_dpcd_read_wake(intel_dp-aux,
+   DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
+   frame_sync_cap, 1);
+   /* PSR2 needs frame sync as well */
+   if (frame_sync_cap) {
+   DRM_DEBUG_KMS(PSR2 supported on sink);
+   intel_dp-psr2_support = true;
+   } else
+   intel_dp-psr2_support = false;
+   }
}
  
  	/* Training Pattern 3 support, both source and sink */

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 8bb18e5..ed1b0a5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -663,6 +663,8 @@ struct intel_dp {
struct intel_dp_mst_encoder *mst_encoders[I915_MAX_PIPES];
struct drm_dp_mst_topology_mgr mst_mgr;
  
+	bool psr2_support;

+
uint32_t (*get_aux_clock_divider)(struct intel_dp *dp, int index);
/*
 * This function returns the value we have to program the AUX_CTL
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index b9f40c2..99dbc73 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -117,6 +117,19 @@ static void vlv_psr_setup_vsc(struct intel_dp *intel_dp)
I915_WRITE(VLV_VSCSDP(pipe), val);
  }
  
+static void skl_psr_setup_su_vsc(struct intel_dp *intel_dp)

+{
+   struct edp_vsc_psr psr_vsc;
+
+   /* Prepare VSC Header for SU as per EDP 1.4 spec, Table 6.11 */
+   memset(psr_vsc, 0, sizeof(psr_vsc));
+   psr_vsc.sdp_header.HB0 = 0;
+   psr_vsc.sdp_header.HB1 = 0x7;
+   psr_vsc.sdp_header.HB2 = 0x3;
+   psr_vsc.sdp_header.HB3 = 0xb;
+   intel_psr_write_vsc(intel_dp, psr_vsc);
+}
+
  static void hsw_psr_setup_vsc(struct intel_dp *intel_dp)
  {
struct edp_vsc_psr psr_vsc;
@@ -165,6 +178,12 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
drm_dp_dpcd_writeb(intel_dp-aux, DP_PSR_EN_CFG,
   DP_PSR_ENABLE  ~DP_PSR_MAIN_LINK_ACTIVE);
  
+	/* Enable AUX frame sync at sink */

+   if (intel_dp-psr2_support)
+   drm_dp_dpcd_writeb(intel_dp-aux,
+   

Re: [Intel-gfx] [PATCH] drm/i915: Keep ring-active_list and ring-requests_list consistent

2015-03-23 Thread Chris Wilson
On Mon, Mar 23, 2015 at 09:49:15AM +0100, Daniel Vetter wrote:
 In case it's burried too much in the thread:
 
 Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
 
 Addadendum for the commit:
 
 Note that this is only a problem in evict_vm where the following happens
 after a retire_request has cleaned out all requests, but not all active
 bo:
 - intel_ring_idle called from i915_gpu_idle notices that no requests are
   outstanding and immediately returns.
 - i915_gem_retire_requests_ring called from i915_gem_retire_requests also
   immediately returns when there's no request, still leaving the bo on the
   active list.
 - evict_vm hits the WARN_ON(!list_empty(vm-active_list)) after evicting
   all active objects that there's still stuff left that shouldn't be
   there.
 
 Chris, is that an accurate enough description for Jani to add to the
 patch?

Not quite. It affects everywhere where we rely on i915_gpu_idle() idling
the gpu (e.g. suspend), it is only the canary in i915_gem_evict_vm()
that first alerted us to the bug. Maybe we have some recent weird bugs in
suspend (or it may be too soon for those reports to start trickling in)?
-Chris

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


Re: [Intel-gfx] [PATCH] drm/i915: Keep ring-active_list and ring-requests_list consistent

2015-03-23 Thread Daniel Vetter
On Mon, Mar 23, 2015 at 09:15:02AM +, Chris Wilson wrote:
 On Mon, Mar 23, 2015 at 09:13:36AM +, Chris Wilson wrote:
  On Mon, Mar 23, 2015 at 09:49:15AM +0100, Daniel Vetter wrote:
   In case it's burried too much in the thread:
   
   Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
   
   Addadendum for the commit:
   
   Note that this is only a problem in evict_vm where the following happens
   after a retire_request has cleaned out all requests, but not all active
   bo:
   - intel_ring_idle called from i915_gpu_idle notices that no requests are
 outstanding and immediately returns.
   - i915_gem_retire_requests_ring called from i915_gem_retire_requests also
 immediately returns when there's no request, still leaving the bo on the
 active list.
   - evict_vm hits the WARN_ON(!list_empty(vm-active_list)) after evicting
 all active objects that there's still stuff left that shouldn't be
 there.
   
   Chris, is that an accurate enough description for Jani to add to the
   patch?
  
  Not quite. It affects everywhere where we rely on i915_gpu_idle() idling
  the gpu (e.g. suspend), it is only the canary in i915_gem_evict_vm()
  that first alerted us to the bug. Maybe we have some recent weird bugs in
  suspend (or it may be too soon for those reports to start trickling in)?
 
 I take that back. The gpu is idle (no more requests). It's just the
 bookkeeping that's wrong (and that only affects eviction iirc).
 
 I stand corrected.

Yeah totally missed that tbh. But since we restore ggtt ptes on resume I
think even if we manage to leave a bunch of objects more behind we should
be fine. Worst-case there's more target area for stray writes from the
bios on S4 ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2015-03-23 Thread Chris Wilson
On Mon, Mar 23, 2015 at 09:43:19AM +, Chris Wilson wrote:
 On Mon, Mar 23, 2015 at 10:35:16AM +0100, Daniel Vetter wrote:
  On Sun, Mar 22, 2015 at 03:41:04PM +, Chris Wilson wrote:
   Delay the expensive read on the FPGA_DBG register from once per mmio to
   once per forcewake section when we are doing the general wellbeing
   check rather than the targetted error detection. This almost reduces
   the overhead of the debug facility (for example when submitting execlists)
   to zero whilst keeping the debug checks around.
   
   Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
   Cc: Mika Kuoppala mika.kuopp...@intel.com
   Cc: Paulo Zanoni paulo.r.zan...@intel.com
  
  Unfortunately the unclaimed reg stuff is most useful for debugging display
  power well issues (it catches those while nothing else really does), and
  this removes that facility. Can't we do tricks with using raw reads/writes
  for forcewaked registers or something like that?
 
 How about beefing up intel_uncore_check_errors() to enable one-shot
 mmio_debug as well? Then if it is an i915 error we would catch it on the
 next cycle.

So something like:
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 6b065592aede..a10bf6a5c55b 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1416,11 +1416,6 @@ int intel_gpu_reset(struct drm_device *dev)
 
 void intel_uncore_check_errors(struct drm_device *dev)
 {
-   struct drm_i915_private *dev_priv = dev-dev_private;
-
-   if (HAS_FPGA_DBG_UNCLAIMED(dev) 
-   (__raw_i915_read32(dev_priv, FPGA_DBG)  FPGA_DBG_RM_NOCLAIM)) {
-   DRM_ERROR(Unclaimed register before interrupt\n);
-   __raw_i915_write32(dev_priv, FPGA_DBG, FPGA_DBG_RM_NOCLAIM);
-   }
+   if (HAS_FPGA_DBG_UNCLAIMED(dev))
+   hsw_unclaimed_reg_detect(to_i915(dev));
 }


-- 
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] About install Intel(R) Graphics Installer for Linux* 1.0.8 on Linux Mint

2015-03-23 Thread king chess




Hi

How can install Intel(R) Graphics Installer for Linux* 1.0.8 on Linux mint 17.1
  

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


[Intel-gfx] [PATCH 4/4] media: cxd2820r: use DIV_ROUND_CLOSEST_ULL()

2015-03-23 Thread Javi Merino
Now that the kernel provides DIV_ROUND_CLOSEST_ULL(), drop the internal
implementation and use the kernel one.

Cc: Antti Palosaari cr...@iki.fi
Cc: Mauro Carvalho Chehab mche...@osg.samsung.com
Signed-off-by: Javi Merino javi.mer...@arm.com
---
I've only compile-tested it, I don't have the hardware to run it.

 drivers/media/dvb-frontends/cxd2820r_c.c| 2 +-
 drivers/media/dvb-frontends/cxd2820r_core.c | 6 --
 drivers/media/dvb-frontends/cxd2820r_priv.h | 2 --
 drivers/media/dvb-frontends/cxd2820r_t.c| 2 +-
 drivers/media/dvb-frontends/cxd2820r_t2.c   | 2 +-
 5 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/media/dvb-frontends/cxd2820r_c.c 
b/drivers/media/dvb-frontends/cxd2820r_c.c
index 149fdca3fb44..72b0e2db3aab 100644
--- a/drivers/media/dvb-frontends/cxd2820r_c.c
+++ b/drivers/media/dvb-frontends/cxd2820r_c.c
@@ -79,7 +79,7 @@ int cxd2820r_set_frontend_c(struct dvb_frontend *fe)
 
num = if_freq / 1000; /* Hz = kHz */
num *= 0x4000;
-   if_ctl = 0x4000 - cxd2820r_div_u64_round_closest(num, 41000);
+   if_ctl = 0x4000 - DIV_ROUND_CLOSEST_ULL(num, 41000);
buf[0] = (if_ctl  8)  0x3f;
buf[1] = (if_ctl  0)  0xff;
 
diff --git a/drivers/media/dvb-frontends/cxd2820r_core.c 
b/drivers/media/dvb-frontends/cxd2820r_core.c
index 422e84bbb008..490e090048ef 100644
--- a/drivers/media/dvb-frontends/cxd2820r_core.c
+++ b/drivers/media/dvb-frontends/cxd2820r_core.c
@@ -244,12 +244,6 @@ error:
return ret;
 }
 
-/* 64 bit div with round closest, like DIV_ROUND_CLOSEST but 64 bit */
-u32 cxd2820r_div_u64_round_closest(u64 dividend, u32 divisor)
-{
-   return div_u64(dividend + (divisor / 2), divisor);
-}
-
 static int cxd2820r_set_frontend(struct dvb_frontend *fe)
 {
struct cxd2820r_priv *priv = fe-demodulator_priv;
diff --git a/drivers/media/dvb-frontends/cxd2820r_priv.h 
b/drivers/media/dvb-frontends/cxd2820r_priv.h
index 7ff5f60c83e1..4b428959b16e 100644
--- a/drivers/media/dvb-frontends/cxd2820r_priv.h
+++ b/drivers/media/dvb-frontends/cxd2820r_priv.h
@@ -64,8 +64,6 @@ int cxd2820r_wr_reg_mask(struct cxd2820r_priv *priv, u32 reg, 
u8 val,
 int cxd2820r_wr_regs(struct cxd2820r_priv *priv, u32 reginfo, u8 *val,
int len);
 
-u32 cxd2820r_div_u64_round_closest(u64 dividend, u32 divisor);
-
 int cxd2820r_wr_regs(struct cxd2820r_priv *priv, u32 reginfo, u8 *val,
int len);
 
diff --git a/drivers/media/dvb-frontends/cxd2820r_t.c 
b/drivers/media/dvb-frontends/cxd2820r_t.c
index 51401d036530..008cb2ac8480 100644
--- a/drivers/media/dvb-frontends/cxd2820r_t.c
+++ b/drivers/media/dvb-frontends/cxd2820r_t.c
@@ -103,7 +103,7 @@ int cxd2820r_set_frontend_t(struct dvb_frontend *fe)
 
num = if_freq / 1000; /* Hz = kHz */
num *= 0x100;
-   if_ctl = cxd2820r_div_u64_round_closest(num, 41000);
+   if_ctl = DIV_ROUND_CLOSEST_ULL(num, 41000);
buf[0] = ((if_ctl  16)  0xff);
buf[1] = ((if_ctl   8)  0xff);
buf[2] = ((if_ctl   0)  0xff);
diff --git a/drivers/media/dvb-frontends/cxd2820r_t2.c 
b/drivers/media/dvb-frontends/cxd2820r_t2.c
index 9c0c4f42175c..35fe364c7182 100644
--- a/drivers/media/dvb-frontends/cxd2820r_t2.c
+++ b/drivers/media/dvb-frontends/cxd2820r_t2.c
@@ -120,7 +120,7 @@ int cxd2820r_set_frontend_t2(struct dvb_frontend *fe)
 
num = if_freq / 1000; /* Hz = kHz */
num *= 0x100;
-   if_ctl = cxd2820r_div_u64_round_closest(num, 41000);
+   if_ctl = DIV_ROUND_CLOSEST_ULL(num, 41000);
buf[0] = ((if_ctl  16)  0xff);
buf[1] = ((if_ctl   8)  0xff);
buf[2] = ((if_ctl   0)  0xff);
-- 
1.9.1

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


Re: [Intel-gfx] [PATCH 05/59] drm/i915: Reserve ring buffer space for i915_add_request() commands

2015-03-23 Thread Daniel Vetter
On Fri, Mar 20, 2015 at 03:55:59PM +, John Harrison wrote:
 On 20/03/2015 15:13, Daniel Vetter wrote:
 On Thu, Mar 19, 2015 at 12:30:10PM +, john.c.harri...@intel.com wrote:
 +void intel_ring_reserved_space_use(struct intel_ringbuffer *ringbuf, int 
 size)
 Just a bit of interface bikeshed - I'd drop the size parameter here. It
 just duplicates what we tell the ring in the reservation code and the real
 check happens in the _end function.
 
 +{
 +   WARN_ON(size  ringbuf-reserved_size);
 +   WARN_ON(ringbuf-reserved_in_use);
 +
 +   ringbuf-reserved_in_use = true;
 +   ringbuf-reserved_tail   = ringbuf-tail;
 +}
 +
 +void intel_ring_reserved_space_end(struct intel_ringbuffer *ringbuf)
 +{
 +   WARN_ON(!ringbuf-reserved_in_use);
 +   WARN_ON(ringbuf-tail  ringbuf-reserved_tail + 
 ringbuf-reserved_size);
 Don't we need to handle wrap-around to make sure we do correctly check for
 sufficient reservation?
 -Daniel
 
 There is nothing special to worry about for wrapping. The regular
 intel_ring_begin() code will handle all that as before. The whole point of
 the reserved scheme is that it is basically the same as calling
 intel_ring_begin() with 'size + RESERVED_SIZE' everywhere. So when
 i915_add_request() starts, it is guaranteed that an
 'intel_ring_begin(RESERVED_SIZE)' has been done already including any
 necessary buffer wrapping. Thus it does not actually need to call
 'i_r_begin()' at all, really - it is guaranteed to succeed (as long as it
 stays within RESERVED_SIZE total usage).

I think there's a misunderstanding. Let me try to explain again.

ringbuf-tail gets wrapped around, but the expression
ringbuf-reserved-tail + ringbuf-reserved_size doesn't. And the
comparison  also doesn't handle wrap around.

All taken together there won't be a spurios WARN, buf if you wrap -tail
and haven't reserved enough space your check wont catch this. The only
thing you need is reserved_size+reserved_tail  RINGBUF_SIZE and your WARN
won't fire, not even if we wrap the ring a few times.

This is even more important since the wrapping itself increases space
requirements a bit, and so we want to be especially careful with checking
that we reserved enough there.

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


Re: [Intel-gfx] [PATCH 04/49] drm/i915/bxt: Broxton uses the same GMS values as Skylake

2015-03-23 Thread Antti Koskipää
Reviewed-by: Antti Koskipää antti.koski...@linux.intel.com

On 03/17/2015 11:39 AM, Imre Deak wrote:
 From: Damien Lespiau damien.lesp...@intel.com
 
 v2: Rebase on top of the early-quirks rework from Ville.
 
 Signed-off-by: Damien Lespiau damien.lesp...@intel.com (v1)
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  arch/x86/kernel/early-quirks.c | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
 index fe9f0b7..ab470e4 100644
 --- a/arch/x86/kernel/early-quirks.c
 +++ b/arch/x86/kernel/early-quirks.c
 @@ -546,6 +546,7 @@ static const struct pci_device_id intel_stolen_ids[] 
 __initconst = {
   INTEL_BDW_D_IDS(gen8_stolen_funcs),
   INTEL_CHV_IDS(chv_stolen_funcs),
   INTEL_SKL_IDS(gen9_stolen_funcs),
 + INTEL_BXT_IDS(gen9_stolen_funcs),
  };
  
  static void __init intel_graphics_stolen(int num, int slot, int func)
 

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


Re: [Intel-gfx] [PATCH 08/49] drm/i915/bxt: Broxton DDB is 512 blocks

2015-03-23 Thread Antti Koskipää
Reviewed-by: Antti Koskipää antti.koski...@linux.intel.com

On 03/17/2015 11:39 AM, Imre Deak wrote:
 From: Damien Lespiau damien.lesp...@intel.com
 
 Signed-off-by: Damien Lespiau damien.lesp...@intel.com
 ---
  drivers/gpu/drm/i915/intel_pm.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
 index 288c9d2..b89ab4d 100644
 --- a/drivers/gpu/drm/i915/intel_pm.c
 +++ b/drivers/gpu/drm/i915/intel_pm.c
 @@ -2538,6 +2538,7 @@ static bool ilk_disable_lp_wm(struct drm_device *dev)
   */
  
  #define SKL_DDB_SIZE 896 /* in blocks */
 +#define BXT_DDB_SIZE 512
  
  static void
  skl_ddb_get_pipe_allocation_limits(struct drm_device *dev,
 @@ -2556,7 +2557,10 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device 
 *dev,
   return;
   }
  
 - ddb_size = SKL_DDB_SIZE;
 + if (IS_BROXTON(dev))
 + ddb_size = BXT_DDB_SIZE;
 + else
 + ddb_size = SKL_DDB_SIZE;
  
   ddb_size -= 4; /* 4 blocks for bypass path allocation */
  
 

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


Re: [Intel-gfx] [PATCH 05/49] drm/i915/bxt: Enable PTE encoding

2015-03-23 Thread Antti Koskipää
Reviewed-by: Antti Koskipää antti.koski...@linux.intel.com

On 03/17/2015 11:39 AM, Imre Deak wrote:
 From: Sumit Singh sumit.k.si...@intel.com
 
 The caching options for page table entries have remained the same as
 Cherryview. This patch fixes it so the right code path is taken on BXT.
 
 v2: Fix up commit message (Mike)
 
 Signed-off-by: Sumit Singh sumit.k.si...@intel.com
 Signed-off-by: Damien Lespiau damien.lesp...@intel.com
 ---
  drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
 b/drivers/gpu/drm/i915/i915_gem_gtt.c
 index f1b9ea6..4311292 100644
 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
 +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
 @@ -1506,7 +1506,7 @@ void i915_gem_restore_gtt_mappings(struct drm_device 
 *dev)
  
  
   if (INTEL_INFO(dev)-gen = 8) {
 - if (IS_CHERRYVIEW(dev))
 + if (IS_CHERRYVIEW(dev) || IS_BROXTON(dev))
   chv_setup_private_ppat(dev_priv);
   else
   bdw_setup_private_ppat(dev_priv);
 @@ -2187,7 +2187,7 @@ static int gen8_gmch_probe(struct drm_device *dev,
  
   *gtt_total = (gtt_size / sizeof(gen8_gtt_pte_t))  PAGE_SHIFT;
  
 - if (IS_CHERRYVIEW(dev))
 + if (IS_CHERRYVIEW(dev) || IS_BROXTON(dev))
   chv_setup_private_ppat(dev_priv);
   else
   bdw_setup_private_ppat(dev_priv);
 

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


Re: [Intel-gfx] [PATCH] tests/kms_psr_sink_crc: Make render visible to human eyes

2015-03-23 Thread Daniel Vetter
On Fri, Mar 20, 2015 at 05:43:40PM +, Vivi, Rodrigo wrote:
 On Fri, 2015-03-20 at 10:54 +0100, Daniel Vetter wrote:
  On Thu, Mar 19, 2015 at 06:24:24PM -0700, Rodrigo Vivi wrote:
   This will allow manual tests when crc isn't available.
   
   v2: Remove unused and non-sense buf-size and decrease buf-stride a bit 
   as suggested by Daniel.
  
  buf-size isn't nonsense really, it does seem to match what we've
  allocated. But it also seems unused in the rendercpy functions I've
  checked. Imo you should keep that line
 
 oh sure, bad phrase the value 4 was nonsense.
 But if I increases that it fails. Without setting it works.
 What do you think?

If just keeping that line makes the test work there's something _really_
fishy going on. If it persists after git clean -dfx and full recompile I'd
dig into it, since this really doesn't make sense.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2015-03-23 Thread Chris Wilson
On Mon, Mar 23, 2015 at 10:35:16AM +0100, Daniel Vetter wrote:
 On Sun, Mar 22, 2015 at 03:41:04PM +, Chris Wilson wrote:
  Delay the expensive read on the FPGA_DBG register from once per mmio to
  once per forcewake section when we are doing the general wellbeing
  check rather than the targetted error detection. This almost reduces
  the overhead of the debug facility (for example when submitting execlists)
  to zero whilst keeping the debug checks around.
  
  Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
  Cc: Mika Kuoppala mika.kuopp...@intel.com
  Cc: Paulo Zanoni paulo.r.zan...@intel.com
 
 Unfortunately the unclaimed reg stuff is most useful for debugging display
 power well issues (it catches those while nothing else really does), and
 this removes that facility. Can't we do tricks with using raw reads/writes
 for forcewaked registers or something like that?

How about beefing up intel_uncore_check_errors() to enable one-shot
mmio_debug as well? Then if it is an i915 error we would catch it on the
next cycle.
-Chris

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


Re: [Intel-gfx] [PATCH] drm/i915: Use usleep_range() in wait_for()

2015-03-23 Thread Daniel Vetter
On Mon, Mar 23, 2015 at 11:39:12AM +0200, Ville Syrjälä wrote:
 On Fri, Mar 20, 2015 at 09:09:51PM +, Chris Wilson wrote:
  On Fri, Mar 20, 2015 at 09:28:08PM +0200, ville.syrj...@linux.intel.com 
  wrote:
   From: Ville Syrjälä ville.syrj...@linux.intel.com
   
   msleep() can sleep for way too long, so switch wait_for() to use
   usleep_range() instead. Following a totally unscientific method
   I just picked the range as W-2W.
   
   This cuts the i915 init time on my BSW to almost half:
   - initcall i915_init+0x0/0xa8 [i915] returned 0 after 419977 usecs
   + initcall i915_init+0x0/0xa8 [i915] returned 0 after 238419 usecs
   
   Note that I didn't perform any other benchmarks on this so far.
   
   Cc: Jesse Barnes jbar...@virtuousgeek.org
   Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
  
  Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
  
  Hmm, I think we can improve further with a more variable sleep. The
  maximum we pass to wait_for() is usually plucked from somewhere in the
  spec (or is just a safety factor). Either way, it is a good guide as to
  how to actually sleep for - if say we try to only sample 1000 times up
  to the maximum:
  
  if (do_sleep  drm_can_sleep()) {
  usleep_range((MS), 10*(MS));
  }
  
  So whilst you have a situation where we clearly sleep too long between
  sampling (a register), it would be beneficial to start adding some debug
  infrastructure. Or even better if usleep_range already does it for us...
 
 Yeah, it would be nice to have some more information about how long we
 sleep typically in each case.
 
 We could perhaps then even micro optimize the 'set knob - poll for knob
 to become active' pattern by doing a preemptive sleep between the set
 and poll steps in the hopes that we don't have to check the condition
 more than once. Not sure that would be worth the effort though.

Something like the below might be worth a quick shot. Maybe with 3 instead
of 2, but then we need to make sure we don't drop down to 0 ever.
-Daniel

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d2a4de0e4f4a..b796e4c47da5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -58,6 +58,7 @@
}   \
if ((W)  drm_can_sleep()) {   \
usleep_range((W)*1000, (W)*2000);   \
+   W = ROUND_UP(W, 2); \
} else {\
cpu_relax();\
}   \
@@ -65,7 +66,7 @@
ret__;  \
 })
 
-#define wait_for(COND, MS) _wait_for(COND, MS, 1)
+#define wait_for(COND, MS) _wait_for(COND, MS, ROUND_UP(COND, 2))
 #define wait_for_atomic(COND, MS) _wait_for(COND, MS, 0)
 #define wait_for_atomic_us(COND, US) _wait_for((COND), \
   DIV_ROUND_UP((US), 1000), 0)
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 07/49] drm/i915/bxt: Add the plane4 related interrupt definitions

2015-03-23 Thread Antti Koskipää
Reviewed-by: Antti Koskipää antti.koski...@linux.intel.com

On 03/17/2015 11:39 AM, Imre Deak wrote:
 From: Damien Lespiau damien.lesp...@intel.com
 
 Signed-off-by: Damien Lespiau damien.lesp...@intel.com
 ---
  drivers/gpu/drm/i915/i915_reg.h | 3 +++
  1 file changed, 3 insertions(+)
 
 diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
 index cc8ebab..3369a11 100644
 --- a/drivers/gpu/drm/i915/i915_reg.h
 +++ b/drivers/gpu/drm/i915/i915_reg.h
 @@ -5216,9 +5216,11 @@ enum skl_disp_power_wells {
  #define  GEN8_PIPE_VSYNC (1  1)
  #define  GEN8_PIPE_VBLANK(1  0)
  #define  GEN9_PIPE_CURSOR_FAULT  (1  11)
 +#define  GEN9_PIPE_PLANE4_FAULT  (1  10)
  #define  GEN9_PIPE_PLANE3_FAULT  (1  9)
  #define  GEN9_PIPE_PLANE2_FAULT  (1  8)
  #define  GEN9_PIPE_PLANE1_FAULT  (1  7)
 +#define  GEN9_PIPE_PLANE4_FLIP_DONE  (1  6)
  #define  GEN9_PIPE_PLANE3_FLIP_DONE  (1  5)
  #define  GEN9_PIPE_PLANE2_FLIP_DONE  (1  4)
  #define  GEN9_PIPE_PLANE1_FLIP_DONE  (1  3)
 @@ -5229,6 +5231,7 @@ enum skl_disp_power_wells {
GEN8_PIPE_PRIMARY_FAULT)
  #define GEN9_DE_PIPE_IRQ_FAULT_ERRORS \
   (GEN9_PIPE_CURSOR_FAULT | \
 +  GEN9_PIPE_PLANE4_FAULT | \
GEN9_PIPE_PLANE3_FAULT | \
GEN9_PIPE_PLANE2_FAULT | \
GEN9_PIPE_PLANE1_FAULT)
 

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


Re: [Intel-gfx] [PATCH 1/4] kernel.h: Implement DIV_ROUND_CLOSEST_ULL

2015-03-23 Thread Daniel Vetter
On Fri, Mar 20, 2015 at 11:14:40AM +, Javi Merino wrote:
 We have grown a number of different implementations of
 DIV_ROUND_CLOSEST_ULL throughout the kernel.  Move the i915 one to
 kernel.h so that it can be reused.
 
 Cc: Daniel Vetter daniel.vet...@intel.com
 Cc: Jani Nikula jani.nik...@linux.intel.com
 Cc: David Airlie airl...@linux.ie
 Cc: Darrick J. Wong djw...@us.ibm.com
 Cc: Guenter Roeck li...@roeck-us.net
 Cc: Andrew Morton a...@linux-foundation.org
 Signed-off-by: Javi Merino javi.mer...@arm.com

Acked-by: Daniel Vetter daniel.vet...@ffwll.ch

And preemptive ack for the next version with the includes at different
places.
-Daniel

 ---
  drivers/gpu/drm/i915/intel_drv.h |  4 +---
  include/linux/kernel.h   | 11 +++
  2 files changed, 12 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_drv.h 
 b/drivers/gpu/drm/i915/intel_drv.h
 index eef79ccd0b7c..346e28fdd7dd 100644
 --- a/drivers/gpu/drm/i915/intel_drv.h
 +++ b/drivers/gpu/drm/i915/intel_drv.h
 @@ -28,6 +28,7 @@
  #include linux/async.h
  #include linux/i2c.h
  #include linux/hdmi.h
 +#include linux/kernel.h
  #include drm/i915_drm.h
  #include i915_drv.h
  #include drm/drm_crtc.h
 @@ -36,9 +37,6 @@
  #include drm/drm_dp_mst_helper.h
  #include drm/drm_rect.h
  
 -#define DIV_ROUND_CLOSEST_ULL(ll, d) \
 -({ unsigned long long _tmp = (ll)+(d)/2; do_div(_tmp, d); _tmp; })
 -
  /**
   * _wait_for - magic (register) wait macro
   *
 diff --git a/include/linux/kernel.h b/include/linux/kernel.h
 index d6d630d31ef3..f7d744e9d275 100644
 --- a/include/linux/kernel.h
 +++ b/include/linux/kernel.h
 @@ -103,6 +103,17 @@
   (((__x) - ((__d) / 2)) / (__d));\
  }\
  )
 +/*
 + * Same as above but for u64 dividends.  divisor must be a 32-bit
 + * number.
 + */
 +#define DIV_ROUND_CLOSEST_ULL(x, divisor)(   \
 +{\
 + unsigned long long _tmp = (x) + (divisor) / 2;  \
 + do_div(_tmp, divisor);  \
 + _tmp;   \
 +}\
 +)
  
  /*
   * Multiplies an integer by a fraction, while avoiding unnecessary
 -- 
 1.9.1
 
 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

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


Re: [Intel-gfx] [PATCH] drm/i915: Keep ring-active_list and ring-requests_list consistent

2015-03-23 Thread Daniel Vetter
On Fri, Mar 20, 2015 at 03:36:11PM +, Chris Wilson wrote:
 On Fri, Mar 20, 2015 at 04:33:08PM +0100, Daniel Vetter wrote:
  On Fri, Mar 20, 2015 at 03:04:39PM +, Chris Wilson wrote:
   The retire comes before the before the gpu_idle (we retire often as a
   part of busy, execbuffer, timers etc). The traces show exactly that.
  
  Yeah, the sequence I see is:
  1. retire requests leaves active objects behind with all requests retired.
  2. evict_vim
  |- 2a. gpu_idle
  |- 2b. retire_requests
  |- 2c. WARN_ON(i915_gem_evict_vm);
  
  I agree with you that before the call to evict_vm the lists are
  inconsistent. What I don't understand how that inconsistency can get past
  the 2a/2b double-punch.
 
 2a/2b are both no-ops in this scenario.

Lifted blindfolds, finally found the short-circuit

if (list_empty(ring-request_list))
return;

at the top of i915_gem_retire_requests_ring.

Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch

and for -fixes since the offending patch is in 4.0-rc1.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Use usleep_range() in wait_for()

2015-03-23 Thread Daniel Vetter
On Fri, Mar 20, 2015 at 12:31:16PM -0700, Jesse Barnes wrote:
 On 03/20/2015 12:28 PM, ville.syrj...@linux.intel.com wrote:
  From: Ville Syrjälä ville.syrj...@linux.intel.com
  
  msleep() can sleep for way too long, so switch wait_for() to use
  usleep_range() instead. Following a totally unscientific method
  I just picked the range as W-2W.
  
  This cuts the i915 init time on my BSW to almost half:
  - initcall i915_init+0x0/0xa8 [i915] returned 0 after 419977 usecs
  + initcall i915_init+0x0/0xa8 [i915] returned 0 after 238419 usecs
  
  Note that I didn't perform any other benchmarks on this so far.
  
  Cc: Jesse Barnes jbar...@virtuousgeek.org
  Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
  ---
   drivers/gpu/drm/i915/intel_drv.h | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)
  
  diff --git a/drivers/gpu/drm/i915/intel_drv.h 
  b/drivers/gpu/drm/i915/intel_drv.h
  index 6f20f3a..d2a4de0 100644
  --- a/drivers/gpu/drm/i915/intel_drv.h
  +++ b/drivers/gpu/drm/i915/intel_drv.h
  @@ -56,8 +56,8 @@
  ret__ = -ETIMEDOUT; \
  break;  \
  }   \
  -   if (W  drm_can_sleep())  {\
  -   msleep(W);  \
  +   if ((W)  drm_can_sleep()) {   \
  +   usleep_range((W)*1000, (W)*2000);   \
  } else {\
  cpu_relax();\
  }   \
  
 
 Nice improvement!  I guess it's just because usleep_range() uses an
 hrtimeout, but since we have the added slop of the range it may actually
 be an improvement, power-wise too.
 
 Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org

Nice indeed. Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 16/19] drm/i915: Check lane sharing between pipes B C using atomic state

2015-03-23 Thread Ander Conselvan De Oliveira
On Sun, 2015-03-22 at 16:20 +, Konduru, Chandra wrote:
 
 
  -Original Message-
  From: Conselvan De Oliveira, Ander
  Sent: Thursday, March 19, 2015 11:46 PM
  To: Konduru, Chandra
  Cc: intel-gfx@lists.freedesktop.org
  Subject: Re: [PATCH 16/19] drm/i915: Check lane sharing between pipes B  C
  using atomic state
  
  On Thu, 2015-03-19 at 20:58 +, Konduru, Chandra wrote:
  
-Original Message-
From: Conselvan De Oliveira, Ander
Sent: Friday, March 13, 2015 2:49 AM
To: intel-gfx@lists.freedesktop.org
Cc: Konduru, Chandra; Conselvan De Oliveira, Ander
Subject: [PATCH 16/19] drm/i915: Check lane sharing between pipes B
 C using atomic state
   
Makes that code atomic ready.
   
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
 drivers/gpu/drm/i915/intel_display.c | 49
++-
-
 1 file changed, 42 insertions(+), 7 deletions(-)
   
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e720a48..8c97186 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5537,13 +5537,20 @@ bool intel_connector_get_hw_state(struct
intel_connector *connector)
return encoder-get_hw_state(encoder, pipe);  }
   
-static int pipe_required_fdi_lanes(struct drm_device *dev, enum
pipe pipe)
+static int pipe_required_fdi_lanes(struct drm_atomic_state *state,
+  enum pipe pipe)
 {
struct intel_crtc *crtc =
-   to_intel_crtc(intel_get_crtc_for_pipe(dev, pipe));
+   to_intel_crtc(intel_get_crtc_for_pipe(state-dev, 
pipe));
+   struct intel_crtc_state *crtc_state;
+
+   crtc_state = intel_atomic_get_crtc_state(state, crtc);
+   if (WARN_ON(IS_ERR(crtc_state))) {
+   /* Cause modeset to fail due to excess lanes. */
+   return 5;
+   }
   
-   if (crtc-base.state-enable 
-   crtc-config-has_pch_encoder)
+   if (crtc_state-base.enable  crtc_state-has_pch_encoder)
return crtc-config-fdi_lanes;
   
return 0;
@@ -5552,6 +5559,8 @@ static int pipe_required_fdi_lanes(struct
drm_device *dev, enum pipe pipe)  static bool
ironlake_check_fdi_lanes(struct drm_device *dev, enum pipe pipe,
 struct intel_crtc_state 
*pipe_config)  {
+   struct drm_atomic_state *state = pipe_config-base.state;
+
DRM_DEBUG_KMS(checking fdi config on pipe %c, lanes %i\n,
  pipe_name(pipe), pipe_config-fdi_lanes);
if (pipe_config-fdi_lanes  4) {
@@ -5579,7 +5588,7 @@ static bool ironlake_check_fdi_lanes(struct
drm_device *dev, enum pipe pipe,
return true;
case PIPE_B:
if (pipe_config-fdi_lanes  2 
-   pipe_required_fdi_lanes(dev, PIPE_C)  0) {
+   pipe_required_fdi_lanes(state, PIPE_C)  0) {
DRM_DEBUG_KMS(invalid shared fdi lane config on
  pipe %c: %i
lanes\n,
  pipe_name(pipe), 
pipe_config-fdi_lanes);
return false;
@@ -5591,7 +5600,7 @@ static bool ironlake_check_fdi_lanes(struct
drm_device *dev, enum pipe pipe,
  pipe_name(pipe), 
pipe_config-fdi_lanes);
return false;
}
-   if (pipe_required_fdi_lanes(dev, PIPE_B)  2) {
+   if (pipe_required_fdi_lanes(state, PIPE_B)  2) {
DRM_DEBUG_KMS(fdi link B uses too many lanes to
  enable link
C\n);
return false;
}
@@ -5601,15 +5610,41 @@ static bool ironlake_check_fdi_lanes(struct
drm_device *dev, enum pipe pipe,
}
 }
   
+static int add_pipe_b_c_to_state(struct drm_atomic_state *state) {
+   struct intel_crtc *pipe_B =
+   to_intel_crtc(intel_get_crtc_for_pipe(state-dev, 
PIPE_B));
+   struct intel_crtc *pipe_C =
+   to_intel_crtc(intel_get_crtc_for_pipe(state-dev, 
PIPE_C));
+   struct intel_crtc_state *crtc_state;
+
+   crtc_state = intel_atomic_get_crtc_state(state, pipe_B);
+   if (IS_ERR(crtc_state))
+   return PTR_ERR(crtc_state);
+
+   crtc_state = intel_atomic_get_crtc_state(state, pipe_C);
+   if (IS_ERR(crtc_state))
+   return PTR_ERR(crtc_state);
+
+   return 0;
+}
+
 #define RETRY 1
 static int ironlake_fdi_compute_config(struct intel_crtc *intel_crtc,
   struct 

Re: [Intel-gfx] [PATCH] drm/i915: Keep ring-active_list and ring-requests_list consistent

2015-03-23 Thread Chris Wilson
On Mon, Mar 23, 2015 at 09:13:36AM +, Chris Wilson wrote:
 On Mon, Mar 23, 2015 at 09:49:15AM +0100, Daniel Vetter wrote:
  In case it's burried too much in the thread:
  
  Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
  
  Addadendum for the commit:
  
  Note that this is only a problem in evict_vm where the following happens
  after a retire_request has cleaned out all requests, but not all active
  bo:
  - intel_ring_idle called from i915_gpu_idle notices that no requests are
outstanding and immediately returns.
  - i915_gem_retire_requests_ring called from i915_gem_retire_requests also
immediately returns when there's no request, still leaving the bo on the
active list.
  - evict_vm hits the WARN_ON(!list_empty(vm-active_list)) after evicting
all active objects that there's still stuff left that shouldn't be
there.
  
  Chris, is that an accurate enough description for Jani to add to the
  patch?
 
 Not quite. It affects everywhere where we rely on i915_gpu_idle() idling
 the gpu (e.g. suspend), it is only the canary in i915_gem_evict_vm()
 that first alerted us to the bug. Maybe we have some recent weird bugs in
 suspend (or it may be too soon for those reports to start trickling in)?

I take that back. The gpu is idle (no more requests). It's just the
bookkeeping that's wrong (and that only affects eviction iirc).

I stand corrected.
-Chris

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


Re: [Intel-gfx] [PATCH 01/49] drm/i915/bxt: Add BXT PCI ids

2015-03-23 Thread Antti Koskipää
Reviewed-by: Antti Koskipää antti.koski...@linux.intel.com

On 03/17/2015 11:39 AM, Imre Deak wrote:
 From: Damien Lespiau damien.lesp...@intel.com
 
 v2: Switch to info-ring_mask and add VEBOX support.
 v3: Fold in update from Damien.
 v4: Add GEN_DEFAULT_PIPEOFFSETS and IVB_CURSOR_OFFSETS
 v5: set no-LLC (imre)
 
 Signed-off-by: Damien Lespiau damien.lesp...@intel.com (v1,v4)
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch (v4)
 Signed-off-by: Imre Deak imre.d...@intel.com
 ---
  drivers/gpu/drm/i915/i915_drv.c | 14 +-
  include/drm/i915_pciids.h   |  6 ++
  2 files changed, 19 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
 index 82f8be4..4d50785 100644
 --- a/drivers/gpu/drm/i915/i915_drv.c
 +++ b/drivers/gpu/drm/i915/i915_drv.c
 @@ -381,6 +381,17 @@ static const struct intel_device_info 
 intel_skylake_gt3_info = {
   IVB_CURSOR_OFFSETS,
  };
  
 +static const struct intel_device_info intel_broxton_info = {
 + .is_preliminary = 1,
 + .gen = 9,
 + .need_gfx_hws = 1, .has_hotplug = 1,
 + .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
 + .num_pipes = 3,
 + .has_ddi = 1,
 + GEN_DEFAULT_PIPEOFFSETS,
 + IVB_CURSOR_OFFSETS,
 +};
 +
  /*
   * Make sure any device matches here are from most specific to most
   * general.  For example, since the Quanta match is based on the subsystem
 @@ -420,7 +431,8 @@ static const struct intel_device_info 
 intel_skylake_gt3_info = {
   INTEL_CHV_IDS(intel_cherryview_info),  \
   INTEL_SKL_GT1_IDS(intel_skylake_info), \
   INTEL_SKL_GT2_IDS(intel_skylake_info), \
 - INTEL_SKL_GT3_IDS(intel_skylake_gt3_info)  \
 + INTEL_SKL_GT3_IDS(intel_skylake_gt3_info), \
 + INTEL_BXT_IDS(intel_broxton_info)
  
  static const struct pci_device_id pciidlist[] = {/* aka */
   INTEL_PCI_IDS,
 diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
 index 6133723..bd0d644 100644
 --- a/include/drm/i915_pciids.h
 +++ b/include/drm/i915_pciids.h
 @@ -287,4 +287,10 @@
   INTEL_SKL_GT3_IDS(info)
  
  
 +#define INTEL_BXT_IDS(info) \
 + INTEL_VGA_DEVICE(0x0A84, info), \
 + INTEL_VGA_DEVICE(0x0A85, info), \
 + INTEL_VGA_DEVICE(0x0A86, info), \
 + INTEL_VGA_DEVICE(0x0A87, info)
 +
  #endif /* _I915_PCIIDS_H */
 

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


Re: [Intel-gfx] [PATCH 51/59] drm/i915: Add *_ring_begin() to request allocation

2015-03-23 Thread Daniel Vetter
On Fri, Mar 20, 2015 at 04:09:55PM +, John Harrison wrote:
 On 20/03/2015 15:30, Chris Wilson wrote:
 On Fri, Mar 20, 2015 at 04:23:45PM +0100, Daniel Vetter wrote:
 On Thu, Mar 19, 2015 at 12:30:56PM +, john.c.harri...@intel.com wrote:
 diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
 b/drivers/gpu/drm/i915/intel_ringbuffer.c
 index 6f198df..c7dcabd 100644
 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
 +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
 @@ -2205,21 +2205,27 @@ int intel_ring_alloc_request_extras(struct 
 drm_i915_gem_request *request)
return 0;
   }
 -int intel_ring_reserved_space_reserve(struct intel_ringbuffer *ringbuf, 
 int size)
 +int legacy_ring_reserved_space_reserve(struct drm_i915_gem_request 
 *request)
   {
 -  /* NB: Until request management is fully tidied up and the OLR is
 -   * removed, there are too many ways for get false hits on this
 -   * anti-recursion check! */
 -  /*WARN_ON(ringbuf-reserved_size);*/
 +  /*
 +   * The first call merely notes the reserve request and is common for
 +   * all back ends. The subsequent localised _begin() call actually
 +   * ensures that the reservation is available. Without the begin, if
 +   * the request creator immediately submitted the request without
 +   * adding any commands to it then there might not actually be
 +   * sufficient room for the submission commands.
 +   */
 +  intel_ring_reserved_space_reserve(request-ringbuf, 
 MIN_SPACE_FOR_ADD_REQUEST);
 +
 +  return intel_ring_begin(request, 0);
 This feels a bit convoluted tbh, and would fall aparat if we start adding
 sanity checks to _begin/advance functions. Can't we instead directly call
 ring_wait_for_space? This forgoes the intel_wrap_ring_buffer call, but
 otoh we just need to factor that into our estimates. Wrapping the ring for
 the entire reservartion right away is
 a) way too much - we only wrap individual ring_being calls anyway
 b) not doing any good since all the intermediate intel_ring_emit calls
 might very-well push us into a wrap anyway.
 
 In the end we just need to increase our reservation with the biggest
 intel_ring_begin we have in the add_request code - that's the worst-case
 of ring space we might waste due to wrapping.

 I don't see why sanity checks in begin/advance would be a problem. This
 _begin() call is only required in the situation where no-one actually adds
 any commands to the ring before calling i915_add_request() and then is only
 necessary because i915_add_request() is not allowed to call _begin() any
 more because it is not allowed to fail. There is no magic going on behind
 the scenes. It is exactly the same as calling '_begin(RESERVED_SIZE)'. All
 subsequent code must still do it's own _begin() call before adding commands
 to the ring. Any sanity checks would ignore the reserved size and complain
 if a _begin() is too small for the commands actually written. It should all
 just work :). Plus it is nice and simple and easy to maintain.
 
 Also, I don't see why it is better to do the wrap as late as possible. If a
 wrap is going to be required at some point then it doesn't really matter
 when it is done - early or late, the (small) hit still has to be taken.
 Given that the buffer size is orders of magnitude larger than the size of an
 individual request, there is no possibility of ever having to wrap twice. So
 I would say that keeping the code nice and simple outweighs any advantage to
 wrapping a few calls later.

Ok two examples:

1. We have 100 bytes add request tail that we reserve, but only 80 bytes
left before wrapping. Your reservation code will wrap.

Let's also assume we have 160 bytes of execbuf stuff in 20bytes block. If
we would not have wrapped right away we'd save those 80 bytes of wrapping.
Eager wrapping just wasted space.

2. Again 100 bytes of reservation, 160 bytes of execbuf. But this time
around assume we have 200 bytes left before wrap. Your reservation
doesn't wrap since there's still 100 bytes left. But after the execbuf
there's only 40 bytes left, requiring a wrap. Eager wrapping didn't help
at all for correct reservation. Which means we _have_ to include the
worst-case loss for wrapping into our reservation, and more important the
reservation check _must_ handle wrapping correctly. Since that's the case
where things will fall appart if the reservation is just a bit too small.

Hence my recommendation to only reserve the space and not bother with
wrapping (it's a net loss) and also make sure we catch any kind of
overflow due to wrapping.

We could instead try to keep wrapping into account for the reserved space,
but I think that's more fragile. It's also more wasteful since generally
we don't need a 100 byte contiguous block but just a few dwords for each
individual command. So effective wrapping overhead is a lot less than
100-4.

Finally imo shrugging the double-wrap off isn't a good idea since emitting
a lot of crap by accident is a very likely bug. And with the guc
scheduling mode I've 

Re: [Intel-gfx] [PATCH 01/21 v2] drm/i915: Adding drm helper function drm_plane_from_index().

2015-03-23 Thread Daniel Vetter
On Fri, Mar 20, 2015 at 05:04:22PM -0700, Chandra Konduru wrote:
 Adding drm helper function to return plane pointer from index where
 index is a returned by drm_plane_index.
 
 v2:
 -avoided nested loop by adding loop count (Daniel)
 
 Signed-off-by: Chandra Konduru chandra.kond...@intel.com

Sorry forgotten to mention this earlier, but any code touching drm core
must be cc'ed to dri-devel. Best to just add a Cc: line before the sob
line so that git send-email automatically picks it up every time.
-Daniel

 ---
  drivers/gpu/drm/drm_crtc.c |   22 ++
  include/drm/drm_crtc.h |1 +
  2 files changed, 23 insertions(+)
 
 diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
 index 9f970c2..b6703f4 100644
 --- a/drivers/gpu/drm/drm_crtc.c
 +++ b/drivers/gpu/drm/drm_crtc.c
 @@ -1286,6 +1286,28 @@ unsigned int drm_plane_index(struct drm_plane *plane)
  EXPORT_SYMBOL(drm_plane_index);
  
  /**
 + * drm_plane_from_index - find the registered plane at an index
 + * @idx: index of registered plane to find for
 + *
 + * Given a plane index, return the registered plane from DRM device's
 + * list of planes with matching index.
 + */
 +struct drm_plane *
 +drm_plane_from_index(struct drm_device *dev, int idx)
 +{
 + struct drm_plane *plane;
 + unsigned int i = 0;
 +
 + list_for_each_entry(plane, dev-mode_config.plane_list, head) {
 + if (i == idx)
 + return plane;
 + i++;
 + }
 + return NULL;
 +}
 +EXPORT_SYMBOL(drm_plane_from_index);
 +
 +/**
   * drm_plane_force_disable - Forcibly disable a plane
   * @plane: plane to disable
   *
 diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
 index 7b5c661..6b30036 100644
 --- a/include/drm/drm_crtc.h
 +++ b/include/drm/drm_crtc.h
 @@ -1264,6 +1264,7 @@ extern int drm_plane_init(struct drm_device *dev,
 bool is_primary);
  extern void drm_plane_cleanup(struct drm_plane *plane);
  extern unsigned int drm_plane_index(struct drm_plane *plane);
 +extern struct drm_plane * drm_plane_from_index(struct drm_device *dev, int 
 idx);
  extern void drm_plane_force_disable(struct drm_plane *plane);
  extern int drm_plane_check_pixel_format(const struct drm_plane *plane,
   u32 format);
 -- 
 1.7.9.5
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


Re: [Intel-gfx] [PATCH] drm/i915: Use usleep_range() in wait_for()

2015-03-23 Thread Ville Syrjälä
On Fri, Mar 20, 2015 at 09:09:51PM +, Chris Wilson wrote:
 On Fri, Mar 20, 2015 at 09:28:08PM +0200, ville.syrj...@linux.intel.com wrote:
  From: Ville Syrjälä ville.syrj...@linux.intel.com
  
  msleep() can sleep for way too long, so switch wait_for() to use
  usleep_range() instead. Following a totally unscientific method
  I just picked the range as W-2W.
  
  This cuts the i915 init time on my BSW to almost half:
  - initcall i915_init+0x0/0xa8 [i915] returned 0 after 419977 usecs
  + initcall i915_init+0x0/0xa8 [i915] returned 0 after 238419 usecs
  
  Note that I didn't perform any other benchmarks on this so far.
  
  Cc: Jesse Barnes jbar...@virtuousgeek.org
  Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
 
 Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
 
 Hmm, I think we can improve further with a more variable sleep. The
 maximum we pass to wait_for() is usually plucked from somewhere in the
 spec (or is just a safety factor). Either way, it is a good guide as to
 how to actually sleep for - if say we try to only sample 1000 times up
 to the maximum:
 
 if (do_sleep  drm_can_sleep()) {
   usleep_range((MS), 10*(MS));
 }
 
 So whilst you have a situation where we clearly sleep too long between
 sampling (a register), it would be beneficial to start adding some debug
 infrastructure. Or even better if usleep_range already does it for us...

Yeah, it would be nice to have some more information about how long we
sleep typically in each case.

We could perhaps then even micro optimize the 'set knob - poll for knob
to become active' pattern by doing a preemptive sleep between the set
and poll steps in the hopes that we don't have to check the condition
more than once. Not sure that would be worth the effort though.

-- 
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] tests/kms_psr_sink_crc: Make render visible to human eyes

2015-03-23 Thread Vivi, Rodrigo
On Mon, 2015-03-23 at 09:36 +0100, Daniel Vetter wrote:
 On Mon, Mar 23, 2015 at 09:35:27AM +0100, Daniel Vetter wrote:
  On Fri, Mar 20, 2015 at 05:43:40PM +, Vivi, Rodrigo wrote:
   On Fri, 2015-03-20 at 10:54 +0100, Daniel Vetter wrote:
On Thu, Mar 19, 2015 at 06:24:24PM -0700, Rodrigo Vivi wrote:
 This will allow manual tests when crc isn't available.
 
 v2: Remove unused and non-sense buf-size and decrease buf-stride a 
 bit as suggested by Daniel.

buf-size isn't nonsense really, it does seem to match what we've
allocated. But it also seems unused in the rendercpy functions I've
checked. Imo you should keep that line
   
   oh sure, bad phrase the value 4 was nonsense.
   But if I increases that it fails. Without setting it works.
   What do you think?
  
  If just keeping that line makes the test work there's something _really_
  fishy going on. If it persists after git clean -dfx and full recompile I'd
  dig into it, since this really doesn't make sense.

But what are the values of size and stride you believe it should work in
a actual visible way?

 
 valgrined might be the best tool for a first attempt at figuring out
 what's wrong.
 -Daniel

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


Re: [Intel-gfx] [PATCH 1/2] drm/i915: fix race when clearing RPS IIR bits

2015-03-23 Thread Chris Wilson
On Mon, Mar 23, 2015 at 07:11:34PM +0200, Imre Deak wrote:
 When disabling RPS interrupts there is a race where we disable RPS
 inerrupts while the interrupt handler is running and the handler has
 already latched the pending RPS interrupt from the master IIR register.
 Afterwards the disabling path clears the PM IIR bits, making the state
 of pending interrupts inconsistent from the interrupt handler's point of
 view. This triggers the following warning: The master control interrupt
 lied (PM)!.
 
 To fix this make sure that any running interrupt handler (which may
 have already latched the master IIR) finishes before clearing the IIR
 bits.
 

Isn't this overkill for what is just a bogus WARN? If the WARN is a
logical consequence of the code, let's just remove the WARN.

Or iow can you not find a cheaper way to fix this?
-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/4] kernel.h: Implement DIV_ROUND_CLOSEST_ULL

2015-03-23 Thread Javi Merino
On Mon, Mar 23, 2015 at 12:34:04PM +, Jeff Epler wrote:
 On Fri, Mar 20, 2015 at 11:14:40AM +, Javi Merino wrote:
  +/*
  + * Same as above but for u64 dividends.  divisor must be a 32-bit
  + * number.
  + */
  +#define DIV_ROUND_CLOSEST_ULL(x, divisor)( \
  +{  \
  +   unsigned long long _tmp = (x) + (divisor) / 2;  \
  +   do_div(_tmp, divisor);  \
  +   _tmp;   \
  +}  \
  +)
 
 The macro evaluates 'divisor' twice.

Good catch.  That needs to be fixed.  I could do the typeof trick that
DIV_ROUND_CLOSEST() does but it's probably better to just create a
static function as Alex Elder suggests.  I'll send a v2 tomorrow with
a static function instead.

Cheers,
Javi

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


[Intel-gfx] [PATCH 1/2] drm/i915: fix race when clearing RPS IIR bits

2015-03-23 Thread Imre Deak
When disabling RPS interrupts there is a race where we disable RPS
inerrupts while the interrupt handler is running and the handler has
already latched the pending RPS interrupt from the master IIR register.
Afterwards the disabling path clears the PM IIR bits, making the state
of pending interrupts inconsistent from the interrupt handler's point of
view. This triggers the following warning: The master control interrupt
lied (PM)!.

To fix this make sure that any running interrupt handler (which may
have already latched the master IIR) finishes before clearing the IIR
bits.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87347
Signed-off-by: Imre Deak imre.d...@intel.com
---
 drivers/gpu/drm/i915/i915_irq.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 6d8340d..7afbde4 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -330,6 +330,13 @@ void gen6_disable_rps_interrupts(struct drm_device *dev)
__gen6_disable_pm_irq(dev_priv, dev_priv-pm_rps_events);
I915_WRITE(gen6_pm_ier(dev_priv), I915_READ(gen6_pm_ier(dev_priv)) 
~dev_priv-pm_rps_events);
+
+   spin_unlock_irq(dev_priv-irq_lock);
+
+   synchronize_irq(dev-irq);
+
+   spin_lock_irq(dev_priv-irq_lock);
+
I915_WRITE(gen6_pm_iir(dev_priv), dev_priv-pm_rps_events);
I915_WRITE(gen6_pm_iir(dev_priv), dev_priv-pm_rps_events);
 
-- 
2.1.0

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


[Intel-gfx] [PATCH 2/2] drm/i915: move clearing of RPS interrupt bits from disable to reset time

2015-03-23 Thread Imre Deak
The logical place for clearing the RPS latched interrupt bits is when
resetting the RPS interrupts, so move the corresponding part from the RPS
disable function to the reset function. During resetting we already
cleared the IIR bits, so the only thing missing there was clearing pm_iir.

Note that we call gen6_disable_rps_interrupts() also during driver load
and resume time via intel_uncore_sanitize() when i915 interrupts are
still not installed. If there are any pending RPS bits at this point
(which after this patch wouldn't be cleared) they will be cleared by the
reset code via the interrupt preinstall hooks.

Signed-off-by: Imre Deak imre.d...@intel.com
---
 drivers/gpu/drm/i915/i915_irq.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 7afbde4..14ecb4d 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -277,6 +277,7 @@ void gen6_reset_rps_interrupts(struct drm_device *dev)
I915_WRITE(reg, dev_priv-pm_rps_events);
I915_WRITE(reg, dev_priv-pm_rps_events);
POSTING_READ(reg);
+   dev_priv-rps.pm_iir = 0;
spin_unlock_irq(dev_priv-irq_lock);
 }
 
@@ -334,15 +335,6 @@ void gen6_disable_rps_interrupts(struct drm_device *dev)
spin_unlock_irq(dev_priv-irq_lock);
 
synchronize_irq(dev-irq);
-
-   spin_lock_irq(dev_priv-irq_lock);
-
-   I915_WRITE(gen6_pm_iir(dev_priv), dev_priv-pm_rps_events);
-   I915_WRITE(gen6_pm_iir(dev_priv), dev_priv-pm_rps_events);
-
-   dev_priv-rps.pm_iir = 0;
-
-   spin_unlock_irq(dev_priv-irq_lock);
 }
 
 /**
-- 
2.1.0

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


Re: [Intel-gfx] [PATCH 01/21 v2] drm/i915: Adding drm helper function drm_plane_from_index().

2015-03-23 Thread Konduru, Chandra


 -Original Message-
 From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
 Sent: Monday, March 23, 2015 2:33 AM
 To: Konduru, Chandra
 Cc: intel-gfx@lists.freedesktop.org; Conselvan De Oliveira, Ander; Vetter, 
 Daniel
 Subject: Re: [Intel-gfx] [PATCH 01/21 v2] drm/i915: Adding drm helper function
 drm_plane_from_index().
 
 On Fri, Mar 20, 2015 at 05:04:22PM -0700, Chandra Konduru wrote:
  Adding drm helper function to return plane pointer from index where
  index is a returned by drm_plane_index.
 
  v2:
  -avoided nested loop by adding loop count (Daniel)
 
  Signed-off-by: Chandra Konduru chandra.kond...@intel.com
 
 Sorry forgotten to mention this earlier, but any code touching drm core must 
 be
 cc'ed to dri-devel. Best to just add a Cc: line before the sob line so that 
 git send-
 email automatically picks it up every time.
 -Daniel

np, sure.
By the way, copied dri-devel.

 
  ---
   drivers/gpu/drm/drm_crtc.c |   22 ++
   include/drm/drm_crtc.h |1 +
   2 files changed, 23 insertions(+)
 
  diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
  index 9f970c2..b6703f4 100644
  --- a/drivers/gpu/drm/drm_crtc.c
  +++ b/drivers/gpu/drm/drm_crtc.c
  @@ -1286,6 +1286,28 @@ unsigned int drm_plane_index(struct drm_plane
  *plane)  EXPORT_SYMBOL(drm_plane_index);
 
   /**
  + * drm_plane_from_index - find the registered plane at an index
  + * @idx: index of registered plane to find for
  + *
  + * Given a plane index, return the registered plane from DRM device's
  + * list of planes with matching index.
  + */
  +struct drm_plane *
  +drm_plane_from_index(struct drm_device *dev, int idx) {
  +   struct drm_plane *plane;
  +   unsigned int i = 0;
  +
  +   list_for_each_entry(plane, dev-mode_config.plane_list, head) {
  +   if (i == idx)
  +   return plane;
  +   i++;
  +   }
  +   return NULL;
  +}
  +EXPORT_SYMBOL(drm_plane_from_index);
  +
  +/**
* drm_plane_force_disable - Forcibly disable a plane
* @plane: plane to disable
*
  diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index
  7b5c661..6b30036 100644
  --- a/include/drm/drm_crtc.h
  +++ b/include/drm/drm_crtc.h
  @@ -1264,6 +1264,7 @@ extern int drm_plane_init(struct drm_device *dev,
bool is_primary);
   extern void drm_plane_cleanup(struct drm_plane *plane);  extern
  unsigned int drm_plane_index(struct drm_plane *plane);
  +extern struct drm_plane * drm_plane_from_index(struct drm_device
  +*dev, int idx);
   extern void drm_plane_force_disable(struct drm_plane *plane);  extern
  int drm_plane_check_pixel_format(const struct drm_plane *plane,
  u32 format);
  --
  1.7.9.5
 
  ___
  Intel-gfx mailing list
  Intel-gfx@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/intel-gfx
 
 --
 Daniel Vetter
 Software Engineer, Intel Corporation
 http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 16/19] drm/i915: Check lane sharing between pipes B C using atomic state

2015-03-23 Thread Konduru, Chandra


 -Original Message-
 From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
 Sent: Monday, March 23, 2015 12:34 AM
 To: Konduru, Chandra
 Cc: intel-gfx@lists.freedesktop.org
 Subject: Re: [PATCH 16/19] drm/i915: Check lane sharing between pipes B  C
 using atomic state
 
 On Sun, 2015-03-22 at 16:20 +, Konduru, Chandra wrote:
 
 
   -Original Message-
   From: Conselvan De Oliveira, Ander
   Sent: Thursday, March 19, 2015 11:46 PM
   To: Konduru, Chandra
   Cc: intel-gfx@lists.freedesktop.org
   Subject: Re: [PATCH 16/19] drm/i915: Check lane sharing between
   pipes B  C using atomic state
  
   On Thu, 2015-03-19 at 20:58 +, Konduru, Chandra wrote:
   
 -Original Message-
 From: Conselvan De Oliveira, Ander
 Sent: Friday, March 13, 2015 2:49 AM
 To: intel-gfx@lists.freedesktop.org
 Cc: Konduru, Chandra; Conselvan De Oliveira, Ander
 Subject: [PATCH 16/19] drm/i915: Check lane sharing between
 pipes B  C using atomic state

 Makes that code atomic ready.

 Signed-off-by: Ander Conselvan de Oliveira
 ander.conselvan.de.olive...@intel.com
 ---
  drivers/gpu/drm/i915/intel_display.c | 49
 ++-
 -
  1 file changed, 42 insertions(+), 7 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_display.c
 b/drivers/gpu/drm/i915/intel_display.c
 index e720a48..8c97186 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -5537,13 +5537,20 @@ bool intel_connector_get_hw_state(struct
 intel_connector *connector)
   return encoder-get_hw_state(encoder, pipe);  }

 -static int pipe_required_fdi_lanes(struct drm_device *dev, enum
 pipe pipe)
 +static int pipe_required_fdi_lanes(struct drm_atomic_state *state,
 +enum pipe pipe)
  {
   struct intel_crtc *crtc =
 - to_intel_crtc(intel_get_crtc_for_pipe(dev, pipe));
 + to_intel_crtc(intel_get_crtc_for_pipe(state-dev,
 pipe));
 + struct intel_crtc_state *crtc_state;
 +
 + crtc_state = intel_atomic_get_crtc_state(state, crtc);
 + if (WARN_ON(IS_ERR(crtc_state))) {
 + /* Cause modeset to fail due to excess lanes. */
 + return 5;
 + }

 - if (crtc-base.state-enable 
 - crtc-config-has_pch_encoder)
 + if (crtc_state-base.enable  crtc_state-has_pch_encoder)
   return crtc-config-fdi_lanes;

   return 0;
 @@ -5552,6 +5559,8 @@ static int pipe_required_fdi_lanes(struct
 drm_device *dev, enum pipe pipe)  static bool
 ironlake_check_fdi_lanes(struct drm_device *dev, enum pipe pipe,
struct intel_crtc_state 
 *pipe_config)  {
 + struct drm_atomic_state *state = pipe_config-base.state;
 +
   DRM_DEBUG_KMS(checking fdi config on pipe %c, lanes %i\n,
 pipe_name(pipe), pipe_config-fdi_lanes);
   if (pipe_config-fdi_lanes  4) { @@ -5579,7 +5588,7 @@ static
 bool ironlake_check_fdi_lanes(struct drm_device *dev, enum pipe
 pipe,
   return true;
   case PIPE_B:
   if (pipe_config-fdi_lanes  2 
 - pipe_required_fdi_lanes(dev, PIPE_C)  0) {
 + pipe_required_fdi_lanes(state, PIPE_C)  0) {
   DRM_DEBUG_KMS(invalid shared fdi lane config on
   pipe %c: %i
 lanes\n,
 pipe_name(pipe), 
 pipe_config-fdi_lanes);
   return false;
 @@ -5591,7 +5600,7 @@ static bool
 ironlake_check_fdi_lanes(struct drm_device *dev, enum pipe pipe,
 pipe_name(pipe), 
 pipe_config-fdi_lanes);
   return false;
   }
 - if (pipe_required_fdi_lanes(dev, PIPE_B)  2) {
 + if (pipe_required_fdi_lanes(state, PIPE_B)  2) {
   DRM_DEBUG_KMS(fdi link B uses too many lanes to
   enable link
 C\n);
   return false;
   }
 @@ -5601,15 +5610,41 @@ static bool
 ironlake_check_fdi_lanes(struct drm_device *dev, enum pipe pipe,
   }
  }

 +static int add_pipe_b_c_to_state(struct drm_atomic_state *state) {
 + struct intel_crtc *pipe_B =
 + to_intel_crtc(intel_get_crtc_for_pipe(state-dev,
 PIPE_B));
 + struct intel_crtc *pipe_C =
 + to_intel_crtc(intel_get_crtc_for_pipe(state-dev,
 PIPE_C));
 + struct intel_crtc_state *crtc_state;
 +
 + crtc_state = intel_atomic_get_crtc_state(state, pipe_B);
 + if (IS_ERR(crtc_state))
 + return PTR_ERR(crtc_state);
 +
 + crtc_state = 

[Intel-gfx] [PATCH] tests/kms_drrs: fb change notification through debugfs

2015-03-23 Thread Ramalingam C
At present there are some functional issues at front buffer tracking.
So to test the DRRS feature and the DRRS test apps, we have added a
debugfs to provide the fb change notification. Corresponding calls
implemented in this change

DO NOT MERGE: As this is a temperary fix to test the DRRS independent
of the front buffer tracking. This will be dropped once the front buffer
tracking is fixed.

Signed-off-by: Ramalingam C ramalinga...@intel.com
---
 tests/kms_drrs.c |   71 ++
 1 file changed, 71 insertions(+)

diff --git a/tests/kms_drrs.c b/tests/kms_drrs.c
index 91bda5c..8e2338d 100644
--- a/tests/kms_drrs.c
+++ b/tests/kms_drrs.c
@@ -37,6 +37,20 @@ IGT_TEST_DESCRIPTION(
 
 #define DRRS_STATUS_BYTES_CNT  1000
 
+#define INTEL_FRONTBUFFER_BITS_PER_PIPE 4
+#define INTEL_FRONTBUFFER_BITS \
+   (INTEL_FRONTBUFFER_BITS_PER_PIPE * I915_MAX_PIPES)
+#define INTEL_FRONTBUFFER_PRIMARY(pipe) \
+   (1  (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
+#define INTEL_FRONTBUFFER_CURSOR(pipe) \
+   (1  (1 + (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe
+#define INTEL_FRONTBUFFER_SPRITE(pipe) \
+   (1  (2 + (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe
+#define INTEL_FRONTBUFFER_OVERLAY(pipe) \
+   (1  (3 + (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe
+#define INTEL_FRONTBUFFER_ALL_MASK(pipe) \
+   (0xf  (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
+
 typedef struct {
int drm_fd;
uint32_t devid;
@@ -126,6 +140,36 @@ static bool is_drrs_state(data_t *data, const char str[15])
return strstr(status, str) != NULL;
 
 }
+/*
+ * drrs_fb_status_update:
+ *
+ * drm front buffer tracking is not notifying the FB status change in
+ * many cases.
+ * Hence to test the DRRS module independently we are providing the DRRS
+ * invalidate and flush calls through a debugfs. NOTE: Additional kernel
+ * patch is required to add the required debugfs and to detach the DRRS module
+ * from the front buffer tracking implementation
+ */
+static void drrs_fb_status_update(data_t *data, unsigned fb_status_bits,
+   bool rendered)
+{
+   FILE *ctl;
+   size_t written;
+   struct fb_status fb_status;
+
+   igt_info(Entry to drrs_fb_status_update with fb_status_bits %u\n,
+   fb_status_bits);
+
+   ctl = igt_debugfs_fopen(i915_drrs_fb_status, r+);
+
+   fb_status.rendered = rendered;
+   fb_status.fb_bits = fb_status_bits;
+
+   written = fwrite(fb_status, sizeof(fb_status), 1, ctl);
+   igt_assert_eq(written, 1);
+
+   fclose(ctl);
+}
 
 static bool prepare_crtc(data_t *data)
 {
@@ -196,6 +240,15 @@ static bool execute_test(data_t *data)
return false;
}
 
+   /*
+* FIXME: When Front buffer tracking is fixed, remove
+* next two function calls.
+*/
+   drrs_fb_status_update(data, INTEL_FRONTBUFFER_PRIMARY(data-pipe),
+   false);
+   drrs_fb_status_update(data, INTEL_FRONTBUFFER_PRIMARY(data-pipe),
+   true);
+
igt_wait_for_vblank(data-drm_fd, data-pipe);
 
 
@@ -222,6 +275,15 @@ static bool execute_test(data_t *data)
igt_plane_set_fb(data-primary, data-fb[0]);
igt_display_commit(display);
 
+   /*
+* FIXME: When Front buffer tracking is fixed, remove
+* next two function calls.
+*/
+   drrs_fb_status_update(data, INTEL_FRONTBUFFER_PRIMARY(data-pipe),
+   false);
+   drrs_fb_status_update(data, INTEL_FRONTBUFFER_PRIMARY(data-pipe),
+   true);
+
igt_wait_for_vblank(data-drm_fd, data-pipe);
 
if (is_drrs_state(data, DRRS_HIGH_RR)) {
@@ -246,6 +308,15 @@ static bool execute_test(data_t *data)
igt_plane_set_fb(data-primary, data-fb[1]);
igt_display_commit(display);
 
+   /*
+* FIXME: When Front buffer tracking is fixed, remove
+* next two function calls.
+*/
+   drrs_fb_status_update(data, INTEL_FRONTBUFFER_PRIMARY(data-pipe),
+   false);
+   drrs_fb_status_update(data, INTEL_FRONTBUFFER_PRIMARY(data-pipe),
+   true);
+
igt_wait_for_vblank(data-drm_fd, data-pipe);
 
if (is_drrs_state(data, DRRS_HIGH_RR)) {
-- 
1.7.9.5

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


[Intel-gfx] [PATCH 1/2] drm/i915: Removing the drrs from front buffer tracker

2015-03-23 Thread Ramalingam C
Calls from front buffer tracker module to DRRS is removed.

DO NOT MERGE: This change is to test the DRRS with IGT, independent of
front buffer tracking. This change will be dropped as soon as front
buffer tracker fully functional.

Signed-off-by: Ramalingam C ramalinga...@intel.com
---
 drivers/gpu/drm/i915/intel_frontbuffer.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c 
b/drivers/gpu/drm/i915/intel_frontbuffer.c
index 0a1bac8..23c9fcb 100644
--- a/drivers/gpu/drm/i915/intel_frontbuffer.c
+++ b/drivers/gpu/drm/i915/intel_frontbuffer.c
@@ -157,7 +157,6 @@ void intel_fb_obj_invalidate(struct drm_i915_gem_object 
*obj,
intel_mark_fb_busy(dev, obj-frontbuffer_bits, ring);
 
intel_psr_invalidate(dev, obj-frontbuffer_bits);
-   intel_edp_drrs_invalidate(dev, obj-frontbuffer_bits);
intel_fbc_invalidate(dev_priv, obj-frontbuffer_bits, origin);
 }
 
@@ -184,7 +183,6 @@ void intel_frontbuffer_flush(struct drm_device *dev,
 
intel_mark_fb_busy(dev, frontbuffer_bits, NULL);
 
-   intel_edp_drrs_flush(dev, frontbuffer_bits);
intel_psr_flush(dev, frontbuffer_bits);
intel_fbc_flush(dev_priv, frontbuffer_bits);
 }
-- 
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 1/2] i-g-t: Adding plane scaling test case

2015-03-23 Thread Thomas Wood
On 21 March 2015 at 00:11, Chandra Konduru chandra.kond...@intel.com wrote:
 From: chandra konduru chandra.kond...@intel.com

 This patch is adding i-g-t plane scaling test case to test couple basic
 display plane scaling usages. Additional test scenarios can be added later.

Unfortunately both patches in this series don't apply cleanly to
current master of intel-gpu-tools. Please could you rebase and send
them again?


 v2:
 -Added iterative scaling to visually observe scaling (me)

 v3:
 -Added a flag to control primary plane scaling.

 Signed-off-by: chandra konduru chandra.kond...@intel.com
 ---
  lib/igt_fb.h  |4 +
  lib/igt_kms.c |  122 +--
  lib/igt_kms.h |5 +
  tests/.gitignore  |1 +
  tests/Android.mk  |1 +
  tests/Makefile.sources|1 +
  tests/kms_plane_scaling.c |  370 
 +
  7 files changed, 488 insertions(+), 16 deletions(-)
  create mode 100644 tests/kms_plane_scaling.c

 diff --git a/lib/igt_fb.h b/lib/igt_fb.h
 index d9fb6bb..c21d1d0 100644
 --- a/lib/igt_fb.h
 +++ b/lib/igt_fb.h
 @@ -54,6 +54,10 @@ struct igt_fb {
 unsigned tiling;
 unsigned size;
 cairo_surface_t *cairo_surface;
 +   uint32_t src_x;
 +   uint32_t src_y;
 +   uint32_t src_w;
 +   uint32_t src_h;
  };

  enum igt_text_align {
 diff --git a/lib/igt_kms.c b/lib/igt_kms.c
 index 72841ef..895830b 100644
 --- a/lib/igt_kms.c
 +++ b/lib/igt_kms.c
 @@ -1299,6 +1299,14 @@ static int igt_drm_plane_commit(igt_plane_t *plane,
 igt_display_t *display = output-display;
 uint32_t fb_id, crtc_id;
 int ret;
 +   uint32_t src_x;
 +   uint32_t src_y;
 +   uint32_t src_w;
 +   uint32_t src_h;
 +   int32_t crtc_x;
 +   int32_t crtc_y;
 +   uint32_t crtc_w;
 +   uint32_t crtc_h;

 igt_assert(plane-drm_plane);

 @@ -1329,32 +1337,43 @@ static int igt_drm_plane_commit(igt_plane_t *plane,
   IGT_FIXED(0,0) /* src_h */);

 CHECK_RETURN(ret, fail_on_error);
 -   } else if (plane-fb_changed || plane-position_changed) {
 +   } else if (plane-fb_changed || plane-position_changed ||
 +   plane-size_changed) {
 +   src_x = IGT_FIXED(plane-fb-src_x,0); /* src_x */
 +   src_y = IGT_FIXED(plane-fb-src_y,0); /* src_y */
 +   src_w = IGT_FIXED(plane-fb-src_w,0); /* src_w */
 +   src_h = IGT_FIXED(plane-fb-src_h,0); /* src_h */
 +   crtc_x = plane-crtc_x;
 +   crtc_y = plane-crtc_y;
 +   crtc_w = plane-crtc_w;
 +   crtc_h = plane-crtc_h;
 +
 LOG(display,
 -   %s: SetPlane %s.%d, fb %u, position (%d, %d)\n,
 +   %s: SetPlane %s.%d, fb %u, src = (%d, %d) 
 +   %ux%u dst = (%u, %u) %ux%u\n,
 igt_output_name(output),
 kmstest_pipe_name(output-config.pipe),
 plane-index,
 fb_id,
 -   plane-crtc_x, plane-crtc_y);
 +   src_x  16, src_y  16, src_w  16, src_h  16,
 +   crtc_x, crtc_y, crtc_w, crtc_h);

 ret = drmModeSetPlane(display-drm_fd,
   plane-drm_plane-plane_id,
   crtc_id,
   fb_id,
   0,/* flags */
 - plane-crtc_x, plane-crtc_y,
 - plane-crtc_w, plane-crtc_h,
 - IGT_FIXED(0,0), /* src_x */
 - IGT_FIXED(0,0), /* src_y */
 - IGT_FIXED(plane-fb-width,0), /* src_w 
 */
 - IGT_FIXED(plane-fb-height,0) /* src_h 
 */);
 + crtc_x, crtc_y,
 + crtc_w, crtc_h,
 + src_x, src_y,
 + src_w, src_h);

 CHECK_RETURN(ret, fail_on_error);
 }

 plane-fb_changed = false;
 plane-position_changed = false;
 +   plane-size_changed = false;

 if (plane-rotation_changed) {
 igt_plane_set_property(plane, plane-rotation_property,
 @@ -1449,7 +1468,7 @@ static int igt_primary_plane_commit_legacy(igt_plane_t 
 *primary,
 igt_assert(!primary-rotation_changed);

 if (!primary-fb_changed  !primary-position_changed 
 -   !primary-panning_changed)
 +   !primary-size_changed  !primary-panning_changed)
 return 0;

 crtc_id = output-config.crtc-crtc_id;
 @@ -1496,6 +1515,7 @@ static int igt_primary_plane_commit_legacy(igt_plane_t 
 *primary,
 primary-pipe-enabled = 

[Intel-gfx] [PATCH 2/2] drm/i915: eDP DRRS limited to only one panel at a time

2015-03-23 Thread Ramalingam C
In case of multiple eDP panels, only one can have
the DRRS enabled on it.

In future eDP DRRS will be extended for multiple panels.

Signed-off-by: Ramalingam C ramalinga...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0b26df9..ec40d19 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5311,6 +5311,11 @@ intel_dp_drrs_init(struct intel_connector 
*intel_connector,
return NULL;
}
 
+   if (dev_priv-drrs.type == SEAMLESS_DRRS_SUPPORT) {
+   DRM_DEBUG_KMS(DRRS already enabled on previous connector\n);
+   return NULL;
+   }
+
INIT_DELAYED_WORK(dev_priv-drrs.work, intel_edp_drrs_downclock_work);
 
mutex_init(dev_priv-drrs.mutex);
-- 
1.7.9.5

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


[Intel-gfx] [PATCH] tests/kms_drrs: Test Idleness DRRS

2015-03-23 Thread Ramalingam C
Idleness DRRS:
By default the DRRS state will be at DRRS_HIGH_RR. When a Display
content is Idle for more than 1Sec Idleness will be declared and
DRRS_LOW_RR will be invoked. And as soon as there is a display
content change there will be a DRRS state transition as
DRRS_LOW_RR-- DRRS_HIGH_RR.

To test this Idleness DRRS IGT will probe the DRRS state at below
instances and compare with the expected state.

InstanceExpected State
1. Immediately after rendering the still image  DRRS_HIGH_RR
2. After a delay of 1.2Sec  DRRS_LOW_RR
3. After changing the frame buffer  DRRS_HIGH_RR
4. After a delay of 1.2Sec  DRRS_LOW_RR
5. After changing the frame buffer  DRRS_HIGH_RR
6. After a delay of 1.2Sec  DRRS_LOW_RR

Signed-off-by: Ramalingam C ramalinga...@intel.com
Signed-off-by: Vandana Kannan vandana.kan...@intel.com
---
 tests/Makefile.sources |1 +
 tests/kms_drrs.c   |  376 
 2 files changed, 377 insertions(+)
 create mode 100644 tests/kms_drrs.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 74deec3..2305cd4 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -65,6 +65,7 @@ TESTS_progs_M = \
gem_write_read_ring_switch \
kms_addfb \
kms_cursor_crc \
+   kms_drrs \
kms_fbc_crc \
kms_flip \
kms_flip_event_leak \
diff --git a/tests/kms_drrs.c b/tests/kms_drrs.c
new file mode 100644
index 000..91bda5c
--- /dev/null
+++ b/tests/kms_drrs.c
@@ -0,0 +1,376 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include drmtest.h
+#include igt_debugfs.h
+#include igt_kms.h
+#include intel_chipset.h
+#include intel_batchbuffer.h
+#include ioctl_wrappers.h
+#include time.h
+
+IGT_TEST_DESCRIPTION(
+Performs write operations and then waits for DRRS to invoke the
+Low Refresh Rate and then disturbs the contents of the screen once
+again hence DRRS revert back to High Refresh Rate(Default).);
+
+#define DRRS_STATUS_BYTES_CNT  1000
+
+typedef struct {
+   int drm_fd;
+   uint32_t devid;
+   uint32_t handle[2];
+   igt_display_t display;
+   igt_output_t *output;
+   enum pipe pipe;
+   igt_plane_t *primary;
+   struct igt_fb fb[2];
+   uint32_t fb_id[2];
+} data_t;
+
+struct __attribute__((packed, aligned(16))) fb_status {
+   bool rendered;
+   unsigned fb_bits;
+};
+
+/*
+ * print_date_and_time : Func to print the date and time
+ */
+static void print_date_and_time(void)
+{
+   time_t curtime;
+   struct tm *loctime;
+
+   curtime = time(NULL);
+   loctime = localtime(curtime);
+   fputs (asctime (loctime), stdout);
+}
+
+/*
+ * read_drrs_status: Func to read the DRRS status from debugfs
+ */
+static bool read_drrs_status(data_t *data, char *str)
+{
+   FILE *status;
+   int cnt;
+
+   status = igt_debugfs_fopen(i915_drrs_status, r);
+   igt_assert(status);
+
+   cnt = fread(str, DRRS_STATUS_BYTES_CNT - 1, 1, status);
+   if (!cnt) {
+   if (!feof(status)) {
+   igt_info(Err %d at fread\n, ferror(status));
+   return false;
+   }
+   clearerr(status);
+   }
+
+   fclose(status);
+   return true;
+}
+
+/*
+ * is_drrs_enabled : Func to check for DRRS support
+ */
+static bool is_drrs_enabled(data_t *data)
+{
+   char str[DRRS_STATUS_BYTES_CNT] = {};
+
+   read_drrs_status(data, str);
+   return strstr(str, DRRS Supported: Yes) != NULL;
+}
+
+/*
+ * print_drrs_status   : Func to print the DRRS status from the debugfs
+ */
+static bool print_drrs_status(data_t 

  1   2   >