All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <swboyd@chromium.org>
To: Kuogee Hsieh <quic_khsieh@quicinc.com>,
	agross@kernel.org, airlied@linux.ie, bjorn.andersson@linaro.org,
	daniel@ffwll.ch, dmitry.baryshkov@linaro.org,
	 dri-devel@lists.freedesktop.org, robdclark@gmail.com,
	sean@poorly.run,  vkoul@kernel.org
Cc: quic_sbillaka@quicinc.com, linux-arm-msm@vger.kernel.org,
	quic_abhinavk@quicinc.com, linux-kernel@vger.kernel.org,
	aravindh@codeaurora.org, freedreno@lists.freedesktop.org
Subject: Re: [PATCH v11 1/4] drm/msm/dp: do not initialize phy until plugin interrupt received
Date: Wed, 12 Jan 2022 12:00:45 -0800	[thread overview]
Message-ID: <CAE-0n53hrPYR3ThwxM_+fzyRSB+6W1drFymW5n_RKmg_gf8z-w@mail.gmail.com> (raw)
In-Reply-To: <1641926606-1012-2-git-send-email-quic_khsieh@quicinc.com>

Quoting Kuogee Hsieh (2022-01-11 10:43:23)
> Current DP drivers have regulators, clocks, irq and phy are grouped
> together within a function and executed not in a symmetric manner.
> This increase difficulty of code maintenance and limited code scalability.
> This patch divides the driver life cycle of operation into four states,
> resume (including booting up), dongle plugin, dongle unplugged and suspend.
> Regulators, core clocks and irq are grouped together and enabled at resume
> (or booting up) so that the DP controller is armed and ready to receive HPD
> plugin interrupts. HPD plugin interrupt is generated when a dongle plugs
> into DUT (device under test). Once HPD plugin interrupt is received, DP
> controller will initialize phy so that dpcd read/write will function and
> following link training can be proceeded successfully. DP phy will be
> disabled after main link is teared down at end of unplugged HPD interrupt
> handle triggered by dongle unplugged out of DUT. Finally regulators, code
> clocks and irq are disabled at corresponding suspension.

I'll write out the various scenarios

#1
	dongle plugged in with HDMI cable attached
	driver probe

#2
	dongle unplugged
	driver probe

#3
	dongle plugged in without HDMI cable attached
	driver probe

#4
	driver probe
	dongle plugged in without HDMI cable attached


#5
	driver probe
	dongle plugged in with HDMI cable attached

#6
	driver probe
	dongle plugged in
	suspend
	resume

#7
	driver probe
	dongle plugged in
	suspend
	dongle unplugged
	resume

#8
	driver probe
	dongle plugged in without HDMI cable attached
	suspend
	resume

#9
	driver probe
	dongle plugged in without HDMI cable attached
	suspend
	HDMI cable attached during suspend
	resume

What's the state of the phy and core initialized variable at the end of
each of these scenarios? Please fill out the truth table.

		  +-----------------+------------------------
                  |    false        |       true            |
		  +-----------------+------------------------
 phy_initialized  |                 |                       |
		  +-----------------+------------------------
 core_initialized |                 | #1,                   |
		  +-----------------+------------------------

I guess we also need eDP scenarios, but that's probably simpler

#10
	eDP panel connected
	driver probe

#11
	eDP panel disconnected
	driver probe

#12
	eDP panel disconnected
	driver probe
	suspend
	resume

> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
> index 7cc4d21..f6bb4bc 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -83,6 +83,7 @@ struct dp_display_private {
>
>         /* state variables */
>         bool core_initialized;
> +       bool phy_initialized;
>         bool hpd_irq_on;
>         bool audio_supported;
>
> @@ -372,21 +373,46 @@ static int dp_display_process_hpd_high(struct dp_display_private *dp)
>         return rc;
>  }
>
> -static void dp_display_host_init(struct dp_display_private *dp, int reset)
> +static void dp_display_host_phy_init(struct dp_display_private *dp)
>  {
> -       bool flip = false;
> +       DRM_DEBUG_DP("core_init=%d phy_init=%d\n",
> +                       dp->core_initialized, dp->phy_initialized);
>
> +       if (!dp->phy_initialized) {
> +               dp_ctrl_phy_init(dp->ctrl);
> +               dp->phy_initialized = true;
> +       }
> +}
> +
> +static void dp_display_host_phy_exit(struct dp_display_private *dp)
> +{
> +       DRM_DEBUG_DP("core_init=%d phy_init=%d\n",
> +                       dp->core_initialized, dp->phy_initialized);
> +
> +       if (dp->phy_initialized) {
> +               dp_ctrl_phy_exit(dp->ctrl);
> +               dp->phy_initialized = false;
> +       }
> +}
> +
> +static void dp_display_host_init(struct dp_display_private *dp)
> +{
>         DRM_DEBUG_DP("core_initialized=%d\n", dp->core_initialized);
>         if (dp->core_initialized) {
>                 DRM_DEBUG_DP("DP core already initialized\n");
>                 return;
>         }
>
> -       if (dp->usbpd->orientation == ORIENTATION_CC2)
> -               flip = true;
> +       dp_power_init(dp->power, false);
> +       dp_ctrl_reset_irq_ctrl(dp->ctrl, true);
> +
> +       /*
> +        * eDP is the embedded primary display and has its own phy
> +        * initialize phy immediately

Question still stands why we can't wait for hpd high from the eDP panel.
Also, I think "has its own phy" means that it's not part of a combo
USB+DP phy? Can you please clarify?

> +        */
> +       if (dp->dp_display.connector_type == DRM_MODE_CONNECTOR_eDP)
> +               dp_display_host_phy_init(dp);
>
> -       dp_power_init(dp->power, flip);
> -       dp_ctrl_host_init(dp->ctrl, flip, reset);
>         dp_aux_init(dp->aux);
>         dp->core_initialized = true;
>  }
> @@ -1306,20 +1330,23 @@ static int dp_pm_resume(struct device *dev)
>         dp->hpd_state = ST_DISCONNECTED;
>
>         /* turn on dp ctrl/phy */
> -       dp_display_host_init(dp, true);
> +       dp_display_host_init(dp);
>
>         dp_catalog_ctrl_hpd_config(dp->catalog);
>
> -       /*
> -        * set sink to normal operation mode -- D0
> -        * before dpcd read
> -        */
> -       dp_link_psm_config(dp->link, &dp->panel->link_info, false);
>
>         if (dp_catalog_link_is_connected(dp->catalog)) {
> +               /*
> +                * set sink to normal operation mode -- D0
> +                * before dpcd read
> +                */
> +               dp_display_host_phy_init(dp);
> +               dp_link_psm_config(dp->link, &dp->panel->link_info, false);
>                 sink_count = drm_dp_read_sink_count(dp->aux);
>                 if (sink_count < 0)
>                         sink_count = 0;
> +
> +               dp_display_host_phy_exit(dp);

Why is the phy exited on resume when the link is still connected? Is
this supposed to be done only when the sink_count is 0? And how does
this interact with eDP where the phy is initialized by the call to
dp_display_host_init() earlier in this function.

>         }
>
>         dp->link->sink_count = sink_count;
> @@ -1366,6 +1393,8 @@ static int dp_pm_suspend(struct device *dev)
>                 dp_display_host_deinit(dp);
>         }
>
> +       dp_display_host_phy_exit(dp);
> +
>         dp->hpd_state = ST_SUSPENDED;
>
>         /* host_init will be called at pm_resume */

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <swboyd@chromium.org>
To: Kuogee Hsieh <quic_khsieh@quicinc.com>,
	agross@kernel.org, airlied@linux.ie, bjorn.andersson@linaro.org,
	daniel@ffwll.ch, dmitry.baryshkov@linaro.org,
	dri-devel@lists.freedesktop.org, robdclark@gmail.com,
	sean@poorly.run, vkoul@kernel.org
Cc: quic_abhinavk@quicinc.com, aravindh@codeaurora.org,
	quic_sbillaka@quicinc.com, freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v11 1/4] drm/msm/dp: do not initialize phy until plugin interrupt received
Date: Wed, 12 Jan 2022 12:00:45 -0800	[thread overview]
Message-ID: <CAE-0n53hrPYR3ThwxM_+fzyRSB+6W1drFymW5n_RKmg_gf8z-w@mail.gmail.com> (raw)
In-Reply-To: <1641926606-1012-2-git-send-email-quic_khsieh@quicinc.com>

Quoting Kuogee Hsieh (2022-01-11 10:43:23)
> Current DP drivers have regulators, clocks, irq and phy are grouped
> together within a function and executed not in a symmetric manner.
> This increase difficulty of code maintenance and limited code scalability.
> This patch divides the driver life cycle of operation into four states,
> resume (including booting up), dongle plugin, dongle unplugged and suspend.
> Regulators, core clocks and irq are grouped together and enabled at resume
> (or booting up) so that the DP controller is armed and ready to receive HPD
> plugin interrupts. HPD plugin interrupt is generated when a dongle plugs
> into DUT (device under test). Once HPD plugin interrupt is received, DP
> controller will initialize phy so that dpcd read/write will function and
> following link training can be proceeded successfully. DP phy will be
> disabled after main link is teared down at end of unplugged HPD interrupt
> handle triggered by dongle unplugged out of DUT. Finally regulators, code
> clocks and irq are disabled at corresponding suspension.

I'll write out the various scenarios

#1
	dongle plugged in with HDMI cable attached
	driver probe

#2
	dongle unplugged
	driver probe

#3
	dongle plugged in without HDMI cable attached
	driver probe

#4
	driver probe
	dongle plugged in without HDMI cable attached


#5
	driver probe
	dongle plugged in with HDMI cable attached

#6
	driver probe
	dongle plugged in
	suspend
	resume

#7
	driver probe
	dongle plugged in
	suspend
	dongle unplugged
	resume

#8
	driver probe
	dongle plugged in without HDMI cable attached
	suspend
	resume

#9
	driver probe
	dongle plugged in without HDMI cable attached
	suspend
	HDMI cable attached during suspend
	resume

What's the state of the phy and core initialized variable at the end of
each of these scenarios? Please fill out the truth table.

		  +-----------------+------------------------
                  |    false        |       true            |
		  +-----------------+------------------------
 phy_initialized  |                 |                       |
		  +-----------------+------------------------
 core_initialized |                 | #1,                   |
		  +-----------------+------------------------

I guess we also need eDP scenarios, but that's probably simpler

#10
	eDP panel connected
	driver probe

#11
	eDP panel disconnected
	driver probe

#12
	eDP panel disconnected
	driver probe
	suspend
	resume

> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
> index 7cc4d21..f6bb4bc 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -83,6 +83,7 @@ struct dp_display_private {
>
>         /* state variables */
>         bool core_initialized;
> +       bool phy_initialized;
>         bool hpd_irq_on;
>         bool audio_supported;
>
> @@ -372,21 +373,46 @@ static int dp_display_process_hpd_high(struct dp_display_private *dp)
>         return rc;
>  }
>
> -static void dp_display_host_init(struct dp_display_private *dp, int reset)
> +static void dp_display_host_phy_init(struct dp_display_private *dp)
>  {
> -       bool flip = false;
> +       DRM_DEBUG_DP("core_init=%d phy_init=%d\n",
> +                       dp->core_initialized, dp->phy_initialized);
>
> +       if (!dp->phy_initialized) {
> +               dp_ctrl_phy_init(dp->ctrl);
> +               dp->phy_initialized = true;
> +       }
> +}
> +
> +static void dp_display_host_phy_exit(struct dp_display_private *dp)
> +{
> +       DRM_DEBUG_DP("core_init=%d phy_init=%d\n",
> +                       dp->core_initialized, dp->phy_initialized);
> +
> +       if (dp->phy_initialized) {
> +               dp_ctrl_phy_exit(dp->ctrl);
> +               dp->phy_initialized = false;
> +       }
> +}
> +
> +static void dp_display_host_init(struct dp_display_private *dp)
> +{
>         DRM_DEBUG_DP("core_initialized=%d\n", dp->core_initialized);
>         if (dp->core_initialized) {
>                 DRM_DEBUG_DP("DP core already initialized\n");
>                 return;
>         }
>
> -       if (dp->usbpd->orientation == ORIENTATION_CC2)
> -               flip = true;
> +       dp_power_init(dp->power, false);
> +       dp_ctrl_reset_irq_ctrl(dp->ctrl, true);
> +
> +       /*
> +        * eDP is the embedded primary display and has its own phy
> +        * initialize phy immediately

Question still stands why we can't wait for hpd high from the eDP panel.
Also, I think "has its own phy" means that it's not part of a combo
USB+DP phy? Can you please clarify?

> +        */
> +       if (dp->dp_display.connector_type == DRM_MODE_CONNECTOR_eDP)
> +               dp_display_host_phy_init(dp);
>
> -       dp_power_init(dp->power, flip);
> -       dp_ctrl_host_init(dp->ctrl, flip, reset);
>         dp_aux_init(dp->aux);
>         dp->core_initialized = true;
>  }
> @@ -1306,20 +1330,23 @@ static int dp_pm_resume(struct device *dev)
>         dp->hpd_state = ST_DISCONNECTED;
>
>         /* turn on dp ctrl/phy */
> -       dp_display_host_init(dp, true);
> +       dp_display_host_init(dp);
>
>         dp_catalog_ctrl_hpd_config(dp->catalog);
>
> -       /*
> -        * set sink to normal operation mode -- D0
> -        * before dpcd read
> -        */
> -       dp_link_psm_config(dp->link, &dp->panel->link_info, false);
>
>         if (dp_catalog_link_is_connected(dp->catalog)) {
> +               /*
> +                * set sink to normal operation mode -- D0
> +                * before dpcd read
> +                */
> +               dp_display_host_phy_init(dp);
> +               dp_link_psm_config(dp->link, &dp->panel->link_info, false);
>                 sink_count = drm_dp_read_sink_count(dp->aux);
>                 if (sink_count < 0)
>                         sink_count = 0;
> +
> +               dp_display_host_phy_exit(dp);

Why is the phy exited on resume when the link is still connected? Is
this supposed to be done only when the sink_count is 0? And how does
this interact with eDP where the phy is initialized by the call to
dp_display_host_init() earlier in this function.

>         }
>
>         dp->link->sink_count = sink_count;
> @@ -1366,6 +1393,8 @@ static int dp_pm_suspend(struct device *dev)
>                 dp_display_host_deinit(dp);
>         }
>
> +       dp_display_host_phy_exit(dp);
> +
>         dp->hpd_state = ST_SUSPENDED;
>
>         /* host_init will be called at pm_resume */

  reply	other threads:[~2022-01-12 20:00 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-11 18:43 [PATCH v11 0/4] group dp driver related patches into one series Kuogee Hsieh
2022-01-11 18:43 ` Kuogee Hsieh
2022-01-11 18:43 ` [PATCH v11 1/4] drm/msm/dp: do not initialize phy until plugin interrupt received Kuogee Hsieh
2022-01-11 18:43   ` Kuogee Hsieh
2022-01-12 20:00   ` Stephen Boyd [this message]
2022-01-12 20:00     ` Stephen Boyd
2022-01-12 22:17     ` Kuogee Hsieh
2022-01-12 22:17       ` Kuogee Hsieh
2022-01-13  4:13       ` Stephen Boyd
2022-01-13  4:13         ` Stephen Boyd
2022-01-13 17:51         ` Kuogee Hsieh
2022-01-13 17:51           ` Kuogee Hsieh
2022-01-13 19:47           ` Stephen Boyd
2022-01-13 19:47             ` Stephen Boyd
2022-01-13 20:44             ` Kuogee Hsieh
2022-01-13 20:44               ` Kuogee Hsieh
2022-01-13 21:52               ` Stephen Boyd
2022-01-13 21:52                 ` Stephen Boyd
2022-01-13 22:14                 ` Kuogee Hsieh
2022-01-13 22:14                   ` Kuogee Hsieh
2022-01-13 23:13                   ` Stephen Boyd
2022-01-13 23:13                     ` Stephen Boyd
2022-01-11 18:43 ` [PATCH v11 2/4] drm/msm/dp: populate connector of struct dp_panel Kuogee Hsieh
2022-01-11 18:43   ` Kuogee Hsieh
2022-01-11 18:43 ` [PATCH v11 3/4] drm/msm/dp: add support of tps4 (training pattern 4) for HBR3 Kuogee Hsieh
2022-01-11 18:43   ` Kuogee Hsieh
2022-01-11 18:43 ` [PATCH v11 4/4] drm/msm/dp: stop link training after link training 2 failed Kuogee Hsieh
2022-01-11 18:43   ` Kuogee Hsieh

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=CAE-0n53hrPYR3ThwxM_+fzyRSB+6W1drFymW5n_RKmg_gf8z-w@mail.gmail.com \
    --to=swboyd@chromium.org \
    --cc=agross@kernel.org \
    --cc=airlied@linux.ie \
    --cc=aravindh@codeaurora.org \
    --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_khsieh@quicinc.com \
    --cc=quic_sbillaka@quicinc.com \
    --cc=robdclark@gmail.com \
    --cc=sean@poorly.run \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.