- 21 Jan, 2020 13 commits
-
-
Ville Syrjälä authored
Replace the hand rolled intel_attached_dp() with the real thing. @@ identifier F !~ "^intel_attached_dp$"; expression C; @@ F(...) { <... - enc_to_intel_dp(intel_attached_encoder(C)) + intel_attached_dp(C) ...> } v2: Regenerated Signed-off-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-8-ville.syrjala@linux.intel.comReviewed-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
-
Ville Syrjälä authored
We have uses for intel_attached_dp() outside of intel_dp.c. Move it to a header. Signed-off-by:
Mika Kahola <mika.kahola@intel.com>
-
Ville Syrjälä authored
It's easy to confuse the drm_connector->encoder (legacy state adjusted during modeset) and intel_connector->encoder (the statically (sans. MST) attached encoder of the connector). For the latter let's use intel_attached_encoder() consistently. @@ identifier F !~ "^intel_attached_encoder$"; struct intel_connector *C; expression E; @@ F(...) { <... ( C->encoder = E | - C->encoder + intel_attached_encoder(C) ) ...> } @@ identifier F !~ "^intel_attached_encoder$"; struct drm_connector *C; expression E; @@ F(...) { <... ( to_intel_connector(C)->encoder = E | - to_intel_connector(C)->encoder + intel_attached_encoder(to_intel_connector(C)) ) ...> } v2: Regenerated Signed-off-by: -
Jani Nikula authored
Provide slightly more debugging help. Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200117150235.22471-1-jani.nikula@intel.com
-
Jani Nikula authored
Don't access i915->vbt.ddi_port_info[] directly. Reviewed-by:
-
Jani Nikula authored
Report port presence based on port presence in VBT alone, relaxing the requirements on supported encoders (DP, DVI, or HDMI). The goal is to make future changes easier, however there is a small risk of reporting more ports present than before in case of dubious VBT. Regarding the current callers of intel_bios_is_port_present(), the potential issue might be caused by DVO_PORT_CRT being identified as port E in dvo_port_to_port(). Hopefully no VBT has that on SKL+ which support DP/DVI/HDMI on port E; the current CRT init code on HSW/BDW does not care. Reviewed-by:
-
Jani Nikula authored
Don't access i915->vbt.ddi_port_info[] directly. Reviewed-by:
-
Jani Nikula authored
Don't access i915->vbt.ddi_port_info[] directly. Reviewed-by:
-
Jani Nikula authored
Don't access i915->vbt.ddi_port_info[] directly. Reviewed-by:
-
Jani Nikula authored
Don't access i915->vbt.ddi_port_info[] directly. Reviewed-by:
-
Jani Nikula authored
Don't access i915->vbt.ddi_port_info[] directly. Reviewed-by:
-
Jani Nikula authored
Don't access i915->vbt.ddi_port_info[] directly. Reviewed-by:
-
Jani Nikula authored
Don't access i915->vbt.ddi_port_info[] directly. Reviewed-by:
-
- 20 Jan, 2020 10 commits
-
-
Chris Wilson authored
Currently we create a new mmap_offset for every call to mmap_offset_ioctl. This exposes ourselves to an abusive client that may simply create new mmap_offsets ad infinitum, which will exhaust physical memory and the virtual address space. In addition to the exhaustion, a very long linear list of mmap_offsets causes other clients using the object to incur long list walks -- these long lists can also be generated by simply having many clients generate their own mmap_offset. However, we can simply use the drm_vma_node itself to manage the file association (allow/revoke) dropping our need to keep an mmo per-file. Then if we keep a small rbtree of per-type mmap_offsets, we can lookup duplicate requests quickly. Fixes: cc662126 ("drm/i915: Introduce DRM_I915_GEM_MMAP_OFFSET") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Reviewed-by:
Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200120104924.4000706-3-chris@chris-wilson.co.uk
-
Ville Syrjälä authored
Move the force_dvi check to a single function that can be called from both mode validation and compute_config(). Note that currently we don't call it from mode validation, but that will change soon. Signed-off-by:
-
Ville Syrjälä authored
Move the force_dvi check to a single function that can be called from both mode validation and compute_config(). Signed-off-by:
-
Ville Syrjälä authored
The strings we want to print to the on stack buffers should be no more than 8 * 3 + strlen("(GET_SCALED_HDTV_RESOLUTION_SUPPORT)") + 1 = 61 bytes. So let's shrink the buffers down to 64 bytes. Also switch the BUG_ON()s to WARN_ON()s if I made a mistake in my arithmentic. Signed-off-by: -
Ville Syrjälä authored
Let's not pollute the function scope with variables when they're only needed inside some loops. Signed-off-by:
José Roberto de Souza <jose.souza@intel.com>
-
Ville Syrjälä authored
sync_mode_slaves_mask is a bitmask so use PIPE_CONF_CHECK_X() for it so we get the mismatch printed in hex instead of decimal. Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Tested-by:
-
Ville Syrjälä authored
Let's use the pipe rather than the silly 'i' iterator from for_each_oldnew_intel_crtc_in_state() for indexing the ddb entries array. Maybe one day we can assume c99 and hide the 'i' entirely from sight. Signed-off-by:
-
Ville Syrjälä authored
Currently we don't call intel_crtc_prepare_cleared_state() for crtcs that are going to be entirely disabled (uapi.enable==false). That means such crtcs will leave stale junk lying around in their states and we have to sprinkle hw.enable checks all over before we can look at the states. Let's change that a bit so that we aways do the state clearing, even for fully disabled crtcs. Note that we still keep some parts of the old state (see intel_crtc_prepare_cleared_state() for the details) so probably can't trust things 100% when hw.enable==false. But at least there's less chance now that we end up looking at stale junk. Signed-off-by:
-
Ville Syrjälä authored
The post-fastset "does anyone still need a full modeset?" for port sync looks busted. The outer loop bails out of a full modeset is still needed by the current crtc, and then we skip forcing a full modeset on the related crtcs. That's totally the opposite of what we want. The MST path has the logic mostly the other way around so it looks correct. To fix the port sync case let's follow the MST logic for both. So, if the current crtc already needs a modeset we do nothing. otherwise we check if any of the related crtcs needs a modeset, and if so we force a full modeset for the current crtc. And while at let's change the else if to a plain if to so we don't have needless coupling between the MST and port sync checks. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Fixes: 05a8e451 ("drm/i915/display: Use external dependency loop for port sync") Signed-off-by:
-
Tvrtko Ursulin authored
In our ABI we have defined I915_ENGINE_CLASS_INVALID_NONE and I915_ENGINE_CLASS_INVALID_VIRTUAL as negative values which creates implicit coupling with type widths used in, also ABI, struct i915_engine_class_instance. One place where we export engine->uabi_class I915_ENGINE_CLASS_INVALID_VIRTUAL is from our our tracepoints. Because the type of the former is u8 in contrast to u16 defined in the ABI, 254 will be returned instead of 65534 which userspace would legitimately expect. Another place is I915_CONTEXT_PARAM_ENGINES. Therefore we need to align the type used to store engine ABI class and instance. v2: * Update the commit message mentioning get_engines and cc stable. (Chris) Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 6d06779e ("drm/i915: Load balancing across a virtual engine") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: <stable@vger.kernel.org> # v5.3+ Reviewed-by:
-
- 18 Jan, 2020 1 commit
-
-
Chris Wilson authored
Just in the very unlikely case we have not stopped the GPU before we return the pages being used by the GPU to the system, force a reset. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200117180309.3249427-1-chris@chris-wilson.co.uk
-
- 17 Jan, 2020 16 commits
-
-
Matthew Auld authored
If we create a rather large userptr object(e.g 1ULL << 32) we might shift past the type-width of num_pages: (int)num_pages << PAGE_SHIFT, resulting in a totally bogus sg_table, which fortunately will eventually manifest as: gen8_ppgtt_insert_huge:463 GEM_BUG_ON(iter->sg->length < page_size) kernel BUG at drivers/gpu/drm/i915/gt/gen8_ppgtt.c:463! v2: more unsigned long prefer I915_GTT_PAGE_SIZE Fixes: 5cc9ed4b ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl") Signed-off-by: -
Matthew Auld authored
Don't allow a mismatch between obj->base.size/vma->size and the actual number of pages for the backing store, which is limited to INT_MAX pages. v2: document what are missing before we can safely drop the limit check Signed-off-by:
-
Chris Wilson authored
Since commit 22b7a426 ("drm/i915/execlists: Preempt-to-busy"), we prune the engine->active.requests list prior to preemption, thus removing the trace of the currently executing request. If that request hangs rather than be preempted, we conclude that no active request was on the GPU. Fortunately, this only impacts our debugging, and not our means of hang detection or recovery. v2: Use from to check the current iterator before continuing, and report active as NULL if the current request is already completed. References: 22b7a426 ("drm/i915/execlists: Preempt-to-busy") Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200117113259.3023890-1-chris@chris-wilson.co.uk
-
Wambui Karuga authored
Replace the use of printk based logging macros with the new struct drm_device based logging macro in i915/intel_memory_region.c. Signed-off-by:
Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by:
-
Wambui Karuga authored
This converts the use of printk based logging macros in i915/intel_gvt.c with the new struct drm_device based logging macros. Signed-off-by:
-
Wambui Karuga authored
This replaces the printk and struct device based logging macros with the new struct drm_device style based logging macros i915/intel_device_info.c. Signed-off-by:
-
Wambui Karuga authored
Replace the use of printk and struct device based logging macros with the new struct drm_device based logging macros in i915/intel_csr.c Signed-off-by:
-
Wambui Karuga authored
Replace the use of printk based logging macros with the struct drm_device based macros in i915/i915_vgpu.c Signed-off-by:
-
Michal Wajdeczko authored
As we now have "ct" available almost in all functions we can start using dev variants of logs also for debug. Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Michal Wajdeczko authored
As we now have "ct" available in ct_read function we can switch from generic DRM_ERROR to our custom CT_ERROR. Signed-off-by:
Piotr Piórkowski <piotr.piorkowski@intel.com> Signed-off-by:
-
Michal Wajdeczko authored
Since we only have one RECV buffer we don't need to explicitly pass it to the read function. Signed-off-by:
-
Michal Wajdeczko authored
Since we only have one SEND buffer we don't need to explicitly pass it to the write function. Signed-off-by:
-
Michal Wajdeczko authored
We should never BUG_ON on any corruption in CTB descriptor as data there can be also modified by the GuC. Instead we can use flag "is_in_error" to indicate that we will not process any further messages over this CTB (until reset). While here move descriptor error reporting to the function that actually touches that descriptor. Note that unexpected content of the specific CT messages, that still complies with generic CT message format, shall not trigger disabling whole CTB, as that might just indicate new unsupported message types. v2: drop redundant message (Daniele) Signed-off-by:
-
Chris Wilson authored
Smatch worries that the engine->mask may be 0 leading to the loop being shortcircuited leaving the next pointer unset, drivers/gpu/drm/i915/i915_active.c:667 i915_active_acquire_preallocate_barrier() error: uninitialized symbol 'next'. Assert that mask is not 0 and smatch can then verify that next must be initialised before use. Signed-off-by:
-
Chris Wilson authored
A forgetful copy'n'paste left the name of the old function intact, and did not introduce the new function 'i915_request_is_ready' Signed-off-by:
-
Zhang Xiaoxu authored
Since commit 742379c0 ("drm/i915: Start chopping up the GPU error capture"), function 'i915_error_state_store' was defined and used with only one parameter. But if no 'CONFIG_DRM_I915_CAPTURE_ERROR', this function was defined with two parameter. This may lead compile error. This patch fix it. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Zhang Xiaoxu <zhangxiaoxu5@huawei.com> Reviewed-by:
Andi Shyti <andi.shyti@intel.com> Signed-off-by:
-
