From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To: David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
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>,
Andy Gross <agross@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konrad.dybcio@linaro.org>,
Vinod Koul <vkoul@kernel.org>,
Kishon Vijay Abraham I <kishon@kernel.org>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
linux-phy@lists.infradead.org, linux-usb@vger.kernel.org,
freedreno@lists.freedesktop.org
Subject: [PATCH v5 0/6] drm: simplify support for transparent DRM bridges
Date: Thu, 26 Oct 2023 01:28:01 +0300 [thread overview]
Message-ID: <20231025223027.943563-1-dmitry.baryshkov@linaro.org> (raw)
Supporting DP/USB-C can result in a chain of several transparent
bridges (PHY, redrivers, mux, etc). All attempts to implement DP support
in a different way resulted either in series of hacks or in device tree
not reflecting the actual hardware design. This results in drivers
having similar boilerplate code for such bridges.
Next, these drivers are susceptible to -EPROBE_DEFER loops: the next
bridge can either be probed from the bridge->attach callback, when it is
too late to return -EPROBE_DEFER, or from the probe() callback, when the
next bridge might not yet be available, because it depends on the
resources provided by the probing device. Device links can not fully
solve this problem since there are mutual dependencies between adjancent
devices.
Last, but not least, this results in the the internal knowledge of DRM
subsystem slowly diffusing into other subsystems, like PHY or USB/TYPEC.
To solve all these issues, define a separate DRM helper, which creates
separate aux device just for the bridge. During probe such aux device
doesn't result in the EPROBE_DEFER loops. Instead it allows the device
drivers to probe properly, according to the actual resource
dependencies. The bridge auxdevs are then probed when the next bridge
becomes available, sparing drivers from drm_bridge_attach() returning
-EPROBE_DEFER.
Changes since v4:
- Added documentation for new API (Sima)
- Added generic code to handle "last mile" DP bridges implementing just
the HPD functionality.
- Rebased on top of linux-next to be able to drop #ifdef's around
drm_bridge->of_node
Changes since v3:
- Moved bridge driver to gpu/drm/bridge (Neil Armstrong)
- Renamed it to aux-bridge (since there is already a simple_bridge driver)
- Made CONFIG_OF mandatory for this driver (Neil Armstrong)
- Added missing kfree and ida_free (Dan Carpenter)
Changes since v2:
- ifdef'ed bridge->of_node access (LKP)
Changes since v1:
- Added EXPORT_SYMBOL_GPL / MODULE_LICENSE / etc. to drm_simple_bridge
Dmitry Baryshkov (6):
drm/bridge: add transparent bridge helper
phy: qcom: qmp-combo: switch to DRM_AUX_BRIDGE
usb: typec: nb7vpq904m: switch to DRM_AUX_BRIDGE
drm/bridge: implement generic DP HPD bridge
soc: qcom: pmic-glink: switch to DRM_AUX_HPD_BRIDGE
usb: typec: qcom-pmic-typec: switch to DRM_AUX_HPD_BRIDGE
drivers/gpu/drm/bridge/Kconfig | 17 ++
drivers/gpu/drm/bridge/Makefile | 2 +
drivers/gpu/drm/bridge/aux-bridge.c | 140 +++++++++++++++
drivers/gpu/drm/bridge/aux-hpd-bridge.c | 164 ++++++++++++++++++
drivers/phy/qualcomm/Kconfig | 2 +-
drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 44 +----
drivers/soc/qcom/Kconfig | 1 +
drivers/soc/qcom/pmic_glink_altmode.c | 33 +---
drivers/usb/typec/mux/Kconfig | 2 +-
drivers/usb/typec/mux/nb7vpq904m.c | 44 +----
drivers/usb/typec/tcpm/Kconfig | 1 +
drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c | 41 +----
include/drm/bridge/aux-bridge.h | 37 ++++
13 files changed, 383 insertions(+), 145 deletions(-)
create mode 100644 drivers/gpu/drm/bridge/aux-bridge.c
create mode 100644 drivers/gpu/drm/bridge/aux-hpd-bridge.c
create mode 100644 include/drm/bridge/aux-bridge.h
--
2.42.0
next reply other threads:[~2023-10-25 22:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-25 22:28 Dmitry Baryshkov [this message]
2023-10-25 22:28 ` [PATCH v5 1/6] drm/bridge: add transparent bridge helper Dmitry Baryshkov
2023-10-25 22:28 ` [PATCH v5 2/6] phy: qcom: qmp-combo: switch to DRM_AUX_BRIDGE Dmitry Baryshkov
2023-10-25 22:28 ` [PATCH v5 3/6] usb: typec: nb7vpq904m: " Dmitry Baryshkov
2023-10-25 22:28 ` [PATCH v5 4/6] drm/bridge: implement generic DP HPD bridge Dmitry Baryshkov
2023-10-26 11:31 ` kernel test robot
2023-10-25 22:28 ` [PATCH v5 5/6] soc: qcom: pmic-glink: switch to DRM_AUX_HPD_BRIDGE Dmitry Baryshkov
2023-10-26 1:54 ` Bjorn Andersson
2023-10-25 22:28 ` [PATCH v5 6/6] usb: typec: qcom-pmic-typec: " Dmitry Baryshkov
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=20231025223027.943563-1-dmitry.baryshkov@linaro.org \
--to=dmitry.baryshkov@linaro.org \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=agross@kernel.org \
--cc=airlied@gmail.com \
--cc=andersson@kernel.org \
--cc=andrzej.hajda@intel.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=jernej.skrabec@gmail.com \
--cc=jonas@kwiboo.se \
--cc=kishon@kernel.org \
--cc=konrad.dybcio@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=linux-usb@vger.kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=rfoss@kernel.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;
as well as URLs for NNTP newsgroup(s).