summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2023-03-24drm/i915/dpt: Only do the POT stride remap when using DPTVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230320090522.9909-3-ville.syrjala@linux.intel.com Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
2023-03-24drm/i915/dpt: Treat the DPT BO as a framebufferVille Syrjälä
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: stable@vger.kernel.org Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Imre Deak <imre.deak@intel.com> Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation for dpt") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230320090522.9909-2-ville.syrjala@linux.intel.com Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
2023-03-24drm/bridge: ps8640: Return NULL immediately when EDID read failPin-yen Lin
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 <treapking@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230324035909.1727356-1-treapking@chromium.org
2023-03-24gpu: host1x: fix uninitialized variable useArnd Bergmann
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 <nathan@kernel.org> Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com> Reported-by: "kernelci.org bot" <bot@kernelci.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20230127221418.2522612-1-arnd@kernel.org
2023-03-24Merge tag 'amd-drm-fixes-6.3-2023-03-23' of ↵Daniel Vetter
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 <daniel.vetter@ffwll.ch> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230323161939.7751-1-alexander.deucher@amd.com
2023-03-24Merge tag 'drm-intel-fixes-2023-03-23' of ↵Daniel Vetter
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 <daniel.vetter@ffwll.ch> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/878rfn7njw.fsf@intel.com
2023-03-24Merge tag 'drm-misc-fixes-2023-03-23' of ↵Daniel Vetter
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 <daniel.vetter@ffwll.ch> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230323082401.GA8371@linux-uq9g
2023-03-23drm/i915/guc: Allow for very slow GuC loadingJohn Harrison
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 <John.C.Harrison@Intel.com> Tested-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316220632.3312218-3-John.C.Harrison@Intel.com
2023-03-23drm/i915/guc: Improve GuC load error reportingJohn Harrison
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 <John.C.Harrison@Intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316220632.3312218-2-John.C.Harrison@Intel.com
2023-03-23drm/bridge: ps8640: Add a cache for EDIDPin-yen Lin
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 <treapking@chromium.org> Reviewed-by: Robert Foss <rfoss@kernel.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230315035508.2874915-2-treapking@chromium.org
2023-03-23drm/bridge: ps8640: Skip redundant bridge enablePin-yen Lin
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 <treapking@chromium.org> Reviewed-by: Robert Foss <rfoss@kernel.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230315035508.2874915-1-treapking@chromium.org
2023-03-23drm/i915/selftests: Drop igt_cs_tlbJonathan Cavitt
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 <jonathan.cavitt@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Acked-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230320192117.287374-1-andi.shyti@linux.intel.com
2023-03-23drm/amd/display: Set dcn32 caps.seamless_odmHersen Wu
[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 <qingqing.zhuo@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Hersen Wu <hersenxs.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-03-23drm/amd/display: fix wrong index used in dccg32_set_dpstreamclkHersen Wu
[Why & How] When merging commit 9af611f29034 ("drm/amd/display: Fix DCN32 DPSTREAMCLK_CNTL programming"), index change was not picked up. Cc: stable@vger.kernel.org Cc: Mario Limonciello <mario.limonciello@amd.com> Fixes: 9af611f29034 ("drm/amd/display: Fix DCN32 DPSTREAMCLK_CNTL programming") Reviewed-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Hersen Wu <hersenxs.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-03-23drm/amdgpu/nv: Apply ASPM quirk on Intel ADL + AMD NaviKai-Heng Feng
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 <alexander.deucher@amd.com> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2023-03-23drm/amd/display: remove outdated 8bpc commentsAlex Hung
[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 <Harry.Wentland@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-03-23drm/amdgpu/gfx: set cg flags to enter/exit safe modeJane Jian
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 <Jane.Jian@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-03-23drm/amdgpu: Force signal hw_fences that are embedded in non-sched jobsYuBiao Wang
[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 <YuBiao.Wang@amd.com> Acked-by: Luben Tuikov <luben.tuikov@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-03-23drm/amdgpu: add mes resume when do gfx post soft resetTong Liu01
[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 <Tong.Liu01@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-03-23drm/amdgpu: skip ASIC reset for APUs when go to S4Tim Huang
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 <tim.huang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 6.1.x
2023-03-23drm/amdgpu: reposition the gpu reset checking for reuseTim Huang
Move the amdgpu_acpi_should_gpu_reset out of CONFIG_SUSPEND to share it with hibernate case. Signed-off-by: Tim Huang <tim.huang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 6.1.x
2023-03-23drm/i915/huc: use const struct bus_type pointersGreg Kroah-Hartman
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 <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Tony Ye <tony.ye@intel.com> Cc: Vitaly Lubart <vitaly.lubart@intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://lore.kernel.org/r/20230313182918.1312597-30-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-23drm/i915/gem: Flush lmem contents after constructionChris Wilson
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 <matthew.auld@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Chris Wilson <chris.p.wilson@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.16+ Signed-off-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316165918.13074-1-nirmoy.das@intel.com
2023-03-23drm/panfrost: Add support for Mali on the MT8186 SoCAngeloGioacchino Del Regno
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 <angelogioacchino.delregno@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316102041.210269-13-angelogioacchino.delregno@collabora.com
2023-03-23drm/panfrost: Add new compatible for Mali on the MT8183 SoCAngeloGioacchino Del Regno
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 <angelogioacchino.delregno@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316102041.210269-12-angelogioacchino.delregno@collabora.com
2023-03-23drm/panfrost: Add mediatek,mt8192-mali compatibleAlyssa Rosenzweig
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 <alyssa.rosenzweig@collabora.com> [Angelo: Removed unneeded "sram" supply, added mt8195 to commit description] Co-developed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316102041.210269-11-angelogioacchino.delregno@collabora.com
2023-03-23drm/panfrost: Add the MT8192 GPU IDAlyssa Rosenzweig
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 <alyssa.rosenzweig@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316102041.210269-10-angelogioacchino.delregno@collabora.com
2023-03-23drm/panfrost: Increase MAX_PM_DOMAINS to 5Alyssa Rosenzweig
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 <alyssa.rosenzweig@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316102041.210269-9-angelogioacchino.delregno@collabora.com
2023-03-23drm/i915/mtl: Add HDCP GSC interfaceSuraj Kandpal
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 <tomas.winkler@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316092927.668980-7-suraj.kandpal@intel.com
2023-03-23drm/i915/mtl: Add function to send command to GSC CSSuraj Kandpal
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 <ankit.k.nautiyal@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Pervin Teres <alan.previn.teres.alexis@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316092927.668980-6-suraj.kandpal@intel.com
2023-03-23drm/i915/hdcp: HDCP2.x Refactoring to agnostic hdcpSuraj Kandpal
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 <tomas.winkler@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316092927.668980-4-suraj.kandpal@intel.com
2023-03-23drm/i915/hdcp: Use generic names for HDCP helpers and structsAnshuman Gupta
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 <tomas.winkler@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Acked-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316092927.668980-3-suraj.kandpal@intel.com
2023-03-23drm/i915/gsc: Create GSC request submission mechanismSuraj Kandpal
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 <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Signed-off-by: Suraj Kandpal<suraj.kandpal@intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316092927.668980-2-suraj.kandpal@intel.com
2023-03-23drm/i915: Use i915 instead of dev_priv insied the file_priv structureAndi Shyti
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 <andi.shyti@linux.intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230322001611.632321-1-andi.shyti@linux.intel.com
2023-03-23drm/rockchip: vop2: Add error check to devm_regmap_init_mmioAlfredo Cruz
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 <alfredo.carlon@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230322224411.15612-1-alfredo.carlon@gmail.com
2023-03-23drm/rockchip: dw_hdmi: cleanup drm encoder during unbindToby Chen
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 <tobyc@nvidia.com> [moved encoder cleanup above clk_disable, similar to bind-error-path] Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230317005126.496-1-tobyc@nvidia.com
2023-03-22drm/rockchip: vop2: fix uninitialized variable possible_crtcsTom Rix
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 <trix@redhat.com> Acked-by: Michael Riesch <michael.riesch@wolfvision.net> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230316132302.531724-1-trix@redhat.com
2023-03-22drm/i915/tc: Check the PLL type used by an enabled TC portImre Deak
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ä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230321220101.983366-3-imre.deak@intel.com
2023-03-22drm/i915/tc: Factor out a function querying active links on a TC portImre Deak
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ä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230321220101.983366-2-imre.deak@intel.com
2023-03-22drm/i915: Add encoder hook to get the PLL type used by TC portsImre Deak
Add an encoder hook, which can be called on enabled TC ports to determine if the port uses a TBT or a non-TBT PLL. An upcoming patch will use this to sanity check active TC port's PHY state wrt. the PLL type used by the port. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316131724.359612-13-imre.deak@intel.com
2023-03-22drm/i915/tc: Assume a TC port is legacy if VBT says the port has HDMIImre Deak
Since an HDMI output can only be enabled in legacy mode on TC ports, assume that VBT is wrong and the port is legacy if VBT says the port is non-legacy and has HDMI. If VBT says to enable DP as well leave the non-legacy flag enabled, relying on the flag getting fixed up based on the HPD status during sink detection. v2: Fix the legacy port flag only if DP is not enabled. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230321220101.983366-1-imre.deak@intel.com
2023-03-22drm/i915/tc: Make the TC mode readout consistent in all PHY statesImre Deak
For consistency detect the initial TC mode in the PHY owned state the same way this is done in the not owned state (w/o changing the behavior). While at it, add more details to the PHY state debug print. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316131724.359612-11-imre.deak@intel.com
2023-03-22drm/i915/tc: Fix initial TC mode on disabled legacy portsImre Deak
Atm, a TC port's initial mode will be read out as TBT mode in any case the PHY ownership is not held. This isn't correct for legacy ports which should be used only in legacy mode. Fix the above initial mode to be disconnected mode for a legacy port and TBT mode for DP-alt/TBT ports. Determine the port type by checking first the HPD state and then the legacy VBT flag (so the HPD state can correct a bogus VBT flag). If a sink is connected on a disabled port the PHY will get also connected (switching it to legacy mode on a legacy port). Also connect the PHY on a legacy port if it's enabled but BIOS incorrectly left it in the disconnected state for some reason. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316131724.359612-10-imre.deak@intel.com
2023-03-22drm/i915/tc: Fix TC mode for a legacy port if the PHY is not readyImre Deak
A legacy TC port can't be switched to TBT mode, even if the PHY initialization wasn't ready yet for some reason, so prevent this. This shouldn't normally happen as the driver waits for the IOM/TCSS PHY initialization during driver loading and system resume. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316131724.359612-9-imre.deak@intel.com
2023-03-22drm/i915/tc: Fix target TC mode for a disconnected legacy portImre Deak
Atm, the target TC mode - which the PHY should be switched to at any point it's used - is TBT in case there is no sink connected. However legacy ports are only used in the legacy mode regardless of the sink connected state. Fix the mode returned by intel_tc_port_get_target_mode() accordingly. Despite of the above issue, the PHY got disconnected as expected in response to a sink disconnect event, causing only a redundant PHY disconnect->reconnect sequence whenever the port was used. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316131724.359612-8-imre.deak@intel.com
2023-03-22drm/i915/tc: Factor out helpers converting HPD mask to TC modeImre Deak
Factor out helpers used later in the patchset to convert an HPD status mask to TC mode or target TC mode. No functional changes. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316131724.359612-7-imre.deak@intel.com
2023-03-22drm/i915/tc: Wait for IOM/FW PHY initialization of legacy TC portsImre Deak
During boot-up/system resume, the TC PHY on legacy ports will be initialized by the IOM/TCSS firmware regardless of a sink being connected or not (as opposed to DP-alt/TBT ports, which the FW only inits once a sink is connected). Wait for the above initialization to complete during HW readout, so that connecting the PHY later will already see the expected PHY ready state. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316131724.359612-6-imre.deak@intel.com
2023-03-22drm/i915/tc: Fix system resume MST mode restore for DP-alt sinksImre Deak
At least restoring the MST topology during system resume needs to use AUX before the display HW readout->sanitization sequence is complete, but on TC ports the PHY may be in the wrong mode for this, resulting in the AUX transfers to fail. The initial TC port mode is kept fixed as BIOS left it for the above HW readout sequence (to prevent changing the mode on an enabled port). If the port is disabled this initial mode is TBT - as in any case the PHY ownership is not held - even if a DP-alt sink is connected. Thus, the AUX transfers during this time will use TBT mode instead of the expected DP-alt mode and so time out. Fix the above by connecting the PHY during port initialization if the port is disabled, which will switch to the expected mode (DP-alt in the above case). As the encoder/pipe HW state isn't read-out yet at this point, check if the port is enabled based on the DDI_BUF enabled flag. Save the read-out initial mode, so intel_tc_port_sanitize_mode() can check this wrt. the read-out encoder HW state. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316131724.359612-5-imre.deak@intel.com
2023-03-22drm/i915/tc: Fix the ICL PHY ownership check in TC-cold stateImre Deak
The commit renaming icl_tc_phy_is_in_safe_mode() to icl_tc_phy_take_ownership() didn't flip the function's return value accordingly, fix this up. This didn't cause an actual problem besides state check errors, since the function is only used during HW readout. Cc: José Roberto de Souza <jose.souza@intel.com> Fixes: f53979d68a77 ("drm/i915/display/tc: Rename safe_mode functions ownership") Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316131724.359612-4-imre.deak@intel.com
2023-03-22drm/i915/tc: Fix TC port link ref init for DP MST during HW readoutImre Deak
An enabled TC MST port holds one TC port link reference, regardless of the number of enabled streams on it, but the TC port HW readout takes one reference for each active MST stream. Fix the HW readout, taking only one reference for MST ports. This didn't cause an actual problem, since the encoder HW readout doesn't yet support reading out the MST HW state. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316131724.359612-3-imre.deak@intel.com
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-21 15:29:14 +0000