[PATCH/RFC 0/5] Generic RTC class driver

[PATCH/RFC 0/5] Generic RTC class driver

[Geert Uytterhoeven]

I've been looking into problems with auto-loading the RTC driver on PPC=
 (more
specifically on PS3):
  - The recent "rtc-ppc" RTC class driver is not autoloaded by udev bec=
ause
    it's an old style platform driver that contains its own platform de=
vice.
  - The alternative old "genrtc" driver is autoloaded on non-udev syste=
ms only
    because it contains the module alias char-major-10-135. However, it=
's not
    a new-style RTC class driver.

=46ortunately there already exists a generic RTC class driver: "rtc-par=
isc".
Despite it's name, it's platform-independent, as it's build on top of t=
he RTC
abstraction used by "genrtc".

This patch series
  - adds a missing module alias to rtc-parisc,
  - renames rtc-parisc to rtc-generic,
  - converts the architectures that currently have CONFIG_GEN_RTC enabl=
ed in
    their defconfig (m68k, parisc, powerpc) to rtc-generic,
  - removes the obsolete rtc-ppc driver,
  - removes the old genrtc driver.
 =20
Note that genrtc may be used on other archictectures as well: at least =
alpha
has the required infrastructure ([gs]et_rtc_time()). The Kconfig rules =
allow
genrtc to be enabled on several others (cris, h8300, mn10300, um, x86, =
xtensa).

=46urthermore genrtc and rtc-generic are not 100% userspace compatible:
  - /dev/rtc provided by genrtc uses a misc character device (10:135),
  - /dev/rtc provided by rtc-generic uses a dynamic character device.
 =20
So perhaps we don't want to kill gen-rtc yet?

Any comments are welcomed!

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village =C2=B7 Da Vincilaan 7-D1 =C2=B7 B-1935 Zaventem =C2=
=B7 Belgium

Phone:    +32 (0)2 700 8453
=46ax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 =C2=B7 RPR Brussels
=46ortis =C2=B7 BIC GEBABEBB =C2=B7 IBAN BE41293037680010
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH/RFC 1/5] rtc-parisc: Add missing module alias

[Geert Uytterhoeven]

Make udev autoload the driver

Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
 drivers/rtc/rtc-parisc.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/rtc/rtc-parisc.c b/drivers/rtc/rtc-parisc.c
index c6bfa6f..28fb7d3 100644
--- a/drivers/rtc/rtc-parisc.c
+++ b/drivers/rtc/rtc-parisc.c
@@ -110,3 +110,4 @@ module_exit(parisc_rtc_fini);
 MODULE_AUTHOR("Kyle McMartin <kyle@mcmartin.ca>");
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("HP PA-RISC RTC driver");
+MODULE_ALIAS("platform:rtc-parisc");
-- 
1.6.0.4

[PATCH/RFC 2/5] pa-risc: Rename rtc-parisc to rtc-generic

[Geert Uytterhoeven]

The rtc-parisc driver is not PA-RISC specific at all, as it uses the existing
generic RTC infrastructure ([gs]et_rtc_time()).
Rename the driver from rtc-parisc to rtc-generic, and make it depend on the new
Kconfig symbol ARCH_HAS_GENERIC_RTC.

Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
 arch/parisc/Kconfig       |    6 ++-
 arch/parisc/kernel/time.c |    6 +-
 drivers/rtc/Kconfig       |   10 ++--
 drivers/rtc/Makefile      |    2 +-
 drivers/rtc/rtc-generic.c |  113 +++++++++++++++++++++++++++++++++++++++++++++
 drivers/rtc/rtc-parisc.c  |  113 ---------------------------------------------
 6 files changed, 127 insertions(+), 123 deletions(-)
 create mode 100644 drivers/rtc/rtc-generic.c
 delete mode 100644 drivers/rtc/rtc-parisc.c

diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index aacf11d..cacb3a1 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -10,7 +10,7 @@ config PARISC
 	select HAVE_IDE
 	select HAVE_OPROFILE
 	select RTC_CLASS
-	select RTC_DRV_PARISC
+	select RTC_DRV_GENERIC
 	select INIT_ALL_POSSIBLE
 	help
 	  The PA-RISC microprocessor is designed by Hewlett-Packard and used
@@ -43,6 +43,10 @@ config ARCH_HAS_ILOG2_U64
 	bool
 	default n
 
+config ARCH_HAS_GENERIC_RTC
+	bool
+	default y
+
 config GENERIC_FIND_NEXT_BIT
 	bool
 	default y
diff --git a/arch/parisc/kernel/time.c b/arch/parisc/kernel/time.c
index 9d46c43..849f460 100644
--- a/arch/parisc/kernel/time.c
+++ b/arch/parisc/kernel/time.c
@@ -216,8 +216,8 @@ void __init start_cpu_itimer(void)
 	per_cpu(cpu_data, cpu).it_value = next_tick;
 }
 
-struct platform_device rtc_parisc_dev = {
-	.name = "rtc-parisc",
+static struct platform_device rtc_generic_dev = {
+	.name = "rtc-generic",
 	.id = -1,
 };
 
@@ -225,7 +225,7 @@ static int __init rtc_init(void)
 {
 	int ret;
 
-	ret = platform_device_register(&rtc_parisc_dev);
+	ret = platform_device_register(&rtc_generic_dev);
 	if (ret < 0)
 		printk(KERN_ERR "unable to register rtc device...\n");
 
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 81450fb..3e58182 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -677,12 +677,12 @@ config RTC_DRV_RS5C313
 	help
 	  If you say yes here you get support for the Ricoh RS5C313 RTC chips.
 
-config RTC_DRV_PARISC
-	tristate "PA-RISC firmware RTC support"
-	depends on PARISC
+config RTC_DRV_GENERIC
+	tristate "Generic RTC support"
+	depends on ARCH_HAS_GENERIC_RTC
 	help
-	  Say Y or M here to enable RTC support on PA-RISC systems using
-	  firmware calls. If you do not know what you are doing, you should
+	  Say Y or M here to enable RTC support on systems using the generic
+	  RTC abstraction. If you do not know what you are doing, you should
 	  just say Y.
 
 config RTC_DRV_PPC
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 0e697aa..9c18a01 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -55,7 +55,7 @@ obj-$(CONFIG_RTC_DRV_PCF8563)	+= rtc-pcf8563.o
 obj-$(CONFIG_RTC_DRV_PCF8583)	+= rtc-pcf8583.o
 obj-$(CONFIG_RTC_DRV_PL030)	+= rtc-pl030.o
 obj-$(CONFIG_RTC_DRV_PL031)	+= rtc-pl031.o
-obj-$(CONFIG_RTC_DRV_PARISC)	+= rtc-parisc.o
+obj-$(CONFIG_RTC_DRV_GENERIC)	+= rtc-generic.o
 obj-$(CONFIG_RTC_DRV_PPC)	+= rtc-ppc.o
 obj-$(CONFIG_RTC_DRV_PXA)	+= rtc-pxa.o
 obj-$(CONFIG_RTC_DRV_R9701)	+= rtc-r9701.o
diff --git a/drivers/rtc/rtc-generic.c b/drivers/rtc/rtc-generic.c
new file mode 100644
index 0000000..b744c7d
--- /dev/null
+++ b/drivers/rtc/rtc-generic.c
@@ -0,0 +1,113 @@
+/* rtc-generic: RTC driver using the generic RTC abstraction
+ *
+ * Copyright (C) 2008 Kyle McMartin <kyle@mcmartin.ca>
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/time.h>
+#include <linux/platform_device.h>
+
+#include <asm/rtc.h>
+
+/* as simple as can be, and no simpler. */
+struct generic_rtc {
+	struct rtc_device *rtc;
+	spinlock_t lock;
+};
+
+static int generic_get_time(struct device *dev, struct rtc_time *tm)
+{
+	struct generic_rtc *p = dev_get_drvdata(dev);
+	unsigned long flags, ret;
+
+	spin_lock_irqsave(&p->lock, flags);
+	ret = get_rtc_time(tm);
+	spin_unlock_irqrestore(&p->lock, flags);
+
+	if (ret & RTC_BATT_BAD)
+		return -EOPNOTSUPP;
+
+	return 0;
+}
+
+static int generic_set_time(struct device *dev, struct rtc_time *tm)
+{
+	struct generic_rtc *p = dev_get_drvdata(dev);
+	unsigned long flags;
+	int ret;
+
+	spin_lock_irqsave(&p->lock, flags);
+	ret = set_rtc_time(tm);
+	spin_unlock_irqrestore(&p->lock, flags);
+
+	if (ret < 0)
+		return -EOPNOTSUPP;
+
+	return 0;
+}
+
+static const struct rtc_class_ops generic_rtc_ops = {
+	.read_time = generic_get_time,
+	.set_time = generic_set_time,
+};
+
+static int __devinit generic_rtc_probe(struct platform_device *dev)
+{
+	struct generic_rtc *p;
+
+	p = kzalloc(sizeof (*p), GFP_KERNEL);
+	if (!p)
+		return -ENOMEM;
+
+	spin_lock_init(&p->lock);
+
+	p->rtc = rtc_device_register("rtc-generic", &dev->dev,
+				     &generic_rtc_ops, THIS_MODULE);
+	if (IS_ERR(p->rtc)) {
+		int err = PTR_ERR(p->rtc);
+		kfree(p);
+		return err;
+	}
+
+	platform_set_drvdata(dev, p);
+
+	return 0;
+}
+
+static int __devexit generic_rtc_remove(struct platform_device *dev)
+{
+	struct generic_rtc *p = platform_get_drvdata(dev);
+
+	rtc_device_unregister(p->rtc);
+	kfree(p);
+
+	return 0;
+}
+
+static struct platform_driver generic_rtc_driver = {
+	.driver = {
+		.name = "rtc-generic",
+		.owner = THIS_MODULE,
+	},
+	.probe = generic_rtc_probe,
+	.remove = __devexit_p(generic_rtc_remove),
+};
+
+static int __init generic_rtc_init(void)
+{
+	return platform_driver_register(&generic_rtc_driver);
+}
+
+static void __exit generic_rtc_fini(void)
+{
+	platform_driver_unregister(&generic_rtc_driver);
+}
+
+module_init(generic_rtc_init);
+module_exit(generic_rtc_fini);
+
+MODULE_AUTHOR("Kyle McMartin <kyle@mcmartin.ca>");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Generic RTC driver");
+MODULE_ALIAS("platform:rtc-generic");
diff --git a/drivers/rtc/rtc-parisc.c b/drivers/rtc/rtc-parisc.c
deleted file mode 100644
index 28fb7d3..0000000
--- a/drivers/rtc/rtc-parisc.c
+++ /dev/null
@@ -1,113 +0,0 @@
-/* rtc-parisc: RTC for HP PA-RISC firmware
- *
- * Copyright (C) 2008 Kyle McMartin <kyle@mcmartin.ca>
- */
-
-#include <linux/kernel.h>
-#include <linux/module.h>
-#include <linux/time.h>
-#include <linux/platform_device.h>
-
-#include <asm/rtc.h>
-
-/* as simple as can be, and no simpler. */
-struct parisc_rtc {
-	struct rtc_device *rtc;
-	spinlock_t lock;
-};
-
-static int parisc_get_time(struct device *dev, struct rtc_time *tm)
-{
-	struct parisc_rtc *p = dev_get_drvdata(dev);
-	unsigned long flags, ret;
-
-	spin_lock_irqsave(&p->lock, flags);
-	ret = get_rtc_time(tm);
-	spin_unlock_irqrestore(&p->lock, flags);
-
-	if (ret & RTC_BATT_BAD)
-		return -EOPNOTSUPP;
-
-	return 0;
-}
-
-static int parisc_set_time(struct device *dev, struct rtc_time *tm)
-{
-	struct parisc_rtc *p = dev_get_drvdata(dev);
-	unsigned long flags;
-	int ret;
-
-	spin_lock_irqsave(&p->lock, flags);
-	ret = set_rtc_time(tm);
-	spin_unlock_irqrestore(&p->lock, flags);
-
-	if (ret < 0)
-		return -EOPNOTSUPP;
-
-	return 0;
-}
-
-static const struct rtc_class_ops parisc_rtc_ops = {
-	.read_time = parisc_get_time,
-	.set_time = parisc_set_time,
-};
-
-static int __devinit parisc_rtc_probe(struct platform_device *dev)
-{
-	struct parisc_rtc *p;
-
-	p = kzalloc(sizeof (*p), GFP_KERNEL);
-	if (!p)
-		return -ENOMEM;
-
-	spin_lock_init(&p->lock);
-
-	p->rtc = rtc_device_register("rtc-parisc", &dev->dev, &parisc_rtc_ops,
-					THIS_MODULE);
-	if (IS_ERR(p->rtc)) {
-		int err = PTR_ERR(p->rtc);
-		kfree(p);
-		return err;
-	}
-
-	platform_set_drvdata(dev, p);
-
-	return 0;
-}
-
-static int __devexit parisc_rtc_remove(struct platform_device *dev)
-{
-	struct parisc_rtc *p = platform_get_drvdata(dev);
-
-	rtc_device_unregister(p->rtc);
-	kfree(p);
-
-	return 0;
-}
-
-static struct platform_driver parisc_rtc_driver = {
-	.driver = {
-		.name = "rtc-parisc",
-		.owner = THIS_MODULE,
-	},
-	.probe = parisc_rtc_probe,
-	.remove = __devexit_p(parisc_rtc_remove),
-};
-
-static int __init parisc_rtc_init(void)
-{
-	return platform_driver_register(&parisc_rtc_driver);
-}
-
-static void __exit parisc_rtc_fini(void)
-{
-	platform_driver_unregister(&parisc_rtc_driver);
-}
-
-module_init(parisc_rtc_init);
-module_exit(parisc_rtc_fini);
-
-MODULE_AUTHOR("Kyle McMartin <kyle@mcmartin.ca>");
-MODULE_LICENSE("GPL");
-MODULE_DESCRIPTION("HP PA-RISC RTC driver");
-MODULE_ALIAS("platform:rtc-parisc");
-- 
1.6.0.4

[PATCH/RFC 3/5] m68k: Enable rtc-generic

[Geert Uytterhoeven]

Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
 arch/m68k/Kconfig       |    4 ++++
 arch/m68k/kernel/time.c |   21 +++++++++++++++++++++
 2 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index fb87c08..9d2565e 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -27,6 +27,10 @@ config ARCH_HAS_ILOG2_U64
 	bool
 	default n
 
+config ARCH_HAS_GENERIC_RTC
+	bool
+	default y
+
 config GENERIC_HWEIGHT
 	bool
 	default y
diff --git a/arch/m68k/kernel/time.c b/arch/m68k/kernel/time.c
index 7db4159..b26933f 100644
--- a/arch/m68k/kernel/time.c
+++ b/arch/m68k/kernel/time.c
@@ -18,6 +18,7 @@
 #include <linux/string.h>
 #include <linux/mm.h>
 #include <linux/rtc.h>
+#include <linux/platform_device.h>
 
 #include <asm/machdep.h>
 #include <asm/io.h>
@@ -159,3 +160,23 @@ int do_settimeofday(struct timespec *tv)
 }
 
 EXPORT_SYMBOL(do_settimeofday);
+
+
+static struct platform_device rtc_generic_dev = {
+	.name = "rtc-generic",
+	.id = -1,
+};
+
+static int __init rtc_init(void)
+{
+	int ret;
+
+	ret = platform_device_register(&rtc_generic_dev);
+	if (ret < 0)
+		pr_err("Unable to register rtc device...\n");
+
+	/* not necessarily an error */
+	return 0;
+}
+
+module_init(rtc_init);
-- 
1.6.0.4

[PATCH/RFC 4/5] powerpc: Enable rtc-generic, and kill rtc-ppc

[Geert Uytterhoeven]

Create the "rtc-generic" platform device if ppc_md.get_rtc_time is set.
Kill rtc-ppc, as rtc-generic offers the same functionality in a more ge=
neric
way.

Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
 arch/powerpc/Kconfig       |    4 ++
 arch/powerpc/kernel/time.c |   22 ++++++++++++++
 drivers/rtc/Kconfig        |    8 -----
 drivers/rtc/Makefile       |    1 -
 drivers/rtc/rtc-ppc.c      |   69 ------------------------------------=
--------
 5 files changed, 26 insertions(+), 78 deletions(-)
 delete mode 100644 drivers/rtc/rtc-ppc.c

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 40b7981..82e47b0 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -85,6 +85,10 @@ config ARCH_HAS_ILOG2_U64
 	bool
 	default y if 64BIT
=20
+config ARCH_HAS_GENERIC_RTC
+	bool
+	default y
+
 config GENERIC_HWEIGHT
 	bool
 	default y
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index c956403..616c7d3 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -1127,3 +1127,25 @@ void div128_by_32(u64 dividend_high, u64 dividen=
d_low,
 	dr->result_low  =3D ((u64)y << 32) + z;
=20
 }
+
+static struct platform_device rtc_generic_dev =3D {
+	.name =3D "rtc-generic",
+	.id =3D -1,
+};
+
+static int __init rtc_init(void)
+{
+	int ret;
+
+	if (!ppc_md.get_rtc_time)
+		return -ENODEV;
+
+	ret =3D platform_device_register(&rtc_generic_dev);
+	if (ret < 0)
+		pr_err("Unable to register rtc device...\n");
+
+	/* not necessarily an error */
+	return 0;
+}
+
+module_init(rtc_init);
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 3e58182..9964a72 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -685,14 +685,6 @@ config RTC_DRV_GENERIC
 	  RTC abstraction. If you do not know what you are doing, you should
 	  just say Y.
=20
-config RTC_DRV_PPC
-       tristate "PowerPC machine dependent RTC support"
-       depends on PPC
-       help
-	 The PowerPC kernel has machine-specific functions for accessing
-	 the RTC. This exposes that functionality through the generic RTC
-	 class.
-
 config RTC_DRV_PXA
        tristate "PXA27x/PXA3xx"
        depends on ARCH_PXA
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 9c18a01..bd209a5 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -56,7 +56,6 @@ obj-$(CONFIG_RTC_DRV_PCF8583)	+=3D rtc-pcf8583.o
 obj-$(CONFIG_RTC_DRV_PL030)	+=3D rtc-pl030.o
 obj-$(CONFIG_RTC_DRV_PL031)	+=3D rtc-pl031.o
 obj-$(CONFIG_RTC_DRV_GENERIC)	+=3D rtc-generic.o
-obj-$(CONFIG_RTC_DRV_PPC)	+=3D rtc-ppc.o
 obj-$(CONFIG_RTC_DRV_PXA)	+=3D rtc-pxa.o
 obj-$(CONFIG_RTC_DRV_R9701)	+=3D rtc-r9701.o
 obj-$(CONFIG_RTC_DRV_RS5C313)	+=3D rtc-rs5c313.o
diff --git a/drivers/rtc/rtc-ppc.c b/drivers/rtc/rtc-ppc.c
deleted file mode 100644
index c8e97e2..0000000
--- a/drivers/rtc/rtc-ppc.c
+++ /dev/null
@@ -1,69 +0,0 @@
-/*
- * RTC driver for ppc_md RTC functions
- *
- * =C2=A9 2007 Red Hat, Inc.
- *
- * Author: David Woodhouse <dwmw2@infradead.org>
- *
- * This program is free software; you can redistribute it and/or modif=
y
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-
-#include <linux/module.h>
-#include <linux/err.h>
-#include <linux/rtc.h>
-#include <linux/platform_device.h>
-#include <asm/machdep.h>
-
-static int ppc_rtc_read_time(struct device *dev, struct rtc_time *tm)
-{
-	ppc_md.get_rtc_time(tm);
-	return 0;
-}
-
-static int ppc_rtc_set_time(struct device *dev, struct rtc_time *tm)
-{
-	return ppc_md.set_rtc_time(tm);
-}
-
-static const struct rtc_class_ops ppc_rtc_ops =3D {
-	.set_time =3D ppc_rtc_set_time,
-	.read_time =3D ppc_rtc_read_time,
-};
-
-static struct rtc_device *rtc;
-static struct platform_device *ppc_rtc_pdev;
-
-static int __init ppc_rtc_init(void)
-{
-	if (!ppc_md.get_rtc_time || !ppc_md.set_rtc_time)
-		return -ENODEV;
-
-	ppc_rtc_pdev =3D platform_device_register_simple("ppc-rtc", 0, NULL, =
0);
-	if (IS_ERR(ppc_rtc_pdev))
-		return PTR_ERR(ppc_rtc_pdev);
-
-	rtc =3D rtc_device_register("ppc_md", &ppc_rtc_pdev->dev,
-				  &ppc_rtc_ops, THIS_MODULE);
-	if (IS_ERR(rtc)) {
-		platform_device_unregister(ppc_rtc_pdev);
-		return PTR_ERR(rtc);
-	}
-
-	return 0;
-}
-
-static void __exit ppc_rtc_exit(void)
-{
-	rtc_device_unregister(rtc);
-	platform_device_unregister(ppc_rtc_pdev);
-}
-
-module_init(ppc_rtc_init);
-module_exit(ppc_rtc_exit);

[PATCH/RFC 5/5] rtc: Kill genrtc, as all its users have been converted to rtc-generic

[Geert Uytterhoeven]

Warning: genrtc and rtc-generic are not 100% userspace compatible:
  - /dev/rtc provided by genrtc uses a misc character device (10:135)
  - /dev/rtc provided by rtc-generic uses a dynamic character device

Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
 drivers/char/Kconfig  |   25 ---
 drivers/char/Makefile |    1 -
 drivers/char/genrtc.c |  527 -------------------------------------------------
 3 files changed, 0 insertions(+), 553 deletions(-)
 delete mode 100644 drivers/char/genrtc.c

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 735bbe2..c0960a1 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -840,31 +840,6 @@ config JS_RTC
 	  To compile this driver as a module, choose M here: the
 	  module will be called js-rtc.
 
-config GEN_RTC
-	tristate "Generic /dev/rtc emulation"
-	depends on RTC!=y && !IA64 && !ARM && !M32R && !MIPS && !SPARC && !FRV && !S390 && !SUPERH && !AVR32 && !BLACKFIN
-	---help---
-	  If you say Y here and create a character special file /dev/rtc with
-	  major number 10 and minor number 135 using mknod ("man mknod"), you
-	  will get access to the real time clock (or hardware clock) built
-	  into your computer.
-
-	  It reports status information via the file /proc/driver/rtc and its
-	  behaviour is set by various ioctls on /dev/rtc. If you enable the
-	  "extended RTC operation" below it will also provide an emulation
-	  for RTC_UIE which is required by some programs and may improve
-	  precision in some cases.
-
-	  To compile this driver as a module, choose M here: the
-	  module will be called genrtc.
-
-config GEN_RTC_X
-	bool "Extended RTC operation"
-	depends on GEN_RTC
-	help
-	  Provides an emulation for RTC_UIE which is required by some programs
-	  and may improve precision of the generic RTC support in some cases.
-
 config EFI_RTC
 	bool "EFI Real Time Clock Services"
 	depends on IA64
diff --git a/drivers/char/Makefile b/drivers/char/Makefile
index 565e473..c9432f0 100644
--- a/drivers/char/Makefile
+++ b/drivers/char/Makefile
@@ -75,7 +75,6 @@ obj-$(CONFIG_APPLICOM)		+= applicom.o
 obj-$(CONFIG_SONYPI)		+= sonypi.o
 obj-$(CONFIG_RTC)		+= rtc.o
 obj-$(CONFIG_HPET)		+= hpet.o
-obj-$(CONFIG_GEN_RTC)		+= genrtc.o
 obj-$(CONFIG_EFI_RTC)		+= efirtc.o
 obj-$(CONFIG_DS1302)		+= ds1302.o
 obj-$(CONFIG_XILINX_HWICAP)	+= xilinx_hwicap/
diff --git a/drivers/char/genrtc.c b/drivers/char/genrtc.c
deleted file mode 100644
index aac0985..0000000
--- a/drivers/char/genrtc.c
+++ /dev/null
@@ -1,527 +0,0 @@
-/*
- *	Real Time Clock interface for
- *		- q40 and other m68k machines,
- *		- HP PARISC machines
- *		- PowerPC machines
- *      emulate some RTC irq capabilities in software
- *
- *      Copyright (C) 1999 Richard Zidlicky
- *
- *	based on Paul Gortmaker's rtc.c device and
- *           Sam Creasey Generic rtc driver
- *
- *	This driver allows use of the real time clock (built into
- *	nearly all computers) from user space. It exports the /dev/rtc
- *	interface supporting various ioctl() and also the /proc/driver/rtc
- *	pseudo-file for status information.
- *
- *	The ioctls can be used to set the interrupt behaviour where
- *	supported.
- *
- *	The /dev/rtc interface will block on reads until an interrupt
- *	has been received. If a RTC interrupt has already happened,
- *	it will output an unsigned long and then block. The output value
- *	contains the interrupt status in the low byte and the number of
- *	interrupts since the last read in the remaining high bytes. The
- *	/dev/rtc interface can also be used with the select(2) call.
- *
- *	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.
- *
-
- *      1.01 fix for 2.3.X                    rz@linux-m68k.org
- *      1.02 merged with code from genrtc.c   rz@linux-m68k.org
- *      1.03 make it more portable            zippel@linux-m68k.org
- *      1.04 removed useless timer code       rz@linux-m68k.org
- *      1.05 portable RTC_UIE emulation       rz@linux-m68k.org
- *      1.06 set_rtc_time can return an error trini@kernel.crashing.org
- *      1.07 ported to HP PARISC (hppa)	      Helge Deller <deller@gmx.de>
- */
-
-#define RTC_VERSION	"1.07"
-
-#include <linux/module.h>
-#include <linux/errno.h>
-#include <linux/miscdevice.h>
-#include <linux/fcntl.h>
-
-#include <linux/rtc.h>
-#include <linux/init.h>
-#include <linux/poll.h>
-#include <linux/proc_fs.h>
-#include <linux/smp_lock.h>
-#include <linux/workqueue.h>
-
-#include <asm/uaccess.h>
-#include <asm/system.h>
-#include <asm/rtc.h>
-
-/*
- *	We sponge a minor off of the misc major. No need slurping
- *	up another valuable major dev number for this. If you add
- *	an ioctl, make sure you don't conflict with SPARC's RTC
- *	ioctls.
- */
-
-static DECLARE_WAIT_QUEUE_HEAD(gen_rtc_wait);
-
-/*
- *	Bits in gen_rtc_status.
- */
-
-#define RTC_IS_OPEN		0x01	/* means /dev/rtc is in use	*/
-
-static unsigned char gen_rtc_status;	/* bitmapped status byte.	*/
-static unsigned long gen_rtc_irq_data;	/* our output to the world	*/
-
-/* months start at 0 now */
-static unsigned char days_in_mo[] =
-{31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};
-
-static int irq_active;
-
-#ifdef CONFIG_GEN_RTC_X
-static struct work_struct genrtc_task;
-static struct timer_list timer_task;
-
-static unsigned int oldsecs;
-static int lostint;
-static unsigned long tt_exp;
-
-static void gen_rtc_timer(unsigned long data);
-
-static volatile int stask_active;              /* schedule_work */
-static volatile int ttask_active;              /* timer_task */
-static int stop_rtc_timers;                    /* don't requeue tasks */
-static DEFINE_SPINLOCK(gen_rtc_lock);
-
-static void gen_rtc_interrupt(unsigned long arg);
-
-/*
- * Routine to poll RTC seconds field for change as often as possible,
- * after first RTC_UIE use timer to reduce polling
- */
-static void genrtc_troutine(struct work_struct *work)
-{
-	unsigned int tmp = get_rtc_ss();
-	
-	if (stop_rtc_timers) {
-		stask_active = 0;
-		return;
-	}
-
-	if (oldsecs != tmp){
-		oldsecs = tmp;
-
-		timer_task.function = gen_rtc_timer;
-		timer_task.expires = jiffies + HZ - (HZ/10);
-		tt_exp=timer_task.expires;
-		ttask_active=1;
-		stask_active=0;
-		add_timer(&timer_task);
-
-		gen_rtc_interrupt(0);
-	} else if (schedule_work(&genrtc_task) == 0)
-		stask_active = 0;
-}
-
-static void gen_rtc_timer(unsigned long data)
-{
-	lostint = get_rtc_ss() - oldsecs ;
-	if (lostint<0) 
-		lostint = 60 - lostint;
-	if (time_after(jiffies, tt_exp))
-		printk(KERN_INFO "genrtc: timer task delayed by %ld jiffies\n",
-		       jiffies-tt_exp);
-	ttask_active=0;
-	stask_active=1;
-	if ((schedule_work(&genrtc_task) == 0))
-		stask_active = 0;
-}
-
-/* 
- * call gen_rtc_interrupt function to signal an RTC_UIE,
- * arg is unused.
- * Could be invoked either from a real interrupt handler or
- * from some routine that periodically (eg 100HZ) monitors
- * whether RTC_SECS changed
- */
-static void gen_rtc_interrupt(unsigned long arg)
-{
-	/*  We store the status in the low byte and the number of
-	 *	interrupts received since the last read in the remainder
-	 *	of rtc_irq_data.  */
-
-	gen_rtc_irq_data += 0x100;
-	gen_rtc_irq_data &= ~0xff;
-	gen_rtc_irq_data |= RTC_UIE;
-
-	if (lostint){
-		printk("genrtc: system delaying clock ticks?\n");
-		/* increment count so that userspace knows something is wrong */
-		gen_rtc_irq_data += ((lostint-1)<<8);
-		lostint = 0;
-	}
-
-	wake_up_interruptible(&gen_rtc_wait);
-}
-
-/*
- *	Now all the various file operations that we export.
- */
-static ssize_t gen_rtc_read(struct file *file, char __user *buf,
-			size_t count, loff_t *ppos)
-{
-	unsigned long data;
-	ssize_t retval;
-
-	if (count != sizeof (unsigned int) && count != sizeof (unsigned long))
-		return -EINVAL;
-
-	if (file->f_flags & O_NONBLOCK && !gen_rtc_irq_data)
-		return -EAGAIN;
-
-	retval = wait_event_interruptible(gen_rtc_wait,
-			(data = xchg(&gen_rtc_irq_data, 0)));
-	if (retval)
-		goto out;
-
-	/* first test allows optimizer to nuke this case for 32-bit machines */
-	if (sizeof (int) != sizeof (long) && count == sizeof (unsigned int)) {
-		unsigned int uidata = data;
-		retval = put_user(uidata, (unsigned int __user *)buf) ?:
-			sizeof(unsigned int);
-	}
-	else {
-		retval = put_user(data, (unsigned long __user *)buf) ?:
-			sizeof(unsigned long);
-	}
-out:
-	return retval;
-}
-
-static unsigned int gen_rtc_poll(struct file *file,
-				 struct poll_table_struct *wait)
-{
-	poll_wait(file, &gen_rtc_wait, wait);
-	if (gen_rtc_irq_data != 0)
-		return POLLIN | POLLRDNORM;
-	return 0;
-}
-
-#endif
-
-/*
- * Used to disable/enable interrupts, only RTC_UIE supported
- * We also clear out any old irq data after an ioctl() that
- * meddles with the interrupt enable/disable bits.
- */
-
-static inline void gen_clear_rtc_irq_bit(unsigned char bit)
-{
-#ifdef CONFIG_GEN_RTC_X
-	stop_rtc_timers = 1;
-	if (ttask_active){
-		del_timer_sync(&timer_task);
-		ttask_active = 0;
-	}
-	while (stask_active)
-		schedule();
-
-	spin_lock(&gen_rtc_lock);
-	irq_active = 0;
-	spin_unlock(&gen_rtc_lock);
-#endif
-}
-
-static inline int gen_set_rtc_irq_bit(unsigned char bit)
-{
-#ifdef CONFIG_GEN_RTC_X
-	spin_lock(&gen_rtc_lock);
-	if ( !irq_active ) {
-		irq_active = 1;
-		stop_rtc_timers = 0;
-		lostint = 0;
-		INIT_WORK(&genrtc_task, genrtc_troutine);
-		oldsecs = get_rtc_ss();
-		init_timer(&timer_task);
-
-		stask_active = 1;
-		if (schedule_work(&genrtc_task) == 0){
-			stask_active = 0;
-		}
-	}
-	spin_unlock(&gen_rtc_lock);
-	gen_rtc_irq_data = 0;
-	return 0;
-#else
-	return -EINVAL;
-#endif
-}
-
-static int gen_rtc_ioctl(struct inode *inode, struct file *file,
-			 unsigned int cmd, unsigned long arg)
-{
-	struct rtc_time wtime;
-	struct rtc_pll_info pll;
-	void __user *argp = (void __user *)arg;
-
-	switch (cmd) {
-
-	case RTC_PLL_GET:
-	    if (get_rtc_pll(&pll))
-	 	    return -EINVAL;
-	    else
-		    return copy_to_user(argp, &pll, sizeof pll) ? -EFAULT : 0;
-
-	case RTC_PLL_SET:
-		if (!capable(CAP_SYS_TIME))
-			return -EACCES;
-		if (copy_from_user(&pll, argp, sizeof(pll)))
-			return -EFAULT;
-	    return set_rtc_pll(&pll);
-
-	case RTC_UIE_OFF:	/* disable ints from RTC updates.	*/
-		gen_clear_rtc_irq_bit(RTC_UIE);
-		return 0;
-
-	case RTC_UIE_ON:	/* enable ints for RTC updates.	*/
-	        return gen_set_rtc_irq_bit(RTC_UIE);
-
-	case RTC_RD_TIME:	/* Read the time/date from RTC	*/
-		/* this doesn't get week-day, who cares */
-		memset(&wtime, 0, sizeof(wtime));
-		get_rtc_time(&wtime);
-
-		return copy_to_user(argp, &wtime, sizeof(wtime)) ? -EFAULT : 0;
-
-	case RTC_SET_TIME:	/* Set the RTC */
-	    {
-		int year;
-		unsigned char leap_yr;
-
-		if (!capable(CAP_SYS_TIME))
-			return -EACCES;
-
-		if (copy_from_user(&wtime, argp, sizeof(wtime)))
-			return -EFAULT;
-
-		year = wtime.tm_year + 1900;
-		leap_yr = ((!(year % 4) && (year % 100)) ||
-			   !(year % 400));
-
-		if ((wtime.tm_mon < 0 || wtime.tm_mon > 11) || (wtime.tm_mday < 1))
-			return -EINVAL;
-
-		if (wtime.tm_mday < 0 || wtime.tm_mday >
-		    (days_in_mo[wtime.tm_mon] + ((wtime.tm_mon == 1) && leap_yr)))
-			return -EINVAL;
-
-		if (wtime.tm_hour < 0 || wtime.tm_hour >= 24 ||
-		    wtime.tm_min < 0 || wtime.tm_min >= 60 ||
-		    wtime.tm_sec < 0 || wtime.tm_sec >= 60)
-			return -EINVAL;
-
-		return set_rtc_time(&wtime);
-	    }
-	}
-
-	return -EINVAL;
-}
-
-/*
- *	We enforce only one user at a time here with the open/close.
- *	Also clear the previous interrupt data on an open, and clean
- *	up things on a close.
- */
-
-static int gen_rtc_open(struct inode *inode, struct file *file)
-{
-	lock_kernel();
-	if (gen_rtc_status & RTC_IS_OPEN) {
-		unlock_kernel();
-		return -EBUSY;
-	}
-
-	gen_rtc_status |= RTC_IS_OPEN;
-	gen_rtc_irq_data = 0;
-	irq_active = 0;
-	unlock_kernel();
-
-	return 0;
-}
-
-static int gen_rtc_release(struct inode *inode, struct file *file)
-{
-	/*
-	 * Turn off all interrupts once the device is no longer
-	 * in use and clear the data.
-	 */
-
-	gen_clear_rtc_irq_bit(RTC_PIE|RTC_AIE|RTC_UIE);
-
-	gen_rtc_status &= ~RTC_IS_OPEN;
-	return 0;
-}
-
-
-#ifdef CONFIG_PROC_FS
-
-/*
- *	Info exported via "/proc/driver/rtc".
- */
-
-static int gen_rtc_proc_output(char *buf)
-{
-	char *p;
-	struct rtc_time tm;
-	unsigned int flags;
-	struct rtc_pll_info pll;
-
-	p = buf;
-
-	flags = get_rtc_time(&tm);
-
-	p += sprintf(p,
-		     "rtc_time\t: %02d:%02d:%02d\n"
-		     "rtc_date\t: %04d-%02d-%02d\n"
-		     "rtc_epoch\t: %04u\n",
-		     tm.tm_hour, tm.tm_min, tm.tm_sec,
-		     tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday, 1900);
-
-	tm.tm_hour = tm.tm_min = tm.tm_sec = 0;
-
-	p += sprintf(p, "alarm\t\t: ");
-	if (tm.tm_hour <= 24)
-		p += sprintf(p, "%02d:", tm.tm_hour);
-	else
-		p += sprintf(p, "**:");
-
-	if (tm.tm_min <= 59)
-		p += sprintf(p, "%02d:", tm.tm_min);
-	else
-		p += sprintf(p, "**:");
-
-	if (tm.tm_sec <= 59)
-		p += sprintf(p, "%02d\n", tm.tm_sec);
-	else
-		p += sprintf(p, "**\n");
-
-	p += sprintf(p,
-		     "DST_enable\t: %s\n"
-		     "BCD\t\t: %s\n"
-		     "24hr\t\t: %s\n"
-		     "square_wave\t: %s\n"
-		     "alarm_IRQ\t: %s\n"
-		     "update_IRQ\t: %s\n"
-		     "periodic_IRQ\t: %s\n"
-		     "periodic_freq\t: %ld\n"
-		     "batt_status\t: %s\n",
-		     (flags & RTC_DST_EN) ? "yes" : "no",
-		     (flags & RTC_DM_BINARY) ? "no" : "yes",
-		     (flags & RTC_24H) ? "yes" : "no",
-		     (flags & RTC_SQWE) ? "yes" : "no",
-		     (flags & RTC_AIE) ? "yes" : "no",
-		     irq_active ? "yes" : "no",
-		     (flags & RTC_PIE) ? "yes" : "no",
-		     0L /* freq */,
-		     (flags & RTC_BATT_BAD) ? "bad" : "okay");
-	if (!get_rtc_pll(&pll))
-	    p += sprintf(p,
-			 "PLL adjustment\t: %d\n"
-			 "PLL max +ve adjustment\t: %d\n"
-			 "PLL max -ve adjustment\t: %d\n"
-			 "PLL +ve adjustment factor\t: %d\n"
-			 "PLL -ve adjustment factor\t: %d\n"
-			 "PLL frequency\t: %ld\n",
-			 pll.pll_value,
-			 pll.pll_max,
-			 pll.pll_min,
-			 pll.pll_posmult,
-			 pll.pll_negmult,
-			 pll.pll_clock);
-	return p - buf;
-}
-
-static int gen_rtc_read_proc(char *page, char **start, off_t off,
-			     int count, int *eof, void *data)
-{
-	int len = gen_rtc_proc_output (page);
-        if (len <= off+count) *eof = 1;
-	*start = page + off;
-	len -= off;
-        if (len>count) len = count;
-        if (len<0) len = 0;
-	return len;
-}
-
-static int __init gen_rtc_proc_init(void)
-{
-	struct proc_dir_entry *r;
-
-	r = create_proc_read_entry("driver/rtc", 0, NULL, gen_rtc_read_proc, NULL);
-	if (!r)
-		return -ENOMEM;
-	return 0;
-}
-#else
-static inline int gen_rtc_proc_init(void) { return 0; }
-#endif /* CONFIG_PROC_FS */
-
-
-/*
- *	The various file operations we support.
- */
-
-static const struct file_operations gen_rtc_fops = {
-	.owner		= THIS_MODULE,
-#ifdef CONFIG_GEN_RTC_X
-	.read		= gen_rtc_read,
-	.poll		= gen_rtc_poll,
-#endif
-	.ioctl		= gen_rtc_ioctl,
-	.open		= gen_rtc_open,
-	.release	= gen_rtc_release,
-};
-
-static struct miscdevice rtc_gen_dev =
-{
-	.minor		= RTC_MINOR,
-	.name		= "rtc",
-	.fops		= &gen_rtc_fops,
-};
-
-static int __init rtc_generic_init(void)
-{
-	int retval;
-
-	printk(KERN_INFO "Generic RTC Driver v%s\n", RTC_VERSION);
-
-	retval = misc_register(&rtc_gen_dev);
-	if (retval < 0)
-		return retval;
-
-	retval = gen_rtc_proc_init();
-	if (retval) {
-		misc_deregister(&rtc_gen_dev);
-		return retval;
-	}
-
-	return 0;
-}
-
-static void __exit rtc_generic_exit(void)
-{
-	remove_proc_entry ("driver/rtc", NULL);
-	misc_deregister(&rtc_gen_dev);
-}
-
-
-module_init(rtc_generic_init);
-module_exit(rtc_generic_exit);

Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver

[Alessandro Zummo]

On Fri, 20 Feb 2009 16:46:44 +0100
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:

> Fortunately there already exists a generic RTC class driver: "rtc-parisc".
> Despite it's name, it's platform-independent, as it's build on top of the RTC
> abstraction used by "genrtc".
> 
> This patch series
>   - adds a missing module alias to rtc-parisc,
>   - renames rtc-parisc to rtc-generic,
>   - converts the architectures that currently have CONFIG_GEN_RTC enabled in
>     their defconfig (m68k, parisc, powerpc) to rtc-generic,
>   - removes the obsolete rtc-ppc driver,
>   - removes the old genrtc driver.
>   
> Note that genrtc may be used on other archictectures as well: at least alpha
> has the required infrastructure ([gs]et_rtc_time()). The Kconfig rules allow
> genrtc to be enabled on several others (cris, h8300, mn10300, um, x86, xtensa).
> 
> Furthermore genrtc and rtc-generic are not 100% userspace compatible:
>   - /dev/rtc provided by genrtc uses a misc character device (10:135),
>   - /dev/rtc provided by rtc-generic uses a dynamic character device.

 Hello,

   my opinion on this kind of stuff is that I want to avoid the layering
 of implementations under the rtc subsystem. I'd rather prefer that each
 rtc device had its own driver. 
 
  I've made error in the past, by accepting such kind of drivers, and
 would like to avoid that it happens again.

  Regarding the user space, the assumption that a device has
 a fixed major:minor number should be dropped as well.

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver

[Geert Uytterhoeven]

On Fri, 20 Feb 2009, Alessandro Zummo wrote:
> On Fri, 20 Feb 2009 16:46:44 +0100
> Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > Fortunately there already exists a generic RTC class driver: "rtc-p=
arisc".
> > Despite it's name, it's platform-independent, as it's build on top =
of the RTC
> > abstraction used by "genrtc".
> >=20
> > This patch series
> >   - adds a missing module alias to rtc-parisc,
> >   - renames rtc-parisc to rtc-generic,
> >   - converts the architectures that currently have CONFIG_GEN_RTC e=
nabled in
> >     their defconfig (m68k, parisc, powerpc) to rtc-generic,
> >   - removes the obsolete rtc-ppc driver,
> >   - removes the old genrtc driver.
> >  =20
> > Note that genrtc may be used on other archictectures as well: at le=
ast alpha
> > has the required infrastructure ([gs]et_rtc_time()). The Kconfig ru=
les allow
> > genrtc to be enabled on several others (cris, h8300, mn10300, um, x=
86, xtensa).
> >=20
> > Furthermore genrtc and rtc-generic are not 100% userspace compatibl=
e:
> >   - /dev/rtc provided by genrtc uses a misc character device (10:13=
5),
> >   - /dev/rtc provided by rtc-generic uses a dynamic character devic=
e.
>=20
>  Hello,
>=20
>    my opinion on this kind of stuff is that I want to avoid the layer=
ing
>  of implementations under the rtc subsystem. I'd rather prefer that e=
ach
>  rtc device had its own driver.=20
> =20
>   I've made error in the past, by accepting such kind of drivers, and
>  would like to avoid that it happens again.

So you want us to kill the ppc_md.[gs]et_rtc_time() [ppc], mach_hwclk()=
 [m68k],
mach_gettod() [m68knommu] (and probably a few other) abstractions, and =
move all
RTC code out of arch/ into seperate drivers under drivers/rtc/ instead?

What about ppc_md.get_boot_time() [ppc]?
Please note that the functions above may also be used for very early cl=
ock
setting (e.g. time_init()) and in read_persistent_clock().
How should we handle these?

Even on x86 there seems to be way too much RTC logic in arch/x86/kernel=
/rtc.c
(e.g. mach_get_cmos_time()), which is duplicated in drivers/rtc/rtc-cmo=
s.c
through the inline function __get_rtc_time() in include/asm-generic/rtc=
=2Eh
(clever, hardware-specific stuff in asm-generic ;-)

>   Regarding the user space, the assumption that a device has
>  a fixed major:minor number should be dropped as well.

I know. But it's a userland-visible change, so I wanted to explicit poi=
nt to
it.

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village =B7 Da Vincilaan 7-D1 =B7 B-1935 Zaventem =B7 Bel=
gium

Phone:    +32 (0)2 700 8453
=46ax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 =B7 RPR Brussels
=46ortis =B7 BIC GEBABEBB =B7 IBAN BE41293037680010
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver

[Alessandro Zummo]

On Mon, 23 Feb 2009 13:34:49 +0100 (CET)
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:

> >  Hello,
> > 
> >    my opinion on this kind of stuff is that I want to avoid the layering
> >  of implementations under the rtc subsystem. I'd rather prefer that each
> >  rtc device had its own driver. 
> >  
> >   I've made error in the past, by accepting such kind of drivers, and
> >  would like to avoid that it happens again.
> 
> So you want us to kill the ppc_md.[gs]et_rtc_time() [ppc], mach_hwclk() [m68k],
> mach_gettod() [m68knommu] (and probably a few other) abstractions, and move all
> RTC code out of arch/ into seperate drivers under drivers/rtc/ instead?

 not all at once :) 

 I'd start writing a working driver and then see how we should eventually
 adapt the rtc subsystem to cope with your needs.
 
