aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2022-01-25drm/amdgpu: add helper to query rlcg reg access flagHawking Zhang2-0/+43
Query rlc indirect register access approach specified by sriov host driver per ip blocks Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Zhou, Peng Ju <PengJu.Zhou@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amd/display: clean up some inconsistent indentingYang Li1-25/+23
Eliminate the follow smatch warning: drivers/gpu/drm/amd/display/dc/dml/calcs/dce_calcs.c:3415 bw_calcs() warn: inconsistent indenting Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amd/display: Fix memory leakYongzhi Liu1-20/+60
[why] Resource release is needed on the error handling path to prevent memory leak. [how] Fix this by adding kfree on the error handling path. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Yongzhi Liu <lyz_cs@pku.edu.cn> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amd/pm: remove useless ifJiapeng Chong1-4/+1
Clean the following coccicheck warning: ./drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c:7035:2-4: WARNING: possible condition with no effect (if == else). Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amd/amdgpu/amdgpu_cs: fix refcount leak of a dma_fence objXin Xiong1-0/+1
This issue takes place in an error path in amdgpu_cs_fence_to_handle_ioctl(). When `info->in.what` falls into default case, the function simply returns -EINVAL, forgetting to decrement the reference count of a dma_fence obj, which is bumped earlier by amdgpu_cs_get_fence(). This may result in reference count leaks. Fix it by decreasing the refcount of specific object before returning the error code. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Xin Xiong <xiongx18@fudan.edu.cn> Signed-off-by: Xin Tan <tanxin.ctf@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amdgpu/display: use msleep rather than udelay for long delaysAlex Deucher1-2/+2
Some architectures (e.g., ARM) throw an compilation error if the udelay is too long. In general udelays of longer than 2000us are not recommended on any architecture. Switch to msleep in these cases. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amdgpu/display: adjust msleep limit in dp_wait_for_training_aux_rd_intervalAlex Deucher1-1/+1
Some architectures (e.g., ARM) have relatively low udelay limits. On most architectures, anything longer than 2000us is not recommended. Change the check to align with other similar checks in DC. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amdgpu: filter out radeon secondary ids as wellAlex Deucher1-0/+81
Older radeon boards (r2xx-r5xx) had secondary PCI functions which we solely there for supporting multi-head on OSs with special requirements. Add them to the unsupported list as well so we don't attempt to bind to them. The driver would fail to bind to them anyway, but this does so in a cleaner way that should not confuse the user. Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amd/pm: use dev_*** to print output in multiple GPUsGuchun Chen5-10/+15
In multiple GPU configuration, when failed to send a SMU message, it's hard to figure out which GPU has such problem. So it's not comfortable to user. [40190.142181] amdgpu: [powerplay] last message was failed ret is 65535 [40190.242420] amdgpu: [powerplay] failed to send message 201 ret is 65535 [40190.392763] amdgpu: [powerplay] last message was failed ret is 65535 [40190.492997] amdgpu: [powerplay] failed to send message 200 ret is 65535 [40190.743575] amdgpu: [powerplay] last message was failed ret is 65535 [40190.843812] amdgpu: [powerplay] failed to send message 282 ret is 65535 Signed-off-by: Guchun Chen <guchun.chen@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amdgpu: drop WARN_ON in amdgpu_gart_bind/unbindGuchun Chen1-2/+2
NULL pointer check has guarded it already. calltrace: amdgpu_ttm_gart_bind+0x49/0xa0 [amdgpu] amdgpu_ttm_alloc_gart+0x13f/0x180 [amdgpu] amdgpu_bo_create_reserved+0x139/0x2c0 [amdgpu] ? amdgpu_ttm_debugfs_init+0x120/0x120 [amdgpu] amdgpu_bo_create_kernel+0x17/0x80 [amdgpu] amdgpu_ttm_init+0x542/0x5e0 [amdgpu] Fixes: 1b08dfb889b2c5 ("drm/amdgpu: remove gart.ready flag") Signed-off-by: Guchun Chen <guchun.chen@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amd/display: Not to call dpcd_set_source_specific_data during resume.Rajib Mahapatra1-1/+2
[Why] During resume path, dpcd_set_source_specific_data is taking extra time when core_link_write_dpcd fails on DP_SOURCE_OUI+0x03 and DP_SOURCE_MINIMUM_HBLANK_SUPPORTED. Here,aux->transfer fails with multiple retries and consume significant amount time during S0i3 resume. [How] Not to call dpcd_set_source_specific_data during resume path when there is no oled panel connected and achieve faster resume during S0i3. Reviewed-by: Hersen Wu <hersenxs.wu@amd.com> Signed-off-by: Rajib Mahapatra <rajib.mahapatra@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amd/pm: drop unneeded hwmgr->smu_lockEvan Quan2-241/+38
As all those related APIs are already well protected by adev->pm.mutex. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Guchun Chen <guchun.chen@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amd/pm: drop unneeded feature->mutexEvan Quan4-31/+10
As all those related APIs are already well protected by adev->pm.mutex. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Guchun Chen <guchun.chen@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amd/pm: drop unneeded smu_baco->mutexEvan Quan3-16/+5
As those APIs related are already well protected by adev->pm.mutex. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Guchun Chen <guchun.chen@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amd/pm: drop unneeded smu->sensor_lockEvan Quan10-20/+0
As all those related APIs are already well protected by adev->pm.mutex and smu->message_lock. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Guchun Chen <guchun.chen@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amd/pm: drop unneeded smu->metrics_lockEvan Quan12-195/+70
As all those related APIs are already well protected by adev->pm.mutex and smu->message_lock. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Guchun Chen <guchun.chen@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amd/pm: drop unneeded vcn/jpeg_gate_lockEvan Quan2-54/+11
As those related APIs are already protected by adev->pm.mutex. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Guchun Chen <guchun.chen@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amd/pm: drop unneeded lock protection smu->mutexEvan Quan6-299/+34
As all those APIs are already protected either by adev->pm.mutex or smu->message_lock. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Guchun Chen <guchun.chen@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amdgpu: suppress the warning about enum value 'AMD_IP_BLOCK_TYPE_NUM'Evan Quan1-0/+1
Suppress the warning below on building htmldocs: drivers/gpu/drm/amd/include/amd_shared.h:103: warning: Enum value 'AMD_IP_BLOCK_TYPE_NUM' not described in enum 'amd_ip_block_type' Fixes: 6ee27ee27ba8 ("drm/amd/pm: avoid duplicate powergate/ungate setting") Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Guchun Chen <guchun.chen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amdgpu: enable amdgpu_dc module parameterLang Yu1-2/+8
It doesn't work under IP discovery mode. Make it work! Signed-off-by: Lang Yu <Lang.Yu@amd.com> Reviewed-by: Alex Deucher <aleander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amd: Fix MSB of SMU version printingMario Limonciello4-22/+22
Yellow carp has been outputting versions like `1093.24.0`, but this is supposed to be 69.24.0. That is the MSB is being interpreted incorrectly. The MSB is not part of the major version, but has generally been treated that way thus far. It's actually the program, and used to distinguish between two programs from a similar family but different codebase. Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amdgpu: Disable FRU EEPROM access for SRIOVshaoyunl1-0/+6
VF acces the EEPROM is blocked by security policy, we might need other way to get SKUs info for VF v2: squash in compilation fix from Luben Signed-off-by: shaoyunl <shaoyun.liu@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Kent Russell <kent.russell@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amdgpu/display: Remove t_srx_delay_us.Bas Nieuwenhuizen8-17/+0
Unused. Convert the divisions into asserts on the divisor, to debug why it is zero. The divide by zero is suspected of causing kernel panics. While I have no idea where the zero is coming from I think this patch is a positive either way. Cc: stable@vger.kernel.org Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amd/display: Wrap dcn301_calculate_wm_and_dlg for FPU.Bas Nieuwenhuizen3-2/+13
Mirrors the logic for dcn30. Cue lots of WARNs and some kernel panics without this fix. Cc: stable@vger.kernel.org Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amd/display: Fix FP start/end for dcn30_internal_validate_bw.Bas Nieuwenhuizen1-2/+2
It calls populate_dml_pipes which uses doubles to initialize the scale_ratio_depth params. Mirrors the dcn20 logic. Cc: stable@vger.kernel.org Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amd/display/dc/calcs/dce_calcs: Fix a memleak in calculate_bandwidth()Zhou Qingyang1-2/+2
In calculate_bandwidth(), the tag free_sclk and free_yclk are reversed, which could lead to a memory leak of yclk. Fix this bug by changing the location of free_sclk and free_yclk. This bug was found by a static analyzer. Builds with 'make allyesconfig' show no new warnings, and our static analyzer no longer warns about this code. Fixes: 2be8989d0fc2 ("drm/amd/display/dc/calcs/dce_calcs: Move some large variables from the stack to the heap") Signed-off-by: Zhou Qingyang <zhou1615@umn.edu> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/nouveau/acr: Fix undefined behavior in nvkm_acr_hsfw_load_bl()Zhou Qingyang1-4/+5
In nvkm_acr_hsfw_load_bl(), the return value of kmalloc() is directly passed to memcpy(), which could lead to undefined behavior on failure of kmalloc(). Fix this bug by using kmemdup() instead of kmalloc()+memcpy(). This bug was found by a static analyzer. Builds with 'make allyesconfig' show no new warnings, and our static analyzer no longer warns about this code. Fixes: 22dcda45a3d1 ("drm/nouveau/acr: implement new subdev to replace "secure boot"") Signed-off-by: Zhou Qingyang <zhou1615@umn.edu> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220124165856.57022-1-zhou1615@umn.edu
2022-01-25drm/amdgpu/display: use msleep rather than udelay for long delaysAlex Deucher1-2/+2
Some architectures (e.g., ARM) throw an compilation error if the udelay is too long. In general udelays of longer than 2000us are not recommended on any architecture. Switch to msleep in these cases. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amdgpu/display: adjust msleep limit in dp_wait_for_training_aux_rd_intervalAlex Deucher1-1/+1
Some architectures (e.g., ARM) have relatively low udelay limits. On most architectures, anything longer than 2000us is not recommended. Change the check to align with other similar checks in DC. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amdgpu: filter out radeon secondary ids as wellAlex Deucher1-0/+81
Older radeon boards (r2xx-r5xx) had secondary PCI functions which we solely there for supporting multi-head on OSs with special requirements. Add them to the unsupported list as well so we don't attempt to bind to them. The driver would fail to bind to them anyway, but this does so in a cleaner way that should not confuse the user. Cc: stable@vger.kernel.org Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amd/display: change FIFO reset condition to embedded display onlyZhan Liu1-1/+1
[Why] FIFO reset is only necessary for fast boot sequence, where otg is disabled and dig fe is enabled when changing dispclk. Fast boot is only enabled on embedded displays. [How] Change FIFO reset condition to "embedded display only". Signed-off-by: Zhan Liu <zhan.liu@amd.com> Reviewed-by: Charlene Liu <charlene.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amd/display: Correct MPC split policy for DCN301Zhan Liu1-1/+1
[Why] DCN301 has seamless boot enabled. With MPC split enabled at the same time, system will hang. [How] Revert MPC split policy back to "MPC_SPLIT_AVOID". Since we have ODM combine enabled on DCN301, pipe split is not necessary here. Signed-off-by: Zhan Liu <zhan.liu@amd.com> Reviewed-by: Charlene Liu <charlene.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amd/display: Fix for otg synchronization logicMeenakshikumar Somasundaram7-13/+105
[Why] During otg sync trigger, plane states are used to decide whether the otg is already synchronized or not. There are scenarions when otgs are disabled without plane state getting disabled and in such case the otg is excluded from synchronization. [How] Introduced pipe_idx_syncd in pipe_ctx that tracks each otgs master pipe. When a otg is disabled/enabled, pipe_idx_syncd is reset to itself. On sync trigger, pipe_idx_syncd is checked to decide whether a otg is already synchronized and the otg is further included or excluded from synchronization. v2: Don't drop is_blanked logic Reviewed-by: Jun Lei <Jun.Lei@amd.com> Reviewed-by: Mustapha Ghaddar <mustapha.ghaddar@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: meenakshikumar somasundaram <meenakshikumar.somasundaram@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Cc: torvalds@linux-foundation.org Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/i915/guc: Ensure multi-lrc fini breadcrumb math is correctMatthew Brost1-6/+27
Realized that the GuC multi-lrc fini breadcrumb emit code is very delicate as the math this code does relies on functions it calls to emit a certain number of DWs. Add a few GEM_BUG_ONs to assert the math is correct. v2: - Rebase + resend for CI (Checkpatch) - Fix blank line warning Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220119210639.33053-1-matthew.brost@intel.com
2022-01-25drm/i915: Flush TLBs before releasing backing storeTvrtko Ursulin9-4/+161
We need to flush TLBs before releasing backing store otherwise userspace is able to encounter stale entries if a) it is not declaring access to certain buffers and b) it races with the backing store release from a such undeclared execution already executing on the GPU in parallel. The approach taken is to mark any buffer objects which were ever bound to the GPU and to trigger a serialized TLB flush when their backing store is released. Alternatively the flushing could be done on VMA unbind, at which point we would be able to ascertain whether there is potential a parallel GPU execution (which could race), but essentially it boils down to paying the cost of TLB flushes potentially needlessly at VMA unbind time (when the backing store is not known to be going away so not needed for safety), versus potentially needlessly at backing store relase time (since we at that point cannot tell whether there is anything executing on the GPU which uses that object). Thereforce simplicity of implementation has been chosen for now with scope to benchmark and refine later as required. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reported-by: Sushma Venkatesh Reddy <sushma.venkatesh.reddy@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Dave Airlie <airlied@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-01-25drm/etnaviv: relax submit size limitsLucas Stach1-2/+2
While all userspace tried to limit commandstreams to 64K in size, a bug in the Mesa driver lead to command streams of up to 128K being submitted. Allow those to avoid breaking existing userspace. Fixes: 6dfa2fab8ddd ("drm/etnaviv: limit submit sizes") Cc: stable@vger.kernel.org Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
2022-01-25drm/msm/gpu: Cancel idle/boost work on suspendRob Clark1-2/+19
With system suspend using pm_runtime_force_suspend() we can't rely on the pm_runtime_get_if_in_use() trick to deal with devfreq callbacks after (or racing with) suspend. So flush any pending idle or boost work in the suspend path. Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20220108180913.814448-3-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2022-01-25drm/msm/gpu: Wait for idle before suspendingRob Clark3-0/+24
System suspend uses pm_runtime_force_suspend(), which cheekily bypasses the runpm reference counts. This doesn't actually work so well when the GPU is active. So add a reasonable delay waiting for the GPU to become idle. Alternatively we could just return -EBUSY in this case, but that has the disadvantage of causing system suspend to fail. v2: s/ret/remaining [sboyd], and switch to using active_submits count to ensure we aren't racing with submit cleanup (and devfreq idle work getting scheduled, etc) v3: fix inverted logic Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220108180913.814448-2-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2022-01-25drm/edid: Support type 7 timingsYaroslav Bolyukin1-4/+8
Per VESA DisplayID Standard v2.0: Type VII Timing – Detailed Timing Data Definitions were already provided as type I, but not used Signed-off-by: Yaroslav Bolyukin <iam@lach.pw> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220123191955.57994-1-iam@lach.pw
2022-01-25drm/vc4: hdmi: Change CSC callback prototypeMaxime Ripard2-1/+7
In order to support the YUV output, we'll need the atomic state to know what is the state of the associated property in the CSC setup callback. Let's change the prototype of that callback to allow us to access it. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-11-maxime@cerno.tech
2022-01-25drm/vc4: hdmi: Define colorspace matricesMaxime Ripard1-29/+49
The current CSC setup code for the BCM2711 uses a sequence of register writes to configure the CSC depending on whether we output using a full or limited range. However, with the upcoming introduction of the YUV output, we're going to add new matrices to perform the conversions, so we should switch to something a bit more flexible that takes the matrix as an argument and programs the CSC accordingly. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-10-maxime@cerno.tech
2022-01-25drm/vc4: hdmi: Replace CSC_CTL hardcoded value by definesMaxime Ripard2-3/+5
On BCM2711, the HDMI_CSC_CTL register value has been hardcoded to an opaque value. Let's replace it with properly defined values. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-9-maxime@cerno.tech
2022-01-25drm/vc4: hdmi: Move XBAR setup to csc_setupMaxime Ripard1-1/+2
On the BCM2711, the HDMI_VEC_INTERFACE_XBAR register configuration depends on whether we're using an RGB or YUV output. Let's move that configuration to the CSC setup. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-8-maxime@cerno.tech
2022-01-25drm/vc4: hdmi: Use full range helper in csc functionsMaxime Ripard2-22/+13
The CSC callbacks takes a boolean as an argument to tell whether we're using the full range or limited range RGB. However, with the upcoming YUV support, the logic will be a bit more complex. In order to address this, let's make the callbacks take the entire mode, and call our new helper to tell whether the full or limited range RGB should be used. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-7-maxime@cerno.tech
2022-01-25drm/vc4: hdmi: Add full range RGB helperMaxime Ripard1-2/+10
We're going to need to tell whether we want to run with a full or limited range RGB output in multiple places in the code, so let's create a helper that will return whether we need with full range or not. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-6-maxime@cerno.tech
2022-01-25drm/connector: Fix typo in output formatMaxime Ripard8-36/+36
The HDMI specification mentions YCbCr everywhere, but our enums have YCrCb. Let's rename it to match. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-5-maxime@cerno.tech
2022-01-25drm/edid: Split deep color modes between RGB and YUV444Maxime Ripard4-7/+8
The current code assumes that the RGB444 and YUV444 formats are the same, but the HDMI 2.0 specification states that: The three DC_XXbit bits above only indicate support for RGB 4:4:4 at that pixel size. Support for YCBCR 4:4:4 in Deep Color modes is indicated with the DC_Y444 bit. If DC_Y444 is set, then YCBCR 4:4:4 is supported for all modes indicated by the DC_XXbit flags. So if we have YUV444 support and any DC_XXbit flag set but the DC_Y444 flag isn't, we'll assume that we support that deep colour mode for YUV444 which breaks the specification. In order to fix this, let's split the edid_hdmi_dc_modes field in struct drm_display_info into two fields, one for RGB444 and one for YUV444. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: d0c94692e0a3 ("drm/edid: Parse and handle HDMI deep color modes.") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-4-maxime@cerno.tech
2022-01-25drm/edid: Don't clear formats if using deep colorMaxime Ripard1-8/+0
The current code, when parsing the EDID Deep Color depths, that the YUV422 cannot be used, referring to the HDMI 1.3 Specification. This specification, in its section 6.2.4, indeed states: For each supported Deep Color mode, RGB 4:4:4 shall be supported and optionally YCBCR 4:4:4 may be supported. YCBCR 4:2:2 is not permitted for any Deep Color mode. This indeed can be interpreted like the code does, but the HDMI 1.4 specification further clarifies that statement in its section 6.2.4: For each supported Deep Color mode, RGB 4:4:4 shall be supported and optionally YCBCR 4:4:4 may be supported. YCBCR 4:2:2 is also 36-bit mode but does not require the further use of the Deep Color modes described in section 6.5.2 and 6.5.3. This means that, even though YUV422 can be used with 12 bit per color, it shouldn't be treated as a deep color mode. This is also broken with YUV444 if it's supported by the display, but DRM_EDID_HDMI_DC_Y444 isn't set. In such a case, the code will clear color_formats of the YUV444 support set previously in drm_parse_cea_ext(), but will not set it back. Since the formats supported are already setup properly in drm_parse_cea_ext(), let's just remove the code modifying the formats in drm_parse_hdmi_deep_color_info() Fixes: d0c94692e0a3 ("drm/edid: Parse and handle HDMI deep color modes.") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-3-maxime@cerno.tech
2022-01-25drm/edid: Rename drm_hdmi_avi_infoframe_colorspace to _colorimetryMaxime Ripard4-7/+7
The drm_hdmi_avi_infoframe_colorspace() function actually sets the colorimetry and extended_colorimetry fields in the hdmi_avi_infoframe structure with DRM_MODE_COLORIMETRY_* values. To make things worse, the hdmi_avi_infoframe structure also has a colorspace field used to signal whether an RGB or YUV output is being used. Let's remove the inconsistency and allow for the colorspace usage by renaming the function. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-2-maxime@cerno.tech
2022-01-25drm/docs: Document where the C8 color lut is storedDaniel Vetter1-0/+4
Also add notes that for atomic drivers it's really somewhere else and no longer in struct drm_crtc. Maybe we should put a bigger warning here that this is confusing, since the pixel format is a plane property, but the GAMMA_LUT property is on the crtc. But I think we can fix this if/when someone finds a need for a per-plane CLUT, since I'm not sure such hw even exists. I'm also not sure whether even hardware with a CLUT and a full color correction pipeline with degamm/cgm/gamma exists. Motivated by comments from Geert that we have a gap here. v2: More names for color luts (Laurent). Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220124221633.952374-1-daniel.vetter@ffwll.ch
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.