rk3399更换屏幕尺寸后出现drm/rockchip: dw-mipi: fix phy clk lane stop state timeout 的解决办法

由于板子支持不同尺寸的屏幕,我这边用的是5寸屏幕,对应设备树文件kernel/arch/arm64/boot/dts/rockchip/rp-rk3399.dts 头文件中放开#include “rp_lcd_mipi_720_1280.dtsi”
然后编译内核,打包update.img,烧写,重启,出现drm/rockchip: dw-mipi: fix phy clk lane stop state timeout

-----------------------------原文网址-https://www.spinics.net/lists/arm-kernel/msg517057.html ----------------------------致谢—

drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 3 +± 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 72d7f48…8401185 100644
— a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -477,6 +477,8 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
dev_err(dsi->dev,
“failed to wait for phy clk lane stop state\n”);

	+ dsi_write(dsi, DSI_LPCLK_CTRL, PHY_TXREQUESTCLKHS);

phy_init_end:
if (!IS_ERR(dsi->phy_cfg_clk))
clk_disable_unprepare(dsi->phy_cfg_clk);
@@ -714,7 +716,6 @@ static void dw_mipi_dsi_init(struct dw_mipi_dsi *dsi)
| PHY_RSTZ | PHY_SHUTDOWNZ);
dsi_write(dsi, DSI_CLKMGR_CFG, TO_CLK_DIVIDSION(10) |
TX_ESC_CLK_DIVIDSION(7));

    - dsi_write(dsi, DSI_LPCLK_CTRL, PHY_TXREQUESTCLKHS);

}

static void dw_mipi_dsi_dpi_config(struct dw_mipi_dsi *dsi,


上面的意思就是:打开/drivers/gpu/drm/rockchip/dw-mipi-dsi.c文件
1、在"failed to wait for phy clk lane stop state\n");后面增加
dsi_write(dsi, DSI_LPCLK_CTRL, PHY_TXREQUESTCLKHS);
2、把static void dw_mipi_dsi_init(struct dw_mipi_dsi *dsi)函数中的
dsi_write(dsi, DSI_LPCLK_CTRL, PHY_TXREQUESTCLKHS); 注释掉

然后保存编译重新搞一遍内核,烧写。ok。

