* Re: [PATCH] arm64: dts: qcom: Move board nodes to common DTSI
From: Sibi Sankar @ 2026-03-26 16:55 UTC (permalink / raw)
To: Krzysztof Kozlowski, Gopikrishna Garmidi, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, rajendra.nayak
In-Reply-To: <03996c07-f9f3-4586-96ae-075927da2577@kernel.org>
On 3/26/2026 7:55 PM, Krzysztof Kozlowski wrote:
> On 26/03/2026 15:21, Gopikrishna Garmidi wrote:
>> The display, peripherals (touchpad/touchscreen/keypad), usb and their
>> dependent device nodes are common to both Glymur and Mahua CRDs,
>> so move them from glymur-crd.dts to glymur-crd.dtsi to enable code
>> reuse.
>>
> Same questions as for earlier tries (why this has to be repeated?), e.g.
> x1-crd: Please describe here what is the actual common hardware. In
> terms of physical hardware, not what you want to share.
There seems to be some kind of confusion here. This patch doesn't
introduce the common board file rather it just moves the nodes
mentioned in the commit message to the common board file.
https://lore.kernel.org/lkml/20260318124100.212992-3-gopikrishna.garmidi@oss.qualcomm.com/
The actual creation of the common board file was done ^^.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v1 2/3] arm64: dts: freescale: Add support for Variscite DART-MX93
From: Andrew Lunn @ 2026-03-26 16:41 UTC (permalink / raw)
To: Stefano Radaelli
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Shawn Guo, Dario Binacchi, Alexander Stein, Maud Spierings,
Josua Mayer, Markus Niebel, Francesco Dolcini, Primoz Fiser
In-Reply-To: <304e5edc9ed11a552ac96c28d1046e4b13d5f960.1774539301.git.stefano.r@variscite.com>
> +&eqos {
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&pinctrl_eqos>;
> + pinctrl-1 = <&pinctrl_eqos_sleep>;
> + /*
> + * The required RGMII TX and RX 2ns delays are implemented directly
> + * in hardware via passive delay elements on the SOM PCB.
> + * No delay configuration is needed in software via PHY driver.
> + */
> + phy-mode = "rgmii";
> + phy-handle = <ðphy0>;
> + snps,clk-csr = <5>;
> + status = "okay";
> +
> + mdio {
> + compatible = "snps,dwmac-mdio";
> + clock-frequency = < 1000000>;
As far as i know, stmmac does not implement that property. There is
the danger somebody does implement it sometime in the future, and your
board breaks because it does not work a 10MHz.
I suggest removing this.
Andrew
^ permalink raw reply
* Re: [PATCH] dt-bindings: sound: Convert pcm3060 to DT schema
From: Rob Herring (Arm) @ 2026-03-26 16:32 UTC (permalink / raw)
To: Padmashree S S
Cc: lgirdwood, linux-sound, linux-kernel, krzk+dt, broonie, conor+dt,
k.marinushkin, devicetree
In-Reply-To: <20260326153041.496811-1-padmashreess2006@gmail.com>
On Thu, 26 Mar 2026 21:00:40 +0530, Padmashree S S wrote:
> Note:
> * This patch is part of the GSoC2026 application process for device tree bindings conversions
> * https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
>
> Signed-off-by: Padmashree S S <padmashreess2006@gmail.com>
> ---
> .../devicetree/bindings/sound/pcm3060.txt | 23 ----------
> .../devicetree/bindings/sound/pcm3060.yaml | 45 +++++++++++++++++++
> 2 files changed, 45 insertions(+), 23 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/sound/pcm3060.txt
> create mode 100644 Documentation/devicetree/bindings/sound/pcm3060.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
./Documentation/devicetree/bindings/sound/pcm3060.yaml:45:7: [error] no new line character at the end of file (new-line-at-end-of-file)
dtschema/dtc warnings/errors:
doc reference errors (make refcheckdocs):
Warning: MAINTAINERS references a file that doesn't exist: Documentation/devicetree/bindings/sound/pcm3060.txt
MAINTAINERS: Documentation/devicetree/bindings/sound/pcm3060.txt
See https://patchwork.kernel.org/project/devicetree/patch/20260326153041.496811-1-padmashreess2006@gmail.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v2 2/2] hwmon: (pmbus/q54sj108a2) Add support for q50sn12072 and q54sn120a1
From: Guenter Roeck @ 2026-03-26 16:29 UTC (permalink / raw)
To: Brian Chiang
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
linux-kernel, linux-hwmon, Jack Cheng
In-Reply-To: <20260326-add-support-for-q50sn12072-and-q54sn120a1-v2-2-77bc77eedc76@inventec.com>
On Thu, Mar 26, 2026 at 01:48:06PM +0000, Brian Chiang wrote:
> From: Jack Cheng <cheng.jackhy@inventec.com>
>
> The Q50SN12072 and Q54SN120A1 are high-efficiency, high-density DC-DC power
> module from Delta Power Modules.
>
> The Q50SN12072, quarter brick, single output 12V. This product provides up
> to 1200 watts of output power at 38~60V. The Q50SN12072 offers peak
> efficiency up to 98.3%@54Vin.
>
> The Q54SN120A1, quarter brick, single output 12V. This product provides up
> to 1300 watts of output power at 40~60V. The Q54SN120A1 offers peak
> efficiency up to 98.1%@54Vin.
>
> Add support for them to q54sj108a2 driver.
>
> Signed-off-by: Jack Cheng <cheng.jackhy@inventec.com>
> Co-developed-by: Brian Chiang <chiang.brian@inventec.com>
> Signed-off-by: Brian Chiang <chiang.brian@inventec.com>
> ---
> drivers/hwmon/pmbus/q54sj108a2.c | 97 ++++++++++++++++++++++++++++------------
> 1 file changed, 68 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/hwmon/pmbus/q54sj108a2.c b/drivers/hwmon/pmbus/q54sj108a2.c
> index d5d60a9af8c5..cc2b32ad935c 100644
> --- a/drivers/hwmon/pmbus/q54sj108a2.c
> +++ b/drivers/hwmon/pmbus/q54sj108a2.c
> @@ -22,7 +22,9 @@
> #define PMBUS_FLASH_KEY_WRITE 0xEC
>
> enum chips {
> - q54sj108a2
> + q50sn12072,
> + q54sj108a2,
> + q54sn120a1
> };
>
> enum {
> @@ -55,10 +57,24 @@ struct q54sj108a2_data {
> #define to_psu(x, y) container_of((x), struct q54sj108a2_data, debugfs_entries[(y)])
>
> static struct pmbus_driver_info q54sj108a2_info[] = {
> - [q54sj108a2] = {
> + [q50sn12072] = {
> .pages = 1,
> + /* Source : Delta Q50SN12072 */
> + .format[PSC_VOLTAGE_OUT] = linear,
> + .format[PSC_TEMPERATURE] = linear,
> + .format[PSC_VOLTAGE_IN] = linear,
> + .format[PSC_CURRENT_OUT] = linear,
>
> + .func[0] = PMBUS_HAVE_VIN | PMBUS_HAVE_IIN | PMBUS_HAVE_PIN |
> + PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT |
> + PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT |
> + PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP |
> + PMBUS_HAVE_STATUS_INPUT | PMBUS_HAVE_POUT,
> + },
> + [q54sj108a2] = {
> + .pages = 1,
> /* Source : Delta Q54SJ108A2 */
> + .format[PSC_VOLTAGE_OUT] = linear,
> .format[PSC_TEMPERATURE] = linear,
> .format[PSC_VOLTAGE_IN] = linear,
> .format[PSC_CURRENT_OUT] = linear,
> @@ -69,6 +85,20 @@ static struct pmbus_driver_info q54sj108a2_info[] = {
> PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP |
> PMBUS_HAVE_STATUS_INPUT,
> },
> + [q54sn120a1] = {
> + .pages = 1,
> + /* Source : Delta Q54SN120A1 */
> + .format[PSC_VOLTAGE_OUT] = linear,
> + .format[PSC_TEMPERATURE] = linear,
> + .format[PSC_VOLTAGE_IN] = linear,
> + .format[PSC_CURRENT_OUT] = linear,
> +
> + .func[0] = PMBUS_HAVE_VIN | PMBUS_HAVE_IIN | PMBUS_HAVE_PIN |
> + PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT |
> + PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT |
> + PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP |
> + PMBUS_HAVE_STATUS_INPUT | PMBUS_HAVE_POUT,
> + },
> };
>
> static ssize_t q54sj108a2_debugfs_read(struct file *file, char __user *buf,
> @@ -270,7 +300,9 @@ static const struct file_operations q54sj108a2_fops = {
> };
>
> static const struct i2c_device_id q54sj108a2_id[] = {
> + { "q50sn12072", q50sn12072 },
> { "q54sj108a2", q54sj108a2 },
> + { "q54sn120a1", q54sn120a1 },
> { },
> };
>
> @@ -280,6 +312,7 @@ static int q54sj108a2_probe(struct i2c_client *client)
> {
> struct device *dev = &client->dev;
> u8 buf[I2C_SMBUS_BLOCK_MAX + 1];
> + const struct i2c_device_id *mid;
> enum chips chip_id;
> int ret, i;
> struct dentry *debugfs;
> @@ -292,14 +325,9 @@ static int q54sj108a2_probe(struct i2c_client *client)
> I2C_FUNC_SMBUS_BLOCK_DATA))
> return -ENODEV;
>
> - if (client->dev.of_node)
> - chip_id = (enum chips)(unsigned long)of_device_get_match_data(dev);
> - else
> - chip_id = i2c_match_id(q54sj108a2_id, client)->driver_data;
> -
> ret = i2c_smbus_read_block_data(client, PMBUS_MFR_ID, buf);
> if (ret < 0) {
> - dev_err(&client->dev, "Failed to read Manufacturer ID\n");
> + dev_err(dev, "Failed to read Manufacturer ID\n");
> return ret;
> }
> if (ret != 6 || strncmp(buf, "DELTA", 5)) {
> @@ -308,19 +336,25 @@ static int q54sj108a2_probe(struct i2c_client *client)
> return -ENODEV;
> }
>
> - /*
> - * The chips support reading PMBUS_MFR_MODEL.
> - */
> ret = i2c_smbus_read_block_data(client, PMBUS_MFR_MODEL, buf);
> if (ret < 0) {
> dev_err(dev, "Failed to read Manufacturer Model\n");
> return ret;
> }
> - if (ret != 14 || strncmp(buf, "Q54SJ108A2", 10)) {
> + for (mid = q54sj108a2_id; mid->name[0]; mid++) {
> + if (ret == strlen(mid->name) && !strncasecmp(mid->name, buf, ret))
> + break;
> + }
> + if (!mid->name[0]) {
> buf[ret] = '\0';
> dev_err(dev, "Unsupported Manufacturer Model '%s'\n", buf);
> return -ENODEV;
> }
From Sashiko feedback:
In the original driver, the PMBUS_MFR_MODEL response length was explicitly
expected to be 14 bytes (if (ret != 14 || strncmp(buf, "Q54SJ108A2", 10))),
indicating the hardware returns the 10-character name padded with 4 extra
bytes. The patch changes the detection logic to loop through supported
devices and strictly require the returned length to match the device name's
length exactly (`ret == strlen(mid->name)`). Since `ret` will be 14 for the
original hardware, and strlen("q54sj108a2") is 10, the condition 14 == 10
evaluates to false. This causes the loop to exit without matching,
erroneously printing 'Unsupported Manufacturer Model' and returning -ENODEV.
This completely breaks driver probing and hardware monitoring for the
pre-existing Q54SJ108A2 device."
> + chip_id = mid->driver_data;
> +
> + if (strcmp(client->name, mid->name) != 0)
> + dev_notice(dev, "Device mismatch: Configured %s, detected %s\n",
> + client->name, mid->name);
>
> ret = i2c_smbus_read_block_data(client, PMBUS_MFR_REVISION, buf);
> if (ret < 0) {
> @@ -341,6 +375,7 @@ static int q54sj108a2_probe(struct i2c_client *client)
> if (!psu)
> return 0;
>
> + psu->chip = chip_id;
> psu->client = client;
>
> debugfs = pmbus_get_debugfs_dir(client);
> @@ -359,9 +394,6 @@ static int q54sj108a2_probe(struct i2c_client *client)
> debugfs_create_file("write_protect", 0444, q54sj108a2_dir,
> &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_WRITEPROTECT],
> &q54sj108a2_fops);
> - debugfs_create_file("store_default", 0200, q54sj108a2_dir,
> - &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_STOREDEFAULT],
> - &q54sj108a2_fops);
> debugfs_create_file("vo_ov_response", 0644, q54sj108a2_dir,
> &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_VOOV_RESPONSE],
> &q54sj108a2_fops);
> @@ -383,27 +415,34 @@ static int q54sj108a2_probe(struct i2c_client *client)
> debugfs_create_file("mfr_location", 0444, q54sj108a2_dir,
> &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_MFR_LOCATION],
> &q54sj108a2_fops);
> - debugfs_create_file("blackbox_erase", 0200, q54sj108a2_dir,
> - &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_ERASE],
> - &q54sj108a2_fops);
> debugfs_create_file("blackbox_read_offset", 0444, q54sj108a2_dir,
> &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_READ_OFFSET],
> &q54sj108a2_fops);
What is the purpose/value of keeping this file outside the if() block ?
> - debugfs_create_file("blackbox_set_offset", 0200, q54sj108a2_dir,
> - &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_SET_OFFSET],
> - &q54sj108a2_fops);
> - debugfs_create_file("blackbox_read", 0444, q54sj108a2_dir,
> - &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_READ],
> - &q54sj108a2_fops);
> - debugfs_create_file("flash_key", 0444, q54sj108a2_dir,
> - &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_FLASH_KEY],
> - &q54sj108a2_fops);
> + if (psu->chip == q54sj108a2) {
> + debugfs_create_file("store_default", 0200, q54sj108a2_dir,
> + &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_STOREDEFAULT],
> + &q54sj108a2_fops);
> + debugfs_create_file("blackbox_erase", 0200, q54sj108a2_dir,
> + &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_ERASE],
> + &q54sj108a2_fops);
> + debugfs_create_file("blackbox_set_offset", 0200, q54sj108a2_dir,
> + &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_SET_OFFSET],
> + &q54sj108a2_fops);
> + debugfs_create_file("blackbox_read", 0444, q54sj108a2_dir,
> + &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_READ],
> + &q54sj108a2_fops);
> + debugfs_create_file("flash_key", 0444, q54sj108a2_dir,
> + &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_FLASH_KEY],
> + &q54sj108a2_fops);
> + }
>
> return 0;
> }
>
> static const struct of_device_id q54sj108a2_of_match[] = {
> - { .compatible = "delta,q54sj108a2", .data = (void *)q54sj108a2 },
> + { .compatible = "delta,q50sn12072" },
> + { .compatible = "delta,q54sj108a2" },
> + { .compatible = "delta,q54sn120a1" },
Why drop .data here ?
Thanks,
Guenter
> { },
> };
>
> @@ -421,6 +460,6 @@ static struct i2c_driver q54sj108a2_driver = {
> module_i2c_driver(q54sj108a2_driver);
>
> MODULE_AUTHOR("Xiao.Ma <xiao.mx.ma@deltaww.com>");
> -MODULE_DESCRIPTION("PMBus driver for Delta Q54SJ108A2 series modules");
> +MODULE_DESCRIPTION("PMBus driver for Delta Q54SJ108A2 and compatibles");
> MODULE_LICENSE("GPL");
> MODULE_IMPORT_NS("PMBUS");
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v3 8/9] media: i2c: ov08d10: add support for reset and power management
From: Matthias Fend @ 2026-03-26 16:25 UTC (permalink / raw)
To: Sakari Ailus, Matthias Fend
Cc: Jimmy Su, Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, linux-media, linux-kernel,
devicetree, bsp-development.geo
In-Reply-To: <acU0Gky-EldJlx0t@kekkonen.localdomain>
Hi Sakari,
Am 26.03.2026 um 14:26 schrieb Sakari Ailus:
> Hi Matthias,
>
> A few more minor comments.
>
> On Tue, Mar 24, 2026 at 11:41:42AM +0100, Matthias Fend wrote:
>> Add support for the required power supplies as well as the control of an
>> optional sensor reset.
>>
>> Signed-off-by: Matthias Fend <matthias.fend@emfend.at>
>> ---
>> drivers/media/i2c/ov08d10.c | 93 ++++++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 92 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/i2c/ov08d10.c b/drivers/media/i2c/ov08d10.c
>> index ce0fa30a86129302b5dda0b8796e44054fd77c88..19035991e8bb164d4fca5d87ee4551191974e8bb 100644
>> --- a/drivers/media/i2c/ov08d10.c
>> +++ b/drivers/media/i2c/ov08d10.c
>> @@ -8,6 +8,7 @@
>> #include <linux/module.h>
>> #include <linux/pm_runtime.h>
>> #include <linux/regulator/consumer.h>
>> +#include <linux/reset.h>
>> #include <media/v4l2-ctrls.h>
>> #include <media/v4l2-device.h>
>> #include <media/v4l2-fwnode.h>
>> @@ -513,9 +514,17 @@ static const char * const ov08d10_test_pattern_menu[] = {
>> "Standard Color Bar",
>> };
>>
>> +static const char *const ov08d10_supply_names[] = {
>> + "dovdd", /* Digital I/O power */
>> + "avdd", /* Analog power */
>> + "dvdd", /* Digital core power */
>> +};
>> +
>> struct ov08d10 {
>> struct device *dev;
>> struct clk *clk;
>> + struct reset_control *reset;
>> + struct regulator_bulk_data supplies[ARRAY_SIZE(ov08d10_supply_names)];
>>
>> struct v4l2_subdev sd;
>> struct media_pad pad;
>> @@ -1265,6 +1274,56 @@ static const struct v4l2_subdev_internal_ops ov08d10_internal_ops = {
>> .open = ov08d10_open,
>> };
>>
>> +static int ov08d10_power_off(struct device *dev)
>> +{
>> + struct v4l2_subdev *sd = dev_get_drvdata(dev);
>> + struct ov08d10 *ov08d10 = to_ov08d10(sd);
>> +
>> + reset_control_assert(ov08d10->reset);
>> +
>> + regulator_bulk_disable(ARRAY_SIZE(ov08d10->supplies),
>> + ov08d10->supplies);
>> +
>> + clk_disable_unprepare(ov08d10->clk);
>> +
>> + return 0;
>> +}
>> +
>> +static int ov08d10_power_on(struct device *dev)
>> +{
>> + struct v4l2_subdev *sd = dev_get_drvdata(dev);
>> + struct ov08d10 *ov08d10 = to_ov08d10(sd);
>> + int ret;
>> +
>> + ret = regulator_bulk_enable(ARRAY_SIZE(ov08d10->supplies),
>> + ov08d10->supplies);
>> + if (ret < 0) {
>> + dev_err(dev, "failed to enable regulators: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + ret = clk_prepare_enable(ov08d10->clk);
>> + if (ret < 0) {
>> + regulator_bulk_disable(ARRAY_SIZE(ov08d10->supplies),
>> + ov08d10->supplies);
>> +
>> + dev_err(dev, "failed to enable imaging clock: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + if (ov08d10->reset) {
>> + /* Delay from DVDD stable to sensor XSHUTDN pull up: 5ms */
>> + fsleep(5 * USEC_PER_MSEC);
>> +
>> + reset_control_deassert(ov08d10->reset);
>> +
>> + /* Delay from XSHUTDN pull up to SCCB start: 8ms */
>> + fsleep(8 * USEC_PER_MSEC);
>
> Don't you need the fsleep()'s (or at least the latter one) even if you have
> no reset GPIO?
Good point. I couldn't find any explicit information in the datasheet
about operating without a hardware reset.
While I didn't encounter any problems during my tests without a reset,
that's probably just coincidence, and I think it's a good idea to wait
for the delay you suggested in any case.
>
>> + }
>> +
>> + return 0;
>> +}
>> +
>> static int ov08d10_identify_module(struct ov08d10 *ov08d10)
>> {
>> struct i2c_client *client = v4l2_get_subdevdata(&ov08d10->sd);
>> @@ -1371,6 +1430,10 @@ static void ov08d10_remove(struct i2c_client *client)
>> media_entity_cleanup(&sd->entity);
>> v4l2_ctrl_handler_free(sd->ctrl_handler);
>> pm_runtime_disable(ov08d10->dev);
>> + if (!pm_runtime_status_suspended(ov08d10->dev)) {
>> + ov08d10_power_off(ov08d10->dev);
>> + pm_runtime_set_suspended(ov08d10->dev);
>> + }
>> mutex_destroy(&ov08d10->mutex);
>> }
>>
>> @@ -1378,6 +1441,7 @@ static int ov08d10_probe(struct i2c_client *client)
>> {
>> struct ov08d10 *ov08d10;
>> unsigned long freq;
>> + unsigned int i;
>> int ret;
>>
>> ov08d10 = devm_kzalloc(&client->dev, sizeof(*ov08d10), GFP_KERNEL);
>> @@ -1403,12 +1467,32 @@ static int ov08d10_probe(struct i2c_client *client)
>> return ret;
>> }
>>
>> + ov08d10->reset = devm_reset_control_get_optional_exclusive(ov08d10->dev, NULL);
>
> This is a bit long.
>
> I'll take the set now but please post a fix on top.
I just posted a fixup. I hope it was as you intended.
Thanks
~Matthias
>
>> + if (IS_ERR(ov08d10->reset))
>> + return dev_err_probe(ov08d10->dev, PTR_ERR(ov08d10->reset),
>> + "failed to get reset\n");
>> + reset_control_assert(ov08d10->reset);
>> +
>> + for (i = 0; i < ARRAY_SIZE(ov08d10_supply_names); i++)
>> + ov08d10->supplies[i].supply = ov08d10_supply_names[i];
>> +
>> + ret = devm_regulator_bulk_get(ov08d10->dev,
>> + ARRAY_SIZE(ov08d10->supplies),
>> + ov08d10->supplies);
>> + if (ret)
>> + return dev_err_probe(ov08d10->dev, ret,
>> + "failed to get regulators\n");
>> +
>> v4l2_i2c_subdev_init(&ov08d10->sd, client, &ov08d10_subdev_ops);
>>
>> + ret = ov08d10_power_on(ov08d10->dev);
>> + if (ret)
>> + return dev_err_probe(ov08d10->dev, ret, "failed to power on\n");
>> +
>> ret = ov08d10_identify_module(ov08d10);
>> if (ret) {
>> dev_err(ov08d10->dev, "failed to find sensor: %d\n", ret);
>> - return ret;
>> + goto probe_error_power_off;
>> }
>>
>> mutex_init(&ov08d10->mutex);
>> @@ -1452,9 +1536,15 @@ static int ov08d10_probe(struct i2c_client *client)
>> v4l2_ctrl_handler_free(ov08d10->sd.ctrl_handler);
>> mutex_destroy(&ov08d10->mutex);
>>
>> +probe_error_power_off:
>> + ov08d10_power_off(ov08d10->dev);
>> +
>> return ret;
>> }
>>
>> +static DEFINE_RUNTIME_DEV_PM_OPS(ov08d10_pm_ops,
>> + ov08d10_power_off, ov08d10_power_on, NULL);
>> +
>> #ifdef CONFIG_ACPI
>> static const struct acpi_device_id ov08d10_acpi_ids[] = {
>> { "OVTI08D1" },
>> @@ -1473,6 +1563,7 @@ MODULE_DEVICE_TABLE(of, ov08d10_of_match);
>> static struct i2c_driver ov08d10_i2c_driver = {
>> .driver = {
>> .name = "ov08d10",
>> + .pm = pm_ptr(&ov08d10_pm_ops),
>> .acpi_match_table = ACPI_PTR(ov08d10_acpi_ids),
>> .of_match_table = ov08d10_of_match,
>> },
>>
>
^ permalink raw reply
* Re: [PATCH v2] regulator: dt-bindings: mps,mp8859: convert to DT schema
From: Mark Brown @ 2026-03-26 11:55 UTC (permalink / raw)
To: devicetree, robh, krzk+dt, conor+dt, reichl, sravanhome,
lgirdwood, Bhargav Joshi
Cc: daniel.baluta, simona.toaca, d-gole, m-chawdhry, linux-kernel
In-Reply-To: <20260325230559.73527-1-rougueprince47@gmail.com>
On Thu, 26 Mar 2026 04:35:59 +0530, Bhargav Joshi wrote:
> regulator: dt-bindings: mps,mp8859: convert to DT schema
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-7.1
Thanks!
[1/1] regulator: dt-bindings: mps,mp8859: convert to DT schema
https://git.kernel.org/broonie/regulator/c/32a4cd3d451d
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v11 2/3] of: Factor arguments passed to of_map_id() into a struct
From: Bjorn Helgaas @ 2026-03-26 16:19 UTC (permalink / raw)
To: Vijayanand Jitta, Richard Zhu, Lucas Stach
Cc: Nipun Gupta, Nikhil Agarwal, Joerg Roedel, Will Deacon,
Robin Murphy, Marc Zyngier, Lorenzo Pieralisi, Thomas Gleixner,
Saravana Kannan, Krzysztof Wilczyński, Manivannan Sadhasivam,
Bjorn Helgaas, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Juergen Gross, Stefano Stabellini,
Oleksandr Tyshchenko, Dmitry Baryshkov, Konrad Dybcio,
Bjorn Andersson, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Prakash Gupta, Vikash Garodia, linux-kernel, iommu,
linux-arm-kernel, devicetree, linux-pci, imx, xen-devel,
linux-arm-msm, Charan Teja Kalla
In-Reply-To: <20260325-parse_iommu_cells-v11-2-1fefa5c0e82c@oss.qualcomm.com>
[cc->to: Richard, Lucas for pci-imx6.c question]
On Wed, Mar 25, 2026 at 04:38:23PM +0530, Vijayanand Jitta wrote:
> From: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
>
> Change of_map_id() to take a pointer to struct of_phandle_args
> instead of passing target device node and translated IDs separately.
> Update all callers accordingly.
>
> Add an explicit filter_np parameter to of_map_id() and of_map_msi_id()
> to separate the filter input from the output. Previously, the target
> parameter served dual purpose: as an input filter (if non-NULL, only
> match entries targeting that node) and as an output (receiving the
> matched node with a reference held). Now filter_np is the explicit
> input filter and arg->np is the pure output.
>
> Previously, of_map_id() would call of_node_put() on the matched node
> when a filter was provided, making reference ownership inconsistent.
> Remove this internal of_node_put() call so that of_map_id() now always
> transfers ownership of the matched node reference to the caller via
> arg->np. Callers are now consistently responsible for releasing this
> reference with of_node_put(arg->np) when done.
> ...
Not actually part of *this* patch, and AFAICS this patch is correct
as-is, but is it necessary to have different logic around
of_node_put() for imx_pcie_add_lut_by_rid() and
apple_pcie_enable_device()?
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -1137,6 +1137,8 @@ static void imx_pcie_remove_lut(struct imx_pcie *imx_pcie, u16 rid)
>
> static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid)
> {
> + struct of_phandle_args iommu_spec = {};
> + struct of_phandle_args msi_spec = {};
> struct device *dev = imx_pcie->pci->dev;
> struct device_node *target;
> u32 sid_i, sid_m;
> @@ -1144,7 +1146,12 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid)
> u32 sid = 0;
>
> target = NULL;
> - err_i = of_map_iommu_id(dev->of_node, rid, &target, &sid_i);
> + err_i = of_map_iommu_id(dev->of_node, rid, &iommu_spec);
> + if (!err_i) {
> + target = iommu_spec.np;
> + sid_i = iommu_spec.args[0];
> + }
> +
> if (target) {
> of_node_put(target);
Here it's conditional on "target" even though of_node_put() checks
internally for non-NULL, so it would be safe without the conditional
here.
> } else {
> @@ -1156,8 +1163,11 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid)
> err_i = -EINVAL;
> }
>
> - target = NULL;
> - err_m = of_map_msi_id(dev->of_node, rid, &target, &sid_m);
> + err_m = of_map_msi_id(dev->of_node, rid, NULL, &msi_spec);
> + if (!err_m) {
> + target = msi_spec.np;
> + sid_m = msi_spec.args[0];
> + }
>
> /*
> * err_m target
And here (outside the diff context) we also call of_node_put()
conditionally:
...
else if (target)
of_node_put(target);
> diff --git a/drivers/pci/controller/pcie-apple.c b/drivers/pci/controller/pcie-apple.c
> index a0937b7b3c4d..c2cffc0659f4 100644
> --- a/drivers/pci/controller/pcie-apple.c
> +++ b/drivers/pci/controller/pcie-apple.c
> @@ -755,6 +755,7 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d
> {
> u32 sid, rid = pci_dev_id(pdev);
> struct apple_pcie_port *port;
> + struct of_phandle_args iommu_spec = {};
> int idx, err;
>
> port = apple_pcie_get_port(pdev);
> @@ -764,10 +765,12 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d
> dev_dbg(&pdev->dev, "added to bus %s, index %d\n",
> pci_name(pdev->bus->self), port->idx);
>
> - err = of_map_iommu_id(port->pcie->dev->of_node, rid, NULL, &sid);
> + err = of_map_iommu_id(port->pcie->dev->of_node, rid, &iommu_spec);
> if (err)
> return err;
>
> + of_node_put(iommu_spec.np);
Here we call of_node_put() unconditionally.
I think it would be much nicer if imx_pcie_add_lut_by_rid() used the
same style as apple_pcie_enable_device() and did the of_node_put()
unconditionally. That would untangle the function a bit and make it
easier to analyze.
> + sid = iommu_spec.args[0];
> mutex_lock(&port->pcie->lock);
>
> idx = bitmap_find_free_region(port->sid_map, port->sid_map_sz, 0);
^ permalink raw reply
* Re: [PATCH] dt-bindings: mailbox: qcom-ipcc: Document the Eliza Inter-Processor Communication Controller
From: Manivannan Sadhasivam @ 2026-03-26 16:18 UTC (permalink / raw)
To: Abel Vesa
Cc: Jassi Brar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260318-eliza-bindings-ipcc-v1-1-8f066c33ce7e@oss.qualcomm.com>
On Wed, Mar 18, 2026 at 10:26:49AM +0200, Abel Vesa wrote:
> Document the compatible for Qualcomm Eliza SoC Inter-Processor
> Communication Controller (IPCC).
>
> It is fully compatible with the ones found on the other Qualcomm SoCs,
> so add it alongside them in order to have the generic compatible as
> fallback.
>
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
- Mani
> ---
> Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
> index 7c4d6170491d..f5c584cf2146 100644
> --- a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
> +++ b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
> @@ -24,6 +24,7 @@ properties:
> compatible:
> items:
> - enum:
> + - qcom,eliza-ipcc
> - qcom,glymur-ipcc
> - qcom,kaanapali-ipcc
> - qcom,milos-ipcc
>
> ---
> base-commit: 8e5a478b6d6a5bb0a3d52147862b15e4d826af19
> change-id: 20260318-eliza-bindings-ipcc-c636f38f88e1
>
> Best regards,
> --
> Abel Vesa <abel.vesa@oss.qualcomm.com>
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v2 2/2] pinctrl: renesas: rzt2h: Add pin configuration support
From: Geert Uytterhoeven @ 2026-03-26 16:12 UTC (permalink / raw)
To: Prabhakar
Cc: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Magnus Damm, linux-renesas-soc, linux-gpio, devicetree,
linux-kernel, Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260319141515.2053556-3-prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi Prabhakar,
On Thu, 19 Mar 2026 at 15:15, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Add pin configuration support for the Renesas RZ/T2H SoC. The RZ/T2H SoC
> allows configuring several electrical characteristics through the DRCTLm
> (I/O Buffer Function Switching) registers. These registers control bias
> configuration, Schmitt trigger input, output slew rate, and drive
> strength.
>
> Implement pinconf_ops to allow reading and updating these properties
> through the generic pin configuration framework. The implementation
> supports bias-disable, bias-pull-up, bias-pull-down,
> input-schmitt-enable, slew-rate, and drive-strength-microamp.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> ---
> v1->v2:
> - Updated commit description
> - Dropped 32 bit reg access for DRCTLm registers
> - Switched using to guard for locking in rzt2h_pinctrl_drctl_rmwq
> helper function
> - Dropped using RENESAS_RZT2H_PIN_CONFIG_DRIVE_STRENGTH instead
> switched to using the standard PIN_CONFIG_DRIVE_STRENGTH_UA
Thanks for the update!
> --- a/drivers/pinctrl/renesas/pinctrl-rzt2h.c
> +++ b/drivers/pinctrl/renesas/pinctrl-rzt2h.c
> @@ -54,6 +56,16 @@
> #define PFC_PIN_MASK(pin) (PFC_MASK << ((pin) * 8))
> #define PFC_FUNC_INTERRUPT 0
>
> +#define DRCTL_PIN_SHIFT(pin) ((pin) << 3)
"* 8" sounds more logical to me.
> +#define DRCTL_DRV_PIN_MASK(pin) (GENMASK_ULL(1, 0) << DRCTL_PIN_SHIFT(pin))
> +#define DRCTL_PUD_PIN_MASK(pin) (GENMASK_ULL(3, 2) << DRCTL_PIN_SHIFT(pin))
> +#define DRCTL_SMT_PIN_MASK(pin) (BIT_ULL(4) << DRCTL_PIN_SHIFT(pin))
> +#define DRCTL_SR_PIN_MASK(pin) (BIT_ULL(5) << DRCTL_PIN_SHIFT(pin))
I will drop DRCTL_PIN_SHIFT(), and replace it by "((pin) * 8)" while
applying, for consistency with e.g. PFC_PIN_MASK() above.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-pinctrl for v7.1.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: pinctrl: renesas,r9a09g077: Document pin configuration properties
From: Geert Uytterhoeven @ 2026-03-26 16:01 UTC (permalink / raw)
To: Prabhakar
Cc: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Magnus Damm, linux-renesas-soc, linux-gpio, devicetree,
linux-kernel, Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260319141515.2053556-2-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Thu, 19 Mar 2026 at 15:15, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Document the pin configuration properties supported by the RZ/T2H
> pinctrl driver.
>
> The RZ/T2H SoC allows configuring several electrical characteristics
> through the DRCTLm (I/O Buffer Function Switching) registers. These
> registers control drive strength, bias configuration, Schmitt trigger
> input, and output slew rate.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> ---
> v1->v2:
> - Updated commit description
> - Switched to using the standard drive-strength-microamp property
> name instead of a custom one
> - Added a description for slew-rate property
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-pinctrl for v7.1.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sm8750-mtp: Set sufficient voltage for panel nt37801
From: Bjorn Andersson @ 2026-03-26 15:58 UTC (permalink / raw)
To: Ayushi Makhija
Cc: konrad.dybcio, robh+dt, krzysztof.kozlowski+dt, conor+dt,
dmitry.baryshkov, linux-arm-msm, devicetree, linux-kernel,
linux-arm-kernel, quic_rajeevny, quic_vproddut
In-Reply-To: <ccb11c2a-4cf1-4486-be71-d4bcc983cee6@quicinc.com>
On Thu, Mar 26, 2026 at 03:06:52PM +0530, Ayushi Makhija wrote:
> On 3/24/2026 7:34 AM, Bjorn Andersson wrote:
> > On Mon, Mar 23, 2026 at 03:52:29PM +0530, Ayushi Makhija wrote:
> >> The NT37801 Sepc V1.0 chapter "5.7.1 Power On Sequence" states
> >> VDDI=1.65V~1.95V, so set sufficient voltage for panel nt37801.
> >>
> >
> > Please add Fixes: tag.
> >
>
> Hi Bjorn,
>
> Sure, will add in new patchset.
>
> >> Signed-off-by: Ayushi Makhija <quic_amakhija@quicinc.com>
> >
> > Please start using your oss.qualcomm.com address.
> >
> >> ---
> >> arch/arm64/boot/dts/qcom/sm8750-mtp.dts | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm64/boot/dts/qcom/sm8750-mtp.dts b/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
> >> index 3837f6785320..6ba4e69bf377 100644
> >> --- a/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
> >> +++ b/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
> >> @@ -462,7 +462,7 @@ vreg_l11b_1p0: ldo11 {
> >>
> >> vreg_l12b_1p8: ldo12 {
> >> regulator-name = "vreg_l12b_1p8";
> >> - regulator-min-microvolt = <1200000>;
> >> + regulator-min-microvolt = <1650000>;
> >
> > Are you sure it's not supposed to be 1.8V, given the name of the rail?
> >
> > Regards,
> > Bjorn
>
> There was already discussion regarding the minimum voltage for this regulator on sm8550 target
> on other upstream patch.
>
> Link: https://lore.kernel.org/all/aQQdQoCLeKhYtY7W@yuanjiey.ap.qualcomm.com/
>
> This values is according to the NT37801 panel sec
> "The NT37801 Sepc V1.0 chapter "5.7.1 Power On Sequence" states
> VDDI=1.65V~1.95V."
>
Yes, so the panel requires 1.65V, so regulator-min-microvolt needs to be
at least that. But regulator-min-microvolt should account for all the
consumers of the rail, are there any others?
Which leads me to my question, the people designing the board named the
rail VREG_L12B_1P8 in the schematics, why didn't they name it
VREG_L12B_1P65?
Please check all the consumers and make the regulator-min-microvolt work
for all of them - if that's 1.65V, then your change is good.
Regards,
Bjorn
> Thanks,
> Ayushi
>
> >> regulator-max-microvolt = <1800000>;
> >> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> >> regulator-allow-set-load;
> >> --
> >> 2.34.1
> >>
>
^ permalink raw reply
* Re: (subset) [PATCH v10 0/5] Add MIPI CSI-2 support for i.MX8ULP
From: Frank Li @ 2026-03-26 15:57 UTC (permalink / raw)
To: Rui Miguel Silva, Laurent Pinchart, Martin Kepplinger,
Purism Kernel Team, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Philipp Zabel,
Guoniu Zhou
Cc: linux-media, devicetree, imx, linux-arm-kernel, linux-kernel,
Conor Dooley
In-Reply-To: <177453839102.4969.6512848643800500076.b4-ty@nxp.com>
On Thu, Mar 26, 2026 at 11:20:54AM -0400, Frank Li wrote:
>
> On Fri, 05 Dec 2025 17:07:42 +0800, Guoniu Zhou wrote:
> > The serial adds MIPI CSI-2 support for i.MX8ULP.
> >
> >
>
> Applied, thanks!
>
> [5/5] arm64: dts: imx8ulp: Add CSI and ISI Nodes
> commit: 73f3ca0f85285b2fc4ea05affb9a44bf899cd595
>
> Add extra empty line between reg and child node.
Guoniu Zhou:
I have to drop this one because miss <dt-bindings/reset/imx8ulp-pcc-reset.h>
Do you miss some dependence?
Frank
>
> Best regards,
> --
> Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* [PATCH v1 3/3] arm64: dts: imx93-var-dart: Add support for Variscite Sonata board
From: Stefano Radaelli @ 2026-03-26 15:47 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Dario Binacchi, Alexander Stein,
Maud Spierings, Josua Mayer, Markus Niebel, Francesco Dolcini,
Primoz Fiser
In-Reply-To: <cover.1774539301.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add device tree support for the Variscite Sonata carrier board with the
DART-MX93 system on module.
The Sonata board includes
- uSD Card support
- USB ports and OTG
- Additional Gigabit Ethernet interface
- Uart, SPI and I2C interfaces
- GPIO Expanders
- RTC module
- TPM module
- CAN peripherals
Link: https://variscite.com/carrier-boards/sonata-board/
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../dts/freescale/imx93-var-dart-sonata.dts | 654 ++++++++++++++++++
2 files changed, 655 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 2da6dc4f8a14..266eddd745c9 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -487,6 +487,7 @@ imx93-tqma9352-mba91xxca-rgb-cdtech-dc44-dtbs := imx93-tqma9352-mba91xxca.dtb im
dtb-$(CONFIG_ARCH_MXC) += imx93-tqma9352-mba91xxca-lvds-tm070jvhg33.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-tqma9352-mba91xxca-rgb-cdtech-dc44.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx93-var-dart-sonata.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-var-som-symphony.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93w-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx943-evk.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts b/arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts
new file mode 100644
index 000000000000..5513d3b148a2
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts
@@ -0,0 +1,654 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Variscite Sonata carrier board for DART-MX93
+ *
+ * Link: https://variscite.com/carrier-boards/sonata-board/
+ *
+ * Copyright (C) 2026 Variscite Ltd. - https://www.variscite.com/
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/leds/common.h>
+#include "imx93-var-dart.dtsi"
+
+/ {
+ model = "Variscite DART-MX93 on Sonata-Board";
+ compatible = "variscite,var-dart-mx93-sonata",
+ "variscite,var-dart-mx93",
+ "fsl,imx93";
+
+ aliases {
+ ethernet0 = &eqos;
+ ethernet1 = &fec;
+ gpio0 = &gpio1;
+ gpio1 = &gpio2;
+ gpio2 = &gpio3;
+ i2c0 = &lpi2c1;
+ i2c1 = &lpi2c2;
+ i2c2 = &lpi2c3;
+ i2c3 = &lpi2c4;
+ i2c4 = &lpi2c5;
+ mmc0 = &usdhc1;
+ mmc1 = &usdhc2;
+ serial0 = &lpuart1;
+ serial1 = &lpuart2;
+ serial2 = &lpuart3;
+ serial3 = &lpuart4;
+ serial4 = &lpuart5;
+ serial5 = &lpuart6;
+ serial6 = &lpuart7;
+ };
+
+ chosen {
+ stdout-path = &lpuart1;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ button-home {
+ label = "Home";
+ linux,code = <KEY_HOME>;
+ gpios = <&pca6408_1 4 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+
+ button-up {
+ label = "Up";
+ linux,code = <KEY_UP>;
+ gpios = <&pca6408_1 5 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+
+ button-down {
+ label = "Down";
+ linux,code = <KEY_DOWN>;
+ gpios = <&pca6408_1 6 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+
+ button-back {
+ label = "Back";
+ linux,code = <KEY_BACK>;
+ gpios = <&pca6408_1 7 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_leds_gpio>;
+
+ led-emmc {
+ gpios = <&gpio2 11 GPIO_ACTIVE_HIGH>;
+ label = "eMMC";
+ linux,default-trigger = "mmc0";
+ };
+ };
+
+ clk40m: oscillator {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <40000000>;
+ clock-output-names = "can_osc";
+ };
+
+ reg_vref_1v8: regulator-adc-vref {
+ compatible = "regulator-fixed";
+ regulator-name = "vref_1v8";
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1800000>;
+ };
+
+ reg_usdhc2_vmmc: regulator-vmmc-usdhc2 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_SD2_3V3";
+ off-on-delay-us = <20000>;
+ pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
+ pinctrl-names = "default";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ gpio = <&gpio2 18 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ ethosu_mem: ethosu-region@88000000 {
+ compatible = "shared-dma-pool";
+ reusable;
+ reg = <0x0 0x88000000 0x0 0x8000000>;
+ };
+
+ vdev0vring0: vdev0vring0@87ee0000 {
+ reg = <0 0x87ee0000 0 0x8000>;
+ no-map;
+ };
+
+ vdev0vring1: vdev0vring1@87ee8000 {
+ reg = <0 0x87ee8000 0 0x8000>;
+ no-map;
+ };
+
+ vdev1vring0: vdev1vring0@87ef0000 {
+ reg = <0 0x87ef0000 0 0x8000>;
+ no-map;
+ };
+
+ vdev1vring1: vdev1vring1@87ef8000 {
+ reg = <0 0x87ef8000 0 0x8000>;
+ no-map;
+ };
+
+ rsc_table: rsc-table@2021e000 {
+ reg = <0 0x2021e000 0 0x1000>;
+ no-map;
+ };
+
+ vdevbuffer: vdevbuffer@87f00000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x87f00000 0 0x100000>;
+ no-map;
+ };
+
+ ele_reserved: ele-reserved@87de0000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x87de0000 0 0x100000>;
+ no-map;
+ };
+ };
+};
+
+&adc1 {
+ vref-supply = <®_vref_1v8>;
+ status = "okay";
+};
+
+/* Use external instead of internal RTC */
+&bbnsm_rtc {
+ status = "disabled";
+};
+
+&eqos {
+ mdio {
+ ethphy1: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ reset-assert-us = <15000>;
+ reset-deassert-us = <100000>;
+ reset-gpios = <&pca6408_2 0 GPIO_ACTIVE_LOW>;
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_YELLOW>;
+ function = LED_FUNCTION_LAN;
+ linux,default-trigger = "netdev";
+ };
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ linux,default-trigger = "netdev";
+ };
+ };
+ };
+ };
+};
+
+ðphy0 {
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_YELLOW>;
+ function = LED_FUNCTION_LAN;
+ linux,default-trigger = "netdev";
+ };
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ linux,default-trigger = "netdev";
+ };
+ };
+};
+
+&fec {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&pinctrl_fec>;
+ pinctrl-1 = <&pinctrl_fec_sleep>;
+ /*
+ * The required RGMII TX and RX 2ns delays are implemented directly
+ * in hardware via passive delay elements on the SOM PCB.
+ * No delay configuration is needed in software via PHY driver.
+ */
+ phy-mode = "rgmii";
+ phy-handle = <ðphy1>;
+ status = "okay";
+};
+
+&flexcan1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan1>;
+ status = "okay";
+};
+
+&lpi2c1 {
+ clock-frequency = <400000>;
+ pinctrl-0 = <&pinctrl_lpi2c1>;
+ pinctrl-1 = <&pinctrl_lpi2c1_gpio>;
+ pinctrl-2 = <&pinctrl_lpi2c1_gpio>;
+ pinctrl-names = "default", "sleep", "gpio";
+ scl-gpios = <&gpio1 0 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio1 1 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ pca9534: gpio@22 {
+ compatible = "nxp,pca9534";
+ reg = <0x22>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ /* Capacitive touch controller */
+ ft5x06_ts: touchscreen@38 {
+ compatible = "edt,edt-ft5206";
+ reg = <0x38>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-0 = <&pinctrl_captouch>;
+ pinctrl-names = "default";
+ reset-gpios = <&pca6408_2 4 GPIO_ACTIVE_LOW>;
+ touchscreen-inverted-x;
+ touchscreen-inverted-y;
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ wakeup-source;
+ };
+
+ /* USB Type-C Controller */
+ typec@3d {
+ compatible = "nxp,ptn5150";
+ reg = <0x3d>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <29 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-0 = <&pinctrl_extcon>;
+ pinctrl-names = "default";
+
+ port {
+ typec1_dr_sw: endpoint {
+ remote-endpoint = <&usb1_drd_sw>;
+ };
+ };
+ };
+
+ rtc@68 {
+ compatible = "dallas,ds1337";
+ reg = <0x68>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rtc>;
+ wakeup-source;
+ };
+};
+
+&lpi2c5 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default", "sleep", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c5>;
+ pinctrl-1 = <&pinctrl_lpi2c5_gpio>;
+ pinctrl-2 = <&pinctrl_lpi2c5_gpio>;
+ scl-gpios = <&gpio2 23 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 22 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+};
+
+&lpi2c7 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default", "sleep", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c7>;
+ pinctrl-1 = <&pinctrl_lpi2c7_gpio>;
+ pinctrl-2 = <&pinctrl_lpi2c7_gpio>;
+ scl-gpios = <&gpio2 7 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 6 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ pca6408_1: gpio@20 {
+ compatible = "nxp,pcal6408";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ pca6408_2: gpio@21 {
+ compatible = "nxp,pcal6408";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ st33ktpm2xi2c: tpm@2e {
+ compatible = "st,st33ktpm2xi2c", "tcg,tpm-tis-i2c";
+ reg = <0x2e>;
+ };
+};
+
+&lpspi8 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpspi8>;
+ cs-gpios = <&gpio2 1 GPIO_ACTIVE_LOW>;
+ status = "okay";
+
+ /* CAN controller */
+ can0: can@0 {
+ compatible = "microchip,mcp251xfd";
+ reg = <0>;
+ clocks = <&clk40m>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can>;
+ spi-max-frequency = <1000000>;
+ };
+};
+
+/* Console (J10) */
+&lpuart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+/* Header (J12.4, J12.6) */
+&lpuart6 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart6>;
+ status = "okay";
+};
+
+/* Header (J12.11, J12.13) */
+&lpuart7 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart7>;
+ status = "okay";
+};
+
+&tpm3 {
+ pinctrl-0 = <&pinctrl_tpm3>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&usbotg1 {
+ dr_mode = "otg";
+ hnp-disable;
+ srp-disable;
+ adp-disable;
+ usb-role-switch;
+ disable-over-current;
+ samsung,picophy-pre-emp-curr-control = <3>;
+ samsung,picophy-dc-vol-level-adjust = <7>;
+ status = "okay";
+
+ port {
+ usb1_drd_sw: endpoint {
+ remote-endpoint = <&typec1_dr_sw>;
+ };
+ };
+};
+
+&usbotg2 {
+ disable-over-current;
+ dr_mode = "host";
+ status = "okay";
+};
+
+/* SD */
+&usdhc2 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+ cd-gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
+ vmmc-supply = <®_usdhc2_vmmc>;
+ bus-width = <4>;
+ no-sdio;
+ no-mmc;
+ status = "okay";
+};
+
+&wdog3 {
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hog>;
+
+ pinctrl_can: cangrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO03__GPIO2_IO03 0x31e
+ >;
+ };
+
+ pinctrl_captouch: captouchgrp {
+ fsl,pins = <
+ MX93_PAD_CCM_CLKO2__GPIO3_IO27 0x31e
+ >;
+ };
+
+ pinctrl_extcon: extcongrp {
+ fsl,pins = <
+ MX93_PAD_CCM_CLKO4__GPIO4_IO29 0x31e
+ >;
+ };
+
+ pinctrl_fec: fecgrp {
+ fsl,pins = <
+ MX93_PAD_ENET2_RD0__ENET1_RGMII_RD0 0x57e
+ MX93_PAD_ENET2_RD1__ENET1_RGMII_RD1 0x57e
+ MX93_PAD_ENET2_RD2__ENET1_RGMII_RD2 0x57e
+ MX93_PAD_ENET2_RD3__ENET1_RGMII_RD3 0x37e
+ MX93_PAD_ENET2_RXC__ENET1_RGMII_RXC 0x58e
+ MX93_PAD_ENET2_RX_CTL__ENET1_RGMII_RX_CTL 0x57e
+ MX93_PAD_ENET2_TD0__ENET1_RGMII_TD0 0x57e
+ MX93_PAD_ENET2_TD1__ENET1_RGMII_TD1 0x57e
+ MX93_PAD_ENET2_TD2__ENET1_RGMII_TD2 0x57e
+ MX93_PAD_ENET2_TD3__ENET1_RGMII_TD3 0x57e
+ MX93_PAD_ENET2_TXC__ENET1_RGMII_TXC 0x58e
+ MX93_PAD_ENET2_TX_CTL__ENET1_RGMII_TX_CTL 0x57e
+ >;
+ };
+
+ pinctrl_fec_sleep: fecsleepgrp {
+ fsl,pins = <
+ MX93_PAD_ENET2_RD0__GPIO4_IO24 0x51e
+ MX93_PAD_ENET2_RD1__GPIO4_IO25 0x51e
+ MX93_PAD_ENET2_RD2__GPIO4_IO26 0x51e
+ MX93_PAD_ENET2_RD3__GPIO4_IO27 0x51e
+ MX93_PAD_ENET2_RXC__GPIO4_IO23 0x51e
+ MX93_PAD_ENET2_RX_CTL__GPIO4_IO22 0x51e
+ MX93_PAD_ENET2_TD0__GPIO4_IO19 0x51e
+ MX93_PAD_ENET2_TD1__GPIO4_IO18 0x51e
+ MX93_PAD_ENET2_TD2__GPIO4_IO17 0x51e
+ MX93_PAD_ENET2_TD3__GPIO4_IO16 0x51e
+ MX93_PAD_ENET2_TXC__GPIO4_IO21 0x51e
+ MX93_PAD_ENET2_TX_CTL__GPIO4_IO20 0x51e
+ >;
+ };
+
+ pinctrl_flexcan1: flexcan1grp {
+ fsl,pins = <
+ MX93_PAD_PDM_CLK__CAN1_TX 0x139e
+ MX93_PAD_PDM_BIT_STREAM0__CAN1_RX 0x139e
+ >;
+ };
+
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ /* GPIO Expanders shared IRQ */
+ MX93_PAD_PDM_BIT_STREAM1__GPIO1_IO10 0x31e
+ >;
+ };
+
+ pinctrl_leds_gpio: ledgrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO11__GPIO2_IO11 0x31e
+ >;
+ };
+
+ pinctrl_lpi2c1: lpi2c1grp {
+ fsl,pins = <
+ MX93_PAD_I2C1_SCL__LPI2C1_SCL 0x40000b9e
+ MX93_PAD_I2C1_SDA__LPI2C1_SDA 0x40000b9e
+ >;
+ };
+
+ pinctrl_lpi2c1_gpio: lpi2c1-gpiogrp {
+ fsl,pins = <
+ MX93_PAD_I2C1_SCL__GPIO1_IO00 0x31e
+ MX93_PAD_I2C1_SDA__GPIO1_IO01 0x31e
+ >;
+ };
+
+ pinctrl_lpi2c5: lpi2c5grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO22__LPI2C5_SDA 0x40000b9e
+ MX93_PAD_GPIO_IO23__LPI2C5_SCL 0x40000b9e
+ >;
+ };
+
+ pinctrl_lpi2c5_gpio: lpi2c5-gpiogrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO22__GPIO2_IO22 0x31e
+ MX93_PAD_GPIO_IO23__GPIO2_IO23 0x31e
+ >;
+ };
+
+ pinctrl_lpi2c7: lpi2c7grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO07__LPI2C7_SCL 0x40000b9e
+ MX93_PAD_GPIO_IO06__LPI2C7_SDA 0x40000b9e
+ >;
+ };
+
+ pinctrl_lpi2c7_gpio: lpi2c7-gpiogrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO07__GPIO2_IO07 0x31e
+ MX93_PAD_GPIO_IO06__GPIO2_IO06 0x31e
+ >;
+ };
+
+ pinctrl_lpspi8: lpspi8grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO00__GPIO2_IO00 0x31e
+ MX93_PAD_GPIO_IO01__GPIO2_IO01 0x31e
+ MX93_PAD_GPIO_IO12__GPIO2_IO12 0x31e
+ MX93_PAD_GPIO_IO13__LPSPI8_SIN 0x31e
+ MX93_PAD_GPIO_IO14__LPSPI8_SOUT 0x31e
+ MX93_PAD_GPIO_IO15__LPSPI8_SCK 0x31e
+ >;
+ };
+
+ pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
+ fsl,pins = <
+ MX93_PAD_CCM_CLKO3__GPIO4_IO28 0x31e
+ >;
+ };
+
+ pinctrl_rtc: rtcgrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO02__GPIO2_IO02 0x31e
+ >;
+ };
+
+ pinctrl_tpm3: tpm3grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO24__TPM3_CH3 0x51e
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX93_PAD_UART1_RXD__LPUART1_RX 0x31e
+ MX93_PAD_UART1_TXD__LPUART1_TX 0x31e
+ >;
+ };
+
+ pinctrl_uart6: uart6grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO05__LPUART6_RX 0x31e
+ MX93_PAD_GPIO_IO04__LPUART6_TX 0x31e
+ >;
+ };
+
+ pinctrl_uart7: uart7grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO09__LPUART7_RX 0x31e
+ MX93_PAD_GPIO_IO08__LPUART7_TX 0x31e
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX93_PAD_SD2_CLK__USDHC2_CLK 0x1582
+ MX93_PAD_SD2_CMD__USDHC2_CMD 0x40001382
+ MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x40001382
+ MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x40001382
+ MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x40001382
+ MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x40001382
+ MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
+ >;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+ fsl,pins = <
+ MX93_PAD_SD2_CLK__USDHC2_CLK 0x158e
+ MX93_PAD_SD2_CMD__USDHC2_CMD 0x4000138e
+ MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x4000138e
+ MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x4000138e
+ MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x4000138e
+ MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x4000138e
+ MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
+ >;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+ fsl,pins = <
+ MX93_PAD_SD2_CLK__USDHC2_CLK 0x15fe
+ MX93_PAD_SD2_CMD__USDHC2_CMD 0x400013fe
+ MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x400013fe
+ MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x400013fe
+ MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x400013fe
+ MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x400013fe
+ MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
+ >;
+ };
+
+ pinctrl_usdhc2_gpio: usdhc2gpiogrp {
+ fsl,pins = <
+ MX93_PAD_SD2_CD_B__GPIO3_IO00 0x31e
+ >;
+ };
+};
--
2.47.3
^ permalink raw reply related
* [PATCH v1 2/3] arm64: dts: freescale: Add support for Variscite DART-MX93
From: Stefano Radaelli @ 2026-03-26 15:47 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Dario Binacchi, Alexander Stein,
Maud Spierings, Josua Mayer, Markus Niebel, Francesco Dolcini,
Primoz Fiser
In-Reply-To: <cover.1774539301.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add device tree support for the Variscite DART-MX93 system on module.
This SOM is designed to be used with various carrier boards.
The module includes:
- NXP i.MX93 MPU processor
- Up to 2GB of LPDDR4 memory
- Up to 128GB of eMMC storage memory
- Integrated 10/100/1000 Mbps Ethernet Transceiver
- Codec audio WM8904
- WIFI6 dual-band 802.11ax/ac/a/b/g/n with optional 802.15.4 and Bluetooth
Only SOM-specific peripherals are enabled by default. Carrier board
specific interfaces are left disabled to be enabled in the respective
carrier board device trees.
Link: https://variscite.com/system-on-module-som/i-mx-9/i-mx-93/dart-mx93/
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
.../boot/dts/freescale/imx93-var-dart.dtsi | 462 ++++++++++++++++++
1 file changed, 462 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-dart.dtsi
diff --git a/arch/arm64/boot/dts/freescale/imx93-var-dart.dtsi b/arch/arm64/boot/dts/freescale/imx93-var-dart.dtsi
new file mode 100644
index 000000000000..bfed6625f5ab
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-var-dart.dtsi
@@ -0,0 +1,462 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Common dtsi for Variscite DART-MX93
+ *
+ * Link: https://variscite.com/system-on-module-som/i-mx-9/i-mx-93/dart-mx93/
+ *
+ * Copyright (C) 2026 Variscite Ltd. - https://www.variscite.com/
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/usb/pd.h>
+#include "imx93.dtsi"
+
+/ {
+ model = "Variscite DART-MX93 Module";
+ compatible = "variscite,var-dart-mx93", "fsl,imx93";
+
+ sound-wm8904 {
+ compatible = "simple-audio-card";
+ simple-audio-card,bitclock-master = <&codec_dai>;
+ simple-audio-card,format = "i2s";
+ simple-audio-card,frame-master = <&codec_dai>;
+ simple-audio-card,mclk-fs = <256>;
+ simple-audio-card,name = "wm8904-audio";
+ simple-audio-card,routing =
+ "Headphone Jack", "HPOUTL",
+ "Headphone Jack", "HPOUTR",
+ "IN2L", "Line In Jack",
+ "IN2R", "Line In Jack",
+ "IN1L", "Microphone Jack",
+ "IN1R", "Microphone Jack";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Headphone", "Headphone Jack",
+ "Line", "Line In Jack";
+
+ codec_dai: simple-audio-card,codec {
+ sound-dai = <&wm8904>;
+ };
+
+ simple-audio-card,cpu {
+ sound-dai = <&sai1>;
+ };
+ };
+
+ wifi_pwrseq: wifi-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ post-power-on-delay-ms = <100>;
+ power-off-delay-us = <10000>;
+ reset-gpios = <&gpio4 14 GPIO_ACTIVE_LOW>, /* WIFI_RESET */
+ <&gpio3 7 GPIO_ACTIVE_LOW>; /* WIFI_PWR_EN */
+ };
+};
+
+&cm33 {
+ mbox-names = "tx", "rx", "rxdb";
+ mboxes = <&mu1 0 1>,
+ <&mu1 1 1>,
+ <&mu1 3 1>;
+ memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
+ <&vdev1vring0>, <&vdev1vring1>, <&rsc_table>;
+ status = "okay";
+};
+
+&eqos {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&pinctrl_eqos>;
+ pinctrl-1 = <&pinctrl_eqos_sleep>;
+ /*
+ * The required RGMII TX and RX 2ns delays are implemented directly
+ * in hardware via passive delay elements on the SOM PCB.
+ * No delay configuration is needed in software via PHY driver.
+ */
+ phy-mode = "rgmii";
+ phy-handle = <ðphy0>;
+ snps,clk-csr = <5>;
+ status = "okay";
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ clock-frequency = <1000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <100000>;
+ };
+ };
+};
+
+&lpi2c3 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default", "sleep", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c3>;
+ pinctrl-1 = <&pinctrl_lpi2c3_gpio>;
+ pinctrl-2 = <&pinctrl_lpi2c3_gpio>;
+ scl-gpios = <&gpio2 29 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 28 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ wm8904: audio-codec@1a {
+ compatible = "wlf,wm8904";
+ reg = <0x1a>;
+ #sound-dai-cells = <0>;
+ clocks = <&clk IMX93_CLK_SAI1_GATE>;
+ clock-names = "mclk";
+ AVDD-supply = <&buck5>;
+ CPVDD-supply = <&buck5>;
+ DBVDD-supply = <&buck4>;
+ DCVDD-supply = <&buck5>;
+ MICVDD-supply = <&buck5>;
+ wlf,drc-cfg-names = "default", "peaklimiter", "tradition",
+ "soft", "music";
+ /*
+ * Config registers per name, respectively:
+ * KNEE_IP = 0, KNEE_OP = 0, HI_COMP = 1, LO_COMP = 1
+ * KNEE_IP = -24, KNEE_OP = -6, HI_COMP = 1/4, LO_COMP = 1
+ * KNEE_IP = -42, KNEE_OP = -3, HI_COMP = 0, LO_COMP = 1
+ * KNEE_IP = -45, KNEE_OP = -9, HI_COMP = 1/8, LO_COMP = 1
+ * KNEE_IP = -30, KNEE_OP = -10.5, HI_COMP = 1/4, LO_COMP = 1
+ */
+ wlf,drc-cfg-regs = /bits/ 16 <0x01af 0x3248 0x0000 0x0000>,
+ /bits/ 16 <0x04af 0x324b 0x0010 0x0408>,
+ /bits/ 16 <0x04af 0x324b 0x0028 0x0704>,
+ /bits/ 16 <0x04af 0x324b 0x0018 0x078c>,
+ /bits/ 16 <0x04af 0x324b 0x0010 0x050e>;
+ /* GPIO1 = DMIC_CLK, don't touch others */
+ wlf,gpio-cfg = <0x0018>, <0xffff>, <0xffff>, <0xffff>;
+ /* DMIC is connected to IN1L */
+ wlf,in1l-as-dmicdat1;
+ };
+
+ pmic@25 {
+ compatible = "nxp,pca9451a";
+ reg = <0x25>;
+
+ regulators {
+ buck1: BUCK1 {
+ regulator-name = "BUCK1";
+ regulator-min-microvolt = <650000>;
+ regulator-max-microvolt = <2237500>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ };
+
+ buck2: BUCK2 {
+ regulator-name = "BUCK2";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <2187500>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ };
+
+ buck4: BUCK4 {
+ regulator-name = "BUCK4";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck5: BUCK5 {
+ regulator-name = "BUCK5";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck6: BUCK6 {
+ regulator-name = "BUCK6";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1: LDO1 {
+ regulator-name = "LDO1";
+ regulator-min-microvolt = <1600000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo4: LDO4 {
+ regulator-name = "LDO4";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo5: LDO5 {
+ regulator-name = "LDO5";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+};
+
+/* BT module */
+&lpuart5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart5>, <&pinctrl_bt>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "nxp,88w8987-bt";
+ };
+};
+
+&mu1 {
+ status = "okay";
+};
+
+&mu2 {
+ status = "okay";
+};
+
+&sai1 {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&pinctrl_sai1>;
+ pinctrl-1 = <&pinctrl_sai1_sleep>;
+ assigned-clocks = <&clk IMX93_CLK_SAI1>;
+ assigned-clock-parents = <&clk IMX93_CLK_AUDIO_PLL>;
+ assigned-clock-rates = <12288000>;
+ #sound-dai-cells = <0>;
+ fsl,sai-mclk-direction-output;
+ status = "okay";
+};
+
+/* eMMC */
+&usdhc1 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
+/* WiFi */
+&usdhc3 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
+ pinctrl-0 = <&pinctrl_usdhc3>, <&pinctrl_usdhc3_wlan>;
+ pinctrl-1 = <&pinctrl_usdhc3_100mhz>, <&pinctrl_usdhc3_wlan>;
+ pinctrl-2 = <&pinctrl_usdhc3_200mhz>, <&pinctrl_usdhc3_wlan>;
+ pinctrl-3 = <&pinctrl_usdhc3_sleep>, <&pinctrl_usdhc3_wlan>;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ keep-power-in-suspend;
+ bus-width = <4>;
+ non-removable;
+ wakeup-source;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_bt: btgrp {
+ fsl,pins = <
+ MX93_PAD_ENET2_MDIO__GPIO4_IO15 0x51e
+ >;
+ };
+
+ pinctrl_eqos: eqosgrp {
+ fsl,pins = <
+ MX93_PAD_ENET1_MDC__ENET_QOS_MDC 0x57e
+ MX93_PAD_ENET1_MDIO__ENET_QOS_MDIO 0x57e
+ MX93_PAD_ENET1_RD0__ENET_QOS_RGMII_RD0 0x57e
+ MX93_PAD_ENET1_RD1__ENET_QOS_RGMII_RD1 0x57e
+ MX93_PAD_ENET1_RD2__ENET_QOS_RGMII_RD2 0x57e
+ MX93_PAD_ENET1_RD3__ENET_QOS_RGMII_RD3 0x57e
+ MX93_PAD_ENET1_RXC__CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK 0x58e
+ MX93_PAD_ENET1_RX_CTL__ENET_QOS_RGMII_RX_CTL 0x57e
+ MX93_PAD_ENET1_TD0__ENET_QOS_RGMII_TD0 0x57e
+ MX93_PAD_ENET1_TD1__ENET_QOS_RGMII_TD1 0x57e
+ MX93_PAD_ENET1_TD2__ENET_QOS_RGMII_TD2 0x57e
+ MX93_PAD_ENET1_TD3__ENET_QOS_RGMII_TD3 0x57e
+ MX93_PAD_ENET1_TXC__CCM_ENET_QOS_CLOCK_GENERATE_TX_CLK 0x58e
+ MX93_PAD_ENET1_TX_CTL__ENET_QOS_RGMII_TX_CTL 0x57e
+ MX93_PAD_UART2_TXD__GPIO1_IO07 0x51e
+ >;
+ };
+
+ pinctrl_eqos_sleep: eqos-sleepgrp {
+ fsl,pins = <
+ MX93_PAD_ENET1_MDC__GPIO4_IO00 0x31e
+ MX93_PAD_ENET1_MDIO__GPIO4_IO01 0x31e
+ MX93_PAD_ENET1_RD0__GPIO4_IO10 0x31e
+ MX93_PAD_ENET1_RD1__GPIO4_IO11 0x31e
+ MX93_PAD_ENET1_RD2__GPIO4_IO12 0x31e
+ MX93_PAD_ENET1_RD3__GPIO4_IO13 0x31e
+ MX93_PAD_ENET1_RXC__GPIO4_IO09 0x31e
+ MX93_PAD_ENET1_RX_CTL__GPIO4_IO08 0x31e
+ MX93_PAD_ENET1_TD0__GPIO4_IO05 0x31e
+ MX93_PAD_ENET1_TD1__GPIO4_IO04 0x31e
+ MX93_PAD_ENET1_TD2__GPIO4_IO03 0x31e
+ MX93_PAD_ENET1_TD3__GPIO4_IO02 0x31e
+ MX93_PAD_ENET1_TXC__GPIO4_IO07 0x31e
+ MX93_PAD_ENET1_TX_CTL__GPIO4_IO06 0x31e
+ >;
+ };
+
+ pinctrl_lpi2c3: lpi2c3grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO28__LPI2C3_SDA 0x40000b9e
+ MX93_PAD_GPIO_IO29__LPI2C3_SCL 0x40000b9e
+ >;
+ };
+
+ pinctrl_lpi2c3_gpio: lpi2c3gpiogrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO28__GPIO2_IO28 0x40000b9e
+ MX93_PAD_GPIO_IO29__GPIO2_IO29 0x40000b9e
+ >;
+ };
+
+ pinctrl_sai1: sai1grp {
+ fsl,pins = <
+ MX93_PAD_SAI1_TXC__SAI1_TX_BCLK 0x31e
+ MX93_PAD_SAI1_TXFS__SAI1_TX_SYNC 0x31e
+ MX93_PAD_SAI1_TXD0__SAI1_TX_DATA00 0x31e
+ MX93_PAD_SAI1_RXD0__SAI1_RX_DATA00 0x31e
+ MX93_PAD_I2C2_SDA__SAI1_RX_BCLK 0x31e
+ MX93_PAD_I2C2_SCL__SAI1_RX_SYNC 0x31e
+ MX93_PAD_UART2_RXD__SAI1_MCLK 0x31e
+ >;
+ };
+
+ pinctrl_sai1_sleep: sai1-sleepgrp {
+ fsl,pins = <
+ MX93_PAD_SAI1_TXC__GPIO1_IO12 0x31e
+ MX93_PAD_SAI1_TXFS__GPIO1_IO11 0x31e
+ MX93_PAD_SAI1_TXD0__GPIO1_IO13 0x31e
+ MX93_PAD_SAI1_RXD0__GPIO1_IO14 0x31e
+ MX93_PAD_UART2_RXD__GPIO1_IO06 0x31e
+ MX93_PAD_I2C2_SDA__GPIO1_IO03 0x31e
+ MX93_PAD_I2C2_SCL__GPIO1_IO02 0x31e
+ >;
+ };
+
+ pinctrl_uart5: uart5grp {
+ fsl,pins = <
+ MX93_PAD_DAP_TDO_TRACESWO__LPUART5_TX 0x31e
+ MX93_PAD_DAP_TDI__LPUART5_RX 0x31e
+ MX93_PAD_DAP_TMS_SWDIO__LPUART5_RTS_B 0x31e
+ MX93_PAD_DAP_TCLK_SWCLK__LPUART5_CTS_B 0x31e
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX93_PAD_SD1_CLK__USDHC1_CLK 0x1582
+ MX93_PAD_SD1_CMD__USDHC1_CMD 0x40001382
+ MX93_PAD_SD1_DATA0__USDHC1_DATA0 0x40001382
+ MX93_PAD_SD1_DATA1__USDHC1_DATA1 0x40001382
+ MX93_PAD_SD1_DATA2__USDHC1_DATA2 0x40001382
+ MX93_PAD_SD1_DATA3__USDHC1_DATA3 0x40001382
+ MX93_PAD_SD1_DATA4__USDHC1_DATA4 0x40001382
+ MX93_PAD_SD1_DATA5__USDHC1_DATA5 0x40001382
+ MX93_PAD_SD1_DATA6__USDHC1_DATA6 0x40001382
+ MX93_PAD_SD1_DATA7__USDHC1_DATA7 0x40001382
+ MX93_PAD_SD1_STROBE__USDHC1_STROBE 0x1582
+ >;
+ };
+
+ pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
+ fsl,pins = <
+ MX93_PAD_SD1_CLK__USDHC1_CLK 0x158e
+ MX93_PAD_SD1_CMD__USDHC1_CMD 0x4000138e
+ MX93_PAD_SD1_DATA0__USDHC1_DATA0 0x4000138e
+ MX93_PAD_SD1_DATA1__USDHC1_DATA1 0x4000138e
+ MX93_PAD_SD1_DATA2__USDHC1_DATA2 0x4000138e
+ MX93_PAD_SD1_DATA3__USDHC1_DATA3 0x4000138e
+ MX93_PAD_SD1_DATA4__USDHC1_DATA4 0x4000138e
+ MX93_PAD_SD1_DATA5__USDHC1_DATA5 0x4000138e
+ MX93_PAD_SD1_DATA6__USDHC1_DATA6 0x4000138e
+ MX93_PAD_SD1_DATA7__USDHC1_DATA7 0x4000138e
+ MX93_PAD_SD1_STROBE__USDHC1_STROBE 0x158e
+ >;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
+ fsl,pins = <
+ MX93_PAD_SD1_CLK__USDHC1_CLK 0x15fe
+ MX93_PAD_SD1_CMD__USDHC1_CMD 0x400013fe
+ MX93_PAD_SD1_DATA0__USDHC1_DATA0 0x400013fe
+ MX93_PAD_SD1_DATA1__USDHC1_DATA1 0x400013fe
+ MX93_PAD_SD1_DATA2__USDHC1_DATA2 0x400013fe
+ MX93_PAD_SD1_DATA3__USDHC1_DATA3 0x400013fe
+ MX93_PAD_SD1_DATA4__USDHC1_DATA4 0x400013fe
+ MX93_PAD_SD1_DATA5__USDHC1_DATA5 0x400013fe
+ MX93_PAD_SD1_DATA6__USDHC1_DATA6 0x400013fe
+ MX93_PAD_SD1_DATA7__USDHC1_DATA7 0x400013fe
+ MX93_PAD_SD1_STROBE__USDHC1_STROBE 0x15fe
+ >;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX93_PAD_SD3_CLK__USDHC3_CLK 0x1582
+ MX93_PAD_SD3_CMD__USDHC3_CMD 0x40001382
+ MX93_PAD_SD3_DATA0__USDHC3_DATA0 0x40001382
+ MX93_PAD_SD3_DATA1__USDHC3_DATA1 0x40001382
+ MX93_PAD_SD3_DATA2__USDHC3_DATA2 0x40001382
+ MX93_PAD_SD3_DATA3__USDHC3_DATA3 0x40001382
+ >;
+ };
+
+ pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {
+ fsl,pins = <
+ MX93_PAD_SD3_CLK__USDHC3_CLK 0x158e
+ MX93_PAD_SD3_CMD__USDHC3_CMD 0x4000138e
+ MX93_PAD_SD3_DATA0__USDHC3_DATA0 0x4000138e
+ MX93_PAD_SD3_DATA1__USDHC3_DATA1 0x4000138e
+ MX93_PAD_SD3_DATA2__USDHC3_DATA2 0x4000138e
+ MX93_PAD_SD3_DATA3__USDHC3_DATA3 0x4000138e
+ >;
+ };
+
+ pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
+ fsl,pins = <
+ MX93_PAD_SD3_CLK__USDHC3_CLK 0x15fe
+ MX93_PAD_SD3_CMD__USDHC3_CMD 0x400013fe
+ MX93_PAD_SD3_DATA0__USDHC3_DATA0 0x400013fe
+ MX93_PAD_SD3_DATA1__USDHC3_DATA1 0x400013fe
+ MX93_PAD_SD3_DATA2__USDHC3_DATA2 0x400013fe
+ MX93_PAD_SD3_DATA3__USDHC3_DATA3 0x400013fe
+ >;
+ };
+
+ pinctrl_usdhc3_sleep: usdhc3-sleepgrp {
+ fsl,pins = <
+ MX93_PAD_SD3_CLK__GPIO3_IO20 0x400
+ MX93_PAD_SD3_CMD__GPIO3_IO21 0x400
+ MX93_PAD_SD3_DATA0__GPIO3_IO22 0x400
+ MX93_PAD_SD3_DATA1__GPIO3_IO23 0x400
+ MX93_PAD_SD3_DATA2__GPIO3_IO24 0x400
+ MX93_PAD_SD3_DATA3__GPIO3_IO25 0x400
+ >;
+ };
+
+ pinctrl_usdhc3_wlan: usdhc3wlangrp {
+ fsl,pins = <
+ MX93_PAD_ENET2_MDC__GPIO4_IO14 0x51e
+ MX93_PAD_SD2_RESET_B__GPIO3_IO07 0x51e
+ >;
+ };
+};
--
2.47.3
^ permalink raw reply related
* [PATCH v1 1/3] dt-bindings: arm: fsl: add Variscite DART-MX93 Boards
From: Stefano Radaelli @ 2026-03-26 15:47 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Dario Binacchi, Alexander Stein,
Maud Spierings, Josua Mayer, Markus Niebel, Francesco Dolcini,
Primoz Fiser
In-Reply-To: <cover.1774539301.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add DT compatible strings for Variscite DART-MX93 SoM and Variscite
development carrier Board.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index da2be7114f64..77497a261fd5 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1587,6 +1587,12 @@ properties:
- const: variscite,var-dart-mx91 # Variscite DART-MX91 SOM
- const: fsl,imx91
+ - description: Variscite DART-MX93 based boards
+ items:
+ - const: variscite,var-dart-mx93-sonata # Variscite DART-MX93 on Sonata Development Board
+ - const: variscite,var-dart-mx93 # Variscite DART-MX93 SOM
+ - const: fsl,imx93
+
- description: Variscite VAR-SOM-MX93 based boards
items:
- const: variscite,var-som-mx93-symphony
--
2.47.3
^ permalink raw reply related
* [PATCH v1 0/3] Add support for Variscite DART-MX93 and Sonata board
From: Stefano Radaelli @ 2026-03-26 15:47 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Dario Binacchi, Alexander Stein,
Maud Spierings, Josua Mayer, Markus Niebel, Francesco Dolcini,
Primoz Fiser
This patch series adds support for the Variscite DART-MX93 system on
module and the Sonata carrier board.
The series includes:
- SOM device tree with on-module peripherals
- Sonata carrier board device tree with board-specific features
The implementation follows the standard SOM + carrier board pattern
where the SOM dtsi contains only peripherals mounted on the module,
while carrier-specific interfaces are enabled in the board dts.
Stefano Radaelli (3):
dt-bindings: arm: fsl: add Variscite DART-MX93 Boards
arm64: dts: freescale: Add support for Variscite DART-MX93
arm64: dts: imx93-var-dart: Add support for Variscite Sonata board
.../devicetree/bindings/arm/fsl.yaml | 6 +
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../dts/freescale/imx93-var-dart-sonata.dts | 654 ++++++++++++++++++
.../boot/dts/freescale/imx93-var-dart.dtsi | 462 +++++++++++++
4 files changed, 1123 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-dart.dtsi
base-commit: 6c4b48012d57f205c94f25da0c68a4027ea6daf6
--
2.47.3
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: monaco: extend fastrpc compute cb
From: Srinivas Kandagatla @ 2026-03-26 15:45 UTC (permalink / raw)
To: andersson, konradybcio, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260326154111.2781802-1-srinivas.kandagatla@oss.qualcomm.com>
On 3/26/26 3:41 PM, Srinivas Kandagatla wrote:
> For some reason we ended up adding only 4 out of 11 compute cb's for
> CDSP, add the missing compute cb. This will also improve the end
> user-experience by enabling running multiple AI usecases in parallel.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
> ---
Changes since v1:
- renamed the node names to be decimals from hex.
-srini
> arch/arm64/boot/dts/qcom/monaco.dtsi | 49 ++++++++++++++++++++++++++++
> 1 file changed, 49 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
> index 10e799dd4a78..38fbd44c7d8f 100644
> --- a/arch/arm64/boot/dts/qcom/monaco.dtsi
> +++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
> @@ -7739,6 +7739,55 @@ compute-cb@4 {
> <&apps_smmu 0x1964 0x0400>;
> dma-coherent;
> };
> +
> + compute-cb@5 {
> + compatible = "qcom,fastrpc-compute-cb";
> + reg = <5>;
> + iommus = <&apps_smmu 0x19c5 0x0400>;
> + dma-coherent;
> + };
> +
> + compute-cb@6 {
> + compatible = "qcom,fastrpc-compute-cb";
> + reg = <6>;
> + iommus = <&apps_smmu 0x19c6 0x0400>;
> + dma-coherent;
> + };
> +
> + compute-cb@7 {
> + compatible = "qcom,fastrpc-compute-cb";
> + reg = <7>;
> + iommus = <&apps_smmu 0x19c7 0x0400>;
> + dma-coherent;
> + };
> +
> + compute-cb@8 {
> + compatible = "qcom,fastrpc-compute-cb";
> + reg = <8>;
> + iommus = <&apps_smmu 0x19c8 0x0400>;
> + dma-coherent;
> + };
> +
> + compute-cb@9 {
> + compatible = "qcom,fastrpc-compute-cb";
> + reg = <9>;
> + iommus = <&apps_smmu 0x19c9 0x0400>;
> + dma-coherent;
> + };
> +
> + compute-cb@11 {
> + compatible = "qcom,fastrpc-compute-cb";
> + reg = <0xb>;
> + iommus = <&apps_smmu 0x19cb 0x0400>;
> + dma-coherent;
> + };
> +
> + compute-cb@12 {
> + compatible = "qcom,fastrpc-compute-cb";
> + reg = <0xc>;
> + iommus = <&apps_smmu 0x19cc 0x000>;
> + dma-coherent;
> + };
> };
> };
> };
^ permalink raw reply
* Re: [PATCH 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA
From: Alexandre Belloni @ 2026-03-26 15:44 UTC (permalink / raw)
To: Rob Herring
Cc: Conor Dooley, Akhil R, Frank Li, Krzysztof Kozlowski,
Conor Dooley, Rafael J . Wysocki, Robert Moore, Len Brown,
Guenter Roeck, Philipp Zabel, Eric Biggers, Fredrik Markstrom,
Miquel Raynal, Thierry Reding, Jon Hunter, Suresh Mangipudi,
linux-tegra, linux-i3c, devicetree, linux-kernel, linux-acpi,
acpica-devel, linux-hwmon
In-Reply-To: <20260326150503.GA2360967-robh@kernel.org>
On 26/03/2026 10:05:03-0500, Rob Herring wrote:
> On Wed, Mar 18, 2026 at 05:31:50PM +0000, Conor Dooley wrote:
> > On Wed, Mar 18, 2026 at 10:57:14PM +0530, Akhil R wrote:
> > > Add the 'mipi-i3c-static-method' property mentioned in the MIPI I3C
> > > Discovery and Configuration Specification [1] to specify which discovery
> > > method an I3C device supports during bus initialization. The property is
> > > a bitmap, where a bit value of 1 indicates support for that method, and 0
> > > indicates lack of support.
> > > Bit 0: SETDASA CCC (Direct)
> > > Bit 1: SETAASA CCC (Broadcast)
> > > Bit 2: Other CCC (vendor / standards extension)
> > > All other bits are reserved.
> > >
> > > It is specifically needed when an I3C device requires SETAASA for the
> > > address assignment. SETDASA will be supported by default if this property
> > > is absent - which means for now the property just serves as a flag to
> > > enable SETAASA, but keep the property as a bitmap to align with the
> > > specifications.
> > >
> > > [1] https://www.mipi.org/specifications/disco
> > >
> > > Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> > > ---
> > > .../devicetree/bindings/i3c/i3c.yaml | 30 ++++++++++++++++---
> > > 1 file changed, 26 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/i3c/i3c.yaml b/Documentation/devicetree/bindings/i3c/i3c.yaml
> > > index e25fa72fd785..1705d90d4d79 100644
> > > --- a/Documentation/devicetree/bindings/i3c/i3c.yaml
> > > +++ b/Documentation/devicetree/bindings/i3c/i3c.yaml
> > > @@ -31,10 +31,12 @@ properties:
> > > described in the device tree, which in turn means we have to describe
> > > I3C devices.
> > >
> > > - Another use case for describing an I3C device in the device tree is when
> > > - this I3C device has a static I2C address and we want to assign it a
> > > - specific I3C dynamic address before the DAA takes place (so that other
> > > - devices on the bus can't take this dynamic address).
> > > + Other use-cases for describing an I3C device in the device tree are:
> > > + - When the I3C device has a static I2C address and we want to assign
> > > + it a specific I3C dynamic address before the DAA takes place (so
> > > + that other devices on the bus can't take this dynamic address).
> > > + - When the I3C device requires SETAASA for its discovery and uses a
> > > + pre-defined static address.
> > >
> > > "#size-cells":
> > > const: 0
> > > @@ -147,6 +149,26 @@ patternProperties:
> > > through SETDASA. If static address is not present, this address is assigned
> > > through SETNEWDA after assigning a temporary address via ENTDAA.
> > >
> > > + mipi-i3c-static-method:
> > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > + minimum: 0x1
> > > + maximum: 0xff
> > > + default: 1
> > > + description: |
> > > + Bitmap describing which methods of Dynamic Address Assignment from a
> > > + static address are supported by this I3C Target. A bit value of 1
> > > + indicates support for that method, and 0 indicates lack of support.
> >
> > I really am not keen on properties that are bitmaps, why can't we just
> > use the strings "setdasa", "setaasa" etc?
>
> If this comes from a specification, then I'd tend to just copy it rather
> than invent our own thing. Obviously if is something structured
> fundamentally different from how DT is designed, then we wouldn't. But
> this is just a simple property.
>
The issue being that the specification is not public so it is difficult
to take any decision.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v2] arm64: dts: monaco: extend fastrpc compute cb
From: Srinivas Kandagatla @ 2026-03-26 15:41 UTC (permalink / raw)
To: andersson, konradybcio, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, devicetree, linux-kernel, Srinivas Kandagatla
For some reason we ended up adding only 4 out of 11 compute cb's for
CDSP, add the missing compute cb. This will also improve the end
user-experience by enabling running multiple AI usecases in parallel.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/monaco.dtsi | 49 ++++++++++++++++++++++++++++
1 file changed, 49 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
index 10e799dd4a78..38fbd44c7d8f 100644
--- a/arch/arm64/boot/dts/qcom/monaco.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
@@ -7739,6 +7739,55 @@ compute-cb@4 {
<&apps_smmu 0x1964 0x0400>;
dma-coherent;
};
+
+ compute-cb@5 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <5>;
+ iommus = <&apps_smmu 0x19c5 0x0400>;
+ dma-coherent;
+ };
+
+ compute-cb@6 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <6>;
+ iommus = <&apps_smmu 0x19c6 0x0400>;
+ dma-coherent;
+ };
+
+ compute-cb@7 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <7>;
+ iommus = <&apps_smmu 0x19c7 0x0400>;
+ dma-coherent;
+ };
+
+ compute-cb@8 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <8>;
+ iommus = <&apps_smmu 0x19c8 0x0400>;
+ dma-coherent;
+ };
+
+ compute-cb@9 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <9>;
+ iommus = <&apps_smmu 0x19c9 0x0400>;
+ dma-coherent;
+ };
+
+ compute-cb@11 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <0xb>;
+ iommus = <&apps_smmu 0x19cb 0x0400>;
+ dma-coherent;
+ };
+
+ compute-cb@12 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <0xc>;
+ iommus = <&apps_smmu 0x19cc 0x000>;
+ dma-coherent;
+ };
};
};
};
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] arm64: dts: monaco: extend fastrpc compute cb
From: Srinivas Kandagatla @ 2026-03-26 15:38 UTC (permalink / raw)
To: Bjorn Andersson
Cc: konradybcio, robh, krzk+dt, conor+dt, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <acUzKYUCbUOIOrw2@baldur>
On 3/26/26 1:24 PM, Bjorn Andersson wrote:
> On Thu, Mar 26, 2026 at 12:58:34PM +0000, Srinivas Kandagatla wrote:
>> diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
> [..]
>> +
>> + compute-cb@b {
>
> That doesn't match the patternProperties "(compute-)?cb@[0-9]*$".
>
> Is the reg an index, or an "address"? Should we use base 10, or should
> we fix the yaml?
Ah.. sorry for this, will fix this in next spin,
--srini
>
> Regards,
> Bjorn
>
>> + compatible = "qcom,fastrpc-compute-cb";
>> + reg = <0xb>;
>> + iommus = <&apps_smmu 0x19cb 0x0400>;
>> + dma-coherent;
>> + };
>> +
>> + compute-cb@c {
>> + compatible = "qcom,fastrpc-compute-cb";
>> + reg = <0xc>;
>> + iommus = <&apps_smmu 0x19cc 0x000>;
>> + dma-coherent;
>> + };
>> };
>> };
>> };
>> --
>> 2.47.3
>>
^ permalink raw reply
* Re: [PATCH 04/22] dt-bindings: dma: renesas,rz-dmac: Document optional DMA ACK cell
From: Geert Uytterhoeven @ 2026-03-26 15:27 UTC (permalink / raw)
To: John Madieu
Cc: Kuninori Morimoto, Vinod Koul, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Michael Turquette, Stephen Boyd,
Conor Dooley, Frank Li, Liam Girdwood, Magnus Damm,
Thomas Gleixner, Jaroslav Kysela, Takashi Iwai, Philipp Zabel,
Claudiu Beznea, Biju Das, Fabrizio Castro, Lad Prabhakar,
John Madieu, linux-renesas-soc, linux-clk, devicetree,
linux-kernel, dmaengine, linux-sound
In-Reply-To: <20260319155334.51278-5-john.madieu.xa@bp.renesas.com>
Hi John,
On Thu, 19 Mar 2026 at 16:55, John Madieu <john.madieu.xa@bp.renesas.com> wrote:
> Some peripherals on RZ/V2H, RZ/V2N, and RZ/G3E SoCs require explicit
> ACK signal routing through the ICU. Document the optional second cell
> in the DMA specifier for specifying the ACK signal number.
>
> The first cell remains unchanged and specifies the encoded MID/RID and
> channel configuration. The optional second cell specifies the DMA ACK
> signal number for peripherals requiring level-based handshaking.
>
> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
Thanks for your patch!
Just a quick head-up, as I haven't read the actual secion in the
documentation yet.
> --- a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> +++ b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> @@ -63,17 +63,27 @@ properties:
> - const: register
>
> '#dma-cells':
> - const: 1
> - description:
> + description: |
> The cell specifies the encoded MID/RID or the REQ No values of
> the DMAC port connected to the DMA client and the slave channel
> configuration parameters.
> + Use 1 cell for basic DMA configuration.
> + Use 2 cells when DMA ACK signal routing through ICU is required
> + (RZ/V2H, RZ/V2N, RZ/G3E audio peripherals such as SSIU, SPDIF, SRC, DVC).
> +
> + First cell:
> bits[0:9] - Specifies the MID/RID or the REQ No value
> bit[10] - Specifies DMA request high enable (HIEN)
> bit[11] - Specifies DMA request detection type (LVL)
> bits[12:14] - Specifies DMAACK output mode (AM)
> bit[15] - Specifies Transfer Mode (TM)
>
> + Second cell (optional, when #dma-cells = <2>):
> + bits[6:0] - DMA acknowledge signal number (from ICU ACK table),
> + where 0 is a valid signal number.
> + Required for peripherals using level-based DMA
> + handshaking (SSIU, SPDIF, RSPI, SCU, ADC, PDM).
How do you expect this to work? #dma-cells applies to all DMA consumers
of this provider, and these SoCs already have DMA users relying on
#dma-cells being one.
In addition, you cannot have optional cells: if #dma-cells is two,
then all consumers must supply two cells (of course we could switch
all of them to two cells at once). However, as zero is a valid signal
number, we cannot use that as a dummy when no DMA acknowledge signal
number is needed (we could use e.g. 0xffffffff instead).
Is there any other way to provide this information?
E.g. could we have a table in the driver that contains this info for
the (presumably few) MID/RID values that need it?
> +
> dma-channels:
> const: 16
>
> @@ -212,6 +222,20 @@ allOf:
> - renesas,icu
> - resets
>
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: renesas,r9a09g057-dmac
> + then:
> + properties:
> + '#dma-cells':
> + enum: [1, 2]
> + else:
> + properties:
> + '#dma-cells':
> + const: 1
> +
> - if:
> properties:
> compatible:
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] dt-bindings: sound: Convert pcm3060 to DT schema
From: Padmashree S S @ 2026-03-26 15:30 UTC (permalink / raw)
To: k.marinushkin, lgirdwood, broonie
Cc: robh, conor+dt, krzk+dt, linux-sound, devicetree, linux-kernel,
Padmashree S S
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
Signed-off-by: Padmashree S S <padmashreess2006@gmail.com>
---
.../devicetree/bindings/sound/pcm3060.txt | 23 ----------
.../devicetree/bindings/sound/pcm3060.yaml | 45 +++++++++++++++++++
2 files changed, 45 insertions(+), 23 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/sound/pcm3060.txt
create mode 100644 Documentation/devicetree/bindings/sound/pcm3060.yaml
diff --git a/Documentation/devicetree/bindings/sound/pcm3060.txt b/Documentation/devicetree/bindings/sound/pcm3060.txt
deleted file mode 100644
index 97de66932d44..000000000000
--- a/Documentation/devicetree/bindings/sound/pcm3060.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-PCM3060 audio CODEC
-
-This driver supports both I2C and SPI.
-
-Required properties:
-
-- compatible: "ti,pcm3060"
-
-- reg : the I2C address of the device for I2C, the chip select
- number for SPI.
-
-Optional properties:
-
-- ti,out-single-ended: "true" if output is single-ended;
- "false" or not specified if output is differential.
-
-Examples:
-
- pcm3060: pcm3060@46 {
- compatible = "ti,pcm3060";
- reg = <0x46>;
- ti,out-single-ended = "true";
- };
diff --git a/Documentation/devicetree/bindings/sound/pcm3060.yaml b/Documentation/devicetree/bindings/sound/pcm3060.yaml
new file mode 100644
index 000000000000..a0455c9dad73
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/pcm3060.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/pcm3060.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PCM3060 audio CODEC
+
+maintainers:
+ - Kirill Marinushkin <k.marinushkin@gmail.com>
+
+properties:
+ compatible:
+ const: ti,pcm3060
+
+ reg:
+ maxItems: 1
+ description: |
+ The I2C address of the device
+ or SPI chip select number.
+
+ ti,out-single-ended:
+ type: boolean
+ description: |
+ If present, the output is single-ended.
+ If absent, the output is differential.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pcm3060: audio-codec@46 {
+ compatible = "ti,pcm3060";
+ reg = <0x46>;
+ ti,out-single-ended;
+ };
+ };
\ No newline at end of file
2.43.0
^ permalink raw reply related
* [PATCH v5 8/8] i2c: rtl9300: add RTL9607C i2c controller support
From: Rustam Adilov @ 2026-03-26 15:26 UTC (permalink / raw)
To: Chris Packham, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, linux-kernel
Cc: Rustam Adilov
In-Reply-To: <20260326152656.14030-1-adilov@disroot.org>
Add support for the internal I2C controllers of RTL9607C series based
SoCs. Add register definitions, chip-specific functions and macros too.
Make use of the clk introduced from the previous patch to get the clk_div
value and use it during the rtl9607c channel configuration.
Introduce a new EXT_SCK_5MS field to the reg fields struct which is going
to be initialized by rtl9607c init function at the end of the probe.
This patch depends on all the previous patches in this patch series.
Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Signed-off-by: Rustam Adilov <adilov@disroot.org>
---
drivers/i2c/busses/i2c-rtl9300.c | 70 ++++++++++++++++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/drivers/i2c/busses/i2c-rtl9300.c b/drivers/i2c/busses/i2c-rtl9300.c
index b718b74afe0d..8cedffbb2964 100644
--- a/drivers/i2c/busses/i2c-rtl9300.c
+++ b/drivers/i2c/busses/i2c-rtl9300.c
@@ -57,6 +57,7 @@ enum rtl9300_i2c_reg_fields {
F_SDA_SEL,
F_BUSY,
F_CLK_DIV,
+ F_EXT_SCK_5MS,
/* keep last */
F_NUM_FIELDS
@@ -77,8 +78,10 @@ struct rtl9300_i2c_drv_data {
#define RTL9300_I2C_MUX_NCHAN 8
#define RTL9310_I2C_MUX_NCHAN 12
+#define RTL9607_I2C_MUX_NCHAN 1
#define RTL9300_I2C_MAX_DATA_LEN 16
+#define RTL9607_I2C_MAX_DATA_LEN 4
struct rtl9300_i2c {
struct regmap *regmap;
@@ -127,6 +130,14 @@ struct rtl9300_i2c_xfer {
#define RTL9310_I2C_MST_MEMADDR_CTRL 0x4
#define RTL9310_I2C_MST_DATA_CTRL 0x8
+#define RTL9607_I2C_CONFIG 0x22f50
+#define RTL9607_IO_MODE_EN 0x23014
+#define RTL9607_I2C_IND_WD 0x0
+#define RTL9607_I2C_IND_ADR 0x8
+#define RTL9607_I2C_IND_CMD 0x10
+#define RTL9607_I2C_IND_RD 0x18
+#define RTL9607_REG_ADDR_8BIT_LEN 0
+
static int rtl9300_i2c_reg_addr_set(struct rtl9300_i2c *i2c, u32 reg, u16 len)
{
int ret;
@@ -178,6 +189,27 @@ static int rtl9300_i2c_config_chan(struct rtl9300_i2c *i2c, struct rtl9300_i2c_c
return 0;
}
+static int rtl9607_i2c_config_chan(struct rtl9300_i2c *i2c, struct rtl9300_i2c_chan *chan)
+{
+ const struct rtl9300_i2c_drv_data *drv_data;
+ int ret;
+
+ if (i2c->sda_num == chan->sda_num)
+ return 0;
+
+ ret = regmap_field_write(i2c->fields[F_CLK_DIV], chan->clk_div);
+ if (ret)
+ return ret;
+
+ drv_data = device_get_match_data(i2c->dev);
+ ret = drv_data->select_scl(i2c, i2c->scl_num);
+ if (ret)
+ return ret;
+
+ i2c->sda_num = chan->sda_num;
+ return 0;
+}
+
static void rtl9300_i2c_config_clock(u32 clock_freq, struct rtl9300_i2c_chan *chan)
{
struct rtl9300_i2c *i2c = chan->i2c;
@@ -202,6 +234,13 @@ static void rtl9300_i2c_config_clock(u32 clock_freq, struct rtl9300_i2c_chan *ch
}
}
+static void rtl9607_i2c_config_clock(u32 clock_freq, struct rtl9300_i2c_chan *chan)
+{
+ struct rtl9300_i2c *i2c = chan->i2c;
+
+ chan->clk_div = clk_get_rate(i2c->clk) / clock_freq - 1;
+}
+
static int rtl9300_i2c_read(struct rtl9300_i2c *i2c, u8 *buf, u8 len)
{
u32 vals[4] = {};
@@ -422,6 +461,11 @@ static int rtl9300_i2c_init(struct rtl9300_i2c *i2c)
return regmap_field_write(i2c->fields[F_RD_MODE], 0);
}
+static int rtl9607_i2c_init(struct rtl9300_i2c *i2c)
+{
+ return regmap_field_write(i2c->fields[F_EXT_SCK_5MS], 1);
+}
+
static int rtl9300_i2c_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -574,6 +618,31 @@ static const struct rtl9300_i2c_drv_data rtl9310_i2c_drv_data = {
.reg_addr_8bit_len = RTL9300_REG_ADDR_8BIT_LEN,
};
+static const struct rtl9300_i2c_drv_data rtl9607_i2c_drv_data = {
+ .field_desc = {
+ [F_SCL_SEL] = GLB_REG_FIELD(RTL9607_IO_MODE_EN, 13, 14),
+ [F_EXT_SCK_5MS] = MST_REG_FIELD(RTL9607_I2C_CONFIG, 26, 26),
+ [F_DEV_ADDR] = MST_REG_FIELD(RTL9607_I2C_CONFIG, 14, 20),
+ [F_MEM_ADDR_WIDTH] = MST_REG_FIELD(RTL9607_I2C_CONFIG, 12, 13),
+ [F_DATA_WIDTH] = MST_REG_FIELD(RTL9607_I2C_CONFIG, 10, 11),
+ [F_CLK_DIV] = MST_REG_FIELD(RTL9607_I2C_CONFIG, 0, 9),
+ [F_I2C_FAIL] = MST_REG_FIELD(RTL9607_I2C_IND_CMD, 3, 3),
+ [F_BUSY] = MST_REG_FIELD(RTL9607_I2C_IND_CMD, 2, 2),
+ [F_RWOP] = MST_REG_FIELD(RTL9607_I2C_IND_CMD, 1, 1),
+ [F_I2C_TRIG] = MST_REG_FIELD(RTL9607_I2C_IND_CMD, 0, 0),
+ [F_MEM_ADDR] = MST_REG_FIELD(RTL9607_I2C_IND_ADR, 0, 31),
+ },
+ .select_scl = rtl9310_i2c_select_scl,
+ .config_chan = rtl9607_i2c_config_chan,
+ .config_clock = rtl9607_i2c_config_clock,
+ .misc_init = rtl9607_i2c_init,
+ .rd_reg = RTL9607_I2C_IND_RD,
+ .wd_reg = RTL9607_I2C_IND_WD,
+ .max_nchan = RTL9607_I2C_MUX_NCHAN,
+ .max_data_len = RTL9607_I2C_MAX_DATA_LEN,
+ .reg_addr_8bit_len = RTL9607_REG_ADDR_8BIT_LEN,
+};
+
static const struct of_device_id i2c_rtl9300_dt_ids[] = {
{ .compatible = "realtek,rtl9301-i2c", .data = (void *) &rtl9300_i2c_drv_data },
{ .compatible = "realtek,rtl9302b-i2c", .data = (void *) &rtl9300_i2c_drv_data },
@@ -583,6 +652,7 @@ static const struct of_device_id i2c_rtl9300_dt_ids[] = {
{ .compatible = "realtek,rtl9311-i2c", .data = (void *) &rtl9310_i2c_drv_data },
{ .compatible = "realtek,rtl9312-i2c", .data = (void *) &rtl9310_i2c_drv_data },
{ .compatible = "realtek,rtl9313-i2c", .data = (void *) &rtl9310_i2c_drv_data },
+ { .compatible = "realtek,rtl9607-i2c", .data = (void *) &rtl9607_i2c_drv_data },
{}
};
MODULE_DEVICE_TABLE(of, i2c_rtl9300_dt_ids);
--
2.53.0
^ permalink raw reply related
* [PATCH v5 7/8] i2c: rtl9300: intoduce new function properties to driver data
From: Rustam Adilov @ 2026-03-26 15:26 UTC (permalink / raw)
To: Chris Packham, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, linux-kernel
Cc: Rustam Adilov
In-Reply-To: <20260326152656.14030-1-adilov@disroot.org>
Due to the very nature of differences between RTL9607C i2c controller
and RTL9300 / RTL9310 that are incompatible with each other in some areas
of this driver, for example in clock configuration, channel configuration
and initialization at the end of the probe, introduce new function
properties to the driver data struct to handle those differences.
With these new properties, create configuration functions for RTL9300 and
RTL9310 and assign them to their respective driver data structs.
Signed-off-by: Rustam Adilov <adilov@disroot.org>
---
drivers/i2c/busses/i2c-rtl9300.c | 66 +++++++++++++++++++++-----------
1 file changed, 44 insertions(+), 22 deletions(-)
diff --git a/drivers/i2c/busses/i2c-rtl9300.c b/drivers/i2c/busses/i2c-rtl9300.c
index 16af49ccd1dd..b718b74afe0d 100644
--- a/drivers/i2c/busses/i2c-rtl9300.c
+++ b/drivers/i2c/busses/i2c-rtl9300.c
@@ -65,6 +65,9 @@ enum rtl9300_i2c_reg_fields {
struct rtl9300_i2c_drv_data {
struct rtl9300_i2c_reg_field field_desc[F_NUM_FIELDS];
int (*select_scl)(struct rtl9300_i2c *i2c, u8 scl);
+ int (*config_chan)(struct rtl9300_i2c *i2c, struct rtl9300_i2c_chan *chan);
+ void (*config_clock)(u32 clock_freq, struct rtl9300_i2c_chan *chan);
+ int (*misc_init)(struct rtl9300_i2c *i2c);
u32 rd_reg;
u32 wd_reg;
u8 max_nchan;
@@ -175,6 +178,30 @@ static int rtl9300_i2c_config_chan(struct rtl9300_i2c *i2c, struct rtl9300_i2c_c
return 0;
}
+static void rtl9300_i2c_config_clock(u32 clock_freq, struct rtl9300_i2c_chan *chan)
+{
+ struct rtl9300_i2c *i2c = chan->i2c;
+
+ switch (clock_freq) {
+ case I2C_MAX_STANDARD_MODE_FREQ:
+ chan->bus_freq = RTL9300_I2C_STD_FREQ;
+ break;
+ case I2C_MAX_FAST_MODE_FREQ:
+ chan->bus_freq = RTL9300_I2C_FAST_FREQ;
+ break;
+ case RTL9300_I2C_MAX_SUPER_FAST_FREQ:
+ chan->bus_freq = RTL9300_I2C_SUPER_FAST_FREQ;
+ break;
+ case RTL9300_I2C_MAX_SLOW_FREQ:
+ chan->bus_freq = RTL9300_I2C_SLOW_FREQ;
+ break;
+ default:
+ dev_warn(i2c->dev, "SDA%d clock-frequency %d not supported using default\n",
+ chan->sda_num, clock_freq);
+ break;
+ }
+}
+
static int rtl9300_i2c_read(struct rtl9300_i2c *i2c, u8 *buf, u8 len)
{
u32 vals[4] = {};
@@ -322,7 +349,7 @@ static int rtl9300_i2c_smbus_xfer(struct i2c_adapter *adap, u16 addr, unsigned s
guard(rtl9300_i2c)(i2c);
drv_data = device_get_match_data(i2c->dev);
- ret = rtl9300_i2c_config_chan(i2c, chan);
+ ret = drv_data->config_chan(i2c, chan);
if (ret)
return ret;
@@ -389,6 +416,12 @@ static struct i2c_adapter_quirks rtl9300_i2c_quirks = {
.max_write_len = 16,
};
+static int rtl9300_i2c_init(struct rtl9300_i2c *i2c)
+{
+ /* only use standard read format */
+ return regmap_field_write(i2c->fields[F_RD_MODE], 0);
+}
+
static int rtl9300_i2c_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -453,27 +486,11 @@ static int rtl9300_i2c_probe(struct platform_device *pdev)
if (ret)
clock_freq = I2C_MAX_STANDARD_MODE_FREQ;
- switch (clock_freq) {
- case I2C_MAX_STANDARD_MODE_FREQ:
- chan->bus_freq = RTL9300_I2C_STD_FREQ;
- break;
- case I2C_MAX_FAST_MODE_FREQ:
- chan->bus_freq = RTL9300_I2C_FAST_FREQ;
- break;
- case RTL9300_I2C_MAX_SUPER_FAST_FREQ:
- chan->bus_freq = RTL9300_I2C_SUPER_FAST_FREQ;
- break;
- case RTL9300_I2C_MAX_SLOW_FREQ:
- chan->bus_freq = RTL9300_I2C_SLOW_FREQ;
- break;
- default:
- dev_warn(i2c->dev, "SDA%d clock-frequency %d not supported using default\n",
- sda_num, clock_freq);
- break;
- }
-
chan->sda_num = sda_num;
chan->i2c = i2c;
+
+ drv_data->config_clock(clock_freq, chan);
+
adap = &i2c->chans[i].adap;
adap->owner = THIS_MODULE;
adap->algo = &rtl9300_i2c_algo;
@@ -491,8 +508,7 @@ static int rtl9300_i2c_probe(struct platform_device *pdev)
}
i2c->sda_num = 0xff;
- /* only use standard read format */
- ret = regmap_field_write(i2c->fields[F_RD_MODE], 0);
+ ret = drv_data->misc_init(i2c);
if (ret)
return ret;
@@ -521,6 +537,9 @@ static const struct rtl9300_i2c_drv_data rtl9300_i2c_drv_data = {
[F_BUSY] = MST_REG_FIELD(RTL9300_I2C_MST_CTRL1, 0, 0),
},
.select_scl = rtl9300_i2c_select_scl,
+ .config_chan = rtl9300_i2c_config_chan,
+ .config_clock = rtl9300_i2c_config_clock,
+ .misc_init = rtl9300_i2c_init,
.rd_reg = RTL9300_I2C_MST_DATA_WORD0,
.wd_reg = RTL9300_I2C_MST_DATA_WORD0,
.max_nchan = RTL9300_I2C_MUX_NCHAN,
@@ -545,6 +564,9 @@ static const struct rtl9300_i2c_drv_data rtl9310_i2c_drv_data = {
[F_BUSY] = MST_REG_FIELD(RTL9310_I2C_MST_CTRL, 0, 0),
},
.select_scl = rtl9310_i2c_select_scl,
+ .config_chan = rtl9300_i2c_config_chan,
+ .config_clock = rtl9300_i2c_config_clock,
+ .misc_init = rtl9300_i2c_init,
.rd_reg = RTL9310_I2C_MST_DATA_CTRL,
.wd_reg = RTL9310_I2C_MST_DATA_CTRL,
.max_nchan = RTL9310_I2C_MUX_NCHAN,
--
2.53.0
^ permalink raw reply related
* [PATCH v5 6/8] i2c: rtl9300: introduce clk struct for upcoming rtl9607 support
From: Rustam Adilov @ 2026-03-26 15:26 UTC (permalink / raw)
To: Chris Packham, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, linux-kernel
Cc: Rustam Adilov
In-Reply-To: <20260326152656.14030-1-adilov@disroot.org>
In RTL9607C i2c controller, there is 10 bit CLK_DIV field for
setting the clock of i2c interface which depends on the rate
of i2c clk (which seems be fixed to 62.5MHz according to Realtek SDK).
Introduce the clk struct and the respective F_CLK_DIV and clk_div
which are going to be used in the upcoming patch for rtl9607c i2c
controller support addition.
devm_clk_get_optional_enabled() function was used for cleaner code
as it automatically returns NULL if the clk is not present, which is
going to be the case for RTL9300 and RTL9310 i2c controllers.
Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Signed-off-by: Rustam Adilov <adilov@disroot.org>
---
drivers/i2c/busses/i2c-rtl9300.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/i2c/busses/i2c-rtl9300.c b/drivers/i2c/busses/i2c-rtl9300.c
index ffbc6c52861b..16af49ccd1dd 100644
--- a/drivers/i2c/busses/i2c-rtl9300.c
+++ b/drivers/i2c/busses/i2c-rtl9300.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0-only
#include <linux/bits.h>
+#include <linux/clk.h>
#include <linux/i2c.h>
#include <linux/i2c-mux.h>
#include <linux/mod_devicetable.h>
@@ -28,6 +29,7 @@ struct rtl9300_i2c_chan {
struct rtl9300_i2c *i2c;
enum rtl9300_bus_freq bus_freq;
u8 sda_num;
+ u32 clk_div;
};
enum rtl9300_i2c_reg_scope {
@@ -54,6 +56,7 @@ enum rtl9300_i2c_reg_fields {
F_SDA_OUT_SEL,
F_SDA_SEL,
F_BUSY,
+ F_CLK_DIV,
/* keep last */
F_NUM_FIELDS
@@ -85,6 +88,7 @@ struct rtl9300_i2c {
u8 scl_num;
u8 sda_num;
struct mutex lock;
+ struct clk *clk;
};
DEFINE_GUARD(rtl9300_i2c, struct rtl9300_i2c *, mutex_lock(&_T->lock), mutex_unlock(&_T->lock))
@@ -432,6 +436,10 @@ static int rtl9300_i2c_probe(struct platform_device *pdev)
if (ret)
return ret;
+ i2c->clk = devm_clk_get_optional_enabled(dev, NULL);
+ if (IS_ERR(i2c->clk))
+ return dev_err_probe(dev, PTR_ERR(i2c->clk), "Failed to enable i2c clock\n");
+
i = 0;
for_each_child_of_node_scoped(dev->of_node, child) {
struct rtl9300_i2c_chan *chan = &i2c->chans[i];
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox