Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1;
Message-ID: <1d9bf80d-0267-937b-4dd9-c57db7a89cb4@quicinc.com>
Date:   Mon, 25 Sep 2023 09:07:18 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Subject: Re: [PATCH v3 6/7] drm/msm/dp: add
 pm_runtime_force_suspend()/resume()
Content-Language: en-US
To:     Abhinav Kumar <quic_abhinavk@quicinc.com>,
        Stephen Boyd <swboyd@chromium.org>,
        Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
CC:     <dri-devel@lists.freedesktop.org>, <robdclark@gmail.com>,
        <sean@poorly.run>, <dianders@chromium.org>, <vkoul@kernel.org>,
        <daniel@ffwll.ch>, <airlied@gmail.com>, <agross@kernel.org>,
        <andersson@kernel.org>, <quic_jesszhan@quicinc.com>,
        <quic_sbillaka@quicinc.com>, <marijn.suijten@somainline.org>,
        <freedreno@lists.freedesktop.org>, <linux-arm-msm@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>
References: <1694813901-26952-1-git-send-email-quic_khsieh@quicinc.com>
 <1694813901-26952-7-git-send-email-quic_khsieh@quicinc.com>
 <CAA8EJpqPXoFX4LXyXYgfh07Vpxg-KgD8VBR6x5bXf4GOJmbOtw@mail.gmail.com>
 <2f98d5f1-57c1-d9fe-cb1c-b975db057287@quicinc.com>
 <CAA8EJpr2wRq6Txi7YAQpJKa_9UGqH_nmHzvVOaAPkwOrtDg4Tw@mail.gmail.com>
 <CAE-0n53dqHONzMTd_ZC-fKWTzDVq6Wqwo4OFZMUcghZ5SD5RhA@mail.gmail.com>
 <65566a68-3510-2e5f-7d57-e4dba08c008c@quicinc.com>
From:   Kuogee Hsieh <quic_khsieh@quicinc.com>
In-Reply-To: <65566a68-3510-2e5f-7d57-e4dba08c008c@quicinc.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk


On 9/22/2023 6:35 PM, Abhinav Kumar wrote:
> Hi Stephen
>
> On 9/22/2023 2:54 PM, Stephen Boyd wrote:
>> Quoting Dmitry Baryshkov (2023-09-19 02:50:12)
>>> On Mon, 18 Sept 2023 at 20:48, Kuogee Hsieh 
>>> <quic_khsieh@quicinc.com> wrote:
>>>>
>>>>
>>>> On 9/15/2023 6:21 PM, Dmitry Baryshkov wrote:
>>>>> On Sat, 16 Sept 2023 at 00:38, Kuogee Hsieh 
>>>>> <quic_khsieh@quicinc.com> wrote:
>>>>>> Add pm_runtime_force_suspend()/resume() to complete incorporating pm
>>>>>> runtime framework into DP driver. Both dp_pm_prepare() and 
>>>>>> dp_pm_complete()
>>>>>> are added to set hpd_state to correct state. After resume, DP 
>>>>>> driver will
>>>>>> re training its main link after .hpd_enable() callback enabled HPD
>>>>>> interrupts and bring up display accordingly.
>>>>> How will it re-train the main link? What is the code path for that?
>>>>
>>>> 1) for edp, dp_bridge_atomic_enable(), called from framework, to start
>>>> link training and bring up display.
>>>
>>> And this path doesn't use .hpd_enable() which you have mentioned in
>>> the commit message. Please don't try to shorten the commit message.
>>> You see, I have had questions to several of them, which means that
>>> they were not verbose enough.
>>>
>>>>
>>>> 2) for external DP, HPD_PLUG_INT will be generated to start link
>>>> training and bring up display.
>>>
>>> This should be hpd_notify, who starts link training, not some event.
>>
>> I think this driver should train the link during atomic_enable(), not
>> hpd_notify() (or directly from the irq handler). The drm_bridge_funcs
>> talk a bit about when the clocks and timing signals are supposed to be
>> enabled. For example, struct drm_bridge_funcs::atomic_pre_enable() says
>> the "display pipe (i.e.  clocks and timing signals) feeding this bridge
>> will not yet be running when this callback is called". And struct
>> drm_bridge_funcs::atomic_enable() says "this callback must enable the
>> display link feeding the next bridge in the chain if there is one."
>>
>> That looks to me like link training, i.e. the display link, should
>> happen in the enable path and not hpd_notify. It looks like link
>> training could fail, but when that happens I believe the driver should
>> call drm_connector_set_link_status_property() with
>> DRM_MODE_LINK_STATUS_BAD. The two callers of that which exist in the
>> tree also call drm_kms_helper_hotplug_event() or
>> drm_kms_helper_connector_hotplug_event() after updating the link so that
>> userspace knows to try again.
>>
>> It would be nice if there was some drm_bridge_set_link_status_bad() API
>> that bridge drivers could use to signal that the link status is bad and
>> call the hotplug helper. Maybe it could also record some diagnostics
>> about which bridge failed to setup the link and stop the atomic_enable()
>> chain for that connector.
>
> Doing link training when we get hpd instead of atomic_enable() is a 
> design choice we have been following for a while because for the case 
> when link training fails in atomic_enable() and setting the link 
> status property as you mentioned, the compositor needs to be able to 
> handle that and also needs to try with a different resolution or take 
> some other corrective action. We have seen many compositors not able 
> to handle this complexity. So the design sends the hotplug to usermode 
> only after link training succeeds.
>
> I do not think we should change this design unless prototyped with an 
> existing compositor such as chrome or android at this point.
>
> Thanks
>
> Abhinav


We did perform link training at atomic_enable() at eDP case since we can 
assume link training will always success without link rate or link lane 
being reduced.

However for external DP case, link training can not be guarantee always 
success without link rate or lane being reduced as Abhinav mentioned.

In addition,  CTS (compliance test) it required to complete link 
training within 10ms after hpd asserted.

I am not sure do link training at atomic_enable() can meet this timing 
requirement.