Re: [PATCH v4 1/2] drm/msm/dp: handle irq_hpd with sink_count = 0 correctly

khsieh
2021-05-19T16:01:42Z

On 2021-05-18 14:42, Stephen Boyd wrote:
> Quoting Kuogee Hsieh (2021-05-14 10:35:13)
>> irq_hpd interrupt should be handled after dongle plugged in and
>> before dongle unplugged. Hence irq_hpd interrupt is enabled at
>> the end of the plugin handle and disabled at the beginning of
>> unplugged handle. Current irq_hpd with sink_count = 0 is wrongly
>> handled same as the dongle unplugged which tears down the mainlink
>> and disables the phy. This patch fixes this problem by only tearing
>> down the mainlink but keeping phy enabled at irq_hpd with
>> sink_count = 0 handle so that next irq_hpd with sink_count =1 can be
>> handled by setup mainlink only.
>>
>> Changes in v2:
>> -- add ctrl->phy_Power_count
>>
>> Changes in v3:
>> -- del ctrl->phy_Power_count
>> -- add phy_power_off to dp_ctrl_off_link_stream()
>>
>> Changes in v4:
>> -- return immediately if clock disable failed at
>> dp_ctrl_off_link_stream()
>>
>> Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
>
> I think we want some Fixes tag. Not sure what it would be though.
>
> I also noticed that if I plug and unplug the HDMI cable from my apple
> dongle that I see this error message
>
> [drm:dp_display_usbpd_attention_cb] *ERROR* Disconnected, no
> DP_LINK_STATUS_UPDATED

> *ERROR* Disconnected, no DP_LINK_STATUS_UPDATED <== this is caused by
> dongle generate the second
irq_hpd with sink_count = 0 after first first irq_hpd with sink_count =
0. The fix is you have
set dongle to D3 (power off) state after first irq_pd with sink_count =
0 handled.
I have a patch fix this problem. I will merge and re submit for review.

> which looks like the irq_hpd comes in while I'm disconnecting the HDMI
> cable but the hpd_state is ST_DISCONNECTED. The state is set to
> ST_DISCONNECTED in msm_dp_display_disable() so it seems that userspace
> has turned off the external display, and then the kthread runs for the
> irq_hpd but it's too late.
>
> Something is missing from this patch then to properly disable the
> IRQ_HPD interrupt before telling userspace that the external display is
> disconnected. Shouldn't we be toggling the irq enable bits from the
> hardirq context when we figure out what it is? The logic would be
>
> in_hardirq() {
>
> if (hpd high)
> enable_irq_hpd(); // Probably this can be delayed to the kthread
> after enabling the link
>
> if (hpd_low)
> disable_irq_hpd(); // But this certainly cannot be in the kthread
>
> else if (irq_hpd) // Notice the else-if so that if hpd is low we
> don't even try to handle irq_hpd if it came in at the same time
> handle_irq_hpd();
> }
>
> Because we can't really mess with the irq controls in the kthread when
> hpd goes low, it will be too late. For all we know, the kthread could
> run seconds later, after an irq_hpd has come bouncing in at the same
> time and pushed an irq_hpd handling event onto the kthread.