Re: [Intel-gfx] [PATCH] drm/i915: select MMU_NOTIFIER

2014-06-18 Thread Chris Wilson
On Wed, Jun 18, 2014 at 12:38:52AM +0200, Daniel Vetter wrote:
 Without this the interactions with the core mm don't work to well and
 heavy userptr tests OOM _really_ premature. With this my 2G memory
 atom is much happier when running gem_userptr_blt tests.

Since those tests include those that bypass mmu-notifier, how? Are you
sure you are not papering over a core bug?
-Chris

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


[Intel-gfx] [PATCH] Fix the comments for igt case: pm_rc6_residency

2014-06-18 Thread Wendy Wang
1. Replace abort() with igt_exit()
2. Combine two subtests(rc6_residency_check and rc6_residency_counter)
 into one subtest(residency_accuracy)
3. Replace printf with igt_info(f...)

Test result on multi platforms:
[root@x-bdw01 power]# ./pm_rc6_residency
IGT-Version: 1.7-gf2fcec6 (x86_64)
(Linux: 3.15.0-rc8_drm-intel-nightly_b438e8_20140615+ x86_64)
This machine doesn't support rc6pp
This machine doesn't support rc6p
This machine entry into rc6 state
The residency counter: 0.994333
Subtest residency-accuracy: SUCCESS

[root@x-byt06: power]# ./pm_rc6_residency
IGT-Version: 1.7-gf2fcec6 (x86_64)
(Linux: 3.15.0-rc8_drm-intel-next-queued_27b6c1_20140618+ x86_64)
This machine doesn't support rc6pp
This machine doesn't support rc6p
This machine entry into rc6 state
The residency counter: 1.144333
Test assertion failure function residency_accuracy, file pm_rc6_residency.c:141:
Last errno: 0, Success
Failed assertion: (flag_counter != 0)  (counter_result =1)
Sysfs RC6 residency counter is inaccurate
Subtest residency-accuracy: FAIL

[root@x-hswu32 home]# ./pm_rc6_residency
IGT-Version: 1.7-gf2fcec6 (x86_64)
(Linux: 3.15.0-rc8_drm-intel-nightly_e9ce9f_20140617+ x86_64)
This machine doesn't support rc6pp
This machine doesn't support rc6p
This machine entry into rc6 state
The residency counter: 1.004333
Test assertion failure function residency_accuracy, file pm_rc6_residency.c:141:
Last errno: 0, Success
Failed assertion: (flag_counter != 0)  (counter_result =1)
Sysfs RC6 residency counter is inaccurate
Subtest residency-accuracy: FAIL

[root@x-ivb16 power]# ./pm_rc6_residency
IGT-Version: 1.7-gf2fcec6 (x86_64)
(Linux: 3.15.0-rc8_drm-intel-nightly_fff6c5_20140618+ x86_64)
This machine doesn't support rc6pp
This machine entry into rc6p state
The residency counter: 0.99
Subtest residency-accuracy: SUCCESS

[root@x-ivb16 power]# ./pm_rc6_residency --list
residency-accuracy

[root@x-ivb16 power]# ./pm_rc6_residency --run-subtest residency-accuracy
IGT-Version: 1.7-gf2fcec6 (x86_64)
(Linux: 3.15.0-rc8_drm-intel-nightly_fff6c5_20140618+ x86_64)
This machine doesn't support rc6pp
This machine entry into rc6p state
The residency counter: 0.993667
Subtest residency-accuracy: SUCCESS

Signed-off-by: Wendy Wang wendy.w...@intel.com

diff --git a/tests/pm_rc6_residency.c b/tests/pm_rc6_residency.c
index d364369..0945364 100644
--- a/tests/pm_rc6_residency.c
+++ b/tests/pm_rc6_residency.c
@@ -47,7 +47,7 @@ static unsigned int readit(const char *path)
file = fopen(path, r);
if (file == NULL) {
fprintf(stderr, Couldn't open %s (%d)\n, path, errno);
-   abort();
+   igt_exit();
}
scanned = fscanf(file, %u, ret);
igt_assert(scanned == 1);
@@ -90,14 +90,24 @@ static void read_rc6_residency( int value[], const char 
*name_of_rc6_residency[]
free(path);
 }
 
-static void rc6_residency_counter(int value[],const char 
*name_of_rc6_residency[])
+static void residency_accuracy(int value[],const char *name_of_rc6_residency[])
 {
int flag;
unsigned int flag_counter,flag_support;
double counter_result = 0;
+   unsigned int diff;
flag_counter = 0;
flag_support = 0;
 
+   diff = (value[3] - value[0]) +
+   (value[4] - value[1]) +
+   (value[5] - value[2]);
+
+   igt_assert_f(diff = (SLEEP_DURATION + RC6_FUDGE),Diff was too high. 
That is unpossible\n);
+   igt_assert_f(diff = (SLEEP_DURATION - RC6_FUDGE),GPU was not in RC6 
long enough. Check that 
+   the GPU is as idle as 
possible(ie. no X, 
+   running and running no 
other tests)\n);
+
for(flag = NUMBER_OF_RC6_RESIDENCY-1; flag = 0; flag --)
{
unsigned int  tmp_counter, tmp_support;
@@ -113,7 +123,7 @@ static void rc6_residency_counter(int value[],const char 
*name_of_rc6_residency[
 
if( value [flag + 3] == 0){
tmp_support = 0;
-   printf(This machine doesn't support 
%s\n,name_of_rc6_residency[flag]);
+   igt_info(This machine doesn't support 
%s\n,name_of_rc6_residency[flag]);
}
else
tmp_support = 1;
@@ -124,26 +134,11 @@ static void rc6_residency_counter(int value[],const char 
*name_of_rc6_residency[
flag_support = flag_support + tmp_support;
flag_support = flag_support  1;
}
+   igt_info(This machine entry into %s state\n, 
name_of_rc6_residency[(flag_counter / 2) - 1]);
+   igt_info(The residency counter: %f \n, counter_result);
 
-   printf(The residency counter: %f \n, counter_result);
-
-   igt_skip_on_f(flag_support == 0 , This machine didn't entry any RC6 
state.\n);
-   igt_assert_f((flag_counter != 0)  (counter_result =1) , Sysfs RC6 
residency counter is 

Re: [Intel-gfx] [PATCH] drm/i915: select MMU_NOTIFIER

2014-06-18 Thread Daniel Vetter
On Wed, Jun 18, 2014 at 8:33 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Wed, Jun 18, 2014 at 12:38:52AM +0200, Daniel Vetter wrote:
 Without this the interactions with the core mm don't work to well and
 heavy userptr tests OOM _really_ premature. With this my 2G memory
 atom is much happier when running gem_userptr_blt tests.

 Since those tests include those that bypass mmu-notifier, how? Are you
 sure you are not papering over a core bug?

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


[Intel-gfx] [PATCH 00/11] Support for 180 degree HW rotation

2014-06-18 Thread sonika . jindal
From: Sonika Jindal sonika.jin...@intel.com

Enables 180 degree rotation for sprite and primary planes.
Updated the primary plane rotation support as per the new universal plane
design.

Most of these patches were already reviewed in intel-gfx in February 2014 thats
why there is version history in few of them.

Testcase: kms_rotation_crc
This igt can be extended for clipped rotation cases. Right it only tests 180
degree rotation for sprite and primary plane with crc check.

Sonika Jindal (2):
  tests/kms_rotation_crc: IGT for 180 degree HW rotation
  drm/i915: Add 180 degree primary plane rotation support

Ville Syrjälä (9):
  drm: Move DRM_ROTATE bits out of omapdrm into drm_crtc.h
  drm: Add support_bits parameter to drm_property_create_bitmask()
  drm: Add drm_mode_create_rotation_property()
  drm/omap: Switch omapdrm over to drm_mode_create_rotation_property()
  drm: Add drm_rect rotation functions
  drm: Add drm_rotation_simplify()
  drm/i915: Add 180 degree sprite rotation support
  drm/i915: Make intel_plane_restore() return an error
  drm/i915: Add rotation property for sprites

 drivers/gpu/drm/drm_crtc.c   |   66 +++-
 drivers/gpu/drm/drm_rect.c   |  140 ++
 drivers/gpu/drm/i915/i915_dma.c  |   17 +
 drivers/gpu/drm/i915/i915_drv.h  |1 +
 drivers/gpu/drm/i915/i915_reg.h  |4 +
 drivers/gpu/drm/i915/intel_display.c |   91 +-
 drivers/gpu/drm/i915/intel_drv.h |3 +-
 drivers/gpu/drm/i915/intel_pm.c  |8 ++
 drivers/gpu/drm/i915/intel_sprite.c  |   93 --
 drivers/gpu/drm/omapdrm/omap_drv.h   |7 --
 drivers/gpu/drm/omapdrm/omap_plane.c |   17 ++---
 include/drm/drm_crtc.h   |   15 +++-
 include/drm/drm_rect.h   |6 ++
 13 files changed, 433 insertions(+), 35 deletions(-)

-- 
1.7.10.4

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


[Intel-gfx] [PATCH 01/11] drm: Move DRM_ROTATE bits out of omapdrm into drm_crtc.h

2014-06-18 Thread sonika . jindal
From: Ville Syrjälä ville.syrjala at linux.intel.com

The rotation property stuff should be standardized among all drivers.
Move the bits to drm_crtc.h from omap_drv.h.

Signed-off-by: Ville Syrjälä ville.syrjala at linux.intel.com
---
 drivers/gpu/drm/omapdrm/omap_drv.h |7 ---
 include/drm/drm_crtc.h |8 
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h 
b/drivers/gpu/drm/omapdrm/omap_drv.h
index 284b80f..b08a450 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/gpu/drm/omapdrm/omap_drv.h
@@ -119,13 +119,6 @@ struct omap_drm_private {
struct omap_drm_irq error_handler;
 };
 
-/* this should probably be in drm-core to standardize amongst drivers */
-#define DRM_ROTATE_0   0
-#define DRM_ROTATE_90  1
-#define DRM_ROTATE_180 2
-#define DRM_ROTATE_270 3
-#define DRM_REFLECT_X  4
-#define DRM_REFLECT_Y  5
 
 #ifdef CONFIG_DEBUG_FS
 int omap_debugfs_init(struct drm_minor *minor);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 4ee7e26..bfc7235 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -75,6 +75,14 @@ static inline uint64_t I642U64(int64_t val)
return (uint64_t)*((uint64_t *)val);
 }
 
+/* rotation property bits */
+#define DRM_ROTATE_0   0
+#define DRM_ROTATE_90  1
+#define DRM_ROTATE_180 2
+#define DRM_ROTATE_270 3
+#define DRM_REFLECT_X  4
+#define DRM_REFLECT_Y  5
+
 enum drm_connector_force {
DRM_FORCE_UNSPECIFIED,
DRM_FORCE_OFF,
-- 
1.7.10.4

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


[Intel-gfx] [PATCH 04/11] drm/omap: Switch omapdrm over to drm_mode_create_rotation_property()

2014-06-18 Thread sonika . jindal
From: Ville Syrjälä ville.syrjala at linux.intel.com

Use the new drm_mode_create_rotation_property() in omapdrm.

Cc: David Airlie airlied at linux.ie
Cc: Rob Clark robdclark at gmail.com
Cc: Sagar Kamble sagar.a.kamble at intel.com
Cc: Ville Syrjälä ville.syrjala at linux.intel.com
Cc: Tomi Valkeinen tomi.valkeinen at ti.com
Cc: Greg Kroah-Hartman gregkh at linuxfoundation.org
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Ville Syrjälä ville.syrjala at linux.intel.com
---
 drivers/gpu/drm/omapdrm/omap_plane.c |   20 +++-
 1 file changed, 7 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
b/drivers/gpu/drm/omapdrm/omap_plane.c
index aff06e7..da9d15d 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -308,19 +308,13 @@ void omap_plane_install_properties(struct drm_plane 
*plane,
if (priv-has_dmm) {
prop = priv-rotation_prop;
if (!prop) {
-   const struct drm_prop_enum_list props[] = {
-   { DRM_ROTATE_0,   rotate-0 },
-   { DRM_ROTATE_90,  rotate-90 },
-   { DRM_ROTATE_180, rotate-180 },
-   { DRM_ROTATE_270, rotate-270 },
-   { DRM_REFLECT_X,  reflect-x },
-   { DRM_REFLECT_Y,  reflect-y },
-   };
-   prop = drm_property_create_bitmask(dev, 0, rotation,
-   props, ARRAY_SIZE(props),
-   BIT(DRM_ROTATE_0) | BIT(DRM_ROTATE_90) |
-   BIT(DRM_ROTATE_180) | 
BIT(DRM_ROTATE_270) |
-   BIT(DRM_REFLECT_X) | 
BIT(DRM_REFLECT_Y));
+   prop = drm_mode_create_rotation_property(dev,
+
BIT(DRM_ROTATE_0) |
+
BIT(DRM_ROTATE_90) |
+
BIT(DRM_ROTATE_180) |
+
BIT(DRM_ROTATE_270) |
+
BIT(DRM_REFLECT_X) |
+
BIT(DRM_REFLECT_Y));
if (prop == NULL)
return;
priv-rotation_prop = prop;
-- 
1.7.10.4

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


[Intel-gfx] [PATCH 02/11] drm: Add support_bits parameter to drm_property_create_bitmask()

2014-06-18 Thread sonika . jindal
From: Ville Syrjälä ville.syrjala at linux.intel.com

Make drm_property_create_bitmask() a bit more generic by allowing the
caller to specify which bits are in fact supported. This allows multiple
callers to use the same enum list, but still create different versions
of the same property with different list of supported bits.

v2: Populate values[] array as non-sparse
Make supported_bits 64bit
Fix up omapdrm call site (Rob)

Cc: Tomi Valkeinen tomi.valkeinen at ti.com
Cc: Rob Clark robdclark at gmail.com
Cc: Sagar Kamble sagar.a.kamble at intel.com
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Ville Syrjälä ville.syrjala at linux.intel.com
---
 drivers/gpu/drm/drm_crtc.c   |   17 +
 drivers/gpu/drm/omapdrm/omap_plane.c |5 -
 include/drm/drm_crtc.h   |3 ++-
 3 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 41c7212..2fbee61 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3395,19 +3395,28 @@ EXPORT_SYMBOL(drm_property_create_enum);
 struct drm_property *drm_property_create_bitmask(struct drm_device *dev,
 int flags, const char *name,
 const struct drm_prop_enum_list *props,
-int num_values)
+int num_props,
+uint64_t supported_bits)
 {
struct drm_property *property;
-   int i, ret;
+   int i, ret, index = 0;
+   int num_values = hweight64(supported_bits);
 
flags |= DRM_MODE_PROP_BITMASK;
 
property = drm_property_create(dev, flags, name, num_values);
if (!property)
return NULL;
+   for (i = 0; i  num_props; i++) {
+   if (!(supported_bits  (1ULL  props[i].type)))
+   continue;
 
-   for (i = 0; i  num_values; i++) {
-   ret = drm_property_add_enum(property, i,
+   if (WARN_ON(index = num_values)) {
+   drm_property_destroy(dev, property);
+   return NULL;
+   }
+
+   ret = drm_property_add_enum(property, index++,
  props[i].type,
  props[i].name);
if (ret) {
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 3cf31ee..aff06e7 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -317,7 +317,10 @@ void omap_plane_install_properties(struct drm_plane *plane,
{ DRM_REFLECT_Y,  reflect-y },
};
prop = drm_property_create_bitmask(dev, 0, rotation,
-   props, ARRAY_SIZE(props));
+   props, ARRAY_SIZE(props),
+   BIT(DRM_ROTATE_0) | BIT(DRM_ROTATE_90) |
+   BIT(DRM_ROTATE_180) | 
BIT(DRM_ROTATE_270) |
+   BIT(DRM_REFLECT_X) | 
BIT(DRM_REFLECT_Y));
if (prop == NULL)
return;
priv-rotation_prop = prop;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index bfc7235..cb4850a 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1006,7 +1006,8 @@ extern struct drm_property 
*drm_property_create_enum(struct drm_device *dev, int
 struct drm_property *drm_property_create_bitmask(struct drm_device *dev,
 int flags, const char *name,
 const struct drm_prop_enum_list *props,
-int num_values);
+int num_props,
+uint64_t supported_bits);
 struct drm_property *drm_property_create_range(struct drm_device *dev, int 
flags,
 const char *name,
 uint64_t min, uint64_t max);
-- 
1.7.10.4

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


[Intel-gfx] [PATCH 06/11] drm: Add drm_rotation_simplify()

2014-06-18 Thread sonika . jindal
From: Ville Syrjälä ville.syrjala at linux.intel.com

drm_rotation_simplify() can be used to eliminate unsupported rotation
flags. It will check if any unsupported flags are present, and if so
it will modify the rotation to an alternate form by adding 180 degrees
to rotation angle, and flipping the reflect x and y bits. The hope is
that this identity transform will eliminate the unsupported flags.

Of course that might not result in any more supported rotation, so
the caller is still responsible for checking the result afterwards.

Cc: David Airlie airlied at linux.ie
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Ville Syrjälä ville.syrjala at linux.intel.com
---
 drivers/gpu/drm/drm_crtc.c |   30 ++
 include/drm/drm_crtc.h |2 ++
 2 files changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f224d4d..89bab66 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4842,6 +4842,36 @@ int drm_format_vert_chroma_subsampling(uint32_t format)
 EXPORT_SYMBOL(drm_format_vert_chroma_subsampling);
 
 /**
+ * drm_rotation_simplify() - Try to simplify the rotation
+ * @rotation: Rotation to be simplified
+ * @supported_rotations: Supported rotations
+ *
+ * Attempt to simplify the rotation to a form that is supported.
+ * Eg. if the hardware supports everything except DRM_REFLECT_X
+ * one could call this function like this:
+ *
+ * drm_rotation_simplify(rotation, BIT(DRM_ROTATE_0) |
+ *   BIT(DRM_ROTATE_90) | BIT(DRM_ROTATE_180) |
+ *   BIT(DRM_ROTATE_270) | BIT(DRM_REFLECT_Y));
+ *
+ * to eliminate the DRM_ROTATE_X flag. Depending on what kind of
+ * transforms the hardware supports, this function may not
+ * be able to produce a supported transform, so the caller should
+ * check the result afterwards.
+ */
+unsigned int drm_rotation_simplify(unsigned int rotation,
+  unsigned int supported_rotations)
+{
+   if (rotation  ~supported_rotations) {
+   rotation ^= BIT(DRM_REFLECT_X) | BIT(DRM_REFLECT_Y);
+   rotation = (rotation  ~0xf) | BIT((ffs(rotation  0xf) + 1) % 
4);
+   }
+
+   return rotation;
+}
+EXPORT_SYMBOL(drm_rotation_simplify);
+
+/**
  * drm_mode_config_init - initialize DRM mode_configuration structure
  * @dev: DRM device
  *
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f7b383b..08ed55e 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1115,6 +1115,8 @@ extern int drm_format_vert_chroma_subsampling(uint32_t 
format);
 extern const char *drm_get_format_name(uint32_t format);
 extern struct drm_property *drm_mode_create_rotation_property(struct 
drm_device *dev,
  unsigned int 
supported_rotations);
+extern unsigned int drm_rotation_simplify(unsigned int rotation,
+ unsigned int supported_rotations);
 
 /* Helpers */
 
-- 
1.7.10.4

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


[Intel-gfx] [PATCH 10/11] drm/i915: Add 180 degree primary plane rotation support

2014-06-18 Thread sonika . jindal
From: Sonika Jindal sonika.jin...@intel.com

Primary planes support 180 degree rotation. Expose the feature
through rotation drm property.

v2: Calculating linear/tiled offsets based on pipe source width and
height. Added 180 degree rotation support in ironlake_update_plane.

v3: Checking if CRTC is active before issueing update_plane. Added
wait for vblank to make sure we dont overtake page flips. Disabling
FBC since it does not work with rotated planes.

v4: Updated rotation checks for pending flips, fbc disable. Creating
rotation property only for Gen4 onwards. Property resetting as part
of lastclose.

v5: Resetting property in i915_driver_lastclose properly for planes
and crtcs. Fixed linear offset calculation that was off by 1 w.r.t
width in i9xx_update_plane and ironlake_update_plane. Removed tab
based indentation and unnecessary braces in intel_crtc_set_property
and intel_update_fbc. FBC and flip related checks should be done only
for valid crtcs.

v6: Minor nits in FBC disable checks for comments in intel_crtc_set_property
and positioning the disable code in intel_update_fbc.

v7: In case rotation property on inactive crtc is updated, we return
successfully printing debug log as crtc is inactive and only property change
is preserved.

v8: update_plane is changed to update_primary_plane, crtc-fb is changed to
crtc-primary-fb  and return value of update_primary_plane is ignored.

v9: added rotation property to primary plane instead of crtc.

Testcase: igt/kms_rotation_crc

Cc: Daniel Vetter daniel.vetter at ffwll.ch
Cc: Jani Nikula jani.nikula at linux.intel.com
Cc: David Airlie airlied at linux.ie
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Cc: vijay.a.purushothaman at intel.com
Signed-off-by: Uma Shankar uma.shankar at intel.com
Signed-off-by: Sagar Kamble sagar.a.kamble at intel.com
---
 drivers/gpu/drm/i915/i915_dma.c  |   17 +++
 drivers/gpu/drm/i915/i915_reg.h  |1 +
 drivers/gpu/drm/i915/intel_display.c |   91 --
 drivers/gpu/drm/i915/intel_pm.c  |8 +++
 4 files changed, 113 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 5e583a1..4c91fbc 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1939,6 +1939,8 @@ int i915_driver_open(struct drm_device *dev, struct 
drm_file *file)
 void i915_driver_lastclose(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
+   struct intel_crtc *crtc;
+   struct intel_plane *plane;
 
/* On gen6+ we refuse to init without kms enabled, but then the drm core
 * goes right around and calls lastclose. Check for this and don't clean
@@ -1946,6 +1948,21 @@ void i915_driver_lastclose(struct drm_device *dev)
if (!dev_priv)
return;
 
+   if (dev_priv-rotation_property) {
+   list_for_each_entry(crtc, dev-mode_config.crtc_list, 
base.head) {
+   to_intel_plane(crtc-base.primary)-rotation = 
BIT(DRM_ROTATE_0);
+   drm_object_property_set_value(crtc-base.base,
+   dev_priv-rotation_property,
+   
to_intel_plane(crtc-base.primary)-rotation);
+   }
+   list_for_each_entry(plane, dev-mode_config.plane_list, 
base.head) {
+   plane-rotation = BIT(DRM_ROTATE_0);
+   drm_object_property_set_value(plane-base.base,
+   dev_priv-rotation_property,
+   plane-rotation);
+   }
+   }
+
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
intel_fbdev_restore_mode(dev);
vga_switcheroo_process_delayed_switch();
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c70c804..c600d3b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4087,6 +4087,7 @@ enum punit_power_well {
 #define   DISPPLANE_NO_LINE_DOUBLE 0
 #define   DISPPLANE_STEREO_POLARITY_FIRST  0
 #define   DISPPLANE_STEREO_POLARITY_SECOND (118)
+#define   DISPPLANE_ROTATE_180 (115)
 #define   DISPPLANE_TRICKLE_FEED_DISABLE   (114) /* Ironlake */
 #define   DISPPLANE_TILED  (110)
 #define _DSPAADDR  0x70184
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5e8e711..1dc8b68 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2414,7 +2414,9 @@ static void i9xx_update_primary_plane(struct drm_crtc 
*crtc,
unsigned long linear_offset;
u32 dspcntr;
u32 reg;
+   int pixel_size;
 
+   pixel_size = drm_format_plane_cpp(fb-pixel_format, 0);
intel_fb = 

[Intel-gfx] [PATCH 09/11] drm/i915: Add rotation property for sprites

2014-06-18 Thread sonika . jindal
From: Ville Syrjälä ville.syrjala at linux.intel.com

Sprite planes support 180 degree rotation. The lower layers are now in
place, so hook in the standard rotation property to expose the feature
to the users.

Cc: Daniel Vetter daniel.vetter at ffwll.ch
Cc: Jani Nikula jani.nikula at linux.intel.com
Cc: David Airlie airlied at linux.ie
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Ville Syrjälä ville.syrjala at linux.intel.com
---
 drivers/gpu/drm/i915/i915_drv.h |1 +
 drivers/gpu/drm/i915/intel_sprite.c |   42 ++-
 2 files changed, 42 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0640071..b56a1a5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1514,6 +1514,7 @@ struct drm_i915_private {
 
struct drm_property *broadcast_rgb_property;
struct drm_property *force_audio_property;
+   struct drm_property *rotation_property;
 
uint32_t hw_context_size;
struct list_head context_list;
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index cbad738..b9af256 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1202,6 +1202,30 @@ out_unlock:
return ret;
 }
 
+static int intel_plane_set_property(struct drm_plane *plane,
+   struct drm_property *prop,
+   uint64_t val)
+{
+   struct drm_i915_private *dev_priv = plane-dev-dev_private;
+   struct intel_plane *intel_plane = to_intel_plane(plane);
+   uint64_t old_val;
+   int ret = -ENOENT;
+
+   if (prop == dev_priv-rotation_property) {
+   /* exactly one rotation angle please */
+   if (hweight32(val  0xf) != 1)
+   return -EINVAL;
+
+   old_val = intel_plane-rotation;
+   intel_plane-rotation = val;
+   ret = intel_plane_restore(plane);
+   if (ret)
+   intel_plane-rotation = old_val;
+   }
+
+   return ret;
+}
+
 int intel_plane_restore(struct drm_plane *plane)
 {
struct intel_plane *intel_plane = to_intel_plane(plane);
@@ -1228,6 +1252,7 @@ static const struct drm_plane_funcs intel_plane_funcs = {
.update_plane = intel_update_plane,
.disable_plane = intel_disable_plane,
.destroy = intel_destroy_plane,
+   .set_property = intel_plane_set_property,
 };
 
 static uint32_t ilk_plane_formats[] = {
@@ -1264,6 +1289,7 @@ static uint32_t vlv_plane_formats[] = {
 int
 intel_plane_init(struct drm_device *dev, enum pipe pipe, int plane)
 {
+   struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_plane *intel_plane;
unsigned long possible_crtcs;
const uint32_t *plane_formats;
@@ -1338,8 +1364,22 @@ intel_plane_init(struct drm_device *dev, enum pipe pipe, 
int plane)
 intel_plane_funcs,
 plane_formats, num_plane_formats,
 false);
-   if (ret)
+   if (ret) {
kfree(intel_plane);
+   goto out;
+   }
+
+   if (!dev_priv-rotation_property)
+   dev_priv-rotation_property =
+   drm_mode_create_rotation_property(dev,
+ BIT(DRM_ROTATE_0) |
+ BIT(DRM_ROTATE_180));
+
+   if (dev_priv-rotation_property)
+   drm_object_attach_property(intel_plane-base.base,
+  dev_priv-rotation_property,
+  intel_plane-rotation);
 
+ out:
return ret;
 }
-- 
1.7.10.4

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


[Intel-gfx] [PATCH 03/11] drm: Add drm_mode_create_rotation_property()

2014-06-18 Thread sonika . jindal
From: Ville Syrjälä ville.syrjala at linux.intel.com

Add a function to create a standards compliant rotation property.

Signed-off-by: Ville Syrjälä ville.syrjala at linux.intel.com
---
 drivers/gpu/drm/drm_crtc.c |   18 ++
 include/drm/drm_crtc.h |2 ++
 2 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 2fbee61..f224d4d 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4959,3 +4959,21 @@ void drm_mode_config_cleanup(struct drm_device *dev)
drm_modeset_lock_fini(dev-mode_config.connection_mutex);
 }
 EXPORT_SYMBOL(drm_mode_config_cleanup);
+
+struct drm_property *drm_mode_create_rotation_property(struct drm_device *dev,
+  unsigned int 
supported_rotations)
+{
+   static const struct drm_prop_enum_list props[] = {
+   { DRM_ROTATE_0,   rotate-0 },
+   { DRM_ROTATE_90,  rotate-90 },
+   { DRM_ROTATE_180, rotate-180 },
+   { DRM_ROTATE_270, rotate-270 },
+   { DRM_REFLECT_X,  reflect-x },
+   { DRM_REFLECT_Y,  reflect-y },
+   };
+
+   return drm_property_create_bitmask(dev, 0, rotation,
+  props, ARRAY_SIZE(props),
+  supported_rotations);
+}
+EXPORT_SYMBOL(drm_mode_create_rotation_property);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index cb4850a..f7b383b 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1113,6 +1113,8 @@ extern int drm_format_plane_cpp(uint32_t format, int 
plane);
 extern int drm_format_horz_chroma_subsampling(uint32_t format);
 extern int drm_format_vert_chroma_subsampling(uint32_t format);
 extern const char *drm_get_format_name(uint32_t format);
+extern struct drm_property *drm_mode_create_rotation_property(struct 
drm_device *dev,
+ unsigned int 
supported_rotations);
 
 /* Helpers */
 
-- 
1.7.10.4

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


[Intel-gfx] [PATCH 07/11] drm/i915: Add 180 degree sprite rotation support

2014-06-18 Thread sonika . jindal
From: Ville Syrjälä ville.syrjala at linux.intel.com

The sprite planes (in fact all display planes starting from gen4)
support 180 degree rotation. Add the relevant low level bits to the
sprite code to make use of that feature.

The upper layers are not yet plugged in.

v2: HSW handles the rotated buffer offset automagically

v3: BDW also handles the rotated buffer offset automagically

Testcase: igt/kms_rotation_crc

Cc: Daniel Vetter daniel.vetter at ffwll.ch
Cc: Jani Nikula jani.nikula at linux.intel.com
Cc: David Airlie airlied at linux.ie
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Ville Syrjälä ville.syrjala at linux.intel.com
Signed-off-by: Sagar Kamble sagar.a.kamble at intel.com
---
 drivers/gpu/drm/i915/i915_reg.h |3 +++
 drivers/gpu/drm/i915/intel_drv.h|1 +
 drivers/gpu/drm/i915/intel_sprite.c |   37 +++
 3 files changed, 41 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3488567..c70c804 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4171,6 +4171,7 @@ enum punit_power_well {
 #define   DVS_YUV_ORDER_UYVY   (116)
 #define   DVS_YUV_ORDER_YVYU   (216)
 #define   DVS_YUV_ORDER_VYUY   (316)
+#define   DVS_ROTATE_180   (115)
 #define   DVS_DEST_KEY (12)
 #define   DVS_TRICKLE_FEED_DISABLE (114)
 #define   DVS_TILED(110)
@@ -4241,6 +4242,7 @@ enum punit_power_well {
 #define   SPRITE_YUV_ORDER_UYVY(116)
 #define   SPRITE_YUV_ORDER_YVYU(216)
 #define   SPRITE_YUV_ORDER_VYUY(316)
+#define   SPRITE_ROTATE_180(115)
 #define   SPRITE_TRICKLE_FEED_DISABLE  (114)
 #define   SPRITE_INT_GAMMA_ENABLE  (113)
 #define   SPRITE_TILED (110)
@@ -4314,6 +4316,7 @@ enum punit_power_well {
 #define   SP_YUV_ORDER_UYVY(116)
 #define   SP_YUV_ORDER_YVYU(216)
 #define   SP_YUV_ORDER_VYUY(316)
+#define   SP_ROTATE_180(115)
 #define   SP_TILED (110)
 #define _SPALINOFF (VLV_DISPLAY_BASE + 0x72184)
 #define _SPASTRIDE (VLV_DISPLAY_BASE + 0x72188)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ab5962b..67b1c59 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -437,6 +437,7 @@ struct intel_plane {
unsigned int crtc_w, crtc_h;
uint32_t src_x, src_y;
uint32_t src_w, src_h;
+   unsigned int rotation;
 
/* Since we need to change the watermarks before/after
 * enabling/disabling the planes, we need to store the parameters here
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 404335d..54d4224 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -163,6 +163,7 @@ vlv_update_plane(struct drm_plane *dplane, struct drm_crtc 
*crtc,
sprctl = ~SP_PIXFORMAT_MASK;
sprctl = ~SP_YUV_BYTE_ORDER_MASK;
sprctl = ~SP_TILED;
+   sprctl = ~SP_ROTATE_180;
 
switch (fb-pixel_format) {
case DRM_FORMAT_YUYV:
@@ -234,6 +235,14 @@ vlv_update_plane(struct drm_plane *dplane, struct drm_crtc 
*crtc,
fb-pitches[0]);
linear_offset -= sprsurf_offset;
 
+   if (intel_plane-rotation == BIT(DRM_ROTATE_180)) {
+   sprctl |= SP_ROTATE_180;
+
+   x += src_w;
+   y += src_h;
+   linear_offset += src_h * fb-pitches[0] + src_w * pixel_size;
+   }
+
atomic_update = intel_pipe_update_start(intel_crtc, start_vbl_count);
 
intel_update_primary_plane(intel_crtc);
@@ -363,6 +372,7 @@ ivb_update_plane(struct drm_plane *plane, struct drm_crtc 
*crtc,
sprctl = ~SPRITE_RGB_ORDER_RGBX;
sprctl = ~SPRITE_YUV_BYTE_ORDER_MASK;
sprctl = ~SPRITE_TILED;
+   sprctl = ~SPRITE_ROTATE_180;
 
switch (fb-pixel_format) {
case DRM_FORMAT_XBGR:
@@ -424,6 +434,17 @@ ivb_update_plane(struct drm_plane *plane, struct drm_crtc 
*crtc,
   pixel_size, fb-pitches[0]);
linear_offset -= sprsurf_offset;
 
+   if (intel_plane-rotation == BIT(DRM_ROTATE_180)) {
+   sprctl |= SPRITE_ROTATE_180;
+
+   /* HSW and BDW does this automagically in hardware */
+   if (!IS_HASWELL(dev)  !IS_BROADWELL(dev)) {
+   x += src_w;
+   y += src_h;
+   linear_offset += src_h * fb-pitches[0] + src_w * 
pixel_size;
+   }
+   }
+
atomic_update = intel_pipe_update_start(intel_crtc, start_vbl_count);
 
intel_update_primary_plane(intel_crtc);
@@ -569,6 +590,7 @@ ilk_update_plane(struct drm_plane *plane, struct drm_crtc 
*crtc,

[Intel-gfx] [PATCH 05/11] drm: Add drm_rect rotation functions

2014-06-18 Thread sonika . jindal
From: Ville Syrjälä ville.syrjala at linux.intel.com

Add some helper functions to move drm_rects between different rotated
coordinate spaces. One function does the forward transform and
another does the inverse.

Cc: David Airlie airlied at linux.ie
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Ville Syrjälä ville.syrjala at linux.intel.com
---
 drivers/gpu/drm/drm_rect.c |  140 
 include/drm/drm_rect.h |6 ++
 2 files changed, 146 insertions(+)

diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
index 7047ca0..631f5af 100644
--- a/drivers/gpu/drm/drm_rect.c
+++ b/drivers/gpu/drm/drm_rect.c
@@ -293,3 +293,143 @@ void drm_rect_debug_print(const struct drm_rect *r, bool 
fixed_point)
DRM_DEBUG_KMS(%dx%d%+d%+d\n, w, h, r-x1, r-y1);
 }
 EXPORT_SYMBOL(drm_rect_debug_print);
+
+/**
+ * drm_rect_rotate - Rotate the rectangle
+ * @r: rectangle to be rotated
+ * @width: Width of the coordinate space
+ * @height: Height of the coordinate space
+ * @rotation: Transformation to be applied
+ *
+ * Apply @rotation to the coordinates of rectangle @r.
+ *
+ * @width and @height combined with @rotation define
+ * the location of the new origin.
+ *
+ * @width correcsponds to the horizontal and @height
+ * to the vertical axis of the untransformed coordinate
+ * space.
+ */
+void drm_rect_rotate(struct drm_rect *r,
+int width, int height,
+unsigned int rotation)
+{
+   struct drm_rect tmp;
+
+   if (rotation  (BIT(DRM_REFLECT_X) | BIT(DRM_REFLECT_Y))) {
+   tmp = *r;
+
+   if (rotation  BIT(DRM_REFLECT_X)) {
+   r-x1 = width - tmp.x2;
+   r-x2 = width - tmp.x1;
+   }
+
+   if (rotation  BIT(DRM_REFLECT_Y)) {
+   r-y1 = height - tmp.y2;
+   r-y2 = height - tmp.y1;
+   }
+   }
+
+   switch (rotation  0xf) {
+   case BIT(DRM_ROTATE_0):
+   break;
+   case BIT(DRM_ROTATE_90):
+   tmp = *r;
+   r-x1 = tmp.y1;
+   r-x2 = tmp.y2;
+   r-y1 = width - tmp.x2;
+   r-y2 = width - tmp.x1;
+   break;
+   case BIT(DRM_ROTATE_180):
+   tmp = *r;
+   r-x1 = width - tmp.x2;
+   r-x2 = width - tmp.x1;
+   r-y1 = height - tmp.y2;
+   r-y2 = height - tmp.y1;
+   break;
+   case BIT(DRM_ROTATE_270):
+   tmp = *r;
+   r-x1 = height - tmp.y2;
+   r-x2 = height - tmp.y1;
+   r-y1 = tmp.x1;
+   r-y2 = tmp.x2;
+   break;
+   default:
+   break;
+   }
+}
+EXPORT_SYMBOL(drm_rect_rotate);
+
+/**
+ * drm_rect_rotate_inv - Inverse rotate the rectangle
+ * @r: rectangle to be rotated
+ * @width: Width of the coordinate space
+ * @height: Height of the coordinate space
+ * @rotation: Transformation whose inverse is to be applied
+ *
+ * Apply the inverse of @rotation to the coordinates
+ * of rectangle @r.
+ *
+ * @width and @height combined with @rotation define
+ * the location of the new origin.
+ *
+ * @width correcsponds to the horizontal and @height
+ * to the vertical axis of the original untransformed
+ * coordinate space, so that you never have to flip
+ * them when doing a rotatation and its inverse.
+ * That is, if you do:
+ *
+ * drm_rotate(r, width, height, rotation);
+ * drm_rotate_inv(r, width, height, rotation);
+ *
+ * you will always get back the original rectangle.
+ */
+void drm_rect_rotate_inv(struct drm_rect *r,
+int width, int height,
+unsigned int rotation)
+{
+   struct drm_rect tmp;
+
+   switch (rotation  0xf) {
+   case BIT(DRM_ROTATE_0):
+   break;
+   case BIT(DRM_ROTATE_90):
+   tmp = *r;
+   r-x1 = width - tmp.y2;
+   r-x2 = width - tmp.y1;
+   r-y1 = tmp.x1;
+   r-y2 = tmp.x2;
+   break;
+   case BIT(DRM_ROTATE_180):
+   tmp = *r;
+   r-x1 = width - tmp.x2;
+   r-x2 = width - tmp.x1;
+   r-y1 = height - tmp.y2;
+   r-y2 = height - tmp.y1;
+   break;
+   case BIT(DRM_ROTATE_270):
+   tmp = *r;
+   r-x1 = tmp.y1;
+   r-x2 = tmp.y2;
+   r-y1 = height - tmp.x2;
+   r-y2 = height - tmp.x1;
+   break;
+   default:
+   break;
+   }
+
+   if (rotation  (BIT(DRM_REFLECT_X) | BIT(DRM_REFLECT_Y))) {
+   tmp = *r;
+
+   if (rotation  BIT(DRM_REFLECT_X)) {
+   r-x1 = width - tmp.x2;
+   r-x2 = width - tmp.x1;
+   }
+
+   if (rotation  BIT(DRM_REFLECT_Y)) 

[Intel-gfx] [PATCH 08/11] drm/i915: Make intel_plane_restore() return an error

2014-06-18 Thread sonika . jindal
From: Ville Syrjälä ville.syrjala at linux.intel.com

Propagate the error from intel_update_plane() up through
intel_plane_restore() to the caller. This will be used for
rollback purposes when setting properties fails.

Cc: Daniel Vetter daniel.vetter at ffwll.ch
Cc: Jani Nikula jani.nikula at linux.intel.com
Cc: David Airlie airlied at linux.ie
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Ville Syrjälä ville.syrjala at linux.intel.com
---
 drivers/gpu/drm/i915/intel_drv.h|2 +-
 drivers/gpu/drm/i915/intel_sprite.c |   14 +++---
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 67b1c59..da5a3ca 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -993,7 +993,7 @@ bool intel_sdvo_init(struct drm_device *dev, uint32_t 
sdvo_reg, bool is_sdvob);
 int intel_plane_init(struct drm_device *dev, enum pipe pipe, int plane);
 void intel_flush_primary_plane(struct drm_i915_private *dev_priv,
   enum plane plane);
-void intel_plane_restore(struct drm_plane *plane);
+int intel_plane_restore(struct drm_plane *plane);
 void intel_plane_disable(struct drm_plane *plane);
 int intel_sprite_set_colorkey(struct drm_device *dev, void *data,
  struct drm_file *file_priv);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 54d4224..cbad738 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1202,18 +1202,18 @@ out_unlock:
return ret;
 }
 
-void intel_plane_restore(struct drm_plane *plane)
+int intel_plane_restore(struct drm_plane *plane)
 {
struct intel_plane *intel_plane = to_intel_plane(plane);
 
if (!plane-crtc || !plane-fb)
-   return;
+   return 0;
 
-   intel_update_plane(plane, plane-crtc, plane-fb,
-  intel_plane-crtc_x, intel_plane-crtc_y,
-  intel_plane-crtc_w, intel_plane-crtc_h,
-  intel_plane-src_x, intel_plane-src_y,
-  intel_plane-src_w, intel_plane-src_h);
+   return intel_update_plane(plane, plane-crtc, plane-fb,
+ intel_plane-crtc_x, intel_plane-crtc_y,
+ intel_plane-crtc_w, intel_plane-crtc_h,
+ intel_plane-src_x, intel_plane-src_y,
+ intel_plane-src_w, intel_plane-src_h);
 }
 
 void intel_plane_disable(struct drm_plane *plane)
-- 
1.7.10.4

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


[Intel-gfx] [PATCH 11/11] tests/kms_rotation_crc: IGT for 180 degree HW rotation

2014-06-18 Thread sonika . jindal
From: Sonika Jindal sonika.jin...@intel.com

Testcase for 180 degree HW rotation

Cc: sagar.a.kam...@intel.com

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
 tests/Makefile.sources   |1 +
 tests/kms_rotation_crc.c |  427 ++
 2 files changed, 428 insertions(+)
 create mode 100644 tests/kms_rotation_crc.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index e4c23b3..b59c146 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -69,6 +69,7 @@ TESTS_progs_M = \
kms_plane \
kms_render \
kms_setmode \
+   kms_rotation_crc \
pm_lpsp \
pm_rpm \
pm_rps \
diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
new file mode 100644
index 000..74a52cd
--- /dev/null
+++ b/tests/kms_rotation_crc.c
@@ -0,0 +1,427 @@
+/*
+ * Copyright © 2013 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include errno.h
+#include limits.h
+#include stdbool.h
+#include stdio.h
+#include string.h
+#include sys/ioctl.h
+#include stdint.h
+#include stddef.h
+#include fcntl.h
+
+#include drmtest.h
+#include igt_debugfs.h
+#include igt_kms.h
+#include igt_core.h
+
+#define DRM_ROTATE_0   0
+#define DRM_ROTATE_90  1
+#define DRM_ROTATE_180 2
+#define DRM_ROTATE_270 3
+#define DRM_REFLECT_X  4
+#define DRM_REFLECT_Y  5
+#define DRM_ROTATE_NUM 6
+
+#define BIT(x) (1  x)
+
+// This will be part of libdrm later. Adding here temporarily
+#define DRM_PLANE_TYPE_OVERLAY 0
+#define DRM_PLANE_TYPE_PRIMARY 1
+#define DRM_PLANE_TYPE_CURSOR  2
+#define DRM_CLIENT_CAP_EXPOSE_PRIMARY_PLANES 2
+
+typedef struct {
+   int gfx_fd;
+   igt_display_t display;
+   igt_output_t *output;
+   int type;
+   int pipe;
+   struct igt_fb fb;
+   igt_crc_t ref_crc[2];
+   igt_pipe_crc_t *pipe_crc;
+   int rotate;
+} data_t;
+
+bool check_plane_type(int drm_fd, uint32_t plane_id, uint32_t type);
+int set_plane_property(data_t *data, int plane_id, const char *prop_name, int
+   val, igt_crc_t *crc_output);
+void test_sprite_rotation(data_t *data);
+void test_primary_rotation(data_t *data);
+bool prepare_crtc(data_t *data);
+
+bool prepare_crtc(data_t *data)
+{
+   drmModeModeInfo *mode;
+   igt_display_t *display = data-display;
+   igt_output_t *output = data-output;
+   cairo_t *cr;
+   igt_plane_t *primary, *sprite;
+   int fb_id;
+   int w, h;
+
+   igt_output_set_pipe(output, data-pipe);
+   igt_display_commit(display);
+
+   /* create the pipe_crc object for this pipe */
+   if (data-pipe_crc)
+   igt_pipe_crc_free(data-pipe_crc);
+
+   data-pipe_crc = igt_pipe_crc_new(data-pipe,
+   INTEL_PIPE_CRC_SOURCE_AUTO);
+   if (!data-pipe_crc) {
+   igt_info(auto crc not supported on this connector with pipe 
%i\n,
+   data-pipe);
+   return false;
+   }
+
+
+   if (!data-output-valid) {
+   igt_output_set_pipe(output, PIPE_ANY);
+   igt_display_commit(display);
+   return false;
+   }
+
+   switch (data-type) {
+
+   case DRM_PLANE_TYPE_OVERLAY: /* Sprite */
+   igt_info(Sprite plane\n);
+   mode = igt_output_get_mode(output);
+   w = mode-hdisplay;
+   h = mode-vdisplay;
+
+   fb_id = igt_create_fb(data-gfx_fd,
+   mode-hdisplay, mode-vdisplay,
+   DRM_FORMAT_XRGB,
+   false, /* tiled */
+   data-fb);
+   igt_assert(fb_id);
+   cr = igt_get_cairo_ctx(data-gfx_fd, data-fb);
+
+   /* Paint 

Re: [Intel-gfx] [PATCH] drm/i915/vlv: DP_SINK_COUNT is not reliable for valleyview platform.

2014-06-18 Thread Jani Nikula
On Wed, 18 Jun 2014, Wang, Quanxian quanxian.w...@intel.com wrote:
 -Original Message-
 From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
 Sent: Tuesday, June 17, 2014 11:12 PM
 To: Wang, Quanxian
 Cc: intel-gfx@lists.freedesktop.org; Daniel Vetter
 Subject: RE: [Intel-gfx] [PATCH] drm/i915/vlv: DP_SINK_COUNT is not reliable
 for valleyview platform.
 
 On Tue, 17 Jun 2014, Wang, Quanxian quanxian.w...@intel.com wrote:
  -Original Message-
  From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
  Sent: Monday, June 16, 2014 4:18 PM
  To: Wang, Quanxian; Daniel Vetter
  Cc: intel-gfx@lists.freedesktop.org
  Subject: RE: [Intel-gfx] [PATCH] drm/i915/vlv: DP_SINK_COUNT is not
  reliable for valleyview platform.
 
  On Mon, 16 Jun 2014, Wang, Quanxian quanxian.w...@intel.com
 wrote:
   -Original Message-
   From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
   Sent: Friday, June 13, 2014 5:12 PM
   To: Daniel Vetter; Wang, Quanxian
   Cc: intel-gfx@lists.freedesktop.org
   Subject: Re: [Intel-gfx] [PATCH] drm/i915/vlv: DP_SINK_COUNT is
   not reliable for valleyview platform.
  
   On Fri, 13 Jun 2014, Daniel Vetter dan...@ffwll.ch wrote:
On Fri, Jun 13, 2014 at 02:52:04PM +0800, Quanxian Wang wrote:
DP connector will be disconnected after chvt to another console
for
10 minutes or more on valleyview platform VTC1010.
   
This needs _much_ more detail, really.
   
Also it smells like we work around a sink issue, which means the
correct quirk is to use some sink id (like OUI), _not_ the platform.
Since this way you break all DP1.1+ stuff on vlv and if someone
puts this panel onto a different platform it still doesn't work.
  
   Furthermore you should end up in this code path *only* if you have
   a DP branch device. This shouldn't happen for eDP or native DP
   displays. Please confirm what kind of setup you're experiencing
   issues
  with.
  
   Frankly I wouldn't be surpised if we do have issues with branch
   devices, but this is not the fix.
   [Wang, Quanxian] Any idea how to do it? Currently in VTC1010
   device, we use native DP to connect HDMI monitor.(DP2HDMI) This
   case will
  happen.
 
  So it's an active adapter?
  [Wang, Quanxian] yes.
 
  Please send full dmesg from early booth with drm.debug=0xe module
  parameter set, exhibiting the problem.
  [Wang, Quanxian] I will send the dmesg log soon. If open drm.debug=0xe,
 irq log will overwrite all the dmesg output. I will have some change to get 
 the
 complete log for you. Just wait for a while.
 
 
 What's the irq log you talk about? HPD? That might explain the issues.
 [Wang, Quanxian] right, Too many valleyview_irq_handler log output.
 
  After checking with hardware spec, I have some comment for registers
  of Display Port In i915_reg.h, I found we use PCB_DP_x(address
  0xe4100+??, control, data...) to do the communication and check what the
 SINK_COUNT. (I found it was defined in Ivybridge spec 2012) The process
 focus on South Display Engine to do the communication.
  But in valleyview spec(2014), I don't find 0xe4110, and only
  0x64100+xxx for north display engine are available. (DPx_AUX_CH_CTL
  series defined in i915_reg.h)
 
  Question: Is the something changed for that after valleyview or
 haswell(2013-2014)?
 
 If you think we're using PCH registers on VLV/BYT, please point me at the
 lines of code.
 [Wang, Quanxian] i915/intel_dp.c:3709, with debug, I found it use 
 PCH_DPB_AUX_CH_CTL for VLV. However from the boot information, it seems work. 
 But in VLV bspec, I don't find it. So I am doubt if some hardware process is 
 changed. Sorry I just point that, but I am not clear of display port process 
 for reading status SINK_COUNT.

See the display port spec for details.

Obviously code references require a commit reference as well; the code
changes rapidly. The code I'm looking at has if (HAS_DDI(dev)) right
before the snippet below, i.e. not executed on VLV.

BR,
Jani.


 3709 case PORT_B:
 3710 intel_dp-aux_ch_ctl_reg = PCH_DPB_AUX_CH_CTL;
 3711 break;
 3712 case PORT_C:
 3713 intel_dp-aux_ch_ctl_reg = PCH_DPC_AUX_CH_CTL;
 3714 break;
 3715 case PORT_D:
 3716 intel_dp-aux_ch_ctl_reg = PCH_DPD_AUX_CH_CTL;

 i915/intel_dp.c:3830 (function intel_dp_aux_ch)
 455 for (i = 0; i  send_bytes; i += 4)
  456 I915_WRITE(ch_data + i,
  457pack_aux(send + i, send_bytes 
 - i));

 
 BR,
 Jani.
 
 
 
  Thanks
 
  BR,
  Jani.
 
 
 
 
 
 
 
 
  
  
   BR,
   Jani.
  
  
   
Or I completely don't understand this at all.
   
Also, such a patch needs a full spec quote or a w/a citation or
something solid if it's a more generic issue.
-Daniel
   
Signed-off-by: Quanxian Wang quanxian.w...@intel.com
  

Re: [Intel-gfx] [PATCH v5 2/2] drm/i915: State readout and cross-checking for dp_m2_n2

2014-06-18 Thread Daniel Vetter
On Wed, Jun 18, 2014 at 10:11:20AM +0530, Vandana Kannan wrote:
 On Jun-17-2014 10:12 PM, Daniel Vetter wrote:
  On Tue, Jun 17, 2014 at 05:52:24PM +0300, Jani Nikula wrote:
  On Mon, 16 Jun 2014, Vandana Kannan vandana.kan...@intel.com wrote:
  On Jun-13-2014 7:42 PM, Jani Nikula wrote:
  On Thu, 22 May 2014, Vandana Kannan vandana.kan...@intel.com wrote:
  Adding relevant read out comparison code, in check_crtc_state, for the 
  new
  member of crtc_config, dp_m2_n2, which was introduced to store link_m_n
  values for a DP downclock mode (if available). Suggested by Daniel.
 
  v2: Changed patch title.
  Daniel's review comments incorporated.
  Added relevant state readout code for M2_N2. dp_m2_n2 comparison to be 
  done
  only when high RR is not in use (This is because alternate m_n register
  programming will be done only when low RR is being used).
 
  v3: Modified call to get_m2_n2 which had dp_m_n as param by mistake.
  Compare dp_m_n and dp_m2_n2 for gen 7 and below. compare the structures
  based on DRRS state for gen 8 and above.
  Save and restore M2 N2 registers for gen 7 and below
 
  v4: For Gen=8, check M_N registers against dp_m_n and dp_m2_n2 as 
  there is
  only one set of M_N registers
 
  v5: Removed the chunk which saves and restores M2_N2 registers. Modified
  get_m_n() to get M2_N2 registers as well. Modified the macro which 
  compares
  hw.dp_m_n against sw.dp_m2_n2/sw.dp_m_n for gen  8.
 
  Signed-off-by: Vandana Kannan vandana.kan...@intel.com
  Cc: Daniel Vetter daniel.vet...@ffwll.ch
  ---
   drivers/gpu/drm/i915/intel_display.c | 68 
  +++-
   1 file changed, 60 insertions(+), 8 deletions(-)
 
  diff --git a/drivers/gpu/drm/i915/intel_display.c 
  b/drivers/gpu/drm/i915/intel_display.c
  index cf3ad87..d593897 100644
  --- a/drivers/gpu/drm/i915/intel_display.c
  +++ b/drivers/gpu/drm/i915/intel_display.c
  @@ -6945,7 +6945,8 @@ static void intel_pch_transcoder_get_m_n(struct 
  intel_crtc *crtc,
   
   static void intel_cpu_transcoder_get_m_n(struct intel_crtc *crtc,
   enum transcoder transcoder,
  -struct intel_link_m_n *m_n)
  +struct intel_link_m_n *m_n,
  +struct intel_link_m_n *m2_n2)
   {
  struct drm_device *dev = crtc-base.dev;
  struct drm_i915_private *dev_priv = dev-dev_private;
  @@ -6959,6 +6960,15 @@ static void intel_cpu_transcoder_get_m_n(struct 
  intel_crtc *crtc,
  m_n-gmch_n = I915_READ(PIPE_DATA_N1(transcoder));
  m_n-tu = ((I915_READ(PIPE_DATA_M1(transcoder))
   TU_SIZE_MASK)  TU_SIZE_SHIFT) + 1;
  +   if (m2_n2  INTEL_INFO(dev)-gen  8) {
  +   m2_n2-link_m = 
  I915_READ(PIPE_LINK_M2(transcoder));
  +   m2_n2-link_n = 
  I915_READ(PIPE_LINK_N2(transcoder));
  +   m2_n2-gmch_m = 
  I915_READ(PIPE_DATA_M2(transcoder))
  +~TU_SIZE_MASK;
  +   m2_n2-gmch_n = 
  I915_READ(PIPE_DATA_N2(transcoder));
  +   m2_n2-tu = 
  ((I915_READ(PIPE_DATA_M2(transcoder))
  +TU_SIZE_MASK)  
  TU_SIZE_SHIFT) + 1;
  +   }
  } else {
  m_n-link_m = I915_READ(PIPE_LINK_M_G4X(pipe));
  m_n-link_n = I915_READ(PIPE_LINK_N_G4X(pipe));
  @@ -6977,14 +6987,15 @@ void intel_dp_get_m_n(struct intel_crtc *crtc,
  intel_pch_transcoder_get_m_n(crtc, 
  pipe_config-dp_m_n);
  else
  intel_cpu_transcoder_get_m_n(crtc, 
  pipe_config-cpu_transcoder,
  -pipe_config-dp_m_n);
  +pipe_config-dp_m_n,
  +pipe_config-dp_m2_n2);
   }
   
   static void ironlake_get_fdi_m_n_config(struct intel_crtc *crtc,
  struct intel_crtc_config 
  *pipe_config)
   {
  intel_cpu_transcoder_get_m_n(crtc, pipe_config-cpu_transcoder,
  -pipe_config-fdi_m_n);
  +pipe_config-fdi_m_n, NULL);
   }
   
   static void ironlake_get_pfit_config(struct intel_crtc *crtc,
  @@ -9485,6 +9496,15 @@ static void intel_dump_pipe_config(struct 
  intel_crtc *crtc,
pipe_config-dp_m_n.gmch_m, 
  pipe_config-dp_m_n.gmch_n,
pipe_config-dp_m_n.link_m, 
  pipe_config-dp_m_n.link_n,
pipe_config-dp_m_n.tu);
  +
  +   DRM_DEBUG_KMS(dp: %i, gmch_m2: %u, gmch_n2: %u, link_m2: %u, 
  link_n2: %u, tu2: %u\n,
  + pipe_config-has_dp_encoder,
  + pipe_config-dp_m2_n2.gmch_m,
  + pipe_config-dp_m2_n2.gmch_n,
  +  

Re: [Intel-gfx] [PATCH v2] drm/i915: Bring GPU Freq to min while suspending.

2014-06-18 Thread Daniel Vetter
On Thu, Jun 19, 2014 at 08:53:24AM +0530, Deepak S wrote:
 
 On Wednesday 18 June 2014 03:47 AM, Daniel Vetter wrote:
 On Wed, Jun 18, 2014 at 05:30:53AM +0530, deepa...@linux.intel.com wrote:
 From: Deepak S deepa...@linux.intel.com
 
 We might be leaving the GPU Frequency (and thus vnn) high during the 
 suspend.
 Flush the delayed work queue should take care of this.
 
 v2: Fixed typo in commit message (Deepak)
 
 Signed-off-by: Deepak S deepa...@linux.intel.com
 ---
   drivers/gpu/drm/i915/i915_gem.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_gem.c 
 b/drivers/gpu/drm/i915/i915_gem.c
 index 7f643db..8d5ae82 100644
 --- a/drivers/gpu/drm/i915/i915_gem.c
 +++ b/drivers/gpu/drm/i915/i915_gem.c
 @@ -4541,7 +4541,7 @@ i915_gem_suspend(struct drm_device *dev)
 del_timer_sync(dev_priv-gpu_error.hangcheck_timer);
 cancel_delayed_work_sync(dev_priv-mm.retire_work);
 -   cancel_delayed_work_sync(dev_priv-mm.idle_work);
 +   flush_delayed_work(dev_priv-mm.idle_work);
 Shouldn't we do that in suspend_gt_powersave instead? Also if we cancel
 the retire work the idle work won't necessarily get armed and we might
 miss the window. Just forcing the gt to the lowest freq in
 suspend_gt_powersave should be more reliable.
 -Daniel
 
 Since we a calling suspend_gt_powersave after i915_gem_suspend, i added the 
 flush in suspend.

I'm confused: So you're doing the change I've suggested or it doesn't
work? Please unconfuse me ;-)

 Yes i agree forcing the gt freq us more reliable

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


Re: [Intel-gfx] [PATCH 00/11] Support for 180 degree HW rotation

2014-06-18 Thread Damien Lespiau
On Wed, Jun 18, 2014 at 02:27:16PM +0530, sonika.jin...@intel.com wrote:
 From: Sonika Jindal sonika.jin...@intel.com
 
 Enables 180 degree rotation for sprite and primary planes.
 Updated the primary plane rotation support as per the new universal plane
 design.
 
 Most of these patches were already reviewed in intel-gfx in February 2014 
 thats
 why there is version history in few of them.
 
 Testcase: kms_rotation_crc
 This igt can be extended for clipped rotation cases. Right it only tests 180
 degree rotation for sprite and primary plane with crc check.
 
 Sonika Jindal (2):
   tests/kms_rotation_crc: IGT for 180 degree HW rotation
   drm/i915: Add 180 degree primary plane rotation support
 
 Ville Syrjälä (9):
   drm: Move DRM_ROTATE bits out of omapdrm into drm_crtc.h
   drm: Add support_bits parameter to drm_property_create_bitmask()
   drm: Add drm_mode_create_rotation_property()
   drm/omap: Switch omapdrm over to drm_mode_create_rotation_property()
   drm: Add drm_rect rotation functions
   drm: Add drm_rotation_simplify()
   drm/i915: Add 180 degree sprite rotation support
   drm/i915: Make intel_plane_restore() return an error
   drm/i915: Add rotation property for sprites

Now that we have universal planes, I guess the last blocker for this
series is gone. Thanks for keeping at it.

Some of these patches already had review tags. Would you mind:

  - Re-add the r-b tags already gathered,
  - Remove Greg KH from the Cc. list, let's not bother him with that
  - Remove Dave Airlie from the Cc. list, dri-devel is enough (+ us
pinging him about the series if necessary)
  - Don't resend the igt patch with the kernel ones,
  - Add a patch on top to update the big property table
Documentation/DocBook/drm.tmpl - let's make sure we don't upstream
new properties without updating that list

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


Re: [Intel-gfx] [PATCH 00/11] Support for 180 degree HW rotation

2014-06-18 Thread Chris Wilson
On Wed, Jun 18, 2014 at 12:00:36PM +0100, Damien Lespiau wrote:
 On Wed, Jun 18, 2014 at 02:27:16PM +0530, sonika.jin...@intel.com wrote:
  From: Sonika Jindal sonika.jin...@intel.com
  
  Enables 180 degree rotation for sprite and primary planes.
  Updated the primary plane rotation support as per the new universal plane
  design.
  
  Most of these patches were already reviewed in intel-gfx in February 2014 
  thats
  why there is version history in few of them.
  
  Testcase: kms_rotation_crc
  This igt can be extended for clipped rotation cases. Right it only tests 180
  degree rotation for sprite and primary plane with crc check.
  
  Sonika Jindal (2):
tests/kms_rotation_crc: IGT for 180 degree HW rotation
drm/i915: Add 180 degree primary plane rotation support
  
  Ville Syrjälä (9):
drm: Move DRM_ROTATE bits out of omapdrm into drm_crtc.h
drm: Add support_bits parameter to drm_property_create_bitmask()
drm: Add drm_mode_create_rotation_property()
drm/omap: Switch omapdrm over to drm_mode_create_rotation_property()
drm: Add drm_rect rotation functions
drm: Add drm_rotation_simplify()
drm/i915: Add 180 degree sprite rotation support
drm/i915: Make intel_plane_restore() return an error
drm/i915: Add rotation property for sprites
 
 Now that we have universal planes, I guess the last blocker for this
 series is gone. Thanks for keeping at it.

Hah. We were last arguing over the property names.
-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 00/11] Support for 180 degree HW rotation

2014-06-18 Thread Damien Lespiau
On Wed, Jun 18, 2014 at 12:07:17PM +0100, Chris Wilson wrote:
  Now that we have universal planes, I guess the last blocker for this
  series is gone. Thanks for keeping at it.
 
 Hah. We were last arguing over the property names.

But only because the property was on the CRTC and rotation (or
primary-rotation) ended up in limbo? The property is now on the
(primary) plane object.

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


Re: [Intel-gfx] [PATCH 09/11] drm/i915: Add rotation property for sprites

2014-06-18 Thread Damien Lespiau
On Wed, Jun 18, 2014 at 02:27:25PM +0530, sonika.jin...@intel.com wrote:
 From: Ville Syrjälä ville.syrjala at linux.intel.com
 
 Sprite planes support 180 degree rotation. The lower layers are now in
 place, so hook in the standard rotation property to expose the feature
 to the users.
 
 Cc: Daniel Vetter daniel.vetter at ffwll.ch
 Cc: Jani Nikula jani.nikula at linux.intel.com
 Cc: David Airlie airlied at linux.ie
 Cc: dri-devel at lists.freedesktop.org
 Cc: linux-kernel at vger.kernel.org
 Signed-off-by: Ville Syrjälä ville.syrjala at linux.intel.com
 ---
  drivers/gpu/drm/i915/i915_drv.h |1 +
  drivers/gpu/drm/i915/intel_sprite.c |   42 
 ++-
  2 files changed, 42 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index 0640071..b56a1a5 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -1514,6 +1514,7 @@ struct drm_i915_private {
  
   struct drm_property *broadcast_rgb_property;
   struct drm_property *force_audio_property;
 + struct drm_property *rotation_property;
  
   uint32_t hw_context_size;
   struct list_head context_list;
 diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
 b/drivers/gpu/drm/i915/intel_sprite.c
 index cbad738..b9af256 100644
 --- a/drivers/gpu/drm/i915/intel_sprite.c
 +++ b/drivers/gpu/drm/i915/intel_sprite.c
 @@ -1202,6 +1202,30 @@ out_unlock:
   return ret;
  }
  
 +static int intel_plane_set_property(struct drm_plane *plane,
 + struct drm_property *prop,
 + uint64_t val)
 +{
 + struct drm_i915_private *dev_priv = plane-dev-dev_private;
 + struct intel_plane *intel_plane = to_intel_plane(plane);
 + uint64_t old_val;
 + int ret = -ENOENT;
 +
 + if (prop == dev_priv-rotation_property) {

Shouldn't we add a:

if (val  (BIT(DRM_ROTATE_0) | BIT(DRM_ROTATE_180)))
return -EINVAL;

To ensure userspace doesn't send garbage in the upper bits so we can
reuse them down the road?

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


Re: [Intel-gfx] [PATCH 00/11] Support for 180 degree HW rotation

2014-06-18 Thread Chris Wilson
On Wed, Jun 18, 2014 at 12:12:31PM +0100, Damien Lespiau wrote:
 On Wed, Jun 18, 2014 at 12:07:17PM +0100, Chris Wilson wrote:
   Now that we have universal planes, I guess the last blocker for this
   series is gone. Thanks for keeping at it.
  
  Hah. We were last arguing over the property names.
 
 But only because the property was on the CRTC and rotation (or
 primary-rotation) ended up in limbo? The property is now on the
 (primary) plane object.

Ville also had plans for a superproperty called rotation on the CRTC
that would adjust all planes. Not quite sure what his final plans were.
-Chris

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


[Intel-gfx] [PATCH 1/4] drm/i915: Suppress redundant syncs with mmio page flips

2014-06-18 Thread Chris Wilson
Since mmio-flips do not occur on the suggested ring, we are introducing
an extra sync operation where none is required. Pass the current
obj-ring, which is what mmio flip will use, to pin_to_display_plane so
that we emit the appropriate synchronisation (none).

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/intel_display.c | 29 -
 1 file changed, 20 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5e8e711..55cb343 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9492,21 +9492,32 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
ring = dev_priv-ring[RCS];
}
 
-   ret = intel_pin_and_fence_fb_obj(dev, obj, ring);
-   if (ret)
-   goto cleanup_pending;
+   if (use_mmio_flip(ring, obj)) {
+   ret = intel_pin_and_fence_fb_obj(dev, obj, obj-ring);
+   if (ret)
+   goto cleanup_pending;
 
-   work-gtt_offset =
-   i915_gem_obj_ggtt_offset(obj) + intel_crtc-dspaddr_offset;
+   work-gtt_offset =
+   i915_gem_obj_ggtt_offset(obj) + 
intel_crtc-dspaddr_offset;
 
-   if (use_mmio_flip(ring, obj))
ret = intel_queue_mmio_flip(dev, crtc, fb, obj, ring,
page_flip_flags);
-   else
+   if (ret)
+   goto cleanup_unpin;
+
+   } else {
+   ret = intel_pin_and_fence_fb_obj(dev, obj, ring);
+   if (ret)
+   goto cleanup_pending;
+
+   work-gtt_offset =
+   i915_gem_obj_ggtt_offset(obj) + 
intel_crtc-dspaddr_offset;
+
ret = dev_priv-display.queue_flip(dev, crtc, fb, obj, ring,
page_flip_flags);
-   if (ret)
-   goto cleanup_unpin;
+   if (ret)
+   goto cleanup_unpin;
+   }
 
intel_disable_fbc(dev);
intel_mark_fb_busy(obj, NULL);
-- 
1.9.1

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


[Intel-gfx] [PATCH 2/4] drm/i915: Check for a stalled page flip after each vblank

2014-06-18 Thread Chris Wilson
Long ago, back in the racy haydays of 915gm interrupt handling, page
flips would occasionally go astray and leave the hardware stuck, and the
display not updating. This annoyed people who relied on their systems
being able to display continuously updating information 24/7, and so
some code to detect when the driver missed the page flip completion
signal was added. Until recently, it was presumed that the interrupt
handling was now flawless, but once again Simon Farnsworth has found a
system whose display will stall. Reinstate the pageflip stall detection,
which works by checking to see if the hardware has been updated to the
new framebuffer address following each vblank. If the hardware is
scanning out from the new framebuffer, but we still think the flip is
pending, then we kick our driver into submision.

This is a continuation of the effort started with
commit 4e5359cd053bfb7d8dabe4a63624a5726848ffbc
Author: Simon Farnsworth simon.farnswo...@onelan.co.uk
Date:   Wed Sep 1 17:47:52 2010 +0100

drm/i915: Avoid pageflipping freeze when we miss the flip prepare interrupt

This now includes a belt-and-braces approach to make sure the driver
(or the hardware) doesn't miss an interrupt and cause us to stop
updating the display should the unthinkable happen and the pageflip fail - i.e.
that the user is able to continue submitting flips.

v2: Cleanup, refactor, and rename
v3: Only start counting vblanks after the flip command has been seen by
the hardware.
v4: Record the seqno after we touch the ring, or else there may be no
seqno allocated yet.
v5: Rebase on mmio-flip.

Reported-by: Simon Farnsworth si...@farnz.org.uk
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75502
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com [v4]
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  32 ++---
 drivers/gpu/drm/i915/i915_irq.c  |  84 +++
 drivers/gpu/drm/i915/intel_display.c | 127 ---
 drivers/gpu/drm/i915/intel_drv.h |   5 ++
 4 files changed, 155 insertions(+), 93 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 76c2572..b4c6f20 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -511,6 +511,7 @@ static int i915_gem_pageflip_info(struct seq_file *m, void 
*data)
 {
struct drm_info_node *node = m-private;
struct drm_device *dev = node-minor-dev;
+   struct drm_i915_private *dev_priv = dev-dev_private;
unsigned long flags;
struct intel_crtc *crtc;
int ret;
@@ -530,6 +531,8 @@ static int i915_gem_pageflip_info(struct seq_file *m, void 
*data)
seq_printf(m, No flip due on pipe %c (plane %c)\n,
   pipe, plane);
} else {
+   u32 addr;
+
if (atomic_read(work-pending)  INTEL_FLIP_COMPLETE) {
seq_printf(m, Flip queued on pipe %c (plane 
%c)\n,
   pipe, plane);
@@ -537,23 +540,32 @@ static int i915_gem_pageflip_info(struct seq_file *m, 
void *data)
seq_printf(m, Flip pending (waiting for vsync) 
on pipe %c (plane %c)\n,
   pipe, plane);
}
+   if (work-ring)
+   seq_printf(m, Flip queued on %s at seqno %u, 
now %u\n,
+   work-ring-name,
+   work-flip_queued_seqno,
+   
work-ring-get_seqno(work-ring, true));
+   else
+   seq_printf(m, Flip not associated with any 
ring\n);
+   seq_printf(m, Flip queued on frame %d, (was ready on 
frame %d), now %d\n,
+  work-flip_queued_vblank,
+  work-flip_ready_vblank,
+  drm_vblank_count(dev, crtc-pipe));
if (work-enable_stall_check)
seq_puts(m, Stall check enabled, );
else
seq_puts(m, Stall check waiting for page flip 
ioctl, );
seq_printf(m, %d prepares\n, 
atomic_read(work-pending));
 
-   if (work-old_fb_obj) {
-   struct drm_i915_gem_object *obj = 
work-old_fb_obj;
-   if (obj)
-   seq_printf(m, Old framebuffer 
gtt_offset 0x%08lx\n,
-  
i915_gem_obj_ggtt_offset(obj));

[Intel-gfx] [PATCH 4/4] drm/i915: Boost GPU frequency if we detect outstanding pageflips

2014-06-18 Thread Chris Wilson
If we hit a vblank and see that have a pageflip queue but not yet
processed, ensure that the GPU is running at maximum in order to clear
the backlog. Pageflips are only queued for the following vblank, if we
miss it, there will be a visible stutter. Boosting the GPU frequency
doesn't prevent us from missing the target vblank, but it should help
the subsequent frames hitting theirs.

v2: Reorder vblank vs flip-complete so that we only check for a missed
flip after processing the completion events, and avoid spurious boosts.

v3: Rename missed_vblank
v4: Rebase
v5: Cancel the outstanding work in runtime suspend

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_drv.c  |  1 +
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_display.c |  6 ++
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 drivers/gpu/drm/i915/intel_pm.c  | 15 +++
 5 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7ae4e2a..e792aa4 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1399,6 +1399,7 @@ static int intel_runtime_suspend(struct device *device)
 * sure the GPU is idle and the RPS freq is set to the minimum. See
 * intel_mark_idle().
 */
+   cancel_work_sync(dev_priv-rps.boost_work);
cancel_work_sync(dev_priv-rps.work);
intel_runtime_pm_disable_interrupts(dev);
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0640071..d8a59c2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -910,6 +910,7 @@ struct intel_gen6_power_mgmt {
 
bool enabled;
struct delayed_work delayed_resume_work;
+   struct work_struct boost_work;
 
/*
 * Protects RPS/RC6 register access and PCU communication.
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0301e8c..b9c62b7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9463,6 +9463,7 @@ void intel_check_page_flip(struct drm_device *dev, int 
pipe)
struct drm_crtc *crtc = dev_priv-pipe_to_crtc_mapping[pipe];
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
unsigned long flags;
+   bool missed_vblank;
 
if (crtc == NULL)
return;
@@ -9473,7 +9474,12 @@ void intel_check_page_flip(struct drm_device *dev, int 
pipe)
 intel_crtc-unpin_work-flip_queued_vblank, 
drm_vblank_count(dev, pipe));
page_flip_completed(intel_crtc);
}
+   missed_vblank = (intel_crtc-unpin_work != NULL 
+drm_vblank_count(dev, pipe) - 
intel_crtc-unpin_work-flip_queued_vblank  1);
spin_unlock_irqrestore(dev-event_lock, flags);
+
+   if (missed_vblank)
+   intel_queue_rps_boost(dev);
 }
 
 static int intel_crtc_page_flip(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index fd5d1ef..e38645c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -978,6 +978,7 @@ void ironlake_teardown_rc6(struct drm_device *dev);
 void gen6_update_ring_freq(struct drm_device *dev);
 void gen6_rps_idle(struct drm_i915_private *dev_priv);
 void gen6_rps_boost(struct drm_i915_private *dev_priv);
+void intel_queue_rps_boost(struct drm_device *dev);
 void intel_aux_display_runtime_get(struct drm_i915_private *dev_priv);
 void intel_aux_display_runtime_put(struct drm_i915_private *dev_priv);
 void intel_runtime_pm_get(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 2043c4b..ebc11bd 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6792,6 +6792,19 @@ int vlv_freq_opcode(struct drm_i915_private *dev_priv, 
int val)
return DIV_ROUND_CLOSEST(4 * mul * val, dev_priv-mem_freq) + 0xbd - 6;
 }
 
+static void __intel_rps_boost_work(struct work_struct *work)
+{
+   gen6_rps_boost(container_of(work, struct drm_i915_private, 
rps.boost_work));
+}
+
+void intel_queue_rps_boost(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   if (INTEL_INFO(dev)-gen = 6)
+   queue_work(dev_priv-wq, dev_priv-rps.boost_work);
+}
+
 void intel_pm_setup(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -6800,6 +6813,8 @@ void intel_pm_setup(struct drm_device *dev)
 
INIT_DELAYED_WORK(dev_priv-rps.delayed_resume_work,
  intel_gen6_powersave_work);
+   INIT_WORK(dev_priv-rps.boost_work,
+ __intel_rps_boost_work);
 
dev_priv-pm.suspended = false;
dev_priv-pm.irqs_disabled = 

[Intel-gfx] [PATCH 3/4] drm/i915: Decouple the stuck pageflip on modeset

2014-06-18 Thread Chris Wilson
If we successfully confuse the hardware, and cause it to drop a queued
pageflip, we wait for 60s and issue a warning before continuing on with
the modeset. However, this leaves the pending pageflip still stuck
indefinitely. Pretend to userspace that it does complete, and let us
start afresh following the modeset.

v2: Rebase after refactor

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/intel_display.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9a077b6..0301e8c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3368,9 +3368,19 @@ void intel_crtc_wait_for_pending_flips(struct drm_crtc 
*crtc)
 
WARN_ON(waitqueue_active(dev_priv-pending_flip_queue));
 
-   WARN_ON(wait_event_timeout(dev_priv-pending_flip_queue,
-  !intel_crtc_has_pending_flip(crtc),
-  60*HZ) == 0);
+   if (WARN_ON(wait_event_timeout(dev_priv-pending_flip_queue,
+  !intel_crtc_has_pending_flip(crtc),
+  60*HZ) == 0)) {
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   unsigned long flags;
+
+   spin_lock_irqsave(dev-event_lock, flags);
+   if (intel_crtc-unpin_work) {
+   WARN_ONCE(1, Removing stuck page flip\n);
+   page_flip_completed(intel_crtc);
+   }
+   spin_unlock_irqrestore(dev-event_lock, flags);
+   }
 
mutex_lock(dev-struct_mutex);
intel_finish_fb(crtc-primary-fb);
-- 
1.9.1

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


Re: [Intel-gfx] [PATCH 11/11] tests/kms_rotation_crc: IGT for 180 degree HW rotation

2014-06-18 Thread Damien Lespiau
On Wed, Jun 18, 2014 at 02:27:27PM +0530, sonika.jin...@intel.com wrote:
 From: Sonika Jindal sonika.jin...@intel.com
 
 Testcase for 180 degree HW rotation
 
 Cc: sagar.a.kam...@intel.com
 
 Signed-off-by: Sonika Jindal sonika.jin...@intel.com

The test looks good to me (I haven't checked in details, the bar for igt
is quite a bit lower). It shows two gaps in the igt kms API:

  - Retrieving the primary plane (there's a series from Matt fixing this
and exposing the primary plane through igt_output_get_plane())
  - Adding a set_property() convenience function
(ala igt_plane_set_property(rotation, BIT(DRM_ROTATE_180)))
(no-one is working on that just yet, can de done later)

A small question before pushing this, have you checked that the test
correctly skips when running with a kernel without rotation support?

Thanks,

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


Re: [Intel-gfx] [PATCH 00/11] Support for 180 degree HW rotation

2014-06-18 Thread Damien Lespiau
On Wed, Jun 18, 2014 at 12:21:39PM +0100, Chris Wilson wrote:
 On Wed, Jun 18, 2014 at 12:12:31PM +0100, Damien Lespiau wrote:
  On Wed, Jun 18, 2014 at 12:07:17PM +0100, Chris Wilson wrote:
Now that we have universal planes, I guess the last blocker for this
series is gone. Thanks for keeping at it.
   
   Hah. We were last arguing over the property names.
  
  But only because the property was on the CRTC and rotation (or
  primary-rotation) ended up in limbo? The property is now on the
  (primary) plane object.
 
 Ville also had plans for a superproperty called rotation on the CRTC
 that would adjust all planes. Not quite sure what his final plans were.

Sure, that would have to be some extra fun to be had for another time
though (looks useful).

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


Re: [Intel-gfx] [PATCH 11/11] tests/kms_rotation_crc: IGT for 180 degree HW rotation

2014-06-18 Thread Chris Wilson
On Wed, Jun 18, 2014 at 12:32:00PM +0100, Damien Lespiau wrote:
 On Wed, Jun 18, 2014 at 02:27:27PM +0530, sonika.jin...@intel.com wrote:
  From: Sonika Jindal sonika.jin...@intel.com
  
  Testcase for 180 degree HW rotation
  
  Cc: sagar.a.kam...@intel.com
  
  Signed-off-by: Sonika Jindal sonika.jin...@intel.com
 
 The test looks good to me (I haven't checked in details, the bar for igt
 is quite a bit lower). It shows two gaps in the igt kms API:
 
   - Retrieving the primary plane (there's a series from Matt fixing this
 and exposing the primary plane through igt_output_get_plane())
   - Adding a set_property() convenience function
 (ala igt_plane_set_property(rotation, BIT(DRM_ROTATE_180)))
 (no-one is working on that just yet, can de done later)
 
 A small question before pushing this, have you checked that the test
 correctly skips when running with a kernel without rotation support?

Note: don't push userspace using new ABI until that ABI has been
agreed upon and committed to the kernel.
-Chris

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


[Intel-gfx] [PATCH 02/10] drm: Add support_bits parameter to drm_property_create_bitmask()

2014-06-18 Thread sonika . jindal
From: Ville Syrjälä ville.syrjala at linux.intel.com

Make drm_property_create_bitmask() a bit more generic by allowing the
caller to specify which bits are in fact supported. This allows multiple
callers to use the same enum list, but still create different versions
of the same property with different list of supported bits.

v2: Populate values[] array as non-sparse
Make supported_bits 64bit
Fix up omapdrm call site (Rob)

Cc: Tomi Valkeinen tomi.valkeinen at ti.com
Cc: Rob Clark robdclark at gmail.com
Cc: Sagar Kamble sagar.a.kamble at intel.com
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Ville Syrjälä ville.syrjala at linux.intel.com
Reviewed-by: Imre Deak imre.deak at intel.com
Reviewed-by: Sagar Kamble sagar.a.kam...@intel.com
---
 drivers/gpu/drm/drm_crtc.c   |   17 +
 drivers/gpu/drm/omapdrm/omap_plane.c |5 -
 include/drm/drm_crtc.h   |3 ++-
 3 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 41c7212..2fbee61 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3395,19 +3395,28 @@ EXPORT_SYMBOL(drm_property_create_enum);
 struct drm_property *drm_property_create_bitmask(struct drm_device *dev,
 int flags, const char *name,
 const struct drm_prop_enum_list *props,
-int num_values)
+int num_props,
+uint64_t supported_bits)
 {
struct drm_property *property;
-   int i, ret;
+   int i, ret, index = 0;
+   int num_values = hweight64(supported_bits);
 
flags |= DRM_MODE_PROP_BITMASK;
 
property = drm_property_create(dev, flags, name, num_values);
if (!property)
return NULL;
+   for (i = 0; i  num_props; i++) {
+   if (!(supported_bits  (1ULL  props[i].type)))
+   continue;
 
-   for (i = 0; i  num_values; i++) {
-   ret = drm_property_add_enum(property, i,
+   if (WARN_ON(index = num_values)) {
+   drm_property_destroy(dev, property);
+   return NULL;
+   }
+
+   ret = drm_property_add_enum(property, index++,
  props[i].type,
  props[i].name);
if (ret) {
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 3cf31ee..aff06e7 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -317,7 +317,10 @@ void omap_plane_install_properties(struct drm_plane *plane,
{ DRM_REFLECT_Y,  reflect-y },
};
prop = drm_property_create_bitmask(dev, 0, rotation,
-   props, ARRAY_SIZE(props));
+   props, ARRAY_SIZE(props),
+   BIT(DRM_ROTATE_0) | BIT(DRM_ROTATE_90) |
+   BIT(DRM_ROTATE_180) | 
BIT(DRM_ROTATE_270) |
+   BIT(DRM_REFLECT_X) | 
BIT(DRM_REFLECT_Y));
if (prop == NULL)
return;
priv-rotation_prop = prop;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index bfc7235..cb4850a 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1006,7 +1006,8 @@ extern struct drm_property 
*drm_property_create_enum(struct drm_device *dev, int
 struct drm_property *drm_property_create_bitmask(struct drm_device *dev,
 int flags, const char *name,
 const struct drm_prop_enum_list *props,
-int num_values);
+int num_props,
+uint64_t supported_bits);
 struct drm_property *drm_property_create_range(struct drm_device *dev, int 
flags,
 const char *name,
 uint64_t min, uint64_t max);
-- 
1.7.10.4

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


[Intel-gfx] [PATCH 10/10] drm/i915: Add 180 degree primary plane rotation support

2014-06-18 Thread sonika . jindal
From: Sonika Jindal sonika.jin...@intel.com

Primary planes support 180 degree rotation. Expose the feature
through rotation drm property.

v2: Calculating linear/tiled offsets based on pipe source width and
height. Added 180 degree rotation support in ironlake_update_plane.

v3: Checking if CRTC is active before issueing update_plane. Added
wait for vblank to make sure we dont overtake page flips. Disabling
FBC since it does not work with rotated planes.

v4: Updated rotation checks for pending flips, fbc disable. Creating
rotation property only for Gen4 onwards. Property resetting as part
of lastclose.

v5: Resetting property in i915_driver_lastclose properly for planes
and crtcs. Fixed linear offset calculation that was off by 1 w.r.t
width in i9xx_update_plane and ironlake_update_plane. Removed tab
based indentation and unnecessary braces in intel_crtc_set_property
and intel_update_fbc. FBC and flip related checks should be done only
for valid crtcs.

v6: Minor nits in FBC disable checks for comments in intel_crtc_set_property
and positioning the disable code in intel_update_fbc.

v7: In case rotation property on inactive crtc is updated, we return
successfully printing debug log as crtc is inactive and only property change
is preserved.

v8: update_plane is changed to update_primary_plane, crtc-fb is changed to
crtc-primary-fb  and return value of update_primary_plane is ignored.

v9: added rotation property to primary plane instead of crtc.

Testcase: igt/kms_rotation_crc

Cc: Daniel Vetter daniel.vetter at ffwll.ch
Cc: Jani Nikula jani.nikula at linux.intel.com
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Cc: vijay.a.purushothaman at intel.com
Signed-off-by: Uma Shankar uma.shankar at intel.com
Signed-off-by: Sagar Kamble sagar.a.kamble at intel.com
Reviewed-by: Ville Syrjälä ville.syrjala at linux.intel.com
---
 drivers/gpu/drm/i915/i915_dma.c  |   17 +++
 drivers/gpu/drm/i915/i915_reg.h  |1 +
 drivers/gpu/drm/i915/intel_display.c |   91 --
 drivers/gpu/drm/i915/intel_pm.c  |8 +++
 4 files changed, 113 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 5e583a1..4c91fbc 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1939,6 +1939,8 @@ int i915_driver_open(struct drm_device *dev, struct 
drm_file *file)
 void i915_driver_lastclose(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
+   struct intel_crtc *crtc;
+   struct intel_plane *plane;
 
/* On gen6+ we refuse to init without kms enabled, but then the drm core
 * goes right around and calls lastclose. Check for this and don't clean
@@ -1946,6 +1948,21 @@ void i915_driver_lastclose(struct drm_device *dev)
if (!dev_priv)
return;
 
+   if (dev_priv-rotation_property) {
+   list_for_each_entry(crtc, dev-mode_config.crtc_list, 
base.head) {
+   to_intel_plane(crtc-base.primary)-rotation = 
BIT(DRM_ROTATE_0);
+   drm_object_property_set_value(crtc-base.base,
+   dev_priv-rotation_property,
+   
to_intel_plane(crtc-base.primary)-rotation);
+   }
+   list_for_each_entry(plane, dev-mode_config.plane_list, 
base.head) {
+   plane-rotation = BIT(DRM_ROTATE_0);
+   drm_object_property_set_value(plane-base.base,
+   dev_priv-rotation_property,
+   plane-rotation);
+   }
+   }
+
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
intel_fbdev_restore_mode(dev);
vga_switcheroo_process_delayed_switch();
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c70c804..c600d3b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4087,6 +4087,7 @@ enum punit_power_well {
 #define   DISPPLANE_NO_LINE_DOUBLE 0
 #define   DISPPLANE_STEREO_POLARITY_FIRST  0
 #define   DISPPLANE_STEREO_POLARITY_SECOND (118)
+#define   DISPPLANE_ROTATE_180 (115)
 #define   DISPPLANE_TRICKLE_FEED_DISABLE   (114) /* Ironlake */
 #define   DISPPLANE_TILED  (110)
 #define _DSPAADDR  0x70184
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5e8e711..1dc8b68 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2414,7 +2414,9 @@ static void i9xx_update_primary_plane(struct drm_crtc 
*crtc,
unsigned long linear_offset;
u32 dspcntr;
u32 reg;
+   int pixel_size;
 
+   pixel_size = drm_format_plane_cpp(fb-pixel_format, 0);
   

[Intel-gfx] [PATCH 07/10] drm/i915: Add 180 degree sprite rotation support

2014-06-18 Thread sonika . jindal
From: Ville Syrjälä ville.syrjala at linux.intel.com

The sprite planes (in fact all display planes starting from gen4)
support 180 degree rotation. Add the relevant low level bits to the
sprite code to make use of that feature.

The upper layers are not yet plugged in.

v2: HSW handles the rotated buffer offset automagically

v3: BDW also handles the rotated buffer offset automagically

Testcase: igt/kms_rotation_crc

Cc: Daniel Vetter daniel.vetter at ffwll.ch
Cc: Jani Nikula jani.nikula at linux.intel.com
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Ville Syrjälä ville.syrjala at linux.intel.com
Signed-off-by: Sagar Kamble sagar.a.kamble at intel.com
Reviewed-by: Imre Deak imre.deak at intel.com
---
 drivers/gpu/drm/i915/i915_reg.h |3 +++
 drivers/gpu/drm/i915/intel_drv.h|1 +
 drivers/gpu/drm/i915/intel_sprite.c |   37 +++
 3 files changed, 41 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3488567..c70c804 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4171,6 +4171,7 @@ enum punit_power_well {
 #define   DVS_YUV_ORDER_UYVY   (116)
 #define   DVS_YUV_ORDER_YVYU   (216)
 #define   DVS_YUV_ORDER_VYUY   (316)
+#define   DVS_ROTATE_180   (115)
 #define   DVS_DEST_KEY (12)
 #define   DVS_TRICKLE_FEED_DISABLE (114)
 #define   DVS_TILED(110)
@@ -4241,6 +4242,7 @@ enum punit_power_well {
 #define   SPRITE_YUV_ORDER_UYVY(116)
 #define   SPRITE_YUV_ORDER_YVYU(216)
 #define   SPRITE_YUV_ORDER_VYUY(316)
+#define   SPRITE_ROTATE_180(115)
 #define   SPRITE_TRICKLE_FEED_DISABLE  (114)
 #define   SPRITE_INT_GAMMA_ENABLE  (113)
 #define   SPRITE_TILED (110)
@@ -4314,6 +4316,7 @@ enum punit_power_well {
 #define   SP_YUV_ORDER_UYVY(116)
 #define   SP_YUV_ORDER_YVYU(216)
 #define   SP_YUV_ORDER_VYUY(316)
+#define   SP_ROTATE_180(115)
 #define   SP_TILED (110)
 #define _SPALINOFF (VLV_DISPLAY_BASE + 0x72184)
 #define _SPASTRIDE (VLV_DISPLAY_BASE + 0x72188)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ab5962b..67b1c59 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -437,6 +437,7 @@ struct intel_plane {
unsigned int crtc_w, crtc_h;
uint32_t src_x, src_y;
uint32_t src_w, src_h;
+   unsigned int rotation;
 
/* Since we need to change the watermarks before/after
 * enabling/disabling the planes, we need to store the parameters here
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 404335d..54d4224 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -163,6 +163,7 @@ vlv_update_plane(struct drm_plane *dplane, struct drm_crtc 
*crtc,
sprctl = ~SP_PIXFORMAT_MASK;
sprctl = ~SP_YUV_BYTE_ORDER_MASK;
sprctl = ~SP_TILED;
+   sprctl = ~SP_ROTATE_180;
 
switch (fb-pixel_format) {
case DRM_FORMAT_YUYV:
@@ -234,6 +235,14 @@ vlv_update_plane(struct drm_plane *dplane, struct drm_crtc 
*crtc,
fb-pitches[0]);
linear_offset -= sprsurf_offset;
 
+   if (intel_plane-rotation == BIT(DRM_ROTATE_180)) {
+   sprctl |= SP_ROTATE_180;
+
+   x += src_w;
+   y += src_h;
+   linear_offset += src_h * fb-pitches[0] + src_w * pixel_size;
+   }
+
atomic_update = intel_pipe_update_start(intel_crtc, start_vbl_count);
 
intel_update_primary_plane(intel_crtc);
@@ -363,6 +372,7 @@ ivb_update_plane(struct drm_plane *plane, struct drm_crtc 
*crtc,
sprctl = ~SPRITE_RGB_ORDER_RGBX;
sprctl = ~SPRITE_YUV_BYTE_ORDER_MASK;
sprctl = ~SPRITE_TILED;
+   sprctl = ~SPRITE_ROTATE_180;
 
switch (fb-pixel_format) {
case DRM_FORMAT_XBGR:
@@ -424,6 +434,17 @@ ivb_update_plane(struct drm_plane *plane, struct drm_crtc 
*crtc,
   pixel_size, fb-pitches[0]);
linear_offset -= sprsurf_offset;
 
+   if (intel_plane-rotation == BIT(DRM_ROTATE_180)) {
+   sprctl |= SPRITE_ROTATE_180;
+
+   /* HSW and BDW does this automagically in hardware */
+   if (!IS_HASWELL(dev)  !IS_BROADWELL(dev)) {
+   x += src_w;
+   y += src_h;
+   linear_offset += src_h * fb-pitches[0] + src_w * 
pixel_size;
+   }
+   }
+
atomic_update = intel_pipe_update_start(intel_crtc, start_vbl_count);
 
intel_update_primary_plane(intel_crtc);
@@ -569,6 +590,7 @@ ilk_update_plane(struct drm_plane *plane, struct drm_crtc 
*crtc,

[Intel-gfx] [PATCH 00/10] Support for 180 degree HW rotation

2014-06-18 Thread sonika . jindal
From: Sonika Jindal sonika.jin...@intel.com

Enables 180 degree rotation for sprite and primary planes.
Updated the primary plane rotation support as per the new universal plane
design.

Most of these patches were already reviewed in intel-gfx in February 2014 thats
why there is version history in few of them.

Testcase: kms_rotation_crc
This igt can be extended for clipped rotation cases. Right it only tests 180
degree rotation for sprite and primary plane with crc check.

Sonika Jindal (1):
  drm/i915: Add 180 degree primary plane rotation support

Ville Syrjälä (9):
  drm: Move DRM_ROTATE bits out of omapdrm into drm_crtc.h
  drm: Add support_bits parameter to drm_property_create_bitmask()
  drm: Add drm_mode_create_rotation_property()
  drm/omap: Switch omapdrm over to drm_mode_create_rotation_property()
  drm: Add drm_rect rotation functions
  drm: Add drm_rotation_simplify()
  drm/i915: Add 180 degree sprite rotation support
  drm/i915: Make intel_plane_restore() return an error
  drm/i915: Add rotation property for sprites

 drivers/gpu/drm/drm_crtc.c   |   66 +++-
 drivers/gpu/drm/drm_rect.c   |  140 ++
 drivers/gpu/drm/i915/i915_dma.c  |   17 +
 drivers/gpu/drm/i915/i915_drv.h  |1 +
 drivers/gpu/drm/i915/i915_reg.h  |4 +
 drivers/gpu/drm/i915/intel_display.c |   91 +-
 drivers/gpu/drm/i915/intel_drv.h |3 +-
 drivers/gpu/drm/i915/intel_pm.c  |8 ++
 drivers/gpu/drm/i915/intel_sprite.c  |   93 --
 drivers/gpu/drm/omapdrm/omap_drv.h   |7 --
 drivers/gpu/drm/omapdrm/omap_plane.c |   17 ++---
 include/drm/drm_crtc.h   |   15 +++-
 include/drm/drm_rect.h   |6 ++
 13 files changed, 433 insertions(+), 35 deletions(-)

-- 
1.7.10.4

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


[Intel-gfx] [PATCH 06/10] drm: Add drm_rotation_simplify()

2014-06-18 Thread sonika . jindal
From: Ville Syrjälä ville.syrjala at linux.intel.com

drm_rotation_simplify() can be used to eliminate unsupported rotation
flags. It will check if any unsupported flags are present, and if so
it will modify the rotation to an alternate form by adding 180 degrees
to rotation angle, and flipping the reflect x and y bits. The hope is
that this identity transform will eliminate the unsupported flags.

Of course that might not result in any more supported rotation, so
the caller is still responsible for checking the result afterwards.

Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Ville Syrjälä ville.syrjala at linux.intel.com
Reviewed-by: Imre Deak imre.deak at intel.com
---
 drivers/gpu/drm/drm_crtc.c |   30 ++
 include/drm/drm_crtc.h |2 ++
 2 files changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f224d4d..89bab66 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4842,6 +4842,36 @@ int drm_format_vert_chroma_subsampling(uint32_t format)
 EXPORT_SYMBOL(drm_format_vert_chroma_subsampling);
 
 /**
+ * drm_rotation_simplify() - Try to simplify the rotation
+ * @rotation: Rotation to be simplified
+ * @supported_rotations: Supported rotations
+ *
+ * Attempt to simplify the rotation to a form that is supported.
+ * Eg. if the hardware supports everything except DRM_REFLECT_X
+ * one could call this function like this:
+ *
+ * drm_rotation_simplify(rotation, BIT(DRM_ROTATE_0) |
+ *   BIT(DRM_ROTATE_90) | BIT(DRM_ROTATE_180) |
+ *   BIT(DRM_ROTATE_270) | BIT(DRM_REFLECT_Y));
+ *
+ * to eliminate the DRM_ROTATE_X flag. Depending on what kind of
+ * transforms the hardware supports, this function may not
+ * be able to produce a supported transform, so the caller should
+ * check the result afterwards.
+ */
+unsigned int drm_rotation_simplify(unsigned int rotation,
+  unsigned int supported_rotations)
+{
+   if (rotation  ~supported_rotations) {
+   rotation ^= BIT(DRM_REFLECT_X) | BIT(DRM_REFLECT_Y);
+   rotation = (rotation  ~0xf) | BIT((ffs(rotation  0xf) + 1) % 
4);
+   }
+
+   return rotation;
+}
+EXPORT_SYMBOL(drm_rotation_simplify);
+
+/**
  * drm_mode_config_init - initialize DRM mode_configuration structure
  * @dev: DRM device
  *
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f7b383b..08ed55e 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1115,6 +1115,8 @@ extern int drm_format_vert_chroma_subsampling(uint32_t 
format);
 extern const char *drm_get_format_name(uint32_t format);
 extern struct drm_property *drm_mode_create_rotation_property(struct 
drm_device *dev,
  unsigned int 
supported_rotations);
+extern unsigned int drm_rotation_simplify(unsigned int rotation,
+ unsigned int supported_rotations);
 
 /* Helpers */
 
-- 
1.7.10.4

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


[Intel-gfx] [PATCH 03/10] drm: Add drm_mode_create_rotation_property()

2014-06-18 Thread sonika . jindal
From: Ville Syrjälä ville.syrjala at linux.intel.com

Add a function to create a standards compliant rotation property.

Signed-off-by: Ville Syrjälä ville.syrjala at linux.intel.com
Reviewed-by: Imre Deak imre.deak at intel.com
---
 drivers/gpu/drm/drm_crtc.c |   18 ++
 include/drm/drm_crtc.h |2 ++
 2 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 2fbee61..f224d4d 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4959,3 +4959,21 @@ void drm_mode_config_cleanup(struct drm_device *dev)
drm_modeset_lock_fini(dev-mode_config.connection_mutex);
 }
 EXPORT_SYMBOL(drm_mode_config_cleanup);
+
+struct drm_property *drm_mode_create_rotation_property(struct drm_device *dev,
+  unsigned int 
supported_rotations)
+{
+   static const struct drm_prop_enum_list props[] = {
+   { DRM_ROTATE_0,   rotate-0 },
+   { DRM_ROTATE_90,  rotate-90 },
+   { DRM_ROTATE_180, rotate-180 },
+   { DRM_ROTATE_270, rotate-270 },
+   { DRM_REFLECT_X,  reflect-x },
+   { DRM_REFLECT_Y,  reflect-y },
+   };
+
+   return drm_property_create_bitmask(dev, 0, rotation,
+  props, ARRAY_SIZE(props),
+  supported_rotations);
+}
+EXPORT_SYMBOL(drm_mode_create_rotation_property);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index cb4850a..f7b383b 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1113,6 +1113,8 @@ extern int drm_format_plane_cpp(uint32_t format, int 
plane);
 extern int drm_format_horz_chroma_subsampling(uint32_t format);
 extern int drm_format_vert_chroma_subsampling(uint32_t format);
 extern const char *drm_get_format_name(uint32_t format);
+extern struct drm_property *drm_mode_create_rotation_property(struct 
drm_device *dev,
+ unsigned int 
supported_rotations);
 
 /* Helpers */
 
-- 
1.7.10.4

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


[Intel-gfx] [PATCH 09/10] drm/i915: Add rotation property for sprites

2014-06-18 Thread sonika . jindal
From: Ville Syrjälä ville.syrjala at linux.intel.com

Sprite planes support 180 degree rotation. The lower layers are now in
place, so hook in the standard rotation property to expose the feature
to the users.

Cc: Daniel Vetter daniel.vetter at ffwll.ch
Cc: Jani Nikula jani.nikula at linux.intel.com
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Ville Syrjälä ville.syrjala at linux.intel.com
Reviewed-by: Imre Deak imre.deak at intel.com
---
 drivers/gpu/drm/i915/i915_drv.h |1 +
 drivers/gpu/drm/i915/intel_sprite.c |   42 ++-
 2 files changed, 42 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0640071..b56a1a5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1514,6 +1514,7 @@ struct drm_i915_private {
 
struct drm_property *broadcast_rgb_property;
struct drm_property *force_audio_property;
+   struct drm_property *rotation_property;
 
uint32_t hw_context_size;
struct list_head context_list;
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index cbad738..b9af256 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1202,6 +1202,30 @@ out_unlock:
return ret;
 }
 
+static int intel_plane_set_property(struct drm_plane *plane,
+   struct drm_property *prop,
+   uint64_t val)
+{
+   struct drm_i915_private *dev_priv = plane-dev-dev_private;
+   struct intel_plane *intel_plane = to_intel_plane(plane);
+   uint64_t old_val;
+   int ret = -ENOENT;
+
+   if (prop == dev_priv-rotation_property) {
+   /* exactly one rotation angle please */
+   if (hweight32(val  0xf) != 1)
+   return -EINVAL;
+
+   old_val = intel_plane-rotation;
+   intel_plane-rotation = val;
+   ret = intel_plane_restore(plane);
+   if (ret)
+   intel_plane-rotation = old_val;
+   }
+
+   return ret;
+}
+
 int intel_plane_restore(struct drm_plane *plane)
 {
struct intel_plane *intel_plane = to_intel_plane(plane);
@@ -1228,6 +1252,7 @@ static const struct drm_plane_funcs intel_plane_funcs = {
.update_plane = intel_update_plane,
.disable_plane = intel_disable_plane,
.destroy = intel_destroy_plane,
+   .set_property = intel_plane_set_property,
 };
 
 static uint32_t ilk_plane_formats[] = {
@@ -1264,6 +1289,7 @@ static uint32_t vlv_plane_formats[] = {
 int
 intel_plane_init(struct drm_device *dev, enum pipe pipe, int plane)
 {
+   struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_plane *intel_plane;
unsigned long possible_crtcs;
const uint32_t *plane_formats;
@@ -1338,8 +1364,22 @@ intel_plane_init(struct drm_device *dev, enum pipe pipe, 
int plane)
 intel_plane_funcs,
 plane_formats, num_plane_formats,
 false);
-   if (ret)
+   if (ret) {
kfree(intel_plane);
+   goto out;
+   }
+
+   if (!dev_priv-rotation_property)
+   dev_priv-rotation_property =
+   drm_mode_create_rotation_property(dev,
+ BIT(DRM_ROTATE_0) |
+ BIT(DRM_ROTATE_180));
+
+   if (dev_priv-rotation_property)
+   drm_object_attach_property(intel_plane-base.base,
+  dev_priv-rotation_property,
+  intel_plane-rotation);
 
+ out:
return ret;
 }
-- 
1.7.10.4

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


[Intel-gfx] [PATCH 05/10] drm: Add drm_rect rotation functions

2014-06-18 Thread sonika . jindal
From: Ville Syrjälä ville.syrjala at linux.intel.com

Add some helper functions to move drm_rects between different rotated
coordinate spaces. One function does the forward transform and
another does the inverse.

Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Ville Syrjälä ville.syrjala at linux.intel.com
Reviewed-by: Imre Deak imre.deak at intel.com
---
 drivers/gpu/drm/drm_rect.c |  140 
 include/drm/drm_rect.h |6 ++
 2 files changed, 146 insertions(+)

diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
index 7047ca0..631f5af 100644
--- a/drivers/gpu/drm/drm_rect.c
+++ b/drivers/gpu/drm/drm_rect.c
@@ -293,3 +293,143 @@ void drm_rect_debug_print(const struct drm_rect *r, bool 
fixed_point)
DRM_DEBUG_KMS(%dx%d%+d%+d\n, w, h, r-x1, r-y1);
 }
 EXPORT_SYMBOL(drm_rect_debug_print);
+
+/**
+ * drm_rect_rotate - Rotate the rectangle
+ * @r: rectangle to be rotated
+ * @width: Width of the coordinate space
+ * @height: Height of the coordinate space
+ * @rotation: Transformation to be applied
+ *
+ * Apply @rotation to the coordinates of rectangle @r.
+ *
+ * @width and @height combined with @rotation define
+ * the location of the new origin.
+ *
+ * @width correcsponds to the horizontal and @height
+ * to the vertical axis of the untransformed coordinate
+ * space.
+ */
+void drm_rect_rotate(struct drm_rect *r,
+int width, int height,
+unsigned int rotation)
+{
+   struct drm_rect tmp;
+
+   if (rotation  (BIT(DRM_REFLECT_X) | BIT(DRM_REFLECT_Y))) {
+   tmp = *r;
+
+   if (rotation  BIT(DRM_REFLECT_X)) {
+   r-x1 = width - tmp.x2;
+   r-x2 = width - tmp.x1;
+   }
+
+   if (rotation  BIT(DRM_REFLECT_Y)) {
+   r-y1 = height - tmp.y2;
+   r-y2 = height - tmp.y1;
+   }
+   }
+
+   switch (rotation  0xf) {
+   case BIT(DRM_ROTATE_0):
+   break;
+   case BIT(DRM_ROTATE_90):
+   tmp = *r;
+   r-x1 = tmp.y1;
+   r-x2 = tmp.y2;
+   r-y1 = width - tmp.x2;
+   r-y2 = width - tmp.x1;
+   break;
+   case BIT(DRM_ROTATE_180):
+   tmp = *r;
+   r-x1 = width - tmp.x2;
+   r-x2 = width - tmp.x1;
+   r-y1 = height - tmp.y2;
+   r-y2 = height - tmp.y1;
+   break;
+   case BIT(DRM_ROTATE_270):
+   tmp = *r;
+   r-x1 = height - tmp.y2;
+   r-x2 = height - tmp.y1;
+   r-y1 = tmp.x1;
+   r-y2 = tmp.x2;
+   break;
+   default:
+   break;
+   }
+}
+EXPORT_SYMBOL(drm_rect_rotate);
+
+/**
+ * drm_rect_rotate_inv - Inverse rotate the rectangle
+ * @r: rectangle to be rotated
+ * @width: Width of the coordinate space
+ * @height: Height of the coordinate space
+ * @rotation: Transformation whose inverse is to be applied
+ *
+ * Apply the inverse of @rotation to the coordinates
+ * of rectangle @r.
+ *
+ * @width and @height combined with @rotation define
+ * the location of the new origin.
+ *
+ * @width correcsponds to the horizontal and @height
+ * to the vertical axis of the original untransformed
+ * coordinate space, so that you never have to flip
+ * them when doing a rotatation and its inverse.
+ * That is, if you do:
+ *
+ * drm_rotate(r, width, height, rotation);
+ * drm_rotate_inv(r, width, height, rotation);
+ *
+ * you will always get back the original rectangle.
+ */
+void drm_rect_rotate_inv(struct drm_rect *r,
+int width, int height,
+unsigned int rotation)
+{
+   struct drm_rect tmp;
+
+   switch (rotation  0xf) {
+   case BIT(DRM_ROTATE_0):
+   break;
+   case BIT(DRM_ROTATE_90):
+   tmp = *r;
+   r-x1 = width - tmp.y2;
+   r-x2 = width - tmp.y1;
+   r-y1 = tmp.x1;
+   r-y2 = tmp.x2;
+   break;
+   case BIT(DRM_ROTATE_180):
+   tmp = *r;
+   r-x1 = width - tmp.x2;
+   r-x2 = width - tmp.x1;
+   r-y1 = height - tmp.y2;
+   r-y2 = height - tmp.y1;
+   break;
+   case BIT(DRM_ROTATE_270):
+   tmp = *r;
+   r-x1 = tmp.y1;
+   r-x2 = tmp.y2;
+   r-y1 = height - tmp.x2;
+   r-y2 = height - tmp.x1;
+   break;
+   default:
+   break;
+   }
+
+   if (rotation  (BIT(DRM_REFLECT_X) | BIT(DRM_REFLECT_Y))) {
+   tmp = *r;
+
+   if (rotation  BIT(DRM_REFLECT_X)) {
+   r-x1 = width - tmp.x2;
+   r-x2 = width - tmp.x1;
+   }
+
+   if (rotation  

[Intel-gfx] [PATCH 08/10] drm/i915: Make intel_plane_restore() return an error

2014-06-18 Thread sonika . jindal
From: Ville Syrjälä ville.syrjala at linux.intel.com

Propagate the error from intel_update_plane() up through
intel_plane_restore() to the caller. This will be used for
rollback purposes when setting properties fails.

Cc: Daniel Vetter daniel.vetter at ffwll.ch
Cc: Jani Nikula jani.nikula at linux.intel.com
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Ville Syrjälä ville.syrjala at linux.intel.com
Reviewed-by: Imre Deak imre.deak at intel.com
---
 drivers/gpu/drm/i915/intel_drv.h|2 +-
 drivers/gpu/drm/i915/intel_sprite.c |   14 +++---
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 67b1c59..da5a3ca 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -993,7 +993,7 @@ bool intel_sdvo_init(struct drm_device *dev, uint32_t 
sdvo_reg, bool is_sdvob);
 int intel_plane_init(struct drm_device *dev, enum pipe pipe, int plane);
 void intel_flush_primary_plane(struct drm_i915_private *dev_priv,
   enum plane plane);
-void intel_plane_restore(struct drm_plane *plane);
+int intel_plane_restore(struct drm_plane *plane);
 void intel_plane_disable(struct drm_plane *plane);
 int intel_sprite_set_colorkey(struct drm_device *dev, void *data,
  struct drm_file *file_priv);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 54d4224..cbad738 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1202,18 +1202,18 @@ out_unlock:
return ret;
 }
 
-void intel_plane_restore(struct drm_plane *plane)
+int intel_plane_restore(struct drm_plane *plane)
 {
struct intel_plane *intel_plane = to_intel_plane(plane);
 
if (!plane-crtc || !plane-fb)
-   return;
+   return 0;
 
-   intel_update_plane(plane, plane-crtc, plane-fb,
-  intel_plane-crtc_x, intel_plane-crtc_y,
-  intel_plane-crtc_w, intel_plane-crtc_h,
-  intel_plane-src_x, intel_plane-src_y,
-  intel_plane-src_w, intel_plane-src_h);
+   return intel_update_plane(plane, plane-crtc, plane-fb,
+ intel_plane-crtc_x, intel_plane-crtc_y,
+ intel_plane-crtc_w, intel_plane-crtc_h,
+ intel_plane-src_x, intel_plane-src_y,
+ intel_plane-src_w, intel_plane-src_h);
 }
 
 void intel_plane_disable(struct drm_plane *plane)
-- 
1.7.10.4

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


[Intel-gfx] [PATCH 04/10] drm/omap: Switch omapdrm over to drm_mode_create_rotation_property()

2014-06-18 Thread sonika . jindal
From: Ville Syrjälä ville.syrjala at linux.intel.com

Use the new drm_mode_create_rotation_property() in omapdrm.

Cc: Rob Clark robdclark at gmail.com
Cc: Sagar Kamble sagar.a.kamble at intel.com
Cc: Ville Syrjälä ville.syrjala at linux.intel.com
Cc: Tomi Valkeinen tomi.valkeinen at ti.com
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Ville Syrjälä ville.syrjala at linux.intel.com
Reviewed-by: Rob Clark robdclark at gmail.com
Reviewed-by: Imre Deak imre.deak at intel.com
Reviewed-by: Sagar Kamble sagar.a.kam...@intel.com
---
 drivers/gpu/drm/omapdrm/omap_plane.c |   20 +++-
 1 file changed, 7 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
b/drivers/gpu/drm/omapdrm/omap_plane.c
index aff06e7..da9d15d 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -308,19 +308,13 @@ void omap_plane_install_properties(struct drm_plane 
*plane,
if (priv-has_dmm) {
prop = priv-rotation_prop;
if (!prop) {
-   const struct drm_prop_enum_list props[] = {
-   { DRM_ROTATE_0,   rotate-0 },
-   { DRM_ROTATE_90,  rotate-90 },
-   { DRM_ROTATE_180, rotate-180 },
-   { DRM_ROTATE_270, rotate-270 },
-   { DRM_REFLECT_X,  reflect-x },
-   { DRM_REFLECT_Y,  reflect-y },
-   };
-   prop = drm_property_create_bitmask(dev, 0, rotation,
-   props, ARRAY_SIZE(props),
-   BIT(DRM_ROTATE_0) | BIT(DRM_ROTATE_90) |
-   BIT(DRM_ROTATE_180) | 
BIT(DRM_ROTATE_270) |
-   BIT(DRM_REFLECT_X) | 
BIT(DRM_REFLECT_Y));
+   prop = drm_mode_create_rotation_property(dev,
+
BIT(DRM_ROTATE_0) |
+
BIT(DRM_ROTATE_90) |
+
BIT(DRM_ROTATE_180) |
+
BIT(DRM_ROTATE_270) |
+
BIT(DRM_REFLECT_X) |
+
BIT(DRM_REFLECT_Y));
if (prop == NULL)
return;
priv-rotation_prop = prop;
-- 
1.7.10.4

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


[Intel-gfx] [PATCH 01/10] drm: Move DRM_ROTATE bits out of omapdrm into drm_crtc.h

2014-06-18 Thread sonika . jindal
From: Ville Syrjälä ville.syrjala at linux.intel.com

The rotation property stuff should be standardized among all drivers.
Move the bits to drm_crtc.h from omap_drv.h.

Signed-off-by: Ville Syrjälä ville.syrjala at linux.intel.com
Reviewed-by: Imre Deak imre.deak at intel.com
---
 drivers/gpu/drm/omapdrm/omap_drv.h |7 ---
 include/drm/drm_crtc.h |8 
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h 
b/drivers/gpu/drm/omapdrm/omap_drv.h
index 284b80f..b08a450 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/gpu/drm/omapdrm/omap_drv.h
@@ -119,13 +119,6 @@ struct omap_drm_private {
struct omap_drm_irq error_handler;
 };
 
-/* this should probably be in drm-core to standardize amongst drivers */
-#define DRM_ROTATE_0   0
-#define DRM_ROTATE_90  1
-#define DRM_ROTATE_180 2
-#define DRM_ROTATE_270 3
-#define DRM_REFLECT_X  4
-#define DRM_REFLECT_Y  5
 
 #ifdef CONFIG_DEBUG_FS
 int omap_debugfs_init(struct drm_minor *minor);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 4ee7e26..bfc7235 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -75,6 +75,14 @@ static inline uint64_t I642U64(int64_t val)
return (uint64_t)*((uint64_t *)val);
 }
 
+/* rotation property bits */
+#define DRM_ROTATE_0   0
+#define DRM_ROTATE_90  1
+#define DRM_ROTATE_180 2
+#define DRM_ROTATE_270 3
+#define DRM_REFLECT_X  4
+#define DRM_REFLECT_Y  5
+
 enum drm_connector_force {
DRM_FORCE_UNSPECIFIED,
DRM_FORCE_OFF,
-- 
1.7.10.4

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


Re: [Intel-gfx] [PATCH 00/11] Support for 180 degree HW rotation

2014-06-18 Thread Jindal, Sonika



On 6/18/2014 4:30 PM, Damien Lespiau wrote:

On Wed, Jun 18, 2014 at 02:27:16PM +0530, sonika.jin...@intel.com wrote:

From: Sonika Jindal sonika.jin...@intel.com

Enables 180 degree rotation for sprite and primary planes.
Updated the primary plane rotation support as per the new universal plane
design.

Most of these patches were already reviewed in intel-gfx in February 2014 thats
why there is version history in few of them.

Testcase: kms_rotation_crc
This igt can be extended for clipped rotation cases. Right it only tests 180
degree rotation for sprite and primary plane with crc check.

Sonika Jindal (2):
   tests/kms_rotation_crc: IGT for 180 degree HW rotation
   drm/i915: Add 180 degree primary plane rotation support

Ville Syrjälä (9):
   drm: Move DRM_ROTATE bits out of omapdrm into drm_crtc.h
   drm: Add support_bits parameter to drm_property_create_bitmask()
   drm: Add drm_mode_create_rotation_property()
   drm/omap: Switch omapdrm over to drm_mode_create_rotation_property()
   drm: Add drm_rect rotation functions
   drm: Add drm_rotation_simplify()
   drm/i915: Add 180 degree sprite rotation support
   drm/i915: Make intel_plane_restore() return an error
   drm/i915: Add rotation property for sprites


Now that we have universal planes, I guess the last blocker for this
series is gone. Thanks for keeping at it.

Some of these patches already had review tags. Would you mind:

   - Re-add the r-b tags already gathered,
   - Remove Greg KH from the Cc. list, let's not bother him with that
   - Remove Dave Airlie from the Cc. list, dri-devel is enough (+ us
 pinging him about the series if necessary)
   - Don't resend the igt patch with the kernel ones,
   - Add a patch on top to update the big property table
 Documentation/DocBook/drm.tmpl - let's make sure we don't upstream
 new properties without updating that list


Thanks Damien,
I have updated the patches with r-b tags.
I will update the documentation and post the patch shortly.

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


Re: [Intel-gfx] [PATCH 00/10] Support for 180 degree HW rotation

2014-06-18 Thread Daniel Vetter
On Wed, Jun 18, 2014 at 05:14:49PM +0530, sonika.jin...@intel.com wrote:
 From: Sonika Jindal sonika.jin...@intel.com
 
 Enables 180 degree rotation for sprite and primary planes.
 Updated the primary plane rotation support as per the new universal plane
 design.
 
 Most of these patches were already reviewed in intel-gfx in February 2014 
 thats
 why there is version history in few of them.
 
 Testcase: kms_rotation_crc
 This igt can be extended for clipped rotation cases. Right it only tests 180
 degree rotation for sprite and primary plane with crc check.
 
 Sonika Jindal (1):
   drm/i915: Add 180 degree primary plane rotation support
 
 Ville Syrjälä (9):
   drm: Move DRM_ROTATE bits out of omapdrm into drm_crtc.h
   drm: Add support_bits parameter to drm_property_create_bitmask()
   drm: Add drm_mode_create_rotation_property()
   drm/omap: Switch omapdrm over to drm_mode_create_rotation_property()
   drm: Add drm_rect rotation functions
   drm: Add drm_rotation_simplify()
   drm/i915: Add 180 degree sprite rotation support
   drm/i915: Make intel_plane_restore() return an error
   drm/i915: Add rotation property for sprites

Pleas don't repost entire patch series on the same day without a changelog
in the cover letter explaining what's going on and what changed.

If you just need to repost a few patches that changed due to review,
please do that with an in-reply-to directly to the relevant discussion.

If everyone reposts their big patch series a few times a day we'll have
utter chaos.
-Daniel

 
  drivers/gpu/drm/drm_crtc.c   |   66 +++-
  drivers/gpu/drm/drm_rect.c   |  140 
 ++
  drivers/gpu/drm/i915/i915_dma.c  |   17 +
  drivers/gpu/drm/i915/i915_drv.h  |1 +
  drivers/gpu/drm/i915/i915_reg.h  |4 +
  drivers/gpu/drm/i915/intel_display.c |   91 +-
  drivers/gpu/drm/i915/intel_drv.h |3 +-
  drivers/gpu/drm/i915/intel_pm.c  |8 ++
  drivers/gpu/drm/i915/intel_sprite.c  |   93 --
  drivers/gpu/drm/omapdrm/omap_drv.h   |7 --
  drivers/gpu/drm/omapdrm/omap_plane.c |   17 ++---
  include/drm/drm_crtc.h   |   15 +++-
  include/drm/drm_rect.h   |6 ++
  13 files changed, 433 insertions(+), 35 deletions(-)
 
 -- 
 1.7.10.4
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


Re: [Intel-gfx] [PATCH 09/11] drm/i915: Add rotation property for sprites

2014-06-18 Thread Jindal, Sonika



On 6/18/2014 4:42 PM, Damien Lespiau wrote:

On Wed, Jun 18, 2014 at 02:27:25PM +0530, sonika.jin...@intel.com wrote:

From: Ville Syrjälä ville.syrjala at linux.intel.com

Sprite planes support 180 degree rotation. The lower layers are now in
place, so hook in the standard rotation property to expose the feature
to the users.

Cc: Daniel Vetter daniel.vetter at ffwll.ch
Cc: Jani Nikula jani.nikula at linux.intel.com
Cc: David Airlie airlied at linux.ie
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Ville Syrjälä ville.syrjala at linux.intel.com
---
  drivers/gpu/drm/i915/i915_drv.h |1 +
  drivers/gpu/drm/i915/intel_sprite.c |   42 ++-
  2 files changed, 42 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0640071..b56a1a5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1514,6 +1514,7 @@ struct drm_i915_private {

struct drm_property *broadcast_rgb_property;
struct drm_property *force_audio_property;
+   struct drm_property *rotation_property;

uint32_t hw_context_size;
struct list_head context_list;
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index cbad738..b9af256 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1202,6 +1202,30 @@ out_unlock:
return ret;
  }

+static int intel_plane_set_property(struct drm_plane *plane,
+   struct drm_property *prop,
+   uint64_t val)
+{
+   struct drm_i915_private *dev_priv = plane-dev-dev_private;
+   struct intel_plane *intel_plane = to_intel_plane(plane);
+   uint64_t old_val;
+   int ret = -ENOENT;
+
+   if (prop == dev_priv-rotation_property) {


Shouldn't we add a:

if (val  (BIT(DRM_ROTATE_0) | BIT(DRM_ROTATE_180)))
return -EINVAL;

To ensure userspace doesn't send garbage in the upper bits so we can
reuse them down the road?


But we are checking if more than one bit is set, we return EINVAL.
So we only care for one rotation angle being sent from user.
Shouldn't that suffice?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 00/11] Support for 180 degree HW rotation

2014-06-18 Thread Ville Syrjälä
On Wed, Jun 18, 2014 at 12:21:39PM +0100, Chris Wilson wrote:
 On Wed, Jun 18, 2014 at 12:12:31PM +0100, Damien Lespiau wrote:
  On Wed, Jun 18, 2014 at 12:07:17PM +0100, Chris Wilson wrote:
Now that we have universal planes, I guess the last blocker for this
series is gone. Thanks for keeping at it.
   
   Hah. We were last arguing over the property names.
  
  But only because the property was on the CRTC and rotation (or
  primary-rotation) ended up in limbo? The property is now on the
  (primary) plane object.
 
 Ville also had plans for a superproperty called rotation on the CRTC
 that would adjust all planes. Not quite sure what his final plans were.

I just liked it because it was so easy to hook in at the kernel level,
and it made it possible to test rotation without having support for it
in the ddx. But I don't mind if we just drop it for now. We can revisit
later if there's a real use case for it.

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


Re: [Intel-gfx] [PATCH 00/10] Support for 180 degree HW rotation

2014-06-18 Thread Jindal, Sonika



On 6/18/2014 5:22 PM, Daniel Vetter wrote:

On Wed, Jun 18, 2014 at 05:14:49PM +0530, sonika.jin...@intel.com wrote:

From: Sonika Jindal sonika.jin...@intel.com

Enables 180 degree rotation for sprite and primary planes.
Updated the primary plane rotation support as per the new universal plane
design.

Most of these patches were already reviewed in intel-gfx in February 2014 thats
why there is version history in few of them.

Testcase: kms_rotation_crc
This igt can be extended for clipped rotation cases. Right it only tests 180
degree rotation for sprite and primary plane with crc check.

Sonika Jindal (1):
   drm/i915: Add 180 degree primary plane rotation support

Ville Syrjälä (9):
   drm: Move DRM_ROTATE bits out of omapdrm into drm_crtc.h
   drm: Add support_bits parameter to drm_property_create_bitmask()
   drm: Add drm_mode_create_rotation_property()
   drm/omap: Switch omapdrm over to drm_mode_create_rotation_property()
   drm: Add drm_rect rotation functions
   drm: Add drm_rotation_simplify()
   drm/i915: Add 180 degree sprite rotation support
   drm/i915: Make intel_plane_restore() return an error
   drm/i915: Add rotation property for sprites


Pleas don't repost entire patch series on the same day without a changelog
in the cover letter explaining what's going on and what changed.

If you just need to repost a few patches that changed due to review,
please do that with an in-reply-to directly to the relevant discussion.

If everyone reposts their big patch series a few times a day we'll have
utter chaos.
-Daniel


I am sorry for this. I thought creating a new patchset should be good, 
missed updating it in cover letter.

I will keep this in mind.






  drivers/gpu/drm/drm_crtc.c   |   66 +++-
  drivers/gpu/drm/drm_rect.c   |  140 ++
  drivers/gpu/drm/i915/i915_dma.c  |   17 +
  drivers/gpu/drm/i915/i915_drv.h  |1 +
  drivers/gpu/drm/i915/i915_reg.h  |4 +
  drivers/gpu/drm/i915/intel_display.c |   91 +-
  drivers/gpu/drm/i915/intel_drv.h |3 +-
  drivers/gpu/drm/i915/intel_pm.c  |8 ++
  drivers/gpu/drm/i915/intel_sprite.c  |   93 --
  drivers/gpu/drm/omapdrm/omap_drv.h   |7 --
  drivers/gpu/drm/omapdrm/omap_plane.c |   17 ++---
  include/drm/drm_crtc.h   |   15 +++-
  include/drm/drm_rect.h   |6 ++
  13 files changed, 433 insertions(+), 35 deletions(-)

--
1.7.10.4

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



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


[Intel-gfx] [PATCH 06/16] drm/i915: Track the psr dp connector in dev_priv-psr.enabled

2014-06-18 Thread Daniel Vetter
Trying to fish that one out through looping is a bit a locking
nightmare. So just set it and use it in the work struct.

v2:
- Don't Oops in psr_work, spotted by Rodrigo.
- Fix compile warning.

Cc: Rodrigo Vivi rodrigo.v...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_debugfs.c |  2 +-
 drivers/gpu/drm/i915/i915_drv.h |  3 ++-
 drivers/gpu/drm/i915/intel_dp.c | 22 +-
 3 files changed, 12 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 8057fd4fc86c..4818aff9e6d6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1973,7 +1973,7 @@ static int i915_edp_psr_status(struct seq_file *m, void 
*data)
 
seq_printf(m, Sink_Support: %s\n, yesno(dev_priv-psr.sink_support));
seq_printf(m, Source_OK: %s\n, yesno(dev_priv-psr.source_ok));
-   seq_printf(m, Enabled: %s\n, yesno(dev_priv-psr.enabled));
+   seq_printf(m, Enabled: %s\n, yesno((bool)dev_priv-psr.enabled));
seq_printf(m, Active: %s\n, yesno(dev_priv-psr.active));
 
enabled = HAS_PSR(dev) 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 877c3e0de12e..740a0d95b89a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -633,10 +633,11 @@ struct i915_drrs {
struct intel_connector *connector;
 };
 
+struct intel_dp;
 struct i915_psr {
bool sink_support;
bool source_ok;
-   bool enabled;
+   struct intel_dp *enabled;
bool active;
struct delayed_work work;
 };
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 84fe5a75f8b2..00ddcaf82ae1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1826,7 +1826,7 @@ static void intel_edp_psr_do_enable(struct intel_dp 
*intel_dp)
/* Enable PSR on the host */
intel_edp_psr_enable_source(intel_dp);
 
-   dev_priv-psr.enabled = true;
+   dev_priv-psr.enabled = intel_dp;
dev_priv-psr.active = true;
 }
 
@@ -1867,26 +1867,22 @@ void intel_edp_psr_disable(struct intel_dp *intel_dp)
   EDP_PSR_STATUS_STATE_MASK) == 0, 2000, 10))
DRM_ERROR(Timed out waiting for PSR Idle State\n);
 
-   dev_priv-psr.enabled = false;
+   dev_priv-psr.enabled = NULL;
 }
 
 static void intel_edp_psr_work(struct work_struct *work)
 {
struct drm_i915_private *dev_priv =
container_of(work, typeof(*dev_priv), psr.work.work);
-   struct drm_device *dev = dev_priv-dev;
-   struct intel_encoder *encoder;
-   struct intel_dp *intel_dp = NULL;
+   struct intel_dp *intel_dp = dev_priv-psr.enabled;
 
-   list_for_each_entry(encoder, dev-mode_config.encoder_list, base.head)
-   if (encoder-type == INTEL_OUTPUT_EDP) {
-   intel_dp = enc_to_intel_dp(encoder-base);
+   if (!intel_dp)
+   return;
 
-   if (!intel_edp_psr_match_conditions(intel_dp))
-   intel_edp_psr_disable(intel_dp);
-   else
-   intel_edp_psr_do_enable(intel_dp);
-   }
+   if (!intel_edp_psr_match_conditions(intel_dp))
+   intel_edp_psr_disable(intel_dp);
+   else
+   intel_edp_psr_do_enable(intel_dp);
 }
 
 static void intel_edp_psr_inactivate(struct drm_device *dev)
-- 
2.0.0

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


[Intel-gfx] [PATCH 09/16] drm/i915: More checks for psr.enabled

2014-06-18 Thread Daniel Vetter
We need to make sure that no one else is using this in the
enable function and also that the work item hasn't raced
with the disabled function.

v2: Improve bisectability by moving one hunk to an earlier patch.

Cc: Rodrigo Vivi rodrigo.v...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 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 910f73de3a92..870219ff1187 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1844,6 +1844,11 @@ void intel_edp_psr_enable(struct intel_dp *intel_dp)
return;
}
 
+   if (dev_priv-psr.enabled) {
+   DRM_DEBUG_KMS(PSR already in use\n);
+   return;
+   }
+
/* Setup PSR once */
intel_edp_psr_setup(intel_dp);
 
-- 
2.0.0

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


[Intel-gfx] [PATCH 07/16] drm/i915: Don't try to disable psr harder from the work item

2014-06-18 Thread Daniel Vetter
It's disabled already except when we've raced.

Cc: Rodrigo Vivi rodrigo.v...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/intel_dp.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 00ddcaf82ae1..a2f39055fbb1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1879,9 +1879,7 @@ static void intel_edp_psr_work(struct work_struct *work)
if (!intel_dp)
return;
 
-   if (!intel_edp_psr_match_conditions(intel_dp))
-   intel_edp_psr_disable(intel_dp);
-   else
+   if (intel_edp_psr_match_conditions(intel_dp))
intel_edp_psr_do_enable(intel_dp);
 }
 
-- 
2.0.0

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


[Intel-gfx] [PATCH 12/16] drm/i915: Use new frontbuffer bits to increase pll clock

2014-06-18 Thread Daniel Vetter
The downclocking checks a few more things, so not that simple to
convert. Also, this should get unified with the drrs handling and also
use the locking of that. Otoh the drrs locking is about as hapzardous
as no locking, at least on first sight.

For easier conversion ditch the upclocking on unload - we'll turn off
everything anyway.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 ++
 drivers/gpu/drm/i915/intel_display.c | 32 ++--
 2 files changed, 12 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2ae2b96c371d..dcd8fd956ec7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1614,6 +1614,8 @@ struct drm_i915_gem_object_ops {
(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)))
 
 struct drm_i915_gem_object {
struct drm_gem_object base;
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 87d3be939488..e6a387169af2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -76,7 +76,8 @@ static const uint32_t intel_cursor_formats[] = {
 #define DIV_ROUND_CLOSEST_ULL(ll, d)   \
 ({ unsigned long long _tmp = (ll)+(d)/2; do_div(_tmp, d); _tmp; })
 
-static void intel_increase_pllclock(struct drm_crtc *crtc);
+static void intel_increase_pllclock(struct drm_device *dev,
+   enum pipe pipe);
 static void intel_crtc_update_cursor(struct drm_crtc *crtc, bool on);
 
 static void i9xx_crtc_clock_get(struct intel_crtc *crtc,
@@ -2585,7 +2586,7 @@ intel_pipe_set_base_atomic(struct drm_crtc *crtc, struct 
drm_framebuffer *fb,
 
if (dev_priv-display.disable_fbc)
dev_priv-display.disable_fbc(dev);
-   intel_increase_pllclock(crtc);
+   intel_increase_pllclock(dev, to_intel_crtc(crtc)-pipe);
 
dev_priv-display.update_primary_plane(crtc, fb, x, y);
 
@@ -8720,12 +8721,10 @@ struct drm_display_mode *intel_crtc_mode_get(struct 
drm_device *dev,
return mode;
 }
 
-static void intel_increase_pllclock(struct drm_crtc *crtc)
+static void intel_increase_pllclock(struct drm_device *dev,
+   enum pipe pipe)
 {
-   struct drm_device *dev = crtc-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   int pipe = intel_crtc-pipe;
int dpll_reg = DPLL(pipe);
int dpll;
 
@@ -8831,21 +8830,19 @@ void intel_mark_fb_busy(struct drm_i915_gem_object *obj,
struct intel_engine_cs *ring)
 {
struct drm_device *dev = obj-base.dev;
-   struct drm_crtc *crtc;
+   enum pipe pipe;
 
intel_edp_psr_exit(dev);
 
if (!i915.powersave)
return;
 
-   for_each_crtc(dev, crtc) {
-   if (!crtc-primary-fb)
-   continue;
-
-   if (to_intel_framebuffer(crtc-primary-fb)-obj != obj)
+   for_each_pipe(pipe) {
+   if (!(obj-frontbuffer_bits 
+ INTEL_FRONTBUFFER_ALL_MASK(pipe)))
continue;
 
-   intel_increase_pllclock(crtc);
+   intel_increase_pllclock(dev, pipe);
if (ring  intel_fbc_enabled(dev))
ring-fbc_dirty = true;
}
@@ -12801,7 +12798,6 @@ void intel_connector_unregister(struct intel_connector 
*intel_connector)
 void intel_modeset_cleanup(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
-   struct drm_crtc *crtc;
struct drm_connector *connector;
 
/*
@@ -12821,14 +12817,6 @@ void intel_modeset_cleanup(struct drm_device *dev)
 
intel_unregister_dsm_handler();
 
-   for_each_crtc(dev, crtc) {
-   /* Skip inactive CRTCs */
-   if (!crtc-primary-fb)
-   continue;
-
-   intel_increase_pllclock(crtc);
-   }
-
intel_disable_fbc(dev);
 
intel_disable_gt_powersave(dev);
-- 
2.0.0

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


[Intel-gfx] [PATCH 00/16] PSR rework and accurate frontbuffer tracking

2014-06-18 Thread Daniel Vetter
Hi all,

Lots of changes since the first time around:
- Piles of bugfixes all over to make the psr stuff actually work.
- Bugfixes in the frontbuffer tracking (I've undersized one bitfield by
  accident, so didn't work on more than one pipe).
- Polished function names and interface semantics for the frontbuffer tracking
  events.
- Some patch splitting and reorg.
- Comments for tricky stuff.
- Improved debugfs data, dumping the new fields.
- Polish all over.

Rodrigo also tested this a bit and we've noticed that the current psr test gets
a few things wrong, so needs improvement. Testing BYT psr is also still pending,
I'd like to have that confirmation before merging.

But otherwise this seems to actually work somewhat.

Another thing I'm thinking about is extracting the frontbuffer handling into a
new file (intel_frontbuffer.c or anyone have a better name) and integrate the
new kerneldoc plus add a short overview section. We could even move some of the
power saving code (psr fits better in intel_dp.c I think, but fbc maybe) in
there, together with the documentation.

Comments  feedback highly welcome.

Rodrigo is signed up to review the entire pile, but for the frontbuffer tracking
I really want ChrisVille to chime in and ack it, too.

Cheers, Daniel

Daniel Vetter (16):
  drm/i915: Drop unecessary complexity from psr_inactivate
  drm/i915: Ditch intel_edp_psr_update
  drm/i915: Run psr_setup unconditionally
  drm/i915: Drop schedule_back from psr_exit
  drm/i915: Add a FIXME about drrs/psr interactions
  drm/i915: Track the psr dp connector in dev_priv-psr.enabled
  drm/i915: Don't try to disable psr harder from the work item
  drm/i915: Lock down psr sw/hw state tracking
  drm/i915: More checks for psr.enabled
  drm/i915: Add locking to psr code
  drm/i915: Introduce accurate frontbuffer tracking
  drm/i915: Use new frontbuffer bits to increase pll clock
  drm/i915: Properly track domain of the fbcon fb
  drm/i915: Track frontbuffer invalidation/flushing
  drm/i915: Fix up PSR frontbuffer tracking
  drm/i915: Improve PSR debugfs output

 drivers/gpu/drm/i915/i915_debugfs.c|   8 +-
 drivers/gpu/drm/i915/i915_drv.h|  48 -
 drivers/gpu/drm/i915/i915_gem.c|  37 +++-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |   6 +-
 drivers/gpu/drm/i915/intel_display.c   | 285 +++--
 drivers/gpu/drm/i915/intel_dp.c| 210 +++--
 drivers/gpu/drm/i915/intel_drv.h   |  35 +++-
 drivers/gpu/drm/i915/intel_fbdev.c |  21 ++-
 drivers/gpu/drm/i915/intel_overlay.c   |  14 ++
 drivers/gpu/drm/i915/intel_sprite.c|  11 +-
 10 files changed, 510 insertions(+), 165 deletions(-)

-- 
2.0.0

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


[Intel-gfx] [PATCH 05/16] drm/i915: Add a FIXME about drrs/psr interactions

2014-06-18 Thread Daniel Vetter
Can't review this right now due to lack of DRRS code.

Cc: Rodrigo Vivi rodrigo.v...@intel.com
Cc: Vandana Kannan vandana.kan...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 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 0d1efdbb4636..84fe5a75f8b2 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4071,6 +4071,11 @@ void intel_dp_set_drrs_state(struct drm_device *dev, int 
refresh_rate)
return;
}
 
+   /*
+* FIXME: This needs proper synchronization with psr state. But really
+* hard to tell without seeing the user of this function of this code.
+* Check locking and ordering once that lands.
+*/
if (INTEL_INFO(dev)-gen  8  intel_edp_is_psr_enabled(dev)) {
DRM_DEBUG_KMS(DRRS is disabled as PSR is enabled\n);
return;
-- 
2.0.0

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


[Intel-gfx] [PATCH 03/16] drm/i915: Run psr_setup unconditionally

2014-06-18 Thread Daniel Vetter
Due to runtime pm and system s/r we need to restore hw state every
time we enable a pipe again. Hence trying to avoid that is just
pointless book-keeping which Rodrigo then tried to work around by
manually adding psr_setup calls to our resume code.

Much simpler to just remove code instead.

v2: Properly bail out of psr exit if psr isn't enabled. Spotted by
Rodrigo.

Cc: Rodrigo Vivi rodrigo.v...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_drv.h | 1 -
 drivers/gpu/drm/i915/intel_dp.c | 7 +--
 2 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0640071e30a9..877c3e0de12e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -636,7 +636,6 @@ struct i915_drrs {
 struct i915_psr {
bool sink_support;
bool source_ok;
-   bool setup_done;
bool enabled;
bool active;
struct delayed_work work;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b373b895fe48..420939fdb31d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1663,9 +1663,6 @@ static void intel_edp_psr_setup(struct intel_dp *intel_dp)
struct drm_i915_private *dev_priv = dev-dev_private;
struct edp_vsc_psr psr_vsc;
 
-   if (dev_priv-psr.setup_done)
-   return;
-
/* Prepare VSC packet as per EDP 1.3 spec, Table 3.10 */
memset(psr_vsc, 0, sizeof(psr_vsc));
psr_vsc.sdp_header.HB0 = 0;
@@ -1677,8 +1674,6 @@ static void intel_edp_psr_setup(struct intel_dp *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);
-
-   dev_priv-psr.setup_done = true;
 }
 
 static void intel_edp_psr_enable_sink(struct intel_dp *intel_dp)
@@ -1911,7 +1906,7 @@ void intel_edp_psr_exit(struct drm_device *dev, bool 
schedule_back)
if (!HAS_PSR(dev))
return;
 
-   if (!dev_priv-psr.setup_done)
+   if (!dev_priv-psr.enabled)
return;
 
cancel_delayed_work_sync(dev_priv-psr.work);
-- 
2.0.0

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


[Intel-gfx] [PATCH 15/16] drm/i915: Fix up PSR frontbuffer tracking

2014-06-18 Thread Daniel Vetter
I've tried to split this up, but all the changes are so tightly
related that I didn't find a good way to do this without breaking
bisecting. Essentially this completely changes how psr is glued into
the overall driver, and there's not much you can do to soften such a
paradigm change.

- Use frontbuffer tracking bits stuff to separate disable and
  re-enable.

- Don't re-check everything in the psr work. We have now accurate
  tracking for everything, so no need to check for sprites or tiling
  really. Allows us to ditch tons of locks.

- That in turn allows us to properly cancel the work in the disable
  function - no more deadlocks.

- Add a check for HSW sprites and force a flush. Apparently the
  hardware doesn't forward the flushing when updating the sprite base
  address. We can do the same trick everywhere else we have such
  issues, e.g. on baytrail with ... everything.

- Don't re-enable psr with a delay in psr_exit. It really must be
  turned off forever if we detect a gtt write. At least with the
  current frontbuffer render tracking. Userspace can do a busy ioctl
  call or no-op pageflip to re-enable psr.

- Drop redundant checks for crtc and crtc-active - now that they're
  only called from enable this is guaranteed.

- Fix up the hsw port check. eDP can also happen on port D, but the
  issue is exactly that it doesn't work there. So an || check is
  wrong.

- We still schedule the psr work with a delay. The frontbuffer
  flushing interface mandates that we upload the next full frame, so
  need to wait a bit. Once we have single-shot frame uploads we can do
  better here.

v2: Don't enable psr initially, rely upon the fb flush of the initial
plane setup for that. Gives us more unified code flow and makes the
crtc enable sequence less a special case.

v3: s/psr_exit/psr_invalidate/ for consistency

v4: Fixup whitespace.

v5: Correctly bail out of psr_invalidate/flush when
dev_priv-psr.enabled is NULL. Spotted by Rodrigo.

v6:
- Only schedule work when there's work to do. Fixes WARNINGs reported
  by Rodrigo.
- Comments Chris requested to clarify the code.

Cc: Rodrigo Vivi rodrigo.v...@intel.com
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_drv.h  |   1 +
 drivers/gpu/drm/i915/intel_display.c |   4 +-
 drivers/gpu/drm/i915/intel_dp.c  | 125 ++-
 drivers/gpu/drm/i915/intel_drv.h |   5 +-
 4 files changed, 85 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0a309fe53911..1e52da99ca79 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -641,6 +641,7 @@ struct i915_psr {
struct intel_dp *enabled;
bool active;
struct delayed_work work;
+   unsigned busy_frontbuffer_bits;
 };
 
 enum intel_pch {
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 2361d03ea1f3..50bca2c7c3f6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8895,7 +8895,7 @@ void intel_fb_obj_invalidate(struct drm_i915_gem_object 
*obj,
 
intel_mark_fb_busy(dev, obj-frontbuffer_bits, ring);
 
-   intel_edp_psr_exit(dev);
+   intel_edp_psr_invalidate(dev, obj-frontbuffer_bits);
 }
 
 /**
@@ -8921,7 +8921,7 @@ void intel_frontbuffer_flush(struct drm_device *dev,
 
intel_mark_fb_busy(dev, frontbuffer_bits, NULL);
 
-   intel_edp_psr_exit(dev);
+   intel_edp_psr_flush(dev, frontbuffer_bits);
 }
 
 /**
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e17a85468f78..1a8b3d90e422 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1746,8 +1746,6 @@ static bool intel_edp_psr_match_conditions(struct 
intel_dp *intel_dp)
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_crtc *crtc = dig_port-base.base.crtc;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   struct drm_i915_gem_object *obj = 
to_intel_framebuffer(crtc-primary-fb)-obj;
-   struct intel_encoder *intel_encoder = dp_to_dig_port(intel_dp)-base;
 
lockdep_assert_held(dev_priv-psr.lock);
lockdep_assert_held(dev-struct_mutex);
@@ -1761,8 +1759,7 @@ static bool intel_edp_psr_match_conditions(struct 
intel_dp *intel_dp)
return false;
}
 
-   if (IS_HASWELL(dev)  (intel_encoder-type != INTEL_OUTPUT_EDP ||
-   dig_port-port != PORT_A)) {
+   if (IS_HASWELL(dev)  dig_port-port != PORT_A) {
DRM_DEBUG_KMS(HSW ties PSR to DDI A (eDP)\n);
return false;
}
@@ -1772,34 +1769,10 @@ static bool intel_edp_psr_match_conditions(struct 
intel_dp *intel_dp)
return false;
}
 
-   crtc = dig_port-base.base.crtc;
-   if (crtc == NULL) {
-   DRM_DEBUG_KMS(crtc not 

[Intel-gfx] [PATCH 11/16] drm/i915: Introduce accurate frontbuffer tracking

2014-06-18 Thread Daniel Vetter
So from just a quick look we seem to have enough information to
accurately figure out whether a given gem bo is used as a frontbuffer
and where exactly: We have obj-pin_count as a first check with no
false negatives and only negligible false positives. And then we can
just walk the modeset objects and figure out where exactly a buffer is
used as scanout.

Except that we can't due to locking order: If we already hold
dev-struct_mutex we can't acquire any modeset locks, so could
potential chase freed pointers and other evil stuff.

So we need something else. For that introduce a new set of bits
obj-frontbuffer_bits to track where a buffer object is used. That we
can then chase without grabbing any modeset locks.

Of course the consumers of this (DRRS, PSR, FBC, ...) still need to be
able to do their magic both when called from modeset and from gem
code. But that can be easily achieved by adding locks for these
specific subsystems which always nest within either kms or gem
locking.

This patch just adds the relevant update code to all places.

Note that if we ever support multi-planar scanout targets then we need
one frontbuffer tracking bit per attachment point that we expose to
userspace.

v2:
- Fix more oopsen. Oops.
- WARN if we leak obj-frontbuffer_bits when freeing a gem buffer. Fix
  the bugs this brought to light.
- s/update_frontbuffer_bits/update_fb_bits/. More consistent with the
  fb tracking functions (fb for gem object, frontbuffer for raw bits).
  And the function name was way too long.

v3: Size obj-frontbuffer_bits correctly so that all pipes fit in.

Cc: Rodrigo Vivi rodrigo.v...@intel.com
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_drv.h  | 26 +
 drivers/gpu/drm/i915/i915_gem.c  | 19 ++
 drivers/gpu/drm/i915/intel_display.c | 72 +++-
 drivers/gpu/drm/i915/intel_overlay.c | 11 ++
 drivers/gpu/drm/i915/intel_sprite.c  |  7 
 5 files changed, 118 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b6195ea334e6..2ae2b96c371d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1595,6 +1595,26 @@ struct drm_i915_gem_object_ops {
void (*release)(struct drm_i915_gem_object *);
 };
 
+/*
+ * Frontbuffer tracking bits. Set in obj-frontbuffer_bits while a gem bo is
+ * considered to be the frontbuffer for the given plane interface-vise. This
+ * doesn't mean that the hw necessarily already scans it out, but that any
+ * rendering (by the cpu or gpu) will land in the frontbuffer eventually.
+ *
+ * We have one bit per pipe and per scanout plane type.
+ */
+#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
+
 struct drm_i915_gem_object {
struct drm_gem_object base;
 
@@ -1682,6 +1702,8 @@ struct drm_i915_gem_object {
unsigned int has_global_gtt_mapping:1;
unsigned int has_dma_mapping:1;
 
+   unsigned int frontbuffer_bits:INTEL_FRONTBUFFER_BITS;
+
struct sg_table *pages;
int pages_pin_count;
 
@@ -1728,6 +1750,10 @@ struct drm_i915_gem_object {
 };
 #define to_intel_bo(x) container_of(x, struct drm_i915_gem_object, base)
 
+void i915_gem_update_fb_bits(struct drm_i915_gem_object *old,
+struct drm_i915_gem_object *new,
+unsigned frontbuffer_bits);
+
 /**
  * Request queue structure.
  *
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7d7d52bc922a..c40dd4ba2c27 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4449,6 +4449,8 @@ void i915_gem_free_object(struct drm_gem_object *gem_obj)
if (obj-stolen)
i915_gem_object_unpin_pages(obj);
 
+   WARN_ON(obj-frontbuffer_bits);
+
if (WARN_ON(obj-pages_pin_count))
obj-pages_pin_count = 0;
if (discard_backing_storage(obj))
@@ -4993,6 +4995,23 @@ int i915_gem_open(struct drm_device *dev, struct 
drm_file *file)
return ret;
 }
 
+void i915_gem_update_fb_bits(struct drm_i915_gem_object *old,
+struct drm_i915_gem_object *new,
+unsigned frontbuffer_bits)
+{
+   if (old) {
+   WARN_ON(!mutex_is_locked(old-base.dev-struct_mutex));
+   WARN_ON(!(old-frontbuffer_bits  frontbuffer_bits));
+   

[Intel-gfx] [PATCH 14/16] drm/i915: Track frontbuffer invalidation/flushing

2014-06-18 Thread Daniel Vetter
So these are the guts of the new beast. This tracks when a frontbuffer
gets invalidated (due to frontbuffer rendering) and hence should be
constantly scaned out, and when it's flushed again and can be
compressed/one-shot-upload.

Rules for flushing are simple: The frontbuffer needs one more full
upload starting from the next vblank. Which means that the flushing
can _only_ be called once the frontbuffer update has been latched.

But this poses a problem for pageflips: We can't just delay the
flushing until the pageflip is latched, since that would pose the risk
that we override frontbuffer rendering that has been scheduled
in-between the pageflip ioctl and the actual latching.

To handle this track asynchronous invalidations (and also pageflip)
state per-ring and delay any in-between flushing until the rendering
has completed. And also cancel any delayed flushing if we get a new
invalidation request (whether delayed or not).

Also call intel_mark_fb_busy in both cases in all cases to make sure
that we keep the screen at the highest refresh rate both on flips,
synchronous plane updates and for frontbuffer rendering.

v2: Lots of improvements

Suggestions from Chris:
- Move invalidate/flush in flush_*_domain and set_to_*_domain.
- Drop the flush in busy_ioctl since it's redundant. Was a leftover
  from an earlier concept to track flips/delayed flushes.
- Don't forget about the initial modeset enable/final disable.
  Suggested by Chris.

Track flips accurately, too. Since flips complete independently of
rendering we need to track pending flips in a separate mask. Again if
an invalidate happens we need to cancel the evenutal flush to avoid
races.

v3:
Provide correct header declarations for flip functions. Currently not
needed outside of intel_display.c, but part of the proper interface.

v4: Add proper domain management to fbcon so that the fbcon buffer is
also tracked correctly.

v5: Fixup locking around the fbcon set_to_gtt_domain call.

v6: More comments from Chris:
- Split out fbcon changes.
- Drop superflous checks for potential scanout before calling intel_fb
  functions - we can micro-optimize this later.
- s/intel_fb_/intel_fb_obj_/ to make it clear that this deals in gem
  object. We already have precedence for fb_obj in the pin_and_fence
  functions.

v7: Clarify the semantics of the flip flush handling by renaming
things a bit:
- Don't go through a gem object but take the relevant frontbuffer bits
  directly. These functions center on the plane, the actual object is
  irrelevant - even a flip to the same object as already active should
  cause a flush.
- Add a new intel_frontbuffer_flip for synchronous plane updates. It
  currently just calls intel_frontbuffer_flush since the implemenation
  differs.

This way we achieve a clear split between one-shot update events on
one side and frontbuffer rendering with potentially a very long delay
between the invalidate and flush.

Chris and I also had some discussions about mark_busy and whether it
is appropriate to call from flush. But mark busy is a state which
should be derived from the 3 events (invalidate, flush, flip) we now
have by the users, like psr does by tracking relevant information in
psr.busy_frontbuffer_bits. DRRS (the only real use of mark_busy for
frontbuffer) needs to have similar logic. With that the overall
mark_busy in the core could be removed.

v8: Only when retiring gpu buffers only flush frontbuffer bits we
actually invalidated in a batch. Just for safety since before any
additional usage/invalidate we should always retire current rendering.
Suggested by Chris Wilson.

Cc: Rodrigo Vivi rodrigo.v...@intel.com
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_drv.h|  14 +++
 drivers/gpu/drm/i915/i915_gem.c|  18 ++-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |   6 +-
 drivers/gpu/drm/i915/intel_display.c   | 180 +++--
 drivers/gpu/drm/i915/intel_drv.h   |  29 -
 drivers/gpu/drm/i915/intel_overlay.c   |   3 +
 drivers/gpu/drm/i915/intel_sprite.c|   4 +-
 7 files changed, 229 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dcd8fd956ec7..0a309fe53911 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1332,6 +1332,17 @@ struct intel_pipe_crc {
wait_queue_head_t wq;
 };
 
+struct i915_frontbuffer_tracking {
+   struct mutex lock;
+
+   /*
+* Tracking bits for delayed frontbuffer flushing du to gpu activity or
+* scheduled flips.
+*/
+   unsigned busy_bits;
+   unsigned flip_bits;
+};
+
 struct drm_i915_private {
struct drm_device *dev;
struct kmem_cache *slab;
@@ -1478,6 +1489,9 @@ struct drm_i915_private {
bool lvds_downclock_avail;
/* indicates the reduced downclock for LVDS*/
int lvds_downclock;
+

[Intel-gfx] [PATCH 01/16] drm/i915: Drop unecessary complexity from psr_inactivate

2014-06-18 Thread Daniel Vetter
It's not needed and further more will get in the way of a sane
locking scheme - psr_exit _can't_ take modeset locks due to lock
inversion, and at least once dp mst hits the connector list
is no longer static.

But since we track all state in dev_priv-psr there is no need
at all.

Cc: Rodrigo Vivi rodrigo.v...@intel.com
Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/intel_dp.c | 24 +++-
 1 file changed, 3 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 912e9c4de58f..74e194d66bba 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1910,29 +1910,11 @@ static void intel_edp_psr_work(struct work_struct *work)
 static void intel_edp_psr_inactivate(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
-   struct intel_connector *connector;
-   struct intel_encoder *encoder;
-   struct intel_crtc *intel_crtc;
-   struct intel_dp *intel_dp = NULL;
-
-   list_for_each_entry(connector, dev-mode_config.connector_list,
-   base.head) {
 
-   if (connector-base.dpms != DRM_MODE_DPMS_ON)
-   continue;
-
-   encoder = to_intel_encoder(connector-base.encoder);
-   if (encoder-type == INTEL_OUTPUT_EDP) {
+   dev_priv-psr.active = false;
 
-   intel_dp = enc_to_intel_dp(encoder-base);
-   intel_crtc = to_intel_crtc(encoder-base.crtc);
-
-   dev_priv-psr.active = false;
-
-   I915_WRITE(EDP_PSR_CTL(dev), I915_READ(EDP_PSR_CTL(dev))
-   ~EDP_PSR_ENABLE);
-   }
-   }
+   I915_WRITE(EDP_PSR_CTL(dev), I915_READ(EDP_PSR_CTL(dev))
+   ~EDP_PSR_ENABLE);
 }
 
 void intel_edp_psr_exit(struct drm_device *dev, bool schedule_back)
-- 
2.0.0

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


[Intel-gfx] [PATCH 08/16] drm/i915: Lock down psr sw/hw state tracking

2014-06-18 Thread Daniel Vetter
Make sure we track the sw side (psr.active) correctly and WARN
everywhere it might get out of sync with the hw.

v2: Fixup WARN_ON logic inversion, reported by Rodrigo.

Cc: Rodrigo Vivi rodrigo.v...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/intel_dp.c | 43 ++---
 1 file changed, 23 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a2f39055fbb1..910f73de3a92 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1817,8 +1817,8 @@ static void intel_edp_psr_do_enable(struct intel_dp 
*intel_dp)
struct drm_device *dev = intel_dig_port-base.base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
 
-   if (intel_edp_is_psr_enabled(dev))
-   return;
+   WARN_ON(I915_READ(EDP_PSR_CTL(dev))  EDP_PSR_ENABLE);
+   WARN_ON(dev_priv-psr.active);
 
/* Enable PSR on the panel */
intel_edp_psr_enable_sink(intel_dp);
@@ -1859,13 +1859,19 @@ void intel_edp_psr_disable(struct intel_dp *intel_dp)
if (!dev_priv-psr.enabled)
return;
 
-   I915_WRITE(EDP_PSR_CTL(dev),
-  I915_READ(EDP_PSR_CTL(dev))  ~EDP_PSR_ENABLE);
+   if (dev_priv-psr.active) {
+   I915_WRITE(EDP_PSR_CTL(dev),
+  I915_READ(EDP_PSR_CTL(dev))  ~EDP_PSR_ENABLE);
+
+   /* Wait till PSR is idle */
+   if (_wait_for((I915_READ(EDP_PSR_STATUS_CTL(dev)) 
+  EDP_PSR_STATUS_STATE_MASK) == 0, 2000, 10))
+   DRM_ERROR(Timed out waiting for PSR Idle State\n);
 
-   /* Wait till PSR is idle */
-   if (_wait_for((I915_READ(EDP_PSR_STATUS_CTL(dev)) 
-  EDP_PSR_STATUS_STATE_MASK) == 0, 2000, 10))
-   DRM_ERROR(Timed out waiting for PSR Idle State\n);
+   dev_priv-psr.active = false;
+   } else {
+   WARN_ON(I915_READ(EDP_PSR_CTL(dev))  EDP_PSR_ENABLE);
+   }
 
dev_priv-psr.enabled = NULL;
 }
@@ -1883,16 +1889,6 @@ static void intel_edp_psr_work(struct work_struct *work)
intel_edp_psr_do_enable(intel_dp);
 }
 
-static void intel_edp_psr_inactivate(struct drm_device *dev)
-{
-   struct drm_i915_private *dev_priv = dev-dev_private;
-
-   dev_priv-psr.active = false;
-
-   I915_WRITE(EDP_PSR_CTL(dev), I915_READ(EDP_PSR_CTL(dev))
-   ~EDP_PSR_ENABLE);
-}
-
 void intel_edp_psr_exit(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -1905,8 +1901,15 @@ void intel_edp_psr_exit(struct drm_device *dev)
 
cancel_delayed_work_sync(dev_priv-psr.work);
 
-   if (dev_priv-psr.active)
-   intel_edp_psr_inactivate(dev);
+   if (dev_priv-psr.active) {
+   u32 val = I915_READ(EDP_PSR_CTL(dev));
+
+   WARN_ON(!(val  EDP_PSR_ENABLE));
+
+   I915_WRITE(EDP_PSR_CTL(dev), val  ~EDP_PSR_ENABLE);
+
+   dev_priv-psr.active = false;
+   }
 
schedule_delayed_work(dev_priv-psr.work,
  msecs_to_jiffies(100));
-- 
2.0.0

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


[Intel-gfx] [PATCH 13/16] drm/i915: Properly track domain of the fbcon fb

2014-06-18 Thread Daniel Vetter
X could end up putting the fbcon fb into other domains, e.g.
for smooth take-overs. Also we want this for accurate frontbuffer
tracking: The set_config is an implicit flush and will re-enable
psr and similar features, so we need to bring the bo back into
the gtt domain.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/intel_fbdev.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index 27975c3e21c5..53c50240d1c2 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -43,10 +43,29 @@
 #include drm/i915_drm.h
 #include i915_drv.h
 
+static int intel_fbdev_set_par(struct fb_info *info)
+{
+   struct drm_fb_helper *fb_helper = info-par;
+   struct intel_fbdev *ifbdev =
+   container_of(fb_helper, struct intel_fbdev, helper);
+   int ret;
+
+   ret = drm_fb_helper_set_par(info);
+
+   if (ret == 0) {
+   mutex_lock(fb_helper-dev-struct_mutex);
+   ret = i915_gem_object_set_to_gtt_domain(ifbdev-fb-obj,
+   true);
+   mutex_unlock(fb_helper-dev-struct_mutex);
+   }
+
+   return ret;
+}
+
 static struct fb_ops intelfb_ops = {
.owner = THIS_MODULE,
.fb_check_var = drm_fb_helper_check_var,
-   .fb_set_par = drm_fb_helper_set_par,
+   .fb_set_par = intel_fbdev_set_par,
.fb_fillrect = cfb_fillrect,
.fb_copyarea = cfb_copyarea,
.fb_imageblit = cfb_imageblit,
-- 
2.0.0

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


[Intel-gfx] [PATCH 16/16] drm/i915: Improve PSR debugfs output

2014-06-18 Thread Daniel Vetter
Add busy_frontbuffer_bits and locking.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_debugfs.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 4818aff9e6d6..6c0413fd3d37 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1971,10 +1971,15 @@ static int i915_edp_psr_status(struct seq_file *m, void 
*data)
 
intel_runtime_pm_get(dev_priv);
 
+   mutex_lock(dev_priv-psr.lock);
seq_printf(m, Sink_Support: %s\n, yesno(dev_priv-psr.sink_support));
seq_printf(m, Source_OK: %s\n, yesno(dev_priv-psr.source_ok));
seq_printf(m, Enabled: %s\n, yesno((bool)dev_priv-psr.enabled));
seq_printf(m, Active: %s\n, yesno(dev_priv-psr.active));
+   seq_printf(m, Busy frontbuffer bits: 0x%03x\n,
+  dev_priv-psr.busy_frontbuffer_bits);
+   seq_printf(m, Re-enable work scheduled: %s\n,
+  yesno(work_busy(dev_priv-psr.work.work)));
 
enabled = HAS_PSR(dev) 
I915_READ(EDP_PSR_CTL(dev))  EDP_PSR_ENABLE;
@@ -1984,6 +1989,7 @@ static int i915_edp_psr_status(struct seq_file *m, void 
*data)
psrperf = I915_READ(EDP_PSR_PERF_CNT(dev)) 
EDP_PSR_PERF_CNT_MASK;
seq_printf(m, Performance_Counter: %u\n, psrperf);
+   mutex_unlock(dev_priv-psr.lock);
 
intel_runtime_pm_put(dev_priv);
return 0;
-- 
2.0.0

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


Re: [Intel-gfx] [PATCH 09/11] drm/i915: Add rotation property for sprites

2014-06-18 Thread Ville Syrjälä
On Wed, Jun 18, 2014 at 12:12:52PM +0100, Damien Lespiau wrote:
 On Wed, Jun 18, 2014 at 02:27:25PM +0530, sonika.jin...@intel.com wrote:
  From: Ville Syrjälä ville.syrjala at linux.intel.com
  
  Sprite planes support 180 degree rotation. The lower layers are now in
  place, so hook in the standard rotation property to expose the feature
  to the users.
  
  Cc: Daniel Vetter daniel.vetter at ffwll.ch
  Cc: Jani Nikula jani.nikula at linux.intel.com
  Cc: David Airlie airlied at linux.ie
  Cc: dri-devel at lists.freedesktop.org
  Cc: linux-kernel at vger.kernel.org
  Signed-off-by: Ville Syrjälä ville.syrjala at linux.intel.com
  ---
   drivers/gpu/drm/i915/i915_drv.h |1 +
   drivers/gpu/drm/i915/intel_sprite.c |   42 
  ++-
   2 files changed, 42 insertions(+), 1 deletion(-)
  
  diff --git a/drivers/gpu/drm/i915/i915_drv.h 
  b/drivers/gpu/drm/i915/i915_drv.h
  index 0640071..b56a1a5 100644
  --- a/drivers/gpu/drm/i915/i915_drv.h
  +++ b/drivers/gpu/drm/i915/i915_drv.h
  @@ -1514,6 +1514,7 @@ struct drm_i915_private {
   
  struct drm_property *broadcast_rgb_property;
  struct drm_property *force_audio_property;
  +   struct drm_property *rotation_property;
   
  uint32_t hw_context_size;
  struct list_head context_list;
  diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
  b/drivers/gpu/drm/i915/intel_sprite.c
  index cbad738..b9af256 100644
  --- a/drivers/gpu/drm/i915/intel_sprite.c
  +++ b/drivers/gpu/drm/i915/intel_sprite.c
  @@ -1202,6 +1202,30 @@ out_unlock:
  return ret;
   }
   
  +static int intel_plane_set_property(struct drm_plane *plane,
  +   struct drm_property *prop,
  +   uint64_t val)
  +{
  +   struct drm_i915_private *dev_priv = plane-dev-dev_private;
  +   struct intel_plane *intel_plane = to_intel_plane(plane);
  +   uint64_t old_val;
  +   int ret = -ENOENT;
  +
  +   if (prop == dev_priv-rotation_property) {
 
 Shouldn't we add a:
   
   if (val  (BIT(DRM_ROTATE_0) | BIT(DRM_ROTATE_180)))
   return -EINVAL;
 
 To ensure userspace doesn't send garbage in the upper bits so we can
 reuse them down the road?

drm_property_change_is_valid() should already check that no unsupported
bits can escape into the driver.

-- 
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 13/16] drm/i915: Properly track domain of the fbcon fb

2014-06-18 Thread Chris Wilson
On Wed, Jun 18, 2014 at 01:59:14PM +0200, Daniel Vetter wrote:
 X could end up putting the fbcon fb into other domains, e.g.
 for smooth take-overs. Also we want this for accurate frontbuffer
 tracking: The set_config is an implicit flush and will re-enable
 psr and similar features, so we need to bring the bo back into
 the gtt domain.

Is this possibly an atomic path? It would be nice to have a note on
fb_ops which were. But I remember having lots of in_atomic() handling
for fbdev acceleration (copied from nouveau).
-Chris

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


Re: [Intel-gfx] [PATCH 11/16] drm/i915: Introduce accurate frontbuffer tracking

2014-06-18 Thread Chris Wilson
On Wed, Jun 18, 2014 at 01:59:12PM +0200, Daniel Vetter wrote:
   mutex_lock(dev-struct_mutex);
 - ret = intel_pin_and_fence_fb_obj(dev,
 -  to_intel_framebuffer(fb)-obj,
 -  NULL);
 + ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
 + i915_gem_update_fb_bits(to_intel_framebuffer(old_fb)-obj, obj,
 + INTEL_FRONTBUFFER_PRIMARY(pipe));

Hey, no changing state on a failed operation.
-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 00/10] Support for 180 degree HW rotation

2014-06-18 Thread Daniel Vetter
On Wed, Jun 18, 2014 at 05:27:41PM +0530, Jindal, Sonika wrote:
 
 
 On 6/18/2014 5:22 PM, Daniel Vetter wrote:
 On Wed, Jun 18, 2014 at 05:14:49PM +0530, sonika.jin...@intel.com wrote:
 From: Sonika Jindal sonika.jin...@intel.com
 
 Enables 180 degree rotation for sprite and primary planes.
 Updated the primary plane rotation support as per the new universal plane
 design.
 
 Most of these patches were already reviewed in intel-gfx in February 2014 
 thats
 why there is version history in few of them.
 
 Testcase: kms_rotation_crc
 This igt can be extended for clipped rotation cases. Right it only tests 180
 degree rotation for sprite and primary plane with crc check.
 
 Sonika Jindal (1):
drm/i915: Add 180 degree primary plane rotation support
 
 Ville Syrjälä (9):
drm: Move DRM_ROTATE bits out of omapdrm into drm_crtc.h
drm: Add support_bits parameter to drm_property_create_bitmask()
drm: Add drm_mode_create_rotation_property()
drm/omap: Switch omapdrm over to drm_mode_create_rotation_property()
drm: Add drm_rect rotation functions
drm: Add drm_rotation_simplify()
drm/i915: Add 180 degree sprite rotation support
drm/i915: Make intel_plane_restore() return an error
drm/i915: Add rotation property for sprites
 
 Pleas don't repost entire patch series on the same day without a changelog
 in the cover letter explaining what's going on and what changed.
 
 If you just need to repost a few patches that changed due to review,
 please do that with an in-reply-to directly to the relevant discussion.
 
 If everyone reposts their big patch series a few times a day we'll have
 utter chaos.
 -Daniel
 
 I am sorry for this. I thought creating a new patchset should be good,
 missed updating it in cover letter.
 I will keep this in mind.

It's always a balancing act - if the threads nest too deeply eventually
in-reply-to becomes a mess, too. But a rule of thumb is that you should
only resend when the patch series changed completely or once review has
settled down (so only after a few days) and the review thread has become
too deeply nested.

But resending the entire series on the same day before review has
concluded is definitely too early. Our team is global so without a full
day not everyone even had a chance to look at it - us west coast is still
fast asleep ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 09/16] drm/i915: More checks for psr.enabled

2014-06-18 Thread Daniel Vetter
On Wed, Jun 18, 2014 at 01:27:06PM +0100, Chris Wilson wrote:
 On Wed, Jun 18, 2014 at 01:59:10PM +0200, Daniel Vetter wrote:
  We need to make sure that no one else is using this in the
  enable function and also that the work item hasn't raced
  with the disabled function.
  
  v2: Improve bisectability by moving one hunk to an earlier patch.
  
  Cc: Rodrigo Vivi rodrigo.v...@intel.com
  Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
  ---
   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 910f73de3a92..870219ff1187 100644
  --- a/drivers/gpu/drm/i915/intel_dp.c
  +++ b/drivers/gpu/drm/i915/intel_dp.c
  @@ -1844,6 +1844,11 @@ void intel_edp_psr_enable(struct intel_dp *intel_dp)
  return;
  }
 
 Is this the tail of a HAS_PSR() now made obsolete?

Yeah, we have a bit of redundancy here now I think. Otoh once we have
locking they make sense again since HAS_PSR can be checked without
grabbing the psr lock, while psr.enabled can't. So I think it makes sense
to keep them.
-Daniel

   
  +   if (dev_priv-psr.enabled) {
  +   DRM_DEBUG_KMS(PSR already in use\n);
  +   return;
  +   }
 -Chris
 
 -- 
 Chris Wilson, Intel Open Source Technology Centre

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


Re: [Intel-gfx] [PATCH 13/16] drm/i915: Properly track domain of the fbcon fb

2014-06-18 Thread Daniel Vetter
On Wed, Jun 18, 2014 at 01:10:32PM +0100, Chris Wilson wrote:
 On Wed, Jun 18, 2014 at 01:59:14PM +0200, Daniel Vetter wrote:
  X could end up putting the fbcon fb into other domains, e.g.
  for smooth take-overs. Also we want this for accurate frontbuffer
  tracking: The set_config is an implicit flush and will re-enable
  psr and similar features, so we need to bring the bo back into
  the gtt domain.
 
 Is this possibly an atomic path? It would be nice to have a note on
 fb_ops which were. But I remember having lots of in_atomic() handling
 for fbdev acceleration (copied from nouveau).

They are all callable from atomic, at least in Oopses. fbdev accel is
completely bonghits in that regard (imnsho) and I think the only option we
have is to block _any_ fbdev operation in atomic contexts from the start
and use David Herrmann's special last effort emergency logging support to
print the Oops. Even trying to make all this code work from atomic
contexts is imo a losing battle and a complete validation nightmare.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 09/16] drm/i915: More checks for psr.enabled

2014-06-18 Thread Chris Wilson
On Wed, Jun 18, 2014 at 02:41:34PM +0200, Daniel Vetter wrote:
 On Wed, Jun 18, 2014 at 01:27:06PM +0100, Chris Wilson wrote:
  On Wed, Jun 18, 2014 at 01:59:10PM +0200, Daniel Vetter wrote:
   We need to make sure that no one else is using this in the
   enable function and also that the work item hasn't raced
   with the disabled function.
   
   v2: Improve bisectability by moving one hunk to an earlier patch.
   
   Cc: Rodrigo Vivi rodrigo.v...@intel.com
   Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
   ---
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 910f73de3a92..870219ff1187 100644
   --- a/drivers/gpu/drm/i915/intel_dp.c
   +++ b/drivers/gpu/drm/i915/intel_dp.c
   @@ -1844,6 +1844,11 @@ void intel_edp_psr_enable(struct intel_dp 
   *intel_dp)
 return;
 }
  
  Is this the tail of a HAS_PSR() now made obsolete?
 
 Yeah, we have a bit of redundancy here now I think. Otoh once we have
 locking they make sense again since HAS_PSR can be checked without
 grabbing the psr lock, while psr.enabled can't. So I think it makes sense
 to keep them.

We do try to encourage the idiom of checking compatibility once at init,
then checking state at runtime. If the lock becomes burdensome we can
mitigate it.  Hmm, such as

frontbuffer_bits = ~fb_tracking.busy_bits; /* only notify us for changes in 
state */

Further promoting the idea of refactoring cpu/gpu/flip tracking. :)
-Chris

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


[Intel-gfx] [PATCH] drm/i915: Print obj-frontbuffer_bits in debugfs output

2014-06-18 Thread Daniel Vetter
Can be useful to figure out imbalances and bugs in the frontbuffer
tracking.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6c0413fd3d37..73510481bdba 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -170,6 +170,8 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object 
*obj)
}
if (obj-ring != NULL)
seq_printf(m,  (%s), obj-ring-name);
+   if (obj-frontbuffer_bits)
+   seq_printf(m,  (frontbuffer: 0x%03x), obj-frontbuffer_bits);
 }
 
 static void describe_ctx(struct seq_file *m, struct intel_context *ctx)
-- 
2.0.0

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


Re: [Intel-gfx] [PATCH] backlight: Fix compile error

2014-06-18 Thread Chris Wilson
On Wed, Jun 18, 2014 at 02:41:56PM +0200, Hans de Goede wrote:
 /usr/include/xorg/os.h around line 579 reads:
 
 extern _X_EXPORT char *
 strndup(const char *str, size_t n);
 
 However strndup is already defined by glibc, and this redefine causes a
 compile error.
 
 This gets triggered because backlight.c does:
 
 Without first doing:
 
 Causing HAVE_STRNDUP to not be defined.
 
 Signed-off-by: Hans de Goede hdego...@redhat.com
 ---
  src/backlight.c | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/src/backlight.c b/src/backlight.c
 index d5b10a0..62241ab 100644
 --- a/src/backlight.c
 +++ b/src/backlight.c
 @@ -42,6 +42,7 @@
  #include fcntl.h
  #include unistd.h
  #include dirent.h
 +#include xorg-server.h
  #include xf86.h
  #include pciaccess.h

Does ordering it as

diff --git a/src/backlight.c b/src/backlight.c
index d5b10a0..24eb11c 100644
--- a/src/backlight.c
+++ b/src/backlight.c
@@ -29,6 +29,9 @@
 #include config.h
 #endif
 
+#include xorg-server.h
+#include xf86.h
+
 #include sys/types.h
 #include sys/wait.h
 #include sys/stat.h
@@ -42,7 +45,6 @@
 #include fcntl.h
 #include unistd.h
 #include dirent.h
-#include xf86.h
 #include pciaccess.h
 
 #include backlight.h

make more sense?
-Chris

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


[Intel-gfx] [PATCH 2/2] uxa: Mark the output as off before making pipe changes

2014-06-18 Thread Hans de Goede
This is a partial backport of commit c6cd10f536, which makes the same
change for sna, to avoid users still using uxa ending up with a blackscreen
after plugging in an external monitor.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 src/uxa/intel_display.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/uxa/intel_display.c b/src/uxa/intel_display.c
index e00b9c2..a745dc5 100644
--- a/src/uxa/intel_display.c
+++ b/src/uxa/intel_display.c
@@ -320,6 +320,14 @@ intel_crtc_apply(xf86CrtcPtr crtc)
xf86OutputPtr output = xf86_config-output[i];
struct intel_output *intel_output;
 
+   /* Make sure we mark the output as off (and save the backlight)
+* before the kernel turns it off due to changing the pipe.
+* This is necessary as the kernel may turn off the backlight
+* and we lose track of the user settings.
+*/
+   if (output-crtc == NULL)
+   output-funcs-dpms(output, DPMSModeOff);
+
if (output-crtc != crtc)
continue;
 
-- 
2.0.0

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


[Intel-gfx] [PATCH] drm/i915: Introduce accurate frontbuffer tracking

2014-06-18 Thread Daniel Vetter
So from just a quick look we seem to have enough information to
accurately figure out whether a given gem bo is used as a frontbuffer
and where exactly: We have obj-pin_count as a first check with no
false negatives and only negligible false positives. And then we can
just walk the modeset objects and figure out where exactly a buffer is
used as scanout.

Except that we can't due to locking order: If we already hold
dev-struct_mutex we can't acquire any modeset locks, so could
potential chase freed pointers and other evil stuff.

So we need something else. For that introduce a new set of bits
obj-frontbuffer_bits to track where a buffer object is used. That we
can then chase without grabbing any modeset locks.

Of course the consumers of this (DRRS, PSR, FBC, ...) still need to be
able to do their magic both when called from modeset and from gem
code. But that can be easily achieved by adding locks for these
specific subsystems which always nest within either kms or gem
locking.

This patch just adds the relevant update code to all places.

Note that if we ever support multi-planar scanout targets then we need
one frontbuffer tracking bit per attachment point that we expose to
userspace.

v2:
- Fix more oopsen. Oops.
- WARN if we leak obj-frontbuffer_bits when freeing a gem buffer. Fix
  the bugs this brought to light.
- s/update_frontbuffer_bits/update_fb_bits/. More consistent with the
  fb tracking functions (fb for gem object, frontbuffer for raw bits).
  And the function name was way too long.

v3: Size obj-frontbuffer_bits correctly so that all pipes fit in.

v4: Don't update fb bits in set_base on failure. Noticed by Chris.

Cc: Rodrigo Vivi rodrigo.v...@intel.com
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_drv.h  | 26 +
 drivers/gpu/drm/i915/i915_gem.c  | 19 ++
 drivers/gpu/drm/i915/intel_display.c | 73 +++-
 drivers/gpu/drm/i915/intel_overlay.c | 11 ++
 drivers/gpu/drm/i915/intel_sprite.c  |  7 
 5 files changed, 119 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b6195ea334e6..2ae2b96c371d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1595,6 +1595,26 @@ struct drm_i915_gem_object_ops {
void (*release)(struct drm_i915_gem_object *);
 };
 
+/*
+ * Frontbuffer tracking bits. Set in obj-frontbuffer_bits while a gem bo is
+ * considered to be the frontbuffer for the given plane interface-vise. This
+ * doesn't mean that the hw necessarily already scans it out, but that any
+ * rendering (by the cpu or gpu) will land in the frontbuffer eventually.
+ *
+ * We have one bit per pipe and per scanout plane type.
+ */
+#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
+
 struct drm_i915_gem_object {
struct drm_gem_object base;
 
@@ -1682,6 +1702,8 @@ struct drm_i915_gem_object {
unsigned int has_global_gtt_mapping:1;
unsigned int has_dma_mapping:1;
 
+   unsigned int frontbuffer_bits:INTEL_FRONTBUFFER_BITS;
+
struct sg_table *pages;
int pages_pin_count;
 
@@ -1728,6 +1750,10 @@ struct drm_i915_gem_object {
 };
 #define to_intel_bo(x) container_of(x, struct drm_i915_gem_object, base)
 
+void i915_gem_update_fb_bits(struct drm_i915_gem_object *old,
+struct drm_i915_gem_object *new,
+unsigned frontbuffer_bits);
+
 /**
  * Request queue structure.
  *
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7d7d52bc922a..c40dd4ba2c27 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4449,6 +4449,8 @@ void i915_gem_free_object(struct drm_gem_object *gem_obj)
if (obj-stolen)
i915_gem_object_unpin_pages(obj);
 
+   WARN_ON(obj-frontbuffer_bits);
+
if (WARN_ON(obj-pages_pin_count))
obj-pages_pin_count = 0;
if (discard_backing_storage(obj))
@@ -4993,6 +4995,23 @@ int i915_gem_open(struct drm_device *dev, struct 
drm_file *file)
return ret;
 }
 
+void i915_gem_update_fb_bits(struct drm_i915_gem_object *old,
+struct drm_i915_gem_object *new,
+unsigned frontbuffer_bits)
+{
+   if (old) {
+   WARN_ON(!mutex_is_locked(old-base.dev-struct_mutex));
+   

[Intel-gfx] [PATCH 1/2] uxa: When the output is off, report the cached backlight value

2014-06-18 Thread Hans de Goede
This is a backport of commit b545e10c50cb to uxa, so that users who are
still using uxa, don't end up with a black screen after suspend / resume.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 src/uxa/intel_display.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/uxa/intel_display.c b/src/uxa/intel_display.c
index b90061b..e00b9c2 100644
--- a/src/uxa/intel_display.c
+++ b/src/uxa/intel_display.c
@@ -1257,9 +1257,13 @@ intel_output_get_property(xf86OutputPtr output, Atom 
property)
if (!intel_output-backlight.iface)
return FALSE;
 
-   val = intel_output_backlight_get(output);
-   if (val  0)
-   return FALSE;
+   if (intel_output-dpms_mode == DPMSModeOn) {
+   val = intel_output_backlight_get(output);
+   if (val  0)
+   return FALSE;
+   } else {
+   val = intel_output-backlight_active_level;
+   }
 
err = RRChangeOutputProperty(output-randr_output, property,
 XA_INTEGER, 32, PropModeReplace, 
1, val,
-- 
2.0.0

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


Re: [Intel-gfx] [PATCH 09/16] drm/i915: More checks for psr.enabled

2014-06-18 Thread Daniel Vetter
On Wed, Jun 18, 2014 at 01:46:16PM +0100, Chris Wilson wrote:
 On Wed, Jun 18, 2014 at 02:41:34PM +0200, Daniel Vetter wrote:
  On Wed, Jun 18, 2014 at 01:27:06PM +0100, Chris Wilson wrote:
   On Wed, Jun 18, 2014 at 01:59:10PM +0200, Daniel Vetter wrote:
We need to make sure that no one else is using this in the
enable function and also that the work item hasn't raced
with the disabled function.

v2: Improve bisectability by moving one hunk to an earlier patch.

Cc: Rodrigo Vivi rodrigo.v...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 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 910f73de3a92..870219ff1187 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1844,6 +1844,11 @@ void intel_edp_psr_enable(struct intel_dp 
*intel_dp)
return;
}
   
   Is this the tail of a HAS_PSR() now made obsolete?
  
  Yeah, we have a bit of redundancy here now I think. Otoh once we have
  locking they make sense again since HAS_PSR can be checked without
  grabbing the psr lock, while psr.enabled can't. So I think it makes sense
  to keep them.
 
 We do try to encourage the idiom of checking compatibility once at init,
 then checking state at runtime. If the lock becomes burdensome we can
 mitigate it.  Hmm, such as

Ok, convinced, I'll throw a cleanup patch on top.

 frontbuffer_bits = ~fb_tracking.busy_bits; /* only notify us for changes in 
 state */
 
 Further promoting the idea of refactoring cpu/gpu/flip tracking. :)

The idea is that consumers like psr track the state and have the edge
detection they care about. Once we have drrs and fbc converted we can have
a look at this again and whether extracting common logic makes sense. But
I suspect that there's not much room given that we always accumulate funky
platform hacks like the hsw sprite case. So passing the unfilter events to
the consumers seemed like the right approach.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915: Properly track domain of the fbcon fb

2014-06-18 Thread Daniel Vetter
X could end up putting the fbcon fb into other domains, e.g.
for smooth take-overs. Also we want this for accurate frontbuffer
tracking: The set_config is an implicit flush and will re-enable
psr and similar features, so we need to bring the bo back into
the gtt domain.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/intel_fbdev.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index 27975c3e21c5..53c50240d1c2 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -43,10 +43,29 @@
 #include drm/i915_drm.h
 #include i915_drv.h
 
+static int intel_fbdev_set_par(struct fb_info *info)
+{
+   struct drm_fb_helper *fb_helper = info-par;
+   struct intel_fbdev *ifbdev =
+   container_of(fb_helper, struct intel_fbdev, helper);
+   int ret;
+
+   ret = drm_fb_helper_set_par(info);
+
+   if (ret == 0) {
+   mutex_lock(fb_helper-dev-struct_mutex);
+   ret = i915_gem_object_set_to_gtt_domain(ifbdev-fb-obj,
+   true);
+   mutex_unlock(fb_helper-dev-struct_mutex);
+   }
+
+   return ret;
+}
+
 static struct fb_ops intelfb_ops = {
.owner = THIS_MODULE,
.fb_check_var = drm_fb_helper_check_var,
-   .fb_set_par = drm_fb_helper_set_par,
+   .fb_set_par = intel_fbdev_set_par,
.fb_fillrect = cfb_fillrect,
.fb_copyarea = cfb_copyarea,
.fb_imageblit = cfb_imageblit,
-- 
2.0.0

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


Re: [Intel-gfx] [PATCH] backlight: Fix compile error

2014-06-18 Thread Hans de Goede
Hi,

On 06/18/2014 02:51 PM, Chris Wilson wrote:
 On Wed, Jun 18, 2014 at 02:41:56PM +0200, Hans de Goede wrote:
 /usr/include/xorg/os.h around line 579 reads:

 extern _X_EXPORT char *
 strndup(const char *str, size_t n);

 However strndup is already defined by glibc, and this redefine causes a
 compile error.

 This gets triggered because backlight.c does:

 Without first doing:

 Causing HAVE_STRNDUP to not be defined.

 Signed-off-by: Hans de Goede hdego...@redhat.com
 ---
  src/backlight.c | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/src/backlight.c b/src/backlight.c
 index d5b10a0..62241ab 100644
 --- a/src/backlight.c
 +++ b/src/backlight.c
 @@ -42,6 +42,7 @@
  #include fcntl.h
  #include unistd.h
  #include dirent.h
 +#include xorg-server.h
  #include xf86.h
  #include pciaccess.h
 
 Does ordering it as
 
 diff --git a/src/backlight.c b/src/backlight.c
 index d5b10a0..24eb11c 100644
 --- a/src/backlight.c
 +++ b/src/backlight.c
 @@ -29,6 +29,9 @@
  #include config.h
  #endif
  
 +#include xorg-server.h
 +#include xf86.h
 +
  #include sys/types.h
  #include sys/wait.h
  #include sys/stat.h
 @@ -42,7 +45,6 @@
  #include fcntl.h
  #include unistd.h
  #include dirent.h
 -#include xf86.h
  #include pciaccess.h
  
  #include backlight.h
 
 make more sense?

I usually put specific library includes after standard libc includes, so IMHO 
no,
if you move them up you should probably also move the pciaccess.h include up.

The important thing seems to be to include xorg-server.h before any other 
xserver
includes.

Regards,

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


[Intel-gfx] [PATCH] drm/i915: Remove redundant HAS_PSR checks

2014-06-18 Thread Daniel Vetter
We only need to check for this in psr_enable, everything else is
already protect by the dev_priv-psr.enabled checks. Those need the
psr locking, but these functions are called infrequent enough that the
locking overhead is negligible.

Suggested by Chris Wilson.

Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/intel_dp.c | 14 --
 1 file changed, 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 1a8b3d90e422..0c1c77ae16fb 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1754,11 +1754,6 @@ static bool intel_edp_psr_match_conditions(struct 
intel_dp *intel_dp)
 
dev_priv-psr.source_ok = false;
 
-   if (!HAS_PSR(dev)) {
-   DRM_DEBUG_KMS(PSR not supported on this platform\n);
-   return false;
-   }
-
if (IS_HASWELL(dev)  dig_port-port != PORT_A) {
DRM_DEBUG_KMS(HSW ties PSR to DDI A (eDP)\n);
return false;
@@ -1845,9 +1840,6 @@ void intel_edp_psr_disable(struct intel_dp *intel_dp)
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct drm_i915_private *dev_priv = dev-dev_private;
 
-   if (!HAS_PSR(dev))
-   return;
-
mutex_lock(dev_priv-psr.lock);
if (!dev_priv-psr.enabled) {
mutex_unlock(dev_priv-psr.lock);
@@ -1922,9 +1914,6 @@ void intel_edp_psr_invalidate(struct drm_device *dev,
struct drm_crtc *crtc;
enum pipe pipe;
 
-   if (!HAS_PSR(dev))
-   return;
-
mutex_lock(dev_priv-psr.lock);
if (!dev_priv-psr.enabled) {
mutex_unlock(dev_priv-psr.lock);
@@ -1949,9 +1938,6 @@ void intel_edp_psr_flush(struct drm_device *dev,
struct drm_crtc *crtc;
enum pipe pipe;
 
-   if (!HAS_PSR(dev))
-   return;
-
mutex_lock(dev_priv-psr.lock);
if (!dev_priv-psr.enabled) {
mutex_unlock(dev_priv-psr.lock);
-- 
2.0.0

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


Re: [Intel-gfx] [PATCH 09/11] drm/i915: Add rotation property for sprites

2014-06-18 Thread Damien Lespiau
On Wed, Jun 18, 2014 at 05:24:56PM +0530, Jindal, Sonika wrote:
 Shouldn't we add a:
  
  if (val  (BIT(DRM_ROTATE_0) | BIT(DRM_ROTATE_180)))
  return -EINVAL;
 
 To ensure userspace doesn't send garbage in the upper bits so we can
 reuse them down the road?
 
 But we are checking if more than one bit is set, we return EINVAL.
 So we only care for one rotation angle being sent from user.
 Shouldn't that suffice?

Nop. If given (1  50) we'd still pass the test but with an invalid
(reserved) value.

I didn't spot the generic drm_property_change_is_valid() (Ville's
answer), so it should be handled for us by the DRM core already.

All is fine.

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


[Intel-gfx] [PATCH] drm/i915: Properly track domain of the fbcon fb

2014-06-18 Thread Daniel Vetter
X could end up putting the fbcon fb into other domains, e.g.
for smooth take-overs. Also we want this for accurate frontbuffer
tracking: The set_config is an implicit flush and will re-enable
psr and similar features, so we need to bring the bo back into
the gtt domain.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/intel_fbdev.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index 27975c3e21c5..53c50240d1c2 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -43,10 +43,29 @@
 #include drm/i915_drm.h
 #include i915_drv.h
 
+static int intel_fbdev_set_par(struct fb_info *info)
+{
+   struct drm_fb_helper *fb_helper = info-par;
+   struct intel_fbdev *ifbdev =
+   container_of(fb_helper, struct intel_fbdev, helper);
+   int ret;
+
+   ret = drm_fb_helper_set_par(info);
+
+   if (ret == 0) {
+   mutex_lock(fb_helper-dev-struct_mutex);
+   ret = i915_gem_object_set_to_gtt_domain(ifbdev-fb-obj,
+   true);
+   mutex_unlock(fb_helper-dev-struct_mutex);
+   }
+
+   return ret;
+}
+
 static struct fb_ops intelfb_ops = {
.owner = THIS_MODULE,
.fb_check_var = drm_fb_helper_check_var,
-   .fb_set_par = drm_fb_helper_set_par,
+   .fb_set_par = intel_fbdev_set_par,
.fb_fillrect = cfb_fillrect,
.fb_copyarea = cfb_copyarea,
.fb_imageblit = cfb_imageblit,
-- 
2.0.0

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


Re: [Intel-gfx] [PATCH] backlight: Fix compile error

2014-06-18 Thread Chris Wilson
On Wed, Jun 18, 2014 at 03:04:21PM +0200, Hans de Goede wrote:
 Hi,
 
 On 06/18/2014 02:51 PM, Chris Wilson wrote:
  On Wed, Jun 18, 2014 at 02:41:56PM +0200, Hans de Goede wrote:
  /usr/include/xorg/os.h around line 579 reads:
 
  extern _X_EXPORT char *
  strndup(const char *str, size_t n);
 
  However strndup is already defined by glibc, and this redefine causes a
  compile error.
 
  This gets triggered because backlight.c does:
 
  Without first doing:
 
  Causing HAVE_STRNDUP to not be defined.
 
  Signed-off-by: Hans de Goede hdego...@redhat.com
  ---
   src/backlight.c | 1 +
   1 file changed, 1 insertion(+)
 
  diff --git a/src/backlight.c b/src/backlight.c
  index d5b10a0..62241ab 100644
  --- a/src/backlight.c
  +++ b/src/backlight.c
  @@ -42,6 +42,7 @@
   #include fcntl.h
   #include unistd.h
   #include dirent.h
  +#include xorg-server.h
   #include xf86.h
   #include pciaccess.h
  
  Does ordering it as
  
  diff --git a/src/backlight.c b/src/backlight.c
  index d5b10a0..24eb11c 100644
  --- a/src/backlight.c
  +++ b/src/backlight.c
  @@ -29,6 +29,9 @@
   #include config.h
   #endif
   
  +#include xorg-server.h
  +#include xf86.h
  +
   #include sys/types.h
   #include sys/wait.h
   #include sys/stat.h
  @@ -42,7 +45,6 @@
   #include fcntl.h
   #include unistd.h
   #include dirent.h
  -#include xf86.h
   #include pciaccess.h
   
   #include backlight.h
  
  make more sense?
 
 I usually put specific library includes after standard libc includes, so 
 IMHO no,
 if you move them up you should probably also move the pciaccess.h include up.
 
 The important thing seems to be to include xorg-server.h before any other 
 xserver
 includes.

Right, so I usually put it first, and usually put xf86*.h last.
 
 Regards,
 
 Hans
 

-- 
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] backlight: Fix compile error

2014-06-18 Thread Chris Wilson
On Wed, Jun 18, 2014 at 02:41:56PM +0200, Hans de Goede wrote:
 /usr/include/xorg/os.h around line 579 reads:
 
 extern _X_EXPORT char *
 strndup(const char *str, size_t n);
 
 However strndup is already defined by glibc, and this redefine causes a
 compile error.
 
 This gets triggered because backlight.c does:
 
 Without first doing:
 
 Causing HAVE_STRNDUP to not be defined.
 
 Signed-off-by: Hans de Goede hdego...@redhat.com

Pushed with one extra newline to break up the xorg headers from the
rest.

Thanks,
-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 2/2] uxa: Mark the output as off before making pipe changes

2014-06-18 Thread Chris Wilson
On Wed, Jun 18, 2014 at 03:01:37PM +0200, Hans de Goede wrote:
 This is a partial backport of commit c6cd10f536, which makes the same
 change for sna, to avoid users still using uxa ending up with a blackscreen
 after plugging in an external monitor.
 
 Signed-off-by: Hans de Goede hdego...@redhat.com

Do you want to reference your bugzilla here for background on the bug?
-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 00/10] Support for 180 degree HW rotation

2014-06-18 Thread Damien Lespiau
On Wed, Jun 18, 2014 at 05:14:49PM +0530, sonika.jin...@intel.com wrote:
 From: Sonika Jindal sonika.jin...@intel.com
 
 Enables 180 degree rotation for sprite and primary planes.
 Updated the primary plane rotation support as per the new universal plane
 design.
 
 Most of these patches were already reviewed in intel-gfx in February 2014 
 thats
 why there is version history in few of them.
 
 Testcase: kms_rotation_crc
 This igt can be extended for clipped rotation cases. Right it only tests 180
 degree rotation for sprite and primary plane with crc check.

* All the Signed-off-by/Cc tags have mangled e-mail addresses, (blah at foo) so:
  - The Cc: fields of your emails are empty.
  - checkpatch.pl complains about invalid s-o-b tags.

* Please remove the Cc: to the LKML, no need to add more chaos there.

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


[Intel-gfx] [PATCH i-g-t 0/4] enabling connectors (v2)

2014-06-18 Thread Thomas Wood
The following series is a replacement for the previous series that enabled
connector states to be modified. It now uses the debugfs interface to change
the connection state of connectors and also adds the ability to override the
EDID blocks on the connectors.


Thomas Wood (4):
  lib: add function to change connector states
  lib: add the ability to set an EDID data block on a connector
  lib: add igt_enable_connectors and igt_reset_connectors
  tests: enable extra connectors in kms_flip and kms_pipe_crc_basic

 .../intel-gpu-tools/intel-gpu-tools-docs.xml   |   1 +
 lib/Makefile.sources   |   1 +
 lib/igt_edid.h | 125 +++
 lib/igt_kms.c  | 169 +
 lib/igt_kms.h  |  42 +
 tests/Makefile.sources |   1 +
 tests/kms_flip.c   |   2 +
 tests/kms_force_connector.c| 113 ++
 tests/kms_pipe_crc_basic.c |   2 +
 9 files changed, 456 insertions(+)
 create mode 100644 lib/igt_edid.h
 create mode 100644 tests/kms_force_connector.c

-- 
1.9.3

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


[Intel-gfx] [PATCH i-g-t 1/4] lib: add function to change connector states

2014-06-18 Thread Thomas Wood
Add an API function and a test program to force a particular state on a
connector.

Signed-off-by: Thomas Wood thomas.w...@intel.com
---
 lib/igt_kms.c   | 57 +
 lib/igt_kms.h   | 16 
 tests/Makefile.sources  |  1 +
 tests/kms_force_connector.c | 89 +
 4 files changed, 163 insertions(+)
 create mode 100644 tests/kms_force_connector.c

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index c0f4f6c..8de8e0a 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -384,6 +384,63 @@ err1:
return -1;
 }
 
+static int get_card_number(int fd)
+{
+   struct stat buf;
+
+   /* find the minor number of the device */
+   fstat(fd, buf);
+
+   return minor(buf.st_rdev);
+}
+
+/**
+ * kmstest_force_connector:
+ * @fd: drm file descriptor
+ * @connector: connector
+ * @state: state to force on @connector
+ *
+ * Force the specified state on the specified connector.
+ */
+void kmstest_force_connector(int drm_fd, drmModeConnector *connector, enum
+kmstest_force_connector_state state)
+{
+   char *path;
+   const char *value;
+   int debugfs_fd, ret;
+
+   switch (state) {
+   case FORCE_CONNECTOR_ON:
+   value = on;
+   break;
+   case FORCE_CONNECTOR_DIGITAL:
+   value = digital;
+   break;
+   case FORCE_CONNECTOR_OFF:
+   value = off;
+   break;
+
+   default:
+   case FORCE_CONNECTOR_UNSPECIFIED:
+   value = unspecified;
+   break;
+   }
+
+   asprintf(path, /sys/kernel/debug/dri/%d/%s-%d/force,
+get_card_number(drm_fd),
+kmstest_connector_type_str(connector-connector_type),
+connector-connector_type_id);
+   debugfs_fd = open(path, O_WRONLY | O_TRUNC);
+   free(path);
+
+   igt_assert(debugfs_fd != -1);
+
+   ret = write(debugfs_fd, value, strlen(value));
+   close(debugfs_fd);
+
+   igt_assert(ret != -1);
+}
+
 void kmstest_free_connector_config(struct kmstest_connector_config *config)
 {
drmModeFreeCrtc(config-crtc);
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 7d015b4..45a98c8 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -76,11 +76,27 @@ struct kmstest_connector_config {
int pipe;
 };
 
+/**
+ * kmstest_force_connector_state:
+ * @FORCE_CONNECTOR_UNSPECIFIED: Unspecified
+ * @FORCE_CONNECTOR_ON: On
+ * @FORCE_CONNECTOR_DIGITAL: Digital
+ * @FORCE_CONNECTOR_OFF: Off
+ */
+enum kmstest_force_connector_state {
+   FORCE_CONNECTOR_UNSPECIFIED,
+   FORCE_CONNECTOR_ON,
+   FORCE_CONNECTOR_DIGITAL,
+   FORCE_CONNECTOR_OFF
+};
+
 int kmstest_get_connector_default_mode(int drm_fd, drmModeConnector *connector,
  drmModeModeInfo *mode);
 int kmstest_get_connector_config(int drm_fd, uint32_t connector_id,
 unsigned long crtc_idx_mask,
 struct kmstest_connector_config *config);
+void kmstest_force_connector(int fd, drmModeConnector *connector,
+enum kmstest_force_connector_state state);
 void kmstest_free_connector_config(struct kmstest_connector_config *config);
 
 void kmstest_dump_mode(drmModeModeInfo *mode);
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 17c0ab9..dc08a3c 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -138,6 +138,7 @@ TESTS_progs = \
gen3_render_tiledx_blits \
gen3_render_tiledy_blits \
gen7_forcewake_mt \
+   kms_force_connector \
kms_sink_crc_basic \
kms_fence_pin_leak \
pm_psr \
diff --git a/tests/kms_force_connector.c b/tests/kms_force_connector.c
new file mode 100644
index 000..0591da0
--- /dev/null
+++ b/tests/kms_force_connector.c
@@ -0,0 +1,89 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 

[Intel-gfx] [PATCH i-g-t 2/4] lib: add the ability to set an EDID data block on a connector

2014-06-18 Thread Thomas Wood
Add a function to set an EDID data block on a connector and include a
set of generic EDID blocks for testing.

Signed-off-by: Thomas Wood thomas.w...@intel.com
---
 .../intel-gpu-tools/intel-gpu-tools-docs.xml   |   1 +
 lib/Makefile.sources   |   1 +
 lib/igt_edid.h | 125 +
 lib/igt_kms.c  |  50 -
 lib/igt_kms.h  |  23 
 tests/kms_force_connector.c|  24 
 6 files changed, 220 insertions(+), 4 deletions(-)
 create mode 100644 lib/igt_edid.h

diff --git a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml 
b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
index 68ca8d4..3d9caf8 100644
--- a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
+++ b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
@@ -25,6 +25,7 @@
 xi:include href=xml/intel_batchbuffer.xml/
 xi:include href=xml/intel_chipset.xml/
 xi:include href=xml/intel_io.xml/
+xi:include href=xml/igt_edid.xml/
 
   /chapter
   index id=api-index-full
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 62a0c75..8c6c4dc 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -40,6 +40,7 @@ libintel_tools_la_SOURCES =   \
intel_iosf.c\
igt_kms.c   \
igt_kms.h   \
+   igt_edid.h  \
igt_fb.c\
igt_fb.h\
igt_core.c  \
diff --git a/lib/igt_edid.h b/lib/igt_edid.h
new file mode 100644
index 000..27373b7
--- /dev/null
+++ b/lib/igt_edid.h
@@ -0,0 +1,125 @@
+/*
+ * generic edid taken from Linux, drivers/gpu/drm/drm_edid_load.c:
+ *
+ *
+   drm_edid_load.c: use a built-in EDID data set or load it via the firmware
+   interface
+
+   Copyright (C) 2012 Carsten Emde c.e...@osadl.org
+
+   This program is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Public License
+   as published by the Free Software Foundation; either version 2
+   of the License, or (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA.
+*/
+
+#ifndef __IGT_EDID_H__
+#define __IGT_EDID_H__
+
+#include igt_kms.h
+
+#define EDID_LENGTH 128
+
+static const unsigned char generic_edid[MAX_EDIDS][EDID_LENGTH] = {
+   {
+   0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00,
+   0x31, 0xd8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+   0x05, 0x16, 0x01, 0x03, 0x6d, 0x23, 0x1a, 0x78,
+   0xea, 0x5e, 0xc0, 0xa4, 0x59, 0x4a, 0x98, 0x25,
+   0x20, 0x50, 0x54, 0x00, 0x08, 0x00, 0x61, 0x40,
+   0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
+   0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x64, 0x19,
+   0x00, 0x40, 0x41, 0x00, 0x26, 0x30, 0x08, 0x90,
+   0x36, 0x00, 0x63, 0x0a, 0x11, 0x00, 0x00, 0x18,
+   0x00, 0x00, 0x00, 0xff, 0x00, 0x4c, 0x69, 0x6e,
+   0x75, 0x78, 0x20, 0x23, 0x30, 0x0a, 0x20, 0x20,
+   0x20, 0x20, 0x00, 0x00, 0x00, 0xfd, 0x00, 0x3b,
+   0x3d, 0x2f, 0x31, 0x07, 0x00, 0x0a, 0x20, 0x20,
+   0x20, 0x20, 0x20, 0x20, 0x00, 0x00, 0x00, 0xfc,
+   0x00, 0x4c, 0x69, 0x6e, 0x75, 0x78, 0x20, 0x58,
+   0x47, 0x41, 0x0a, 0x20, 0x20, 0x20, 0x00, 0x55,
+   },
+   {
+   0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00,
+   0x31, 0xd8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+   0x05, 0x16, 0x01, 0x03, 0x6d, 0x2c, 0x23, 0x78,
+   0xea, 0x5e, 0xc0, 0xa4, 0x59, 0x4a, 0x98, 0x25,
+   0x20, 0x50, 0x54, 0x00, 0x00, 0x00, 0x81, 0x80,
+   0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
+   0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x30, 0x2a,
+   0x00, 0x98, 0x51, 0x00, 0x2a, 0x40, 0x30, 0x70,
+   0x13, 0x00, 0xbc, 0x63, 0x11, 0x00, 0x00, 0x1e,
+   0x00, 0x00, 0x00, 0xff, 0x00, 0x4c, 0x69, 0x6e,
+   0x75, 0x78, 0x20, 0x23, 0x30, 0x0a, 0x20, 0x20,
+   0x20, 0x20, 0x00, 0x00, 0x00, 0xfd, 0x00, 0x3b,
+   0x3d, 0x3e, 0x40, 0x0b, 0x00, 0x0a, 0x20, 0x20,
+   0x20, 0x20, 0x20, 0x20, 0x00, 0x00, 0x00, 0xfc,
+   0x00, 0x4c, 0x69, 0x6e, 0x75, 0x78, 0x20, 0x53,
+   0x58, 0x47, 0x41, 0x0a, 0x20, 0x20, 0x00, 0xa0,
+   },
+   {
+   0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00,
+   0x31, 0xd8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+   0x05, 0x16, 0x01, 0x03, 0x6d, 0x37, 0x29, 0x78,
+   0xea, 0x5e, 0xc0, 0xa4, 0x59, 0x4a, 0x98, 0x25,
+   0x20, 0x50, 0x54, 0x00, 0x00, 0x00, 0xa9, 0x40,
+   

[Intel-gfx] [PATCH i-g-t 3/4] lib: add igt_enable_connectors and igt_reset_connectors

2014-06-18 Thread Thomas Wood
igt_enable_connectors forces connectors to be enabled where doing so is
known to work well. igt_reset_connectors resets the force state on all
connectors.
---
 lib/igt_kms.c | 70 +++
 lib/igt_kms.h |  3 +++
 2 files changed, 73 insertions(+)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 86dec51..3fcb0da 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1148,3 +1148,73 @@ void igt_wait_for_vblank(int drm_fd, enum pipe pipe)
 
igt_assert(drmWaitVBlank(drm_fd, wait_vbl) == 0);
 }
+
+static void reset_connectors_at_exit(int sig)
+{
+   igt_reset_connectors();
+}
+
+/**
+ * igt_enable_connectors:
+ *
+ * Force connectors to be enabled where this is known to work well. Use
+ * #igt_reset_connectors to revert the changes.
+ *
+ * An exit handler is installed to ensure connectors are reset when the test
+ * exits.
+ */
+void igt_enable_connectors(void)
+{
+   drmModeRes *res;
+   drmModeConnector *c;
+   int drm_fd;
+
+   drm_fd = drm_open_any();
+
+   res = drmModeGetResources(drm_fd);
+
+   for (int i = 0; i  res-count_connectors; i++) {
+
+   c = drmModeGetConnector(drm_fd, res-connectors[i]);
+
+   /* don't attempt to force connectors that are already connected
+*/
+   if (c-connection == DRM_MODE_CONNECTED)
+   continue;
+
+   /* just enable VGA for now */
+   if (c-connector_type == DRM_MODE_CONNECTOR_VGA)
+   kmstest_force_connector(drm_fd, c, FORCE_CONNECTOR_ON);
+
+   drmModeFreeConnector(c);
+   }
+   close(drm_fd);
+
+   igt_install_exit_handler(reset_connectors_at_exit);
+}
+
+/**
+ * igt_reset_connectors:
+ *
+ * Remove any forced state from the connectors.
+ */
+void igt_reset_connectors(void)
+{
+   drmModeRes *res;
+   drmModeConnector *c;
+   int drm_fd;
+
+   drm_fd = drm_open_any();
+   res = drmModeGetResources(drm_fd);
+
+   for (int i = 0; i  res-count_connectors; i++) {
+
+   c = drmModeGetConnector(drm_fd, res-connectors[i]);
+
+   kmstest_force_connector(drm_fd, c, FORCE_CONNECTOR_UNSPECIFIED);
+
+   drmModeFreeConnector(c);
+   }
+
+   close(drm_fd);
+}
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 4cf74e8..d9b2c64 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -217,5 +217,8 @@ void igt_wait_for_vblank(int drm_fd, enum pipe pipe);
 
 #define IGT_FIXED(i,f) ((i)  16 | (f))
 
+void igt_enable_connectors(void);
+void igt_reset_connectors(void);
+
 #endif /* __IGT_KMS_H__ */
 
-- 
1.9.3

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


Re: [Intel-gfx] [PATCH 2/2] uxa: Mark the output as off before making pipe changes

2014-06-18 Thread Hans de Goede
Hi,

On 06/18/2014 03:14 PM, Chris Wilson wrote:
 On Wed, Jun 18, 2014 at 03:01:37PM +0200, Hans de Goede wrote:
 This is a partial backport of commit c6cd10f536, which makes the same
 change for sna, to avoid users still using uxa ending up with a blackscreen
 after plugging in an external monitor.

 Signed-off-by: Hans de Goede hdego...@redhat.com
 
 Do you want to reference your bugzilla here for background on the bug?

I wasn't sure, which is why I omitted it, but yes that probably makes sense,
please add these links to the commit msg:

https://bugzilla.redhat.com/show_bug.cgi?id=1032978
https://bugzilla.redhat.com/show_bug.cgi?id=1103806

Thanks,

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


Re: [Intel-gfx] [PATCH i-g-t 2/4] lib: add the ability to set an EDID data block on a connector

2014-06-18 Thread Daniel Vetter
On Wed, Jun 18, 2014 at 02:44:11PM +0100, Thomas Wood wrote:
 +/**
 + * kmstest_generic_edid:
 + * @EDID_XGA: 1024x768
 + * @EDID_SXGA: 1280x1024
 + * @EDID_UXGA: 1600x1200
 + * @EDID_WSXGA: 1680x1050
 + * @EDID_FHD: 1920x1080
 + * @MAX_EDIDS: Size of #generic_edid array
 + */
 +enum kmstest_generic_edid {
 + EDID_XGA,   /* 1024x768 */
 + EDID_SXGA,  /* 1280x1024 */
 + EDID_UXGA,  /* 1600x1200 */
 + EDID_WSXGA, /* 1680x1050 */
 + EDID_FHD,   /* 1920x1080 */

Hm, can't we have just one full hd edid which supports all the above
modes?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 1/2] drm/i915: Set M2_N2 registers during mode set

2014-06-18 Thread Vandana Kannan
For Gen  8, set M2_N2 registers on every mode set. This is required to make
sure M2_N2 registers are set during boot, resume from sleep for cross-
checking the state. The register is set only if DRRS is supported.

v2: Patch rebased

Signed-off-by: Vandana Kannan vandana.kan...@intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_drv.h  |  3 +++
 drivers/gpu/drm/i915/intel_display.c | 36 
 drivers/gpu/drm/i915/intel_dp.c  | 14 --
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 4 files changed, 36 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0640071..6bf6e00 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1989,6 +1989,9 @@ struct drm_i915_cmd_table {
 #define HAS_PSR(dev)   (IS_HASWELL(dev) || IS_BROADWELL(dev))
 #define HAS_RUNTIME_PM(dev)(IS_GEN6(dev) || IS_HASWELL(dev) || \
 IS_BROADWELL(dev) || IS_VALLEYVIEW(dev))
+#define HAS_DRRS(dev)  (to_i915(dev)-drrs.connector  \
+to_i915(dev)-drrs.connector- \
+panel.downclock_mode)
 
 #define INTEL_PCH_DEVICE_ID_MASK   0xff00
 #define INTEL_PCH_IBX_DEVICE_ID_TYPE   0x3b00
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5e8e711..fca5e02 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3987,8 +3987,12 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)
if (intel_crtc-config.has_pch_encoder)
intel_prepare_shared_dpll(intel_crtc);
 
-   if (intel_crtc-config.has_dp_encoder)
+   if (intel_crtc-config.has_dp_encoder) {
intel_dp_set_m_n(intel_crtc);
+   if (INTEL_INFO(dev)-gen  8  HAS_DRRS(dev))
+   intel_dp_set_m2_n2(intel_crtc,
+   intel_crtc-config.dp_m2_n2);
+   }
 
intel_set_pipe_timings(intel_crtc);
 
@@ -4097,8 +4101,12 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)
if (intel_crtc-active)
return;
 
-   if (intel_crtc-config.has_dp_encoder)
+   if (intel_crtc-config.has_dp_encoder) {
intel_dp_set_m_n(intel_crtc);
+   if (INTEL_INFO(dev)-gen  8  HAS_DRRS(dev))
+   intel_dp_set_m2_n2(intel_crtc,
+   intel_crtc-config.dp_m2_n2);
+   }
 
intel_set_pipe_timings(intel_crtc);
 
@@ -4614,8 +4622,12 @@ static void valleyview_crtc_enable(struct drm_crtc *crtc)
/* Set up the display plane register */
dspcntr = DISPPLANE_GAMMA_ENABLE;
 
-   if (intel_crtc-config.has_dp_encoder)
+   if (intel_crtc-config.has_dp_encoder) {
intel_dp_set_m_n(intel_crtc);
+   if (INTEL_INFO(dev)-gen  8  HAS_DRRS(dev))
+   intel_dp_set_m2_n2(intel_crtc,
+   intel_crtc-config.dp_m2_n2);
+   }
 
intel_set_pipe_timings(intel_crtc);
 
@@ -4706,8 +4718,12 @@ static void i9xx_crtc_enable(struct drm_crtc *crtc)
else
dspcntr |= DISPPLANE_SEL_PIPE_B;
 
-   if (intel_crtc-config.has_dp_encoder)
+   if (intel_crtc-config.has_dp_encoder) {
intel_dp_set_m_n(intel_crtc);
+   if (INTEL_INFO(dev)-gen  8  HAS_DRRS(dev))
+   intel_dp_set_m2_n2(intel_crtc,
+   intel_crtc-config.dp_m2_n2);
+   }
 
intel_set_pipe_timings(intel_crtc);
 
@@ -5494,6 +5510,18 @@ static void intel_dp_set_m_n(struct intel_crtc *crtc)
intel_cpu_transcoder_set_m_n(crtc, crtc-config.dp_m_n);
 }
 
+void intel_dp_set_m2_n2(struct intel_crtc *crtc, struct intel_link_m_n *m_n)
+{
+   struct drm_device *dev = crtc-base.dev;
+   struct drm_i915_private *dev_priv = dev-dev_private;
+   enum transcoder transcoder = crtc-config.cpu_transcoder;
+
+   I915_WRITE(PIPE_DATA_M2(transcoder), TU_SIZE(m_n-tu) | m_n-gmch_m);
+   I915_WRITE(PIPE_DATA_N2(transcoder), m_n-gmch_n);
+   I915_WRITE(PIPE_LINK_M2(transcoder), m_n-link_m);
+   I915_WRITE(PIPE_LINK_N2(transcoder), m_n-link_n);
+}
+
 static void vlv_update_pll(struct intel_crtc *crtc)
 {
u32 dpll, dpll_md;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 912e9c4..3394615 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -780,20 +780,6 @@ intel_dp_set_clock(struct intel_encoder *encoder,
}
 }
 
-static void
-intel_dp_set_m2_n2(struct intel_crtc *crtc, struct intel_link_m_n *m_n)
-{
-   struct drm_device *dev = crtc-base.dev;
-   struct drm_i915_private *dev_priv = dev-dev_private;
-   enum transcoder transcoder = crtc-config.cpu_transcoder;
-

Re: [Intel-gfx] [PATCH i-g-t 2/4] lib: add the ability to set an EDID data block on a connector

2014-06-18 Thread Thomas Wood
On 18 June 2014 14:57, Daniel Vetter dan...@ffwll.ch wrote:
 On Wed, Jun 18, 2014 at 02:44:11PM +0100, Thomas Wood wrote:
 +/**
 + * kmstest_generic_edid:
 + * @EDID_XGA: 1024x768
 + * @EDID_SXGA: 1280x1024
 + * @EDID_UXGA: 1600x1200
 + * @EDID_WSXGA: 1680x1050
 + * @EDID_FHD: 1920x1080
 + * @MAX_EDIDS: Size of #generic_edid array
 + */
 +enum kmstest_generic_edid {
 + EDID_XGA,   /* 1024x768 */
 + EDID_SXGA,  /* 1280x1024 */
 + EDID_UXGA,  /* 1600x1200 */
 + EDID_WSXGA, /* 1680x1050 */
 + EDID_FHD,   /* 1920x1080 */

 Hm, can't we have just one full hd edid which supports all the above
 modes?


Yes, although for kms_force_connector I actually wanted two different
EDIDs to make sure overwriting the value worked correctly.


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


Re: [Intel-gfx] [PATCH i-g-t 1/4] lib: add function to change connector states

2014-06-18 Thread Chris Wilson
On Wed, Jun 18, 2014 at 02:44:10PM +0100, Thomas Wood wrote:
 +static int get_card_number(int fd)
 +{
 + struct stat buf;
 +
 + /* find the minor number of the device */
 + fstat(fd, buf);
 +
 + return minor(buf.st_rdev);

This mixes in rendernode/controlnode tags.
-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 v5 2/2] drm/i915: State readout and cross-checking for dp_m2_n2

2014-06-18 Thread Vandana Kannan
On Jun-18-2014 4:16 PM, Daniel Vetter wrote:
 On Wed, Jun 18, 2014 at 10:11:20AM +0530, Vandana Kannan wrote:
 On Jun-17-2014 10:12 PM, Daniel Vetter wrote:
 On Tue, Jun 17, 2014 at 05:52:24PM +0300, Jani Nikula wrote:
 On Mon, 16 Jun 2014, Vandana Kannan vandana.kan...@intel.com wrote:
 On Jun-13-2014 7:42 PM, Jani Nikula wrote:
 On Thu, 22 May 2014, Vandana Kannan vandana.kan...@intel.com wrote:
 Adding relevant read out comparison code, in check_crtc_state, for the 
 new
 member of crtc_config, dp_m2_n2, which was introduced to store link_m_n
 values for a DP downclock mode (if available). Suggested by Daniel.

 v2: Changed patch title.
 Daniel's review comments incorporated.
 Added relevant state readout code for M2_N2. dp_m2_n2 comparison to be 
 done
 only when high RR is not in use (This is because alternate m_n register
 programming will be done only when low RR is being used).

 v3: Modified call to get_m2_n2 which had dp_m_n as param by mistake.
 Compare dp_m_n and dp_m2_n2 for gen 7 and below. compare the structures
 based on DRRS state for gen 8 and above.
 Save and restore M2 N2 registers for gen 7 and below

 v4: For Gen=8, check M_N registers against dp_m_n and dp_m2_n2 as 
 there is
 only one set of M_N registers

 v5: Removed the chunk which saves and restores M2_N2 registers. Modified
 get_m_n() to get M2_N2 registers as well. Modified the macro which 
 compares
 hw.dp_m_n against sw.dp_m2_n2/sw.dp_m_n for gen  8.

 Signed-off-by: Vandana Kannan vandana.kan...@intel.com
 Cc: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  drivers/gpu/drm/i915/intel_display.c | 68 
 +++-
  1 file changed, 60 insertions(+), 8 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index cf3ad87..d593897 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -6945,7 +6945,8 @@ static void intel_pch_transcoder_get_m_n(struct 
 intel_crtc *crtc,
  
  static void intel_cpu_transcoder_get_m_n(struct intel_crtc *crtc,
  enum transcoder transcoder,
 -struct intel_link_m_n *m_n)
 +struct intel_link_m_n *m_n,
 +struct intel_link_m_n *m2_n2)
  {
 struct drm_device *dev = crtc-base.dev;
 struct drm_i915_private *dev_priv = dev-dev_private;
 @@ -6959,6 +6960,15 @@ static void intel_cpu_transcoder_get_m_n(struct 
 intel_crtc *crtc,
 m_n-gmch_n = I915_READ(PIPE_DATA_N1(transcoder));
 m_n-tu = ((I915_READ(PIPE_DATA_M1(transcoder))
  TU_SIZE_MASK)  TU_SIZE_SHIFT) + 1;
 +   if (m2_n2  INTEL_INFO(dev)-gen  8) {
 +   m2_n2-link_m = 
 I915_READ(PIPE_LINK_M2(transcoder));
 +   m2_n2-link_n = 
 I915_READ(PIPE_LINK_N2(transcoder));
 +   m2_n2-gmch_m = 
 I915_READ(PIPE_DATA_M2(transcoder))
 +~TU_SIZE_MASK;
 +   m2_n2-gmch_n = 
 I915_READ(PIPE_DATA_N2(transcoder));
 +   m2_n2-tu = 
 ((I915_READ(PIPE_DATA_M2(transcoder))
 +TU_SIZE_MASK)  
 TU_SIZE_SHIFT) + 1;
 +   }
 } else {
 m_n-link_m = I915_READ(PIPE_LINK_M_G4X(pipe));
 m_n-link_n = I915_READ(PIPE_LINK_N_G4X(pipe));
 @@ -6977,14 +6987,15 @@ void intel_dp_get_m_n(struct intel_crtc *crtc,
 intel_pch_transcoder_get_m_n(crtc, 
 pipe_config-dp_m_n);
 else
 intel_cpu_transcoder_get_m_n(crtc, 
 pipe_config-cpu_transcoder,
 -pipe_config-dp_m_n);
 +pipe_config-dp_m_n,
 +pipe_config-dp_m2_n2);
  }
  
  static void ironlake_get_fdi_m_n_config(struct intel_crtc *crtc,
 struct intel_crtc_config 
 *pipe_config)
  {
 intel_cpu_transcoder_get_m_n(crtc, pipe_config-cpu_transcoder,
 -pipe_config-fdi_m_n);
 +pipe_config-fdi_m_n, NULL);
  }
  
  static void ironlake_get_pfit_config(struct intel_crtc *crtc,
 @@ -9485,6 +9496,15 @@ static void intel_dump_pipe_config(struct 
 intel_crtc *crtc,
   pipe_config-dp_m_n.gmch_m, 
 pipe_config-dp_m_n.gmch_n,
   pipe_config-dp_m_n.link_m, 
 pipe_config-dp_m_n.link_n,
   pipe_config-dp_m_n.tu);
 +
 +   DRM_DEBUG_KMS(dp: %i, gmch_m2: %u, gmch_n2: %u, link_m2: %u, 
 link_n2: %u, tu2: %u\n,
 + pipe_config-has_dp_encoder,
 + pipe_config-dp_m2_n2.gmch_m,
 + pipe_config-dp_m2_n2.gmch_n,
 + pipe_config-dp_m2_n2.link_m,
 + 

[Intel-gfx] [PATCH v6 2/2] drm/i915: State readout and cross-checking for dp_m2_n2

2014-06-18 Thread Vandana Kannan
Adding relevant read out comparison code, in check_crtc_state, for the new
member of crtc_config, dp_m2_n2, which was introduced to store link_m_n
values for a DP downclock mode (if available). Suggested by Daniel.

v2: Changed patch title.
Daniel's review comments incorporated.
Added relevant state readout code for M2_N2. dp_m2_n2 comparison to be done
only when high RR is not in use (This is because alternate m_n register
programming will be done only when low RR is being used).

v3: Modified call to get_m2_n2 which had dp_m_n as param by mistake.
Compare dp_m_n and dp_m2_n2 for gen 7 and below. compare the structures
based on DRRS state for gen 8 and above.
Save and restore M2 N2 registers for gen 7 and below

v4: For Gen=8, check M_N registers against dp_m_n and dp_m2_n2 as there is
only one set of M_N registers

v5: Removed the chunk which saves and restores M2_N2 registers. Modified
get_m_n() to get M2_N2 registers as well. Modified the macro which compares
hw.dp_m_n against sw.dp_m2_n2/sw.dp_m_n for gen  8.

v6: Added check to compare dp_m2_n2 only when DRRS is enabled

Signed-off-by: Vandana Kannan vandana.kan...@intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Jani Nikula jani.nik...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_display.c | 70 +++-
 1 file changed, 62 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index fca5e02..6c74ef6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7116,7 +7116,8 @@ static void intel_pch_transcoder_get_m_n(struct 
intel_crtc *crtc,
 
 static void intel_cpu_transcoder_get_m_n(struct intel_crtc *crtc,
 enum transcoder transcoder,
-struct intel_link_m_n *m_n)
+struct intel_link_m_n *m_n,
+struct intel_link_m_n *m2_n2)
 {
struct drm_device *dev = crtc-base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -7130,6 +7131,15 @@ static void intel_cpu_transcoder_get_m_n(struct 
intel_crtc *crtc,
m_n-gmch_n = I915_READ(PIPE_DATA_N1(transcoder));
m_n-tu = ((I915_READ(PIPE_DATA_M1(transcoder))
 TU_SIZE_MASK)  TU_SIZE_SHIFT) + 1;
+   if (m2_n2  INTEL_INFO(dev)-gen  8) {
+   m2_n2-link_m = I915_READ(PIPE_LINK_M2(transcoder));
+   m2_n2-link_n = I915_READ(PIPE_LINK_N2(transcoder));
+   m2_n2-gmch_m = I915_READ(PIPE_DATA_M2(transcoder))
+~TU_SIZE_MASK;
+   m2_n2-gmch_n = I915_READ(PIPE_DATA_N2(transcoder));
+   m2_n2-tu = ((I915_READ(PIPE_DATA_M2(transcoder))
+TU_SIZE_MASK)  TU_SIZE_SHIFT) + 1;
+   }
} else {
m_n-link_m = I915_READ(PIPE_LINK_M_G4X(pipe));
m_n-link_n = I915_READ(PIPE_LINK_N_G4X(pipe));
@@ -7148,14 +7158,15 @@ void intel_dp_get_m_n(struct intel_crtc *crtc,
intel_pch_transcoder_get_m_n(crtc, pipe_config-dp_m_n);
else
intel_cpu_transcoder_get_m_n(crtc, pipe_config-cpu_transcoder,
-pipe_config-dp_m_n);
+pipe_config-dp_m_n,
+pipe_config-dp_m2_n2);
 }
 
 static void ironlake_get_fdi_m_n_config(struct intel_crtc *crtc,
struct intel_crtc_config *pipe_config)
 {
intel_cpu_transcoder_get_m_n(crtc, pipe_config-cpu_transcoder,
-pipe_config-fdi_m_n);
+pipe_config-fdi_m_n, NULL);
 }
 
 static void ironlake_get_pfit_config(struct intel_crtc *crtc,
@@ -9755,6 +9766,15 @@ static void intel_dump_pipe_config(struct intel_crtc 
*crtc,
  pipe_config-dp_m_n.gmch_m, pipe_config-dp_m_n.gmch_n,
  pipe_config-dp_m_n.link_m, pipe_config-dp_m_n.link_n,
  pipe_config-dp_m_n.tu);
+
+   DRM_DEBUG_KMS(dp: %i, gmch_m2: %u, gmch_n2: %u, link_m2: %u, link_n2: 
%u, tu2: %u\n,
+ pipe_config-has_dp_encoder,
+ pipe_config-dp_m2_n2.gmch_m,
+ pipe_config-dp_m2_n2.gmch_n,
+ pipe_config-dp_m2_n2.link_m,
+ pipe_config-dp_m2_n2.link_n,
+ pipe_config-dp_m2_n2.tu);
+
DRM_DEBUG_KMS(requested mode:\n);
drm_mode_debug_printmodeline(pipe_config-requested_mode);
DRM_DEBUG_KMS(adjusted mode:\n);
@@ -10135,6 +10155,22 @@ intel_pipe_config_compare(struct drm_device *dev,
return false; \
}
 
+/* This is required for BDW+ where there is only one set of registers 

Re: [Intel-gfx] [PATCH 12/16] drm/i915: Use new frontbuffer bits to increase pll clock

2014-06-18 Thread Chris Wilson
On Wed, Jun 18, 2014 at 01:59:13PM +0200, Daniel Vetter wrote:
 The downclocking checks a few more things, so not that simple to
 convert. Also, this should get unified with the drrs handling and also
 use the locking of that. Otoh the drrs locking is about as hapzardous
 as no locking, at least on first sight.
 
 For easier conversion ditch the upclocking on unload - we'll turn off
 everything anyway.
 
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
-Chris

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


Re: [Intel-gfx] [PATCH] drm/i915: Print obj-frontbuffer_bits in debugfs output

2014-06-18 Thread Chris Wilson
On Wed, Jun 18, 2014 at 02:46:49PM +0200, Daniel Vetter wrote:
 Can be useful to figure out imbalances and bugs in the frontbuffer
 tracking.
 
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk

I don't think this will be useful for error state. All the failure modes
here I think relate to display coherency, unless you can think of
something else?
-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 v2 1/2] drm/i915: Set M2_N2 registers during mode set

2014-06-18 Thread Daniel Vetter
On Wed, Jun 18, 2014 at 07:47:24PM +0530, Vandana Kannan wrote:
 For Gen  8, set M2_N2 registers on every mode set. This is required to make
 sure M2_N2 registers are set during boot, resume from sleep for cross-
 checking the state. The register is set only if DRRS is supported.
 
 v2: Patch rebased
 
 Signed-off-by: Vandana Kannan vandana.kan...@intel.com
 Cc: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  drivers/gpu/drm/i915/i915_drv.h  |  3 +++
  drivers/gpu/drm/i915/intel_display.c | 36 
 
  drivers/gpu/drm/i915/intel_dp.c  | 14 --
  drivers/gpu/drm/i915/intel_drv.h |  1 +
  4 files changed, 36 insertions(+), 18 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index 0640071..6bf6e00 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -1989,6 +1989,9 @@ struct drm_i915_cmd_table {
  #define HAS_PSR(dev) (IS_HASWELL(dev) || IS_BROADWELL(dev))
  #define HAS_RUNTIME_PM(dev)  (IS_GEN6(dev) || IS_HASWELL(dev) || \
IS_BROADWELL(dev) || IS_VALLEYVIEW(dev))
 +#define HAS_DRRS(dev)(to_i915(dev)-drrs.connector  \
 +  to_i915(dev)-drrs.connector- \
 +  panel.downclock_mode)

Didn't spot this the first time around, but HAS_* macros should be chip
invariants, so no runtime-dependent pointer chasing and similar things
here. Which also means you can't use this in the pipe config checks.
Solution for that is to set pipe_config-has_drrs bool when you set the
2nd set of dp m/n values in the pipe_config in intel_dp_compute config.

My apologies that this takes so long and that the documentation for our
pipe-config infrastructure is so bad (= doesn't exist). I'm slowly working
towards the goal of document all the different subsystems in our driver.

Thanks, Daniel

  
  #define INTEL_PCH_DEVICE_ID_MASK 0xff00
  #define INTEL_PCH_IBX_DEVICE_ID_TYPE 0x3b00
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 5e8e711..fca5e02 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -3987,8 +3987,12 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)
   if (intel_crtc-config.has_pch_encoder)
   intel_prepare_shared_dpll(intel_crtc);
  
 - if (intel_crtc-config.has_dp_encoder)
 + if (intel_crtc-config.has_dp_encoder) {
   intel_dp_set_m_n(intel_crtc);
 + if (INTEL_INFO(dev)-gen  8  HAS_DRRS(dev))
 + intel_dp_set_m2_n2(intel_crtc,
 + intel_crtc-config.dp_m2_n2);
 + }
  
   intel_set_pipe_timings(intel_crtc);
  
 @@ -4097,8 +4101,12 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)
   if (intel_crtc-active)
   return;
  
 - if (intel_crtc-config.has_dp_encoder)
 + if (intel_crtc-config.has_dp_encoder) {
   intel_dp_set_m_n(intel_crtc);
 + if (INTEL_INFO(dev)-gen  8  HAS_DRRS(dev))
 + intel_dp_set_m2_n2(intel_crtc,
 + intel_crtc-config.dp_m2_n2);
 + }
  
   intel_set_pipe_timings(intel_crtc);
  
 @@ -4614,8 +4622,12 @@ static void valleyview_crtc_enable(struct drm_crtc 
 *crtc)
   /* Set up the display plane register */
   dspcntr = DISPPLANE_GAMMA_ENABLE;
  
 - if (intel_crtc-config.has_dp_encoder)
 + if (intel_crtc-config.has_dp_encoder) {
   intel_dp_set_m_n(intel_crtc);
 + if (INTEL_INFO(dev)-gen  8  HAS_DRRS(dev))
 + intel_dp_set_m2_n2(intel_crtc,
 + intel_crtc-config.dp_m2_n2);
 + }
  
   intel_set_pipe_timings(intel_crtc);
  
 @@ -4706,8 +4718,12 @@ static void i9xx_crtc_enable(struct drm_crtc *crtc)
   else
   dspcntr |= DISPPLANE_SEL_PIPE_B;
  
 - if (intel_crtc-config.has_dp_encoder)
 + if (intel_crtc-config.has_dp_encoder) {
   intel_dp_set_m_n(intel_crtc);
 + if (INTEL_INFO(dev)-gen  8  HAS_DRRS(dev))
 + intel_dp_set_m2_n2(intel_crtc,
 + intel_crtc-config.dp_m2_n2);
 + }
  
   intel_set_pipe_timings(intel_crtc);
  
 @@ -5494,6 +5510,18 @@ static void intel_dp_set_m_n(struct intel_crtc *crtc)
   intel_cpu_transcoder_set_m_n(crtc, crtc-config.dp_m_n);
  }
  
 +void intel_dp_set_m2_n2(struct intel_crtc *crtc, struct intel_link_m_n *m_n)
 +{
 + struct drm_device *dev = crtc-base.dev;
 + struct drm_i915_private *dev_priv = dev-dev_private;
 + enum transcoder transcoder = crtc-config.cpu_transcoder;
 +
 + I915_WRITE(PIPE_DATA_M2(transcoder), TU_SIZE(m_n-tu) | m_n-gmch_m);
 + I915_WRITE(PIPE_DATA_N2(transcoder), m_n-gmch_n);
 + I915_WRITE(PIPE_LINK_M2(transcoder), m_n-link_m);
 + 

Re: [Intel-gfx] [PATCH] drm/i915: Introduce accurate frontbuffer tracking

2014-06-18 Thread Daniel Vetter
On Wed, Jun 18, 2014 at 03:55:44PM +0100, Chris Wilson wrote:
 On Wed, Jun 18, 2014 at 03:01:25PM +0200, Daniel Vetter wrote:
  +void i915_gem_update_fb_bits(struct drm_i915_gem_object *old,
  +struct drm_i915_gem_object *new,
  +unsigned frontbuffer_bits);
  +
 
 Time to be a nuisance:
 
 i915_gem_object_track_fb()
 
 The key part is that is operates on the object. The other is just to try
 and shorten the name as compensation.

Hm, I've thought the i915_gem part is a giveaway - I'm not too fond of the
i915_gem_obj prefix since it's so long ...

  @@ -1062,6 +1065,7 @@ intel_disable_plane(struct drm_plane *plane)
  struct drm_device *dev = plane-dev;
  struct intel_plane *intel_plane = to_intel_plane(plane);
  struct intel_crtc *intel_crtc;
  +   enum pipe pipe;
   
  if (!plane-fb)
  return 0;
  @@ -1070,6 +1074,7 @@ intel_disable_plane(struct drm_plane *plane)
  return -EINVAL;
   
  intel_crtc = to_intel_crtc(plane-crtc);
  +   pipe = intel_crtc-pipe;
   
  if (intel_crtc-active) {
  bool primary_was_enabled = intel_crtc-primary_enabled;
  @@ -1088,6 +1093,8 @@ intel_disable_plane(struct drm_plane *plane)
   
  mutex_lock(dev-struct_mutex);
  intel_unpin_fb_obj(intel_plane-obj);
  +   i915_gem_update_fb_bits(intel_plane-obj, NULL,
  +   INTEL_FRONTBUFFER_SPRITE(pipe));
 
 Introducing a local here for a one off, or was checkpatch in an angry
 mood with INTEL_FRONTBUFFER_SPRITE(intel_crtc-pipe) ?

Just a case of shortening the line a bit, it looks terribly ugly imo. I
hope we can prettify this once we have a bit more unified nuclear flip
logic for all planes.

 That's all I spotted, the logic looks fine. But just remind me,
 i915_gem_object_track_fb() did do a lockdep_assert_held(dev-struct_mutex)?

Yeah, both when new or old are non-NULL, as a prep for per-object locking.
If we ever get there ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Properly track domain of the fbcon fb

2014-06-18 Thread Daniel Vetter
On Wed, Jun 18, 2014 at 03:57:49PM +0100, Chris Wilson wrote:
 On Wed, Jun 18, 2014 at 03:05:19PM +0200, Daniel Vetter wrote:
  X could end up putting the fbcon fb into other domains, e.g.
  for smooth take-overs. Also we want this for accurate frontbuffer
  tracking: The set_config is an implicit flush and will re-enable
  psr and similar features, so we need to bring the bo back into
  the gtt domain.
  
  Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
  ---
   drivers/gpu/drm/i915/intel_fbdev.c | 21 -
   1 file changed, 20 insertions(+), 1 deletion(-)
  
  diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
  b/drivers/gpu/drm/i915/intel_fbdev.c
  index 27975c3e21c5..53c50240d1c2 100644
  --- a/drivers/gpu/drm/i915/intel_fbdev.c
  +++ b/drivers/gpu/drm/i915/intel_fbdev.c
  @@ -43,10 +43,29 @@
   #include drm/i915_drm.h
   #include i915_drv.h
   
  +static int intel_fbdev_set_par(struct fb_info *info)
  +{
  +   struct drm_fb_helper *fb_helper = info-par;
  +   struct intel_fbdev *ifbdev =
  +   container_of(fb_helper, struct intel_fbdev, helper);
  +   int ret;
  +
  +   ret = drm_fb_helper_set_par(info);
  +
  +   if (ret == 0) {
 
 Add a comment here saying you are happy with the potential deadlock,
 double-fault and what not, and I'll accept it with provisons that I'll
 still worry that this will explode in our faces.

/*
 * FIXME: fbdev presumes that all callbacks also work from atomic contexts
 * and relies on that for emergency oops printing. KMS totally doesn't do
 * that and the locking here is by far not the only place this goes wrong.
 * Ignore this for now until we solve this for real.
 */

Like this?
-Daniel
 
  +   mutex_lock(fb_helper-dev-struct_mutex);
  +   ret = i915_gem_object_set_to_gtt_domain(ifbdev-fb-obj,
  +   true);
  +   mutex_unlock(fb_helper-dev-struct_mutex);
  +   }
  +
  +   return ret;
  +}
  +
   static struct fb_ops intelfb_ops = {
  .owner = THIS_MODULE,
  .fb_check_var = drm_fb_helper_check_var,
  -   .fb_set_par = drm_fb_helper_set_par,
  +   .fb_set_par = intel_fbdev_set_par,
  .fb_fillrect = cfb_fillrect,
  .fb_copyarea = cfb_copyarea,
  .fb_imageblit = cfb_imageblit,
  -- 
  2.0.0
  
  ___
  Intel-gfx mailing list
  Intel-gfx@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/intel-gfx
  
 
 -- 
 Chris Wilson, Intel Open Source Technology Centre
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


Re: [Intel-gfx] [PATCH] drm/i915: Introduce accurate frontbuffer tracking

2014-06-18 Thread Chris Wilson
On Wed, Jun 18, 2014 at 05:55:31PM +0200, Daniel Vetter wrote:
 On Wed, Jun 18, 2014 at 03:55:44PM +0100, Chris Wilson wrote:
  On Wed, Jun 18, 2014 at 03:01:25PM +0200, Daniel Vetter wrote:
   +void i915_gem_update_fb_bits(struct drm_i915_gem_object *old,
   +  struct drm_i915_gem_object *new,
   +  unsigned frontbuffer_bits);
   +
  
  Time to be a nuisance:
  
  i915_gem_object_track_fb()
  
  The key part is that is operates on the object. The other is just to try
  and shorten the name as compensation.
 
 Hm, I've thought the i915_gem part is a giveaway - I'm not too fond of the
 i915_gem_obj prefix since it's so long ...

Until we make the wholehearted change, stick to convention.

i915_bo_* coccinelle script?
-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: Print obj-frontbuffer_bits in debugfs output

2014-06-18 Thread Daniel Vetter
On Wed, Jun 18, 2014 at 03:50:20PM +0100, Chris Wilson wrote:
 On Wed, Jun 18, 2014 at 02:46:49PM +0200, Daniel Vetter wrote:
  Can be useful to figure out imbalances and bugs in the frontbuffer
  tracking.
  
  Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 
 Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
 
 I don't think this will be useful for error state. All the failure modes
 here I think relate to display coherency, unless you can think of
 something else?

No, should really only be relevant for display coherency bugs, not unhappy
gpus. I think the biggest risk there is that flushing at inopportune times
might upset the hardware. But since these operations happen at few times
per frame we can't dump a tracing stream of debug noise by default.

So nothing to add here until we have dynamic debugging or some other means
for more fine-grained debug logging.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


  1   2   >