* [PATCH 12/12] rtc: rzn1: Add support for Renesas RZ/T2H and RZ/N2H SoCs
From: Prabhakar @ 2026-06-15 15:48 UTC (permalink / raw)
To: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Add a new compatible string "renesas,r9a09g077-rtc" to the OF match table
to support the RTC IP variant found on the RZ/T2H and RZ/N2H SoCs.
These newer SoCs integrate a closely related variant of the RZ/N1 RTC IP.
The RZ/T2H and RZ/N2H variants lack the RTCA0SUBU and RTCA0TCR registers,
those registers are not accessed or used when operating under the
rzn1_rtc_ops_scmp configurations, making the current infrastructure
compatible.
The RZ/T2H RTC variant also supports a 1 Hz output signal on the
RTCAT1HZ pin, controlled by the RTCA0CTL1[RTCA01HZE] bit. This bit is
marked as reserved in the RZ/N1 hardware manual, making RZ/T2H a
distinct RTC variant despite its overall compatibility with the RZ/N1
implementation.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/rtc/rtc-rzn1.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
index 9f9cf9882fc4..dfff8dc8c321 100644
--- a/drivers/rtc/rtc-rzn1.c
+++ b/drivers/rtc/rtc-rzn1.c
@@ -597,6 +597,7 @@ static int rzn1_rtc_resume(struct device *dev)
static DEFINE_SIMPLE_DEV_PM_OPS(rzn1_rtc_pm_ops, rzn1_rtc_suspend, rzn1_rtc_resume);
static const struct of_device_id rzn1_rtc_of_match[] = {
+ { .compatible = "renesas,r9a09g077-rtc" },
{ .compatible = "renesas,rzn1-rtc" },
{},
};
--
2.54.0
^ permalink raw reply related
* [PATCH 11/12] rtc: rzn1: use FIELD_PREP/FIELD_GET and GENMASK for register access
From: Prabhakar @ 2026-06-15 15:48 UTC (permalink / raw)
To: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Replace open-coded shift and mask operations with the bitfield API.
Note that the weekday field is changed from an explicit 0x0f mask to
an 8-bit field definition, matching the hardware manual. This does not
change behaviour, as valid weekday values cannot exceed 7.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/rtc/rtc-rzn1.c | 46 ++++++++++++++++++++++++------------------
1 file changed, 26 insertions(+), 20 deletions(-)
diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
index c7ef3c81180f..9f9cf9882fc4 100644
--- a/drivers/rtc/rtc-rzn1.c
+++ b/drivers/rtc/rtc-rzn1.c
@@ -12,6 +12,8 @@
*/
#include <linux/bcd.h>
+#include <linux/bitfield.h>
+#include <linux/bits.h>
#include <linux/clk.h>
#include <linux/init.h>
#include <linux/iopoll.h>
@@ -40,14 +42,18 @@
#define RZN1_RTC_CTL2_STOPPED (RZN1_RTC_CTL2_WAIT | RZN1_RTC_CTL2_WST)
#define RZN1_RTC_TIME 0x30
-#define RZN1_RTC_TIME_MIN_SHIFT 8
-#define RZN1_RTC_TIME_HOUR_SHIFT 16
+#define RZN1_RTC_TIME_SEC GENMASK(7, 0)
+#define RZN1_RTC_TIME_MIN GENMASK(15, 8)
+#define RZN1_RTC_TIME_HOUR GENMASK(23, 16)
+
#define RZN1_RTC_CAL 0x34
-#define RZN1_RTC_CAL_DAY_SHIFT 8
-#define RZN1_RTC_CAL_MON_SHIFT 16
-#define RZN1_RTC_CAL_YEAR_SHIFT 24
+#define RZN1_RTC_CAL_WDAY GENMASK(7, 0)
+#define RZN1_RTC_CAL_DAY GENMASK(15, 8)
+#define RZN1_RTC_CAL_MON GENMASK(23, 16)
+#define RZN1_RTC_CAL_YEAR GENMASK(31, 24)
#define RZN1_RTC_SUBU 0x38
+#define RZN1_RTC_SUBU_RTCA0FX GENMASK(5, 0)
#define RZN1_RTC_SUBU_DEV BIT(7)
#define RZN1_RTC_SUBU_DECR BIT(6)
@@ -82,15 +88,15 @@ static void rzn1_rtc_get_time_snapshot(struct rzn1_rtc *rtc, struct rtc_time *tm
u32 val;
val = readl(rtc->base + RZN1_RTC_TIMEC);
- tm->tm_sec = bcd2bin(val);
- tm->tm_min = bcd2bin(val >> RZN1_RTC_TIME_MIN_SHIFT);
- tm->tm_hour = bcd2bin(val >> RZN1_RTC_TIME_HOUR_SHIFT);
+ tm->tm_sec = bcd2bin(FIELD_GET(RZN1_RTC_TIME_SEC, val));
+ tm->tm_min = bcd2bin(FIELD_GET(RZN1_RTC_TIME_MIN, val));
+ tm->tm_hour = bcd2bin(FIELD_GET(RZN1_RTC_TIME_HOUR, val));
val = readl(rtc->base + RZN1_RTC_CALC);
- tm->tm_wday = val & 0x0f;
- tm->tm_mday = bcd2bin(val >> RZN1_RTC_CAL_DAY_SHIFT);
- tm->tm_mon = bcd2bin(val >> RZN1_RTC_CAL_MON_SHIFT) - 1;
- tm->tm_year = bcd2bin(val >> RZN1_RTC_CAL_YEAR_SHIFT) + 100;
+ tm->tm_wday = FIELD_GET(RZN1_RTC_CAL_WDAY, val);
+ tm->tm_mday = bcd2bin(FIELD_GET(RZN1_RTC_CAL_DAY, val));
+ tm->tm_mon = bcd2bin(FIELD_GET(RZN1_RTC_CAL_MON, val)) - 1;
+ tm->tm_year = bcd2bin(FIELD_GET(RZN1_RTC_CAL_YEAR, val)) + 100;
}
static int rzn1_rtc_read_time(struct device *dev, struct rtc_time *tm)
@@ -133,15 +139,15 @@ static int rzn1_rtc_set_time(struct device *dev, struct rtc_time *tm)
return ret;
}
- val = bin2bcd(tm->tm_sec);
- val |= bin2bcd(tm->tm_min) << RZN1_RTC_TIME_MIN_SHIFT;
- val |= bin2bcd(tm->tm_hour) << RZN1_RTC_TIME_HOUR_SHIFT;
+ val = FIELD_PREP(RZN1_RTC_TIME_SEC, bin2bcd(tm->tm_sec)) |
+ FIELD_PREP(RZN1_RTC_TIME_MIN, bin2bcd(tm->tm_min)) |
+ FIELD_PREP(RZN1_RTC_TIME_HOUR, bin2bcd(tm->tm_hour));
writel(val, rtc->base + RZN1_RTC_TIME);
- val = tm->tm_wday;
- val |= bin2bcd(tm->tm_mday) << RZN1_RTC_CAL_DAY_SHIFT;
- val |= bin2bcd(tm->tm_mon + 1) << RZN1_RTC_CAL_MON_SHIFT;
- val |= bin2bcd(tm->tm_year - 100) << RZN1_RTC_CAL_YEAR_SHIFT;
+ val = FIELD_PREP(RZN1_RTC_CAL_WDAY, tm->tm_wday) |
+ FIELD_PREP(RZN1_RTC_CAL_DAY, bin2bcd(tm->tm_mday)) |
+ FIELD_PREP(RZN1_RTC_CAL_MON, bin2bcd(tm->tm_mon + 1)) |
+ FIELD_PREP(RZN1_RTC_CAL_YEAR, bin2bcd(tm->tm_year - 100));
writel(val, rtc->base + RZN1_RTC_CAL);
writel(0, rtc->base + RZN1_RTC_CTL2);
@@ -306,7 +312,7 @@ static int rzn1_rtc_read_offset(struct device *dev, long *offset)
val = readl(rtc->base + RZN1_RTC_SUBU);
ppb_per_step = val & RZN1_RTC_SUBU_DEV ? 1017 : 3051;
subtract = val & RZN1_RTC_SUBU_DECR;
- val &= 0x3F;
+ val = FIELD_GET(RZN1_RTC_SUBU_RTCA0FX, val);
if (!val)
*offset = 0;
--
2.54.0
^ permalink raw reply related
* [PATCH 10/12] rtc: rzn1: Consistently use dev_err_probe()
From: Prabhakar @ 2026-06-15 15:48 UTC (permalink / raw)
To: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Use dev_err_probe() in the IRQ request error path to make error handling
consistent with the rest of rzn1_rtc_probe().
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/rtc/rtc-rzn1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
index 25cad9213147..c7ef3c81180f 100644
--- a/drivers/rtc/rtc-rzn1.c
+++ b/drivers/rtc/rtc-rzn1.c
@@ -477,7 +477,7 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
ret = devm_request_irq(dev, irq, rzn1_rtc_alarm_irq, 0, "RZN1 RTC Alarm", rtc);
if (ret) {
- dev_err(dev, "RTC alarm interrupt not available\n");
+ dev_err_probe(dev, ret, "RTC alarm interrupt not available\n");
goto dis_runtime_pm;
}
--
2.54.0
^ permalink raw reply related
* [PATCH 07/12] rtc: rzn1: fix alarm range check truncation on 32-bit systems
From: Prabhakar @ 2026-06-15 15:48 UTC (permalink / raw)
To: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
alarm and farest were declared as unsigned long, but
rtc_tm_to_time64() returns time64_t (s64). On 32-bit systems where
unsigned long is 32 bits, the assignment silently truncates the upper
32 bits of the timestamp.
Fix by declaring alarm and farest as time64_t and replacing
time_after() with a direct signed comparison, which is correct for
time64_t values that will never realistically overflow.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/rtc/rtc-rzn1.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
index fe21fa624288..06339adae71f 100644
--- a/drivers/rtc/rtc-rzn1.c
+++ b/drivers/rtc/rtc-rzn1.c
@@ -21,6 +21,7 @@
#include <linux/pm_runtime.h>
#include <linux/rtc.h>
#include <linux/spinlock.h>
+#include <linux/time64.h>
#define RZN1_RTC_CTL0 0x00
#define RZN1_RTC_CTL0_SLSB_SCMP BIT(4)
@@ -265,8 +266,8 @@ static int rzn1_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
{
struct rzn1_rtc *rtc = dev_get_drvdata(dev);
struct rtc_time *tm = &alrm->time, tm_now;
- unsigned long alarm, farest;
unsigned int days_ahead, wday;
+ time64_t alarm, farest;
int ret;
ret = rzn1_rtc_read_time(dev, &tm_now);
@@ -276,7 +277,7 @@ static int rzn1_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
/* We cannot set alarms more than one week ahead */
farest = rtc_tm_to_time64(&tm_now) + rtc->rtcdev->alarm_offset_max;
alarm = rtc_tm_to_time64(tm);
- if (time_after(alarm, farest))
+ if (alarm > farest)
return -ERANGE;
/* Convert alarm day into week day */
--
2.54.0
^ permalink raw reply related
* [PATCH 09/12] rtc: rzn1: Use temporary variable for struct device
From: Prabhakar @ 2026-06-15 15:48 UTC (permalink / raw)
To: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Use a temporary variable for the struct device pointers to avoid
dereferencing.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/rtc/rtc-rzn1.c | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
index bc6af59744e4..25cad9213147 100644
--- a/drivers/rtc/rtc-rzn1.c
+++ b/drivers/rtc/rtc-rzn1.c
@@ -386,13 +386,14 @@ static const struct rtc_class_ops rzn1_rtc_ops_scmp = {
static int rzn1_rtc_probe(struct platform_device *pdev)
{
+ struct device *dev = &pdev->dev;
struct rzn1_rtc *rtc;
u32 val, scmp_val = 0;
struct clk *xtal;
unsigned long rate;
int irq, ret;
- rtc = devm_kzalloc(&pdev->dev, sizeof(*rtc), GFP_KERNEL);
+ rtc = devm_kzalloc(dev, sizeof(*rtc), GFP_KERNEL);
if (!rtc)
return -ENOMEM;
@@ -400,14 +401,14 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
rtc->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(rtc->base))
- return dev_err_probe(&pdev->dev, PTR_ERR(rtc->base), "Missing reg\n");
+ return dev_err_probe(dev, PTR_ERR(rtc->base), "Missing reg\n");
irq = platform_get_irq_byname(pdev, "alarm");
if (irq < 0)
return irq;
rtc->alarm_irq = irq;
- rtc->rtcdev = devm_rtc_allocate_device(&pdev->dev);
+ rtc->rtcdev = devm_rtc_allocate_device(dev);
if (IS_ERR(rtc->rtcdev))
return PTR_ERR(rtc->rtcdev);
@@ -415,15 +416,15 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
rtc->rtcdev->range_max = RTC_TIMESTAMP_END_2099;
rtc->rtcdev->alarm_offset_max = 7 * 86400;
- ret = devm_pm_runtime_enable(&pdev->dev);
+ ret = devm_pm_runtime_enable(dev);
if (ret < 0)
return ret;
- ret = pm_runtime_resume_and_get(&pdev->dev);
+ ret = pm_runtime_resume_and_get(dev);
if (ret < 0)
return ret;
/* Only switch to scmp if we have an xtal clock with a valid rate and != 32768 */
- xtal = devm_clk_get_optional(&pdev->dev, "xtal");
+ xtal = devm_clk_get_optional(dev, "xtal");
if (IS_ERR(xtal)) {
ret = PTR_ERR(xtal);
goto dis_runtime_pm;
@@ -474,9 +475,9 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
spin_lock_init(&rtc->ctl1_access_lock);
- ret = devm_request_irq(&pdev->dev, irq, rzn1_rtc_alarm_irq, 0, "RZN1 RTC Alarm", rtc);
+ ret = devm_request_irq(dev, irq, rzn1_rtc_alarm_irq, 0, "RZN1 RTC Alarm", rtc);
if (ret) {
- dev_err(&pdev->dev, "RTC alarm interrupt not available\n");
+ dev_err(dev, "RTC alarm interrupt not available\n");
goto dis_runtime_pm;
}
@@ -486,18 +487,18 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
goto dis_runtime_pm;
}
if (irq >= 0)
- ret = devm_request_irq(&pdev->dev, irq, rzn1_rtc_1s_irq, 0, "RZN1 RTC 1s", rtc);
+ ret = devm_request_irq(dev, irq, rzn1_rtc_1s_irq, 0, "RZN1 RTC 1s", rtc);
if (irq < 0 || ret) {
set_bit(RTC_FEATURE_ALARM_RES_MINUTE, rtc->rtcdev->features);
clear_bit(RTC_FEATURE_UPDATE_INTERRUPT, rtc->rtcdev->features);
- dev_warn(&pdev->dev, "RTC pps interrupt not available. Alarm has only minute accuracy\n");
+ dev_warn(dev, "RTC pps interrupt not available. Alarm has only minute accuracy\n");
rtc->sec_irq = -ENXIO;
} else {
rtc->sec_irq = irq;
}
- device_init_wakeup(&pdev->dev, true);
+ device_init_wakeup(dev, true);
ret = devm_rtc_register_device(rtc->rtcdev);
if (ret)
@@ -506,7 +507,7 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
return 0;
dis_runtime_pm:
- pm_runtime_put(&pdev->dev);
+ pm_runtime_put(dev);
return ret;
}
--
2.54.0
^ permalink raw reply related
* [PATCH 08/12] rtc: rzn1: Dynamically calculate synchronization delay based on clock rate
From: Prabhakar @ 2026-06-15 15:48 UTC (permalink / raw)
To: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Replace the hardcoded hardware synchronization delays with a calculated
time window derived from the operating sub-clock frequency.
The driver currently hardcodes microsecond ranges assuming a fixed
sub-clock frequency of 32.768 kHz. Newer SoC variants, such as the
RZ/T2H, drive this hardware block using a much faster clock rate
(~195.3 kHz). Hardcoding these wait windows forces faster blocks to
over-sleep, introducing unnecessary delays during clock initialization
and register configuration.
Calculate the duration of the required clock cycles in microseconds based
on the runtime clock rate, and store this value in the driver private
structure to adjust the usleep_range() and readl_poll_timeout() boundaries
dynamically.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/rtc/rtc-rzn1.c | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
index 06339adae71f..bc6af59744e4 100644
--- a/drivers/rtc/rtc-rzn1.c
+++ b/drivers/rtc/rtc-rzn1.c
@@ -71,6 +71,7 @@ struct rzn1_rtc {
*/
spinlock_t ctl1_access_lock;
struct rtc_time tm_alarm;
+ unsigned long sync_time;
int alarm_irq;
int sec_irq;
bool alarm_enabled;
@@ -124,8 +125,8 @@ static int rzn1_rtc_set_time(struct device *dev, struct rtc_time *tm)
/* Hold the counter if it was counting up */
writel(RZN1_RTC_CTL2_WAIT, rtc->base + RZN1_RTC_CTL2);
- /* Wait for the counter to stop: two 32k clock cycles */
- usleep_range(61, 100);
+ /* Wait for the counter to stop: two RTC_PCLK clock cycles */
+ usleep_range(rtc->sync_time, rtc->sync_time + 100);
ret = readl_poll_timeout(rtc->base + RZN1_RTC_CTL2, val,
val & RZN1_RTC_CTL2_WST, 0, 100);
if (ret)
@@ -433,17 +434,25 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
ret = -EOPNOTSUPP;
goto dis_runtime_pm;
}
-
if (rate != 32768)
scmp_val = RZN1_RTC_CTL0_SLSB_SCMP;
+
+ /*
+ * The internal clock counter operates in synchronization with the
+ * RTC_PCLK clock. Calculate the duration of two RTC_PCLK clock
+ * cycles in microseconds required for operations to complete.
+ */
+ rtc->sync_time = DIV_ROUND_UP(2 * NSEC_PER_MSEC, rate);
+
}
/* Disable controller during SUBU/SCMP setup */
val = readl(rtc->base + RZN1_RTC_CTL0) & ~RZN1_RTC_CTL0_CE;
writel(val, rtc->base + RZN1_RTC_CTL0);
- /* Wait 2-4 32k clock cycles for the disabled controller */
+ /* Wait 2-4 RTC_PCLK clock cycles for the disabled controller to stop */
ret = readl_poll_timeout(rtc->base + RZN1_RTC_CTL0, val,
- !(val & RZN1_RTC_CTL0_CEST), 62, 123);
+ !(val & RZN1_RTC_CTL0_CEST), rtc->sync_time,
+ rtc->sync_time * 2);
if (ret)
goto dis_runtime_pm;
--
2.54.0
^ permalink raw reply related
* [PATCH 06/12] rtc: rzn1: Sort headers alphabetically
From: Prabhakar @ 2026-06-15 15:47 UTC (permalink / raw)
To: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Sorting headers alphabetically helps locating duplicates, and make it
easier to figure out where to insert new headers.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/rtc/rtc-rzn1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
index 12a319e9112c..fe21fa624288 100644
--- a/drivers/rtc/rtc-rzn1.c
+++ b/drivers/rtc/rtc-rzn1.c
@@ -15,8 +15,8 @@
#include <linux/clk.h>
#include <linux/init.h>
#include <linux/iopoll.h>
-#include <linux/module.h>
#include <linux/mod_devicetable.h>
+#include <linux/module.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/rtc.h>
--
2.54.0
^ permalink raw reply related
* [PATCH 05/12] rtc: rzn1: Add system suspend/resume support and wakeup capability
From: Prabhakar @ 2026-06-15 15:47 UTC (permalink / raw)
To: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Add system-wide power management support along with wakeup capability to
the rtc-rzn1 driver.
The hardware alarm module inside this RTC variant lacks a dedicated seconds
match register, meaning native hardware alarms can only be programmed with
minute-level granularity. For awake states, the driver bridges sub-minute
gaps by switching from a standard alarm interrupt (ALME) to a 1-second
periodic broadcast loop (1SE).
To support device wakeup from low-power states, initialize the device as a
system wakeup source during probe and configure both the hardware alarm IRQ
and the 1-second periodic IRQ as wakeup sources via enable_irq_wake() in the
suspend path. Because of hardware tracking design constraints across the
internal timer blocks, precise point-in-time wakeup alignment cannot be
guaranteed. Emit an explicit warning message during system suspend to notify
the user of this architectural layout limitation.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/rtc/rtc-rzn1.c | 80 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 80 insertions(+)
diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
index 866ff595188d..12a319e9112c 100644
--- a/drivers/rtc/rtc-rzn1.c
+++ b/drivers/rtc/rtc-rzn1.c
@@ -70,6 +70,9 @@ struct rzn1_rtc {
*/
spinlock_t ctl1_access_lock;
struct rtc_time tm_alarm;
+ int alarm_irq;
+ int sec_irq;
+ bool alarm_enabled;
};
static void rzn1_rtc_get_time_snapshot(struct rzn1_rtc *rtc, struct rtc_time *tm)
@@ -219,6 +222,8 @@ static int rzn1_rtc_alarm_irq_enable(struct device *dev, unsigned int enable)
writel(ctl1, rtc->base + RZN1_RTC_CTL1);
}
+ rtc->alarm_enabled = enable;
+
return 0;
}
@@ -398,6 +403,7 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
irq = platform_get_irq_byname(pdev, "alarm");
if (irq < 0)
return irq;
+ rtc->alarm_irq = irq;
rtc->rtcdev = devm_rtc_allocate_device(&pdev->dev);
if (IS_ERR(rtc->rtcdev))
@@ -476,8 +482,13 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
set_bit(RTC_FEATURE_ALARM_RES_MINUTE, rtc->rtcdev->features);
clear_bit(RTC_FEATURE_UPDATE_INTERRUPT, rtc->rtcdev->features);
dev_warn(&pdev->dev, "RTC pps interrupt not available. Alarm has only minute accuracy\n");
+ rtc->sec_irq = -ENXIO;
+ } else {
+ rtc->sec_irq = irq;
}
+ device_init_wakeup(&pdev->dev, true);
+
ret = devm_rtc_register_device(rtc->rtcdev);
if (ret)
goto dis_runtime_pm;
@@ -500,6 +511,74 @@ static void rzn1_rtc_remove(struct platform_device *pdev)
pm_runtime_put(&pdev->dev);
}
+static int rzn1_rtc_suspend(struct device *dev)
+{
+ struct rzn1_rtc *rtc = dev_get_drvdata(dev);
+ int ret;
+
+ if (!device_may_wakeup(dev))
+ return 0;
+
+ /*
+ * Note on HW Wakeup Granularity Limitations:
+ * True second-level accuracy cannot be guaranteed for device wakeups due
+ * to hardware design tracking limitations across the three available blocks:
+ * - Alarm Interrupt (RTC_ALM): Only matches on day-of-week, hour, and minute.
+ * It completely lacks a seconds comparator field.
+ * - 1-Second Interrupt (RTC_1S): A free-running broadcast that fires every
+ * second. Activating it as a wakeup source triggers an immediate resume
+ * on the very next 1-second boundary, bypassing target accuracy.
+ * - Fixed Interval Interrupt (RTC_PRD): Periodic broadcast options (0.25s,
+ * 0.5s, 1s, 1min, 1hr, 1day, or 1month) lack point-in-time matching,
+ * offering no targeted relief.
+ *
+ * Consequently, due to the absence of a seconds comparator, if a wakeup is
+ * requested within the current minute, the system will resume on the very next
+ * 1-second tick regardless of the actual target alarm time. When the alarm
+ * target is scheduled for a future minute, the system will resume early at the
+ * start of that target minute boundary (00 seconds), failing to guarantee
+ * second-level accuracy for the initial hardware wakeup event.
+ */
+ if (rtc->alarm_enabled)
+ dev_crit(dev, "second/minute-level wakeup accuracy cannot be guaranteed by HW\n");
+ ret = enable_irq_wake(rtc->alarm_irq);
+ if (ret)
+ return ret;
+ if (rtc->sec_irq >= 0) {
+ ret = enable_irq_wake(rtc->sec_irq);
+ if (ret) {
+ disable_irq_wake(rtc->alarm_irq);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+static int rzn1_rtc_resume(struct device *dev)
+{
+ struct rzn1_rtc *rtc = dev_get_drvdata(dev);
+ int ret;
+
+ if (!device_may_wakeup(dev))
+ return 0;
+
+ ret = disable_irq_wake(rtc->alarm_irq);
+ if (ret)
+ return ret;
+ if (rtc->sec_irq >= 0) {
+ ret = disable_irq_wake(rtc->sec_irq);
+ if (ret) {
+ enable_irq_wake(rtc->alarm_irq);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+static DEFINE_SIMPLE_DEV_PM_OPS(rzn1_rtc_pm_ops, rzn1_rtc_suspend, rzn1_rtc_resume);
+
static const struct of_device_id rzn1_rtc_of_match[] = {
{ .compatible = "renesas,rzn1-rtc" },
{},
@@ -512,6 +591,7 @@ static struct platform_driver rzn1_rtc_driver = {
.driver = {
.name = "rzn1-rtc",
.of_match_table = rzn1_rtc_of_match,
+ .pm = pm_ptr(&rzn1_rtc_pm_ops),
},
};
module_platform_driver(rzn1_rtc_driver);
--
2.54.0
^ permalink raw reply related
* [PATCH 04/12] rtc: Kconfig: Broaden RTC_DRV_RZN1 dependency to ARCH_RENESAS
From: Prabhakar @ 2026-06-15 15:47 UTC (permalink / raw)
To: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Replace the ARCH_RZN1 dependency with ARCH_RENESAS for the RTC_DRV_RZN1
config option to make the driver available across both ARM32 and ARM64
Renesas architectures.
The newer RZ/T2H and RZ/N2H ARM64 SoCs integrate a closely related variant
of the RTC IP block found on the RZ/N1 SoCs. Update the build dependency
and expand the Kconfig help text to allow this driver to be selected for
these additional platforms.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/rtc/Kconfig | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 364afc73f8ab..764f8b9ff742 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1635,10 +1635,11 @@ config RTC_DRV_RS5C313
config RTC_DRV_RZN1
tristate "Renesas RZ/N1 RTC"
- depends on ARCH_RZN1 || COMPILE_TEST
+ depends on ARCH_RENESAS || COMPILE_TEST
depends on OF && HAS_IOMEM
help
- If you say yes here you get support for the Renesas RZ/N1 RTC.
+ If you say yes here you get support for the RTC found on Renesas RZ/N1,
+ RZ/N2H, and RZ/T2H SoCs.
config RTC_DRV_GENERIC
tristate "Generic RTC support"
--
2.54.0
^ permalink raw reply related
* [PATCH 03/12] rtc: rzn1: Fix malformed MODULE_AUTHOR string
From: Prabhakar @ 2026-06-15 15:47 UTC (permalink / raw)
To: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Fix a malformed MODULE_AUTHOR macro in the rtc-rzn1 driver where a missing
closing angle bracket on the second author entry creates an invalid format.
Correct it to the standard "Name <email>" format.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/rtc/rtc-rzn1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
index f81d691c8b9a..866ff595188d 100644
--- a/drivers/rtc/rtc-rzn1.c
+++ b/drivers/rtc/rtc-rzn1.c
@@ -517,6 +517,6 @@ static struct platform_driver rzn1_rtc_driver = {
module_platform_driver(rzn1_rtc_driver);
MODULE_AUTHOR("Michel Pollet <buserror@gmail.com>");
-MODULE_AUTHOR("Miquel Raynal <miquel.raynal@bootlin.com");
+MODULE_AUTHOR("Miquel Raynal <miquel.raynal@bootlin.com>");
MODULE_DESCRIPTION("RZ/N1 RTC driver");
MODULE_LICENSE("GPL");
--
2.54.0
^ permalink raw reply related
* [PATCH 02/12] rtc: rzn1: Handle EPROBE_DEFER for optional pps interrupt
From: Prabhakar @ 2026-06-15 15:47 UTC (permalink / raw)
To: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar, stable
In-Reply-To: <20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Check for -EPROBE_DEFER from platform_get_irq_byname_optional() and handle
the deferred probe request properly.
Although the "pps" interrupt is optional, an error code of -EPROBE_DEFER
indicates that the interrupt subsystem is not yet ready. Intercept this
specific error condition, assign it to the return value, and jump to the
dis_runtime_pm label to avoid ignoring a valid probe deferral.
Fixes: eea7791e00f33 ("rtc: rzn1: implement one-second accuracy for alarms")
Cc: stable@vger.kernel.org
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/rtc/rtc-rzn1.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
index c4ed43735457..f81d691c8b9a 100644
--- a/drivers/rtc/rtc-rzn1.c
+++ b/drivers/rtc/rtc-rzn1.c
@@ -465,6 +465,10 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
}
irq = platform_get_irq_byname_optional(pdev, "pps");
+ if (irq == -EPROBE_DEFER) {
+ ret = irq;
+ goto dis_runtime_pm;
+ }
if (irq >= 0)
ret = devm_request_irq(&pdev->dev, irq, rzn1_rtc_1s_irq, 0, "RZN1 RTC 1s", rtc);
--
2.54.0
^ permalink raw reply related
* [PATCH 01/12] dt-bindings: rtc: renesas,rzn1-rtc: Add RZ/T2H and RZ/N2H support
From: Prabhakar @ 2026-06-15 15:47 UTC (permalink / raw)
To: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Add compatible strings for the RTC block found on the Renesas RZ/T2H
(R9A09G077) and RZ/N2H (R9A09G087) SoCs.
These SoCs integrate a closely related variant of the RZ/N1 RTC IP.
Unlike RZ/N1, they do not implement the RTCA0SUBU and RTCA0TCR
registers. This is not a limitation for Linux support, as these
registers are not used when the RTC operates in "scmp" clock mode, which
is required on RZ/T2H and RZ/N2H due to their 195.3 kHz input clock.
The RZ/T2H RTC variant also supports a 1Hz output signal on the
RTCAT1HZ pin, controlled by the RTCA0CTL1[RTCA01HZE] bit. This bit is
marked as reserved in the RZ/N1 hardware manual.
Update the binding schema to require the additional clock inputs used by
these SoCs.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
.../bindings/rtc/renesas,rzn1-rtc.yaml | 35 +++++++++++++++----
1 file changed, 28 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/renesas,rzn1-rtc.yaml b/Documentation/devicetree/bindings/rtc/renesas,rzn1-rtc.yaml
index 1860f0e4c31a..ea7b039a91e7 100644
--- a/Documentation/devicetree/bindings/rtc/renesas,rzn1-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/renesas,rzn1-rtc.yaml
@@ -9,15 +9,19 @@ title: Renesas RZ/N1 SoCs Real-Time Clock
maintainers:
- Miquel Raynal <miquel.raynal@bootlin.com>
-allOf:
- - $ref: rtc.yaml#
-
properties:
compatible:
- items:
- - enum:
- - renesas,r9a06g032-rtc
- - const: renesas,rzn1-rtc
+ oneOf:
+ - items:
+ - enum:
+ - renesas,r9a06g032-rtc
+ - const: renesas,rzn1-rtc
+
+ - const: renesas,r9a09g077-rtc
+
+ - items:
+ - const: renesas,r9a09g087-rtc
+ - const: renesas,r9a09g077-rtc
reg:
maxItems: 1
@@ -54,6 +58,23 @@ required:
- clock-names
- power-domains
+allOf:
+ - $ref: rtc.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,r9a09g077-rtc
+ - renesas,r9a09g087-rtc
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ clock-names:
+ minItems: 2
+
unevaluatedProperties: false
examples:
--
2.54.0
^ permalink raw reply related
* [PATCH 00/12] Add RTC support for Renesas RZ/T2H and RZ/N2H SoCs
From: Prabhakar @ 2026-06-15 15:47 UTC (permalink / raw)
To: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi all,
This series adds support for the RTC IP found on the Renesas RZ/T2H and
RZ/N2H SoCs.
The RTC block is closely related to the RZ/N1 implementation and can
reuse the existing driver infrastructure when operating in SCMP mode,
which is required on these SoCs due to their 195.3 kHz RTC input clock.
While the RZ/T2H and RZ/N2H variants do not implement the RTCA0SUBU and
RTCA0TCR registers present on RZ/N1, those registers are not accessed by
the driver in SCMP mode, allowing support to be added with minimal
changes.
The RZ/T2H RTC variant also supports a 1 Hz output signal on the
RTCAT1HZ pin, controlled by the RTCA0CTL1[RTCA01HZE] bit. This bit is
marked as reserved in the RZ/N1 hardware manual, making RZ/T2H a
distinct RTC variant despite its overall compatibility with the RZ/N1
implementation.
The series consists of:
dt-bindings updates to describe the RZ/T2H and RZ/N2H RTC variants,
driver updates to recognize the new compatible string and enable
support for these SoCs.
Cheers,
Prabhakar
Lad Prabhakar (12):
dt-bindings: rtc: renesas,rzn1-rtc: Add RZ/T2H and RZ/N2H support
rtc: rzn1: Handle EPROBE_DEFER for optional pps interrupt
rtc: rzn1: Fix malformed MODULE_AUTHOR string
rtc: Kconfig: Broaden RTC_DRV_RZN1 dependency to ARCH_RENESAS
rtc: rzn1: Add system suspend/resume support and wakeup capability
rtc: rzn1: Sort headers alphabetically
rtc: rzn1: fix alarm range check truncation on 32-bit systems
rtc: rzn1: Dynamically calculate synchronization delay based on clock
rate
rtc: rzn1: Use temporary variable for struct device
rtc: rzn1: Consistently use dev_err_probe()
rtc: rzn1: use FIELD_PREP/FIELD_GET and GENMASK for register access
rtc: rzn1: Add support for Renesas RZ/T2H and RZ/N2H SoCs
.../bindings/rtc/renesas,rzn1-rtc.yaml | 35 +++-
drivers/rtc/Kconfig | 5 +-
drivers/rtc/rtc-rzn1.c | 182 ++++++++++++++----
3 files changed, 173 insertions(+), 49 deletions(-)
--
2.54.0
^ permalink raw reply
* Re: [PATCH v2 7/8] dt-bindings: display: allwinner: Split H616 DE33 layer reg space
From: Jernej Škrabec @ 2026-06-15 15:47 UTC (permalink / raw)
To: wens, Krzysztof Kozlowski
Cc: samuel, mripard, maarten.lankhorst, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt, mturquette, sboyd, dri-devel, devicetree,
linux-arm-kernel, linux-sunxi, linux-kernel, linux-clk
In-Reply-To: <86943057-f5b4-4fae-9172-45f13814494f@kernel.org>
Dne ponedeljek, 15. junij 2026 ob 06:28:54 Srednjeevropski poletni čas je Krzysztof Kozlowski napisal(a):
> On 14/06/2026 16:08, Jernej Škrabec wrote:
> > Dne ponedeljek, 25. maj 2026 ob 14:10:38 Srednjeevropski poletni čas je Krzysztof Kozlowski napisal(a):
> >> On 24/05/2026 23:33, Chen-Yu Tsai wrote:
> >>> Hi,
> >>>
> >>> (resent from new email)
> >>>
> >>> On Thu, May 14, 2026 at 2:04 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>>>
> >>>> On Sat, May 09, 2026 at 09:00:14PM +0200, Jernej Skrabec wrote:
> >>>>> From: Jernej Skrabec <jernej.skrabec@gmail.com>
> >>>>>
> >>>>> As it turns out, current H616 DE33 binding was written based on
> >>>>> incomplete understanding of DE33 design. Namely, planes are shared
> >>>>> resource and not tied to specific mixer, which was the case for previous
> >>>>> generations of Display Engine (DE3 and earlier).
> >>>>>
> >>>>> This means that current DE33 binding doesn't properly reflect HW and
> >>>>> using it would mean that second mixer (used for second display output)
> >>>>> can't be supported.
> >>>>>
> >>>>> Remove layer register space, which will be represented with additional
> >>>>> node, and replace it with phandle, which will point to that new, shared
> >>>>> node. That way, all mixers can share same layers.
> >>>>>
> >>>>> There is no user of this binding yet, so changes can be made safely,
> >>>>> without breaking any backward compatibility.
> >>>>
> >>>> There is user. git grep gives me:
> >>>> drivers/gpu/drm/sun4i/sun8i_mixer.c
> >>>>
> >>>> which means this is a released ABI. As I understood, the old code was
> >>>
> >>> We held off on merging the DT changes so that we could rework this.
> >>> I can't find the actual request though. It was probably over IRC.
> >>>
> >>>> working fine but just did not support all use cases. Why this cannot be
> >>>> kept backwards compatible?
> >>>
> >>> AFAIK the "planes" block is shared between two display mixers. As the
> >>> commit message explains, this prevents using the second mixer, since
> >>> only one of them can claim and map the register space. And on the H700
> >>> (which is the same die as the H616 discussed here but with more exposed
> >>> interfaces), there could actually be a use case for the second mixer.
> >>
> >> It explains why you want to make the changes but not why you cannot keep
> >> it backwards compatible.
> >
> > I guess it can be backward compatible, but I don't think it makes sense.
> > Yes, original driver implemented original DT bindings, but there is no node
> > which uses that binding. If there is no user of that, why would driver
>
> Did you check all out of tree users of the ABI? All vendor kernels,
> forks and all of them for which the ABI was made for?
Since when do we care about out of tree users? I understand that drivers
must support old device tree files. Once they work, compatibility must
be carried forward. But that's not the case here.
In any case, vendor kernels have completely different DT structure. This
was developed independently from them. Take a look at [1] how BSP DT looks
like, specifically Display Engine node.
Of course there are some distros which grab WIP patches from mailing lists
soon after they are available. For example, I know that Armbian carried old
WIP patches which used old ABI. However, such distros generally don't care
about exact solution and ditch patches as soon as proper solution is merged
upstream or even when better WIP patches come around. DT files in such
distros get updated alongside kernel, they are not hidden in firmware.
Best regards,
Jernej
[1] https://github.com/orangepi-xunlong/linux-orangepi/blob/orange-pi-4.9-sun50iw9/arch/arm64/boot/dts/sunxi/sun50iw9p1.dtsi#L1315-L1339
>
> If there is no single downstream/out of tree kernel using this ABI, then
> of course you do not need to consider it. I don't know how would you
> prove that but I am open for suggestions.
>
> > need to support it nevertheless? Supporting only actually used DT binding
> > allows for better code architecture, as there is no need to support second,
> > unused path. It also simplifies testing, since developer doesn't need to
> > test both paths if code is changed in that area.
> >
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v7 4/5] iio: adc: versal-sysmon: add threshold event support
From: Erim, Salih @ 2026-06-15 15:45 UTC (permalink / raw)
To: Andy Shevchenko
Cc: jic23, andy, dlechner, nuno.sa, robh, krzk+dt, conor+dt,
conall.ogriofa, michal.simek, linux, erimsalih, linux-iio,
devicetree, linux-kernel
In-Reply-To: <ajAPh4xKqxRyIpBe@ashevche-desk.local>
Hi Andy,
Thanks for the review, replies inline.
On 15/06/2026 15:43, Andy Shevchenko wrote:
> On Mon, Jun 15, 2026 at 12:37:21AM +0100, Salih Erim wrote:
>> Add threshold event support for temperature and supply voltage
>> channels.
>>
>> Temperature events:
>> - Rising threshold with configurable value on the device
>> temperature channel (current max across all satellites)
>> - Per-channel hysteresis as a millicelsius value
>> - Event direction is IIO_EV_DIR_RISING (hysteresis mode)
>>
>> Supply voltage events:
>> - Rising/falling threshold per supply channel
>> - Per-channel alarm enable via alarm configuration registers
>>
>> The hardware supports both window and hysteresis alarm modes for
>> temperature. This driver uses hysteresis mode, where the upper
>> threshold triggers the alarm and the lower threshold clears it
>> (re-arm point). The hardware has a single ISR bit per temperature
>> channel with no indication of which threshold was crossed, so
>> hysteresis mode is the natural fit. The lower threshold register
>> is computed internally as (upper - hysteresis).
>>
>> Hysteresis is stored in the driver as a millicelsius value,
>> initialized from the hardware registers at probe. Writing the
>> rising threshold or hysteresis recomputes the lower register.
>> ALARM_CONFIG is hard-coded to hysteresis mode during init.
>>
>> The hardware also provides a separate over-temperature (OT)
>> threshold, but it is not exposed through IIO as it serves as a
>> hardware safety mechanism for platform shutdown. OT will be
>> exposed through the thermal framework in a follow-up series.
>>
>> The interrupt handler masks active threshold interrupts (which are
>> level-sensitive) and schedules a delayed worker to poll for condition
>> clear before unmasking. When no hardware IRQ is available, event
>> specs are not attached and interrupt init is skipped, since the
>> I2C regmap backend cannot be called from atomic context.
>>
>> When disabling a supply channel alarm, the group interrupt remains
>> active if any other channel in the same alarm group still has an
>> alarm enabled.
>>
>> A devm cleanup action masks all interrupts on driver unbind to
>> prevent unhandled interrupt storms after the IRQ handler is freed.
>
> ...
>
>> +static void sysmon_q8p7_to_millicelsius(s16 raw_data, int *val)
>> +{
>> + *val = (raw_data * (int)MILLI) >> SYSMON_FRACTIONAL_SHIFT;
>
> MILLIDEGREE_PER_DEGREE is defined as int.
Will use MILLIDEGREE_PER_DEGREE in both q8p7 conversion functions.
>
>> +}
>> +
>> +static void sysmon_millicelsius_to_q8p7(u32 *raw_data, int val)
>> +{
>> + *raw_data = (val << SYSMON_FRACTIONAL_SHIFT) / (int)MILLI;
>
> Ditto.
>
>> +}
>
> ...
>
>> +static void sysmon_supply_processedtoraw(int val, u32 reg_val, u32 *raw_data)
>> +{
>> + int exponent = FIELD_GET(SYSMON_MODE_MASK, reg_val);
>> + int format = FIELD_GET(SYSMON_FMT_MASK, reg_val);
>> + int scale, tmp;
>> +
>> + scale = BIT(SYSMON_SUPPLY_MANTISSA_BITS - exponent);
>> + tmp = (val * scale) / (int)MILLI;
>
> Due to agnosticism of this function, I dunno if the above can be applied here.
Agreed, this converts millivolts, not millicelsius.
MILLI with the (int) cast is correct here.
>
>> + if (format)
>> + tmp = clamp(tmp, S16_MIN, S16_MAX);
>> + else
>> + tmp = clamp(tmp, 0, U16_MAX);
>> +
>> + *raw_data = (u16)tmp;
>> +}
>
> ...
>
>> +static int sysmon_read_alarm_config(struct sysmon *sysmon,
>> + unsigned long address)
>> +{
>> + u32 shift = address % SYSMON_ALARM_BITS_PER_REG;
>> + u32 offset = SYSMON_ALARM_OFFSET(address);
>> + unsigned int reg_val;
>> + int ret;
>> +
>> + ret = regmap_read(sysmon->regmap, offset, ®_val);
>> + if (ret)
>> + return ret;
>> +
>> + return !!(reg_val & BIT(shift));
>
> regmap_test_bits()?
Will switch to regmap_test_bits(). This simplifies the whole
function to a single return statement.
>
>> +}
>
> ...
>
>> -static int sysmon_parse_fw(struct iio_dev *indio_dev, struct device *dev)
>> +static int sysmon_parse_fw(struct iio_dev *indio_dev, struct device *dev,
>> + int irq)
>
> I would leave one line (82 characters IIANM).
Will join onto one line.
Thanks,
Salih
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v7 3/5] iio: adc: versal-sysmon: add I2C driver
From: Erim, Salih @ 2026-06-15 15:42 UTC (permalink / raw)
To: Andy Shevchenko
Cc: jic23, andy, dlechner, nuno.sa, robh, krzk+dt, conor+dt,
conall.ogriofa, michal.simek, linux, erimsalih, linux-iio,
devicetree, linux-kernel
In-Reply-To: <ajAMjZzfTqplts_B@ashevche-desk.local>
Hi Andy,
On 15/06/2026 15:30, Andy Shevchenko wrote:
> On Mon, Jun 15, 2026 at 12:37:20AM +0100, Salih Erim wrote:
>> Add an I2C transport driver for the Versal SysMon block. The SysMon
>> provides an I2C slave interface that allows an external master to
>> read voltage and temperature measurements through the same register
>> map used by the MMIO path.
>>
>> The I2C command frame is an 8-byte structure containing a 4-byte data
>> payload, a 2-byte register offset, and a 1-byte instruction field.
>> Read operations send the frame with a read instruction, then receive
>> a 4-byte response containing the register value.
>>
>> Events are not supported on the I2C path because there is no
>> interrupt line and the I2C regmap backend cannot be called from
>> atomic context.
>
> ...
>
>> +static const struct regmap_config sysmon_i2c_regmap_config = {
>> + .reg_bits = 32,
>> + .val_bits = 32,
>> + .reg_stride = SYSMON_REG_STRIDE,
>> + .max_register = SYSMON_MAX_REG,
>> + .reg_read = sysmon_i2c_reg_read,
>> + .reg_write = sysmon_i2c_reg_write,
>> +};
>
> No cache?
No, the registers are live ADC readings and interrupt status.
Caching would return stale voltage and temperature data.
Thanks,
Salih
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v7 2/5] iio: adc: add Versal SysMon driver
From: Erim, Salih @ 2026-06-15 15:41 UTC (permalink / raw)
To: Andy Shevchenko
Cc: jic23, andy, dlechner, nuno.sa, robh, krzk+dt, conor+dt,
conall.ogriofa, michal.simek, linux, erimsalih, linux-iio,
devicetree, linux-kernel
In-Reply-To: <ajAKkqMO5jdQjKgS@ashevche-desk.local>
Hi Andy,
Thanks for the review, replies inline.
On 15/06/2026 15:22, Andy Shevchenko wrote:
> On Mon, Jun 15, 2026 at 12:37:19AM +0100, Salih Erim wrote:
>> Add the core driver and MMIO platform driver for the AMD/Xilinx Versal
>> System Monitor (SysMon) block.
>>
>> The SysMon block resides in the platform management controller (PMC) and
>> provides on-chip voltage and temperature monitoring through a 10-bit,
>> 200 kSPS ADC. It can monitor up to 160 voltage channels and 64
>> temperature satellites distributed across the SoC, with a consistent
>> sample rate of 8 kSPS per channel regardless of how many channels are
>> enabled.
>>
>> The hardware also provides four aggregate temperature registers that
>> are always present regardless of the device tree configuration: the
>> current max and min across all active satellites, and the peak and
>> trough values recorded since the last hardware reset.
>>
>> The driver is split into two compilation units:
>> - versal-sysmon-core: Channel parsing, IIO registration, read_raw
>> - versal-sysmon: MMIO platform driver with custom regmap accessors
>>
>> Voltage results are stored in a 19-bit modified floating-point format
>> and converted to millivolts. Temperature results are stored in Q8.7
>> signed fixed-point Celsius format and converted to millicelsius.
>>
>> The MMIO regmap backend uses a custom reg_write accessor that
>> automatically unlocks the NPI (NoC programming interface) lock
>> register before each write, as required by the hardware. The regmap
>> is configured with fast_io since the underlying MMIO accessors are
>> safe to call from atomic context.
>
> ...
>
>> +static int sysmon_read_raw(struct iio_dev *indio_dev,
>> + struct iio_chan_spec const *chan,
>> + int *val, int *val2, long mask)
>> +{
>> + struct sysmon *sysmon = iio_priv(indio_dev);
>> + unsigned int regval;
>> + int ret;
>> +
>> + guard(mutex)(&sysmon->lock);
>> +
>> + switch (chan->type) {
>> + case IIO_TEMP:
>> + if (mask == IIO_CHAN_INFO_SCALE) {
>> + /* Q8.7 to millicelsius: raw * 1000 / 128 */
>> + *val = MILLI;
>
> Since this is about temperature, wouldn't be better to use
>
> MILLIDEGREE_PER_DEGREE
>
> here?
Agreed, MILLIDEGREE_PER_DEGREE is semantically correct here.
Will change in v8.
>
>> + *val2 = BIT(SYSMON_FRACTIONAL_SHIFT);
>> + return IIO_VAL_FRACTIONAL;
>> + }
>> + if (mask != IIO_CHAN_INFO_RAW)
>> + return -EINVAL;
>> +
>> + ret = regmap_read(sysmon->regmap, chan->address, ®val);
>> + if (ret)
>> + return ret;
>> +
>> + *val = sign_extend32(regval, 15);
>> + return IIO_VAL_INT;
>> +
>> + case IIO_VOLTAGE:
>> + if (mask != IIO_CHAN_INFO_PROCESSED)
>> + return -EINVAL;
>> +
>> + ret = regmap_read(sysmon->regmap,
>> + chan->address * SYSMON_REG_STRIDE +
>> + SYSMON_SUPPLY_BASE, ®val);
>> + if (ret)
>> + return ret;
>> +
>> + sysmon_supply_rawtoprocessed(regval, val);
>> + return IIO_VAL_INT;
>> +
>> + default:
>> + return -EINVAL;
>> + }
>> +}
>
> ...
>
>> +static int sysmon_parse_fw(struct iio_dev *indio_dev, struct device *dev)
>> +{
>> + unsigned int num_chan, idx, temp_chan_idx, volt_chan_idx;
>> + unsigned int num_supply, num_temp;
>> + struct iio_chan_spec *sysmon_channels;
>> + const char *label;
>> + u32 reg;
>> + int ret;
>> +
>> + struct fwnode_handle *supply_node __free(fwnode_handle) =
>> + device_get_named_child_node(dev, "voltage-channels");
>> + num_supply = fwnode_get_child_node_count(supply_node);
>> +
>> + struct fwnode_handle *temp_node __free(fwnode_handle) =
>> + device_get_named_child_node(dev, "temperature-channels");
>> + num_temp = fwnode_get_child_node_count(temp_node);
>> +
>> + num_chan = size_add(num_temp, size_add(ARRAY_SIZE(temp_channels), num_supply));
>
> + overflow.h
Accepted, Will add.
>
>> + sysmon_channels = devm_kcalloc(dev, num_chan, sizeof(*sysmon_channels), GFP_KERNEL);
>> + if (!sysmon_channels)
>> + return -ENOMEM;
>> +
>> + /* Static temperature channels first */
>> + memcpy(sysmon_channels, temp_channels, sizeof(temp_channels));
>> + idx = ARRAY_SIZE(temp_channels);
>> +
>> + /* Supply channels from DT */
>> + fwnode_for_each_child_node_scoped(supply_node, child) {
>> + ret = fwnode_property_read_u32(child, "reg", ®);
>> + if (ret)
>> + return dev_err_probe(dev, ret,
>> + "missing reg for supply channel\n");
>> +
>> + if (reg > SYSMON_SUPPLY_IDX_MAX)
>> + return dev_err_probe(dev, -EINVAL,
>> + "supply reg %u exceeds max %u\n",
>> + reg, SYSMON_SUPPLY_IDX_MAX);
>> +
>> + ret = fwnode_property_read_string(child, "label", &label);
>> + if (ret)
>> + return dev_err_probe(dev, ret,
>> + "missing label for supply channel\n");
>> +
>> + sysmon_channels[idx++] = (struct iio_chan_spec) {
>> + .type = IIO_VOLTAGE,
>> + .indexed = 1,
>> + .address = reg,
>> + .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
>> + .datasheet_name = label,
>> + };
>> + }
>> +
>> + /* Temperature satellite channels from DT */
>> + fwnode_for_each_child_node_scoped(temp_node, child) {
>> + ret = fwnode_property_read_u32(child, "reg", ®);
>> + if (ret)
>> + return dev_err_probe(dev, ret,
>> + "missing reg for temp channel\n");
>> +
>> + if (reg < 1 || reg > SYSMON_TEMP_SAT_MAX)
>> + return dev_err_probe(dev, -EINVAL,
>> + "temp reg %u out of range [1..%u]\n",
>> + reg, SYSMON_TEMP_SAT_MAX);
>> +
>> + ret = fwnode_property_read_string(child, "label", &label);
>> + if (ret)
>> + return dev_err_probe(dev, ret,
>> + "missing label for temp channel\n");
>> +
>> + sysmon_channels[idx++] = (struct iio_chan_spec) {
>> + .type = IIO_TEMP,
>> + .indexed = 1,
>> + .address = SYSMON_TEMP_SAT_BASE +
>> + (reg - 1) * SYSMON_REG_STRIDE,
>> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
>> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),
>> + .datasheet_name = label,
>> + };
>> + }
>> +
>> + indio_dev->num_channels = idx;
>> + indio_dev->info = &sysmon_iio_info;
>> +
>> + /*
>> + * Assign per-type sequential channel numbers.
>> + * IIO sysfs uses type prefix (in_tempN, in_voltageN)
>> + * so numbers only need to be unique within each type.
>> + */
>> + temp_chan_idx = 0;
>> + volt_chan_idx = 0;
>> + for (unsigned int idx = 0; idx < indio_dev->num_channels; idx++) {
>> + if (sysmon_channels[idx].type == IIO_TEMP)
>> + sysmon_channels[idx].channel = temp_chan_idx++;
>> + else
>> + sysmon_channels[idx].channel = volt_chan_idx++;
>> + }
>> +
>> + indio_dev->channels = sysmon_channels;
>> +
>> + return 0;
>> +}
>
> ...
>
>> +/**
>> + * sysmon_core_probe() - Initialize Versal SysMon core
>
> It is managed, please name it accordingly: devm_sysmon_core_probe().
Will rename to devm_sysmon_core_probe() and update callers.
Thanks,
Salih
>
>> + * @dev: Parent device
>> + * @regmap: Register map for hardware access
>> + *
>> + * Return: 0 on success, negative errno on failure.
>> + */
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v3 1/8] dt-bindings: remoteproc: qcom,pas: add thermal mitigation properties
From: Daniel Lezcano @ 2026-06-15 15:33 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Gaurav Kohli, Krzysztof Kozlowski, Bjorn Andersson,
Mathieu Poirier, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Amit Kucheria, Manivannan Sadhasivam, Konrad Dybcio, Kees Cook,
Gustavo A. R. Silva, cros-qcom-dts-watchers, linux-arm-msm,
linux-remoteproc, devicetree, linux-kernel, linux-pm,
linux-hardening, Manaf Meethalavalappu Pallikunhi
In-Reply-To: <mp2hl67rupxrssa43dcy36m3dwatlxsu7n27l7qdqsguo5i3bp@bo6sdzxglxt2>
Le 15/06/2026 à 17:14, Dmitry Baryshkov a écrit :
> On Mon, Jun 15, 2026 at 04:33:38PM +0200, Daniel Lezcano wrote:
>>
>>
>> Le 15/06/2026 à 16:11, Dmitry Baryshkov a écrit :
>>> On Mon, Jun 15, 2026 at 02:30:49PM +0200, Daniel Lezcano wrote:
>>>> Hi Gaurav,
>>>>
>>>> Le 15/06/2026 à 14:12, Gaurav Kohli a écrit :
>>>>>
>>>>>
>>>>> On 6/15/2026 4:04 PM, Daniel Lezcano wrote:
>>>>>> On 6/13/26 13:05, Gaurav Kohli wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 6/13/2026 1:11 PM, Krzysztof Kozlowski wrote:
>>>>>>>> On 12/06/2026 15:52, Gaurav Kohli wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 6/11/2026 5:53 PM, Krzysztof Kozlowski wrote:
>>>>>>>>>> On 11/06/2026 13:12, Gaurav Kohli wrote:
>>>>>>>>>>>> Why? And where is this generic property defined? You cannot just
>>>>>>>>>>>> sprinkle generic properties in random bindings.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Ack, will add why part.
>>>>>>>>>>> These names are matched with the thermal
>>>>>>>>>>> mitigation device identifiers
>>>>>>>>>>> populated by remote firmware over QMI and define
>>>>>>>>>>> mitigation devices are
>>>>>>>>>>> exposed as cooling devices.
>>>>>>>>>>
>>>>>>>>>> No, -names correspond to values passed via DT, not
>>>>>>>>>> some remote firmware.
>>>>>>>>>> The remote firmware should give you interface which
>>>>>>>>>> is explicit and does
>>>>>>>>>> not need such properties.
>>>>>>>>>
>>>>>>>>> thanks Krzysztof for review, We need tmd-names because
>>>>>>>>> of following reasons:
>>>>>>>>>
>>>>>>>>> Following Daniel's series [1], the thermal framework supports
>>>>>>>>> mapping multiple cooling devices per remoteproc/device via indexed
>>>>>>>>> cooling-cells.
>>>>>>>>>
>>>>>>>>> 1) The thermal framework's cooling-maps reference
>>>>>>>>> cooling devices by index (for #cooling-cells = <3>).
>>>>>>>>> Without tmd- names,
>>>>>>>>> there's no way to know which index corresponds to which
>>>>>>>>> TMD, as firmware
>>>>>>>>> may return tmd-names in any order.
>>>>>>>>>
>>>>>>>>> below are the changes post new thermal mapping changes:
>>>>>>>>> DT: tmd-names = "cdsp_sw", "xyz";
>>>>>>>>> Firmware: ["cdsp_sw", "xyz1", "xyz2",]
>>>>>>>>> Driver registers: Only "cdsp_sw" (index 0) and "xyz" (index 1)
>>>>>>>>
>>>>>>>> names property are not to instruct drivers to register or not to
>>>>>>>> register something.
>>>>>>>>
>>>>>>>> I don't understand the problem and explanation in the binding is
>>>>>>>> basically non-existing.
>>>>>>>>
>>>>>>>> Remember that all lists and indices ARE FIXED, so driver knows exactly
>>>>>>>> which index means what.
>>>>>>>>
>>>>>>>
>>>>>>> thanks for review, shall i use driver data, which is basically
>>>>>>> pas data structure like below:
>>>>>>>
>>>>>>> static const struct qcom_pas_data {
>>>>>>> .crash_reason_smem = 601,
>>>>>>> .firmware_name = "cdsp.mdt",
>>>>>>> .tmd_names = (const char *[]){"xyz", NULL},
>>>>>>> .num_tmds = 1,
>>>>>>>
>>>>>>> Is something like above acceptable? and this will also help to
>>>>>>> filter tmd names as well?
>>>>>>
>>>>>>
>>>>>> How the thermal framework will bind the thermal zone with the TMD ?
>>>>>> (node pointer, id) ?
>>>>>>
>>>>>
>>>>> Hi Daniel,
>>>>>
>>>>> thanks for review.
>>>>>
>>>>> With id only, in this case instead of taking tmd names from device tree,
>>>>> qmi_tmd will take tmd name from pas_data(driver) and register with the
>>>>> cooling framework with id only. Please let us know if this looks fine.
>>>> May be I'm missing something but:
>>>>
>>>> - The QMI TMD returns a list of names, not ids
>>>> - The QMI TMD may return the list in different order than assumed
>>>> - The cooling map index points to the name of the TMD in the DT
>>>> - This name is used to match the name in the aformentionned list
>>>> - The index in the list and the id in the DT can differ
>>>
>>> Would it be better if we define standard indices for the standard names?
>>> This way we decouple the actual firmware strings from the DT.
>>
>> I don't think so, it seems to me too fragile and prone to error.
>>
>> It is a remote proc, an external subsystem. The contract between the client
>> and the server is the protocol. The protocol specifies the identifier as
>> named strings, the TMD names, not numerical identifiers.
>>
>> When asking for the list of TMDs, we get a list of strings. But as it is an
>> external subsystems, may be tomorrow someone decide to send list ordered
>> alphabetically, or per number of states, or whatever.
>>
>> With hardcoded id the QMI TMD clients break
>
> I was thinking about something like:
>
> #define QCOM_TMD_DSP 0
> #define QCOM_TMD_PA 1
Ah ok, it is correct if:
tmd-names = "dsp", "pa"
Or
#define QCOM_TMD_PA 0
#define QCOM_TMD_DSP 1
tmd-names = "pa", "dsp"
> cooling-maps {
> map0 {
> cooling-device = <&remoteproc_cdsp QCOM_TMD_DSP 0 2>;
> };
> map1 {
> cooling-device = <&remoteproc_mpss QCOM_TMD_DSP 0 2>;
> };
> map2 {
> cooling-device = <&remoteproc_mpss QCOM_TMD_PA 0 2>;
> };
> };
>
>
>>
>>>> Krzysztof , I don't get why having the TMD names as properties is wrong,
>>>> they describes the existing TMDs on the system and the cooling maps index
>>>> points to the one to be connected with thermal zone.
>>>
>>
>
^ permalink raw reply
* Re: [PATCH v3 4/8] arm64: dts: qcom: kodiak: Enable CDSP & Modem cooling
From: Dmitry Baryshkov @ 2026-06-15 15:25 UTC (permalink / raw)
To: Gaurav Kohli
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Daniel Lezcano, Amit Kucheria,
Manivannan Sadhasivam, Konrad Dybcio, Kees Cook,
Gustavo A. R. Silva, cros-qcom-dts-watchers, linux-arm-msm,
linux-remoteproc, devicetree, linux-kernel, linux-pm,
linux-hardening, Manaf Meethalavalappu Pallikunhi
In-Reply-To: <4006d16f-a159-4f1b-ba80-f19bef8f4c5c@oss.qualcomm.com>
On Mon, Jun 15, 2026 at 11:02:22AM +0530, Gaurav Kohli wrote:
>
>
> On 6/9/2026 4:27 PM, Dmitry Baryshkov wrote:
> > On Tue, Jun 09, 2026 at 03:52:59PM +0530, Gaurav Kohli wrote:
> > > Unlike the CPU, the CDSP/Modem does not throttle its speed automatically
> > > when it reaches high temperatures in kodiak.
> > >
> > > Set up CDSP cooling by throttling the cdsp when it reaches 100°C and
> > > for modem when it reaches to 95°C.
> > >
> > > Remove inherited mdmss cooling-map nodes for Non Modem kodiak variant.
> >
> > Why? If it is a GNSS-only MPSS, does it not provide any thermal
> > mitigation mechanisms? Does ADSP provide those? WPSS?
> >
>
> Hi Dmitry,
>
> Thank you for the review.
>
> Since the remoteproc_mpss node doesn't exist on these boards, the
> cooling-maps that reference it cause DT compilation errors. That's why
> we need to remove the inherited cooling-maps from the SoC DTSI.
> /delete-node/ &remoteproc_mpss;
Ok. Explain that in the commit message. And maybe we need to fix those
boards to provide mpss instead.
>
> Regarding thermal mitigation for other subsystems:
> ->CDSP and Modem are the primary heat sources based on our internal
> thermal testing and evaluation.
> ->ADSP and WPSS have lower power consumption and don't typically reach
> thermal thresholds that require active mitigation
> ->For this, I'm checking with our internal team to confirm if ADSP/WPSS
> provide any TMD mechanism across all targets.
They do. I've posted the dump of qrtr-lookup somewhere.
>
> > >
> > > Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
> > > ---
> > > arch/arm64/boot/dts/qcom/kodiak.dtsi | 127 ++++++++++++++++++++-
> > > .../boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts | 17 +++
> >
> > So, you removed those for Radxa Q6A, but not forRB3 Gen2. Why?
> >
>
> Ack, this is a miss. will fix this.
>
> > > .../dts/qcom/qcs6490-thundercomm-minipc-g1iot.dts | 17 +++
> > > .../boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts | 17 +++
> > > .../boot/dts/qcom/sc7280-herobrine-lte-sku.dtsi | 18 +++
> > > .../boot/dts/qcom/sc7280-herobrine-wifi-sku.dtsi | 16 +++
> > > 6 files changed, 208 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> > > index fa540d8c2615..d345add2d8c8 100644
> > > --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> > > @@ -3427,6 +3427,9 @@ remoteproc_mpss: remoteproc@4080000 {
> > > qcom,smem-states = <&modem_smp2p_out 0>;
> > > qcom,smem-state-names = "stop";
> > > + #cooling-cells = <3>;
> > > + tmd-names = "pa", "modem";
> > > +
> > > status = "disabled";
> > > glink-edge {
> > > @@ -4787,6 +4790,9 @@ remoteproc_cdsp: remoteproc@a300000 {
> > > qcom,smem-states = <&cdsp_smp2p_out 0>;
> > > qcom,smem-state-names = "stop";
> > > + #cooling-cells = <2>;
> > > + tmd-names = "cdsp_sw";
> >
> > I'm going to review only this DT, the comments apply to the rest of
> > them.
> >
> > So, we have two cases, CDSP and MPSS. Why does CDSP have only 2 cells?
> > Just because tmd-names has only one name? What if we add another
> > mitigation (which can be added in the firmware), do we suddenly have to
> > change number of cells and all the cooling devices to reflect it?
> >
>
> As Cdsp has only one relevant tmd to mitigate, so we have used cooling cells
> as 2. But i will change this to 3 as this is backward compatible.
>
> > Finally. If I understand correctly, these mitigtion mechanisms are
> > provided by the firmware. Firmware differs between the boards. Vendors
> > (in theory) can change them. Why do we list these names here, in the SoC
> > DT?
> >
>
> Below are the main reason for this, replied in other thread also.
> Please guide, if i can use qcom_pas_data to define names.
>
> Following Daniel's series [1], the thermal framework supports
> mapping multiple cooling devices per remoteproc/device via indexed
> cooling-cells.
>
> 1) The thermal framework's cooling-maps reference
> cooling devices by index (for #cooling-cells = <3>). Without tmd-names,
> there's no way to know which index corresponds to which TMD, as firmware
> may return tmd-names in any order.
You can #define the indices to the well known names, turning those into
bindings.
>
> below are the changes post new thermal mapping changes:
> DT: tmd-names = "cdsp_sw", "xyz";
> Firmware: ["cdsp_sw", "xyz1", "xyz2",]
> Driver registers: Only "cdsp_sw" (index 0) and "xyz" (index 1)
What if the DT has "cdsp_sw", but the firmware doesn't report it? That's
an error, as it seems.
>
> This allows cooling-maps like below:
> cooling-device = <&remoteproc 0 ...> // "cdsp_sw"
> cooling-device = <&remoteproc 1 ...> // "xyz"
>
> 2) Not all firmware-provided TMDs should be
> exposed as cooling devices. The tmd-names property acts as a filter,
> allowing board-specific DT to select only the relevant TMDs for that
> platform.
But then the properties should be defined in the board DT rather than
the platform DT.
>
> [1]
> https://lore.kernel.org/all/20260526140802.1059293-12-daniel.lezcano@oss.qualcomm.com/
>
> Shall i use pas data to define tmd-names instead of dt ?
Let's settle in the thread with Daniel.
>
> > > +
> > > status = "disabled";
> > > glink-edge {
> > > + cooling-maps {
> > > + map0 {
> > > + trip = <&mdmss0_alert1>;
> > > + cooling-device = <&remoteproc_mpss 0 0 2>;
> >
> > What does this mean? I assume that the first cell is one of the
> > mechanisms. What is the difference between them? Do we really need to
> > list them one by one here?
> >
>
> Let me check, if i can document different tmd's somewhere:
>
> -> modem tmd used for Modem Processor mitigation.
> -> pa is used for Power Amplifier mitigation.
What does that mean?
>
> And we need to list them for binding purpose mainly.
>
> > What do other cells mean? Why are they 0 and 2 rather than
> > THERMAL_NO_LIMIT? How does one come with those values? This should all
> > be documented and explained somewhere.
> >
>
> Will change to THERMAL_NO_LIMIT. Let me check, if i can use
> qli doc for documentation.
>
> > > + };
> > > +
> > > + map1 {
> > > + trip = <&mdmss0_alert1>;
> > > + cooling-device = <&remoteproc_mpss 1 0 2>;
> > > + };
> > > + };
> > > };
> >
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v3 1/8] dt-bindings: remoteproc: qcom,pas: add thermal mitigation properties
From: Dmitry Baryshkov @ 2026-06-15 15:14 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Gaurav Kohli, Krzysztof Kozlowski, Bjorn Andersson,
Mathieu Poirier, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Amit Kucheria, Manivannan Sadhasivam, Konrad Dybcio, Kees Cook,
Gustavo A. R. Silva, cros-qcom-dts-watchers, linux-arm-msm,
linux-remoteproc, devicetree, linux-kernel, linux-pm,
linux-hardening, Manaf Meethalavalappu Pallikunhi
In-Reply-To: <93e7251c-c75d-4e43-9ae2-bf485af58de3@oss.qualcomm.com>
On Mon, Jun 15, 2026 at 04:33:38PM +0200, Daniel Lezcano wrote:
>
>
> Le 15/06/2026 à 16:11, Dmitry Baryshkov a écrit :
> > On Mon, Jun 15, 2026 at 02:30:49PM +0200, Daniel Lezcano wrote:
> > > Hi Gaurav,
> > >
> > > Le 15/06/2026 à 14:12, Gaurav Kohli a écrit :
> > > >
> > > >
> > > > On 6/15/2026 4:04 PM, Daniel Lezcano wrote:
> > > > > On 6/13/26 13:05, Gaurav Kohli wrote:
> > > > > >
> > > > > >
> > > > > > On 6/13/2026 1:11 PM, Krzysztof Kozlowski wrote:
> > > > > > > On 12/06/2026 15:52, Gaurav Kohli wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > On 6/11/2026 5:53 PM, Krzysztof Kozlowski wrote:
> > > > > > > > > On 11/06/2026 13:12, Gaurav Kohli wrote:
> > > > > > > > > > > Why? And where is this generic property defined? You cannot just
> > > > > > > > > > > sprinkle generic properties in random bindings.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Ack, will add why part.
> > > > > > > > > > These names are matched with the thermal
> > > > > > > > > > mitigation device identifiers
> > > > > > > > > > populated by remote firmware over QMI and define
> > > > > > > > > > mitigation devices are
> > > > > > > > > > exposed as cooling devices.
> > > > > > > > >
> > > > > > > > > No, -names correspond to values passed via DT, not
> > > > > > > > > some remote firmware.
> > > > > > > > > The remote firmware should give you interface which
> > > > > > > > > is explicit and does
> > > > > > > > > not need such properties.
> > > > > > > >
> > > > > > > > thanks Krzysztof for review, We need tmd-names because
> > > > > > > > of following reasons:
> > > > > > > >
> > > > > > > > Following Daniel's series [1], the thermal framework supports
> > > > > > > > mapping multiple cooling devices per remoteproc/device via indexed
> > > > > > > > cooling-cells.
> > > > > > > >
> > > > > > > > 1) The thermal framework's cooling-maps reference
> > > > > > > > cooling devices by index (for #cooling-cells = <3>).
> > > > > > > > Without tmd- names,
> > > > > > > > there's no way to know which index corresponds to which
> > > > > > > > TMD, as firmware
> > > > > > > > may return tmd-names in any order.
> > > > > > > >
> > > > > > > > below are the changes post new thermal mapping changes:
> > > > > > > > DT: tmd-names = "cdsp_sw", "xyz";
> > > > > > > > Firmware: ["cdsp_sw", "xyz1", "xyz2",]
> > > > > > > > Driver registers: Only "cdsp_sw" (index 0) and "xyz" (index 1)
> > > > > > >
> > > > > > > names property are not to instruct drivers to register or not to
> > > > > > > register something.
> > > > > > >
> > > > > > > I don't understand the problem and explanation in the binding is
> > > > > > > basically non-existing.
> > > > > > >
> > > > > > > Remember that all lists and indices ARE FIXED, so driver knows exactly
> > > > > > > which index means what.
> > > > > > >
> > > > > >
> > > > > > thanks for review, shall i use driver data, which is basically
> > > > > > pas data structure like below:
> > > > > >
> > > > > > static const struct qcom_pas_data {
> > > > > > .crash_reason_smem = 601,
> > > > > > .firmware_name = "cdsp.mdt",
> > > > > > .tmd_names = (const char *[]){"xyz", NULL},
> > > > > > .num_tmds = 1,
> > > > > >
> > > > > > Is something like above acceptable? and this will also help to
> > > > > > filter tmd names as well?
> > > > >
> > > > >
> > > > > How the thermal framework will bind the thermal zone with the TMD ?
> > > > > (node pointer, id) ?
> > > > >
> > > >
> > > > Hi Daniel,
> > > >
> > > > thanks for review.
> > > >
> > > > With id only, in this case instead of taking tmd names from device tree,
> > > > qmi_tmd will take tmd name from pas_data(driver) and register with the
> > > > cooling framework with id only. Please let us know if this looks fine.
> > > May be I'm missing something but:
> > >
> > > - The QMI TMD returns a list of names, not ids
> > > - The QMI TMD may return the list in different order than assumed
> > > - The cooling map index points to the name of the TMD in the DT
> > > - This name is used to match the name in the aformentionned list
> > > - The index in the list and the id in the DT can differ
> >
> > Would it be better if we define standard indices for the standard names?
> > This way we decouple the actual firmware strings from the DT.
>
> I don't think so, it seems to me too fragile and prone to error.
>
> It is a remote proc, an external subsystem. The contract between the client
> and the server is the protocol. The protocol specifies the identifier as
> named strings, the TMD names, not numerical identifiers.
>
> When asking for the list of TMDs, we get a list of strings. But as it is an
> external subsystems, may be tomorrow someone decide to send list ordered
> alphabetically, or per number of states, or whatever.
>
> With hardcoded id the QMI TMD clients break
I was thinking about something like:
#define QCOM_TMD_DSP 0
#define QCOM_TMD_PA 1
cooling-maps {
map0 {
cooling-device = <&remoteproc_cdsp QCOM_TMD_DSP 0 2>;
};
map1 {
cooling-device = <&remoteproc_mpss QCOM_TMD_DSP 0 2>;
};
map2 {
cooling-device = <&remoteproc_mpss QCOM_TMD_PA 0 2>;
};
};
>
> > > Krzysztof , I don't get why having the TMD names as properties is wrong,
> > > they describes the existing TMDs on the system and the cooling maps index
> > > points to the one to be connected with thermal zone.
> >
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH V12 7/9] iio: imu: inv_icm42607: Add Accelerometer for icm42607
From: Andy Shevchenko @ 2026-06-15 15:07 UTC (permalink / raw)
To: Chris Morgan
Cc: Chris Morgan, linux-iio, andy, nuno.sa, dlechner, jic23,
jean-baptiste.maneyrol, linux-rockchip, devicetree, heiko,
conor+dt, krzk+dt, robh
In-Reply-To: <PH0PR19MB997338010EC6FA92E0AA63875FA5E62@PH0PR19MB997338.namprd19.prod.outlook.com>
On Mon, Jun 15, 2026 at 09:51:40AM -0500, Chris Morgan wrote:
> On Mon, Jun 15, 2026 at 02:21:05PM +0300, Andy Shevchenko wrote:
> > On Thu, Jun 11, 2026 at 03:26:04PM -0500, Chris Morgan wrote:
...
> > Please, please, use IWYU! So many headers are missing...
> > (Same comment to all files in this series.)
> >
> > + array_size.h
> > + bits.h // BIT()
> > + cleanup.h // guard()()
> > + device/devres.h // devm_kasprintf()
> > + err.h // -EINVAL, IS_ERR()
> >
> > > +#include <linux/iio/iio.h>
> > > +#include <linux/mutex.h>
> > > +#include <linux/pm_runtime.h>
> > > +#include <linux/regmap.h>
> >
> > + types.h // s16, __be16
> >
> > Also you need to have
> >
> > asm/byteorder.h // be16_to_cpup()
>
> How are you running IWYU against the builds? So far I've tried but I
> can't seem to get it to run properly.
Sorry, I meant "use IWYU principle". I don't run the tool, I just looked into
the code.
...
> > > + for (i = 5; i < ARRAY_SIZE(inv_icm42607_accel_odr); ++i) {
> >
> > Why pre-increment? Same for all other cases.
>
> The register starts at 5 and all values below 5 are invalid. Starting
> this increment at 5 ensures we don't expose invalid values to
> userspace.
It doesn't explain pre-increment. Post-increment should work as is.
> > > + if (i == odr)
> > > + break;
> > > + }
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v9 2/9] drm/bridge: fsl-ldb: Get the next non-panel bridge
From: Frank Li @ 2026-06-15 15:02 UTC (permalink / raw)
To: Laurentiu Palcu
Cc: Ying Liu, Luca Ceresoli, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, linux-clk, imx, devicetree, linux-arm-kernel,
linux-kernel, dri-devel
In-Reply-To: <20260612-dcif-upstreaming-v9-2-8d0ff89aa3c5@oss.nxp.com>
On Fri, Jun 12, 2026 at 02:58:33PM +0300, Laurentiu Palcu wrote:
> From: Liu Ying <victor.liu@nxp.com>
>
> The next bridge in bridge chain could be a panel bridge or a non-panel
> bridge. Use devm_drm_of_get_bridge() to replace the combination
> function calls of of_drm_find_panel() and devm_drm_panel_bridge_add()
> to get either a panel bridge or a non-panel bridge, instead of getting
> a panel bridge only.
>
> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/gpu/drm/bridge/fsl-ldb.c | 31 ++++++++++++-------------------
> 1 file changed, 12 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/fsl-ldb.c b/drivers/gpu/drm/bridge/fsl-ldb.c
> index 9bfaa3f933709..bd03c36ee696c 100644
> --- a/drivers/gpu/drm/bridge/fsl-ldb.c
> +++ b/drivers/gpu/drm/bridge/fsl-ldb.c
> @@ -15,7 +15,6 @@
> #include <drm/drm_atomic_helper.h>
> #include <drm/drm_bridge.h>
> #include <drm/drm_of.h>
> -#include <drm/drm_panel.h>
>
> #define LDB_CTRL_CH0_ENABLE BIT(0)
> #define LDB_CTRL_CH0_DI_SELECT BIT(1)
> @@ -86,7 +85,6 @@ static const struct fsl_ldb_devdata fsl_ldb_devdata[] = {
> struct fsl_ldb {
> struct device *dev;
> struct drm_bridge bridge;
> - struct drm_bridge *panel_bridge;
> struct clk *clk;
> struct regmap *regmap;
> const struct fsl_ldb_devdata *devdata;
> @@ -119,7 +117,7 @@ static int fsl_ldb_attach(struct drm_bridge *bridge,
> {
> struct fsl_ldb *fsl_ldb = to_fsl_ldb(bridge);
>
> - return drm_bridge_attach(encoder, fsl_ldb->panel_bridge,
> + return drm_bridge_attach(encoder, fsl_ldb->bridge.next_bridge,
> bridge, flags);
> }
>
> @@ -296,9 +294,8 @@ static const struct drm_bridge_funcs funcs = {
> static int fsl_ldb_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> - struct device_node *panel_node;
> struct device_node *remote1, *remote2;
> - struct drm_panel *panel;
> + struct drm_bridge *next_bridge;
> struct fsl_ldb *fsl_ldb;
> int dual_link;
>
> @@ -321,36 +318,32 @@ static int fsl_ldb_probe(struct platform_device *pdev)
> if (IS_ERR(fsl_ldb->regmap))
> return PTR_ERR(fsl_ldb->regmap);
>
> - /* Locate the remote ports and the panel node */
> + /* Locate the remote ports. */
> remote1 = of_graph_get_remote_node(dev->of_node, 1, 0);
> remote2 = of_graph_get_remote_node(dev->of_node, 2, 0);
> fsl_ldb->ch0_enabled = (remote1 != NULL);
> fsl_ldb->ch1_enabled = (remote2 != NULL);
> - panel_node = of_node_get(remote1 ? remote1 : remote2);
> of_node_put(remote1);
> of_node_put(remote2);
>
> - if (!fsl_ldb->ch0_enabled && !fsl_ldb->ch1_enabled) {
> - of_node_put(panel_node);
> - return dev_err_probe(dev, -ENXIO, "No panel node found");
> - }
> + if (!fsl_ldb->ch0_enabled && !fsl_ldb->ch1_enabled)
> + return dev_err_probe(dev, -ENXIO, "No next bridge node found");
>
> dev_dbg(dev, "Using %s\n",
> fsl_ldb_is_dual(fsl_ldb) ? "dual-link mode" :
> fsl_ldb->ch0_enabled ? "channel 0" : "channel 1");
>
> - panel = of_drm_find_panel(panel_node);
> - of_node_put(panel_node);
> - if (IS_ERR(panel))
> - return PTR_ERR(panel);
> -
> if (of_property_present(dev->of_node, "nxp,enable-termination-resistor"))
> fsl_ldb->use_termination_resistor = true;
>
> - fsl_ldb->panel_bridge = devm_drm_panel_bridge_add(dev, panel);
> - if (IS_ERR(fsl_ldb->panel_bridge))
> - return PTR_ERR(fsl_ldb->panel_bridge);
> + next_bridge = devm_drm_of_get_bridge(dev, dev->of_node,
> + fsl_ldb->ch0_enabled ? 1 : 2,
> + 0);
> + if (IS_ERR(next_bridge))
> + return dev_err_probe(dev, PTR_ERR(next_bridge),
> + "failed to get next bridge\n");
>
> + fsl_ldb->bridge.next_bridge = drm_bridge_get(next_bridge);
>
> if (fsl_ldb_is_dual(fsl_ldb)) {
> struct device_node *port1, *port2;
>
> --
> 2.51.0
>
^ permalink raw reply
* Re: [PATCH v9 4/9] dt-bindings: display: imx: Add i.MX94 DCIF
From: Frank Li @ 2026-06-15 15:01 UTC (permalink / raw)
To: Laurentiu Palcu
Cc: Ying Liu, Luca Ceresoli, Philipp Zabel, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, linux-clk,
imx, devicetree, linux-arm-kernel, linux-kernel, dri-devel
In-Reply-To: <20260612-dcif-upstreaming-v9-4-8d0ff89aa3c5@oss.nxp.com>
On Fri, Jun 12, 2026 at 02:58:35PM +0300, Laurentiu Palcu wrote:
>
> DCIF is the i.MX94 Display Controller Interface which is used to
> drive a TFT LCD panel or connects to a display interface depending
> on the chip configuration.
>
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> ---
> .../bindings/display/imx/nxp,imx94-dcif.yaml | 90 ++++++++++++++++++++++
> 1 file changed, 90 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/imx/nxp,imx94-dcif.yaml b/Documentation/devicetree/bindings/display/imx/nxp,imx94-dcif.yaml
> new file mode 100644
> index 0000000000000..8894e87666972
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/imx/nxp,imx94-dcif.yaml
> @@ -0,0 +1,90 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2025 NXP
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/imx/nxp,imx94-dcif.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: i.MX94 Display Control Interface (DCIF)
> +
> +maintainers:
> + - Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> +
> +description:
> + The Display Control Interface(DCIF) is a system master that fetches graphics
> + stored in memory and displays them on a TFT LCD panel or connects to a
> + display interface depending on the chip configuration.
> +
> +properties:
> + compatible:
> + const: nxp,imx94-dcif
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + items:
> + - description: CPU domain 0 (controlled by common registers group).
> + - description: CPU domain 1 (controlled by background layer registers group).
> + - description: CPU domain 2 (controlled by foreground layer registers group).
> +
> + interrupt-names:
> + items:
> + - const: common
> + - const: bg_layer
> + - const: fg_layer
> +
> + clocks:
> + maxItems: 3
> +
> + clock-names:
> + items:
> + - const: apb
> + - const: axi
> + - const: pix
> +
> + power-domains:
> + maxItems: 1
> +
> + port:
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> + description: Display Pixel Interface(DPI) output port
> +
> + properties:
> + endpoint:
> + $ref: /schemas/media/video-interfaces.yaml#
> + unevaluatedProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - power-domains
> + - port
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + display-controller@4b120000 {
> + compatible = "nxp,imx94-dcif";
> + reg = <0x4b120000 0x300000>;
> + interrupts = <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 378 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 379 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "common", "bg_layer", "fg_layer";
> + clocks = <&scmi_clk 69>, <&scmi_clk 70>, <&dispmix_csr 0>;
> + clock-names = "apb", "axi", "pix";
> + assigned-clocks = <&dispmix_csr 0>;
> + assigned-clock-parents = <&ldb_pll_pixel>;
> + power-domains = <&scmi_devpd 11>;
Nit: need extra empty line here
> + port {
> + dcif_out: endpoint {
Needn't label here for example
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> + remote-endpoint = <&ldb_in>;
> + };
> + };
> + };
>
> --
> 2.51.0
>
^ permalink raw reply
* Re: [PATCH v9 3/9] drm/bridge: fsl-ldb: Add support for i.MX94
From: Frank Li @ 2026-06-15 15:00 UTC (permalink / raw)
To: Laurentiu Palcu
Cc: Ying Liu, Luca Ceresoli, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, linux-clk, imx, devicetree, linux-arm-kernel,
linux-kernel, dri-devel
In-Reply-To: <20260612-dcif-upstreaming-v9-3-8d0ff89aa3c5@oss.nxp.com>
On Fri, Jun 12, 2026 at 02:58:34PM +0300, Laurentiu Palcu wrote:
>
> i.MX94 series LDB controller shares the same LDB and LVDS control
> registers as i.MX8MP and i.MX93 but supports a higher maximum clock
> frequency.
>
> Add a 'max_clk_khz' member to the fsl_ldb_devdata structure in order to
> be able to set different max frequencies for other platforms.
>
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/gpu/drm/bridge/fsl-ldb.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/fsl-ldb.c b/drivers/gpu/drm/bridge/fsl-ldb.c
> index bd03c36ee696c..b4959f654f2ac 100644
> --- a/drivers/gpu/drm/bridge/fsl-ldb.c
> +++ b/drivers/gpu/drm/bridge/fsl-ldb.c
> @@ -57,6 +57,7 @@ enum fsl_ldb_devtype {
> IMX6SX_LDB,
> IMX8MP_LDB,
> IMX93_LDB,
> + IMX94_LDB,
> };
>
> struct fsl_ldb_devdata {
> @@ -64,21 +65,31 @@ struct fsl_ldb_devdata {
> u32 lvds_ctrl;
> bool lvds_en_bit;
> bool single_ctrl_reg;
> + u32 max_clk_khz;
> };
>
> static const struct fsl_ldb_devdata fsl_ldb_devdata[] = {
> [IMX6SX_LDB] = {
> .ldb_ctrl = 0x18,
> .single_ctrl_reg = true,
> + .max_clk_khz = 80000,
> },
> [IMX8MP_LDB] = {
> .ldb_ctrl = 0x5c,
> .lvds_ctrl = 0x128,
> + .max_clk_khz = 80000,
> },
> [IMX93_LDB] = {
> .ldb_ctrl = 0x20,
> .lvds_ctrl = 0x24,
> .lvds_en_bit = true,
> + .max_clk_khz = 80000,
> + },
> + [IMX94_LDB] = {
> + .ldb_ctrl = 0x04,
> + .lvds_ctrl = 0x08,
> + .lvds_en_bit = true,
> + .max_clk_khz = 148500,
> },
> };
>
> @@ -274,7 +285,7 @@ fsl_ldb_mode_valid(struct drm_bridge *bridge,
> {
> struct fsl_ldb *fsl_ldb = to_fsl_ldb(bridge);
>
> - if (mode->clock > (fsl_ldb_is_dual(fsl_ldb) ? 160000 : 80000))
> + if (mode->clock > (fsl_ldb_is_dual(fsl_ldb) ? 2 : 1) * fsl_ldb->devdata->max_clk_khz)
> return MODE_CLOCK_HIGH;
>
> return MODE_OK;
> @@ -386,6 +397,8 @@ static const struct of_device_id fsl_ldb_match[] = {
> .data = &fsl_ldb_devdata[IMX8MP_LDB], },
> { .compatible = "fsl,imx93-ldb",
> .data = &fsl_ldb_devdata[IMX93_LDB], },
> + { .compatible = "fsl,imx94-ldb",
> + .data = &fsl_ldb_devdata[IMX94_LDB], },
> { /* sentinel */ },
> };
> MODULE_DEVICE_TABLE(of, fsl_ldb_match);
>
> --
> 2.51.0
>
^ permalink raw reply
* Re: [PATCH v9 5/9] drm/imx: Add support for i.MX94 DCIF
From: Frank Li @ 2026-06-15 14:58 UTC (permalink / raw)
To: Laurentiu Palcu
Cc: Ying Liu, Luca Ceresoli, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, linux-clk,
imx, devicetree, linux-arm-kernel, linux-kernel, dri-devel
In-Reply-To: <20260612-dcif-upstreaming-v9-5-8d0ff89aa3c5@oss.nxp.com>
On Fri, Jun 12, 2026 at 02:58:36PM +0300, Laurentiu Palcu wrote:
> The i.MX94 Display Control Interface features:
> * Up to maximum 3 layers of alpha blending:
> - 1 background layer(Layer 0);
> - 1 foreground layer(Layer 1);
> - A programmable constant color behind the background layer;
> * Each layer supports:
> - programmable plane size;
> - programmable background color;
> - embedded alpha and global alpha;
> * Data output with CRC checksum for 4 programmable regions;
>
> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # bridge refcounting
> Signed-off-by: Sandor Yu <sandor.yu@nxp.com>
> Co-developed-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox