All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Kuogee Hsieh <quic_khsieh@quicinc.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Rob Clark <robdclark@gmail.com>, Sean Paul <sean@poorly.run>,
	Abhinav Kumar <quic_abhinavk@quicinc.com>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	Stephen Boyd <swboyd@chromium.org>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	intel-gfx@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
	freedreno@lists.freedesktop.org, linux-usb@vger.kernel.org
Subject: Re: [PATCH v4 5/5] drm/msm/dp: Implement hpd_notify()
Date: Mon, 2 May 2022 16:02:59 -0700	[thread overview]
Message-ID: <YnBjI1HyL//X4KOn@ripper> (raw)
In-Reply-To: <YnBbNO31bwNUoRQL@ripper>

On Mon 02 May 15:29 PDT 2022, Bjorn Andersson wrote:

> On Mon 02 May 13:59 PDT 2022, Kuogee Hsieh wrote:
> 
> > 
> > On 5/2/2022 9:53 AM, Bjorn Andersson wrote:
> > > The Qualcomm DisplayPort driver contains traces of the necessary
> > > plumbing to hook up USB HPD, in the form of the dp_hpd module and the
> > > dp_usbpd_cb struct. Use this as basis for implementing the
> > > hpd_notify() callback, by amending the dp_hpd module with the
> > > missing logic.
> > > 
> > > Overall the solution is similar to what's done downstream, but upstream
> > > all the code to disect the HPD notification lives on the calling side of
> > > drm_connector_oob_hotplug_event().
> > > 
> > > drm_connector_oob_hotplug_event() performs the lookup of the
> > > drm_connector based on fwnode, hence the need to assign the fwnode in
> > > dp_drm_connector_init().
> > > 
> > > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > > ---
> > > 
> > > Changes since v3:
> > > - Implements hpd_notify instead of oob_hotplug_event
> > > - Rebased on new cleanup patch from Dmitry
> > > - Set hpd_state to ST_MAINLINK_READY when dp_display_usbpd_configure() succeeds
> > > 
> > >   drivers/gpu/drm/msm/dp/dp_display.c | 26 ++++++++++++++++++++++++++
> > >   drivers/gpu/drm/msm/dp/dp_display.h |  1 +
> > >   drivers/gpu/drm/msm/dp/dp_drm.c     |  3 +++
> > >   drivers/gpu/drm/msm/dp/dp_drm.h     |  2 ++
> > >   4 files changed, 32 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
> > > index b447446d75e9..080294ac6144 100644
> > > --- a/drivers/gpu/drm/msm/dp/dp_display.c
> > > +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> > > @@ -83,6 +83,8 @@ struct dp_display_private {
> > >   	bool hpd_irq_on;
> > >   	bool audio_supported;
> > > +	bool connected;
> > > +
> > >   	struct drm_device *drm_dev;
> > >   	struct platform_device *pdev;
> > >   	struct dentry *root;
> > > @@ -1271,6 +1273,7 @@ static int dp_display_probe(struct platform_device *pdev)
> > >   	if (!desc)
> > >   		return -EINVAL;
> > > +	dp->dp_display.dev = &pdev->dev;
> > >   	dp->pdev = pdev;
> > >   	dp->name = "drm_dp";
> > >   	dp->dp_display.connector_type = desc->connector_type;
> > > @@ -1760,3 +1763,26 @@ void dp_bridge_mode_set(struct drm_bridge *drm_bridge,
> > >   	dp_display->dp_mode.h_active_low =
> > >   		!!(dp_display->dp_mode.drm_mode.flags & DRM_MODE_FLAG_NHSYNC);
> > >   }
> > > +
> > > +void dp_bridge_hpd_notify(struct drm_bridge *bridge,
> > > +			  enum drm_connector_status status)
> > > +{
> > > +	struct msm_dp_bridge *dp_bridge = to_dp_bridge(bridge);
> > > +	struct msm_dp *dp = dp_bridge->dp_display;
> > > +	struct dp_display_private *dp_display = container_of(dp, struct dp_display_private, dp_display);
> > > +	int ret;
> > > +
> > > +	drm_dbg_dp(dp_display->drm_dev, "status: %d connected: %d\n", status, dp_display->connected);
> > > +
> > > +	if (!dp_display->connected && status == connector_status_connected) {
> > > +		dp_display->connected = true;
> > > +		ret = dp_display_usbpd_configure(dp_display);
> > > +		if (!ret)
> > > +			dp_display->hpd_state = ST_MAINLINK_READY;
> > > +	} else if (status != connector_status_connected) {
> > > +		dp_display->connected = false;
> > > +		dp_display_notify_disconnect(dp_display);
> > > +	} else {
> > > +		dp_display_usbpd_attention(dp_display);
> > > +	}
> > > +}
> > 
> > I would assume dp_bridge_hpd_notify() will server same purpose as
> > dp_display_irq_handler() if hpd_notification is enabled.
> > 
> 
> I agree with this statement.
> 
> > In that case, should dp_bridge_hpd_notify() add
> > EV_HPD_PLUG_INT/EV_IRQ_HPD_INT/EV_HPD_UNPLUG_INT
> > 
> 
> I tried this originally, but couldn't get it to work and expected that
> as the downstream driver doesn't do this, there was some good reason for
> me not to do it either.
> 
> > into event q to kick off corresponding
> > dp_hpd_plug_handle()/dp_irq_hpd_handle()/dp_hpd_unplug_handle()?
> > 
> 
> But since then the driver has been cleaned up significantly, so I
> decided to give it a test again.
> Unfortunately it still doesn't work, but now it's easier to trace.
> 
> Replacing the 3 cases with relevant calls to dp_add_event() results in
> us inserting a EV_HPD_UNPLUG_INT event really early, before things has
> been brought up. This will result in dp_hpd_unplug_handle() trying to
> disable the dp_catalog_hpd_config_intr(), which will crash as the
> hardware isn't yet clocked up.
> 

As I sent that I realized and have now confirmed that if I get a HPD
connect before dp_display_host_init() things will not be in an
appropriate state to either and the board will crash...

I will dig a little bit more to see what we can do about this.

Regards,
Bjorn

> Further more, this points out the main difference between the normal HPD
> code and the USB HPD code; dp_catalog_hpd_config_intr() will enable the
> plug/unplug interrupts, which it shouldn't do for USB-controlled.
> 
> 
> So it seems we need two code paths after all.
> 
> > By the way, I am going to test this patch out.
> > 
> > Any patches I have to pull in before apply this serial patches?
> > 
> 
> The patches applies on Dmitry's msm-next-staging, which I've merged on
> top of linux-next together with a number of pending patches to get the
> DPU up on SM8350 and a pmic_glink driver which I'm about to post.
> 
> But to validate that it doesn't affect your non-USB case, Dmitry's
> branch should be sufficient.
> 
> Thanks,
> Bjorn
> 
> > > diff --git a/drivers/gpu/drm/msm/dp/dp_display.h b/drivers/gpu/drm/msm/dp/dp_display.h
> > > index 4f9fe4d7610b..2d2614bc5a14 100644
> > > --- a/drivers/gpu/drm/msm/dp/dp_display.h
> > > +++ b/drivers/gpu/drm/msm/dp/dp_display.h
> > > @@ -11,6 +11,7 @@
> > >   #include "disp/msm_disp_snapshot.h"
> > >   struct msm_dp {
> > > +	struct device *dev;
> > >   	struct drm_device *drm_dev;
> > >   	struct device *codec_dev;
> > >   	struct drm_bridge *bridge;
> > > diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c b/drivers/gpu/drm/msm/dp/dp_drm.c
> > > index 62d58b9c4647..821cfd37b1fb 100644
> > > --- a/drivers/gpu/drm/msm/dp/dp_drm.c
> > > +++ b/drivers/gpu/drm/msm/dp/dp_drm.c
> > > @@ -68,6 +68,7 @@ static const struct drm_bridge_funcs dp_bridge_ops = {
> > >   	.mode_valid   = dp_bridge_mode_valid,
> > >   	.get_modes    = dp_bridge_get_modes,
> > >   	.detect       = dp_bridge_detect,
> > > +	.hpd_notify   = dp_bridge_hpd_notify,
> > >   };
> > >   struct drm_bridge *dp_bridge_init(struct msm_dp *dp_display, struct drm_device *dev,
> > > @@ -138,6 +139,8 @@ struct drm_connector *dp_drm_connector_init(struct msm_dp *dp_display)
> > >   	if (IS_ERR(connector))
> > >   		return connector;
> > > +	connector->fwnode = fwnode_handle_get(dev_fwnode(dp_display->dev));
> > > +
> > >   	drm_connector_attach_encoder(connector, dp_display->encoder);
> > >   	return connector;
> > > diff --git a/drivers/gpu/drm/msm/dp/dp_drm.h b/drivers/gpu/drm/msm/dp/dp_drm.h
> > > index f4b1ed1e24f7..3b7480a86844 100644
> > > --- a/drivers/gpu/drm/msm/dp/dp_drm.h
> > > +++ b/drivers/gpu/drm/msm/dp/dp_drm.h
> > > @@ -32,5 +32,7 @@ enum drm_mode_status dp_bridge_mode_valid(struct drm_bridge *bridge,
> > >   void dp_bridge_mode_set(struct drm_bridge *drm_bridge,
> > >   			const struct drm_display_mode *mode,
> > >   			const struct drm_display_mode *adjusted_mode);
> > > +void dp_bridge_hpd_notify(struct drm_bridge *bridge,
> > > +			  enum drm_connector_status status);
> > >   #endif /* _DP_DRM_H_ */

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Kuogee Hsieh <quic_khsieh@quicinc.com>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	David Airlie <airlied@linux.ie>,
	dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
	intel-gfx@lists.freedesktop.org,
	Abhinav Kumar <quic_abhinavk@quicinc.com>,
	Stephen Boyd <swboyd@chromium.org>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Sean Paul <sean@poorly.run>,
	Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	freedreno@lists.freedesktop.org
Subject: Re: [PATCH v4 5/5] drm/msm/dp: Implement hpd_notify()
Date: Mon, 2 May 2022 16:02:59 -0700	[thread overview]
Message-ID: <YnBjI1HyL//X4KOn@ripper> (raw)
In-Reply-To: <YnBbNO31bwNUoRQL@ripper>

On Mon 02 May 15:29 PDT 2022, Bjorn Andersson wrote:

> On Mon 02 May 13:59 PDT 2022, Kuogee Hsieh wrote:
> 
> > 
> > On 5/2/2022 9:53 AM, Bjorn Andersson wrote:
> > > The Qualcomm DisplayPort driver contains traces of the necessary
> > > plumbing to hook up USB HPD, in the form of the dp_hpd module and the
> > > dp_usbpd_cb struct. Use this as basis for implementing the
> > > hpd_notify() callback, by amending the dp_hpd module with the
> > > missing logic.
> > > 
> > > Overall the solution is similar to what's done downstream, but upstream
> > > all the code to disect the HPD notification lives on the calling side of
> > > drm_connector_oob_hotplug_event().
> > > 
> > > drm_connector_oob_hotplug_event() performs the lookup of the
> > > drm_connector based on fwnode, hence the need to assign the fwnode in
> > > dp_drm_connector_init().
> > > 
> > > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > > ---
> > > 
> > > Changes since v3:
> > > - Implements hpd_notify instead of oob_hotplug_event
> > > - Rebased on new cleanup patch from Dmitry
> > > - Set hpd_state to ST_MAINLINK_READY when dp_display_usbpd_configure() succeeds
> > > 
> > >   drivers/gpu/drm/msm/dp/dp_display.c | 26 ++++++++++++++++++++++++++
> > >   drivers/gpu/drm/msm/dp/dp_display.h |  1 +
> > >   drivers/gpu/drm/msm/dp/dp_drm.c     |  3 +++
> > >   drivers/gpu/drm/msm/dp/dp_drm.h     |  2 ++
> > >   4 files changed, 32 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
> > > index b447446d75e9..080294ac6144 100644
> > > --- a/drivers/gpu/drm/msm/dp/dp_display.c
> > > +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> > > @@ -83,6 +83,8 @@ struct dp_display_private {
> > >   	bool hpd_irq_on;
> > >   	bool audio_supported;
> > > +	bool connected;
> > > +
> > >   	struct drm_device *drm_dev;
> > >   	struct platform_device *pdev;
> > >   	struct dentry *root;
> > > @@ -1271,6 +1273,7 @@ static int dp_display_probe(struct platform_device *pdev)
> > >   	if (!desc)
> > >   		return -EINVAL;
> > > +	dp->dp_display.dev = &pdev->dev;
> > >   	dp->pdev = pdev;
> > >   	dp->name = "drm_dp";
> > >   	dp->dp_display.connector_type = desc->connector_type;
> > > @@ -1760,3 +1763,26 @@ void dp_bridge_mode_set(struct drm_bridge *drm_bridge,
> > >   	dp_display->dp_mode.h_active_low =
> > >   		!!(dp_display->dp_mode.drm_mode.flags & DRM_MODE_FLAG_NHSYNC);
> > >   }
> > > +
> > > +void dp_bridge_hpd_notify(struct drm_bridge *bridge,
> > > +			  enum drm_connector_status status)
> > > +{
> > > +	struct msm_dp_bridge *dp_bridge = to_dp_bridge(bridge);
> > > +	struct msm_dp *dp = dp_bridge->dp_display;
> > > +	struct dp_display_private *dp_display = container_of(dp, struct dp_display_private, dp_display);
> > > +	int ret;
> > > +
> > > +	drm_dbg_dp(dp_display->drm_dev, "status: %d connected: %d\n", status, dp_display->connected);
> > > +
> > > +	if (!dp_display->connected && status == connector_status_connected) {
> > > +		dp_display->connected = true;
> > > +		ret = dp_display_usbpd_configure(dp_display);
> > > +		if (!ret)
> > > +			dp_display->hpd_state = ST_MAINLINK_READY;
> > > +	} else if (status != connector_status_connected) {
> > > +		dp_display->connected = false;
> > > +		dp_display_notify_disconnect(dp_display);
> > > +	} else {
> > > +		dp_display_usbpd_attention(dp_display);
> > > +	}
> > > +}
> > 
> > I would assume dp_bridge_hpd_notify() will server same purpose as
> > dp_display_irq_handler() if hpd_notification is enabled.
> > 
> 
> I agree with this statement.
> 
> > In that case, should dp_bridge_hpd_notify() add
> > EV_HPD_PLUG_INT/EV_IRQ_HPD_INT/EV_HPD_UNPLUG_INT
> > 
> 
> I tried this originally, but couldn't get it to work and expected that
> as the downstream driver doesn't do this, there was some good reason for
> me not to do it either.
> 
> > into event q to kick off corresponding
> > dp_hpd_plug_handle()/dp_irq_hpd_handle()/dp_hpd_unplug_handle()?
> > 
> 
> But since then the driver has been cleaned up significantly, so I
> decided to give it a test again.
> Unfortunately it still doesn't work, but now it's easier to trace.
> 
> Replacing the 3 cases with relevant calls to dp_add_event() results in
> us inserting a EV_HPD_UNPLUG_INT event really early, before things has
> been brought up. This will result in dp_hpd_unplug_handle() trying to
> disable the dp_catalog_hpd_config_intr(), which will crash as the
> hardware isn't yet clocked up.
> 

As I sent that I realized and have now confirmed that if I get a HPD
connect before dp_display_host_init() things will not be in an
appropriate state to either and the board will crash...

I will dig a little bit more to see what we can do about this.

Regards,
Bjorn

> Further more, this points out the main difference between the normal HPD
> code and the USB HPD code; dp_catalog_hpd_config_intr() will enable the
> plug/unplug interrupts, which it shouldn't do for USB-controlled.
> 
> 
> So it seems we need two code paths after all.
> 
> > By the way, I am going to test this patch out.
> > 
> > Any patches I have to pull in before apply this serial patches?
> > 
> 
> The patches applies on Dmitry's msm-next-staging, which I've merged on
> top of linux-next together with a number of pending patches to get the
> DPU up on SM8350 and a pmic_glink driver which I'm about to post.
> 
> But to validate that it doesn't affect your non-USB case, Dmitry's
> branch should be sufficient.
> 
> Thanks,
> Bjorn
> 
> > > diff --git a/drivers/gpu/drm/msm/dp/dp_display.h b/drivers/gpu/drm/msm/dp/dp_display.h
> > > index 4f9fe4d7610b..2d2614bc5a14 100644
> > > --- a/drivers/gpu/drm/msm/dp/dp_display.h
> > > +++ b/drivers/gpu/drm/msm/dp/dp_display.h
> > > @@ -11,6 +11,7 @@
> > >   #include "disp/msm_disp_snapshot.h"
> > >   struct msm_dp {
> > > +	struct device *dev;
> > >   	struct drm_device *drm_dev;
> > >   	struct device *codec_dev;
> > >   	struct drm_bridge *bridge;
> > > diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c b/drivers/gpu/drm/msm/dp/dp_drm.c
> > > index 62d58b9c4647..821cfd37b1fb 100644
> > > --- a/drivers/gpu/drm/msm/dp/dp_drm.c
> > > +++ b/drivers/gpu/drm/msm/dp/dp_drm.c
> > > @@ -68,6 +68,7 @@ static const struct drm_bridge_funcs dp_bridge_ops = {
> > >   	.mode_valid   = dp_bridge_mode_valid,
> > >   	.get_modes    = dp_bridge_get_modes,
> > >   	.detect       = dp_bridge_detect,
> > > +	.hpd_notify   = dp_bridge_hpd_notify,
> > >   };
> > >   struct drm_bridge *dp_bridge_init(struct msm_dp *dp_display, struct drm_device *dev,
> > > @@ -138,6 +139,8 @@ struct drm_connector *dp_drm_connector_init(struct msm_dp *dp_display)
> > >   	if (IS_ERR(connector))
> > >   		return connector;
> > > +	connector->fwnode = fwnode_handle_get(dev_fwnode(dp_display->dev));
> > > +
> > >   	drm_connector_attach_encoder(connector, dp_display->encoder);
> > >   	return connector;
> > > diff --git a/drivers/gpu/drm/msm/dp/dp_drm.h b/drivers/gpu/drm/msm/dp/dp_drm.h
> > > index f4b1ed1e24f7..3b7480a86844 100644
> > > --- a/drivers/gpu/drm/msm/dp/dp_drm.h
> > > +++ b/drivers/gpu/drm/msm/dp/dp_drm.h
> > > @@ -32,5 +32,7 @@ enum drm_mode_status dp_bridge_mode_valid(struct drm_bridge *bridge,
> > >   void dp_bridge_mode_set(struct drm_bridge *drm_bridge,
> > >   			const struct drm_display_mode *mode,
> > >   			const struct drm_display_mode *adjusted_mode);
> > > +void dp_bridge_hpd_notify(struct drm_bridge *bridge,
> > > +			  enum drm_connector_status status);
> > >   #endif /* _DP_DRM_H_ */

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Kuogee Hsieh <quic_khsieh@quicinc.com>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	David Airlie <airlied@linux.ie>,
	dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
	intel-gfx@lists.freedesktop.org,
	Abhinav Kumar <quic_abhinavk@quicinc.com>,
	Stephen Boyd <swboyd@chromium.org>,
	Maxime Ripard <mripard@kernel.org>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	freedreno@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v4 5/5] drm/msm/dp: Implement hpd_notify()
Date: Mon, 2 May 2022 16:02:59 -0700	[thread overview]
Message-ID: <YnBjI1HyL//X4KOn@ripper> (raw)
In-Reply-To: <YnBbNO31bwNUoRQL@ripper>

On Mon 02 May 15:29 PDT 2022, Bjorn Andersson wrote:

> On Mon 02 May 13:59 PDT 2022, Kuogee Hsieh wrote:
> 
> > 
> > On 5/2/2022 9:53 AM, Bjorn Andersson wrote:
> > > The Qualcomm DisplayPort driver contains traces of the necessary
> > > plumbing to hook up USB HPD, in the form of the dp_hpd module and the
> > > dp_usbpd_cb struct. Use this as basis for implementing the
> > > hpd_notify() callback, by amending the dp_hpd module with the
> > > missing logic.
> > > 
> > > Overall the solution is similar to what's done downstream, but upstream
> > > all the code to disect the HPD notification lives on the calling side of
> > > drm_connector_oob_hotplug_event().
> > > 
> > > drm_connector_oob_hotplug_event() performs the lookup of the
> > > drm_connector based on fwnode, hence the need to assign the fwnode in
> > > dp_drm_connector_init().
> > > 
> > > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > > ---
> > > 
> > > Changes since v3:
> > > - Implements hpd_notify instead of oob_hotplug_event
> > > - Rebased on new cleanup patch from Dmitry
> > > - Set hpd_state to ST_MAINLINK_READY when dp_display_usbpd_configure() succeeds
> > > 
> > >   drivers/gpu/drm/msm/dp/dp_display.c | 26 ++++++++++++++++++++++++++
> > >   drivers/gpu/drm/msm/dp/dp_display.h |  1 +
> > >   drivers/gpu/drm/msm/dp/dp_drm.c     |  3 +++
> > >   drivers/gpu/drm/msm/dp/dp_drm.h     |  2 ++
> > >   4 files changed, 32 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
> > > index b447446d75e9..080294ac6144 100644
> > > --- a/drivers/gpu/drm/msm/dp/dp_display.c
> > > +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> > > @@ -83,6 +83,8 @@ struct dp_display_private {
> > >   	bool hpd_irq_on;
> > >   	bool audio_supported;
> > > +	bool connected;
> > > +
> > >   	struct drm_device *drm_dev;
> > >   	struct platform_device *pdev;
> > >   	struct dentry *root;
> > > @@ -1271,6 +1273,7 @@ static int dp_display_probe(struct platform_device *pdev)
> > >   	if (!desc)
> > >   		return -EINVAL;
> > > +	dp->dp_display.dev = &pdev->dev;
> > >   	dp->pdev = pdev;
> > >   	dp->name = "drm_dp";
> > >   	dp->dp_display.connector_type = desc->connector_type;
> > > @@ -1760,3 +1763,26 @@ void dp_bridge_mode_set(struct drm_bridge *drm_bridge,
> > >   	dp_display->dp_mode.h_active_low =
> > >   		!!(dp_display->dp_mode.drm_mode.flags & DRM_MODE_FLAG_NHSYNC);
> > >   }
> > > +
> > > +void dp_bridge_hpd_notify(struct drm_bridge *bridge,
> > > +			  enum drm_connector_status status)
> > > +{
> > > +	struct msm_dp_bridge *dp_bridge = to_dp_bridge(bridge);
> > > +	struct msm_dp *dp = dp_bridge->dp_display;
> > > +	struct dp_display_private *dp_display = container_of(dp, struct dp_display_private, dp_display);
> > > +	int ret;
> > > +
> > > +	drm_dbg_dp(dp_display->drm_dev, "status: %d connected: %d\n", status, dp_display->connected);
> > > +
> > > +	if (!dp_display->connected && status == connector_status_connected) {
> > > +		dp_display->connected = true;
> > > +		ret = dp_display_usbpd_configure(dp_display);
> > > +		if (!ret)
> > > +			dp_display->hpd_state = ST_MAINLINK_READY;
> > > +	} else if (status != connector_status_connected) {
> > > +		dp_display->connected = false;
> > > +		dp_display_notify_disconnect(dp_display);
> > > +	} else {
> > > +		dp_display_usbpd_attention(dp_display);
> > > +	}
> > > +}
> > 
> > I would assume dp_bridge_hpd_notify() will server same purpose as
> > dp_display_irq_handler() if hpd_notification is enabled.
> > 
> 
> I agree with this statement.
> 
> > In that case, should dp_bridge_hpd_notify() add
> > EV_HPD_PLUG_INT/EV_IRQ_HPD_INT/EV_HPD_UNPLUG_INT
> > 
> 
> I tried this originally, but couldn't get it to work and expected that
> as the downstream driver doesn't do this, there was some good reason for
> me not to do it either.
> 
> > into event q to kick off corresponding
> > dp_hpd_plug_handle()/dp_irq_hpd_handle()/dp_hpd_unplug_handle()?
> > 
> 
> But since then the driver has been cleaned up significantly, so I
> decided to give it a test again.
> Unfortunately it still doesn't work, but now it's easier to trace.
> 
> Replacing the 3 cases with relevant calls to dp_add_event() results in
> us inserting a EV_HPD_UNPLUG_INT event really early, before things has
> been brought up. This will result in dp_hpd_unplug_handle() trying to
> disable the dp_catalog_hpd_config_intr(), which will crash as the
> hardware isn't yet clocked up.
> 

As I sent that I realized and have now confirmed that if I get a HPD
connect before dp_display_host_init() things will not be in an
appropriate state to either and the board will crash...

I will dig a little bit more to see what we can do about this.

Regards,
Bjorn

> Further more, this points out the main difference between the normal HPD
> code and the USB HPD code; dp_catalog_hpd_config_intr() will enable the
> plug/unplug interrupts, which it shouldn't do for USB-controlled.
> 
> 
> So it seems we need two code paths after all.
> 
> > By the way, I am going to test this patch out.
> > 
> > Any patches I have to pull in before apply this serial patches?
> > 
> 
> The patches applies on Dmitry's msm-next-staging, which I've merged on
> top of linux-next together with a number of pending patches to get the
> DPU up on SM8350 and a pmic_glink driver which I'm about to post.
> 
> But to validate that it doesn't affect your non-USB case, Dmitry's
> branch should be sufficient.
> 
> Thanks,
> Bjorn
> 
> > > diff --git a/drivers/gpu/drm/msm/dp/dp_display.h b/drivers/gpu/drm/msm/dp/dp_display.h
> > > index 4f9fe4d7610b..2d2614bc5a14 100644
> > > --- a/drivers/gpu/drm/msm/dp/dp_display.h
> > > +++ b/drivers/gpu/drm/msm/dp/dp_display.h
> > > @@ -11,6 +11,7 @@
> > >   #include "disp/msm_disp_snapshot.h"
> > >   struct msm_dp {
> > > +	struct device *dev;
> > >   	struct drm_device *drm_dev;
> > >   	struct device *codec_dev;
> > >   	struct drm_bridge *bridge;
> > > diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c b/drivers/gpu/drm/msm/dp/dp_drm.c
> > > index 62d58b9c4647..821cfd37b1fb 100644
> > > --- a/drivers/gpu/drm/msm/dp/dp_drm.c
> > > +++ b/drivers/gpu/drm/msm/dp/dp_drm.c
> > > @@ -68,6 +68,7 @@ static const struct drm_bridge_funcs dp_bridge_ops = {
> > >   	.mode_valid   = dp_bridge_mode_valid,
> > >   	.get_modes    = dp_bridge_get_modes,
> > >   	.detect       = dp_bridge_detect,
> > > +	.hpd_notify   = dp_bridge_hpd_notify,
> > >   };
> > >   struct drm_bridge *dp_bridge_init(struct msm_dp *dp_display, struct drm_device *dev,
> > > @@ -138,6 +139,8 @@ struct drm_connector *dp_drm_connector_init(struct msm_dp *dp_display)
> > >   	if (IS_ERR(connector))
> > >   		return connector;
> > > +	connector->fwnode = fwnode_handle_get(dev_fwnode(dp_display->dev));
> > > +
> > >   	drm_connector_attach_encoder(connector, dp_display->encoder);
> > >   	return connector;
> > > diff --git a/drivers/gpu/drm/msm/dp/dp_drm.h b/drivers/gpu/drm/msm/dp/dp_drm.h
> > > index f4b1ed1e24f7..3b7480a86844 100644
> > > --- a/drivers/gpu/drm/msm/dp/dp_drm.h
> > > +++ b/drivers/gpu/drm/msm/dp/dp_drm.h
> > > @@ -32,5 +32,7 @@ enum drm_mode_status dp_bridge_mode_valid(struct drm_bridge *bridge,
> > >   void dp_bridge_mode_set(struct drm_bridge *drm_bridge,
> > >   			const struct drm_display_mode *mode,
> > >   			const struct drm_display_mode *adjusted_mode);
> > > +void dp_bridge_hpd_notify(struct drm_bridge *bridge,
> > > +			  enum drm_connector_status status);
> > >   #endif /* _DP_DRM_H_ */

  parent reply	other threads:[~2022-05-02 23:01 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-02 16:53 [PATCH v4 0/5] drm/msm/dp: implement HPD notifications handling Bjorn Andersson
2022-05-02 16:53 ` [Intel-gfx] " Bjorn Andersson
2022-05-02 16:53 ` Bjorn Andersson
2022-05-02 16:53 ` [PATCH v4 1/5] drm/bridge_connector: stop filtering events in drm_bridge_connector_hpd_cb() Bjorn Andersson
2022-05-02 16:53   ` [Intel-gfx] " Bjorn Andersson
2022-05-02 16:53   ` Bjorn Andersson
2022-05-02 16:53 ` [PATCH v4 2/5] drm: Add HPD state to drm_connector_oob_hotplug_event() Bjorn Andersson
2022-05-02 16:53   ` [Intel-gfx] " Bjorn Andersson
2022-05-02 16:53   ` Bjorn Andersson
2022-05-16 11:25   ` Heikki Krogerus
2022-05-16 11:25     ` [Intel-gfx] " Heikki Krogerus
2022-05-16 11:25     ` Heikki Krogerus
2022-05-16 12:05     ` [Intel-gfx] " Hans de Goede
2022-05-16 12:05       ` Hans de Goede
2022-05-16 12:05       ` Hans de Goede
2022-05-17  9:41   ` Heikki Krogerus
2022-05-17  9:41     ` [Intel-gfx] " Heikki Krogerus
2022-05-17  9:41     ` Heikki Krogerus
2022-05-02 16:53 ` [PATCH v4 3/5] drm/bridge_connector: implement oob_hotplug_event Bjorn Andersson
2022-05-02 16:53   ` [Intel-gfx] " Bjorn Andersson
2022-05-02 16:53   ` Bjorn Andersson
2022-05-02 16:53 ` [PATCH v4 4/5] drm/msm/dp: remove most of usbpd-related remains Bjorn Andersson
2022-05-02 16:53   ` [Intel-gfx] " Bjorn Andersson
2022-05-02 16:53   ` Bjorn Andersson
2022-05-02 16:53 ` [PATCH v4 5/5] drm/msm/dp: Implement hpd_notify() Bjorn Andersson
2022-05-02 16:53   ` [Intel-gfx] " Bjorn Andersson
2022-05-02 16:53   ` Bjorn Andersson
2022-05-02 20:59   ` Kuogee Hsieh
2022-05-02 20:59     ` [Intel-gfx] " Kuogee Hsieh
2022-05-02 20:59     ` Kuogee Hsieh
2022-05-02 22:29     ` Bjorn Andersson
2022-05-02 22:29       ` [Intel-gfx] " Bjorn Andersson
2022-05-02 22:29       ` Bjorn Andersson
2022-05-02 22:49       ` Kuogee Hsieh
2022-05-02 22:49         ` [Intel-gfx] " Kuogee Hsieh
2022-05-02 22:49         ` Kuogee Hsieh
2022-05-02 23:06         ` Bjorn Andersson
2022-05-02 23:06           ` [Intel-gfx] " Bjorn Andersson
2022-05-02 23:06           ` Bjorn Andersson
2022-05-02 23:02       ` Bjorn Andersson [this message]
2022-05-02 23:02         ` [Intel-gfx] " Bjorn Andersson
2022-05-02 23:02         ` Bjorn Andersson
2022-05-03 13:25 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/msm/dp: implement HPD notifications handling Patchwork

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=YnBjI1HyL//X4KOn@ripper \
    --to=bjorn.andersson@linaro.org \
    --cc=airlied@linux.ie \
    --cc=daniel@ffwll.ch \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=quic_abhinavk@quicinc.com \
    --cc=quic_khsieh@quicinc.com \
    --cc=robdclark@gmail.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=sean@poorly.run \
    --cc=swboyd@chromium.org \
    --cc=tvrtko.ursulin@linux.intel.com \
    --cc=tzimmermann@suse.de \
    /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.