> What about ppc_md.get_boot_time() [ppc]?
> Please note that the functions above may also be used for very early clock
> setting (e.g. time_init()) and in read_persistent_clock().
> How should we handle these?

 read_persistent_clock is something that should be reconsidered
 as well along with all the ntp stuff.

> Even on x86 there seems to be way too much RTC logic in arch/x86/kernel/rtc.c

> (e.g. mach_get_cmos_time()), which is duplicated in drivers/rtc/rtc-cmos.c
> through the inline function __get_rtc_time() in include/asm-generic/rtc.h
> (clever, hardware-specific stuff in asm-generic ;-)

 yep, I know :( that hardcoded rtc stuff seems to be everywhere!


-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver

[Geert Uytterhoeven]

On Mon, 23 Feb 2009, Alessandro Zummo wrote:
> On Mon, 23 Feb 2009 13:34:49 +0100 (CET)
> Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > >    my opinion on this kind of stuff is that I want to avoid the l=
ayering
> > >  of implementations under the rtc subsystem. I'd rather prefer th=
at each
> > >  rtc device had its own driver.=20
> > > =20
> > >   I've made error in the past, by accepting such kind of drivers,=
 and
> > >  would like to avoid that it happens again.
> >=20
> > So you want us to kill the ppc_md.[gs]et_rtc_time() [ppc], mach_hwc=
lk() [m68k],
> > mach_gettod() [m68knommu] (and probably a few other) abstractions, =
and move all
> > RTC code out of arch/ into seperate drivers under drivers/rtc/ inst=
ead?
>=20
>  not all at once :)=20
>=20
>  I'd start writing a working driver and then see how we should eventu=
ally
>  adapt the rtc subsystem to cope with your needs.

OK, so here's a first example: rtc-ps3.

Note that this single patch adds 100+ lines of code, while my previous =
patch
series removed 500+ lines of code, while solving the autoloading proble=
m for
several ppc and m68k platforms.

Converting all (ca. 20?) ppc and m68k RTC support code into individual =
RTC
class drivers would add ca. 100+ lines of code for each individual driv=
er.

=46rom 641412e4e638d00c8821c2d9b38e02727821a203 Mon Sep 17 00:00:00 200=
1
=46rom: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Date: Tue, 24 Feb 2009 14:04:20 +0100
Subject: [PATCH] Create a real RTC driver for PS3, called "rtc-ps3"

---
 arch/powerpc/include/asm/ps3.h        |    4 +
 arch/powerpc/platforms/ps3/os-area.c  |    2 +
 arch/powerpc/platforms/ps3/platform.h |    2 -
 arch/powerpc/platforms/ps3/setup.c    |    2 -
 arch/powerpc/platforms/ps3/time.c     |   25 ++++----
 drivers/rtc/Kconfig                   |    9 +++
 drivers/rtc/Makefile                  |    1 +
 drivers/rtc/rtc-ps3.c                 |  106 +++++++++++++++++++++++++=
++++++++
 8 files changed, 133 insertions(+), 18 deletions(-)
 create mode 100644 drivers/rtc/rtc-ps3.c

diff --git a/arch/powerpc/include/asm/ps3.h b/arch/powerpc/include/asm/=
ps3.h
index b65446a..dee0480 100644
--- a/arch/powerpc/include/asm/ps3.h
+++ b/arch/powerpc/include/asm/ps3.h
@@ -500,6 +500,10 @@ u64 ps3_get_spe_id(void *arg);
 /* mutex synchronizing GPU accesses and video mode changes */
 extern struct mutex ps3_gpu_mutex;
=20
+/* os area */
+u64 ps3_os_area_get_rtc_diff(void);
+void ps3_os_area_set_rtc_diff(u64 rtc_diff);
+
 /* kernel debug routines */
=20
 int ps3_debug_setup_dabr(u64 address, unsigned int dabr_flags);
diff --git a/arch/powerpc/platforms/ps3/os-area.c b/arch/powerpc/platfo=
rms/ps3/os-area.c
index ccf0157..f1f2d47 100644
--- a/arch/powerpc/platforms/ps3/os-area.c
+++ b/arch/powerpc/platforms/ps3/os-area.c
@@ -823,6 +823,7 @@ u64 ps3_os_area_get_rtc_diff(void)
 {
 	return saved_params.rtc_diff;
 }
+EXPORT_SYMBOL(ps3_os_area_get_rtc_diff);
=20
 /**
  * ps3_os_area_set_rtc_diff - Set the rtc diff value.
@@ -838,6 +839,7 @@ void ps3_os_area_set_rtc_diff(u64 rtc_diff)
 		os_area_queue_work();
 	}
 }
+EXPORT_SYMBOL(ps3_os_area_set_rtc_diff);
=20
 /**
  * ps3_os_area_get_av_multi_out - Returns the default video mode.
diff --git a/arch/powerpc/platforms/ps3/platform.h b/arch/powerpc/platf=
orms/ps3/platform.h
index 235c13e..136aa06 100644
--- a/arch/powerpc/platforms/ps3/platform.h
+++ b/arch/powerpc/platforms/ps3/platform.h
@@ -64,8 +64,6 @@ int ps3_set_rtc_time(struct rtc_time *time);
=20
 void __init ps3_os_area_save_params(void);
 void __init ps3_os_area_init(void);
-u64 ps3_os_area_get_rtc_diff(void);
-void ps3_os_area_set_rtc_diff(u64 rtc_diff);
=20
 /* spu */
=20
diff --git a/arch/powerpc/platforms/ps3/setup.c b/arch/powerpc/platform=
s/ps3/setup.c
index e2032c6..020ba1d 100644
--- a/arch/powerpc/platforms/ps3/setup.c
+++ b/arch/powerpc/platforms/ps3/setup.c
@@ -300,8 +300,6 @@ define_machine(ps3) {
 	.init_IRQ			=3D ps3_init_IRQ,
 	.panic				=3D ps3_panic,
 	.get_boot_time			=3D ps3_get_boot_time,
-	.set_rtc_time			=3D ps3_set_rtc_time,
-	.get_rtc_time			=3D ps3_get_rtc_time,
 	.set_dabr			=3D ps3_set_dabr,
 	.calibrate_decr			=3D ps3_calibrate_decr,
 	.progress			=3D ps3_progress,
diff --git a/arch/powerpc/platforms/ps3/time.c b/arch/powerpc/platforms=
/ps3/time.c
index d0daf7d..112397d 100644
--- a/arch/powerpc/platforms/ps3/time.c
+++ b/arch/powerpc/platforms/ps3/time.c
@@ -19,6 +19,7 @@
  */
=20
 #include <linux/kernel.h>
+#include <linux/platform_device.h>
=20
 #include <asm/rtc.h>
 #include <asm/lv1call.h>
@@ -74,23 +75,19 @@ static u64 read_rtc(void)
 	return rtc_val;
 }
=20
-int ps3_set_rtc_time(struct rtc_time *tm)
+unsigned long __init ps3_get_boot_time(void)
 {
-	u64 now =3D mktime(tm->tm_year + 1900, tm->tm_mon + 1, tm->tm_mday,
-		tm->tm_hour, tm->tm_min, tm->tm_sec);
-
-	ps3_os_area_set_rtc_diff(now - read_rtc());
-	return 0;
+	return read_rtc() + ps3_os_area_get_rtc_diff();
 }
=20
-void ps3_get_rtc_time(struct rtc_time *tm)
-{
-	to_tm(read_rtc() + ps3_os_area_get_rtc_diff(), tm);
-	tm->tm_year -=3D 1900;
-	tm->tm_mon -=3D 1;
-}
+static struct platform_device rtc_ps3_dev =3D {
+	.name =3D "rtc-ps3",
+	.id =3D -1,
+};
=20
-unsigned long __init ps3_get_boot_time(void)
+static int __init rtc_init(void)
 {
-	return read_rtc() + ps3_os_area_get_rtc_diff();
+	return platform_device_register(&rtc_ps3_dev);
 }
+
+module_init(rtc_init);
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 81450fb..4b61288 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -736,4 +736,13 @@ config RTC_DRV_MV
 	  This driver can also be built as a module. If so, the module
 	  will be called rtc-mv.
=20
+config RTC_DRV_PS3
+	tristate "PS3 RTC"
+	depends on PPC_PS3
+	help
+	  If you say yes here you will get support for the RTC on PS3.
+
+	  This driver can also be built as a module. If so, the module
+	  will be called rtc-ps3.
+
 endif # RTC_CLASS
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 0e697aa..7fe627c 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -76,3 +76,4 @@ obj-$(CONFIG_RTC_DRV_VR41XX)	+=3D rtc-vr41xx.o
 obj-$(CONFIG_RTC_DRV_WM8350)	+=3D rtc-wm8350.o
 obj-$(CONFIG_RTC_DRV_X1205)	+=3D rtc-x1205.o
 obj-$(CONFIG_RTC_DRV_PCF50633)	+=3D rtc-pcf50633.o
