* Re: [PATCH v4 1/4] regulator: dt-bindings: Add Unisoc SC2730 PMIC
From: Krzysztof Kozlowski @ 2026-05-22 6:14 UTC (permalink / raw)
To: Otto Pflüger
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Orson Zhai, Baolin Wang, Chunyan Zhang, Lee Jones,
linux-kernel, devicetree
In-Reply-To: <20260521-sc2730-regulators-v4-1-1ac8a3b5ed82@abscue.de>
On Thu, May 21, 2026 at 06:17:06PM +0200, Otto Pflüger wrote:
> Add bindings for the regulators found in the Spreadtrum/Unisoc SC2730
> PMIC, used e.g. with the UMS512 and UMS9230 SoCs.
>
> Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
> ---
> .../bindings/regulator/sprd,sc2730-regulator.yaml | 44 ++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 02/10] dt-bindings: clock: Add Amlogic A9 PLL clock controller
From: Jian Hu @ 2026-05-22 6:20 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Jerome Brunet, Xianwei Zhao,
Kevin Hilman, Martin Blumenstingl, linux-kernel, linux-clk,
devicetree, linux-amlogic, linux-arm-kernel
In-Reply-To: <20260515-subtle-sepia-tuatara-cfee3d@quoll>
Hi Krzysztof,
Thanks for your review.
On 5/15/2026 4:09 PM, Krzysztof Kozlowski wrote:
> [ EXTERNAL EMAIL ]
>
> On Mon, May 11, 2026 at 08:47:24PM +0800, Jian Hu wrote:
>> Add the PLL clock controller dt-bindings for the Amlogic A9 SoC family.
>>
>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>> ---
>> .../bindings/clock/amlogic,a9-pll-clkc.yaml | 110 +++++++++++++++++++++
>> include/dt-bindings/clock/amlogic,a9-pll-clkc.h | 55 +++++++++++
>> 2 files changed, 165 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/amlogic,a9-pll-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,a9-pll-clkc.yaml
>> new file mode 100644
>> index 000000000000..4ee6013ba1a1
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/amlogic,a9-pll-clkc.yaml
>> @@ -0,0 +1,110 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +# Copyright (C) 2026 Amlogic, Inc. All rights reserved
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/clock/amlogic,a9-pll-clkc.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Amlogic A9 Series PLL Clock Controller
>> +
>> +maintainers:
>> + - Neil Armstrong <neil.armstrong@linaro.org>
>> + - Jerome Brunet <jbrunet@baylibre.com>
>> + - Jian Hu <jian.hu@amlogic.com>
>> + - Xianwei Zhao <xianwei.zhao@amlogic.com>
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - amlogic,a9-gp0-pll
>> + - amlogic,a9-hifi0-pll
>> + - amlogic,a9-hifi1-pll
>> + - amlogic,a9-mclk0-pll
>> + - amlogic,a9-mclk1-pll
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + '#clock-cells':
>> + const: 1
>> +
>> + clocks:
>> + items:
>> + - description: pll input oscillator gate
>> + - description: fixed input clock source for mclk_sel_0
>> + - description: u3p2pll input clock source for mclk_sel_0 (optional)
> Second clock is also optional. Drop "(optional)" comment, just
> confusing.
GP0 has only one parent clock, while MCLK has three.
The second and third parent entries of GP0 are vacant,
so they need to be marked optional.
I will add the optional property for the second clock in the next revision.
>> + minItems: 1
>> +
>> + clock-names:
>> + items:
>> + - const: in0
>> + - const: in1
>> + - const: in2
> Pretty pointless names, drop property.
Ok, I will drop them.
clock-names:
- items:
- - const: in0
- - const: in1
- - const: in2
minItems: 1
>> + minItems: 1
>> +
>> +required:
>> + - compatible
>> + - '#clock-cells'
>> + - reg
>> + - clocks
>> + - clock-names
>> +
>> +allOf:
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + enum:
>> + - amlogic,a9-mclk0-pll
>> + - amlogic,a9-mclk1-pll
>> +
>> + then:
>> + properties:
>> + clocks:
>> + maxItems: 3
> No, minItems instead. maxItems is already 3, so what is the point of
> redefining it?
Ok, I will use minItems instead.
>> +
>> + clock-names:
>> + maxItems: 3
>> +
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + enum:
>> + - amlogic,a9-gp0-pll
>> + - amlogic,a9-hifi0-pll
>> + - amlogic,a9-hifi1-pll
>> +
>> + then:
>> + properties:
>> + clocks:
>> + maxItems: 1
>> +
>> + clock-names:
>> + maxItems: 1
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + apb4 {
> soc
Ok, I will rename it to soc.
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + clock-controller@8200 {
>> + compatible = "amlogic,a9-gp0-pll";
>> + reg = <0x0 0x8200 0x0 0x20>;
>> + #clock-cells = <1>;
>> + clocks = <&scmi_clk 0>;
>> + clock-names = "in0";
>> + };
>> +
>> + clock-controller@8330 {
>> + compatible = "amlogic,a9-mclk0-pll";
>> + reg = <0x0 0x8330 0x0 0x14>;
>> + #clock-cells = <1>;
>> + clocks = <&scmi_clk 4>,
>> + <&scmi_clk 8>;
>> + clock-names = "in0", "in1";
> One example is enough, you have exactly the same properties.
Ok, I will drop the second clock node.
>
> Best regards,
> Krzysztof
>
Best regards,
Jian
^ permalink raw reply
* Re: [PATCH v14 4/6] pinctrl: add NXP MC33978/MC34978 pinctrl driver
From: sashiko-bot @ 2026-05-22 6:22 UTC (permalink / raw)
To: Oleksij Rempel; +Cc: linux-hwmon, robh, devicetree, conor+dt
In-Reply-To: <20260522044855.1772639-5-o.rempel@pengutronix.de>
> From: David Jander <david@protonic.nl>
>
> Add pin control and GPIO driver for the NXP MC33978/MC34978 Multiple
> Switch Detection Interface (MSDI) devices.
>
> This driver exposes the 22 mechanical switch detection inputs (14
> Switch-to-Ground, 8 Programmable) as standard GPIOs.
>
> Key features implemented:
> - GPIO read/write: Translates physical switch states (open/closed)
> to logical GPIO levels based on the configured switch topology
> (Switch-to-Ground vs. Switch-to-Battery).
> - Emulated Output: Allows setting pins "high" or "low" by manipulating
> the tri-state registers and hardware pull topologies.
> - Interrupt routing: Proxies GPIO interrupt requests to the irq_domain
> managed by the parent MFD core driver via a hierarchical irq_chip.
>
> Signed-off-by: David Jander <david@protonic.nl>
> Co-developed-by: Oleksij Rempel <o.rempel@pengutronix.de>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260522044855.1772639-1-o.rempel@pengutronix.de?part=4
^ permalink raw reply
* RE: [PATCH v4 4/5] drm: renesas: rz-du: Move mode_valid logic to per-SoC clock limits
From: Biju Das @ 2026-05-22 6:27 UTC (permalink / raw)
To: Lad, Prabhakar
Cc: Laurent Pinchart, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel,
Geert Uytterhoeven, magnus.damm, dri-devel@lists.freedesktop.org,
linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Fabrizio Castro,
Prabhakar Mahadev Lad
In-Reply-To: <TY3PR01MB11346028C0876AA344758AABA86012@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Hi,
> -----Original Message-----
> From: Biju Das
> Sent: 20 May 2026 09:16
> Subject: RE: [PATCH v4 4/5] drm: renesas: rz-du: Move mode_valid logic to per-SoC clock limits
>
> Hi Prabhakar,
>
> > -----Original Message-----
> > From: Lad, Prabhakar <prabhakar.csengg@gmail.com>
> > Sent: 20 May 2026 09:14
> > Subject: Re: [PATCH v4 4/5] drm: renesas: rz-du: Move mode_valid logic
> > to per-SoC clock limits
> >
> > Hi Biju,
> >
> > Thank you for the review.
> >
> > On Wed, May 20, 2026 at 6:36 AM Biju Das <biju.das.jz@bp.renesas.com> wrote:
> > >
> > > Hi Prabhakar,
> > >
> > > Thanks for the patch.
> > >
> > > > -----Original Message-----
> > > > From: Prabhakar <prabhakar.csengg@gmail.com>
> > > > Sent: 19 May 2026 17:08
> > > > Subject: [PATCH v4 4/5] drm: renesas: rz-du: Move mode_valid logic
> > > > to per-SoC clock limits
> > > >
> > > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > > >
> > > > Move pixel clock validation from a fixed encoder check to per SoC
> > > > constraints stored in rzg2l_du_device_info.
> > > >
> > > > Pixel clock limits differ across SoCs in the RZ DU family and
> > > > cannot be expressed by a single shared rule. For example, RZ/G2UL
> > > > and RZ/G2L limit the DPAD0 pixel clock to a narrow window, while
> > > > other SoCs such as RZ/T2H require a
> > wider operating range.
> > > >
> > > > Add mode_clock_min and mode_clock_max fields to
> > > > rzg2l_du_device_info to describe the supported pixel clock range
> > > > for each SoC. Update
> > > > rzg2l_du_encoder_mode_valid() to check these bounds when
> > > > evaluating
> > > > DPAD0 outputs, returning MODE_CLOCK_LOW when the pixel clock falls
> > > > below mode_clock_min and MODE_CLOCK_HIGH when it exceeds mode_clock_max.
> > > >
> > > > Populate the pixel clock limits for both the RZ/G2UL (R9A07G043U)
> > > > and RZ/G2L (R9A07G044) variants to a minimum of 20875 kHz and a
> > > > maximum of
> > > > 83500 kHz.
> > > >
> > > > Signed-off-by: Lad Prabhakar
> > > > <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > > > ---
> > > > v3->v4:
> > > > - Dropped per pad limits
> > > > - Updated commit message to reflect the change in approach.
> > > >
> > > > v2->v3:
> > > > - Moved clock limits from device_info to output_routing to allow
> > > > per-output constraints.
> > > > - Updated commit message to reflect the change in approach.
> > > >
> > > > v1->v2:
> > > > - Dropped storing info pointer in struct rzg2l_du_encoder as it's not needed.
> > > > ---
> > > > drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c | 6 +++++-
> > > > drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h | 4 ++++
> > > > drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.c | 9 ++++++++-
> > > > 3 files changed, 17 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
> > > > b/drivers/gpu/drm/renesas/rz- du/rzg2l_du_drv.c index
> > > > 0fef33a5a089..1e4b9f38c55b 100644
> > > > --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
> > > > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
> > > > @@ -35,6 +35,8 @@ static const struct rzg2l_du_device_info rzg2l_du_r9a07g043u_info = {
> > > > .port = 0,
> > > > },
> > > > },
> > > > + .mode_clock_min = 20875,
> > > > + .mode_clock_max = 83500,
> > > > };
> > > >
> > > > static const struct rzg2l_du_device_info rzg2l_du_r9a07g044_info
> > > > = { @@ -48,7 +50,9 @@ static const struct rzg2l_du_device_info rzg2l_du_r9a07g044_info = {
> > > > .possible_outputs = BIT(0),
> > > > .port = 1,
> > > > }
> > > > - }
> > > > + },
> > > > + .mode_clock_min = 20875,
> > > > + .mode_clock_max = 83500,
> > > > };
> > > >
> > > > static const struct rzg2l_du_device_info rzg2l_du_r9a09g057_info
> > > > = { diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
> > > > b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
> > > > index 58806c2a8f2b..885558eb9547 100644
> > > > --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
> > > > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
> > > > @@ -44,10 +44,14 @@ struct rzg2l_du_output_routing {
> > > > * struct rzg2l_du_device_info - DU model-specific information
> > > > * @channels_mask: bit mask of available DU channels
> > > > * @routes: array of CRTC to output routes, indexed by output
> > > > (RZG2L_DU_OUTPUT_*)
> > > > + * @mode_clock_min: minimum pixel clock in kHz
> > > > + * @mode_clock_max: maximum pixel clock in kHz
> > > > */
> > > > struct rzg2l_du_device_info {
> > > > unsigned int channels_mask;
> > > > struct rzg2l_du_output_routing routes[RZG2L_DU_OUTPUT_MAX];
> > > > + u32 mode_clock_min;
> > > > + u32 mode_clock_max;
> > > > };
> > > >
> > > > #define RZG2L_DU_MAX_CRTCS 1
> > > > diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.c
> > > > b/drivers/gpu/drm/renesas/rz- du/rzg2l_du_encoder.c index
> > > > 0e567b57a408..56220139a149 100644
> > > > --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.c
> > > > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.c
> > > > @@ -50,8 +50,15 @@ rzg2l_du_encoder_mode_valid(struct drm_encoder *encoder,
> > > > const struct drm_display_mode *mode) {
> > > > struct rzg2l_du_encoder *renc = to_rzg2l_encoder(encoder);
> > > > + struct rzg2l_du_device *rcdu = to_rzg2l_du_device(renc->base.dev);
> > > > + const struct rzg2l_du_device_info *info = rcdu->info;
> > > >
> > > > - if (renc->output == RZG2L_DU_OUTPUT_DPAD0 && mode->clock > 83500)
> > > > + if (renc->output != RZG2L_DU_OUTPUT_DPAD0)
> > > > + return MODE_OK;
> > > > +
> > > > + if (info->mode_clock_min && mode->clock <
> > > > + info->mode_clock_min)
> > >
> > > I will avoid checking the first part as it is mandatory for SoCs
> > > with DPI support and DPI check above make sure that this part of the
> > > code is reachable only for DPI output.
> > >
> > Will you fix up while applying or shall I send a new version?
>
> I can take care of this if there are no other comments.
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Cheers,
Biju
>
> Cheers,
> Biju
>
> >
> > Cheers,
> > Prabhakar
> > > > + return MODE_CLOCK_LOW;
> > > > + if (info->mode_clock_max && mode->clock >
> > > > + info->mode_clock_max)
> > >
> > > Same here.
> > >
> > > Cheers,
> > > Biju
> > >
> > > > return MODE_CLOCK_HIGH;
> > > >
> > > > return MODE_OK;
> > > > --
> > > > 2.54.0
> > >
^ permalink raw reply
* Re: [PATCH v4 2/4] dt-bindings: mfd: sprd,sc2731: Include SC2730 regulator bindings
From: Krzysztof Kozlowski @ 2026-05-22 6:28 UTC (permalink / raw)
To: Otto Pflüger
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Orson Zhai, Baolin Wang, Chunyan Zhang, Lee Jones,
linux-kernel, devicetree
In-Reply-To: <20260521-sc2730-regulators-v4-2-1ac8a3b5ed82@abscue.de>
On Thu, May 21, 2026 at 06:17:07PM +0200, Otto Pflüger wrote:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: sprd,sc2731
And what about every other variant?
> + then:
> + properties:
> + regulators:
> + $ref: /schemas/regulator/sprd,sc2731-regulator.yaml#
> +
> examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
>
> --
> 2.51.0
>
^ permalink raw reply
* Re: [PATCH v1 5/9] arm64: dts: agilex5: add SOCDK eMMC daughter board support
From: Kathpalia, Tanmay @ 2026-05-22 6:30 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-mmc, ulf.hansson, Dinh Nguyen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree, linux-kernel
In-Reply-To: <20260515-grinning-inescapable-butterfly-eba39d@quoll>
[Re-sending in plain text due to HTML rejection by the mailing list.]
Hi Krzyztof,
Thanks for your feedback.
On 5/15/2026 2:07 PM, Krzysztof Kozlowski wrote:
> On Mon, May 11, 2026 at 01:21:27PM -0700, Tanmay Kathpalia wrote:
>> Add device tree support for the Agilex5 SOCDK board variant with
>> eMMC daughter card.
>>
>> Update the SoC dtsi with a fixed 1.8V regulator for eMMC I/O voltage.
>>
>> Add socfpga_agilex5_socdk_emmc.dts with eMMC controller configured for:
>> - 8-bit bus width
>> - Non-removable eMMC device
>> - High-speed, HS200, and HS400 modes at 1.8V
>> - 200MHz maximum frequency with SDHCI clock base capability override
>>
>> Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
>> ---
>> arch/arm64/boot/dts/intel/Makefile | 1 +
>> .../arm64/boot/dts/intel/socfpga_agilex5.dtsi | 8 ++
>> .../dts/intel/socfpga_agilex5_socdk_emmc.dts | 111 ++++++++++++++++++
>> 3 files changed, 120 insertions(+)
>> create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_emmc.dts
>>
>> diff --git a/arch/arm64/boot/dts/intel/Makefile b/arch/arm64/boot/dts/intel/Makefile
>> index 33fcc55d0cb9..5bbbcfda1f48 100644
>> --- a/arch/arm64/boot/dts/intel/Makefile
>> +++ b/arch/arm64/boot/dts/intel/Makefile
>> @@ -8,5 +8,6 @@ dtb-$(CONFIG_ARCH_INTEL_SOCFPGA) += socfpga_agilex_n6000.dtb \
>> socfpga_agilex5_socdk_013b.dtb \
>> socfpga_agilex5_socdk_modular.dtb \
>> socfpga_agilex5_socdk_nand.dtb \
>> + socfpga_agilex5_socdk_emmc.dtb \
>> socfpga_n5x_socdk.dtb
>> dtb-$(CONFIG_ARCH_KEEMBAY) += keembay-evm.dtb
>> diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
>> index 7e080f13166f..feb4ccb317a7 100644
>> --- a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
>> +++ b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
>> @@ -317,6 +317,14 @@ sd_io_1v8_reg: regulator-1p8v {
>> <3300000 0x0>;
>> };
>>
>> + emmc_io_1v8_reg: regulator-fixed-1p8v {
> How is this property of a SoC? How SoC itself has a fixed regulator for
> EMMC? Really?
>
> Best regards,
> Krzysztof
Apologies, you are absolutely right.
The emmc_io_1v8_reg regulator is a fixed 1.8v rail on the eMMC
daughter card, not a property of the SoC silicon.
In v2 this will be fixed:
emmc_io_1v8_reg will be moved to the root level of
socfpga_agilex5_socdk_emmc.dts where it correctly describes
board-level hardware.
Regards,
Tanmay
^ permalink raw reply
* Re: [PATCH v18 1/3] dt-bindings: pwm: opencores: Drop starfive compatibles and update maintainers
From: Hal Feng @ 2026-05-22 6:31 UTC (permalink / raw)
To: Conor Dooley
Cc: Uwe Kleine-König, Philipp Zabel, Rob Herring,
Krzysztof Kozlowski, Emil Renner Berthing, Palmer Dabbelt,
Paul Walmsley, Albert Ou, Changhuang Liang,
linux-pwm@vger.kernel.org, devicetree@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260515-blinked-gigabyte-d2882372b616@spud>
> On 25.05.15 21:06, Conor Dooley wrote:
> On Fri, May 15, 2026 at 01:47:20PM +0800, Hal Feng wrote:
> > Each of the StarFive JH7100/JH7110/JH8100 SoCs has 8 OpenCores PTC IP
> > cores. One OpenCores PTC IP core can output one PWM channel. The only
> > difference among them is the register base address. There is no need
> > to add starfive compatibles to distinguish them.
>
> NAK, that's not an acceptable reason to remove soc-specific compatibles.
Got it, because it will break Device Tree ABI.
Best regards,
Hal
>
> pw-bot: changes-requested
>
> >
> > I will maintain the pwm module in place of William.
> >
> > Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
> > ---
> > .../devicetree/bindings/pwm/opencores,pwm.yaml | 10 +++-------
> > 1 file changed, 3 insertions(+), 7 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/pwm/opencores,pwm.yaml
> > b/Documentation/devicetree/bindings/pwm/opencores,pwm.yaml
> > index 52a59d245cdb..834fb17ec595 100644
> > --- a/Documentation/devicetree/bindings/pwm/opencores,pwm.yaml
> > +++ b/Documentation/devicetree/bindings/pwm/opencores,pwm.yaml
> > @@ -7,7 +7,7 @@ $schema:
> http://devicetree.org/meta-schemas/core.yaml#
> > title: OpenCores PWM controller
> >
> > maintainers:
> > - - William Qiu <william.qiu@starfivetech.com>
> > + - Hal Feng <hal.feng@starfivetech.com>
> >
> > description:
> > The OpenCores PTC ip core contains a PWM controller. When operating
> > in PWM @@ -20,10 +20,6 @@ allOf:
> > properties:
> > compatible:
> > items:
> > - - enum:
> > - - starfive,jh7100-pwm
> > - - starfive,jh7110-pwm
> > - - starfive,jh8100-pwm
> > - const: opencores,pwm-v1
> >
> > reg:
> > @@ -48,8 +44,8 @@ additionalProperties: false
> > examples:
> > - |
> > pwm@12490000 {
> > - compatible = "starfive,jh7110-pwm", "opencores,pwm-v1";
> > - reg = <0x12490000 0x10000>;
> > + compatible = "opencores,pwm-v1";
> > + reg = <0x12490000 0x10>;
> > clocks = <&clkgen 181>;
> > resets = <&rstgen 109>;
> > #pwm-cells = <3>;
> > --
> > 2.43.2
> >
^ permalink raw reply
* Re: [PATCH v4 4/5] dt-bindings: display: Add Synaptics R63455 panel support
From: Neil Armstrong @ 2026-05-22 6:32 UTC (permalink / raw)
To: Dmitry Baryshkov, Jun Nie
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, dri-devel,
freedreno, linux-kernel, devicetree
In-Reply-To: <2w6cpuzwxht2dv7a3xj57ukuzqa2b77ba2syl2ewdmq5bprczb@g3rm2k7e4l4h>
On 5/21/26 22:24, Dmitry Baryshkov wrote:
> On Thu, May 21, 2026 at 10:46:06PM +0800, Jun Nie wrote:
>> Add support for the dual-panel system found in the virtual reality device.
>> This system consists of two physical 2160x2160 panels, each connected via
>> a MIPI DSI interface. The backlight is managed through DSI link.
>>
>> Signed-off-by: Jun Nie <jun.nie@linaro.org>
>> ---
>> .../bindings/display/panel/synaptics,r63455.yaml | 125 +++++++++++++++++++++
>> 1 file changed, 125 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/display/panel/synaptics,r63455.yaml b/Documentation/devicetree/bindings/display/panel/synaptics,r63455.yaml
>> new file mode 100644
>> index 0000000000000..a94b355ed9557
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/panel/synaptics,r63455.yaml
>> @@ -0,0 +1,125 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/display/panel/synaptics,r63455.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Synaptics R63455 based dual 2160x2160 MIPI-DSI Panel
>> +
>> +maintainers:
>> + - Jun Nie <jun.nie@linaro.org>
>> +
>> +description:
>> + Synaptics R63455 is a Virtual Reality Display Driver and VR Bridge, used in
>> + pair in Headset devices. The Virtual Reality Display complex is composed of
>> + two strictly identical display panels, each driven by its own DSI interface
>> + but forms a single virtual display for the human eye perception and thus
>> + requires a strict synchronization of the two display panel content update.
>> +
>> +allOf:
>> + - $ref: panel-common.yaml#
>> +
>> +properties:
>> + compatible:
>> + items:
>> + - enum:
>> + - sharp,ls026b3sa06
>> + - boe,vs026c4m-n52-6000
>> + - const: synaptics,r63455
>> +
>> + reset-gpios:
>> + maxItems: 2
>> + description: 2 reset pins for 2 physical panels
>> +
>> + left-pos-supply:
>> + description: Positive 5.7V supply for left panel
>
> So, is the R63455 driving both panels or are there two panels, each
> having R63455 controller? What if somebody gets a single Sharp panel and
> wants to use it in their device? How will it match these bindings?
It's highly improbable, those are very specialized panels that are designed
for xr usage in pair. Yes a hobbyist could try to use a single panel
but it's only usable when placed close to an eye, and barely useless if you
don't have both eyes.
Let's skip highly improbable use-cases and focus on the main use case of the
hardware device.
>
>> +
>> + right-pos-supply:
>> + description: Positive 5.7V supply for right panel
>> +
>> + left-neg-supply:
>> + description: Negative 5.7V supply for left panel
>> +
>> + right-neg-supply:
>> + description: Negative 5.7V supply for right panel
>> +
>> + left-backlight-supply:
>> + description: Backlight 21V supply for left panel
>> +
>> + right-backlight-supply:
>> + description: Backlight 21V supply for right panel
>> +
>> + vdda-supply:
>> + description: core 1.8V supply for panels
>> +
>> + ports: $ref: /schemas/graph.yaml#/properties/ports
>> +
>> +required:
>> + - compatible
>> + - reset-gpios
>> + - left-pos-supply
>> + - left-neg-supply
>> + - right-pos-supply
>> + - right-neg-supply
>> + - left-backlight-supply
>> + - right-backlight-supply
>> + - vdda-supply
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/gpio/gpio.h>
>> +
>> + &mdss_dsi0 {
>
> Please drop the MDSS specifics, there should be one (or two) DSI busses,
> driving your panels. The rests are details which are not necessary for
> the example.
>
>> + vdda-supply = <&vreg_l3i_1p2>;
>> + status = "okay";
>> +
>> + qcom,dual-dsi-mode;
>> + qcom,master-dsi;
>> +
>> + panel: panel@0 {
>> + compatible = "sharp,ls026b3sa06", "synaptics,r63455";
>> + reg = <0>;
>> +
>> + reset-gpios = <&pm8550_gpios 3 GPIO_ACTIVE_HIGH>,
>> + <&pm8550_gpios 11 GPIO_ACTIVE_HIGH>;
>> +
>> + left-pos-supply = <&vpos_left>;
>> + left-neg-supply = <&vneg_left>;
>> + right-pos-supply = <&vpos_right>;
>> + right-neg-supply = <&vneg_right>;
>> + left-backlight-supply = <&backlight_left>;
>> + right-backlight-supply = <&backlight_right>;
>> +
>> + vdda-supply = <&vreg_l12b_1p8>;
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + port@0 {
>> + reg = <0>;
>> + panel0_in: endpoint {
>> + remote-endpoint = <&mdss_dsi0_out>;
>
> What is mdss_dsi0_out?
>
>> + };
>> + };
>> +
>> + port@1 {
>> + reg = <1>;
>> + panel1_in: endpoint {
>> + remote-endpoint = <&mdss_dsi1_out>;
>> + };
>> + };
>> + };
>> + };
>> +
>> + &mdss_dsi0_out {
>> + remote-endpoint = <&panel0_in>;
>> + data-lanes = <0 1 2>;
>> + };
>> +
>> + &mdss_dsi1_out {
>> + remote-endpoint = <&panel1_in>;
>> + data-lanes = <0 1 2>;
>> + };
>> +...
>>
>> --
>> 2.43.0
>>
>
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: remoteproc: qcom,shikra-pas: Document Shikra PAS remoteprocs
From: Krzysztof Kozlowski @ 2026-05-22 6:32 UTC (permalink / raw)
To: Komal Bajaj
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm,
linux-remoteproc, devicetree, linux-kernel, Bibek Kumar Patro
In-Reply-To: <20260521-shikra-rproc-v3-1-2fca0bbe1ad7@oss.qualcomm.com>
On Thu, May 21, 2026 at 06:51:37PM +0530, Komal Bajaj wrote:
> Document the bindings for the CDSP, LPAICP and MPSS PAS on
> the Shikra SoC.
>
> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
> ---
> .../bindings/remoteproc/qcom,shikra-pas.yaml | 167 +++++++++++++++++++++
> 1 file changed, 167 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 2/4] dt-bindings: mfd: sprd,sc2731: Include SC2730 regulator bindings
From: Otto Pflüger @ 2026-05-22 6:32 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Orson Zhai, Baolin Wang, Chunyan Zhang, Lee Jones,
linux-kernel, devicetree
In-Reply-To: <20260522-sweet-magic-kelpie-d6daec@quoll>
On Fri, May 22, 2026 at 08:28:59AM +0200, Krzysztof Kozlowski wrote:
> On Thu, May 21, 2026 at 06:17:07PM +0200, Otto Pflüger wrote:
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: sprd,sc2731
>
> And what about every other variant?
For sc2720, sc2721 and sc2723, the regulators should also be different,
but I'm not able to test anything with those PMICs. The original binding
was wrong.
>
> > + then:
> > + properties:
> > + regulators:
> > + $ref: /schemas/regulator/sprd,sc2731-regulator.yaml#
> > +
> > examples:
> > - |
> > #include <dt-bindings/gpio/gpio.h>
> >
> > --
> > 2.51.0
> >
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: cpufreq: qcom-hw: Document Shikra CPUFREQ Hardware
From: Krzysztof Kozlowski @ 2026-05-22 6:34 UTC (permalink / raw)
To: Imran Shaik
Cc: Rafael J. Wysocki, Viresh Kumar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Manivannan Sadhasivam, Ajit Pandey, Taniya Das,
Jagadeesh Kona, linux-pm, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20260521-shikra-cpufreq-scaling-v3-1-883c13d1e514@oss.qualcomm.com>
On Thu, May 21, 2026 at 07:36:04PM +0530, Imran Shaik wrote:
> The Qualcomm Shikra cpufreq hardware is functionally identical to EPSS,
> but supports only up to 12 frequency lookup table (LUT) entries. Introduce
> Shikra specific bindings to represent this constrained EPSS variant.
>
> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
> ---
> .../bindings/cpufreq/qcom,shikra-epss.yaml | 96 ++++++++++++++++++++++
> 1 file changed, 96 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/cpufreq/qcom,shikra-epss.yaml b/Documentation/devicetree/bindings/cpufreq/qcom,shikra-epss.yaml
> new file mode 100644
> index 0000000000000000000000000000000000000000..8543fd00d82acdbb3422bde462417118aa4c49d1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/qcom,shikra-epss.yaml
> @@ -0,0 +1,96 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/cpufreq/qcom,shikra-epss.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: CPUFREQ HW for Qualcomm Shikra SoC
Qualcomm Shikra SoC EPSS
> +
> +maintainers:
> + - Imran Shaik <imran.shaik@oss.qualcomm.com>
> + - Taniya Das <taniya.das@oss.qualcomm.com>
> +
> +description: |
> + CPUFREQ HW is a hardware engine used by some Qualcomm SoCs to manage
EPSS is a ....
> + frequency in hardware. It is capable of controlling frequency for
> + multiple clusters.
> +
> + The Qualcomm Shikra CPUFREQ HW supports up to 12 frequency lookup table
here as well, like I mentioned last time. cpufreq is linuxism and I
asked you about name of actual device.
With above:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 01/10] dt-bindings: display: rockchip: analogix-dp: Fix hclk as third clock for RK3588
From: Damon Ding @ 2026-05-22 6:29 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss, Laurent.pinchart, jonas, jernej.skrabec,
nicolas.frattaroli, cristian.ciocaltea, sebastian.reichel,
dmitry.baryshkov, luca.ceresoli, dianders, m.szyprowski,
dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260522-demonic-shaggy-wasp-a3f261@quoll>
Hi Krzysztof,
On 5/22/2026 2:11 PM, Krzysztof Kozlowski wrote:
> On Thu, May 21, 2026 at 04:08:26PM +0800, Damon Ding wrote:
>> RK3588 eDP controller requires HCLK_VO1 to access the VO1 GRF
>> registers and enable the video datapath.
>>
>> Previously, the clock was enabled implicitly via the 'rockchip,vo-grf'
>> phandle reference, which allowed the eDP to work without explicitly
>> managing the hclk_vo1 clock. However, this is not safe or explicit.
>>
>> To make the clock dependency explicit, enforce per-SoC clock-names
>> requirements:
>> - RK3288: 2 clocks (dp, pclk)
>> - RK3399: 3 clocks (dp, pclk, grf)
>> - RK3588: 3 clocks (dp, pclk, hclk)
>>
>> Do not reuse the 'grf' clock name for RK3588 because it represents
>> a different clock with distinct control logic:
>> - The 'grf' clock is only for GRF register access and is toggled
>> dynamically during register access.
>> - The 'hclk' clock controls both GRF access and video datapath
>> gating, and must remain enabled during probe.
>>
>> Fixes: f855146263b1 ("dt-bindings: display: rockchip: analogix-dp: Add support for RK3588")
>> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
>>
>> ---
>>
>> Changes in v4:
>> - Modify the commit msg.
>>
>> Changes in v5:
>> - Enforce the correct third clock name on a per-compatible basis.
>> - Modify the commit msg simultaneously.
>>
>> Changes in v6:
>> - Expand more detail commit msg about using hclk instead of grf clock.
>> ---
>> .../rockchip/rockchip,analogix-dp.yaml | 37 +++++++++++++++++--
>> 1 file changed, 33 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
>> index d99b23b88cc5..8001c1facf98 100644
>> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
>> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
>> @@ -23,10 +23,7 @@ properties:
>>
>> clock-names:
>> minItems: 2
>> - items:
>> - - const: dp
>> - - const: pclk
>> - - const: grf
>> + maxItems: 3
>>
>> power-domains:
>> maxItems: 1
>> @@ -60,6 +57,33 @@ required:
>> allOf:
>> - $ref: /schemas/display/bridge/analogix,dp.yaml#
>>
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + enum:
>> + - rockchip,rk3288-dp
>> + then:
>> + properties:
>> + clock-names:
>> + items:
>> + - const: dp
>> + - const: pclk
>
> Why aren't there constraints for clocks? They always must come together.
>
> Please open any other binding and look how it is done there.
>
>
Yes, as Conor's suggestion, the right way is to keep all valid clock
names at the top level, and use only minItems/maxItems in allOf to
differentiate clocks and clock-names of platforms.
I will update this in next version.
Best regards,
Damon
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: cpufreq: qcom-hw: Document Shikra CPUFREQ Hardware
From: Krzysztof Kozlowski @ 2026-05-22 6:35 UTC (permalink / raw)
To: Imran Shaik
Cc: Rafael J. Wysocki, Viresh Kumar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Manivannan Sadhasivam, Ajit Pandey, Taniya Das,
Jagadeesh Kona, linux-pm, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20260521-shikra-cpufreq-scaling-v3-1-883c13d1e514@oss.qualcomm.com>
On Thu, May 21, 2026 at 07:36:04PM +0530, Imran Shaik wrote:
> The Qualcomm Shikra cpufreq hardware is functionally identical to EPSS,
> but supports only up to 12 frequency lookup table (LUT) entries. Introduce
> Shikra specific bindings to represent this constrained EPSS variant.
>
> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
> ---
> .../bindings/cpufreq/qcom,shikra-epss.yaml | 96 ++++++++++++++++++++++
> 1 file changed, 96 insertions(+)
Please use subject prefixes matching the subsystem. You can get them for
example with 'git log --oneline -- DIRECTORY_OR_FILE' on the directory
your patch is touching. For bindings, the preferred subjects are
explained here:
https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters
There is no "qcom-hw" schema, so no clue from where did you get this
one.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: clock: via,vt8500: Convert to DT Schema
From: Krzysztof Kozlowski @ 2026-05-22 6:42 UTC (permalink / raw)
To: Udaya Kiran Challa
Cc: mturquette, sboyd, robh, krzk+dt, conor+dt, skhan, me, linux-rtc,
devicetree, linux-kernel
In-Reply-To: <20260521170810.19702-1-challauday369@gmail.com>
On Thu, May 21, 2026 at 10:37:28PM +0530, Udaya Kiran Challa wrote:
> Convert the VIA/Wondermedia VT8500 and Wondermedia WM8xxx series SoCs clock
> controller binding from the legacy text format to DT schema.
>
> Signed-off-by: Udaya Kiran Challa <challauday369@gmail.com>
> ---
> Changelog:
> Changes since v1:
> - Add default value for divisor-mask
> - Add required properties compatible and model
> - Fix example node name
> - Update example size cells and reg value
>
> Link to v1:https://lore.kernel.org/all/20260520025131.17772-1-challauday369@gmail.com/
> ---
> .../bindings/clock/via,vt8500-clock.yaml | 126 ++++++++++++++++++
> .../devicetree/bindings/clock/vt8500.txt | 74 ----------
> 2 files changed, 126 insertions(+), 74 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/clock/via,vt8500-clock.yaml
> delete mode 100644 Documentation/devicetree/bindings/clock/vt8500.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/via,vt8500-clock.yaml b/Documentation/devicetree/bindings/clock/via,vt8500-clock.yaml
> new file mode 100644
> index 000000000000..9e19103866bc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/via,vt8500-clock.yaml
> @@ -0,0 +1,126 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/via,vt8500-clock.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: VIA/Wondermedia VT8500 Clock Controller
> +
> +maintainers:
> + - Michael Turquette <mturquette@baylibre.com>
> + - Stephen Boyd <sboyd@kernel.org>
> +
> +description: |
Do not need '|' unless you need to preserve formatting.
> + Clock controller bindings for VIA/Wondermedia VT8500 and Wondermedia WM8xxx
> + series SoCs.
> +
> +properties:
> + compatible:
> + enum:
> + - via,vt8500-pll-clock
> + - wm,wm8650-pll-clock
> + - wm,wm8750-pll-clock
> + - wm,wm8850-pll-clock
> + - via,vt8500-device-clock
> +
> + reg:
> + maxItems: 1
> + description:
> + Offset of the PLL register within the PMC register space.
> +
> + clocks:
> + maxItems: 1
> + description:
> + Parent reference clock.
Drop description
> +
> + "#clock-cells":
> + const: 0
> +
> + enable-reg:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Offset of the clock enable register within the PMC register space.
> +
> + enable-bit:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + maximum: 31
> + description:
> + Bit index controlling clock enable.
> +
> + divisor-reg:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Offset of the clock divisor register within the PMC register space.
> +
> + divisor-mask:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + default: 0x1f
> + description:
> + Bitmask describing the divisor field inside divisor-reg.
> +
> +required:
> + - compatible
> + - "#clock-cells"
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + enum:
> + - via,vt8500-pll-clock
> + - wm,wm8650-pll-clock
> + - wm,wm8750-pll-clock
> + - wm,wm8850-pll-clock
> + then:
> + required:
> + - reg
> + - clocks
> +
> + - if:
> + properties:
> + compatible:
> + const: via,vt8500-device-clock
> + then:
> + required:
> + - clocks
> + anyOf:
> + - required:
> + - enable-reg
> + - enable-bit
> + - required:
> + - divisor-reg
reg: false, no?
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + / {
> + compatible = "via,wm8650";
> + model = "Wondermedia WM8650";
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + ref25: clock-25000000 {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <25000000>;
> + };
Drop everything above
> +
> + plla: clock@200 {
> + compatible = "wm,wm8650-pll-clock";
> + reg = <0x200 0x04>;
> + clocks = <&ref25>;
> + #clock-cells = <0>;
> + };
> +
> + clksdhc: clock {
Entire binding is for part of other device, so where is the rest? This
should not be done separately from the parent. And then example goes
only to one place.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 5/6] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Enable GPU and display pipeline
From: Neil Armstrong @ 2026-05-22 6:44 UTC (permalink / raw)
To: Graham O'Connor, linux-arm-msm
Cc: andersson, konradybcio, robin.clark, lumag, abhinav.kumar, robh,
krzk+dt, conor+dt, dri-devel, devicetree, linux-kernel
In-Reply-To: <20260522060645.4399-6-graham.oconnor@gmail.com>
Hi,
On 5/22/26 08:06, Graham O'Connor wrote:
> Enable the GPU clock controller (gpucc), GMU, display clock controller
> (dispcc), and MDSS display subsystem.
>
> Add DisplayPort HPD pinctrl state for GPIO47 and wire up the DP output
> pipeline through the RA620 DP-to-HDMI bridge. The RA620 is a passive
> hardware bridge requiring no driver - it converts DP to HDMI
> autonomously. Add the dp-connector and hdmi-connector nodes to complete
> the display graph.
>
> Disable DSI, DSI PHY, eDP, and eDP PHY as these interfaces are not
> present on the Radxa Dragon Q6A hardware.
>
> Tested on Radxa Dragon Q6A (QCS6490) with RA620 DP-to-HDMI bridge
> connected to an HDMI monitor.
>
> Signed-off-by: Graham O'Connor <graham.oconnor@gmail.com>
> ---
> .../dts/qcom/qcs6490-radxa-dragon-q6a.dts | 85 +++++++++++++++++++
> 1 file changed, 85 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> index 4003837ad..e8ad6e666 100644
> --- a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> @@ -1113,3 +1113,88 @@ &pcie1 {
> &eud {
> status = "disabled";
> };
> +
> +&gpucc {
> + status = "okay";
> +};
> +
> +&gmu {
> + status = "okay";
> +};
> +
> +&dispcc {
> + status = "okay";
> +};
> +
> +&mdss {
> + status = "okay";
> +};
> +
> +&tlmm {
> + dp_hot_plug_det: dp-hot-plug-det-state {
> + pins = "gpio47";
> + function = "dp_hot";
> + bias-disable;
> + };
> +};
> +
> +/ {
> + hdmi-bridge {
> + compatible = "dp-connector";
This is not the right way to enable the HDMI connector.
This patch https://lore.kernel.org/all/20250914-radxa-dragon-q6a-v2-5-045f7e92b3bb@radxa.com/
is the right way by exposing the HDMI bridge and setting the right usb_1_qmpphy data lanes.
Neil
> + label = "hdmi";
> + type = "full-size";
> + pinctrl-names = "default";
> + pinctrl-0 = <&dp_hot_plug_det>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + hdmi_bridge_in: endpoint {
> + remote-endpoint = <&usb_dp_qmpphy_out_dp>;
> + };
> + };
> + port@1 {
> + reg = <1>;
> + hdmi_bridge_out: endpoint {
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> + };
> + };
> + };
> +
> + hdmi-connector {
> + compatible = "hdmi-connector";
> + label = "hdmi";
> + type = "a";
> + port {
> + hdmi_connector_in: endpoint {
> + remote-endpoint = <&hdmi_bridge_out>;
> + };
> + };
> + };
> +};
> +
> +&mdss_dp {
> + status = "okay";
> +};
> +
> +&mdss_dp_out {
> + data-lanes = <0 1>;
> +};
> +
> +&mdss_dsi {
> + status = "disabled";
> +};
> +
> +&mdss_dsi_phy {
> + status = "disabled";
> +};
> +
> +&mdss_edp {
> + status = "disabled";
> +};
> +
> +&mdss_edp_phy {
> + status = "disabled";
> +};
^ permalink raw reply
* Re: [PATCH 6/6] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Enable USB3 SuperSpeed
From: Neil Armstrong @ 2026-05-22 6:44 UTC (permalink / raw)
To: Graham O'Connor, linux-arm-msm
Cc: andersson, konradybcio, robin.clark, lumag, abhinav.kumar, robh,
krzk+dt, conor+dt, dri-devel, devicetree, linux-kernel
In-Reply-To: <20260522060645.4399-7-graham.oconnor@gmail.com>
On 5/22/26 08:06, Graham O'Connor wrote:
> Enable the USB3-A port by configuring the USB HSPHY with required
> regulator supplies and the QMP combo PHY with correct lane assignments
> for this fixed USB-A connector.
>
> The QMP combo PHY shares lanes between DisplayPort and USB3 SuperSpeed.
> Configure port@0 with two endpoints: endpoint@0 for DP output (lanes
> 0-1) connected to the HDMI bridge, and endpoint@1 for USB3 SS output
> (lanes 2-3). Remove the orientation-switch property as this is a fixed
> USB-A connector with no orientation switching.
>
> Add a usb-a-connector node wiring the HS and SS paths to the DWC3
> controller and QMP PHY respectively. Set dr_mode to host as this is
> a fixed host-only USB-A port.
>
> Tested on Radxa Dragon Q6A (QCS6490) with USB3 SuperSpeed confirmed
> via lsusb showing 5000M link speed.
>
> Signed-off-by: Graham O'Connor <graham.oconnor@gmail.com>
> ---
> .../dts/qcom/qcs6490-radxa-dragon-q6a.dts | 71 +++++++++++++++++++
> 1 file changed, 71 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> index e8ad6e666..c16c3664e 100644
> --- a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> @@ -1198,3 +1198,74 @@ &mdss_edp {
> &mdss_edp_phy {
> status = "disabled";
> };
> +
> +&usb_1_hsphy {
> + vdda-pll-supply = <&vreg_l10c_0p88>;
> + vdda18-supply = <&vreg_l1c_1p8>;
> + vdda33-supply = <&vreg_l2b_3p072>;
> + status = "okay";
> +};
> +
> +&usb_1_qmpphy {
> + vdda-phy-supply = <&vreg_l6b_1p2>;
> + vdda-pll-supply = <&vreg_l1b_0p912>;
> + /delete-property/ orientation-switch;
> + status = "okay";
> +
> + ports {
> + port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /delete-node/ endpoint;
> +
> + /* DP output - connected to hdmi-bridge */
> + usb_dp_qmpphy_out_dp: endpoint@0 {
> + reg = <0>;
> + data-lanes = <0 1>;
> + remote-endpoint = <&hdmi_bridge_in>;
> + };
Previous patch needs this change to work, please squash.
Neil
> +
> + /* USB3 SS output */
> + usb_dp_qmpphy_out_usb: endpoint@1 {
> + reg = <1>;
> + data-lanes = <2 3>;
> + remote-endpoint = <&usb3_con_ss_in>;
> + };
> + };
> + };
> +};
> +
> +/ {
> + usb3_con: connector {
> + compatible = "usb-a-connector";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + usb3_con_hs_in: endpoint {
> + remote-endpoint = <&usb_1_dwc3_hs>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + usb3_con_ss_in: endpoint {
> + remote-endpoint = <&usb_dp_qmpphy_out_usb>;
> + };
> + };
> + };
> + };
> +};
> +
> +&usb_1_dwc3_hs {
> + remote-endpoint = <&usb3_con_hs_in>;
> +};
> +
> +&usb_1 {
> + dr_mode = "host";
> + status = "okay";
> +};
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: phy: sc8280xp-qmp-pcie: Document Eliza PCIe phy
From: Krzysztof Kozlowski @ 2026-05-22 6:46 UTC (permalink / raw)
To: Krishna Chaitanya Chundru
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Bjorn Helgaas, Bjorn Andersson,
linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-pci
In-Reply-To: <20260521-eliza-v1-1-97cdbe88389d@oss.qualcomm.com>
On Thu, May 21, 2026 at 07:35:29PM +0530, Krishna Chaitanya Chundru wrote:
> Add compatibles for the Eliza PCIe QMP PHY's, which supports Gen3x1 and
> Gen3x2 configurations.
>
> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
> ---
> .../devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v14 5/6] hwmon: add NXP MC33978/MC34978 driver
From: sashiko-bot @ 2026-05-22 6:47 UTC (permalink / raw)
To: Oleksij Rempel; +Cc: devicetree, conor+dt, linux-hwmon, robh
In-Reply-To: <20260522044855.1772639-6-o.rempel@pengutronix.de>
> Add hardware monitoring support for the NXP MC33978/MC34978 Multiple
> Switch Detection Interface (MSDI).
>
> The hardware utilizes a clear-on-read FAULT register, but physical
> faults remain asserted as long as the underlying condition exists. This
> asserts a global FAULT_STAT bit on the SPI bus. To handle this without
> trapping the CPU in an interrupt storm, this driver implements the
> following architecture:
> - Requests a rising-edge nested IRQ (IRQF_TRIGGER_RISING) from the MFD
> core to catch the initial 0 -> 1 transition of the global fault state.
> - Caches hwmon-specific alarm bits and calculates state edges (XOR) to
> isolate alarm transitions from system integrity faults.
> - Implements a 1Hz delayed workqueue that polls the hardware as long as
> any alarm is active. This compensates for the edge-triggered IRQ by
> discovering secondary faults that occur without a rising edge, and
> detecting when the hardware clears.
>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260522044855.1772639-1-o.rempel@pengutronix.de?part=5
^ permalink raw reply
* Re: [PATCH 1/6] soc: qcom: rpmh-rsc: Skip TCS init when RSC is managed by firmware
From: sashiko-bot @ 2026-05-22 6:48 UTC (permalink / raw)
To: Graham O'Connor; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260522060645.4399-2-graham.oconnor@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Returning early from the probe function bypasses the initialization of critical locks, waitqueues, and list heads, leading to kernel panics when RPMh APIs are invoked.
- [High] The early return completely skips `devm_of_platform_populate()`, preventing essential child devices from probing and permanently breaking the system boot process.
--
commit 42c9f85b1ee98ffd687b17f97edf46cb0e222ced
Author: Graham O'Connor <graham.oconnor@gmail.com>
soc: qcom: rpmh-rsc: Skip TCS init when RSC is managed by firmware
This commit skips TCS initialization in the RPMh RSC driver when the hardware
solver is already active. This prevents security violations and system resets
caused by reinitializing a controller that is actively managed by firmware.
> --- a/drivers/soc/qcom/rpmh-rsc.c
> +++ b/drivers/soc/qcom/rpmh-rsc.c
[ ... ]
> @@ -1074,6 +1074,20 @@ static int rpmh_rsc_probe(struct platform_device *pdev)
> else
> drv->regs = rpmh_rsc_reg_offset_ver_2_7;
>
> + /*
> + * On some platforms the RSC is already managed by the firmware
> + * when the kernel boots. Calling rpmh_probe_tcs_config() in this
> + * state would reinitialize the controller and cause a security
> + * violation. Skip TCS initialization if the hardware solver is
> + * already active.
> + */
> + if (readl_relaxed(drv->base + drv->regs[DRV_SOLVER_CONFIG]) &
> + (DRV_HW_SOLVER_MASK << DRV_HW_SOLVER_SHIFT)) {
> + dev_dbg(&pdev->dev, "RSC already managed by firmware, skipping TCS init\n");
> + platform_set_drvdata(pdev, drv);
> + return 0;
[Severity: Critical]
Since drv is allocated with devm_kzalloc(), bypassing the rest of the probe
function leaves essential software structures uninitialized.
Specifically, spin_lock_init(&drv->client.cache_lock),
init_waitqueue_head(&drv->tcs_wait), and INIT_LIST_HEAD(&drv->client.cache)
are skipped.
Because platform_set_drvdata(pdev, drv) exposes this controller to other
drivers, will standard RPMh APIs like rpmh_write() crash with a NULL pointer
dereference when attempting to acquire the uninitialized spinlock or add to
the zero-initialized list head?
[Severity: High]
Does this early return also skip the instantiation of child devices?
The rpmh_rsc_probe() function normally relies on devm_of_platform_populate()
at the end of the function to instantiate its children. By returning early,
crucial child devices such as the clock controller (rpmhcc), power domain
controller (rpmhpd), and interconnect voters (bcm-voter) are never created.
Will this leave downstream peripheral drivers that depend on these clocks
or regulators permanently stuck in an -EPROBE_DEFER state, breaking the
system boot process?
> + }
> +
> ret = rpmh_probe_tcs_config(pdev, drv);
> if (ret)
> return ret;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260522060645.4399-1-graham.oconnor@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: PCI: qcom: Document the Eliza PCIe Controller
From: Krzysztof Kozlowski @ 2026-05-22 6:50 UTC (permalink / raw)
To: Krishna Chaitanya Chundru
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Bjorn Helgaas, Bjorn Andersson,
linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-pci
In-Reply-To: <20260521-eliza-v1-2-97cdbe88389d@oss.qualcomm.com>
On Thu, May 21, 2026 at 07:35:30PM +0530, Krishna Chaitanya Chundru wrote:
> +description:
> + Qualcomm ELIZA SoC (and compatible) PCIe root complex controller is based on
> + the Synopsis DesignWare PCIe IP.
> +
> +properties:
> + compatible:
> + const: qcom,pcie-eliza
All new pcie compatibles moved to correct format.
> +
> + reg:
> + minItems: 5
> + maxItems: 6
> +
> + reg-names:
> + minItems: 5
> + items:
> + - const: parf # Qualcomm specific registers
> + - const: dbi # DesignWare PCIe registers
> + - const: elbi # External local bus interface registers
> + - const: atu # ATU address space
> + - const: config # PCIe configuration space
> + - const: mhi # MHI registers
> +
> + clocks:
> + maxItems: 7
> +
> + clock-names:
> + items:
> + - const: aux # Auxiliary clock
> + - const: cfg # Configuration clock
> + - const: bus_master # Master AXI clock
> + - const: bus_slave # Slave AXI clock
> + - const: slave_q2a # Slave Q2A clock
> + - const: ddrss_sf_tbu # PCIe SF TBU clock
> + - const: cnoc_sf_axi # Config NoC PCIe1 AXI clock
> +
> + interrupts:
> + minItems: 8
This should not be flexible. Neither 'reg'.
> + maxItems: 9
> +
> + interrupt-names:
> + minItems: 8
> + items:
> + - const: msi0
> + - const: msi1
> + - const: msi2
> + - const: msi3
> + - const: msi4
> + - const: msi5
> + - const: msi6
> + - const: msi7
> + - const: global
> +
> + resets:
> + maxItems: 2
> +
> + reset-names:
> + items:
> + - const: pci # PCIe core reset
> + - const: link_down # PCIe link down reset
> +
> +required:
> + - power-domains
> + - resets
> + - reset-names
> +
> +allOf:
> + - $ref: qcom,pcie-common.yaml#
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/qcom,eliza-gcc.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/interconnect/qcom,eliza-rpmh.h>
> +
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + pcie@1c00000 {
> + compatible = "qcom,pcie-eliza";
> + reg = <0 0x01c00000 0 0x3000>,
> + <0 0x40000000 0 0xf1d>,
> + <0 0x40000f20 0 0xa8>,
> + <0 0x40001000 0 0x1000>,
> + <0 0x40100000 0 0x100000>;
> + reg-names = "parf", "dbi", "elbi", "atu", "config";
> + ranges = <0x01000000 0x0 0x00000000 0x0 0x40200000 0x0 0x100000>,
> + <0x02000000 0x0 0x40300000 0x0 0x40300000 0x0 0x3d00000>;
> +
> + bus-range = <0x00 0xff>;
> + device_type = "pci";
> + linux,pci-domain = <0>;
> + num-lanes = <1>;
> +
> + #address-cells = <3>;
> + #size-cells = <2>;
> +
> + clocks = <&gcc GCC_PCIE_0_AUX_CLK>,
> + <&gcc GCC_PCIE_0_CFG_AHB_CLK>,
> + <&gcc GCC_PCIE_0_MSTR_AXI_CLK>,
> + <&gcc GCC_PCIE_0_SLV_AXI_CLK>,
> + <&gcc GCC_PCIE_0_SLV_Q2A_AXI_CLK>,
> + <&gcc GCC_DDRSS_PCIE_SF_QTB_CLK>,
> + <&gcc GCC_CNOC_PCIE_SF_AXI_CLK>;
> + clock-names = "aux",
> + "cfg",
> + "bus_master",
> + "bus_slave",
> + "slave_q2a",
> + "ddrss_sf_tbu",
> + "cnoc_sf_axi";
> +
> + dma-coherent;
> +
> + interrupts = <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 478 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 479 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 535 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 536 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 537 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 540 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 653 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "msi0", "msi1", "msi2", "msi3",
> + "msi4", "msi5", "msi6", "msi7", "global";
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 0x7>;
> + interrupt-map = <0 0 0 1 &intc 0 0 0 564 IRQ_TYPE_LEVEL_HIGH>, /* int_a */
> + <0 0 0 2 &intc 0 0 0 565 IRQ_TYPE_LEVEL_HIGH>, /* int_b */
> + <0 0 0 3 &intc 0 0 0 566 IRQ_TYPE_LEVEL_HIGH>, /* int_c */
> + <0 0 0 4 &intc 0 0 0 567 IRQ_TYPE_LEVEL_HIGH>; /* int_d */
> +
> + interconnects = <&pcie_noc MASTER_PCIE_0 0 &mc_virt SLAVE_EBI1 0>,
> + <&gem_noc MASTER_APPSS_PROC 0 &cnoc_main SLAVE_PCIE_0 0>;
> + interconnect-names = "pcie-mem", "cpu-pcie";
> +
> + iommu-map = <0x0 &apps_smmu 0x1480 0x1>,
> + <0x100 &apps_smmu 0x1481 0x1>;
> +
> + pinctrl-0 = <&pcie0_default_state>;
> + pinctrl-names = "default";
> +
> + power-domains = <&gcc GCC_PCIE_0_GDSC>;
> +
> + resets = <&gcc GCC_PCIE_0_BCR>,
> + <&gcc GCC_PCIE_0_LINK_DOWN_BCR>;
> + reset-names = "pci",
> + "link_down";
> +
Drop stray blank line.
> + };
> + };
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH 3/4] PCI: qcom: Add Support for Eliza
From: Krzysztof Kozlowski @ 2026-05-22 6:51 UTC (permalink / raw)
To: Krishna Chaitanya Chundru
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Bjorn Helgaas, Bjorn Andersson,
linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-pci
In-Reply-To: <20260521-eliza-v1-3-97cdbe88389d@oss.qualcomm.com>
On Thu, May 21, 2026 at 07:35:31PM +0530, Krishna Chaitanya Chundru wrote:
> Add support for Eliza soc, which has two PCIe controllers capable
> of 8GT/s X1 and 8GT/s X2, using the cfg_1_9_0 configuration.
>
> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
> ---
> drivers/pci/controller/dwc/pcie-qcom.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> index af6bf5cce65b..40f0a5f247eb 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> @@ -2123,6 +2123,7 @@ static int qcom_pcie_resume_noirq(struct device *dev)
> static const struct of_device_id qcom_pcie_match[] = {
> { .compatible = "qcom,pcie-apq8064", .data = &cfg_2_1_0 },
> { .compatible = "qcom,pcie-apq8084", .data = &cfg_1_0_0 },
> + { .compatible = "qcom,pcie-eliza", .data = &cfg_1_9_0 },
So compatible with sm8550. Why isn't this explained in commit msg of
the binding?
Anyway, drop the change, pointless. Look how other devices handle this -
do you see kaanapali here? No.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 14/15] dt-bindings: display: panel-lvds: Add LG LP156WF1
From: Krzysztof Kozlowski @ 2026-05-22 6:53 UTC (permalink / raw)
To: Vitor Soares
Cc: Laurent Pinchart, Neil Armstrong, Jessica Zhang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Lad Prabhakar,
Thierry Reding, Sam Ravnborg, Vitor Soares, dri-devel, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260521150038.103538-31-ivitro@gmail.com>
On Thu, May 21, 2026 at 04:00:50PM +0100, Vitor Soares wrote:
> From: Vitor Soares <vitor.soares@toradex.com>
>
> Add the compatible string for the LG LP156WF1 15.6" FHD (1920x1080)
> dual-channel TFT LCD LVDS panel.
>
> Assisted-by: Claude:claude-sonnet-4.6
Really - oneliner for trivial binding needs AI tools to help writing it?
> Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
> ---
> Documentation/devicetree/bindings/display/panel/panel-lvds.yaml | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 13/15] dt-bindings: display: panel-lvds: Add dual-channel LVDS support
From: Krzysztof Kozlowski @ 2026-05-22 6:55 UTC (permalink / raw)
To: Vitor Soares
Cc: Laurent Pinchart, Neil Armstrong, Jessica Zhang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Lad Prabhakar,
Thierry Reding, Sam Ravnborg, Vitor Soares, dri-devel, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260521150038.103538-30-ivitro@gmail.com>
On Thu, May 21, 2026 at 04:00:49PM +0100, Vitor Soares wrote:
> From: Vitor Soares <vitor.soares@toradex.com>
>
> The panel-lvds binding only supports single-channel panels.
On purpose, no?
> Extend it to support dual-channel LVDS panels by referencing the
> lvds-dual-ports schema when a ports container is present.
You now changed existing panels to dual channel.
>
> Assisted-by: Claude:claude-sonnet-4.6
Using assisted by is not permission to send us unreviewed code.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/6] drm/msm/dp: Limit voltage swing level to 2 for RA620 bridge
From: sashiko-bot @ 2026-05-22 6:55 UTC (permalink / raw)
To: Graham O'Connor; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260522060645.4399-4-graham.oconnor@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] A device-specific workaround for the RA620 bridge is applied globally, capping the maximum voltage swing and pre-emphasis levels for all DP devices using the MSM DP driver.
--
commit cfc03fd78122eb643ca94e4cccdc197ffa9a8de0
Author: Graham O'Connor <graham.oconnor@gmail.com>
drm/msm/dp: Limit voltage swing level to 2 for RA620 bridge
This commit reduces the maximum DisplayPort link training level to 2 to work
around a link training failure specific to the RA620 DP-to-HDMI bridge used
on the Radxa Dragon Q6A platform.
> diff --git a/drivers/gpu/drm/msm/dp/dp_link.h b/drivers/gpu/drm/msm/dp/dp_link.h
> index 76125e9c07e9c..ff0d8e99d87c9 100644
> --- a/drivers/gpu/drm/msm/dp/dp_link.h
> +++ b/drivers/gpu/drm/msm/dp/dp_link.h
> @@ -24,7 +24,7 @@ struct msm_dp_link_info {
> unsigned long capabilities;
> };
>
> -#define DP_TRAIN_LEVEL_MAX 3
> +#define DP_TRAIN_LEVEL_MAX 2
[Severity: High]
Does this change globally cap the maximum voltage swing and pre-emphasis
levels for all DisplayPort devices using the MSM DP driver?
Because the DP specification supports voltage swing up to level 3, which is
often required for signal integrity over long cables or at high bandwidths,
removing this capability globally can cause link training failures and
unstable connections on fully compliant displays.
Furthermore, since maximum pre-emphasis is calculated as DP_TRAIN_LEVEL_MAX
minus the voltage level, capping this macro at 2 means that if a voltage
swing level of 2 is used, the pre-emphasis level is strictly constrained to 0.
Could this hardware-specific workaround for the RA620 bridge be implemented
conditionally (for example, via DPCD OUI detection, bridge properties, or
device tree matching) rather than permanently degrading global subsystem
capabilities for all platforms?
>
> struct msm_dp_link_test_video {
> u32 test_video_pattern;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260522060645.4399-1-graham.oconnor@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH v18 2/3] riscv: dts: starfive: Correct pwm nodes
From: Hal Feng @ 2026-05-22 6:47 UTC (permalink / raw)
To: Conor Dooley
Cc: Uwe Kleine-König, Philipp Zabel, Rob Herring,
Krzysztof Kozlowski, Emil Renner Berthing, Palmer Dabbelt,
Paul Walmsley, Albert Ou, Changhuang Liang,
linux-pwm@vger.kernel.org, devicetree@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260515-dandruff-outpour-7b3b6b5480db@spud>
> On 26.05.15 21:10, Conor Dooley wrote:
> On Fri, May 15, 2026 at 01:47:21PM +0800, Hal Feng wrote:
> > Each of the StarFive JH7100/JH7110 SoCs has 8 OpenCores PTC IP cores.
> > One OpenCores PTC IP core can output one PWM channel.
> >
> > Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
> > ---
> > .../boot/dts/starfive/jh7100-common.dtsi | 28 ++++++--
> > arch/riscv/boot/dts/starfive/jh7100.dtsi | 69 ++++++++++++++++++-
> > .../boot/dts/starfive/jh7110-common.dtsi | 27 ++++++--
> > .../boot/dts/starfive/jh7110-milkv-mars.dts | 6 +-
> > .../dts/starfive/jh7110-milkv-marscm.dtsi | 6 +-
> > .../dts/starfive/jh7110-pine64-star64.dts | 6 +-
> > .../jh7110-starfive-visionfive-2-lite.dtsi | 6 +-
> > .../jh7110-starfive-visionfive-2.dtsi | 6 +-
> > arch/riscv/boot/dts/starfive/jh7110.dtsi | 69 ++++++++++++++++++-
> > 9 files changed, 200 insertions(+), 23 deletions(-)
> >
> > diff --git a/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
> > b/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
> > index ae1a6aeb0aea..85106545090e 100644
> > --- a/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
> > +++ b/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
> > @@ -199,13 +199,23 @@ GPO_I2C2_PAD_SDA_OEN,
> > };
> > };
> >
> > - pwm_pins: pwm-0 {
> > - pwm-pins {
> > + pwm0_pins: pwm0-0 {
> > + pwm0-pins {
> > pinmux = <GPIOMUX(7,
> > GPO_PWM_PAD_OUT_BIT0,
> > GPO_PWM_PAD_OE_N_BIT0,
> > - GPI_NONE)>,
> > - <GPIOMUX(5,
> > + GPI_NONE)>;
> > + bias-disable;
> > + drive-strength = <35>;
> > + input-disable;
> > + input-schmitt-disable;
> > + slew-rate = <0>;
> > + };
> > + };
> > +
> > + pwm1_pins: pwm1-0 {
> > + pwm1-pins {
> > + pinmux = <GPIOMUX(5,
> > GPO_PWM_PAD_OUT_BIT1,
> > GPO_PWM_PAD_OE_N_BIT1,
> > GPI_NONE)>;
> > @@ -359,9 +369,15 @@ &osc_aud {
> > clock-frequency = <27000000>;
> > };
> >
> > -&pwm {
> > +&pwm0 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pwm0_pins>;
> > + status = "okay";
> > +};
> > +
> > +&pwm1 {
> > pinctrl-names = "default";
> > - pinctrl-0 = <&pwm_pins>;
> > + pinctrl-0 = <&pwm1_pins>;
> > status = "okay";
> > };
> >
> > diff --git a/arch/riscv/boot/dts/starfive/jh7100.dtsi
> > b/arch/riscv/boot/dts/starfive/jh7100.dtsi
> > index 7de0732b8eab..4629e9747307 100644
> > --- a/arch/riscv/boot/dts/starfive/jh7100.dtsi
> > +++ b/arch/riscv/boot/dts/starfive/jh7100.dtsi
> > @@ -360,9 +360,72 @@ watchdog@12480000 {
> > <&rstgen JH7100_RSTN_WDT>;
> > };
> >
> > - pwm: pwm@12490000 {
> > - compatible = "starfive,jh7100-pwm", "opencores,pwm-v1";
> > - reg = <0x0 0x12490000 0x0 0x10000>;
> > + pwm0: pwm@12490000 {
> > + compatible = "opencores,pwm-v1";
> > + reg = <0x0 0x12490000 0x0 0x10>;
>
> NAK on the compatibles front, but this also looks very suspect, given the size of
> the register regions, but I think it is actually correct.
> You need to explain why it is correct in the commit message.
OK. Will keep the old compatibles and explain the change of register size in
the commit message.
Best regards,
Hal
^ 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