This patches series adds a new driver for the RTC found in the Mstar
SSD20xD SoCs. It adds a basic rtc driver, the corresponding devicetree
bindings and its documentation.
The rtctest (from selftests) has been passed on this driver, with the
following output:
# rtctest
TAP version 13
1..8
# Starting 8 tests from 1 test cases.
# RUN rtc.date_read ...
# rtctest.c:52:date_read:Current RTC date/time is 17/05/2023 15:58:12.
# OK rtc.date_read
ok 1 rtc.date_read
# RUN rtc.date_read_loop ...
# rtctest.c:95:date_read_loop:Continuously reading RTC time for 30s (with 11ms breaks after every read).
# rtctest.c:122:date_read_loop:Performed 888 RTC time reads.
# OK rtc.date_read_loop
ok 2 rtc.date_read_loop
# RUN rtc.uie_read ...
# rtctest.c:137:uie_read:skip update IRQs not supported.
# OK rtc.uie_read
ok 3 rtc.uie_read
# RUN rtc.uie_select ...
# rtctest.c:166:uie_select:skip update IRQs not supported.
# OK rtc.uie_select
ok 4 rtc.uie_select
# RUN rtc.alarm_alm_set ...
# rtctest.c:214:alarm_alm_set:skip alarms are not supported.
# OK rtc.alarm_alm_set
ok 5 rtc.alarm_alm_set
# RUN rtc.alarm_wkalm_set ...
# rtctest.c:274:alarm_wkalm_set:skip alarms are not supported.
# OK rtc.alarm_wkalm_set
ok 6 rtc.alarm_wkalm_set
# RUN rtc.alarm_alm_set_minute ...
# rtctest.c:324:alarm_alm_set_minute:skip alarms are not supported.
# OK rtc.alarm_alm_set_minute
ok 7 rtc.alarm_alm_set_minute
# RUN rtc.alarm_wkalm_set_minute ...
# rtctest.c:384:alarm_wkalm_set_minute:skip alarms are not supported.
# OK rtc.alarm_wkalm_set_minute
ok 8 rtc.alarm_wkalm_set_minute
# PASSED: 8 / 8 tests passed.
# Totals: pass:8 fail:0 xfail:0 xpass:0 skip:0 error:0
Romain Perier (3):
rtc: Add support for the SSD20xD RTC
dt-bindings: rtc: Add Mstar SSD20xD RTC devicetree bindings
documentation
ARM: dts: mstar: Enable rtc for SSD20xD
.../bindings/rtc/mstar,ssd20xd-rtc.yaml | 37 +++
arch/arm/boot/dts/mstar-infinity2m.dtsi | 5 +
drivers/rtc/Kconfig | 11 +
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-ssd20xd.c | 249 ++++++++++++++++++
5 files changed, 303 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/mstar,ssd20xd-rtc.yaml
create mode 100644 drivers/rtc/rtc-ssd20xd.c
--
2.39.2
This adds the documentation for the devicetree bindings of the Mstar
SSD20xD RTC driver.
Signed-off-by: Romain Perier <[email protected]>
---
.../bindings/rtc/mstar,ssd20xd-rtc.yaml | 37 +++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/mstar,ssd20xd-rtc.yaml
diff --git a/Documentation/devicetree/bindings/rtc/mstar,ssd20xd-rtc.yaml b/Documentation/devicetree/bindings/rtc/mstar,ssd20xd-rtc.yaml
new file mode 100644
index 000000000000..2acd86cce69f
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/mstar,ssd20xd-rtc.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/mstar,ssd20xd-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mstar SSD20xD RTC
+
+allOf:
+ - $ref: rtc.yaml#
+
+maintainers:
+ - Daniel Palmer <[email protected]>
+ - Romain Perier <[email protected]>
+
+properties:
+ compatible:
+ enum:
+ - mstar,ssd20xd-rtc
+ reg:
+ maxItems: 1
+
+ start-year: true
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ rtc@6800 {
+ compatible = "mstar,ssd20xd-rtc";
+ reg = <0x6800 0x200>;
+ };
+...
--
2.39.2
Newer SigmaStar SSD20xD SoCs contain a really low power RTC (300uA claimed),
capable of running while the system is sleeping (battery powered), this
is not the case with the other RTC on older SoCs. This adds basic support
for this RTC block.
Signed-off-by: Romain Perier <[email protected]>
Co-developed-by: Daniel Palmer <[email protected]>
Signed-off-by: Daniel Palmer <[email protected]>
---
drivers/rtc/Kconfig | 11 ++
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-ssd20xd.c | 249 ++++++++++++++++++++++++++++++++++++++
3 files changed, 261 insertions(+)
create mode 100644 drivers/rtc/rtc-ssd20xd.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 753872408615..894151163ab8 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1978,4 +1978,15 @@ config RTC_DRV_POLARFIRE_SOC
This driver can also be built as a module, if so, the module
will be called "rtc-mpfs".
+config RTC_DRV_SSD20XD
+ tristate "SigmaStar SSD20XD RTC"
+ depends on ARCH_MSTARV7 || COMPILE_TEST
+ default ARCH_MSTARV7
+ help
+ If you say yes here you get support for the SigmaStar SSD20XD On-Chip
+ Real Time Clock.
+
+ This driver can also be built as a module, if so, the module
+ will be called "rtc-ssd20xd".
+
endif # RTC_CLASS
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index ea445d1ebb17..f14fff00a7aa 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -103,6 +103,7 @@ obj-$(CONFIG_RTC_DRV_MESON) += rtc-meson.o
obj-$(CONFIG_RTC_DRV_MOXART) += rtc-moxart.o
obj-$(CONFIG_RTC_DRV_MPC5121) += rtc-mpc5121.o
obj-$(CONFIG_RTC_DRV_MSC313) += rtc-msc313.o
+obj-$(CONFIG_RTC_DRV_SSD20XD) += rtc-ssd20xd.o
obj-$(CONFIG_RTC_DRV_MSM6242) += rtc-msm6242.o
obj-$(CONFIG_RTC_DRV_MT2712) += rtc-mt2712.o
obj-$(CONFIG_RTC_DRV_MT6397) += rtc-mt6397.o
diff --git a/drivers/rtc/rtc-ssd20xd.c b/drivers/rtc/rtc-ssd20xd.c
new file mode 100644
index 000000000000..4dfa37109d88
--- /dev/null
+++ b/drivers/rtc/rtc-ssd20xd.c
@@ -0,0 +1,249 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Real time clocks driver for MStar/SigmaStar SSD20xD SoCs.
+ *
+ * (C) 2021 Daniel Palmer
+ * (C) 2023 Romain Perier
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/module.h>
+#include <linux/mod_devicetable.h>
+#include <linux/platform_device.h>
+#include <linux/rtc.h>
+#include <linux/regmap.h>
+#include <linux/pm.h>
+
+#define REG_CTRL 0x0
+#define REG_CTRL1 0x4
+#define REG_ISO_CTRL 0xc
+#define REG_WRDATA_L 0x10
+#define REG_WRDATA_H 0x14
+#define REG_ISOACK 0x20
+#define REG_RDDATA_L 0x24
+#define REG_RDDATA_H 0x28
+#define REG_RDCNT_L 0x30
+#define REG_RDCNT_H 0x34
+#define REG_CNT_TRIG 0x38
+#define REG_PWRCTRL 0x3c
+#define REG_RTC_TEST 0x54
+
+#define CNT_RD_TRIG_BIT BIT(0)
+#define CNT_RD_BIT BIT(0)
+#define BASE_WR_BIT BIT(1)
+#define BASE_RD_BIT BIT(2)
+#define CNT_RST_BIT BIT(3)
+#define ISO_CTRL_ACK_MASK BIT(3)
+#define ISO_CTRL_ACK_SHIFT 3
+#define SW0_WR_BIT BIT(5)
+#define SW1_WR_BIT BIT(6)
+#define SW0_RD_BIT BIT(7)
+#define SW1_RD_BIT BIT(8)
+
+#define ISO_CTRL_MASK GENMASK(2, 0)
+
+struct ssd20xd_rtc {
+ struct rtc_device *rtc_dev;
+ void __iomem *base;
+};
+
+static u8 read_iso_en(void __iomem *base)
+{
+ return readb(base + REG_RTC_TEST) & 0x1;
+}
+
+static u8 read_iso_ctrl_ack(void __iomem *base)
+{
+ return (readb(base + REG_ISOACK) & ISO_CTRL_ACK_MASK) >> ISO_CTRL_ACK_SHIFT;
+}
+
+static int ssd20xd_rtc_isoctrl(struct ssd20xd_rtc *priv)
+{
+ static const unsigned int sequence[] = { 0x0, 0x1, 0x3, 0x7, 0x5, 0x1, 0x0 };
+ unsigned int val;
+ struct device *dev = &priv->rtc_dev->dev;
+ int i, ret;
+
+ /*
+ * This gates iso_en by writing a special sequence of bytes to iso_ctrl
+ * and ensuring that it has been correctly applied by reading iso_ctrl_ack
+ */
+ for (i = 0; i < ARRAY_SIZE(sequence); i++) {
+ writeb(sequence[i] & ISO_CTRL_MASK, priv->base + REG_ISO_CTRL);
+
+ ret = read_poll_timeout(read_iso_ctrl_ack, val, val == (i % 2), 100,
+ 20 * 100, true, priv->base);
+ if (ret) {
+ dev_err(dev, "Timeout waiting for ack byte %i (%x) of sequence\n", i,
+ sequence[i]);
+ return ret;
+ }
+ }
+
+ /*
+ * At this point iso_en should be raised for 1ms
+ */
+ ret = read_poll_timeout(read_iso_en, val, val, 100, 22 * 100, true, priv->base);
+ if (ret)
+ dev_err(dev, "Timeout waiting for iso_en\n");
+ mdelay(2);
+ return 0;
+}
+
+static void ssd20xd_rtc_read_reg(struct ssd20xd_rtc *priv, unsigned int reg,
+ unsigned int field, unsigned int *base)
+{
+ unsigned int l, h;
+ u16 val;
+
+ /* Ask for the content of an RTC value into RDDATA by gating iso_en,
+ * then iso_en is gated and the content of RDDATA can be read
+ */
+ val = readw(priv->base + reg);
+ writew(val | field, priv->base + reg);
+ ssd20xd_rtc_isoctrl(priv);
+ writew(val & ~field, priv->base + reg);
+
+ l = readw(priv->base + REG_RDDATA_L);
+ h = readw(priv->base + REG_RDDATA_H);
+
+ *base = (h << 16) | l;
+}
+
+static void ssd20xd_rtc_write_reg(struct ssd20xd_rtc *priv, unsigned int reg,
+ unsigned int field, u32 base)
+{
+ u16 val;
+
+ /* Set the content of an RTC value from WRDATA by gating iso_en */
+ val = readw(priv->base + reg);
+ writew(val | field, priv->base + reg);
+ writew(base, priv->base + REG_WRDATA_L);
+ writew(base >> 16, priv->base + REG_WRDATA_H);
+ ssd20xd_rtc_isoctrl(priv);
+ writew(val & ~field, priv->base + reg);
+}
+
+static int ssd20xd_rtc_read_counter(struct ssd20xd_rtc *priv, unsigned int *counter)
+{
+ unsigned int l, h;
+ u16 val;
+
+ val = readw(priv->base + REG_CTRL1);
+ writew(val | CNT_RD_BIT, priv->base + REG_CTRL1);
+ ssd20xd_rtc_isoctrl(priv);
+ writew(val & ~CNT_RD_BIT, priv->base + REG_CTRL1);
+
+ val = readw(priv->base + REG_CTRL1);
+ writew(val | CNT_RD_TRIG_BIT, priv->base + REG_CNT_TRIG);
+ writew(val & ~CNT_RD_TRIG_BIT, priv->base + REG_CNT_TRIG);
+
+ l = readw(priv->base + REG_RDCNT_L);
+ h = readw(priv->base + REG_RDCNT_H);
+
+ *counter = (h << 16) | l;
+
+ return 0;
+}
+
+static int ssd20xd_rtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+ struct ssd20xd_rtc *priv = dev_get_drvdata(dev);
+ unsigned int sw0, base, counter;
+ u32 seconds;
+ int ret;
+
+ /* Check that RTC is enabled by SW */
+ ssd20xd_rtc_read_reg(priv, REG_CTRL, SW0_RD_BIT, &sw0);
+ if (sw0 != 1)
+ return -EINVAL;
+
+ /* Get RTC base value from RDDATA */
+ ssd20xd_rtc_read_reg(priv, REG_CTRL, BASE_RD_BIT, &base);
+ /* Get RTC counter value from RDDATA */
+ ret = ssd20xd_rtc_read_counter(priv, &counter);
+ if (ret)
+ return ret;
+
+ seconds = base + counter;
+
+ rtc_time64_to_tm(seconds, tm);
+
+ return 0;
+}
+
+static int ssd20xd_rtc_reset_counter(struct ssd20xd_rtc *priv)
+{
+ u16 val;
+
+ val = readw(priv->base + REG_CTRL);
+ writew(val | CNT_RST_BIT, priv->base + REG_CTRL);
+ ssd20xd_rtc_isoctrl(priv);
+ writew(val & ~CNT_RST_BIT, priv->base + REG_CTRL);
+ ssd20xd_rtc_isoctrl(priv);
+
+ return 0;
+}
+
+static int ssd20xd_rtc_set_time(struct device *dev, struct rtc_time *tm)
+{
+ struct ssd20xd_rtc *priv = dev_get_drvdata(dev);
+ unsigned long seconds = rtc_tm_to_time64(tm);
+
+ ssd20xd_rtc_write_reg(priv, REG_CTRL, BASE_WR_BIT, seconds);
+ ssd20xd_rtc_reset_counter(priv);
+ ssd20xd_rtc_write_reg(priv, REG_CTRL, SW0_WR_BIT, 1);
+
+ return 0;
+}
+
+static const struct rtc_class_ops ssd20xd_rtc_ops = {
+ .read_time = ssd20xd_rtc_read_time,
+ .set_time = ssd20xd_rtc_set_time,
+};
+
+static int ssd20xd_rtc_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct ssd20xd_rtc *priv;
+
+ priv = devm_kzalloc(&pdev->dev, sizeof(struct ssd20xd_rtc), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(priv->base))
+ return PTR_ERR(priv->base);
+
+ priv->rtc_dev = devm_rtc_allocate_device(dev);
+ if (IS_ERR(priv->rtc_dev))
+ return PTR_ERR(priv->rtc_dev);
+
+ priv->rtc_dev->ops = &ssd20xd_rtc_ops;
+ priv->rtc_dev->range_max = U32_MAX;
+
+ platform_set_drvdata(pdev, priv);
+
+ return devm_rtc_register_device(priv->rtc_dev);
+}
+
+static const struct of_device_id ssd20xd_rtc_of_match_table[] = {
+ { .compatible = "mstar,ssd20xd-rtc" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, ssd20xd_rtc_of_match_table);
+
+static struct platform_driver ssd20xd_rtc_driver = {
+ .probe = ssd20xd_rtc_probe,
+ .driver = {
+ .name = "ssd20xd-rtc",
+ .of_match_table = ssd20xd_rtc_of_match_table,
+ },
+};
+module_platform_driver(ssd20xd_rtc_driver);
+
+MODULE_AUTHOR("Daniel Palmer <[email protected]>");
+MODULE_AUTHOR("Romain Perier <[email protected]>");
+MODULE_DESCRIPTION("MStar SSD20xD RTC Driver");
+MODULE_LICENSE("GPL v2");
--
2.39.2
This adds the definition of the rtc device node. It enables RTC block
for SSD20xD SoCs and newer.
---
arch/arm/boot/dts/mstar-infinity2m.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/mstar-infinity2m.dtsi b/arch/arm/boot/dts/mstar-infinity2m.dtsi
index 1b485efd7156..75f9173ca703 100644
--- a/arch/arm/boot/dts/mstar-infinity2m.dtsi
+++ b/arch/arm/boot/dts/mstar-infinity2m.dtsi
@@ -32,6 +32,11 @@ cpu1: cpu@1 {
};
&riu {
+ rtc@6800 {
+ compatible = "mstar,ssd20xd-rtc";
+ reg = <0x6800 0x200>;
+ };
+
smpctrl: smpctrl@204000 {
reg = <0x204000 0x200>;
status = "disabled";
--
2.39.2
Hey Romain,
On Wed, May 17, 2023 at 04:41:43PM +0200, Romain Perier wrote:
> This adds the documentation for the devicetree bindings of the Mstar
> SSD20xD RTC driver.
Bindings describe hardware, not the driver ;)
>
> Signed-off-by: Romain Perier <[email protected]>
> ---
> .../bindings/rtc/mstar,ssd20xd-rtc.yaml | 37 +++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rtc/mstar,ssd20xd-rtc.yaml
>
> diff --git a/Documentation/devicetree/bindings/rtc/mstar,ssd20xd-rtc.yaml b/Documentation/devicetree/bindings/rtc/mstar,ssd20xd-rtc.yaml
> new file mode 100644
> index 000000000000..2acd86cce69f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/mstar,ssd20xd-rtc.yaml
> @@ -0,0 +1,37 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/rtc/mstar,ssd20xd-rtc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Mstar SSD20xD RTC
> +
> +allOf:
> + - $ref: rtc.yaml#
> +
> +maintainers:
> + - Daniel Palmer <[email protected]>
> + - Romain Perier <[email protected]>
> +
> +properties:
> + compatible:
> + enum:
> + - mstar,ssd20xd-rtc
Is this x a wildcard?
In general, having a specific compatible is preferred, and if there are
other models that are compatible we can list several "fall back" to the
most specific one implemented in a driver.
Thanks,
Conor.
On 17/05/2023 16:41, Romain Perier wrote:
> This adds the documentation for the devicetree bindings of the Mstar
> SSD20xD RTC driver.
>
Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC. It might happen, that command when run on an older
kernel, gives you outdated entries. Therefore please be sure you base
your patches on recent Linux kernel.
A nit, subject: drop second/last, redundant "devicetree bindings
documentation". The "dt-bindings" prefix is already stating that these
are bindings. You actually repeated everything...
> Signed-off-by: Romain Perier <[email protected]>
> ---
> .../bindings/rtc/mstar,ssd20xd-rtc.yaml | 37 +++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rtc/mstar,ssd20xd-rtc.yaml
>
> diff --git a/Documentation/devicetree/bindings/rtc/mstar,ssd20xd-rtc.yaml b/Documentation/devicetree/bindings/rtc/mstar,ssd20xd-rtc.yaml
> new file mode 100644
> index 000000000000..2acd86cce69f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/mstar,ssd20xd-rtc.yaml
> @@ -0,0 +1,37 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/rtc/mstar,ssd20xd-rtc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Mstar SSD20xD RTC
> +
> +allOf:
> + - $ref: rtc.yaml#
This goes just above properties:
> +
> +maintainers:
> + - Daniel Palmer <[email protected]>
> + - Romain Perier <[email protected]>
> +
> +properties:
> + compatible:
> + enum:
> + - mstar,ssd20xd-rtc
Why rtc suffix? Can it be anything else?
Missing blank line
> + reg:
> + maxItems: 1
> +
> + start-year: true
Drop
What about interrupt line?
> +
> +required:
> + - compatible
> + - reg
> +
> +additionalProperties: false
instead
unevaluatedProperties: false
> +
> +examples:
> + - |
> + rtc@6800 {
> + compatible = "mstar,ssd20xd-rtc";
> + reg = <0x6800 0x200>;
> + };
> +...
Best regards,
Krzysztof
Le mer. 17 mai 2023 à 19:44, Conor Dooley <[email protected]> a écrit :
>
> Hey Romain,
>
> On Wed, May 17, 2023 at 04:41:43PM +0200, Romain Perier wrote:
> > This adds the documentation for the devicetree bindings of the Mstar
> > SSD20xD RTC driver.
>
> Bindings describe hardware, not the driver ;)
Hi,
Yep, I just copied and pasted the message of a previous merged-commit,
I will fix it.
>
> >
> > Signed-off-by: Romain Perier <[email protected]>
> > ---
> > .../bindings/rtc/mstar,ssd20xd-rtc.yaml | 37 +++++++++++++++++++
> > 1 file changed, 37 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/rtc/mstar,ssd20xd-rtc.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/rtc/mstar,ssd20xd-rtc.yaml b/Documentation/devicetree/bindings/rtc/mstar,ssd20xd-rtc.yaml
> > new file mode 100644
> > index 000000000000..2acd86cce69f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/rtc/mstar,ssd20xd-rtc.yaml
> > @@ -0,0 +1,37 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/rtc/mstar,ssd20xd-rtc.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Mstar SSD20xD RTC
> > +
> > +allOf:
> > + - $ref: rtc.yaml#
> > +
> > +maintainers:
> > + - Daniel Palmer <[email protected]>
> > + - Romain Perier <[email protected]>
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - mstar,ssd20xd-rtc
>
> Is this x a wildcard?
> In general, having a specific compatible is preferred, and if there are
> other models that are compatible we can list several "fall back" to the
> most specific one implemented in a driver.
The first SoC being concerned is SSD202D, so "mstar,ssd202d-rtc" ?
Thanks,
Romain
On Mon, May 22, 2023 at 08:47:08AM +0200, Romain Perier wrote:
> Le mer. 17 mai 2023 ? 19:44, Conor Dooley <[email protected]> a ?crit :
> > > +properties:
> > > + compatible:
> > > + enum:
> > > + - mstar,ssd20xd-rtc
> >
> > Is this x a wildcard?
> > In general, having a specific compatible is preferred, and if there are
> > other models that are compatible we can list several "fall back" to the
> > most specific one implemented in a driver.
>
>
> The first SoC being concerned is SSD202D, so "mstar,ssd202d-rtc" ?
Sounds good to me, thanks.
Le jeu. 18 mai 2023 à 10:24, Krzysztof Kozlowski <[email protected]> a écrit :
>
> On 17/05/2023 16:41, Romain Perier wrote:
> > This adds the documentation for the devicetree bindings of the Mstar
> > SSD20xD RTC driver.
> >
>
> Please use scripts/get_maintainers.pl to get a list of necessary people
> and lists to CC. It might happen, that command when run on an older
> kernel, gives you outdated entries. Therefore please be sure you base
> your patches on recent Linux kernel.
Hi,
This is usually what I do for all patches series, but possible I have
missed some person
>
> A nit, subject: drop second/last, redundant "devicetree bindings
> documentation". The "dt-bindings" prefix is already stating that these
> are bindings. You actually repeated everything...
Originally, it was just to write a simple sentence with words... it
gives context, you know...
Like here: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=7647204c2e81b28b4a7c4eec7d539f998d48eaf0
or here: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=dd49cbedde8a0f1e0d09698f9cad791d37a8e03e
But honestly, I don't want to debate about this, yes I can remove
redundant "devicetree bindings documentation" ^^
>
> > Signed-off-by: Romain Perier <[email protected]>
> > ---
> > .../bindings/rtc/mstar,ssd20xd-rtc.yaml | 37 +++++++++++++++++++
> > 1 file changed, 37 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/rtc/mstar,ssd20xd-rtc.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/rtc/mstar,ssd20xd-rtc.yaml b/Documentation/devicetree/bindings/rtc/mstar,ssd20xd-rtc.yaml
> > new file mode 100644
> > index 000000000000..2acd86cce69f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/rtc/mstar,ssd20xd-rtc.yaml
> > @@ -0,0 +1,37 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/rtc/mstar,ssd20xd-rtc.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Mstar SSD20xD RTC
> > +
> > +allOf:
> > + - $ref: rtc.yaml#
>
> This goes just above properties:
>
ack
> > +
> > +maintainers:
> > + - Daniel Palmer <[email protected]>
> > + - Romain Perier <[email protected]>
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - mstar,ssd20xd-rtc
>
> Why rtc suffix? Can it be anything else?
Well, it is the dt-bindings for an RTC block ? suppose tomorrow we
have an ethernet block specific to the SoC SSD202D, it should be
"mstar,ssd202d-ethernet" , how do you make
the difference if you just put "mstar,sd202d" ? Plus a lot of rtc
dt-bindings have this suffix (when it is not an IP name). This is
exactly the case for rtc-msc313e and it was not an issue.
>
> Missing blank line
ack
>
> > + reg:
> > + maxItems: 1
> > +
> > + start-year: true
>
> Drop
>
> What about interrupt line?
There is currently no interrupt right now, we have not yet the irqchip
code for handling the alarm irq of this rtc block.
>
> > +
> > +required:
> > + - compatible
> > + - reg
> > +
> > +additionalProperties: false
>
> instead
> unevaluatedProperties: false
ack
Thanks,
Romain
Hello,
On 17/05/2023 16:41:42+0200, Romain Perier wrote:
> Newer SigmaStar SSD20xD SoCs contain a really low power RTC (300uA claimed),
The low power RTCs are more on the side of a few tenth of nA. RV3028
consumes 40nA, including the crystal. AB1805 consumes 14nA with an RC
oscillator. It is funny how SoC vendors think they are low power ;)
> +static int ssd20xd_rtc_isoctrl(struct ssd20xd_rtc *priv)
> +{
> + static const unsigned int sequence[] = { 0x0, 0x1, 0x3, 0x7, 0x5, 0x1, 0x0 };
> + unsigned int val;
> + struct device *dev = &priv->rtc_dev->dev;
> + int i, ret;
> +
> + /*
> + * This gates iso_en by writing a special sequence of bytes to iso_ctrl
> + * and ensuring that it has been correctly applied by reading iso_ctrl_ack
> + */
> + for (i = 0; i < ARRAY_SIZE(sequence); i++) {
> + writeb(sequence[i] & ISO_CTRL_MASK, priv->base + REG_ISO_CTRL);
> +
> + ret = read_poll_timeout(read_iso_ctrl_ack, val, val == (i % 2), 100,
> + 20 * 100, true, priv->base);
> + if (ret) {
> + dev_err(dev, "Timeout waiting for ack byte %i (%x) of sequence\n", i,
> + sequence[i]);
This is a user visible message but there is no action for the user to
take apart from retrying. You should drop this.
> + return ret;
> + }
> + }
> +
> + /*
> + * At this point iso_en should be raised for 1ms
> + */
> + ret = read_poll_timeout(read_iso_en, val, val, 100, 22 * 100, true, priv->base);
> + if (ret)
> + dev_err(dev, "Timeout waiting for iso_en\n");
Ditto.
> + mdelay(2);
> + return 0;
> +}
> +
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Hi Alexandre,
On Tue, 30 May 2023 at 07:40, Alexandre Belloni
<[email protected]> wrote:
>
> Hello,
>
> On 17/05/2023 16:41:42+0200, Romain Perier wrote:
> > Newer SigmaStar SSD20xD SoCs contain a really low power RTC (300uA claimed),
>
> The low power RTCs are more on the side of a few tenth of nA. RV3028
> consumes 40nA, including the crystal. AB1805 consumes 14nA with an RC
> oscillator. It is funny how SoC vendors think they are low power ;)
To be fair to them I think the 300uA claim is for the whole SoC in
RTC-only deep sleep.
Whatever logic is powered on alongside the RTC to trigger wake up will
be part of that number I guess.
Cheers,
Daniel
On 22/05/2023 13:27, Romain Perier wrote:
>>> +properties:
>>> + compatible:
>>> + enum:
>>> + - mstar,ssd20xd-rtc
>>
>> Why rtc suffix? Can it be anything else?
>
> Well, it is the dt-bindings for an RTC block ? suppose tomorrow we
> have an ethernet block specific to the SoC SSD202D, it should be
> "mstar,ssd202d-ethernet" , how do you make
> the difference if you just put "mstar,sd202d" ? Plus a lot of rtc
> dt-bindings have this suffix (when it is not an IP name).
There are a lot of bad design choices or bugs - are you going to
implement the same mistakes because someone did it?
> This is
> exactly the case for rtc-msc313e and it was not an issue.
So that was my question - can it be anything else? There is literally no
description of the hardware... Neither in commit msg nor in description:
field in bindings.
What is SSD202D? SoC? RTC?
>
>>
>> Missing blank line
>
> ack
>
>>
>>> + reg:
>>> + maxItems: 1
>>> +
>>> + start-year: true
>>
>> Drop
>>
>> What about interrupt line?
>
> There is currently no interrupt right now, we have not yet the irqchip
> code for handling the alarm irq of this rtc block.
So you are going to change the hardware and add the interrupt line? We
do not talk about drivers, but hardware. Whether your driver handles it
or not, matters less.
Describe the hardware, not the current implementation of one driver.
Best regards,
Krzysztof
Hi Krzysztof,
On Tue, 30 May 2023 at 17:01, Krzysztof Kozlowski <[email protected]> wrote:
> > This is
> > exactly the case for rtc-msc313e and it was not an issue.
>
> So that was my question - can it be anything else? There is literally no
> description of the hardware... Neither in commit msg nor in description:
> field in bindings.
This RTC block is a block inside of the SSD201/SSD202D (they are the
same die with different memory attached) and is only found there.
The documentation we have for this is literally one page in a PDF that
says "RTC registers".
It could be an IP block licensed from somewhere and technically have a
better name but right now all we know is this RTC block is the one in
that chip and that chip is the first known instance of it.
Say we manage to get the ethernet mainlined at some point: That's a
lot easier as we know already it's a hacked up version of the cadence
macb so the compatible can be "macb something".
> >> What about interrupt line?
> >
> > There is currently no interrupt right now, we have not yet the irqchip
> > code for handling the alarm irq of this rtc block.
>
> So you are going to change the hardware and add the interrupt line? We
> do not talk about drivers, but hardware. Whether your driver handles it
> or not, matters less.
>
> Describe the hardware, not the current implementation of one driver.
We don't really know how the interrupt is wired up in the hardware properly yet.
Cheers,
Daniel
On 31/05/2023 01:12, Daniel Palmer wrote:
> Hi Krzysztof,
>
> On Tue, 30 May 2023 at 17:01, Krzysztof Kozlowski <[email protected]> wrote:
>>> This is
>>> exactly the case for rtc-msc313e and it was not an issue.
>>
>> So that was my question - can it be anything else? There is literally no
>> description of the hardware... Neither in commit msg nor in description:
>> field in bindings.
>
> This RTC block is a block inside of the SSD201/SSD202D (they are the
But what is SSD201?
> same die with different memory attached) and is only found there.
> The documentation we have for this is literally one page in a PDF that
> says "RTC registers".
> It could be an IP block licensed from somewhere and technically have a
> better name but right now all we know is this RTC block is the one in
> that chip and that chip is the first known instance of it.
>
> Say we manage to get the ethernet mainlined at some point: That's a
> lot easier as we know already it's a hacked up version of the cadence
> macb so the compatible can be "macb something".
>
>>>> What about interrupt line?
>>>
>>> There is currently no interrupt right now, we have not yet the irqchip
>>> code for handling the alarm irq of this rtc block.
>>
>> So you are going to change the hardware and add the interrupt line? We
>> do not talk about drivers, but hardware. Whether your driver handles it
>> or not, matters less.
>>
>> Describe the hardware, not the current implementation of one driver.
>
> We don't really know how the interrupt is wired up in the hardware properly yet.
OK
Best regards,
Krzysztof
Hi Krzysztof,
On Wed, 31 May 2023 at 15:49, Krzysztof Kozlowski <[email protected]> wrote:
> > This RTC block is a block inside of the SSD201/SSD202D (they are the
>
> But what is SSD201?
Dual Cortex A7 SoC with integrated memory (SSD201 == 64MB, SSD202D ==
128MB) that happens to have an RTC.
Cheers,
Daniel