+obj-$(CONFIG_RTC_DRV_PS3)	+=3D rtc-ps3.o
diff --git a/drivers/rtc/rtc-ps3.c b/drivers/rtc/rtc-ps3.c
new file mode 100644
index 0000000..84ae08c
--- /dev/null
+++ b/drivers/rtc/rtc-ps3.c
@@ -0,0 +1,106 @@
+/*
+ * PS3 RTC Driver
+ *
+ * Copyright 2009 Sony Corporation
+ *
+ * This program is free software; you can redistribute it and/or modif=
y
+ * it under the terms of the GNU General Public License as published b=
y
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.
+ * If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/rtc.h>
+
+#include <asm/lv1call.h>
+#include <asm/ps3.h>
+
+
+static u64 read_rtc(void)
+{
+	int result;
+	u64 rtc_val;
+	u64 tb_val;
+
+	result =3D lv1_get_rtc(&rtc_val, &tb_val);
+	BUG_ON(result);
+
+	return rtc_val;
+}
+
+static int ps3_get_time(struct device *dev, struct rtc_time *tm)
+{
+	to_tm(read_rtc() + ps3_os_area_get_rtc_diff(), tm);
+	tm->tm_year -=3D 1900;
+	tm->tm_mon -=3D 1;
+	return 0;
+}
+
+static int ps3_set_time(struct device *dev, struct rtc_time *tm)
+{
+	u64 now =3D mktime(tm->tm_year + 1900, tm->tm_mon + 1, tm->tm_mday,
+			 tm->tm_hour, tm->tm_min, tm->tm_sec);
+	ps3_os_area_set_rtc_diff(now - read_rtc());
+	return 0;
+}
+
+static const struct rtc_class_ops ps3_rtc_ops =3D {
+	.read_time =3D ps3_get_time,
+	.set_time =3D ps3_set_time,
+};
+
+static int __devinit ps3_rtc_probe(struct platform_device *dev)
+{
+	struct rtc_device *rtc;
+
+	rtc =3D rtc_device_register("rtc-ps3", &dev->dev, &ps3_rtc_ops,
+				     THIS_MODULE);
+	if (IS_ERR(rtc))
+		return PTR_ERR(rtc);
+
+	platform_set_drvdata(dev, rtc);
+	return 0;
+}
+
+static int __devexit ps3_rtc_remove(struct platform_device *dev)
+{
+	rtc_device_unregister(platform_get_drvdata(dev));
+	return 0;
+}
+
+static struct platform_driver ps3_rtc_driver =3D {
+	.driver =3D {
+		.name =3D "rtc-ps3",
+		.owner =3D THIS_MODULE,
+	},
+	.probe =3D ps3_rtc_probe,
+	.remove =3D __devexit_p(ps3_rtc_remove),
+};
+
+static int __init ps3_rtc_init(void)
+{
+	return platform_driver_register(&ps3_rtc_driver);
+}
+
+static void __exit ps3_rtc_fini(void)
+{
+	platform_driver_unregister(&ps3_rtc_driver);
+}
+
+module_init(ps3_rtc_init);
+module_exit(ps3_rtc_fini);
+
+MODULE_AUTHOR("Sony Corporation");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("ps3 RTC driver");
+MODULE_ALIAS("platform:rtc-ps3");
--=20
1.6.0.4


With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village =B7 Da Vincilaan 7-D1 =B7 B-1935 Zaventem =B7 Bel=
gium

Phone:    +32 (0)2 700 8453
=46ax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 =B7 RPR Brussels
=46ortis =B7 BIC GEBABEBB =B7 IBAN BE41293037680010

Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver

[Alessandro Zummo]

On Tue, 24 Feb 2009 18:56:03 +0100 (CET)
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:

> 
> On Mon, 23
> > 
> >  I'd start writing a working driver and then see how we should eventually
> >  adapt the rtc subsystem to cope with your needs.
> 
> OK, so here's a first example: rtc-ps3.
> 
> Note that this single patch adds 100+ lines of code, while my previous patch
> series removed 500+ lines of code, while solving the autoloading problem for
> several ppc and m68k platforms.

 This patch has a much cleaner approach, imho.

> Converting all (ca. 20?) ppc and m68k RTC support code into individual RTC
> class drivers would add ca. 100+ lines of code for each individual driver.



 How different are all of those boards? It's simply a matter
 of parameters and offsets? can we group them somehow?

 
-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver

[Brad Boyer]

On Tue, Feb 24, 2009 at 07:37:08PM +0100, Alessandro Zummo wrote:
> On Tue, 24 Feb 2009 18:56:03 +0100 (CET)
> Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > Converting all (ca. 20?) ppc and m68k RTC support code into individual RTC
> > class drivers would add ca. 100+ lines of code for each individual driver.
> 
>  How different are all of those boards? It's simply a matter
>  of parameters and offsets? can we group them somehow?

I imagine we could cut down the numbers somewhat with clever code sharing,
but it's still going to be a fairly large number. I don't know all the
embedded boards, but just with all the Macintosh models there are at
least three and maybe four drastically different methods of RTC access,
and all of them are directly tied to some chip that does something else
completely unrelated. For one of them we don't even have a driver at the
moment.  They also are all custom chips that wouldn't be used anywhere
else. The other thing we need to keep in mind is that if we do it right
we can share drivers across m68k and powerpc in some cases.  I imagine
some of the embedded powerpc boards are using chips that are common in
other architectures as well.

	Brad Boyer
	flar@allandria.com

Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver

[Geert Uytterhoeven]

On Tue, 24 Feb 2009, Brad Boyer wrote:
> On Tue, Feb 24, 2009 at 07:37:08PM +0100, Alessandro Zummo wrote:
> > On Tue, 24 Feb 2009 18:56:03 +0100 (CET)
> > Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > > Converting all (ca. 20?) ppc and m68k RTC support code into indiv=
idual RTC
> > > class drivers would add ca. 100+ lines of code for each individua=
l driver.
> >=20
> >  How different are all of those boards? It's simply a matter
> >  of parameters and offsets? can we group them somehow?
>=20
> I imagine we could cut down the numbers somewhat with clever code sha=
ring,
> but it's still going to be a fairly large number. I don't know all th=
e
> embedded boards, but just with all the Macintosh models there are at
> least three and maybe four drastically different methods of RTC acces=
s,
> and all of them are directly tied to some chip that does something el=
se
> completely unrelated. For one of them we don't even have a driver at =
the

Yeah, on Mac/m68k the RTC is usually handled by a chip that does lots o=
f other
things, so you need to keep the bulk of the code in arch/m68k/ anyway.

> moment.  They also are all custom chips that wouldn't be used anywher=
e
> else. The other thing we need to keep in mind is that if we do it rig=
ht
> we can share drivers across m68k and powerpc in some cases.  I imagin=
e
> some of the embedded powerpc boards are using chips that are common i=
n
> other architectures as well.

Many embedded powerpc boards already have RTC class drivers under drive=
rs/rtc/,
as their RTC chips are sufficiently common.

The ones that don't are mostly "workstation" or "server" type hardware.=
 The
full list is:
  - rtas_set_rtc_time
  - mpc8xx_set_rtc_time
  - beat_get_rtc_time
  - chrp_set_rtc_time
  - iSeries_set_rtc_time
  - maple_set_rtc_time
  - pmac_set_rtc_time
  - ps3_set_rtc_time

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village =B7 Da Vincilaan 7-D1 =B7 B-1935 Zaventem =B7 Bel=
gium

Phone:    +32 (0)2 700 8453
=46ax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 =B7 RPR Brussels
=46ortis =B7 BIC GEBABEBB =B7 IBAN BE41293037680010
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver

[David Woodhouse]

On Mon, 2009-02-23 at 13:34 +0100, Geert Uytterhoeven wrote:
> >    my opinion on this kind of stuff is that I want to avoid the layering
> >  of implementations under the rtc subsystem. I'd rather prefer that each
> >  rtc device had its own driver. 
> >  
> >   I've made error in the past, by accepting such kind of drivers, and
> >  would like to avoid that it happens again.
> 
> So you want us to kill the ppc_md.[gs]et_rtc_time() [ppc], mach_hwclk() [m68k],
> mach_gettod() [m68knommu] (and probably a few other) abstractions, and move all
> RTC code out of arch/ into seperate drivers under drivers/rtc/ instead?

That's the ideal... although did we get NTP sync working again yet?

The rtc-ppc driver was intended as a short-term workaround so that we
can enable the generic RTC class (which was required for PA Semi
Electra, iirc), and still have stuff work on other platforms.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver

[Alessandro Zummo]

On Wed, 25 Feb 2009 06:35:27 +0900
David Woodhouse <dwmw2@infradead.org> wrote:

> > So you want us to kill the ppc_md.[gs]et_rtc_time() [ppc], mach_hwclk() [m68k],
> > mach_gettod() [m68knommu] (and probably a few other) abstractions, and move all
> > RTC code out of arch/ into seperate drivers under drivers/rtc/ instead?
> 
> That's the ideal... although did we get NTP sync working again yet?

 not yet. we're close but I've been very busy :(
 
-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver

[David Woodhouse]

On Tue, 2009-02-24 at 23:11 +0100, Alessandro Zummo wrote:
> On Wed, 25 Feb 2009 06:35:27 +0900
> David Woodhouse <dwmw2@infradead.org> wrote:
> 
> > > So you want us to kill the ppc_md.[gs]et_rtc_time() [ppc], mach_hwclk() [m68k],
> > > mach_gettod() [m68knommu] (and probably a few other) abstractions, and move all
> > > RTC code out of arch/ into seperate drivers under drivers/rtc/ instead?
> > 
> > That's the ideal... although did we get NTP sync working again yet?
> 
>  not yet. we're close but I've been very busy :(

I know the feeling.

Once that's working, we can convert individual PPC platforms over,
removing the routines from the ppc_md and creating a generic RTC driver
instead. PA Electra is already like that -- because it wasn't a
regression there to have broken NTP sync. But the others need to wait.

Eventually, we ought to be able to drop the RTC functions from the
ppc_md -- and presumably the equivalent for other architectures too.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver

[Geert Uytterhoeven]

On Wed, 25 Feb 2009, David Woodhouse wrote:
> On Tue, 2009-02-24 at 23:11 +0100, Alessandro Zummo wrote:
> > On Wed, 25 Feb 2009 06:35:27 +0900
> > David Woodhouse <dwmw2@infradead.org> wrote:
> >=20
> > > > So you want us to kill the ppc_md.[gs]et_rtc_time() [ppc], mach=
_hwclk() [m68k],
> > > > mach_gettod() [m68knommu] (and probably a few other) abstractio=
ns, and move all
> > > > RTC code out of arch/ into seperate drivers under drivers/rtc/ =
instead?
> > >=20
> > > That's the ideal... although did we get NTP sync working again ye=
t?
> >=20
> >  not yet. we're close but I've been very busy :(
>=20
> I know the feeling.
>=20
> Once that's working, we can convert individual PPC platforms over,
> removing the routines from the ppc_md and creating a generic RTC driv=
er
> instead. PA Electra is already like that -- because it wasn't a
> regression there to have broken NTP sync. But the others need to wait=
=2E

I didn't know NTP was broken with RTC class drivers?

So we should actually keep on using genrtc instead of rtc-ppc/rtc-gener=
ic for
now? ;-)

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village =B7 Da Vincilaan 7-D1 =B7 B-1935 Zaventem =B7 Bel=
gium

Phone:    +32 (0)2 700 8453
=46ax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 =B7 RPR Brussels
=46ortis =B7 BIC GEBABEBB =B7 IBAN BE41293037680010
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver

[Alessandro Zummo]

On Wed, 25 Feb 2009 11:00:13 +0100 (CET)
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:

> I didn't know NTP was broken with RTC class drivers?
> 
> So we should actually keep on using genrtc instead of rtc-ppc/rtc-generic for
> now? ;-)

 broken here means that the kernel won't save the time to the hardware
 rtc every 11 minutes as it used to do. normal NTP operations are unaffected.

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver

[Maciej W. Rozycki]

On Wed, 25 Feb 2009, Alessandro Zummo wrote:

> > I didn't know NTP was broken with RTC class drivers?
> > 
> > So we should actually keep on using genrtc instead of rtc-ppc/rtc-generic for
> > now? ;-)
> 
>  broken here means that the kernel won't save the time to the hardware
>  rtc every 11 minutes as it used to do. normal NTP operations are unaffected.

 I posted patches to support it last year -- from your answer I infer they 
were not applied in the end.  I'll see if I can try to refresh them and 
push again next time I'll be upgrading my kernel.

  Maciej

Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver

[Alessandro Zummo]

On Fri, 27 Feb 2009 17:17:36 +0000 (GMT)
"Maciej W. Rozycki" <macro@linux-mips.org> wrote:

>  I posted patches to support it last year -- from your answer I infer they 
> were not applied in the end.  I'll see if I can try to refresh them and 
> push again next time I'll be upgrading my kernel.

 they were almost ok but there are still a few things that I
 need to check before incorporating them. 

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver

[Richard Zidlicky]

On Wed, Feb 25, 2009 at 11:18:36AM +0100, Alessandro Zummo wrote:
> On Wed, 25 Feb 2009 11:00:13 +0100 (CET)
> Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> 
> > I didn't know NTP was broken with RTC class drivers?
> > 
> > So we should actually keep on using genrtc instead of rtc-ppc/rtc-generic for
> > now? ;-)
> 
>  broken here means that the kernel won't save the time to the hardware
>  rtc every 11 minutes as it used to do. normal NTP operations are unaffected.

seems like so far ppc is the only architecture attempting to implement it
correctly, all others either have it unimplemented or use the broken
by design set_rtc_mmss method. 
Also note that in most cases hwclock has much better possibilities
to do a good job.

Regarding genrtc vs rtc-ppc/rtc-generic it is worth noting that genrtc
provides RTC_UIE emulation which is of some use for exotic programs like 
"chrony".
Afaics this is also the only situation without a good userspace workaround 
and chrony never worked well for me so I have nothing against junking the 
code.

Regarding a possible reorganisation from the generic to all separate drivers
I agree that the habit of putting rtc-chip specific code in asm-generic is 
confusing at best. 
In many cases such code might be better placed in drivers/rtc or 
include/linux/rtc/chipname.

Imho this does not preclude the possibility to use a generic framework. While
there certainly are valid reasons to have separate drivers in some cases 
I do not see much value in rewriting everything as separate drivers where 
the generic framework works well.

Richard

Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver

[Geert Uytterhoeven]

T24gRnJpLCAyNyBGZWIgMjAwOSwgUmljaGFyZCBaaWRsaWNreSB3cm90ZToKPiBPbiBXZWQsIEZl
YiAyNSwgMjAwOSBhdCAxMToxODozNkFNICswMTAwLCBBbGVzc2FuZHJvIFp1bW1vIHdyb3RlOgo+
ID4gT24gV2VkLCAyNSBGZWIgMjAwOSAxMTowMDoxMyArMDEwMCAoQ0VUKQo+ID4gR2VlcnQgVXl0
dGVyaG9ldmVuIDxHZWVydC5VeXR0ZXJob2V2ZW5Ac29ueWNvbS5jb20+IHdyb3RlOgo+ID4gCj4g
PiA+IEkgZGlkbid0IGtub3cgTlRQIHdhcyBicm9rZW4gd2l0aCBSVEMgY2xhc3MgZHJpdmVycz8K
PiA+ID4gCj4gPiA+IFNvIHdlIHNob3VsZCBhY3R1YWxseSBrZWVwIG9uIHVzaW5nIGdlbnJ0YyBp
bnN0ZWFkIG9mIHJ0Yy1wcGMvcnRjLWdlbmVyaWMgZm9yCj4gPiA+IG5vdz8gOy0pCj4gPiAKPiA+
ICBicm9rZW4gaGVyZSBtZWFucyB0aGF0IHRoZSBrZXJuZWwgd29uJ3Qgc2F2ZSB0aGUgdGltZSB0
byB0aGUgaGFyZHdhcmUKPiA+ICBydGMgZXZlcnkgMTEgbWludXRlcyBhcyBpdCB1c2VkIHRvIGRv
LiBub3JtYWwgTlRQIG9wZXJhdGlvbnMgYXJlIHVuYWZmZWN0ZWQuCj4gCj4gc2VlbXMgbGlrZSBz
byBmYXIgcHBjIGlzIHRoZSBvbmx5IGFyY2hpdGVjdHVyZSBhdHRlbXB0aW5nIHRvIGltcGxlbWVu
dCBpdAo+IGNvcnJlY3RseSwgYWxsIG90aGVycyBlaXRoZXIgaGF2ZSBpdCB1bmltcGxlbWVudGVk
IG9yIHVzZSB0aGUgYnJva2VuCj4gYnkgZGVzaWduIHNldF9ydGNfbW1zcyBtZXRob2QuIAo+IEFs
c28gbm90ZSB0aGF0IGluIG1vc3QgY2FzZXMgaHdjbG9jayBoYXMgbXVjaCBiZXR0ZXIgcG9zc2li
aWxpdGllcwo+IHRvIGRvIGEgZ29vZCBqb2IuCj4gCj4gUmVnYXJkaW5nIGdlbnJ0YyB2cyBydGMt
cHBjL3J0Yy1nZW5lcmljIGl0IGlzIHdvcnRoIG5vdGluZyB0aGF0IGdlbnJ0Ywo+IHByb3ZpZGVz
IFJUQ19VSUUgZW11bGF0aW9uIHdoaWNoIGlzIG9mIHNvbWUgdXNlIGZvciBleG90aWMgcHJvZ3Jh
bXMgbGlrZSAKPiAiY2hyb255Ii4KPiBBZmFpY3MgdGhpcyBpcyBhbHNvIHRoZSBvbmx5IHNpdHVh
dGlvbiB3aXRob3V0IGEgZ29vZCB1c2Vyc3BhY2Ugd29ya2Fyb3VuZCAKPiBhbmQgY2hyb255IG5l
dmVyIHdvcmtlZCB3ZWxsIGZvciBtZSBzbyBJIGhhdmUgbm90aGluZyBhZ2FpbnN0IGp1bmtpbmcg
dGhlIAo+IGNvZGUuCgpXaGF0IGFib3V0IENPTkZJR19SVENfSU5URl9ERVZfVUlFX0VNVUwgZm9y
IFJUQyBjbGFzcyBkZXZpY2VzPwoKPiBSZWdhcmRpbmcgYSBwb3NzaWJsZSByZW9yZ2FuaXNhdGlv
biBmcm9tIHRoZSBnZW5lcmljIHRvIGFsbCBzZXBhcmF0ZSBkcml2ZXJzCj4gSSBhZ3JlZSB0aGF0
IHRoZSBoYWJpdCBvZiBwdXR0aW5nIHJ0Yy1jaGlwIHNwZWNpZmljIGNvZGUgaW4gYXNtLWdlbmVy
aWMgaXMgCj4gY29uZnVzaW5nIGF0IGJlc3QuIAo+IEluIG1hbnkgY2FzZXMgc3VjaCBjb2RlIG1p
Z2h0IGJlIGJldHRlciBwbGFjZWQgaW4gZHJpdmVycy9ydGMgb3IgCj4gaW5jbHVkZS9saW51eC9y
dGMvY2hpcG5hbWUuCj4gCj4gSW1obyB0aGlzIGRvZXMgbm90IHByZWNsdWRlIHRoZSBwb3NzaWJp
bGl0eSB0byB1c2UgYSBnZW5lcmljIGZyYW1ld29yay4gV2hpbGUKPiB0aGVyZSBjZXJ0YWlubHkg
YXJlIHZhbGlkIHJlYXNvbnMgdG8gaGF2ZSBzZXBhcmF0ZSBkcml2ZXJzIGluIHNvbWUgY2FzZXMg
Cj4gSSBkbyBub3Qgc2VlIG11Y2ggdmFsdWUgaW4gcmV3cml0aW5nIGV2ZXJ5dGhpbmcgYXMgc2Vw
YXJhdGUgZHJpdmVycyB3aGVyZSAKPiB0aGUgZ2VuZXJpYyBmcmFtZXdvcmsgd29ya3Mgd2VsbC4K
CkluZGVlZC4gWW91IGNhbiBoYXZlIGEgd29ya2luZyBSVEMgY2xhc3MgZHJpdmVyIGZvciBsb3Rz
IG9mIGhhcmR3YXJlIGJ5IGp1c3QKd3JpdGluZyBjYS4gMTAwIGxpbmVzIG9mIGNvZGUgb24gdG9w
IG9mIHRoZSBnZW5lcmljIGZyYW1ld29yay4KCldpdGgga2luZCByZWdhcmRzLAoKR2VlcnQgVXl0
dGVyaG9ldmVuClNvZnR3YXJlIEFyY2hpdGVjdAoKU29ueSBUZWNoc29mdCBDZW50cmUgRXVyb3Bl
ClRoZSBDb3Jwb3JhdGUgVmlsbGFnZSDCtyBEYSBWaW5jaWxhYW4gNy1EMSDCtyBCLTE5MzUgWmF2
ZW50ZW0gwrcgQmVsZ2l1bQoKUGhvbmU6ICAgICszMiAoMCkyIDcwMCA4NDUzCkZheDogICAgICAr
MzIgKDApMiA3MDAgODYyMgpFLW1haWw6ICAgR2VlcnQuVXl0dGVyaG9ldmVuQHNvbnljb20uY29t
CkludGVybmV0OiBodHRwOi8vd3d3LnNvbnktZXVyb3BlLmNvbS8KCkEgZGl2aXNpb24gb2YgU29u
eSBFdXJvcGUgKEJlbGdpdW0pIE4uVi4KVkFUIEJFIDA0MTMuODI1LjE2MCDCtyBSUFIgQnJ1c3Nl
bHMKRm9ydGlzIMK3IEJJQyBHRUJBQkVCQiDCtyBJQkFOIEJFNDEyOTMwMzc2ODAwMTAKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTGludXhwcGMtZGV2IG1h
aWxpbmcgbGlzdApMaW51eHBwYy1kZXZAb3psYWJzLm9yZwpodHRwczovL296bGFicy5vcmcvbWFp
bG1hbi9saXN0aW5mby9saW51eHBwYy1kZXY=

Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver

[Alessandro Zummo]

On Mon, 2 Mar 2009 10:54:14 +0100 (CET)
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:

> Indeed. You can have a working RTC class driver for lots of hardware by just
> writing ca. 100 lines of code on top of the generic framework.

 That's true, but we would then have two generic frameworks. And one
 of them will have its code scattered all around the kernel.

 So you either use the old rtc framework, which is perfectly functional,
 or you move to the new rtc lass and write the drivers.

 Layering a generic framework over another generic framework
 is quite a nonsense . 

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver

[Geert Uytterhoeven]

On Mon, 2 Mar 2009, Alessandro Zummo wrote:
> On Mon, 2 Mar 2009 10:54:14 +0100 (CET)
> Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > Indeed. You can have a working RTC class driver for lots of hardwar=
e by just
> > writing ca. 100 lines of code on top of the generic framework.
>=20
>  That's true, but we would then have two generic frameworks. And one
>  of them will have its code scattered all around the kernel.
>=20
>  So you either use the old rtc framework, which is perfectly function=
al,
>  or you move to the new rtc lass and write the drivers.

So I can solve my problem (autoloading the RTC driver on PS3 by udev) b=
y
converting the old genrtc driver into a platform device driver and crea=
ting
platform devices where appropriate.

However, this doesn't solve the distro's problem: as the old RTC framew=
ork
depends on RTC_LIB=3Dn, you cannot have both old and new RTC drivers in=
 your
(single) distro kernel. That's why dmwm2 created drivers/rtc/rtc-ppc.c:=
 Fedora
had to support machines with both old and new RTC drivers. As all of th=
e old
drivers are actually behind the ppc_md.[sg]et_rtc_time() abstraction, t=
his was
very easy.

Hence it's all or nothing, and we have to convert all of them.

drivers/rtc/rtc-generic.c would allow to have a working system without =
old
RTC drivers, until all low-level code has been converted to individual =
RTC
drivers.

>  Layering a generic framework over another generic framework
>  is quite a nonsense .=20

IMHO these two generic frameworks are quite different: [sg]et_rtc_time(=
)
abstracts the low-level RTC hardware interface, while RTC class handles=
 the
interaction with userspace.

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village =B7 Da Vincilaan 7-D1 =B7 B-1935 Zaventem =B7 Bel=
gium

Phone:    +32 (0)2 700 8453
=46ax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 =B7 RPR Brussels
=46ortis =B7 BIC GEBABEBB =B7 IBAN BE41293037680010
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver

[Alessandro Zummo]

On Mon, 2 Mar 2009 11:28:01 +0100 (CET)
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:

> So I can solve my problem (autoloading the RTC driver on PS3 by udev) by
> converting the old genrtc driver into a platform device driver and creating
> platform devices where appropriate.

 yes. btw, if you are building a kernel specific for the PS3, I would
 compile the rtc driver statically, otherwise it won't be available
 early on boot.
 
> However, this doesn't solve the distro's problem: as the old RTC framework
> depends on RTC_LIB=n, you cannot have both old and new RTC drivers in your
> (single) distro kernel. That's why dmwm2 created drivers/rtc/rtc-ppc.c: Fedora
> had to support machines with both old and new RTC drivers. As all of the old
> drivers are actually behind the ppc_md.[sg]et_rtc_time() abstraction, this was
> very easy.

 ok, generic kernel. you will have to load the modules on initrd. no, sadly you
 can't have both of them. you might stick with the old interface or
 convert them all. 

> Hence it's all or nothing, and we have to convert all of them.
> 
> drivers/rtc/rtc-generic.c would allow to have a working system without old
> RTC drivers, until all low-level code has been converted to individual RTC
> drivers.

 I know but I have enough experience to foresee that once a generic over generic
 framework is in place it's very hard to get rid of it because people
 will have no incentives.

 If you really need rtc-generic you can keep using it even if it's 
 not in the kernel, distributions often have their specific
 set of kernel patches.

 But I'd strongly suggest to plan and execute a conversion process.


> >  Layering a generic framework over another generic framework
> >  is quite a nonsense . 
> 
> IMHO these two generic frameworks are quite different: [sg]et_rtc_time()
> abstracts the low-level RTC hardware interface, while RTC class handles the
> interaction with userspace.

 When I wrote it my intention was to make it as an abstraction _between_
 the userspace and the hardware according to the platform/device model.

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver

[Geert Uytterhoeven]

On Mon, 2 Mar 2009, Alessandro Zummo wrote:
> On Mon, 2 Mar 2009 11:28:01 +0100 (CET)
> Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > So I can solve my problem (autoloading the RTC driver on PS3 by udev) by
> > converting the old genrtc driver into a platform device driver and crea=
ting
> > platform devices where appropriate.
> =

>  yes. btw, if you are building a kernel specific for the PS3, I would
>  compile the rtc driver statically, otherwise it won't be available
>  early on boot.
>  =

> > However, this doesn't solve the distro's problem: as the old RTC framew=
ork
> > depends on RTC_LIB=3Dn, you cannot have both old and new RTC drivers in=
 your
> > (single) distro kernel. That's why dmwm2 created drivers/rtc/rtc-ppc.c:=
 Fedora
> > had to support machines with both old and new RTC drivers. As all of th=
e old
> > drivers are actually behind the ppc_md.[sg]et_rtc_time() abstraction, t=
his was
> > very easy.
> =

>  ok, generic kernel. you will have to load the modules on initrd. no, sad=
ly you
>  can't have both of them. you might stick with the old interface or
>  convert them all. =

> =

> > Hence it's all or nothing, and we have to convert all of them.
> > =

> > drivers/rtc/rtc-generic.c would allow to have a working system without =
old
> > RTC drivers, until all low-level code has been converted to individual =
RTC
> > drivers.
> =

>  I know but I have enough experience to foresee that once a generic over =
generic
>  framework is in place it's very hard to get rid of it because people
>  will have no incentives.

I know.

>  If you really need rtc-generic you can keep using it even if it's =

>  not in the kernel, distributions often have their specific
>  set of kernel patches.

rtc-generic is already in the kernel, it's just called rtc-parisc ;-)

>  But I'd strongly suggest to plan and execute a conversion process.

So would you accept a patch series that:
  1. Adds the missing module aliases to rtc-parisc (which is a bugfix),
  2. Moves the platform device creation out of rtc-ppc and into arch-specif=
ic
     code (which is also a bugfix),
  3. Consolidates rtc-parisc and rtc-ppc into rtc-generic (which is a clean=
up),
  4. Makes rtc-generic dependent on PARISC, PPC, and M68K (the existing
     [sg]et_rtc_time() users):
       a. without introducing ARCH_HAS_GENERIC_RTC,
       b. with a big fat warning in the Kconfig comment not relaxing the
          dependencies, as it's supposed to go away.
  4. Converts the PS3 RTC support into a separate driver, called rtc-ps3
     (as a bonus ;-)

? If yes, I'll cook it up.

Other RTC platform support can be converted into separate drivers later.

Thanks!

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village =B7 Da Vincilaan 7-D1 =B7 B-1935 Zaventem =B7 Belgium

Phone:    +32 (0)2 700 8453
Fax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 =B7 RPR Brussels
Fortis =B7 BIC GEBABEBB =B7 IBAN BE41293037680010

Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver

[Alessandro Zummo]

On Tue, 3 Mar 2009 11:41:23 +0100 (CET)
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:

> rtc-generic is already in the kernel, it's just called rtc-parisc ;-)

 Really? I never saw it :)

> >  But I'd strongly suggest to plan and execute a conversion process.
> 
> So would you accept a patch series that:
>   1. Adds the missing module aliases to rtc-parisc (which is a bugfix),
>   2. Moves the platform device creation out of rtc-ppc and into arch-specific
>      code (which is also a bugfix),
>   3. Consolidates rtc-parisc and rtc-ppc into rtc-generic (which is a cleanup),
>   4. Makes rtc-generic dependent on PARISC, PPC, and M68K (the existing
>      [sg]et_rtc_time() users):
>        a. without introducing ARCH_HAS_GENERIC_RTC,
>        b. with a big fat warning in the Kconfig comment not relaxing the
>           dependencies, as it's supposed to go away.
>   4. Converts the PS3 RTC support into a separate driver, called rtc-ps3
>      (as a bonus ;-)
> 
> ? If yes, I'll cook it up.
> 
> Other RTC platform support can be converted into separate drivers later.

 Seems reasonable. But please add a list of users of rtc-generic and information
 about their respective rtc hardware along with some general planning about
 which future driver would cover which users.

 And let's hope this is a beginning :)

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver

[Paul Mundt]

On Tue, Mar 03, 2009 at 11:41:23AM +0100, Geert Uytterhoeven wrote:
> So would you accept a patch series that:
>   1. Adds the missing module aliases to rtc-parisc (which is a bugfix),
>   2. Moves the platform device creation out of rtc-ppc and into arch-specific
>      code (which is also a bugfix),
>   3. Consolidates rtc-parisc and rtc-ppc into rtc-generic (which is a cleanup),
>   4. Makes rtc-generic dependent on PARISC, PPC, and M68K (the existing
>      [sg]et_rtc_time() users):
>        a. without introducing ARCH_HAS_GENERIC_RTC,
>        b. with a big fat warning in the Kconfig comment not relaxing the
>           dependencies, as it's supposed to go away.
>   4. Converts the PS3 RTC support into a separate driver, called rtc-ps3
>      (as a bonus ;-)
> 
> ? If yes, I'll cook it up.
> 
> Other RTC platform support can be converted into separate drivers later.
> 
Did you miss the rtc-firmware thread?

http://groups.google.com/group/rtc-linux/browse_thread/thread/53e8d98966048f66/1d730cb4aa2f85f0?lnk=gst&q=rtc-firmware#1d730cb4aa2f85f0
http://groups.google.com/group/rtc-linux/browse_thread/thread/b3d10115c7e147f2/cb9c1530d9c3a433?lnk=gst&q=rtc-firmware#cb9c1530d9c3a433

Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver

[Geert Uytterhoeven]

On Wed, 4 Mar 2009, Paul Mundt wrote:
> On Tue, Mar 03, 2009 at 11:41:23AM +0100, Geert Uytterhoeven wrote:
> > So would you accept a patch series that:
> >   1. Adds the missing module aliases to rtc-parisc (which is a bugf=
ix),
> >   2. Moves the platform device creation out of rtc-ppc and into arc=
h-specific
> >      code (which is also a bugfix),
> >   3. Consolidates rtc-parisc and rtc-ppc into rtc-generic (which is=
 a cleanup),
> >   4. Makes rtc-generic dependent on PARISC, PPC, and M68K (the exis=
ting
> >      [sg]et_rtc_time() users):
> >        a. without introducing ARCH_HAS_GENERIC_RTC,
> >        b. with a big fat warning in the Kconfig comment not relaxin=
g the
> >           dependencies, as it's supposed to go away.
> >   4. Converts the PS3 RTC support into a separate driver, called rt=
c-ps3
> >      (as a bonus ;-)
> >=20
> > ? If yes, I'll cook it up.
> >=20
> > Other RTC platform support can be converted into separate drivers l=
ater.
> >=20
> Did you miss the rtc-firmware thread?
>=20
> http://groups.google.com/group/rtc-linux/browse_thread/thread/53e8d98=
966048f66/1d730cb4aa2f85f0?lnk=3Dgst&q=3Drtc-firmware#1d730cb4aa2f85f0
> http://groups.google.com/group/rtc-linux/browse_thread/thread/b3d1011=
5c7e147f2/cb9c1530d9c3a433?lnk=3Dgst&q=3Drtc-firmware#cb9c1530d9c3a433

Thanks Paul, I wasn't aware of that thread!

Yes, this is almost the same. The only part I don't agree with is the m=
ove of
the creation of the platform device from arch-specific code to rtc-firm=
ware.c,
as this makes autoloading the driver more difficult.

Seems like everybody but the RTC maintainer has an interest in having a=
n RTC
class driver on top of [gs]et_rtc_time()... ;-)

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village =B7 Da Vincilaan 7-D1 =B7 B-1935 Zaventem =B7 Bel=
gium

Phone:    +32 (0)2 700 8453
=46ax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 =B7 RPR Brussels
=46ortis =B7 BIC GEBABEBB =B7 IBAN BE41293037680010
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver

[Alessandro Zummo]

On Wed, 4 Mar 2009 09:26:29 +0100 (CET)
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:

> Thanks Paul, I wasn't aware of that thread!
> 
> Yes, this is almost the same. The only part I don't agree with is the move of
> the creation of the platform device from arch-specific code to rtc-firmware.c,
> as this makes autoloading the driver more difficult.

 and it's also against a proper implementation of the device/driver model.

> Seems like everybody but the RTC maintainer has an interest in having an RTC
> class driver on top of [gs]et_rtc_time()... ;-)

 That's because everyone is lazy :) 

 Seriously, if you want to handle it in the way we wrote
 in the previous emails, it's ok for me.

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver

[Geert Uytterhoeven]

On Wed, 4 Mar 2009, Alessandro Zummo wrote:
> On Wed, 4 Mar 2009 09:26:29 +0100 (CET)
> Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
>=20
> > Thanks Paul, I wasn't aware of that thread!
> >=20
> > Yes, this is almost the same. The only part I don't agree with is t=
he move of
> > the creation of the platform device from arch-specific code to rtc-=
firmware.c,
> > as this makes autoloading the driver more difficult.
>=20
>  and it's also against a proper implementation of the device/driver m=
odel.
>=20
> > Seems like everybody but the RTC maintainer has an interest in havi=
ng an RTC
> > class driver on top of [gs]et_rtc_time()... ;-)
>=20
>  That's because everyone is lazy :)=20
>=20
>  Seriously, if you want to handle it in the way we wrote
>  in the previous emails, it's ok for me.

OK, I will do so. Thanks!

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village =B7 Da Vincilaan 7-D1 =B7 B-1935 Zaventem =B7 Bel=
gium

Phone:    +32 (0)2 700 8453
=46ax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 =B7 RPR Brussels
=46ortis =B7 BIC GEBABEBB =B7 IBAN BE41293037680010
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver

[Geert Uytterhoeven]

On Wed, 25 Feb 2009, David Woodhouse wrote:
> On Mon, 2009-02-23 at 13:34 +0100, Geert Uytterhoeven wrote:
> > >    my opinion on this kind of stuff is that I want to avoid the l=
ayering
> > >  of implementations under the rtc subsystem. I'd rather prefer th=
at each
> > >  rtc device had its own driver.=20
> > > =20
> > >   I've made error in the past, by accepting such kind of drivers,=
 and
> > >  would like to avoid that it happens again.
> >=20
> > So you want us to kill the ppc_md.[gs]et_rtc_time() [ppc], mach_hwc=
lk() [m68k],
> > mach_gettod() [m68knommu] (and probably a few other) abstractions, =
and move all
> > RTC code out of arch/ into seperate drivers under drivers/rtc/ inst=
ead?
>=20
> That's the ideal... although did we get NTP sync working again yet?
>=20
> The rtc-ppc driver was intended as a short-term workaround so that we
> can enable the generic RTC class (which was required for PA Semi
> Electra, iirc), and still have stuff work on other platforms.

Sure. The only differences between your rtc-ppc driver and rtc-parisc w=
ere:
  - rtc-ppc uses the PPC RTC abstraction (ppc_md.[gs]et_rtc_time()),
    while rtc-parisc uses the genrtc abstraction layer ([gs]et_rtc_time=
()),
    which is shared by several architectures,
  - rtc-ppc has the platform device built-in in the driver, while rtc-p=
arisc
    relies on the creation of the platform device in platform code.

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village =B7 Da Vincilaan 7-D1 =B7 B-1935 Zaventem =B7 Bel=
gium

Phone:    +32 (0)2 700 8453
=46ax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 =B7 RPR Brussels
=46ortis =B7 BIC GEBABEBB =B7 IBAN BE41293037680010
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC 0/5] Generic RTC class driver

[Helge Deller]

Geert Uytterhoeven wrote:
> I've been looking into problems with auto-loading the RTC driver on PPC (more
> specifically on PS3):
>   - The recent "rtc-ppc" RTC class driver is not autoloaded by udev because
>     it's an old style platform driver that contains its own platform device.
>   - The alternative old "genrtc" driver is autoloaded on non-udev systems only
>     because it contains the module alias char-major-10-135. However, it's not
>     a new-style RTC class driver.
> 
> Fortunately there already exists a generic RTC class driver: "rtc-parisc".
> Despite it's name, it's platform-independent, as it's build on top of the RTC
> abstraction used by "genrtc".
> 
> This patch series
>   - adds a missing module alias to rtc-parisc,
>   - renames rtc-parisc to rtc-generic,
>   - converts the architectures that currently have CONFIG_GEN_RTC enabled in
>     their defconfig (m68k, parisc, powerpc) to rtc-generic,
>   - removes the obsolete rtc-ppc driver,
>   - removes the old genrtc driver.
>   
> Note that genrtc may be used on other archictectures as well: at least alpha
> has the required infrastructure ([gs]et_rtc_time()). The Kconfig rules allow
> genrtc to be enabled on several others (cris, h8300, mn10300, um, x86, xtensa).
> 
> Furthermore genrtc and rtc-generic are not 100% userspace compatible:
>   - /dev/rtc provided by genrtc uses a misc character device (10:135),
>   - /dev/rtc provided by rtc-generic uses a dynamic character device.
>   
> So perhaps we don't want to kill gen-rtc yet?
> 
> Any comments are welcomed!

Hi Geert,
FYI, I didn't followed any discussions or changes around the RTC drivers for parisc,
but Dann Frazier did some work on the parisc RTC driver as well.
His patches were merged (not upstream yet!) in Kyle's "rtc-parisc" branch at:
http://git.kernel.org/?p=linux/kernel/git/kyle/parisc-2.6.git;a=shortlog;h=rtc-parisc

Not sure if they conflict (or are in sync) with your patches...

Helge

Re: [PATCH/RFC 0/5] Generic RTC class driver

[Geert Uytterhoeven]

On Tue, 24 Feb 2009, Helge Deller wrote:
> Geert Uytterhoeven wrote:
> > I've been looking into problems with auto-loading the RTC driver on=
 PPC (more
> > specifically on PS3):
> >   - The recent "rtc-ppc" RTC class driver is not autoloaded by udev=
 because
> >     it's an old style platform driver that contains its own platfor=
m device.
> >   - The alternative old "genrtc" driver is autoloaded on non-udev s=
ystems only
> >     because it contains the module alias char-major-10-135. However=
, it's not
> >     a new-style RTC class driver.
> >=20
> > Fortunately there already exists a generic RTC class driver: "rtc-p=
arisc".
> > Despite it's name, it's platform-independent, as it's build on top =
of the RTC
> > abstraction used by "genrtc".
> >=20
> > This patch series
> >   - adds a missing module alias to rtc-parisc,
> >   - renames rtc-parisc to rtc-generic,
> >   - converts the architectures that currently have CONFIG_GEN_RTC e=
nabled in
> >     their defconfig (m68k, parisc, powerpc) to rtc-generic,
> >   - removes the obsolete rtc-ppc driver,
> >   - removes the old genrtc driver.
> >  =20
> > Note that genrtc may be used on other archictectures as well: at le=
ast alpha
> > has the required infrastructure ([gs]et_rtc_time()). The Kconfig ru=
les allow
> > genrtc to be enabled on several others (cris, h8300, mn10300, um, x=
86, xtensa).
> >=20
> > Furthermore genrtc and rtc-generic are not 100% userspace compatibl=
e:
> >   - /dev/rtc provided by genrtc uses a misc character device (10:13=
5),
> >   - /dev/rtc provided by rtc-generic uses a dynamic character devic=
e.
> >  =20
> > So perhaps we don't want to kill gen-rtc yet?
> >=20
> > Any comments are welcomed!
>=20
> Hi Geert,
> FYI, I didn't followed any discussions or changes around the RTC driv=
ers for parisc,
> but Dann Frazier did some work on the parisc RTC driver as well.
> His patches were merged (not upstream yet!) in Kyle's "rtc-parisc" br=
anch at:
> http://git.kernel.org/?p=3Dlinux/kernel/git/kyle/parisc-2.6.git;a=3Ds=
hortlog;h=3Drtc-parisc
>=20
> Not sure if they conflict (or are in sync) with your patches...

Thanks, they provide some nice cleanups.

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village =C2=B7 Da Vincilaan 7-D1 =C2=B7 B-1935 Zaventem =C2=
=B7 Belgium

Phone:    +32 (0)2 700 8453
=46ax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 =C2=B7 RPR Brussels
=46ortis =C2=B7 BIC GEBABEBB =C2=B7 IBAN BE41293037680010
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html