[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAE-0n53WW0jqorW2MPaTczmJP+d+_qaRBcwmoJBP2dL4x8_DqA@mail.gmail.com>
Date: Fri, 21 May 2021 14:56:12 -0700
From: Stephen Boyd <swboyd@...omium.org>
To: Kuogee Hsieh <khsieh@...eaurora.org>, agross@...nel.org,
bjorn.andersson@...aro.org, robdclark@...il.com, sean@...rly.run,
vkoul@...nel.org
Cc: abhinavk@...eaurora.org, aravindh@...eaurora.org,
linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 1/2] drm/msm/dp: handle irq_hpd with sink_count = 0 correctly
Quoting Kuogee Hsieh (2021-05-19 13:22:33)
> 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. This patch also set dongle into D3
> (power off) state at end of handling irq_hpd with sink_count = 0.
>
> 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()
>
> Changes in v5:
> -- set dongle to D3 (power off) state at dp_ctrl_off_link_stream()
>
> Changes in v6:
> -- add Fixes tag
>
> Fixes: 94e58e2d06e3 ("drm/msm/dp: reset dp controller only at boot up and pm_resume")
>
> Signed-off-by: Kuogee Hsieh <khsieh@...eaurora.org>
> ---
Tested-by: Stephen Boyd <swboyd@...omium.org>
Reviewed-by: Stephen Boyd <swboyd@...omium.org>
We can resolve the lingering dual irq issue later on if you don't want
to send another round of this. Also, the title says 1/2 so I wonder if
there's another patch? Doesn't look like there is but I have to ask. If
not, please generate patches with the right -<N> argument or revision
range.
Powered by blists - more mailing lists