- 26 Oct, 2022 16 commits
-
-
Jani Nikula authored
Convert to drm_kms_dbg/drm_err where possible, and reference the connector using [CONNECTOR:%d:%s]. Pass connectors around a bit more to enable this. Where this is not possible, unify the rest of the debugs to DRM_DEBUG_KMS. Rewrite tile debug logging to one line while at it. v2: - Use [CONNECTOR:%d:%s] throughout (Ville) - Tile debug logging revamp - Pass connector around a bit more Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e48346bfe09a632d5a5faa55e3c161b196cf21e8.1666614699.git.jani.nikula@intel.com
-
Jani Nikula authored
Reference the connector using [CONNECTOR:%d:%s] in existing device based debug logging. Signed-off-by:
Simon Ser <contact@emersion.fr> Link: https://patchwork.freedesktop.org/patch/msgid/5884410682bcbc032de4d3af8562c0b271edaa7f.1666614699.git.jani.nikula@intel.com
-
Jani Nikula authored
Conform to device specific logging. v2: Include [CONNECTOR:%d:%s] (Ville) Signed-off-by:
-
Jani Nikula authored
The EDID loader is internal to drm, not for drivers. Signed-off-by:
-
Jani Nikula authored
There's a lot going on here, but the main thing is switching the firmware EDID loader to use struct drm_edid. Unfortunately, it's difficult to reasonably split to smaller pieces. Convert the EDID loader to struct drm_edid. There's a functional change in validation; it no longer tries to fix errors or filter invalid blocks. It's stricter in this sense. Hopefully this will not be an issue. As a by-product, this change also allows HF-EEODB extended EDIDs to be passed via override/firmware EDID. Signed-off-by:
-
Jani Nikula authored
Follow the usual naming convention by file name. Signed-off-by:
-
Jani Nikula authored
Stop passing around something that's readily available in connector->name. Signed-off-by:
-
Jani Nikula authored
Having the EDID override debugfs directly update the EDID property is problematic. The update is partial only. The driver has no way of knowing it's been updated. Mode list is not updated. It's an inconsistent state. Detach debugfs EDID override from the property update completely. Only set and reset a separate override EDID copy from debugfs, and have it take effect only at detect (via EDID read). The copy is at connector->edid_override, protected by connector->edid_override_mutex. This also brings override EDID closer to firmware EDID in behaviour. Add validation of the override EDID which we completely lacked. Note that IGT already forces a detect whenever tests update the override EDID. v2: Add locking (Ville) Signed-off-by:
-
Jani Nikula authored
We've lacked a function for immutable validity check on drm_edid. Add one. Signed-off-by:
-
Jani Nikula authored
Split the drm_edid block count helper to a base version that reports the block count indicated by EDID contents, and another on top that limits the block count based on size allocated for the EDID. Signed-off-by:
-
Jani Nikula authored
Follow the naming of both EDID override functions as well as drm_edid_connector_update(). This also matches better what the function does; a combination of EDID property update and add modes. Indeed it should later be converted to call drm_edid_connector_update(). Signed-off-by:
-
Jani Nikula authored
Add a function to dump the override EDID in debugfs. This hides the override EDID management better in drm_edid.c. Signed-off-by:
-
Jani Nikula authored
It's useful debugging information to know if and when an override EDID was set or reset. Signed-off-by:
-
Jani Nikula authored
The connector->override_edid flag is strictly for EDID override debugfs management, and drivers have no business using it. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Xinhui Pan <Xinhui.Pan@amd.com> Cc: amd-gfx@lists.freedesktop.org Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Acked-by:
Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/c901869ff8a4e3aebc4abec99c7dd7b4c224f6e6.1666614699.git.jani.nikula@intel.com
-
Jani Nikula authored
The connector->override_edid flag is strictly for EDID override debugfs management, and drivers have no business using it. The check for override_edid was added in commit 30190629 ("drm/i915: Ignore TMDS clock limit for DP++ when EDID override is set") to facilitate mode list cross-checking against modes in override EDID when the connector in question isn't even connected. The dual mode detect fallback would do VBT based limiting in this case. Instead of override EDID, check for connector forcing in the fallback. v2: Simply use !connector->force (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
For normal connector detect, there's really no point in trying dual mode detect if the connector is disconnected. We can simplify the detect sequence by skipping it. Since intel_hdmi_dp_dual_mode_detect() is only called when EDID is present, we can drop the has_edid parameter. The functional effect is speeding up disconnected connector detection ever so slightly, and, combined with firmware EDID, also stop logging about assuming dual mode adaptor. It's a bit subtle, but this will also skip dual mode detect if the connector is force connected and a) there's no EDID of any kind, normal or override/firmware or b) there's EDID but it does not indicate digital. These are corner cases no matter what, and arguably forcing should not be limited by dual mode detect. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
- 25 Oct, 2022 20 commits
-
-
Zack Rusin authored
Fixes a warning about extra docs about a function argument that has been removed a while back: drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:3888: warning: Excess function parameter 'sync_file' description in 'vmw_execbuf_copy_fence_user' Fixes: a0f90c88 ("drm/vmwgfx: Fix stale file descriptors on failed usercopy") Signed-off-by:
Zack Rusin <zackr@vmware.com> Reviewed-by:
Martin Krastev <krastevm@vmware.com> Reviewed-by:
Maaz Mombasawala <mombasawalam@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221022040236.616490-18-zack@kde.org
-
Zack Rusin authored
It's important to get the initial size of cotables right because otherwise every app needs to start with a synchronous cotable resize. This has an measurable impact on system wide performance but is not relevant for long running single full screen apps for which the cotable resizes will happen early in the lifecycle and will continue running just fine. To eliminate the initial cotable resizes match the initial sizes to what the userspace expects. The actual result of the patch is simply setting the initial size of two of the cotables to a size that will align them to two pages instead of one. For a piglit run, before: name | total | per frame | per sec vmw_cotable_resize | 1405 | 0.12 | 1.58 vmw_execbuf_ioctl | 290805 | 25.43 | 326.05 After: name | total | per frame | per sec vmw_cotable_resize | 4 | 0.00 | 0.00 vmw_execbuf_ioctl | 281673 | 25.10 | 274.68 Signed-off-by:
Michael Banack <banackm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221022040236.616490-17-zack@kde.org
-
Zack Rusin authored
There's been a lot of cotable resizes on startup which we can track by adding a mks stat to measure both the invocation count and time spent doing cotable resizes. This is only used if kernel is configured with CONFIG_DRM_VMWGFX_MKSSTATS The stats are collected on the host size inside the vmware-stats.log file. Signed-off-by:
-
Zack Rusin authored
The explicit vblank handling was never finished. The driver never had the full implementation of vblank and what was there is emulated by DRM when the driver doesn't pretend to be implementing it itself. Let DRM handle the vblank emulation and stop pretending the driver is doing anything special with vblank. In the future it would make sense to implement helpers for full vblank handling because vkms and amdgpu_vkms already have that code. Exporting it to common helpers and having all three drivers share it would make sense (that would be largely just to allow more of igt to run). Signed-off-by:
-
Zack Rusin authored
Instead of using vmwgfx specific framebuffer implementation use the drm fb helpers. There's no change in functionality, the only difference is a reduction in the amount of code inside the vmwgfx module. drm fb helpers do not deal correctly with changes in crtc preferred mode at runtime, but the old fb code wasn't dealing with it either. Same situation applies to high-res fb consoles - the old code was limited to 1176x885 because it was checking for legacy/deprecated memory limites, the drm fb helpers are limited to the initial resolution set on fb due to first problem (drm fb helpers being unable to handle hotplug crtc preferred mode changes). This also removes the kernel config for disabling fb support which hasn't been used or supported in a very long time. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20221022040236.616490-14-zack@kde.org
-
Zack Rusin authored
Dumb buffers allow a very limited set of formats. Basically everything apart from 1, 2 and 4 is expected to return an error. Make vmwgfx follow those guidelines. This fixes igt's dumb_buffer invalid_bpp test on vmwgfx. Signed-off-by:
-
Maaz Mombasawala authored
The vmwgfx driver has migrated from using the hashtable in vmwgfx_hashtab to the linux/hashtable implementation. Remove the vmwgfx_hashtab from the driver. Signed-off-by:
-
Maaz Mombasawala authored
This is part of an effort to move from the vmwgfx_open_hash hashtable to linux/hashtable implementation. Refactor the ref_hash hashtable, used for fast lookup of reference objects associated with a ttm file. This also exposed a problem related to inconsistently using 32-bit and 64-bit keys with this hashtable. The hash function used changes depending on the size of the type, and results are not consistent across numbers, for example, hash_32(329) = 329, but hash_long(329) = 328. This would cause the lookup to fail for objects already in the hashtable, since keys of different sizes were being passed during adding and lookup. This was not an issue before because vmwgfx_open_hash always used hash_long. Fix this by always using 64-bit keys for this hashtable, which means that hash_long is always used. Signed-off-by:
-
Michael Banack authored
Extend the cursor diffing support to support the command-path. Signed-off-by:
-
Michael Banack authored
Add support for cursor surfaces when using mob cursors. Signed-off-by:
-
Michael Banack authored
Avoid making the SVGA device do extra work if the new cursor image matches the old one. Signed-off-by:
-
Michael Banack authored
Clean up the cursor mob path by moving ownership of the mobs into the plane_state, and just leaving a cache of unused mobs in the plane itself. Signed-off-by:
-
Maaz Mombasawala authored
Vmwgfx's hashtab implementation needs to be replaced with linux/hashtable to reduce maintenence burden. As part of this effort, refactor the res_ht hashtable used for resource validation during execbuf execution to use linux/hashtable implementation. This also refactors vmw_validation_context to use vmw_sw_context as the container for the hashtable, whereas before it used a vmwgfx_open_hash directly. This makes vmw_validation_context less generic, but there is no functional change since res_ht is the only instance where validation context used a hashtable in vmwgfx driver. Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by:
-
Maaz Mombasawala authored
The object_hash hashtable for ttm objects is not being used. Remove it and perform refactoring in ttm_object init function. Signed-off-by:
-
Maaz Mombasawala authored
Vmwgfx's hashtab implementation needs to be replaced with linux/hashtable to reduce maintenance burden. Refactor cmdbuf resource manager to use linux/hashtable.h implementation as part of this effort. Signed-off-by:
-
Martin Krastev authored
Function vmw_mksstat_add_ioctl allocates three big arrays on stack. That triggers frame-size [-Wframe-larger-than=] warning. Refactor that function to use kmalloc_array instead. v2: Initialize page to null to avoid possible uninitialized use of it, spotted by the kernel test robot <lkp@intel.com> Signed-off-by: -
Zack Rusin authored
Driver id registers are a new mechanism in the svga device to hint to the device which driver is running. This should not change device behavior in any way, but might be convenient to work-around specific bugs in guest drivers. Signed-off-by:
-
Luben Tuikov authored
The currently default Round-Robin GPU scheduling can result in starvation of entities which have a large number of jobs, over entities which have a very small number of jobs (single digit). This can be illustrated in the following diagram, where jobs are alphabetized to show their chronological order of arrival, where job A is the oldest, B is the second oldest, and so on, to J, the most recent job to arrive. ---> entities j | H-F-----A--E--I-- o | --G-----B-----J-- b | --------C-------- s\/ --------D-------- WLOG, assuming all jobs are "ready", then a R-R scheduling will execute them in the following order (a slice off of the top of the entities' list), H, F, A, E, I, G, B, J, C, D. However, to mitigate job starvation, we'd rather execute C and D before E, and so on, given, of course, that they're all ready to be executed. So, if all jobs are ready at this instant, the order of execution for this and the next 9 instances of picking the next job to execute, should really be, A, B, C, D, E, F, G, H, I, J, which is their chronological order. The only reason for this order to be broken, is if an older job is not yet ready, but a younger job is ready, at an instant of picking a new job to execute. For instance if job C wasn't ready at time 2, but job D was ready, then we'd pick job D, like this: 0 +1 +2 ... A, B, D, ... And from then on, C would be preferred before all other jobs, if it is ready at the time when a new job for execution is picked. So, if C became ready two steps later, the execution order would look like this: ......0 +1 +2 ... A, B, D, E, C, F, G, H, I, J This is what the FIFO GPU scheduling algorithm achieves. It uses a Red-Black tree to keep jobs sorted in chronological order, where picking the oldest job is O(1) (we use the "cached" structure), and balancing the tree is O(log n). IOW, it picks the *oldest ready* job to execute now. The implementation is already in the kernel, and this commit only changes the default GPU scheduling algorithm to use. This was tested and achieves about 1% faster performance over the Round Robin algorithm. Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <Alexander.Deucher@amd.com> Cc: Direct Rendering Infrastructure - Development <dri-devel@lists.freedesktop.org> Signed-off-by:Luben Tuikov <luben.tuikov@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221024212634.27230-1-luben.tuikov@amd.comSigned-off-by:
-
Simon Ser authored
A typical DP-MST unplug removes a KMS connector. However care must be taken to properly synchronize with user-space. The expected sequence of events is the following: 1. The kernel notices that the DP-MST port is gone. 2. The kernel marks the connector as disconnected, then sends a uevent to make user-space re-scan the connector list. 3. User-space notices the connector goes from connected to disconnected, disables it. 4. Kernel handles the IOCTL disabling the connector. On success, the very last reference to the struct drm_connector is dropped and drm_connector_cleanup() is called. 5. The connector is removed from the list, and a uevent is sent to tell user-space that the connector disappeared. The very last step was missing. As a result, user-space thought the connector still existed and could try to disable it again. Since the kernel no longer knows about the connector, that would end up with EINVAL and confused user-space. Fix this by sending a hotplug uevent from drm_connector_cleanup(). Signed-off-by:
Jonas Ådahl <jadahl@redhat.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221017153150.60675-2-contact@emersion.fr
-
Simon Ser authored
This reverts commit 981f0929. It turns out this causes logically active but disconnected DP MST connectors to disappear from the KMS resources list, and Mutter then assumes the connector is already disabled. Later on Mutter tries to re-use the same CRTC but fails since on the kernel side it's still tied to the disconnected DP MST connector. Signed-off-by:
-
- 24 Oct, 2022 4 commits
-
-
Dmitry Osipenko authored
The drm_client_buffer_delete() wasn't switched to unlocked GEM vunmapping by accident when rest of drm_client code transitioned to the unlocked variants of the vmapping functions. Make drm_client_buffer_delete() use the unlocked variant. This fixes lockdep warning splat about missing reservation lock when framebuffer is released. Reported-by:
kernel test robot <yujie.liu@intel.com> Link: https://lore.kernel.org/dri-devel/890f70db-68b0-8456-ca3c-c5496ef90517@collabora.com/T/ Fixes: 79e2cf2e ("drm/gem: Take reservation lock for vmap/vunmap operations") Signed-off-by:
Dmitry Osipenko <dmitry.osipenko@collabora.com> Acked-by:
-
Pin-yen Lin authored
Originally, the it6505 relies on a short sleep in the IRQ handler and a long sleep to make sure it6505->lane_swap and it6505->lane_count is configured in it6505_extcon_work and it6505_detect, respectively. Use completion and additional DPCD read to remove the unnecessary waits, and use a different lock for it6505_extcon_work and the threaded IRQ handler because they no longer need to run exclusively. The wait time of the completion is usually less than 10ms in local experiments, but leave it larger here just in case. Signed-off-by:
Pin-yen Lin <treapking@chromium.org> Reviewed-by:
Robert Foss <robert.foss@linaro.org> Signed-off-by:
-
Pin-yen Lin authored
Move the DPCD read and link setup steps to HPD IRQ handler to remove an unnecessary dependency between .detect callback and the HPD IRQ handler before registering it6505 as a DRM bridge. This is safe because there is always a .detect call after each HPD IRQ handler triggered by the drm_helper_hpd_irq_event call. Signed-off-by:
-
Pin-yen Lin authored
During device boot, the HPD interrupt could be triggered before the DRM subsystem registers it6505 as a DRM bridge. In such cases, the driver tries to access AUX channel and causes NULL pointer dereference. Initializing the AUX channel earlier to prevent such error. Fixes: b5c84a9e ("drm/bridge: add it6505 driver") Signed-off-by:
-
