* Re: [PATCH v4 2/7] dt-bindings: display: bridge: Document Renesas R-Car V4H DSC bindings
From: Tomi Valkeinen @ 2026-06-15 6:39 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-renesas-soc, linux-clk, linux-kernel, dri-devel, devicetree,
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, Conor Dooley
In-Reply-To: <20260615-rcar-du-dsc-v4-2-93096a1b56a3@ideasonboard.com>
Hi,
On 15/06/2026 09:28, 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>
> 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";
I missed adding "renesas,rcar-dsc" here.
Tomi
^ permalink raw reply
* Re: [PATCH v5 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Uwe Kleine-König @ 2026-06-15 6:37 UTC (permalink / raw)
To: Julian Braha
Cc: Andrea della Porta, linux-pwm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel, Naushir Patuck,
Stanimir Varbanov, mbrugger
In-Reply-To: <0b6a7f41-b753-48dc-b46e-77aaf0e999f4@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 652 bytes --]
On Sat, Jun 13, 2026 at 01:27:49PM +0100, Julian Braha wrote:
> On 6/12/26 15:01, Andrea della Porta wrote:
>
> > +config PWM_RASPBERRYPI_RP1
> > + tristate "RP1 PWM support"
> > + depends on MISC_RP1 || COMPILE_TEST
> > + depends on HAS_IOMEM
> > + select REGMAP_MMIO
> > + select MFD_SYSCON
> > + help
> > + PWM framework driver for Raspberry Pi RP1 controller.
> > +
>
> Hi Andrea,
>
> Selecting REGMAP_MMIO is unnecessary here since you're already selecting
> MFD_SYSCON.
IMHO selecting REGMAP_MMIO explicitly here is fine because at least to
me it's not obvious that MFD_SYSCON enforces REGMAP_MMIO.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/2] cpufreq: spacemit: Add K1 cpufreq driver
From: Viresh Kumar @ 2026-06-15 6:34 UTC (permalink / raw)
To: Shuwei Wu
Cc: Rafael J. Wysocki, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Yixun Lan, linux-pm, linux-kernel, linux-riscv, spacemit,
devicetree
In-Reply-To: <DJ9EFPG561VZ.1WGRYYHJ2W9J9@mailbox.org>
Hi Shuwei,
On 15-06-26, 14:12, Shuwei Wu wrote:
> The clusters have separate clocks, but they share the same voltage supply.[1]
> So two independent policies would be unsafe: one policy could lower the shared
> voltage while the other cluster is still running at a higher frequency.
No, both will vote for the regulator contraints using CPU device and the
regulator core will make sure it doesn't break any of them. This is what all
frameworks do, regulator, clk, etc.
> This means they can't use different policies.
This is incorrect.
> From a hardware perspective, the eight cores of the K1 are homogeneous,
> so using the same policy for them is relatively reasonable.
Right, but this is inefficient. One cluster can be idle, or in low freq mode
while other can be in higher. They MUST be two policies.
> I used a K1-specific driver because cpufreq-dt only manages one CPU clock
> through the CPU device used for the OPP transition.
> On K1, the policy needs to control two independent cluster clocks and one shared
> regulator, so the driver has to update the second cluster clock explicitly and
> keep the ordering safe: raise voltage before raising either cluster, and lower
> both cluster clocks before lowering the shared voltage.
>
> [1] https://lore.kernel.org/spacemit/aeaXszeaE62rM6BJ@aurel32.net/
--
viresh
^ permalink raw reply
* Re: [PATCH] dt-bindings: pwm: st,pwm: convert to DT schema
From: Uwe Kleine-König @ 2026-06-15 6:34 UTC (permalink / raw)
To: Charan Pedumuru
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Pal Singh,
linux-pwm, devicetree, linux-kernel
In-Reply-To: <20260613-st-pwm-v1-1-458c2c89709a@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 598 bytes --]
Hello,
On Sat, Jun 13, 2026 at 07:04:11AM +0000, Charan Pedumuru wrote:
> Convert STMicroelectronics STiH41x PWM/Capture controller binding
> to DT schema.
>
> Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
FTR: sashiko found a relevant issue in this patch, sent a mail about it,
but not to the list. It's about the old binding requiring `interrupts`
which isn't the case in the new proposed one.
Find the full message at
https://sashiko.dev/#/message/20260613071327.BE3101F000E9%40smtp.kernel.org.
So I marked this patch as changes requested.
Best reagrds
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* 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
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