[ 2.853456] reg-fixed-voltage vcc3v3-pcie3x2-1: nonexclusive access to GPIO for vcc3v3-pcie3x2-1 [ 2.947405] dw-mipi-dsi2 fde20000.dsi: Fixed dependency cycle(s) with /dsi@fde20000/panel0@0 [ 2.947434] mipi-dsi fde20000.dsi.0: Fixed dependency cycle(s) with /dsi@fde20000 [ 3.035490] rockchip-mipi-csi2-hw fdd10000.mipi0-csi2-hw: enter mipi csi2 hw probe! [ 3.035571] rockchip-mipi-csi2-hw fdd10000.mipi0-csi2-hw: probe success, v4l2_dev:mipi0-csi2-hw! [ 3.035600] rockchip-mipi-csi2-hw fdd20000.mipi1-csi2-hw: enter mipi csi2 hw probe! [ 3.035653] rockchip-mipi-csi2-hw fdd20000.mipi1-csi2-hw: probe success, v4l2_dev:mipi1-csi2-hw! [ 3.035676] rockchip-mipi-csi2-hw fdd30000.mipi2-csi2-hw: enter mipi csi2 hw probe! [ 3.035726] rockchip-mipi-csi2-hw fdd30000.mipi2-csi2-hw: probe success, v4l2_dev:mipi2-csi2-hw! [ 3.035748] rockchip-mipi-csi2-hw fdd40000.mipi3-csi2-hw: enter mipi csi2 hw probe! [ 3.035797] rockchip-mipi-csi2-hw fdd40000.mipi3-csi2-hw: probe success, v4l2_dev:mipi3-csi2-hw! [ 3.035819] rockchip-mipi-csi2-hw fdd50000.mipi4-csi2-hw: enter mipi csi2 hw probe! [ 3.035870] rockchip-mipi-csi2-hw fdd50000.mipi4-csi2-hw: probe success, v4l2_dev:mipi4-csi2-hw! [ 3.035892] rockchip-mipi-csi2-hw fdd60000.mipi5-csi2-hw: enter mipi csi2 hw probe! [ 3.035941] rockchip-mipi-csi2-hw fdd60000.mipi5-csi2-hw: probe success, v4l2_dev:mipi5-csi2-hw! [ 29.693440] rockchip-vop2 fdd90000.vop: [drm:vop2_crtc_atomic_enable] Update mode to 376x960p60, type: 16(0 [ 30.456682] dw-mipi-dsi2 fde20000.dsi: [drm:dw_mipi_dsi2_encoder_atomic_enable] final DSI-Link bandwidth: s [ 100.953594] rockchip-vop2 fdd90000.vop: [drm:vop2_crtc_atomic_enable] Update mode to 376x960p60, type: 16(0 [ 101.716915] dw-mipi-dsi2 fde20000.dsi: [drm:dw_mipi_dsi2_encoder_atomic_enable] final DSI-Link bandwidth: s [ 600.729108] rockchip-vop2 fdd90000.vop: [drm:vop2_crtc_atomic_enable] Update mode to 376x960p60, type: 16(0 [ 601.493382] dw-mipi-dsi2 fde20000.dsi: [drm:dw_mipi_dsi2_encoder_atomic_enable] final DSI-Link bandwidth: s 监控内核日志的说明
08-13
rk3562_t:/ # dmesg|grep drm [ 5.348616] OF: fdt: Reserved memory: failed to reserve memory for node 'drm-cubic-lut@00000000': base 0x0000000000000000, size 0 MiB [ 5.783639] rockchip-vop2 ff400000.vop: [drm:vop2_bind] vp0 assign plane mask: 0x30c, primary plane phy id: 2 [ 5.784195] rockchip-drm display-subsystem: bound ff400000.vop (ops vop2_component_ops) [ 6.106010] rockchip-vop2 ff400000.vop: [drm:vop2_bind] vp0 assign plane mask: 0x30c, primary plane phy id: 2 [ 6.106406] rockchip-drm display-subsystem: bound ff400000.vop (ops vop2_component_ops) [ 6.204331] rockchip-vop2 ff400000.vop: [drm:vop2_bind] vp0 assign plane mask: 0x30c, primary plane phy id: 2 [ 6.205136] rockchip-drm display-subsystem: bound ff400000.vop (ops vop2_component_ops) [ 6.205279] rockchip-drm display-subsystem: bound ffb10000.dsi (ops dw_mipi_dsi_rockchip_ops) [ 6.206235] rockchip-drm display-subsystem: bound ff060000.syscon:rgb (ops rockchip_rgb_component_ops) [ 6.223850] [drm] kms: can't enable cloning when we probably wanted to. [ 6.238005] rockchip-drm display-subsystem: [drm] fb0: rockchipdrmfb frame buffer device [ 6.239020] [drm] Initialized rockchip 3.0.0 20140818 for display-subsystem on minor 0 [ 6.250999] [drm] Initialized rknpu 0.9.2 20231018 for ff300000.npu on minor 1 [ 12.129190] init: starting service 'rockchip.drmservice'... [ 20.643676] Freeing drm_logo memory: 736K [ 226.257096] rockchip-vop2 ff400000.vop: [drm:vop2_crtc_atomic_disable] Crtc atomic disable vp0 [ 284.218697] rockchip-vop2 ff400000.vop: [drm:vop2_crtc_atomic_enable] Update mode to 1920x1080p58, type: 16(if:20, flag:0x0) for vp0 dclk: 148500000 [ 286.726897] dw-mipi-dsi-rockchip ffb10000.dsi: [drm:dw_mipi_dsi_bridge_enable] final DSI-Link bandwidth: 996 x 4 Mbps [ 286.993558] rockchip-vop2 ff400000.vop: [drm:vop2_crtc_atomic_disable] Crtc atomic disable vp0 [ 286.997737] rockchip-vop2 ff400000.vop: [drm:vop2_crtc_atomic_enable] Update mode to 1920x1080p58, type: 17(if:1, flag:0x0) for vp0 dclk: 148500000 [ 289.530308] dw-mipi-dsi-rockchip ffb10000.dsi: [drm:dw_mipi_dsi_bridge_enable] final DSI-Link bandwidth: 996 x 4 Mbps rk3562_t:/ # rk3562_t:/ # 这个是相关的日志
06-04
<think>我们正在解决一个内核驱动错误:`dw-mipi-dsi fe070000.dsi [drm:dw_mipi_dsi_probe] failed to get mipi dphy: -517` 错误代码-517表示EPROBE_DEFER,意味着某个依赖的资源(例如时钟、电源、PHY等)尚未准备好,因此需要延迟探测。 根据引用[3]中的代码片段,在dw_mipi_dsi_register函数中,当encoder->possible_crtcs为0时,会返回-EPROBE_DEFER。这提示我们可能是由于DSI控制器依赖的CRTC(显示控制器)还没有初始化完成。 但是,我们当前的错误是在dw_mipi_dsi_probe中发生的,具体是获取mipi dphy失败。因此,问题可能出在DSI控制器无法获取到与其关联的MIPI DPHY(物理层)设备。 解决思路: 1. 检查设备树(DT)配置,确保DSI节点正确引用了DPHY节点。 2. 检查DPHY驱动是否已经正确加载,并且其probe函数是否成功执行。 3. 由于是-517错误,内核会自动重新探测,但我们需要确保依赖关系正确。 步骤: 一、设备树配置: 根据引用[1],设备树中需要正确配置MIPI-DSI节点和DPHY节点。例如: 在DSI节点中,应该有一个指向DPHY节点的phandle。例如: dsi0: dsi@fe070000 { compatible = "rockchip,rk3568-mipi-dsi"; reg = <0x0 0xfe070000 0x0 0x10000>; interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>; clocks = <&cru PCLK_DSITX_0>, <&cru HCLK_VIDEO>; clock-names = "pclk", "hclk"; resets = <&cru SRST_P_DSITX_0>, <&cru SRST_H_DSITX_0>; reset-names = "apb", "ahb"; phys = <&dphy0>; phy-names = "dphy"; ... }; 同时,要有一个DPHY节点,例如: dphy0: dphy@fe070000 { compatible = "rockchip,rk3568-dphy"; reg = <0x0 0xfe070000 0x0 0x10000>; ... }; 注意:上面的reg地址相同,但实际中DPHY可能位于不同的地址,或者在同一地址但通过子寄存器访问。具体要根据硬件手册。 二、DPHY驱动状态: 检查DPHY驱动是否已经正确加载。可以通过查看内核日志(dmesg)来确认DPHY的probe是否成功。 三、内核配置: 确保在内核配置中启用了DPHY的驱动。例如,对于Rockchip平台,需要配置CONFIG_ROCKCHIP_MIPI_DPHY。 四、模块加载顺序: 如果DSI和DPHY驱动都是模块,需要确保DPHY模块先加载。但如果是编译进内核,则顺序由设备初始化顺序决定。 五、检查时钟和电源: 根据引用[2],MIPI DSI的时钟由PLL提供,然后DPHY也有自己的时钟。确保在设备树中为DSI和DPHY提供了正确的时钟,并且这些时钟在驱动中正确获取和使能。 六、参考已有的设备树配置: 参考引用[1]中提到的设备树配置部分(8.1和8.2节),检查自己的设备树是否配置正确。 七、调试方法: 在内核启动参数中添加“initcall_debug”可以跟踪驱动初始化的顺序,有助于找出哪个驱动被延迟了。 具体到错误信息,我们重点关注: failed to get mipi dphy: -517 这通常发生在驱动尝试获取一个phandle指向的设备(这里是DPHY)时,但该设备还没有被初始化(probe)。 因此,我们可以: 1. 检查设备树中DSI节点的"phys"属性是否正确指向了DPHY节点。 2. 确保DPHY节点的compatible字符串正确,并且有对应的驱动。 3. 检查DPHY驱动是否存在返回-EPROBE_DEFER的情况(比如它依赖的时钟、电源等没准备好)。 如果设备树配置正确,那么问题可能出在DPHY驱动本身。需要检查DPHY驱动的probe函数,看它是否因为某些资源(如时钟、复位线、电源等)未准备好而返回-EPROBE_DEFER。 总结步骤: 1. 检查设备树DSI和DPHY节点的配置。 2. 查看内核日志中DPHY驱动的加载情况。 3. 检查内核配置。 4. 使用initcall_debug调试启动顺序。 如果问题仍然存在,可能需要深入分析DPHY驱动和DSI驱动的代码,特别是资源获取和初始化顺序。 注意:根据引用[1]中的环境介绍,可能是T527平台(全志科技?),但错误信息中提到的寄存器地址fe070000是Rockchip RK3568的DSI控制器地址。因此,需要确认平台。不过,解决思路是通用的。 根据引用[3]的代码,在DSI控制器注册时,会尝试获取CRTC,但这里的错误是获取DPHY失败,所以重点在DPHY。 另外,引用[5]提到rockchip_drm_bind函数,这可能是Rockchip DRM驱动的一个关键函数,它负责绑定整个显示子系统。如果平台是Rockchip,那么显示控制器的初始化顺序可能是:先CRTC(VOP),然后DPHY,最后DSI。如果VOP没有准备好,DPHY可能就不会被初始化,进而导致DSI获取DPHY失败。因此,检查整个显示控制器的设备树节点和驱动初始化顺序也很重要。 因此,我们可能需要: 确保在设备树中,DPHY节点所依赖的资源(比如VOP的时钟)已经正确配置。 具体操作: 1. 设备树配置示例(以Rockchip RK3568为例): - 确保DSI节点中的phys属性指向正确的DPHY节点。 - 确保DPHY节点中的clocks属性正确,例如: clocks = <&pmucru CLK_MIPIDPHY_REF>; clock-names = "ref"; 2.DSI节点中,添加对DPHY的依赖: phys = <&dphy>; phy-names = "dphy"; 3. 在DPHY节点中,确保compatible字符串与驱动匹配,例如: compatible = "rockchip,rk3568-dphy"; 4. 检查内核配置: CONFIG_DRM_DW_MIPI_DSI=y CONFIG_PHY_ROCKCHIP_MIPI_RX=y # 接收可能需要,但发送也需要DPHY CONFIG_PHY_ROCKCHIP_INNO_MIPI_DPHY=y # 对于RK3568,这个驱动用于DPHY 5. 如果使用模块,确保加载顺序: modprobe phy_rockchip_inno_mipi_dphy modprobe dw_mipi_dsi 6. 在内核启动参数中添加“initcall_debug”,查看日志中DPHYDSI的probe顺序。 7. 如果DPHY驱动返回-EPROBE_DEFER,则检查DPHY驱动所依赖的资源(时钟、复位、电源域等)是否准备就绪。 8. 对于全志T527平台,则需要使用全志对应的DPHY驱动,并检查其设备树和驱动。 由于错误信息中寄存器地址fe070000是Rockchip RK3568的,因此我们以Rockchip为例,但思路同样适用于其他平台。 最后,如果以上步骤无法解决问题,可以尝试在驱动中添加调试打印,追踪dw_mipi_dsi_probe函数中获取phy的代码路径。 在dw_mipi_dsi_probe函数中,通常会有一行类似这样的代码: dsi->dphy = devm_phy_get(dev, "dphy"); 如果获取失败,就会返回-517。 因此,我们可以检查该函数调用,并确认为什么phy_get会返回-EPROBE_DEFER。 希望这些步骤能帮助解决问题。 </think> ### 解决 `dw-mipi-dsi fe070000.dsi [drm:dw_mipi_dsi_probe] failed to get mipi dphy: -517` 错误的方法 错误代码 `-517` 表示 `EPROBE_DEFER`,即内核在初始化过程中发现 **关键依赖资源未就绪**,需要延迟加载驱动。以下是系统性的解决步骤: --- ### 一、核心原因分析 1. **DPHY 物理层未就绪** MIPI-DSI 控制器依赖 DPHY(物理层)提供时钟和信号传输能力。错误表明 DSI 控制器在探测时无法获取 DPHY 设备(引用[2]): > 在 MIPI_DSI 系统中,PLL 为 MIPI_DSI 提供时钟,而 DPHY 有自己的时钟生成机制[^2]。 2. **依赖资源未初始化** DPHY 可能因以下原因未准备好: - 时钟(Clock)未使能 - 复位(Reset)信号未释放 - 电源域(Power Domain)未开启 - 设备树节点未正确绑定驱动 --- ### 二、解决步骤 #### 1. **检查设备树(DT)配置** - **确认 DPHY 节点存在**:确保 DSI 节点通过 `phys` 属性正确引用 DPHY 节点: ```dts dsi: dsi@fe070000 { compatible = "rockchip,rk3568-mipi-dsi"; phys = <&dphy>; // 关键:指向 DPHY 节点 phy-names = "dphy"; ... }; dphy: phy@fe070000 { // DPHY 节点定义 compatible = "rockchip,rk3568-dphy"; clocks = <&cru CLK_MIPIDPHY_REF>; // 时钟必须正确 resets = <&cru SRST_MIPIDPHY_REF>; // 复位信号 ... }; ``` - **验证时钟和复位**:检查 DPHY 节点的 `clocks` 和 `resets` 属性是否与硬件手册一致(引用[1])。 #### 2. **检查 DPHY 驱动状态** - 通过内核日志确认 DPHY 驱动是否加载成功: ```bash dmesg | grep -i "dphy" ``` - 若 DPHY 驱动未加载,检查内核配置: ``` CONFIG_PHY_ROCKCHIP_INNO_MIPI_DPHY=y # Rockchip 平台 ``` #### 3. **验证资源初始化顺序** -DSI 驱动源码中,确保在 `probe` 函数中获取 DPHY 前,其依赖的资源已就绪: ```c dsi->dphy = devm_phy_get(dev, "dphy"); // 此调用返回 -EPROBE_DEFER ``` - 使用 `initcall_debug` 跟踪初始化顺序: ```bash # 在启动参数添加 initcall_debug ignore_loglevel ``` 查看日志中 DPHYDSI 驱动的加载顺序(DPHY 应先于 DSI)。 #### 4. **电源和时钟管理** - 检查 DPHY 的电源域是否使能(如 `power-domains = <&power RK3568_PD_VI>`)。 - 验证时钟是否被正确使能(引用[2]): > MIPI_DSI 内部的 DPHY 有自己的时钟生成机制[^2]。 #### 5. **处理延迟探测** - 如果 DPHY 驱动返回 `-EPROBE_DEFER`,确保其依赖的资源(如 PLL 时钟)已就绪: ```c // 在 DPHY 驱动中检查时钟 dphy->ref_clk = devm_clk_get(dev, "ref"); if (IS_ERR(dphy->ref_clk)) return PTR_ERR(dphy->ref_clk); ``` --- ### 三、调试技巧 1. **检查驱动匹配状态**: ```bash ls /sys/bus/platform/drivers/dw_mipi_dsi # 查看 DSI 驱动绑定状态 ls /sys/bus/platform/drivers/rockchip-inno-mipi-dphy # 查看 DPHY 驱动绑定 ``` 2. **设备树覆盖测试**: 临时移除 DSI 节点中的 `phys` 属性,观察错误是否变为 `-ENODEV`(确认 DPHY 是根本原因)。 3. **内核补丁**: 若问题由驱动缺陷导致,可尝试修复 DPHY 驱动中的资源获取逻辑(参考引用[3]中的 `dw_mipi_dsi_register` 错误处理)[^3]。 --- ### 四、总结流程 ```mermaid graph TD A[出现 -517 错误] --> B{检查设备树} B -->|DSI 引用 DPHY?| C[验证 DPHY 节点] C -->|时钟/复位正确?| D[检查 DPHY 驱动状态] D -->|驱动未加载| E[启用 CONFIG_PHY_*] D -->|驱动已加载| F[调试资源依赖顺序] F --> G[使用 initcall_debug] G --> H[修复电源/时钟初始化] H --> I[问题解决] ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值