linux/drivers/gpu/drm/mediatek/mtk_dp.c

2970 lines
77 KiB

drm/mediatek: dp: Add hpd debounce From the DP spec 1.4a chapter 3.3, upstream devices should implement HPD signal de-bouncing on an external connection. A period of 100ms should be used to detect an HPD connect event. To cover these cases, HPD de-bounce should be implemented only after HPD low has been detected for at least 100ms. Therefore, 1. If HPD is low (which means plugging out) for longer than 100ms: we need to do de-bouncing (which means we need to wait for 100ms). 2. If HPD low is for less than 100ms: we don't need to care about the de-bouncing. In this patch, we start a 100ms timer and use a need_debounce boolean to implement the feature. Two cases when HPD is high: 1. If the timer is expired (>100ms): - need_debounce is true. - When HPD high (plugging event comes), need_debounce will be true and then we need to do de-bouncing (wait for 100ms). 2. If the timer is not expired (<100ms): - need_debounce is false. - When HPD high (plugging event comes), need_debounce will be false and no need to do de-bouncing. HPD_______ __________________ | |<- 100ms -> |____________| <- 100ms -> Without HPD de-bouncing, USB-C to HDMI Adapaters will not be detected. The change has been successfully tested with the following devices: - Dell Adapter - USB-C to HDMI - Acer 1in1 HDMI dongle - Ugreen 1in1 HDMI dongle - innowatt HDMI + USB3 hub - Acer 2in1 HDMI dongle - Apple 3in1 HDMI dongle (A2119) - J5Create 3in1 HDMI dongle (JAC379) Tested-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Signed-off-by: Guillaume Ranquet <granquet@baylibre.com> Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220901044149.16782-10-rex-bc.chen@mediatek.com
2022-09-01 12:41:48 +08:00
drm/mediatek: dp: Add hpd debounce From the DP spec 1.4a chapter 3.3, upstream devices should implement HPD signal de-bouncing on an external connection. A period of 100ms should be used to detect an HPD connect event. To cover these cases, HPD de-bounce should be implemented only after HPD low has been detected for at least 100ms. Therefore, 1. If HPD is low (which means plugging out) for longer than 100ms: we need to do de-bouncing (which means we need to wait for 100ms). 2. If HPD low is for less than 100ms: we don't need to care about the de-bouncing. In this patch, we start a 100ms timer and use a need_debounce boolean to implement the feature. Two cases when HPD is high: 1. If the timer is expired (>100ms): - need_debounce is true. - When HPD high (plugging event comes), need_debounce will be true and then we need to do de-bouncing (wait for 100ms). 2. If the timer is not expired (<100ms): - need_debounce is false. - When HPD high (plugging event comes), need_debounce will be false and no need to do de-bouncing. HPD_______ __________________ | |<- 100ms -> |____________| <- 100ms -> Without HPD de-bouncing, USB-C to HDMI Adapaters will not be detected. The change has been successfully tested with the following devices: - Dell Adapter - USB-C to HDMI - Acer 1in1 HDMI dongle - Ugreen 1in1 HDMI dongle - innowatt HDMI + USB3 hub - Acer 2in1 HDMI dongle - Apple 3in1 HDMI dongle (A2119) - J5Create 3in1 HDMI dongle (JAC379) Tested-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Signed-off-by: Guillaume Ranquet <granquet@baylibre.com> Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220901044149.16782-10-rex-bc.chen@mediatek.com
2022-09-01 12:41:48 +08:00
drm/mediatek: Move DP training to hotplug thread By adjusting the order of link training and relocating it to HPD, link training can identify the usability of each lane in the current link. It also supports handling signal instability and weakness due to environmental issues, enabling the acquisition of a stable bandwidth for the current link. Subsequently, DP work can proceed based on the actual maximum bandwidth. It should training in the hpd event thread. Check the mode with lane count and link rate of training. If we're eDP and capabilities were already parsed we can skip reading again because eDP panels aren't hotpluggable hence the caps and training information won't ever change in a boot life Therefore, bridge typec judgment is required for edp training in atomic_enable function. `mtk_dp_parse_capabilities` is related to DP training, it is used in `mtk_dp_hpd_event_thread` before DP training, and then only used by eDP when read edid. -Modify part of in `mtk_dp_bridge_atomic_disable` if (mtk_dp->train_info.cable_plugged_in) { drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D3); usleep_range(2000, 3000); } /* power off aux */ mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE, DP_PWR_STATE_BANDGAP_TPLL, DP_PWR_STATE_MASK); -Modify part of in `mtk_dp_aux_panel_poweron(mtk_dp, false);` if (pwron) { .... } else { /* power off panel */ drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D3); usleep_range(2000, 3000); /* power off aux */ mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE, DP_PWR_STATE_BANDGAP_TPLL, DP_PWR_STATE_MASK); } The `mtk_dp_aux_panel_poweron` function fails to align. Within the `mtk_dp_hpd_event_thread`, if DP is disconnected, the `mtk_dp_aux_panel_poweron` function will write from `aux` to `DPRX`, causing a failure and thus preventing symmetry. This shows the current timings after the DP cable is plugged in, as well as the modified timings. current timings: Fix timings: mtk_dp_hpd_event_thread() mtk_dp_hpd_event_thread() (including DP link training) | | ... ... mtk_dp_bridge_mode_valid() mtk_dp_bridge_mode_valid() | ... ... mtk_dp_bridge_atomic_check() mtk_dp_bridge_atomic_check() | ... ... mtk_dp_bridge_atomic_enable() mtk_dp_bridge_atomic_enable() (including DP link training) PS: 1. "..." represents ommited steps; 2. `mtk_dp_bridge_mode_valid()` calculates the bandwidth using the current lane count and link rate, and then filters each mode to determine if it supports returning a status. 3. In the `drm_display_mode_to_videomode(&crtc_state->adjusted_mode, &mtk_dp->info.vm);` function, within the `mtk_dp_bridge_atomic_check()` function, `adjusted_mode` sets the currently selected display mode for the DRM. 4. DP link training tests the signal conditions of the link between DPTX and DPRX, and selects the lane count and link rate that meet the signal conditions. 5. For example, the platform support DP 4lane 5.4G, but panel A support DP 2lane 5.4G. This is a time sequence: a).Plug in panel A. According to the platform, it can output 4K60Hz. b).Timing mode set 4K 60Hz(Including in mtk_dp_bridge_atomic_check function). c).Atomic enable(Based on panel A ability, training pass 2lane 5.4G). d).Finally, due to 2lane 5.4G bandwidth limitation, the platform cannot output 4K 60Hz, resulting in a black sreen. If apply this patch. a).Plug in panel A. b).Training pass 2lane 5.4G c).Timing mode set 2K 60Hz(Based on the 2lane 5.4G bandwidth limit and including in mtk_dp_bridge_atomic_che Signed-off-by: Liankun Yang <liankun.yang@mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20251223061755.7717-1-liankun.yang@mediatek.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-12-23 14:16:52 +08:00
drm/mediatek: dp: Add hpd debounce From the DP spec 1.4a chapter 3.3, upstream devices should implement HPD signal de-bouncing on an external connection. A period of 100ms should be used to detect an HPD connect event. To cover these cases, HPD de-bounce should be implemented only after HPD low has been detected for at least 100ms. Therefore, 1. If HPD is low (which means plugging out) for longer than 100ms: we need to do de-bouncing (which means we need to wait for 100ms). 2. If HPD low is for less than 100ms: we don't need to care about the de-bouncing. In this patch, we start a 100ms timer and use a need_debounce boolean to implement the feature. Two cases when HPD is high: 1. If the timer is expired (>100ms): - need_debounce is true. - When HPD high (plugging event comes), need_debounce will be true and then we need to do de-bouncing (wait for 100ms). 2. If the timer is not expired (<100ms): - need_debounce is false. - When HPD high (plugging event comes), need_debounce will be false and no need to do de-bouncing. HPD_______ __________________ | |<- 100ms -> |____________| <- 100ms -> Without HPD de-bouncing, USB-C to HDMI Adapaters will not be detected. The change has been successfully tested with the following devices: - Dell Adapter - USB-C to HDMI - Acer 1in1 HDMI dongle - Ugreen 1in1 HDMI dongle - innowatt HDMI + USB3 hub - Acer 2in1 HDMI dongle - Apple 3in1 HDMI dongle (A2119) - J5Create 3in1 HDMI dongle (JAC379) Tested-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Signed-off-by: Guillaume Ranquet <granquet@baylibre.com> Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220901044149.16782-10-rex-bc.chen@mediatek.com
2022-09-01 12:41:48 +08:00
drm/mediatek: dp: Add hpd debounce From the DP spec 1.4a chapter 3.3, upstream devices should implement HPD signal de-bouncing on an external connection. A period of 100ms should be used to detect an HPD connect event. To cover these cases, HPD de-bounce should be implemented only after HPD low has been detected for at least 100ms. Therefore, 1. If HPD is low (which means plugging out) for longer than 100ms: we need to do de-bouncing (which means we need to wait for 100ms). 2. If HPD low is for less than 100ms: we don't need to care about the de-bouncing. In this patch, we start a 100ms timer and use a need_debounce boolean to implement the feature. Two cases when HPD is high: 1. If the timer is expired (>100ms): - need_debounce is true. - When HPD high (plugging event comes), need_debounce will be true and then we need to do de-bouncing (wait for 100ms). 2. If the timer is not expired (<100ms): - need_debounce is false. - When HPD high (plugging event comes), need_debounce will be false and no need to do de-bouncing. HPD_______ __________________ | |<- 100ms -> |____________| <- 100ms -> Without HPD de-bouncing, USB-C to HDMI Adapaters will not be detected. The change has been successfully tested with the following devices: - Dell Adapter - USB-C to HDMI - Acer 1in1 HDMI dongle - Ugreen 1in1 HDMI dongle - innowatt HDMI + USB3 hub - Acer 2in1 HDMI dongle - Apple 3in1 HDMI dongle (A2119) - J5Create 3in1 HDMI dongle (JAC379) Tested-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Signed-off-by: Guillaume Ranquet <granquet@baylibre.com> Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220901044149.16782-10-rex-bc.chen@mediatek.com
2022-09-01 12:41:48 +08:00
drm/mediatek: dp: Add hpd debounce From the DP spec 1.4a chapter 3.3, upstream devices should implement HPD signal de-bouncing on an external connection. A period of 100ms should be used to detect an HPD connect event. To cover these cases, HPD de-bounce should be implemented only after HPD low has been detected for at least 100ms. Therefore, 1. If HPD is low (which means plugging out) for longer than 100ms: we need to do de-bouncing (which means we need to wait for 100ms). 2. If HPD low is for less than 100ms: we don't need to care about the de-bouncing. In this patch, we start a 100ms timer and use a need_debounce boolean to implement the feature. Two cases when HPD is high: 1. If the timer is expired (>100ms): - need_debounce is true. - When HPD high (plugging event comes), need_debounce will be true and then we need to do de-bouncing (wait for 100ms). 2. If the timer is not expired (<100ms): - need_debounce is false. - When HPD high (plugging event comes), need_debounce will be false and no need to do de-bouncing. HPD_______ __________________ | |<- 100ms -> |____________| <- 100ms -> Without HPD de-bouncing, USB-C to HDMI Adapaters will not be detected. The change has been successfully tested with the following devices: - Dell Adapter - USB-C to HDMI - Acer 1in1 HDMI dongle - Ugreen 1in1 HDMI dongle - innowatt HDMI + USB3 hub - Acer 2in1 HDMI dongle - Apple 3in1 HDMI dongle (A2119) - J5Create 3in1 HDMI dongle (JAC379) Tested-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Signed-off-by: Guillaume Ranquet <granquet@baylibre.com> Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220901044149.16782-10-rex-bc.chen@mediatek.com
2022-09-01 12:41:48 +08:00
drm/mediatek: Move DP training to hotplug thread By adjusting the order of link training and relocating it to HPD, link training can identify the usability of each lane in the current link. It also supports handling signal instability and weakness due to environmental issues, enabling the acquisition of a stable bandwidth for the current link. Subsequently, DP work can proceed based on the actual maximum bandwidth. It should training in the hpd event thread. Check the mode with lane count and link rate of training. If we're eDP and capabilities were already parsed we can skip reading again because eDP panels aren't hotpluggable hence the caps and training information won't ever change in a boot life Therefore, bridge typec judgment is required for edp training in atomic_enable function. `mtk_dp_parse_capabilities` is related to DP training, it is used in `mtk_dp_hpd_event_thread` before DP training, and then only used by eDP when read edid. -Modify part of in `mtk_dp_bridge_atomic_disable` if (mtk_dp->train_info.cable_plugged_in) { drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D3); usleep_range(2000, 3000); } /* power off aux */ mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE, DP_PWR_STATE_BANDGAP_TPLL, DP_PWR_STATE_MASK); -Modify part of in `mtk_dp_aux_panel_poweron(mtk_dp, false);` if (pwron) { .... } else { /* power off panel */ drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D3); usleep_range(2000, 3000); /* power off aux */ mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE, DP_PWR_STATE_BANDGAP_TPLL, DP_PWR_STATE_MASK); } The `mtk_dp_aux_panel_poweron` function fails to align. Within the `mtk_dp_hpd_event_thread`, if DP is disconnected, the `mtk_dp_aux_panel_poweron` function will write from `aux` to `DPRX`, causing a failure and thus preventing symmetry. This shows the current timings after the DP cable is plugged in, as well as the modified timings. current timings: Fix timings: mtk_dp_hpd_event_thread() mtk_dp_hpd_event_thread() (including DP link training) | | ... ... mtk_dp_bridge_mode_valid() mtk_dp_bridge_mode_valid() | ... ... mtk_dp_bridge_atomic_check() mtk_dp_bridge_atomic_check() | ... ... mtk_dp_bridge_atomic_enable() mtk_dp_bridge_atomic_enable() (including DP link training) PS: 1. "..." represents ommited steps; 2. `mtk_dp_bridge_mode_valid()` calculates the bandwidth using the current lane count and link rate, and then filters each mode to determine if it supports returning a status. 3. In the `drm_display_mode_to_videomode(&crtc_state->adjusted_mode, &mtk_dp->info.vm);` function, within the `mtk_dp_bridge_atomic_check()` function, `adjusted_mode` sets the currently selected display mode for the DRM. 4. DP link training tests the signal conditions of the link between DPTX and DPRX, and selects the lane count and link rate that meet the signal conditions. 5. For example, the platform support DP 4lane 5.4G, but panel A support DP 2lane 5.4G. This is a time sequence: a).Plug in panel A. According to the platform, it can output 4K60Hz. b).Timing mode set 4K 60Hz(Including in mtk_dp_bridge_atomic_check function). c).Atomic enable(Based on panel A ability, training pass 2lane 5.4G). d).Finally, due to 2lane 5.4G bandwidth limitation, the platform cannot output 4K 60Hz, resulting in a black sreen. If apply this patch. a).Plug in panel A. b).Training pass 2lane 5.4G c).Timing mode set 2K 60Hz(Based on the 2lane 5.4G bandwidth limit and including in mtk_dp_bridge_atomic_che Signed-off-by: Liankun Yang <liankun.yang@mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20251223061755.7717-1-liankun.yang@mediatek.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-12-23 14:16:52 +08:00
drm/mediatek: dp: Add hpd debounce From the DP spec 1.4a chapter 3.3, upstream devices should implement HPD signal de-bouncing on an external connection. A period of 100ms should be used to detect an HPD connect event. To cover these cases, HPD de-bounce should be implemented only after HPD low has been detected for at least 100ms. Therefore, 1. If HPD is low (which means plugging out) for longer than 100ms: we need to do de-bouncing (which means we need to wait for 100ms). 2. If HPD low is for less than 100ms: we don't need to care about the de-bouncing. In this patch, we start a 100ms timer and use a need_debounce boolean to implement the feature. Two cases when HPD is high: 1. If the timer is expired (>100ms): - need_debounce is true. - When HPD high (plugging event comes), need_debounce will be true and then we need to do de-bouncing (wait for 100ms). 2. If the timer is not expired (<100ms): - need_debounce is false. - When HPD high (plugging event comes), need_debounce will be false and no need to do de-bouncing. HPD_______ __________________ | |<- 100ms -> |____________| <- 100ms -> Without HPD de-bouncing, USB-C to HDMI Adapaters will not be detected. The change has been successfully tested with the following devices: - Dell Adapter - USB-C to HDMI - Acer 1in1 HDMI dongle - Ugreen 1in1 HDMI dongle - innowatt HDMI + USB3 hub - Acer 2in1 HDMI dongle - Apple 3in1 HDMI dongle (A2119) - J5Create 3in1 HDMI dongle (JAC379) Tested-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Signed-off-by: Guillaume Ranquet <granquet@baylibre.com> Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220901044149.16782-10-rex-bc.chen@mediatek.com
2022-09-01 12:41:48 +08:00
drm/mediatek: Move DP training to hotplug thread By adjusting the order of link training and relocating it to HPD, link training can identify the usability of each lane in the current link. It also supports handling signal instability and weakness due to environmental issues, enabling the acquisition of a stable bandwidth for the current link. Subsequently, DP work can proceed based on the actual maximum bandwidth. It should training in the hpd event thread. Check the mode with lane count and link rate of training. If we're eDP and capabilities were already parsed we can skip reading again because eDP panels aren't hotpluggable hence the caps and training information won't ever change in a boot life Therefore, bridge typec judgment is required for edp training in atomic_enable function. `mtk_dp_parse_capabilities` is related to DP training, it is used in `mtk_dp_hpd_event_thread` before DP training, and then only used by eDP when read edid. -Modify part of in `mtk_dp_bridge_atomic_disable` if (mtk_dp->train_info.cable_plugged_in) { drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D3); usleep_range(2000, 3000); } /* power off aux */ mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE, DP_PWR_STATE_BANDGAP_TPLL, DP_PWR_STATE_MASK); -Modify part of in `mtk_dp_aux_panel_poweron(mtk_dp, false);` if (pwron) { .... } else { /* power off panel */ drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D3); usleep_range(2000, 3000); /* power off aux */ mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE, DP_PWR_STATE_BANDGAP_TPLL, DP_PWR_STATE_MASK); } The `mtk_dp_aux_panel_poweron` function fails to align. Within the `mtk_dp_hpd_event_thread`, if DP is disconnected, the `mtk_dp_aux_panel_poweron` function will write from `aux` to `DPRX`, causing a failure and thus preventing symmetry. This shows the current timings after the DP cable is plugged in, as well as the modified timings. current timings: Fix timings: mtk_dp_hpd_event_thread() mtk_dp_hpd_event_thread() (including DP link training) | | ... ... mtk_dp_bridge_mode_valid() mtk_dp_bridge_mode_valid() | ... ... mtk_dp_bridge_atomic_check() mtk_dp_bridge_atomic_check() | ... ... mtk_dp_bridge_atomic_enable() mtk_dp_bridge_atomic_enable() (including DP link training) PS: 1. "..." represents ommited steps; 2. `mtk_dp_bridge_mode_valid()` calculates the bandwidth using the current lane count and link rate, and then filters each mode to determine if it supports returning a status. 3. In the `drm_display_mode_to_videomode(&crtc_state->adjusted_mode, &mtk_dp->info.vm);` function, within the `mtk_dp_bridge_atomic_check()` function, `adjusted_mode` sets the currently selected display mode for the DRM. 4. DP link training tests the signal conditions of the link between DPTX and DPRX, and selects the lane count and link rate that meet the signal conditions. 5. For example, the platform support DP 4lane 5.4G, but panel A support DP 2lane 5.4G. This is a time sequence: a).Plug in panel A. According to the platform, it can output 4K60Hz. b).Timing mode set 4K 60Hz(Including in mtk_dp_bridge_atomic_check function). c).Atomic enable(Based on panel A ability, training pass 2lane 5.4G). d).Finally, due to 2lane 5.4G bandwidth limitation, the platform cannot output 4K 60Hz, resulting in a black sreen. If apply this patch. a).Plug in panel A. b).Training pass 2lane 5.4G c).Timing mode set 2K 60Hz(Based on the 2lane 5.4G bandwidth limit and including in mtk_dp_bridge_atomic_che Signed-off-by: Liankun Yang <liankun.yang@mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20251223061755.7717-1-liankun.yang@mediatek.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-12-23 14:16:52 +08:00
drm/mediatek: dp: Add hpd debounce From the DP spec 1.4a chapter 3.3, upstream devices should implement HPD signal de-bouncing on an external connection. A period of 100ms should be used to detect an HPD connect event. To cover these cases, HPD de-bounce should be implemented only after HPD low has been detected for at least 100ms. Therefore, 1. If HPD is low (which means plugging out) for longer than 100ms: we need to do de-bouncing (which means we need to wait for 100ms). 2. If HPD low is for less than 100ms: we don't need to care about the de-bouncing. In this patch, we start a 100ms timer and use a need_debounce boolean to implement the feature. Two cases when HPD is high: 1. If the timer is expired (>100ms): - need_debounce is true. - When HPD high (plugging event comes), need_debounce will be true and then we need to do de-bouncing (wait for 100ms). 2. If the timer is not expired (<100ms): - need_debounce is false. - When HPD high (plugging event comes), need_debounce will be false and no need to do de-bouncing. HPD_______ __________________ | |<- 100ms -> |____________| <- 100ms -> Without HPD de-bouncing, USB-C to HDMI Adapaters will not be detected. The change has been successfully tested with the following devices: - Dell Adapter - USB-C to HDMI - Acer 1in1 HDMI dongle - Ugreen 1in1 HDMI dongle - innowatt HDMI + USB3 hub - Acer 2in1 HDMI dongle - Apple 3in1 HDMI dongle (A2119) - J5Create 3in1 HDMI dongle (JAC379) Tested-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Signed-off-by: Guillaume Ranquet <granquet@baylibre.com> Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220901044149.16782-10-rex-bc.chen@mediatek.com
2022-09-01 12:41:48 +08:00
drm/mediatek: Move DP training to hotplug thread By adjusting the order of link training and relocating it to HPD, link training can identify the usability of each lane in the current link. It also supports handling signal instability and weakness due to environmental issues, enabling the acquisition of a stable bandwidth for the current link. Subsequently, DP work can proceed based on the actual maximum bandwidth. It should training in the hpd event thread. Check the mode with lane count and link rate of training. If we're eDP and capabilities were already parsed we can skip reading again because eDP panels aren't hotpluggable hence the caps and training information won't ever change in a boot life Therefore, bridge typec judgment is required for edp training in atomic_enable function. `mtk_dp_parse_capabilities` is related to DP training, it is used in `mtk_dp_hpd_event_thread` before DP training, and then only used by eDP when read edid. -Modify part of in `mtk_dp_bridge_atomic_disable` if (mtk_dp->train_info.cable_plugged_in) { drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D3); usleep_range(2000, 3000); } /* power off aux */ mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE, DP_PWR_STATE_BANDGAP_TPLL, DP_PWR_STATE_MASK); -Modify part of in `mtk_dp_aux_panel_poweron(mtk_dp, false);` if (pwron) { .... } else { /* power off panel */ drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D3); usleep_range(2000, 3000); /* power off aux */ mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE, DP_PWR_STATE_BANDGAP_TPLL, DP_PWR_STATE_MASK); } The `mtk_dp_aux_panel_poweron` function fails to align. Within the `mtk_dp_hpd_event_thread`, if DP is disconnected, the `mtk_dp_aux_panel_poweron` function will write from `aux` to `DPRX`, causing a failure and thus preventing symmetry. This shows the current timings after the DP cable is plugged in, as well as the modified timings. current timings: Fix timings: mtk_dp_hpd_event_thread() mtk_dp_hpd_event_thread() (including DP link training) | | ... ... mtk_dp_bridge_mode_valid() mtk_dp_bridge_mode_valid() | ... ... mtk_dp_bridge_atomic_check() mtk_dp_bridge_atomic_check() | ... ... mtk_dp_bridge_atomic_enable() mtk_dp_bridge_atomic_enable() (including DP link training) PS: 1. "..." represents ommited steps; 2. `mtk_dp_bridge_mode_valid()` calculates the bandwidth using the current lane count and link rate, and then filters each mode to determine if it supports returning a status. 3. In the `drm_display_mode_to_videomode(&crtc_state->adjusted_mode, &mtk_dp->info.vm);` function, within the `mtk_dp_bridge_atomic_check()` function, `adjusted_mode` sets the currently selected display mode for the DRM. 4. DP link training tests the signal conditions of the link between DPTX and DPRX, and selects the lane count and link rate that meet the signal conditions. 5. For example, the platform support DP 4lane 5.4G, but panel A support DP 2lane 5.4G. This is a time sequence: a).Plug in panel A. According to the platform, it can output 4K60Hz. b).Timing mode set 4K 60Hz(Including in mtk_dp_bridge_atomic_check function). c).Atomic enable(Based on panel A ability, training pass 2lane 5.4G). d).Finally, due to 2lane 5.4G bandwidth limitation, the platform cannot output 4K 60Hz, resulting in a black sreen. If apply this patch. a).Plug in panel A. b).Training pass 2lane 5.4G c).Timing mode set 2K 60Hz(Based on the 2lane 5.4G bandwidth limit and including in mtk_dp_bridge_atomic_che Signed-off-by: Liankun Yang <liankun.yang@mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20251223061755.7717-1-liankun.yang@mediatek.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-12-23 14:16:52 +08:00
drm/mediatek: Move DP training to hotplug thread By adjusting the order of link training and relocating it to HPD, link training can identify the usability of each lane in the current link. It also supports handling signal instability and weakness due to environmental issues, enabling the acquisition of a stable bandwidth for the current link. Subsequently, DP work can proceed based on the actual maximum bandwidth. It should training in the hpd event thread. Check the mode with lane count and link rate of training. If we're eDP and capabilities were already parsed we can skip reading again because eDP panels aren't hotpluggable hence the caps and training information won't ever change in a boot life Therefore, bridge typec judgment is required for edp training in atomic_enable function. `mtk_dp_parse_capabilities` is related to DP training, it is used in `mtk_dp_hpd_event_thread` before DP training, and then only used by eDP when read edid. -Modify part of in `mtk_dp_bridge_atomic_disable` if (mtk_dp->train_info.cable_plugged_in) { drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D3); usleep_range(2000, 3000); } /* power off aux */ mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE, DP_PWR_STATE_BANDGAP_TPLL, DP_PWR_STATE_MASK); -Modify part of in `mtk_dp_aux_panel_poweron(mtk_dp, false);` if (pwron) { .... } else { /* power off panel */ drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D3); usleep_range(2000, 3000); /* power off aux */ mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE, DP_PWR_STATE_BANDGAP_TPLL, DP_PWR_STATE_MASK); } The `mtk_dp_aux_panel_poweron` function fails to align. Within the `mtk_dp_hpd_event_thread`, if DP is disconnected, the `mtk_dp_aux_panel_poweron` function will write from `aux` to `DPRX`, causing a failure and thus preventing symmetry. This shows the current timings after the DP cable is plugged in, as well as the modified timings. current timings: Fix timings: mtk_dp_hpd_event_thread() mtk_dp_hpd_event_thread() (including DP link training) | | ... ... mtk_dp_bridge_mode_valid() mtk_dp_bridge_mode_valid() | ... ... mtk_dp_bridge_atomic_check() mtk_dp_bridge_atomic_check() | ... ... mtk_dp_bridge_atomic_enable() mtk_dp_bridge_atomic_enable() (including DP link training) PS: 1. "..." represents ommited steps; 2. `mtk_dp_bridge_mode_valid()` calculates the bandwidth using the current lane count and link rate, and then filters each mode to determine if it supports returning a status. 3. In the `drm_display_mode_to_videomode(&crtc_state->adjusted_mode, &mtk_dp->info.vm);` function, within the `mtk_dp_bridge_atomic_check()` function, `adjusted_mode` sets the currently selected display mode for the DRM. 4. DP link training tests the signal conditions of the link between DPTX and DPRX, and selects the lane count and link rate that meet the signal conditions. 5. For example, the platform support DP 4lane 5.4G, but panel A support DP 2lane 5.4G. This is a time sequence: a).Plug in panel A. According to the platform, it can output 4K60Hz. b).Timing mode set 4K 60Hz(Including in mtk_dp_bridge_atomic_check function). c).Atomic enable(Based on panel A ability, training pass 2lane 5.4G). d).Finally, due to 2lane 5.4G bandwidth limitation, the platform cannot output 4K 60Hz, resulting in a black sreen. If apply this patch. a).Plug in panel A. b).Training pass 2lane 5.4G c).Timing mode set 2K 60Hz(Based on the 2lane 5.4G bandwidth limit and including in mtk_dp_bridge_atomic_che Signed-off-by: Liankun Yang <liankun.yang@mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20251223061755.7717-1-liankun.yang@mediatek.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-12-23 14:16:52 +08:00
drm/mediatek: Move DP training to hotplug thread By adjusting the order of link training and relocating it to HPD, link training can identify the usability of each lane in the current link. It also supports handling signal instability and weakness due to environmental issues, enabling the acquisition of a stable bandwidth for the current link. Subsequently, DP work can proceed based on the actual maximum bandwidth. It should training in the hpd event thread. Check the mode with lane count and link rate of training. If we're eDP and capabilities were already parsed we can skip reading again because eDP panels aren't hotpluggable hence the caps and training information won't ever change in a boot life Therefore, bridge typec judgment is required for edp training in atomic_enable function. `mtk_dp_parse_capabilities` is related to DP training, it is used in `mtk_dp_hpd_event_thread` before DP training, and then only used by eDP when read edid. -Modify part of in `mtk_dp_bridge_atomic_disable` if (mtk_dp->train_info.cable_plugged_in) { drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D3); usleep_range(2000, 3000); } /* power off aux */ mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE, DP_PWR_STATE_BANDGAP_TPLL, DP_PWR_STATE_MASK); -Modify part of in `mtk_dp_aux_panel_poweron(mtk_dp, false);` if (pwron) { .... } else { /* power off panel */ drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D3); usleep_range(2000, 3000); /* power off aux */ mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE, DP_PWR_STATE_BANDGAP_TPLL, DP_PWR_STATE_MASK); } The `mtk_dp_aux_panel_poweron` function fails to align. Within the `mtk_dp_hpd_event_thread`, if DP is disconnected, the `mtk_dp_aux_panel_poweron` function will write from `aux` to `DPRX`, causing a failure and thus preventing symmetry. This shows the current timings after the DP cable is plugged in, as well as the modified timings. current timings: Fix timings: mtk_dp_hpd_event_thread() mtk_dp_hpd_event_thread() (including DP link training) | | ... ... mtk_dp_bridge_mode_valid() mtk_dp_bridge_mode_valid() | ... ... mtk_dp_bridge_atomic_check() mtk_dp_bridge_atomic_check() | ... ... mtk_dp_bridge_atomic_enable() mtk_dp_bridge_atomic_enable() (including DP link training) PS: 1. "..." represents ommited steps; 2. `mtk_dp_bridge_mode_valid()` calculates the bandwidth using the current lane count and link rate, and then filters each mode to determine if it supports returning a status. 3. In the `drm_display_mode_to_videomode(&crtc_state->adjusted_mode, &mtk_dp->info.vm);` function, within the `mtk_dp_bridge_atomic_check()` function, `adjusted_mode` sets the currently selected display mode for the DRM. 4. DP link training tests the signal conditions of the link between DPTX and DPRX, and selects the lane count and link rate that meet the signal conditions. 5. For example, the platform support DP 4lane 5.4G, but panel A support DP 2lane 5.4G. This is a time sequence: a).Plug in panel A. According to the platform, it can output 4K60Hz. b).Timing mode set 4K 60Hz(Including in mtk_dp_bridge_atomic_check function). c).Atomic enable(Based on panel A ability, training pass 2lane 5.4G). d).Finally, due to 2lane 5.4G bandwidth limitation, the platform cannot output 4K 60Hz, resulting in a black sreen. If apply this patch. a).Plug in panel A. b).Training pass 2lane 5.4G c).Timing mode set 2K 60Hz(Based on the 2lane 5.4G bandwidth limit and including in mtk_dp_bridge_atomic_che Signed-off-by: Liankun Yang <liankun.yang@mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20251223061755.7717-1-liankun.yang@mediatek.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-12-23 14:16:52 +08:00
drm/mediatek: Move DP training to hotplug thread By adjusting the order of link training and relocating it to HPD, link training can identify the usability of each lane in the current link. It also supports handling signal instability and weakness due to environmental issues, enabling the acquisition of a stable bandwidth for the current link. Subsequently, DP work can proceed based on the actual maximum bandwidth. It should training in the hpd event thread. Check the mode with lane count and link rate of training. If we're eDP and capabilities were already parsed we can skip reading again because eDP panels aren't hotpluggable hence the caps and training information won't ever change in a boot life Therefore, bridge typec judgment is required for edp training in atomic_enable function. `mtk_dp_parse_capabilities` is related to DP training, it is used in `mtk_dp_hpd_event_thread` before DP training, and then only used by eDP when read edid. -Modify part of in `mtk_dp_bridge_atomic_disable` if (mtk_dp->train_info.cable_plugged_in) { drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D3); usleep_range(2000, 3000); } /* power off aux */ mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE, DP_PWR_STATE_BANDGAP_TPLL, DP_PWR_STATE_MASK); -Modify part of in `mtk_dp_aux_panel_poweron(mtk_dp, false);` if (pwron) { .... } else { /* power off panel */ drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D3); usleep_range(2000, 3000); /* power off aux */ mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE, DP_PWR_STATE_BANDGAP_TPLL, DP_PWR_STATE_MASK); } The `mtk_dp_aux_panel_poweron` function fails to align. Within the `mtk_dp_hpd_event_thread`, if DP is disconnected, the `mtk_dp_aux_panel_poweron` function will write from `aux` to `DPRX`, causing a failure and thus preventing symmetry. This shows the current timings after the DP cable is plugged in, as well as the modified timings. current timings: Fix timings: mtk_dp_hpd_event_thread() mtk_dp_hpd_event_thread() (including DP link training) | | ... ... mtk_dp_bridge_mode_valid() mtk_dp_bridge_mode_valid() | ... ... mtk_dp_bridge_atomic_check() mtk_dp_bridge_atomic_check() | ... ... mtk_dp_bridge_atomic_enable() mtk_dp_bridge_atomic_enable() (including DP link training) PS: 1. "..." represents ommited steps; 2. `mtk_dp_bridge_mode_valid()` calculates the bandwidth using the current lane count and link rate, and then filters each mode to determine if it supports returning a status. 3. In the `drm_display_mode_to_videomode(&crtc_state->adjusted_mode, &mtk_dp->info.vm);` function, within the `mtk_dp_bridge_atomic_check()` function, `adjusted_mode` sets the currently selected display mode for the DRM. 4. DP link training tests the signal conditions of the link between DPTX and DPRX, and selects the lane count and link rate that meet the signal conditions. 5. For example, the platform support DP 4lane 5.4G, but panel A support DP 2lane 5.4G. This is a time sequence: a).Plug in panel A. According to the platform, it can output 4K60Hz. b).Timing mode set 4K 60Hz(Including in mtk_dp_bridge_atomic_check function). c).Atomic enable(Based on panel A ability, training pass 2lane 5.4G). d).Finally, due to 2lane 5.4G bandwidth limitation, the platform cannot output 4K 60Hz, resulting in a black sreen. If apply this patch. a).Plug in panel A. b).Training pass 2lane 5.4G c).Timing mode set 2K 60Hz(Based on the 2lane 5.4G bandwidth limit and including in mtk_dp_bridge_atomic_che Signed-off-by: Liankun Yang <liankun.yang@mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20251223061755.7717-1-liankun.yang@mediatek.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-12-23 14:16:52 +08:00
drm/mediatek: Move DP training to hotplug thread By adjusting the order of link training and relocating it to HPD, link training can identify the usability of each lane in the current link. It also supports handling signal instability and weakness due to environmental issues, enabling the acquisition of a stable bandwidth for the current link. Subsequently, DP work can proceed based on the actual maximum bandwidth. It should training in the hpd event thread. Check the mode with lane count and link rate of training. If we're eDP and capabilities were already parsed we can skip reading again because eDP panels aren't hotpluggable hence the caps and training information won't ever change in a boot life Therefore, bridge typec judgment is required for edp training in atomic_enable function. `mtk_dp_parse_capabilities` is related to DP training, it is used in `mtk_dp_hpd_event_thread` before DP training, and then only used by eDP when read edid. -Modify part of in `mtk_dp_bridge_atomic_disable` if (mtk_dp->train_info.cable_plugged_in) { drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D3); usleep_range(2000, 3000); } /* power off aux */ mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE, DP_PWR_STATE_BANDGAP_TPLL, DP_PWR_STATE_MASK); -Modify part of in `mtk_dp_aux_panel_poweron(mtk_dp, false);` if (pwron) { .... } else { /* power off panel */ drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D3); usleep_range(2000, 3000); /* power off aux */ mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE, DP_PWR_STATE_BANDGAP_TPLL, DP_PWR_STATE_MASK); } The `mtk_dp_aux_panel_poweron` function fails to align. Within the `mtk_dp_hpd_event_thread`, if DP is disconnected, the `mtk_dp_aux_panel_poweron` function will write from `aux` to `DPRX`, causing a failure and thus preventing symmetry. This shows the current timings after the DP cable is plugged in, as well as the modified timings. current timings: Fix timings: mtk_dp_hpd_event_thread() mtk_dp_hpd_event_thread() (including DP link training) | | ... ... mtk_dp_bridge_mode_valid() mtk_dp_bridge_mode_valid() | ... ... mtk_dp_bridge_atomic_check() mtk_dp_bridge_atomic_check() | ... ... mtk_dp_bridge_atomic_enable() mtk_dp_bridge_atomic_enable() (including DP link training) PS: 1. "..." represents ommited steps; 2. `mtk_dp_bridge_mode_valid()` calculates the bandwidth using the current lane count and link rate, and then filters each mode to determine if it supports returning a status. 3. In the `drm_display_mode_to_videomode(&crtc_state->adjusted_mode, &mtk_dp->info.vm);` function, within the `mtk_dp_bridge_atomic_check()` function, `adjusted_mode` sets the currently selected display mode for the DRM. 4. DP link training tests the signal conditions of the link between DPTX and DPRX, and selects the lane count and link rate that meet the signal conditions. 5. For example, the platform support DP 4lane 5.4G, but panel A support DP 2lane 5.4G. This is a time sequence: a).Plug in panel A. According to the platform, it can output 4K60Hz. b).Timing mode set 4K 60Hz(Including in mtk_dp_bridge_atomic_check function). c).Atomic enable(Based on panel A ability, training pass 2lane 5.4G). d).Finally, due to 2lane 5.4G bandwidth limitation, the platform cannot output 4K 60Hz, resulting in a black sreen. If apply this patch. a).Plug in panel A. b).Training pass 2lane 5.4G c).Timing mode set 2K 60Hz(Based on the 2lane 5.4G bandwidth limit and including in mtk_dp_bridge_atomic_che Signed-off-by: Liankun Yang <liankun.yang@mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20251223061755.7717-1-liankun.yang@mediatek.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-12-23 14:16:52 +08:00
drm/mediatek: dp: Add hpd debounce From the DP spec 1.4a chapter 3.3, upstream devices should implement HPD signal de-bouncing on an external connection. A period of 100ms should be used to detect an HPD connect event. To cover these cases, HPD de-bounce should be implemented only after HPD low has been detected for at least 100ms. Therefore, 1. If HPD is low (which means plugging out) for longer than 100ms: we need to do de-bouncing (which means we need to wait for 100ms). 2. If HPD low is for less than 100ms: we don't need to care about the de-bouncing. In this patch, we start a 100ms timer and use a need_debounce boolean to implement the feature. Two cases when HPD is high: 1. If the timer is expired (>100ms): - need_debounce is true. - When HPD high (plugging event comes), need_debounce will be true and then we need to do de-bouncing (wait for 100ms). 2. If the timer is not expired (<100ms): - need_debounce is false. - When HPD high (plugging event comes), need_debounce will be false and no need to do de-bouncing. HPD_______ __________________ | |<- 100ms -> |____________| <- 100ms -> Without HPD de-bouncing, USB-C to HDMI Adapaters will not be detected. The change has been successfully tested with the following devices: - Dell Adapter - USB-C to HDMI - Acer 1in1 HDMI dongle - Ugreen 1in1 HDMI dongle - innowatt HDMI + USB3 hub - Acer 2in1 HDMI dongle - Apple 3in1 HDMI dongle (A2119) - J5Create 3in1 HDMI dongle (JAC379) Tested-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Signed-off-by: Guillaume Ranquet <granquet@baylibre.com> Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220901044149.16782-10-rex-bc.chen@mediatek.com
2022-09-01 12:41:48 +08:00
drm/mediatek: dp: Add hpd debounce From the DP spec 1.4a chapter 3.3, upstream devices should implement HPD signal de-bouncing on an external connection. A period of 100ms should be used to detect an HPD connect event. To cover these cases, HPD de-bounce should be implemented only after HPD low has been detected for at least 100ms. Therefore, 1. If HPD is low (which means plugging out) for longer than 100ms: we need to do de-bouncing (which means we need to wait for 100ms). 2. If HPD low is for less than 100ms: we don't need to care about the de-bouncing. In this patch, we start a 100ms timer and use a need_debounce boolean to implement the feature. Two cases when HPD is high: 1. If the timer is expired (>100ms): - need_debounce is true. - When HPD high (plugging event comes), need_debounce will be true and then we need to do de-bouncing (wait for 100ms). 2. If the timer is not expired (<100ms): - need_debounce is false. - When HPD high (plugging event comes), need_debounce will be false and no need to do de-bouncing. HPD_______ __________________ | |<- 100ms -> |____________| <- 100ms -> Without HPD de-bouncing, USB-C to HDMI Adapaters will not be detected. The change has been successfully tested with the following devices: - Dell Adapter - USB-C to HDMI - Acer 1in1 HDMI dongle - Ugreen 1in1 HDMI dongle - innowatt HDMI + USB3 hub - Acer 2in1 HDMI dongle - Apple 3in1 HDMI dongle (A2119) - J5Create 3in1 HDMI dongle (JAC379) Tested-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Signed-off-by: Guillaume Ranquet <granquet@baylibre.com> Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220901044149.16782-10-rex-bc.chen@mediatek.com
2022-09-01 12:41:48 +08:00
drm: convert many bridge drivers from devm_kzalloc() to devm_drm_bridge_alloc() API devm_drm_bridge_alloc() is the new API to be used for allocating (and partially initializing) a private driver struct embedding a struct drm_bridge. For many drivers having a simple code flow in the probe function, this commit does a mass conversion automatically with the following semantic patch. The changes have been reviewed manually for correctness as well as to find any false positives. The patch has been applied with the explicit exclusion of bridge/panel.c, handled by a separate patch. After applying the semantic patch, manually fixed these issues: - 4 drivers need ERR_CAST() instead of PTR_ERR() as the function calling devm_drm_bridge_alloc() returns a pointer - re-added empty lines and comments that the script had removed but that should stay @@ type T; identifier C; identifier BR; expression DEV; expression FUNCS; @@ -T *C; +T *C; ... ( -C = devm_kzalloc(DEV, ...); -if (!C) - return -ENOMEM; +C = devm_drm_bridge_alloc(DEV, T, BR, FUNCS); +if (IS_ERR(C)) + return PTR_ERR(C); | -C = devm_kzalloc(DEV, ...); -if (!C) - return ERR_PTR(-ENOMEM); +C = devm_drm_bridge_alloc(DEV, T, BR, FUNCS); +if (IS_ERR(C)) + return PTR_ERR(C); ) ... -C->BR.funcs = FUNCS; Reviewed-by: Manikandan Muralidharan <manikandan.m@microchip.com> # microchip-lvds.c Reviewed-by: Douglas Anderson <dianders@chromium.org> # parade-ps8640 Tested-by: Douglas Anderson <dianders@chromium.org> # parade-ps8640 Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250509-drm-bridge-convert-to-alloc-api-v3-2-b8bc1f16d7aa@bootlin.com [Luca: fixed trivial patch conflict in adv7511_drv.c while applying] Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-05-09 15:53:28 +02:00