- 21 Jan, 2020 6 commits
-
-
Jani Nikula authored
Don't access i915->vbt.ddi_port_info[] directly. Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/9e4fcb625cec26ee88245aad7ae80bfe93b14e59.1579270868.git.jani.nikula@intel.com
-
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 22 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:
-
Chris Wilson authored
drivers/gpu/drm/i915/i915_debugfs_params.c:228:15: warning: symbol 'i915_debugfs_params' was not declared. Should it be static? drivers/gpu/drm/i915/i915_debugfs_params.c:228:16: error: no previous prototype for ‘i915_debugfs_params’ [-Werror=missing-prototypes] 228 | struct dentry *i915_debugfs_params(struct drm_i915_private *i915) Signed-off-by:
-
Lyude Paul authored
Turns out we actually already have some companies, such as Lenovo, shipping machines with AMOLED screens that don't allow controlling the backlight through the usual PWM interface and only allow controlling it through the standard EDP DPCD interface. One example of one of these laptops is the X1 Extreme 2nd Generation. Since we've got systems that need this turned on by default now to have backlight controls working out of the box, let's start auto-detecting it for systems by default based on what the VBT tells us. We do this by changing the default value for the enable_dpcd_backlight module param from 0 to -1. Tested-by:
AceLan Kao <acelan.kao@canonical.com> Tested-by:
Perry Yuan <pyuan@redhat.com> Signed-off-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Lyude Paul authored
For eDP panels, it appears it's expected that so long as the panel is in DPCD control mode that the brightness value is never set to 0. Instead, if the desired effect is to set the panel's backlight to 0 we're expected to simply turn off the backlight through the DP_EDP_DISPLAY_CONTROL_REGISTER. We already do the latter correctly in intel_dp_aux_disable_backlight(). But, we make the mistake of writing the DPCD registers in the wrong order when enabling the backlight in intel_dp_aux_enable_backlight() since we currently enable the backlight through DP_EDP_DISPLAY_CONTROL_REGISTER before writing the brightness level. On the X1 Extreme 2nd Generation, this appears to have the potential of confusing the panel in such a way that further attempts to set the brightness don't actually change the backlight as expected and leave it off. Presumably, this happens because the incorrect register writing order briefly leaves the panel with DPCD mode enabled and a 0 brightness level set. So, reverse the order we write the DPCD registers when enabling the panel backlight so that we write the brightness value first, and enable the backlight second. This fix appears to be the final bit needed to get the backlight on the ThinkPad X1 Extreme 2nd Generation's AMOLED screen working. Tested-by:
-
Lyude Paul authored
Currently we always determine the initial panel brightness level by simply reading the value from DP_EDP_BACKLIGHT_BRIGHTNESS_MSB/LSB. This seems wrong though, because if the panel is not currently in DPCD control mode there's not really any reason why there would be any brightness value programmed in the first place. This appears to be the case on the Lenovo ThinkPad X1 Extreme 2nd Generation, where the default value in these registers is always 0 on boot despite the fact the panel runs at max brightness by default. Getting the initial brightness value correct here is important as well, since the panel on this laptop doesn't behave well if it's ever put into DPCD control mode while the brightness level is programmed to 0. So, let's fix this by checking what the current backlight control mode is before reading the brightness level. If it's in DPCD control mode, we return the programmed brightness level. Otherwise we assume 100% brightness and return the highest possible brightness level. This also prevents us from accidentally programming a brightness level of 0. This is one of the many fixes that gets backlight controls working on the ThinkPad X1 Extreme 2nd Generation with optional 4K AMOLED screen. Changes since v1: * s/DP_EDP_DISPLAY_CONTROL_REGISTER/DP_EDP_BACKLIGHT_MODE_SET_REGISTER/ - Jani Tested-by:
-
Lyude Paul authored
Max backlight value for the panel was being calculated using byte count i.e. 0xffff if 2 bytes are supported for backlight brightness and 0xff if 1 byte is supported. However, EDP_PWMGEN_BIT_COUNT determines the number of active control bits used for the brightness setting. Thus, even if the panel uses 2 byte setting, it might not use all the control bits. Thus, max backlight should be set based on the value of EDP_PWMGEN_BIT_COUNT instead of assuming 65535 or 255. Additionally, EDP_PWMGEN_BIT_COUNT was being updated based on the VBT frequency which results in a different max backlight value. Thus, setting of EDP_PWMGEN_BIT_COUNT is moved to setup phase instead of enable so that max backlight can be calculated correctly. Only the frequency divider is set during the enable phase using the value of EDP_PWMGEN_BIT_COUNT. This is based off the original patch series from Furquan Shaikh <furquan@google.com>: https://patchwork.freedesktop.org/patch/317255/?series=62326&rev=3 Changes since original patch: * Remove unused intel_dp variable in intel_dp_aux_setup_backlight() * Fix checkpatch issues * Make sure that we rewrite the pwmgen bit count whenever we bring the panel out of D3 mode v2 by Jani: * rebase * fix readb return value check Cc: Furquan Shaikh <furquan@google.com> Tested-by:
-
Vivek Kasireddy authored
Perform the i2c bus/adapter lookup from ACPI Namespace only if ACPI is enabled in the kernel config. If ACPI is not enabled or if the lookup fails, we'll fallback to using the VBT for identifying the i2c bus. v2: Add fixes tag (Jani) Fixes: 8cbf89db ("drm/i915/dsi: Parse the I2C element from the VBT MIPI sequence block (v3)") Cc: Hans de Goede <hdegoede@redhat.com> Cc: Nabendu Maiti <nabendu.bikash.maiti@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Zhang Xiaoxu <zhangxiaoxu5@huawei.com> Reported-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by:
-
- 16 Jan, 2020 1 commit
-
-
Chris Wilson authored
Currently, we skip error capture upon forced preemption. We apply forced preemption when there is a higher priority request that should be running but is being blocked, and we skip inline error capture so that the preemption request is not further delayed by a user controlled capture -- extending the denial of service. However, preemption reset is also used for heartbeats and regular GPU hangs. By skipping the error capture, we remove the ability to debug GPU hangs. In order to capture the error without delaying the preemption request further, we can do an out-of-line capture by removing the guilty request from the execution queue and scheduling a worker to dump that request. When removing a request, we need to remove the entire context and all descendants from the execution queue, so that they do not jump past. Closes: https://gitlab.freedesktop.org/drm/intel/issues/738 Fixes: 3a7a92ab ("drm/i915/execlists: Force preemption") Signed-off-by:
-
