* [PATCH v8 1/4] dt-bindings: backlight: Add max25014 support
From: Maud Spierings via B4 Relay @ 2026-04-07 14:41 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Liam Girdwood, Mark Brown, Frank Li
Cc: dri-devel, linux-leds, devicetree, linux-kernel, linux-fbdev, imx,
linux-arm-kernel, Maud Spierings
In-Reply-To: <20260407-max25014-v8-0-14eac7ed673a@gocontroll.com>
From: Maud Spierings <maudspierings@gocontroll.com>
The Maxim MAX25014 is a 4-channel automotive grade backlight driver IC
with integrated boost controller.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Maud Spierings <maudspierings@gocontroll.com>
---
In the current implementation the control registers for channel 1,
control all channels. So only one led subnode with led-sources is
supported right now. If at some point the driver functionality is
expanded the bindings can be easily extended with it.
---
.../bindings/leds/backlight/maxim,max25014.yaml | 83 ++++++++++++++++++++++
MAINTAINERS | 5 ++
2 files changed, 88 insertions(+)
diff --git a/Documentation/devicetree/bindings/leds/backlight/maxim,max25014.yaml b/Documentation/devicetree/bindings/leds/backlight/maxim,max25014.yaml
new file mode 100644
index 0000000000000..d00be2e081938
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/maxim,max25014.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/maxim,max25014.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim max25014 backlight controller
+
+maintainers:
+ - Maud Spierings <maudspierings@gocontroll.com>
+
+properties:
+ compatible:
+ enum:
+ - maxim,max25014
+
+ reg:
+ maxItems: 1
+
+ default-brightness:
+ minimum: 0
+ maximum: 100
+ default: 50
+
+ enable-gpios:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ power-supply:
+ description: Regulator which controls the boost converter input rail.
+
+ pwms:
+ maxItems: 1
+
+ maxim,iset:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 15
+ default: 11
+ description:
+ Value of the ISET field in the ISET register. This controls the current
+ scale of the outputs, a higher number means more current.
+
+ maxim,strings:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ A 4-bit bitfield that describes which led strings to turn on.
+ minItems: 4
+ maxItems: 4
+ items:
+ maximum: 1
+ default:
+ [1 1 1 1]
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ backlight@6f {
+ compatible = "maxim,max25014";
+ reg = <0x6f>;
+ default-brightness = <50>;
+ enable-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ power-supply = <®_backlight>;
+ pwms = <&pwm1>;
+ maxim,iset = <7>;
+ maxim,strings = <1 1 1 0>;
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 10d12b51b1f6f..7e3ad236537fe 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15688,6 +15688,11 @@ F: Documentation/userspace-api/media/drivers/max2175.rst
F: drivers/media/i2c/max2175*
F: include/uapi/linux/max2175.h
+MAX25014 BACKLIGHT DRIVER
+M: Maud Spierings <maudspierings@gocontroll.com>
+S: Maintained
+F: Documentation/devicetree/bindings/leds/backlight/maxim,max25014.yaml
+
MAX31335 RTC DRIVER
M: Antoniu Miclaus <antoniu.miclaus@analog.com>
L: linux-rtc@vger.kernel.org
--
2.53.0
^ permalink raw reply related
* [PATCH v8 3/4] arm64: dts: freescale: moduline-display-av101hdt-a10: add backlight
From: Maud Spierings via B4 Relay @ 2026-04-07 14:41 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Liam Girdwood, Mark Brown, Frank Li
Cc: dri-devel, linux-leds, devicetree, linux-kernel, linux-fbdev, imx,
linux-arm-kernel, Maud Spierings
In-Reply-To: <20260407-max25014-v8-0-14eac7ed673a@gocontroll.com>
From: Maud Spierings <maudspierings@gocontroll.com>
Add the missing backlight driver.
Signed-off-by: Maud Spierings <maudspierings@gocontroll.com>
---
...x8p-ml81-moduline-display-106-av101hdt-a10.dtso | 24 ++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tx8p-ml81-moduline-display-106-av101hdt-a10.dtso b/arch/arm64/boot/dts/freescale/imx8mp-tx8p-ml81-moduline-display-106-av101hdt-a10.dtso
index c6fc5d5b1e5fa..23e4bf64b28b5 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-tx8p-ml81-moduline-display-106-av101hdt-a10.dtso
+++ b/arch/arm64/boot/dts/freescale/imx8mp-tx8p-ml81-moduline-display-106-av101hdt-a10.dtso
@@ -17,6 +17,7 @@
panel {
compatible = "boe,av101hdt-a10";
+ backlight = <&backlight>;
enable-gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
pinctrl-0 = <&pinctrl_panel>;
pinctrl-names = "default";
@@ -40,7 +41,30 @@ reg_vbus: regulator-vbus {
};
};
+&i2c4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ backlight: backlight@6f {
+ compatible = "maxim,max25014";
+ reg = <0x6f>;
+ default-brightness = <50>;
+ enable-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_backlight>;
+ maxim,iset = <7>;
+ maxim,strings = <1 1 1 0>;
+ };
+};
+
&iomuxc {
+ pinctrl_backlight: backlightgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_GPIO1_IO04__GPIO1_IO04
+ (MX8MP_PULL_UP | MX8MP_PULL_ENABLE)
+ >;
+ };
+
pinctrl_panel: panelgrp {
fsl,pins = <
MX8MP_IOMUXC_GPIO1_IO07__GPIO1_IO07
--
2.53.0
^ permalink raw reply related
* [PATCH v8 0/4] backlight: add new max25014 backlight driver
From: Maud Spierings via B4 Relay @ 2026-04-07 14:41 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Liam Girdwood, Mark Brown, Frank Li
Cc: dri-devel, linux-leds, devicetree, linux-kernel, linux-fbdev, imx,
linux-arm-kernel, Maud Spierings
The Maxim MAX25014 is an automotive grade backlight driver IC. Its
datasheet can be found at [1].
With its integrated boost controller, it can power 4 channels (led
strings) and has a number of different modes using pwm and or i2c.
Currently implemented is only i2c control.
link: https://www.analog.com/media/en/technical-documentation/data-sheets/MAX25014.pdf [1]
Signed-off-by: Maud Spierings <maudspierings@gocontroll.com>
---
Changes in v8:
- Clean up some leftovers from the led subnodes, address/size-cells (Rob)
- Add Robs rb tag
- Add Daniels rb tag
- Bring the Kconfig option in line text wise with other drivers
- Rebase on the latest next
- Link to v7: https://lore.kernel.org/r/20260123-max25014-v7-0-15e504b9acc7@gocontroll.com
Changes in v7:
- remove the led subnodes
- always enable the regulator by using devm_regulator_get_enable()
- remove the no longer required gotos and simplify early returns
- fix the name of the SHORTED_LED error field
- fix the name of the SHORTGND error field
- use the proper backlight helper functions for setting/getting
brightness
- Link to v6: https://lore.kernel.org/r/20251201-max25014-v6-0-88e3ac8112ff@gocontroll.com
Changes in v6:
- fixup changes in v4 where default brightness handling was changed but
not noted
- remove leftover comment about initializing brightness
- use BIT definitions for fields in the DIAG register
- apply reverse christmas tree initialization of local variables
- remove !=0 from checks, just check if (ret)
- remove > 0 from checks, just check if (val)
- use dev_err_probe() more
- set enable gpio high in the get() instead of seperately calling set()
- change usleep_range() to fsleep()
- remove null checks when setting gpio value
- get regular regulator, not optional to avoid further NULL checks in
case none is provided
- introduce max25014_initial_power_state() to check if the bootloader
has already initialized the backlight and to correctly set props.power
- squash max25014_register_control() into max25014_update_status()
- in max25014_configure() perform extra checking on the DISABLE register
now that the state from the bootloader is taken into account
- Link to v5: https://lore.kernel.org/r/20251107-max25014-v5-0-9a6aa57306bf@gocontroll.com
Changes in v5:
- moved comment about current functions of the driver to the actual
comment section of the commit
- fixed the led@0 property, regex patternProperty is not needed as of
now
- added extra clarification about the ISET field/register
- moved #address-cells and #size-cells to the correct location
- remove leftover default-brightness in backlight nodes
- Link to v4: https://lore.kernel.org/r/20251009-max25014-v4-0-6adb2a0aa35f@gocontroll.com
Changes in v4:
- remove setting default brightness, let backlight core take care of it
- use a led node to describe the backlight
- use led-sources to enable specific channels
- also wait 2ms when there is a supply but no enable
- change dev_warn() to dev_err() in error path in max25014_check_errors()
- set backlight_properties.scale to BACKLIGHT_SCALE_LINEAR
- rebase latest next
- add address-cells and size-cells to i2c4 in av101hdt-a10.dtso
- Link to v3: https://lore.kernel.org/r/20250911-max25014-v3-0-d03f4eba375e@gocontroll.com
Changes in v3:
- fixed commit message type intgrated -> integrated
- added maximum and description to maxim,iset-property
- dropped unused labels and pinctrl in bindings example
- put the compatible first in the bindings example and dts
- removed brackets around defines
- removed the leftover pdata struct field
- removed the initial_brightness struct field
- Link to v2: https://lore.kernel.org/r/20250819-max25014-v2-0-5fd7aeb141ea@gocontroll.com
Changes in v2:
- Remove leftover unused property from the bindings example
- Complete the bindings example with all properties
- Remove some double info from the maxim,iset property
- Remove platform_data header, fold its data into the max25014 struct
- Don't force defines to be unsigned
- Remove stray struct max25014 declaration
- Remove chipname and device from the max25014 struct
- Inline the max25014_backlight_register() and strings_mask() functions
- Remove CONFIG_OF ifdef
- Link to v1: https://lore.kernel.org/r/20250725-max25014-v1-0-0e8cce92078e@gocontroll.com
---
Maud Spierings (4):
dt-bindings: backlight: Add max25014 support
backlight: add max25014atg backlight
arm64: dts: freescale: moduline-display-av101hdt-a10: add backlight
arm64: dts: freescale: moduline-display-av123z7m-n17: add backlight
.../bindings/leds/backlight/maxim,max25014.yaml | 83 +++++
MAINTAINERS | 6 +
...x8p-ml81-moduline-display-106-av101hdt-a10.dtso | 24 ++
...x8p-ml81-moduline-display-106-av123z7m-n17.dtso | 19 +-
drivers/video/backlight/Kconfig | 7 +
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/max25014.c | 377 +++++++++++++++++++++
7 files changed, 516 insertions(+), 1 deletion(-)
---
base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
change-id: 20250626-max25014-4207591e1af5
Best regards,
--
Maud Spierings <maudspierings@gocontroll.com>
^ permalink raw reply
* [PATCH v8 2/4] backlight: add max25014atg backlight
From: Maud Spierings via B4 Relay @ 2026-04-07 14:41 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Liam Girdwood, Mark Brown, Frank Li
Cc: dri-devel, linux-leds, devicetree, linux-kernel, linux-fbdev, imx,
linux-arm-kernel, Maud Spierings
In-Reply-To: <20260407-max25014-v8-0-14eac7ed673a@gocontroll.com>
From: Maud Spierings <maudspierings@gocontroll.com>
The Maxim MAX25014 is a 4-channel automotive grade backlight driver IC
with integrated boost controller.
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Signed-off-by: Maud Spierings <maudspierings@gocontroll.com>
---
MAINTAINERS | 1 +
drivers/video/backlight/Kconfig | 7 +
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/max25014.c | 377 +++++++++++++++++++++++++++++++++++++
4 files changed, 386 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7e3ad236537fe..1f1a5326a6aab 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15692,6 +15692,7 @@ MAX25014 BACKLIGHT DRIVER
M: Maud Spierings <maudspierings@gocontroll.com>
S: Maintained
F: Documentation/devicetree/bindings/leds/backlight/maxim,max25014.yaml
+F: drivers/video/backlight/max25014.c
MAX31335 RTC DRIVER
M: Antoniu Miclaus <antoniu.miclaus@analog.com>
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index a7a3fbaf7c29e..f4e99542ffe8f 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -282,6 +282,13 @@ config BACKLIGHT_DA9052
help
Enable the Backlight Driver for DA9052-BC and DA9053-AA/Bx PMICs.
+config BACKLIGHT_MAX25014
+ tristate "Backlight driver for Maxim MAX25014"
+ depends on I2C
+ select REGMAP_I2C
+ help
+ If you are using a MAX25014 chip as a backlight driver say Y to enable it.
+
config BACKLIGHT_MAX8925
tristate "Backlight driver for MAX8925"
depends on MFD_MAX8925
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 794820a98ed49..21c8313cfb121 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_BACKLIGHT_LOCOMO) += locomolcd.o
obj-$(CONFIG_BACKLIGHT_LP855X) += lp855x_bl.o
obj-$(CONFIG_BACKLIGHT_LP8788) += lp8788_bl.o
obj-$(CONFIG_BACKLIGHT_LV5207LP) += lv5207lp.o
+obj-$(CONFIG_BACKLIGHT_MAX25014) += max25014.o
obj-$(CONFIG_BACKLIGHT_MAX8925) += max8925_bl.o
obj-$(CONFIG_BACKLIGHT_MP3309C) += mp3309c.o
obj-$(CONFIG_BACKLIGHT_MT6370) += mt6370-backlight.o
diff --git a/drivers/video/backlight/max25014.c b/drivers/video/backlight/max25014.c
new file mode 100644
index 0000000000000..3ee45617261f3
--- /dev/null
+++ b/drivers/video/backlight/max25014.c
@@ -0,0 +1,377 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Backlight driver for Maxim MAX25014
+ *
+ * Copyright (C) 2025 GOcontroll B.V.
+ * Author: Maud Spierings <maudspierings@gocontroll.com>
+ */
+
+#include <linux/backlight.h>
+#include <linux/gpio/consumer.h>
+#include <linux/i2c.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+
+#define MAX25014_ISET_DEFAULT_100 11
+#define MAX_BRIGHTNESS 100
+#define MIN_BRIGHTNESS 0
+#define TON_MAX 130720 /* @153Hz */
+#define TON_STEP 1307 /* @153Hz */
+#define TON_MIN 0
+
+#define MAX25014_DEV_ID 0x00
+#define MAX25014_REV_ID 0x01
+#define MAX25014_ISET 0x02
+#define MAX25014_IMODE 0x03
+#define MAX25014_TON1H 0x04
+#define MAX25014_TON1L 0x05
+#define MAX25014_TON2H 0x06
+#define MAX25014_TON2L 0x07
+#define MAX25014_TON3H 0x08
+#define MAX25014_TON3L 0x09
+#define MAX25014_TON4H 0x0A
+#define MAX25014_TON4L 0x0B
+#define MAX25014_TON_1_4_LSB 0x0C
+#define MAX25014_SETTING 0x12
+#define MAX25014_DISABLE 0x13
+#define MAX25014_BSTMON 0x14
+#define MAX25014_IOUT1 0x15
+#define MAX25014_IOUT2 0x16
+#define MAX25014_IOUT3 0x17
+#define MAX25014_IOUT4 0x18
+#define MAX25014_OPEN 0x1B
+#define MAX25014_SHORTGND 0x1C
+#define MAX25014_SHORTED_LED 0x1D
+#define MAX25014_MASK 0x1E
+#define MAX25014_DIAG 0x1F
+
+#define MAX25014_ISET_ENA BIT(5)
+#define MAX25014_ISET_PSEN BIT(4)
+#define MAX25014_IMODE_HDIM BIT(2)
+#define MAX25014_SETTING_FPWM GENMASK(6, 4)
+#define MAX25014_DISABLE_DIS_MASK GENMASK(3, 0)
+#define MAX25014_DIAG_OT BIT(0)
+#define MAX25014_DIAG_OTW BIT(1)
+#define MAX25014_DIAG_HW_RST BIT(2)
+#define MAX25014_DIAG_BSTOV BIT(3)
+#define MAX25014_DIAG_BSTUV BIT(4)
+#define MAX25014_DIAG_IREFOOR BIT(5)
+
+struct max25014 {
+ struct i2c_client *client;
+ struct backlight_device *bl;
+ struct regmap *regmap;
+ struct gpio_desc *enable;
+ uint32_t iset;
+ uint8_t strings_mask;
+};
+
+static const struct regmap_config max25014_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = MAX25014_DIAG,
+};
+
+static int max25014_initial_power_state(struct max25014 *maxim)
+{
+ uint32_t val;
+ int ret;
+
+ ret = regmap_read(maxim->regmap, MAX25014_ISET, &val);
+ if (ret)
+ return ret;
+
+ return val & MAX25014_ISET_ENA ? BACKLIGHT_POWER_ON : BACKLIGHT_POWER_OFF;
+}
+
+static int max25014_check_errors(struct max25014 *maxim)
+{
+ uint32_t val;
+ uint8_t i;
+ int ret;
+
+ ret = regmap_read(maxim->regmap, MAX25014_OPEN, &val);
+ if (ret)
+ return ret;
+ if (val) {
+ dev_err(&maxim->client->dev, "Open led strings detected on:\n");
+ for (i = 0; i < 4; i++) {
+ if (val & 1 << i)
+ dev_err(&maxim->client->dev, "string %d\n", i + 1);
+ }
+ return -EIO;
+ }
+
+ ret = regmap_read(maxim->regmap, MAX25014_SHORTGND, &val);
+ if (ret)
+ return ret;
+ if (val) {
+ dev_err(&maxim->client->dev, "Short to ground detected on:\n");
+ for (i = 0; i < 4; i++) {
+ if (val & 1 << i)
+ dev_err(&maxim->client->dev, "string %d\n", i + 1);
+ }
+ return -EIO;
+ }
+
+ ret = regmap_read(maxim->regmap, MAX25014_SHORTED_LED, &val);
+ if (ret)
+ return ret;
+ if (val) {
+ dev_err(&maxim->client->dev, "Shorted led detected on:\n");
+ for (i = 0; i < 4; i++) {
+ if (val & 1 << i)
+ dev_err(&maxim->client->dev, "string %d\n", i + 1);
+ }
+ return -EIO;
+ }
+
+ ret = regmap_read(maxim->regmap, MAX25014_DIAG, &val);
+ if (ret)
+ return ret;
+ /*
+ * The HW_RST bit always starts at 1 after power up.
+ * It is reset on first read, does not indicate an error.
+ */
+ if (val && val != MAX25014_DIAG_HW_RST) {
+ if (val & MAX25014_DIAG_OT)
+ dev_err(&maxim->client->dev,
+ "Overtemperature shutdown\n");
+ if (val & MAX25014_DIAG_OTW)
+ dev_err(&maxim->client->dev,
+ "Chip is getting too hot (>125C)\n");
+ if (val & MAX25014_DIAG_BSTOV)
+ dev_err(&maxim->client->dev,
+ "Boost converter overvoltage\n");
+ if (val & MAX25014_DIAG_BSTUV)
+ dev_err(&maxim->client->dev,
+ "Boost converter undervoltage\n");
+ if (val & MAX25014_DIAG_IREFOOR)
+ dev_err(&maxim->client->dev, "IREF out of range\n");
+ return -EIO;
+ }
+ return 0;
+}
+
+/*
+ * 1. disable unused strings
+ * 2. set dim mode
+ * 3. set setting register
+ * 4. enable the backlight
+ */
+static int max25014_configure(struct max25014 *maxim, int initial_state)
+{
+ uint32_t val;
+ int ret;
+
+ ret = regmap_read(maxim->regmap, MAX25014_DISABLE, &val);
+ if (ret)
+ return ret;
+
+ /*
+ * Strings can only be disabled when MAX25014_ISET_ENA == 0, check if
+ * it needs to be changed at all to prevent the backlight flashing when
+ * it is configured correctly by the bootloader
+ */
+ if (!((val & MAX25014_DISABLE_DIS_MASK) == maxim->strings_mask)) {
+ if (initial_state == BACKLIGHT_POWER_ON) {
+ ret = regmap_write(maxim->regmap, MAX25014_ISET, 0);
+ if (ret)
+ return ret;
+ }
+ ret = regmap_write(maxim->regmap, MAX25014_DISABLE, maxim->strings_mask);
+ if (ret)
+ return ret;
+ }
+
+ ret = regmap_write(maxim->regmap, MAX25014_IMODE, MAX25014_IMODE_HDIM);
+ if (ret)
+ return ret;
+
+ ret = regmap_read(maxim->regmap, MAX25014_SETTING, &val);
+ if (ret)
+ return ret;
+
+ ret = regmap_write(maxim->regmap, MAX25014_SETTING,
+ val & ~MAX25014_SETTING_FPWM);
+ if (ret)
+ return ret;
+
+ return regmap_write(maxim->regmap, MAX25014_ISET,
+ maxim->iset | MAX25014_ISET_ENA |
+ MAX25014_ISET_PSEN);
+}
+
+static int max25014_update_status(struct backlight_device *bl_dev)
+{
+ struct max25014 *maxim = bl_get_data(bl_dev);
+ uint32_t reg;
+ int ret;
+
+ reg = TON_STEP * backlight_get_brightness(bl_dev);
+
+ /*
+ * 18 bit number lowest, 2 bits in first register,
+ * next lowest 8 in the L register, next 8 in the H register
+ * Seemingly setting the strength of only one string controls all of
+ * them, individual settings don't affect the outcome.
+ */
+ ret = regmap_write(maxim->regmap, MAX25014_TON_1_4_LSB, reg & 0b00000011);
+ if (ret != 0)
+ return ret;
+ ret = regmap_write(maxim->regmap, MAX25014_TON1L, (reg >> 2) & 0b11111111);
+ if (ret != 0)
+ return ret;
+ return regmap_write(maxim->regmap, MAX25014_TON1H, (reg >> 10) & 0b11111111);
+}
+
+static const struct backlight_ops max25014_bl_ops = {
+ .options = BL_CORE_SUSPENDRESUME,
+ .update_status = max25014_update_status,
+};
+
+static int max25014_parse_dt(struct max25014 *maxim,
+ uint32_t *initial_brightness)
+{
+ struct device *dev = &maxim->client->dev;
+ struct device_node *node = dev->of_node;
+ uint32_t strings[4];
+ int res, i;
+
+ res = of_property_count_u32_elems(node, "maxim,strings");
+ if (res == 4) {
+ of_property_read_u32_array(node, "maxim,strings", strings, 4);
+ for (i = 0; i < 4; i++) {
+ if (strings[i] == 0)
+ maxim->strings_mask |= 1 << i;
+ }
+ } else {
+ maxim->strings_mask = 0;
+ }
+
+ *initial_brightness = 50U;
+ of_property_read_u32(node, "default-brightness", initial_brightness);
+
+ maxim->iset = MAX25014_ISET_DEFAULT_100;
+ of_property_read_u32(node, "maxim,iset", &maxim->iset);
+
+ if (maxim->iset > 15)
+ return dev_err_probe(dev, -EINVAL,
+ "Invalid iset, should be a value from 0-15, entered was %d\n",
+ maxim->iset);
+
+ if (*initial_brightness > 100)
+ return dev_err_probe(dev, -EINVAL,
+ "Invalid initial brightness, should be a value from 0-100, entered was %d\n",
+ *initial_brightness);
+
+ return 0;
+}
+
+static int max25014_probe(struct i2c_client *cl)
+{
+ const struct i2c_device_id *id = i2c_client_get_device_id(cl);
+ struct backlight_properties props;
+ uint32_t initial_brightness = 50;
+ struct backlight_device *bl;
+ struct max25014 *maxim;
+ int ret;
+
+ maxim = devm_kzalloc(&cl->dev, sizeof(struct max25014), GFP_KERNEL);
+ if (!maxim)
+ return -ENOMEM;
+
+ maxim->client = cl;
+
+ ret = max25014_parse_dt(maxim, &initial_brightness);
+ if (ret)
+ return ret;
+
+ ret = devm_regulator_get_enable(&maxim->client->dev, "power");
+ if (ret)
+ return dev_err_probe(&maxim->client->dev, ret,
+ "failed to get power-supply");
+
+ maxim->enable = devm_gpiod_get_optional(&maxim->client->dev, "enable",
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(maxim->enable))
+ return dev_err_probe(&maxim->client->dev, PTR_ERR(maxim->enable),
+ "failed to get enable gpio\n");
+
+ /* Datasheet Electrical Characteristics tSTARTUP 2ms */
+ fsleep(2000);
+
+ maxim->regmap = devm_regmap_init_i2c(cl, &max25014_regmap_config);
+ if (IS_ERR(maxim->regmap))
+ return dev_err_probe(&maxim->client->dev, PTR_ERR(maxim->regmap),
+ "failed to initialize the i2c regmap\n");
+
+ i2c_set_clientdata(cl, maxim);
+
+ ret = max25014_check_errors(maxim);
+ if (ret) /* error is already reported in the above function */
+ return ret;
+
+ ret = max25014_initial_power_state(maxim);
+ if (ret < 0)
+ return dev_err_probe(&maxim->client->dev, ret, "Could not get enabled state\n");
+
+ memset(&props, 0, sizeof(struct backlight_properties));
+ props.type = BACKLIGHT_PLATFORM;
+ props.max_brightness = MAX_BRIGHTNESS;
+ props.brightness = initial_brightness;
+ props.scale = BACKLIGHT_SCALE_LINEAR;
+ props.power = ret;
+
+ ret = max25014_configure(maxim, ret);
+ if (ret)
+ return dev_err_probe(&maxim->client->dev, ret, "device config error");
+
+ bl = devm_backlight_device_register(&maxim->client->dev, id->name,
+ &maxim->client->dev, maxim,
+ &max25014_bl_ops, &props);
+ if (IS_ERR(bl))
+ return dev_err_probe(&maxim->client->dev, PTR_ERR(bl),
+ "failed to register backlight\n");
+
+ maxim->bl = bl;
+
+ backlight_update_status(maxim->bl);
+
+ return 0;
+}
+
+static void max25014_remove(struct i2c_client *cl)
+{
+ struct max25014 *maxim = i2c_get_clientdata(cl);
+
+ backlight_device_set_brightness(maxim->bl, 0);
+ gpiod_set_value_cansleep(maxim->enable, 0);
+}
+
+static const struct of_device_id max25014_dt_ids[] = {
+ { .compatible = "maxim,max25014", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, max25014_dt_ids);
+
+static const struct i2c_device_id max25014_ids[] = {
+ { "max25014" },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, max25014_ids);
+
+static struct i2c_driver max25014_driver = {
+ .driver = {
+ .name = KBUILD_MODNAME,
+ .of_match_table = of_match_ptr(max25014_dt_ids),
+ },
+ .probe = max25014_probe,
+ .remove = max25014_remove,
+ .id_table = max25014_ids,
+};
+module_i2c_driver(max25014_driver);
+
+MODULE_DESCRIPTION("Maxim MAX25014 backlight driver");
+MODULE_AUTHOR("Maud Spierings <maudspierings@gocontroll.com>");
+MODULE_LICENSE("GPL");
--
2.53.0
^ permalink raw reply related
* [PATCH v8 4/4] arm64: dts: freescale: moduline-display-av123z7m-n17: add backlight
From: Maud Spierings via B4 Relay @ 2026-04-07 14:41 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Liam Girdwood, Mark Brown, Frank Li
Cc: dri-devel, linux-leds, devicetree, linux-kernel, linux-fbdev, imx,
linux-arm-kernel, Maud Spierings
In-Reply-To: <20260407-max25014-v8-0-14eac7ed673a@gocontroll.com>
From: Maud Spierings <maudspierings@gocontroll.com>
Add the missing backlight.
Signed-off-by: Maud Spierings <maudspierings@gocontroll.com>
---
...p-tx8p-ml81-moduline-display-106-av123z7m-n17.dtso | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tx8p-ml81-moduline-display-106-av123z7m-n17.dtso b/arch/arm64/boot/dts/freescale/imx8mp-tx8p-ml81-moduline-display-106-av123z7m-n17.dtso
index 3eb665ce9d5d2..0b969c8c04db1 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-tx8p-ml81-moduline-display-106-av123z7m-n17.dtso
+++ b/arch/arm64/boot/dts/freescale/imx8mp-tx8p-ml81-moduline-display-106-av123z7m-n17.dtso
@@ -16,6 +16,7 @@
panel {
compatible = "boe,av123z7m-n17";
+ backlight = <&backlight>;
enable-gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
pinctrl-0 = <&pinctrl_panel>;
pinctrl-names = "default";
@@ -91,10 +92,26 @@ lvds1_out: endpoint {
};
};
- /* max25014 @ 0x6f */
+ backlight: backlight@6f {
+ compatible = "maxim,max25014";
+ reg = <0x6f>;
+ default-brightness = <50>;
+ enable-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_backlight>;
+ maxim,iset = <7>;
+ maxim,strings = <1 1 1 1>;
+ };
};
&iomuxc {
+ pinctrl_backlight: backlightgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_GPIO1_IO04__GPIO1_IO04
+ (MX8MP_PULL_UP | MX8MP_PULL_ENABLE)
+ >;
+ };
+
pinctrl_lvds_bridge: lvdsbridgegrp {
fsl,pins = <
MX8MP_IOMUXC_SAI1_TXD2__GPIO4_IO14
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v5 2/2] iio: dac: ad5706r: Add support for AD5706R DAC
From: Andy Shevchenko @ 2026-04-07 14:46 UTC (permalink / raw)
To: Alexis Czezar Torreno
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-iio, devicetree,
linux-kernel
In-Reply-To: <20260407-dev_ad5706r-v5-2-a4c7737b6ae9@analog.com>
On Tue, Apr 07, 2026 at 11:39:45AM +0800, Alexis Czezar Torreno wrote:
> Add support for the Analog Devices AD5706R, a 4-channel 16-bit
> current output digital-to-analog converter with SPI interface.
>
> Features:
> - 4 independent DAC channels
> - Hardware and software LDAC trigger
> - Configurable output range
> - PWM-based LDAC control
> - Dither and toggle modes
> - Dynamically configurable SPI speed
Mostly okay, see minor comments below, the main one is about treating void * as
__be16/__be32 * without any validation.
...
> +static int ad5706r_regmap_write(void *context, const void *data, size_t count)
> +{
> + struct ad5706r_state *st = context;
> + unsigned int num_bytes, val;
> + u16 reg;
> +
> + reg = get_unaligned_be16(data);
> + num_bytes = ad5706r_reg_len(reg);
> +
> + struct spi_transfer xfer = {
> + .tx_buf = st->tx_buf,
> + .len = num_bytes + 2,
> + };
> + val = get_unaligned_be32(data);
Is it safe? The data is void *, no size of it is counted here...
> + put_unaligned_be32(val, st->tx_buf);
> +
> + /* For single byte, copy the data to the correct position */
> + if (num_bytes == AD5706R_SINGLE_BYTE_LEN)
> + st->tx_buf[2] = st->tx_buf[3];
> +
> + return spi_sync_transfer(st->spi, &xfer, 1);
> +}
> +static int ad5706r_regmap_read(void *context, const void *reg_buf,
> + size_t reg_size, void *val_buf, size_t val_size)
> +{
> + struct ad5706r_state *st = context;
> + unsigned int num_bytes;
> + u16 reg, cmd, val;
> + int ret;
> +
> + reg = get_unaligned_be16(reg_buf);
> + num_bytes = ad5706r_reg_len(reg);
> +
> + /* Full duplex, device responds immediately after command */
> + struct spi_transfer xfer = {
> + .tx_buf = st->tx_buf,
> + .rx_buf = st->rx_buf,
> + .len = 2 + num_bytes,
> + };
> +
> + cmd = AD5706R_RD_MASK | (reg & AD5706R_ADDR_MASK);
> + put_unaligned_be16(cmd, st->tx_buf);
For the consistency's sake use &st->tx_buf[0].
> + put_unaligned_be16(0, &st->tx_buf[2]);
> +
> + ret = spi_sync_transfer(st->spi, &xfer, 1);
> + if (ret)
> + return ret;
> +
> + /* Extract value from response (skip 2-byte command echo) */
> + if (num_bytes == AD5706R_SINGLE_BYTE_LEN)
> + val = st->rx_buf[2];
> + else if (num_bytes == AD5706R_DOUBLE_BYTE_LEN)
> + val = get_unaligned_be16(&st->rx_buf[2]);
> + else
> + return -EINVAL;
> +
> + put_unaligned_be16(val, val_buf);
> +
> + return 0;
> +}
...
> +#define AD5706R_CHAN(_channel) { \
> + .type = IIO_CURRENT, \
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
> + BIT(IIO_CHAN_INFO_SCALE), \
Missing indentation at the end with tabs.
> + .output = 1, \
> + .indexed = 1, \
> + .channel = _channel, \
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v3 0/2] Add Renesas RZ/G3L RSPI support
From: Biju @ 2026-04-07 14:57 UTC (permalink / raw)
To: Fabrizio Castro, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm
Cc: Biju Das, linux-spi, linux-renesas-soc, devicetree, linux-kernel,
Prabhakar Mahadev Lad, Biju Das
From: Biju Das <biju.das.jz@bp.renesas.com>
This patch series adds binding and driver support for RSPI IP found on the
RZ/G3L SoC. The RSPI is compatible with RZ/V2H RSPI, but has 2 clocks
compared to 3 on RZ/V2H.
v2->v3:
* Added ordered DMA names for the dma-names property.
* Dropped the tag from bindings as there is a change related to dma-names
property.
v1->v2:
* Rebased to next
* Collected tags
Biju Das (2):
dt-bindings: spi: renesas,rzv2h-rspi: Document RZ/G3L SoC
spi: rzv2h-rspi: Add support for RZ/G3L (R9A08G046)
.../bindings/spi/renesas,rzv2h-rspi.yaml | 28 +++++++++++++++++++
drivers/spi/spi-rzv2h-rspi.c | 8 ++++++
2 files changed, 36 insertions(+)
--
2.43.0
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: spi: renesas,rzv2h-rspi: Document RZ/G3L SoC
From: Biju @ 2026-04-07 14:57 UTC (permalink / raw)
To: Fabrizio Castro, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm
Cc: Biju Das, linux-spi, linux-renesas-soc, devicetree, linux-kernel,
Prabhakar Mahadev Lad, Biju Das
In-Reply-To: <20260407145753.101840-1-biju.das.jz@bp.renesas.com>
From: Biju Das <biju.das.jz@bp.renesas.com>
Document RSPI IP found on the RZ/G3L SoC. The RSPI IP is compatible with
the RZ/V2H RSPI IP, but has 2 clocks compared to 3 on RZ/V2H.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
v2->v3:
* Added ordered DMA names for the dma-names property.
* Dropped the tag
v1->v2:
* Collected tag
---
.../bindings/spi/renesas,rzv2h-rspi.yaml | 28 +++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml b/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
index 2c9045fd51de..6f4bb83a549f 100644
--- a/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
+++ b/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
@@ -13,6 +13,7 @@ properties:
compatible:
oneOf:
- enum:
+ - renesas,r9a08g046-rspi # RZ/G3L
- renesas,r9a09g057-rspi # RZ/V2H(P)
- renesas,r9a09g077-rspi # RZ/T2H
- items:
@@ -90,6 +91,33 @@ required:
allOf:
- $ref: spi-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,r9a08g046-rspi
+ then:
+ properties:
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: tclk
+ dmas:
+ maxItems: 2
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
+
+ required:
+ - resets
+ - reset-names
+
- if:
properties:
compatible:
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 5/5] arm64: dts: qcom: qcs8550: add QCS8550 RB5Gen2 board support
From: Dmitry Baryshkov @ 2026-04-07 15:01 UTC (permalink / raw)
To: Joe Sandom
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260407113925.4imd3lxkcrq47pu3@linaro>
On Tue, Apr 07, 2026 at 12:39:25PM +0100, Joe Sandom wrote:
> On Sun, Apr 05, 2026 at 12:20:23AM +0300, Dmitry Baryshkov wrote:
> > On Sat, Apr 04, 2026 at 10:50:58AM +0100, Joe Sandom via B4 Relay wrote:
> > > +
> > > + wcn7850-pmu {
> > > + compatible = "qcom,wcn7850-pmu";
> > > +
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&wlan_en>, <&bt_default>, <&pmk8550_sleep_clk>;
> >
> > swctrl?
> Bundled into bt_default since it's tied to BT
It's not. It's either WiFi or BT.
> >
> > > +
> > > + wlan-enable-gpios = <&tlmm 80 GPIO_ACTIVE_HIGH>;
> > > + bt-enable-gpios = <&tlmm 81 GPIO_ACTIVE_HIGH>;
> >
[...]
> > > + iommu-map = <0x0 &apps_smmu 0x1400 0x1>,
> > > + <0x100 &apps_smmu 0x1401 0x1>,
> > > + <0x208 &apps_smmu 0x1402 0x1>,
> > > + <0x210 &apps_smmu 0x1403 0x1>,
> > > + <0x218 &apps_smmu 0x1404 0x1>,
> > > + <0x300 &apps_smmu 0x1407 0x1>,
> > > + <0x400 &apps_smmu 0x1408 0x1>,
> > > + <0x500 &apps_smmu 0x140c 0x1>,
> > > + <0x501 &apps_smmu 0x140e 0x1>;
> > > +
> > > + /delete-property/ msi-map;
> >
> > Why?
> I tried extending the msi-map to cover the RIDs from the QPS615
> PCIe switch (matching the iommu-map entries), but this caused
> ITS MAPD command timeouts. From what I could gather, deleting
> msi-map forces the PCIe controller to fall back to the internal
> iMSI-RX module, where this worked properly.
>
> For reference, I checked the RB3gen2 since it also uses a QPS615
> and there doesn't seem to be any msi-map defined (in kodiak.dtsi).
>
> Any recommendations to resolve this properly?
Maybe Mani knows. Please mention this in the commit message at least.
> >
> > > +
> > > + status = "okay";
> > > +};
> > > +
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH] of: fdt: skip KHO when booting as crash kernel
From: Evangelos Petrongonas @ 2026-04-07 15:06 UTC (permalink / raw)
To: Rob Herring, Saravana Kannan
Cc: Evangelos Petrongonas, Mike Rapoport (Microsoft), Changyuan Lyu,
Alexander Graf, Pasha Tatashin, Pratyush Yadav, Andrew Morton,
devicetree, kexec, linux-kernel, nh-open-source
KHO preserves state across kexec by passing a KHO-specific FDT pointer
and scratch memory region to the incoming kernel. These point to
physical addresses in the outgoing kernel's memory that the incoming
kernel is expected to access and restore from. This falls apart when
the incoming kernel is a crash kernel as the crash kernel can run in a
small reserved memory region. The scratch regions can sit outside this
reservation, so the end result is quite unpleasant.
kho_add_chosen() unconditionally propagates KHO properties into
the device tree for all kexec image types, including crash images. The
crash kernel then discovers these properties during
early_init_dt_check_kho(), records the stale physical addresses via
kho_populate(), and later faults in kho_memory_init() when it tries
phys_to_virt() on the KHO FDT address:
Unable to handle kernel paging request at virtual address xxxxxxxx
...
fdt_offset_ptr+...
fdt_check_node_offset_+...
fdt_first_property_offset+...
fdt_get_property_namelen_+...
fdt_getprop+...
kho_memory_init+...
mm_core_init+...
start_kernel+...
kho_locate_mem_hole() already skips KHO logic for KEXEC_TYPE_CRASH
images, but the DT property propagation and the consumer side were both
missing the same guard.
Fix this at both ends. Have kho_add_chosen() skip writing KHO properties
for crash images so the stale pointers never reach the crash kernel's
device tree. Also have early_init_dt_check_kho() bail out when
is_kdump_kernel() is true. This way even if KHO properties end up in
the DT through some other path, the crash kernel will not act on them.
Fixes: 274cdcb1c004 ("arm64: add KHO support")
Signed-off-by: Evangelos Petrongonas <epetron@amazon.de>
---
I think we should backport the fix on KHO compatible versions (6.16+),
hence the "Fixes:" tag. Tested on an arm64 system.
drivers/of/fdt.c | 3 +++
drivers/of/kexec.c | 3 ++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 43a0944ca462..77018ec99fc8 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -926,6 +926,9 @@ static void __init early_init_dt_check_kho(void)
if (!IS_ENABLED(CONFIG_KEXEC_HANDOVER) || (long)node < 0)
return;
+ if (is_kdump_kernel())
+ return;
+
if (!of_flat_dt_get_addr_size(node, "linux,kho-fdt",
&fdt_start, &fdt_size))
return;
diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
index c4cf3552c018..b95f0b386684 100644
--- a/drivers/of/kexec.c
+++ b/drivers/of/kexec.c
@@ -271,7 +271,8 @@ static int kho_add_chosen(const struct kimage *image, void *fdt, int chosen_node
if (ret && ret != -FDT_ERR_NOTFOUND)
return ret;
- if (!image->kho.fdt || !image->kho.scratch)
+ if (!image->kho.fdt || !image->kho.scratch ||
+ image->type == KEXEC_TYPE_CRASH)
return 0;
fdt_mem = image->kho.fdt;
--
2.43.0
Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597
^ permalink raw reply related
* Re: [PATCH] dt-bindings: display: bridge: lt9211: Require data-lanes on DSI input ports
From: Marek Vasut @ 2026-04-07 14:51 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree, Andrzej Hajda, Conor Dooley, David Airlie,
Jernej Skrabec, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, Maarten Lankhorst, Maxime Ripard,
Neil Armstrong, Rob Herring, Robert Foss, Simona Vetter,
Thomas Zimmermann, dri-devel, linux-kernel
In-Reply-To: <20260407-invaluable-pretty-leopard-1e8dfc@quoll>
On 4/7/26 10:00 AM, Krzysztof Kozlowski wrote:
>> NOTE: For example Linux kernel driver does already use that information
>> and fails to probe if it is missing. There are currently no intree
>
> The first sentence must be part of the commit msg. That is important
> reason why you are doing this... but I don't see how you achieve any of
> this. Look:
>
>
>> users for this binding, so no new warnings will be generated once
>> this is applied, but a new user is about to be added.
>
> What warnings? How?
There are no in-tree users of this binding, so no DT checker warnings
will be produced on existing in-tree DTs. I am in the process of adding
a DTO which uses this binding now in arm64: dts: imx8mm: imx8mp: Add
DTOs for Data Modul i.MX8M Mini and Plus eDM SBC
>> ---
>> .../display/bridge/lontium,lt9211.yaml | 37 ++++++++++++++++++-
>> 1 file changed, 35 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml
>> index 9a6e9b25d14a9..5264fb2b68b78 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml
>> +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml
>> @@ -36,18 +36,50 @@ properties:
>>
>> properties:
>> port@0:
>> - $ref: /schemas/graph.yaml#/properties/port
>> + $ref: /schemas/graph.yaml#/$defs/port-base
>
> OK, that's correct.
>
>> + unevaluatedProperties: false
>> description:
>> Primary MIPI DSI port-1 for MIPI input or
>> LVDS port-1 for LVDS input or DPI input.
>>
>> + properties:
>> + endpoint:
>> + $ref: /schemas/media/video-interfaces.yaml#
>> + unevaluatedProperties: false
>
> That's correct.
>
>> +
>> + properties:
>> + data-lanes:
>> + description: array of physical DSI data lane indexes.
>> + minItems: 1
>> + items:
>> + - const: 1
>> + - const: 2
>> + - const: 3
>> + - const: 4
>
> That's almost redundant in this context - it was already there - and the
> point is that it solves noting in the problem you had. Binding still
> does not validate the ABI and does not match it, still.
>
> Since commit foo bar, driver needs data-lanes, so what you need to do is
> allow them and to require them. You can also specify their constraints
> if device can be configured multiple ways, up to 4 lanes.
Please pardon my ignorance, what exactly do you propose I change in this
patch ?
^ permalink raw reply
* [PATCH v2 0/2] Describe IMEM on Milos
From: Luca Weiss @ 2026-04-07 15:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel, Luca Weiss
Add a compatible and describe the IMEM for the Milos SoC.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
Changes in v2:
- Use mmio-sram for describing IMEM
- Link to v1: https://patch.msgid.link/20260403-milos-imem-v1-0-4244ebb47017@fairphone.com
---
Luca Weiss (2):
dt-bindings: sram: Document qcom,milos-imem
arm64: dts: qcom: milos: Add IMEM node
Documentation/devicetree/bindings/sram/sram.yaml | 1 +
arch/arm64/boot/dts/qcom/milos.dtsi | 20 ++++++++++++++++++++
2 files changed, 21 insertions(+)
---
base-commit: 83acad05dee54a5cff0c98dd7962e55d4c6b145a
change-id: 20260403-milos-imem-3a034224946a
Best regards,
--
Luca Weiss <luca.weiss@fairphone.com>
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: sram: Document qcom,milos-imem
From: Luca Weiss @ 2026-04-07 15:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel, Luca Weiss
In-Reply-To: <20260407-milos-imem-v2-0-5084a490340c@fairphone.com>
Add compatible for Milos SoC IMEM.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
Documentation/devicetree/bindings/sram/sram.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml
index c451140962c8..cb2e11c73d98 100644
--- a/Documentation/devicetree/bindings/sram/sram.yaml
+++ b/Documentation/devicetree/bindings/sram/sram.yaml
@@ -35,6 +35,7 @@ properties:
- nvidia,tegra194-sysram
- nvidia,tegra234-sysram
- qcom,kaanapali-imem
+ - qcom,milos-imem
- qcom,rpm-msg-ram
- rockchip,rk3288-pmu-sram
--
2.53.0
^ permalink raw reply related
* [PATCH v2 2/2] arm64: dts: qcom: milos: Add IMEM node
From: Luca Weiss @ 2026-04-07 15:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel, Luca Weiss
In-Reply-To: <20260407-milos-imem-v2-0-5084a490340c@fairphone.com>
Add a node for the IMEM found on Milos, which contains pil-reloc-info
and the modem tables for IPA, among others.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
Not happy about the names of the subnodes. pil-reloc-sram is not allowed
it seems. Glymur calls it "pil-sram@94c", not sure this is wanted?
Please advice.
---
arch/arm64/boot/dts/qcom/milos.dtsi | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi b/arch/arm64/boot/dts/qcom/milos.dtsi
index 4a64a98a434b..0c69d5810f5e 100644
--- a/arch/arm64/boot/dts/qcom/milos.dtsi
+++ b/arch/arm64/boot/dts/qcom/milos.dtsi
@@ -2289,6 +2289,26 @@ scl-pins {
};
};
+ sram@14680000 {
+ compatible = "qcom,milos-imem", "mmio-sram";
+ reg = <0x0 0x14680000 0x0 0x2c000>;
+ ranges = <0 0 0x14680000 0x2c000>;
+
+ no-memory-wc;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ pilreloc-sram@94c {
+ compatible = "qcom,pil-reloc-info";
+ reg = <0x94c 0xc8>;
+ };
+
+ ipa_modem_tables: modemtables-sram@3000 {
+ reg = <0x3000 0x2000>;
+ };
+ };
+
apps_smmu: iommu@15000000 {
compatible = "qcom,milos-smmu-500", "qcom,smmu-500", "arm,mmu-500";
reg = <0x0 0x15000000 0x0 0x100000>;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
From: Mathieu Poirier @ 2026-04-07 15:19 UTC (permalink / raw)
To: Peng Fan
Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Daniel Baluta, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel, Peng Fan
In-Reply-To: <acs2PAZq2k3zjmDW@shlinux89>
On Tue, Mar 31, 2026 at 10:49:32AM +0800, Peng Fan wrote:
> On Mon, Mar 30, 2026 at 10:22:35AM -0600, Mathieu Poirier wrote:
> >On Fri, Mar 27, 2026 at 10:42:03AM +0800, Peng Fan (OSS) wrote:
> >> From: Peng Fan <peng.fan@nxp.com>
> >>
> >> Cortex-M[7,33] processors use a fixed reset vector table format:
> >>
> >> 0x00 Initial SP value
> >> 0x04 Reset vector
> >> 0x08 NMI
> >> 0x0C ...
> >> ...
> >> IRQ[n]
> >>
> >> In ELF images, the corresponding layout is:
> >>
> >> reset_vectors: --> hardware reset address
> >> .word __stack_end__
> >> .word Reset_Handler
> >> .word NMI_Handler
> >> .word HardFault_Handler
> >> ...
> >> .word UART_IRQHandler
> >> .word SPI_IRQHandler
> >> ...
> >>
> >> Reset_Handler: --> ELF entry point address
> >> ...
> >>
> >> The hardware fetches the first two words from reset_vectors and populates
> >> SP with __stack_end__ and PC with Reset_Handler. Execution proceeds from
> >> Reset_Handler.
> >>
> >> However, the ELF entry point does not always match the hardware reset
> >> address. For example, on i.MX94 CM33S:
> >>
> >> ELF entry point: 0x0ffc211d
> >> hardware reset base: 0x0ffc0000 (default reset value, sw programmable)
> >>
> >
> >But why? Why can't the ELF image be set to the right reset base?
>
> Per zephyr general link script[1]:
> ENTRY(CONFIG_KERNEL_ENTRY)
>
> CONFIG_KERNEL_ENTRY(_start) is the first instruction that Cortex-M starts to
> execute.
>
> config KERNEL_ENTRY
> string "Kernel entry symbol"
> default "__start"
> help
> Code entry symbol, to be set at linking phase.
>
> The hardware reset base is different: it is the address where the hardware
> fetches the initial MSP and PC values from the vector table. Hardware uses
> this base to initialize the stack pointer and program counter, and only then
> does the Cortex‑M begin execution at the reset handler.
That part is clear.
>
> Aligning the ELF entry point with the hardware reset base on Cortex‑M systems
> is possible, but it comes with several risks.
I'm not asking to align the ELF entry point with the hardware reset base. All I
want is to have the correct start address embedded in the ELF file to avoid
having to use a mask.
> 1, Semantic mismatch (ELF vs. hardware behavior)
> 2, Debuggers may attempt to set breakpoints or start execution at the entry symbol
>
> [1] https://elixir.bootlin.com/zephyr/v4.4.0-rc1/source/include/zephyr/arch/arm/cortex_m/scripts/linker.ld#L103
>
> Regards
> Peng.
> >
^ permalink raw reply
* [PATCH 00/12] arm64: dts: qcom: qcs6490: Radxa Dragon Q6A feature enablement and fixes
From: Xilin Wu @ 2026-04-07 15:19 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dmitry Baryshkov, Liam Girdwood, Mark Brown,
Judy Hsiao
Cc: linux-arm-msm, linux-kernel, devicetree, Konrad Dybcio,
linux-sound, Xilin Wu, Stephen Chen
This series brings the Radxa Dragon Q6A (QCS6490) board support up to
date with the latest official firmware and enables additional hardware.
Fixes and alignment with latest firmware:
- Allow QSEECOM for UEFI/efivars support
- Align reserved-memory with the latest firmware memory map
- Drop QSPI node now restricted by TrustZone
- Switch to board-specific CDSP firmware matching new WP boot firmware
- Correct GPIO_27 label
Hardware enablement:
- Enable UFS controller (Gear-4 Rate-A)
- Enable USB 3.0 and HDMI (via DP-to-HDMI bridge)
- Mark secondary USB controller as wakeup source
- Add I2C aliases for CCI buses
Variant for LPASS CPU audio:
- Factor out common board dtsi for sharing between variants
- Add dt-bindings for Dragon Q6A sound card
- Add LPASS CPU audio variant for EL2 direct hardware access
Signed-off-by: Xilin Wu <sophon@radxa.com>
---
Stephen Chen (3):
arm64: dts: qcom: kodiak: Add I2C aliases for CCI
arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Correct GPIO_27 label
arm64: dts: qcom: kodiak: Mark secondary USB controller as wakeup source
Xilin Wu (9):
firmware: qcom: scm: Allow QSEECOM for Radxa Dragon Q6A
arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Enable UFS controller
arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Enable USB 3.0 and HDMI ports
arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Use board-specific CDSP firmware
arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Drop QSPI node and reserve its pins
arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Align reserved-memory with latest firmware map
arm64: dts: qcom: qcs6490-radxa-dragon-q6a: factor out common board dtsi
ASoC: dt-bindings: google,sc7280-herobrine: Add Radxa Dragon Q6A sound card
arm64: dts: qcom: qcs6490-radxa-dragon-q6a: add LPASS CPU audio variant
.../bindings/sound/google,sc7280-herobrine.yaml | 9 +-
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/kodiak.dtsi | 5 +
.../qcom/qcs6490-radxa-dragon-q6a-lpass-cpu.dts | 131 +++
.../boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts | 1047 +-----------------
.../boot/dts/qcom/qcs6490-radxa-dragon-q6a.dtsi | 1137 ++++++++++++++++++++
drivers/firmware/qcom/qcom_scm.c | 1 +
7 files changed, 1300 insertions(+), 1031 deletions(-)
---
base-commit: 816f193dd0d95246f208590924dd962b192def78
change-id: 20260407-dragon-q6a-feat-fixes-6a30f6ba8b18
Best regards,
--
Xilin Wu <sophon@radxa.com>
^ permalink raw reply
* [PATCH 03/12] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Enable USB 3.0 and HDMI ports
From: Xilin Wu @ 2026-04-07 15:19 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dmitry Baryshkov, Liam Girdwood, Mark Brown,
Judy Hsiao
Cc: linux-arm-msm, linux-kernel, devicetree, Konrad Dybcio,
linux-sound, Xilin Wu
In-Reply-To: <20260407-dragon-q6a-feat-fixes-v1-0-14aca49dde3d@radxa.com>
This board doesn't feature a regular Type-C port. The usb_1_qmpphy's
RX1/TX1 pair is statically connected to the USB-A port, while its RX0/TX0
pair is connected to the RA620 DP-to-HDMI bridge.
Add and enable the nodes for the features to work.
Signed-off-by: Xilin Wu <sophon@radxa.com>
---
.../boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts | 152 +++++++++++++++++++++
1 file changed, 152 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 c961d3ec625f..8d649b3a1cfa 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
+++ b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
@@ -111,6 +111,71 @@ usb2_3_connector: endpoint {
};
};
+ 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_1_qmpphy_out_usb>;
+ };
+ };
+ };
+ };
+
+ hdmi-bridge {
+ compatible = "radxa,ra620";
+
+ pinctrl-0 = <&dp_hot_plug_det>;
+ pinctrl-names = "default";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ hdmi_bridge_in: endpoint {
+ remote-endpoint = <&usb_1_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>;
+ };
+ };
+ };
+
leds {
compatible = "gpio-leds";
@@ -521,6 +586,21 @@ &lpass_va_macro {
status = "okay";
};
+&mdss {
+ status = "okay";
+};
+
+&mdss_dp {
+ sound-name-prefix = "Display Port0";
+
+ status = "okay";
+};
+
+&mdss_dp_out {
+ data-lanes = <0 1>;
+ remote-endpoint = <&usb_dp_qmpphy_dp_in>;
+};
+
&pcie0 {
perst-gpios = <&tlmm 87 GPIO_ACTIVE_LOW>;
wake-gpios = <&tlmm 89 GPIO_ACTIVE_HIGH>;
@@ -738,6 +818,22 @@ &sound {
"AMIC2", "MIC BIAS2",
"TX SWR_ADC1", "ADC2_OUTPUT";
+ dp0-dai-link {
+ link-name = "DP0 Playback";
+
+ codec {
+ sound-dai = <&mdss_dp>;
+ };
+
+ cpu {
+ sound-dai = <&q6apmbedai DISPLAY_PORT_RX_0>;
+ };
+
+ platform {
+ sound-dai = <&q6apm>;
+ };
+ };
+
wcd-playback-dai-link {
link-name = "WCD Playback";
@@ -982,6 +1078,58 @@ &ufs_mem_phy {
status = "okay";
};
+&usb_1 {
+ dr_mode = "host";
+
+ status = "okay";
+};
+
+&usb_1_dwc3_hs {
+ remote-endpoint = <&usb3_con_hs_in>;
+};
+
+&usb_1_hsphy {
+ vdda-pll-supply = <&vreg_l10c_0p88>;
+ vdda33-supply = <&vreg_l2b_3p072>;
+ vdda18-supply = <&vreg_l1c_1p8>;
+
+ 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;
+
+ /* RX0/TX0 is statically connected to RA620 bridge */
+ usb_1_qmpphy_out_dp: endpoint@0 {
+ reg = <0>;
+
+ data-lanes = <0 1>;
+ remote-endpoint = <&hdmi_bridge_in>;
+ };
+
+ /* RX1/TX1 is statically connected to USB-A port */
+ usb_1_qmpphy_out_usb: endpoint@1 {
+ reg = <1>;
+
+ data-lanes = <2 3>;
+ remote-endpoint = <&usb3_con_ss_in>;
+ };
+ };
+ };
+};
+
&usb_2 {
dr_mode = "host";
@@ -1048,6 +1196,10 @@ &venus {
};
/* PINCTRL - additions to nodes defined in sc7280.dtsi */
+&dp_hot_plug_det {
+ bias-disable;
+};
+
&pcie0_clkreq_n {
bias-pull-up;
drive-strength = <2>;
--
2.53.0
^ permalink raw reply related
* [PATCH 02/12] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Enable UFS controller
From: Xilin Wu @ 2026-04-07 15:19 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dmitry Baryshkov, Liam Girdwood, Mark Brown,
Judy Hsiao
Cc: linux-arm-msm, linux-kernel, devicetree, Konrad Dybcio,
linux-sound, Xilin Wu
In-Reply-To: <20260407-dragon-q6a-feat-fixes-v1-0-14aca49dde3d@radxa.com>
Add and enable UFS related nodes for this board.
Note that UFS Gear-4 Rate-B is unstable due to board and UFS module design
limitations. UFS on this board is stable when working at Gear-4 Rate-A.
Signed-off-by: Xilin Wu <sophon@radxa.com>
---
.../boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts | 23 ++++++++++++++++++++++
1 file changed, 23 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 bb5a42b038f1..c961d3ec625f 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
+++ b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
@@ -959,6 +959,29 @@ &uart5 {
status = "okay";
};
+&ufs_mem_hc {
+ reset-gpios = <&tlmm 175 GPIO_ACTIVE_LOW>;
+ vcc-supply = <&vreg_l7b_2p96>;
+ vcc-max-microamp = <800000>;
+ vccq-supply = <&vreg_l9b_1p2>;
+ vccq-max-microamp = <900000>;
+ vccq2-supply = <&vreg_l9b_1p2>;
+ vccq2-max-microamp = <1300000>;
+
+ /* Gear-4 Rate-B is unstable due to board */
+ /* and UFS module design limitations */
+ limit-gear-rate = "rate-a";
+
+ status = "okay";
+};
+
+&ufs_mem_phy {
+ vdda-phy-supply = <&vreg_l10c_0p88>;
+ vdda-pll-supply = <&vreg_l6b_1p2>;
+
+ status = "okay";
+};
+
&usb_2 {
dr_mode = "host";
--
2.53.0
^ permalink raw reply related
* [PATCH 01/12] firmware: qcom: scm: Allow QSEECOM for Radxa Dragon Q6A
From: Xilin Wu @ 2026-04-07 15:19 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dmitry Baryshkov, Liam Girdwood, Mark Brown,
Judy Hsiao
Cc: linux-arm-msm, linux-kernel, devicetree, Konrad Dybcio,
linux-sound, Xilin Wu
In-Reply-To: <20260407-dragon-q6a-feat-fixes-v1-0-14aca49dde3d@radxa.com>
add "radxa,dragon-q6a" as compatible device for QSEECOM
This is required to get access to efivars and uefi boot loader support.
Signed-off-by: Xilin Wu <sophon@radxa.com>
---
drivers/firmware/qcom/qcom_scm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
index 9b06a69d3a6d..55b18463560a 100644
--- a/drivers/firmware/qcom/qcom_scm.c
+++ b/drivers/firmware/qcom/qcom_scm.c
@@ -2319,6 +2319,7 @@ static const struct of_device_id qcom_scm_qseecom_allowlist[] __maybe_unused = {
{ .compatible = "qcom,x1e80100-crd" },
{ .compatible = "qcom,x1e80100-qcp" },
{ .compatible = "qcom,x1p42100-crd" },
+ { .compatible = "radxa,dragon-q6a" },
{ }
};
--
2.53.0
^ permalink raw reply related
* [PATCH 05/12] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Use board-specific CDSP firmware
From: Xilin Wu @ 2026-04-07 15:19 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dmitry Baryshkov, Liam Girdwood, Mark Brown,
Judy Hsiao
Cc: linux-arm-msm, linux-kernel, devicetree, Konrad Dybcio,
linux-sound, Xilin Wu
In-Reply-To: <20260407-dragon-q6a-feat-fixes-v1-0-14aca49dde3d@radxa.com>
The official boot firmware for Dragon Q6A has been switched to the
Qualcomm WP (Windows) boot firmware. Use the matching board-specific
CDSP firmware instead of the generic one so that the DSP firmware stack
remains compatible with the new boot firmware.
The corresponding custom DSP firmware has already been added to
linux-firmware:
https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/882
Signed-off-by: Xilin Wu <sophon@radxa.com>
---
arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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 8d649b3a1cfa..91f1b4f57915 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
+++ b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
@@ -783,7 +783,7 @@ &remoteproc_adsp {
};
&remoteproc_cdsp {
- firmware-name = "qcom/qcs6490/cdsp.mbn";
+ firmware-name = "qcom/qcs6490/radxa/dragon-q6a/cdsp.mbn";
status = "okay";
};
--
2.53.0
^ permalink raw reply related
* [PATCH 06/12] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Drop QSPI node and reserve its pins
From: Xilin Wu @ 2026-04-07 15:19 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dmitry Baryshkov, Liam Girdwood, Mark Brown,
Judy Hsiao
Cc: linux-arm-msm, linux-kernel, devicetree, Konrad Dybcio,
linux-sound, Xilin Wu
In-Reply-To: <20260407-dragon-q6a-feat-fixes-v1-0-14aca49dde3d@radxa.com>
The latest official boot firmware configures TrustZone to restrict
direct access to the QSPI controller. Any attempt to access it from
the non-secure world causes an immediate board reset.
Remove the QSPI flash node and its associated pinctrl states, mark
GPIOs 12-17 as reserved, and protect the QSPI clocks in the GCC
node to prevent the kernel from touching this hardware.
Signed-off-by: Xilin Wu <sophon@radxa.com>
---
.../boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts | 60 +++-------------------
1 file changed, 7 insertions(+), 53 deletions(-)
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 91f1b4f57915..8d6bb4b0724b 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
+++ b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
@@ -513,6 +513,9 @@ &gcc {
<GCC_MSS_Q6SS_BOOT_CLK_SRC>,
<GCC_MSS_Q6_MEMNOC_AXI_CLK>,
<GCC_MSS_SNOC_AXI_CLK>,
+ <GCC_QSPI_CNOC_PERIPH_AHB_CLK>,
+ <GCC_QSPI_CORE_CLK>,
+ <GCC_QSPI_CORE_CLK_SRC>,
<GCC_SEC_CTRL_CLK_SRC>,
<GCC_WPSS_AHB_BDG_MST_CLK>,
<GCC_WPSS_AHB_CLK>,
@@ -745,28 +748,6 @@ &pon_pwrkey {
status = "okay";
};
-&qspi {
- /* It's not possible to use QSPI with iommu */
- /* due to an error in qcom_smmu_write_s2cr */
- /delete-property/ iommus;
-
- pinctrl-0 = <&qspi_clk>, <&qspi_cs0>, <&qspi_data0>,
- <&qspi_data1>, <&qspi_data23>;
- pinctrl-1 = <&qspi_sleep>;
- pinctrl-names = "default", "sleep";
-
- status = "okay";
-
- spi_flash: flash@0 {
- compatible = "winbond,w25q256", "jedec,spi-nor";
- reg = <0>;
-
- spi-max-frequency = <104000000>;
- spi-tx-bus-width = <4>;
- spi-rx-bus-width = <4>;
- };
-};
-
&qupv3_id_0 {
firmware-name = "qcom/qcm6490/qupv3fw.elf";
status = "okay";
@@ -906,6 +887,10 @@ wcd_tx: codec@0,3 {
};
&tlmm {
+ /*
+ * 12-17: reserved for QSPI flash
+ */
+ gpio-reserved-ranges = <12 6>;
gpio-line-names =
/* GPIO_0 ~ GPIO_3 */
"PIN_13", "PIN_15", "", "",
@@ -1024,12 +1009,6 @@ pcie1_wake_n: pcie1-wake-n-state {
bias-pull-up;
};
- qspi_sleep: qspi-sleep-state {
- pins = "gpio12", "gpio13", "gpio14", "gpio15", "gpio16", "gpio17";
- function = "gpio";
- output-disable;
- };
-
sd_cd: sd-cd-state {
pins = "gpio91";
function = "gpio";
@@ -1210,31 +1189,6 @@ &pcie1_clkreq_n {
drive-strength = <2>;
};
-&qspi_clk {
- bias-disable;
- drive-strength = <16>;
-};
-
-&qspi_cs0 {
- bias-disable;
- drive-strength = <8>;
-};
-
-&qspi_data0 {
- bias-disable;
- drive-strength = <8>;
-};
-
-&qspi_data1 {
- bias-disable;
- drive-strength = <8>;
-};
-
-&qspi_data23 {
- bias-disable;
- drive-strength = <8>;
-};
-
&sdc1_clk {
bias-disable;
drive-strength = <16>;
--
2.53.0
^ permalink raw reply related
* [PATCH 04/12] arm64: dts: qcom: kodiak: Add I2C aliases for CCI
From: Xilin Wu @ 2026-04-07 15:19 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dmitry Baryshkov, Liam Girdwood, Mark Brown,
Judy Hsiao
Cc: linux-arm-msm, linux-kernel, devicetree, Konrad Dybcio,
linux-sound, Xilin Wu, Stephen Chen
In-Reply-To: <20260407-dragon-q6a-feat-fixes-v1-0-14aca49dde3d@radxa.com>
From: Stephen Chen <stephen@radxa.com>
Add I2C bus aliases (i2c16-i2c19) for the CCI (Camera Control Interface)
I2C buses, allowing a stable numbering of these buses independent of
probe order.
Signed-off-by: Stephen Chen <stephen@radxa.com>
Signed-off-by: Xilin Wu <sophon@radxa.com>
---
arch/arm64/boot/dts/qcom/kodiak.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
index 988ca5f7c8a0..3a30126af3d4 100644
--- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
+++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
@@ -57,6 +57,10 @@ aliases {
i2c13 = &i2c13;
i2c14 = &i2c14;
i2c15 = &i2c15;
+ i2c16 = &cci0_i2c0;
+ i2c17 = &cci0_i2c1;
+ i2c18 = &cci1_i2c0;
+ i2c19 = &cci1_i2c1;
mmc1 = &sdhc_1;
mmc2 = &sdhc_2;
spi0 = &spi0;
--
2.53.0
^ permalink raw reply related
* [PATCH 07/12] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Correct GPIO_27 label
From: Xilin Wu @ 2026-04-07 15:19 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dmitry Baryshkov, Liam Girdwood, Mark Brown,
Judy Hsiao
Cc: linux-arm-msm, linux-kernel, devicetree, Konrad Dybcio,
linux-sound, Xilin Wu, Stephen Chen
In-Reply-To: <20260407-dragon-q6a-feat-fixes-v1-0-14aca49dde3d@radxa.com>
From: Stephen Chen <stephen@radxa.com>
The label of GPIO_27 is wrong. Fix it.
Fixes: ef254b12ec60 ("arm64: dts: qcom: qcs6490: Introduce Radxa Dragon Q6A")
Signed-off-by: Stephen Chen <stephen@radxa.com>
Signed-off-by: Xilin Wu <sophon@radxa.com>
---
arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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 8d6bb4b0724b..fe3f60f8ed5a 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
+++ b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
@@ -905,7 +905,7 @@ &tlmm {
/* GPIO_20 ~ GPIO_23 */
"", "", "PIN_8", "PIN_10",
/* GPIO_24 ~ GPIO_27 */
- "PIN_3", "PIN_5", "PIN_16", "PIN_27",
+ "PIN_3", "PIN_5", "PIN_16", "PIN_18",
/* GPIO_28 ~ GPIO_31 */
"PIN_31", "PIN_11", "PIN_32", "PIN_29",
/* GPIO_32 ~ GPIO_35 */
--
2.53.0
^ permalink raw reply related
* [PATCH 08/12] arm64: dts: qcom: kodiak: Mark secondary USB controller as wakeup source
From: Xilin Wu @ 2026-04-07 15:20 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dmitry Baryshkov, Liam Girdwood, Mark Brown,
Judy Hsiao
Cc: linux-arm-msm, linux-kernel, devicetree, Konrad Dybcio,
linux-sound, Xilin Wu, Stephen Chen
In-Reply-To: <20260407-dragon-q6a-feat-fixes-v1-0-14aca49dde3d@radxa.com>
From: Stephen Chen <stephen@radxa.com>
Mark the secondary USB controller (usb_2) as a wakeup source so that it
can be used to wake the system from suspend.
Signed-off-by: Stephen Chen <stephen@radxa.com>
Signed-off-by: Xilin Wu <sophon@radxa.com>
---
arch/arm64/boot/dts/qcom/kodiak.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
index 3a30126af3d4..940ec799e905 100644
--- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
+++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
@@ -4404,6 +4404,7 @@ usb_2: usb@8c00000 {
phy-names = "usb2-phy";
maximum-speed = "high-speed";
usb-role-switch;
+ wakeup-source;
port {
usb2_role_switch: endpoint {
--
2.53.0
^ permalink raw reply related
* [PATCH 09/12] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Align reserved-memory with latest firmware map
From: Xilin Wu @ 2026-04-07 15:20 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dmitry Baryshkov, Liam Girdwood, Mark Brown,
Judy Hsiao
Cc: linux-arm-msm, linux-kernel, devicetree, Konrad Dybcio,
linux-sound, Xilin Wu
In-Reply-To: <20260407-dragon-q6a-feat-fixes-v1-0-14aca49dde3d@radxa.com>
The current board DTS no longer matches the reserved-memory carveouts
used by the latest official Dragon Q6A firmware. Update the memory map
to keep the DTS in sync with firmware expectations.
Signed-off-by: Xilin Wu <sophon@radxa.com>
---
.../boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts | 43 +++++++++-------------
1 file changed, 17 insertions(+), 26 deletions(-)
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 fe3f60f8ed5a..5679f38de5b3 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
+++ b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
@@ -22,7 +22,9 @@
#include "qcs6490-audioreach.dtsi"
/delete-node/ &adsp_mem;
+/delete-node/ &adsp_rpc_remote_heap_mem;
/delete-node/ &cdsp_mem;
+/delete-node/ &gpu_zap_mem;
/delete-node/ &ipa_fw_mem;
/delete-node/ &mpss_mem;
/delete-node/ &remoteproc_mpss;
@@ -33,7 +35,6 @@
/delete-node/ &wlan_ce_mem;
/delete-node/ &wlan_fw_mem;
/delete-node/ &wpss_mem;
-/delete-node/ &xbl_mem;
/ {
model = "Radxa Dragon Q6A";
@@ -193,43 +194,33 @@ user-led {
};
reserved-memory {
- xbl_mem: xbl@80700000 {
- reg = <0x0 0x80700000 0x0 0x100000>;
+ lpass_ml_mem: lpass-ml@81800000 {
+ reg = <0x0 0x81800000 0x0 0xf00000>;
no-map;
};
- cdsp_secure_heap_mem: cdsp-secure-heap@81800000 {
- reg = <0x0 0x81800000 0x0 0x1e00000>;
+ cdsp_secure_heap_mem: cdsp-secure-heap@82700000 {
+ reg = <0x0 0x82700000 0x0 0x10000>;
no-map;
};
- camera_mem: camera@84300000 {
- reg = <0x0 0x84300000 0x0 0x500000>;
+ adsp_mem: adsp@8b800000 {
+ reg = <0x0 0x8b800000 0x0 0x2800000>;
no-map;
};
- adsp_mem: adsp@84800000 {
- reg = <0x0 0x84800000 0x0 0x2800000>;
+ cdsp_mem: cdsp@8e000000 {
+ reg = <0x0 0x8e000000 0x0 0x1e00000>;
no-map;
};
- cdsp_mem: cdsp@87000000 {
- reg = <0x0 0x87000000 0x0 0x1e00000>;
+ video_mem: video@8fe00000 {
+ reg = <0x0 0x8fe00000 0x0 0x500000>;
no-map;
};
- video_mem: video@88e00000 {
- reg = <0x0 0x88e00000 0x0 0x700000>;
- no-map;
- };
-
- cvp_mem: cvp@89500000 {
- reg = <0x0 0x89500000 0x0 0x500000>;
- no-map;
- };
-
- gpu_microcode_mem: gpu-microcode@89a00000 {
- reg = <0x0 0x89a00000 0x0 0x2000>;
+ gpu_zap_mem: zap@90300000 {
+ reg = <0x0 0x90300000 0x0 0x5000>;
no-map;
};
@@ -249,12 +240,12 @@ qtee_mem: qtee@c1300000 {
};
trusted_apps_mem: trusted-apps@c1800000 {
- reg = <0x0 0xc1800000 0x0 0x1c00000>;
+ reg = <0x0 0xc1800000 0x0 0x2200000>;
no-map;
};
- debug_vm_mem: debug-vm@d0600000 {
- reg = <0x0 0xd0600000 0x0 0x100000>;
+ adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap@c6500000 {
+ reg = <0x0 0xc6500000 0x0 0x800000>;
no-map;
};
};
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox