Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
In-Reply-To: <ab2a7aadb6ada58246ec972c4938c627@codeaurora.org>
References: <1628007913-29892-1-git-send-email-khsieh@codeaurora.org>
 <CAE-0n51yNrmrqgDrkj2+c2Bx-bYxNs1m2pQBxvVkSpBH2hxzoA@mail.gmail.com> <ab2a7aadb6ada58246ec972c4938c627@codeaurora.org>
From:   Stephen Boyd <swboyd@chromium.org>
User-Agent: alot/0.9.1
Date:   Wed, 4 Aug 2021 09:24:34 -0700
Message-ID: <CAE-0n52bpS4mxM+=xxXvxQYSc5p_xyhkPQ07E1ad9uM1ZBKLwA@mail.gmail.com>
Subject: Re: [PATCH v3] drm/msm/dp: update is_connected status base on sink
 count at dp_pm_resume()
To:     khsieh@codeaurora.org
Cc:     agross@kernel.org, bjorn.andersson@linaro.org, robdclark@gmail.com,
        sean@poorly.run, vkoul@kernel.org, abhinavk@codeaurora.org,
        aravindh@codeaurora.org, freedreno@lists.freedesktop.org,
        dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Quoting khsieh@codeaurora.org (2021-08-04 08:48:04)
> On 2021-08-03 12:05, Stephen Boyd wrote:
> > Quoting Kuogee Hsieh (2021-08-03 09:25:13)
> >> @@ -1327,14 +1327,26 @@ static int dp_pm_resume(struct device *dev)
> >>
> >>         dp_catalog_ctrl_hpd_config(dp->catalog);
> >>
> >> -       status = dp_catalog_link_is_connected(dp->catalog);
> >> +       /*
> >> +        * set sink to normal operation mode -- D0
> >> +        * before dpcd read
> >> +        */
> >> +       dp_link_psm_config(dp->link, &dp->panel->link_info, false);
> >> +
> >> +       /* if sink conencted, do dpcd read sink count */
> >
> > s/conencted/connected/
> >
> > This also just says what the code is doing. Why do we only read the
> > sink
> > count if the link is connected? Can we read the sink count even if the
> > link isn't connected and then consider sink count as 0 if trying to
> > read
> > fails?
> >
> yes, we can do that.
> But it will suffer aux time out and retry.
> i think it is better to avoid this overhead by check connection first.
>

Hmm ok. Maybe something is wrong with the aux channel where it doesn't
avoid the timeout if the connection is obviously not established yet.