* [PATCH v12 0/5] iio: adc: add Versal SysMon driver
From: Salih Erim @ 2026-06-24 14:37 UTC (permalink / raw)
To: jic23, andy
Cc: dlechner, nuno.sa, robh, krzk+dt, conor+dt, conall.ogriofa,
michal.simek, sai.krishna.potthuri, linux, erimsalih, git,
linux-iio, devicetree, linux-kernel, Salih Erim
This series adds a new IIO driver for the AMD/Xilinx Versal System
Monitor (SysMon), providing on-chip voltage and temperature monitoring.
The Versal SysMon measures up to 160 supply voltages and reads up to
64 temperature satellites distributed across the SoC. The hardware
also provides aggregated device temperature registers: the current
max and min across all active satellites, and peak/trough values
recorded since last hardware reset. The device can be accessed via
memory-mapped I/O or via an I2C interface.
The driver is split into a bus-agnostic core module using the regmap
API, an MMIO platform driver, and an I2C driver. This allows the
same IIO logic to be shared across different bus transports.
Note: Sai Krishna Potthuri is added as co-maintainer and will be
actively taking over the upstream maintenance of this driver going
forward. Please direct any future review feedback to him.
Previous submissions:
v11: https://lore.kernel.org/all/20260623014036.3865402-1-salih.erim@amd.com/
v10: https://lore.kernel.org/all/20260618101414.3462934-1-salih.erim@amd.com/
v9: https://lore.kernel.org/all/20260617180147.3370346-1-salih.erim@amd.com/
v8: https://lore.kernel.org/all/20260616131559.3029543-1-salih.erim@amd.com/
v7: https://lore.kernel.org/all/20260614233722.2603459-1-salih.erim@amd.com/
v6: https://lore.kernel.org/all/20260611222738.2035062-1-salih.erim@amd.com/
v5: https://lore.kernel.org/all/20260608183801.1257051-1-salih.erim@amd.com/
v4: https://lore.kernel.org/all/20260606051707.535281-1-salih.erim@amd.com/
v3: https://lore.kernel.org/all/20260527114211.174288-1-salih.erim@amd.com/
v2: https://lore.kernel.org/all/20260502111951.538488-1-salih.erim@amd.com/
v1: https://lore.kernel.org/all/cover.1757061697.git.michal.simek@amd.com/
Changes in v12:
- Add Sai Krishna Potthuri as co-maintainer in MAINTAINERS
Changes in v11:
- Add input validation for threshold event writes and clamp
computed lower threshold to Q8.7 range (Jonathan, Sashiko)
- Add oversampling info_mask to static temp channels (Jonathan)
Changes in v10:
- Address Andy v9 nit-picks: limits.h for IWYU, variable
declaration grouping in P2 (Andy)
Changes in v9:
- Address Andy v8 review items: symbol namespace, function
signature joins, minmax.h, variable naming consistency,
num_static move to P2 (Andy)
Changes in v8:
- Address Andy v7 review items: MILLIDEGREE_PER_DEGREE, overflow.h,
devm_versal_sysmon_core_probe rename, volatile register comment,
regmap_test_bits, unsigned int for osr_write, ~0 instead of
~0U (Andy)
- Fix devm teardown race in interrupt cleanup (Sashiko)
Changes in v7:
- Move TEMP event onto channel 0; drop OT as separate IIO
channel; use single temp_channels array with runtime event
attachment (Jonathan)
- Return administrative state from temp_mask in read_event_config
instead of transient hardware IMR (Jonathan, Sashiko)
- Add devm cleanup to mask HW interrupts on driver unbind (Sashiko)
- Add documentation comment for static aggregate temp channels
(Jonathan)
- Split sysmon_osr_write into per-type helpers (Jonathan)
Changes in v6:
- Address all Andy v5 review items: switch(chan->type) in event
functions, reversed xmas tree ordering, macro brace placement,
scoped_guard in unmask worker, combined regmap error checks,
join single-line constructs, IWYU header fixes (Andy)
- Fix fwnode_irq_get() to propagate only -EPROBE_DEFER; treating
all negatives as fatal broke probe on I2C nodes without
interrupts property
Changes in v5:
- Core: add err.h include (IWYU) (Andy)
- Core: drop (int) cast on MILLI in scale assignment (Andy)
- Core: sign_extend32() instead of (s16) cast (Andy)
- Core: remove unneeded parentheses in voltage address
calculation (Andy)
- Core: drop NULL checks before fwnode_get_child_node_count
(NULL-aware) (Andy)
- Core: nested size_add() for overflow-safe allocation (Andy)
- Core: if (ret) instead of if (ret < 0) for fwnode property
reads (Andy)
- Core: remove outer parentheses in satellite address
calculation (Andy)
- Core: loop index declared in for() scope (Andy)
- MMIO: add err.h, types.h includes (IWYU) (Andy)
- Header: remove unused types.h include and struct iio_dev
forward declaration at P2 stage (Andy)
- I2C: add err.h, mod_devicetable.h includes (IWYU) (Andy)
- Events: clamp() instead of clamp_t() (Andy)
- Events: regmap_assign_bits() instead of separate set/clear (Andy)
- Events: remove unneeded parentheses (2 places) (Andy)
- Events: for_each_set_bit on single line (Andy)
- Events: regmap_clear_bits() instead of regmap_update_bits() (Andy)
- Events: simplify unmask XOR to ~status & masked_temp (Andy)
- Events: add comment explaining unmask &= ~temp_mask logic (Andy)
- Events: split container_of across two lines (Andy)
- Events: move ISR write after !isr check (Andy)
- Events: unsigned int for init_hysteresis address param (Andy)
- Events: add comment explaining error check policy in
worker/IRQ (Andy)
- Events: nested size_add() for overflow-safe allocation (Andy)
- Events: propagate negative from fwnode_irq_get() for
EPROBE_DEFER (Andy)
- Events: pass irq instead of has_irq to sysmon_parse_fw (Andy)
- Oversampling: remove unneeded parentheses (Andy)
- Oversampling: use struct regmap *map local variable (Andy)
- Oversampling: switch instead of redundant if/if on
channel_type (Andy)
- Oversampling: add CONFIG register readback fence after
oversampling update to prevent NoC bus hang from posted
writes (found during hardware stress testing)
Changes in v4:
- Core: temperature channels use RAW + SCALE (IIO_VAL_FRACTIONAL,
1000/128) instead of PROCESSED; voltage channels use PROCESSED
only, drop RAW; drop scan_type from all channel macros (Jonathan)
- Core: move __free(fwnode_handle) declarations down to just
above use; devm_regmap_init() on one line; lock comment
describes RMW sequences and cached state (Jonathan)
- Events: merge event channels into static temp array -- two
arrays (with/without events) selected by has_irq; event-only
channels have no info_mask (Jonathan)
- Events: blank lines, fit under 80 chars, default returns error,
return early in each case, guard(spinlock) in IRQ handler
(Jonathan)
- Events: take irq_lock in write_event_config for temp_mask
updates (Sashiko)
- I2C: replace enum with defines, use unaligned accessors for
data and register offset packing, named initializer in
i2c_device_id (Jonathan)
- I2C: drop bitfield.h, add unaligned.h
- Oversampling: return directly, remove else after early returns,
rename mask defines, blank lines (Jonathan)
- Oversampling: move oversampling read inside guard(mutex) scope
- Fix v2 lore link in cover letter
Changes in v3:
- DT binding: single compatible, voltage-channels rename, single
quotes, drop label/bipolar/xlnx,aie-temp (Krzysztof)
- Core: IWYU throughout, __free(fwnode_handle), sign_extend32(),
size_add(), dev_err_probe(), s16 param, remove (int) casts,
drop SYSMON_MILLI in favor of (int)MILLI, rename _ext to _name
in SYSMON_CHAN_TEMP macro (Andy, Jonathan)
- Core: fwnode_irq_get() moved to core_probe, remove sysmon->dev/
indio_dev/irq from struct, describe protected data in lock
comment, add RAW+PROCESSED comment (Jonathan)
- I2C: IWYU, remove wrapper struct, explicit enum values, sizeof()
for buffers, = { } initializers, adapt to core_probe interface
change (Andy, Krzysztof)
- Events: IWYU, FIELD_GET/FIELD_PREP, regmap_set/clear_bits,
clamp_t, !!, IRQ_RETVAL(), devm_delayed_work_autocancel,
loop var scope, error checks, remove redundant else, logical
param splits, spinlock safety comment (Andy)
- Events: hysteresis rework -- store as millicelsius, hardcode
ALARM_CONFIG to hysteresis mode, compute lower threshold from
(upper - hysteresis), remove falling threshold for temperature,
single event spec per channel with IIO_EV_DIR_RISING, push
IIO_EV_DIR_RISING for temp and IIO_EV_DIR_EITHER for voltage
(Jonathan)
Tested on VCK190 (single SLR, MMIO path, 7 supplies, 10 temperature
satellites). I2C compile-tested.
A follow-up series will add thermal zone integration, secure firmware
access, and I2C remote monitoring.
Salih Erim (5):
dt-bindings: iio: adc: add xlnx,versal-sysmon binding
iio: adc: add Versal SysMon driver
iio: adc: versal-sysmon: add I2C driver
iio: adc: versal-sysmon: add threshold event support
iio: adc: versal-sysmon: add oversampling support
.../bindings/iio/adc/xlnx,versal-sysmon.yaml | 154 +++
MAINTAINERS | 8 +
drivers/iio/adc/Kconfig | 33 +
drivers/iio/adc/Makefile | 3 +
drivers/iio/adc/versal-sysmon-core.c | 1052 +++++++++++++++++
drivers/iio/adc/versal-sysmon-i2c.c | 134 +++
drivers/iio/adc/versal-sysmon.c | 92 ++
drivers/iio/adc/versal-sysmon.h | 120 ++
8 files changed, 1596 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/xlnx,versal-sysmon.yaml
create mode 100644 drivers/iio/adc/versal-sysmon-core.c
create mode 100644 drivers/iio/adc/versal-sysmon-i2c.c
create mode 100644 drivers/iio/adc/versal-sysmon.c
create mode 100644 drivers/iio/adc/versal-sysmon.h
--
2.48.1
^ permalink raw reply
* [PATCH v12 1/5] dt-bindings: iio: adc: add xlnx,versal-sysmon binding
From: Salih Erim @ 2026-06-24 14:37 UTC (permalink / raw)
To: jic23, andy
Cc: dlechner, nuno.sa, robh, krzk+dt, conor+dt, conall.ogriofa,
michal.simek, sai.krishna.potthuri, linux, erimsalih, git,
linux-iio, devicetree, linux-kernel, Salih Erim,
Krzysztof Kozlowski
In-Reply-To: <20260624143722.4047649-1-salih.erim@amd.com>
Add devicetree binding for the AMD/Xilinx Versal System Monitor (SysMon).
The Versal SysMon is the successor to the Zynq UltraScale+ AMS block,
providing on-chip voltage and temperature monitoring. The hardware
supports up to 160 supply voltage measurement points and up to 64
temperature satellites distributed across the SoC, with configurable
threshold alarms and oversampling. The device can be accessed via
memory-mapped I/O or via an I2C interface.
Supply and temperature channels are described as child nodes under
container nodes, referencing the standard adc.yaml binding for
channel properties.
Co-developed-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Salih Erim <salih.erim@amd.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Changes in v12:
- No code changes
Changes in v11:
- No code changes
Changes in v10:
- No code changes
Changes in v9:
- No code changes
Changes in v8:
- No code changes
Changes in v7:
- No code changes
Changes in v6:
- No code changes
Changes in v5:
- No code changes
Changes in v4:
- Add Reviewed-by tag from Krzysztof Kozlowski
Changes in v3:
- Use single compatible (xlnx,versal-sysmon only), remove
xlnx,versal-sysmon-i2c (Krzysztof)
- Rename supply-channels container to voltage-channels (Krzysztof)
- Use single quotes in patternProperties regex (Krzysztof)
- Drop label description from channel properties (Krzysztof)
- Drop bipolar from channel properties (Krzysztof)
- Remove xlnx,aie-temp property from binding and example (Krzysztof)
Changes in v2:
- Restructured to container nodes (supply-channels, temperature-channels)
with channel@N children referencing adc.yaml
- Added xlnx,versal-sysmon-i2c compatible
- Descriptions rewritten to describe hardware only
- Example simplified to #address-cells = <1>
- Interrupt example uses GIC_SPI/IRQ_TYPE_LEVEL_HIGH constants
- Commit description explains hardware context instead of schema layout
- reg required for both MMIO and I2C, interrupts optional
- Hex unit-addresses (channel@a not channel@10) per DTSpec
- patternProperties regex updated to accept hex digits [0-9a-f]
- Example trimmed to minimal variants (one basic + one bipolar supply,
one AIE temperature channel)
.../bindings/iio/adc/xlnx,versal-sysmon.yaml | 154 ++++++++++++++++++
1 file changed, 154 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/xlnx,versal-sysmon.yaml
diff --git a/Documentation/devicetree/bindings/iio/adc/xlnx,versal-sysmon.yaml b/Documentation/devicetree/bindings/iio/adc/xlnx,versal-sysmon.yaml
new file mode 100644
index 00000000000..1ad58e3d616
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/xlnx,versal-sysmon.yaml
@@ -0,0 +1,154 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022 - 2026, Advanced Micro Devices, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/xlnx,versal-sysmon.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AMD/Xilinx Versal System Monitor
+
+maintainers:
+ - Salih Erim <salih.erim@amd.com>
+
+description:
+ The AMD/Xilinx Versal System Monitor (SysMon) is the successor to the
+ Zynq UltraScale+ AMS block. It provides on-chip voltage and temperature
+ monitoring with up to 160 voltage measurement points and up to
+ 64 temperature satellites distributed across the SoC. The hardware
+ supports configurable threshold alarms and oversampling. The device
+ can be accessed via memory-mapped I/O or via an I2C interface.
+
+properties:
+ compatible:
+ const: xlnx,versal-sysmon
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ '#io-channel-cells':
+ const: 1
+
+ voltage-channels:
+ type: object
+ description:
+ Container for voltage measurement channels.
+
+ properties:
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ patternProperties:
+ '^channel@([0-9a-f]|[1-9][0-9a-f])$':
+ $ref: adc.yaml
+
+ description:
+ Measures a voltage rail. The register index and rail
+ name are assigned by the hardware design tool (Vivado).
+
+ properties:
+ reg:
+ minimum: 0
+ maximum: 159
+ description:
+ Voltage measurement register index assigned by the hardware
+ design tool.
+
+ required:
+ - reg
+ - label
+
+ unevaluatedProperties: false
+
+ required:
+ - '#address-cells'
+ - '#size-cells'
+
+ additionalProperties: false
+
+ temperature-channels:
+ type: object
+ description:
+ Container for temperature satellite measurement channels.
+
+ properties:
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ patternProperties:
+ '^channel@([1-9a-f]|[1-3][0-9a-f]|40)$':
+ $ref: adc.yaml
+
+ description:
+ Reads a temperature satellite sensor. Each satellite monitors
+ a specific region of the SoC die.
+
+ properties:
+ reg:
+ minimum: 1
+ maximum: 64
+ description:
+ Temperature satellite number (1-based hardware index).
+
+ required:
+ - reg
+ - label
+
+ unevaluatedProperties: false
+
+ required:
+ - '#address-cells'
+ - '#size-cells'
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ sysmon@f1270000 {
+ compatible = "xlnx,versal-sysmon";
+ reg = <0xf1270000 0x4000>;
+ interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
+ #io-channel-cells = <1>;
+
+ voltage-channels {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ reg = <0>;
+ label = "vccaux";
+ };
+
+ channel@3 {
+ reg = <3>;
+ label = "vcc_ram";
+ bipolar;
+ };
+ };
+
+ temperature-channels {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@a {
+ reg = <10>;
+ label = "aie-temp-ch1";
+ };
+ };
+ };
--
2.48.1
^ permalink raw reply related
* [PATCH v12 3/5] iio: adc: versal-sysmon: add I2C driver
From: Salih Erim @ 2026-06-24 14:37 UTC (permalink / raw)
To: jic23, andy
Cc: dlechner, nuno.sa, robh, krzk+dt, conor+dt, conall.ogriofa,
michal.simek, sai.krishna.potthuri, linux, erimsalih, git,
linux-iio, devicetree, linux-kernel, Salih Erim, Andy Shevchenko
In-Reply-To: <20260624143722.4047649-1-salih.erim@amd.com>
Add an I2C transport driver for the Versal SysMon block. The SysMon
provides an I2C slave interface that allows an external master to
read voltage and temperature measurements through the same register
map used by the MMIO path.
The I2C command frame is an 8-byte structure containing a 4-byte data
payload, a 2-byte register offset, and a 1-byte instruction field.
Read operations send the frame with a read instruction, then receive
a 4-byte response containing the register value.
Events are not supported on the I2C path because there is no
interrupt line and the I2C regmap backend cannot be called from
atomic context.
Co-developed-by: Conall O'Griofa <conall.ogriofa@amd.com>
Signed-off-by: Conall O'Griofa <conall.ogriofa@amd.com>
Signed-off-by: Salih Erim <salih.erim@amd.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
---
Changes in v12:
- No code changes
Changes in v11:
- No code changes
Changes in v10:
- No code changes
Changes in v9:
- Add Reviewed-by tag from Andy Shevchenko
- Add MODULE_IMPORT_NS("VERSAL_SYSMON") (Andy, from P2 namespace)
Changes in v8:
- Add volatile register comment for regmap cache (Andy)
- Update devm_versal_sysmon_core_probe call site (Andy, from P2 rename)
Changes in v7:
- No code changes
Changes in v6:
- Add types.h include (IWYU) (Andy)
- Add local struct device *dev, join devm_regmap_init on
one line (Andy)
Changes in v5:
- Add err.h, mod_devicetable.h includes (IWYU) (Andy)
Changes in v4:
- Replace enum with defines for I2C frame offsets (Jonathan)
- Use get_unaligned_le32() for read data reassembly (Jonathan)
- Use put_unaligned_le32/le16() for write data and register offset
packing (Jonathan)
- Named initializer in i2c_device_id (Jonathan)
- Drop bitfield.h, add unaligned.h (FIELD_GET/FIELD_PREP replaced
by unaligned accessors)
Changes in v3:
- IWYU: fix includes (Andy)
- Enum: assign all values explicitly for HW-mapped fields (Andy)
- Remove sysmon_i2c wrapper struct, pass i2c_client directly
(Andy)
- Use sizeof() for I2C buffer lengths instead of defines (Andy)
- Use = { } instead of = { 0 } for initializers (Andy)
- Use single compatible xlnx,versal-sysmon (Krzysztof)
- Adapt to core_probe interface change: irq moved to core,
remove irq parameter from bus driver (Jonathan)
Changes in v2:
- New patch (I2C was deferred to Series B in v1)
- Uses regmap API with custom I2C read/write callbacks
- Shares core module with MMIO driver via sysmon_core_probe()
- No event support (I2C has no interrupt line)
- Separate VERSAL_SYSMON_I2C Kconfig symbol
- Reverse Christmas Tree variable ordering in read/write functions
drivers/iio/adc/Kconfig | 13 +++
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/versal-sysmon-i2c.c | 134 ++++++++++++++++++++++++++++
3 files changed, 148 insertions(+)
create mode 100644 drivers/iio/adc/versal-sysmon-i2c.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index c7f19057484..8f9fc9de74a 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -1963,6 +1963,19 @@ config VERSAL_SYSMON
To compile this driver as a module, choose M here: the module
will be called versal-sysmon.
+config VERSAL_SYSMON_I2C
+ tristate "AMD Versal SysMon I2C driver"
+ depends on I2C
+ select VERSAL_SYSMON_CORE
+ help
+ Say yes here to have support for the AMD/Xilinx Versal System
+ Monitor (SysMon) via I2C interface. This driver enables voltage
+ and temperature monitoring when the Versal chip has SysMon
+ configured with I2C access.
+
+ To compile this driver as a module, choose M here: the module
+ will be called versal-sysmon-i2c.
+
config VF610_ADC
tristate "Freescale vf610 ADC driver"
depends on HAS_IOMEM
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index d7696b1b157..5abb611fe46 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -169,6 +169,7 @@ obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
obj-$(CONFIG_VERSAL_SYSMON_CORE) += versal-sysmon-core.o
obj-$(CONFIG_VERSAL_SYSMON) += versal-sysmon.o
+obj-$(CONFIG_VERSAL_SYSMON_I2C) += versal-sysmon-i2c.o
obj-$(CONFIG_VF610_ADC) += vf610_adc.o
obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
obj-$(CONFIG_XILINX_AMS) += xilinx-ams.o
diff --git a/drivers/iio/adc/versal-sysmon-i2c.c b/drivers/iio/adc/versal-sysmon-i2c.c
new file mode 100644
index 00000000000..e9a7629159a
--- /dev/null
+++ b/drivers/iio/adc/versal-sysmon-i2c.c
@@ -0,0 +1,134 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * AMD Versal SysMon I2C driver
+ *
+ * Copyright (C) 2023 - 2026, Advanced Micro Devices, Inc.
+ */
+
+#include <linux/bits.h>
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+#include <linux/types.h>
+#include <linux/unaligned.h>
+
+#include "versal-sysmon.h"
+
+#define SYSMON_I2C_INSTR_READ BIT(2)
+#define SYSMON_I2C_INSTR_WRITE BIT(3)
+
+/*
+ * I2C command frame layout (8 bytes):
+ * [0..3] data payload (little-endian u32)
+ * [4..5] register offset >> 2 (little-endian u16)
+ * [6] instruction (read/write)
+ * [7] reserved
+ */
+#define SYSMON_I2C_DATA_OFS 0
+#define SYSMON_I2C_REG_OFS 4
+#define SYSMON_I2C_INSTR_OFS 6
+
+static int sysmon_i2c_reg_read(void *context, unsigned int reg,
+ unsigned int *val)
+{
+ struct i2c_client *client = context;
+ u8 write_buf[8] = { };
+ u8 read_buf[4];
+ int ret;
+
+ put_unaligned_le16(reg >> 2, &write_buf[SYSMON_I2C_REG_OFS]);
+ write_buf[SYSMON_I2C_INSTR_OFS] = SYSMON_I2C_INSTR_READ;
+
+ ret = i2c_master_send(client, write_buf, sizeof(write_buf));
+ if (ret < 0)
+ return ret;
+ if (ret != sizeof(write_buf))
+ return -EIO;
+
+ ret = i2c_master_recv(client, read_buf, sizeof(read_buf));
+ if (ret < 0)
+ return ret;
+ if (ret != sizeof(read_buf))
+ return -EIO;
+
+ *val = get_unaligned_le32(read_buf);
+
+ return 0;
+}
+
+static int sysmon_i2c_reg_write(void *context, unsigned int reg,
+ unsigned int val)
+{
+ struct i2c_client *client = context;
+ u8 write_buf[8] = { };
+ int ret;
+
+ put_unaligned_le32(val, &write_buf[SYSMON_I2C_DATA_OFS]);
+ put_unaligned_le16(reg >> 2, &write_buf[SYSMON_I2C_REG_OFS]);
+ write_buf[SYSMON_I2C_INSTR_OFS] = SYSMON_I2C_INSTR_WRITE;
+
+ ret = i2c_master_send(client, write_buf, sizeof(write_buf));
+ if (ret < 0)
+ return ret;
+ if (ret != sizeof(write_buf))
+ return -EIO;
+
+ return 0;
+}
+
+/*
+ * Almost all registers are volatile (live ADC readings, interrupt
+ * status). The rest are not accessed often enough to benefit from
+ * caching.
+ */
+static const struct regmap_config sysmon_i2c_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = SYSMON_REG_STRIDE,
+ .max_register = SYSMON_MAX_REG,
+ .reg_read = sysmon_i2c_reg_read,
+ .reg_write = sysmon_i2c_reg_write,
+};
+
+static int sysmon_i2c_probe(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ struct regmap *regmap;
+
+ regmap = devm_regmap_init(dev, NULL, client, &sysmon_i2c_regmap_config);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
+ /* I2C has no IRQ connection; events are not supported */
+ return devm_versal_sysmon_core_probe(dev, regmap);
+}
+
+static const struct of_device_id sysmon_i2c_of_match_table[] = {
+ { .compatible = "xlnx,versal-sysmon" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, sysmon_i2c_of_match_table);
+
+static const struct i2c_device_id sysmon_i2c_id_table[] = {
+ { .name = "versal-sysmon" },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, sysmon_i2c_id_table);
+
+static struct i2c_driver sysmon_i2c_driver = {
+ .probe = sysmon_i2c_probe,
+ .driver = {
+ .name = "versal-sysmon-i2c",
+ .of_match_table = sysmon_i2c_of_match_table,
+ },
+ .id_table = sysmon_i2c_id_table,
+};
+module_i2c_driver(sysmon_i2c_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("AMD Versal SysMon I2C Driver");
+MODULE_IMPORT_NS("VERSAL_SYSMON");
+MODULE_AUTHOR("Conall O'Griofa <conall.ogriofa@amd.com>");
+MODULE_AUTHOR("Salih Erim <salih.erim@amd.com>");
--
2.48.1
^ permalink raw reply related
* Re: [PATCH v2 2/2] arm64: dts: qcom: sdm845-oneplus: Update compatible to include model
From: David Heidelberg @ 2026-06-24 14:37 UTC (permalink / raw)
To: Dmitry Torokhov, Krzysztof Kozlowski, Konrad Dybcio
Cc: 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: <ajtaUb4YmyZTDLmQ@google.com>
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.
--- 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.
> 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.
>
> 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?
David
>
> Thanks.
>
^ permalink raw reply
* Re: [PATCH v5 12/16] media: iris: implement support for the Agatti platform
From: Vikash Garodia @ 2026-06-24 14:30 UTC (permalink / raw)
To: Dmitry Baryshkov, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vishnu Reddy
Cc: linux-media, linux-arm-msm, linux-kernel, devicetree,
Dikshita Agarwal
In-Reply-To: <20260616-iris-ar50lt-v5-12-583b42770b6a@oss.qualcomm.com>
On 6/16/2026 5:34 AM, Dmitry Baryshkov wrote:
> Port support for the AR50Lt video codec core (present for example on the
> Agatti platform) to the Iris driver. Unlike more recent cores this
> generation doesn't have the PIPE property (as it always has only one
> pipe). Also, unlike newer platforms, buffer sizes are requested from the
> firmware instead of being calculated by the driver.
>
> Co-developed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/iris/Makefile | 1 +
> drivers/media/platform/qcom/iris/iris_hfi_gen1.c | 227 +++++++++++++++++++++
> .../platform/qcom/iris/iris_platform_common.h | 6 +
> .../platform/qcom/iris/iris_platform_vpu_ar50lt.c | 110 ++++++++++
> drivers/media/platform/qcom/iris/iris_probe.c | 4 +
> drivers/media/platform/qcom/iris/iris_vpu_buffer.c | 13 ++
> drivers/media/platform/qcom/iris/iris_vpu_buffer.h | 1 +
> 7 files changed, 362 insertions(+)
>
> diff --git a/drivers/media/platform/qcom/iris/Makefile b/drivers/media/platform/qcom/iris/Makefile
> index f1b204b95694..bbd1f724963e 100644
> --- a/drivers/media/platform/qcom/iris/Makefile
> +++ b/drivers/media/platform/qcom/iris/Makefile
> @@ -14,6 +14,7 @@ qcom-iris-objs += iris_buffer.o \
> iris_hfi_queue.o \
> iris_platform_vpu2.o \
> iris_platform_vpu3x.o \
> + iris_platform_vpu_ar50lt.o \
> iris_power.o \
> iris_probe.o \
> iris_resources.o \
> diff --git a/drivers/media/platform/qcom/iris/iris_hfi_gen1.c b/drivers/media/platform/qcom/iris/iris_hfi_gen1.c
> index ca1545d28b53..f57af31dbd9f 100644
> --- a/drivers/media/platform/qcom/iris/iris_hfi_gen1.c
> +++ b/drivers/media/platform/qcom/iris/iris_hfi_gen1.c
> @@ -443,3 +443,230 @@ const struct iris_firmware_data iris_hfi_gen1_data = {
> .enc_ip_int_buf_tbl = sm8250_enc_ip_int_buf_tbl,
> .enc_ip_int_buf_tbl_size = ARRAY_SIZE(sm8250_enc_ip_int_buf_tbl),
> };
> +
> +static const struct platform_inst_fw_cap iris_inst_fw_cap_gen1_ar50lt_dec[] = {
> + {
> + .cap_id = STAGE,
> + .min = STAGE_1,
> + .max = STAGE_2,
> + .step_or_mask = 1,
> + .value = STAGE_2,
> + .hfi_id = HFI_PROPERTY_PARAM_WORK_MODE,
> + .set = iris_set_stage,
> + },
> +};
> +
<snip>
> +
> +static const u32 iris_hfi_gen2_ar50lt_dec_ip_int_buf_tbl[] = {
gen1...
> + BUF_BIN,
> + BUF_SCRATCH_1,
> +};
> +
> +const struct iris_firmware_data iris_hfi_gen1_ar50lt_data = {
> + .init_hfi_ops = &iris_hfi_gen1_sys_ops_init,
> +
> + .inst_fw_caps_dec = iris_inst_fw_cap_gen1_ar50lt_dec,
> + .inst_fw_caps_dec_size = ARRAY_SIZE(iris_inst_fw_cap_gen1_ar50lt_dec),
> + .inst_fw_caps_enc = inst_fw_cap_gen1_ar50lt_enc,
> + .inst_fw_caps_enc_size = ARRAY_SIZE(inst_fw_cap_gen1_ar50lt_enc),
> +
> + .dec_input_config_params_default =
> + sm8250_vdec_input_config_param_default,
> + .dec_input_config_params_default_size =
> + ARRAY_SIZE(sm8250_vdec_input_config_param_default),
> + .enc_input_config_params = sm8250_venc_input_config_param,
> + .enc_input_config_params_size =
> + ARRAY_SIZE(sm8250_venc_input_config_param),
> +
> + .dec_ip_int_buf_tbl = iris_hfi_gen2_ar50lt_dec_ip_int_buf_tbl,
> + .dec_ip_int_buf_tbl_size = ARRAY_SIZE(iris_hfi_gen2_ar50lt_dec_ip_int_buf_tbl),
same here
> + .dec_op_int_buf_tbl = sm8250_dec_op_int_buf_tbl,
> + .dec_op_int_buf_tbl_size = ARRAY_SIZE(sm8250_dec_op_int_buf_tbl),
> +
Regards,
Vikash
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Leo Yan @ 2026-06-24 14:25 UTC (permalink / raw)
To: Jie Gan
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Yuanfang Zhang,
Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <20260624-fix-tracenoc-probe-issue-v2-2-786520f62f21@oss.qualcomm.com>
On Wed, Jun 24, 2026 at 05:49:26PM +0800, Jie Gan wrote:
> The AMBA bus attempts to read the CID/PID of a device before invoking
> its probe function if the arm,primecell-periphid property is absent.
> This causes a deferred probe issue for the TraceNoC device, as the
> CID/PID cannot be read from the periphid register.
> Add the arm,primecell-periphid property to bypass the AMBA bus
> check and resolve the probe issue.
tnoc.c registers both an AMBA driver and a platform driver. Shouldn't it
be registered as a platform device instead?
Thanks,
Leo
^ permalink raw reply
* Re: [PATCH v5 15/16] media: venus: skip QCM2290 if Iris driver is enabled
From: Vikash Garodia @ 2026-06-24 14:24 UTC (permalink / raw)
To: Dmitry Baryshkov, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vishnu Reddy
Cc: linux-media, linux-arm-msm, linux-kernel, devicetree,
Dikshita Agarwal
In-Reply-To: <20260616-iris-ar50lt-v5-15-583b42770b6a@oss.qualcomm.com>
On 6/16/2026 5:34 AM, Dmitry Baryshkov wrote:
> As the Iris driver now supports the QCM2290 hardware too, there is a
> race between Venus and Iris drivers on binding to the corresponding
> device. Follow the approach used by other platforms and skip QCM2290 in
> the Venus driver if Iris is enabled.
>
> Signed-off-by: Dmitry Baryshkov<dmitry.baryshkov@oss.qualcomm.com>
> Reviewed-by: Dikshita Agarwal<dikshita.agarwal@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/venus/core.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v5 16/16] media: iris: constify inst_fw_cap_sm8250_dec
From: Vikash Garodia @ 2026-06-24 14:23 UTC (permalink / raw)
To: Dmitry Baryshkov, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vishnu Reddy
Cc: linux-media, linux-arm-msm, linux-kernel, devicetree,
Dikshita Agarwal
In-Reply-To: <20260616-iris-ar50lt-v5-16-583b42770b6a@oss.qualcomm.com>
On 6/16/2026 5:34 AM, Dmitry Baryshkov wrote:
> Mark inst_fw_cap_sm8250_dec as a const array, the data is read-only.
>
> Suggested-by: Vishnu Reddy<busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Dmitry Baryshkov<dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/iris/iris_hfi_gen1.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 1/2] iio: dac: dac8163: Add driver for DAC8163
From: David Lechner @ 2026-06-24 14:18 UTC (permalink / raw)
To: Lukas, Siratul Islam
Cc: andy, conor+dt, devicetree, jic23, krzk+dt, linux-iio,
linux-kernel, nuno.sa, robh
In-Reply-To: <ajuVjk-lw-DqUVnl@berta-MS-7693>
On 6/24/26 3:30 AM, Lukas wrote:
> Thanks for the review. As i said this is my first time submitting a
> patch. I have looked at already existing spi dac drivers for reference
> but i seemed to have missed quite a lot. But the comments are greatly
> appreciated.
>
> On Wed, Jun 24, 2026 at 12:56:15AM +0600, Siratul Islam wrote:
>> A link to the datasheet here would be nice.
>
> I will try to add all the small suggestions i dont mention explicitly,
> like style issues or using guard instead of manual lock/unlock to v2.
>
>>> +
>>> + if (st->internal_ref) {
>>> + st->vref_uv = 2500000; /* 2.5V internal reference */
>> A note on where this value came from or why this was chosen, or a reference to datasheet would be better.
>
> I think i would add the suggestion from David Lechner to remove the
> internal_ref property completly and add "the way of doing optional
> voltage references". This includes using the macro
> DAC8163_INTERNAL_REF_mV. Would this be acceptable?
>
>> You have a CMD_SOFT_RST defined but not used. Should this be used to reset before doing any configuration?
>
> Yes this is a command which isnt used at this point. But maybe it makes
> sense to reset the DAC first when probing.
In general we tend to reset IIO devices during probe. DACs can be an exception
though since they are output devices and resetting it could change the output.
This device is quite simple anyway, so reset probably isn't needed.
>
> Best regards
> Lukas
^ permalink raw reply
* Re: [PATCH v5 12/16] media: iris: implement support for the Agatti platform
From: Vikash Garodia @ 2026-06-24 14:17 UTC (permalink / raw)
To: Dmitry Baryshkov, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vishnu Reddy
Cc: linux-media, linux-arm-msm, linux-kernel, devicetree,
Dikshita Agarwal
In-Reply-To: <20260616-iris-ar50lt-v5-12-583b42770b6a@oss.qualcomm.com>
On 6/16/2026 5:34 AM, Dmitry Baryshkov wrote:
> Port support for the AR50Lt video codec core (present for example on the
> Agatti platform) to the Iris driver. Unlike more recent cores this
> generation doesn't have the PIPE property (as it always has only one
> pipe). Also, unlike newer platforms, buffer sizes are requested from the
> firmware instead of being calculated by the driver.
>
> Co-developed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/iris/Makefile | 1 +
> drivers/media/platform/qcom/iris/iris_hfi_gen1.c | 227 +++++++++++++++++++++
> .../platform/qcom/iris/iris_platform_common.h | 6 +
> .../platform/qcom/iris/iris_platform_vpu_ar50lt.c | 110 ++++++++++
> drivers/media/platform/qcom/iris/iris_probe.c | 4 +
> drivers/media/platform/qcom/iris/iris_vpu_buffer.c | 13 ++
> drivers/media/platform/qcom/iris/iris_vpu_buffer.h | 1 +
> 7 files changed, 362 insertions(+)
>
> diff --git a/drivers/media/platform/qcom/iris/Makefile b/drivers/media/platform/qcom/iris/Makefile
> index f1b204b95694..bbd1f724963e 100644
> --- a/drivers/media/platform/qcom/iris/Makefile
> +++ b/drivers/media/platform/qcom/iris/Makefile
> @@ -14,6 +14,7 @@ qcom-iris-objs += iris_buffer.o \
> iris_hfi_queue.o \
> iris_platform_vpu2.o \
> iris_platform_vpu3x.o \
> + iris_platform_vpu_ar50lt.o \
> iris_power.o \
> iris_probe.o \
> iris_resources.o \
> diff --git a/drivers/media/platform/qcom/iris/iris_hfi_gen1.c b/drivers/media/platform/qcom/iris/iris_hfi_gen1.c
> index ca1545d28b53..f57af31dbd9f 100644
> --- a/drivers/media/platform/qcom/iris/iris_hfi_gen1.c
> +++ b/drivers/media/platform/qcom/iris/iris_hfi_gen1.c
> @@ -443,3 +443,230 @@ const struct iris_firmware_data iris_hfi_gen1_data = {
> .enc_ip_int_buf_tbl = sm8250_enc_ip_int_buf_tbl,
> .enc_ip_int_buf_tbl_size = ARRAY_SIZE(sm8250_enc_ip_int_buf_tbl),
> };
> +
> +static const struct platform_inst_fw_cap iris_inst_fw_cap_gen1_ar50lt_dec[] = {
> + {
> + .cap_id = STAGE,
> + .min = STAGE_1,
> + .max = STAGE_2,
> + .step_or_mask = 1,
> + .value = STAGE_2,
> + .hfi_id = HFI_PROPERTY_PARAM_WORK_MODE,
> + .set = iris_set_stage,
> + },
> +};
> +
> +static const struct platform_inst_fw_cap inst_fw_cap_gen1_ar50lt_enc[] = {
> + {
> + .cap_id = STAGE,
> + .min = STAGE_1,
> + .max = STAGE_2,
> + .step_or_mask = 1,
> + .value = STAGE_2,
> + .hfi_id = HFI_PROPERTY_PARAM_WORK_MODE,
> + .set = iris_set_stage,
> + },
> + {
> + .cap_id = PROFILE_H264,
> + .min = V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE,
> + .max = V4L2_MPEG_VIDEO_H264_PROFILE_MULTIVIEW_HIGH,
> + .step_or_mask = BIT(V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE) |
> + BIT(V4L2_MPEG_VIDEO_H264_PROFILE_CONSTRAINED_BASELINE) |
> + BIT(V4L2_MPEG_VIDEO_H264_PROFILE_MAIN) |
> + BIT(V4L2_MPEG_VIDEO_H264_PROFILE_HIGH) |
> + BIT(V4L2_MPEG_VIDEO_H264_PROFILE_STEREO_HIGH) |
> + BIT(V4L2_MPEG_VIDEO_H264_PROFILE_MULTIVIEW_HIGH),
> + .value = V4L2_MPEG_VIDEO_H264_PROFILE_HIGH,
> + .hfi_id = HFI_PROPERTY_PARAM_PROFILE_LEVEL_CURRENT,
> + .flags = CAP_FLAG_OUTPUT_PORT | CAP_FLAG_MENU,
> + .set = iris_set_profile_level_gen1,
> + },
> + {
> + .cap_id = PROFILE_HEVC,
> + .min = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN,
> + .max = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_STILL_PICTURE,
> + .step_or_mask = BIT(V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN) |
> + BIT(V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_STILL_PICTURE),
> + .value = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN,
> + .hfi_id = HFI_PROPERTY_PARAM_PROFILE_LEVEL_CURRENT,
> + .flags = CAP_FLAG_OUTPUT_PORT | CAP_FLAG_MENU,
> + .set = iris_set_profile_level_gen1,
> + },
> + {
> + .cap_id = LEVEL_H264,
> + .min = V4L2_MPEG_VIDEO_H264_LEVEL_1_0,
> + .max = V4L2_MPEG_VIDEO_H264_LEVEL_4_2,
> + .step_or_mask = BIT(V4L2_MPEG_VIDEO_H264_LEVEL_1_0) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_1B) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_1_1) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_1_2) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_1_3) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_2_0) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_2_1) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_2_2) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_3_0) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_3_1) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_3_2) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_4_0) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_4_1) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_4_2),
> + .value = V4L2_MPEG_VIDEO_H264_LEVEL_1_0,
> + .hfi_id = HFI_PROPERTY_PARAM_PROFILE_LEVEL_CURRENT,
> + .flags = CAP_FLAG_OUTPUT_PORT | CAP_FLAG_MENU,
> + .set = iris_set_profile_level_gen1,
> + },
> + {
> + .cap_id = LEVEL_HEVC,
> + .min = V4L2_MPEG_VIDEO_HEVC_LEVEL_1,
> + .max = V4L2_MPEG_VIDEO_HEVC_LEVEL_4_1,
> + .step_or_mask = BIT(V4L2_MPEG_VIDEO_HEVC_LEVEL_1) |
> + BIT(V4L2_MPEG_VIDEO_HEVC_LEVEL_2) |
> + BIT(V4L2_MPEG_VIDEO_HEVC_LEVEL_2_1) |
> + BIT(V4L2_MPEG_VIDEO_HEVC_LEVEL_3) |
> + BIT(V4L2_MPEG_VIDEO_HEVC_LEVEL_3_1) |
> + BIT(V4L2_MPEG_VIDEO_HEVC_LEVEL_4) |
> + BIT(V4L2_MPEG_VIDEO_HEVC_LEVEL_4_1),
> + .value = V4L2_MPEG_VIDEO_HEVC_LEVEL_1,
> + .hfi_id = HFI_PROPERTY_PARAM_PROFILE_LEVEL_CURRENT,
> + .flags = CAP_FLAG_OUTPUT_PORT | CAP_FLAG_MENU,
> + .set = iris_set_profile_level_gen1,
> + },
> + {
> + .cap_id = HEADER_MODE,
> + .min = V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE,
> + .max = V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME,
> + .step_or_mask = BIT(V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE) |
> + BIT(V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME),
> + .value = V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME,
> + .hfi_id = HFI_PROPERTY_CONFIG_VENC_SYNC_FRAME_SEQUENCE_HEADER,
> + .flags = CAP_FLAG_OUTPUT_PORT | CAP_FLAG_MENU,
> + .set = iris_set_header_mode_gen1,
> + },
> + {
> + .cap_id = BITRATE,
> + .min = BITRATE_MIN,
> + .max = BITRATE_MAX_AR50LT,
> + .step_or_mask = BITRATE_STEP,
> + .value = BITRATE_DEFAULT_AR50LT,
> + .hfi_id = HFI_PROPERTY_CONFIG_VENC_TARGET_BITRATE,
> + .flags = CAP_FLAG_OUTPUT_PORT | CAP_FLAG_INPUT_PORT |
> + CAP_FLAG_DYNAMIC_ALLOWED,
> + .set = iris_set_bitrate_gen1,
> + },
> + {
> + .cap_id = BITRATE_MODE,
> + .min = V4L2_MPEG_VIDEO_BITRATE_MODE_VBR,
> + .max = V4L2_MPEG_VIDEO_BITRATE_MODE_CBR,
> + .step_or_mask = BIT(V4L2_MPEG_VIDEO_BITRATE_MODE_VBR) |
> + BIT(V4L2_MPEG_VIDEO_BITRATE_MODE_CBR),
> + .value = V4L2_MPEG_VIDEO_BITRATE_MODE_VBR,
> + .hfi_id = HFI_PROPERTY_PARAM_VENC_RATE_CONTROL,
> + .flags = CAP_FLAG_OUTPUT_PORT | CAP_FLAG_MENU,
> + .set = iris_set_bitrate_mode_gen1,
> + },
> + {
> + .cap_id = FRAME_SKIP_MODE,
> + .min = V4L2_MPEG_VIDEO_FRAME_SKIP_MODE_DISABLED,
> + .max = V4L2_MPEG_VIDEO_FRAME_SKIP_MODE_BUF_LIMIT,
> + .step_or_mask = BIT(V4L2_MPEG_VIDEO_FRAME_SKIP_MODE_DISABLED) |
> + BIT(V4L2_MPEG_VIDEO_FRAME_SKIP_MODE_BUF_LIMIT),
> + .value = V4L2_MPEG_VIDEO_FRAME_SKIP_MODE_DISABLED,
> + .flags = CAP_FLAG_OUTPUT_PORT | CAP_FLAG_MENU,
> + },
> + {
> + .cap_id = FRAME_RC_ENABLE,
> + .min = 0,
> + .max = 1,
> + .step_or_mask = 1,
> + .value = 1,
> + },
> + {
> + .cap_id = GOP_SIZE,
> + .min = 0,
> + .max = (1 << 16) - 1,
> + .step_or_mask = 1,
> + .value = 30,
> + .set = iris_set_u32
> + },
> + {
> + .cap_id = ENTROPY_MODE,
> + .min = V4L2_MPEG_VIDEO_H264_ENTROPY_MODE_CAVLC,
> + .max = V4L2_MPEG_VIDEO_H264_ENTROPY_MODE_CABAC,
> + .step_or_mask = BIT(V4L2_MPEG_VIDEO_H264_ENTROPY_MODE_CAVLC) |
> + BIT(V4L2_MPEG_VIDEO_H264_ENTROPY_MODE_CABAC),
> + .value = V4L2_MPEG_VIDEO_H264_ENTROPY_MODE_CAVLC,
> + .hfi_id = HFI_PROPERTY_PARAM_VENC_H264_ENTROPY_CONTROL,
> + .flags = CAP_FLAG_OUTPUT_PORT | CAP_FLAG_MENU,
> + .set = iris_set_entropy_mode_gen1,
> + },
> + {
> + .cap_id = MIN_FRAME_QP_H264,
> + .min = MIN_QP_8BIT_AR50LT,
> + .max = MAX_QP,
> + .step_or_mask = 1,
> + .value = MIN_QP_8BIT_AR50LT,
> + .hfi_id = HFI_PROPERTY_PARAM_VENC_SESSION_QP_RANGE_V2,
> + .flags = CAP_FLAG_OUTPUT_PORT,
> + .set = iris_set_qp_range,
> + },
> + {
> + .cap_id = MIN_FRAME_QP_HEVC,
> + .min = MIN_QP_8BIT_AR50LT,
> + .max = MAX_QP_HEVC,
> + .step_or_mask = 1,
> + .value = MIN_QP_8BIT_AR50LT,
> + .hfi_id = HFI_PROPERTY_PARAM_VENC_SESSION_QP_RANGE_V2,
> + .flags = CAP_FLAG_OUTPUT_PORT,
> + .set = iris_set_qp_range,
> + },
> + {
> + .cap_id = MAX_FRAME_QP_H264,
> + .min = MIN_QP_8BIT_AR50LT,
> + .max = MAX_QP,
> + .step_or_mask = 1,
> + .value = MAX_QP,
> + .hfi_id = HFI_PROPERTY_PARAM_VENC_SESSION_QP_RANGE_V2,
> + .flags = CAP_FLAG_OUTPUT_PORT,
> + .set = iris_set_qp_range,
> + },
> + {
> + .cap_id = MAX_FRAME_QP_HEVC,
> + .min = MIN_QP_8BIT_AR50LT,
> + .max = MAX_QP_HEVC,
> + .step_or_mask = 1,
> + .value = MAX_QP_HEVC,
> + .hfi_id = HFI_PROPERTY_PARAM_VENC_SESSION_QP_RANGE_V2,
> + .flags = CAP_FLAG_OUTPUT_PORT,
> + .set = iris_set_qp_range,
> + },
> +};
> +
> +static const u32 iris_hfi_gen2_ar50lt_dec_ip_int_buf_tbl[] = {
> + BUF_BIN,
> + BUF_SCRATCH_1,
> +};
> +
> +const struct iris_firmware_data iris_hfi_gen1_ar50lt_data = {
> + .init_hfi_ops = &iris_hfi_gen1_sys_ops_init,
> +
> + .inst_fw_caps_dec = iris_inst_fw_cap_gen1_ar50lt_dec,
> + .inst_fw_caps_dec_size = ARRAY_SIZE(iris_inst_fw_cap_gen1_ar50lt_dec),
> + .inst_fw_caps_enc = inst_fw_cap_gen1_ar50lt_enc,
> + .inst_fw_caps_enc_size = ARRAY_SIZE(inst_fw_cap_gen1_ar50lt_enc),
> +
> + .dec_input_config_params_default =
> + sm8250_vdec_input_config_param_default,
> + .dec_input_config_params_default_size =
> + ARRAY_SIZE(sm8250_vdec_input_config_param_default),
> + .enc_input_config_params = sm8250_venc_input_config_param,
> + .enc_input_config_params_size =
> + ARRAY_SIZE(sm8250_venc_input_config_param),
> +
> + .dec_ip_int_buf_tbl = iris_hfi_gen2_ar50lt_dec_ip_int_buf_tbl,
> + .dec_ip_int_buf_tbl_size = ARRAY_SIZE(iris_hfi_gen2_ar50lt_dec_ip_int_buf_tbl),
> + .dec_op_int_buf_tbl = sm8250_dec_op_int_buf_tbl,
> + .dec_op_int_buf_tbl_size = ARRAY_SIZE(sm8250_dec_op_int_buf_tbl),
> +
> + .enc_ip_int_buf_tbl = sm8250_enc_ip_int_buf_tbl,
> + .enc_ip_int_buf_tbl_size = ARRAY_SIZE(sm8250_enc_ip_int_buf_tbl),
> +};
> diff --git a/drivers/media/platform/qcom/iris/iris_platform_common.h b/drivers/media/platform/qcom/iris/iris_platform_common.h
> index 6a189489369f..bc04831ae7fc 100644
> --- a/drivers/media/platform/qcom/iris/iris_platform_common.h
> +++ b/drivers/media/platform/qcom/iris/iris_platform_common.h
> @@ -39,6 +39,10 @@ struct iris_inst;
> #define MAX_HEVC_VBR_LAYER_HP_SLIDING_WINDOW 5
> #define MAX_HIER_CODING_LAYER_GEN1 6
>
> +#define BITRATE_MAX_AR50LT 100000000
> +#define BITRATE_DEFAULT_AR50LT 20000000
> +#define MIN_QP_8BIT_AR50LT 0
> +
> enum stage_type {
> STAGE_1 = 1,
> STAGE_2 = 2,
> @@ -51,8 +55,10 @@ enum pipe_type {
> };
>
> extern const struct iris_firmware_data iris_hfi_gen1_data;
> +extern const struct iris_firmware_data iris_hfi_gen1_ar50lt_data;
> extern const struct iris_firmware_data iris_hfi_gen2_data;
>
> +extern const struct iris_platform_data qcm2290_data;
> extern const struct iris_platform_data qcs8300_data;
> extern const struct iris_platform_data sc7280_data;
> extern const struct iris_platform_data sm8250_data;
> diff --git a/drivers/media/platform/qcom/iris/iris_platform_vpu_ar50lt.c b/drivers/media/platform/qcom/iris/iris_platform_vpu_ar50lt.c
> new file mode 100644
> index 000000000000..393256f39112
> --- /dev/null
> +++ b/drivers/media/platform/qcom/iris/iris_platform_vpu_ar50lt.c
> @@ -0,0 +1,110 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#include "iris_core.h"
> +#include "iris_ctrls.h"
> +#include "iris_hfi_gen2.h"
> +#include "iris_hfi_gen2_defines.h"
> +#include "iris_platform_common.h"
> +#include "iris_vpu_buffer.h"
> +#include "iris_vpu_common.h"
> +
> +#define WRAPPER_INTR_STATUS_A2HWD_BMSK 0x10
> +
> +const struct iris_firmware_desc iris_vpu_ar50lt_p1_gen1_s6_desc = {
> + .firmware_data = &iris_hfi_gen1_ar50lt_data,
> + .get_vpu_buffer_size = iris_vpu_ar50lt_gen1_buf_size,
unlike gen2, gen1 is calling buffer_requirement from firmware for every
buffer types. And given that call is a synchronous call to firmware i.e
it calls and wait for a response, i see it can cause delay (and infact
not needed) if called for multiple internal buffer types. Can we see if
we can call that call once ? That call to firmware (get prop for
HFI_PROPERTY_CONFIG_BUFFER_REQUIREMENTS) fetches requirement for all
buffer types.
Regards,
Vikash
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: iio: dac: Add DAC8163
From: David Lechner @ 2026-06-24 14:14 UTC (permalink / raw)
To: Lukas Metz
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-kernel, linux-iio,
devicetree
In-Reply-To: <ajt0vibLhh6Mmhoc@berta-MS-7693>
On 6/24/26 1:25 AM, Lukas Metz wrote:
> Thanks a lot for the review. This is my first time submitting a
> patch so im grateful for the detailed comments and suggestions.
>
> On Tue, Jun 23, 2026 at 02:17:04PM -0500, David Lechner wrote:
>> It is more logical to put the dt-bindings patch first in the series
>> before the driver that makes use of it.
>
> I will reorder the commits in v2.
For future reference, you don't need to respond to comments that you
agree with (save us time reading).
>
>> There are a couple of more SPI properties needed since this is not a "normal"
>> SPI device. We can only write and not read because there is no D_OUT pin. So
>>
>> spi-rx-bus-width:
>> items:
>> - const: 0
>>
>> will describe this.
>
> I will the add the suggested changes to v2. Are there any other poperties
> i have missed? Same for the other comments regarding vendor-prefix,
> spi-max-frequency, avdd-supply and vref supply name.
>
>> We also want the binding to be complete even if the driver doesn't all of it, so
>> `clear-gpios` and `sync-gpios` probably make sense too.
>
> SYNC pin is the chip select pin of the device as described below. In
> that case i dont need to add it here right?
Ah, OK. It is probably worth mentioning that in the top-level description
here in the bindings.
>
>> Usually, we don't bother with a property like this since it is redundant.
>> If an external reference supply is given, then it gets used, otherwise
>> the internal reference is used.
>
> That sounds logical. I will remove the property completly.
>
>> These chips don't appear to have a chip select pin, so this comment
>> doesn't make sense to me. More logical would be to just use dac@0
>> and reg = <0>; since it should just be ignored.
>
> The SYNC pin on the device acts like a chip select pin.
> According to the datasheet: when the pin goes low it enables the input shift
> register. At least that was my understanding. On my board i have tested the
> driver with the chip select signal connected to the SYNC pin. The
> example comes straight from my own device tree where i have two devices
> on the bus. Thats why i used reg<1> here but i can change it to 0 and
> remove the comment.>
>> The pin is marked active low in the datasheet, so I would expect
>> this to be GPIO_ACTIVE_LOW.
>
> I wasnt sure about that. The pin needs to be held low continuously. I
> thought when the pin is marked active low and i initialize the pin with
> GPIOD_OUT_LOW the result will be that the pin is held high. To match the
> datasheet description seems logical though.
>
The GPIOD_OUT_LOW and GPIOD_OUT_HIGH names in the kernel are not ideal.
Think of them as "deasserted" and "asserted". If the devicetree has
GPIO_ACTIVE_LOW, then GPIOD_OUT_HIGH will "assert" the pin by pulling
the voltage low (because it is active low).
^ permalink raw reply
* Re: [PATCH v6 1/3] regulator: dt-bindings: Add Unisoc SC2730 PMIC
From: Mark Brown @ 2026-06-24 14:13 UTC (permalink / raw)
To: Rob Herring
Cc: Otto Pflüger, Liam Girdwood, Krzysztof Kozlowski,
Conor Dooley, Orson Zhai, Baolin Wang, Chunyan Zhang, Lee Jones,
linux-kernel, devicetree, Krzysztof Kozlowski
In-Reply-To: <20260624130613.GA4054894-robh@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 587 bytes --]
On Wed, Jun 24, 2026 at 08:06:13AM -0500, Rob Herring wrote:
> On Sat, Jun 20, 2026 at 10:54:00AM +0200, Otto Pflüger wrote:
> > Add bindings for the regulators found in the Spreadtrum/Unisoc SC2730
> > PMIC, used e.g. with the UMS512 and UMS9230 SoCs.
> >
> > Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
> > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> > ---
> > .../bindings/regulator/sprd,sc2730-regulator.yaml | 44 ++++++++++++++++++++++
> > 1 file changed, 44 insertions(+)
> Applied for rc1 to fix the warnings.
Warnings?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v6 1/2] dt-bindings: bridge: Add Lontium LT9611C(EX/UXD) MIPI DSI to HDMI driver
From: Krzysztof Kozlowski @ 2026-06-24 14:05 UTC (permalink / raw)
To: Sunyun Yang, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, dmitry.baryshkov, maarten.lankhorst, rfoss,
mripard
Cc: Laurent.pinchart, tzimmermann, jonas, jernej.skrabec, devicetree,
dri-devel, linux-kernel, xmzhu, xmzhu, rlyu, xbpeng
In-Reply-To: <CAFQXuNYq5QYAXRzcUBnyvVh5ofPBVYONCs1dM6qPgK0BDja5Ow@mail.gmail.com>
On 11/05/2026 05:28, Sunyun Yang wrote:
> <syyang@lontium.com> 于2026年5月8日周五 22:25写道：
>>
>> From: Sunyun Yang <syyang@lontium.com>
>>
>> LT9611C(EX/UXD) is an I2C-controlled chip that Receiver signal/dual port
>> mipi dsi and output hdmi, differences in hardware features:
>> - LT9611C: supports 1-port mipi dsi to hdmi 1.4
>> - LT9611EX: supports 2-port mipi dsi to hdmi 1.4
>> - LT9611UXD: supports 2-port mipi dsi to hdmi 1.4/2.0
>>
>> Signed-off-by: Sunyun Yang <syyang@lontium.com>
>> ---
>> .../bindings/display/bridge/lontium,lt9611.yaml | 8 ++++++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
>> index 429a06057ae8..e0821a63d9d7 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
>> +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
>> @@ -4,19 +4,23 @@
>> $id: http://devicetree.org/schemas/display/bridge/lontium,lt9611.yaml#
>> $schema: http://devicetree.org/meta-schemas/core.yaml#
>>
>> -title: Lontium LT9611(UXC) 2 Port MIPI to HDMI Bridge
>> +title: Lontium LT9611(UXC/C/EX/UXD) 2 Port MIPI DSI to HDMI Bridge
>>
>> maintainers:
>> - Vinod Koul <vkoul@kernel.org>
>>
>> description: |
>> - The LT9611 and LT9611UXC are bridge devices which convert DSI to HDMI
>> + The LT9611、LT9611UXC、LT9611C、LT9611EX and LT9611UXD
>> + are bridge devices which convert DSI to HDMI
>>
>> properties:
>> compatible:
>> enum:
>> - lontium,lt9611
>> + - lontium,lt9611c
>> + - lontium,lt9611ex
>> - lontium,lt9611uxc
>> + - lontium,lt9611uxd
>>
>> reg:
>> maxItems: 1
>> --
>
> Gentle ping.
> Thanks.
Except mess with threading, your patchset does not build, when applied
on next-20260618.
What is the base of this?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v4 4/4] arm64: dts: amlogic: meson-axg-s400: enable mipi_pcie_analog_dphy for PCIe
From: Jun Yan @ 2026-06-24 13:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260624135650.727077-1-jerrysteve1101@gmail.com>
The PCIe PHY node references mipi_pcie_analog_dphy via its phys property.
Enable this analog PHY node to make PCIe functionally viable.
Fixes: 9715b01da6cf ("arm64: dts: meson-axg-s400: enable PCIe M.2 Key E slots")
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 7ba249cc3d56..4f13e2b041e1 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -431,6 +431,10 @@ gpio_speaker: gpio-controller@1f {
};
};
+&mipi_pcie_analog_dphy {
+ status = "okay";
+};
+
&pdm {
pinctrl-0 = <&pdm_dclk_a14_pins>, <&pdm_din0_pins>,
<&pdm_din1_pins>, <&pdm_din2_pins>, <&pdm_din3_pins>;
--
2.54.0
^ permalink raw reply related
* [PATCH v4 3/4] arm64: dts: amlogic: meson-axg: Disable pcie_phy node by default
From: Jun Yan @ 2026-06-24 13:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260624135650.727077-1-jerrysteve1101@gmail.com>
Set the pcie_phy node to "disabled" as it is not used on some boards
and should be enabled per-board when necessary.
This change suppresses the deferred probe warning:
platform ff644000.phy: deferred probe pending: (reason unknown)
The meson-axg dtsi now disables pcie_phy by default, so enable it
for the s400 board to support PCIe functionality.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 4 ++++
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 1 +
2 files changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 285c6ac1dd61..7ba249cc3d56 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -448,6 +448,10 @@ &pcieB {
status = "okay";
};
+&pcie_phy {
+ status = "okay";
+};
+
&pwm_ab {
status = "okay";
pinctrl-0 = <&pwm_a_x20_pins>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 8ca3ac09b306..5b8ef98f6d03 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -328,6 +328,7 @@ pcie_phy: phy@ff644000 {
phys = <&mipi_pcie_analog_dphy>;
phy-names = "analog";
#phy-cells = <0>;
+ status = "disabled";
};
pdm: audio-controller@ff632000 {
--
2.54.0
^ permalink raw reply related
* [PATCH v4 2/4] arm64: dts: amlogic: meson-axg: Add missing nand_rb0 pin to nand_all_pins
From: Jun Yan @ 2026-06-24 13:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260624135650.727077-1-jerrysteve1101@gmail.com>
The nand_all_pins pinctrl node was missing the nand_rb0 (ready/busy)
pin description, which is required for NAND controller operation.
Add it to the pinmux list.
Fixes: be18d53c32b2 ("arm64: dts: amlogic: meson-axg: pinctrl node for NAND")
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 6457667d974e..8ca3ac09b306 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -481,7 +481,8 @@ mux {
"nand_ale",
"nand_cle",
"nand_wen_clk",
- "nand_ren_wr";
+ "nand_ren_wr",
+ "nand_rb0";
function = "nand";
input-enable;
bias-pull-up;
--
2.54.0
^ permalink raw reply related
* [PATCH v4 1/4] arm64: dts: amlogic: meson-axg: Disable nfc node by default
From: Jun Yan @ 2026-06-24 13:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260624135650.727077-1-jerrysteve1101@gmail.com>
nand_rb0 and emmc_ds share one pad. Before enabling nand_rb0 for nfc,
disable nfc nodes by default to resolve pinctrl resource contention.
No mainline AXG boards enable nfc currently thus no extra DTS adjustments
are needed.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index f1f53fd98ae2..6457667d974e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -1999,6 +1999,7 @@ nfc: nand-controller@7800 {
clocks = <&clkc CLKID_SD_EMMC_C>,
<&clkc CLKID_FCLK_DIV2>;
clock-names = "core", "device";
+ status = "disabled";
};
usb2_phy1: phy@9020 {
--
2.54.0
^ permalink raw reply related
* [PATCH v4 0/4] arm64: dts: amlogic: meson-axg: NAND fix and PCIe PHY adjustment
From: Jun Yan @ 2026-06-24 13:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
- Disable nfc node by default ahead of nand_rb0 pin addition.
- Add missing nand_rb0 pin to fix incomplete NAND pinctrl.
- Disable pcie_phy by default to suppress probe warning.
- Re-enable pcie_phy on S400 board to preserve PCIe functionality.
- Enable mipi_pcie_analog_dphy for PCIe on S400 board.
Changes in v4:
- Add patch to enable mipi_pcie_analog_dphy for PCIe on S400 board.
- Link to v3:
https://lore.kernel.org/all/20260617082239.645562-1-jerrysteve1101@gmail.com/
Changes in v3:
- squash "disable pcie_phy node by default" and "enable pcie_phy in
meson-axg-s400" patches
- Link to v2:
https://lore.kernel.org/all/20260617071604.635627-1-jerrysteve1101@gmail.com/
Changes in v2:
- Add patch to disable nfc node by default.
- Link to v1:
https://lore.kernel.org/all/20260529140605.1070764-1-jerrysteve1101@gmail.com/
Jun Yan (4):
arm64: dts: amlogic: meson-axg: Disable nfc node by default
arm64: dts: amlogic: meson-axg: Add missing nand_rb0 pin to
nand_all_pins
arm64: dts: amlogic: meson-axg: Disable pcie_phy node by default
arm64: dts: amlogic: meson-axg-s400: enable mipi_pcie_analog_dphy for
PCIe
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 8 ++++++++
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 5 ++++-
2 files changed, 12 insertions(+), 1 deletion(-)
--
2.54.0
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Suzuki K Poulose @ 2026-06-24 13:51 UTC (permalink / raw)
To: Jie Gan, Konrad Dybcio, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang,
Jingyi Wang, Abel Vesa, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <f39ec59f-97c4-4d5f-bf02-560adae312d9@oss.qualcomm.com>
On 24/06/2026 14:48, Jie Gan wrote:
>
>
> On 6/24/2026 9:27 PM, Konrad Dybcio wrote:
>> On 6/24/26 11:49 AM, Jie Gan wrote:
>>> The AMBA bus attempts to read the CID/PID of a device before invoking
>>> its probe function if the arm,primecell-periphid property is absent.
>>> This causes a deferred probe issue for the TraceNoC device, as the
>>> CID/PID cannot be read from the periphid register.
>>
>> Why does it probe defer?
>>
>
> For an AMBA device, the periphid is mandatory for probing. In the
> amba_match function, AMBA attempts to read the periphid from the CID/PID
> registers if the arm,primecell-periphid property is absent in the device
> tree. If this read fails, it returns -EPROBE_DEFER, and the probe
> ultimately fails.
Why does it fail ? power management ? hw broken ? Is it really AMBA or
do you pretend that to be an AMBA device by faking the CID/PID?
Suzuki
> Most AMBA devices expose valid CID/PID registers, so specifying
> arm,primecell-periphid in the device tree is usually unnecessary.
> However, for the TraceNoC device in this case, AMBA cannot reliably read
> the periphid from the corresponding registers.
>
>> And is this required for all TNOC devices?
>
> So far, the TNOC device has been added to sm8750, Glymur, and Kaanapali
> platforms, and all exhibit probe failures due to the same root cause.
>
> I prefer to fix it on Kaanapali first.
>
> Thanks,
> Jie
>
>>
>> Konrad
>
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Jie Gan @ 2026-06-24 13:48 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang, Jingyi Wang,
Abel Vesa, Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <f0634a64-1141-4ff9-9033-825e3c75d28d@oss.qualcomm.com>
On 6/24/2026 9:27 PM, Konrad Dybcio wrote:
> On 6/24/26 11:49 AM, Jie Gan wrote:
>> The AMBA bus attempts to read the CID/PID of a device before invoking
>> its probe function if the arm,primecell-periphid property is absent.
>> This causes a deferred probe issue for the TraceNoC device, as the
>> CID/PID cannot be read from the periphid register.
>
> Why does it probe defer?
>
For an AMBA device, the periphid is mandatory for probing. In the
amba_match function, AMBA attempts to read the periphid from the CID/PID
registers if the arm,primecell-periphid property is absent in the device
tree. If this read fails, it returns -EPROBE_DEFER, and the probe
ultimately fails.
Most AMBA devices expose valid CID/PID registers, so specifying
arm,primecell-periphid in the device tree is usually unnecessary.
However, for the TraceNoC device in this case, AMBA cannot reliably read
the periphid from the corresponding registers.
> And is this required for all TNOC devices?
So far, the TNOC device has been added to sm8750, Glymur, and Kaanapali
platforms, and all exhibit probe failures due to the same root cause.
I prefer to fix it on Kaanapali first.
Thanks,
Jie
>
> Konrad
^ permalink raw reply
* Re: [PATCH v3 6/7] ARM: dts: aspeed: g6: Change vuart compatible string for ast2600
From: Grégoire Layet @ 2026-06-24 13:44 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt, andrew, jacky_chou, yh_chung, ninad,
anirudhsriniv, linux-serial, linux-aspeed, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260624-copper-albatross-of-youth-6abae8@quoll>
Hi Krzysztof,
> Please start testing your patches. This for sure fails tests.
>
> It does not look like you tested the DTS against bindings. Please run
> 'make dtbs_check W=1' (see
> Documentation/devicetree/bindings/writing-schema.rst or
> https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
> for instructions).
> Maybe you need to update your dtschema and yamllint. Don't rely on
> distro packages for dtschema and be sure you are using the latest
> released dtschema.
You are right, I had tested my patches but wrongly. It is indeed failling.
I'm very sorry for that. Thank's for taking the time to explain.
Best regards,
Grégoire
^ permalink raw reply
* [PATCH] dt-bindings: mfd: khadas,mcu: Drop type reference from "fan-supply"
From: Rob Herring (Arm) @ 2026-06-24 13:36 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Krzysztof Kozlowski, Conor Dooley,
Ronald Claveau
Cc: Conor Dooley, linux-amlogic, devicetree, linux-kernel
"fan-supply" already has a type and shouldn't have a type $ref. Drop the
$ref to fix the warning.
Fixes: 39dd85d9246e ("dt-bindings: mfd: khadas: Add new compatible for Khadas VIM4 MCU")
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
---
Applying this to my tree and sending to Linus for rc1.
---
Documentation/devicetree/bindings/mfd/khadas,mcu.yaml | 1 -
1 file changed, 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
index 1f135618e3b6..c6f91e7bc8aa 100644
--- a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
+++ b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
@@ -28,7 +28,6 @@ properties:
fan-supply:
description: Phandle to the regulator that powers the fan.
- $ref: /schemas/types.yaml#/definitions/phandle
required:
- compatible
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v4 0/4] arm64: dts: qcom: Add IMDT QCS8550 SBC
From: William Bright @ 2026-06-24 13:34 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20260610-imdt-qcs8550-sbc-rfc-v4-0-358e71d606bc@imd-tec.com>
Hi all,
Another gentle ping on this patch series.
Many thanks,
Will
^ permalink raw reply
* Re: [PATCH 2/8] arm64: dts: qcom: sm8450: Remove unneeded reserved memory nodes
From: Konrad Dybcio @ 2026-06-24 13:28 UTC (permalink / raw)
To: Esteban Urrutia, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Will Deacon, Robin Murphy,
Joerg Roedel (AMD), Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-clk, linux-kernel, devicetree, iommu,
linux-arm-kernel, linux-phy
In-Reply-To: <b3541802-3035-40ee-8327-a65bd5d2dfee@proton.me>
On 6/24/26 3:26 PM, Esteban Urrutia wrote:
>
>
> On 6/23/26 7:03 AM, Konrad Dybcio wrote:
>>> This is mentioned in the memory map description, but is not part
>>> of it.
>>>
>>> I booted up a 8450 HDK and it doesn't even have MTE, so it's
>>> probably valid
>>
>> i.e. it doesn't report MTE to Linux. I don't know if it's Gunyah
>> trapping it.
> Then, should device trees delete these memory regions on a case-by-case
> basis, or be left as is?
I'd delete it and reintroduce as necessary
Konrad
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Konrad Dybcio @ 2026-06-24 13:27 UTC (permalink / raw)
To: Jie Gan, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang, Jingyi Wang,
Abel Vesa, Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <20260624-fix-tracenoc-probe-issue-v2-2-786520f62f21@oss.qualcomm.com>
On 6/24/26 11:49 AM, Jie Gan wrote:
> The AMBA bus attempts to read the CID/PID of a device before invoking
> its probe function if the arm,primecell-periphid property is absent.
> This causes a deferred probe issue for the TraceNoC device, as the
> CID/PID cannot be read from the periphid register.
Why does it probe defer?
And is this required for all TNOC devices?
Konrad
^ 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