* 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 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
* [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 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 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
* 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
* 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 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 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 6/6] arm64: defconfig: make Tegra238 and Tegra264 Pinctrl a loadable module
From: Thierry Reding @ 2026-04-16 14:30 UTC (permalink / raw)
To: Jon Hunter
Cc: Krzysztof Kozlowski, 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>
[-- Attachment #1: Type: text/plain, Size: 2568 bytes --]
On Mon, Apr 13, 2026 at 10:49:50AM +0100, Jon Hunter wrote:
>
> On 10/04/2026 09:25, Jon Hunter wrote:
> >
> >
> > On 10/04/2026 07:37, Krzysztof Kozlowski wrote:
> > > On 09/04/2026 15:13, pshete@nvidia.com wrote:
> > > > From: Prathamesh Shete <pshete@nvidia.com>
> > > >
> > > > Building the Pinctrl driver into the kernel image increases its size.
> > >
> > > That's obvious.
> > >
> > > > These drivers are not required during early boot, build them as
> > > > a loadable
> > > > module instead to reduce the kernel image size.
> > >
> > > So you replace built-in into module?
> > > >
> > > > Signed-off-by: Prathamesh Shete <pshete@nvidia.com>
> > > > ---
> > > > arch/arm64/configs/defconfig | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> > > > 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 know some people have objected to this type of construct in the past
because it means that you automatically enable these drivers in configs
where it previously wasn't, bloating people's test builds, etc.
I also know that people don't like it when we add seemingly random
options to defconfig.
For this particular case, given that the options are dependent on the
per-SoC Kconfig symbols I think the "default m" above is a fair
compromise.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 5/9] ASoC: mediatek: mt2701: add HDMI audio memif, FE and BE DAIs
From: Mark Brown @ 2026-04-16 14:23 UTC (permalink / raw)
To: Daniel Golle
Cc: Liam Girdwood, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Jaroslav Kysela,
Takashi Iwai, Cyril Chao, Arnd Bergmann, Kuninori Morimoto,
Nícolas F. R. A. Prado, Eugen Hristev, linux-sound,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <975f39291cffc5d3f201d2ec7fdc2cfdd1fed6aa.1776265610.git.daniel@makrotopia.org>
[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]
On Wed, Apr 15, 2026 at 04:23:59PM +0100, Daniel Golle wrote:
> Extend the MT2701/MT7623N AFE driver with the HDMI playback path:
> +static int mt2701_afe_hdmi_hw_params(struct snd_pcm_substream *substream,
> + struct snd_pcm_hw_params *params,
> + struct snd_soc_dai *dai)
> +{
> + /* Channel count into the HDMI output memif (bits [7:4]). */
> + regmap_update_bits(afe->regmap, AFE_HDMI_OUT_CON0,
> + 0x000000f0, channels << 4);
Are the other fields guaranteed to be already set up properly?
> + /*
> + * 8-channel I2S framing: standard I2S, 32-bit slots,
> + * LRCK/BCK inverted. The wire protocol is fixed.
> + */
> + regmap_update_bits(afe->regmap, AFE_8CH_I2S_OUT_CON,
> + AFE_8CH_I2S_OUT_CON_WLEN_MASK |
> + AFE_8CH_I2S_OUT_CON_I2S_DELAY |
> + AFE_8CH_I2S_OUT_CON_LRCK_INV |
> + AFE_8CH_I2S_OUT_CON_BCK_INV,
> + AFE_8CH_I2S_OUT_CON_WLEN_32BIT |
> + AFE_8CH_I2S_OUT_CON_I2S_DELAY |
> + AFE_8CH_I2S_OUT_CON_LRCK_INV |
> + AFE_8CH_I2S_OUT_CON_BCK_INV);
Does this need suspend/resume handling?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v3] rtc: bq32000: add configurable delay between RTC reads
From: Adriana Stancu @ 2026-04-16 14:21 UTC (permalink / raw)
To: alexandre.belloni
Cc: linux-rtc, devicetree, linux-kernel, robh, krzk+dt, conor+dt,
Adriana Stancu
When the RTC is used on systems without a interrupt line, userspace
tools like `hwclock` fall back to a frequent polling loop to synchronize
with the edge of the next second.
On the BQ32000, this aggressive polling can temporarly lock the register
refresh cycle, because the continuous transfers prevent the hardware from
updating the buffer. This results in stale data reads or select() timeouts
in userspace.
This patch introduces a delay before reading the RTC registers in order to
provide a sufficient idle time for the hardware to sync with the register
buffer.
Signed-off-by: Adriana Stancu <adriana@arista.com>
---
drivers/rtc/rtc-bq32k.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/rtc/rtc-bq32k.c b/drivers/rtc/rtc-bq32k.c
index 7ad34539be4d..edce95eb328f 100644
--- a/drivers/rtc/rtc-bq32k.c
+++ b/drivers/rtc/rtc-bq32k.c
@@ -16,6 +16,7 @@
#include <linux/kstrtox.h>
#include <linux/errno.h>
#include <linux/bcd.h>
+#include <linux/delay.h>
#define BQ32K_SECONDS 0x00 /* Seconds register address */
#define BQ32K_SECONDS_MASK 0x7F /* Mask over seconds value */
@@ -89,9 +90,17 @@ static int bq32k_write(struct device *dev, void *data, uint8_t off, uint8_t len)
static int bq32k_rtc_read_time(struct device *dev, struct rtc_time *tm)
{
+ struct i2c_client *client = to_i2c_client(dev);
struct bq32k_regs regs;
int error;
+ /*
+ * When the device doesn't have the interrupt connected, prevent
+ * userpace from polling the RTC registers to frequently.
+ */
+ if (client->irq <= 0)
+ usleep_range(2000, 2500);
+
error = bq32k_read(dev, ®s, 0, sizeof(regs));
if (error)
return error;
--
2.51.0
^ permalink raw reply related
* Re: [PATCH 1/5] dt-bindings: interrupt-controller: Add support for secure donated SGIs
From: Rob Herring @ 2026-04-16 14:02 UTC (permalink / raw)
To: Sudeep Holla
Cc: Krzysztof Kozlowski, Conor Dooley, Marc Zyngier, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260416-true-prophetic-centipede-3ad8e5@sudeepholla>
On Thu, Apr 16, 2026 at 8:09 AM Sudeep Holla <sudeep.holla@kernel.org> wrote:
>
> On Thu, Apr 16, 2026 at 07:11:46AM -0500, Rob Herring wrote:
> > On Sun, Apr 12, 2026 at 06:04:37PM +0100, Sudeep Holla wrote:
> > > In GICv3, SGI security is defined by interrupt grouping and configuration
> > > rather than by SGI number alone. Linux conventionally reserves SGIs 0-7
> > > for non-secure internal kernel IPIs, while higher SGIs is assumed to be
> > > owned/stolen by the Secure world unless explicitly made available.
> > >
> > > Document secure donated SGI interrupt specifiers for the GICv3 binding.
> > > It describes "arm,secure-donated-ns-sgi-ranges" for SGIs donated by the
> > > secure world to non-secure software. It excludes SGIs 0-7, which are
> > > already used by the kernel for internal IPI purposes.
> > >
> > > Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
> > > ---
> > > .../bindings/interrupt-controller/arm,gic-v3.yaml | 27 +++++++++++++++++++++-
> > > include/dt-bindings/interrupt-controller/arm-gic.h | 1 +
> > > 2 files changed, 27 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
> > > index bfd30aae682b..664727d071c9 100644
> > > --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
> > > +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
> > > @@ -45,17 +45,24 @@ description: |
> > >
> > > The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
> > > interrupts, 2 for interrupts in the Extended SPI range, 3 for the
> > > - Extended PPI range. Other values are reserved for future use.
> > > + Extended PPI range, and 4 for SGI interrupts. Other values are
> > > + reserved for future use.
> > >
> > > The 2nd cell contains the interrupt number for the interrupt type.
> > > SPI interrupts are in the range [0-987]. PPI interrupts are in the
> > > range [0-15]. Extended SPI interrupts are in the range [0-1023].
> > > Extended PPI interrupts are in the range [0-127].
> > >
> > > + SGI interrupts are in the range [8-15] which overlaps with the SGIs
> > > + assigned to/reserved for the secure world but donated to the non
> > > + secure world to use. Refer "arm,secure-donated-ns-sgi-ranges" for
> > > + more details.
> > > +
> > > The 3rd cell is the flags, encoded as follows:
> > > bits[3:0] trigger type and level flags.
> > > 1 = edge triggered
> > > 4 = level triggered
> > > + SGIs are edge triggered and must be described as such.
> > >
> > > The 4th cell is a phandle to a node describing a set of CPUs this
> > > interrupt is affine to. The interrupt must be a PPI, and the node
> > > @@ -136,6 +143,24 @@ description: |
> > > - $ref: /schemas/types.yaml#/definitions/uint32
> > > - $ref: /schemas/types.yaml#/definitions/uint64
> > >
> > > + arm,secure-donated-ns-sgi-ranges:
> > > + description:
> > > + A list of pairs <sgi span>, where "sgi" is the first SGI INTID of a
> > > + range donated by the secure side to non-secure software, and "span" is
> > > + the size of that range. Multiple ranges can be provided.
> > > +
> > > + SGIs described by interrupt specifiers with type 4 (SGI) must fall
> > > + within one of these ranges. SGIs(0-7) reserved by non-secure world
> > > + for internal IPIs must not be listed here. "sgi" must be in the
> > > + range [8-15], "span" must be in the range [1-8], and the range must
> > > + not extend past SGI 15.
> > > + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> > > + items:
> >
> > As a matrix, you need:
> >
> > items:
> > items:
> > - ...
> > - ...
> >
> > However, given this is at most 8 entries, I would just do an array:
> >
> > minItems: 1
> > maxItems: 8
> > uniqueItems: true
> > items:
> > minimum: 8
> > maximum: 15
> >
>
> Makes sense.
>
> > Unless we need more flexibility in GICv5?
> >
>
> IIUC, there are not SGIs in GICv5 and we may need to use one software PPI
> as a replacement for SGIs. LPIs are used for IPIs.
>
> I am assuming Marc will soon post his opinion/rejection on this series 😉
> based on some offline discussion we had with respect to how it fits with
> GICv5.
>
> > Is there an example we can stick this property into so it gets tested?
> >
>
> Not sure if [1] serves as an example or you are looking for something else.
In the binding example, but don't add a whole new example for it.
Did [1] pass validation? If it did, it shouldn't have and I need to
investigate. If you didn't run it, then that would be the reason I
want it in the binding example.
Rob
^ permalink raw reply
* Re: [PATCH v7 00/15] arm64: dts: qcom: sdm845-lg: Improve hardware support in devicetree
From: Rob Herring @ 2026-04-16 13:55 UTC (permalink / raw)
To: Paul Sajna
Cc: Bjorn Andersson, Konrad Dybcio, Krzysztof Kozlowski, Conor Dooley,
David Heidelberg, linux-arm-msm, devicetree, linux-kernel,
phone-devel, ~postmarketos/upstreaming, Amir Dahan,
Christopher Brown, Konrad Dybcio, Dmitry Baryshkov, Pavel Machek
In-Reply-To: <20260331-judyln-dts-v7-0-87217b15fefb@postmarketos.org>
On Tue, Mar 31, 2026 at 08:15:05PM -0700, Paul Sajna wrote:
> Rollup of improved hardware support via devicetree for LG G7 ThinQ
> (judyln) from sdm845-mainline kernel fork
>
> Notably, this patch-series enables full DRM acceleration and wifi,
> among other small improvements in individual commits
>
> after this patch-series the main things that remain to be worked
> on include touchscreen, audio, and modem.
>
> Depends upon panel driver patch-series https://lore.kernel.org/all/20250910-judyln-panel-v1-1-825c74403bbb@postmarketos.org/T/#r9a976ca01e309b6c03100e984a26a0ffc2fe2002
Generally no one is going to look at nor apply a 7 month old series.
Anything not based on the current rc1 should be resent. Also, that's v1,
not v2 that you sent.
However, the .dts change was applied and now there's a warning and I
ended up here. So I've applied the binding change. You can resend the
driver changes if you want your display to work.
Rob
^ permalink raw reply
* Re: [PATCH RFC 00/10] media: qcom: venus: add MSM8939 support
From: Konrad Dybcio @ 2026-04-16 13:52 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-0-a09fcf2c23df@gmail.com>
On 4/16/26 3:43 PM, Erikas Bitovtas wrote:
> This patch series adds support for Venus on MSM8939. It is mostly
> similar to MSM8916 Venus, except it needs two additional cores to be
> powered on before it can start decoding.
>
> This patch series is marked as an RFC. Before submitting a non-RFC
> series, I would like to have some details clarified regarding how Venus
> works in order to improve and eventually upstream support for MSM8939.
>
> 1. In downstream, particularly in LA.BR.1.2.9.1_rb1.5, the buses
> for vcodec0 cores have only decoding bits enabled, as depicted
> by qcom,bus-configs property of qcom,msm-bus-clients children
> in qcom,vidc node. Do I understand correctly that these cores
> are only needed for decoding, and not for encoding?
> 2. Currently in device tree there is a video-decoder subnode for Venus
> node, however, for SDM845-v2 (and newer) chipsets, Venus does not use
> subnodes. Does this mean it should be dropped for MSM8939 as well?
> 3. MSM8939 supports HEVC decoding, however, as the patchset is written
> now, it does not work. It can be enabled, however, it will result in
> breakage of Venus for faulty MSM8916 firmwares, because the code
> disabling HEVC for HFI v1 needs to be removed, and as per commit
> c50cc6dc6c48 ("media: venus: hfi_parser: Ignore HEVC encoding for V1"),
> this would break support for some MSM8916 devices. What could be the
> best way to work around this?
if (!device_is_compatible(core->dev, "qcom,msm8939-venus"))?
Also, you mentioned HEVC *de*coding, while the commit you pointed to
disables *en*coding (decoding had been already disabled prior to that
commit)
Konrad
^ permalink raw reply
* Re: [PATCH 03/10] mfd: qcom_rpm: add msm8960 QDSS clock resource
From: Konrad Dybcio @ 2026-04-16 13:49 UTC (permalink / raw)
To: Antony Kurniawan Soemardi, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel, phone-devel, Rudraksha Gupta
In-Reply-To: <71751331-651d-43aa-b30f-135cc62e8915@smankusors.com>
On 4/15/26 5:20 PM, Antony Kurniawan Soemardi wrote:
> On 4/14/2026 3:07 PM, Konrad Dybcio wrote:
>> On 4/14/26 10:06 AM, Konrad Dybcio wrote:
>>> On 4/13/26 8:55 PM, Antony Kurniawan Soemardi via B4 Relay wrote:
>>>> From: Antony Kurniawan Soemardi <linux@smankusors.com>
>>>>
>>>> msm8960 uses the same clock descriptor as apq8064 but lacked the
>>>
>>> This doesn't quite seem to be the case, some fields differ and
>>> apq8064 additionally has:
>>>
>>> QCOM_RPM_PM8821_SMPS1
>>> QCOM_RPM_PM8821_SMPS2
>>> QCOM_RPM_PM8821_LDO1
>>> QCOM_RPM_VDDMIN_GPIO
>>
>> Ah hmm, the MFD driver seems to provide *all* RPM resources..
>
> What I meant by "clock descriptor" in the commit message was
> specifically the subset corresponding to RPM managed clocks. From what I
> can tell based on downstream code, msm8960 and apq8064 seem to share the
> same set of RPM clocks, even though the overall resource lists differ.
>
> Is that understanding correct?
If that's struct msm_rpm_map_data on msm-3.x, then I see that 8x60 has:
+MSM_RPM_MAP(PLL_4, PLL_4, 1),
+MSM_RPM_MAP(SMI_CLK, SMI_CLK, 1),
While 8960 has:
-MSM_RPM_MAP(QDSS_CLK, QDSS_CLK, 1),
Konrad
^ permalink raw reply
* Re: [PATCH v2 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Uwe Kleine-König @ 2026-04-16 13:48 UTC (permalink / raw)
To: Andrea della Porta
Cc: linux-pwm, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Florian Fainelli, Broadcom internal kernel review list,
devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Naushir Patuck, Stanimir Varbanov, mbrugger
In-Reply-To: <aeC6U7D6TfWm8JPx@apocalypse>
[-- Attachment #1: Type: text/plain, Size: 3091 bytes --]
Hello Andrea,
one thing I forgot to ask: Is there a public reference manual covering
the hardware. If yes, please add a link at the top of the driver.
On Thu, Apr 16, 2026 at 12:30:43PM +0200, Andrea della Porta wrote:
> On 19:31 Fri 10 Apr , Uwe Kleine-König wrote:
> > I assume there is a glitch if I update two channels and the old
> > configuration of the first channel ends while I'm in the middle of
> > configuring the second?
>
> The configuration registers are per-channel but the update flag is global.
> I don't have details of the hw insights, my best guess is that anything that
> you set in the registers before updating the flag will take effect, so there
> should be no glitches.
Would be great if you could test that. (Something along the lines of:
configure a very short period and wait a bit to be sure the short
configuration is active. Configure something with a long period and wait
shortly to be sure that the long period started, then change the duty,
toggle the update bit and modify a 2nd channel without toggling update
again. Then check the output of the 2nd channel after the first
channel's period ended.
> > > + if (ticks > U32_MAX)
> > > + ticks = U32_MAX;
> > > + wfhw->period_ticks = ticks;
> >
> > What happens if wf->period_length_ns > 0 but ticks == 0?
>
> I've added a check, returning 1 to signal teh round-up, and a minimum tick of 1
> in this case.
Sounds good. Are you able to verify that there is no +1 missing in the
calculation, e.g. using 1 as register value really gives you a period of
1 tick and not 2?
> > > + if (wf->duty_offset_ns + wf->duty_length_ns >= wf->period_length_ns) {
> >
> > The maybe surprising effect here is that in the two cases
> >
> > wf->duty_offset_ns == wf->period_length_ns and wf->duty_length_ns == 0
> >
> > and
> >
> > wf->duty_length_ns == wf->period_length_ns and wf->duty_offset_ns == 0
> >
> > you're configuring inverted polarity. I doesn't matter technically
> > because the result is the same, but for consumers still using pwm_state
> > this is irritating. That's why pwm-stm32 uses inverted polarity only if
> > also wf->duty_length_ns and wf->duty_offset_ns are non-zero.
Please align to the pwm-stm32 algorithm (as of
https://patch.msgid.link/c5e7767cee821b5f6e00f95bd14a5e13015646fb.1776264104.git.u.kleine-koenig@baylibre.com)
here to decide when to select inverted polarity.
> > > + }
> > > +
> > > + return 0;
> > > +
> > > +err_disable_clk:
> > > + clk_disable_unprepare(rp1->clk);
> > > +
> > > + return ret;
> > > +}
> >
> > On remove you miss to balance the call to clk_prepare_enable() (if no
> > failed call to clk_prepare_enable() in rp1_pwm_resume() happend).
>
> Since this driver now exports a syscon, it's only builtin (=Y) so
> it cannot be unloaded.
> I've also avoided the .remove callback via .suppress_bind_attrs.
Oh no, please work cleanly here and make the driver unbindable. This
yields better code quality and also helps during development and
debugging.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH RFC 10/10] media: venus: add power domain enable logic for Venus cores
From: Erikas Bitovtas @ 2026-04-16 13:43 UTC (permalink / raw)
To: 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, Erikas Bitovtas
In-Reply-To: <20260416-msm8939-venus-rfc-v1-0-a09fcf2c23df@gmail.com>
Attach power domains for vdec and venc cores and power them up if a vdec
or venc session is started.
Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
---
drivers/media/platform/qcom/venus/pm_helpers.c | 121 ++++++++++++++++++++++++-
1 file changed, 119 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/pm_helpers.c b/drivers/media/platform/qcom/venus/pm_helpers.c
index cc21a4762188..713812421c44 100644
--- a/drivers/media/platform/qcom/venus/pm_helpers.c
+++ b/drivers/media/platform/qcom/venus/pm_helpers.c
@@ -246,6 +246,94 @@ static int load_scale_bw(struct venus_core *core)
return icc_set_bw(core->video_path, total_avg, total_peak);
}
+static int vcodec_domains_get_v1(struct venus_core *core, struct device *dev,
+ struct dev_pm_domain_list **pmdomains,
+ const char **pmdomain_names,
+ unsigned int pmdomains_num)
+{
+ int ret;
+ struct dev_pm_domain_attach_data vcodec_data = {
+ .pd_names = pmdomain_names,
+ .num_pd_names = pmdomains_num,
+ .pd_flags = PD_FLAG_NO_DEV_LINK,
+ };
+
+ if (!pmdomain_names)
+ return 0;
+
+ ret = devm_pm_domain_attach_list(dev, &vcodec_data, pmdomains);
+ return ret;
+}
+
+static int vdec_domains_attach(struct venus_core *core)
+{
+ struct device *dev = core->dev_dec;
+ const struct venus_resources *res = core->res;
+
+ return vcodec_domains_get_v1(core, dev, &core->vcodec0_pmdomains,
+ res->vcodec0_pmdomains,
+ res->vcodec0_pmdomains_num);
+}
+
+static int venc_domains_attach(struct venus_core *core)
+{
+ struct device *dev = core->dev_enc;
+ const struct venus_resources *res = core->res;
+
+ return vcodec_domains_get_v1(core, dev, &core->vcodec1_pmdomains,
+ res->vcodec1_pmdomains,
+ res->vcodec1_pmdomains_num);
+}
+
+static int vcodec_domains_enable_v1(struct venus_core *core,
+ struct dev_pm_domain_list *pmdomains,
+ unsigned int pmdomains_num)
+{
+ int i, ret;
+
+ if (!pmdomains)
+ return 0;
+
+ for (i = 0; i < pmdomains_num; i++) {
+ ret = pm_runtime_resume_and_get(pmdomains->pd_devs[i]);
+ if (ret)
+ goto err;
+ }
+
+ return ret;
+
+err:
+ while (i--)
+ pm_runtime_put_sync(pmdomains->pd_devs[i]);
+
+ return ret;
+}
+
+static int vdec_domains_get(struct venus_core *core)
+{
+ const struct venus_resources *res = core->res;
+
+ return vcodec_domains_enable_v1(core, core->vcodec0_pmdomains,
+ res->vcodec0_pmdomains_num);
+}
+
+static int venc_domains_get(struct venus_core *core)
+{
+ const struct venus_resources *res = core->res;
+
+ return vcodec_domains_enable_v1(core, core->vcodec1_pmdomains,
+ res->vcodec1_pmdomains_num);
+}
+
+static void vcodec_domains_put_v1(struct dev_pm_domain_list *pmdomains,
+ unsigned int pmdomains_num)
+{
+ unsigned int i = pmdomains_num;
+
+ while (i--)
+ pm_runtime_put_sync(pmdomains->pd_devs[i]);
+}
+
static int load_scale_v1(struct venus_inst *inst)
{
struct venus_core *core = inst->core;
@@ -331,6 +419,11 @@ static int core_power_v1(struct venus_core *core, int on)
static int vdec_get_v1(struct device *dev)
{
struct venus_core *core = dev_get_drvdata(dev);
+ int ret;
+
+ ret = vdec_domains_attach(core);
+ if (ret < 0)
+ return ret;
return vcodec_clks_get(core, dev, core->vcodec0_clks,
core->res->vcodec0_clks);
@@ -339,8 +432,18 @@ static int vdec_get_v1(struct device *dev)
static int vdec_power_v1(struct device *dev, int on)
{
struct venus_core *core = dev_get_drvdata(dev);
+ const struct venus_resources *res = core->res;
int ret = 0;
+ if (on == POWER_ON)
+ ret = vdec_domains_get(core);
+ else
+ vcodec_domains_put_v1(core->vcodec0_pmdomains,
+ res->vcodec0_pmdomains_num);
+
+ if (ret)
+ return ret;
+
if (on == POWER_ON)
ret = vcodec_clks_enable(core, core->vcodec0_clks);
else
@@ -352,6 +455,11 @@ static int vdec_power_v1(struct device *dev, int on)
static int venc_get_v1(struct device *dev)
{
struct venus_core *core = dev_get_drvdata(dev);
+ int ret;
+
+ ret = venc_domains_attach(core);
+ if (ret < 0)
+ return ret;
return vcodec_clks_get(core, dev, core->vcodec1_clks,
core->res->vcodec1_clks);
@@ -360,8 +468,17 @@ static int venc_get_v1(struct device *dev)
static int venc_power_v1(struct device *dev, int on)
{
struct venus_core *core = dev_get_drvdata(dev);
+ const struct venus_resources *res = core->res;
int ret = 0;
+ if (on == POWER_ON)
+ ret = venc_domains_get(core);
+ else
+ vcodec_domains_put_v1(core->vcodec1_pmdomains,
+ res->vcodec1_pmdomains_num);
+ if (ret)
+ return ret;
+
if (on == POWER_ON)
ret = vcodec_clks_enable(core, core->vcodec1_clks);
else
@@ -905,7 +1022,7 @@ static int venc_power_v4(struct device *dev, int on)
return ret;
}
-static int vcodec_domains_get(struct venus_core *core)
+static int vcodec_domains_get_v4(struct venus_core *core)
{
int ret;
struct device *dev = core->dev;
@@ -1023,7 +1140,7 @@ static int core_get_v4(struct venus_core *core)
if (ret)
return ret;
- ret = vcodec_domains_get(core);
+ ret = vcodec_domains_get_v4(core);
if (ret)
return ret;
--
2.53.0
^ permalink raw reply related
* [PATCH RFC 09/10] media: qcom: venus: Move HFI v3 venc and vdec methods to HFI v1
From: Erikas Bitovtas @ 2026-04-16 13:43 UTC (permalink / raw)
To: 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, Erikas Bitovtas
In-Reply-To: <20260416-msm8939-venus-rfc-v1-0-a09fcf2c23df@gmail.com>
Some Qualcomm SoCs which come with HFI v1 like MSM8909 and MSM8939 also
have dedicated cores for Venus, like in HFI v3. Move methods from HFI v3
to HFI v1 so they can be reused.
Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
---
drivers/media/platform/qcom/venus/pm_helpers.c | 66 +++++++++++++++++++-------
1 file changed, 48 insertions(+), 18 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/pm_helpers.c b/drivers/media/platform/qcom/venus/pm_helpers.c
index f0269524ac70..cc21a4762188 100644
--- a/drivers/media/platform/qcom/venus/pm_helpers.c
+++ b/drivers/media/platform/qcom/venus/pm_helpers.c
@@ -328,10 +328,56 @@ static int core_power_v1(struct venus_core *core, int on)
return ret;
}
+static int vdec_get_v1(struct device *dev)
+{
+ struct venus_core *core = dev_get_drvdata(dev);
+
+ return vcodec_clks_get(core, dev, core->vcodec0_clks,
+ core->res->vcodec0_clks);
+}
+
+static int vdec_power_v1(struct device *dev, int on)
+{
+ struct venus_core *core = dev_get_drvdata(dev);
+ int ret = 0;
+
+ if (on == POWER_ON)
+ ret = vcodec_clks_enable(core, core->vcodec0_clks);
+ else
+ vcodec_clks_disable(core, core->vcodec0_clks);
+
+ return ret;
+}
+
+static int venc_get_v1(struct device *dev)
+{
+ struct venus_core *core = dev_get_drvdata(dev);
+
+ return vcodec_clks_get(core, dev, core->vcodec1_clks,
+ core->res->vcodec1_clks);
+}
+
+static int venc_power_v1(struct device *dev, int on)
+{
+ struct venus_core *core = dev_get_drvdata(dev);
+ int ret = 0;
+
+ if (on == POWER_ON)
+ ret = vcodec_clks_enable(core, core->vcodec1_clks);
+ else
+ vcodec_clks_disable(core, core->vcodec1_clks);
+
+ return ret;
+}
+
static const struct venus_pm_ops pm_ops_v1 = {
.core_get = core_get_v1,
.core_put = core_put_v1,
.core_power = core_power_v1,
+ .vdec_get = vdec_get_v1,
+ .vdec_power = vdec_power_v1,
+ .venc_get = venc_get_v1,
+ .venc_power = venc_power_v1,
.load_scale = load_scale_v1,
};
@@ -351,14 +397,6 @@ vcodec_control_v3(struct venus_core *core, u32 session_type, bool enable)
writel(1, ctrl);
}
-static int vdec_get_v3(struct device *dev)
-{
- struct venus_core *core = dev_get_drvdata(dev);
-
- return vcodec_clks_get(core, dev, core->vcodec0_clks,
- core->res->vcodec0_clks);
-}
-
static int vdec_power_v3(struct device *dev, int on)
{
struct venus_core *core = dev_get_drvdata(dev);
@@ -376,14 +414,6 @@ static int vdec_power_v3(struct device *dev, int on)
return ret;
}
-static int venc_get_v3(struct device *dev)
-{
- struct venus_core *core = dev_get_drvdata(dev);
-
- return vcodec_clks_get(core, dev, core->vcodec1_clks,
- core->res->vcodec1_clks);
-}
-
static int venc_power_v3(struct device *dev, int on)
{
struct venus_core *core = dev_get_drvdata(dev);
@@ -405,9 +435,9 @@ static const struct venus_pm_ops pm_ops_v3 = {
.core_get = core_get_v1,
.core_put = core_put_v1,
.core_power = core_power_v1,
- .vdec_get = vdec_get_v3,
+ .vdec_get = vdec_get_v1,
.vdec_power = vdec_power_v3,
- .venc_get = venc_get_v3,
+ .venc_get = venc_get_v1,
.venc_power = venc_power_v3,
.load_scale = load_scale_v1,
};
--
2.53.0
^ permalink raw reply related
* [PATCH RFC 08/10] media: venus: move getting vdec and venc for later
From: Erikas Bitovtas @ 2026-04-16 13:43 UTC (permalink / raw)
To: 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, Erikas Bitovtas
In-Reply-To: <20260416-msm8939-venus-rfc-v1-0-a09fcf2c23df@gmail.com>
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 ++++++------
drivers/media/platform/qcom/venus/venc.c | 12 ++++++------
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/vdec.c b/drivers/media/platform/qcom/venus/vdec.c
index daa8f56610c7..a4aacf5e535b 100644
--- a/drivers/media/platform/qcom/venus/vdec.c
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -1792,12 +1792,6 @@ static int vdec_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, core);
- if (core->pm_ops->vdec_get) {
- ret = core->pm_ops->vdec_get(dev);
- if (ret)
- return ret;
- }
-
vdev = video_device_alloc();
if (!vdev)
return -ENOMEM;
@@ -1817,6 +1811,12 @@ static int vdec_probe(struct platform_device *pdev)
core->vdev_dec = vdev;
core->dev_dec = dev;
+ if (core->pm_ops->vdec_get) {
+ ret = core->pm_ops->vdec_get(dev);
+ if (ret)
+ return ret;
+ }
+
video_set_drvdata(vdev, core);
pm_runtime_set_autosuspend_delay(dev, 2000);
pm_runtime_use_autosuspend(dev);
diff --git a/drivers/media/platform/qcom/venus/venc.c b/drivers/media/platform/qcom/venus/venc.c
index bf53267cb68d..5f6844d3d9d0 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -1568,12 +1568,6 @@ static int venc_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, core);
- if (core->pm_ops->venc_get) {
- ret = core->pm_ops->venc_get(dev);
- if (ret)
- return ret;
- }
-
vdev = video_device_alloc();
if (!vdev)
return -ENOMEM;
@@ -1593,6 +1587,12 @@ static int venc_probe(struct platform_device *pdev)
core->vdev_enc = vdev;
core->dev_enc = dev;
+ if (core->pm_ops->venc_get) {
+ ret = core->pm_ops->venc_get(dev);
+ if (ret)
+ return ret;
+ }
+
video_set_drvdata(vdev, core);
pm_runtime_set_autosuspend_delay(dev, 2000);
pm_runtime_use_autosuspend(dev);
--
2.53.0
^ permalink raw reply related
* [PATCH RFC 07/10] clk: qcom: gcc-msm8939: mark Venus core GDSCs as hardware controlled
From: Erikas Bitovtas @ 2026-04-16 13:43 UTC (permalink / raw)
To: 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, Erikas Bitovtas
In-Reply-To: <20260416-msm8939-venus-rfc-v1-0-a09fcf2c23df@gmail.com>
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.
Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
---
drivers/clk/qcom/gcc-msm8939.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/clk/qcom/gcc-msm8939.c b/drivers/clk/qcom/gcc-msm8939.c
index 45193b3d714b..420997b00ae0 100644
--- a/drivers/clk/qcom/gcc-msm8939.c
+++ b/drivers/clk/qcom/gcc-msm8939.c
@@ -3664,6 +3664,7 @@ static struct clk_branch gcc_venus0_vcodec0_clk = {
static struct clk_branch gcc_venus0_core0_vcodec0_clk = {
.halt_reg = 0x4c02c,
+ .halt_check = BRANCH_HALT_SKIP,
.clkr = {
.enable_reg = 0x4c02c,
.enable_mask = BIT(0),
@@ -3681,6 +3682,7 @@ static struct clk_branch gcc_venus0_core0_vcodec0_clk = {
static struct clk_branch gcc_venus0_core1_vcodec0_clk = {
.halt_reg = 0x4c034,
+ .halt_check = BRANCH_HALT_SKIP,
.clkr = {
.enable_reg = 0x4c034,
.enable_mask = BIT(0),
@@ -3753,6 +3755,7 @@ static struct gdsc venus_core0_gdsc = {
.pd = {
.name = "venus_core0",
},
+ .flags = HW_CTRL,
.pwrsts = PWRSTS_OFF_ON,
};
@@ -3761,6 +3764,7 @@ static struct gdsc venus_core1_gdsc = {
.pd = {
.name = "venus_core1",
},
+ .flags = HW_CTRL,
.pwrsts = PWRSTS_OFF_ON,
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v11 2/4] crypto: spacc - Add SPAcc ahash support
From: Pavitrakumar Managutte @ 2026-04-16 13:44 UTC (permalink / raw)
To: Herbert Xu
Cc: linux-crypto, linux-kernel, devicetree, robh, conor+dt,
Ruud.Derwig, manjunath.hadli, adityak, navami.telsang, bhoomikak
In-Reply-To: <ad4iJhEM-ZwgadBh@gondor.apana.org.au>
Hi Herbert,
I have pushed the V12 patchset as per your inputs. Dropped SM3 for
now, added other code improvements.
Warm regards,
PK
On Tue, Apr 14, 2026 at 4:47 PM Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Tue, Apr 14, 2026 at 03:58:16PM +0530, Pavitrakumar Managutte wrote:
> > Hi Herbert,
> > If the above snip looks good, I can push that and some more code
> > clean-ups/improvements as part of V12 patchset. Do let me know.
> >
> > Below are the code fixes and improvements
> > 1. Multi-device safety handling - All packed up inside priv
> > 2. Minor code polishes
> > 3. memzero_explicit inside setkey, spacc_compute_xcbc_key etc.
> > 4. Algo registration clean-ups
>
> I would prefer if you left out sm3 for now. If it really mattered
> someone would move it to lib/crypto.
>
> Thanks,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>
^ permalink raw reply
* [PATCH RFC 06/10] arm64: dts: qcom: msm8939-asus-z00t: add Venus
From: Erikas Bitovtas @ 2026-04-16 13:43 UTC (permalink / raw)
To: 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, Erikas Bitovtas
In-Reply-To: <20260416-msm8939-venus-rfc-v1-0-a09fcf2c23df@gmail.com>
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";
+};
+
+&venus_mem {
+ status = "okay";
+};
+
&wcnss {
status = "okay";
};
--
2.53.0
^ permalink raw reply related
* [PATCH RFC 05/10] arm64: dts: qcom: msm8939-longcheer-l9100: Enable venus node
From: Erikas Bitovtas @ 2026-04-16 13:43 UTC (permalink / raw)
To: 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, Erikas Bitovtas
In-Reply-To: <20260416-msm8939-venus-rfc-v1-0-a09fcf2c23df@gmail.com>
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";
+};
+
+&venus_mem {
+ status = "okay";
+};
+
&wcnss {
status = "okay";
};
--
2.53.0
^ permalink raw reply related
* [PATCH RFC 04/10] arm64: dts: qcom: msm8939: Add venus node
From: Erikas Bitovtas @ 2026-04-16 13:43 UTC (permalink / raw)
To: 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, Erikas Bitovtas
In-Reply-To: <20260416-msm8939-venus-rfc-v1-0-a09fcf2c23df@gmail.com>
From: André Apitzsch <git@apitzsch.eu>
Add DT entries for the msm8939 venus encoder/decoder.
Signed-off-by: André Apitzsch <git@apitzsch.eu>
Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
---
arch/arm64/boot/dts/qcom/msm8939.dtsi | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8939.dtsi b/arch/arm64/boot/dts/qcom/msm8939.dtsi
index d4d7b0c9206c..b7cfd289d31c 100644
--- a/arch/arm64/boot/dts/qcom/msm8939.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8939.dtsi
@@ -1627,6 +1627,30 @@ opp-19200000 {
};
};
+ venus: video-codec@1d00000 {
+ compatible = "qcom,msm8939-venus";
+ reg = <0x01d00000 0xff000>;
+ interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&gcc GCC_VENUS0_VCODEC0_CLK>,
+ <&gcc GCC_VENUS0_AHB_CLK>,
+ <&gcc GCC_VENUS0_AXI_CLK>;
+ clock-names = "core", "iface", "bus";
+ power-domains = <&gcc VENUS_GDSC>;
+ iommus = <&apps_iommu 5>;
+ memory-region = <&venus_mem>;
+ status = "disabled";
+
+ 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>;
+ power-domain-names = "core0", "core1";
+ };
+ };
+
apps_iommu: iommu@1ef0000 {
compatible = "qcom,msm8916-iommu", "qcom,msm-iommu-v1";
reg = <0x01ef0000 0x3000>;
--
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