aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2023-12-19drm/i915: Ratelimit debug log in vm_fault_ttmNirmoy Das1-2/+3
Test like i915_gem_mman_live_selftests/igt_mmap_migrate can cause dmesg spamming. Use ratelimit api to reduce log rate. References: https://gitlab.freedesktop.org/drm/intel/-/issues/7038 Signed-off-by: Nirmoy Das <[email protected]> Cc: Matthew Auld <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-12-19drm/i915/gem: Atomically invalidate userptr on mmu-notifierJonathan Cavitt5-77/+0
Never block for outstanding work on userptr object upon receipt of a mmu-notifier. The reason we originally did so was to immediately unbind the userptr and unpin its pages, but since that has been dropped in commit b4b9731b02c3c ("drm/i915: Simplify userptr locking"), we never return the pages to the system i.e. never drop our page->mapcount and so do not allow the page and CPU PTE to be revoked. Based on this history, we know we are safe to drop the wait entirely. Upon return from mmu-notifier, we will still have the userptr pages pinned preventing the following PTE operation (such as try_to_unmap) adjusting the vm_area_struct, so it is safe to keep the pages around for as long as we still have i/o pending. We do not have any means currently to asynchronously revalidate the userptr pages, that is always prior to next use. Signed-off-by: Chris Wilson <[email protected]> Signed-off-by: Jonathan Cavitt <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-12-19drm/i915/hdcp: fix intel_hdcp_get_repeater_ctl() error return valueJani Nikula1-2/+2
intel_hdcp_get_repeater_ctl() is supposed to return unsigned register contents. Returning negative error values is unexpected, and none of the callers check for that. Sort of fix the error cases by returning 0. I don't think we should hit these cases anyway, and using 0 for the registers is safer than 0xffffffea (-EINVAL). Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-12-19drm/i915/hdcp: unify connector logging formatJani Nikula1-34/+34
It's customary to debug log connectors using [CONNECTOR:%d:%s] format. Make the HDCP code follow suit. Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-12-19drm/bridge: ps8640: Fix size mismatch warning w/ lenDouglas Anderson1-1/+1
After commit 26195af57798 ("drm/bridge: ps8640: Drop the ability of ps8640 to fetch the EDID"), I got an error compiling: error: comparison of distinct pointer types ('typeof (len) *' (aka 'unsigned int *') and 'typeof (msg->size) *' (aka 'unsigned long *')) [-Werror,-Wcompare-distinct-pointer-types] Fix it by declaring the `len` as size_t. The above error only shows up on downstream kernels without commit d03eba99f5bf ("minmax: allow min()/max()/clamp() if the arguments have the same signedness."), but since commit 26195af57798 ("drm/bridge: ps8640: Drop the ability of ps8640 to fetch the EDID") is a "Fix" that will likely be backported it seems nice to make it easy. ...plus it's more correct to declare `len` as size_t anyway. Fixes: 26195af57798 ("drm/bridge: ps8640: Drop the ability of ps8640 to fetch the EDID") Reviewed-by: Stephen Boyd <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20231218090454.1.I5c6eb80b2f746439c4b58efab788e00701d08759@changeid
2023-12-19Merge tag 'drm-misc-next-2023-12-14' of ↵Dave Airlie38-270/+2257
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for $kernel-version: UAPI Changes: Cross-subsystem Changes: - A few fixes for usb/typec Core Changes: - ci: Updates to the defconfig, igt version, etc. - writeback: Move the atomic_check helper from the encoder to connector Driver Changes: - rockchip: Add support for rk3588 - xe: Update the TODO list - panel: - nv3052c: Register documentation, init sequence improvements and support for the Fascontek FS035VG158 - st7701: Add support for the Anbernic RG-ARC - new driver: Synaptics R63353 panel controller, Ilitek ILI9805 panel controller - new panel: AUO G156HAN04.0 Signed-off-by: Dave Airlie <[email protected]> From: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/aqpn5miejmkks7pbcfex7b6u63uwsruywxsnr3x5ljs45qatin@nbkkej2elk46
2023-12-19drm/bridge: properly refcount DT nodes in aux bridge driversDmitry Baryshkov2-3/+4
The aux-bridge and aux-hpd-bridge drivers didn't call of_node_get() on the device nodes further used for dev->of_node and platform data. When bridge devices are released, the reference counts are decreased, resulting in refcount underflow / use-after-free warnings. Get corresponding refcounts during AUX bridge allocation. Reported-by: Luca Weiss <[email protected]> Fixes: 2a04739139b2 ("drm/bridge: add transparent bridge helper") Fixes: 26f4bac3d884 ("drm/bridge: aux-hpd: Replace of_device.h with explicit include") Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-12-18drm/panel-edp: Add several generic edp panelsXuxin Xiong1-0/+4
Add support for the following 3 panels: 1. BOE NV116WHM-N49 V8.0 2. BOE NV122WUM-N41 3. CSO MNC207QS1-1 Signed-off-by: Xuxin Xiong <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20231218095933.2487360-1-xuxinxiong@huaqin.corp-partner.google.com
2023-12-18drm/tests: Switch to kunit devicesMaxime Ripard1-63/+3
Kunit recently gained helpers to create test managed devices. This means that we no longer have to roll our own helpers in KMS and we can reuse them. Signed-off-by: Maxime Ripard <[email protected]> Tested-by: David Gow <[email protected]> Signed-off-by: David Gow <[email protected]> Signed-off-by: Shuah Khan <[email protected]>
2023-12-18drm/vc4: tests: Use KUNIT_DEFINE_ACTION_WRAPPERDavid Gow1-6/+3
In order to pass functions to kunit_add_action(), they need to be of the kunit_action_t type. While casting the function pointer can work, it will break control-flow integrity. vc4_mock already defines such a wrapper for drm_dev_unregister(), but it involves less boilerplate to use the new macro, so replace the manual implementation. Signed-off-by: David Gow <[email protected]> Reviewed-by: Maxime Ripard <[email protected]> Signed-off-by: Shuah Khan <[email protected]>
2023-12-18drm/tests: Use KUNIT_DEFINE_ACTION_WRAPPER()David Gow1-21/+9
In order to pass functions to kunit_add_action(), they need to be of the kunit_action_t type. While casting the function pointer can work, it will break control-flow integrity. drm_kunit_helpers already defines wrappers, but we now have a macro which does this automatically. Using this greatly reduces the boilerplate needed. Acked-by: Maxime Ripard <[email protected]> Signed-off-by: David Gow <[email protected]> Signed-off-by: Shuah Khan <[email protected]>
2023-12-18drm/bridge: ti-sn65dsi86: Never store more than msg->size bytes in AUX xferDouglas Anderson1-1/+3
For aux reads, the value `msg->size` indicates the size of the buffer provided by `msg->buffer`. We should never in any circumstances write more bytes to the buffer since it may overflow the buffer. In the ti-sn65dsi86 driver there is one code path that reads the transfer length from hardware. Even though it's never been seen to be a problem, we should make extra sure that the hardware isn't increasing the length since doing so would cause us to overrun the buffer. Fixes: 982f589bde7a ("drm/bridge: ti-sn65dsi86: Update reply on aux failures") Reviewed-by: Stephen Boyd <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20231214123752.v3.2.I7b83c0f31aeedc6b1dc98c7c741d3e1f94f040f8@changeid
2023-12-18drm/bridge: parade-ps8640: Never store more than msg->size bytes in AUX xferDouglas Anderson1-2/+3
While testing, I happened to notice a random crash that looked like: Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: drm_dp_dpcd_probe+0x120/0x120 Analysis of drm_dp_dpcd_probe() shows that we pass in a 1-byte buffer (allocated on the stack) to the aux->transfer() function. Presumably if the aux->transfer() writes more than one byte to this buffer then we're in a bad shape. Dropping into kgdb, I noticed that "aux->transfer" pointed at ps8640_aux_transfer(). Reading through ps8640_aux_transfer(), I can see that there are cases where it could write more bytes to msg->buffer than were specified by msg->size. This could happen if the hardware reported back something bogus to us. Let's fix this so we never write more than msg->size bytes. We'll still read all the bytes from the hardware just in case the hardware requires it since the aux transfer data comes through an auto-incrementing register. NOTE: I have no actual way to reproduce this issue but it seems likely this is what was happening in the crash I looked at. Fixes: 13afcdd7277e ("drm/bridge: parade-ps8640: Add support for AUX channel") Reviewed-by: Stephen Boyd <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20231214123752.v3.1.I9d1afcaad76a3e2c0ca046dc4adbc2b632c22eda@changeid
2023-12-18drm/panel-edp: Add some panels with conservative timingsPin-yen Lin1-0/+31
These panels are used by Mediatek MT8173 Chromebooks, and they used to work with the downstream v4.19 kernel without any specified delay. Back in the v4.19 kernel, they used the "little white lie" approach, which is making the devicetree claim a specific panel's compatible string for many different panels. That was a common solution before the generic edp-panel driver. After we uprevved the device to a newer kernel and used the edp-panel driver, we saw multiple devices reporting warnings of using an unknown panel and falling back to the conservative timings, which means that they turn on/off much more slowly than they should. We tried to fill in the timings for those panels, but we failed to find all the data sheets for them. Therefore, instead of having them use the default conservative timings, update them with less-conservative timings from other panels of the same vendor. The panels should still work under those timings, and we can save some delays and suppress the warnings. Signed-off-by: Pin-yen Lin <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-12-18drm/edp-panel: Add panels delay entriesPin-yen Lin1-0/+39
Add panels used by Mediatek MT8173 Chromebooks. Signed-off-by: Pin-yen Lin <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-12-18drm/panel-edp: Add powered_on_to_enable delayPin-yen Lin1-0/+20
Add the support of powered_on_to_enable delay as the minimum time that needs to have passed between the panel powered on and enable may begin. This delay is seen in BOE panels as the minimum delay of T3+T4+T5+T6+T8 in the eDP timing diagrams. Signed-off-by: Pin-yen Lin <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-12-18drm/mediatek: dp: Add phy_mtk_dp module as pre-dependencyNícolas F. R. A. Prado1-0/+1
The mtk_dp driver registers a phy device which is handled by the phy_mtk_dp driver and assumes that the phy probe will complete synchronously, proceeding to make use of functionality exposed by that driver right away. This assumption however is false when the phy driver is built as a module, causing the mtk_dp driver to fail probe in this case. Add the phy_mtk_dp module as a pre-dependency to the mtk_dp module to ensure the phy module has been loaded before the dp, so that the phy probe happens synchrounously and the mtk_dp driver can probe successfully even with the phy driver built as a module. Suggested-by: AngeloGioacchino Del Regno <[email protected]> Fixes: f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver") Signed-off-by: Nícolas F. R. A. Prado <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Guillaume Ranquet <[email protected]> Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/ Signed-off-by: Chun-Kuang Hu <[email protected]>
2023-12-18drm/i915/dmc: Don't enable any pipe DMC eventsVille Syrjälä1-2/+41
The pipe DMC seems to be making a mess of things in ADL. Various weird symptoms have been observed such as missing vblank irqs, typicalle happening when using multiple displays. Keep all pipe DMC event handlers disabled until needed (which is never atm). This is also what Windows does on ADL+. We can also drop DG2 from disable_all_flip_queue_events() since on DG2 the pipe DMC is the one that handles the flip queue events. Cc: [email protected] Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8685 Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Imre Deak <[email protected]> (cherry picked from commit 648d7be8ecf47b0556e32550145c70db153b16fb) Signed-off-by: Jani Nikula <[email protected]>
2023-12-18drm/i915/mtl: Fix HDMI/DP PLL clock selectionImre Deak1-1/+2
Select the HDMI specific PLL clock only for HDMI outputs. Fixes: 62618c7f117e ("drm/i915/mtl: C20 PLL programming") Cc: Mika Kahola <[email protected]> Cc: Radhakrishna Sripada <[email protected]> Reviewed-by: Radhakrishna Sripada <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 937d02cc79c6828fef28a4d80d8d0ad2f7bf2b62) Signed-off-by: Jani Nikula <[email protected]>
2023-12-18drm/i915: Reject async flips with bigjoinerVille Syrjälä1-0/+11
Currently async flips are busted when bigjoiner is in use. As a short term fix simply reject async flips in that case. Cc: [email protected] Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9769 Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Stanislav Lisovskiy <[email protected]> (cherry picked from commit e93bffc2ac0a833b42841f31fff955549d38ce98) Signed-off-by: Jani Nikula <[email protected]>
2023-12-18drm/i915/hwmon: Fix static analysis tool reported issuesKarthik Poosa1-2/+2
Updated i915 hwmon with fixes for issues reported by static analysis tool. Fixed integer overflow with upcasting. v2: - Added Fixes tag (Badal). - Updated commit message as per review comments (Anshuman). Fixes: 4c2572fe0ae7 ("drm/i915/hwmon: Expose power1_max_interval") Reviewed-by: Badal Nilawar <[email protected]> Reviewed-by: Anshuman Gupta <[email protected]> Signed-off-by: Karthik Poosa <[email protected]> Signed-off-by: Anshuman Gupta <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit ac3420d3d428443a08b923f9118121c170192b62) Signed-off-by: Jani Nikula <[email protected]>
2023-12-18drm/i915/display: Get bigjoiner config before dsc config during readoutAnkit Nautiyal1-1/+1
Currently we get bigjoiner config after the dsc get config, during HW readout. Since dsc_get_config now uses bigjoiner flags/pipes to compute DSC PPS parameter pic_width, this results in a state mismatch when Bigjoiner and DSC are used together. So call get bigjoiner config before calling dsc get config function. Fixes: 8b70b5691704 ("drm/i915/vdsc: Fill the intel_dsc_get_pps_config function") Cc: Suraj Kandpal <[email protected]> Cc: Ankit Nautiyal <[email protected]> Cc: Animesh Manna <[email protected]> Cc: Jani Nikula <[email protected]> Signed-off-by: Ankit Nautiyal <[email protected]> Reviewed-by: Suraj Kandpal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit baf31a20fa7f3538d68ffa5262a715eb1d699cdd) Signed-off-by: Jani Nikula <[email protected]>
2023-12-18drm/mm: Allow CONFIG_DRM_MM_DEBUG with DRM=mVille Syrjälä1-1/+1
The original rationale for commit cd456f8d06d2 ("drm: Restrict stackdepot usage to builtin drm.ko") was that depot_save_stack() (which is what we used back then) wasn't exported. stack_depot_save() (which is what we use now) is exported however, so relax the dependency allow CONFIG_DRM_MM_DEBUG with DRM=m. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Javier Martinez Canillas <[email protected]>
2023-12-18drm/i915/display: Remove dead code around intel_atomic_helper->free_listJouni Högander4-35/+0
After switching to directly using dma_fence instead of i915_sw_fence we have left some dead code around intel_atomic_helper->free_list. Remove that dead code. v2: Remove intel_atomic_state->freed as well Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-12-18drm/i915/dmc: Print out the DMC mmio register list at fw load timeVille Syrjälä1-0/+18
To help with debugging print out the mmio list contained in the DMC firmware. Also highlight the event registers, and whether we're going to disable them or not. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Imre Deak <[email protected]>
2023-12-18drm/i915/dmc: Also disable HRR event on TGL/ADLS main DMCVille Syrjälä2-0/+6
Unlike later platforms TGL/ADLS has the half refresh rate (HRR) event on the main DMC (as opposed to the pipe DMC). Since we're disabling that event on all later platforms already let's do the same on TGL/ADLS as well. There is supposedly a bit somewhere (DMC_CHICKEN on TGL) to make the handler not do anything, but we don't currently have code to frob it. Though that bit should be off by default, the ADL+ experience has shown us that trusting any of this isn't a good idea. So seems safer to just disable all event handlers we know that we don't need. Also the TGL/ADLS DMC firmware is apparently using the wrong event (undelayed vblank) here anyway. It should be using the delayed vblank event instead (like ADL+ firmware does), but they didn't release a firmware fix for this and instead just hacked around this in the Windows driver code :/ v2: Also disable the event on ADLS (Imre) Cc: Imre Deak <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Imre Deak <[email protected]>
2023-12-18drm/i915/dmc: Also disable the flip queue event on TGL main DMCVille Syrjälä1-78/+5
Unlike later platforms TGL has its flip queue event (CLK_MSEC) on the main DMC (as opposed to the pipe DMC). Currently we're doing a second pass to disable that, but let's just follow the same approach as the later platforms and never even enable the event in the first place. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Imre Deak <[email protected]>
2023-12-18drm/i915/dmc: Don't enable any pipe DMC eventsVille Syrjälä1-2/+41
The pipe DMC seems to be making a mess of things in ADL. Various weird symptoms have been observed such as missing vblank irqs, typicalle happening when using multiple displays. Keep all pipe DMC event handlers disabled until needed (which is never atm). This is also what Windows does on ADL+. We can also drop DG2 from disable_all_flip_queue_events() since on DG2 the pipe DMC is the one that handles the flip queue events. Cc: [email protected] Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8685 Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Imre Deak <[email protected]>
2023-12-17drivers/gpu/drm/i915/i915_memcpy.c: fix missing includesKent Overstreet1-0/+2
Signed-off-by: Kent Overstreet <[email protected]>
2023-12-15drm/amd/display: Revert " drm/amd/display: Use channel_width = 2 for vram ↵Alvin Lee1-7/+1
table 3.0" [Description] Revert commit fec05adc40c2 ("drm/amd/display: Use channel_width = 2 for vram table 3.0") Because the issue is being fixed from VBIOS side. Reviewed-by: Samson Tam <[email protected]> Acked-by: Wayne Lin <[email protected]> Signed-off-by: Alvin Lee <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-12-15drm/amd/display: remove HPO PG in driver sideMuhammad Ahmed1-0/+1
[why & how] Add config to make HPO PG handled in dmubfw ips entry/exit Reviewed-by: Charlene Liu <[email protected]> Acked-by: Wayne Lin <[email protected]> Signed-off-by: Muhammad Ahmed <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-12-15drm/amd/display: do not send commands to DMUB if DMUB is inactive from S3Samson Tam5-0/+55
[Why] On resume from S3, may get apply_idle_optimizations call while DMUB is inactive which will just time out. [How] Set and track power state in dmub_srv and check power state before sending commands to DMUB. Add interface in both dmub_srv and dc_dmub_srv Reviewed-by: Nicholas Kazlauskas <[email protected]> Acked-by: Wayne Lin <[email protected]> Signed-off-by: Samson Tam <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-12-15drm/amd/swsmu: remove duplicate definition of smu v14_0_0 driver if versionLi Ma2-6/+1
There is a repeated define of smu v14_0_0 driver if version, so delete one in driver if header. Signed-off-by: Li Ma <[email protected]> Reviewed-by: Kenneth Feng <[email protected]> Reviewed-by: Yifan Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-12-15drm/amdgpu: make an improvement on amdgpu_hmm_range_get_pagesJames Zhu1-1/+1
Only schedule when hmm_range_fault returns error. Signed-off-by: James Zhu <[email protected]> Acked-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-12-15drm/amdgpu: increase hmm range get pages timeoutJames Zhu1-2/+2
When application tries to allocate all system memory and cause memory to swap out. Needs more time for hmm_range_fault to validate the remaining page for allocation. To be safe, increase timeout value to 1 second for 64MB range. Signed-off-by: James Zhu <[email protected]> Acked-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-12-15drm/amdkfd: svm range always mapped flag not working on APUPhilip Yang1-6/+12
On gfx943 APU there is no VRAM and page migration, queue CWSR area, svm range with always mapped flag, is not mapped to GPU correctly. This works fine if retry fault on CWSR area can be recovered, but could cause deadlock if there is another retry fault recover waiting for CWSR to finish. Fix this by mapping svm range with always mapped flag to GPU with ACCESS attribute if XNACK ON. There is side effect, because all GPUs have ACCESS attribute by default on new svm range with XNACK on, the CWSR area will be mapped to all GPUs after this change. This side effect will be fixed with Thunk change to set CWSR svm range with ACCESS_IN_PLACE attribute on the GPU that user queue is created. Signed-off-by: Philip Yang <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-12-15drm/amdkfd: only flush mes process context if mes support is thereJonathan Kim1-1/+2
Fix up on mes process context flush to prevent non-mes devices from spamming error messages or running into undefined behaviour during process termination. Fixes: bd33bb1409b4 ("drm/amdkfd: fix mes set shader debugger process management") Signed-off-by: Jonathan Kim <[email protected]> Reviewed-by: Eric Huang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-12-15drm/bridge: samsung-dsim: check the return value only if necessaryDario Binacchi1-4/+4
It was useless to check again the "ret" variable if the function register_host() was not called. Signed-off-by: Dario Binacchi <[email protected]> Reviewed-by: Frieder Schrempf <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-12-15drm/bridge: tc358767: Add descriptions to register definitionsAlexander Stein1-15/+15
Use the register names from the datasheet. No functional change intended. Signed-off-by: Alexander Stein <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-12-15drm/bridge: tc358767: Add precious register SYSSTATAlexander Stein1-0/+10
This is the single register which clears its value upon read operation. Signed-off-by: Alexander Stein <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-12-15drm/bridge: tc358767: Add more volatile registersAlexander Stein1-0/+7
These registers might change their value without any host write operation. Signed-off-by: Alexander Stein <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-12-15drm/bridge: tc358767: Sort volatile registers according to addressAlexander Stein1-3/+3
Sort the list by the starting address to ease adding new entries. No functional change intended. Signed-off-by: Alexander Stein <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-12-15drm/bridge: tc358767: Add more registers to non-writeable rangeAlexander Stein1-6/+81
While at it, also add missing register definitions. HDCP registers are skipped as they are not named, range 0x0980 - 0x09ac. Signed-off-by: Alexander Stein <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-12-15drm/bridge: tc358767: Fix order of register definesAlexander Stein1-7/+7
0x0510 is bigger than 0x50c, order them accordingly. No functional change intended. Signed-off-by: Alexander Stein <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-12-15drm/bridge: tc358767: Use regmap_access_table for writeable registersAlexander Stein1-7/+10
Using ranges it is easier to add more register where writing is not allowed, especially for sequences of registers. Signed-off-by: Alexander Stein <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-12-15drm/imagination: Fix error path in pvr_vm_create_contextDonald Robson1-15/+13
It is possible to double free the vm_ctx->mmu_ctx object in this function.     630 err_page_table_destroy: --> 631         pvr_mmu_context_destroy(vm_ctx->mmu_ctx); The pvr_vm_context_put() function does:         kref_put(&vm_ctx->ref_count, pvr_vm_context_release); Here the pvr_vm_context_release() will call:         pvr_mmu_context_destroy(vm_ctx->mmu_ctx); Refactor to an unwind style. Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Donald Robson <[email protected]> Reviewed-by: Dan Carpenter <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-12-15drm/imagination: Fix ERR_PTR test on pointer to pointer.Donald Robson1-1/+1
drivers/gpu/drm/imagination/pvr_vm.c:631 pvr_vm_create_context() error: 'vm_ctx->mmu_ctx' dereferencing possible ERR_PTR() 612 vm_ctx->mmu_ctx = pvr_mmu_context_create(pvr_dev); 613 err = PTR_ERR_OR_ZERO(&vm_ctx->mmu_ctx); ^ The address is never an error pointer so this will always return 0. Remove the ampersand. Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Donald Robson <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-12-15drm/imagination: Fixed oops when misusing ioctl CREATE_HWRT_DATASETDonald Robson1-13/+14
While writing the matching IGT suite I discovered that it's possible to cause a kernel oops when using DRM_IOCTL_PVR_CREATE_HWRT_DATASET when the call to hwrt_init_common_fw_structure() fails. Use an unwind-type error path to avoid cleaning up the object using the the release function before it is fully resolved. Signed-off-by: Donald Robson <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-12-15drm/imagination: Fixed infinite loop in pvr_vm_mips_map()Donald Robson1-3/+3
Unwinding loop in error path for this function uses unsigned limit variable, causing the promotion of the signed counter variable. --> 204 for (; pfn >= start_pfn; pfn--) ^^^^^^^^^^^^^^^^ If start_pfn can be zero then this is an endless loop. I've seen this code in other places as well. This loop is slightly off as well. It should decrement pfn on the first iteration. Fix by making the loop limit variables signed. Also fix missing predecrement by modifying to while loop. Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Donald Robson <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-12-15drm/i915: Use kmap_local_page() in gem/i915_gem_execbuffer.cZhao Liu1-5/+5
The use of kmap_atomic() is being deprecated in favor of kmap_local_page()[1], and this patch converts the calls from kmap_atomic() to kmap_local_page(). The main difference between atomic and local mappings is that local mappings doesn't disable page faults or preemption (the preemption is disabled for !PREEMPT_RT case, otherwise it only disables migration). With kmap_local_page(), we can avoid the often unwanted side effect of unnecessary page faults and preemption disables. In i915_gem_execbuffer.c, eb->reloc_cache.vaddr is mapped by kmap_atomic() in eb_relocate_entry(), and is unmapped by kunmap_atomic() in reloc_cache_reset(). And this mapping/unmapping occurs in two places: one is in eb_relocate_vma(), and another is in eb_relocate_vma_slow(). The function eb_relocate_vma() or eb_relocate_vma_slow() doesn't need to disable pagefaults and preemption during the above mapping/ unmapping. So it can simply use kmap_local_page() / kunmap_local() that can instead do the mapping / unmapping regardless of the context. Convert the calls of kmap_atomic() / kunmap_atomic() to kmap_local_page() / kunmap_local(). [1]: https://lore.kernel.org/all/[email protected] Suggested-by: Ira Weiny <[email protected]> Suggested-by: Fabio M. De Francesco <[email protected]> Signed-off-by: Zhao Liu <[email protected]> Reviewed-by: Ira Weiny <[email protected]> Reviewed-by: Fabio M. De Francesco <[email protected]> Signed-off-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.