* [PATCH 1/3] powerpc/dts: mpc5121: Move GPIO controller properties to SoC dtsi
From: Dmitry Torokhov @ 2026-07-19 5:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Anatolij Gustschin
Cc: devicetree, linuxppc-dev, linux-kernel
In-Reply-To: <20260718-ads7846-pdm360ng-v1-0-f318f85cda57@gmail.com>
Define gpio@1100 with label gpio_pic as a GPIO controller and
interrupt controller directly in mpc5121.dtsi so all MPC5121 boards
inherit the correct controller capabilities.
Remove the redundant local controller property declaration block from
ac14xx.dts.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
arch/powerpc/boot/dts/ac14xx.dts | 13 -------------
arch/powerpc/boot/dts/mpc5121.dtsi | 6 +++++-
2 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/boot/dts/ac14xx.dts b/arch/powerpc/boot/dts/ac14xx.dts
index 5d8877e1f4ad..05fcf08df1ca 100644
--- a/arch/powerpc/boot/dts/ac14xx.dts
+++ b/arch/powerpc/boot/dts/ac14xx.dts
@@ -148,19 +148,6 @@ clock@f00 {
compatible = "fsl,mpc5121rev2-clock", "fsl,mpc5121-clock";
};
- /*
- * GPIO PIC:
- * interrupts cell = <pin nr, sense>
- * sense == 8: Level, low assertion
- * sense == 2: Edge, high-to-low change
- */
- gpio_pic: gpio@1100 {
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
sdhc@1500 {
cd-gpios = <&gpio_pic 23 0>; /* card detect */
wp-gpios = <&gpio_pic 24 0>; /* write protect */
diff --git a/arch/powerpc/boot/dts/mpc5121.dtsi b/arch/powerpc/boot/dts/mpc5121.dtsi
index a278fb7b9e71..9c5dacb94b92 100644
--- a/arch/powerpc/boot/dts/mpc5121.dtsi
+++ b/arch/powerpc/boot/dts/mpc5121.dtsi
@@ -146,10 +146,14 @@ pmc@1000 {
interrupts = <83 0x8>;
};
- gpio@1100 {
+ gpio_pic: gpio@1100 {
compatible = "fsl,mpc5121-gpio";
reg = <0x1100 0x100>;
interrupts = <78 0x8>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
};
can@1300 {
--
2.55.0.229.g6434b31f56-goog
^ permalink raw reply related
* [PATCH 2/3] powerpc/dts: pdm360ng: Convert ADS7845 touchscreen to DT bindings
From: Dmitry Torokhov @ 2026-07-19 5:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Anatolij Gustschin
Cc: devicetree, linuxppc-dev, linux-kernel
In-Reply-To: <20260718-ads7846-pdm360ng-v1-0-f318f85cda57@gmail.com>
The PDM360NG board is equipped with an ADS7845 touchscreen controller.
Previously, pdm360ng.dts used "ti,ads7846" as a placeholder and relied
on platform data in pdm360ng.c to override the model to 7845.
Update the ts@0 touchscreen node in pdm360ng.dts to use the correct
"ti,ads7845" compatible string along with pendown-gpio and
interrupt-parent properties referencing gpio_pic.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
arch/powerpc/boot/dts/pdm360ng.dts | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/pdm360ng.dts b/arch/powerpc/boot/dts/pdm360ng.dts
index 67c3b9db75d7..69d8b6a0241c 100644
--- a/arch/powerpc/boot/dts/pdm360ng.dts
+++ b/arch/powerpc/boot/dts/pdm360ng.dts
@@ -176,11 +176,12 @@ psc@11900 {
/* ADS7845 touch screen controller */
ts@0 {
- compatible = "ti,ads7846";
+ compatible = "ti,ads7845";
reg = <0x0>;
spi-max-frequency = <3000000>;
- /* pen irq is GPIO25 */
- interrupts = <78 0x8>;
+ interrupt-parent = <&gpio_pic>;
+ interrupts = <25 0x8>;
+ pendown-gpio = <&gpio_pic 25 0>;
};
};
--
2.55.0.229.g6434b31f56-goog
^ permalink raw reply related
* [PATCH 3/3] powerpc/512x: Remove pdm360ng platform setup in favor of mpc512x_generic
From: Dmitry Torokhov @ 2026-07-19 5:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Anatolij Gustschin
Cc: devicetree, linuxppc-dev, linux-kernel
In-Reply-To: <20260718-ads7846-pdm360ng-v1-0-f318f85cda57@gmail.com>
Now that the ADS7845 touchscreen on PDM360NG is fully described in the
device tree, custom platform setup in pdm360ng.c is no longer needed.
Add ifm,pdm360ng to the board match list in mpc512x_generic.c, update
Kconfig to select MPC512x_GENERIC for PDM360NG, and remove pdm360ng.c.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
arch/powerpc/platforms/512x/Kconfig | 3 +-
arch/powerpc/platforms/512x/Makefile | 1 -
arch/powerpc/platforms/512x/mpc512x_generic.c | 1 +
arch/powerpc/platforms/512x/pdm360ng.c | 126 --------------------------
4 files changed, 3 insertions(+), 128 deletions(-)
diff --git a/arch/powerpc/platforms/512x/Kconfig b/arch/powerpc/platforms/512x/Kconfig
index deecede78776..9d46d791af05 100644
--- a/arch/powerpc/platforms/512x/Kconfig
+++ b/arch/powerpc/platforms/512x/Kconfig
@@ -32,11 +32,12 @@ config MPC512x_GENERIC
which do not need custom platform specific setup.
Compatible boards include: Protonic LVT base boards (ZANMCU
- and VICVT2), Freescale MPC5125 Tower system.
+ and VICVT2), Freescale MPC5125 Tower system, IFM PDM360NG.
config PDM360NG
bool "ifm PDM360NG board"
depends on PPC_MPC512x
+ select MPC512x_GENERIC
select DEFAULT_UIMAGE
help
This option enables support for the PDM360NG board.
diff --git a/arch/powerpc/platforms/512x/Makefile b/arch/powerpc/platforms/512x/Makefile
index 2daf22ee26a0..4da6f6923d8f 100644
--- a/arch/powerpc/platforms/512x/Makefile
+++ b/arch/powerpc/platforms/512x/Makefile
@@ -7,4 +7,3 @@ obj-y += mpc512x_shared.o
obj-$(CONFIG_MPC5121_ADS) += mpc5121_ads.o mpc5121_ads_cpld.o
obj-$(CONFIG_MPC512x_GENERIC) += mpc512x_generic.o
obj-$(CONFIG_MPC512x_LPBFIFO) += mpc512x_lpbfifo.o
-obj-$(CONFIG_PDM360NG) += pdm360ng.o
diff --git a/arch/powerpc/platforms/512x/mpc512x_generic.c b/arch/powerpc/platforms/512x/mpc512x_generic.c
index d4fa6c302ccf..d330d3d85887 100644
--- a/arch/powerpc/platforms/512x/mpc512x_generic.c
+++ b/arch/powerpc/platforms/512x/mpc512x_generic.c
@@ -24,6 +24,7 @@ static const char * const board[] __initconst = {
"prt,prtlvt",
"fsl,mpc5125ads",
"ifm,ac14xx",
+ "ifm,pdm360ng",
NULL
};
diff --git a/arch/powerpc/platforms/512x/pdm360ng.c b/arch/powerpc/platforms/512x/pdm360ng.c
deleted file mode 100644
index 8bbbf78bb42b..000000000000
--- a/arch/powerpc/platforms/512x/pdm360ng.c
+++ /dev/null
@@ -1,126 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/*
- * Copyright (C) 2010 DENX Software Engineering
- *
- * Anatolij Gustschin, <agust@denx.de>
- *
- * PDM360NG board setup
- */
-
-#include <linux/device.h>
-#include <linux/kernel.h>
-#include <linux/io.h>
-#include <linux/of.h>
-#include <linux/of_address.h>
-#include <linux/of_fdt.h>
-
-#include <asm/machdep.h>
-#include <asm/ipic.h>
-
-#include "mpc512x.h"
-
-#if defined(CONFIG_TOUCHSCREEN_ADS7846) || \
- defined(CONFIG_TOUCHSCREEN_ADS7846_MODULE)
-#include <linux/interrupt.h>
-#include <linux/spi/ads7846.h>
-#include <linux/spi/spi.h>
-#include <linux/notifier.h>
-
-static void *pdm360ng_gpio_base;
-
-static int pdm360ng_get_pendown_state(void)
-{
- u32 reg;
-
- reg = in_be32(pdm360ng_gpio_base + 0xc);
- if (reg & 0x40)
- setbits32(pdm360ng_gpio_base + 0xc, 0x40);
-
- reg = in_be32(pdm360ng_gpio_base + 0x8);
-
- /* return 1 if pen is down */
- return (reg & 0x40) == 0;
-}
-
-static struct ads7846_platform_data pdm360ng_ads7846_pdata = {
- .model = 7845,
- .get_pendown_state = pdm360ng_get_pendown_state,
- .irq_flags = IRQF_TRIGGER_LOW,
-};
-
-static int __init pdm360ng_penirq_init(void)
-{
- struct device_node *np;
-
- np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-gpio");
- if (!np) {
- pr_err("%s: Can't find 'mpc5121-gpio' node\n", __func__);
- return -ENODEV;
- }
-
- pdm360ng_gpio_base = of_iomap(np, 0);
- of_node_put(np);
- if (!pdm360ng_gpio_base) {
- pr_err("%s: Can't map gpio regs.\n", __func__);
- return -ENODEV;
- }
- out_be32(pdm360ng_gpio_base + 0xc, 0xffffffff);
- setbits32(pdm360ng_gpio_base + 0x18, 0x2000);
- setbits32(pdm360ng_gpio_base + 0x10, 0x40);
-
- return 0;
-}
-
-static int pdm360ng_touchscreen_notifier_call(struct notifier_block *nb,
- unsigned long event, void *__dev)
-{
- struct device *dev = __dev;
-
- if ((event == BUS_NOTIFY_ADD_DEVICE) &&
- of_device_is_compatible(dev->of_node, "ti,ads7846")) {
- dev->platform_data = &pdm360ng_ads7846_pdata;
- return NOTIFY_OK;
- }
- return NOTIFY_DONE;
-}
-
-static struct notifier_block pdm360ng_touchscreen_nb = {
- .notifier_call = pdm360ng_touchscreen_notifier_call,
-};
-
-static void __init pdm360ng_touchscreen_init(void)
-{
- if (pdm360ng_penirq_init())
- return;
-
- bus_register_notifier(&spi_bus_type, &pdm360ng_touchscreen_nb);
-}
-#else
-static inline void __init pdm360ng_touchscreen_init(void)
-{
-}
-#endif /* CONFIG_TOUCHSCREEN_ADS7846 */
-
-static void __init pdm360ng_init(void)
-{
- mpc512x_init();
- pdm360ng_touchscreen_init();
-}
-
-static int __init pdm360ng_probe(void)
-{
- mpc512x_init_early();
-
- return 1;
-}
-
-define_machine(pdm360ng) {
- .name = "PDM360NG",
- .compatible = "ifm,pdm360ng",
- .probe = pdm360ng_probe,
- .setup_arch = mpc512x_setup_arch,
- .init = pdm360ng_init,
- .init_IRQ = mpc512x_init_IRQ,
- .get_irq = ipic_get_irq,
- .restart = mpc512x_restart,
-};
--
2.55.0.229.g6434b31f56-goog
^ permalink raw reply related
* Re: [PATCH 3/3] powerpc/512x: Remove pdm360ng platform setup in favor of mpc512x_generic
From: sashiko-bot @ 2026-07-19 5:33 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260718-ads7846-pdm360ng-v1-3-f318f85cda57@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Removing the custom `get_pendown_state` hook exposes an incorrect active-high polarity in the device tree, breaking the touchscreen.
--
--- Patch [3]: [PATCH 3/3] powerpc/512x: Remove pdm360ng platform setup in favor of mpc512x_generic ---
commit 9b77e36fa4d0feb9318830af9ed4e14fde12adec
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Subject: powerpc/512x: Remove pdm360ng platform setup in favor of mpc512x_generic
This commit removes the custom platform setup file pdm360ng.c for the
PDM360NG board, stating that its ADS7845 touchscreen is now fully described
in the device tree. It also adds the board to the mpc512x_generic match list
and updates Kconfig to remove the specific board file.
> diff --git a/arch/powerpc/platforms/512x/pdm360ng.c b/arch/powerpc/platforms/512x/pdm360ng.c
> deleted file mode 100644
> index 8bbbf78bb42bd..0000000000000
> --- a/arch/powerpc/platforms/512x/pdm360ng.c
> +++ /dev/null
> @@ -1,126 +0,0 @@
[ ... ]
> -static int pdm360ng_get_pendown_state(void)
> -{
> - u32 reg;
> -
> - reg = in_be32(pdm360ng_gpio_base + 0xc);
> - if (reg & 0x40)
> - setbits32(pdm360ng_gpio_base + 0xc, 0x40);
> -
> - reg = in_be32(pdm360ng_gpio_base + 0x8);
> -
> - /* return 1 if pen is down */
> - return (reg & 0x40) == 0;
> -}
[Severity: High]
Will removing this custom pendown handler break the touchscreen due to an
incorrect polarity specified in the device tree?
The custom pdm360ng_get_pendown_state() function returned 1 when the pen was
down, properly inverting the active-low hardware signal:
return (reg & 0x40) == 0;
With this custom code removed, the ads7846 driver falls back to using the
pendown-gpio property defined in arch/powerpc/boot/dts/pdm360ng.dts:
pendown-gpio = <&gpio_pic 25 0>;
Since this property specifies 0 (GPIO_ACTIVE_HIGH) instead of active-low,
gpiod_get_value() will return 0 when the pin is physically low. This causes
ads7846_hard_irq() to incorrectly interpret the pen as being UP and return
IRQ_HANDLED instead of waking the thread, effectively dropping all touch
events.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260718-ads7846-pdm360ng-v1-0-f318f85cda57@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/dts: mpc5121: Move GPIO controller properties to SoC dtsi
From: sashiko-bot @ 2026-07-19 5:34 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260718-ads7846-pdm360ng-v1-1-f318f85cda57@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The ads7846 touchscreen driver and gpio-mpc8xxx driver both claim IPIC IRQ 78, leading to an IRQ request conflict and masked interrupts.
--
--- Patch [1]: [PATCH 1/3] powerpc/dts: mpc5121: Move GPIO controller properties to SoC dtsi ---
commit 9f0c3f1fd5a726a9eddf4e07512d2ccf88203d01
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
powerpc/dts: mpc5121: Move GPIO controller properties to SoC dtsi
Define gpio@1100 with label gpio_pic as a GPIO controller and
interrupt controller directly in mpc5121.dtsi so all MPC5121 boards
inherit the correct controller capabilities.
> diff --git a/arch/powerpc/boot/dts/mpc5121.dtsi b/arch/powerpc/boot/dts/mpc5121.dtsi
> index a278fb7b9e711..9c5dacb94b924 100644
> --- a/arch/powerpc/boot/dts/mpc5121.dtsi
> +++ b/arch/powerpc/boot/dts/mpc5121.dtsi
[ ... ]
> @@ -146,10 +146,14 @@ pmc@1000 {
> interrupts = <83 0x8>;
> };
>
> - gpio@1100 {
> + gpio_pic: gpio@1100 {
> compatible = "fsl,mpc5121-gpio";
> reg = <0x1100 0x100>;
> interrupts = <78 0x8>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
[Severity: High]
This is a pre-existing issue, but does centralizing this interrupt controller
declaration leave an unresolved IRQ request conflict on the pdm360ng board?
In arch/powerpc/boot/dts/pdm360ng.dts, the touchscreen node directly claims
IPIC IRQ 78 instead of routing through the GPIO controller:
ts@0 {
...
interrupts = <78 0x8>;
};
Additionally, in arch/powerpc/platforms/512x/pdm360ng.c,
pdm360ng_penirq_init() directly manipulates the GPIO controller's IMR
register:
setbits32(pdm360ng_gpio_base + 0x10, 0x40);
When both the ads7846 touchscreen driver and gpio-mpc8xxx driver try to
claim IRQ 78, could the request fail with -EBUSY?
Even if they could share the IRQ, the gpio-mpc8xxx driver clears the GPIO
IMR register on probe, which would silently overwrite the earlier setup
done by pdm360ng_penirq_init() and mask the touchscreen's interrupt.
Could this cause a permanent loss of touch input on boot for the pdm360ng
when both drivers are enabled?
> };
>
> can@1300 {
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260718-ads7846-pdm360ng-v1-0-f318f85cda57@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH 2/3] powerpc/dts: pdm360ng: Convert ADS7845 touchscreen to DT bindings
From: sashiko-bot @ 2026-07-19 5:35 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260718-ads7846-pdm360ng-v1-2-f318f85cda57@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The `pendown-gpio` property is configured with active-high polarity instead of active-low, which breaks touchscreen input and causes an interrupt storm.
- [High] Legacy platform data and raw initialization code for the touchscreen were not removed, leaving dead code and conflicting hardware initialization.
--
--- Patch [2]: [PATCH 2/3] powerpc/dts: pdm360ng: Convert ADS7845 touchscreen to DT bindings ---
commit 1e38d4980520e39bd3a703aa35c53c86099afebb
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
powerpc/dts: pdm360ng: Convert ADS7845 touchscreen to DT bindings
The PDM360NG board is equipped with an ADS7845 touchscreen controller.
Previously, pdm360ng.dts used "ti,ads7846" as a placeholder and relied
on platform data in pdm360ng.c to override the model to 7845.
Update the ts@0 touchscreen node in pdm360ng.dts to use the correct
"ti,ads7845" compatible string along with pendown-gpio and
interrupt-parent properties referencing gpio_pic.
> diff --git a/arch/powerpc/boot/dts/pdm360ng.dts b/arch/powerpc/boot/dts/pdm360ng.dts
> index 67c3b9db75d76..69d8b6a0241cb 100644
> --- a/arch/powerpc/boot/dts/pdm360ng.dts
> +++ b/arch/powerpc/boot/dts/pdm360ng.dts
> @@ -176,11 +176,12 @@ psc@11900 {
>
> /* ADS7845 touch screen controller */
> ts@0 {
> - compatible = "ti,ads7846";
> + compatible = "ti,ads7845";
[Severity: High]
Will updating the compatible string here leave conflicting legacy
initialization active in arch/powerpc/platforms/512x/pdm360ng.c?
Since pdm360ng_touchscreen_notifier_call() checks for "ti,ads7846", this
change will cause the notifier to silently fail, abandoning the platform
data injection and leaving it as dead code.
Additionally, pdm360ng_penirq_init() still executes unconditionally on boot,
performing uncoordinated direct memory writes to configure the GPIO
controller interrupt.
Since the touchscreen is now natively bound to the GPIO subsystem via DT,
will this raw memory manipulation conflict with the subsystem's state?
> reg = <0x0>;
> spi-max-frequency = <3000000>;
> - /* pen irq is GPIO25 */
> - interrupts = <78 0x8>;
> + interrupt-parent = <&gpio_pic>;
> + interrupts = <25 0x8>;
> + pendown-gpio = <&gpio_pic 25 0>;
[Severity: High]
Is this pendown-gpio configuration expected to use the GPIO_ACTIVE_HIGH
flag (0)?
The interrupts property correctly defines a level-low trigger (0x8), but the
pendown-gpio property uses 0.
When the pen is down, the driver's gpiod_get_value() in get_pendown_state()
reads the physical 0 and returns a logical 0. This signals to ads7846_irq()
that the pen is up, aborting without executing the SPI sequence needed to
clear the hardware interrupt.
Because the interrupt is level-triggered and never cleared, it fires
continuously.
Should this use GPIO_ACTIVE_LOW (1) instead to prevent an interrupt storm?
> };
> };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260718-ads7846-pdm360ng-v1-0-f318f85cda57@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH 1/4] regulator: dt-bindings: Add Silergy SYR82X allowed modes
From: Krzysztof Kozlowski @ 2026-07-19 5:58 UTC (permalink / raw)
To: Victor Krawiec, Mark Brown
Cc: lgirdwood, robh, krzk+dt, conor+dt, linux-kernel, devicetree
In-Reply-To: <c3977e59-951b-4d91-a775-6c96cb84e37c@arturia.com>
On 17/07/2026 16:14, Victor Krawiec wrote:
>
>
> On 7/17/26 14:44, Mark Brown wrote:
>> On Fri, Jul 17, 2026 at 02:31:51PM +0200, Krzysztof Kozlowski wrote:
>>
>>> So you are adding constants for one device but used in the bindings and
>>> driver for other? Are they valid there?
>>
>> It's one of these devices that's got a bunch of clones from various
>> manufacturers with minor differences and share a driver.
>
> I checked the datasheets and all devices share the same 2 modes which
> are Auto-PFM and Forced PWM mode.
>
> Since devices are all clones and share the same modes the binding part
> can be generic. I plan to rename the header and its macros to use
> FAN53555 name and add this property to the binding:
>
> regulator-initial-mode:
> enum:
> [ 1, 2 ]
> description:
> Defined in
> include/dt-bindings/regulator/fcs,fan53555-regulator.h
>
> However the implementation I made in the driver is currently
> restricted to SYR82X. I could make it generic but I don't have access
> to the other devices to test it.
>
Old name of header file is fine, but please explain this in commit msg.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] dt-bindings: net: Add Maxio MAE0621A PHY
From: Krzysztof Kozlowski @ 2026-07-19 6:04 UTC (permalink / raw)
To: Liu Changjie, Andrew Lunn, Heiner Kallweit, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev
Cc: Russell King, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Luo Jie, Wolfram Sang, devicetree, linux-kernel
In-Reply-To: <MN0PR19MB6091F865EF7FE6AC1EE41C10ACC62@MN0PR19MB6091.namprd19.prod.outlook.com>
On 17/07/2026 05:44, Liu Changjie wrote:
> Document the MAE0621A PHY ID and its optional 125 MHz CLKOUT
> setting. Boards which do not provide the property retain the hardware
> strap or bootloader configuration.
>
> Only the 125 MHz setting is exposed because it is the only setting
> exercised on hardware.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 4/4] iio: flow: add Sensirion SLF3S liquid flow sensor driver
From: Krzysztof Kozlowski @ 2026-07-19 6:18 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Wadim Mueller, Krzysztof Kozlowski, Rob Herring, Conor Dooley,
David Lechner, Nuno Sá, Andy Shevchenko, Maxwell Doose,
linux-iio, devicetree, linux-kernel, Marcelo Schmitt,
Rodrigo Alencar
In-Reply-To: <20260621145117.70b2d50e@jic23-huawei>
On 21/06/2026 15:51, Jonathan Cameron wrote:
> On Mon, 15 Jun 2026 06:27:00 +0200
> Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
>> On 14/06/2026 17:10, Jonathan Cameron wrote:
>>> On Sat, 13 Jun 2026 09:51:13 +0200
>>> Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>
>>>> On 12/06/2026 19:47, Jonathan Cameron wrote:
>>>>> On Thu, 11 Jun 2026 16:01:12 +0200
>>>>> Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>>>
>>>>>> On 11/06/2026 15:27, Wadim Mueller wrote:
>>>>>>> +
>>>>>>> +static const struct of_device_id slf3s_of_match[] = {
>>>>>>> + { .compatible = "sensirion,slf3s-0600f", .data = &slf3s_variants[0] },
>>>>>>> + { .compatible = "sensirion,slf3s-1300f", .data = &slf3s_variants[1] },
>>>>>>> + { .compatible = "sensirion,slf3s-4000b", .data = &slf3s_variants[2] },
>>>>>>
>>>>>> You should have only 1300f here and detect the variants. That was my
>>>>>> point when I suggested to use the fallback.
>>>>>>
>>>>>
>>>>> I'm lost. How does that work? They cannot fallback to that part because
>>>>> it relies on in driver detection of the fact that they are incompatible.
>>>>>
>>>>
>>>> I am lost too. Then why were they made compatible in the binding?
>>>>
>>>> Entire discussion was that these are FULLY compatible due to variant
>>>> detection. That was the entire point of discussing more generic
>>>> fallback. Using specific fallback does not change that - it is the same
>>>> concept.
>>>>
>>>> If devices are not detectable, why were we discussing any compatibility?
>>>
>>> They are detectable, but the feature set is not, so to me there is zero valid
>>> in a generic fallback, we have to update the driver every time a new part comes
>>> along. (i.e. I agree with Conor's reply to the previous version thread).
>>> A specific fallback to a completely compatible part would be fine as there
>>> would be sufficient info to not need the ID lookup.
>>
>> This patch has specific fallback and we discuss this now.
>>
>>>
>>> The case in the binding for this version is the worst of all options because
>>> it implies it is valid to fallback to something that gives a false impression
>>> of being specific when it's relying on ID matching to say actually it's something
>>> else.
>>>
>>> So definitely not
>>> + compatible:
>>> + oneOf:
>>> + - const: sensirion,slf3s-1300f
>>> + - items:
>>> + - enum:
>>> + - sensirion,slf3s-0600f
>>> + - sensirion,slf3s-4000b
>>> + - const: sensirion,slf3s-1300f
>>> +
>>>
>>> Falling back to slf3s is better than this, but I'd rather not have a fallback
>>> at all, thus allowing correct fallback to the parts listed here in future.
>>
>> Why? These devices are fully detectable thus fully compatible.
>
> Ok. We aren't really making progress. Let me layout the three approaches.
> + advantages and disadvantages as I understand it.
>
> What we have here:
> compatible:
> oneOf:
> - const: sensirion,slf3s-1300f
> - items:
> - enum:
> - sensirion,slf3s-0600f
> - sensirion,slf3s-4000b
> - const: sensirion,slf3s-1300f
>
> Advantages: Fallback to a real part.
> Disadvantages:
> - Requires a driver change even for drop in replacements (which will have
> different WHOAMI IDs.
> - To me it implies that a driver that supports slf3s-1300f should just
> work with parts we haven't seen yet if they have that in their fallback
> lists. I appreciate you think that we shouldn't put effort into supporting
> that case, but to me it seems more or less free to support and is useful.
>
> Generic compatible for fallback.
> compatible:
> - items:
> - enum:
> - sensirion,slf3s-0600f
> - sensirion,slf3s-1300f
> - sensirion,slf3s-4000b
> - const: sensirion,slf3s
>
> Advantages: Fallback to something that doesn't imply the post fix is coming from
> DT. So kind of hints we need detection code.
> Disadvantages: requires driver changes for each fully compatible drop in part.
> Note I'm not sure what this brings us over just having one compatible... Maybe
> we'll some day get a non detectable difference where we need to use the binding
> but seems fairly unlikely (I've seen that happen once when a manufacturer failed
> to update a WHOAMI reg value for a new part).
>
> No fallbacks
> compatible:
> enum:
> - sensirion,slf3s-0600f
> - sensirion,slf3s-1300f
> - sensirion,slf3s-4000b
>
> Advantages: (Common!) a future drop in compatible part works with old kernels
> as the driver knows a match + part information to use if the ID
> match fails.
> Disadvantages: Not sure I see any... However I'm guessing I'm missing something.
The same disadvantages as in other cases:
"Requires a driver change even for drop in replacements (which will have
different WHOAMI IDs."
But I think I get your main point - since we need to compare WHOAMI
registers for fallback cases, then there is no benefit of using the
fallback in the first place, so let's go with original approach.
>
> Note for this topic I think it would be great to capture some best practice
> information somewhere so we can improve consistency. I've looked around and
> there are some bits of feedback in numerous threads but those are hard to track
> down.
>
> The Dt spec refers to these as being about programming mode + driver selection.
> I will note that we have very broad families of devices that have a somewhat
> standard register interface + do always put the WHOAMI in the same place.
> In the vendor drivers those match a single hydra of a driver; upstream we
> have multiple drivers as devices do very different things and hence in
> practice almost no code would have been shared - so I have no idea what
> we should have done for those more commplex cases. Following your logic
> (I may have it wrong!) I think we would have had a generic compatible
> for the whole family but in upstream Linux no driver would have bound
> to that. I guess there are different extremes:
>
> 1) This case - register interfaces is consistent for all registers,
> we are just matching on constant tables needed to interpret the
> data in those tables.
Interpreting data in registers is the programming interface, therefore
the programming interface of that part is different. However since there
is reliable autodetection of a model, the programming interface is
considered compatible.
> 2) Similarish. Main register interface shared, but optional additional
> parts. If one device is a strict superset, a fallback is
> appropriate (in my view) but if I follow your points here then they
> should all have a single fallback compatible.
> 3) Not particularly similar, but still detectable in a consistent
> way. To me not appropriate to have a common fallback as based on
> the dt-spec thing about matching drivers, they will typically
> match different drivers. Maybe we should have a common fallback
> but typically not bind to it?
Unused common fallback rather suggests they are not compatible. The
purpose of the fallback is for SW to use. If it is not used, let's just
skip the fallback.
> 4) Detection code becomes a mess and is different for each part
> (see the old i2c_detect stuff) So hopefully no one thinks we
> should use a fallback once we reach
> this level of complexity (unless part are genuinely compatible)
Yes.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 2/4] dt-bindings: iio: flow: add Sensirion SLF3S liquid flow sensor
From: Krzysztof Kozlowski @ 2026-07-19 6:19 UTC (permalink / raw)
To: Wadim Mueller, Jonathan Cameron, Krzysztof Kozlowski, Rob Herring,
Conor Dooley, David Lechner, Nuno Sá, Andy Shevchenko,
Maxwell Doose
Cc: linux-iio, devicetree, linux-kernel, Marcelo Schmitt,
Rodrigo Alencar
In-Reply-To: <20260714085358.20842-3-wafgo01@gmail.com>
On 14/07/2026 10:53, Wadim Mueller wrote:
> Document the bindings for the Sensirion SLF3S family of digital
> liquid-flow sensors on I2C. The family currently covers the
> SLF3S-0600F, SLF3S-1300F and SLF3S-4000B variants.
>
> All variants share the same register map and are fully detectable
> from the product-information register at probe time, so
> sensirion,slf3s-1300f serves as the fallback compatible for the
> other variants.
>
> The active calibration medium (water / IPA) is runtime-switchable
> via the in_volumeflow_medium sysfs attribute and therefore not a
> DT property.
>
> Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> .../bindings/iio/flow/sensirion,slf3s.yaml | 58 +++++++++++++++++++
> MAINTAINERS | 7 +++
> 2 files changed, 65 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml b/Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml
> new file mode 100644
> index 000000000000..c054a505b75d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml
> @@ -0,0 +1,58 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/flow/sensirion,slf3s.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Sensirion SLF3S liquid flow sensor
> +
> +maintainers:
> + - Wadim Mueller <wafgo01@gmail.com>
> +
> +description:
> + Family of digital liquid-flow sensors from Sensirion with I2C interface. All
> + family members share the same register map; sub-types differ only in the flow
> + scale factor and the calibrated measurement range. The sub-type can be
> + identified from the product-information register.
> +
> +properties:
> + compatible:
> + oneOf:
> + - const: sensirion,slf3s-1300f
> + - items:
> + - enum:
> + - sensirion,slf3s-0600f
> + - sensirion,slf3s-4000b
> + - const: sensirion,slf3s-1300f
This is fine with me, also fine with separate non-compatible compatibles.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v10 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Krzysztof Kozlowski @ 2026-07-19 6:28 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Bryan O'Donoghue, Vladimir Zapolskiy, linux-arm-msm,
linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <20260718-x1e-csi2-phy-v10-1-5720a7888953@linaro.org>
On Sat, Jul 18, 2026 at 03:38:17AM +0100, Bryan O'Donoghue wrote:
> Add a base schema for the MIPI CSI2 PHYs on Qualcomm SoCs. This PHY
> supports both DPHY and CPHY operation. A special mode of DPHY operation -
> called variously split-mode or combo-mode also allows for two sensors to be
> connected to one PHY.
>
> The submitted binding here describes the DPHY modes of operation only. CPHY
> is left to future work.
>
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> ---
> .../bindings/phy/qcom,x1e80100-csi2-phy.yaml | 195 +++++++++++++++++++++
> 1 file changed, 195 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v7 1/2] dt-bindings: bridge: Add Lontium LT9611C(EX/UXD) MIPI DSI to HDMI driver
From: Krzysztof Kozlowski @ 2026-07-19 6:36 UTC (permalink / raw)
To: mohit.dsor
Cc: Sunyun Yang, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, dri-devel, devicetree, linux-kernel, venkata.valluru,
Jessica Zhang, Mohit Dsor
In-Reply-To: <20260716-lt9611c-v7-v7-1-7553a14735fc@oss.qualcomm.com>
On Thu, Jul 16, 2026 at 05:01:09PM +0530, mohit.dsor@oss.qualcomm.com wrote:
> From: Sunyun Yang <syyang@lontium.com>
>
> LT9611C(EX/UXD) is an I2C-controlled chip that Receiver signal/dual port
> mipi dsi and output hdmi, differences in hardware features:
> - LT9611C: supports 1-port mipi dsi to hdmi 1.4
So you need "if:then:" block disallowing port@1.
> - LT9611EX: supports 2-port mipi dsi to hdmi 1.4
> - LT9611UXD: supports 2-port mipi dsi to hdmi 1.4/2.0
>
> Signed-off-by: Sunyun Yang <syyang@lontium.com>
> Signed-off-by: Mohit Dsor <mdsor@oss.qualcomm.com>
> ---
> .../devicetree/bindings/display/bridge/lontium,lt9611.yaml | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> index 429a06057ae8..e0821a63d9d7 100644
> --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> @@ -4,19 +4,23 @@
> $id: http://devicetree.org/schemas/display/bridge/lontium,lt9611.yaml#
> $schema: http://devicetree.org/meta-schemas/core.yaml#
>
> -title: Lontium LT9611(UXC) 2 Port MIPI to HDMI Bridge
> +title: Lontium LT9611(UXC/C/EX/UXD) 2 Port MIPI DSI to HDMI Bridge
>
> maintainers:
> - Vinod Koul <vkoul@kernel.org>
>
> description: |
> - The LT9611 and LT9611UXC are bridge devices which convert DSI to HDMI
> + The LT9611、LT9611UXC、LT9611C、LT9611EX and LT9611UXD
These are some odd characters here. I guess this was in earlier versions
as well...
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 0/3] Add QMP PCIe multiple link-mode PHY support
From: Krzysztof Kozlowski @ 2026-07-19 6:43 UTC (permalink / raw)
To: Qiang Yu
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Manivannan Sadhasivam, Philipp Zabel,
Bjorn Andersson, Konrad Dybcio, linux-arm-msm, linux-phy,
devicetree, linux-kernel
In-Reply-To: <20260717-glymur_linkmode_0717-v5-0-4f9e87a61463@oss.qualcomm.com>
On Fri, Jul 17, 2026 at 02:58:32AM -0700, Qiang Yu wrote:
> Hi all,
>
> Some QMP PCIe PHY hardware blocks can be configured through a link-mode
> register into different link topologies, such as a single wide link, or
> multiple independent narrower links (e.g. x8 or x4+x4 mode on the Glymur
> PCIe3 PHY).
>
> Earlier revisions tried to extend the existing single-instance
> phy-qcom-qmp-pcie.c driver to cover this hardware. That added a large
> amount of conditional, multi-PHY logic to a driver whose data model
> assumes one PHY per node.
>
> This series adds a dedicated PHY provider driver,
> phy-qcom-qmp-pcie-multiphy.c:
>
> A single PHY provider node describes the shared hardware block. A new
> "qcom,link-mode" property points at the TCSR syscon register that reports
> the active topology; the driver reads it once at probe. #phy-cells = <1>
> lets consumers pass a logical PHY index to obtain their sub-PHY. Match
> data is indexed by link mode, and each link mode has its own array of
> per-PHY config tables, so one shared provider exposes a different set of
> logical PHYs depending on the active mode. The driver inherits the PHY
> settings and link mode already programmed by UEFI, so only the no-CSR
> reset is used, and no PHY setting tables or related structures are
> defined. Each sub-PHY owns its register regions and power domain, so in a
> bifurcated mode the links are brought up, and powered independently.
>
> The driver is implemented and validated on Glymur, and is intended to
> be extensible to other multi-mode QMP PCIe PHYs.
>
> This series depends on a prerequisite patch by Krzysztof Kozlowski:
> https://lore.kernel.org/r/20260420133616.88740-2-krzysztof.kozlowski@oss.qualcomm.com
There was a v2, still not applied I think:
https://lore.kernel.org/all/20260609141608.354186-2-krzysztof.kozlowski@oss.qualcomm.com/
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 1/3] dt-bindings: phy: qcom: Add Glymur QMP PCIe multiple link-mode PHY
From: Krzysztof Kozlowski @ 2026-07-19 6:50 UTC (permalink / raw)
To: Qiang Yu
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Manivannan Sadhasivam, Philipp Zabel,
Bjorn Andersson, Konrad Dybcio, linux-arm-msm, linux-phy,
devicetree, linux-kernel
In-Reply-To: <20260717-glymur_linkmode_0717-v5-1-4f9e87a61463@oss.qualcomm.com>
On Fri, Jul 17, 2026 at 02:58:33AM -0700, Qiang Yu wrote:
> diff --git a/Documentation/devicetree/bindings/phy/qcom,glymur-qmp-pcie-multiphy.yaml b/Documentation/devicetree/bindings/phy/qcom,glymur-qmp-pcie-multiphy.yaml
> new file mode 100644
> index 000000000000..73550f77e9b6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/qcom,glymur-qmp-pcie-multiphy.yaml
Filename: qcom,glymur-qmp-gen5x8-pcie-phy.yaml
> @@ -0,0 +1,176 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/qcom,glymur-qmp-pcie-multiphy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm QMP PCIe multiple link-mode PHY controller (PCIe, Glymur)
> +
> +maintainers:
> + - Qiang Yu <qiang.yu@oss.qualcomm.com>
> + - Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> +
> +description: |
> + The Glymur SoC uses a single PCIe Gen5 PHY hardware block for the
> + PCIe3a/PCIe3b controllers. This block supports two link modes, selected
> + at runtime via a TCSR syscon register:
> +
> + 1. x8 - a single 8-lane PHY instance is exposed (PCIe3a only)
> + 2. x4+x4 - two independent 4-lane PHY instances are exposed (PCIe3a and
> + PCIe3b)
> +
> + The node always describes both PHY instances ("port a" and "port b"),
> + regardless of which link mode is active on the board.
> +
> +properties:
> + compatible:
> + enum:
> + - qcom,glymur-qmp-gen5x8-pcie-phy
> +
> + reg:
> + minItems: 2
Dop
> + maxItems: 2
> +
> + reg-names:
> + items:
> + - const: port_a
> + - const: port_b
> +
> + clocks:
> + minItems: 10
Drop
> + maxItems: 10
> +
> + clock-names:
> + items:
> + - const: aux
> + - const: cfg_ahb
> + - const: ref
> + - const: rchng
> + - const: pipe
> + - const: phy_b_aux
> + - const: cfg_ahb_b
> + - const: rchng_b
> + - const: pipe_b
> + - const: pipediv2_b
> +
> + power-domains:
> + minItems: 2
Drop
> + maxItems: 2
> +
> + power-domain-names:
> + items:
> + - const: phy_a_gdsc
port_a
> + - const: phy_b_gdsc
port_b
> +
> + resets:
> + minItems: 4
Drop
> + maxItems: 4
> +
> + reset-names:
> + items:
> + - const: phy_a
port_a
> + - const: phy_a_nocsr
port_a_nocsr
etc.
> + - const: phy_b
> + - const: phy_b_nocsr
> +
> + vdda-phy-supply: true
> +
> + vdda-pll-supply: true
> +
> + vdda-refgen0p9-supply: true
> +
> + vdda-refgen1p2-supply: true
> +
> + qcom,link-mode:
> + description:
> + Reference to a register in the TCSR syscon that reports the link
> + mode the PCIe PHY is currently configured for, either a single x8
> + link or two independent x4 links. The link mode is programmed by
> + firmware before Linux boots; this property is only used to read
> + the active link mode, specified as a phandle to the syscon and
> + the register offset.
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + items:
> + - items:
> + - description: phandle of TCSR syscon
> + - description: offset of link mode register
> +
> + "#clock-cells":
> + const: 1
> +
> + clock-output-names:
> + items:
> + - description: Name of the PHY A pipe clock output.
> + - description: Name of the PHY B pipe clock output.
> +
> + "#phy-cells":
> + const: 1
You should explain in description the meaning of cell value. Or provide
filename of header with constants.
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - clock-names
> + - power-domains
> + - power-domain-names
> + - resets
> + - reset-names
> + - vdda-phy-supply
> + - vdda-pll-supply
> + - vdda-refgen0p9-supply
> + - vdda-refgen1p2-supply
> + - qcom,link-mode
> + - "#clock-cells"
> + - clock-output-names
> + - "#phy-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/qcom,glymur-gcc.h>
> + #include <dt-bindings/clock/qcom,glymur-tcsr.h>
> +
> + pcie3_phy: phy@f00000 {
Drop unused label.
The old 5x4 glymur compatible could be deprecated as well, but fine for
me without doing so.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 01/17] spi: dt-bindings: add spi-max-post-config-frequency-hz property
From: Krzysztof Kozlowski @ 2026-07-19 6:53 UTC (permalink / raw)
To: Santhosh Kumar K
Cc: broonie, robh, krzk+dt, conor+dt, miquel.raynal, richard,
vigneshr, pratyush, mwalle, takahiro.kuwano, linux-spi,
devicetree, linux-kernel, linux-mtd, praneeth, u-kumar1, a-dutta,
Conor Dooley
In-Reply-To: <20260717185116.2065505-2-s-k6@ti.com>
On Sat, Jul 18, 2026 at 12:21:00AM +0530, Santhosh Kumar K wrote:
> Add spi-max-post-config-frequency-hz, a generic property for SPI
> peripherals that operate at two distinct clock rates: a conservative
> rate always reachable without controller configuration, and a higher
> rate achievable only after controller-side configuration.
>
> When both properties are present, spi-max-frequency gives the
> conservative pre-configuration rate and spi-max-post-config-frequency-hz
> gives the higher post-configuration target.
>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Santhosh Kumar K <s-k6@ti.com>
> ---
> .../devicetree/bindings/spi/spi-peripheral-props.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
> index 880a9f624566..12211f8c9f7d 100644
> --- a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
> +++ b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
> @@ -45,6 +45,11 @@ properties:
> description:
> Maximum SPI clocking speed of the device in Hz.
>
> + spi-max-post-config-frequency-hz:
> + description:
> + Maximum SPI clock frequency in Hz achievable after controller-side
> + configuration.
How did you implement my feedback?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 02/17] spi: dt-bindings: add spi-phy-pattern-partition property
From: Krzysztof Kozlowski @ 2026-07-19 6:54 UTC (permalink / raw)
To: Santhosh Kumar K
Cc: broonie, robh, krzk+dt, conor+dt, miquel.raynal, richard,
vigneshr, pratyush, mwalle, takahiro.kuwano, linux-spi,
devicetree, linux-kernel, linux-mtd, praneeth, u-kumar1, a-dutta
In-Reply-To: <20260717185116.2065505-3-s-k6@ti.com>
On Sat, Jul 18, 2026 at 12:21:01AM +0530, Santhosh Kumar K wrote:
> Add spi-phy-pattern-partition, a per-device phandle property on the
> flash sub-node that allows the DT author to directly reference the
> partition holding the SPI PHY tuning pattern. Used to locate the
> pattern data during PHY tuning when the device cannot load the
> pattern dynamically.
>
> PHY tuning works by reading a known data pattern from the device
> repeatedly while sweeping controller delay parameters until the
> capture window is stable. For SPI NAND, the driver loads the pattern
> into the page cache once using write-to-cache opcodes, then reads it
> during the sweep. SPI NOR devices have no equivalent opcode, so the
> pattern must be pre-programmed in a dedicated flash partition. One
> partition per device is required to keep the procedure unambiguous
> when multiple devices share a bus.
>
> Signed-off-by: Santhosh Kumar K <s-k6@ti.com>
> ---
> .../devicetree/bindings/spi/cdns,qspi-nor.yaml | 17 +++++++++++++++++
> .../bindings/spi/spi-peripheral-props.yaml | 7 +++++++
> 2 files changed, 24 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 4/4] arm64: dts: rockchip: enable HDMI RX audio capture on Orange Pi 5 Plus
From: Igor Paunovic @ 2026-07-19 7:12 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Dmitry Osipenko, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, linux-media,
linux-rockchip, linux-arm-kernel, kernel, devicetree,
linux-kernel
In-Reply-To: <alwKdkNsMi9L4ZiY@venus>
Hi Sebastian,
Thanks -- both make sense and both are done for v4:
The card is renamed to "RK3588 HDMI-IN".
The card definition moved into rk3588-extra.dtsi as
hdmi_receiver_sound, disabled by default, mirroring the hdmi1_sound
node that already lives in that file -- and the Orange Pi 5 Plus dts
now only flips it (and i2s7_8ch) to "okay".
I'll hold v4 until Dmitry's testing round on the driver side so
everything lands in one respin.
Igor
On Sun, Jul 19, 2026 at 1:32 AM Sebastian Reichel
<sebastian.reichel@collabora.com> wrote:
>
> Hi,
>
> On Sat, Jul 18, 2026 at 10:57:28AM +0200, Igor Paunovic wrote:
> > Route the HDMI receiver audio to i2s7_8ch, the receive-only I2S
> > interface dedicated to HDMI RX, through a simple-audio-card with the
> > receiver as bitclock and frame master. Together with the audio
> > capture support in the snps_hdmirx driver this exposes a capture-only
> > ALSA card fed by the HDMI input.
> >
> > Tested on the Orange Pi 5 Plus with multiple HDMI sources: capture
> > follows the source sample rate and stays in sync via the FIFO-level
> > clock tracking in the driver.
> >
> > Signed-off-by: Igor Paunovic <royalnet026@gmail.com>
> > ---
> > New in v3.
> >
> > .../dts/rockchip/rk3588-orangepi-5-plus.dts | 20 +++++++++++++++++++
> > 1 file changed, 20 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
> > index 9950d11..d5840e1 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
> > +++ b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
> > @@ -37,6 +37,22 @@
> > };
> > };
> >
> > + hdmiin-sound {
> > + compatible = "simple-audio-card";
> > + simple-audio-card,name = "rockchip,hdmiin";
>
> The name is exposed to userspace and visible to the user (e.g.
> in alsamixer), but also used by Alsa UCM2. I suggest to use
> "RK3588 HDMI-IN".
>
> > + simple-audio-card,format = "i2s";
> > + simple-audio-card,bitclock-master = <&hdmiin_codec>;
> > + simple-audio-card,frame-master = <&hdmiin_codec>;
> > +
> > + simple-audio-card,cpu {
> > + sound-dai = <&i2s7_8ch>;
> > + };
> > +
> > + hdmiin_codec: simple-audio-card,codec {
> > + sound-dai = <&hdmi_receiver 0>;
> > + };
> > + };
> > +
>
> Move the whole card definition to rk3588-extra.dtsi with a new label
> (e.g. hdmi_receiver_sound) and add status = "disabled"; Then just do
>
> &hdmi_receiver_sound {
> status = "okay";
> };
>
> in the Orange Pi 5+ DT, i.e. just like the soundcards for HDMI
> output. This reduces a lot of duplication as the soundcard is the
> same on all boards considering there is a dedicated I2S channel for
> it. It's disabled by default as some boards do not route the HDMI
> receiver at all.
>
> Greetings,
>
> -- Sebastian
>
> > ir-receiver {
> > compatible = "gpio-ir-receiver";
> > gpios = <&gpio4 RK_PB3 GPIO_ACTIVE_LOW>;
> > @@ -247,6 +263,10 @@
> > status = "okay";
> > };
> >
> > +&i2s7_8ch {
> > + status = "okay";
> > +};
> > +
> > &led_blue_gpio {
> > gpios = <&gpio3 RK_PA6 GPIO_ACTIVE_HIGH>;
> > status = "okay";
> > --
> > 2.53.0
> >
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: usb: Add ITE IT8851/IT8853 Type-C PD controllers
From: Krzysztof Kozlowski @ 2026-07-19 7:37 UTC (permalink / raw)
To: Amber Kao
Cc: Jeson Yang, Yaode Fang, Greg Kroah-Hartman, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heikki Krogerus, linux-usb,
devicetree, linux-kernel, Bling Chiang, Eric Su, Doreen Lin
In-Reply-To: <20260717-ucsi-itepd-v4-1-f3ba5addd0df@ite.com.tw>
On Fri, Jul 17, 2026 at 05:59:49PM +0800, Amber Kao wrote:
> +description:
> + The ITE IT8851 is an I2C-based USB Type-C Power Delivery (PD) controller
> + supporting one Type-C port.
> + The IT8853 is the two-port variant sharing the same programming interface.
> +
> +properties:
> + compatible:
> + enum:
> + - ite,it8851
> + - ite,it8853
According to your driver code, these are fully compatible, so why aren't
the compatibility expressed with the fallback?
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + wakeup-source: true
> +
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 0
> +
> +patternProperties:
> + "^connector@[01]$":
Keep consistent quotes, either ' or "
> + $ref: /schemas/connector/usb-connector.yaml#
> + unevaluatedProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
You also need:
anyOf:
- required:
- connector@0
- required:
- connector@1
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: sound: add Texas Instruments TAS2557
From: Krzysztof Kozlowski @ 2026-07-19 8:33 UTC (permalink / raw)
To: Gianluca Boiano
Cc: Mark Brown, Liam Girdwood, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jaroslav Kysela, Takashi Iwai, Shenghao Ding,
Kevin Lu, Baojun Xu, Wang, Sen, linux-sound, devicetree,
linux-kernel
In-Reply-To: <20260717233402.414326-2-morf3089@gmail.com>
On Sat, Jul 18, 2026 at 01:33:59AM +0200, Gianluca Boiano wrote:
> Document the TAS2557 mono Class-D smart amplifier with an integrated
> DSP for speaker protection. The device is controlled over I2C and
> receives audio over I2S/TDM (ASI). One node can describe either a
> single mono device or, via a two-entry `reg`, a stereo pair sharing
> one bus: the physical device at each `reg` index applies that half
> (DEV_A/DEV_B) of a stereo-tuned firmware image, so no separate
> channel-selection property is needed -- device order in `reg` is
> the only configuration required, matching the convention already
> used by ti,tas2781.yaml/ti,tas2563.yaml for the same TI firmware
> toolchain. `ti,imon-slot-nos`/`ti,vmon-slot-nos` follow the same
> per-index convention for the TDM sense-data slots. `reg` is capped
> at two entries because the uCDSP firmware container only defines
> mono or two-device (DEV_A/DEV_B) types -- there is no third slot to
> extend into regardless of DT shape.
>
> The on-chip DSP boots from a firmware image generated per speaker
> design with the TI PurePath Console tuning tools; the optional
> firmware-name property selects a board-specific image, shared by
> every device in the group.
>
> Addresses review from Krzysztof Kozlowski, who questioned a
> per-node channel-selection property (an earlier ti,channel/
> ti,audio-channel design) on the grounds that it doesn't scale and
> isn't how other multi-device TI amplifiers in-tree solve the same
> problem.
This paragraph does not look useful in commit log. This is part of
changelog rather.
>
> Signed-off-by: Gianluca Boiano <morf3089@gmail.com>
> ---
> Changes in v3:
> - single-node reg-array model (up to two devices), matching
> ti,tas2781.yaml; drop ti,channel, derive DEV_A/DEV_B from reg order
> - rename ti,imon-slot-no/ti,vmon-slot-no to the plural
> ti,imon-slot-nos/ti,vmon-slot-nos arrays; firmware-name maxItems: 1
>
> Changes in v2:
> - add the four mandatory supplies to "required" (Wang Sen)
>
> .../devicetree/bindings/sound/ti,tas2557.yaml | 174 ++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 175 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 3/3] device property: add test cases for fwnode_for_each_child_node()
From: Andy Shevchenko @ 2026-07-19 8:37 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Xu Yang, linux-acpi, driver-core, linux-kernel, Daniel Scally,
Heikki Krogerus, Sakari Ailus, Greg Kroah-Hartman,
Rafael J. Wysocki, Rob Herring, Saravana Kannan, devicetree
In-Reply-To: <DK1RFV9AABBD.KP0VPMWKFYWM@kernel.org>
On Sat, Jul 18, 2026 at 04:18:12PM +0200, Danilo Krummrich wrote:
> On Thu Jun 11, 2026 at 10:31 PM CEST, Andy Shevchenko wrote:
> >
> > Add test cases for fwnode_for_each_child_node() API.
> >
> > Test command:
> > $ ./tools/testing/kunit/kunit.py run property-entry
> >
> > Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> This patch broke the build [1], hence I dropped it from the queue (but kept the
> first two patches of this series).
>
> of_node_init() can't be used from modules, either it needs EXPORT_SYMBOL_GPL()
> itself, or of_node_ktype needs to be exported for this kunit test to work.
Oh, thanks for pointing out.
> [1] https://lore.kernel.org/all/202607181651.RnUuV8n6-lkp@intel.com/
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v8 2/8] iio: dac: ad5686: missing NULL check on match data
From: Andy Shevchenko @ 2026-07-19 8:50 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Rodrigo Alencar, Michael Auchter, linux, linux-iio, devicetree,
linux-kernel, linux-hardening, Michael Hennerich, David Lechner,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Kees Cook, Gustavo A. R. Silva, sashiko-bot
In-Reply-To: <20260719005533.41520a27@jic23-huawei>
On Sun, Jul 19, 2026 at 12:55:44AM +0100, Jonathan Cameron wrote:
> On Fri, 17 Jul 2026 13:28:52 +0300
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
...
> I applied the following rather than going for a v9 for just this:
Thanks!
> Shout if I messed it up.
...
> + if (!chip_info)
> + return -ENODEV;
Perhaps stick with -ENODATA? (Maybe in a separate change, dunno...)
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 1/4] dt-bindings: media: snps,dw-hdmi-rx: add #sound-dai-cells
From: Krzysztof Kozlowski @ 2026-07-19 8:54 UTC (permalink / raw)
To: Igor Paunovic
Cc: Dmitry Osipenko, Mauro Carvalho Chehab, Sebastian Reichel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
linux-media, linux-rockchip, linux-arm-kernel, kernel, devicetree,
linux-kernel
In-Reply-To: <20260718085728.6797-2-royalnet026@gmail.com>
On Sat, Jul 18, 2026 at 10:57:25AM +0200, Igor Paunovic wrote:
> diff --git a/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
> index b7f6c87..fa6cd0d 100644
> --- a/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
> +++ b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
> @@ -78,6 +78,13 @@ properties:
> The phandle of the syscon node for the Video Output GRF register
> to enable EDID transfer through SDAIN and SCLIN.
>
> + "#sound-dai-cells":
> + const: 1
> + description:
> + The HDMI RX controller has two digital audio interfaces, one for
> + I2S and one for S/PDIF. The DAI cell selects the interface, 0 for
> + I2S and 1 for S/PDIF.
> +
Schema should also reference dai-common.yaml and use
"unevaluatedProperties: false".
> required:
> - compatible
> - reg
> @@ -129,4 +136,6 @@ examples:
> pinctrl-0 = <&hdmim1_rx_cec &hdmim1_rx_hpdin &hdmim1_rx_scl &hdmim1_rx_sda &hdmirx_5v_detection>;
> pinctrl-names = "default";
> hpd-gpios = <&gpio1 22 GPIO_ACTIVE_LOW>;
> + /* referenced by a sound card as <&hdmi_receiver 0> (0: I2S, 1: S/PDIF) */
Drop comment, not needed. Consumer is not really relevant.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 0/2] Introduce Lenovo Legion Y700 Gen4
From: Pengyu Luo @ 2026-07-19 9:32 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: inux-arm-msm, devicetree, linux-kernel, guf296, Pengyu Luo
Add an initial devicetree for the Lenovo Legion Y700 Gen4, which is
based on sm8750-qrd.
Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
---
Pengyu Luo (2):
dt-bindings: arm: qcom: Document Lenovo Legion Y700 Gen4
arm64: dts: qcom: sm8750: Add Lenovo Legion Y700 Gen4
.../devicetree/bindings/arm/qcom.yaml | 1 +
arch/arm64/boot/dts/qcom/Makefile | 1 +
.../boot/dts/qcom/sm8750-lenovo-elden.dts | 1097 +++++++++++++++++
3 files changed, 1099 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/sm8750-lenovo-elden.dts
--
2.54.0
^ permalink raw reply
* [PATCH 1/2] dt-bindings: arm: qcom: Document Lenovo Legion Y700 Gen4
From: Pengyu Luo @ 2026-07-19 9:32 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: inux-arm-msm, devicetree, linux-kernel, guf296, Pengyu Luo
In-Reply-To: <20260719093226.197740-1-mitltlatltl@gmail.com>
Add compatible for the SM8750-based Lenovo Legion Y700 Gen4, using its
codename, elden.
Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
---
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index c7c9a9279684..e1ade271e712 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -1160,6 +1160,7 @@ properties:
- items:
- enum:
+ - lenovo,elden
- qcom,sm8750-mtp
- qcom,sm8750-qrd
- const: qcom,sm8750
--
2.54.0
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: qcom: sm8750: Add Lenovo Legion Y700 Gen4
From: Pengyu Luo @ 2026-07-19 9:32 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: inux-arm-msm, devicetree, linux-kernel, guf296, Pengyu Luo
In-Reply-To: <20260719093226.197740-1-mitltlatltl@gmail.com>
Add an initial devicetree for the Lenovo Legion Y700 Gen4, which is
based on sm8750-qrd.
Supported features:
- Altmode
- Backlight
- Battery & Charge (Full speed)
- Buttons
- Framebuffer (Require mdss and dispcc to be disabled)
- USB (Two ports)
Downstream supported features:
- Display (8/10 bits) (Pending [1])
- GPU
- Touchscreen
Unsupported features:
- BT & WIFI
- Cameras & Flash
- Microphones & Speakers (Downstream available, pending test [2])
- Sensors (Downstream available, pending test [3])
- Vibrators (Downstream available, pending test [2])
[1]: https://lore.kernel.org/dri-devel/20260709142846.12463-1-mitltlatltl@gmail.com
[2]: https://github.com/GUF296/linux/commits/codex/tb321fu-full-remediation-20260715
[3]: https://github.com/linux-msm/hexagonrpc
Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
.../boot/dts/qcom/sm8750-lenovo-elden.dts | 1097 +++++++++++++++++
2 files changed, 1098 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/sm8750-lenovo-elden.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index e05414290d8e..cb93708e0415 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -405,6 +405,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sm8650-hdk-rear-camera-card.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8650-hdk.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8650-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8650-qrd.dtb
+dtb-$(CONFIG_ARCH_QCOM) += sm8750-lenovo-elden.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8750-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8750-qrd.dtb
dtb-$(CONFIG_ARCH_QCOM) += talos-evk.dtb
diff --git a/arch/arm64/boot/dts/qcom/sm8750-lenovo-elden.dts b/arch/arm64/boot/dts/qcom/sm8750-lenovo-elden.dts
new file mode 100644
index 000000000000..c67c00ea45a0
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sm8750-lenovo-elden.dts
@@ -0,0 +1,1096 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
+ * Copyright (c) 2025-2026 Pengyu Luo <mitltlatltl@gmail.com>
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/phy/phy.h>
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+#include "sm8750.dtsi"
+#include "pm8550.dtsi"
+#define PMK8550VE_SID 8
+#include "pm8550ve.dtsi"
+#include "pmih0108.dtsi"
+#include "pmk8550.dtsi"
+#include "sm8750-pmics.dtsi"
+
+/ {
+ model = "Lenovo Legion Y700 Gen4";
+ compatible = "lenovo,elden", "qcom,sm8750";
+ chassis-type = "tablet";
+
+ aliases {
+ i2c5 = &i2c5;
+ i2c6 = &i2c6;
+ i2c9 = &i2c9;
+ i2c10 = &i2c10;
+ serial1 = &uart14;
+ };
+
+ /* mandatory, ABL requires the chosen node to boot */
+ chosen {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ framebuffer: framebuffer@fc800000 {
+ compatible = "simple-framebuffer";
+ reg = <0x0 0xfc800000 0x0 0x2b00000>;
+ width = <1904>;
+ height = <3040>;
+ stride = <(1904 * 4)>;
+ format = "a8r8g8b8";
+ };
+ };
+
+ clocks {
+ xo_board: xo-board {
+ compatible = "fixed-clock";
+ clock-frequency = <76800000>;
+ #clock-cells = <0>;
+ };
+
+ sleep_clk: sleep-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <32000>;
+ #clock-cells = <0>;
+ };
+
+ bi_tcxo_div2: bi-tcxo-div2-clk {
+ compatible = "fixed-factor-clock";
+ #clock-cells = <0>;
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ clock-mult = <1>;
+ clock-div = <2>;
+ };
+
+ bi_tcxo_ao_div2: bi-tcxo-ao-div2-clk {
+ compatible = "fixed-factor-clock";
+ #clock-cells = <0>;
+
+ clocks = <&rpmhcc RPMH_CXO_CLK_A>;
+ clock-mult = <1>;
+ clock-div = <2>;
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ pinctrl-0 = <&volume_up_n>;
+ pinctrl-names = "default";
+
+ key-volume-up {
+ label = "Volume Up";
+ linux,code = <KEY_VOLUMEUP>;
+ gpios = <&pm8550_gpios 6 GPIO_ACTIVE_LOW>;
+ debounce-interval = <15>;
+ linux,can-disable;
+ wakeup-source;
+ };
+ };
+
+ pmic-glink {
+ compatible = "qcom,sm8750-pmic-glink",
+ "qcom,sm8550-pmic-glink",
+ "qcom,pmic-glink";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ orientation-gpios = <&tlmm 61 GPIO_ACTIVE_HIGH>;
+
+ /* Long edge */
+ connector@0 {
+ compatible = "usb-c-connector";
+ reg = <0>;
+
+ power-role = "dual";
+ data-role = "dual";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ pmic_glink_hs_in: endpoint {
+ remote-endpoint = <&usb_dwc3_hs>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ pmic_glink_ss_in: endpoint {
+ remote-endpoint = <&usb_dp_qmpphy_out>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ pmic_glink_sbu: endpoint {
+ remote-endpoint = <&fsa4480_sbu_mux>;
+ };
+ };
+ };
+ };
+
+ /* Short edge */
+ connector@1 {
+ compatible = "usb-c-connector";
+ reg = <1>;
+
+ power-role = "dual";
+ data-role = "dual";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ pmic_glink_hs_c2_in: endpoint {
+ remote-endpoint = <&usb_dwc3_hs2>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ pmic_glink_hs_sbu: endpoint {
+ remote-endpoint = <&fsa4480_hs_sbu_mux>;
+ };
+ };
+ };
+ };
+ };
+
+ reserved-memory {
+ /*
+ * Use this to tell the BL to initialize the display related
+ * resources, so we can use efifb. Please 's/-/_/'
+ */
+ splash-region {
+ reg = <0 0xfc800000 0 0x2b00000>;
+ no-map;
+ };
+ };
+
+ vph_pwr: vph-pwr-regulator {
+ compatible = "regulator-fixed";
+
+ regulator-name = "vph_pwr";
+ regulator-min-microvolt = <3700000>;
+ regulator-max-microvolt = <3700000>;
+
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vreg_iovdd_1p8: regulator-dsi-1p8 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "vreg_iovdd_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ gpio = <&tlmm 161 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&iovdd_reg_en>;
+ pinctrl-names = "default";
+
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vreg_vsp_6p1: regulator-vsp-6p1 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "vreg_vsp_6p1";
+ regulator-min-microvolt = <6100000>;
+ regulator-max-microvolt = <6100000>;
+
+ gpio = <&tlmm 72 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&vsp_reg_en>;
+ pinctrl-names = "default";
+
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vreg_vsn_5p8: regulator-vsn-5p8 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "vreg_vsn_5p8";
+ regulator-min-microvolt = <5800000>;
+ regulator-max-microvolt = <5800000>;
+
+ gpio = <&tlmm 73 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&vsn_reg_en>;
+ pinctrl-names = "default";
+
+ regulator-always-on;
+ regulator-boot-on;
+ };
+};
+
+&apps_rsc {
+ regulators-0 {
+ compatible = "qcom,pm8550-rpmh-regulators";
+
+ vdd-bob1-supply = <&vph_pwr>;
+ vdd-bob2-supply = <&vph_pwr>;
+ vdd-l1-l4-l10-supply = <&vreg_s3g_1p8>;
+ vdd-l2-l13-l14-supply = <&vreg_bob1>;
+ vdd-l3-supply = <&vreg_s7i_1p2>;
+ vdd-l5-l16-supply = <&vreg_bob1>;
+ vdd-l6-l7-supply = <&vreg_bob1>;
+ vdd-l8-l9-supply = <&vreg_bob1>;
+ vdd-l11-supply = <&vreg_s7i_1p2>;
+ vdd-l12-supply = <&vreg_s3g_1p8>;
+ vdd-l15-supply = <&vreg_s3g_1p8>;
+ vdd-l17-supply = <&vreg_bob2>;
+
+ qcom,pmic-id = "b";
+
+ vreg_bob1: bob1 {
+ regulator-name = "vreg_bob1";
+ regulator-min-microvolt = <3008000>;
+ regulator-max-microvolt = <4000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_bob2: bob2 {
+ regulator-name = "vreg_bob2";
+ regulator-min-microvolt = <2704000>;
+ regulator-max-microvolt = <3008000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l1b_1p8: ldo1 {
+ regulator-name = "vreg_l1b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2b_3p0: ldo2 {
+ regulator-name = "vreg_l2b_3p0";
+ regulator-min-microvolt = <3008000>;
+ regulator-max-microvolt = <3048000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l4b_1p8: ldo4 {
+ regulator-name = "vreg_l4b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l5b_3p1: ldo5 {
+ regulator-name = "vreg_l5b_3p1";
+ regulator-min-microvolt = <3100000>;
+ regulator-max-microvolt = <3148000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l6b_1p8: ldo6 {
+ regulator-name = "vreg_l6b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3008000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7b_1p8: ldo7 {
+ regulator-name = "vreg_l7b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3008000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l8b_1p8: ldo8 {
+ regulator-name = "vreg_l8b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3008000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l9b_2p9: ldo9 {
+ regulator-name = "vreg_l9b_2p9";
+ regulator-min-microvolt = <2960000>;
+ regulator-max-microvolt = <3008000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l10b_1p8: ldo10 {
+ regulator-name = "vreg_l10b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l14b_3p2: ldo14 {
+ regulator-name = "vreg_l14b_3p2";
+ regulator-min-microvolt = <3200000>;
+ regulator-max-microvolt = <3200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l15b_1p8: ldo15 {
+ regulator-name = "vreg_l15b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l16b_2p8: ldo16 {
+ regulator-name = "vreg_l16b_2p8";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l17b_2p5: ldo17 {
+ regulator-name = "vreg_l17b_2p5";
+ regulator-min-microvolt = <2504000>;
+ regulator-max-microvolt = <2504000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-1 {
+ compatible = "qcom,pm8550ve-rpmh-regulators";
+
+ vdd-l1-supply = <&vreg_s7i_1p2>;
+ vdd-l2-supply = <&vreg_s1d_0p97>;
+ vdd-l3-supply = <&vreg_s1d_0p97>;
+ vdd-s1-supply = <&vph_pwr>;
+ vdd-s3-supply = <&vph_pwr>;
+ vdd-s4-supply = <&vph_pwr>;
+
+ qcom,pmic-id = "d";
+
+ vreg_s1d_0p97: smps1 {
+ regulator-name = "vreg_s1d_0p97";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s3d_1p2: smps3 {
+ regulator-name = "vreg_s3d_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s4d_0p85: smps4 {
+ regulator-name = "vreg_s4d_0p85";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1036000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l1d_1p2: ldo1 {
+ regulator-name = "vreg_l1d_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2d_0p88: ldo2 {
+ regulator-name = "vreg_l2d_0p88";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3d_0p88: ldo3 {
+ regulator-name = "vreg_l3d_0p88";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <920000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-2 {
+ compatible = "qcom,pm8550ve-rpmh-regulators";
+
+ vdd-l1-supply = <&vreg_s1d_0p97>;
+ vdd-l2-supply = <&vreg_s7i_1p2>;
+ vdd-l3-supply = <&vreg_s3g_1p8>;
+ vdd-s5-supply = <&vph_pwr>;
+
+ qcom,pmic-id = "f";
+
+ vreg_s5f_0p5: smps5 {
+ regulator-name = "vreg_s5f_0p5";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l1f_0p88: ldo1 {
+ regulator-name = "vreg_l1f_0p88";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <920000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2f_1p2: ldo2 {
+ regulator-name = "vreg_l2f_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3f_1p8: ldo3 {
+ regulator-name = "vreg_l3f_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ };
+
+ regulators-3 {
+ compatible = "qcom,pm8550ve-rpmh-regulators";
+
+ vdd-l1-supply = <&vreg_s1d_0p97>;
+ vdd-l2-supply = <&vreg_s3g_1p8>;
+ vdd-l3-supply = <&vreg_s7i_1p2>;
+ vdd-s1-supply = <&vph_pwr>;
+ vdd-s3-supply = <&vph_pwr>;
+
+ qcom,pmic-id = "g";
+
+ vreg_s1g_0p5: smps1 {
+ regulator-name = "vreg_s1g_0p5";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <700000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s3g_1p8: smps3 {
+ regulator-name = "vreg_s3g_1p8";
+ regulator-min-microvolt = <1856000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_LPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s4g_0p75: smps4 {
+ regulator-name = "vreg_s4g_0p75";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <900000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l1g_0p91: ldo1 {
+ regulator-name = "vreg_l1g_0p91";
+ regulator-min-microvolt = <912000>;
+ regulator-max-microvolt = <936000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2g_1p8: ldo2 {
+ regulator-name = "vreg_l2g_1p8";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1860000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3g_1p2: ldo3 {
+ regulator-name = "vreg_l3g_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1256000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-4 {
+ compatible = "qcom,pm8550ve-rpmh-regulators";
+
+ vdd-l1-supply = <&vreg_s7i_1p2>;
+ vdd-l2-supply = <&vreg_s7i_1p2>;
+ vdd-l3-supply = <&vreg_s1d_0p97>;
+ vdd-s7-supply = <&vph_pwr>;
+ vdd-s8-supply = <&vph_pwr>;
+
+ qcom,pmic-id = "i";
+
+ vreg_s7i_1p2: smps7 {
+ regulator-name = "vreg_s7i_1p2";
+ regulator-min-microvolt = <1224000>;
+ regulator-max-microvolt = <1340000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s8i_0p9: smps8 {
+ regulator-name = "vreg_s8i_0p9";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <972000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l1i_1p2: ldo1 {
+ regulator-name = "vreg_l1i_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2i_1p2: ldo2 {
+ regulator-name = "vreg_l2i_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3i_0p88: ldo3 {
+ regulator-name = "vreg_l3i_0p88";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-5 {
+ compatible = "qcom,pm8550vs-rpmh-regulators";
+
+ vdd-l1-supply = <&vreg_s1d_0p97>;
+ vdd-l2-supply = <&vreg_s7i_1p2>;
+ vdd-s2-supply = <&vph_pwr>;
+ vdd-s3-supply = <&vph_pwr>;
+
+ qcom,pmic-id = "j";
+
+ vreg_s2j_1p1: smps2 {
+ regulator-name = "vreg_s2j_1p1";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s3j_1p1: smps3 {
+ regulator-name = "vreg_s3j_1p1";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l1j_0p91: ldo1 {
+ regulator-name = "vreg_l1j_0p91";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <920000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2j_1p2: ldo2 {
+ regulator-name = "vreg_l2j_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+};
+
+&gpi_dma1 {
+ status = "okay";
+};
+
+&gpi_dma2 {
+ status = "okay";
+};
+
+&i2c5 {
+ status = "okay";
+
+ typec-mux@42 {
+ compatible = "fcs,fsa4480";
+ reg = <0x42>;
+
+ vcc-supply = <&vreg_bob1>;
+
+ mode-switch;
+ orientation-switch;
+
+ port {
+ fsa4480_hs_sbu_mux: endpoint {
+ remote-endpoint = <&pmic_glink_hs_sbu>;
+ };
+ };
+ };
+
+ typec-mux@43 {
+ compatible = "fcs,fsa4480";
+ reg = <0x43>;
+
+ vcc-supply = <&vreg_bob1>;
+
+ mode-switch;
+ orientation-switch;
+
+ port {
+ fsa4480_sbu_mux: endpoint {
+ remote-endpoint = <&pmic_glink_sbu>;
+ };
+ };
+ };
+
+ eusb_repeater: redriver@4f {
+ compatible = "nxp,ptn3222"; /* PTN3222DUK */
+ reg = <0x4f>;
+ #phy-cells = <0>;
+
+ vdd3v3-supply = <&vreg_l5b_3p1>;
+ vdd1v8-supply = <&vreg_l15b_1p8>;
+
+ reset-gpios = <&pm8550ve_gpios 6 GPIO_ACTIVE_LOW>;
+
+ pinctrl-0 = <&eusb_reset_n>, <&eusb_mux_default>;
+ pinctrl-names = "default";
+ };
+};
+
+&i2c6 {
+ status = "okay";
+
+ /* haptic_hv_l@5a haptic_hv_r@5b */
+};
+
+&i2c9 {
+ status = "okay";
+
+ /* aw882xx_smartpa@34 @37 */
+};
+
+&i2c10 {
+ status = "okay";
+
+ /* i2c_wl2868c@2F */
+
+ /*
+ * bias@3e, as9702 or aw37504
+ *
+ * gpio72/gpio73: enable pin for OUTP/OUTN
+ * In practical, register programming is not required for as9702
+ *
+ * as9702: (REG02H[7:0]=0xf1)
+ * reg: 0x00 0x01 0x03
+ * val: 0x15 0x12 0x73
+ *
+ * aw37504: (REG04H[1:0]=0x01)
+ * reg: 0x00 0x01 0x03 0x04
+ * val: 0x15 0x12 0x43 0x09
+ */
+
+ backlight: backlight@76 {
+ compatible = "awinic,aw99706";
+ reg = <0x76>;
+
+ enable-gpio = <&tlmm 88 GPIO_ACTIVE_HIGH>;
+
+ pinctrl-0 = <&aw99706_bl_active>;
+ pinctrl-names = "default";
+
+ default-brightness = <511>;
+ max-brightness = <4095>;
+
+ awinic,dim-mode = <1>;
+ awinic,sw-freq-hz = <750000>;
+ awinic,sw-ilmt-microamp = <3000000>;
+ awinic,uvlo-thres-microvolt = <2200000>;
+ awinic,iled-max-microamp = <30000>;
+ awinic,ramp-ctl = <3>;
+ };
+};
+
+&mdss {
+ status = "okay";
+};
+
+&mdss_dp0 {
+ status = "okay";
+};
+
+&mdss_dp0_out {
+ remote-endpoint = <&usb_dp_qmpphy_dp_in>;
+};
+
+&mdss_dsi0 {
+ vdda-supply = <&vreg_l3g_1p2>;
+
+ qcom,dual-dsi-mode;
+ qcom,sync-dual-dsi;
+ qcom,master-dsi;
+
+ status = "okay";
+
+ /* panel: csot,pp8807hb1-1 */
+};
+
+&mdss_dsi0_phy {
+ vdds-supply = <&vreg_l3i_0p88>;
+ phy-type = <PHY_TYPE_CPHY>;
+
+ status = "okay";
+};
+
+&mdss_dsi1 {
+ /* Bonded DSI, source to dsi0_phy PLL */
+ clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE1_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK1_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC1_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&mdss_dsi0_phy DSI_PIXEL_PLL_CLK>,
+ <&mdss_dsi0_phy DSI_BYTE_PLL_CLK>,
+ <&dispcc DISP_CC_ESYNC1_CLK>,
+ <&dispcc DISP_CC_OSC_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE1_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK1_CLK_SRC>;
+
+ vdda-supply = <&vreg_l3g_1p2>;
+
+ qcom,dual-dsi-mode;
+ qcom,sync-dual-dsi;
+
+ status = "okay";
+};
+
+&mdss_dsi1_phy {
+ vdds-supply = <&vreg_l3i_0p88>;
+ phy-type = <PHY_TYPE_CPHY>;
+
+ status = "okay";
+};
+
+&pcie0 {
+ vdda-supply = <&vreg_l1f_0p88>;
+ vddpe-3v3-supply = <&vreg_l3g_1p2>;
+
+ pinctrl-0 = <&pcie0_default_state>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&pcie0_phy {
+ vdda-phy-supply = <&vreg_l1f_0p88>;
+ vdda-pll-supply = <&vreg_l3g_1p2>;
+
+ status = "okay";
+};
+
+&pcieport0 {
+ wake-gpios = <&tlmm 104 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&tlmm 102 GPIO_ACTIVE_LOW>;
+
+ /* WCN7861, id: pci17cb,110e */
+};
+
+&pm8550_gpios {
+ volume_up_n: volume-up-n-state {
+ pins = "gpio6";
+ function = "normal";
+ bias-pull-up;
+ input-enable;
+ power-source = <1>;
+ };
+};
+
+&pm8550ve_gpios {
+ eusb_reset_n: eusb-reset-n-state {
+ pins = "gpio6";
+ function = "normal";
+ bias-disable;
+ power-source = <1>;
+ qcom,drive-strength = <2>;
+ };
+};
+
+&pmih0108_eusb2_repeater {
+ vdd18-supply = <&vreg_l15b_1p8>;
+ vdd3-supply = <&vreg_l5b_3p1>;
+};
+
+&pon_pwrkey {
+ status = "okay";
+};
+
+&pon_resin {
+ linux,code = <KEY_VOLUMEDOWN>;
+
+ status = "okay";
+};
+
+&qupv3_1 {
+ status = "okay";
+};
+
+&qupv3_2 {
+ status = "okay";
+};
+
+&remoteproc_adsp {
+ firmware-name = "qcom/sm8750/LENOVO/elden/adsp.mbn",
+ "qcom/sm8750/LENOVO/elden/adsp_dtb.mbn";
+
+ status = "okay";
+};
+
+&remoteproc_cdsp {
+ firmware-name = "qcom/sm8750/LENOVO/elden/cdsp.mbn",
+ "qcom/sm8750/LENOVO/elden/cdsp_dtb.mbn";
+
+ status = "okay";
+};
+
+&spi4 {
+ status = "okay";
+
+ /* novatek@0 */
+};
+
+&sdhc_2 {
+ cd-gpios = <&tlmm 55 GPIO_ACTIVE_HIGH>;
+
+ vmmc-supply = <&vreg_l9b_2p9>;
+ vqmmc-supply = <&vreg_l8b_1p8>;
+
+ no-sdio;
+ no-mmc;
+
+ pinctrl-0 = <&sdc2_default &sdc2_card_det_n>;
+ pinctrl-1 = <&sdc2_sleep &sdc2_card_det_n>;
+ pinctrl-names = "default", "sleep";
+
+ status = "okay";
+};
+
+&tlmm {
+ /* For CDT: <32 3> <37 2> <77 1>; */
+ /* reserved for secure world */
+ gpio-reserved-ranges = <39 1>, <74 1>;
+
+ aw99706_bl_active: aw99706-bl-active-state {
+ pins = "gpio88";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-disable;
+ };
+
+ eusb_mux_default: eusb-mux-default-state {
+ pins = "gpio29";
+ function = "gpio";
+ drive-strength = <2>;
+ output-high; /* Unconditionally enable */
+ bias-pull-down;
+ };
+
+ iovdd_reg_en: iovdd-reg-en-state {
+ pins = "gpio161";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-pull-up;
+ };
+
+ sdc2_card_det_n: sd-card-det-n-state {
+ pins = "gpio55";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ vsp_reg_en: vsp-reg-en-state {
+ pins = "gpio72";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-pull-up;
+ };
+
+ vsn_reg_en: vsn-reg-en-state {
+ pins = "gpio73";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-pull-up;
+ };
+};
+
+&uart14 {
+ status = "okay";
+
+ /* WCN7861-BT */
+};
+
+&ufs_mem_phy {
+ vdda-phy-supply = <&vreg_l1j_0p91>;
+ vdda-pll-supply = <&vreg_l3g_1p2>;
+
+ status = "okay";
+};
+
+&ufs_mem_hc {
+ reset-gpios = <&tlmm 215 GPIO_ACTIVE_LOW>;
+
+ vcc-supply = <&vreg_l17b_2p5>;
+ vcc-max-microamp = <1300000>;
+ vccq-supply = <&vreg_l1d_1p2>;
+ vccq-max-microamp = <1200000>;
+
+ status = "okay";
+};
+
+&usb {
+ dr_mode = "otg";
+ maximum-speed = "super-speed-plus-gen2x1";
+
+ status = "okay";
+
+ ports {
+ /*
+ * USB2.0 is shared for two ports, set pinctrl eusb_mux_default
+ * to select the repeter. Plugging out one of them will reset
+ * the DWC3, which causes both of them to be disconnected.
+ */
+ port@0 {
+ reg = <0>;
+
+ usb_dwc3_hs: endpoint {
+ remote-endpoint = <&pmic_glink_hs_in>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ usb_dwc3_hs2: endpoint {
+ remote-endpoint = <&pmic_glink_hs_c2_in>;
+ };
+ };
+ };
+};
+
+&usb_dp_qmpphy {
+ vdda-phy-supply = <&vreg_l3g_1p2>;
+ vdda-pll-supply = <&vreg_l2d_0p88>;
+
+ mode-switch;
+ orientation-switch;
+
+ status = "okay";
+};
+
+&usb_dp_qmpphy_dp_in {
+ remote-endpoint = <&mdss_dp0_out>;
+};
+
+&usb_dp_qmpphy_out {
+ remote-endpoint = <&pmic_glink_ss_in>;
+};
+
+&usb_hsphy {
+ vdd-supply = <&vreg_l2d_0p88>;
+ vdda12-supply = <&vreg_l3g_1p2>;
+
+ phys = <&eusb_repeater>;
+
+ status = "okay";
+};
--
2.54.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox