* Re: [PATCH v6 2/9] dt-bindings: media: nxp: Add Wave6 video codec device
From: Krzysztof Kozlowski @ 2026-06-25 6:28 UTC (permalink / raw)
To: Nas Chung
Cc: Conor Dooley, mchehab@kernel.org, hverkuil@xs4all.nl,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
shawnguo@kernel.org, s.hauer@pengutronix.de,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-imx@nxp.com,
linux-arm-kernel@lists.infradead.org, jackson.lee, lafley.kim,
marek.vasut@mailbox.org
In-Reply-To: <SL2P216MB2441BB9DC91CCBE494F2B45BFBEC2@SL2P216MB2441.KORP216.PROD.OUTLOOK.COM>
On Thu, Jun 25, 2026 at 01:43:33AM +0000, Nas Chung wrote:
> >> + sram:
> >> + $ref: /schemas/types.yaml#/definitions/phandle
> >> + description:
> >> + phandle to the SRAM node used to store reference data, reducing DMA
> >> + memory bandwidth.
> >> +
> >> + iommus:
> >> + maxItems: 1
> >> +
> >> + "#cooling-cells":
> >> + const: 2
> >> +
> >> + "#address-cells":
> >> + const: 2
> >> +
> >> + "#size-cells":
> >> + const: 2
> >> +
> >> + ranges: true
> >> +
> >> +patternProperties:
> >> + "^interface@[0-9a-f]+$":
> >
> >I have to wonder if this interface business is required at all.
> >Why can this not go into the parent, with each region fetchable via
> >reg-names, interrupt-names and iommu-names?
>
> Thanks for your feedback.
>
> I did try the flat model, but the blocker is the IOMMU.
>
> The control region and four interface regions are independent DMA requesters
> with distinct stream IDs, and each interface can be assigned to a different VM,
> driving the video core with its own isolated memory.
>
> If all stream IDs are listed under the parent's iommus, they bind to a
> single device and share one domain, so the isolation is lost.
> This is the main reason I added the interface nodes.
Feels similar to issue Qualcomm has. I rejected such subnodes and
Qualcomm came with a solution in DMA IOMMU code, but that solution was
rejected by DMA folks:
https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/
I don't have proper arguments to convince DMA folks, thus I agree for
Qualcomm for the subnodes. It should be fine here as well, in such case.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: input: Add Qualcomm SPMI PMIC haptics
From: Krzysztof Kozlowski @ 2026-06-25 6:23 UTC (permalink / raw)
To: Fenglin Wu, linux-arm-msm, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Stephen Boyd,
Bjorn Andersson, Konrad Dybcio
Cc: David Collins, Subbaraman Narayanamurthy, Kamal Wadhwa, kernel,
linux-input, devicetree, linux-kernel
In-Reply-To: <20260624-qcom-spmi-haptics-v2-1-b9118e60f3e3@oss.qualcomm.com>
On 25/06/2026 04:00, Fenglin Wu wrote:
> Add binding document for the haptics module inside Qualcomm PMIC
> PMIH0108.
>
> Assisted-by: Claude:claude-4-6-sonnet
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
> .../bindings/input/qcom,spmi-haptics.yaml | 132 +++++++++++++++++++++
> 1 file changed, 132 insertions(+)
You did not test this before sending, therefore this fits in to AI slop
category. I do not accept AI slop to be sent to mailing list.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v8 2/2] hwmon: Add Eswin EIC7700 PVT sensor driver
From: sashiko-bot @ 2026-06-25 6:22 UTC (permalink / raw)
To: hehuan1; +Cc: linux-hwmon, devicetree, robh, conor+dt
In-Reply-To: <20260625061214.1648-1-hehuan1@eswincomputing.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Missing Hardware State Restoration after System Sleep / Runtime PM
--
commit 90e30b4d9c6082a265da7f7091bf9e2cd31aec81
Author: Huan He <hehuan1@eswincomputing.com>
hwmon: Add Eswin EIC7700 PVT sensor driver
This commit introduces support for the ESWIN EIC7700 Voltage and
Temperature (PVT) sensor. The driver implements temperature and voltage
monitoring using polynomial conversion and provides a sysfs interface
for accessing the sensor data.
> diff --git a/drivers/hwmon/eic7700-pvt.c b/drivers/hwmon/eic7700-pvt.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/hwmon/eic7700-pvt.c
[ ... ]
> +static int __maybe_unused eic7700_pvt_runtime_resume(struct device *dev)
> +{
> + struct pvt_hwmon *pvt = dev_get_drvdata(dev);
> + int ret;
> +
> + ret = clk_bulk_prepare_enable(PVT_CLK_NUM, pvt->clks);
> + if (ret) {
> + dev_err(dev, "Failed to enable clocks: %d\n", ret);
> + return ret;
> + }
> +
[Severity: Medium]
Does this code need to restore the hardware trim value after resuming?
The driver initializes the sensor mode and trim configuration via
eic7700_pvt_init_iface() during probe.
If the device enters system suspend or runtime suspend and the power domain
is disabled, the hardware configuration could be lost. Since the driver
utilizes pm_runtime_force_resume() for system suspend paths, should this
callback re-apply the trim values to prevent incorrect sensor readings
upon wake?
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625061049.1614-1-hehuan1@eswincomputing.com?part=2
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: mfd: qcom,spmi-pmic: Document haptics device
From: Krzysztof Kozlowski @ 2026-06-25 6:21 UTC (permalink / raw)
To: Fenglin Wu, linux-arm-msm, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Stephen Boyd,
Bjorn Andersson, Konrad Dybcio
Cc: David Collins, Subbaraman Narayanamurthy, Kamal Wadhwa, kernel,
linux-input, devicetree, linux-kernel
In-Reply-To: <20260624-qcom-spmi-haptics-v2-2-b9118e60f3e3@oss.qualcomm.com>
On 25/06/2026 04:00, Fenglin Wu wrote:
> Some of the Qualcomm SPMI PMIC has haptics device in it, add it in the
> device list.
>
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
Still nothing about merging issue/dependency I asked to explain. You did
not solve it, you did not mention it how I asked. We speak about basics
of Linux kernel development process. If you cannot get this, even after
I directed you in v1, then you need to attend internal trainings or read
internal docs (go/upstream) where this is explained.
I drop the patches from DT Patchwork.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 0/4] input: misc: Add an initial driver for haptics inside Qcom PMIH010x PMIC
From: Krzysztof Kozlowski @ 2026-06-25 6:19 UTC (permalink / raw)
To: Fenglin Wu
Cc: linux-arm-msm, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Stephen Boyd, Bjorn Andersson,
Konrad Dybcio, David Collins, Subbaraman Narayanamurthy,
Kamal Wadhwa, kernel, linux-input, devicetree, linux-kernel
In-Reply-To: <36043887-6bbd-4b2d-941c-bf222786b80d@oss.qualcomm.com>
On 25/06/2026 03:41, Fenglin Wu wrote:
>
> On 6/24/2026 6:05 PM, Krzysztof Kozlowski wrote:
>> No. Act as maintainer. Clone Linus tree, apply the patch and see if
>> everything works. My claim is that nothing works and maintainer tree is
>> broken.
>>
>> Best regards,
>> Krzysztof
>
> Thanks for the explanation. I just did that and I didn't see conflict
> when applying the binding and driver changes, but I did see a conflict
> when applying the DTS change. I will drop the DTS change 1st and resend
> them after the driver and binding changes get accepted.
That is not what I meant and you did not follow maintainer process. And
why did you ignore second binding? Identify how many separate
maintainers are here and act like them. I looked again at your patchset
and I am sure about that - patchset is unmergeable by Lee.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] iio: dac: dac8163: Add driver for DAC8163
From: Andy Shevchenko @ 2026-06-25 6:18 UTC (permalink / raw)
To: Lukas
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-kernel,
linux-iio, devicetree
In-Reply-To: <ajvt5J5Cs5cOdTLt@berta-MS-7693>
On Wed, Jun 24, 2026 at 04:47:00PM +0200, Lukas wrote:
> On Tue, Jun 23, 2026 at 10:39:23PM +0300, Andy Shevchenko wrote:
>
> > > + dev_dbg(dev, "%s: val=%d val2=%d\n", __func__, val, val2);
> >
> > No. Is it RFC? PoC? Or production-ready? If not the latter, come when it will
> > be production-ready.
>
> I will remove the debug print. I tried my best to make this driver production-ready.
> I saw that other drivers also have similar debug messages so i didnt
> remove it after my first tests and thought it is ok to leave it in
> there.
Debug messages are different. And in IIO we don't have them (perhaps some
historical leftovers or corner cases, dunno). If you have an example, share
the pointer, I will check that. Perhaps we can drop them in that driver.
(The debug prints like above are fine in the drivers in staging, but staging
is not really accepting much nowadays, so it's not the point.)
> My intention was to try to apply the suggestions and comments i
> get and send a second revision. Do you think thats the right way?
That's the way how it goes. You address all or almost all comments,
send a new version where in the comments you need to explain the
non-addressed pieces ("why?" they haven't been addressed).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v8 1/2] dt-bindings: hwmon: Add Eswin EIC7700 PVT sensor
From: sashiko-bot @ 2026-06-25 6:17 UTC (permalink / raw)
To: hehuan1; +Cc: conor+dt, devicetree, robh, linux-hwmon
In-Reply-To: <20260625061147.1631-1-hehuan1@eswincomputing.com>
> From: Huan He <hehuan1@eswincomputing.com>
>
> Add device tree binding documentation for ESWIN EIC7700 Voltage and
> Temperature sensor.
>
> The EIC7700 SoC integrates two PVT instances for monitoring SoC and DDR
> power domains respectively.
>
> Signed-off-by: Yulin Lu <luyulin@eswincomputing.com>
> Signed-off-by: Huan He <hehuan1@eswincomputing.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625061049.1614-1-hehuan1@eswincomputing.com?part=1
^ permalink raw reply
* [PATCH v8 2/2] hwmon: Add Eswin EIC7700 PVT sensor driver
From: hehuan1 @ 2026-06-25 6:12 UTC (permalink / raw)
To: linux, robh, krzk+dt, conor+dt, p.zabel, linux-hwmon, devicetree,
linux-kernel
Cc: ningyu, linmin, pinkesh.vaghela, luyulin, dongxuyang, Huan He
In-Reply-To: <20260625061049.1614-1-hehuan1@eswincomputing.com>
From: Huan He <hehuan1@eswincomputing.com>
Add support for ESWIN EIC7700 Voltage and Temperature sensor. The driver
supports temperature and voltage monitoring with polynomial conversion,
and provides sysfs interface for sensor data access.
The PVT IP contains one temperature sensor and one voltage sensor.
Signed-off-by: Yulin Lu <luyulin@eswincomputing.com>
Signed-off-by: Huan He <hehuan1@eswincomputing.com>
---
drivers/hwmon/Kconfig | 12 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/eic7700-pvt.c | 507 ++++++++++++++++++++++++++++++++++++
drivers/hwmon/eic7700-pvt.h | 99 +++++++
4 files changed, 619 insertions(+)
create mode 100644 drivers/hwmon/eic7700-pvt.c
create mode 100644 drivers/hwmon/eic7700-pvt.h
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 5c2d3ff5fce8..6375c5f1136e 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -2067,6 +2067,18 @@ config SENSORS_DME1737
This driver can also be built as a module. If so, the module
will be called dme1737.
+config SENSORS_EIC7700_PVT
+ tristate "Eswin EIC7700 Voltage, Temperature sensor driver"
+ depends on ARCH_ESWIN || COMPILE_TEST
+ depends on HWMON
+ select POLYNOMIAL
+ help
+ If you say yes here you get support for Eswin EIC7700 PVT sensor
+ embedded into the SoC.
+
+ This driver can also be built as a module. If so, the module will be
+ called eic7700-pvt.
+
config SENSORS_EMC1403
tristate "SMSC EMC1403/23 thermal sensor"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 63effc0ab8d1..e49cfdda970c 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_SENSORS_DME1737) += dme1737.o
obj-$(CONFIG_SENSORS_DRIVETEMP) += drivetemp.o
obj-$(CONFIG_SENSORS_DS620) += ds620.o
obj-$(CONFIG_SENSORS_DS1621) += ds1621.o
+obj-$(CONFIG_SENSORS_EIC7700_PVT) += eic7700-pvt.o
obj-$(CONFIG_SENSORS_EMC1403) += emc1403.o
obj-$(CONFIG_SENSORS_EMC1812) += emc1812.o
obj-$(CONFIG_SENSORS_EMC2103) += emc2103.o
diff --git a/drivers/hwmon/eic7700-pvt.c b/drivers/hwmon/eic7700-pvt.c
new file mode 100644
index 000000000000..f694259258a9
--- /dev/null
+++ b/drivers/hwmon/eic7700-pvt.c
@@ -0,0 +1,507 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ESWIN EIC7700 Voltage, Temperature sensor driver
+ *
+ * Copyright 2026, Beijing ESWIN Computing Technology Co., Ltd.
+ *
+ * Authors:
+ * Yulin Lu <luyulin@eswincomputing.com>
+ * Huan He <hehuan1@eswincomputing.com>
+ */
+
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <linux/polynomial.h>
+#include <linux/reset.h>
+#include "eic7700-pvt.h"
+
+static const struct pvt_sensor_info pvt_info[] = {
+ PVT_SENSOR_INFO(0, "Temperature", hwmon_temp, TEMP),
+ PVT_SENSOR_INFO(0, "Voltage", hwmon_in, VOLT),
+};
+
+static const char * const pvt_clk_names[PVT_CLK_NUM] = {"enable", "apb"};
+
+/*
+ * The original translation formulae of the temperature (in degrees of Celsius)
+ * to PVT data and vice-versa are following:
+ * N = 6.0818e-8*(T^4) +1.2873e-5*(T^3) + 7.2244e-3*(T^2) + 3.6484*(T^1) +
+ * 1.6198e2,
+ * T = -1.8439e-11*(N^4) + 8.0705e-8*(N^3) + -1.8501e-4*(N^2) +
+ * 3.2843e-1*(N^1) - 4.8690e1,
+ * where T = [-40, 125]C and N = [27, 771].
+ * They must be accordingly altered to be suitable for the integer arithmetics.
+ * The technique is called 'factor redistribution', which just makes sure the
+ * multiplications and divisions are made so to have a result of the operations
+ * within the integer numbers limit. In addition we need to translate the
+ * formulae to accept millidegrees of Celsius. Here what they look like after
+ * the alterations:
+ * N = (60818e-20*(T^4) + 12873e-14*(T^3) + 72244e-9*(T^2) + 36484e-3*T +
+ * 16198e2) / 1e4,
+ * T = -18439e-12*(N^4) + 80705e-9*(N^3) - 185010e-6*(N^2) + 328430e-3*N -
+ * 48690,
+ * where T = [-40000, 125000] mC and N = [27, 771].
+ */
+static const struct polynomial poly_N_to_temp = {
+ .total_divider = 1,
+ .terms = {
+ {4, -18439, 1000, 1},
+ {3, 80705, 1000, 1},
+ {2, -185010, 1000, 1},
+ {1, 328430, 1000, 1},
+ {0, -48690, 1, 1}
+ }
+};
+
+/*
+ * Similar alterations are performed for the voltage conversion equations.
+ * The original formulae are:
+ * N = 1.3905e3*V - 5.7685e2,
+ * V = (N + 5.7685e2) / 1.3905e3,
+ * where V = [0.72, 0.88] V and N = [424, 646].
+ * After the optimization they looks as follows:
+ * N = (13905e-3*V - 5768.5) / 10,
+ * V = (N * 10^5 / 13905 + 57685 * 10^3 / 13905) / 10.
+ * where V = [720, 880] mV and N = [424, 646].
+ */
+static const struct polynomial poly_N_to_volt = {
+ .total_divider = 10,
+ .terms = {
+ {1, 100000, 13905, 1},
+ {0, 57685000, 1, 13905}
+ }
+};
+
+static inline u32 eic7700_pvt_update(void __iomem *reg, u32 mask, u32 data)
+{
+ u32 old;
+
+ old = readl_relaxed(reg);
+ writel((old & ~mask) | (data & mask), reg);
+
+ return old & mask;
+}
+
+static inline void eic7700_pvt_set_mode(struct pvt_hwmon *pvt, u32 mode)
+{
+ u32 old;
+
+ mode = FIELD_PREP(PVT_MODE_MASK, mode);
+
+ old = eic7700_pvt_update(pvt->regs + PVT_ENA, PVT_ENA_EN, 0);
+ eic7700_pvt_update(pvt->regs + PVT_MODE, PVT_MODE_MASK, mode);
+ eic7700_pvt_update(pvt->regs + PVT_ENA, PVT_ENA_EN, old);
+}
+
+static inline void eic7700_pvt_set_trim(struct pvt_hwmon *pvt, u32 val)
+{
+ u32 old;
+
+ old = eic7700_pvt_update(pvt->regs + PVT_ENA, PVT_ENA_EN, 0);
+ writel(val, pvt->regs + PVT_TRIM);
+ eic7700_pvt_update(pvt->regs + PVT_ENA, PVT_ENA_EN, old);
+}
+
+static irqreturn_t eic7700_pvt_hard_isr(int irq, void *data)
+{
+ struct pvt_hwmon *pvt = data;
+ u32 stat, val;
+ int active;
+
+ if (IS_ENABLED(CONFIG_PM)) {
+ active = pm_runtime_get_if_active(pvt->dev);
+ if (active <= 0)
+ return IRQ_NONE;
+ }
+
+ stat = readl(pvt->regs + PVT_INT);
+ if (!(stat & PVT_INT_STAT)) {
+ if (IS_ENABLED(CONFIG_PM))
+ pm_runtime_put(pvt->dev);
+ return IRQ_NONE;
+ }
+
+ eic7700_pvt_update(pvt->regs + PVT_INT, PVT_INT_CLR, PVT_INT_CLR);
+ /*
+ * Read the data, update the cache and notify a waiter of this event.
+ */
+ val = readl(pvt->regs + PVT_DATA);
+ WRITE_ONCE(pvt->data_cache, FIELD_GET(PVT_DATA_OUT, val));
+ complete(&pvt->conversion);
+
+ if (IS_ENABLED(CONFIG_PM))
+ pm_runtime_put(pvt->dev);
+
+ return IRQ_HANDLED;
+}
+
+static int eic7700_pvt_read_data(struct pvt_hwmon *pvt,
+ enum pvt_sensor_type type, long *val)
+{
+ unsigned long timeout;
+ u32 data;
+ int ret;
+
+ /*
+ * Wait for PVT conversion to complete and update the data cache. The
+ * data read procedure is following: set the requested PVT sensor mode,
+ * enable conversion, wait until conversion is finished, then disable
+ * conversion and IRQ, and read the cached data.
+ */
+ reinit_completion(&pvt->conversion);
+
+ eic7700_pvt_set_mode(pvt, pvt_info[type].mode);
+ eic7700_pvt_update(pvt->regs + PVT_ENA, PVT_ENA_EN, PVT_ENA_EN);
+
+ /*
+ * Wait with timeout since in case if the sensor is suddenly powered
+ * down the request won't be completed and the caller will hang up on
+ * this procedure until the power is back up again. Multiply the
+ * timeout by the factor of two to prevent a false timeout.
+ */
+ timeout = 2 * usecs_to_jiffies(ktime_to_us(pvt->timeout));
+ ret = wait_for_completion_timeout(&pvt->conversion, timeout);
+
+ eic7700_pvt_update(pvt->regs + PVT_ENA, PVT_ENA_EN, 0);
+ eic7700_pvt_update(pvt->regs + PVT_INT, PVT_INT_CLR, PVT_INT_CLR);
+
+ if (!ret)
+ synchronize_irq(pvt->irq);
+
+ data = READ_ONCE(pvt->data_cache);
+
+ if (!ret)
+ return -ETIMEDOUT;
+
+ if (type == PVT_TEMP)
+ *val = polynomial_calc(&poly_N_to_temp, data);
+ else
+ *val = polynomial_calc(&poly_N_to_volt, data);
+
+ return 0;
+}
+
+static const struct hwmon_channel_info *pvt_channel_info[] = {
+ HWMON_CHANNEL_INFO(chip, HWMON_C_REGISTER_TZ),
+ HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT | HWMON_T_LABEL),
+ HWMON_CHANNEL_INFO(in, HWMON_I_INPUT | HWMON_I_LABEL),
+ NULL
+};
+
+static umode_t eic7700_pvt_hwmon_is_visible(const void *data,
+ enum hwmon_sensor_types type,
+ u32 attr, int ch)
+{
+ switch (type) {
+ case hwmon_temp:
+ switch (attr) {
+ case hwmon_temp_input:
+ case hwmon_temp_label:
+ return 0444;
+ }
+ break;
+ case hwmon_in:
+ switch (attr) {
+ case hwmon_in_input:
+ case hwmon_in_label:
+ return 0444;
+ }
+ break;
+ default:
+ break;
+ }
+
+ return 0;
+}
+
+static int eic7700_pvt_hwmon_read(struct device *dev,
+ enum hwmon_sensor_types type, u32 attr,
+ int ch, long *val)
+{
+ struct pvt_hwmon *pvt = dev_get_drvdata(dev);
+ int ret;
+
+ ret = pm_runtime_get_sync(pvt->dev);
+ if (ret < 0) {
+ dev_err(pvt->dev, "Failed to resume PVT device: %d\n", ret);
+ pm_runtime_put_noidle(pvt->dev);
+ return ret;
+ }
+
+ switch (type) {
+ case hwmon_temp:
+ switch (attr) {
+ case hwmon_temp_input:
+ ret = eic7700_pvt_read_data(pvt, ch, val);
+ break;
+ default:
+ ret = -EOPNOTSUPP;
+ }
+ break;
+ case hwmon_in:
+ if (attr == hwmon_in_input)
+ ret = eic7700_pvt_read_data(pvt, PVT_VOLT + ch, val);
+ else
+ ret = -EOPNOTSUPP;
+ break;
+ default:
+ ret = -EOPNOTSUPP;
+ }
+
+ pm_runtime_mark_last_busy(pvt->dev);
+ pm_runtime_put_autosuspend(pvt->dev);
+ return ret;
+}
+
+static int eic7700_pvt_hwmon_read_string(struct device *dev,
+ enum hwmon_sensor_types type, u32 attr,
+ int ch, const char **str)
+{
+ switch (type) {
+ case hwmon_temp:
+ if (attr == hwmon_temp_label) {
+ *str = pvt_info[ch].label;
+ return 0;
+ }
+ break;
+ case hwmon_in:
+ if (attr == hwmon_in_label) {
+ *str = pvt_info[PVT_VOLT + ch].label;
+ return 0;
+ }
+ break;
+ default:
+ break;
+ }
+
+ return -EOPNOTSUPP;
+}
+
+static const struct hwmon_ops pvt_hwmon_ops = {
+ .is_visible = eic7700_pvt_hwmon_is_visible,
+ .read = eic7700_pvt_hwmon_read,
+ .read_string = eic7700_pvt_hwmon_read_string
+};
+
+static const struct hwmon_chip_info pvt_hwmon_info = {
+ .ops = &pvt_hwmon_ops,
+ .info = pvt_channel_info
+};
+
+static struct pvt_hwmon *eic7700_pvt_create_data(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct pvt_hwmon *pvt;
+
+ pvt = devm_kzalloc(dev, sizeof(*pvt), GFP_KERNEL);
+ if (!pvt)
+ return ERR_PTR(-ENOMEM);
+
+ pvt->dev = dev;
+ init_completion(&pvt->conversion);
+
+ return pvt;
+}
+
+static int eic7700_pvt_init_iface(struct pvt_hwmon *pvt)
+{
+ /*
+ * Make sure controller are disabled so not to accidentally have ISR
+ * executed before the driver data is fully initialized. Clear the IRQ
+ * status as well.
+ */
+ eic7700_pvt_update(pvt->regs + PVT_ENA, PVT_ENA_EN, 0);
+ eic7700_pvt_update(pvt->regs + PVT_INT, PVT_INT_CLR, PVT_INT_CLR);
+ readl(pvt->regs + PVT_INT);
+ readl(pvt->regs + PVT_DATA);
+
+ /* Setup default sensor mode and temperature trim. */
+ eic7700_pvt_set_mode(pvt, pvt_info[PVT_TEMP].mode);
+
+ /*
+ * Max conversion latency (~333 µs) derived from PVT spec:
+ * maximum sampling rate = 3000 samples/sec.
+ */
+ pvt->timeout = ns_to_ktime(PVT_TOUT_MIN);
+
+ eic7700_pvt_set_trim(pvt, PVT_TRIM_DEF);
+
+ return 0;
+}
+
+static int eic7700_pvt_request_irq(struct pvt_hwmon *pvt)
+{
+ struct platform_device *pdev = to_platform_device(pvt->dev);
+ int ret;
+
+ pvt->irq = platform_get_irq(pdev, 0);
+ if (pvt->irq < 0)
+ return pvt->irq;
+
+ ret = devm_request_threaded_irq(pvt->dev, pvt->irq,
+ eic7700_pvt_hard_isr, NULL,
+ IRQF_TRIGGER_HIGH, "pvt", pvt);
+ if (ret) {
+ dev_err(pvt->dev, "Couldn't request PVT IRQ\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static int eic7700_pvt_create_hwmon(struct pvt_hwmon *pvt)
+{
+ pvt->hwmon = devm_hwmon_device_register_with_info(pvt->dev, "pvt",
+ pvt, &pvt_hwmon_info,
+ NULL);
+ if (IS_ERR(pvt->hwmon)) {
+ dev_err(pvt->dev, "Couldn't create hwmon device\n");
+ return PTR_ERR(pvt->hwmon);
+ }
+
+ return 0;
+}
+
+static void eic7700_pvt_disable_pm_runtime(void *data)
+{
+ struct pvt_hwmon *pvt = data;
+
+ pm_runtime_dont_use_autosuspend(pvt->dev);
+ pm_runtime_disable(pvt->dev);
+
+ if (!pm_runtime_status_suspended(pvt->dev)) {
+ clk_bulk_disable_unprepare(PVT_CLK_NUM, pvt->clks);
+ pm_runtime_set_suspended(pvt->dev);
+ }
+}
+
+static int eic7700_pvt_probe(struct platform_device *pdev)
+{
+ struct reset_control *rst;
+ struct pvt_hwmon *pvt;
+ int i, ret;
+
+ pvt = eic7700_pvt_create_data(pdev);
+ if (IS_ERR(pvt))
+ return PTR_ERR(pvt);
+
+ platform_set_drvdata(pdev, pvt);
+
+ pvt->regs = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(pvt->regs))
+ return PTR_ERR(pvt->regs);
+
+ for (i = 0; i < PVT_CLK_NUM; i++)
+ pvt->clks[i].id = pvt_clk_names[i];
+
+ ret = devm_clk_bulk_get(&pdev->dev, PVT_CLK_NUM, pvt->clks);
+ if (ret)
+ return dev_err_probe(&pdev->dev, ret,
+ "Couldn't get clock descriptors\n");
+
+ rst = devm_reset_control_get_exclusive_deasserted(&pdev->dev, NULL);
+ if (IS_ERR(rst))
+ return dev_err_probe(pvt->dev, PTR_ERR(rst),
+ "Couldn't get reset control\n");
+
+ ret = clk_bulk_prepare_enable(PVT_CLK_NUM, pvt->clks);
+ if (ret)
+ return dev_err_probe(pvt->dev, ret,
+ "Failed to enable clocks\n");
+
+ ret = eic7700_pvt_init_iface(pvt);
+ if (ret) {
+ clk_bulk_disable_unprepare(PVT_CLK_NUM, pvt->clks);
+ return ret;
+ }
+
+ if (IS_ENABLED(CONFIG_PM))
+ clk_bulk_disable_unprepare(PVT_CLK_NUM, pvt->clks);
+
+ pm_runtime_enable(&pdev->dev);
+ pm_runtime_set_autosuspend_delay(&pdev->dev, 3000);
+ pm_runtime_use_autosuspend(&pdev->dev);
+ pm_runtime_get_noresume(&pdev->dev);
+
+ ret = devm_add_action_or_reset(pvt->dev, eic7700_pvt_disable_pm_runtime,
+ pvt);
+ if (ret) {
+ pm_runtime_put_noidle(&pdev->dev);
+ return dev_err_probe(&pdev->dev, ret,
+ "Can't register PM cleanup\n");
+ }
+
+ ret = eic7700_pvt_request_irq(pvt);
+ if (ret)
+ goto err_put_pm_runtime;
+
+ ret = eic7700_pvt_create_hwmon(pvt);
+ if (ret)
+ goto err_put_pm_runtime;
+
+ pm_runtime_put_autosuspend(&pdev->dev);
+
+ return 0;
+
+err_put_pm_runtime:
+ pm_runtime_put_noidle(&pdev->dev);
+ return ret;
+}
+
+static int __maybe_unused eic7700_pvt_runtime_resume(struct device *dev)
+{
+ struct pvt_hwmon *pvt = dev_get_drvdata(dev);
+ int ret;
+
+ ret = clk_bulk_prepare_enable(PVT_CLK_NUM, pvt->clks);
+ if (ret) {
+ dev_err(dev, "Failed to enable clocks: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int __maybe_unused eic7700_pvt_runtime_suspend(struct device *dev)
+{
+ struct pvt_hwmon *pvt = dev_get_drvdata(dev);
+
+ clk_bulk_disable_unprepare(PVT_CLK_NUM, pvt->clks);
+
+ return 0;
+}
+
+static const struct dev_pm_ops eic7700_pvt_pm_ops = {
+ SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, pm_runtime_force_resume)
+ RUNTIME_PM_OPS(eic7700_pvt_runtime_suspend, eic7700_pvt_runtime_resume,
+ NULL)
+};
+
+static const struct of_device_id pvt_of_match[] = {
+ { .compatible = "eswin,eic7700-pvt"},
+ { }
+};
+MODULE_DEVICE_TABLE(of, pvt_of_match);
+
+static struct platform_driver pvt_driver = {
+ .probe = eic7700_pvt_probe,
+ .driver = {
+ .name = "eic7700-pvt",
+ .of_match_table = pvt_of_match,
+ .pm = pm_ptr(&eic7700_pvt_pm_ops),
+ },
+};
+module_platform_driver(pvt_driver);
+
+MODULE_AUTHOR("Yulin Lu <luyulin@eswincomputing.com>");
+MODULE_AUTHOR("Huan He <hehuan1@eswincomputing.com>");
+MODULE_DESCRIPTION("Eswin eic7700 PVT driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/hwmon/eic7700-pvt.h b/drivers/hwmon/eic7700-pvt.h
new file mode 100644
index 000000000000..fb10f9e4e93a
--- /dev/null
+++ b/drivers/hwmon/eic7700-pvt.h
@@ -0,0 +1,99 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * ESWIN EIC7700 Voltage, Temperature sensor driver
+ *
+ * Copyright 2026, Beijing ESWIN Computing Technology Co., Ltd.
+ */
+#ifndef __HWMON_EIC7700_PVT_H__
+#define __HWMON_EIC7700_PVT_H__
+
+#include <linux/completion.h>
+#include <linux/hwmon.h>
+#include <linux/kernel.h>
+#include <linux/time.h>
+
+/* ESWIN EIC7700 PVT registers and their bitfields */
+#define PVT_TRIM 0x04
+#define PVT_MODE 0x08
+#define PVT_MODE_MASK GENMASK(2, 0)
+#define PVT_CTRL_MODE_TEMP 0x0
+#define PVT_CTRL_MODE_VOLT 0x4
+#define PVT_ENA 0x0c
+#define PVT_ENA_EN BIT(0)
+#define PVT_INT 0x10
+#define PVT_INT_STAT BIT(0)
+#define PVT_INT_CLR BIT(1)
+#define PVT_DATA 0x14
+#define PVT_DATA_OUT GENMASK(9, 0)
+
+/*
+ * PVT sensors-related limits and default values
+ * @PVT_TEMP_CHS: Number of temperature hwmon channels.
+ * @PVT_VOLT_CHS: Number of voltage hwmon channels.
+ * @PVT_TRIM_DEF: Default temperature sensor trim value (set a proper value
+ * when one is determined for ESWIN EIC7700 SoC).
+ * @PVT_TOUT_MIN: Minimal timeout between samples in nanoseconds.
+ */
+#define PVT_TEMP_CHS 1
+#define PVT_VOLT_CHS 1
+#define PVT_TRIM_DEF 0
+#define PVT_TOUT_MIN (NSEC_PER_SEC / 3000)
+
+/*
+ * enum pvt_sensor_type - ESWIN EIC7700 PVT sensor types (correspond to each PVT
+ * sampling mode)
+ * @PVT_TEMP: PVT Temperature sensor.
+ * @PVT_VOLT: PVT Voltage sensor.
+ */
+enum pvt_sensor_type {
+ PVT_TEMP = 0,
+ PVT_VOLT
+};
+
+#define PVT_CLK_NUM 2
+
+/*
+ * struct pvt_sensor_info - ESWIN EIC7700 PVT sensor informational structure
+ * @channel: Sensor channel ID.
+ * @label: hwmon sensor label.
+ * @mode: PVT mode corresponding to the channel.
+ * @type: Sensor type.
+ */
+struct pvt_sensor_info {
+ int channel;
+ const char *label;
+ u32 mode;
+ enum hwmon_sensor_types type;
+};
+
+#define PVT_SENSOR_INFO(_ch, _label, _type, _mode) \
+ { \
+ .channel = _ch, \
+ .label = _label, \
+ .mode = PVT_CTRL_MODE_ ##_mode, \
+ .type = _type, \
+ }
+
+/*
+ * struct pvt_hwmon - Eswin EIC7700 PVT private data
+ * @dev: device structure of the PVT platform device.
+ * @hwmon: hwmon device structure.
+ * @regs: pointer to the Eswin EIC7700 PVT registers region.
+ * @irq: PVT events IRQ number.
+ * @clks: PVT clock descriptors.
+ * @data_cache: data cache in raw format.
+ * @conversion: data conversion completion.
+ * @timeout: conversion timeout.
+ */
+struct pvt_hwmon {
+ struct device *dev;
+ struct device *hwmon;
+ void __iomem *regs;
+ int irq;
+ struct clk_bulk_data clks[PVT_CLK_NUM];
+ u32 data_cache;
+ struct completion conversion;
+ ktime_t timeout;
+};
+
+#endif /* __HWMON_EIC7700_PVT_H__ */
--
2.34.1
^ permalink raw reply related
* [PATCH v8 1/2] dt-bindings: hwmon: Add Eswin EIC7700 PVT sensor
From: hehuan1 @ 2026-06-25 6:11 UTC (permalink / raw)
To: linux, robh, krzk+dt, conor+dt, p.zabel, linux-hwmon, devicetree,
linux-kernel
Cc: ningyu, linmin, pinkesh.vaghela, luyulin, dongxuyang, Huan He
In-Reply-To: <20260625061049.1614-1-hehuan1@eswincomputing.com>
From: Huan He <hehuan1@eswincomputing.com>
Add device tree binding documentation for ESWIN EIC7700 Voltage and
Temperature sensor.
The EIC7700 SoC integrates two PVT instances for monitoring SoC and DDR
power domains respectively.
Signed-off-by: Yulin Lu <luyulin@eswincomputing.com>
Signed-off-by: Huan He <hehuan1@eswincomputing.com>
---
.../bindings/hwmon/eswin,eic7700-pvt.yaml | 72 +++++++++++++++++++
1 file changed, 72 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/eswin,eic7700-pvt.yaml
diff --git a/Documentation/devicetree/bindings/hwmon/eswin,eic7700-pvt.yaml b/Documentation/devicetree/bindings/hwmon/eswin,eic7700-pvt.yaml
new file mode 100644
index 000000000000..58ec8635dce3
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/eswin,eic7700-pvt.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/eswin,eic7700-pvt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ESWIN EIC7700 PVT Sensor
+
+maintainers:
+ - Yulin Lu <luyulin@eswincomputing.com>
+ - Huan He <hehuan1@eswincomputing.com>
+
+description:
+ ESWIN EIC7700 SoC integrates embedded voltage and temperature sensors to
+ monitor the internal SoC environment. The system includes two PVT sensor
+ instances. The PVT0 monitors the main SoC power domain. The PVT1 sensor
+ monitors the DDR core power domain.
+
+allOf:
+ - $ref: /schemas/hwmon/hwmon-common.yaml#
+
+properties:
+ compatible:
+ const: eswin,eic7700-pvt
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: PVT enable clock
+ - description: APB bus clock
+
+ clock-names:
+ items:
+ - const: enable
+ - const: apb
+
+ interrupts:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ '#thermal-sensor-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - resets
+ - '#thermal-sensor-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ sensor@50b00000 {
+ compatible = "eswin,eic7700-pvt";
+ reg = <0x50b00000 0x10000>;
+ clocks = <&clocks 244>, <&clocks 234>;
+ clock-names = "enable", "apb";
+ interrupts = <349>;
+ interrupt-parent = <&plic>;
+ label = "pvt0";
+ resets = <&reset 111>;
+ #thermal-sensor-cells = <0>;
+ };
+...
--
2.34.1
^ permalink raw reply related
* [PATCH v8 0/2] Add driver support for ESWIN EIC7700 PVT controller
From: hehuan1 @ 2026-06-25 6:10 UTC (permalink / raw)
To: linux, robh, krzk+dt, conor+dt, p.zabel, linux-hwmon, devicetree,
linux-kernel
Cc: ningyu, linmin, pinkesh.vaghela, luyulin, dongxuyang, Huan He
From: Huan He <hehuan1@eswincomputing.com>
Add support for the ESWIN EIC7700 PVT (Voltage, Temperature) sensor
Features:
The driver supports monitoring of voltage and temperature parameters
through the hardware monitoring subsystem. It provides an access to the
sampled Temperature and Voltage.
Test:
Tested this patch on the SiFive HiFive Premier P550 (which uses the ESWIN
EIC7700 SoC).
Updates:
Changes in v8:
- Update eswin,eic7700-pvt.yaml
- Delete reviewed-by tag of Krzysztof Kozlowski due to functional
changes. Add the APB clock because when the kernel is booted with
CMDLINE option "clk_ignore_unused", the APB clock remains enabled by
default; without this option, the APB clock may be gated and the PVT
driver will not operate correctly
- Update eic7700-pvt.c and eic7700-pvt.h
- Add APB clock support and retrieve clocks using devm_clk_bulk_get()
- Update eic7700_pvt_hard_isr() to verify PVT_INT_STAT before clearing
the interrupt and completing a conversion, preventing spurious
interrupts from returning stale data or completing a conversion early
- Update eic7700_pvt_probe() to register the PM runtime cleanup action
before requesting the IRQ, so the IRQ is torn down before clocks are
disabled during driver removal, preventing a possible
use-after-disable of the hardware clock in the ISR
Changes in v7:
- Remove the unused reset control pointer from struct pvt_hwmon and keep
the reset control handle local to eic7700_pvt_probe()
- Update eic7700_pvt_init_iface() to disable PVT_ENA_EN before clearing
the interrupt status, preventing a possible level-triggered interrupt
storm if the bootloader leaves the conversion engine running
- Update eic7700_pvt_disable_pm_runtime() to explicitly disable runtime
PM and avoid an unbalanced disable_depth
Changes in v6:
- Fix the !CONFIG_PM probe error path by disabling the clock if IRQ
request fails before the PM cleanup action is registered
- Replace pm_runtime_put_noidle() with pm_runtime_put() in the IRQ
handler to avoid a runtime PM reference-count race with the read path
- Remove the unused pvt_clear_data() devres action and its associated
devm_add_action() registration
Changes in v5:
- Update eswin,eic7700-pvt.yaml
- Drop the label enum constraint and remove label from the required
list
- Add '#thermal-sensor-cells' to the required list
- Rename the example node to the generic sensor@... form
- Update the binding description to describe one temperature sensor
and one voltage sensor
- Update eic7700-pvt.c
- Register the hwmon device with the fixed name "pvt"
- Remove label-based instance identification from the driver
- Fix CONFIG_PM=n support by keeping the clock enabled when runtime PM
is unavailable
- Add pm_runtime_force_suspend() in the cleanup path to avoid leaving
the device active during unbind
- Switch system sleep callbacks to pm_runtime_force_suspend() and
pm_runtime_force_resume()
- Guard ISR register accesses with pm_runtime_get_if_active()
- Add synchronize_irq() on the timeout path to avoid stale completion
races
- Remove temp_offset support because the raw trim register does not
match the hwmon ABI
- Align the commit message with the implementation (one temperature
sensor, one voltage sensor)
Changes in v4:
- Update eswin,eic7700-pvt.yaml
- Delete reviewed-by tag of Conor Dooley, because the label enum
constraint is introduced
- Update eic7700-pvt.c and eic7700-pvt.h
- Remove the unused LVT/ULVT/SVT process-monitoring channels
- Remove the probe-time power check since the PVT block is always
powered on EIC7700 and the extra verification is unnecessary
- Stop requesting the interrupt as shared and use the dedicated PVT IRQ
only
- Reorder probe initialization so the interface is initialized before
the clock is disabled, avoiding register accesses with the clock gated
- Fix runtime PM reference handling on error paths by balancing
pm_runtime_get_noresume() with pm_runtime_put_noidle()
- Add pm_runtime_put_noidle() handling for failed pm_runtime_get_sync()
calls in hwmon read/write paths
- Switch the PM callback registration from pm_sleep_ptr() to pm_ptr()
Changes in v3:
- Update eswin,eic7700-pvt.yaml
- Remove redundant label property description and use 'label: true' to
reference the definition in hwmon-common.yaml
- Replace 'additionalProperties: false' with
'unevaluatedProperties: false'
- Remove the description for '#thermal-sensor-cells'
- Update eic7700-pvt.c and eic7700-pvt.h
- Fix clock reference count imbalance with Runtime PM:
Replace devm_clk_get_enabled() with devm_clk_get() and manually
manage clock enable/disable to avoid double-disable in remove() when
Runtime PM is active. Clock is now enabled only during probe for
eic7700_pvt_check_pwr(), then disabled before enabling Runtime PM,
which takes full control of the clock thereafter
- Add detailed comment explaining the spurious interrupt risk in
eic7700_pvt_check_pwr()
- Replace wait_for_completion_interruptible() with
wait_for_completion_timeout() to prevent infinite wait
Changes in v2:
- Update eswin,eic7700-pvt.yaml
- Reference the hwmon-common.yaml file
- Remove the clock-names and reset-names properties
- Move additionalProperties: false after the required block
- Remove one example node to avoid redundancy
- Update eic7700-pvt.c and eic7700-pvt.h
- Remove unused sensor macros (PVT_SENSOR_FIRST, PVT_SENSOR_LAST,
PVT_SENSORS_NUM)
- Drop the unnecessary hwmon-sysfs.h header
- Replace dynamic sensor info allocation with a static array and unify
sensor labels
- Remove unused hwmon_temp_type attribute
- Eliminate redundant validation checks
- Remove mutex and related locking, relying on hwmon core
serialization
- Replace per-sensor caches and completions with a single data cache
and completion object
- Remove pvt->sensor tracking. ISR no longer depends on the currently
selected sensor
- Move devm_add_action() registration after init_completion() for
safer cleanup, and update cleanup function (pvt_clear_data)
- Replace devm_reset_control_get_optional_exclusive() with
devm_reset_control_get_exclusive_deasserted()
- Replace eic7700_pvt_remove() with eic7700_pvt_disable_pm_runtime()
and move it after PM runtime enable to avoid resource leaks on probe
failure and remove clock disable and reset assert from
eic7700_pvt_disable_pm_runtime() as it is already handled by devm_*
framework
- Remove redundant clock presence check in runtime_resume
- Link to v1: https://lore.kernel.org/all/20260109090718.442-1-hehuan1@eswincomputing.com/
Huan He (2):
dt-bindings: hwmon: Add Eswin EIC7700 PVT sensor
hwmon: Add Eswin EIC7700 PVT sensor driver
.../bindings/hwmon/eswin,eic7700-pvt.yaml | 72 +++
drivers/hwmon/Kconfig | 12 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/eic7700-pvt.c | 507 ++++++++++++++++++
drivers/hwmon/eic7700-pvt.h | 99 ++++
5 files changed, 691 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/eswin,eic7700-pvt.yaml
create mode 100644 drivers/hwmon/eic7700-pvt.c
create mode 100644 drivers/hwmon/eic7700-pvt.h
--
2.34.1
^ permalink raw reply
* [PATCH v2] spi: dt-bindings: microchip,pic32mzda-sqi: Convert to DT schema
From: Udaya Kiran Challa @ 2026-06-25 6:09 UTC (permalink / raw)
To: tsbogend, robh, krzk+dt, conor+dt
Cc: skhan, me, linux-spi, devicetree, linux-kernel,
Udaya Kiran Challa
Convert Microchip PIC32 Quad SPI controller devicetree binding
from legacy text format to DT schema.
Signed-off-by: Udaya Kiran Challa <challauday369@gmail.com>
---
Changelog:
Changes since v1:
- Drop maxItems and add items list in 'clocks' property
- Remove unsed label from example node
---
.../bindings/spi/microchip,pic32mzda-sqi.yaml | 55 +++++++++++++++++++
.../devicetree/bindings/spi/sqi-pic32.txt | 18 ------
2 files changed, 55 insertions(+), 18 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/microchip,pic32mzda-sqi.yaml
delete mode 100644 Documentation/devicetree/bindings/spi/sqi-pic32.txt
diff --git a/Documentation/devicetree/bindings/spi/microchip,pic32mzda-sqi.yaml b/Documentation/devicetree/bindings/spi/microchip,pic32mzda-sqi.yaml
new file mode 100644
index 000000000000..c8f58c506087
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/microchip,pic32mzda-sqi.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/microchip,pic32mzda-sqi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PIC32MZDA Quad SPI controller
+
+maintainers:
+ - Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+properties:
+ compatible:
+ const: microchip,pic32mzda-sqi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: SPI source clock
+ - description: SQI register interface clock
+
+ clock-names:
+ items:
+ - const: spi_ck
+ - const: reg_ck
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/microchip,pic32-clock.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ spi@1f8e2000 {
+ compatible = "microchip,pic32mzda-sqi";
+ reg = <0x1f8e2000 0x200>;
+ interrupts = <169 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&rootclk REF2CLK>, <&rootclk PB5CLK>;
+ clock-names = "spi_ck", "reg_ck";
+ };
diff --git a/Documentation/devicetree/bindings/spi/sqi-pic32.txt b/Documentation/devicetree/bindings/spi/sqi-pic32.txt
deleted file mode 100644
index c82d021bce50..000000000000
--- a/Documentation/devicetree/bindings/spi/sqi-pic32.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Microchip PIC32 Quad SPI controller
------------------------------------
-Required properties:
-- compatible: Should be "microchip,pic32mzda-sqi".
-- reg: Address and length of SQI controller register space.
-- interrupts: Should contain SQI interrupt.
-- clocks: Should contain phandle of two clocks in sequence, one that drives
- clock on SPI bus and other that drives SQI controller.
-- clock-names: Should be "spi_ck" and "reg_ck" in order.
-
-Example:
- sqi1: spi@1f8e2000 {
- compatible = "microchip,pic32mzda-sqi";
- reg = <0x1f8e2000 0x200>;
- clocks = <&rootclk REF2CLK>, <&rootclk PB5CLK>;
- clock-names = "spi_ck", "reg_ck";
- interrupts = <169 IRQ_TYPE_LEVEL_HIGH>;
- };
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 03/12] iio: adc: at91-sama5d2_adc: adapt the driver for sama7d65
From: Varshini.Rajendran @ 2026-06-25 5:53 UTC (permalink / raw)
To: andriy.shevchenko
Cc: ehristev, jic23, dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt,
Nicolas.Ferre, alexandre.belloni, claudiu.beznea, srini,
linux-iio, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <ajrO3-buCfS0vx1L@ashevche-desk.local>
Hi Andy,
On 23/06/26 11:52 pm, Andy Shevchenko wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On Tue, Jun 23, 2026 at 04:29:35PM +0530, Varshini Rajendran wrote:
>> Add support for sama7d65 ADC. The differences are highlighted with the
>> compatible. The calibration data layout is the main difference.
>
> Do you need to update a Kconfig help text?
Yes. I will update the supported SoC specifics in the Kconfig help text.
I will also address the rest of your review comments in the v3 patchset.
Thanks for your time.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
--
Thanks,
Varshini Rajendran.
^ permalink raw reply
* [PATCH] arm64: dts: imx8mp-ab2: Enable MU2 for DSP communication
From: shengjiu.wang @ 2026-06-25 5:47 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
devicetree, imx, linux-arm-kernel, linux-kernel
From: Shengjiu Wang <shengjiu.wang@nxp.com>
Enable the MU2 (Message Unit 2) node on the i.MX8MP Audio Board v2.
MU2 is required for inter-processor communication between the
application CPU and the HiFi4 DSP, allowing DSP firmware to exchange
control and status messages with the Linux host.
Without this change, the DSP driver cannot establish the message
channel and DSP audio processing is non-functional.
Fixes: bf68c18150efc ("arm64: dts: imx8mp-ab2: add support for NXP i.MX8MP audio board (version 2)")
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mp-ab2.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-ab2.dts b/arch/arm64/boot/dts/freescale/imx8mp-ab2.dts
index 443e4fd5b9bf..285bf79864eb 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-ab2.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-ab2.dts
@@ -775,6 +775,10 @@ &micfil {
status = "okay";
};
+&mu2 {
+ status = "okay";
+};
+
&pwm1 {
pinctrl-0 = <&pinctrl_pwm1>;
pinctrl-names = "default";
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v8 0/2] Add Meta(Facebook) ventura2 BMC(AST2600)
From: Kyle Hsieh @ 2026-06-25 5:35 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260615-ventura2_initial_dts-v8-0-c89f92c80447@gmail.com>
Hi Maintainers,
Just a gentle ping on this v8 series.
All review comments from the previous versions have been addressed.
Please let me know if there is anything else needed for this to be
applied.
Thanks,
Kyle
On Mon, Jun 15, 2026 at 10:44 AM Kyle Hsieh <kylehsieh1995@gmail.com> wrote:
>
> Summary:
> Add linux device tree entry related to Meta(Facebook) ventura2.
> specific devices connected to BMC(AST2600) SoC.
>
> Signed-off-by: Kyle Hsieh <kylehsieh1995@gmail.com>
> ---
> Changes in v8:
> - Addressed review comments from Andrew Lunn:
> * Added a detailed comment to the Marvell 88E6393X EEPROM node to clarify its hardware I2C multiplexer isolation and out-of-band firmware update mechanism, explaining why there is no concurrent access or multi-master scenario.
> - Link to v7: https://lore.kernel.org/r/20260611-ventura2_initial_dts-v7-0-a61d8902bc5f@gmail.com
>
> Changes in v7:
> - Updated the commit message to include a detailed description of the Ventura2 platform's purpose and its key hardware features.
> - Fix comments from Andrew Jeffery:
> * Ensured consistent blank lines to separate child nodes from parent properties and from each other throughout the DTS.
> * Sorted fan nodes in ascending order.
> * Replaced '//' comments with '/* */' block comments.
> - Fix feedback from Sashiko AI:
> * Added 'idle-state = <6>;' to the PCA9548 mux on i2c4.
> - Link to v6: https://lore.kernel.org/r/20260610-ventura2_initial_dts-v6-0-375d8e9d7ebf@gmail.com
>
> Changes in v6:
> - Addressed automated feedback from Sashiko bot:
> * Clarified comments that io_expander0 and io_expander8 physically share the same interrupt line (Wired-OR) by hardware design.
> * Removed leading zeros from unit addresses in DAC nodes (dac@c, dac@e, dac@f).
> * Removed unused properties from the adc@48 node.
> - Link to v5: https://lore.kernel.org/r/20260608-ventura2_initial_dts-v5-0-37ee5bcf58b6@gmail.com
>
> Changes in v5:
> - Addressed review comments:
> * Added comments explaining the necessity of 'legacy_' prefixes (hardware label collision), pre-allocated I2C aliases (future expansions), and the 'ledd1' naming convention (schematic alignment).
> * Removed the empty `&mdio0` node to comply with upstream networking subsystem guidelines.
> * Removed the redundant `&peci0` node.
> * Sorted `&kcs3` and `&lpc_ctrl` nodes in strict alphabetical order.
> - Hardware/DT alignment updates:
> * Removed unpopulated sensors (adi,adt7461, infineon,tda38640, ti,ina230, ti,ina238) to accurately reflect the current board population.
> * Added the secondary flash node (flash@1 labeled "e810") under the &spi2 bus.
> - Link to v4: https://lore.kernel.org/r/20260424-ventura2_initial_dts-v4-0-806b00ea4314@gmail.com
>
> Changes in v4:
> - Fixed capitalization: "ventura2" -> "Ventura2".
> - Reordered I2C child nodes in ascending order of unit addresses.
> - Enable PECI, LPC control, and KCS3 interfaces for host communication.
> - Configure MCTP controller on I2C4 and enable MCTP support for specific mux channels.
> - Add Infineon TDA38640 and TI INA230 power monitor nodes.
> - GPIO and Pinmux cleanup for PVT:
> - Aligned gpio-line-names as requested.
> - Remove unused or non-existent GPIO line names to align with Ventura2 PVT.
> - Update specific GPIO pins to empty strings where signals were removed or consolidated.
> - Adjust SGPIOM frequency to 200kHz and update signal line names.
> - Enable UART3 and add serial2 alias.
> - Link to v3: https://lore.kernel.org/r/20260113-ventura2_initial_dts-v3-0-2dbfda6a5b47@gmail.com
>
> Changes in v3:
> - Add annotation for marvel 88e6393x
> - Modify the gpio-line-name
> - Modify the node order alphabetically
> - Modify dt-bindings document for rmc instead of bmc
> - Move the gpio-line-names to original node
> - Link to v2: https://lore.kernel.org/r/20251224-ventura2_initial_dts-v2-0-f193ba5d4073@gmail.com
>
> Changes in v2:
> - Remove unused mdio
> - Link to v1: https://lore.kernel.org/r/20251222-ventura2_initial_dts-v1-0-1f06166c78a3@gmail.com
>
> ---
> Kyle Hsieh (2):
> dt-bindings: arm: aspeed: add Meta ventura2 board
> ARM: dts: aspeed: ventura2: Add Meta ventura2 BMC
>
> .../devicetree/bindings/arm/aspeed/aspeed.yaml | 1 +
> arch/arm/boot/dts/aspeed/Makefile | 1 +
> .../dts/aspeed/aspeed-bmc-facebook-ventura2.dts | 2903 ++++++++++++++++++++
> 3 files changed, 2905 insertions(+)
> ---
> base-commit: 9448598b22c50c8a5bb77a9103e2d49f134c9578
> change-id: 20251222-ventura2_initial_dts-909b3277d665
>
> Best regards,
> --
> Kyle Hsieh <kylehsieh1995@gmail.com>
>
^ permalink raw reply
* Re: [PATCH RFC v7 0/9] firmware: arm_scmi: vendors: Qualcomm Generic Vendor Extensions
From: Pragnesh Papaniya @ 2026-06-25 5:27 UTC (permalink / raw)
To: Sudeep Holla
Cc: Cristian Marussi, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sibi Sankar, MyungJoo Ham, Kyungmin Park, Chanwoo Choi,
Dmitry Osipenko, Thierry Reding, Jonathan Hunter, Bjorn Andersson,
Konrad Dybcio, Rajendra Nayak, Pankaj Patil, linux-arm-msm,
linux-kernel, arm-scmi, linux-arm-kernel, devicetree, linux-pm,
linux-tegra, Amir Vajid, Ramakrishna Gottimukkula
In-Reply-To: <20260623-busy-beautiful-trout-8cc2ea@sudeepholla>
On 23-Jun-26 2:17 PM, Sudeep Holla wrote:
> On Fri, Jun 19, 2026 at 06:01:23PM +0530, Pragnesh Papaniya wrote:
>>
>> On 16-Jun-26 1:57 PM, Sudeep Holla wrote:
>>
>>> Not sure if it was discussed in the previous versions or not, it would be
>>> good if you can capture why some of bus scaling doesn't work with the existing
>>> SCMI performance protocol and the monitors don't fit the MPAM mode.
>>>
>>> Please capture them in 1/9 as a motivation for this vendor protocol. It will
>>> then help to understand it better as I am still struggling to. Sorry for that.
>>
>> Thanks for the input!
>>
>> SCMI perf protocol exports perf domains to kernel where kernel can set
>> the frequency but here the scaling governor runs on the SCP while kernel
>> just observes frequency changes made by remote governor.
>
> OK if it is sort of read-only w.r.t kernel, why not perf domain notifications
> work to consume the change done by the SCMI platform.
>
> And why do you have set operations in the vendor protocol being proposed then.
> It all looks like something just cooked up to make things work. I need
> detailed reasoning as why the existing perf protocol can't work considering
> all the existing notifications in place.
Please do take another look at the documentation and driver changes to see
how it all comes together, since it's apparent that we use SET operation for
a ton of things. Taking another stab at explaining how the MEMLAT uses all
the ops exposed by the vendor protocol.
We use the SET operation to pass on various tuneables (IPM CEIL, stall floors,
write-back filter, freq-scale params, adaptive low/high freq, sample ms),
the core-freq -> mem-freq map, and min/max clamps) required to run the
MEMLAT algorithm on the SCP. You might ask why can't we have these values
stored somewhere on the SCP itself? We would like to but all of these are
tuneable values, that can change for various boards for the same SoC.
The START/STOP operations are meant to start/stop the algorithm, in this case
the bus scaling algorithm.
We use the GET operation to get the current frequency of memory that we
are trying to scale. It can be also used to read back all the parameters
that we are trying to set. Another thing to note is that exposing the current
frequency to the userspace was something that the community wanted.
With all of ^^ in mind, re-using the perf protocol becomes impossible.
https://lore.kernel.org/lkml/k4lpzxtrq3x6riyv6etxiobn7nbpczf2bp3m4oc752nhjknlit@uo53kbppzim7/
https://lore.kernel.org/lkml/20241115003809epcms1p518df149458f3023d33ec6d87a315e8f6@epcms1p5/
We'll add more call flow diagrams as part of the documentation for the next
re-spin to make reviews a bit more easier.
-Pragnesh
>
>> While MPAM is not enabled/supported on all hardware (Hamoa).
>
> Fair enough but I still don't fully understand to rule that out yet.
>
^ permalink raw reply
* Re: [PATCH v6 4/4] arm64: dts: freescale: Add dual-channel LVDS overlay for TQMa8MPxS
From: sashiko-bot @ 2026-06-25 5:27 UTC (permalink / raw)
To: Alexander Stein; +Cc: imx, Frank.Li, conor+dt, devicetree, robh, wsa+renesas
In-Reply-To: <20260625051449.2560197-4-alexander.stein@ew.tq-group.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The device tree overlay adds a 'ports' node to '&panel_lvds0' without deleting the existing 'port' node, causing a structural conflict and leaving an orphaned, one-way OF graph endpoint.
--
commit 8dc3732086b5dde9e7781747b60e7109f1ba68e8
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
arm64: dts: freescale: Add dual-channel LVDS overlay for TQMa8MPxS
This adds an overlay for the supported LVDS display AUO G133HAN01.
Configure the video PLL frequency to exactly match typical pixel clock of
141.200 MHz.
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso
> new file mode 100644
> index 0000000000000..2d2dfda944faa
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso
[ ... ]
> +&panel_lvds0 {
> + compatible = "auo,g133han01";
> + status = "okay";
> +
> + ports {
> + #address-cells = <1>;
[Severity: Low]
Does this overlay need to delete the existing port node from the base tree
before defining the ports node?
Without an explicit /delete-node/ port; command, both the port and ports
nodes will coexist in the merged device tree, which violates the mutual
exclusion rule in panel-common-dual.yaml.
Additionally, since the overlay re-defines the panel_in_lvds0 label to point
to the new ports/port@0/endpoint, the old port/endpoint is not deleted. It
will retain its remote-endpoint = <&ldb_lvds_ch0> property, creating a
one-way link that triggers dtc warnings for graph connections not being
bidirectional.
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625051449.2560197-1-alexander.stein@ew.tq-group.com?part=4
^ permalink raw reply
* Re: [PATCH v6 3/4] arm64: dts: freescale: add LVDS overlays for TQMa8MPxS
From: sashiko-bot @ 2026-06-25 5:26 UTC (permalink / raw)
To: Alexander Stein; +Cc: devicetree, robh, wsa+renesas, imx, Frank.Li, conor+dt
In-Reply-To: <20260625051449.2560197-3-alexander.stein@ew.tq-group.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The standalone `.dtbo` files are not added to `dtb-$(CONFIG_ARCH_MXC)`, preventing them from being installed by `make dtbs_install`.
--
commit 11ad35117d23241efb0a2ebb767e914a535c2a98
Author: Paul Gerber <paul.gerber@tq-group.com>
arm64: dts: freescale: add LVDS overlays for TQMa8MPxS
This commit adds device tree overlays for the Tianma tm070jvhg33 display
supported by the TQMa8MPxS on both LVDS channels. The display timings and
pixel clock are explicitly specified to achieve the correct LDB clock
frequency.
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index 7a1d8586ce7c8..f0779a5d3b737 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -379,6 +379,11 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtbo
> dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-lvds-tm070jvhg33.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-lvds-tm070jvhg33-imx219.dtb
>
> +imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33-dtbs += imx8mp-tqma8mpqs-mb-smarc-2.dtb imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtbo
> +imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33-dtbs += imx8mp-tqma8mpqs-mb-smarc-2.dtb imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtbo
> +dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtb
> +dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtb
[Severity: Medium]
Will this omit the standalone .dtbo files from being installed by
make dtbs_install?
The dtb-$(CONFIG_ARCH_MXC) target adds the statically merged composite .dtb
files, but it looks like the standalone .dtbo files are missing. Without
these, users wouldn't be able to apply the overlays dynamically via the
bootloader.
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625051449.2560197-1-alexander.stein@ew.tq-group.com?part=3
^ permalink raw reply
* [PATCH v6 1/4] dt-bindings: arm: fsl: add TQMa8MPxS board
From: Alexander Stein @ 2026-06-25 5:14 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Shawn Guo
Cc: Paul Gerber, devicetree, linux-kernel, imx, linux-arm-kernel,
linux, linux-renesas-soc, Alexander Stein, Conor Dooley
From: Paul Gerber <paul.gerber@tq-group.com>
TQMa8MPxS is a SOM family using NXP i.MX8MP CPU family.
MB-SMARC-2 is an evaluation mainbord for this SOM
The SOM needs a mainboard, therefore we provide two compatibles here:
"tq,imx8mp-<SOM>" for the module and
"tq,imx8mp-<SOM>-<SBC>"
Signed-off-by: Paul Gerber <paul.gerber@tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
Changes in v6:
* None
Documentation/devicetree/bindings/arm/fsl.yaml | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 86876311ec59a..6237fb2ae50e6 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1310,6 +1310,18 @@ properties:
- const: tq,imx8mp-tqma8mpql # TQ-Systems GmbH i.MX8MP TQMa8MPQL SOM
- const: fsl,imx8mp
+ - description:
+ TQMa8MPxS is a series of SOM featuring NXP i.MX8MP system-on-chip
+ variants. It has the SMARC-2.0 form factor and is designed to be
+ placed on different carrier boards. All CPU variants use the same
+ device tree hence only one compatible is needed. MB-SMARC-2 is a
+ carrier reference design.
+ items:
+ - enum:
+ - tq,imx8mp-tqma8mpqs-mb-smarc-2 # TQ-Systems GmbH i.MX8MP TQMa8MPQS SOM on MB-SMARC-2
+ - const: tq,imx8mp-tqma8mpqs # TQ-Systems GmbH i.MX8MP TQMa8MPQS SOM
+ - const: fsl,imx8mp
+
- description: Variscite VAR-SOM-MX8M Plus based boards
items:
- const: variscite,var-som-mx8mp-symphony
--
2.54.0
^ permalink raw reply related
* [PATCH v6 2/4] arm64: dts: freescale: add initial device tree for TQMa8MPQS with i.MX8MP
From: Alexander Stein @ 2026-06-25 5:14 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Shawn Guo
Cc: Paul Gerber, devicetree, linux-kernel, imx, linux-arm-kernel,
linux, linux-renesas-soc, Alexander Stein
In-Reply-To: <20260625051449.2560197-1-alexander.stein@ew.tq-group.com>
From: Paul Gerber <paul.gerber@tq-group.com>
This adds support for TQMa8MPQS module on MB-SMARC-2 board.
Signed-off-by: Paul Gerber <paul.gerber@tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
Changes in v6:
* Add interrupt to DSI-DP bridge
* Adjust AUDIO_PLL2 clock rate
The eMMC/SD card properties regarding higher speeds, as mentioned by
Sashiko bot, is not necessary for i.MX platforms as the capability bits
privde the correct information already.
The platform already runs at "mmc HS400 enhanced strobe" and
"sd uhs SDR104" (taken from /sys/kernel/debug/mmc*/ios)
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../freescale/imx8mp-tqma8mpqs-mb-smarc-2.dts | 380 ++++++
.../boot/dts/freescale/imx8mp-tqma8mpqs.dtsi | 1178 +++++++++++++++++
3 files changed, 1559 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs.dtsi
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 43e1dc51b11d7..acb73cde76f16 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -439,6 +439,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revc-jutouch-jt101tm023.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-toradex-smarc-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mpxl.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2.dtb
imx8mp-tx8p-ml81-moduline-display-106-av101hdt-a10-dtbs += imx8mp-tx8p-ml81-moduline-display-106.dtb \
imx8mp-tx8p-ml81-moduline-display-106-av101hdt-a10.dtbo
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2.dts b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2.dts
new file mode 100644
index 0000000000000..f01af630a7c4a
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2.dts
@@ -0,0 +1,380 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright 2025-2026 TQ-Systems GmbH <linux@ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Paul Gerber
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/leds/common.h>
+#include "imx8mp-tqma8mpqs.dtsi"
+
+/ {
+ model = "TQ-Systems i.MX8MPlus TQMa8MPxS on MB-SMARC-2";
+ compatible = "tq,imx8mp-tqma8mpqs-mb-smarc-2", "tq,imx8mp-tqma8mpqs", "fsl,imx8mp";
+ chassis-type = "embedded";
+
+ chosen {
+ stdout-path = &uart3;
+ };
+
+ aliases {
+ ethernet0 = &eqos;
+ ethernet1 = &fec;
+ mmc0 = &usdhc3;
+ mmc1 = &usdhc2;
+ rtc0 = &pcf85063;
+ rtc1 = &snvs_rtc;
+ spi0 = &flexspi;
+ spi1 = &ecspi1;
+ spi2 = &ecspi2;
+ spi3 = &ecspi3;
+ };
+
+ backlight_lvds0: backlight-lvds0 {
+ compatible = "pwm-backlight";
+ pwms = <&pwm3 0 100000 0>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <7>;
+ enable-gpios = <&expander0 0 GPIO_ACTIVE_HIGH>;
+ power-supply = <®_12v0>;
+ status = "disabled";
+ };
+
+ backlight_lvds1: backlight-lvds1 {
+ compatible = "pwm-backlight";
+ pwms = <&pwm2 0 100000 0>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <7>;
+ enable-gpios = <&expander0 2 GPIO_ACTIVE_HIGH>;
+ power-supply = <®_12v0>;
+ status = "disabled";
+ };
+
+ hdmi-connector {
+ compatible = "hdmi-connector";
+ label = "X6";
+ type = "a";
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&hdmi_tx_out>;
+ };
+ };
+ };
+
+ panel_lvds0: panel-lvds0 {
+ /*
+ * Display is not fixed, so compatible has to be added from
+ * DT overlay
+ */
+ backlight = <&backlight_lvds0>;
+ power-supply = <®_lvds0>;
+ status = "disabled";
+
+ port {
+ panel_in_lvds0: endpoint {
+ remote-endpoint = <&ldb_lvds_ch0>;
+ };
+ };
+ };
+
+ panel_lvds1: panel-lvds1 {
+ /*
+ * Display is not fixed, so compatible has to be added from
+ * DT overlay
+ */
+ backlight = <&backlight_lvds1>;
+ power-supply = <®_lvds1>;
+ status = "disabled";
+
+ port {
+ panel_in_lvds1: endpoint {
+ remote-endpoint = <&ldb_lvds_ch1>;
+ };
+ };
+ };
+
+ reg_1v8: regulator-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ reg_12v0: regulator-12v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "12V0";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ regulator-always-on;
+ };
+
+ reg_lvds0: regulator-lvds0 {
+ compatible = "regulator-fixed";
+ regulator-name = "LCD0_VDD_EN";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&expander0 1 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_lvds1: regulator-lvds1 {
+ compatible = "regulator-fixed";
+ regulator-name = "LCD1_VDD_EN";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&expander0 3 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* global autoconfigured region for contiguous allocations */
+ linux,cma {
+ compatible = "shared-dma-pool";
+ reusable;
+ size = <0 0x38000000>;
+ alloc-ranges = <0 0x40000000 0 0x78000000>;
+ linux,cma-default;
+ };
+ };
+
+ sound {
+ compatible = "fsl,imx-audio-tlv320aic32x4";
+ model = "tqm-tlv320aic32";
+ audio-asrc = <&easrc>;
+ audio-cpu = <&sai5>;
+ audio-codec = <&tlv320aic3x04>;
+ audio-routing =
+ "IN3_L", "Mic Jack",
+ "Mic Jack", "Mic Bias",
+ "IN1_L", "Line In Jack",
+ "IN1_R", "Line In Jack",
+ "Line Out Jack", "LOL",
+ "Line Out Jack", "LOR";
+ };
+
+ usb-connector {
+ compatible = "gpio-usb-b-connector", "usb-b-connector";
+ type = "micro";
+ label = "X4";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbcon0>;
+ id-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
+
+ port {
+ usb_dr_connector: endpoint {
+ remote-endpoint = <&usb3_dwc>;
+ };
+ };
+ };
+};
+
+&easrc {
+ status = "okay";
+};
+
+&ecspi1 {
+ status = "okay";
+};
+
+&eqos {
+ status = "okay";
+};
+
+ðphy0 {
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <0>;
+ default-state = "keep";
+ };
+
+ led@2 {
+ reg = <2>;
+ color = <LED_COLOR_ID_AMBER>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <0>;
+ default-state = "keep";
+ };
+ };
+};
+
+ðphy3 {
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <0>;
+ default-state = "keep";
+ };
+
+ led@2 {
+ reg = <2>;
+ color = <LED_COLOR_ID_AMBER>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <0>;
+ default-state = "keep";
+ };
+ };
+};
+
+&fec {
+ status = "okay";
+};
+
+&flexcan1 {
+ xceiver-supply = <®_3v3>;
+ status = "okay";
+};
+
+&flexcan2 {
+ xceiver-supply = <®_3v3>;
+ status = "okay";
+};
+
+&hdmi_pvi {
+ status = "okay";
+};
+
+&hdmi_tx {
+ status = "okay";
+
+ ports {
+ port@1 {
+ hdmi_tx_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+};
+
+&hdmi_tx_phy {
+ status = "okay";
+};
+
+&i2c1 {
+ tlv320aic3x04: audio-codec@18 {
+ compatible = "ti,tlv320aic32x4";
+ reg = <0x18>;
+ clock-names = "mclk";
+ clocks = <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI5_MCLK1>;
+ iov-supply = <®_1v8>;
+ ldoin-supply = <®_3v3>;
+ assigned-clocks = <&clk IMX8MP_CLK_SAI5>;
+ assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>;
+ assigned-clock-rates = <12288000>;
+ };
+
+ eeprom2: eeprom@57 {
+ compatible = "atmel,24c32";
+ reg = <0x57>;
+ pagesize = <32>;
+ vcc-supply = <®_3v3>;
+ };
+};
+
+&ldb_lvds_ch0 {
+ remote-endpoint = <&panel_in_lvds0>;
+};
+
+&ldb_lvds_ch1 {
+ remote-endpoint = <&panel_in_lvds1>;
+};
+
+&lcdif1 {
+ status = "okay";
+};
+
+&lcdif3 {
+ status = "okay";
+};
+
+&pcie_phy {
+ fsl,clkreq-unsupported;
+ status = "okay";
+};
+
+&pcie {
+ status = "okay";
+};
+
+®_usdhc2_vmmc {
+ startup-delay-us = <100>;
+ off-on-delay-us = <200000>;
+ status = "okay";
+};
+
+®_usdhc2_vqmmc {
+ status = "okay";
+};
+
+&sai3 {
+ status = "okay";
+};
+
+&sai5 {
+ status = "okay";
+};
+
+&snvs_pwrkey {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&uart4 {
+ status = "okay";
+};
+
+&usb3_0 {
+ status = "okay";
+};
+
+&usb_dwc3_0 {
+ status = "okay";
+
+ port {
+ usb3_dwc: endpoint {
+ remote-endpoint = <&usb_dr_connector>;
+ };
+ };
+};
+
+&usdhc2 {
+ cd-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
+ wp-gpios = <&gpio2 20 GPIO_ACTIVE_HIGH>;
+ vmmc-supply = <®_usdhc2_vmmc>;
+ no-mmc;
+ no-sdio;
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs.dtsi
new file mode 100644
index 0000000000000..20d55eeead576
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs.dtsi
@@ -0,0 +1,1178 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright 2025-2026 TQ-Systems GmbH <linux@ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Paul Gerber
+ */
+
+#include <dt-bindings/net/ti-dp83867.h>
+#include <dt-bindings/phy/phy-imx8-pcie.h>
+#include "imx8mp.dtsi"
+
+/ {
+ model = "TQ-Systems i.MX8MPlus TQMa8MPxS";
+ compatible = "tq,imx8mp-tqma8mpqs", "fsl,imx8mp";
+
+ clk_dp: clk-dp {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <26000000>;
+ };
+
+ clk_xtal25: clk-xtal25 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ };
+
+ memory@40000000 {
+ device_type = "memory";
+ reg = <0x0 0x40000000 0 0x80000000>;
+ };
+
+ reg_5v0: regulator-5v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_5V0";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ reg_usdhc2_vmmc: regulator-usdhc2-vmmc {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
+ regulator-name = "SDIO_PWR_EN";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio2 19 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ status = "disabled";
+ };
+
+ reg_usdhc2_vqmmc: regulator-usdhc2-vqmmc {
+ compatible = "regulator-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_usdhc2_vqmmc>;
+ regulator-name = "V_SD";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
+ states = <1800000 0x1>,
+ <3300000 0x0>;
+ vin-supply = <&ldo5>;
+ status = "disabled";
+ };
+};
+
+&A53_0 {
+ cpu-supply = <&buck2>;
+};
+
+&audio_blk_ctrl {
+ assigned-clocks = <&clk IMX8MP_AUDIO_PLL1>,
+ <&clk IMX8MP_AUDIO_PLL2>;
+ assigned-clock-rates = <393216000>, <147333333>;
+};
+
+&ecspi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi1>;
+ cs-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>, <&gpio5 12 GPIO_ACTIVE_LOW>;
+};
+
+/* GBE0 */
+&eqos {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_eqos>;
+ phy-mode = "rgmii-id";
+ phy-handle = <ðphy0>;
+ snps,force_thresh_dma_mode;
+ snps,mtl-tx-config = <&mtl_tx_setup>;
+ snps,mtl-rx-config = <&mtl_rx_setup>;
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_eqos_phy>;
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
+ ti,dp83867-rxctrl-strap-quirk;
+ ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
+ reset-gpios = <&expander0 6 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <500000>;
+ reset-deassert-us = <50000>;
+ enet-phy-lane-no-swap;
+ interrupt-parent = <&gpio2>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ ethphy3: ethernet-phy@3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec_phy>;
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <3>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
+ ti,dp83867-rxctrl-strap-quirk;
+ ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
+ reset-gpios = <&expander0 7 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <500000>;
+ reset-deassert-us = <50000>;
+ enet-phy-lane-no-swap;
+ interrupt-parent = <&gpio2>;
+ interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
+ };
+ };
+
+ mtl_tx_setup: tx-queues-config {
+ snps,tx-queues-to-use = <5>;
+
+ queue0 {
+ snps,dcb-algorithm;
+ snps,priority = <0x1>;
+ };
+
+ queue1 {
+ snps,dcb-algorithm;
+ snps,priority = <0x2>;
+ };
+
+ queue2 {
+ snps,dcb-algorithm;
+ snps,priority = <0x4>;
+ };
+
+ queue3 {
+ snps,dcb-algorithm;
+ snps,priority = <0x8>;
+ };
+
+ queue4 {
+ snps,dcb-algorithm;
+ snps,priority = <0xf0>;
+ };
+ };
+
+ mtl_rx_setup: rx-queues-config {
+ snps,rx-queues-to-use = <5>;
+ snps,rx-sched-sp;
+
+ queue0 {
+ snps,dcb-algorithm;
+ snps,priority = <0x1>;
+ snps,map-to-dma-channel = <0>;
+ };
+
+ queue1 {
+ snps,dcb-algorithm;
+ snps,priority = <0x2>;
+ snps,map-to-dma-channel = <1>;
+ };
+
+ queue2 {
+ snps,dcb-algorithm;
+ snps,priority = <0x4>;
+ snps,map-to-dma-channel = <2>;
+ };
+
+ queue3 {
+ snps,dcb-algorithm;
+ snps,priority = <0x8>;
+ snps,map-to-dma-channel = <3>;
+ };
+
+ queue4 {
+ snps,dcb-algorithm;
+ snps,priority = <0xf0>;
+ snps,map-to-dma-channel = <4>;
+ };
+ };
+};
+
+/* GBE1 */
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec>;
+ phy-mode = "rgmii-id";
+ phy-handle = <ðphy3>;
+ fsl,magic-packet;
+};
+
+&flexcan1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan1>;
+};
+
+&flexcan2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan2>;
+};
+
+&flexspi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexspi0>;
+ status = "okay";
+
+ flash0: flash@0 {
+ reg = <0>;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <66666666>;
+ spi-tx-bus-width = <4>;
+ spi-rx-bus-width = <4>;
+ vcc-supply = <&buck5>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+ };
+};
+
+&gpio1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio1>;
+
+ gpio-line-names = "SLEEP", "BATLOW#", "", "LID",
+ "", "GPIO10", "CHARGING#", "CHG_PRSNT#",
+ "PMIC_IRQ#", "ESPI_CS1_ALERT#", "USB1_OTG_ID", "USB2_OTG_ID",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "";
+
+ pmic_irq_hog: pmic-irq-hog {
+ gpio-hog;
+ gpios = <8 0>;
+ input;
+ line-name = "PMIC_IRQ#";
+ };
+};
+
+&gpio2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hoggpio2>;
+
+ gpio-line-names = "", "", "", "",
+ "", "", "", "",
+ "", "", "PERST#", "PEWAKE#",
+ "SDIO_CD#", "", "", "",
+ "", "", "", "SDIO_PWR_EN",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "";
+
+ enet0-int-hog {
+ gpio-hog;
+ gpios = <0 0>;
+ input;
+ line-name = "ENET0_INT#";
+ };
+
+ enet1-int-hog {
+ gpio-hog;
+ gpios = <1 0>;
+ input;
+ line-name = "ENET_INT#";
+ };
+
+ pewake-hog {
+ gpio-hog;
+ gpios = <11 0>;
+ input;
+ line-name = "PEWAKE#";
+ };
+};
+
+&gpio3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio3>;
+
+ gpio-line-names = "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "GPIO4",
+ "GPIO3", "", "", "",
+ "", "", "", "",
+ "TEMP_EVENT#", "", "", "";
+
+ temp-event-hog {
+ gpio-hog;
+ gpios = <28 0>;
+ input;
+ line-name = "TEMP_EVENT#";
+ };
+};
+
+&gpio4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio4>, <&pinctrl_sdp>, <&pinctrl_espi_rst>;
+
+ gpio-line-names = "RTC_INT#", "GPIO8", "", "",
+ "GPIO9", "ESPI_RST#", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "GBE0_SDP_DIR", "",
+ "GPIO7", "", "", "",
+ "", "GPIO0", "GPIO1", "",
+ "GPIO2", "GPIO6", "", "";
+
+ rtc-int-hog {
+ gpio-hog;
+ gpios = <0 0>;
+ input;
+ line-name = "RTC_INT#";
+ };
+
+ espi-reset-hog {
+ gpio-hog;
+ gpios = <5 0>;
+ output-high;
+ line-name = "ESPI_RST#";
+ };
+};
+
+&gpio5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio5>;
+
+ gpio-line-names = "", "", "", "",
+ "", "GPIO5", "", "",
+ "", "", "GPIO12", "GPIO11",
+ "", "GPIO13", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "";
+
+ dp-hpd-int-hog {
+ gpio-hog;
+ gpios = <21 0>;
+ input;
+ line-name = "DP_HPD_INT";
+ };
+};
+
+&hdmi_tx {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hdmi>;
+};
+
+&i2c1 {
+ clock-frequency = <384000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ pinctrl-1 = <&pinctrl_i2c1_gpio>;
+ scl-gpios = <&gpio5 14 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio5 15 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ eeprom0: eeprom@50 {
+ compatible = "atmel,24c64";
+ reg = <0x50>;
+ pagesize = <32>;
+ read-only;
+ vcc-supply = <&buck5>;
+ };
+
+ pcf85063: rtc@51 {
+ compatible = "nxp,pcf85063a";
+ reg = <0x51>;
+ quartz-load-femtofarads = <7000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pcf85063>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <0 IRQ_TYPE_EDGE_FALLING>;
+ };
+
+ eeprom1: eeprom@54 {
+ compatible = "atmel,24c64";
+ reg = <0x54>;
+ pagesize = <32>;
+ vcc-supply = <&buck5>;
+ };
+
+ /* protectable identification memory (part of M24C64-D @50) */
+ eeprom@58 {
+ compatible = "atmel,24c64d-wl";
+ reg = <0x58>;
+ size = <32>;
+ pagesize = <32>;
+ vcc-supply = <&buck5>;
+ };
+
+ /* protectable identification memory (part of M24C64-D @54) */
+ eeprom@5c {
+ compatible = "atmel,24c64d-wl";
+ reg = <0x5c>;
+ size = <32>;
+ pagesize = <32>;
+ vcc-supply = <&buck5>;
+ };
+
+ pcieclk: clock-generator@6a {
+ compatible = "renesas,9fgv0241";
+ reg = <0x6a>;
+ clocks = <&clk_xtal25>;
+ #clock-cells = <1>;
+ };
+
+ inertial-sensor@6b {
+ compatible = "st,ism330dhcx";
+ reg = <0x6b>;
+ vdd-supply = <&buck4>;
+ vddio-supply = <&buck4>;
+ };
+};
+
+&i2c2 {
+ clock-frequency = <384000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ pinctrl-1 = <&pinctrl_i2c2_gpio>;
+ scl-gpios = <&gpio5 16 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio5 17 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ pmic: pmic@25 {
+ reg = <0x25>;
+ compatible = "nxp,pca9450c";
+
+ /* PMIC PCA9450 PMIC_nINT GPIO1_IO08 */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pmic>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
+
+ regulators {
+ /* V_0V85_SOC: 0.85 .. 0.95 */
+ buck1: BUCK1 {
+ regulator-name = "BUCK1";
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <950000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ };
+
+ /* VDD_ARM */
+ buck2: BUCK2 {
+ regulator-name = "BUCK2";
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ nxp,dvs-run-voltage = <950000>;
+ nxp,dvs-standby-voltage = <850000>;
+ regulator-ramp-delay = <3125>;
+ };
+
+ /* VCC3V3 -> VMMC, ... must not be changed */
+ buck4: BUCK4 {
+ regulator-name = "BUCK4";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ /* V_1V8 -> VQMMC, SPI-NOR, ... must not be changed */
+ buck5: BUCK5 {
+ regulator-name = "BUCK5";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ /* V_1V1 -> RAM, ... must not be changed */
+ buck6: BUCK6 {
+ regulator-name = "BUCK6";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ /* V_1V8_SNVS */
+ ldo1: LDO1 {
+ regulator-name = "LDO1";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ /* V_1V8_ANA */
+ ldo3: LDO3 {
+ regulator-name = "LDO3";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ /* unused */
+ ldo4: LDO4 {
+ regulator-name = "LDO4";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ /* VCC SD IO - switched using SD2 VSELECT */
+ ldo5: LDO5 {
+ regulator-name = "LDO5";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+ };
+ };
+
+ tmp1075: temperature-sensor@4a {
+ compatible = "ti,tmp1075";
+ reg = <0x4a>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tmp1075>;
+ vs-supply = <&buck4>;
+ };
+
+ expander0: gpio@73 {
+ compatible = "nxp,pca9538";
+ reg = <0x73>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ vcc-supply = <&buck5>;
+ gpio-line-names = "LCD0_BKLT_EN", "LCD0_VDD_EN",
+ "LCD1_BKLT_EN", "LCD1_VDD_EN",
+ "DP_BRIDGE_EN", "HUB_RST#",
+ "ENET0_RESET#", "ENET1_RESET#";
+ };
+};
+
+&i2c3 {
+ clock-frequency = <384000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ pinctrl-1 = <&pinctrl_i2c3_gpio>;
+ scl-gpios = <&gpio5 18 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio5 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ dp_bridge: dp-bridge@f {
+ compatible = "toshiba,tc9595", "toshiba,tc358767";
+ reg = <0xf>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tc9595>;
+ clock-names = "ref";
+ clocks = <&clk_dp>;
+ reset-gpios = <&expander0 4 GPIO_ACTIVE_HIGH>;
+ toshiba,hpd-pin = <0>;
+ interrupts-extended = <&gpio5 21 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ dsi_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ data-lanes = <1 2 3 4>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ endpoint {
+ toshiba,pre-emphasis = /bits/ 8 <1 1>;
+ };
+ };
+ };
+ };
+};
+
+&i2c4 {
+ clock-frequency = <384000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c4>;
+ pinctrl-1 = <&pinctrl_i2c4_gpio>;
+ scl-gpios = <&gpio2 4 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 5 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+};
+
+&i2c6 {
+ clock-frequency = <384000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c6>;
+ pinctrl-1 = <&pinctrl_i2c6_gpio>;
+ scl-gpios = <&gpio2 2 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 3 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+};
+
+// Change parent clock of disp1 pixel clock to audio_pll2
+&media_blk_ctrl {
+ assigned-clocks = <&clk IMX8MP_CLK_MEDIA_AXI>,
+ <&clk IMX8MP_CLK_MEDIA_APB>,
+ <&clk IMX8MP_CLK_MEDIA_DISP1_PIX>,
+ <&clk IMX8MP_CLK_MEDIA_DISP2_PIX>,
+ <&clk IMX8MP_CLK_MEDIA_ISP>,
+ <&clk IMX8MP_VIDEO_PLL1>;
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL2_1000M>,
+ <&clk IMX8MP_SYS_PLL1_800M>,
+ <&clk IMX8MP_AUDIO_PLL2_OUT>,
+ <&clk IMX8MP_VIDEO_PLL1_OUT>,
+ <&clk IMX8MP_SYS_PLL2_500M>;
+};
+
+&mipi_dsi {
+ samsung,burst-clock-frequency = <1000000000>;
+ samsung,esc-clock-frequency = <10000000>;
+
+ ports {
+ port@1 {
+ reg = <1>;
+
+ dsi_out: endpoint {
+ remote-endpoint = <&dsi_in>;
+ data-lanes = <1 2 3 4>;
+ };
+ };
+ };
+};
+
+&pcie_phy {
+ fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
+ clock-names = "ref";
+ clocks = <&pcieclk 0>;
+};
+
+&pcie {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pcie>;
+ clocks = <&clk IMX8MP_CLK_HSIO_ROOT>,
+ <&clk IMX8MP_CLK_HSIO_AXI>,
+ <&clk IMX8MP_CLK_PCIE_ROOT>;
+ clock-names = "pcie", "pcie_bus", "pcie_aux";
+ reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;
+ assigned-clocks = <&clk IMX8MP_CLK_PCIE_AUX>;
+ assigned-clock-rates = <10000000>;
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL2_50M>;
+};
+
+&pwm2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm2>;
+};
+
+&pwm3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm3>;
+};
+
+&sai3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sai3>;
+ assigned-clocks = <&clk IMX8MP_CLK_SAI3>;
+ assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>;
+ assigned-clock-rates = <12288000>;
+};
+
+&sai5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sai5>;
+ assigned-clocks = <&clk IMX8MP_CLK_SAI5>;
+ assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>;
+ assigned-clock-rates = <12288000>;
+ fsl,sai-mclk-direction-output;
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ assigned-clocks = <&clk IMX8MP_CLK_UART1>;
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_80M>;
+ uart-has-rtscts;
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ assigned-clocks = <&clk IMX8MP_CLK_UART2>;
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_80M>;
+ uart-has-rtscts;
+};
+
+&uart3 {
+ /* console */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+ status = "okay";
+};
+
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>;
+ assigned-clocks = <&clk IMX8MP_CLK_UART4>;
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_80M>;
+};
+
+&usb3_phy0 {
+ vbus-supply = <®_5v0>;
+ status = "okay";
+};
+
+&usb3_phy1 {
+ vbus-supply = <®_5v0>;
+ status = "okay";
+};
+
+&usb3_0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb0>;
+ fsl,over-current-active-low;
+};
+
+&usb3_1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb1>;
+ fsl,over-current-active-low;
+ status = "okay";
+};
+
+&usb_dwc3_0 {
+ /* dual role is implemented, but not a full featured OTG */
+ hnp-disable;
+ srp-disable;
+ adp-disable;
+ dr_mode = "otg";
+ usb-role-switch;
+ role-switch-default-mode = "peripheral";
+ /* SMARC-2 USB0 interface only supports USB 2.0 signals */
+ maximum-speed = "high-speed";
+};
+
+&usb_dwc3_1 {
+ dr_mode = "host";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ hub_2_0: hub@1 {
+ compatible = "usb451,8142";
+ reg = <1>;
+ peer-hub = <&hub_3_0>;
+ reset-gpios = <&expander0 5 GPIO_ACTIVE_LOW>;
+ vdd-supply = <®_3v3>;
+ };
+
+ hub_3_0: hub@2 {
+ compatible = "usb451,8140";
+ reg = <2>;
+ peer-hub = <&hub_2_0>;
+ reset-gpios = <&expander0 5 GPIO_ACTIVE_LOW>;
+ vdd-supply = <®_3v3>;
+ };
+};
+
+&usdhc2 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+ bus-width = <4>;
+ vqmmc-supply = <®_usdhc2_vqmmc>;
+ /* NOTE: CD / WP and VMMC support depends on mainboard */
+};
+
+&usdhc3 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc3>;
+ pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
+ bus-width = <8>;
+ non-removable;
+ no-sdio;
+ no-sd;
+ vmmc-supply = <&buck4>;
+ vqmmc-supply = <&buck5>;
+ status = "okay";
+};
+
+&wdog1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ fsl,ext-reset-output;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_ecspi1: ecspi1grp {
+ fsl,pins = <MX8MP_IOMUXC_ECSPI1_MISO__ECSPI1_MISO 0x1c0>,
+ <MX8MP_IOMUXC_ECSPI1_MOSI__ECSPI1_MOSI 0x1c0>,
+ <MX8MP_IOMUXC_ECSPI1_SCLK__ECSPI1_SCLK 0x1c0>,
+ <MX8MP_IOMUXC_ECSPI1_SS0__GPIO5_IO09 0x1c0>,
+ <MX8MP_IOMUXC_ECSPI2_MISO__GPIO5_IO12 0x1c0>;
+ };
+
+ pinctrl_eqos: eqosgrp {
+ fsl,pins = <MX8MP_IOMUXC_ENET_MDC__ENET_QOS_MDC 0x40000044>,
+ <MX8MP_IOMUXC_ENET_MDIO__ENET_QOS_MDIO 0x40000044>,
+ <MX8MP_IOMUXC_ENET_RD0__ENET_QOS_RGMII_RD0 0x90>,
+ <MX8MP_IOMUXC_ENET_RD1__ENET_QOS_RGMII_RD1 0x90>,
+ <MX8MP_IOMUXC_ENET_RD2__ENET_QOS_RGMII_RD2 0x90>,
+ <MX8MP_IOMUXC_ENET_RD3__ENET_QOS_RGMII_RD3 0x90>,
+ <MX8MP_IOMUXC_ENET_RXC__CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK 0x90>,
+ <MX8MP_IOMUXC_ENET_RX_CTL__ENET_QOS_RGMII_RX_CTL 0x90>,
+ <MX8MP_IOMUXC_ENET_TD0__ENET_QOS_RGMII_TD0 0x12>,
+ <MX8MP_IOMUXC_ENET_TD1__ENET_QOS_RGMII_TD1 0x12>,
+ <MX8MP_IOMUXC_ENET_TD2__ENET_QOS_RGMII_TD2 0x12>,
+ <MX8MP_IOMUXC_ENET_TD3__ENET_QOS_RGMII_TD3 0x12>,
+ <MX8MP_IOMUXC_ENET_TX_CTL__ENET_QOS_RGMII_TX_CTL 0x12>,
+ <MX8MP_IOMUXC_ENET_TXC__CCM_ENET_QOS_CLOCK_GENERATE_TX_CLK 0x14>;
+ };
+
+ pinctrl_eqos_event: eqosevtgrp {
+ fsl,pins = <MX8MP_IOMUXC_SAI2_MCLK__ENET_QOS_1588_EVENT3_IN 0x100>,
+ <MX8MP_IOMUXC_SAI2_TXFS__ENET_QOS_1588_EVENT3_OUT 0x1c0>;
+ };
+
+ pinctrl_eqos_phy: eqosphygrp {
+ fsl,pins = <MX8MP_IOMUXC_SD1_CLK__GPIO2_IO00 0x1c0>;
+ };
+
+ pinctrl_espi_rst: espirstgrp {
+ fsl,pins = <MX8MP_IOMUXC_SAI1_RXD3__GPIO4_IO05 0x144>;
+ };
+
+ pinctrl_fec: fecgrp {
+ fsl,pins = <MX8MP_IOMUXC_SAI1_RXD4__ENET1_RGMII_RD0 0x90>,
+ <MX8MP_IOMUXC_SAI1_RXD5__ENET1_RGMII_RD1 0x90>,
+ <MX8MP_IOMUXC_SAI1_RXD6__ENET1_RGMII_RD2 0x90>,
+ <MX8MP_IOMUXC_SAI1_RXD7__ENET1_RGMII_RD3 0x90>,
+ <MX8MP_IOMUXC_SAI1_TXC__ENET1_RGMII_RXC 0x90>,
+ <MX8MP_IOMUXC_SAI1_TXFS__ENET1_RGMII_RX_CTL 0x90>,
+ <MX8MP_IOMUXC_SAI1_TXD0__ENET1_RGMII_TD0 0x12>,
+ <MX8MP_IOMUXC_SAI1_TXD1__ENET1_RGMII_TD1 0x12>,
+ <MX8MP_IOMUXC_SAI1_TXD2__ENET1_RGMII_TD2 0x12>,
+ <MX8MP_IOMUXC_SAI1_TXD3__ENET1_RGMII_TD3 0x12>,
+ <MX8MP_IOMUXC_SAI1_TXD4__ENET1_RGMII_TX_CTL 0x12>,
+ <MX8MP_IOMUXC_SAI1_TXD5__ENET1_RGMII_TXC 0x14>;
+ };
+
+ pinctrl_fec_event: fecevtgrp {
+ fsl,pins = <MX8MP_IOMUXC_SAI1_RXD1__ENET1_1588_EVENT1_OUT 0x100>,
+ <MX8MP_IOMUXC_SAI1_RXD0__ENET1_1588_EVENT1_IN 0x1c0>;
+ };
+
+ pinctrl_fec_phy: fecphygrp {
+ fsl,pins = <MX8MP_IOMUXC_SD1_CMD__GPIO2_IO01 0x1c0>;
+ };
+
+ pinctrl_flexcan1: flexcan1grp {
+ fsl,pins = <MX8MP_IOMUXC_SAI5_RXD1__CAN1_TX 0x150>,
+ <MX8MP_IOMUXC_SAI5_RXD2__CAN1_RX 0x150>;
+ };
+
+ pinctrl_flexcan2: flexcan2grp {
+ fsl,pins = <MX8MP_IOMUXC_SAI5_RXD3__CAN2_TX 0x150>,
+ <MX8MP_IOMUXC_SAI5_MCLK__CAN2_RX 0x150>;
+ };
+
+ pinctrl_flexspi0: flexspi0grp {
+ fsl,pins = <MX8MP_IOMUXC_NAND_ALE__FLEXSPI_A_SCLK 0x142>,
+ <MX8MP_IOMUXC_NAND_CE0_B__FLEXSPI_A_SS0_B 0x82>,
+ <MX8MP_IOMUXC_NAND_DQS__FLEXSPI_A_DQS 0x40000010>,
+ <MX8MP_IOMUXC_NAND_DATA00__FLEXSPI_A_DATA00 0x82>,
+ <MX8MP_IOMUXC_NAND_DATA01__FLEXSPI_A_DATA01 0x82>,
+ <MX8MP_IOMUXC_NAND_DATA02__FLEXSPI_A_DATA02 0x82>,
+ <MX8MP_IOMUXC_NAND_DATA03__FLEXSPI_A_DATA03 0x82>;
+ };
+
+ pinctrl_sdp: gbegrp {
+ fsl,pins = <MX8MP_IOMUXC_SAI1_TXD6__GPIO4_IO18 0x10>,
+ <MX8MP_IOMUXC_SAI1_TXD7__GPIO4_IO19 0x10>;
+ };
+
+ pinctrl_gpio1: gpio1grp {
+ fsl,pins = <MX8MP_IOMUXC_GPIO1_IO00__GPIO1_IO00 0x10>,
+ <MX8MP_IOMUXC_GPIO1_IO01__GPIO1_IO01 0x10>,
+ <MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x10>,
+ <MX8MP_IOMUXC_GPIO1_IO05__GPIO1_IO05 0x10>,
+ <MX8MP_IOMUXC_GPIO1_IO06__GPIO1_IO06 0x10>,
+ <MX8MP_IOMUXC_GPIO1_IO07__GPIO1_IO07 0x80>,
+ <MX8MP_IOMUXC_GPIO1_IO09__GPIO1_IO09 0x80>;
+ };
+
+ pinctrl_gpio3: gpio3grp {
+ fsl,pins = <MX8MP_IOMUXC_SAI5_RXFS__GPIO3_IO19 0x10>,
+ <MX8MP_IOMUXC_SAI5_RXC__GPIO3_IO20 0x10>;
+ };
+
+ pinctrl_gpio4: gpio4grp {
+ fsl,pins = <MX8MP_IOMUXC_SAI1_RXC__GPIO4_IO01 0x10>,
+ <MX8MP_IOMUXC_SAI1_RXD2__GPIO4_IO04 0x10>,
+ <MX8MP_IOMUXC_SAI1_MCLK__GPIO4_IO20 0x10>,
+ <MX8MP_IOMUXC_SAI2_TXC__GPIO4_IO25 0x10>,
+ <MX8MP_IOMUXC_SAI2_TXD0__GPIO4_IO26 0x10>,
+ <MX8MP_IOMUXC_SAI3_RXFS__GPIO4_IO28 0x10>,
+ <MX8MP_IOMUXC_SAI3_RXC__GPIO4_IO29 0x10>;
+ };
+
+ pinctrl_gpio5: gpio5grp {
+ fsl,pins = <MX8MP_IOMUXC_SPDIF_EXT_CLK__GPIO5_IO05 0x10>,
+ <MX8MP_IOMUXC_ECSPI2_SCLK__GPIO5_IO10 0x10>,
+ <MX8MP_IOMUXC_ECSPI2_MOSI__GPIO5_IO11 0x10>,
+ <MX8MP_IOMUXC_ECSPI2_SS0__GPIO5_IO13 0x10>;
+ };
+
+ pinctrl_hdmi: hdmigrp {
+ fsl,pins = <MX8MP_IOMUXC_HDMI_DDC_SCL__HDMIMIX_HDMI_SCL 0x400001c2>,
+ <MX8MP_IOMUXC_HDMI_DDC_SDA__HDMIMIX_HDMI_SDA 0x400001c2>,
+ <MX8MP_IOMUXC_HDMI_HPD__HDMIMIX_HDMI_HPD 0x40000010>;
+ };
+
+ pinctrl_hoggpio2: hoggpio2grp {
+ fsl,pins = <MX8MP_IOMUXC_SD1_STROBE__GPIO2_IO11 0x140>;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <MX8MP_IOMUXC_I2C1_SCL__I2C1_SCL 0x400001e2>,
+ <MX8MP_IOMUXC_I2C1_SDA__I2C1_SDA 0x400001e2>;
+ };
+
+ pinctrl_i2c1_gpio: i2c1-gpiogrp {
+ fsl,pins = <MX8MP_IOMUXC_I2C1_SCL__GPIO5_IO14 0x400001e2>,
+ <MX8MP_IOMUXC_I2C1_SDA__GPIO5_IO15 0x400001e2>;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <MX8MP_IOMUXC_I2C2_SCL__I2C2_SCL 0x400001e2>,
+ <MX8MP_IOMUXC_I2C2_SDA__I2C2_SDA 0x400001e2>;
+ };
+
+ pinctrl_i2c2_gpio: i2c2-gpiogrp {
+ fsl,pins = <MX8MP_IOMUXC_I2C2_SCL__GPIO5_IO16 0x400001e2>,
+ <MX8MP_IOMUXC_I2C2_SDA__GPIO5_IO17 0x400001e2>;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <MX8MP_IOMUXC_I2C3_SCL__I2C3_SCL 0x400001e2>,
+ <MX8MP_IOMUXC_I2C3_SDA__I2C3_SDA 0x400001e2>;
+ };
+
+ pinctrl_i2c3_gpio: i2c3-gpiogrp {
+ fsl,pins = <MX8MP_IOMUXC_I2C3_SCL__GPIO5_IO18 0x400001e2>,
+ <MX8MP_IOMUXC_I2C3_SDA__GPIO5_IO19 0x400001e2>;
+ };
+
+ pinctrl_i2c4: i2c4grp {
+ fsl,pins = <MX8MP_IOMUXC_SD1_DATA2__I2C4_SCL 0x400001e2>,
+ <MX8MP_IOMUXC_SD1_DATA3__I2C4_SDA 0x400001e2>;
+ };
+
+ pinctrl_i2c4_gpio: i2c4-gpiogrp {
+ fsl,pins = <MX8MP_IOMUXC_SD1_DATA2__GPIO2_IO04 0x400001e2>,
+ <MX8MP_IOMUXC_SD1_DATA3__GPIO2_IO05 0x400001e2>;
+ };
+
+ pinctrl_i2c6: i2c6grp {
+ fsl,pins = <MX8MP_IOMUXC_SD1_DATA0__I2C6_SCL 0x400001e2>,
+ <MX8MP_IOMUXC_SD1_DATA1__I2C6_SDA 0x400001e2>;
+ };
+
+ pinctrl_i2c6_gpio: i2c6-gpiogrp {
+ fsl,pins = <MX8MP_IOMUXC_SD1_DATA0__GPIO2_IO02 0x400001e2>,
+ <MX8MP_IOMUXC_SD1_DATA1__GPIO2_IO03 0x400001e2>;
+ };
+
+ pinctrl_pcf85063: pcf85063grp {
+ fsl,pins = <MX8MP_IOMUXC_SAI1_RXFS__GPIO4_IO00 0x80>;
+ };
+
+ pinctrl_pcie: pciegrp {
+ fsl,pins = <MX8MP_IOMUXC_I2C4_SCL__PCIE_CLKREQ_B 0x60>,
+ <MX8MP_IOMUXC_SD1_RESET_B__GPIO2_IO10 0x94>;
+ };
+
+ pinctrl_pmic: pmicirqgrp {
+ fsl,pins = <MX8MP_IOMUXC_GPIO1_IO08__GPIO1_IO08 0x1c0>;
+ };
+
+ pinctrl_pwm2: pwm2grp {
+ fsl,pins = <MX8MP_IOMUXC_SPDIF_RX__PWM2_OUT 0x14>;
+ };
+
+ pinctrl_pwm3: pwm3grp {
+ fsl,pins = <MX8MP_IOMUXC_SPDIF_TX__PWM3_OUT 0x14>;
+ };
+
+ pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
+ fsl,pins = <MX8MP_IOMUXC_SD2_RESET_B__GPIO2_IO19 0x10>;
+ };
+
+ pinctrl_reg_usdhc2_vqmmc: regusdhc2vqmmcgrp {
+ fsl,pins = <MX8MP_IOMUXC_GPIO1_IO04__GPIO1_IO04 0xc0>;
+ };
+
+ pinctrl_sai3: sai3grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SAI3_RXD__AUDIOMIX_SAI3_RX_DATA00 0x94
+ MX8MP_IOMUXC_SAI3_TXD__AUDIOMIX_SAI3_TX_DATA00 0x94
+ MX8MP_IOMUXC_SAI3_TXFS__AUDIOMIX_SAI3_TX_SYNC 0x94
+ MX8MP_IOMUXC_SAI3_TXC__AUDIOMIX_SAI3_TX_BCLK 0x94
+ >;
+ };
+
+ pinctrl_sai5: sai5grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SAI3_MCLK__AUDIOMIX_SAI5_MCLK 0x94
+ MX8MP_IOMUXC_SAI5_RXD0__AUDIOMIX_SAI5_RX_DATA00 0x94
+ MX8MP_IOMUXC_SAI2_RXD0__AUDIOMIX_SAI5_TX_DATA00 0x94
+ MX8MP_IOMUXC_SAI2_RXFS__AUDIOMIX_SAI5_TX_SYNC 0x94
+ MX8MP_IOMUXC_SAI2_RXC__AUDIOMIX_SAI5_TX_BCLK 0x94
+ >;
+ };
+
+ pinctrl_tc9595: tc9595grp {
+ fsl,pins = <MX8MP_IOMUXC_I2C4_SDA__GPIO5_IO21 0x10>;
+ };
+
+ pinctrl_tmp1075: tmp1075grp {
+ fsl,pins = <MX8MP_IOMUXC_HDMI_CEC__GPIO3_IO28 0x140>;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <MX8MP_IOMUXC_UART1_TXD__UART1_DCE_TX 0x140>,
+ <MX8MP_IOMUXC_UART1_RXD__UART1_DCE_RX 0x140>,
+ <MX8MP_IOMUXC_UART3_RXD__UART1_DCE_CTS 0x140>,
+ <MX8MP_IOMUXC_UART3_TXD__UART1_DCE_RTS 0x140>;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <MX8MP_IOMUXC_UART2_TXD__UART2_DCE_TX 0x140>,
+ <MX8MP_IOMUXC_UART2_RXD__UART2_DCE_RX 0x140>,
+ <MX8MP_IOMUXC_SD1_DATA4__UART2_DCE_RTS 0x140>,
+ <MX8MP_IOMUXC_SD1_DATA5__UART2_DCE_CTS 0x140>;
+ };
+
+ pinctrl_uart3: uart3grp {
+ fsl,pins = <MX8MP_IOMUXC_SD1_DATA6__UART3_DCE_TX 0x140>,
+ <MX8MP_IOMUXC_SD1_DATA7__UART3_DCE_RX 0x140>;
+ };
+
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <MX8MP_IOMUXC_UART4_RXD__UART4_DCE_RX 0x140>,
+ <MX8MP_IOMUXC_UART4_TXD__UART4_DCE_TX 0x140>;
+ };
+
+ pinctrl_usb0: usb0grp {
+ fsl,pins = <MX8MP_IOMUXC_GPIO1_IO13__USB1_OTG_OC 0x1c0>,
+ <MX8MP_IOMUXC_GPIO1_IO12__USB1_OTG_PWR 0x1c0>;
+ };
+
+ pinctrl_usb1: usb1grp {
+ fsl,pins = <MX8MP_IOMUXC_GPIO1_IO15__USB2_OTG_OC 0x1c0>,
+ <MX8MP_IOMUXC_GPIO1_IO14__USB2_OTG_PWR 0x1c0>;
+ };
+
+ pinctrl_usbcon0: usb0congrp {
+ fsl,pins = <MX8MP_IOMUXC_GPIO1_IO10__GPIO1_IO10 0x1c0>;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK 0x192>,
+ <MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD 0x1d2>,
+ <MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d2>,
+ <MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d2>,
+ <MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d2>,
+ <MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d2>;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+ fsl,pins = <MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK 0x194>,
+ <MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD 0x1d4>,
+ <MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d4>,
+ <MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d4>,
+ <MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d4>,
+ <MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d4>;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+ fsl,pins = <MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK 0x194>,
+ <MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD 0x1d4>,
+ <MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d4>,
+ <MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d4>,
+ <MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d4>,
+ <MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d4>;
+ };
+
+ pinctrl_usdhc2_gpio: usdhc2-gpiogrp {
+ fsl,pins = <MX8MP_IOMUXC_SD2_CD_B__GPIO2_IO12 0x1c0>,
+ <MX8MP_IOMUXC_SD2_WP__GPIO2_IO20 0x1c0>;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK 0x194>,
+ <MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3 0x1d4>,
+ <MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE 0x84>,
+ <MX8MP_IOMUXC_NAND_READY_B__USDHC3_RESET_B 0x84>;
+ };
+
+ pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {
+ fsl,pins = <MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK 0x194>,
+ <MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3 0x1d4>,
+ <MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE 0x84>,
+ <MX8MP_IOMUXC_NAND_READY_B__USDHC3_RESET_B 0x84>;
+ };
+
+ pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
+ fsl,pins = <MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK 0x194>,
+ <MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3 0x1d4>,
+ <MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE 0x84>,
+ <MX8MP_IOMUXC_NAND_READY_B__USDHC3_RESET_B 0x84>;
+ };
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <MX8MP_IOMUXC_GPIO1_IO02__WDOG1_WDOG_B 0x1c4>;
+ };
+};
--
2.54.0
^ permalink raw reply related
* [PATCH v6 4/4] arm64: dts: freescale: Add dual-channel LVDS overlay for TQMa8MPxS
From: Alexander Stein @ 2026-06-25 5:14 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Shawn Guo
Cc: Alexander Stein, devicetree, linux-kernel, imx, linux-arm-kernel,
linux, linux-renesas-soc
In-Reply-To: <20260625051449.2560197-1-alexander.stein@ew.tq-group.com>
This adds an overlay for the supported LVDS display AUO G133HAN01.
Configure the video PLL frequency to exactly match typical pixel clock of
141.200 MHz.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
Changes in v6:
* None
arch/arm64/boot/dts/freescale/Makefile | 2 +
...p-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso | 81 +++++++++++++++++++
2 files changed, 83 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 2f4568e7105f4..0c390ef6f7571 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -498,8 +498,10 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtbo
dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-lvds-tm070jvhg33.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-lvds-tm070jvhg33-imx219.dtb
+imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01-dtbs += imx8mp-tqma8mpqs-mb-smarc-2.dtb imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtbo
imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33-dtbs += imx8mp-tqma8mpqs-mb-smarc-2.dtb imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtbo
imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33-dtbs += imx8mp-tqma8mpqs-mb-smarc-2.dtb imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtbo
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso
new file mode 100644
index 0000000000000..2d2dfda944faa
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
+/*
+ * Copyright (c) 2025-2026 TQ-Systems GmbH <linux@ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Martin Schmiedel
+ */
+
+/dts-v1/;
+/plugin/;
+
+&backlight_lvds0 {
+ status = "okay";
+};
+
+&panel_lvds0 {
+ compatible = "auo,g133han01";
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dual-lvds-odd-pixels;
+
+ panel_in_lvds0: endpoint {
+ remote-endpoint = <&ldb_lvds_ch0>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dual-lvds-even-pixels;
+
+ panel_in_lvds1: endpoint {
+ remote-endpoint = <&ldb_lvds_ch1>;
+ };
+ };
+ };
+};
+
+&lcdif2 {
+ status = "okay";
+};
+
+&lvds_bridge {
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ ldb_lvds_ch0: endpoint {
+ remote-endpoint = <&panel_in_lvds0>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ ldb_lvds_ch1: endpoint {
+ remote-endpoint = <&panel_in_lvds1>;
+ };
+ };
+ };
+};
+
+// Update VIDEO_PLL1 frequency
+&media_blk_ctrl {
+ assigned-clock-rates = <500000000>, <200000000>,
+ <0>, <0>, <500000000>,
+ <988400000>;
+};
+
+&pwm3 {
+ status = "okay";
+};
--
2.54.0
^ permalink raw reply related
* [PATCH v6 3/4] arm64: dts: freescale: add LVDS overlays for TQMa8MPxS
From: Alexander Stein @ 2026-06-25 5:14 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Shawn Guo
Cc: Paul Gerber, devicetree, linux-kernel, imx, linux-arm-kernel,
linux, linux-renesas-soc, Alexander Stein
In-Reply-To: <20260625051449.2560197-1-alexander.stein@ew.tq-group.com>
From: Paul Gerber <paul.gerber@tq-group.com>
This adds overlays for the supported LVDS display tianma tm070jvhg33
for both LVDS channels.
The display timings have to be specified explicitly. Using the typical
pixel clock, the LDB clock can not be configured as the 7-fold of that.
By setting pixel clock to 74.25 MHz, LDB can be configured to exactly
519.75 MHz.
Signed-off-by: Paul Gerber <paul.gerber@tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
Changes in v6:
* None
arch/arm64/boot/dts/freescale/Makefile | 5 +++
...qma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtso | 43 +++++++++++++++++++
...qma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtso | 43 +++++++++++++++++++
3 files changed, 91 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtso
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index acb73cde76f16..2f4568e7105f4 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -498,6 +498,11 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtbo
dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-lvds-tm070jvhg33.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-lvds-tm070jvhg33-imx219.dtb
+imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33-dtbs += imx8mp-tqma8mpqs-mb-smarc-2.dtb imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtbo
+imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33-dtbs += imx8mp-tqma8mpqs-mb-smarc-2.dtb imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtbo
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtb
+
dtb-$(CONFIG_ARCH_MXC) += imx8mq-evk.dtb
imx8mq-evk-pcie1-ep-dtbs += imx8mq-evk.dtb imx-pcie1-ep.dtbo
dtb-$(CONFIG_ARCH_MXC) += imx8mq-evk-pcie1-ep.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtso b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtso
new file mode 100644
index 0000000000000..2cf1de8c05b49
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtso
@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
+/*
+ * Copyright (c) 2025-2026 TQ-Systems GmbH <linux@ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Paul Gerber
+ */
+
+/dts-v1/;
+/plugin/;
+
+&backlight_lvds0 {
+ status = "okay";
+};
+
+&panel_lvds0{
+ compatible = "tianma,tm070jvhg33";
+ status = "okay";
+
+ panel-timing {
+ clock-frequency = <74250000>;
+ hactive = <1280>;
+ vactive = <800>;
+ hfront-porch = <64>;
+ hback-porch = <5>;
+ hsync-len = <1>;
+ vfront-porch = <40>;
+ vback-porch = <2>;
+ vsync-len = <1>;
+ de-active = <1>;
+ };
+};
+
+&lcdif2 {
+ status = "okay";
+};
+
+&lvds_bridge {
+ status = "okay";
+};
+
+&pwm3 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtso b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtso
new file mode 100644
index 0000000000000..cbad0cfab2925
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtso
@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
+/*
+ * Copyright (c) 2025-2026 TQ-Systems GmbH <linux@ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Paul Gerber
+ */
+
+/dts-v1/;
+/plugin/;
+
+&backlight_lvds1 {
+ status = "okay";
+};
+
+&panel_lvds1{
+ compatible = "tianma,tm070jvhg33";
+ status = "okay";
+
+ panel-timing {
+ clock-frequency = <74250000>;
+ hactive = <1280>;
+ vactive = <800>;
+ hfront-porch = <64>;
+ hback-porch = <5>;
+ hsync-len = <1>;
+ vfront-porch = <40>;
+ vback-porch = <2>;
+ vsync-len = <1>;
+ de-active = <1>;
+ };
+};
+
+&lcdif2 {
+ status = "okay";
+};
+
+&lvds_bridge {
+ status = "okay";
+};
+
+&pwm2 {
+ status = "okay";
+};
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2 2/2] arm64: dts: qcom: sdm845-oneplus: Update compatible to include model
From: Dmitry Torokhov @ 2026-06-25 4:53 UTC (permalink / raw)
To: David Heidelberg
Cc: Krzysztof Kozlowski, Konrad Dybcio, Rob Herring, Conor Dooley,
Jason A. Donenfeld, Matthias Schiffer, Vincent Huang,
Bjorn Andersson, Konrad Dybcio, linux-input, devicetree,
linux-kernel, linux-arm-msm, phone-devel, Krzysztof Kozlowski
In-Reply-To: <52b7dd3a-3f6f-474c-8386-4fc2776b185b@ixit.cz>
On Wed, Jun 24, 2026 at 04:37:25PM +0200, David Heidelberg wrote:
> On 24/06/2026 06:28, Dmitry Torokhov wrote:
> > Hi David,
> >
> > On Sun, Jun 21, 2026 at 07:11:45PM +0200, David Heidelberg wrote:
> > > On 28/05/2026 00:13, David Heidelberg wrote:
> > > > On 27/05/2026 23:56, Dmitry Torokhov wrote:
> > > > > Hi David,
> > > > >
> > > > > On Sat, May 23, 2026 at 11:45:35AM +0200, David Heidelberg via B4 Relay wrote:
> > > > > > From: David Heidelberg <david@ixit.cz>
> > > > > >
> > > > > > We know the driver is reporting s3706b, introduce the compatible so we
> > > > > > can more easily introduce quirks for weird touchscreen replacements in
> > > > > > followup series.
> > > > > >
> > > > > > Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> > > > > > Signed-off-by: David Heidelberg <david@ixit.cz>
> > > > > > ---
> > > > > > arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 2 +-
> > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> > > > > > b/arch/ arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> > > > > > index 6b7378cf4d493..148164d456a5a 100644
> > > > > > --- a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> > > > > > +++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> > > > > > @@ -475,17 +475,17 @@ bq27441_fg: bq27441-battery@55 {
> > > > > > };
> > > > > > };
> > > > > > &i2c12 {
> > > > > > status = "okay";
> > > > > > clock-frequency = <400000>;
> > > > > > synaptics-rmi4-i2c@20 {
> > > > > > - compatible = "syna,rmi4-i2c";
> > > > > > + compatible = "syna,rmi4-s3706b", "syna,rmi4-i2c";
> > > > >
> > > > > So I believe we established that this device (s3706b) does not in fact
> > > > > implement rmi4 protocol properly. Why do we have "syna,rmi4-i2c" as a
> > > > > fallback? Shouldn't it be just "syna,rmi4-s3706b"?
> > > >
> > > > The vendor supplies s3706b which does implement the RMI4 properly.
> > > >
> > > > The 3rd party replacement impersonating original parts may not implement
> > > > it properly, but I don't address this issue in this initial submission.
> > > >
> > > > With this compatible we know which original part is used by the vendor
> > > > and installed in the phones, so later we can deduct specific sequences
> > > > for the replacement aftermarket parts to keep phone touchscreen working
> > > > same as they do on Android without affecting other devices.
> > >
> > > Hello Dmitry.
> > >
> > > May I ask what is currently preventing this series from moving forward?
> > >
> > > The first version was posted in 2023 [1]. I picked it up again in 2025 [2]
> > > and am now on the 9th iteration (this patchset). At this point, the series
> > > has been under discussion for well over a year, with relatively little
> > > feedback and increasingly long gaps between review rounds.
> > >
> > > The current approach is based on the guidance I have received so far,
> > > including suggestions from the device-tree maintainers. When concerns were
> > > raised, I tried to address them and rework the series accordingly.
> > >
> > > What I am struggling with is understanding what specific issue still needs
> > > to be resolved before these patches can be accepted. If there are remaining
> > > requirements, objections to the approach, or technical concerns that I have
> > > not addressed, I would appreciate having them stated explicitly so I can
> > > work on them.
> > >
> > > I also split out the straightforward, self-contained changes in the hope
> > > that at least those could progress independently while I continued working
> > > on any follow-up requirements. However, even those patches do not appear to
> > > be moving forward.
> > >
> > > Could you please clarify what outcome you would like to see from this
> > > series, and what concrete changes would be required to get it accepted?
> >
> > I am still confused about how you want to differentiate between the full
> > RMI4 support vs the OnePlus flavor. The "syna,rmi4-s3706b", as you
> > mentioned, implements RMI4 protocol properly, so we do not need to
> > actually have it documented neither in binding nor in DTS.
>
> --- part 1 ---
>
> This series addresses identification within device-tree. It's normal
> recommended practice.
>
> If we know, the device ships specific, but **compliant** variant, we just
> put it as compatible = "more-specific", "less-specific"; in this case
> "syna,rmi4-s3706b", "syna,rmi4-i2c"
>
> This approach is used everywhere. This has nothing to do with after-market parts.
We do this in many cases, sometimes when a part has different timings or
maybe additional functionality compared to the base model.
How does this new compatible for controller that fully implements RMI4
protocol help here?
>
> --- part 2 (irrelevant for this series) ---
>
> >
> > The issue you have with after-market parts that are not compliant and we
> > need to figure out how to deal with them. Inside the driver I
>
> As was suggested by device-tree folks, this is the first step, there isn't
> better one available. If there is, please suggest one, and I'll apply it.
Was it clearly communicated to DT folks that the compatible you are
adding is fully compatible with the base "syna,rmi4-i2c" but other ones
will not be compatible?
>
> > essentially need a"incomplete protocol" flag that we can use to
> > implement additional checks or skip known to be not implemented
> > functions/queries. In DT we could introduce something like
> > "oneplus,rmi4-i2c" that is decidedly not compatible with "syna,rmi4-i2c"
> > and neither one should be a fallback for the other.
> >
> > This of course needs buy-in from DT maintainers.
>
> As you can see, this still holds Acked-by and Reviewed-by from the relevant
> people - Krzysztof and Konrad.
I see that but the commit does not explain how exactly you are planning
to deal with knockoffs.
>
> >
> > Does this make sense?
>
> For the scope we're discussing it doesn't seems so.
>
> This discussion should be associated with the last revision of the full
> series I sent 3 months ago. We're in very unflattering state, where:
>
> 2018 - these aftermarket touchscreen worked on Android well enough for
> people to have working touch (let's say with slightly worse experience then
> the original).
>
> 2026 in the mainline, we cannot even more forward and report to user-space
> there is aftermarket non-compliant piece of hardware installed.
>
> Actionable steps I suggest after this series lands:
>
> 1. don't do any changes, but since we know what 3rd party touchscreen do
> incorrectly deviating from the standard, REPORT it to the userspace, so USER
> know, their device (phone/tablet) doesn't have original part.
>
> 2. then figure out, IF we can reasonably well workaround it and HOW to do it
>
> These two steps present some progress which could be discussed and could
> lead us somewhere, what do you think?
So since we know that these devices can come with controllers that do
not implement RMI4 fully, can we:
1. Establish a new compatible that is separate from syna,rmi4-i2c? As I
mentioned, it could be oneplus,rmi4-i2c or event a concrete controller
vendor,id combo. The point that it should be completely separate from
the current compatible and not use the current compatible as a fallback.
2. Make modifications to RMI4 implementation to handle these controllers
in a reasonable manner, but not mess up the full RMI4 support
3. Update DTS for the affected headsets to switch them to this new
implementation.2. Make modifications to RMI4 implementation to handle
these controllers in a reasonable manner, but not mess up the full RMI4
support
3. Update DTS for the affected headsets to switch them to this new
implementation.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: mfd: qcom,spmi-pmic: Document haptics device
From: Rob Herring (Arm) @ 2026-06-25 3:32 UTC (permalink / raw)
To: Fenglin Wu
Cc: Subbaraman Narayanamurthy, Lee Jones, devicetree, kernel,
Dmitry Torokhov, Bjorn Andersson, linux-kernel, David Collins,
Kamal Wadhwa, Conor Dooley, Krzysztof Kozlowski, linux-input,
Stephen Boyd, Konrad Dybcio, linux-arm-msm
In-Reply-To: <20260624-qcom-spmi-haptics-v2-2-b9118e60f3e3@oss.qualcomm.com>
On Wed, 24 Jun 2026 19:00:37 -0700, Fenglin Wu wrote:
> Some of the Qualcomm SPMI PMIC has haptics device in it, add it in the
> device list.
>
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/input/qcom,spmi-haptics.yaml: properties:qcom,vmax-microvolt: '$ref' should not be valid under {'const': '$ref'}
hint: Standard unit suffix properties don't need a type $ref
from schema $id: http://devicetree.org/meta-schemas/core.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/input/qcom,spmi-haptics.example.dtb: haptics@f000 (qcom,spmi-haptics): qcom,vmax-microvolt: 1300000 is not of type 'array'
from schema $id: http://devicetree.org/schemas/property-units.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260624-qcom-spmi-haptics-v2-2-b9118e60f3e3@oss.qualcomm.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v2 4/4] phy: nuvoton: phy-ma35d1-usb2: extend to dual-port with OTG support
From: sashiko-bot @ 2026-06-25 2:59 UTC (permalink / raw)
To: Joey Lu
Cc: neil.armstrong, robh, conor+dt, olteanv, devicetree, vkoul,
linux-phy
In-Reply-To: <20260625023958.569299-5-a0987203069@gmail.com>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [High] The custom `ma35_usb_phy_xlate` callback accesses `args->args[0]` without verifying `args->args_count`, leading to a potential read of uninitialized stack memory.
- [High] The driver breaks Device Tree backward compatibility by unconditionally relying on the parent's `of_node` for the syscon regmap, removing the legacy 'nuvoton,sys' phandle fallback.
- [High] The driver fails to explicitly clear the 'MISCFCR0_UHOVRCURH' bit if the 'nuvoton,oc-active-high' property is absent, leading to persistent incorrect hardware state across soft reboots.
- [High] The driver incorrectly skips PHY clock stabilization checks if the `SUSPEND` bit is already set, potentially leading to hardware hangs.
- [Medium] The variable 'val' in `ma35_role_sw_get` is used uninitialized if the `regmap_read` call fails.
--
commit ff3f6d83cfb95f48a64d4c533549a7465a41d150
Author: Joey Lu <a0987203069@gmail.com>
phy: nuvoton: phy-ma35d1-usb2: extend to dual-port with OTG support
This commit extends the driver to support both PHY ports and integrates OTG
role switching. It introduces a custom xlate function, unifies the init
callback, removes redundant clock management, and registers a USB role switch.
> --- a/drivers/phy/nuvoton/phy-ma35d1-usb2.c
> +++ b/drivers/phy/nuvoton/phy-ma35d1-usb2.c
[ ... ]
> +static int ma35_usb_phy_init(struct phy *phy)
> +{
> + struct ma35_phy_port *port = phy_get_drvdata(phy);
> + struct ma35_usb_phy *p = container_of(port - port->idx,
> + struct ma35_usb_phy, port[0]);
> + unsigned int n = port->idx;
> + unsigned int val;
> + int ret;
> +
> + regmap_read(p->sysreg, MA35_SYS_USBPMISCR, &val);
> +
> + if (val & USBPMISCR_PHY_SUSPEND(n))
> + return 0;
[Severity: High]
Does returning early here skip necessary PHY clock stabilization checks?
The previous implementation specifically polled the clock stable bit
even when the suspend bit was already set. By returning immediately,
the USB controller might start accessing the PHY before its newly ungated
clock has fully stabilized, potentially resulting in bus hangs.
[ ... ]
> +static enum usb_role ma35_role_sw_get(struct usb_role_switch *sw)
> +{
> + struct ma35_usb_phy *p = usb_role_switch_get_drvdata(sw);
> + u32 val;
> +
> + regmap_read(p->sysreg, MA35_SYS_PWRONOTP, &val);
> +
> + return (val & PWRONOTP_USBP0ID) ? USB_ROLE_HOST : USB_ROLE_DEVICE;
> +}
[Severity: Medium]
Is it possible for val to be evaluated uninitialized here?
If regmap_read() encounters an error, it returns a non-zero error code
and leaves val unmodified. This could cause the function to return an
incorrect USB role based on stack garbage.
[ ... ]
> +static struct phy *ma35_usb_phy_xlate(struct device *dev,
> + const struct of_phandle_args *args)
> +{
> + struct ma35_usb_phy *p = dev_get_drvdata(dev);
> +
> + if (args->args[0] >= MA35_PHY_NUM)
> + return ERR_PTR(-EINVAL);
[Severity: High]
Does this code safely handle device trees where the number of phy cells is zero?
If args_count is zero, args->args would be uninitialized stack memory,
which could result in returning an incorrect PHY port or out-of-bounds
access. Should there be a check for args->args_count >= 1?
[ ... ]
> +static int ma35_usb_phy_probe(struct platform_device *pdev)
> +{
[ ... ]
> + p->sysreg = syscon_node_to_regmap(pdev->dev.parent->of_node);
> + if (IS_ERR(p->sysreg))
> + return dev_err_probe(&pdev->dev, PTR_ERR(p->sysreg),
> + "failed to get parent SYS regmap\n");
[Severity: High]
Does this break Device Tree backward compatibility?
The old implementation relied on a "nuvoton,sys" phandle fallback which has
been removed here. Systems using older device tree binaries might fail to
probe the USB PHY on kernel upgrades if the node isn't a direct child of
the syscon.
[ ... ]
> + if (of_property_read_bool(pdev->dev.of_node, "nuvoton,oc-active-high"))
> + regmap_update_bits(p->sysreg, MA35_SYS_MISCFCR0,
> + MISCFCR0_UHOVRCURH, MISCFCR0_UHOVRCURH);
[Severity: High]
If the "nuvoton,oc-active-high" property is absent, should this code explicitly
clear the MISCFCR0_UHOVRCURH bit?
Without an else branch to clear the bit, a soft reboot could incorrectly
inherit an active-high state set by a bootloader or previous kernel.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625023958.569299-1-a0987203069@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: phy: nuvoton,ma35d1-usb2-phy: extend for dual-port OTG support
From: sashiko-bot @ 2026-06-25 2:58 UTC (permalink / raw)
To: Joey Lu
Cc: vkoul, devicetree, neil.armstrong, conor+dt, olteanv, linux-phy,
robh
In-Reply-To: <20260625023958.569299-3-a0987203069@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The commit message claims multiple driver behavioral changes that are missing from the patch, leaving the driver incompatible with the new binding.
--
commit f557b8622653f3df69b040020ac61c52fd0498d6
Author: Joey Lu <a0987203069@gmail.com>
dt-bindings: phy: nuvoton,ma35d1-usb2-phy: extend for dual-port OTG support
This commit updates the device tree binding for the MA35D1 USB2 PHY to support
dual-port OTG. It changes the PHY node to be a child of a syscon node, removes
the nuvoton,sys and clocks properties, and updates #phy-cells to 1.
> - The PHY node is now a child of the system-management syscon node
> with a reg property. The nuvoton,sys phandle and clocks properties
> are removed; the driver derives the regmap from its parent, and
> clock gating is owned by each individual USB controller.
>
> - #phy-cells changes from 0 to 1: the cell selects the PHY port.
> diff --git a/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.yaml
> index fff858c909a06..a20d03c80932b 100644
> --- a/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.yaml
[ ... ]
> @@ -8,38 +8,72 @@ title: Nuvoton MA35D1 USB2 phy
[ ... ]
> "#phy-cells":
> - const: 0
> + const: 1
> + description:
> + The single cell selects the PHY port. 0 selects the OTG port (USB0,
> + shared with DWC2 gadget controller) and 1 selects the host-only port
> + (USB1).
>
> - clocks:
> - maxItems: 1
>
> - nuvoton,sys:
> - $ref: /schemas/types.yaml#/definitions/phandle
> + nuvoton,rcalcode:
[Severity: High]
Does this patch introduce a regression by updating the binding without the
corresponding driver updates?
The commit message indicates the driver derives the regmap from its parent and
handles the #phy-cells change, but this patch does not contain driver
modifications.
If a device tree is updated to comply with this new binding, will the existing
driver fail to probe? Looking at ma35_usb_phy_probe() in
drivers/phy/nuvoton/phy-ma35d1-usb2.c, it unconditionally requires the
nuvoton,sys property:
drivers/phy/nuvoton/phy-ma35d1-usb2.c:ma35_usb_phy_probe() {
...
p_phy->sysreg = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
"nuvoton,sys");
if (IS_ERR(p_phy->sysreg))
...
}
Additionally, the unmodified driver still uses of_phy_simple_xlate and
registers a single PHY, which is structurally incompatible with the binding
change to #phy-cells = <1>:
drivers/phy/nuvoton/phy-ma35d1-usb2.c:ma35_usb_phy_probe() {
...
provider = devm_of_phy_provider_register(&pdev->dev, of_phy_simple_xlate);
...
}
Should the driver changes be included in this patch or submitted together as
a series to avoid breaking USB initialization at boot time for compliant device
trees?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625023958.569299-1-a0987203069@gmail.com?part=2
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox