[PATCH 0/4] arm64: dts: qcom: support SDM845 HDK

[PATCH 0/4] arm64: dts: qcom: support SDM845 HDK

[Dmitry Baryshkov]

Lantronix HDK845 aka Qualcomm SDM845-HDK is a hardware development kit
for the Qualcomm SDM845 / SDA845 platform. It uses the modem-less
version of the chip (SDA845) and provides a rich set of the peripherals
and connectors.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
David Heidelberg (1):
      arm64: dts: qcom: sdm845: Add missing MDSS reset

Dmitry Baryshkov (3):
      clk: qcom: dispcc-sdm845: set GENPD_FLAG_NO_STAY_ON flag for MDSS domain
      dt-bindings: arm: qcom: add Qualcomm SDM845 HDK
      arm64: dts: qcom: add device tree for SDM845-HDK

 Documentation/devicetree/bindings/arm/qcom.yaml |   1 +
 arch/arm64/boot/dts/qcom/Makefile               |   1 +
 arch/arm64/boot/dts/qcom/sdm845-hdk.dts         | 820 ++++++++++++++++++++++++
 arch/arm64/boot/dts/qcom/sdm845.dtsi            |   1 +
 drivers/clk/qcom/dispcc-sdm845.c                |   1 +
 5 files changed, 824 insertions(+)
---
base-commit: 54f467c01375a137f5801a910089138d2202b148
change-id: 20260122-sdm845-hdk-9466530c4267

Best regards,
-- 
With best wishes
Dmitry

[PATCH 1/4] clk: qcom: dispcc-sdm845: set GENPD_FLAG_NO_STAY_ON flag for MDSS domain

[Dmitry Baryshkov]

