[Intel-gfx] ✓ Fi.CI.BAT: success for Adding driver-private objects to atomic state
== Series Details == Series: Adding driver-private objects to atomic state URL : https://patchwork.freedesktop.org/series/23308/ State : success == Summary == Series 23308v1 Adding driver-private objects to atomic state https://patchwork.freedesktop.org/api/1.0/series/23308/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> FAIL (fi-snb-2600) fdo#17 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: fail -> PASS (fi-skl-6700k) fdo#100367 Test pm_rpm: Subgroup basic-rte: incomplete -> PASS (fi-bsw-n3050) fdo#100718 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#100367 https://bugs.freedesktop.org/show_bug.cgi?id=100367 fdo#100718 https://bugs.freedesktop.org/show_bug.cgi?id=100718 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:437s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:427s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:588s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:511s fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 time:542s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:481s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:487s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:414s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:406s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:423s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:492s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:486s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:454s fi-kbl-7560u total:278 pass:267 dwarn:1 dfail:0 fail:0 skip:10 time:568s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:448s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time:568s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:456s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:499s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:428s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:541s fi-snb-2600 total:278 pass:248 dwarn:0 dfail:0 fail:1 skip:29 time:405s 9bb844000d9412c2758b861ce7aee1e9546fccb9 drm-tip: 2017y-04m-20d-14h-46m-59s UTC integration manifest 3347ee1 drm/dp: Track MST link bandwidth 8fef895b4 drm/dp: Add DP MST helpers to atomically find and release vcpi slots 403e426 drm/dp: Introduce MST topology state to track available link bandwidth 4eb3832 drm: Add driver-private objects to atomic state == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4527/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 4/4] drm/dp: Track MST link bandwidth
From: "Pandiyan, Dhinakaran" Use the added helpers to track MST link bandwidth for atomic modesets. Link bw is acquired in the ->atomic_check() phase when CRTCs are being enabled with drm_atomic_find_vcpi_slots() instead of drm_find_vcpi_slots(). Similarly, link bw is released during ->atomic_check() with the connector helper callback ->atomic_release() when CRTCs are disabled. v5: Implement connector->atomic_check() in place of atomic_release() v4: Return an int from intel_dp_mst_atomic_release() (Maarten) v3: Handled the case where ->atomic_release() is called more than once during an atomic_check() for the same state. v2: Squashed atomic_release() implementation and caller (Daniel) Fixed logic for connector-crtc switching case (Daniel) Fixed logic for suspend-resume case. Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Archit Taneja Cc: Chris Wilson Cc: Harry Wentland Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/i915/intel_dp_mst.c | 57 + 1 file changed, 51 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c index 5af22a7..20c557c 100644 --- a/drivers/gpu/drm/i915/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/intel_dp_mst.c @@ -39,9 +39,9 @@ static bool intel_dp_mst_compute_config(struct intel_encoder *encoder, struct intel_dp *intel_dp = &intel_dig_port->dp; struct intel_connector *connector = to_intel_connector(conn_state->connector); - struct drm_atomic_state *state; + struct drm_atomic_state *state = pipe_config->base.state; int bpp; - int lane_count, slots; + int lane_count, slots = 0; const struct drm_display_mode *adjusted_mode = &pipe_config->base.adjusted_mode; int mst_pbn; @@ -63,24 +63,68 @@ static bool intel_dp_mst_compute_config(struct intel_encoder *encoder, pipe_config->pipe_bpp = bpp; pipe_config->port_clock = intel_dp_max_link_rate(intel_dp); - state = pipe_config->base.state; - if (drm_dp_mst_port_has_audio(&intel_dp->mst_mgr, connector->port)) pipe_config->has_audio = true; - mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp); + mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp); pipe_config->pbn = mst_pbn; - slots = drm_dp_find_vcpi_slots(&intel_dp->mst_mgr, mst_pbn); intel_link_compute_m_n(bpp, lane_count, adjusted_mode->crtc_clock, pipe_config->port_clock, &pipe_config->dp_m_n); + if (pipe_config->base.active) { + slots = drm_dp_atomic_find_vcpi_slots(state, &intel_dp->mst_mgr, + connector->port, mst_pbn); + if (slots < 0) { + DRM_DEBUG_KMS("failed finding vcpi slots:%d\n", slots); + return false; + } + } pipe_config->dp_m_n.tu = slots; return true; +} +static inline bool release_resources(struct drm_crtc_state *crtc_state) +{ + return (crtc_state->connectors_changed || + crtc_state->mode_changed || + (crtc_state->active_changed && !crtc_state->active)); +} + +static int intel_dp_mst_atomic_check(struct drm_connector *connector, + struct drm_connector_state *new_conn_state) +{ + struct drm_atomic_state *state = new_conn_state->state; + struct drm_connector_state *old_conn_state; + struct drm_crtc *old_crtc; + struct drm_crtc_state *crtc_state; + int slots, ret = 0; + + old_conn_state = drm_atomic_get_old_connector_state(state, connector); + old_crtc = old_conn_state->crtc; + if (!old_crtc) + return 0; + + crtc_state = drm_atomic_get_new_crtc_state(state, old_crtc); + slots = to_intel_crtc_state(crtc_state)->dp_m_n.tu; + + if (release_resources(crtc_state) && slots > 0) { + struct drm_dp_mst_topology_mgr *mgr; + struct drm_encoder *old_encoder; + + old_encoder = old_conn_state->best_encoder; + mgr = &enc_to_mst(old_encoder)->primary->dp.mst_mgr; + + ret = drm_dp_atomic_release_vcpi_slots(state, mgr, slots); + if (ret) + DRM_DEBUG_KMS("failed releasing %d vcpi slots:%d\n", slots, ret); + else + to_intel_crtc_state(crtc_state)->dp_m_n.tu = 0; + } + return ret; } static void intel_mst_disable_dp(struct intel_encoder *encoder, @@ -378,6 +422,7 @@ static const struct drm_connector_helper_funcs intel_dp_mst_connector_helper_fun .mode_valid = intel_dp_mst_mode_valid, .atomic_best_encoder = intel_mst_atomic_best_encoder, .best_encoder = intel_mst_best_encoder, + .atomic_check = intel_dp_mst_atomic_check, }; stat
[Intel-gfx] [PATCH v7 1/4] drm: Add driver-private objects to atomic state
From: "Pandiyan, Dhinakaran" It is necessary to track states for objects other than connector, crtc and plane for atomic modesets. But adding objects like DP MST link bandwidth to drm_atomic_state would mean that a non-core object will be modified by the core helper functions for swapping and clearing it's state. So, lets add void * objects and helper functions that operate on void * types to keep these objects and states private to the core. Drivers can then implement specific functions to swap and clear states. The other advantage having just void * for these objects in drm_atomic_state is that objects of different types can be managed in the same state array. v6: More kernel-doc to keep 0-day happy v5: Remove more NULL checks (Maarten) v4: Avoid redundant NULL checks when private_objs array is empty (Maarten) v3: Macro alignment (Chris) v2: Added docs and new iterator to filter private objects (Daniel) Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Archit Taneja Cc: Chris Wilson Cc: Harry Wentland Acked-by: Harry Wentland Suggested-by: Daniel Vetter Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/drm_atomic.c| 65 +++ drivers/gpu/drm/drm_atomic_helper.c | 5 ++ include/drm/drm_atomic.h| 101 3 files changed, 171 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 30229ab..8e5f3eb 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -57,6 +57,7 @@ void drm_atomic_state_default_release(struct drm_atomic_state *state) kfree(state->connectors); kfree(state->crtcs); kfree(state->planes); + kfree(state->private_objs); } EXPORT_SYMBOL(drm_atomic_state_default_release); @@ -184,6 +185,17 @@ void drm_atomic_state_default_clear(struct drm_atomic_state *state) state->planes[i].ptr = NULL; state->planes[i].state = NULL; } + + for (i = 0; i < state->num_private_objs; i++) { + void *obj_state = state->private_objs[i].obj_state; + + state->private_objs[i].funcs->destroy_state(obj_state); + state->private_objs[i].obj = NULL; + state->private_objs[i].obj_state = NULL; + state->private_objs[i].funcs = NULL; + } + state->num_private_objs = 0; + } EXPORT_SYMBOL(drm_atomic_state_default_clear); @@ -978,6 +990,59 @@ static void drm_atomic_plane_print_state(struct drm_printer *p, } /** + * drm_atomic_get_private_obj_state - get private object state + * @state: global atomic state + * @obj: private object to get the state for + * @funcs: pointer to the struct of function pointers that identify the object + * type + * + * This function returns the private object state for the given private object, + * allocating the state if needed. It does not grab any locks as the caller is + * expected to care of any required locking. + * + * RETURNS: + * + * Either the allocated state or the error code encoded into a pointer. + */ +void * +drm_atomic_get_private_obj_state(struct drm_atomic_state *state, void *obj, + const struct drm_private_state_funcs *funcs) +{ + int index, num_objs, i; + size_t size; + struct __drm_private_objs_state *arr; + + for (i = 0; i < state->num_private_objs; i++) + if (obj == state->private_objs[i].obj && + state->private_objs[i].obj_state) + return state->private_objs[i].obj_state; + + num_objs = state->num_private_objs + 1; + size = sizeof(*state->private_objs) * num_objs; + arr = krealloc(state->private_objs, size, GFP_KERNEL); + if (!arr) + return ERR_PTR(-ENOMEM); + + state->private_objs = arr; + index = state->num_private_objs; + memset(&state->private_objs[index], 0, sizeof(*state->private_objs)); + + state->private_objs[index].obj_state = funcs->duplicate_state(state, obj); + if (!state->private_objs[index].obj_state) + return ERR_PTR(-ENOMEM); + + state->private_objs[index].obj = obj; + state->private_objs[index].funcs = funcs; + state->num_private_objs = num_objs; + + DRM_DEBUG_ATOMIC("Added new private object state %p to %p\n", +state->private_objs[index].obj_state, state); + + return state->private_objs[index].obj_state; +} +EXPORT_SYMBOL(drm_atomic_get_private_obj_state); + +/** * drm_atomic_get_connector_state - get connector state * @state: global atomic state object * @connector: connector to get state object for diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index cfeda5f..cce05fb 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -2032,6 +2032,8 @@ void drm_atomic_helper_swap_state(struct drm_atomic_state *state, struct drm_p
[Intel-gfx] [PATCH v7 3/4] drm/dp: Add DP MST helpers to atomically find and release vcpi slots
From: "Pandiyan, Dhinakaran" drm_dp_atomic_find_vcpi_slots() should be called from ->atomic_check() to check there are sufficient vcpi slots for a mode and to add that to the state. This should be followed by a call to drm_dp_mst_allocate_vcpi() in ->atomic_commit() to initialize a struct vcpi for the port. drm_dp_atomic_release_vcpi_slots() should be called from ->atomic_check() to release a port's vcpi slot allocation from the state. Drivers that do not make use of this atomic helper are expected to call drm_dp_find_vcpi_slots() instead before calling drm_dp_mst_allocate_vcpi(). v3: drm_dp_atomic_release_vcpi_slots() now needs to know how many slots to release as we may not have a valid reference to port. v2: Added checks for verifying the port reference is valid Moved get_mst_topology_state() into the helpers (Daniel) Changed find_vcpi_slots() to not depend on current allocation Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Archit Taneja Cc: Chris Wilson Cc: Harry Wentland Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/drm_dp_mst_topology.c | 75 +++ include/drm/drm_dp_mst_helper.h | 6 +++ 2 files changed, 81 insertions(+) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index 0ad0baa..d1cbb9c 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -2498,6 +2498,81 @@ static int drm_dp_init_vcpi(struct drm_dp_mst_topology_mgr *mgr, } /** + * drm_dp_atomic_find_vcpi_slots() - Find and add vcpi slots to the state + * @state: global atomic state + * @mgr: MST topology manager for the port + * @port: port to find vcpi slots for + * @pbn: bandwidth required for the mode in PBN + * + * RETURNS: + * Total slots in the atomic state assigned for this port or error + */ +int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state *state, + struct drm_dp_mst_topology_mgr *mgr, + struct drm_dp_mst_port *port, int pbn) +{ + struct drm_dp_mst_topology_state *topology_state; + int req_slots; + + topology_state = drm_atomic_get_mst_topology_state(state, mgr); + if (topology_state == NULL) + return -ENOMEM; + + port = drm_dp_get_validated_port_ref(mgr, port); + if (port == NULL) + return -EINVAL; + req_slots = DIV_ROUND_UP(pbn, mgr->pbn_div); + DRM_DEBUG_KMS("vcpi slots req=%d, avail=%d\n", + req_slots, topology_state->avail_slots); + + if (req_slots > topology_state->avail_slots) { + drm_dp_put_port(port); + return -ENOSPC; + } + + topology_state->avail_slots -= req_slots; + DRM_DEBUG_KMS("vcpi slots avail=%d", topology_state->avail_slots); + + drm_dp_put_port(port); + return req_slots; +} +EXPORT_SYMBOL(drm_dp_atomic_find_vcpi_slots); + +/** + * drm_dp_atomic_release_vcpi_slots() - Release allocated vcpi slots + * @state: global atomic state + * @mgr: MST topology manager for the port + * @slots: number of vcpi slots to release + * + * RETURNS: + * 0 if @slots were added back to &drm_dp_mst_topology_state->avail_slots or + * negative error code + */ +int drm_dp_atomic_release_vcpi_slots(struct drm_atomic_state *state, +struct drm_dp_mst_topology_mgr *mgr, +int slots) +{ + struct drm_dp_mst_topology_state *topology_state; + + topology_state = drm_atomic_get_mst_topology_state(state, mgr); + if (topology_state == NULL) + return -ENOMEM; + + /* We cannot rely on port->vcpi.num_slots to update +* topology_state->avail_slots as the port may not exist if the parent +* branch device was unplugged. This should be fixed by tracking +* per-port slot allocation in drm_dp_mst_topology_state instead of +* depending on the caller to tell us how many slots to release. +*/ + topology_state->avail_slots += slots; + DRM_DEBUG_KMS("vcpi slots released=%d, avail=%d\n", + slots, topology_state->avail_slots); + + return 0; +} +EXPORT_SYMBOL(drm_dp_atomic_release_vcpi_slots); + +/** * drm_dp_mst_allocate_vcpi() - Allocate a virtual channel * @mgr: manager for this port * @port: port to allocate a virtual channel for. diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h index 0b371df..177ab6f 100644 --- a/include/drm/drm_dp_mst_helper.h +++ b/include/drm/drm_dp_mst_helper.h @@ -615,5 +615,11 @@ void drm_dp_mst_topology_mgr_suspend(struct drm_dp_mst_topology_mgr *mgr); int drm_dp_mst_topology_mgr_resume(struct drm_dp_mst_topology_mgr *mgr); struct drm_dp_mst_topology_state *drm_atomic_get_mst_topology_state(struct drm_atomic_state *state, struct drm_dp_mst_topology_mgr *mgr); +int d
[Intel-gfx] [PATCH v7 0/4] Adding driver-private objects to atomic state
Changes in this version: Used connector->atomic_check() to release vcpi slots instead of the atomic_release() callback. This series introduces void * type driver-private objects in core and adds helper functions that operate on these private objects. Drivers need to implement object-specific functions to swap and clear object states. The advantage of having void * for these objects in the core is objects of different types can be managed in the same atomic state array. The series implements DP-MST link bw tracking using the driver-private object infrastructure. Pandiyan, Dhinakaran (4): drm: Add driver-private objects to atomic state drm/dp: Introduce MST topology state to track available link bandwidth drm/dp: Add DP MST helpers to atomically find and release vcpi slots drm/dp: Track MST link bandwidth drivers/gpu/drm/drm_atomic.c | 65 +++ drivers/gpu/drm/drm_atomic_helper.c | 5 ++ drivers/gpu/drm/drm_dp_mst_topology.c | 150 ++ drivers/gpu/drm/i915/intel_dp_mst.c | 57 +++-- include/drm/drm_atomic.h | 101 +++ include/drm/drm_dp_mst_helper.h | 26 ++ 6 files changed, 398 insertions(+), 6 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 2/4] drm/dp: Introduce MST topology state to track available link bandwidth
From: "Pandiyan, Dhinakaran" Link bandwidth is shared between multiple display streams in DP MST configurations. The DP MST topology manager structure maintains the shared link bandwidth for a primary link directly connected to the GPU. For atomic modesetting drivers, checking if there is sufficient link bandwidth for a mode needs to be done during the atomic_check phase to avoid failed modesets. Let's encapsulate the available link bw information in a private state structure so that bw can be allocated and released atomically for each of the ports sharing the primary link. v3: WARN_ON() if connection_mutex is not held (Archit) v2: Included kernel doc, moved state initialization and switched to kmemdup() for allocation (Daniel) Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Archit Taneja Cc: Chris Wilson Cc: Harry Wentland Reviewed-by: Maarten Lankhorst Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/drm_dp_mst_topology.c | 75 +++ include/drm/drm_dp_mst_helper.h | 20 ++ 2 files changed, 95 insertions(+) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index d3fc7e4..0ad0baa 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -2936,6 +2936,69 @@ static void drm_dp_destroy_connector_work(struct work_struct *work) (*mgr->cbs->hotplug)(mgr); } +void *drm_dp_mst_duplicate_state(struct drm_atomic_state *state, void *obj) +{ + struct drm_dp_mst_topology_mgr *mgr = obj; + struct drm_dp_mst_topology_state *new_mst_state; + + if (WARN_ON(!mgr->state)) + return NULL; + + new_mst_state = kmemdup(mgr->state, sizeof(*new_mst_state), GFP_KERNEL); + if (new_mst_state) + new_mst_state->state = state; + return new_mst_state; +} + +void drm_dp_mst_swap_state(void *obj, void **obj_state_ptr) +{ + struct drm_dp_mst_topology_mgr *mgr = obj; + struct drm_dp_mst_topology_state **topology_state_ptr; + + topology_state_ptr = (struct drm_dp_mst_topology_state **)obj_state_ptr; + + mgr->state->state = (*topology_state_ptr)->state; + swap(*topology_state_ptr, mgr->state); + mgr->state->state = NULL; +} + +void drm_dp_mst_destroy_state(void *obj_state) +{ + kfree(obj_state); +} + +static const struct drm_private_state_funcs mst_state_funcs = { + .duplicate_state = drm_dp_mst_duplicate_state, + .swap_state = drm_dp_mst_swap_state, + .destroy_state = drm_dp_mst_destroy_state, +}; + +/** + * drm_atomic_get_mst_topology_state: get MST topology state + * + * @state: global atomic state + * @mgr: MST topology manager, also the private object in this case + * + * This function wraps drm_atomic_get_priv_obj_state() passing in the MST atomic + * state vtable so that the private object state returned is that of a MST + * topology object. Also, drm_atomic_get_private_obj_state() expects the caller + * to care of the locking, so warn if don't hold the connection_mutex. + * + * RETURNS: + * + * The MST topology state or error pointer. + */ +struct drm_dp_mst_topology_state *drm_atomic_get_mst_topology_state(struct drm_atomic_state *state, + struct drm_dp_mst_topology_mgr *mgr) +{ + struct drm_device *dev = mgr->dev; + + WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex)); + return drm_atomic_get_private_obj_state(state, mgr, + &mst_state_funcs); +} +EXPORT_SYMBOL(drm_atomic_get_mst_topology_state); + /** * drm_dp_mst_topology_mgr_init - initialise a topology manager * @mgr: manager struct to initialise @@ -2980,6 +3043,15 @@ int drm_dp_mst_topology_mgr_init(struct drm_dp_mst_topology_mgr *mgr, if (test_calc_pbn_mode() < 0) DRM_ERROR("MST PBN self-test failed\n"); + mgr->state = kzalloc(sizeof(*mgr->state), GFP_KERNEL); + if (mgr->state == NULL) + return -ENOMEM; + mgr->state->mgr = mgr; + + /* max. time slots - one slot for MTP header */ + mgr->state->avail_slots = 63; + mgr->funcs = &mst_state_funcs; + return 0; } EXPORT_SYMBOL(drm_dp_mst_topology_mgr_init); @@ -3000,6 +3072,9 @@ void drm_dp_mst_topology_mgr_destroy(struct drm_dp_mst_topology_mgr *mgr) mutex_unlock(&mgr->payload_lock); mgr->dev = NULL; mgr->aux = NULL; + kfree(mgr->state); + mgr->state = NULL; + mgr->funcs = NULL; } EXPORT_SYMBOL(drm_dp_mst_topology_mgr_destroy); diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h index 5b02476..0b371df 100644 --- a/include/drm/drm_dp_mst_helper.h +++ b/include/drm/drm_dp_mst_helper.h @@ -24,6 +24,7 @@ #include #include +#include struct drm_dp_mst_branch; @@ -403,6 +404,12 @@ struct drm_dp_payload { int vcpi; }; +struct drm
Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree
Thanks Stephen. Looks good to me. Logan On 20/04/17 08:10 PM, Stephen Rothwell wrote: > Hi all, > > After merging the drm-misc tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > drivers/tee/tee_shm.c:87:2: error: unknown field 'kmap_atomic' specified in > initializer > .kmap_atomic = tee_shm_op_kmap_atomic, > ^ > drivers/tee/tee_shm.c:87:17: error: initialization from incompatible pointer > type [-Werror=incompatible-pointer-types] > .kmap_atomic = tee_shm_op_kmap_atomic, > ^ > drivers/tee/tee_shm.c:87:17: note: (near initialization for > 'tee_shm_dma_buf_ops.begin_cpu_access') > drivers/tee/tee_shm.c:88:2: error: unknown field 'kmap' specified in > initializer > .kmap = tee_shm_op_kmap, > ^ > drivers/tee/tee_shm.c:88:10: error: initialization from incompatible pointer > type [-Werror=incompatible-pointer-types] > .kmap = tee_shm_op_kmap, > ^ > drivers/tee/tee_shm.c:88:10: note: (near initialization for > 'tee_shm_dma_buf_ops.end_cpu_access') > > Caused by commit > > f9b67f0014cb ("dma-buf: Rename dma-ops to prevent conflict with > kunmap_atomic macro") > > interacting with commit > > 967c9cca2cc5 ("tee: generic TEE subsystem") > > from the arm-soc tree. > > I applied the following merge fix patch for today: > > From: Stephen Rothwell > Date: Fri, 21 Apr 2017 12:06:32 +1000 > Subject: [PATCH] tee: merge fix for dma-ops field name changes > > Signed-off-by: Stephen Rothwell > --- > drivers/tee/tee_shm.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c > index 0be1e3e93bee..4e14c9c9cb1c 100644 > --- a/drivers/tee/tee_shm.c > +++ b/drivers/tee/tee_shm.c > @@ -84,8 +84,8 @@ static struct dma_buf_ops tee_shm_dma_buf_ops = { > .map_dma_buf = tee_shm_op_map_dma_buf, > .unmap_dma_buf = tee_shm_op_unmap_dma_buf, > .release = tee_shm_op_release, > - .kmap_atomic = tee_shm_op_kmap_atomic, > - .kmap = tee_shm_op_kmap, > + .map_atomic = tee_shm_op_kmap_atomic, > + .map = tee_shm_op_kmap, > .mmap = tee_shm_op_mmap, > }; > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: build failure after merge of the drm-misc tree
Hi all, After merging the drm-misc tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/tee/tee_shm.c:87:2: error: unknown field 'kmap_atomic' specified in initializer .kmap_atomic = tee_shm_op_kmap_atomic, ^ drivers/tee/tee_shm.c:87:17: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] .kmap_atomic = tee_shm_op_kmap_atomic, ^ drivers/tee/tee_shm.c:87:17: note: (near initialization for 'tee_shm_dma_buf_ops.begin_cpu_access') drivers/tee/tee_shm.c:88:2: error: unknown field 'kmap' specified in initializer .kmap = tee_shm_op_kmap, ^ drivers/tee/tee_shm.c:88:10: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] .kmap = tee_shm_op_kmap, ^ drivers/tee/tee_shm.c:88:10: note: (near initialization for 'tee_shm_dma_buf_ops.end_cpu_access') Caused by commit f9b67f0014cb ("dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro") interacting with commit 967c9cca2cc5 ("tee: generic TEE subsystem") from the arm-soc tree. I applied the following merge fix patch for today: From: Stephen Rothwell Date: Fri, 21 Apr 2017 12:06:32 +1000 Subject: [PATCH] tee: merge fix for dma-ops field name changes Signed-off-by: Stephen Rothwell --- drivers/tee/tee_shm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c index 0be1e3e93bee..4e14c9c9cb1c 100644 --- a/drivers/tee/tee_shm.c +++ b/drivers/tee/tee_shm.c @@ -84,8 +84,8 @@ static struct dma_buf_ops tee_shm_dma_buf_ops = { .map_dma_buf = tee_shm_op_map_dma_buf, .unmap_dma_buf = tee_shm_op_unmap_dma_buf, .release = tee_shm_op_release, - .kmap_atomic = tee_shm_op_kmap_atomic, - .kmap = tee_shm_op_kmap, + .map_atomic = tee_shm_op_kmap_atomic, + .map = tee_shm_op_kmap, .mmap = tee_shm_op_mmap, }; -- 2.11.0 -- Cheers, Stephen Rothwell ___ 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: Don't try detecting sinks on ports already in use
== Series Details == Series: drm: i915: Don't try detecting sinks on ports already in use URL : https://patchwork.freedesktop.org/series/23299/ State : success == Summary == Series 23299v1 drm: i915: Don't try detecting sinks on ports already in use https://patchwork.freedesktop.org/api/1.0/series/23299/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: fail -> PASS (fi-skl-6700k) fdo#100367 Test pm_rpm: Subgroup basic-rte: incomplete -> PASS (fi-bsw-n3050) fdo#100718 fdo#100367 https://bugs.freedesktop.org/show_bug.cgi?id=100367 fdo#100718 https://bugs.freedesktop.org/show_bug.cgi?id=100718 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:422s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:430s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:567s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:509s fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 time:554s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:470s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:470s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:409s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:404s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:421s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:482s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:471s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:460s fi-kbl-7560u total:278 pass:267 dwarn:1 dfail:0 fail:0 skip:10 time:569s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:453s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time:574s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:465s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:481s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:428s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:521s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:400s 9bb844000d9412c2758b861ce7aee1e9546fccb9 drm-tip: 2017y-04m-20d-14h-46m-59s UTC integration manifest 5e41558 drm: i915: Don't try detecting sinks on ports already in use == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4526/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH RFC] drm: i915: Don't try detecting sinks on ports already in use
On systems where more than one connector is attached to the same port, the HPD pin is also shared, and attaching one connector will trigger a hotplug on every other connector on that port. But, according to the documentation, connectors sharing the port cannot be enabled simultaneously, such that we can abort the detection process early if another connector was detected succesfully. This has the good side effect of preventing DP timeouts whenever something else is connected to the shared port, like below: [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f [drm:drm_dp_dpcd_access] Too many retries, giving up. First error: -110 Since this reduces the overhead of the i915_hotplug_work_func, it may address the following vblank misses detected by the CI: https://bugs.freedesktop.org/show_bug.cgi?id=100215 https://bugs.freedesktop.org/show_bug.cgi?id=100558 Signed-off-by: Gabriel Krisman Bertazi --- drivers/gpu/drm/i915/intel_display.c | 26 ++ drivers/gpu/drm/i915/intel_dp.c | 3 +++ drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_hdmi.c| 3 +++ 4 files changed, 33 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 85b9e2f521a0..618b5138c0c7 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -11270,6 +11270,32 @@ static bool check_digital_port_conflicts(struct drm_atomic_state *state) return true; } +bool intel_shared_digital_port_in_use(struct drm_connector *conn) +{ + struct drm_connector *peer; + struct drm_connector_list_iter iter; + struct intel_encoder *enc = to_intel_connector(conn)->encoder; + int ret = false; + + drm_connector_list_iter_begin(conn->dev, &iter); + drm_for_each_connector_iter(peer, &iter) { + struct intel_encoder *peer_enc; + + if (peer == conn || + peer->status != connector_status_connected) + continue; + + peer_enc = to_intel_connector(peer)->encoder; + if (peer_enc->port == enc->port) { + ret = true; + break; + } + } + drm_connector_list_iter_end(&iter); + + return ret; +} + static void clear_intel_crtc_state(struct intel_crtc_state *crtc_state) { diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 08834f74d396..0823c588575f 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -4628,6 +4628,9 @@ intel_dp_long_pulse(struct intel_connector *intel_connector) WARN_ON(!drm_modeset_is_locked(&connector->dev->mode_config.connection_mutex)); + if (intel_shared_digital_port_in_use(connector)) + return connector_status_disconnected; + intel_display_power_get(to_i915(dev), intel_dp->aux_power_domain); /* Can't disconnect eDP, but you can close the lid... */ diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 54f3ff840812..fd5f2517bede 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -1411,6 +1411,7 @@ int vlv_force_pll_on(struct drm_i915_private *dev_priv, enum pipe pipe, const struct dpll *dpll); void vlv_force_pll_off(struct drm_i915_private *dev_priv, enum pipe pipe); int lpt_get_iclkip(struct drm_i915_private *dev_priv); +bool intel_shared_digital_port_in_use(struct drm_connector *conn); /* modesetting asserts */ void assert_panel_unlocked(struct drm_i915_private *dev_priv, diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 6efc3cb8c471..ed4015ae7d24 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -1527,6 +1527,9 @@ intel_hdmi_detect(struct drm_connector *connector, bool force) DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id, connector->name); + if (intel_shared_digital_port_in_use(connector)) + return connector_status_disconnected;; + intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS); intel_hdmi_unset_edid(connector); -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 05/20] drm/i915/tdr: Add support for per engine reset recovery
On 19/04/17 03:49, Chris Wilson wrote: On Tue, Apr 18, 2017 at 01:23:20PM -0700, Michel Thierry wrote: From: Arun Siluvery This change implements support for per-engine reset as an initial, less intrusive hang recovery option to be attempted before falling back to the legacy full GPU reset recovery mode if necessary. This is only supported from Gen8 onwards. Hangchecker determines which engines are hung and invokes error handler to recover from it. Error handler schedules recovery for each of those engines that are hung. The recovery procedure is as follows, - identifies the request that caused the hang and it is dropped - force engine to idle: this is done by issuing a reset request - reset and re-init engine - restart submissions to the engine If engine reset fails then we fall back to heavy weight full gpu reset which resets all engines and reinitiazes complete state of HW and SW. v2: Rebase. v3: s/*engine_reset*/*reset_engine*/; freeze engine and irqs before calling i915_gem_reset_engine (Chris). v4: Rebase, modify i915_gem_reset_prepare to use a ring mask and reuse the function for reset_engine. v5: intel_reset_engine_start/cancel instead of request/unrequest_reset. v6: Clean up reset_engine function to not require mutex, i.e. no need to call revoke/restore_fences and _retire_requests (Chris). Cc: Chris Wilson Cc: Mika Kuoppala Signed-off-by: Tomas Elf Signed-off-by: Arun Siluvery Signed-off-by: Michel Thierry --- drivers/gpu/drm/i915/i915_drv.c | 76 -- drivers/gpu/drm/i915/i915_drv.h | 12 +++- drivers/gpu/drm/i915/i915_gem.c | 97 +++-- drivers/gpu/drm/i915/i915_gem_request.c | 2 +- drivers/gpu/drm/i915/intel_uncore.c | 20 +++ 5 files changed, 158 insertions(+), 49 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index e03d0643dbd6..634893cd93b3 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1810,7 +1810,7 @@ void i915_reset(struct drm_i915_private *dev_priv) pr_notice("drm/i915: Resetting chip after gpu hang\n"); disable_irq(dev_priv->drm.irq); - ret = i915_gem_reset_prepare(dev_priv); + ret = i915_gem_reset_prepare(dev_priv, ALL_ENGINES); if (ret) { DRM_ERROR("GPU recovery failed\n"); intel_gpu_reset(dev_priv, ALL_ENGINES); @@ -1852,7 +1852,7 @@ void i915_reset(struct drm_i915_private *dev_priv) i915_queue_hangcheck(dev_priv); finish: - i915_gem_reset_finish(dev_priv); + i915_gem_reset_finish(dev_priv, ALL_ENGINES); enable_irq(dev_priv->drm.irq); wakeup: @@ -1871,11 +1871,79 @@ void i915_reset(struct drm_i915_private *dev_priv) * * Reset a specific GPU engine. Useful if a hang is detected. * Returns zero on successful reset or otherwise an error code. + * + * Procedure is: + * - identifies the request that caused the hang and it is dropped + * - force engine to idle: this is done by issuing a reset request + * - reset engine + * - restart submissions to the engine */ int i915_reset_engine(struct intel_engine_cs *engine) { - /* FIXME: replace me with engine reset sequence */ - return -ENODEV; + int ret; + struct drm_i915_private *dev_priv = engine->i915; + struct i915_gpu_error *error = &dev_priv->gpu_error; + + GEM_BUG_ON(!test_bit(I915_RESET_BACKOFF, &error->flags)); + + DRM_DEBUG_DRIVER("resetting %s\n", engine->name); + + /* +* We need to first idle the engine by issuing a reset request, +* then perform soft reset and re-initialize hw state, for all of +* this GT power need to be awake so ensure it does throughout the +* process +*/ + intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL); Hmm, what path did we take to get here without taking rpm? I thought I had fixed the last offender. Too many rebases... As you say, this is no longer needed after 1604a86d08053 "drm/i915: Extend rpm wakelock during i915_handle_error()" + disable_irq(dev_priv->drm.irq); I am 99% certain that we don't need to disable_irq() now for per-engine reset... I'd keep it in the global reset as simple paranoia. 100% correct. + ret = i915_gem_reset_prepare_engine(engine); + if (ret) { + DRM_ERROR("Previous reset failed - promote to full reset\n"); + goto error; + } + + /* +* the request that caused the hang is stuck on elsp, identify the +* active request and drop it, adjust head to skip the offending +* request to resume executing remaining requests in the queue. +*/ Hmm. Interesting. This relies on i915_gem_retire_requests() (i.e. struct_mutex) to skip replaying innocent requests, but here we should be asserting that we do have the hung request. i.e. request = i915_gem_find_active_request(engine); if (!request) goto
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix pipe/transcoder enum mismatches
== Series Details == Series: drm/i915: Fix pipe/transcoder enum mismatches URL : https://patchwork.freedesktop.org/series/23296/ State : success == Summary == Series 23296v1 drm/i915: Fix pipe/transcoder enum mismatches https://patchwork.freedesktop.org/api/1.0/series/23296/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> FAIL (fi-snb-2600) fdo#17 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: fail -> PASS (fi-skl-6700k) fdo#100367 Test pm_rpm: Subgroup basic-rte: incomplete -> PASS (fi-bsw-n3050) fdo#100718 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#100367 https://bugs.freedesktop.org/show_bug.cgi?id=100367 fdo#100718 https://bugs.freedesktop.org/show_bug.cgi?id=100718 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:436s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:425s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:581s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:507s fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 time:545s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:487s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:494s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:408s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:405s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:429s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:498s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:479s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:460s fi-kbl-7560u total:278 pass:267 dwarn:1 dfail:0 fail:0 skip:10 time:571s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:449s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time:574s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:461s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:486s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:430s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:534s fi-snb-2600 total:278 pass:248 dwarn:0 dfail:0 fail:1 skip:29 time:403s 9bb844000d9412c2758b861ce7aee1e9546fccb9 drm-tip: 2017y-04m-20d-14h-46m-59s UTC integration manifest 0c17701 drm/i915: Fix pipe/transcoder enum mismatches == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4525/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches
In several instances the driver passes an 'enum pipe' value to a function expecting an 'enum transcoder' and viceversa. Since PIPE_x and TRANSCODER_x have the same values this doesn't cause functional problems. Still it is incorrect and causes clang to generate warnings like this: drivers/gpu/drm/i915/intel_display.c:1844:34: warning: implicit conversion from enumeration type 'enum transcoder' to different enumeration type 'enum pipe' [-Wenum-conversion] assert_fdi_rx_enabled(dev_priv, TRANSCODER_A); Change the code to pass values of the type expected by the callee. Signed-off-by: Matthias Kaehlcke --- drivers/gpu/drm/i915/intel_display.c | 4 ++-- drivers/gpu/drm/i915/intel_dp.c | 6 -- drivers/gpu/drm/i915/intel_hdmi.c| 6 -- drivers/gpu/drm/i915/intel_sdvo.c| 6 -- 4 files changed, 14 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index ed1f4f272b4f..23484f042fae 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1841,7 +1841,7 @@ static void lpt_enable_pch_transcoder(struct drm_i915_private *dev_priv, /* FDI must be feeding us bits for PCH ports */ assert_fdi_tx_enabled(dev_priv, (enum pipe) cpu_transcoder); - assert_fdi_rx_enabled(dev_priv, TRANSCODER_A); + assert_fdi_rx_enabled(dev_priv, PIPE_A); /* Workaround: set timing override bit. */ val = I915_READ(TRANS_CHICKEN2(PIPE_A)); @@ -4607,7 +4607,7 @@ static void lpt_pch_enable(struct drm_crtc *crtc) struct intel_crtc *intel_crtc = to_intel_crtc(crtc); enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder; - assert_pch_transcoder_disabled(dev_priv, TRANSCODER_A); + assert_pch_transcoder_disabled(dev_priv, PIPE_A); lpt_program_iclkip(crtc); diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index d1670b8afbf5..454c2d3dfdd6 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -3568,7 +3568,8 @@ intel_dp_link_down(struct intel_dp *intel_dp) * doing the workaround. Sweep them under the rug. */ intel_set_cpu_fifo_underrun_reporting(dev_priv, PIPE_A, false); - intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, false); + intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A, + false); /* always enable with pattern 1 (as per spec) */ DP &= ~(DP_PIPEB_SELECT | DP_LINK_TRAIN_MASK); @@ -3582,7 +3583,8 @@ intel_dp_link_down(struct intel_dp *intel_dp) intel_wait_for_vblank_if_active(dev_priv, PIPE_A); intel_set_cpu_fifo_underrun_reporting(dev_priv, PIPE_A, true); - intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, true); + intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A, + true); } msleep(intel_dp->panel_power_down_delay); diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 24b2fa5b6282..48b1f5d37204 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -1153,7 +1153,8 @@ static void intel_disable_hdmi(struct intel_encoder *encoder, * doing the workaround. Sweep them under the rug. */ intel_set_cpu_fifo_underrun_reporting(dev_priv, PIPE_A, false); - intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, false); + intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A, + false); temp &= ~SDVO_PIPE_B_SELECT; temp |= SDVO_ENABLE; @@ -1172,7 +1173,8 @@ static void intel_disable_hdmi(struct intel_encoder *encoder, intel_wait_for_vblank_if_active(dev_priv, PIPE_A); intel_set_cpu_fifo_underrun_reporting(dev_priv, PIPE_A, true); - intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, true); + intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A, + true); } intel_hdmi->set_infoframes(&encoder->base, false, old_crtc_state, old_conn_state); diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo.c index 2ad13903a054..0568a9950f7f 100644 --- a/drivers/gpu/drm/i915/intel_sdvo.c +++ b/drivers/gpu/drm/i915/intel_sdvo.c @@ -1462,7 +1462,8 @@ static void intel_disable_sdvo(struct intel_encoder *encoder, * doing the workaround. Sweep them under the rug. */ intel_set_cpu_fifo_underrun_reporting(dev_priv, PIPE_A, false); - intel_set_pch_fifo_underrun_reporting(dev_priv, PIP
Re: [Intel-gfx] [PULL] drm-misc-next-fixes
On Thu, Apr 20, 2017 at 10:11 PM, Sean Paul wrote: > Hi Dave, > A few fixes for you to pick up. The driver changes are trivial, and the > maintainer change was necessitated by the sti fix. The headliner here is the > dma_buf_ops rename, since it touches so many drivers. Everything looks sane > and > builds with that change, so it shouldn't cause problems. > > > drm-misc-next-fixes-2017-04-20: > > Core changes: > - Maintain sti via drm-misc (Vincent) > - Rename dma_buf_ops->kmap_* to avoid naming collision (Logan) This one touches v4l and ion and is acked by the corresponding maintainers (but Sumit forgot to record that when applying the patch, and Sean didn't highlight it in the summary). Sean, should we augment the template that cross-subsystem stuff (outside of what's on-topic for drm-misc) needs to be highlighted specifically in the pull summary? Off for vacation for real now. Cheers, Daniel > > Driver changes: > - Fix UHD displays on stih407 (Vincent) > - Fix uninitialized var return in atmel-hlcdc (Dan) > > Take care, Sean > > > The following changes since commit 8cb68c83ab99a474ae847602f0c514d0fe17cc82: > > drm: Fix get_property logic fumble (2017-04-12 18:11:32 +0200) > > are available in the git repository at: > > git://anongit.freedesktop.org/git/drm-misc > tags/drm-misc-next-fixes-2017-04-20 > > for you to fetch changes up to f9b67f0014cba18f1aabb6fa9272335a043eb6fd: > > dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro > (2017-04-20 13:47:46 +0530) > > > drm-misc-next-fixes-2017-04-20 > > Core changes: > - Maintain sti via drm-misc (Vincent) > - Rename dma_buf_ops->kmap_* to avoid naming collision (Logan) > > Driver changes: > - Fix UHD displays on stih407 (Vincent) > - Fix uninitialized var return in atmel-hlcdc (Dan) > > > Dan Carpenter (1): > drm: atmel-hlcdc: Uninitialized return in atmel_hlcdc_create_outputs() > > Logan Gunthorpe (1): > dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro > > Vincent Abriou (2): > MAINTAINERS: add drm/sti driver into drm-misc > drm/sti: fix GDP size to support up to UHD resolution > > MAINTAINERS | 2 +- > drivers/dma-buf/dma-buf.c| 16 > drivers/gpu/drm/armada/armada_gem.c | 8 > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 5 ++--- > drivers/gpu/drm/drm_prime.c | 8 > drivers/gpu/drm/i915/i915_gem_dmabuf.c | 8 > drivers/gpu/drm/i915/selftests/mock_dmabuf.c | 8 > drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c| 8 > drivers/gpu/drm/sti/sti_gdp.c| 12 +++- > drivers/gpu/drm/tegra/gem.c | 8 > drivers/gpu/drm/udl/udl_dmabuf.c | 8 > drivers/gpu/drm/vmwgfx/vmwgfx_prime.c| 8 > drivers/media/v4l2-core/videobuf2-dma-contig.c | 4 ++-- > drivers/media/v4l2-core/videobuf2-dma-sg.c | 4 ++-- > drivers/media/v4l2-core/videobuf2-vmalloc.c | 4 ++-- > drivers/staging/android/ion/ion.c| 8 > include/linux/dma-buf.h | 22 +++--- > 17 files changed, 71 insertions(+), 70 deletions(-) > > -- > Sean Paul, Software Engineer, Google / Chromium OS -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-next-fixes
Hi Dave, A few fixes for you to pick up. The driver changes are trivial, and the maintainer change was necessitated by the sti fix. The headliner here is the dma_buf_ops rename, since it touches so many drivers. Everything looks sane and builds with that change, so it shouldn't cause problems. drm-misc-next-fixes-2017-04-20: Core changes: - Maintain sti via drm-misc (Vincent) - Rename dma_buf_ops->kmap_* to avoid naming collision (Logan) Driver changes: - Fix UHD displays on stih407 (Vincent) - Fix uninitialized var return in atmel-hlcdc (Dan) Take care, Sean The following changes since commit 8cb68c83ab99a474ae847602f0c514d0fe17cc82: drm: Fix get_property logic fumble (2017-04-12 18:11:32 +0200) are available in the git repository at: git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-fixes-2017-04-20 for you to fetch changes up to f9b67f0014cba18f1aabb6fa9272335a043eb6fd: dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro (2017-04-20 13:47:46 +0530) drm-misc-next-fixes-2017-04-20 Core changes: - Maintain sti via drm-misc (Vincent) - Rename dma_buf_ops->kmap_* to avoid naming collision (Logan) Driver changes: - Fix UHD displays on stih407 (Vincent) - Fix uninitialized var return in atmel-hlcdc (Dan) Dan Carpenter (1): drm: atmel-hlcdc: Uninitialized return in atmel_hlcdc_create_outputs() Logan Gunthorpe (1): dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro Vincent Abriou (2): MAINTAINERS: add drm/sti driver into drm-misc drm/sti: fix GDP size to support up to UHD resolution MAINTAINERS | 2 +- drivers/dma-buf/dma-buf.c| 16 drivers/gpu/drm/armada/armada_gem.c | 8 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 5 ++--- drivers/gpu/drm/drm_prime.c | 8 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 8 drivers/gpu/drm/i915/selftests/mock_dmabuf.c | 8 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c| 8 drivers/gpu/drm/sti/sti_gdp.c| 12 +++- drivers/gpu/drm/tegra/gem.c | 8 drivers/gpu/drm/udl/udl_dmabuf.c | 8 drivers/gpu/drm/vmwgfx/vmwgfx_prime.c| 8 drivers/media/v4l2-core/videobuf2-dma-contig.c | 4 ++-- drivers/media/v4l2-core/videobuf2-dma-sg.c | 4 ++-- drivers/media/v4l2-core/videobuf2-vmalloc.c | 4 ++-- drivers/staging/android/ion/ion.c| 8 include/linux/dma-buf.h | 22 +++--- 17 files changed, 71 insertions(+), 70 deletions(-) -- 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] freedesktop bug id: 100548, bisected to sched/clock commit
On Thu, Apr 20, 2017 at 07:19:50PM +0200, Peter Zijlstra wrote: > Just for my sanity, could you confirm "tsc=unstable" (which requires the > patch) actually works for you? Also, could you get me the dmesg of a 'broken' boot? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 13/20] drm/i915/guc: Provide register list to be saved/restored during engine reset
On 20/04/17 09:39, Daniele Ceraolo Spurio wrote: On 20/04/17 04:33, Joonas Lahtinen wrote: On ke, 2017-04-19 at 11:35 -0700, Michel Thierry wrote: From: Arun Siluvery GuC expects a list of registers from the driver which are saved/restored during engine reset. The type of value to be saved is controlled by flags. We provide a minimal set of registers that we want GuC to save and restore. This is not an issue in case of engine reset as driver initializes most of them following an engine reset, but in case of media reset (aka watchdog reset) which is completely internal to GuC (including resubmission of hung workload), it is necessary to provide this list, otherwise GuC won't be able to schedule further workloads after a reset. This is the minimal set of registers identified for things to work as expected but if we see any new issues, this register list can be expanded. In order to not loose any existing workarounds, we have to let GuC know the registers and its values. These will be reapplied after the reset. Note that we can't just read the current value because most of these registers are masked (so we have a workaround for a workaround for a workaround). v2: REGSET_MASKED is too difficult for GuC, use REGSET_SAVE_DEFAULT_VALUE and current value from RING_MODE reg instead; no need to preserve head/tail either, be extra paranoid and save whitelisted registers (Daniele). v3: Workarounds added only once during _init_workarounds also have to been restored, or we risk loosing them after internal GuC reset (Daniele). Cc: Daniele Ceraolo Spurio Signed-off-by: Arun Siluvery Signed-off-by: Jeff McGee Signed-off-by: Michel Thierry @@ -732,15 +755,16 @@ static int gen9_init_workarounds(struct intel_engine_cs *engine) int ret; /* WaConextSwitchWithConcurrentTLBInvalidate:skl,bxt,kbl,glk */ -I915_WRITE(GEN9_CSFE_CHICKEN1_RCS, _MASKED_BIT_ENABLE(GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE)); +I915_GUC_REG_WRITE(GEN9_CSFE_CHICKEN1_RCS, + _MASKED_BIT_ENABLE(GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE)); To make grepping easier, how about? I915_WRITE(GUC_REG(GEN9_CSFE_CHICKEN1_RCS), ...); Regards, Joonas GUC_REG makes it sound like it is somehow related to GuC, while it isn't, we just want GuC to restore its value. What about GUC_REG_RESTORE? Honestly, I dont care about names, pick one and I add it. Just a reminder, we not only need the reg offset, we want to save the value too. -Michel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] freedesktop bug id: 100548, bisected to sched/clock commit
On Tue, Apr 18, 2017 at 05:53:56PM +0200, Peter Zijlstra wrote: > On Tue, Apr 18, 2017 at 02:10:07PM +, Lofstedt, Marta wrote: > > Sorry Peter, I still see regression on the Core2 machine, with your patch. > > > > Blergh, ok. I'll see if I can dig out an actual Core2 machine somewhere. > I should have enough parts about. Argh! My Core2 seems to work as expected _without_ this patch (time is continuous at the stable->unstable switch), but is broken (time jumps backwards by almost .2s) with this patch -- because by the time ACPI Processor marks TSC as busted, we haven't ran the clocksource watchdog yet. Just for my sanity, could you confirm "tsc=unstable" (which requires the patch) actually works for you? I'll go prod at things now that I have an actual Core2 running; although sadly I don't see an obvious problem without this patch. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 18/20] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout
On 20/04/17 01:52, Chris Wilson wrote: On Wed, Apr 19, 2017 at 06:09:00PM -0700, Michel Thierry wrote: This patch is missing: diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index c1013af0b910..a8bdea43a217 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.c +++ b/drivers/gpu/drm/i915/i915_gem_context.c @@ -1135,7 +1135,7 @@ int i915_gem_context_getparam_ioctl(struct drm_device *dev, void *data, return PTR_ERR(ctx); } - args->size = 0; + args->size = (args->param != I915_CONTEXT_PARAM_WATCHDOG) ? 0 : args->size; switch (args->param) { case I915_CONTEXT_PARAM_BAN_PERIOD: ret = -EINVAL; Or there will be no way to get the current thresholds (chunk was missed due to some TRTT code nearby). I'll be sure to include it in the next version. No. It is always preset to 0. The PARAM should set it to the actual struct size (it would write) and *not* the user's size. -Chris Ok, then I'll change the shortcut in get_watchdog, because as it is you can query the size, but not the thresholds. int i915_gem_context_get_watchdog() { ... if (args->size == 0) goto out; ... out: args->size = sizeof(threshold_in_us); return 0; } } ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 13/20] drm/i915/guc: Provide register list to be saved/restored during engine reset
On 20/04/17 04:33, Joonas Lahtinen wrote: On ke, 2017-04-19 at 11:35 -0700, Michel Thierry wrote: From: Arun Siluvery GuC expects a list of registers from the driver which are saved/restored during engine reset. The type of value to be saved is controlled by flags. We provide a minimal set of registers that we want GuC to save and restore. This is not an issue in case of engine reset as driver initializes most of them following an engine reset, but in case of media reset (aka watchdog reset) which is completely internal to GuC (including resubmission of hung workload), it is necessary to provide this list, otherwise GuC won't be able to schedule further workloads after a reset. This is the minimal set of registers identified for things to work as expected but if we see any new issues, this register list can be expanded. In order to not loose any existing workarounds, we have to let GuC know the registers and its values. These will be reapplied after the reset. Note that we can't just read the current value because most of these registers are masked (so we have a workaround for a workaround for a workaround). v2: REGSET_MASKED is too difficult for GuC, use REGSET_SAVE_DEFAULT_VALUE and current value from RING_MODE reg instead; no need to preserve head/tail either, be extra paranoid and save whitelisted registers (Daniele). v3: Workarounds added only once during _init_workarounds also have to been restored, or we risk loosing them after internal GuC reset (Daniele). Cc: Daniele Ceraolo Spurio Signed-off-by: Arun Siluvery Signed-off-by: Jeff McGee Signed-off-by: Michel Thierry @@ -732,15 +755,16 @@ static int gen9_init_workarounds(struct intel_engine_cs *engine) int ret; /* WaConextSwitchWithConcurrentTLBInvalidate:skl,bxt,kbl,glk */ - I915_WRITE(GEN9_CSFE_CHICKEN1_RCS, _MASKED_BIT_ENABLE(GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE)); + I915_GUC_REG_WRITE(GEN9_CSFE_CHICKEN1_RCS, + _MASKED_BIT_ENABLE(GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE)); To make grepping easier, how about? I915_WRITE(GUC_REG(GEN9_CSFE_CHICKEN1_RCS), ...); Regards, Joonas GUC_REG makes it sound like it is somehow related to GuC, while it isn't, we just want GuC to restore its value. What about GUC_REG_RESTORE? Thanks, Daniele ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v4] benchmarks/gem_wsim: Command submission workload simulator
On Thu, Apr 20, 2017 at 01:29:11PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > +static void > +run_workload(unsigned int id, struct workload *wrk, unsigned int repeat, > + enum intel_engine_id (*balance)(struct workload *wrk, > + struct w_step *w), > + unsigned int flags) > +{ > + struct timespec t_start, t_end; > + struct w_step *w; > + double t; > + int i, j; > + > + clock_gettime(CLOCK_MONOTONIC, &t_start); > + > + srand(t_start.tv_nsec); Let's supply the seed with the workload specification. And use a portable prng so we can be sure we can reproduce results from one system to the next. -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 i-g-t v4] benchmarks/gem_wsim: Command submission workload simulator
On Thu, Apr 20, 2017 at 03:34:56PM +0100, Tvrtko Ursulin wrote: > > On 20/04/2017 15:23, Chris Wilson wrote: > >On Thu, Apr 20, 2017 at 01:29:11PM +0100, Tvrtko Ursulin wrote: > >>+static void > >>+alloc_step_batch(struct workload *wrk, struct w_step *w, struct w_step_eb > >>*b, > >>+enum intel_engine_id engine, unsigned int flags) > >>+{ > >>+ unsigned int bb_i, j = 0; > >>+ > >>+ b->obj[j].handle = gem_create(fd, 4096); > >>+ b->obj[j].flags = EXEC_OBJECT_WRITE; > >>+ j++; > >>+ > >>+ if (flags & SEQNO) { > >>+ b->obj[j].handle = wrk->status_page_handle; > >>+ j++; > >>+ } > >>+ > >>+ bb_i = j++; > >>+ b->bb_sz = get_bb_sz(w->duration.max); > >>+ b->bb_handle = b->obj[bb_i].handle = gem_create(fd, b->bb_sz); > >>+ terminate_bb(w, b, engine, flags); > >>+ > >>+ igt_assert(w->dependency <= 0); > >>+ if (w->dependency) { > >>+ int dep_idx = w->idx + w->dependency; > >>+ > >>+ igt_assert(dep_idx >= 0 && dep_idx < wrk->nr_steps); > >>+ igt_assert(wrk->steps[dep_idx].type == BATCH); > >>+ > >>+ b->obj[j].handle = b->obj[bb_i].handle; > >>+ bb_i = j; > >>+ b->obj[j - 1].handle = wrk->steps[dep_idx].b[0].obj[0].handle; > >>+ j++; > >>+ > >>+ if (wrk->steps[dep_idx].b[1].obj[0].handle) { > >>+ b->obj[j].handle = b->obj[bb_i].handle; > >>+ bb_i = j; > >>+ b->obj[j - 1].handle = > >>+ wrk->steps[dep_idx].b[1].obj[0].handle; > >>+ j++; > >>+ } > >>+ } > >>+ > >>+ if (flags & SEQNO) { > >>+ b->reloc.presumed_offset = -1; > > > >So as I understand it, you are caching the execbuf/obj/reloc for the > >workload and then may reissue later with different seqno on different > >rings? In which case we have a problem as the kernel will write back the > > > > >updated offsets to b->reloc.presumed_offset and b->obj[].offset and in > >future passes they will match and the seqno write will go into the wrong > >slot (if it swaps rings). > > > >You either want to reset presumed_offset=-1 each time, or better for all > >concerned write the correct address alongside the seqno (which also > >enables NORELOC). > > > >Delta incoming. > > Only the seqno changes, but each engine has its own eb/obj/reloc. So > I think there is no problem. Or is there still? bb_handle is per engine as well. Ugh. No, that seems like you are self-consistent, you just need to remove the -1 and your code is NORELOC correct. I wouldn't go so far as having entirely separate batches for each engine though :) -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 i-g-t v4] benchmarks/gem_wsim: Command submission workload simulator
On 20/04/2017 15:52, Chris Wilson wrote: On Thu, Apr 20, 2017 at 01:29:11PM +0100, Tvrtko Ursulin wrote: + wrk->nr_bb[engine]++; + + if (engine == VCS && balance) { + engine = balance(wrk, w); + wrk->nr_bb[engine]++; + b = &w->b[engine - VCS1]; + + if (flags & SEQNO) + update_bb_seqno(b, engine, + ++wrk->seqno[engine]); + } + + if (w->duration.min != w->duration.max) { + unsigned int d = get_duration(&w->duration); + unsigned long offset; + + offset = ALIGN(b->bb_sz - get_bb_sz(d), + 2 * sizeof(uint32_t)); + b->eb.batch_start_offset = offset; + } + + gem_execbuf(fd, &b->eb); Likely double counting wrk->nr_bb. I suggest placing it next to the gem_execbuf(). Just convenience in balancing mode so that nr(VCS) = nr(VCS1) + nr(VCS2). Also from a different angle, if the sum does not hold, that means workload had auto-balancing and explicit VCS1/2 batches. It's only used to print out the stats at the end of the run. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/27] drm/i915/execlists: Pack the count into the low bits of the port.request
On 19/04/2017 10:41, Chris Wilson wrote: add/remove: 1/1 grow/shrink: 5/4 up/down: 391/-578 (-187) function old new delta execlists_submit_ports 262 471+209 port_assign.isra - 136+136 capture 63446359 +15 reset_common_ring438 452 +14 execlists_submit_request 228 238 +10 gen8_init_common_ring334 341 +7 intel_engine_is_idle 106 105 -1 i915_engine_info23142290 -24 __i915_gem_set_wedged_BKL485 411 -74 intel_lrc_irq_handler 17891604-185 execlists_update_context 294 --294 The most important change there is the improve to the intel_lrc_irq_handler and excclist_submit_ports (net improvement since execlists_update_context is now inlined). Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_debugfs.c| 32 --- drivers/gpu/drm/i915/i915_gem.c| 6 +- drivers/gpu/drm/i915/i915_gpu_error.c | 13 ++- drivers/gpu/drm/i915/i915_guc_submission.c | 18 ++-- drivers/gpu/drm/i915/intel_engine_cs.c | 2 +- drivers/gpu/drm/i915/intel_lrc.c | 133 - drivers/gpu/drm/i915/intel_ringbuffer.h| 8 +- 7 files changed, 120 insertions(+), 92 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 870c470177b5..0b5d7142d8d9 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -3315,6 +3315,7 @@ static int i915_engine_info(struct seq_file *m, void *unused) if (i915.enable_execlists) { u32 ptr, read, write; struct rb_node *rb; + unsigned int idx; seq_printf(m, "\tExeclist status: 0x%08x %08x\n", I915_READ(RING_EXECLIST_STATUS_LO(engine)), @@ -3332,8 +,7 @@ static int i915_engine_info(struct seq_file *m, void *unused) if (read > write) write += GEN8_CSB_ENTRIES; while (read < write) { - unsigned int idx = ++read % GEN8_CSB_ENTRIES; - + idx = ++read % GEN8_CSB_ENTRIES; seq_printf(m, "\tExeclist CSB[%d]: 0x%08x, context: %d\n", idx, I915_READ(RING_CONTEXT_STATUS_BUF_LO(engine, idx)), @@ -3341,21 +3341,19 @@ static int i915_engine_info(struct seq_file *m, void *unused) } rcu_read_lock(); - rq = READ_ONCE(engine->execlist_port[0].request); - if (rq) { - seq_printf(m, "\t\tELSP[0] count=%d, ", - engine->execlist_port[0].count); - print_request(m, rq, "rq: "); - } else { - seq_printf(m, "\t\tELSP[0] idle\n"); - } - rq = READ_ONCE(engine->execlist_port[1].request); - if (rq) { - seq_printf(m, "\t\tELSP[1] count=%d, ", - engine->execlist_port[1].count); - print_request(m, rq, "rq: "); - } else { - seq_printf(m, "\t\tELSP[1] idle\n"); + for (idx = 0; idx < ARRAY_SIZE(engine->execlist_port); idx++) { + unsigned int count; + + rq = port_unpack(&engine->execlist_port[idx], +&count); + if (rq) { + seq_printf(m, "\t\tELSP[%d] count=%d, ", + idx, count); + print_request(m, rq, "rq: "); + } else { + seq_printf(m, "\t\tELSP[%d] idle\n", + idx); + } } rcu_read_unlock(); diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 2bc72314cdd1..f6df402a5247 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -3039,12 +3039,14 @@ static void engine_set_wedged(struct intel_engine_cs *engine) */ if (i915.enable_execlists) { +
Re: [Intel-gfx] [PATCH i-g-t v4] benchmarks/gem_wsim: Command submission workload simulator
On Thu, Apr 20, 2017 at 01:29:11PM +0100, Tvrtko Ursulin wrote: > + wrk->nr_bb[engine]++; > + > + if (engine == VCS && balance) { > + engine = balance(wrk, w); > + wrk->nr_bb[engine]++; > + b = &w->b[engine - VCS1]; > + > + if (flags & SEQNO) > + update_bb_seqno(b, engine, > + ++wrk->seqno[engine]); > + } > + > + if (w->duration.min != w->duration.max) { > + unsigned int d = get_duration(&w->duration); > + unsigned long offset; > + > + offset = ALIGN(b->bb_sz - get_bb_sz(d), > +2 * sizeof(uint32_t)); > + b->eb.batch_start_offset = offset; > + } > + > + gem_execbuf(fd, &b->eb); Likely double counting wrk->nr_bb. I suggest placing it next to the gem_execbuf(). -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 v4] drm: Add DPCD definitions for DP 1.4 DSC feature
On Tue, 04 Apr 2017, Manasi Navare wrote: > From: "Navare, Manasi D" > > Display stream compression is supported on DP 1.4 DP > devices. This patch adds the corersponding DPCD > register definitions for DSC. > > v4: > * Add DSC Enable DPCD register def (Ander) > v3: > * Add some SHIFTS and MASKS for uniformity (Jani Nikula) > v2: > * Rebased on drm-tip > > Signed-off-by: Manasi Navare > Cc: Jani Nikula > Cc: Paulo Zanoni > Cc: dri-de...@lists.freedesktop.org Pushed to drm-misc-next, thanks for the patch. BR, Jani. > --- > include/drm/drm_dp_helper.h | 107 > > 1 file changed, 107 insertions(+) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index c0bd0d7..f6258ed 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -179,6 +179,111 @@ > > #define DP_GUID 0x030 /* 1.2 */ > > +#define DP_DSC_SUPPORT 0x060 /* DP 1.4 */ > +# define DP_DSC_DECOMPRESSION_IS_SUPPORTED (1 << 0) > + > +#define DP_DSC_REV 0x061 > +# define DP_DSC_MAJOR_MASK (0xf << 0) > +# define DP_DSC_MINOR_MASK (0xf << 4) > +# define DP_DSC_MAJOR_SHIFT 0 > +# define DP_DSC_MINOR_SHIFT 4 > + > +#define DP_DSC_RC_BUF_BLK_SIZE 0x062 > +# define DP_DSC_RC_BUF_BLK_SIZE_1 0x0 > +# define DP_DSC_RC_BUF_BLK_SIZE_4 0x1 > +# define DP_DSC_RC_BUF_BLK_SIZE_16 0x2 > +# define DP_DSC_RC_BUF_BLK_SIZE_64 0x3 > + > +#define DP_DSC_RC_BUF_SIZE 0x063 > + > +#define DP_DSC_SLICE_CAP_1 0x064 > +# define DP_DSC_1_PER_DP_DSC_SINK (1 << 0) > +# define DP_DSC_2_PER_DP_DSC_SINK (1 << 1) > +# define DP_DSC_4_PER_DP_DSC_SINK (1 << 3) > +# define DP_DSC_6_PER_DP_DSC_SINK (1 << 4) > +# define DP_DSC_8_PER_DP_DSC_SINK (1 << 5) > +# define DP_DSC_10_PER_DP_DSC_SINK (1 << 6) > +# define DP_DSC_12_PER_DP_DSC_SINK (1 << 7) > + > +#define DP_DSC_LINE_BUF_BIT_DEPTH 0x065 > +# define DP_DSC_LINE_BUF_BIT_DEPTH_MASK (0xf << 0) > +# define DP_DSC_LINE_BUF_BIT_DEPTH_90x0 > +# define DP_DSC_LINE_BUF_BIT_DEPTH_10 0x1 > +# define DP_DSC_LINE_BUF_BIT_DEPTH_11 0x2 > +# define DP_DSC_LINE_BUF_BIT_DEPTH_12 0x3 > +# define DP_DSC_LINE_BUF_BIT_DEPTH_13 0x4 > +# define DP_DSC_LINE_BUF_BIT_DEPTH_14 0x5 > +# define DP_DSC_LINE_BUF_BIT_DEPTH_15 0x6 > +# define DP_DSC_LINE_BUF_BIT_DEPTH_16 0x7 > +# define DP_DSC_LINE_BUF_BIT_DEPTH_80x8 > + > +#define DP_DSC_BLK_PREDICTION_SUPPORT 0x066 > +# define DP_DSC_BLK_PREDICTION_IS_SUPPORTED (1 << 0) > + > +#define DP_DSC_MAX_BITS_PER_PIXEL_LOW 0x067 /* eDP 1.4 */ > + > +#define DP_DSC_MAX_BITS_PER_PIXEL_HI0x068 /* eDP 1.4 */ > + > +#define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069 > +# define DP_DSC_RGB (1 << 0) > +# define DP_DSC_YCbCr444(1 << 1) > +# define DP_DSC_YCbCr422_Simple (1 << 2) > +# define DP_DSC_YCbCr422_Native (1 << 3) > +# define DP_DSC_YCbCr420_Native (1 << 4) > + > +#define DP_DSC_DEC_COLOR_DEPTH_CAP 0x06A > +# define DP_DSC_8_BPC (1 << 1) > +# define DP_DSC_10_BPC (1 << 2) > +# define DP_DSC_12_BPC (1 << 3) > + > +#define DP_DSC_PEAK_THROUGHPUT 0x06B > +# define DP_DSC_THROUGHPUT_MODE_0_MASK (0xf << 0) > +# define DP_DSC_THROUGHPUT_MODE_0_SHIFT 0 > +# define DP_DSC_THROUGHPUT_MODE_0_340 (1 << 0) > +# define DP_DSC_THROUGHPUT_MODE_0_400 (2 << 0) > +# define DP_DSC_THROUGHPUT_MODE_0_450 (3 << 0) > +# define DP_DSC_THROUGHPUT_MODE_0_500 (4 << 0) > +# define DP_DSC_THROUGHPUT_MODE_0_550 (5 << 0) > +# define DP_DSC_THROUGHPUT_MODE_0_600 (6 << 0) > +# define DP_DSC_THROUGHPUT_MODE_0_650 (7 << 0) > +# define DP_DSC_THROUGHPUT_MODE_0_700 (8 << 0) > +# define DP_DSC_THROUGHPUT_MODE_0_750 (9 << 0) > +# define DP_DSC_THROUGHPUT_MODE_0_800 (10 << 0) > +# define DP_DSC_THROUGHPUT_MODE_0_850 (11 << 0) > +# define DP_DSC_THROUGHPUT_MODE_0_900 (12 << 0) > +# define DP_DSC_THROUGHPUT_MODE_0_950 (13 << 0) > +# define DP_DSC_THROUGHPUT_MODE_0_1000 (14 << 0) > +# define DP_DSC_THROUGHPUT_MODE_1_MASK (0xf << 4) > +# define DP_DSC_THROUGHPUT_MODE_1_SHIFT 4 > +# define DP_DSC_THROUGHPUT_MODE_1_340 (1 << 4) > +# define DP_DSC_THROUGHPUT_MODE_1_400 (2 << 4) > +# define DP_DSC_THROUGHPUT_MODE_1_450 (3 << 4) > +# define DP_DSC_THROUGHPUT_MODE_1_500 (4 << 4) > +# define DP_DSC_THROUGHPUT_MODE_1_550 (5 << 4) > +# define DP_DSC_THROUGHPUT_MODE_1_600 (6 << 4) > +# define DP_DSC_THROUGHPUT_MODE_1_650 (7 << 4) > +# define DP_DSC_THROUGHPUT_MODE_1_700 (8 <<
Re: [Intel-gfx] [PATCH i-g-t v4] benchmarks/gem_wsim: Command submission workload simulator
On 20/04/2017 15:33, Chris Wilson wrote: On Thu, Apr 20, 2017 at 03:23:27PM +0100, Chris Wilson wrote: You either want to reset presumed_offset=-1 each time, or better for all concerned write the correct address alongside the seqno (which also enables NORELOC). Delta incoming. See attached. Next concern is that I have full rings which implies that we are not waiting on each batch before resubmitting with a new seqno? If I throw a assert(!busy(batch_bo)) before the *b->mapped_seqno am I going to be upset? Yes you would. :) I had a sync (as a move to cpu domain) before seqno update in the last version but it disappeared as I was fixing the whole area of seqno tracking. So the balancing results in the patch are bogus since the seqno can jump to latest ahead of the time... Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v4] benchmarks/gem_wsim: Command submission workload simulator
On 20/04/2017 15:23, Chris Wilson wrote: On Thu, Apr 20, 2017 at 01:29:11PM +0100, Tvrtko Ursulin wrote: +static void +alloc_step_batch(struct workload *wrk, struct w_step *w, struct w_step_eb *b, +enum intel_engine_id engine, unsigned int flags) +{ + unsigned int bb_i, j = 0; + + b->obj[j].handle = gem_create(fd, 4096); + b->obj[j].flags = EXEC_OBJECT_WRITE; + j++; + + if (flags & SEQNO) { + b->obj[j].handle = wrk->status_page_handle; + j++; + } + + bb_i = j++; + b->bb_sz = get_bb_sz(w->duration.max); + b->bb_handle = b->obj[bb_i].handle = gem_create(fd, b->bb_sz); + terminate_bb(w, b, engine, flags); + + igt_assert(w->dependency <= 0); + if (w->dependency) { + int dep_idx = w->idx + w->dependency; + + igt_assert(dep_idx >= 0 && dep_idx < wrk->nr_steps); + igt_assert(wrk->steps[dep_idx].type == BATCH); + + b->obj[j].handle = b->obj[bb_i].handle; + bb_i = j; + b->obj[j - 1].handle = wrk->steps[dep_idx].b[0].obj[0].handle; + j++; + + if (wrk->steps[dep_idx].b[1].obj[0].handle) { + b->obj[j].handle = b->obj[bb_i].handle; + bb_i = j; + b->obj[j - 1].handle = + wrk->steps[dep_idx].b[1].obj[0].handle; + j++; + } + } + + if (flags & SEQNO) { + b->reloc.presumed_offset = -1; So as I understand it, you are caching the execbuf/obj/reloc for the workload and then may reissue later with different seqno on different rings? In which case we have a problem as the kernel will write back the > > updated offsets to b->reloc.presumed_offset and b->obj[].offset and in future passes they will match and the seqno write will go into the wrong slot (if it swaps rings). You either want to reset presumed_offset=-1 each time, or better for all concerned write the correct address alongside the seqno (which also enables NORELOC). Delta incoming. Only the seqno changes, but each engine has its own eb/obj/reloc. So I think there is no problem. Or is there still? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v4] benchmarks/gem_wsim: Command submission workload simulator
On Thu, Apr 20, 2017 at 03:23:27PM +0100, Chris Wilson wrote: > You either want to reset presumed_offset=-1 each time, or better for all > concerned write the correct address alongside the seqno (which also > enables NORELOC). > > Delta incoming. See attached. Next concern is that I have full rings which implies that we are not waiting on each batch before resubmitting with a new seqno? If I throw a assert(!busy(batch_bo)) before the *b->mapped_seqno am I going to be upset? -Chris -- Chris Wilson, Intel Open Source Technology Centre >From 5bf424c2719e81f926b74f4136610cbdfd26a4d8 Mon Sep 17 00:00:00 2001 From: Chris Wilson Date: Thu, 20 Apr 2017 15:30:07 +0100 Subject: [PATCH] seqno-reloc --- benchmarks/gem_wsim.c | 17 +++-- 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c index adf2d6de..e616335b 100644 --- a/benchmarks/gem_wsim.c +++ b/benchmarks/gem_wsim.c @@ -45,6 +45,8 @@ #include "drmtest.h" #include "intel_io.h" +#define LOCAL_I915_GEM_DOMAIN_WC 0x80 + enum intel_engine_id { RCS, BCS, @@ -86,7 +88,9 @@ struct w_step struct drm_i915_gem_relocation_entry reloc; unsigned long bb_sz; uint32_t bb_handle; - uint32_t *mapped_batch, *mapped_seqno; + uint32_t *mapped_batch; + uint64_t *mapped_address; + uint32_t *mapped_seqno; unsigned int mapped_len; } b[2]; /* One for each VCS when load balancing */ }; @@ -405,7 +409,8 @@ terminate_bb(struct w_step *w, struct w_step_eb *b, enum intel_engine_id engine, mmap_len += cmd_offset - mmap_start; gem_set_domain(fd, b->bb_handle, - I915_GEM_DOMAIN_CPU, I915_GEM_DOMAIN_CPU); + LOCAL_I915_GEM_DOMAIN_WC, + LOCAL_I915_GEM_DOMAIN_WC); ptr = gem_mmap__wc(fd, b->bb_handle, mmap_start, mmap_len, PROT_WRITE); cs = (uint32_t *)((char *)ptr + cmd_offset - mmap_start); @@ -415,6 +420,7 @@ terminate_bb(struct w_step *w, struct w_step_eb *b, enum intel_engine_id engine, b->reloc.delta = (engine - VCS1) * sizeof(uint32_t); *cs++ = MI_STORE_DWORD_IMM; + b->mapped_address = (uint64_t *)cs; *cs++ = 0; *cs++ = 0; b->mapped_seqno = cs; @@ -469,7 +475,6 @@ alloc_step_batch(struct workload *wrk, struct w_step *w, struct w_step_eb *b, } if (flags & SEQNO) { - b->reloc.presumed_offset = -1; b->reloc.target_handle = 1; b->obj[bb_i].relocs_ptr = to_user_pointer(&b->reloc); b->obj[bb_i].relocation_count = 1; @@ -485,8 +490,7 @@ alloc_step_batch(struct workload *wrk, struct w_step *w, struct w_step_eb *b, engine = VCS1; b->eb.flags = eb_engine_map[engine]; b->eb.flags |= I915_EXEC_HANDLE_LUT; - if (!(flags & SEQNO)) - b->eb.flags |= I915_EXEC_NO_RELOC; + b->eb.flags |= I915_EXEC_NO_RELOC; #ifdef DEBUG printf("%u: %u:%x|%x|%x|%x %10lu flags=%llx bb=%x[%u] ctx[%u]=%u\n", w->idx, b->eb.buffer_count, b->obj[0].handle, @@ -628,8 +632,9 @@ static void update_bb_seqno(struct w_step_eb *b, enum intel_engine_id engine, uint32_t seqno) { - *b->mapped_seqno = seqno; b->reloc.delta = (engine - VCS1) * sizeof(uint32_t); + *b->mapped_address = b->reloc.presumed_offset + b->reloc.delta; + *b->mapped_seqno = seqno; } static void -- 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 v4] benchmarks/gem_wsim: Command submission workload simulator
On Thu, Apr 20, 2017 at 01:29:11PM +0100, Tvrtko Ursulin wrote: > +static void > +alloc_step_batch(struct workload *wrk, struct w_step *w, struct w_step_eb *b, > + enum intel_engine_id engine, unsigned int flags) > +{ > + unsigned int bb_i, j = 0; > + > + b->obj[j].handle = gem_create(fd, 4096); > + b->obj[j].flags = EXEC_OBJECT_WRITE; > + j++; > + > + if (flags & SEQNO) { > + b->obj[j].handle = wrk->status_page_handle; > + j++; > + } > + > + bb_i = j++; > + b->bb_sz = get_bb_sz(w->duration.max); > + b->bb_handle = b->obj[bb_i].handle = gem_create(fd, b->bb_sz); > + terminate_bb(w, b, engine, flags); > + > + igt_assert(w->dependency <= 0); > + if (w->dependency) { > + int dep_idx = w->idx + w->dependency; > + > + igt_assert(dep_idx >= 0 && dep_idx < wrk->nr_steps); > + igt_assert(wrk->steps[dep_idx].type == BATCH); > + > + b->obj[j].handle = b->obj[bb_i].handle; > + bb_i = j; > + b->obj[j - 1].handle = wrk->steps[dep_idx].b[0].obj[0].handle; > + j++; > + > + if (wrk->steps[dep_idx].b[1].obj[0].handle) { > + b->obj[j].handle = b->obj[bb_i].handle; > + bb_i = j; > + b->obj[j - 1].handle = > + wrk->steps[dep_idx].b[1].obj[0].handle; > + j++; > + } > + } > + > + if (flags & SEQNO) { > + b->reloc.presumed_offset = -1; So as I understand it, you are caching the execbuf/obj/reloc for the workload and then may reissue later with different seqno on different rings? In which case we have a problem as the kernel will write back the updated offsets to b->reloc.presumed_offset and b->obj[].offset and in future passes they will match and the seqno write will go into the wrong slot (if it swaps rings). You either want to reset presumed_offset=-1 each time, or better for all concerned write the correct address alongside the seqno (which also enables NORELOC). Delta incoming. -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 12/27] drm/i915: Only report a wakeup if the waiter was truly asleep
On Thu, Apr 20, 2017 at 02:30:21PM +0100, Tvrtko Ursulin wrote: > > On 19/04/2017 10:41, Chris Wilson wrote: > >If we attempt to wake up a waiter, who is currently checking the seqno > >it will be in the TASK_INTERRUPTIBLE state and ttwu will report success. > >However, it is actually awake and functioning -- so delay reporting the > >actual wake up until it sleeps. > > > >v2: Defend against !CONFIG_SMP > >v3: Don't filter out calls to wake_up_process I forgot this patch was inbetween the series, i.e. I am not pursuing this one at the moment. > >References: https://bugs.freedesktop.org/show_bug.cgi?id=17 > >Signed-off-by: Chris Wilson > >Cc: Tvrtko Ursulin > >Cc: Joonas Lahtinen > >--- > > drivers/gpu/drm/i915/intel_breadcrumbs.c | 18 -- > > drivers/gpu/drm/i915/intel_ringbuffer.h | 4 > > 2 files changed, 20 insertions(+), 2 deletions(-) > > > >diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c > >b/drivers/gpu/drm/i915/intel_breadcrumbs.c > >index 9ccbf26124c6..808d3a3cda0a 100644 > >--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c > >+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c > >@@ -27,6 +27,12 @@ > > > > #include "i915_drv.h" > > > >+#ifdef CONFIG_SMP > >+#define task_asleep(tsk) (!(tsk)->on_cpu) > >+#else > >+#define task_asleep(tsk) ((tsk) != current) > >+#endif > >+ > > static unsigned int __intel_breadcrumbs_wakeup(struct intel_breadcrumbs *b) > > { > > struct intel_wait *wait; > >@@ -37,8 +43,16 @@ static unsigned int __intel_breadcrumbs_wakeup(struct > >intel_breadcrumbs *b) > > wait = b->irq_wait; > > if (wait) { > > result = ENGINE_WAKEUP_WAITER; > >-if (wake_up_process(wait->tsk)) > >+ > >+/* Be careful not to report a successful wakeup if the waiter > >+ * is currently processing the seqno, where it will have > >+ * already called set_task_state(TASK_INTERRUPTIBLE). > >+ */ > >+if (task_asleep(wait->tsk)) > > result |= ENGINE_WAKEUP_ASLEEP; > >+ > >+if (wake_up_process(wait->tsk)) > >+result |= ENGINE_WAKEUP_SUCCESS; > > The rough idea I had of atomic_inc(&b->wakeup_cnt) here with > unconditional wake_up_process, coupled with atomic_dec_and_test in > the signaler would not work? I was thinking that would avoid > signaler losing the wakeup and avoid us having to touch the low > level scheduler data. Best one I had was to store an atomic counter in each struct intel_wait to determine if it was inside the wait-for-breadcrumb. But that is duplicating on-cpu (with the same advantage of not being confused by any sleep elsewhere in the check-breadcrumb path) and fundamentally less precise. > Or what you meant last time by not sure it was worth it was > referring to the above? I think the chance that this is affecting a missed breacrumb result is small, certainly not with the regularity of snb-2600. I had pushed it to the end, but obviously not far enough down the list. When I looked at the list of patches, I actually though this was a different patch "drm/i915: Only wake the waiter from the interrupt if passed" My apologies for the noise. -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 12/27] drm/i915: Only report a wakeup if the waiter was truly asleep
On 19/04/2017 10:41, Chris Wilson wrote: If we attempt to wake up a waiter, who is currently checking the seqno it will be in the TASK_INTERRUPTIBLE state and ttwu will report success. However, it is actually awake and functioning -- so delay reporting the actual wake up until it sleeps. v2: Defend against !CONFIG_SMP v3: Don't filter out calls to wake_up_process References: https://bugs.freedesktop.org/show_bug.cgi?id=17 Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/intel_breadcrumbs.c | 18 -- drivers/gpu/drm/i915/intel_ringbuffer.h | 4 2 files changed, 20 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c b/drivers/gpu/drm/i915/intel_breadcrumbs.c index 9ccbf26124c6..808d3a3cda0a 100644 --- a/drivers/gpu/drm/i915/intel_breadcrumbs.c +++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c @@ -27,6 +27,12 @@ #include "i915_drv.h" +#ifdef CONFIG_SMP +#define task_asleep(tsk) (!(tsk)->on_cpu) +#else +#define task_asleep(tsk) ((tsk) != current) +#endif + static unsigned int __intel_breadcrumbs_wakeup(struct intel_breadcrumbs *b) { struct intel_wait *wait; @@ -37,8 +43,16 @@ static unsigned int __intel_breadcrumbs_wakeup(struct intel_breadcrumbs *b) wait = b->irq_wait; if (wait) { result = ENGINE_WAKEUP_WAITER; - if (wake_up_process(wait->tsk)) + + /* Be careful not to report a successful wakeup if the waiter +* is currently processing the seqno, where it will have +* already called set_task_state(TASK_INTERRUPTIBLE). +*/ + if (task_asleep(wait->tsk)) result |= ENGINE_WAKEUP_ASLEEP; + + if (wake_up_process(wait->tsk)) + result |= ENGINE_WAKEUP_SUCCESS; The rough idea I had of atomic_inc(&b->wakeup_cnt) here with unconditional wake_up_process, coupled with atomic_dec_and_test in the signaler would not work? I was thinking that would avoid signaler losing the wakeup and avoid us having to touch the low level scheduler data. Or what you meant last time by not sure it was worth it was referring to the above? Regards, Tvrtko } return result; @@ -98,7 +112,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long data) * but we still have a waiter. Assuming all batches complete within * DRM_I915_HANGCHECK_JIFFIES [1.5s]! */ - if (intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP) { + if (intel_engine_wakeup(engine) == ENGINE_WAKEUP) { missed_breadcrumb(engine); mod_timer(&engine->breadcrumbs.fake_irq, jiffies + 1); } else { diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h b/drivers/gpu/drm/i915/intel_ringbuffer.h index 00d36aa4e26d..d25b88467e5e 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.h +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h @@ -668,6 +668,10 @@ static inline bool intel_engine_has_waiter(const struct intel_engine_cs *engine) unsigned int intel_engine_wakeup(struct intel_engine_cs *engine); #define ENGINE_WAKEUP_WAITER BIT(0) #define ENGINE_WAKEUP_ASLEEP BIT(1) +#define ENGINE_WAKEUP_SUCCESS BIT(2) +#define ENGINE_WAKEUP (ENGINE_WAKEUP_WAITER | \ + ENGINE_WAKEUP_ASLEEP | \ + ENGINE_WAKEUP_SUCCESS) void __intel_engine_disarm_breadcrumbs(struct intel_engine_cs *engine); void intel_engine_disarm_breadcrumbs(struct intel_engine_cs *engine); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v4] benchmarks/gem_wsim: Command submission workload simulator
From: Tvrtko Ursulin Tool which emits batch buffers to engines with configurable sequences, durations, contexts, dependencies and userspace waits. Unfinished but shows promise so sending out for early feedback. v2: * Load workload descriptors from files. (also -w) * Help text. * Calibration control if needed. (-t) * NORELOC | LUT to eb flags. * Added sample workload to wsim/workload1. v3: * Multiple parallel different workloads (-w -w ...). * Multi-context workloads. * Variable (random) batch length. * Load balancing (round robin and queue depth estimation). * Workloads delays and explicit sync steps. * Workload frequency (period) control. v4: * Fixed queue-depth estimation by creating separate batches per engine when qd load balancing is on. * Dropped separate -s cmd line option. It can turn itself on automatically when needed. * Keep a single status page and lie about the write hazard as suggested by Chris. * Use batch_start_offset for controlling the batch duration. (Chris) * Set status page object cache level. (Chris) * Moved workload description to a README. * Tidied example workloads. * Some other cleanups and refactorings. TODO list: * Fence support. * Better error handling. * Less 1980's workload parsing. * Proper workloads. * Threads? * ... ? Signed-off-by: Tvrtko Ursulin Cc: Chris Wilson Cc: "Rogozhkin, Dmitry V" --- Comparing some test workloads under load balancing it seems that it is starting to work, but it still needs more thorough verification. For example, round- robin balancing: # benchmarks/gem_wsim -n 585341 \ -w benchmarks/wsim/vcs1.wsim \ -w benchmarks/wsim/vcs_balanced.wsim \ -r 100 -b 0 Using 585341 nop calibration for 1000us delay. 2 clients. 1: 3.008s elapsed (33.243 workloads/s). 2500 (1250 + 1250) total VCS batches. 0: 4.455s elapsed (22.449 workloads/s). 0 (2500 + 0) total VCS batches. 4.455s elapsed (44.889 workloads/s) Versus the queue-depth estimation: # benchmarks/gem_wsim -n 585341 \ -w benchmarks/wsim/vcs1.wsim \ -w benchmarks/wsim/vcs_balanced.wsim \ -r 100 -b 1 Using 585341 nop calibration for 1000us delay. 2 clients. 1: 2.239s elapsed (44.659 workloads/s). 2500 (837 + 1663) total VCS batches. Average queue depths 27.575, 19.285. 0: 4.012s elapsed (24.928 workloads/s). 0 (2500 + 0) total VCS batches. Average queue depths -nan, -nan. 4.012s elapsed (49.845 workloads/s) In both cases we run two workloads, one which only submits to VCS1 and one which can be load-balanced. The latter gets a ~33% boost with queue-depth estimation, and the non-balancing workload ~10%. --- benchmarks/Makefile.sources |1 + benchmarks/gem_wsim.c| 1014 ++ benchmarks/wsim/README | 54 ++ benchmarks/wsim/media_17i7.wsim |7 + benchmarks/wsim/media_load_balance_17i7.wsim |7 + benchmarks/wsim/vcs1.wsim| 25 + benchmarks/wsim/vcs_balanced.wsim| 25 + 7 files changed, 1133 insertions(+) create mode 100644 benchmarks/gem_wsim.c create mode 100644 benchmarks/wsim/README create mode 100644 benchmarks/wsim/media_17i7.wsim create mode 100644 benchmarks/wsim/media_load_balance_17i7.wsim create mode 100644 benchmarks/wsim/vcs1.wsim create mode 100644 benchmarks/wsim/vcs_balanced.wsim diff --git a/benchmarks/Makefile.sources b/benchmarks/Makefile.sources index 3af54ebe36f2..3a941150abb3 100644 --- a/benchmarks/Makefile.sources +++ b/benchmarks/Makefile.sources @@ -14,6 +14,7 @@ benchmarks_prog_list =\ gem_prw \ gem_set_domain \ gem_syslatency \ + gem_wsim\ kms_vblank \ prime_lookup\ vgem_mmap \ diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c new file mode 100644 index ..adf2d6decf12 --- /dev/null +++ b/benchmarks/gem_wsim.c @@ -0,0 +1,1014 @@ +/* + * Copyright © 2017 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMIT
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Use discardable buffers for rings
On Thu, Apr 20, 2017 at 10:49:37AM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Use discardable buffers for rings > URL : https://patchwork.freedesktop.org/series/23274/ > State : failure > > == Summary == > > Series 23274v1 drm/i915: Use discardable buffers for rings > https://patchwork.freedesktop.org/api/1.0/series/23274/revisions/1/mbox/ > > Test gem_exec_flush: > Subgroup basic-batch-kernel-default-uc: > pass -> FAIL (fi-snb-2600) fdo#17 > Test gem_exec_suspend: > Subgroup basic-s4-devices: > dmesg-warn -> PASS (fi-snb-2600) fdo#100125 > pass -> DMESG-WARN (fi-kbl-7560u) fdo#100125 > Test kms_cursor_legacy: > Subgroup basic-busy-flip-before-cursor-atomic: > pass -> FAIL (fi-snb-2600) > Test pm_rpm: > Subgroup basic-rte: > incomplete -> PASS (fi-bsw-n3050) fdo#100718 > > fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 > fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 > fdo#100718 https://bugs.freedesktop.org/show_bug.cgi?id=100718 Looks scarier than it actually was. Fixed my typos in the commitmsg and pushed. Thanks for the review, I thought we had been using internal for rings ever since we added the internal allocator (that was one of the intended use cases for the allocator). -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 v6 13/20] drm/i915/guc: Provide register list to be saved/restored during engine reset
On ke, 2017-04-19 at 11:35 -0700, Michel Thierry wrote: > From: Arun Siluvery > > GuC expects a list of registers from the driver which are saved/restored > during engine reset. The type of value to be saved is controlled by > flags. We provide a minimal set of registers that we want GuC to save and > restore. This is not an issue in case of engine reset as driver initializes > most of them following an engine reset, but in case of media reset (aka > watchdog reset) which is completely internal to GuC (including resubmission > of hung workload), it is necessary to provide this list, otherwise GuC won't > be able to schedule further workloads after a reset. This is the minimal > set of registers identified for things to work as expected but if we see > any new issues, this register list can be expanded. > > In order to not loose any existing workarounds, we have to let GuC know > the registers and its values. These will be reapplied after the reset. > Note that we can't just read the current value because most of these > registers are masked (so we have a workaround for a workaround for a > workaround). > > v2: REGSET_MASKED is too difficult for GuC, use REGSET_SAVE_DEFAULT_VALUE > and current value from RING_MODE reg instead; no need to preserve > head/tail either, be extra paranoid and save whitelisted registers (Daniele). > > v3: Workarounds added only once during _init_workarounds also have to > been restored, or we risk loosing them after internal GuC reset > (Daniele). > > Cc: Daniele Ceraolo Spurio > Signed-off-by: Arun Siluvery > Signed-off-by: Jeff McGee > Signed-off-by: Michel Thierry > @@ -732,15 +755,16 @@ static int gen9_init_workarounds(struct intel_engine_cs > *engine) > > int ret; > > /* WaConextSwitchWithConcurrentTLBInvalidate:skl,bxt,kbl,glk */ > - I915_WRITE(GEN9_CSFE_CHICKEN1_RCS, > _MASKED_BIT_ENABLE(GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE)); > + I915_GUC_REG_WRITE(GEN9_CSFE_CHICKEN1_RCS, > + > _MASKED_BIT_ENABLE(GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE)); To make grepping easier, how about? I915_WRITE(GUC_REG(GEN9_CSFE_CHICKEN1_RCS), ...); 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] ✗ Fi.CI.BAT: failure for drm/i915: Use discardable buffers for rings
== Series Details == Series: drm/i915: Use discardable buffers for rings URL : https://patchwork.freedesktop.org/series/23274/ State : failure == Summary == Series 23274v1 drm/i915: Use discardable buffers for rings https://patchwork.freedesktop.org/api/1.0/series/23274/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> FAIL (fi-snb-2600) fdo#17 Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-snb-2600) fdo#100125 pass -> DMESG-WARN (fi-kbl-7560u) fdo#100125 Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: pass -> FAIL (fi-snb-2600) Test pm_rpm: Subgroup basic-rte: incomplete -> PASS (fi-bsw-n3050) fdo#100718 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#100718 https://bugs.freedesktop.org/show_bug.cgi?id=100718 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:434s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:426s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:570s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:508s fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 time:550s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:497s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:477s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:411s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:410s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:429s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:495s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:486s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:459s fi-kbl-7560u total:278 pass:267 dwarn:1 dfail:0 fail:0 skip:10 time:567s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:454s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time:577s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:460s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:494s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:432s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:531s fi-snb-2600 total:278 pass:247 dwarn:0 dfail:0 fail:2 skip:29 time:400s 2fe165cbf4b2287276f03e607d17341119203d9d drm-tip: 2017y-04m-20d-09h-46m-54s UTC integration manifest 886e8ea drm/i915: Use discardable buffers for rings == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4524/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 03/13] lib/igt_aux: Include unistd.h for gettid() on Android
On Wed, Apr 19, 2017 at 05:23:46PM +0300, Jani Nikula wrote: > On Wed, 19 Apr 2017, Arkadiusz Hiler wrote: > > On Wed, Apr 19, 2017 at 03:22:19PM +0300, Jani Nikula wrote: > >> On Wed, 19 Apr 2017, Arkadiusz Hiler wrote: > >> > We define gettid() using syscall() because glibc does not provide a > >> > wrapper. > >> > > >> > Android's bionic got the syscall covered though. > >> > > >> > Signed-off-by: Arkadiusz Hiler > >> > --- > >> > lib/igt_aux.h | 5 + > >> > 1 file changed, 5 insertions(+) > >> > > >> > diff --git a/lib/igt_aux.h b/lib/igt_aux.h > >> > index e62858e..54b9716 100644 > >> > --- a/lib/igt_aux.h > >> > +++ b/lib/igt_aux.h > >> > @@ -43,7 +43,12 @@ extern int num_trash_bos; > >> > #define NSEC_PER_SEC (1000*USEC_PER_SEC) > >> > > >> > /* signal interrupt helpers */ > >> > +#ifdef ANDROID > >> > >> Seems like this should be something like HAVE_GETTID, defined by > >> configure or by android makefiles? > > > > Yeah, but that's not that easy (yet) and that's not the only area which > > would use it - notice the thing with cairo from the cover letter. > > > > config.h is generated in a ugly way for Android - lib/Android.mk does > > that. Also if you ./configure it stops compiling for Android causing > > confusing error. > > > > Whole area could use some heavy reworking. > > > > One approach would be to mimic what other projects do: > > > > * have config_android.h with set of sane #defines (as environment is > >more static and there is no ac/am) > > > > * don't define HAVE_CONFIG_H and just `-include config_android.h` on... > >Android > > > > * add gettid() discovery via ac for Linux (I don't think that any > >libc other than bionic wraps that call though) > > > > > > But that would made a whole series. > > I would like to go with #ifdef ANDROID for now. > > Fair enough. > > It's just that I cringe seeing #ifdef instead of #ifdef > , when and are not interchangeable or > 1:1. For example, glibc might include gettid later. > > BR, > Jani. I completetly get that, I had mixed feeling adding the ifdef. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use discardable buffers for rings
On to, 2017-04-20 at 11:17 +0100, Chris Wilson wrote: > The contents of a ring are only valid between HEAD and TAIL, when the > ring is idle (HEAD == TAIL) we can simply let the pages go under memory > pressue if they are not pinned by an active context. And new content > will be written and so the ring will again be valid between HEAD and > TAIL, everything outside can be discarded. > > Note that we take care of ensuring that we do not reset the HEAD > backwards following a GPU hang on an idle ring. > > The same precautions are what enable us to use stolen memory for rings. > > Signed-off-by: Chris Wilson 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 i-g-t 08/13] benchmarks/Android.mk: Add gem_latency to skip list
On Wed, Apr 19, 2017 at 05:58:28PM +0100, Chris Wilson wrote: > On Wed, Apr 19, 2017 at 01:01:50PM +0200, Arkadiusz Hiler wrote: > > AOSP, as of this commit, does not include libdrm with fence defines. > > Pushed local defines that should keep the benchmark happy. > > Please do reset the configure libdrm requirements to what is available > on min(Android, debian stable). They should be our compile targets. > -Chris Series rebased (sans this patch) cleanly on current master. Everything compiles just fine :-) Thanks! -- Cheers, Arek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Use discardable buffers for rings
The contents of a ring are only valid between HEAD and TAIL, when the ring is idle (HEAD == TAIL) we can simply let the pages go under memory pressue if they are not pinned by an active context. And new content will be written and so the ring will again be valid between HEAD and TAIL, everything outside can be discarded. Note that we take care of ensuring that we do not reset the HEAD backwards following a GPU hang on an idle ring. The same precautions are what enable us to use stolen memory for rings. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 7d2e5df61028..0cfffc9b4e8f 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -1165,7 +1165,7 @@ intel_ring_create_vma(struct drm_i915_private *dev_priv, int size) obj = i915_gem_object_create_stolen(dev_priv, size); if (!obj) - obj = i915_gem_object_create(dev_priv, size); + obj = i915_gem_object_create_internal(dev_priv, size); if (IS_ERR(obj)) return ERR_CAST(obj); -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [i-g-t PATCH v4 1/2] lib/igt_kms: Add support for 4K and audio HDMI EDID injection.
On 19.04.2017 11:13, Petri Latvala wrote: > > The only Intel-specific part I can spot is that one chunk where you > check for at-least-hsw. Is that so you can properly report skip > instead of fail? It would be good to make this all suitable for > non-Intel hw. > That is meant to report skip on hardware before HSW - those can't properly handle 4K anyway. I'm not sure how other older non-intel HW handles 4K though. > > Anyway, series is > > Reviewed-by: Petri Latvala > > Thanks, pushed! > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 14/20] drm/i915/guc: Add support for reset engine using GuC commands
On Wed, Apr 19, 2017 at 04:22:43PM -0700, Michel Thierry wrote: > On 19/04/17 03:27, Chris Wilson wrote: > >On Tue, Apr 18, 2017 at 01:23:29PM -0700, Michel Thierry wrote: > >>This patch adds per engine reset and recovery (TDR) support when GuC is > >>used to submit workloads to GPU. > >> > >>In the case of i915 directly submission to ELSP, driver manages hang > >>detection, recovery and resubmission. With GuC submission these tasks > >>are shared between driver and GuC. i915 is still responsible for detecting > >>a hang, and when it does it only requests GuC to reset that Engine. GuC > >>internally manages acquiring forcewake and idling the engine before actually > >>resetting it. > >> > >>Once the reset is successful, i915 takes over again and handles > >>resubmission. > >>The scheduler in i915 knows which requests are pending so after resetting > >>a engine, pending workloads/requests are resubmitted again. > >> > >>v2: s/i915_guc_request_engine_reset/i915_guc_reset_engine/ to match the > >>non-guc funtion names. > >> > >>Signed-off-by: Arun Siluvery > >>Signed-off-by: Jeff McGee > >>Signed-off-by: Michel Thierry > >>--- > >>diff --git a/drivers/gpu/drm/i915/intel_lrc.c > >>b/drivers/gpu/drm/i915/intel_lrc.c > >>index 7df278fe492e..6295760098a1 100644 > >>--- a/drivers/gpu/drm/i915/intel_lrc.c > >>+++ b/drivers/gpu/drm/i915/intel_lrc.c > >>@@ -1176,14 +1176,15 @@ static int gen8_init_common_ring(struct > >>intel_engine_cs *engine) > >> > >>/* After a GPU reset, we may have requests to replay */ > >>clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted); > >>- if (!i915.enable_guc_submission && !execlists_elsp_idle(engine)) { > >>+ if (!execlists_elsp_idle(engine)) { > >>DRM_DEBUG_DRIVER("Restarting %s from requests [0x%x, 0x%x]\n", > >> engine->name, > >> port_seqno(&engine->execlist_port[0]), > >> port_seqno(&engine->execlist_port[1])); > >>engine->execlist_port[0].count = 0; > >>engine->execlist_port[1].count = 0; > >>- execlists_submit_ports(engine); > >>+ if (!dev_priv->guc.execbuf_client) > >>+ execlists_submit_ports(engine); > > > >Not sure what you were intending to do here as this only resets the > >submission count -- which is not used by guc dequeue. Some merit in the > >making the code look similar, certainly adds the dbg message but I think > >it is unrelated to the rest of the patch. > > Yes, it only keeps the same debug message (originally added to check > it was taking the right path). I can remove if you think it doesn't > provide anything useful. Just a small patch by itself, it is only a distraction to the larger patch. -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 14/27] drm/i915: Don't mark an execlists context-switch when idle
On ke, 2017-04-19 at 10:41 +0100, Chris Wilson wrote: > If we *know* that the engine is idle, i.e. we have not more contexts in > lift, we can skip any spurious CSB idle interrupts. These spurious in flight? > interrupts seem to arrive long after we assert that the engines are > completely idle, triggering later assertions: > > [ 178.896646] intel_engine_is_idle(bcs): interrupt not handled, irq_posted=2 > [ 178.896655] [ cut here ] > [ 178.896658] kernel BUG at drivers/gpu/drm/i915/intel_engine_cs.c:226! > [ 178.896661] invalid opcode: [#1] SMP > [ 178.896663] Modules linked in: i915(E) x86_pkg_temp_thermal(E) > crct10dif_pclmul(E) crc32_pclmul(E) crc32c_intel(E) ghash_clmulni_intel(E) > nls_ascii(E) nls_cp437(E) vfat(E) fat(E) intel_gtt(E) i2c_algo_bit(E) > drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) fb_sys_fops(E) > aesni_intel(E) prime_numbers(E) evdev(E) aes_x86_64(E) drm(E) crypto_simd(E) > cryptd(E) glue_helper(E) mei_me(E) mei(E) lpc_ich(E) efivars(E) mfd_core(E) > battery(E) video(E) acpi_pad(E) button(E) tpm_tis(E) tpm_tis_core(E) tpm(E) > autofs4(E) i2c_i801(E) fan(E) thermal(E) i2c_designware_platform(E) > i2c_designware_core(E) > [ 178.896694] CPU: 1 PID: 522 Comm: gem_exec_whispe Tainted: GE > 4.11.0-rc5+ #14 > [ 178.896702] task: 88040aba8d40 task.stack: c93f > [ 178.896722] RIP: 0010:intel_engine_init_global_seqno+0x1db/0x1f0 [i915] > [ 178.896725] RSP: 0018:c93f3ab0 EFLAGS: 00010246 > [ 178.896728] RAX: RBX: 88040af54000 RCX: > > [ 178.896731] RDX: 88041ec933e0 RSI: 88041ec8cc48 RDI: > 88041ec8cc48 > [ 178.896734] RBP: c93f3ac8 R08: R09: > 047d > [ 178.896736] R10: 0040 R11: 88040b344f80 R12: > > [ 178.896739] R13: 88040bce R14: 88040bce52d8 R15: > 88040bce > [ 178.896742] FS: 7f22d8c0() GS:88041ec8() > knlGS: > [ 178.896746] CS: 0010 DS: ES: CR0: 80050033 > [ 178.896749] CR2: 7f41ddd8f000 CR3: 00040bb03000 CR4: > 001406e0 > [ 178.896752] Call Trace: > [ 178.896768] reset_all_global_seqno.part.33+0x4e/0xd0 [i915] > [ 178.896782] i915_gem_request_alloc+0x304/0x330 [i915] > [ 178.896795] i915_gem_do_execbuffer+0x8a1/0x17d0 [i915] > [ 178.896799] ? remove_wait_queue+0x48/0x50 > [ 178.896812] ? i915_wait_request+0x300/0x590 [i915] > [ 178.896816] ? wake_up_q+0x70/0x70 > [ 178.896819] ? refcount_dec_and_test+0x11/0x20 > [ 178.896823] ? reservation_object_add_excl_fence+0xa5/0x100 > [ 178.896835] i915_gem_execbuffer2+0xab/0x1f0 [i915] > [ 178.896844] drm_ioctl+0x1e6/0x460 [drm] > [ 178.896858] ? i915_gem_execbuffer+0x260/0x260 [i915] > [ 178.896862] ? dput+0xcf/0x250 > [ 178.896866] ? full_proxy_release+0x66/0x80 > [ 178.896869] ? mntput+0x1f/0x30 > [ 178.896872] do_vfs_ioctl+0x8f/0x5b0 > [ 178.896875] ? fput+0x9/0x10 > [ 178.896878] ? task_work_run+0x80/0xa0 > [ 178.896881] SyS_ioctl+0x3c/0x70 > [ 178.896885] entry_SYSCALL_64_fastpath+0x17/0x98 > [ 178.896888] RIP: 0033:0x7f2ccb455ca7 > [ 178.896890] RSP: 002b:7ffcabec72d8 EFLAGS: 0246 ORIG_RAX: > 0010 > [ 178.896894] RAX: ffda RBX: 55f897a44b90 RCX: > 7f2ccb455ca7 > [ 178.896897] RDX: 7ffcabec74a0 RSI: 40406469 RDI: > 0003 > [ 178.896900] RBP: 7f2ccb70a440 R08: 7f2ccb70d0a4 R09: > > [ 178.896903] R10: R11: 0246 R12: > > [ 178.896905] R13: 55f89782d71a R14: 7ffcabecf838 R15: > 0003 > [ 178.896908] Code: 00 31 d2 4c 89 ef 8d 70 48 41 ff 95 f8 06 00 00 e9 68 fe > ff ff be 0f 00 00 00 48 c7 c7 48 dc 37 a0 e8 fa 33 d6 e0 e9 0b ff ff ff <0f> > 0b 0f 0b 0f 0b 0f 0b 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 > > On the other hand, by ignoring the interrupt do we risk running out of > space in CSB ring? Testing for a few hours suggests not, i.e. that we > only seem to get the odd delayed CSB idle notification. > > Signed-off-by: Chris Wilson > Cc: Tvrtko Ursulin Slap your Tested-by too. Reviewed-by: Joonas Lahtinen Even with that, I dislike the port_count macro. 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 v6 18/20] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout
On Wed, Apr 19, 2017 at 06:09:00PM -0700, Michel Thierry wrote: > This patch is missing: > > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c > b/drivers/gpu/drm/i915/i915_gem_context.c > index c1013af0b910..a8bdea43a217 100644 > --- a/drivers/gpu/drm/i915/i915_gem_context.c > +++ b/drivers/gpu/drm/i915/i915_gem_context.c > @@ -1135,7 +1135,7 @@ int i915_gem_context_getparam_ioctl(struct > drm_device *dev, void *data, > return PTR_ERR(ctx); > } > > - args->size = 0; > + args->size = (args->param != I915_CONTEXT_PARAM_WATCHDOG) ? 0 : > args->size; > switch (args->param) { > case I915_CONTEXT_PARAM_BAN_PERIOD: > ret = -EINVAL; > > Or there will be no way to get the current thresholds (chunk was > missed due to some TRTT code nearby). I'll be sure to include it in > the next version. No. It is always preset to 0. The PARAM should set it to the actual struct size (it would write) and *not* the user's size. -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 22/27] drm/i915: Eliminate lots of iterations over the execobjects array
On ke, 2017-04-19 at 10:41 +0100, Chris Wilson wrote: > The major scaling bottleneck in execbuffer is the processing of the > execobjects. Creating an auxiliary list is inefficient when compared to > using the execobject array we already have allocated. > > Reservation is then split into phases. As we lookup up the VMA, we > try and bind it back into active location. Only if that fails, do we add > it to the unbound list for phase 2. In phase 2, we try and add all those > objects that could not fit into their previous location, with fallback > to retrying all objects and evicting the VM in case of severe > fragmentation. (This is the same as before, except that phase 1 is now > done inline with looking up the VMA to avoid an iteration over the > execobject array. In the ideal case, we eliminate the separate reservation > phase). During the reservation phase, we only evict from the VM between > passes (rather than currently as we try to fit every new VMA). In > testing with Unreal Engine's Atlantis demo which stresses the eviction > logic on gen7 class hardware, this speed up the framerate by a factor of > 2. > > The second loop amalgamation is between move_to_gpu and move_to_active. > As we always submit the request, even if incomplete, we can use the > current request to track active VMA as we perform the flushes and > synchronisation required. > > The next big advancement is to avoid copying back to the user any > execobjects and relocations that are not changed. > > v2: Add a Theory of Operation spiel. > v3: Fall back to slow relocations in preparation for flushing userptrs. > v4: Document struct members, factor out eb_validate_vma(), add a few > more comments to explain some magic and hide other magic behind macros. > > Signed-off-by: Chris Wilson Changelog checks out. Assuming you peeked at the generated html docs: 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 v4 6/9] drm/i915: Convert intel_dp properties to atomic.
On 19-04-17 17:53, Daniel Vetter wrote: > On Wed, Apr 12, 2017 at 12:50:04PM +0200, Maarten Lankhorst wrote: >> intel_dp supports 3 properties, scaling mode, broadcast rgb and >> force_audio. intel_digital_connector handles the plumbing, >> so we only have to hook this up in compute_config and init. >> >> Signed-off-by: Maarten Lankhorst >> --- >> drivers/gpu/drm/i915/intel_dp.c | 136 >> +++ >> drivers/gpu/drm/i915/intel_drv.h | 3 - >> 2 files changed, 24 insertions(+), 115 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c >> b/drivers/gpu/drm/i915/intel_dp.c >> index b1a0cb3c79d4..f976d10b4f0a 100644 >> --- a/drivers/gpu/drm/i915/intel_dp.c >> +++ b/drivers/gpu/drm/i915/intel_dp.c >> @@ -1630,6 +1630,8 @@ intel_dp_compute_config(struct intel_encoder *encoder, >> enum port port = dp_to_dig_port(intel_dp)->port; >> struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc); >> struct intel_connector *intel_connector = intel_dp->attached_connector; >> +struct intel_digital_connector_state *intel_conn_state = >> +to_intel_digital_connector_state(conn_state); >> int lane_count, clock; >> int min_lane_count = 1; >> int max_lane_count = intel_dp_max_lane_count(intel_dp); >> @@ -1655,10 +1657,10 @@ intel_dp_compute_config(struct intel_encoder >> *encoder, >> pipe_config->has_drrs = false; >> if (port == PORT_A) >> pipe_config->has_audio = false; >> -else if (intel_dp->force_audio == HDMI_AUDIO_AUTO) >> +else if (intel_conn_state->force_audio == HDMI_AUDIO_AUTO) >> pipe_config->has_audio = intel_dp->has_audio; >> else >> -pipe_config->has_audio = intel_dp->force_audio == HDMI_AUDIO_ON; >> +pipe_config->has_audio = intel_conn_state->force_audio == >> HDMI_AUDIO_ON; >> >> if (is_edp(intel_dp) && intel_connector->panel.fixed_mode) { >> intel_fixed_panel_mode(intel_connector->panel.fixed_mode, >> @@ -1673,10 +1675,10 @@ intel_dp_compute_config(struct intel_encoder >> *encoder, >> >> if (HAS_GMCH_DISPLAY(dev_priv)) >> intel_gmch_panel_fitting(intel_crtc, pipe_config, >> - >> intel_connector->panel.fitting_mode); >> + conn_state->scaling_mode); >> else >> intel_pch_panel_fitting(intel_crtc, pipe_config, >> - >> intel_connector->panel.fitting_mode); >> +conn_state->scaling_mode); >> } >> >> if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK) >> @@ -1745,7 +1747,7 @@ intel_dp_compute_config(struct intel_encoder *encoder, >> return false; >> >> found: >> -if (intel_dp->color_range_auto) { >> +if (intel_conn_state->broadcast_rgb == INTEL_BROADCAST_RGB_AUTO) { >> /* >> * See: >> * CEA-861-E - 5.1 Default Encoding Parameters >> @@ -1757,7 +1759,7 @@ intel_dp_compute_config(struct intel_encoder *encoder, >> HDMI_QUANTIZATION_RANGE_LIMITED; >> } else { >> pipe_config->limited_color_range = >> -intel_dp->limited_color_range; >> +intel_conn_state->broadcast_rgb == >> INTEL_BROADCAST_RGB_LIMITED; >> } >> >> pipe_config->lane_count = lane_count; >> @@ -4781,104 +4783,6 @@ static int intel_dp_get_modes(struct drm_connector >> *connector) >> } >> >> static int >> -intel_dp_set_property(struct drm_connector *connector, >> - struct drm_property *property, >> - uint64_t val) >> -{ >> -struct drm_i915_private *dev_priv = to_i915(connector->dev); >> -struct intel_connector *intel_connector = to_intel_connector(connector); >> -struct intel_encoder *intel_encoder = intel_attached_encoder(connector); >> -struct intel_dp *intel_dp = enc_to_intel_dp(&intel_encoder->base); >> -int ret; >> - >> -ret = drm_object_property_set_value(&connector->base, property, val); >> -if (ret) >> -return ret; >> - >> -if (property == dev_priv->force_audio_property) { >> -int i = val; >> -bool has_audio, old_has_audio; >> -int old_force_audio = intel_dp->force_audio; >> - >> -if (i == intel_dp->force_audio) >> -return 0; >> - >> -if (old_force_audio == HDMI_AUDIO_AUTO) >> -old_has_audio = intel_dp->has_audio; >> -else >> -old_has_audio = old_force_audio; >> - >> -intel_dp->force_audio = i; >> - >> -if (i == HDMI_AUDIO_AUTO) >> -has_audio = intel_dp->has_audio; >> -else >> -has_audio = (i == HDMI_AUDIO_ON); >> - >> -if (has_audio == old_has_audio) >> -
Re: [Intel-gfx] [PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro
Hi All, On 2017-04-20 09:51, Daniel Vetter wrote: On Wed, Apr 19, 2017 at 01:36:10PM -0600, Logan Gunthorpe wrote: Seeing the kunmap_atomic dma_buf_ops share the same name with a macro in highmem.h, the former can be aliased if any dma-buf user includes that header. I'm personally trying to include highmem.h inside scatterlist.h and this breaks the dma-buf code proper. Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP. To maintain consistency I've renamed all four of kmap* and kunmap* to be map* and unmap*. (Even though only kmap_atomic presently conflicts.) [1] https://www.spinics.net/lists/target-devel/msg15070.html Signed-off-by: Logan Gunthorpe Reviewed-by: Sinclair Yeh Acked-by: Daniel Vetter Probably simplest if we pull this in through the drm-misc tree for 4.12. Can we have an ack for the v4l side for that pls? For the V4L2/videobuf2: Acked-by: Marek Szyprowski Thanks, Daniel --- Changes since v1: - Added the missing tegra driver (noticed by kbuild robot) - Rebased off of drm-intel-next to get the i915 selftest that is new - Fixed nits Sinclair pointed out. drivers/dma-buf/dma-buf.c | 16 drivers/gpu/drm/armada/armada_gem.c| 8 drivers/gpu/drm/drm_prime.c| 8 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 8 drivers/gpu/drm/i915/selftests/mock_dmabuf.c | 8 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 8 drivers/gpu/drm/tegra/gem.c| 8 drivers/gpu/drm/udl/udl_dmabuf.c | 8 drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 8 drivers/media/v4l2-core/videobuf2-dma-contig.c | 4 ++-- drivers/media/v4l2-core/videobuf2-dma-sg.c | 4 ++-- drivers/media/v4l2-core/videobuf2-vmalloc.c| 4 ++-- drivers/staging/android/ion/ion.c | 8 include/linux/dma-buf.h| 22 +++--- 14 files changed, 61 insertions(+), 61 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index f72aaac..512bdbc 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -405,8 +405,8 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) || !exp_info->ops->map_dma_buf || !exp_info->ops->unmap_dma_buf || !exp_info->ops->release - || !exp_info->ops->kmap_atomic - || !exp_info->ops->kmap + || !exp_info->ops->map_atomic + || !exp_info->ops->map || !exp_info->ops->mmap)) { return ERR_PTR(-EINVAL); } @@ -872,7 +872,7 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, unsigned long page_num) { WARN_ON(!dmabuf); - return dmabuf->ops->kmap_atomic(dmabuf, page_num); + return dmabuf->ops->map_atomic(dmabuf, page_num); } EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic); @@ -889,8 +889,8 @@ void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, unsigned long page_num, { WARN_ON(!dmabuf); - if (dmabuf->ops->kunmap_atomic) - dmabuf->ops->kunmap_atomic(dmabuf, page_num, vaddr); + if (dmabuf->ops->unmap_atomic) + dmabuf->ops->unmap_atomic(dmabuf, page_num, vaddr); } EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic); @@ -907,7 +907,7 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long page_num) { WARN_ON(!dmabuf); - return dmabuf->ops->kmap(dmabuf, page_num); + return dmabuf->ops->map(dmabuf, page_num); } EXPORT_SYMBOL_GPL(dma_buf_kmap); @@ -924,8 +924,8 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long page_num, { WARN_ON(!dmabuf); - if (dmabuf->ops->kunmap) - dmabuf->ops->kunmap(dmabuf, page_num, vaddr); + if (dmabuf->ops->unmap) + dmabuf->ops->unmap(dmabuf, page_num, vaddr); } EXPORT_SYMBOL_GPL(dma_buf_kunmap); diff --git a/drivers/gpu/drm/armada/armada_gem.c b/drivers/gpu/drm/armada/armada_gem.c index 1597458..d6c2a5d 100644 --- a/drivers/gpu/drm/armada/armada_gem.c +++ b/drivers/gpu/drm/armada/armada_gem.c @@ -529,10 +529,10 @@ static const struct dma_buf_ops armada_gem_prime_dmabuf_ops = { .map_dma_buf= armada_gem_prime_map_dma_buf, .unmap_dma_buf = armada_gem_prime_unmap_dma_buf, .release= drm_gem_dmabuf_release, - .kmap_atomic= armada_gem_dmabuf_no_kmap, - .kunmap_atomic = armada_gem_dmabuf_no_kunmap, - .kmap = armada_gem_dmabuf_no_kmap, - .kunmap = armada_gem_dmabuf_no_kunmap, + .map_atomic = armada_gem_dmabuf_no_kmap, + .unmap_atomic = armada_gem_dmabuf_no_kunmap, + .map= armada_gem_dmabuf_no_kmap, + .unmap = armada_gem_dmabuf_no_kunmap,
[Intel-gfx] [i-g-t PATCH 2/4] igt/igt_core: Provide an option to check for the log buffer contents
Signed-off-by: Abdiel Janulgue --- lib/igt_core.c | 24 lib/igt_core.h | 3 +++ 2 files changed, 27 insertions(+) diff --git a/lib/igt_core.c b/lib/igt_core.c index 8a7ba0d..e80a32a 100644 --- a/lib/igt_core.c +++ b/lib/igt_core.c @@ -329,6 +329,30 @@ static void _igt_log_buffer_dump(void) pthread_mutex_unlock(&log_buffer_mutex); } +/** + * igt_log_buffer_inspect: + * + * Provides a way to replay the internal igt log buffer for inspection. + * @check: A user-specified handler that gets invoked for each line of + the log buffer. The handler should return true to stop + inspecting the rest of the buffer. + * @data: passed as a user argument to the inspection function. + */ +void igt_log_buffer_inspect(igt_buffer_log_handler_t check, void *data) +{ + uint8_t i; + pthread_mutex_lock(&log_buffer_mutex); + + i = log_buffer.start; + do { + if (check(log_buffer.entries[i], data)) + break; + i++; + } while (i != log_buffer.start && i != log_buffer.end); + + pthread_mutex_unlock(&log_buffer_mutex); +} + __attribute__((format(printf, 1, 2))) static void kmsg(const char *format, ...) #define KERN_EMER "<0>" diff --git a/lib/igt_core.h b/lib/igt_core.h index 6d4cf60..3e0d3c3 100644 --- a/lib/igt_core.h +++ b/lib/igt_core.h @@ -817,6 +817,9 @@ void igt_vlog(const char *domain, enum igt_log_level level, const char *format, */ #define igt_critical(f...) igt_log(IGT_LOG_DOMAIN, IGT_LOG_CRITICAL, f) +typedef bool (*igt_buffer_log_handler_t)(const char *line, void *data); +void igt_log_buffer_inspect(igt_buffer_log_handler_t check, void *data); + extern enum igt_log_level igt_log_level; /** -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [i-g-t PATCH 3/4] lib/igt_debugfs: Add helper to return path to device.
Signed-off-by: Abdiel Janulgue --- lib/igt_debugfs.c | 26 ++ lib/igt_debugfs.h | 1 + 2 files changed, 27 insertions(+) diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c index 7584be5..b019c3b 100644 --- a/lib/igt_debugfs.c +++ b/lib/igt_debugfs.c @@ -22,6 +22,9 @@ * */ +#ifndef ANDROID +#define _GNU_SOURCE +#endif #include #include #include @@ -198,6 +201,29 @@ int igt_debugfs_dir(int device) igt_debug("Opening debugfs directory '%s'\n", path); return open(path, O_RDONLY); } +\ +/** + * igt_debugfs_path: + * @device: fd of the device + * + * Returns: + * The path to the debugfs directory corresponding to device + */ +const char *igt_debugfs_path(int device) +{ + char *path = 0; + + if (!path) { + char *linkname; + int debugfs; + igt_assert((debugfs = igt_debugfs_dir(device)) != -1); + igt_assert(path = calloc(PATH_MAX, sizeof(char))); + igt_assert(asprintf(&linkname, "/proc/self/fd/%d", debugfs) != -1); + igt_assert(readlink(linkname, path, PATH_MAX * sizeof(char)) != -1); + } + + return path; +} /** * igt_debugfs_open: diff --git a/lib/igt_debugfs.h b/lib/igt_debugfs.h index 7b846a8..76cf409 100644 --- a/lib/igt_debugfs.h +++ b/lib/igt_debugfs.h @@ -204,5 +204,6 @@ void igt_enable_prefault(void); */ int igt_get_stable_obj_count(int driver); void igt_debugfs_dump(int device, const char *filename); +const char *igt_debugfs_path(int device); #endif /* __IGT_DEBUGFS_H__ */ -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [i-g-t PATCH 1/4] lib/igt_core: Add igt_exec helpers
Support executing external processes with the goal of capturing its standard streams to the igt logging infrastructure in addition to its exit status. Cc: Daniel Vetter Cc: Petri Latvala Signed-off-by: Abdiel Janulgue --- lib/igt_core.c | 151 + lib/igt_core.h | 3 ++ 2 files changed, 154 insertions(+) diff --git a/lib/igt_core.c b/lib/igt_core.c index 403b942..8a7ba0d 100644 --- a/lib/igt_core.c +++ b/lib/igt_core.c @@ -2073,3 +2073,154 @@ FILE *__igt_fopen_data(const char* igt_srcdir, const char* igt_datadir, return fp; } + +struct output_pipe { + int output_fd; + int save_fd; + int read_fd; + int write_fd; + bool redirected; + enum igt_log_level log_level; +}; + +static bool redirect_output(struct output_pipe *p, int output_fd, + enum igt_log_level level) +{ + int fds[2], flags; + + if (pipe(fds) == -1) + return false; + + if ((flags = fcntl(fds[0], F_GETFL) == -1)) + return false; + + flags |= O_NONBLOCK; + if (fcntl(fds[0], F_SETFL, flags) == -1) + return false; + + /* save output */ + if ((p->save_fd = dup(output_fd)) == -1) + return false; + + /* Redirect output to our buffer */ + if (dup2(fds[1], output_fd) == -1) + return false; + + p->output_fd = output_fd; + p->read_fd = fds[0]; + p->write_fd = fds[1]; + p->redirected = true; + p->log_level = level; + + return true; +} + +static bool unredirect_output(struct output_pipe *p) +{ + close(p->write_fd); + if (dup2(p->save_fd, p->output_fd) == -1) + return false; + close(p->save_fd); + + p->redirected = false; + + return true; +} + +/** + * igt_exec: + * + * Executes the shell command specified in @command and capture its stdout and + * stderr to igt_log or igt_warn respectively. + * + * Returns: The exit status of the executed process. -1 for failure. + */ +int igt_exec(const char *command) +{ +#define OUT 0 +#define ERR 1 + struct output_pipe op[2]; + int i, sel_fd, status; + fd_set fds; + struct timeval timeout = { .tv_sec = 0, .tv_usec = 0 }; + char buf[PIPE_BUF]; + + if (!redirect_output(&op[OUT], STDOUT_FILENO, IGT_LOG_INFO)) + return -1; + if (!redirect_output(&op[ERR], STDERR_FILENO, IGT_LOG_WARN)) + return -1; + + if ((status = system(command)) == -1) + return -1; + + FD_ZERO(&fds); + FD_SET(op[OUT].read_fd, &fds); + FD_SET(op[ERR].read_fd, &fds); + + sel_fd = max(op[OUT].read_fd, op[ERR].read_fd); + if (select(sel_fd + 1, &fds, NULL, NULL, &timeout) == -1) + return -1; + + for (i = 0; i < ARRAY_SIZE(op); i++) { + struct output_pipe *current = &op[i]; + + if (!FD_ISSET(current->read_fd, &fds)) { + close(current->read_fd); + if (!unredirect_output(current)) + return -1; + continue; + } + + memset(buf, 0, sizeof(buf)); + while (read(current->read_fd, buf, sizeof(buf)) > 0) { + if (current->redirected) { + if (!unredirect_output(current)) + return -1; + } + igt_log(IGT_LOG_DOMAIN, current->log_level, + "[cmd] %s", buf); + memset(buf, 0, sizeof(buf)); + } + close(current->read_fd); + } + + return WEXITSTATUS(status); +} + +/** + * igt_exec_quiet: + * Similar to igt_exec(), except redirect output to /dev/null + * + * Returns: The exit status of the executed process. -1 for failure. + */ +int igt_exec_quiet(const char *command) +{ + int stderr_fd_copy, stdout_fd_copy, status, nullfd; + + /* redirect */ + if ((nullfd = open("/dev/null", O_WRONLY)) == -1) + return -1; + if ((stdout_fd_copy = dup(STDOUT_FILENO)) == -1) + return -1; + if ((stderr_fd_copy = dup(STDERR_FILENO)) == -1) + return -1; + + if (dup2(nullfd, STDOUT_FILENO) == -1) + return -1; + if (dup2(nullfd, STDERR_FILENO) == -1) + return -1; + + if ((status = system(command)) == -1) + return -1; + + /* restore */ + if (dup2(stdout_fd_copy, STDOUT_FILENO) == -1) + return -1; + if (dup2(stderr_fd_copy, STDERR_FILENO) == -1) + return -1; + + close(stdout_fd_copy); + close(stderr_fd_copy); + + return WEXITSTATUS(status); +} diff --git a/lib/igt_core.h b/lib/igt_core.h index 51b98d8..6d4cf60 100644 --- a/lib/igt_core.h +++ b/lib/igt_core.h @@ -91
[Intel-gfx] [i-g-t PATCH 4/4] Convert shell script tests to C version
Converted: - check_drm_clients (ensures no other clients are running. functionality provided by drm_open_driver_master). - debugfs_emon_crash - debugfs_wedged - drv_debugfs_reader - sysfs_l3_parity - test_rte_check (same as check_drm_clients) - tools_test - ZZ_check_dmesg Cc: Daniel Vetter Cc: Petri Latvala Signed-off-by: Abdiel Janulgue --- tests/Makefile.sources | 9 +--- tests/ZZ_check_dmesg | 11 - tests/check_drm_clients | 6 --- tests/debugfs.c | 75 tests/debugfs_emon_crash | 16 --- tests/debugfs_wedged | 10 - tests/drv_debugfs_reader | 9 tests/sysfs_l3_parity| 22 -- tests/test_rte_check | 6 --- tests/tools.c| 111 +++ tests/tools_test | 16 --- 11 files changed, 188 insertions(+), 103 deletions(-) delete mode 100755 tests/ZZ_check_dmesg delete mode 100755 tests/check_drm_clients create mode 100644 tests/debugfs.c delete mode 100755 tests/debugfs_emon_crash delete mode 100755 tests/debugfs_wedged delete mode 100755 tests/drv_debugfs_reader delete mode 100755 tests/sysfs_l3_parity delete mode 100755 tests/test_rte_check create mode 100644 tests/tools.c delete mode 100755 tests/tools_test diff --git a/tests/Makefile.sources b/tests/Makefile.sources index 7fa9b8f..089428d 100644 --- a/tests/Makefile.sources +++ b/tests/Makefile.sources @@ -234,6 +234,8 @@ TESTS_progs = \ drv_module_reload \ kms_sysfs_edid_timing \ perf \ + debugfs \ + tools \ $(NULL) # IMPORTANT: The ZZ_ tests need to be run last! @@ -242,11 +244,6 @@ TESTS_scripts_M = \ $(NULL) TESTS_scripts = \ - debugfs_emon_crash \ - drv_debugfs_reader \ - sysfs_l3_parity \ - test_rte_check \ - tools_test \ $(NULL) # This target contains testcases which support automagic subtest enumeration @@ -308,9 +305,7 @@ HANG = \ $(NULL) scripts = \ - check_drm_clients \ ddx_intel_after_fbdev \ - debugfs_wedged \ drm_lib.sh \ drm_getopt.sh \ $(NULL) diff --git a/tests/ZZ_check_dmesg b/tests/ZZ_check_dmesg deleted file mode 100755 index e28ba35..000 --- a/tests/ZZ_check_dmesg +++ /dev/null @@ -1,11 +0,0 @@ -#!/bin/sh - -if dmesg | grep '\*ERROR\*' > /dev/null ; then - echo "DRM_ERROR dirt in dmesg" - exit 1 -fi - -if dmesg | grep -- '--\[ cut here \]' > /dev/null ; then - echo "found a backtrace in dmesg" - exit 1 -fi diff --git a/tests/check_drm_clients b/tests/check_drm_clients deleted file mode 100755 index 2a891b8..000 --- a/tests/check_drm_clients +++ /dev/null @@ -1,6 +0,0 @@ -#!/bin/bash - -SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )" -. $SOURCE_DIR/drm_lib.sh - -exit $IGT_EXIT_SUCCESS diff --git a/tests/debugfs.c b/tests/debugfs.c new file mode 100644 index 000..2e2f9bb --- /dev/null +++ b/tests/debugfs.c @@ -0,0 +1,75 @@ +/* + * Copyright © 2017 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS + * IN THE SOFTWARE. + */ +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif +#include "igt.h" + +igt_main +{ + int fd = -1; + igt_skip_on_simulation(); + + igt_fixture { + fd = drm_open_driver_master(DRIVER_INTEL); + igt_require_gem(fd); + } + + igt_subtest_group { + igt_subtest("debugfs_emon_crash") { + int i; + char *cmd; + igt_assert(asprintf(&cmd, "cat %s/i915_emon_status", + igt_debugfs_path(fd)) != -1); + + for (i = 0; i < 1000; i++) + igt_exec_quiet(cmd); + + free(cmd); + } + + igt_subtest("debugfs_wedged") { +
Re: [Intel-gfx] [PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro
Hi Marek, Thanks! On 20 April 2017 at 13:36, Marek Szyprowski wrote: > Hi All, > > On 2017-04-20 09:51, Daniel Vetter wrote: >> >> On Wed, Apr 19, 2017 at 01:36:10PM -0600, Logan Gunthorpe wrote: >>> >>> Seeing the kunmap_atomic dma_buf_ops share the same name with a macro >>> in highmem.h, the former can be aliased if any dma-buf user includes >>> that header. >>> >>> I'm personally trying to include highmem.h inside scatterlist.h and this >>> breaks the dma-buf code proper. >>> >>> Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP. >>> >>> To maintain consistency I've renamed all four of kmap* and kunmap* to be >>> map* and unmap*. (Even though only kmap_atomic presently conflicts.) >>> >>> [1] https://www.spinics.net/lists/target-devel/msg15070.html >>> >>> Signed-off-by: Logan Gunthorpe >>> Reviewed-by: Sinclair Yeh >> >> Acked-by: Daniel Vetter >> >> Probably simplest if we pull this in through the drm-misc tree for 4.12. >> Can we have an ack for the v4l side for that pls? > > > For the V4L2/videobuf2: > Acked-by: Marek Szyprowski > I will queue it up for drm-misc-fixes so it gets into 4.12. > > >> Thanks, Daniel Best, Sumit. >>> >>> --- >>> >>> Changes since v1: >>> >>> - Added the missing tegra driver (noticed by kbuild robot) >>> - Rebased off of drm-intel-next to get the i915 selftest that is new >>> - Fixed nits Sinclair pointed out. >>> >>> drivers/dma-buf/dma-buf.c | 16 >>> drivers/gpu/drm/armada/armada_gem.c| 8 >>> drivers/gpu/drm/drm_prime.c| 8 >>> drivers/gpu/drm/i915/i915_gem_dmabuf.c | 8 >>> drivers/gpu/drm/i915/selftests/mock_dmabuf.c | 8 >>> drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 8 >>> drivers/gpu/drm/tegra/gem.c| 8 >>> drivers/gpu/drm/udl/udl_dmabuf.c | 8 >>> drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 8 >>> drivers/media/v4l2-core/videobuf2-dma-contig.c | 4 ++-- >>> drivers/media/v4l2-core/videobuf2-dma-sg.c | 4 ++-- >>> drivers/media/v4l2-core/videobuf2-vmalloc.c| 4 ++-- >>> drivers/staging/android/ion/ion.c | 8 >>> include/linux/dma-buf.h| 22 >>> +++--- >>> 14 files changed, 61 insertions(+), 61 deletions(-) >>> >>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c >>> index f72aaac..512bdbc 100644 >>> --- a/drivers/dma-buf/dma-buf.c >>> +++ b/drivers/dma-buf/dma-buf.c >>> @@ -405,8 +405,8 @@ struct dma_buf *dma_buf_export(const struct >>> dma_buf_export_info *exp_info) >>> || !exp_info->ops->map_dma_buf >>> || !exp_info->ops->unmap_dma_buf >>> || !exp_info->ops->release >>> - || !exp_info->ops->kmap_atomic >>> - || !exp_info->ops->kmap >>> + || !exp_info->ops->map_atomic >>> + || !exp_info->ops->map >>> || !exp_info->ops->mmap)) { >>> return ERR_PTR(-EINVAL); >>> } >>> @@ -872,7 +872,7 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, >>> unsigned long page_num) >>> { >>> WARN_ON(!dmabuf); >>> >>> - return dmabuf->ops->kmap_atomic(dmabuf, page_num); >>> + return dmabuf->ops->map_atomic(dmabuf, page_num); >>> } >>> EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic); >>> >>> @@ -889,8 +889,8 @@ void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, >>> unsigned long page_num, >>> { >>> WARN_ON(!dmabuf); >>> >>> - if (dmabuf->ops->kunmap_atomic) >>> - dmabuf->ops->kunmap_atomic(dmabuf, page_num, vaddr); >>> + if (dmabuf->ops->unmap_atomic) >>> + dmabuf->ops->unmap_atomic(dmabuf, page_num, vaddr); >>> } >>> EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic); >>> >>> @@ -907,7 +907,7 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned >>> long page_num) >>> { >>> WARN_ON(!dmabuf); >>> >>> - return dmabuf->ops->kmap(dmabuf, page_num); >>> + return dmabuf->ops->map(dmabuf, page_num); >>> } >>> EXPORT_SYMBOL_GPL(dma_buf_kmap); >>> >>> @@ -924,8 +924,8 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned >>> long page_num, >>> { >>> WARN_ON(!dmabuf); >>> >>> - if (dmabuf->ops->kunmap) >>> - dmabuf->ops->kunmap(dmabuf, page_num, vaddr); >>> + if (dmabuf->ops->unmap) >>> + dmabuf->ops->unmap(dmabuf, page_num, vaddr); >>> } >>> EXPORT_SYMBOL_GPL(dma_buf_kunmap); >>> >>> diff --git a/drivers/gpu/drm/armada/armada_gem.c >>> b/drivers/gpu/drm/armada/armada_gem.c >>> index 1597458..d6c2a5d 100644 >>> --- a/drivers/gpu/drm/armada/armada_gem.c >>> +++ b/drivers/gpu/drm/armada/armada_gem.c >>> @@ -529,10 +529,10 @@ static const struct dma_buf_ops >>> armada_gem_prime_dmabuf_ops = { >>>
Re: [Intel-gfx] [PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro
Hi Logan, Thanks for the patch. On 20 April 2017 at 13:21, Daniel Vetter wrote: > On Wed, Apr 19, 2017 at 01:36:10PM -0600, Logan Gunthorpe wrote: >> Seeing the kunmap_atomic dma_buf_ops share the same name with a macro >> in highmem.h, the former can be aliased if any dma-buf user includes >> that header. >> >> I'm personally trying to include highmem.h inside scatterlist.h and this >> breaks the dma-buf code proper. >> >> Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP. >> >> To maintain consistency I've renamed all four of kmap* and kunmap* to be >> map* and unmap*. (Even though only kmap_atomic presently conflicts.) >> >> [1] https://www.spinics.net/lists/target-devel/msg15070.html >> >> Signed-off-by: Logan Gunthorpe >> Reviewed-by: Sinclair Yeh > > Acked-by: Daniel Vetter Acked-by: Sumit Semwal > > Probably simplest if we pull this in through the drm-misc tree for 4.12. > Can we have an ack for the v4l side for that pls? > > Thanks, Daniel > >> --- >> >> Changes since v1: >> >> - Added the missing tegra driver (noticed by kbuild robot) >> - Rebased off of drm-intel-next to get the i915 selftest that is new >> - Fixed nits Sinclair pointed out. >> >> drivers/dma-buf/dma-buf.c | 16 >> drivers/gpu/drm/armada/armada_gem.c| 8 >> drivers/gpu/drm/drm_prime.c| 8 >> drivers/gpu/drm/i915/i915_gem_dmabuf.c | 8 >> drivers/gpu/drm/i915/selftests/mock_dmabuf.c | 8 >> drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 8 >> drivers/gpu/drm/tegra/gem.c| 8 >> drivers/gpu/drm/udl/udl_dmabuf.c | 8 >> drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 8 >> drivers/media/v4l2-core/videobuf2-dma-contig.c | 4 ++-- >> drivers/media/v4l2-core/videobuf2-dma-sg.c | 4 ++-- >> drivers/media/v4l2-core/videobuf2-vmalloc.c| 4 ++-- >> drivers/staging/android/ion/ion.c | 8 >> include/linux/dma-buf.h| 22 +++--- >> 14 files changed, 61 insertions(+), 61 deletions(-) >> >> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c >> index f72aaac..512bdbc 100644 >> --- a/drivers/dma-buf/dma-buf.c >> +++ b/drivers/dma-buf/dma-buf.c >> @@ -405,8 +405,8 @@ struct dma_buf *dma_buf_export(const struct >> dma_buf_export_info *exp_info) >> || !exp_info->ops->map_dma_buf >> || !exp_info->ops->unmap_dma_buf >> || !exp_info->ops->release >> - || !exp_info->ops->kmap_atomic >> - || !exp_info->ops->kmap >> + || !exp_info->ops->map_atomic >> + || !exp_info->ops->map >> || !exp_info->ops->mmap)) { >> return ERR_PTR(-EINVAL); >> } >> @@ -872,7 +872,7 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, >> unsigned long page_num) >> { >> WARN_ON(!dmabuf); >> >> - return dmabuf->ops->kmap_atomic(dmabuf, page_num); >> + return dmabuf->ops->map_atomic(dmabuf, page_num); >> } >> EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic); >> >> @@ -889,8 +889,8 @@ void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, >> unsigned long page_num, >> { >> WARN_ON(!dmabuf); >> >> - if (dmabuf->ops->kunmap_atomic) >> - dmabuf->ops->kunmap_atomic(dmabuf, page_num, vaddr); >> + if (dmabuf->ops->unmap_atomic) >> + dmabuf->ops->unmap_atomic(dmabuf, page_num, vaddr); >> } >> EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic); >> >> @@ -907,7 +907,7 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long >> page_num) >> { >> WARN_ON(!dmabuf); >> >> - return dmabuf->ops->kmap(dmabuf, page_num); >> + return dmabuf->ops->map(dmabuf, page_num); >> } >> EXPORT_SYMBOL_GPL(dma_buf_kmap); >> >> @@ -924,8 +924,8 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned >> long page_num, >> { >> WARN_ON(!dmabuf); >> >> - if (dmabuf->ops->kunmap) >> - dmabuf->ops->kunmap(dmabuf, page_num, vaddr); >> + if (dmabuf->ops->unmap) >> + dmabuf->ops->unmap(dmabuf, page_num, vaddr); >> } >> EXPORT_SYMBOL_GPL(dma_buf_kunmap); >> >> diff --git a/drivers/gpu/drm/armada/armada_gem.c >> b/drivers/gpu/drm/armada/armada_gem.c >> index 1597458..d6c2a5d 100644 >> --- a/drivers/gpu/drm/armada/armada_gem.c >> +++ b/drivers/gpu/drm/armada/armada_gem.c >> @@ -529,10 +529,10 @@ static const struct dma_buf_ops >> armada_gem_prime_dmabuf_ops = { >> .map_dma_buf= armada_gem_prime_map_dma_buf, >> .unmap_dma_buf = armada_gem_prime_unmap_dma_buf, >> .release= drm_gem_dmabuf_release, >> - .kmap_atomic= armada_gem_dmabuf_no_kmap, >> - .kunmap_atomic = armada_gem_dmabuf_no_kunmap, >> - .kmap = armada_gem_dmabuf_no_kmap, >> - .kunmap = armad
Re: [Intel-gfx] [PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro
On Wed, Apr 19, 2017 at 01:36:10PM -0600, Logan Gunthorpe wrote: > Seeing the kunmap_atomic dma_buf_ops share the same name with a macro > in highmem.h, the former can be aliased if any dma-buf user includes > that header. > > I'm personally trying to include highmem.h inside scatterlist.h and this > breaks the dma-buf code proper. > > Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP. > > To maintain consistency I've renamed all four of kmap* and kunmap* to be > map* and unmap*. (Even though only kmap_atomic presently conflicts.) > > [1] https://www.spinics.net/lists/target-devel/msg15070.html > > Signed-off-by: Logan Gunthorpe > Reviewed-by: Sinclair Yeh Acked-by: Daniel Vetter Probably simplest if we pull this in through the drm-misc tree for 4.12. Can we have an ack for the v4l side for that pls? Thanks, Daniel > --- > > Changes since v1: > > - Added the missing tegra driver (noticed by kbuild robot) > - Rebased off of drm-intel-next to get the i915 selftest that is new > - Fixed nits Sinclair pointed out. > > drivers/dma-buf/dma-buf.c | 16 > drivers/gpu/drm/armada/armada_gem.c| 8 > drivers/gpu/drm/drm_prime.c| 8 > drivers/gpu/drm/i915/i915_gem_dmabuf.c | 8 > drivers/gpu/drm/i915/selftests/mock_dmabuf.c | 8 > drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 8 > drivers/gpu/drm/tegra/gem.c| 8 > drivers/gpu/drm/udl/udl_dmabuf.c | 8 > drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 8 > drivers/media/v4l2-core/videobuf2-dma-contig.c | 4 ++-- > drivers/media/v4l2-core/videobuf2-dma-sg.c | 4 ++-- > drivers/media/v4l2-core/videobuf2-vmalloc.c| 4 ++-- > drivers/staging/android/ion/ion.c | 8 > include/linux/dma-buf.h| 22 +++--- > 14 files changed, 61 insertions(+), 61 deletions(-) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index f72aaac..512bdbc 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -405,8 +405,8 @@ struct dma_buf *dma_buf_export(const struct > dma_buf_export_info *exp_info) > || !exp_info->ops->map_dma_buf > || !exp_info->ops->unmap_dma_buf > || !exp_info->ops->release > - || !exp_info->ops->kmap_atomic > - || !exp_info->ops->kmap > + || !exp_info->ops->map_atomic > + || !exp_info->ops->map > || !exp_info->ops->mmap)) { > return ERR_PTR(-EINVAL); > } > @@ -872,7 +872,7 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, > unsigned long page_num) > { > WARN_ON(!dmabuf); > > - return dmabuf->ops->kmap_atomic(dmabuf, page_num); > + return dmabuf->ops->map_atomic(dmabuf, page_num); > } > EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic); > > @@ -889,8 +889,8 @@ void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, > unsigned long page_num, > { > WARN_ON(!dmabuf); > > - if (dmabuf->ops->kunmap_atomic) > - dmabuf->ops->kunmap_atomic(dmabuf, page_num, vaddr); > + if (dmabuf->ops->unmap_atomic) > + dmabuf->ops->unmap_atomic(dmabuf, page_num, vaddr); > } > EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic); > > @@ -907,7 +907,7 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long > page_num) > { > WARN_ON(!dmabuf); > > - return dmabuf->ops->kmap(dmabuf, page_num); > + return dmabuf->ops->map(dmabuf, page_num); > } > EXPORT_SYMBOL_GPL(dma_buf_kmap); > > @@ -924,8 +924,8 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long > page_num, > { > WARN_ON(!dmabuf); > > - if (dmabuf->ops->kunmap) > - dmabuf->ops->kunmap(dmabuf, page_num, vaddr); > + if (dmabuf->ops->unmap) > + dmabuf->ops->unmap(dmabuf, page_num, vaddr); > } > EXPORT_SYMBOL_GPL(dma_buf_kunmap); > > diff --git a/drivers/gpu/drm/armada/armada_gem.c > b/drivers/gpu/drm/armada/armada_gem.c > index 1597458..d6c2a5d 100644 > --- a/drivers/gpu/drm/armada/armada_gem.c > +++ b/drivers/gpu/drm/armada/armada_gem.c > @@ -529,10 +529,10 @@ static const struct dma_buf_ops > armada_gem_prime_dmabuf_ops = { > .map_dma_buf= armada_gem_prime_map_dma_buf, > .unmap_dma_buf = armada_gem_prime_unmap_dma_buf, > .release= drm_gem_dmabuf_release, > - .kmap_atomic= armada_gem_dmabuf_no_kmap, > - .kunmap_atomic = armada_gem_dmabuf_no_kunmap, > - .kmap = armada_gem_dmabuf_no_kmap, > - .kunmap = armada_gem_dmabuf_no_kunmap, > + .map_atomic = armada_gem_dmabuf_no_kmap, > + .unmap_atomic = armada_gem_dmabuf_no_kunmap, > + .map= armada_gem_dmabuf_no_kmap, > + .unmap = armada_
Re: [Intel-gfx] [PATCH 01/27] drm/i915/selftests: Allocate inode/file dynamically
On ke, 2017-04-19 at 10:41 +0100, Chris Wilson wrote: > Avoid having too large a stack by creating the fake struct inode/file on > the heap instead. > > drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file': > drivers/gpu/drm/i915/selftests/mock_drm.c:46:1: error: the frame size of 1328 > bytes is larger than 1280 bytes [-Werror=frame-larger-than=] > drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file_free': > drivers/gpu/drm/i915/selftests/mock_drm.c:54:1: error: the frame size of 1312 > bytes is larger than 1280 bytes [-Werror=frame-larger-than=] > > Reported-by: Arnd Bergmann > Fixes: 66d9cb5d805a ("drm/i915: Mock the GEM device for self-testing") > Signed-off-by: Chris Wilson > Cc: Joonas Lahtinen > Cc: Tvrtko Ursulin > Cc: Matthew Auld > Cc: Arnd Bergmann > Acked-by: Arnd Bergmann 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] ✓ Fi.CI.BAT: success for drm/i915/scheduler: add gvt force-single-submission and notification for guc (rev4)
== Series Details == Series: drm/i915/scheduler: add gvt force-single-submission and notification for guc (rev4) URL : https://patchwork.freedesktop.org/series/21972/ State : success == Summary == Series 21972v4 drm/i915/scheduler: add gvt force-single-submission and notification for guc https://patchwork.freedesktop.org/api/1.0/series/21972/revisions/4/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-kbl-7560u) fdo#100125 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:432s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:429s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:576s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:505s fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 time:548s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:485s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:481s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:408s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:405s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:421s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:483s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:495s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:460s fi-kbl-7560u total:278 pass:267 dwarn:1 dfail:0 fail:0 skip:10 time:569s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:449s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time:569s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:460s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:496s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:429s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:540s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:399s 1b757084743a73fa672e92b4e5cf00a291667dfc drm-tip: 2017y-04m-19d-12h-50m-15s UTC integration manifest 9f1c42d drm/i915: refactor gvt force-single-submission == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4523/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/scheduler: add gvt force-single-submission and notification for guc (rev4)
Hi, > == Series Details == > > Series: drm/i915/scheduler: add gvt force-single-submission and notification > for guc (rev4) > URL : https://patchwork.freedesktop.org/series/21972/ > State : failure > > == Summary == > > Series 21972v4 drm/i915/scheduler: add gvt force-single-submission and > notification for guc > https://patchwork.freedesktop.org/api/1.0/series/21972/revisions/4/mbox/ > > Test gem_exec_flush: > Subgroup basic-batch-kernel-default-uc: > pass -> FAIL (fi-snb-2600) fdo#17 > Test pm_rpm: > Subgroup basic-pci-d3-state: > pass -> INCOMPLETE (fi-byt-j1900) Right, now seems to match https://bugs.freedesktop.org/show_bug.cgi?id=99740 Marking. Re-testing. > Subgroup basic-rte: > pass -> INCOMPLETE (fi-bsw-n3050) fdo#100718 > > fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 > fdo#100718 https://bugs.freedesktop.org/show_bug.cgi?id=100718 > > fi-byt-j1900 total:241 pass:217 dwarn:0 dfail:0 fail:0 skip:23 > > 1b757084743a73fa672e92b4e5cf00a291667dfc drm-tip: 2017y-04m-19d-12h- > 50m-15s UTC integration manifest 03cb65f drm/i915: refactor gvt force- > single-submission > > == Logs == Jani Saarinen Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx