* [PATCH v14 2/7] qcom-tgu: Add TGU driver
From: Songwei Chai @ 2026-04-17 7:33 UTC (permalink / raw)
To: andersson, alexander.shishkin, mike.leach, konrad.dybcio,
suzuki.poulose, james.clark, krzk+dt, conor+dt
Cc: Songwei Chai, linux-kernel, linux-arm-kernel, linux-arm-msm,
coresight, devicetree, gregkh
In-Reply-To: <20260417073336.2712426-1-songwei.chai@oss.qualcomm.com>
Add driver to support device TGU (Trigger Generation Unit).
TGU is a Data Engine which can be utilized to sense a plurality of
signals and create a trigger into the CTI or generate interrupts to
processors. Add probe/enable/disable functions for tgu.
Signed-off-by: Songwei Chai <songwei.chai@oss.qualcomm.com>
Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
.../ABI/testing/sysfs-bus-amba-devices-tgu | 9 +
drivers/Makefile | 1 +
drivers/hwtracing/Kconfig | 2 +
drivers/hwtracing/qcom/Kconfig | 20 ++
drivers/hwtracing/qcom/Makefile | 3 +
drivers/hwtracing/qcom/tgu.c | 193 ++++++++++++++++++
drivers/hwtracing/qcom/tgu.h | 51 +++++
7 files changed, 279 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
create mode 100644 drivers/hwtracing/qcom/Kconfig
create mode 100644 drivers/hwtracing/qcom/Makefile
create mode 100644 drivers/hwtracing/qcom/tgu.c
create mode 100644 drivers/hwtracing/qcom/tgu.h
diff --git a/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu b/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
new file mode 100644
index 000000000000..f877a00fcaa5
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
@@ -0,0 +1,9 @@
+What: /sys/bus/amba/devices/<tgu-name>/enable_tgu
+Date: April 2026
+KernelVersion: 7.1
+Contact: Jinlong Mao <jinlong.mao@oss.qualcomm.com>, Songwei Chai <songwei.chai@oss.qualcomm.com>
+Description:
+ (RW) Set/Get the enable/disable status of TGU
+ Accepts only one of the 2 values - 0 or 1.
+ 0 : disable TGU.
+ 1 : enable TGU.
diff --git a/drivers/Makefile b/drivers/Makefile
index 53fbd2e0acdd..82b712a12a26 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -177,6 +177,7 @@ obj-$(CONFIG_RAS) += ras/
obj-$(CONFIG_USB4) += thunderbolt/
obj-$(CONFIG_CORESIGHT) += hwtracing/coresight/
obj-y += hwtracing/intel_th/
+obj-y += hwtracing/qcom/
obj-$(CONFIG_STM) += hwtracing/stm/
obj-$(CONFIG_HISI_PTT) += hwtracing/ptt/
obj-y += android/
diff --git a/drivers/hwtracing/Kconfig b/drivers/hwtracing/Kconfig
index 911ee977103c..8a640218eed8 100644
--- a/drivers/hwtracing/Kconfig
+++ b/drivers/hwtracing/Kconfig
@@ -7,4 +7,6 @@ source "drivers/hwtracing/intel_th/Kconfig"
source "drivers/hwtracing/ptt/Kconfig"
+source "drivers/hwtracing/qcom/Kconfig"
+
endmenu
diff --git a/drivers/hwtracing/qcom/Kconfig b/drivers/hwtracing/qcom/Kconfig
new file mode 100644
index 000000000000..5c94c75ffa39
--- /dev/null
+++ b/drivers/hwtracing/qcom/Kconfig
@@ -0,0 +1,20 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# QCOM specific hwtracing drivers
+#
+menu "Qualcomm specific hwtracing drivers"
+
+config QCOM_TGU
+ tristate "QCOM Trigger Generation Unit driver"
+ depends on ARCH_QCOM || COMPILE_TEST
+ depends on ARM_AMBA
+ help
+ This driver provides support for Trigger Generation Unit that is
+ used to detect patterns or sequences on a given set of signals.
+ TGU is used to monitor a particular bus within a given region to
+ detect illegal transaction sequences or slave responses. It is also
+ used to monitor a data stream to detect protocol violations and to
+ provide a trigger point for centering data around a specific event
+ within the trace data buffer.
+
+endmenu
diff --git a/drivers/hwtracing/qcom/Makefile b/drivers/hwtracing/qcom/Makefile
new file mode 100644
index 000000000000..5a0a868c1ea0
--- /dev/null
+++ b/drivers/hwtracing/qcom/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_QCOM_TGU) += tgu.o
diff --git a/drivers/hwtracing/qcom/tgu.c b/drivers/hwtracing/qcom/tgu.c
new file mode 100644
index 000000000000..49c8f710b931
--- /dev/null
+++ b/drivers/hwtracing/qcom/tgu.c
@@ -0,0 +1,193 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#include <linux/amba/bus.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/pm_runtime.h>
+
+#include "tgu.h"
+
+static void tgu_write_all_hw_regs(struct tgu_drvdata *drvdata)
+{
+ TGU_UNLOCK(drvdata->base);
+ /* Enable TGU to program the triggers */
+ writel(1, drvdata->base + TGU_CONTROL);
+ TGU_LOCK(drvdata->base);
+}
+
+static int tgu_enable(struct device *dev)
+{
+ struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
+
+ guard(spinlock)(&drvdata->lock);
+ drvdata->enabled = true;
+
+ tgu_write_all_hw_regs(drvdata);
+
+ return 0;
+}
+
+static void tgu_do_disable(struct tgu_drvdata *drvdata)
+{
+ TGU_UNLOCK(drvdata->base);
+ writel(0, drvdata->base + TGU_CONTROL);
+ TGU_LOCK(drvdata->base);
+
+ drvdata->enabled = false;
+}
+
+static void tgu_disable(struct device *dev)
+{
+ struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
+
+ guard(spinlock)(&drvdata->lock);
+ if (!drvdata->enabled)
+ return;
+
+ tgu_do_disable(drvdata);
+}
+
+static ssize_t enable_tgu_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
+ bool enabled;
+
+ guard(spinlock)(&drvdata->lock);
+ enabled = drvdata->enabled;
+
+ return sysfs_emit(buf, "%d\n", !!enabled);
+}
+
+/* enable_tgu_store - Configure Trace and Gating Unit (TGU) triggers. */
+static ssize_t enable_tgu_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf,
+ size_t size)
+{
+ struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
+ unsigned long val;
+ int ret;
+
+ ret = kstrtoul(buf, 0, &val);
+ if (ret || val > 1)
+ return -EINVAL;
+
+ if (val) {
+ scoped_guard(spinlock, &drvdata->lock) {
+ if (drvdata->enabled)
+ return -EBUSY;
+ }
+
+ ret = pm_runtime_resume_and_get(dev);
+ if (ret)
+ return ret;
+
+ ret = tgu_enable(dev);
+ if (ret) {
+ pm_runtime_put(dev);
+ return ret;
+ }
+ } else {
+ scoped_guard(spinlock, &drvdata->lock) {
+ if (!drvdata->enabled)
+ return -EINVAL;
+ }
+
+ tgu_disable(dev);
+ pm_runtime_put(dev);
+ }
+
+ return size;
+}
+static DEVICE_ATTR_RW(enable_tgu);
+
+static struct attribute *tgu_common_attrs[] = {
+ &dev_attr_enable_tgu.attr,
+ NULL,
+};
+
+static const struct attribute_group tgu_common_grp = {
+ .attrs = tgu_common_attrs,
+ NULL,
+};
+
+static const struct attribute_group *tgu_attr_groups[] = {
+ &tgu_common_grp,
+ NULL,
+};
+
+static int tgu_probe(struct amba_device *adev, const struct amba_id *id)
+{
+ struct device *dev = &adev->dev;
+ struct tgu_drvdata *drvdata;
+ int ret;
+
+ drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
+ if (!drvdata)
+ return -ENOMEM;
+
+ drvdata->dev = &adev->dev;
+ dev_set_drvdata(dev, drvdata);
+
+ drvdata->base = devm_ioremap_resource(dev, &adev->res);
+ if (IS_ERR(drvdata->base))
+ return PTR_ERR(drvdata->base);
+
+ spin_lock_init(&drvdata->lock);
+
+ ret = sysfs_create_groups(&dev->kobj, tgu_attr_groups);
+ if (ret) {
+ dev_err(dev, "failed to create sysfs groups: %d\n", ret);
+ return ret;
+ }
+
+ drvdata->enabled = false;
+
+ pm_runtime_put(&adev->dev);
+
+ return 0;
+}
+
+static void tgu_remove(struct amba_device *adev)
+{
+ struct device *dev = &adev->dev;
+
+ sysfs_remove_groups(&dev->kobj, tgu_attr_groups);
+
+ tgu_disable(dev);
+}
+
+static const struct amba_id tgu_ids[] = {
+ {
+ .id = 0x000f0e00,
+ .mask = 0x000fffff,
+ },
+ { 0, 0, NULL },
+};
+
+MODULE_DEVICE_TABLE(amba, tgu_ids);
+
+static struct amba_driver tgu_driver = {
+ .drv = {
+ .name = "qcom-tgu",
+ .suppress_bind_attrs = true,
+ },
+ .probe = tgu_probe,
+ .remove = tgu_remove,
+ .id_table = tgu_ids,
+};
+
+module_amba_driver(tgu_driver);
+
+MODULE_AUTHOR("Songwei Chai <songwei.chai@oss.qualcomm.com>");
+MODULE_AUTHOR("Jinlong Mao <jinlong.mao@oss.qualcomm.com>");
+MODULE_DESCRIPTION("Qualcomm Trigger Generation Unit driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/hwtracing/qcom/tgu.h b/drivers/hwtracing/qcom/tgu.h
new file mode 100644
index 000000000000..dd7533b9d735
--- /dev/null
+++ b/drivers/hwtracing/qcom/tgu.h
@@ -0,0 +1,51 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#ifndef _QCOM_TGU_H
+#define _QCOM_TGU_H
+
+/* Register addresses */
+#define TGU_CONTROL 0x0000
+#define TGU_LAR 0xfb0
+#define TGU_UNLOCK_OFFSET 0xc5acce55
+
+static inline void TGU_LOCK(void __iomem *addr)
+{
+ do {
+ /* Wait for things to settle */
+ mb();
+ writel_relaxed(0x0, addr + TGU_LAR);
+ } while (0);
+}
+
+static inline void TGU_UNLOCK(void __iomem *addr)
+{
+ do {
+ writel_relaxed(TGU_UNLOCK_OFFSET, addr + TGU_LAR);
+ /* Make sure everyone has seen this */
+ mb();
+ } while (0);
+}
+
+/**
+ * struct tgu_drvdata - Data structure for a TGU (Trigger Generator Unit)
+ * @base: Memory-mapped base address of the TGU device
+ * @dev: Pointer to the associated device structure
+ * @lock: Spinlock for handling concurrent access to private data
+ * @enabled: Flag indicating whether the TGU device is enabled
+ *
+ * This structure defines the data associated with a TGU device,
+ * including its base address, device pointers, clock, spinlock for
+ * synchronization, trigger data pointers, maximum limits for various
+ * trigger-related parameters, and enable status.
+ */
+struct tgu_drvdata {
+ void __iomem *base;
+ struct device *dev;
+ spinlock_t lock;
+ bool enabled;
+};
+
+#endif
--
2.34.1
^ permalink raw reply related
* [PATCH v14 1/7] dt-bindings: arm: Add support for Qualcomm TGU trace
From: Songwei Chai @ 2026-04-17 7:33 UTC (permalink / raw)
To: andersson, alexander.shishkin, mike.leach, konrad.dybcio,
suzuki.poulose, james.clark, krzk+dt, conor+dt
Cc: Songwei Chai, linux-kernel, linux-arm-kernel, linux-arm-msm,
coresight, devicetree, gregkh, Rob Herring
In-Reply-To: <20260417073336.2712426-1-songwei.chai@oss.qualcomm.com>
The Trigger Generation Unit (TGU) is designed to detect patterns or
sequences within a specific region of the System on Chip (SoC). Once
configured and activated, it monitors sense inputs and can detect a
pre-programmed state or sequence across clock cycles, subsequently
producing a trigger.
TGU configuration space
offset table
x-------------------------x
| |
| |
| | Step configuration
| | space layout
| coresight management | x-------------x
| registers | |---> | |
| | | | reserve |
| | | | |
|-------------------------| | |-------------|
| | | | priority[3] |
| step[7] |<-- | |-------------|
|-------------------------| | | | priority[2] |
| | | | |-------------|
| ... | |Steps region | | priority[1] |
| | | | |-------------|
|-------------------------| | | | priority[0] |
| |<-- | |-------------|
| step[0] |--------------------> | |
|-------------------------| | condition |
| | | |
| control and status | x-------------x
| space | | |
x-------------------------x |Timer/Counter|
| |
x-------------x
TGU Configuration in Hardware
The TGU provides a step region for user configuration, similar
to a flow chart. Each step region consists of three register clusters:
1.Priority Region: Sets the required signals with priority.
2.Condition Region: Defines specific requirements (e.g., signal A
reaches three times) and the subsequent action once the requirement is
met.
3.Timer/Counter (Optional): Provides timing or counting functionality.
Add a new tgu.yaml file to describe the bindings required to
define the TGU in the device trees.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Songwei Chai <songwei.chai@oss.qualcomm.com>
---
.../devicetree/bindings/arm/qcom,tgu.yaml | 71 +++++++++++++++++++
1 file changed, 71 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/qcom,tgu.yaml
diff --git a/Documentation/devicetree/bindings/arm/qcom,tgu.yaml b/Documentation/devicetree/bindings/arm/qcom,tgu.yaml
new file mode 100644
index 000000000000..76440f2497b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/qcom,tgu.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+# Copyright (c) 2025 Qualcomm Innovation Center, Inc. All rights reserved.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/qcom,tgu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Trigger Generation Unit - TGU
+
+description: |
+ The Trigger Generation Unit (TGU) is a Data Engine which can be utilized
+ to sense a plurality of signals and create a trigger into the CTI or
+ generate interrupts to processors. The TGU is like the trigger circuit
+ of a Logic Analyzer. The corresponding trigger logic can be realized by
+ configuring the conditions for each step after sensing the signal.
+ Once setup and enabled, it will observe sense inputs and based upon
+ the activity of those inputs, even over clock cycles, may detect a
+ preprogrammed state/sequence and then produce a trigger or interrupt.
+
+ The primary use case of the TGU is to detect patterns or sequences on a
+ given set of signals within some region to identify the issue in time
+ once there is abnormal behavior in the subsystem.
+
+maintainers:
+ - Mao Jinlong <jinlong.mao@oss.qualcomm.com>
+ - Songwei Chai <songwei.chai@oss.qualcomm.com>
+
+# Need a custom select here or 'arm,primecell' will match on lots of nodes
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,tgu
+ required:
+ - compatible
+
+properties:
+ compatible:
+ items:
+ - const: qcom,tgu
+ - const: arm,primecell
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: apb_pclk
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ tgu@10b0e000 {
+ compatible = "qcom,tgu", "arm,primecell";
+ reg = <0x10b0e000 0x1000>;
+
+ clocks = <&aoss_qmp>;
+ clock-names = "apb_pclk";
+ };
+...
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 2/2] riscv: ultrarisc: 8250_dw: support DP1000 uart
From: Jia Wang @ 2026-04-17 7:32 UTC (permalink / raw)
To: Andy Shevchenko
Cc: wangjia, Ilpo Järvinen, Greg Kroah-Hartman, Jiri Slaby,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-kernel,
linux-serial, linux-riscv, devicetree, Zhang Xincheng
In-Reply-To: <abfrDBeJrValJR9a@ashevche-desk.local>
On 2026-03-16 13:35 +0200, Andy Shevchenko wrote:
> On Mon, Mar 16, 2026 at 02:33:23PM +0800, Jia Wang via B4 Relay wrote:
>
> > The UART of DP1000 does not support automatic detection of
> > buffer size. skip_autocfg needs to be set to true
>
> Missed period at the end.
>
Thanks, I will fix the missing period.
>
> ...
>
> > +#define DW_UART_QUIRK_FIXED_TYPE BIT(6)
>
> Seems unrequired.
>
> But to make sure, can you elaborate what's going on here?
> What is the reads from UCV and CPR registers?
>
Apologies for the delayed response.
Our DW UART implementation on DP1000 does not provide the CPR/UCV capability
registers, and reads from both registers always return 0. As a result, the
autodetection logic in 8250_dw cannot obtain meaningful capability
information.
To handle this, the current approach is to skip autodetection and rely on
fixed configuration via a quirk.
If there is a preferred or more appropriate way to support DW UART instances
without CPR/UCV, I would be happy to adjust the implementation based on your
suggestions.
> --
> With Best Regards,
> Andy Shevchenko
>
>
>
Best Regards,
Jia Wang
^ permalink raw reply
* Re: [PATCH v2 6/6] ASoC: dt-bindings: renesas,fsi: add support for multiple clocks
From: Geert Uytterhoeven @ 2026-04-17 7:26 UTC (permalink / raw)
To: Bui Duc Phuc
Cc: Krzysztof Kozlowski, kuninori.morimoto.gx, broonie, lgirdwood,
robh, krzk+dt, conor+dt, geert+renesas, magnus.damm, perex, tiwai,
linux-sound, linux-renesas-soc, devicetree, linux-kernel
In-Reply-To: <CAABR9nF131G3K3-vUdaDwHuQ7MCCLd-VO5syLApE_qsn+J49kA@mail.gmail.com>
Hi Phuc,
On Fri, 17 Apr 2026 at 05:35, Bui Duc Phuc <phucduc.bui@gmail.com> wrote:
> > Where does this match the driver?
> > Usually the functional clock is called "fck".
>
> Regarding the clock name "own", I used it because of the following
> implementation in the current driver:
>
> clock->own = devm_clk_get(dev, NULL);
> if (IS_ERR(clock->own))
> return -EINVAL;
>
> The driver currently fetches the first clock in the list (index 0) and
> stores it in a variable named own.
> That is why I named it "own" in the DT bindings to match.
Thanks, I hadn't looked at variables names (I searched for "own"
including double quotes).
> However, I have noticed that other DTS files commonly use "fck" for
> the functional clock.
> Are you suggesting that I should also rename the variable from "own"
> to "fck" in the driver code ??
I think there is no need to rename the variable.
> For example:
>
> clocks = <&mstp2_clks R8A7740_CLK_SCIFA1>;
> clock-names = "fck";
>
> But from the hardware manual, MSTP refers to a "Module Stop Clock",
> not a "functional clock".
> So I'm not sure if using "fck" here is appropriate. Could you explain
> the reasoning behind calling this clock "fck"?
It is the main clock that needs to be enabled to make the device
function. This is independent from the notion of it being a
"Module Stop Clock" or not, and became sort of a convention.
> Regarding the FSI clocks, they can be categorized into two types:
> audio clocks and module clocks (which may include bus/bridge clocks).
> The driver itself does not explicitly handle the enabling/disabling of
> the module clock; it only manages the audio clocks.
> From my code tracing:
> At boot: The kernel automatically attaches the PM domain and
> prepares the clocks during device initialization.
> During playback (aplay): The FSI driver doesn't enable the module
> clock directly. Instead, it is handled via:
> genpd_runtime_resume -> pm_clk_resume -> clk_core_enable ->
> cpg_mstp_clock_endisable.
Correct. On most (all?) Renesas SoCs, devices are part of a clock
domain, and their functional clocks are managed by Runtime PM.
> Since this module clock is essential for register access, it must
> always be the first entry in the clocks property (index 0) so
> devm_clk_get(dev, NULL)
> can fetch it correctly, right?
It is not strictly needed to be the first clock, and mostly a relic of the past,
when clocks weren't accessed by name, but by index.
Also, many devices have only a single clock, so don't need a name.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v1 03/11] media: v4l2-isp: Add helper function to compute extended stats size
From: Jacopo Mondi @ 2026-04-17 7:15 UTC (permalink / raw)
To: Antoine Bouyer
Cc: julien.vuillaumier, alexi.birlinger, daniel.baluta, peng.fan,
frank.li, jacopo.mondi, laurent.pinchart, mchehab, robh, krzk+dt,
conor+dt, michael.riesch, anthony.mcgivern, linux-media,
linux-kernel, devicetree, imx, jai.luthra, paul.elder
In-Reply-To: <20260413160331.2611829-4-antoine.bouyer@nxp.com>
Hi Antoine
On Mon, Apr 13, 2026 at 06:03:23PM +0200, Antoine Bouyer wrote:
> v4l2-isp framework only supports extended buffer for generic ISP
> configuration. This patch adds simple helper function to compute the
> extended statistics buffer size, exactly the same as for extended
> parameters, except that it uses the `v4l2_isp_stats_block_header`
> structure definition to prevent conflict with the
> `v4l2_isp_params_block_header` one.
>
> Signed-off-by: Antoine Bouyer <antoine.bouyer@nxp.com>
> ---
> include/media/v4l2-isp.h | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/include/media/v4l2-isp.h b/include/media/v4l2-isp.h
> index f3a6d0edcb24..9a93a534e7b0 100644
> --- a/include/media/v4l2-isp.h
> +++ b/include/media/v4l2-isp.h
> @@ -27,6 +27,19 @@ struct vb2_buffer;
> #define v4l2_isp_params_buffer_size(max_params_size) \
> (offsetof(struct v4l2_isp_params_buffer, data) + (max_params_size))
>
> +/**
> + * v4l2_isp_stats_buffer_size - Calculate size of v4l2_isp_stats_buffer
> + * @max_stats_size: The total size of the ISP statistic blocks
> + *
> + * Users of the v4l2 extensible statistics buffers will have differing sized data
> + * arrays depending on their specific ISP blocks. Drivers and userspace will need
> + * to be able to calculate the appropriate size of the struct to accommodate all
> + * ISP statistics blocks provided by the platform.
> + * This macro provides a convenient tool for the calculation.
> + */
> +#define v4l2_isp_stats_buffer_size(max_stats_size) \
> + (offsetof(struct v4l2_isp_stats_buffer, data) + (max_stats_size))
> +
Should we do this or simply:
--- a/include/media/v4l2-isp.h
+++ b/include/media/v4l2-isp.h
@@ -15,17 +15,21 @@ struct device;
struct vb2_buffer;
/**
- * v4l2_isp_params_buffer_size - Calculate size of v4l2_isp_params_buffer
- * @max_params_size: The total size of the ISP configuration blocks
+ * v4l2_isp_buffer_size - Calculate size of v4l2_isp_buffer
+ * @max_size: The total size of the ISP configuration or statistics blocks
+ *
+ * Users of v4l2-isp will have differing sized data arrays for parameters and
+ * statistics, depending on their specific blocks. Drivers need to be able to
+ * calculate the appropriate size of the buffer to accommodate all ISP blocks
+ * supported by the platform. This macro provides a convenient tool for the
+ * calculation.
+ *
+ * The intended users of this function are drivers initializing the size
+ * of their metadata (parameters and statistics) buffers.
*
- * Users of the v4l2 extensible parameters will have differing sized data arrays
- * depending on their specific parameter buffers. Drivers and userspace will
- * need to be able to calculate the appropriate size of the struct to
- * accommodate all ISP configuration blocks provided by the platform.
- * This macro provides a convenient tool for the calculation.
*/
-#define v4l2_isp_params_buffer_size(max_params_size) \
- (offsetof(struct v4l2_isp_params_buffer, data) + (max_params_size))
+#define v4l2_isp_buffer_size(max_size) \
+ (offsetof(struct v4l2_isp_buffer, data) + (max_size))
(I wrote this before noticing your patch :)
> /**
> * v4l2_isp_params_validate_buffer_size - Validate a V4L2 ISP buffer sizes
> * @dev: the driver's device pointer
> --
> 2.51.0
>
^ permalink raw reply
* Re: [PATCH v2 2/6] ASoC: renesas: fsi: Fix hang by enabling SPU clock
From: Bui Duc Phuc @ 2026-04-17 7:11 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: broonie, lgirdwood, robh, krzk+dt, conor+dt, geert+renesas,
magnus.damm, perex, tiwai, linux-sound, linux-renesas-soc,
devicetree, linux-kernel
In-Reply-To: <87pl3yzabq.wl-kuninori.morimoto.gx@renesas.com>
Hi Morimoto-san,
> > I d> Since fsi_hw_startup() and fsi_hw_shutdown() are called from fsi_dai_trigger(),
> > I think this runs in an atomic context, but please correct me if I'm wrong.
> > If so, is it safe to call clk_prepare_enable() under guard(spinlock_irqsave)?
> > Since clk_prepare() can sleep, I’m wondering if this could potentially
> > cause a "scheduling while atomic" issue.
> >
> > Would it make more sense to move clk_prepare() to init time (in new
> > fsi_clk_init() ),
> > and only use clk_enable() / clk_disable() in the trigger path?
>
> I don't remember detail of SH-Mobile clock driver, but yes.
Thank you. I will update it in the next version.
Best Regards,
Phuc
^ permalink raw reply
* [PATCH v4 6/6] mfd: motorola-cpcap: add support for Mot CPCAP composition
From: Svyatoslav Ryhel @ 2026-04-17 7:11 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Pavel Machek, Svyatoslav Ryhel, David Lechner,
Tony Lindgren
Cc: linux-input, devicetree, linux-kernel, linux-leds
In-Reply-To: <20260417071106.21984-1-clamor95@gmail.com>
Add a MFD subdevice composition used in Tegra20 based Mot board
(Motorola Atrix 4G and Droid X2).
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/mfd/motorola-cpcap.c | 50 ++++++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/drivers/mfd/motorola-cpcap.c b/drivers/mfd/motorola-cpcap.c
index 516d1e33affa..fdec92f5c6b0 100644
--- a/drivers/mfd/motorola-cpcap.c
+++ b/drivers/mfd/motorola-cpcap.c
@@ -335,6 +335,54 @@ static const struct cpcap_chip_data cpcap_mapphone_data = {
.num_devices = ARRAY_SIZE(cpcap_mapphone_mfd_devices),
};
+/*
+ * The Mot board features a USB-PHY and charger similar to the ones in
+ * Mapphone; however, because Mot is based on Tegra20, it is incompatible
+ * with the existing implementation, which is tightly interconnected with
+ * the OMAP USB PHY.
+ */
+static const struct mfd_cell cpcap_mot_mfd_devices[] = {
+ {
+ .name = "cpcap_adc",
+ .of_compatible = "motorola,mot-cpcap-adc",
+ }, {
+ .name = "cpcap_battery",
+ .of_compatible = "motorola,cpcap-battery",
+ }, {
+ .name = "cpcap-regulator",
+ .of_compatible = "motorola,mot-cpcap-regulator",
+ }, {
+ .name = "cpcap-rtc",
+ .of_compatible = "motorola,cpcap-rtc",
+ }, {
+ .name = "cpcap-pwrbutton",
+ .of_compatible = "motorola,cpcap-pwrbutton",
+ }, {
+ .name = "cpcap-led",
+ .id = 0,
+ .of_compatible = "motorola,cpcap-led-red",
+ }, {
+ .name = "cpcap-led",
+ .id = 1,
+ .of_compatible = "motorola,cpcap-led-green",
+ }, {
+ .name = "cpcap-led",
+ .id = 2,
+ .of_compatible = "motorola,cpcap-led-blue",
+ }, {
+ .name = "cpcap-led",
+ .id = 3,
+ .of_compatible = "motorola,cpcap-led-adl",
+ }, {
+ .name = "cpcap-codec",
+ },
+};
+
+static const struct cpcap_chip_data cpcap_mot_data = {
+ .mfd_devices = cpcap_mot_mfd_devices,
+ .num_devices = ARRAY_SIZE(cpcap_mot_mfd_devices),
+};
+
static int cpcap_probe(struct spi_device *spi)
{
struct cpcap_ddata *cpcap;
@@ -389,6 +437,7 @@ static int cpcap_probe(struct spi_device *spi)
static const struct of_device_id cpcap_of_match[] = {
{ .compatible = "motorola,cpcap", .data = &cpcap_default_data },
{ .compatible = "motorola,mapphone-cpcap", .data = &cpcap_mapphone_data },
+ { .compatible = "motorola,mot-cpcap", .data = &cpcap_mot_data },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, cpcap_of_match);
@@ -396,6 +445,7 @@ MODULE_DEVICE_TABLE(of, cpcap_of_match);
static const struct spi_device_id cpcap_spi_ids[] = {
{ .name = "cpcap", .driver_data = (kernel_ulong_t)&cpcap_default_data },
{ .name = "mapphone-cpcap", .driver_data = (kernel_ulong_t)&cpcap_mapphone_data },
+ { .name = "mot-cpcap", .driver_data = (kernel_ulong_t)&cpcap_mot_data },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(spi, cpcap_spi_ids);
--
2.51.0
^ permalink raw reply related
* [PATCH v4 5/6] mfd: motorola-cpcap: diverge configuration per-board
From: Svyatoslav Ryhel @ 2026-04-17 7:11 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Pavel Machek, Svyatoslav Ryhel, David Lechner,
Tony Lindgren
Cc: linux-input, devicetree, linux-kernel, linux-leds
In-Reply-To: <20260417071106.21984-1-clamor95@gmail.com>
MFD have rigid subdevice structure which does not allow flexible dynamic
subdevice linking. Address this by diverging CPCAP subdevice composition
to take into account board specific configuration.
Create a common default subdevice composition, rename existing subdevice
composition into cpcap_mapphone_mfd_devices since it targets mainly
Mapphone board.
Removed st,6556002 as it is no longer applicable to all cases and
duplicates motorola,cpcap, which is used as the default composition.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/mfd/motorola-cpcap.c | 101 ++++++++++++++++++++++++++++-------
1 file changed, 83 insertions(+), 18 deletions(-)
diff --git a/drivers/mfd/motorola-cpcap.c b/drivers/mfd/motorola-cpcap.c
index d8243b956f87..516d1e33affa 100644
--- a/drivers/mfd/motorola-cpcap.c
+++ b/drivers/mfd/motorola-cpcap.c
@@ -12,6 +12,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/mod_devicetable.h>
+#include <linux/property.h>
#include <linux/regmap.h>
#include <linux/sysfs.h>
@@ -24,10 +25,16 @@
#define CPCAP_REGISTER_SIZE 4
#define CPCAP_REGISTER_BITS 16
+struct cpcap_chip_data {
+ const struct mfd_cell *mfd_devices;
+ unsigned int num_devices;
+};
+
struct cpcap_ddata {
struct spi_device *spi;
struct regmap_irq *irqs;
struct regmap_irq_chip_data *irqdata[CPCAP_NR_IRQ_CHIPS];
+ const struct cpcap_chip_data *cdata;
const struct regmap_config *regmap_conf;
struct regmap *regmap;
};
@@ -195,20 +202,6 @@ static int cpcap_init_irq(struct cpcap_ddata *cpcap)
return 0;
}
-static const struct of_device_id cpcap_of_match[] = {
- { .compatible = "motorola,cpcap", },
- { .compatible = "st,6556002", },
- {},
-};
-MODULE_DEVICE_TABLE(of, cpcap_of_match);
-
-static const struct spi_device_id cpcap_spi_ids[] = {
- { .name = "cpcap", },
- { .name = "6556002", },
- {},
-};
-MODULE_DEVICE_TABLE(spi, cpcap_spi_ids);
-
static const struct regmap_config cpcap_regmap_config = {
.reg_bits = 16,
.reg_stride = 4,
@@ -241,7 +234,56 @@ static int cpcap_resume(struct device *dev)
static DEFINE_SIMPLE_DEV_PM_OPS(cpcap_pm, cpcap_suspend, cpcap_resume);
-static const struct mfd_cell cpcap_mfd_devices[] = {
+static const struct mfd_cell cpcap_default_mfd_devices[] = {
+ {
+ .name = "cpcap_adc",
+ .of_compatible = "motorola,cpcap-adc",
+ }, {
+ .name = "cpcap_battery",
+ .of_compatible = "motorola,cpcap-battery",
+ }, {
+ .name = "cpcap-regulator",
+ .of_compatible = "motorola,cpcap-regulator",
+ }, {
+ .name = "cpcap-rtc",
+ .of_compatible = "motorola,cpcap-rtc",
+ }, {
+ .name = "cpcap-pwrbutton",
+ .of_compatible = "motorola,cpcap-pwrbutton",
+ }, {
+ .name = "cpcap-usb-phy",
+ .of_compatible = "motorola,cpcap-usb-phy",
+ }, {
+ .name = "cpcap-led",
+ .id = 0,
+ .of_compatible = "motorola,cpcap-led-red",
+ }, {
+ .name = "cpcap-led",
+ .id = 1,
+ .of_compatible = "motorola,cpcap-led-green",
+ }, {
+ .name = "cpcap-led",
+ .id = 2,
+ .of_compatible = "motorola,cpcap-led-blue",
+ }, {
+ .name = "cpcap-led",
+ .id = 3,
+ .of_compatible = "motorola,cpcap-led-adl",
+ }, {
+ .name = "cpcap-led",
+ .id = 4,
+ .of_compatible = "motorola,cpcap-led-cp",
+ }, {
+ .name = "cpcap-codec",
+ },
+};
+
+static const struct cpcap_chip_data cpcap_default_data = {
+ .mfd_devices = cpcap_default_mfd_devices,
+ .num_devices = ARRAY_SIZE(cpcap_default_mfd_devices),
+};
+
+static const struct mfd_cell cpcap_mapphone_mfd_devices[] = {
{
.name = "cpcap_adc",
.of_compatible = "motorola,mapphone-cpcap-adc",
@@ -285,7 +327,12 @@ static const struct mfd_cell cpcap_mfd_devices[] = {
.of_compatible = "motorola,cpcap-led-cp",
}, {
.name = "cpcap-codec",
- }
+ },
+};
+
+static const struct cpcap_chip_data cpcap_mapphone_data = {
+ .mfd_devices = cpcap_mapphone_mfd_devices,
+ .num_devices = ARRAY_SIZE(cpcap_mapphone_mfd_devices),
};
static int cpcap_probe(struct spi_device *spi)
@@ -297,6 +344,10 @@ static int cpcap_probe(struct spi_device *spi)
if (!cpcap)
return -ENOMEM;
+ cpcap->cdata = device_get_match_data(&spi->dev);
+ if (!cpcap->cdata)
+ return -ENODEV;
+
cpcap->spi = spi;
spi_set_drvdata(spi, cpcap);
@@ -331,10 +382,24 @@ static int cpcap_probe(struct spi_device *spi)
spi->dev.coherent_dma_mask = 0;
spi->dev.dma_mask = &spi->dev.coherent_dma_mask;
- return devm_mfd_add_devices(&spi->dev, 0, cpcap_mfd_devices,
- ARRAY_SIZE(cpcap_mfd_devices), NULL, 0, NULL);
+ return devm_mfd_add_devices(&spi->dev, 0, cpcap->cdata->mfd_devices,
+ cpcap->cdata->num_devices, NULL, 0, NULL);
}
+static const struct of_device_id cpcap_of_match[] = {
+ { .compatible = "motorola,cpcap", .data = &cpcap_default_data },
+ { .compatible = "motorola,mapphone-cpcap", .data = &cpcap_mapphone_data },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, cpcap_of_match);
+
+static const struct spi_device_id cpcap_spi_ids[] = {
+ { .name = "cpcap", .driver_data = (kernel_ulong_t)&cpcap_default_data },
+ { .name = "mapphone-cpcap", .driver_data = (kernel_ulong_t)&cpcap_mapphone_data },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(spi, cpcap_spi_ids);
+
static struct spi_driver cpcap_driver = {
.driver = {
.name = "cpcap-core",
--
2.51.0
^ permalink raw reply related
* [PATCH v4 4/6] dt-bindings: mfd: motorola-cpcap: document Mapphone and Mot CPCAP
From: Svyatoslav Ryhel @ 2026-04-17 7:11 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Pavel Machek, Svyatoslav Ryhel, David Lechner,
Tony Lindgren
Cc: linux-input, devicetree, linux-kernel, linux-leds
In-Reply-To: <20260417071106.21984-1-clamor95@gmail.com>
Add compatibles for Mapphone and Mot CPCAP subdevice compositions. Both
variations cannot use st,6556002 fallback since they may be based on
different controllers.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
---
.../devicetree/bindings/mfd/motorola,cpcap.yaml | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
index eea5b2efa80c..487e5456864b 100644
--- a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
+++ b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
@@ -14,9 +14,14 @@ allOf:
properties:
compatible:
- items:
- - const: motorola,cpcap
- - const: st,6556002
+ oneOf:
+ - enum:
+ - motorola,mapphone-cpcap
+ - motorola,mot-cpcap
+
+ - items:
+ - const: motorola,cpcap
+ - const: st,6556002
reg:
maxItems: 1
--
2.51.0
^ permalink raw reply related
* [PATCH v4 3/6] dt-bindings: mfd: motorola-cpcap: convert to DT schema
From: Svyatoslav Ryhel @ 2026-04-17 7:11 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Pavel Machek, Svyatoslav Ryhel, David Lechner,
Tony Lindgren
Cc: linux-input, devicetree, linux-kernel, linux-leds
In-Reply-To: <20260417071106.21984-1-clamor95@gmail.com>
Convert devicetree bindings for the Motorola CPCAP MFD from TXT to YAML.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
---
.../bindings/mfd/motorola,cpcap.yaml | 411 ++++++++++++++++++
.../bindings/mfd/motorola-cpcap.txt | 78 ----
2 files changed, 411 insertions(+), 78 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
delete mode 100644 Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
diff --git a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
new file mode 100644
index 000000000000..eea5b2efa80c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
@@ -0,0 +1,411 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/motorola,cpcap.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Motorola CPCAP PMIC MFD
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ items:
+ - const: motorola,cpcap
+ - const: st,6556002
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ spi-max-frequency:
+ maximum: 9600000
+
+ spi-cs-high: true
+ spi-cpol: true
+ spi-cpha: true
+
+ adc:
+ $ref: /schemas/iio/adc/motorola,cpcap-adc.yaml
+
+ audio-codec:
+ type: object
+ additionalProperties: false
+
+ properties:
+ interrupts:
+ items:
+ - description: headset detect interrupt
+ - description: microphone bias 2 detect interrupt
+
+ interrupt-names:
+ items:
+ - const: hs
+ - const: mb2
+
+ "#sound-dai-cells":
+ const: 1
+
+ VAUDIO-supply:
+ description:
+ Codec power supply, usually VAUDIO regulator of CPCAP.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: port connected to the Stereo HiFi DAC
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: port connected to the Voice DAC
+
+ required:
+ - port@0
+ - port@1
+
+ required:
+ - interrupts
+ - interrupt-names
+ - "#sound-dai-cells"
+
+ battery:
+ $ref: /schemas/power/supply/cpcap-battery.yaml
+
+ charger:
+ $ref: /schemas/power/supply/cpcap-charger.yaml
+
+ key-power:
+ $ref: /schemas/input/motorola,cpcap-pwrbutton.yaml
+
+ phy:
+ $ref: /schemas/phy/motorola,cpcap-usb-phy.yaml
+
+ regulator:
+ $ref: /schemas/regulator/motorola,cpcap-regulator.yaml
+
+ rtc:
+ $ref: /schemas/rtc/motorola,cpcap-rtc.yaml
+
+patternProperties:
+ "^led(-[a-z]+)?$":
+ $ref: /schemas/leds/motorola,cpcap-leds.yaml
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/input/linux-event-codes.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpcap: pmic@0 {
+ compatible = "motorola,cpcap", "st,6556002";
+ reg = <0>; /* cs0 */
+
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_EDGE_RISING>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ spi-max-frequency = <3000000>;
+ spi-cs-high;
+
+ spi-cpol;
+ spi-cpha;
+
+ cpcap_adc: adc {
+ compatible = "motorola,cpcap-adc";
+
+ interrupt-parent = <&cpcap>;
+ interrupts = <8 IRQ_TYPE_NONE>;
+ interrupt-names = "adcdone";
+
+ #io-channel-cells = <1>;
+ };
+
+ cpcap_audio: audio-codec {
+ interrupt-parent = <&cpcap>;
+ interrupts = <9 IRQ_TYPE_NONE>, <10 IRQ_TYPE_NONE>;
+ interrupt-names = "hs", "mb2";
+
+ VAUDIO-supply = <&vdd_audio>;
+
+ #sound-dai-cells = <1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* HiFi */
+ port@0 {
+ reg = <0>;
+
+ cpcap_audio_codec0: endpoint {
+ };
+ };
+
+ /* Voice */
+ port@1 {
+ reg = <1>;
+
+ cpcap_audio_codec1: endpoint {
+ };
+ };
+ };
+ };
+
+ cpcap_battery: battery {
+ compatible = "motorola,cpcap-battery";
+
+ interrupt-parent = <&cpcap>;
+ interrupts = <6 IRQ_TYPE_NONE>, <5 IRQ_TYPE_NONE>,
+ <3 IRQ_TYPE_NONE>, <20 IRQ_TYPE_NONE>,
+ <54 IRQ_TYPE_NONE>, <57 IRQ_TYPE_NONE>;
+ interrupt-names = "eol", "lowbph", "lowbpl",
+ "chrgcurr1", "battdetb", "cccal";
+
+ io-channels = <&cpcap_adc 0>, <&cpcap_adc 1>,
+ <&cpcap_adc 5>, <&cpcap_adc 6>;
+ io-channel-names = "battdetb", "battp",
+ "chg_isense", "batti";
+ power-supplies = <&cpcap_charger>;
+ };
+
+ cpcap_charger: charger {
+ compatible = "motorola,mapphone-cpcap-charger";
+
+ interrupt-parent = <&cpcap>;
+ interrupts = <13 IRQ_TYPE_NONE>, <12 IRQ_TYPE_NONE>,
+ <29 IRQ_TYPE_NONE>, <28 IRQ_TYPE_NONE>,
+ <22 IRQ_TYPE_NONE>, <21 IRQ_TYPE_NONE>,
+ <20 IRQ_TYPE_NONE>, <19 IRQ_TYPE_NONE>,
+ <54 IRQ_TYPE_NONE>;
+ interrupt-names = "chrg_det", "rvrs_chrg", "chrg_se1b",
+ "se0conn", "rvrs_mode", "chrgcurr2",
+ "chrgcurr1", "vbusvld", "battdetb";
+
+ mode-gpios = <&gpio3 29 GPIO_ACTIVE_LOW>,
+ <&gpio3 23 GPIO_ACTIVE_LOW>;
+
+ io-channels = <&cpcap_adc 0>, <&cpcap_adc 1>,
+ <&cpcap_adc 2>, <&cpcap_adc 5>,
+ <&cpcap_adc 6>;
+ io-channel-names = "battdetb", "battp",
+ "vbus", "chg_isense",
+ "batti";
+ };
+
+ key-power {
+ compatible = "motorola,cpcap-pwrbutton";
+
+ interrupt-parent = <&cpcap>;
+ interrupts = <23 IRQ_TYPE_NONE>;
+ };
+
+ led-red {
+ compatible = "motorola,cpcap-led-red";
+ vdd-supply = <&vdd_led>;
+ label = "status-led::red";
+ };
+
+ led-green {
+ compatible = "motorola,cpcap-led-green";
+ vdd-supply = <&vdd_led>;
+ label = "status-led::green";
+ };
+
+ led-blue {
+ compatible = "motorola,cpcap-led-blue";
+ vdd-supply = <&vdd_led>;
+ label = "status-led::blue";
+ };
+
+ cpcap_usb2_phy: phy {
+ compatible = "motorola,cpcap-usb-phy";
+
+ pinctrl-0 = <&usb_gpio_mux_sel1>, <&usb_gpio_mux_sel2>;
+ pinctrl-1 = <&usb_ulpi_pins>;
+ pinctrl-2 = <&usb_utmi_pins>;
+ pinctrl-3 = <&uart3_pins>;
+ pinctrl-names = "default", "ulpi", "utmi", "uart";
+ #phy-cells = <0>;
+
+ interrupts-extended =
+ <&cpcap 15 IRQ_TYPE_NONE>, <&cpcap 14 IRQ_TYPE_NONE>,
+ <&cpcap 28 IRQ_TYPE_NONE>, <&cpcap 19 IRQ_TYPE_NONE>,
+ <&cpcap 18 IRQ_TYPE_NONE>, <&cpcap 17 IRQ_TYPE_NONE>,
+ <&cpcap 16 IRQ_TYPE_NONE>, <&cpcap 49 IRQ_TYPE_NONE>,
+ <&cpcap 48 IRQ_TYPE_NONE>;
+ interrupt-names = "id_ground", "id_float", "se0conn",
+ "vbusvld", "sessvld", "sessend",
+ "se1", "dm", "dp";
+
+ mode-gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>,
+ <&gpio1 0 GPIO_ACTIVE_HIGH>;
+
+ io-channels = <&cpcap_adc 2>, <&cpcap_adc 7>;
+ io-channel-names = "vbus", "id";
+
+ vusb-supply = <&avdd_usb>;
+ };
+
+ regulator {
+ compatible = "motorola,cpcap-regulator";
+
+ regulators {
+ vdd_cpu: SW1 {
+ regulator-name = "vdd_cpu";
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1125000>;
+ regulator-enable-ramp-delay = <1500>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vdd_core: SW2 {
+ regulator-name = "vdd_core";
+ regulator-min-microvolt = <950000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-enable-ramp-delay = <1500>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vdd_1v8_vio: SW3 {
+ regulator-name = "vdd_1v8_vio";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-enable-ramp-delay = <0>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vdd_aon: SW4 {
+ regulator-name = "vdd_aon";
+ regulator-min-microvolt = <950000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-enable-ramp-delay = <1500>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vdd_led: SW5 {
+ regulator-name = "vdd_led";
+ regulator-min-microvolt = <5050000>;
+ regulator-max-microvolt = <5050000>;
+ regulator-enable-ramp-delay = <1500>;
+ regulator-boot-on;
+ };
+
+ vdd_hvio: VHVIO {
+ regulator-name = "vdd_hvio";
+ regulator-min-microvolt = <2775000>;
+ regulator-max-microvolt = <2775000>;
+ regulator-enable-ramp-delay = <1000>;
+ };
+
+ vcore_emmc: VSDIO {
+ regulator-name = "vcore_emmc";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-enable-ramp-delay = <1000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ avdd_dsi_csi: VCSI {
+ regulator-name = "avdd_dsi_csi";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-enable-ramp-delay = <1000>;
+ regulator-boot-on;
+ };
+
+ avdd_3v3_periph: VWLAN2 {
+ regulator-name = "avdd_3v3_periph";
+ regulator-min-microvolt = <2775000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-enable-ramp-delay = <1000>;
+ regulator-boot-on;
+ };
+
+ vddio_usd: VSIMCARD {
+ regulator-name = "vddio_usd";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2900000>;
+ regulator-enable-ramp-delay = <1000>;
+ regulator-boot-on;
+ };
+
+ vdd_haptic: VVIB {
+ regulator-name = "vdd_haptic";
+ regulator-min-microvolt = <1300000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-enable-ramp-delay = <1000>;
+ };
+
+ avdd_usb: VUSB {
+ regulator-name = "avdd_usb";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-enable-ramp-delay = <1000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vdd_audio: VAUDIO {
+ regulator-name = "vdd_audio";
+ regulator-min-microvolt = <2775000>;
+ regulator-max-microvolt = <2775000>;
+ regulator-enable-ramp-delay = <1000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+ };
+
+ cpcap_rtc: rtc {
+ compatible = "motorola,cpcap-rtc";
+
+ interrupt-parent = <&cpcap>;
+ interrupts = <39 IRQ_TYPE_NONE>, <26 IRQ_TYPE_NONE>;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
deleted file mode 100644
index 18c3fc26ca93..000000000000
--- a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
+++ /dev/null
@@ -1,78 +0,0 @@
-Motorola CPCAP PMIC device tree binding
-
-Required properties:
-- compatible : One or both of "motorola,cpcap" or "ste,6556002"
-- reg : SPI chip select
-- interrupts : The interrupt line the device is connected to
-- interrupt-controller : Marks the device node as an interrupt controller
-- #interrupt-cells : The number of cells to describe an IRQ, should be 2
-- #address-cells : Child device offset number of cells, should be 1
-- #size-cells : Child device size number of cells, should be 0
-- spi-max-frequency : Typically set to 3000000
-- spi-cs-high : SPI chip select direction
-
-Optional subnodes:
-
-The sub-functions of CPCAP get their own node with their own compatible values,
-which are described in the following files:
-
-- Documentation/devicetree/bindings/power/supply/cpcap-battery.yaml
-- Documentation/devicetree/bindings/power/supply/cpcap-charger.yaml
-- Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
-- Documentation/devicetree/bindings/phy/motorola,cpcap-usb-phy.yaml
-- Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
-- Documentation/devicetree/bindings/rtc/cpcap-rtc.txt
-- Documentation/devicetree/bindings/leds/leds-cpcap.txt
-- Documentation/devicetree/bindings/iio/adc/motorola,cpcap-adc.yaml
-
-The only exception is the audio codec. Instead of a compatible value its
-node must be named "audio-codec".
-
-Required properties for the audio-codec subnode:
-
-- #sound-dai-cells = <1>;
-- interrupts : should contain jack detection interrupts, with headset
- detect interrupt matching "hs" and microphone bias 2
- detect interrupt matching "mb2" in interrupt-names.
-- interrupt-names : Contains "hs", "mb2"
-
-The audio-codec provides two DAIs. The first one is connected to the
-Stereo HiFi DAC and the second one is connected to the Voice DAC.
-
-Example:
-
-&mcspi1 {
- cpcap: pmic@0 {
- compatible = "motorola,cpcap", "ste,6556002";
- reg = <0>; /* cs0 */
- interrupt-parent = <&gpio1>;
- interrupts = <7 IRQ_TYPE_EDGE_RISING>;
- interrupt-controller;
- #interrupt-cells = <2>;
- #address-cells = <1>;
- #size-cells = <0>;
- spi-max-frequency = <3000000>;
- spi-cs-high;
-
- audio-codec {
- #sound-dai-cells = <1>;
- interrupts-extended = <&cpcap 9 0>, <&cpcap 10 0>;
- interrupt-names = "hs", "mb2";
-
- /* HiFi */
- port@0 {
- endpoint {
- remote-endpoint = <&cpu_dai1>;
- };
- };
-
- /* Voice */
- port@1 {
- endpoint {
- remote-endpoint = <&cpu_dai2>;
- };
- };
- };
- };
-};
-
--
2.51.0
^ permalink raw reply related
* [PATCH v4 2/6] dt-bindings: input: cpcap-pwrbutton: convert to DT schema
From: Svyatoslav Ryhel @ 2026-04-17 7:11 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Pavel Machek, Svyatoslav Ryhel, David Lechner,
Tony Lindgren
Cc: linux-input, devicetree, linux-kernel, linux-leds
In-Reply-To: <20260417071106.21984-1-clamor95@gmail.com>
Convert power button devicetree bindings for the Motorola CPCAP MFD from
TXT to YAML format. This patch does not change any functionality; the
bindings remain the same.
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
---
.../bindings/input/cpcap-pwrbutton.txt | 20 ------------
.../input/motorola,cpcap-pwrbutton.yaml | 32 +++++++++++++++++++
2 files changed, 32 insertions(+), 20 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
create mode 100644 Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
diff --git a/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt b/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
deleted file mode 100644
index 0dd0076daf71..000000000000
--- a/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-Motorola CPCAP on key
-
-This module is part of the CPCAP. For more details about the whole
-chip see Documentation/devicetree/bindings/mfd/motorola-cpcap.txt.
-
-This module provides a simple power button event via an Interrupt.
-
-Required properties:
-- compatible: should be one of the following
- - "motorola,cpcap-pwrbutton"
-- interrupts: irq specifier for CPCAP's ON IRQ
-
-Example:
-
-&cpcap {
- cpcap_pwrbutton: pwrbutton {
- compatible = "motorola,cpcap-pwrbutton";
- interrupts = <23 IRQ_TYPE_NONE>;
- };
-};
diff --git a/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml b/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
new file mode 100644
index 000000000000..77a3e5a47d1a
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/motorola,cpcap-pwrbutton.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Motorola CPCAP PMIC power key
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+description:
+ This module is part of the Motorola CPCAP MFD device. For more details
+ see Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml. The
+ power key is represented as a sub-node of the PMIC node on the device
+ tree.
+
+properties:
+ compatible:
+ const: motorola,cpcap-pwrbutton
+
+ interrupts:
+ items:
+ - description: CPCAP's ON interrupt
+
+required:
+ - compatible
+ - interrupts
+
+additionalProperties: false
+
+...
--
2.51.0
^ permalink raw reply related
* [PATCH v4 1/6] dt-bindings: leds: leds-cpcap: convert to DT schema
From: Svyatoslav Ryhel @ 2026-04-17 7:11 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Pavel Machek, Svyatoslav Ryhel, David Lechner,
Tony Lindgren
Cc: linux-input, devicetree, linux-kernel, linux-leds
In-Reply-To: <20260417071106.21984-1-clamor95@gmail.com>
Convert LEDs devicetree bindings for the Motorola CPCAP MFD from TXT to
YAML format. This patch does not change any functionality; the bindings
remain the same.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
---
.../devicetree/bindings/leds/leds-cpcap.txt | 29 -------------
.../bindings/leds/motorola,cpcap-leds.yaml | 42 +++++++++++++++++++
2 files changed, 42 insertions(+), 29 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/leds/leds-cpcap.txt
create mode 100644 Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml
diff --git a/Documentation/devicetree/bindings/leds/leds-cpcap.txt b/Documentation/devicetree/bindings/leds/leds-cpcap.txt
deleted file mode 100644
index ebf7cdc7f70c..000000000000
--- a/Documentation/devicetree/bindings/leds/leds-cpcap.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-Motorola CPCAP PMIC LEDs
-------------------------
-
-This module is part of the CPCAP. For more details about the whole
-chip see Documentation/devicetree/bindings/mfd/motorola-cpcap.txt.
-
-Requires node properties:
-- compatible: should be one of
- * "motorola,cpcap-led-mdl" (Main Display Lighting)
- * "motorola,cpcap-led-kl" (Keyboard Lighting)
- * "motorola,cpcap-led-adl" (Aux Display Lighting)
- * "motorola,cpcap-led-red" (Red Triode)
- * "motorola,cpcap-led-green" (Green Triode)
- * "motorola,cpcap-led-blue" (Blue Triode)
- * "motorola,cpcap-led-cf" (Camera Flash)
- * "motorola,cpcap-led-bt" (Bluetooth)
- * "motorola,cpcap-led-cp" (Camera Privacy LED)
-- label: see Documentation/devicetree/bindings/leds/common.txt
-- vdd-supply: A phandle to the regulator powering the LED
-
-Example:
-
-&cpcap {
- cpcap_led_red: red-led {
- compatible = "motorola,cpcap-led-red";
- label = "cpcap:red";
- vdd-supply = <&sw5>;
- };
-};
diff --git a/Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml b/Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml
new file mode 100644
index 000000000000..c8e7b88a05cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/motorola,cpcap-leds.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Motorola CPCAP PMIC LEDs
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+description:
+ This module is part of the Motorola CPCAP MFD device. For more details
+ see Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml. LEDs are
+ represented as sub-nodes of the PMIC node on the device tree.
+
+allOf:
+ - $ref: /schemas/leds/common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - motorola,cpcap-led-adl # Display Lighting
+ - motorola,cpcap-led-blue # Blue Triode
+ - motorola,cpcap-led-bt # Bluetooth
+ - motorola,cpcap-led-cf # Camera Flash
+ - motorola,cpcap-led-cp # Camera Privacy LED
+ - motorola,cpcap-led-green # Green Triode
+ - motorola,cpcap-led-kl # Keyboard Lighting
+ - motorola,cpcap-led-mdl # Main Display Lighting
+ - motorola,cpcap-led-red # Red Triode
+
+ vdd-supply: true
+
+required:
+ - compatible
+ - label
+ - vdd-supply
+
+unevaluatedProperties: false
+
+...
--
2.51.0
^ permalink raw reply related
* [PATCH v4 0/6] mfd: cpcap: convert documentation to schema and add Mot board support
From: Svyatoslav Ryhel @ 2026-04-17 7:11 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Pavel Machek, Svyatoslav Ryhel, David Lechner,
Tony Lindgren
Cc: linux-input, devicetree, linux-kernel, linux-leds
The initial goal was only to add support for the CPCAP used in the Mot
Tegra20 board; however, since the documentation was already partially
converted, I decided to complete the conversion to schema too.
The CPCAP regulator, leds, rtc, pwrbutton and core files were converted
from TXT to YAML while preserving the original structure. Mot board
compatibility was added to the regulator and core schema. Since these
were one-line patches, they were not separated into dedicated commits;
however, the commit message notes this for both cases.
Finally, the CPCAP MFD was slightly refactored to improve support for
multiple subcell compositions.
---
Changes in v2:
- fixed code style
- rtc conversion was picked, so patch dropped
- added audio ports description into mfd schema
- splitted schema conversion and compatible addition
- minor style improvements and typo fixes
Changes in v3:
- added regulator node names list into pattern
- filled spi_device_id with driver data
- ADC patches were picked, so changes dropped
Changes in v4:
- dropped regulator patches (applied)
---
Svyatoslav Ryhel (6):
dt-bindings: leds: leds-cpcap: convert to DT schema
dt-bindings: input: cpcap-pwrbutton: convert to DT schema
dt-bindings: mfd: motorola-cpcap: convert to DT schema
dt-bindings: mfd: motorola-cpcap: document Mapphone and Mot CPCAP
mfd: motorola-cpcap: diverge configuration per-board
mfd: motorola-cpcap: add support for Mot CPCAP composition
.../bindings/input/cpcap-pwrbutton.txt | 20 -
.../input/motorola,cpcap-pwrbutton.yaml | 32 ++
.../devicetree/bindings/leds/leds-cpcap.txt | 29 --
.../bindings/leds/motorola,cpcap-leds.yaml | 42 ++
.../bindings/mfd/motorola,cpcap.yaml | 416 ++++++++++++++++++
.../bindings/mfd/motorola-cpcap.txt | 78 ----
drivers/mfd/motorola-cpcap.c | 151 ++++++-
7 files changed, 623 insertions(+), 145 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
create mode 100644 Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
delete mode 100644 Documentation/devicetree/bindings/leds/leds-cpcap.txt
create mode 100644 Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml
create mode 100644 Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
delete mode 100644 Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
--
2.51.0
^ permalink raw reply
* [PATCH v3 3/3] arm64: dts: qcom: milos: Add GX clock controller
From: Luca Weiss @ 2026-04-17 7:07 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Alexander Koskovich
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, linux-clk,
devicetree, linux-kernel, Luca Weiss, Konrad Dybcio,
Jagadeesh Kona
In-Reply-To: <20260417-milos-gxclkctl-v3-0-08f5988c43a2@fairphone.com>
Add a node for the GX clock controller, which provides a power domain to
consumers.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
arch/arm64/boot/dts/qcom/milos.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi b/arch/arm64/boot/dts/qcom/milos.dtsi
index 4a64a98a434b..4bd9181ca03e 100644
--- a/arch/arm64/boot/dts/qcom/milos.dtsi
+++ b/arch/arm64/boot/dts/qcom/milos.dtsi
@@ -1542,6 +1542,16 @@ lpass_ag_noc: interconnect@3c40000 {
qcom,bcm-voters = <&apps_bcm_voter>;
};
+ gxclkctl: clock-controller@3d64000 {
+ compatible = "qcom,milos-gxclkctl";
+ reg = <0x0 0x03d64000 0x0 0x6000>;
+
+ power-domains = <&rpmhpd RPMHPD_GFX>,
+ <&gpucc GPU_CC_CX_GDSC>;
+
+ #power-domain-cells = <1>;
+ };
+
gpucc: clock-controller@3d90000 {
compatible = "qcom,milos-gpucc";
reg = <0x0 0x03d90000 0x0 0x9800>;
--
2.53.0
^ permalink raw reply related
* [PATCH v3 2/3] clk: qcom: Add support for GXCLK for Milos
From: Luca Weiss @ 2026-04-17 7:07 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Alexander Koskovich
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, linux-clk,
devicetree, linux-kernel, Luca Weiss, Jagadeesh Kona, Taniya Das,
Dmitry Baryshkov
In-Reply-To: <20260417-milos-gxclkctl-v3-0-08f5988c43a2@fairphone.com>
GXCLKCTL (Graphics GX Clock Controller) is a block dedicated to managing
clocks for the GPU subsystem on GX power domain. The GX clock controller
driver manages only the GX GDSC and the rest of the resources of the
controller are managed by the firmware.
We can use the existing kaanapali driver for Milos as well since the
GX_CLKCTL_GX_GDSC supported by the Linux driver requires the same
configuration.
Reviewed-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
drivers/clk/qcom/Makefile | 2 +-
drivers/clk/qcom/gxclkctl-kaanapali.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 89d07c35e4d9..462c7615a6d7 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -189,7 +189,7 @@ obj-$(CONFIG_SM_GPUCC_8450) += gpucc-sm8450.o
obj-$(CONFIG_SM_GPUCC_8550) += gpucc-sm8550.o
obj-$(CONFIG_SM_GPUCC_8650) += gpucc-sm8650.o
obj-$(CONFIG_SM_GPUCC_8750) += gpucc-sm8750.o gxclkctl-kaanapali.o
-obj-$(CONFIG_SM_GPUCC_MILOS) += gpucc-milos.o
+obj-$(CONFIG_SM_GPUCC_MILOS) += gpucc-milos.o gxclkctl-kaanapali.o
obj-$(CONFIG_SM_LPASSCC_6115) += lpasscc-sm6115.o
obj-$(CONFIG_SM_TCSRCC_8550) += tcsrcc-sm8550.o
obj-$(CONFIG_SM_TCSRCC_8650) += tcsrcc-sm8650.o
diff --git a/drivers/clk/qcom/gxclkctl-kaanapali.c b/drivers/clk/qcom/gxclkctl-kaanapali.c
index 40d856378a74..7b0af0ba1e68 100644
--- a/drivers/clk/qcom/gxclkctl-kaanapali.c
+++ b/drivers/clk/qcom/gxclkctl-kaanapali.c
@@ -53,6 +53,7 @@ static const struct qcom_cc_desc gx_clkctl_kaanapali_desc = {
static const struct of_device_id gx_clkctl_kaanapali_match_table[] = {
{ .compatible = "qcom,glymur-gxclkctl" },
{ .compatible = "qcom,kaanapali-gxclkctl" },
+ { .compatible = "qcom,milos-gxclkctl" },
{ .compatible = "qcom,sm8750-gxclkctl" },
{ }
};
--
2.53.0
^ permalink raw reply related
* [PATCH v3 1/3] dt-bindings: clock: qcom: document the Milos GX clock controller
From: Luca Weiss @ 2026-04-17 7:07 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Alexander Koskovich
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, linux-clk,
devicetree, linux-kernel, Luca Weiss, Krzysztof Kozlowski
In-Reply-To: <20260417-milos-gxclkctl-v3-0-08f5988c43a2@fairphone.com>
Qualcomm GX(graphics) is a clock controller which has PLLs, clocks and
Power domains (GDSC), but the requirement from the SW driver is to use
the GDSC power domain from the clock controller to recover the GPU
firmware in case of any failure/hangs. The rest of the resources of the
clock controller are being used by the firmware of GPU. This module
exposes the GDSC power domains which helps the recovery of Graphics
subsystem.
Milos can reuse the qcom,kaanapali-gxclkctl.h header due to similarity
of the hardware block, and also reuse of the Linux driver.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
.../bindings/clock/qcom,milos-gxclkctl.yaml | 61 ++++++++++++++++++++++
1 file changed, 61 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/qcom,milos-gxclkctl.yaml b/Documentation/devicetree/bindings/clock/qcom,milos-gxclkctl.yaml
new file mode 100644
index 000000000000..fbcb5d3f3e3d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,milos-gxclkctl.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,milos-gxclkctl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Graphics Power Domain Controller on Milos
+
+maintainers:
+ - Luca Weiss <luca.weiss@fairphone.com>
+
+description: |
+ Qualcomm GX(graphics) is a clock controller which has PLLs, clocks and
+ Power domains (GDSC). This module provides the power domains control
+ of gxclkctl on Qualcomm SoCs which helps the recovery of Graphics subsystem.
+
+ See also:
+ include/dt-bindings/clock/qcom,kaanapali-gxclkctl.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,milos-gxclkctl
+
+ reg:
+ maxItems: 1
+
+ power-domains:
+ description:
+ Power domains required for the clock controller to operate
+ items:
+ - description: GFX power domain
+ - description: GPUCC(CX) power domain
+
+ '#power-domain-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - power-domains
+ - '#power-domain-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ clock-controller@3d64000 {
+ compatible = "qcom,milos-gxclkctl";
+ reg = <0x0 0x03d64000 0x0 0x6000>;
+ power-domains = <&rpmhpd RPMHPD_GFX>,
+ <&gpucc 0>;
+ #power-domain-cells = <1>;
+ };
+ };
+...
--
2.53.0
^ permalink raw reply related
* [PATCH v3 0/3] Add support for GXCLK for Milos
From: Luca Weiss @ 2026-04-17 7:07 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Alexander Koskovich
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, linux-clk,
devicetree, linux-kernel, Luca Weiss, Krzysztof Kozlowski,
Jagadeesh Kona, Taniya Das, Dmitry Baryshkov, Konrad Dybcio
Similar to other new SoCs, Milos also contains the GXCLKCTL block that
we need to control for GPU. Add support for it.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
Changes in v3:
- Replace unevaluatedProperties with additionalProperties
- Pick up tags
- Link to v2: https://patch.msgid.link/20260403-milos-gxclkctl-v2-0-95eb94a7d0a4@fairphone.com
Changes in v2:
- Update casing of binding title, reg goes as second property (Krzysztof)
- Rebase on linux-next
- Pick up tags
- Link to v1: https://lore.kernel.org/r/20260306-milos-gxclkctl-v1-0-00b09ee159a7@fairphone.com
---
Luca Weiss (3):
dt-bindings: clock: qcom: document the Milos GX clock controller
clk: qcom: Add support for GXCLK for Milos
arm64: dts: qcom: milos: Add GX clock controller
.../bindings/clock/qcom,milos-gxclkctl.yaml | 61 ++++++++++++++++++++++
arch/arm64/boot/dts/qcom/milos.dtsi | 10 ++++
drivers/clk/qcom/Makefile | 2 +-
drivers/clk/qcom/gxclkctl-kaanapali.c | 1 +
4 files changed, 73 insertions(+), 1 deletion(-)
---
base-commit: f4d9dc7f102a8d7e7fa018ae048aa324349122a4
change-id: 20260306-milos-gxclkctl-8a8372d6a1e0
Best regards,
--
Luca Weiss <luca.weiss@fairphone.com>
^ permalink raw reply
* [PATCH v4 3/3 RESEND] drm/bridge: simple-bridge: Add support for MStar TSUMU88ADT3-LF-1
From: Svyatoslav Ryhel @ 2026-04-17 6:49 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
David Airlie, Simona Vetter, Svyatoslav Ryhel
Cc: dri-devel, devicetree, linux-kernel
In-Reply-To: <20260417064953.20511-1-clamor95@gmail.com>
From: Maxim Schwalm <maxim.schwalm@gmail.com>
A simple HDMI bridge used in ASUS Transformer AiO P1801-T.
Signed-off-by: Maxim Schwalm <maxim.schwalm@gmail.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Robert Foss <rfoss@kernel.org>
---
drivers/gpu/drm/bridge/simple-bridge.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/bridge/simple-bridge.c b/drivers/gpu/drm/bridge/simple-bridge.c
index 8aa31ca3c72d..cc13c98f9be6 100644
--- a/drivers/gpu/drm/bridge/simple-bridge.c
+++ b/drivers/gpu/drm/bridge/simple-bridge.c
@@ -270,6 +270,11 @@ static const struct of_device_id simple_bridge_match[] = {
.data = &(const struct simple_bridge_info) {
.connector_type = DRM_MODE_CONNECTOR_HDMIA,
},
+ }, {
+ .compatible = "mstar,tsumu88adt3-lf-1",
+ .data = &(const struct simple_bridge_info) {
+ .connector_type = DRM_MODE_CONNECTOR_HDMIA,
+ },
}, {
.compatible = "parade,ps185hdm",
.data = &(const struct simple_bridge_info) {
--
2.51.0
^ permalink raw reply related
* [PATCH v4 2/3 RESEND] dt-bindigs: display: extend the simple bridge with MStar TSUMU88ADT3-LF-1 bridge
From: Svyatoslav Ryhel @ 2026-04-17 6:49 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
David Airlie, Simona Vetter, Svyatoslav Ryhel
Cc: dri-devel, devicetree, linux-kernel
In-Reply-To: <20260417064953.20511-1-clamor95@gmail.com>
A simple bridge used in ASUS Transformer AiO P1801-T.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Robert Foss <rfoss@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
.../devicetree/bindings/display/bridge/simple-bridge.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
index e6808419f625..7636c24906ba 100644
--- a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
@@ -30,6 +30,7 @@ properties:
- algoltek,ag6311
- asl-tek,cs5263
- dumb-vga-dac
+ - mstar,tsumu88adt3-lf-1
- parade,ps185hdm
- radxa,ra620
- realtek,rtd2171
--
2.51.0
^ permalink raw reply related
* [PATCH v4 1/3 RESEND] dt-bindigs: display: extend the LVDS codec with Triple 10-BIT LVDS Transmitter
From: Svyatoslav Ryhel @ 2026-04-17 6:49 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
David Airlie, Simona Vetter, Svyatoslav Ryhel
Cc: dri-devel, devicetree, linux-kernel
In-Reply-To: <20260417064953.20511-1-clamor95@gmail.com>
From: David Heidelberg <david@ixit.cz>
LVDS transmitter used in the Microsoft Surface RT.
Signed-off-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Robert Foss <rfoss@kernel.org>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
---
Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
index 7586d681bcc6..0363201f0e61 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
@@ -34,6 +34,7 @@ properties:
- items:
- enum:
- doestek,dtc34lm85am # For the Doestek DTC34LM85AM Flat Panel Display (FPD) Transmitter
+ - idt,v103 # For the Triple 10-BIT LVDS Transmitter
- onnn,fin3385 # OnSemi FIN3385
- ti,ds90c185 # For the TI DS90C185 FPD-Link Serializer
- ti,ds90c187 # For the TI DS90C187 FPD-Link Serializer
--
2.51.0
^ permalink raw reply related
* [PATCH v4 0/3 RESEND] drm: bridge: add support for Triple 10-BIT
From: Svyatoslav Ryhel @ 2026-04-17 6:49 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
David Airlie, Simona Vetter, Svyatoslav Ryhel
Cc: dri-devel, devicetree, linux-kernel
Triple 10-BIT LVDS Transmitter is used in Microsoft Surface RT and
MStar TSUMU88ADT3-LF-1 HDMI bridge is used in ASUS Transformer AiO
P1801-T.
Link to v3: https://lore.kernel.org/lkml/20250824092728.105643-1-clamor95@gmail.com/
---
Changes on switching from v3 to v4:
- rebased on top of v7.0
Changes on switching from v2 to v3:
- place mstar,tsumu88adt3-lf-1 alphabetically
- fix typos
Changes on switching from v1 to v2:
- sort compatible alphabetically in schema
---
David Heidelberg (1):
dt-bindigs: display: extend the LVDS codec with Triple 10-BIT LVDS
Transmitter
Maxim Schwalm (1):
drm/bridge: simple-bridge: Add support for MStar TSUMU88ADT3-LF-1
Svyatoslav Ryhel (1):
dt-bindigs: display: extend the simple bridge with MStar
TSUMU88ADT3-LF-1 bridge
.../devicetree/bindings/display/bridge/lvds-codec.yaml | 1 +
.../devicetree/bindings/display/bridge/simple-bridge.yaml | 1 +
drivers/gpu/drm/bridge/simple-bridge.c | 5 +++++
3 files changed, 7 insertions(+)
--
2.51.0
^ permalink raw reply
* [PATCH v1 1/1 RESEND] dt-bindings: display: bridge: ssd2825: inherit dsi-controller properties
From: Svyatoslav Ryhel @ 2026-04-17 6:46 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Svyatoslav Ryhel
Cc: dri-devel, devicetree, linux-kernel
In-Reply-To: <20260417064657.20293-1-clamor95@gmail.com>
SSD2825 being RGB-DSI bridge should inherit dsi-controller properties same
way other DSI controllers and DSI bridges do.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
.../devicetree/bindings/display/bridge/solomon,ssd2825.yaml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/solomon,ssd2825.yaml b/Documentation/devicetree/bindings/display/bridge/solomon,ssd2825.yaml
index e2d293d623b8..760645493031 100644
--- a/Documentation/devicetree/bindings/display/bridge/solomon,ssd2825.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/solomon,ssd2825.yaml
@@ -10,6 +10,7 @@ maintainers:
- Svyatoslav Ryhel <clamor95@gmail.com>
allOf:
+ - $ref: /schemas/display/dsi-controller.yaml#
- $ref: /schemas/spi/spi-peripheral-props.yaml#
properties:
@@ -86,7 +87,7 @@ required:
- compatible
- ports
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
--
2.51.0
^ permalink raw reply related
* [PATCH v1 0/1 RESEND] dt-bindings: display: bridge: ssd2825: inherit dsi-controller properties
From: Svyatoslav Ryhel @ 2026-04-17 6:46 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Svyatoslav Ryhel
Cc: dri-devel, devicetree, linux-kernel
SSD2825 being RGB-DSI bridge should inherit dsi-controller properties same
way other DSI controllers and DSI bridges do.
Svyatoslav Ryhel (1):
dt-bindings: display: bridge: ssd2825: inherit dsi-controller
properties
.../devicetree/bindings/display/bridge/solomon,ssd2825.yaml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--
2.51.0
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: socfpga: Add the Agilex7 series SoC's
From: Krzysztof Kozlowski @ 2026-04-17 6:43 UTC (permalink / raw)
To: Dinh Nguyen; +Cc: robh, krzk+dt, conor+dt, devicetree
In-Reply-To: <a75e4553-3db3-491c-a5af-a539e9c8da82@kernel.org>
On 16/04/2026 17:20, Dinh Nguyen wrote:
>
>
> 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.
The family does not matter. What is "socfga-agilex"? One given soc. Not
a family.
>
> 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
So what is "altr,socfpga-agilex7"? Why SoC has two compatibles?
>
> 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
But why? Why are you using one SoC compatible in other context? It's
really no different than all other SoCs.
>
> 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.
You anyway MUST have new binding for each device. Please carefully
follow writing bindings and DTS 101.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] ARM: dts: aspeed: anacapa: add interrupt properties for PDB PCA9555
From: Rex Fu via B4 Relay @ 2026-04-17 6:41 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel, Rex Fu
From: Rex Fu <Rex.Fu@amd.com>
Add interrupt-parent and interrupts properties to the PDB PCA9555
nodes in the anacapa DTS.
Signed-off-by: Rex Fu <Rex.Fu@amd.com>
---
Single DTS update for the PDB PCA9555 interrupt wiring on anacapa.
---
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
index 2cb7bd128d24..7319f2319bb7 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
@@ -481,6 +481,9 @@ gpio@22 {
gpio-controller;
#gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <174 IRQ_TYPE_LEVEL_LOW>;
+
gpio-line-names =
"RPDB_FAN_FULL_SPEED_R_N", "RPDB_I2C_TEMP75_U8_ALERT_R_N",
"RPDB_I2C_TMP432_U29_ALERT_R_N", "RPDB_GLOBAL_WP",
@@ -500,6 +503,9 @@ gpio@24 {
gpio-controller;
#gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <174 IRQ_TYPE_LEVEL_LOW>;
+
gpio-line-names =
"RPDB_EAM2_PRSNT_MOS_N_R", "RPDB_EAM3_PRSNT_MOS_N_R",
"RPDB_PWRGD_P50V_HSC4_SYS_R",
@@ -529,6 +535,9 @@ gpio@22 {
gpio-controller;
#gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <174 IRQ_TYPE_LEVEL_LOW>;
+
gpio-line-names =
"LPDB_FAN_FULL_SPEED_R_N","LPDB_I2C_TEMP75_U8_ALERT_R_N",
"LPDB_I2C_TMP432_U29_ALERT_R_N","LPDB_GLOBAL_WP",
@@ -546,6 +555,9 @@ gpio@24 {
gpio-controller;
#gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <174 IRQ_TYPE_LEVEL_LOW>;
+
gpio-line-names =
"LPDB_P50V_FAN1_R2_PG","LPDB_P50V_FAN2_R2_PG",
"LPDB_P50V_FAN3_R2_PG","LPDB_P50V_FAN4_R2_PG",
---
base-commit: 76b4ec8efdc3887cdbf730da2e55881fc1a18770
change-id: 20260417-anacapa-pca9555-irq-3090d4120270
Best regards,
--
Rex Fu <Rex.Fu@amd.com>
^ 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