* Re: [PATCH v2 2/3] arm64: dts: qcom: Add HP EliteBook X G2q 14 AI
From: t @ 2026-06-27 18:55 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Jason Pettit, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
Akhil P Oommen, Mahadevan P, Sibi Sankar, Jingyi Wang,
Ananthu C V
In-Reply-To: <c6966f05-b1bb-4b71-8373-c90995ab4cc3@oss.qualcomm.com>
From: Jason Pettit <jason.pettit@oss.qualcomm.com>
On Fri, 26 Jun 2026 13:27:42 +0200, Konrad Dybcio wrote:
> If you remove these two nodes, the QMPPHY-as-DP-only should still
> function (it's the USB3 block that depends on the QMPPHY, not the
> other way around)
I boot-tested this. With &usb_2 and &usb_2_hsphy removed, dmesg still
shows the af64000 DP controller binding and /sys/class/drm shows the
HDMI-A-1 connector as connected, but nothing is displayed on the attached
monitor. With both nodes present, the monitor shows an image.
So removing them stops HDMI from working on this board.
The comment in v3 will be updated to read:
/* usb_2's combo PHY drives the HDMI bridge over DP; keep the dwc3 enabled. */
Thanks,
Jason
^ permalink raw reply
* Re: [PATCH v2 2/3] arm64: dts: qcom: Add HP EliteBook X G2q 14 AI
From: t @ 2026-06-27 18:55 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Jason Pettit, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
Akhil P Oommen, Mahadevan P, Sibi Sankar, Jingyi Wang,
Ananthu C V
In-Reply-To: <e6c95342-b3a9-46bd-aeb2-a1384234476d@oss.qualcomm.com>
From: Jason Pettit <jason.pettit@oss.qualcomm.com>
On Fri, 26 Jun 2026 13:26:14 +0200, Konrad Dybcio wrote:
> I would assume it's simply not present (as every SMB2370 is a separate
> physical chip) - perhaps we should just add status = "disabled" in the
> DTSI file and enable the nodes on an as-needed basis
I'm not sure if the chip is populated, but I tested whether it enumerates.
With smb2370_l enabled, the SID-11 SPMI device (2-0b on the SPMI-2 bus)
fails to probe:
spmi spmi-2: pmic_arb_check_chnl_status_v1: 0xb 0x104: transaction failed (0x3)
pmic-spmi 2-0b: probe with driver pmic-spmi failed with error -5
The SPMI PMIC arbiter can't complete a transaction to SID 0xb, so pmic-spmi
can't read it and the eusb2 repeater doesn't bind pmic@b (only pmic@9 and
pmic@a come up). I keep it disabled.
Defaulting that in smb2370.dtsi would touch the shared file instead of just
this board, so I've left the override here for now. The comment in v3 will
be updated to read:
/*
* smb2370.dtsi enables all three repeaters by default; SID-11
* (smb2370_l) does not enumerate on this board, so override it back
* to disabled.
*/
Thanks,
Jason
^ permalink raw reply
* Re: [PATCH v2 2/3] arm64: dts: qcom: Add HP EliteBook X G2q 14 AI
From: Jason Pettit @ 2026-06-27 19:06 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Jason Pettit, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
Akhil P Oommen, Mahadevan P, Sibi Sankar, Jingyi Wang,
Ananthu C V
In-Reply-To: <c6966f05-b1bb-4b71-8373-c90995ab4cc3@oss.qualcomm.com>
On Fri, 26 Jun 2026 13:27:42 +0200, Konrad Dybcio wrote:
> If you remove these two nodes, the QMPPHY-as-DP-only should still
> function (it's the USB3 block that depends on the QMPPHY, not the
> other way around)
Apologies for the duplicate. My earlier copy of this reply went out with a
misconfigured sender identity from a local mail setup issue. Resending it
cleanly.
I boot-tested this. With &usb_2 and &usb_2_hsphy removed, dmesg still
shows the af64000 DP controller binding and /sys/class/drm shows the
HDMI-A-1 connector as connected, but nothing is displayed on the attached
monitor. With both nodes present, the monitor shows an image.
So removing them stops HDMI from working on this board.
The comment in v3 will be updated to read:
/* usb_2's combo PHY drives the HDMI bridge over DP; keep the dwc3 enabled. */
Thanks,
Jason
^ permalink raw reply
* Re: [PATCH v2 2/3] arm64: dts: qcom: Add HP EliteBook X G2q 14 AI
From: Jason Pettit @ 2026-06-27 19:06 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Jason Pettit, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
Akhil P Oommen, Mahadevan P, Sibi Sankar, Jingyi Wang,
Ananthu C V
In-Reply-To: <e6c95342-b3a9-46bd-aeb2-a1384234476d@oss.qualcomm.com>
On Fri, 26 Jun 2026 13:26:14 +0200, Konrad Dybcio wrote:
> I would assume it's simply not present (as every SMB2370 is a separate
> physical chip) - perhaps we should just add status = "disabled" in the
> DTSI file and enable the nodes on an as-needed basis
Apologies for the duplicate. My earlier copy of this reply went out with a
misconfigured sender identity from a local mail setup issue. Resending it
cleanly.
I'm not sure if the chip is populated, but I tested whether it enumerates.
With smb2370_l enabled, the SID-11 SPMI device (2-0b on the SPMI-2 bus)
fails to probe:
spmi spmi-2: pmic_arb_check_chnl_status_v1: 0xb 0x104: transaction failed (0x3)
pmic-spmi 2-0b: probe with driver pmic-spmi failed with error -5
The SPMI PMIC arbiter can't complete a transaction to SID 0xb, so pmic-spmi
can't read it and the eusb2 repeater doesn't bind pmic@b (only pmic@9 and
pmic@a come up). I keep it disabled.
Defaulting that in smb2370.dtsi would touch the shared file instead of just
this board, so I've left the override here for now. The comment in v3 will
be updated to read:
/*
* smb2370.dtsi enables all three repeaters by default; SID-11
* (smb2370_l) does not enumerate on this board, so override it back
* to disabled.
*/
Thanks,
Jason
^ permalink raw reply
* Re: [PATCH v4 2/2] iio: magnetometer: add support for Melexis MLX90393
From: David Lechner @ 2026-06-27 19:49 UTC (permalink / raw)
To: Nikhil Gautam, linux-iio
Cc: jic23, nuno.sa, andy, u.kleine-koenig, robh, krzk+dt, conor+dt,
devicetree, linux-kernel
In-Reply-To: <20260627095519.8377-3-nikhilgtr@gmail.com>
On 6/27/26 4:55 AM, Nikhil Gautam wrote:
> Add Industrial I/O subsystem support for the Melexis
> MLX90393 3-axis magnetometer and temperature sensor.
>
> The driver currently supports:
>
> raw magnetic field measurements
> raw temperature measurements
> configurable gain/scale selection
> configurable oversampling ratio
> direct mode operation
>
> The MLX90393 supports both I2C and SPI interfaces. This
> initial implementation adds support for the I2C interface.
>
> The device uses a command-based communication protocol
> rather than a conventional register-addressed interface.
> A small transport abstraction layer is therefore used
> instead of regmap to share the common sensor logic
> between the current I2C implementation and future SPI
> support without duplicating code.
>
> Signed-off-by: Nikhil Gautam <nikhilgtr@gmail.com>
> ---
> MAINTAINERS | 1 +
> drivers/iio/magnetometer/Kconfig | 10 +
> drivers/iio/magnetometer/Makefile | 2 +
> drivers/iio/magnetometer/mlx90393.h | 73 +++
> drivers/iio/magnetometer/mlx90393_core.c | 701 +++++++++++++++++++++++
> drivers/iio/magnetometer/mlx90393_i2c.c | 76 +++
> 6 files changed, 863 insertions(+)
> create mode 100644 drivers/iio/magnetometer/mlx90393.h
> create mode 100644 drivers/iio/magnetometer/mlx90393_core.c
> create mode 100644 drivers/iio/magnetometer/mlx90393_i2c.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 469ae3f9aa0f..177dda261801 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -15506,6 +15506,7 @@ M: Nikhil Gautam <nikhilgtr@gmail.com>
> L: linux-iio@vger.kernel.org
> S: Maintained
> F: Documentation/devicetree/bindings/iio/magnetometer/melexis,mlx90393.yaml
> +F: drivers/iio/magnetometer/mlx90393*
>
> MELEXIS MLX90614 DRIVER
> M: Crt Mori <cmo@melexis.com>
> diff --git a/drivers/iio/magnetometer/Kconfig b/drivers/iio/magnetometer/Kconfig
> index 3debf1320ad1..e6b74e7e3317 100644
> --- a/drivers/iio/magnetometer/Kconfig
> +++ b/drivers/iio/magnetometer/Kconfig
> @@ -128,6 +128,16 @@ config HID_SENSOR_MAGNETOMETER_3D
> Say yes here to build support for the HID SENSOR
> Magnetometer 3D.
>
> +config MLX90393
> + tristate "MELEXIS MLX90393 3-axis magnetometer sensor"
> + depends on I2C
> + help
> + Say yes here to build support for the MELEXIS MLX90393 3-axis
> + magnetometer.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called mlx90393.
> +
> config MMC35240
> tristate "MEMSIC MMC35240 3-axis magnetic sensor"
> select REGMAP_I2C
> diff --git a/drivers/iio/magnetometer/Makefile b/drivers/iio/magnetometer/Makefile
> index 9297723a97d8..542c89d38a59 100644
> --- a/drivers/iio/magnetometer/Makefile
> +++ b/drivers/iio/magnetometer/Makefile
> @@ -14,6 +14,8 @@ obj-$(CONFIG_BMC150_MAGN_SPI) += bmc150_magn_spi.o
>
> obj-$(CONFIG_MAG3110) += mag3110.o
> obj-$(CONFIG_HID_SENSOR_MAGNETOMETER_3D) += hid-sensor-magn-3d.o
> +obj-$(CONFIG_MLX90393) += mlx90393_core.o
> +obj-$(CONFIG_MLX90393) += mlx90393_i2c.o
Seems like the tabs are just making it more messy.
I would just go with one space.
> obj-$(CONFIG_MMC35240) += mmc35240.o
>
> obj-$(CONFIG_IIO_ST_MAGN_3AXIS) += st_magn.o
> diff --git a/drivers/iio/magnetometer/mlx90393.h b/drivers/iio/magnetometer/mlx90393.h
> new file mode 100644
> index 000000000000..6a646ac05198
> --- /dev/null
> +++ b/drivers/iio/magnetometer/mlx90393.h
> @@ -0,0 +1,73 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * MLX90393 magnetometer & temperature sensor driver
> + *
> + * Copyright (c) 2026 Nikhil Gautam <nikhilgtr@gmail.com>
> + */
> +
> +#ifndef MLX90393_H
> +#define MLX90393_H
> +
> +#include <linux/bits.h>
> +#include <linux/types.h>
> +
> +#define MLX90393_AXIS_MAX 2
> +#define MLX90393_GAIN_MAX 8
> +#define MLX90393_RES_MAX 4
> +#define MLX90393_OSR2_MAX 4
> +#define MLX90393_OSR_MAX 4
> +
> +#define MLX90393_CMD_MASK GENMASK(7, 4)
> +
> +/* Commands (datasheet, Table 11 - Command List) */
> +#define MLX90393_CMD_SB 0x10 /* Start Burst Mode */
> +#define MLX90393_CMD_SW 0x20 /* Start Wake-up on Change Mode */
> +#define MLX90393_CMD_SM 0x30 /* Start Single Measurement Mode */
> +#define MLX90393_CMD_RM 0x40 /* Read Measurement */
> +#define MLX90393_CMD_RR 0x50 /* Read Register */
> +#define MLX90393_CMD_WR 0x60 /* Write Register */
> +#define MLX90393_CMD_EX 0x80 /* Exit Mode */
> +#define MLX90393_CMD_HR 0xD0 /* Memory Recall */
> +#define MLX90393_CMD_HS 0xE0 /* Memory Store */
> +#define MLX90393_CMD_RT 0xF0 /* Reset Device */
> +
> +#define MLX90393_MEASURE_Z BIT(0)
> +#define MLX90393_MEASURE_Y BIT(1)
> +#define MLX90393_MEASURE_X BIT(2)
> +#define MLX90393_MEASURE_TEMP BIT(3)
> +
> +#define MLX90393_MEASURE_ALL (MLX90393_MEASURE_TEMP | \
> + MLX90393_MEASURE_X | MLX90393_MEASURE_Y | MLX90393_MEASURE_Z)
> +
> +#define MLX90393_NUM_CHANNELS 4
> +
> +#define MLX90393_STATUS_RESP GENMASK(1, 0)
> +#define MLX90393_STATUS_RT BIT(2)
> +#define MLX90393_STATUS_ERROR BIT(4)
> +
> +#define MLX90393_REG_CONF1 0x00
> +#define MLX90393_REG_CONF2 0x01
> +#define MLX90393_REG_CONF3 0x02
> +#define MLX90393_REG_CONF4 0x03
> +
> +#define MLX90393_CONF1_GAIN_SEL GENMASK(6, 4)
> +#define MLX90393_CONF1_HALLCONF GENMASK(3, 0)
> +
> +#define MLX90393_CONF3_OSR GENMASK(1, 0)
> +#define MLX90393_CONF3_DIG_FILT GENMASK(4, 2)
> +#define MLX90393_CONF3_RES_X GENMASK(6, 5)
> +#define MLX90393_CONF3_RES_Y GENMASK(8, 7)
> +#define MLX90393_CONF3_RES_Z GENMASK(10, 9)
> +#define MLX90393_CONF3_OSR2 GENMASK(12, 11)
> +
> +struct device;
> +
> +struct mlx90393_transfer_ops {
> + int (*xfer)(void *context, const u8 *tx, int tx_len, u8 *rx, int rx_len);
> +};
> +
> +int mlx90393_core_probe(struct device *dev,
> + const struct mlx90393_transfer_ops *ops,
> + void *context);
> +
> +#endif
> diff --git a/drivers/iio/magnetometer/mlx90393_core.c b/drivers/iio/magnetometer/mlx90393_core.c
> new file mode 100644
> index 000000000000..78fcab8a2b56
> --- /dev/null
> +++ b/drivers/iio/magnetometer/mlx90393_core.c
> @@ -0,0 +1,701 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * MLX90393 magnetometer & temperature sensor driver
> + *
> + * Copyright (c) 2026 Nikhil Gautam <nikhilgtr@gmail.com>
> + *
> + * Datasheet: https://media.melexis.com/-/media/files/documents/datasheets/mlx90393-datasheet-melexis.pdf
> + */
> +
> +#include <linux/array_size.h>
> +#include <linux/bitfield.h>
> +#include <linux/bitops.h>
> +#include <linux/errno.h>
> +#include <linux/delay.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/types.h>
> +#include <linux/time64.h>
> +#include <linux/unaligned.h>
> +#include <linux/units.h>
> +
> +#include <linux/iio/iio.h>
> +
> +#include "mlx90393.h"
> +
> +struct mlx90393_data {
> + /* Protects sensor configuration and measurement operations */
> + struct mutex lock;
> + struct device *dev;
> + void *bus_context;
> + const struct mlx90393_transfer_ops *ops;
> + u8 gain_sel;
> + u8 hallconf;
> +
> + u8 res_xy;
> + u8 res_z;
> +
> + u8 dig_filt;
> + u8 osr;
> + u8 osr2;
> +};
> +
> +enum mlx90393_channels {
> + MLX90393_CHAN_X,
> + MLX90393_CHAN_Y,
> + MLX90393_CHAN_Z,
> + MLX90393_CHAN_TEMP,
> +};
> +
> +enum mlx90393_axis_type {
> + MLX90393_AXIS_TYPE_XY,
> + MLX90393_AXIS_TYPE_Z,
> +};
> +
> +/* Datasheet: Table no.17 */
It would be more helpful to also say that this is nanotesela per LSB at 25 deg C.
And probably also explain why we don't care about the 35 deg C table.
> +static const int mlx90393_scale_table[MLX90393_AXIS_MAX][MLX90393_GAIN_MAX]
> + [MLX90393_RES_MAX] = {
> + /* XY axis */
> + {
> + { 751, 1502, 3004, 6009},
> + { 601, 1202, 2403, 4840},
> + { 451, 901, 1803, 3605},
> + { 376, 751, 1502, 3004},
> + { 300, 601, 1202, 2403},
> + { 250, 501, 1001, 2003},
> + { 200, 401, 801, 1602},
> + { 150, 300, 601, 1202},
> + },
> + /* Z axis */
> + {
> + { 1210, 2420, 4840, 9680},
> + { 968, 1936, 3872, 7744},
> + { 726, 1452, 2904, 5808},
> + { 605, 1210, 2420, 4840},
> + { 484, 968, 1936, 3872},
> + { 403, 807, 1613, 3227},
> + { 323, 645, 1291, 2581},
> + { 242, 484, 968, 1936},
> + }
> +};
> +
> +static const int mlx90393_osr2_avail[MLX90393_OSR2_MAX] = {
> + 0, 1, 2, 3,
OSR of 0 does not make sense. It would mean 0 samples, which would
be no data. Should this be the same as OSR below?
> +};
> +
> +static const int mlx90393_osr_avail[MLX90393_OSR_MAX] = {
> + 1, 2, 4, 8,
> +};
> +
> +#define MLX90393_CHAN(idx, axis, addr) { \
> + .type = IIO_MAGN, \
> + .modified = 1, \
> + .channel = idx, \
> + .address = addr, \
> + .channel2 = IIO_MOD_##axis, \
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
> + BIT(IIO_CHAN_INFO_SCALE), \
> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO),\
> + .info_mask_separate_available = \
> + BIT(IIO_CHAN_INFO_SCALE), \
> + .info_mask_shared_by_type_available = \
> + BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO), \
> +}
> +
> +static const struct iio_chan_spec mlx90393_channels[] = {
> + MLX90393_CHAN(0, X, MLX90393_CHAN_X),
> + MLX90393_CHAN(1, Y, MLX90393_CHAN_Y),
> + MLX90393_CHAN(2, Z, MLX90393_CHAN_Z),
> + {
> + .type = IIO_TEMP,
> + .address = MLX90393_CHAN_TEMP,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> + BIT(IIO_CHAN_INFO_OFFSET) |
> + BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO),
> + .info_mask_separate_available =
> + BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO),
> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),
It would make the attribute names a bit more symetric if
IIO_CHAN_INFO_OVERSAMPLING_RATIO was shared_by_type and
IIO_CHAN_INFO_SCALE was separate just like the mag channels.
> + },
> +};
> +
> +/*
> + * Calculate total conversion time in microseconds.
> + *
> + * Formula derived from datasheet timing equations.
> + * Datasheet: Table 8, Page no. 12
> + *
> + * Abbreviations:
> + * TCONVM -> Single Magnetic axis conversion time
> + * TCONVT -> Temperature conversion time
> + * TSTBY -> Time from IDLE to STANDBY
> + * TACTIVE -> Time from STBY to ACTIVE
> + * TCONV_END -> Time to end analog active mode
> + */
> +static int mlx90393_get_tconv_us(struct mlx90393_data *data)
> +{
> + const int osr = data->osr;
> + const int osr2 = data->osr2;
> + const int df = data->dig_filt;
> +
> + int tconvm;
> + int tconvt;
> +
> + int m = 3; /* X,Y,Z */
const
> +
> + /*
> + * TCONVM = 67 + 64 * 2^OSR * (2 + 2^DIG_FILT)
> + */
Can be single line comment.
> + tconvm = 67 + (64 * BIT(osr) * (2 + BIT(df)));
> +
> + /*
> + * TCONVT = 67 + 192 * 2^OSR2
> + */
ditto
> + tconvt = 67 + (192 * BIT(osr2));
> + /*
> + * Total conversion time:
> + * TSTBY + TACTIVE + m * TCONVM + TCONVT + TCONV_END
> + */
> + return 220 + 360 + (m * tconvm) + tconvt + 120;
Unnecessary ().
> +}
> +
> +static int mlx90393_xfer(struct mlx90393_data *data,
> + const u8 *tx, int tx_len,
> + u8 *rx, int rx_len)
> +{
> + return data->ops->xfer(data->bus_context, tx, tx_len, rx, rx_len);
> +}
> +
> +static int mlx90393_check_status(u8 cmd, u8 status)
> +{
> + /* Datasheet: Table 12: Status byte definition */
> +
> + /* Always validate error bit */
> + if (status & MLX90393_STATUS_ERROR)
> + return -EIO;
> +
> + switch (cmd & MLX90393_CMD_MASK) {
> + case MLX90393_CMD_RM:
> + /*
> + * D1:D0 indicates response availability
> + * 00 means invalid/no measurement
> + */
> + if ((status & MLX90393_STATUS_RESP) == 0)
> + return -EIO;
Should this have a different error code? In other words,
does this just mean "try again later and there might be
data"?
> + return 0;
> + case MLX90393_CMD_RT:
> + /* Reset acknowledge */
> + if ((status & MLX90393_STATUS_RT) == 0)
> + return -EIO;
Datasheet calls this RS bit, not RT (which is the cooresponding
command).
> + return 0;
> + default:
> + return 0;
> + }
> +}
> +
> +static int mlx90393_write_cmd(struct mlx90393_data *data, u8 cmd)
> +{
> + u8 status;
> + int ret;
> +
> + ret = mlx90393_xfer(data, &cmd, 1, &status, 1);
> + if (ret)
> + return ret;
> +
> + return mlx90393_check_status(cmd, status);
> +}
> +
> +static int mlx90393_read_cmd(struct mlx90393_data *data, u8 cmd, u8 *rx,
> + int rx_len)
> +{
> + int ret;
> +
> + ret = mlx90393_xfer(data, &cmd, 1, rx, rx_len);
> + if (ret)
> + return ret;
> +
> + return mlx90393_check_status(cmd, rx[0]);
> +}
> +
> +static int mlx90393_read_reg(struct mlx90393_data *data, u8 reg, u16 *val)
> +{
> + u8 tx[2];
> + u8 rx[3];
> + int ret;
> +
> + tx[0] = MLX90393_CMD_RR;
> + /* Register address is encoded in bits [7:2] */
> + tx[1] = reg << 2;
> +
> + ret = mlx90393_xfer(data, tx, sizeof(tx), rx, sizeof(rx));
> + if (ret)
> + return ret;
> +
> + ret = mlx90393_check_status(tx[0], rx[0]);
> + if (ret)
> + return ret;
> +
> + *val = get_unaligned_be16(&rx[1]);
> +
> + return 0;
> +}
> +
> +static int mlx90393_write_reg(struct mlx90393_data *data, u8 reg, u16 val)
> +{
> + u8 tx[4];
> + u8 status;
> + int ret;
> +
> + tx[0] = MLX90393_CMD_WR;
> + put_unaligned_be16(val, &tx[1]);
> + /* Register address is encoded in bits [7:2] */
> + tx[3] = reg << 2;
> +
> + ret = mlx90393_xfer(data, tx, sizeof(tx), &status, 1);
> + if (ret)
> + return ret;
> +
> + return mlx90393_check_status(tx[0], status);
> +}
> +
> +static int mlx90393_update_bits(struct mlx90393_data *data, u8 reg,
> + u16 mask, u16 val)
> +{
> + u16 reg_val;
> + int ret;
> +
> + ret = mlx90393_read_reg(data, reg, ®_val);
> + if (ret)
> + return ret;
> +
> + reg_val &= ~mask;
> + reg_val |= (val << __ffs(mask)) & mask;
Usually, we would call FIELD_PREP() before passing val rather
than doing this here. As it is, this doesn't allow updating
multiple fields at the same time.
> +
> + return mlx90393_write_reg(data, reg, reg_val);
> +}
Why not create a regmap with a custom bus type instead of reimplementing
functions like this?
> +
> +static int mlx90393_read_measurement(struct mlx90393_data *data,
> + enum mlx90393_channels chan, int *val)
> +{
> + u8 rx[9];
> + int ret;
> +
> + /* Start measurement */
> + ret = mlx90393_write_cmd(data, MLX90393_CMD_SM | MLX90393_MEASURE_ALL);
> + if (ret)
> + return ret;
> +
> + /* Wait conversion */
> + fsleep(mlx90393_get_tconv_us(data));
> +
> + /* Read measurement */
> + ret = mlx90393_read_cmd(data, MLX90393_CMD_RM | MLX90393_MEASURE_ALL,
> + rx, sizeof(rx));
> + if (ret)
> + return ret;
> + /*
> + * Measurement response layout:
> + * [status][temp][x][y][z]
Would be more useful if this also said how many bytes each field is.
Although not sure how useful comment is since we can see this below.
Other than mentioning that status is ignored.
> + */
> +
> + switch (chan) {
> + case MLX90393_CHAN_TEMP:
> + *val = get_unaligned_be16(&rx[1]);
> + return 0;
> +
> + case MLX90393_CHAN_X:
> + *val = sign_extend32(get_unaligned_be16(&rx[3]), 15);
> + return 0;
> +
> + case MLX90393_CHAN_Y:
> + *val = sign_extend32(get_unaligned_be16(&rx[5]), 15);
> + return 0;
> +
> + case MLX90393_CHAN_Z:
> + *val = sign_extend32(get_unaligned_be16(&rx[7]), 15);
> + return 0;
> +
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int mlx90393_get_scale(struct mlx90393_data *data,
Would be nice if the function name included _mag_ since this doesn't
include the temperature scale.
> + const struct iio_chan_spec *chan,
> + int *val, int *val2)
> +{
> + enum mlx90393_axis_type axis;
> + u8 res;
> +
> + if (chan->channel2 == IIO_MOD_Z) {
> + axis = MLX90393_AXIS_TYPE_Z;
> + res = data->res_z;
> + } else {
> + axis = MLX90393_AXIS_TYPE_XY;
> + res = data->res_xy;
> + }
> +
> + *val = 0;
> + *val2 = mlx90393_scale_table[axis][data->gain_sel][res];
> +
> + return IIO_VAL_INT_PLUS_NANO;
> +}
> +
> +static int mlx90393_find_scale(struct mlx90393_data *data, bool z_axis,
same here.
> + int val, int val2,
> + int *gain)
don't need to wrap this last line.
> +{
> + u8 res;
> + enum mlx90393_axis_type axis;
Putting enum first (like the previous funtion) looks nicer.
> +
> + if (z_axis) {
> + axis = MLX90393_AXIS_TYPE_Z;
> + res = data->res_z;
> + } else {
> + axis = MLX90393_AXIS_TYPE_XY;
> + res = data->res_xy;
> + }
> +
> + if (val != 0)
> + return -EINVAL;
> +
> + for (unsigned int i = 0; i < ARRAY_SIZE(mlx90393_scale_table[0]); i++) {
> + if (mlx90393_scale_table[axis][i][res] == val2) {
> + *gain = i;
> + return 0;
> + }
> + }
> +
> + return -EINVAL;
> +}
> +
> +static int mlx90393_set_scale(struct mlx90393_data *data,
> + const struct iio_chan_spec *chan,
> + int val, int val2)
> +{
> + bool z_axis;
> + int gain;
> + int ret;
> +
> + z_axis = chan->channel2 == IIO_MOD_Z;
> +
> + ret = mlx90393_find_scale(data, z_axis, val, val2, &gain);
> + if (ret)
> + return ret;
> +
> + ret = mlx90393_update_bits(data, MLX90393_REG_CONF1, MLX90393_CONF1_GAIN_SEL,
> + gain);
> + if (ret)
> + return ret;
> +
> + data->gain_sel = gain;
> + return 0;
> +}
> +
> +static int mlx90393_get_osr(struct mlx90393_data *data, int *val)
> +{
> + *val = mlx90393_osr_avail[data->osr];
> + return IIO_VAL_INT;
> +}
> +
> +static int mlx90393_find_osr(int val, int *osr)
> +{
> + for (unsigned int i = 0; i < MLX90393_OSR_MAX; i++) {
> + if (mlx90393_osr_avail[i] == val) {
> + *osr = i;
> + return 0;
> + }
> + }
> +
> + return -EINVAL;
> +}
The two functions above are quite simple and only used once each.
They could just be done inline instead.
> +
> +static int mlx90393_get_temp_osr2(struct mlx90393_data *data, int *val)
> +{
> + *val = mlx90393_osr2_avail[data->osr2];
> + return IIO_VAL_INT;
> +}
> +
> +static int mlx90393_set_osr(struct mlx90393_data *data, int val)
Would be more logical to keep this with other osr functions instead of
being in the middle of osr2 functions.
> +{
> + int osr;
> + int ret;
> +
> + ret = mlx90393_find_osr(val, &osr);
> + if (ret)
> + return ret;
> +
> + if (osr == data->osr)
> + return 0;
> +
> + ret = mlx90393_update_bits(data, MLX90393_REG_CONF3, MLX90393_CONF3_OSR,
> + osr);
> + if (ret)
> + return ret;
> +
> + data->osr = osr;
> + return 0;
> +}
> +
> +static int mlx90393_set_temp_osr2(struct mlx90393_data *data, int val)
> +{
> + int ret;
> +
> + if (val < 0 || val >= MLX90393_OSR2_MAX)
> + return -EINVAL;
As mentioned already, allowing 0 doesn't make sense for oversampling_ratio.
> +
> + if (val == data->osr2)
> + return 0;
> +
> + ret = mlx90393_update_bits(data, MLX90393_REG_CONF3, MLX90393_CONF3_OSR2,
> + val);
> + if (ret)
> + return ret;
> +
> + data->osr2 = val;
> +
> + return 0;
> +}
> +
> +static int mlx90393_write_raw_get_fmt(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + long mask)
> +{
> + switch (mask) {
> + case IIO_CHAN_INFO_SCALE:
> + return IIO_VAL_INT_PLUS_NANO;
> +
> + case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
> + return IIO_VAL_INT;
> +
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int mlx90393_write_raw(struct iio_dev *indio_dev,
> + const struct iio_chan_spec *chan,
> + int val, int val2,
> + long mask)
> +{
> + struct mlx90393_data *data = iio_priv(indio_dev);
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_SCALE: {
> + guard(mutex)(&data->lock);
> + return mlx90393_set_scale(data, chan, val, val2);
> + }
> +
> + case IIO_CHAN_INFO_OVERSAMPLING_RATIO: {
> + guard(mutex)(&data->lock);
> + switch (chan->type) {
> + case IIO_TEMP:
> + return mlx90393_set_temp_osr2(data, val);
> +
> + case IIO_MAGN:
> + return mlx90393_set_osr(data, val);
> +
> + default:
> + return -EINVAL;
> + }
> + }
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int mlx90393_read_raw(struct iio_dev *indio_dev,
> + const struct iio_chan_spec *chan,
> + int *val, int *val2, long mask)
> +{
> + struct mlx90393_data *data = iio_priv(indio_dev);
> + int ret;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW: {
> + guard(mutex)(&data->lock);
> + ret = mlx90393_read_measurement(data, chan->address, val);
> + if (ret)
> + return ret;
> +
> + return IIO_VAL_INT;
> + }
One too many tabs before }.
> + case IIO_CHAN_INFO_SCALE:
> + switch (chan->type) {
> + case IIO_MAGN:
> + return mlx90393_get_scale(data, chan, val, val2);
> +
> + case IIO_TEMP:
> + /*
> + * Datasheet Table 7: Thermal Specification
> + */
Comment fits on one line.
> + *val = 0;
> + *val2 = 22124;
It this converting to millideg C?
From 45.2 LSB/deg C, I got:
*val = 22;
*val2 = 123893;
> + return IIO_VAL_INT_PLUS_MICRO;
> +
> + default:
> + return -EINVAL;
> + }
> +
> + case IIO_CHAN_INFO_OFFSET:
> + if (chan->type != IIO_TEMP)
> + return -EINVAL;
> + /*
> + * Datasheet Table 7: Thermal Specification
> + */
> +
> + *val = -45114;
> + return IIO_VAL_INT;
> +
> + case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
> + switch (chan->type) {
> + case IIO_TEMP:
> + return mlx90393_get_temp_osr2(data, val);
> + case IIO_MAGN:
> + return mlx90393_get_osr(data, val);
> + default:
> + return -EINVAL;
> + }
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int mlx90393_read_avail(struct iio_dev *indio_dev,
> + const struct iio_chan_spec *chan,
> + const int **vals,
> + int *type,
> + int *length,
> + long mask)
> +{
> + struct mlx90393_data *data = iio_priv(indio_dev);
> + static int scale_avail[MLX90393_GAIN_MAX][MLX90393_AXIS_MAX];
> + enum mlx90393_axis_type axis;
> + u8 res;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_SCALE: {
> + guard(mutex)(&data->lock);
> + axis = chan->channel2 == IIO_MOD_Z;
> + res = axis ? data->res_z : data->res_xy;
> +
> + for (unsigned int i = 0; i < MLX90393_GAIN_MAX; i++) {
> + scale_avail[i][0] = 0;
> + scale_avail[i][1] =
> + mlx90393_scale_table[axis][i][res];
> + }
> +
> + *vals = &scale_avail[0][0];
> + *type = IIO_VAL_INT_PLUS_NANO;
> + *length = MLX90393_GAIN_MAX * MLX90393_AXIS_MAX;
Although MLX90393_AXIS_MAX has the correct value of 2, it doesn't
makes sense semantically. The 2 just comes from the fact we have
2 ints per value in the array. Just use `2` here directly.
> + return IIO_AVAIL_LIST;
> + }
> +
> + case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
> + if (chan->type == IIO_TEMP) {
> + *vals = mlx90393_osr2_avail;
> + *type = IIO_VAL_INT;
> + *length = MLX90393_OSR2_MAX;
> + } else {
> + *vals = mlx90393_osr_avail;
> + *type = IIO_VAL_INT;
> + *length = MLX90393_OSR_MAX;
> + }
> + return IIO_AVAIL_LIST;
> +
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static const struct iio_info mlx90393_info = {
> + .read_raw = mlx90393_read_raw,
> + .write_raw = mlx90393_write_raw,
> + .read_avail = mlx90393_read_avail,
> + .write_raw_get_fmt = mlx90393_write_raw_get_fmt,
> +};
> +
> +static int mlx90393_init(struct mlx90393_data *data)
> +{
> + int ret;
> + u16 reg;
> +
> + /* Exit mode */
> + ret = mlx90393_write_cmd(data, MLX90393_CMD_EX);
> + if (ret)
> + return ret;
> +
> + /*
> + * Datasheet section 15.4.1.2 (RT command), Figure 16:
> + * Wait 1 ms after EX command before issuing RT.
> + */
> + fsleep(1 * USEC_PER_MSEC);
> +
> + /* Reset device */
> + ret = mlx90393_write_cmd(data, MLX90393_CMD_RT);
> + if (ret)
> + return ret;
> +
> + /*
> + * Datasheet section 15.4.1.2 (RT command), Figure 16:
> + * Wait 1.5 ms for the start-up sequence to complete.
> + */
> + fsleep(1.5 * USEC_PER_MSEC);
> +
> + ret = mlx90393_read_reg(data, MLX90393_REG_CONF1, ®);
> + if (ret)
> + return ret;
> +
> + data->gain_sel = FIELD_GET(MLX90393_CONF1_GAIN_SEL, reg);
> + data->hallconf = FIELD_GET(MLX90393_CONF1_HALLCONF, reg);
We should know the default values after reset already, so could
hard-code them instead, no?
> +
> + ret = mlx90393_read_reg(data, MLX90393_REG_CONF3, ®);
> + if (ret)
> + return ret;
> +
> + data->res_xy = FIELD_GET(MLX90393_CONF3_RES_X, reg);
> + data->res_z = FIELD_GET(MLX90393_CONF3_RES_Z, reg);
> + data->dig_filt = FIELD_GET(MLX90393_CONF3_DIG_FILT, reg);
> + data->osr = FIELD_GET(MLX90393_CONF3_OSR, reg);
> + data->osr2 = FIELD_GET(MLX90393_CONF3_OSR2, reg);
Same here.
> +
> + return 0;
> +}
> +
> +int mlx90393_core_probe(struct device *dev,
> + const struct mlx90393_transfer_ops *ops,
> + void *context)
> +{
> + struct iio_dev *indio_dev;
> + struct mlx90393_data *data;
> + int ret;
> +
> + indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
> + if (!indio_dev)
> + return -ENOMEM;
> +
> + data = iio_priv(indio_dev);
> + ret = devm_mutex_init(dev, &data->lock);
> + if (ret)
> + return ret;
> +
> + data->dev = dev;
> + data->ops = ops;
> + data->bus_context = context;
> +
> + indio_dev->name = "mlx90393";
> + indio_dev->info = &mlx90393_info;
> + indio_dev->modes = INDIO_DIRECT_MODE;
> + indio_dev->channels = mlx90393_channels;
> + indio_dev->num_channels = ARRAY_SIZE(mlx90393_channels);
> +
> + ret = mlx90393_init(data);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to initialize device\n");
> +
> + return devm_iio_device_register(dev, indio_dev);
> +}
> +EXPORT_SYMBOL_NS_GPL(mlx90393_core_probe, "IIO_MLX90393");
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Nikhil Gautam <nikhilgtr@gmail.com>");
> +MODULE_DESCRIPTION("MLX90393 magnetometer sensor driver");
> diff --git a/drivers/iio/magnetometer/mlx90393_i2c.c b/drivers/iio/magnetometer/mlx90393_i2c.c
> new file mode 100644
> index 000000000000..a9f0a40d15e8
> --- /dev/null
> +++ b/drivers/iio/magnetometer/mlx90393_i2c.c
> @@ -0,0 +1,76 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +#include <linux/array_size.h>
> +#include <linux/errno.h>
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/mod_devicetable.h>
> +
> +#include "mlx90393.h"
> +
> +/*
> + * MLX90393 commands use repeated-start transfers where
> + * every command is followed by a status/data response.
> + */
> +static int mlx90393_i2c_xfer(void *context,
> + const u8 *tx, int tx_len,
> + u8 *rx, int rx_len)
> +{
> + struct i2c_client *client = context;
> + int ret;
> + struct i2c_msg msgs[2] = {
> + [0] = {
> + .addr = client->addr,
> + .len = tx_len,
> + .buf = (u8 *)tx,
> + },
> + [1] = {
> + .addr = client->addr,
> + .flags = I2C_M_RD,
> + .len = rx_len,
> + .buf = rx,
> + },
> + };
> +
> + ret = i2c_transfer(client->adapter, msgs, ARRAY_SIZE(msgs));
> + if (ret != ARRAY_SIZE(msgs))
> + return ret < 0 ? ret : -EIO;
> +
> + return 0;
> +}
> +
> +static const struct mlx90393_transfer_ops mlx90393_i2c_ops = {
> + .xfer = mlx90393_i2c_xfer,
> +};
> +
> +static int mlx90393_i2c_probe(struct i2c_client *client)
> +{
> + return mlx90393_core_probe(&client->dev, &mlx90393_i2c_ops, client);
> +}
> +
> +static const struct i2c_device_id mlx90393_id[] = {
> + { .name = "mlx90393" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(i2c, mlx90393_id);
> +
> +static const struct of_device_id mlx90393_of_match[] = {
> + { .compatible = "melexis,mlx90393" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, mlx90393_of_match);
> +
> +static struct i2c_driver mlx90393_i2c_driver = {
> + .driver = {
> + .name = "mlx90393",
> + .of_match_table = mlx90393_of_match,
> + },
> + .probe = mlx90393_i2c_probe,
> + .id_table = mlx90393_id,
> +};
> +
> +module_i2c_driver(mlx90393_i2c_driver);
> +
> +MODULE_IMPORT_NS("IIO_MLX90393");
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Nikhil Gautam <nikhilgtr@gmail.com>");
> +MODULE_DESCRIPTION("MLX90393 magnetometer sensor driver");
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: iio: adc: Add Nuvoton MA35D1 EADC
From: David Lechner @ 2026-06-27 20:05 UTC (permalink / raw)
To: Chi-Wen Weng, jic23, robh, krzk+dt, conor+dt
Cc: nuno.sa, andy, linux-arm-kernel, linux-iio, devicetree,
linux-kernel, cwweng
In-Reply-To: <20260625110638.38438-2-cwweng.linux@gmail.com>
On 6/25/26 6:06 AM, Chi-Wen Weng wrote:
> From: Chi-Wen Weng <cwweng@nuvoton.com>
>
> Add devicetree binding for the Enhanced ADC controller found on
> Nuvoton MA35D1 SoCs.
>
> The controller has one register region, one interrupt and one functional
> clock. ADC inputs are described using standard channel child nodes,
> including optional differential channel pairs.
>
> Signed-off-by: Chi-Wen Weng <cwweng@nuvoton.com>
> ---
> .../bindings/iio/adc/nuvoton,ma35d1-eadc.yaml | 100 ++++++++++++++++++
> 1 file changed, 100 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/nuvoton,ma35d1-eadc.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/nuvoton,ma35d1-eadc.yaml b/Documentation/devicetree/bindings/iio/adc/nuvoton,ma35d1-eadc.yaml
> new file mode 100644
> index 000000000000..ae7ad0f7689a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/nuvoton,ma35d1-eadc.yaml
> @@ -0,0 +1,100 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/adc/nuvoton,ma35d1-eadc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Nuvoton MA35D1 Enhanced Analog to Digital Converter
> +
> +maintainers:
> + - Chi-Wen Weng <cwweng@nuvoton.com>
> +
> +description: |
> + The Nuvoton MA35D1 Enhanced Analog to Digital Converter (EADC) is a
> + 12-bit ADC controller integrated in the MA35D1 SoC. Each enabled ADC
> + input is described by a child channel node.
> +
> +properties:
> + compatible:
> + const: nuvoton,ma35d1-eadc
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
Datasheet says there are 4 interrupts.
> +
> + clocks:
> + maxItems: 1
Should there be an optional vref-supply for the V_REF pin?
Should there be a dmas property? Datasheet says it supports
PDMA transfer.
> +
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 0
> +
> +patternProperties:
> + '^channel@[0-8]$':
> + type: object
> + $ref: adc.yaml
> + unevaluatedProperties: false
> +
> + properties:
> + reg:
> + minimum: 0
> + maximum: 8
I assume 8 is for the internal batter voltage channel? Often, we don't
include fixed internal channels like this in the devicetree since they
are always the same and don't depend on external wiring.
> +
> + diff-channels:
> + minItems: 2
> + maxItems: 2
adc.yaml already specifies minItems and maxItems, so we don't need to repeat it.
> + items:
> + minimum: 0
> + maximum: 8
This (and reg) are uint32, so don't really need minimum: 0.
Also, I assume that 8 is for the internal battery voltage channel, which
wouldn't make sense as part of a differential input.
> +
> + required:
> + - reg
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - '#address-cells'
> + - '#size-cells'
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + adc@40430000 {
> + compatible = "nuvoton,ma35d1-eadc";
> + reg = <0x0 0x40430000 0x0 0x10000>;
> + interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clk EADC_GATE>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + channel@0 {
> + reg = <0>;
> + };
> +
> + channel@1 {
> + reg = <1>;
> + };
> +
> + channel@2 {
> + reg = <2>;
> + diff-channels = <2 3>;
> + };
> + };
> + };
> +...
^ permalink raw reply
* [PATCH v2 1/9] dt-bindings: reset: altr: add COMBOPHY_RESET for Agilex5
From: Tanmay Kathpalia @ 2026-06-27 20:14 UTC (permalink / raw)
To: linux-mmc
Cc: ulf.hansson, Tanmay Kathpalia, Conor Dooley, Philipp Zabel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
linux-kernel
In-Reply-To: <20260627201457.12318-1-tanmay.kathpalia@altera.com>
Add COMBOPHY_RESET definition at index 38 for the combo PHY reset
control on Altera Agilex5 SoCs. This reset is used by peripherals
such as the SD/eMMC controller that share the combo PHY.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
---
include/dt-bindings/reset/altr,rst-mgr-s10.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/dt-bindings/reset/altr,rst-mgr-s10.h b/include/dt-bindings/reset/altr,rst-mgr-s10.h
index 04c4d0c6fd34..c2505b9eb63e 100644
--- a/include/dt-bindings/reset/altr,rst-mgr-s10.h
+++ b/include/dt-bindings/reset/altr,rst-mgr-s10.h
@@ -22,7 +22,7 @@
#define USB0_RESET 35
#define USB1_RESET 36
#define NAND_RESET 37
-/* 38 is empty */
+#define COMBOPHY_RESET 38
#define SDMMC_RESET 39
#define EMAC0_OCP_RESET 40
#define EMAC1_OCP_RESET 41
--
2.43.7
^ permalink raw reply related
* [PATCH v2 2/9] dt-bindings: mmc: cdns,sdhci: add SD6HC support and PHY properties
From: Tanmay Kathpalia @ 2026-06-27 20:14 UTC (permalink / raw)
To: linux-mmc
Cc: ulf.hansson, Tanmay Kathpalia, Ulf Hansson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Masahiro Yamada, devicetree,
linux-kernel
In-Reply-To: <20260627201457.12318-1-tanmay.kathpalia@altera.com>
Extend the Cadence SDHCI binding to support the sixth-generation SD6HC
controller. Add the cdns,sd6hc compatible string with two named clocks
(ciu and biu) and three SD6HC-specific PHY timing properties for iocell
input/output delay and delay element size.
Add the altr,agilex5-sd6hc compatible string with three named reset
lines from the Altera HPS Reset Manager. Introduce per-variant
constraints so SD6HC and SD4HC each enforce their own clock, reset, and
PHY property requirements independently.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
---
.../devicetree/bindings/mmc/cdns,sdhci.yaml | 122 ++++++++++++++++--
1 file changed, 111 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
index 6c7317d13aa6..edd96e1d2bdc 100644
--- a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
+++ b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
@@ -4,21 +4,29 @@
$id: http://devicetree.org/schemas/mmc/cdns,sdhci.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Cadence SD/SDIO/eMMC Host Controller (SD4HC)
+title: Cadence SD/SDIO/eMMC Host Controller (SD4HC and SD6HC)
maintainers:
- Masahiro Yamada <yamada.masahiro@socionext.com>
+ - Tanmay Kathpalia <tanmay.kathpalia@altera.com>
properties:
compatible:
- items:
- - enum:
- - amd,pensando-elba-sd4hc
- - microchip,mpfs-sd4hc
- - microchip,pic64gx-sd4hc
- - mobileye,eyeq-sd4hc
- - socionext,uniphier-sd4hc
- - const: cdns,sd4hc
+ oneOf:
+ - description: Cadence SD4HC controller
+ items:
+ - enum:
+ - amd,pensando-elba-sd4hc
+ - microchip,mpfs-sd4hc
+ - microchip,pic64gx-sd4hc
+ - mobileye,eyeq-sd4hc
+ - socionext,uniphier-sd4hc
+ - const: cdns,sd4hc
+ - description: Cadence SD6HC controller
+ items:
+ - enum:
+ - altr,agilex5-sd6hc
+ - const: cdns,sd6hc
reg:
minItems: 1
@@ -28,10 +36,12 @@ properties:
maxItems: 1
clocks:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
resets:
- maxItems: 1
+ minItems: 1
+ maxItems: 3
# PHY DLL input delays:
# They are used to delay the data valid window, and align the window to
@@ -115,6 +125,25 @@ properties:
minimum: 0
maximum: 0x7f
+ # SD6HC PHY timing properties:
+ cdns,iocell-input-delay:
+ description: Input delay across IO cells in picoseconds
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 20000 # 20 ns
+
+ cdns,iocell-output-delay:
+ description: Output delay across IO cells in picoseconds
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 20000 # 20 ns
+
+ cdns,delay-element:
+ description: Delay element size in picoseconds
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 1000 # 1 ns
+
required:
- compatible
- reg
@@ -139,6 +168,77 @@ allOf:
reg:
maxItems: 1
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: cdns,sd6hc
+ then:
+ description: SD6HC variant - use IO-cell and delay element properties
+ properties:
+ clocks:
+ minItems: 2
+ maxItems: 2
+ clock-names:
+ items:
+ - const: ciu
+ - const: biu
+ dma-coherent: true
+ iommus:
+ maxItems: 1
+ cdns,phy-input-delay-sd-highspeed: false
+ cdns,phy-input-delay-legacy: false
+ cdns,phy-input-delay-sd-uhs-sdr12: false
+ cdns,phy-input-delay-sd-uhs-sdr25: false
+ cdns,phy-input-delay-sd-uhs-sdr50: false
+ cdns,phy-input-delay-sd-uhs-ddr50: false
+ cdns,phy-input-delay-mmc-highspeed: false
+ cdns,phy-input-delay-mmc-ddr: false
+ cdns,phy-dll-delay-sdclk: false
+ cdns,phy-dll-delay-sdclk-hsmmc: false
+ cdns,phy-dll-delay-strobe: false
+ required:
+ - clock-names
+
+ # The Cadence SD6HC IP has per-clock-domain reset inputs, but the specific
+ # reset lines exposed here ("sdhc-reset", "combophy", "sdmmc-ocp") are
+ # provided by the Altera HPS Reset Manager and reflect the Agilex5 SoC
+ # integration.
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: altr,agilex5-sd6hc
+ then:
+ properties:
+ resets:
+ minItems: 3
+ maxItems: 3
+ reset-names:
+ items:
+ - const: sdhc-reset
+ - const: combophy
+ - const: sdmmc-ocp
+ required:
+ - resets
+ - reset-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: cdns,sd4hc
+ then:
+ description: SD4HC variant - use legacy DLL delay properties
+ properties:
+ clocks:
+ maxItems: 1
+ resets:
+ maxItems: 1
+ cdns,iocell-input-delay: false
+ cdns,iocell-output-delay: false
+ cdns,delay-element: false
+
unevaluatedProperties: false
examples:
--
2.43.7
^ permalink raw reply related
* [PATCH v2 3/9] arm64: dts: agilex5: add Cadence SD6HC controller and SOCDK enablement
From: Tanmay Kathpalia @ 2026-06-27 20:14 UTC (permalink / raw)
To: linux-mmc
Cc: ulf.hansson, Tanmay Kathpalia, Dinh Nguyen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree, linux-kernel
In-Reply-To: <20260627201457.12318-1-tanmay.kathpalia@altera.com>
Add the Cadence SD6HC controller node to the Agilex5 SoC DTSI as a
shared SD/eMMC node, disabled by default. The controller integrates
with the system SMMU for IOMMU support and uses SDMCLK as the primary
clock source for PHY timing.
On the SOCDK board, add a fixed 3.3V regulator for card power and a
GPIO-controlled regulator for I/O voltage switching between 1.8V and
3.3V. Enable the controller for SD-only operation in 4-bit bus width
with high-speed and SDR104 UHS-I modes at 200 MHz.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
---
.../arm64/boot/dts/intel/socfpga_agilex5.dtsi | 25 +++++++++++++++
.../boot/dts/intel/socfpga_agilex5_socdk.dts | 31 +++++++++++++++++++
2 files changed, 56 insertions(+)
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
index 02e62d954e94..f552aa0c1faa 100644
--- a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
@@ -300,6 +300,31 @@ portb: gpio-controller@0 {
};
};
+ /*
+ * Shared SD/eMMC controller node. On the SOCDK OOBE daughter-card
+ * this is used for SD card operation; on the SOCDK eMMC daughter-card
+ * it is configured for eMMC.
+ */
+ emmc: mmc@10808000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "altr,agilex5-sd6hc", "cdns,sd6hc";
+ reg = <0x10808000 0x1000>;
+ interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
+ resets = <&rst SDMMC_RESET>, <&rst COMBOPHY_RESET>, <&rst SDMMC_OCP_RESET>;
+ reset-names = "sdhc-reset", "combophy", "sdmmc-ocp";
+ /*
+ * "ciu" (SDMCLK) is listed first so it is selected as the
+ * primary clock by the SDHCI platform layer; the SD6HC PHY
+ * timing calculations are derived from this clock rate.
+ */
+ clocks = <&clkmgr AGILEX5_SDMCLK>, <&clkmgr AGILEX5_L4_MP_CLK>;
+ clock-names = "ciu", "biu";
+ iommus = <&smmu 5>;
+ dma-coherent;
+ status = "disabled";
+ };
+
nand: nand-controller@10b80000 {
compatible = "cdns,hp-nfc";
reg = <0x10b80000 0x10000>,
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk.dts b/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk.dts
index 262bb3e8e5c7..c56f46721bb0 100644
--- a/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk.dts
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk.dts
@@ -34,6 +34,24 @@ memory@80000000 {
/* We expect the bootloader to fill in the reg */
reg = <0x0 0x80000000 0x0 0x0>;
};
+
+ vmmc_reg: regulator-fixed-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc-sd";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vqmmc_io_reg: regulator-1p8v {
+ compatible = "regulator-gpio";
+ regulator-name = "vqmmc-io";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ states = <1800000 0x1>,
+ <3300000 0x0>;
+ gpios = <&portb 3 GPIO_ACTIVE_HIGH>;
+ };
};
&gpio0 {
@@ -98,6 +116,19 @@ root: partition@4200000 {
};
};
+&emmc {
+ status = "okay";
+
+ no-mmc;
+ disable-wp;
+ bus-width = <4>;
+ cap-sd-highspeed;
+ sd-uhs-sdr104;
+ vmmc-supply = <&vmmc_reg>;
+ vqmmc-supply = <&vqmmc_io_reg>;
+ max-frequency = <200000000>;
+};
+
&uart0 {
status = "okay";
};
--
2.43.7
^ permalink raw reply related
* [PATCH v2 4/9] dt-bindings: arm: intel: add Agilex5 SOCDK eMMC board variant
From: Tanmay Kathpalia @ 2026-06-27 20:14 UTC (permalink / raw)
To: linux-mmc
Cc: ulf.hansson, Tanmay Kathpalia, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dinh Nguyen, devicetree, linux-kernel
In-Reply-To: <20260627201457.12318-1-tanmay.kathpalia@altera.com>
Add "intel,socfpga-agilex5-socdk-emmc" compatible string for the
Agilex5 SOCDK board variant configured with eMMC storage.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
---
Documentation/devicetree/bindings/arm/altera.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/altera.yaml b/Documentation/devicetree/bindings/arm/altera.yaml
index 206686f3eebc..f5efcbc381b8 100644
--- a/Documentation/devicetree/bindings/arm/altera.yaml
+++ b/Documentation/devicetree/bindings/arm/altera.yaml
@@ -113,6 +113,7 @@ properties:
- intel,socfpga-agilex5-socdk-013b
- intel,socfpga-agilex5-socdk-modular
- intel,socfpga-agilex5-socdk-nand
+ - intel,socfpga-agilex5-socdk-emmc
- const: intel,socfpga-agilex5
- description: SoCFPGA VT
--
2.43.7
^ permalink raw reply related
* [PATCH v2 5/9] arm64: dts: agilex5: add SOCDK eMMC daughter board support
From: Tanmay Kathpalia @ 2026-06-27 20:14 UTC (permalink / raw)
To: linux-mmc
Cc: ulf.hansson, Tanmay Kathpalia, Dinh Nguyen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree, linux-kernel
In-Reply-To: <20260627201457.12318-1-tanmay.kathpalia@altera.com>
Add socfpga_agilex5_socdk_emmc.dts for the Agilex5 SoCDK eMMC daughter
board variant. Define board-specific regulators at the DTS root: a
fixed 3.3V supply for card power and a fixed 1.8V supply for eMMC I/O
voltage.
Enable the shared SD/eMMC controller for eMMC-only operation with an
8-bit bus, HS200 and HS400 modes at 1.8V signaling, and a 200 MHz
maximum clock frequency.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
---
arch/arm64/boot/dts/intel/Makefile | 1 +
.../dts/intel/socfpga_agilex5_socdk_emmc.dts | 120 ++++++++++++++++++
2 files changed, 121 insertions(+)
create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_emmc.dts
diff --git a/arch/arm64/boot/dts/intel/Makefile b/arch/arm64/boot/dts/intel/Makefile
index 33fcc55d0cb9..5bbbcfda1f48 100644
--- a/arch/arm64/boot/dts/intel/Makefile
+++ b/arch/arm64/boot/dts/intel/Makefile
@@ -8,5 +8,6 @@ dtb-$(CONFIG_ARCH_INTEL_SOCFPGA) += socfpga_agilex_n6000.dtb \
socfpga_agilex5_socdk_013b.dtb \
socfpga_agilex5_socdk_modular.dtb \
socfpga_agilex5_socdk_nand.dtb \
+ socfpga_agilex5_socdk_emmc.dtb \
socfpga_n5x_socdk.dtb
dtb-$(CONFIG_ARCH_KEEMBAY) += keembay-evm.dtb
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_emmc.dts b/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_emmc.dts
new file mode 100644
index 000000000000..455808db32bb
--- /dev/null
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_emmc.dts
@@ -0,0 +1,120 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2026, Altera Corporation
+ */
+#include "socfpga_agilex5.dtsi"
+
+/ {
+ model = "SoCFPGA Agilex5 SoCDK eMMC daughter board";
+ compatible = "intel,socfpga-agilex5-socdk-emmc", "intel,socfpga-agilex5";
+
+ aliases {
+ serial0 = &uart0;
+ ethernet0 = &gmac0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-0 {
+ label = "hps_led0";
+ gpios = <&porta 6 GPIO_ACTIVE_HIGH>;
+ };
+
+ led-1 {
+ label = "hps_led1";
+ gpios = <&porta 7 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ /* We expect the bootloader to fill in the reg */
+ reg = <0x0 0x80000000 0x0 0x0>;
+ };
+
+ vmmc_reg: regulator-fixed-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc-emmc";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vqmmc_io_reg: regulator-fixed-1p8v {
+ compatible = "regulator-fixed";
+ regulator-name = "vqmmc-io";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+};
+
+&gmac0 {
+ status = "okay";
+ phy-mode = "rgmii-id";
+ phy-handle = <&emac0_phy0>;
+ max-frame-size = <9000>;
+
+ mdio0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+
+ emac0_phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+ };
+};
+
+&gpio0 {
+ status = "okay";
+};
+
+&gpio1 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+};
+
+&i3c0 {
+ status = "okay";
+};
+
+&i3c1 {
+ status = "okay";
+};
+
+&emmc {
+ status = "okay";
+
+ no-sd;
+ no-sdio;
+ disable-wp;
+ non-removable;
+ cap-mmc-highspeed;
+ mmc-hs200-1_8v;
+ mmc-hs400-1_8v;
+ bus-width = <8>;
+ vmmc-supply = <&vmmc_reg>;
+ vqmmc-supply = <&vqmmc_io_reg>;
+ max-frequency = <200000000>;
+};
+
+&osc1 {
+ clock-frequency = <25000000>;
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&watchdog0 {
+ status = "okay";
+};
--
2.43.7
^ permalink raw reply related
* Re: [PATCH v2 3/9] arm64: dts: agilex5: add Cadence SD6HC controller and SOCDK enablement
From: sashiko-bot @ 2026-06-27 20:24 UTC (permalink / raw)
To: Tanmay Kathpalia; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260627201457.12318-4-tanmay.kathpalia@altera.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The GPIO-controlled I/O regulator (vqmmc-io) initializes to 1.8V instead of the required 3.3V at boot due to missing `gpios-states` property.
--
commit d6ddf71779dce5e00733c866f08e72b6d91c3a47
Author: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
arm64: dts: agilex5: add Cadence SD6HC controller and SOCDK enablement
This commit adds the Cadence SD6HC controller node to the Agilex5 SoC DTSI
and enables it for the SOCDK board. It configures the controller for SD-only
operation with a fixed 3.3V card power regulator and a GPIO-controlled I/O
voltage regulator.
> diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk.dts b/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk.dts
> index 262bb3e8e5c72..c56f46721bb06 100644
> --- a/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk.dts
> +++ b/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk.dts
[ ... ]
> @@ -34,6 +34,24 @@ memory@80000000 {
> /* We expect the bootloader to fill in the reg */
> reg = <0x0 0x80000000 0x0 0x0>;
> };
> +
> + vmmc_reg: regulator-fixed-3p3v {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc-sd";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + vqmmc_io_reg: regulator-1p8v {
> + compatible = "regulator-gpio";
> + regulator-name = "vqmmc-io";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + states = <1800000 0x1>,
> + <3300000 0x0>;
> + gpios = <&portb 3 GPIO_ACTIVE_HIGH>;
> + };
[Severity: High]
Does this missing gpios-states property cause the regulator to initialize
incorrectly at boot?
In drivers/regulator/gpio-regulator.c, when gpios-states is omitted,
of_get_gpio_regulator_config() defaults the GPIO to GPIOD_OUT_HIGH. Based
on the states array here, a high state (0x1) selects 1.8V instead of the
standard 3.3V required for initial SD card operation.
Could this violate SD card power sequencing by supplying 1.8V to the I/O
lines while VDD is 3.3V, potentially causing enumeration failures or
electrical damage?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260627201457.12318-1-tanmay.kathpalia@altera.com?part=3
^ permalink raw reply
* Re: [PATCH v2 2/9] dt-bindings: mmc: cdns,sdhci: add SD6HC support and PHY properties
From: sashiko-bot @ 2026-06-27 20:26 UTC (permalink / raw)
To: Tanmay Kathpalia; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260627201457.12318-3-tanmay.kathpalia@altera.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Device tree schema guideline violation: standard properties are defined solely within conditional blocks.
--
commit e277493647bd6915b90ee32b253e1cb7514a8c5f
Author: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
dt-bindings: mmc: cdns,sdhci: add SD6HC support and PHY properties
Extend the Cadence SDHCI binding to support the sixth-generation SD6HC
controller. Add the cdns,sd6hc and altr,agilex5-sd6hc compatible strings
along with variant constraints.
> diff --git a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
> index 6c7317d13aa6c..edd96e1d2bdcd 100644
> --- a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
> +++ b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
[ ... ]
> @@ -139,6 +168,77 @@ allOf:
> reg:
> maxItems: 1
>
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: cdns,sd6hc
> + then:
> + description: SD6HC variant - use IO-cell and delay element properties
> + properties:
> + clocks:
> + minItems: 2
> + maxItems: 2
> + clock-names:
> + items:
> + - const: ciu
> + - const: biu
> + dma-coherent: true
> + iommus:
> + maxItems: 1
[Severity: Low]
This isn't a bug, but should clock-names, dma-coherent, and iommus be
declared in the top-level properties block instead of solely within this
conditional?
The dt-schema guidelines suggest defining properties with their broadest
constraints at the top level rather than entirely within if:then blocks, to
ensure proper documentation generation and tooling compatibility.
[ ... ]
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: altr,agilex5-sd6hc
> + then:
> + properties:
> + resets:
> + minItems: 3
> + maxItems: 3
> + reset-names:
> + items:
> + - const: sdhc-reset
> + - const: combophy
> + - const: sdmmc-ocp
[Severity: Low]
Similar to the clock-names property, should reset-names also be declared at
the top level rather than being exclusively defined in this conditional block?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260627201457.12318-1-tanmay.kathpalia@altera.com?part=2
^ permalink raw reply
* Re: [PATCH 2/2] iio: adc: Add Nuvoton MA35D1 EADC driver
From: David Lechner @ 2026-06-27 20:52 UTC (permalink / raw)
To: Chi-Wen Weng, jic23, robh, krzk+dt, conor+dt
Cc: nuno.sa, andy, linux-arm-kernel, linux-iio, devicetree,
linux-kernel, cwweng
In-Reply-To: <20260625110638.38438-3-cwweng.linux@gmail.com>
On 6/25/26 6:06 AM, Chi-Wen Weng wrote:
> From: Chi-Wen Weng <cwweng@nuvoton.com>
>
> Add an IIO driver for the Nuvoton MA35D1 Enhanced ADC controller.
>
> The driver supports direct raw reads and triggered buffered capture. The
> controller end-of-conversion interrupt is exposed as the device trigger
> and is used to push samples into the IIO buffer.
>
> Channels are described by firmware child nodes and can be configured as
> single-ended or differential inputs. Since the differential enable bit is
> global, mixed single-ended and differential buffered scans are rejected.
>
> DMA support is intentionally not included in this initial upstream driver;
> conversions are handled through the interrupt-driven path.
>
> Signed-off-by: Chi-Wen Weng <cwweng@nuvoton.com>
> ---
> drivers/iio/adc/Kconfig | 10 +
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/ma35d1_eadc.c | 636 ++++++++++++++++++++++++++++++++++
> 3 files changed, 647 insertions(+)
> create mode 100644 drivers/iio/adc/ma35d1_eadc.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 1c663c98c6c9..43409999a94b 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -981,6 +981,16 @@ config LTC2497
> To compile this driver as a module, choose M here: the module will be
> called ltc2497.
>
> +config MA35D1_EADC
> + tristate "MA35D1 EADC driver"
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
> + help
> + Say yes here to build support for MA35D1 EADC.
> +
> + To compile this driver as a module, choose M here: the module will be
> + called ma35d1.
> +
> config MAX1027
> tristate "Maxim max1027 ADC driver"
> depends on SPI
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 707dd708912f..7b9b38688223 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -85,6 +85,7 @@ obj-$(CONFIG_LTC2471) += ltc2471.o
> obj-$(CONFIG_LTC2485) += ltc2485.o
> obj-$(CONFIG_LTC2496) += ltc2496.o ltc2497-core.o
> obj-$(CONFIG_LTC2497) += ltc2497.o ltc2497-core.o
> +obj-$(CONFIG_MA35D1_EADC) += ma35d1_eadc.o
> obj-$(CONFIG_MAX1027) += max1027.o
> obj-$(CONFIG_MAX11100) += max11100.o
> obj-$(CONFIG_MAX1118) += max1118.o
> diff --git a/drivers/iio/adc/ma35d1_eadc.c b/drivers/iio/adc/ma35d1_eadc.c
> new file mode 100644
> index 000000000000..0c075126e139
> --- /dev/null
> +++ b/drivers/iio/adc/ma35d1_eadc.c
> @@ -0,0 +1,636 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Nuvoton MA35D1 EADC driver
> + *
> + * Copyright (c) 2026 Nuvoton Technology Corp.
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/bits.h>
> +#include <linux/bitmap.h>
> +#include <linux/clk.h>
> +#include <linux/completion.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/mutex.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm.h>
> +#include <linux/property.h>
> +
> +#include <linux/iio/buffer.h>
> +#include <linux/iio/iio.h>
> +#include <linux/iio/trigger.h>
> +#include <linux/iio/trigger_consumer.h>
> +#include <linux/iio/triggered_buffer.h>
> +
> +#define MA35D1_EADC_DAT(n) (0x00 + (n) * 0x04)
> +#define MA35D1_EADC_CTL 0x50
> +#define MA35D1_EADC_SWTRG 0x54
> +#define MA35D1_EADC_SCTL(n) (0x80 + (n) * 0x04)
> +#define MA35D1_EADC_INTSRC0 0xd0
> +#define MA35D1_EADC_STATUS2 0xf8
> +#define MA35D1_EADC_SELSMP0 0x140
> +#define MA35D1_EADC_REFADJCTL 0x150
> +
> +#define MA35D1_EADC_CTL_ADCEN BIT(0)
> +#define MA35D1_EADC_CTL_ADCIEN0 BIT(2)
> +#define MA35D1_EADC_CTL_DIFFEN BIT(8)
> +
> +#define MA35D1_EADC_SCTL_CHSEL_MASK GENMASK(3, 0)
> +#define MA35D1_EADC_SCTL_TRGDLY_MASK GENMASK(15, 8)
> +#define MA35D1_EADC_SCTL_TRGSEL_MASK GENMASK(21, 16)
> +#define MA35D1_EADC_SCTL_TRGSEL_ADINT0 \
> + FIELD_PREP(MA35D1_EADC_SCTL_TRGSEL_MASK, 2)
> +
> +#define MA35D1_EADC_DAT_MASK GENMASK(11, 0)
> +#define MA35D1_EADC_STATUS2_ADIF0 BIT(0)
> +#define MA35D1_EADC_INTSRC0_ADINT0 BIT(0)
> +#define MA35D1_EADC_REFADJCTL_EXT_VREF BIT(0)
> +
> +#define MA35D1_EADC_MAX_CHANNELS 9
> +#define MA35D1_EADC_MAX_SAMPLE_MODULES 16
> +#define MA35D1_EADC_CHAN_NAME_LEN 16
> +#define MA35D1_EADC_TIMEOUT msecs_to_jiffies(1000)
> +
> +struct ma35d1_adc {
> + struct device *dev;
It looks like this is never used, so we can drop it.
> + void __iomem *regs;
> + struct clk *clk;
> + struct completion completion;
> + /* Protects direct conversions against concurrent register access. */
> + struct mutex lock;
> + struct iio_trigger *trig;
> + unsigned int scan_chancnt;
> + bool scan_differential;
> + char chan_name[MA35D1_EADC_MAX_CHANNELS][MA35D1_EADC_CHAN_NAME_LEN];
> + struct {
> + u16 channels[MA35D1_EADC_MAX_SAMPLE_MODULES];
> + aligned_s64 timestamp;
> + } scan;
Unless the hardware requires all channels to be read at once, we should
use this instead:
IIO_DECLARE_BUFFER_WITH_TS(u16, scan, MA35D1_EADC_MAX_SAMPLE_MODULES);
It means an array with enough room for MA35D1_EADC_MAX_SAMPLE_MODULES u16
data points plus an aligned timestamp, but doesn't specify where the
timestamp will be as it could be in a different place depending on how
many channels are read.
Also, this is only used in one function, so can just be stack-allocated
in that function (with ` = { };` to zero it) instead of allocating it here.
> +};
> +
> +static inline u32 ma35d1_adc_read(struct ma35d1_adc *adc, u32 reg)
> +{
> + return readl(adc->regs + reg);
> +}
> +
> +static inline void ma35d1_adc_write(struct ma35d1_adc *adc, u32 reg, u32 val)
> +{
> + writel(val, adc->regs + reg);
> +}
> +
> +static void ma35d1_adc_rmw(struct ma35d1_adc *adc, u32 reg, u32 mask, u32 val)
> +{
> + u32 tmp;
> +
> + tmp = ma35d1_adc_read(adc, reg);
> + tmp &= ~mask;
> + tmp |= val;
> + ma35d1_adc_write(adc, reg, tmp);
> +}
Why not use regmap?
> +
> +static void ma35d1_adc_set_diff(struct ma35d1_adc *adc, bool differential)
> +{
> + ma35d1_adc_rmw(adc, MA35D1_EADC_CTL, MA35D1_EADC_CTL_DIFFEN,
> + differential ? MA35D1_EADC_CTL_DIFFEN : 0);
> +}
> +
> +static void ma35d1_adc_config_sample(struct ma35d1_adc *adc,
> + unsigned int sample, unsigned int channel)
> +{
> + u32 reg = MA35D1_EADC_SCTL(sample);
> +
> + ma35d1_adc_rmw(adc, reg,
> + MA35D1_EADC_SCTL_CHSEL_MASK |
> + MA35D1_EADC_SCTL_TRGSEL_MASK,
> + FIELD_PREP(MA35D1_EADC_SCTL_CHSEL_MASK, channel) |
> + MA35D1_EADC_SCTL_TRGSEL_ADINT0);
> +}
> +
> +static void ma35d1_adc_disable_irq(struct ma35d1_adc *adc)
> +{
> + ma35d1_adc_rmw(adc, MA35D1_EADC_CTL, MA35D1_EADC_CTL_ADCIEN0, 0);
> +}
> +
> +static void ma35d1_adc_hw_init(struct ma35d1_adc *adc)
> +{
> + ma35d1_adc_disable_irq(adc);
> + ma35d1_adc_rmw(adc, MA35D1_EADC_CTL,
> + MA35D1_EADC_CTL_ADCEN, MA35D1_EADC_CTL_ADCEN);
> + ma35d1_adc_write(adc, MA35D1_EADC_STATUS2, MA35D1_EADC_STATUS2_ADIF0);
> + ma35d1_adc_rmw(adc, MA35D1_EADC_INTSRC0,
> + MA35D1_EADC_INTSRC0_ADINT0,
> + MA35D1_EADC_INTSRC0_ADINT0);
> + ma35d1_adc_rmw(adc, MA35D1_EADC_REFADJCTL,
> + MA35D1_EADC_REFADJCTL_EXT_VREF,
> + MA35D1_EADC_REFADJCTL_EXT_VREF);
As mentioned elsewhere, external reference doesn't make sense unless
we can get the reference voltage from it.
> + ma35d1_adc_rmw(adc, MA35D1_EADC_SELSMP0, GENMASK(1, 0), 3);
> +}
> +
> +static void ma35d1_adc_hw_disable(void *data)
> +{
> + struct ma35d1_adc *adc = data;
> +
> + ma35d1_adc_disable_irq(adc);
ma35d1_adc_hw_init() doesn't enable the IRQ, so this seems a bit unbalanced.
> + ma35d1_adc_rmw(adc, MA35D1_EADC_CTL, MA35D1_EADC_CTL_ADCEN, 0);
> +}
> +
> +static irqreturn_t ma35d1_adc_isr(int irq, void *data)
> +{
> + struct iio_dev *indio_dev = data;
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> + u32 status;
> +
> + status = ma35d1_adc_read(adc, MA35D1_EADC_STATUS2);
> + if (!(status & MA35D1_EADC_STATUS2_ADIF0))
> + return IRQ_NONE;
> +
> + ma35d1_adc_write(adc, MA35D1_EADC_STATUS2, MA35D1_EADC_STATUS2_ADIF0);
> +
> + if (iio_buffer_enabled(indio_dev)) {
> + ma35d1_adc_disable_irq(adc);
> + iio_trigger_poll(adc->trig);
> + } else {
> + complete(&adc->completion);
> + }
> +
> + return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t ma35d1_adc_trigger_handler(int irq, void *p)
> +{
> + struct iio_poll_func *pf = p;
> + struct iio_dev *indio_dev = pf->indio_dev;
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> + int i;
> +
> + for (i = 0; i < adc->scan_chancnt; i++)
> + adc->scan.channels[i] =
> + ma35d1_adc_read(adc, MA35D1_EADC_DAT(i)) &
> + MA35D1_EADC_DAT_MASK;
> +
> + iio_push_to_buffers_with_timestamp(indio_dev, &adc->scan, pf->timestamp);
> + iio_trigger_notify_done(adc->trig);
> +
> + ma35d1_adc_rmw(adc, MA35D1_EADC_CTL, MA35D1_EADC_CTL_ADCIEN0,
> + MA35D1_EADC_CTL_ADCIEN0);
> + ma35d1_adc_write(adc, MA35D1_EADC_SWTRG, 1);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int ma35d1_adc_read_conversion(struct iio_dev *indio_dev,
> + const struct iio_chan_spec *chan,
> + int *val)
> +{
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> + long timeout;
> +
> + reinit_completion(&adc->completion);
> +
> + ma35d1_adc_write(adc, MA35D1_EADC_STATUS2, MA35D1_EADC_STATUS2_ADIF0);
> + ma35d1_adc_rmw(adc, MA35D1_EADC_SCTL(0),
> + MA35D1_EADC_SCTL_CHSEL_MASK |
> + MA35D1_EADC_SCTL_TRGSEL_MASK,
> + FIELD_PREP(MA35D1_EADC_SCTL_CHSEL_MASK,
> + chan->channel));
> + ma35d1_adc_set_diff(adc, chan->differential);
> + ma35d1_adc_rmw(adc, MA35D1_EADC_CTL, MA35D1_EADC_CTL_ADCIEN0,
> + MA35D1_EADC_CTL_ADCIEN0);
> + ma35d1_adc_write(adc, MA35D1_EADC_SWTRG, 1);
> +
> + timeout = wait_for_completion_interruptible_timeout(&adc->completion,
> + MA35D1_EADC_TIMEOUT);
> + ma35d1_adc_disable_irq(adc);
> +
> + if (timeout < 0)
> + return timeout;
> + if (!timeout)
> + return -ETIMEDOUT;
> +
> + *val = ma35d1_adc_read(adc, MA35D1_EADC_DAT(0)) & MA35D1_EADC_DAT_MASK;
> +
> + return 0;
> +}
> +
> +static int ma35d1_adc_read_raw(struct iio_dev *indio_dev,
> + const struct iio_chan_spec *chan,
> + int *val, int *val2, long mask)
> +{
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> + int ret;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + if (!iio_device_claim_direct(indio_dev))
> + return -EBUSY;
> +
> + mutex_lock(&adc->lock);
> + ret = ma35d1_adc_read_conversion(indio_dev, chan, val);
> + mutex_unlock(&adc->lock);
> +
> + iio_device_release_direct(indio_dev);
> + if (ret)
> + return ret;
> +
> + return IIO_VAL_INT;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int ma35d1_adc_validate_scan(struct iio_dev *indio_dev,
> + const unsigned long *scan_mask)
> +{
> + const struct iio_chan_spec *chan;
> + bool have_single = false;
> + bool have_diff = false;
> + unsigned int count = 0;
> + unsigned long bit;
> +
> + for_each_set_bit(bit, scan_mask, indio_dev->masklength) {
> + chan = &indio_dev->channels[bit];
> +
> + if (chan->type == IIO_TIMESTAMP)
> + continue;
Timestamp channel will never be set (it is handled differently), so we
don't need to check here.
> + count++;
> + if (chan->differential)
> + have_diff = true;
> + else
> + have_single = true;
> + }
> +
> + if (!count || count > MA35D1_EADC_MAX_SAMPLE_MODULES)
> + return -EINVAL;
> +
> + if (have_single && have_diff)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int ma35d1_adc_update_scan_mode(struct iio_dev *indio_dev,
> + const unsigned long *scan_mask)
> +{
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> + const struct iio_chan_spec *chan;
> + unsigned int sample = 0;
> + unsigned long bit;
> + bool differential = false;
> + int ret;
> +
> + ret = ma35d1_adc_validate_scan(indio_dev, scan_mask);
> + if (ret)
> + return ret;
> +
> + for_each_set_bit(bit, scan_mask, indio_dev->masklength) {
> + chan = &indio_dev->channels[bit];
> + if (chan->type == IIO_TIMESTAMP)
> + continue;
Same here.
> +
> + if (!sample)
> + differential = chan->differential;
> +
> + ma35d1_adc_config_sample(adc, sample, chan->channel);
> + sample++;
> + }
> +
> + adc->scan_chancnt = sample;
> + adc->scan_differential = differential;
> +
> + return 0;
> +}
> +
> +static int ma35d1_adc_buffer_postenable(struct iio_dev *indio_dev)
> +{
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> + int i;
> +
> + if (!adc->scan_chancnt)
> + return -EINVAL;
Should this even be possible because of ma35d1_adc_validate_scan()?
> +
> + ma35d1_adc_write(adc, MA35D1_EADC_STATUS2, MA35D1_EADC_STATUS2_ADIF0);
> + ma35d1_adc_rmw(adc, MA35D1_EADC_INTSRC0,
> + MA35D1_EADC_INTSRC0_ADINT0,
> + MA35D1_EADC_INTSRC0_ADINT0);
> + ma35d1_adc_rmw(adc, MA35D1_EADC_REFADJCTL,
> + MA35D1_EADC_REFADJCTL_EXT_VREF,
> + MA35D1_EADC_REFADJCTL_EXT_VREF);
How can we use the external V_REF without knowing what is connected to it?
I would expect this to use internal reference unless the devicetree specified
a vref-supply.
> + ma35d1_adc_rmw(adc, MA35D1_EADC_SELSMP0, GENMASK(1, 0), 3);
There should be a macro to say what field GENMASK(1, 0) is.
> + ma35d1_adc_set_diff(adc, adc->scan_differential);
> +
> + for (i = 0; i < adc->scan_chancnt; i++)
> + ma35d1_adc_rmw(adc, MA35D1_EADC_SCTL(i),
> + MA35D1_EADC_SCTL_TRGDLY_MASK,
> + MA35D1_EADC_SCTL_TRGDLY_MASK);
> +
> + ma35d1_adc_rmw(adc, MA35D1_EADC_CTL, MA35D1_EADC_CTL_ADCIEN0,
> + MA35D1_EADC_CTL_ADCIEN0);
> + ma35d1_adc_write(adc, MA35D1_EADC_SWTRG, 1);
> +
> + return 0;
> +}
> +
> +static int ma35d1_adc_buffer_predisable(struct iio_dev *indio_dev)
> +{
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> + int i;
> +
> + ma35d1_adc_disable_irq(adc);
> + for (i = 0; i < adc->scan_chancnt; i++)
> + ma35d1_adc_rmw(adc, MA35D1_EADC_SCTL(i),
> + MA35D1_EADC_SCTL_TRGSEL_MASK, 0);
> +
> + return 0;
> +}
> +
> +static const struct iio_buffer_setup_ops ma35d1_adc_buffer_ops = {
> + .postenable = ma35d1_adc_buffer_postenable,
> + .predisable = ma35d1_adc_buffer_predisable,
> +};
> +
> +static const struct iio_info ma35d1_adc_info = {
> + .read_raw = ma35d1_adc_read_raw,
> + .update_scan_mode = ma35d1_adc_update_scan_mode,
> +};
> +
> +static const struct iio_trigger_ops ma35d1_adc_trigger_ops = {
> + .validate_device = iio_trigger_validate_own_device,
> +};
> +
> +static void ma35d1_adc_init_channel(struct ma35d1_adc *adc,
> + struct iio_chan_spec *chan, u32 vinp,
> + u32 vinn, int scan_index, bool differential)
> +{
> + char *name = adc->chan_name[vinp];
> +
> + chan->type = IIO_VOLTAGE;
> + chan->indexed = 1;
> + chan->channel = vinp;
> + chan->address = vinp;
Setting address is reduant if it is always going to be the same as channel.
We can just use channel directly instead. address doesn't appear to be
used anyway.
> + chan->scan_index = scan_index;
> + chan->info_mask_separate = BIT(IIO_CHAN_INFO_RAW);
This should also have IIO_CHAN_INFO_SCALE that is based on the reference source.
> + chan->scan_type.sign = 'u';
This field has a new name:
chan->scan_type.format = IIO_SCAN_FORMAT_UNSIGNED_INT;
> + chan->scan_type.realbits = 12;
> + chan->scan_type.storagebits = 16;
> + chan->scan_type.endianness = IIO_CPU;
> +
> + if (differential) {
> + chan->differential = 1;
> + chan->channel2 = vinn;
> + snprintf(name, MA35D1_EADC_CHAN_NAME_LEN, "in%d-in%d", vinp,
> + vinn);
> + } else {
> + snprintf(name, MA35D1_EADC_CHAN_NAME_LEN, "in%d", vinp);
> + }
> +
> + chan->datasheet_name = name;
We usually don't use datasheet_name. It would make more sense to implement
labels and get the label from devicetree.
> +}
> +
> +static int ma35d1_adc_parse_channels(struct iio_dev *indio_dev,
> + struct device *dev)
> +{
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> + DECLARE_BITMAP(used_channels, MA35D1_EADC_MAX_CHANNELS);
> + struct fwnode_handle *child;
> + struct iio_chan_spec *channels;
> + int num_channels;
> + int scan_index = 0;
> + int ret;
> +
> + bitmap_zero(used_channels, MA35D1_EADC_MAX_CHANNELS);
> +
> + num_channels = device_get_child_node_count(dev);
> + if (!num_channels)
> + return dev_err_probe(dev, -ENODATA,
> + "no ADC channels configured\n");
> +
> + if (num_channels > MA35D1_EADC_MAX_CHANNELS)
> + return dev_err_probe(dev, -EINVAL, "too many ADC channels\n");
> +
> + channels = devm_kcalloc(dev, num_channels + 1, sizeof(*channels),
> + GFP_KERNEL);
> + if (!channels)
> + return -ENOMEM;
> +
> + device_for_each_child_node(dev, child) {
Can use device_for_each_child_node_scoped() here to avoid needing to put
handle on all return paths.
> + u32 diff[2];
> + u32 reg;
> + bool differential = false;
> +
> + ret = fwnode_property_read_u32(child, "reg", ®);
> + if (ret) {
> + fwnode_handle_put(child);
> + return dev_err_probe(dev, ret,
> + "missing channel reg property\n");
> + }
> +
> + if (reg >= MA35D1_EADC_MAX_CHANNELS) {
> + fwnode_handle_put(child);
> + return dev_err_probe(dev, -EINVAL,
> + "invalid ADC channel %u\n", reg);
> + }
> +
> + if (test_and_set_bit(reg, used_channels)) {
> + fwnode_handle_put(child);
> + return dev_err_probe(dev, -EINVAL,
> + "duplicate ADC channel %u\n", reg);
> + }
> +
> + if (fwnode_property_present(child, "diff-channels")) {
> + ret = fwnode_property_read_u32_array(child,
> + "diff-channels",
> + diff,
> + ARRAY_SIZE(diff));
> + if (ret) {
> + fwnode_handle_put(child);
> + return dev_err_probe(dev, ret,
> + "invalid diff-channels for channel %u\n",
> + reg);
> + }
> +
> + if (diff[0] != reg ||
> + diff[1] >= MA35D1_EADC_MAX_CHANNELS ||
> + diff[0] == diff[1]) {
> + fwnode_handle_put(child);
> + return dev_err_probe(dev, -EINVAL,
> + "invalid differential ADC channel %u-%u\n",
> + diff[0], diff[1]);
> + }
> +
> + if (test_and_set_bit(diff[1], used_channels)) {
> + fwnode_handle_put(child);
> + return dev_err_probe(dev, -EINVAL,
> + "ADC channel %u already used\n",
> + diff[1]);
> + }
> +
> + differential = true;
> + }
> +
> + ma35d1_adc_init_channel(adc, &channels[scan_index], reg,
> + differential ? diff[1] : 0,
> + scan_index, differential);
> + scan_index++;
> + }
> +
> + channels[scan_index] = (struct iio_chan_spec)
The macro already includes (struct iio_chan_spec) so we don't need it here.
> + IIO_CHAN_SOFT_TIMESTAMP(scan_index);
> +
> + indio_dev->channels = channels;
> + indio_dev->num_channels = scan_index + 1;
> + indio_dev->masklength = indio_dev->num_channels;
> +
> + return 0;
> +}
> +
> +static int ma35d1_adc_setup_trigger(struct iio_dev *indio_dev,
> + struct device *dev)
> +{
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> + int ret;
> +
> + adc->trig = devm_iio_trigger_alloc(dev, "%s-trigger", dev_name(dev));
> + if (!adc->trig)
> + return -ENOMEM;
> +
> + adc->trig->ops = &ma35d1_adc_trigger_ops;
> + iio_trigger_set_drvdata(adc->trig, indio_dev);
> +
> + ret = devm_iio_trigger_register(dev, adc->trig);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to register trigger\n");
> +
> + ret = iio_trigger_set_immutable(indio_dev, adc->trig);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to set trigger\n");
> +
> + return 0;
> +}
> +
> +static int ma35d1_adc_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct iio_dev *indio_dev;
> + struct ma35d1_adc *adc;
> + int irq;
> + int ret;
> +
> + indio_dev = devm_iio_device_alloc(dev, sizeof(*adc));
> + if (!indio_dev)
> + return -ENOMEM;
> + adc = iio_priv(indio_dev);
> + adc->dev = dev;
> + mutex_init(&adc->lock);
devm_mutex_init()
> + init_completion(&adc->completion);
> +
> + adc->regs = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(adc->regs))
> + return dev_err_probe(dev, PTR_ERR(adc->regs),
> + "failed to map registers\n");
> +
> + adc->clk = devm_clk_get_enabled(dev, NULL);
> + if (IS_ERR(adc->clk))
> + return dev_err_probe(dev, PTR_ERR(adc->clk),
> + "failed to get and enable ADC clock\n");
> +
> + indio_dev->name = "ma35d1-eadc";
> + indio_dev->modes = INDIO_DIRECT_MODE | INDIO_BUFFER_TRIGGERED;
devm_iio_triggered_buffer_setup() sets the INDIO_BUFFER_TRIGGERED
flag, so we don't need it here.
> + indio_dev->info = &ma35d1_adc_info;
> +
> + ret = ma35d1_adc_parse_channels(indio_dev, dev);
> + if (ret)
> + return ret;
> +
> + ma35d1_adc_hw_init(adc);
> +
> + ret = devm_add_action_or_reset(dev, ma35d1_adc_hw_disable, adc);
> + if (ret)
> + return ret;
> +
> + ret = ma35d1_adc_setup_trigger(indio_dev, dev);
> + if (ret)
> + return ret;
> +
> + irq = platform_get_irq(pdev, 0);
> + if (irq < 0)
> + return irq;
> +
> + ret = devm_request_irq(dev, irq, ma35d1_adc_isr, 0, dev_name(dev),
> + indio_dev);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to request IRQ %d\n", irq);
> +
> + ret = devm_iio_triggered_buffer_setup(dev, indio_dev,
> + iio_pollfunc_store_time,
> + ma35d1_adc_trigger_handler,
> + &ma35d1_adc_buffer_ops);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "failed to setup triggered buffer\n");
> +
> + platform_set_drvdata(pdev, indio_dev);
> +
> + ret = devm_iio_device_register(dev, indio_dev);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to register IIO device\n");
> +
> + return 0;
> +}
> +
> +static int ma35d1_adc_suspend(struct device *dev)
> +{
> + struct iio_dev *indio_dev = dev_get_drvdata(dev);
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> +
> + if (iio_buffer_enabled(indio_dev))
> + return -EBUSY;
> +
> + ma35d1_adc_hw_disable(adc);
> + clk_disable_unprepare(adc->clk);
> +
> + return 0;
> +}
> +
> +static int ma35d1_adc_resume(struct device *dev)
> +{
> + struct iio_dev *indio_dev = dev_get_drvdata(dev);
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> + int ret;
> +
> + ret = clk_prepare_enable(adc->clk);
> + if (ret)
> + return ret;
> +
> + ma35d1_adc_hw_init(adc);
> +
> + return 0;
> +}
> +
> +static DEFINE_SIMPLE_DEV_PM_OPS(ma35d1_adc_pm_ops,
> + ma35d1_adc_suspend, ma35d1_adc_resume);
> +
> +static const struct of_device_id ma35d1_adc_of_match[] = {
> + { .compatible = "nuvoton,ma35d1-eadc" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, ma35d1_adc_of_match);
> +
> +static struct platform_driver ma35d1_adc_driver = {
> + .probe = ma35d1_adc_probe,
> + .driver = {
> + .name = "ma35d1-eadc",
> + .of_match_table = ma35d1_adc_of_match,
> + .pm = pm_sleep_ptr(&ma35d1_adc_pm_ops),
> + },
> +};
> +module_platform_driver(ma35d1_adc_driver);
> +
> +MODULE_AUTHOR("Chi-Wen Weng <cwweng@nuvoton.com>");
> +MODULE_DESCRIPTION("Nuvoton MA35D1 EADC driver");
> +MODULE_LICENSE("GPL");
^ permalink raw reply
* Re: [External] [PATCH v2 3/8] riscv: Add support for srmcfg CSR from Ssqosid extension
From: Drew Fustini @ 2026-06-27 21:21 UTC (permalink / raw)
To: yunhui cui
Cc: Adrien Ricciardi, Alexandre Ghiti, Atish Kumar Patra, Atish Patra,
Babu Moger, Ben Horgan, Borislav Petkov, Chen Pei, Conor Dooley,
Conor Dooley, Dave Hansen, Dave Martin, Fenghua Yu, Gong Shuai,
Gong Shuai, guo.wenjia23, James Morse, Kornel Dulęba,
Krzysztof Kozlowski, liu.qingtao2, Liu Zhiwei, Palmer Dabbelt,
Paul Walmsley, Peter Newman, Radim Krčmář,
Reinette Chatre, Rob Herring, Samuel Holland,
Sebastian Andrzej Siewior, Tony Luck, Vasudevan Srinivasan,
Ved Shanbhogue, Weiwei Li, linux-kernel, linux-riscv, x86,
devicetree, linux-rt-devel, linux-doc
In-Reply-To: <CAEEQ3w=ZLnW-Wz_=PcUQTN8q0wxUq1_epCs0B+v=sSug+OHD=Q@mail.gmail.com>
On Sat, Jun 27, 2026 at 05:11:11PM +0800, yunhui cui wrote:
> Hi Drew,
Hi, thanks for the reviews.
>
> On Thu, Jun 25, 2026 at 9:40 AM Drew Fustini <fustini@kernel.org> wrote:
> >
> > Add support for the srmcfg CSR defined in the Ssqosid ISA extension.
> > The CSR contains two fields:
> >
> > - Resource Control ID (RCID) for resource allocation
> > - Monitoring Counter ID (MCID) for tracking resource usage
> >
> > Requests from a hart to shared resources are tagged with these IDs,
> > allowing resource usage to be associated with the running task.
> >
> > Add a srmcfg field to thread_struct with the same format as the CSR so
> > the scheduler can set the RCID and MCID for each task on context
> > switch. A per-cpu cpu_srmcfg variable mirrors the CSR state to avoid
> > redundant writes. L1D-hot memory access is faster than a CSR read and
> > avoids traps under virtualization.
> >
> > A per-cpu cpu_srmcfg_default holds the default srmcfg for each CPU as
> > set by resctrl CPU group assignment. On context switch, RCID and MCID
> > inherit from the CPU default independently: a task whose thread RCID
> > field is zero takes the CPU default's RCID, and likewise for MCID.
> >
> > Link: https://github.com/riscv/riscv-ssqosid/releases/tag/v1.0
> > Assisted-by: Claude:claude-opus-4-7
> > Co-developed-by: Kornel Dulęba <mindal@semihalf.com>
> > Signed-off-by: Kornel Dulęba <mindal@semihalf.com>
> > Signed-off-by: Drew Fustini <fustini@kernel.org>
[..]
> > diff --git a/arch/riscv/include/asm/qos.h b/arch/riscv/include/asm/qos.h
> > new file mode 100644
> > index 0000000000000000000000000000000000000000..e9e1d69f3797be5f89785a9b3aa7d9d51c476a8a
> > --- /dev/null
> > +++ b/arch/riscv/include/asm/qos.h
[..]
> > +static inline void __switch_to_srmcfg(struct task_struct *next)
> > +{
[..]
> > + if (thread_srmcfg != __this_cpu_read(cpu_srmcfg)) {
> > + /*
> > + * Drain stores from the outgoing task before the CSR write
> > + * so they retain the previous RCID/MCID tag at the cache
> > + * interconnect.
> > + */
> > + RISCV_FENCE(rw, o);
> > +
> > + __this_cpu_write(cpu_srmcfg, thread_srmcfg);
> > + csr_write(CSR_SRMCFG, thread_srmcfg);
> > + /*
> > + * Order the csrw before the new task's loads/stores so they
> > + * pick up the new tag. Zicsr 6.1.1 makes CSR writes weakly
> > + * ordered (device-output) vs memory ops. Ssqosid v1.0 is
> > + * silent so honor the general CSR rule.
> > + */
> > + RISCV_FENCE(o, rw);
>
> This is in the context-switch path and may be expensive in practice. Even if
> the target workload is pinned and grouped, unpinned/default-group tasks or
> kworkers may still run on those CPUs, causing frequent SRMCFG transitions and
> paying two fences each time.
>
> Is this strict ordering required by the Ssqosid spec or known hardware? If
> not, can we make this a trade-off and avoid the fences by default, accepting a
> small QoS-tagging inaccuracy around the context-switch boundary?
These fences were introduced based on Sashiko feedback on the RFC
series. You make a good point that this may be too conservative and some
inaccuracy probably would be acceptable. I would be okay with dropping
them, and we can reevaluate once more hardware implementations with
Ssqosid become public.
Thanks,
Drew
^ permalink raw reply
* Re: [PATCH v4 2/4] iio: adc: ltc2378: Add support for LTC2378-20 and similar ADCs
From: David Lechner @ 2026-06-27 21:24 UTC (permalink / raw)
To: Marcelo Schmitt, linux-iio, devicetree, linux-kernel
Cc: jic23, nuno.sa, Michael.Hennerich, andy, robh, krzk+dt, conor+dt,
julianbraha, marcelo.schmitt1
In-Reply-To: <0abf862eeb277ae82262d09b11b1446f04c47be7.1782397418.git.marcelo.schmitt@analog.com>
On 6/25/26 9:35 AM, Marcelo Schmitt wrote:
> Support for LTC2378-20 and similar analog-to-digital converters.
This should mention that it contains some future prep for offloading.
(Although would be a bit easier to review if we deferred adding the
offload stuff).
>
> Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
> ---
> Change log v3 -> v4:
> - Reworked the driver to make IIO channels static according to v3 feedback.
> - Updated to use default 8 bits_per_word for non-offloaded transfers.
> - Handled refin voltage reference supply for LTC2338.
> - Used spi_bpw_to_bytes() where applicable.
>
> MAINTAINERS | 1 +
> drivers/iio/adc/Kconfig | 12 ++
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/ltc2378.c | 395 ++++++++++++++++++++++++++++++++++++++
> 4 files changed, 409 insertions(+)
> create mode 100644 drivers/iio/adc/ltc2378.c
>
...
> diff --git a/drivers/iio/adc/ltc2378.c b/drivers/iio/adc/ltc2378.c
> new file mode 100644
> index 000000000000..9a9f32e4989b
> --- /dev/null
> +++ b/drivers/iio/adc/ltc2378.c
> @@ -0,0 +1,395 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Analog Devices LTC2378 ADC series driver
> + *
> + * Copyright (C) 2026 Analog Devices Inc.
> + * Author: Marcelo Schmitt <marcelo.schmitt@analog.com>
> + */
> +
> +#include <linux/bitops.h>
> +#include <linux/bits.h>
> +#include <linux/cleanup.h>
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/spi/spi.h>
> +#include <linux/types.h>
> +#include <linux/units.h>
> +
> +#include <linux/iio/iio.h>
> +#include <linux/iio/types.h>
> +
> +#define __LTC2378_DIFF_CHANNEL(_sign, _real_bits, _storage_bits, _offl)\
Why the leading underscores? I don't see a conflicting name.
> +{ \
> + .type = IIO_VOLTAGE, \
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
> + BIT(IIO_CHAN_INFO_SCALE) | \
> + (_offl ? BIT(IIO_CHAN_INFO_SAMP_FREQ) : 0), \
> + .info_mask_separate_available = _offl ? BIT(IIO_CHAN_INFO_SAMP_FREQ) : 0,\
> + .scan_index = 0, \
> + .scan_type = { \
> + .format = _sign ? IIO_SCAN_FORMAT_SIGNED_INT : \
> + IIO_SCAN_FORMAT_UNSIGNED_INT, \
> + .realbits = _real_bits, \
> + .storagebits = _storage_bits, \
> + .shift = (_offl ? 0 : _storage_bits - _real_bits), \
> + .endianness = _offl ? IIO_CPU : IIO_BE \
> + }, \
> +}
> +
> +#define LTC2378_BIPOLAR_DIFF_CHANNEL(_real_bits) \
> + __LTC2378_DIFF_CHANNEL(1, _real_bits, (((_real_bits) > 16) ? 32 : 16), 0)
> +
> +#define LTC2378_UNIPOLAR_DIFF_CHANNEL(_real_bits) \
> + __LTC2378_DIFF_CHANNEL(0, _real_bits, (((_real_bits) > 16) ? 32 : 16), 0)
Why not move the (((_real_bits) > 16) ? 32 : 16) into the __LTC2378_DIFF_CHANNEL()
macro to avoid repeating it?
> +
> +struct ltc2378_chip_info {
> + const char *name;
> + unsigned int internal_ref_uv;
_uV (to be consistent)
> + struct iio_chan_spec chan;
> +};
> +
...
> +static int ltc2378_regulator_setup(struct device *dev, struct ltc2378_state *st)
> +{
> + int ret;
> +
> + ret = devm_regulator_get_enable_read_voltage(dev, "refin");
> + if (ret < 0 && ret != -ENODEV) {
> + return dev_err_probe(dev, ret, "failed to read refin regulator\n");
> + } else if (ret > 0) {
Else is not needed here.
> + st->ref_uV = ret;
> + return 0;
> + }
> +
> + if (st->info->internal_ref_uv) {
> + st->ref_uV = st->info->internal_ref_uv;
> + return 0;
> + }
I would be tempted to have two separate functions here and only call one depending
on the chip. Otherwise, it allows incorrect devicetree.
> +
> + ret = devm_regulator_get_enable_read_voltage(dev, "ref");
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "failed to read ref regulator\n");
> +
> + st->ref_uV = ret;
> +
> + return 0;
> +}
> +
^ permalink raw reply
* Re: [PATCH v4 0/4] iio: adc: Add support for LTC2378 and similar ADCs
From: David Lechner @ 2026-06-27 21:39 UTC (permalink / raw)
To: Marcelo Schmitt, linux-iio, devicetree, linux-kernel
Cc: jic23, nuno.sa, Michael.Hennerich, andy, robh, krzk+dt, conor+dt,
julianbraha, marcelo.schmitt1
In-Reply-To: <cover.1782397418.git.marcelo.schmitt@analog.com>
On 6/25/26 9:34 AM, Marcelo Schmitt wrote:
> This patch series adds support for LTC2378 and similar low noise, low power,
> high speed, successive approximation register (SAR) ADCs. These ADCs are similar
> among each other, varying mainly on the amount of precision bits, maximum sample
> rate, and input configuration (either fully differential or pseudo-differential).
>
I had a few minor comments and I suspect Sashiko found a few legitimate
things. But this is looking really nice now.
Reviewed-by: David Lechner <dlechner@baylibre.com>
^ permalink raw reply
* Re: [External] [PATCH v2 4/8] riscv_cbqri: Add capacity controller probe and allocation device ops
From: Drew Fustini @ 2026-06-27 21:45 UTC (permalink / raw)
To: yunhui cui
Cc: Adrien Ricciardi, Alexandre Ghiti, Atish Kumar Patra, Atish Patra,
Babu Moger, Ben Horgan, Borislav Petkov, Chen Pei, Conor Dooley,
Conor Dooley, Dave Hansen, Dave Martin, Fenghua Yu, Gong Shuai,
Gong Shuai, guo.wenjia23, James Morse, Kornel Dulęba,
Krzysztof Kozlowski, liu.qingtao2, Liu Zhiwei, Palmer Dabbelt,
Paul Walmsley, Peter Newman, Radim Krčmář,
Reinette Chatre, Rob Herring, Samuel Holland,
Sebastian Andrzej Siewior, Tony Luck, Vasudevan Srinivasan,
Ved Shanbhogue, Weiwei Li, linux-kernel, linux-riscv, x86,
devicetree, linux-rt-devel, linux-doc
In-Reply-To: <CAEEQ3w=n6L3ugSL6_LTCQcw0CyUSSxpfEVV0Dp-CpQ_XkLUXPQ@mail.gmail.com>
On Sat, Jun 27, 2026 at 05:19:44PM +0800, yunhui cui wrote:
> Hi Drew,
>
> On Thu, Jun 25, 2026 at 9:41 AM Drew Fustini <fustini@kernel.org> wrote:
> >
> > Add support for the RISC-V CBQRI capacity controller. A platform driver
> > passes a cbqri_controller_info descriptor together with the cache level
> > to riscv_cbqri_register_cc_dt(), which probes the controller and adds it
> > to the controller list.
> >
> > Assisted-by: Claude:claude-opus-4-7
> > Co-developed-by: Adrien Ricciardi <aricciardi@baylibre.com>
> > Signed-off-by: Adrien Ricciardi <aricciardi@baylibre.com>
> > Signed-off-by: Drew Fustini <fustini@kernel.org>
> > ---
> > MAINTAINERS | 3 +
> > drivers/resctrl/Kconfig | 13 +
> > drivers/resctrl/Makefile | 3 +
> > drivers/resctrl/cbqri_devices.c | 520 +++++++++++++++++++++++++++++++++++++++
> > drivers/resctrl/cbqri_internal.h | 107 ++++++++
> > include/linux/riscv_cbqri.h | 47 ++++
> > 6 files changed, 693 insertions(+)
[..]
> > +int cbqri_apply_cache_config(struct cbqri_controller *ctrl, u32 closid,
> > + const struct cbqri_cc_config *cfg)
> > +{
[..]
> > +
> > + /* Set capacity block mask (cc_block_mask) */
> > + cbqri_set_cbm(ctrl, cfg->cbm);
> > +
> > + /* Capacity config limit operation for the AT half implied by cfg->at */
> > + err = cbqri_cc_alloc_op(ctrl, CBQRI_CC_ALLOC_CTL_OP_CONFIG_LIMIT,
> > + closid, cfg->at);
> > + if (err < 0)
> > + goto out;
>
> When CUNITS=1, CONFIG_LIMIT also consumes cc_cunits. If resctrl does not
> expose unit limits, the driver should still write cc_cunits=0 before
> CONFIG_LIMIT to avoid a hidden stale/implementation-defined unit limit.
>
> Should we handle cc_cunits here?
That is a good that cc_units should be handled even though we can't yet
expose it to resctrl. I will change the code to set cc_cunits to 0
before a config limit operation on controllers that support capacity
units, so a stale unit limit does not constrain block-mask allocation.
Thanks,
Drew
^ permalink raw reply
* Re: [External] [PATCH v2 3/8] riscv: Add support for srmcfg CSR from Ssqosid extension
From: Drew Fustini @ 2026-06-27 21:58 UTC (permalink / raw)
To: yunhui cui
Cc: Adrien Ricciardi, Alexandre Ghiti, Atish Kumar Patra, Atish Patra,
Babu Moger, Ben Horgan, Borislav Petkov, Chen Pei, Conor Dooley,
Conor Dooley, Dave Hansen, Dave Martin, Fenghua Yu, Gong Shuai,
Gong Shuai, guo.wenjia23, James Morse, Kornel Dulęba,
Krzysztof Kozlowski, liu.qingtao2, Liu Zhiwei, Palmer Dabbelt,
Paul Walmsley, Peter Newman, Radim Krčmář,
Reinette Chatre, Rob Herring, Samuel Holland,
Sebastian Andrzej Siewior, Tony Luck, Vasudevan Srinivasan,
Ved Shanbhogue, Weiwei Li, linux-kernel, linux-riscv, x86,
devicetree, linux-rt-devel, linux-doc
In-Reply-To: <CAEEQ3wkhiE=TdFTzEn39GVWSgGnaN0raBpmd=6sYaoh304LNBg@mail.gmail.com>
On Sat, Jun 27, 2026 at 05:38:28PM +0800, yunhui cui wrote:
> Hi Drew,
>
> On Thu, Jun 25, 2026 at 9:40 AM Drew Fustini <fustini@kernel.org> wrote:
[..]
> > +config RISCV_ISA_SSQOSID
> > + bool "Ssqosid extension support for supervisor mode Quality of Service ID"
> > + depends on 64BIT
>
> Why is 64BIT required here?
Sashiko raised many potential issues related to RV32 in reviews of my
RFC series:
v3: https://sashiko.dev/#/patchset/20260414-ssqosid-cbqri-rqsc-v7-0-v3-0-b3b2e7e9847a%40kernel.org
v4: https://sashiko.dev/#/patchset/20260510-ssqosid-cbqri-rqsc-v7-0-v4-0-eb53831ef683%40kernel.org
v5: https://sashiko.dev/#/patchset/20260524-ssqosid-cbqri-rqsc-v7-0-v5-0-78d3a7ba9dbe%40kernel.org
v6: https://sashiko.dev/#/patchset/20260601-ssqosid-cbqri-rqsc-v7-0-v6-0-baf00f50028a%40kernel.org
RV32 systems with CBQRI didn't seem likely to me so I decided requiring
64BIT would eliminate the potential issues that Sashiko raised. If there
is actually a 32-bit implementation that someone knows of, then I would
be happy to re-evaluate RV32 support.
Thanks,
Drew
^ permalink raw reply
* Re: [External] [PATCH v2 4/8] riscv_cbqri: Add capacity controller probe and allocation device ops
From: Drew Fustini @ 2026-06-27 22:10 UTC (permalink / raw)
To: yunhui cui
Cc: Adrien Ricciardi, Alexandre Ghiti, Atish Kumar Patra, Atish Patra,
Babu Moger, Ben Horgan, Borislav Petkov, Chen Pei, Conor Dooley,
Conor Dooley, Dave Hansen, Dave Martin, Fenghua Yu, Gong Shuai,
Gong Shuai, guo.wenjia23, James Morse, Kornel Dulęba,
Krzysztof Kozlowski, liu.qingtao2, Liu Zhiwei, Palmer Dabbelt,
Paul Walmsley, Peter Newman, Radim Krčmář,
Reinette Chatre, Rob Herring, Samuel Holland,
Sebastian Andrzej Siewior, Tony Luck, Vasudevan Srinivasan,
Ved Shanbhogue, Weiwei Li, linux-kernel, linux-riscv, x86,
devicetree, linux-rt-devel, linux-doc
In-Reply-To: <CAEEQ3w=ZVtHPdLfN0tTzG8AACu+rjhEFWY5pCg+uxvmr7ofqfA@mail.gmail.com>
On Sat, Jun 27, 2026 at 05:31:03PM +0800, yunhui cui wrote:
> Hi Drew,
>
> On Thu, Jun 25, 2026 at 9:41 AM Drew Fustini <fustini@kernel.org> wrote:
> >
> > Add support for the RISC-V CBQRI capacity controller. A platform driver
> > passes a cbqri_controller_info descriptor together with the cache level
> > to riscv_cbqri_register_cc_dt(), which probes the controller and adds it
> > to the controller list.
> >
> > Assisted-by: Claude:claude-opus-4-7
> > Co-developed-by: Adrien Ricciardi <aricciardi@baylibre.com>
> > Signed-off-by: Adrien Ricciardi <aricciardi@baylibre.com>
> > Signed-off-by: Drew Fustini <fustini@kernel.org>
[..]
> > diff --git a/drivers/resctrl/cbqri_devices.c b/drivers/resctrl/cbqri_devices.c
> > new file mode 100644
> > index 0000000000000000000000000000000000000000..8ad9df404f65d5d82722cf8b78f02936c489ca6d
> > --- /dev/null
> > +++ b/drivers/resctrl/cbqri_devices.c
[..]
> > +
> > +/* Set capacity block mask (cc_block_mask) */
> > +static void cbqri_set_cbm(struct cbqri_controller *ctrl, u64 cbm)
> > +{
> > + iowrite64(cbm, ctrl->base + CBQRI_CC_BLOCK_MASK_OFF);
>
> The CBQRI spec allows naturally aligned 4-byte accesses and only guarantees
> atomicity for 4-byte accesses; 8-byte atomicity is unspecified.
>
> Would 32-bit split accesses be preferable here instead of relying on
> ioread64/iowrite64? This may also make the driver less dependent on native
> 64-bit MMIO support.
I suppose there could be systems that are RV64 but do 4-byte access for
the CBQRI registers. You are right the spec only guarantees atomicity
for naturally aligned 4-byte accesses and leaves 8-byte atomicity
unspecified.
I will switch the controller register accesses to 32-bit reads and
writes. The driver rejects ncblks > 32, so cc_block_mask only uses its
low 32 bits. For cc_alloc_ctl, the writable fields all sit in the low
word while the status and busy bits are read-only in the high word. A
read can reconstruct the value from two 32-bit reads and a write only
needs the low word.
Thanks,
Drew
^ permalink raw reply
* Re: [PATCH v4 1/3] iio: adc: Fix incorrect reading when datarate changed in single mode
From: David Lechner @ 2026-06-27 22:31 UTC (permalink / raw)
To: Jakub Szczudlo, linux-iio
Cc: andy, antoniu.miclaus, conor+dt, devicetree, duje, jic23,
jishnu.prakash, jorge.marques, joshua.crofts1, krzk+dt, linusw,
linux-kernel, marcelo.schmitt, mazziesaccount, mike.looijmans,
nuno.sa, robh, sakari.ailus, wens
In-Reply-To: <20260622221550.374235-2-jakubszczudlo40@gmail.com>
On 6/22/26 5:15 PM, Jakub Szczudlo wrote:
> When device is suspended and it is in single mode then changing
> datarate doesn't make it actual wait for new measurement, so to
> be sure that read after change is correct functions that changes
> datarate and gain will wait for new data.
>
> Fixes: 541880542f2b ("iio: adc: Add TI ADS1100 and ADS1000")
> Signed-off-by: Jakub Szczudlo <jakubszczudlo40@gmail.com>
> ---
> drivers/iio/adc/ti-ads1100.c | 74 ++++++++++++++++++++++++++++++++++--
> 1 file changed, 70 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iio/adc/ti-ads1100.c b/drivers/iio/adc/ti-ads1100.c
> index 9fe8d54cce83..e3c801381434 100644
> --- a/drivers/iio/adc/ti-ads1100.c
> +++ b/drivers/iio/adc/ti-ads1100.c
> @@ -15,6 +15,7 @@
> #include <linux/module.h>
> #include <linux/init.h>
> #include <linux/i2c.h>
> +#include <linux/iopoll.h>
> #include <linux/mutex.h>
> #include <linux/property.h>
> #include <linux/pm_runtime.h>
> @@ -43,6 +44,9 @@
> static const int ads1100_data_rate[] = { 128, 32, 16, 8 };
> static const int ads1100_data_rate_bits[] = { 12, 14, 15, 16 };
>
> +/* Timeout based on the minimum sample rate of 8 SPS (7.5s) */
> +#define ADS1100_MAX_DRDY_TIMEOUT_US 7500000
> +
> struct ads1100_data {
> struct i2c_client *client;
> struct regulator *reg_vdd;
> @@ -123,10 +127,49 @@ static int ads1100_get_adc_result(struct ads1100_data *data, int chan, int *val)
> return 0;
> }
>
> +static bool ads1100_new_data_not_ready(struct ads1100_data *data)
> +{
> + int ret;
> + u8 buffer[3];
> +
> + ret = i2c_master_recv(data->client, (char *)&buffer, sizeof(buffer));
Do we actually need the cast here? char * is like void * and should not need it.
> + if (ret < 0) {
> + dev_err(&data->client->dev, "I2C read fail: %d\n", ret);
> + return true;
> + } else if (ret < 3) {
I don't think it is possible to return anything other than 3 or error.
In other words, short read without error is not possible.
> + dev_err(&data->client->dev, "Short I2C read\n");
> + return true;
> + }
> +
> + return FIELD_GET(ADS1100_CFG_ST_BSY, buffer[2]);
> +}
> +
> +static int ads1100_poll_data_ready(struct ads1100_data *data)
> +{
> + int ret;
> + u8 buffer[3];
> + bool data_ready;
> + int datarate = ads1100_data_rate[FIELD_GET(ADS1100_DR_MASK, data->config)];
> + /* To be sure we wait 5 times more than datarate */
> + unsigned long wait_time = DIV_ROUND_CLOSEST(MICRO, 5 * datarate);
This is a bit dense making it hard to read.
Also, it's always helpful to include units in variable names. wait_time_us?
data_rate_hz?
> +
> + /* To be sure that polled value will have value after config change */
> + ret = i2c_master_recv(data->client, (char *)&buffer, sizeof(buffer));
> + if (ret < 0) {
> + dev_err(&data->client->dev, "I2C read fail: %d\n", ret);
> + return ret;
> + }
> +
> + return read_poll_timeout(ads1100_new_data_not_ready, data_ready,
> + !data_ready, wait_time,
> + ADS1100_MAX_DRDY_TIMEOUT_US, false, data);
> +}
> +
^ permalink raw reply
* Re: [PATCH v4 3/3] iio: adc: Add ti-ads1110 support to ti-ads1100 driver
From: David Lechner @ 2026-06-27 22:42 UTC (permalink / raw)
To: Jakub Szczudlo, linux-iio
Cc: andy, antoniu.miclaus, conor+dt, devicetree, duje, jic23,
jishnu.prakash, jorge.marques, joshua.crofts1, krzk+dt, linusw,
linux-kernel, marcelo.schmitt, mazziesaccount, mike.looijmans,
nuno.sa, robh, sakari.ailus, wens
In-Reply-To: <20260622221550.374235-4-jakubszczudlo40@gmail.com>
On 6/22/26 5:15 PM, Jakub Szczudlo wrote:
> Add ADS1110 support that have faster datarate than ADS1100, it also uses
> internal voltage reference of 2.048V for measurement.
>
> Signed-off-by: Jakub Szczudlo <jakubszczudlo40@gmail.com>
> ---
> drivers/iio/adc/Kconfig | 6 +--
> drivers/iio/adc/ti-ads1100.c | 81 +++++++++++++++++++++++++++---------
> 2 files changed, 64 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 1c663c98c6c9..30198335c63b 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -1765,11 +1765,11 @@ config TI_ADS1018
> called ti-ads1018.
>
> config TI_ADS1100
> - tristate "Texas Instruments ADS1100 and ADS1000 ADC"
> + tristate "Texas Instruments ADS1100 and similar single channel I2C ADC"
> depends on I2C
> help
> - If you say yes here you get support for Texas Instruments ADS1100 and
> - ADS1000 ADC chips.
> + If you say yes here you get support TI ADS1100 and similar single
> + channel I2C Analog to Digital Converters.
>
> This driver can also be built as a module. If so, the module will be
> called ti-ads1100.
> diff --git a/drivers/iio/adc/ti-ads1100.c b/drivers/iio/adc/ti-ads1100.c
> index e3c801381434..ec79a89464fb 100644
> --- a/drivers/iio/adc/ti-ads1100.c
> +++ b/drivers/iio/adc/ti-ads1100.c
> @@ -5,7 +5,7 @@
> * Copyright (c) 2023, Topic Embedded Products
> *
> * Datasheet: https://www.ti.com/lit/gpn/ads1100
> - * IIO driver for ADS1100 and ADS1000 ADC 16-bit I2C
> + * IIO driver for ADS1100 and similar single channel ADC 16-bit I2C
> */
>
> #include <linux/bitfield.h>
> @@ -40,20 +40,44 @@
> #define ADS1100_SINGLESHOT ADS1100_CFG_SC
>
> #define ADS1100_SLEEP_DELAY_MS 2000
> +#define ADS1110_INTERNAL_REF_mV 2048
>
> static const int ads1100_data_rate[] = { 128, 32, 16, 8 };
> +static const int ads1110_data_rate[] = { 240, 60, 30, 15 };
> static const int ads1100_data_rate_bits[] = { 12, 14, 15, 16 };
>
> /* Timeout based on the minimum sample rate of 8 SPS (7.5s) */
> #define ADS1100_MAX_DRDY_TIMEOUT_US 7500000
>
> +struct ads1100_config {
> + const char *name;
> + const int *data_rate;
Usually, we would call an array like this available_data_rate_hz, otherwise
it sounds like a single value. And having units is always helpful.
> + const int data_rate_count;
> + bool has_internal_vref_only;
> +};
> +
> +static const struct ads1100_config ads1100_config = {
> + .name = "ads1100",
> + .data_rate = ads1100_data_rate,
> + .data_rate_count = ARRAY_SIZE(ads1100_data_rate),
> + .has_internal_vref_only = false,
> +};
> +
> +static const struct ads1100_config ads1110_config = {
> + .name = "ads1110",
> + .data_rate = ads1110_data_rate,
> + .data_rate_count = ARRAY_SIZE(ads1110_data_rate),
> + .has_internal_vref_only = true,
> +};
> +
> struct ads1100_data {
> struct i2c_client *client;
> struct regulator *reg_vdd;
> struct mutex lock;
> int scale_avail[2 * 4]; /* 4 gain settings */
> + const struct ads1100_config *ads_config;
> u8 config;
> - bool supports_data_rate; /* Only the ADS1100 can select the rate */
> + bool supports_data_rate;
> };
>
> static const struct iio_chan_spec ads1100_channel = {
> @@ -89,6 +113,14 @@ static int ads1100_set_config_bits(struct ads1100_data *data, u8 mask, u8 value)
> return 0;
> };
>
> +static int ads1100_get_vref_milivolts(struct ads1100_data *data)
> +{
> + if (data->ads_config->has_internal_vref_only)
> + return ADS1110_INTERNAL_REF_mV;
> +
> + return regulator_get_voltage(data->reg_vdd) / MILLI;
Technically, regulator_get_voltage() can return a negative error
which would be corrupted by dividing it.
> +}
> +
Usually, we just do this during probe and store vref_mV in the
private data struct as the regulator voltage doesn't typically
change at runtime. Could clean that up as a preliminary patch to
make this patch simpler.
> static int ads1100_data_bits(struct ads1100_data *data)
> {
> return ads1100_data_rate_bits[FIELD_GET(ADS1100_DR_MASK, data->config)];
> @@ -114,6 +146,9 @@ static int ads1100_get_adc_result(struct ads1100_data *data, int chan, int *val)
> if (ret < 0) {
> dev_err(&data->client->dev, "I2C read fail: %d\n", ret);
> return ret;
> + } else if (ret < 2) {
> + dev_err(&data->client->dev, "Short I2C read\n");
> + return -EIO;
As mentioned already, I think this is dead code. Not related to this
patch anyway.
> }
>
> /* Value is always 16-bit 2's complement */
> @@ -184,7 +219,7 @@ static int ads1100_set_scale(struct ads1100_data *data, int val, int val2)
> if (ret)
> return ret;
>
> - microvolts = regulator_get_voltage(data->reg_vdd);
> + microvolts = ads1100_get_vref_milivolts(data) * (MICRO / MILLI);
> /*
> * val2 is in 'micro' units, n = val2 / 1000000
> * result must be millivolts, d = microvolts / 1000
> @@ -209,9 +244,9 @@ static int ads1100_set_data_rate(struct ads1100_data *data, int chan, int rate)
> unsigned int size;
> int ret;
>
> - size = data->supports_data_rate ? ARRAY_SIZE(ads1100_data_rate) : 1;
> + size = data->supports_data_rate ? data->ads_config->data_rate_count : 1;
> for (i = 0; i < size; i++) {
> - if (ads1100_data_rate[i] != rate)
> + if (data->ads_config->data_rate[i] != rate)
> continue;
>
> PM_RUNTIME_ACQUIRE_AUTOSUSPEND(&data->client->dev, pm);
> @@ -233,14 +268,9 @@ static int ads1100_set_data_rate(struct ads1100_data *data, int chan, int rate)
> return -EINVAL;
> }
>
> -static int ads1100_get_vdd_millivolts(struct ads1100_data *data)
> -{
> - return regulator_get_voltage(data->reg_vdd) / (MICRO / MILLI);
> -}
> -
> static void ads1100_calc_scale_avail(struct ads1100_data *data)
> {
> - int millivolts = ads1100_get_vdd_millivolts(data);
> + int millivolts = ads1100_get_vref_milivolts(data);
> unsigned int i;
>
> for (i = 0; i < ARRAY_SIZE(data->scale_avail) / 2; i++) {
> @@ -262,9 +292,9 @@ static int ads1100_read_avail(struct iio_dev *indio_dev,
> switch (mask) {
> case IIO_CHAN_INFO_SAMP_FREQ:
> *type = IIO_VAL_INT;
> - *vals = ads1100_data_rate;
> + *vals = data->ads_config->data_rate;
> if (data->supports_data_rate)
> - *length = ARRAY_SIZE(ads1100_data_rate);
> + *length = data->ads_config->data_rate_count;
> else
> *length = 1;
> return IIO_AVAIL_LIST;
> @@ -283,6 +313,7 @@ static int ads1100_read_raw(struct iio_dev *indio_dev,
> int *val2, long mask)
> {
> int ret;
> + int data_rate_index;
> struct ads1100_data *data = iio_priv(indio_dev);
>
> guard(mutex)(&data->lock);
> @@ -299,12 +330,12 @@ static int ads1100_read_raw(struct iio_dev *indio_dev,
> return IIO_VAL_INT;
> case IIO_CHAN_INFO_SCALE:
> /* full-scale is the supply voltage in millivolts */
> - *val = ads1100_get_vdd_millivolts(data);
> + *val = ads1100_get_vref_milivolts(data);
> *val2 = 15 + FIELD_GET(ADS1100_PGA_MASK, data->config);
> return IIO_VAL_FRACTIONAL_LOG2;
> case IIO_CHAN_INFO_SAMP_FREQ:
> - *val = ads1100_data_rate[FIELD_GET(ADS1100_DR_MASK,
> - data->config)];
> + data_rate_index = FIELD_GET(ADS1100_DR_MASK, data->config);
> + *val = data->ads_config->data_rate[data_rate_index];
> return IIO_VAL_INT;
> default:
> return -EINVAL;
> @@ -373,6 +404,7 @@ static int ads1100_probe(struct i2c_client *client)
> struct iio_dev *indio_dev;
> struct ads1100_data *data;
> struct device *dev = &client->dev;
> + const struct ads1100_config *model;
> int ret;
>
> indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
> @@ -404,6 +436,13 @@ static int ads1100_probe(struct i2c_client *client)
> if (ret)
> return ret;
>
> + model = i2c_get_match_data(client);
> + if (!model)
> + return dev_err_probe(dev, -EINVAL,
> + "Can't get device data from firmware\n");
> +
> + data->ads_config = (struct ads1100_config *)model;
Just assign data->ads_config directly from i2c_get_match_data(). We don't
need local variable (or cast).
> +
> ret = ads1100_setup(data);
> if (ret)
> return dev_err_probe(dev, ret,
> @@ -466,16 +505,18 @@ static DEFINE_RUNTIME_DEV_PM_OPS(ads1100_pm_ops,
> NULL);
>
> static const struct i2c_device_id ads1100_id[] = {
> - { .name = "ads1100" },
> - { .name = "ads1000" },
> + { .name = "ads1000", .driver_data = (kernel_ulong_t)&ads1100_config },
> + { .name = "ads1100", .driver_data = (kernel_ulong_t)&ads1100_config },
> + { .name = "ads1110", .driver_data = (kernel_ulong_t)&ads1110_config },
> { }
> };
>
> MODULE_DEVICE_TABLE(i2c, ads1100_id);
>
> static const struct of_device_id ads1100_of_match[] = {
> - {.compatible = "ti,ads1100" },
> - {.compatible = "ti,ads1000" },
> + { .compatible = "ti,ads1000", .data = &ads1100_config },
> + { .compatible = "ti,ads1100", .data = &ads1100_config },
> + { .compatible = "ti,ads1110", .data = &ads1110_config },
> { }
> };
>
^ permalink raw reply
* [PATCH 1/3] dt-bindings: vendor-prefixes: Add graperain
From: Coia Prant @ 2026-06-27 22:57 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Dragan Simic, Jonas Karlman
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
Coia Prant
Add graperain to the vendor prefixes.
Link: https://www.graperain.cn/ (China)
Link: https://www.graperain.com/ (Global)
Signed-off-by: Coia Prant <coiaprant@gmail.com>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 396044f36..641a37c0d 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -682,6 +682,8 @@ patternProperties:
description: Goramo Gorecki
"^gplus,.*":
description: GPLUS
+ "^graperain,.*":
+ description: Shenzhen Graperain Technology Co., Ltd.
"^grinn,.*":
description: Grinn
"^grmn,.*":
--
2.47.3
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: arm: rockchip: Add Graperain G3568 series
From: Coia Prant @ 2026-06-27 22:57 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Dragan Simic, Jonas Karlman
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
Coia Prant
In-Reply-To: <20260627225755.1710837-2-coiaprant@gmail.com>
This documents Graperain G3568 v2 which is a development board based on RK3568 SoC.
This series also have an SBC series with the suffix "box".
This board is development board series, not SBC series.
Link: https://www.graperain.cn/RK3568/RK3568-Development/ (China)
Link: https://www.graperain.com/ARM-Embedded-RK3568-Development-Board/ (Global)
Link: https://image.chukouplus.com/upload/C_153/product_file/20211022/6daddec9e400458816dd4c57ba807fc3.pdf
Signed-off-by: Coia Prant <coiaprant@gmail.com>
---
Documentation/devicetree/bindings/arm/rockchip.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 1a9dde186..873d41bff 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -683,6 +683,12 @@ properties:
- const: google,veyron-tiger
- const: google,veyron
- const: rockchip,rk3288
+
+ - description: Graperain G3568 series board
+ items:
+ - enum:
+ - graperain,g3568-v2
+ - const: rockchip,rk3568
- description: H96 Max V58 TV Box
items:
--
2.47.3
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: rockchip: Add devicetree for the Graperain G3568 v2
From: Coia Prant @ 2026-06-27 22:57 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Dragan Simic, Jonas Karlman
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
Coia Prant
In-Reply-To: <20260627225755.1710837-2-coiaprant@gmail.com>
The Graperain G3568 v2 is an RK3568-based development board, just like the RK3568-EVB.
It always uses soldered connections between the GR3568CV2 core board and the
RK3568BV2/GR3568BV2 I/O board.
The G3568 board has multiple hardware revisions, and we currently support v2 (I/O board).
Specification:
- SoC: RockChip RK3568 ARM64 (4 cores)
- eMMC: 16-128 GB
- RAM: 2-16 GB
- Power: DC 12V 2A
- Ethernet: 2x RTL8211F RGMII (10/100/1000 Mbps)
- Wireless radio: 802.11b/g/n/ac dual-band
- LED:
Power: AlwaysOn
User: GPIO
- Button:
ESC: SARADC/0 <1100k µV>
MENU: SARADC/0 <1400k µV>
VOL-: SARADC/0 <430k µV>
VOL+: SARADC/0 <50k µV>
Power/Reset: PMIC RK809
- CAN
CAN/1: 4-pin (PH 2.0)
- PWM
PWM/4: Backlight
PWM/5: Backlight
PWM/7: IR Receiver
- UART:
UART/2: Debug TTL - 1500000 8N1 (1.25mm)
UART/3: TTL (PH 2.0)
UART/4: TTL (PH 2.0)
UART/8: AP6356S Bluetooth
UART/9: TTL (PH 2.0)
- I2C:
I2C/0: PMIC RK809
I2C/1: Touchscreen
I2C/4: Camera
I2C/5: RTC@51 PCF8563
- I2S:
I2S/0: HDMI Sound
I2S/1: RK809 Audio Codec
I2S/3: AP6356S Bluetooth Sound
- SDMMC:
SDMMC/0: microSD (TF) slot
SDMMC/2: AP6356S SDIO WiFi card
- Camera: 1x CSI
- Video: HDMI / DSI0 (MIPI/LVDS) / DSI1 (MIPI/EDP)
- Audio: HDMI / MIC / Speaker / SPDIF / 3.5mm Headphones / AP6356S Bluetooth
- USB:
USB 2.0 HOST x2
USB 2.0 OTG x1 (shared with USB 3.0 OTG/HOST)
USB 3.0 HOST x1
USB 3.0 OTG/HOST x1
- SATA: 1x SATA 3.0 with Power/4-pin
- PCIe: 1x PCIe 3.0 x2 (x4 connecter)
Link:
- https://image.chukouplus.com/upload/C_153/product_file/20211022/6daddec9e400458816dd4c57ba807fc3.pdf
- https://blog.gov.cooking/archives/research-graperain-g3568-v2-and-flash.html
Signed-off-by: Coia Prant <coiaprant@gmail.com>
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../rockchip/rk3568-graperain-g3568-v2.dts | 894 ++++++++++++++++++
2 files changed, 895 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-graperain-g3568-v2.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 761d82b4f..6e9d049e8 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -144,6 +144,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-easepi-r1.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-evb1-v10.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-fastrhino-r66s.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-fastrhino-r68s.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-graperain-g3568-v2.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-hinlink-h66k.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-hinlink-h68k.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-lubancat-2.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-graperain-g3568-v2.dts b/arch/arm64/boot/dts/rockchip/rk3568-graperain-g3568-v2.dts
new file mode 100644
index 000000000..221992d6c
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3568-graperain-g3568-v2.dts
@@ -0,0 +1,894 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,vop2.h>
+#include "rk3568.dtsi"
+
+/ {
+ model = "Graperain G3568 v2";
+ compatible = "graperain,g3568-v2", "rockchip,rk3568";
+
+ aliases {
+ ethernet0 = &gmac0;
+ ethernet1 = &gmac1;
+ mmc0 = &sdhci;
+ mmc1 = &sdmmc0;
+ mmc2 = &sdmmc2;
+ rtc0 = &rtc0;
+ };
+
+ chosen {
+ stdout-path = "serial2:1500000n8";
+ };
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = <&saradc 0>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <1800000>;
+ poll-interval = <100>;
+
+ button-esc {
+ label = "esc";
+ linux,code = <KEY_ESC>;
+ press-threshold-microvolt = <1250000>;
+ };
+
+ button-menu {
+ label = "menu";
+ linux,code = <KEY_MENU>;
+ press-threshold-microvolt = <1600000>;
+ };
+
+ button-vol-down {
+ label = "volume down";
+ linux,code = <KEY_VOLUMEDOWN>;
+ press-threshold-microvolt = <600000>;
+ };
+
+ button-vol-up {
+ label = "volume up";
+ linux,code = <KEY_VOLUMEUP>;
+ press-threshold-microvolt = <100000>;
+ };
+ };
+
+ hdmi-con {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_work: led-0 {
+ gpios = <&gpio0 RK_PC0 GPIO_ACTIVE_HIGH>;
+ function = LED_FUNCTION_HEARTBEAT;
+ color = <LED_COLOR_ID_BLUE>;
+ linux,default-trigger = "heartbeat";
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_work_en>;
+ };
+ };
+
+ rk809-sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,name = "Analog RK809";
+ simple-audio-card,mclk-fs = <256>;
+
+ simple-audio-card,cpu {
+ sound-dai = <&i2s1_8ch>;
+ };
+ simple-audio-card,codec {
+ sound-dai = <&rk809>;
+ };
+ };
+
+ pdm_codec: pdm-codec {
+ compatible = "dmic-codec";
+ num-channels = <2>;
+ #sound-dai-cells = <0>;
+ };
+
+ pdm_sound: pdm-sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "microphone";
+
+ simple-audio-card,cpu {
+ sound-dai = <&pdm>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&pdm_codec>;
+ };
+ };
+
+ spdif_dit: spdif-dit {
+ compatible = "linux,spdif-dit";
+ #sound-dai-cells = <0>;
+ };
+
+ spdif_sound: spdif-sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "SPDIF";
+
+ simple-audio-card,cpu {
+ sound-dai = <&spdif>;
+ };
+ simple-audio-card,codec {
+ sound-dai = <&spdif_dit>;
+ };
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <&rk809 1>;
+ clock-names = "ext_clock";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_enable>;
+ post-power-on-delay-ms = <100>;
+ power-off-delay-us = <300>;
+ reset-gpios = <&gpio3 RK_PD5 GPIO_ACTIVE_LOW>;
+ };
+
+ dc_12v: regulator-dc-12v {
+ compatible = "regulator-fixed";
+ regulator-name = "dc_12v";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ };
+
+ pcie30_avdd0v9: regulator-pcie30-avdd0v9 {
+ compatible = "regulator-fixed";
+ regulator-name = "pcie30_avdd0v9";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+ vin-supply = <&vcc3v3_sys>;
+ };
+
+ pcie30_avdd1v8: regulator-pcie30-avdd1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "pcie30_avdd1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vcc3v3_sys>;
+ };
+
+ vcc3v3_sys: regulator-vcc3v3-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&dc_12v>;
+ };
+
+ vcc3v3_pcie: regulator-vcc3v3-pcie {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio3 RK_PC3 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc3v3_pcie_en_pin>;
+ regulator-name = "vcc3v3_pcie";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ startup-delay-us = <5000>;
+ vin-supply = <&dc_12v>;
+ };
+
+ vcc5v0_sys: regulator-vcc5v0-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&dc_12v>;
+ };
+
+ vcc5v0_usb: regulator-vcc5v0-usb {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_usb";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&dc_12v>;
+ };
+
+ vcc5v0_usb_host: regulator-vcc5v0-usb-host {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio0 RK_PA6 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc5v0_usb_host_en>;
+ regulator-name = "vcc5v0_usb_host";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc5v0_usb>;
+ };
+
+ vcc5v0_usb_otg: regulator-vcc5v0-usb-otg {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio0 RK_PA5 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc5v0_usb_otg_en>;
+ regulator-name = "vcc5v0_usb_otg";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc5v0_usb>;
+ };
+};
+
+&can1 {
+ assigned-clocks = <&cru CLK_CAN1>;
+ assigned-clock-rates = <150000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&can1m1_pins>;
+ status = "okay";
+};
+
+/* used for usb_host0_xhci */
+&combphy0 {
+ status = "okay";
+};
+
+/* used for usb_host1_xhci */
+&combphy1 {
+ status = "okay";
+};
+
+/* connected to sata2 */
+&combphy2 {
+ status = "okay";
+};
+
+&cpu0 {
+ cpu-supply = <&vdd_cpu>;
+};
+
+&cpu1 {
+ cpu-supply = <&vdd_cpu>;
+};
+
+&cpu2 {
+ cpu-supply = <&vdd_cpu>;
+};
+
+&cpu3 {
+ cpu-supply = <&vdd_cpu>;
+};
+
+&gmac0 {
+ assigned-clocks = <&cru SCLK_GMAC0_RX_TX>, <&cru SCLK_GMAC0>;
+ assigned-clock-parents = <&cru SCLK_GMAC0_RGMII_SPEED>;
+ assigned-clock-rates = <0>, <125000000>;
+ clock_in_out = "output";
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac0_miim
+ &gmac0_tx_bus2
+ &gmac0_rx_bus2
+ &gmac0_rgmii_clk
+ &gmac0_rgmii_bus>;
+ phy-handle = <&rgmii_phy0>;
+ phy-mode = "rgmii-id";
+ status = "okay";
+};
+
+&gmac1 {
+ assigned-clocks = <&cru SCLK_GMAC1_RX_TX>, <&cru SCLK_GMAC1>;
+ assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>;
+ assigned-clock-rates = <0>, <125000000>;
+ clock_in_out = "output";
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac1m1_miim
+ &gmac1m1_tx_bus2
+ &gmac1m1_rx_bus2
+ &gmac1m1_rgmii_clk
+ &gmac1m1_rgmii_bus>;
+ phy-handle = <&rgmii_phy1>;
+ phy-mode = "rgmii-id";
+ status = "okay";
+};
+
+&gpu {
+ mali-supply = <&vdd_gpu>;
+ status = "okay";
+};
+
+&hdmi {
+ avdd-0v9-supply = <&vdda0v9_image>;
+ avdd-1v8-supply = <&vcca1v8_image>;
+ status = "okay";
+};
+
+&hdmi_in {
+ hdmi_in_vp0: endpoint {
+ remote-endpoint = <&vp0_out_hdmi>;
+ };
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
+&hdmi_sound {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ vdd_cpu: regulator@1c {
+ compatible = "tcs,tcs4525";
+ reg = <0x1c>;
+ fcs,suspend-voltage-selector = <1>;
+ regulator-name = "vdd_cpu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1150000>;
+ regulator-ramp-delay = <2300>;
+ vin-supply = <&vcc5v0_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ rk809: pmic@20 {
+ compatible = "rockchip,rk809";
+ reg = <0x20>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PA3 IRQ_TYPE_LEVEL_LOW>;
+ assigned-clocks = <&cru I2S1_MCLKOUT_TX>;
+ assigned-clock-parents = <&cru CLK_I2S1_8CH_TX>;
+ #clock-cells = <1>;
+ clock-names = "mclk";
+ clocks = <&cru I2S1_MCLKOUT_TX>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int>, <&i2s1m0_mclk>;
+ system-power-controller;
+ #sound-dai-cells = <0>;
+ vcc1-supply = <&vcc3v3_sys>;
+ vcc2-supply = <&vcc3v3_sys>;
+ vcc3-supply = <&vcc3v3_sys>;
+ vcc4-supply = <&vcc3v3_sys>;
+ vcc5-supply = <&vcc3v3_sys>;
+ vcc6-supply = <&vcc3v3_sys>;
+ vcc7-supply = <&vcc3v3_sys>;
+ vcc8-supply = <&vcc3v3_sys>;
+ vcc9-supply = <&vcc3v3_sys>;
+ wakeup-source;
+
+ regulators {
+ vdd_logic: DCDC_REG1 {
+ regulator-name = "vdd_logic";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-initial-mode = <0x2>;
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_gpu: DCDC_REG2 {
+ regulator-name = "vdd_gpu";
+ regulator-always-on;
+ regulator-initial-mode = <0x2>;
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_ddr: DCDC_REG3 {
+ regulator-name = "vcc_ddr";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-initial-mode = <0x2>;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vdd_npu: DCDC_REG4 {
+ regulator-name = "vdd_npu";
+ regulator-initial-mode = <0x2>;
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_1v8: DCDC_REG5 {
+ regulator-name = "vcc_1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda0v9_image: LDO_REG1 {
+ regulator-name = "vdda0v9_image";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda_0v9: LDO_REG2 {
+ regulator-name = "vdda_0v9";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda0v9_pmu: LDO_REG3 {
+ regulator-name = "vdda0v9_pmu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <900000>;
+ };
+ };
+
+ vccio_acodec: LDO_REG4 {
+ regulator-name = "vccio_acodec";
+ regulator-always-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vccio_sd: LDO_REG5 {
+ regulator-name = "vccio_sd";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc3v3_pmu: LDO_REG6 {
+ regulator-name = "vcc3v3_pmu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vcca_1v8: LDO_REG7 {
+ regulator-name = "vcca_1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcca1v8_pmu: LDO_REG8 {
+ regulator-name = "vcca1v8_pmu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcca1v8_image: LDO_REG9 {
+ regulator-name = "vcca1v8_image";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_3v3: SWITCH_REG1 {
+ regulator-name = "vcc_3v3";
+ regulator-always-on;
+ regulator-boot-on;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc3v3_sd: SWITCH_REG2 {
+ regulator-name = "vcc3v3_sd";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+ };
+
+ codec {
+ rockchip,mic-in-differential;
+ };
+ };
+};
+
+&i2c5 {
+ status = "okay";
+
+ rtc0: rtc@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ #clock-cells = <0>;
+ };
+};
+
+&i2s0_8ch {
+ status = "okay";
+};
+
+&i2s1_8ch {
+ pinctrl-0 = <&i2s1m0_sclktx &i2s1m0_lrcktx &i2s1m0_sdi0 &i2s1m0_sdo0>;
+ rockchip,trcm-sync-tx-only;
+ status = "okay";
+};
+
+/* used for AP6356S Bluetooth Sound */
+&i2s3_2ch {
+ status = "okay";
+};
+
+&mdio0 {
+ rgmii_phy0: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ reset-assert-us = <20000>;
+ reset-deassert-us = <100000>;
+ reset-gpios = <&gpio2 RK_PD3 GPIO_ACTIVE_LOW>;
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ default-state = "keep";
+ };
+
+ led@2 {
+ reg = <2>;
+ color = <LED_COLOR_ID_AMBER>;
+ function = LED_FUNCTION_LAN;
+ default-state = "keep";
+ };
+ };
+ };
+};
+
+&mdio1 {
+ rgmii_phy1: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ reset-assert-us = <20000>;
+ reset-deassert-us = <100000>;
+ reset-gpios = <&gpio2 RK_PD1 GPIO_ACTIVE_LOW>;
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ default-state = "keep";
+ };
+
+ led@2 {
+ reg = <2>;
+ color = <LED_COLOR_ID_AMBER>;
+ function = LED_FUNCTION_LAN;
+ default-state = "keep";
+ };
+ };
+ };
+};
+
+&pcie30phy {
+ status = "okay";
+};
+
+&pcie3x2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie_reset_pin>;
+ reset-gpios = <&gpio2 RK_PD6 GPIO_ACTIVE_HIGH>;
+ vpcie3v3-supply = <&vcc3v3_pcie>;
+ status = "okay";
+};
+
+&pdm {
+ status = "okay";
+};
+
+&pinctrl {
+ leds {
+ led_work_en: led_work_en {
+ rockchip,pins = <0 RK_PC0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pmic {
+ pmic_int: pmic_int {
+ rockchip,pins = <0 RK_PA3 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ sdio-pwrseq {
+ wifi_enable: wifi-enable {
+ rockchip,pins = <3 RK_PD5 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ usb {
+ vcc5v0_usb_host_en: vcc5v0_usb_host_en {
+ rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ vcc5v0_usb_otg_en: vcc5v0_usb_otg_en {
+ rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pcie {
+ pcie_reset_pin: pcie-reset-pin {
+ rockchip,pins = <2 RK_PD6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ vcc3v3_pcie_en_pin: vcc3v3-pcie-en-pin {
+ rockchip,pins = <3 RK_PC3 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&pmu_io_domains {
+ pmuio1-supply = <&vcc3v3_pmu>;
+ pmuio2-supply = <&vcc3v3_pmu>;
+ vccio1-supply = <&vccio_acodec>;
+ vccio2-supply = <&vcc_1v8>;
+ vccio3-supply = <&vccio_sd>;
+ vccio4-supply = <&vcc_1v8>;
+ vccio5-supply = <&vcc_3v3>;
+ vccio6-supply = <&vcc_1v8>;
+ vccio7-supply = <&vcc_3v3>;
+ status = "okay";
+};
+
+&pwm4 {
+ status = "okay";
+};
+
+&pwm5 {
+ status = "okay";
+};
+
+/* Required remotectl for IR receiver */
+&pwm7 {
+ status = "disabled";
+};
+
+&saradc {
+ vref-supply = <&vcca_1v8>;
+ status = "okay";
+};
+
+&sata2 {
+ status = "okay";
+};
+
+/* used for eMMC */
+&sdhci {
+ bus-width = <8>;
+ max-frequency = <200000000>;
+ mmc-hs200-1_8v;
+ non-removable;
+ pinctrl-names = "default";
+ pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>;
+ status = "okay";
+};
+
+/* used for microSD (TF) Slot */
+&sdmmc0 {
+ bus-width = <4>;
+ cap-sd-highspeed;
+ cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
+ disable-wp;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc0_bus4 &sdmmc0_clk &sdmmc0_cmd &sdmmc0_det>;
+ sd-uhs-sdr104;
+ vmmc-supply = <&vcc3v3_sd>;
+ vqmmc-supply = <&vccio_sd>;
+ status = "okay";
+};
+
+/* used for AP6356S WiFi */
+&sdmmc2 {
+ bus-width = <4>;
+ cap-sd-highspeed;
+ cap-sdio-irq;
+ keep-power-in-suspend;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ non-removable;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc2m0_bus4 &sdmmc2m0_cmd &sdmmc2m0_clk>;
+ sd-uhs-sdr104;
+ vmmc-supply = <&vcc3v3_sys>;
+ vqmmc-supply = <&vcc_1v8>;
+ status = "okay";
+};
+
+&spdif {
+ status = "okay";
+};
+
+&tsadc {
+ rockchip,hw-tshut-mode = <1>;
+ rockchip,hw-tshut-polarity = <0>;
+ status = "okay";
+};
+
+/* used for Debug */
+&uart2 {
+ status = "okay";
+};
+
+&uart3 {
+ pinctrl-0 = <&uart3m1_xfer>;
+ status = "okay";
+};
+
+&uart4 {
+ pinctrl-0 = <&uart4m1_xfer>;
+ status = "okay";
+};
+
+/* used for WiFi/BT AP6356S */
+&uart8 {
+ pinctrl-0 = <&uart8m0_xfer &uart8m0_ctsn>;
+ status = "okay";
+};
+
+&uart9 {
+ pinctrl-0 = <&uart9m1_xfer>;
+ status = "okay";
+};
+
+&usb_host0_ehci {
+ status = "okay";
+};
+
+&usb_host0_ohci {
+ status = "okay";
+};
+
+&usb_host0_xhci {
+ extcon = <&usb2phy0>;
+ status = "okay";
+};
+
+&usb_host1_ehci {
+ status = "okay";
+};
+
+&usb_host1_ohci {
+ status = "okay";
+};
+
+&usb_host1_xhci {
+ status = "okay";
+};
+
+&usb2phy0 {
+ status = "okay";
+};
+
+&usb2phy0_host {
+ phy-supply = <&vcc5v0_usb_host>;
+ status = "okay";
+};
+
+&usb2phy0_otg {
+ phy-supply = <&vcc5v0_usb_otg>;
+ status = "okay";
+};
+
+&usb2phy1 {
+ status = "okay";
+};
+
+&usb2phy1_host {
+ phy-supply = <&vcc5v0_usb_host>;
+ status = "okay";
+};
+
+&usb2phy1_otg {
+ phy-supply = <&vcc5v0_usb_host>;
+ status = "okay";
+};
+
+&vop {
+ assigned-clocks = <&cru DCLK_VOP0>, <&cru DCLK_VOP1>;
+ assigned-clock-parents = <&pmucru PLL_HPLL>, <&cru PLL_VPLL>;
+ status = "okay";
+};
+
+&vop_mmu {
+ status = "okay";
+};
+
+&vp0 {
+ vp0_out_hdmi: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
+ reg = <ROCKCHIP_VOP2_EP_HDMI0>;
+ remote-endpoint = <&hdmi_in_vp0>;
+ };
+};
--
2.47.3
^ 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