* Re: [PATCH RFC 04/10] arm64: dts: qcom: msm8939: Add venus node
From: Bryan O'Donoghue @ 2026-04-16 14:31 UTC (permalink / raw)
To: Erikas Bitovtas, Vikash Garodia, Dikshita Agarwal,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, André Apitzsch, Bjorn Andersson, Konrad Dybcio,
Michael Turquette, Stephen Boyd
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel, linux-clk,
~postmarketos/upstreaming, phone-devel
In-Reply-To: <20260416-msm8939-venus-rfc-v1-4-a09fcf2c23df@gmail.com>
On 16/04/2026 14:43, Erikas Bitovtas wrote:
> + video-decoder {
> + compatible = "venus-decoder";
> + clocks = <&gcc GCC_VENUS0_CORE0_VCODEC0_CLK>,
> + <&gcc GCC_VENUS0_CORE1_VCODEC0_CLK>;
> + clock-names = "core0", "core1";
> + power-domains = <&gcc VENUS_CORE0_GDSC>,
> + <&gcc VENUS_CORE1_GDSC>;
This doesn't make sense.
You have two cores => assign one to encoder and the other to decoder.
And your resource struct looks like this
+static const struct venus_resources msm8939_res = {
+ .freq_tbl = msm8939_freq_table,
+ .freq_tbl_size = ARRAY_SIZE(msm8939_freq_table),
+ .reg_tbl = msm8939_reg_preset,
+ .reg_tbl_size = ARRAY_SIZE(msm8939_reg_preset),
+ .clks = { "core", "iface", "bus", },
+ .clks_num = 3,
+ .vcodec0_clks = { "core0", "core1" },
+ .vcodec_clks_num = 2,
+ .vcodec0_pmdomains = (const char *[]) { "core0", "core1" },
+ .vcodec0_pmdomains_num = 2,
+ .max_load = 489600, /* 1080p@30 + 1080p@30 */
You've got the max load right.
+ .hfi_version = HFI_VERSION_1XX,
+ .vmem_id = VIDC_RESOURCE_NONE,
+ .vmem_size = 0,
+ .vmem_addr = 0,
+ .dma_mask = 0xddc00000 - 1,
+ .fwname = "qcom/venus-1.8/venus.mbn",
+ .enc_nodename = "video-encoder",
+};
8916 points the way here
static const struct venus_resources msm8916_res = {
.freq_tbl = msm8916_freq_table,
.freq_tbl_size = ARRAY_SIZE(msm8916_freq_table),
.reg_tbl = msm8916_reg_preset,
.reg_tbl_size = ARRAY_SIZE(msm8916_reg_preset),
.clks = { "core", "iface", "bus", },
.clks_num = 3,
.max_load = 352800, /* 720p@30 + 1080p@30 */
.hfi_version = HFI_VERSION_1XX,
.vmem_id = VIDC_RESOURCE_NONE,
.vmem_size = 0,
.vmem_addr = 0,
.dma_mask = 0xddc00000 - 1,
.fwname = "qcom/venus-1.8/venus.mbn",
.dec_nodename = "video-decoder",
.enc_nodename = "video-encoder",
};
---
bod
^ permalink raw reply
* Re: [PATCH RFC 08/10] media: venus: move getting vdec and venc for later
From: Bryan O'Donoghue @ 2026-04-16 14:33 UTC (permalink / raw)
To: Erikas Bitovtas, Vikash Garodia, Dikshita Agarwal,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, André Apitzsch, Bjorn Andersson, Konrad Dybcio,
Michael Turquette, Stephen Boyd
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel, linux-clk,
~postmarketos/upstreaming, phone-devel
In-Reply-To: <20260416-msm8939-venus-rfc-v1-8-a09fcf2c23df@gmail.com>
On 16/04/2026 14:43, Erikas Bitovtas wrote:
> Call vdec_get and venc_get later in the probe, after core->dev_{dec,enc}
> get assigned. This is needed so dev_dec and dev_enc are initialized
> when we are calling vdec_get and venc_get, so we can attach core power
> domain lists to their devices.
>
> Signed-off-by: Erikas Bitovtas<xerikasxx@gmail.com>
> ---
> drivers/media/platform/qcom/venus/vdec.c | 12 ++++++------
Are you describing a bug - if so you need a Fixes and a cc stable, if
not you should make clearer in the log that subsequent patches depend.
---
bod
^ permalink raw reply
* Re: [PATCH v2 2/2] hwmon: (pmbus/max20830) add driver for max20830
From: Nuno Sá @ 2026-04-16 14:38 UTC (permalink / raw)
To: Alexis Czezar Torreno
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Shuah Khan, linux-hwmon, devicetree,
linux-kernel, linux-doc
In-Reply-To: <20260416-dev_max20830-v2-2-2c7d676dc0bd@analog.com>
On Thu, Apr 16, 2026 at 03:59:11PM +0800, Alexis Czezar Torreno wrote:
> Add support for MAX20830 step-down DC-DC switching regulator with
> PMBus interface. It allows monitoring of input/output voltage,
> output current and temperature through the PMBus serial interface.
>
> Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
> ---
> Documentation/hwmon/index.rst | 1 +
> Documentation/hwmon/max20830.rst | 49 +++++++++++++++++++++++
> MAINTAINERS | 2 +
> drivers/hwmon/pmbus/Kconfig | 9 +++++
> drivers/hwmon/pmbus/Makefile | 1 +
> drivers/hwmon/pmbus/max20830.c | 86 ++++++++++++++++++++++++++++++++++++++++
> 6 files changed, 148 insertions(+)
>
> diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
> index 8b655e5d6b68b90c697a52c7bf526e81d370caf7..56f7eb761be76dd627a2f34135abad05203b0582 100644
> --- a/Documentation/hwmon/index.rst
> +++ b/Documentation/hwmon/index.rst
> @@ -158,6 +158,7 @@ Hardware Monitoring Kernel Drivers
> max197
> max20730
> max20751
> + max20830
> max31722
> max31730
> max31760
> diff --git a/Documentation/hwmon/max20830.rst b/Documentation/hwmon/max20830.rst
> new file mode 100644
> index 0000000000000000000000000000000000000000..936e409dcc5c0898dde27d782308d4a7e1357e73
> --- /dev/null
> +++ b/Documentation/hwmon/max20830.rst
> @@ -0,0 +1,49 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +Kernel driver max20830
> +======================
> +
> +Supported chips:
> +
> + * Analog Devices MAX20830
> +
> + Prefix: 'max20830'
> +
> + Addresses scanned: -
> +
> + Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max20830.pdf
> +
> +Author:
> +
> + - Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
> +
> +
> +Description
> +-----------
> +
> +This driver supports hardware monitoring for Analog Devices MAX20830
> +Step-Down Switching Regulator with PMBus Interface.
> +
> +The MAX20830 is a 2.7V to 16V, 30A fully integrated step-down DC-DC switching
> +regulator. Through the PMBus interface, the device can monitor input/output
> +voltages, output current and temperature.
> +
> +The driver is a client driver to the core PMBus driver. Please see
> +Documentation/hwmon/pmbus.rst for details on PMBus client drivers.
> +
> +Sysfs entries
> +-------------
> +
> +================= ========================================
> +in1_label "vin"
> +in1_input Measured input voltage
> +in1_alarm Input voltage alarm
> +in2_label "vout1"
> +in2_input Measured output voltage
> +in2_alarm Output voltage alarm
> +curr1_label "iout1"
> +curr1_input Measured output current
> +curr1_alarm Output current alarm
> +temp1_input Measured temperature
> +temp1_alarm Chip temperature alarm
> +================= ========================================
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 031c743e979521a92ed9ac67915c178ce31727bd..d6a6745e2dae29c3b8f80bbe61c54a2f5ecd9f47 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -15585,6 +15585,8 @@ L: linux-hwmon@vger.kernel.org
> S: Supported
> W: https://ez.analog.com/linux-software-drivers
> F: Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml
> +F: Documentation/hwmon/max20830.rst
> +F: drivers/hwmon/pmbus/max20830.c
>
> MAX2175 SDR TUNER DRIVER
> M: Ramesh Shanmugasundaram <rashanmu@gmail.com>
> diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
> index 8f4bff375ecbc355f5ed3400855c2852ec2aa5ef..987705bf45b75b7b91ccc469247909f3c3f53d77 100644
> --- a/drivers/hwmon/pmbus/Kconfig
> +++ b/drivers/hwmon/pmbus/Kconfig
> @@ -365,6 +365,15 @@ config SENSORS_MAX20751
> This driver can also be built as a module. If so, the module will
> be called max20751.
>
> +config SENSORS_MAX20830
> + tristate "Analog Devices MAX20830"
> + help
> + If you say yes here you get hardware monitoring support for Analog
> + Devices MAX20830.
> +
> + This driver can also be built as a module. If so, the module will
> + be called max20830.
> +
> config SENSORS_MAX31785
> tristate "Maxim MAX31785 and compatibles"
> help
> diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
> index 7129b62bc00f8a2e98de14004997752a856dfda2..bc52f930e0825a902a0dd1c9e2b44f2e8d577c35 100644
> --- a/drivers/hwmon/pmbus/Makefile
> +++ b/drivers/hwmon/pmbus/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_SENSORS_MAX16601) += max16601.o
> obj-$(CONFIG_SENSORS_MAX17616) += max17616.o
> obj-$(CONFIG_SENSORS_MAX20730) += max20730.o
> obj-$(CONFIG_SENSORS_MAX20751) += max20751.o
> +obj-$(CONFIG_SENSORS_MAX20830) += max20830.o
> obj-$(CONFIG_SENSORS_MAX31785) += max31785.o
> obj-$(CONFIG_SENSORS_MAX34440) += max34440.o
> obj-$(CONFIG_SENSORS_MAX8688) += max8688.o
> diff --git a/drivers/hwmon/pmbus/max20830.c b/drivers/hwmon/pmbus/max20830.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..21ea8b59150cb0564f1776ee08131bad7fdef003
> --- /dev/null
> +++ b/drivers/hwmon/pmbus/max20830.c
> @@ -0,0 +1,86 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Hardware monitoring driver for Analog Devices MAX20830
> + *
> + * Copyright (C) 2026 Analog Devices, Inc.
> + */
> +
> +#include <linux/i2c.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include "pmbus.h"
> +
> +static struct pmbus_driver_info max20830_info = {
> + .pages = 1,
> + .format[PSC_VOLTAGE_IN] = linear,
> + .format[PSC_VOLTAGE_OUT] = linear,
> + .format[PSC_CURRENT_OUT] = linear,
> + .format[PSC_TEMPERATURE] = linear,
> + .func[0] = PMBUS_HAVE_VIN | PMBUS_HAVE_VOUT | PMBUS_HAVE_IOUT |
> + PMBUS_HAVE_TEMP |
> + PMBUS_HAVE_STATUS_VOUT | PMBUS_HAVE_STATUS_IOUT |
> + PMBUS_HAVE_STATUS_INPUT | PMBUS_HAVE_STATUS_TEMP,
> +};
> +
> +static int max20830_probe(struct i2c_client *client)
> +{
> + u8 buf[I2C_SMBUS_BLOCK_MAX + 1];
AI seems a bit paranoid but maybe to be on the safe side just initialize
the above buffer.
> + u8 len;
> + int ret;
> +
> + if (!i2c_check_functionality(client->adapter,
> + I2C_FUNC_SMBUS_READ_I2C_BLOCK))
> + return -ENODEV;
> +
> + /*
> + * Use i2c_smbus_read_i2c_block_data() instead of
> + * i2c_smbus_read_block_data() to support I2C controllers
> + * which do not support SMBus block reads.
> + */
> + ret = i2c_smbus_read_i2c_block_data(client, PMBUS_IC_DEVICE_ID,
> + I2C_SMBUS_BLOCK_MAX, buf);
> + if (ret < 0)
> + return dev_err_probe(&client->dev, ret,
> + "Failed to read IC_DEVICE_ID\n");
> +
> + /* First byte is the block length. */
> + len = buf[0];
> + if (len != 9)
> + return dev_err_probe(&client->dev, -ENODEV,
> + "Unexpected IC_DEVICE_ID response\n");
> +
> + buf[len] = '\0';
It looks like it has a point in the above though.
- Nuno Sá
^ permalink raw reply
* Re: [PATCH 6/6] arm64: defconfig: make Tegra238 and Tegra264 Pinctrl a loadable module
From: Krzysztof Kozlowski @ 2026-04-16 14:37 UTC (permalink / raw)
To: Jon Hunter, pshete, linux-gpio, devicetree, linux-tegra,
linux-kernel, arnd, bjorn.andersson, conor+dt, dmitry.baryshkov,
ebiggers, geert, krzk+dt, kuninori.morimoto.gx, linusw,
luca.weiss, michal.simek, prabhakar.mahadev-lad.rj, robh, rosenp,
sven, thierry.reding, webgeek1234
In-Reply-To: <19f390ab-ffa9-4237-9f24-ead07b627a89@nvidia.com>
On 13/04/2026 11:49, Jon Hunter wrote:
>>>> index dd1ac01ee29b..f525670d3b84 100644
>>>> --- a/arch/arm64/configs/defconfig
>>>> +++ b/arch/arm64/configs/defconfig
>>>> @@ -711,6 +711,8 @@ CONFIG_PINCTRL_SC8280XP_LPASS_LPI=m
>>>> CONFIG_PINCTRL_SM8550_LPASS_LPI=m
>>>> CONFIG_PINCTRL_SM8650_LPASS_LPI=m
>>>> CONFIG_PINCTRL_SOPHGO_SG2000=y
>>>> +CONFIG_PINCTRL_TEGRA238=m
>>>> +CONFIG_PINCTRL_TEGRA264=m
>>>
>>> No, you just added as module. Why do we want them in upstream defconfig?
>>>
>>> Standard question, already asked Nvidia more than once.
>>
>> Yes :-)
>>
>> Prathamesh, what we need to do is ...
>>
>> 1. Add a patch to populate the pinctrl DT nodes for Tegra264 device.
>> 2. In this patch, only enable pinctrl for Tegra264 because we are
>> lacking an upstream board for Tegra238 for that moment. In the commit
>> message we should add a comment to indicate with Tegra264 platform is
>> using this.
>
> Thinking about this some more, I think I would prefer that we skip the
> defconfig patch and just add ...
>
> default m if ARCH_TEGRA_238_SOC
>
> default m if ARCH_TEGRA_264_SOC
>
> ... in the respective Kconfig files for the drivers.
I support this, I am trying to do something similar to Qualcomm. None of
core SoC drivers should become a question to the user. We want one
multiplatform image in general, so whoever chooses ARCH_TEGRA or
ARCH_QCOM should get everything (while still being able to disable if
needed).
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v7 0/3] Add Efinix FPGA configuration support
From: iansdannapel @ 2026-04-16 14:42 UTC (permalink / raw)
To: linux-fpga, devicetree, linux-kernel
Cc: mdf, yilun.xu, trix, robh, krzk+dt, conor+dt, neil.armstrong,
heiko, marex, prabhakar.mahadev-lad.rj, dev, Ian Dannapel
From: Ian Dannapel <iansdannapel@gmail.com>
Hi all,
This is v7 of the series adding support for programming Efinix FPGAs
over SPI using the fpga-mgr subsystem.
The series adds DT bindings for the Efinix SPI configuration interface
and a new FPGA manager driver implementing passive SPI configuration.
Testing:
- Verified on a custom board with an Efinix Trion T13 FPGA
- Tested full bitstream configuration over SPI at 25 MHz
Changes since v6:
dt-bindings: fpga: Add Efinix SPI programming bindings
- Require spi-cpha and spi-cpol in the binding to match the driver’s probe-time requirement
- Dropped review tag
fpga-mgr: Add Efinix SPI programming driver
- moved Makefile entry to the end of the FPGA manager section
- moved "keep asserted CS" comment to first appeareance
- removed unnecessary variable struct device *dev = &mgr->dev; in fpga mgr callbacks
- trimmed unused spi_device_id's
Ian Dannapel (3):
dt-bindings: vendor-prefix: Add prefix for Efinix, Inc.
dt-bindings: fpga: Add Efinix SPI programming bindings
fpga-mgr: Add Efinix SPI programming driver
.../bindings/fpga/efinix,trion-config.yaml | 98 +++++++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
drivers/fpga/Kconfig | 7 +
drivers/fpga/Makefile | 1 +
drivers/fpga/efinix-spi.c | 260 ++++++++++++++++++
5 files changed, 368 insertions(+)
create mode 100644 Documentation/devicetree/bindings/fpga/efinix,trion-config.yaml
create mode 100644 drivers/fpga/efinix-spi.c
--
2.43.0
^ permalink raw reply
* [PATCH v7 1/3] dt-bindings: vendor-prefix: Add prefix for Efinix, Inc.
From: iansdannapel @ 2026-04-16 14:42 UTC (permalink / raw)
To: linux-fpga, devicetree, linux-kernel
Cc: mdf, yilun.xu, trix, robh, krzk+dt, conor+dt, neil.armstrong,
heiko, marex, prabhakar.mahadev-lad.rj, dev, Ian Dannapel,
Conor Dooley, Alexander Dahl
In-Reply-To: <20260416144237.373852-1-iansdannapel@gmail.com>
From: Ian Dannapel <iansdannapel@gmail.com>
Add entry for Efinix, Inc. (https://www.efinixinc.com/)
Signed-off-by: Ian Dannapel <iansdannapel@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Alexander Dahl <ada@thorsis.com>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 00bffb9c4469..9e20384ff624 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -485,6 +485,8 @@ patternProperties:
description: Emtop Embedded Solutions
"^eeti,.*":
description: eGalax_eMPIA Technology Inc
+ "^efinix,.*":
+ description: Efinix, Inc.
"^egnite,.*":
description: egnite GmbH
"^einfochips,.*":
--
2.43.0
^ permalink raw reply related
* [PATCH v7 2/3] dt-bindings: fpga: Add Efinix SPI programming bindings
From: iansdannapel @ 2026-04-16 14:42 UTC (permalink / raw)
To: linux-fpga, devicetree, linux-kernel
Cc: mdf, yilun.xu, trix, robh, krzk+dt, conor+dt, neil.armstrong,
heiko, marex, prabhakar.mahadev-lad.rj, dev, Ian Dannapel
In-Reply-To: <20260416144237.373852-1-iansdannapel@gmail.com>
From: Ian Dannapel <iansdannapel@gmail.com>
Add device tree bindings documentation for configuring Efinix FPGA
using serial SPI passive programming mode.
Signed-off-by: Ian Dannapel <iansdannapel@gmail.com>
---
.../bindings/fpga/efinix,trion-config.yaml | 98 +++++++++++++++++++
1 file changed, 98 insertions(+)
create mode 100644 Documentation/devicetree/bindings/fpga/efinix,trion-config.yaml
diff --git a/Documentation/devicetree/bindings/fpga/efinix,trion-config.yaml b/Documentation/devicetree/bindings/fpga/efinix,trion-config.yaml
new file mode 100644
index 000000000000..7c7444ff9c3a
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/efinix,trion-config.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/fpga/efinix,trion-config.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Efinix SPI FPGA Manager
+
+maintainers:
+ - Ian Dannapel <iansdannapel@gmail.com>
+
+description: |
+ Efinix FPGAs (Trion, Topaz, and Titanium families) support loading bitstreams
+ through "SPI Passive Mode".
+ Additional pin hogs for bus width configuration should be set
+ elsewhere, if necessary.
+
+ References:
+ - https://www.efinixinc.com/docs/an006-configuring-trion-fpgas-v6.3.pdf
+ - https://www.efinixinc.com/docs/an033-configuring-titanium-fpgas-v2.8.pdf
+ - https://www.efinixinc.com/docs/an061-configuring-topaz-fpgas-v1.1.pdf
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - efinix,titanium-config
+ - efinix,topaz-config
+ - const: efinix,trion-config
+ - const: efinix,trion-config
+
+ spi-cpha: true
+
+ spi-cpol: true
+
+ spi-max-frequency:
+ maximum: 25000000
+
+ reg:
+ maxItems: 1
+
+ reset-gpios:
+ description:
+ reset and re-configuration trigger pin (low active)
+ maxItems: 1
+
+ cdone-gpios:
+ description:
+ optional configuration done status pin (high active)
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - spi-cpha
+ - spi-cpol
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
+ fpga-mgr@0 {
+ compatible = "efinix,trion-config";
+ reg = <0>;
+ spi-max-frequency = <25000000>;
+ spi-cpha;
+ spi-cpol;
+ reset-gpios = <&gpio4 17 GPIO_ACTIVE_LOW>;
+ cdone-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
+ };
+ };
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
+ fpga-mgr@0 {
+ compatible = "efinix,titanium-config", "efinix,trion-config";
+ reg = <0>;
+ spi-max-frequency = <25000000>;
+ spi-cpha;
+ spi-cpol;
+ reset-gpios = <&gpio4 17 GPIO_ACTIVE_LOW>;
+ cdone-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
+ };
+ };
+...
--
2.43.0
^ permalink raw reply related
* [PATCH v7 3/3] fpga-mgr: Add Efinix SPI programming driver
From: iansdannapel @ 2026-04-16 14:42 UTC (permalink / raw)
To: linux-fpga, devicetree, linux-kernel
Cc: mdf, yilun.xu, trix, robh, krzk+dt, conor+dt, neil.armstrong,
heiko, marex, prabhakar.mahadev-lad.rj, dev, Ian Dannapel
In-Reply-To: <20260416144237.373852-1-iansdannapel@gmail.com>
From: Ian Dannapel <iansdannapel@gmail.com>
Add a new driver for loading binary firmware to configuration
RAM using "SPI passive mode" on Efinix FPGAs.
Efinix passive SPI configuration requires chip select to remain asserted
from reset until the complete bitstream and trailing idle clocks have
been transferred, so the driver keeps CS active with cs_change and locks
the SPI bus for the duration of configuration.
Signed-off-by: Ian Dannapel <iansdannapel@gmail.com>
---
drivers/fpga/Kconfig | 7 +
drivers/fpga/Makefile | 1 +
drivers/fpga/efinix-spi.c | 260 ++++++++++++++++++++++++++++++++++++++
3 files changed, 268 insertions(+)
create mode 100644 drivers/fpga/efinix-spi.c
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 37b35f58f0df..748fc210c135 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -288,6 +288,13 @@ config FPGA_MGR_LATTICE_SYSCONFIG_SPI
FPGA manager driver support for Lattice FPGAs programming over slave
SPI sysCONFIG interface.
+config FPGA_MGR_EFINIX_SPI
+ tristate "Efinix FPGA configuration over SPI"
+ depends on SPI
+ help
+ FPGA manager driver support for Efinix FPGAs configuration over SPI
+ (passive mode only).
+
source "drivers/fpga/tests/Kconfig"
endif # FPGA
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index aeb89bb13517..6f5798b27e0d 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_FPGA_MGR_LATTICE_SYSCONFIG) += lattice-sysconfig.o
obj-$(CONFIG_FPGA_MGR_LATTICE_SYSCONFIG_SPI) += lattice-sysconfig-spi.o
obj-$(CONFIG_ALTERA_PR_IP_CORE) += altera-pr-ip-core.o
obj-$(CONFIG_ALTERA_PR_IP_CORE_PLAT) += altera-pr-ip-core-plat.o
+obj-$(CONFIG_FPGA_MGR_EFINIX_SPI) += efinix-spi.o
# FPGA Secure Update Drivers
obj-$(CONFIG_FPGA_M10_BMC_SEC_UPDATE) += intel-m10-bmc-sec-update.o
diff --git a/drivers/fpga/efinix-spi.c b/drivers/fpga/efinix-spi.c
new file mode 100644
index 000000000000..ed9a41232a32
--- /dev/null
+++ b/drivers/fpga/efinix-spi.c
@@ -0,0 +1,260 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * FPGA Manager Driver for Efinix
+ *
+ * Copyright (C) 2025 iris-GmbH infrared & intelligent sensors
+ *
+ * Ian Dannapel <iansdannapel@gmail.com>
+ *
+ * Load Efinix FPGA firmware over SPI using the serial configuration interface.
+ *
+ * Note: Only passive mode (host initiates transfer) is currently supported.
+ */
+
+#include <linux/delay.h>
+#include <linux/fpga/fpga-mgr.h>
+#include <linux/gpio/consumer.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/spi/spi.h>
+
+/*
+ * 13 dummy bytes generate 104 SPI clock cycles (8 bits each).
+ * Used to meet the requirement for >100 clock cycles idle sequence.
+ */
+#define EFINIX_SPI_IDLE_CYCLES_BYTES 13
+
+/*
+ * tDMIN: Minimum time between deassertion of CRESET_N to first
+ * valid configuration data. (32 µs)
+ */
+#define EFINIX_TDMIN_US_MIN 35
+#define EFINIX_TDMIN_US_MAX 40
+
+/*
+ * tCRESET_N: Minimum CRESET_N low pulse width required to
+ * trigger re-configuration. (320 ns)
+ */
+#define EFINIX_TCRESETN_DELAY_MIN_US 1
+#define EFINIX_TCRESETN_DELAY_MAX_US 2
+
+/*
+ * tUSER: Minimum configuration duration after CDONE goes high
+ * before entering user mode. (25 µs)
+ */
+#define EFINIX_TUSER_US_MIN 30
+#define EFINIX_TUSER_US_MAX 35
+
+struct efinix_spi_conf {
+ struct spi_device *spi;
+ struct gpio_desc *cdone;
+ struct gpio_desc *reset;
+};
+
+static void efinix_spi_reset(struct efinix_spi_conf *conf)
+{
+ gpiod_set_value(conf->reset, 1);
+ usleep_range(EFINIX_TCRESETN_DELAY_MIN_US, EFINIX_TCRESETN_DELAY_MAX_US);
+ gpiod_set_value(conf->reset, 0);
+ usleep_range(EFINIX_TDMIN_US_MIN, EFINIX_TDMIN_US_MAX);
+}
+
+static enum fpga_mgr_states efinix_spi_state(struct fpga_manager *mgr)
+{
+ struct efinix_spi_conf *conf = mgr->priv;
+
+ if (conf->cdone && gpiod_get_value(conf->cdone) == 1)
+ return FPGA_MGR_STATE_OPERATING;
+
+ return FPGA_MGR_STATE_UNKNOWN;
+}
+
+static int efinix_spi_write_init(struct fpga_manager *mgr,
+ struct fpga_image_info *info,
+ const char *buf, size_t count)
+{
+ struct efinix_spi_conf *conf = mgr->priv;
+ struct spi_transfer assert_cs = {
+ /* Keep CS asserted across configuration. */
+ .cs_change = 1,
+ };
+ struct spi_message message;
+ int ret;
+
+ if (info->flags & FPGA_MGR_PARTIAL_RECONFIG) {
+ dev_err(&mgr->dev, "Partial reconfiguration not supported\n");
+ return -EOPNOTSUPP;
+ }
+
+ /*
+ * Efinix passive SPI configuration requires chip select to stay
+ * asserted from reset until the bitstream is fully clocked in.
+ * Lock the SPI bus so no other device can toggle CS between the
+ * reset pulse and the write/complete transfers.
+ */
+ spi_bus_lock(conf->spi->controller);
+ spi_message_init_with_transfers(&message, &assert_cs, 1);
+ ret = spi_sync_locked(conf->spi, &message);
+ if (ret) {
+ spi_bus_unlock(conf->spi->controller);
+ return ret;
+ }
+
+ /* Reset with CS asserted */
+ efinix_spi_reset(conf);
+
+ return 0;
+}
+
+static int efinix_spi_write(struct fpga_manager *mgr, const char *buf,
+ size_t count)
+{
+ struct spi_transfer write_xfer = {
+ .tx_buf = buf,
+ .len = count,
+ .cs_change = 1,
+ };
+ struct efinix_spi_conf *conf = mgr->priv;
+ struct spi_message message;
+ int ret;
+
+ spi_message_init_with_transfers(&message, &write_xfer, 1);
+ ret = spi_sync_locked(conf->spi, &message);
+ if (ret) {
+ dev_err(&mgr->dev, "SPI error in firmware write: %d\n", ret);
+ spi_bus_unlock(conf->spi->controller);
+ }
+
+ return ret;
+}
+
+static int efinix_spi_write_complete(struct fpga_manager *mgr,
+ struct fpga_image_info *info)
+{
+ unsigned long timeout =
+ jiffies + usecs_to_jiffies(info->config_complete_timeout_us);
+ struct spi_transfer clk_cycles = {
+ .len = EFINIX_SPI_IDLE_CYCLES_BYTES,
+ /* Release CS after the trailing idle clocks are sent. */
+ .cs_change = 0,
+ };
+ struct efinix_spi_conf *conf = mgr->priv;
+ struct spi_message message;
+ int done, ret;
+ bool expired = false;
+ u8 *dummy_buf;
+
+ dummy_buf = kzalloc(EFINIX_SPI_IDLE_CYCLES_BYTES, GFP_KERNEL);
+ if (!dummy_buf) {
+ ret = -ENOMEM;
+ goto unlock_spi;
+ }
+
+ /*
+ * Keep the bus locked while sending the trailing idle clocks, then
+ * let this final transfer deassert CS to terminate configuration.
+ */
+ clk_cycles.tx_buf = dummy_buf;
+ spi_message_init_with_transfers(&message, &clk_cycles, 1);
+ ret = spi_sync_locked(conf->spi, &message);
+ if (ret) {
+ dev_err(&mgr->dev, "SPI error in write complete: %d\n", ret);
+ goto free_buf;
+ }
+
+ if (conf->cdone) {
+ while (!expired) {
+ done = gpiod_get_value(conf->cdone);
+ if (done < 0) {
+ ret = done;
+ goto free_buf;
+ }
+ if (done)
+ break;
+
+ usleep_range(10, 20);
+ expired = time_after(jiffies, timeout);
+ }
+
+ if (expired) {
+ dev_err(&mgr->dev, "Timeout waiting for CDONE\n");
+ ret = -ETIMEDOUT;
+ goto free_buf;
+ }
+ }
+
+ usleep_range(EFINIX_TUSER_US_MIN, EFINIX_TUSER_US_MAX);
+
+free_buf:
+ kfree(dummy_buf);
+unlock_spi:
+ spi_bus_unlock(conf->spi->controller);
+
+ return ret;
+}
+
+static const struct fpga_manager_ops efinix_spi_ops = {
+ .state = efinix_spi_state,
+ .write_init = efinix_spi_write_init,
+ .write = efinix_spi_write,
+ .write_complete = efinix_spi_write_complete,
+};
+
+static int efinix_spi_probe(struct spi_device *spi)
+{
+ struct efinix_spi_conf *conf;
+ struct fpga_manager *mgr;
+
+ if (!(spi->mode & SPI_CPHA) || !(spi->mode & SPI_CPOL))
+ return dev_err_probe(&spi->dev, -EINVAL,
+ "Unsupported SPI mode, set CPHA and CPOL\n");
+
+ conf = devm_kzalloc(&spi->dev, sizeof(*conf), GFP_KERNEL);
+ if (!conf)
+ return -ENOMEM;
+
+ conf->reset = devm_gpiod_get(&spi->dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(conf->reset))
+ return dev_err_probe(&spi->dev, PTR_ERR(conf->reset),
+ "Failed to get RESET gpio\n");
+
+ conf->cdone = devm_gpiod_get_optional(&spi->dev, "cdone", GPIOD_IN);
+ if (IS_ERR(conf->cdone))
+ return dev_err_probe(&spi->dev, PTR_ERR(conf->cdone),
+ "Failed to get CDONE gpio\n");
+
+ conf->spi = spi;
+
+ mgr = devm_fpga_mgr_register(&spi->dev,
+ "Efinix FPGA Manager",
+ &efinix_spi_ops, conf);
+
+ return PTR_ERR_OR_ZERO(mgr);
+}
+
+static const struct of_device_id efinix_spi_of_match[] = {
+ { .compatible = "efinix,trion-config", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, efinix_spi_of_match);
+
+static const struct spi_device_id efinix_ids[] = {
+ { "trion-config", 0 },
+ {},
+};
+MODULE_DEVICE_TABLE(spi, efinix_ids);
+
+static struct spi_driver efinix_spi_driver = {
+ .driver = {
+ .name = "efinix-spi",
+ .of_match_table = efinix_spi_of_match,
+ },
+ .probe = efinix_spi_probe,
+ .id_table = efinix_ids,
+};
+
+module_spi_driver(efinix_spi_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Ian Dannapel <iansdannapel@gmail.com>");
+MODULE_DESCRIPTION("Efinix FPGA SPI Programming Driver");
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 2/2] drm/bridge: waveshare-dsi: support DSI LCD kits with LVDS panels
From: Luca Ceresoli @ 2026-04-16 14:45 UTC (permalink / raw)
To: Dmitry Baryshkov, Neil Armstrong, Jessica Zhang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, Sam Ravnborg, Joseph Guo, Marek Vasut,
Andrzej Hajda, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec
Cc: dri-devel, devicetree, linux-kernel
In-Reply-To: <20260412-ws-lcd-v3-2-db22c2631828@oss.qualcomm.com>
On Sun Apr 12, 2026 at 7:32 PM CEST, Dmitry Baryshkov wrote:
> Several Waveshare DSI LCD kits use LVDS panels and the ICN6202 DSI2LVDS
> bridge. Support that setup by handling waveshare,dsi2lvds compatible.
> The only difference with the existing waveshare,dsi2dpi is the bridge's
> output type (LVDS vs DPI).
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v2] dt-bindings: iio: gyroscope: add mount-matrix for bmg160
From: Vishwas Rajashekar via B4 Relay @ 2026-04-16 15:03 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
H. Nikolaus Schaller
Cc: linux-iio, devicetree, linux-kernel, luca, Vishwas Rajashekar
From: Vishwas Rajashekar <vishwas.dev@vrajashkr.com>
Adds mount-matrix as an optional property to dt-bindings
for the bmg160 gyroscope as the driver reads this optional
property during probe.
Signed-off-by: Vishwas Rajashekar <vishwas.dev@vrajashkr.com>
---
The bmg160 driver reads an optional mount-matrix using
"iio_read_mount_matrix" in "bmg160_core_probe" and stores
this orientation data in "struct bmg160_data". As the "mount-matrix"
property is used by the driver, this change proposes to add it to
the corresponding dt-bindings.
---
Changes in v2:
- Addressed review feedback: add mount-matrix example for bmg160
- Link to v1: https://patch.msgid.link/20260415-bmg160-mount-matrix-dt-binding-v1-1-0e2c85964ee6@vrajashkr.com
To: Jonathan Cameron <jic23@kernel.org>
To: David Lechner <dlechner@baylibre.com>
To: Nuno Sá <nuno.sa@analog.com>
To: Andy Shevchenko <andy@kernel.org>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: linux-iio@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
Documentation/devicetree/bindings/iio/gyroscope/bosch,bmg160.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/gyroscope/bosch,bmg160.yaml b/Documentation/devicetree/bindings/iio/gyroscope/bosch,bmg160.yaml
index 3c6fe74af0b8..ec97778cca78 100644
--- a/Documentation/devicetree/bindings/iio/gyroscope/bosch,bmg160.yaml
+++ b/Documentation/devicetree/bindings/iio/gyroscope/bosch,bmg160.yaml
@@ -22,6 +22,9 @@ properties:
vdd-supply: true
vddio-supply: true
+ mount-matrix:
+ description: an optional 3x3 mounting rotation matrix.
+
spi-max-frequency:
maximum: 10000000
@@ -52,6 +55,9 @@ examples:
reg = <0x69>;
interrupt-parent = <&gpio6>;
interrupts = <18 IRQ_TYPE_EDGE_RISING>;
+ mount-matrix = "0", "1", "0",
+ "1", "0", "0",
+ "0", "0", "1";
};
};
...
---
base-commit: 591cd656a1bf5ea94a222af5ef2ee76df029c1d2
change-id: 20260414-bmg160-mount-matrix-dt-binding-e76ddde94866
Best regards,
--
Vishwas Rajashekar <vishwas.dev@vrajashkr.com>
^ permalink raw reply related
* Re: [PATCH] dt-bindings: iio: dac: mcp47feb02: Fix binding issues
From: Conor Dooley @ 2026-04-16 15:15 UTC (permalink / raw)
To: Ariana Lazar
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
Conor Dooley, linux-iio, devicetree, linux-kernel
In-Reply-To: <20260416-mcp47feb02-fix5-v1-1-9656c2fed6d2@microchip.com>
[-- Attachment #1: Type: text/plain, Size: 8563 bytes --]
Hey,
On Thu, Apr 16, 2026 at 04:33:36PM +0300, Ariana Lazar wrote:
> Change maxItems value from 8 to 1 for the channel number reg property.
> Change example reg value from 0 to 0x60.
> Fix a few typos in property descriptions.
> Sort the part numbers in the enum list lexicographically.
Hmm, this looks like 3 or 4 patches to me. The maxItems change probably
qualifies for a fixes tag, none of the rest do.
>
> Fixes: 4ba12d304175 ("dt-bindings: iio: dac: adding support for Microchip MCP47FEB02")
> Reported-by: Conor Dooley <conor@kernel.org>
> Closes: https://lore.kernel.org/all/20260403-speed-childless-1360de358229@spud/
I didn't report anything, I just commented on something that you had
already "reported" when you fixed it yourself.
> Reported-by: David Lechner <dlechner@baylibre.com>
> Closes: https://lore.kernel.org/all/dd0dbadb-604b-4f12-8674-268b7db096fd@baylibre.com/
David didn't report anything either, he just gave you review feedback on
the change you made to the example.
> Signed-off-by: Ariana Lazar <ariana.lazar@microchip.com>
> ---
> .../bindings/iio/dac/microchip,mcp47feb02.yaml | 57 +++++++++++-----------
> 1 file changed, 28 insertions(+), 29 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml b/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml
> index d2466aa6bda2106a8b695347a0edf38462294d03..88a1495f2967a3d821ada7e7e9a7fbb466401040 100644
> --- a/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml
> +++ b/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml
> @@ -61,29 +61,29 @@ properties:
> compatible:
> enum:
> - microchip,mcp47feb01
> - - microchip,mcp47feb11
> - - microchip,mcp47feb21
> - microchip,mcp47feb02
> + - microchip,mcp47feb04
> + - microchip,mcp47feb08
> + - microchip,mcp47feb11
> - microchip,mcp47feb12
> + - microchip,mcp47feb14
> + - microchip,mcp47feb18
> + - microchip,mcp47feb21
> - microchip,mcp47feb22
> + - microchip,mcp47feb24
> + - microchip,mcp47feb28
> - microchip,mcp47fvb01
> - - microchip,mcp47fvb11
> - - microchip,mcp47fvb21
> - microchip,mcp47fvb02
> - - microchip,mcp47fvb12
> - - microchip,mcp47fvb22
> - microchip,mcp47fvb04
> - - microchip,mcp47fvb14
> - - microchip,mcp47fvb24
> - microchip,mcp47fvb08
> + - microchip,mcp47fvb11
> + - microchip,mcp47fvb12
> + - microchip,mcp47fvb14
> - microchip,mcp47fvb18
> + - microchip,mcp47fvb21
> + - microchip,mcp47fvb22
> + - microchip,mcp47fvb24
> - microchip,mcp47fvb28
> - - microchip,mcp47feb04
> - - microchip,mcp47feb14
> - - microchip,mcp47feb24
> - - microchip,mcp47feb08
> - - microchip,mcp47feb18
> - - microchip,mcp47feb28
>
> reg:
> maxItems: 1
> @@ -111,13 +111,13 @@ properties:
> - for single-channel device: Vout0;
> - for dual-channel device: Vout0, Vout1;
> - for quad-channel device: Vout0, Vout2;
> - - for octal-channel device: Vout0, Vout2, Vout6, Vout8;
> + - for octal-channel device: Vout0, Vout2, Vout4, Vout6;
>
> vref1-supply:
> description: |
> Vref1 pin may be used as a voltage reference when this supply is specified.
> The internal reference will be taken into account for voltage reference
> - beside VDD if this supply does not exist.
> + besides VDD if this supply does not exist.
ngl, I don't think this is a typo, the sentence doesn't make sense
either before or after the change. Should this be something like "The
internal reference and VDD will be used as the voltage reference if this
supply does not exist?
>
> This supply will be voltage reference for the following outputs:
> - for quad-channel device: Vout1, Vout3;
> @@ -141,7 +141,7 @@ properties:
> description:
> Enable buffering of the external Vref/Vref0 pin in cases where the
> external reference voltage does not have sufficient current capability in
> - order not to drop it’s voltage when connected to the internal resistor
> + order not to drop its voltage when connected to the internal resistor
> ladder circuit.
>
> microchip,vref1-buffered:
> @@ -149,7 +149,7 @@ properties:
> description:
> Enable buffering of the external Vref1 pin in cases where the external
> reference voltage does not have sufficient current capability in order not
> - to drop it’s voltage when connected to the internal resistor ladder
> + to drop its voltage when connected to the internal resistor ladder
> circuit.
>
> patternProperties:
> @@ -161,8 +161,7 @@ patternProperties:
> properties:
> reg:
> description: The channel number.
> - minItems: 1
> - maxItems: 8
> + maxItems: 1
>
> label:
> description: Unique name to identify which channel this is.
> @@ -227,12 +226,12 @@ allOf:
> compatible:
> contains:
> enum:
> - - microchip,mcp47fvb04
> - - microchip,mcp47fvb14
> - - microchip,mcp47fvb24
> - microchip,mcp47feb04
> - microchip,mcp47feb14
> - microchip,mcp47feb24
> + - microchip,mcp47fvb04
> + - microchip,mcp47fvb14
> + - microchip,mcp47fvb24
> then:
> patternProperties:
> "^channel@[0-3]$":
> @@ -245,12 +244,12 @@ allOf:
> compatible:
> contains:
> enum:
> - - microchip,mcp47fvb08
> - - microchip,mcp47fvb18
> - - microchip,mcp47fvb28
> - microchip,mcp47feb08
> - microchip,mcp47feb18
> - microchip,mcp47feb28
> + - microchip,mcp47fvb08
> + - microchip,mcp47fvb18
> + - microchip,mcp47fvb28
> then:
> patternProperties:
> "^channel@[0-7]$":
> @@ -280,9 +279,9 @@ examples:
>
> #address-cells = <1>;
> #size-cells = <0>;
> - dac@0 {
> + dac@60 {
> compatible = "microchip,mcp47feb02";
> - reg = <0>;
> + reg = <0x60>;
> vdd-supply = <&vdac_vdd>;
> vref-supply = <&vref_reg>;
>
> @@ -297,6 +296,6 @@ examples:
> reg = <0x1>;
> label = "Adjustable_voltage_ch1";
> };
> - };
> + };
> };
This whitespace change looks odd. You've aligned the opening and closing
braces, but the indent is not consistent as there's mixed 4- and 2-space
indentation used in this example. I think you need to do:
diff --git a/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml b/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml
index d2466aa6bda21..a36874c4ae276 100644
--- a/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml
@@ -278,25 +278,25 @@ examples:
- |
i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ dac@0 {
+ compatible = "microchip,mcp47feb02";
+ reg = <0>;
+ vdd-supply = <&vdac_vdd>;
+ vref-supply = <&vref_reg>;
+
#address-cells = <1>;
#size-cells = <0>;
- dac@0 {
- compatible = "microchip,mcp47feb02";
+ channel@0 {
reg = <0>;
- vdd-supply = <&vdac_vdd>;
- vref-supply = <&vref_reg>;
+ label = "Adjustable_voltage_ch0";
+ };
- #address-cells = <1>;
- #size-cells = <0>;
- channel@0 {
- reg = <0>;
- label = "Adjustable_voltage_ch0";
- };
-
- channel@1 {
- reg = <0x1>;
- label = "Adjustable_voltage_ch1";
- };
+ channel@1 {
+ reg = <0x1>;
+ label = "Adjustable_voltage_ch1";
+ };
};
};
...
Cheers,
Conor.
> ...
>
> ---
> base-commit: d2a4ec19d2a2e54c23b5180e939994d3da4a6b91
> change-id: 20260416-mcp47feb02-fix5-26994c5b428c
>
> Best regards,
> --
> Ariana Lazar <ariana.lazar@microchip.com>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply related
* Re: [PATCH 02/10] dt-bindings: mfd: syscon: add qcom,msm8960-sps-sic
From: Antony Kurniawan Soemardi @ 2026-04-16 14:18 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Konrad Dybcio,
linux-arm-msm, linux-clk, devicetree, linux-kernel, phone-devel,
Rudraksha Gupta
In-Reply-To: <bac33524-1caa-4bff-be36-df909917cf3b@kernel.org>
On 4/15/2026 1:51 PM, Krzysztof Kozlowski wrote:
> On 14/04/2026 20:34, Antony Kurniawan Soemardi wrote:
>> On 4/14/2026 2:19 PM, Krzysztof Kozlowski wrote:
>>> This was also sent. Where is the changelog and versioning? What changed
>>> here?
>> Sorry, the cover letter should have referenced the earlier dt-bindings
>> series [1] and explained about it.
>>
>> In this patch series, I combined the original 2 patches into a larger 10
>> patch series to make it more complete. Especially since earlier feedback
>> noted that the bindings were not used by any in-tree consumers. Since
>> the scope changed significantly from the original, I resent it as a new
>> series rather than a v2.
>>
>> Would you prefer splitting this series into separate series like before,
>> for example:
>
> No, you need to keep versioning, changelogs and make clear how previous
> comments got resolved.
I see, thanks for the clarification.
To confirm my understanding, since this series already went out without
proper versioning, the next resend should be labeled v3, with a
changelog covering both what changed from the original dt-bindings
series (v1) and from this series (v2).
Is that correct?
--
Thanks,
Antony K. S.
^ permalink raw reply
* Re: [PATCH RFC 06/10] arm64: dts: qcom: msm8939-asus-z00t: add Venus
From: Konrad Dybcio @ 2026-04-16 15:17 UTC (permalink / raw)
To: Erikas Bitovtas, Bryan O'Donoghue, Vikash Garodia,
Dikshita Agarwal, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, André Apitzsch,
Bjorn Andersson, Konrad Dybcio, Michael Turquette, Stephen Boyd
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel, linux-clk,
~postmarketos/upstreaming, phone-devel
In-Reply-To: <20260416-msm8939-venus-rfc-v1-6-a09fcf2c23df@gmail.com>
On 4/16/26 3:43 PM, Erikas Bitovtas wrote:
> Enable Venus video encoder/decoder for Asus ZenFone 2 Laser/Selfie.
>
> Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
> ---
> arch/arm64/boot/dts/qcom/msm8939-asus-z00t.dts | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8939-asus-z00t.dts b/arch/arm64/boot/dts/qcom/msm8939-asus-z00t.dts
> index 90e966242720..231a3e9c1929 100644
> --- a/arch/arm64/boot/dts/qcom/msm8939-asus-z00t.dts
> +++ b/arch/arm64/boot/dts/qcom/msm8939-asus-z00t.dts
> @@ -267,6 +267,14 @@ &usb_hs_phy {
> extcon = <&usb_id>;
> };
>
> +&venus {
> + status = "okay";
You need a firmware path here
Konrad
^ permalink raw reply
* Re: [PATCH RFC 05/10] arm64: dts: qcom: msm8939-longcheer-l9100: Enable venus node
From: Konrad Dybcio @ 2026-04-16 15:17 UTC (permalink / raw)
To: Erikas Bitovtas, Bryan O'Donoghue, Vikash Garodia,
Dikshita Agarwal, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, André Apitzsch,
Bjorn Andersson, Konrad Dybcio, Michael Turquette, Stephen Boyd
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel, linux-clk,
~postmarketos/upstreaming, phone-devel
In-Reply-To: <20260416-msm8939-venus-rfc-v1-5-a09fcf2c23df@gmail.com>
On 4/16/26 3:43 PM, Erikas Bitovtas wrote:
> From: André Apitzsch <git@apitzsch.eu>
>
> Enable the venus node so that the video encoder/decoder will start
> working.
>
> Signed-off-by: André Apitzsch <git@apitzsch.eu>
> ---
> arch/arm64/boot/dts/qcom/msm8939-longcheer-l9100.dts | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8939-longcheer-l9100.dts b/arch/arm64/boot/dts/qcom/msm8939-longcheer-l9100.dts
> index 13422a19c26a..48514c3df718 100644
> --- a/arch/arm64/boot/dts/qcom/msm8939-longcheer-l9100.dts
> +++ b/arch/arm64/boot/dts/qcom/msm8939-longcheer-l9100.dts
> @@ -314,6 +314,14 @@ &usb_hs_phy {
> extcon = <&usb_id>;
> };
>
> +&venus {
> + status = "okay";
Likewise
Konrad
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: socfpga: Add the Agilex7 series SoC's
From: Dinh Nguyen @ 2026-04-16 15:20 UTC (permalink / raw)
To: Krzysztof Kozlowski; +Cc: robh, krzk+dt, conor+dt, devicetree
In-Reply-To: <321be4a9-2633-403b-ac44-4ec9102f7d14@kernel.org>
On 4/14/26 07:55, Krzysztof Kozlowski wrote:
> On 14/04/2026 14:53, Dinh Nguyen wrote:
>>
>>
>> On 4/14/26 02:17, Krzysztof Kozlowski wrote:
>>> On Mon, Apr 13, 2026 at 09:45:52AM -0500, Dinh Nguyen wrote:
>>>> The Agilex7 is a series of devices from Altera that are derived from
>>>> the Agilex family.
>>>>
>>>> The Agilex7F device supports PCIE 4.0 and DDR4. The Agilex7I device supports
>>>> PCIE 5.0 and DDR4, while the Agilex7M device supports DDR4, DDR5, LPDDR5
>>>> and PCIE 5.0.
>>>>
>>>> All other peripherals from these devices are the same as the Agilex
>>>> device.
>>>>
>>>> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
>>>> ---
>>>> Documentation/devicetree/bindings/arm/altera.yaml | 10 ++++++++++
>>>> 1 file changed, 10 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/altera.yaml b/Documentation/devicetree/bindings/arm/altera.yaml
>>>> index 206686f3eebc..5ee09f8d4698 100644
>>>> --- a/Documentation/devicetree/bindings/arm/altera.yaml
>>>> +++ b/Documentation/devicetree/bindings/arm/altera.yaml
>>>> @@ -115,6 +115,16 @@ properties:
>>>> - intel,socfpga-agilex5-socdk-nand
>>>> - const: intel,socfpga-agilex5
>>>>
>>>> + - description: Agilex7 series F, I and M boards
>>>> + items:
>>>> + - enum:
>>>> + - intel,socfpga-agilex7m-socdk
>>>> + - enum:
>>>> + - intel,socfpga-agilex7f
>>>> + - intel,socfpga-agilex7i
>>>> + - intel,socfpga-agilex7m
>>>> + - const: intel,socfpga-agilex
>>>
>>> And separate question - why previous soc "agilex" is used as fallback?
>>> Even more confusing.
>>>
>>
>> You're right. Sorry for the confusion. The Agilex7M, I, F devices are
>> basically "agilex" devices with some few additions (PCIE, DDR5). Maybe I
>> should place the Agilex7M/I/F devices into the "agilex" boards area?
>
> Compatibles should be specific and not based on families, thus what is
> "intel,socfpga-agilex"? SoC, right?
>
> Then "intel,socfpgaa-agilex7f" is a new SoC, no?
>
The Agilex7 is re-branded name for the original Agilex soc,
"intel, socfga-agilex". From a software perspective, they are the same
device. I looked over the commits to see how I could handle a
rebranding, but couldn't come up with a conclusion.
I could create a new SoC like you've suggested:
+ - description: Agilex7m boards
+ items:
+ - enum:
+ - altr,socfpga-agilex7m-socdk
+ - const: altr,socfpga-agilex7m
+ - const: altr,socfpga-agilex7
Or I can use the original "intel,socfpga-agilex"?
+ - description: Agilex7m boards
+ items:
+ - enum:
+ - altr,socfpga-agilex7m-socdk
+ - const: altr,socfpga-agilex7m
+ - const: altr,socfpga-agilex
If I create a new "altr,socfpga-agilex7" binding, then I would have to
add the new binding to a few drivers. But if I use the original
"intel,socfpga-agilex", then no drivers will need to be updated.
Thanks,
Dinh
^ permalink raw reply
* Re: [PATCH RFC 07/10] clk: qcom: gcc-msm8939: mark Venus core GDSCs as hardware controlled
From: Konrad Dybcio @ 2026-04-16 15:21 UTC (permalink / raw)
To: Erikas Bitovtas, Bryan O'Donoghue, Vikash Garodia,
Dikshita Agarwal, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, André Apitzsch,
Bjorn Andersson, Konrad Dybcio, Michael Turquette, Stephen Boyd
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel, linux-clk,
~postmarketos/upstreaming, phone-devel
In-Reply-To: <20260416-msm8939-venus-rfc-v1-7-a09fcf2c23df@gmail.com>
On 4/16/26 3:43 PM, Erikas Bitovtas wrote:
> Since in downstream kernel VENUS_CORE0_GDSC and VENUS_CORE1_GDSC have a
> device tree property "qcom,supports-hw-trigger", add a HW_CTRL flag
> to these GDSCs to indicate that they are hardware controlled.
>
> Because they can be switched off at any moment, also skip voting for
> it so it can be enabled later.
The second paragraph bears no connection with what the effect of
the changes you made is, whatsoever
Konrad
^ permalink raw reply
* [PATCH] ASoC: dt-bindings: cdns: Convert xtfpga I2S to dt-schema
From: Chaitanya Sabnis @ 2026-04-16 15:23 UTC (permalink / raw)
To: Max Filippov, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-sound, devicetree, linux-kernel, Chaitanya Sabnis
Convert the Cadence XTensa FPGA I2S controller plain-text binding
documentation to standard dt-schema (YAML).
The hardware requires exactly one memory region, one interrupt line,
and one phandle to the master clock. Verified these constraints against
the driver source in sound/soc/xtensa/xtfpga-i2s.c.
Signed-off-by: Chaitanya Sabnis <chaitanya.msabnis@gmail.com>
---
.../bindings/sound/cdns,xtfpga-i2s.txt | 18 -------
.../bindings/sound/cdns,xtfpga-i2s.yaml | 48 +++++++++++++++++++
2 files changed, 48 insertions(+), 18 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.txt
create mode 100644 Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.yaml
diff --git a/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.txt b/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.txt
deleted file mode 100644
index 860fc0da39c0..000000000000
--- a/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Bindings for I2S controller built into xtfpga Xtensa bitstreams.
-
-Required properties:
-- compatible: shall be "cdns,xtfpga-i2s".
-- reg: memory region (address and length) with device registers.
-- interrupts: interrupt for the device.
-- clocks: phandle to the clk used as master clock. I2S bus clock
- is derived from it.
-
-Examples:
-
- i2s0: xtfpga-i2s@d080000 {
- #sound-dai-cells = <0>;
- compatible = "cdns,xtfpga-i2s";
- reg = <0x0d080000 0x40>;
- interrupts = <2 1>;
- clocks = <&cdce706 4>;
- };
diff --git a/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.yaml b/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.yaml
new file mode 100644
index 000000000000..9a4a9db3c159
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/cdns,xtfpga-i2s.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence XTensa FPGA I2S Controller
+
+maintainers:
+ - Max Filippov <jcmvbkbc@gmail.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: cdns,xtfpga-i2s
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+ description: phandle to the clk used as master clock. I2S bus clock is derived from it.
+
+ "#sound-dai-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2s@d080000 {
+ compatible = "cdns,xtfpga-i2s";
+ reg = <0x0d080000 0x40>;
+ interrupts = <2 1>;
+ clocks = <&cdce706 4>;
+ #sound-dai-cells = <0>;
+ };
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v5 4/4] MAINTAINERS: Add entry on Allwinner sun8i/H616 PWM driver
From: Uwe Kleine-König @ 2026-04-16 15:28 UTC (permalink / raw)
To: Krzysztof Kozlowski, Richard Genoud
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Philipp Zabel, Paul Kocialkowski,
Thomas Petazzoni, John Stultz, Joao Schim, bigunclemax, linux-pwm,
devicetree, linux-arm-kernel, linux-sunxi, linux-kernel
In-Reply-To: <e9904440-b08d-4f9d-8d66-121633289695@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1119 bytes --]
Hello,
On Thu, Apr 16, 2026 at 03:23:49PM +0200, Krzysztof Kozlowski wrote:
> On 16/04/2026 15:14, Richard Genoud wrote:
> > Add myself as maintainer of Allwinner SUN8I PWM driver.
> >
> > Tested-by: John Stultz <jstultz@google.com>
>
> Please drop or help me understand how one can test maintainers change?
> Build process tools are not testing.
For me that is fine. This is the only way we have to record that John
tested the series. Also if I applied the original series I would have
let b4 add it to all patches in reply to a "tested-by" send in reply to
the cover letter.
My feedback here would be more: Don't send a new revision for such
comments within 30 min, also not for
> And you have commit msg trailing junk.
. Maintainers differ, but if this is the only concern and the series is
fine otherwise, I'd just fix that when applying. (But I think the "don't
send a new iteration on the same day" is more universal, also for more
fundamental feedback.) There is no need to bother all subscribers of 5
mailing lists with a new thread in such quick sequence.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: Re: [PATCH v4 1/2] dt-bindings: pwm: dwc: add reset optional
From: Conor Dooley @ 2026-04-16 15:29 UTC (permalink / raw)
To: Xuyang Dong
Cc: Krzysztof Kozlowski, ukleinek, robh, krzk+dt, conor+dt, ben-linux,
ben.dooks, p.zabel, linux-pwm, devicetree, linux-kernel, ningyu,
linmin, xuxiang, wangguosheng, pinkesh.vaghela
In-Reply-To: <281f7aa3.5575.19d95a879f8.Coremail.dongxuyang@eswincomputing.com>
[-- Attachment #1: Type: text/plain, Size: 2300 bytes --]
On Thu, Apr 16, 2026 at 05:38:59PM +0800, Xuyang Dong wrote:
> > > >
> > > > The DesignWare PWM includes separate reset signals dedicated to each clock
> > > > domain:
> > > > The presetn signal resets logic in pclk domain.
> > > > The timer_N_resetn signal resets logic in the timer_N_clk domain.
> > > > The resets are active-low.
> > > >
> > > > Signed-off-by: Xuyang Dong <dongxuyang@eswincomputing.com>
> > >
> > > This commit implies that your hardware differs from existing devices,
> > > I think you should add a device-specific compatible.
> > >
>
> Hi Conor and Krzysztof,
>
> The DesignWare PWM Databook for 2.13a says: "The DW_apb_timers includes
> separate reset signals dedicated to each clock domain". They are:
> The presetn signal resets logic in pclk domain (i.e., the bus clock in DT).
> The timer_N_resetn signal resets logic in the timer_N_clk domain (i.e.,
> the timer clock in DT).
>
> These reset signals are optional; it is up to the designer's
> implementation.
Right, and it's that "designer's implementation" that warrants a
device-specific compatible.
>
> According to [1], the applied YAML is also based on 2.13a, so our
> hardware is the same as the existing devices. It's just that these two
> reset signals were missing from the original YAML binding.
>
> [1] https://lore.kernel.org/linux-pwm/8bb5103d-803e-90d2-fd93-132bb2aac2d6@sifive.com/
>
> > > > ---
> > > > .../devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml | 3 +++
> > > > 1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml b/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
> > > > index 7523a89a1773..a8bbad0360f8 100644
> > > > --- a/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
> > > > +++ b/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
> > > > @@ -43,6 +43,9 @@ properties:
> > > > - const: bus
> > > > - const: timer
> > > >
> > > > + resets:
> > > > + maxItems: 2
> >
> > And this should really be listed with description, because order is
> > fixed.
> >
>
> The description of resets will be listed in next version.
>
> Best regards,
> Xuyang Dong
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: iio: gyroscope: add mount-matrix for bmg160
From: Conor Dooley @ 2026-04-16 15:42 UTC (permalink / raw)
To: vishwas.dev
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
H. Nikolaus Schaller, linux-iio, devicetree, linux-kernel, luca
In-Reply-To: <20260416-bmg160-mount-matrix-dt-binding-v2-1-e66cf5cff8e8@vrajashkr.com>
[-- Attachment #1: Type: text/plain, Size: 2882 bytes --]
On Thu, Apr 16, 2026 at 08:33:21PM +0530, Vishwas Rajashekar via B4 Relay wrote:
> From: Vishwas Rajashekar <vishwas.dev@vrajashkr.com>
>
> Adds mount-matrix as an optional property to dt-bindings
> for the bmg160 gyroscope as the driver reads this optional
> property during probe.
Ultimately, what the driver does is not relevant here. All that matters
is that the property is relevant to the hardware. Please come up with a
commit message that avoids mentioning linux drivers and instead explains
why it is relevant to the hardware.
pw-bot: changes-requested
Cheers,
Conor.
>
> Signed-off-by: Vishwas Rajashekar <vishwas.dev@vrajashkr.com>
> ---
> The bmg160 driver reads an optional mount-matrix using
> "iio_read_mount_matrix" in "bmg160_core_probe" and stores
> this orientation data in "struct bmg160_data". As the "mount-matrix"
> property is used by the driver, this change proposes to add it to
> the corresponding dt-bindings.
> ---
> Changes in v2:
> - Addressed review feedback: add mount-matrix example for bmg160
> - Link to v1: https://patch.msgid.link/20260415-bmg160-mount-matrix-dt-binding-v1-1-0e2c85964ee6@vrajashkr.com
>
> To: Jonathan Cameron <jic23@kernel.org>
> To: David Lechner <dlechner@baylibre.com>
> To: Nuno Sá <nuno.sa@analog.com>
> To: Andy Shevchenko <andy@kernel.org>
> To: Rob Herring <robh@kernel.org>
> To: Krzysztof Kozlowski <krzk+dt@kernel.org>
> To: Conor Dooley <conor+dt@kernel.org>
> To: "H. Nikolaus Schaller" <hns@goldelico.com>
> Cc: linux-iio@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> Documentation/devicetree/bindings/iio/gyroscope/bosch,bmg160.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/iio/gyroscope/bosch,bmg160.yaml b/Documentation/devicetree/bindings/iio/gyroscope/bosch,bmg160.yaml
> index 3c6fe74af0b8..ec97778cca78 100644
> --- a/Documentation/devicetree/bindings/iio/gyroscope/bosch,bmg160.yaml
> +++ b/Documentation/devicetree/bindings/iio/gyroscope/bosch,bmg160.yaml
> @@ -22,6 +22,9 @@ properties:
> vdd-supply: true
> vddio-supply: true
>
> + mount-matrix:
> + description: an optional 3x3 mounting rotation matrix.
> +
> spi-max-frequency:
> maximum: 10000000
>
> @@ -52,6 +55,9 @@ examples:
> reg = <0x69>;
> interrupt-parent = <&gpio6>;
> interrupts = <18 IRQ_TYPE_EDGE_RISING>;
> + mount-matrix = "0", "1", "0",
> + "1", "0", "0",
> + "0", "0", "1";
> };
> };
> ...
>
> ---
> base-commit: 591cd656a1bf5ea94a222af5ef2ee76df029c1d2
> change-id: 20260414-bmg160-mount-matrix-dt-binding-e76ddde94866
>
> Best regards,
> --
> Vishwas Rajashekar <vishwas.dev@vrajashkr.com>
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v7 2/3] dt-bindings: fpga: Add Efinix SPI programming bindings
From: Conor Dooley @ 2026-04-16 15:43 UTC (permalink / raw)
To: iansdannapel
Cc: linux-fpga, devicetree, linux-kernel, mdf, yilun.xu, trix, robh,
krzk+dt, conor+dt, neil.armstrong, heiko, marex,
prabhakar.mahadev-lad.rj, dev
In-Reply-To: <20260416144237.373852-3-iansdannapel@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 379 bytes --]
On Thu, Apr 16, 2026 at 04:42:35PM +0200, iansdannapel@gmail.com wrote:
> From: Ian Dannapel <iansdannapel@gmail.com>
>
> Add device tree bindings documentation for configuring Efinix FPGA
> using serial SPI passive programming mode.
>
> Signed-off-by: Ian Dannapel <iansdannapel@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: hwmon: pmbus: add max20830
From: Conor Dooley @ 2026-04-16 15:51 UTC (permalink / raw)
To: Alexis Czezar Torreno
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Shuah Khan, linux-hwmon, devicetree,
linux-kernel, linux-doc
In-Reply-To: <20260416-dev_max20830-v2-1-2c7d676dc0bd@analog.com>
[-- Attachment #1: Type: text/plain, Size: 3739 bytes --]
On Thu, Apr 16, 2026 at 03:59:10PM +0800, Alexis Czezar Torreno wrote:
> Add device tree documentation for MAX20830 step-down DC-DC switching
> regulator with PMBus interface.
>
> Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
> ---
> .../bindings/hwmon/pmbus/adi,max20830.yaml | 61 ++++++++++++++++++++++
> MAINTAINERS | 7 +++
> 2 files changed, 68 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml
> new file mode 100644
> index 0000000000000000000000000000000000000000..8b3ec1ffa0c9460de2122f6606ce3dcbcdfbbcc7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml
> @@ -0,0 +1,61 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/hwmon/pmbus/adi,max20830.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analog Devices MAX20830 Step-Down Switching Regulator with PMBus
> +
> +maintainers:
> + - Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
> +
> +description: |
> + The MAX20830 is a fully integrated step-down DC-DC switching regulator with
> + PMBus interface. It provides 2.7V to 16V input, 0.4V to 5.8V adjustable
> + output, and up to 30A output current. It allows monitoring of input/output
> + voltage, output current and temperature through the PMBus serial interface.
> + Datasheet:
> + https://www.analog.com/en/products/max20830.html
> +
> +allOf:
> + - $ref: /schemas/regulator/regulator.yaml#
> +
> +properties:
> + compatible:
> + const: adi,max20830
> +
> + reg:
> + maxItems: 1
On the previous version, you got an LLM comment about not having the
interrupts property amongst other things.
I think the other things got implemented, but I didn't see any reply to
the bot about that?
I think the answer is that it shouldn't because the pin it referenced
doesn't exist, but when looking at the schematic I have to wonder if
there should be an interrupts property for dealing with "pgood"?
Cheers,
Conor.
> +
> + vddh-supply:
> + description:
> + Phandle to the regulator that provides the VDDH power supply.
> +
> + avdd-supply:
> + description:
> + Phandle to the regulator that provides the AVDD power supply.
> +
> + ldoin-supply:
> + description:
> + Optional 2.5V to 5.5V LDO input supply.
> +
> +required:
> + - compatible
> + - reg
> + - vddh-supply
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + regulator@30 {
> + compatible = "adi,max20830";
> + reg = <0x30>;
> + vddh-supply = <&vddh>;
> + };
> + };
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0a3991c10ade20dd79cc7d1bf2a1d307ba6bd19d..031c743e979521a92ed9ac67915c178ce31727bd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -15579,6 +15579,13 @@ F: Documentation/devicetree/bindings/hwmon/pmbus/adi,max17616.yaml
> F: Documentation/hwmon/max17616.rst
> F: drivers/hwmon/pmbus/max17616.c
>
> +MAX20830 HARDWARE MONITOR DRIVER
> +M: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
> +L: linux-hwmon@vger.kernel.org
> +S: Supported
> +W: https://ez.analog.com/linux-software-drivers
> +F: Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml
> +
> MAX2175 SDR TUNER DRIVER
> M: Ramesh Shanmugasundaram <rashanmu@gmail.com>
> L: linux-media@vger.kernel.org
>
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v7 1/3] dt-bindings: pinctrl: Add aspeed,ast2700-soc0-pinctrl
From: Conor Dooley @ 2026-04-16 15:54 UTC (permalink / raw)
To: Billy Tsai
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, Linus Walleij, Bartosz Golaszewski,
Ryan Chen, Andrew Jeffery, devicetree, linux-arm-kernel,
linux-aspeed, linux-kernel, openbmc, linux-gpio, linux-clk
In-Reply-To: <20260416-upstream_pinctrl-v7-1-d72762253163@aspeedtech.com>
[-- Attachment #1: Type: text/plain, Size: 5099 bytes --]
On Thu, Apr 16, 2026 at 03:29:43PM +0800, Billy Tsai wrote:
> Add a device tree binding for the pin controller found in the
> ASPEED AST2700 SoC0.
>
> The controller manages various peripheral functions such as eMMC, USB,
> VGA DDC, JTAG, and PCIe root complex signals.
>
> Describe the AST2700 SoC0 pin controller using standard pin multiplexing
> and configuration properties.
>
> Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
> ---
> .../pinctrl/aspeed,ast2700-soc0-pinctrl.yaml | 162 +++++++++++++++++++++
> 1 file changed, 162 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2700-soc0-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2700-soc0-pinctrl.yaml
> new file mode 100644
> index 000000000000..947f3cd09fcc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2700-soc0-pinctrl.yaml
> @@ -0,0 +1,162 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pinctrl/aspeed,ast2700-soc0-pinctrl.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ASPEED AST2700 SoC0 Pin Controller
> +
> +maintainers:
> + - Billy Tsai <billy_tsai@aspeedtech.com>
> +
> +description:
> + The AST2700 features a dual-SoC architecture with two interconnected SoCs,
> + each having its own System Control Unit (SCU) for independent pin control.
> + This pin controller manages the pin multiplexing for SoC0.
> +
> + The SoC0 pin controller manages pin functions including eMMC, VGA DDC,
> + dual USB3/USB2 ports (A and B), JTAG, and PCIe root complex interfaces.
> +
> +properties:
> + compatible:
> + const: aspeed,ast2700-soc0-pinctrl
> + reg:
> + maxItems: 1
> +
> +patternProperties:
> + '-state$':
> + type: object
> + allOf:
> + - $ref: pinmux-node.yaml#
> + - $ref: pincfg-node.yaml#
> +
> + additionalProperties: false
> +
> + properties:
> + function:
> + enum:
> + - EMMC
> + - JTAGDDR
> + - JTAGM0
> + - JTAGPCIEA
> + - JTAGPCIEB
> + - JTAGPSP
> + - JTAGSSP
> + - JTAGTSP
> + - JTAGUSB3A
> + - JTAGUSB3B
> + - PCIERC0PERST
> + - PCIERC1PERST
> + - TSPRSTN
> + - UFSCLKI
> + - USB2AD0
> + - USB2AD1
> + - USB2AH
> + - USB2AHP
> + - USB2AHPD0
> + - USB2AXH
> + - USB2AXH2B
> + - USB2AXHD1
> + - USB2AXHP
> + - USB2AXHP2B
> + - USB2AXHPD1
> + - USB2BD0
> + - USB2BD1
> + - USB2BH
> + - USB2BHP
> + - USB2BHPD0
> + - USB2BXH
> + - USB2BXH2A
> + - USB2BXHD1
> + - USB2BXHP
> + - USB2BXHP2A
> + - USB2BXHPD1
> + - USB3AXH
> + - USB3AXH2B
> + - USB3AXHD
> + - USB3AXHP
> + - USB3AXHP2B
> + - USB3AXHPD
> + - USB3BXH
> + - USB3BXH2A
> + - USB3BXHD
> + - USB3BXHP
> + - USB3BXHP2A
> + - USB3BXHPD
> + - VB
> + - VGADDC
> +
> + groups:
> + enum:
> + - EMMCCDN
> + - EMMCG1
> + - EMMCG4
> + - EMMCG8
> + - EMMCWPN
> + - JTAG0
> + - PCIERC0PERST
> + - PCIERC1PERST
> + - TSPRSTN
> + - UFSCLKI
> + - USB2A
> + - USB2AAP
> + - USB2ABP
> + - USB2ADAP
> + - USB2AH
> + - USB2AHAP
> + - USB2B
> + - USB2BAP
> + - USB2BBP
> + - USB2BDBP
> + - USB2BH
> + - USB2BHBP
> + - USB3A
> + - USB3AAP
> + - USB3ABP
> + - USB3B
> + - USB3BAP
> + - USB3BBP
> + - VB0
> + - VB1
> + - VGADDC
> + pins:
> + enum:
> + - AB13
> + - AB14
> + - AC13
> + - AC14
> + - AD13
> + - AD14
> + - AE13
> + - AE14
> + - AE15
> + - AF13
> + - AF14
> + - AF15
Why do you have groups and pins?
Is it valid in your device to have groups and pins in the same node?
> +
> + drive-strength:
> + enum: [3, 6, 8, 11, 16, 18, 20, 23, 30, 32, 33, 35, 37, 38, 39, 41]
> +
> + bias-disable: true
> + bias-pull-up: true
> + bias-pull-down: true
> +
> +required:
> + - compatible
> + - reg
> +
> +allOf:
> + - $ref: pinctrl.yaml#
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + pinctrl@400 {
> + compatible = "aspeed,ast2700-soc0-pinctrl";
> + reg = <0x400 0x318>;
> + emmc-state {
> + function = "EMMC";
> + groups = "EMMCG1";
> + };
> + };
>
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v6 10/21] dt-bindings: display: renesas,rzg2l-du: Add support for RZ/G3E SoC
From: Laurent Pinchart @ 2026-04-16 16:34 UTC (permalink / raw)
To: Tommaso Merciai
Cc: tomm.merciai, geert, linux-renesas-soc, biju.das.jz,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Michael Turquette, Stephen Boyd, Magnus Damm,
Tomi Valkeinen, dri-devel, devicetree, linux-kernel, linux-clk
In-Reply-To: <191a4bc7-f19e-4771-b70d-e54dd5506799@bp.renesas.com>
On Fri, Apr 10, 2026 at 03:21:44PM +0200, Tommaso Merciai wrote:
> On 4/9/26 15:24, Laurent Pinchart wrote:
> > On Thu, Apr 09, 2026 at 01:15:18PM +0200, Tommaso Merciai wrote:
> >> On 4/8/26 17:00, Laurent Pinchart wrote:
> >>> On Wed, Apr 08, 2026 at 04:44:48PM +0200, Tommaso Merciai wrote:
> >>>> On 4/8/26 16:16, Laurent Pinchart wrote:
> >>>>> On Wed, Apr 08, 2026 at 04:02:14PM +0200, Tommaso Merciai wrote:
> >>>>>> On 4/8/26 14:24, Laurent Pinchart wrote:
> >>>>>>> On Wed, Apr 08, 2026 at 12:36:55PM +0200, Tommaso Merciai wrote:
> >>>>>>>> The RZ/G3E SoC has 2 LCD controllers (LCDC), each containing a Frame
> >>>>>>>> Compression Processor (FCPVD), a Video Signal Processor (VSPD), and a
> >>>>>>>> Display Unit (DU).
> >>>>>>>>
> >>>>>>>> - LCDC0 supports DSI and LVDS (single or dual-channel) outputs.
> >>>>>>>> - LCDC1 supports DSI, LVDS (single-channel), and RGB outputs.
> >>>>>>>>
> >>>>>>>> Add a new SoC-specific compatible string 'renesas,r9a09g047-du'.
> >>>>>>>>
> >>>>>>>> Extend patternProperties from "^port@[0-1]$" to "^port@[0-3]$" to
> >>>>>>>> allow up to four output ports, and explicitly disable port@2 and port@3
> >>>>>>>> for existing SoCs that do not expose them.
> >>>>>>>>
> >>>>>>>> Describe the four output ports of the RZ/G3E DU:
> >>>>>>>>
> >>>>>>>> - port@0: DSI (available on both LCDC instances)
> >>>>>>>> - port@1: DPAD / parallel RGB (LCDC1 only)
> >>>>>>>> - port@2: LVDS channel 0 (LCDC0 only)
> >>>>>>>> - port@3: LVDS channel 1 (available on both LCDC instances)
> >>>>>>>>
> >>>>>>>> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> >>>>>>>> ---
> >>>>>>>> v5->v6:
> >>>>>>>> - Extend patternProperties from "^port@[0-1]$" to "^port@[0-3]$" and
> >>>>>>>> explicitly disable port@2 and port@3 for existing SoCs that do not expose
> >>>>>>>> them.
> >>>>>>>> - Reworked ports numbering + improved/fixed ports descriptions in the
> >>>>>>>> bindings documentation.
> >>>>>>>> - Improved commit body.
> >>>>>>>>
> >>>>>>>> v4->v5:
> >>>>>>>> - Dropped renesas,id property and updated bindings
> >>>>>>>> accordingly.
> >>>>>>>>
> >>>>>>>> v2->v3:
> >>>>>>>> - No changes.
> >>>>>>>>
> >>>>>>>> v2->v3:
> >>>>>>>> - No changes.
> >>>>>>>>
> >>>>>>>> v1->v2:
> >>>>>>>> - Use single compatible string instead of multiple compatible strings
> >>>>>>>> for the two DU instances, leveraging a 'renesas,id' property to
> >>>>>>>> differentiate between DU0 and DU1.
> >>>>>>>> - Updated commit message accordingly.
> >>>>>>>>
> >>>>>>>> .../bindings/display/renesas,rzg2l-du.yaml | 30 ++++++++++++++++++-
> >>>>>>>> 1 file changed, 29 insertions(+), 1 deletion(-)
> >>>>>>>>
> >>>>>>>> diff --git a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> >>>>>>>> index 5add3b832eab..32da0b5ec88c 100644
> >>>>>>>> --- a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> >>>>>>>> +++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> >>>>>>>> @@ -20,6 +20,7 @@ properties:
> >>>>>>>> - enum:
> >>>>>>>> - renesas,r9a07g043u-du # RZ/G2UL
> >>>>>>>> - renesas,r9a07g044-du # RZ/G2{L,LC}
> >>>>>>>> + - renesas,r9a09g047-du # RZ/G3E
> >>>>>>>> - renesas,r9a09g057-du # RZ/V2H(P)
> >>>>>>>> - items:
> >>>>>>>> - enum:
> >>>>>>>> @@ -61,7 +62,7 @@ properties:
> >>>>>>>> model-dependent. Each port shall have a single endpoint.
> >>>>>>>>
> >>>>>>>> patternProperties:
> >>>>>>>> - "^port@[0-1]$":
> >>>>>>>> + "^port@[0-3]$":
> >>>>>>>> $ref: /schemas/graph.yaml#/properties/port
> >>>>>>>> unevaluatedProperties: false
> >>>>>>>>
> >>>>>>>> @@ -103,6 +104,8 @@ allOf:
> >>>>>>>> port@0:
> >>>>>>>> description: DPI
> >>>>>>>> port@1: false
> >>>>>>>> + port@2: false
> >>>>>>>> + port@3: false
> >>>>>>>>
> >>>>>>>> required:
> >>>>>>>> - port@0
> >>>>>>>> @@ -119,6 +122,8 @@ allOf:
> >>>>>>>> description: DSI
> >>>>>>>> port@1:
> >>>>>>>> description: DPI
> >>>>>>>> + port@2: false
> >>>>>>>> + port@3: false
> >>>>>>>>
> >>>>>>>> required:
> >>>>>>>> - port@0
> >>>>>>>> @@ -135,9 +140,32 @@ allOf:
> >>>>>>>> port@0:
> >>>>>>>> description: DSI
> >>>>>>>> port@1: false
> >>>>>>>> + port@2: false
> >>>>>>>> + port@3: false
> >>>>>>>>
> >>>>>>>> required:
> >>>>>>>> - port@0
> >>>>>>>> + - if:
> >>>>>>>> + properties:
> >>>>>>>> + compatible:
> >>>>>>>> + contains:
> >>>>>>>> + const: renesas,r9a09g047-du
> >>>>>>>> + then:
> >>>>>>>> + properties:
> >>>>>>>> + ports:
> >>>>>>>> + properties:
> >>>>>>>> + port@0:
> >>>>>>>> + description: DSI
> >>>>>>>> + port@1:
> >>>>>>>> + description: DPAD
> >>>>>>>> + port@2:
> >>>>>>>> + description: LVDS, Channel 0
> >>>>>>>> + port@3:
> >>>>>>>> + description: LVDS, Channel 1
> >>>>>>>> +
> >>>>>>>> + required:
> >>>>>>>> + - port@0
> >>>>>>>> + - port@3
> >>>>>>>
> >>>>>>> Why are ports 1 and 2 not required ?
> >>>>>>
> >>>>>> About this we had a similar discussion on v5[0]
> >>>>>> We are using the same compatible and:
> >>>>>>
> >>>>>> - LCDC0 supports DSI and LVDS (single or dual-channel) outputs.
> >>>>>> |
> >>>>>> --> then has:
> >>>>>> port@0
> >>>>>> port@2
> >>>>>> port@3
> >>>>>>
> >>>>>>
> >>>>>> - LCDC1 supports DSI, LVDS (single-channel), and RGB outputs.
> >>>>>> |
> >>>>>> --> then has:
> >>>>>> port@0
> >>>>>> port@1
> >>>>>> port@3
> >>>>>
> >>>>> Ah yes, I forget there are two LCDC instances with different output
> >>>>> configurations.
> >>>>>
> >>>>> Something still looks a bit weird to me though. For LCDC1, which
> >>>>> supports a single LVDS channel, you use the port described as the second
> >>>>> LVDS channel. Is there a reason not to use port@2 ?
> >>>>
> >>>> 9.11 Low Voltage Differential Signaling (LVDS)
> >>>> 9.11.1.2 Block Diagram
> >>>> Figure 9.11-1 shows a block diagram of LVDS.
> >>>>
> >>>> LCDC1 is connected to LVDS, Channel 1
> >>>> For this reason I'm using port@3.
> >>>
> >>> Re-reading that, I think I've misinterpreted the hardware architecture.
> >>> Doesn't the DU have a single output, that is connected the multiple
> >>> encoders (LVDS and DSI for LCDC0 and LVDS, DSI and DPI for LCDC1) ? It
> >>> seems modelling it with a single port and multiple endpoints would
> >>> better match the device.
> >>>
> >>> For LVDS in particular, I see a single LVDS encoder with two channels,
> >>> so there should not be two LVDS output ports in the DU. The two ports
> >>> should be on the output of the LVDS device.
> >>
> >> You are suggesting the following dt architecture:
> >>
> >> du0: display@16460000 {
> >> compatible = "renesas,r9a09g047-du";
> >> reg = <0 0x16460000 0 0x10000>;
> >> interrupts = <GIC_SPI 882 IRQ_TYPE_LEVEL_HIGH>;
> >> clocks = <&cpg CPG_MOD 0xed>,
> >> <&cpg CPG_MOD 0xee>,
> >> <&cpg CPG_MOD 0xef>;
> >> clock-names = "aclk", "pclk", "vclk";
> >> power-domains = <&cpg>;
> >> resets = <&cpg 0xdc>;
> >> renesas,vsps = <&vspd0 0>;
> >> status = "disabled";
> >>
> >> port {
> >> du0_out_dsi: endpoint@0 {
> >> reg = <0>;
> >> };
> >>
> >> du0_out_lvds0: endpoint@2 {
> >> reg = <2>;
> >> };
> >>
> >> du0_out_lvds1: endpoint@3 {
> >> reg = <3>;
> >> };
> >> }
> >> };
> >>
> >> du1: display@16490000 {
> >> compatible = "renesas,r9a09g047-du";
> >> reg = <0 0x16490000 0 0x10000>;
> >> interrupts = <GIC_SPI 922 IRQ_TYPE_LEVEL_HIGH>;
> >> clocks = <&cpg CPG_MOD 0x1a8>,
> >> <&cpg CPG_MOD 0x1a9>,
> >> <&cpg CPG_MOD 0x1aa>;
> >> clock-names = "aclk", "pclk", "vclk";
> >> power-domains = <&cpg>;
> >> resets = <&cpg 0x11e>;
> >> renesas,vsps = <&vspd1 0>;
> >> status = "disabled";
> >>
> >> port {
> >> du1_out_dsi: endpoint@0 {
> >> reg = <0>;
> >> };
> >>
> >> du1_out_rgb: endpoint@1 {
> >> reg = <1>;
> >> };
> >>
> >> du1_out_lvds1: endpoint@3 {
> >> reg = <3>;
> >> };
> >> }
> >> };
> >>
> >>
> >> Please correct me if I'm wrong.
> >
> > That's right. It would match the hardware, or at least my understanding
> > of the hardware based on the documentation. As far as I can tell, each
> > DU has a single 24-bit output port connected to multiple encoders.
>
> Thanks for the clarification.
>
> I want to make sure I understand the intended architecture correctly,
> because I see a potential conflict between your feedback on the two patches.
>
> For [1], you confirmed the two separate DU nodes (DU0 and DU1) with the
> single-port/multi-endpoint model. That maps to two separate platform
> devices, which means two separate DRM devices.
Not necessarily, it would be possible to instantiate a single drm_device
to cover both platform_device instances. It would require a bit of
manual work in the driver though.
> For [2], you suggested:
>
> "you can have one DRM device that covers two LCDCs, with one CRTC each,
> both connected to the same DSI encoder. Userspace then selects which
> CRTC drives which connector."
>
> Please correct me if I'm wrong but to me these two appear to be
> incompatible. With two separate DRM devices,the DSI encoder and its
> connector can only belong to one of them. Userspace cannot select
> between CRTCs across two DRM devices.
>
> To support the single-DRM-device model you describe, both DU0 and DU1
> would need to be managed by a single driver instance, similar to R-Car
> DU which aggregate multiple LCDC channels into one DRM device.
>
> Using a single DRM device that spawn 2 crtc (1 du dt node ) this use
> case can be tested with the following cmds:
>
> modetest -M rzg2l-du -s 58@55:800x600-56.25@XR24
> modetest -M rzg2l-du -s 58@56:800x600-56.25@XR24
>
> Could you clarify which architecture is the intended direction?
>
> Option A: Two separate DRM devices (2 DU dt nodes, current approach),
> with the DSI input selected via DT configuration.
> The dynamic vclk selection I implemented still applies,
> but runtime CRTC switching from userspace is not possible.
>
> Option B: A single DRM device aggregating both DU instances (1 DU dt node),
> with two CRTCs both connected to the DSI encoder.
I meant option B.
> [1] https://patchwork.kernel.org/project/linux-renesas-soc/patch/8f814f22ff62dcde6153260e2c8c29a5415c9a89.1775636898.git.tommaso.merciai.xr@bp.renesas.com/
> [2] https://patchwork.kernel.org/project/linux-renesas-soc/patch/9e0f64dd5e1efb0d27219416121c91a19da96ebd.1775636898.git.tommaso.merciai.xr@bp.renesas.com/
>
> >>>>>> Then port@1 is required for DU1 but not for DU0.
> >>>>>> Same port@2 is required for DU0 but not for DU1.
> >>>>>>
> >>>>>> [0] https://patchwork.kernel.org/project/linux-renesas-soc/patch/ca022fdbba5236c36e0cb3095db4c31e8e0cb1b8.1770996493.git.tommaso.merciai.xr@bp.renesas.com/
> >>>>>>
> >>>>>>>>
> >>>>>>>> examples:
> >>>>>>>> # RZ/G2L DU
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH RFC 06/10] arm64: dts: qcom: msm8939-asus-z00t: add Venus
From: Erikas Bitovtas @ 2026-04-16 16:57 UTC (permalink / raw)
To: Konrad Dybcio, Bryan O'Donoghue, Vikash Garodia,
Dikshita Agarwal, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, André Apitzsch,
Bjorn Andersson, Konrad Dybcio, Michael Turquette, Stephen Boyd
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel, linux-clk,
~postmarketos/upstreaming, phone-devel
In-Reply-To: <0a5f9bd6-d3ea-4819-8be3-cc5a06ec0339@oss.qualcomm.com>
On 4/16/26 6:17 PM, Konrad Dybcio wrote:
> On 4/16/26 3:43 PM, Erikas Bitovtas wrote:
>> Enable Venus video encoder/decoder for Asus ZenFone 2 Laser/Selfie.
>>
>> Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
>> ---
>> arch/arm64/boot/dts/qcom/msm8939-asus-z00t.dts | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/msm8939-asus-z00t.dts b/arch/arm64/boot/dts/qcom/msm8939-asus-z00t.dts
>> index 90e966242720..231a3e9c1929 100644
>> --- a/arch/arm64/boot/dts/qcom/msm8939-asus-z00t.dts
>> +++ b/arch/arm64/boot/dts/qcom/msm8939-asus-z00t.dts
>> @@ -267,6 +267,14 @@ &usb_hs_phy {
>> extcon = <&usb_id>;
>> };
>>
>> +&venus {
>> + status = "okay";
>
> You need a firmware path here
When I tested Venus on my device, it loaded without one specified -
msm-firmware-loader creates a symbolic link from modem partition for
firmware. Additionally, none of the MSM8916 devices seem to include a
firmware name. Has something changed since then?
> Konrad
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox