From: "Sankeerth Billakanti (QUIC)" <quic_sbillaka@quicinc.com>
To: "Bjorn Andersson (QUIC)" <quic_bjorande@quicinc.com>
Cc: "dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
"freedreno@lists.freedesktop.org"
<freedreno@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"robdclark@gmail.com" <robdclark@gmail.com>,
"seanpaul@chromium.org" <seanpaul@chromium.org>,
"swboyd@chromium.org" <swboyd@chromium.org>,
"Kalyan Thota (QUIC)" <quic_kalyant@quicinc.com>,
"Abhinav Kumar (QUIC)" <quic_abhinavk@quicinc.com>,
"dianders@chromium.org" <dianders@chromium.org>,
"Kuogee Hsieh (QUIC)" <quic_khsieh@quicinc.com>,
"sean@poorly.run" <sean@poorly.run>,
"airlied@linux.ie" <airlied@linux.ie>,
"daniel@ffwll.ch" <daniel@ffwll.ch>,
"dmitry.baryshkov@linaro.org" <dmitry.baryshkov@linaro.org>,
"Vishnuvardhan Prodduturi (QUIC)" <quic_vproddut@quicinc.com>
Subject: RE: [RFC PATCH 2/2] drm/msm/dp: enable pm_runtime support for dp driver
Date: Wed, 1 Mar 2023 08:19:14 +0000 [thread overview]
Message-ID: <511d7b597b68441d8596dcb51ff18a5d@quicinc.com> (raw)
In-Reply-To: <20230227233641.GC4062527@hu-bjorande-lv.qualcomm.com>
>> diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c
>> b/drivers/gpu/drm/msm/dp/dp_aux.c
>[..]
>> +static int dp_runtime_resume(struct device *dev) {
>> + struct platform_device *pdev = to_platform_device(dev);
>> + struct msm_dp *dp_display = platform_get_drvdata(pdev);
>> + struct dp_display_private *dp;
>> +
>> + dp = container_of(dp_display, struct dp_display_private, dp_display);
>> + dp_display_host_init(dp);
>> +
>> + if (dp->dp_display.is_edp) {
>> + dp_display_host_phy_init(dp);
>> + } else {
>> + dp_catalog_hpd_config_intr(dp->catalog,
>> + DP_DP_HPD_PLUG_INT_MASK |
>> + DP_DP_HPD_UNPLUG_INT_MASK,
>> + true);
>
>I believe this is backwards.
>
>Only in the event that there's no "downstream" HPD handler should we use
>the internal HPD. This is signalled by the DRM framework by a call to
>dp_bridge_hpd_enable(). So we should use that to enable/disable the
>internal HPD handler.
>
>When this happens, we have a reason for keeping power on; i.e. call
>pm_runtime_get(). Once we have power/clocking, we'd call
>dp_catalog_hpd_config_intr(), from dp_bridge_hpd_enable().
>
>
>In the case that the internal HPD handling is not use,
>dp_bridge_hpd_enable() will not be called, instead once the downstream hpd
>handler switches state dp_bridge_hpd_notify() will be invoked.
>
>In this case, we need the DP controller to be powered/clocked between
>connector_status_connected and connector_status_disconnected.
>
>
>I believe this should allow the DP controller(s) to stay powered down in the
>case where we have external HPD handling (e.g. USB Type-C or gpio-based
>dp-connector).
>
>Regards,
>Bjorn
I agree with the approach. I am moving my dev to msm-next. Will make the changes according to the HPD handling and repost
Thank you,
Sankeerth
WARNING: multiple messages have this Message-ID (diff)
From: "Sankeerth Billakanti (QUIC)" <quic_sbillaka@quicinc.com>
To: "Bjorn Andersson (QUIC)" <quic_bjorande@quicinc.com>
Cc: "Kalyan Thota \(QUIC\)" <quic_kalyant@quicinc.com>,
"dianders@chromium.org" <dianders@chromium.org>,
"Abhinav Kumar \(QUIC\)" <quic_abhinavk@quicinc.com>,
"Vishnuvardhan Prodduturi \(QUIC\)" <quic_vproddut@quicinc.com>,
"airlied@linux.ie" <airlied@linux.ie>,
"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"swboyd@chromium.org" <swboyd@chromium.org>,
"sean@poorly.run" <sean@poorly.run>,
"seanpaul@chromium.org" <seanpaul@chromium.org>,
"dmitry.baryshkov@linaro.org" <dmitry.baryshkov@linaro.org>,
"Kuogee Hsieh \(QUIC\)" <quic_khsieh@quicinc.com>,
"freedreno@lists.freedesktop.org"
<freedreno@lists.freedesktop.org>
Subject: RE: [RFC PATCH 2/2] drm/msm/dp: enable pm_runtime support for dp driver
Date: Wed, 1 Mar 2023 08:19:14 +0000 [thread overview]
Message-ID: <511d7b597b68441d8596dcb51ff18a5d@quicinc.com> (raw)
In-Reply-To: <20230227233641.GC4062527@hu-bjorande-lv.qualcomm.com>
>> diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c
>> b/drivers/gpu/drm/msm/dp/dp_aux.c
>[..]
>> +static int dp_runtime_resume(struct device *dev) {
>> + struct platform_device *pdev = to_platform_device(dev);
>> + struct msm_dp *dp_display = platform_get_drvdata(pdev);
>> + struct dp_display_private *dp;
>> +
>> + dp = container_of(dp_display, struct dp_display_private, dp_display);
>> + dp_display_host_init(dp);
>> +
>> + if (dp->dp_display.is_edp) {
>> + dp_display_host_phy_init(dp);
>> + } else {
>> + dp_catalog_hpd_config_intr(dp->catalog,
>> + DP_DP_HPD_PLUG_INT_MASK |
>> + DP_DP_HPD_UNPLUG_INT_MASK,
>> + true);
>
>I believe this is backwards.
>
>Only in the event that there's no "downstream" HPD handler should we use
>the internal HPD. This is signalled by the DRM framework by a call to
>dp_bridge_hpd_enable(). So we should use that to enable/disable the
>internal HPD handler.
>
>When this happens, we have a reason for keeping power on; i.e. call
>pm_runtime_get(). Once we have power/clocking, we'd call
>dp_catalog_hpd_config_intr(), from dp_bridge_hpd_enable().
>
>
>In the case that the internal HPD handling is not use,
>dp_bridge_hpd_enable() will not be called, instead once the downstream hpd
>handler switches state dp_bridge_hpd_notify() will be invoked.
>
>In this case, we need the DP controller to be powered/clocked between
>connector_status_connected and connector_status_disconnected.
>
>
>I believe this should allow the DP controller(s) to stay powered down in the
>case where we have external HPD handling (e.g. USB Type-C or gpio-based
>dp-connector).
>
>Regards,
>Bjorn
I agree with the approach. I am moving my dev to msm-next. Will make the changes according to the HPD handling and repost
Thank you,
Sankeerth
next prev parent reply other threads:[~2023-03-01 8:19 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-23 13:56 [RFC PATCH 0/2] drm/msm/dp: refactor the msm dp driver resources Sankeerth Billakanti
2023-02-23 13:56 ` Sankeerth Billakanti
2023-02-23 13:56 ` [RFC PATCH 1/2] drm/msm/dp: enumerate edp panel during driver probe Sankeerth Billakanti
2023-02-23 13:56 ` Sankeerth Billakanti
2023-02-23 14:59 ` Dmitry Baryshkov
2023-02-23 14:59 ` Dmitry Baryshkov
2023-03-01 8:13 ` Sankeerth Billakanti (QUIC)
2023-03-01 8:13 ` Sankeerth Billakanti (QUIC)
2023-03-01 10:37 ` Dmitry Baryshkov
2023-03-01 10:37 ` Dmitry Baryshkov
2023-03-14 10:23 ` Sankeerth Billakanti (QUIC)
2023-03-14 10:23 ` Sankeerth Billakanti (QUIC)
2023-03-14 11:34 ` Dmitry Baryshkov
2023-03-14 11:34 ` Dmitry Baryshkov
2023-02-23 13:56 ` [RFC PATCH 2/2] drm/msm/dp: enable pm_runtime support for dp driver Sankeerth Billakanti
2023-02-23 13:56 ` Sankeerth Billakanti
2023-02-23 17:09 ` kernel test robot
2023-02-27 23:36 ` Bjorn Andersson
2023-02-27 23:36 ` Bjorn Andersson
2023-03-01 8:19 ` Sankeerth Billakanti (QUIC) [this message]
2023-03-01 8:19 ` Sankeerth Billakanti (QUIC)
2023-02-23 15:18 ` [RFC PATCH 0/2] drm/msm/dp: refactor the msm dp driver resources Dmitry Baryshkov
2023-02-23 15:18 ` Dmitry Baryshkov
2023-03-01 8:17 ` Sankeerth Billakanti (QUIC)
2023-03-01 8:17 ` Sankeerth Billakanti (QUIC)
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=511d7b597b68441d8596dcb51ff18a5d@quicinc.com \
--to=quic_sbillaka@quicinc.com \
--cc=airlied@linux.ie \
--cc=daniel@ffwll.ch \
--cc=dianders@chromium.org \
--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_bjorande@quicinc.com \
--cc=quic_kalyant@quicinc.com \
--cc=quic_khsieh@quicinc.com \
--cc=quic_vproddut@quicinc.com \
--cc=robdclark@gmail.com \
--cc=sean@poorly.run \
--cc=seanpaul@chromium.org \
--cc=swboyd@chromium.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.