this patch add's the RTC found on Gemini SoC.
changes
v2
- usage of readl/write
- spacing around *
- line wrapping aligned to open parenthesis
- add driver file to MAINTAINERS
Ulli
From: Hans Ulli Kroll <[email protected]>
Subject: [PATCHv2] RTC:driver for Cortina's SOC
In-Reply-To:
Driver for the on chip RTC found on Cortina's SoC Gemini.
Signed-off-by: Hans Ulli Kroll <[email protected]>
---
MAINTAINERS | 1 +
drivers/rtc/Kconfig | 9 +++
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-gemini.c | 191 +++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 202 insertions(+)
create mode 100644 drivers/rtc/rtc-gemini.c
diff --git a/MAINTAINERS b/MAINTAINERS
index c2781eb..2e91f68 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -978,6 +978,7 @@ L: [email protected] (moderated for non-subscribers)
T: git git://github.com/ulli-kroll/linux.git
S: Maintained
F: arch/arm/mach-gemini/
+F: drivers/rtc/rtc-gemini.c
ARM/CSR SIRFPRIMA2 MACHINE SUPPORT
M: Barry Song <[email protected]>
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 6149ae0..c6ea9aa 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1362,6 +1362,15 @@ config RTC_DRV_ARMADA38X
This driver can also be built as a module. If so, the module
will be called armada38x-rtc.
+config RTC_DRV_GEMINI
+ tristate "Gemini SoC RTC"
+ help
+ If you say Y here you will get support for the
+ RTC found on Gemini SoC's.
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-gemini.
+
config RTC_DRV_PS3
tristate "PS3 RTC"
depends on PPC_PS3
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index c31731c..0fd6e22 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -64,6 +64,7 @@ obj-$(CONFIG_RTC_DRV_EFI) += rtc-efi.o
obj-$(CONFIG_RTC_DRV_EM3027) += rtc-em3027.o
obj-$(CONFIG_RTC_DRV_EP93XX) += rtc-ep93xx.o
obj-$(CONFIG_RTC_DRV_FM3130) += rtc-fm3130.o
+obj-$(CONFIG_RTC_DRV_GEMINI) += rtc-gemini.o
obj-$(CONFIG_RTC_DRV_GENERIC) += rtc-generic.o
obj-$(CONFIG_RTC_DRV_HID_SENSOR_TIME) += rtc-hid-sensor-time.o
obj-$(CONFIG_RTC_DRV_HYM8563) += rtc-hym8563.o
diff --git a/drivers/rtc/rtc-gemini.c b/drivers/rtc/rtc-gemini.c
new file mode 100644
index 0000000..ca94bd5
--- /dev/null
+++ b/drivers/rtc/rtc-gemini.c
@@ -0,0 +1,191 @@
+/*
+ * Gemini OnChip RTC
+ *
+ * Copyright (C) 2009 Janos Laube <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Original code for older kernel 2.6.15 are form Stormlinksemi
+ * first update from Janos Laube for > 2.6.29 kernels
+ *
+ * checkpatch fixes and usage off rtc-lib code
+ * Hans Ulli Kroll <[email protected]>
+ */
+
+#include <linux/rtc.h>
+#include <linux/io.h>
+#include <linux/slab.h>
+#include <linux/platform_device.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <mach/hardware.h>
+
+#define DRV_NAME "rtc-gemini"
+#define DRV_VERSION "0.2"
+
+MODULE_AUTHOR("Hans Ulli Kroll <[email protected]>");
+MODULE_DESCRIPTION("RTC driver for Gemini SoC");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:" DRV_NAME);
+
+struct gemini_rtc {
+ struct rtc_device *rtc_dev;
+ void __iomem *rtc_base;
+ int rtc_irq;
+};
+
+enum gemini_rtc_offsets {
+ GEMINI_RTC_SECOND = 0x00,
+ GEMINI_RTC_MINUTE = 0x04,
+ GEMINI_RTC_HOUR = 0x08,
+ GEMINI_RTC_DAYS = 0x0C,
+ GEMINI_RTC_ALARM_SECOND = 0x10,
+ GEMINI_RTC_ALARM_MINUTE = 0x14,
+ GEMINI_RTC_ALARM_HOUR = 0x18,
+ GEMINI_RTC_RECORD = 0x1C,
+ GEMINI_RTC_CR = 0x20
+};
+
+static irqreturn_t gemini_rtc_interrupt(int irq, void *dev)
+{
+ return IRQ_HANDLED;
+}
+
+/*
+ * Looks like the RTC in the Gemini SoC is (totaly) broken
+ * We can't read/write directly the time from RTC registers.
+ * We must do some "offset" calculation to get the real time
+ *
+ * This FIX works pretty fine and Stormlinksemi aka Cortina-Networks does
+ * the same thing, without the rtc-lib.c calls.
+ */
+
+static int gemini_rtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+ struct gemini_rtc *rtc = dev_get_drvdata(dev);
+
+ unsigned int days, hour, min, sec;
+ unsigned long offset, time;
+
+ sec = readl(rtc->rtc_base + GEMINI_RTC_SECOND);
+ min = readl(rtc->rtc_base + GEMINI_RTC_MINUTE);
+ hour = readl(rtc->rtc_base + GEMINI_RTC_HOUR);
+ days = readl(rtc->rtc_base + GEMINI_RTC_DAYS);
+ offset = readl(rtc->rtc_base + GEMINI_RTC_RECORD);
+
+ time = offset + days * 86400 + hour * 3600 + min * 60 + sec;
+
+ rtc_time_to_tm(time, tm);
+
+ return 0;
+}
+
+static int gemini_rtc_set_time(struct device *dev, struct rtc_time *tm)
+{
+ struct gemini_rtc *rtc = dev_get_drvdata(dev);
+ unsigned int sec, min, hour, day;
+ unsigned long offset, time;
+
+ if (tm->tm_year >= 2148) /* EPOCH Year + 179 */
+ return -EINVAL;
+
+ rtc_tm_to_time(tm, &time);
+
+ sec = readl(rtc->rtc_base + GEMINI_RTC_SECOND);
+ min = readl(rtc->rtc_base + GEMINI_RTC_MINUTE);
+ hour = readl(rtc->rtc_base + GEMINI_RTC_HOUR);
+ day = readl(rtc->rtc_base + GEMINI_RTC_DAYS);
+
+ offset = time - (day*86400 + hour*3600 + min*60 + sec);
+
+ writel(offset, rtc->rtc_base + GEMINI_RTC_RECORD);
+ writel(0x01, rtc->rtc_base + GEMINI_RTC_CR);
+
+ return 0;
+}
+
+static struct rtc_class_ops gemini_rtc_ops = {
+ .read_time = gemini_rtc_read_time,
+ .set_time = gemini_rtc_set_time,
+};
+
+static int gemini_rtc_probe(struct platform_device *pdev)
+{
+ struct gemini_rtc *rtc;
+ struct device *dev = &pdev->dev;
+ struct resource *res;
+ int ret;
+
+ rtc = kzalloc(sizeof(*rtc), GFP_KERNEL);
+ if (unlikely(!rtc))
+ return -ENOMEM;
+ platform_set_drvdata(pdev, rtc);
+
+ res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (!res) {
+ ret = -ENODEV;
+ goto err_mem;
+ }
+ rtc->rtc_irq = res->start;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ ret = -ENODEV;
+ goto err_mem;
+ }
+ rtc->rtc_base = devm_ioremap(&pdev->dev, res->start,
+ res->end - res->start + 1);
+
+ ret = request_irq(rtc->rtc_irq, gemini_rtc_interrupt,
+ IRQF_SHARED, pdev->name, dev);
+ if (unlikely(ret))
+ goto err_mem;
+
+ rtc->rtc_dev = rtc_device_register(pdev->name, dev,
+ &gemini_rtc_ops, THIS_MODULE);
+ if (unlikely(IS_ERR(rtc->rtc_dev))) {
+ ret = PTR_ERR(rtc->rtc_dev);
+ goto err_irq;
+ }
+ return 0;
+
+err_irq:
+ free_irq(rtc->rtc_irq, dev);
+
+err_mem:
+ kfree(rtc);
+ return ret;
+}
+
+static int gemini_rtc_remove(struct platform_device *pdev)
+{
+ struct gemini_rtc *rtc = platform_get_drvdata(pdev);
+ struct device *dev = &pdev->dev;
+
+ free_irq(rtc->rtc_irq, dev);
+ rtc_device_unregister(rtc->rtc_dev);
+ platform_set_drvdata(pdev, NULL);
+ kfree(rtc);
+
+ return 0;
+}
+
+static struct platform_driver gemini_rtc_driver = {
+ .driver = {
+ .name = DRV_NAME,
+ .owner = THIS_MODULE,
+ },
+ .probe = gemini_rtc_probe,
+ .remove = gemini_rtc_remove,
+};
+
+module_platform_driver_probe(gemini_rtc_driver, gemini_rtc_probe);
+
--
2.3.5
On Mon, 2015-05-11 at 18:25 +0200, Hans Ulli Kroll wrote:
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> +config RTC_DRV_GEMINI
> + tristate "Gemini SoC RTC"
> + help
> + If you say Y here you will get support for the
> + RTC found on Gemini SoC's.
> +
> + This driver can also be built as a module. If so, the module
> + will be called rtc-gemini.
This has, by the look of it, very little dependencies, probably just
RTC_CLASS. So I think that this symbol can be enabled in allyesconfig,
allmodconfig, and randconfig for most architectures. (I just tested this
- what a novel idea! - and it will indeed be set by allyesconfig and
allmodconfig on x86_64.)
> --- /dev/null
> +++ b/drivers/rtc/rtc-gemini.c
> +#include <mach/hardware.h>
Except for arm, builds using a .config containing
CONFIG_RTC_DRV_GEMINI=[my]
will fail here. (*/mach/hardware.h is mainly used for arm.) That is
bound to generate, well, fanmail for you. Perhaps it's better if
RTC_DRV_GEMINI depends on, say, ARCH_GEMINI.
Paul Bolle
Hi,
On 11/05/2015 at 18:25:36 +0200, Hans Ulli Kroll wrote :
> this patch add's the RTC found on Gemini SoC.
>
> changes
> v2
> - usage of readl/write
> - spacing around *
I don't see that one being fixed
> - line wrapping aligned to open parenthesis
There is still one near the request_irq.
> - add driver file to MAINTAINERS
>
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
On Tuesday 12 May 2015 11:05:34 Paul Bolle wrote:
> On Mon, 2015-05-11 at 18:25 +0200, Hans Ulli Kroll wrote:
> > --- a/drivers/rtc/Kconfig
> > +++ b/drivers/rtc/Kconfig
>
> > +config RTC_DRV_GEMINI
> > + tristate "Gemini SoC RTC"
> > + help
> > + If you say Y here you will get support for the
> > + RTC found on Gemini SoC's.
> > +
> > + This driver can also be built as a module. If so, the module
> > + will be called rtc-gemini.
>
> This has, by the look of it, very little dependencies, probably just
> RTC_CLASS. So I think that this symbol can be enabled in allyesconfig,
> allmodconfig, and randconfig for most architectures. (I just tested this
> - what a novel idea! - and it will indeed be set by allyesconfig and
> allmodconfig on x86_64.)
>
> > --- /dev/null
> > +++ b/drivers/rtc/rtc-gemini.c
>
> > +#include <mach/hardware.h>
>
> Except for arm, builds using a .config containing
> CONFIG_RTC_DRV_GEMINI=[my]
>
> will fail here. (*/mach/hardware.h is mainly used for arm.) That is
> bound to generate, well, fanmail for you. Perhaps it's better if
> RTC_DRV_GEMINI depends on, say, ARCH_GEMINI.
Well spotted, thanks for the report.
I have a patch that will turn mach-gemini into multiplatform, and
at that point it will also fail there. The correct solution I think
is to move the GEMINI_RTC_SECOND etc definitions into rtc-gemini.c
itself and remove the #include.
It still makes sense to have a dependency, but I'd express it
as
depends on ARCH_GEMINI || COMPILE_TEST
in order to let the driver get compiled for an allyesconfig kernel
on all architectures, but not appear as an option for normal builds
that do not set COMPILE_TEST.
Arnd
On Tue, 12 May 2015, Arnd Bergmann wrote:
> On Tuesday 12 May 2015 11:05:34 Paul Bolle wrote:
> > On Mon, 2015-05-11 at 18:25 +0200, Hans Ulli Kroll wrote:
> > > --- a/drivers/rtc/Kconfig
> > > +++ b/drivers/rtc/Kconfig
> >
> > > +config RTC_DRV_GEMINI
> > > + tristate "Gemini SoC RTC"
> > > + help
> > > + If you say Y here you will get support for the
> > > + RTC found on Gemini SoC's.
> > > +
> > > + This driver can also be built as a module. If so, the module
> > > + will be called rtc-gemini.
> >
> > This has, by the look of it, very little dependencies, probably just
> > RTC_CLASS. So I think that this symbol can be enabled in allyesconfig,
> > allmodconfig, and randconfig for most architectures. (I just tested this
> > - what a novel idea! - and it will indeed be set by allyesconfig and
> > allmodconfig on x86_64.)
> >
> > > --- /dev/null
> > > +++ b/drivers/rtc/rtc-gemini.c
> >
> > > +#include <mach/hardware.h>
> >
> > Except for arm, builds using a .config containing
> > CONFIG_RTC_DRV_GEMINI=[my]
> >
> > will fail here. (*/mach/hardware.h is mainly used for arm.) That is
> > bound to generate, well, fanmail for you. Perhaps it's better if
> > RTC_DRV_GEMINI depends on, say, ARCH_GEMINI.
>
> Well spotted, thanks for the report.
>
> I have a patch that will turn mach-gemini into multiplatform, and
> at that point it will also fail there. The correct solution I think
> is to move the GEMINI_RTC_SECOND etc definitions into rtc-gemini.c
> itself and remove the #include.
>
GEMINI_RTC_SECOND and other register offset are in the driver.
The only address I get from the #include is the base address of the RTC
> It still makes sense to have a dependency, but I'd express it
> as
>
> depends on ARCH_GEMINI || COMPILE_TEST
>
Is done in series three. Without COMPILE_TEST
Hmm I missied someone to send ...
Ulli
On Wednesday 13 May 2015 20:23:40 Hans Ulli Kroll wrote:
> > I have a patch that will turn mach-gemini into multiplatform, and
> > at that point it will also fail there. The correct solution I think
> > is to move the GEMINI_RTC_SECOND etc definitions into rtc-gemini.c
> > itself and remove the #include.
> >
>
> GEMINI_RTC_SECOND and other register offset are in the driver.
> The only address I get from the #include is the base address of the RTC
>
Ah, I see. Please pass a struct resource for this then when you call
platform_device_register_simple from the platform code, and
use platform_get_resource/devm_ioremap_resource to map it so you can
remove that inclusion.
Arnd
On Wednesday 13 May 2015 21:03:29 Arnd Bergmann wrote:
> From: Arnd Bergmann <[email protected]>
> To: Hans Ulli Kroll <[email protected]>
> CC: Paul Bolle <[email protected]>, Alexandre Belloni <[email protected]>, [email protected]
> Date: Today 21:03:29
> On Wednesday 13 May 2015 20:23:40 Hans Ulli Kroll wrote:
> > > I have a patch that will turn mach-gemini into multiplatform, and
> > > at that point it will also fail there. The correct solution I think
> > > is to move the GEMINI_RTC_SECOND etc definitions into rtc-gemini.c
> > > itself and remove the #include.
> > >
> >
> > GEMINI_RTC_SECOND and other register offset are in the driver.
> > The only address I get from the #include is the base address of the RTC
> >
>
> Ah, I see. Please pass a struct resource for this then when you call
> platform_device_register_simple from the platform code, and
> use platform_get_resource/devm_ioremap_resource to map it so you can
> remove that inclusion.
I just saw that you already do this, so the #include should not be needed at all.
Arnd