mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kuogee Hsieh <quic_khsieh@quicinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: <robdclark@gmail.com>, <sean@poorly.run>, <swboyd@chromium.org>,
	<vkoul@kernel.org>, <daniel@ffwll.ch>, <airlied@linux.ie>,
	<agross@kernel.org>, <bjorn.andersson@linaro.org>,
	<quic_abhinavk@quicinc.com>, <quic_aravindh@quicinc.com>,
	<quic_sbillaka@quicinc.com>, <freedreno@lists.freedesktop.org>,
	<dri-devel@lists.freedesktop.org>,
	<linux-arm-msm@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] drm/msm/dp: enhance both connect and disconnect pending_timeout handle
Date: Thu, 14 Apr 2022 15:06:28 -0700	[thread overview]
Message-ID: <2039ef97-4fdb-bffe-1e02-18ae79c18be4@quicinc.com> (raw)
In-Reply-To: <CAA8EJpqzucFGf8ndDi2LZqtKiOt_w=_h1oPAUNVCdmUyh_3+zA@mail.gmail.com>


On 4/8/2022 4:59 PM, Dmitry Baryshkov wrote:
> On Fri, 8 Apr 2022 at 23:30, Kuogee Hsieh <quic_khsieh@quicinc.com> wrote:
>>
>> On 4/8/2022 5:27 AM, Dmitry Baryshkov wrote:
>>> On 07/04/2022 00:28, Kuogee Hsieh wrote:
>>>> dp_hpd_plug_handle() is responsible for setting up main link and send
>>>> uevent to notify user space framework to start video stream. Similarly,
>>>> dp_hdp_unplug_handle is responsible to send uevent to notify user space
>>>> framework to stop video stream and then tear down main link.
>>>> However there are rare cases, such as in the middle of system
>>>> suspending,
>>>> that uevent could not be delivered to user space framework. Therefore
>>>> some kind of recover mechanism armed by timer need to be in place in the
>>>> case of user space framework does not respond to uevent.
>>> Hmm, how does userpsace 'respond' to the uevent? The driver should
>>> send hotplug notifications to userspace, but it must not expect any
>>> particular reaction. The userspace might be as simple, as fbdev
>>> emulation, but the driver still should function correctly.
>> yes, driver is function correctly by setting up main link. but it does
>> not know which resolution to display.
>>
>> It send hotplug notification through uevent to framework after main link
>> is ready.
>>
>> Framework  is responsible to set up MDP timing engine to start video stream.
>>
>>
>> However it does not know which
> It's of no concern to the driver. It is completely the userspace
> problem. After resuming, it should reread available video output
> properties. The display could have been changed while the system is
> suspended.
>  From your description I still do not understand why you need the
> 'recovery' mechanism.

I mean "recovery" means  dp driver may leave stay at link ready 
mistakenly after dongle unplugged due to missing framework action to 
tear down main link so that next dongle plug in will not work.

Currently it was armed with timeout function and it will fired if 
framework did not call msm_dp_display_disable() after 5 second.

Anyway, we think this approach is not good. therefore it is replaced 
with  below patch.

drm/msm/dp: tear down main link at unplug handle immediately



  reply	other threads:[~2022-04-14 22:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-06 21:28 Kuogee Hsieh
2022-04-08 12:27 ` Dmitry Baryshkov
2022-04-08 20:30   ` Kuogee Hsieh
2022-04-08 23:59     ` Dmitry Baryshkov
2022-04-14 22:06       ` Kuogee Hsieh [this message]
2022-04-14 23:34         ` Dmitry Baryshkov
2022-04-16  0:06           ` Kuogee Hsieh
2022-04-20 22:58             ` Stephen Boyd
2022-04-20 23:57               ` Kuogee Hsieh
2022-04-14  0:02 ` Stephen Boyd
2022-04-14 16:34   ` Kuogee Hsieh
2022-04-14 19:36     ` Stephen Boyd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2039ef97-4fdb-bffe-1e02-18ae79c18be4@quicinc.com \
    --to=quic_khsieh@quicinc.com \
    --cc=agross@kernel.org \
    --cc=airlied@linux.ie \
    --cc=bjorn.andersson@linaro.org \
    --cc=daniel@ffwll.ch \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_abhinavk@quicinc.com \
    --cc=quic_aravindh@quicinc.com \
    --cc=quic_sbillaka@quicinc.com \
    --cc=robdclark@gmail.com \
    --cc=sean@poorly.run \
    --cc=swboyd@chromium.org \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®