* Re: [PATCH v4 2/7] dt-bindings: display: bridge: Document Renesas R-Car V4H DSC bindings
From: sashiko-bot @ 2026-06-15 6:34 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: devicetree, dri-devel, robh, wsa+renesas, conor+dt
In-Reply-To: <20260615-rcar-du-dsc-v4-2-93096a1b56a3@ideasonboard.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The DT binding example fails schema validation because its `compatible` string array is incomplete and does not match the schema's requirements.
--
commit 0c24ed90ba663d71759d36b46777595ba20ee9c3
Author: Marek Vasut <marek.vasut+renesas@mailbox.org>
dt-bindings: display: bridge: Document Renesas R-Car V4H DSC bindings
This commit adds device tree bindings for the VESA DSC Display Stream
Compression encoder embedded in the Renesas R-Car V4H SoC. It defines the
schema constraints, required properties, and provides an example node.
> 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 0000000000000..4d2c2c6cb1f08
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/renesas,dsc.yaml
[ ... ]
> +properties:
> + compatible:
> + items:
> + - enum:
> + - renesas,r8a779g0-dsc
> + - const: renesas,rcar-dsc
> +
[ ... ]
> +examples:
> + - |
> + #include <dt-bindings/clock/r8a779g0-cpg-mssr.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/power/r8a779g0-sysc.h>
> +
> + bridge@feb8d000 {
> + compatible = "renesas,r8a779g0-dsc";
[Severity: Low]
Does this example fail dt_binding_check validation? The schema requires the
compatible property to be an array containing exactly two items: the
SoC-specific string and the fallback constant (renesas,rcar-dsc). However,
the example only provides the SoC-specific string.
Should the example be updated to match the schema requirements?
> + reg = <0xfeb8d000 0x400>;
> + interrupts = <GIC_SPI 559 IRQ_TYPE_LEVEL_HIGH>;
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-rcar-du-dsc-v4-0-93096a1b56a3@ideasonboard.com?part=2
^ permalink raw reply
* Re: [PATCH v2 4/4] iio: dac: ad3530r: Add support for AD3532R/AD3532
From: sashiko-bot @ 2026-06-15 6:33 UTC (permalink / raw)
To: Kim Seer Paller; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260615-iio-ad3532r-support-v2-4-84a0af8b83fa@analog.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The `AD3532R_MAX_REG_ADDR` macro is off by one byte, which breaks read and write operations for the highest channel (channel 15).
--
commit 26c7d468b3bc4ece87a824dffd3ce6a739dc9fcd
Author: Kim Seer Paller <kimseer.paller@analog.com>
iio: dac: ad3530r: Add support for AD3532R/AD3532
The AD3532R/AD3532 is a 16-channel, 16-bit voltage output DAC with a
dual-bank register architecture. This patch adds AD3532R-specific register
definitions, channel specs, per-bank register arrays, and per-chip
regmap configurations.
> diff --git a/drivers/iio/dac/ad3530r.c b/drivers/iio/dac/ad3530r.c
> --- a/drivers/iio/dac/ad3530r.c
> +++ b/drivers/iio/dac/ad3530r.c
> @@ -39,6 +40,22 @@
[ ... ]
> +#define AD3532R_SW_LDAC_TRIG_0 0x10E5
> +#define AD3532R_SW_LDAC_TRIG_1 0x30E5
> +#define AD3532R_INPUT_CH_0 0x10EB
> +#define AD3532R_INPUT_CH_1 0x30EB
> +#define AD3532R_MAX_REG_ADDR 0x30F9
[Severity: High]
Will this maximum register address break accesses for channel 15?
Since ad3532r_input_ch_reg(15) correctly returns the base register address
0x30F9, and val_bits is 8 for this 16-bit DAC, accessing the channel requires
reading or writing 2 bytes (addresses 0x30F9 and 0x30FA).
If max_register is restrictively defined as 0x30F9, the regmap subsystem's
bounds check will reject the access to 0x30FA and return -EINVAL during
regmap_bulk_read() or regmap_bulk_write() operations.
It looks like this might be a copy of a pre-existing bug in the driver, as
AD3530R_MAX_REG_ADDR is set to 0xF9, which would similarly break channel 7
on the AD3530R.
> +
> #define AD3530R_SLD_TRIG_A BIT(7)
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-iio-ad3532r-support-v2-0-84a0af8b83fa@analog.com?part=4
^ permalink raw reply
* Re: [PATCH] of: property: Fix of_fwnode_get_reference_args() with negative index
From: Krzysztof Kozlowski @ 2026-06-15 6:33 UTC (permalink / raw)
To: Alban Bedel
Cc: devicetree, Rob Herring, Saravana Kannan, driver-core,
linux-kernel, Tommaso Merciai
In-Reply-To: <20260611102806.2643869-1-alban.bedel@lht.dlh.de>
On Thu, Jun 11, 2026 at 12:28:06PM +0200, Alban Bedel wrote:
> fwnode_property_get_reference_args() should return -ENOENT when an out
> of bound index is passed. An issue arised with the OF backend because
> the OF API use signed indexes while the fwnode API use unsigned ones.
> When an index value greater the INT_MAX was passed to the OF backend
> it got casted to a negative value and it returned -EINVAL instead of
INT_MAX is not out of bound for this function. It is invalid value,
because OF code expects signed.
> -ENOENT. This patch add a check to of_fwnode_get_reference_args() to
> catch negative index before they are passed to the OF API and return
> -ENOENT right away.
I do not understand why are you fixing this issue that way. For this
API, the INT_MAX is correct value, but you claim that it is wrong and
should be ENOENT (even if there is entry).
Fine, if this is not a correct value, then EINVAL.
But more important I think this should be just fixed in different way -
why index in OF calls is signed in the first place? All indices are
supposed to be unsigned in general, because that is both logical and
readable when accessing arrays.
>
> This issue appeared when the following pattern was used in the LED
> subsystem:
>
> index = fwnode_property_match_string(fwnode, "led-names", name)
> led_node = fwnode_find_reference(fwnode, "leds", index);
>
> Unlike the same pattern with the OF API, this pattern implicitly cast
> the signed return value of fwnode_property_match_string() to an
> unsigned index leading to the above issue with the OF backend. It can
> be argued that the return value of fwnode_property_match_string()
> should be checked separately, but I think there is value in supporting
> such simple and straight to the point patterns.
>
> Link: https://lore.kernel.org/linux-leds/aimVRwJPhlGxsIUj@tom-desktop/T/#mc43cbf7e0599991b56dd0d9680714d28d145fbc8
> Cc: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> Signed-off-by: Alban Bedel <alban.bedel@lht.dlh.de>
> ---
> drivers/of/property.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/of/property.c b/drivers/of/property.c
> index 136946f8b746f..eace2d1847b99 100644
> --- a/drivers/of/property.c
> +++ b/drivers/of/property.c
> @@ -1157,6 +1157,13 @@ of_fwnode_get_reference_args(const struct fwnode_handle *fwnode,
> unsigned int i;
> int ret;
>
> + /* This function should return -ENOENT for out of bound indexes,
/*
Please use Linux coding style comments.
> + * but the OF API uses signed indexes and consider negative indexes
> + * as invalid. Catch them here to correctly implement the fwnode API.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/4] dt-bindings: iio: dac: add support for AD3532R/AD3532
From: sashiko-bot @ 2026-06-15 6:33 UTC (permalink / raw)
To: Kim Seer Paller; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260615-iio-ad3532r-support-v2-3-84a0af8b83fa@analog.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The `ad3530r_chip` struct initialization redundantly initializes `.input_ch_reg` twice.
--
commit 2528c529a11e7b49d5cde3c0238451d59c5f698b
Author: Kim Seer Paller <kimseer.paller@analog.com>
iio: dac: ad3530r: Refactor setup to table-driven register bank approach
Replace direct register calls in ad3530r_setup() with per-chip register
address arrays and bank helpers. Convert sw_ldac_trig_reg from a static
register address to a function pointer for per-bank LDAC trigger
register selection. Switch spi_device_id to named initializers.
> diff --git a/drivers/iio/dac/ad3530r.c b/drivers/iio/dac/ad3530r.c
> index d9db3226ecd64..e4346bc729ba5 100644
> --- a/drivers/iio/dac/ad3530r.c
> +++ b/drivers/iio/dac/ad3530r.c
[ ... ]
> @@ -344,7 +387,14 @@ static const struct ad3530r_chip_info ad3530r_chip = {
> .name = "ad3530r",
> .channels = ad3530r_channels,
> .num_channels = ARRAY_SIZE(ad3530r_channels),
> - .sw_ldac_trig_reg = AD3530R_SW_LDAC_TRIG_A,
> + .sw_ldac_trig_reg = ad3530r_trigger_sw_ldac_reg,
> + .input_ch_reg = ad3530r_input_ch_reg,
^^^^^^^^^^^^^
[Severity: Low]
Is .input_ch_reg redundantly initialized here? It looks like .input_ch_reg
is also assigned just a few lines down in this struct.
> + .interface_config_a = ad3530r_if_config,
> + .output_control = ad3530r_out_ctrl,
> + .reference_control = ad3530r_ref_ctrl,
> + .op_mode = ad3530r_op_mode,
> + .num_banks = ARRAY_SIZE(ad3530r_if_config),
> + .num_op_mode_regs = ARRAY_SIZE(ad3530r_op_mode),
> .input_ch_reg = ad3530r_input_ch_reg,
> .internal_ref_support = true,
> };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-iio-ad3532r-support-v2-0-84a0af8b83fa@analog.com?part=3
^ permalink raw reply
* Re: [PATCH v2 2/4] iio: ABI: add DAC 10kohm_to_gnd powerdown mode
From: sashiko-bot @ 2026-06-15 6:32 UTC (permalink / raw)
To: Kim Seer Paller; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260615-iio-ad3532r-support-v2-2-84a0af8b83fa@analog.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Duplicate field initialization in the `ad3530r_chip` structure.
--
commit 2528c529a11e7b49d5cde3c0238451d59c5f698b
Author: Kim Seer Paller <kimseer.paller@analog.com>
iio: dac: ad3530r: Refactor setup to table-driven register bank approach
Replace direct register calls in ad3530r_setup() with per-chip register
address arrays and bank helpers. Convert sw_ldac_trig_reg from a static
register address to a function pointer for per-bank LDAC trigger register
selection.
> diff --git a/drivers/iio/dac/ad3530r.c b/drivers/iio/dac/ad3530r.c
> index d9db3226ecd64..e4346bc729ba5 100644
> --- a/drivers/iio/dac/ad3530r.c
> +++ b/drivers/iio/dac/ad3530r.c
[ ... ]
> @@ -344,7 +387,14 @@ static const struct ad3530r_chip_info ad3530r_chip = {
> .name = "ad3530r",
> .channels = ad3530r_channels,
> .num_channels = ARRAY_SIZE(ad3530r_channels),
> - .sw_ldac_trig_reg = AD3530R_SW_LDAC_TRIG_A,
> + .sw_ldac_trig_reg = ad3530r_trigger_sw_ldac_reg,
> + .input_ch_reg = ad3530r_input_ch_reg,
> + .interface_config_a = ad3530r_if_config,
> + .output_control = ad3530r_out_ctrl,
> + .reference_control = ad3530r_ref_ctrl,
> + .op_mode = ad3530r_op_mode,
> + .num_banks = ARRAY_SIZE(ad3530r_if_config),
> + .num_op_mode_regs = ARRAY_SIZE(ad3530r_op_mode),
> .input_ch_reg = ad3530r_input_ch_reg,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[Severity: Low]
Is this duplicate initialization intended? It looks like .input_ch_reg is
initialized twice in the ad3530r_chip structure, once in the newly added
lines and again here.
> .internal_ref_support = true,
> };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-iio-ad3532r-support-v2-0-84a0af8b83fa@analog.com?part=2
^ permalink raw reply
* Re: [PATCH v2 1/4] iio: dac: ad3530r: Refactor setup to table-driven register bank approach
From: sashiko-bot @ 2026-06-15 6:30 UTC (permalink / raw)
To: Kim Seer Paller; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260615-iio-ad3532r-support-v2-1-84a0af8b83fa@analog.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Duplicate field initialization for `input_ch_reg` in the `ad3530r_chip` structure.
--
commit 2528c529a11e7b49d5cde3c0238451d59c5f698b
Author: Kim Seer Paller <kimseer.paller@analog.com>
iio: dac: ad3530r: Refactor setup to table-driven register bank approach
This commit replaces direct register accesses in ad3530r_setup() with a
table-driven register bank approach using per-chip address arrays. It also
converts the software LDAC trigger register from a static address to a
function pointer.
> diff --git a/drivers/iio/dac/ad3530r.c b/drivers/iio/dac/ad3530r.c
> index d9db3226ecd64..e4346bc729ba5 100644
> --- a/drivers/iio/dac/ad3530r.c
> +++ b/drivers/iio/dac/ad3530r.c
[ ... ]
> @@ -344,7 +387,14 @@ static const struct ad3530r_chip_info ad3530r_chip = {
> .name = "ad3530r",
> .channels = ad3530r_channels,
> .num_channels = ARRAY_SIZE(ad3530r_channels),
> - .sw_ldac_trig_reg = AD3530R_SW_LDAC_TRIG_A,
> + .sw_ldac_trig_reg = ad3530r_trigger_sw_ldac_reg,
> + .input_ch_reg = ad3530r_input_ch_reg,
> + .interface_config_a = ad3530r_if_config,
> + .output_control = ad3530r_out_ctrl,
> + .reference_control = ad3530r_ref_ctrl,
> + .op_mode = ad3530r_op_mode,
> + .num_banks = ARRAY_SIZE(ad3530r_if_config),
> + .num_op_mode_regs = ARRAY_SIZE(ad3530r_op_mode),
> .input_ch_reg = ad3530r_input_ch_reg,
[Severity: Low]
This isn't a bug, but there is now a duplicate initialization of
.input_ch_reg in ad3530r_chip. Should the newly added instance be removed
to prevent compiler warnings like -Winitializer-overrides?
> .internal_ref_support = true,
> };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-iio-ad3532r-support-v2-0-84a0af8b83fa@analog.com?part=1
^ permalink raw reply
* [PATCH v4 7/7] arm64: dts: renesas: white-hawk: Add second mini-DP output support
From: Tomi Valkeinen @ 2026-06-15 6:28 UTC (permalink / raw)
To: Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Marek Vasut,
Laurent Pinchart, Kieran Bingham, Philipp Zabel
Cc: linux-renesas-soc, linux-clk, linux-kernel, dri-devel, devicetree,
Tomi Valkeinen
In-Reply-To: <20260615-rcar-du-dsc-v4-0-93096a1b56a3@ideasonboard.com>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Add support for the mini-DisplayPort connector on the White Hawk
BreakOut board. This connector 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
Single development board.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
[tomi.valkeinen: added status=okay for dsc]
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen+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";
+ };
};
--
2.43.0
^ permalink raw reply related
* [PATCH v4 6/7] arm64: dts: renesas: sparrow-hawk: Enable DisplayPort by adding DSC
From: Tomi Valkeinen @ 2026-06-15 6:28 UTC (permalink / raw)
To: Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Marek Vasut,
Laurent Pinchart, Kieran Bingham, Philipp Zabel
Cc: linux-renesas-soc, linux-clk, linux-kernel, dri-devel, devicetree,
Tomi Valkeinen
In-Reply-To: <20260615-rcar-du-dsc-v4-0-93096a1b56a3@ideasonboard.com>
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]
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen+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 af680290ce81..0a5ebe0460ca 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";
--
2.43.0
^ permalink raw reply related
* [PATCH v4 5/7] arm64: dts: renesas: r8a779g0: Add DSC
From: Tomi Valkeinen @ 2026-06-15 6:28 UTC (permalink / raw)
To: Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Marek Vasut,
Laurent Pinchart, Kieran Bingham, Philipp Zabel
Cc: linux-renesas-soc, linux-clk, linux-kernel, dri-devel, devicetree,
Tomi Valkeinen
In-Reply-To: <20260615-rcar-du-dsc-v4-0-93096a1b56a3@ideasonboard.com>
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..123baaea8db4 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: bridge@feb8d000 {
+ compatible = "renesas,r8a779g0-dsc", "renesas,rcar-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>;
};
};
--
2.43.0
^ permalink raw reply related
* [PATCH v4 4/7] drm/rcar-du: dsi: Support DSC in the pipeline
From: Tomi Valkeinen @ 2026-06-15 6:28 UTC (permalink / raw)
To: Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Marek Vasut,
Laurent Pinchart, Kieran Bingham, Philipp Zabel
Cc: linux-renesas-soc, linux-clk, linux-kernel, dri-devel, devicetree,
Tomi Valkeinen
In-Reply-To: <20260615-rcar-du-dsc-v4-0-93096a1b56a3@ideasonboard.com>
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.
To solve this problem, add checks to rcar_du_crtc_atomic_enable() and
rcar_du_crtc_atomic_disable() to detect the DSC via the bridge type, and
skip the DCS bridge when needed.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
---
drivers/gpu/drm/renesas/rcar-du/rcar_du_crtc.c | 18 ++++++++++++++++++
drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c | 1 +
2 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_crtc.c b/drivers/gpu/drm/renesas/rcar-du/rcar_du_crtc.c
index 6c07c406f725..f14fd89f9104 100644
--- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_crtc.c
@@ -754,6 +754,15 @@ static void rcar_du_crtc_atomic_enable(struct drm_crtc *crtc,
(BIT(RCAR_DU_OUTPUT_DSI0) | BIT(RCAR_DU_OUTPUT_DSI1)))) {
struct drm_bridge *bridge = rcdu->dsi[rcrtc->index];
+ /*
+ * When we have a DSC block between the DU and the DSI,
+ * the "bridge" points to the DSC. Detect the DSC by looking
+ * at the bridge type, and skip the DSC if the bridge is not
+ * the DSI bridge.
+ */
+ if (bridge->type != DRM_MODE_CONNECTOR_DSI)
+ bridge = bridge->next_bridge;
+
rcar_mipi_dsi_pclk_enable(bridge, state);
}
@@ -796,6 +805,15 @@ static void rcar_du_crtc_atomic_disable(struct drm_crtc *crtc,
(BIT(RCAR_DU_OUTPUT_DSI0) | BIT(RCAR_DU_OUTPUT_DSI1)))) {
struct drm_bridge *bridge = rcdu->dsi[rcrtc->index];
+ /*
+ * When we have a DSC block between the DU and the DSI,
+ * the "bridge" points to the DSC. Detect the DSC by looking
+ * at the bridge type, and skip the DSC if the bridge is not
+ * the DSI bridge.
+ */
+ if (bridge->type != DRM_MODE_CONNECTOR_DSI)
+ bridge = bridge->next_bridge;
+
/*
* Disable the DSI clock output, see
* rcar_du_crtc_atomic_enable().
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 aaafee1c060b..f429f03a380c 100644
--- a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c
+++ b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c
@@ -957,6 +957,7 @@ static int rcar_mipi_dsi_host_attach(struct mipi_dsi_host *host,
/* Initialize the DRM bridge. */
dsi->bridge.of_node = dsi->dev->of_node;
+ dsi->bridge.type = DRM_MODE_CONNECTOR_DSI;
drm_bridge_add(&dsi->bridge);
return 0;
--
2.43.0
^ permalink raw reply related
* [PATCH v4 3/7] drm/rcar-du: dsc: Add rudimentary Renesas R-Car V4H DSC driver
From: Tomi Valkeinen @ 2026-06-15 6:28 UTC (permalink / raw)
To: Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Marek Vasut,
Laurent Pinchart, Kieran Bingham, Philipp Zabel
Cc: linux-renesas-soc, linux-clk, linux-kernel, dri-devel, devicetree,
Tomi Valkeinen
In-Reply-To: <20260615-rcar-du-dsc-v4-0-93096a1b56a3@ideasonboard.com>
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
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 | 149 +++++++++++++++++++++++++++++
3 files changed, 162 insertions(+)
diff --git a/drivers/gpu/drm/renesas/rcar-du/Kconfig b/drivers/gpu/drm/renesas/rcar-du/Kconfig
index 840305fdeb49..80bd770ae0f6 100644
--- a/drivers/gpu/drm/renesas/rcar-du/Kconfig
+++ b/drivers/gpu/drm/renesas/rcar-du/Kconfig
@@ -25,6 +25,18 @@ config DRM_RCAR_CMM
def_tristate DRM_RCAR_DU
depends on DRM_RCAR_USE_CMM
+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
+
config DRM_RCAR_DW_HDMI
tristate "R-Car Gen3 and RZ/G2 DU HDMI Encoder Support"
depends on DRM && OF
diff --git a/drivers/gpu/drm/renesas/rcar-du/Makefile b/drivers/gpu/drm/renesas/rcar-du/Makefile
index 6f132325c8b7..9ab7a0ac45d8 100644
--- a/drivers/gpu/drm/renesas/rcar-du/Makefile
+++ b/drivers/gpu/drm/renesas/rcar-du/Makefile
@@ -10,6 +10,7 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
obj-$(CONFIG_DRM_RCAR_CMM) += rcar_cmm.o
+obj-$(CONFIG_DRM_RCAR_DSC) += rcar_dsc.o
obj-$(CONFIG_DRM_RCAR_DU) += rcar-du-drm.o
obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
obj-$(CONFIG_DRM_RCAR_LVDS) += rcar_lvds.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..5a2ff3149136
--- /dev/null
+++ b/drivers/gpu/drm/renesas/rcar-du/rcar_dsc.c
@@ -0,0 +1,149 @@
+// 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/platform_device.h>
+#include <linux/pm_runtime.h>
+
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_bridge.h>
+
+struct rcar_dsc {
+ struct drm_bridge bridge;
+
+ struct device *dev;
+};
+
+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_commit *commit)
+{
+ struct rcar_dsc *dsc = bridge_to_rcar_dsc(bridge);
+
+ WARN_ON(pm_runtime_get_sync(dsc->dev));
+}
+
+static void rcar_dsc_atomic_disable(struct drm_bridge *bridge,
+ struct drm_atomic_commit *commit)
+{
+ 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 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->bridge.next_bridge = of_drm_get_bridge_by_endpoint(dev->of_node,
+ 1, 0);
+ if (IS_ERR(dsc->bridge.next_bridge))
+ return PTR_ERR(dsc->bridge.next_bridge);
+
+ 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,rcar-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");
--
2.43.0
^ permalink raw reply related
* [PATCH v4 2/7] dt-bindings: display: bridge: Document Renesas R-Car V4H DSC bindings
From: Tomi Valkeinen @ 2026-06-15 6:28 UTC (permalink / raw)
To: Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Marek Vasut,
Laurent Pinchart, Kieran Bingham, Philipp Zabel
Cc: linux-renesas-soc, linux-clk, linux-kernel, dri-devel, devicetree,
Tomi Valkeinen, Conor Dooley
In-Reply-To: <20260615-rcar-du-dsc-v4-0-93096a1b56a3@ideasonboard.com>
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>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
.../bindings/display/bridge/renesas,dsc.yaml | 99 ++++++++++++++++++++++
1 file changed, 99 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..4d2c2c6cb1f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,dsc.yaml
@@ -0,0 +1,99 @@
+# 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:
+ items:
+ - enum:
+ - renesas,r8a779g0-dsc
+ - const: renesas,rcar-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>
+
+ bridge@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>;
+ };
+ };
+ };
+ };
+...
--
2.43.0
^ permalink raw reply related
* [PATCH v4 1/7] clk: renesas: r8a779g0: Add DSC clock
From: Tomi Valkeinen @ 2026-06-15 6:28 UTC (permalink / raw)
To: Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Marek Vasut,
Laurent Pinchart, Kieran Bingham, Philipp Zabel
Cc: linux-renesas-soc, linux-clk, linux-kernel, dri-devel, devicetree,
Tomi Valkeinen
In-Reply-To: <20260615-rcar-du-dsc-v4-0-93096a1b56a3@ideasonboard.com>
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>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen+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),
};
--
2.43.0
^ permalink raw reply related
* [PATCH v4 0/7] drm/rcar-du: Add support for DSI pipelines with DSC
From: Tomi Valkeinen @ 2026-06-15 6:28 UTC (permalink / raw)
To: Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Marek Vasut,
Laurent Pinchart, Kieran Bingham, Philipp Zabel
Cc: linux-renesas-soc, linux-clk, linux-kernel, dri-devel, devicetree,
Tomi Valkeinen, Conor Dooley
Some DSI pipelines have DSC (Display Stream Compression) IP block
between the DU and the DSI. Even if DSC is not needed, the IP must be
enabled for the DSI output to work.
This series adds a basic DSC driver, so that the DSC IP gets enabled in
bypass mode. This enables DisplayPort output on Sparrow Hawk board, as
the DP output comes from DSI and sn65dsi86 bridge, and also White Hawk
board's second mini-DP output.
Original series from Marek.
Note: I see that not every run of kms++'s kmstest gives me a picture on
my monitor. Sometimes the monitor seems to be trying to repeatedly sync,
but fails, and the screen stays black. However, I see this same issue on
WhiteHawk, which uses DSI0 pipeline, without DSC, so I think that is a
separate issue.
Tomi
Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
---
Changes in v4:
- Add 'renesas,rcar-dsc' compatible, in addition to the SoC specific
compatible
- Use 'bridge' as the name of the DT node
- Arrange Kconfig and Makefile entries alphabetically
- Rebase on drm-misc-next, and fix the drm_atomic_state rename issue
- Use pm_runtime_get_sync() in .atomic_enable() instead of
pm_runtime_resume_and_get() to fix the possible runtime PM get/put
discrepancy
- Drop ioremap and mmio field, as the driver does not touch the
registers
- Use of_drm_get_bridge_by_endpoint() to get the next bridge
- Rewrite "drm/rcar-du: dsi: Support DSC in the pipeline" to use
bridge->type to detect the DSI and the DSC
- And some cosmetic fixes pointed out in the review comments
- Link to v3: https://patch.msgid.link/20260515-rcar-du-dsc-v3-0-164157820498@ideasonboard.com
Changes in v3:
- Simplify DSC driver: drop reset control, drop clk handling, use runtime PM
- Split dts changes for r8a779g0 and sparrow-hawk to separate patches
- Add "arm64: dts: renesas: white-hawk: Add second mini-DP output
support"
- Link to v2: https://patch.msgid.link/20260515-rcar-du-dsc-v2-0-f6b9240a1240@ideasonboard.com
Changes in v2:
- Fixed the dts example in "dt-bindings: display: bridge: Document
Renesas R-Car V4H DSC bindings"
- Link to v1: https://lore.kernel.org/r/20260514-rcar-du-dsc-v1-0-d65f7a9e9841@ideasonboard.com
---
Geert Uytterhoeven (1):
arm64: dts: renesas: white-hawk: Add second mini-DP output support
Marek Vasut (5):
clk: renesas: r8a779g0: Add DSC clock
dt-bindings: display: bridge: Document Renesas R-Car V4H DSC bindings
drm/rcar-du: dsc: Add rudimentary Renesas R-Car V4H DSC driver
arm64: dts: renesas: r8a779g0: Add DSC
arm64: dts: renesas: sparrow-hawk: Enable DisplayPort by adding DSC
Tomi Valkeinen (1):
drm/rcar-du: dsi: Support DSC in the pipeline
.../bindings/display/bridge/renesas,dsc.yaml | 99 ++++++++++++++
.../arm64/boot/dts/renesas/r8a779g0-white-hawk.dts | 94 +++++++++++++
arch/arm64/boot/dts/renesas/r8a779g0.dtsi | 31 ++++-
.../boot/dts/renesas/r8a779g3-sparrow-hawk.dts | 5 +
drivers/clk/renesas/r8a779g0-cpg-mssr.c | 1 +
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 | 149 +++++++++++++++++++++
drivers/gpu/drm/renesas/rcar-du/rcar_du_crtc.c | 18 +++
drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c | 1 +
10 files changed, 410 insertions(+), 1 deletion(-)
---
base-commit: a56a73ec85c81c7e533bc249ff0fd996256053fd
change-id: 20260514-rcar-du-dsc-45bcf0c2fe86
Best regards,
--
Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
^ permalink raw reply
* RE: [PATCH] dt-bindings: mfd: syscon: Revert renesas,r9a08g046-lvds-cmn
From: Biju Das @ 2026-06-15 6:27 UTC (permalink / raw)
To: Krzysztof Kozlowski, Krzysztof Kozlowski
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, magnus.damm, Tommaso Merciai,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <20260615-ultramarine-vole-of-art-653db7@quoll>
Hi Krzysztof Kozlowski,
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: 15 June 2026 07:10
> Subject: Re: [PATCH] dt-bindings: mfd: syscon: Revert renesas,r9a08g046-lvds-cmn
>
> On Mon, Jun 08, 2026 at 01:55:08PM +0200, Krzysztof Kozlowski wrote:
> > Revert commit 51284d8b1dbc ("dt-bindings: mfd: syscon: Document the
> > LVDS_CMN syscon for the RZ/G3L") because it is completely not matching
> > reality and clearly incorrect in respect of renesas,r9a08g046-lvds-cmn.
> >
> > It wasn't ever build-tested by author on their DTS, either.
> >
> > The documented renesas,r9a08g046-lvds-cmn compatible clearly disallows
> > any children and simple-mfd fallback, however its only use in original
> > patchset is with simple-mfd and children, so this could have never
> > worked.
> >
> > Fixes: 51284d8b1dbc ("dt-bindings: mfd: syscon: Document the LVDS_CMN
> > syscon for the RZ/G3L")
> > Signed-off-by: Krzysztof Kozlowski
> > <krzysztof.kozlowski@oss.qualcomm.com>
> > ---
> > Documentation/devicetree/bindings/mfd/syscon.yaml | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml
> > b/Documentation/devicetree/bindings/mfd/syscon.yaml
> > index 9c81010d5a74..e22867088063 100644
> > --- a/Documentation/devicetree/bindings/mfd/syscon.yaml
> > +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
>
>
> For the record: this patch is still valid and justified, even with my other syscon-related work.
>
> The compatible here is not correctly documented and should be reverted.
I agree.
Acked-by: Biju Das <biju.das.jz@bp.renesas.com>
Cheers,
Biju
^ permalink raw reply
* Re: [PATCH v3 00/13] Support ACPI and SETAASA device discovery
From: Akhil R @ 2026-06-15 6:25 UTC (permalink / raw)
To: alexandre.belloni
Cc: Frank.Li, acpica-devel, akhilrajeev, arnd, bjorn.andersson,
conor+dt, devicetree, dmitry.baryshkov, ebiggers, geert,
jonathanh, krzk+dt, lenb, linux-acpi, linux-hwmon, linux-i3c,
linux-kernel, linux-tegra, linux, miquel.raynal, p.zabel, rafael,
robh, saket.dumbre, treding, wsa+renesas
In-Reply-To: <2026061420560674ab6fb9@mail.local>
On Sun, 14 Jun 2026 22:56:06 +0200, Alexandre Belloni wrote:
> On 23/04/2026 14:26:59+0530, Akhil R wrote:
>> This patch series adds SETAASA device discovery to the I3C subsystem,
>> enabling support for SPD5118 temperature sensors found on DDR5 memory
>> modules. The changes also add ACPI support for all existing DAA
>> methods like SETDASA, SETNEWDA as well as I2C devices on I3C bus.
>>
>> SPD5118 and similar devices on DDR5 memory modules differ from typical
>> I3C devices in their initialization. They use SETAASA broadcast CCC
>> instead of ENTDAA for address assignment, and per JEDEC specification,
>> are not required to have a Provisioned ID or implement standard device
>> information CCC commands (GETPID, GETDCR, GETBCR).
>>
>> The series enables to describe all I3C and I2C devices on both Device
>> Tree and the ACPI table, using unified device property APIs throughout
>> the I3C core and the Synopsys DesignWare I3C master driver.
>>
>> Please note that the series modifies drivers across multiple subsystems,
>> like Device Tree bindings, ACPI, I3C and HWMON.
>>
>> v2->v3:
>> * Fix maximum value and indent bit list for mipi-i3c-static-method.
>> * Move I3C_ADDR_METHOD_* macros to dt-bindings header.
>> * Drop ACPICA commit IDs, keep only the Link: tags.
>> * Revert the change which proceeds to register other devices if SETAASA
>> is not supported so that it aligns with the rest of the driver and to
>> avoid the issues pointed by Sashiko.
>> * Rework multiple commit messages.
>>
>> v1->v2:
>> * Added patch to remove 16-bit addressing support for SPD5118
>> * Guard ACPI calls with #ifdef CONFIG_ACPI
>> * Remove CONFIG_OF guard for of_alias_get_highest_id()
>> * Mask mipi-i3c-static-method in the driver to select only valid values.
>> * Proceed to register other devices if SETAASA is not supported.
>> * Update commit message and links in the description of multiple commits.
>>
>>
>> Akhil R (13):
>> dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA
>> ACPICA: Read LVR from the I2C resource descriptor
>> i3c: master: Use unified device property interface
>> i3c: master: Support ACPI enumeration of child devices
>> i3c: master: Add support for devices using SETAASA
>> i3c: master: Add support for devices without PID
>> i3c: master: match I3C device through DT and ACPI
>> i3c: dw-i3c-master: Add SETAASA as supported CCC
>> i3c: dw-i3c-master: Add a quirk to skip clock and reset
>> i3c: dw-i3c-master: Add ACPI ID for Tegra410
>> hwmon: spd5118: Remove 16-bit addressing
>> hwmon: spd5118: Add I3C support
>> arm64: defconfig: Enable I3C and SPD5118 hwmon
>>
>
> I'd really like to apply this but I would have preferred having an
> actual ack from Rob on patch 1. Also, you are going to have to rebase on
> the current i3c-next. Can you do this?
Definitely. I had been addressing the comments from Rob and Saashiko, but
got hooked up into somethings else in the last few weeks. I will send v4
soon. Thanks for reaching out.
Best Regards,
Akhil
^ permalink raw reply
* Re: [PATCH v6 0/6] mfd: cpcap: convert documentation to schema and add Mot board support
From: Svyatoslav Ryhel @ 2026-06-15 6:25 UTC (permalink / raw)
To: Lee Jones
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Pavel Machek, linux-input, devicetree, linux-kernel, linux-leds
In-Reply-To: <20260527151432.GE671544@google.com>
ср, 27 трав. 2026 р. о 18:14 Lee Jones <lee@kernel.org> пише:
>
> On Wed, 20 May 2026, Svyatoslav Ryhel wrote:
>
> > The initial goal was only to add support for the CPCAP used in the Mot
> > Tegra20 board; however, since the documentation was already partially
> > converted, I decided to complete the conversion to schema too.
> >
> > The CPCAP regulator, leds, rtc, pwrbutton and core files were converted
> > from TXT to YAML while preserving the original structure. Mot board
> > compatibility was added to the regulator and core schema. Since these
> > were one-line patches, they were not separated into dedicated commits;
> > however, the commit message notes this for both cases.
> >
> > Finally, the CPCAP MFD was slightly refactored to improve support for
> > multiple subcell compositions.
>
> Once you've fixed the DT issues that Rob pointed out, I'll merge the set.
Hello Lee! This patchset already contains fixes Rob pointed to. May
you please merge it?
> --
> Lee Jones
^ permalink raw reply
* RE: [PATCH v4 5/5] rtc: pcf85363: add watchdog support with configurable step size
From: Lakshay Piplani @ 2026-06-15 6:25 UTC (permalink / raw)
To: Lakshay Piplani, alexandre.belloni@bootlin.com,
linux-rtc@vger.kernel.org, linux-kernel@vger.kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
devicetree@vger.kernel.org, wim@linux-watchdog.org,
linux@roeck-us.net, linux-watchdog@vger.kernel.org
Cc: Vikash Bansal, Priyanka Jain
In-Reply-To: <20251121121137.3043764-5-lakshay.piplani@nxp.com>
> /*
> * Reads 6 bytes of timestamp data starting at the given base register,
> * converts them from BCD to binary, and formats the result into a @@ -685,6
> +833,10 @@ static int pcf85363_probe(struct i2c_client *client)
> PIN_IO_TSPM | PIN_IO_TSIM,
> PIN_IO_TSPM | PIN_IO_TSIM);
>
> + ret = pcf85363_watchdog_init(dev, pcf85363->regmap);
> + if (ret)
> + dev_err_probe(dev, ret, "Watchdog init failed\n");
> +
> if (irq_a > 0 || wakeup_source)
> device_init_wakeup(dev, true);
>
> --
> 2.25.1
Hi,
I hope you're doing well.
This is a gentle follow-up regarding the v4 patch series for the PCF85363 RTC driver that I submitted in November 2025.
I understand things can get busy, but I haven't seen any feedback on the series yet, so I wanted to check if you've had a chance to review it.
I'd be happy to make any updates if needed. Please let me know if there's anything required from my side to move this forward.
Thanks in advance for your time and feedback.
Best regards,
Lakshay Piplani
^ permalink raw reply
* RE: [PATCH v4 4/5] rtc: pcf85363: add oscillator offset calibration support
From: Lakshay Piplani @ 2026-06-15 6:23 UTC (permalink / raw)
To: Lakshay Piplani, alexandre.belloni@bootlin.com,
linux-rtc@vger.kernel.org, linux-kernel@vger.kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
devicetree@vger.kernel.org, wim@linux-watchdog.org,
linux@roeck-us.net, linux-watchdog@vger.kernel.org
Cc: Vikash Bansal, Priyanka Jain
In-Reply-To: <20251121121137.3043764-4-lakshay.piplani@nxp.com>
> -----Original Message-----
> From: Lakshay Piplani <lakshay.piplani@nxp.com>
> Sent: Friday, November 21, 2025 5:42 PM
> To: alexandre.belloni@bootlin.com; linux-rtc@vger.kernel.org; linux-
> kernel@vger.kernel.org; robh@kernel.org; krzk+dt@kernel.org;
> conor+dt@kernel.org; devicetree@vger.kernel.org; wim@linux-watchdog.org;
> linux@roeck-us.net; linux-watchdog@vger.kernel.org
> Cc: Vikash Bansal <vikash.bansal@nxp.com>; Priyanka Jain
> <priyanka.jain@nxp.com>; Shashank Rebbapragada
> <shashank.rebbapragada@nxp.com>; Lakshay Piplani
> <lakshay.piplani@nxp.com>
> Subject: [PATCH v4 4/5] rtc: pcf85363: add oscillator offset calibration support
>
> Expose the oscillator offset register of PCF85263/PCF85363 through the
> rtc_class_ops read_offset and set_offset callbacks, allowing userspace to apply
> frequency correction for drift compensation.
>
> The correction mode defaults to normal mode (OFFM = 0), where each step
> introduces an offset of approximately 2.170 ppm and corrections occur every 4
> hours.
>
> Signed-off-by: Lakshay Piplani <lakshay.piplani@nxp.com>
> ---
> V3 -> V4:
> - No changes in v4.
> V2 -> V3:
> - Split into separate patches as suggested:
> - Battery switch-over detection.
> - Timestamp recording for TS pin and battery switch-over events.
> - Offset calibration.
> - Watchdog timer (to be reviewed by watchdog maintainers).
> - Dropped Alarm2 support
> - Switched to rtc_add_group() for sysfs attributes
> V1 -> V2:
> - Watchdog related changes due to removal of vendor specific properties
> from device tree
> * remove vendor DT knobs (enable/timeout/stepsize/repeat)
> * use watchdog_init_timeout (with 10s default)
> * derive clock_sel from final timeout
> * default, repeat=true (repeat mode)
> - Fixed uninitalised warning on 'ret' (reported by kernel test robot)
> - Use dev_dbg instead of dev_info for debug related print messages
> - Minor cleanup and comments.
>
> drivers/rtc/rtc-pcf85363.c | 46
> ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
>
> diff --git a/drivers/rtc/rtc-pcf85363.c b/drivers/rtc/rtc-pcf85363.c index
> e10e58f69012..665bbbb169b0 100644
> --- a/drivers/rtc/rtc-pcf85363.c
> +++ b/drivers/rtc/rtc-pcf85363.c
> @@ -123,6 +123,11 @@
> #define TSR2_SHIFT 2
> #define TSR3_SHIFT 6
>
> +#define OFFSET_SIGN_BIT 7
> +#define OFFSET_MINIMUM -128
> +#define OFFSET_MAXIMUM 127
> +#define OFFSET_MASK 0xFF
> +
> struct pcf85363 {
> struct rtc_device *rtc;
> struct regmap *regmap;
> @@ -359,6 +364,45 @@ static irqreturn_t pcf85363_rtc_handle_irq(int irq,
> void *dev_id)
> return handled ? IRQ_HANDLED : IRQ_NONE; }
>
> +/*
> + * Read the current RTC offset from the CTRL_OFFSET
> + * register. This value is an 8-bit signed 2's complement
> + * value that corrects osciallator drift.
> + */
> +static int pcf85363_read_offset(struct device *dev, long *offset) {
> + struct pcf85363 *pcf85363 = dev_get_drvdata(dev);
> + unsigned int val;
> + int ret;
> +
> + ret = regmap_read(pcf85363->regmap, CTRL_OFFSET, &val);
> +
> + if (ret)
> + return ret;
> +
> + *offset = sign_extend32(val & OFFSET_MASK, OFFSET_SIGN_BIT);
> +
> + return 0;
> +}
> +
> +/*
> + * Write an oscillator offset correction value to
> + * the CTRL_OFFSET register. The valid range is
> + * -128 to 127 (8-bit signed), typically used to fine
> + * tune accuracy.
> + */
> +static int pcf85363_set_offset(struct device *dev, long offset) {
> + struct pcf85363 *pcf85363 = dev_get_drvdata(dev);
> +
> + if (offset < OFFSET_MINIMUM || offset > OFFSET_MAXIMUM) {
> + dev_warn(dev, "Offset out of range: %ld\n", offset);
> + return -ERANGE;
> + }
> +
> + return regmap_write(pcf85363->regmap, CTRL_OFFSET, offset &
> +OFFSET_MASK); }
> +
> static int pcf85363_rtc_ioctl(struct device *dev,
> unsigned int cmd, unsigned long arg) { @@ -396,6
> +440,8 @@ static const struct rtc_class_ops rtc_ops = {
> .read_alarm = pcf85363_rtc_read_alarm,
> .set_alarm = pcf85363_rtc_set_alarm,
> .alarm_irq_enable = pcf85363_rtc_alarm_irq_enable,
> + .read_offset = pcf85363_read_offset,
> + .set_offset = pcf85363_set_offset,
> };
>
> static int pcf85363_nvram_read(void *priv, unsigned int offset, void *val,
> --
> 2.25.1
Hi,
I hope you're doing well.
This is a gentle follow-up regarding the v4 patch series for the PCF85363 RTC driver that I submitted in November 2025.
I understand things can get busy, but I haven't seen any feedback on the series yet, so I wanted to check if you've had a chance to review it.
I'd be happy to make any updates if needed. Please let me know if there's anything required from my side to move this forward.
Thanks in advance for your time and feedback.
Best regards,
Lakshay Piplani
^ permalink raw reply
* Re: [PATCH v8 4/7] input: keyboard: Add driver for ASUS Transformer dock multimedia keys
From: Svyatoslav Ryhel @ 2026-06-15 6:23 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Rob Herring, Krzysztof Kozlowski, Michał Mirosław,
Ion Agorria, Svyatoslav Ryhel, Sebastian Reichel, Pavel Machek,
Lee Jones, Conor Dooley, devicetree, linux-kernel, linux-input,
linux-leds, linux-pm
In-Reply-To: <20260528053203.9339-5-clamor95@gmail.com>
чт, 28 трав. 2026 р. о 08:32 Svyatoslav Ryhel <clamor95@gmail.com> пише:
>
> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
>
> Add support for multimedia top button row of ASUS Transformer's Mobile
> Dock keyboard. Driver is made that function keys (F1-F12) are used by
> default which suits average Linux use better and with pressing
> ScreenLock + AltGr function keys layout is switched to multimedia keys.
> Since this only modifies codes sent by asus-ec-keys it doesn't affect
> normal keyboards at all.
>
> Co-developed-by: Ion Agorria <ion@agorria.com>
> Signed-off-by: Ion Agorria <ion@agorria.com>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> drivers/input/keyboard/Kconfig | 10 +
> drivers/input/keyboard/Makefile | 1 +
> .../input/keyboard/asus-transformer-ec-keys.c | 286 ++++++++++++++++++
> 3 files changed, 297 insertions(+)
> create mode 100644 drivers/input/keyboard/asus-transformer-ec-keys.c
>
Hello Dmitry! May you please take a look and Ack it if you are fine
this this driver or tell what I should adjust? That would be very
helpful. Thank you.
^ permalink raw reply
* RE: [PATCH v4 3/5] rtc: pcf85363: add timestamp support with configurable timestamp mode
From: Lakshay Piplani @ 2026-06-15 6:23 UTC (permalink / raw)
To: Lakshay Piplani, alexandre.belloni@bootlin.com,
linux-rtc@vger.kernel.org, linux-kernel@vger.kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
devicetree@vger.kernel.org, wim@linux-watchdog.org,
linux@roeck-us.net, linux-watchdog@vger.kernel.org
Cc: Vikash Bansal, Priyanka Jain
In-Reply-To: <20251121121137.3043764-3-lakshay.piplani@nxp.com>
> -----Original Message-----
> From: Lakshay Piplani <lakshay.piplani@nxp.com>
> Sent: Friday, November 21, 2025 5:42 PM
> To: alexandre.belloni@bootlin.com; linux-rtc@vger.kernel.org; linux-
> kernel@vger.kernel.org; robh@kernel.org; krzk+dt@kernel.org;
> conor+dt@kernel.org; devicetree@vger.kernel.org; wim@linux-watchdog.org;
> linux@roeck-us.net; linux-watchdog@vger.kernel.org
> Cc: Vikash Bansal <vikash.bansal@nxp.com>; Priyanka Jain
> <priyanka.jain@nxp.com>; Shashank Rebbapragada
> <shashank.rebbapragada@nxp.com>; Lakshay Piplani
> <lakshay.piplani@nxp.com>
> Subject: [PATCH v4 3/5] rtc: pcf85363: add timestamp support with
> configurable timestamp mode
>
> Add support for the timestamp capture registers available on PCF85263 and
> PCF85363. The registers latch the current time when selected events occur,
> such as TS pin activation or battery switch-over.
>
> The capture source can be configured via the nxp,timestamp-mode device tree
> property, and latched values are exported through read-only sysfs attributes.
>
> Additionally:
> - Use rtc_add_group() instead of sysfs_create_group() to register the
> timestamp attributes under the RTC class device (/sys/class/rtc/rtcX).
> - Perform minor cleanups in the probe function for better readability.
>
> Signed-off-by: Lakshay Piplani <lakshay.piplani@nxp.com>
> ---
> V3 -> V4:
> - No changes in v4.
> V2 -> V3:
> - Split into separate patches as suggested:
> - Battery switch-over detection.
> - Timestamp recording for TS pin and battery switch-over events.
> - Offset calibration.
> - Watchdog timer (to be reviewed by watchdog maintainers).
> - Dropped Alarm2 support
> - Switched to rtc_add_group() for sysfs attributes
> V1 -> V2:
> - Watchdog related changes due to removal of vendor specific properties
> from device tree
> * remove vendor DT knobs (enable/timeout/stepsize/repeat)
> * use watchdog_init_timeout (with 10s default)
> * derive clock_sel from final timeout
> * default, repeat=true (repeat mode)
> - Fixed uninitalised warning on 'ret' (reported by kernel test robot)
> - Use dev_dbg instead of dev_info for debug related print messages
> - Minor cleanup and comments.
>
> drivers/rtc/rtc-pcf85363.c | 209 +++++++++++++++++++++++++++++++------
> 1 file changed, 175 insertions(+), 34 deletions(-)
Hi,
I hope you're doing well.
This is a gentle follow-up regarding the v4 patch series for the PCF85363 RTC driver that I submitted in November 2025.
I understand things can get busy, but I haven't seen any feedback on the series yet, so I wanted to check if you've had a chance to review it.
I'd be happy to make any updates if needed. Please let me know if there's anything required from my side to move this forward.
Thanks in advance for your time and feedback.
Best regards,
Lakshay Piplani
^ permalink raw reply
* Re: [PATCH v2 2/3] regulator: dt-bindings: qcom,sdm845-refgen-regulator: Document IPQ9650
From: Kathiravan Thirumoorthy @ 2026-06-15 6:22 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, linux-arm-msm, linux-kernel,
devicetree
In-Reply-To: <20260612-blazing-brainy-firefly-d77a6b@quoll>
On 6/12/2026 2:32 PM, Krzysztof Kozlowski wrote:
> On Thu, Jun 11, 2026 at 02:33:17PM +0530, Kathiravan Thirumoorthy wrote:
>> IPQ9650 has two REFGEN blocks which provide reference current to the PCIe,
>> USB and UNIPHY PHYs. Unlike other supported platforms, IPQ9650 requires the
>> REFGEN clocks to be enabled explicitly.
>>
>> Document the IPQ9650 compatible and the required clocks for it.
>>
>> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
>
> You just ignored feedback... From me and Sashiko.
Sorry, I missed that. Let me address that in the next spin.
>
> So you got the same comments.
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v8 3/7] input: serio: Add driver for ASUS Transformer dock keyboard and touchpad
From: Svyatoslav Ryhel @ 2026-06-15 6:22 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lee Jones,
Pavel Machek, Sebastian Reichel, Ion Agorria,
Michał Mirosław, Svyatoslav Ryhel, devicetree,
linux-kernel, linux-input, linux-leds, linux-pm
In-Reply-To: <20260528053203.9339-4-clamor95@gmail.com>
чт, 28 трав. 2026 р. о 08:32 Svyatoslav Ryhel <clamor95@gmail.com> пише:
>
> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
>
> Add input driver for ASUS Transformer dock keyboard and touchpad.
>
> Some keys in ASUS Dock report keycodes that don't make sense according to
> their position, this patch modifies the incoming data that is sent to
> serio to send proper scancodes.
>
> Co-developed-by: Ion Agorria <ion@agorria.com>
> Signed-off-by: Ion Agorria <ion@agorria.com>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> drivers/input/serio/Kconfig | 15 ++
> drivers/input/serio/Makefile | 1 +
> drivers/input/serio/asus-transformer-ec-kbc.c | 158 ++++++++++++++++++
> 3 files changed, 174 insertions(+)
> create mode 100644 drivers/input/serio/asus-transformer-ec-kbc.c
Hello Dmitry! May you please take a look and Ack it if you are fine
this this driver or tell what I should adjust? That would be very
helpful. Thank you.
^ permalink raw reply
* [PATCH v2 4/4] iio: dac: ad3530r: Add support for AD3532R/AD3532
From: Kim Seer Paller @ 2026-06-15 6:20 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-iio, linux-kernel, linux, devicetree, Kim Seer Paller
In-Reply-To: <20260615-iio-ad3532r-support-v2-0-84a0af8b83fa@analog.com>
The AD3532R/AD3532 is a 16-channel, 16-bit voltage output DAC with a
dual-bank register architecture (bank 0 at 0x1000 for channels 0-7,
bank 1 at 0x3000 for channels 8-15). It shares similar functionality
with AD3530R (channel configuration, LDAC triggering, powerdown control),
the main difference being the register address map due to the dual-bank
architecture, handled by table-driven helpers.
Add AD3532R-specific register definitions, channel specs, per-bank
register arrays, a dedicated ad3532r_set_dac_powerdown(), and per-chip
regmap_config to limit debugfs-exposed register space to each variant's
actual address range.
Signed-off-by: Kim Seer Paller <kimseer.paller@analog.com>
---
drivers/iio/dac/Kconfig | 4 +-
drivers/iio/dac/ad3530r.c | 208 +++++++++++++++++++++++++++++++++++++++++++---
2 files changed, 197 insertions(+), 15 deletions(-)
diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
index 657c68e75542..f034f7dda703 100644
--- a/drivers/iio/dac/Kconfig
+++ b/drivers/iio/dac/Kconfig
@@ -11,8 +11,8 @@ config AD3530R
depends on SPI
select REGMAP_SPI
help
- Say yes here to build support for Analog Devices AD3530R, AD3531R
- Digital to Analog Converter.
+ Say yes here to build support for Analog Devices AD3530/AD3530R,
+ AD3531/AD3531R, and AD3532/AD3532R Digital to Analog Converters.
To compile this driver as a module, choose M here: the
module will be called ad3530r.
diff --git a/drivers/iio/dac/ad3530r.c b/drivers/iio/dac/ad3530r.c
index e4346bc729ba..435d98ce29cb 100644
--- a/drivers/iio/dac/ad3530r.c
+++ b/drivers/iio/dac/ad3530r.c
@@ -2,6 +2,7 @@
/*
* AD3530R/AD3530 8-channel, 16-bit Voltage Output DAC Driver
* AD3531R/AD3531 4-channel, 16-bit Voltage Output DAC Driver
+ * AD3532R/AD3532 16-channel, 16-bit Voltage Output DAC Driver
*
* Copyright 2025 Analog Devices Inc.
*/
@@ -39,6 +40,22 @@
#define AD3531R_SW_LDAC_TRIG_A 0xDD
#define AD3531R_INPUT_CH 0xE3
+#define AD3532R_INTERFACE_CONFIG_A_0 0x1000
+#define AD3532R_INTERFACE_CONFIG_A_1 0x3000
+#define AD3532R_OUTPUT_OPERATING_MODE_0 0x1020
+#define AD3532R_OUTPUT_OPERATING_MODE_1 0x1021
+#define AD3532R_OUTPUT_OPERATING_MODE_2 0x3020
+#define AD3532R_OUTPUT_OPERATING_MODE_3 0x3021
+#define AD3532R_OUTPUT_CONTROL_0 0x102A
+#define AD3532R_OUTPUT_CONTROL_1 0x302A
+#define AD3532R_REFERENCE_CONTROL_0 0x103C
+#define AD3532R_REFERENCE_CONTROL_1 0x303C
+#define AD3532R_SW_LDAC_TRIG_0 0x10E5
+#define AD3532R_SW_LDAC_TRIG_1 0x30E5
+#define AD3532R_INPUT_CH_0 0x10EB
+#define AD3532R_INPUT_CH_1 0x30EB
+#define AD3532R_MAX_REG_ADDR 0x30F9
+
#define AD3530R_SLD_TRIG_A BIT(7)
#define AD3530R_OUTPUT_CONTROL_RANGE BIT(2)
#define AD3530R_REFERENCE_CONTROL_SEL BIT(0)
@@ -50,8 +67,10 @@
#define AD3530R_LDAC_PULSE_US 100
#define AD3530R_DAC_MAX_VAL GENMASK(15, 0)
-#define AD3530R_MAX_CHANNELS 8
+#define AD3530R_CH_PER_REG 4
+#define AD3530R_CH_PER_BANK 8
#define AD3531R_MAX_CHANNELS 4
+#define AD3532R_MAX_CHANNELS 16
enum ad3530r_mode {
AD3530R_NORMAL_OP,
@@ -68,6 +87,7 @@ struct ad3530r_chan {
struct ad3530r_chip_info {
const char *name;
const struct iio_chan_spec *channels;
+ const struct regmap_config *regmap_config;
int (*input_ch_reg)(unsigned int channel);
int (*sw_ldac_trig_reg)(unsigned int channel);
const unsigned int *interface_config_a;
@@ -84,7 +104,7 @@ struct ad3530r_state {
struct regmap *regmap;
/* lock to protect against multiple access to the device and shared data */
struct mutex lock;
- struct ad3530r_chan chan[AD3530R_MAX_CHANNELS];
+ struct ad3530r_chan chan[AD3532R_MAX_CHANNELS];
const struct ad3530r_chip_info *chip_info;
struct gpio_desc *ldac_gpio;
int vref_mV;
@@ -105,6 +125,14 @@ static int ad3531r_input_ch_reg(unsigned int channel)
return 2 * channel + AD3531R_INPUT_CH;
}
+static int ad3532r_input_ch_reg(unsigned int channel)
+{
+ if (channel < 8)
+ return 2 * channel + AD3532R_INPUT_CH_0;
+
+ return 2 * (channel - 8) + AD3532R_INPUT_CH_1;
+}
+
static const char * const ad3530r_powerdown_modes[] = {
"1kohm_to_gnd",
"7.7kohm_to_gnd",
@@ -117,6 +145,12 @@ static const char * const ad3531r_powerdown_modes[] = {
"16kohm_to_gnd",
};
+static const char * const ad3532r_powerdown_modes[] = {
+ "1kohm_to_gnd",
+ "10kohm_to_gnd",
+ "three_state",
+};
+
static int ad3530r_get_powerdown_mode(struct iio_dev *indio_dev,
const struct iio_chan_spec *chan)
{
@@ -152,6 +186,13 @@ static const struct iio_enum ad3531r_powerdown_mode_enum = {
.set = ad3530r_set_powerdown_mode,
};
+static const struct iio_enum ad3532r_powerdown_mode_enum = {
+ .items = ad3532r_powerdown_modes,
+ .num_items = ARRAY_SIZE(ad3532r_powerdown_modes),
+ .get = ad3530r_get_powerdown_mode,
+ .set = ad3530r_set_powerdown_mode,
+};
+
static ssize_t ad3530r_get_dac_powerdown(struct iio_dev *indio_dev,
uintptr_t private,
const struct iio_chan_spec *chan,
@@ -196,6 +237,39 @@ static ssize_t ad3530r_set_dac_powerdown(struct iio_dev *indio_dev,
return len;
}
+static ssize_t ad3532r_set_dac_powerdown(struct iio_dev *indio_dev,
+ uintptr_t private,
+ const struct iio_chan_spec *chan,
+ const char *buf, size_t len)
+{
+ struct ad3530r_state *st = iio_priv(indio_dev);
+ unsigned int reg, pdmode, mask, val, local_ch;
+ bool powerdown;
+ int ret;
+
+ ret = kstrtobool(buf, &powerdown);
+ if (ret)
+ return ret;
+
+ guard(mutex)(&st->lock);
+ local_ch = chan->channel % AD3530R_CH_PER_BANK;
+ reg = (chan->channel < AD3530R_CH_PER_BANK ? AD3532R_OUTPUT_OPERATING_MODE_0 :
+ AD3532R_OUTPUT_OPERATING_MODE_2) +
+ local_ch / AD3530R_CH_PER_REG;
+ mask = AD3530R_OP_MODE_CHAN_MSK(local_ch % AD3530R_CH_PER_REG);
+
+ pdmode = powerdown ? st->chan[chan->channel].powerdown_mode : 0;
+ val = field_prep(mask, pdmode);
+
+ ret = regmap_update_bits(st->regmap, reg, mask, val);
+ if (ret)
+ return ret;
+
+ st->chan[chan->channel].powerdown = powerdown;
+
+ return len;
+}
+
static int ad3530r_trigger_sw_ldac_reg(unsigned int channel)
{
return AD3530R_SW_LDAC_TRIG_A;
@@ -206,6 +280,14 @@ static int ad3531r_trigger_sw_ldac_reg(unsigned int channel)
return AD3531R_SW_LDAC_TRIG_A;
}
+static int ad3532r_trigger_sw_ldac_reg(unsigned int channel)
+{
+ if (channel < 8)
+ return AD3532R_SW_LDAC_TRIG_0;
+
+ return AD3532R_SW_LDAC_TRIG_1;
+}
+
static int ad3530r_trigger_hw_ldac(struct gpio_desc *ldac_gpio)
{
gpiod_set_value_cansleep(ldac_gpio, 1);
@@ -318,6 +400,19 @@ static const struct iio_chan_spec_ext_info ad3531r_ext_info[] = {
{ }
};
+static const struct iio_chan_spec_ext_info ad3532r_ext_info[] = {
+ {
+ .name = "powerdown",
+ .shared = IIO_SEPARATE,
+ .read = ad3530r_get_dac_powerdown,
+ .write = ad3532r_set_dac_powerdown,
+ },
+ IIO_ENUM("powerdown_mode", IIO_SEPARATE, &ad3532r_powerdown_mode_enum),
+ IIO_ENUM_AVAILABLE("powerdown_mode", IIO_SHARED_BY_TYPE,
+ &ad3532r_powerdown_mode_enum),
+ { }
+};
+
#define AD3530R_CHAN(_chan, _ext_info) \
{ \
.type = IIO_VOLTAGE, \
@@ -347,6 +442,25 @@ static const struct iio_chan_spec ad3531r_channels[] = {
AD3530R_CHAN(3, ad3531r_ext_info),
};
+static const struct iio_chan_spec ad3532r_channels[] = {
+ AD3530R_CHAN(0, ad3532r_ext_info),
+ AD3530R_CHAN(1, ad3532r_ext_info),
+ AD3530R_CHAN(2, ad3532r_ext_info),
+ AD3530R_CHAN(3, ad3532r_ext_info),
+ AD3530R_CHAN(4, ad3532r_ext_info),
+ AD3530R_CHAN(5, ad3532r_ext_info),
+ AD3530R_CHAN(6, ad3532r_ext_info),
+ AD3530R_CHAN(7, ad3532r_ext_info),
+ AD3530R_CHAN(8, ad3532r_ext_info),
+ AD3530R_CHAN(9, ad3532r_ext_info),
+ AD3530R_CHAN(10, ad3532r_ext_info),
+ AD3530R_CHAN(11, ad3532r_ext_info),
+ AD3530R_CHAN(12, ad3532r_ext_info),
+ AD3530R_CHAN(13, ad3532r_ext_info),
+ AD3530R_CHAN(14, ad3532r_ext_info),
+ AD3530R_CHAN(15, ad3532r_ext_info),
+};
+
static const unsigned int ad3530r_if_config[] = {
AD3530R_INTERFACE_CONFIG_A,
};
@@ -368,9 +482,44 @@ static const unsigned int ad3531r_op_mode[] = {
AD3530R_OUTPUT_OPERATING_MODE_0,
};
+static const unsigned int ad3532r_if_config[] = {
+ AD3532R_INTERFACE_CONFIG_A_0,
+ AD3532R_INTERFACE_CONFIG_A_1,
+};
+
+static const unsigned int ad3532r_out_ctrl[] = {
+ AD3532R_OUTPUT_CONTROL_0,
+ AD3532R_OUTPUT_CONTROL_1,
+};
+
+static const unsigned int ad3532r_ref_ctrl[] = {
+ AD3532R_REFERENCE_CONTROL_0,
+ AD3532R_REFERENCE_CONTROL_1,
+};
+
+static const unsigned int ad3532r_op_mode[] = {
+ AD3532R_OUTPUT_OPERATING_MODE_0,
+ AD3532R_OUTPUT_OPERATING_MODE_1,
+ AD3532R_OUTPUT_OPERATING_MODE_2,
+ AD3532R_OUTPUT_OPERATING_MODE_3,
+};
+
+static const struct regmap_config ad3530r_regmap_config = {
+ .reg_bits = 16,
+ .val_bits = 8,
+ .max_register = AD3530R_MAX_REG_ADDR,
+};
+
+static const struct regmap_config ad3532r_regmap_config = {
+ .reg_bits = 16,
+ .val_bits = 8,
+ .max_register = AD3532R_MAX_REG_ADDR,
+};
+
static const struct ad3530r_chip_info ad3530_chip = {
.name = "ad3530",
.channels = ad3530r_channels,
+ .regmap_config = &ad3530r_regmap_config,
.num_channels = ARRAY_SIZE(ad3530r_channels),
.sw_ldac_trig_reg = ad3530r_trigger_sw_ldac_reg,
.input_ch_reg = ad3530r_input_ch_reg,
@@ -386,6 +535,7 @@ static const struct ad3530r_chip_info ad3530_chip = {
static const struct ad3530r_chip_info ad3530r_chip = {
.name = "ad3530r",
.channels = ad3530r_channels,
+ .regmap_config = &ad3530r_regmap_config,
.num_channels = ARRAY_SIZE(ad3530r_channels),
.sw_ldac_trig_reg = ad3530r_trigger_sw_ldac_reg,
.input_ch_reg = ad3530r_input_ch_reg,
@@ -402,6 +552,7 @@ static const struct ad3530r_chip_info ad3530r_chip = {
static const struct ad3530r_chip_info ad3531_chip = {
.name = "ad3531",
.channels = ad3531r_channels,
+ .regmap_config = &ad3530r_regmap_config,
.num_channels = ARRAY_SIZE(ad3531r_channels),
.sw_ldac_trig_reg = ad3531r_trigger_sw_ldac_reg,
.input_ch_reg = ad3531r_input_ch_reg,
@@ -417,6 +568,7 @@ static const struct ad3530r_chip_info ad3531_chip = {
static const struct ad3530r_chip_info ad3531r_chip = {
.name = "ad3531r",
.channels = ad3531r_channels,
+ .regmap_config = &ad3530r_regmap_config,
.num_channels = ARRAY_SIZE(ad3531r_channels),
.sw_ldac_trig_reg = ad3531r_trigger_sw_ldac_reg,
.input_ch_reg = ad3531r_input_ch_reg,
@@ -429,6 +581,38 @@ static const struct ad3530r_chip_info ad3531r_chip = {
.internal_ref_support = true,
};
+static const struct ad3530r_chip_info ad3532_chip = {
+ .name = "ad3532",
+ .channels = ad3532r_channels,
+ .regmap_config = &ad3532r_regmap_config,
+ .num_channels = ARRAY_SIZE(ad3532r_channels),
+ .sw_ldac_trig_reg = ad3532r_trigger_sw_ldac_reg,
+ .input_ch_reg = ad3532r_input_ch_reg,
+ .interface_config_a = ad3532r_if_config,
+ .output_control = ad3532r_out_ctrl,
+ .reference_control = ad3532r_ref_ctrl,
+ .op_mode = ad3532r_op_mode,
+ .num_banks = ARRAY_SIZE(ad3532r_if_config),
+ .num_op_mode_regs = ARRAY_SIZE(ad3532r_op_mode),
+ .internal_ref_support = false,
+};
+
+static const struct ad3530r_chip_info ad3532r_chip = {
+ .name = "ad3532r",
+ .channels = ad3532r_channels,
+ .regmap_config = &ad3532r_regmap_config,
+ .num_channels = ARRAY_SIZE(ad3532r_channels),
+ .sw_ldac_trig_reg = ad3532r_trigger_sw_ldac_reg,
+ .input_ch_reg = ad3532r_input_ch_reg,
+ .interface_config_a = ad3532r_if_config,
+ .output_control = ad3532r_out_ctrl,
+ .reference_control = ad3532r_ref_ctrl,
+ .op_mode = ad3532r_op_mode,
+ .num_banks = ARRAY_SIZE(ad3532r_if_config),
+ .num_op_mode_regs = ARRAY_SIZE(ad3532r_op_mode),
+ .internal_ref_support = true,
+};
+
static int ad3530r_set_reg_bank_bits(const struct ad3530r_state *st,
const unsigned int *regs,
unsigned int num_regs,
@@ -534,12 +718,6 @@ static int ad3530r_setup(struct ad3530r_state *st, int external_vref_uV)
return 0;
}
-static const struct regmap_config ad3530r_regmap_config = {
- .reg_bits = 16,
- .val_bits = 8,
- .max_register = AD3530R_MAX_REG_ADDR,
-};
-
static const struct iio_info ad3530r_info = {
.read_raw = ad3530r_read_raw,
.write_raw = ad3530r_write_raw,
@@ -560,7 +738,11 @@ static int ad3530r_probe(struct spi_device *spi)
st = iio_priv(indio_dev);
- st->regmap = devm_regmap_init_spi(spi, &ad3530r_regmap_config);
+ st->chip_info = spi_get_device_match_data(spi);
+ if (!st->chip_info)
+ return -ENODEV;
+
+ st->regmap = devm_regmap_init_spi(spi, st->chip_info->regmap_config);
if (IS_ERR(st->regmap))
return dev_err_probe(dev, PTR_ERR(st->regmap),
"Failed to init regmap");
@@ -569,10 +751,6 @@ static int ad3530r_probe(struct spi_device *spi)
if (ret)
return ret;
- st->chip_info = spi_get_device_match_data(spi);
- if (!st->chip_info)
- return -ENODEV;
-
ret = devm_regulator_bulk_get_enable(dev, ARRAY_SIZE(regulators),
regulators);
if (ret)
@@ -606,6 +784,8 @@ static const struct spi_device_id ad3530r_id[] = {
{ .name = "ad3530r", .driver_data = (kernel_ulong_t)&ad3530r_chip },
{ .name = "ad3531", .driver_data = (kernel_ulong_t)&ad3531_chip },
{ .name = "ad3531r", .driver_data = (kernel_ulong_t)&ad3531r_chip },
+ { .name = "ad3532", .driver_data = (kernel_ulong_t)&ad3532_chip },
+ { .name = "ad3532r", .driver_data = (kernel_ulong_t)&ad3532r_chip },
{ }
};
MODULE_DEVICE_TABLE(spi, ad3530r_id);
@@ -615,6 +795,8 @@ static const struct of_device_id ad3530r_of_match[] = {
{ .compatible = "adi,ad3530r", .data = &ad3530r_chip },
{ .compatible = "adi,ad3531", .data = &ad3531_chip },
{ .compatible = "adi,ad3531r", .data = &ad3531r_chip },
+ { .compatible = "adi,ad3532", .data = &ad3532_chip },
+ { .compatible = "adi,ad3532r", .data = &ad3532r_chip },
{ }
};
MODULE_DEVICE_TABLE(of, ad3530r_of_match);
--
2.34.1
^ permalink raw reply related
* [PATCH v2 3/4] dt-bindings: iio: dac: add support for AD3532R/AD3532
From: Kim Seer Paller @ 2026-06-15 6:20 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-iio, linux-kernel, linux, devicetree, Kim Seer Paller,
Conor Dooley
In-Reply-To: <20260615-iio-ad3532r-support-v2-0-84a0af8b83fa@analog.com>
The AD3532R/AD3532 is a 16-channel version of the AD3530R/AD3530.
This adds compatible strings for the AD3532R/AD3532.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Kim Seer Paller <kimseer.paller@analog.com>
---
.../devicetree/bindings/iio/dac/adi,ad3530r.yaml | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad3530r.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad3530r.yaml
index a355d52a9d64..2fe098619772 100644
--- a/Documentation/devicetree/bindings/iio/dac/adi,ad3530r.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad3530r.yaml
@@ -10,15 +10,17 @@ maintainers:
- Kim Seer Paller <kimseer.paller@analog.com>
description: |
- The AD3530/AD3530R (8-channel) and AD3531/AD3531R (4-channel) are low-power,
- 16-bit, buffered voltage output digital-to-analog converters (DACs) with
- software-programmable gain controls, providing full-scale output spans of 2.5V
- or 5V for reference voltages of 2.5V. These devices operate from a single 2.7V
- to 5.5V supply and are guaranteed monotonic by design. The "R" variants
- include a 2.5V, 5ppm/°C internal reference, which is disabled by default.
+ The AD3530/AD3530R (8-channel), AD3531/AD3531R (4-channel), and AD3532/AD3532R
+ (16-channel) are low-power, 16-bit, buffered voltage output digital-to-analog
+ converters (DACs) with software-programmable gain controls, providing
+ full-scale output spans of 2.5V or 5V for reference voltages of 2.5V. These
+ devices operate from a single 2.7V to 5.5V supply and are guaranteed monotonic
+ by design. The "R" variants include a 2.5V, 5ppm/°C internal reference, which
+ is disabled by default.
Datasheet can be found here:
https://www.analog.com/media/en/technical-documentation/data-sheets/ad3530_ad530r.pdf
https://www.analog.com/media/en/technical-documentation/data-sheets/ad3531-ad3531r.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad3532r.pdf
properties:
compatible:
@@ -27,6 +29,8 @@ properties:
- adi,ad3530r
- adi,ad3531
- adi,ad3531r
+ - adi,ad3532
+ - adi,ad3532r
reg:
maxItems: 1
--
2.34.1
^ 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