Re: [Intel-gfx] [PATCH] drm/i915: select MMU_NOTIFIER
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
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
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
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
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()
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()
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()
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
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
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()
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
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
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
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
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.
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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()
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
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
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
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()
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()
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
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
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
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()
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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