Re: [Intel-gfx] [PATCH 02/10] drm/i915: Drop some unused fields from i915_execbuffer_params
On ti, 2017-01-31 at 13:15 +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin> > dev, file and ctx are unused. > > Signed-off-by: Tvrtko Ursulin Could either squash this to the previous commit, or have this before previous commit, to avoid going through removed code in previous patch (easier for rebasing etc.) Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/10] drm/i915: Tidy execbuf_submit
On ti, 2017-01-31 at 13:15 +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin> > Use a local variable for storing the request and engine > and at the same time drop the engine field from > i915_execbuffer_params since it is available from the > request. > > textdata bss dec hex filename > 1085402 263982628 1114428 11013c i915.ko.0 > 1085354 263982628 1114380 11010c i915.ko.1 > > Signed-off-by: Tvrtko Ursulin Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/10] drm/i915: Tidy i915_gem_do_execbuffer
On ti, 2017-01-31 at 13:15 +, Tvrtko Ursulin wrote: > > From: Tvrtko Ursulin> > Instead of sprinkling around usage and initialization of > i915_execbuffer_params we can consolidate it just before > execbuf_submit for maintability and readability. > > That way we can also drop the memset since it becomes > easy to spot we initialize all the fields. > > textdata bss dec hex filename > 1085466 263982628 1114492 11017c i915.ko.0 > 1085402 263982628 1114428 11013c i915.ko.1 > > Signed-off-by: Tvrtko Ursulin > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > @@ -50,14 +50,14 @@ > #define BATCH_OFFSET_BIAS (256*1024) > > struct i915_execbuffer_params { > - struct drm_device *dev; > - struct drm_file *file; > - struct i915_vma *batch; > - u32 dispatch_flags; > - u32 args_batch_start_offset; > - struct intel_engine_cs *engine; > - struct i915_gem_context *ctx; > - struct drm_i915_gem_request *request; > + struct drm_device *dev; > + struct drm_file *file; > + struct i915_vma *batch; > + u32 dispatch_flags; > + u32 batch_start; > + struct intel_engine_cs *engine; > + struct i915_gem_context *ctx; > + struct drm_i915_gem_request *request; > }; You could just drop the pretty spaces totally. Otherwise, when something gets changed, the whole struct has to be re-indented. Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/bxt: Enable IPC support
Hi, On Tuesday 31 January 2017 09:26 PM, Ander Conselvan De Oliveira wrote: On Tue, 2017-01-31 at 20:27 +0530, Mahesh Kumar wrote: This patch adds IPC support for platforms. This patch enables IPC only for BXT/KBL platform as for SKL recommendation is to keep it disabled. IPC (Isochronous Priority Control) is the hardware feature, which dynamically controls the memory read priority of Display. When IPC is enabled, plane read requests are sent at high priority until filling above the transition watermark, then the requests are sent at lower priority until dropping below the level 0 watermark. The lower priority requests allow other memory clients to have better memory access. When IPC is disabled, all plane read requests are sent at high priority. Changes since V1: - Remove commandline parameter to disable ipc - Address Paulo's comments Changes since V2: - Address review comments - Set ipc_enabled flag Changes since V3: - move ipc_enabled flag assignment inside intel_ipc_enable function Changes since V4: - Re-enable IPC after suspend/resume Signed-off-by: Mahesh Kumar--- drivers/gpu/drm/i915/i915_drv.c | 4 +++- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_display.c | 1 + drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_pm.c | 16 5 files changed, 22 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index ca168b22ee26..5f3b22946971 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1246,7 +1246,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct pci_device_id *ent) intel_runtime_pm_enable(dev_priv); - dev_priv->ipc_enabled = false; + intel_enable_ipc(dev_priv); /* Everything is in place, we can now relax! */ DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n", @@ -2439,6 +2439,8 @@ static int intel_runtime_resume(struct device *kdev) enable_rpm_wakeref_asserts(dev_priv); + intel_enable_ipc(dev_priv); + if (ret) DRM_ERROR("Runtime resume failed, disabling it (%d)\n", ret); else diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 72f9f36ae5ce..36e0a33f876c 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -6466,6 +6466,7 @@ enum { #define DISP_FBC_WM_DIS (1<<15) #define DISP_ARB_CTL2 _MMIO(0x45004) #define DISP_DATA_PARTITION_5_6 (1<<6) +#define DISP_IPC_ENABLE (1<<3) #define DBUF_CTL _MMIO(0x45008) #define DBUF_POWER_REQUEST (1<<31) #define DBUF_POWER_STATE (1<<30) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 0bf8e1bfbe7e..1aa708b6f55e 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -17222,6 +17222,7 @@ void intel_display_resume(struct drm_device *dev) if (!ret) ret = __intel_display_resume(dev, state); + intel_enable_ipc(dev_priv); drm_modeset_drop_locks(); drm_modeset_acquire_fini(); mutex_unlock(>mode_config.mutex); diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 0cec0013ace0..ab7423b0a41b 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -1787,6 +1787,7 @@ bool skl_ddb_allocation_overlaps(const struct skl_ddb_entry **entries, uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state *pipe_config); bool ilk_disable_lp_wm(struct drm_device *dev); int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6); +void intel_enable_ipc(struct drm_i915_private *dev_priv); static inline int intel_enable_rc6(void) { return i915.enable_rc6; diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 249623d45be0..16e83efa1118 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4667,6 +4667,22 @@ void intel_update_watermarks(struct intel_crtc *crtc) dev_priv->display.update_wm(crtc); } +void intel_enable_ipc(struct drm_i915_private *dev_priv) +{ + u32 val; + + dev_priv->ipc_enabled = false; + if (!(IS_BROXTON(dev_priv) || IS_KABYLAKE(dev_priv))) + return; Do we want this enabled in Geminilake? Ander yes, we need to enable this for Gemnilake also, but we need "Transition WM" patch, before enabling it for GLK. -Mahesh + + val = I915_READ(DISP_ARB_CTL2); + + val |= DISP_IPC_ENABLE; + + I915_WRITE(DISP_ARB_CTL2, val); + dev_priv->ipc_enabled = true; +} + /* * Lock protecting IPS related data structures */ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org
[Intel-gfx] [PATCH i-g-t v4 03/11] lib/igt_kms: export properties names
From: Gustavo PadovanSigned-off-by: Gustavo Padovan Signed-off-by: Robert Foss --- lib/igt_kms.c | 6 +++--- lib/igt_kms.h | 23 +++ 2 files changed, 26 insertions(+), 3 deletions(-) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index 41acce45..142658a6 100644 --- a/lib/igt_kms.c +++ b/lib/igt_kms.c @@ -157,7 +157,7 @@ const unsigned char* igt_kms_get_base_edid(void) #define EDID_NAME alt_edid #include "igt_edid_template.h" -static const char *igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = { +const char *igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = { "SRC_X", "SRC_Y", "SRC_W", @@ -172,7 +172,7 @@ static const char *igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = { "rotation" }; -static const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = { +const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = { "background_color", "CTM", "DEGAMMA_LUT", @@ -181,7 +181,7 @@ static const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = { "ACTIVE" }; -static const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = { +const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = { "scaling mode", "CRTC_ID" }; diff --git a/lib/igt_kms.h b/lib/igt_kms.h index 25626187..00e0dc68 100644 --- a/lib/igt_kms.h +++ b/lib/igt_kms.h @@ -97,12 +97,28 @@ enum igt_atomic_crtc_properties { IGT_NUM_CRTC_PROPS }; +/** + * igt_crtc_prop_names + * + * igt_crtc_prop_names contains a list of crtc property names, + * as indexed by the igt_atomic_crtc_properties enum. + */ +extern const char *igt_crtc_prop_names[]; + enum igt_atomic_connector_properties { IGT_CONNECTOR_SCALING_MODE = 0, IGT_CONNECTOR_CRTC_ID, IGT_NUM_CONNECTOR_PROPS }; +/** + * igt_connector_prop_names + * + * igt_connector_prop_names contains a list of crtc property names, + * as indexed by the igt_atomic_connector_properties enum. + */ +extern const char *igt_connector_prop_names[]; + struct kmstest_connector_config { drmModeCrtc *crtc; drmModeConnector *connector; @@ -237,6 +253,13 @@ enum igt_atomic_plane_properties { IGT_NUM_PLANE_PROPS }; +/** + * igt_plane_prop_names + * + * igt_plane_prop_names contains a list of crtc property names, + * as indexed by the igt_atomic_plane_properties enum. + */ +extern const char *igt_plane_prop_names[]; typedef struct igt_display igt_display_t; typedef struct igt_pipe igt_pipe_t; -- 2.11.0.453.g787f75f05 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v4 11/11] lib/igt_kms: Added igt_pipe_get_last_out_fence()
Added the igt_pipe_get_last_out_fence() helper function that wraps accesses to pipe->fence_out. Signed-off-by: Robert Foss--- lib/igt_kms.c | 8 lib/igt_kms.h | 1 + 2 files changed, 9 insertions(+) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index a1eaf411..b99b0398 100644 --- a/lib/igt_kms.c +++ b/lib/igt_kms.c @@ -1938,6 +1938,14 @@ static igt_output_t *igt_pipe_get_output(igt_pipe_t *pipe) return NULL; } +int igt_pipe_get_last_out_fence(igt_pipe_t *pipe) +{ + int fd = (int) pipe->out_fence_fd; + pipe->out_fence_fd = -1; + + return fd; +} + bool igt_pipe_get_property(igt_pipe_t *pipe, const char *name, uint32_t *prop_id, uint64_t *value, drmModePropertyPtr *prop) diff --git a/lib/igt_kms.h b/lib/igt_kms.h index 6754d00e..8fb327d9 100644 --- a/lib/igt_kms.h +++ b/lib/igt_kms.h @@ -390,6 +390,7 @@ igt_plane_t *igt_output_get_plane_type(igt_output_t *output, int plane_type); igt_output_t *igt_output_from_connector(igt_display_t *display, drmModeConnector *connector); igt_plane_t *igt_pipe_get_plane_type(igt_pipe_t *pipe, int plane_type); +int igt_pipe_get_last_out_fence(igt_pipe_t *pipe); bool igt_pipe_get_property(igt_pipe_t *pipe, const char *name, uint32_t *prop_id, uint64_t *value, drmModePropertyPtr *prop); -- 2.11.0.453.g787f75f05 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v4 02/11] lib/igt_kms: move igt_kms_get_alt_edid() to the right place
From: Gustavo PadovanSigned-off-by: Gustavo Padovan Signed-off-by: Robert Foss --- lib/igt_kms.c | 34 +- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index 4ba6316d..41acce45 100644 --- a/lib/igt_kms.c +++ b/lib/igt_kms.c @@ -157,23 +157,6 @@ const unsigned char* igt_kms_get_base_edid(void) #define EDID_NAME alt_edid #include "igt_edid_template.h" -/** - * igt_kms_get_alt_edid: - * - * Get an alternate edid block, which includes the following modes: - * - * - 1400x1050 60Hz - * - 1920x1080 60Hz - * - 1280x720 60Hz - * - 1024x768 60Hz - * - 800x600 60Hz - * - 640x480 60Hz - * - * This can be extended with further features using functions such as - * #kmstest_edid_add_3d. - * - * Returns: an alternate edid block - */ static const char *igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = { "SRC_X", "SRC_Y", @@ -301,6 +284,23 @@ igt_atomic_fill_pipe_props(igt_display_t *display, igt_pipe_t *pipe, drmModeFreeObjectProperties(props); } +/** + * igt_kms_get_alt_edid: + * + * Get an alternate edid block, which includes the following modes: + * + * - 1400x1050 60Hz + * - 1920x1080 60Hz + * - 1280x720 60Hz + * - 1024x768 60Hz + * - 800x600 60Hz + * - 640x480 60Hz + * + * This can be extended with further features using functions such as + * #kmstest_edid_add_3d. + * + * Returns: an alternate edid block + */ const unsigned char* igt_kms_get_alt_edid(void) { update_edid_csum(alt_edid); -- 2.11.0.453.g787f75f05 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v4 08/11] tests/kms_atomic_transition: add fencing parameter to run_transition_tests
From: Gustavo PadovanSigned-off-by: Gustavo Padovan Signed-off-by: Robert Foss --- tests/kms_atomic_transition.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c index 095af515..72429759 100644 --- a/tests/kms_atomic_transition.c +++ b/tests/kms_atomic_transition.c @@ -264,7 +264,7 @@ retry: */ static void run_transition_test(igt_display_t *display, enum pipe pipe, igt_output_t *output, - enum transition_type type, bool nonblocking) + enum transition_type type, bool nonblocking, bool fencing) { struct igt_fb fb, argb_fb, sprite_fb; drmModeModeInfo *mode, override_mode; @@ -674,19 +674,19 @@ igt_main igt_subtest("plane-all-transition") for_each_pipe_with_valid_output(, pipe, output) - run_transition_test(, pipe, output, TRANSITION_PLANES, false); + run_transition_test(, pipe, output, TRANSITION_PLANES, false, false); igt_subtest("plane-all-transition-nonblocking") for_each_pipe_with_valid_output(, pipe, output) - run_transition_test(, pipe, output, TRANSITION_PLANES, true); + run_transition_test(, pipe, output, TRANSITION_PLANES, true, false); igt_subtest("plane-all-modeset-transition") for_each_pipe_with_valid_output(, pipe, output) - run_transition_test(, pipe, output, TRANSITION_MODESET, false); + run_transition_test(, pipe, output, TRANSITION_MODESET, false, false); igt_subtest("plane-toggle-modeset-transition") for_each_pipe_with_valid_output(, pipe, output) - run_transition_test(, pipe, output, TRANSITION_MODESET_DISABLE, false); + run_transition_test(, pipe, output, TRANSITION_MODESET_DISABLE, false, false); for (i = 1; i <= I915_MAX_PIPES; i++) { igt_subtest_f("%ix-modeset-transitions", i) -- 2.11.0.453.g787f75f05 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v4 09/11] tests/kms_atomic_transition: add out_fences tests
Signed-off-by: Gustavo PadovanSigned-off-by: Robert Foss --- lib/igt_kms.c | 16 + tests/kms_atomic_transition.c | 153 -- 2 files changed, 164 insertions(+), 5 deletions(-) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index 7bf3fa3a..64f8b337 100644 --- a/lib/igt_kms.c +++ b/lib/igt_kms.c @@ -53,6 +53,7 @@ #include "intel_chipset.h" #include "igt_debugfs.h" #include "igt_sysfs.h" +#include "sw_sync.h" /** * SECTION:igt_kms @@ -2470,6 +2471,21 @@ static int igt_atomic_commit(igt_display_t *display, uint32_t flags, void *user_ } ret = drmModeAtomicCommit(display->drm_fd, req, flags, user_data); + if (!ret) { + + for_each_pipe(display, pipe) { + igt_pipe_t *pipe_obj = >pipes[pipe]; + + if (pipe_obj->out_fence_fd == -1) + continue; + + igt_assert(pipe_obj->out_fence_fd >= 0); + ret = sync_fence_wait(pipe_obj->out_fence_fd, 1000); + igt_assert(ret == 0); + close(pipe_obj->out_fence_fd); + } + } + drmModeAtomicFree(req); return ret; diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c index 72429759..4b1278a4 100644 --- a/tests/kms_atomic_transition.c +++ b/tests/kms_atomic_transition.c @@ -23,7 +23,9 @@ #include "igt.h" #include "drmtest.h" +#include "sw_sync.h" #include +#include #include #include #include @@ -253,6 +255,94 @@ retry: sprite_width, sprite_height, alpha); } +int *timeline; +pthread_t *thread; +int *seqno; + +static void prepare_fencing(igt_display_t *display, enum pipe pipe) +{ + igt_plane_t *plane; + int n_planes; + + igt_require_sw_sync(); + + n_planes = display->pipes[pipe].n_planes; + timeline = calloc(sizeof(*timeline), n_planes); + igt_assert_f(timeline != NULL, "Failed to allocate memory for timelines\n"); + thread = calloc(sizeof(*thread), n_planes); + igt_assert_f(thread != NULL, "Failed to allocate memory for thread\n"); + seqno = calloc(sizeof(*seqno), n_planes); + igt_assert_f(seqno != NULL, "Failed to allocate memory for seqno\n"); + + for_each_plane_on_pipe(display, pipe, plane) + timeline[plane->index] = sw_sync_timeline_create(); +} + +static void unprepare_fencing(igt_display_t *display, enum pipe pipe) +{ + igt_plane_t *plane; + + for_each_plane_on_pipe(display, pipe, plane) + close(timeline[plane->index]); + + free(timeline); + free(thread); + free(seqno); +} + +static void *fence_inc_thread(void *arg) +{ + int t = *((int *) arg); + + pthread_detach(pthread_self()); + + usleep(5000); + sw_sync_timeline_inc(t, 1); + return NULL; +} + +static void configure_fencing(igt_display_t *display, enum pipe pipe) +{ + igt_plane_t *plane; + int i, fd, ret; + + for_each_plane_on_pipe(display, pipe, plane) { + + if (!plane->fb) + continue; + + i = plane->index; + + seqno[i]++; + fd = sw_sync_timeline_create_fence(timeline[i], seqno[i]); + igt_plane_set_fence_fd(plane, fd); + close(fd); + ret = pthread_create([i], NULL, fence_inc_thread, [i]); + igt_assert_eq(ret, 0); + } +} + +static void clear_fencing(igt_display_t *display, enum pipe pipe) +{ + igt_plane_t *plane; + + for_each_plane_on_pipe(display, pipe, plane) + igt_plane_set_fence_fd(plane, -1); +} + +static void atomic_commit(igt_display_t *display, enum pipe pipe, unsigned int flags, void *data, bool fencing) +{ + if (fencing) { + configure_fencing(display, pipe); + igt_pipe_request_out_fence(>pipes[pipe]); + } + + igt_display_commit_atomic(display, flags, data); + + if (fencing) + clear_fencing(display, pipe); +} + /* * 1. Set primary plane to a known fb. * 2. Make sure getcrtc returns the correct fb id. @@ -273,6 +363,10 @@ run_transition_test(igt_display_t *display, enum pipe pipe, igt_output_t *output struct plane_parms parms[display->pipes[pipe].n_planes]; bool skip_test = false; unsigned flags = DRM_MODE_PAGE_FLIP_EVENT; + int ret; + + if (fencing) + prepare_fencing(display, pipe); if (nonblocking) flags |= DRM_MODE_ATOMIC_NONBLOCK; @@ -307,12 +401,48 @@ run_transition_test(igt_display_t *display, enum pipe pipe, igt_output_t *output setup_parms(display, pipe, mode, _fb, _fb, parms); + /* +* In some configurations the tests may not run to completion with all +* sprite planes lit up at 4k
[Intel-gfx] [PATCH i-g-t v4 01/11] tests/kms_atomic_transition: use igt timeout instead of blocking
From: Gustavo PadovanIf the event never arrives we can timeout and end the test. Signed-off-by: Gustavo Padovan Signed-off-by: Robert Foss --- tests/kms_atomic_transition.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c index 5fdb6175..095af515 100644 --- a/tests/kms_atomic_transition.c +++ b/tests/kms_atomic_transition.c @@ -383,7 +383,9 @@ static void commit_display(igt_display_t *display, unsigned event_mask, bool non struct drm_event_vblank *vblank = (void *)buf; uint32_t crtc_id, pipe = I915_MAX_PIPES; + igt_set_timeout(3, "Timed out while reading drm_fd\n"); ret = read(display->drm_fd, buf, sizeof(buf)); + igt_reset_timeout(); if (ret < 0 && (errno == EINTR || errno == EAGAIN)) continue; -- 2.11.0.453.g787f75f05 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v4 04/11] tests/kms_atomic: use global atomic properties definitions
From: Gustavo PadovanSigned-off-by: Gustavo Padovan Signed-off-by: Robert Foss --- tests/kms_atomic.c | 123 - 1 file changed, 37 insertions(+), 86 deletions(-) diff --git a/tests/kms_atomic.c b/tests/kms_atomic.c index e6d71c31..8df51ccd 100644 --- a/tests/kms_atomic.c +++ b/tests/kms_atomic.c @@ -105,55 +105,6 @@ static const char *plane_type_prop_names[NUM_PLANE_TYPE_PROPS] = { "Cursor" }; -enum plane_properties { - PLANE_SRC_X = 0, - PLANE_SRC_Y, - PLANE_SRC_W, - PLANE_SRC_H, - PLANE_CRTC_X, - PLANE_CRTC_Y, - PLANE_CRTC_W, - PLANE_CRTC_H, - PLANE_FB_ID, - PLANE_CRTC_ID, - PLANE_TYPE, - NUM_PLANE_PROPS -}; - -static const char *plane_prop_names[NUM_PLANE_PROPS] = { - "SRC_X", - "SRC_Y", - "SRC_W", - "SRC_H", - "CRTC_X", - "CRTC_Y", - "CRTC_W", - "CRTC_H", - "FB_ID", - "CRTC_ID", - "type" -}; - -enum crtc_properties { - CRTC_MODE_ID = 0, - CRTC_ACTIVE, - NUM_CRTC_PROPS -}; - -static const char *crtc_prop_names[NUM_CRTC_PROPS] = { - "MODE_ID", - "ACTIVE" -}; - -enum connector_properties { - CONNECTOR_CRTC_ID = 0, - NUM_CONNECTOR_PROPS -}; - -static const char *connector_prop_names[NUM_CONNECTOR_PROPS] = { - "CRTC_ID" -}; - struct kms_atomic_blob { uint32_t id; /* 0 if not already allocated */ size_t len; @@ -197,9 +148,9 @@ struct kms_atomic_state { struct kms_atomic_desc { int fd; - uint32_t props_connector[NUM_CONNECTOR_PROPS]; - uint32_t props_crtc[NUM_CRTC_PROPS]; - uint32_t props_plane[NUM_PLANE_PROPS]; + uint32_t props_connector[IGT_NUM_CONNECTOR_PROPS]; + uint32_t props_crtc[IGT_NUM_CRTC_PROPS]; + uint32_t props_plane[IGT_NUM_PLANE_PROPS]; uint64_t props_plane_type[NUM_PLANE_TYPE_PROPS]; }; @@ -280,7 +231,7 @@ connector_get_current_state(struct kms_atomic_connector_state *connector) for (i = 0; i < props->count_props; i++) { uint32_t *prop_ids = connector->state->desc->props_connector; - if (props->props[i] == prop_ids[CONNECTOR_CRTC_ID]) + if (props->props[i] == prop_ids[IGT_CONNECTOR_CRTC_ID]) connector->crtc_id = props->prop_values[i]; } drmModeFreeObjectProperties(props); @@ -348,16 +299,16 @@ find_connector(struct kms_atomic_state *state, static void plane_populate_req(struct kms_atomic_plane_state *plane, drmModeAtomicReq *req) { - plane_set_prop(req, plane, PLANE_CRTC_ID, plane->crtc_id); - plane_set_prop(req, plane, PLANE_FB_ID, plane->fb_id); - plane_set_prop(req, plane, PLANE_SRC_X, plane->src_x); - plane_set_prop(req, plane, PLANE_SRC_Y, plane->src_y); - plane_set_prop(req, plane, PLANE_SRC_W, plane->src_w); - plane_set_prop(req, plane, PLANE_SRC_H, plane->src_h); - plane_set_prop(req, plane, PLANE_CRTC_X, plane->crtc_x); - plane_set_prop(req, plane, PLANE_CRTC_Y, plane->crtc_y); - plane_set_prop(req, plane, PLANE_CRTC_W, plane->crtc_w); - plane_set_prop(req, plane, PLANE_CRTC_H, plane->crtc_h); + plane_set_prop(req, plane, IGT_PLANE_CRTC_ID, plane->crtc_id); + plane_set_prop(req, plane, IGT_PLANE_FB_ID, plane->fb_id); + plane_set_prop(req, plane, IGT_PLANE_SRC_X, plane->src_x); + plane_set_prop(req, plane, IGT_PLANE_SRC_Y, plane->src_y); + plane_set_prop(req, plane, IGT_PLANE_SRC_W, plane->src_w); + plane_set_prop(req, plane, IGT_PLANE_SRC_H, plane->src_h); + plane_set_prop(req, plane, IGT_PLANE_CRTC_X, plane->crtc_x); + plane_set_prop(req, plane, IGT_PLANE_CRTC_Y, plane->crtc_y); + plane_set_prop(req, plane, IGT_PLANE_CRTC_W, plane->crtc_w); + plane_set_prop(req, plane, IGT_PLANE_CRTC_H, plane->crtc_h); } static void plane_get_current_state(struct kms_atomic_plane_state *plane) @@ -373,27 +324,27 @@ static void plane_get_current_state(struct kms_atomic_plane_state *plane) for (i = 0; i < props->count_props; i++) { uint32_t *prop_ids = desc->props_plane; - if (props->props[i] == prop_ids[PLANE_CRTC_ID]) + if (props->props[i] == prop_ids[IGT_PLANE_CRTC_ID]) plane->crtc_id = props->prop_values[i]; - else if (props->props[i] == prop_ids[PLANE_FB_ID]) + else if (props->props[i] == prop_ids[IGT_PLANE_FB_ID]) plane->fb_id = props->prop_values[i]; - else if (props->props[i] == prop_ids[PLANE_CRTC_X]) + else if (props->props[i] == prop_ids[IGT_PLANE_CRTC_X]) plane->crtc_x = props->prop_values[i]; - else if (props->props[i] ==
[Intel-gfx] [PATCH i-g-t v4 05/11] lib/igt_kms: Add support for the IN_FENCE_FD property
Add support dor the IN_FENCE_FD property to enable setting in fences for atomic commits. Signed-off-by: Robert Foss--- lib/igt_kms.c | 25 + lib/igt_kms.h | 5 + 2 files changed, 30 insertions(+) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index 142658a6..9b60d74a 100644 --- a/lib/igt_kms.c +++ b/lib/igt_kms.c @@ -168,6 +168,7 @@ const char *igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = { "CRTC_H", "FB_ID", "CRTC_ID", + "IN_FENCE_FD", "type", "rotation" }; @@ -1667,6 +1668,7 @@ void igt_display_init(igt_display_t *display, int drm_fd) plane->type = type; plane->pipe = pipe; plane->drm_plane = drm_plane; + plane->fence_fd = -1; if (is_atomic == 0) { display->is_atomic = 1; @@ -1994,6 +1996,11 @@ igt_atomic_prepare_plane_commit(igt_plane_t *plane, igt_pipe_t *pipe, plane->index, fb_id); + if (plane->fence_fd >= 0) { + uint64_t fence_fd = (int64_t) plane->fence_fd; + igt_atomic_populate_plane_req(req, plane, IGT_PLANE_IN_FENCE_FD, fence_fd); + } + if (plane->fb_changed) { igt_atomic_populate_plane_req(req, plane, IGT_PLANE_CRTC_ID, fb_id ? crtc_id : 0); igt_atomic_populate_plane_req(req, plane, IGT_PLANE_FB_ID, fb_id); @@ -2815,6 +2822,24 @@ void igt_plane_set_fb(igt_plane_t *plane, struct igt_fb *fb) plane->size_changed = true; } +/** + * igt_plane_set_fence_fd: + * @plane: plane + * @fence_fd: fence fd, disable fence_fd by setting it to -1 + * + * This function sets a fence fd to enable a commit to wait for some event to + * occur before completing. + */ +void igt_plane_set_fence_fd(igt_plane_t *plane, int fence_fd) +{ + close(plane->fence_fd); + + if (fcntl(fence_fd, F_GETFD) != -1) + plane->fence_fd = dup(fence_fd); + else + plane->fence_fd = -1; +} + void igt_plane_set_position(igt_plane_t *plane, int x, int y) { igt_pipe_t *pipe = plane->pipe; diff --git a/lib/igt_kms.h b/lib/igt_kms.h index 00e0dc68..8acad8ef 100644 --- a/lib/igt_kms.h +++ b/lib/igt_kms.h @@ -248,6 +248,7 @@ enum igt_atomic_plane_properties { IGT_PLANE_FB_ID, IGT_PLANE_CRTC_ID, + IGT_PLANE_IN_FENCE_FD, IGT_PLANE_TYPE, IGT_PLANE_ROTATION, IGT_NUM_PLANE_PROPS @@ -306,6 +307,9 @@ typedef struct { uint32_t src_h; igt_rotation_t rotation; + + /* in fence fd */ + int fence_fd; uint32_t atomic_props_plane[IGT_NUM_PLANE_PROPS]; } igt_plane_t; @@ -396,6 +400,7 @@ void igt_pipe_set_ctm_matrix(igt_pipe_t *pipe, void *ptr, size_t length); void igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr, size_t length); void igt_plane_set_fb(igt_plane_t *plane, struct igt_fb *fb); +void igt_plane_set_fence_fd(igt_plane_t *plane, int fence_fd); void igt_plane_set_position(igt_plane_t *plane, int x, int y); void igt_plane_set_size(igt_plane_t *plane, int w, int h); void igt_plane_set_rotation(igt_plane_t *plane, igt_rotation_t rotation); -- 2.11.0.453.g787f75f05 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v4 00/11] tests/kms_atomic_transition add fence testing
This series adds in/out fence testing to kms_atomic_transition test and makes some minor cleanups. This series can be found here: https://git.collabora.com/cgit/user/robertfoss/intel-gpu-tools.git/log/?h=fences_$VER Changes since v3: Rebased on upstream/master lib/igt_kms: - Change out_fence from int64_t to int32_t - Fixed build error halfway in the series - Change IN_FENCE_FD to be an int always - Change name of out_fence to out_fence_fd - Removed useless assert - Fixed erroneous fence_fd check in igt_atomic_commit() - Implemented igt_plane_set_fence_fd FD close logic - Properly close fd in igt_atomic_prepare_plane_commit() tests/kms_atomic: - Changed type of out_fence_ptr to int32_t tests/kms_atomic_transition: - Fixed indentation errors in prepare_fencing() - Added close() to callers of igt_plane_set_fence_fd with valid FDs - Move change atomic_commit to earlier commit to remove inter commit changes Changes since v2: Rebased on upstream/master lib/igt_kms: - Reset plane->fence_fd to -1 during igt_atomic_prepare_plane_commit() - Rework out_fencs_ptr to be an int64_t named out_fence - Add igt_pipe_request_out_fence() tests/: - Switch to using igt_pipe_request_out_fence() - Close out_fence fd - Change out_fence to int64_t in run_transition_test() - Added comments noting that two testcases are not invalid - Added igt_pipe_get_last_out_fence() that wraps pipe->fence_out Changes since v1: lib/igt_kms: - Added gtk-doc for exported symbols - Changed integer casting to avoid potential issues - Changed out_fence_ptr type to int64_t* - Fixed igt_plane_set_fence_fd comment tests/: - Rework timeout change in commit_display() - Extract plane_invalid_params_fence() out plane_invalid_params() - Extract crtc_invalid_params_fence() out crtc_invalid_params() - Prevent add igt_require_sw_sync to subtests using sw_sync Gustavo Padovan (8): tests/kms_atomic_transition: use igt timeout instead of blocking lib/igt_kms: move igt_kms_get_alt_edid() to the right place lib/igt_kms: export properties names tests/kms_atomic: use global atomic properties definitions lib/igt_kms: Add support for the OUT_FENCE_PTR property tests/kms_atomic: stress possible fence settings tests/kms_atomic_transition: add fencing parameter to run_transition_tests tests/kms_atomic_transition: add in_fences tests Robert Foss (3): lib/igt_kms: Add support for the IN_FENCE_FD property tests/kms_atomic_transition: add out_fences tests lib/igt_kms: Added igt_pipe_get_last_out_fence() lib/igt_kms.c | 115 +--- lib/igt_kms.h | 35 - tests/kms_atomic.c| 310 +- tests/kms_atomic_transition.c | 184 +++-- tools/intel_vbt_decode| Bin 0 -> 384448 bytes 5 files changed, 511 insertions(+), 133 deletions(-) create mode 100755 tools/intel_vbt_decode -- 2.11.0.453.g787f75f05 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v4 06/11] lib/igt_kms: Add support for the OUT_FENCE_PTR property
From: Gustavo PadovanAdd support for the OUT_FENCE_PTR property to enable setting out fences for atomic commits. Signed-off-by: Gustavo Padovan Signed-off-by: Robert Foss --- lib/igt_kms.c | 23 ++- lib/igt_kms.h | 6 +- 2 files changed, 27 insertions(+), 2 deletions(-) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index 9b60d74a..7bf3fa3a 100644 --- a/lib/igt_kms.c +++ b/lib/igt_kms.c @@ -179,7 +179,8 @@ const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = { "DEGAMMA_LUT", "GAMMA_LUT", "MODE_ID", - "ACTIVE" + "ACTIVE", + "OUT_FENCE_PTR" }; const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = { @@ -2385,6 +2386,14 @@ static void igt_atomic_prepare_crtc_commit(igt_pipe_t *pipe_obj, drmModeAtomicRe igt_atomic_populate_crtc_req(req, pipe_obj, IGT_CRTC_ACTIVE, !!output); } + pipe_obj->out_fence_fd = -1; + if (pipe_obj->out_fence_requested) + { + pipe_obj->out_fence_requested = false; + igt_atomic_populate_crtc_req(req, pipe_obj, IGT_CRTC_OUT_FENCE_PTR, + (uint64_t)(uintptr_t) _obj->out_fence_fd); + } + /* * TODO: Add all crtc level properties here */ @@ -2959,6 +2968,18 @@ void igt_plane_set_rotation(igt_plane_t *plane, igt_rotation_t rotation) plane->rotation_changed = true; } +/** + * igt_pipe_request_out_fence: + * @pipe: pipe pointer to which background color to be set + * + * Marks this pipe for requesting an out fence at the next atomic commit + * will contain the fd number of the out fence created by KMS. + */ +void igt_pipe_request_out_fence(igt_pipe_t *pipe) +{ + pipe->out_fence_requested = true; +} + void igt_pipe_set_degamma_lut(igt_pipe_t *pipe, void *ptr, size_t length) { diff --git a/lib/igt_kms.h b/lib/igt_kms.h index 8acad8ef..6754d00e 100644 --- a/lib/igt_kms.h +++ b/lib/igt_kms.h @@ -94,6 +94,7 @@ enum igt_atomic_crtc_properties { IGT_CRTC_GAMMA_LUT, IGT_CRTC_MODE_ID, IGT_CRTC_ACTIVE, + IGT_CRTC_OUT_FENCE_PTR, IGT_NUM_CRTC_PROPS }; @@ -341,6 +342,9 @@ struct igt_pipe { uint64_t mode_blob; bool mode_changed; + + int32_t out_fence_fd; + bool out_fence_requested; }; typedef struct { @@ -394,7 +398,7 @@ static inline bool igt_plane_supports_rotation(igt_plane_t *plane) { return plane->rotation_property != 0; } - +void igt_pipe_request_out_fence(igt_pipe_t *pipe); void igt_pipe_set_degamma_lut(igt_pipe_t *pipe, void *ptr, size_t length); void igt_pipe_set_ctm_matrix(igt_pipe_t *pipe, void *ptr, size_t length); void igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr, size_t length); -- 2.11.0.453.g787f75f05 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v4 07/11] tests/kms_atomic: stress possible fence settings
From: Gustavo PadovanSigned-off-by: Gustavo Padovan Signed-off-by: Robert Foss Reviewed-by: Brian Starkey --- tests/kms_atomic.c | 187 ++--- 1 file changed, 177 insertions(+), 10 deletions(-) diff --git a/tests/kms_atomic.c b/tests/kms_atomic.c index 8df51ccd..e794a62b 100644 --- a/tests/kms_atomic.c +++ b/tests/kms_atomic.c @@ -44,6 +44,7 @@ #include "drmtest.h" #include "igt.h" #include "igt_aux.h" +#include "sw_sync.h" #ifndef DRM_CLIENT_CAP_ATOMIC #define DRM_CLIENT_CAP_ATOMIC 3 @@ -126,6 +127,7 @@ struct kms_atomic_plane_state { uint32_t fb_id; /* 0 to disable */ uint32_t src_x, src_y, src_w, src_h; /* 16.16 fixed-point */ uint32_t crtc_x, crtc_y, crtc_w, crtc_h; /* normal integers */ + int32_t fence_fd; }; struct kms_atomic_crtc_state { @@ -133,6 +135,7 @@ struct kms_atomic_crtc_state { uint32_t obj; int idx; bool active; + int32_t *out_fence_ptr; struct kms_atomic_blob mode; }; @@ -190,11 +193,13 @@ static uint32_t blob_duplicate(int fd, uint32_t id_orig) crtc_populate_req(crtc, req); \ plane_populate_req(plane, req); \ do_atomic_commit((crtc)->state->desc->fd, req, flags); \ - crtc_check_current_state(crtc, plane, relax); \ - plane_check_current_state(plane, relax); \ + if (!(flags & DRM_MODE_ATOMIC_TEST_ONLY)) { \ + crtc_check_current_state(crtc, plane, relax); \ + plane_check_current_state(plane, relax); \ + } \ } -#define crtc_commit_atomic_err(crtc, plane, crtc_old, plane_old, req, relax, e) { \ +#define crtc_commit_atomic_err(crtc, plane, crtc_old, plane_old, req, flags, relax, e) { \ drmModeAtomicSetCursor(req, 0); \ crtc_populate_req(crtc, req); \ plane_populate_req(plane, req); \ @@ -299,6 +304,9 @@ find_connector(struct kms_atomic_state *state, static void plane_populate_req(struct kms_atomic_plane_state *plane, drmModeAtomicReq *req) { + if (plane->fence_fd) + plane_set_prop(req, plane, IGT_PLANE_IN_FENCE_FD, plane->fence_fd); + plane_set_prop(req, plane, IGT_PLANE_CRTC_ID, plane->crtc_id); plane_set_prop(req, plane, IGT_PLANE_FB_ID, plane->fb_id); plane_set_prop(req, plane, IGT_PLANE_SRC_X, plane->src_x); @@ -433,6 +441,10 @@ find_plane(struct kms_atomic_state *state, enum plane_type type, static void crtc_populate_req(struct kms_atomic_crtc_state *crtc, drmModeAtomicReq *req) { + if (crtc->out_fence_ptr) + crtc_set_prop(req, crtc, IGT_CRTC_OUT_FENCE_PTR, + (uint64_t) crtc->out_fence_ptr); + crtc_set_prop(req, crtc, IGT_CRTC_MODE_ID, crtc->mode.id); crtc_set_prop(req, crtc, IGT_CRTC_ACTIVE, crtc->active); } @@ -1061,6 +1073,37 @@ static void plane_invalid_params(struct kms_atomic_crtc_state *crtc, drmModeAtomicFree(req); } +static void plane_invalid_params_fence(struct kms_atomic_crtc_state *crtc, + struct kms_atomic_plane_state *plane_old, + struct kms_atomic_connector_state *conn) +{ + struct kms_atomic_plane_state plane = *plane_old; + drmModeAtomicReq *req = drmModeAtomicAlloc(); + int timeline, fence_fd; + + igt_require_sw_sync(); + + /* invalid fence fd */ + plane.fence_fd = plane.state->desc->fd; + plane.crtc_id = plane_old->crtc_id; + plane_commit_atomic_err(, plane_old, req, + ATOMIC_RELAX_NONE, EINVAL); + + /* Valid fence_fd but invalid CRTC */ + timeline = sw_sync_timeline_create(); + fence_fd = sw_sync_timeline_create_fence(timeline, 1); + plane.fence_fd = fence_fd; + plane.crtc_id = ~0U; + plane_commit_atomic_err(, plane_old, req, + ATOMIC_RELAX_NONE, EINVAL); + + plane.fence_fd = -1; + close(fence_fd); + close(timeline); + + drmModeAtomicFree(req); +} + static void crtc_invalid_params(struct kms_atomic_crtc_state *crtc_old, struct kms_atomic_plane_state *plane, struct kms_atomic_connector_state *conn) @@ -1072,30 +1115,32 @@ static void crtc_invalid_params(struct kms_atomic_crtc_state *crtc_old, /* Pass a series of invalid object IDs for the mode ID. */ crtc.mode.id = plane->obj; - crtc_commit_atomic_err(, plane, crtc_old, plane, req, + crtc_commit_atomic_err(, plane, crtc_old, plane, req, 0, ATOMIC_RELAX_NONE, EINVAL); crtc.mode.id = crtc.obj; - crtc_commit_atomic_err(, plane, crtc_old, plane, req, + crtc_commit_atomic_err(, plane, crtc_old, plane, req, 0,
Re: [Intel-gfx] [PATCH i-g-t v3 11/11] tests/kms_atomic_transition: add in_fences tests
On 2017-01-31 11:52 AM, Brian Starkey wrote: On Mon, Jan 30, 2017 at 08:58:47PM -0500, Robert Foss wrote: From: Gustavo PadovanSigned-off-by: Gustavo Padovan Signed-off-by: Robert Foss --- lib/igt_kms.c | 3 +++ tests/kms_atomic_transition.c | 48 ++- 2 files changed, 32 insertions(+), 19 deletions(-) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index 523f3f57..bc815363 100644 --- a/lib/igt_kms.c +++ b/lib/igt_kms.c @@ -2009,6 +2009,9 @@ igt_atomic_prepare_plane_commit(igt_plane_t *plane, igt_pipe_t *pipe, if (plane->fence_fd >= 0) { uint64_t fence_fd = (int64_t) plane->fence_fd; igt_atomic_populate_plane_req(req, plane, IGT_PLANE_IN_FENCE_FD, fence_fd); + +/* reset fence_fd to prevent it from being set for the next commit */ +plane->fence_fd = -1; Who closes it? Fixed in v4. } if (plane->fb_changed) { diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c index eebb5d66..0876bbb3 100644 --- a/tests/kms_atomic_transition.c +++ b/tests/kms_atomic_transition.c @@ -23,7 +23,9 @@ #include "igt.h" #include "drmtest.h" +#include "sw_sync.h" #include +#include #include #include #include @@ -362,6 +364,9 @@ run_transition_test(igt_display_t *display, enum pipe pipe, igt_output_t *output unsigned flags = DRM_MODE_PAGE_FLIP_EVENT; int ret; +if (fencing) +prepare_fencing(display, pipe); + if (nonblocking) flags |= DRM_MODE_ATOMIC_NONBLOCK; @@ -404,18 +409,19 @@ run_transition_test(igt_display_t *display, enum pipe pipe, igt_output_t *output wm_setup_plane(display, pipe, iter_max - 1, parms); if (fencing) -igt_pipe_set_out_fence_ptr(>pipes[pipe], -(int64_t *) _fence); +igt_pipe_request_out_fence(>pipes[pipe]); + Hopefully this can get rebased away? I'm getting confused about what's actually being added/changed in this commit. Fixed in v4. The igt_pipe_set_out_fence_ptr calls were really spread about. ret = igt_display_try_commit_atomic(display, DRM_MODE_ATOMIC_TEST_ONLY | DRM_MODE_ATOMIC_ALLOW_MODESET, NULL); -if (ret != -EINVAL || n_planes < 3) +if (ret != -EINVAL || display->pipes[pipe].n_planes < 3) break; ret = 0; for_each_plane_on_pipe(display, pipe, plane) { i = plane->index; -if (plane->is_primary || plane->is_cursor) +if (plane->type == DRM_PLANE_TYPE_PRIMARY || +plane->type == DRM_PLANE_TYPE_CURSOR) continue; This seems spurious? ... A bit more add/remove churn below which can hopefully go away with a rebase. Ack, removing churn in v4. Cheers, -Brian if (parms[i].width <= 512) @@ -436,10 +442,8 @@ run_transition_test(igt_display_t *display, enum pipe pipe, igt_output_t *output wm_setup_plane(display, pipe, i, parms); -if (fencing) -igt_pipe_set_out_fence_ptr(>pipes[pipe], _fence); +atomic_commit(display, pipe, flags, (void *)(unsigned long)i, fencing); -igt_display_commit_atomic(display, flags, (void *)(unsigned long)i); drmHandleEvent(display->drm_fd, _events); if (type == TRANSITION_MODESET_DISABLE) { @@ -463,19 +467,14 @@ run_transition_test(igt_display_t *display, enum pipe pipe, igt_output_t *output if (type == TRANSITION_MODESET) igt_output_override_mode(output, _mode); -if (fencing) -igt_pipe_set_out_fence_ptr(>pipes[pipe], _fence); - -igt_display_commit_atomic(display, flags, (void *)(unsigned long)j); +atomic_commit(display, pipe, flags, (void *)(unsigned long)i, fencing); drmHandleEvent(display->drm_fd, _events); wm_setup_plane(display, pipe, i, parms); if (type == TRANSITION_MODESET) igt_output_override_mode(output, NULL); -if (fencing) -igt_pipe_set_out_fence_ptr(>pipes[pipe], _fence); - +atomic_commit(display, pipe, flags, (void *)(unsigned long)i, fencing); igt_display_commit_atomic(display, flags, (void *)(unsigned long)i); drmHandleEvent(display->drm_fd, _events); } @@ -483,6 +482,8 @@ run_transition_test(igt_display_t *display, enum pipe pipe, igt_output_t *output } cleanup: +unprepare_fencing(display, pipe); + igt_output_set_pipe(output, PIPE_NONE); for_each_plane_on_pipe(display, pipe, plane) @@ -617,7 +618,7 @@ static void collect_crcs_mask(igt_pipe_crc_t **pipe_crcs, unsigned mask, igt_crc } } -static void run_modeset_tests(igt_display_t *display, int howmany, bool nonblocking) +static void run_modeset_tests(igt_display_t *display, int howmany, bool nonblocking,
Re: [Intel-gfx] [PATCH v2] drm/i915: Get correct display clock on 945gm
Hi Arthur, [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on next-20170131] [cannot apply to v4.10-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Arthur-Heymans/drm-i915-Get-correct-display-clock-on-945gm/20170201-072757 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: x86_64-randconfig-i0-01312305 (attached as .config) compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All warnings (new ones prefixed by >>): drivers/gpu/drm/i915/intel_display.c: In function 'intel_init_display_hooks': >> drivers/gpu/drm/i915/intel_display.c:16240:45: warning: assignment from >> incompatible pointer type dev_priv->display.get_display_clock_speed = ^ vim +16240 drivers/gpu/drm/i915/intel_display.c 88212941 Imre Deak 2016-03-16 16224IS_GEN6(dev_priv) || IS_IVYBRIDGE(dev_priv)) e70236a8 Jesse Barnes 2009-09-21 16225 dev_priv->display.get_display_clock_speed = e70236a8 Jesse Barnes 2009-09-21 16226 i945_get_display_clock_speed; 88212941 Imre Deak 2016-03-16 16227 else if (IS_GM45(dev_priv)) 34edce2f Ville Syrjälä 2015-05-22 16228 dev_priv->display.get_display_clock_speed = 34edce2f Ville Syrjälä 2015-05-22 16229 gm45_get_display_clock_speed; c0f86832 Jani Nikula2016-12-07 16230 else if (IS_I965GM(dev_priv)) 34edce2f Ville Syrjälä 2015-05-22 16231 dev_priv->display.get_display_clock_speed = 34edce2f Ville Syrjälä 2015-05-22 16232 i965gm_get_display_clock_speed; 88212941 Imre Deak 2016-03-16 16233 else if (IS_PINEVIEW(dev_priv)) 34edce2f Ville Syrjälä 2015-05-22 16234 dev_priv->display.get_display_clock_speed = 34edce2f Ville Syrjälä 2015-05-22 16235 pnv_get_display_clock_speed; 88212941 Imre Deak 2016-03-16 16236 else if (IS_G33(dev_priv) || IS_G4X(dev_priv)) 34edce2f Ville Syrjälä 2015-05-22 16237 dev_priv->display.get_display_clock_speed = 34edce2f Ville Syrjälä 2015-05-22 16238 g33_get_display_clock_speed; 88212941 Imre Deak 2016-03-16 16239 else if (IS_I915G(dev_priv)) e70236a8 Jesse Barnes 2009-09-21 @16240 dev_priv->display.get_display_clock_speed = e70236a8 Jesse Barnes 2009-09-21 16241 i915_get_display_clock_speed; 52d2d756 Arthur Heymans 2017-02-01 16242 else if (IS_I845G(dev_priv)) e70236a8 Jesse Barnes 2009-09-21 16243 dev_priv->display.get_display_clock_speed = e70236a8 Jesse Barnes 2009-09-21 16244 i9xx_misc_get_display_clock_speed; 52d2d756 Arthur Heymans 2017-02-01 16245 else if (IS_I945GM(dev_priv)) 52d2d756 Arthur Heymans 2017-02-01 16246 dev_priv->display.get_display_clock_speed = 52d2d756 Arthur Heymans 2017-02-01 16247 i945gm_get_display_clock_speed; 88212941 Imre Deak 2016-03-16 16248 else if (IS_I915GM(dev_priv)) :: The code at line 16240 was first introduced by commit :: e70236a8d3d0a4c100a0b9f7d394d9bda9c56aca drm/i915: split display functions by chip type :: TO: Jesse Barnes <jbar...@virtuousgeek.org> :: CC: Eric Anholt <e...@anholt.net> --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)
== Series Details == Series: Still call-traces after suspend-resume (pm? i915? cpu/hotplug?) URL : https://patchwork.freedesktop.org/series/18871/ State : success == Summary == Series 18871v1 Still call-traces after suspend-resume (pm? i915? cpu/hotplug?) https://patchwork.freedesktop.org/api/1.0/series/18871/revisions/1/mbox/ fi-bdw-5557u total:247 pass:233 dwarn:0 dfail:0 fail:0 skip:14 fi-bsw-n3050 total:247 pass:208 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:247 pass:225 dwarn:0 dfail:0 fail:0 skip:22 fi-bxt-t5700 total:78 pass:65 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-hsw-4770r total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-ivb-3520m total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-ivb-3770 total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-kbl-7500u total:247 pass:224 dwarn:0 dfail:0 fail:2 skip:21 fi-skl-6260u total:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-skl-6700hqtotal:247 pass:227 dwarn:0 dfail:0 fail:0 skip:20 fi-skl-6700k total:247 pass:222 dwarn:4 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-snb-2520m total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-snb-2600 total:247 pass:215 dwarn:0 dfail:0 fail:0 skip:32 83f390eaec64a1b0566f5f747d20741c077fcff5 drm-tip: 2017y-01m-31d-20h-19m-59s UTC integration manifest 9beee45 Still call-traces after suspend-resume (pm? i915? cpu/hotplug?) == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3659/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v3 10/11] tests/kms_atomic_transition: add out_fences tests
On 2017-01-31 11:52 AM, Brian Starkey wrote: On Mon, Jan 30, 2017 at 08:58:46PM -0500, Robert Foss wrote: Signed-off-by: Gustavo PadovanSigned-off-by: Robert Foss --- lib/igt_kms.c | 35 ++ tests/kms_atomic_transition.c | 148 ++ 2 files changed, 169 insertions(+), 14 deletions(-) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index f14496dd..523f3f57 100644 --- a/lib/igt_kms.c +++ b/lib/igt_kms.c @@ -53,6 +53,7 @@ #include "intel_chipset.h" #include "igt_debugfs.h" #include "igt_sysfs.h" +#include "sw_sync.h" /** * SECTION:igt_kms @@ -2479,6 +2480,21 @@ static int igt_atomic_commit(igt_display_t *display, uint32_t flags, void *user_ } ret = drmModeAtomicCommit(display->drm_fd, req, flags, user_data); +if (!ret) { + +for_each_pipe(display, pipe) { +igt_pipe_t *pipe_obj = >pipes[pipe]; + +if (pipe_obj->out_fence != -1) +continue; Should be "if (pipe_obj->fence == -1)" ? The stuff below seems to be assuming the fence is valid. Correct, fixed in v4. + +igt_assert(pipe_obj->out_fence >= 0); +ret = sync_fence_wait(pipe_obj->out_fence, 1000); +igt_assert(ret == 0); +close(pipe_obj->out_fence); +} +} + drmModeAtomicFree(req); return ret; @@ -2972,6 +2988,11 @@ void igt_plane_set_rotation(igt_plane_t *plane, igt_rotation_t rotation) plane->rotation_changed = true; } +void igt_pipe_request_out_fence(igt_pipe_t *pipe) Oh here it is! +{ +pipe->out_fence_requested = true; +} + void igt_pipe_set_degamma_lut(igt_pipe_t *pipe, void *ptr, size_t length) { @@ -2994,20 +3015,6 @@ igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr, size_t length) } /** - * igt_pipe_set_out_fence_ptr: - * @pipe: pipe pointer to which background color to be set - * @fence_ptr: out fence pointer - * - * Sets the out fence pointer that will be passed to the kernel in - * the atomic ioctl. When the kernel returns the out fence pointer - * will contain the fd number of the out fence created by KMS. - */ -void igt_pipe_set_out_fence_ptr(igt_pipe_t *pipe, int64_t *fence_ptr) ... and there this one goes. This deletion and the function above need to be squashed into the earlier commit I suppose. Ack, fixed in v4. -{ -pipe->out_fence_ptr = fence_ptr; -} - -/** * igt_crtc_set_background: * @pipe: pipe pointer to which background color to be set * @background: background color value in BGR 16bpc diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c index 72429759..eebb5d66 100644 --- a/tests/kms_atomic_transition.c +++ b/tests/kms_atomic_transition.c @@ -253,6 +253,93 @@ retry: sprite_width, sprite_height, alpha); } +int *timeline; +pthread_t *thread; +int *seqno; + +static void prepare_fencing(igt_display_t *display, enum pipe pipe) +{ +igt_plane_t *plane; +int n_planes; + +igt_require_sw_sync(); + +n_planes = display->pipes[pipe].n_planes; +timeline = calloc(sizeof(*timeline), n_planes); +igt_assert_f(timeline != NULL, "Failed to allocate memory for timelines\n"); +thread = calloc(sizeof(*thread), n_planes); +igt_assert_f(thread != NULL, "Failed to allocate memory for thread\n"); +seqno = calloc(sizeof(*seqno), n_planes); +igt_assert_f(seqno != NULL, "Failed to allocate memory for seqno\n"); The 6 lines above are space-indented Ack, fixed in v4. + +for_each_plane_on_pipe(display, pipe, plane) +timeline[plane->index] = sw_sync_timeline_create(); +} + +static void unprepare_fencing(igt_display_t *display, enum pipe pipe) +{ +igt_plane_t *plane; + +for_each_plane_on_pipe(display, pipe, plane) +close(timeline[plane->index]); + +free(timeline); +free(thread); +free(seqno); +} + +static void *fence_inc_thread(void *arg) +{ +int t = *((int *) arg); + +pthread_detach(pthread_self()); + +usleep(5000); +sw_sync_timeline_inc(t, 1); +return NULL; +} + +static void configure_fencing(igt_display_t *display, enum pipe pipe) +{ +igt_plane_t *plane; +int i, fd, ret; + +for_each_plane_on_pipe(display, pipe, plane) { + +if (!plane->fb) +continue; + +i = plane->index; + +seqno[i]++; +fd = sw_sync_timeline_create_fence(timeline[i], seqno[i]); +igt_plane_set_fence_fd(plane, fd); +ret = pthread_create([i], NULL, fence_inc_thread, [i]); +igt_assert_eq(ret, 0); +} +} + +static void clear_fencing(igt_display_t *display, enum pipe pipe) +{ +igt_plane_t *plane; + +for_each_plane_on_pipe(display, pipe, plane) +igt_plane_set_fence_fd(plane, -1); Someone should close the old fence_fd if it's not -1. I think igt_plane_set_fence_fd() should dup() the passed in fence, and igt_display_atomic_commit() should set it to -1 after the
Re: [Intel-gfx] [PATCH] drm: Don't race connector registration
I added some printk()s all over and gathered a bit more information about what's going on. It looks like the display doesn't work until the drm connector code cleans up the *old* connector. For some reason, it isn't motivated to do that until I go to the console and back. In this case, the display was connected to DP-4. intel_dp_destroy_mst_connector() got called on it when I switched away, but drm_connector_cleanup() did not get called. Upon switching back DP-3/5/6 get created. One of these *eventually* ends up being "enabled", but is not now. When I switch over to the console, drm_connector_cleanup() finally gets called on the old connector: DP-4 and I can switch back to X and I see one of DP-3/5/6 enabled and working. Here are some snippets of dmesg interspersed with what I was doing: Push DVI switch button to switch to other system: > [ 6824.562838] drm_dp_destroy_port() kfree(8801ade46800) > [ 6824.563164] drm_dp_destroy_connector_work() port: 8801ade42000 > connector: 8801ade46000 > [ 6824.563178] intel_dp_destroy_mst_connector() connector: 8801ade46000 > name: DP-3 : 8801ade46048 intel_connector: 8801ade46000 > [ 6824.563186] drm_sysfs_connector_remove() connector: 8801ade46000 kdev: > 8801a941b400 > [ 6824.571556] drm_connector_cleanup(8801ade46000)::329 > connector->registered: 0 cpu: 3 > [ 6824.571570] drm_connector_cleanup() kfree() connector->name: 'DP-3' : > 8801ade46048 > [ 6824.571581] drm_dp_free_mst_port() kfree port: 8801ade42000 > [ 6824.571587] drm_dp_destroy_connector_work() port: 8801ade42800 > connector: 8801ade47000 > [ 6824.571594] intel_dp_destroy_mst_connector() connector: 8801ade47000 > name: DP-4 : 8801ade47048 intel_connector: 8801ade47000 > [ 6824.571601] drm_sysfs_connector_remove() connector: 8801ade47000 kdev: > 8801a941a000 > [ 6824.571915] drm_dp_free_mst_port() kfree port: 8801ade42800 > [ 6824.571925] drm_dp_destroy_connector_work() port: 8801ade40800 > connector: 8801ade43000 > [ 6824.571934] intel_dp_destroy_mst_connector() connector: 8801ade43000 > name: DP-6 : 8801ade43048 intel_connector: 8801ade43000 > [ 6824.571943] drm_sysfs_connector_remove() connector: 8801ade43000 kdev: > 8801a9419800 > [ 6824.572091] drm_connector_cleanup(8801ade43000)::329 > connector->registered: 0 cpu: 3 > [ 6824.572101] drm_connector_cleanup() kfree() connector->name: 'DP-6' : > 8801ade43048 > [ 6824.572110] drm_dp_free_mst_branch_device() kfree mstb: 88030ac22600 > [ 6824.572117] drm_dp_free_mst_port() kfree port: 8801ade40800 Push button to switch back: > [ 6837.349693] drm_connector_init() connector->name: 'DP-3' : > 88040231d848 > [ 6837.349894] drm_sysfs_connector_add() connector: 88040231d800 kdev: > 8801ae99f400 > [ 6837.352786] drm_connector_init() connector->name: 'DP-5' : > 880402318048 > [ 6837.352951] drm_sysfs_connector_add() connector: 880402318000 kdev: > 8801ae99c000 > [ 6837.353036] drm_connector_init() connector->name: 'DP-6' : > 88040d37f048 > [ 6837.353154] drm_sysfs_connector_add() connector: 88040d37f000 kdev: > 8801ae99ec00 I can type into the X session, but both screens are blank. When I press Ctrl-Alt-F2, I get: > [ 6850.494310] drm_connector_cleanup(8801ade47000)::329 > connector->registered: 0 cpu: 1 > [ 6850.494314] drm_connector_cleanup() kfree() connector->name: 'DP-4' : > 8801ade47048 Now I can switch back to X and everything is OK again. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Get correct display clock on 945gm (rev3)
== Series Details == Series: drm/i915: Get correct display clock on 945gm (rev3) URL : https://patchwork.freedesktop.org/series/18693/ State : success == Summary == Series 18693v3 drm/i915: Get correct display clock on 945gm https://patchwork.freedesktop.org/api/1.0/series/18693/revisions/3/mbox/ fi-bdw-5557u total:247 pass:233 dwarn:0 dfail:0 fail:0 skip:14 fi-bsw-n3050 total:247 pass:208 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:247 pass:225 dwarn:0 dfail:0 fail:0 skip:22 fi-bxt-t5700 total:78 pass:65 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-hsw-4770r total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-ivb-3520m total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-ivb-3770 total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-kbl-7500u total:247 pass:224 dwarn:0 dfail:0 fail:2 skip:21 fi-skl-6260u total:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-skl-6700hqtotal:247 pass:227 dwarn:0 dfail:0 fail:0 skip:20 fi-skl-6700k total:247 pass:222 dwarn:4 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-snb-2520m total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-snb-2600 total:247 pass:215 dwarn:0 dfail:0 fail:0 skip:32 83f390eaec64a1b0566f5f747d20741c077fcff5 drm-tip: 2017y-01m-31d-20h-19m-59s UTC integration manifest a784911 drm/i915: Get correct display clock on 945gm == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3658/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)
On Mon, Jan 30, 2017 at 11:44 PM, Rafael J. Wysockiwrote: > On 1/24/2017 2:33 AM, Sedat Dilek wrote: >> >> On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki >> wrote: >>> >>> On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek >>> wrote: Hi, I have already reported this issue in [1]. One of the issue was solved. Unfortunately, it looks like there is still a different problem here (Ubuntu/precise AMD64). I tried v4.10-rc1 and latest Linus tree up to... commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1 "mm/filemap: fix parameters to test_bit()" Here we go... [ 29.636047] BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1032 [ 29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg [ 29.636058] 1 lock held by Xorg/1500: [ 29.636060] #0: (>struct_mutex){+.+.+.}, at: [] i915_mutex_lock_interruptible+0x43/0x140 [i915] [ 29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted 4.10.0-rc1-6-iniza-amd64 #1 [ 29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013 [ 29.636111] Call Trace: [ 29.636120] dump_stack+0x85/0xc2 [ 29.636124] ___might_sleep+0x196/0x260 [ 29.636127] __might_sleep+0x53/0xb0 [ 29.636131] __pm_runtime_resume+0x7a/0x90 [ 29.636159] intel_runtime_pm_get+0x25/0x90 [i915] [ 29.636189] aliasing_gtt_bind_vma+0xaa/0xf0 [i915] [ 29.636220] i915_vma_bind+0xaf/0x1e0 [i915] [ 29.636248] i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915] [ 29.636272] i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915] [ 29.636275] ? trace_hardirqs_on+0xd/0x10 [ 29.636294] ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 [i915] [ 29.636316] ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915] [ 29.636342] i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915] [ 29.636347] ? __might_fault+0x4e/0xb0 [ 29.636373] i915_gem_execbuffer2+0xc5/0x260 [i915] [ 29.636376] ? __might_fault+0x4e/0xb0 [ 29.636395] drm_ioctl+0x206/0x450 [drm] [ 29.636420] ? i915_gem_execbuffer+0x340/0x340 [i915] [ 29.636425] ? __fget+0x5/0x200 [ 29.636429] do_vfs_ioctl+0x91/0x6f0 [ 29.636431] ? __fget+0x111/0x200 [ 29.636433] ? __fget+0x5/0x200 [ 29.636436] SyS_ioctl+0x79/0x90 [ 29.636441] entry_SYSCALL_64_fastpath+0x23/0xc6 On suspend/resume I see the same call trace. [2] points to the "BUG" line. >>> >>> Well, this appears to be an i915 issue, but not a serious one. >>> >>> Clearly, a function that may sleep (pm_runtime_get_sync() in >>> intel_runtime_pm_get()) is called with disabled interrupts. If I >>> understand the code correctly, though, it actually is not going to >>> sleep in this particular case, because pm_runtime_get_sync() has >>> already been called once for this device in the same code path which >>> means that this particular instance will return immediately, so this >>> is a false-positive (most likely). >>> >>> Let me see if I the might_sleep_if() assertion in >>> __pm_runtime_resume(() can be moved to a better place. >>> >> Hi Rafael, >> >> did you had a chance to look at this? >> The problem still remains in Linux v4.10-rc5. > > > No, I didn't. > > As I said, this is not a serious issue. Something like the attached (untested). Please try it and let me know if it makes the splat go away. Thanks, Rafael --- drivers/base/power/runtime.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) Index: linux-pm/drivers/base/power/runtime.c === --- linux-pm.orig/drivers/base/power/runtime.c +++ linux-pm/drivers/base/power/runtime.c @@ -966,13 +966,13 @@ int __pm_runtime_idle(struct device *dev unsigned long flags; int retval; - might_sleep_if(!(rpmflags & RPM_ASYNC) && !dev->power.irq_safe); - if (rpmflags & RPM_GET_PUT) { if (!atomic_dec_and_test(>power.usage_count)) return 0; } + might_sleep_if(!(rpmflags & RPM_ASYNC) && !dev->power.irq_safe); + spin_lock_irqsave(>power.lock, flags); retval = rpm_idle(dev, rpmflags); spin_unlock_irqrestore(>power.lock, flags); @@ -998,13 +998,13 @@ int __pm_runtime_suspend(struct device * unsigned long flags; int retval; - might_sleep_if(!(rpmflags & RPM_ASYNC) && !dev->power.irq_safe); - if (rpmflags & RPM_GET_PUT) { if (!atomic_dec_and_test(>power.usage_count)) return 0; } + might_sleep_if(!(rpmflags & RPM_ASYNC) && !dev->power.irq_safe); + spin_lock_irqsave(>power.lock, flags); retval = rpm_suspend(dev, rpmflags); spin_unlock_irqrestore(>power.lock, flags); @@ -1029,7 +1029,8 @@ int __pm_runtime_resume(struct device *d
Re: [Intel-gfx] [PATCH v2] drm/i915: Get correct display clock on 945gm
Hi Arthur, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20170131] [cannot apply to v4.10-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Arthur-Heymans/drm-i915-Get-correct-display-clock-on-945gm/20170201-072757 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: x86_64-rhel (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): drivers/gpu/drm/i915/intel_display.c: In function 'intel_init_display_hooks': >> drivers/gpu/drm/i915/intel_display.c:16240:45: error: assignment from >> incompatible pointer type [-Werror=incompatible-pointer-types] dev_priv->display.get_display_clock_speed = ^ cc1: some warnings being treated as errors vim +16240 drivers/gpu/drm/i915/intel_display.c 34edce2f Ville Syrjälä 2015-05-22 16234 dev_priv->display.get_display_clock_speed = 34edce2f Ville Syrjälä 2015-05-22 16235 pnv_get_display_clock_speed; 88212941 Imre Deak 2016-03-16 16236 else if (IS_G33(dev_priv) || IS_G4X(dev_priv)) 34edce2f Ville Syrjälä 2015-05-22 16237 dev_priv->display.get_display_clock_speed = 34edce2f Ville Syrjälä 2015-05-22 16238 g33_get_display_clock_speed; 88212941 Imre Deak 2016-03-16 16239 else if (IS_I915G(dev_priv)) e70236a8 Jesse Barnes 2009-09-21 @16240 dev_priv->display.get_display_clock_speed = e70236a8 Jesse Barnes 2009-09-21 16241 i915_get_display_clock_speed; 52d2d756 Arthur Heymans 2017-02-01 16242 else if (IS_I845G(dev_priv)) e70236a8 Jesse Barnes 2009-09-21 16243 dev_priv->display.get_display_clock_speed = :: The code at line 16240 was first introduced by commit :: e70236a8d3d0a4c100a0b9f7d394d9bda9c56aca drm/i915: split display functions by chip type :: TO: Jesse Barnes <jbar...@virtuousgeek.org> :: CC: Eric Anholt <e...@anholt.net> --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Get correct display clock on 945gm
This is according to Mobile Intel® 945 Express Chipset Family datasheet. Signed-off-by: Arthur Heymans--- drivers/gpu/drm/i915/i915_reg.h | 2 +- drivers/gpu/drm/i915/intel_display.c | 27 +-- 2 files changed, 26 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 02a65ddae3a3..f0b7849ace17 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -119,7 +119,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg) #define GCFGC 0xf0 /* 915+ only */ #define GC_LOW_FREQUENCY_ENABLE (1 << 7) #define GC_DISPLAY_CLOCK_190_200_MHZ (0 << 4) -#define GC_DISPLAY_CLOCK_333_MHZ (4 << 4) +#define GC_DISPLAY_CLOCK_333_320_MHZ (4 << 4) #define GC_DISPLAY_CLOCK_267_MHZ_PNV (0 << 4) #define GC_DISPLAY_CLOCK_333_MHZ_PNV (1 << 4) #define GC_DISPLAY_CLOCK_444_MHZ_PNV (2 << 4) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index ac25706b7d4d..998920ab3ec8 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -7407,6 +7407,26 @@ static int i945_get_display_clock_speed(struct drm_i915_private *dev_priv) return 40; } +static int i945gm_get_display_clock_speed(struct drm_i915_private *dev_priv) +{ + struct pci_dev *pdev = dev_priv->drm.pdev; + u16 gcfgc = 0; + + pci_read_config_word(pdev, GCFGC, ); + + if (gcfgc & GC_LOW_FREQUENCY_ENABLE) + return 13; + else { + switch (gcfgc & GC_DISPLAY_CLOCK_MASK) { + case GC_DISPLAY_CLOCK_333_320_MHZ: + return 32; + default: + case GC_DISPLAY_CLOCK_190_200_MHZ: + return 20; + } + } +} + static int i915_get_display_clock_speed(struct drm_i915_private *dev_priv) { return 33; @@ -7453,7 +7473,7 @@ static int i915gm_get_display_clock_speed(struct drm_i915_private *dev_priv) return 13; else { switch (gcfgc & GC_DISPLAY_CLOCK_MASK) { - case GC_DISPLAY_CLOCK_333_MHZ: + case GC_DISPLAY_CLOCK_333_320_MHZ: return 33; default: case GC_DISPLAY_CLOCK_190_200_MHZ: @@ -16244,9 +16264,12 @@ void intel_init_display_hooks(struct drm_i915_private *dev_priv) else if (IS_I915G(dev_priv)) dev_priv->display.get_display_clock_speed = i915_get_display_clock_speed; - else if (IS_I945GM(dev_priv) || IS_I845G(dev_priv)) + else if (IS_I845G(dev_priv)) dev_priv->display.get_display_clock_speed = i9xx_misc_get_display_clock_speed; + else if (IS_I945GM(dev_priv)) + dev_priv->display.get_display_clock_speed = + i945gm_get_display_clock_speed; else if (IS_I915GM(dev_priv)) dev_priv->display.get_display_clock_speed = i915gm_get_display_clock_speed; -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Get correct display clock on 945gm (rev2)
== Series Details == Series: drm/i915: Get correct display clock on 945gm (rev2) URL : https://patchwork.freedesktop.org/series/18693/ State : failure == Summary == CC drivers/acpi/acpica/utpredef.o CC [M] drivers/gpu/drm/i915/i915_perf.o CC [M] drivers/gpu/drm/i915/i915_oa_hsw.o CC drivers/acpi/acpica/utresrc.o CC drivers/acpi/acpica/utstate.o CC drivers/acpi/acpica/utstring.o CC drivers/acpi/acpica/utstrtoul64.o CC drivers/acpi/acpica/utxface.o CC [M] drivers/gpu/drm/i915/intel_gvt.o CC drivers/acpi/acpica/utxfinit.o CC drivers/acpi/acpica/utxferror.o LD net/ipv6/built-in.o CC drivers/acpi/acpica/utxfmutex.o CC [M] drivers/gpu/drm/i915/gvt/aperture_gm.o CC [M] drivers/gpu/drm/i915/gvt/gvt.o LD drivers/iommu/built-in.o CC [M] drivers/gpu/drm/i915/gvt/handlers.o CC [M] drivers/gpu/drm/i915/gvt/vgpu.o CC [M] drivers/gpu/drm/i915/gvt/trace_points.o CC [M] drivers/gpu/drm/i915/gvt/interrupt.o CC [M] drivers/gpu/drm/i915/gvt/firmware.o LD [M] drivers/gpu/drm/vgem/vgem.o CC [M] drivers/gpu/drm/i915/gvt/gtt.o CC [M] drivers/gpu/drm/i915/gvt/cfg_space.o CC [M] drivers/gpu/drm/i915/gvt/opregion.o CC [M] drivers/gpu/drm/i915/gvt/mmio.o CC [M] drivers/gpu/drm/i915/gvt/edid.o CC [M] drivers/gpu/drm/i915/gvt/display.o CC [M] drivers/gpu/drm/i915/gvt/sched_policy.o CC [M] drivers/gpu/drm/i915/gvt/scheduler.o CC [M] drivers/gpu/drm/i915/gvt/execlist.o CC [M] drivers/gpu/drm/i915/gvt/render.o CC [M] drivers/gpu/drm/i915/intel_lpe_audio.o CC [M] drivers/gpu/drm/i915/gvt/cmd_parser.o LD drivers/pci/built-in.o LD drivers/usb/gadget/libcomposite.o LD drivers/video/console/built-in.o LD drivers/video/built-in.o LD drivers/acpi/acpica/acpi.o LD drivers/usb/gadget/udc/udc-core.o LD drivers/gpu/drm/drm.o LD drivers/usb/gadget/udc/built-in.o LD drivers/usb/gadget/built-in.o LD net/xfrm/built-in.o LD drivers/scsi/sd_mod.o LD drivers/scsi/built-in.o LD drivers/acpi/acpica/built-in.o LD [M] drivers/net/ethernet/broadcom/genet/genet.o LD drivers/tty/serial/8250/8250_base.o LD drivers/tty/serial/8250/built-in.o LD drivers/tty/serial/built-in.o LD drivers/acpi/built-in.o drivers/gpu/drm/i915/intel_display.c: In function ‘intel_init_display_hooks’: drivers/gpu/drm/i915/intel_display.c:16268:45: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types] dev_priv->display.get_display_clock_speed = ^ LD drivers/usb/host/xhci-hcd.o LD [M] sound/pci/hda/snd-hda-codec-generic.o LD sound/pci/built-in.o LD fs/btrfs/btrfs.o LD [M] drivers/net/ethernet/intel/e1000/e1000.o LD sound/built-in.o LD fs/btrfs/built-in.o AR lib/lib.a EXPORTS lib/lib-ksyms.o LD lib/built-in.o LD drivers/usb/core/usbcore.o LD drivers/usb/core/built-in.o LD [M] drivers/net/ethernet/intel/igbvf/igbvf.o CC arch/x86/kernel/cpu/capflags.o LD arch/x86/kernel/cpu/built-in.o LD arch/x86/kernel/built-in.o LD drivers/tty/vt/built-in.o LD drivers/tty/built-in.o LD drivers/md/md-mod.o LD drivers/md/built-in.o LD arch/x86/built-in.o LD net/ipv4/built-in.o LD drivers/usb/host/built-in.o LD drivers/usb/built-in.o LD fs/ext4/ext4.o LD fs/ext4/built-in.o LD net/core/built-in.o LD fs/built-in.o LD net/built-in.o LD [M] drivers/net/ethernet/intel/igb/igb.o LD [M] drivers/net/ethernet/intel/e1000e/e1000e.o LD drivers/net/ethernet/built-in.o LD drivers/net/built-in.o cc1: all warnings being treated as errors scripts/Makefile.build:293: recipe for target 'drivers/gpu/drm/i915/intel_display.o' failed make[4]: *** [drivers/gpu/drm/i915/intel_display.o] Error 1 scripts/Makefile.build:551: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:551: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:551: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:988: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Get correct display clock on 945gm
This is according to Mobile Intel® 945 Express Chipset Family datasheet. Signed-off-by: Arthur Heymans--- drivers/gpu/drm/i915/i915_reg.h | 2 +- drivers/gpu/drm/i915/intel_display.c | 29 ++--- 2 files changed, 27 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 02a65ddae3a3..f0b7849ace17 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -119,7 +119,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg) #define GCFGC 0xf0 /* 915+ only */ #define GC_LOW_FREQUENCY_ENABLE (1 << 7) #define GC_DISPLAY_CLOCK_190_200_MHZ (0 << 4) -#define GC_DISPLAY_CLOCK_333_MHZ (4 << 4) +#define GC_DISPLAY_CLOCK_333_320_MHZ (4 << 4) #define GC_DISPLAY_CLOCK_267_MHZ_PNV (0 << 4) #define GC_DISPLAY_CLOCK_333_MHZ_PNV (1 << 4) #define GC_DISPLAY_CLOCK_444_MHZ_PNV (2 << 4) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index ac25706b7d4d..3e1deb501983 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -7407,7 +7407,27 @@ static int i945_get_display_clock_speed(struct drm_i915_private *dev_priv) return 40; } -static int i915_get_display_clock_speed(struct drm_i915_private *dev_priv) +static int i945gm_get_display_clock_speed(struct drm_i915_private *dev_priv) +{ + struct pci_dev *pdev = dev_priv->drm.pdev; + u16 gcfgc = 0; + + pci_read_config_word(pdev, GCFGC, ); + + if (gcfgc & GC_LOW_FREQUENCY_ENABLE) + return 13; + else { + switch (gcfgc & GC_DISPLAY_CLOCK_MASK) { + case GC_DISPLAY_CLOCK_333_320_MHZ: + return 32; + default: + case GC_DISPLAY_CLOCK_190_200_MHZ: + return 20; + } + } +} + +static int i915_get_display_clock_speed(struct drm_device *dev) { return 33; } @@ -7453,7 +7473,7 @@ static int i915gm_get_display_clock_speed(struct drm_i915_private *dev_priv) return 13; else { switch (gcfgc & GC_DISPLAY_CLOCK_MASK) { - case GC_DISPLAY_CLOCK_333_MHZ: + case GC_DISPLAY_CLOCK_333_320_MHZ: return 33; default: case GC_DISPLAY_CLOCK_190_200_MHZ: @@ -16244,9 +16264,12 @@ void intel_init_display_hooks(struct drm_i915_private *dev_priv) else if (IS_I915G(dev_priv)) dev_priv->display.get_display_clock_speed = i915_get_display_clock_speed; - else if (IS_I945GM(dev_priv) || IS_I845G(dev_priv)) + else if (IS_I845G(dev_priv)) dev_priv->display.get_display_clock_speed = i9xx_misc_get_display_clock_speed; + else if (IS_I945GM(dev_priv)) + dev_priv->display.get_display_clock_speed = + i945gm_get_display_clock_speed; else if (IS_I915GM(dev_priv)) dev_priv->display.get_display_clock_speed = i915gm_get_display_clock_speed; -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v3 08/11] tests/kms_atomic: stress possible fence settings
On 2017-01-31 11:50 AM, Brian Starkey wrote: This one lgtm, just need to swap all the uint64_t out_fence_ptrs for int32_t. -Brian Fixed in v4. Rob. On Mon, Jan 30, 2017 at 08:58:44PM -0500, Robert Foss wrote: From: Gustavo PadovanSigned-off-by: Gustavo Padovan Signed-off-by: Robert Foss --- tests/kms_atomic.c | 187 ++--- 1 file changed, 177 insertions(+), 10 deletions(-) diff --git a/tests/kms_atomic.c b/tests/kms_atomic.c index 8df51ccd..09605e38 100644 --- a/tests/kms_atomic.c +++ b/tests/kms_atomic.c @@ -44,6 +44,7 @@ #include "drmtest.h" #include "igt.h" #include "igt_aux.h" +#include "sw_sync.h" #ifndef DRM_CLIENT_CAP_ATOMIC #define DRM_CLIENT_CAP_ATOMIC 3 @@ -126,6 +127,7 @@ struct kms_atomic_plane_state { uint32_t fb_id; /* 0 to disable */ uint32_t src_x, src_y, src_w, src_h; /* 16.16 fixed-point */ uint32_t crtc_x, crtc_y, crtc_w, crtc_h; /* normal integers */ +int32_t fence_fd; }; struct kms_atomic_crtc_state { @@ -133,6 +135,7 @@ struct kms_atomic_crtc_state { uint32_t obj; int idx; bool active; +uint64_t out_fence_ptr; struct kms_atomic_blob mode; }; @@ -190,11 +193,13 @@ static uint32_t blob_duplicate(int fd, uint32_t id_orig) crtc_populate_req(crtc, req); \ plane_populate_req(plane, req); \ do_atomic_commit((crtc)->state->desc->fd, req, flags); \ -crtc_check_current_state(crtc, plane, relax); \ -plane_check_current_state(plane, relax); \ +if (!(flags & DRM_MODE_ATOMIC_TEST_ONLY)) { \ +crtc_check_current_state(crtc, plane, relax); \ +plane_check_current_state(plane, relax); \ +} \ } -#define crtc_commit_atomic_err(crtc, plane, crtc_old, plane_old, req, relax, e) { \ +#define crtc_commit_atomic_err(crtc, plane, crtc_old, plane_old, req, flags, relax, e) { \ drmModeAtomicSetCursor(req, 0); \ crtc_populate_req(crtc, req); \ plane_populate_req(plane, req); \ @@ -299,6 +304,9 @@ find_connector(struct kms_atomic_state *state, static void plane_populate_req(struct kms_atomic_plane_state *plane, drmModeAtomicReq *req) { +if (plane->fence_fd) +plane_set_prop(req, plane, IGT_PLANE_IN_FENCE_FD, plane->fence_fd); + plane_set_prop(req, plane, IGT_PLANE_CRTC_ID, plane->crtc_id); plane_set_prop(req, plane, IGT_PLANE_FB_ID, plane->fb_id); plane_set_prop(req, plane, IGT_PLANE_SRC_X, plane->src_x); @@ -433,6 +441,10 @@ find_plane(struct kms_atomic_state *state, enum plane_type type, static void crtc_populate_req(struct kms_atomic_crtc_state *crtc, drmModeAtomicReq *req) { +if (crtc->out_fence_ptr) +crtc_set_prop(req, crtc, IGT_CRTC_OUT_FENCE_PTR, + crtc->out_fence_ptr); + crtc_set_prop(req, crtc, IGT_CRTC_MODE_ID, crtc->mode.id); crtc_set_prop(req, crtc, IGT_CRTC_ACTIVE, crtc->active); } @@ -1061,6 +1073,37 @@ static void plane_invalid_params(struct kms_atomic_crtc_state *crtc, drmModeAtomicFree(req); } +static void plane_invalid_params_fence(struct kms_atomic_crtc_state *crtc, +struct kms_atomic_plane_state *plane_old, +struct kms_atomic_connector_state *conn) +{ +struct kms_atomic_plane_state plane = *plane_old; +drmModeAtomicReq *req = drmModeAtomicAlloc(); +int timeline, fence_fd; + +igt_require_sw_sync(); + +/* invalid fence fd */ +plane.fence_fd = plane.state->desc->fd; +plane.crtc_id = plane_old->crtc_id; +plane_commit_atomic_err(, plane_old, req, +ATOMIC_RELAX_NONE, EINVAL); + +/* Valid fence_fd but invalid CRTC */ +timeline = sw_sync_timeline_create(); +fence_fd = sw_sync_timeline_create_fence(timeline, 1); +plane.fence_fd = fence_fd; +plane.crtc_id = ~0U; +plane_commit_atomic_err(, plane_old, req, +ATOMIC_RELAX_NONE, EINVAL); + +plane.fence_fd = -1; +close(fence_fd); +close(timeline); + +drmModeAtomicFree(req); +} + static void crtc_invalid_params(struct kms_atomic_crtc_state *crtc_old, struct kms_atomic_plane_state *plane, struct kms_atomic_connector_state *conn) @@ -1072,30 +1115,32 @@ static void crtc_invalid_params(struct kms_atomic_crtc_state *crtc_old, /* Pass a series of invalid object IDs for the mode ID. */ crtc.mode.id = plane->obj; -crtc_commit_atomic_err(, plane, crtc_old, plane, req, +crtc_commit_atomic_err(, plane, crtc_old, plane, req, 0, ATOMIC_RELAX_NONE, EINVAL); crtc.mode.id = crtc.obj; -crtc_commit_atomic_err(, plane, crtc_old, plane, req, +crtc_commit_atomic_err(, plane, crtc_old, plane, req, 0, ATOMIC_RELAX_NONE, EINVAL); crtc.mode.id = conn->obj; -crtc_commit_atomic_err(, plane, crtc_old, plane, req, +crtc_commit_atomic_err(, plane, crtc_old,
Re: [Intel-gfx] [PATCH i-g-t v3 07/11] lib/igt_kms: Add support for the OUT_FENCE_PTR property
On 2017-01-31 11:49 AM, Brian Starkey wrote: On Mon, Jan 30, 2017 at 08:58:43PM -0500, Robert Foss wrote: From: Gustavo PadovanAdd support for the OUT_FENCE_PTR property to enable setting out fences for atomic commits. Signed-off-by: Gustavo Padovan Signed-off-by: Robert Foss --- lib/igt_kms.c | 26 +- lib/igt_kms.h | 6 +- 2 files changed, 30 insertions(+), 2 deletions(-) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index b79d2867..f14496dd 100644 --- a/lib/igt_kms.c +++ b/lib/igt_kms.c @@ -179,7 +179,8 @@ const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = { "DEGAMMA_LUT", "GAMMA_LUT", "MODE_ID", -"ACTIVE" +"ACTIVE", +"OUT_FENCE_PTR" }; const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = { @@ -2393,6 +2394,15 @@ static void igt_atomic_prepare_crtc_commit(igt_pipe_t *pipe_obj, drmModeAtomicRe igt_atomic_populate_crtc_req(req, pipe_obj, IGT_CRTC_ACTIVE, !!output); } +pipe_obj->out_fence = -1; +if (pipe_obj->out_fence_requested) +{ +pipe_obj->out_fence_requested = false; +igt_atomic_populate_crtc_req(req, pipe_obj, IGT_CRTC_OUT_FENCE_PTR, +(uint64_t)(uintptr_t) _obj->out_fence); +igt_assert_f(pipe_obj->out_fence != -1, "Unable to get fence, received -1 fd\n"); Doesn't this assertion always fail? You just set it to -1 Ack, fixed in v4 +} + /* *TODO: Add all crtc level properties here */ @@ -2984,6 +2994,20 @@ igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr, size_t length) } /** + * igt_pipe_set_out_fence_ptr: + * @pipe: pipe pointer to which background color to be set + * @fence_ptr: out fence pointer + * + * Sets the out fence pointer that will be passed to the kernel in + * the atomic ioctl. When the kernel returns the out fence pointer + * will contain the fd number of the out fence created by KMS. + */ +void igt_pipe_set_out_fence_ptr(igt_pipe_t *pipe, int64_t *fence_ptr) +{ +pipe->out_fence_ptr = fence_ptr; +} Is this ever used? You seem to use _obj->out_fence unconditionally above (and igt_pipe has no member named out_fence_ptr). I guess is left over from the previous API and needs to be removed? That's exactly what happened. Removed in v4. + +/** * igt_crtc_set_background: * @pipe: pipe pointer to which background color to be set * @background: background color value in BGR 16bpc diff --git a/lib/igt_kms.h b/lib/igt_kms.h index 85688853..9672dadc 100644 --- a/lib/igt_kms.h +++ b/lib/igt_kms.h @@ -94,6 +94,7 @@ enum igt_atomic_crtc_properties { IGT_CRTC_GAMMA_LUT, IGT_CRTC_MODE_ID, IGT_CRTC_ACTIVE, + IGT_CRTC_OUT_FENCE_PTR, IGT_NUM_CRTC_PROPS }; @@ -341,6 +342,9 @@ struct igt_pipe { uint64_t mode_blob; bool mode_changed; + +int64_t out_fence; +bool out_fence_requested; }; typedef struct { @@ -395,7 +399,7 @@ static inline bool igt_plane_supports_rotation(igt_plane_t *plane) { return plane->rotation_property != 0; } - +void igt_pipe_request_out_fence(igt_pipe_t *pipe); Not implemented? I think this patch got confused somewhere :-( -Brian Yes, some code has been moved around and this piece was not properly moved. Fixed in v4. Rob. void igt_pipe_set_degamma_lut(igt_pipe_t *pipe, void *ptr, size_t length); void igt_pipe_set_ctm_matrix(igt_pipe_t *pipe, void *ptr, size_t length); void igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr, size_t length); -- 2.11.0.453.g787f75f05 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for DisplayPort audio support on Cherrytrail
== Series Details == Series: DisplayPort audio support on Cherrytrail URL : https://patchwork.freedesktop.org/series/18864/ State : success == Summary == Series 18864v1 DisplayPort audio support on Cherrytrail https://patchwork.freedesktop.org/api/1.0/series/18864/revisions/1/mbox/ fi-bdw-5557u total:247 pass:233 dwarn:0 dfail:0 fail:0 skip:14 fi-bsw-n3050 total:247 pass:208 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:247 pass:225 dwarn:0 dfail:0 fail:0 skip:22 fi-bxt-t5700 total:78 pass:65 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-hsw-4770r total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-ivb-3520m total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-ivb-3770 total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-kbl-7500u total:247 pass:224 dwarn:0 dfail:0 fail:2 skip:21 fi-skl-6260u total:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-skl-6700hqtotal:247 pass:227 dwarn:0 dfail:0 fail:0 skip:20 fi-skl-6700k total:247 pass:222 dwarn:4 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-snb-2520m total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-snb-2600 total:247 pass:215 dwarn:0 dfail:0 fail:0 skip:32 83f390eaec64a1b0566f5f747d20741c077fcff5 drm-tip: 2017y-01m-31d-20h-19m-59s UTC integration manifest 15954fb drm/i915: Pass platform device to LPE audio notifier 1358641 ALSA: x86: Use config base depending on the pipe 0545a59 ALSA: x86: intel_hdmi: add definitions and logic for DP audio 14efa05 drm/i915: Pass pipe to LPE audio notification 32b5514 drm/i915: Avoid MST pipe handling for LPE audio 82dd01f drm/i915: add DisplayPort amp unmute for LPE audio mode 9bf23c4 drm/i915: add DP support in LPE audio mode == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3656/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/7] ALSA: x86: Use config base depending on the pipe
From: Pierre-Louis BossartNow the pipe that is being used is passed over i915 notification, we can re-setup the relevant register offset depending on pipe assignments during hotplug. This allows playback on single port machines such Zotac Pi330 or dual-port machines such as Dell Wyse 3040 box Signed-off-by: Pierre-Louis Bossart Signed-off-by: Takashi Iwai --- sound/x86/intel_hdmi_lpe_audio.c | 26 +- 1 file changed, 21 insertions(+), 5 deletions(-) diff --git a/sound/x86/intel_hdmi_lpe_audio.c b/sound/x86/intel_hdmi_lpe_audio.c index cea05dfc081a..6d630f20bca8 100644 --- a/sound/x86/intel_hdmi_lpe_audio.c +++ b/sound/x86/intel_hdmi_lpe_audio.c @@ -463,6 +463,22 @@ static void notify_audio_lpe(void *audio_ptr) } else if (eld != NULL) { + switch (eld->pipe_id) { + case 0: + ctx->had_config_offset = AUDIO_HDMI_CONFIG_A; + break; + case 1: + ctx->had_config_offset = AUDIO_HDMI_CONFIG_B; + break; + case 2: + ctx->had_config_offset = AUDIO_HDMI_CONFIG_C; + break; + default: + dev_dbg(_pdev->dev, "Invalid pipe %d\n", + eld->pipe_id); + break; + } + hdmi_set_eld(eld->eld_data); mid_hdmi_audio_signal_event(HAD_EVENT_HOT_PLUG); @@ -560,15 +576,15 @@ static int hdmi_lpe_audio_probe(struct platform_device *pdev) ctx->mmio_start = mmio_start; ctx->tmds_clock_speed = DIS_SAMPLE_RATE_148_5; - if (pci_dev_present(cherryview_ids)) { + if (pci_dev_present(cherryview_ids)) dev_dbg(_pdev->dev, "%s: Cherrytrail LPE - Detected\n", __func__); - ctx->had_config_offset = AUDIO_HDMI_CONFIG_C; - } else { + else dev_dbg(_pdev->dev, "%s: Baytrail LPE - Assume\n", __func__); - ctx->had_config_offset = AUDIO_HDMI_CONFIG_A; - } + + /* assume pipe A as default */ + ctx->had_config_offset = AUDIO_HDMI_CONFIG_A; pdata = pdev->dev.platform_data; -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/7] drm/i915: add DisplayPort amp unmute for LPE audio mode
From: Pierre-Louis BossartEnable unmute/mute amp notification. This doesn't seem to affect HDMI support so this is done unconditionally. An earlier version of this patch set a chicken bit at address 0x62F38 prior to the mute/unmute but this register doesn't seem to do anything so this phase was removed. Signed-off-by: Pierre-Louis Bossart Signed-off-by: Takashi Iwai --- drivers/gpu/drm/i915/i915_reg.h| 10 ++ drivers/gpu/drm/i915/intel_lpe_audio.c | 17 + 2 files changed, 27 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index a9ffc8df241b..8fcc80cb864b 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -2061,6 +2061,16 @@ enum skl_disp_power_wells { #define I915_HDMI_LPE_AUDIO_BASE (VLV_DISPLAY_BASE + 0x65000) #define I915_HDMI_LPE_AUDIO_SIZE 0x1000 +/* DisplayPort Audio w/ LPE */ +#define VLV_AUD_PORT_EN_B_DBG (VLV_DISPLAY_BASE + 0x62F20) +#define VLV_AUD_PORT_EN_C_DBG (VLV_DISPLAY_BASE + 0x62F30) +#define VLV_AUD_PORT_EN_D_DBG (VLV_DISPLAY_BASE + 0x62F34) +#define VLV_AUD_PORT_EN_DBG(port) _MMIO_PORT3((port) - PORT_B, \ + VLV_AUD_PORT_EN_B_DBG, \ + VLV_AUD_PORT_EN_C_DBG, \ + VLV_AUD_PORT_EN_D_DBG) +#define VLV_AMP_MUTE (1 << 1) + #define GEN6_BSD_RNCID _MMIO(0x12198) #define GEN7_FF_THREAD_MODE_MMIO(0x20a0) diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c b/drivers/gpu/drm/i915/intel_lpe_audio.c index 245523e14418..f95624a46f27 100644 --- a/drivers/gpu/drm/i915/intel_lpe_audio.c +++ b/drivers/gpu/drm/i915/intel_lpe_audio.c @@ -337,15 +337,25 @@ void intel_lpe_audio_notify(struct drm_i915_private *dev_priv, { unsigned long irq_flags; struct intel_hdmi_lpe_audio_pdata *pdata = NULL; + u32 audio_enable; + i915_reg_t mmio; if (!HAS_LPE_AUDIO(dev_priv)) return; + if (port == PORT_A) { + DRM_ERROR("PORT_A is not valid for HDMI/DP usages\n"); + return; + } + pdata = dev_get_platdata( &(dev_priv->lpe_audio.platdev->dev)); spin_lock_irqsave(>lpe_audio_slock, irq_flags); + mmio = VLV_AUD_PORT_EN_DBG(port); + audio_enable = I915_READ(mmio); + if (eld != NULL) { memcpy(pdata->eld.eld_data, eld, HDMI_MAX_ELD_BYTES); @@ -357,11 +367,18 @@ void intel_lpe_audio_notify(struct drm_i915_private *dev_priv, pdata->tmds_clock_speed = tmds_clk_speed; if (link_rate) pdata->link_rate = link_rate; + + /* Unmute the amp for both DP and HDMI */ + I915_WRITE(mmio, audio_enable & ~VLV_AMP_MUTE); + } else { memset(pdata->eld.eld_data, 0, HDMI_MAX_ELD_BYTES); pdata->hdmi_connected = false; pdata->dp_output = false; + + /* Mute the amp for both DP and HDMI */ + I915_WRITE(mmio, audio_enable | VLV_AMP_MUTE); } if (pdata->notify_audio_lpe) -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/7] drm/i915: Pass pipe to LPE audio notification
The LPE audio configuration depends on the pipe, thus we need to pass the currently used pipe. It's now embedded in struct intel_hdmi_lpe_audio_eld as well as port id. Signed-off-by: Takashi Iwai--- drivers/gpu/drm/i915/i915_drv.h| 2 +- drivers/gpu/drm/i915/intel_audio.c | 6 +++--- drivers/gpu/drm/i915/intel_lpe_audio.c | 3 ++- include/drm/intel_lpe_audio.h | 1 + 4 files changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 836d823d476b..27311a337e2b 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -3401,7 +3401,7 @@ int intel_lpe_audio_init(struct drm_i915_private *dev_priv); void intel_lpe_audio_teardown(struct drm_i915_private *dev_priv); void intel_lpe_audio_irq_handler(struct drm_i915_private *dev_priv); void intel_lpe_audio_notify(struct drm_i915_private *dev_priv, - void *eld, int port, int tmds_clk_speed, + void *eld, int port, int pipe, int tmds_clk_speed, bool dp_output, int link_rate); /* intel_i2c.c */ diff --git a/drivers/gpu/drm/i915/intel_audio.c b/drivers/gpu/drm/i915/intel_audio.c index d4e6d1136cfe..892169b7952b 100644 --- a/drivers/gpu/drm/i915/intel_audio.c +++ b/drivers/gpu/drm/i915/intel_audio.c @@ -634,12 +634,12 @@ void intel_audio_codec_enable(struct intel_encoder *intel_encoder, switch (intel_encoder->type) { case INTEL_OUTPUT_HDMI: - intel_lpe_audio_notify(dev_priv, connector->eld, port, + intel_lpe_audio_notify(dev_priv, connector->eld, port, pipe, crtc_state->port_clock, false, 0); break; case INTEL_OUTPUT_DP: - intel_lpe_audio_notify(dev_priv, connector->eld, port, + intel_lpe_audio_notify(dev_priv, connector->eld, port, pipe, adjusted_mode->crtc_clock, true, crtc_state->port_clock); break; @@ -680,7 +680,7 @@ void intel_audio_codec_disable(struct intel_encoder *intel_encoder) (int) port, (int) pipe); } - intel_lpe_audio_notify(dev_priv, NULL, port, 0, false, 0); + intel_lpe_audio_notify(dev_priv, NULL, port, pipe, 0, false, 0); } /** diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c b/drivers/gpu/drm/i915/intel_lpe_audio.c index f95624a46f27..2ca3c775c6b1 100644 --- a/drivers/gpu/drm/i915/intel_lpe_audio.c +++ b/drivers/gpu/drm/i915/intel_lpe_audio.c @@ -332,7 +332,7 @@ void intel_lpe_audio_teardown(struct drm_i915_private *dev_priv) * Notify lpe audio driver of eld change. */ void intel_lpe_audio_notify(struct drm_i915_private *dev_priv, - void *eld, int port, int tmds_clk_speed, + void *eld, int port, int pipe, int tmds_clk_speed, bool dp_output, int link_rate) { unsigned long irq_flags; @@ -360,6 +360,7 @@ void intel_lpe_audio_notify(struct drm_i915_private *dev_priv, memcpy(pdata->eld.eld_data, eld, HDMI_MAX_ELD_BYTES); pdata->eld.port_id = port; + pdata->eld.pipe_id = pipe; pdata->hdmi_connected = true; pdata->dp_output = dp_output; diff --git a/include/drm/intel_lpe_audio.h b/include/drm/intel_lpe_audio.h index 857e0eafed79..410128e4cd70 100644 --- a/include/drm/intel_lpe_audio.h +++ b/include/drm/intel_lpe_audio.h @@ -31,6 +31,7 @@ struct intel_hdmi_lpe_audio_eld { int port_id; + int pipe_id; unsigned char eld_data[HDMI_MAX_ELD_BYTES]; }; -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/7] ALSA: x86: intel_hdmi: add definitions and logic for DP audio
From: Pierre-Louis BossartImported from legacy patches Note: the new code doesn't assume a modified ELD but an explicit notification that DP is present. It appears that the i915 code does change the ELD so we could use the ELD-based tests to check for DP audio Signed-off-by: Pierre-Louis Bossart Signed-off-by: Takashi Iwai --- sound/x86/intel_hdmi_audio.c | 173 +-- sound/x86/intel_hdmi_audio.h | 8 +- sound/x86/intel_hdmi_lpe_audio.c | 36 +++- sound/x86/intel_hdmi_lpe_audio.h | 29 +++ 4 files changed, 216 insertions(+), 30 deletions(-) diff --git a/sound/x86/intel_hdmi_audio.c b/sound/x86/intel_hdmi_audio.c index f30155446117..5ce139c1b21d 100644 --- a/sound/x86/intel_hdmi_audio.c +++ b/sound/x86/intel_hdmi_audio.c @@ -396,6 +396,7 @@ static int snd_intelhad_prog_audio_ctrl_v2(struct snd_pcm_substream *substream, else cfg_val.cfg_regx_v2.layout = LAYOUT1; + cfg_val.cfg_regx_v2.val_bit = 1; had_write_register(AUD_CONFIG, cfg_val.cfg_regval); return 0; } @@ -447,6 +448,7 @@ static int snd_intelhad_prog_audio_ctrl_v1(struct snd_pcm_substream *substream, } + cfg_val.cfg_regx.val_bit = 1; had_write_register(AUD_CONFIG, cfg_val.cfg_regval); return 0; } @@ -548,6 +550,7 @@ void had_build_channel_allocation_map(struct snd_intelhad *intelhaddata) } had_get_caps(HAD_GET_ELD, >eeld); + had_get_caps(HAD_GET_DP_OUTPUT, >dp_output); pr_debug("eeld.speaker_allocation_block = %x\n", intelhaddata->eeld.speaker_allocation_block); @@ -685,7 +688,7 @@ static void snd_intelhad_prog_dip_v1(struct snd_pcm_substream *substream, /*Calculte the byte wide checksum for all valid DIP words*/ for (i = 0; i < BYTES_PER_WORD; i++) - checksum += (INFO_FRAME_WORD1 >> i*BITS_PER_BYTE) & MASK_BYTE0; + checksum += (HDMI_INFO_FRAME_WORD1 >> i*BITS_PER_BYTE) & MASK_BYTE0; for (i = 0; i < BYTES_PER_WORD; i++) checksum += (frame2.fr2_val >> i*BITS_PER_BYTE) & MASK_BYTE0; for (i = 0; i < BYTES_PER_WORD; i++) @@ -693,7 +696,7 @@ static void snd_intelhad_prog_dip_v1(struct snd_pcm_substream *substream, frame2.fr2_regx.chksum = -(checksum); - had_write_register(AUD_HDMIW_INFOFR, INFO_FRAME_WORD1); + had_write_register(AUD_HDMIW_INFOFR, HDMI_INFO_FRAME_WORD1); had_write_register(AUD_HDMIW_INFOFR, frame2.fr2_val); had_write_register(AUD_HDMIW_INFOFR, frame3.fr3_val); @@ -722,28 +725,35 @@ static void snd_intelhad_prog_dip_v2(struct snd_pcm_substream *substream, union aud_info_frame2 frame2 = {.fr2_val = 0}; union aud_info_frame3 frame3 = {.fr3_val = 0}; u8 checksum = 0; + u32 info_frame; int channels; channels = substream->runtime->channels; had_write_register(AUD_CNTL_ST, ctrl_state.ctrl_val); - frame2.fr2_regx.chnl_cnt = substream->runtime->channels - 1; + if (intelhaddata->dp_output) { + info_frame = DP_INFO_FRAME_WORD1; + frame2.fr2_val = 1; + } else { + info_frame = HDMI_INFO_FRAME_WORD1; + frame2.fr2_regx.chnl_cnt = substream->runtime->channels - 1; - frame3.fr3_regx.chnl_alloc = snd_intelhad_channel_allocation( - intelhaddata, channels); + frame3.fr3_regx.chnl_alloc = snd_intelhad_channel_allocation( + intelhaddata, channels); - /*Calculte the byte wide checksum for all valid DIP words*/ - for (i = 0; i < BYTES_PER_WORD; i++) - checksum += (INFO_FRAME_WORD1 >> i*BITS_PER_BYTE) & MASK_BYTE0; - for (i = 0; i < BYTES_PER_WORD; i++) - checksum += (frame2.fr2_val >> i*BITS_PER_BYTE) & MASK_BYTE0; - for (i = 0; i < BYTES_PER_WORD; i++) - checksum += (frame3.fr3_val >> i*BITS_PER_BYTE) & MASK_BYTE0; + /*Calculte the byte wide checksum for all valid DIP words*/ + for (i = 0; i < BYTES_PER_WORD; i++) + checksum += (info_frame >> i*BITS_PER_BYTE) & MASK_BYTE0; + for (i = 0; i < BYTES_PER_WORD; i++) + checksum += (frame2.fr2_val >> i*BITS_PER_BYTE) & MASK_BYTE0; + for (i = 0; i < BYTES_PER_WORD; i++) + checksum += (frame3.fr3_val >> i*BITS_PER_BYTE) & MASK_BYTE0; - frame2.fr2_regx.chksum = -(checksum); + frame2.fr2_regx.chksum = -(checksum); + } - had_write_register(AUD_HDMIW_INFOFR_v2, INFO_FRAME_WORD1); + had_write_register(AUD_HDMIW_INFOFR_v2, info_frame); had_write_register(AUD_HDMIW_INFOFR_v2, frame2.fr2_val); had_write_register(AUD_HDMIW_INFOFR_v2, frame3.fr3_val); @@
[Intel-gfx] [PATCH 3/7] drm/i915: Avoid MST pipe handling for LPE audio
The pipe gets cleared to -1 for non-MST before the ELD audio notification due to the MST audio support. This makes sense for HD-audio that received the MST handling, but it's useless for LPE audio. Handle the MST pipe hack conditionally only for HD-audio. Reported-by: Pierre-Louis BossartSigned-off-by: Takashi Iwai --- drivers/gpu/drm/i915/intel_audio.c | 21 +++-- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_audio.c b/drivers/gpu/drm/i915/intel_audio.c index 1645ce42b898..d4e6d1136cfe 100644 --- a/drivers/gpu/drm/i915/intel_audio.c +++ b/drivers/gpu/drm/i915/intel_audio.c @@ -624,13 +624,14 @@ void intel_audio_codec_enable(struct intel_encoder *intel_encoder, dev_priv->av_enc_map[pipe] = intel_encoder; mutex_unlock(_priv->av_mutex); - /* audio drivers expect pipe = -1 to indicate Non-MST cases */ - if (intel_encoder->type != INTEL_OUTPUT_DP_MST) - pipe = -1; - - if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify) + if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify) { + /* audio drivers expect pipe = -1 to indicate Non-MST cases */ + if (intel_encoder->type != INTEL_OUTPUT_DP_MST) + pipe = -1; acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr, (int) port, (int) pipe); + } + switch (intel_encoder->type) { case INTEL_OUTPUT_HDMI: intel_lpe_audio_notify(dev_priv, connector->eld, port, @@ -671,13 +672,13 @@ void intel_audio_codec_disable(struct intel_encoder *intel_encoder) dev_priv->av_enc_map[pipe] = NULL; mutex_unlock(_priv->av_mutex); - /* audio drivers expect pipe = -1 to indicate Non-MST cases */ - if (intel_encoder->type != INTEL_OUTPUT_DP_MST) - pipe = -1; - - if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify) + if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify) { + /* audio drivers expect pipe = -1 to indicate Non-MST cases */ + if (intel_encoder->type != INTEL_OUTPUT_DP_MST) + pipe = -1; acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr, (int) port, (int) pipe); + } intel_lpe_audio_notify(dev_priv, NULL, port, 0, false, 0); } -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/7] drm/i915: Pass platform device to LPE audio notifier
This allows the LPE HDMI driver to clean up its global variable reference. Also drop to pass the eld pointer because the connection status and the ELD bytes can be retrieved from the attached pdata. Signed-off-by: Takashi Iwai--- drivers/gpu/drm/i915/intel_lpe_audio.c | 3 +-- include/drm/intel_lpe_audio.h | 4 +++- sound/x86/intel_hdmi_lpe_audio.c | 23 +++ 3 files changed, 15 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c b/drivers/gpu/drm/i915/intel_lpe_audio.c index 2ca3c775c6b1..ef0e74830289 100644 --- a/drivers/gpu/drm/i915/intel_lpe_audio.c +++ b/drivers/gpu/drm/i915/intel_lpe_audio.c @@ -383,8 +383,7 @@ void intel_lpe_audio_notify(struct drm_i915_private *dev_priv, } if (pdata->notify_audio_lpe) - pdata->notify_audio_lpe( - (eld != NULL) ? >eld : NULL); + pdata->notify_audio_lpe(dev_priv->lpe_audio.platdev); else pdata->notify_pending = true; diff --git a/include/drm/intel_lpe_audio.h b/include/drm/intel_lpe_audio.h index 410128e4cd70..e9892b4c3af1 100644 --- a/include/drm/intel_lpe_audio.h +++ b/include/drm/intel_lpe_audio.h @@ -27,6 +27,8 @@ #include #include +struct platform_device; + #define HDMI_MAX_ELD_BYTES 128 struct intel_hdmi_lpe_audio_eld { @@ -42,7 +44,7 @@ struct intel_hdmi_lpe_audio_pdata { bool dp_output; int link_rate; struct intel_hdmi_lpe_audio_eld eld; - void (*notify_audio_lpe)(void *audio_ptr); + void (*notify_audio_lpe)(struct platform_device *pdev); spinlock_t lpe_audio_slock; }; diff --git a/sound/x86/intel_hdmi_lpe_audio.c b/sound/x86/intel_hdmi_lpe_audio.c index 6d630f20bca8..3cb0f642575c 100644 --- a/sound/x86/intel_hdmi_lpe_audio.c +++ b/sound/x86/intel_hdmi_lpe_audio.c @@ -439,15 +439,14 @@ static irqreturn_t display_pipe_interrupt_handler(int irq, void *dev_id) return IRQ_HANDLED; } -static void notify_audio_lpe(void *audio_ptr) +static void notify_audio_lpe(struct platform_device *pdev) { - struct hdmi_lpe_audio_ctx *ctx = get_hdmi_context(); - struct intel_hdmi_lpe_audio_pdata *pdata = hlpe_pdev->dev.platform_data; - struct intel_hdmi_lpe_audio_eld *eld = audio_ptr; + struct hdmi_lpe_audio_ctx *ctx = platform_get_drvdata(pdev); + struct intel_hdmi_lpe_audio_pdata *pdata = pdev->dev.platform_data; if (pdata->hdmi_connected != true) { - dev_dbg(_pdev->dev, "%s: Event: HAD_NOTIFY_HOT_UNPLUG\n", + dev_dbg(>dev, "%s: Event: HAD_NOTIFY_HOT_UNPLUG\n", __func__); if (hlpe_state == hdmi_connector_status_connected) { @@ -458,10 +457,11 @@ static void notify_audio_lpe(void *audio_ptr) mid_hdmi_audio_signal_event( HAD_EVENT_HOT_UNPLUG); } else - dev_dbg(_pdev->dev, "%s: Already Unplugged!\n", + dev_dbg(>dev, "%s: Already Unplugged!\n", __func__); - } else if (eld != NULL) { + } else { + struct intel_hdmi_lpe_audio_eld *eld = >eld; switch (eld->pipe_id) { case 0: @@ -474,7 +474,7 @@ static void notify_audio_lpe(void *audio_ptr) ctx->had_config_offset = AUDIO_HDMI_CONFIG_C; break; default: - dev_dbg(_pdev->dev, "Invalid pipe %d\n", + dev_dbg(>dev, "Invalid pipe %d\n", eld->pipe_id); break; } @@ -485,7 +485,7 @@ static void notify_audio_lpe(void *audio_ptr) hlpe_state = hdmi_connector_status_connected; - dev_dbg(_pdev->dev, "%s: HAD_NOTIFY_ELD : port = %d, tmds = %d\n", + dev_dbg(>dev, "%s: HAD_NOTIFY_ELD : port = %d, tmds = %d\n", __func__, eld->port_id, pdata->tmds_clock_speed); if (pdata->tmds_clock_speed) { @@ -494,8 +494,7 @@ static void notify_audio_lpe(void *audio_ptr) ctx->link_rate = pdata->link_rate; mid_hdmi_audio_signal_event(HAD_EVENT_MODE_CHANGING); } - } else - dev_dbg(_pdev->dev, "%s: Event: NULL EDID!!\n", __func__); + } } /** @@ -606,7 +605,7 @@ static int hdmi_lpe_audio_probe(struct platform_device *pdev) if (pdata->notify_pending) { dev_dbg(_pdev->dev, "%s: handle pending notification\n", __func__); - notify_audio_lpe(>eld); + notify_audio_lpe(pdev); pdata->notify_pending = false; } spin_unlock_irqrestore(>lpe_audio_slock, flag_irq); -- 2.11.0 ___ Intel-gfx mailing list
[Intel-gfx] [PATCH 1/7] drm/i915: add DP support in LPE audio mode
From: Pierre-Louis BossartIf DisplayPort is detected, pass flag and link rate to audio driver Signed-off-by: Pierre-Louis Bossart Signed-off-by: Takashi Iwai --- drivers/gpu/drm/i915/i915_drv.h| 3 ++- drivers/gpu/drm/i915/intel_audio.c | 19 +++ drivers/gpu/drm/i915/intel_lpe_audio.c | 7 ++- include/drm/intel_lpe_audio.h | 2 ++ 4 files changed, 25 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 3e3102cedc82..836d823d476b 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -3401,7 +3401,8 @@ int intel_lpe_audio_init(struct drm_i915_private *dev_priv); void intel_lpe_audio_teardown(struct drm_i915_private *dev_priv); void intel_lpe_audio_irq_handler(struct drm_i915_private *dev_priv); void intel_lpe_audio_notify(struct drm_i915_private *dev_priv, - void *eld, int port, int tmds_clk_speed); + void *eld, int port, int tmds_clk_speed, + bool dp_output, int link_rate); /* intel_i2c.c */ extern int intel_setup_gmbus(struct drm_device *dev); diff --git a/drivers/gpu/drm/i915/intel_audio.c b/drivers/gpu/drm/i915/intel_audio.c index 364f96207c40..1645ce42b898 100644 --- a/drivers/gpu/drm/i915/intel_audio.c +++ b/drivers/gpu/drm/i915/intel_audio.c @@ -631,9 +631,20 @@ void intel_audio_codec_enable(struct intel_encoder *intel_encoder, if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify) acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr, (int) port, (int) pipe); - - intel_lpe_audio_notify(dev_priv, connector->eld, port, - crtc_state->port_clock); + switch (intel_encoder->type) { + case INTEL_OUTPUT_HDMI: + intel_lpe_audio_notify(dev_priv, connector->eld, port, + crtc_state->port_clock, + false, 0); + break; + case INTEL_OUTPUT_DP: + intel_lpe_audio_notify(dev_priv, connector->eld, port, + adjusted_mode->crtc_clock, + true, crtc_state->port_clock); + break; + default: + break; + } } /** @@ -668,7 +679,7 @@ void intel_audio_codec_disable(struct intel_encoder *intel_encoder) acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr, (int) port, (int) pipe); - intel_lpe_audio_notify(dev_priv, NULL, port, 0); + intel_lpe_audio_notify(dev_priv, NULL, port, 0, false, 0); } /** diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c b/drivers/gpu/drm/i915/intel_lpe_audio.c index 27d94255872d..245523e14418 100644 --- a/drivers/gpu/drm/i915/intel_lpe_audio.c +++ b/drivers/gpu/drm/i915/intel_lpe_audio.c @@ -332,7 +332,8 @@ void intel_lpe_audio_teardown(struct drm_i915_private *dev_priv) * Notify lpe audio driver of eld change. */ void intel_lpe_audio_notify(struct drm_i915_private *dev_priv, - void *eld, int port, int tmds_clk_speed) + void *eld, int port, int tmds_clk_speed, + bool dp_output, int link_rate) { unsigned long irq_flags; struct intel_hdmi_lpe_audio_pdata *pdata = NULL; @@ -351,12 +352,16 @@ void intel_lpe_audio_notify(struct drm_i915_private *dev_priv, pdata->eld.port_id = port; pdata->hdmi_connected = true; + pdata->dp_output = dp_output; if (tmds_clk_speed) pdata->tmds_clock_speed = tmds_clk_speed; + if (link_rate) + pdata->link_rate = link_rate; } else { memset(pdata->eld.eld_data, 0, HDMI_MAX_ELD_BYTES); pdata->hdmi_connected = false; + pdata->dp_output = false; } if (pdata->notify_audio_lpe) diff --git a/include/drm/intel_lpe_audio.h b/include/drm/intel_lpe_audio.h index 952de05a9d76..857e0eafed79 100644 --- a/include/drm/intel_lpe_audio.h +++ b/include/drm/intel_lpe_audio.h @@ -38,6 +38,8 @@ struct intel_hdmi_lpe_audio_pdata { bool notify_pending; int tmds_clock_speed; bool hdmi_connected; + bool dp_output; + int link_rate; struct intel_hdmi_lpe_audio_eld eld; void (*notify_audio_lpe)(void *audio_ptr); spinlock_t lpe_audio_slock; -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/7] DisplayPort audio support on Cherrytrail
Hi, the following patches enable DisplayPort Audio on Cherrytrail machines when applied on top of my topic/intel-lpe-audio branch. Tests of DP audio were run on Dell Wyse 3040. The regression test were performed on Baytrail (Compute Stick) and Cherrytrail (Zotac PI330) in HDMI mode. On Cherrytrail there were no issues changing between HDMI and DP connectors dynamically. Could you i915 people review and give ACK if they are OK? The changes in drm/i915 side are fairly trivial, so I'd like to take them through sound git tree once after I receive your ACKs. Changes since RFC: - reordered and squashed patches - clean-up of register definitions and offsets (based on feedback from Jani/Ville) - unmute amp for both HDMI and DP unconditionally - mute amp on invalid ELD (unplug) - remove test for chicken bit which seems to have no effect in hardware - cosmetic edits to make checkpatch happy - change i915 notification argument to pass the plataform device instead Most of hard work in this patchset has been done by Pierre, so all credits go to him. thanks, Takashi === Pierre-Louis Bossart (4): drm/i915: add DP support in LPE audio mode drm/i915: add DisplayPort amp unmute for LPE audio mode ALSA: x86: intel_hdmi: add definitions and logic for DP audio ALSA: x86: Use config base depending on the pipe Takashi Iwai (3): drm/i915: Avoid MST pipe handling for LPE audio drm/i915: Pass pipe to LPE audio notification drm/i915: Pass platform device to LPE audio notifier drivers/gpu/drm/i915/i915_drv.h| 3 +- drivers/gpu/drm/i915/i915_reg.h| 10 ++ drivers/gpu/drm/i915/intel_audio.c | 38 +--- drivers/gpu/drm/i915/intel_lpe_audio.c | 28 +- include/drm/intel_lpe_audio.h | 7 +- sound/x86/intel_hdmi_audio.c | 173 - sound/x86/intel_hdmi_audio.h | 8 +- sound/x86/intel_hdmi_lpe_audio.c | 83 sound/x86/intel_hdmi_lpe_audio.h | 29 ++ 9 files changed, 315 insertions(+), 64 deletions(-) -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/2] drm/i915: Backport vma fixes for 4.10-rc6
On Tue, Jan 31, 2017 at 12:28:40PM -0800, Linus Torvalds wrote: > On Tue, Jan 31, 2017 at 1:21 AM, Maarten Lankhorst >wrote: > > > > This is marked for rc6 because it seems the issue is triggerable on > > mainline and resulting in an oops. > > So I did apply my obvious "avoid the oops and just warn about it" > patch: commit 39cb2c9a316e ("drm/i915: Check for NULL i915_vma in > intel_unpin_fb_obj()"). > > I haven't actually triggered the problem since, so I don't know if > there might be some other downstream issue, but the workaround *may* > just be acceptable from a 4.10 standpoint. You need sufficient memory pressure to start using partial views, and then kill the X server while it's using that partial view still (i.e. not too much memory pressure to prevent them from getting evicted). And it's global gttt pressure, so not much do to with what's going on on your machine. So hard to hit, but when you do the book-keeping is rather completely wreaked since we throw away the views while they're still in use. > Some maintainer who knows the code better should make the judgment call. It's a lot less scary than what I thought: - the cherry picks needed are a lot less than what I feared, a lot of the prep work landed in 4.10 and a bunch of it in patches in linux-next aren't needed for 4.10 due to other reasons. - we have a testcase to repro this instantly. It uses rotation instead of partial views (which depend upon allocation order to hit the bug, rotation is deterministic), but the same code blows up for the same reasons because it's a bug in the view code, not with a specific view. The only thing that's mildly scary is that we need a drm core patch to make it happen. But that one has been for a while in linux-next too, so should be acceptable. Only thing left to do is let CI beat on this specifically for a bit, so pull request should be ready for -rc7 I hope. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/2] drm/i915: Backport vma fixes for 4.10-rc6
On Tue, Jan 31, 2017 at 1:21 AM, Maarten Lankhorstwrote: > > This is marked for rc6 because it seems the issue is triggerable on > mainline and resulting in an oops. So I did apply my obvious "avoid the oops and just warn about it" patch: commit 39cb2c9a316e ("drm/i915: Check for NULL i915_vma in intel_unpin_fb_obj()"). I haven't actually triggered the problem since, so I don't know if there might be some other downstream issue, but the workaround *may* just be acceptable from a 4.10 standpoint. Some maintainer who knows the code better should make the judgment call. Linus ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm-misc: Document small drivers expectations
On Tue, Jan 31, 2017 at 02:31:32PM -0500, Sean Paul wrote: > On Tue, Jan 31, 2017 at 07:01:44PM +0100, Daniel Vetter wrote: > > For the experiement we have right now Eric (with vc4) and Sean Paul > > (with rockchip and zte) volunteering, and Gerd (entire pile of qemu > > drivers) and Boris (atmel) are also considering to participate. I > > think that's enough to get started and figure things out as we go. > > > > I tried to summarize the main points from the rfc discussions into a > > short chapter. > > Did we decide on whether we're using a topic branch to start out? Also, are > you > on the hook for pull requests? Hm, I guess that was too implicit. The idea is that anything small goes directly into drm-misc-next, and only really huge stuff (I've picked an arbitrary limit of 20+ patches) goes into a topic branch. That's definitely something we need to refine as we go I think. But for one-off patches I think the common tree is really a benefit, since no coordination between subsytem wide refactoring and driver patches is needed through pull requests. And yes since it's the same tree I'm volunteering for pull requests. dim status tells me when there's something pending (I wrote that a bit ago as prep to make drm-misc easy for me). -Daniel > > Sean > > > > > v2: Spelling fixes (Anholt). > > > > Cc: Boris Brezillon> > Cc: Eric Anholt > > Cc: Sean Paul > > Cc: Gerd Hoffmann > > Cc: Mark Yao > > Cc: Shawn Guo > > Acked-by: Sean Paul > > Acked-by: Gerd Hoffmann > > Acked-by: Boris Brezillon > > Acked-by: Eric Anholt > > Signed-off-by: Daniel Vetter > > --- > > drm-misc.rst | 30 ++ > > 1 file changed, 30 insertions(+) > > > > diff --git a/drm-misc.rst b/drm-misc.rst > > index 3d711ec60047..7f7233cf3c61 100644 > > --- a/drm-misc.rst > > +++ b/drm-misc.rst > > @@ -93,6 +93,36 @@ Right now the only hard merge criteria are: > > * See also the extensive `committer guidelines for drm-intel > > `_. > > > > +Small Drivers > > += > > + > > +Small drivers, where a full tree is overkill, can be maintained in > > drm-misc. For > > +now it's just an experiment with a few drivers to figure out a working > > process. > > +Slightly different rules apply: > > + > > +* Small is measured in patches merged per kernel release. The occasional > > big > > + patch series is still acceptable if it's not a common thing (e.g. new hw > > + enabling once a year), and if the series is really big (more than 20 > > patches) > > + it should probably be managed through a topic branch in drm-misc and > > with a > > + separate pull request to drm maintainer. dim_ supports this with the > > + create-branch command. > > + > > +* Group maintainership is assumed, i.e. all regular contributors (not just > > + the primary maintainer) will get commit rights. > > + > > +* Since even a broken driver is more useful than no driver minimal review > > + standards are a lot lower. The default should be some notes about what > > could > > + be improved in follow-up work and accepting patches by default. > > Maintainer > > + group for drivers can agree on stricter rules, especially when they have > > a > > + bigger user base that shouldn't suffer from regressions. > > + > > +* Minimal peer-review is also expected for drivers with just one > > contributor, > > + but obviously then only focuses on best practices for the interaction > > with drm > > + core and helpers. Plus a bit looking for common patterns in dealing with > > the > > + hardware, since display IP all has to handle the same issues in the end. > > In > > + most cases this will just along the lines of "Looks good, Ack". drm-misc > > + maintainers will help out with getting that review market going. > > + > > Tooling > > === > > > > -- > > 2.11.0 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Sean Paul, Software Engineer, Google / Chromium OS -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm-misc: Document small drivers expectations
On Tue, Jan 31, 2017 at 07:01:44PM +0100, Daniel Vetter wrote: > For the experiement we have right now Eric (with vc4) and Sean Paul > (with rockchip and zte) volunteering, and Gerd (entire pile of qemu > drivers) and Boris (atmel) are also considering to participate. I > think that's enough to get started and figure things out as we go. > > I tried to summarize the main points from the rfc discussions into a > short chapter. Did we decide on whether we're using a topic branch to start out? Also, are you on the hook for pull requests? Sean > > v2: Spelling fixes (Anholt). > > Cc: Boris Brezillon> Cc: Eric Anholt > Cc: Sean Paul > Cc: Gerd Hoffmann > Cc: Mark Yao > Cc: Shawn Guo > Acked-by: Sean Paul > Acked-by: Gerd Hoffmann > Acked-by: Boris Brezillon > Acked-by: Eric Anholt > Signed-off-by: Daniel Vetter > --- > drm-misc.rst | 30 ++ > 1 file changed, 30 insertions(+) > > diff --git a/drm-misc.rst b/drm-misc.rst > index 3d711ec60047..7f7233cf3c61 100644 > --- a/drm-misc.rst > +++ b/drm-misc.rst > @@ -93,6 +93,36 @@ Right now the only hard merge criteria are: > * See also the extensive `committer guidelines for drm-intel > `_. > > +Small Drivers > += > + > +Small drivers, where a full tree is overkill, can be maintained in drm-misc. > For > +now it's just an experiment with a few drivers to figure out a working > process. > +Slightly different rules apply: > + > +* Small is measured in patches merged per kernel release. The occasional big > + patch series is still acceptable if it's not a common thing (e.g. new hw > + enabling once a year), and if the series is really big (more than 20 > patches) > + it should probably be managed through a topic branch in drm-misc and with a > + separate pull request to drm maintainer. dim_ supports this with the > + create-branch command. > + > +* Group maintainership is assumed, i.e. all regular contributors (not just > + the primary maintainer) will get commit rights. > + > +* Since even a broken driver is more useful than no driver minimal review > + standards are a lot lower. The default should be some notes about what > could > + be improved in follow-up work and accepting patches by default. Maintainer > + group for drivers can agree on stricter rules, especially when they have a > + bigger user base that shouldn't suffer from regressions. > + > +* Minimal peer-review is also expected for drivers with just one contributor, > + but obviously then only focuses on best practices for the interaction with > drm > + core and helpers. Plus a bit looking for common patterns in dealing with > the > + hardware, since display IP all has to handle the same issues in the end. In > + most cases this will just along the lines of "Looks good, Ack". drm-misc > + maintainers will help out with getting that review market going. > + > Tooling > === > > -- > 2.11.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Sean Paul, Software Engineer, Google / Chromium OS ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH RFC] drm/i915: reduce cursor size for GEN5 hardware
Hello, On Tue, Jan 31, 2017 at 10:03:26AM +0100, Maarten Lankhorst wrote: > Op 31-01-17 om 09:09 schreef Uwe Kleine-König: > > From: Chris Wilson> > > > As the introduced comment admits this is clearly a workaround, but for > > me this is the only known way to make my Lenovo X201 work without > > flickering and crashing. > > > > Signed-off-by: Uwe Kleine-König > > [uwe: added changelog, comment and restrict to GEN5] > > --- > > Hello, > > > > as I don't like having to compile my own kernel (which has this workaround) > > I > > suggest to apply this patch until someone with more knowledge than me about > > i915 finds the muse and time to work on this. > > Just curious, does this help? > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index ae2c0bb4b2e8..13de4c526ca6 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -1838,7 +1838,7 @@ static uint32_t ilk_compute_cur_wm(const struct > intel_crtc_state *cstate, >* this is necessary to avoid flickering. >*/ > int cpp = 4; > - int width = pstate->base.visible ? pstate->base.crtc_w : 64; > + int width = 256; > > if (!cstate->base.active) > return 0; > On a kernel with this patch applied I cannot reproduce the flickering. I keep that kernel running but expect that it also fixes the crash. Best regards Uwe signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/gen9: WM memory bandwidth related workaround
Hi Mahesh, [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on next-20170130] [cannot apply to v4.10-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Mahesh-Kumar/Enable-IPC-WM-related-WA-s/20170131-230708 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: i386-allmodconfig (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=i386 All warnings (new ones prefixed by >>): In file included from arch/x86/include/asm/string.h:2:0, from include/linux/string.h:18, from arch/x86/include/asm/page_32.h:34, from arch/x86/include/asm/page.h:13, from arch/x86/include/asm/processor.h:17, from include/linux/mutex.h:19, from include/linux/notifier.h:13, from include/linux/clk.h:17, from include/linux/cpufreq.h:14, from drivers/gpu/drm/i915/intel_pm.c:28: drivers/gpu/drm/i915/intel_pm.c: In function 'skl_compute_memory_bandwidth_wm_wa': >> drivers/gpu/drm/i915/intel_pm.c:4118:56: warning: argument to 'sizeof' in >> '__builtin_memcpy' call is the same expression as the destination; did you >> mean to dereference it? [-Wsizeof-pointer-memaccess] memcpy(mem_attr, _priv->wm.skl_hw.mem_attr, sizeof(mem_attr)); ^ arch/x86/include/asm/string_32.h:182:48: note: in definition of macro 'memcpy' #define memcpy(t, f, n) __builtin_memcpy(t, f, n) ^ vim +4118 drivers/gpu/drm/i915/intel_pm.c 4102 mem_attr->mem_wa = WATERMARK_WA_NONE; 4103 return 0; 4104 } 4105 4106 if (!memdev_info->valid) 4107 goto exit; 4108 4109 /* 4110 * We hold wm_mutex lock, so any other flip can't proceed beyond WM 4111 * calculation step until this flip writes modified WM values. 4112 * So it's safe to read plane_state of other pipes without taking CRTC lock 4113 */ 4114 ret = drm_modeset_lock(_priv->wm.wm_ww_mutex, state->acquire_ctx); 4115 if (ret) 4116 return ret; 4117 > 4118 memcpy(mem_attr, _priv->wm.skl_hw.mem_attr, > sizeof(mem_attr)); 4119 4120 for_each_crtc_in_state(state, crtc, cstate, i) { 4121 struct drm_plane *plane; 4122 const struct drm_plane_state *pstate; 4123 int active_planes = 0; 4124 uint32_t max_plane_bw_kbps = 0; 4125 4126 mem_attr->pipe_y_tiled[i] = false; --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm-misc: Document small drivers expectations
For the experiement we have right now Eric (with vc4) and Sean Paul (with rockchip and zte) volunteering, and Gerd (entire pile of qemu drivers) and Boris (atmel) are also considering to participate. I think that's enough to get started and figure things out as we go. I tried to summarize the main points from the rfc discussions into a short chapter. v2: Spelling fixes (Anholt). Cc: Boris BrezillonCc: Eric Anholt Cc: Sean Paul Cc: Gerd Hoffmann Cc: Mark Yao Cc: Shawn Guo Acked-by: Sean Paul Acked-by: Gerd Hoffmann Acked-by: Boris Brezillon Acked-by: Eric Anholt Signed-off-by: Daniel Vetter --- drm-misc.rst | 30 ++ 1 file changed, 30 insertions(+) diff --git a/drm-misc.rst b/drm-misc.rst index 3d711ec60047..7f7233cf3c61 100644 --- a/drm-misc.rst +++ b/drm-misc.rst @@ -93,6 +93,36 @@ Right now the only hard merge criteria are: * See also the extensive `committer guidelines for drm-intel `_. +Small Drivers += + +Small drivers, where a full tree is overkill, can be maintained in drm-misc. For +now it's just an experiment with a few drivers to figure out a working process. +Slightly different rules apply: + +* Small is measured in patches merged per kernel release. The occasional big + patch series is still acceptable if it's not a common thing (e.g. new hw + enabling once a year), and if the series is really big (more than 20 patches) + it should probably be managed through a topic branch in drm-misc and with a + separate pull request to drm maintainer. dim_ supports this with the + create-branch command. + +* Group maintainership is assumed, i.e. all regular contributors (not just + the primary maintainer) will get commit rights. + +* Since even a broken driver is more useful than no driver minimal review + standards are a lot lower. The default should be some notes about what could + be improved in follow-up work and accepting patches by default. Maintainer + group for drivers can agree on stricter rules, especially when they have a + bigger user base that shouldn't suffer from regressions. + +* Minimal peer-review is also expected for drivers with just one contributor, + but obviously then only focuses on best practices for the interaction with drm + core and helpers. Plus a bit looking for common patterns in dealing with the + hardware, since display IP all has to handle the same issues in the end. In + most cases this will just along the lines of "Looks good, Ack". drm-misc + maintainers will help out with getting that review market going. + Tooling === -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-fixes
Hi Dave, 2 patches to fix the oops Dave Hanse reported, plus a double kfree fix Maarten discovered while backporting the fix for Linus. For Linus' vma tracking oops the plan is to send you a dedicated pull with the 2 patches we need, but since it's tricky we're letting CI beat on it a bit more. Cheers, Daniel The following changes since commit 566cf877a1fcb6d6dc0126b076aad062054c2637: Linux 4.10-rc6 (2017-01-29 14:25:17 -0800) are available in the git repository at: git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-fixes-2017-01-31 for you to fetch changes up to 92c715fca907686f5298220ece53423e38ba3aed: drm/atomic: Fix double free in drm_atomic_state_default_clear (2017-01-31 13:41:46 +0100) Daniel Vetter (2): drm: prevent double-(un)registration for connectors drm: Don't race connector registration Maarten Lankhorst (1): drm/atomic: Fix double free in drm_atomic_state_default_clear drivers/gpu/drm/drm_atomic.c| 13 - drivers/gpu/drm/drm_connector.c | 23 ++- drivers/gpu/drm/drm_drv.c | 4 include/drm/drmP.h | 1 + include/drm/drm_connector.h | 16 +++- 5 files changed, 46 insertions(+), 11 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/gen9: WM memory bandwidth related workaround
Hi Mahesh, [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on next-20170130] [cannot apply to v4.10-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Mahesh-Kumar/Enable-IPC-WM-related-WA-s/20170131-230708 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: x86_64-rhel (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All warnings (new ones prefixed by >>): drivers/gpu/drm/i915/intel_pm.c: In function 'skl_compute_memory_bandwidth_wm_wa': >> drivers/gpu/drm/i915/intel_pm.c:4118:56: warning: argument to 'sizeof' in >> 'memcpy' call is the same expression as the destination; did you mean to >> dereference it? [-Wsizeof-pointer-memaccess] memcpy(mem_attr, _priv->wm.skl_hw.mem_attr, sizeof(mem_attr)); ^ vim +4118 drivers/gpu/drm/i915/intel_pm.c 4102 mem_attr->mem_wa = WATERMARK_WA_NONE; 4103 return 0; 4104 } 4105 4106 if (!memdev_info->valid) 4107 goto exit; 4108 4109 /* 4110 * We hold wm_mutex lock, so any other flip can't proceed beyond WM 4111 * calculation step until this flip writes modified WM values. 4112 * So it's safe to read plane_state of other pipes without taking CRTC lock 4113 */ 4114 ret = drm_modeset_lock(_priv->wm.wm_ww_mutex, state->acquire_ctx); 4115 if (ret) 4116 return ret; 4117 > 4118 memcpy(mem_attr, _priv->wm.skl_hw.mem_attr, > sizeof(mem_attr)); 4119 4120 for_each_crtc_in_state(state, crtc, cstate, i) { 4121 struct drm_plane *plane; 4122 const struct drm_plane_state *pstate; 4123 int active_planes = 0; 4124 uint32_t max_plane_bw_kbps = 0; 4125 4126 mem_attr->pipe_y_tiled[i] = false; --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v3 05/11] lib/igt_kms: Added igt_pipe_get_last_out_fence()
On Mon, Jan 30, 2017 at 08:58:41PM -0500, Robert Foss wrote: Added the igt_pipe_get_last_out_fence() helper function that wraps accesses to pipe->fence_out. Signed-off-by: Robert Foss--- lib/igt_kms.c | 8 lib/igt_kms.h | 1 + 2 files changed, 9 insertions(+) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index 142658a6..f0e38b75 100644 --- a/lib/igt_kms.c +++ b/lib/igt_kms.c @@ -1934,6 +1934,14 @@ static igt_output_t *igt_pipe_get_output(igt_pipe_t *pipe) return NULL; } +int igt_pipe_get_last_out_fence(igt_pipe_t *pipe) +{ + int fd = (int) pipe->out_fence; + pipe->out_fence = -1; + + return fd; If this wasn't the compile error you already found, then "out_fence" doesn't seem to have been added to igt_pipe_t yet. -Brian +} + bool igt_pipe_get_property(igt_pipe_t *pipe, const char *name, uint32_t *prop_id, uint64_t *value, drmModePropertyPtr *prop) diff --git a/lib/igt_kms.h b/lib/igt_kms.h index 00e0dc68..94ff27bb 100644 --- a/lib/igt_kms.h +++ b/lib/igt_kms.h @@ -382,6 +382,7 @@ igt_plane_t *igt_output_get_plane_type(igt_output_t *output, int plane_type); igt_output_t *igt_output_from_connector(igt_display_t *display, drmModeConnector *connector); igt_plane_t *igt_pipe_get_plane_type(igt_pipe_t *pipe, int plane_type); +int igt_pipe_get_last_out_fence(igt_pipe_t *pipe); bool igt_pipe_get_property(igt_pipe_t *pipe, const char *name, uint32_t *prop_id, uint64_t *value, drmModePropertyPtr *prop); -- 2.11.0.453.g787f75f05 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v3 11/11] tests/kms_atomic_transition: add in_fences tests
On Mon, Jan 30, 2017 at 08:58:47PM -0500, Robert Foss wrote: From: Gustavo PadovanSigned-off-by: Gustavo Padovan Signed-off-by: Robert Foss --- lib/igt_kms.c | 3 +++ tests/kms_atomic_transition.c | 48 ++- 2 files changed, 32 insertions(+), 19 deletions(-) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index 523f3f57..bc815363 100644 --- a/lib/igt_kms.c +++ b/lib/igt_kms.c @@ -2009,6 +2009,9 @@ igt_atomic_prepare_plane_commit(igt_plane_t *plane, igt_pipe_t *pipe, if (plane->fence_fd >= 0) { uint64_t fence_fd = (int64_t) plane->fence_fd; igt_atomic_populate_plane_req(req, plane, IGT_PLANE_IN_FENCE_FD, fence_fd); + + /* reset fence_fd to prevent it from being set for the next commit */ + plane->fence_fd = -1; Who closes it? } if (plane->fb_changed) { diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c index eebb5d66..0876bbb3 100644 --- a/tests/kms_atomic_transition.c +++ b/tests/kms_atomic_transition.c @@ -23,7 +23,9 @@ #include "igt.h" #include "drmtest.h" +#include "sw_sync.h" #include +#include #include #include #include @@ -362,6 +364,9 @@ run_transition_test(igt_display_t *display, enum pipe pipe, igt_output_t *output unsigned flags = DRM_MODE_PAGE_FLIP_EVENT; int ret; + if (fencing) + prepare_fencing(display, pipe); + if (nonblocking) flags |= DRM_MODE_ATOMIC_NONBLOCK; @@ -404,18 +409,19 @@ run_transition_test(igt_display_t *display, enum pipe pipe, igt_output_t *output wm_setup_plane(display, pipe, iter_max - 1, parms); if (fencing) - igt_pipe_set_out_fence_ptr(>pipes[pipe], - (int64_t *) _fence); + igt_pipe_request_out_fence(>pipes[pipe]); + Hopefully this can get rebased away? I'm getting confused about what's actually being added/changed in this commit. ret = igt_display_try_commit_atomic(display, DRM_MODE_ATOMIC_TEST_ONLY | DRM_MODE_ATOMIC_ALLOW_MODESET, NULL); - if (ret != -EINVAL || n_planes < 3) + if (ret != -EINVAL || display->pipes[pipe].n_planes < 3) break; ret = 0; for_each_plane_on_pipe(display, pipe, plane) { i = plane->index; - if (plane->is_primary || plane->is_cursor) + if (plane->type == DRM_PLANE_TYPE_PRIMARY || + plane->type == DRM_PLANE_TYPE_CURSOR) continue; This seems spurious? ... A bit more add/remove churn below which can hopefully go away with a rebase. Cheers, -Brian if (parms[i].width <= 512) @@ -436,10 +442,8 @@ run_transition_test(igt_display_t *display, enum pipe pipe, igt_output_t *output wm_setup_plane(display, pipe, i, parms); - if (fencing) - igt_pipe_set_out_fence_ptr(>pipes[pipe], _fence); + atomic_commit(display, pipe, flags, (void *)(unsigned long)i, fencing); - igt_display_commit_atomic(display, flags, (void *)(unsigned long)i); drmHandleEvent(display->drm_fd, _events); if (type == TRANSITION_MODESET_DISABLE) { @@ -463,19 +467,14 @@ run_transition_test(igt_display_t *display, enum pipe pipe, igt_output_t *output if (type == TRANSITION_MODESET) igt_output_override_mode(output, _mode); - if (fencing) - igt_pipe_set_out_fence_ptr(>pipes[pipe], _fence); - - igt_display_commit_atomic(display, flags, (void *)(unsigned long)j); + atomic_commit(display, pipe, flags, (void *)(unsigned long)i, fencing); drmHandleEvent(display->drm_fd, _events); wm_setup_plane(display, pipe, i, parms); if (type == TRANSITION_MODESET) igt_output_override_mode(output, NULL); - if (fencing) - igt_pipe_set_out_fence_ptr(>pipes[pipe], _fence); - + atomic_commit(display, pipe, flags, (void *)(unsigned long)i, fencing); igt_display_commit_atomic(display, flags, (void *)(unsigned long)i); drmHandleEvent(display->drm_fd, _events); } @@ -483,6 +482,8 @@ run_transition_test(igt_display_t *display, enum pipe pipe, igt_output_t *output } cleanup: +
Re: [Intel-gfx] [PATCH i-g-t v3 10/11] tests/kms_atomic_transition: add out_fences tests
On Mon, Jan 30, 2017 at 08:58:46PM -0500, Robert Foss wrote: Signed-off-by: Gustavo PadovanSigned-off-by: Robert Foss --- lib/igt_kms.c | 35 ++ tests/kms_atomic_transition.c | 148 ++ 2 files changed, 169 insertions(+), 14 deletions(-) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index f14496dd..523f3f57 100644 --- a/lib/igt_kms.c +++ b/lib/igt_kms.c @@ -53,6 +53,7 @@ #include "intel_chipset.h" #include "igt_debugfs.h" #include "igt_sysfs.h" +#include "sw_sync.h" /** * SECTION:igt_kms @@ -2479,6 +2480,21 @@ static int igt_atomic_commit(igt_display_t *display, uint32_t flags, void *user_ } ret = drmModeAtomicCommit(display->drm_fd, req, flags, user_data); + if (!ret) { + + for_each_pipe(display, pipe) { + igt_pipe_t *pipe_obj = >pipes[pipe]; + + if (pipe_obj->out_fence != -1) + continue; Should be "if (pipe_obj->fence == -1)" ? The stuff below seems to be assuming the fence is valid. + + igt_assert(pipe_obj->out_fence >= 0); + ret = sync_fence_wait(pipe_obj->out_fence, 1000); + igt_assert(ret == 0); + close(pipe_obj->out_fence); + } + } + drmModeAtomicFree(req); return ret; @@ -2972,6 +2988,11 @@ void igt_plane_set_rotation(igt_plane_t *plane, igt_rotation_t rotation) plane->rotation_changed = true; } +void igt_pipe_request_out_fence(igt_pipe_t *pipe) Oh here it is! +{ + pipe->out_fence_requested = true; +} + void igt_pipe_set_degamma_lut(igt_pipe_t *pipe, void *ptr, size_t length) { @@ -2994,20 +3015,6 @@ igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr, size_t length) } /** - * igt_pipe_set_out_fence_ptr: - * @pipe: pipe pointer to which background color to be set - * @fence_ptr: out fence pointer - * - * Sets the out fence pointer that will be passed to the kernel in - * the atomic ioctl. When the kernel returns the out fence pointer - * will contain the fd number of the out fence created by KMS. - */ -void igt_pipe_set_out_fence_ptr(igt_pipe_t *pipe, int64_t *fence_ptr) ... and there this one goes. This deletion and the function above need to be squashed into the earlier commit I suppose. -{ - pipe->out_fence_ptr = fence_ptr; -} - -/** * igt_crtc_set_background: * @pipe: pipe pointer to which background color to be set * @background: background color value in BGR 16bpc diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c index 72429759..eebb5d66 100644 --- a/tests/kms_atomic_transition.c +++ b/tests/kms_atomic_transition.c @@ -253,6 +253,93 @@ retry: sprite_width, sprite_height, alpha); } +int *timeline; +pthread_t *thread; +int *seqno; + +static void prepare_fencing(igt_display_t *display, enum pipe pipe) +{ + igt_plane_t *plane; + int n_planes; + + igt_require_sw_sync(); + + n_planes = display->pipes[pipe].n_planes; +timeline = calloc(sizeof(*timeline), n_planes); +igt_assert_f(timeline != NULL, "Failed to allocate memory for timelines\n"); +thread = calloc(sizeof(*thread), n_planes); +igt_assert_f(thread != NULL, "Failed to allocate memory for thread\n"); +seqno = calloc(sizeof(*seqno), n_planes); +igt_assert_f(seqno != NULL, "Failed to allocate memory for seqno\n"); The 6 lines above are space-indented + + for_each_plane_on_pipe(display, pipe, plane) + timeline[plane->index] = sw_sync_timeline_create(); +} + +static void unprepare_fencing(igt_display_t *display, enum pipe pipe) +{ + igt_plane_t *plane; + + for_each_plane_on_pipe(display, pipe, plane) + close(timeline[plane->index]); + + free(timeline); + free(thread); + free(seqno); +} + +static void *fence_inc_thread(void *arg) +{ + int t = *((int *) arg); + + pthread_detach(pthread_self()); + + usleep(5000); + sw_sync_timeline_inc(t, 1); + return NULL; +} + +static void configure_fencing(igt_display_t *display, enum pipe pipe) +{ + igt_plane_t *plane; + int i, fd, ret; + + for_each_plane_on_pipe(display, pipe, plane) { + + if (!plane->fb) + continue; + + i = plane->index; + + seqno[i]++; + fd = sw_sync_timeline_create_fence(timeline[i], seqno[i]); + igt_plane_set_fence_fd(plane, fd); + ret = pthread_create([i], NULL, fence_inc_thread, [i]); + igt_assert_eq(ret, 0); + } +} + +static void clear_fencing(igt_display_t *display, enum pipe pipe) +{ + igt_plane_t *plane; + + for_each_plane_on_pipe(display, pipe, plane) + igt_plane_set_fence_fd(plane, -1); Someone should close
Re: [Intel-gfx] [PATCH i-g-t v3 08/11] tests/kms_atomic: stress possible fence settings
This one lgtm, just need to swap all the uint64_t out_fence_ptrs for int32_t. -Brian On Mon, Jan 30, 2017 at 08:58:44PM -0500, Robert Foss wrote: From: Gustavo PadovanSigned-off-by: Gustavo Padovan Signed-off-by: Robert Foss --- tests/kms_atomic.c | 187 ++--- 1 file changed, 177 insertions(+), 10 deletions(-) diff --git a/tests/kms_atomic.c b/tests/kms_atomic.c index 8df51ccd..09605e38 100644 --- a/tests/kms_atomic.c +++ b/tests/kms_atomic.c @@ -44,6 +44,7 @@ #include "drmtest.h" #include "igt.h" #include "igt_aux.h" +#include "sw_sync.h" #ifndef DRM_CLIENT_CAP_ATOMIC #define DRM_CLIENT_CAP_ATOMIC 3 @@ -126,6 +127,7 @@ struct kms_atomic_plane_state { uint32_t fb_id; /* 0 to disable */ uint32_t src_x, src_y, src_w, src_h; /* 16.16 fixed-point */ uint32_t crtc_x, crtc_y, crtc_w, crtc_h; /* normal integers */ + int32_t fence_fd; }; struct kms_atomic_crtc_state { @@ -133,6 +135,7 @@ struct kms_atomic_crtc_state { uint32_t obj; int idx; bool active; + uint64_t out_fence_ptr; struct kms_atomic_blob mode; }; @@ -190,11 +193,13 @@ static uint32_t blob_duplicate(int fd, uint32_t id_orig) crtc_populate_req(crtc, req); \ plane_populate_req(plane, req); \ do_atomic_commit((crtc)->state->desc->fd, req, flags); \ - crtc_check_current_state(crtc, plane, relax); \ - plane_check_current_state(plane, relax); \ + if (!(flags & DRM_MODE_ATOMIC_TEST_ONLY)) { \ + crtc_check_current_state(crtc, plane, relax); \ + plane_check_current_state(plane, relax); \ + } \ } -#define crtc_commit_atomic_err(crtc, plane, crtc_old, plane_old, req, relax, e) { \ +#define crtc_commit_atomic_err(crtc, plane, crtc_old, plane_old, req, flags, relax, e) { \ drmModeAtomicSetCursor(req, 0); \ crtc_populate_req(crtc, req); \ plane_populate_req(plane, req); \ @@ -299,6 +304,9 @@ find_connector(struct kms_atomic_state *state, static void plane_populate_req(struct kms_atomic_plane_state *plane, drmModeAtomicReq *req) { + if (plane->fence_fd) + plane_set_prop(req, plane, IGT_PLANE_IN_FENCE_FD, plane->fence_fd); + plane_set_prop(req, plane, IGT_PLANE_CRTC_ID, plane->crtc_id); plane_set_prop(req, plane, IGT_PLANE_FB_ID, plane->fb_id); plane_set_prop(req, plane, IGT_PLANE_SRC_X, plane->src_x); @@ -433,6 +441,10 @@ find_plane(struct kms_atomic_state *state, enum plane_type type, static void crtc_populate_req(struct kms_atomic_crtc_state *crtc, drmModeAtomicReq *req) { + if (crtc->out_fence_ptr) + crtc_set_prop(req, crtc, IGT_CRTC_OUT_FENCE_PTR, + crtc->out_fence_ptr); + crtc_set_prop(req, crtc, IGT_CRTC_MODE_ID, crtc->mode.id); crtc_set_prop(req, crtc, IGT_CRTC_ACTIVE, crtc->active); } @@ -1061,6 +1073,37 @@ static void plane_invalid_params(struct kms_atomic_crtc_state *crtc, drmModeAtomicFree(req); } +static void plane_invalid_params_fence(struct kms_atomic_crtc_state *crtc, + struct kms_atomic_plane_state *plane_old, + struct kms_atomic_connector_state *conn) +{ + struct kms_atomic_plane_state plane = *plane_old; + drmModeAtomicReq *req = drmModeAtomicAlloc(); + int timeline, fence_fd; + + igt_require_sw_sync(); + + /* invalid fence fd */ + plane.fence_fd = plane.state->desc->fd; + plane.crtc_id = plane_old->crtc_id; + plane_commit_atomic_err(, plane_old, req, + ATOMIC_RELAX_NONE, EINVAL); + + /* Valid fence_fd but invalid CRTC */ + timeline = sw_sync_timeline_create(); + fence_fd = sw_sync_timeline_create_fence(timeline, 1); + plane.fence_fd = fence_fd; + plane.crtc_id = ~0U; + plane_commit_atomic_err(, plane_old, req, + ATOMIC_RELAX_NONE, EINVAL); + + plane.fence_fd = -1; + close(fence_fd); + close(timeline); + + drmModeAtomicFree(req); +} + static void crtc_invalid_params(struct kms_atomic_crtc_state *crtc_old, struct kms_atomic_plane_state *plane, struct kms_atomic_connector_state *conn) @@ -1072,30 +1115,32 @@ static void crtc_invalid_params(struct kms_atomic_crtc_state *crtc_old, /* Pass a series of invalid object IDs for the mode ID. */ crtc.mode.id = plane->obj; - crtc_commit_atomic_err(, plane, crtc_old, plane, req, + crtc_commit_atomic_err(, plane, crtc_old, plane, req, 0, ATOMIC_RELAX_NONE, EINVAL); crtc.mode.id = crtc.obj; - crtc_commit_atomic_err(, plane, crtc_old, plane, req, +
Re: [Intel-gfx] [PATCH i-g-t v3 07/11] lib/igt_kms: Add support for the OUT_FENCE_PTR property
On Mon, Jan 30, 2017 at 08:58:43PM -0500, Robert Foss wrote: From: Gustavo PadovanAdd support for the OUT_FENCE_PTR property to enable setting out fences for atomic commits. Signed-off-by: Gustavo Padovan Signed-off-by: Robert Foss --- lib/igt_kms.c | 26 +- lib/igt_kms.h | 6 +- 2 files changed, 30 insertions(+), 2 deletions(-) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index b79d2867..f14496dd 100644 --- a/lib/igt_kms.c +++ b/lib/igt_kms.c @@ -179,7 +179,8 @@ const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = { "DEGAMMA_LUT", "GAMMA_LUT", "MODE_ID", - "ACTIVE" + "ACTIVE", + "OUT_FENCE_PTR" }; const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = { @@ -2393,6 +2394,15 @@ static void igt_atomic_prepare_crtc_commit(igt_pipe_t *pipe_obj, drmModeAtomicRe igt_atomic_populate_crtc_req(req, pipe_obj, IGT_CRTC_ACTIVE, !!output); } + pipe_obj->out_fence = -1; + if (pipe_obj->out_fence_requested) + { + pipe_obj->out_fence_requested = false; + igt_atomic_populate_crtc_req(req, pipe_obj, IGT_CRTC_OUT_FENCE_PTR, + (uint64_t)(uintptr_t) _obj->out_fence); + igt_assert_f(pipe_obj->out_fence != -1, "Unable to get fence, received -1 fd\n"); Doesn't this assertion always fail? You just set it to -1 + } + /* * TODO: Add all crtc level properties here */ @@ -2984,6 +2994,20 @@ igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr, size_t length) } /** + * igt_pipe_set_out_fence_ptr: + * @pipe: pipe pointer to which background color to be set + * @fence_ptr: out fence pointer + * + * Sets the out fence pointer that will be passed to the kernel in + * the atomic ioctl. When the kernel returns the out fence pointer + * will contain the fd number of the out fence created by KMS. + */ +void igt_pipe_set_out_fence_ptr(igt_pipe_t *pipe, int64_t *fence_ptr) +{ + pipe->out_fence_ptr = fence_ptr; +} Is this ever used? You seem to use _obj->out_fence unconditionally above (and igt_pipe has no member named out_fence_ptr). I guess is left over from the previous API and needs to be removed? + +/** * igt_crtc_set_background: * @pipe: pipe pointer to which background color to be set * @background: background color value in BGR 16bpc diff --git a/lib/igt_kms.h b/lib/igt_kms.h index 85688853..9672dadc 100644 --- a/lib/igt_kms.h +++ b/lib/igt_kms.h @@ -94,6 +94,7 @@ enum igt_atomic_crtc_properties { IGT_CRTC_GAMMA_LUT, IGT_CRTC_MODE_ID, IGT_CRTC_ACTIVE, + IGT_CRTC_OUT_FENCE_PTR, IGT_NUM_CRTC_PROPS }; @@ -341,6 +342,9 @@ struct igt_pipe { uint64_t mode_blob; bool mode_changed; + + int64_t out_fence; + bool out_fence_requested; }; typedef struct { @@ -395,7 +399,7 @@ static inline bool igt_plane_supports_rotation(igt_plane_t *plane) { return plane->rotation_property != 0; } - +void igt_pipe_request_out_fence(igt_pipe_t *pipe); Not implemented? I think this patch got confused somewhere :-( -Brian void igt_pipe_set_degamma_lut(igt_pipe_t *pipe, void *ptr, size_t length); void igt_pipe_set_ctm_matrix(igt_pipe_t *pipe, void *ptr, size_t length); void igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr, size_t length); -- 2.11.0.453.g787f75f05 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v3 06/11] lib/igt_kms: Add support for the IN_FENCE_FD property
On Mon, Jan 30, 2017 at 08:58:42PM -0500, Robert Foss wrote: Add support dor the IN_FENCE_FD property to enable setting in fences for atomic commits. Signed-off-by: Robert Foss--- lib/igt_kms.c | 20 lib/igt_kms.h | 5 + 2 files changed, 25 insertions(+) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index f0e38b75..b79d2867 100644 --- a/lib/igt_kms.c +++ b/lib/igt_kms.c @@ -168,6 +168,7 @@ const char *igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = { "CRTC_H", "FB_ID", "CRTC_ID", + "IN_FENCE_FD", "type", "rotation" }; @@ -1667,6 +1668,7 @@ void igt_display_init(igt_display_t *display, int drm_fd) plane->type = type; plane->pipe = pipe; plane->drm_plane = drm_plane; + plane->fence_fd = -1; if (is_atomic == 0) { display->is_atomic = 1; @@ -2002,6 +2004,11 @@ igt_atomic_prepare_plane_commit(igt_plane_t *plane, igt_pipe_t *pipe, plane->index, fb_id); + if (plane->fence_fd >= 0) { + uint64_t fence_fd = (int64_t) plane->fence_fd; + igt_atomic_populate_plane_req(req, plane, IGT_PLANE_IN_FENCE_FD, fence_fd); + } + if (plane->fb_changed) { igt_atomic_populate_plane_req(req, plane, IGT_PLANE_CRTC_ID, fb_id ? crtc_id : 0); igt_atomic_populate_plane_req(req, plane, IGT_PLANE_FB_ID, fb_id); @@ -2823,6 +2830,19 @@ void igt_plane_set_fb(igt_plane_t *plane, struct igt_fb *fb) plane->size_changed = true; } +/** + * igt_plane_set_fence_fd: + * @plane: plane + * @fence_fd: fence fd, disable fence_fd by setting it to -1 + * + * This function sets a fence fd to enable a commit to wait for some event to + * occur before completing. + */ +void igt_plane_set_fence_fd(igt_plane_t *plane, uint32_t fence_fd) nitpick, but should that be "int fence_fd" ? Also have some comments later in the series around the fd ownership. If nothing else, the comment here could say what's expected. -Brian +{ + plane->fence_fd = fence_fd; +} + void igt_plane_set_position(igt_plane_t *plane, int x, int y) { igt_pipe_t *pipe = plane->pipe; diff --git a/lib/igt_kms.h b/lib/igt_kms.h index 94ff27bb..85688853 100644 --- a/lib/igt_kms.h +++ b/lib/igt_kms.h @@ -248,6 +248,7 @@ enum igt_atomic_plane_properties { IGT_PLANE_FB_ID, IGT_PLANE_CRTC_ID, + IGT_PLANE_IN_FENCE_FD, IGT_PLANE_TYPE, IGT_PLANE_ROTATION, IGT_NUM_PLANE_PROPS @@ -306,6 +307,9 @@ typedef struct { uint32_t src_h; igt_rotation_t rotation; + + /* in fence fd */ + int32_t fence_fd; uint32_t atomic_props_plane[IGT_NUM_PLANE_PROPS]; } igt_plane_t; @@ -397,6 +401,7 @@ void igt_pipe_set_ctm_matrix(igt_pipe_t *pipe, void *ptr, size_t length); void igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr, size_t length); void igt_plane_set_fb(igt_plane_t *plane, struct igt_fb *fb); +void igt_plane_set_fence_fd(igt_plane_t *plane, uint32_t fence_fd); void igt_plane_set_position(igt_plane_t *plane, int x, int y); void igt_plane_set_size(igt_plane_t *plane, int w, int h); void igt_plane_set_rotation(igt_plane_t *plane, igt_rotation_t rotation); -- 2.11.0.453.g787f75f05 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915: Make intel_detect_preproduction_hw easier to extend
On Mon, Jan 30, 2017 at 05:54:14PM -, Patchwork wrote: > == Series Details == > > Series: series starting with [v2,1/3] drm/i915: Make > intel_detect_preproduction_hw easier to extend > URL : https://patchwork.freedesktop.org/series/18758/ > State : success > > == Summary == > > Series 18758v1 Series without cover letter > https://patchwork.freedesktop.org/api/1.0/series/18758/revisions/1/mbox/ > > > fi-bdw-5557u total:246 pass:232 dwarn:0 dfail:0 fail:0 skip:14 > fi-bsw-n3050 total:246 pass:207 dwarn:0 dfail:0 fail:0 skip:39 > fi-bxt-j4205 total:246 pass:224 dwarn:0 dfail:0 fail:0 skip:22 > fi-bxt-t5700 total:78 pass:65 dwarn:0 dfail:0 fail:0 skip:12 > fi-byt-j1900 total:246 pass:219 dwarn:0 dfail:0 fail:0 skip:27 > fi-byt-n2820 total:246 pass:215 dwarn:0 dfail:0 fail:0 skip:31 > fi-hsw-4770 total:246 pass:227 dwarn:0 dfail:0 fail:0 skip:19 > fi-hsw-4770r total:246 pass:227 dwarn:0 dfail:0 fail:0 skip:19 > fi-ivb-3520m total:246 pass:225 dwarn:0 dfail:0 fail:0 skip:21 > fi-ivb-3770 total:246 pass:225 dwarn:0 dfail:0 fail:0 skip:21 > fi-skl-6260u total:246 pass:233 dwarn:0 dfail:0 fail:0 skip:13 > fi-skl-6700hqtotal:246 pass:226 dwarn:0 dfail:0 fail:0 skip:20 > fi-skl-6700k total:246 pass:221 dwarn:4 dfail:0 fail:0 skip:21 > fi-skl-6770hqtotal:246 pass:233 dwarn:0 dfail:0 fail:0 skip:13 > fi-snb-2520m total:246 pass:215 dwarn:0 dfail:0 fail:0 skip:31 > fi-snb-2600 total:246 pass:214 dwarn:0 dfail:0 fail:0 skip:32 Applied in spite of some late background noise about bxt-a0 support, a bit late now. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Sanity check the computed size and base of stolen memory
On Tue, Jan 31, 2017 at 12:13:47PM +0200, Joonas Lahtinen wrote: > On ma, 2017-01-30 at 13:47 +, Chris Wilson wrote: > > Just do a quick check that the stolen memory address range doesn't > > overflow our chosen integer type. > > > > v2: Add add_overflows() to utils with the promise that gcc7 can do this > > better than C and then maybe it will have a proper definition in core. > > > > Signed-off-by: Chris Wilson> > Cc: Joonas Lahtinen > > Reviewed-by: Joonas Lahtinen Applied, thanks, -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/bxt: Enable IPC support
On Tue, 2017-01-31 at 20:27 +0530, Mahesh Kumar wrote: > This patch adds IPC support for platforms. This patch enables IPC > only for BXT/KBL platform as for SKL recommendation is to keep it disabled. > IPC (Isochronous Priority Control) is the hardware feature, which > dynamically controls the memory read priority of Display. > > When IPC is enabled, plane read requests are sent at high priority until > filling above the transition watermark, then the requests are sent at > lower priority until dropping below the level 0 watermark. > The lower priority requests allow other memory clients to have better > memory access. When IPC is disabled, all plane read requests are sent at > high priority. > > Changes since V1: > - Remove commandline parameter to disable ipc > - Address Paulo's comments > Changes since V2: > - Address review comments > - Set ipc_enabled flag > Changes since V3: > - move ipc_enabled flag assignment inside intel_ipc_enable function > Changes since V4: > - Re-enable IPC after suspend/resume > > Signed-off-by: Mahesh Kumar> --- > drivers/gpu/drm/i915/i915_drv.c | 4 +++- > drivers/gpu/drm/i915/i915_reg.h | 1 + > drivers/gpu/drm/i915/intel_display.c | 1 + > drivers/gpu/drm/i915/intel_drv.h | 1 + > drivers/gpu/drm/i915/intel_pm.c | 16 > 5 files changed, 22 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index ca168b22ee26..5f3b22946971 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -1246,7 +1246,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct > pci_device_id *ent) > > intel_runtime_pm_enable(dev_priv); > > - dev_priv->ipc_enabled = false; > + intel_enable_ipc(dev_priv); > > /* Everything is in place, we can now relax! */ > DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n", > @@ -2439,6 +2439,8 @@ static int intel_runtime_resume(struct device *kdev) > > enable_rpm_wakeref_asserts(dev_priv); > > + intel_enable_ipc(dev_priv); > + > if (ret) > DRM_ERROR("Runtime resume failed, disabling it (%d)\n", ret); > else > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index 72f9f36ae5ce..36e0a33f876c 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -6466,6 +6466,7 @@ enum { > #define DISP_FBC_WM_DIS (1<<15) > #define DISP_ARB_CTL2_MMIO(0x45004) > #define DISP_DATA_PARTITION_5_6 (1<<6) > +#define DISP_IPC_ENABLE (1<<3) > #define DBUF_CTL _MMIO(0x45008) > #define DBUF_POWER_REQUEST (1<<31) > #define DBUF_POWER_STATE(1<<30) > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 0bf8e1bfbe7e..1aa708b6f55e 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -17222,6 +17222,7 @@ void intel_display_resume(struct drm_device *dev) > if (!ret) > ret = __intel_display_resume(dev, state); > > + intel_enable_ipc(dev_priv); > drm_modeset_drop_locks(); > drm_modeset_acquire_fini(); > mutex_unlock(>mode_config.mutex); > diff --git a/drivers/gpu/drm/i915/intel_drv.h > b/drivers/gpu/drm/i915/intel_drv.h > index 0cec0013ace0..ab7423b0a41b 100644 > --- a/drivers/gpu/drm/i915/intel_drv.h > +++ b/drivers/gpu/drm/i915/intel_drv.h > @@ -1787,6 +1787,7 @@ bool skl_ddb_allocation_overlaps(const struct > skl_ddb_entry **entries, > uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state *pipe_config); > bool ilk_disable_lp_wm(struct drm_device *dev); > int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6); > +void intel_enable_ipc(struct drm_i915_private *dev_priv); > static inline int intel_enable_rc6(void) > { > return i915.enable_rc6; > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index 249623d45be0..16e83efa1118 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -4667,6 +4667,22 @@ void intel_update_watermarks(struct intel_crtc *crtc) > dev_priv->display.update_wm(crtc); > } > > +void intel_enable_ipc(struct drm_i915_private *dev_priv) > +{ > + u32 val; > + > + dev_priv->ipc_enabled = false; > + if (!(IS_BROXTON(dev_priv) || IS_KABYLAKE(dev_priv))) > + return; Do we want this enabled in Geminilake? Ander > + > + val = I915_READ(DISP_ARB_CTL2); > + > + val |= DISP_IPC_ENABLE; > + > + I915_WRITE(DISP_ARB_CTL2, val); > + dev_priv->ipc_enabled = true; > +} > + > /* > * Lock protecting IPS related data structures > */ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v3 00/11] tests/kms_atomic_transition add fence testing
On 2017-01-31 05:18 AM, Chris Wilson wrote: On Mon, Jan 30, 2017 at 08:58:36PM -0500, Robert Foss wrote: This series adds in/out fence testing to kms_atomic_transition test and makes some minor cleanups. This series is rebased ontop of the dyn_n_planes_v3 series. This series can be found here: https://git.collabora.com/cgit/user/robertfoss/intel-gpu-tools.git/log/?h=fences_$VER Changes since v1: lib/igt_kms: - Added gtk-doc for exported symbols - Changed integer casting to avoid potential issues - Changed out_fence_ptr type to int64_t* - Fixed igt_plane_set_fence_fd comment tests/: - Rework timeout change in commit_display() - Extract plane_invalid_params_fence() out plane_invalid_params() - Extract crtc_invalid_params_fence() out crtc_invalid_params() - Prevent add igt_require_sw_sync to subtests using sw_sync Changes since v2: Rebased on upstream/master lib/igt_kms: - Reset plane->fence_fd to -1 during igt_atomic_prepare_plane_commit() - Rework out_fencs_ptr to be an int64_t named out_fence - Add igt_pipe_request_out_fence() tests/: - Switch to using igt_pipe_request_out_fence() - Close out_fence fd - Change out_fence to int64_t in run_transition_test() - Added comments noting that two testcases are not invalid - Added igt_pipe_get_last_out_fence() that wraps pipe->fence_out Looks like this this missing the uabi conversion to s32 (int). -Chris Correct, I'll submit a v4 with this fix later today if no other major issues are reported. Rob. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt] intel-ci: Move start of gvt tests last
The purpose of the current placeholder gvt is to reload the module with gvt enabled. As a reload, it should be last after the basic reload checks. Signed-off-by: Chris Wilson--- tests/intel-ci/fast-feedback.testlist | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/intel-ci/fast-feedback.testlist b/tests/intel-ci/fast-feedback.testlist index 0ca499a4..828bd3ff 100644 --- a/tests/intel-ci/fast-feedback.testlist +++ b/tests/intel-ci/fast-feedback.testlist @@ -130,7 +130,6 @@ igt@gem_tiled_pread_basic igt@gem_wait@basic-busy-all igt@gem_wait@basic-wait-all igt@gem_workarounds@basic-read -igt@gvt_basic@invalid-placeholder-test igt@kms_addfb_basic@addfb25-bad-modifier igt@kms_addfb_basic@addfb25-framebuffer-vs-set-tiling igt@kms_addfb_basic@addfb25-modifier-no-flag @@ -250,3 +249,4 @@ igt@drv_module_reload@basic-reload igt@drv_module_reload@basic-no-display igt@drv_module_reload@basic-reload-inject igt@drv_module_reload@basic-reload-final +igt@gvt_basic@invalid-placeholder-test -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Enable IPC & WM related WA's
== Series Details == Series: Enable IPC & WM related WA's URL : https://patchwork.freedesktop.org/series/18842/ State : success == Summary == Series 18842v1 Enable IPC & WM related WA's https://patchwork.freedesktop.org/api/1.0/series/18842/revisions/1/mbox/ fi-bdw-5557u total:247 pass:233 dwarn:0 dfail:0 fail:0 skip:14 fi-bsw-n3050 total:247 pass:208 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:247 pass:225 dwarn:0 dfail:0 fail:0 skip:22 fi-bxt-t5700 total:78 pass:65 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-hsw-4770r total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-ivb-3520m total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-ivb-3770 total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-kbl-7500u total:247 pass:224 dwarn:0 dfail:0 fail:2 skip:21 fi-skl-6260u total:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-skl-6700hqtotal:247 pass:227 dwarn:0 dfail:0 fail:0 skip:20 fi-skl-6700k total:247 pass:222 dwarn:4 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-snb-2520m total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-snb-2600 total:247 pass:215 dwarn:0 dfail:0 fail:0 skip:32 a0695bf4e1c12de4863e775747fe850b92661dc6 drm-tip: 2017y-01m-31d-13h-38m-55s UTC integration manifest 7876fae drm/i915: Decode system memory bandwidth 41469f0 drm/i915/bxt: Enable IPC support == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3655/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for do_execbuffer tidy
== Series Details == Series: do_execbuffer tidy URL : https://patchwork.freedesktop.org/series/18838/ State : warning == Summary == Series 18838v1 do_execbuffer tidy https://patchwork.freedesktop.org/api/1.0/series/18838/revisions/1/mbox/ Test kms_force_connector_basic: Subgroup force-connector-state: pass -> DMESG-WARN (fi-snb-2520m) fi-bdw-5557u total:247 pass:233 dwarn:0 dfail:0 fail:0 skip:14 fi-bsw-n3050 total:247 pass:208 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:247 pass:225 dwarn:0 dfail:0 fail:0 skip:22 fi-bxt-t5700 total:78 pass:65 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-hsw-4770r total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-ivb-3520m total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-ivb-3770 total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-kbl-7500u total:247 pass:224 dwarn:0 dfail:0 fail:2 skip:21 fi-skl-6260u total:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-skl-6700hqtotal:247 pass:227 dwarn:0 dfail:0 fail:0 skip:20 fi-skl-6700k total:247 pass:222 dwarn:4 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-snb-2520m total:247 pass:215 dwarn:1 dfail:0 fail:0 skip:31 fi-snb-2600 total:247 pass:215 dwarn:0 dfail:0 fail:0 skip:32 a0695bf4e1c12de4863e775747fe850b92661dc6 drm-tip: 2017y-01m-31d-13h-38m-55s UTC integration manifest db7e420 drm/i915: Remove some unecessary line breaks c87579b drm/i915: Pass file_priv to eb_select_engine a436b4e drm/i915: eb_engine_select only needs flags c17110c drm/i915: Drop unused engine parameter from i915_gem_validate_context a07e08f drm/i915: Remove some single use locals i915_gem_do_execbuffer d6e08ae drm/i915: Nuke i915_execbuffer_params 51324f0 drm/i915: Remove batch field from i915_execbuffer_params 84b1d2e drm/i915: Tidy execbuf_submit eb4ad7b drm/i915: Drop some unused fields from i915_execbuffer_params 5029d71 drm/i915: Tidy i915_gem_do_execbuffer == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3654/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915/bxt: Enable IPC support
This patch adds IPC support for platforms. This patch enables IPC only for BXT/KBL platform as for SKL recommendation is to keep it disabled. IPC (Isochronous Priority Control) is the hardware feature, which dynamically controls the memory read priority of Display. When IPC is enabled, plane read requests are sent at high priority until filling above the transition watermark, then the requests are sent at lower priority until dropping below the level 0 watermark. The lower priority requests allow other memory clients to have better memory access. When IPC is disabled, all plane read requests are sent at high priority. Changes since V1: - Remove commandline parameter to disable ipc - Address Paulo's comments Changes since V2: - Address review comments - Set ipc_enabled flag Changes since V3: - move ipc_enabled flag assignment inside intel_ipc_enable function Changes since V4: - Re-enable IPC after suspend/resume Signed-off-by: Mahesh Kumar--- drivers/gpu/drm/i915/i915_drv.c | 4 +++- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_display.c | 1 + drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_pm.c | 16 5 files changed, 22 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index ca168b22ee26..5f3b22946971 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1246,7 +1246,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct pci_device_id *ent) intel_runtime_pm_enable(dev_priv); - dev_priv->ipc_enabled = false; + intel_enable_ipc(dev_priv); /* Everything is in place, we can now relax! */ DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n", @@ -2439,6 +2439,8 @@ static int intel_runtime_resume(struct device *kdev) enable_rpm_wakeref_asserts(dev_priv); + intel_enable_ipc(dev_priv); + if (ret) DRM_ERROR("Runtime resume failed, disabling it (%d)\n", ret); else diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 72f9f36ae5ce..36e0a33f876c 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -6466,6 +6466,7 @@ enum { #define DISP_FBC_WM_DIS (1<<15) #define DISP_ARB_CTL2 _MMIO(0x45004) #define DISP_DATA_PARTITION_5_6 (1<<6) +#define DISP_IPC_ENABLE (1<<3) #define DBUF_CTL _MMIO(0x45008) #define DBUF_POWER_REQUEST(1<<31) #define DBUF_POWER_STATE (1<<30) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 0bf8e1bfbe7e..1aa708b6f55e 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -17222,6 +17222,7 @@ void intel_display_resume(struct drm_device *dev) if (!ret) ret = __intel_display_resume(dev, state); + intel_enable_ipc(dev_priv); drm_modeset_drop_locks(); drm_modeset_acquire_fini(); mutex_unlock(>mode_config.mutex); diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 0cec0013ace0..ab7423b0a41b 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -1787,6 +1787,7 @@ bool skl_ddb_allocation_overlaps(const struct skl_ddb_entry **entries, uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state *pipe_config); bool ilk_disable_lp_wm(struct drm_device *dev); int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6); +void intel_enable_ipc(struct drm_i915_private *dev_priv); static inline int intel_enable_rc6(void) { return i915.enable_rc6; diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 249623d45be0..16e83efa1118 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4667,6 +4667,22 @@ void intel_update_watermarks(struct intel_crtc *crtc) dev_priv->display.update_wm(crtc); } +void intel_enable_ipc(struct drm_i915_private *dev_priv) +{ + u32 val; + + dev_priv->ipc_enabled = false; + if (!(IS_BROXTON(dev_priv) || IS_KABYLAKE(dev_priv))) + return; + + val = I915_READ(DISP_ARB_CTL2); + + val |= DISP_IPC_ENABLE; + + I915_WRITE(DISP_ARB_CTL2, val); + dev_priv->ipc_enabled = true; +} + /* * Lock protecting IPS related data structures */ -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Decode system memory bandwidth
This patch adds support to decode system memory bandwidth which will be used for arbitrated display memory percentage calculation in GEN9 based system. Changes from v1: - Address comments from Paulo - implement decode function for SKL/KBL also Changes from v2: - Rewrite the code as per HW team inputs - Addresses review comments Changes from v3: - Fix compilation warning Changes from v4: - Address review comments - Round-off the frequency & bandwidth results Signed-off-by: Mahesh Kumar--- drivers/gpu/drm/i915/i915_drv.c | 179 drivers/gpu/drm/i915/i915_drv.h | 12 +++ drivers/gpu/drm/i915/i915_reg.h | 37 + 3 files changed, 228 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 5f3b22946971..b8d0dd2811a9 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -975,6 +975,179 @@ static void intel_sanitize_options(struct drm_i915_private *dev_priv) DRM_DEBUG_DRIVER("use GPU sempahores? %s\n", yesno(i915.semaphores)); } +static enum rank +skl_memdev_get_channel_rank(uint32_t val) +{ + uint8_t l_rank, s_rank; + uint8_t l_size, s_size; + + if (!val) + return I915_DRAM_RANK_INVALID; + + l_size = (val >> SKL_DRAM_SIZE_L_SHIFT) & SKL_DRAM_SIZE_MASK; + s_size = (val >> SKL_DRAM_SIZE_S_SHIFT) & SKL_DRAM_SIZE_MASK; + l_rank = (val >> SKL_DRAM_RANK_L_SHIFT) & SKL_DRAM_RANK_MASK; + s_rank = (val >> SKL_DRAM_RANK_S_SHIFT) & SKL_DRAM_RANK_MASK; + + if ((l_size == 0) && (s_size == 0)) + return I915_DRAM_RANK_INVALID; + + if (l_rank == SKL_DRAM_RANK_DUAL || s_rank == SKL_DRAM_RANK_DUAL) + return I915_DRAM_RANK_DUAL; + + if ((l_size && l_rank == SKL_DRAM_RANK_SINGLE) && + (s_size && s_rank == SKL_DRAM_RANK_SINGLE)) + return I915_DRAM_RANK_DUAL; + return I915_DRAM_RANK_SINGLE; +} + +static int +skl_get_memdev_info(struct drm_i915_private *dev_priv) +{ + struct memdev_info *memdev_info = _priv->memdev_info; + uint32_t mem_freq_khz; + uint32_t val; + enum rank ch0_rank, ch1_rank; + + val = I915_READ(SKL_MC_BIOS_DATA_0_0_0_MCHBAR_PCU); + mem_freq_khz = DIV_ROUND_UP((val & SKL_REQ_DATA_MASK) * + SKL_MEMORY_FREQ_MULTIPLIER_HZ, 1000); + + val = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN); + ch0_rank = skl_memdev_get_channel_rank(val); + if (ch0_rank != I915_DRAM_RANK_INVALID) + memdev_info->num_channels++; + + val = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN); + ch1_rank = skl_memdev_get_channel_rank(val); + if (ch1_rank != I915_DRAM_RANK_INVALID) + memdev_info->num_channels++; + + if (memdev_info->num_channels == 0) { + DRM_ERROR("Number of mem channels are zero\n"); + return -EINVAL; + } + + memdev_info->bandwidth_kbps = memdev_info->num_channels * + mem_freq_khz * 8; + + if (memdev_info->bandwidth_kbps == 0) { + DRM_ERROR("Couldn't get system memory bandwidth\n"); + return -EINVAL; + } + + /* +* If any of channel is single rank channel, worst case output will be +* same as if single rank memory, so consider single rank memory. +*/ + if (ch0_rank == I915_DRAM_RANK_SINGLE + || ch1_rank == I915_DRAM_RANK_SINGLE) + memdev_info->rank = I915_DRAM_RANK_SINGLE; + else + memdev_info->rank = max(ch0_rank, ch1_rank); + + if (memdev_info->rank == I915_DRAM_RANK_INVALID) { + DRM_ERROR("couldn't get memory rank information\n"); + return -EINVAL; + } + + memdev_info->valid = true; + return 0; +} + +static int +bxt_get_memdev_info(struct drm_i915_private *dev_priv) +{ + struct memdev_info *memdev_info = _priv->memdev_info; + uint32_t dram_channels; + uint32_t mem_freq_khz, val; + uint8_t num_active_channels; + int i; + + val = I915_READ(BXT_P_CR_MC_BIOS_REQ_0_0_0); + mem_freq_khz = DIV_ROUND_UP((val & BXT_REQ_DATA_MASK) * + BXT_MEMORY_FREQ_MULTIPLIER_HZ, 1000); + + dram_channels = (val >> BXT_DRAM_CHANNEL_ACTIVE_SHIFT) & + BXT_DRAM_CHANNEL_ACTIVE_MASK; + num_active_channels = hweight32(dram_channels); + + /* each active bit represents 4-byte channel */ + memdev_info->bandwidth_kbps = (mem_freq_khz * num_active_channels * 4); + + if (memdev_info->bandwidth_kbps == 0) { + DRM_ERROR("Couldn't get system memory bandwidth\n"); + return -EINVAL; + } + + /* +* Now read each DUNIT8/9/10/11 to check the rank of each dimms. +*/ +
[Intel-gfx] [PATCH 3/3] drm/i915/gen9: WM memory bandwidth related workaround
This patch enables workarounds related to display arbitrated memory bandwidth only if it's necessary. WA's are applicable for all GEN9 based platforms. Changes since v1: - Rebase on top of Paulo's patch series Changes since v2: - Address review comments - Rebase/rework as per other patch changes in series Changes since v3: - Rebase the patch - introduce ww_mutex to protect WM operations - Protect system memory bandwidth calculation with ww_mutex Signed-off-by: Mahesh Kumar--- drivers/gpu/drm/i915/i915_drv.c | 1 + drivers/gpu/drm/i915/i915_drv.h | 15 drivers/gpu/drm/i915/intel_display.c | 34 drivers/gpu/drm/i915/intel_pm.c | 163 +++ 4 files changed, 194 insertions(+), 19 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index b8d0dd2811a9..a14b2a9d2e6a 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -814,6 +814,7 @@ static int i915_driver_init_early(struct drm_i915_private *dev_priv, mutex_init(_priv->modeset_restore_lock); mutex_init(_priv->av_mutex); mutex_init(_priv->wm.wm_mutex); + drm_modeset_lock_init(_priv->wm.wm_ww_mutex); mutex_init(_priv->pps_mutex); intel_uc_init_early(dev_priv); diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index df24de2b65f2..6e5cdd6c9dfd 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1174,6 +1174,13 @@ enum intel_sbi_destination { SBI_MPHY, }; +/* SKL+ Watermark arbitrated display bandwidth Workarounds */ +enum watermark_memory_wa { + WATERMARK_WA_NONE, + WATERMARK_WA_X_TILED, + WATERMARK_WA_Y_TILED, +}; + #define QUIRK_PIPEA_FORCE (1<<0) #define QUIRK_LVDS_SSC_DISABLE (1<<1) #define QUIRK_INVERT_BRIGHTNESS (1<<2) @@ -1744,8 +1751,15 @@ struct skl_ddb_allocation { struct skl_ddb_entry y_plane[I915_MAX_PIPES][I915_MAX_PLANES]; }; +struct skl_mem_bw_attr { + enum watermark_memory_wa mem_wa; + uint32_t pipe_bw_kbps[I915_MAX_PIPES]; + bool pipe_y_tiled[I915_MAX_PIPES]; +}; + struct skl_wm_values { unsigned dirty_pipes; + struct skl_mem_bw_attr mem_attr; struct skl_ddb_allocation ddb; }; @@ -2348,6 +2362,7 @@ struct drm_i915_private { * cstate->wm.need_postvbl_update. */ struct mutex wm_mutex; + struct drm_modeset_lock wm_ww_mutex; /* protect DDB/WM redistribution among pipes */ /* * Set during HW readout of watermarks/DDB. Some platforms diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 1aa708b6f55e..de512bd8136b 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -14589,6 +14589,38 @@ static void intel_atomic_track_fbs(struct drm_atomic_state *state) to_intel_plane(plane)->frontbuffer_bit); } +static void +intel_update_wm_bw_wa(struct drm_atomic_state *state) +{ + struct intel_atomic_state *intel_state = to_intel_atomic_state(state); + struct drm_i915_private *dev_priv = to_i915(state->dev); + const struct drm_crtc *crtc; + const struct drm_crtc_state *cstate; + const struct memdev_info *memdev_info = _priv->memdev_info; + struct skl_mem_bw_attr *results = _state->wm_results.mem_attr; + struct skl_mem_bw_attr *hw_vals = _priv->wm.skl_hw.mem_attr; + int i; + + if (!IS_GEN9(dev_priv)) + return; + + if (!memdev_info->valid) + return; + + for_each_crtc_in_state(state, crtc, cstate, i) { + hw_vals->pipe_bw_kbps[i] = results->pipe_bw_kbps[i]; + hw_vals->pipe_y_tiled[i] = results->pipe_y_tiled[i]; + } + + hw_vals->mem_wa = results->mem_wa; + + /* +* As we already updated state variables no need to hold the lock, +* other commits can proceed now with their calculation +*/ + drm_modeset_unlock(_priv->wm.wm_ww_mutex); +} + /** * intel_atomic_commit - commit validated state object * @dev: DRM device @@ -14629,6 +14661,8 @@ static int intel_atomic_commit(struct drm_device *dev, intel_shared_dpll_swap_state(state); intel_atomic_track_fbs(state); + intel_update_wm_bw_wa(state); + if (intel_state->modeset) { memcpy(dev_priv->min_pixclk, intel_state->min_pixclk, sizeof(intel_state->min_pixclk)); diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 16e83efa1118..ae43df5cdfd8 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -2887,21 +2887,6 @@ bool ilk_disable_lp_wm(struct drm_device *dev) #define SKL_SAGV_BLOCK_TIME30 /* µs */ -/* - * FIXME: We still don't have the
[Intel-gfx] [PATCH 0/3] Enable IPC & WM related WA's
This series include remaining patches from following series to enable IPC and Enable/update memory BW related WA's for WM. https://patchwork.freedesktop.org/series/15562/ Mahesh Kumar (3): drm/i915/bxt: Enable IPC support drm/i915: Decode system memory bandwidth drm/i915/gen9: WM memory bandwidth related workaround drivers/gpu/drm/i915/i915_drv.c | 184 ++- drivers/gpu/drm/i915/i915_drv.h | 27 + drivers/gpu/drm/i915/i915_reg.h | 38 drivers/gpu/drm/i915/intel_display.c | 35 +++ drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_pm.c | 179 ++ 6 files changed, 444 insertions(+), 20 deletions(-) -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tools: rename intel_bios_reader to intel_vbt_decode
On Mon, 30 Jan 2017, Ville Syrjäläwrote: > On Mon, Jan 30, 2017 at 10:00:54AM +0200, Jani Nikula wrote: >> On Tue, 24 Jan 2017, Jani Nikula wrote: >> > After all these years intel_bios_reader and intel_bios_dumper still >> > manage to confuse me. Read or dump, which one decodes. Rename >> > intel_bios_reader to intel_vbt_decode to be in line with the naming of >> > all the other tools (particularly the closely related >> > intel_opregion_decode tool) that decode previously gathered or dumped >> > information. >> > >> > Signed-off-by: Jani Nikula >> >> Pushed patches 1-5 because they were trivial and I don't expect anyone >> to care. >> >> How about this one? I don't dare push without acks on the change. > > You're not alone in your confusion. I routinely end up trying to use > the wrong tool. So I for one welcome this change. > > Acked-by: Ville Syrjälä Thanks, pushed with that and Petri's IRC ack. BR, Jani. > >> >> BR, >> Jani. >> >> > >> > --- >> > >> > Patch 6/6 with -M option. >> > --- >> > man/Makefile.am | 4 ++-- >> > man/intel_bios_dumper.rst | 2 +- >> > man/{intel_bios_reader.rst => intel_vbt_decode.rst} | 10 +- >> > tools/.gitignore| 2 +- >> > tools/Makefile.sources | 6 +++--- >> > tools/intel_opregion_decode.c | 2 +- >> > tools/{intel_bios_reader.c => intel_vbt_decode.c} | 0 >> > 7 files changed, 13 insertions(+), 13 deletions(-) >> > rename man/{intel_bios_reader.rst => intel_vbt_decode.rst} (89%) >> > rename tools/{intel_bios_reader.c => intel_vbt_decode.c} (100%) >> > >> > diff --git a/man/Makefile.am b/man/Makefile.am >> > index e40e2e931ada..0098fa45a618 100644 >> > --- a/man/Makefile.am >> > +++ b/man/Makefile.am >> > @@ -3,7 +3,6 @@ appman_RST = \ >> >intel_aubdump.rst \ >> >intel_audio_dump.rst\ >> >intel_bios_dumper.rst \ >> > - intel_bios_reader.rst \ >> >intel_error_decode.rst \ >> >intel_gpu_frequency.rst \ >> >intel_gpu_top.rst \ >> > @@ -16,7 +15,8 @@ appman_RST = \ >> >intel_upload_blit_large.rst \ >> >intel_upload_blit_large_gtt.rst \ >> >intel_upload_blit_large_map.rst \ >> > - intel_upload_blit_small.rst >> > + intel_upload_blit_small.rst \ >> > + intel_vbt_decode.rst >> > >> > if HAVE_RST2MAN >> > appman_DATA = $(appman_RST:rst=$(APP_MAN_SUFFIX)) >> > diff --git a/man/intel_bios_dumper.rst b/man/intel_bios_dumper.rst >> > index 89e0001a70f7..b271b9b1afef 100644 >> > --- a/man/intel_bios_dumper.rst >> > +++ b/man/intel_bios_dumper.rst >> > @@ -33,4 +33,4 @@ Report bugs to https://bugs.freedesktop.org. >> > SEE ALSO >> > >> > >> > -**intel_bios_reader(1)** >> > +**intel_vbt_decode(1)** >> > diff --git a/man/intel_bios_reader.rst b/man/intel_vbt_decode.rst >> > similarity index 89% >> > rename from man/intel_bios_reader.rst >> > rename to man/intel_vbt_decode.rst >> > index 0e935904bcfb..a8d36d500b6d 100644 >> > --- a/man/intel_bios_reader.rst >> > +++ b/man/intel_vbt_decode.rst >> > @@ -1,6 +1,6 @@ >> > -= >> > -intel_bios_reader >> > -= >> > + >> > +intel_vbt_decode >> > + >> > >> > - >> > Intel Video BIOS Table parser >> > @@ -16,12 +16,12 @@ Intel Video BIOS Table parser >> > SYNOPSIS >> > >> > >> > -**intel_bios_reader** [*OPTIONS*] >> > +**intel_vbt_decode** [*OPTIONS*] >> > >> > DESCRIPTION >> > === >> > >> > -**intel_bios_reader** is a tool to parse the Intel Video BIOS Tables >> > (VBT) and >> > +**intel_vbt_decode** is a tool to parse the Intel Video BIOS Tables (VBT) >> > and >> > present the information in a human readable format. >> > >> > The preferred ways of getting the binary VBT to parse are: >> > diff --git a/tools/.gitignore b/tools/.gitignore >> > index 13825a3c9a74..7f5de26f1d07 100644 >> > --- a/tools/.gitignore >> > +++ b/tools/.gitignore >> > @@ -5,7 +5,7 @@ intel_aubdump >> > intel_audio_dump >> > intel_backlight >> > intel_bios_dumper >> > -intel_bios_reader >> > +intel_vbt_decode >> > intel_display_crc >> > intel_display_poller >> > intel_dump_decode >> > diff --git a/tools/Makefile.sources b/tools/Makefile.sources >> > index e2451ea1272c..2c41afffea39 100644 >> > --- a/tools/Makefile.sources >> > +++ b/tools/Makefile.sources >> > @@ -10,7 +10,6 @@ tools_prog_lists = \ >> >intel_reg \ >> >intel_backlight \ >> >intel_bios_dumper \ >> > - intel_bios_reader \ >> >intel_display_crc \ >> >intel_display_poller\ >> >intel_forcewaked\ >> > @@ -28,6
Re: [Intel-gfx] [PATCH v2] drm/color: un-inline drm_color_lut_extract()
On Fri, 27 Jan 2017, Jani Nikulawrote: > The function is not that big, but it's also not used for anything > performance critical. Make it a normal function. > > As a side effect, this apparently makes sparse smarter about what it's > doing, and gets rid of the warning: > > ./include/drm/drm_color_mgmt.h:53:28: warning: shift too big (4294967295) for > type unsigned long > ./include/drm/drm_color_mgmt.h:53:28: warning: cast truncates bits from > constant value (8000 becomes 0) > > v2: rebased > > Cc: Lionel Landwerlin > Reviewed-by: Daniel Vetter > Reviewed-by: Lionel Landwerlin > Signed-off-by: Jani Nikula This time, pushed to drm-misc-next. Thanks for the review. BR, Jani. > --- > drivers/gpu/drm/drm_color_mgmt.c | 24 > include/drm/drm_color_mgmt.h | 27 ++- > 2 files changed, 26 insertions(+), 25 deletions(-) > > diff --git a/drivers/gpu/drm/drm_color_mgmt.c > b/drivers/gpu/drm/drm_color_mgmt.c > index 789b4c65cd69..cc23b9a505c0 100644 > --- a/drivers/gpu/drm/drm_color_mgmt.c > +++ b/drivers/gpu/drm/drm_color_mgmt.c > @@ -88,6 +88,30 @@ > */ > > /** > + * drm_color_lut_extract - clamp and round LUT entries > + * @user_input: input value > + * @bit_precision: number of bits the hw LUT supports > + * > + * Extract a degamma/gamma LUT value provided by user (in the form of > + * _color_lut entries) and round it to the precision supported by the > + * hardware. > + */ > +uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision) > +{ > + uint32_t val = user_input; > + uint32_t max = 0x >> (16 - bit_precision); > + > + /* Round only if we're not using full precision. */ > + if (bit_precision < 16) { > + val += 1UL << (16 - bit_precision - 1); > + val >>= 16 - bit_precision; > + } > + > + return clamp_val(val, 0, max); > +} > +EXPORT_SYMBOL(drm_color_lut_extract); > + > +/** > * drm_crtc_enable_color_mgmt - enable color management properties > * @crtc: DRM CRTC > * @degamma_lut_size: the size of the degamma lut (before CSC) > diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h > index d9c2f680f5ae..bce4a532836d 100644 > --- a/include/drm/drm_color_mgmt.h > +++ b/include/drm/drm_color_mgmt.h > @@ -25,6 +25,8 @@ > > #include > > +uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision); > + > void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc, > uint degamma_lut_size, > bool has_ctm, > @@ -33,29 +35,4 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc, > int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc, >int gamma_size); > > -/** > - * drm_color_lut_extract - clamp and round LUT entries > - * @user_input: input value > - * @bit_precision: number of bits the hw LUT supports > - * > - * Extract a degamma/gamma LUT value provided by user (in the form of > - * _color_lut entries) and round it to the precision supported by the > - * hardware. > - */ > -static inline uint32_t drm_color_lut_extract(uint32_t user_input, > - uint32_t bit_precision) > -{ > - uint32_t val = user_input; > - uint32_t max = 0x >> (16 - bit_precision); > - > - /* Round only if we're not using full precision. */ > - if (bit_precision < 16) { > - val += 1UL << (16 - bit_precision - 1); > - val >>= 16 - bit_precision; > - } > - > - return clamp_val(val, 0, max); > -} > - > - > #endif -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/10] do_execbuffer tidy
On Tue, Jan 31, 2017 at 01:15:36PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin> > I've noticed a few opportunities to improve the readability of this functions > and then kept spotting more and more which can be removed or compacted. > > Eventually ended up with removing i915_execbuffer_params completely. But I > think > it's OK since the plan between when it was added to now changed. Most of it looks like churn duplicating patches I've already sent. :( We have an open performance regression bug (that has only gotten worse with multiple timelines) that I really would like to see some progress on. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/10] drm/i915: Drop some unused fields from i915_execbuffer_params
From: Tvrtko Ursulindev, file and ctx are unused. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index ee7b7bd17e29..2991751516f8 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -50,13 +50,10 @@ #define BATCH_OFFSET_BIAS (256*1024) struct i915_execbuffer_params { - struct drm_device *dev; - struct drm_file *file; struct i915_vma *batch; u32 dispatch_flags; u32 batch_start; struct intel_engine_cs *engine; - struct i915_gem_context *ctx; struct drm_i915_gem_request *request; }; @@ -1834,11 +1831,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, * kept around beyond the duration of the IOCTL once the GPU * scheduler arrives. */ - params.dev= dev; - params.file = file; params.engine = engine; params.dispatch_flags = dispatch_flags; - params.ctx= ctx; params.batch = batch; params.batch_start= batch_start_offset; params.request= req; -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/10] drm/i915: Drop unused engine parameter from i915_gem_validate_context
From: Tvrtko UrsulinSigned-off-by: Tvrtko Ursulin Reviewed-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 57ae6573a37b..51cf3ff3e21d 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -1222,7 +1222,7 @@ validate_exec_list(struct drm_device *dev, static struct i915_gem_context * i915_gem_validate_context(struct drm_device *dev, struct drm_file *file, - struct intel_engine_cs *engine, const u32 ctx_id) + const u32 ctx_id) { struct i915_gem_context *ctx; @@ -1656,7 +1656,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, if (ret) goto pre_mutex_err; - ctx = i915_gem_validate_context(dev, file, engine, + ctx = i915_gem_validate_context(dev, file, i915_execbuffer2_get_context_id(*args)); if (IS_ERR(ctx)) { mutex_unlock(>struct_mutex); -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/10] drm/i915: Remove some single use locals i915_gem_do_execbuffer
From: Tvrtko UrsulinRemove ctx_id, ggtt and vm since they are single use. textdata bss dec hex filename 1085338 263982628 1114364 1100fc i915.ko.0 1085290 263982628 1114316 1100cc i915.ko.1 Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 82e74db5923b..57ae6573a37b 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -1573,16 +1573,13 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, struct drm_i915_gem_exec_object2 *exec) { struct drm_i915_private *dev_priv = to_i915(dev); - struct i915_ggtt *ggtt = _priv->ggtt; struct eb_vmas *eb; struct drm_i915_gem_exec_object2 shadow_exec_entry; struct intel_engine_cs *engine; struct i915_gem_context *ctx; - struct i915_address_space *vm; struct drm_i915_gem_request *req; struct i915_vma *batch; u32 batch_start; - const u32 ctx_id = i915_execbuffer2_get_context_id(*args); u32 dispatch_flags; struct dma_fence *in_fence = NULL; struct sync_file *out_fence = NULL; @@ -1659,7 +1656,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, if (ret) goto pre_mutex_err; - ctx = i915_gem_validate_context(dev, file, engine, ctx_id); + ctx = i915_gem_validate_context(dev, file, engine, + i915_execbuffer2_get_context_id(*args)); if (IS_ERR(ctx)) { mutex_unlock(>struct_mutex); ret = PTR_ERR(ctx); @@ -1668,11 +1666,6 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, i915_gem_context_get(ctx); - if (ctx->ppgtt) - vm = >ppgtt->base; - else - vm = >base; - eb = eb_create(dev_priv, args); if (eb == NULL) { i915_gem_context_put(ctx); @@ -1682,7 +1675,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, } /* Look up object handles */ - ret = eb_lookup_vmas(eb, exec, args, vm, file); + ret = eb_lookup_vmas(eb, exec, args, ctx->ppgtt ? >ppgtt->base : +_priv->ggtt.base, file); if (ret) goto err; -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/10] drm/i915: Tidy i915_gem_do_execbuffer
From: Tvrtko UrsulinInstead of sprinkling around usage and initialization of i915_execbuffer_params we can consolidate it just before execbuf_submit for maintability and readability. That way we can also drop the memset since it becomes easy to spot we initialize all the fields. textdata bss dec hex filename 1085466 263982628 1114492 11017c i915.ko.0 1085402 263982628 1114428 11013c i915.ko.1 Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 87 +++--- 1 file changed, 44 insertions(+), 43 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 91c2393199a3..ee7b7bd17e29 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -50,14 +50,14 @@ #define BATCH_OFFSET_BIAS (256*1024) struct i915_execbuffer_params { - struct drm_device *dev; - struct drm_file *file; - struct i915_vma *batch; - u32 dispatch_flags; - u32 args_batch_start_offset; - struct intel_engine_cs *engine; - struct i915_gem_context *ctx; - struct drm_i915_gem_request *request; + struct drm_device *dev; + struct drm_file *file; + struct i915_vma *batch; + u32 dispatch_flags; + u32 batch_start; + struct intel_engine_cs *engine; + struct i915_gem_context *ctx; + struct drm_i915_gem_request *request; }; struct eb_vmas { @@ -1484,11 +1484,10 @@ execbuf_submit(struct i915_execbuffer_params *params, } exec_len = args->batch_len; - exec_start = params->batch->node.start + -params->args_batch_start_offset; + exec_start = params->batch->node.start + params->batch_start; if (exec_len == 0) - exec_len = params->batch->size - params->args_batch_start_offset; + exec_len = params->batch->size - params->batch_start; ret = params->engine->emit_bb_start(params->request, exec_start, exec_len, @@ -1592,8 +1591,10 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, struct intel_engine_cs *engine; struct i915_gem_context *ctx; struct i915_address_space *vm; - struct i915_execbuffer_params params_master; /* XXX: will be removed later */ - struct i915_execbuffer_params *params = _master; + struct drm_i915_gem_request *req; + struct i915_vma *batch; + u32 batch_start_offset; + struct i915_execbuffer_params params; const u32 ctx_id = i915_execbuffer2_get_context_id(*args); u32 dispatch_flags; struct dma_fence *in_fence = NULL; @@ -1685,8 +1686,6 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, else vm = >base; - memset(_master, 0x00, sizeof(params_master)); - eb = eb_create(dev_priv, args); if (eb == NULL) { i915_gem_context_put(ctx); @@ -1701,7 +1700,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, goto err; /* take note of the batch buffer before we might reorder the lists */ - params->batch = eb_get_batch(eb); + batch = eb_get_batch(eb); /* Move the objects en-masse into the GTT, evicting if necessary. */ need_relocs = (args->flags & I915_EXEC_NO_RELOC) == 0; @@ -1725,24 +1724,24 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, } /* Set the pending read domains for the batch buffer to COMMAND */ - if (params->batch->obj->base.pending_write_domain) { + if (batch->obj->base.pending_write_domain) { DRM_DEBUG("Attempting to use self-modifying batch buffer\n"); ret = -EINVAL; goto err; } - if (args->batch_start_offset > params->batch->size || - args->batch_len > params->batch->size - args->batch_start_offset) { + if (args->batch_start_offset > batch->size || + args->batch_len > batch->size - args->batch_start_offset) { DRM_DEBUG("Attempting to use out-of-bounds batch\n"); ret = -EINVAL; goto err; } - params->args_batch_start_offset = args->batch_start_offset; + batch_start_offset = args->batch_start_offset; if (engine->needs_cmd_parser && args->batch_len) { struct i915_vma *vma; vma = i915_gem_execbuffer_parse(engine, _exec_entry, - params->batch->obj, + batch->obj,
[Intel-gfx] [PATCH 05/10] drm/i915: Nuke i915_execbuffer_params
From: Tvrtko UrsulinNow that it only contains three parameters we can pass them directly to execbuf_submit just as well. No effect on generated binary, just a source reduction. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 39 -- 1 file changed, 10 insertions(+), 29 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index afbb56196162..82e74db5923b 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -49,12 +49,6 @@ #define BATCH_OFFSET_BIAS (256*1024) -struct i915_execbuffer_params { - u32 dispatch_flags; - u32 batch_start; - struct drm_i915_gem_request *request; -}; - struct eb_vmas { struct drm_i915_private *i915; struct list_head vmas; @@ -1404,11 +1398,10 @@ i915_gem_execbuffer_parse(struct intel_engine_cs *engine, } static int -execbuf_submit(struct i915_execbuffer_params *params, - struct drm_i915_gem_execbuffer2 *args, +execbuf_submit(struct drm_i915_gem_request *req, u32 batch_start, + u32 dispatch_flags, struct drm_i915_gem_execbuffer2 *args, struct list_head *vmas) { - struct drm_i915_gem_request *req = params->request; struct drm_i915_private *dev_priv = req->i915; struct intel_engine_cs *engine = req->engine; u64 exec_start, exec_len; @@ -1481,17 +1474,16 @@ execbuf_submit(struct i915_execbuffer_params *params, } exec_len = args->batch_len; - exec_start = req->batch->node.start + params->batch_start; + exec_start = req->batch->node.start + batch_start; if (exec_len == 0) - exec_len = req->batch->size - params->batch_start; + exec_len = req->batch->size - batch_start; - ret = engine->emit_bb_start(req, exec_start, exec_len, - params->dispatch_flags); + ret = engine->emit_bb_start(req, exec_start, exec_len, dispatch_flags); if (ret) return ret; - trace_i915_gem_ring_dispatch(req, params->dispatch_flags); + trace_i915_gem_ring_dispatch(req, dispatch_flags); i915_gem_execbuffer_move_to_active(vmas, req); @@ -1589,8 +1581,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, struct i915_address_space *vm; struct drm_i915_gem_request *req; struct i915_vma *batch; - u32 batch_start_offset; - struct i915_execbuffer_params params; + u32 batch_start; const u32 ctx_id = i915_execbuffer2_get_context_id(*args); u32 dispatch_flags; struct dma_fence *in_fence = NULL; @@ -1732,7 +1723,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, goto err; } - batch_start_offset = args->batch_start_offset; + batch_start = args->batch_start_offset; if (engine->needs_cmd_parser && args->batch_len) { struct i915_vma *vma; @@ -1758,7 +1749,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, * command parser has accepted. */ dispatch_flags |= I915_DISPATCH_SECURE; - batch_start_offset = 0; + batch_start = 0; batch = vma; } } @@ -1824,17 +1815,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, if (ret) goto err_request; - /* -* Save assorted stuff away to pass through to *_submission(). -* NB: This data should be 'persistent' and not local as it will -* kept around beyond the duration of the IOCTL once the GPU -* scheduler arrives. -*/ - params.dispatch_flags = dispatch_flags; - params.batch_start= batch_start_offset; - params.request= req; - - ret = execbuf_submit(, args, >vmas); + ret = execbuf_submit(req, batch_start, dispatch_flags, args, >vmas); err_request: __i915_add_request(req, ret == 0); if (out_fence) { -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/10] do_execbuffer tidy
From: Tvrtko UrsulinI've noticed a few opportunities to improve the readability of this functions and then kept spotting more and more which can be removed or compacted. Eventually ended up with removing i915_execbuffer_params completely. But I think it's OK since the plan between when it was added to now changed. Overall reduction in source and binary, hopefully for tidier code. textdata bss dec hex filename 1085466 263982628 1114492 11017c i915.ko.0 1085290 263982628 1114316 1100cc i915.ko.1 Tvrtko Ursulin (10): drm/i915: Tidy i915_gem_do_execbuffer drm/i915: Drop some unused fields from i915_execbuffer_params drm/i915: Tidy execbuf_submit drm/i915: Remove batch field from i915_execbuffer_params drm/i915: Nuke i915_execbuffer_params drm/i915: Remove some single use locals i915_gem_do_execbuffer drm/i915: Drop unused engine parameter from i915_gem_validate_context drm/i915: eb_engine_select only needs flags drm/i915: Pass file_priv to eb_select_engine drm/i915: Remove some unecessary line breaks drivers/gpu/drm/i915/i915_gem_execbuffer.c | 159 +++-- 1 file changed, 60 insertions(+), 99 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/10] drm/i915: Remove batch field from i915_execbuffer_params
From: Tvrtko UrsulinAlso redundant since it is stored in the request. textdata bss dec hex filename 1085354 263982628 1114380 11010c i915.ko.0 1085338 263982628 1114364 1100fc i915.ko.1 Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 119322eb9897..afbb56196162 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -50,7 +50,6 @@ #define BATCH_OFFSET_BIAS (256*1024) struct i915_execbuffer_params { - struct i915_vma *batch; u32 dispatch_flags; u32 batch_start; struct drm_i915_gem_request *request; @@ -1482,10 +1481,10 @@ execbuf_submit(struct i915_execbuffer_params *params, } exec_len = args->batch_len; - exec_start = params->batch->node.start + params->batch_start; + exec_start = req->batch->node.start + params->batch_start; if (exec_len == 0) - exec_len = params->batch->size - params->batch_start; + exec_len = req->batch->size - params->batch_start; ret = engine->emit_bb_start(req, exec_start, exec_len, params->dispatch_flags); @@ -1832,7 +1831,6 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, * scheduler arrives. */ params.dispatch_flags = dispatch_flags; - params.batch = batch; params.batch_start= batch_start_offset; params.request= req; -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/10] drm/i915: Remove some unecessary line breaks
From: Tvrtko UrsulinJust spotted a few lines which fit in 80 chars and were split. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index ff102b39c3b3..18312959f961 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -1066,8 +1066,7 @@ i915_gem_execbuffer_relocate_slow(struct drm_device *dev, goto err; need_relocs = (args->flags & I915_EXEC_NO_RELOC) == 0; - ret = i915_gem_execbuffer_reserve(engine, >vmas, ctx, - _relocs); + ret = i915_gem_execbuffer_reserve(engine, >vmas, ctx, _relocs); if (ret) goto err; @@ -1682,8 +1681,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, /* Move the objects en-masse into the GTT, evicting if necessary. */ need_relocs = (args->flags & I915_EXEC_NO_RELOC) == 0; - ret = i915_gem_execbuffer_reserve(engine, >vmas, ctx, - _relocs); + ret = i915_gem_execbuffer_reserve(engine, >vmas, ctx, _relocs); if (ret) goto err; @@ -1693,8 +1691,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, if (ret) { if (ret == -EFAULT) { ret = i915_gem_execbuffer_relocate_slow(dev, args, file, - engine, - eb, exec, ctx); + engine, eb, + exec, ctx); BUG_ON(!mutex_is_locked(>struct_mutex)); } if (ret) @@ -1719,8 +1717,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, struct i915_vma *vma; vma = i915_gem_execbuffer_parse(engine, _exec_entry, - batch->obj, - eb, + batch->obj, eb, args->batch_start_offset, args->batch_len, drm_is_current_master(file)); -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/10] drm/i915: eb_engine_select only needs flags
From: Tvrtko UrsulinNot the whole args struct needs to be passed in. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 51cf3ff3e21d..ae94cc27c9ba 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -1519,11 +1519,10 @@ static const enum intel_engine_id user_ring_map[I915_USER_RINGS + 1] = { }; static struct intel_engine_cs * -eb_select_engine(struct drm_i915_private *dev_priv, -struct drm_file *file, -struct drm_i915_gem_execbuffer2 *args) +eb_select_engine(struct drm_i915_private *dev_priv, struct drm_file *file, +u64 flags) { - unsigned int user_ring_id = args->flags & I915_EXEC_RING_MASK; + unsigned int user_ring_id = flags & I915_EXEC_RING_MASK; struct intel_engine_cs *engine; if (user_ring_id > I915_USER_RINGS) { @@ -1532,14 +1531,14 @@ eb_select_engine(struct drm_i915_private *dev_priv, } if ((user_ring_id != I915_EXEC_BSD) && - ((args->flags & I915_EXEC_BSD_MASK) != 0)) { + ((flags & I915_EXEC_BSD_MASK) != 0)) { DRM_DEBUG("execbuf with non bsd ring but with invalid " - "bsd dispatch flags: %d\n", (int)(args->flags)); + "bsd dispatch flags: %d\n", (int)(flags)); return NULL; } if (user_ring_id == I915_EXEC_BSD && HAS_BSD2(dev_priv)) { - unsigned int bsd_idx = args->flags & I915_EXEC_BSD_MASK; + unsigned int bsd_idx = flags & I915_EXEC_BSD_MASK; if (bsd_idx == I915_EXEC_BSD_DEFAULT) { bsd_idx = gen8_dispatch_bsd_engine(dev_priv, file); @@ -1604,7 +1603,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, if (args->flags & I915_EXEC_IS_PINNED) dispatch_flags |= I915_DISPATCH_PINNED; - engine = eb_select_engine(dev_priv, file, args); + engine = eb_select_engine(dev_priv, file, args->flags); if (!engine) return -EINVAL; -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/10] drm/i915: Pass file_priv to eb_select_engine
From: Tvrtko Ursulinfile_priv is what it needs to pass on to gen8_dispatch_bsd_engine so simplify things by passing it straight away. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index ae94cc27c9ba..ff102b39c3b3 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -1496,10 +1496,8 @@ execbuf_submit(struct drm_i915_gem_request *req, u32 batch_start, */ static unsigned int gen8_dispatch_bsd_engine(struct drm_i915_private *dev_priv, -struct drm_file *file) +struct drm_i915_file_private *file_priv) { - struct drm_i915_file_private *file_priv = file->driver_priv; - /* Check whether the file_priv has already selected one ring. */ if ((int)file_priv->bsd_engine < 0) file_priv->bsd_engine = atomic_fetch_xor(1, @@ -1519,8 +1517,8 @@ static const enum intel_engine_id user_ring_map[I915_USER_RINGS + 1] = { }; static struct intel_engine_cs * -eb_select_engine(struct drm_i915_private *dev_priv, struct drm_file *file, -u64 flags) +eb_select_engine(struct drm_i915_private *dev_priv, +struct drm_i915_file_private *file_priv, u64 flags) { unsigned int user_ring_id = flags & I915_EXEC_RING_MASK; struct intel_engine_cs *engine; @@ -1541,7 +1539,7 @@ eb_select_engine(struct drm_i915_private *dev_priv, struct drm_file *file, unsigned int bsd_idx = flags & I915_EXEC_BSD_MASK; if (bsd_idx == I915_EXEC_BSD_DEFAULT) { - bsd_idx = gen8_dispatch_bsd_engine(dev_priv, file); + bsd_idx = gen8_dispatch_bsd_engine(dev_priv, file_priv); } else if (bsd_idx >= I915_EXEC_BSD_RING1 && bsd_idx <= I915_EXEC_BSD_RING2) { bsd_idx >>= I915_EXEC_BSD_SHIFT; @@ -1603,7 +1601,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, if (args->flags & I915_EXEC_IS_PINNED) dispatch_flags |= I915_DISPATCH_PINNED; - engine = eb_select_engine(dev_priv, file, args->flags); + engine = eb_select_engine(dev_priv, file->driver_priv, args->flags); if (!engine) return -EINVAL; -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/10] drm/i915: Tidy execbuf_submit
From: Tvrtko UrsulinUse a local variable for storing the request and engine and at the same time drop the engine field from i915_execbuffer_params since it is available from the request. textdata bss dec hex filename 1085402 263982628 1114428 11013c i915.ko.0 1085354 263982628 1114380 11010c i915.ko.1 Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 35 +++--- 1 file changed, 17 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 2991751516f8..119322eb9897 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -53,7 +53,6 @@ struct i915_execbuffer_params { struct i915_vma *batch; u32 dispatch_flags; u32 batch_start; - struct intel_engine_cs *engine; struct drm_i915_gem_request *request; }; @@ -1410,17 +1409,19 @@ execbuf_submit(struct i915_execbuffer_params *params, struct drm_i915_gem_execbuffer2 *args, struct list_head *vmas) { - struct drm_i915_private *dev_priv = params->request->i915; + struct drm_i915_gem_request *req = params->request; + struct drm_i915_private *dev_priv = req->i915; + struct intel_engine_cs *engine = req->engine; u64 exec_start, exec_len; int instp_mode; u32 instp_mask; int ret; - ret = i915_gem_execbuffer_move_to_gpu(params->request, vmas); + ret = i915_gem_execbuffer_move_to_gpu(req, vmas); if (ret) return ret; - ret = i915_switch_context(params->request); + ret = i915_switch_context(req); if (ret) return ret; @@ -1430,25 +1431,25 @@ execbuf_submit(struct i915_execbuffer_params *params, case I915_EXEC_CONSTANTS_REL_GENERAL: case I915_EXEC_CONSTANTS_ABSOLUTE: case I915_EXEC_CONSTANTS_REL_SURFACE: - if (instp_mode != 0 && params->engine->id != RCS) { + if (instp_mode != 0 && engine->id != RCS) { DRM_DEBUG("non-0 rel constants mode on non-RCS\n"); return -EINVAL; } if (instp_mode != dev_priv->relative_constants_mode) { - if (INTEL_INFO(dev_priv)->gen < 4) { + if (INTEL_GEN(dev_priv) < 4) { DRM_DEBUG("no rel constants on pre-gen4\n"); return -EINVAL; } - if (INTEL_INFO(dev_priv)->gen > 5 && + if (INTEL_GEN(dev_priv) > 5 && instp_mode == I915_EXEC_CONSTANTS_REL_SURFACE) { DRM_DEBUG("rel surface constants mode invalid on gen5+\n"); return -EINVAL; } /* The HW changed the meaning on this bit on gen6 */ - if (INTEL_INFO(dev_priv)->gen >= 6) + if (INTEL_GEN(dev_priv) >= 6) instp_mask &= ~I915_EXEC_CONSTANTS_REL_SURFACE; } break; @@ -1457,11 +1458,11 @@ execbuf_submit(struct i915_execbuffer_params *params, return -EINVAL; } - if (params->engine->id == RCS && + if (engine->id == RCS && instp_mode != dev_priv->relative_constants_mode) { - struct intel_ring *ring = params->request->ring; + struct intel_ring *ring = req->ring; - ret = intel_ring_begin(params->request, 4); + ret = intel_ring_begin(req, 4); if (ret) return ret; @@ -1475,7 +1476,7 @@ execbuf_submit(struct i915_execbuffer_params *params, } if (args->flags & I915_EXEC_GEN7_SOL_RESET) { - ret = i915_reset_gen7_sol_offsets(params->request); + ret = i915_reset_gen7_sol_offsets(req); if (ret) return ret; } @@ -1486,15 +1487,14 @@ execbuf_submit(struct i915_execbuffer_params *params, if (exec_len == 0) exec_len = params->batch->size - params->batch_start; - ret = params->engine->emit_bb_start(params->request, - exec_start, exec_len, - params->dispatch_flags); + ret = engine->emit_bb_start(req, exec_start, exec_len, + params->dispatch_flags); if (ret) return ret; - trace_i915_gem_ring_dispatch(params->request, params->dispatch_flags); + trace_i915_gem_ring_dispatch(req, params->dispatch_flags); -
Re: [Intel-gfx] [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)
On Tue, Jan 31, 2017 at 01:12:05PM +0100, Rafael J. Wysocki wrote: > On 1/31/2017 1:02 PM, Imre Deak wrote: > >On Tue, Jan 31, 2017 at 12:39:35PM +0100, Rafael J. Wysocki wrote: > >>On 1/31/2017 11:58 AM, Imre Deak wrote: > >>>Hi Rafael, > >>Hi, > >> > >>>On Mon, Jan 30, 2017 at 11:44:37PM +0100, Rafael J. Wysocki wrote: > On 1/24/2017 2:33 AM, Sedat Dilek wrote: > >On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki> >wrote: > >>On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek > >>wrote: > >>>Hi, > >>> > >>>I have already reported this issue in [1]. > >>>One of the issue was solved. > >>>Unfortunately, it looks like there is still a different problem here > >>>(Ubuntu/precise AMD64). > >>> > >>>I tried v4.10-rc1 and latest Linus tree up to... > >>> > >>>commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1 > >>>"mm/filemap: fix parameters to test_bit()" > >>> > >>>Here we go... > >>> > >>>[ 29.636047] BUG: sleeping function called from invalid context at > >>>drivers/base/power/runtime.c:1032 > >>>[ 29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: > >>>Xorg > >>>[ 29.636058] 1 lock held by Xorg/1500: > >>>[ 29.636060] #0: (>struct_mutex){+.+.+.}, at: > >>>[] i915_mutex_lock_interruptible+0x43/0x140 [i915] > >>>[ 29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted > >>>4.10.0-rc1-6-iniza-amd64 #1 > >>>[ 29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD. > >>>530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013 > >>>[ 29.636111] Call Trace: > >>>[ 29.636120] dump_stack+0x85/0xc2 > >>>[ 29.636124] ___might_sleep+0x196/0x260 > >>>[ 29.636127] __might_sleep+0x53/0xb0 > >>>[ 29.636131] __pm_runtime_resume+0x7a/0x90 > >>>[ 29.636159] intel_runtime_pm_get+0x25/0x90 [i915] > >>>[ 29.636189] aliasing_gtt_bind_vma+0xaa/0xf0 [i915] > >>>[ 29.636220] i915_vma_bind+0xaf/0x1e0 [i915] > >>>[ 29.636248] i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915] > >>>[ 29.636272] i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 > >>>[i915] > >>>[ 29.636275] ? trace_hardirqs_on+0xd/0x10 > >>>[ 29.636294] ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 > >>>[i915] > >>>[ 29.636316] ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 > >>>[i915] > >>>[ 29.636342] i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915] > >>>[ 29.636347] ? __might_fault+0x4e/0xb0 > >>>[ 29.636373] i915_gem_execbuffer2+0xc5/0x260 [i915] > >>>[ 29.636376] ? __might_fault+0x4e/0xb0 > >>>[ 29.636395] drm_ioctl+0x206/0x450 [drm] > >>>[ 29.636420] ? i915_gem_execbuffer+0x340/0x340 [i915] > >>>[ 29.636425] ? __fget+0x5/0x200 > >>>[ 29.636429] do_vfs_ioctl+0x91/0x6f0 > >>>[ 29.636431] ? __fget+0x111/0x200 > >>>[ 29.636433] ? __fget+0x5/0x200 > >>>[ 29.636436] SyS_ioctl+0x79/0x90 > >>>[ 29.636441] entry_SYSCALL_64_fastpath+0x23/0xc6 > >>> > >>>On suspend/resume I see the same call trace. > >>>[2] points to the "BUG" line. > >>Well, this appears to be an i915 issue, but not a serious one. > >> > >>Clearly, a function that may sleep (pm_runtime_get_sync() in > >>intel_runtime_pm_get()) is called with disabled interrupts. If I > >>understand the code correctly, though, it actually is not going to > >>sleep in this particular case, because pm_runtime_get_sync() has > >>already been called once for this device in the same code path which > >>means that this particular instance will return immediately, so this > >>is a false-positive (most likely). > >>>Not sure what's the root cause, but thought to clarify the above: > >>> > >>>Yes, i915_gem_do_execbuffer() does take an RPM reference to optimize > >>>things, so the RPM get in aliasing_gtt_bind_vma() won't need to resume > >>>the device on this path. This isn't a guarantee though, > >>>aliasing_gtt_bind_vma() could be called from other places without an RPM > >>>reference. So preemption being disabled at that point is not > >>>intentional. I also can't see where on the above path it would get > >>>disabled due to a bug or otherwise. > >>The i915 code is correct AFAICS, but the core complains about a nested > >>invocation of pm_runtime_get_sync() with disabled interrupts (which looks OK > >>though), so the complaint is a false positive. > >Well, my point was that interrupts (or preemption) doesn't seem to get > >disabled anywhere on that path. > > But the might_sleep_if() assertion in __pm_runtime_resume() triggers for > some reason. I wonder why then? > > Of course, I may be overlooking something in the i915 code. > > In any case, if you do > > pm_runtime_get_sync(dev) > local_irq_disable() > pm_runtime_get_sync(dev) > > pm_runtime_put(dev) > local_irq_enable() >
Re: [Intel-gfx] [PATCH] drm/atomic: Fix double free in drm_atomic_state_default_clear
On Tue, Jan 31, 2017 at 10:04:09AM -0200, Gustavo Padovan wrote: > Hi Maarten, > > 2017-01-31 Maarten Lankhorst: > > > drm_atomic_helper_page_flip and drm_atomic_ioctl set their own events > > in crtc_state->event. But when it's set the event is freed in 2 places. > > > > Solve this by only freeing the event in the atomic ioctl when it > > allocated its own event. > > > > This has been broken twice. The first time when the code was introduced, > > but only in the corner case when an event is allocated, but more crtc's > > were included by atomic check and then failing. This can mostly > > happen when you do an atomic modeset in i915 and the display clock is > > changed, which forces all crtc's to be included to the state. > > > > This has been broken worse by adding in-fences support, which caused > > the double free to be done unconditionally. > > > > [IGT] kms_rotation_crc: starting subtest primary-rotation-180 > > = > > BUG kmalloc-128 (Tainted: G U ): Object already free > > - > > > > Disabling lock debugging due to kernel taint > > INFO: Allocated in drm_atomic_helper_setup_commit+0x285/0x2f0 > > [drm_kms_helper] age=0 cpu=3 pid=1529 > > ___slab_alloc+0x308/0x3b0 > > __slab_alloc+0xd/0x20 > > kmem_cache_alloc_trace+0x92/0x1c0 > > drm_atomic_helper_setup_commit+0x285/0x2f0 [drm_kms_helper] > > intel_atomic_commit+0x35/0x4f0 [i915] > > drm_atomic_commit+0x46/0x50 [drm] > > drm_mode_atomic_ioctl+0x7d4/0xab0 [drm] > > drm_ioctl+0x2b3/0x490 [drm] > > do_vfs_ioctl+0x69c/0x700 > > SyS_ioctl+0x4e/0x80 > > entry_SYSCALL_64_fastpath+0x13/0x94 > > INFO: Freed in drm_event_cancel_free+0xa3/0xb0 [drm] age=0 cpu=3 pid=1529 > > __slab_free+0x48/0x2e0 > > kfree+0x159/0x1a0 > > drm_event_cancel_free+0xa3/0xb0 [drm] > > drm_mode_atomic_ioctl+0x86d/0xab0 [drm] > > drm_ioctl+0x2b3/0x490 [drm] > > do_vfs_ioctl+0x69c/0x700 > > SyS_ioctl+0x4e/0x80 > > entry_SYSCALL_64_fastpath+0x13/0x94 > > INFO: Slab 0xde1f0997b080 objects=17 used=2 fp=0x92fb65ec2578 > > flags=0x2008101 > > INFO: Object 0x92fb65ec2578 @offset=1400 fp=0x92fb65ec2ae8 > > > > Redzone 92fb65ec2570: bb bb bb bb bb bb bb bb > > > > Object 92fb65ec2578: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > > > Object 92fb65ec2588: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > > > Object 92fb65ec2598: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > > > Object 92fb65ec25a8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > > > Object 92fb65ec25b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > > > Object 92fb65ec25c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > > > Object 92fb65ec25d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > > > Object 92fb65ec25e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 > > kkk. > > Redzone 92fb65ec25f8: bb bb bb bb bb bb bb bb > > > > Padding 92fb65ec2738: 5a 5a 5a 5a 5a 5a 5a 5a > > > > CPU: 3 PID: 180 Comm: kworker/3:2 Tainted: GBU > > 4.10.0-rc6-patser+ #5039 > > Hardware name: /NUC5PPYB, BIOS > > PYBSWCEL.86A.0031.2015.0601.1712 06/01/2015 > > Workqueue: events intel_atomic_helper_free_state [i915] > > Call Trace: > > dump_stack+0x4d/0x6d > > print_trailer+0x20c/0x220 > > free_debug_processing+0x1c6/0x330 > > ? drm_atomic_state_default_clear+0xf7/0x1c0 [drm] > > __slab_free+0x48/0x2e0 > > ? drm_atomic_state_default_clear+0xf7/0x1c0 [drm] > > kfree+0x159/0x1a0 > > drm_atomic_state_default_clear+0xf7/0x1c0 [drm] > > ? drm_atomic_state_clear+0x30/0x30 [drm] > > intel_atomic_state_clear+0xd/0x20 [i915] > > drm_atomic_state_clear+0x1a/0x30 [drm] > > __drm_atomic_state_free+0x13/0x60 [drm] > > intel_atomic_helper_free_state+0x5d/0x70 [i915] > > process_one_work+0x260/0x4a0 > > worker_thread+0x2d1/0x4f0 > > kthread+0x127/0x130 > > ? process_one_work+0x4a0/0x4a0 > > ? kthread_stop+0x120/0x120 > > ret_from_fork+0x29/0x40 > > FIX kmalloc-128: Object at 0x92fb65ec2578 not freed > > > > Fixes: 3b24f7d67581 ("drm/atomic: Add struct drm_crtc_commit to track async > > updates") > > Fixes: 9626014258a5 ("drm/fence: add in-fences support") > > Cc: # v4.8+ > > Cc: Daniel Vetter > > Signed-off-by: Maarten Lankhorst > > Reviewed-by: Daniel Vetter > > --- > > drivers/gpu/drm/drm_atomic.c | 13 - > > 1 file changed, 8 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_atomic.c
Re: [Intel-gfx] [PATCH v2 26/38] drm/i915: Exercise filling the top/bottom portions of the ppgtt
On to, 2017-01-19 at 11:41 +, Chris Wilson wrote: > Allocate objects with varying number of pages (which should hopefully > consist of a mixture of contiguous page chunks and so coalesced sg > lists) and check that the sg walkers in insert_pages cope. > > Signed-off-by: Chris Wilson> +static int fill_hole(struct drm_i915_private *i915, > + struct i915_address_space *vm, > + u64 hole_start, u64 hole_end, > + unsigned long end_time) > +{ > + const u64 hole_size = hole_end - hole_start; > + struct drm_i915_gem_object *obj; > + const unsigned long max_pages = > + min_t(u64, 1 << 20, hole_size/2 >> PAGE_SHIFT); At least make a comment, why this specific number. It's good to know if something is a hard limit vs. pulled out of thin air. > + for_each_prime_number_from(prime, 2, 13) { SMALL_PRIME_MAX or something similar? Also, what are we targeting with the selected number, staying below X bytes, N seconds or what? I think all the tests could be clarified with such comments. > + GEM_BUG_ON(!full_size); This could be in huge_gem_object too? > + obj = huge_gem_object(i915, PAGE_SIZE, full_size); > + if (IS_ERR(obj)) > + break; > + > + list_add(>batch_pool_link, ); > + > + /* Align differing sized objects against the edges, and > + * check we don't walk off into the void when binding > + * them into the GTT. > + */ > + for (p = phases; p->name; p++) { > + u64 flags; > + > + flags = p->base; "offset" and "flags" could be separate variables, just for readability as this is a test. > + list_for_each_entry(obj, , > batch_pool_link) { > + vma = i915_vma_instance(obj, vm, NULL); > + if (IS_ERR(vma)) > + continue; > + > + err = i915_vma_pin(vma, 0, 0, flags); > + if (err) { > + pr_err("Fill %s pin failed with > err=%d on size=%lu pages (prime=%lu), flags=%llx\n", p->name, err, npages, > prime, flags); > + goto err; > + } > + > + i915_vma_unpin(vma); > + > + flags += p->step; > + if (flags < hole_start || > + flags > hole_end) This is also why I'd prefer the variables to be separate, you could check <= and >= . > + break; Make a comment for this block, each previous object is smaller, and that we rely on the list for ordering. Even when the lack of comments tried to deceive me, I think I understood it right; Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)
On 1/31/2017 1:02 PM, Imre Deak wrote: On Tue, Jan 31, 2017 at 12:39:35PM +0100, Rafael J. Wysocki wrote: On 1/31/2017 11:58 AM, Imre Deak wrote: Hi Rafael, Hi, On Mon, Jan 30, 2017 at 11:44:37PM +0100, Rafael J. Wysocki wrote: On 1/24/2017 2:33 AM, Sedat Dilek wrote: On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysockiwrote: On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek wrote: Hi, I have already reported this issue in [1]. One of the issue was solved. Unfortunately, it looks like there is still a different problem here (Ubuntu/precise AMD64). I tried v4.10-rc1 and latest Linus tree up to... commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1 "mm/filemap: fix parameters to test_bit()" Here we go... [ 29.636047] BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1032 [ 29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg [ 29.636058] 1 lock held by Xorg/1500: [ 29.636060] #0: (>struct_mutex){+.+.+.}, at: [] i915_mutex_lock_interruptible+0x43/0x140 [i915] [ 29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted 4.10.0-rc1-6-iniza-amd64 #1 [ 29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013 [ 29.636111] Call Trace: [ 29.636120] dump_stack+0x85/0xc2 [ 29.636124] ___might_sleep+0x196/0x260 [ 29.636127] __might_sleep+0x53/0xb0 [ 29.636131] __pm_runtime_resume+0x7a/0x90 [ 29.636159] intel_runtime_pm_get+0x25/0x90 [i915] [ 29.636189] aliasing_gtt_bind_vma+0xaa/0xf0 [i915] [ 29.636220] i915_vma_bind+0xaf/0x1e0 [i915] [ 29.636248] i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915] [ 29.636272] i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915] [ 29.636275] ? trace_hardirqs_on+0xd/0x10 [ 29.636294] ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 [i915] [ 29.636316] ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915] [ 29.636342] i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915] [ 29.636347] ? __might_fault+0x4e/0xb0 [ 29.636373] i915_gem_execbuffer2+0xc5/0x260 [i915] [ 29.636376] ? __might_fault+0x4e/0xb0 [ 29.636395] drm_ioctl+0x206/0x450 [drm] [ 29.636420] ? i915_gem_execbuffer+0x340/0x340 [i915] [ 29.636425] ? __fget+0x5/0x200 [ 29.636429] do_vfs_ioctl+0x91/0x6f0 [ 29.636431] ? __fget+0x111/0x200 [ 29.636433] ? __fget+0x5/0x200 [ 29.636436] SyS_ioctl+0x79/0x90 [ 29.636441] entry_SYSCALL_64_fastpath+0x23/0xc6 On suspend/resume I see the same call trace. [2] points to the "BUG" line. Well, this appears to be an i915 issue, but not a serious one. Clearly, a function that may sleep (pm_runtime_get_sync() in intel_runtime_pm_get()) is called with disabled interrupts. If I understand the code correctly, though, it actually is not going to sleep in this particular case, because pm_runtime_get_sync() has already been called once for this device in the same code path which means that this particular instance will return immediately, so this is a false-positive (most likely). Not sure what's the root cause, but thought to clarify the above: Yes, i915_gem_do_execbuffer() does take an RPM reference to optimize things, so the RPM get in aliasing_gtt_bind_vma() won't need to resume the device on this path. This isn't a guarantee though, aliasing_gtt_bind_vma() could be called from other places without an RPM reference. So preemption being disabled at that point is not intentional. I also can't see where on the above path it would get disabled due to a bug or otherwise. The i915 code is correct AFAICS, but the core complains about a nested invocation of pm_runtime_get_sync() with disabled interrupts (which looks OK though), so the complaint is a false positive. Well, my point was that interrupts (or preemption) doesn't seem to get disabled anywhere on that path. But the might_sleep_if() assertion in __pm_runtime_resume() triggers for some reason. I wonder why then? Of course, I may be overlooking something in the i915 code. In any case, if you do pm_runtime_get_sync(dev) local_irq_disable() pm_runtime_get_sync(dev) pm_runtime_put(dev) local_irq_enable() pm_runtime_put(dev) that is technically correct, but it will cause the core to complain. Thanks, Rafael ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atomic: Fix double free in drm_atomic_state_default_clear
Hi Maarten, 2017-01-31 Maarten Lankhorst: > drm_atomic_helper_page_flip and drm_atomic_ioctl set their own events > in crtc_state->event. But when it's set the event is freed in 2 places. > > Solve this by only freeing the event in the atomic ioctl when it > allocated its own event. > > This has been broken twice. The first time when the code was introduced, > but only in the corner case when an event is allocated, but more crtc's > were included by atomic check and then failing. This can mostly > happen when you do an atomic modeset in i915 and the display clock is > changed, which forces all crtc's to be included to the state. > > This has been broken worse by adding in-fences support, which caused > the double free to be done unconditionally. > > [IGT] kms_rotation_crc: starting subtest primary-rotation-180 > = > BUG kmalloc-128 (Tainted: G U ): Object already free > - > > Disabling lock debugging due to kernel taint > INFO: Allocated in drm_atomic_helper_setup_commit+0x285/0x2f0 > [drm_kms_helper] age=0 cpu=3 pid=1529 > ___slab_alloc+0x308/0x3b0 > __slab_alloc+0xd/0x20 > kmem_cache_alloc_trace+0x92/0x1c0 > drm_atomic_helper_setup_commit+0x285/0x2f0 [drm_kms_helper] > intel_atomic_commit+0x35/0x4f0 [i915] > drm_atomic_commit+0x46/0x50 [drm] > drm_mode_atomic_ioctl+0x7d4/0xab0 [drm] > drm_ioctl+0x2b3/0x490 [drm] > do_vfs_ioctl+0x69c/0x700 > SyS_ioctl+0x4e/0x80 > entry_SYSCALL_64_fastpath+0x13/0x94 > INFO: Freed in drm_event_cancel_free+0xa3/0xb0 [drm] age=0 cpu=3 pid=1529 > __slab_free+0x48/0x2e0 > kfree+0x159/0x1a0 > drm_event_cancel_free+0xa3/0xb0 [drm] > drm_mode_atomic_ioctl+0x86d/0xab0 [drm] > drm_ioctl+0x2b3/0x490 [drm] > do_vfs_ioctl+0x69c/0x700 > SyS_ioctl+0x4e/0x80 > entry_SYSCALL_64_fastpath+0x13/0x94 > INFO: Slab 0xde1f0997b080 objects=17 used=2 fp=0x92fb65ec2578 > flags=0x2008101 > INFO: Object 0x92fb65ec2578 @offset=1400 fp=0x92fb65ec2ae8 > > Redzone 92fb65ec2570: bb bb bb bb bb bb bb bb > > Object 92fb65ec2578: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > Object 92fb65ec2588: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > Object 92fb65ec2598: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > Object 92fb65ec25a8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > Object 92fb65ec25b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > Object 92fb65ec25c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > Object 92fb65ec25d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > Object 92fb65ec25e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 > kkk. > Redzone 92fb65ec25f8: bb bb bb bb bb bb bb bb > > Padding 92fb65ec2738: 5a 5a 5a 5a 5a 5a 5a 5a > > CPU: 3 PID: 180 Comm: kworker/3:2 Tainted: GBU > 4.10.0-rc6-patser+ #5039 > Hardware name: /NUC5PPYB, BIOS > PYBSWCEL.86A.0031.2015.0601.1712 06/01/2015 > Workqueue: events intel_atomic_helper_free_state [i915] > Call Trace: > dump_stack+0x4d/0x6d > print_trailer+0x20c/0x220 > free_debug_processing+0x1c6/0x330 > ? drm_atomic_state_default_clear+0xf7/0x1c0 [drm] > __slab_free+0x48/0x2e0 > ? drm_atomic_state_default_clear+0xf7/0x1c0 [drm] > kfree+0x159/0x1a0 > drm_atomic_state_default_clear+0xf7/0x1c0 [drm] > ? drm_atomic_state_clear+0x30/0x30 [drm] > intel_atomic_state_clear+0xd/0x20 [i915] > drm_atomic_state_clear+0x1a/0x30 [drm] > __drm_atomic_state_free+0x13/0x60 [drm] > intel_atomic_helper_free_state+0x5d/0x70 [i915] > process_one_work+0x260/0x4a0 > worker_thread+0x2d1/0x4f0 > kthread+0x127/0x130 > ? process_one_work+0x4a0/0x4a0 > ? kthread_stop+0x120/0x120 > ret_from_fork+0x29/0x40 > FIX kmalloc-128: Object at 0x92fb65ec2578 not freed > > Fixes: 3b24f7d67581 ("drm/atomic: Add struct drm_crtc_commit to track async > updates") > Fixes: 9626014258a5 ("drm/fence: add in-fences support") > Cc: # v4.8+ > Cc: Daniel Vetter > Signed-off-by: Maarten Lankhorst > Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/drm_atomic.c | 13 - > 1 file changed, 8 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c > index 50f5cf7b69d1..fdfb1ec17e66 100644 > --- a/drivers/gpu/drm/drm_atomic.c > +++ b/drivers/gpu/drm/drm_atomic.c > @@ -2032,13 +2032,16 @@ static void complete_crtc_signaling(struct drm_device > *dev, > } > > for_each_crtc_in_state(state, crtc,
Re: [Intel-gfx] [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)
On Tue, Jan 31, 2017 at 12:39:35PM +0100, Rafael J. Wysocki wrote: > On 1/31/2017 11:58 AM, Imre Deak wrote: > >Hi Rafael, > > Hi, > > >On Mon, Jan 30, 2017 at 11:44:37PM +0100, Rafael J. Wysocki wrote: > >>On 1/24/2017 2:33 AM, Sedat Dilek wrote: > >>>On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki> >>>wrote: > On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek > wrote: > >Hi, > > > >I have already reported this issue in [1]. > >One of the issue was solved. > >Unfortunately, it looks like there is still a different problem here > >(Ubuntu/precise AMD64). > > > >I tried v4.10-rc1 and latest Linus tree up to... > > > >commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1 > >"mm/filemap: fix parameters to test_bit()" > > > >Here we go... > > > >[ 29.636047] BUG: sleeping function called from invalid context at > >drivers/base/power/runtime.c:1032 > >[ 29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg > >[ 29.636058] 1 lock held by Xorg/1500: > >[ 29.636060] #0: (>struct_mutex){+.+.+.}, at: > >[] i915_mutex_lock_interruptible+0x43/0x140 [i915] > >[ 29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted > >4.10.0-rc1-6-iniza-amd64 #1 > >[ 29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD. > >530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013 > >[ 29.636111] Call Trace: > >[ 29.636120] dump_stack+0x85/0xc2 > >[ 29.636124] ___might_sleep+0x196/0x260 > >[ 29.636127] __might_sleep+0x53/0xb0 > >[ 29.636131] __pm_runtime_resume+0x7a/0x90 > >[ 29.636159] intel_runtime_pm_get+0x25/0x90 [i915] > >[ 29.636189] aliasing_gtt_bind_vma+0xaa/0xf0 [i915] > >[ 29.636220] i915_vma_bind+0xaf/0x1e0 [i915] > >[ 29.636248] i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915] > >[ 29.636272] i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 > >[i915] > >[ 29.636275] ? trace_hardirqs_on+0xd/0x10 > >[ 29.636294] ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 > >[i915] > >[ 29.636316] ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915] > >[ 29.636342] i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915] > >[ 29.636347] ? __might_fault+0x4e/0xb0 > >[ 29.636373] i915_gem_execbuffer2+0xc5/0x260 [i915] > >[ 29.636376] ? __might_fault+0x4e/0xb0 > >[ 29.636395] drm_ioctl+0x206/0x450 [drm] > >[ 29.636420] ? i915_gem_execbuffer+0x340/0x340 [i915] > >[ 29.636425] ? __fget+0x5/0x200 > >[ 29.636429] do_vfs_ioctl+0x91/0x6f0 > >[ 29.636431] ? __fget+0x111/0x200 > >[ 29.636433] ? __fget+0x5/0x200 > >[ 29.636436] SyS_ioctl+0x79/0x90 > >[ 29.636441] entry_SYSCALL_64_fastpath+0x23/0xc6 > > > >On suspend/resume I see the same call trace. > >[2] points to the "BUG" line. > Well, this appears to be an i915 issue, but not a serious one. > > Clearly, a function that may sleep (pm_runtime_get_sync() in > intel_runtime_pm_get()) is called with disabled interrupts. If I > understand the code correctly, though, it actually is not going to > sleep in this particular case, because pm_runtime_get_sync() has > already been called once for this device in the same code path which > means that this particular instance will return immediately, so this > is a false-positive (most likely). > >Not sure what's the root cause, but thought to clarify the above: > > > >Yes, i915_gem_do_execbuffer() does take an RPM reference to optimize > >things, so the RPM get in aliasing_gtt_bind_vma() won't need to resume > >the device on this path. This isn't a guarantee though, > >aliasing_gtt_bind_vma() could be called from other places without an RPM > >reference. So preemption being disabled at that point is not > >intentional. I also can't see where on the above path it would get > >disabled due to a bug or otherwise. > > The i915 code is correct AFAICS, but the core complains about a nested > invocation of pm_runtime_get_sync() with disabled interrupts (which looks OK > though), so the complaint is a false positive. Well, my point was that interrupts (or preemption) doesn't seem to get disabled anywhere on that path. --Imre > > As I said, the way to go here appears to be to tweak the core, which I'm > going to do. > > Thanks, > Rafael > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 33/38] drm/i915: Test creation of partial VMA
On to, 2017-01-19 at 11:41 +, Chris Wilson wrote: > Mock testing to ensure we can create and lookup partial VMA. > > Signed-off-by: Chris Wilson> +static bool assert_partial(struct drm_i915_gem_object *obj, > + struct i915_vma *vma, > + unsigned long offset, > + unsigned long size) > +{ > + struct sgt_iter sgt; Confusing name, could rather be "sgti" or just "i", or "iter". > +static int igt_vma_partial(void *arg) > +{ > + struct drm_i915_private *i915 = arg; > + const unsigned int npages = 1021; /* prime! */ #define THE_MAGIC_PRIME 1021 > + for (loop = 0; loop <= 1; loop++) { /* exercise both create/lookup */ I'd like the phase array/variable more. "loop" variable is kinda confusing easily. > + unsigned int count, nvma; > + Make a comment here that a whole VMA is also created at the end and it needs to be accounted. This is why the phase array might be more readable. > + nvma = loop; > + for_each_prime_number_from(sz, 1, npages) { > + for_each_prime_number_from(offset, 0, npages - sz) { > + struct i915_address_space *vm = > + >ggtt.base; Could be out of the loop, too. > + > + /* Create a mapping for the entire object, just for extra fun */ > + vma = i915_vma_instance(obj, >ggtt.base, NULL); No helper for this block? With the variable renamed; Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)
On 1/31/2017 11:58 AM, Imre Deak wrote: Hi Rafael, Hi, On Mon, Jan 30, 2017 at 11:44:37PM +0100, Rafael J. Wysocki wrote: On 1/24/2017 2:33 AM, Sedat Dilek wrote: On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysockiwrote: On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek wrote: Hi, I have already reported this issue in [1]. One of the issue was solved. Unfortunately, it looks like there is still a different problem here (Ubuntu/precise AMD64). I tried v4.10-rc1 and latest Linus tree up to... commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1 "mm/filemap: fix parameters to test_bit()" Here we go... [ 29.636047] BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1032 [ 29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg [ 29.636058] 1 lock held by Xorg/1500: [ 29.636060] #0: (>struct_mutex){+.+.+.}, at: [] i915_mutex_lock_interruptible+0x43/0x140 [i915] [ 29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted 4.10.0-rc1-6-iniza-amd64 #1 [ 29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013 [ 29.636111] Call Trace: [ 29.636120] dump_stack+0x85/0xc2 [ 29.636124] ___might_sleep+0x196/0x260 [ 29.636127] __might_sleep+0x53/0xb0 [ 29.636131] __pm_runtime_resume+0x7a/0x90 [ 29.636159] intel_runtime_pm_get+0x25/0x90 [i915] [ 29.636189] aliasing_gtt_bind_vma+0xaa/0xf0 [i915] [ 29.636220] i915_vma_bind+0xaf/0x1e0 [i915] [ 29.636248] i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915] [ 29.636272] i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915] [ 29.636275] ? trace_hardirqs_on+0xd/0x10 [ 29.636294] ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 [i915] [ 29.636316] ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915] [ 29.636342] i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915] [ 29.636347] ? __might_fault+0x4e/0xb0 [ 29.636373] i915_gem_execbuffer2+0xc5/0x260 [i915] [ 29.636376] ? __might_fault+0x4e/0xb0 [ 29.636395] drm_ioctl+0x206/0x450 [drm] [ 29.636420] ? i915_gem_execbuffer+0x340/0x340 [i915] [ 29.636425] ? __fget+0x5/0x200 [ 29.636429] do_vfs_ioctl+0x91/0x6f0 [ 29.636431] ? __fget+0x111/0x200 [ 29.636433] ? __fget+0x5/0x200 [ 29.636436] SyS_ioctl+0x79/0x90 [ 29.636441] entry_SYSCALL_64_fastpath+0x23/0xc6 On suspend/resume I see the same call trace. [2] points to the "BUG" line. Well, this appears to be an i915 issue, but not a serious one. Clearly, a function that may sleep (pm_runtime_get_sync() in intel_runtime_pm_get()) is called with disabled interrupts. If I understand the code correctly, though, it actually is not going to sleep in this particular case, because pm_runtime_get_sync() has already been called once for this device in the same code path which means that this particular instance will return immediately, so this is a false-positive (most likely). Not sure what's the root cause, but thought to clarify the above: Yes, i915_gem_do_execbuffer() does take an RPM reference to optimize things, so the RPM get in aliasing_gtt_bind_vma() won't need to resume the device on this path. This isn't a guarantee though, aliasing_gtt_bind_vma() could be called from other places without an RPM reference. So preemption being disabled at that point is not intentional. I also can't see where on the above path it would get disabled due to a bug or otherwise. The i915 code is correct AFAICS, but the core complains about a nested invocation of pm_runtime_get_sync() with disabled interrupts (which looks OK though), so the complaint is a false positive. As I said, the way to go here appears to be to tweak the core, which I'm going to do. Thanks, Rafael ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] intel-ci: Minimal exercise of explicit fencing
On Tue, Jan 31, 2017 at 01:21:15PM +0200, Petri Latvala wrote: > On Tue, Jan 31, 2017 at 09:54:21AM +, Chris Wilson wrote: > > Ping? And any feedback from the earlier ringfill-fds? > > -Chris > > > Sent ack on the ringfill test. This one has been queued for a test > round at farm2. > > For those following along and smelling chances of getting their > $favoritefeatureoftheday into BAT, I'm being a little more lenient > than I should with allowing more tests into fast-feedback at this > time. As soon as we can deploy Ezbench-driven extended testing (not > far now btw), fast-feedback will go on a diet. Unless that is accompanied by some coverage based feedback methodology consider me grumpy. I wish that we had the tools for BAT to be an automatic selection of the testcases that gave excellent coverage and sensitivity. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: The return of i915_gpu_info to debugfs
== Series Details == Series: drm/i915: The return of i915_gpu_info to debugfs URL : https://patchwork.freedesktop.org/series/18833/ State : failure == Summary == Series 18833v1 drm/i915: The return of i915_gpu_info to debugfs https://patchwork.freedesktop.org/api/1.0/series/18833/revisions/1/mbox/ Test drv_hangman: Subgroup error-state-basic: pass -> FAIL (fi-snb-2520m) pass -> FAIL (fi-snb-2600) pass -> FAIL (fi-skl-6700k) pass -> FAIL (fi-bxt-j4205) pass -> FAIL (fi-hsw-4770) pass -> FAIL (fi-skl-6770hq) pass -> FAIL (fi-hsw-4770r) pass -> FAIL (fi-skl-6700hq) pass -> FAIL (fi-byt-n2820) pass -> FAIL (fi-bsw-n3050) pass -> FAIL (fi-bxt-t5700) pass -> FAIL (fi-ivb-3520m) pass -> FAIL (fi-ivb-3770) pass -> FAIL (fi-bdw-5557u) pass -> FAIL (fi-byt-j1900) pass -> FAIL (fi-skl-6260u) fi-bdw-5557u total:246 pass:231 dwarn:0 dfail:0 fail:1 skip:14 fi-bsw-n3050 total:246 pass:206 dwarn:0 dfail:0 fail:1 skip:39 fi-bxt-j4205 total:246 pass:223 dwarn:0 dfail:0 fail:1 skip:22 fi-bxt-t5700 total:78 pass:64 dwarn:0 dfail:0 fail:1 skip:12 fi-byt-j1900 total:246 pass:218 dwarn:0 dfail:0 fail:1 skip:27 fi-byt-n2820 total:246 pass:214 dwarn:0 dfail:0 fail:1 skip:31 fi-hsw-4770 total:246 pass:226 dwarn:0 dfail:0 fail:1 skip:19 fi-hsw-4770r total:246 pass:226 dwarn:0 dfail:0 fail:1 skip:19 fi-ivb-3520m total:246 pass:224 dwarn:0 dfail:0 fail:1 skip:21 fi-ivb-3770 total:246 pass:224 dwarn:0 dfail:0 fail:1 skip:21 fi-skl-6260u total:246 pass:232 dwarn:0 dfail:0 fail:1 skip:13 fi-skl-6700hqtotal:246 pass:225 dwarn:0 dfail:0 fail:1 skip:20 fi-skl-6700k total:246 pass:220 dwarn:4 dfail:0 fail:1 skip:21 fi-skl-6770hqtotal:246 pass:232 dwarn:0 dfail:0 fail:1 skip:13 fi-snb-2520m total:246 pass:214 dwarn:0 dfail:0 fail:1 skip:31 fi-snb-2600 total:246 pass:213 dwarn:0 dfail:0 fail:1 skip:32 5689d1f0e8e542fc5a89191493fb77188add8807 drm-tip: 2017y-01m-31d-10h-05m-02s UTC integration manifest 5e63eb9 drm/i915: The return of i915_gpu_info to debugfs == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3652/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Be defensive when cleaning up i915_gem_internal pages
On Tue, Jan 31, 2017 at 11:04:49AM +, Matthew Auld wrote: > On 31 January 2017 at 10:46, Chris Wilsonwrote: > > If we abort the i915_gem_internal get_pages, we mark the failing sg as > > the last. However, that means we iterate upto and including the failing > > sg element and results us in trying to free the unallocated sg_page(). > s/us in/in us/ Ta. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] intel-ci: Minimal exercise of explicit fencing
On Tue, Jan 31, 2017 at 09:54:21AM +, Chris Wilson wrote: > Ping? And any feedback from the earlier ringfill-fds? > -Chris Sent ack on the ringfill test. This one has been queued for a test round at farm2. For those following along and smelling chances of getting their $favoritefeatureoftheday into BAT, I'm being a little more lenient than I should with allowing more tests into fast-feedback at this time. As soon as we can deploy Ezbench-driven extended testing (not far now btw), fast-feedback will go on a diet. -- Petri Latvala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] intel-ci: Add multiple ringfill for execlists
On Tue, Jan 24, 2017 at 01:02:23PM +0200, Petri Latvala wrote: > On Tue, Jan 24, 2017 at 09:31:39AM +, Chris Wilson wrote: > > On Wed, Jan 18, 2017 at 08:54:10PM +, Chris Wilson wrote: > > > Execlists introduces a new wrinkle to filling rings, in that each > > > context has an independent set of rings. Add the subtest that exercises > > > filling multiple execlist rings (for the same engine) to BAT. > > > > > > Signed-off-by: Chris Wilson> > > Cc: Petri Latvala > > > > Ping? This provides coverage of some hairy paths on execlists/guc that > > currently have nothing explicit. > > > Sent to farm2 for a test round. Acked-by: Petri Latvala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Be defensive when cleaning up i915_gem_internal pages
On 31 January 2017 at 10:46, Chris Wilsonwrote: > If we abort the i915_gem_internal get_pages, we mark the failing sg as > the last. However, that means we iterate upto and including the failing > sg element and results us in trying to free the unallocated sg_page(). s/us in/in us/ > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add MIPI_IO WA and program DSI regulators
Looks ok. Acked-by: Mika KaholaOn Wed, 2017-01-25 at 19:43 +0530, Vidya Srinivas wrote: > From: Uma Shankar > > Enable MIPI IO WA for BXT DSI as per bspec and > program the DSI regulators. > > v2: Moved IO enable to pre-enable as per Mika's > review comments. Also reused the existing register > definition for BXT_P_CR_GT_DISP_PWRON. > > v3: Added Programming the DSI regulators as per disable/enable > sequences. > > v4: Restricting regulator changes to BXT as suggested by > Jani/Mika > > v5: Removed redundant read/modify for regulator register as > per Jani's comment. Maintain enable/disable symmetry as per spec. > > Signed-off-by: Uma Shankar > Signed-off-by: Vidya Srinivas > --- > drivers/gpu/drm/i915/i915_reg.h | 7 +++ > drivers/gpu/drm/i915/intel_dsi.c | 24 > 2 files changed, 31 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_reg.h > b/drivers/gpu/drm/i915/i915_reg.h > index 00970aa..0a9ad44 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -1553,6 +1553,7 @@ enum skl_disp_power_wells { > _MMIO(_BXT_PHY_CH(phy, ch, reg_ch0, reg_ch1)) > > #define BXT_P_CR_GT_DISP_PWRON _MMIO(0x138090) > +#define MIPIO_RST_CTRL (1 << 2) > > #define _BXT_PHY_CTL_DDI_A 0x64C00 > #define _BXT_PHY_CTL_DDI_B 0x64C10 > @@ -8301,6 +8302,12 @@ enum { > #define _BXT_MIPIC_PORT_CTRL 0x6B8C0 > #define BXT_MIPI_PORT_CTRL(tc) _MMIO_MIPI(tc, > _BXT_MIPIA_PORT_CTRL, _BXT_MIPIC_PORT_CTRL) > > +#define BXT_P_DSI_REGULATOR_CFG _MMIO(0x16002 > 0) > +#define STAP_SELECT (1 << 0) > + > +#define BXT_P_DSI_REGULATOR_TX_CTRL _MMIO(0x160054) > +#define HS_IO_CTRL_SELECT (1 << 0) > + > #define DPI_ENABLE (1 << 31) > /* A + C */ > #define MIPIA_MIPI4DPHY_DELAY_COUNT_SHIFT 27 > #define MIPIA_MIPI4DPHY_DELAY_COUNT_MASK(0xf << 27) > diff --git a/drivers/gpu/drm/i915/intel_dsi.c > b/drivers/gpu/drm/i915/intel_dsi.c > index 16732e7..c98234e 100644 > --- a/drivers/gpu/drm/i915/intel_dsi.c > +++ b/drivers/gpu/drm/i915/intel_dsi.c > @@ -548,6 +548,7 @@ static void intel_dsi_pre_enable(struct > intel_encoder *encoder, > struct drm_i915_private *dev_priv = to_i915(encoder- > >base.dev); > struct intel_dsi *intel_dsi = enc_to_intel_dsi( > >base); > enum port port; > + u32 val; > > DRM_DEBUG_KMS("\n"); > > @@ -558,6 +559,17 @@ static void intel_dsi_pre_enable(struct > intel_encoder *encoder, > intel_disable_dsi_pll(encoder); > intel_enable_dsi_pll(encoder, pipe_config); > > + if (IS_BROXTON(dev_priv)) { > + /* Add MIPI IO reset programming for modeset */ > + val = I915_READ(BXT_P_CR_GT_DISP_PWRON); > + I915_WRITE(BXT_P_CR_GT_DISP_PWRON, > + val | MIPIO_RST_CTRL); > + > + /* Power up DSI regulator */ > + I915_WRITE(BXT_P_DSI_REGULATOR_CFG, STAP_SELECT); > + I915_WRITE(BXT_P_DSI_REGULATOR_TX_CTRL, 0); > + } > + > intel_dsi_prepare(encoder, pipe_config); > > /* Panel Enable over CRC PMIC */ > @@ -707,6 +719,7 @@ static void intel_dsi_post_disable(struct > intel_encoder *encoder, > { > struct drm_i915_private *dev_priv = to_i915(encoder- > >base.dev); > struct intel_dsi *intel_dsi = enc_to_intel_dsi( > >base); > + u32 val; > > DRM_DEBUG_KMS("\n"); > > @@ -714,6 +727,17 @@ static void intel_dsi_post_disable(struct > intel_encoder *encoder, > > intel_dsi_clear_device_ready(encoder); > > + if (IS_BROXTON(dev_priv)) { > + /* Power down DSI regulator to save power */ > + I915_WRITE(BXT_P_DSI_REGULATOR_CFG, STAP_SELECT); > + I915_WRITE(BXT_P_DSI_REGULATOR_TX_CTRL, > HS_IO_CTRL_SELECT); > + > + /* Add MIPI IO reset programming for modeset */ > + val = I915_READ(BXT_P_CR_GT_DISP_PWRON); > + I915_WRITE(BXT_P_CR_GT_DISP_PWRON, > + val & ~MIPIO_RST_CTRL); > + } > + > intel_disable_dsi_pll(encoder); > > if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) { -- Mika Kahola - Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)
Hi Rafael, On Mon, Jan 30, 2017 at 11:44:37PM +0100, Rafael J. Wysocki wrote: > On 1/24/2017 2:33 AM, Sedat Dilek wrote: > >On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysockiwrote: > >>On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek wrote: > >>>Hi, > >>> > >>>I have already reported this issue in [1]. > >>>One of the issue was solved. > >>>Unfortunately, it looks like there is still a different problem here > >>>(Ubuntu/precise AMD64). > >>> > >>>I tried v4.10-rc1 and latest Linus tree up to... > >>> > >>>commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1 > >>>"mm/filemap: fix parameters to test_bit()" > >>> > >>>Here we go... > >>> > >>>[ 29.636047] BUG: sleeping function called from invalid context at > >>>drivers/base/power/runtime.c:1032 > >>>[ 29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg > >>>[ 29.636058] 1 lock held by Xorg/1500: > >>>[ 29.636060] #0: (>struct_mutex){+.+.+.}, at: > >>>[] i915_mutex_lock_interruptible+0x43/0x140 [i915] > >>>[ 29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted > >>>4.10.0-rc1-6-iniza-amd64 #1 > >>>[ 29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD. > >>>530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013 > >>>[ 29.636111] Call Trace: > >>>[ 29.636120] dump_stack+0x85/0xc2 > >>>[ 29.636124] ___might_sleep+0x196/0x260 > >>>[ 29.636127] __might_sleep+0x53/0xb0 > >>>[ 29.636131] __pm_runtime_resume+0x7a/0x90 > >>>[ 29.636159] intel_runtime_pm_get+0x25/0x90 [i915] > >>>[ 29.636189] aliasing_gtt_bind_vma+0xaa/0xf0 [i915] > >>>[ 29.636220] i915_vma_bind+0xaf/0x1e0 [i915] > >>>[ 29.636248] i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915] > >>>[ 29.636272] i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915] > >>>[ 29.636275] ? trace_hardirqs_on+0xd/0x10 > >>>[ 29.636294] ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 > >>>[i915] > >>>[ 29.636316] ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915] > >>>[ 29.636342] i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915] > >>>[ 29.636347] ? __might_fault+0x4e/0xb0 > >>>[ 29.636373] i915_gem_execbuffer2+0xc5/0x260 [i915] > >>>[ 29.636376] ? __might_fault+0x4e/0xb0 > >>>[ 29.636395] drm_ioctl+0x206/0x450 [drm] > >>>[ 29.636420] ? i915_gem_execbuffer+0x340/0x340 [i915] > >>>[ 29.636425] ? __fget+0x5/0x200 > >>>[ 29.636429] do_vfs_ioctl+0x91/0x6f0 > >>>[ 29.636431] ? __fget+0x111/0x200 > >>>[ 29.636433] ? __fget+0x5/0x200 > >>>[ 29.636436] SyS_ioctl+0x79/0x90 > >>>[ 29.636441] entry_SYSCALL_64_fastpath+0x23/0xc6 > >>> > >>>On suspend/resume I see the same call trace. > >>>[2] points to the "BUG" line. > >>Well, this appears to be an i915 issue, but not a serious one. > >> > >>Clearly, a function that may sleep (pm_runtime_get_sync() in > >>intel_runtime_pm_get()) is called with disabled interrupts. If I > >>understand the code correctly, though, it actually is not going to > >>sleep in this particular case, because pm_runtime_get_sync() has > >>already been called once for this device in the same code path which > >>means that this particular instance will return immediately, so this > >>is a false-positive (most likely). Not sure what's the root cause, but thought to clarify the above: Yes, i915_gem_do_execbuffer() does take an RPM reference to optimize things, so the RPM get in aliasing_gtt_bind_vma() won't need to resume the device on this path. This isn't a guarantee though, aliasing_gtt_bind_vma() could be called from other places without an RPM reference. So preemption being disabled at that point is not intentional. I also can't see where on the above path it would get disabled due to a bug or otherwise. --Imre > >> > >>Let me see if I the might_sleep_if() assertion in > >>__pm_runtime_resume(() can be moved to a better place. > >> > >Hi Rafael, > > > >did you had a chance to look at this? > >The problem still remains in Linux v4.10-rc5. > > No, I didn't. > > As I said, this is not a serious issue. > > Thanks, > Rafael > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 30/38] drm/i915: Test creation of VMA
On to, 2017-01-19 at 11:41 +, Chris Wilson wrote: > Simple test to exercise creation and lookup of VMA within an object. > > Signed-off-by: Chris Wilson> +static bool assert_vma(struct i915_vma *vma, > + struct drm_i915_gem_object *obj, > + struct i915_gem_context *ctx) > +{ > + if (vma->vm != >ppgtt->base) { > + pr_err("VMA created with wrong VM\n"); > + return false; > + } maybe "bool correct = true;" and list all the errors he VMA has? and finally return correct; > + for_each_prime_number(num_obj, ULONG_MAX - 1) { > + for (; no < num_obj; no++) { > + obj = i915_gem_object_create_internal(i915, PAGE_SIZE); > + if (IS_ERR(obj)) > + goto err; > + > + list_add(>batch_pool_link, ); See below; > + } > + > + nc = 0; > + for_each_prime_number(num_ctx, MAX_CONTEXT_HW_ID) { > + for (; nc < num_ctx; nc++) { > + ctx = mock_context(i915, "mock"); > + if (!ctx) > + goto err; > + > + list_move(>link, ); Why the difference? > + } > + > + err = create_vmas(i915, , ); > + if (err) > + goto err; > + > + if (igt_timeout(end_time, > + "%s timed out: after %lu objects\n", > + __func__, no)) Maybe also context count, because it's available. Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Be defensive when cleaning up i915_gem_internal pages
If we abort the i915_gem_internal get_pages, we mark the failing sg as the last. However, that means we iterate upto and including the failing sg element and results us in trying to free the unallocated sg_page(). Signed-off-by: Chris Wilson--- drivers/gpu/drm/i915/i915_gem_internal.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_internal.c b/drivers/gpu/drm/i915/i915_gem_internal.c index 17ce53d0d092..64d8fb3fd764 100644 --- a/drivers/gpu/drm/i915/i915_gem_internal.c +++ b/drivers/gpu/drm/i915/i915_gem_internal.c @@ -35,8 +35,10 @@ static void internal_free_pages(struct sg_table *st) { struct scatterlist *sg; - for (sg = st->sgl; sg; sg = __sg_next(sg)) - __free_pages(sg_page(sg), get_order(sg->length)); + for (sg = st->sgl; sg; sg = __sg_next(sg)) { + if (sg_page(sg)) + __free_pages(sg_page(sg), get_order(sg->length)); + } sg_free_table(st); kfree(st); @@ -116,6 +118,7 @@ i915_gem_object_get_pages_internal(struct drm_i915_gem_object *obj) return st; err: + sg_set_page(sg, NULL, 0, 0); sg_mark_end(sg); internal_free_pages(st); return ERR_PTR(-ENOMEM); -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: The return of i915_gpu_info to debugfs
Once upon a time before we had automated GPU state capture upon hangs, we had intel_gpu_dump. Now we come almost full circle and reinstate that view of the current GPU queues and registers by using the error capture facility to snapshot the GPU state when debugfs/.../i915_gpu_info is opened - which should provided useful debugging to both the error capture routines (without having to cause a hang and avoid the error state being eaten by igt) and generally. Signed-off-by: Chris WilsonCc: Mika Kuoppala --- drivers/gpu/drm/i915/i915_debugfs.c | 123 +++--- drivers/gpu/drm/i915/i915_drv.h | 26 --- drivers/gpu/drm/i915/i915_gpu_error.c | 71 drivers/gpu/drm/i915/i915_sysfs.c | 31 + 4 files changed, 132 insertions(+), 119 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 3ae06568df7b..124a184389a8 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -954,89 +954,103 @@ static int i915_gem_fence_regs_info(struct seq_file *m, void *data) } #if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR) - -static ssize_t -i915_error_state_write(struct file *filp, - const char __user *ubuf, - size_t cnt, - loff_t *ppos) +static ssize_t error_state_read(struct file *file, char __user *ubuf, + size_t count, loff_t *pos) { - struct i915_error_state_file_priv *error_priv = filp->private_data; - - DRM_DEBUG_DRIVER("Resetting error state\n"); - i915_destroy_error_state(error_priv->i915); - - return cnt; -} + struct drm_i915_error_state *error = file->private_data; + struct drm_i915_error_state_buf str; + ssize_t ret; + loff_t tmp; -static int i915_error_state_open(struct inode *inode, struct file *file) -{ - struct drm_i915_private *dev_priv = inode->i_private; - struct i915_error_state_file_priv *error_priv; + if (!error) + return 0; - error_priv = kzalloc(sizeof(*error_priv), GFP_KERNEL); - if (!error_priv) - return -ENOMEM; + ret = i915_error_state_buf_init(, error->i915, count, *pos); + if (ret) + return ret; - error_priv->i915 = dev_priv; + ret = i915_error_state_to_str(, error); + if (ret) + goto out; - i915_error_state_get(_priv->drm, error_priv); + tmp = 0; + ret = simple_read_from_buffer(ubuf, count, , str.buf, str.bytes); + if (ret < 0) + goto out; - file->private_data = error_priv; + *pos = str.start + ret; +out: + i915_error_state_buf_release(); + return ret; +} +static int error_state_release(struct inode *inode, struct file *file) +{ + i915_error_state_put(file->private_data); return 0; } -static int i915_error_state_release(struct inode *inode, struct file *file) +static int i915_gpu_info_open(struct inode *inode, struct file *file) { - struct i915_error_state_file_priv *error_priv = file->private_data; + struct drm_i915_error_state *error; - i915_error_state_put(error_priv); - kfree(error_priv); + error = i915_error_state(inode->i_private); + if (!error) + return -ENOMEM; + file->private_data = error; return 0; } -static ssize_t i915_error_state_read(struct file *file, char __user *userbuf, -size_t count, loff_t *pos) +static const struct file_operations i915_gpu_info_fops = { + .owner = THIS_MODULE, + .open = i915_gpu_info_open, + .read = error_state_read, + .llseek = default_llseek, + .release = error_state_release, +}; + +static ssize_t +i915_error_state_write(struct file *filp, + const char __user *ubuf, + size_t cnt, + loff_t *ppos) { - struct i915_error_state_file_priv *error_priv = file->private_data; - struct drm_i915_error_state_buf error_str; - loff_t tmp_pos = 0; - ssize_t ret_count = 0; - int ret; + struct drm_i915_error_state *error = filp->private_data; - ret = i915_error_state_buf_init(_str, error_priv->i915, - count, *pos); - if (ret) - return ret; + if (!error) + return 0; - ret = i915_error_state_to_str(_str, error_priv); - if (ret) - goto out; + DRM_DEBUG_DRIVER("Resetting error state\n"); + i915_destroy_error_state(error->i915); - ret_count = simple_read_from_buffer(userbuf, count, _pos, - error_str.buf, - error_str.bytes); + return cnt; +} - if (ret_count < 0) -
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/atomic: Fix double free in drm_atomic_state_default_clear
== Series Details == Series: drm/atomic: Fix double free in drm_atomic_state_default_clear URL : https://patchwork.freedesktop.org/series/18826/ State : success == Summary == Series 18826v1 drm/atomic: Fix double free in drm_atomic_state_default_clear https://patchwork.freedesktop.org/api/1.0/series/18826/revisions/1/mbox/ Test kms_flip: Subgroup basic-flip-vs-wf_vblank: dmesg-warn -> PASS (fi-snb-2520m) Test kms_force_connector_basic: Subgroup force-connector-state: dmesg-warn -> PASS (fi-snb-2520m) Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-a: dmesg-warn -> PASS (fi-snb-2520m) fi-bdw-5557u total:246 pass:232 dwarn:0 dfail:0 fail:0 skip:14 fi-bsw-n3050 total:246 pass:207 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:246 pass:224 dwarn:0 dfail:0 fail:0 skip:22 fi-bxt-t5700 total:78 pass:65 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:246 pass:219 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:246 pass:215 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:246 pass:227 dwarn:0 dfail:0 fail:0 skip:19 fi-hsw-4770r total:246 pass:227 dwarn:0 dfail:0 fail:0 skip:19 fi-ivb-3520m total:246 pass:225 dwarn:0 dfail:0 fail:0 skip:21 fi-kbl-7500u total:246 pass:223 dwarn:0 dfail:0 fail:2 skip:21 fi-skl-6260u total:246 pass:233 dwarn:0 dfail:0 fail:0 skip:13 fi-skl-6700hqtotal:246 pass:226 dwarn:0 dfail:0 fail:0 skip:20 fi-skl-6700k total:246 pass:221 dwarn:4 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:246 pass:233 dwarn:0 dfail:0 fail:0 skip:13 fi-snb-2520m total:246 pass:215 dwarn:0 dfail:0 fail:0 skip:31 fi-snb-2600 total:246 pass:214 dwarn:0 dfail:0 fail:0 skip:32 123d798c350471aba7e0625c154c6d9e395756c8 drm-tip: 2017y-01m-30d-21h-14m-37s UTC integration manifest 3d83408 drm/atomic: Fix double free in drm_atomic_state_default_clear == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3651/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v3 00/11] tests/kms_atomic_transition add fence testing
On Mon, Jan 30, 2017 at 08:58:36PM -0500, Robert Foss wrote: > This series adds in/out fence testing to kms_atomic_transition test and makes > some minor cleanups. > > This series is rebased ontop of the dyn_n_planes_v3 series. > > This series can be found here: > https://git.collabora.com/cgit/user/robertfoss/intel-gpu-tools.git/log/?h=fences_$VER > > > Changes since v1: > > lib/igt_kms: >- Added gtk-doc for exported symbols >- Changed integer casting to avoid potential issues >- Changed out_fence_ptr type to int64_t* >- Fixed igt_plane_set_fence_fd comment > > tests/: >- Rework timeout change in commit_display() >- Extract plane_invalid_params_fence() out plane_invalid_params() >- Extract crtc_invalid_params_fence() out crtc_invalid_params() >- Prevent add igt_require_sw_sync to subtests using sw_sync > > > Changes since v2: > Rebased on upstream/master > > lib/igt_kms: > - Reset plane->fence_fd to -1 during igt_atomic_prepare_plane_commit() > - Rework out_fencs_ptr to be an int64_t named out_fence > - Add igt_pipe_request_out_fence() > tests/: > - Switch to using igt_pipe_request_out_fence() > - Close out_fence fd > - Change out_fence to int64_t in run_transition_test() > - Added comments noting that two testcases are not invalid > - Added igt_pipe_get_last_out_fence() that wraps pipe->fence_out Looks like this this missing the uabi conversion to s32 (int). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Sanity check the computed size and base of stolen memory
On ma, 2017-01-30 at 13:47 +, Chris Wilson wrote: > Just do a quick check that the stolen memory address range doesn't > overflow our chosen integer type. > > v2: Add add_overflows() to utils with the promise that gcc7 can do this > better than C and then maybe it will have a proper definition in core. > > Signed-off-by: Chris Wilson> Cc: Joonas Lahtinen Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add MIPI_IO WA and program DSI regulators
Gentle remainder - could you kindly check the patch please? Thank you. > -Original Message- > From: Srinivas, Vidya > Sent: Wednesday, January 25, 2017 7:43 PM > To: intel-gfx@lists.freedesktop.org > Cc: Shankar, Uma; Nikula, Jani > ; Syrjala, Ville ; Kahola, > Mika ; Srinivas, Vidya > Subject: [PATCH] drm/i915: Add MIPI_IO WA and program DSI regulators > > From: Uma Shankar > > Enable MIPI IO WA for BXT DSI as per bspec and program the DSI regulators. > > v2: Moved IO enable to pre-enable as per Mika's review comments. Also > reused the existing register definition for BXT_P_CR_GT_DISP_PWRON. > > v3: Added Programming the DSI regulators as per disable/enable sequences. > > v4: Restricting regulator changes to BXT as suggested by Jani/Mika > > v5: Removed redundant read/modify for regulator register as per Jani's > comment. Maintain enable/disable symmetry as per spec. > > Signed-off-by: Uma Shankar > Signed-off-by: Vidya Srinivas > --- > drivers/gpu/drm/i915/i915_reg.h | 7 +++ > drivers/gpu/drm/i915/intel_dsi.c | 24 > 2 files changed, 31 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_reg.h > b/drivers/gpu/drm/i915/i915_reg.h index 00970aa..0a9ad44 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -1553,6 +1553,7 @@ enum skl_disp_power_wells { > _MMIO(_BXT_PHY_CH(phy, ch, reg_ch0, reg_ch1)) > > #define BXT_P_CR_GT_DISP_PWRON _MMIO(0x138090) > +#define MIPIO_RST_CTRL (1 << 2) > > #define _BXT_PHY_CTL_DDI_A 0x64C00 > #define _BXT_PHY_CTL_DDI_B 0x64C10 > @@ -8301,6 +8302,12 @@ enum { > #define _BXT_MIPIC_PORT_CTRL 0x6B8C0 > #define BXT_MIPI_PORT_CTRL(tc) _MMIO_MIPI(tc, > _BXT_MIPIA_PORT_CTRL, _BXT_MIPIC_PORT_CTRL) > > +#define BXT_P_DSI_REGULATOR_CFG _MMIO(0x160020) > +#define STAP_SELECT (1 << 0) > + > +#define BXT_P_DSI_REGULATOR_TX_CTRL _MMIO(0x160054) > +#define HS_IO_CTRL_SELECT (1 << 0) > + > #define DPI_ENABLE (1 << 31) /* A + C */ > #define MIPIA_MIPI4DPHY_DELAY_COUNT_SHIFT 27 > #define MIPIA_MIPI4DPHY_DELAY_COUNT_MASK(0xf << 27) > diff --git a/drivers/gpu/drm/i915/intel_dsi.c > b/drivers/gpu/drm/i915/intel_dsi.c > index 16732e7..c98234e 100644 > --- a/drivers/gpu/drm/i915/intel_dsi.c > +++ b/drivers/gpu/drm/i915/intel_dsi.c > @@ -548,6 +548,7 @@ static void intel_dsi_pre_enable(struct > intel_encoder *encoder, > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev); > struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base); > enum port port; > + u32 val; > > DRM_DEBUG_KMS("\n"); > > @@ -558,6 +559,17 @@ static void intel_dsi_pre_enable(struct > intel_encoder *encoder, > intel_disable_dsi_pll(encoder); > intel_enable_dsi_pll(encoder, pipe_config); > > + if (IS_BROXTON(dev_priv)) { > + /* Add MIPI IO reset programming for modeset */ > + val = I915_READ(BXT_P_CR_GT_DISP_PWRON); > + I915_WRITE(BXT_P_CR_GT_DISP_PWRON, > + val | MIPIO_RST_CTRL); > + > + /* Power up DSI regulator */ > + I915_WRITE(BXT_P_DSI_REGULATOR_CFG, STAP_SELECT); > + I915_WRITE(BXT_P_DSI_REGULATOR_TX_CTRL, 0); > + } > + > intel_dsi_prepare(encoder, pipe_config); > > /* Panel Enable over CRC PMIC */ > @@ -707,6 +719,7 @@ static void intel_dsi_post_disable(struct > intel_encoder *encoder, { > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev); > struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base); > + u32 val; > > DRM_DEBUG_KMS("\n"); > > @@ -714,6 +727,17 @@ static void intel_dsi_post_disable(struct > intel_encoder *encoder, > > intel_dsi_clear_device_ready(encoder); > > + if (IS_BROXTON(dev_priv)) { > + /* Power down DSI regulator to save power */ > + I915_WRITE(BXT_P_DSI_REGULATOR_CFG, STAP_SELECT); > + I915_WRITE(BXT_P_DSI_REGULATOR_TX_CTRL, > HS_IO_CTRL_SELECT); > + > + /* Add MIPI IO reset programming for modeset */ > + val = I915_READ(BXT_P_CR_GT_DISP_PWRON); > + I915_WRITE(BXT_P_CR_GT_DISP_PWRON, > + val & ~MIPIO_RST_CTRL); > + } > + > intel_disable_dsi_pll(encoder); > > if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) { > -- > 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx