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

[khsieh@codeaurora.org]

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.