Since the commit 13a4b7fb6260 ("pmdomain: core: Leave powered-on genpds
on until late_initcall_sync") setting of the display clocks is partially
broken. For example, when on SDM845-HDK the bootloader leaves display
enabled, later the kernel can't set up DSI clocks, ending up with the
broken display, blinking blue.

 ------------[ cut here ]------------
 disp_cc_mdss_pclk0_clk_src: rcg didn't update its configuration.
 WARNING: CPU: 7 PID: 81 at drivers/clk/qcom/clk-rcg2.c:136 update_config+0xd4/0xf0
 Modules linked in:
 CPU: 7 UID: 0 PID: 81 Comm: kworker/u32:3 Not tainted 6.16.0-rc2-00040-ga3f36de2f3ba #4236 PREEMPT
 Hardware name: Qualcomm Technologies, Inc. SDM845 HDK (DT)
 Workqueue: events_unbound deferred_probe_work_func
 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : update_config+0xd4/0xf0
 lr : update_config+0xd4/0xf0
 sp : ffff800080992a30
 x29: ffff800080992a40 x28: 0000000000000001 x27: ffff00008db49080
 x26: ffff00008db49220 x25: 0000000000000000 x24: 0000000008d9ee20
 x23: ffffd6f1bf1f6cd8 x22: 0000000008d9ee20 x21: ffffd6f1becadfa8
 x20: ffffd6f1bf1f6cc0 x19: 0000000000000000 x18: fffffffffffef3f0
 x17: 0000000000000004 x16: 0000000000000024 x15: 0000000000000005
 x14: fffffffffffcf3ef x13: 2e6e6f6974617275 x12: 6769666e6f632073
 x11: 7469206574616470 x10: 752074276e646964 x9 : 72756769666e6f63
 x8 : ffff800080992790 x7 : ffff8000809928c0 x6 : ffff800080992850
 x5 : ffff8000809927d0 x4 : ffff800080994000 x3 : 0000000000000000
 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000808d1b00
 Call trace:
  update_config+0xd4/0xf0 (P)
  clk_rcg2_configure+0xb8/0xc0
  clk_pixel_set_rate+0x138/0x180
  clk_change_rate+0x124/0x620
  clk_change_rate+0x1b4/0x620
  clk_change_rate+0x1b4/0x620
  clk_change_rate+0x1b4/0x620
  clk_change_rate+0x1b4/0x620
  clk_change_rate+0x1b4/0x620
  clk_change_rate+0x1b4/0x620
  clk_core_set_rate_nolock+0x230/0x2b0
  clk_set_rate+0x38/0x90
  _opp_config_clk_single+0x30/0x98
  _set_opp+0x11c/0x530
  dev_pm_opp_set_rate+0x18c/0x280
  dsi_link_clk_set_rate_6g+0x44/0x100
  msm_dsi_host_power_on+0xc4/0x988
  dsi_mgr_bridge_pre_enable+0x194/0x3e0
  drm_atomic_bridge_call_pre_enable+0x40/0x58
  drm_atomic_bridge_chain_pre_enable+0x50/0x130
  drm_atomic_helper_commit_modeset_enables+0x15c/0x26c
  msm_atomic_commit_tail+0x214/0xb18
  commit_tail+0xa0/0x1a0
  drm_atomic_helper_commit+0x1a8/0x1d0
  drm_atomic_commit+0x8c/0xcc
  drm_client_modeset_commit_atomic+0x258/0x2d0
  drm_client_modeset_commit_locked+0x60/0x1b8
  drm_client_modeset_commit+0x2c/0x58
  __drm_fb_helper_restore_fbdev_mode_unlocked+0xbc/0xe8
  drm_fb_helper_set_par+0x30/0x58
  fbcon_init+0x3cc/0x530
  visual_init+0x8c/0xe0
  do_bind_con_driver.isra.0+0x18c/0x320
  do_take_over_console+0x13c/0x1d4
  do_fbcon_takeover+0x6c/0xe0
  fbcon_fb_registered+0x1dc/0x1e0
  do_register_framebuffer+0x1bc/0x278
  register_framebuffer+0x30/0x5c
  __drm_fb_helper_initial_config_and_unlock+0x2dc/0x5a8
  drm_fb_helper_initial_config+0x48/0x58
  drm_fbdev_client_hotplug+0x7c/0xe0
  drm_client_register+0x5c/0xa0
  drm_fbdev_client_setup+0xa4/0x1c0
  drm_client_setup+0x58/0xa0
  msm_drm_bind+0x3b4/0x460
  try_to_bring_up_aggregate_device+0x16c/0x1e0
  __component_add+0xa8/0x170
  component_add+0x14/0x20
  dsi_dev_attach+0x20/0x38
  dsi_host_attach+0x58/0x98
  devm_mipi_dsi_attach+0x34/0x90
  lt9611_attach_dsi+0x98/0x120
  lt9611_probe+0x3f8/0x4a0
  i2c_device_probe+0x154/0x340
  really_probe+0xbc/0x2c0
  __driver_probe_device+0x78/0x120
  driver_probe_device+0x3c/0x160
  __device_attach_driver+0xb8/0x140
  bus_for_each_drv+0x88/0xe8
  __device_attach+0xa0/0x198
  device_initial_probe+0x14/0x20
  bus_probe_device+0xb4/0xc0
  deferred_probe_work_func+0x90/0xcc
  process_one_work+0x214/0x64c
  worker_thread+0x1c0/0x364
  kthread+0x14c/0x220
  ret_from_fork+0x10/0x20
 irq event stamp: 110949
 hardirqs last  enabled at (110949): [<ffffd6f1be502d78>] _raw_spin_unlock_irqrestore+0x6c/0x74
 hardirqs last disabled at (110948): [<ffffd6f1be502268>] _raw_spin_lock_irqsave+0x84/0x88
 softirqs last  enabled at (109450): [<ffffd6f1be1b9ff0>] release_sock+0x90/0xa4
 softirqs last disabled at (109448): [<ffffd6f1be1b9f88>] release_sock+0x28/0xa4
 ---[ end trace 0000000000000000 ]---
 ------------[ cut here ]------------
 disp_cc_mdss_pclk1_clk_src: rcg didn't update its configuration.
 WARNING: CPU: 7 PID: 81 at drivers/clk/qcom/clk-rcg2.c:136 update_config+0xd4/0xf0
 Modules linked in:
 CPU: 7 UID: 0 PID: 81 Comm: kworker/u32:3 Tainted: G        W           6.16.0-rc2-00040-ga3f36de2f3ba #4236 PREEMPT
 Tainted: [W]=WARN
 Hardware name: Qualcomm Technologies, Inc. SDM845 HDK (DT)
 Workqueue: events_unbound deferred_probe_work_func
 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : update_config+0xd4/0xf0
 lr : update_config+0xd4/0xf0
 sp : ffff800080992a30
 x29: ffff800080992a40 x28: 0000000000000001 x27: ffff00008db49080
 x26: ffff00008db49220 x25: 0000000000000000 x24: 0000000008d9ee20
 x23: ffffd6f1bf1f6c48 x22: 0000000008d9ee20 x21: ffffd6f1becb1b50
 x20: ffffd6f1bf1f6c30 x19: 0000000000000000 x18: ffffffffffff0790
 x17: 0000000000000004 x16: 0000000000000024 x15: 0000000000000005
 x14: fffffffffffd078f x13: 2e6e6f6974617275 x12: 6769666e6f632073
 x11: 7469206574616470 x10: 752074276e646964 x9 : 72756769666e6f63
 x8 : ffff800080992790 x7 : ffff8000809928c0 x6 : ffff800080992850
 x5 : ffff8000809927d0 x4 : ffff800080994000 x3 : 0000000000000000
 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000808d1b00
 Call trace:
  update_config+0xd4/0xf0 (P)
  clk_rcg2_configure+0xb8/0xc0
  clk_pixel_set_rate+0x138/0x180
  clk_change_rate+0x124/0x620
  clk_change_rate+0x1b4/0x620
  clk_change_rate+0x1b4/0x620
  clk_change_rate+0x1b4/0x620
  clk_change_rate+0x1b4/0x620
  clk_change_rate+0x1b4/0x620
  clk_change_rate+0x1b4/0x620
  clk_core_set_rate_nolock+0x230/0x2b0
  clk_set_rate+0x38/0x90
  _opp_config_clk_single+0x30/0x98
  _set_opp+0x11c/0x530
  dev_pm_opp_set_rate+0x18c/0x280
  dsi_link_clk_set_rate_6g+0x44/0x100
  msm_dsi_host_power_on+0xc4/0x988
  dsi_mgr_bridge_pre_enable+0x194/0x3e0
  drm_atomic_bridge_call_pre_enable+0x40/0x58
  drm_atomic_bridge_chain_pre_enable+0x50/0x130
  drm_atomic_helper_commit_modeset_enables+0x15c/0x26c
  msm_atomic_commit_tail+0x214/0xb18
  commit_tail+0xa0/0x1a0
  drm_atomic_helper_commit+0x1a8/0x1d0
  drm_atomic_commit+0x8c/0xcc
  drm_client_modeset_commit_atomic+0x258/0x2d0
  drm_client_modeset_commit_locked+0x60/0x1b8
  drm_client_modeset_commit+0x2c/0x58
  __drm_fb_helper_restore_fbdev_mode_unlocked+0xbc/0xe8
  drm_fb_helper_set_par+0x30/0x58
  fbcon_init+0x3cc/0x530
  visual_init+0x8c/0xe0
  do_bind_con_driver.isra.0+0x18c/0x320
  do_take_over_console+0x13c/0x1d4
  do_fbcon_takeover+0x6c/0xe0
  fbcon_fb_registered+0x1dc/0x1e0
  do_register_framebuffer+0x1bc/0x278
  register_framebuffer+0x30/0x5c
  __drm_fb_helper_initial_config_and_unlock+0x2dc/0x5a8
  drm_fb_helper_initial_config+0x48/0x58
  drm_fbdev_client_hotplug+0x7c/0xe0
  drm_client_register+0x5c/0xa0
  drm_fbdev_client_setup+0xa4/0x1c0
  drm_client_setup+0x58/0xa0
  msm_drm_bind+0x3b4/0x460
  try_to_bring_up_aggregate_device+0x16c/0x1e0
  __component_add+0xa8/0x170
  component_add+0x14/0x20
  dsi_dev_attach+0x20/0x38
  dsi_host_attach+0x58/0x98
  devm_mipi_dsi_attach+0x34/0x90
  lt9611_attach_dsi+0x98/0x120
  lt9611_probe+0x3f8/0x4a0
  i2c_device_probe+0x154/0x340
  really_probe+0xbc/0x2c0
  __driver_probe_device+0x78/0x120
  driver_probe_device+0x3c/0x160
  __device_attach_driver+0xb8/0x140
  bus_for_each_drv+0x88/0xe8
  __device_attach+0xa0/0x198
  device_initial_probe+0x14/0x20
  bus_probe_device+0xb4/0xc0
  deferred_probe_work_func+0x90/0xcc
  process_one_work+0x214/0x64c
  worker_thread+0x1c0/0x364
  kthread+0x14c/0x220
  ret_from_fork+0x10/0x20
 irq event stamp: 110949
 hardirqs last  enabled at (110949): [<ffffd6f1be502d78>] _raw_spin_unlock_irqrestore+0x6c/0x74
 hardirqs last disabled at (110948): [<ffffd6f1be502268>] _raw_spin_lock_irqsave+0x84/0x88
 softirqs last  enabled at (109450): [<ffffd6f1be1b9ff0>] release_sock+0x90/0xa4
 softirqs last disabled at (109448): [<ffffd6f1be1b9f88>] release_sock+0x28/0xa4
 ---[ end trace 0000000000000000 ]---
 lt9611 3-003b: video check: hactive_a=0, hactive_b=0, vactive=0, v_total=0, h_total_sysclk=0
 [drm:dpu_encoder_phys_vid_wait_for_commit_done:540] [dpu error]vblank timeout: 2
 [drm:dpu_kms_wait_for_commit_done:524] [dpu error]wait for commit done returned -110
 fb0: sys_imageblit: framebuffer is not in virtual address space.
 [drm:dpu_encoder_phys_vid_wait_for_commit_done:540] [dpu error]vblank timeout: 2
 [drm:dpu_kms_wait_for_commit_done:524] [dpu error]wait for commit done returned -110
 [drm:dpu_encoder_phys_vid_wait_for_commit_done:540] [dpu error]vblank timeout: 2
 [drm:dpu_kms_wait_for_commit_done:524] [dpu error]wait for commit done returned -110
 Console: switching to colour frame buffer device 480x135
 [drm:dpu_encoder_phys_vid_wait_for_commit_done:540] [dpu error]vblank timeout: 2
 [drm:dpu_kms_wait_for_commit_done:524] [dpu error]wait for commit done returned -110
 [drm:dpu_encoder_phys_vid_wait_for_commit_done:540] [dpu error]vblank timeout: 2
 [drm:dpu_kms_wait_for_commit_done:524] [dpu error]wait for commit done returned -110

Fixes: 13a4b7fb6260 ("pmdomain: core: Leave powered-on genpds on until late_initcall_sync")
Cc: stable@vger.kernel.org
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
 drivers/clk/qcom/dispcc-sdm845.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/qcom/dispcc-sdm845.c b/drivers/clk/qcom/dispcc-sdm845.c
index 78e43f6d7502..468b30497746 100644
--- a/drivers/clk/qcom/dispcc-sdm845.c
+++ b/drivers/clk/qcom/dispcc-sdm845.c
@@ -763,6 +763,7 @@ static struct gdsc mdss_gdsc = {
 	.en_rest_wait_val = 0x5,
 	.pd = {
 		.name = "mdss_gdsc",
+		.flags = GENPD_FLAG_NO_STAY_ON,
 	},
 	.pwrsts = PWRSTS_OFF_ON,
 	.flags = HW_CTRL | POLL_CFG_GDSCR,

-- 
2.47.3

Re: [PATCH 1/4] clk: qcom: dispcc-sdm845: set GENPD_FLAG_NO_STAY_ON flag for MDSS domain

[Taniya Das]

On 2/18/2026 2:50 AM, Dmitry Baryshkov wrote:
> drivers/clk/qcom/dispcc-sdm845.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/clk/qcom/dispcc-sdm845.c b/drivers/clk/qcom/dispcc-sdm845.c
> index 78e43f6d7502..468b30497746 100644
> --- a/drivers/clk/qcom/dispcc-sdm845.c
> +++ b/drivers/clk/qcom/dispcc-sdm845.c
> @@ -763,6 +763,7 @@ static struct gdsc mdss_gdsc = {
>  	.en_rest_wait_val = 0x5,
>  	.pd = {
>  		.name = "mdss_gdsc",
> +		.flags = GENPD_FLAG_NO_STAY_ON,
>  	},
>  	.pwrsts = PWRSTS_OFF_ON,
>  	.flags = HW_CTRL | POLL_CFG_GDSCR,


Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>

-- 
Thanks,
Taniya Das

Re: [PATCH 1/4] clk: qcom: dispcc-sdm845: set GENPD_FLAG_NO_STAY_ON flag for MDSS domain

[Krzysztof Kozlowski]

On 17/02/2026 22:20, Dmitry Baryshkov wrote:
> Since the commit 13a4b7fb6260 ("pmdomain: core: Leave powered-on genpds
> on until late_initcall_sync") setting of the display clocks is partially
> broken. For example, when on SDM845-HDK the bootloader leaves display
> enabled, later the kernel can't set up DSI clocks, ending up with the
> broken display, blinking blue.
> 
>  ------------[ cut here ]------------
>  disp_cc_mdss_pclk0_clk_src: rcg didn't update its configuration.
>  WARNING: CPU: 7 PID: 81 at drivers/clk/qcom/clk-rcg2.c:136 update_config+0xd4/0xf0
>  Modules linked in:
>  CPU: 7 UID: 0 PID: 81 Comm: kworker/u32:3 Not tainted 6.16.0-rc2-00040-ga3f36de2f3ba #4236 PREEMPT
>  Hardware name: Qualcomm Technologies, Inc. SDM845 HDK (DT)
>  Workqueue: events_unbound deferred_probe_work_func
>  pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>  pc : update_config+0xd4/0xf0
>  lr : update_config+0xd4/0xf0
>  sp : ffff800080992a30
>  x29: ffff800080992a40 x28: 0000000000000001 x27: ffff00008db49080
>  x26: ffff00008db49220 x25: 0000000000000000 x24: 0000000008d9ee20
>  x23: ffffd6f1bf1f6cd8 x22: 0000000008d9ee20 x21: ffffd6f1becadfa8
>  x20: ffffd6f1bf1f6cc0 x19: 0000000000000000 x18: fffffffffffef3f0
>  x17: 0000000000000004 x16: 0000000000000024 x15: 0000000000000005
>  x14: fffffffffffcf3ef x13: 2e6e6f6974617275 x12: 6769666e6f632073
>  x11: 7469206574616470 x10: 752074276e646964 x9 : 72756769666e6f63
>  x8 : ffff800080992790 x7 : ffff8000809928c0 x6 : ffff800080992850
>  x5 : ffff8000809927d0 x4 : ffff800080994000 x3 : 0000000000000000
>  x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000808d1b00

Please trim the context/messages - most of above is not needed

>  Call trace:
>   update_config+0xd4/0xf0 (P)
>   clk_rcg2_configure+0xb8/0xc0
>   clk_pixel_set_rate+0x138/0x180
>   clk_change_rate+0x124/0x620
>   clk_change_rate+0x1b4/0x620
>   clk_change_rate+0x1b4/0x620
>   clk_change_rate+0x1b4/0x620
>   clk_change_rate+0x1b4/0x620
>   clk_change_rate+0x1b4/0x620
>   clk_change_rate+0x1b4/0x620
>   clk_core_set_rate_nolock+0x230/0x2b0
>   clk_set_rate+0x38/0x90
>   _opp_config_clk_single+0x30/0x98
>   _set_opp+0x11c/0x530
>   dev_pm_opp_set_rate+0x18c/0x280
>   dsi_link_clk_set_rate_6g+0x44/0x100
>   msm_dsi_host_power_on+0xc4/0x988
>   dsi_mgr_bridge_pre_enable+0x194/0x3e0
>   drm_atomic_bridge_call_pre_enable+0x40/0x58
>   drm_atomic_bridge_chain_pre_enable+0x50/0x130
>   drm_atomic_helper_commit_modeset_enables+0x15c/0x26c
>   msm_atomic_commit_tail+0x214/0xb18
>   commit_tail+0xa0/0x1a0
>   drm_atomic_helper_commit+0x1a8/0x1d0
>   drm_atomic_commit+0x8c/0xcc
>   drm_client_modeset_commit_atomic+0x258/0x2d0
>   drm_client_modeset_commit_locked+0x60/0x1b8
>   drm_client_modeset_commit+0x2c/0x58
>   __drm_fb_helper_restore_fbdev_mode_unlocked+0xbc/0xe8
>   drm_fb_helper_set_par+0x30/0x58
>   fbcon_init+0x3cc/0x530
>   visual_init+0x8c/0xe0
>   do_bind_con_driver.isra.0+0x18c/0x320
>   do_take_over_console+0x13c/0x1d4
>   do_fbcon_takeover+0x6c/0xe0
>   fbcon_fb_registered+0x1dc/0x1e0
>   do_register_framebuffer+0x1bc/0x278
>   register_framebuffer+0x30/0x5c
>   __drm_fb_helper_initial_config_and_unlock+0x2dc/0x5a8
>   drm_fb_helper_initial_config+0x48/0x58
>   drm_fbdev_client_hotplug+0x7c/0xe0
>   drm_client_register+0x5c/0xa0
>   drm_fbdev_client_setup+0xa4/0x1c0
>   drm_client_setup+0x58/0xa0
>   msm_drm_bind+0x3b4/0x460
>   try_to_bring_up_aggregate_device+0x16c/0x1e0
>   __component_add+0xa8/0x170
>   component_add+0x14/0x20
>   dsi_dev_attach+0x20/0x38
>   dsi_host_attach+0x58/0x98
>   devm_mipi_dsi_attach+0x34/0x90
>   lt9611_attach_dsi+0x98/0x120
>   lt9611_probe+0x3f8/0x4a0
>   i2c_device_probe+0x154/0x340
>   really_probe+0xbc/0x2c0

Nothing below makes sense either

>   __driver_probe_device+0x78/0x120
>   driver_probe_device+0x3c/0x160
>   __device_attach_driver+0xb8/0x140
>   bus_for_each_drv+0x88/0xe8
>   __device_attach+0xa0/0x198
>   device_initial_probe+0x14/0x20
>   bus_probe_device+0xb4/0xc0
>   deferred_probe_work_func+0x90/0xcc
>   process_one_work+0x214/0x64c
>   worker_thread+0x1c0/0x364
>   kthread+0x14c/0x220
>   ret_from_fork+0x10/0x20
>  irq event stamp: 110949
>  hardirqs last  enabled at (110949): [<ffffd6f1be502d78>] _raw_spin_unlock_irqrestore+0x6c/0x74
>  hardirqs last disabled at (110948): [<ffffd6f1be502268>] _raw_spin_lock_irqsave+0x84/0x88
>  softirqs last  enabled at (109450): [<ffffd6f1be1b9ff0>] release_sock+0x90/0xa4
>  softirqs last disabled at (109448): [<ffffd6f1be1b9f88>] release_sock+0x28/0xa4
>  ---[ end trace 0000000000000000 ]---
>  ------------[ cut here ]------------
>  disp_cc_mdss_pclk1_clk_src: rcg didn't update its configuration.

And that's the same log.

Best regards,
Krzysztof

Re: [PATCH 1/4] clk: qcom: dispcc-sdm845: set GENPD_FLAG_NO_STAY_ON flag for MDSS domain

[Bjorn Andersson]

On Tue, Feb 17, 2026 at 11:20:42PM +0200, Dmitry Baryshkov wrote:
> Since the commit 13a4b7fb6260 ("pmdomain: core: Leave powered-on genpds
> on until late_initcall_sync") setting of the display clocks is partially
> broken. For example, when on SDM845-HDK the bootloader leaves display
> enabled, later the kernel can't set up DSI clocks, ending up with the
> broken display, blinking blue.

This describes how the problem manifest itself. Can you please document
why clocks are partially broken and how that relate to the GDSC state,
and why setting GENPD_FLAG_NO_STAY_ON solves this?

Regards,
Bjorn

> 
>  ------------[ cut here ]------------
>  disp_cc_mdss_pclk0_clk_src: rcg didn't update its configuration.
>  WARNING: CPU: 7 PID: 81 at drivers/clk/qcom/clk-rcg2.c:136 update_config+0xd4/0xf0
>  Modules linked in:
>  CPU: 7 UID: 0 PID: 81 Comm: kworker/u32:3 Not tainted 6.16.0-rc2-00040-ga3f36de2f3ba #4236 PREEMPT
>  Hardware name: Qualcomm Technologies, Inc. SDM845 HDK (DT)
>  Workqueue: events_unbound deferred_probe_work_func
>  pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>  pc : update_config+0xd4/0xf0
>  lr : update_config+0xd4/0xf0
>  sp : ffff800080992a30
>  x29: ffff800080992a40 x28: 0000000000000001 x27: ffff00008db49080
>  x26: ffff00008db49220 x25: 0000000000000000 x24: 0000000008d9ee20
>  x23: ffffd6f1bf1f6cd8 x22: 0000000008d9ee20 x21: ffffd6f1becadfa8
>  x20: ffffd6f1bf1f6cc0 x19: 0000000000000000 x18: fffffffffffef3f0
>  x17: 0000000000000004 x16: 0000000000000024 x15: 0000000000000005
>  x14: fffffffffffcf3ef x13: 2e6e6f6974617275 x12: 6769666e6f632073
>  x11: 7469206574616470 x10: 752074276e646964 x9 : 72756769666e6f63
>  x8 : ffff800080992790 x7 : ffff8000809928c0 x6 : ffff800080992850
>  x5 : ffff8000809927d0 x4 : ffff800080994000 x3 : 0000000000000000
>  x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000808d1b00
>  Call trace:
>   update_config+0xd4/0xf0 (P)
>   clk_rcg2_configure+0xb8/0xc0
>   clk_pixel_set_rate+0x138/0x180
>   clk_change_rate+0x124/0x620
>   clk_change_rate+0x1b4/0x620
>   clk_change_rate+0x1b4/0x620
>   clk_change_rate+0x1b4/0x620
>   clk_change_rate+0x1b4/0x620
>   clk_change_rate+0x1b4/0x620
>   clk_change_rate+0x1b4/0x620
>   clk_core_set_rate_nolock+0x230/0x2b0
>   clk_set_rate+0x38/0x90
>   _opp_config_clk_single+0x30/0x98
>   _set_opp+0x11c/0x530
>   dev_pm_opp_set_rate+0x18c/0x280
>   dsi_link_clk_set_rate_6g+0x44/0x100
>   msm_dsi_host_power_on+0xc4/0x988
>   dsi_mgr_bridge_pre_enable+0x194/0x3e0
>   drm_atomic_bridge_call_pre_enable+0x40/0x58
>   drm_atomic_bridge_chain_pre_enable+0x50/0x130
>   drm_atomic_helper_commit_modeset_enables+0x15c/0x26c
>   msm_atomic_commit_tail+0x214/0xb18
>   commit_tail+0xa0/0x1a0
>   drm_atomic_helper_commit+0x1a8/0x1d0
>   drm_atomic_commit+0x8c/0xcc
>   drm_client_modeset_commit_atomic+0x258/0x2d0
>   drm_client_modeset_commit_locked+0x60/0x1b8
>   drm_client_modeset_commit+0x2c/0x58
>   __drm_fb_helper_restore_fbdev_mode_unlocked+0xbc/0xe8
>   drm_fb_helper_set_par+0x30/0x58
>   fbcon_init+0x3cc/0x530
>   visual_init+0x8c/0xe0
>   do_bind_con_driver.isra.0+0x18c/0x320
>   do_take_over_console+0x13c/0x1d4
>   do_fbcon_takeover+0x6c/0xe0
>   fbcon_fb_registered+0x1dc/0x1e0
>   do_register_framebuffer+0x1bc/0x278
>   register_framebuffer+0x30/0x5c
>   __drm_fb_helper_initial_config_and_unlock+0x2dc/0x5a8
>   drm_fb_helper_initial_config+0x48/0x58
>   drm_fbdev_client_hotplug+0x7c/0xe0
>   drm_client_register+0x5c/0xa0
>   drm_fbdev_client_setup+0xa4/0x1c0
>   drm_client_setup+0x58/0xa0
>   msm_drm_bind+0x3b4/0x460
>   try_to_bring_up_aggregate_device+0x16c/0x1e0
>   __component_add+0xa8/0x170
>   component_add+0x14/0x20
>   dsi_dev_attach+0x20/0x38
>   dsi_host_attach+0x58/0x98
>   devm_mipi_dsi_attach+0x34/0x90
>   lt9611_attach_dsi+0x98/0x120
>   lt9611_probe+0x3f8/0x4a0
>   i2c_device_probe+0x154/0x340
>   really_probe+0xbc/0x2c0
>   __driver_probe_device+0x78/0x120
>   driver_probe_device+0x3c/0x160
>   __device_attach_driver+0xb8/0x140
>   bus_for_each_drv+0x88/0xe8
>   __device_attach+0xa0/0x198
>   device_initial_probe+0x14/0x20
>   bus_probe_device+0xb4/0xc0
>   deferred_probe_work_func+0x90/0xcc
>   process_one_work+0x214/0x64c
>   worker_thread+0x1c0/0x364
>   kthread+0x14c/0x220
>   ret_from_fork+0x10/0x20
>  irq event stamp: 110949
>  hardirqs last  enabled at (110949): [<ffffd6f1be502d78>] _raw_spin_unlock_irqrestore+0x6c/0x74
>  hardirqs last disabled at (110948): [<ffffd6f1be502268>] _raw_spin_lock_irqsave+0x84/0x88
>  softirqs last  enabled at (109450): [<ffffd6f1be1b9ff0>] release_sock+0x90/0xa4
>  softirqs last disabled at (109448): [<ffffd6f1be1b9f88>] release_sock+0x28/0xa4
>  ---[ end trace 0000000000000000 ]---
>  ------------[ cut here ]------------
>  disp_cc_mdss_pclk1_clk_src: rcg didn't update its configuration.
>  WARNING: CPU: 7 PID: 81 at drivers/clk/qcom/clk-rcg2.c:136 update_config+0xd4/0xf0
>  Modules linked in:
>  CPU: 7 UID: 0 PID: 81 Comm: kworker/u32:3 Tainted: G        W           6.16.0-rc2-00040-ga3f36de2f3ba #4236 PREEMPT
>  Tainted: [W]=WARN
>  Hardware name: Qualcomm Technologies, Inc. SDM845 HDK (DT)
>  Workqueue: events_unbound deferred_probe_work_func
>  pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>  pc : update_config+0xd4/0xf0
>  lr : update_config+0xd4/0xf0
>  sp : ffff800080992a30
>  x29: ffff800080992a40 x28: 0000000000000001 x27: ffff00008db49080
>  x26: ffff00008db49220 x25: 0000000000000000 x24: 0000000008d9ee20
>  x23: ffffd6f1bf1f6c48 x22: 0000000008d9ee20 x21: ffffd6f1becb1b50
>  x20: ffffd6f1bf1f6c30 x19: 0000000000000000 x18: ffffffffffff0790
>  x17: 0000000000000004 x16: 0000000000000024 x15: 0000000000000005
>  x14: fffffffffffd078f x13: 2e6e6f6974617275 x12: 6769666e6f632073
>  x11: 7469206574616470 x10: 752074276e646964 x9 : 72756769666e6f63
>  x8 : ffff800080992790 x7 : ffff8000809928c0 x6 : ffff800080992850
>  x5 : ffff8000809927d0 x4 : ffff800080994000 x3 : 0000000000000000
>  x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000808d1b00
>  Call trace:
>   update_config+0xd4/0xf0 (P)
>   clk_rcg2_configure+0xb8/0xc0
>   clk_pixel_set_rate+0x138/0x180
>   clk_change_rate+0x124/0x620
>   clk_change_rate+0x1b4/0x620
>   clk_change_rate+0x1b4/0x620
>   clk_change_rate+0x1b4/0x620
>   clk_change_rate+0x1b4/0x620
>   clk_change_rate+0x1b4/0x620
>   clk_change_rate+0x1b4/0x620
>   clk_core_set_rate_nolock+0x230/0x2b0
>   clk_set_rate+0x38/0x90
>   _opp_config_clk_single+0x30/0x98
>   _set_opp+0x11c/0x530
>   dev_pm_opp_set_rate+0x18c/0x280
>   dsi_link_clk_set_rate_6g+0x44/0x100
>   msm_dsi_host_power_on+0xc4/0x988
>   dsi_mgr_bridge_pre_enable+0x194/0x3e0
>   drm_atomic_bridge_call_pre_enable+0x40/0x58
>   drm_atomic_bridge_chain_pre_enable+0x50/0x130
>   drm_atomic_helper_commit_modeset_enables+0x15c/0x26c
>   msm_atomic_commit_tail+0x214/0xb18
>   commit_tail+0xa0/0x1a0
>   drm_atomic_helper_commit+0x1a8/0x1d0
>   drm_atomic_commit+0x8c/0xcc
>   drm_client_modeset_commit_atomic+0x258/0x2d0
>   drm_client_modeset_commit_locked+0x60/0x1b8
>   drm_client_modeset_commit+0x2c/0x58
>   __drm_fb_helper_restore_fbdev_mode_unlocked+0xbc/0xe8
>   drm_fb_helper_set_par+0x30/0x58
>   fbcon_init+0x3cc/0x530
>   visual_init+0x8c/0xe0
>   do_bind_con_driver.isra.0+0x18c/0x320
>   do_take_over_console+0x13c/0x1d4
>   do_fbcon_takeover+0x6c/0xe0
>   fbcon_fb_registered+0x1dc/0x1e0
>   do_register_framebuffer+0x1bc/0x278
>   register_framebuffer+0x30/0x5c
>   __drm_fb_helper_initial_config_and_unlock+0x2dc/0x5a8
>   drm_fb_helper_initial_config+0x48/0x58
>   drm_fbdev_client_hotplug+0x7c/0xe0
>   drm_client_register+0x5c/0xa0
>   drm_fbdev_client_setup+0xa4/0x1c0
>   drm_client_setup+0x58/0xa0
>   msm_drm_bind+0x3b4/0x460
>   try_to_bring_up_aggregate_device+0x16c/0x1e0
>   __component_add+0xa8/0x170
>   component_add+0x14/0x20
>   dsi_dev_attach+0x20/0x38
>   dsi_host_attach+0x58/0x98
>   devm_mipi_dsi_attach+0x34/0x90
>   lt9611_attach_dsi+0x98/0x120
>   lt9611_probe+0x3f8/0x4a0
>   i2c_device_probe+0x154/0x340
>   really_probe+0xbc/0x2c0
>   __driver_probe_device+0x78/0x120
>   driver_probe_device+0x3c/0x160
>   __device_attach_driver+0xb8/0x140
>   bus_for_each_drv+0x88/0xe8
>   __device_attach+0xa0/0x198
>   device_initial_probe+0x14/0x20
>   bus_probe_device+0xb4/0xc0
>   deferred_probe_work_func+0x90/0xcc
>   process_one_work+0x214/0x64c
>   worker_thread+0x1c0/0x364
>   kthread+0x14c/0x220
>   ret_from_fork+0x10/0x20
>  irq event stamp: 110949
>  hardirqs last  enabled at (110949): [<ffffd6f1be502d78>] _raw_spin_unlock_irqrestore+0x6c/0x74
>  hardirqs last disabled at (110948): [<ffffd6f1be502268>] _raw_spin_lock_irqsave+0x84/0x88
>  softirqs last  enabled at (109450): [<ffffd6f1be1b9ff0>] release_sock+0x90/0xa4
>  softirqs last disabled at (109448): [<ffffd6f1be1b9f88>] release_sock+0x28/0xa4
>  ---[ end trace 0000000000000000 ]---
>  lt9611 3-003b: video check: hactive_a=0, hactive_b=0, vactive=0, v_total=0, h_total_sysclk=0
>  [drm:dpu_encoder_phys_vid_wait_for_commit_done:540] [dpu error]vblank timeout: 2
>  [drm:dpu_kms_wait_for_commit_done:524] [dpu error]wait for commit done returned -110
>  fb0: sys_imageblit: framebuffer is not in virtual address space.
>  [drm:dpu_encoder_phys_vid_wait_for_commit_done:540] [dpu error]vblank timeout: 2
>  [drm:dpu_kms_wait_for_commit_done:524] [dpu error]wait for commit done returned -110
>  [drm:dpu_encoder_phys_vid_wait_for_commit_done:540] [dpu error]vblank timeout: 2
>  [drm:dpu_kms_wait_for_commit_done:524] [dpu error]wait for commit done returned -110
>  Console: switching to colour frame buffer device 480x135
>  [drm:dpu_encoder_phys_vid_wait_for_commit_done:540] [dpu error]vblank timeout: 2
>  [drm:dpu_kms_wait_for_commit_done:524] [dpu error]wait for commit done returned -110
>  [drm:dpu_encoder_phys_vid_wait_for_commit_done:540] [dpu error]vblank timeout: 2
>  [drm:dpu_kms_wait_for_commit_done:524] [dpu error]wait for commit done returned -110
> 
> Fixes: 13a4b7fb6260 ("pmdomain: core: Leave powered-on genpds on until late_initcall_sync")
> Cc: stable@vger.kernel.org
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
>  drivers/clk/qcom/dispcc-sdm845.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/clk/qcom/dispcc-sdm845.c b/drivers/clk/qcom/dispcc-sdm845.c
> index 78e43f6d7502..468b30497746 100644
> --- a/drivers/clk/qcom/dispcc-sdm845.c
> +++ b/drivers/clk/qcom/dispcc-sdm845.c
> @@ -763,6 +763,7 @@ static struct gdsc mdss_gdsc = {
>  	.en_rest_wait_val = 0x5,
>  	.pd = {
>  		.name = "mdss_gdsc",
> +		.flags = GENPD_FLAG_NO_STAY_ON,
>  	},
>  	.pwrsts = PWRSTS_OFF_ON,
>  	.flags = HW_CTRL | POLL_CFG_GDSCR,
> 
> -- 
> 2.47.3
> 

Re: [PATCH 1/4] clk: qcom: dispcc-sdm845: set GENPD_FLAG_NO_STAY_ON flag for MDSS domain

[Dmitry Baryshkov]

On Wed, Feb 18, 2026 at 08:49:34AM -0600, Bjorn Andersson wrote:
> On Tue, Feb 17, 2026 at 11:20:42PM +0200, Dmitry Baryshkov wrote:
> > Since the commit 13a4b7fb6260 ("pmdomain: core: Leave powered-on genpds
> > on until late_initcall_sync") setting of the display clocks is partially
> > broken. For example, when on SDM845-HDK the bootloader leaves display
> > enabled, later the kernel can't set up DSI clocks, ending up with the
> > broken display, blinking blue.
> 
> This describes how the problem manifest itself. Can you please document
> why clocks are partially broken and how that relate to the GDSC state,
> and why setting GENPD_FLAG_NO_STAY_ON solves this?

Probably the best answer (for the second part of the question): I don't
know (yet).

-- 
With best wishes
Dmitry

Re: [PATCH 1/4] clk: qcom: dispcc-sdm845: set GENPD_FLAG_NO_STAY_ON flag for MDSS domain

[Jagadeesh Kona]

On 2/18/2026 9:28 PM, Dmitry Baryshkov wrote:
> On Wed, Feb 18, 2026 at 08:49:34AM -0600, Bjorn Andersson wrote:
>> On Tue, Feb 17, 2026 at 11:20:42PM +0200, Dmitry Baryshkov wrote:
>>> Since the commit 13a4b7fb6260 ("pmdomain: core: Leave powered-on genpds
>>> on until late_initcall_sync") setting of the display clocks is partially
>>> broken. For example, when on SDM845-HDK the bootloader leaves display
>>> enabled, later the kernel can't set up DSI clocks, ending up with the
>>> broken display, blinking blue.
>>
>> This describes how the problem manifest itself. Can you please document
>> why clocks are partially broken and how that relate to the GDSC state,
>> and why setting GENPD_FLAG_NO_STAY_ON solves this?
> 
> Probably the best answer (for the second part of the question): I don't
> know (yet).
> 

RCG update typically gets stuck if the new/old source is OFF while the RCG is ON; but
if the RCG is already OFF, the update proceeds safely even if new/old source is OFF.

A possible theory is that if the GDSC is in OFF state, the branch clocks will be OFF,
due to this RCG also will be in OFF state, preventing the update stuck issue even if
the new/old source is OFF. But, if the GDSC remains on until sync_state, the branches
and RCG likely stays ON, leading to update stuck issue if the new/old source is OFF.

Ideally, if both old and new RCG sources are ON during the update configuration, the
update should succeed regardless of the GDSC status.

Thanks,
Jagadeesh

Re: [PATCH 1/4] clk: qcom: dispcc-sdm845: set GENPD_FLAG_NO_STAY_ON flag for MDSS domain

[Dmitry Baryshkov]

On Thu, Feb 19, 2026 at 11:41:06PM +0530, Jagadeesh Kona wrote:
> 
> 
> On 2/18/2026 9:28 PM, Dmitry Baryshkov wrote:
> > On Wed, Feb 18, 2026 at 08:49:34AM -0600, Bjorn Andersson wrote:
> >> On Tue, Feb 17, 2026 at 11:20:42PM +0200, Dmitry Baryshkov wrote:
> >>> Since the commit 13a4b7fb6260 ("pmdomain: core: Leave powered-on genpds
> >>> on until late_initcall_sync") setting of the display clocks is partially
> >>> broken. For example, when on SDM845-HDK the bootloader leaves display
> >>> enabled, later the kernel can't set up DSI clocks, ending up with the
> >>> broken display, blinking blue.
> >>
> >> This describes how the problem manifest itself. Can you please document
> >> why clocks are partially broken and how that relate to the GDSC state,
> >> and why setting GENPD_FLAG_NO_STAY_ON solves this?
> > 
> > Probably the best answer (for the second part of the question): I don't
> > know (yet).
> > 
> 
> RCG update typically gets stuck if the new/old source is OFF while the RCG is ON; but
> if the RCG is already OFF, the update proceeds safely even if new/old source is OFF.
> 
> A possible theory is that if the GDSC is in OFF state, the branch clocks will be OFF,
> due to this RCG also will be in OFF state, preventing the update stuck issue even if
> the new/old source is OFF. But, if the GDSC remains on until sync_state, the branches
> and RCG likely stays ON, leading to update stuck issue if the new/old source is OFF.
> 
> Ideally, if both old and new RCG sources are ON during the update configuration, the
> update should succeed regardless of the GDSC status.

Both pclkN_clk_src clocks have CLK_OPS_PARENT_ENABLE set, so the parents
must be on.

-- 
With best wishes
Dmitry

[PATCH 2/4] dt-bindings: arm: qcom: add Qualcomm SDM845 HDK

[Dmitry Baryshkov]

Document the mobile HDK for the Qualcomm SDM845 platform.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index d48c625d3fc4..80491aa994ec 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -921,6 +921,7 @@ properties:
               - lg,judyp
               - oneplus,enchilada
               - oneplus,fajita
+              - qcom,sdm845-hdk
               - qcom,sdm845-mtp
               - shift,axolotl
               - samsung,starqltechn

-- 
2.47.3

Re: [PATCH 2/4] dt-bindings: arm: qcom: add Qualcomm SDM845 HDK

[Krzysztof Kozlowski]

On Tue, Feb 17, 2026 at 11:20:43PM +0200, Dmitry Baryshkov wrote:
> Document the mobile HDK for the Qualcomm SDM845 platform.
> 
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

[PATCH 3/4] arm64: dts: qcom: sdm845: Add missing MDSS reset

[Dmitry Baryshkov]

From: David Heidelberg <david@ixit.cz>

If the OS does not support recovering the state left by the
bootloader it needs a way to reset display hardware, so that it can
start from a clean state. Add a reference to the relevant reset.

Signed-off-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index bf2f9c04adba..75c192eddc57 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -4550,6 +4550,7 @@ mdss: display-subsystem@ae00000 {
 			reg-names = "mdss";
 
 			power-domains = <&dispcc MDSS_GDSC>;
+			resets = <&dispcc DISP_CC_MDSS_RSCC_BCR>;
 
 			clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
 				 <&dispcc DISP_CC_MDSS_MDP_CLK>;

-- 
2.47.3

Re: [PATCH 3/4] arm64: dts: qcom: sdm845: Add missing MDSS reset

[Konrad Dybcio]

On 2/17/26 10:20 PM, Dmitry Baryshkov wrote:
> From: David Heidelberg <david@ixit.cz>
> 
> If the OS does not support recovering the state left by the
> bootloader it needs a way to reset display hardware, so that it can
> start from a clean state. Add a reference to the relevant reset.

This is not the relevant reset

You want MDSS_CORE_BCR @ 0xaf0_2000

Konrad

> 
> Signed-off-by: David Heidelberg <david@ixit.cz>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---


>  arch/arm64/boot/dts/qcom/sdm845.dtsi | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index bf2f9c04adba..75c192eddc57 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -4550,6 +4550,7 @@ mdss: display-subsystem@ae00000 {
>  			reg-names = "mdss";
>  
>  			power-domains = <&dispcc MDSS_GDSC>;
> +			resets = <&dispcc DISP_CC_MDSS_RSCC_BCR>;
>  
>  			clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
>  				 <&dispcc DISP_CC_MDSS_MDP_CLK>;
> 

Re: [PATCH 3/4] arm64: dts: qcom: sdm845: Add missing MDSS reset

[David Heidelberg]

On 18/02/2026 11:30, Konrad Dybcio wrote:
> On 2/17/26 10:20 PM, Dmitry Baryshkov wrote:
>> From: David Heidelberg <david@ixit.cz>
>>
>> If the OS does not support recovering the state left by the
>> bootloader it needs a way to reset display hardware, so that it can
>> start from a clean state. Add a reference to the relevant reset.
> 
> This is not the relevant reset
> 
> You want MDSS_CORE_BCR @ 0xaf0_2000

Thanks, I prepared the fixes [1].

I'll try to test it if it's not breaking anything for us and send as v2 
of [2].

David

[1] https://codeberg.org/sdm845/linux/commits/branch/b4/mdss-reset
[2] 
https://patchwork.kernel.org/project/linux-arm-msm/patch/20260112-mdss-reset-v1-1-af7c572204d3@ixit.cz/

> 
> Konrad
> 
>>
>> Signed-off-by: David Heidelberg <david@ixit.cz>
>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>> ---
> 
> 
>>   arch/arm64/boot/dts/qcom/sdm845.dtsi | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> index bf2f9c04adba..75c192eddc57 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> @@ -4550,6 +4550,7 @@ mdss: display-subsystem@ae00000 {
>>   			reg-names = "mdss";
>>   
>>   			power-domains = <&dispcc MDSS_GDSC>;
>> +			resets = <&dispcc DISP_CC_MDSS_RSCC_BCR>;
>>   
>>   			clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
>>   				 <&dispcc DISP_CC_MDSS_MDP_CLK>;
>>

-- 
David Heidelberg

Re: [PATCH 3/4] arm64: dts: qcom: sdm845: Add missing MDSS reset

[Konrad Dybcio]

On 2/18/26 12:18 PM, David Heidelberg wrote:
> On 18/02/2026 11:30, Konrad Dybcio wrote:
>> On 2/17/26 10:20 PM, Dmitry Baryshkov wrote:
>>> From: David Heidelberg <david@ixit.cz>
>>>
>>> If the OS does not support recovering the state left by the
>>> bootloader it needs a way to reset display hardware, so that it can
>>> start from a clean state. Add a reference to the relevant reset.
>>
>> This is not the relevant reset
>>
>> You want MDSS_CORE_BCR @ 0xaf0_2000
> 
> Thanks, I prepared the fixes [1].
> 
> I'll try to test it if it's not breaking anything for us and send as v2 of [2].
> 
> David
> 
> [1] https://codeberg.org/sdm845/linux/commits/branch/b4/mdss-reset
> [2] https://patchwork.kernel.org/project/linux-arm-msm/patch/20260112-mdss-reset-v1-1-af7c572204d3@ixit.cz/

Please don't alter the contents of dt-bindings, it really doesn't matter
if on sdm845 it's reset0 or reset1, that's why we define them in the first
place 

Konrad

Re: [PATCH 3/4] arm64: dts: qcom: sdm845: Add missing MDSS reset

[David Heidelberg]

On 18/02/2026 12:24, Konrad Dybcio wrote:
> On 2/18/26 12:18 PM, David Heidelberg wrote:
>> On 18/02/2026 11:30, Konrad Dybcio wrote:
>>> On 2/17/26 10:20 PM, Dmitry Baryshkov wrote:
>>>> From: David Heidelberg <david@ixit.cz>
>>>>
>>>> If the OS does not support recovering the state left by the
>>>> bootloader it needs a way to reset display hardware, so that it can
>>>> start from a clean state. Add a reference to the relevant reset.
>>>
>>> This is not the relevant reset
>>>
>>> You want MDSS_CORE_BCR @ 0xaf0_2000
>>
>> Thanks, I prepared the fixes [1].
>>
>> I'll try to test it if it's not breaking anything for us and send as v2 of [2].
>>
>> David
>>
>> [1] https://codeberg.org/sdm845/linux/commits/branch/b4/mdss-reset
>> [2] https://patchwork.kernel.org/project/linux-arm-msm/patch/20260112-mdss-reset-v1-1-af7c572204d3@ixit.cz/
> 
> Please don't alter the contents of dt-bindings, it really doesn't matter
> if on sdm845 it's reset0 or reset1, that's why we define them in the first
> place

Sure, np

> 
> Konrad

-- 
David Heidelberg

Re: [PATCH 3/4] arm64: dts: qcom: sdm845: Add missing MDSS reset

[Dmitry Baryshkov]

On Wed, Feb 18, 2026 at 12:24:26PM +0100, Konrad Dybcio wrote:
> On 2/18/26 12:18 PM, David Heidelberg wrote:
> > On 18/02/2026 11:30, Konrad Dybcio wrote:
> >> On 2/17/26 10:20 PM, Dmitry Baryshkov wrote:
> >>> From: David Heidelberg <david@ixit.cz>
> >>>
> >>> If the OS does not support recovering the state left by the
> >>> bootloader it needs a way to reset display hardware, so that it can
> >>> start from a clean state. Add a reference to the relevant reset.
> >>
> >> This is not the relevant reset
> >>
> >> You want MDSS_CORE_BCR @ 0xaf0_2000
> > 
> > Thanks, I prepared the fixes [1].
> > 
> > I'll try to test it if it's not breaking anything for us and send as v2 of [2].
> > 
> > David
> > 
> > [1] https://codeberg.org/sdm845/linux/commits/branch/b4/mdss-reset
> > [2] https://patchwork.kernel.org/project/linux-arm-msm/patch/20260112-mdss-reset-v1-1-af7c572204d3@ixit.cz/
> 
> Please don't alter the contents of dt-bindings, it really doesn't matter
> if on sdm845 it's reset0 or reset1, that's why we define them in the first
> place 

I dpn't think that will pass. Current reset is defined as RSCC, we can't
change that to CORE behind the scene. I'd prefer David's approach.

> 
> Konrad

-- 
With best wishes
Dmitry

Re: [PATCH 3/4] arm64: dts: qcom: sdm845: Add missing MDSS reset

[Konrad Dybcio]

On 18-Feb-26 12:58, Dmitry Baryshkov wrote:
> On Wed, Feb 18, 2026 at 12:24:26PM +0100, Konrad Dybcio wrote:
>> On 2/18/26 12:18 PM, David Heidelberg wrote:
>>> On 18/02/2026 11:30, Konrad Dybcio wrote:
>>>> On 2/17/26 10:20 PM, Dmitry Baryshkov wrote:
>>>>> From: David Heidelberg <david@ixit.cz>
>>>>>
>>>>> If the OS does not support recovering the state left by the
>>>>> bootloader it needs a way to reset display hardware, so that it can
>>>>> start from a clean state. Add a reference to the relevant reset.
>>>>
>>>> This is not the relevant reset
>>>>
>>>> You want MDSS_CORE_BCR @ 0xaf0_2000
>>>
>>> Thanks, I prepared the fixes [1].
>>>
>>> I'll try to test it if it's not breaking anything for us and send as v2 of [2].
>>>
>>> David
>>>
>>> [1] https://codeberg.org/sdm845/linux/commits/branch/b4/mdss-reset
>>> [2] https://patchwork.kernel.org/project/linux-arm-msm/patch/20260112-mdss-reset-v1-1-af7c572204d3@ixit.cz/
>>
>> Please don't alter the contents of dt-bindings, it really doesn't matter
>> if on sdm845 it's reset0 or reset1, that's why we define them in the first
>> place 
> 
> I dpn't think that will pass. Current reset is defined as RSCC, we can't
> change that to CORE behind the scene. I'd prefer David's approach.

Back when I replied, David had a patch that removed the current RSCC
reset definition in dt-bindings (at index 0) and re-used that index
for CORE, putting RSCC at index 1. Perhaps it's better to link to
specific commits when making comments, note to self :P

Konrad

Re: [PATCH 3/4] arm64: dts: qcom: sdm845: Add missing MDSS reset

[Dmitry Baryshkov]

On Wed, Feb 18, 2026 at 03:28:01PM +0100, Konrad Dybcio wrote:
> 
> 
> On 18-Feb-26 12:58, Dmitry Baryshkov wrote:
> > On Wed, Feb 18, 2026 at 12:24:26PM +0100, Konrad Dybcio wrote:
> >> On 2/18/26 12:18 PM, David Heidelberg wrote:
> >>> On 18/02/2026 11:30, Konrad Dybcio wrote:
> >>>> On 2/17/26 10:20 PM, Dmitry Baryshkov wrote:
> >>>>> From: David Heidelberg <david@ixit.cz>
> >>>>>
> >>>>> If the OS does not support recovering the state left by the
> >>>>> bootloader it needs a way to reset display hardware, so that it can
> >>>>> start from a clean state. Add a reference to the relevant reset.
> >>>>
> >>>> This is not the relevant reset
> >>>>
> >>>> You want MDSS_CORE_BCR @ 0xaf0_2000
> >>>
> >>> Thanks, I prepared the fixes [1].
> >>>
> >>> I'll try to test it if it's not breaking anything for us and send as v2 of [2].
> >>>
> >>> David
> >>>
> >>> [1] https://codeberg.org/sdm845/linux/commits/branch/b4/mdss-reset
> >>> [2] https://patchwork.kernel.org/project/linux-arm-msm/patch/20260112-mdss-reset-v1-1-af7c572204d3@ixit.cz/
> >>
> >> Please don't alter the contents of dt-bindings, it really doesn't matter
> >> if on sdm845 it's reset0 or reset1, that's why we define them in the first
> >> place 
> > 
> > I dpn't think that will pass. Current reset is defined as RSCC, we can't
> > change that to CORE behind the scene. I'd prefer David's approach.
> 
> Back when I replied, David had a patch that removed the current RSCC
> reset definition in dt-bindings (at index 0) and re-used that index
> for CORE, putting RSCC at index 1. Perhaps it's better to link to
> specific commits when making comments, note to self :P

Yes, I saw the commit having two resets. Anyway, as we saw, it doesn't
work.

-- 
With best wishes
Dmitry

Re: [PATCH 3/4] arm64: dts: qcom: sdm845: Add missing MDSS reset

[David Heidelberg]

On 18/02/2026 16:59, Dmitry Baryshkov wrote:
> On Wed, Feb 18, 2026 at 03:28:01PM +0100, Konrad Dybcio wrote:
>>
>>
>> On 18-Feb-26 12:58, Dmitry Baryshkov wrote:
>>> On Wed, Feb 18, 2026 at 12:24:26PM +0100, Konrad Dybcio wrote:
>>>> On 2/18/26 12:18 PM, David Heidelberg wrote:
>>>>> On 18/02/2026 11:30, Konrad Dybcio wrote:
>>>>>> On 2/17/26 10:20 PM, Dmitry Baryshkov wrote:
>>>>>>> From: David Heidelberg <david@ixit.cz>
>>>>>>>
>>>>>>> If the OS does not support recovering the state left by the
>>>>>>> bootloader it needs a way to reset display hardware, so that it can
>>>>>>> start from a clean state. Add a reference to the relevant reset.
>>>>>>
>>>>>> This is not the relevant reset
>>>>>>
>>>>>> You want MDSS_CORE_BCR @ 0xaf0_2000
>>>>>
>>>>> Thanks, I prepared the fixes [1].
>>>>>
>>>>> I'll try to test it if it's not breaking anything for us and send as v2 of [2].
>>>>>
>>>>> David
>>>>>
>>>>> [1] https://codeberg.org/sdm845/linux/commits/branch/b4/mdss-reset
>>>>> [2] https://patchwork.kernel.org/project/linux-arm-msm/patch/20260112-mdss-reset-v1-1-af7c572204d3@ixit.cz/
>>>>
>>>> Please don't alter the contents of dt-bindings, it really doesn't matter
>>>> if on sdm845 it's reset0 or reset1, that's why we define them in the first
>>>> place
>>>
>>> I dpn't think that will pass. Current reset is defined as RSCC, we can't
>>> change that to CORE behind the scene. I'd prefer David's approach.
>>
>> Back when I replied, David had a patch that removed the current RSCC
>> reset definition in dt-bindings (at index 0) and re-used that index
>> for CORE, putting RSCC at index 1. Perhaps it's better to link to
>> specific commits when making comments, note to self :P
> 
> Yes, I saw the commit having two resets. Anyway, as we saw, it doesn't
> work.

So, finally I spent "so much effort" (read throwing it at LLM) looking at:

arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0x9d4bb500, 
fsynr=0x170021, cbfrsynra=0xc88, cb=11
arm-smmu 15000000.iommu: FSR    = 00000402 [Format=2 TF], SID=0xc88
arm-smmu 15000000.iommu: FSYNR0 = 00170021 [S1CBNDX=23 PNU PLVL=1]
arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0x9d4c6900, 
fsynr=0x170021, cbfrsynra=0x880, cb=11
arm-smmu 15000000.iommu: FSR    = 00000402 [Format=2 TF], SID=0x880
arm-smmu 15000000.iommu: FSYNR0 = 00170021 [S1CBNDX=23 PNU PLVL=1]
arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0x9d4c3f00, 
fsynr=0x170021, cbfrsynra=0xc88, cb=11
arm-smmu 15000000.iommu: FSR    = 00000402 [Format=2 TF], SID=0xc88
arm-smmu 15000000.iommu: FSYNR0 = 00170021 [S1CBNDX=23 PNU PLVL=1]
arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0x9d4cff00, 
fsynr=0x170021, cbfrsynra=0xc88, cb=11
arm-smmu 15000000.iommu: FSR    = 00000402 [Format=2 TF], SID=0xc88
arm-smmu 15000000.iommu: FSYNR0 = 00170021 [S1CBNDX=23 PNU PLVL=1]
arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0x9d4cd220, 
fsynr=0x170021, cbfrsynra=0x880, cb=11
arm-smmu 15000000.iommu: FSR    = 00000402 [Format=2 TF], SID=0x880
arm-smmu 15000000.iommu: FSYNR0 = 00170021 [S1CBNDX=23 PNU PLVL=1]
arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0x9d4d9a00, 
fsynr=0x170021, cbfrsynra=0x880, cb=11
arm-smmu 15000000.iommu: FSR    = 00000402 [Format=2 TF], SID=0x880
arm-smmu 15000000.iommu: FSYNR0 = 00170021 [S1CBNDX=23 PNU PLVL=1]
arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0x9d4deb00, 
fsynr=0x170021, cbfrsynra=0x880, cb=11
arm-smmu 15000000.iommu: FSR    = 00000402 [Format=2 TF], SID=0x880
arm-smmu 15000000.iommu: FSYNR0 = 00170021 [S1CBNDX=23 PNU PLVL=1]
arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0x9d4e3400, 
fsynr=0x170021, cbfrsynra=0xc88, cb=11
arm-smmu 15000000.iommu: FSR    = 00000402 [Format=2 TF], SID=0xc88
arm-smmu 15000000.iommu: FSYNR0 = 00170021 [S1CBNDX=23 PNU PLVL=1]
arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0x9d4e9500, 
fsynr=0x170021, cbfrsynra=0xc88, cb=11
arm-smmu 15000000.iommu: FSR    = 00000402 [Format=2 TF], SID=0xc88
arm-smmu 15000000.iommu: FSYNR0 = 00170021 [S1CBNDX=23 PNU PLVL=1]
arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0x9d4eca00, 
fsynr=0x170021, cbfrsynra=0x880, cb=11
arm-smmu 15000000.iommu: FSR    = 00000402 [Format=2 TF], SID=0x880
arm-smmu 15000000.iommu: FSYNR0 = 00170021 [S1CBNDX=23 PNU PLVL=1]

These (or very similar warnings) are around sdm845 definitely 6.19+ / linux-next 
kernels for some time, but pretty harmless.

LLM suggested multiple fixes, but when presenting possibility of implementing 
mdss reset it found it as most preferable [1].

Adding MDSS reset would most likely solve it. It's not critical, but not nice to 
see many red lines in the dmesg.

Is there something I could experiment with to get closer to have proper MDSS reset?

David

[1] https://paste.sr.ht/~okias/c20e8bb1a67ba09df558d56da84894d71ddc1b54

Re: [PATCH 3/4] arm64: dts: qcom: sdm845: Add missing MDSS reset

[Dmitry Baryshkov]

On Thu, Apr 09, 2026 at 10:38:15PM +0200, David Heidelberg wrote:
> On 18/02/2026 16:59, Dmitry Baryshkov wrote:
> > On Wed, Feb 18, 2026 at 03:28:01PM +0100, Konrad Dybcio wrote:
> > > 
> > > 
> > > On 18-Feb-26 12:58, Dmitry Baryshkov wrote:
> > > > On Wed, Feb 18, 2026 at 12:24:26PM +0100, Konrad Dybcio wrote:
> > > > > On 2/18/26 12:18 PM, David Heidelberg wrote:
> > > > > > On 18/02/2026 11:30, Konrad Dybcio wrote:
> > > > > > > On 2/17/26 10:20 PM, Dmitry Baryshkov wrote:
> > > > > > > > From: David Heidelberg <david@ixit.cz>
> > > > > > > > 
> > > > > > > > If the OS does not support recovering the state left by the
> > > > > > > > bootloader it needs a way to reset display hardware, so that it can
> > > > > > > > start from a clean state. Add a reference to the relevant reset.
> > > > > > > 
> > > > > > > This is not the relevant reset
> > > > > > > 
> > > > > > > You want MDSS_CORE_BCR @ 0xaf0_2000
> > > > > > 
> > > > > > Thanks, I prepared the fixes [1].
> > > > > > 
> > > > > > I'll try to test it if it's not breaking anything for us and send as v2 of [2].
> > > > > > 
> > > > > > David
> > > > > > 
> > > > > > [1] https://codeberg.org/sdm845/linux/commits/branch/b4/mdss-reset
> > > > > > [2] https://patchwork.kernel.org/project/linux-arm-msm/patch/20260112-mdss-reset-v1-1-af7c572204d3@ixit.cz/
> > > > > 
> > > > > Please don't alter the contents of dt-bindings, it really doesn't matter
> > > > > if on sdm845 it's reset0 or reset1, that's why we define them in the first
> > > > > place
> > > > 
> > > > I dpn't think that will pass. Current reset is defined as RSCC, we can't
> > > > change that to CORE behind the scene. I'd prefer David's approach.
> > > 
> > > Back when I replied, David had a patch that removed the current RSCC
> > > reset definition in dt-bindings (at index 0) and re-used that index
> > > for CORE, putting RSCC at index 1. Perhaps it's better to link to
> > > specific commits when making comments, note to self :P
> > 
> > Yes, I saw the commit having two resets. Anyway, as we saw, it doesn't
> > work.
> 
> So, finally I spent "so much effort" (read throwing it at LLM) looking at:
> 
> arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402,
> iova=0x9d4bb500, fsynr=0x170021, cbfrsynra=0xc88, cb=11
> arm-smmu 15000000.iommu: FSR    = 00000402 [Format=2 TF], SID=0xc88
> arm-smmu 15000000.iommu: FSYNR0 = 00170021 [S1CBNDX=23 PNU PLVL=1]

[...]

> 
> These (or very similar warnings) are around sdm845 definitely 6.19+ /
> linux-next kernels for some time, but pretty harmless.
> 
> LLM suggested multiple fixes, but when presenting possibility of
> implementing mdss reset it found it as most preferable [1].
> 
> Adding MDSS reset would most likely solve it. It's not critical, but not
> nice to see many red lines in the dmesg.
> 
> Is there something I could experiment with to get closer to have proper MDSS reset?

I don't have a sensible solution at this point. We tried using the MDSS
reset on several SDM845 devices, but they just reset. So... I don't have
any possible solution.

> 
> David
> 
> [1] https://paste.sr.ht/~okias/c20e8bb1a67ba09df558d56da84894d71ddc1b54

-- 
With best wishes
Dmitry

Re: [PATCH 3/4] arm64: dts: qcom: sdm845: Add missing MDSS reset

[Konrad Dybcio]

On 4/9/26 11:24 PM, Dmitry Baryshkov wrote:
> On Thu, Apr 09, 2026 at 10:38:15PM +0200, David Heidelberg wrote:
>> On 18/02/2026 16:59, Dmitry Baryshkov wrote:
>>> On Wed, Feb 18, 2026 at 03:28:01PM +0100, Konrad Dybcio wrote:
>>>>
>>>>
>>>> On 18-Feb-26 12:58, Dmitry Baryshkov wrote:
>>>>> On Wed, Feb 18, 2026 at 12:24:26PM +0100, Konrad Dybcio wrote:
>>>>>> On 2/18/26 12:18 PM, David Heidelberg wrote:
>>>>>>> On 18/02/2026 11:30, Konrad Dybcio wrote:
>>>>>>>> On 2/17/26 10:20 PM, Dmitry Baryshkov wrote:
>>>>>>>>> From: David Heidelberg <david@ixit.cz>
>>>>>>>>>
>>>>>>>>> If the OS does not support recovering the state left by the
>>>>>>>>> bootloader it needs a way to reset display hardware, so that it can
>>>>>>>>> start from a clean state. Add a reference to the relevant reset.
>>>>>>>>
>>>>>>>> This is not the relevant reset
>>>>>>>>
>>>>>>>> You want MDSS_CORE_BCR @ 0xaf0_2000
>>>>>>>
>>>>>>> Thanks, I prepared the fixes [1].
>>>>>>>
>>>>>>> I'll try to test it if it's not breaking anything for us and send as v2 of [2].
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>> [1] https://codeberg.org/sdm845/linux/commits/branch/b4/mdss-reset
>>>>>>> [2] https://patchwork.kernel.org/project/linux-arm-msm/patch/20260112-mdss-reset-v1-1-af7c572204d3@ixit.cz/
>>>>>>
>>>>>> Please don't alter the contents of dt-bindings, it really doesn't matter
>>>>>> if on sdm845 it's reset0 or reset1, that's why we define them in the first
>>>>>> place
>>>>>
>>>>> I dpn't think that will pass. Current reset is defined as RSCC, we can't
>>>>> change that to CORE behind the scene. I'd prefer David's approach.
>>>>
>>>> Back when I replied, David had a patch that removed the current RSCC
>>>> reset definition in dt-bindings (at index 0) and re-used that index
>>>> for CORE, putting RSCC at index 1. Perhaps it's better to link to
>>>> specific commits when making comments, note to self :P
>>>
>>> Yes, I saw the commit having two resets. Anyway, as we saw, it doesn't
>>> work.
>>
>> So, finally I spent "so much effort" (read throwing it at LLM) looking at:
>>
>> arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402,
>> iova=0x9d4bb500, fsynr=0x170021, cbfrsynra=0xc88, cb=11
>> arm-smmu 15000000.iommu: FSR    = 00000402 [Format=2 TF], SID=0xc88
>> arm-smmu 15000000.iommu: FSYNR0 = 00170021 [S1CBNDX=23 PNU PLVL=1]
> 
> [...]
> 
>>
>> These (or very similar warnings) are around sdm845 definitely 6.19+ /
>> linux-next kernels for some time, but pretty harmless.
>>
>> LLM suggested multiple fixes, but when presenting possibility of
>> implementing mdss reset it found it as most preferable [1].
>>
>> Adding MDSS reset would most likely solve it. It's not critical, but not
>> nice to see many red lines in the dmesg.
>>
>> Is there something I could experiment with to get closer to have proper MDSS reset?
> 
> I don't have a sensible solution at this point. We tried using the MDSS
> reset on several SDM845 devices, but they just reset. So... I don't have
> any possible solution.

The older context talks about altering the existing dt-bindings values
and now we're at hardware (mis)behaving? What is the issue here?

Konrad

Re: [PATCH 3/4] arm64: dts: qcom: sdm845: Add missing MDSS reset

[Dmitry Baryshkov]

On Wed, Feb 18, 2026 at 12:18:39PM +0100, David Heidelberg wrote:
> On 18/02/2026 11:30, Konrad Dybcio wrote:
> > On 2/17/26 10:20 PM, Dmitry Baryshkov wrote:
> > > From: David Heidelberg <david@ixit.cz>
> > > 
> > > If the OS does not support recovering the state left by the
> > > bootloader it needs a way to reset display hardware, so that it can
> > > start from a clean state. Add a reference to the relevant reset.
> > 
> > This is not the relevant reset
> > 
> > You want MDSS_CORE_BCR @ 0xaf0_2000
> 
> Thanks, I prepared the fixes [1].

UPD: touching that register resets the device. So, it seems, we will
have to live without the MDSS Core reset of SDM845.

> 
> I'll try to test it if it's not breaking anything for us and send as v2 of
> [2].
> 
> David
> 
> [1] https://codeberg.org/sdm845/linux/commits/branch/b4/mdss-reset
> [2] https://patchwork.kernel.org/project/linux-arm-msm/patch/20260112-mdss-reset-v1-1-af7c572204d3@ixit.cz/
> 
> > 
> > Konrad
> > 
> > > 
> > > Signed-off-by: David Heidelberg <david@ixit.cz>
> > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > > ---
> > 
> > 
> > >   arch/arm64/boot/dts/qcom/sdm845.dtsi | 1 +
> > >   1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > index bf2f9c04adba..75c192eddc57 100644
> > > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > @@ -4550,6 +4550,7 @@ mdss: display-subsystem@ae00000 {
> > >   			reg-names = "mdss";
> > >   			power-domains = <&dispcc MDSS_GDSC>;
> > > +			resets = <&dispcc DISP_CC_MDSS_RSCC_BCR>;
> > >   			clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
> > >   				 <&dispcc DISP_CC_MDSS_MDP_CLK>;
> > > 
> 
> -- 
> David Heidelberg
> 

-- 
With best wishes
Dmitry

Re: [PATCH 3/4] arm64: dts: qcom: sdm845: Add missing MDSS reset

[David Heidelberg]

On 18/02/2026 13:19, Dmitry Baryshkov wrote:
> On Wed, Feb 18, 2026 at 12:18:39PM +0100, David Heidelberg wrote:
>> On 18/02/2026 11:30, Konrad Dybcio wrote:
>>> On 2/17/26 10:20 PM, Dmitry Baryshkov wrote:
>>>> From: David Heidelberg <david@ixit.cz>
>>>>
>>>> If the OS does not support recovering the state left by the
>>>> bootloader it needs a way to reset display hardware, so that it can
>>>> start from a clean state. Add a reference to the relevant reset.
>>>
>>> This is not the relevant reset
>>>
>>> You want MDSS_CORE_BCR @ 0xaf0_2000
>>
>> Thanks, I prepared the fixes [1].
> 
> UPD: touching that register resets the device. So, it seems, we will
> have to live without the MDSS Core reset of SDM845.

For me, so far, one test on Pixel 3 it freezes the device. Haven't found 
UART dongle, so not sure where exactly.

David

> 
>>
>> I'll try to test it if it's not breaking anything for us and send as v2 of
>> [2].
>>
>> David
>>
>> [1] https://codeberg.org/sdm845/linux/commits/branch/b4/mdss-reset
>> [2] https://patchwork.kernel.org/project/linux-arm-msm/patch/20260112-mdss-reset-v1-1-af7c572204d3@ixit.cz/
>>
>>>
>>> Konrad
>>>
>>>>
>>>> Signed-off-by: David Heidelberg <david@ixit.cz>
>>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>>> ---
>>>
>>>
>>>>    arch/arm64/boot/dts/qcom/sdm845.dtsi | 1 +
>>>>    1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>>> index bf2f9c04adba..75c192eddc57 100644
>>>> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>>> @@ -4550,6 +4550,7 @@ mdss: display-subsystem@ae00000 {
>>>>    			reg-names = "mdss";
>>>>    			power-domains = <&dispcc MDSS_GDSC>;
>>>> +			resets = <&dispcc DISP_CC_MDSS_RSCC_BCR>;
>>>>    			clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
>>>>    				 <&dispcc DISP_CC_MDSS_MDP_CLK>;
>>>>
>>
>> -- 
>> David Heidelberg
>>
> 

-- 
David Heidelberg

[PATCH 4/4] arm64: dts: qcom: add device tree for SDM845-HDK

[Dmitry Baryshkov]

Add device tree for the Qualcomm / Lantronix SDM845 HDK. It is the
development platform using the modem-less (SDA845) SoC, optional onboard
DSI panel and a rich set of connectors.

Working:
- HDMI display
- uSD, UFS, USB
- DSPs, WiFi, BT
- Buttons, LEDs

Not working or not tested:
- DisplayPort - TCPM not supported for this PMIC
- WiGig - requires power sequencing driver, doesn't work with the
  current in-kernel driver
- Audio
- FingerPrint
- USIM

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/Makefile       |   1 +
 arch/arm64/boot/dts/qcom/sdm845-hdk.dts | 820 ++++++++++++++++++++++++++++++++
 2 files changed, 821 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index f80b5d9cf1e8..dc901a0fa8b3 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -272,6 +272,7 @@ sdm845-db845c-navigation-mezzanine-dtbs	:= sdm845-db845c.dtb sdm845-db845c-navig
 dtb-$(CONFIG_ARCH_QCOM)	+= sdm845-db845c-navigation-mezzanine.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sdm845-google-crosshatch.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sdm845-google-blueline.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= sdm845-hdk.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sdm845-lg-judyln.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sdm845-lg-judyp.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sdm845-mtp.dtb
diff --git a/arch/arm64/boot/dts/qcom/sdm845-hdk.dts b/arch/arm64/boot/dts/qcom/sdm845-hdk.dts
new file mode 100644
index 000000000000..4dd426912d20
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm845-hdk.dts
@@ -0,0 +1,820 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+#include "sdm845.dtsi"
+#include "pm8005.dtsi"
+#include "pm8998.dtsi"
+#include "pmi8998.dtsi"
+
+/ {
+	model = "Qualcomm Technologies, Inc. SDM845 HDK";
+	compatible = "qcom,sdm845-hdk", "qcom,sdm845";
+	chassis-type = "embedded";
+
+	aliases {
+		serial0 = &uart9;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		autorepeat;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&home_pin_a>, <&vol_up_pin_a>;
+
+		key-home {
+			label = "Home";
+			linux,code = <KEY_HOMEPAGE>;
+			gpios = <&pm8998_gpios 5 GPIO_ACTIVE_LOW>;
+		};
+
+		key-vol-up {
+			label = "Volume Up";
+			linux,code = <KEY_VOLUMEUP>;
+			gpios = <&pm8998_gpios 6 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	hdmi-out {
+		compatible = "hdmi-connector";
+		type = "a";
+
+		port {
+			hdmi_con: endpoint {
+				remote-endpoint = <&lt9611_out>;
+			};
+		};
+	};
+
+	/*
+	 * Apparently RPMh does not provide support for PM8998 S4 and S6
+	 * because they are always-on; model them as fixed regulators.
+	 */
+	vreg_s4a_1p8: regulator-pm8998-smps4 {
+		compatible = "regulator-fixed";
+		regulator-name = "vreg_s4a_1p8";
+
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+
+		regulator-always-on;
+		regulator-boot-on;
+
+		vin-supply = <&vph_pwr>;
+	};
+
+	vreg_s6a_0p8: regulator-pm8998-smps6 {
+		compatible = "regulator-fixed";
+		regulator-name = "vreg_s6a_0p8";
+
+		regulator-min-microvolt = <800000>;
+		regulator-max-microvolt = <800000>;
+
+		regulator-always-on;
+		regulator-boot-on;
+
+		vin-supply = <&vph_pwr>;
+	};
+
+	vreg_sys_bob_3p3: regulator-sys-bob {
+		compatible = "regulator-fixed";
+		regulator-name = "sys_bob";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+
+		regulator-always-on;
+		regulator-boot-on;
+
+		vin-supply = <&vreg_s4a_1p8>;
+	};
+
+	vph_pwr: regulator-vph-pwr {
+		compatible = "regulator-fixed";
+		regulator-name = "vph_pwr";
+		regulator-min-microvolt = <3700000>;
+		regulator-max-microvolt = <3700000>;
+	};
+};
+
+&adsp_pas {
+	firmware-name = "qcom/sdm845/adsp.mbn";
+
+	status = "okay";
+};
+
+&apps_rsc {
+	regulators-0 {
+		compatible = "qcom,pm8998-rpmh-regulators";
+		qcom,pmic-id = "a";
+
+		vdd-s1-supply = <&vph_pwr>;
+		vdd-s2-supply = <&vph_pwr>;
+		vdd-s3-supply = <&vph_pwr>;
+		vdd-s4-supply = <&vph_pwr>;
+		vdd-s5-supply = <&vph_pwr>;
+		vdd-s6-supply = <&vph_pwr>;
+		vdd-s7-supply = <&vph_pwr>;
+		vdd-s8-supply = <&vph_pwr>;
+		vdd-s9-supply = <&vph_pwr>;
+		vdd-s10-supply = <&vph_pwr>;
+		vdd-s11-supply = <&vph_pwr>;
+		vdd-s12-supply = <&vph_pwr>;
+		vdd-s13-supply = <&vph_pwr>;
+		vdd-l1-l27-supply = <&vreg_s7a_1p025>;
+		vdd-l2-l8-l17-supply = <&vreg_s3a_1p35>;
+		vdd-l3-l11-supply = <&vreg_s7a_1p025>;
+		vdd-l4-l5-supply = <&vreg_s7a_1p025>;
+		vdd-l6-supply = <&vph_pwr>;
+		vdd-l7-l12-l14-l15-supply = <&vreg_s5a_2p04>;
+		vdd-l9-supply = <&vreg_bob>;
+		vdd-l10-l23-l25-supply = <&vreg_bob>;
+		vdd-l13-l19-l21-supply = <&vreg_bob>;
+		vdd-l16-l28-supply = <&vreg_bob>;
+		vdd-l18-l22-supply = <&vreg_bob>;
+		vdd-l20-l24-supply = <&vreg_bob>;
+		vdd-l26-supply = <&vreg_s3a_1p35>;
+		vin-lvs-1-2-supply = <&vreg_s4a_1p8>;
+
+		vreg_s2a_1p125: smps2 {
+			regulator-min-microvolt = <1100000>;
+			regulator-max-microvolt = <1100000>;
+		};
+
+		vreg_s3a_1p35: smps3 {
+			regulator-min-microvolt = <1352000>;
+			regulator-max-microvolt = <1352000>;
+		};
+
+		vreg_s5a_2p04: smps5 {
+			regulator-min-microvolt = <1904000>;
+			regulator-max-microvolt = <2040000>;
+		};
+
+		vreg_s7a_1p025: smps7 {
+			regulator-min-microvolt = <900000>;
+			regulator-max-microvolt = <1028000>;
+		};
+
+		vreg_l1a_0p88: ldo1 {
+			regulator-min-microvolt = <880000>;
+			regulator-max-microvolt = <880000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l2a_1p2: ldo2 {
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-always-on;
+		};
+
+		vreg_l3a_1p0: ldo3 {
+			regulator-min-microvolt = <1000000>;
+			regulator-max-microvolt = <1000000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l5a_0p8: ldo5 {
+			regulator-min-microvolt = <800000>;
+			regulator-max-microvolt = <800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l6a_1p85: ldo6 {
+			regulator-min-microvolt = <1856000>;
+			regulator-max-microvolt = <1856000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l7a_1p8: ldo7 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l8a_1p2: ldo8 {
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1248000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l9a_1p8: ldo9 {
+			regulator-min-microvolt = <1704000>;
+			regulator-max-microvolt = <2928000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l10a_1p8: ldo10 {
+			regulator-min-microvolt = <1704000>;
+			regulator-max-microvolt = <2928000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l11a_1p0: ldo11 {
+			regulator-min-microvolt = <1000000>;
+			regulator-max-microvolt = <1048000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l12a_1p8: ldo12 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l13a_2p95: ldo13 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <2960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l14a_1p8: ldo14 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l15a_1p8: ldo15 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l16a_2p7: ldo16 {
+			regulator-min-microvolt = <2704000>;
+			regulator-max-microvolt = <2704000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l17a_1p3: ldo17 {
+			regulator-min-microvolt = <1304000>;
+			regulator-max-microvolt = <1304000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l18a_2p7: ldo18 {
+			regulator-min-microvolt = <2704000>;
+			regulator-max-microvolt = <2960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l19a_3p0: ldo19 {
+			regulator-min-microvolt = <2856000>;
+			regulator-max-microvolt = <3104000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l20a_2p95: ldo20 {
+			regulator-min-microvolt = <2704000>;
+			regulator-max-microvolt = <2960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l21a_2p95: ldo21 {
+			regulator-min-microvolt = <2704000>;
+			regulator-max-microvolt = <2960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l22a_2p85: ldo22 {
+			regulator-min-microvolt = <2864000>;
+			regulator-max-microvolt = <3312000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l23a_3p3: ldo23 {
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3312000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l24a_3p075: ldo24 {
+			regulator-min-microvolt = <3088000>;
+			regulator-max-microvolt = <3088000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l25a_3p3: ldo25 {
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3312000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l26a_1p2: ldo26 {
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l28a_3p0: ldo28 {
+			regulator-min-microvolt = <2856000>;
+			regulator-max-microvolt = <3008000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_lvs1a_1p8: lvs1 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+		};
+
+		vreg_lvs2a_1p8: lvs2 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+		};
+	};
+
+	regulators-1 {
+		compatible = "qcom,pmi8998-rpmh-regulators";
+		qcom,pmic-id = "b";
+
+		vdd-bob-supply = <&vph_pwr>;
+
+		vreg_bob: bob {
+			regulator-min-microvolt = <3312000>;
+			regulator-max-microvolt = <3600000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_AUTO>;
+			regulator-allow-bypass;
+		};
+	};
+
+	regulators-2 {
+		compatible = "qcom,pm8005-rpmh-regulators";
+		qcom,pmic-id = "c";
+
+		vdd-s1-supply = <&vph_pwr>;
+		vdd-s2-supply = <&vph_pwr>;
+		vdd-s3-supply = <&vph_pwr>;
+		vdd-s4-supply = <&vph_pwr>;
+
+		vreg_s3c_0p6: smps3 {
+			regulator-min-microvolt = <600000>;
+			regulator-max-microvolt = <600000>;
+		};
+	};
+};
+
+&cluster_sleep_0 {
+	/* default, 0x4100c244, kills the board */
+	arm,psci-suspend-param = <0x41008244>;
+};
+
+&cdsp_pas {
+	firmware-name = "qcom/sdm845/cdsp.mbn";
+
+	status = "okay";
+};
+
+&gcc {
+	protected-clocks = <GCC_QSPI_CORE_CLK>,
+			   <GCC_QSPI_CORE_CLK_SRC>,
+			   <GCC_QSPI_CNOC_PERIPH_AHB_CLK>,
+			   <GCC_LPASS_Q6_AXI_CLK>,
+			   <GCC_LPASS_SWAY_CLK>;
+};
+
+&gpi_dma0 {
+	status = "okay";
+};
+
+&gpi_dma1 {
+	status = "okay";
+};
+
+&gpu {
+	status = "okay";
+};
+
+&gpu_zap_shader {
+	firmware-name = "qcom/sdm845/a630_zap.mbn";
+};
+
+&i2c3 {
+	clock-frequency = <400000>;
+
+	status = "okay";
+
+	lt9611_codec: hdmi-bridge@3b {
+		compatible = "lontium,lt9611";
+		reg = <0x3b>;
+		#sound-dai-cells = <1>;
+
+		interrupts-extended = <&tlmm 113 IRQ_TYPE_EDGE_FALLING>;
+
+		reset-gpios = <&tlmm 76 GPIO_ACTIVE_HIGH>;
+
+		vdd-supply = <&vreg_s4a_1p8>;
+		vcc-supply = <&vreg_sys_bob_3p3>;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&lt9611_irq_pin>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+
+				lt9611_a: endpoint {
+					remote-endpoint = <&mdss_dsi0_out>;
+				};
+			};
+
+			port@1 {
+				reg = <1>;
+
+				lt9611_b: endpoint {
+					remote-endpoint = <&mdss_dsi1_out>;
+				};
+			};
+
+			port@2 {
+				reg = <2>;
+
+				lt9611_out: endpoint {
+					remote-endpoint = <&hdmi_con>;
+				};
+			};
+		};
+	};
+};
+
+&mdss {
+	status = "okay";
+};
+
+&mdss_dsi0 {
+	status = "okay";
+	vdda-supply = <&vreg_l26a_1p2>;
+
+	qcom,dual-dsi-mode;
+	qcom,master-dsi;
+};
+
+&mdss_dsi0_out {
+	remote-endpoint = <&lt9611_a>;
+	data-lanes = <0 1 2 3>;
+};
+
+&mdss_dsi0_phy {
+	status = "okay";
+	vdds-supply = <&vreg_s6a_0p8>;
+};
+
+&mdss_dsi1 {
+	vdda-supply = <&vreg_l26a_1p2>;
+
+	qcom,dual-dsi-mode;
+
+	/* DSI1 is slave, so use DSI0 clocks */
+	assigned-clock-parents = <&mdss_dsi0_phy DSI_BYTE_PLL_CLK>,
+				 <&mdss_dsi0_phy DSI_PIXEL_PLL_CLK>;
+
+	status = "okay";
+};
+
+&mdss_dsi1_out {
+	remote-endpoint = <&lt9611_b>;
+	data-lanes = <0 1 2 3>;
+};
+
+&mdss_dsi1_phy {
+	vdds-supply = <&vreg_s6a_0p8>;
+	status = "okay";
+};
+
+&mss_pil {
+	firmware-name = "qcom/sdm845/mba.mbn", "qcom/sdm845/modem.mbn";
+
+	status = "okay";
+};
+
+&pcie0 {
+	perst-gpios = <&tlmm 35 GPIO_ACTIVE_LOW>;
+
+	pinctrl-0 = <&pcie0_default_state>;
+	pinctrl-names = "default";
+
+	status = "okay";
+};
+
+&pcie0_phy {
+	vdda-phy-supply = <&vreg_l1a_0p88>;
+	vdda-pll-supply = <&vreg_l26a_1p2>;
+
+	status = "okay";
+};
+
+&pcie1 {
+	perst-gpios = <&tlmm 102 GPIO_ACTIVE_LOW>;
+
+	pinctrl-names = "default";
+	pinctrl-0 = <&pcie1_default_state>;
+
+	status = "okay";
+};
+
+&pcie1_phy {
+	status = "okay";
+
+	vdda-phy-supply = <&vreg_l1a_0p88>;
+	vdda-pll-supply = <&vreg_l26a_1p2>;
+};
+
+&pm8998_gpios {
+	home_pin_a: home-active-state {
+		pins = "gpio6";
+		function = "normal";
+		input-enable;
+		bias-pull-up;
+		qcom,drive-strength = <PMIC_GPIO_STRENGTH_NO>;
+	};
+
+	vol_up_pin_a: vol-up-active-state {
+		pins = "gpio6";
+		function = "normal";
+		input-enable;
+		bias-pull-up;
+		qcom,drive-strength = <PMIC_GPIO_STRENGTH_NO>;
+	};
+};
+
+&pm8998_resin {
+	linux,code = <KEY_VOLUMEDOWN>;
+
+	status = "okay";
+};
+
+&pmi8998_lpg {
+	status = "okay";
+
+	qcom,power-source = <1>;
+
+	led@3 {
+		reg = <3>;
+		color = <LED_COLOR_ID_BLUE>;
+		function = LED_FUNCTION_BLUETOOTH;
+		linux,default-trigger = "bluetooth-power";
+	};
+
+	led@4 {
+		reg = <4>;
+		color = <LED_COLOR_ID_GREEN>;
+		function = LED_FUNCTION_HEARTBEAT;
+		linux,default-trigger = "heartbeat";
+		function-enumerator = <2>;
+	};
+
+	led@5 {
+		reg = <5>;
+		color = <LED_COLOR_ID_RED>;
+		function = LED_FUNCTION_INDICATOR;
+		function-enumerator = <1>;
+	};
+};
+
+&pmi8998_wled {
+	status = "disabled";
+};
+
+&qupv3_id_0 {
+	status = "okay";
+};
+
+&qupv3_id_1 {
+	status = "okay";
+};
+
+&sdhc_2 {
+	status = "okay";
+
+	pinctrl-0 = <&sdc2_default_state &sdc2_card_det_n>;
+	pinctrl-names = "default";
+
+	vmmc-supply = <&vreg_l21a_2p95>;
+	vqmmc-supply = <&vreg_l13a_2p95>;
+
+	bus-width = <4>;
+	cd-gpios = <&tlmm 126 GPIO_ACTIVE_LOW>;
+};
+
+&slpi_pas {
+	firmware-name = "qcom/sdm845/Qualcomm/SDM845-HDK/slpi.mbn";
+
+	status = "okay";
+};
+
+&tlmm {
+	gpio-reserved-ranges = <0 4>, /* SPI (eSE - embedded Secure Element) */
+			       <81 4>; /* SPI (fingerprint reader) */
+
+	lt9611_irq_pin: lt9611-irq-state {
+		pins = "gpio113";
+		function = "gpio";
+		bias-disable;
+	};
+
+	pcie0_default_state: pcie0-default-state {
+		clkreq-pins {
+			pins = "gpio36";
+			function = "pci_e0";
+			bias-pull-up;
+		};
+
+		perst-n-pins {
+			pins = "gpio35";
+			function = "gpio";
+			drive-strength = <2>;
+			bias-pull-down;
+		};
+
+		wake-n-pins {
+			pins = "gpio37";
+			function = "gpio";
+			drive-strength = <2>;
+			bias-pull-up;
+		};
+	};
+
+	pcie1_default_state: pcie1-default-state {
+		clkreq-pins {
+			pins = "gpio103";
+			function = "pci_e1";
+			bias-pull-up;
+		};
+
+		perst-n-pins {
+			pins = "gpio102";
+			function = "gpio";
+			drive-strength = <16>;
+			bias-pull-down;
+		};
+
+		wake-n-pins {
+			pins = "gpio104";
+			function = "gpio";
+			drive-strength = <2>;
+			bias-pull-up;
+		};
+	};
+
+	sdc2_default_state: sdc2-default-state {
+		clk-pins {
+			pins = "sdc2_clk";
+			bias-disable;
+
+			/*
+			 * It seems that mmc_test reports errors if drive
+			 * strength is not 16 on clk, cmd, and data pins.
+			 */
+			drive-strength = <16>;
+		};
+
+		cmd-pins {
+			pins = "sdc2_cmd";
+			bias-pull-up;
+			drive-strength = <10>;
+		};
+
+		data-pins {
+			pins = "sdc2_data";
+			bias-pull-up;
+			drive-strength = <10>;
+		};
+	};
+
+	sdc2_card_det_n: sd-card-det-n-state {
+		pins = "gpio126";
+		function = "gpio";
+		bias-pull-up;
+	};
+};
+
+&uart6 {
+	pinctrl-0 = <&qup_uart6_4pin>;
+
+	status = "okay";
+
+	bluetooth {
+		compatible = "qcom,wcn3990-bt";
+
+		vddio-supply = <&vreg_s4a_1p8>;
+		vddxo-supply = <&vreg_l7a_1p8>;
+		vddrf-supply = <&vreg_l17a_1p3>;
+		vddch0-supply = <&vreg_l25a_3p3>;
+		max-speed = <3200000>;
+	};
+};
+
+&uart9 {
+	status = "okay";
+};
+
+&ufs_mem_hc {
+	status = "okay";
+
+	reset-gpios = <&tlmm 150 GPIO_ACTIVE_LOW>;
+
+	vcc-supply = <&vreg_l20a_2p95>;
+	vcc-max-microamp = <800000>;
+};
+
+&ufs_mem_phy {
+	status = "okay";
+
+	vdda-phy-supply = <&vreg_l1a_0p88>;
+	vdda-pll-supply = <&vreg_l26a_1p2>;
+};
+
+&usb_1 {
+	status = "okay";
+};
+
+&usb_1_dwc3 {
+	dr_mode = "peripheral";
+};
+
+&usb_1_hsphy {
+	status = "okay";
+
+	vdd-supply = <&vreg_l1a_0p88>;
+	vdda-pll-supply = <&vreg_l12a_1p8>;
+	vdda-phy-dpdm-supply = <&vreg_l24a_3p075>;
+
+	qcom,imp-res-offset-value = <8>;
+	qcom,hstx-trim-value = <QUSB2_V2_HSTX_TRIM_21_6_MA>;
+	qcom,preemphasis-level = <QUSB2_V2_PREEMPHASIS_5_PERCENT>;
+	qcom,preemphasis-width = <QUSB2_V2_PREEMPHASIS_WIDTH_HALF_BIT>;
+};
+
+&usb_1_qmpphy {
+	vdda-phy-supply = <&vreg_l26a_1p2>;
+	vdda-pll-supply = <&vreg_l1a_0p88>;
+
+	status = "okay";
+};
+
+/* HS only */
+&usb_2 {
+	qcom,select-utmi-as-pipe-clk;
+
+	status = "okay";
+};
+
+&usb_2_dwc3 {
+	maximum-speed = "high-speed";
+	phys = <&usb_2_hsphy>;
+	phy-names = "usb2-phy";
+
+	dr_mode = "host";
+};
+
+&usb_2_hsphy {
+	vdd-supply = <&vreg_l1a_0p88>;
+	vdda-pll-supply = <&vreg_l12a_1p8>;
+	vdda-phy-dpdm-supply = <&vreg_l24a_3p075>;
+
+	qcom,imp-res-offset-value = <8>;
+	qcom,hstx-trim-value = <QUSB2_V2_HSTX_TRIM_22_8_MA>;
+
+	status = "okay";
+};
+
+&venus {
+	status = "okay";
+};
+
+&wifi {
+	vdd-0.8-cx-mx-supply = <&vreg_l5a_0p8>;
+	vdd-1.8-xo-supply = <&vreg_l7a_1p8>;
+	vdd-1.3-rfa-supply = <&vreg_l17a_1p3>;
+	vdd-3.3-ch0-supply = <&vreg_l25a_3p3>;
+	vdd-3.3-ch1-supply = <&vreg_l23a_3p3>;
+
+	qcom,snoc-host-cap-8bit-quirk;
+	qcom,calibration-variant = "Qualcomm_sdm845hdk";
+
+	status = "okay";
+};
+
+/* PINCTRL - additions to nodes defined in sdm845.dtsi */
+&qup_uart9_rx {
+	drive-strength = <2>;
+	bias-pull-up;
+};
+
+&qup_uart9_tx {
+	drive-strength = <2>;
+	bias-disable;
+};

-- 
2.47.3

Re: [PATCH 4/4] arm64: dts: qcom: add device tree for SDM845-HDK

[Konrad Dybcio]

On 2/17/26 10:20 PM, Dmitry Baryshkov wrote:
> Add device tree for the Qualcomm / Lantronix SDM845 HDK. It is the
> development platform using the modem-less (SDA845) SoC, optional onboard
> DSI panel and a rich set of connectors.
> 
> Working:
> - HDMI display
> - uSD, UFS, USB
> - DSPs, WiFi, BT
> - Buttons, LEDs
> 
> Not working or not tested:
> - DisplayPort - TCPM not supported for this PMIC
> - WiGig - requires power sequencing driver, doesn't work with the
>   current in-kernel driver
> - Audio
> - FingerPrint
> - USIM
> 
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---

[...]

> +	gpio-keys {
> +		compatible = "gpio-keys";
> +		autorepeat;
> +
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&home_pin_a>, <&vol_up_pin_a>;

property-n
property-names

in this order, file-wide, please

[...]

> +&cluster_sleep_0 {
> +	/* default, 0x4100c244, kills the board */
> +	arm,psci-suspend-param = <0x41008244>;
> +};

Does crashdump say anything interesting?

[...]

> +&mdss_dsi1_phy {
> +	vdds-supply = <&vreg_s6a_0p8>;
> +	status = "okay";

Let's uniformly keep a \n above 'status'

[...]

> +&pm8998_gpios {
> +	home_pin_a: home-active-state {
> +		pins = "gpio6";

gpio5 here

[...]

> +&pmi8998_lpg {
> +	status = "okay";
> +
> +	qcom,power-source = <1>;
> +
> +	led@3 {
> +		reg = <3>;
> +		color = <LED_COLOR_ID_BLUE>;
> +		function = LED_FUNCTION_BLUETOOTH;
> +		linux,default-trigger = "bluetooth-power";
> +	};
> +
> +	led@4 {
> +		reg = <4>;
> +		color = <LED_COLOR_ID_GREEN>;
> +		function = LED_FUNCTION_HEARTBEAT;
> +		linux,default-trigger = "heartbeat";
> +		function-enumerator = <2>;

function-enumerators only seem necessary when the same color&func
combo is registered multiple times

> +	};
> +
> +	led@5 {
> +		reg = <5>;
> +		color = <LED_COLOR_ID_RED>;
> +		function = LED_FUNCTION_INDICATOR;
> +		function-enumerator = <1>;

panic-indicator?

> +	};
> +};
> +
> +&pmi8998_wled {
> +	status = "disabled";
> +};

It's already disabled

> +
> +&qupv3_id_0 {
> +	status = "okay";
> +};
> +
> +&qupv3_id_1 {
> +	status = "okay";
> +};
> +
> +&sdhc_2 {
> +	status = "okay";

last, please (there's more occurences below)


> +	pcie0_default_state: pcie0-default-state {
> +		clkreq-pins {
> +			pins = "gpio36";
> +			function = "pci_e0";
> +			bias-pull-up;
> +		};
> +
> +		perst-n-pins {
> +			pins = "gpio35";
> +			function = "gpio";
> +			drive-strength = <2>;
> +			bias-pull-down;

bias-disable?

Konrad