public inbox for linux-rockchip@lists.infradead.org
 help / color / mirror / Atom feed
From: Sebastian Reichel <sebastian.reichel@collabora.com>
To: Chaoyi Chen <kernel@airkyi.com>
Cc: "Sandy Huang" <hjc@rock-chips.com>,
	"Heiko Stübner" <heiko@sntech.de>,
	"Andy Yan" <andy.yan@rock-chips.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Andrzej Hajda" <andrzej.hajda@intel.com>,
	"Neil Armstrong" <neil.armstrong@linaro.org>,
	"Robert Foss" <rfoss@kernel.org>,
	"Laurent Pinchart" <Laurent.pinchart@ideasonboard.com>,
	"Jonas Karlman" <jonas@kwiboo.se>,
	"Jernej Skrabec" <jernej.skrabec@gmail.com>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Damon Ding" <damon.ding@rock-chips.com>,
	"Dmitry Baryshkov" <lumag@kernel.org>,
	"Alexey Charkov" <alchark@gmail.com>,
	dri-devel@lists.freedesktop.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org, kernel@collabora.com
Subject: Re: [PATCH 00/10] Synopsys DisplayPort Controller improvements for Rockchip platforms
Date: Tue, 31 Mar 2026 04:09:35 +0200	[thread overview]
Message-ID: <acsoT_i-LfoMoIy_@venus> (raw)
In-Reply-To: <AFAEA46A791878B0+9fe68e46-8d8f-44f1-80e3-dfad2de51832@airkyi.com>


[-- Attachment #1.1: Type: text/plain, Size: 2613 bytes --]

Hi,

On Tue, Mar 31, 2026 at 09:18:32AM +0800, Chaoyi Chen wrote:
> On 3/30/2026 7:50 PM, Sebastian Reichel wrote:
> > On Mon, Mar 30, 2026 at 09:34:15AM +0800, Chaoyi Chen wrote:
> >>> There are two parts, which possibly need some discussion:
> >>>
> >>>  1. I added a dedicated bridge callback for out-of-band hotplug events,
> >>>     which is separate from the hotplug_notify. I have a feeling, that
> >>>     there might be a better solution, but haven't found it.
> >>
> >> Could you explain what an out-of-band hotplug event is?
> >>
> >> Can't the drivers/usb/typec/altmodes/displayport.c respond to these
> >> hot-plug events? Thank you.
> > 
> > That is what generates the out-of-band hotplug event in the first
> > place via drm_connector_oob_hotplug_event(). The oob in that call
> > means out of band.
> > 
> > If you look at that function it calls oob_hotplug_event() callback
> > on the DRM connector, which is then implemented by
> > drm_bridge_connector_oob_hotplug_event(). This function calls uses
> > the normal hpd handling (shared by in-band and out-of-band) and I'm
> > patching it, so that the bridges are aware of hpd explicitly being
> > provided out-of-band.
> > 
> 
> Ah, I'm actually more concerned with the specific types of events.
> For example, the "explicitly" provided HPD you mentioned here. 
> Isn't drm_connector_oob_hotplug_event able to provide those?
> 
> I assume you’re looking for an oob event that is propagated along the
> bridge chain, rather than at the connector. Is that so? Thank you.

The connector has a dedicated hotplug oob event callback, but I obviously
need the event on the bridge, since the DP controller is implemented as
bridge. The existing infrastructure propages it down to the bridge chain
via drm_bridge_hpd_notify(), which can be received by the DP controller
via the .hpd_notify callback in struct drm_bridge_funcs.

The problem is, that this receives events for in-band AND
out-of-band hotplug events. That's why I added a new bridge
callback, which hooks into the existing framework, but only delivers
out-of-band events and no in-band events.

The problem with receiving in-band in addition to out-of-band is
that the out-of-band signal should set the hotplug pin accordingly,
but the in-band detection also checks the actual DP link. If the OOB
hotplug signal says "nothing plugged", the hotplug pin should be
forced off, but if the DP link detection fails, the hotplug pin
should not be force disabled, as that makes any further detection
tries useless.

Greetings,

-- Sebastian

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2026-03-31  2:10 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-26 17:31 [PATCH 00/10] Synopsys DisplayPort Controller improvements for Rockchip platforms Sebastian Reichel
2026-03-26 17:31 ` [PATCH 01/10] drm/bridge: synopsys: dw-dp: Simplify driver data setting Sebastian Reichel
2026-03-26 17:31 ` [PATCH 02/10] drm/bridge: synopsys: dw-dp: Support MEDIA_BUS_FMT_FIXED Sebastian Reichel
2026-03-26 17:31 ` [PATCH 03/10] drm/bridge: synopsys: dw-dp: Add follow-up bridge support Sebastian Reichel
2026-03-26 17:31 ` [PATCH 04/10] drm/bridge: Add out-of-band HPD notify handler Sebastian Reichel
2026-03-26 17:31 ` [PATCH 05/10] drm/bridge: synopsys: dw-dp: Support software triggered OOB HPD Sebastian Reichel
2026-03-26 17:31 ` [PATCH 06/10] drm/rockchip: dw_dp: Implement out-of-band HPD handling Sebastian Reichel
2026-03-26 17:31 ` [PATCH 07/10] drm/bridge: synopsys: dw-dp: Add Runtime PM support Sebastian Reichel
2026-03-26 17:31 ` [PATCH 08/10] drm/rockchip: dw_dp: Add runtime " Sebastian Reichel
2026-03-26 17:31 ` [PATCH RFC 09/10] dt-bindings: display: rockchip: dw-dp: fix sound DAI cells Sebastian Reichel
2026-03-26 17:31 ` [PATCH 10/10] drm/bridge: synopsys: dw-dp: Add audio support Sebastian Reichel
2026-03-30  1:34 ` [PATCH 00/10] Synopsys DisplayPort Controller improvements for Rockchip platforms Chaoyi Chen
2026-03-30 11:50   ` Sebastian Reichel
2026-03-31  1:18     ` Chaoyi Chen
2026-03-31  2:09       ` Sebastian Reichel [this message]
2026-03-31  3:16         ` Chaoyi Chen
2026-03-31 11:01           ` Sebastian Reichel

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=acsoT_i-LfoMoIy_@venus \
    --to=sebastian.reichel@collabora.com \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=alchark@gmail.com \
    --cc=andrzej.hajda@intel.com \
    --cc=andy.yan@rock-chips.com \
    --cc=conor+dt@kernel.org \
    --cc=damon.ding@rock-chips.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=heiko@sntech.de \
    --cc=hjc@rock-chips.com \
    --cc=jernej.skrabec@gmail.com \
    --cc=jonas@kwiboo.se \
    --cc=kernel@airkyi.com \
    --cc=kernel@collabora.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=lumag@kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=rfoss@kernel.org \
    --cc=robh@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox