aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2023-03-24drm/i915/perf: Add support for OA media unitsUmesh Nerlige Ramappa6-22/+274
MTL introduces additional OA units dedicated to media use cases. Add support for programming these OA units by passing the media engine class and instance parameters. UMD specific changes for GPUvis support: https://patchwork.freedesktop.org/patch/522827/?series=114023 https://patchwork.freedesktop.org/patch/522822/?series=114023 https://patchwork.freedesktop.org/patch/522826/?series=114023 https://patchwork.freedesktop.org/patch/522828/?series=114023 https://patchwork.freedesktop.org/patch/522816/?series=114023 https://patchwork.freedesktop.org/patch/522825/?series=114023 v2: (Ashutosh) - check for IP_VER(12, 70) instead of MTL - remove PERF_GROUP_OAG comment in mtl_oa_base - remove oa_buffer.group - use engine->oa_group->type in engine_supports_oa_format - remove fw_domains and use FORCEWAKE_ALL - remove MPES/MPEC comment - s/xehp/mtl/ in b counter validation function name - remove engine_supports_oa in __oa_engine_group - remove warn_ON from __oam_engine_group - refactor oa_init_groups and oa_init_regs - assign g->type correctly - use enum oa_type definition v3: (Ashutosh) - Drop oa_unit_functional as engine_supports_oa is enough v4: - s/DRM_DEBUG/drm_dbg/ Signed-off-by: Umesh Nerlige Ramappa <[email protected]> Reviewed-by: Ashutosh Dixit <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-24drm/i915/perf: Add engine class instance parameters to perfUmesh Nerlige Ramappa1-27/+44
One or more engines map to a specific OA unit. All reports from these engines are captured in the OA buffer managed by this OA unit. Current i915 OA implementation supports only the OAG unit. OAG primarily caters to render engine, so i915 OA uses render as the default engine in the OA implementation. Since there are more OA units on newer hardware that map to other engines, allow user to pass engine class and instance to select and program specific OA units. UMD specific changes for GPUvis support: https://patchwork.freedesktop.org/patch/522827/?series=114023 https://patchwork.freedesktop.org/patch/522822/?series=114023 https://patchwork.freedesktop.org/patch/522826/?series=114023 https://patchwork.freedesktop.org/patch/522828/?series=114023 https://patchwork.freedesktop.org/patch/522816/?series=114023 https://patchwork.freedesktop.org/patch/522825/?series=114023 v2: (Ashutosh) - Clarify commit message - Add drm_dbg - Clarify uapi description v3: (Ashutosh) - Remove irrelevant info from the uapi comment v4: Ensure engine class:instance is passed together (Ashutosh) v5: Remove unnecessary quote (Ashutosh) Signed-off-by: Umesh Nerlige Ramappa <[email protected]> Reviewed-by: Ashutosh Dixit <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-24drm/i915/perf: Handle non-power-of-2 reportsUmesh Nerlige Ramappa1-24/+27
Some of the newer OA formats are not powers of 2. For those formats, adjust the hw_tail accordingly when checking for new reports. v2: (Ashutosh) - Switch to OA_TAKEN for diff calculation - Use OA_BUFFER_SIZE instead of the vma size - Update comments Signed-off-by: Umesh Nerlige Ramappa <[email protected]> Reviewed-by: Ashutosh Dixit <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-24drm/i915/perf: Parse 64bit report header formats correctlyUmesh Nerlige Ramappa2-25/+90
Now that OA formats come in flavor of 64 bit reports, the report header has 64 bit report-id, timestamp, context-id and gpu-ticks fields. When filtering these reports, use the right width for these fields. Note that upper dword of context id is reserved, so squash lower dword only. v2: (Ashutosh) - Drop inline - Update comment with dword definitions - report id and timestamp Signed-off-by: Umesh Nerlige Ramappa <[email protected]> Reviewed-by: Ashutosh Dixit <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-24drm/i915/perf: Fail modprobe if i915_perf_init fails on OOMUmesh Nerlige Ramappa3-4/+10
i915_perf_init can fail due to OOM. Fail driver init if i915_perf_init fails. v2: (Jani) - Reorder patch in the series Signed-off-by: Umesh Nerlige Ramappa <[email protected]> Reviewed-by: Ashutosh Dixit <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-24drm/i915/perf: Group engines into respective OA groupsUmesh Nerlige Ramappa4-12/+127
Now that we may have multiple OA units in a single GT as well as on separate GTs, create an engine group that maps to a single OA unit. v2: (Jani) - Drop warning on ENOMEM - Reorder patch in the series v3: (Ashutosh) - Remove unused members from perf structs - Update comments - Update engine_supports_oa check - Just return 1 in num_perf_groups_per_gt for now - Set engine->oa_group to NULL to begin with v4: Use engine_supports_oa() check in oa_init_reg_state (Ashutosh) v5: Rebase after dropping engine_supports_oa helper Signed-off-by: Umesh Nerlige Ramappa <[email protected]> Reviewed-by: Ashutosh Dixit <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-24drm/i915/perf: Validate OA sseu config outside switchUmesh Nerlige Ramappa1-10/+13
Once OA supports media engine class:instance, the engine can only be validated outside the switch since class and instance parameters are separate entities. Since OA sseu config depends on engine class:instance, validate OA sseu config outside the switch. v2: (Ashutosh) - Clarify commit message - Use drm_dbg instead of DRM_DEBUG - Reorder stack variables Signed-off-by: Umesh Nerlige Ramappa <[email protected]> Reviewed-by: Ashutosh Dixit <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-24drm/i915/mtl: Synchronize i915/BIOS on C6 enablingVinay Belgaumkar3-3/+27
If BIOS enables/disables C6, i915 should do the same. Also, retain this value across driver reloads. This is needed only for MTL as of now due to an existing bug in OA which needs C6 disabled for it to function. BIOS behavior is also different across platforms in terms of how C6 is enabled. Signed-off-by: Vinay Belgaumkar <[email protected]> Reviewed-by: Ashutosh Dixit <[email protected]> Signed-off-by: Umesh Nerlige Ramappa <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-24drm/i915/perf: Drop wakeref on GuC RC errorChris Wilson2-5/+15
If we fail to adjust the GuC run-control on opening the perf stream, make sure we unwind the wakeref just taken. v2: Retain old goto label names (Ashutosh) v3: Drop bitfield boolean Fixes: 01e742746785 ("drm/i915/guc: Support OA when Wa_16011777198 is enabled") Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Ashutosh Dixit <[email protected]> Signed-off-by: Umesh Nerlige Ramappa <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-24drm/i915: Add PLANE_CHICKEN registersVille Syrjälä1-0/+9
Define the PLANE_CHICKEN register offsets. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Juha-Pekka Heikkila <[email protected]>
2023-03-24drm/i915/dpt: Introduce HAS_DPT()Ville Syrjälä2-1/+3
Replace the hand rolled DISPLAY_VER check for a more descriptive HAS_DPT() macro. Will be used on more than one place later. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Juha-Pekka Heikkila <[email protected]>
2023-03-24drm/i915/dpt: Only do the POT stride remap when using DPTVille Syrjälä1-1/+1
If we want to test with DPT disabled on ADL the POT stride remap stuff needs to be disabled. Make it depend on actual DPT usage instead of just assuming it based on the modifier. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Juha-Pekka Heikkila <[email protected]>
2023-03-24drm/i915/dpt: Treat the DPT BO as a framebufferVille Syrjälä3-1/+6
Currently i915_gem_object_is_framebuffer() doesn't treat the BO containing the framebuffer's DPT as a framebuffer itself. This means eg. that the shrinker can evict the DPT BO while leaving the actual FB BO bound, when the DPT is allocated from regular shmem. That causes an immediate oops during hibernate as we try to rewrite the PTEs inside the already evicted DPT obj. TODO: presumably this might also be the reason for the DPT related display faults under heavy memory pressure, but I'm still not sure how that would happen as the object should be pinned by intel_dpt_pin() while in active use by the display engine... Cc: [email protected] Cc: Juha-Pekka Heikkila <[email protected]> Cc: Matthew Auld <[email protected]> Cc: Imre Deak <[email protected]> Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation for dpt") Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Juha-Pekka Heikkila <[email protected]>
2023-03-24drm/bridge: ps8640: Return NULL immediately when EDID read failPin-yen Lin1-0/+6
drm_edid_read returns NULL on error, so feeding it directly into drm_edid_duplicate may lead to NULL pointer dereference. Add a check to guard this. Fixes: 6a17b4d1b52f ("drm/bridge: ps8640: Add a cache for EDID") Signed-off-by: Pin-yen Lin <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-24gpu: host1x: fix uninitialized variable useArnd Bergmann1-3/+2
The error handling for platform_get_irq() failing no longer works after a recent change, clang now points this out with a warning: drivers/gpu/host1x/dev.c:520:6: error: variable 'syncpt_irq' is uninitialized when used here [-Werror,-Wuninitialized] if (syncpt_irq < 0) ^~~~~~~~~~ Fix this by removing the variable and checking the correct error status. Fixes: 625d4ffb438c ("gpu: host1x: Rewrite syncpoint interrupt handling") Reviewed-by: Nathan Chancellor <[email protected]> Reviewed-by: Mikko Perttunen <[email protected]> Reported-by: "kernelci.org bot" <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Reviewed-by: Jon Hunter <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-24Merge tag 'amd-drm-fixes-6.3-2023-03-23' of ↵Daniel Vetter11-41/+72
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.3-2023-03-23: amdgpu: - S4 fix - Soft reset fixes - SR-IOV fix - Remove an out of date comment in the DC code - ASPM fix - DCN 3.2 fixes Signed-off-by: Daniel Vetter <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-24Merge tag 'drm-intel-fixes-2023-03-23' of ↵Daniel Vetter13-72/+88
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes drm/i915 fixes for v6.3-rc4: - Fix an MTL workaround - Fix fbdev obj locking before vma pin - Fix state inheritance tracking in initial commit - Fix missing GuC error capture codes - Fix missing debug object activation - Fix uc init late order relative to probe error injection - Fix perf limit reasons formatting - Fix vblank timestamp update on seamless M/N changes Signed-off-by: Daniel Vetter <[email protected]> From: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-24Merge tag 'drm-misc-fixes-2023-03-23' of ↵Daniel Vetter3-10/+20
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Short summary of fixes pull: * fixes for bind and probing error handling for meson, lt8912b bridge * panel-orientation fixes for Lenovo Book X90F Signed-off-by: Daniel Vetter <[email protected]> From: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20230323082401.GA8371@linux-uq9g
2023-03-23drm/i915/guc: Allow for very slow GuC loadingJohn Harrison1-3/+47
A failure to load the GuC is occasionally observed where the GuC log actually showed that the GuC had loaded just fine. The implication being that the load just took ever so slightly longer than the 200ms timeout. Given that the actual time should be tens of milliseconds at the slowest, this should never happen. So far the issue has generally been caused by a bad IFWI resulting in low frequencies during boot (depsite the KMD requesting max frequency). However, the issue seems to happen more often than one would like. So a) increase the timeout so that the user still gets a working system even in the case of slow load. And b) report the frequency during the load to see if that is the case of the slow down. v2: Reduce timeout in non-debug builds, add references (Daniele) References: https://gitlab.freedesktop.org/drm/intel/-/issues/7931 References: https://gitlab.freedesktop.org/drm/intel/-/issues/8060 References: https://gitlab.freedesktop.org/drm/intel/-/issues/8083 References: https://gitlab.freedesktop.org/drm/intel/-/issues/8136 References: https://gitlab.freedesktop.org/drm/intel/-/issues/8137 Signed-off-by: John Harrison <[email protected]> Tested-by: Ashutosh Dixit <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-23drm/i915/guc: Improve GuC load error reportingJohn Harrison3-21/+95
There are multiple ways in which the GuC load can fail. The driver was reporting the status register as is, but not everyone can read the matrix unfiltered. So add decoding of the common error cases. Also, remove the comment about interrupt based load completion checking being not recommended. The interrupt was removed from the GuC firmware some time ago so it is no longer an option anyway. While at it, also abort the timeout if a known error code is reported. No need to keep waiting if the GuC has already given up the load. v2: Fix mis-matched case and confusing 'success' variable (Daniele). Signed-off-by: John Harrison <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-23drm/bridge: ps8640: Add a cache for EDIDPin-yen Lin1-24/+36
When there are multiple EDID reads, the bridge will be repeatedly enabled and disabled. Add a cache for EDID to speed this up. Signed-off-by: Pin-yen Lin <[email protected]> Reviewed-by: Robert Foss <[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-03-23drm/bridge: ps8640: Skip redundant bridge enablePin-yen Lin1-1/+2
Skip the drm_bridge_chain_pre_enable call when the bridge is already pre_enabled. This make pre_enable and post_disable (thus pm_runtime_get/put) symmetric. Fixes: 46f206304db0 ("drm/bridge: ps8640: Rework power state handling") Signed-off-by: Pin-yen Lin <[email protected]> Reviewed-by: Robert Foss <[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-03-23drm/i915/selftests: Drop igt_cs_tlbJonathan Cavitt1-356/+0
The gt_tlb live selftest has the same code coverage as the igt_cs_tlb subtest of gtt, except it is better at detecting TLB bugs. Furthermore, while igt_cs_tlb is hitting some unforeseen issues, these issues are either false positives due to the test being poorly formatted, or are true positives that can be more easily diagnosed with smaller tests. As such, igt_cs_tlb is superceded by and obsoleted by gt_tlb, meaning it can be removed. Signed-off-by: Jonathan Cavitt <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Acked-by: Nirmoy Das <[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-03-23drm/amd/display: Set dcn32 caps.seamless_odmHersen Wu1-0/+1
[Why & How] seamless_odm set was not picked up while merging commit 2d017189e2b3 ("drm/amd/display: Blank eDP on enable drv if odm enabled") Fixes: 2d017189e2b3 ("drm/amd/display: Blank eDP on enable drv if odm enabled") Reviewed-by: Qingqing Zhuo <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Hersen Wu <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-03-23drm/amd/display: fix wrong index used in dccg32_set_dpstreamclkHersen Wu1-2/+1
[Why & How] When merging commit 9af611f29034 ("drm/amd/display: Fix DCN32 DPSTREAMCLK_CNTL programming"), index change was not picked up. Cc: [email protected] Cc: Mario Limonciello <[email protected]> Fixes: 9af611f29034 ("drm/amd/display: Fix DCN32 DPSTREAMCLK_CNTL programming") Reviewed-by: Qingqing Zhuo <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Hersen Wu <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-03-23drm/amdgpu/nv: Apply ASPM quirk on Intel ADL + AMD NaviKai-Heng Feng4-17/+18
S2idle resume freeze can be observed on Intel ADL + AMD WX5500. This is caused by commit 0064b0ce85bb ("drm/amd/pm: enable ASPM by default"). The root cause is still not clear for now. So extend and apply the ASPM quirk from commit e02fe3bc7aba ("drm/amdgpu: vi: disable ASPM on Intel Alder Lake based systems"), to workaround the issue on Navi cards too. Fixes: 0064b0ce85bb ("drm/amd/pm: enable ASPM by default") Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2458 Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2023-03-23drm/amd/display: remove outdated 8bpc commentsAlex Hung1-1/+0
[Why] The commit c76e483cd916 ("drm/amd/display: Don't restrict bpc to 8 bpc") removes the historical 8bpc dependency and sets max_bpc to 16. [How] The comment that states "8bpc for non-edp" needs to be removed as well. Reviewed-by: Harry Wentland <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Alex Hung <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-03-23drm/amdgpu/gfx: set cg flags to enter/exit safe modeJane Jian1-0/+5
sriov needs to enter/exit safe mode in update umd p state add the cg flag to let it enter or exit while needed Signed-off-by: Jane Jian <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-03-23drm/amdgpu: Force signal hw_fences that are embedded in non-sched jobsYuBiao Wang1-0/+9
[Why] For engines not supporting soft reset, i.e. VCN, there will be a failed ib test before mode 1 reset during asic reset. The fences in this case are never signaled and next time when we try to free the sa_bo, kernel will hang. [How] During pre_asic_reset, driver will clear job fences and afterwards the fences' refcount will be reduced to 1. For drm_sched_jobs it will be released in job_free_cb, and for non-sched jobs like ib_test, it's meant to be released in sa_bo_free but only when the fences are signaled. So we have to force signal the non_sched bad job's fence during pre_asic_reset or the clear is not complete. Signed-off-by: YuBiao Wang <[email protected]> Acked-by: Luben Tuikov <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-03-23drm/amdgpu: add mes resume when do gfx post soft resetTong Liu011-0/+9
[why] when gfx do soft reset, mes will also do reset, if mes is not resumed when do recover from soft reset, mes is unable to respond in later sequence [how] resume mes when do gfx post soft reset Signed-off-by: Tong Liu01 <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-03-23drm/amdgpu: skip ASIC reset for APUs when go to S4Tim Huang1-1/+4
For GC IP v11.0.4/11, PSP TMR need to be reserved for ASIC mode2 reset. But for S4, when psp suspend, it will destroy the TMR that fails the ASIC reset. [ 96.006101] amdgpu 0000:62:00.0: amdgpu: MODE2 reset [ 100.409717] amdgpu 0000:62:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000011 SMN_C2PMSG_82:0x00000002 [ 100.411593] amdgpu 0000:62:00.0: amdgpu: Mode2 reset failed! [ 100.412470] amdgpu 0000:62:00.0: PM: pci_pm_freeze(): amdgpu_pmops_freeze+0x0/0x50 [amdgpu] returns -62 [ 100.414020] amdgpu 0000:62:00.0: PM: dpm_run_callback(): pci_pm_freeze+0x0/0xd0 returns -62 [ 100.415311] amdgpu 0000:62:00.0: PM: pci_pm_freeze+0x0/0xd0 returned -62 after 4623202 usecs [ 100.416608] amdgpu 0000:62:00.0: PM: failed to freeze async: error -62 We can skip the reset on APUs, assuming we can resume them properly. Verified on some GFX11, GFX10 and old GFX9 APUs. Signed-off-by: Tim Huang <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] # 6.1.x
2023-03-23drm/amdgpu: reposition the gpu reset checking for reuseTim Huang2-20/+25
Move the amdgpu_acpi_should_gpu_reset out of CONFIG_SUSPEND to share it with hibernate case. Signed-off-by: Tim Huang <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] # 6.1.x
2023-03-23drm/i915/huc: use const struct bus_type pointersGreg Kroah-Hartman2-4/+4
The struct bus_type pointers in the functions intel_huc_register_gsc_notifier() and intel_huc_unregister_gsc_notifier() should be a const pointer, as the structure is not modified anywhere in the functions, and the pointer they are passed will be a const * in the near future. Cc: Jani Nikula <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Cc: Alan Previn <[email protected]> Cc: John Harrison <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Tony Ye <[email protected]> Cc: Vitaly Lubart <[email protected]> Cc: [email protected] Cc: [email protected] Acked-by: Tvrtko Ursulin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-03-23drm/i915/gem: Flush lmem contents after constructionChris Wilson1-1/+2
i915_gem_object_create_lmem_from_data() lacks the flush of the data written to lmem to ensure the object is marked as dirty and the writes flushed to the backing store. Once created, we can immediately release the obj->mm.mapping caching of the vmap. Fixes: 7acbbc7cf485 ("drm/i915/guc: put all guc objects in lmem when available") Cc: Matthew Auld <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Cc: Andi Shyti <[email protected]> Cc: Matthew Brost <[email protected]> Cc: John Harrison <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Cc: <[email protected]> # v5.16+ Signed-off-by: Nirmoy Das <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Reviewed-by: Nirmoy Das <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-23drm/panfrost: Add support for Mali on the MT8186 SoCAngeloGioacchino Del Regno1-0/+9
MediaTek MT8186 has a Mali-G52 MC2 2EE (Bifrost): add a new compatible and platform data using the same supplies list as "mt8183_b" (only one regulator), and a new pm_domains list with only two power domains. Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Steven Price <[email protected]> Reviewed-by: Chen-Yu Tsai <[email protected]> Tested-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-23drm/panfrost: Add new compatible for Mali on the MT8183 SoCAngeloGioacchino Del Regno1-0/+17
The "mediatek,mt8183-mali" compatible uses platform data that calls for getting (and managing) two regulators ("mali" and "sram") but devfreq does not support this usecase, resulting in DVFS not working. Since a lot of MediaTek SoCs need to set the voltages for the GPU SRAM regulator in a specific relation to the GPU VCORE regulator, a MediaTek SoC specific driver was introduced to automatically satisfy, through coupling, these constraints: this means that there is at all no need to manage both regulators in panfrost but to otherwise just manage the main "mali" (-> gpu vcore) regulator instead. Keeping in mind that we cannot break the ABI, the most sensible route (avoiding hacks and uselessly overcomplicated code) to get a MT8183 node with one power supply was to add a new "mediatek,mt8183b-mali" compatible, which effectively deprecates the former. Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Steven Price <[email protected]> Reviewed-by: Chen-Yu Tsai <[email protected]> Tested-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-23drm/panfrost: Add mediatek,mt8192-mali compatibleAlyssa Rosenzweig1-0/+11
Required for Mali-G57 on the Mediatek MT8192 and MT8195, which uses even more power domains than the MT8183 before it. Signed-off-by: Alyssa Rosenzweig <[email protected]> [Angelo: Removed unneeded "sram" supply, added mt8195 to commit description] Co-developed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Steven Price <[email protected]> Reviewed-by: Chen-Yu Tsai <[email protected]> Tested-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-23drm/panfrost: Add the MT8192 GPU IDAlyssa Rosenzweig1-0/+8
MediaTek MT8192 has a Mali-G57 with a special GPU ID. Add its GPU ID, but treat it as otherwise identical to a standard Mali-G57. We do _not_ fix up the GPU ID here -- userspace needs to be aware of the special GPU ID, in case we find functional differences between MediaTek's implementation and the standard Mali-G57 down the line. Signed-off-by: Alyssa Rosenzweig <[email protected]> Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Steven Price <[email protected]> Reviewed-by: Chen-Yu Tsai <[email protected]> Tested-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-23drm/panfrost: Increase MAX_PM_DOMAINS to 5Alyssa Rosenzweig1-1/+1
Increase the MAX_PM_DOMAINS constant from 3 to 5, to support the extra power domains required by the Mali-G57 on the MT8192. Signed-off-by: Alyssa Rosenzweig <[email protected]> Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Steven Price <[email protected]> Reviewed-by: Chen-Yu Tsai <[email protected]> Tested-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-23drm/i915/mtl: Add HDCP GSC interfaceSuraj Kandpal3-8/+660
MTL uses GSC command streamer i.e gsc cs to send HDCP/PXP commands to GSC f/w. It requires to keep hdcp display driver agnostic to content protection f/w (ME/GSC fw) in the form of i915_hdcp_fw_ops generic ops. Adding HDCP GSC CS interface by leveraging the i915_hdcp_fw_ops generic ops instead of I915_HDCP_COMPONENT as integral part of i915. Adding checks to see if GSC is loaded and proxy is setup --v6 -dont change the license date in same patch series [Jani] -fix the license year {Jani] --v8 -remove stale comment [Ankit] -get headers in alphabetical order [Ankit] -fix hdcp2_supported check [Ankit] --v9 -remove return statement from hdcp_gsc_fini [Ankit] Cc: Tomas Winkler <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Uma Shankar <[email protected]> Cc: Ankit Nautiyal <[email protected]> Signed-off-by: Anshuman Gupta <[email protected]> Signed-off-by: Suraj Kandpal <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Uma Shankar <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-23drm/i915/mtl: Add function to send command to GSC CSSuraj Kandpal6-0/+261
Add function that takes care of sending command to gsc cs. We start of with allocation of memory for our command intel_hdcp_gsc_message that contains gsc cs memory header as directed in specs followed by the actual payload hdcp message that we want to send. Spec states that we need to poll pending bit of response header around 20 times each try being 50ms apart hence adding that to current gsc_msg_send function Also we use the same function to take care of both sending and receiving hence no separate function to get the response. --v4 -Create common function to fill in gsc_mtl_header [Alan] -define host session bitmask [Alan] --v5 -use i915 directly instead of gt->i915 [Alan] -No need to make fields NULL as we are already using kzalloc [Alan] --v8 -change mechanism to reuse the same memory for one hdcp session[Alan] -fix header ordering -add comments to explain flags and host session mask [Alan] --v9 -remove gem obj from hdcp message as we can use i915_vma_unpin_and_release [Alan] -move hdcp message allocation and deallocation from hdcp2_enable and hdcp2_disable to init and teardown of HDCP [Alan] --v10 -remove unnecessary i915_vma_unpin [Alan] --v11 -fix comment style [Uma] Cc: Ankit Nautiyal <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Cc: Alan Pervin Teres <[email protected]> Cc: Uma Shankar <[email protected]> Cc: Anshuman Gupta <[email protected]> Signed-off-by: Suraj Kandpal <[email protected]> Reviewed-by: Alan Previn <[email protected]> Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Uma Shankar <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-23drm/i915/hdcp: HDCP2.x Refactoring to agnostic hdcpSuraj Kandpal1-2/+2
There are more than 1 type of content protection security firmware. Make the name generic %s/_mei_/_ --v3 -Changing names to drop cp_fw to make naming more agnostic[Jani] --v4 -remove header reference in intel_display_core.h [Uma] -fix commit message and prefix drm [Uma] Cc: Tomas Winkler <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Uma Shankar <[email protected]> Cc: Ankit Nautiyal <[email protected]> Signed-off-by: Anshuman Gupta <[email protected]> Signed-off-by: Suraj Kandpal <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Uma Shankar <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-23drm/i915/hdcp: Use generic names for HDCP helpers and structsAnshuman Gupta3-66/+68
pre MTL we interact with mei interface to talk to firmware and enable CP but going forward we will talk to gsc cs because of which we are making all names for HDCP helpers and structures generic as either mei or gsc cs maybe used. Change the include/drm/i915_mei_hdcp_interface.h to include/drm/i915_hdcp_interface.h Change the i915_hdcp_interface.h header naming convention to suit generic f/w type. %s/MEI_/HDCP_ %s/mei_dev/hdcp_dev Change structure name Accordingly. %s/i915_hdcp_comp_master/i915_hdcp_master %s/i915_hdcp_component_ops/i915_hdcp_ops --v6 -make each patch build individually [Jani] --v8 -change ME FW to ME/GSC FW [Ankit] -fix formatting issue [Ankit] --v9 -fix commit message and header [Uma] --v10 -rename comp variable [Uma] Cc: Tomas Winkler <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Uma Shankar <[email protected]> Cc: Ankit Nautiyal <[email protected]> Signed-off-by: Anshuman Gupta <[email protected]> Signed-off-by: Suraj Kandpal <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Reviewed-by: Uma Shankar <[email protected]> Acked-by: Tomas Winkler <[email protected]> Signed-off-by: Uma Shankar <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-23drm/i915/gsc: Create GSC request submission mechanismSuraj Kandpal4-0/+142
HDCP and PXP will require a common function to allow it to submit commands to the gsc cs. Also adding the gsc mtl header that needs to be added on to the existing payloads of HDCP and PXP. --v4 -Seprate gsc load and heci cmd submission into different functions in different files for better scalability [Alan] -Rename gsc address field [Alan] --v5 -remove extra line is intel_gsc_fw.h [Uma] Cc: Daniele Ceraolo Spurio <[email protected]> Cc: Alan Previn <[email protected]> Signed-off-by: Suraj Kandpal<[email protected]> Reviewed-by: Alan Previn <[email protected]> Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Uma Shankar <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-23drm/i915: Use i915 instead of dev_priv insied the file_priv structureAndi Shyti4-14/+14
In the process of renaming all instances of 'dev_priv' to 'i915', start using 'i915' within the 'drm_i915_file_private' structure. Signed-off-by: Andi Shyti <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-23drm/rockchip: vop2: Add error check to devm_regmap_init_mmioAlfredo Cruz1-0/+2
devm_regmap_init_mmio() may return an invalid pointer in case of an error. This patch adds the corresponding IS_ERR check to vop2->map. Signed-off-by: Alfredo Cruz <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-23drm/rockchip: dw_hdmi: cleanup drm encoder during unbindToby Chen1-0/+1
This fixes a use-after-free crash during rmmod. The DRM encoder is embedded inside the larger rockchip_hdmi, which is allocated with the component. The component memory gets freed before the main drm device is destroyed. Fix it by running encoder cleanup before tearing down its container. Signed-off-by: Toby Chen <[email protected]> [moved encoder cleanup above clk_disable, similar to bind-error-path] Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-22drm/rockchip: vop2: fix uninitialized variable possible_crtcsTom Rix1-5/+4
clang reportes this error drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:2322:8: error: variable 'possible_crtcs' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] if (vp) { ^~ drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:2336:36: note: uninitialized use occurs here ret = vop2_plane_init(vop2, win, possible_crtcs); ^~~~~~~~~~~~~~ drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:2322:4: note: remove the 'if' if its condition is always true if (vp) { ^~~~~~~~ The else-statement changes the win->type to OVERLAY without setting the possible_crtcs variable. Rework the block, initialize possible_crtcs to 0 to remove the else-statement. Split the else-if-statement out to its own if-statement so the OVERLAY check will catch when the win-type has been changed. Fixes: 368419a2d429 ("drm/rockchip: vop2: initialize possible_crtcs properly") Signed-off-by: Tom Rix <[email protected]> Acked-by: Michael Riesch <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-22drm/i915/tc: Check the PLL type used by an enabled TC portImre Deak1-20/+24
The current way to determine during HW state sanitization if a PHY is connected in the expected way doesn't work in all cases. The check for this considers only the PHY ready/owned state and the initial TC mode which was determined earlier by the TC port HW readout - using the sink's HPD and the same PHY ready/owned states. For instance for an enabled DP-alt/TBT port without the PHY ready/owned flags set the initial mode will be TBT, and this will be regarded as a valid PHY state. However it's possible that the port is actually enabled in DP-alt mode, but for some reason the PHY ownership was not acquired. Make sure the driver can detect invalid PHY states as in the above example by checking the PHY ready/owned state wrt. the PLL type used. This should be the TBT PLL if the PHY is not owned and the MG (non-TBT) PLL if the PHY is owned. v2: Rebased on change passing crtc_state in the previous patch. Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-22drm/i915/tc: Factor out a function querying active links on a TC portImre Deak3-16/+30
For clarity factor out the function to determine if there are active links on a TC port. This prepares for the next patch also checking the port's PLL type. While at it pass crtc_state to intel_tc_port_sanitize_mode(), and check hw.active in that, instead of the deprecated crtc->active flag. v2: Check crtc_state->hw.active instead of crtc->active. (Ville) Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.