aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-10-26drm/edid: add function for checking drm_edid validityJani Nikula2-0/+31
We've lacked a function for immutable validity check on drm_edid. Add one. Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/f96188f64e9f7f3deff348d08296609353b12316.1666614699.git.jani.nikula@intel.com
2022-10-26drm/edid: split drm_edid block count helperJani Nikula1-4/+11
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 <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/a7d63878c7fb3dd6f3b987f5257897113797b94f.1666614699.git.jani.nikula@intel.com
2022-10-26drm/edid: rename drm_add_override_edid_modes() to ↵Jani Nikula3-5/+5
drm_edid_override_connector_update() 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 <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/ba12957e0488654e8db010a3ff1534079caec972.1666614699.git.jani.nikula@intel.com
2022-10-26drm/edid: abstract debugfs override EDID show betterJani Nikula3-8/+15
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 <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/74defa7b595f51e6c1f2eacd9c799d567d29f053.1666614699.git.jani.nikula@intel.com
2022-10-26drm/edid: debug log EDID override set/resetJani Nikula1-0/+6
It's useful debugging information to know if and when an override EDID was set or reset. Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/ae352f542b4d69398c0965e33fb2e6e34156cbfb.1666614699.git.jani.nikula@intel.com
2022-10-26drm/amd/display: stop using connector->override_edidJani Nikula1-3/+0
The connector->override_edid flag is strictly for EDID override debugfs management, and drivers have no business using it. Cc: Alex Deucher <[email protected]> Cc: Christian König <[email protected]> Cc: Xinhui Pan <[email protected]> Cc: [email protected] Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Acked-by: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/c901869ff8a4e3aebc4abec99c7dd7b4c224f6e6.1666614699.git.jani.nikula@intel.com
2022-10-26drm/i915/hdmi: stop using connector->override_edidJani Nikula1-4/+1
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 301906290553 ("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ä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/c8b45867cf37134ab40be23e22825ca45adc6041.1666614699.git.jani.nikula@intel.com
2022-10-26drm/i915/hdmi: do dual mode detect only if connectedJani Nikula1-10/+7
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ä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/f8f2a4a147e1c87ba93269a607f71fc29c4b59f6.1666614699.git.jani.nikula@intel.com
2022-10-26drm/nouveau: Remove unused variableZack Rusin1-1/+0
Trivial removal of an unused variable. Not sure how it snuck by me and build bots in the 7c99616e3fe7. Fixes: 7c99616e3fe7 ("drm: Remove drm_mode_config::fb_base") Reported-by: Stephen Rothwell <[email protected]> Cc: Laurent Pinchart <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Christian König <[email protected]> Cc: Ben Skeggs <[email protected]> Cc: Karol Herbst <[email protected]> Cc: Lyude Paul <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Signed-off-by: Zack Rusin <[email protected]> Signed-off-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Dave Airlie <[email protected]>
2022-10-26drm/i915: Stop loading linear degamma LUT on glk needlesslyVille Syrjälä1-23/+3
Make glk_load_luts() a bit lighter for the common case where neither the degamma LUT nor pipe CSC are enabled by not loading the linear degamma LUT. Making .load_luts() as lightweight as possible is a good idea since it may need to execute from a vblank worker under tight deadlines. My earlier reasoning for always loading the linear degamma LUT was to avoid an extra LUT load when just enabling/disabling the pipe CSC, but that is nonsense since we load the LUTs on every flagged color management change/modeset anyway (either of which is needed for a pipe CSC toggle). We can also get rid of the glk_can_preload_luts() special case since the presence of the degamma LUT will now always match csc_enable. v2: Fix typos (Uma) Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-26drm/i915: Get rid of glk_load_degamma_lut_linear()Ville Syrjälä5-42/+82
Since we now have a place (pre_csc_lut) to stuff a purely internal LUT we can replace glk_load_degamma_lut_linear() with such a thing and just rely on the normal glk_load_degamma_lut() to load it as well. drm_mode_config_cleanup() will clean this up for us. v2: Pass on the error pointer Drop a hint about this into the state dump Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-26drm/i915: Assert {pre,post}_csc_lut were assigned sensiblyVille Syrjälä3-0/+23
Since we now have the extra step from hw.(de)gamma_lut into {pre,post}_csc_lut let's make sure we didn't forget to assign them appropriately. Ie. basically making sure intel_color_check() was called when necessary (and that it did its job suitable well). Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-26drm/i915: Introduce crtc_state->{pre,post}_csc_lutVille Syrjälä6-57/+114
Add an extra remapping step between the logical state of the LUTs (hw.(de)gamma_lut) as specified via uapi/bigjoiner copy vs. the actual state of the LUTs programmed into the hardware. With this we should be finally able finish the (de)gamma readout/state checker support for the remaining platforms (ilk-skl) where the same hardware LUT can be positioned either before or after the pipe CSC unit. Where we position it depends on factors such as presence of the logical degamma LUT, RGB vs. YCbCr output, full vs. limited RGB quantization range. Without the extra remapping step the state readout doesn't really know whether the LUT read from the hardware is the degamma or gamma LUT, and so we is unable to accurately store it into our crtc state. With the remapping step we know exactly where to put it given the order of the LUT vs. CSC in the hardware state. Only the initial hw->uapi state readout done during driver load/resume still has the problem of not really knowing what to do with the LUT(s). But we can just assume 1:1 mapping there and let subsequent commits fix things up. Another benefit is that we now have a place for purely internal LUTs, without complicating the bigjoiner uapi->hw copy logic. This should prove useful for streamlining glk degamma LUT handling. Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-26drm/i915: Make ilk_load_luts() deal with degammaVille Syrjälä1-2/+4
Make ilk_load_luts() ready for a degamma lut. Currently we never have one, but soon we may get one from readout, and I think we may want to change the state computation such that we may end up with one even when userspace has simply supplied a gamma lut. At least the code now follows the path laid out by the ivb/bdw counterpars. Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-25drm/vmwgfx: Fix a sparse warning in kernel docsZack Rusin1-1/+0
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: a0f90c881570 ("drm/vmwgfx: Fix stale file descriptors on failed usercopy") Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: Martin Krastev <[email protected]> Reviewed-by: Maaz Mombasawala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-25drm/vmwgfx: Optimize initial sizes of cotablesZack Rusin1-2/+14
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: Zack Rusin <[email protected]> Reviewed-by: Michael Banack <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-25drm/vmwgfx: Add a mksstat counter for cotable resizesZack Rusin3-9/+22
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 <[email protected]> Reviewed-by: Michael Banack <[email protected]> Reviewed-by: Martin Krastev <[email protected]> Reviewed-by: Maaz Mombasawala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-25drm/vmwgfx: Remove explicit and broken vblank handlingZack Rusin5-101/+1
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 <[email protected]> Reviewed-by: Maaz Mombasawala <[email protected]> Reviewed-by: Martin Krastev <[email protected]> Reviewed-by: Michael Banack <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-25drm/vmwgfx: Port the framebuffer code to drm fb helpersZack Rusin7-991/+28
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: Zack Rusin <[email protected]> Reviewed-by: Maaz Mombasawala <[email protected]> Reviewed-by: Martin Krastev <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-25drm/vmwgfx: Do not allow invalid bpp's for dumb buffersZack Rusin1-1/+15
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: Zack Rusin <[email protected]> Reviewed-by: Martin Krastev <[email protected]> Reviewed-by: Maaz Mombasawala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-25drm/vmwgfx: Remove vmwgfx_hashtabMaaz Mombasawala8-303/+12
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 <[email protected]> Reviewed-by: Martin Krastev <[email protected]> Reviewed-by: Zack Rusin <[email protected]> Signed-off-by: Zack Rusin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-25drm/vmwgfx: Refactor ttm reference object hashtable to use linux/hashtable.Maaz Mombasawala3-49/+56
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: Maaz Mombasawala <[email protected]> Reviewed-by: Zack Rusin <[email protected]> Signed-off-by: Zack Rusin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-25drm/vmwgfx: Diff cursors when using cmdsMichael Banack2-60/+62
Extend the cursor diffing support to support the command-path. Signed-off-by: Michael Banack <[email protected]> Signed-off-by: Zack Rusin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-25drm/vmwgfx: Support cursor surfaces with mob cursorMichael Banack2-29/+50
Add support for cursor surfaces when using mob cursors. Signed-off-by: Michael Banack <[email protected]> Signed-off-by: Zack Rusin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-25drm/vmwgfx: Start diffing new mob cursors against old onesMichael Banack2-26/+81
Avoid making the SVGA device do extra work if the new cursor image matches the old one. Signed-off-by: Michael Banack <[email protected]> Signed-off-by: Zack Rusin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-25drm/vmwgfx: Clean up cursor mobsMichael Banack2-193/+267
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: Michael Banack <[email protected]> Signed-off-by: Zack Rusin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-25drm/vmwgfx: Refactor resource validation hashtable to use linux/hashtable ↵Maaz Mombasawala5-66/+58
implementation. 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: Maaz Mombasawala <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Signed-off-by: Zack Rusin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-25drm/vmwgfx: Remove ttm object hashtableMaaz Mombasawala3-23/+9
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 <[email protected]> Reviewed-by: Zack Rusin <[email protected]> Reviewed-by: Martin Krastev <[email protected]> Signed-off-by: Zack Rusin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-25drm/vmwgfx: Refactor resource manager's hashtable to use linux/hashtable ↵Maaz Mombasawala1-36/+26
implementation. 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: Maaz Mombasawala <[email protected]> Reviewed-by: Zack Rusin <[email protected]> Reviewed-by: Martin Krastev <[email protected]> Signed-off-by: Zack Rusin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-25drm/vmwgfx: Fix frame-size warning in vmw_mksstat_add_ioctlMartin Krastev1-14/+29
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 <[email protected]> Signed-off-by: Martin Krastev <[email protected]> Reviewed-by: Zack Rusin <[email protected]> Reviewed-by: Maaz Mombasawala <[email protected]> Signed-off-by: Zack Rusin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-25drm/vmwgfx: Write the driver id registersZack Rusin1-9/+34
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: Zack Rusin <[email protected]> Reviewed-by: Martin Krastev <[email protected]> Reviewed-by: Maaz Mombasawala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-25drm/scheduler: Set the FIFO scheduling policy as the defaultLuben Tuikov1-2/+2
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 <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Direct Rendering Infrastructure - Development <[email protected]> Signed-off-by: Luben Tuikov <[email protected]> Reviewed-by: Christian König <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Christian König <[email protected]>
2022-10-25drm/connector: send hotplug uevent on connector cleanupSimon Ser1-0/+3
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: Simon Ser <[email protected]> Cc: [email protected] Cc: Daniel Vetter <[email protected]> Cc: Lyude Paul <[email protected]> Cc: Jonas Ådahl <[email protected]> Tested-by: Jonas Ådahl <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-25Revert "drm: hide unregistered connectors from GETCONNECTOR IOCTL"Simon Ser1-3/+0
This reverts commit 981f09295687f856d5345e19c7084aca481c1395. 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: Simon Ser <[email protected]> Tested-by: Jonas Ådahl <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Cc: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-25Merge tag 'drm-misc-next-2022-10-20' of ↵Dave Airlie110-1353/+3849
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 6.2: UAPI Changes: - Documentation for page-flip flags Cross-subsystem Changes: - dma-buf: Add unlocked variant of vmapping and attachment-mapping functions Core Changes: - atomic-helpers: CRTC primary plane test fixes - connector: TV API consistency improvements, cmdline parsing improvements - crtc-helpers: Introduce drm_crtc_helper_atomic_check() helper - edid: Fixes for HFVSDB parsing, - fourcc: Addition of the Vivante tiled modifier - makefile: Sort and reorganize the objects files - mode_config: Remove fb_base from drm_mode_config_funcs - sched: Add a module parameter to change the scheduling policy, refcounting fix for fences - tests: Sort the Kunit tests in the Makefile, improvements to the DP-MST tests - ttm: Remove unnecessary drm_mm_clean() call Driver Changes: - New driver: ofdrm - Move all drivers to a common dma-buf locking convention - bridge: - adv7533: Remove dynamic lane switching - it6505: Runtime PM support - ps8640: Handle AUX defer messages - tc358775: Drop soft-reset over I2C - ast: Atomic Gamma LUT Support, Convert to SHMEM, various improvements - lcdif: Support for YUV planes - mgag200: Fix PLL Setup on some revisions - udl: Modesetting improvements, hot-unplug support - vc4: Fix support for PAL-M Signed-off-by: Dave Airlie <[email protected]> From: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20221020072405.g3o4hxuk75gmeumw@houat
2022-10-24drm/i915/guc: Add compute reglist for guc err captureAlan Previn1-0/+4
We missed this at initial upstream because at that time none of the GuC enabled platforms had a compute engine. Add this now. Signed-off-by: Alan Previn <[email protected]> Reviewed-by: John Harrison <[email protected]> Signed-off-by: John Harrison <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-24drm/i915/guc: Add error-capture init warnings when neededAlan Previn1-9/+69
If GuC is being used and we initialized GuC-error-capture, we need to be warning if we don't provide an error-capture register list in the firmware ADS, for valid GT engines. A warning makes sense as this would impact debugability without realizing why a reglist wasn't retrieved and reported by GuC. However, depending on the platform, we might have certain engines that have a register list for engine instance error state but not for engine class. Thus, add a check only to warn if the register list was non existent vs an empty list (use the empty lists to skip the warning). NOTE: if a future platform were to introduce new registers in place of what was an empty list on existing / legacy hardware engines no warning is provided as the empty list is meant to be used intentionally. As an example, if a future hardware were to add blitter engine-class-registers (new) on top of the legacy blitter engine-instance-register (HEAD, TAIL, etc.), no warning is generated. Signed-off-by: Alan Previn <[email protected]> Reviewed-by: John Harrison <[email protected]> Signed-off-by: John Harrison <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-24drm/i915: Improve long running compute w/a for GuC submissionJohn Harrison2-6/+29
A workaround was added to the driver to allow compute workloads to run 'forever' by disabling pre-emption on the RCS engine for Gen12. It is not totally unbound as the heartbeat will kick in eventually and cause a reset of the hung engine. However, this does not work well in GuC submission mode. In GuC mode, the pre-emption timeout is how GuC detects hung contexts and triggers a per engine reset. Thus, disabling the timeout means also losing all per engine reset ability. A full GT reset will still occur when the heartbeat finally expires, but that is a much more destructive and undesirable mechanism. The purpose of the workaround is actually to give compute tasks longer to reach a pre-emption point after a pre-emption request has been issued. This is necessary because Gen12 does not support mid-thread pre-emption and compute tasks can have long running threads. So, rather than disabling the timeout completely, just set it to a 'long' value. v2: Review feedback from Tvrtko - must hard code the 'long' value instead of determining it algorithmically. So make it an extra CONFIG definition. Also, remove the execlist centric comment from the existing pre-emption timeout CONFIG option given that it applies to more than just execlists. Signed-off-by: John Harrison <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Acked-by: Michal Mrozek <[email protected]> Acked-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-24drm/i915: Make the heartbeat play nice with long pre-emption timeoutsJohn Harrison1-0/+39
Compute workloads are inherently not pre-emptible for long periods on current hardware. As a workaround for this, the pre-emption timeout for compute capable engines was disabled. This is undesirable with GuC submission as it prevents per engine reset of hung contexts. Hence the next patch will re-enable the timeout but bumped up by an order of magnitude. However, the heartbeat might not respect that. Depending upon current activity, a pre-emption to the heartbeat pulse might not even be attempted until the last heartbeat period. Which means that only one period is granted for the pre-emption to occur. With the aforesaid bump, the pre-emption timeout could be significantly larger than this heartbeat period. So adjust the heartbeat code to take the pre-emption timeout into account. When it reaches the final (high priority) period, it now ensures the delay before hitting reset is bigger than the pre-emption timeout. v2: Fix for selftests which adjust the heartbeat period manually. v3: Add FIXME comment about selftests. Add extra FIXME comment and drm_notices when setting heartbeat to a non-default value (review feedback from Tvrtko) Signed-off-by: John Harrison <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-24drm/i915: Fix compute pre-emption w/a to apply to compute enginesJohn Harrison1-12/+12
An earlier patch added support for compute engines. However, it missed enabling the anti-pre-emption w/a for the new engine class. So move the 'compute capable' flag earlier and use it for the pre-emption w/a test. Fixes: c674c5b9342e ("drm/i915/xehp: CCS should use RCS setup functions") Cc: Tvrtko Ursulin <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Cc: Aravind Iddamsetty <[email protected]> Cc: Matt Roper <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Lucas De Marchi <[email protected]> Cc: John Harrison <[email protected]> Cc: Jason Ekstrand <[email protected]> Cc: "Michał Winiarski" <[email protected]> Cc: Matthew Brost <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Tejas Upadhyay <[email protected]> Cc: Umesh Nerlige Ramappa <[email protected]> Cc: "Thomas Hellström" <[email protected]> Cc: Stuart Summers <[email protected]> Cc: Matthew Auld <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Ramalingam C <[email protected]> Cc: Akeem G Abodunrin <[email protected]> Signed-off-by: John Harrison <[email protected]> Reviewed-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-24drm/i915/guc: Limit scheduling properties to avoid overflowJohn Harrison5-10/+119
GuC converts the pre-emption timeout and timeslice quantum values into clock ticks internally. That significantly reduces the point of 32bit overflow. On current platforms, worst case scenario is approximately 110 seconds. Rather than allowing the user to set higher values and then get confused by early timeouts, add limits when setting these values. v2: Add helper functions for clamping (review feedback from Tvrtko). v3: Add a bunch of BUG_ON range checks in addition to the checks already in the clamping functions (Tvrtko) Signed-off-by: John Harrison <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Acked-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-24drm/client: Switch drm_client_buffer_delete() to unlocked drm_gem_vunmapDmitry Osipenko1-1/+1
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 <[email protected]> Link: https://lore.kernel.org/dri-devel/[email protected]/T/ Fixes: 79e2cf2e7a19 ("drm/gem: Take reservation lock for vmap/vunmap operations") Signed-off-by: Dmitry Osipenko <[email protected]> Acked-by: Christian König <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-24drm/i915/gt: use intel_uncore_rmw when appropriateAndrzej Hajda1-3/+1
This patch replaces all occurences of the form intel_uncore_write(reg, intel_uncore_read(reg) OP val) with intel_uncore_rmw. Signed-off-by: Andrzej Hajda <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-24drm/i915: use intel_uncore_rmw when appropriateAndrzej Hajda1-121/+66
This patch replaces all occurences of the form intel_uncore_write(reg, intel_uncore_read(reg) OP val) with intel_uncore_rmw. Signed-off-by: Andrzej Hajda <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-24drm/bridge: it6505: Improve synchronization between extcon subsystemPin-yen Lin1-7/+11
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 <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-24drm/bridge: it6505: Setup links in it6505_irq_hpdPin-yen Lin1-45/+35
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 <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-24drm/bridge: it6505: Initialize AUX channel in it6505_i2c_probePin-yen Lin1-3/+5
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: b5c84a9edcd4 ("drm/bridge: add it6505 driver") Signed-off-by: Pin-yen Lin <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-24gpu/drm: fix repeated words in commentswangjianli1-1/+1
Delete the redundant word 'the'. Signed-off-by: wangjianli <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-24gpu/drm: fix repeated words in commentswangjianli1-1/+1
Delete the redundant word 'the'. Signed-off-by: wangjianli <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-24drm/vc4: Fix spelling mistake "mmaping" -> "mmapping"Colin Ian King1-2/+2
There are a couple of spelling mistakes in DRM_DEBUG messages. Fix them. Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.