[PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string

[PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string

[Andre Przywara]

Add the obvious compatible name to the existing RTC binding.
The actual RTC part of the device uses a different day/month/year
storage scheme, so it's not compatible with the previous devices.
Also the clock part is quite different, as there is no external 32K LOSC
oscillator input.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml      | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
index beeb90e55727..d8a6500e5840 100644
--- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
@@ -26,6 +26,7 @@ properties:
           - const: allwinner,sun50i-a64-rtc
           - const: allwinner,sun8i-h3-rtc
       - const: allwinner,sun50i-h6-rtc
+      - const: allwinner,sun50i-h616-rtc
 
   reg:
     maxItems: 1
@@ -104,6 +105,19 @@ allOf:
           minItems: 3
           maxItems: 3
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: allwinner,sun50i-h616-rtc
+
+    then:
+      properties:
+        clock-output-names:
+          minItems: 3
+          maxItems: 3
+        clocks: false
+
   - if:
       properties:
         compatible:
-- 
2.17.6

[PATCH v8 03/11] rtc: sun6i: Fix time overflow handling

[Andre Przywara]

Using "unsigned long" for UNIX timestamps is never a good idea, and
comparing the value of such a variable against U32_MAX does not do
anything useful on 32-bit systems.

Use the proper time64_t type when dealing with timestamps, and avoid
cutting down the time range unnecessarily. This also fixes the flawed
check for the alarm time being too far into the future.

The check for this condition is actually somewhat theoretical, as the
RTC counts till 2033 only anyways, and 2^32 seconds from now is not
before the year 2157 - at which point I hope nobody will be using this
hardware anymore.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/rtc/rtc-sun6i.c | 14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index adec1b14a8de..c551ebf0ac00 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -138,7 +138,7 @@ struct sun6i_rtc_dev {
 	const struct sun6i_rtc_clk_data *data;
 	void __iomem *base;
 	int irq;
-	unsigned long alarm;
+	time64_t alarm;
 
 	struct clk_hw hw;
 	struct clk_hw *int_osc;
@@ -510,10 +510,8 @@ static int sun6i_rtc_setalarm(struct device *dev, struct rtc_wkalrm *wkalrm)
 	struct sun6i_rtc_dev *chip = dev_get_drvdata(dev);
 	struct rtc_time *alrm_tm = &wkalrm->time;
 	struct rtc_time tm_now;
-	unsigned long time_now = 0;
-	unsigned long time_set = 0;
-	unsigned long time_gap = 0;
-	int ret = 0;
+	time64_t time_now, time_set;
+	int ret;
 
 	ret = sun6i_rtc_gettime(dev, &tm_now);
 	if (ret < 0) {
@@ -528,9 +526,7 @@ static int sun6i_rtc_setalarm(struct device *dev, struct rtc_wkalrm *wkalrm)
 		return -EINVAL;
 	}
 
-	time_gap = time_set - time_now;
-
-	if (time_gap > U32_MAX) {
+	if ((time_set - time_now) > U32_MAX) {
 		dev_err(dev, "Date too far in the future\n");
 		return -EINVAL;
 	}
@@ -539,7 +535,7 @@ static int sun6i_rtc_setalarm(struct device *dev, struct rtc_wkalrm *wkalrm)
 	writel(0, chip->base + SUN6I_ALRM_COUNTER);
 	usleep_range(100, 300);
 
-	writel(time_gap, chip->base + SUN6I_ALRM_COUNTER);
+	writel(time_set - time_now, chip->base + SUN6I_ALRM_COUNTER);
 	chip->alarm = time_set;
 
 	sun6i_rtc_setaie(wkalrm->enabled, chip);
-- 
2.17.6

[PATCH v8 04/11] rtc: sun6i: Add support for linear day storage

[Andre Przywara]

Newer versions of the Allwinner RTC, as for instance found in the H616
SoC, no longer store a broken-down day/month/year representation in the
RTC_DAY_REG, but just a linear day number.
The user manual does not give any indication about the expected epoch
time of this day count, but the BSP kernel uses the UNIX epoch, which
allows easy support due to existing conversion functions in the kernel.

Allow tagging a compatible string with a flag, and use that to mark
those new RTCs. Then convert between a UNIX day number (converted into
seconds) and the broken-down day representation using mktime64() and
time64_to_tm() in the set_time/get_time functions.

That enables support for the RTC in those new chips.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/rtc/rtc-sun6i.c | 66 +++++++++++++++++++++++++++--------------
 1 file changed, 44 insertions(+), 22 deletions(-)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index c551ebf0ac00..a02be8bca6f3 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -110,6 +110,8 @@
 #define SUN6I_YEAR_MIN				1970
 #define SUN6I_YEAR_OFF				(SUN6I_YEAR_MIN - 1900)
 
+#define SECS_PER_DAY				(24 * 3600ULL)
+
 /*
  * There are other differences between models, including:
  *
@@ -133,12 +135,15 @@ struct sun6i_rtc_clk_data {
 	unsigned int has_auto_swt : 1;
 };
 
+#define RTC_LINEAR_DAY	BIT(0)
+
 struct sun6i_rtc_dev {
 	struct rtc_device *rtc;
 	const struct sun6i_rtc_clk_data *data;
 	void __iomem *base;
 	int irq;
 	time64_t alarm;
+	unsigned long flags;
 
 	struct clk_hw hw;
 	struct clk_hw *int_osc;
@@ -467,22 +472,30 @@ static int sun6i_rtc_gettime(struct device *dev, struct rtc_time *rtc_tm)
 	} while ((date != readl(chip->base + SUN6I_RTC_YMD)) ||
 		 (time != readl(chip->base + SUN6I_RTC_HMS)));
 
+	if (chip->flags & RTC_LINEAR_DAY) {
+		/*
+		 * Newer chips store a linear day number, the manual
+		 * does not mandate any epoch base. The BSP driver uses
+		 * the UNIX epoch, let's just copy that, as it's the
+		 * easiest anyway.
+		 */
+		rtc_time64_to_tm((date & 0xffff) * SECS_PER_DAY, rtc_tm);
+	} else {
+		rtc_tm->tm_mday = SUN6I_DATE_GET_DAY_VALUE(date);
+		rtc_tm->tm_mon  = SUN6I_DATE_GET_MON_VALUE(date) - 1;
+		rtc_tm->tm_year = SUN6I_DATE_GET_YEAR_VALUE(date);
+
+		/*
+		 * switch from (data_year->min)-relative offset to
+		 * a (1900)-relative one
+		 */
+		rtc_tm->tm_year += SUN6I_YEAR_OFF;
+	}
+
 	rtc_tm->tm_sec  = SUN6I_TIME_GET_SEC_VALUE(time);
 	rtc_tm->tm_min  = SUN6I_TIME_GET_MIN_VALUE(time);
 	rtc_tm->tm_hour = SUN6I_TIME_GET_HOUR_VALUE(time);
 
-	rtc_tm->tm_mday = SUN6I_DATE_GET_DAY_VALUE(date);
-	rtc_tm->tm_mon  = SUN6I_DATE_GET_MON_VALUE(date);
-	rtc_tm->tm_year = SUN6I_DATE_GET_YEAR_VALUE(date);
-
-	rtc_tm->tm_mon  -= 1;
-
-	/*
-	 * switch from (data_year->min)-relative offset to
-	 * a (1900)-relative one
-	 */
-	rtc_tm->tm_year += SUN6I_YEAR_OFF;
-
 	return 0;
 }
 
@@ -567,20 +580,27 @@ static int sun6i_rtc_settime(struct device *dev, struct rtc_time *rtc_tm)
 	u32 date = 0;
 	u32 time = 0;
 
-	rtc_tm->tm_year -= SUN6I_YEAR_OFF;
-	rtc_tm->tm_mon += 1;
-
-	date = SUN6I_DATE_SET_DAY_VALUE(rtc_tm->tm_mday) |
-		SUN6I_DATE_SET_MON_VALUE(rtc_tm->tm_mon)  |
-		SUN6I_DATE_SET_YEAR_VALUE(rtc_tm->tm_year);
-
-	if (is_leap_year(rtc_tm->tm_year + SUN6I_YEAR_MIN))
-		date |= SUN6I_LEAP_SET_VALUE(1);
-
 	time = SUN6I_TIME_SET_SEC_VALUE(rtc_tm->tm_sec)  |
 		SUN6I_TIME_SET_MIN_VALUE(rtc_tm->tm_min)  |
 		SUN6I_TIME_SET_HOUR_VALUE(rtc_tm->tm_hour);
 
+	if (chip->flags & RTC_LINEAR_DAY) {
+		rtc_tm->tm_sec = 0;
+		rtc_tm->tm_min = 0;
+		rtc_tm->tm_hour = 0;
+		date = div_u64(rtc_tm_to_time64(rtc_tm), SECS_PER_DAY);
+	} else {
+		rtc_tm->tm_year -= SUN6I_YEAR_OFF;
+		rtc_tm->tm_mon += 1;
+
+		date = SUN6I_DATE_SET_DAY_VALUE(rtc_tm->tm_mday) |
+			SUN6I_DATE_SET_MON_VALUE(rtc_tm->tm_mon)  |
+			SUN6I_DATE_SET_YEAR_VALUE(rtc_tm->tm_year);
+
+		if (is_leap_year(rtc_tm->tm_year + SUN6I_YEAR_MIN))
+			date |= SUN6I_LEAP_SET_VALUE(1);
+	}
+
 	/* Check whether registers are writable */
 	if (sun6i_rtc_wait(chip, SUN6I_LOSC_CTRL,
 			   SUN6I_LOSC_CTRL_ACC_MASK, 50)) {
@@ -674,6 +694,8 @@ static int sun6i_rtc_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, chip);
 
+	chip->flags = (unsigned long)of_device_get_match_data(&pdev->dev);
+
 	chip->irq = platform_get_irq(pdev, 0);
 	if (chip->irq < 0)
 		return chip->irq;
-- 
2.17.6

[PATCH v8 05/11] rtc: sun6i: Add support for broken-down alarm registers

[Andre Przywara]

Newer versions of the Allwinner RTC, for instance as found in the H616
SoC, not only store the current day as a linear number, but also change
the way the alarm is handled: There are now two registers, that
explicitly store the wakeup time, in the same format as the current
time.

Add support for that variant by writing the requested wakeup time
directly into the registers, instead of programming the seconds left, as
the old SoCs required.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/rtc/rtc-sun6i.c | 60 +++++++++++++++++++++++++++++------------
 1 file changed, 43 insertions(+), 17 deletions(-)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index a02be8bca6f3..f0ee20bfdccb 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -48,7 +48,8 @@
 
 /* Alarm 0 (counter) */
 #define SUN6I_ALRM_COUNTER			0x0020
-#define SUN6I_ALRM_CUR_VAL			0x0024
+/* This holds the remaining alarm seconds on older SoCs (current value) */
+#define SUN6I_ALRM_COUNTER_HMS			0x0024
 #define SUN6I_ALRM_EN				0x0028
 #define SUN6I_ALRM_EN_CNT_EN			BIT(0)
 #define SUN6I_ALRM_IRQ_EN			0x002c
@@ -523,32 +524,57 @@ static int sun6i_rtc_setalarm(struct device *dev, struct rtc_wkalrm *wkalrm)
 	struct sun6i_rtc_dev *chip = dev_get_drvdata(dev);
 	struct rtc_time *alrm_tm = &wkalrm->time;
 	struct rtc_time tm_now;
-	time64_t time_now, time_set;
+	time64_t time_set;
+	u32 counter_val, counter_val_hms;
 	int ret;
 
-	ret = sun6i_rtc_gettime(dev, &tm_now);
-	if (ret < 0) {
-		dev_err(dev, "Error in getting time\n");
-		return -EINVAL;
-	}
-
 	time_set = rtc_tm_to_time64(alrm_tm);
-	time_now = rtc_tm_to_time64(&tm_now);
-	if (time_set <= time_now) {
-		dev_err(dev, "Date to set in the past\n");
-		return -EINVAL;
-	}
 
-	if ((time_set - time_now) > U32_MAX) {
-		dev_err(dev, "Date too far in the future\n");
-		return -EINVAL;
+	if (chip->flags & RTC_LINEAR_DAY) {
+		time64_t seconds;
+
+		/*
+		 * The alarm registers hold the actual alarm time, encoded
+		 * in the same way (linear day + HMS) as the current time.
+		 */
+		counter_val_hms = SUN6I_TIME_SET_SEC_VALUE(alrm_tm->tm_sec)  |
+				  SUN6I_TIME_SET_MIN_VALUE(alrm_tm->tm_min)  |
+				  SUN6I_TIME_SET_HOUR_VALUE(alrm_tm->tm_hour);
+		seconds = mktime64(alrm_tm->tm_year + 1900, alrm_tm->tm_mon,
+				   alrm_tm->tm_mday, 0, 0, 0);
+		counter_val = div_u64(seconds, SECS_PER_DAY);
+	} else {
+		/* The alarm register holds the number of seconds left. */
+		time64_t time_now;
+
+		ret = sun6i_rtc_gettime(dev, &tm_now);
+		if (ret < 0) {
+			dev_err(dev, "Error in getting time\n");
+			return -EINVAL;
+		}
+
+		time_now = rtc_tm_to_time64(&tm_now);
+		if (time_set <= time_now) {
+			dev_err(dev, "Date to set in the past\n");
+			return -EINVAL;
+		}
+		if ((time_set - time_now) > U32_MAX) {
+			dev_err(dev, "Date too far in the future\n");
+			return -EINVAL;
+		}
+
+		counter_val = time_set - time_now;
 	}
 
 	sun6i_rtc_setaie(0, chip);
 	writel(0, chip->base + SUN6I_ALRM_COUNTER);
+	if (chip->flags & RTC_LINEAR_DAY)
+		writel(0, chip->base + SUN6I_ALRM_COUNTER_HMS);
 	usleep_range(100, 300);
 
-	writel(time_set - time_now, chip->base + SUN6I_ALRM_COUNTER);
+	writel(counter_val, chip->base + SUN6I_ALRM_COUNTER);
+	if (chip->flags & RTC_LINEAR_DAY)
+		writel(counter_val_hms, chip->base + SUN6I_ALRM_COUNTER_HMS);
 	chip->alarm = time_set;
 
 	sun6i_rtc_setaie(wkalrm->enabled, chip);
-- 
2.17.6

[PATCH v8 06/11] rtc: sun6i: Add support for RTCs without external LOSCs

[Andre Przywara]

Some newer Allwinner RTCs (for instance the one in the H616 SoC) lack
a pin for an external 32768 Hz oscillator. As a consequence, this LOSC
can't be selected as the RTC clock source, and we must rely on the
internal RC oscillator.
To allow additions of clocks to the RTC node, add a feature bit to ignore
any provided clocks for now (the current code would think this is the
external LOSC). Later DTs and code can then for instance add the PLL
based clock input, and older kernel won't get confused.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/rtc/rtc-sun6i.c | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index f0ee20bfdccb..ef2b1027ce4c 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -134,6 +134,7 @@ struct sun6i_rtc_clk_data {
 	unsigned int export_iosc : 1;
 	unsigned int has_losc_en : 1;
 	unsigned int has_auto_swt : 1;
+	unsigned int no_ext_losc : 1;
 };
 
 #define RTC_LINEAR_DAY	BIT(0)
@@ -256,7 +257,7 @@ static void __init sun6i_rtc_clk_init(struct device_node *node,
 	}
 
 	/* Switch to the external, more precise, oscillator, if present */
-	if (of_get_property(node, "clocks", NULL)) {
+	if (!rtc->data->no_ext_losc && of_get_property(node, "clocks", NULL)) {
 		reg |= SUN6I_LOSC_CTRL_EXT_OSC;
 		if (rtc->data->has_losc_en)
 			reg |= SUN6I_LOSC_CTRL_EXT_LOSC_EN;
@@ -282,14 +283,19 @@ static void __init sun6i_rtc_clk_init(struct device_node *node,
 	}
 
 	parents[0] = clk_hw_get_name(rtc->int_osc);
-	/* If there is no external oscillator, this will be NULL and ... */
-	parents[1] = of_clk_get_parent_name(node, 0);
+	if (rtc->data->no_ext_losc) {
+		parents[1] = NULL;
+		init.num_parents = 1;
+	} else {
+		/* If there is no external oscillator, this will be NULL and */
+		parents[1] = of_clk_get_parent_name(node, 0);
+		/* ... number of clock parents will be 1. */
+		init.num_parents = of_clk_get_parent_count(node) + 1;
+	}
 
 	rtc->hw.init = &init;
 
 	init.parent_names = parents;
-	/* ... number of clock parents will be 1. */
-	init.num_parents = of_clk_get_parent_count(node) + 1;
 	of_property_read_string_index(node, "clock-output-names", 0,
 				      &init.name);
 
-- 
2.17.6

[PATCH v8 07/11] rtc: sun6i: Add Allwinner H616 support

[Andre Przywara]

The H616 RTC changes its day storage to the newly introduced linear day
scheme, so pair the new compatible string with this feature flag.
The clock part is missing an external 32768 Hz oscillator input pin,
for future expansion we must thus ignore any provided clock for now.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/rtc/rtc-sun6i.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index ef2b1027ce4c..db65273c6f59 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -392,6 +392,23 @@ static void __init sun50i_h6_rtc_clk_init(struct device_node *node)
 CLK_OF_DECLARE_DRIVER(sun50i_h6_rtc_clk, "allwinner,sun50i-h6-rtc",
 		      sun50i_h6_rtc_clk_init);
 
+static const struct sun6i_rtc_clk_data sun50i_h616_rtc_data = {
+	.rc_osc_rate = 16000000,
+	.fixed_prescaler = 32,
+	.has_prescaler = 1,
+	.has_out_clk = 1,
+	.export_iosc = 1,
+	.no_ext_losc = 1,
+};
+
+static void __init sun50i_h616_rtc_clk_init(struct device_node *node)
+{
+	sun6i_rtc_clk_init(node, &sun50i_h616_rtc_data);
+}
+
+CLK_OF_DECLARE_DRIVER(sun50i_h616_rtc_clk, "allwinner,sun50i-h616-rtc",
+		      sun50i_h616_rtc_clk_init);
+
 /*
  * The R40 user manual is self-conflicting on whether the prescaler is
  * fixed or configurable. The clock diagram shows it as fixed, but there
@@ -799,6 +816,8 @@ static const struct of_device_id sun6i_rtc_dt_ids[] = {
 	{ .compatible = "allwinner,sun8i-v3-rtc" },
 	{ .compatible = "allwinner,sun50i-h5-rtc" },
 	{ .compatible = "allwinner,sun50i-h6-rtc" },
+	{ .compatible = "allwinner,sun50i-h616-rtc",
+		.data = (void *)RTC_LINEAR_DAY },
 	{ /* sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, sun6i_rtc_dt_ids);
-- 
2.17.6

Re: [PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string

[Rob Herring]

On Fri, 23 Jul 2021 16:38:29 +0100, Andre Przywara wrote:
> Add the obvious compatible name to the existing RTC binding.
> The actual RTC part of the device uses a different day/month/year
> storage scheme, so it's not compatible with the previous devices.
> Also the clock part is quite different, as there is no external 32K LOSC
> oscillator input.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml      | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 

Reviewed-by: Rob Herring <robh@kernel.org>

Re: [PATCH v8 03/11] rtc: sun6i: Fix time overflow handling

[Jernej Škrabec]

Hi Andre!

Dne petek, 23. julij 2021 ob 17:38:30 CEST je Andre Przywara napisal(a):
> Using "unsigned long" for UNIX timestamps is never a good idea, and
> comparing the value of such a variable against U32_MAX does not do
> anything useful on 32-bit systems.
> 
> Use the proper time64_t type when dealing with timestamps, and avoid
> cutting down the time range unnecessarily. This also fixes the flawed
> check for the alarm time being too far into the future.
> 
> The check for this condition is actually somewhat theoretical, as the
> RTC counts till 2033 only anyways, and 2^32 seconds from now is not
> before the year 2157 - at which point I hope nobody will be using this
> hardware anymore.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  drivers/rtc/rtc-sun6i.c | 14 +++++---------
>  1 file changed, 5 insertions(+), 9 deletions(-)

Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>

Best regards,
Jernej

Re: [PATCH v8 04/11] rtc: sun6i: Add support for linear day storage

[Jernej Škrabec]

Hi Andre!

Dne petek, 23. julij 2021 ob 17:38:31 CEST je Andre Przywara napisal(a):
> Newer versions of the Allwinner RTC, as for instance found in the H616
> SoC, no longer store a broken-down day/month/year representation in the
> RTC_DAY_REG, but just a linear day number.
> The user manual does not give any indication about the expected epoch
> time of this day count, but the BSP kernel uses the UNIX epoch, which
> allows easy support due to existing conversion functions in the kernel.
> 
> Allow tagging a compatible string with a flag, and use that to mark
> those new RTCs. Then convert between a UNIX day number (converted into
> seconds) and the broken-down day representation using mktime64() and
> time64_to_tm() in the set_time/get_time functions.
> 
> That enables support for the RTC in those new chips.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  drivers/rtc/rtc-sun6i.c | 66 +++++++++++++++++++++++++++--------------
>  1 file changed, 44 insertions(+), 22 deletions(-)

Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>

Best regards,
Jernej

Re: [PATCH v8 05/11] rtc: sun6i: Add support for broken-down alarm registers

[Jernej Škrabec]

Hi Andre!

Dne petek, 23. julij 2021 ob 17:38:32 CEST je Andre Przywara napisal(a):
> Newer versions of the Allwinner RTC, for instance as found in the H616
> SoC, not only store the current day as a linear number, but also change
> the way the alarm is handled: There are now two registers, that
> explicitly store the wakeup time, in the same format as the current
> time.
> 
> Add support for that variant by writing the requested wakeup time
> directly into the registers, instead of programming the seconds left, as
> the old SoCs required.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  drivers/rtc/rtc-sun6i.c | 60 +++++++++++++++++++++++++++++------------
>  1 file changed, 43 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> index a02be8bca6f3..f0ee20bfdccb 100644
> --- a/drivers/rtc/rtc-sun6i.c
> +++ b/drivers/rtc/rtc-sun6i.c
> @@ -48,7 +48,8 @@
>  
>  /* Alarm 0 (counter) */
>  #define SUN6I_ALRM_COUNTER			0x0020
> -#define SUN6I_ALRM_CUR_VAL			0x0024
> +/* This holds the remaining alarm seconds on older SoCs (current value) */
> +#define SUN6I_ALRM_COUNTER_HMS			0x0024
>  #define SUN6I_ALRM_EN				0x0028
>  #define SUN6I_ALRM_EN_CNT_EN			BIT(0)
>  #define SUN6I_ALRM_IRQ_EN			0x002c
> @@ -523,32 +524,57 @@ static int sun6i_rtc_setalarm(struct device *dev, 
struct rtc_wkalrm *wkalrm)
>  	struct sun6i_rtc_dev *chip = dev_get_drvdata(dev);
>  	struct rtc_time *alrm_tm = &wkalrm->time;
>  	struct rtc_time tm_now;
> -	time64_t time_now, time_set;
> +	time64_t time_set;
> +	u32 counter_val, counter_val_hms;
>  	int ret;
>  
> -	ret = sun6i_rtc_gettime(dev, &tm_now);
> -	if (ret < 0) {
> -		dev_err(dev, "Error in getting time\n");
> -		return -EINVAL;
> -	}
> -
>  	time_set = rtc_tm_to_time64(alrm_tm);
> -	time_now = rtc_tm_to_time64(&tm_now);
> -	if (time_set <= time_now) {
> -		dev_err(dev, "Date to set in the past\n");
> -		return -EINVAL;
> -	}
>  
> -	if ((time_set - time_now) > U32_MAX) {
> -		dev_err(dev, "Date too far in the future\n");
> -		return -EINVAL;
> +	if (chip->flags & RTC_LINEAR_DAY) {
> +		time64_t seconds;
> +
> +		/*
> +		 * The alarm registers hold the actual alarm time, 
encoded
> +		 * in the same way (linear day + HMS) as the current 
time.
> +		 */
> +		counter_val_hms = SUN6I_TIME_SET_SEC_VALUE(alrm_tm-
>tm_sec)  |
> +				  
SUN6I_TIME_SET_MIN_VALUE(alrm_tm->tm_min)  |
> +				  
SUN6I_TIME_SET_HOUR_VALUE(alrm_tm->tm_hour);
> +		seconds = mktime64(alrm_tm->tm_year + 1900, alrm_tm-
>tm_mon,
> +				   alrm_tm->tm_mday, 0, 0, 0);

While above line should work, it's confusing why you're adding 1900 to years. 
In my opinion it would be better to use same trick you used in patch 4 - 
rtc_tm_to_time64() with hours, minutes and seconds set to 0. Or maybe you 
don't even need to do that, since division by SECS_PER_DAY will round down 
anyway. In such way you hide RTC internal representation detail which doesn't 
need to be exposed here.

Once fixed:
Reviewed by: Jernej Skrabec <jernej.skrabec@gmail.com>

Best regards,
Jernej

> +		counter_val = div_u64(seconds, SECS_PER_DAY);
> +	} else {
> +		/* The alarm register holds the number of seconds left. 
*/
> +		time64_t time_now;
> +
> +		ret = sun6i_rtc_gettime(dev, &tm_now);
> +		if (ret < 0) {
> +			dev_err(dev, "Error in getting time\n");
> +			return -EINVAL;
> +		}
> +
> +		time_now = rtc_tm_to_time64(&tm_now);
> +		if (time_set <= time_now) {
> +			dev_err(dev, "Date to set in the past\n");
> +			return -EINVAL;
> +		}
> +		if ((time_set - time_now) > U32_MAX) {
> +			dev_err(dev, "Date too far in the future\n");
> +			return -EINVAL;
> +		}
> +
> +		counter_val = time_set - time_now;
>  	}
>  
>  	sun6i_rtc_setaie(0, chip);
>  	writel(0, chip->base + SUN6I_ALRM_COUNTER);
> +	if (chip->flags & RTC_LINEAR_DAY)
> +		writel(0, chip->base + SUN6I_ALRM_COUNTER_HMS);
>  	usleep_range(100, 300);
>  
> -	writel(time_set - time_now, chip->base + SUN6I_ALRM_COUNTER);
> +	writel(counter_val, chip->base + SUN6I_ALRM_COUNTER);
> +	if (chip->flags & RTC_LINEAR_DAY)
> +		writel(counter_val_hms, chip->base + 
SUN6I_ALRM_COUNTER_HMS);
>  	chip->alarm = time_set;
>  
>  	sun6i_rtc_setaie(wkalrm->enabled, chip);
> -- 
> 2.17.6
> 
> 

Re: [PATCH v8 06/11] rtc: sun6i: Add support for RTCs without external LOSCs

[Jernej Škrabec]

Hi Andre!

Dne petek, 23. julij 2021 ob 17:38:33 CEST je Andre Przywara napisal(a):
> Some newer Allwinner RTCs (for instance the one in the H616 SoC) lack
> a pin for an external 32768 Hz oscillator. As a consequence, this LOSC
> can't be selected as the RTC clock source, and we must rely on the
> internal RC oscillator.
> To allow additions of clocks to the RTC node, add a feature bit to ignore
> any provided clocks for now (the current code would think this is the
> external LOSC). Later DTs and code can then for instance add the PLL
> based clock input, and older kernel won't get confused.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  drivers/rtc/rtc-sun6i.c | 16 +++++++++++-----
>  1 file changed, 11 insertions(+), 5 deletions(-)
> 

Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>

Best regards,
Jernej

Re: [PATCH v8 07/11] rtc: sun6i: Add Allwinner H616 support

[Jernej Škrabec]

Hi Andre!

Dne petek, 23. julij 2021 ob 17:38:34 CEST je Andre Przywara napisal(a):
> The H616 RTC changes its day storage to the newly introduced linear day
> scheme, so pair the new compatible string with this feature flag.
> The clock part is missing an external 32768 Hz oscillator input pin,
> for future expansion we must thus ignore any provided clock for now.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  drivers/rtc/rtc-sun6i.c | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 

Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>

Best regards,
Jernej

Re: [PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2010 bytes --]

Hi,

On Fri, Jul 23, 2021 at 04:38:29PM +0100, Andre Przywara wrote:
> Add the obvious compatible name to the existing RTC binding.
> The actual RTC part of the device uses a different day/month/year
> storage scheme, so it's not compatible with the previous devices.
> Also the clock part is quite different, as there is no external 32K LOSC
> oscillator input.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>
> ---
>  .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml      | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> index beeb90e55727..d8a6500e5840 100644
> --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> @@ -26,6 +26,7 @@ properties:
>            - const: allwinner,sun50i-a64-rtc
>            - const: allwinner,sun8i-h3-rtc
>        - const: allwinner,sun50i-h6-rtc
> +      - const: allwinner,sun50i-h616-rtc
>  
>    reg:
>      maxItems: 1
> @@ -104,6 +105,19 @@ allOf:
>            minItems: 3
>            maxItems: 3
>  
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: allwinner,sun50i-h616-rtc
> +
> +    then:
> +      properties:
> +        clock-output-names:
> +          minItems: 3
> +          maxItems: 3

You don't need both of them when they are equal

> +        clocks: false
> +

It's not entirely clear to me what those clocks are about though. If we
look at the clock output in the user manual, it looks like there's only
two clocks that are actually being output: the 32k "fanout" clock and
the losc. What are the 3 you're talking about?

Also, it looks like the 32k fanout clock needs at least the hosc or
pll-periph in input, so we probably don't want to ask for no parent
clock?

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v8 05/11] rtc: sun6i: Add support for broken-down alarm registers

[Andre Przywara]

On Sun, 25 Jul 2021 08:11:49 +0200
Jernej Škrabec <jernej.skrabec@gmail.com> wrote:

Hi Jernej,

> Dne petek, 23. julij 2021 ob 17:38:32 CEST je Andre Przywara napisal(a):
> > Newer versions of the Allwinner RTC, for instance as found in the H616
> > SoC, not only store the current day as a linear number, but also change
> > the way the alarm is handled: There are now two registers, that
> > explicitly store the wakeup time, in the same format as the current
> > time.
> > 
> > Add support for that variant by writing the requested wakeup time
> > directly into the registers, instead of programming the seconds left, as
> > the old SoCs required.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> >  drivers/rtc/rtc-sun6i.c | 60 +++++++++++++++++++++++++++++------------
> >  1 file changed, 43 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> > index a02be8bca6f3..f0ee20bfdccb 100644
> > --- a/drivers/rtc/rtc-sun6i.c
> > +++ b/drivers/rtc/rtc-sun6i.c
> > @@ -48,7 +48,8 @@
> >  
> >  /* Alarm 0 (counter) */
> >  #define SUN6I_ALRM_COUNTER			0x0020
> > -#define SUN6I_ALRM_CUR_VAL			0x0024
> > +/* This holds the remaining alarm seconds on older SoCs (current value) */
> > +#define SUN6I_ALRM_COUNTER_HMS			0x0024
> >  #define SUN6I_ALRM_EN				0x0028
> >  #define SUN6I_ALRM_EN_CNT_EN			BIT(0)
> >  #define SUN6I_ALRM_IRQ_EN			0x002c
> > @@ -523,32 +524,57 @@ static int sun6i_rtc_setalarm(struct device *dev,   
> struct rtc_wkalrm *wkalrm)
> >  	struct sun6i_rtc_dev *chip = dev_get_drvdata(dev);
> >  	struct rtc_time *alrm_tm = &wkalrm->time;
> >  	struct rtc_time tm_now;
> > -	time64_t time_now, time_set;
> > +	time64_t time_set;
> > +	u32 counter_val, counter_val_hms;
> >  	int ret;
> >  
> > -	ret = sun6i_rtc_gettime(dev, &tm_now);
> > -	if (ret < 0) {
> > -		dev_err(dev, "Error in getting time\n");
> > -		return -EINVAL;
> > -	}
> > -
> >  	time_set = rtc_tm_to_time64(alrm_tm);
> > -	time_now = rtc_tm_to_time64(&tm_now);
> > -	if (time_set <= time_now) {
> > -		dev_err(dev, "Date to set in the past\n");
> > -		return -EINVAL;
> > -	}
> >  
> > -	if ((time_set - time_now) > U32_MAX) {
> > -		dev_err(dev, "Date too far in the future\n");
> > -		return -EINVAL;
> > +	if (chip->flags & RTC_LINEAR_DAY) {
> > +		time64_t seconds;
> > +
> > +		/*
> > +		 * The alarm registers hold the actual alarm time,   
> encoded
> > +		 * in the same way (linear day + HMS) as the current   
> time.
> > +		 */
> > +		counter_val_hms = SUN6I_TIME_SET_SEC_VALUE(alrm_tm-
> >tm_sec)  |
> > +				    
> SUN6I_TIME_SET_MIN_VALUE(alrm_tm->tm_min)  |
> > +				    
> SUN6I_TIME_SET_HOUR_VALUE(alrm_tm->tm_hour);
> > +		seconds = mktime64(alrm_tm->tm_year + 1900, alrm_tm-
> >tm_mon,
> > +				   alrm_tm->tm_mday, 0, 0, 0);  
> 
> While above line should work, it's confusing why you're adding 1900 to years. 
> In my opinion it would be better to use same trick you used in patch 4 - 
> rtc_tm_to_time64() with hours, minutes and seconds set to 0.

IIRC setalarm does not want the time struct to be changed, but this is
OK in settime. But anyway ...

> Or maybe you 
> don't even need to do that, since division by SECS_PER_DAY will round down 
> anyway. In such way you hide RTC internal representation detail which doesn't 
> need to be exposed here.

That is indeed a very clever idea! I changed both settime and setalarm
accordingly now, adding a comment about this.

> 
> Once fixed:
> Reviewed by: Jernej Skrabec <jernej.skrabec@gmail.com>

Many thanks for the reviews!

Cheers,
Andre

> > +		counter_val = div_u64(seconds, SECS_PER_DAY);
> > +	} else {
> > +		/* The alarm register holds the number of seconds left.   
> */
> > +		time64_t time_now;
> > +
> > +		ret = sun6i_rtc_gettime(dev, &tm_now);
> > +		if (ret < 0) {
> > +			dev_err(dev, "Error in getting time\n");
> > +			return -EINVAL;
> > +		}
> > +
> > +		time_now = rtc_tm_to_time64(&tm_now);
> > +		if (time_set <= time_now) {
> > +			dev_err(dev, "Date to set in the past\n");
> > +			return -EINVAL;
> > +		}
> > +		if ((time_set - time_now) > U32_MAX) {
> > +			dev_err(dev, "Date too far in the future\n");
> > +			return -EINVAL;
> > +		}
> > +
> > +		counter_val = time_set - time_now;
> >  	}
> >  
> >  	sun6i_rtc_setaie(0, chip);
> >  	writel(0, chip->base + SUN6I_ALRM_COUNTER);
> > +	if (chip->flags & RTC_LINEAR_DAY)
> > +		writel(0, chip->base + SUN6I_ALRM_COUNTER_HMS);
> >  	usleep_range(100, 300);
> >  
> > -	writel(time_set - time_now, chip->base + SUN6I_ALRM_COUNTER);
> > +	writel(counter_val, chip->base + SUN6I_ALRM_COUNTER);
> > +	if (chip->flags & RTC_LINEAR_DAY)
> > +		writel(counter_val_hms, chip->base +   
> SUN6I_ALRM_COUNTER_HMS);
> >  	chip->alarm = time_set;
> >  
> >  	sun6i_rtc_setaie(wkalrm->enabled, chip);
> > -- 
> > 2.17.6
> > 
> >   
> 
> 
> 

Re: [PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string

[Andre Przywara]

On Mon, 26 Jul 2021 16:41:37 +0200
Maxime Ripard <maxime@cerno.tech> wrote:

> Hi,
> 
> On Fri, Jul 23, 2021 at 04:38:29PM +0100, Andre Przywara wrote:
> > Add the obvious compatible name to the existing RTC binding.
> > The actual RTC part of the device uses a different day/month/year
> > storage scheme, so it's not compatible with the previous devices.
> > Also the clock part is quite different, as there is no external 32K LOSC
> > oscillator input.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> >
> > ---
> >  .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml      | 14 ++++++++++++++
> >  1 file changed, 14 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > index beeb90e55727..d8a6500e5840 100644
> > --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > @@ -26,6 +26,7 @@ properties:
> >            - const: allwinner,sun50i-a64-rtc
> >            - const: allwinner,sun8i-h3-rtc
> >        - const: allwinner,sun50i-h6-rtc
> > +      - const: allwinner,sun50i-h616-rtc
> >  
> >    reg:
> >      maxItems: 1
> > @@ -104,6 +105,19 @@ allOf:
> >            minItems: 3
> >            maxItems: 3
> >  
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          contains:
> > +            const: allwinner,sun50i-h616-rtc
> > +
> > +    then:
> > +      properties:
> > +        clock-output-names:
> > +          minItems: 3
> > +          maxItems: 3  
> 
> You don't need both of them when they are equal
> 
> > +        clocks: false
> > +  
> 
> It's not entirely clear to me what those clocks are about though. If we
> look at the clock output in the user manual, it looks like there's only
> two clocks that are actually being output: the 32k "fanout" clock and
> the losc. What are the 3 you're talking about?]

I see three: the raw SYSTEM "CLK32K_LOSC", the RTC input + debounce
clock (/32), and the multiplexed PAD.

> Also, it looks like the 32k fanout clock needs at least the hosc or
> pll-periph in input, so we probably don't want to ask for no parent
> clock?

Well, we never seem to reference the HOSC this way, this was always
somewhat explicit. And yes, there is PLL-PERIPH as an input, but we
don't support this yet. So I went with 0 input clocks *for now*: the
driver can then ignore all clocks, so any clock referenced in the DT
later won't cause any harm. This will all be addressed by Samuel's RTC
clock patch, which will also touch the H6, IIRC. And it looks like we
will need to touch the binding anyway then, but can then just *extend*
this.

The point is that everything works(TM) as of now: The consumers
(pinctrl) get their LOSC clock, and can go ahead. This is in the
interest to get us moving now, and refine the actual implementation
later. In this case this will only change the accuracy of the LOSC
frequency (HOSC/x, PLL/y, calibrated RC), but won't change the
semantics.

Cheers,
Andre

Re: [PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 3440 bytes --]

Hi,

On Mon, Aug 02, 2021 at 01:39:38AM +0100, Andre Przywara wrote:
> On Mon, 26 Jul 2021 16:41:37 +0200
> Maxime Ripard <maxime@cerno.tech> wrote:
> 
> > Hi,
> > 
> > On Fri, Jul 23, 2021 at 04:38:29PM +0100, Andre Przywara wrote:
> > > Add the obvious compatible name to the existing RTC binding.
> > > The actual RTC part of the device uses a different day/month/year
> > > storage scheme, so it's not compatible with the previous devices.
> > > Also the clock part is quite different, as there is no external 32K LOSC
> > > oscillator input.
> > > 
> > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > >
> > > ---
> > >  .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml      | 14 ++++++++++++++
> > >  1 file changed, 14 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > > index beeb90e55727..d8a6500e5840 100644
> > > --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > > +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > > @@ -26,6 +26,7 @@ properties:
> > >            - const: allwinner,sun50i-a64-rtc
> > >            - const: allwinner,sun8i-h3-rtc
> > >        - const: allwinner,sun50i-h6-rtc
> > > +      - const: allwinner,sun50i-h616-rtc
> > >  
> > >    reg:
> > >      maxItems: 1
> > > @@ -104,6 +105,19 @@ allOf:
> > >            minItems: 3
> > >            maxItems: 3
> > >  
> > > +  - if:
> > > +      properties:
> > > +        compatible:
> > > +          contains:
> > > +            const: allwinner,sun50i-h616-rtc
> > > +
> > > +    then:
> > > +      properties:
> > > +        clock-output-names:
> > > +          minItems: 3
> > > +          maxItems: 3  
> > 
> > You don't need both of them when they are equal
> > 
> > > +        clocks: false
> > > +  
> > 
> > It's not entirely clear to me what those clocks are about though. If we
> > look at the clock output in the user manual, it looks like there's only
> > two clocks that are actually being output: the 32k "fanout" clock and
> > the losc. What are the 3 you're talking about?]
> 
> I see three: the raw SYSTEM "CLK32K_LOSC", the RTC input + debounce
> clock (/32), and the multiplexed PAD.

But the input and debounce clock is only for the RTC itself right? So it
should be local to the driver and doesn't need to be made available to
the other drivers

Either way, what this list is must be documented.

> > Also, it looks like the 32k fanout clock needs at least the hosc or
> > pll-periph in input, so we probably don't want to ask for no parent
> > clock?
> 
> Well, we never seem to reference the HOSC this way, this was always
> somewhat explicit. And yes, there is PLL-PERIPH as an input, but we
> don't support this yet. So I went with 0 input clocks *for now*: the
> driver can then ignore all clocks, so any clock referenced in the DT
> later won't cause any harm. This will all be addressed by Samuel's RTC
> clock patch, which will also touch the H6, IIRC. And it looks like we
> will need to touch the binding anyway then, but can then just *extend*
> this.

You mentioned that series several times already and never provided an
explanation for what it was supposed to be doing except fixing
everything. What's the general plan for that series?

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string

[Alexandre Belloni]

On 17/08/2021 09:38:10+0200, Maxime Ripard wrote:
> > > It's not entirely clear to me what those clocks are about though. If we
> > > look at the clock output in the user manual, it looks like there's only
> > > two clocks that are actually being output: the 32k "fanout" clock and
> > > the losc. What are the 3 you're talking about?]
> > 
> > I see three: the raw SYSTEM "CLK32K_LOSC", the RTC input + debounce
> > clock (/32), and the multiplexed PAD.
> 
> But the input and debounce clock is only for the RTC itself right? So it
> should be local to the driver and doesn't need to be made available to
> the other drivers
> 

Shouldn't they be exposed to be able to use assigned-clock?


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string

[Andre Przywara]

On Tue, 17 Aug 2021 09:38:10 +0200
Maxime Ripard <maxime@cerno.tech> wrote:

Hi Maxime,

> On Mon, Aug 02, 2021 at 01:39:38AM +0100, Andre Przywara wrote:
> > On Mon, 26 Jul 2021 16:41:37 +0200
> > Maxime Ripard <maxime@cerno.tech> wrote:
> >   
> > > Hi,
> > > 
> > > On Fri, Jul 23, 2021 at 04:38:29PM +0100, Andre Przywara wrote:  
> > > > Add the obvious compatible name to the existing RTC binding.
> > > > The actual RTC part of the device uses a different day/month/year
> > > > storage scheme, so it's not compatible with the previous devices.
> > > > Also the clock part is quite different, as there is no external 32K LOSC
> > > > oscillator input.
> > > > 
> > > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > > >
> > > > ---
> > > >  .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml      | 14 ++++++++++++++
> > > >  1 file changed, 14 insertions(+)
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > > > index beeb90e55727..d8a6500e5840 100644
> > > > --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > > > +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > > > @@ -26,6 +26,7 @@ properties:
> > > >            - const: allwinner,sun50i-a64-rtc
> > > >            - const: allwinner,sun8i-h3-rtc
> > > >        - const: allwinner,sun50i-h6-rtc
> > > > +      - const: allwinner,sun50i-h616-rtc
> > > >  
> > > >    reg:
> > > >      maxItems: 1
> > > > @@ -104,6 +105,19 @@ allOf:
> > > >            minItems: 3
> > > >            maxItems: 3
> > > >  
> > > > +  - if:
> > > > +      properties:
> > > > +        compatible:
> > > > +          contains:
> > > > +            const: allwinner,sun50i-h616-rtc
> > > > +
> > > > +    then:
> > > > +      properties:
> > > > +        clock-output-names:
> > > > +          minItems: 3
> > > > +          maxItems: 3    
> > > 
> > > You don't need both of them when they are equal
> > >   
> > > > +        clocks: false
> > > > +    
> > > 
> > > It's not entirely clear to me what those clocks are about though. If we
> > > look at the clock output in the user manual, it looks like there's only
> > > two clocks that are actually being output: the 32k "fanout" clock and
> > > the losc. What are the 3 you're talking about?]  
> > 
> > I see three: the raw SYSTEM "CLK32K_LOSC", the RTC input + debounce
> > clock (/32), and the multiplexed PAD.  
> 
> But the input and debounce clock is only for the RTC itself right? So it
> should be local to the driver and doesn't need to be made available to
> the other drivers

I understood "debounce" as being the clock used for the pinctrl
debouncer. What would it debounce otherwise? Do you think that this
"debounce circuit" is something internal to the RTC and is totally
irrelevant for us?

But in general I looked at how many *different* clocks this diagram
describes, and I count: one unaltered ("SYSTEM"), one "div by
32" (RTC/debounce), and one multiplexed. My aim was to avoid
DT binding changes when we later discover we do need one of them for
something (as happened in the past). So three seemed to be the safe
choice here, to avoid surprises. In the worst case we just will never
reference one of them.

> Either way, what this list is must be documented.

You mean to overwrite the "description" stanza for clock-output-names?
And can this be done in the per-SoC parts in the later part of the
binding, keeping the existing description?

Cheers,
Andre

> 
> > > Also, it looks like the 32k fanout clock needs at least the hosc or
> > > pll-periph in input, so we probably don't want to ask for no parent
> > > clock?  
> > 
> > Well, we never seem to reference the HOSC this way, this was always
> > somewhat explicit. And yes, there is PLL-PERIPH as an input, but we
> > don't support this yet. So I went with 0 input clocks *for now*: the
> > driver can then ignore all clocks, so any clock referenced in the DT
> > later won't cause any harm. This will all be addressed by Samuel's RTC
> > clock patch, which will also touch the H6, IIRC. And it looks like we
> > will need to touch the binding anyway then, but can then just *extend*
> > this.  
> 
> You mentioned that series several times already and never provided an
> explanation for what it was supposed to be doing except fixing
> everything. What's the general plan for that series?
> 
> Maxime

Re: [PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 976 bytes --]

Salut Alex,

On Tue, Aug 17, 2021 at 10:13:11AM +0200, Alexandre Belloni wrote:
> On 17/08/2021 09:38:10+0200, Maxime Ripard wrote:
> > > > It's not entirely clear to me what those clocks are about though. If we
> > > > look at the clock output in the user manual, it looks like there's only
> > > > two clocks that are actually being output: the 32k "fanout" clock and
> > > > the losc. What are the 3 you're talking about?]
> > > 
> > > I see three: the raw SYSTEM "CLK32K_LOSC", the RTC input + debounce
> > > clock (/32), and the multiplexed PAD.
> > 
> > But the input and debounce clock is only for the RTC itself right? So it
> > should be local to the driver and doesn't need to be made available to
> > the other drivers
> > 
> 
> Shouldn't they be exposed to be able to use assigned-clock?

I'm not sure we would even need that? If it's an internal clock to the
RTC, then we probably won't ever need to change it from the device tree?

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string

[Samuel Holland]

On 8/18/21 4:04 AM, Andre Przywara wrote:
> On Tue, 17 Aug 2021 09:38:10 +0200
> Maxime Ripard <maxime@cerno.tech> wrote:
> 
> Hi Maxime,
> 
>> On Mon, Aug 02, 2021 at 01:39:38AM +0100, Andre Przywara wrote:
>>> On Mon, 26 Jul 2021 16:41:37 +0200
>>> Maxime Ripard <maxime@cerno.tech> wrote:
>>>   
>>>> Hi,
>>>>
>>>> On Fri, Jul 23, 2021 at 04:38:29PM +0100, Andre Przywara wrote:  
>>>>> Add the obvious compatible name to the existing RTC binding.
>>>>> The actual RTC part of the device uses a different day/month/year
>>>>> storage scheme, so it's not compatible with the previous devices.
>>>>> Also the clock part is quite different, as there is no external 32K LOSC
>>>>> oscillator input.
>>>>>
>>>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>>>>
>>>>> ---
>>>>>  .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml      | 14 ++++++++++++++
>>>>>  1 file changed, 14 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
>>>>> index beeb90e55727..d8a6500e5840 100644
>>>>> --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
>>>>> +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
>>>>> @@ -26,6 +26,7 @@ properties:
>>>>>            - const: allwinner,sun50i-a64-rtc
>>>>>            - const: allwinner,sun8i-h3-rtc
>>>>>        - const: allwinner,sun50i-h6-rtc
>>>>> +      - const: allwinner,sun50i-h616-rtc
>>>>>  
>>>>>    reg:
>>>>>      maxItems: 1
>>>>> @@ -104,6 +105,19 @@ allOf:
>>>>>            minItems: 3
>>>>>            maxItems: 3
>>>>>  
>>>>> +  - if:
>>>>> +      properties:
>>>>> +        compatible:
>>>>> +          contains:
>>>>> +            const: allwinner,sun50i-h616-rtc
>>>>> +
>>>>> +    then:
>>>>> +      properties:
>>>>> +        clock-output-names:
>>>>> +          minItems: 3
>>>>> +          maxItems: 3    
>>>>
>>>> You don't need both of them when they are equal
>>>>   
>>>>> +        clocks: false
>>>>> +    
>>>>
>>>> It's not entirely clear to me what those clocks are about though. If we
>>>> look at the clock output in the user manual, it looks like there's only
>>>> two clocks that are actually being output: the 32k "fanout" clock and
>>>> the losc. What are the 3 you're talking about?]  
>>>
>>> I see three: the raw SYSTEM "CLK32K_LOSC", the RTC input + debounce
>>> clock (/32), and the multiplexed PAD.  
>>
>> But the input and debounce clock is only for the RTC itself right? So it
>> should be local to the driver and doesn't need to be made available to
>> the other drivers
> 
> I understood "debounce" as being the clock used for the pinctrl
> debouncer. What would it debounce otherwise? Do you think that this
> "debounce circuit" is something internal to the RTC and is totally
> irrelevant for us?

I'm pretty sure this is the debounce for the NMI and the SoC reset signal, not
the pinctrl. The pinctrl debounce clock pretty clearly references 32 kHz.

> But in general I looked at how many *different* clocks this diagram
> describes, and I count: one unaltered ("SYSTEM"), one "div by
> 32" (RTC/debounce), and one multiplexed. My aim was to avoid
> DT binding changes when we later discover we do need one of them for
> something (as happened in the past). So three seemed to be the safe
> choice here, to avoid surprises. In the worst case we just will never
> reference one of them.

Plus RC16M/IOSC (and depending on how you look at it, DCXO24M/HOSC).

>> Either way, what this list is must be documented.
> 
> You mean to overwrite the "description" stanza for clock-output-names?
> And can this be done in the per-SoC parts in the later part of the
> binding, keeping the existing description?
> 
> Cheers,
> Andre
> 
>>
>>>> Also, it looks like the 32k fanout clock needs at least the hosc or
>>>> pll-periph in input, so we probably don't want to ask for no parent
>>>> clock?  

Do you suggest we fix this for the existing bindings?

>>> Well, we never seem to reference the HOSC this way, this was always
>>> somewhat explicit. And yes, there is PLL-PERIPH as an input, but we
>>> don't support this yet. So I went with 0 input clocks *for now*: the
>>> driver can then ignore all clocks, so any clock referenced in the DT
>>> later won't cause any harm. This will all be addressed by Samuel's RTC
>>> clock patch, which will also touch the H6, IIRC. And it looks like we
>>> will need to touch the binding anyway then, but can then just *extend*
>>> this.  
>>
>> You mentioned that series several times already and never provided an
>> explanation for what it was supposed to be doing except fixing
>> everything. What's the general plan for that series?

This is my fault for not sending anything yet. Since the initial version of the
driver had the RTC providing HOSC, it depended on converting the existing A100,
H6, and H616 CCU drivers to use .fw_name for parents, since those drivers
hardcode two different global names for HOSC. And I had no opportunit to do that
yet.

However, I should really send something that 100% matches the current binding
for SoCs where that exists (i.e. osc24M is a fixed clock), and doing so is a
smaller job.

On the other hand, having osc24M as an RTC *output* neatly sidesteps the fact
that it has been missing from the input list :)

(But on the other-other hand, A50 gets even more fun, as the HOSC crystal may
not be 24MHz anymore. So the RTC has to choose one of three possible HOSC->LOSC
dividers based on the HOSC frequency. But there is no register for HOSC
frequency. So in this case it is convenient to have HOSC as a separate fixed
clock input.)

The basic idea of my patch is that using the CCU library code lets us cleanly
have slightly different clock trees for each of the RTC variants that Allwinner
comes up with.

The secondary goal is to add support for osc32k calibration.

An early version of the patch is here[1], and I will send something as soon as I
have made the modifications described above. But I know you were skeptical about
moving the clock part out of the RTC driver. So if you NACK that, somebody will
have to add all of the variants to the RTC driver.

Regards,
Samuel

[1]: https://github.com/smaeul/linux/commit/9510ca9e95cb.patch

Re: [PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 5114 bytes --]

On Wed, Aug 18, 2021 at 10:04:07AM +0100, Andre Przywara wrote:
> On Tue, 17 Aug 2021 09:38:10 +0200
> Maxime Ripard <maxime@cerno.tech> wrote:
> 
> Hi Maxime,
> 
> > On Mon, Aug 02, 2021 at 01:39:38AM +0100, Andre Przywara wrote:
> > > On Mon, 26 Jul 2021 16:41:37 +0200
> > > Maxime Ripard <maxime@cerno.tech> wrote:
> > >   
> > > > Hi,
> > > > 
> > > > On Fri, Jul 23, 2021 at 04:38:29PM +0100, Andre Przywara wrote:  
> > > > > Add the obvious compatible name to the existing RTC binding.
> > > > > The actual RTC part of the device uses a different day/month/year
> > > > > storage scheme, so it's not compatible with the previous devices.
> > > > > Also the clock part is quite different, as there is no external 32K LOSC
> > > > > oscillator input.
> > > > > 
> > > > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > > > >
> > > > > ---
> > > > >  .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml      | 14 ++++++++++++++
> > > > >  1 file changed, 14 insertions(+)
> > > > > 
> > > > > diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > > > > index beeb90e55727..d8a6500e5840 100644
> > > > > --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > > > > +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > > > > @@ -26,6 +26,7 @@ properties:
> > > > >            - const: allwinner,sun50i-a64-rtc
> > > > >            - const: allwinner,sun8i-h3-rtc
> > > > >        - const: allwinner,sun50i-h6-rtc
> > > > > +      - const: allwinner,sun50i-h616-rtc
> > > > >  
> > > > >    reg:
> > > > >      maxItems: 1
> > > > > @@ -104,6 +105,19 @@ allOf:
> > > > >            minItems: 3
> > > > >            maxItems: 3
> > > > >  
> > > > > +  - if:
> > > > > +      properties:
> > > > > +        compatible:
> > > > > +          contains:
> > > > > +            const: allwinner,sun50i-h616-rtc
> > > > > +
> > > > > +    then:
> > > > > +      properties:
> > > > > +        clock-output-names:
> > > > > +          minItems: 3
> > > > > +          maxItems: 3    
> > > > 
> > > > You don't need both of them when they are equal
> > > >   
> > > > > +        clocks: false
> > > > > +    
> > > > 
> > > > It's not entirely clear to me what those clocks are about though. If we
> > > > look at the clock output in the user manual, it looks like there's only
> > > > two clocks that are actually being output: the 32k "fanout" clock and
> > > > the losc. What are the 3 you're talking about?]  
> > > 
> > > I see three: the raw SYSTEM "CLK32K_LOSC", the RTC input + debounce
> > > clock (/32), and the multiplexed PAD.  
> > 
> > But the input and debounce clock is only for the RTC itself right? So it
> > should be local to the driver and doesn't need to be made available to
> > the other drivers
> 
> I understood "debounce" as being the clock used for the pinctrl
> debouncer. What would it debounce otherwise? Do you think that this
> "debounce circuit" is something internal to the RTC and is totally
> irrelevant for us?

I don't think that's it.

The Debounce circuit is after the 32 divider, so we have a clock rate of
1kHz (Figure 3-35, page 275)

The PIO Interrupt debouncing can use either a 32kHz or 24MHz clock, so
the rates don't match, and given the naming would rather be clocked from
CLK32K_LOSC.

The DCXO_CTRL_REG (Section 3.13.6.13) hints at something different
though, it says:

"
CLK16M_RC_EN
1: Enable
0: Disable
The related register configuration is necessary to ensure the reset debounce
circuit has a stable clock source.
The first time SoC starts up, by default, the reset debounce circuit of SoC
uses 32K divided by RC16M. In power-off, software reads the related bit to
ensure whether EXT32K is working normally, if it is normal, first switch the
clock source of debounce circuit to EXT32K, then close RC16M.
Without EXT32K scenario or external RTC scenario, software confirms firstly
whether EXT32K is working normally before switching, or software does not
close RC16M.
"

I'm not sure why it would be useful for though

> But in general I looked at how many *different* clocks this diagram
> describes, and I count: one unaltered ("SYSTEM"), one "div by
> 32" (RTC/debounce), and one multiplexed. My aim was to avoid
> DT binding changes when we later discover we do need one of them for
> something (as happened in the past). So three seemed to be the safe
> choice here, to avoid surprises. In the worst case we just will never
> reference one of them.

My concern is the pretty much the opposite: if we ever need to remove it
for whatever reason, if it's in the DT, we can't. While we can totally
add it if we need it.

> > Either way, what this list is must be documented.
> 
> You mean to overwrite the "description" stanza for clock-output-names?

Yes

> And can this be done in the per-SoC parts in the later part of the
> binding, keeping the existing description?

Sure

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]