| Age | Commit message (Collapse) | Author |
|---|
|
Underneath, for_each_pipe() really expects struct intel_display. Switch
to it in preparation for removing the transitional __to_intel_display()
macro.
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/1abcd9b4429a25eb40c30691c876d3db089b1cf2.1754499175.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Convert some leftover i915 usages to struct intel_display.
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/8a209e3f60039986794123e6b1631185c9234f8f.1754499175.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Convert some leftover i915 usages to struct intel_display.
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/c521c9fa8b7d2c9a04d472f6c541a41822f76327.1754499174.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Commit 8d9908e8fe9c ("drm/i915/display: remove small micro-optimizations
in irq handling") not only removed the optimizations, it also enabled
wakeref asserts for the GEN11_GU_MISC_IIR access. Silence the asserts by
wrapping the access inside intel_display_rpm_assert_{block,unblock}().
Reported-by: "Jason A. Donenfeld" <Jason@zx2c4.com>
Closes: https://lore.kernel.org/r/aG0tWkfmxWtxl_xc@zx2c4.com
Fixes: 8d9908e8fe9c ("drm/i915/display: remove small micro-optimizations in irq handling")
Cc: stable@vger.kernel.org # v6.13+
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/20250805115656.832235-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Make video port registers nonvolatile. As DSP_CTRL register is written
to twice due to gamma LUT enable bit which is set outside of the main
DSP_CTRL initialization within atomic_enable (for rk356x case it is also
necessary to always disable gamma LUT before writing a new LUT) there is
a chance that DSP_CTRL value read-out in gamma LUT init/update code is
not the one which was written by the preceding DSP_CTRL initialization
code within atomic_enable. This might result in misconfigured DSP_CTRL
which leads to no visual output[1]. Since DSP_CTRL write takes effect
after VSYNC[1] the issue is not always present. When tested on Pinetab2
with kernel 6.14 it happenes only when DRM is compiled as a module[1].
In order to confirm that it is a timing issue I inserted 18ms udelay
before vop2_crtc_atomic_try_set_gamma in atomic enable and compiled DRM
as module - this has also fixed the issue.
[1] https://lore.kernel.org/linux-rockchip/562b38e5.a496.1975f09f983.Coremail.andyshrk@163.com/
Reported-by: Diederik de Haas <didi.debian@cknow.org>
Closes: https://lore.kernel.org/linux-rockchip/DAEVDSTMWI1E.J454VZN0R9MA@cknow.org/
Suggested-by: Andy Yan <andy.yan@rock-chips.com>
Signed-off-by: Piotr Zalewski <pZ010001011111@proton.me>
Tested-by: Diederik de Haas <didi.debian@cknow.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250706083629.140332-2-pZ010001011111@proton.me
|
|
Select drm bridge connector when building cdp-dp.
This was missed in previous commit causing build failure.
Fixes: afbbca25d06e ("drm/rockchip: cdn-dp: Convert to drm bridge")
Signed-off-by: Rudi Heitbaum <rudi@heitbaum.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/aJrlUzV1u4i65NRe@8eba3d7b3083
|
|
Convert the Renesas RZ/G2L MIPI DSI Encoder driver from
SET_RUNTIME_PM_OPS() to RUNTIME_PM_OPS() and pm_ptr(). This lets us
drop the __maybe_unused annotations from its runtime suspend and resume
callbacks, and reduces kernel size in case CONFIG_PM is disabled.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/cdfc1b8ec9e62553654639b9e9026bfed8dd07d1.1752086582.git.geert+renesas@glider.be
|
|
Introduce error handling to address an issue where, after a hotplug
event, the cursor continues to update. This situation can lead to a
kernel panic due to accessing the NULL `old_state->crtc`.
E,g.
Unable to handle kernel NULL pointer dereference at virtual address
Call trace:
mtk_crtc_plane_disable+0x24/0x140
mtk_plane_atomic_update+0x8c/0xa8
drm_atomic_helper_commit_planes+0x114/0x2c8
drm_atomic_helper_commit_tail_rpm+0x4c/0x158
commit_tail+0xa0/0x168
drm_atomic_helper_commit+0x110/0x120
drm_atomic_commit+0x8c/0xe0
drm_atomic_helper_update_plane+0xd4/0x128
__setplane_atomic+0xcc/0x110
drm_mode_cursor_common+0x250/0x440
drm_mode_cursor_ioctl+0x44/0x70
drm_ioctl+0x264/0x5d8
__arm64_sys_ioctl+0xd8/0x510
invoke_syscall+0x6c/0xe0
do_el0_svc+0x68/0xe8
el0_svc+0x34/0x60
el0t_64_sync_handler+0x1c/0xf8
el0t_64_sync+0x180/0x188
Adding NULL pointer checks to ensure stability by preventing operations
on an invalid CRTC state.
Fixes: d208261e9f7c ("drm/mediatek: Add wait_event_timeout when disabling plane")
Signed-off-by: Jason-JH Lin <jason-jh.lin@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20250728025036.24953-1-jason-jh.lin@mediatek.com/
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
|
|
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
amd-drm-fixes-6.17-2025-08-13:
amdgpu:
- PSP fix
- VRAM reservation fix
- CSA fix
- Process kill fix
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexander.deucher@amd.com>
Link: https://lore.kernel.org/r/20250813151905.2040816-1-alexander.deucher@amd.com
|
|
Use the newly added of_reserved_mem_region_to_resource() function to
handle "memory-region" properties.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20250703183447.2073902-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
|
|
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes
Short summary of fixes pull:
bridge:
- fix OF-node leak
- fix documentation
fbdev-emulation:
- pass correct format info to drm_helper_mode_fill_fb_struct()
panfrost:
- print correct RSS size
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20250812064712.GA14554@2a02-2454-fd5e-fd00-2c49-c639-c55f-a125.dyn6.pyur.net
|
|
After a recent change in clang to expose uninitialized warnings from
const variables and pointers [1], there is a warning around crtc_state
in dpu_plane_virtual_atomic_check():
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:1145:6: error: variable 'crtc_state' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
1145 | if (plane_state->crtc)
| ^~~~~~~~~~~~~~~~~
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:1149:58: note: uninitialized use occurs here
1149 | ret = dpu_plane_atomic_check_nosspp(plane, plane_state, crtc_state);
| ^~~~~~~~~~
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:1145:2: note: remove the 'if' if its condition is always true
1145 | if (plane_state->crtc)
| ^~~~~~~~~~~~~~~~~~~~~~
1146 | crtc_state = drm_atomic_get_new_crtc_state(state,
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:1139:35: note: initialize the variable 'crtc_state' to silence this warning
1139 | struct drm_crtc_state *crtc_state;
| ^
| = NULL
Initialize crtc_state to NULL like other places in the driver do, so
that it is consistently initialized.
Cc: stable@vger.kernel.org
Closes: https://github.com/ClangBuiltLinux/linux/issues/2106
Fixes: 774bcfb73176 ("drm/msm/dpu: add support for virtual planes")
Link: https://github.com/llvm/llvm-project/commit/2464313eef01c5b1edf0eccf57a32cdee01472c7 [1]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
Currently, the high bitfield of certain DSI registers
do not align with the configuration of the SWI registers
description. This can lead to wrong programming these DSI
registers, for example for 4k resloution where H_TOTAL is
taking 13 bits but software is programming only 12 bits
because of the incorrect bitmask for H_TOTAL bitfeild,
this is causing DSI FIFO errors. To resolve this issue,
increase the high bitfield of the DSI registers from 12 bits
to 16 bits in dsi.xml to match the SWI register configuration.
Signed-off-by: Ayushi Makhija <quic_amakhija@quicinc.com>
Fixes: 4f52f5e63b62 ("drm/msm: import XML display registers database")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/666229/
Link: https://lore.kernel.org/r/20250730123938.1038640-1-quic_amakhija@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
Fix c&p error in dpu_plane_virtual_atomic_check(), compare CRTC width
too, in addition to CRTC height.
Fixes: 8c62a31607f6 ("drm/msm/dpu: allow using two SSPP blocks for a single plane")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202507150432.U0cALR6W-lkp@intel.com/
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/664170/
Link: https://lore.kernel.org/r/20250715-msm-fix-virt-atomic-check-v1-1-9bab02c9f952@oss.qualcomm.com
|
|
Various parts of the display driver can be triggering the display
snapshot (including the IOMMU fault handlers). Move the call to
msm_disp_snapshot_init() before KMS initialization, otherwise it is
possible to ocassionally trigger the kernel fault during init:
__lock_acquire+0x44/0x2798 (P)
lock_acquire+0x114/0x25c
_raw_spin_lock_irqsave+0x6c/0x90
kthread_queue_work+0x2c/0xac
msm_disp_snapshot_state+0x2c/0x4c
msm_kms_fault_handler+0x2c/0x74
msm_disp_fault_handler+0x30/0x48
report_iommu_fault+0x54/0x128
arm_smmu_context_fault+0x74/0x184
__handle_irq_event_percpu+0xa4/0x24c
handle_irq_event_percpu+0x20/0x5c
handle_irq_event+0x48/0x84
handle_fasteoi_irq+0xcc/0x170
generic_handle_domain_irq+0x48/0x70
gic_handle_irq+0x54/0x11c
call_on_irq_stack+0x3c/0x50
do_interrupt_handler+0x54/0x78
el1_interrupt+0x3c/0x5c
el1h_64_irq_handler+0x20/0x30
el1h_64_irq+0x6c/0x70
_raw_spin_unlock_irqrestore+0x44/0x68 (P)
klist_next+0xc4/0x124
bus_for_each_drv+0x9c/0xe8
__device_attach+0xfc/0x190
device_initial_probe+0x1c/0x2c
bus_probe_device+0x44/0xa0
device_add+0x204/0x3e4
platform_device_add+0x170/0x244
platform_device_register_full+0x130/0x138
drm_connector_hdmi_audio_init+0xc0/0x108
drm_bridge_connector_init+0x318/0x394
msm_dsi_manager_connector_init+0xac/0xdc
msm_dsi_modeset_init+0x78/0xc0
_dpu_kms_drm_obj_init+0x198/0x75c
dpu_kms_hw_init+0x2f8/0x494
msm_drm_kms_init+0xb0/0x230
msm_drm_init+0x218/0x250
msm_drm_bind+0x3c/0x4c
try_to_bring_up_aggregate_device+0x208/0x2a4
__component_add+0xa8/0x188
component_add+0x1c/0x2c
dsi_dev_attach+0x24/0x34
dsi_host_attach+0x68/0xa0
devm_mipi_dsi_attach+0x40/0xcc
lt9611_attach_dsi+0x94/0x118
lt9611_probe+0x368/0x3c8
i2c_device_probe+0x2d0/0x3d8
really_probe+0x130/0x354
__driver_probe_device+0xac/0x110
driver_probe_device+0x44/0x110
__device_attach_driver+0xb0/0x138
bus_for_each_drv+0x90/0xe8
__device_attach+0xfc/0x190
device_initial_probe+0x1c/0x2c
bus_probe_device+0x44/0xa0
deferred_probe_work_func+0xac/0x110
process_one_work+0x20c/0x51c
process_scheduled_works+0x58/0x88
worker_thread+0x1ec/0x304
kthread+0x194/0x1d4
ret_from_fork+0x10/0x20
Reported-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Fixes: 98659487b845 ("drm/msm: add support to take dpu snapshot")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/664149/
Link: https://lore.kernel.org/r/20250715-msm-move-snapshot-init-v1-1-f39c396192ab@oss.qualcomm.com
|
|
To configure and enable the DSI PHY PLL clocks, the MDSS AHB clock must
be active for MMIO operations. Typically, this AHB clock is enabled as
part of the DSI PHY interface enabling (dsi_phy_enable_resource).
However, since these PLL clocks are registered as clock entities, they
can be enabled independently of the DSI PHY interface, leading to
enabling failures and subsequent warnings:
```
msm_dsi_phy 5e94400.phy: [drm:dsi_pll_14nm_vco_prepare] *ERROR* DSI PLL lock failed
------------[ cut here ]------------
dsi0pllbyte already disabled
WARNING: CPU: 3 PID: 1 at drivers/clk/clk.c:1194 clk_core_disable+0xa4/0xac
CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Tainted:
Tainted: [W]=WARN
Hardware name: Qualcomm Technologies, Inc. Robotics RB1 (DT)
pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[...]
```
This issue is particularly prevalent at boot time during the disabling of
unused clocks (clk_disable_unused()) which includes enabling the parent
clock(s) when CLK_OPS_PARENT_ENABLE flag is set (this is the case for the
14nm DSI PHY PLL consumers).
To resolve this issue, we move the AHB clock as a PM dependency of the DSI
PHY device (via pm_clk). Since the DSI PHY device is the parent of the PLL
clocks, this resolves the PLL/AHB dependency. Now the AHB clock is enabled
prior the PLL clk_prepare callback, as part of the runtime-resume chain.
We also eliminate dsi_phy_[enable|disable]_resource functions, which are
superseded by runtime PM.
Note that it breaks compatibility with kernels before 6.0, as we do not
support anymore the legacy `iface_clk` name.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/663239/
Link: https://lore.kernel.org/r/20250709140836.124143-1-loic.poulain@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
Update nova to import `ARef` from `sync::aref` instead of `types`.
This aligns with the ongoing effort to move `ARef` and
`AlwaysRefCounted` to sync.
Suggested-by: Benno Lossin <lossin@kernel.org>
Link: https://github.com/Rust-for-Linux/linux/issues/1173
Signed-off-by: Shankari Anand <shankari.ak0208@gmail.com>
Link: https://lore.kernel.org/r/20250716090941.811418-1-shankari.ak0208@gmail.com
[ Alter subject and commit message to be nova specific. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Add device info for wildcat lake. WCL has 3 pipes and 2 TC ports.
Suggested-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/20250808081931.4101388-2-chaitanya.kumar.borah@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
WCL has 3 pipes and two TC ports, create power well mapping to reflect
HW. Rest remains similar to Xe3 power well configuration.
v2: Remove TC3/4 ports as they do not exist.
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/20250808081931.4101388-1-chaitanya.kumar.borah@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
Debug print the TypeC pin assignment and max lane count value during HW
readout and after resetting the TypeC mode.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-20-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
Cache the pin assignment value. This is more consistent with the way the
max lane count value is tracked and a bit more efficient than reading
out the same value from HW each time it's queried.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-19-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
The pin assignment is only relevant in case the PHY is owned by the
display, that is in legacy and DP-alt mode. In TBT-alt mode the PHY is
owned by the TBT FW/driver and so the pin assignment/configuration is
managed by those components. A follow-up change will cache the pin
assignment value in all the TypeC modes - querying this by calling
get_pin_assignment() - prepare for that here, by reporting pin
assignment NONE in the TBT-alt mode.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-18-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
Pass the intel_tc_port pointer instead of intel_digital_port to all lane
mask and count query helpers internal to intel_tc.c, to avoid the
redundant intel_digital_port -> intel_tc_port conversions.
While at it shorten the function names, keeping the intel_tc_port_
prefix only for exported functions and use the mtl_, icl_ prefixes
making it clear which platforms a given query function is specific for.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-17-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
For consistency, handle the case where
intel_tc_port_get_pin_assignment() is called for a non-TypeC encoder,
returning the default NONE pin assignment value, similarly to how this
is done in intel_tc_port_max_lane_count().
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-16-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
Unify the way to get the max lane count value on all MTL+ platforms,
reducing the code duplication.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-15-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
Unify the way to get the pin assignment on all platforms. This removes
the duplication in the helper functions in this and a follow-up change.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-14-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
Validate the pin assignment on ICL-TGL, similarly to how this is done on
MTL+. ICL supports all the pin assignments, while TGL+ supports only the
NONE, C, D, E pin assignments.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-13-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
For consistency, handle pin assignment NONE on all platforms similarly
to LNL+. On earlier platforms the driver doesn't actually see this pin
assignment - as it's not valid on a connected DP-alt PHY - however it's
a valid HW setting even on those platforms, for instance in legacy mode.
Handle this pin assignment on earlier platforms as well, so that the way
to query the pin assignment can be unified by a follow-up change.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-12-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
Pass around the pin assignment value via the corresponding enum instead
of a plain integer.
While at it rename intel_tc_port_get_pin_assignment_mask() to
intel_tc_port_get_pin_assignment(), since the value returned is not a
mask.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-11-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
Add an enum for the TypeC pin assignment, which is a better way to pass
its value around than a plain integer. While at it add a description for
each pin assignment, based on the DP and DP Alt mode Standards, opting
for more details to ease any future debugging related to a given pin
assignment and the cables / sink types used.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
[Imre: s/deined/defined in pin assignment enum documentation.]
Link: https://lore.kernel.org/r/20250805073700.642107-10-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
Move asserting the expected TC cold power state and the read out
register value right after reading the TCSS_DDI_STATUS register,
similarly to how this is done with the other PORT_TX_DFLEXDPSP and
PORT_TX_DFLEXPA1 PHY registers.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-9-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
Move getting the required display power domain right before reading the
PORT_TX_DFLEXDPSP and PORT_TX_DFLEXPA1 registers, similarly to how this
is done while reading the other TCSS_DDI_STATUS PHY register.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-8-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
Use the PHY's cached max lane count value on all platforms similarly to
LNL+. On LNL+ using the cached value is mandatory - since the
corresponding HW register field can get cleared by the time the value is
queried - on earlier platforms there isn't a problem with using the HW
register instead. Having a uniform way to query the value still makes
sense and it's also a bit more efficient, so do that.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-7-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
This reverts commit 515986100d176663d0a03219a3056e4252f729e6.
The dma_buf field in struct drm_gem_object is not stable over the
object instance's lifetime. The field becomes NULL when user space
releases the final GEM handle on the buffer object. This resulted
in a NULL-pointer deref.
Workarounds in commit 5307dce878d4 ("drm/gem: Acquire references on
GEM handles for framebuffers") and commit f6bfc9afc751 ("drm/framebuffer:
Acquire internal references on GEM handles") only solved the problem
partially. They especially don't work for buffer objects without a DRM
framebuffer associated.
Hence, this revert to going back to using .import_attach->dmabuf.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Simona Vetter <simona.vetter@ffwll.ch>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://lore.kernel.org/r/20250715082635.34974-1-tzimmermann@suse.de
|
|
<linux/mod_devicetable.h>
Include <linux/property.h> to declare device_property_read_u32() and
<linux/mod_devicetable.h> to declare struct of_device_id. Avoids the
dependency on the backlight header to include it.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250812081118.221103-1-tzimmermann@suse.de
|
|
The current wait_panel_status() uses intel_de_wait(),
which internally on Xe platforms calls xe_mmio_wait32().
xe_mmio_wait32() increases poll interval exponentially.
This exponential poll interval increase causes unnessory delays
during resume or power-on when the panel becomes ready earlier,
but polling is delayed due to backoff.
Replace intel_de_wait() with read_poll_timeout() +
intel_de_read() to actively poll the register at a fixed 10ms interval
up to a 5 second timeout. This allows poll to exit
early when panel is ready.
Changes in v2:
Replaced two-phase intel_de_wait() with read_poll_timeout()
+ intel_de_read()
Changes in v3:
- Add poll_interval_ms argument 'wait_panel_status' function.
- Modify 'wait_panel_status' callers with proper poll interval
Changes in v4:
- Change 'wait_panel_off' poll interval to 10ms
Changes in v5:
- Dropped poll_interval_ms parameter,use fixed polling
interval of 10ms (Jani Nikula)
Changes in v6:
- Removed goto in error path
Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Link: https://lore.kernel.org/r/20250807082402.79018-1-dibin.moolakadan.subrahmanian@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Add a call to drm_aperture_remove_framebuffers() to drop the possible
early fb (simplefb).
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20250416-tidss-splash-v1-2-4ff396eb5008@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
|
|
The assignment of zero to variable is redundant as the following
continue statement loops back to the start of the loop where
ret is assigned a new value from the return to the call to
get_parent_dss_vp. Remove assignment.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Link: https://lore.kernel.org/r/20250702084844.966199-1-colin.i.king@gmail.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
|
|
TIDSS uses crtc_* fields to propagate its registers and set the
clock rates. So set the CRTC modesetting timing parameters with
the adjusted mode when needed, to set correct values.
Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Link: https://lore.kernel.org/r/20250624080402.302526-1-j-choudhary@ti.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
|
|
While the cdns-dsi does not support DSI burst mode, the burst mode is
essentially DSI event mode with more versatile clocking and timings.
Thus cdns-dsi doesn't need to fail if the DSI peripheral driver requests
MIPI_DSI_MODE_VIDEO_BURST.
In my particular use case, this allows the use of ti-sn65dsi83 driver.
Tested-by: Parth Pancholi <parth.pancholi@toradex.com>
Tested-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
Link: https://lore.kernel.org/r/20250723-cdns-dsi-impro-v5-15-e61cc06074c2@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
|
|
The driver currently expects the pixel clock and the HS clock to be
compatible, but the DPHY PLL doesn't give very finely grained rates.
This often leads to the situation where the pipeline just fails, as the
resulting HS clock is just too off.
We could change the driver to do a better job on adjusting the DSI
blanking values, hopefully getting a working pipeline even if the pclk
and HS clocks are not exactly compatible. But that is a bigger work.
What we can do easily is to see in .atomic_check() what HS clock rate we
can get, based on the pixel clock rate, and then convert the HS clock
rate back to pixel clock rate and ask that rate from the crtc. If the
crtc has a good PLL (which is the case for TI K3 SoCs), this will fix
any issues wrt. the clock rates.
If the crtc cannot provide the requested clock, well, we're no worse off
with this patch than what we have at the moment.
Tested-by: Parth Pancholi <parth.pancholi@toradex.com>
Tested-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
Link: https://lore.kernel.org/r/20250723-cdns-dsi-impro-v5-14-e61cc06074c2@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
|
|
The timings calculation gets it wrong for DSI event mode, resulting in
too large hbp value. Fix the issue by taking into account the
pulse/event mode difference.
Tested-by: Parth Pancholi <parth.pancholi@toradex.com>
Reviewed-by: Jayesh Choudhary <j-choudhary@ti.com>
Tested-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
Link: https://lore.kernel.org/r/20250723-cdns-dsi-impro-v5-13-e61cc06074c2@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
|
|
The driver does all the calculations and programming with video timings
(hftp, hbp, etc.) instead of the modeline values (hsync_start, ...).
Thus it makes sense to use struct videomode instead of struct
drm_display_mode internally.
Switch to videomode and do some cleanups in cdns_dsi_mode2cfg() along
the way.
Tested-by: Parth Pancholi <parth.pancholi@toradex.com>
Reviewed-by: Aradhya Bhatia <aradhya.bhatia@linux.dev>
Tested-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
Link: https://lore.kernel.org/r/20250723-cdns-dsi-impro-v5-12-e61cc06074c2@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
|
|
The driver tries to calculate the value for REG_WAKEUP_TIME. However,
the calculation itself is not correct, and to add on it, the resulting
value is almost always larger than the field's size, so the actual
result is more or less random.
According to the docs, figuring out the value for REG_WAKEUP_TIME
requires HW characterization and there's no way to have a generic
algorithm to come up with the value. That doesn't help at all...
However, we know that the value must be smaller than the line time, and,
at least in my understanding, the proper value for it is quite small.
Testing shows that setting it to 1/10 of the line time seems to work
well. All video modes from my HDMI monitor work with this algorithm.
Hopefully we'll get more information on how to calculate the value, and
we can then update this.
Tested-by: Parth Pancholi <parth.pancholi@toradex.com>
Tested-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
Link: https://lore.kernel.org/r/20250723-cdns-dsi-impro-v5-11-e61cc06074c2@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
|
|
The Cadence DSI requires negative syncs from the incoming video signal,
but at the moment that requirement is not expressed in any way. If the
crtc decides to use positive syncs, things break down.
Use the adjusted_mode in atomic_check to set the sync flags to negative
ones.
Reviewed-by: Aradhya Bhatia <aradhya.bhatia@linux.dev>
Tested-by: Parth Pancholi <parth.pancholi@toradex.com>
Tested-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
Link: https://lore.kernel.org/r/20250723-cdns-dsi-impro-v5-10-e61cc06074c2@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
|
|
cdns_dsi_adjust_phy_config() is called from cdns_dsi_check_conf(), which
is called from .atomic_check(). It checks the DSI htotal and adjusts it
to align on the DSI lane boundary by changing hfp and then recalculating
htotal and HS clock rate.
This has a few problems.
First is the fact that the whole thing is not needed: we do not need to
align on the lane boundary. The whole frame is sent in HS mode, and it
is fine if the line's last byte clock tick fills, say, only 2 of the 4
lanes. The next line will just continue from there. Assuming the
DSI timing values have been calculated to match the incoming DPI stream,
and the HS clock is compatible with the DPI pixel clock, the "uneven"
DSI lines will even out when multiple lines are being sent.
But we could do the align, aligning is not a problem as such. However,
adding more bytes to the hfp, as the function currently does, makes the
DSI line time longer, so the function then adjusts the HS clock rate.
This is where things fail: we don't know what rates we can get from the
HS clock, and at least in TI K3 SoC case the rates are quite coarsely
grained. Thus small adjustment to hfp will lead to a big change in HS
clock rate, and things break down.
We could do a loop here, adjusting hfp, adjusting clock, checking clock
rate, adjusting hfp again, etc., but considering that the whole
adjustment shouldn't be needed at all, it's easier to just remove the
function.
Something like this function should be added back later, when adding
burst mode support, but that's a bigger change and I don't think this
function would help that work in any way.
Tested-by: Parth Pancholi <parth.pancholi@toradex.com>
Tested-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
Link: https://lore.kernel.org/r/20250723-cdns-dsi-impro-v5-9-e61cc06074c2@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
|
|
cdns_dsi_mode2cfg() calculates the dsi timings, but for some reason
doesn't set the htotal based on those timings. It is set only later, in
cdns_dsi_adjust_phy_config().
As cdns_dsi_mode2cfg() is the logical place to calculate it, let's move
it there. Especially as the following patch will remove
cdns_dsi_adjust_phy_config().
Reviewed-by: Aradhya Bhatia <aradhya.bhatia@linux.dev>
Tested-by: Parth Pancholi <parth.pancholi@toradex.com>
Tested-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
Link: https://lore.kernel.org/r/20250723-cdns-dsi-impro-v5-8-e61cc06074c2@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
|
|
The docs say about mode_valid():
"it is not allowed to look at anything else but the passed-in mode, and
validate it against configuration-invariant hardware constraints"
We're doing a lot more than just looking at the mode. The main issue
here is that we're doing checks based on the pixel clock, before we know
what the pixel clock from the crtc actually is.
So, drop the cdns_dsi_check_conf() call from .mode_valid().
Reviewed-by: Aradhya Bhatia <aradhya.bhatia@linux.dev>
Tested-by: Parth Pancholi <parth.pancholi@toradex.com>
Tested-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
Link: https://lore.kernel.org/r/20250723-cdns-dsi-impro-v5-7-e61cc06074c2@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
|
|
The driver checks if "DPI(HFP) > DSI(HSS+HSA+HSE+HBP)", and rejects the
mode if not.
However, testing shows that this doesn't hold at all. I can set the hfp
to very small values, with no errors. The feedback from the HW team also
was that the check is not right, although it's not clear if there's a
way to validate the FIFO emptying.
The check rejects quite a lot of modes, apparently for no good reason,
so drop the check.
Tested-by: Parth Pancholi <parth.pancholi@toradex.com>
Tested-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
Link: https://lore.kernel.org/r/20250723-cdns-dsi-impro-v5-6-e61cc06074c2@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
|
|
With recent change the cdns_dsi_check_conf() is always called with
mode_valid_check = true. We can thus remove all the code related to the
"false" paths.
Tested-by: Parth Pancholi <parth.pancholi@toradex.com>
Tested-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
Link: https://lore.kernel.org/r/20250723-cdns-dsi-impro-v5-5-e61cc06074c2@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
|
