summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2024-07-30Merge drm/drm-fixes into drm-misc-fixesMaxime Ripard
Let's start the new drm-misc-fixes cycle by bringing in 6.11-rc1. Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-07-29drm/xe/xe2hpg: Introduce performance tuning changes for Xe2_HPGSai Teja Pottumuttu
Add performance tuning changes for Xe2_HPG Bspec: 72161 Signed-off-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240724121521.2347524-1-sai.teja.pottumuttu@intel.com
2024-07-29drm/xe: Migrate OOB WAs to OR rulesLucas De Marchi
Now that rtp has OR rules, it's not needed to extend it to process OOB WAs. Previously if an entry had no name, it was considered as "a set of rules OR'ed with the last named entry". Instead of generating new entries, add OR rules. The syntax for xe_wa_oob.rules remains the same, with xe_gen_wa_oob generating the slightly different table. Object sizes delta are negligible, but having just one logic makes it easier to maintain: add/remove: 0/0 grow/shrink: 1/2 up/down: 160/-269 (-109) Function old new delta __compound_literal 6104 6264 +160 xe_wa_dump 1839 1810 -29 oob_was 816 576 -240 Total: Before=17257, After=17148, chg -0.63% Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240727015907.899192-9-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-07-29drm/xe/rtp: Expand max rules/actions per entry againLucas De Marchi
Like commit 512660cd1f1a ("drm/xe/rtp: Expand max rules/actions per entry") did, expand the maximum number of actions/rules. That commit was too conservative, just incrementing 2. Other than the ugliness of these macros and additional preprocessor steps when they are used, there are no downsides on increasing the maximum: the tables in which they are used use a sentinel to mark the last element. With rtp processing now supporting OR rules, it's possible to migrate the extension made for OOB WAs that "entries with name are OR'ed in previous entry". For that the maximum number of rules needs to be increased. Just double it. Hopefully 12 is sufficient for longer than 6 was. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240727015907.899192-8-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-07-29drm/xe/rtp: Simplify marking active workaroundsLucas De Marchi
Stop doing the calculation both in rtp_mark_active() and in its caller. The caller easily knows the number of entries to mark, so just pass it forward. That also simplifies rtp_mark_active() since now it doesn't have a special case when handling 1 entry. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240727015907.899192-7-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-07-29drm/xe/kunit: Test rtp with no actionsLucas De Marchi
The OOB WAs use xe_rtp_process(), without passing an sr to save result of the actions since there are none. They are also executed in a gt-only context, making it harder to share the implementation. Thus, introduce a new set of tests to check these RTP entries. The only check that can be done is if the entry was marked as active. Before commit fd6797ec50c5 ("drm/xe/rtp: Fix off-by-one when processing rules") several of these tests were failing: the processing of OR'ed entries would make the subsequent entry to be inadvertently enabled. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240727015907.899192-6-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-07-29drm/xe/kunit: Rename rtp test casesLucas De Marchi
Those tests check the behavior of xe_rtp_process_to_sr(), so name them accordingly to allow adding tests for xe_rtp_process() later. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240727015907.899192-5-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-07-29drm/xe/kunit: Test active rtp entriesLucas De Marchi
Enabling active tracking in the rtp context and check for all the tests the expected entries become active. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240727015907.899192-4-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-07-29drm/xe/kunit: Rename count to count_sr_entriesLucas De Marchi
The RTP tests check both the result of processing the RTP entries and the outcome saved as SR entries. Rename "count" to be explicit about what's being counted. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240727015907.899192-3-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-07-29drm/xe/kunit: Test WAs for BMGLucas De Marchi
Add one variant for BMG to make sure the workarounds do not conflict. This matches the machine with BMG in CI: BATTLEMAGE e20b:0000 dgfx:1 gfx:Xe2_LPG / Xe2_HPG (20.01) media:Xe2_LPM / Xe2_HPM (13.01) display:yes dma_m_s:46 tc:1 gscfi:0 cscfi:1 Stepping = (G:A0, M:A1, D:**, B:**) Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240727015907.899192-2-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-07-29drm/xe/migrate: Future-proof compressed PAT checkMatt Roper
Although all current Xe2 platforms support FlatCCS, we probably shouldn't assume that will be universally true forever. In the past we've had platforms like PVC that didn't support compression, and the same could show up again at some point in the future. Future-proof the migration code by adding an explicit check for FlatCCS support to the condition that decides whether to use a compressed PAT index for migration. While we're at it, we can drop the IS_DGFX check since it's redundant with the src_is_vram check (only dGPUs have VRAM). Cc: Akshata Jahagirdar <akshata.jahagirdar@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Akshata Jahagirdar <akshata.jahagirdar@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240726171757.2728819-2-matthew.d.roper@intel.com
2024-07-29drm/xe: Fix opregion leakLucas De Marchi
Being part o the display, ideally the setup and cleanup would be done by display itself. However this is a bigger refactor that needs to be done on both i915 and xe. For now, just fix the leak: unreferenced object 0xffff8881a0300008 (size 192): comm "modprobe", pid 4354, jiffies 4295647021 hex dump (first 32 bytes): 00 00 87 27 81 88 ff ff 18 80 9b 00 00 c9 ff ff ...'............ 18 81 9b 00 00 c9 ff ff 00 00 00 00 00 00 00 00 ................ backtrace (crc 99260e31): [<ffffffff823ce65b>] kmemleak_alloc+0x4b/0x80 [<ffffffff81493be2>] kmalloc_trace_noprof+0x312/0x3d0 [<ffffffffa1345679>] intel_opregion_setup+0x89/0x700 [xe] [<ffffffffa125bfaf>] xe_display_init_noirq+0x2f/0x90 [xe] [<ffffffffa1199ec3>] xe_device_probe+0x7a3/0xbf0 [xe] [<ffffffffa11f3713>] xe_pci_probe+0x333/0x5b0 [xe] [<ffffffff81af6be8>] local_pci_probe+0x48/0xb0 [<ffffffff81af8778>] pci_device_probe+0xc8/0x280 [<ffffffff81d09048>] really_probe+0xf8/0x390 [<ffffffff81d0937a>] __driver_probe_device+0x8a/0x170 [<ffffffff81d09503>] driver_probe_device+0x23/0xb0 [<ffffffff81d097b7>] __driver_attach+0xc7/0x190 [<ffffffff81d0628d>] bus_for_each_dev+0x7d/0xd0 [<ffffffff81d0851e>] driver_attach+0x1e/0x30 [<ffffffff81d07ac7>] bus_add_driver+0x117/0x250 Fixes: 44e694958b95 ("drm/xe/display: Implement display support") Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240724215309.644423-1-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-07-29drm/nouveau: remove unused variable retJani Nikula
Fix build with CONFIG_NOUVEAU_PLATFORM_DRIVER enabled: ../drivers/gpu/drm/nouveau/nouveau_platform.c: In function ‘nouveau_platform_probe’: ../drivers/gpu/drm/nouveau/nouveau_platform.c:29:13: error: unused variable ‘ret’ [-Werror=unused-variable] 29 | int ret; | ^~~ Fixes: 961ae5f9807b ("drm/nouveau: handle pci/tegra drm_dev_{alloc, register} from common code") Cc: Ben Skeggs <bskeggs@nvidia.com> Cc: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240729123624.868907-1-jani.nikula@intel.com
2024-07-29i915/perf: Remove code to update PWR_CLK_STATE for gen12Umesh Nerlige Ramappa
PWR_CLK_STATE only needs to be modified up until gen11. For gen12 this code is not applicable. Remove code to update context image with PWR_CLK_STATE for gen12. Fixes: 00a7f0d7155c ("drm/i915/tgl: Add perf support on TGL") Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240629005643.3050678-1-umesh.nerlige.ramappa@intel.com (cherry picked from commit 7b5bdae7740eb6a3d09f9cd4e4b07362a15b86b3) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2024-07-29Merge drm/drm-next into drm-misc-nextThomas Zimmermann
Backmerging to get a late RC of v6.10 before moving into v6.11. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2024-07-29drm/gma500: Make I2C terminology more inclusiveEaswar Hariharan
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave" with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/, fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists in the specification. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240711052734.1273652-3-eahariha@linux.microsoft.com
2024-07-29drm/client: Fix error code in drm_client_buffer_vmap_local()Dan Carpenter
This function accidentally returns zero/success on the failure path. It leads to locking issues and an uninitialized *map_copy in the caller. Fixes: b4b0193e83cb ("drm/fbdev-generic: Fix locking with drm_client_buffer_vmap_local()") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/89d13df3-747c-4c5d-b122-d081aef5110a@stanley.mountain
2024-07-28minmax: don't use max() in situations that want a C constant expressionLinus Torvalds
We only had a couple of array[] declarations, and changing them to just use 'MAX()' instead of 'max()' fixes the issue. This will allow us to simplify our min/max macros enormously, since they can now unconditionally use temporary variables to avoid using the argument values multiple times. Cc: David Laight <David.Laight@aculab.com> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-07-28minmax: make generic MIN() and MAX() macros available everywhereLinus Torvalds
This just standardizes the use of MIN() and MAX() macros, with the very traditional semantics. The goal is to use these for C constant expressions and for top-level / static initializers, and so be able to simplify the min()/max() macros. These macro names were used by various kernel code - they are very traditional, after all - and all such users have been fixed up, with a few different approaches: - trivial duplicated macro definitions have been removed Note that 'trivial' here means that it's obviously kernel code that already included all the major kernel headers, and thus gets the new generic MIN/MAX macros automatically. - non-trivial duplicated macro definitions are guarded with #ifndef This is the "yes, they define their own versions, but no, the include situation is not entirely obvious, and maybe they don't get the generic version automatically" case. - strange use case #1 A couple of drivers decided that the way they want to describe their versioning is with #define MAJ 1 #define MIN 2 #define DRV_VERSION __stringify(MAJ) "." __stringify(MIN) which adds zero value and I just did my Alexander the Great impersonation, and rewrote that pointless Gordian knot as #define DRV_VERSION "1.2" instead. - strange use case #2 A couple of drivers thought that it's a good idea to have a random 'MIN' or 'MAX' define for a value or index into a table, rather than the traditional macro that takes arguments. These values were re-written as C enum's instead. The new function-line macros only expand when followed by an open parenthesis, and thus don't clash with enum use. Happily, there weren't really all that many of these cases, and a lot of users already had the pattern of using '#ifndef' guarding (or in one case just using '#undef MIN') before defining their own private version that does the same thing. I left such cases alone. Cc: David Laight <David.Laight@aculab.com> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-07-28minmax: add a few more MIN_T/MAX_T usersLinus Torvalds
Commit 3a7e02c040b1 ("minmax: avoid overly complicated constant expressions in VM code") added the simpler MIN_T/MAX_T macros in order to avoid some excessive expansion from the rather complicated regular min/max macros. The complexity of those macros stems from two issues: (a) trying to use them in situations that require a C constant expression (in static initializers and for array sizes) (b) the type sanity checking and MIN_T/MAX_T avoids both of these issues. Now, in the whole (long) discussion about all this, it was pointed out that the whole type sanity checking is entirely unnecessary for min_t/max_t which get a fixed type that the comparison is done in. But that still leaves min_t/max_t unnecessarily complicated due to worries about the C constant expression case. However, it turns out that there really aren't very many cases that use min_t/max_t for this, and we can just force-convert those. This does exactly that. Which in turn will then allow for much simpler implementations of min_t()/max_t(). All the usual "macros in all upper case will evaluate the arguments multiple times" rules apply. We should do all the same things for the regular min/max() vs MIN/MAX() cases, but that has the added complexity of various drivers defining their own local versions of MIN/MAX, so that needs another level of fixes first. Link: https://lore.kernel.org/all/b47fad1d0cf8449886ad148f8c013dae@AcuMS.aculab.com/ Cc: David Laight <David.Laight@aculab.com> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-07-27drm/amdgpu: Fix APU handling in amdgpu_pm_load_smu_firmware()Alex Deucher
We only need to skip this on modern APUs. It's required on older APUs as it's where start_smu gets called from. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3502 Fixes: 064d92436b69 ("drm/amd/pm: avoid to load smu firmware for APUs") Reviewed-by: Tim Huang <tim.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Tim Huang <Tim.Huang@amd.com> (cherry picked from commit 608d886c978cd5f3d8650630568d96c231845227)
2024-07-27drm/amdgpu: increase mes log buffer size for gfx12Michael Chen
MES firmware requires larger log buffer for gfx12. Allocate proper buffer respectively for gfx11 and gfx12. Signed-off-by: Michael Chen <michael.chen@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 739d0f3e1f36738d4cd84166784a8f7a58d69612)
2024-07-27drm/amdgpu: fix contiguous handling for IB parsing v2Christian König
Otherwise we won't get correct access to the IB. v2: keep setting AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS to avoid problems in the VRAM backend. Signed-off-by: Christian König <christian.koenig@amd.com> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3501 Fixes: e362b7c8f8c7 ("drm/amdgpu: Modify the contiguous flags behaviour") Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Tested-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit fbfb5f0342253d92c4e446588c428a9d90c3f610)
2024-07-27drm/amdgpu/pm: support gpu_metrics sysfs interface for smu v14.0.2/3Kenneth Feng
support gpu_metrics sysfs interface for smu v14.0.2/3 Signed-off-by: Kenneth Feng <kenneth.feng@amd.com> Reviewed-by: Yang Wang <kevinyang.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 60c30ba7ba2064066ec462236666058cbbf619c1)
2024-07-27drm/amd/display: Add new enable and disable functions for DCN35Hansen Dsouza
Add new enable and disable functions based on DCCG spec. Signed-off-by: Hansen Dsouza <Hansen.Dsouza@amd.com> Reviewed-by: Muhammad Ahmed <ahmed.ahmed@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-27drm/amd/display: Use gpuvm_min_page_size_kbytes for DML2 surfacesNicholas Kazlauskas
[Why] It's currently hard coded to 256 when it should be using the SOC provided values. This can result in corruption with linear surfaces where we prefetch more PTE than the buffer can hold. [How] Update the min page size correctly for the plane. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Jun Lei <jun.lei@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-27drm/amd/display: Initialize get_bytes_per_element's default to 1Alex Hung
Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y & bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity. Signed-off-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-27drm/amd/display: Check null values from functionsAlex Hung
Functions get_per_method_common_meta and get_expanded_strategy_list can return null and thus it is necessary to check their returned values before dereferencing. This fixes 3 NULL_RETURNS issues reported by Coverity. Signed-off-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-27drm/amd/display: Add logs for debugging outboxCruise
The DP tunnel AUX reply is received through Outbox1. Print the Outbox1 status if an issue occurs. Signed-off-by: Cruise <Cruise.Hung@amd.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Wayne Lin <wayne.lin@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-27drm/amd/display: Add new enable and disable functionsHansen Dsouza
Add new enable and disable functions based on DCCG spec. Signed-off-by: Hansen Dsouza <Hansen.Dsouza@amd.com> Reviewed-by: Muhammad Ahmed <ahmed.ahmed@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-27drm/radeon: convert bios_hardcoded_edid to drm_edidThomas Weißschuh
Instead of manually passing around 'struct edid *' and its size, use 'struct drm_edid', which encapsulates a validated combination of both. As the drm_edid_ can handle NULL gracefully, the explicit checks can be dropped. Also save a few characters by transforming '&array[0]' to the equivalent 'array' and using 'max_t(int, ...)' instead of manual casts. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-27drm/amdgpu: convert bios_hardcoded_edid to drm_edidThomas Weißschuh
Instead of manually passing around 'struct edid *' and its size, use 'struct drm_edid', which encapsulates a validated combination of both. As the drm_edid_ can handle NULL gracefully, the explicit checks can be dropped. Also save a few characters by transforming '&array[0]' to the equivalent 'array' and using 'max_t(int, ...)' instead of manual casts. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-27drm/amdgpu: Fix APU handling in amdgpu_pm_load_smu_firmware()Alex Deucher
We only need to skip this on modern APUs. It's required on older APUs as it's where start_smu gets called from. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3502 Fixes: 064d92436b69 ("drm/amd/pm: avoid to load smu firmware for APUs") Reviewed-by: Tim Huang <tim.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Tim Huang <Tim.Huang@amd.com>
2024-07-27drm/amdgpu: trigger ip dump before suspend of IP'sSunil Khatri
Problem: IP dump right now is done post suspend of all IP's which for some IP's could change power state and software state too which we do not want to reflect in the dump as it might not be same at the time of hang. Solution: IP should be dumped as close to the HW state when the GPU was in hung state without trying to reinitialize any resource. Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-27drm/amd/display: Avoid overflow assignment in link_dp_ctsAlex Hung
sampling_rate is an uint8_t but is assigned an unsigned int, and thus it can overflow. As a result, sampling_rate is changed to uint32_t. Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it should only be assigned to a value less or equal than 4. This fixes 2 INTEGER_OVERFLOW issues reported by Coverity. Signed-off-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Wenjing Liu <wenjing.liu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-27drm/amd/display: Use correct cm_helper functionIlya Bakoulin
Need to use cm3_helper function with DCN401 to avoid cases where high RGB component values can get set to zero if using the TF curve generated by cm_helper. Signed-off-by: Ilya Bakoulin <Ilya.Bakoulin@amd.com> Reviewed-by: Alvin Lee <alvin.lee2@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-27drm/amd/display: Add seamless boot support for more DIG operation modesNicholas Kazlauskas
[Why] When pre-OS firmware enables display support for displays that operate the DIG in 2 pixels per cycle processing modes the inferred pixel rate from get_pixel_clk_frequency_100hz does not account for the true pixel rate since we're outputting 2 per cycle past the stream encoder. This causes seamless boot validation to abort early. [How] Add a new stream encoder function for getting pixels per cycle from the stream encoder. If the pixels per cycle is greater than 1 and the driver policy is to enable 2 pixels per cycle for post-OS then allow seamless boot to continue. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Duncan Ma <duncan.ma@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-27drm/amd/display: Reset VRR config during resumeTom Chung
[Why] After resume the system, the new_crtc_state->vrr_infopacket does not synchronize with the current state. It will affect the update_freesync_state_on_stream() does not update the state correctly. The previous patch causes a PSR SU regression that cannot let panel go into self-refresh mode. [How] Reset the VRR config during resume to force update the VRR config later. Fixes: eb6dfbb7a9c6 ("drm/amd/display: Reset freesync config before update new state") Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Reviewed-by: Sun peng Li <sunpeng.li@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-27drm/amd/display: Add a missing PSR stateTom Chung
[Why & How] Add a missing PSR state to make the dmub_psr_get_state() return a correct PSR state. Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Reviewed-by: Sun peng Li <sunpeng.li@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-27drm/amd/display: sync dmub output event type.Charlene Liu
[why] dmubfw added a new event type, update amdgpu to avoid "notify type 6 invalid" Signed-off-by: Charlene Liu <Charlene.Liu@amd.com> Reviewed-by: Chris Park <chris.park@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-27drm/amd/display: restore immediate_disable_crtc for w/aCharlene Liu
[why] immediate_disable_crtc does not reset ODM. if switching to disable_crtc which will disable ODM as well. i.e. need to restore ODM mem cfg at reenable it at end of w/a. Signed-off-by: Charlene Liu <Charlene.Liu@amd.com> Reviewed-by: Xi (Alex) Liu <xi.liu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-27drm/amdgpu: increase mes log buffer size for gfx12Michael Chen
MES firmware requires larger log buffer for gfx12. Allocate proper buffer respectively for gfx11 and gfx12. Signed-off-by: Michael Chen <michael.chen@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-27drm/amd/display: Check stream_status before it is usedAlex Hung
[WHAT & HOW] dc_state_get_stream_status can return null, and therefore null must be checked before stream_status is used. This fixes 1 NULL_RETURNS issue reported by Coverity. Signed-off-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-27drm/amd/display: Check null pointers before using themAlex Hung
[WHAT & HOW] dc_link is null checked previously in the same function, indicating it might be null as reported by Coverity. This fixes 1 FORWARD_NULL issue reported by Coverity. Signed-off-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-27drm/amd/display: Fix possible overflow in integer multiplicationAlex Hung
[WHAT & HOW] Integer multiplies integer may overflow in context that expects an expression of unsigned long long (64 bits). This can be fixed by casting integer to unsigned long long to force 64 bits results. This fixes 2 OVERFLOW_BEFORE_WIDEN issues reported by Coverity. Signed-off-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-27drm/amd/display: Add option to disable unbounded req in DML21Alvin Lee
Use debug option for disabling unbounded req in DML21 Signed-off-by: Alvin Lee <Alvin.Lee2@amd.com> Reviewed-by: Austin Zheng <Austin.Zheng@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-27drm/amd/display: Refactor for dioBhuvanachandra Pinninti
Moved files to respective folders to improve DIO code. Signed-off-by: Bhuvanachandra Pinninti <bpinnint@amd.com> Reviewed-by: Martin Leung <martin.leung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-27drm/amd/display: Request 0MHz dispclk for zero display caseNicholas Kazlauskas
[Why] If we aren't entering RCG/IPS2 or CLKSTOP is not supported by PMFW then we should be requesting a dispclk value of 0MHz to PMFW. Currenly we run at max clock since there's an assumption in APU clock table formulation where we can run at any DISPCLK at any state so the real clock value ends up as 1200Mhz - the maximum. [How] Set to 0 instead of the minimum value in the state array. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Duncan Ma <duncan.ma@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-27drm/amdgpu: print VCN instance dump for valid instanceSunil Khatri
VCN dump is dependent on power state of the ip. Dump is valid if VCN was powered up at the time of ip dump. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-27drm/amd/display: Add two dmmuy I2C entry for GPIO port mapping issueChris Park
[Why] When only 4 I2C is declared, two dummies are required to correctly map GPIO port. [How] Add one more I2C dummy entry to match GPIO port. Signed-off-by: Chris Park <chris.park@amd.com> Reviewed-by: Alvin Lee <alvin.lee2@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit v1.2.3 (git 2.25.1) at 2026-04-20 00:39:23 +0000