* Re: [PATCH v4 2/4] dt-bindings: hwmon: Add Sensirion SHT30 series
From: Conor Dooley @ 2026-03-26 17:45 UTC (permalink / raw)
To: Guenter Roeck
Cc: Zaixiang Xu, robh, krzk+dt, conor+dt, linux-hwmon, devicetree,
linux-kernel
In-Reply-To: <20260326-lullaby-elevator-3a3d25e9a6c0@spud>
[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]
On Thu, Mar 26, 2026 at 05:42:30PM +0000, Conor Dooley wrote:
> On Wed, Mar 25, 2026 at 06:05:22PM -0700, Guenter Roeck wrote:
> > On 3/25/26 11:20, Conor Dooley wrote:
> > > On Wed, Mar 25, 2026 at 05:08:08PM +0800, Zaixiang Xu wrote:
> > > > Add YAML devicetree binding schema for Sensirion SHT30 series.
> > > > Use fallback compatibles for compatible chips and add optional
> > > > interrupts and vdd-supply properties.
> > > >
> > > > Reported-by: kernel test robot <lkp@intel.com>
> > > > Closes: https://lore.kernel.org/r/202603212044.BRPaiz86-lkp@intel.com/
> > >
> > > The robot did not report that this binding was missing.
> > > It also told you not to add these tags.
> > >
> > > You also ignored my and Krzysztof's reviews.
> > >
> > > NAK.
> > >
> >
> > Maybe we should just point to AI feedback:
> >
> > https://sashiko.dev/#/patchset/1774429690-129139-1-git-send-email-zaixiang.xu.dev%40gmail.com
> >
> > and only get involved after AI does not report any problems.
> >
>
> The presentation of info in that is weird, it creates a pseudo-commit
> message, and then goes on to talk about things that the pseudo-commit
> message has had culled.
How good is this LLM stuff at figuring out if previous review feedback
has been resolved? Or is it not capable of looking at earlier revisions?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2 4/4] net: phy: Introduce Airoha AN8801/R Gigabit Ethernet PHY driver
From: Russell King (Oracle) @ 2026-03-26 17:44 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Andrew Lunn, Andrew Lunn, Louis-Alexis Eyraud, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, AngeloGioacchino Del Regno,
Heiner Kallweit, kevin-kw.huang, macpaul.lin, matthias.bgg,
kernel, netdev, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel
In-Reply-To: <385d2137-0d15-4dc0-8994-9cd48e4150b4@bootlin.com>
On Thu, Mar 26, 2026 at 06:25:20PM +0100, Maxime Chevallier wrote:
> On 26/03/2026 17:56, Andrew Lunn wrote:
> >> What is the timing requirements for a system going into suspend vs a WoL
> >> packet being sent? Should a WoL packet abort entry into suspend? If yes,
> >> then we need to program the MAC before the PHY is suspended, because
> >> suspend could already be in progress.
> >
> > We would then need to hook into the NETDEV_CHANGEADDR notifier, and
> > call into the PHY driver to let it reprogram the MAC address.
>
> We would also probably have to re-do that MAC addr programming at phy
> attach time ? If the PHY isn't attached (e.g. link admin-down on some
> boards), we can't use that notifier as we don't know what netdev to
> listen to. Or I'm missing something ?
Another point to consider in this area:
Should a detached PHY remain with WoL enabled?
If e.g. the network driver is unbound from its device, which certainly
disconnects the PHY from the network interface, should that PHY still
be able to wake up the system when there is no way to configure,
check its status, or handle its interrupts?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH v4 2/4] dt-bindings: hwmon: Add Sensirion SHT30 series
From: Conor Dooley @ 2026-03-26 17:42 UTC (permalink / raw)
To: Guenter Roeck
Cc: Zaixiang Xu, robh, krzk+dt, conor+dt, linux-hwmon, devicetree,
linux-kernel
In-Reply-To: <09105b02-3d85-4808-ba0a-f3799787425a@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]
On Wed, Mar 25, 2026 at 06:05:22PM -0700, Guenter Roeck wrote:
> On 3/25/26 11:20, Conor Dooley wrote:
> > On Wed, Mar 25, 2026 at 05:08:08PM +0800, Zaixiang Xu wrote:
> > > Add YAML devicetree binding schema for Sensirion SHT30 series.
> > > Use fallback compatibles for compatible chips and add optional
> > > interrupts and vdd-supply properties.
> > >
> > > Reported-by: kernel test robot <lkp@intel.com>
> > > Closes: https://lore.kernel.org/r/202603212044.BRPaiz86-lkp@intel.com/
> >
> > The robot did not report that this binding was missing.
> > It also told you not to add these tags.
> >
> > You also ignored my and Krzysztof's reviews.
> >
> > NAK.
> >
>
> Maybe we should just point to AI feedback:
>
> https://sashiko.dev/#/patchset/1774429690-129139-1-git-send-email-zaixiang.xu.dev%40gmail.com
>
> and only get involved after AI does not report any problems.
>
The presentation of info in that is weird, it creates a pseudo-commit
message, and then goes on to talk about things that the pseudo-commit
message has had culled.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: arm: mediatek: mediatek,g3dsys: Convert to DT schema
From: Uday Kiran @ 2026-03-26 17:35 UTC (permalink / raw)
To: Rob Herring (Arm); +Cc: linux-kernel, devicetree, skhan, conor+dt, krzk+dt
In-Reply-To: <177448145727.289326.12296113937712003366.robh@kernel.org>
On Thu, Mar 26, 2026 at 5:01 AM Rob Herring (Arm) <robh@kernel.org> wrote:
>
>
> On Wed, 25 Mar 2026 23:45:09 +0530, Udaya Kiran Challa wrote:
> > Convert the MediaTek G3D system controller devicetree binding
> > from the legacy text format to DT schema.
> >
> > Signed-off-by: Udaya Kiran Challa <challauday369@gmail.com>
> > ---
> > Changelog:
> > Changes since v2:
> > - Move binding to soc/mediatek directory
> > - Rename file to mediatek,mt2701-g3dsys.yaml based on fallback compatible
> >
> > Link to v2:https://lore.kernel.org/all/20260323180616.23333-1-challauday369@gmail.com/
> >
> > Changes since v1:
> > - Drop redundant description for reg
> > - Drop redundant description for provider properties
> >
> > Link to v1:https://lore.kernel.org/all/20260315080302.454233-1-challauday369@gmail.com/
> > ---
> > .../bindings/arm/mediatek/mediatek,g3dsys.txt | 30 ----------
> > .../soc/mediatek/mediatek,mt2701-g3dsys.yaml | 58 +++++++++++++++++++
> > 2 files changed, 58 insertions(+), 30 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,g3dsys.txt
> > create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mediatek,mt2701-g3dsys.yaml
> >
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/soc/mediatek/mediatek,mt2701-g3dsys.yaml: $id: Cannot determine base path from $id, relative path/filename doesn't match actual path or filename
> $id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt2701-g3dsys.yaml
> file: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/soc/mediatek/mediatek,mt2701-g3dsys.yaml
>
> doc reference errors (make refcheckdocs):
>
> See https://patchwork.kernel.org/project/devicetree/patch/20260325181509.3430-1-challauday369@gmail.com
>
> The base for the series is generally the latest rc1. A different dependency
> should be noted in *this* patch.
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
>
> pip3 install dtschema --upgrade
>
> Please check and re-submit after running the above command yourself. Note
> that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> your schema. However, it must be unset to test all examples with your schema.
>
Apologies Rob, this seems to have been missed in the submitted patch.
The dt_binding_check passes successfully on my end. I will send an
updated patch shortly.
^ permalink raw reply
* [PATCH 05/10] drm/bridge: synopsys: dw-dp: Support software triggered OOB HPD
From: Sebastian Reichel @ 2026-03-26 17:31 UTC (permalink / raw)
To: Sandy Huang, Heiko Stübner, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Damon Ding, Dmitry Baryshkov, Alexey Charkov, dri-devel,
linux-rockchip, linux-kernel, devicetree, kernel,
Sebastian Reichel
In-Reply-To: <20260326-synopsys-dw-dp-improvements-v1-0-501849162290@collabora.com>
Add support for USB-C DP AltMode out-of-band hotplug handling. The
handling itself is implemented in the platform specific driver as the
registers to force HPD state are not part of the Designware DisplayPort
IP itself. Instead the platform integration might provide the necessary
functionality to mux the HPD signal.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/gpu/drm/bridge/synopsys/dw-dp.c | 38 ++++++++++++++++++++++++++++++++-
include/drm/bridge/dw_dp.h | 3 +++
2 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-dp.c b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
index c3a108f1faa9..df2d629287fd 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-dp.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
@@ -1824,6 +1824,19 @@ static struct drm_bridge_state *dw_dp_bridge_atomic_duplicate_state(struct drm_b
return &state->base;
}
+static void dw_dp_bridge_oob_notify(struct drm_bridge *bridge,
+ struct drm_connector *connector,
+ enum drm_connector_status status)
+{
+ bool hpd_high = status != connector_status_disconnected;
+ struct dw_dp *dp = bridge_to_dp(bridge);
+
+ if (dp->plat_data.hpd_sw_cfg)
+ dp->plat_data.hpd_sw_cfg(dp->plat_data.data, hpd_high);
+ else
+ dev_err_once(dp->dev, "Missing platform handler for OOB HPD handling\n");
+}
+
static const struct drm_bridge_funcs dw_dp_bridge_funcs = {
.atomic_duplicate_state = dw_dp_bridge_atomic_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
@@ -1837,6 +1850,7 @@ static const struct drm_bridge_funcs dw_dp_bridge_funcs = {
.detect = dw_dp_bridge_detect,
.edid_read = dw_dp_bridge_edid_read,
.detach = dw_dp_bridge_detach,
+ .oob_notify = dw_dp_bridge_oob_notify,
};
static int dw_dp_link_retrain(struct dw_dp *dp)
@@ -1973,6 +1987,19 @@ static void dw_dp_phy_exit(void *data)
phy_exit(dp->phy);
}
+static bool dw_dp_is_routed_to_usb_c(struct drm_encoder *encoder)
+{
+ struct drm_bridge *last_bridge __free(drm_bridge_put) = NULL;
+ struct fwnode_handle *fwnode;
+
+ last_bridge = drm_bridge_chain_get_last_bridge(encoder);
+ if (!last_bridge)
+ return false;
+
+ fwnode = of_fwnode_handle(last_bridge->of_node);
+ return fwnode_device_is_compatible(fwnode, "usb-c-connector");
+}
+
struct dw_dp *dw_dp_bind(struct device *dev, struct drm_encoder *encoder,
const struct dw_dp_plat_data *plat_data)
{
@@ -1988,7 +2015,9 @@ struct dw_dp *dw_dp_bind(struct device *dev, struct drm_encoder *encoder,
dp->dev = dev;
dp->pixel_mode = plat_data->pixel_mode;
-
+ dp->plat_data.hpd_sw_sel = plat_data->hpd_sw_sel;
+ dp->plat_data.hpd_sw_cfg = plat_data->hpd_sw_cfg;
+ dp->plat_data.data = plat_data->data;
dp->plat_data.max_link_rate = plat_data->max_link_rate;
bridge = &dp->bridge;
mutex_init(&dp->irq_lock);
@@ -2086,6 +2115,13 @@ struct dw_dp *dw_dp_bind(struct device *dev, struct drm_encoder *encoder,
goto unregister_aux;
}
+ if (dw_dp_is_routed_to_usb_c(encoder)) {
+ dev_dbg(dev, "USB-C mode\n");
+
+ if (dp->plat_data.hpd_sw_sel)
+ dp->plat_data.hpd_sw_sel(dp->plat_data.data, 1);
+ }
+
dw_dp_init_hw(dp);
ret = phy_init(dp->phy);
diff --git a/include/drm/bridge/dw_dp.h b/include/drm/bridge/dw_dp.h
index 25363541e69d..4aacd0e56f50 100644
--- a/include/drm/bridge/dw_dp.h
+++ b/include/drm/bridge/dw_dp.h
@@ -20,6 +20,9 @@ enum {
struct dw_dp_plat_data {
u32 max_link_rate;
u8 pixel_mode;
+ void *data;
+ void (*hpd_sw_sel)(void *data, bool hpd);
+ void (*hpd_sw_cfg)(void *data, bool hpd);
};
struct dw_dp *dw_dp_bind(struct device *dev, struct drm_encoder *encoder,
--
2.53.0
^ permalink raw reply related
* [PATCH RFC 09/10] dt-bindings: display: rockchip: dw-dp: fix sound DAI cells
From: Sebastian Reichel @ 2026-03-26 17:31 UTC (permalink / raw)
To: Sandy Huang, Heiko Stübner, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Damon Ding, Dmitry Baryshkov, Alexey Charkov, dri-devel,
linux-rockchip, linux-kernel, devicetree, kernel,
Sebastian Reichel
In-Reply-To: <20260326-synopsys-dw-dp-improvements-v1-0-501849162290@collabora.com>
The RK3588 and RK3576 DesignWare DisplayPort controllers both have two
possible DAI interfaces: I2S and S/PDIF. Thus it is needed to have an
argument to select the right interface.
In case of RK3576 this is not enough though. The RK3576 has the same IP
as RK3588, but configured with Multi Stream Transport (MST) enabled for
up to 3 displays and thus has a total of 6 DAI interfaces (I2S and
S/PDIF for each possible stream. Meanwhile the RK3588 does not support
MST and thus has only 2 DAI interfaces.
The binding update right now only supports the simple single stream
transport (SST) setup. To avoid further DT ABI breakage (or complicated
bindings supporting different number of arguments), it's probably a good
idea to take MST into account now even though the upstream Linux driver
does not yet support it.
I see two options:
1. Adding yet another cell, so that we have the following:
<&dp_ctrl [display_stream] [i2s_or_spdif]>; potentially append
extra input ports for MST video data to existing ports node
(e.g. port@2). I would only handle the sound DAI part in my
patch and basically use '0' for the display stream and just
leave the option of using '1' or '2' once MST support is added.
2. The vendor kernel creates a sub-node for each supported display
stream and puts the ports mapping as well as the DAI reference
into that. This bundles all information for one display stream
together, which creates a clean look but the subnode does not
really describe any real thing in the hardware.
As upstream MST support seems to be quite limited, I wish for some
feedback about the preferred way to handle this.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
.../devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
index 2b0d9e23e943..1303d0e2145a 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
@@ -83,7 +83,8 @@ properties:
maxItems: 1
"#sound-dai-cells":
- const: 0
+ const: 1
+ description: 0 for I2S, 1 for SPDIF
required:
- compatible
@@ -144,7 +145,7 @@ examples:
resets = <&cru SRST_DP0>;
phys = <&usbdp_phy0 PHY_TYPE_DP>;
power-domains = <&power RK3588_PD_VO0>;
- #sound-dai-cells = <0>;
+ #sound-dai-cells = <1>;
ports {
#address-cells = <1>;
--
2.53.0
^ permalink raw reply related
* [PATCH 01/10] drm/bridge: synopsys: dw-dp: Simplify driver data setting
From: Sebastian Reichel @ 2026-03-26 17:31 UTC (permalink / raw)
To: Sandy Huang, Heiko Stübner, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Damon Ding, Dmitry Baryshkov, Alexey Charkov, dri-devel,
linux-rockchip, linux-kernel, devicetree, kernel,
Sebastian Reichel
In-Reply-To: <20260326-synopsys-dw-dp-improvements-v1-0-501849162290@collabora.com>
There is no need to get the platform device just for setting up
the driver data. Simplify the logic.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/gpu/drm/rockchip/dw_dp-rockchip.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw_dp-rockchip.c b/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
index 22c0911f1896..dd8db923d6d7 100644
--- a/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
@@ -74,7 +74,6 @@ static const struct drm_encoder_helper_funcs dw_dp_encoder_helper_funcs = {
static int dw_dp_rockchip_bind(struct device *dev, struct device *master, void *data)
{
- struct platform_device *pdev = to_platform_device(dev);
const struct dw_dp_plat_data *plat_data;
struct drm_device *drm_dev = data;
struct rockchip_dw_dp *dp;
@@ -87,7 +86,7 @@ static int dw_dp_rockchip_bind(struct device *dev, struct device *master, void *
return -ENOMEM;
dp->dev = dev;
- platform_set_drvdata(pdev, dp);
+ dev_set_drvdata(dev, dp);
plat_data = of_device_get_match_data(dev);
if (!plat_data)
--
2.53.0
^ permalink raw reply related
* [PATCH 10/10] drm/bridge: synopsys: dw-dp: Add audio support
From: Sebastian Reichel @ 2026-03-26 17:31 UTC (permalink / raw)
To: Sandy Huang, Heiko Stübner, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Damon Ding, Dmitry Baryshkov, Alexey Charkov, dri-devel,
linux-rockchip, linux-kernel, devicetree, kernel,
Sebastian Reichel
In-Reply-To: <20260326-synopsys-dw-dp-improvements-v1-0-501849162290@collabora.com>
Implement audio support for the Synopsys DesignWare DisplayPort
controller.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/gpu/drm/bridge/synopsys/dw-dp.c | 197 +++++++++++++++++++++++++++++++-
1 file changed, 196 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-dp.c b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
index 9ee9e3b9d912..add22acea719 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-dp.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
@@ -23,17 +23,21 @@
#include <drm/drm_bridge.h>
#include <drm/drm_bridge_connector.h>
#include <drm/display/drm_dp_helper.h>
+#include <drm/display/drm_hdmi_audio_helper.h>
#include <drm/drm_edid.h>
#include <drm/drm_of.h>
#include <drm/drm_print.h>
#include <drm/drm_probe_helper.h>
#include <drm/drm_simple_kms_helper.h>
+#include <sound/hdmi-codec.h>
+
#define DW_DP_VERSION_NUMBER 0x0000
#define DW_DP_VERSION_TYPE 0x0004
#define DW_DP_ID 0x0008
#define DW_DP_CONFIG_REG1 0x0100
+#define AUDIO_SELECT GENMASK(2, 1)
#define DW_DP_CONFIG_REG2 0x0104
#define DW_DP_CONFIG_REG3 0x0108
@@ -110,6 +114,10 @@
#define HBR_MODE_ENABLE BIT(10)
#define AUDIO_DATA_WIDTH GENMASK(9, 5)
#define AUDIO_DATA_IN_EN GENMASK(4, 1)
+#define AUDIO_DATA_IN_EN_CHANNEL12 BIT(0)
+#define AUDIO_DATA_IN_EN_CHANNEL34 BIT(1)
+#define AUDIO_DATA_IN_EN_CHANNEL56 BIT(2)
+#define AUDIO_DATA_IN_EN_CHANNEL78 BIT(3)
#define AUDIO_INF_SELECT BIT(0)
#define DW_DP_SDP_VERTICAL_CTRL 0x0500
@@ -253,6 +261,8 @@
#define SDP_REG_BANK_SIZE 16
+#define DW_DP_SDP_VERSION 0x12
+
struct dw_dp_link_caps {
bool enhanced_framing;
bool tps3_supported;
@@ -305,6 +315,19 @@ struct dw_dp_hotplug {
bool long_hpd;
};
+enum dw_dp_audio_interface_support {
+ DW_DP_AUDIO_I2S_ONLY = 0,
+ DW_DP_AUDIO_SPDIF_ONLY = 1,
+ DW_DP_AUDIO_I2S_AND_SPDIF = 2,
+ DW_DP_AUDIO_NONE = 3,
+};
+
+enum dw_dp_audio_interface {
+ DW_DP_AUDIO_I2S = 0,
+ DW_DP_AUDIO_SPDIF = 1,
+ DW_DP_AUDIO_UNUSED,
+};
+
struct dw_dp {
struct drm_bridge bridge;
struct device *dev;
@@ -320,6 +343,8 @@ struct dw_dp {
int irq;
struct work_struct hpd_work;
struct dw_dp_hotplug hotplug;
+ enum dw_dp_audio_interface audio_interface;
+ int audio_channels;
/* Serialize hpd status access */
struct mutex irq_lock;
@@ -1844,6 +1869,163 @@ static void dw_dp_bridge_oob_notify(struct drm_bridge *bridge,
dev_err_once(dp->dev, "Missing platform handler for OOB HPD handling\n");
}
+static int dw_dp_audio_infoframe_send(struct dw_dp *dp)
+{
+ struct hdmi_audio_infoframe frame;
+ struct dw_dp_sdp sdp;
+ int ret;
+
+ ret = hdmi_audio_infoframe_init(&frame);
+ if (ret < 0)
+ return ret;
+
+ frame.coding_type = HDMI_AUDIO_CODING_TYPE_STREAM;
+ frame.sample_frequency = HDMI_AUDIO_SAMPLE_FREQUENCY_STREAM;
+ frame.sample_size = HDMI_AUDIO_SAMPLE_SIZE_STREAM;
+ frame.channels = dp->audio_channels;
+
+ ret = hdmi_audio_infoframe_pack_for_dp(&frame, &sdp.base, DW_DP_SDP_VERSION);
+ if (ret < 0)
+ return ret;
+
+ sdp.flags = DW_DP_SDP_VERTICAL_INTERVAL;
+
+ return dw_dp_send_sdp(dp, &sdp);
+}
+
+static int dw_dp_audio_prepare(struct drm_bridge *bridge,
+ struct drm_connector *connector,
+ struct hdmi_codec_daifmt *daifmt,
+ struct hdmi_codec_params *params)
+{
+ struct dw_dp *dp = bridge_to_dp(bridge);
+ u8 audio_data_in_en, supported_audio_interfaces;
+ u32 cfg1;
+ int ret;
+
+ pm_runtime_get_sync(dp->dev);
+
+ dp->audio_channels = params->cea.channels;
+ switch (params->cea.channels) {
+ case 1:
+ case 2:
+ audio_data_in_en = AUDIO_DATA_IN_EN_CHANNEL12;
+ break;
+ case 8:
+ audio_data_in_en = AUDIO_DATA_IN_EN_CHANNEL12 |
+ AUDIO_DATA_IN_EN_CHANNEL34 |
+ AUDIO_DATA_IN_EN_CHANNEL56 |
+ AUDIO_DATA_IN_EN_CHANNEL78;
+ break;
+ default:
+ dev_err(dp->dev, "invalid audio channels %d\n", dp->audio_channels);
+ return -EINVAL;
+ }
+
+ switch (daifmt->fmt) {
+ case HDMI_SPDIF:
+ dp->audio_interface = DW_DP_AUDIO_SPDIF;
+ break;
+ case HDMI_I2S:
+ /*
+ * It is recommended to use SPDIF instead of I2S, since I2S mode requires
+ * manually inserting PCUV control bits from userspace and this is done
+ * automatically in hardware for SPDIF mode.
+ */
+ dp->audio_interface = DW_DP_AUDIO_I2S;
+ break;
+ default:
+ dev_err(dp->dev, "invalid DAI format %d\n", daifmt->fmt);
+ return -EINVAL;
+ }
+
+ regmap_read(dp->regmap, DW_DP_CONFIG_REG1, &cfg1);
+ supported_audio_interfaces = FIELD_GET(AUDIO_SELECT, cfg1);
+
+ if (supported_audio_interfaces != DW_DP_AUDIO_I2S_AND_SPDIF &&
+ supported_audio_interfaces != dp->audio_interface) {
+ dev_err(dp->dev, "unsupported DAI %d\n", daifmt->fmt);
+ return -EINVAL;
+ }
+
+ clk_prepare_enable(dp->spdif_clk);
+ clk_prepare_enable(dp->i2s_clk);
+
+ regmap_update_bits(dp->regmap, DW_DP_AUD_CONFIG1,
+ AUDIO_DATA_IN_EN | NUM_CHANNELS | AUDIO_DATA_WIDTH |
+ AUDIO_INF_SELECT | HBR_MODE_ENABLE,
+ FIELD_PREP(AUDIO_DATA_IN_EN, audio_data_in_en) |
+ FIELD_PREP(NUM_CHANNELS, dp->audio_channels - 1) |
+ FIELD_PREP(AUDIO_DATA_WIDTH, params->sample_width) |
+ FIELD_PREP(AUDIO_INF_SELECT, dp->audio_interface) |
+ FIELD_PREP(HBR_MODE_ENABLE, 0));
+
+ /* Wait for inf switch */
+ usleep_range(20, 40);
+
+ if (dp->audio_interface == DW_DP_AUDIO_I2S)
+ clk_disable_unprepare(dp->spdif_clk);
+ else if (dp->audio_interface == DW_DP_AUDIO_SPDIF)
+ clk_disable_unprepare(dp->i2s_clk);
+
+ /*
+ * Send audio stream during vertical and horizontal blanking periods.
+ * Send out audio timestamp SDP once per video frame during the vertical
+ * blanking period
+ */
+ regmap_update_bits(dp->regmap, DW_DP_SDP_VERTICAL_CTRL,
+ EN_AUDIO_STREAM_SDP | EN_AUDIO_TIMESTAMP_SDP,
+ FIELD_PREP(EN_AUDIO_STREAM_SDP, 1) |
+ FIELD_PREP(EN_AUDIO_TIMESTAMP_SDP, 1));
+ regmap_update_bits(dp->regmap, DW_DP_SDP_HORIZONTAL_CTRL,
+ EN_AUDIO_STREAM_SDP,
+ FIELD_PREP(EN_AUDIO_STREAM_SDP, 1));
+
+ ret = dw_dp_audio_infoframe_send(dp);
+ if (ret < 0)
+ dev_err(dp->dev, "failed to send audio infoframe\n");
+
+ dev_dbg(dp->dev, "audio start with %d channels using DAI=%d\n",
+ dp->audio_channels, dp->audio_interface);
+
+ return 0;
+}
+
+static void dw_dp_audio_shutdown(struct drm_bridge *bridge,
+ struct drm_connector *connector)
+{
+ struct dw_dp *dp = bridge_to_dp(bridge);
+
+ dev_dbg(dp->dev, "audio shutdown\n");
+
+ /* Disable all audio streams */
+ regmap_update_bits(dp->regmap, DW_DP_AUD_CONFIG1, AUDIO_DATA_IN_EN,
+ FIELD_PREP(AUDIO_DATA_IN_EN, 0));
+
+ if (dp->audio_interface == DW_DP_AUDIO_SPDIF)
+ clk_disable_unprepare(dp->spdif_clk);
+ else if (dp->audio_interface == DW_DP_AUDIO_I2S)
+ clk_disable_unprepare(dp->i2s_clk);
+
+ dp->audio_interface = DW_DP_AUDIO_UNUSED;
+
+ pm_runtime_put_autosuspend(dp->dev);
+}
+
+static int dw_dp_audio_mute_stream(struct drm_bridge *bridge,
+ struct drm_connector *connector,
+ bool enable, int direction)
+{
+ struct dw_dp *dp = bridge_to_dp(bridge);
+
+ dev_dbg(dp->dev, "audio %smute\n", enable ? "" : "un");
+
+ regmap_update_bits(dp->regmap, DW_DP_AUD_CONFIG1, AUDIO_MUTE,
+ FIELD_PREP(AUDIO_MUTE, enable));
+
+ return 0;
+}
+
static const struct drm_bridge_funcs dw_dp_bridge_funcs = {
.atomic_duplicate_state = dw_dp_bridge_atomic_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
@@ -1858,6 +2040,10 @@ static const struct drm_bridge_funcs dw_dp_bridge_funcs = {
.edid_read = dw_dp_bridge_edid_read,
.detach = dw_dp_bridge_detach,
.oob_notify = dw_dp_bridge_oob_notify,
+
+ .dp_audio_prepare = dw_dp_audio_prepare,
+ .dp_audio_shutdown = dw_dp_audio_shutdown,
+ .dp_audio_mute_stream = dw_dp_audio_mute_stream,
};
static int dw_dp_link_retrain(struct dw_dp *dp)
@@ -2084,10 +2270,19 @@ struct dw_dp *dw_dp_bind(struct device *dev, struct drm_encoder *encoder,
}
bridge->of_node = dev->of_node;
- bridge->ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID | DRM_BRIDGE_OP_HPD;
+ bridge->ops = DRM_BRIDGE_OP_DP_AUDIO |
+ DRM_BRIDGE_OP_DETECT |
+ DRM_BRIDGE_OP_EDID |
+ DRM_BRIDGE_OP_HPD;
bridge->type = DRM_MODE_CONNECTOR_DisplayPort;
bridge->ycbcr_420_allowed = true;
+ dp->audio_interface = DW_DP_AUDIO_UNUSED;
+ bridge->hdmi_audio_dev = dev;
+ bridge->hdmi_audio_max_i2s_playback_channels = 8;
+ bridge->hdmi_audio_dai_port = 1;
+ bridge->hdmi_audio_spdif_playback = true;
+
ret = devm_drm_bridge_add(dev, bridge);
if (ret)
return ERR_PTR(ret);
--
2.53.0
^ permalink raw reply related
* [PATCH 06/10] drm/rockchip: dw_dp: Implement out-of-band HPD handling
From: Sebastian Reichel @ 2026-03-26 17:31 UTC (permalink / raw)
To: Sandy Huang, Heiko Stübner, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Damon Ding, Dmitry Baryshkov, Alexey Charkov, dri-devel,
linux-rockchip, linux-kernel, devicetree, kernel,
Sebastian Reichel
In-Reply-To: <20260326-synopsys-dw-dp-improvements-v1-0-501849162290@collabora.com>
Implement out-of-band hotplug handling, which will be used to receive
external hotplug information from the USB-C state machine. This is
currently handled by the USBDP PHY, which brings quite some trouble
as the register being accessed requires the power-domain from the DP
controller and also requires custom TypeC HPD info parsing in the
USBDP PHY driver.
In contrast to the USBDP PHY this does not just enable the hotplug
signal when a DP AltMode capable adapter is plugged in, but instead
properly detects if a cable is plugged in for things like USB-C to
HDMI adapters.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/gpu/drm/rockchip/dw_dp-rockchip.c | 126 ++++++++++++++++++++++++++++--
1 file changed, 120 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw_dp-rockchip.c b/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
index dd8db923d6d7..a9845161ced3 100644
--- a/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
@@ -8,9 +8,12 @@
#include <linux/component.h>
#include <linux/media-bus-format.h>
+#include <linux/hw_bitfield.h>
+#include <linux/mfd/syscon.h>
#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/videodev2.h>
+#include <linux/regmap.h>
#include <drm/bridge/dw_dp.h>
#include <drm/drm_atomic_helper.h>
@@ -24,12 +27,54 @@
#include "rockchip_drm_drv.h"
+#define ROCKCHIP_MAX_CTRLS 2
+
+#define ROCKCHIP_VO_GRF_DP_SINK_HPD_SEL BIT(10)
+#define ROCKCHIP_VO_GRF_DP_SINK_HPD_CFG BIT(11)
+
+struct rockchip_dw_dp_plat_data {
+ u8 num_ctrls;
+ u32 ctrl_ids[ROCKCHIP_MAX_CTRLS];
+ u32 max_link_rate;
+ u8 pixel_mode;
+ u32 hpd_reg[ROCKCHIP_MAX_CTRLS];
+};
+
struct rockchip_dw_dp {
struct dw_dp *base;
struct device *dev;
+ const struct rockchip_dw_dp_plat_data *pdata;
+ struct regmap *vo_grf;
struct rockchip_encoder encoder;
+ int id;
+ bool hpd_sel;
+ bool hpd_cfg;
};
+static void dw_dp_rockchip_hpd_sw_sel(void *data, bool force_hpd_from_sw)
+{
+ struct rockchip_dw_dp *dp = data;
+ u32 hpd_reg = dp->pdata->hpd_reg[dp->id];
+
+ dp->hpd_sel = force_hpd_from_sw;
+
+ regmap_write(dp->vo_grf, hpd_reg,
+ FIELD_PREP_WM16_CONST(ROCKCHIP_VO_GRF_DP_SINK_HPD_SEL, dp->hpd_sel));
+}
+
+static void dw_dp_rockchip_hpd_sw_cfg(void *data, bool hpd)
+{
+ struct rockchip_dw_dp *dp = data;
+ u32 hpd_reg = dp->pdata->hpd_reg[dp->id];
+
+ dev_dbg(dp->dev, "Force HPD connected=%s\n", str_yes_no(hpd));
+
+ dp->hpd_cfg = hpd;
+
+ regmap_write(dp->vo_grf, hpd_reg,
+ FIELD_PREP_WM16_CONST(ROCKCHIP_VO_GRF_DP_SINK_HPD_CFG, dp->hpd_cfg));
+}
+
static int dw_dp_encoder_atomic_check(struct drm_encoder *encoder,
struct drm_crtc_state *crtc_state,
struct drm_connector_state *conn_state)
@@ -72,14 +117,49 @@ static const struct drm_encoder_helper_funcs dw_dp_encoder_helper_funcs = {
.atomic_check = dw_dp_encoder_atomic_check,
};
+static struct regmap *dp_dp_rockchip_get_vo_grf(struct rockchip_dw_dp *dp)
+{
+ struct device_node *np = dev_of_node(dp->dev);
+ struct of_phandle_args args;
+ struct regmap *regmap;
+ int ret;
+
+ ret = of_parse_phandle_with_args(np, "phys", "#phy-cells", 0, &args);
+ if (ret)
+ return ERR_PTR(-ENODEV);
+
+ /*
+ * Limit this workaround to RK3576 and RK3588, new platforms should
+ * add a VO GRF phandle in the DisplayPort DT node.
+ */
+ if (!of_device_is_compatible(args.np, "rockchip,rk3576-usbdp-phy") &&
+ !of_device_is_compatible(args.np, "rockchip,rk3588-usbdp-phy")) {
+ regmap = ERR_PTR(-ENODEV);
+ goto out_put_node;
+ }
+
+ regmap = syscon_regmap_lookup_by_phandle(args.np, "rockchip,vo-grf");
+
+out_put_node:
+ of_node_put(args.np);
+ return regmap;
+}
+
static int dw_dp_rockchip_bind(struct device *dev, struct device *master, void *data)
{
- const struct dw_dp_plat_data *plat_data;
+ const struct rockchip_dw_dp_plat_data *plat_data_const;
+ struct platform_device *pdev = to_platform_device(dev);
+ struct dw_dp_plat_data *plat_data;
struct drm_device *drm_dev = data;
struct rockchip_dw_dp *dp;
struct drm_encoder *encoder;
struct drm_connector *connector;
- int ret;
+ struct resource *res;
+ int ret, id;
+
+ plat_data = drmm_kzalloc(drm_dev, sizeof(*plat_data), GFP_KERNEL);
+ if (!plat_data)
+ return -ENOMEM;
dp = drmm_kzalloc(drm_dev, sizeof(*dp), GFP_KERNEL);
if (!dp)
@@ -88,10 +168,38 @@ static int dw_dp_rockchip_bind(struct device *dev, struct device *master, void *
dp->dev = dev;
dev_set_drvdata(dev, dp);
- plat_data = of_device_get_match_data(dev);
- if (!plat_data)
+ plat_data_const = device_get_match_data(dev);
+ if (!plat_data_const)
return -ENODEV;
+ dp->pdata = plat_data_const;
+
+ res = platform_get_mem_or_io(pdev, 0);
+ if (IS_ERR(res))
+ return PTR_ERR(res);
+
+ /* find the DisplayPort ID from the io address */
+ dp->id = -ENODEV;
+ for (id = 0; id < plat_data_const->num_ctrls; id++) {
+ if (res->start == plat_data_const->ctrl_ids[id]) {
+ dp->id = id;
+ break;
+ }
+ }
+
+ if (dp->id < 0)
+ return dp->id;
+
+ dp->vo_grf = dp_dp_rockchip_get_vo_grf(dp);
+ if (IS_ERR(dp->vo_grf))
+ return PTR_ERR(dp->vo_grf);
+
+ plat_data->max_link_rate = plat_data_const->max_link_rate;
+ plat_data->pixel_mode = plat_data_const->pixel_mode;
+ plat_data->hpd_sw_sel = dw_dp_rockchip_hpd_sw_sel;
+ plat_data->hpd_sw_cfg = dw_dp_rockchip_hpd_sw_cfg;
+ plat_data->data = dp;
+
encoder = &dp->encoder.encoder;
encoder->possible_crtcs = drm_of_find_possible_crtcs(drm_dev, dev->of_node);
rockchip_drm_encoder_set_crtc_endpoint_id(&dp->encoder, dev->of_node, 0, 0);
@@ -127,14 +235,20 @@ static void dw_dp_remove(struct platform_device *pdev)
component_del(&pdev->dev, &dw_dp_rockchip_component_ops);
}
-static const struct dw_dp_plat_data rk3588_dp_plat_data = {
+static const struct rockchip_dw_dp_plat_data rk3588_dp_plat_data = {
+ .num_ctrls = 2,
+ .ctrl_ids = {0xfde50000, 0xfde60000},
.max_link_rate = 810000,
.pixel_mode = DW_DP_MP_QUAD_PIXEL,
+ .hpd_reg = {0x0000, 0x0008},
};
-static const struct dw_dp_plat_data rk3576_dp_plat_data = {
+static const struct rockchip_dw_dp_plat_data rk3576_dp_plat_data = {
+ .num_ctrls = 1,
+ .ctrl_ids = {0x27e40000},
.max_link_rate = 810000,
.pixel_mode = DW_DP_MP_DUAL_PIXEL,
+ .hpd_reg = {0x0000},
};
static const struct of_device_id dw_dp_of_match[] = {
--
2.53.0
^ permalink raw reply related
* [PATCH 07/10] drm/bridge: synopsys: dw-dp: Add Runtime PM support
From: Sebastian Reichel @ 2026-03-26 17:31 UTC (permalink / raw)
To: Sandy Huang, Heiko Stübner, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Damon Ding, Dmitry Baryshkov, Alexey Charkov, dri-devel,
linux-rockchip, linux-kernel, devicetree, kernel,
Sebastian Reichel
In-Reply-To: <20260326-synopsys-dw-dp-improvements-v1-0-501849162290@collabora.com>
Add runtime PM stubs to the Synopsys DesignWare DisplayPort bridge
driver. Support is not enabled automatically and must be hooked up
in the vendor specific glue code.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/gpu/drm/bridge/synopsys/dw-dp.c | 27 +++++++++++++++++++++++++++
include/drm/bridge/dw_dp.h | 3 +++
2 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-dp.c b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
index df2d629287fd..9ee9e3b9d912 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-dp.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
@@ -1465,6 +1465,8 @@ static ssize_t dw_dp_aux_transfer(struct drm_dp_aux *aux,
if (WARN_ON(msg->size > 16))
return -E2BIG;
+ ACQUIRE(pm_runtime_active_auto, pm)(dp->dev);
+
switch (msg->request & ~DP_AUX_I2C_MOT) {
case DP_AUX_NATIVE_WRITE:
case DP_AUX_I2C_WRITE:
@@ -1655,6 +1657,8 @@ static void dw_dp_bridge_atomic_enable(struct drm_bridge *bridge,
struct drm_connector_state *conn_state;
int ret;
+ pm_runtime_get_sync(dp->dev);
+
connector = drm_atomic_get_new_connector_for_encoder(state, bridge->encoder);
if (!connector) {
dev_err(dp->dev, "failed to get connector\n");
@@ -1709,6 +1713,7 @@ static void dw_dp_bridge_atomic_disable(struct drm_bridge *bridge,
dw_dp_link_disable(dp);
bitmap_zero(dp->sdp_reg_bank, SDP_REG_BANK_SIZE);
dw_dp_reset(dp);
+ pm_runtime_put_autosuspend(dp->dev);
}
static bool dw_dp_hpd_detect_link(struct dw_dp *dp, struct drm_connector *connector)
@@ -1729,6 +1734,8 @@ static enum drm_connector_status dw_dp_bridge_detect(struct drm_bridge *bridge,
{
struct dw_dp *dp = bridge_to_dp(bridge);
+ ACQUIRE(pm_runtime_active_auto, pm)(dp->dev);
+
if (!dw_dp_hpd_detect(dp))
return connector_status_disconnected;
@@ -2155,6 +2162,26 @@ struct dw_dp *dw_dp_bind(struct device *dev, struct drm_encoder *encoder,
}
EXPORT_SYMBOL_GPL(dw_dp_bind);
+int dw_dp_runtime_suspend(struct dw_dp *dp)
+{
+ clk_disable_unprepare(dp->aux_clk);
+ clk_disable_unprepare(dp->apb_clk);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(dw_dp_runtime_suspend);
+
+int dw_dp_runtime_resume(struct dw_dp *dp)
+{
+ clk_prepare_enable(dp->apb_clk);
+ clk_prepare_enable(dp->aux_clk);
+
+ dw_dp_init_hw(dp);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(dw_dp_runtime_resume);
+
MODULE_AUTHOR("Andy Yan <andyshrk@163.com>");
MODULE_DESCRIPTION("DW DP Core Library");
MODULE_LICENSE("GPL");
diff --git a/include/drm/bridge/dw_dp.h b/include/drm/bridge/dw_dp.h
index 4aacd0e56f50..8377f4be8e9e 100644
--- a/include/drm/bridge/dw_dp.h
+++ b/include/drm/bridge/dw_dp.h
@@ -27,4 +27,7 @@ struct dw_dp_plat_data {
struct dw_dp *dw_dp_bind(struct device *dev, struct drm_encoder *encoder,
const struct dw_dp_plat_data *plat_data);
+
+int dw_dp_runtime_suspend(struct dw_dp *dp);
+int dw_dp_runtime_resume(struct dw_dp *dp);
#endif /* __DW_DP__ */
--
2.53.0
^ permalink raw reply related
* [PATCH 04/10] drm/bridge: Add out-of-band HPD notify handler
From: Sebastian Reichel @ 2026-03-26 17:31 UTC (permalink / raw)
To: Sandy Huang, Heiko Stübner, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Damon Ding, Dmitry Baryshkov, Alexey Charkov, dri-devel,
linux-rockchip, linux-kernel, devicetree, kernel,
Sebastian Reichel
In-Reply-To: <20260326-synopsys-dw-dp-improvements-v1-0-501849162290@collabora.com>
For DP bridges, that can be used for DP AltMode, it might be necessary
to enforce HPD status. There is an existing ->oob_hotplug_event() on
the DRM connector, but it currently just calls into hpd_notify().
As DP bridge drivers usually also implement .detect and that also
generates calls into hpd_notify, this is a bad place to force the
HPD status as the follow-up detect call might force it off again
resulting in all follow-up calls to the detection routine also
failing.
Avoid this by having a dedicated function for OOB events.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/gpu/drm/display/drm_bridge_connector.c | 6 ++++++
include/drm/drm_bridge.h | 14 ++++++++++++++
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_bridge_connector.c b/drivers/gpu/drm/display/drm_bridge_connector.c
index 39cc18f78eda..4333cc66073e 100644
--- a/drivers/gpu/drm/display/drm_bridge_connector.c
+++ b/drivers/gpu/drm/display/drm_bridge_connector.c
@@ -180,6 +180,12 @@ static void drm_bridge_connector_oob_hotplug_event(struct drm_connector *connect
struct drm_bridge_connector *bridge_connector =
to_drm_bridge_connector(connector);
+ /* Notify all bridges in the pipeline of hotplug events. */
+ drm_for_each_bridge_in_chain_scoped(bridge_connector->encoder, bridge) {
+ if (bridge->funcs->oob_notify)
+ bridge->funcs->oob_notify(bridge, connector, status);
+ }
+
drm_bridge_connector_handle_hpd(bridge_connector, status);
}
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index a8d67bd9ee50..1ad9ae50c829 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -646,6 +646,20 @@ struct drm_bridge_funcs {
*/
void (*hpd_disable)(struct drm_bridge *bridge);
+ /**
+ * @oob_notify:
+ *
+ * Notify the bridge of out of band hot plug detection.
+ *
+ * This callback is optional, it may be implemented by bridges that
+ * need to be notified of display connection or disconnection for
+ * internal reasons. One use case is to force the DP controllers HPD
+ * signal for USB-C DP AltMode.
+ */
+ void (*oob_notify)(struct drm_bridge *bridge,
+ struct drm_connector *connector,
+ enum drm_connector_status status);
+
/**
* @hdmi_tmds_char_rate_valid:
*
--
2.53.0
^ permalink raw reply related
* [PATCH 08/10] drm/rockchip: dw_dp: Add runtime PM support
From: Sebastian Reichel @ 2026-03-26 17:31 UTC (permalink / raw)
To: Sandy Huang, Heiko Stübner, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Damon Ding, Dmitry Baryshkov, Alexey Charkov, dri-devel,
linux-rockchip, linux-kernel, devicetree, kernel,
Sebastian Reichel
In-Reply-To: <20260326-synopsys-dw-dp-improvements-v1-0-501849162290@collabora.com>
Add support for runtime PM to the Rockchip RK3576/3588 Synopsys
DesignWare DisplayPort driver.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/gpu/drm/rockchip/dw_dp-rockchip.c | 40 +++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw_dp-rockchip.c b/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
index a9845161ced3..c371306f7073 100644
--- a/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
@@ -12,6 +12,7 @@
#include <linux/mfd/syscon.h>
#include <linux/of_device.h>
#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
#include <linux/videodev2.h>
#include <linux/regmap.h>
@@ -58,6 +59,8 @@ static void dw_dp_rockchip_hpd_sw_sel(void *data, bool force_hpd_from_sw)
dp->hpd_sel = force_hpd_from_sw;
+ ACQUIRE(pm_runtime_active_auto, pm)(dp->dev);
+
regmap_write(dp->vo_grf, hpd_reg,
FIELD_PREP_WM16_CONST(ROCKCHIP_VO_GRF_DP_SINK_HPD_SEL, dp->hpd_sel));
}
@@ -71,6 +74,8 @@ static void dw_dp_rockchip_hpd_sw_cfg(void *data, bool hpd)
dp->hpd_cfg = hpd;
+ ACQUIRE(pm_runtime_active_auto, pm)(dp->dev);
+
regmap_write(dp->vo_grf, hpd_reg,
FIELD_PREP_WM16_CONST(ROCKCHIP_VO_GRF_DP_SINK_HPD_CFG, dp->hpd_cfg));
}
@@ -213,6 +218,12 @@ static int dw_dp_rockchip_bind(struct device *dev, struct device *master, void *
if (IS_ERR(dp->base))
return PTR_ERR(dp->base);
+ pm_runtime_use_autosuspend(dev);
+ pm_runtime_set_autosuspend_delay(dev, 500);
+ ret = devm_pm_runtime_enable(dev);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to enable runtime PM\n");
+
connector = drm_bridge_connector_init(drm_dev, encoder);
if (IS_ERR(connector))
return dev_err_probe(dev, PTR_ERR(connector),
@@ -235,6 +246,34 @@ static void dw_dp_remove(struct platform_device *pdev)
component_del(&pdev->dev, &dw_dp_rockchip_component_ops);
}
+static int dw_dp_rockchip_runtime_suspend(struct device *dev)
+{
+ struct rockchip_dw_dp *dp = dev_get_drvdata(dev);
+
+ return dw_dp_runtime_suspend(dp->base);
+}
+
+static int dw_dp_rockchip_runtime_resume(struct device *dev)
+{
+ struct rockchip_dw_dp *dp = dev_get_drvdata(dev);
+ u32 hpd_reg = dp->pdata->hpd_reg[dp->id];
+ int ret;
+
+ ret = dw_dp_runtime_resume(dp->base);
+ if (ret)
+ return ret;
+
+ regmap_write(dp->vo_grf, hpd_reg,
+ FIELD_PREP_WM16_CONST(ROCKCHIP_VO_GRF_DP_SINK_HPD_SEL, dp->hpd_sel) |
+ FIELD_PREP_WM16_CONST(ROCKCHIP_VO_GRF_DP_SINK_HPD_CFG, dp->hpd_cfg));
+
+ return 0;
+}
+
+static const struct dev_pm_ops dw_dp_pm_ops = {
+ RUNTIME_PM_OPS(dw_dp_rockchip_runtime_suspend, dw_dp_rockchip_runtime_resume, NULL)
+};
+
static const struct rockchip_dw_dp_plat_data rk3588_dp_plat_data = {
.num_ctrls = 2,
.ctrl_ids = {0xfde50000, 0xfde60000},
@@ -269,5 +308,6 @@ struct platform_driver dw_dp_driver = {
.driver = {
.name = "dw-dp",
.of_match_table = dw_dp_of_match,
+ .pm = pm_ptr(&dw_dp_pm_ops),
},
};
--
2.53.0
^ permalink raw reply related
* [PATCH 03/10] drm/bridge: synopsys: dw-dp: Add follow-up bridge support
From: Sebastian Reichel @ 2026-03-26 17:31 UTC (permalink / raw)
To: Sandy Huang, Heiko Stübner, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Damon Ding, Dmitry Baryshkov, Alexey Charkov, dri-devel,
linux-rockchip, linux-kernel, devicetree, kernel,
Sebastian Reichel
In-Reply-To: <20260326-synopsys-dw-dp-improvements-v1-0-501849162290@collabora.com>
Add support to use USB-C connectors with the DP altmode helper code on
devicetree based platforms. To get this working there must be a DRM
bridge chain from the DisplayPort controller to the USB-C connector.
E.g. on Rockchip RK3576:
root@rk3576 # cat /sys/kernel/debug/dri/0/encoder-0/bridges
bridge[0]: dw_dp_bridge_funcs
refcount: 7
type: [10] DP
OF: /soc/dp@27e40000:rockchip,rk3576-dp
ops: [0x47] detect edid hpd
bridge[1]: drm_aux_bridge_funcs
refcount: 4
type: [0] Unknown
OF: /soc/phy@2b010000:rockchip,rk3576-usbdp-phy
ops: [0x0]
bridge[2]: drm_aux_hpd_bridge_funcs
refcount: 5
type: [10] DP
OF: /soc/i2c@2ac50000/typec-portc@22/connector:usb-c-connector
ops: [0x4] hpd
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/gpu/drm/bridge/synopsys/dw-dp.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-dp.c b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
index 222862d962d9..c3a108f1faa9 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-dp.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
@@ -1978,7 +1978,7 @@ struct dw_dp *dw_dp_bind(struct device *dev, struct drm_encoder *encoder,
{
struct platform_device *pdev = to_platform_device(dev);
struct dw_dp *dp;
- struct drm_bridge *bridge;
+ struct drm_bridge *bridge, *next_bridge;
void __iomem *res;
int ret;
@@ -2072,6 +2072,20 @@ struct dw_dp *dw_dp_bind(struct device *dev, struct drm_encoder *encoder,
goto unregister_aux;
}
+ next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 1, 0);
+ if (IS_ERR(next_bridge)) {
+ ret = PTR_ERR(next_bridge);
+ dev_err_probe(dev, ret, "failed to get follow-up bridge.\n");
+ goto unregister_aux;
+ }
+
+ ret = drm_bridge_attach(encoder, next_bridge, bridge,
+ DRM_BRIDGE_ATTACH_NO_CONNECTOR);
+ if (ret) {
+ dev_err_probe(dev, ret, "Failed to attach next bridge\n");
+ goto unregister_aux;
+ }
+
dw_dp_init_hw(dp);
ret = phy_init(dp->phy);
--
2.53.0
^ permalink raw reply related
* [PATCH 02/10] drm/bridge: synopsys: dw-dp: Support MEDIA_BUS_FMT_FIXED
From: Sebastian Reichel @ 2026-03-26 17:31 UTC (permalink / raw)
To: Sandy Huang, Heiko Stübner, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Damon Ding, Dmitry Baryshkov, Alexey Charkov, dri-devel,
linux-rockchip, linux-kernel, devicetree, kernel,
Sebastian Reichel
In-Reply-To: <20260326-synopsys-dw-dp-improvements-v1-0-501849162290@collabora.com>
Add support for MEDIA_BUS_FMT_FIXED, which is e.g. requested for USB-C
DP chains as the last bridge in the chain (aux-hpd-bridge) does not
implement atomic_get_output_bus_fmts(), which results in the generic
drm_atomic_bridge_chain_select_bus_fmts() code using MEDIA_BUS_FMT_FIXED
instead.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/gpu/drm/bridge/synopsys/dw-dp.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-dp.c b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
index 8f2739fa189e..222862d962d9 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-dp.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
@@ -1528,6 +1528,7 @@ static int dw_dp_bridge_atomic_check(struct drm_bridge *bridge,
struct drm_connector_state *conn_state)
{
struct drm_display_mode *adjusted_mode = &crtc_state->adjusted_mode;
+ unsigned int out_bus_format = bridge_state->output_bus_cfg.format;
struct dw_dp *dp = bridge_to_dp(bridge);
struct dw_dp_bridge_state *state;
const struct dw_dp_output_format *fmt;
@@ -1538,7 +1539,10 @@ static int dw_dp_bridge_atomic_check(struct drm_bridge *bridge,
state = to_dw_dp_bridge_state(bridge_state);
mode = &state->mode;
- fmt = dw_dp_get_output_format(bridge_state->output_bus_cfg.format);
+ if (out_bus_format == MEDIA_BUS_FMT_FIXED)
+ out_bus_format = MEDIA_BUS_FMT_RGB888_1X24;
+
+ fmt = dw_dp_get_output_format(out_bus_format);
if (!fmt)
return -EINVAL;
--
2.53.0
^ permalink raw reply related
* [PATCH 00/10] Synopsys DisplayPort Controller improvements for Rockchip platforms
From: Sebastian Reichel @ 2026-03-26 17:31 UTC (permalink / raw)
To: Sandy Huang, Heiko Stübner, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Damon Ding, Dmitry Baryshkov, Alexey Charkov, dri-devel,
linux-rockchip, linux-kernel, devicetree, kernel,
Sebastian Reichel
This patch series updates the Synopsys Designware DisplayPort bridge
together with the only existing user: The Rockchip RK3576/RK3588:
1. follow-up bridges (PHY, USB-C connector)
this is needed to get USB-C DP AltMode working; I've followed the
Qualcomm driver as reference
2. runtime PM
the initial driver has been upstreamed without RPM; add it to
avoid wasting power when nothing is plugged
3. audio
the initial driver has been upstreamed without audio support;
this adds all missing bits for audio with single stream transport
The series is based on drm-misc-next with Cristian's cleanup series
applied as I expect that to land first:
https://lore.kernel.org/linux-rockchip/20260310-drm-rk-fixes-v2-0-645ecfb43f49@collabora.com/
To properly make use of the bridge code the following USBDP PHY series
is also needed:
https://lore.kernel.org/linux-rockchip/20260313-rockchip-usbdp-cleanup-v3-0-3e8fe89a35b5@collabora.com/
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.
2. The DT binding for audio support - explicitly marked as RFC - works
perfectly fine, but is not ready for MST. I don't intend to
implement that right now, but the binding should obviously take it
into consideration to avoid breaking it in the future. I've put
some points for discussion into the relevant patch.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
Sebastian Reichel (10):
drm/bridge: synopsys: dw-dp: Simplify driver data setting
drm/bridge: synopsys: dw-dp: Support MEDIA_BUS_FMT_FIXED
drm/bridge: synopsys: dw-dp: Add follow-up bridge support
drm/bridge: Add out-of-band HPD notify handler
drm/bridge: synopsys: dw-dp: Support software triggered OOB HPD
drm/rockchip: dw_dp: Implement out-of-band HPD handling
drm/bridge: synopsys: dw-dp: Add Runtime PM support
drm/rockchip: dw_dp: Add runtime PM support
[RFC] dt-bindings: display: rockchip: dw-dp: fix sound DAI cells
drm/bridge: synopsys: dw-dp: Add audio support
.../bindings/display/rockchip/rockchip,dw-dp.yaml | 5 +-
drivers/gpu/drm/bridge/synopsys/dw-dp.c | 284 ++++++++++++++++++++-
drivers/gpu/drm/display/drm_bridge_connector.c | 6 +
drivers/gpu/drm/rockchip/dw_dp-rockchip.c | 167 +++++++++++-
include/drm/bridge/dw_dp.h | 6 +
include/drm/drm_bridge.h | 14 +
6 files changed, 469 insertions(+), 13 deletions(-)
---
base-commit: 0660ee19141e5e90b422b7daa0d8518a8d0d898b
change-id: 20260325-synopsys-dw-dp-improvements-7da2e98df1dd
Best regards,
--
Sebastian Reichel <sebastian.reichel@collabora.com>
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: stmmac: remove axi_kbbe, axi_mb and axi_rb members
From: Simon Horman @ 2026-03-26 17:29 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, Conor Dooley,
David S. Miller, devicetree, Eric Dumazet, Giuseppe Cavallaro,
Jakub Kicinski, Jose Abreu, Krzysztof Kozlowski, linux-arm-kernel,
linux-stm32, netdev, Paolo Abeni, Rob Herring, Yao Zi
In-Reply-To: <E1w4ydo-0000000Dlpb-34jd@rmk-PC.armlinux.org.uk>
On Tue, Mar 24, 2026 at 10:05:40AM +0000, Russell King (Oracle) wrote:
> axi_kbbe, axi_mb and axi_rb are all written, but nothing ever reads
> their values. Remove the code that sets these and the struct members.
>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Hi Russell,
FYI, AI review suggests that these fields should also be removed from
Documentation/networking/device_drivers/ethernet/stmicro/stmmac.rst
^ permalink raw reply
* Re: [PATCH net-next v2 4/4] net: phy: Introduce Airoha AN8801/R Gigabit Ethernet PHY driver
From: Maxime Chevallier @ 2026-03-26 17:25 UTC (permalink / raw)
To: Andrew Lunn, Russell King (Oracle)
Cc: Andrew Lunn, Louis-Alexis Eyraud, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, AngeloGioacchino Del Regno, Heiner Kallweit,
kevin-kw.huang, macpaul.lin, matthias.bgg, kernel, netdev,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <425217fd-f74c-455c-9aa7-5b6682d887fa@lunn.ch>
On 26/03/2026 17:56, Andrew Lunn wrote:
>> What is the timing requirements for a system going into suspend vs a WoL
>> packet being sent? Should a WoL packet abort entry into suspend? If yes,
>> then we need to program the MAC before the PHY is suspended, because
>> suspend could already be in progress.
>
> We would then need to hook into the NETDEV_CHANGEADDR notifier, and
> call into the PHY driver to let it reprogram the MAC address.
We would also probably have to re-do that MAC addr programming at phy
attach time ? If the PHY isn't attached (e.g. link admin-down on some
boards), we can't use that notifier as we don't know what netdev to
listen to. Or I'm missing something ?
Maxime
>
> Andrew
>
^ permalink raw reply
* Re: [PATCH v8 4/5] reset: rzv2h-usb2phy: Keep PHY clock enabled for entire device lifetime
From: Tommaso Merciai @ 2026-03-26 17:22 UTC (permalink / raw)
To: Philipp Zabel
Cc: tomm.merciai, peda, linux-renesas-soc, biju.das.jz,
Fabrizio Castro, Lad Prabhakar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm, Ulf Hansson,
Greg Kroah-Hartman, Josua Mayer, Arnd Bergmann, devicetree,
linux-kernel, stable
In-Reply-To: <37f389274e5c0e33c0e8fad8ffed0237b0127b07.camel@pengutronix.de>
Hi Philipp,
Thanks for your review.
On Thu, Mar 12, 2026 at 04:24:28PM +0100, Philipp Zabel wrote:
> On Do, 2026-03-12 at 15:50 +0100, Tommaso Merciai wrote:
> > The driver was disabling the USB2 PHY clock immediately after register
> > initialization in probe() and after each reset operation. This left the
> > PHY unclocked even though it must remain active for USB functionality.
> >
> > The behavior appeared to work only when another driver
> > (e.g., USB controller) had already enabled the clock, making operation
> > unreliable and hardware-dependent. In configurations where this driver
> > is the sole clock user, USB functionality would fail.
> >
> > Fix this by:
> > - Enabling the clock once in probe() via pm_runtime_resume_and_get()
> > - Removing all pm_runtime_put() calls from assert/deassert/status
> > - Registering a devm cleanup action to release the clock at removal
> > - Removed rzv2h_usbphy_assert_helper() and its call in
> > rzv2h_usb2phy_reset_probe()
> >
> > This ensures the PHY clock remains enabled for the entire device lifetime,
> > preventing instability and aligning with hardware requirements.
> >
> > Cc: stable@vger.kernel.org
> > Fixes: e3911d7f865b ("reset: Add USB2PHY port reset driver for Renesas RZ/V2H(P)")
> > Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
>
> Given the Cc: stable tag I assume I can apply this first, independently
> of the other patches?
Yes, Thanks for asking.
Kind Regards,
Tommaso
>
> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
>
> regards
> Philipp
^ permalink raw reply
* Re: Re: [PATCH net-next v5 3/3] riscv: dts: eswin: eic7700-hifive-premier-p550: enable Ethernet controller
From: Simon Horman @ 2026-03-26 17:21 UTC (permalink / raw)
To: 李志
Cc: devicetree, andrew+netdev, davem, edumazet, kuba, robh, krzk+dt,
conor+dt, netdev, pabeni, mcoquelin.stm32, alexandre.torgue,
rmk+kernel, pjw, palmer, aou, alex, linux-riscv, linux-stm32,
linux-arm-kernel, linux-kernel, maxime.chevallier, ningyu, linmin,
pinkesh.vaghela, pritesh.patel, weishangjuan
In-Reply-To: <2a12c839.5e64.19d28232537.Coremail.lizhi2@eswincomputing.com>
On Thu, Mar 26, 2026 at 11:14:45AM +0800, 李志 wrote:
...
> Hi Simon,
>
> Thanks for your review.
>
> You're right, this build failure is due to an invalid clock reference
> ("clk") in the Ethernet node, which does not correspond to an existing
> clock provider label in the current DTS.
>
> For context, this was discussed during an earlier revision:
> https://lore.kernel.org/lkml/5dea8ce0.4435.19c471231f5.Coremail.lizhi2@eswincomputing.com/
>
> The EIC7700 clock controller support has since been applied, so I will
> update the DTS to reference the correct clock provider and ensure the
> build passes cleanly.
>
> I will fix this in the next revision (v6).
Thanks.
Please be aware that if the patch is routed via net-next,
then the dependency will need to be present in net-next.
^ permalink raw reply
* Re: [PATCH v8 1/5] mux: Add driver for Renesas RZ/V2H USB VBENCTL VBUS_SEL mux
From: Tommaso Merciai @ 2026-03-26 17:20 UTC (permalink / raw)
To: Philipp Zabel
Cc: tomm.merciai, peda, linux-renesas-soc, biju.das.jz,
Fabrizio Castro, Lad Prabhakar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm, Ulf Hansson,
Greg Kroah-Hartman, Josua Mayer, Arnd Bergmann, devicetree,
linux-kernel
In-Reply-To: <eae7dbabeca13c023dd253fe7c1c1d588c585d94.camel@pengutronix.de>
Hi Philipp,
Thanks for your review!
On Thu, Mar 12, 2026 at 04:23:28PM +0100, Philipp Zabel wrote:
> On Do, 2026-03-12 at 15:50 +0100, Tommaso Merciai wrote:
> > As per the RZ/V2H(P) HW manual, VBUSEN can be controlled by the VBUS_SEL
> > bit of the VBENCTL Control Register. This register is mapped in the
> > reset framework. The reset driver expose this register as mux-controller
> > and instantiates this driver. The consumer will use the mux API to
> > control the VBUS_SEL bit.
> >
> > Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
>
>
> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
>
> Converting the reset driver to regmap and passing the regmap via
> dev_get_regmap() would allow to get rid of the dependency between
> patches 1 and 5.
Thanks for the hint.
I will switch to regmap API in v9.
Kind Regards,
Tommaso
>
> regards
> Philipp
^ permalink raw reply
* Re: [PATCH 0/8] drm/mxsfb/lcdif: use DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector
From: Martyn Welch @ 2026-03-26 17:13 UTC (permalink / raw)
To: Luca Ceresoli, Marek Vasut, Stefan Agner, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Liu Ying, Rob Herring,
Saravana Kannan
Cc: Kory Maincent (TI.com), Hervé Codina, Hui Pu, Ian Ray,
Thomas Petazzoni, dri-devel, imx, linux-arm-kernel, linux-kernel,
devicetree, Adam Ford, Alexander Stein, Anson Huang,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Joao Paulo Goncalves,
Josua Mayer, Kieran Bingham, Marco Felsch, Oleksij Rempel,
Peng Fan, Philippe Schenker, Richard Hu, Shengjiu Wang,
Stefan Eichenberger, Vitor Soares
In-Reply-To: <20260320-drm-lcdif-dbanc-v1-0-479a04133e70@bootlin.com>
On 20/03/2026 10:46, Luca Ceresoli wrote:
> This series modernizes the i.mx8mp LCDIF driver to use the
> bridge-connector, which is the current best practice in DRM.
>
> == Call for testing on i.MX8MP boards (especially those using HDMI)!
>
> This series applies changes to how video output devices are probed on
> i.MX8MP, especially those using HDMI. Even though I have put care in not
> breaking anything, there could potentially be pitfalls I haven't realized,
> causing regressions on existing boards.
>
> I have thus added in Cc all developers which appeared active on dts files
> for imx8mp boards involving video. I would appreciate testing on as many
> boards as possible, along with a Tested-by tag, or a report about any
> issues encountered.
>
> Thanks in advance to all testers!
>
Tested-by: Martyn Welch <martyn.welch@collabora.com>
Using Ezurio Nitrogen8M Plus ENC Carrier Board with i.MX88MP SOM and
1280x800 HDMI display.
> == Review recommendation
>
> I recommend reviewing patches in this order to be understood more
> effectively:
>
> * Cover letter
> * Patches 1-5 are small preliminary cleanups/improvements
> * Patch 8 is the goal of this series, but would not work alone
> * Patch 7 this lets patch 8 work; but in turn it can't work alone
> * Patch 6 lets patch 7 work
>
> == Series description
>
> This series is not strictly related to DRM bridge hotplug, it is rather a
> preparation step. Introducing hotplug would need two different approaches:
> one for the new way, for drivers using bridge-connector and
> DRM_BRIDGE_ATTACH_NO_CONNECTOR, another for drivers using the "old, legacy
> way" where the last bridge is supposed to instantiate the
> drm_connector. Hotplug is complicated enough in one case, so it makes sense
> to only support the new way.
>
> The hardware I'm working on is an i.MX8MP, whose LCDIF driver is still
> using the old way. So this series converts to the new way as a preparation
> step.
>
> Patch 8 does the conversion, which is simple. However this would introduce
> a regression on some boards. Here's why:
>
> There are 3 instances of the LCDIF in i.MX8MP:
>
> * LCDIF1, driving the DSI output
> * LCDIF2, driving the LVDS output
> * LCDIF3, driving the HDMI output
>
> The device drivers of peripherals connected to LCDIF1 and LCDIF2 already
> support the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag. So far so good.
>
> LCDIF3 is more tricky. The HDMI pipeline is:
>
> LCDIF3 -> fsl,imx8mp-hdmi-pvi -> fsl,imx8mp-hdmi-tx -> HDMI connector
>
> The fsl,imx8mp-hdmi-tx (hdmi-tx) component supports both cases (with or
> without DRM_BRIDGE_ATTACH_NO_CONNECTOR), but in the
> DRM_BRIDGE_ATTACH_NO_CONNECTOR case it does not create a drm_connector,
> thus preventing the creation of the pipeline. To make it work a connector
> must be created, and the way to do so is describing the connector in the
> device tree (compatible = "hdmi-connector"), so the display-driver will add
> the connector along with a wrapping bridge.
>
> Unfortunately not all device trees in mainline have an hdmi-connector
> node. Adding one is easy, but would break existing hardware upgrading to a
> newer kernel without upgrading the device tree blob. This is addressed by
> patch 7 reusing an existing approach to add such a node to the live device
> tree at init time using a device tree overlay for boards which don't have
> one.
>
> Finally, patch 7 cannot work alone because of a bad interaction between
> devlink and device tree overlays. Patch 6 solves that.
>
> == Grand plan
>
> This is part of the work to support hotplug of DRM bridges. The grand plan
> was discussed in [0].
>
> Here's the work breakdown (➜ marks the current series):
>
> 1. … add refcounting to DRM bridges struct drm_bridge,
> based on devm_drm_bridge_alloc()
> A. ✔ add new alloc API and refcounting (v6.16)
> B. ✔ convert all bridge drivers to new API (v6.17)
> C. ✔ kunit tests (v6.17)
> D. ✔ add get/put to drm_bridge_add/remove() + attach/detach()
> and warn on old allocation pattern (v6.17)
> E. … add get/put on drm_bridge accessors
> 1. ✔ drm_bridge_chain_get_first_bridge(), add cleanup action (v6.18)
> 2. ✔ drm_bridge_get_prev_bridge() (v6.18)
> 3. ✔ drm_bridge_get_next_bridge() (v6.19)
> 4. ✔ drm_for_each_bridge_in_chain() (v6.19)
> 5. ✔ drm_bridge_connector_init (v6.19)
> 6. … protect encoder bridge chain with a mutex
> 7. … of_drm_find_bridge
> a. ✔ add of_drm_get_bridge() (v7.0),
> convert basic direct users (v7.0-v7.1)
> b. ✔ convert direct of_drm_get_bridge() users, part 2 (v7.0)
> c. ✔ convert direct of_drm_get_bridge() users, part 3 (v7.0)
> d. ✔… convert direct of_drm_get_bridge() users, part 4
> (some v7.1, some pending)
> e. convert bridge-only drm_of_find_panel_or_bridge() users
> 8. drm_of_find_panel_or_bridge, *_of_get_bridge
> 9. ✔ enforce drm_bridge_add before drm_bridge_attach (v6.19)
> F. ✔ debugfs improvements
> 1. ✔ add top-level 'bridges' file (v6.16)
> 2. ✔ show refcount and list lingering bridges (v6.19)
> 2. … handle gracefully atomic updates during bridge removal
> A. ✔ Add drm_bridge_enter/exit() to protect device resources (v7.0)
> B. … protect private_obj removal from list
> C. ✔ Add drm_bridge_clear_and_put() (v7.1)
> 3. … DSI host-device driver interaction
> 4. ✔ removing the need for the "always-disconnected" connector
> 5. ➜ Migrate i.MX LCDIF driver to bridge-connector
> 6. DRM bridge hotplug
> A. Bridge hotplug management in the DRM core
> B. Device tree description
>
> [0] https://lore.kernel.org/lkml/20250206-hotplug-drm-bridge-v6-0-9d6f2c9c3058@bootlin.com/#t
>
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> ---
> Luca Ceresoli (8):
> drm/mxsfb/lcdif: simplify remote pointer management using __free
> drm/mxsfb/lcdif: don't unnecessarily loop over ports
> drm/mxsfb/lcdif: use dev_err_probe() consistently in lcdif_attach_bridge
> drm/bridge: dw-hdmi: document the output_port field
> drm/bridge: dw-hdmi: warn on unsupported attach combination
> drm/bridge: dw-hdmi: move next_bridge lookup to attach time
> drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time
> drm/mxsfb/lcdif: use DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector
>
> drivers/gpu/drm/bridge/imx/Kconfig | 17 +++++
> drivers/gpu/drm/bridge/imx/Makefile | 2 +
> .../bridge/imx/imx8mp-hdmi-tx-connector-fixup.c | 60 +++++++++++++++
> .../bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso | 38 ++++++++++
> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c | 1 +
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 45 ++++-------
> drivers/gpu/drm/mxsfb/Kconfig | 1 +
> drivers/gpu/drm/mxsfb/lcdif_drv.c | 88 +++++++++-------------
> include/drm/bridge/dw_hdmi.h | 5 ++
> 9 files changed, 174 insertions(+), 83 deletions(-)
> ---
> base-commit: 8402cf4fc8f8d5756dc81cf9fda1dccdb3622634
> change-id: 20260306-drm-lcdif-dbanc-83dd948327de
>
> Best regards,
^ permalink raw reply
* [PATCH] dt-bindings: gpio: fix microchip #interrupt-cells
From: Conor Dooley @ 2026-03-26 17:02 UTC (permalink / raw)
To: linux-gpio
Cc: conor, Jamie Gibbons, Conor Dooley, Daire McNamara, Linus Walleij,
Bartosz Golaszewski, Rob Herring, Krzysztof Kozlowski, devicetree,
linux-kernel
From: Jamie Gibbons <jamie.gibbons@microchip.com>
The GPIO controller on PolarFire SoC supports more than one type of
interrupt and needs two interrupt cells.
Fixes: 735806d8a68e9 ("dt-bindings: gpio: add bindings for microchip mpfs gpio")
Signed-off-by: Jamie Gibbons <jamie.gibbons@microchip.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
This has been downstream for ages, only noticed it was missing recently
when trying to add consumers.
CC: Conor Dooley <conor.dooley@microchip.com>
CC: Daire McNamara <daire.mcnamara@microchip.com>
CC: Linus Walleij <linusw@kernel.org>
CC: Bartosz Golaszewski <brgl@kernel.org>
CC: Rob Herring <robh@kernel.org>
CC: Krzysztof Kozlowski <krzk+dt@kernel.org>
CC: linux-gpio@vger.kernel.org
CC: devicetree@vger.kernel.org
CC: linux-kernel@vger.kernel.org
---
.../devicetree/bindings/gpio/microchip,mpfs-gpio.yaml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml b/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml
index 184432d24ea18..f42c54653d521 100644
--- a/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml
@@ -37,7 +37,7 @@ properties:
const: 2
"#interrupt-cells":
- const: 1
+ const: 2
ngpios:
description:
@@ -86,7 +86,7 @@ examples:
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
interrupts = <53>, <53>, <53>, <53>,
<53>, <53>, <53>, <53>,
<53>, <53>, <53>, <53>,
--
2.53.0
^ permalink raw reply related
* RE: [PATCH v9 00/21] media: i2c: add Maxim GMSL2/3 serializer and deserializer drivers
From: Dayananda, Vivekananda @ 2026-03-26 17:00 UTC (permalink / raw)
To: dumitru.ceclan@analog.com, Tomi Valkeinen, Mauro Carvalho Chehab,
Sakari Ailus, Laurent Pinchart, Julien Massot, Rob Herring,
Niklas Söderlund, Greg Kroah-Hartman, Cosmin Tanislav
Cc: mitrutzceclan@gmail.com, linux-media@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-staging@lists.linux.dev, linux-gpio@vger.kernel.org,
Niklas Söderlund, martin.hecht@avnet.eu, Tomi Valkeinen,
Cosmin Tanislav, Cory Keitz
In-Reply-To: <20260311-gmsl2-3_serdes-v9-0-41499f09004f@analog.com>
[AMD Official Use Only - AMD Internal Distribution Only]
Hi Dumitru, Sakari,
Thank you for the latest patch series. We have been validating this
on the following test infrastructure:
- IMX219 image sensor
- MAX96724 deserializer
- MAX96717 serializer
With this setup the v9 drivers operate as expected and we are able to
exercise streaming end-to-end.
One item worth noting: our deserializer sits on a custom daughter card
where the I2C bus is routed through port 1. The current MAX96724 driver
only supports I2C on port 0. It would be valuable to extend the driver
to support additional I2C port configurations so that setups like ours
can be accommodated.
Vivek
> -----Original Message-----
> From: Dumitru Ceclan via B4 Relay
> <devnull+dumitru.ceclan.analog.com@kernel.org>
> Sent: Wednesday, March 11, 2026 12:17 AM
> To: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>; Mauro
> Carvalho Chehab <mchehab@kernel.org>; Sakari Ailus
> <sakari.ailus@linux.intel.com>; Laurent Pinchart
> <laurent.pinchart@ideasonboard.com>; Julien Massot
> <julien.massot@collabora.com>; Rob Herring <robh@kernel.org>; Niklas
> Söderlund <niklas.soderlund@ragnatech.se>; Greg Kroah-Hartman
> <gregkh@linuxfoundation.org>; Cosmin Tanislav <cosmin.tanislav@analog.com>
> Cc: mitrutzceclan@gmail.com; linux-media@vger.kernel.org; linux-
> kernel@vger.kernel.org; devicetree@vger.kernel.org; linux-
> staging@lists.linux.dev; linux-gpio@vger.kernel.org; Niklas Söderlund
> <niklas.soderlund+renesas@ragnatech.se>; Martin Hecht
> <Martin.Hecht@avnet.eu>; Tomi Valkeinen
> <tomi.valkeinen@ideasonboard.com>; Cosmin Tanislav
> <demonsingur@gmail.com>; Cory Keitz <ckeitz@amazon.com>
> Subject: [PATCH v9 00/21] media: i2c: add Maxim GMSL2/3 serializer and
> deserializer drivers
>
> This series adds new drivers for multiple Maxim GMSL2 and GMSL3 devices,
> replacing the few GMSL2 drivers already in upstream, and introducing a common
> framework that can be used to implement such GMSL chips, which avoids code
> duplication while also adding support for previously unsupported features.
>
> While the normally acceptable and polite way would be to extend the current
> mainline drivers, the choice was made here to add a totally new set of drivers.
> The current drivers support only a small subset of the possible features, and only
> a few devices, so the end result after extending them would in any case be
> essentially fully rewritten, new drivers.
>
> This series depends on support for internal pads, for which a patch has been
> added.
>
> The previous version is at:
> https://lore.kernel.org/all/20250718152500.2656391-1-
> demonsingur@gmail.com/
>
> Since the previous series, Cosmin has left Analog Devices.
> Because included changes from previous version are trivial, his sign-off and tags
> were retained.
>
> The following deserializers are supported:
> * MAX96712 (already exists in staging)
> * MAX96714 (already exists)
> * MAX96714F (already exists)
> * MAX96714R (GMSL2)
> * MAX96716 (GMSL2)
> * MAX96724 (already exists as part of existing MAX96712 driver)
> * MAX96724F (GMSL2)
> * MAX96724R (GMSL2)
> * MAX9296A (GMSL2)
> * MAX96792A (GMSL3)
>
> The following serializers are supported:
> * MAX96717 (already exists)
> * MAX9295A (GMSL2)
> * MAX96793 (GMSL3)
>
> The following list enumerates new features that are supported by the common
> framework and their respective chip-specific drivers:
> * Full Streams API support. Most deserializers have support for more than one
> link, and more than one PHY. Streams support allows configuration of routing
> between these links and PHYs.
>
> * .get_frame_desc() support. Both the serializers and deserializers implement this
> to query and provide frame descriptor data. This is used in features explained in-
> depth below.
>
> * .get_mbus_config() support. The deserializers implement this to allow upstream
> devices to query the link frequency of its pads.
>
> * Address translation with I2C ATR for the serializers.
>
> * I2C ATR translation - some deserializers cannot do muxing since I2C
> communication channel masking is not available per-link, and the only other way
> to select links is to turn them off, causing link resets.
> For such cases, I2C ATR is used to change the address of the serializers at probe
> time.
>
> * Automatic GMSL link version negotiation between GMSL3, GMSL2 6Gbps,
> GMSL2 3Gbps.
>
> * Automatic stream id selection for deserializers which need serializers to stream
> on unique stream ids.
>
> * Automatic VC remapping on the deserializers. VCs are picked so that if they
> were unique on the sink pad, they will end up as unique on the source pad they
> are routed to too, prioritizing using the same VC ID as the sink pad, to facilitate
> the possibility of using tunnel mode.
>
> * Automatic pixel mode / tunnel mode selection. Tunnel mode is used when VC
> IDs do not need to be changed and all hardware supports tunnel mode,
> otherwise, pixel mode is used. The serializers are automatically switched
> between the two by using a private API.
>
> * Automatic double mode selection. In pixel mode, double mode can be used to
> pack two pixels into a single data unit, optimizing bandwidth usage. The
> serializers are automatically set up to support the double modes determined by
> the deserializers using a private API.
>
> * Automatic data padding. In pixel mode, if the data being transferred uses two
> different BPPs, data needs to be padded. The serializers automatically set this up
> depending on the configured double mode settings and incoming data types.
>
> * Logging. Both the deserializers and serializers implement the V4L2
> .log_status() ops to allow debugging of the internal state and important chip
> status registers.
>
> * PHY modes. Deserializer chips commonly have more than a single PHY.
> The firmware ports are parsed to determine the modes in which to configure the
> PHYs (2x4, 4x2, 1x4+2x2, 2x2+1x4, and variations using fewer lanes).
>
> * Serializer pinctrl. Serializers implement pinctrl to allow setting configs which
> would otherwise be inaccessible through GPIO: TX/RX via GMSL link, pull-up &
> pull-down (with strength), open-drain & push-pull, slew rate, RCLK pin selection.
>
> * TPG with selectable formats, resolutions and framerates for both serializers and
> deserializers.
>
> The drivers have been tested on the following hardware combinations, but further
> testing is welcome to ensure no / minimal breakage:
> * Raspberry Pi 5 + MAX9296A + 2xMAX96717 + 2xIMX219
> * Raspberry Pi 5 + MAX96714 + 1xMAX96717 + 1xIMX219
> * Raspberry Pi 5 + MAX96716A + 2xMAX96717 + 2xIMX219
> * Raspberry Pi 5 + MAX96712 + 4xMAX96717 + 4xIMX219
> * Raspberry Pi 5 + MAX96724 + 4xMAX96717 + 4xIMX219
> * Raspberry Pi 5 + MAX96792A + 1xMAX96793 + 1xMAX96717 + 2xIMX219
> * Raspberry Pi 5 + MAX96792A + 2xMAX96717 + 2xIMX219
> * Renesas V4H + MAX96712 + 2xMAX96717 + 2xIMX219
>
> Analog Devices is taking responsibility for the maintenance of these drivers and
> common framework, and plans to add support for new broad-market chips on top
> of them.
>
> Special thanks go to Tomi Valkeinen <
> tomi.valkeinen+renesas@ideasonboard.com>
> for testing the drivers, helping debug and coming up with ideas / implementations
> for various features.
>
> The following v4l2-compliance test still fails:
> fail: v4l2-test-subdevs.cpp(371): fmt.code == 0 || fmt.code == ~0U
> fail: v4l2-test-subdevs.cpp(418): checkMBusFrameFmt(node, fmt.format)
> test Active VIDIOC_SUBDEV_G/S_FMT: FAIL
>
> As the serializers and deserializers are format agnostic and the values set are not
> used to configure anything in the chips, this test does not make much sense in this
> context. If needed, a check for the specific ~0U value can be added.
>
> V9:
> * split max_des_ops into *_info and *_ops
> * use read_poll_timeout macro in *_wait_for_device()
> * return read_poll_timeout error -ETIMEDOUT in *_wait_for_device()
> * remove use_atr duplicate from max9296a_chip_info, present in max_des_info
> * fix max9296a DPLL register offset
> * fix C-PHY DPLL frequency in max9296a and max96724
> reported by: Cory Keitz <ckeitz@amazon.com>
> * use MAX9296A_COMMON_INFO and MAX9296A_COMMON_OPS to simplify
> probe ops init
> * fix borked patches in previous version, actually remove MAX96717 and
> MAX96714 drivers
>
> V8:
> * max96717: use the renamed PIN_CONFIG_OUTPUT to _LEVEL
> * max96717: use the renamed set_rv ops from struct gpio_chip
> * dt-bindings: set minItems lane-polarities to 2
> * dt-bindings: "add myself as maintainer" commits were removed
> * max_des & max_ser: use a default format for set_routing
> * max_des & max_ser: return ENNOTTY in *_frame_interval for non-TPG pads
>
> V7:
> * dt-bindings: max9296a: use full max96717 compatible
> * max9296a: make max96714_rlms_reg_sequence static
> * explicitly include linux/bitfield.h
> * explicitly depend on I2C and PINCTRL
> * sort media_entity_operations
> * add has_pad_interdep to media_entity_operations
>
> V6:
> * max9296a: put rlms sequence in max9296a_chip_info
> * max_des: reflow stream id a comment
> * max_ser: remove exported symbols not used in other modules
> * max_ser: init mode to a supported value
> * add default routing
> * MAX_SERDES_GMSL_3 -> MAX_SERDES_GMSL_3_12GBPS
> * guard reg_read/write with CONFIG_VIDEO_ADV_DEBUG
> * put exported symbols in MAXIM_SERDES namespace
>
> V5:
> * dt-bindings: max96717: restrict RCLKOUT to pins 2 & 4
> * dt-bindings: max96717: remove confusing rclksel pinconf property
> * dt-bindings: max96717: remove maxim,gmsl-tx/rx pinconf property
> * dt-bindings: max96717: remove gmsl prefix from maxim,gmsl-tx-id/rx-id
> * dt-bindings: max96717: remove minimum: 0
> * dt-bindings: max96717: better document slew-rate
> * dt-bindings: max96717: better document maxim,jitter-compensation
> * dt-bindings: max96717: better document maxim,tx-id/rx-id
>
> * max_serdes: add default TPG values
> * max_serdes: remove MAX_MIPI_FMT macro
> * max_serdes: EXPORT_SYMBOL -> EXPORT_SYMBOL_GPL
> * max_serdes: remove EXPORT_SYMBOL_GPL from symbols not used in other
> modules
> * max_serdes: rename symbols/macros/types to have max_serdes prefix
> * max_serdes: slim down TPG functions
>
> * max_des: fix may be used uninitialized errors
> * max_des: fix misplaced TPG validation
> * max_des: fix setting pipe PHY in tunnel mode for chips that support both
> set_pipe_phy() and set_pipe_tunnel_phy()
> * max_des: move doubled_bpp/sink_bpps variables to usage place
> * max_des: do not dynamically control PHY enable, letting lanes be in
> LP-11 when not streaming
> * max_des: refactor get/set_pipe_stream_id() logic
> * max_des: remove explicit ret = 0
>
> * max_ser: make VC remaps not pipe-specific, allocate dynamically
>
> * max9296a: add missing 1080p30 TPG entry
> * max9296a: move BIT() left shift into macro
> * max9296a: move BIT() ternary into macro
> * max9296a: reuse max_des_ops for chip-specific ops\
> * max9296a: document and compress RLMS register writes
>
> * max96717: restrict RCLKOUT to pins 2 & 4 because of hardware capabilities
> * max96717: add support for XTAL/1, XTAL/2, XTAL/4 clocks
> * max96717: set RX_EN/TX_EN automatically
> * max96717: reorder custom pinconf flags
> * max96717: drop OF dependency
>
> * drop of_match_ptr
> * re-do some indentation
> * implement TPG pattern control
> * remove pr_info() usage
> * inline lane polarity val = 0
> * inline returns
> * rewrite some Kconfig docs
> * split up patches for easier review
>
> V4:
> * max_des: fix infinite version loop
> * max_des: fix pipe link id when there are more pipes than links
> * max_des: implement setting pipe link
> * max_des: do not pass routing to phy update
> * max_des: move GMSL version strings to max_serdes
> * max_des: split finding existing VC remap from adding a new one
> * max_des: add tracking for in-use pipes
> * max_des: skip unused pipes when finding / setting pixel/tunnel mode
> * max_des: simplify remap code
> * max_des: split set_pipe_phy() into set_pipe_tunnel_phy()
>
> * max_ser: clean up i2c_xlates printing
> * max_ser: fix changing serializer address
> * max_ser: move non-continuous mode check into max96717 driver
>
> * max96724: use regmap_set_bits for STREAM_SEL_ALL
> * max96724: match surrounding indent for MAX96724_PHY1_ALT_CLOCK
> * max96724: fix setting invalid PHY to 1 when PHY 0 is in 4-lane mode
> * max96724: remove support for setting pipe phy from max96712
> * max96724: fix setting double mode on pipes 4-7
> * max96724: drop powerdown gpios
>
> * max96717: use gpio_chip's set_rv
>
> * max9296a: switch versions to unsigned int
> * max9296a: remove parantheses from MAX9296A_MIPI_PHY18/20
> * max9296a: fix printing of PHY packet counts
> * max9296a: fix phy_hw_ids size
>
> * remove usage of cammel case in defines
> * move field_get/prep to max_serdes.h
> * rework stream id setup
> * rework tunnel/pixel mode finding
> * rework bpps retrieval
> * pass whole subdev state around
> * add helper for retrieving a route's hw components / frame desc
> * update pipe enable based on active routes
> * add support for tunnel-only chips and VC remaps in tunnel mode
> * simplify max_get_streams_masks()
> * add support for TPG
>
> V3:
> * dt-bindings: drop reflow text patches
>
> * dt-bindings: max96717: move pinctrl configuration into main file
> * dt-bindings: max96717: allow a single level of pins configuration
> * dt-bindings: max96717: use regex for matching pins nodes
> * dt-bindings: max96717: drop extra allOf in pinctrl configuration
> * dt-bindings: max96717: fix i2c-atr channel name regex
> * dt-bindings: max96717: limit pinctrl functions to gpio / rclkout
> * dt-bindings: max96717: limit pins for gpio / rclkout
> * dt-bindings: max96717: add description for bias-pull-up/down
> * dt-bindings: max96717: require pins and function properties
> * dt-bindings: max96717: turn single compatible strings into an enum
>
> * dt-bindings: max9296a: include indices in port descriptions
> * dt-bindings: max9296a: remove property-less schema from input ports
> * dt-bindings: max9296a: use ATR for MAX96716A too, removing MUX entirely
>
> * dt-bindings: max96712: include indices in port descriptions
> * dt-bindings: max96712: deprecate enable-gpios in favor of powerdown-gpios
> * dt-bindings: max96712: switch from MUX to ATR
>
> * dt-bindings: max96714: add support for MAX96714R
>
> * max_des: fix POC NULL check
> * max_des: remove index var in POC enable
> * max_des: fix writing empty remaps
> * max_des: skip mode setting in tunnel mode
> * max_des: remove a duplicate source->sd NULL check
> * max_des: set pipe tunnel mode even for disabled links
>
> * max_ser: apply TX ID changes irrespective of serializer ID
>
> * max9296a: fix typo in BACKTOP22
> * max9296a: make register macros more consistent
> * max9296a: switch MAX96716 from MUX to ATR
> * max9296a: deduplicate max9296a_phy_id() logic
> * max9296a: use proper PHY id in remaps
> * max9296a: fix DPLL reset clear
> * max9296a: limit MAX96714F to GMSL2 3Gbps
> * max9296a: add support for MAX96714R
> * max9296a: do not write GMSL3 link select registers in GMSL2 devices
> * max9296a: use field_prep when setting RX_RATE
> * max9296a: simplify setting SEL_STREAM for MAX96714
> * max9296a: max96716_set_pipe_phy -> max96716a_set_pipe_phy
> * max9296a: fix off-by-one in lane polarity when using
> polarity_on_physical_lanes
>
> * max96724: fix typo in BACKTOP22
> * max96724: switch from MUX to ATR
> * max96724: add support for powerdown GPIO
> * max96724: remove support for tunneling from MAX96712
> * max96724: only set tunnel-related bits when in tunnel mode
> * max96724: add support for MAX96724F/R
> * max96724: oneshot reset links after link selection
>
> * remove GMSL2 version defaults, set all supported versions explicitly
> * reorder GMSL versions to start from 0
> * add support for GMSL2 3Gbps
> * support GMSL version finding for devices using MUX / GATE
> * add support for deserializers which don't have individual control of each link's
> GMSL version
> * add support for deserializers that need unique stream ids across all serializers
> * select_link_version -> set_link_version
> * select_resets_link -> use_atr
>
> V2:
> * add missing compatible for MAX96717F
> * fix embarrassing dt-bindings mistakes
> * move MAX9296A/MAX96716/MAX96792A to a separate file as they have two
> links / PHYs, and adding those conditionally seems impossible
> ---
> Cosmin Tanislav (20):
> dt-bindings: media: i2c: max96717: add support for I2C ATR
> dt-bindings: media: i2c: max96717: add support for pinctrl/pinconf
> dt-bindings: media: i2c: max96717: add support for MAX9295A
> dt-bindings: media: i2c: max96717: add support for MAX96793
> dt-bindings: media: i2c: max96712: use pattern properties for ports
> dt-bindings: media: i2c: max96712: add support for I2C ATR
> dt-bindings: media: i2c: max96712: add support for POC supplies
> dt-bindings: media: i2c: max96712: add support for MAX96724F/R
> dt-bindings: media: i2c: max96714: add support for MAX96714R
> dt-bindings: media: i2c: add MAX9296A, MAX96716A, MAX96792A
> media: i2c: add Maxim GMSL2/3 serializer and deserializer framework
> media: i2c: add Maxim GMSL2/3 serializer framework
> media: i2c: add Maxim GMSL2/3 deserializer framework
> media: i2c: maxim-serdes: add MAX96717 driver
> media: i2c: maxim-serdes: add MAX96724 driver
> media: i2c: maxim-serdes: add MAX9296A driver
> arm64: defconfig: disable deprecated MAX96712 driver
> staging: media: remove MAX96712 driver
> media: i2c: remove MAX96717 driver
> media: i2c: remove MAX96714 driver
>
> Sakari Ailus (1):
> media: mc: Add INTERNAL pad flag
>
> .../bindings/media/i2c/maxim,max9296a.yaml | 242 ++
> .../bindings/media/i2c/maxim,max96712.yaml | 65 +-
> .../bindings/media/i2c/maxim,max96714.yaml | 5 +-
> .../bindings/media/i2c/maxim,max96717.yaml | 154 +-
> .../userspace-api/media/mediactl/media-types.rst | 9 +
> MAINTAINERS | 10 +-
> arch/arm64/configs/defconfig | 1 -
> drivers/media/i2c/Kconfig | 34 +-
> drivers/media/i2c/Makefile | 3 +-
> drivers/media/i2c/max96714.c | 1017 -------
> drivers/media/i2c/max96717.c | 1102 -------
> drivers/media/i2c/maxim-serdes/Kconfig | 60 +
> drivers/media/i2c/maxim-serdes/Makefile | 6 +
> drivers/media/i2c/maxim-serdes/max9296a.c | 1358 +++++++++
> drivers/media/i2c/maxim-serdes/max96717.c | 1686 +++++++++++
> drivers/media/i2c/maxim-serdes/max96724.c | 1193 ++++++++
> drivers/media/i2c/maxim-serdes/max_des.c | 3188
> ++++++++++++++++++++
> drivers/media/i2c/maxim-serdes/max_des.h | 156 +
> drivers/media/i2c/maxim-serdes/max_ser.c | 2138 +++++++++++++
> drivers/media/i2c/maxim-serdes/max_ser.h | 147 +
> drivers/media/i2c/maxim-serdes/max_serdes.c | 413 +++
> drivers/media/i2c/maxim-serdes/max_serdes.h | 183 ++
> drivers/media/mc/mc-entity.c | 15 +-
> drivers/staging/media/Kconfig | 2 -
> drivers/staging/media/Makefile | 1 -
> drivers/staging/media/max96712/Kconfig | 14 -
> drivers/staging/media/max96712/Makefile | 2 -
> drivers/staging/media/max96712/max96712.c | 487 ---
> include/uapi/linux/media.h | 1 +
> 29 files changed, 11006 insertions(+), 2686 deletions(-)
> ---
> base-commit: a15a902a91b78f1544760fb52ef0151f83815f81
> change-id: 20251107-gmsl2-3_serdes-3f2b885209c3
>
> Best regards,
^ permalink raw reply
* Re: [PATCH net-next v2 4/4] net: phy: Introduce Airoha AN8801/R Gigabit Ethernet PHY driver
From: Andrew Lunn @ 2026-03-26 16:56 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Louis-Alexis Eyraud, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, AngeloGioacchino Del Regno, Heiner Kallweit,
kevin-kw.huang, macpaul.lin, matthias.bgg, kernel, netdev,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <acVQQQiciPQBkQOG@shell.armlinux.org.uk>
> What is the timing requirements for a system going into suspend vs a WoL
> packet being sent? Should a WoL packet abort entry into suspend? If yes,
> then we need to program the MAC before the PHY is suspended, because
> suspend could already be in progress.
We would then need to hook into the NETDEV_CHANGEADDR notifier, and
call into the PHY driver to let it reprogram the MAC address.
Andrew
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: Move board nodes to common DTSI
From: Sibi Sankar @ 2026-03-26 16:55 UTC (permalink / raw)
To: Krzysztof Kozlowski, Gopikrishna Garmidi, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, rajendra.nayak
In-Reply-To: <03996c07-f9f3-4586-96ae-075927da2577@kernel.org>
On 3/26/2026 7:55 PM, Krzysztof Kozlowski wrote:
> On 26/03/2026 15:21, Gopikrishna Garmidi wrote:
>> The display, peripherals (touchpad/touchscreen/keypad), usb and their
>> dependent device nodes are common to both Glymur and Mahua CRDs,
>> so move them from glymur-crd.dts to glymur-crd.dtsi to enable code
>> reuse.
>>
> Same questions as for earlier tries (why this has to be repeated?), e.g.
> x1-crd: Please describe here what is the actual common hardware. In
> terms of physical hardware, not what you want to share.
There seems to be some kind of confusion here. This patch doesn't
introduce the common board file rather it just moves the nodes
mentioned in the commit message to the common board file.
https://lore.kernel.org/lkml/20260318124100.212992-3-gopikrishna.garmidi@oss.qualcomm.com/
The actual creation of the common board file was done ^^.
>
> Best regards,
> Krzysztof
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox