* [PATCH v2 2/6] dt-bindings: opp: ti-cpu: Add ti,soc-info property
From: Akashdeep Kaur @ 2026-04-01 10:54 UTC (permalink / raw)
To: krzk, praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt,
rafael, viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
In-Reply-To: <20260401105404.1194717-1-a-kaur@ti.com>
Add ti,soc-info property to allow OPP tables to reference the SoC info
device (chipid) for establishing device link dependencies.
This is used on K3 SoCs (AM625, AM62A7, AM62L3, AM62P5) to ensure proper
probe ordering between ti-cpufreq and k3-socinfo drivers. The ti-cpufreq
driver depends on k3-socinfo registering the SoC device for revision
detection via soc_device_match().
The device link also prevents unbinding k3-socinfo while ti-cpufreq is
using it, maintaining system stability.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
.../bindings/opp/operating-points-v2-ti-cpu.yaml | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml b/Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml
index 624d1f3f1382..f318494d5295 100644
--- a/Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml
+++ b/Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml
@@ -34,6 +34,16 @@ properties:
points to syscon node representing the control module
register space of the SoC.
+ ti,soc-info:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: |
+ Optional phandle to the SoC info device (chipid). Used on K3 SoCs
+ to establish device link dependencies ensuring proper probe ordering
+ (ti-cpufreq after k3-socinfo) and preventing unbinding of k3-socinfo
+ while the OPP table is in use. This is needed because ti-cpufreq uses
+ soc_device_match() to detect SoC revision information provided by
+ k3-socinfo.
+
opp-shared: true
patternProperties:
@@ -82,6 +92,7 @@ examples:
opp-table {
compatible = "operating-points-v2-ti-cpu";
syscon = <&scm_conf>;
+ ti,soc-info = <&chipid>;
opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/6] cpufreq: ti: Fix probe ordering and add device link support for K3 SoCs
From: Akashdeep Kaur @ 2026-04-01 10:53 UTC (permalink / raw)
To: krzk, praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt,
rafael, viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
For K3 SoCs, ti-cpufreq depends on k3-socinfo to provide SoC revision
information via soc_device_match(). If ti-cpufreq probes before
k3-socinfo, soc_device_match() returns NULL, causing incorrect
revision detection and OPP table initialization failures.
Add EPROBE_DEFER handling in ti-cpufreq when soc_device_match() fails
for K3 SoCs, ensuring k3-socinfo probes first.
Add device link support via a new DT property "ti,soc-info" in CPU
OPP tables. Device links prevent unbinding k3-socinfo while
ti-cpufreq is using it.
EPROBE_DEFER handles first-boot probe ordering, while device links
provide runtime dependency management.
For backward compatibility, the DT property is optional.
Changes in v2
- Added DT bindings documentation for ti,soc-info property
- Reordered patches: bindings first, then driver changes, then DTS
- Link to v1: https://lore.kernel.org/all/20260330120105.2985200-1-a-kaur@ti.com/
Testing
- Verified correct probe ordering on AM625, AM62A7, AM62P5 platforms
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
Akashdeep Kaur (6):
cpufreq: ti: Add EPROBE_DEFER for K3 SoCs
dt-bindings: opp: ti-cpu: Add ti,soc-info property
cpufreq: ti: Add device link to k3-socinfo
arm64: dts: ti: k3-am625: Add ti,soc-info to OPP table
arm64: dts: ti: k3-am62a7: Add ti,soc-info to OPP table
arm64: dts: ti: k3-am62p5: Add ti,soc-info to OPP table
.../opp/operating-points-v2-ti-cpu.yaml | 11 ++++
arch/arm64/boot/dts/ti/k3-am625.dtsi | 1 +
arch/arm64/boot/dts/ti/k3-am62a7.dtsi | 1 +
arch/arm64/boot/dts/ti/k3-am62p5.dtsi | 1 +
drivers/cpufreq/ti-cpufreq.c | 61 +++++++++++++++++++
5 files changed, 75 insertions(+)
--
2.34.1
^ permalink raw reply
* [PATCH v2 1/6] cpufreq: ti: Add EPROBE_DEFER for K3 SoCs
From: Akashdeep Kaur @ 2026-04-01 10:53 UTC (permalink / raw)
To: krzk, praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt,
rafael, viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
In-Reply-To: <20260401105404.1194717-1-a-kaur@ti.com>
Defer probe when k3-socinfo hasn't registered the SoC device yet.
Fixes incorrect revision detection when ti-cpufreq probes first.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
drivers/cpufreq/ti-cpufreq.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
index 3d1129aeed02..88f7912ef6a8 100644
--- a/drivers/cpufreq/ti-cpufreq.c
+++ b/drivers/cpufreq/ti-cpufreq.c
@@ -441,6 +441,15 @@ static int ti_cpufreq_get_rev(struct ti_cpufreq_data *opp_data,
*/
*revision_value = 0x1;
goto done;
+ } else if (opp_data->soc_data == &am625_soc_data ||
+ opp_data->soc_data == &am62a7_soc_data ||
+ opp_data->soc_data == &am62l3_soc_data ||
+ opp_data->soc_data == &am62p5_soc_data) {
+ /*
+ * For K3 SoCs, if soc_device_match fails, socinfo hasn't
+ * probed yet. Defer probe to wait for it.
+ */
+ return -EPROBE_DEFER;
}
ret = regmap_read(opp_data->syscon, opp_data->soc_data->rev_offset,
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] of/platform: Don't include reserved memory compatibles that aren't needed
From: Krzysztof Kozlowski @ 2026-04-01 10:54 UTC (permalink / raw)
To: Daniel Palmer; +Cc: robh, saravanak, devicetree, linux-kernel
In-Reply-To: <20260331215735.2783770-1-daniel@thingy.jp>
On Wed, Apr 01, 2026 at 06:57:35AM +0900, Daniel Palmer wrote:
> There are a number of very platform specific compatibles for reserved
> memory that the vast majority of people don't need and they waste
> 196/200 bytes each.
We don't want #ifdefs in the code because they are more difficult to
maintain and review. Following your approach we would need to add such
ifdefs in multiple other places, so I am not convinced it is worth.
And this file should not be having different rules than rest of drivers.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 2/5] media: iris: Add hardware power on/off ops for X1P42100
From: Bryan O'Donoghue @ 2026-04-01 10:49 UTC (permalink / raw)
To: Wangao Wang, Vikash Garodia, Dikshita Agarwal, Abhinav Kumar,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260401-enable_iris_on_purwa-v4-2-ca784552a3e9@oss.qualcomm.com>
On 01/04/2026 11:24, Wangao Wang wrote:
> On X1P42100 the Iris block has an extra BSE clock. Wire this clock into
> the power on/off sequence.
>
> The BSE clock is used to drive the Bin Stream Engine, which is a sub-block
> of the video codec hardware responsible for bitstream-level processing. It
> is required to be enabled separately from the core clock to ensure proper
> codec operation.
>
> Signed-off-by: Wangao Wang <wangao.wang@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/iris/iris_vpu3x.c | 46 ++++++++++++++++++++++
> drivers/media/platform/qcom/iris/iris_vpu_common.h | 1 +
> 2 files changed, 47 insertions(+)
>
> diff --git a/drivers/media/platform/qcom/iris/iris_vpu3x.c b/drivers/media/platform/qcom/iris/iris_vpu3x.c
> index fe4423b951b1e9e31d06dffc69d18071cc985731..e6a62b3ca78efeefa2eed267636789a6b405689f 100644
> --- a/drivers/media/platform/qcom/iris/iris_vpu3x.c
> +++ b/drivers/media/platform/qcom/iris/iris_vpu3x.c
> @@ -71,6 +71,44 @@ static void iris_vpu3_power_off_hardware(struct iris_core *core)
> iris_vpu_power_off_hw(core);
> }
>
> +static int iris_vpu3_purwa_power_on_hw(struct iris_core *core)
> +{
> + int ret;
> +
> + ret = iris_enable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN]);
> + if (ret)
> + return ret;
> +
> + ret = iris_prepare_enable_clock(core, IRIS_HW_CLK);
> + if (ret)
> + goto err_disable_power;
> +
> + ret = iris_prepare_enable_clock(core, IRIS_BSE_HW_CLK);
> + if (ret)
> + goto err_disable_hw_clock;
> +
> + ret = dev_pm_genpd_set_hwmode(core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN], true);
> + if (ret)
> + goto err_disable_bse_hw_clock;
> +
> + return 0;
> +
> +err_disable_bse_hw_clock:
> + iris_disable_unprepare_clock(core, IRIS_BSE_HW_CLK);
> +err_disable_hw_clock:
> + iris_disable_unprepare_clock(core, IRIS_HW_CLK);
> +err_disable_power:
> + iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN]);
> +
> + return ret;
> +}
> +
> +static void iris_vpu3_purwa_power_off_hardware(struct iris_core *core)
> +{
> + iris_vpu3_power_off_hardware(core);
> + iris_disable_unprepare_clock(core, IRIS_BSE_HW_CLK);
> +}
> +
> static void iris_vpu33_power_off_hardware(struct iris_core *core)
> {
> bool handshake_done = false, handshake_busy = false;
> @@ -268,6 +306,14 @@ const struct vpu_ops iris_vpu3_ops = {
> .calc_freq = iris_vpu3x_vpu4x_calculate_frequency,
> };
>
> +const struct vpu_ops iris_vpu3_purwa_ops = {
> + .power_off_hw = iris_vpu3_purwa_power_off_hardware,
> + .power_on_hw = iris_vpu3_purwa_power_on_hw,
> + .power_off_controller = iris_vpu_power_off_controller,
> + .power_on_controller = iris_vpu_power_on_controller,
> + .calc_freq = iris_vpu3x_vpu4x_calculate_frequency,
> +};
> +
> const struct vpu_ops iris_vpu33_ops = {
> .power_off_hw = iris_vpu33_power_off_hardware,
> .power_on_hw = iris_vpu_power_on_hw,
> diff --git a/drivers/media/platform/qcom/iris/iris_vpu_common.h b/drivers/media/platform/qcom/iris/iris_vpu_common.h
> index f6dffc613b822341fb21e12de6b1395202f62cde..88a23cbdc06c5b38b4c8db67718cbd538f0e0721 100644
> --- a/drivers/media/platform/qcom/iris/iris_vpu_common.h
> +++ b/drivers/media/platform/qcom/iris/iris_vpu_common.h
> @@ -10,6 +10,7 @@ struct iris_core;
>
> extern const struct vpu_ops iris_vpu2_ops;
> extern const struct vpu_ops iris_vpu3_ops;
> +extern const struct vpu_ops iris_vpu3_purwa_ops;
> extern const struct vpu_ops iris_vpu33_ops;
> extern const struct vpu_ops iris_vpu35_ops;
> extern const struct vpu_ops iris_vpu4x_ops;
>
> --
> 2.43.0
>
Where @ v4 has noone else reviewed this yet or have you forgotten to b4
trailers --update ?
Anyway.
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
---
bod
^ permalink raw reply
* [PATCH v2 2/2] hwmon:(pmbus/xdp720) Add support for efuse xdp720
From: ASHISH YADAV @ 2026-04-01 10:45 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-hwmon, devicetree, linux-kernel, Ashish Yadav
In-Reply-To: <20260401104550.115715-1-Ashish.Yadav@infineon.com>
From: Ashish Yadav <ashish.yadav@infineon.com>
Add the pmbus driver for Infineon XDP720 Digital eFuse Controller.
Signed-off-by: Ashish Yadav <ashish.yadav@infineon.com>
---
XDP720 Digital eFuse Controller provides accurate system telemetry
(V, I, P, T) and reports analog current at the IMON pin for post-processing.
The Current and Power measurement depends on the RIMON and GIMON values.
Please look into data sheet sections 5.4.2 and 5.4.4 for more details:
https://www.infineon.com/assets/row/public/documents/24/49/infineon-xdp720-001-datasheet-en.pdf
The GIMON (microA/A) depends on the 10th bit of TELEMETRY_AVG PMBUS Register.
The value of RIMON (kohm) can be provided by the user through device tree using
infineon,rimon-micro-ohms property.
---
drivers/hwmon/pmbus/Kconfig | 9 +++
drivers/hwmon/pmbus/Makefile | 1 +
drivers/hwmon/pmbus/xdp720.c | 123 +++++++++++++++++++++++++++++++++++
3 files changed, 133 insertions(+)
create mode 100644 drivers/hwmon/pmbus/xdp720.c
diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
index fc1273abe357..c419e3ecce90 100644
--- a/drivers/hwmon/pmbus/Kconfig
+++ b/drivers/hwmon/pmbus/Kconfig
@@ -702,6 +702,15 @@ config SENSORS_XDP710
This driver can also be built as a module. If so, the module will
be called xdp710.
+config SENSORS_XDP720
+ tristate "Infineon XDP720 family"
+ help
+ If you say yes here you get hardware monitoring support for Infineon
+ XDP720.
+
+ This driver can also be built as a module. If so, the module will
+ be called xdp720.
+
config SENSORS_XDPE152
tristate "Infineon XDPE152 family"
help
diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
index d6c86924f887..1cac7ccae79f 100644
--- a/drivers/hwmon/pmbus/Makefile
+++ b/drivers/hwmon/pmbus/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_SENSORS_TPS546D24) += tps546d24.o
obj-$(CONFIG_SENSORS_UCD9000) += ucd9000.o
obj-$(CONFIG_SENSORS_UCD9200) += ucd9200.o
obj-$(CONFIG_SENSORS_XDP710) += xdp710.o
+obj-$(CONFIG_SENSORS_XDP720) += xdp720.o
obj-$(CONFIG_SENSORS_XDPE122) += xdpe12284.o
obj-$(CONFIG_SENSORS_XDPE152) += xdpe152c4.o
obj-$(CONFIG_SENSORS_ZL6100) += zl6100.o
diff --git a/drivers/hwmon/pmbus/xdp720.c b/drivers/hwmon/pmbus/xdp720.c
new file mode 100644
index 000000000000..382dc3f9ce80
--- /dev/null
+++ b/drivers/hwmon/pmbus/xdp720.c
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Hardware monitoring driver for Infineon XDP720 Digital eFuse Controller
+ *
+ * Copyright (c) 2026 Infineon Technologies. All rights reserved.
+ */
+
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/of_device.h>
+#include <linux/bitops.h>
+#include <linux/math64.h>
+#include "pmbus.h"
+
+/*
+ * The IMON resistor required to generate the system overcurrent protection.
+ * Arbitrary default Rimon value: 2k Ohm
+ */
+#define XDP720_DEFAULT_RIMON 2000000000 /* 2k ohm */
+#define XDP720_TELEMETRY_AVG 0xE9
+
+static struct pmbus_driver_info xdp720_info = {
+ .pages = 1,
+ .format[PSC_VOLTAGE_IN] = direct,
+ .format[PSC_VOLTAGE_OUT] = direct,
+ .format[PSC_CURRENT_OUT] = direct,
+ .format[PSC_POWER] = direct,
+ .format[PSC_TEMPERATURE] = direct,
+
+ .m[PSC_VOLTAGE_IN] = 4653,
+ .b[PSC_VOLTAGE_IN] = 0,
+ .R[PSC_VOLTAGE_IN] = -2,
+ .m[PSC_VOLTAGE_OUT] = 4653,
+ .b[PSC_VOLTAGE_OUT] = 0,
+ .R[PSC_VOLTAGE_OUT] = -2,
+ /*
+ * Current and Power measurement depends on the RIMON (kOhm) and
+ * GIMON(microA/A) values.
+ */
+ .m[PSC_CURRENT_OUT] = 24668,
+ .b[PSC_CURRENT_OUT] = 0,
+ .R[PSC_CURRENT_OUT] = -4,
+ .m[PSC_POWER] = 4486,
+ .b[PSC_POWER] = 0,
+ .R[PSC_POWER] = -1,
+ .m[PSC_TEMPERATURE] = 54,
+ .b[PSC_TEMPERATURE] = 22521,
+ .R[PSC_TEMPERATURE] = -1,
+
+ .func[0] = PMBUS_HAVE_VIN | PMBUS_HAVE_VOUT | PMBUS_HAVE_PIN |
+ PMBUS_HAVE_TEMP | PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_INPUT |
+ PMBUS_HAVE_STATUS_TEMP,
+};
+
+static int xdp720_probe(struct i2c_client *client)
+{
+ struct pmbus_driver_info *info;
+ int ret;
+ u32 rimon;
+ int gimon;
+
+ info = devm_kmemdup(&client->dev, &xdp720_info, sizeof(*info),
+ GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
+
+ ret = i2c_smbus_read_word_data(client, XDP720_TELEMETRY_AVG);
+ if (ret < 0) {
+ dev_err(&client->dev, "Can't get TELEMETRY_AVG\n");
+ return ret;
+ }
+
+ ret >>= 10; /* 10th bit of TELEMETRY_AVG REG for GIMON Value */
+ ret &= GENMASK(0, 0);
+ if (ret == 1)
+ gimon = 18200; /* output gain 18.2 microA/A */
+ else
+ gimon = 9100; /* output gain 9.1 microA/A */
+
+ if (of_property_read_u32(client->dev.of_node,
+ "infineon,rimon-micro-ohms", &rimon))
+ rimon = XDP720_DEFAULT_RIMON; /* Default if not set via DT */
+ if (rimon == 0)
+ return -EINVAL;
+
+ /* Adapt the current and power scale for each instance */
+ info->m[PSC_CURRENT_OUT] = DIV64_U64_ROUND_CLOSEST((u64)
+ info->m[PSC_CURRENT_OUT] * rimon * gimon, 1000000000000);
+ info->m[PSC_POWER] = DIV64_U64_ROUND_CLOSEST((u64)
+ info->m[PSC_POWER] * rimon * gimon, 1000000000000);
+
+ return pmbus_do_probe(client, info);
+}
+
+static const struct of_device_id xdp720_of_match[] = {
+ { .compatible = "infineon,xdp720" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, xdp720_of_match);
+
+static const struct i2c_device_id xdp720_id[] = {
+ { "xdp720" },
+ {}
+};
+MODULE_DEVICE_TABLE(i2c, xdp720_id);
+
+static struct i2c_driver xdp720_driver = {
+ .driver = {
+ .name = "xdp720",
+ .of_match_table = xdp720_of_match,
+ },
+ .probe = xdp720_probe,
+ .id_table = xdp720_id,
+};
+
+module_i2c_driver(xdp720_driver);
+
+MODULE_AUTHOR("Ashish Yadav <ashish.yadav@infineon.com>");
+MODULE_DESCRIPTION("PMBus driver for Infineon XDP720 Digital eFuse Controller");
+MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("PMBUS");
--
2.39.5
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: hwmon/pmbus: Add Infineon XDP720
From: ASHISH YADAV @ 2026-04-01 10:45 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-hwmon, devicetree, linux-kernel, Ashish Yadav
In-Reply-To: <20260401104550.115715-1-Ashish.Yadav@infineon.com>
From: Ashish Yadav <ashish.yadav@infineon.com>
Add documentation for the device tree binding of the XDP720 eFuse.
Signed-off-by: Ashish Yadav <ashish.yadav@infineon.com>
---
This patch introduces a YAML schema describing the required and optional
properties for the XDP720 eFuse device node. It includes details on the
compatible string, register mapping, and rimon-micro-ohms(RIMON).
The RIMON resistance is installed between the Imon pin and the ground
reference.
---
.../bindings/hwmon/pmbus/infineon,xdp720.yaml | 51 +++++++++++++++++++
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml
diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml
new file mode 100644
index 000000000000..bbde8ff92ae9
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+
+$id: http://devicetree.org/schemas/hwmon/pmbus/infineon,xdp720.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Infineon XDP720 Digital eFuse Controller
+
+maintainers:
+ - Ashish Yadav <ashish.yadav@infineon.com>
+
+description: |
+ The XDP720 is an eFuse with integrated current sensor and digital
+ controller. It provides accurate system telemetry (V, I, P, T) and
+ reports analog current at the IMON pin for post-processing.
+
+ Datasheet:
+ https://www.infineon.com/assets/row/public/documents/24/49/infineon-xdp720-001-datasheet-en.pdf
+
+properties:
+ compatible:
+ enum:
+ - infineon,xdp720
+
+ reg:
+ maxItems: 1
+
+ infineon,rimon-micro-ohms:
+ description: |
+ The value of the RIMON resistor, in micro ohms, required to enable
+ the system overcurrent protection.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hwmon@11 {
+ compatible = "infineon,xdp720";
+ reg = <0x11>;
+ infineon,rimon-micro-ohms = <1098000000>; /* 1.098k ohm */
+ };
+ };
--
2.39.5
^ permalink raw reply related
* [PATCH v2 0/2] Add support for Infineon Digital eFuse XDP720
From: ASHISH YADAV @ 2026-04-01 10:45 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-hwmon, devicetree, linux-kernel, Ashish Yadav
From: Ashish Yadav <ashish.yadav@infineon.com>
Hi,
These patches add support for Infineon Digital eFuse XDP720.
XDP720 provides accurate system telemetry (V, I, P, T) and
reports analog current at the IMON pin for post-processing.
The Current and Power measurement depends on the RIMON and GIMON values.
Please look into data sheet sections 5.4.2 and 5.4.4 for more details:
https://www.infineon.com/assets/row/public/documents/24/49/infineon-xdp720-001-datasheet-en.pdf
With Best Regards,
Ashish Yadav
---
Changes in v2:
- Link to v1:
https://lore.kernel.org/all/20260330102345.37065-1-Ashish.Yadav@infineon.com/
- Fix make dt_binding_check issue:
https://patchwork.kernel.org/project/devicetree/patch/20260330102345.37065-2-Ashish.Yadav@infineon.com/
- Address reviews comments for infineon,xdp720.yaml, Kconfig, Makefile and xpe720.c:
https://sashiko.dev/#/patchset/20260330102345.37065-1-Ashish.Yadav%40infineon.com
It includes fixing of extra space, non-ASCII characters and use spaces
instead of tabs.
The xpe720.c driver file update with DIV64_U64_ROUND_CLOSEST() and
MODULE_DEVICE_TABLE() as suggested in review comments.
Ashish Yadav (2):
dt-bindings: hwmon/pmbus: Add Infineon XDP720
hwmon:(pmbus/xdp720) Add support for efuse xdp720
.../bindings/hwmon/pmbus/infineon,xdp720.yaml | 51 ++++++++
drivers/hwmon/pmbus/Kconfig | 9 ++
drivers/hwmon/pmbus/Makefile | 1 +
drivers/hwmon/pmbus/xdp720.c | 123 ++++++++++++++++++
4 files changed, 184 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml
create mode 100644 drivers/hwmon/pmbus/xdp720.c
--
2.39.5
^ permalink raw reply
* Re: [PATCH v4 1/5] dt-bindings: media: qcom,sm8550-iris: Add X1P42100 compatible
From: Bryan O'Donoghue @ 2026-04-01 10:48 UTC (permalink / raw)
To: Wangao Wang, Vikash Garodia, Dikshita Agarwal, Abhinav Kumar,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260401-enable_iris_on_purwa-v4-1-ca784552a3e9@oss.qualcomm.com>
On 01/04/2026 11:24, Wangao Wang wrote:
> Document the new compatible string "qcom,x1p42100-iris".
>
> The x1p42100 SoC integrates the same IRIS video hardware block as SM8550,
> but represents a distinct hardware instance and therefore uses its own
> compatible string.
>
> The x1p42100 variant includes an additional Bitstream Engine (BSE) clock
> that is not present on SM8550. This clock is described explicitly in the
> binding.
>
> Signed-off-by: Wangao Wang <wangao.wang@oss.qualcomm.com>
> ---
> .../bindings/media/qcom,sm8550-iris.yaml | 23 +++++++++++++++++++++-
> 1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> index 9c4b760508b50251ac467ad44a366689260bfc0d..0400ca1bff05dcef6b742c3fbf77e38adca9f280 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> @@ -26,6 +26,7 @@ properties:
> - qcom,qcs8300-iris
> - qcom,sm8550-iris
> - qcom,sm8650-iris
> + - qcom,x1p42100-iris
>
> reg:
> maxItems: 1
> @@ -41,13 +42,16 @@ properties:
> - const: mmcx
>
> clocks:
> - maxItems: 3
> + minItems: 3
> + maxItems: 4
>
> clock-names:
> + minItems: 3
> items:
> - const: iface
> - const: core
> - const: vcodec0_core
> + - const: vcodec0_bse
>
> firmware-name:
> maxItems: 1
> @@ -115,6 +119,23 @@ allOf:
> maxItems: 1
> reset-names:
> maxItems: 1
> + - if:
> + properties:
> + compatible:
> + enum:
> + - qcom,x1p42100-iris
> + then:
> + properties:
> + clocks:
> + minItems: 4
> + clock-names:
> + minItems: 4
> + else:
> + properties:
> + clocks:
> + maxItems: 3
> + clock-names:
> + maxItems: 3
>
> unevaluatedProperties: false
>
>
> --
> 2.43.0
>
LGTM
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
^ permalink raw reply
* Re: [PATCH v5 2/5] media: iris: scale MMCX power domain on SM8250
From: Ulf Hansson @ 2026-04-01 10:46 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Dikshita Agarwal, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Taniya Das, Jonathan Marek, Rafael J. Wysocki,
Bryan O'Donoghue, Vikash Garodia, Mauro Carvalho Chehab,
Stanimir Varbanov, Abhinav Kumar, Hans Verkuil, Stefan Schmidt,
Konrad Dybcio, Bryan O'Donoghue, Dikshita Agarwal,
linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-pm,
linux-media, Mauro Carvalho Chehab
In-Reply-To: <6yfn6ux3gbin2dtopdxxv4okinspueryuey5vfdq633gsewc6r@ttp56brnpgvr>
On Tue, 31 Mar 2026 at 20:46, Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
>
> On Tue, Mar 31, 2026 at 01:33:35PM +0200, Ulf Hansson wrote:
> > On Mon, 30 Mar 2026 at 15:06, Dikshita Agarwal
> > <dikshita.agarwal@oss.qualcomm.com> wrote:
> > >
> > >
> > >
> > > On 3/30/2026 4:45 PM, Dmitry Baryshkov wrote:
> > > > On Mon, Mar 30, 2026 at 10:55:02AM +0530, Dikshita Agarwal wrote:
> > > >>
> > > >>
> > > >> On 2/9/2026 7:02 AM, Dmitry Baryshkov wrote:
> > > >>> On SM8250 most of the video clocks are powered by the MMCX domain, while
> > > >>> the PLL is powered on by the MX domain. Extend the driver to support
> > > >>> scaling both power domains, while keeping compatibility with the
> > > >>> existing DTs, which define only the MX domain.
> > > >>>
> > > >>> Fixes: 79865252acb6 ("media: iris: enable video driver probe of SM8250 SoC")
> > > >>> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> > > >>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > > >>> ---
> > > >>> drivers/media/platform/qcom/iris/iris_platform_gen1.c | 2 +-
> > > >>> drivers/media/platform/qcom/iris/iris_probe.c | 7 +++++++
> > > >>> 2 files changed, 8 insertions(+), 1 deletion(-)
> > > >>>
> > > >>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_gen1.c b/drivers/media/platform/qcom/iris/iris_platform_gen1.c
> > > >>> index df8e6bf9430e..aa71f7f53ee3 100644
> > > >>> --- a/drivers/media/platform/qcom/iris/iris_platform_gen1.c
> > > >>> +++ b/drivers/media/platform/qcom/iris/iris_platform_gen1.c
> > > >>> @@ -281,7 +281,7 @@ static const struct bw_info sm8250_bw_table_dec[] = {
> > > >>>
> > > >>> static const char * const sm8250_pmdomain_table[] = { "venus", "vcodec0" };
> > > >>>
> > > >>> -static const char * const sm8250_opp_pd_table[] = { "mx" };
> > > >>> +static const char * const sm8250_opp_pd_table[] = { "mx", "mmcx" };
> > > >>>
> > > >>> static const struct platform_clk_data sm8250_clk_table[] = {
> > > >>> {IRIS_AXI_CLK, "iface" },
> > > >>> diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
> > > >>> index 7b612ad37e4f..74ec81e3d622 100644
> > > >>> --- a/drivers/media/platform/qcom/iris/iris_probe.c
> > > >>> +++ b/drivers/media/platform/qcom/iris/iris_probe.c
> > > >>> @@ -64,6 +64,13 @@ static int iris_init_power_domains(struct iris_core *core)
> > > >>> return ret;
> > > >>>
> > > >>> ret = devm_pm_domain_attach_list(core->dev, &iris_opp_pd_data, &core->opp_pmdomain_tbl);
> > > >>> + /* backwards compatibility for incomplete ABI SM8250 */
> > > >>> + if (ret == -ENODEV &&
> > > >>> + of_device_is_compatible(core->dev->of_node, "qcom,sm8250-venus")) {
> > > >>> + iris_opp_pd_data.num_pd_names--;
> > > >>> + ret = devm_pm_domain_attach_list(core->dev, &iris_opp_pd_data,
> > > >>> + &core->opp_pmdomain_tbl);
> > > >>> + }
> > > >>> if (ret < 0)
> > > >>> return ret;
> > > >>>
> > > >>>
> > > >>
> > > >> Hitting below compilation error on latest kernel
> > > >>
> > > >> drivers/media/platform/qcom/iris/iris_probe.c: In function
> > > >> ‘iris_init_power_domains’:
> > > >> drivers/media/platform/qcom/iris/iris_probe.c:71:46: error: decrement of
> > > >> read-only member ‘num_pd_names’
> > > >> 71 | iris_opp_pd_data.num_pd_names--;
> > > >
> > > > See commit 7ad7f43e568b ("pmdomain: de-constify fields struct
> > > > dev_pm_domain_attach_data")
> >
> > The intent was for this patch to be part of v7.0-rc1, but I failed
> > with my pull-request to Linus.
> >
> > Instead this will be part of v7.1-rc1, assuming everything goes as expected.
> >
> > Is it possible to drop/defer these changes until v7.2?
>
> It would be very sad.
Right.
Since it's my mistake, let me reconsider. If I rebase my branch and
share the necessary commit through an immutable branch that you can
pull in. Would that work for you?
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH 2/4] platform: arm64: dell-xps-ec: new driver
From: Ilpo Järvinen @ 2026-04-01 10:44 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Aleksandrs Vinarskis, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans de Goede,
Bryan O'Donoghue, linux-arm-msm, devicetree, LKML,
platform-driver-x86, laurentiu.tudor1, Abel Vesa, Tobias Heider,
Val Packett
In-Reply-To: <328acf2d-988e-45b6-9553-240108caa91b@oss.qualcomm.com>
On Wed, 1 Apr 2026, Konrad Dybcio wrote:
> On 4/1/26 9:33 AM, Aleksandrs Vinarskis wrote:
> > Introduce EC driver for Dell XPS 13 9345 (codename 'tributo') which may
> > partially of fully compatible with Snapdragon-based Dell Latitude,
> > Inspiron ('thena'). Primary function of this driver is unblock EC's
> > thermal management, specifically to provide it with necessary
> > information to control device fans, peripherals power.
>
> [...]
>
> > +/*
> > + * Format:
> > + * - header/unknown (2 bytes)
> > + * - per-thermistor entries (3 bytes): thermistor_id, param1, param2
> > + */
> > +static const u8 dell_xps_ec_thermistor_profile[] = {
> > + 0xff, 0x54,
>
> This is super wishful thinking, but 0x54 is ASCII 'T', perhaps for
> "Thermistor" or "Temp"?
>
> > +static int dell_xps_ec_suspend_cmd(struct dell_xps_ec *ec, bool suspend)
> > +{
> > + u8 buf[DELL_XPS_EC_SUSPEND_MSG_LEN] = {};
> > + int ret;
> > +
> > + buf[0] = DELL_XPS_EC_SUSPEND_CMD;
> > + buf[1] = suspend ? 0x01 : 0x00;
> > + /* bytes 2..63 remain zero */
>
> buf[1] = suspend
>
> (since it's a boolean argument)
I'd prefer boolean -> binary conversion is done explicitly.
--
i.
^ permalink raw reply
* Re: [PATCH 2/4] platform: arm64: dell-xps-ec: new driver
From: Ilpo Järvinen @ 2026-04-01 10:41 UTC (permalink / raw)
To: Aleksandrs Vinarskis
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Hans de Goede, Bryan O'Donoghue, linux-arm-msm,
devicetree, LKML, platform-driver-x86, laurentiu.tudor1,
Abel Vesa, Tobias Heider, Val Packett
In-Reply-To: <20260401-dell-xps-9345-ec-v1-2-afa5cacd49be@vinarskis.com>
On Wed, 1 Apr 2026, Aleksandrs Vinarskis wrote:
> Introduce EC driver for Dell XPS 13 9345 (codename 'tributo') which may
> partially of fully compatible with Snapdragon-based Dell Latitude,
> Inspiron ('thena'). Primary function of this driver is unblock EC's
> thermal management, specifically to provide it with necessary
> information to control device fans, peripherals power.
>
> The driver was developed primarily by analyzing ACPI DSDT's _DSM and
> i2c dumps of communication between SoC and EC. Changes to Windows
> driver's behavior include increasing temperature feed loop from ~50ms
> to 100ms here.
>
> While Xps's EC is rather complex and controls practically all device
> peripherals including touch row's brightness and special keys such as
> mic mute, these do not go over this particular i2c interface.
>
> Not yet implemented features:
> - On lid-close IRQ event is registered. Windows performs what to
> appears to be thermistor constants readout, though its not obvious
> what it used for.
> - According to ACPI's _DSM there is a method to readout fans' RPM.
> - Initial thermistor constants were sniffed from Windows, these can be
> likely fine tuned for better cooling performance.
> - There is additional temperature reading that Windows sents to EC but
> more rare than others, likely SoC T_j / TZ98 or TZ4. This is the only
> thermal zone who's reading can exceed 115C without triggering thermal
> shutdown.
> - Given similarities between 'tributo' and 'thena' platforms, including
> EC i2c address, driver can be potentially extended to support both.
>
> Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com>
> ---
> MAINTAINERS | 1 +
> drivers/platform/arm64/Kconfig | 12 ++
> drivers/platform/arm64/Makefile | 1 +
> drivers/platform/arm64/dell-xps-ec.c | 269 +++++++++++++++++++++++++++++++++++
> 4 files changed, 283 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index fe3f2fc4fbc087d8041f97708fbb93722f7d1882..f82c7f6c7377d3f2ff0ae1be263d854749541f03 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7240,6 +7240,7 @@ DELL XPS EMBEDDED CONTROLLER DRIVER
> M: Aleksandrs Vinarskis <alex@vinarskis.com>
> S: Maintained
> F: Documentation/devicetree/bindings/embedded-controller/dell,xps13-9345-ec.yaml
> +F: drivers/platform/arm64/dell-xps-ec.c
>
> DELTA AHE-50DC FAN CONTROL MODULE DRIVER
> M: Zev Weiss <zev@bewilderbeest.net>
> diff --git a/drivers/platform/arm64/Kconfig b/drivers/platform/arm64/Kconfig
> index 10f905d7d6bfa5fad30a0689d3a20481268c781e..0bc8f016032bb05cb3a7cc50bdf1092da04153bc 100644
> --- a/drivers/platform/arm64/Kconfig
> +++ b/drivers/platform/arm64/Kconfig
> @@ -33,6 +33,18 @@ config EC_ACER_ASPIRE1
> laptop where this information is not properly exposed via the
> standard ACPI devices.
>
> +config EC_DELL_XPS
> + tristate "Dell XPS 9345 Embedded Controller driver"
> + depends on ARCH_QCOM || COMPILE_TEST
> + depends on I2C
> + depends on IIO
> + help
> + Driver for the Embedded Controller in the Qualcomm Snapdragon-based
> + Dell XPS 13 9345, which handles thermal management and fan speed
> + control.
> +
> + Say M or Y here to include this support.
> +
> config EC_HUAWEI_GAOKUN
> tristate "Huawei Matebook E Go Embedded Controller driver"
> depends on ARCH_QCOM || COMPILE_TEST
> diff --git a/drivers/platform/arm64/Makefile b/drivers/platform/arm64/Makefile
> index 60c131cff6a15bb51a49c9edab95badf513ee0f6..6768dc6c2310837374e67381cfc729bed1fdaaef 100644
> --- a/drivers/platform/arm64/Makefile
> +++ b/drivers/platform/arm64/Makefile
> @@ -6,6 +6,7 @@
> #
>
> obj-$(CONFIG_EC_ACER_ASPIRE1) += acer-aspire1-ec.o
> +obj-$(CONFIG_EC_DELL_XPS) += dell-xps-ec.o
> obj-$(CONFIG_EC_HUAWEI_GAOKUN) += huawei-gaokun-ec.o
> obj-$(CONFIG_EC_LENOVO_YOGA_C630) += lenovo-yoga-c630.o
> obj-$(CONFIG_EC_LENOVO_THINKPAD_T14S) += lenovo-thinkpad-t14s.o
> diff --git a/drivers/platform/arm64/dell-xps-ec.c b/drivers/platform/arm64/dell-xps-ec.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..5ea8f30931d8b61acbb948d8617dde3681fb8de3
> --- /dev/null
> +++ b/drivers/platform/arm64/dell-xps-ec.c
> @@ -0,0 +1,269 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2026, Aleksandrs Vinarskis <alex@vinarskis.com>
> + */
> +
> +#include <linux/array_size.h>
> +#include <linux/devm-helpers.h>
> +#include <linux/device.h>
> +#include <linux/i2c.h>
> +#include <linux/iio/consumer.h>
> +#include <linux/interrupt.h>
> +#include <linux/module.h>
> +#include <linux/pm.h>
> +#include <linux/workqueue.h>
> +
> +#define DELL_XPS_EC_SUSPEND_CMD 0xb9
> +#define DELL_XPS_EC_SUSPEND_MSG_LEN 64
> +
> +#define DELL_XPS_EC_TEMP_CMD0 0xfb
> +#define DELL_XPS_EC_TEMP_CMD1 0x20
> +#define DELL_XPS_EC_TEMP_CMD3 0x02
> +#define DELL_XPS_EC_TEMP_MSG_LEN 6
> +#define DELL_XPS_EC_TEMP_INTERVAL_MS 100
> +
> +/*
> + * Format:
> + * - header/unknown (2 bytes)
> + * - per-thermistor entries (3 bytes): thermistor_id, param1, param2
> + */
> +static const u8 dell_xps_ec_thermistor_profile[] = {
> + 0xff, 0x54,
> + 0x01, 0x00, 0x2b, /* sys_therm0 */
> + 0x02, 0x44, 0x2a, /* sys_therm1 */
> + 0x03, 0x44, 0x2b, /* sys_therm2 */
> + 0x04, 0x44, 0x28, /* sys_therm3 */
> + 0x05, 0x55, 0x2a, /* sys_therm4 */
> + 0x06, 0x44, 0x26, /* sys_therm5 */
> + 0x07, 0x44, 0x2b, /* sys_therm6 */
> +};
> +
> +/*
> + * Mapping from IIO channel name to EC command byte
> + */
> +static const struct {
> + const char *name;
> + u8 cmd;
> +} dell_xps_ec_therms[] = {
> + /* TODO: 0x01 is sent only occasionally, likely TZ98 or TZ4 */
> + { "sys_therm0", 0x02 },
> + { "sys_therm1", 0x03 },
> + { "sys_therm2", 0x04 },
> + { "sys_therm3", 0x05 },
> + { "sys_therm4", 0x06 },
> + { "sys_therm5", 0x07 },
> + { "sys_therm6", 0x08 },
> +};
> +
> +struct dell_xps_ec {
> + struct device *dev;
> + struct i2c_client *client;
> + struct iio_channel *therm_channels[ARRAY_SIZE(dell_xps_ec_therms)];
> + struct delayed_work temp_work;
> +};
> +
> +static int dell_xps_ec_suspend_cmd(struct dell_xps_ec *ec, bool suspend)
> +{
> + u8 buf[DELL_XPS_EC_SUSPEND_MSG_LEN] = {};
> + int ret;
> +
> + buf[0] = DELL_XPS_EC_SUSPEND_CMD;
> + buf[1] = suspend ? 0x01 : 0x00;
> + /* bytes 2..63 remain zero */
> +
> + ret = i2c_master_send(ec->client, buf, sizeof(buf));
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +
> +static int dell_xps_ec_send_temp(struct dell_xps_ec *ec, u8 cmd_byte,
> + int milli_celsius)
> +{
> + u8 buf[DELL_XPS_EC_TEMP_MSG_LEN];
> + u16 deci_celsius;
> + int ret;
> +
> + /* Convert milli-Celsius to deci-Celsius (Celsius * 10) */
> + deci_celsius = milli_celsius / 100;
> +
> + buf[0] = DELL_XPS_EC_TEMP_CMD0;
> + buf[1] = DELL_XPS_EC_TEMP_CMD1;
> + buf[2] = cmd_byte;
> + buf[3] = DELL_XPS_EC_TEMP_CMD3;
> + buf[4] = deci_celsius & 0xff; /* LSB */
> + buf[5] = (deci_celsius >> 8) & 0xff; /* MSB */
This looks like a 16-bit field so it should be handled as such and with
annotated endianness. One option would be to use a struct so you can use
it as a field.
> + ret = i2c_master_send(ec->client, buf, sizeof(buf));
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +
> +static void dell_xps_ec_temp_work_fn(struct work_struct *work)
> +{
> + struct dell_xps_ec *ec = container_of(work, struct dell_xps_ec,
> + temp_work.work);
> + int val, ret, i;
> +
> + for (i = 0; i < ARRAY_SIZE(dell_xps_ec_therms); i++) {
> + if (!ec->therm_channels[i])
> + continue;
> +
> + ret = iio_read_channel_processed(ec->therm_channels[i], &val);
> + if (ret < 0) {
> + dev_err_ratelimited(ec->dev,
> + "Failed to read thermistor %s: %d\n",
> + dell_xps_ec_therms[i].name, ret);
Add include for dev_err_ratelimited().
> + continue;
> + }
> +
> + ret = dell_xps_ec_send_temp(ec, dell_xps_ec_therms[i].cmd, val);
> + if (ret < 0) {
> + dev_err_ratelimited(ec->dev,
> + "Failed to send temp for %s: %d\n",
> + dell_xps_ec_therms[i].name, ret);
> + }
> + }
> +
> + schedule_delayed_work(&ec->temp_work,
> + msecs_to_jiffies(DELL_XPS_EC_TEMP_INTERVAL_MS));
Add include for msecs_to_jiffies().
> +}
> +
> +static irqreturn_t dell_xps_ec_irq_handler(int irq, void *data)
> +{
> + struct dell_xps_ec *ec = data;
> +
> + /*
> + * TODO: IRQ is fired on lid-close. Follow Windows example to read out
> + * the thermistor thresholds and potentially fan speeds.
> + */
> + dev_info_ratelimited(ec->dev, "IRQ triggered! (irq=%d)\n", irq);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int dell_xps_ec_probe(struct i2c_client *client)
> +{
> + struct device *dev = &client->dev;
> + struct dell_xps_ec *ec;
> + int ret, i;
> +
> + ec = devm_kzalloc(dev, sizeof(*ec), GFP_KERNEL);
> + if (!ec)
> + return -ENOMEM;
> +
> + ec->dev = dev;
> + ec->client = client;
> + i2c_set_clientdata(client, ec);
> +
> + /* Set default thermistor profile */
> + ret = i2c_master_send(client, dell_xps_ec_thermistor_profile,
> + sizeof(dell_xps_ec_thermistor_profile));
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "Failed to set thermistor profile\n");
> +
> + /* Get IIO channels for thermistors */
> + for (i = 0; i < ARRAY_SIZE(dell_xps_ec_therms); i++) {
> + ec->therm_channels[i] = devm_iio_channel_get(dev,
> + dell_xps_ec_therms[i].name);
> + if (IS_ERR(ec->therm_channels[i])) {
Add include.
> + ret = PTR_ERR(ec->therm_channels[i]);
> + ec->therm_channels[i] = NULL;
> + if (ret == -EPROBE_DEFER)
> + return ret;
> + dev_warn(dev, "Thermistor %s not available: %d\n",
> + dell_xps_ec_therms[i].name, ret);
> + }
> + }
> +
> + /* Start periodic temperature reporting */
> + ret = devm_delayed_work_autocancel(dev, &ec->temp_work,
> + dell_xps_ec_temp_work_fn);
> + if (ret)
> + return ret;
> + schedule_delayed_work(&ec->temp_work,
> + msecs_to_jiffies(DELL_XPS_EC_TEMP_INTERVAL_MS));
> + dev_info(dev, "Started periodic temperature reporting to EC every %d ms\n",
> + DELL_XPS_EC_TEMP_INTERVAL_MS);
> +
> + /* Request IRQ for EC events */
> + ret = devm_request_threaded_irq(dev, client->irq, NULL,
> + dell_xps_ec_irq_handler,
> + IRQF_ONESHOT, dev_name(dev), ec);
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "Failed to request IRQ\n");
> +
> + return 0;
> +}
> +
> +/*
> + * Notify EC of suspend
> + *
> + * This will:
> + * - Ramp down the fans
> + * - Cut power to display/trackpad/keyboard/touch row
> + * - Periodically (?) power them back, such that wake-up source still works
> + */
> +static int dell_xps_ec_suspend(struct device *dev)
> +{
> + struct dell_xps_ec *ec = dev_get_drvdata(dev);
> +
> + cancel_delayed_work_sync(&ec->temp_work);
> +
> + return dell_xps_ec_suspend_cmd(ec, true);
> +}
> +
> +/*
> + * Notify EC of resume
> + *
> + * This will undo the suspend actions
> + * Without the resume signal, device would wake up but be forced back into
> + * suspend by EC within seconds
> + */
> +static int dell_xps_ec_resume(struct device *dev)
> +{
> + struct dell_xps_ec *ec = dev_get_drvdata(dev);
> + int ret;
> +
> + ret = dell_xps_ec_suspend_cmd(ec, false);
> + if (ret)
> + return ret;
> +
> + schedule_delayed_work(&ec->temp_work,
> + msecs_to_jiffies(DELL_XPS_EC_TEMP_INTERVAL_MS));
> + return 0;
> +}
> +
> +static const struct of_device_id dell_xps_ec_of_match[] = {
> + { .compatible = "dell,xps13-9345-ec" },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, dell_xps_ec_of_match);
> +
> +static const struct i2c_device_id dell_xps_ec_i2c_id[] = {
> + { "dell-xps-ec" },
> + {}
> +};
> +MODULE_DEVICE_TABLE(i2c, dell_xps_ec_i2c_id);
> +
> +static const struct dev_pm_ops dell_xps_ec_pm_ops = {
> + SYSTEM_SLEEP_PM_OPS(dell_xps_ec_suspend, dell_xps_ec_resume)
> +};
> +
> +static struct i2c_driver dell_xps_ec_driver = {
> + .driver = {
> + .name = "dell-xps-ec",
> + .of_match_table = dell_xps_ec_of_match,
> + .pm = &dell_xps_ec_pm_ops,
> + },
> + .probe = dell_xps_ec_probe,
> + .id_table = dell_xps_ec_i2c_id,
> +};
> +module_i2c_driver(dell_xps_ec_driver);
> +
> +MODULE_AUTHOR("Aleksandrs Vinarskis <alex@vinarskis.com>");
> +MODULE_DESCRIPTION("Dell XPS 13 9345 Embedded Controller");
> +MODULE_LICENSE("GPL");
>
>
--
i.
^ permalink raw reply
* Re: [PATCH 4/6] arm64: dts: qcom: kaanapali-mtp: Enable bluetooth and Wifi
From: Zijun Hu @ 2026-04-01 10:39 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Jingyi Wang, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, aiqun.yu, tingwei.zhang,
trilok.soni, yijie.yang, linux-arm-msm, devicetree, linux-kernel,
20260224-knp-dts-misc-v6-0-79d20dab8a60
In-Reply-To: <ohg7jn4lozqw3lhwmhpx7qyiuw2pmjl7zwv6cbbjmbr2vnnw2e@qz6wbrjynbta>
On 3/30/2026 7:53 PM, Dmitry Baryshkov wrote:
>>> - Is the pin defined in the schema?
>> schema define property 'swctrl-gpios' with description
>> "GPIO line indicating the state of the clock supply to the BT module"
>>
>>> - Is the pin wired in the hardware?
>> pin SW_CTRL is wired in hardware.
> Granted your three answers, it can and should be described in the DT.
>
>> i have below confusions about 'swctrl-gpios' of 'qcom,wcn7850-pmu'
>> which WCN7850 pin is 'swctrl-gpios' mean for ?
>> Why to introduce 'swctrl-gpios' ?
>> what problem does it solve ?
>> how to solve the problem ?
> Please descibe the hardware in the DT. Problem solving belongs to the
> driver.
sorry for not agreeing with your points here.
it is better to correct or remove 'swctrl-gpios' within DT binding spec at least
for 'qcom,wcn7850-pmu' with below reasons:
1) provided that 'swctrl-gpios' is for pin SW_CTRL of datasheet, binding spec's
both description and its expected usage are wrong.
2) its driver does not parse and use the property 'swctrl-gpios', moreover, the
property have no user within upstream DT tree.
3) the property is not mandatory based on binding spec.
4) upstream DT tree have had many such usages as mine which just set default pin
configuration and not specify 'swctrl-gpios' explicitly.
5) kaanapali-mtp is originally preinstalled with android OS which supports some
qualcomm specific feature which have not been supported by up-stream kernel.
so kaanapali-mtp H/W has some wired pins which is not used by up-stream
kernel sometimes
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Krzysztof Kozlowski @ 2026-04-01 10:38 UTC (permalink / raw)
To: Guangliu Ding, Liviu Dudau
Cc: Daniel Baluta (OSS), Daniel Almeida, Alice Ryhl, Boris Brezillon,
Steven Price, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, Jiyu Yang
In-Reply-To: <AM0PR04MB4707335CC7035232D44E6ED9F350A@AM0PR04MB4707.eurprd04.prod.outlook.com>
On 01/04/2026 12:31, Guangliu Ding wrote:
>> Either add the patch(es) that use the compatible to this series in v2, or put a
>> comment in the commit message on where we can see the driver changes.
>>
>
> According to discussions with the GPU vendor, this is a hardware limitation
> of Mali-G310 rather than a hardware bug, and it has been addressed in newer
> Mali GPU families.
>
> In addition, ipa_counters are not enabled in the current Panthor driver. We observed
> this issue with the private Mali DDK where ipa_counters were enabled.
> Therefore, keeping the compatible string is necessary to allow for future divergence.
No one discusses here whether you need separate compatible string.
writing bindings and all my talks are (e.g. DTS 101) are clearly
expecting you.
We discuss only the lack of compatibility in terms of DT, how DT sees
compatible devices.
And lack of driver code is clear indication that devices are compatible
in terms how DT understands it. Feel encouraged to bring actual
arguments in commit msgs in the future.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 7/7] dt-bindings: PCI: intel,lgm-pcie: Add atu resource
From: Rob Herring (Arm) @ 2026-04-01 10:37 UTC (permalink / raw)
To: Florian Eckert
Cc: linux-pci, Eckert.Florian, Rahul Tanwar, linux-kernel,
Lorenzo Pieralisi, Krzysztof Kozlowski, Sajid Dalvi,
Bjorn Helgaas, Manivannan Sadhasivam, Ajay Agarwal, devicetree,
Johan Hovold, Conor Dooley, ms, Krzysztof Wilczyński
In-Reply-To: <20260401-pcie-intel-gw-v3-7-63b008c5b7b2@dev.tdt.de>
On Wed, 01 Apr 2026 11:31:43 +0200, Florian Eckert wrote:
> The 'atu' information is already set in the dwc core, if it is specified
> in the devicetree. The driver uses its own default, if not set in the
> devicetree. This information is hardware specific and should therefore be
> maintained in the devicetree rather than in the source.
>
> To be backward compatibile, this field is not mandatory. If 'atu'
> resource is not specified in the devicetree, the driver’s default value
> is used.
>
> Old DTS entry for PCIe:
>
> reg = <0xd1000000 0x1000>,
> <0xd3000000 0x20000>,
> <0xd0c41000.0x1000>;
> reg-names = "dbi", "config", "app";
>
> New DTS entry for PCIe:
>
> reg = <0xd1000000 0x1000>,
> <0xd10c0000 0x1000>,
> <0xd3000000 0x20000>,
> <0xd0c41000.0x1000>;
> reg-names = "dbi", "atu", "config", "app";
>
> Signed-off-by: Florian Eckert <fe@dev.tdt.de>
> ---
> Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
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/pci/intel-gw-pcie.example.dtb: pcie@d0e00000 (intel,lgm-pcie): reg-names:1: 'config' was expected
from schema $id: http://devicetree.org/schemas/pci/intel-gw-pcie.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pci/intel-gw-pcie.example.dtb: pcie@d0e00000 (intel,lgm-pcie): reg-names:2: 'app' was expected
from schema $id: http://devicetree.org/schemas/pci/intel-gw-pcie.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pci/intel-gw-pcie.example.dtb: pcie@d0e00000 (intel,lgm-pcie): reg-names:3: 'atu' was expected
from schema $id: http://devicetree.org/schemas/pci/intel-gw-pcie.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260401-pcie-intel-gw-v3-7-63b008c5b7b2@dev.tdt.de
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: Re: Re: [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Guangliu Ding @ 2026-04-01 10:31 UTC (permalink / raw)
To: Liviu Dudau
Cc: Daniel Baluta (OSS), Daniel Almeida, Alice Ryhl, Boris Brezillon,
Steven Price, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, Jiyu Yang
In-Reply-To: <aczv0R0aQRmHKdvt@e142607>
Hi Liviu
> On Wed, Apr 01, 2026 at 09:43:12AM +0000, Guangliu Ding wrote:
> > Hi Daniel
> >
> > > On 4/1/26 11:48, Guangliu Ding wrote:
> > > > [You don't often get email from guangliu.ding@nxp.com. Learn why
> > > > this is important at https://aka.ms/LearnAboutSenderIdentification
> > > > ]
> > > >
> > > > Hi Liviu
> > > >
> > > > Thanks for your review. Please refer to my comments below:
> > > >
> > > >> On Tue, Mar 31, 2026 at 06:12:38PM +0800, Guangliu Ding wrote:
> > > >>> Add compatible string of Mali G310 GPU on i.MX952 board.
> > > >>>
> > > >>> Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
> > > >>> Reviewed-by: Jiyu Yang <jiyu.yang@nxp.com>
> > > >>> ---
> > > >>> Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
> > > >>> | 1
> > > >>> +
> > > >>> 1 file changed, 1 insertion(+)
> > > >>>
> > > >>> diff --git
> > > >>> a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yam
> > > >>> l
> > > >> b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
> > > >>> index 8eccd4338a2b..6a10843a26e2 100644
> > > >>> ---
> > > >>> a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yam
> > > >>> l
> > > >>> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf
> > > >>> +++ .yam
> > > >>> +++ l
> > > >>> @@ -20,6 +20,7 @@ properties:
> > > >>> - enum:
> > > >>> - mediatek,mt8196-mali
> > > >>> - nxp,imx95-mali # G310
> > > >>> + - nxp,imx952-mali # G310
> > > >> Can you explain why this is needed? Can it not be covered by the
> > > >> existing compatible?
> > > > There are functional differences in GPU module (GPUMIX) between
> > > > i.MX95 and i.MX952. So they cannot be fully covered by a single existing
> compatible.
> > > > On i.MX952, The GPU clock is controlled by hardware GPU auto
> > > > clock-gating mechanism, while the GPU clock is managed explicitly
> > > > by the
> > > driver on i.MX95.
> > > > Because of these behavioral differences, separate compatible
> > > > strings "nxp,imx95-mali" and "nxp,imx952-mali" are needed to allow
> > > > the driver to handle the two variants independently and to keep
> > > > room for future
> > > divergence.
> > >
> > >
> > > This information should be added in the commit message explaining
> > > why
> > >
> > > the change is needed.
> > >
> > >
> > > But then where is the driver code taking care of these diferences?
> > >
> >
> > Yes. Currently the driver does not require "nxp,imx952-mali" string.
> > However, when GPU ipa_counters are enabled to calculate the GPU
> > busy_time/idle_time for GPU DVFS feature, they will conflict with the
> > hardware GPU auto clock‑gating mechanism, causing GPU clock to remain
> always on.
> > In such cases, ipa_counters need to be disabled so that the GPU auto
> > clock‑gating mechanism can operate normally, using "nxp,imx952-mali"
> string.
>
> OK, I understand that you're following guidance from some other senior
> people on how to upstream patches so you've tried to create the smallest
> patchset to ensure that it gets reviewed and accepted, but in this case we need
> to see the other patches as well to decide if your approach is the right one and
> we do need a separate compatible string.
>
> If enabling GPU ipa_counters causes the clocks to get stuck active, that feels
> like a hardware bug, so figuring out how to handle that is more important than
> adding a compatible string.
>
> Either add the patch(es) that use the compatible to this series in v2, or put a
> comment in the commit message on where we can see the driver changes.
>
According to discussions with the GPU vendor, this is a hardware limitation
of Mali-G310 rather than a hardware bug, and it has been addressed in newer
Mali GPU families.
In addition, ipa_counters are not enabled in the current Panthor driver. We observed
this issue with the private Mali DDK where ipa_counters were enabled.
Therefore, keeping the compatible string is necessary to allow for future divergence.
> Best regards,
> Liviu
>
> --
> ====================
> | I would like to |
> | fix the world, |
> | but they're not |
> | giving me the |
> \ source code! /
> ---------------
> ¯\_(ツ)_/¯
^ permalink raw reply
* [PATCH V4 2/3] dt-bindings: net: Fix Tegra234 MGBE PTP clock
From: Jon Hunter @ 2026-04-01 10:29 UTC (permalink / raw)
To: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding
Cc: netdev, devicetree, linux-tegra, Jon Hunter, Krzysztof Kozlowski
In-Reply-To: <20260401102941.17466-1-jonathanh@nvidia.com>
The PTP clock for the Tegra234 MGBE device is incorrectly named
'ptp-ref' and should be 'ptp_ref'. This is causing the following
warning to be observed on Tegra234 platforms that use this device:
ERR KERN tegra-mgbe 6800000.ethernet eth0: Invalid PTP clock rate
WARNING KERN tegra-mgbe 6800000.ethernet eth0: PTP init failed
Although this constitutes an ABI breakage in the binding for this
device, PTP support has clearly never worked and so fix this now
so we can correct the device-tree for this device. Note that the
MGBE driver still supports the legacy 'ptp-ref' clock name and so
older/existing device-trees will still work, but given that this
is not the correct name, there is no point to advertise this in the
binding.
Fixes: 189c2e5c7669 ("dt-bindings: net: Add Tegra234 MGBE")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
.../devicetree/bindings/net/nvidia,tegra234-mgbe.yaml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/nvidia,tegra234-mgbe.yaml b/Documentation/devicetree/bindings/net/nvidia,tegra234-mgbe.yaml
index 2bd3efff2485..215f14d1897d 100644
--- a/Documentation/devicetree/bindings/net/nvidia,tegra234-mgbe.yaml
+++ b/Documentation/devicetree/bindings/net/nvidia,tegra234-mgbe.yaml
@@ -42,7 +42,7 @@ properties:
- const: mgbe
- const: mac
- const: mac-divider
- - const: ptp-ref
+ - const: ptp_ref
- const: rx-input-m
- const: rx-input
- const: tx
@@ -133,7 +133,7 @@ examples:
<&bpmp TEGRA234_CLK_MGBE0_RX_PCS_M>,
<&bpmp TEGRA234_CLK_MGBE0_RX_PCS>,
<&bpmp TEGRA234_CLK_MGBE0_TX_PCS>;
- clock-names = "mgbe", "mac", "mac-divider", "ptp-ref", "rx-input-m",
+ clock-names = "mgbe", "mac", "mac-divider", "ptp_ref", "rx-input-m",
"rx-input", "tx", "eee-pcs", "rx-pcs-input", "rx-pcs-m",
"rx-pcs", "tx-pcs";
resets = <&bpmp TEGRA234_RESET_MGBE0_MAC>,
--
2.43.0
^ permalink raw reply related
* [PATCH V4 3/3] arm64: tegra: Fix Tegra234 MGBE PTP clock
From: Jon Hunter @ 2026-04-01 10:29 UTC (permalink / raw)
To: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding
Cc: netdev, devicetree, linux-tegra, Jon Hunter, Krzysztof Kozlowski
In-Reply-To: <20260401102941.17466-1-jonathanh@nvidia.com>
The Tegra MGBE PTP clock is incorrectly named as 'ptp-ref' and not
'ptp_ref' and this causing the initialisation of the PTP clock to fail.
The device-tree binding doc for the device and the Tegra MGBE driver
have been updated to use the correct name and so update the device-tree
for Tegra234 as well.
Fixes: 610cdf3186bc ("arm64: tegra: Add MGBE nodes on Tegra234")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
arch/arm64/boot/dts/nvidia/tegra234.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra234.dtsi b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
index 04a95b6658ca..18220cdac9f9 100644
--- a/arch/arm64/boot/dts/nvidia/tegra234.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
@@ -3605,7 +3605,7 @@ ethernet@6800000 {
<&bpmp TEGRA234_CLK_MGBE0_RX_PCS_M>,
<&bpmp TEGRA234_CLK_MGBE0_RX_PCS>,
<&bpmp TEGRA234_CLK_MGBE0_TX_PCS>;
- clock-names = "mgbe", "mac", "mac-divider", "ptp-ref", "rx-input-m",
+ clock-names = "mgbe", "mac", "mac-divider", "ptp_ref", "rx-input-m",
"rx-input", "tx", "eee-pcs", "rx-pcs-input", "rx-pcs-m",
"rx-pcs", "tx-pcs";
resets = <&bpmp TEGRA234_RESET_MGBE0_MAC>,
@@ -3647,7 +3647,7 @@ ethernet@6900000 {
<&bpmp TEGRA234_CLK_MGBE1_RX_PCS_M>,
<&bpmp TEGRA234_CLK_MGBE1_RX_PCS>,
<&bpmp TEGRA234_CLK_MGBE1_TX_PCS>;
- clock-names = "mgbe", "mac", "mac-divider", "ptp-ref", "rx-input-m",
+ clock-names = "mgbe", "mac", "mac-divider", "ptp_ref", "rx-input-m",
"rx-input", "tx", "eee-pcs", "rx-pcs-input", "rx-pcs-m",
"rx-pcs", "tx-pcs";
resets = <&bpmp TEGRA234_RESET_MGBE1_MAC>,
@@ -3689,7 +3689,7 @@ ethernet@6a00000 {
<&bpmp TEGRA234_CLK_MGBE2_RX_PCS_M>,
<&bpmp TEGRA234_CLK_MGBE2_RX_PCS>,
<&bpmp TEGRA234_CLK_MGBE2_TX_PCS>;
- clock-names = "mgbe", "mac", "mac-divider", "ptp-ref", "rx-input-m",
+ clock-names = "mgbe", "mac", "mac-divider", "ptp_ref", "rx-input-m",
"rx-input", "tx", "eee-pcs", "rx-pcs-input", "rx-pcs-m",
"rx-pcs", "tx-pcs";
resets = <&bpmp TEGRA234_RESET_MGBE2_MAC>,
@@ -3731,7 +3731,7 @@ ethernet@6b00000 {
<&bpmp TEGRA234_CLK_MGBE3_RX_PCS_M>,
<&bpmp TEGRA234_CLK_MGBE3_RX_PCS>,
<&bpmp TEGRA234_CLK_MGBE3_TX_PCS>;
- clock-names = "mgbe", "mac", "mac-divider", "ptp-ref", "rx-input-m",
+ clock-names = "mgbe", "mac", "mac-divider", "ptp_ref", "rx-input-m",
"rx-input", "tx", "eee-pcs", "rx-pcs-input", "rx-pcs-m",
"rx-pcs", "tx-pcs";
resets = <&bpmp TEGRA234_RESET_MGBE3_MAC>,
--
2.43.0
^ permalink raw reply related
* [PATCH V4 0/3] net: stmmac: Fix Tegra234 MGBE clock
From: Jon Hunter @ 2026-04-01 10:29 UTC (permalink / raw)
To: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding
Cc: netdev, devicetree, linux-tegra, Jon Hunter
The name of the PTP ref clock for the Tegra234 MGBE ethernet controller
does not match the generic name in the stmmac platform driver. Despite
this basic ethernet is functional on the Tegra234 platforms that use
this driver and as far as I know, we have not tested PTP support with
this driver. Hence, the risk of breaking any functionality is low.
The previous attempt to fix this in the stmmac platform driver, by
supporting the Tegra234 PTP clock name, was rejected [0]. The preference
from the netdev maintainers is to fix this in the DT binding for
Tegra234.
This series fixes this by correcting the device-tree binding to align
with the generic name for the PTP clock. I understand that this is
breaking the ABI for this device, which we should never do, but this
is a last resort for getting this fixed. I am open to any better ideas
to fix this. Please note that we still maintain backward compatibility
in the driver to allow older device-trees to work, but we don't
advertise this via the binding, because I did not see any value in doing
so.
Changes since V3:
- Added Krzysztof's reviewed-by for device-tree changes.
- Re-worked logic in MGBE driver for detecting the legacy clock to make
it more explicit and clear.
Changes since V2:
- Corrected example in dt-binding doc.
Changes since V1:
- Moved handling of different PTP clock names into Tegra234 MGBE driver.
- Add changes to update the Tegra234 MGBE DT binding and DT source.
[0] https://lore.kernel.org/linux-tegra/20250612062032.293275-1-jonathanh@nvidia.com/
Jon Hunter (3):
net: stmmac: Fix PTP ref clock for Tegra234
dt-bindings: net: Fix Tegra234 MGBE PTP clock
arm64: tegra: Fix Tegra234 MGBE PTP clock
.../bindings/net/nvidia,tegra234-mgbe.yaml | 4 ++--
arch/arm64/boot/dts/nvidia/tegra234.dtsi | 8 ++++----
.../net/ethernet/stmicro/stmmac/dwmac-tegra.c | 20 +++++++++++++++++--
3 files changed, 24 insertions(+), 8 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH V4 1/3] net: stmmac: Fix PTP ref clock for Tegra234
From: Jon Hunter @ 2026-04-01 10:29 UTC (permalink / raw)
To: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding
Cc: netdev, devicetree, linux-tegra, Jon Hunter
In-Reply-To: <20260401102941.17466-1-jonathanh@nvidia.com>
Since commit 030ce919e114 ("net: stmmac: make sure that ptp_rate is not
0 before configuring timestamping") was added the following error is
observed on Tegra234:
ERR KERN tegra-mgbe 6800000.ethernet eth0: Invalid PTP clock rate
WARNING KERN tegra-mgbe 6800000.ethernet eth0: PTP init failed
It turns out that the Tegra234 device-tree binding defines the PTP ref
clock name as 'ptp-ref' and not 'ptp_ref' and the above commit now
exposes this and that the PTP clock is not configured correctly.
In order to update device-tree to use the correct 'ptp_ref' name, update
the Tegra MGBE driver to use 'ptp_ref' by default and fallback to using
'ptp-ref' if this clock name is present.
Fixes: d8ca113724e7 ("net: stmmac: tegra: Add MGBE support")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
---
.../net/ethernet/stmicro/stmmac/dwmac-tegra.c | 20 +++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c
index b4b39e6a169e..3af2f001fada 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c
@@ -9,7 +9,7 @@
#include "stmmac_platform.h"
static const char *const mgbe_clks[] = {
- "rx-pcs", "tx", "tx-pcs", "mac-divider", "mac", "mgbe", "ptp-ref", "mac"
+ "rx-pcs", "tx", "tx-pcs", "mac-divider", "mac", "mgbe", "ptp_ref", "mac"
};
struct tegra_mgbe {
@@ -216,6 +216,7 @@ static int tegra_mgbe_probe(struct platform_device *pdev)
struct plat_stmmacenet_data *plat;
struct stmmac_resources res;
struct tegra_mgbe *mgbe;
+ bool use_legacy_ptp = false;
int irq, err, i;
u32 value;
@@ -257,9 +258,24 @@ static int tegra_mgbe_probe(struct platform_device *pdev)
if (!mgbe->clks)
return -ENOMEM;
- for (i = 0; i < ARRAY_SIZE(mgbe_clks); i++)
+ /*
+ * Older device-trees use 'ptp-ref' rather than 'ptp_ref'.
+ * Fall back when the legacy name is present.
+ */
+ if (of_property_match_string(pdev->dev.of_node, "clock-names",
+ "ptp-ref") >= 0)
+ use_legacy_ptp = true;
+
+ for (i = 0; i < ARRAY_SIZE(mgbe_clks); i++) {
mgbe->clks[i].id = mgbe_clks[i];
+ if (use_legacy_ptp && !strcmp(mgbe_clks[i], "ptp_ref")) {
+ dev_warn(mgbe->dev,
+ "Device-tree update needed for PTP clock!\n");
+ mgbe->clks[i].id = "ptp-ref";
+ }
+ }
+
err = devm_clk_bulk_get(mgbe->dev, ARRAY_SIZE(mgbe_clks), mgbe->clks);
if (err < 0)
return err;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 6/6] arm64: dts: qcom: milos: Add Adreno 810 GPU and GMU nodes
From: Konrad Dybcio @ 2026-04-01 10:29 UTC (permalink / raw)
To: Alexander Koskovich, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Akhil P Oommen, Bjorn Andersson
Cc: Luca Weiss, linux-arm-msm, dri-devel, freedreno, devicetree,
linux-kernel
In-Reply-To: <20260331-adreno-810-v1-6-725801dbb12b@pm.me>
On 4/1/26 4:17 AM, Alexander Koskovich wrote:
> Add GPU and GMU devicetree nodes for the Adreno 810 GPU found on
> Qualcomm SM7635 (Milos) based devices.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v9 5/6] reset: rzv2h-usb2phy: Convert to regmap API
From: Tommaso Merciai @ 2026-04-01 10:25 UTC (permalink / raw)
To: Philipp Zabel
Cc: tomm.merciai, peda, linux-renesas-soc, biju.das.jz,
Fabrizio Castro, Lad Prabhakar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm, Greg Kroah-Hartman,
Josua Mayer, Ulf Hansson, devicetree, linux-kernel
In-Reply-To: <7b5c5300921c9d7c931389400cdf6fb2b74ae3ea.camel@pengutronix.de>
Hi Philipp,
Thanks for your comments.
On Wed, Apr 01, 2026 at 11:25:52AM +0200, Philipp Zabel wrote:
> On Mi, 2026-04-01 at 11:10 +0200, Tommaso Merciai wrote:
> [...]
> >
> > Then we can have:
> >
> > static const struct reg_sequence rzv2h_init_seq[] = {
> > { .reg = 0xc10, .def = 0x67c },
> > { .reg = 0xc14, .def = 0x01f },
> > { .reg = 0x600, .def = 0x909 },
> > };
> >
> > static const struct reg_sequence rzv2h_assert_seq[] = {
> > { .reg = 0xb04, .def = 0x303 },
> > { .reg = 0x000, .def = 0x206, .delay_us = 20 },
>
> This will call fsleep(20), which maps to usleep_range(20, 25).
> Please comment on why the delay is changed in the commit message.
Ouch, thanks.
Reference Manual says:
- This reset must be asserted for more than 10us.
Then I think the right choiche would be:
.delay_us = 11
This will call fsleep(11) which maps usleep_range(11, 13)
Please correct me if I'm wrong.
Thanks,
Tommaso
>
> regards
> Philipp
^ permalink raw reply
* [PATCH v4 5/5] arm64: dts: qcom: purwa-iot-som: enable video
From: Wangao Wang @ 2026-04-01 10:24 UTC (permalink / raw)
To: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel, Wangao Wang,
Dmitry Baryshkov, Konrad Dybcio
In-Reply-To: <20260401-enable_iris_on_purwa-v4-0-ca784552a3e9@oss.qualcomm.com>
Enable video nodes on the purwa-iot-som board.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Wangao Wang <wangao.wang@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/purwa-iot-som.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/purwa-iot-som.dtsi b/arch/arm64/boot/dts/qcom/purwa-iot-som.dtsi
index 394e65518ac5037e5c7c50583acefc0dbc8ebb47..ff8621f8750584636ad781467f9c35ace2354e4c 100644
--- a/arch/arm64/boot/dts/qcom/purwa-iot-som.dtsi
+++ b/arch/arm64/boot/dts/qcom/purwa-iot-som.dtsi
@@ -389,6 +389,10 @@ &gpu_zap_shader {
firmware-name = "qcom/x1p42100/gen71500_zap.mbn";
};
+&iris {
+ status = "okay";
+};
+
&pcie3 {
pinctrl-0 = <&pcie3_default>;
pinctrl-names = "default";
--
2.43.0
^ permalink raw reply related
* [PATCH v4 4/5] arm64: dts: qcom: purwa: Override Iris clocks and operating points
From: Wangao Wang @ 2026-04-01 10:24 UTC (permalink / raw)
To: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel, Wangao Wang,
Konrad Dybcio
In-Reply-To: <20260401-enable_iris_on_purwa-v4-0-ca784552a3e9@oss.qualcomm.com>
The Iris block on X1P differs from SM8550/X1E in its clock configuration
and requires a dedicated OPP table. The node inherited from the X1E cannot
be reused directly, and the fallback compatible "qcom,sm8550-iris" cannot
be applied.
Override the inherited clocks, clock-names, and operating points, and
replaces them with the X1P42100-specific definitions. A new OPP table
is provided to support the correct performance levels on this platform.
Depends-on: https://lore.kernel.org/all/20260331-purwa-videocc-camcc-v3-0-6daca180a4b1@oss.qualcomm.com/
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Wangao Wang <wangao.wang@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/purwa.dtsi | 50 +++++++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/purwa.dtsi b/arch/arm64/boot/dts/qcom/purwa.dtsi
index 70e37fa91f5db83e66f9706b62637f6e18dffa89..c2f4457b83e193cff20120c50b53bf4c67e57239 100644
--- a/arch/arm64/boot/dts/qcom/purwa.dtsi
+++ b/arch/arm64/boot/dts/qcom/purwa.dtsi
@@ -21,6 +21,7 @@
/delete-node/ &cpu_pd11;
/delete-node/ &gpu_opp_table;
/delete-node/ &gpu_speed_bin;
+/delete-node/ &iris_opp_table;
/delete-node/ &pcie3_phy;
/delete-node/ &thermal_aoss3;
/delete-node/ &thermal_cpu2_0_btm;
@@ -167,6 +168,55 @@ &gpucc {
compatible = "qcom,x1p42100-gpucc";
};
+&iris {
+ compatible = "qcom,x1p42100-iris";
+
+ clocks = <&gcc GCC_VIDEO_AXI0_CLK>,
+ <&videocc VIDEO_CC_MVS0C_CLK>,
+ <&videocc VIDEO_CC_MVS0_CLK>,
+ <&videocc VIDEO_CC_MVS0_BSE_CLK>;
+ clock-names = "iface",
+ "core",
+ "vcodec0_core",
+ "vcodec0_bse";
+
+ operating-points-v2 = <&iris_opp_table_x1p42100>;
+
+ iris_opp_table_x1p42100: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-210000000 {
+ opp-hz = /bits/ 64 <210000000 105000000>;
+ required-opps = <&rpmhpd_opp_low_svs_d1>,
+ <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000 150000000>;
+ required-opps = <&rpmhpd_opp_low_svs_d1>,
+ <&rpmhpd_opp_svs>;
+ };
+
+ opp-335000000 {
+ opp-hz = /bits/ 64 <335000000 167500000>;
+ required-opps = <&rpmhpd_opp_svs>,
+ <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-424000000 {
+ opp-hz = /bits/ 64 <424000000 212000000>;
+ required-opps = <&rpmhpd_opp_svs>,
+ <&rpmhpd_opp_nom>;
+ };
+
+ opp-500000000 {
+ opp-hz = /bits/ 64 <500000000 250000000>;
+ required-opps = <&rpmhpd_opp_svs>,
+ <&rpmhpd_opp_turbo>;
+ };
+ };
+};
+
/* PCIe3 has half the lanes compared to X1E80100 */
&pcie3 {
num-lanes = <4>;
--
2.43.0
^ permalink raw reply related
* [PATCH v4 3/5] media: iris: Add platform data for X1P42100
From: Wangao Wang @ 2026-04-01 10:24 UTC (permalink / raw)
To: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel, Wangao Wang
In-Reply-To: <20260401-enable_iris_on_purwa-v4-0-ca784552a3e9@oss.qualcomm.com>
Introduce platform data for X1P42100, derived from SM8550 but using a
different clock configuration and a dedicated OPP setup.
Signed-off-by: Wangao Wang <wangao.wang@oss.qualcomm.com>
---
.../platform/qcom/iris/iris_platform_common.h | 1 +
.../media/platform/qcom/iris/iris_platform_gen2.c | 97 ++++++++++++++++++++++
.../platform/qcom/iris/iris_platform_x1p42100.h | 22 +++++
drivers/media/platform/qcom/iris/iris_probe.c | 4 +
4 files changed, 124 insertions(+)
diff --git a/drivers/media/platform/qcom/iris/iris_platform_common.h b/drivers/media/platform/qcom/iris/iris_platform_common.h
index 5a489917580eb10022fdcb52f7321a915e8b239d..2e97360ddcd56a4b61fb296782b0c914b6154784 100644
--- a/drivers/media/platform/qcom/iris/iris_platform_common.h
+++ b/drivers/media/platform/qcom/iris/iris_platform_common.h
@@ -47,6 +47,7 @@ extern const struct iris_platform_data sm8250_data;
extern const struct iris_platform_data sm8550_data;
extern const struct iris_platform_data sm8650_data;
extern const struct iris_platform_data sm8750_data;
+extern const struct iris_platform_data x1p42100_data;
enum platform_clk_type {
IRIS_AXI_CLK, /* AXI0 in case of platforms with multiple AXI clocks */
diff --git a/drivers/media/platform/qcom/iris/iris_platform_gen2.c b/drivers/media/platform/qcom/iris/iris_platform_gen2.c
index 5da90d47f9c6eab4a7e6b17841fdc0e599397bf7..aac72900c0292040500ec4dcde9bd6e7da225fd4 100644
--- a/drivers/media/platform/qcom/iris/iris_platform_gen2.c
+++ b/drivers/media/platform/qcom/iris/iris_platform_gen2.c
@@ -15,6 +15,7 @@
#include "iris_platform_qcs8300.h"
#include "iris_platform_sm8650.h"
#include "iris_platform_sm8750.h"
+#include "iris_platform_x1p42100.h"
#define VIDEO_ARCH_LX 1
#define BITRATE_MAX 245000000
@@ -1317,3 +1318,99 @@ const struct iris_platform_data qcs8300_data = {
.enc_op_int_buf_tbl = sm8550_enc_op_int_buf_tbl,
.enc_op_int_buf_tbl_size = ARRAY_SIZE(sm8550_enc_op_int_buf_tbl),
};
+
+const struct iris_platform_data x1p42100_data = {
+ .get_instance = iris_hfi_gen2_get_instance,
+ .init_hfi_command_ops = iris_hfi_gen2_command_ops_init,
+ .init_hfi_response_ops = iris_hfi_gen2_response_ops_init,
+ .get_vpu_buffer_size = iris_vpu_buf_size,
+ .vpu_ops = &iris_vpu3_purwa_ops,
+ .set_preset_registers = iris_set_sm8550_preset_registers,
+ .icc_tbl = sm8550_icc_table,
+ .icc_tbl_size = ARRAY_SIZE(sm8550_icc_table),
+ .clk_rst_tbl = sm8550_clk_reset_table,
+ .clk_rst_tbl_size = ARRAY_SIZE(sm8550_clk_reset_table),
+ .bw_tbl_dec = sm8550_bw_table_dec,
+ .bw_tbl_dec_size = ARRAY_SIZE(sm8550_bw_table_dec),
+ .pmdomain_tbl = sm8550_pmdomain_table,
+ .pmdomain_tbl_size = ARRAY_SIZE(sm8550_pmdomain_table),
+ .opp_pd_tbl = sm8550_opp_pd_table,
+ .opp_pd_tbl_size = ARRAY_SIZE(sm8550_opp_pd_table),
+ .clk_tbl = x1p42100_clk_table,
+ .clk_tbl_size = ARRAY_SIZE(x1p42100_clk_table),
+ .opp_clk_tbl = x1p42100_opp_clk_table,
+ /* Upper bound of DMA address range */
+ .dma_mask = 0xe0000000 - 1,
+ .fwname = "qcom/vpu/vpu30_p4.mbn",
+ .pas_id = IRIS_PAS_ID,
+ .inst_iris_fmts = platform_fmts_sm8550_dec,
+ .inst_iris_fmts_size = ARRAY_SIZE(platform_fmts_sm8550_dec),
+ .inst_caps = &platform_inst_cap_sm8550,
+ .inst_fw_caps_dec = inst_fw_cap_sm8550_dec,
+ .inst_fw_caps_dec_size = ARRAY_SIZE(inst_fw_cap_sm8550_dec),
+ .inst_fw_caps_enc = inst_fw_cap_sm8550_enc,
+ .inst_fw_caps_enc_size = ARRAY_SIZE(inst_fw_cap_sm8550_enc),
+ .tz_cp_config_data = tz_cp_config_sm8550,
+ .tz_cp_config_data_size = ARRAY_SIZE(tz_cp_config_sm8550),
+ .core_arch = VIDEO_ARCH_LX,
+ .hw_response_timeout = HW_RESPONSE_TIMEOUT_VALUE,
+ .ubwc_config = &ubwc_config_sm8550,
+ .num_vpp_pipe = 1,
+ .max_session_count = 16,
+ .max_core_mbpf = NUM_MBS_8K * 2,
+ .max_core_mbps = ((7680 * 4320) / 256) * 60,
+ .dec_input_config_params_default =
+ sm8550_vdec_input_config_params_default,
+ .dec_input_config_params_default_size =
+ ARRAY_SIZE(sm8550_vdec_input_config_params_default),
+ .dec_input_config_params_hevc =
+ sm8550_vdec_input_config_param_hevc,
+ .dec_input_config_params_hevc_size =
+ ARRAY_SIZE(sm8550_vdec_input_config_param_hevc),
+ .dec_input_config_params_vp9 =
+ sm8550_vdec_input_config_param_vp9,
+ .dec_input_config_params_vp9_size =
+ ARRAY_SIZE(sm8550_vdec_input_config_param_vp9),
+ .dec_input_config_params_av1 =
+ sm8550_vdec_input_config_param_av1,
+ .dec_input_config_params_av1_size =
+ ARRAY_SIZE(sm8550_vdec_input_config_param_av1),
+ .dec_output_config_params =
+ sm8550_vdec_output_config_params,
+ .dec_output_config_params_size =
+ ARRAY_SIZE(sm8550_vdec_output_config_params),
+
+ .enc_input_config_params =
+ sm8550_venc_input_config_params,
+ .enc_input_config_params_size =
+ ARRAY_SIZE(sm8550_venc_input_config_params),
+ .enc_output_config_params =
+ sm8550_venc_output_config_params,
+ .enc_output_config_params_size =
+ ARRAY_SIZE(sm8550_venc_output_config_params),
+
+ .dec_input_prop = sm8550_vdec_subscribe_input_properties,
+ .dec_input_prop_size = ARRAY_SIZE(sm8550_vdec_subscribe_input_properties),
+ .dec_output_prop_avc = sm8550_vdec_subscribe_output_properties_avc,
+ .dec_output_prop_avc_size =
+ ARRAY_SIZE(sm8550_vdec_subscribe_output_properties_avc),
+ .dec_output_prop_hevc = sm8550_vdec_subscribe_output_properties_hevc,
+ .dec_output_prop_hevc_size =
+ ARRAY_SIZE(sm8550_vdec_subscribe_output_properties_hevc),
+ .dec_output_prop_vp9 = sm8550_vdec_subscribe_output_properties_vp9,
+ .dec_output_prop_vp9_size =
+ ARRAY_SIZE(sm8550_vdec_subscribe_output_properties_vp9),
+ .dec_output_prop_av1 = sm8550_vdec_subscribe_output_properties_av1,
+ .dec_output_prop_av1_size =
+ ARRAY_SIZE(sm8550_vdec_subscribe_output_properties_av1),
+
+ .dec_ip_int_buf_tbl = sm8550_dec_ip_int_buf_tbl,
+ .dec_ip_int_buf_tbl_size = ARRAY_SIZE(sm8550_dec_ip_int_buf_tbl),
+ .dec_op_int_buf_tbl = sm8550_dec_op_int_buf_tbl,
+ .dec_op_int_buf_tbl_size = ARRAY_SIZE(sm8550_dec_op_int_buf_tbl),
+
+ .enc_ip_int_buf_tbl = sm8550_enc_ip_int_buf_tbl,
+ .enc_ip_int_buf_tbl_size = ARRAY_SIZE(sm8550_enc_ip_int_buf_tbl),
+ .enc_op_int_buf_tbl = sm8550_enc_op_int_buf_tbl,
+ .enc_op_int_buf_tbl_size = ARRAY_SIZE(sm8550_enc_op_int_buf_tbl),
+};
diff --git a/drivers/media/platform/qcom/iris/iris_platform_x1p42100.h b/drivers/media/platform/qcom/iris/iris_platform_x1p42100.h
new file mode 100644
index 0000000000000000000000000000000000000000..d89acfbc1233dad0692f6c13c3fc22b10e5bdd80
--- /dev/null
+++ b/drivers/media/platform/qcom/iris/iris_platform_x1p42100.h
@@ -0,0 +1,22 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#ifndef __IRIS_PLATFORM_X1P42100_H__
+#define __IRIS_PLATFORM_X1P42100_H__
+
+static const struct platform_clk_data x1p42100_clk_table[] = {
+ {IRIS_AXI_CLK, "iface" },
+ {IRIS_CTRL_CLK, "core" },
+ {IRIS_HW_CLK, "vcodec0_core" },
+ {IRIS_BSE_HW_CLK, "vcodec0_bse" },
+};
+
+static const char *const x1p42100_opp_clk_table[] = {
+ "vcodec0_core",
+ "vcodec0_bse",
+ NULL,
+};
+
+#endif
diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
index ddaacda523ecb9990af0dd0640196223fbcc2cab..287f615dfa6479964ed68649f2829b5bbeed6cd6 100644
--- a/drivers/media/platform/qcom/iris/iris_probe.c
+++ b/drivers/media/platform/qcom/iris/iris_probe.c
@@ -374,6 +374,10 @@ static const struct of_device_id iris_dt_match[] = {
.compatible = "qcom,sm8750-iris",
.data = &sm8750_data,
},
+ {
+ .compatible = "qcom,x1p42100-iris",
+ .data = &x1p42100_data,
+ },
{ },
};
MODULE_DEVICE_TABLE(of, iris_dt_match);
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox