aboutsummaryrefslogtreecommitdiffstatshomepage
AgeCommit message (Collapse)AuthorFilesLines
2024-09-02drm/msm/hdmi: add "qcom,hdmi-tx-8998" compatibleMarc Gonzalez1-0/+1
Current driver already supports the msm8998 HDMI TX. We just need to add the compatible string. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Marc Gonzalez <mgonzalez@freebox.fr> Patchwork: https://patchwork.freedesktop.org/patch/605632/ Link: https://lore.kernel.org/r/20240724-hdmi-tx-v7-3-e44a20553464@freebox.fr Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-09-02dt-bindings: display/msm: hdmi: add qcom,hdmi-tx-8998Marc Gonzalez1-2/+26
HDMI TX block embedded in the APQ8098. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Marc Gonzalez <mgonzalez@freebox.fr> Patchwork: https://patchwork.freedesktop.org/patch/605638/ Link: https://lore.kernel.org/r/20240724-hdmi-tx-v7-2-e44a20553464@freebox.fr Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-09-02dt-bindings: phy: add qcom,hdmi-phy-8998Marc Gonzalez1-0/+1
HDMI PHY block embedded in the APQ8098. Acked-by: Rob Herring (Arm) <robh@kernel.org> Acked-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Marc Gonzalez <mgonzalez@freebox.fr> Patchwork: https://patchwork.freedesktop.org/patch/605634/ Link: https://lore.kernel.org/r/20240724-hdmi-tx-v7-1-e44a20553464@freebox.fr Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-09-02drm/msm/dpu: Configure DP INTF/PHY selectorDmitry Baryshkov4-6/+72
Some platforms provides a mechanism for configuring the mapping between (one or two) DisplayPort intfs and their PHYs. In particular SC8180X requires this to be configured, since on this platform there are fewer controllers than PHYs. The change implements the logic for optionally configuring which PHY each of the DP INTFs should be connected to and marks the SC8180X DPU to program 2 entries. For now the request is simply to program the mapping 1:1, any support for alternative mappings is left until the use case arrise. Note that e.g. msm-4.14 unconditionally maps INTF 0 to PHY 0 on all platforms, so perhaps this is needed in order to get DisplayPort working on some other platforms as well. Co-developed-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/600895/ Link: https://lore.kernel.org/r/20240625-dp-phy-sel-v3-1-c77c7066c454@linaro.org
2024-09-01drm/msm/adreno: Add A306A supportOtto Pflüger3-3/+28
Add support for Adreno 306A GPU what is found in MSM8917 SoC. This GPU marketing name is Adreno 308. Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de> [use internal name of the GPU, reword the commit message] Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Barnabás Czémán <trabarni@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/605403/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-09-01drm/msm/a6xx: Add A621 supportKonrad Dybcio4-1/+106
A621 is a clear A662 derivative (same lineage as A650), no explosions or sick features, other than a NoC bug which can stall the GPU.. Add support for it. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/611100/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-09-01drm/msm/a6xx: Set GMU CGC properties on a6xx tooKonrad Dybcio3-10/+17
This was apparently never done before.. Program the expected values. This also gets rid of sneakily setting that register through the HWCG reg list on A690. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/611098/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-09-01drm/msm/a6xx: Use the per-GPU value for gmu_cgc_modeKonrad Dybcio1-4/+2
This register's magic value differs wildly between different GPUs, use the hardcoded data instead of trying to make some logic out of it. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/611096/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-09-01drm/msm/a6xx: Store correct gmu_cgc_mode in struct a6xx_infoKonrad Dybcio2-0/+20
Store the correct values that we happen to have for some A7xx SKUs in the GPU info struct and fill out the missing information for A6xx GPUs based on downstream kernel information. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/611094/ [add missing entry to a615 catalog to resolve conflict] Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-09-01drm/msm/a6xx: Store primFifoThreshold in struct a6xx_infoKonrad Dybcio3-19/+21
The if-else monster is so unmaintainable that one case is repeated twice. Get rid of it. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/611092/ [add missing entry to a615 catalog to resolve conflict] Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-09-01drm/msm/a6xx: Evaluate adreno_is_a650_family in pdc_in_aop checkKonrad Dybcio1-2/+1
A650 family includes A660 family (they've got a big family), A650 itself, and some more A6XX_GEN3 SKUs, all of which should fall into the same branch of the if-condition. Simplify that. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/605206/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-09-01drm/msm/a5xx: workaround early ring-buffer emptiness checkVladimir Lypak3-0/+9
There is another cause for soft lock-up of GPU in empty ring-buffer: race between GPU executing last commands and CPU checking ring for emptiness. On GPU side IRQ for retire is triggered by CACHE_FLUSH_TS event and RPTR shadow (which is used to check ring emptiness) is updated a bit later from CP_CONTEXT_SWITCH_YIELD. Thus if GPU is executing its last commands slow enough or we check that ring too fast we will miss a chance to trigger switch to lower priority ring because current ring isn't empty just yet. This can escalate to lock-up situation described in previous patch. To work-around this issue we keep track of last submit sequence number for each ring and compare it with one written to memptrs from GPU during execution of CACHE_FLUSH_TS event. Fixes: b1fc2839d2f9 ("drm/msm: Implement preemption for A5XX targets") Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/612047/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-09-01drm/msm/a5xx: fix races in preemption evaluation stageVladimir Lypak2-2/+23
On A5XX GPUs when preemption is used it's invietable to enter a soft lock-up state in which GPU is stuck at empty ring-buffer doing nothing. This appears as full UI lockup and not detected as GPU hang (because it's not). This happens due to not triggering preemption when it was needed. Sometimes this state can be recovered by some new submit but generally it won't happen because applications are waiting for old submits to retire. One of the reasons why this happens is a race between a5xx_submit and a5xx_preempt_trigger called from IRQ during submit retire. Former thread updates ring->cur of previously empty and not current ring right after latter checks it for emptiness. Then both threads can just exit because for first one preempt_state wasn't NONE yet and for second one all rings appeared to be empty. To prevent such situations from happening we need to establish guarantee for preempt_trigger to make decision after each submit or retire. To implement this we serialize preemption initiation using spinlock. If switch is already in progress we need to re-trigger preemption when it finishes. Fixes: b1fc2839d2f9 ("drm/msm: Implement preemption for A5XX targets") Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/612045/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-09-01drm/msm/a5xx: properly clear preemption records on resumeVladimir Lypak1-0/+2
Two fields of preempt_record which are used by CP aren't reset on resume: "data" and "info". This is the reason behind faults which happen when we try to switch to the ring that was active last before suspend. In addition those faults can't be recovered from because we use suspend and resume to do so (keeping values of those fields again). Fixes: b1fc2839d2f9 ("drm/msm: Implement preemption for A5XX targets") Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/612043/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-09-01drm/msm/a5xx: disable preemption in submits by defaultVladimir Lypak1-2/+6
Fine grain preemption (switching from/to points within submits) requires extra handling in command stream of those submits, especially when rendering with tiling (using GMEM). However this handling is missing at this point in mesa (and always was). For this reason we get random GPU faults and hangs if more than one priority level is used because local preemption is enabled prior to executing command stream from submit. With that said it was ahead of time to enable local preemption by default considering the fact that even on downstream kernel it is only enabled if requested via UAPI. Fixes: a7a4c19c36de ("drm/msm/a5xx: fix setting of the CP_PREEMPT_ENABLE_LOCAL register") Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/612041/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-09-01drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrsKonrad Dybcio2-1/+1
There are some cases, such as the one uncovered by Commit 46d4efcccc68 ("drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails") where msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); is called on gpu->pdev == NULL, as the GPU device has not been fully initialized yet. Turns out that there's more than just the aforementioned path that causes this to happen (e.g. the case when there's speedbin data in the catalog, but opp-supported-hw is missing in DT). Assigning msm_gpu->pdev earlier seems like the least painful solution to this, therefore do so. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/602742/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-08-30drm/msm: Fix incorrect file name output in adreno_request_fw()Aleksandr Mishin1-1/+1
In adreno_request_fw() when debugging information is printed to the log after firmware load, an incorrect filename is printed. 'newname' is used instead of 'fwname', so prefix "qcom/" is being added to filename. Looks like "copy-paste" mistake. Fix this mistake by replacing 'newname' with 'fwname'. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 2c41ef1b6f7d ("drm/msm/adreno: deal with linux-firmware fw paths") Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/602382/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-08-30drm/msm: Fix UBWC macrotile_mode for a680Connor Abbott1-0/+3
Make it match the MDSS settings for sc8180x and downstream. Note that without the previous commit that exposes the value of macrotile_mode to mesa, this will break mesa which expects the legacy default value of 0. Therefore we do *not* want to backport it. Signed-off-by: Connor Abbott <cwabbott0@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/607398/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-08-30drm/msm: Expose expanded UBWC config uapiConnor Abbott2-0/+8
This adds extra parameters that affect UBWC tiling that will be used by the Mesa implementation of VK_EXT_host_image_copy. Signed-off-by: Connor Abbott <cwabbott0@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/607401/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-08-30drm/msm: Expand UBWC config settingConnor Abbott3-17/+53
According to downstream we should be setting RBBM_NC_MODE_CNTL to a non-default value on a663 and a680, we don't support a663 and on a680 we're leaving it at the wrong (suboptimal) value. Just set it on all GPUs. Similarly, plumb through level2_swizzling_dis which will be necessary on a663. ubwc_mode is expanded and renamed to ubwc_swizzle to match the name on the display side. Similarly macrotile_mode should match the display side. Signed-off-by: Connor Abbott <cwabbott0@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/607397/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-08-30drm/msm: Update a6xx register XMLConnor Abbott1-21/+1097
Update to Mesa commit 36a13d2b3b0 ("freedreno: fix a7xx perfcntr countables"). Signed-off-by: Connor Abbott <cwabbott0@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/607395/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-08-30drm/msm: Fix CP_BV_DRAW_STATE_ADDR nameConnor Abbott1-1/+1
This was missed because we weren't using the a750-specific indexed regs. Fixes: f3f8207d8aed ("drm/msm: Add devcoredump support for a750") Signed-off-by: Connor Abbott <cwabbott0@gmail.com> Reviewed-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/607394/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-08-30drm/msm: Dump correct dbgahb clusters on a750Connor Abbott1-2/+5
This was missed thanks to the family mixup fixed in the previous commit. Fixes: f3f8207d8aed ("drm/msm: Add devcoredump support for a750") Signed-off-by: Connor Abbott <cwabbott0@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/607393/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-08-30drm/msm: Use a7xx family directly in gpu_stateConnor Abbott1-21/+20
With a7xx, we need to import a new header for each new generation and switch to a different list of registers, instead of making backwards-compatible changes. Using the helpers inadvertently made a750 use the a740 list of registers, instead use the family directly to fix this. Fixes: f3f8207d8aed ("drm/msm: Add devcoredump support for a750") Signed-off-by: Connor Abbott <cwabbott0@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/607392/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-08-30drm/msm/adreno: add a615 supportRichard Acayan1-0/+27
The Adreno A615 is used in SDM670. Add an entry to support it. Signed-off-by: Richard Acayan <mailingradian@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/607238/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-08-30drm/msm/a6xx: Add A642L speedbin (0x81)Eugene Lepshy1-0/+1
According to downstream, A642L's speedbin is 129 and uses 4 as index Signed-off-by: Eugene Lepshy <fekz115@gmail.com> Signed-off-by: Danila Tikhonov <danila@jiaxyga.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/606722/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-08-30drm/msm: Remove unused pm_stateRob Clark1-2/+0
This was added in commit ec446d09366c ("drm/msm: call drm_atomic_helper_suspend() and drm_atomic_helper_resume()"), but unused since commit ca8199f13498 ("drm/msm/dpu: ensure device suspend happens during PM sleep") which switched to drm_mode_config_helper_suspend()/ drm_mode_config_helper_resume().. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/607746/
2024-08-30drm/msm: Remove prototypes for non-existing functionsLaurent Pinchart1-2/+0
The msm_atomic_state_clear() and msm_atomic_state_free() functions are declared but never defined. Remove their prototypes. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Patchwork: https://patchwork.freedesktop.org/patch/610618/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-08-30drm/msm/adreno: Use kvmemdup to simplify the codeLi Zetao1-4/+2
Use kvmemdup instead of kvmalloc() + memcpy() to simplify the code. No functional change intended. Signed-off-by: Li Zetao <lizetao1@huawei.com> Reviewed-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/609596/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-08-30Merge tag 'drm-intel-next-2024-08-29' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-nextDave Airlie80-775/+1515
Cross-driver (xe-core) Changes: - Require BMG scanout buffers to be 64k physically aligned (Maarten) Core (drm) Changes: - Introducing Xe2 ccs modifiers for integrated and discrete graphics (Juha-Pekka) Driver Changes: - General cleanup and more work moving towards intel_display isolation (Jani) - New display workaround (Suraj) - Use correct cp_irq_count on HDCP (Suraj) - eDP PSR fix when CRC is enabled (Jouni) - Fix DP MST state after a sink reset (Imre) - Fix Arrow Lake GSC firmware version (John) - Use chained DSBs for LUT programming (Ville) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ZtCC0lJ0Zf3MoSdW@intel.com
2024-08-30Merge tag 'drm-xe-next-2024-08-28' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-nextDave Airlie87-835/+2271
UAPI Changes: - Fix OA format masks which were breaking build with gcc-5 Cross-subsystem Changes: Driver Changes: - Use dma_fence_chain_free in chain fence unused as a sync (Matthew Brost) - Refactor hw engine lookup and mmio access to be used in more places (Dominik, Matt Auld, Mika Kuoppala) - Enable priority mem read for Xe2 and later (Pallavi Mishra) - Fix PL1 disable flow in xe_hwmon_power_max_write (Karthik) - Fix refcount and speedup devcoredump (Matthew Brost) - Add performance tuning changes to Xe2 (Akshata, Shekhar) - Fix OA sysfs entry (Ashutosh) - Add first GuC firmware support for BMG (Julia) - Bump minimum GuC firmware for platforms under force_probe to match LNL and BMG (Julia) - Fix access check on user fence creation (Nirmoy) - Add/document workarounds for Xe2 (Julia, Daniele, John, Tejas) - Document workaround and use proper WA infra (Matt Roper) - Fix VF configuration on media GT (Michal Wajdeczko) - Fix VM dma-resv lock (Matthew Brost) - Allow suspend/resume exec queue backend op to be called multiple times (Matthew Brost) - Add GT stats to debugfs (Nirmoy) - Add hwconfig to debugfs (Matt Roper) - Compile out all debugfs code with ONFIG_DEUBG_FS=n (Lucas) - Remove dead kunit code (Jani Nikula) - Refactor drvdata storing to help display (Jani Nikula) - Cleanup unsused xe parameter in pte handling (Himal) - Rename s/enable_display/probe_display/ for clarity (Lucas) - Fix missing MCR annotation in couple of registers (Tejas) - Fix DGFX display suspend/resume (Maarten) - Prepare exec_queue_kill for PXP handling (Daniele) - Fix devm/drmm issues (Daniele, Matthew Brost) - Fix tile and ggtt fini sequences (Matthew Brost) - Fix crashes when probing without firmware in place (Daniele, Matthew Brost) - Use xe_managed for kernel BOs (Daniele, Matthew Brost) - Future-proof dss_per_group calculation by using hwconfig (Matt Roper) - Use reserved copy engine for user binds on faulting devices (Matthew Brost) - Allow mixing dma-fence jobs and long-running faulting jobs (Francois) - Cleanup redundant arg when creating use BO (Nirmoy) - Prevent UAF around preempt fence (Auld) - Fix display suspend/resume (Maarten) - Use vma_pages() helper (Thorsten) - Calculate pagefault queue size (Stuart, Matthew Auld) - Fix missing pagefault wq destroy (Stuart) - Fix lifetime handling of HW fence ctx (Matthew Brost) - Fix order destroy order for jobs (Matthew Brost) - Fix TLB invalidation for media GT (Matthew Brost) - Document GGTT (Rodrigo Vivi) - Refactor GGTT layering and fix runtime outer protection (Rodrigo Vivi) - Handle HPD polling on display pm runtime suspend/resume (Imre, Vinod) - Drop unrequired NULL checks (Apoorva, Himal) - Use separate rpm lockdep map for non-d3cold-capable devices (Thomas Hellström) - Support "nomodeset" kernel command-line option (Thomas Zimmermann) - Drop force_probe requirement for LNL and BMG (Lucas, Balasubramani) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/wd42jsh4i3q5zlrmi2cljejohdsrqc6hvtxf76lbxsp3ibrgmz@y54fa7wwxgsd
2024-08-30Merge tag 'drm-misc-next-2024-08-29' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-nextDave Airlie59-876/+2368
drm-misc-next for v6.12: UAPI Changes: devfs: - support device numbers up to MINORBITS limit Core Changes: ci: - increase job timeout devfs: - use XArray for minor ids displayport: - mst: GUID improvements docs: - add fixes and cleanups panic: - optionally display QR code Driver Changes: amdgpu: - faster vblank disabling - GUID improvements gm12u320 - convert to struct drm_edid host1x: - fix syncpoint IRQ during resume - use iommu_paging_domain_alloc() imx: - ipuv3: convert to struct drm_edid omapdrm: - improve error handling panel: - add support for BOE TV101WUM-LL2 plus DT bindings - novatek-nt35950: improve error handling - nv3051d: improve error handling - panel-edp: add support for BOE NE140WUM-N6G; revert support for SDC ATNA45AF01 - visionox-vtdr6130: improve error handling; use devm_regulator_bulk_get_const() renesas: - rz-du: add support for RZ/G2UL plus DT bindings sti: - convert to struct drm_edid tegra: - gr3d: improve PM domain handling - convert to struct drm_edid Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240829144654.GA145538@linux.fritz.box
2024-08-29drm/i915/dsb: Use chained DSBs for LUT programmingVille Syrjälä4-8/+29
In order to better handle the necessary DSB DEwake tricks let's switch over to using a chained DSB for the actual LUT programming. The CPU will start 'dsb_color_commit', which in turn will start the chained 'dsb_color_vblank'. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240624191032.27333-15-ville.syrjala@linux.intel.com Reviewed-by: Animesh Manna <animesh.manna@intel.com>
2024-08-29drm/i915/dsb: s/dsb/dsb_color_vblank/Ville Syrjälä4-23/+23
We'll soon utilize several DSBs during the commit. To that end rename the current crtc_state->dsb to crtc_state->dsb_color_vblank to better reflect its role (color managemnent stuff programmed during vblank). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240624191032.27333-14-ville.syrjala@linux.intel.com Reviewed-by: Animesh Manna <animesh.manna@intel.com>
2024-08-29drm/i915/dsb: Clear DSB_ENABLE_DEWAKE once the DSB is doneVille Syrjälä1-1/+3
In order to avoid the DSB keeping the DEwake permanently asserted we must clear DSB_PMCTRL_2.DSB_FORCE_DEWAKE once we are done. For good measure do the same for DSB_PMCTRL.DSB_ENABLE_DEWAKE. Experimentally this doens't seem to be actually necessary (unlike with DSB_FORCE_DEWAKE). That is, the DSB_ENABLE_DEWAKE doesn't seem to do anything whenever the DSB is not active. But I'd hate to waste a ton of power in case there I'm wrong and there is some way DEwake could remaing asserted. One extra register write is a small price to pay for some peace of mind. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240624191032.27333-13-ville.syrjala@linux.intel.com Reviewed-by: Animesh Manna <animesh.manna@intel.com>
2024-08-29drm/i915/dsb: Allow intel_dsb_chain() to use DSB_WAIT_FOR_VBLANKVille Syrjälä2-6/+40
Allow intel_dsb_chain() to start the chained DSB at start of the undelaye vblank. This is slightly more involved than simply setting the bit as we must use the DEwake mechanism to eliminate pkgC latency. And DSB_ENABLE_DEWAKE itself is problematic in that it allows us to configure just a single scanline, and if the current scanline is already past that DSB_ENABLE_DEWAKE won't do anything, rendering the whole thing moot. The current workaround involves checking the pipe's current scanline with the CPU, and if it looks like we're about to miss the configured DEwake scanline we set DSB_FORCE_DEWAKE to immediately assert DEwake. This is somewhat racy since the hardware is making progress all the while we're checking it on the CPU. We can make things less racy by chaining two DSBs and handling the DSB_FORCE_DEWAKE stuff entirely without CPU involvement: 1. CPU starts the first DSB immediately 2. First DSB configures the second DSB, including its dewake_scanline 3. First DSB starts the second w/ DSB_WAIT_FOR_VBLANK 4. First DSB asserts DSB_FORCE_DEWAKE 5. First DSB waits until we're outside the dewake_scanline-vblank_start window 6. First DSB deasserts DSB_FORCE_DEWAKE That will guarantee that the we are fully awake when the second DSB starts to actually execute. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240624191032.27333-12-ville.syrjala@linux.intel.com Reviewed-by: Animesh Manna <animesh.manna@intel.com>
2024-08-29drm/i915/dsb: Introduce intel_dsb_chain()Ville Syrjälä2-0/+45
In order to handle the DEwake tricks without involving the CPU we need a mechanism by which one DSB can start another one. Add a basic function to do so. We'll extend it later with additional code to actually deal with DEwake. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240624191032.27333-11-ville.syrjala@linux.intel.com Reviewed-by: Animesh Manna <animesh.manna@intel.com>
2024-08-29drm/i915/dsb: Introduce intel_dsb_wait_scanline_{in,out}()Ville Syrjälä2-0/+79
Add functions to emit a DSB scanline window wait instructions. We can either wait for the scanline to be IN the window or OUT of the window. The hardware doesn't handle wraparound so we must manually deal with it by swapping the IN range to the inverse OUT range, or vice versa. Also add a bit of paranoia to catch the edge case of waiting for the entire frame. That doesn't make sense since an IN wait would be a nop, and an OUT wait would imply waiting forever. Most of the time this also results in both scanline ranges (original and inverted) to have lower=upper+1 which is nonsense from the hw POV. For now we are only handling the case where the scanline wait happens prior to latching the double buffered registers during the commit (which might change the timings due to LRR/VRR/etc.) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240624191032.27333-10-ville.syrjala@linux.intel.com Reviewed-by: Animesh Manna <animesh.manna@intel.com>
2024-08-29drm/i915/dsb: Precompute DSB_CHICKENVille Syrjälä1-3/+6
Adjust the code that determines the correct DSB_CHICKEN value to be usable for use within DSB commands themselves. Ie. precompute it based on our knowledge of what the hardware state (VRR vs. not mainly) will be at the time of the commit. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240624191032.27333-9-ville.syrjala@linux.intel.com Reviewed-by: Animesh Manna <animesh.manna@intel.com>
2024-08-29drm/i915/dsb: Account for VRR properly in DSB scanline stuffVille Syrjälä5-18/+67
When determining various scanlines for DSB use we should take into account whether VRR is active at the time when the DSB uses said scanline information. For now all DSB scanline usage occurs prior to the actual commit, so we only need to care about the state of VRR at that time. I've decided to move intel_crtc_scanline_to_hw() in its entirety to the DSB code as it will also need to know the actual state of VRR in order to do its job 100% correctly. TODO: figure out how much of this could be moved to some more generic place and perhaps be shared with the CPU vblank evasion code/etc... Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240624191032.27333-8-ville.syrjala@linux.intel.com Reviewed-by: Animesh Manna <animesh.manna@intel.com>
2024-08-29drm/i915/dsb: Fix dewake scanlineVille Syrjälä1-8/+2
Currently we calculate the DEwake scanline based on the delayed vblank start, while in reality it should be computed based on the undelayed vblank start (as that is where the DSB actually starts). Currently it doesn't really matter as we don't have any vblank delay configured, but that may change in the future so let's be accurate in what we do. We can also remove the max() as intel_crtc_scanline_to_hw() can deal with negative numbers, which there really shouldn't be anyway. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240624191032.27333-7-ville.syrjala@linux.intel.com Reviewed-by: Animesh Manna <animesh.manna@intel.com>
2024-08-29drm/i915/dsb: Shuffle code aroundVille Syrjälä1-28/+28
Relocate intel_dsb_dewake_scanline() and dsb_chicken() upwards in the file. I need to reuse these while emitting DSB commands, and I'd like to keep the DSB command emission stuff more or less grouped together in the file. Also drop the intel_ prefix from intel_dsb_dewake_scanline() since it's all internal stuff and thus doesn't need so much namespacing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240624191032.27333-6-ville.syrjala@linux.intel.com Reviewed-by: Animesh manna <animesh.manna@intel.com>
2024-08-29drm/i915/dsb: Convert dewake_scanline to a hw scanline number earlierVille Syrjälä3-15/+18
Currently we switch from out software idea of a scanline to the hw's idea of a scanline during the commit phase in _intel_dsb_commit(). While that is slightly easier due to fastsets fiddling with the timings, we'll also need to generate proper hw scanline numbers already when emitting DSB scanline wait instructions. So this approach won't do in the future. Switch to hw scanline numbers earlier. Also intel_dsb_dewake_scanline() itself already makes some assumptions about VRR that don't take into account VRR toggling during fastsets, so technically delaying the sw->hw conversion doesn't even help us. The other reason for delaying the conversion was that we are using intel_get_crtc_scanline() during intel_dsb_commit() which gives us the current sw scanline. But this is pretty low level stuff anyway so just using raw PIPEDSL reads seems fine here, and that of course gives us the hw scanline directly, reducing the need to do so many conversions. v2: Return the non-hw scanline from intel_dsb_dewake_scanline() Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240624191032.27333-5-ville.syrjala@linux.intel.com
2024-08-29drm/i915/dsb: Hook up DSB error interruptsVille Syrjälä4-0/+83
Enable all DSB error/fault interrupts so that we can see if anything goes terribly wrong. v2: Pass intel_display to DISPLAY_VER() (Jani) Drop extra '/' from drm_err() for consistency v3: Reorder the irq handler a bit Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240625135852.13431-1-ville.syrjala@linux.intel.com Reviewed-by: Animesh Manna <animesh.manna@intel.com>
2024-08-29drm/tiny/gm12u320: convert to struct drm_edidJani Nikula1-3/+10
Prefer the struct drm_edid based functions for allocating the EDID and updating the connector. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/c31c3afa883a3321345608c480c26161b638a83e.1724348429.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-08-29drm/ipuv3/parallel: convert to struct drm_edidJani Nikula1-5/+9
Prefer the struct drm_edid based functions for storing the EDID and updating the connector. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/a1698044d556072e79041d69b8702099fd17bd90.1724348429.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-08-29drm/tegra: convert to struct drm_edidJani Nikula2-13/+18
Prefer the struct drm_edid based functions for reading the EDID and updating the connector. Acked-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/e764b50f4ad2de95e449ccb37f49c3f37b3333fc.1724348429.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-08-29drm/sti/sti_hdmi: convert to struct drm_edidJani Nikula1-10/+14
Prefer the struct drm_edid based functions for reading the EDID and updating the connector. The functional change is that the CEC physical address gets invalidated when the EDID could not be read. v2: Use drm_edid_read() instead of drm_edid_read_ddc() (Sima) Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/25879a0183e30792bf0d63bdf56a03f11018e4a3.1724348429.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-08-29drm/i915: Fix readout degamma_lut mismatch on ilk/snbVille Syrjälä1-5/+26
On ilk/snb the pipe may be configured to place the LUT before or after the CSC depending on various factors, but as there is only one LUT (no split mode like on IVB+) we only advertise a gamma_lut and no degamma_lut in the uapi to avoid confusing userspace. This can cause a problem during readout if the VBIOS/GOP enabled the LUT in the pre CSC configuration. The current code blindly assigns the results of the readout to the degamma_lut, which will cause a failure during the next atomic_check() as we aren't expecting anything to be in degamma_lut since it's not visible to userspace. Fix the problem by assigning whatever LUT we read out from the hardware into gamma_lut. Cc: stable@vger.kernel.org Fixes: d2559299d339 ("drm/i915: Make ilk_read_luts() capable of degamma readout") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11608 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240710124137.16773-1-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2024-08-29drm/panel: nv3051d: Transition to mipi_dsi_dcs_write_seq_multiAbhishek Tamboli1-183/+184
Replace deprecated 'mipi_dsi_dcs_write_seq()' macro to 'mipi_dsi_dcs_write_seq_multi' macro in panel_nv3051d_init_sequence function. Signed-off-by: Abhishek Tamboli <abhishektamboli9@gmail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240827152504.30586-1-abhishektamboli9@gmail.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240827152504.30586-1-abhishektamboli9@gmail.com
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.