* [PATCH 2/4] drm/bridge: lontium-lt9611c: Increase MCU poll timeout to 200ms
From: Mohit Dsor @ 2026-06-10 21:14 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul
Cc: dri-devel, devicetree, linux-kernel, Mohit Dsor, boss,
qc-display-maintainer
In-Reply-To: <20260611-lt9611-b4-send-v1-0-42abbcd3bb1e@oss.qualcomm.com>
The on-chip MCU may take longer than 100ms to respond on some hardware
variants or slower I2C buses, causing spurious -ETIMEDOUT errors during
normal operation. Double the poll timeout from 100ms to 200ms to improve
reliability without changing the poll interval.
Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
---
drivers/gpu/drm/bridge/lontium-lt9611c.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611c.c b/drivers/gpu/drm/bridge/lontium-lt9611c.c
index cb584855fd8f..b0402726367e 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611c.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611c.c
@@ -97,7 +97,7 @@ static int lt9611c_read_write_flow(struct lt9611c *lt9611c, u8 *params,
regmap_write(lt9611c->regmap, 0xe0de, 0x01);
ret = regmap_read_poll_timeout(lt9611c->regmap, 0xe0ae, temp,
- temp == 0x01, 1000, 100 * 1000);
+ temp == 0x01, 1000, 200 * 1000);
if (ret)
return -ETIMEDOUT;
@@ -107,7 +107,7 @@ static int lt9611c_read_write_flow(struct lt9611c *lt9611c, u8 *params,
regmap_write(lt9611c->regmap, 0xe0de, 0x02);
ret = regmap_read_poll_timeout(lt9611c->regmap, 0xe0ae, temp,
- temp == 0x02, 1000, 100 * 1000);
+ temp == 0x02, 1000, 200 * 1000);
if (ret)
return -ETIMEDOUT;
--
2.34.1
^ permalink raw reply related
* [PATCH 3/4] drm-bridge: lontium lt9611c: fixes and improvements
From: Mohit Dsor @ 2026-06-10 21:14 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul
Cc: dri-devel, devicetree, linux-kernel, Mohit Dsor, boss,
qc-display-maintainer
In-Reply-To: <20260611-lt9611-b4-send-v1-0-42abbcd3bb1e@oss.qualcomm.com>
Remove two redundant lt9611c_reset() calls:
1. In lt9611c_bridge_atomic_pre_enable(): a reset is already performed
during probe and resume; calling it again on every display enable
adds ~440ms of unnecessary latency.
2. At the end of lt9611c_probe(): a reset was already performed earlier
in probe before lt9611c_lock(). The second reset is redundant.
Also, the DRM HDMI bridge framework requires hdmi_write_hdmi_infoframe and
hdmi_clear_hdmi_infoframe callbacks for HDMI vendor-specific infoframe
(VSI) support, used for features such as HDR metadata signalling.
This patch add stub implementations that return success. Wire them into the bridge
function table.
Also, Store the chip variant enum value in the of_match_table .data field and
retrieve it via of_device_get_match_data() when probing from a DT node.
Fall back to i2c_device_id.driver_data for non-DT (e.g. ACPI) probe
paths.
This is the standard kernel pattern for passing per-compatible data
through the OF match table, and avoids relying solely on the I2C device
ID table for chip type detection when DT is available.
Populate bridge.vendor and bridge.product so the DRM HDMI framework can
report the correct manufacturer and product name in the HDMI connector
properties (visible via xrandr --prop and related sysfs entries).
Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
---
drivers/gpu/drm/bridge/lontium-lt9611c.c | 31 ++++++++++++++++++++++++++-----
1 file changed, 26 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611c.c b/drivers/gpu/drm/bridge/lontium-lt9611c.c
index b0402726367e..fe51f4978546 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611c.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611c.c
@@ -622,7 +622,6 @@ static void lt9611c_bridge_atomic_pre_enable(struct drm_bridge *bridge,
ret = regulator_bulk_enable(ARRAY_SIZE(lt9611c->supplies), lt9611c->supplies);
if (ret)
dev_err(lt9611c->dev, "regulator bulk enable failed.\n");
- lt9611c_reset(lt9611c);
}
static void lt9611c_bridge_atomic_enable(struct drm_bridge *bridge,
@@ -777,6 +776,17 @@ static int lt9611c_hdmi_clear_avi_infoframe(struct drm_bridge *bridge)
return 0;
}
+static int lt9611c_hdmi_write_hdmi_infoframe(struct drm_bridge *bridge,
+ const u8 *buffer, size_t len)
+{
+ return 0;
+}
+
+static int lt9611c_hdmi_clear_hdmi_infoframe(struct drm_bridge *bridge)
+{
+ return 0;
+}
+
static int lt9611c_hdmi_write_audio_infoframe(struct drm_bridge *bridge,
const u8 *buffer, size_t len)
{
@@ -895,6 +905,8 @@ static const struct drm_bridge_funcs lt9611c_bridge_funcs = {
.hdmi_tmds_char_rate_valid = lt9611c_hdmi_tmds_char_rate_valid,
.hdmi_write_avi_infoframe = lt9611c_hdmi_write_avi_infoframe,
.hdmi_clear_avi_infoframe = lt9611c_hdmi_clear_avi_infoframe,
+ .hdmi_write_hdmi_infoframe = lt9611c_hdmi_write_hdmi_infoframe,
+ .hdmi_clear_hdmi_infoframe = lt9611c_hdmi_clear_hdmi_infoframe,
.hdmi_write_audio_infoframe = lt9611c_hdmi_write_audio_infoframe,
.hdmi_clear_audio_infoframe = lt9611c_hdmi_clear_audio_infoframe,
@@ -1025,6 +1037,13 @@ static int lt9611c_probe(struct i2c_client *client)
lt9611c->dev = dev;
lt9611c->client = client;
lt9611c->chip_type = id->driver_data;
+
+ if (dev->of_node) {
+ lt9611c->chip_type = (uintptr_t)of_device_get_match_data(dev);
+ } else {
+ lt9611c->chip_type = id->driver_data;
+ }
+
ret = devm_mutex_init(dev, <9611c->ocm_lock);
if (ret)
return dev_err_probe(dev, ret, "failed to init mutex\n");
@@ -1111,6 +1130,9 @@ static int lt9611c_probe(struct i2c_client *client)
DRM_BRIDGE_OP_HDMI_AUDIO;
lt9611c->bridge.type = DRM_MODE_CONNECTOR_HDMIA;
+ lt9611c->bridge.vendor = "Lontium";
+ lt9611c->bridge.product = "LT9611C";
+
lt9611c->bridge.hdmi_audio_dev = dev;
lt9611c->bridge.hdmi_audio_max_i2s_playback_channels = 8;
lt9611c->bridge.hdmi_audio_dai_port = 2;
@@ -1136,7 +1158,6 @@ static int lt9611c_probe(struct i2c_client *client)
lt9611c->hdmi_connected = false;
i2c_set_clientdata(client, lt9611c);
enable_irq(client->irq);
- lt9611c_reset(lt9611c);
return 0;
@@ -1214,9 +1235,9 @@ static struct i2c_device_id lt9611c_id[] = {
};
static const struct of_device_id lt9611c_match_table[] = {
- { .compatible = "lontium,lt9611c" },
- { .compatible = "lontium,lt9611ex" },
- { .compatible = "lontium,lt9611uxd" },
+ { .compatible = "lontium,lt9611c", .data = (void *)CHIP_LT9611C },
+ { .compatible = "lontium,lt9611ex", .data = (void *)CHIP_LT9611EX },
+ { .compatible = "lontium,lt9611uxd", .data = (void *)CHIP_LT9611UXD },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, lt9611c_match_table);
--
2.34.1
^ permalink raw reply related
* [PATCH 4/4] drm/bridge: lontium-lt9611c: Add DSI port selection via DT property
From: Mohit Dsor @ 2026-06-10 21:14 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul
Cc: dri-devel, devicetree, linux-kernel, Mohit Dsor, boss,
qc-display-maintainer
In-Reply-To: <20260611-lt9611-b4-send-v1-0-42abbcd3bb1e@oss.qualcomm.com>
Some board designs connect only DSI port B, or both DSI ports A and B,
to the LT9611C. Add support for a 'lontium,port-select' DT property that
allows the board DTS to specify which DSI port(s) the chip should use:
0 = PORT_SELECT_A (default, single DSI port A)
1 = PORT_SELECT_B (single DSI port B)
2 = PORT_SELECT_AB (dual DSI ports A+B)
When the property is absent the driver defaults to PORT_SELECT_A (0),
preserving backward compatibility with existing DTS files.
The selected port is programmed into the chip via lt9611c_select_port()
during probe, after the chip ID has been verified.
Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
---
drivers/gpu/drm/bridge/lontium-lt9611c.c | 44 ++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611c.c b/drivers/gpu/drm/bridge/lontium-lt9611c.c
index fe51f4978546..5d67bb7391fb 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611c.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611c.c
@@ -41,6 +41,12 @@ enum lt9611_chip_type {
CHIP_LT9611UXD,
};
+enum lt9611c_PORT_SELECT {
+ PORT_SELECT_A = 0,
+ PORT_SELECT_B = 1,
+ PORT_SELECT_AB = 2,
+};
+
struct lt9611c {
struct device *dev;
struct i2c_client *client;
@@ -60,6 +66,8 @@ struct lt9611c {
enum lt9611_chip_type chip_type;
/* HDMI cable connection status */
bool hdmi_connected;
+ /* Selected DSI port configuration */
+ int selected_port;
};
DECLARE_CRC8_TABLE(lt9611c_crc8_table);
@@ -115,6 +123,34 @@ static int lt9611c_read_write_flow(struct lt9611c *lt9611c, u8 *params,
return_count);
}
+static int lt9611c_select_port(struct lt9611c *lt9611c, int port_select)
+{
+ int ret;
+ u8 set_port_select_cmd[6] = {0x57, 0x4d, 0x31, 0x3a, 0x01, 0xc0};
+ u8 set_port_select_ret[5];
+
+ if (port_select == PORT_SELECT_B) {
+ set_port_select_cmd[5] = 0x40;
+ } else if (port_select == PORT_SELECT_AB) {
+ set_port_select_cmd[4] = 0x02;
+ set_port_select_cmd[5] = 0xd0;
+ } else if (port_select != PORT_SELECT_A) {
+ return -EINVAL;
+ }
+
+ /* MCU must be running (0xe0ee=0x00) for lt9611c_read_write_flow */
+ guard(mutex)(<9611c->ocm_lock);
+
+ ret = lt9611c_read_write_flow(lt9611c, set_port_select_cmd,
+ ARRAY_SIZE(set_port_select_cmd),
+ set_port_select_ret,
+ ARRAY_SIZE(set_port_select_ret));
+ if (ret < 0 || set_port_select_ret[4] == 0)
+ return ret < 0 ? ret : -EIO;
+
+ return 0;
+}
+
static void lt9611c_config_parameters(struct lt9611c *lt9611c)
{
const struct reg_sequence seq_write_paras[] = {
@@ -924,6 +960,10 @@ static int lt9611c_parse_dt(struct device *dev,
lt9611c->dsi1_node = of_graph_get_remote_node(dev->of_node, 1, -1);
+ if (of_property_read_u32(dev->of_node, "lontium,port-select",
+ <9611c->selected_port))
+ lt9611c->selected_port = 0;
+
return drm_of_find_panel_or_bridge(dev->of_node, 2, -1, NULL, <9611c->bridge.next_bridge);
}
@@ -1070,6 +1110,10 @@ static int lt9611c_probe(struct i2c_client *client)
lt9611c_reset(lt9611c);
+ ret = lt9611c_select_port(lt9611c, lt9611c->selected_port);
+ if (ret < 0)
+ dev_err(lt9611c->dev, "failed to select port %d\n", lt9611c->selected_port);
+
lt9611c_lock(lt9611c);
ret = lt9611c_read_chipid(lt9611c);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v1 1/2] dt-bindings: sound: add qcom,wsa885x-i2c
From: Linus Walleij @ 2026-06-10 21:20 UTC (permalink / raw)
To: Prasad Kumpatla
Cc: Srinivas Kandagatla, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela, Takashi Iwai,
Bartosz Golaszewski, Srinivas Kandagatla, linux-arm-msm,
linux-sound, devicetree, linux-kernel, linux-gpio
In-Reply-To: <20260610155708.151067-2-prasad.kumpatla@oss.qualcomm.com>
Hi Prasad,
thanks for your patch!
On Wed, Jun 10, 2026 at 5:57 PM Prasad Kumpatla
<prasad.kumpatla@oss.qualcomm.com> wrote:
> Document the Qualcomm WSA885X I2C smart amplifier binding.
Skip I2C? We don't need to tell e.g. "PCI" in some device on PCI and
there is no reason to mention I2C for this device, the fact that it sits
on an I2C bus will be apparent later.
> Describe the required supplies, powerdown and interrupt GPIOs, the
> optional battery configuration, and the optional init-table property
> used to program the device during codec initialization.
>
> This matches the driver programming model and documents the DT data
> needed to use the codec on platforms with Audio IF playback.
>
> Signed-off-by: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com>
Perhaps add
Link: https://www.qualcomm.com/audio/applications/compute-and-mobile-audio/products/wsa8815
(...)
> ---
> .../bindings/sound/qcom,wsa885x-i2c.yaml | 89 +++++++++++++++++++
> 1 file changed, 89 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/qcom,wsa885x-i2c.yaml
>
> diff --git a/Documentation/devicetree/bindings/sound/qcom,wsa885x-i2c.yaml b/Documentation/devicetree/bindings/sound/qcom,wsa885x-i2c.yaml
Drop the -i2c suffix on the files.
> new file mode 100644
> index 000000000..1069f470d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/qcom,wsa885x-i2c.yaml
> @@ -0,0 +1,89 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/qcom,wsa885x-i2c.yaml#
Drop the -i2c suffix.
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm WSA885x I2C smart speaker amplifier
Drop I2C.
> +maintainers:
> + - Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
> + - Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com>
> +
> +description: |
> + WSA885x is a Qualcomm Aqstic smart speaker amplifier with an I2C control
> + interface and a digital audio interface exposed through ASoC DAI callbacks.
> +
> +allOf:
> + - $ref: dai-common.yaml#
> +
> +properties:
> + compatible:
> + const: qcom,wsa885x-i2c
Drop -i2c
> + reg:
> + maxItems: 1
> +
> + '#sound-dai-cells':
> + const: 0
> +
> + powerdown-gpios:
> + description: GPIO controlling the SD_N powerdown pin.
> + maxItems: 1
> +
> + interrupt-gpios:
> + description: GPIO used for the codec interrupt output.
> + maxItems: 1
> +
> + vdd-1p8-supply: true
> +
> + vdd-io-supply: true
> +
> + qcom,battery-config:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: Speaker battery configuration, 1 for 1S and 2 for 2S.
What is a "1S" and a "2S"? Include description here.
> + default: 1
> + enum: [1, 2]
> +
> + qcom,wsa885x-init-table:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + minItems: 2
> + maxItems: 256
> + description: |
> + Sequence of register/value pairs applied during codec hardware
> + initialization. Entries are encoded as alternating register address and
> + register value cells. The number of entries must be even (register/value
> + pairs); maxItems is 256 (128 pairs).
Can this just be a table inside the driver, if it will be the same
array for every user? If this is board-unique then it needs to describe
what each value is actually doing well enough so engineers can use this
documentation right here to configure their board without looking through
register maps and what not.
Something more abstract using SI units etc is probably needed here.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v5 14/20] drm: renesas: rz-du: Add RZ/G3E support
From: Laurent Pinchart @ 2026-06-10 21:22 UTC (permalink / raw)
To: Tommaso Merciai
Cc: tomm.merciai, geert, linux-renesas-soc, biju.das.jz, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Michael Turquette, Stephen Boyd, Magnus Damm,
dri-devel, devicetree, linux-kernel, linux-clk
In-Reply-To: <abq6ohQW-LPcmXgy@tom-desktop>
Hi Tommaso,
On Wed, Mar 18, 2026 at 03:45:54PM +0100, Tommaso Merciai wrote:
> On Fri, Feb 13, 2026 at 05:27:40PM +0100, Tommaso Merciai wrote:
> > The RZ/G3E Soc has 2 LCD controller (LCDC), contain a Frame Compression
> > Processor (FCPVD), a Video Signal Processor (VSPD), Video Signal
> > Processor (VSPD), and Display Unit (DU).
> >
> > LCDC0 supports DSI and LVDS (single or dual-channel) outputs.
> > LCDC1 supports DSI, LVDS (single-channel), and RGB outputs.
> >
> > Depending on the selected output, the correct SMUX2 clock parent must be
> > chosen based on the requested duty cycle:
> >
> > - Index 0 for LVDS -> CDIV7_DSIx_CLK (DUTY H/L=4/3, 4/7 duty cycle)
> > - Index 1 for DSI/DPAD -> CSDIV_2to16_PLLDSIx (symmetric 50% duty cycle)
> >
> > To support this behavior, introduce the `RZG2L_DU_FEATURE_SMUX2_DSI_CLK`
> > feature flag and extend the `rzg2l_du_device_info` structure to include a
> > features field. Also, add a new helper function `rzg2l_du_has()` to check
> > for feature flags.
> >
> > Add support for the RZ/G3E SoC by introducing:
> > - `rzg2l_du_r9a09g047_du_info` structure
> > - The `renesas,r9a09g047-du` compatible string
> >
> > Additionally, introduce the missing output definitions
> > `RZG2L_DU_OUTPUT_LVDS{0,1}`.
> >
> > Introduce `rzg2l_du_crtc_atomic_check()` helper to store the routes from
> > the CRTC output to the DU outputs.
> >
> > Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> > ---
> > v4->v5:
> > - Fixed RG2L_DU_FEATURE_SMUX2_DSI_CLK to RZG2L_DU_FEATURE_SMUX2_DSI_CLK,
> > update commit body accordingly.
> > - Added features field documentation.
> >
> > v3->v4:
> > - No changes.
> >
> > v2->v3:
> > - No changes.
> >
> > v1->v2:
> > - Instead of using clk-provider API to select the right parent clock,
> > based on the outputs. Just set the correct duty cycle based on the
> > output, this reflects at CPG lvl to select the right parent.
> > - Updated commit message accordingly.
> >
> > drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 48 +++++++++++++++++++
> > drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c | 26 ++++++++++
> > drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h | 12 +++++
> > 3 files changed, 86 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> > index 6e7aac6219be..cc35dd409e3e 100644
> > --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> > @@ -64,11 +64,32 @@
> > static void rzg2l_du_crtc_set_display_timing(struct rzg2l_du_crtc *rcrtc)
> > {
> > const struct drm_display_mode *mode = &rcrtc->crtc.state->adjusted_mode;
> > + struct rzg2l_du_crtc_state *rstate =
> > + to_rzg2l_crtc_state(rcrtc->crtc.state);
> > unsigned long mode_clock = mode->clock * 1000;
> > u32 ditr0, ditr1, ditr2, ditr3, ditr4, pbcr0;
> > struct rzg2l_du_device *rcdu = rcrtc->dev;
> >
> > clk_prepare_enable(rcrtc->rzg2l_clocks.dclk);
> > +
> > + if (rzg2l_du_has(rcdu, RZG2L_DU_FEATURE_SMUX2_DSI_CLK)) {
> > + struct clk *clk_parent;
> > +
> > + clk_parent = clk_get_parent(rcrtc->rzg2l_clocks.dclk);
> > +
> > + /*
> > + * Request appropriate duty cycle to let clock driver select
> > + * the correct parent:
> > + * - CDIV7_DSIx_CLK (LVDS path) has DUTY H/L=4/3, 4/7 duty cycle.
> > + * - CSDIV_2to16_PLLDSIx (DSI/RGB path) has symmetric 50% duty cycle.
> > + */
> > + if (rstate->outputs == BIT(RZG2L_DU_OUTPUT_LVDS0) ||
> > + rstate->outputs == BIT(RZG2L_DU_OUTPUT_LVDS1))
> > + clk_set_duty_cycle(clk_parent, 4, 7);
> > + else
> > + clk_set_duty_cycle(clk_parent, 1, 2);
> > + }
> > +
>
> I’d appreciate any feedback/suggestions regarding this.
> Thank you in advance for your time.
Sorry for the very late reply.
I've taken time to analyse the clock tree, and I think the way you model
it makes sense. As the SMUX2_DSI[01]_CLK clocks are used by the LCD,
LVDS and DSI blocks, I may have selected the duty cycle in the LVDS and
DSI drivers personally. I wonder if it would lead to simpler code (you
wouldn't need to implement rzg2l_du_crtc_atomic_check()) here for
instance. In any case, it does not affect the DT bindings, so it could
be changed later too.
Do you need further feedback on this ?
> FYI this commit is related to [0]
>
> [0] https://patchwork.kernel.org/project/linux-renesas-soc/patch/53c8d9e7fde7b176e05503a72af81e74c7a8a1c1.1770996493.git.tommaso.merciai.xr@bp.renesas.com/
>
> Kind Regards,
> Tommaso
>
> > clk_set_rate(rcrtc->rzg2l_clocks.dclk, mode_clock);
> >
> > ditr0 = (DU_DITR0_DEMD_HIGH
> > @@ -248,6 +269,32 @@ static void rzg2l_du_crtc_stop(struct rzg2l_du_crtc *rcrtc)
> > * CRTC Functions
> > */
> >
> > +static int rzg2l_du_crtc_atomic_check(struct drm_crtc *crtc,
> > + struct drm_atomic_state *state)
> > +{
> > + struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state,
> > + crtc);
> > + struct rzg2l_du_crtc_state *rstate = to_rzg2l_crtc_state(crtc_state);
> > + struct drm_encoder *encoder;
> > +
> > + /* Store the routes from the CRTC output to the DU outputs. */
> > + rstate->outputs = 0;
> > +
> > + drm_for_each_encoder_mask(encoder, crtc->dev,
> > + crtc_state->encoder_mask) {
> > + struct rzg2l_du_encoder *renc;
> > +
> > + /* Skip the writeback encoder. */
> > + if (encoder->encoder_type == DRM_MODE_ENCODER_VIRTUAL)
> > + continue;
> > +
> > + renc = to_rzg2l_encoder(encoder);
> > + rstate->outputs |= BIT(renc->output);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > static void rzg2l_du_crtc_atomic_enable(struct drm_crtc *crtc,
> > struct drm_atomic_state *state)
> > {
> > @@ -296,6 +343,7 @@ static void rzg2l_du_crtc_atomic_flush(struct drm_crtc *crtc,
> > }
> >
> > static const struct drm_crtc_helper_funcs crtc_helper_funcs = {
> > + .atomic_check = rzg2l_du_crtc_atomic_check,
> > .atomic_flush = rzg2l_du_crtc_atomic_flush,
> > .atomic_enable = rzg2l_du_crtc_atomic_enable,
> > .atomic_disable = rzg2l_du_crtc_atomic_disable,
> > diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
> > index 0fef33a5a089..3c20471fdbea 100644
> > --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
> > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
> > @@ -51,6 +51,29 @@ static const struct rzg2l_du_device_info rzg2l_du_r9a07g044_info = {
> > }
> > };
> >
> > +static const struct rzg2l_du_device_info rzg2l_du_r9a09g047_du_info = {
> > + .features = RZG2L_DU_FEATURE_SMUX2_DSI_CLK,
> > + .channels_mask = BIT(0),
> > + .routes = {
> > + [RZG2L_DU_OUTPUT_DSI0] = {
> > + .possible_outputs = BIT(0),
> > + .port = 0,
> > + },
> > + [RZG2L_DU_OUTPUT_LVDS0] = {
> > + .possible_outputs = BIT(0),
> > + .port = 1,
> > + },
> > + [RZG2L_DU_OUTPUT_LVDS1] = {
> > + .possible_outputs = BIT(0),
> > + .port = 2,
> > + },
> > + [RZG2L_DU_OUTPUT_DPAD0] = {
> > + .possible_outputs = BIT(0),
> > + .port = 3,
> > + },
> > + },
> > +};
> > +
> > static const struct rzg2l_du_device_info rzg2l_du_r9a09g057_info = {
> > .channels_mask = BIT(0),
> > .routes = {
> > @@ -64,6 +87,7 @@ static const struct rzg2l_du_device_info rzg2l_du_r9a09g057_info = {
> > static const struct of_device_id rzg2l_du_of_table[] = {
> > { .compatible = "renesas,r9a07g043u-du", .data = &rzg2l_du_r9a07g043u_info },
> > { .compatible = "renesas,r9a07g044-du", .data = &rzg2l_du_r9a07g044_info },
> > + { .compatible = "renesas,r9a09g047-du", .data = &rzg2l_du_r9a09g047_du_info },
> > { .compatible = "renesas,r9a09g057-du", .data = &rzg2l_du_r9a09g057_info },
> > { /* sentinel */ }
> > };
> > @@ -74,6 +98,8 @@ const char *rzg2l_du_output_name(enum rzg2l_du_output output)
> > {
> > static const char * const names[] = {
> > [RZG2L_DU_OUTPUT_DSI0] = "DSI0",
> > + [RZG2L_DU_OUTPUT_LVDS0] = "LVDS0",
> > + [RZG2L_DU_OUTPUT_LVDS1] = "LVDS1",
> > [RZG2L_DU_OUTPUT_DPAD0] = "DPAD0"
> > };
> >
> > diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
> > index 58806c2a8f2b..480a7bdfcd66 100644
> > --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
> > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
> > @@ -20,8 +20,12 @@
> > struct device;
> > struct drm_property;
> >
> > +#define RZG2L_DU_FEATURE_SMUX2_DSI_CLK BIT(0) /* Per output mux */
> > +
> > enum rzg2l_du_output {
> > RZG2L_DU_OUTPUT_DSI0,
> > + RZG2L_DU_OUTPUT_LVDS0,
> > + RZG2L_DU_OUTPUT_LVDS1,
> > RZG2L_DU_OUTPUT_DPAD0,
> > RZG2L_DU_OUTPUT_MAX,
> > };
> > @@ -42,10 +46,12 @@ struct rzg2l_du_output_routing {
> >
> > /*
> > * struct rzg2l_du_device_info - DU model-specific information
> > + * @features: device features (RZG2L_DU_FEATURE_*)
> > * @channels_mask: bit mask of available DU channels
> > * @routes: array of CRTC to output routes, indexed by output (RZG2L_DU_OUTPUT_*)
> > */
> > struct rzg2l_du_device_info {
> > + unsigned int features;
> > unsigned int channels_mask;
> > struct rzg2l_du_output_routing routes[RZG2L_DU_OUTPUT_MAX];
> > };
> > @@ -73,6 +79,12 @@ static inline struct rzg2l_du_device *to_rzg2l_du_device(struct drm_device *dev)
> > return container_of(dev, struct rzg2l_du_device, ddev);
> > }
> >
> > +static inline bool rzg2l_du_has(struct rzg2l_du_device *rcdu,
> > + unsigned int feature)
> > +{
> > + return rcdu->info->features & feature;
> > +}
> > +
> > const char *rzg2l_du_output_name(enum rzg2l_du_output output);
> >
> > #endif /* __RZG2L_DU_DRV_H__ */
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] dt-bindings: vendor-prefixes: add Gira
From: Lucas Stach @ 2026-06-10 21:30 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley; +Cc: devicetree, kernel
Add vendor prefix for Gira Giersiepen GmbH & Co. KG
Link: https://www.gira.de/
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 28784d66ae7b..2b7bf7d7b9c2 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -656,6 +656,8 @@ patternProperties:
description: Giantec Semiconductor, Inc.
"^giantplus,.*":
description: Giantplus Technology Co., Ltd.
+ "^gira,.*":
+ description: Gira Giersiepen GmbH & Co. KG
"^glinet,.*":
description: GL Intelligence, Inc.
"^globalscale,.*":
--
2.47.3
^ permalink raw reply related
* Re: [net-next 3/3] arm64: dts: renesas: r8a779g0: Add gPTP node
From: sashiko-bot @ 2026-06-10 21:57 UTC (permalink / raw)
To: Niklas Söderlund; +Cc: robh, devicetree, conor+dt, wsa+renesas
In-Reply-To: <20260609215711.2960150-4-niklas.soderlund+renesas@ragnatech.se>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Device Tree Resource Conflict due to overlapping memory, clock, and reset regions between `tsn0` and `gptp`.
--
commit 225abba0fdcd1f7e4ebd535f168ba1447d871a7e
Author: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
arm64: dts: renesas: r8a779g0: Add gPTP node
The gPTP module is shared between the RAVB and RTSN Ethernet devices on
the SoC.
> diff --git a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi b/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
> index 82a7278836e57..758c4ca0ae5f2 100644
> --- a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
> @@ -603,6 +603,15 @@ tsn0: ethernet@e6460000 {
> status = "disabled";
> };
>
> + gptp: gptp@e6449000 {
> + compatible = "renesas,r8a779g0-gptp", "renesas,rcar-gen4-gptp";
> + reg = <0 0xe6449000 0 0x500>;
> + clocks = <&cpg CPG_MOD 2723>;
> + power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
> + resets = <&cpg 2723>;
[Severity: High]
Will this introduce a regression by duplicating resources already claimed by
the existing tsn0 node?
Looking at the tsn0 node earlier in this file:
tsn0: ethernet@e6460000 {
compatible = "renesas,r8a779g0-ethertsn", "renesas,rcar-gen4-ethertsn";
reg = <0 0xe6460000 0 0x7000>,
<0 0xe6449000 0 0x500>;
reg-names = "tsnes", "gptp";
interrupts = <GIC_SPI 429 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 430 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "tx", "rx";
clocks = <&cpg CPG_MOD 2723>;
power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
resets = <&cpg 2723>;
status = "disabled";
};
It appears tsn0 already claims the 0xe6449000 memory region, CPG_MOD 2723 clock,
and reset 2723.
If both drivers are enabled, will the second driver to probe fail when
requesting these overlapping resources, such as receiving -EBUSY from
devm_ioremap_resource() or request_mem_region()?
Should the overlapping resources be removed from the tsn0 node now that the
gPTP module is represented as a standalone shared node?
> + status = "disabled";
> + };
> +
> i2c0: i2c@e6500000 {
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260609215711.2960150-4-niklas.soderlund+renesas@ragnatech.se?part=1
^ permalink raw reply
* Re: [PATCH 2/2] MAINTAINERS: Add myself as maintainer for PMS7003
From: Maxwell Doose @ 2026-06-10 22:24 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:IIO SUBSYSTEM AND DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Tomasz Duszynski
In-Reply-To: <20260610-pastoral-dark-ostrich-5ca3f6@quoll>
On Wed, Jun 10, 2026 at 4:09 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Tue, Jun 09, 2026 at 11:03:26AM -0500, Maxwell Doose wrote:
> > Tomasz's entry is no longer valid, as he is not active anymore. Add
>
> Why is not longer valid? I see activity in Feb...
>
Strange. According to git log --author="Tomasz Duszynski" last commit
I have from him is 2023. We also did have an RFC open for a month on
linux-iio with Tomasz Cced with no response.
^ permalink raw reply
* Re: [PATCH 2/2] MAINTAINERS: Add myself as maintainer for SPS30
From: Maxwell Doose @ 2026-06-10 22:25 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:IIO SUBSYSTEM AND DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Tomasz Duszynski
In-Reply-To: <20260610-turquoise-marmot-of-research-c3c51c@quoll>
On Wed, Jun 10, 2026 at 4:10 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Tue, Jun 09, 2026 at 11:17:01AM -0500, Maxwell Doose wrote:
> > Tomasz's entry is no longer valid, as he is not active anymore. Add
> > myself as maintainer of the SPS30 to replace his entry.
>
> Same comments.
>
See response on pms7003 patch.
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: iio: sensirion,sps30: Add myself as maintainer
From: Maxwell Doose @ 2026-06-10 22:27 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:IIO SUBSYSTEM AND DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Tomasz Duzsynski
In-Reply-To: <20260610-silver-elk-of-eternity-2beed0@quoll>
On Wed, Jun 10, 2026 at 4:10 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Tue, Jun 09, 2026 at 11:17:00AM -0500, Maxwell Doose wrote:
> > Tomasz's entry is no longer valid, as he is not active anymore. Add
> > myself as maintainer for the SPS30 to replace his entry.
> >
> > Link: https://lore.kernel.org/linux-iio/20260609140712.2e5d1640@jic23-huawei/
> > Cc: Tomasz Duzsynski <tduszyns@gmail.com>
> > Signed-off-by: Maxwell Doose <m32285159@gmail.com>
> > ---
> > .../devicetree/bindings/iio/chemical/sensirion,sps30.yaml | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> How many separate patches are you going to send?
>
Sorry. I guess the reason these are separate patches is because these
are basically across two different subsystems (iio and dt-bindings). I
ought to quit doing this.
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: iio: plantower,pms7003: Add myself as maintainer
From: Maxwell Doose @ 2026-06-10 22:33 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:IIO SUBSYSTEM AND DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Tomasz Duzsynski
In-Reply-To: <20260610-imperial-glittering-pudu-ddfdab@quoll>
On Wed, Jun 10, 2026 at 4:08 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Tue, Jun 09, 2026 at 11:03:25AM -0500, Maxwell Doose wrote:
> > Tomasz's entry is no longer valid, as he is not active anymore. Add
> > myself as maintainer to replace his entry.
>
> Last replies are from Feb 2026, so not that far away. I fail to see the
> context behind that change.
>
> Anyway, it's like fourth patch from you doing the same. It's even more
> confusing seeing this done file by file.
>
> Maybe you just want to add yourself as co-maintainer?
>
In the context of this one, co-maintainer may make more sense, I'm not
as familiar with this driver as I am with, say, the sps30. However I
think we still don't want patches to land in Tomasz's (seemingly
abandoned) email. I would probably wait for Jonathan to chime
regarding that however.
^ permalink raw reply
* Re: [PATCH net-next v6 08/12] of: property: fw_devlink: Add support for "pcs-handle"
From: Rob Herring @ 2026-06-10 22:43 UTC (permalink / raw)
To: Christian Marangi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Krzysztof Kozlowski, Conor Dooley, Simon Horman,
Jonathan Corbet, Shuah Khan, Lorenzo Bianconi, Heiner Kallweit,
Russell King, Saravana Kannan, Philipp Zabel, Nathan Chancellor,
Nick Desaulniers, Bill Wendling, Justin Stitt, netdev, devicetree,
linux-kernel, linux-doc, linux-arm-kernel, linux-mediatek, llvm
In-Reply-To: <20260609151212.29469-9-ansuelsmth@gmail.com>
On Tue, Jun 9, 2026 at 10:13 AM Christian Marangi <ansuelsmth@gmail.com> wrote:
>
> Add support for parsing PCS binding so that fw_devlink can
> enforce the dependency with Ethernet port.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
> drivers/of/property.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/of/property.c b/drivers/of/property.c
> index 136946f8b746..e6584a2f705d 100644
> --- a/drivers/of/property.c
> +++ b/drivers/of/property.c
> @@ -1392,6 +1392,7 @@ DEFINE_SIMPLE_PROP(access_controllers, "access-controllers", "#access-controller
> DEFINE_SIMPLE_PROP(pses, "pses", "#pse-cells")
> DEFINE_SIMPLE_PROP(power_supplies, "power-supplies", NULL)
> DEFINE_SIMPLE_PROP(mmc_pwrseq, "mmc-pwrseq", NULL)
> +DEFINE_SIMPLE_PROP(pcs_handle, "pcs-handle", "#pcs-cells")
There is no such common property "#pcs-cells".
> DEFINE_SUFFIX_PROP(regulators, "-supply", NULL)
> DEFINE_SUFFIX_PROP(gpio, "-gpio", "#gpio-cells")
>
> @@ -1548,6 +1549,7 @@ static const struct supplier_bindings of_supplier_bindings[] = {
> { .parse_prop = parse_interrupts, },
> { .parse_prop = parse_interrupt_map, },
> { .parse_prop = parse_access_controllers, },
> + { .parse_prop = parse_pcs_handle, },
> { .parse_prop = parse_regulators, },
> { .parse_prop = parse_gpio, },
> { .parse_prop = parse_gpios, },
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH 2/3] tty: serial: Add UART driver for Cortina-Access platform
From: Randy Dunlap @ 2026-06-10 22:49 UTC (permalink / raw)
To: Jason Li, jason.li, Greg Kroah-Hartman, Jiri Slaby
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Catalin Marinas,
Will Deacon, Arnd Bergmann, linux-serial, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20260610112821.3030099-4-jason.li@cortina-access.com>
On 6/10/26 4:28 AM, Jason Li wrote:
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index cf7dba473b20..99a1c9308395 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -1592,6 +1592,27 @@ config SERIAL_NUVOTON_MA35D1_CONSOLE
> but you can alter that using a kernel command line option such as
> "console=ttyNVTx".
>
> +config SERIAL_CORTINA_ACCESS
> + tristate "Cortina-Access serial port support"
> + depends on OF
> + select SERIAL_CORE
> + help
> + This driver is for the Cortina-Access SoC UART, present in the
> + CA8289 (Venus) and related CAXXXX family of SoCs. If you have a
> + machine based on the Cortina-Access SoC and wish to use the serial
> + port, say 'Y' here. Otherwise, say 'N'.
It could also be 'm' since the kconfig symbol is tristate.
> +
> +config SERIAL_CORTINA_ACCESS_CONSOLE
> + bool "Console on Cortina-Access serial port"
> + depends on SERIAL_CORTINA_ACCESS=y
> + select SERIAL_CORE_CONSOLE
> + select SERIAL_EARLYCON
> + help
> + Say 'Y' here if you wish to use the Cortina-Access UART as the system
> + console (the device which receives all kernel messages and warnings
> + and which allows logins in single user mode).
> + /dev/ttyS* is the default device node.
> +
> endmenu
--
~Randy
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: interrupt-controller: ti,irq-crossbar: Convert to DT schema
From: Rob Herring @ 2026-06-10 23:01 UTC (permalink / raw)
To: Bhargav Joshi
Cc: Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner, Sricharan R,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, devicetree, linux-kernel, linux-omap, goledhruva,
m-chawdhry, daniel.baluta, simona.toaca
In-Reply-To: <CAOWyW_4kRcZWCyOjJrWvnZ8meKT-ryJuGozuPvKJgPSUStB3Pg@mail.gmail.com>
On Wed, Jun 10, 2026 at 4:12 PM Bhargav Joshi <j.bhargav.u@gmail.com> wrote:
>
> Hi,
>
> On Thu, Jun 11, 2026 at 1:27 AM Rob Herring <robh@kernel.org> wrote:
> >
> > On Sat, Jun 06, 2026 at 02:26:10AM +0530, Bhargav Joshi wrote:
> > > Convert TI irq-crossbar binding from text format to DT schema.
> > >
> > > As part of conversion following changes are made:
> > > - Add '#interrupt-cells' as a required property which was missing in
> > > text binding
> > > - As irq-crossbar is interrupt-controller. Move binding from
> > > bindings/arm/omap to bindings/interrupt-controller
> > > - property ti,irqs-reserved is defined and used as a array but other
> > > binding ti,pruss-intc.yaml uses same property name as a unit8 bitmask
> > > which causes erros in dt_binding_check. Update ti,irqs-reserved
> > > property name to ti,crossbar-irqs-reserved to resolve duplicate naming.
> >
> > Defining a new property breaks the ABI. We will need to fix dtschema to
> > handle it. What's the error?
> property irqs-reserved is defined in two bindings with different types which
> causes dt_binding_check to raise following errors:
> - File "/lib/python3.14/site-packages/dtschema/validator.py", line
> 522, in check_duplicate_property_types
> - print(f"{self.schemas[sch_id]['$filename']}: {p}: multiple
> incompatible types: {v['type']}", file=sys.stderr)
> - KeyError: 'http://devicetree.org/schemas/interrupt-controller/ti,pruss-intc.yaml#'
> dtschema version: 2026.4
I pushed a change to dtschema main branch which should fix this.
Rob
^ permalink raw reply
* Re: [PATCH v3 1/7] clk: renesas: r8a779g0: Add DSC clock
From: Laurent Pinchart @ 2026-06-10 23:14 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Andrzej Hajda, Neil Armstrong, Robert Foss, Jonas Karlman,
Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Marek Vasut,
Kieran Bingham, Philipp Zabel, linux-renesas-soc, linux-clk,
linux-kernel, dri-devel, devicetree
In-Reply-To: <20260515-rcar-du-dsc-v3-1-164157820498@ideasonboard.com>
On Fri, May 15, 2026 at 12:09:26PM +0300, Tomi Valkeinen wrote:
> From: Marek Vasut <marek.vasut+renesas@mailbox.org>
>
> Add the DSC module clock for Renesas R-Car V4H (R8A779G0) SoC.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> drivers/clk/renesas/r8a779g0-cpg-mssr.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/renesas/r8a779g0-cpg-mssr.c b/drivers/clk/renesas/r8a779g0-cpg-mssr.c
> index 015b9773cc55..54ba76ff5ab0 100644
> --- a/drivers/clk/renesas/r8a779g0-cpg-mssr.c
> +++ b/drivers/clk/renesas/r8a779g0-cpg-mssr.c
> @@ -245,6 +245,7 @@ static const struct mssr_mod_clk r8a779g0_mod_clks[] __initconst = {
> DEF_MOD("fcpvx0", 1100, R8A779G0_CLK_S0D1_VIO),
> DEF_MOD("fcpvx1", 1101, R8A779G0_CLK_S0D1_VIO),
> DEF_MOD("tsn", 2723, R8A779G0_CLK_S0D4_HSC),
> + DEF_MOD("dsc", 2819, R8A779G0_CLK_VIOBUSD2),
> DEF_MOD("ssiu", 2926, R8A779G0_CLK_S0D6_PER),
> DEF_MOD("ssi", 2927, R8A779G0_CLK_S0D6_PER),
> };
>
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 2/5] dt-bindings: display: bridge: Document Renesas R-Car V4H DSC bindings
From: Laurent Pinchart @ 2026-06-10 23:18 UTC (permalink / raw)
To: Conor Dooley
Cc: Tomi Valkeinen, Geert Uytterhoeven, Michael Turquette,
Stephen Boyd, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Marek Vasut,
Kieran Bingham, Philipp Zabel, linux-renesas-soc, linux-clk,
linux-kernel, dri-devel, devicetree
In-Reply-To: <20260515-fraying-trickle-7511a2eeaf44@spud>
On Fri, May 15, 2026 at 06:32:27PM +0100, Conor Dooley wrote:
> On Fri, May 15, 2026 at 10:56:15AM +0300, Tomi Valkeinen wrote:
> > From: Marek Vasut <marek.vasut+renesas@mailbox.org>
> >
> > The Renesas DSC Display Stream Compression is a bridge embedded in the
> > Renesas R-Car V4H SoC. The bridge performs VESA DSC encoding of up to
> > 8k or 400 Mpixel/s .
> >
> > Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> > [tomi.valkeinen: fix the example]
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> > ---
> > .../bindings/display/bridge/renesas,dsc.yaml | 96 ++++++++++++++++++++++
> > 1 file changed, 96 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,dsc.yaml b/Documentation/devicetree/bindings/display/bridge/renesas,dsc.yaml
> > new file mode 100644
> > index 000000000000..2918d592732b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,dsc.yaml
>
> Filename matching the compatible please.
>
> pw-bot: changes-requested
>
> > @@ -0,0 +1,96 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/bridge/renesas,dsc.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Renesas R-Car DSC Display Stream Compression
> > +
> > +maintainers:
> > + - Marek Vasut <marek.vasut+renesas@mailbox.org>
> > +
> > +description: |
> > + This binding describes the VESA DSC Display Stream Compression encoder
> > + embedded in the Renesas R-Car V4H SoC. The encoder supports all DSC1.1
> > + encoding mechanisms, configurable bits-per-pixel, resolution up to 8k.
> > +
> > +properties:
> > + compatible:
> > + const: renesas,r8a779g0-dsc
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + clocks:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + power-domains:
> > + maxItems: 1
> > +
> > + resets:
> > + maxItems: 1
> > +
> > + ports:
> > + $ref: /schemas/graph.yaml#/properties/ports
> > +
> > + properties:
> > + port@0:
> > + $ref: /schemas/graph.yaml#/properties/port
> > + description: R-Car DU input port
> > +
> > + port@1:
> > + $ref: /schemas/graph.yaml#/properties/port
> > + description: R-Car DSI output port
> > +
> > + required:
> > + - port@0
> > + - port@1
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > + - interrupts
> > + - power-domains
> > + - resets
> > + - ports
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/clock/r8a779g0-cpg-mssr.h>
> > + #include <dt-bindings/interrupt-controller/arm-gic.h>
> > + #include <dt-bindings/power/r8a779g0-sysc.h>
> > +
> > + dsc@feb8d000 {
>
> Speaking of fixing the example, should this not be "decoder" or
Or rather "encoder"
> "bridge"?
> Not a big deal though.
> With the changed filename
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
>
> > + compatible = "renesas,r8a779g0-dsc";
> > + reg = <0xfeb8d000 0x400>;
> > + interrupts = <GIC_SPI 559 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&cpg CPG_MOD 2819>;
> > + power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
> > + resets = <&cpg 2819>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > + dsc_in_dsi1: endpoint {
> > + remote-endpoint = <&du_out_dsi1>;
> > + };
> > + };
> > +
> > + port@1 {
> > + reg = <1>;
> > + dsc_out_dsi1: endpoint {
> > + remote-endpoint = <&dsi1_in>;
> > + };
> > + };
> > + };
> > + };
> > +...
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v3 2/7] dt-bindings: display: bridge: Document Renesas R-Car V4H DSC bindings
From: Laurent Pinchart @ 2026-06-10 23:20 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Andrzej Hajda, Neil Armstrong, Robert Foss, Jonas Karlman,
Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Marek Vasut,
Kieran Bingham, Philipp Zabel, linux-renesas-soc, linux-clk,
linux-kernel, dri-devel, devicetree
In-Reply-To: <20260515-rcar-du-dsc-v3-2-164157820498@ideasonboard.com>
Hi Tomi and Marek,
Thank you for the patch.
On Fri, May 15, 2026 at 12:09:27PM +0300, Tomi Valkeinen wrote:
> From: Marek Vasut <marek.vasut+renesas@mailbox.org>
>
> The Renesas DSC Display Stream Compression is a bridge embedded in the
> Renesas R-Car V4H SoC. The bridge performs VESA DSC encoding of up to
> 8k or 400 Mpixel/s .
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> [tomi.valkeinen: fix the example]
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
With the comments from Conor in v2 addressed,
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> .../bindings/display/bridge/renesas,dsc.yaml | 96 ++++++++++++++++++++++
> 1 file changed, 96 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,dsc.yaml b/Documentation/devicetree/bindings/display/bridge/renesas,dsc.yaml
> new file mode 100644
> index 000000000000..2918d592732b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/renesas,dsc.yaml
> @@ -0,0 +1,96 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/renesas,dsc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas R-Car DSC Display Stream Compression
> +
> +maintainers:
> + - Marek Vasut <marek.vasut+renesas@mailbox.org>
> +
> +description: |
> + This binding describes the VESA DSC Display Stream Compression encoder
> + embedded in the Renesas R-Car V4H SoC. The encoder supports all DSC1.1
> + encoding mechanisms, configurable bits-per-pixel, resolution up to 8k.
> +
> +properties:
> + compatible:
> + const: renesas,r8a779g0-dsc
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + power-domains:
> + maxItems: 1
> +
> + resets:
> + maxItems: 1
> +
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> +
> + properties:
> + port@0:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: R-Car DU input port
> +
> + port@1:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: R-Car DSI output port
> +
> + required:
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - interrupts
> + - power-domains
> + - resets
> + - ports
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/r8a779g0-cpg-mssr.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/power/r8a779g0-sysc.h>
> +
> + dsc@feb8d000 {
> + compatible = "renesas,r8a779g0-dsc";
> + reg = <0xfeb8d000 0x400>;
> + interrupts = <GIC_SPI 559 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 2819>;
> + power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
> + resets = <&cpg 2819>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + dsc_in_dsi1: endpoint {
> + remote-endpoint = <&du_out_dsi1>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + dsc_out_dsi1: endpoint {
> + remote-endpoint = <&dsi1_in>;
> + };
> + };
> + };
> + };
> +...
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v3 5/7] arm64: dts: renesas: r8a779g0: Add DSC
From: Laurent Pinchart @ 2026-06-10 23:24 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Andrzej Hajda, Neil Armstrong, Robert Foss, Jonas Karlman,
Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Marek Vasut,
Kieran Bingham, Philipp Zabel, linux-renesas-soc, linux-clk,
linux-kernel, dri-devel, devicetree
In-Reply-To: <20260515-rcar-du-dsc-v3-5-164157820498@ideasonboard.com>
Hi Tomi and Marek,
Thank you for the patch.
On Fri, May 15, 2026 at 12:09:30PM +0300, Tomi Valkeinen wrote:
> From: Marek Vasut <marek.vasut+renesas@mailbox.org>
>
> The Renesas DSC Display Stream Compression is a bridge embedded in the
> Renesas R-Car V4H SoC. The bridge is placed between DU and DSI1 units.
>
> The current dtsi file does not represent the DSC at all, and thus the
> pipeline for DSI1 has not been functional.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> [tomi.valkeinen: separated the sparrowhawk changes]
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> arch/arm64/boot/dts/renesas/r8a779g0.dtsi | 31 ++++++++++++++++++++++++++++++-
> 1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi b/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
> index 82a7278836e5..52a6176f9fd0 100644
> --- a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
> @@ -2298,6 +2298,35 @@ du_out_dsi0: endpoint {
> port@1 {
> reg = <1>;
> du_out_dsi1: endpoint {
> + remote-endpoint = <&dsc_in_dsi1>;
> + };
> + };
> + };
> + };
> +
> + dsc: dsc@feb8d000 {
> + compatible = "renesas,r8a779g0-dsc";
> + reg = <0 0xfeb8d000 0 0x400>;
> + interrupts = <GIC_SPI 559 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 2819>;
> + power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
> + resets = <&cpg 2819>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + dsc_in_dsi1: endpoint {
> + remote-endpoint = <&du_out_dsi1>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + dsc_out_dsi1: endpoint {
> remote-endpoint = <&dsi1_in>;
> };
> };
> @@ -2534,7 +2563,7 @@ ports {
> port@0 {
> reg = <0>;
> dsi1_in: endpoint {
> - remote-endpoint = <&du_out_dsi1>;
> + remote-endpoint = <&dsc_out_dsi1>;
> };
> };
>
>
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v3 6/7] arm64: dts: renesas: sparrow-hawk: Enable DisplayPort by adding DSC
From: Laurent Pinchart @ 2026-06-10 23:24 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Andrzej Hajda, Neil Armstrong, Robert Foss, Jonas Karlman,
Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Marek Vasut,
Kieran Bingham, Philipp Zabel, linux-renesas-soc, linux-clk,
linux-kernel, dri-devel, devicetree
In-Reply-To: <20260515-rcar-du-dsc-v3-6-164157820498@ideasonboard.com>
Hi Tomi and Marek,
Thank you for the patch.
On Fri, May 15, 2026 at 12:09:31PM +0300, Tomi Valkeinen wrote:
> From: Marek Vasut <marek.vasut+renesas@mailbox.org>
>
> DisplayPort on the Sparrow Hawk board uses sn65dsi86 bridge, which in
> turn gets the video stream from the SoC's DSI1 port. DSI1 pipeline has a
> DSC block in between the DU and the DSI1. However, there was no DSC
> driver in Linux and also the DSC was not defined in the dts files, and
> thus the DisplayPort output did not work.
>
> Now that we have DSC defined in the SoC dts file (r8a779g0.dtsi), we can
> enable DSC for sparrowhawk.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> [tomi.valkeinen: separated the sparrow hawk changes from the soc changes]
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk.dts | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk.dts b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk.dts
> index 812b133cf29e..f418998c6b05 100644
> --- a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk.dts
> @@ -288,6 +288,11 @@ channel4 {
> };
> };
>
> +/* Page 27 / DSI to Display */
> +&dsc {
> + status = "okay";
> +};
> +
> /* Page 27 / DSI to Display */
> &dsi1 {
> status = "okay";
>
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v3 7/7] arm64: dts: renesas: white-hawk: Add second mini-DP output support
From: Laurent Pinchart @ 2026-06-10 23:34 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Andrzej Hajda, Neil Armstrong, Robert Foss, Jonas Karlman,
Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Marek Vasut,
Kieran Bingham, Philipp Zabel, linux-renesas-soc, linux-clk,
linux-kernel, dri-devel, devicetree
In-Reply-To: <20260515-rcar-du-dsc-v3-7-164157820498@ideasonboard.com>
Hi Tomi, Geert,
Thank you for the patch.
On Fri, May 15, 2026 at 12:09:32PM +0300, Tomi Valkeinen wrote:
> From: Geert Uytterhoeven <geert+renesas@glider.be>
>
> Add support for the mini-DisplayPort connector on the White Hawk
> BreakOut board. This port is driven by a TI SN65DSI86 DSI to eDP
> bridge, which in turn gets the pixel data from the second DSI channel on
> the R-Car V4H SoC. Note that this port is not present on the White Hawk
I would write "connector" instead of "port". The White Hawk Single
connects the DSI1 output to a GMSL serializer.
> Single development board.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> [tomi.valkeinen: added status=okay for dsc]
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> .../arm64/boot/dts/renesas/r8a779g0-white-hawk.dts | 94 ++++++++++++++++++++++
> 1 file changed, 94 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a779g0-white-hawk.dts b/arch/arm64/boot/dts/renesas/r8a779g0-white-hawk.dts
> index 784d4e8b204c..89d60b83ac4f 100644
> --- a/arch/arm64/boot/dts/renesas/r8a779g0-white-hawk.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a779g0-white-hawk.dts
> @@ -12,4 +12,98 @@
> / {
> model = "Renesas White Hawk CPU and Breakout boards based on r8a779g0";
> compatible = "renesas,white-hawk-breakout", "renesas,white-hawk-cpu", "renesas,r8a779g0";
> +
> + sn65dsi86_refclk2: clk-x16 {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <38400000>;
> + };
> +
> + mini-dp-con2 {
> + compatible = "dp-connector";
> + label = "CN15";
> + type = "mini";
> +
> + port {
> + mini_dp_con_in2: endpoint {
> + remote-endpoint = <&sn65dsi86_out2>;
> + };
> + };
> + };
> +};
> +
> +&dsc {
> + status = "okay";
> +};
> +
> +&dsi1 {
> + status = "okay";
> +
> + ports {
> + port@1 {
> + dsi1_out: endpoint {
> + remote-endpoint = <&sn65dsi86_in2>;
> + data-lanes = <1 2 3 4>;
> + };
> + };
> + };
> +};
> +
> +&i2c4 {
> + pinctrl-0 = <&i2c4_pins>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> + clock-frequency = <400000>;
> +
> + bridge@2c {
> + pinctrl-0 = <&irq1_pins>;
> + pinctrl-names = "default";
> +
> + compatible = "ti,sn65dsi86";
> + reg = <0x2c>;
> +
> + clocks = <&sn65dsi86_refclk2>;
> + clock-names = "refclk";
> +
> + interrupts-extended = <&intc_ex 1 IRQ_TYPE_LEVEL_HIGH>;
> +
> + enable-gpios = <&gpio1 27 GPIO_ACTIVE_HIGH>;
> +
> + vccio-supply = <®_1p8v>;
> + vpll-supply = <®_1p8v>;
> + vcca-supply = <®_1p2v>;
> + vcc-supply = <®_1p2v>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + sn65dsi86_in2: endpoint {
> + remote-endpoint = <&dsi1_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + sn65dsi86_out2: endpoint {
> + remote-endpoint = <&mini_dp_con_in2>;
> + };
> + };
> + };
> + };
> +};
> +
> +&pfc {
> + i2c4_pins: i2c4 {
> + groups = "i2c4";
> + function = "i2c4";
> + };
> +
> + irq1_pins: irq1 {
> + groups = "intc_ex_irq1_a";
> + function = "intc_ex";
> + };
> };
>
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v3 3/7] drm/rcar-du: dsc: Add rudimentary Renesas R-Car V4H DSC driver
From: Laurent Pinchart @ 2026-06-10 23:51 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Andrzej Hajda, Neil Armstrong, Robert Foss, Jonas Karlman,
Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Marek Vasut,
Kieran Bingham, Philipp Zabel, linux-renesas-soc, linux-clk,
linux-kernel, dri-devel, devicetree
In-Reply-To: <20260515-rcar-du-dsc-v3-3-164157820498@ideasonboard.com>
Hi Tomi, Marek,
Thank you for the patch.
On Fri, May 15, 2026 at 12:09:28PM +0300, Tomi Valkeinen wrote:
> From: Marek Vasut <marek.vasut+renesas@mailbox.org>
>
> The Renesas DSC Display Stream Compression is a bridge embedded in the
> Renesas R-Car V4H SoC. The bridge performs VESA DSC encoding of up to
> 8k or 400 Mpixel/s . Add rudimentary driver, which currently acts as a
s/s \./s./
> pass-through bridge and allows DSI1 to be operational on R-Car V4H.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> [tomi.valkeinen: use bridge->next_bridge, minor changes]
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> ---
> drivers/gpu/drm/renesas/rcar-du/Kconfig | 12 +++
> drivers/gpu/drm/renesas/rcar-du/Makefile | 1 +
> drivers/gpu/drm/renesas/rcar-du/rcar_dsc.c | 160 +++++++++++++++++++++++++++++
> 3 files changed, 173 insertions(+)
>
> diff --git a/drivers/gpu/drm/renesas/rcar-du/Kconfig b/drivers/gpu/drm/renesas/rcar-du/Kconfig
> index 840305fdeb49..c58dba949d85 100644
> --- a/drivers/gpu/drm/renesas/rcar-du/Kconfig
> +++ b/drivers/gpu/drm/renesas/rcar-du/Kconfig
> @@ -33,6 +33,18 @@ config DRM_RCAR_DW_HDMI
> help
> Enable support for R-Car Gen3 or RZ/G2 internal HDMI encoder.
>
> +config DRM_RCAR_USE_DSC
> + bool "R-Car DU DSC Encoder Support"
> + depends on DRM_BRIDGE && OF
> + depends on DRM_RCAR_DU || COMPILE_TEST
> + default DRM_RCAR_DU
> + help
> + Enable support for the R-Car Display Unit embedded DSC encoder.
> +
> +config DRM_RCAR_DSC
> + def_tristate DRM_RCAR_DU
> + depends on DRM_RCAR_USE_DSC
> +
Nitpicking, I'd move this above CMM, for preserve alphabetical ordering
of the blocks.
> config DRM_RCAR_USE_LVDS
> bool "R-Car DU LVDS Encoder Support"
> depends on DRM_BRIDGE && OF
> diff --git a/drivers/gpu/drm/renesas/rcar-du/Makefile b/drivers/gpu/drm/renesas/rcar-du/Makefile
> index 6f132325c8b7..cc27b2265d94 100644
> --- a/drivers/gpu/drm/renesas/rcar-du/Makefile
> +++ b/drivers/gpu/drm/renesas/rcar-du/Makefile
> @@ -12,5 +12,6 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
> obj-$(CONFIG_DRM_RCAR_CMM) += rcar_cmm.o
> obj-$(CONFIG_DRM_RCAR_DU) += rcar-du-drm.o
> obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
> +obj-$(CONFIG_DRM_RCAR_DSC) += rcar_dsc.o
Here too.
> obj-$(CONFIG_DRM_RCAR_LVDS) += rcar_lvds.o
> obj-$(CONFIG_DRM_RCAR_MIPI_DSI) += rcar_mipi_dsi.o
> diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_dsc.c b/drivers/gpu/drm/renesas/rcar-du/rcar_dsc.c
> new file mode 100644
> index 000000000000..5d3d083e3ce6
> --- /dev/null
> +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_dsc.c
> @@ -0,0 +1,160 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * R-Car DSC Encoder
> + *
> + * Copyright (C) 2025 Marek Vasut <marek.vasut+renesas@mailbox.org>
> + * Copyright (C) 2025 Renesas Electronics Corporation
> + */
> +
#include <linux/container_of.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_graph.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> +
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_bridge.h>
> +#include <drm/drm_of.h>
I think you can drop drm_of.h.
> +
> +struct rcar_dsc {
> + struct drm_bridge bridge;
> +
> + struct device *dev;
> + void __iomem *mmio;
> +};
> +
> +static inline struct rcar_dsc *bridge_to_rcar_dsc(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct rcar_dsc, bridge);
> +}
> +
> +/* -----------------------------------------------------------------------------
> + * Bridge
> + */
> +
> +static int rcar_dsc_attach(struct drm_bridge *bridge,
> + struct drm_encoder *encoder,
> + enum drm_bridge_attach_flags flags)
> +{
> + struct rcar_dsc *dsc = bridge_to_rcar_dsc(bridge);
> +
> + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR))
> + return -EINVAL;
> +
> + return drm_bridge_attach(encoder, dsc->bridge.next_bridge, bridge,
> + DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> +}
> +
> +static void rcar_dsc_atomic_enable(struct drm_bridge *bridge,
> + struct drm_atomic_state *state)
Small conflict when rebasing on top of drm-misc.
> +{
> + struct rcar_dsc *dsc = bridge_to_rcar_dsc(bridge);
> +
> + WARN_ON(pm_runtime_resume_and_get(dsc->dev));
> +}
> +
> +static void rcar_dsc_atomic_disable(struct drm_bridge *bridge,
> + struct drm_atomic_state *state)
> +{
> + struct rcar_dsc *dsc = bridge_to_rcar_dsc(bridge);
> +
> + pm_runtime_put(dsc->dev);
> +}
> +
> +static enum drm_mode_status
> +rcar_dsc_bridge_mode_valid(struct drm_bridge *bridge,
> + const struct drm_display_info *info,
> + const struct drm_display_mode *mode)
> +{
> + if (mode->hdisplay < 320 || mode->hdisplay > 8190)
> + return MODE_BAD_HVALUE;
> +
> + if (mode->vdisplay < 160 || mode->vdisplay > 8190)
> + return MODE_BAD_VVALUE;
> +
> + if (mode->clock > 400000) /* Really 400 Mpixel/s */
> + return MODE_CLOCK_HIGH;
> +
> + return MODE_OK;
> +}
> +
> +static const struct drm_bridge_funcs rcar_dsc_bridge_ops = {
> + .attach = rcar_dsc_attach,
> + .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> + .atomic_reset = drm_atomic_helper_bridge_reset,
> + .atomic_enable = rcar_dsc_atomic_enable,
> + .atomic_disable = rcar_dsc_atomic_disable,
> + .mode_valid = rcar_dsc_bridge_mode_valid,
> +};
> +
> +/* -----------------------------------------------------------------------------
> + * Probe & Remove
> + */
> +
> +static int rcar_dsc_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *remote;
> + struct rcar_dsc *dsc;
> + int ret;
> +
> + dsc = devm_drm_bridge_alloc(dev, struct rcar_dsc, bridge,
> + &rcar_dsc_bridge_ops);
> + if (IS_ERR(dsc))
> + return PTR_ERR(dsc);
> +
> + platform_set_drvdata(pdev, dsc);
> +
> + dsc->dev = &pdev->dev;
> +
> + dsc->mmio = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(dsc->mmio))
> + return PTR_ERR(dsc->mmio);
The driver doesn't access registers, so this can be dropped (along with
the mmio field in the rcar_dsc structure).
> +
> + remote = of_graph_get_remote_node(dev->of_node, 1, 0);
> + if (!remote)
> + return -EINVAL;
> +
> + dsc->bridge.next_bridge = of_drm_find_and_get_bridge(remote);
> + of_node_put(remote);
You can replace this with
dsc->bridge.next_bridge = of_drm_get_bridge_by_endpoint(dev->of_node,
1, 0);
and drop inclusion of of_graph.h.
> + if (!dsc->bridge.next_bridge)
> + return -EPROBE_DEFER;
> +
> + dsc->bridge.of_node = dev->of_node;
> +
> + ret = devm_drm_bridge_add(dev, &dsc->bridge);
> + if (ret)
> + return ret;
> +
> + pm_runtime_enable(&pdev->dev);
> +
> + return 0;
> +}
> +
> +static void rcar_dsc_remove(struct platform_device *pdev)
> +{
> + pm_runtime_disable(&pdev->dev);
> +}
> +
> +static const struct of_device_id rcar_dsc_of_table[] = {
> + { .compatible = "renesas,r8a779g0-dsc" },
> + {}
> +};
> +
> +MODULE_DEVICE_TABLE(of, rcar_dsc_of_table);
> +
> +static struct platform_driver rcar_dsc_platform_driver = {
> + .probe = rcar_dsc_probe,
> + .remove = rcar_dsc_remove,
> + .driver = {
> + .name = "rcar-dsc",
> + .of_match_table = rcar_dsc_of_table,
> + },
> +};
> +
> +module_platform_driver(rcar_dsc_platform_driver);
> +
> +MODULE_DESCRIPTION("Renesas R-Car DSC Encoder Driver");
> +MODULE_LICENSE("GPL");
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v3 4/7] drm/rcar-du: dsi: Support DSC in the pipeline
From: Laurent Pinchart @ 2026-06-11 0:03 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Andrzej Hajda, Neil Armstrong, Robert Foss, Jonas Karlman,
Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Marek Vasut,
Kieran Bingham, Philipp Zabel, linux-renesas-soc, linux-clk,
linux-kernel, dri-devel, devicetree
In-Reply-To: <20260515-rcar-du-dsc-v3-4-164157820498@ideasonboard.com>
Hi Tomi,
Thank you for the patch.
On Fri, May 15, 2026 at 12:09:29PM +0300, Tomi Valkeinen wrote:
> Enabling DSI clocks on rcar-du needs some tricks as the DU dot clock is
> provided by the DSI. Thus, we call rcar_mipi_dsi_pclk_enable() from the
> crtc, when enabling the crtc.
>
> With DSC (added in upcoming patch) in the pipeline, between the DU and
> the DSI, the above call path is broken as the crtc tries to call
> rcar_mipi_dsi_pclk_enable() on the DSC.
>
> Adjust the rcar_mipi_dsi_pclk_enable() so that it detects the DSC, and
> in that case gets the next bridge from the DSC, which is the DSI.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> ---
> drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c | 36 +++++++++++++++++++++++--
> 1 file changed, 34 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c
> index 4ef2e3c129ed..085e229bcb0b 100644
> --- a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c
> +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c
> @@ -88,6 +88,8 @@ struct dsi_setup_info {
> const struct dsi_clk_config *clkset;
> };
>
> +static const struct drm_bridge_funcs rcar_mipi_dsi_bridge_ops;
> +
> static inline struct rcar_mipi_dsi *
> bridge_to_rcar_mipi_dsi(struct drm_bridge *bridge)
> {
> @@ -844,15 +846,39 @@ static void rcar_mipi_dsi_atomic_disable(struct drm_bridge *bridge,
> rcar_mipi_dsi_stop_video(dsi);
> }
>
> +/*
> + * We need to skip the DSC bridge when we have DSC in between the DU and
> + * the DSI. We detect the DSI bridge via bridge->funcs, and assume the
> + * next_bridge is the DSI bridge. If this is not the case, the DT data
> + * is wrong (so it shouldn't really happen).
> + */
> +static struct drm_bridge *
> +rcar_mipi_dsi_resolve_bridge(struct drm_bridge *bridge)
> +{
> + if (bridge->funcs != &rcar_mipi_dsi_bridge_ops)
> + bridge = bridge->next_bridge;
> +
> + if (!bridge || bridge->funcs != &rcar_mipi_dsi_bridge_ops)
> + return NULL;
> +
> + return bridge;
> +}
Hmmmm... It's quite a bit of a hack. It would be nicer to do this in
rcar_du_crtc.c instead, where we cache the dsi bridge pointer. The
question is how to then identify the right bridge, as we won't have
access to rcar_mipi_dsi_bridge_ops. Should this driver set the bridge
type field to DRM_MODE_CONNECTOR_DSI ?
> +
> void rcar_mipi_dsi_pclk_enable(struct drm_bridge *bridge,
> struct drm_atomic_state *state)
> {
> - struct rcar_mipi_dsi *dsi = bridge_to_rcar_mipi_dsi(bridge);
> const struct drm_display_mode *mode;
> struct drm_connector *connector;
> + struct rcar_mipi_dsi *dsi;
> struct drm_crtc *crtc;
> int ret;
>
> + bridge = rcar_mipi_dsi_resolve_bridge(bridge);
> + if (WARN_ON(!bridge))
> + return;
> +
> + dsi = bridge_to_rcar_mipi_dsi(bridge);
> +
> connector = drm_atomic_get_new_connector_for_encoder(state,
> bridge->encoder);
> crtc = drm_atomic_get_new_connector_state(state, connector)->crtc;
> @@ -885,7 +911,13 @@ EXPORT_SYMBOL_GPL(rcar_mipi_dsi_pclk_enable);
>
> void rcar_mipi_dsi_pclk_disable(struct drm_bridge *bridge)
> {
> - struct rcar_mipi_dsi *dsi = bridge_to_rcar_mipi_dsi(bridge);
> + struct rcar_mipi_dsi *dsi;
> +
> + bridge = rcar_mipi_dsi_resolve_bridge(bridge);
> + if (WARN_ON(!bridge))
> + return;
> +
> + dsi = bridge_to_rcar_mipi_dsi(bridge);
>
> rcar_mipi_dsi_shutdown(dsi);
> rcar_mipi_dsi_clk_disable(dsi);
>
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v9 3/4] arm64: dts: aspeed: Add initial AST27xx SoC device tree
From: Andrew Jeffery @ 2026-06-11 0:14 UTC (permalink / raw)
To: Ryan Chen, sashiko-reviews@lists.linux.dev
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org
In-Reply-To: <TY2PPF5CB9A1BE674CFFD62F27DFDFE0B2AF21D2@TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com>
Hi Ryan,
On Tue, 2026-06-09 at 05:36 +0000, Ryan Chen wrote:
> > Subject: Re: [PATCH v9 3/4] arm64: dts: aspeed: Add initial AST27xx SoC device
> > tree
> >
> > Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to
> > consider:
> > - [High] INTC1 maps its summary interrupts to INTC0's TSP routing range,
> > preventing SOC1 interrupts from reaching the Cortex-A35 GIC.
> > - [Low] The device tree defines ad-hoc top-level nodes ('secondary', 'tertiary',
> > 'bootmcu') that violate standard naming schemas, and embeds direct Linux
> > kernel source URLs to justify '#size-cells' behavior.
> > - [Low] Duplicate label definitions in the pinctrl device tree include for multiple
> > pinctrl groups in SOC1 will cause a hard DTC build failure.
> > --
> >
> > commit 92031db9a3c255cefbfcc33df4ca0cb9780dd226
> > Author: Ryan Chen <ryan_chen@aspeedtech.com>
> >
> > arm64: dts: aspeed: Add initial AST27xx SoC device tree
> >
> > Add initial device tree support for the ASPEED AST27xx family, the
> > 8th-generation Baseboard Management Controller (BMC) SoCs.
> >
> > > diff --git a/arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi
> > > b/arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi
> > > new file mode 100644
> > > index 0000000000000..ef283d95649a3
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi
> > [ ... ]
> > > @@ -82,10 +82,10 @@ l2: l2-cache0 {
> > > };
> > >
> > > secondary {
> > > #address-cells = <2>;
> > > /*
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/
> > of/address.c?h=v6.16#n491 */
> > > #size-cells = <0>;
> > > /*
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tre
> > > e/drivers/of/address.c?h=v6.16#n430 */
> > >
> >
> > [Severity: Low]
> > Are these OS-specific comments and ad-hoc root nodes ('secondary', 'tertiary',
> > 'bootmcu') appropriate here?
> >
> > Device trees typically provide an OS-agnostic hardware description using
> > generic nodes (like 'bus', 'soc', or 'remoteproc'). Embedding Linux kernel
> > source URLs suggests the hardware is being modeled around a specific Linux
> > parser implementation rather than providing an independent hardware
> > description.
>
> The concern is valid and acknowledged. The sub-processor interrupt
> controllers (ssp_nvic for SSP/Cortex-M4, tsp_nvic for TSP/Cortex-M4,
> bootmcu_hlic for BootMCU/RISC-V) cannot be placed under the soc1 bus
> because their registers reside in each sub-processor's private address
> space and are not accessible from the Cortex-A35 cores.
>
> The 2-cell address scheme (#address-cells = <2>, #size-cells = <0>)
> encodes a <cpu-index reg-base> tuple as suggested by Matt Johnston [1].
That was me, not Matt.
Further, that two cell scheme was part of a tentative sketch for
discussion from quite some time ago and wasn't intended to be
copy/pasted without further thought. We should remove the index now.
> The Linux kernel source URLs in the comments are admittedly
> Linux-specific and will be removed in v11; the cover letter explains
> the rationale instead.
>
> All sub-processor nodes carry status = "disabled". They are present
> solely to provide phandle references for the aspeed,interrupt-ranges
> properties in intc0 and intc1, which the interrupt controller drivers
> use to build the interrupt domain hierarchy at boot time.
>
> [1] https://lore.kernel.org/all/1a2ca78746e00c2ec4bfc2953a897c48376ed36f.camel@codeconstruct.com.au/
>
> >
> > > ssp_nvic: interrupt-controller@1,e000e100 {
> > [ ... ]
> > > diff --git a/arch/arm64/boot/dts/aspeed/aspeed-g7-soc1-pinctrl.dtsi
> > > b/arch/arm64/boot/dts/aspeed/aspeed-g7-soc1-pinctrl.dtsi
> > > new file mode 100644
> > > index 0000000000000..72d93323593d5
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/aspeed/aspeed-g7-soc1-pinctrl.dtsi
> > [ ... ]
> > > @@ -475,10 +475,10 @@ pinctrl_hvi3c15_default: hvi3c15-default-state {
> > > function = "I3C15";
> > > groups = "HVI3C15";
> > > };
> > >
> > > pinctrl_tach0_default: tach0-default-state {
> > > function = "TACH0";
> > > groups = "TACH0";
> > > };
> > >
> >
> > [Severity: Low]
> > Is this label duplicated? There is another pinctrl_tach0_default definition
> > earlier in this file.
> >
> > Defining the same pinctrl label multiple times (such as pinctrl_tach0_default
> > through pinctrl_tach15_default, and pinctrl_ncts5_default) in the same device
> > tree will cause a fatal syntax error in the Device Tree Compiler.
>
> Will fixed in v11. The labels pinctrl_tach0_default through
> pinctrl_tach15_default were duplicated in aspeed-g7-soc1-pinctrl.dtsi
> due to a copy-paste error. The second block has been removed.
Please send me fixes for these, and avoid sending patches under review
to soc@ in the future:
> Note that the soc@kernel.org is usually not the place to discuss the
> patches, thus work sent to this address should be already considered
> as acceptable by the community.
https://docs.kernel.org/process/maintainer-soc.html#submitting-patches-to-the-main-soc-maintainers
Andrew
^ permalink raw reply
* Re: [PATCH] dt-bindings: iio: accel: Convert lis302 binding to YAML schema
From: kernel test robot @ 2026-06-11 0:33 UTC (permalink / raw)
To: Md Shofiqul Islam, linux-iio, devicetree
Cc: oe-kbuild-all, jic23, dlechner, nuno.sa, andy, robh, krzk+dt,
conor+dt, krzk, linux-kernel, Md Shofiqul Islam
In-Reply-To: <20260610110051.1228-1-shofiqtest@gmail.com>
Hi Md,
kernel test robot noticed the following build warnings:
[auto build test WARNING on jic23-iio/togreg]
[also build test WARNING on linus/master v7.1-rc7 next-20260610]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Md-Shofiqul-Islam/dt-bindings-iio-accel-Convert-lis302-binding-to-YAML-schema/20260610-191419
base: https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
patch link: https://lore.kernel.org/r/20260610110051.1228-1-shofiqtest%40gmail.com
patch subject: [PATCH] dt-bindings: iio: accel: Convert lis302 binding to YAML schema
config: microblaze-randconfig-2052-20260610 (https://download.01.org/0day-ci/archive/20260611/202606110223.IxhtwJBI-lkp@intel.com/config)
compiler: microblaze-linux-gcc (GCC) 15.2.0
dtschema: 2026.5.dev10+g5d839523d
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260611/202606110223.IxhtwJBI-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606110223.IxhtwJBI-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> Warning: Duplicate compatible "st,lis302dl-spi" found in schemas matching "$id":
http://devicetree.org/schemas/iio/accel/st,lis302dl.yaml
http://devicetree.org/schemas/iio/st,st-sensors.yaml#
>> Warning: Duplicate compatible "st,lis3lv02d" found in schemas matching "$id":
http://devicetree.org/schemas/iio/accel/st,lis302dl.yaml
http://devicetree.org/schemas/iio/st,st-sensors.yaml#
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH 1/3] arm64: dts: renesas: r8a77965-salvator-x: Enable GPU support
From: Marek Vasut @ 2026-06-11 0:57 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, David Airlie, Frank Binns,
Geert Uytterhoeven, Krzysztof Kozlowski, Maarten Lankhorst,
Magnus Damm, Matt Coster, Maxime Ripard, Niklas Söderlund,
Rob Herring, Simona Vetter, Thomas Zimmermann, devicetree,
dri-devel, linux-renesas-soc
Enable GPU on Salvator-X with R-Car M3-N.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Frank Binns <frank.binns@imgtec.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Matt Coster <matt.coster@imgtec.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: "Niklas Söderlund" <niklas.soderlund@ragnatech.se>
Cc: Rob Herring <robh@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
index f84c64ed4df7b..af8cfdccd2103 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
@@ -30,3 +30,7 @@ &du {
clock-names = "du.0", "du.1", "du.3",
"dclkin.0", "dclkin.1", "dclkin.3";
};
+
+&gpu {
+ status = "okay";
+};
--
2.53.0
^ permalink raw reply related
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