| Message ID | 20231103230414.1483428-1-dmitry.baryshkov@linaro.org |
|---|---|
| Headers | show |
| Series | drm: simplify support for transparent DRM bridges | expand |
Hi, On 2023/11/4 07:03, Dmitry Baryshkov wrote: > Supporting DP/USB-C can result in a chain of several transparent > bridges (PHY, redrivers, mux, etc). All attempts to implement DP support > in a different way resulted either in series of hacks or in device tree > not reflecting the actual hardware design. This results in drivers > having similar boilerplate code for such bridges. Please improve the written, "resulted" -> "yield" ? > Next, these drivers are susceptible to -EPROBE_DEFER loops: the next > bridge can either be probed from the bridge->attach callback, when it is > too late to return -EPROBE_DEFER, or from the probe() callback, when the > next bridge might not yet be available, because it depends on the > resources provided by the probing device. Device links can not fully > solve this problem since there are mutual dependencies between adjancent > devices. > > Last, but not least, this results in the the internal knowledge of DRM There is a duplicated "the" word in this sentence. As far as I can understand, nearly all of those troubles are because the display bridges drivers are designed as a kernel module(.ko) instead of making them as static link-able helpers. I means that a display bridge device can not work standalone, as it have to be used with a display controller. So a display bridge is just a slave device or a auxiliary device. My question is: if it can't works by itself, we probably shouldn't design them as kernel modules style. Am I correct? > subsystem slowly diffusing into other subsystems, like PHY or USB/TYPEC. Yeah, this indeed a problem. > To solve all these issues, define a separate DRM helper, which creates > separate aux device just for the bridge. I'm supporting you if want to solve all these problems, this is fine and thanks a lot. But I want to ask a question, now that you are solving these problems by creating separate devices, does this manner match the hardware design perfectly? which is the hardware units you newly created device is corresponding to? > During probe such aux device > doesn't result in the EPROBE_DEFER loops. Instead it allows the device > drivers to probe properly, according to the actual resource > dependencies. The bridge auxdevs are then probed when the next bridge > becomes available, sparing drivers from drm_bridge_attach() returning > -EPROBE_DEFER. OK, as far as I can understand, in order to solve the mentioned problem you are also retire the defer probe mechanism. > Changes since v5: > - Removed extra semicolon in !DRM_AUX_HPD_BRIDGE stubs definition. > > Changes since v4: > - Added documentation for new API (Sima) > - Added generic code to handle "last mile" DP bridges implementing just > the HPD functionality. > - Rebased on top of linux-next to be able to drop #ifdef's around > drm_bridge->of_node > > Changes since v3: > - Moved bridge driver to gpu/drm/bridge (Neil Armstrong) > - Renamed it to aux-bridge (since there is already a simple_bridge driver) > - Made CONFIG_OF mandatory for this driver (Neil Armstrong) > - Added missing kfree and ida_free (Dan Carpenter) > > Changes since v2: > - ifdef'ed bridge->of_node access (LKP) > > Changes since v1: > - Added EXPORT_SYMBOL_GPL / MODULE_LICENSE / etc. to drm_simple_bridge > > Dmitry Baryshkov (6): > drm/bridge: add transparent bridge helper > phy: qcom: qmp-combo: switch to DRM_AUX_BRIDGE > usb: typec: nb7vpq904m: switch to DRM_AUX_BRIDGE > drm/bridge: implement generic DP HPD bridge > soc: qcom: pmic-glink: switch to DRM_AUX_HPD_BRIDGE > usb: typec: qcom-pmic-typec: switch to DRM_AUX_HPD_BRIDGE > > drivers/gpu/drm/bridge/Kconfig | 17 ++ > drivers/gpu/drm/bridge/Makefile | 2 + > drivers/gpu/drm/bridge/aux-bridge.c | 140 +++++++++++++++ > drivers/gpu/drm/bridge/aux-hpd-bridge.c | 164 ++++++++++++++++++ > drivers/phy/qualcomm/Kconfig | 2 +- > drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 44 +---- > drivers/soc/qcom/Kconfig | 1 + > drivers/soc/qcom/pmic_glink_altmode.c | 33 +--- > drivers/usb/typec/mux/Kconfig | 2 +- > drivers/usb/typec/mux/nb7vpq904m.c | 44 +---- > drivers/usb/typec/tcpm/Kconfig | 1 + > drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c | 41 +---- > include/drm/bridge/aux-bridge.h | 37 ++++ > 13 files changed, 383 insertions(+), 145 deletions(-) > create mode 100644 drivers/gpu/drm/bridge/aux-bridge.c > create mode 100644 drivers/gpu/drm/bridge/aux-hpd-bridge.c > create mode 100644 include/drm/bridge/aux-bridge.h >
On Wed, 22 Nov 2023 at 18:03, Sui Jingfeng <sui.jingfeng@linux.dev> wrote: > > Hi, > > > On 2023/11/4 07:03, Dmitry Baryshkov wrote: > > Supporting DP/USB-C can result in a chain of several transparent > > bridges (PHY, redrivers, mux, etc). All attempts to implement DP support > > in a different way resulted either in series of hacks or in device tree > > not reflecting the actual hardware design. This results in drivers > > having similar boilerplate code for such bridges. > > Please improve the written, "resulted" -> "yield" ? > > > Next, these drivers are susceptible to -EPROBE_DEFER loops: the next > > bridge can either be probed from the bridge->attach callback, when it is > > too late to return -EPROBE_DEFER, or from the probe() callback, when the > > next bridge might not yet be available, because it depends on the > > resources provided by the probing device. Device links can not fully > > solve this problem since there are mutual dependencies between adjancent > > devices. > > > > Last, but not least, this results in the the internal knowledge of DRM > > There is a duplicated "the" word in this sentence. > > As far as I can understand, nearly all of those troubles are because the display bridges > drivers are designed as a kernel module(.ko) instead of making them as static link-able > helpers. I means that a display bridge device can not work standalone, as it have to be > used with a display controller. So a display bridge is just a slave device or a auxiliary > device. My question is: if it can't works by itself, we probably shouldn't design them as > kernel modules style. Am I correct? No. This has nothing to do with the driver being a kernel module or built-in. > > > subsystem slowly diffusing into other subsystems, like PHY or USB/TYPEC. > > Yeah, this indeed a problem. > > > To solve all these issues, define a separate DRM helper, which creates > > separate aux device just for the bridge. > > I'm supporting you if want to solve all these problems, this is fine and thanks a lot. > But I want to ask a question, now that you are solving these problems by creating separate > devices, does this manner match the hardware design perfectly? which is the hardware units > you newly created device is corresponding to? Aux devices do not always follow the actual hardware internals. For example, see the TI sn65dsi86 driver, which also uses aux devices to split dependency and probing chains. > > During probe such aux device > > doesn't result in the EPROBE_DEFER loops. Instead it allows the device > > drivers to probe properly, according to the actual resource > > dependencies. The bridge auxdevs are then probed when the next bridge > > becomes available, sparing drivers from drm_bridge_attach() returning > > -EPROBE_DEFER. > > OK, as far as I can understand, in order to solve the mentioned problem > you are also retire the defer probe mechanism. No, I'm not retiring the probe deferral mechanism. Instead I'm splitting it into two chains. One going from the controller to the usb-c connector for the signal flow, another going from the connector back to the drm_encoder for the drm_bridge dependencies. > > > > Changes since v5: > > - Removed extra semicolon in !DRM_AUX_HPD_BRIDGE stubs definition. > > > > Changes since v4: > > - Added documentation for new API (Sima) > > - Added generic code to handle "last mile" DP bridges implementing just > > the HPD functionality. > > - Rebased on top of linux-next to be able to drop #ifdef's around > > drm_bridge->of_node > > > > Changes since v3: > > - Moved bridge driver to gpu/drm/bridge (Neil Armstrong) > > - Renamed it to aux-bridge (since there is already a simple_bridge driver) > > - Made CONFIG_OF mandatory for this driver (Neil Armstrong) > > - Added missing kfree and ida_free (Dan Carpenter) > > > > Changes since v2: > > - ifdef'ed bridge->of_node access (LKP) > > > > Changes since v1: > > - Added EXPORT_SYMBOL_GPL / MODULE_LICENSE / etc. to drm_simple_bridge > > > > Dmitry Baryshkov (6): > > drm/bridge: add transparent bridge helper > > phy: qcom: qmp-combo: switch to DRM_AUX_BRIDGE > > usb: typec: nb7vpq904m: switch to DRM_AUX_BRIDGE > > drm/bridge: implement generic DP HPD bridge > > soc: qcom: pmic-glink: switch to DRM_AUX_HPD_BRIDGE > > usb: typec: qcom-pmic-typec: switch to DRM_AUX_HPD_BRIDGE > > > > drivers/gpu/drm/bridge/Kconfig | 17 ++ > > drivers/gpu/drm/bridge/Makefile | 2 + > > drivers/gpu/drm/bridge/aux-bridge.c | 140 +++++++++++++++ > > drivers/gpu/drm/bridge/aux-hpd-bridge.c | 164 ++++++++++++++++++ > > drivers/phy/qualcomm/Kconfig | 2 +- > > drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 44 +---- > > drivers/soc/qcom/Kconfig | 1 + > > drivers/soc/qcom/pmic_glink_altmode.c | 33 +--- > > drivers/usb/typec/mux/Kconfig | 2 +- > > drivers/usb/typec/mux/nb7vpq904m.c | 44 +---- > > drivers/usb/typec/tcpm/Kconfig | 1 + > > drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c | 41 +---- > > include/drm/bridge/aux-bridge.h | 37 ++++ > > 13 files changed, 383 insertions(+), 145 deletions(-) > > create mode 100644 drivers/gpu/drm/bridge/aux-bridge.c > > create mode 100644 drivers/gpu/drm/bridge/aux-hpd-bridge.c > > create mode 100644 include/drm/bridge/aux-bridge.h > >
On 03/11/2023 23:03, Dmitry Baryshkov wrote: > Supporting DP/USB-C can result in a chain of several transparent > bridges (PHY, redrivers, mux, etc). All attempts to implement DP support > in a different way resulted either in series of hacks or in device tree > not reflecting the actual hardware design. This results in drivers > having similar boilerplate code for such bridges. > > Next, these drivers are susceptible to -EPROBE_DEFER loops: the next > bridge can either be probed from the bridge->attach callback, when it is > too late to return -EPROBE_DEFER, or from the probe() callback, when the > next bridge might not yet be available, because it depends on the > resources provided by the probing device. Device links can not fully > solve this problem since there are mutual dependencies between adjancent > devices. > > Last, but not least, this results in the the internal knowledge of DRM > subsystem slowly diffusing into other subsystems, like PHY or USB/TYPEC. > > To solve all these issues, define a separate DRM helper, which creates > separate aux device just for the bridge. During probe such aux device > doesn't result in the EPROBE_DEFER loops. Instead it allows the device > drivers to probe properly, according to the actual resource > dependencies. The bridge auxdevs are then probed when the next bridge > becomes available, sparing drivers from drm_bridge_attach() returning > -EPROBE_DEFER. Dmitry, Looking to give you a Tested-by: here but got the below splat. https://git.codelinaro.org/bryan.odonoghue/kernel/-/tree/next-20231123-tcpm-fix?ref_type=heads - Boot via fastboot - Remove USB cable - Attach DisplayPort cable - Get some activity on the DP - Then this root@linaro-gnome:~# [ 376.861822] xhci-hcd xhci-hcd.4.auto: xHCI Host Controller [ 376.867584] xhci-hcd xhci-hcd.4.auto: new USB bus registered, assigned bus number 3 [ 376.875775] xhci-hcd xhci-hcd.4.auto: hcc params 0x0230ffe5 hci version 0x110 quirks 0x0000000000000010 [ 376.885666] xhci-hcd xhci-hcd.4.auto: irq 229, io mem 0x0a600000 [ 376.892140] xhci-hcd xhci-hcd.4.auto: xHCI Host Controller [ 376.897951] xhci-hcd xhci-hcd.4.auto: new USB bus registered, assigned bus number 4 [ 376.905869] xhci-hcd xhci-hcd.4.auto: Host supports USB 3.1 Enhanced SuperSpeed [ 376.914130] hub 3-0:1.0: USB hub found [ 376.918030] hub 3-0:1.0: 1 port detected [ 376.922417] usb usb4: We don't know the algorithms for LPM for this host, disabling LPM. [ 376.931540] hub 4-0:1.0: USB hub found [ 376.935439] hub 4-0:1.0: 1 port detected [ 377.885638] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060 [ 377.892927] msm_dpu ae01000.display-controller: [drm] Cannot find any crtc or sizes [ 377.894724] Mem abort info: [ 377.905504] ESR = 0x0000000096000004 [ 377.909375] EC = 0x25: DABT (current EL), IL = 32 bits [ 377.914852] SET = 0, FnV = 0 [ 377.918005] EA = 0, S1PTW = 0 [ 377.921250] FSC = 0x04: level 0 translation fault [ 377.926269] Data abort info: [ 377.929239] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 377.934881] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 377.940095] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 377.945563] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101992000 [ 377.952441] [0000000000000060] pgd=0000000000000000, p4d=0000000000000000 [ 377.959448] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 377.965882] Modules linked in: typec_displayport nf_tables libcrc32c nfnetlink q6asm_dai q6routing q6afe_clocks q6afe_dai q6asm q6adm snd_q6dsp_common q6afe q6core apr pdr_interfacer [ 377.965984] aux_bridge crct10dif_ce snd_soc_lpass_macro_common drm_kms_helper qnoc_sm8250 qcom_wdt icc_osm_l3 fuse drm backlight dm_mod ip_tables x_tables [ 378.072201] CPU: 5 PID: 379 Comm: dp_hpd_handler Not tainted 6.7.0-rc2-next-20231123-00008-g812004aeedc0-dirty #30 [ 378.082817] Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) [ 378.088884] msm_dpu ae01000.display-controller: [drm] Cannot find any crtc or sizes [ 378.089697] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 378.089700] pc : drm_object_property_set_value+0x0/0x88 [drm] [ 378.110607] lr : drm_dp_set_subconnector_property+0x58/0x64 [drm_display_helper] [ 378.118205] sp : ffff800081fbbda0 [ 378.121616] x29: ffff800081fbbda0 x28: 0000000000000000 x27: 0000000000000000 [ 378.128940] x26: 0000000000000000 x25: 0000000000000000 x24: ffff38d1ccef2880 [ 378.136264] x23: ffff38d1ccef2a10 x22: ffff38d1ccef2880 x21: ffff38d1ccef29f0 [ 378.143587] x20: 0000000000000000 x19: ffff38d1ccef2880 x18: 0000000000000000 [ 378.150911] x17: 000000040044ffff x16: ffffa79c03e1fe34 x15: 0000000000000000 [ 378.158235] x14: ffff38d1c5861000 x13: 00000000000003ec x12: 0000000000000001 [ 378.165560] x11: 071c71c71c71c71c x10: 0000000000000b00 x9 : ffff800081fbb9d0 [ 378.172884] x8 : ffffa79b9b4d9000 x7 : 0000000000000001 x6 : ffffa79b9b6d74b0 [ 378.180207] x5 : 0000000000000000 x4 : ffff38d1cb2d3800 x3 : ffff38d1c28e169f [ 378.187530] x2 : 000000000000000f x1 : 0000000000000000 x0 : ffff38d1cb2d3840 [ 378.194853] Call trace: [ 378.197376] drm_object_property_set_value+0x0/0x88 [drm] [ 378.202947] dp_display_process_hpd_high+0xa0/0x14c [msm] [ 378.208526] dp_hpd_plug_handle.isra.0+0x8c/0x10c [msm] [ 378.213918] hpd_event_thread+0xc4/0x56c [msm] [ 378.218508] kthread+0x110/0x114 [ 378.221828] ret_from_fork+0x10/0x20 [ 378.225506] Code: 128002a0 d65f03c0 d4210000 17ffffea (f9403024) [ 378.231763] ---[ end trace 0000000000000000 ]--- [ 384.505974] msm_dpu ae01000.display-controller: [drm] Cannot find any crtc or sizes [ 385.538016] msm_dpu ae01000.display-controller: [drm] Cannot find any crtc or sizes [ 385.666018] msm_dpu ae01000.display-controller: [drm] Cannot find any crtc or sizes
On Fri, 24 Nov 2023 at 14:23, Bryan O'Donoghue <bryan.odonoghue@linaro.org> wrote: > > On 03/11/2023 23:03, Dmitry Baryshkov wrote: > > Supporting DP/USB-C can result in a chain of several transparent > > bridges (PHY, redrivers, mux, etc). All attempts to implement DP support > > in a different way resulted either in series of hacks or in device tree > > not reflecting the actual hardware design. This results in drivers > > having similar boilerplate code for such bridges. > > > > Next, these drivers are susceptible to -EPROBE_DEFER loops: the next > > bridge can either be probed from the bridge->attach callback, when it is > > too late to return -EPROBE_DEFER, or from the probe() callback, when the > > next bridge might not yet be available, because it depends on the > > resources provided by the probing device. Device links can not fully > > solve this problem since there are mutual dependencies between adjancent > > devices. > > > > Last, but not least, this results in the the internal knowledge of DRM > > subsystem slowly diffusing into other subsystems, like PHY or USB/TYPEC. > > > > To solve all these issues, define a separate DRM helper, which creates > > separate aux device just for the bridge. During probe such aux device > > doesn't result in the EPROBE_DEFER loops. Instead it allows the device > > drivers to probe properly, according to the actual resource > > dependencies. The bridge auxdevs are then probed when the next bridge > > becomes available, sparing drivers from drm_bridge_attach() returning > > -EPROBE_DEFER. > > Dmitry, > > Looking to give you a Tested-by: here but got the below splat. This should be fixed by https://gitlab.freedesktop.org/drm/msm/-/tags/drm-msm-fixes-2023-11-21 > > https://git.codelinaro.org/bryan.odonoghue/kernel/-/tree/next-20231123-tcpm-fix?ref_type=heads > > - Boot via fastboot > - Remove USB cable > - Attach DisplayPort cable > - Get some activity on the DP > - Then this > > root@linaro-gnome:~# [ 376.861822] xhci-hcd xhci-hcd.4.auto: xHCI Host > Controller > [ 376.867584] xhci-hcd xhci-hcd.4.auto: new USB bus registered, > assigned bus number 3 > [ 376.875775] xhci-hcd xhci-hcd.4.auto: hcc params 0x0230ffe5 hci > version 0x110 quirks 0x0000000000000010 > [ 376.885666] xhci-hcd xhci-hcd.4.auto: irq 229, io mem 0x0a600000 > [ 376.892140] xhci-hcd xhci-hcd.4.auto: xHCI Host Controller > [ 376.897951] xhci-hcd xhci-hcd.4.auto: new USB bus registered, > assigned bus number 4 > [ 376.905869] xhci-hcd xhci-hcd.4.auto: Host supports USB 3.1 Enhanced > SuperSpeed > [ 376.914130] hub 3-0:1.0: USB hub found > [ 376.918030] hub 3-0:1.0: 1 port detected > [ 376.922417] usb usb4: We don't know the algorithms for LPM for this > host, disabling LPM. > [ 376.931540] hub 4-0:1.0: USB hub found > [ 376.935439] hub 4-0:1.0: 1 port detected > [ 377.885638] Unable to handle kernel NULL pointer dereference at > virtual address 0000000000000060 > [ 377.892927] msm_dpu ae01000.display-controller: [drm] Cannot find any > crtc or sizes > [ 377.894724] Mem abort info: > [ 377.905504] ESR = 0x0000000096000004 > [ 377.909375] EC = 0x25: DABT (current EL), IL = 32 bits > [ 377.914852] SET = 0, FnV = 0 > [ 377.918005] EA = 0, S1PTW = 0 > [ 377.921250] FSC = 0x04: level 0 translation fault > [ 377.926269] Data abort info: > [ 377.929239] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 > [ 377.934881] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 > [ 377.940095] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 > [ 377.945563] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101992000 > [ 377.952441] [0000000000000060] pgd=0000000000000000, p4d=0000000000000000 > [ 377.959448] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP > [ 377.965882] Modules linked in: typec_displayport nf_tables libcrc32c > nfnetlink q6asm_dai q6routing q6afe_clocks q6afe_dai q6asm q6adm > snd_q6dsp_common q6afe q6core apr pdr_interfacer > [ 377.965984] aux_bridge crct10dif_ce snd_soc_lpass_macro_common > drm_kms_helper qnoc_sm8250 qcom_wdt icc_osm_l3 fuse drm backlight dm_mod > ip_tables x_tables > [ 378.072201] CPU: 5 PID: 379 Comm: dp_hpd_handler Not tainted > 6.7.0-rc2-next-20231123-00008-g812004aeedc0-dirty #30 > [ 378.082817] Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) > [ 378.088884] msm_dpu ae01000.display-controller: [drm] Cannot find any > crtc or sizes > [ 378.089697] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS > BTYPE=--) > [ 378.089700] pc : drm_object_property_set_value+0x0/0x88 [drm] > [ 378.110607] lr : drm_dp_set_subconnector_property+0x58/0x64 > [drm_display_helper] > [ 378.118205] sp : ffff800081fbbda0 > [ 378.121616] x29: ffff800081fbbda0 x28: 0000000000000000 x27: > 0000000000000000 > [ 378.128940] x26: 0000000000000000 x25: 0000000000000000 x24: > ffff38d1ccef2880 > [ 378.136264] x23: ffff38d1ccef2a10 x22: ffff38d1ccef2880 x21: > ffff38d1ccef29f0 > [ 378.143587] x20: 0000000000000000 x19: ffff38d1ccef2880 x18: > 0000000000000000 > [ 378.150911] x17: 000000040044ffff x16: ffffa79c03e1fe34 x15: > 0000000000000000 > [ 378.158235] x14: ffff38d1c5861000 x13: 00000000000003ec x12: > 0000000000000001 > [ 378.165560] x11: 071c71c71c71c71c x10: 0000000000000b00 x9 : > ffff800081fbb9d0 > [ 378.172884] x8 : ffffa79b9b4d9000 x7 : 0000000000000001 x6 : > ffffa79b9b6d74b0 > [ 378.180207] x5 : 0000000000000000 x4 : ffff38d1cb2d3800 x3 : > ffff38d1c28e169f > [ 378.187530] x2 : 000000000000000f x1 : 0000000000000000 x0 : > ffff38d1cb2d3840 > [ 378.194853] Call trace: > [ 378.197376] drm_object_property_set_value+0x0/0x88 [drm] > [ 378.202947] dp_display_process_hpd_high+0xa0/0x14c [msm] > [ 378.208526] dp_hpd_plug_handle.isra.0+0x8c/0x10c [msm] > [ 378.213918] hpd_event_thread+0xc4/0x56c [msm] > [ 378.218508] kthread+0x110/0x114 > [ 378.221828] ret_from_fork+0x10/0x20 > [ 378.225506] Code: 128002a0 d65f03c0 d4210000 17ffffea (f9403024) > [ 378.231763] ---[ end trace 0000000000000000 ]--- > [ 384.505974] msm_dpu ae01000.display-controller: [drm] Cannot find any > crtc or sizes > [ 385.538016] msm_dpu ae01000.display-controller: [drm] Cannot find any > crtc or sizes > [ 385.666018] msm_dpu ae01000.display-controller: [drm] Cannot find any > crtc or sizes > >