* [PATCH v2 0/5] ARM/arm64: dts: st: fix node ordering in ST board device trees
From: Amelie Delaunay @ 2026-06-12 12:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue
Cc: devicetree, linux-stm32, linux-arm-kernel, linux-kernel,
Amelie Delaunay
In the ST board DTS files, &label entries must be ordered
alphanumerically.
Over time, several nodes ended up out of order as a side effect of
adding new features or refactoring existing ones.
This series restores the correct alphanumeric ordering across
all ST board DTS files, with no functional change.
Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
---
Changes in v2:
- Fix typo in commit message of patch 1.
- Link to v1: https://lore.kernel.org/r/20260611-node_reordering-v1-0-7e519f2cb456@foss.st.com
---
Amelie Delaunay (5):
arm64: dts: st: reorder ommanager node in stm32mp257f-ev1.dts
ARM: dts: stm32: reorder cs_cti_trace node in stm32mp135f-dk.dts
ARM: dts: stm32: reorder cs_cti_trace node in stm32mp15xx-dkx.dtsi
ARM: dts: stm32: reorder cs_cti_trace node in stm32mp157c-ev1.dts
ARM: dts: stm32: reorder mdma1 node in stm32mp15*-scmi.dts
arch/arm/boot/dts/st/stm32mp135f-dk.dts | 4 +-
arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts | 8 ++--
arch/arm/boot/dts/st/stm32mp157c-dk2-scmi.dts | 8 ++--
arch/arm/boot/dts/st/stm32mp157c-ed1-scmi.dts | 8 ++--
arch/arm/boot/dts/st/stm32mp157c-ev1-scmi.dts | 8 ++--
arch/arm/boot/dts/st/stm32mp157c-ev1.dts | 6 +--
arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi | 6 +--
arch/arm64/boot/dts/st/stm32mp257f-ev1.dts | 56 +++++++++++++--------------
8 files changed, 52 insertions(+), 52 deletions(-)
---
base-commit: fba4a31a7f3b6b29b01c83180f83e7ed4c398738
change-id: 20260611-node_reordering-4b9b132b007f
Best regards,
--
Amelie Delaunay <amelie.delaunay@foss.st.com>
^ permalink raw reply
* Re: [PATCH 3/3] iio: magnetometer: add driver for QST QMC5883L Sensor
From: sashiko-bot @ 2026-06-12 12:56 UTC (permalink / raw)
To: Siratul Islam; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260612124557.13750-4-email@sirat.me>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Returning early with `-ERANGE` when the overflow flag (OVL) is set prevents the data registers from being read, leaving the sensor permanently stuck in an overflow state.
- [Medium] The device is left in continuous measurement mode on driver removal or initialization failure, causing an unnecessary power drain.
--
commit 8aa498258e2b8bddd48bf3c46ef8555a7376ea6e
Author: Siratul Islam <email@sirat.me>
iio: magnetometer: add driver for QST QMC5883L Sensor
This commit adds a new I2C driver for the QST QMC5883L 3-Axis Magnetic Sensor,
including continuous measurement mode support and scaling options.
> diff --git a/drivers/iio/magnetometer/qmc5883l.c b/drivers/iio/magnetometer/qmc5883l.c
> new file mode 100644
> index 0000000000000..055e51570635c
> --- /dev/null
> +++ b/drivers/iio/magnetometer/qmc5883l.c
[ ... ]
> +static int qmc5883l_take_measurement(struct iio_dev *indio_dev, int index,
> + int *val)
> +{
> + struct qmc5883l_data *data = iio_priv(indio_dev);
> + unsigned int status;
> + __le16 buf[3];
> + int ret;
> +
> + scoped_guard(mutex, &data->mutex)
> + {
> + /* 50ms headroom over the slowest ODR (10Hz) */
> + ret = regmap_read_poll_timeout(data->regmap,
> + QMC5883L_REG_STATUS1, status,
> + (status & QMC5883L_STATUS_DRDY),
> + 2 * USEC_PER_MSEC,
> + 150 * USEC_PER_MSEC);
> + if (ret)
> + return ret;
> +
> + if (status & QMC5883L_STATUS_OVL)
> + return -ERANGE;
[Severity: High]
If we return -ERANGE here when the overflow flag (OVL) is set, does the
sensor get permanently stuck in an overflow state?
In typical I2C magnetometers, the Data Ready (DRDY) and Overflow (OVL)
status bits are only cleared by reading the data registers. By returning
early without reading the data registers via regmap_bulk_read(), the DRDY
and OVL flags might remain set indefinitely.
On subsequent measurement attempts, regmap_read_poll_timeout() will return
immediately and this check will instantly fail again, potentially locking up
the sensor until a reset.
> +
> + ret = regmap_bulk_read(data->regmap, QMC5883L_REG_X_LSB, buf,
> + sizeof(buf));
[ ... ]
> +static int qmc5883l_init(struct qmc5883l_data *data)
> +{
> + unsigned int reg;
> + int ret;
> +
[ ... ]
> + data->odr = QMC5883L_ODR_50HZ;
> + data->range = QMC5883L_RNG_2G;
> + data->osr = QMC5883L_OSR_64;
> +
> + ret = regmap_write(data->regmap, QMC5883L_REG_CTRL1,
> + (QMC5883L_MODE_CONT | data->odr | data->range |
> + data->osr));
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
[ ... ]
> +static int qmc5883l_probe(struct i2c_client *client)
> +{
[ ... ]
> + indio_dev->name = "qmc5883l";
> + indio_dev->info = &qmc5883l_info;
> + indio_dev->channels = qmc5883l_channels;
> + indio_dev->num_channels = ARRAY_SIZE(qmc5883l_channels);
> + indio_dev->modes = INDIO_DIRECT_MODE;
> +
> + ret = qmc5883l_init(data);
> + if (ret)
> + return dev_err_probe(dev, ret, "qmc5883l init failed\n");
> +
> + return devm_iio_device_register(dev, indio_dev);
> +}
[Severity: Medium]
Is there a missing devm teardown callback to power down the sensor when the
driver is unbound or if registration fails?
In qmc5883l_init(), the sensor is placed into continuous sampling mode. If
devm_iio_device_register() fails, or when the driver is removed, there
doesn't appear to be a registered cleanup action (e.g., via
devm_add_action_or_reset()) to place the device back into standby mode.
Although the devm core disables the VDD/VDDIO regulators during teardown,
these regulators might be shared with other components on the board. If the
shared supply remains active, the sensor could continue continuous sampling
and unnecessarily drain power.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612124557.13750-1-email@sirat.me?part=3
^ permalink raw reply
* Re: [PATCH v6 02/11] ARM: dts: renesas: r8a7740: Add clocks for FSI
From: Bui Duc Phuc @ 2026-06-12 12:54 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Kuninori Morimoto, Mark Brown, Liam Girdwood, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Jaroslav Kysela,
Takashi Iwai, linux-sound, linux-renesas-soc, devicetree,
linux-kernel
In-Reply-To: <CAMuHMdWsLeEzjCPHEa=nY-kC0n34RHL3kUMW30vneUajCWwTRg@mail.gmail.com>
Hi Geert,
>
> According to my schematics (RevA), R120 is not populated, but R250 is.
> So the 12.288 MHz clock is fed to both the FSIACK-pin of R-Mobile A1,
> and the MCLK-pin of the WM8978 codec.
> Which revision of the schematics and board do you have?
>
Oh, sorry, I misread it. You're right, mine is also Rev A, and R120 is
not populated, but R250 is.
>
> I haven't located R120 and R250 yet, so I don't know which
> configuration my board has.
>
Please flip the board over; these resistors are located on the bottom
side of the board rather than the top.
Other components like R123, R124, R139, and R227 are on the top side,
but they are only visible after removing the display.
>
> That information is found in the R-Mobile A1 docs (PORT11):
>
> Table 1.3 Pin Assignment (505-Pin BGA Package)
> Ball No. / Pin Name / Multiplexed Pin Functions / GPIO
> G3 / FSIACK / FSIACK/FSIBCK / PORT11
>
> Table 54.1 List of Multiplexed Pins
> Pin Name / Function 0 / Function 1 / Function 2
> FSIACK / PORT11 / FSIACK / FSIBCK
>
It would be helpful if there were a more detailed Armadillo schematic available.
The R-Mobile A1 documentation (PORT11) is generic and shared across
multiple boards,
so it does not necessarily reflect the exact wiring used on Armadillo.
I did look at the board support code and pin configuration some time
ago, and I also tested audio output over HDMI successfully.
As far as I remember, these pins can be configured as either inputs or
outputs. For example:
fsia_pins: sounda {
groups = "fsia_sclk_in", "fsia_mclk_out",
"fsia_data_in_1", "fsia_data_out_0";
function = "fsia";
};
I'll take another look at it when I have some time next week.
At the moment I'm busy working on a few ASoC cleanup patches,
so I haven't had a chance to investigate this further.
Best regards,
Phuc
^ permalink raw reply
* [PATCH v2] arm64: dts: qcom: qcm6490-fairphone-fp5: Add AW88261 amplifiers
From: Luca Weiss @ 2026-06-12 12:52 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Val Packett, Bharadwaj Raju, Bhushan Shah
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel, Konrad Dybcio, Luca Weiss
Add nodes for the two AW88261 amplifiers, for the top and bottom
speakers of this phone. Hook them up to the sound card.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Co-developed-by: Bharadwaj Raju <bharadwaj.raju@machinesoul.in>
Signed-off-by: Bharadwaj Raju <bharadwaj.raju@machinesoul.in>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
Changes in v2:
- Remove awinic,sync-flag for both amps since it's actually not needed
(Bhushan, off-list)
- Remove RFC prefix
- Pick up tags
- Link to v1: https://patch.msgid.link/20260522-fp5-aw88261-v1-1-20e412eb4c4e@fairphone.com
---
arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 57 +++++++++++++++++++++-
1 file changed, 55 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
index 04cb9230d29f..6ed34b5a99b6 100644
--- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
+++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
@@ -866,8 +866,33 @@ vibrator@5a {
&i2c2 {
status = "okay";
- /* AW88261FCR amplifier @ 34 */
- /* AW88261FCR amplifier @ 35 */
+ /* Top speaker / ear speaker */
+ aw88261_l: audio-codec@34 {
+ compatible = "awinic,aw88261";
+ reg = <0x34>;
+
+ dvdd-supply = <&vreg_l18b>;
+ sound-name-prefix = "Amplifier L";
+ firmware-name = "qcom/qcm6490/fairphone5/aw88261_acf.bin";
+
+ awinic,audio-channel = <0>;
+
+ #sound-dai-cells = <0>;
+ };
+
+ /* Bottom speaker */
+ aw88261_r: audio-codec@35 {
+ compatible = "awinic,aw88261";
+ reg = <0x35>;
+
+ dvdd-supply = <&vreg_l18b>;
+ sound-name-prefix = "Amplifier R";
+ firmware-name = "qcom/qcm6490/fairphone5/aw88261_acf.bin";
+
+ awinic,audio-channel = <1>;
+
+ #sound-dai-cells = <0>;
+ };
};
&i2c4 {
@@ -1161,6 +1186,13 @@ &pon_resin {
status = "okay";
};
+&q6afedai {
+ dai@127 {
+ reg = <QUINARY_MI2S_RX>;
+ qcom,sd-lines = <0>;
+ };
+};
+
&qup_spi13_cs {
drive-strength = <6>;
bias-disable;
@@ -1238,6 +1270,11 @@ &sound {
compatible = "fairphone,fp5-sndcard";
model = "Fairphone 5";
+ pinctrl-0 = <&lpass_i2s1_active>;
+ pinctrl-1 = <&lpass_i2s1_sleep>;
+ pinctrl-names = "default",
+ "sleep";
+
mm1-dai-link {
link-name = "MultiMedia1";
@@ -1246,6 +1283,22 @@ cpu {
};
};
+ i2s-dai-link {
+ link-name = "Quinary MI2S Playback";
+
+ codec {
+ sound-dai = <&aw88261_l>, <&aw88261_r>;
+ };
+
+ cpu {
+ sound-dai = <&q6afedai QUINARY_MI2S_RX>;
+ };
+
+ platform {
+ sound-dai = <&q6routing>;
+ };
+ };
+
displayport-rx-dai-link {
link-name = "DisplayPort Playback";
---
base-commit: e7b907ffb2cd66314df92360e41f7bd5fdaa8182
change-id: 20260522-fp5-aw88261-a02bb0e4b697
Best regards,
--
Luca Weiss <luca.weiss@fairphone.com>
^ permalink raw reply related
* Re: [PATCH v6 4/5] iio: adc: versal-sysmon: add threshold event support
From: Jonathan Cameron @ 2026-06-12 12:52 UTC (permalink / raw)
To: Salih Erim
Cc: andy, dlechner, nuno.sa, robh, krzk+dt, conor+dt, conall.ogriofa,
michal.simek, linux, erimsalih, linux-iio, devicetree,
linux-kernel
In-Reply-To: <20260611222738.2035062-5-salih.erim@amd.com>
On Thu, 11 Jun 2026 23:27:37 +0100
Salih Erim <salih.erim@amd.com> wrote:
> Add threshold event support for temperature and supply voltage
> channels.
>
> Temperature events:
> - Rising threshold with configurable value
> - Over-temperature (OT) alarm with separate threshold
Ah. I ask about this below. If this applies to the same channel
as the main threshold we generally don't support that in IIO and
definitely not by introducing a 'magic' extra channel.
See below.
> - Per-channel hysteresis as a millicelsius value
> - Event direction is IIO_EV_DIR_RISING (hysteresis mode)
>
> Supply voltage events:
> - Rising/falling threshold per supply channel
> - Per-channel alarm enable via alarm configuration registers
>
> The hardware supports both window and hysteresis alarm modes for
> temperature. This driver uses hysteresis mode, where the upper
> threshold triggers the alarm and the lower threshold clears it
> (re-arm point). The hardware has a single ISR bit per temperature
> channel with no indication of which threshold was crossed, so
> hysteresis mode is the natural fit. The lower threshold register
> is computed internally as (upper - hysteresis).
>
> Hysteresis is stored in the driver as a millicelsius value,
> initialized from the hardware registers at probe. Writing the
> rising threshold or hysteresis recomputes the lower register.
> ALARM_CONFIG is hard-coded to hysteresis mode during init.
>
> The interrupt handler masks active threshold interrupts (which are
> level-sensitive) and schedules a delayed worker to poll for condition
> clear before unmasking. When no hardware IRQ is available, event
> channels are not created and interrupt init is skipped, since the
> I2C regmap backend cannot be called from atomic context.
>
> When disabling a supply channel alarm, the group interrupt remains
> active if any other channel in the same alarm group still has an
> alarm enabled.
>
> Signed-off-by: Salih Erim <salih.erim@amd.com>
Some follow on questions on the temperature channels and one thing
Sashiko noticed that looks real.
> diff --git a/drivers/iio/adc/versal-sysmon-core.c b/drivers/iio/adc/versal-sysmon-core.c
> index c875d156dbe..20fd3a87d44 100644
> --- a/drivers/iio/adc/versal-sysmon-core.c
> +++ b/drivers/iio/adc/versal-sysmon-core.c
> @@ -11,7 +11,9 @@
> #include <linux/bitops.h>
> #include <linux/cleanup.h>
> #include <linux/device.h>
> +#include <linux/devm-helpers.h>
> #include <linux/err.h>
> +#include <linux/interrupt.h>
> #include <linux/module.h>
> #include <linux/property.h>
> #include <linux/regmap.h>
> @@ -19,10 +21,19 @@
> #include <linux/sysfs.h>
> #include <linux/units.h>
>
> +#include <linux/iio/events.h>
> #include <linux/iio/iio.h>
>
> #include "versal-sysmon.h"
>
> +/* OT and TEMP hysteresis mode bits in SYSMON_TEMP_EV_CFG */
> +#define SYSMON_OT_HYST_MASK BIT(0)
> +#define SYSMON_TEMP_HYST_MASK BIT(1)
> +
> +/* Compute alarm register offset from a channel address */
> +#define SYSMON_ALARM_OFFSET(addr) \
> + (SYSMON_ALARM_REG + ((addr) / SYSMON_ALARM_BITS_PER_REG) * SYSMON_REG_STRIDE)
> +
> #define SYSMON_CHAN_TEMP(_chan, _address, _name) \
> { \
> .type = IIO_TEMP, \
> @@ -34,14 +45,87 @@
> .datasheet_name = _name, \
> }
>
> +#define SYSMON_CHAN_TEMP_EVENT(_chan, _address, _name, _events) \
> +{ \
> + .type = IIO_TEMP, \
> + .indexed = 1, \
> + .address = _address, \
> + .channel = _chan, \
> + .event_spec = _events, \
> + .num_event_specs = ARRAY_SIZE(_events), \
> + .datasheet_name = _name, \
> +}
> +
> +enum sysmon_alarm_bit {
> + SYSMON_BIT_ALARM0 = 0,
> + SYSMON_BIT_ALARM1 = 1,
> + SYSMON_BIT_ALARM2 = 2,
> + SYSMON_BIT_ALARM3 = 3,
> + SYSMON_BIT_ALARM4 = 4,
> + SYSMON_BIT_OT = 8,
> + SYSMON_BIT_TEMP = 9,
> +};
> /* Static temperature channels (always present) */
> -static const struct iio_chan_spec temp_channels[] = {
> +static const struct iio_chan_spec temp_channels_no_events[] = {
> SYSMON_CHAN_TEMP(0, SYSMON_TEMP_MAX, "temp"),
> SYSMON_CHAN_TEMP(1, SYSMON_TEMP_MIN, "min"),
> SYSMON_CHAN_TEMP(2, SYSMON_TEMP_MAX_MAX, "max_max"),
> SYSMON_CHAN_TEMP(3, SYSMON_TEMP_MIN_MIN, "min_min"),
> };
>
> +/* Static temperature channels with event support (when IRQ available) */
> +static const struct iio_chan_spec temp_channels_with_events[] = {
> + SYSMON_CHAN_TEMP(0, SYSMON_TEMP_MAX, "temp"),
> + SYSMON_CHAN_TEMP(1, SYSMON_TEMP_MIN, "min"),
> + SYSMON_CHAN_TEMP(2, SYSMON_TEMP_MAX_MAX, "max_max"),
> + SYSMON_CHAN_TEMP(3, SYSMON_TEMP_MIN_MIN, "min_min"),
> + SYSMON_CHAN_TEMP_EVENT(4, SYSMON_ADDR_TEMP_EVENT, "temp",
> + sysmon_temp_events),
Is this not an event on channel 0? Why does it need a separate one?
> + SYSMON_CHAN_TEMP_EVENT(5, SYSMON_ADDR_OT_EVENT, "ot",
Why two separate channels for events? Are we dealing with two separate
events on the same signal? Generally we don't support that for IIO because
it's largely meaningless except in hwmon usecases - what is the point in two
thresholds if they are reported through the same path? Just use one and update
it if you want to add another level of detection.
> + sysmon_temp_events),
> +};
> +
> +static int sysmon_read_event_config(struct iio_dev *indio_dev,
> + const struct iio_chan_spec *chan,
> + enum iio_event_type type,
> + enum iio_event_direction dir)
> +{
> + u32 alarm_event_mask = sysmon_get_event_mask(chan->address);
> + struct sysmon *sysmon = iio_priv(indio_dev);
> + unsigned int imr;
> + int config_value;
> + int ret;
> +
> + ret = regmap_read(sysmon->regmap, SYSMON_IMR, &imr);
> + if (ret)
> + return ret;
> +
> + /* IMR bits are 1=masked, invert to get 1=enabled */
> + imr = ~imr;
> +
> + switch (chan->type) {
> + case IIO_VOLTAGE:
> + config_value = sysmon_read_alarm_config(sysmon, chan->address);
> + if (config_value < 0)
> + return config_value;
> + return config_value && (imr & alarm_event_mask);
> +
> + case IIO_TEMP:
> + return !!(imr & alarm_event_mask);
Sashiko made a perhaps insightful observation here. When the interrupt
is masked between sending an event and the worker reenabling it does
this give an unexpected value to userspace? I think that condition
we'd kind of expect this to return 0.
https://sashiko.dev/#/patchset/20260611222738.2035062-1-salih.erim%40amd.com
I think the rest of the feedback is probably false positives or debatable
stuff but this one rang true. Please do take a look at the other stuff
as I may have missed something (maybe the comment about needing to disable
event interrupt generation is true?)
> +
> + default:
> + return -EINVAL;
> + }
> +
^ permalink raw reply
* [PATCH 3/3] iio: magnetometer: add driver for QST QMC5883L Sensor
From: Siratul Islam @ 2026-06-12 12:45 UTC (permalink / raw)
To: jic23, robh, krzk+dt, conor+dt
Cc: dlechner, nuno.sa, andy, linux-iio, devicetree, linux-kernel,
Siratul Islam
In-Reply-To: <20260612124557.13750-1-email@sirat.me>
Add driver for the QST QMC5883L 3-Axis Magnetic Sensor
connected via i2c.
Signed-off-by: Siratul Islam <email@sirat.me>
---
MAINTAINERS | 1 +
drivers/iio/magnetometer/Kconfig | 11 +
drivers/iio/magnetometer/Makefile | 2 +
drivers/iio/magnetometer/qmc5883l.c | 512 ++++++++++++++++++++++++++++
4 files changed, 526 insertions(+)
create mode 100644 drivers/iio/magnetometer/qmc5883l.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 310074b34072..f94da70b91af 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21792,6 +21792,7 @@ M: Siratul Islam <email@sirat.me>
L: linux-iio@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/iio/magnetometer/qstcorp,qmc5883l.yaml
+F: drivers/iio/magnetometer/qmc5883l.c
QT1010 MEDIA DRIVER
L: linux-media@vger.kernel.org
diff --git a/drivers/iio/magnetometer/Kconfig b/drivers/iio/magnetometer/Kconfig
index fb313e591e85..615564174086 100644
--- a/drivers/iio/magnetometer/Kconfig
+++ b/drivers/iio/magnetometer/Kconfig
@@ -198,6 +198,17 @@ config INFINEON_TLV493D
To compile this driver as a module, choose M here: the module
will be called tlv493d.
+config QMC5883L
+ tristate "QST QMC5883L 3-Axis Magnetic Sensor"
+ depends on I2C
+ select REGMAP_I2C
+ help
+ Say Y here to add support driver for QST QMC5883L 3-Axis
+ Magnetic Sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called qmc5883l.
+
config SENSORS_HMC5843
tristate
select IIO_BUFFER
diff --git a/drivers/iio/magnetometer/Makefile b/drivers/iio/magnetometer/Makefile
index 5bd227f8c120..552682555d86 100644
--- a/drivers/iio/magnetometer/Makefile
+++ b/drivers/iio/magnetometer/Makefile
@@ -26,6 +26,8 @@ obj-$(CONFIG_IIO_ST_MAGN_SPI_3AXIS) += st_magn_spi.o
obj-$(CONFIG_INFINEON_TLV493D) += tlv493d.o
+obj-$(CONFIG_QMC5883L) += qmc5883l.o
+
obj-$(CONFIG_SENSORS_HMC5843) += hmc5843_core.o
obj-$(CONFIG_SENSORS_HMC5843_I2C) += hmc5843_i2c.o
obj-$(CONFIG_SENSORS_HMC5843_SPI) += hmc5843_spi.o
diff --git a/drivers/iio/magnetometer/qmc5883l.c b/drivers/iio/magnetometer/qmc5883l.c
new file mode 100644
index 000000000000..055e51570635
--- /dev/null
+++ b/drivers/iio/magnetometer/qmc5883l.c
@@ -0,0 +1,512 @@
+// SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+/*
+ * Support for QST QMC5883L 3-Axis Magnetic Sensor on i2c bus.
+ *
+ * Copyright (C) 2026 Siratul Islam <email@sirat.me>
+ *
+ * Datasheet available at
+ * <https://www.qstcorp.com/upload/pdf/202512/13-52-04%20QMC5883L%20Datasheet%20Rev.%20B.pdf>
+ *
+ * Default 7-bit i2c slave address 0x0D.
+ *
+ */
+
+#include <linux/array_size.h>
+#include <linux/bits.h>
+#include <linux/bitfield.h>
+#include <linux/cleanup.h>
+#include <linux/delay.h>
+#include <linux/dev_printk.h>
+#include <linux/err.h>
+#include <linux/iio/iio.h>
+#include <linux/i2c.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mod_devicetable.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <linux/time.h>
+
+#include <asm/byteorder.h>
+
+#define QMC5883L_REG_X_LSB 0x00
+#define QMC5883L_REG_STATUS1 0x06
+#define QMC5883L_REG_CTRL1 0x09
+#define QMC5883L_REG_CTRL2 0x0A
+#define QMC5883L_REG_SET_RESET 0x0B
+#define QMC5883L_REG_ID 0x0D
+
+#define QMC5883L_CHIP_ID 0xFF
+
+#define QMC5883L_MODE_MASK GENMASK(1, 0)
+#define QMC5883L_ODR_MASK GENMASK(3, 2)
+#define QMC5883L_RNG_MASK GENMASK(5, 4)
+#define QMC5883L_OSR_MASK GENMASK(7, 6)
+
+#define QMC5883L_MODE_STANDBY FIELD_PREP_CONST(QMC5883L_MODE_MASK, 0x00)
+#define QMC5883L_MODE_CONT FIELD_PREP_CONST(QMC5883L_MODE_MASK, 0x01)
+
+#define QMC5883L_ODR_10HZ FIELD_PREP_CONST(QMC5883L_ODR_MASK, 0x00)
+#define QMC5883L_ODR_50HZ FIELD_PREP_CONST(QMC5883L_ODR_MASK, 0x01)
+#define QMC5883L_ODR_100HZ FIELD_PREP_CONST(QMC5883L_ODR_MASK, 0x02)
+#define QMC5883L_ODR_200HZ FIELD_PREP_CONST(QMC5883L_ODR_MASK, 0x03)
+
+#define QMC5883L_RNG_2G FIELD_PREP_CONST(QMC5883L_RNG_MASK, 0x00)
+#define QMC5883L_RNG_8G FIELD_PREP_CONST(QMC5883L_RNG_MASK, 0x01)
+
+#define QMC5883L_OSR_512 FIELD_PREP_CONST(QMC5883L_OSR_MASK, 0x00)
+#define QMC5883L_OSR_256 FIELD_PREP_CONST(QMC5883L_OSR_MASK, 0x01)
+#define QMC5883L_OSR_128 FIELD_PREP_CONST(QMC5883L_OSR_MASK, 0x02)
+#define QMC5883L_OSR_64 FIELD_PREP_CONST(QMC5883L_OSR_MASK, 0x03)
+
+#define QMC5883L_STATUS_DRDY BIT(0)
+#define QMC5883L_STATUS_OVL BIT(1)
+
+#define QMC5883L_SET_RESET_VAL BIT(0)
+#define QMC5883L_INT_DISABLE BIT(0)
+#define QMC5883L_SOFT_RESET BIT(7)
+
+#define QMC5883L_SCALE_2G 83333
+#define QMC5883L_SCALE_8G 333333
+
+/* POR completion time max per datasheet */
+#define QMC5883L_PORT_US 350
+
+struct qmc5883l_data {
+ struct regmap *regmap;
+ struct mutex mutex; /* update and read regmap data */
+ u8 range;
+ u8 odr;
+ u8 osr;
+};
+
+enum qmc5883l_chan {
+ QMC5883L_AXIS_X,
+ QMC5883L_AXIS_Y,
+ QMC5883L_AXIS_Z,
+};
+
+static const int qmc5883l_odr_avail[] = { 10, 50, 100, 200 };
+
+static const int qmc5883l_osr_avail[] = { 512, 256, 128, 64 };
+
+static const int qmc5883l_rng_avail[] = {
+ 0, QMC5883L_SCALE_2G, /* 2G */
+ 0, QMC5883L_SCALE_8G, /* 8G */
+};
+
+static int qmc5883l_take_measurement(struct iio_dev *indio_dev, int index,
+ int *val)
+{
+ struct qmc5883l_data *data = iio_priv(indio_dev);
+ unsigned int status;
+ __le16 buf[3];
+ int ret;
+
+ scoped_guard(mutex, &data->mutex)
+ {
+ /* 50ms headroom over the slowest ODR (10Hz) */
+ ret = regmap_read_poll_timeout(data->regmap,
+ QMC5883L_REG_STATUS1, status,
+ (status & QMC5883L_STATUS_DRDY),
+ 2 * USEC_PER_MSEC,
+ 150 * USEC_PER_MSEC);
+ if (ret)
+ return ret;
+
+ if (status & QMC5883L_STATUS_OVL)
+ return -ERANGE;
+
+ ret = regmap_bulk_read(data->regmap, QMC5883L_REG_X_LSB, buf,
+ sizeof(buf));
+ if (ret)
+ return ret;
+
+ *val = (s16)le16_to_cpu(buf[index]);
+ }
+
+ return 0;
+}
+
+static int qmc5883l_read_raw(struct iio_dev *indio_dev,
+ const struct iio_chan_spec *chan, int *val,
+ int *val2, long mask)
+{
+ struct qmc5883l_data *data = iio_priv(indio_dev);
+ int ret;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ if (!iio_device_claim_direct(indio_dev))
+ return -EBUSY;
+ ret = qmc5883l_take_measurement(indio_dev, chan->address, val);
+ iio_device_release_direct(indio_dev);
+ if (ret)
+ return ret;
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_SCALE:
+ scoped_guard(mutex, &data->mutex)
+ {
+ *val = 0;
+ *val2 = data->range == QMC5883L_RNG_2G ?
+ QMC5883L_SCALE_2G :
+ QMC5883L_SCALE_8G;
+ }
+ return IIO_VAL_INT_PLUS_NANO;
+ case IIO_CHAN_INFO_SAMP_FREQ:
+ scoped_guard(mutex, &data->mutex)
+ {
+ switch (data->odr) {
+ case QMC5883L_ODR_200HZ:
+ *val = 200;
+ break;
+ case QMC5883L_ODR_100HZ:
+ *val = 100;
+ break;
+ case QMC5883L_ODR_50HZ:
+ *val = 50;
+ break;
+ case QMC5883L_ODR_10HZ:
+ *val = 10;
+ break;
+ default:
+ return -EINVAL;
+ }
+ }
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
+ scoped_guard(mutex, &data->mutex)
+ {
+ switch (data->osr) {
+ case QMC5883L_OSR_64:
+ *val = 64;
+ break;
+ case QMC5883L_OSR_128:
+ *val = 128;
+ break;
+ case QMC5883L_OSR_256:
+ *val = 256;
+ break;
+ case QMC5883L_OSR_512:
+ *val = 512;
+ break;
+ default:
+ return -EINVAL;
+ }
+ }
+ return IIO_VAL_INT;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int qmc5883l_write_raw(struct iio_dev *indio_dev,
+ const struct iio_chan_spec *chan, int val,
+ int val2, long mask)
+{
+ struct qmc5883l_data *data = iio_priv(indio_dev);
+ u8 rng;
+ u8 osr;
+ u8 odr;
+ int ret;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_SCALE:
+ if (val != 0)
+ return -EINVAL;
+
+ switch (val2) {
+ case QMC5883L_SCALE_2G:
+ rng = QMC5883L_RNG_2G;
+ break;
+ case QMC5883L_SCALE_8G:
+ rng = QMC5883L_RNG_8G;
+ break;
+ default:
+ return -EINVAL;
+ }
+ scoped_guard(mutex, &data->mutex)
+ {
+ ret = regmap_update_bits(data->regmap,
+ QMC5883L_REG_CTRL1,
+ QMC5883L_RNG_MASK, rng);
+ if (ret)
+ return ret;
+ data->range = rng;
+ }
+ break;
+ case IIO_CHAN_INFO_SAMP_FREQ:
+ switch (val) {
+ case 200:
+ odr = QMC5883L_ODR_200HZ;
+ break;
+ case 100:
+ odr = QMC5883L_ODR_100HZ;
+ break;
+ case 50:
+ odr = QMC5883L_ODR_50HZ;
+ break;
+ case 10:
+ odr = QMC5883L_ODR_10HZ;
+ break;
+ default:
+ return -EINVAL;
+ }
+ scoped_guard(mutex, &data->mutex)
+ {
+ ret = regmap_update_bits(data->regmap,
+ QMC5883L_REG_CTRL1,
+ QMC5883L_ODR_MASK, odr);
+ if (ret)
+ return ret;
+ data->odr = odr;
+ }
+ break;
+ case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
+ switch (val) {
+ case 64:
+ osr = QMC5883L_OSR_64;
+ break;
+ case 128:
+ osr = QMC5883L_OSR_128;
+ break;
+ case 256:
+ osr = QMC5883L_OSR_256;
+ break;
+ case 512:
+ osr = QMC5883L_OSR_512;
+ break;
+ default:
+ return -EINVAL;
+ }
+ scoped_guard(mutex, &data->mutex)
+ {
+ ret = regmap_update_bits(data->regmap,
+ QMC5883L_REG_CTRL1,
+ QMC5883L_OSR_MASK, osr);
+ if (ret)
+ return ret;
+ data->osr = osr;
+ }
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int qmc5883l_read_avail(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ const int **vals, int *type, int *length,
+ long mask)
+{
+ switch (mask) {
+ case IIO_CHAN_INFO_SAMP_FREQ:
+ *vals = qmc5883l_odr_avail;
+ *type = IIO_VAL_INT;
+ *length = ARRAY_SIZE(qmc5883l_odr_avail);
+ return IIO_AVAIL_LIST;
+ case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
+ *vals = qmc5883l_osr_avail;
+ *type = IIO_VAL_INT;
+ *length = ARRAY_SIZE(qmc5883l_osr_avail);
+ return IIO_AVAIL_LIST;
+ case IIO_CHAN_INFO_SCALE:
+ *vals = qmc5883l_rng_avail;
+ *type = IIO_VAL_INT_PLUS_NANO;
+ *length = ARRAY_SIZE(qmc5883l_rng_avail);
+ return IIO_AVAIL_LIST;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int qmc5883l_write_raw_get_fmt(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ long mask)
+{
+ switch (mask) {
+ case IIO_CHAN_INFO_SCALE:
+ return IIO_VAL_INT_PLUS_NANO;
+ default:
+ return IIO_VAL_INT;
+ }
+}
+
+static const struct iio_info qmc5883l_info = {
+ .read_raw = qmc5883l_read_raw,
+ .write_raw = qmc5883l_write_raw,
+ .read_avail = qmc5883l_read_avail,
+ .write_raw_get_fmt = qmc5883l_write_raw_get_fmt,
+};
+
+static int qmc5883l_init(struct qmc5883l_data *data)
+{
+ unsigned int reg;
+ int ret;
+
+ ret = regmap_read(data->regmap, QMC5883L_REG_ID, ®);
+ if (ret)
+ return ret;
+
+ /* Not failing because rev 1.0 had this register reserved */
+ if (reg != QMC5883L_CHIP_ID)
+ dev_warn(regmap_get_device(data->regmap),
+ "unknown chip id: 0x%02x, continuing\n", reg);
+
+ ret = regmap_write(data->regmap, QMC5883L_REG_CTRL2,
+ QMC5883L_SOFT_RESET);
+ if (ret)
+ return ret;
+
+ fsleep(QMC5883L_PORT_US);
+
+ /* DRDY pin no used in this version of the driver */
+ ret = regmap_write(data->regmap, QMC5883L_REG_CTRL2,
+ QMC5883L_INT_DISABLE);
+ if (ret)
+ return ret;
+
+ ret = regmap_write(data->regmap, QMC5883L_REG_SET_RESET,
+ QMC5883L_SET_RESET_VAL);
+ if (ret)
+ return ret;
+
+ data->odr = QMC5883L_ODR_50HZ;
+ data->range = QMC5883L_RNG_2G;
+ data->osr = QMC5883L_OSR_64;
+
+ ret = regmap_write(data->regmap, QMC5883L_REG_CTRL1,
+ (QMC5883L_MODE_CONT | data->odr | data->range |
+ data->osr));
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static bool qmc5883l_volatile_reg(struct device *dev, unsigned int reg)
+{
+ return reg <= QMC5883L_REG_STATUS1;
+}
+
+static bool qmc5883l_writable_reg(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case QMC5883L_REG_CTRL1:
+ case QMC5883L_REG_CTRL2:
+ case QMC5883L_REG_SET_RESET:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static const struct regmap_config qmc5883l_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = QMC5883L_REG_ID,
+ .cache_type = REGCACHE_MAPLE,
+ .volatile_reg = qmc5883l_volatile_reg,
+ .writeable_reg = qmc5883l_writable_reg
+};
+
+#define QMC5883L_CHANNEL(_axis) \
+ { \
+ .type = IIO_MAGN, \
+ .modified = 1, \
+ .channel2 = IIO_MOD_##_axis, \
+ .address = QMC5883L_AXIS_##_axis, \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
+ .info_mask_shared_by_type = \
+ BIT(IIO_CHAN_INFO_SCALE) | \
+ BIT(IIO_CHAN_INFO_SAMP_FREQ) | \
+ BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO), \
+ .info_mask_shared_by_type_available = \
+ BIT(IIO_CHAN_INFO_SCALE) | \
+ BIT(IIO_CHAN_INFO_SAMP_FREQ) | \
+ BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO), \
+ }
+
+static const struct iio_chan_spec qmc5883l_channels[] = {
+ QMC5883L_CHANNEL(X),
+ QMC5883L_CHANNEL(Y),
+ QMC5883L_CHANNEL(Z),
+};
+
+static int qmc5883l_probe(struct i2c_client *client)
+{
+ struct iio_dev *indio_dev;
+ struct regmap *regmap;
+ struct qmc5883l_data *data;
+ struct device *dev = &client->dev;
+ int ret;
+
+ indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ regmap = devm_regmap_init_i2c(client, &qmc5883l_regmap_config);
+ if (IS_ERR(regmap)) {
+ return dev_err_probe(dev, PTR_ERR(regmap),
+ "regmap initialization failed\n");
+ }
+
+ ret = devm_regulator_get_enable(dev, "vdd");
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed to enable VDD regulator\n");
+
+ ret = devm_regulator_get_enable(dev, "vddio");
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed to enable VDDIO regulator\n");
+
+ fsleep(QMC5883L_PORT_US);
+
+ data = iio_priv(indio_dev);
+ data->regmap = regmap;
+ ret = devm_mutex_init(dev, &data->mutex);
+ if (ret)
+ return ret;
+
+ indio_dev->name = "qmc5883l";
+ indio_dev->info = &qmc5883l_info;
+ indio_dev->channels = qmc5883l_channels;
+ indio_dev->num_channels = ARRAY_SIZE(qmc5883l_channels);
+ indio_dev->modes = INDIO_DIRECT_MODE;
+
+ ret = qmc5883l_init(data);
+ if (ret)
+ return dev_err_probe(dev, ret, "qmc5883l init failed\n");
+
+ return devm_iio_device_register(dev, indio_dev);
+}
+
+static const struct of_device_id qmc5883l_match[] = {
+ { .compatible = "qstcorp,qmc5883l" },
+ { },
+};
+MODULE_DEVICE_TABLE(of, qmc5883l_match);
+
+static const struct i2c_device_id qmc5883l_id[] = {
+ { "qmc5883l" },
+ { },
+};
+MODULE_DEVICE_TABLE(i2c, qmc5883l_id);
+
+static struct i2c_driver qmc5883l_driver = {
+ .driver = {
+ .name = "qmc5883l",
+ .of_match_table = qmc5883l_match,
+ },
+ .id_table = qmc5883l_id,
+ .probe = qmc5883l_probe,
+};
+
+module_i2c_driver(qmc5883l_driver);
+
+MODULE_DESCRIPTION("QST QMC5883L 3-Axis Magnetic Sensor driver");
+MODULE_AUTHOR("Siratul Islam <email@sirat.me>");
+MODULE_LICENSE("Dual BSD/GPL");
--
2.54.0
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: iio: magnetometer: add QST QMC5883L Sensor
From: Siratul Islam @ 2026-06-12 12:45 UTC (permalink / raw)
To: jic23, robh, krzk+dt, conor+dt
Cc: dlechner, nuno.sa, andy, linux-iio, devicetree, linux-kernel,
Siratul Islam
In-Reply-To: <20260612124557.13750-1-email@sirat.me>
Add devicetree binding for the QST QMC5883L 3-Axis Magnetic Sensor
connected via i2c.
Interrupt not implemented in driver but kept in the binding for future
addition.
Used enum so that more driver could use this binding
Signed-off-by: Siratul Islam <email@sirat.me>
---
.../iio/magnetometer/qstcorp,qmc5883l.yaml | 48 +++++++++++++++++++
MAINTAINERS | 6 +++
2 files changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/magnetometer/qstcorp,qmc5883l.yaml
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/qstcorp,qmc5883l.yaml b/Documentation/devicetree/bindings/iio/magnetometer/qstcorp,qmc5883l.yaml
new file mode 100644
index 000000000000..238cc7e22b89
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/magnetometer/qstcorp,qmc5883l.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/magnetometer/qstcorp,qmc5883l.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: QST QMC5883L 3-Axis Magnetic Sensor
+
+maintainers:
+ - Siratul Islam <email@sirat.me>
+
+properties:
+ compatible:
+ enum:
+ - qstcorp,qmc5883l
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vdd-supply: true
+
+ vddio-supply: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+ - vddio-supply
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ magnetometer@d {
+ compatible = "qstcorp,qmc5883l";
+ reg = <0x0d>;
+ vdd-supply = <&vdd_3v3_reg>;
+ vddio-supply = <&vdd_3v3_reg>;
+ };
+ };
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index e035a3be797c..310074b34072 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21787,6 +21787,12 @@ F: Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst
F: drivers/bus/fsl-mc/
F: include/uapi/linux/fsl_mc.h
+QST QMC5883L 3-Axis Magnetic Sensor
+M: Siratul Islam <email@sirat.me>
+L: linux-iio@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/iio/magnetometer/qstcorp,qmc5883l.yaml
+
QT1010 MEDIA DRIVER
L: linux-media@vger.kernel.org
S: Orphan
--
2.54.0
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: add entry for qstcorp
From: Siratul Islam @ 2026-06-12 12:45 UTC (permalink / raw)
To: jic23, robh, krzk+dt, conor+dt
Cc: dlechner, nuno.sa, andy, linux-iio, devicetree, linux-kernel,
Siratul Islam
In-Reply-To: <20260612124557.13750-1-email@sirat.me>
Add an entry for QST Corporation Limited
Signed-off-by: Siratul Islam <email@sirat.me>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 28784d66ae7b..11aac47f90ce 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1355,6 +1355,8 @@ patternProperties:
description: Shenzhen QiShenglong Industrialist Co., Ltd.
"^qnap,.*":
description: QNAP Systems, Inc.
+ "^qstcorp,.*":
+ description: QST Corporation Limited
"^quanta,.*":
description: Quanta Computer Inc.
"^radxa,.*":
--
2.54.0
^ permalink raw reply related
* [PATCH 0/3] iio: magnetometer: add driver for QST QMC5883L Sensor
From: Siratul Islam @ 2026-06-12 12:45 UTC (permalink / raw)
To: jic23, robh, krzk+dt, conor+dt
Cc: dlechner, nuno.sa, andy, linux-iio, devicetree, linux-kernel,
Siratul Islam
This patch series introduces the QST QMC5883L 3-Axis Magnetic Sensor
driver. It is a simple device with minimal magnetometer functionalities.
Commonly used as (software incompatible) replacement for the
Honeywell HMC5883L sensor.
This driver implements the basic functionalities of the QMC5883L sensor,
and intentionally leaves out some features like DRDY interrupt pin support
and power management for simplicity, both of which will be addressed
in future patches.
There was an attempt to introduce this device about an year ago but
the author seems to have abandoned the patch series. Since the device
is simple enough, I decided to start from scratch.
Note: I also noticed a patch for the QMC5883P variant. Despite similar
naming, the sensors are different including different register maps,
so these devices are not compatible with each other.
Siratul Islam (3):
dt-bindings: add entry for qstcorp
dt-bindings: iio: magnetometer: add QST QMC5883L Sensor
iio: magnetometer: add driver for QST QMC5883L Sensor
.../iio/magnetometer/qstcorp,qmc5883l.yaml | 48 ++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
MAINTAINERS | 7 +
drivers/iio/magnetometer/Kconfig | 11 +
drivers/iio/magnetometer/Makefile | 2 +
drivers/iio/magnetometer/qmc5883l.c | 512 ++++++++++++++++++
6 files changed, 582 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/magnetometer/qstcorp,qmc5883l.yaml
create mode 100644 drivers/iio/magnetometer/qmc5883l.c
--
2.54.0
^ permalink raw reply
* Re: [PATCH net v3 2/2] dt-bindings: net: updated interrupt type to be active low, level triggered
From: Parthiban.Veerasooran @ 2026-06-12 12:43 UTC (permalink / raw)
To: Selvamani.Rajagopal, andrew, conor
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, robh, krzk+dt,
conor+dt, Pier.Beruto, netdev, linux-kernel, Conor.Dooley,
devicetree
In-Reply-To: <CYYPR02MB98285C570F545729D3ECFB35831B2@CYYPR02MB9828.namprd02.prod.outlook.com>
Hi Selvamani,
On 12/06/26 3:29 am, Selvamani Rajagopal wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
>> Subject: RE: [PATCH net v3 2/2] dt-bindings: net: updated interrupt type to be active low, level triggered
>>
>>>
>>> On 10/06/26 1:32 am, Selvamani Rajagopal wrote:
>>>
>>> Thank you for the update. I will test your v4 submission and share the
>>> feedback as soon as possible.
>>
>> Parthiban,
>>
>> I think it is better to wait for v5 to test. v4 failed in AI code review. It raised some
>> important race conditions related
>> questions. I have some more changes to address those. Will submit v5 soon. You will
>> have it by Monday, if not today.
>>
>
>
> I just submitted v5. Please verify when you have time, unless you want to
> wait for AI code review to be done, which is fine too.
>
> https://patchwork.kernel.org/project/netdevbpf/list/?series=1110309
Thank you for the update. I will try to test it at the earliest.
Best regards,
Parthiban V
>
>
>>>
>>> Best regards,
>>> Parthiban V
>>>>
>
^ permalink raw reply
* Re: [PATCH v4 3/3] arm64: dts: qcom: glymur: Add camera clock controller support
From: Vladimir Zapolskiy @ 2026-06-12 12:42 UTC (permalink / raw)
To: Jagadeesh Kona, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bryan O'Donoghue, Konrad Dybcio
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel,
Dmitry Baryshkov
In-Reply-To: <20260517-glymur_camcc-v4-3-9d00acffdbf7@oss.qualcomm.com>
On 5/17/26 20:33, Jagadeesh Kona wrote:
> Add support for camera clock controller for camera clients to
> be able to request for camera clocks on Glymur SoC's.
>
> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v6 2/5] iio: adc: add Versal SysMon driver
From: Erim, Salih @ 2026-06-12 12:40 UTC (permalink / raw)
To: Jonathan Cameron
Cc: andy, dlechner, nuno.sa, robh, krzk+dt, conor+dt, conall.ogriofa,
michal.simek, linux, erimsalih, linux-iio, devicetree,
linux-kernel
In-Reply-To: <20260612131009.1be11ff2@jic23-huawei>
Hi Jonathan,
On 12/06/2026 13:10, Jonathan Cameron wrote:
> On Thu, 11 Jun 2026 23:27:35 +0100
> Salih Erim <salih.erim@amd.com> wrote:
>
>> Add the core driver and MMIO platform driver for the AMD/Xilinx Versal
>> System Monitor (SysMon) block.
>>
>> The SysMon block resides in the platform management controller (PMC) and
>> provides on-chip voltage and temperature monitoring through a 10-bit,
>> 200 kSPS ADC. It can monitor up to 160 voltage channels and 64
>> temperature satellites distributed across the SoC, with a consistent
>> sample rate of 8 kSPS per channel regardless of how many channels are
>> enabled.
>>
>> The driver is split into two compilation units:
>> - versal-sysmon-core: Channel parsing, IIO registration, read_raw
>> - versal-sysmon: MMIO platform driver with custom regmap accessors
>>
>> Voltage results are stored in a 19-bit modified floating-point format
>> and converted to millivolts. Temperature results are stored in Q8.7
>> signed fixed-point Celsius format and converted to millicelsius.
>>
>> The MMIO regmap backend uses a custom reg_write accessor that
>> automatically unlocks the NPI (NoC programming interface) lock
>> register before each write, as required by the hardware. The regmap
>> is configured with fast_io since the underlying MMIO accessors are
>> safe to call from atomic context.
>>
>> Co-developed-by: Michal Simek <michal.simek@amd.com>
>> Signed-off-by: Michal Simek <michal.simek@amd.com>
>> Signed-off-by: Salih Erim <salih.erim@amd.com>
>
> One question on the static temp channels. I may have forgotten
> some earlier discussion!
>
>> diff --git a/drivers/iio/adc/versal-sysmon-core.c b/drivers/iio/adc/versal-sysmon-core.c
>> new file mode 100644
>> index 00000000000..c875d156dbe
>> --- /dev/null
>> +++ b/drivers/iio/adc/versal-sysmon-core.c
>> @@ -0,0 +1,281 @@
>
>> +
>> +#define SYSMON_CHAN_TEMP(_chan, _address, _name) \
>> +{ \
>> + .type = IIO_TEMP, \
>> + .indexed = 1, \
>> + .address = _address, \
>> + .channel = _chan, \
>> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
>> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
>> + .datasheet_name = _name, \
>> +}
>> +
>> +/* Static temperature channels (always present) */
>> +static const struct iio_chan_spec temp_channels[] = {
>> + SYSMON_CHAN_TEMP(0, SYSMON_TEMP_MAX, "temp"),
>> + SYSMON_CHAN_TEMP(1, SYSMON_TEMP_MIN, "min"),
>> + SYSMON_CHAN_TEMP(2, SYSMON_TEMP_MAX_MAX, "max_max"),
>> + SYSMON_CHAN_TEMP(3, SYSMON_TEMP_MIN_MIN, "min_min"),
>
> Sorry, I missed this in previous reviews, but what are these channels?
> The labels are rather unusual.
>
> My guess is they are gathering up values from across a bunch of sensors
> but I'm not certain. They are unusual enough we probably need some documentation.
>
Your guess is correct. These are hardware-computed aggregate
registers across all active temperature satellites:
- temp (0x1030): current max across all active satellites
- min (0x1034): current min across all active satellites
- max_max (0x1F90): highest peak since last hardware reset
- min_min (0x1F8C): lowest trough since last hardware reset
The cover letter mentions this but the commit message and code
don't. Will add a comment block above the channel definitions
and expand the commit description in v7.
Thanks,
Salih
^ permalink raw reply
* Re: [PATCH v4 2/3] clk: qcom: camcc-glymur: Add camera clock controller driver
From: Vladimir Zapolskiy @ 2026-06-12 12:40 UTC (permalink / raw)
To: Jagadeesh Kona, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bryan O'Donoghue, Konrad Dybcio
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, Taniya Das,
Konrad Dybcio
In-Reply-To: <20260517-glymur_camcc-v4-2-9d00acffdbf7@oss.qualcomm.com>
On 5/17/26 20:33, Jagadeesh Kona wrote:
> Add support for the camera clock controller for camera clients
> to be able to request for camcc clocks on Glymur platform.
>
> Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v4 1/3] dt-bindings: clock: qcom: Add Glymur camera clock controller
From: Vladimir Zapolskiy @ 2026-06-12 12:35 UTC (permalink / raw)
To: Jagadeesh Kona, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bryan O'Donoghue, Konrad Dybcio
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260517-glymur_camcc-v4-1-9d00acffdbf7@oss.qualcomm.com>
On 5/17/26 20:33, Jagadeesh Kona wrote:
> Add device tree bindings for the camera clock controller on
> Qualcomm Glymur SoC.
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* 回复: [net-next v1 1/6] dt-bindings: net: dwmac: Add snps,use-ncsi property
From: Minda Chen @ 2026-06-12 10:54 UTC (permalink / raw)
To: Andrew Lunn
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Jose Abreu, Maxime Coquelin, Russell King,
Giuseppe Cavallaro, Alexandre Torgue, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
devicetree@vger.kernel.org
In-Reply-To: <a542aee0-cc4a-4bed-85fa-1ec6fdfe87d9@lunn.ch>
>
> On Wed, Jun 10, 2026 at 03:24:15PM +0800, Minda Chen wrote:
> > Add snps,use-ncsi dts bindings property for Synopsys designware
>
> Is there anything SNPS specific in how NCSI is implemented? Should this be a
> generic option which any Ethernet interface can use?
>
> Andrew
I will remove this. NCSI actually not generic function. Now just faraday ftgmac100 support this.
^ permalink raw reply
* Re: [PATCH v9 5/9] drm/imx: Add support for i.MX94 DCIF
From: sashiko-bot @ 2026-06-12 12:18 UTC (permalink / raw)
To: Laurentiu Palcu; +Cc: robh, conor+dt, imx, devicetree, dri-devel, Frank.Li
In-Reply-To: <20260612-dcif-upstreaming-v9-5-8d0ff89aa3c5@oss.nxp.com>
Thank you for your contribution! Sashiko AI review found 15 potential issue(s) to consider:
- [High] Read-modify-write (RMW) operations on Write-1-to-Clear (W1C) interrupt status registers cause lost interrupts.
- [High] Module reference count underflow and use-after-free caused by unbalanced `drm_bridge_put`.
- [High] CRTC `bus_format` and `bus_flags` state is corrupted and permanently lost during plane-only atomic updates.
- [High] Unprotected hardware register accesses in the IRQ handler risk bus errors on runtime suspended devices.
- [High] System resume fails to enable the display because `pm_runtime_resume_and_get` is called while PM transitions are disabled.
- [High] An unhandled pending vblank event in `dcif->event` during CRTC disable causes userspace to hang indefinitely and memory to leak.
- [High] Unlocked access to `crtc->state` in `dcif_crc_source_parse` causes a data race and potential use-after-free.
- [High] Failure of `pm_runtime_resume_and_get` causes the atomic commit to hang permanently.
- [High] Use of sleeping functions and inappropriate lock guards in atomic context paths.
- [High] Ignoring the return value of `drm_crtc_vblank_get()` causes vblank reference count underflow on failure.
- [High] Disabling Layer 0 without triggering `SHADOW_LOAD_EN` causes an abrupt hardware stop and AXI bus lockup risks.
- [High] `drm_crtc_vblank_on()` is called before software reset, permanently breaking vblank interrupts.
- [Medium] Dynamic plane color encoding and color range updates are silently ignored.
- [Medium] Transitions between active CRC sources (e.g., updating ROI coordinates) are ignored.
- [Medium] Data race (TOCTOU) on `dcif->crc_is_enabled` causes garbage CRC reads.
--
commit 4328341d625e1f0fbf8be8ca733a73ea0e76115e
Author: Sandor Yu <sandor.yu@nxp.com>
drm/imx: Add support for i.MX94 DCIF
This commit introduces DRM support for the i.MX94 Display Control
Interface (DCIF). It includes core CRTC, plane, and KMS integration,
along with CRC generation support.
> diff --git a/drivers/gpu/drm/imx/dcif/dcif-crc.h b/drivers/gpu/drm/imx/dcif/dcif-crc.h
> --- /dev/null
> +++ b/drivers/gpu/drm/imx/dcif/dcif-crc.h
[ ... ]
> +static inline bool enable_dcif_crc_needed(struct dcif_crtc_state *new_dcstate,
> + struct dcif_crtc_state *old_dcstate)
> +{
> + return old_dcstate->crc.source == DCIF_CRC_SRC_NONE &&
> + new_dcstate->crc.source != DCIF_CRC_SRC_NONE;
> +}
[Severity: Medium]
Does this prevent updates when transitioning directly between two active
CRC configurations? If userspace modifies the ROI region while keeping the
source active, both helpers will return false, meaning the hardware might
continue capturing the old ROI coordinates.
> diff --git a/drivers/gpu/drm/imx/dcif/dcif-crc.c b/drivers/gpu/drm/imx/dcif/dcif-crc.c
> --- /dev/null
> +++ b/drivers/gpu/drm/imx/dcif/dcif-crc.c
[ ... ]
> +void dcif_crc_source_disable(struct dcif_dev *dcif, int ncrc)
> +{
[ ... ]
> + regmap_clear_bits(dcif->regmap, DCIF_CRC_CTRL, DCIF_CRC_CTRL_CRC_EN(ncrc));
> +
> + dcif->crc_is_enabled = false;
> +}
[Severity: Medium]
Is there a data race on the crc_is_enabled flag here? This flag is modified
without holding the event_lock, while the IRQ handler evaluates it with the
lock held. This could allow the module to power off while the IRQ handler
attempts to read the disabled register, generating spurious payload data.
[ ... ]
> +static int dcif_crc_source_parse(struct drm_crtc *crtc, const char *source_name,
> + enum dcif_crc_source *s, struct drm_rect *roi)
> +{
> + static const char roi_prefix[] = "roi:";
> +
> + if (!source_name) {
> + *s = DCIF_CRC_SRC_NONE;
> + } else if (!strcmp(source_name, "auto")) {
> + struct drm_display_mode *mode = &crtc->state->adjusted_mode;
[Severity: High]
Can this unlocked access to the atomic state lead to a use-after-free? This
parser is called before acquiring any connection locks. A concurrent atomic
commit could swap and free the atomic state while this thread is referencing
the adjusted_mode.
> diff --git a/drivers/gpu/drm/imx/dcif/dcif-crtc.c b/drivers/gpu/drm/imx/dcif/dcif-crtc.c
> --- /dev/null
> +++ b/drivers/gpu/drm/imx/dcif/dcif-crtc.c
[ ... ]
> +static void dcif_disable_controller(struct dcif_dev *dcif)
> +{
> + u32 reg;
> + int ret;
> +
> + /* Disable layer 0 */
> + regmap_clear_bits(dcif->regmap, DCIF_CTRLDESC0(0), DCIF_CTRLDESC0_EN);
[Severity: High]
Does clearing the enable bit without also triggering the shadow load bit
leave the layer hardware active? The hardware typically ignores the register
change without the shadow load bit, meaning it will continue fetching data
via DMA. Severing the display controller abruptly while DMA is active could
risk AXI bus lockups.
[ ... ]
> +static void dcif_crtc_queue_state_event(struct drm_crtc *crtc)
> +{
> + struct dcif_dev *dcif = crtc_to_dcif_dev(crtc);
> +
> + scoped_guard(spinlock_irq, &crtc->dev->event_lock) {
> + if (crtc->state->event) {
> + WARN_ON(drm_crtc_vblank_get(crtc));
> + WARN_ON(dcif->event);
> + dcif->event = crtc->state->event;
[Severity: High]
What happens if drm_crtc_vblank_get returns an error? The code continues to
queue the event without having incremented the vblank reference count. When
the interrupt handler later processes the event and calls the corresponding
put function, it would cause a reference count underflow.
[ ... ]
> +static void dcif_crtc_query_output_bus_format(struct drm_crtc *crtc,
> + struct drm_crtc_state *crtc_state)
> +{
> + struct dcif_crtc_state *dcif_state = to_dcif_crtc_state(crtc_state);
> + struct drm_bridge *bridge __free(drm_bridge_put) = NULL;
[Severity: High]
Will the cleanup attribute here cause a use-after-free? The bridge is
obtained via drm_bridge_chain_get_first_bridge, which does not increment
the module reference count. When the function returns, drm_bridge_put will
decrement a reference that was never acquired, potentially allowing the
bridge module to unload prematurely.
> + struct drm_bridge_state *bridge_state;
> +
> + dcif_state->bus_format = MEDIA_BUS_FMT_RGB888_1X24;
> + dcif_state->bus_flags = 0;
> +
> + bridge = dcif_crtc_get_bridge(crtc, crtc_state);
> + if (!bridge)
> + return;
[Severity: High]
Could this overwrite destroy the existing bus_format and bus_flags during
a plane-only update? In a plane update, the bridge is not part of the atomic
commit state, causing the bridge state query below to return NULL. Returning
early leaves the state permanently overwritten with default values.
[ ... ]
> +static void dcif_crtc_atomic_enable(struct drm_crtc *crtc,
> + struct drm_atomic_commit *state)
> +{
[ ... ]
> + /* enable power when we start to set mode for CRTC */
> + ret = pm_runtime_resume_and_get(drm->dev);
> + if (ret < 0) {
> + drm_err(drm, "failed to resume DCIF, ret = %d\n", ret);
> + return;
> + }
[Severity: High]
Is pm_runtime_resume_and_get safe to call here? This is an atomic context
path during non-blocking commits, and this PM function can sleep.
Additionally, if this path executes during system resume, runtime PM
transitions are disabled and it will return an error, leaving the display
blanked.
If it does return early, the pending event in crtc->state->event is never
consumed. The DRM core expects the driver to consume the event, and
abandoning it here will cause the atomic commit to hang indefinitely
waiting for a flip completion.
> + dcif->crtc_pm_enabled = true;
> +
> + drm_crtc_vblank_on(crtc);
> +
> + dcif_crtc_mode_set_nofb(crtc_state, plane_state);
[Severity: High]
Will the software reset performed inside dcif_crtc_mode_set_nofb destroy the
vblank interrupt enablement? Since drm_crtc_vblank_on is called right before
the reset, the hardware state and interrupt enable bits will be cleared,
permanently breaking vblanks.
[ ... ]
> +static void dcif_crtc_atomic_disable(struct drm_crtc *crtc,
> + struct drm_atomic_commit *state)
> +{
[ ... ]
> + if (dcif->crtc_pm_enabled) {
> + dcif->crtc_pm_enabled = false;
> + pm_runtime_put_sync(drm->dev);
> + }
> +
> + scoped_guard(spinlock_irq, &crtc->dev->event_lock) {
> + if (crtc->state->event && !crtc->state->active) {
> + drm_crtc_send_vblank_event(crtc, crtc->state->event);
> + crtc->state->event = NULL;
> + }
> + }
> +}
[Severity: High]
Similar to the enable path, pm_runtime_put_sync is a sleeping function
called in an atomic context.
Also, does the use of the spinlock_irq scoped guard here cause problems?
When exiting the scoped guard, it unconditionally re-enables hardware
interrupts, which breaks the caller's atomic execution context.
Finally, if a non-blocking commit queued an event into dcif->event, it
seems to be ignored here. If the hardware interrupts are turned off, the
pending event in dcif->event is stranded and never signaled, leaving
userspace blocked.
[ ... ]
> +static int dcif_crtc_enable_vblank(struct drm_crtc *crtc)
> +{
> + struct dcif_dev *dcif = crtc_to_dcif_dev(crtc);
> + int domain = dcif->cpu_domain;
> +
> + /* Clear and enable VS_BLANK IRQ */
> + regmap_set_bits(dcif->regmap, DCIF_IS0(domain), DCIF_INT0_VS_BLANK);
> + regmap_set_bits(dcif->regmap, DCIF_IE0(domain), DCIF_INT0_VS_BLANK);
[Severity: High]
Does using a read-modify-write helper on a Write-1-to-Clear register cause
lost interrupts? regmap_set_bits will read the register, OR the new bit, and
write it back, which inadvertently clears any already pending interrupts
before the handler can process them. W1C registers usually need to be
written directly.
[ ... ]
> +static void dcif_crtc_disable_vblank(struct drm_crtc *crtc)
> +{
> + struct dcif_dev *dcif = crtc_to_dcif_dev(crtc);
> + int domain = dcif->cpu_domain;
> +
> + /* Disable and clear VS_BLANK IRQ */
> + regmap_clear_bits(dcif->regmap, DCIF_IE0(domain), DCIF_INT0_VS_BLANK);
> + regmap_clear_bits(dcif->regmap, DCIF_IS0(domain), DCIF_INT0_VS_BLANK);
> +}
[Severity: High]
The same applies here. regmap_clear_bits will write a 1 to all pending
interrupts while writing a 0 to the target bit, improperly clearing unrelated
interrupts and failing to clear the target bit.
[ ... ]
> +irqreturn_t dcif_irq_handler(int irq, void *data)
> +{
> + struct drm_device *drm = data;
> + struct dcif_dev *dcif = to_dcif_dev(drm);
> + int domain = dcif->cpu_domain;
> + u32 stat0, stat1, crc;
> +
> + regmap_read(dcif->regmap, DCIF_IS0(domain), &stat0);
[Severity: High]
Is it safe to read hardware registers here without verifying the power
management active state? If the device is in runtime suspend and its clocks
are turned off, a spurious interrupt could trigger this handler, and
accessing unclocked registers can cause bus faults or system lockups. Should
this be protected with pm_runtime_get_if_active?
> diff --git a/drivers/gpu/drm/imx/dcif/dcif-plane.c b/drivers/gpu/drm/imx/dcif/dcif-plane.c
> --- /dev/null
> +++ b/drivers/gpu/drm/imx/dcif/dcif-plane.c
[ ... ]
> +static int dcif_plane_atomic_check(struct drm_plane *plane, struct drm_atomic_commit *state)
> +{
[ ... ]
> + /*
> + * Force CRTC mode change if framebuffer stride or pixel format have changed.
> + */
> + if (plane->type == DRM_PLANE_TYPE_PRIMARY && old_fb &&
> + (fb->pitches[0] != old_fb->pitches[0] || fb->format->format != old_fb->format->format))
> + crtc_state->mode_changed = true;
[Severity: Medium]
Will dynamic updates to plane color encoding or color ranges be silently
ignored? The hardware CSC coefficients are programmed during a full modeset,
but this check does not flag a mode change if only the color properties are
modified.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612-dcif-upstreaming-v9-0-8d0ff89aa3c5@oss.nxp.com?part=5
^ permalink raw reply
* Re: [PATCH v9 6/9] dt-bindings: clock: nxp,imx95-blk-ctl: Add ldb child node
From: sashiko-bot @ 2026-06-12 12:10 UTC (permalink / raw)
To: Laurentiu Palcu; +Cc: dri-devel, imx, Frank.Li, robh, conor+dt, devicetree
In-Reply-To: <20260612-dcif-upstreaming-v9-6-8d0ff89aa3c5@oss.nxp.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `allOf` conditional block restricts the `ldb` child node exclusively to `nxp,imx94-lvds-csr`, improperly forbidding it for `nxp,imx95-lvds-csr`.
--
commit 6a3665e114245286584773223a39379615a4d4fc
Author: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
dt-bindings: clock: nxp,imx95-blk-ctl: Add ldb child node
This commit adds support for the 'ldb' child node to the i.MX95 BLK CTL
bindings. It updates the schema to handle cases where BLK CTL registers
control the LVDS Display Bridge controllers.
> diff --git a/Documentation/devicetree/bindings/clock/nxp,imx95-blk-ctl.yaml b/Documentation/devicetree/bindings/clock/nxp,imx95-blk-ctl.yaml
> --- a/Documentation/devicetree/bindings/clock/nxp,imx95-blk-ctl.yaml
> +++ b/Documentation/devicetree/bindings/clock/nxp,imx95-blk-ctl.yaml
[ ... ]
> @@ -46,6 +57,21 @@ required:
> - power-domains
> - clocks
>
> +allOf:
> + - if:
> + not:
> + properties:
> + compatible:
> + contains:
> + const: nxp,imx94-lvds-csr
[Severity: Medium]
Does this restriction improperly forbid the ldb child node on i.MX95 devices?
The clock driver exposes LDB-related clocks for the i.MX95 variant, so it
seems nxp,imx95-lvds-csr is also an LVDS CSR that controls the LVDS Display
Bridge. By omitting nxp,imx95-lvds-csr from this check, will valid i.MX95
device trees defining the ldb child node fail schema validation?
Should this condition check an enum containing both nxp,imx94-lvds-csr and
nxp,imx95-lvds-csr instead?
> + then:
> + patternProperties:
> + "^ldb@[0-9a-f]+$": false
> + else:
> + required:
> + - '#address-cells'
> + - '#size-cells'
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612-dcif-upstreaming-v9-0-8d0ff89aa3c5@oss.nxp.com?part=6
^ permalink raw reply
* Re: [PATCH v6 2/5] iio: adc: add Versal SysMon driver
From: Jonathan Cameron @ 2026-06-12 12:10 UTC (permalink / raw)
To: Salih Erim
Cc: andy, dlechner, nuno.sa, robh, krzk+dt, conor+dt, conall.ogriofa,
michal.simek, linux, erimsalih, linux-iio, devicetree,
linux-kernel
In-Reply-To: <20260611222738.2035062-3-salih.erim@amd.com>
On Thu, 11 Jun 2026 23:27:35 +0100
Salih Erim <salih.erim@amd.com> wrote:
> Add the core driver and MMIO platform driver for the AMD/Xilinx Versal
> System Monitor (SysMon) block.
>
> The SysMon block resides in the platform management controller (PMC) and
> provides on-chip voltage and temperature monitoring through a 10-bit,
> 200 kSPS ADC. It can monitor up to 160 voltage channels and 64
> temperature satellites distributed across the SoC, with a consistent
> sample rate of 8 kSPS per channel regardless of how many channels are
> enabled.
>
> The driver is split into two compilation units:
> - versal-sysmon-core: Channel parsing, IIO registration, read_raw
> - versal-sysmon: MMIO platform driver with custom regmap accessors
>
> Voltage results are stored in a 19-bit modified floating-point format
> and converted to millivolts. Temperature results are stored in Q8.7
> signed fixed-point Celsius format and converted to millicelsius.
>
> The MMIO regmap backend uses a custom reg_write accessor that
> automatically unlocks the NPI (NoC programming interface) lock
> register before each write, as required by the hardware. The regmap
> is configured with fast_io since the underlying MMIO accessors are
> safe to call from atomic context.
>
> Co-developed-by: Michal Simek <michal.simek@amd.com>
> Signed-off-by: Michal Simek <michal.simek@amd.com>
> Signed-off-by: Salih Erim <salih.erim@amd.com>
One question on the static temp channels. I may have forgotten
some earlier discussion!
> diff --git a/drivers/iio/adc/versal-sysmon-core.c b/drivers/iio/adc/versal-sysmon-core.c
> new file mode 100644
> index 00000000000..c875d156dbe
> --- /dev/null
> +++ b/drivers/iio/adc/versal-sysmon-core.c
> @@ -0,0 +1,281 @@
> +
> +#define SYSMON_CHAN_TEMP(_chan, _address, _name) \
> +{ \
> + .type = IIO_TEMP, \
> + .indexed = 1, \
> + .address = _address, \
> + .channel = _chan, \
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
> + .datasheet_name = _name, \
> +}
> +
> +/* Static temperature channels (always present) */
> +static const struct iio_chan_spec temp_channels[] = {
> + SYSMON_CHAN_TEMP(0, SYSMON_TEMP_MAX, "temp"),
> + SYSMON_CHAN_TEMP(1, SYSMON_TEMP_MIN, "min"),
> + SYSMON_CHAN_TEMP(2, SYSMON_TEMP_MAX_MAX, "max_max"),
> + SYSMON_CHAN_TEMP(3, SYSMON_TEMP_MIN_MIN, "min_min"),
Sorry, I missed this in previous reviews, but what are these channels?
The labels are rather unusual.
My guess is they are gathering up values from across a bunch of sensors
but I'm not certain. They are unusual enough we probably need some documentation.
^ permalink raw reply
* Re: [PATCH v11 7/9] i3c: hub: Add support for the I3C interface in the I3C hub
From: Julian Braha @ 2026-06-12 12:09 UTC (permalink / raw)
To: Lakshay Piplani, linux-kernel, linux-i3c, alexandre.belloni,
krzk+dt, robh, conor+dt, devicetree, broonie, lee, Frank.Li,
lgirdwood
Cc: vikash.bansal, priyanka.jain, aman.kumarpandey
In-Reply-To: <20260612111816.3688240-8-lakshay.piplani@nxp.com>
On 6/12/26 12:18, Lakshay Piplani wrote:
> if I3C
> source "drivers/i3c/master/Kconfig"
> +
> +config I3C_HUB
> + tristate "I3C Hub Support"
> + depends on I3C
> + help
> + Enable support for the I3C interface in hub devices.
> +
> + This option adds virtual I3C bus support for hubs by creating
> + virtual master controllers for downstream ports and forwarding
> + bus operations through the hub device. It also provides an
> + interface used by hub drivers to enable or disable downstream
> + ports during bus transactions.
> +
> + Say Y here if your platform includes an I3C hub device
> +
> endif # I3C
Hi Lakshay,
The 'depends on I3C' here is unnecessary because that's what the
'if I3C..endif' is already doing.
- Julian Braha
^ permalink raw reply
* Re: [PATCH v9 3/9] drm/bridge: fsl-ldb: Add support for i.MX94
From: sashiko-bot @ 2026-06-12 12:09 UTC (permalink / raw)
To: Laurentiu Palcu; +Cc: Frank.Li, imx, robh, conor+dt, dri-devel, devicetree
In-Reply-To: <20260612-dcif-upstreaming-v9-3-8d0ff89aa3c5@oss.nxp.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Pre-existing use of usleep_range() in an atomic commit callback (fsl_ldb_atomic_enable).
--
commit e14b3dd6d0171a77b5885d6c520dacd31270636e
Author: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
drm/bridge: fsl-ldb: Add support for i.MX94
i.MX94 series LDB controller shares the same LDB and LVDS control
registers as i.MX8MP and i.MX93 but supports a higher maximum clock
frequency.
Add a 'max_clk_khz' member to the fsl_ldb_devdata structure in order to
be able to set different max frequencies for other platforms.
> diff --git a/drivers/gpu/drm/bridge/fsl-ldb.c b/drivers/gpu/drm/bridge/fsl-ldb.c
> index bd03c36ee696c..b4959f654f2ac 100644
> --- a/drivers/gpu/drm/bridge/fsl-ldb.c
> +++ b/drivers/gpu/drm/bridge/fsl-ldb.c
[ ... ]
[Severity: High]
This isn't a bug introduced by this patch, but I noticed a pre-existing
issue in fsl_ldb_atomic_enable() which executes as part of the atomic commit
modeset phase:
drivers/gpu/drm/bridge/fsl-ldb.c:fsl_ldb_atomic_enable() {
...
if (fsl_ldb->use_termination_resistor)
reg |= LVDS_CTRL_HS_EN;
regmap_write(fsl_ldb->regmap, fsl_ldb->devdata->lvds_ctrl, reg);
/* Wait for VBG to stabilize. */
usleep_range(15, 20);
reg |= (fsl_ldb->ch0_enabled ? LVDS_CTRL_CH0_EN : 0) |
(fsl_ldb->ch1_enabled ? LVDS_CTRL_CH1_EN : 0);
...
}
Are sleeping functions permitted in this context?
Because fsl_ldb_atomic_enable() acts as an encoder atomic enable callback,
it runs in an atomic context where sleeping delays like usleep_range()
are forbidden.
Could this lead to kernel warnings, system instability, or deadlocks?
Should this be replaced with a non-sleeping delay like udelay()?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612-dcif-upstreaming-v9-0-8d0ff89aa3c5@oss.nxp.com?part=3
^ permalink raw reply
* Re: [PATCH v8 8/9] arm64: dts: imx943-evk: Add display support using IT6263
From: Laurentiu Palcu @ 2026-06-12 12:06 UTC (permalink / raw)
To: Liu Ying
Cc: imx, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, dri-devel,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <1a3d466c-c1b5-49f1-a9ab-1c827e906e91@nxp.com>
Hi Ying,
On Fri, Mar 06, 2026 at 04:45:25PM +0800, Liu Ying wrote:
> On Wed, Mar 04, 2026 at 11:34:17AM +0000, Laurentiu Palcu wrote:
> > The ITE IT6263 based NXP LVDS to HDMI converter can be attached to the
> > i.MX943 EVK board LVDS port using the mini-SAS connector. Since this is
>
> Since the LVDS to HDMI converter can be attached or detached to the EVK
> board, it would be appropriate to use a DT overlay instead?
AFAIK, imx943 EVK ships with the IT6263 LVDS to HDMI adapter. So, I
believe it's preferable to have support for the adapter in the default
DTB instead of a DT overlay.
--
Thanks,
Laurentiu
^ permalink raw reply
* Re: [PATCH v8 7/9] arm64: dts: imx943: Add display pipeline nodes
From: Laurentiu Palcu @ 2026-06-12 12:02 UTC (permalink / raw)
To: Liu Ying
Cc: imx, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, dri-devel,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <43be372e-8177-457c-9d4e-a2ed69e79c8a@nxp.com>
Hi Ying,
On Fri, Mar 06, 2026 at 04:27:48PM +0800, Liu Ying wrote:
> On Wed, Mar 04, 2026 at 11:34:16AM +0000, Laurentiu Palcu wrote:
> > Add display controller and LDB support in imx943.
> >
> > Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> > ---
> > arch/arm64/boot/dts/freescale/imx943.dtsi | 53 ++++++++++++++++++++++++++++++-
> > 1 file changed, 52 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx943.dtsi b/arch/arm64/boot/dts/freescale/imx943.dtsi
> > index 657c81b6016f2..9a91beef54e86 100644
> > --- a/arch/arm64/boot/dts/freescale/imx943.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx943.dtsi
> > @@ -148,7 +148,7 @@ l3_cache: l3-cache {
> > };
> > };
> >
> > - clock-ldb-pll-div7 {
> > + clock_ldb_pll_div7: clock-ldb-pll-div7 {
> > compatible = "fixed-factor-clock";
> > #clock-cells = <0>;
> > clocks = <&scmi_clk IMX94_CLK_LDBPLL>;
> > @@ -174,9 +174,60 @@ dispmix_csr: syscon@4b010000 {
> > lvds_csr: syscon@4b0c0000 {
> > compatible = "nxp,imx94-lvds-csr", "syscon";
> > reg = <0x0 0x4b0c0000 0x0 0x10000>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > clocks = <&scmi_clk IMX94_CLK_DISPAPB>;
> > #clock-cells = <1>;
> > power-domains = <&scmi_devpd IMX94_PD_DISPLAY>;
> > +
> > + ldb: ldb@4 {
> > + compatible = "fsl,imx94-ldb";
>
> Should this be moved to imx94.dtsi, since the compatible string doesn't
> seem to be i.MX943 specific?
Agreed, I moved them to imx94.dtsi in v9.
--
Thanks,
Laurentiu
^ permalink raw reply
* [PATCH v9 8/9] arm64: dts: imx943-evk: Add display support using IT6263
From: Laurentiu Palcu @ 2026-06-12 11:58 UTC (permalink / raw)
To: Ying Liu, Luca Ceresoli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
Cc: Laurentiu Palcu, linux-clk, imx, devicetree, linux-arm-kernel,
linux-kernel, dri-devel
In-Reply-To: <20260612-dcif-upstreaming-v9-0-8d0ff89aa3c5@oss.nxp.com>
The ITE IT6263 based NXP LVDS to HDMI converter can be attached to the
i.MX943 EVK board LVDS port using the mini-SAS connector. Since this is
the default configuration for the EVK, add support for it here.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
---
arch/arm64/boot/dts/freescale/imx943-evk.dts | 86 ++++++++++++++++++++++++++++
1 file changed, 86 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx943-evk.dts b/arch/arm64/boot/dts/freescale/imx943-evk.dts
index 7cfd424689507..41a2a700a86a5 100644
--- a/arch/arm64/boot/dts/freescale/imx943-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx943-evk.dts
@@ -77,6 +77,36 @@ dmic: dmic {
#sound-dai-cells = <0>;
};
+ hdmi-connector {
+ compatible = "hdmi-connector";
+ label = "hdmi";
+ type = "a";
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&it6263_out>;
+ };
+ };
+ };
+
+ reg_1v8_ext: regulator-1v8-ext {
+ compatible = "regulator-fixed";
+ regulator-name = "1V8_EXT";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_3v3_ext: regulator-3v3-ext {
+ compatible = "regulator-fixed";
+ regulator-name = "3V3_EXT";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
reg_m2_pwr: regulator-m2-pwr {
compatible = "regulator-fixed";
regulator-name = "M.2-power";
@@ -210,6 +240,10 @@ memory@80000000 {
};
};
+&dcif {
+ status = "okay";
+};
+
&enetc1 {
clocks = <&scmi_clk IMX94_CLK_MAC4>;
clock-names = "ref";
@@ -248,6 +282,21 @@ &flexcan4 {
status = "okay";
};
+&ldb {
+ assigned-clocks = <&scmi_clk IMX94_CLK_LDBPLL_VCO>,
+ <&scmi_clk IMX94_CLK_LDBPLL>;
+ assigned-clock-rates = <4158000000>, <1039500000>;
+ status = "okay";
+
+ ports {
+ port@1 {
+ lvds_out: endpoint {
+ remote-endpoint = <&it6263_in>;
+ };
+ };
+ };
+};
+
&lpi2c3 {
clock-frequency = <400000>;
pinctrl-0 = <&pinctrl_lpi2c3>;
@@ -331,6 +380,43 @@ i2c@3 {
reg = <3>;
#address-cells = <1>;
#size-cells = <0>;
+
+ hdmi@4c {
+ compatible = "ite,it6263";
+ reg = <0x4c>;
+ data-mapping = "jeida-24";
+ reset-gpios = <&pcal6416_i2c3_u171 8 GPIO_ACTIVE_LOW>;
+ ivdd-supply = <®_1v8_ext>;
+ ovdd-supply = <®_3v3_ext>;
+ txavcc18-supply = <®_1v8_ext>;
+ txavcc33-supply = <®_3v3_ext>;
+ pvcc1-supply = <®_1v8_ext>;
+ pvcc2-supply = <®_1v8_ext>;
+ avcc-supply = <®_3v3_ext>;
+ anvdd-supply = <®_1v8_ext>;
+ apvdd-supply = <®_1v8_ext>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ it6263_in: endpoint {
+ remote-endpoint = <&lvds_out>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ it6263_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+ };
};
i2c@4 {
--
2.51.0
^ permalink raw reply related
* [PATCH v9 9/9] MAINTAINERS: Add entry for i.MX94 DCIF driver
From: Laurentiu Palcu @ 2026-06-12 11:58 UTC (permalink / raw)
To: Ying Liu, Luca Ceresoli
Cc: Laurentiu Palcu, linux-clk, imx, devicetree, linux-arm-kernel,
linux-kernel, dri-devel
In-Reply-To: <20260612-dcif-upstreaming-v9-0-8d0ff89aa3c5@oss.nxp.com>
The driver is part of DRM subsystem and is located in
drivers/gpu/drm/imx/dcif.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
---
MAINTAINERS | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f1caa6e5198b9..e8931231b5b7e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19492,6 +19492,15 @@ S: Maintained
F: Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml
F: drivers/media/platform/nxp/imx-jpeg
+NXP i.MX 94 DCIF DRIVER
+M: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
+L: dri-devel@lists.freedesktop.org
+L: imx@lists.linux.dev
+S: Maintained
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
+F: Documentation/devicetree/bindings/display/imx/nxp,imx94-dcif.yaml
+F: drivers/gpu/drm/imx/dcif/
+
NXP i.MX CLOCK DRIVERS
M: Abel Vesa <abelvesa@kernel.org>
R: Peng Fan <peng.fan@nxp.com>
--
2.51.0
^ permalink raw reply related
* [PATCH v9 7/9] arm64: dts: imx94: Add display pipeline nodes
From: Laurentiu Palcu @ 2026-06-12 11:58 UTC (permalink / raw)
To: Ying Liu, Luca Ceresoli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
Cc: Laurentiu Palcu, linux-clk, imx, devicetree, linux-arm-kernel,
linux-kernel, dri-devel
In-Reply-To: <20260612-dcif-upstreaming-v9-0-8d0ff89aa3c5@oss.nxp.com>
Add the nodes necessary for the display pipeline on i.MX94:
* LVDS/DISPLAY CSR;
* clock-ldb-pll-div7 needed by DCIF and LDB;
* Display controller interface (DCIF);
* LVDS display bridge (LDB);
Co-developed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
---
arch/arm64/boot/dts/freescale/imx94.dtsi | 82 ++++++++++++++++++++++++++++++++
1 file changed, 82 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx94.dtsi b/arch/arm64/boot/dts/freescale/imx94.dtsi
index a6cb5a6e848b3..95d862682703c 100644
--- a/arch/arm64/boot/dts/freescale/imx94.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx94.dtsi
@@ -3,6 +3,7 @@
* Copyright 2024-2025 NXP
*/
+#include <dt-bindings/clock/nxp,imx94-clock.h>
#include <dt-bindings/dma/fsl-edma.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
@@ -39,6 +40,15 @@ clk_ext1: clock-ext1 {
clock-output-names = "clk_ext1";
};
+ clk_ldb_pll_div7: clock-ldb-pll-div7 {
+ compatible = "fixed-factor-clock";
+ #clock-cells = <0>;
+ clocks = <&scmi_clk IMX94_CLK_LDBPLL>;
+ clock-div = <7>;
+ clock-mult = <1>;
+ clock-output-names = "ldb_pll_div7";
+ };
+
sai1_mclk: clock-sai1-mclk1 {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -1305,6 +1315,78 @@ wdog4: watchdog@49230000 {
};
};
+ dispmix_csr: syscon@4b010000 {
+ compatible = "nxp,imx94-display-csr", "syscon";
+ reg = <0x0 0x4b010000 0x0 0x10000>;
+ clocks = <&scmi_clk IMX94_CLK_DISPAPB>;
+ #clock-cells = <1>;
+ power-domains = <&scmi_devpd IMX94_PD_DISPLAY>;
+ assigned-clocks = <&scmi_clk IMX94_CLK_DISPAXI>,
+ <&scmi_clk IMX94_CLK_DISPAPB>;
+ assigned-clock-parents = <&scmi_clk IMX94_CLK_SYSPLL1_PFD1>,
+ <&scmi_clk IMX94_CLK_SYSPLL1_PFD1_DIV2>;
+ assigned-clock-rates = <400000000>, <133333333>;
+ };
+
+ lvds_csr: syscon@4b0c0000 {
+ compatible = "nxp,imx94-lvds-csr", "syscon";
+ reg = <0x0 0x4b0c0000 0x0 0x10000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ clocks = <&scmi_clk IMX94_CLK_DISPAPB>;
+ #clock-cells = <1>;
+ power-domains = <&scmi_devpd IMX94_PD_DISPLAY>;
+
+ ldb: ldb@4 {
+ compatible = "fsl,imx94-ldb";
+ reg = <0x4 0x4>, <0x8 0x4>;
+ reg-names = "ldb", "lvds";
+ clocks = <&lvds_csr IMX94_CLK_DISPMIX_LVDS_CLK_GATE>;
+ clock-names = "ldb";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ lvds_in: endpoint {
+ remote-endpoint = <&dcif_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ };
+ };
+ };
+ };
+
+ dcif: display-controller@4b120000 {
+ compatible = "nxp,imx94-dcif";
+ reg = <0x0 0x4b120000 0x0 0x300000>;
+ interrupts = <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 378 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 379 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "common", "bg_layer", "fg_layer";
+ clocks = <&scmi_clk IMX94_CLK_DISPAPB>,
+ <&scmi_clk IMX94_CLK_DISPAXI>,
+ <&dispmix_csr IMX94_CLK_DISPMIX_CLK_SEL>;
+ clock-names = "apb", "axi", "pix";
+ assigned-clocks = <&dispmix_csr IMX94_CLK_DISPMIX_CLK_SEL>;
+ assigned-clock-parents = <&clk_ldb_pll_div7>;
+ power-domains = <&scmi_devpd IMX94_PD_DISPLAY>;
+ status = "disabled";
+
+ port {
+ dcif_out: endpoint {
+ remote-endpoint = <&lvds_in>;
+ };
+ };
+ };
+
hsio_blk_ctl: syscon@4c0100c0 {
compatible = "nxp,imx95-hsio-blk-ctl", "syscon";
reg = <0x0 0x4c0100c0 0x0 0x1>;
--
2.51.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