* [PATCH/RFC 0/5] Generic RTC class driver @ 2009-02-20 15:46 Geert Uytterhoeven 2009-02-20 15:46 ` [PATCH/RFC 1/5] rtc-parisc: Add missing module alias Geert Uytterhoeven ` (2 more replies) 0 siblings, 3 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2009-02-20 15:46 UTC (permalink / raw) To: Alessandro Zummo Cc: rtc-linux, Kyle McMartin, David Woodhouse, Richard Zidlicky, linux-parisc, linuxppc-dev, linux-m68k, linux-kernel 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! With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · 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 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH/RFC 1/5] rtc-parisc: Add missing module alias 2009-02-20 15:46 [PATCH/RFC 0/5] Generic RTC class driver Geert Uytterhoeven @ 2009-02-20 15:46 ` Geert Uytterhoeven 2009-02-20 15:46 ` [PATCH/RFC 2/5] pa-risc: Rename rtc-parisc to rtc-generic Geert Uytterhoeven 2009-02-20 16:04 ` [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver Alessandro Zummo 2009-02-24 18:46 ` Helge Deller 2 siblings, 1 reply; 34+ messages in thread From: Geert Uytterhoeven @ 2009-02-20 15:46 UTC (permalink / raw) To: Alessandro Zummo Cc: rtc-linux, Kyle McMartin, David Woodhouse, Richard Zidlicky, linux-parisc, linuxppc-dev, linux-m68k, linux-kernel, 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 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH/RFC 2/5] pa-risc: Rename rtc-parisc to rtc-generic 2009-02-20 15:46 ` [PATCH/RFC 1/5] rtc-parisc: Add missing module alias Geert Uytterhoeven @ 2009-02-20 15:46 ` Geert Uytterhoeven 2009-02-20 15:46 ` [PATCH/RFC 3/5] m68k: Enable rtc-generic Geert Uytterhoeven 0 siblings, 1 reply; 34+ messages in thread From: Geert Uytterhoeven @ 2009-02-20 15:46 UTC (permalink / raw) To: Alessandro Zummo Cc: rtc-linux, Kyle McMartin, David Woodhouse, Richard Zidlicky, linux-parisc, linuxppc-dev, linux-m68k, linux-kernel, 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 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH/RFC 3/5] m68k: Enable rtc-generic 2009-02-20 15:46 ` [PATCH/RFC 2/5] pa-risc: Rename rtc-parisc to rtc-generic Geert Uytterhoeven @ 2009-02-20 15:46 ` Geert Uytterhoeven 2009-02-20 15:46 ` [PATCH/RFC 4/5] powerpc: Enable rtc-generic, and kill rtc-ppc Geert Uytterhoeven 0 siblings, 1 reply; 34+ messages in thread From: Geert Uytterhoeven @ 2009-02-20 15:46 UTC (permalink / raw) To: Alessandro Zummo Cc: rtc-linux, Kyle McMartin, David Woodhouse, Richard Zidlicky, linux-parisc, linuxppc-dev, linux-m68k, linux-kernel, 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 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH/RFC 4/5] powerpc: Enable rtc-generic, and kill rtc-ppc 2009-02-20 15:46 ` [PATCH/RFC 3/5] m68k: Enable rtc-generic Geert Uytterhoeven @ 2009-02-20 15:46 ` Geert Uytterhoeven 2009-02-20 15:46 ` [PATCH/RFC 5/5] rtc: Kill genrtc, as all its users have been converted to rtc-generic Geert Uytterhoeven 0 siblings, 1 reply; 34+ messages in thread From: Geert Uytterhoeven @ 2009-02-20 15:46 UTC (permalink / raw) To: Alessandro Zummo Cc: rtc-linux, Kyle McMartin, David Woodhouse, Richard Zidlicky, linux-parisc, linuxppc-dev, linux-m68k, linux-kernel, Geert Uytterhoeven [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 4535 bytes --] 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 generic 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 +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 dividend_low, dr->result_low = ((u64)y << 32) + z; } + +static struct platform_device rtc_generic_dev = { + .name = "rtc-generic", + .id = -1, +}; + +static int __init rtc_init(void) +{ + int ret; + + if (!ppc_md.get_rtc_time) + return -ENODEV; + + 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); 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. -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) += rtc-pcf8583.o obj-$(CONFIG_RTC_DRV_PL030) += rtc-pl030.o obj-$(CONFIG_RTC_DRV_PL031) += rtc-pl031.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 obj-$(CONFIG_RTC_DRV_RS5C313) += 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 - * - * © 2007 Red Hat, Inc. - * - * Author: David Woodhouse <dwmw2@infradead.org> - * - * This program is free software; you can redistribute it and/or modify - * 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 = { - .set_time = ppc_rtc_set_time, - .read_time = 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 = platform_device_register_simple("ppc-rtc", 0, NULL, 0); - if (IS_ERR(ppc_rtc_pdev)) - return PTR_ERR(ppc_rtc_pdev); - - rtc = 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); - -MODULE_LICENSE("GPL"); -MODULE_AUTHOR("David Woodhouse <dwmw2@infradead.org>"); -MODULE_DESCRIPTION("Generic RTC class driver for PowerPC"); -- 1.6.0.4 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH/RFC 5/5] rtc: Kill genrtc, as all its users have been converted to rtc-generic 2009-02-20 15:46 ` [PATCH/RFC 4/5] powerpc: Enable rtc-generic, and kill rtc-ppc Geert Uytterhoeven @ 2009-02-20 15:46 ` Geert Uytterhoeven 0 siblings, 0 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2009-02-20 15:46 UTC (permalink / raw) To: Alessandro Zummo Cc: rtc-linux, Kyle McMartin, David Woodhouse, Richard Zidlicky, linux-parisc, linuxppc-dev, linux-m68k, linux-kernel, 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); - -MODULE_AUTHOR("Richard Zidlicky"); -MODULE_LICENSE("GPL"); -MODULE_ALIAS_MISCDEV(RTC_MINOR); -- 1.6.0.4 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver 2009-02-20 15:46 [PATCH/RFC 0/5] Generic RTC class driver Geert Uytterhoeven 2009-02-20 15:46 ` [PATCH/RFC 1/5] rtc-parisc: Add missing module alias Geert Uytterhoeven @ 2009-02-20 16:04 ` Alessandro Zummo 2009-02-23 12:34 ` Geert Uytterhoeven 2009-02-24 18:46 ` Helge Deller 2 siblings, 1 reply; 34+ messages in thread From: Alessandro Zummo @ 2009-02-20 16:04 UTC (permalink / raw) To: rtc-linux Cc: Geert.Uytterhoeven, Kyle McMartin, David Woodhouse, Richard Zidlicky, linux-parisc, linuxppc-dev, linux-m68k, linux-kernel 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver 2009-02-20 16:04 ` [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver Alessandro Zummo @ 2009-02-23 12:34 ` Geert Uytterhoeven 2009-02-23 15:05 ` [rtc-linux] " Alessandro Zummo 2009-02-24 21:35 ` [rtc-linux] " David Woodhouse 0 siblings, 2 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2009-02-23 12:34 UTC (permalink / raw) To: Alessandro Zummo Cc: rtc-linux, Richard Zidlicky, linux-parisc, Linux Kernel Development, David, Kyle McMartin, Linux/PPC Development, Linux/m68k, Woodhouse, Benjamin Herrenschmidt 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-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. 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 clock 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-cmos.c through the inline function __get_rtc_time() in include/asm-generic/rtc.h (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 point to it. With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · 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 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver 2009-02-23 12:34 ` Geert Uytterhoeven @ 2009-02-23 15:05 ` Alessandro Zummo 2009-02-24 17:56 ` Geert Uytterhoeven 2009-02-24 21:35 ` [rtc-linux] " David Woodhouse 1 sibling, 1 reply; 34+ messages in thread From: Alessandro Zummo @ 2009-02-23 15:05 UTC (permalink / raw) To: rtc-linux Cc: Geert.Uytterhoeven, Richard Zidlicky, linux-parisc, Linux Kernel Development, David, Kyle McMartin, Linux/PPC Development, Linux/m68k, Woodhouse, Benjamin Herrenschmidt 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver 2009-02-23 15:05 ` [rtc-linux] " Alessandro Zummo @ 2009-02-24 17:56 ` Geert Uytterhoeven 2009-02-24 18:37 ` Alessandro Zummo 0 siblings, 1 reply; 34+ messages in thread From: Geert Uytterhoeven @ 2009-02-24 17:56 UTC (permalink / raw) To: Alessandro Zummo Cc: rtc-linux, Richard Zidlicky, linux-parisc, Linux Kernel Development, David, Kyle McMartin, Linux/PPC Development, Linux/m68k, Woodhouse, Benjamin Herrenschmidt 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 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. 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. 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. >From 641412e4e638d00c8821c2d9b38e02727821a203 Mon Sep 17 00:00:00 2001 From: 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; +/* os area */ +u64 ps3_os_area_get_rtc_diff(void); +void ps3_os_area_set_rtc_diff(u64 rtc_diff); + /* kernel debug routines */ int ps3_debug_setup_dabr(u64 address, unsigned int dabr_flags); diff --git a/arch/powerpc/platforms/ps3/os-area.c b/arch/powerpc/platforms/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); /** * 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); /** * ps3_os_area_get_av_multi_out - Returns the default video mode. diff --git a/arch/powerpc/platforms/ps3/platform.h b/arch/powerpc/platforms/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); 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); /* spu */ diff --git a/arch/powerpc/platforms/ps3/setup.c b/arch/powerpc/platforms/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 = ps3_init_IRQ, .panic = ps3_panic, .get_boot_time = ps3_get_boot_time, - .set_rtc_time = ps3_set_rtc_time, - .get_rtc_time = ps3_get_rtc_time, .set_dabr = ps3_set_dabr, .calibrate_decr = ps3_calibrate_decr, .progress = 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 @@ */ #include <linux/kernel.h> +#include <linux/platform_device.h> #include <asm/rtc.h> #include <asm/lv1call.h> @@ -74,23 +75,19 @@ static u64 read_rtc(void) return rtc_val; } -int ps3_set_rtc_time(struct rtc_time *tm) +unsigned long __init ps3_get_boot_time(void) { - u64 now = 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(); } -void ps3_get_rtc_time(struct rtc_time *tm) -{ - to_tm(read_rtc() + ps3_os_area_get_rtc_diff(), tm); - tm->tm_year -= 1900; - tm->tm_mon -= 1; -} +static struct platform_device rtc_ps3_dev = { + .name = "rtc-ps3", + .id = -1, +}; -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. +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) += rtc-vr41xx.o obj-$(CONFIG_RTC_DRV_WM8350) += rtc-wm8350.o obj-$(CONFIG_RTC_DRV_X1205) += rtc-x1205.o obj-$(CONFIG_RTC_DRV_PCF50633) += rtc-pcf50633.o +obj-$(CONFIG_RTC_DRV_PS3) += 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 modify + * it under the terms of the GNU General Public License as published by + * 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 = 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 -= 1900; + tm->tm_mon -= 1; + return 0; +} + +static int ps3_set_time(struct device *dev, struct rtc_time *tm) +{ + u64 now = 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 = { + .read_time = ps3_get_time, + .set_time = ps3_set_time, +}; + +static int __devinit ps3_rtc_probe(struct platform_device *dev) +{ + struct rtc_device *rtc; + + rtc = 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 = { + .driver = { + .name = "rtc-ps3", + .owner = THIS_MODULE, + }, + .probe = ps3_rtc_probe, + .remove = __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"); -- 1.6.0.4 With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · 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 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver 2009-02-24 17:56 ` Geert Uytterhoeven @ 2009-02-24 18:37 ` Alessandro Zummo 2009-02-25 1:14 ` Brad Boyer 0 siblings, 1 reply; 34+ messages in thread From: Alessandro Zummo @ 2009-02-24 18:37 UTC (permalink / raw) To: rtc-linux Cc: Geert.Uytterhoeven, Richard Zidlicky, linux-parisc, Linux Kernel Development, David, Kyle McMartin, Linux/PPC Development, Linux/m68k, Woodhouse, Benjamin Herrenschmidt 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver 2009-02-24 18:37 ` Alessandro Zummo @ 2009-02-25 1:14 ` Brad Boyer 2009-02-25 9:58 ` Geert Uytterhoeven 0 siblings, 1 reply; 34+ messages in thread From: Brad Boyer @ 2009-02-25 1:14 UTC (permalink / raw) To: Alessandro Zummo Cc: rtc-linux, Geert.Uytterhoeven, Richard Zidlicky, linux-parisc, Linux Kernel Development, David, Kyle McMartin, Linux/PPC Development, Linux/m68k, Woodhouse, Benjamin Herrenschmidt 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver 2009-02-25 1:14 ` Brad Boyer @ 2009-02-25 9:58 ` Geert Uytterhoeven 0 siblings, 0 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2009-02-25 9:58 UTC (permalink / raw) To: Brad Boyer Cc: Alessandro Zummo, Richard Zidlicky, rtc-linux, linux-parisc, David, Linux Kernel Development, Kyle McMartin, Linux/PPC Development, Linux/m68k, Woodhouse 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 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 Yeah, on Mac/m68k the RTC is usually handled by a chip that does lots of 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 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. Many embedded powerpc boards already have RTC class drivers under drivers/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 · Da Vincilaan 7-D1 · B-1935 Zaventem · 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 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver 2009-02-23 12:34 ` Geert Uytterhoeven 2009-02-23 15:05 ` [rtc-linux] " Alessandro Zummo @ 2009-02-24 21:35 ` David Woodhouse 2009-02-24 22:11 ` Alessandro Zummo 2009-02-25 9:54 ` [rtc-linux] " Geert Uytterhoeven 1 sibling, 2 replies; 34+ messages in thread From: David Woodhouse @ 2009-02-24 21:35 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Alessandro Zummo, rtc-linux, Richard Zidlicky, linux-parisc, Linux Kernel Development, David, Kyle McMartin, Linux/PPC Development, Linux/m68k, Benjamin Herrenschmidt 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver 2009-02-24 21:35 ` [rtc-linux] " David Woodhouse @ 2009-02-24 22:11 ` Alessandro Zummo 2009-02-24 22:32 ` David Woodhouse 2009-02-25 9:54 ` [rtc-linux] " Geert Uytterhoeven 1 sibling, 1 reply; 34+ messages in thread From: Alessandro Zummo @ 2009-02-24 22:11 UTC (permalink / raw) To: David Woodhouse Cc: Geert Uytterhoeven, rtc-linux, Richard Zidlicky, linux-parisc, Linux Kernel Development, David, Kyle McMartin, Linux/PPC Development, Linux/m68k, Benjamin Herrenschmidt 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver 2009-02-24 22:11 ` Alessandro Zummo @ 2009-02-24 22:32 ` David Woodhouse 2009-02-25 10:00 ` Geert Uytterhoeven 0 siblings, 1 reply; 34+ messages in thread From: David Woodhouse @ 2009-02-24 22:32 UTC (permalink / raw) To: Alessandro Zummo Cc: Geert Uytterhoeven, rtc-linux, Richard Zidlicky, linux-parisc, Linux Kernel Development, David, Kyle McMartin, Linux/PPC Development, Linux/m68k, Benjamin Herrenschmidt 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver 2009-02-24 22:32 ` David Woodhouse @ 2009-02-25 10:00 ` Geert Uytterhoeven 2009-02-25 10:18 ` [rtc-linux] " Alessandro Zummo 0 siblings, 1 reply; 34+ messages in thread From: Geert Uytterhoeven @ 2009-02-25 10:00 UTC (permalink / raw) To: David Woodhouse Cc: Alessandro Zummo, rtc-linux, Richard Zidlicky, linux-parisc, Linux Kernel Development, David, Kyle McMartin, Linux/PPC Development, Linux/m68k, Benjamin Herrenschmidt 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: > > > > > > 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. 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? ;-) With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · 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 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver 2009-02-25 10:00 ` Geert Uytterhoeven @ 2009-02-25 10:18 ` Alessandro Zummo 2009-02-27 17:17 ` Maciej W. Rozycki 2009-02-27 18:55 ` Richard Zidlicky 0 siblings, 2 replies; 34+ messages in thread From: Alessandro Zummo @ 2009-02-25 10:18 UTC (permalink / raw) To: rtc-linux Cc: Geert.Uytterhoeven, David Woodhouse, Richard Zidlicky, linux-parisc, Linux Kernel Development, David, Kyle McMartin, Linux/PPC Development, Linux/m68k, Benjamin Herrenschmidt 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver 2009-02-25 10:18 ` [rtc-linux] " Alessandro Zummo @ 2009-02-27 17:17 ` Maciej W. Rozycki 2009-02-27 17:19 ` Alessandro Zummo 2009-02-27 18:55 ` Richard Zidlicky 1 sibling, 1 reply; 34+ messages in thread From: Maciej W. Rozycki @ 2009-02-27 17:17 UTC (permalink / raw) To: Alessandro Zummo Cc: rtc-linux, Geert.Uytterhoeven, David Woodhouse, Richard Zidlicky, linux-parisc, Linux Kernel Development, David, Kyle McMartin, Linux/PPC Development, Linux/m68k, Benjamin Herrenschmidt 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver 2009-02-27 17:17 ` Maciej W. Rozycki @ 2009-02-27 17:19 ` Alessandro Zummo 0 siblings, 0 replies; 34+ messages in thread From: Alessandro Zummo @ 2009-02-27 17:19 UTC (permalink / raw) To: Maciej W. Rozycki Cc: rtc-linux, Geert.Uytterhoeven, David Woodhouse, Richard Zidlicky, linux-parisc, Linux Kernel Development, David, Kyle McMartin, Linux/PPC Development, Linux/m68k, Benjamin Herrenschmidt 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver 2009-02-25 10:18 ` [rtc-linux] " Alessandro Zummo 2009-02-27 17:17 ` Maciej W. Rozycki @ 2009-02-27 18:55 ` Richard Zidlicky 2009-03-02 9:54 ` Geert Uytterhoeven 1 sibling, 1 reply; 34+ messages in thread From: Richard Zidlicky @ 2009-02-27 18:55 UTC (permalink / raw) To: Alessandro Zummo Cc: rtc-linux, Geert.Uytterhoeven, David Woodhouse, linux-parisc, Linux Kernel Development, David, Kyle McMartin, Linux/PPC Development, Linux/m68k, Benjamin Herrenschmidt 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver 2009-02-27 18:55 ` Richard Zidlicky @ 2009-03-02 9:54 ` Geert Uytterhoeven 2009-03-02 10:03 ` Alessandro Zummo 0 siblings, 1 reply; 34+ messages in thread From: Geert Uytterhoeven @ 2009-03-02 9:54 UTC (permalink / raw) To: Richard Zidlicky Cc: Alessandro Zummo, rtc-linux, David Woodhouse, linux-parisc, Linux Kernel Development, David, Kyle McMartin, Linux/PPC Development, Linux/m68k, Benjamin Herrenschmidt On Fri, 27 Feb 2009, Richard Zidlicky wrote: > 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. What about CONFIG_RTC_INTF_DEV_UIE_EMUL for RTC class devices? > 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. 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. With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · 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 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver 2009-03-02 9:54 ` Geert Uytterhoeven @ 2009-03-02 10:03 ` Alessandro Zummo 2009-03-02 10:28 ` Geert Uytterhoeven 0 siblings, 1 reply; 34+ messages in thread From: Alessandro Zummo @ 2009-03-02 10:03 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Richard Zidlicky, rtc-linux, David Woodhouse, linux-parisc, Linux Kernel Development, David, Kyle McMartin, Linux/PPC Development, Linux/m68k, Benjamin Herrenschmidt 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver 2009-03-02 10:03 ` Alessandro Zummo @ 2009-03-02 10:28 ` Geert Uytterhoeven 2009-03-02 11:09 ` Alessandro Zummo 0 siblings, 1 reply; 34+ messages in thread From: Geert Uytterhoeven @ 2009-03-02 10:28 UTC (permalink / raw) To: Alessandro Zummo Cc: Richard Zidlicky, rtc-linux, David Woodhouse, linux-parisc, Linux Kernel Development, David, Kyle McMartin, Linux/PPC Development, Linux/m68k, Benjamin Herrenschmidt 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 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. 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. 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. 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 . 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 · Da Vincilaan 7-D1 · B-1935 Zaventem · 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 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver 2009-03-02 10:28 ` Geert Uytterhoeven @ 2009-03-02 11:09 ` Alessandro Zummo 2009-03-03 10:41 ` Geert Uytterhoeven 0 siblings, 1 reply; 34+ messages in thread From: Alessandro Zummo @ 2009-03-02 11:09 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Richard Zidlicky, rtc-linux, David Woodhouse, linux-parisc, Linux Kernel Development, Kyle McMartin, Linux/PPC Development, Linux/m68k, Benjamin Herrenschmidt 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver 2009-03-02 11:09 ` Alessandro Zummo @ 2009-03-03 10:41 ` Geert Uytterhoeven 2009-03-03 13:53 ` Alessandro Zummo 2009-03-03 19:06 ` Paul Mundt 0 siblings, 2 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2009-03-03 10:41 UTC (permalink / raw) To: Alessandro Zummo Cc: Richard Zidlicky, rtc-linux, David Woodhouse, linux-parisc, Linux Kernel Development, Kyle McMartin, Linux/PPC Development, Linux/m68k, Benjamin Herrenschmidt 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 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. 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-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. Thanks! With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · 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 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver 2009-03-03 10:41 ` Geert Uytterhoeven @ 2009-03-03 13:53 ` Alessandro Zummo 2009-03-03 19:06 ` Paul Mundt 1 sibling, 0 replies; 34+ messages in thread From: Alessandro Zummo @ 2009-03-03 13:53 UTC (permalink / raw) To: rtc-linux Cc: Geert.Uytterhoeven, Richard Zidlicky, David Woodhouse, linux-parisc, Linux Kernel Development, Kyle McMartin, Linux/PPC Development, Linux/m68k, Benjamin Herrenschmidt 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver 2009-03-03 10:41 ` Geert Uytterhoeven 2009-03-03 13:53 ` Alessandro Zummo @ 2009-03-03 19:06 ` Paul Mundt 2009-03-04 8:26 ` Geert Uytterhoeven 1 sibling, 1 reply; 34+ messages in thread From: Paul Mundt @ 2009-03-03 19:06 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Alessandro Zummo, Richard Zidlicky, rtc-linux, David Woodhouse, linux-parisc, Linux Kernel Development, Kyle McMartin, Linux/PPC Development, Linux/m68k, Benjamin Herrenschmidt 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver 2009-03-03 19:06 ` Paul Mundt @ 2009-03-04 8:26 ` Geert Uytterhoeven 2009-03-04 12:47 ` Alessandro Zummo 0 siblings, 1 reply; 34+ messages in thread From: Geert Uytterhoeven @ 2009-03-04 8:26 UTC (permalink / raw) To: Paul Mundt Cc: Linux/m68k, Alessandro Zummo, Richard Zidlicky, rtc-linux, linux-parisc, Linux Kernel Development, Kyle McMartin, Linux/PPC Development, David Woodhouse 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 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 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. Seems like everybody but the RTC maintainer has an interest in having an RTC class driver on top of [gs]et_rtc_time()... ;-) With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · 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 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver 2009-03-04 8:26 ` Geert Uytterhoeven @ 2009-03-04 12:47 ` Alessandro Zummo 2009-03-04 12:51 ` Geert Uytterhoeven 0 siblings, 1 reply; 34+ messages in thread From: Alessandro Zummo @ 2009-03-04 12:47 UTC (permalink / raw) To: rtc-linux Cc: Geert.Uytterhoeven, Paul Mundt, Linux/m68k, Richard Zidlicky, linux-parisc, Linux Kernel Development, Kyle McMartin, Linux/PPC Development, David Woodhouse 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver 2009-03-04 12:47 ` Alessandro Zummo @ 2009-03-04 12:51 ` Geert Uytterhoeven 0 siblings, 0 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2009-03-04 12:51 UTC (permalink / raw) To: Alessandro Zummo Cc: rtc-linux, Paul Mundt, Linux/m68k, Richard Zidlicky, linux-parisc, Linux Kernel Development, Kyle McMartin, Linux/PPC Development, David Woodhouse 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: > > > 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. OK, I will do so. Thanks! With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · 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 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver 2009-02-24 21:35 ` [rtc-linux] " David Woodhouse 2009-02-24 22:11 ` Alessandro Zummo @ 2009-02-25 9:54 ` Geert Uytterhoeven 1 sibling, 0 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2009-02-25 9:54 UTC (permalink / raw) To: David Woodhouse Cc: Alessandro Zummo, rtc-linux, Richard Zidlicky, linux-parisc, Linux Kernel Development, David, Kyle McMartin, Linux/PPC Development, Linux/m68k, Benjamin Herrenschmidt 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 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. Sure. The only differences between your rtc-ppc driver and rtc-parisc were: - 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-parisc 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 · Da Vincilaan 7-D1 · B-1935 Zaventem · 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 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH/RFC 0/5] Generic RTC class driver 2009-02-20 15:46 [PATCH/RFC 0/5] Generic RTC class driver Geert Uytterhoeven 2009-02-20 15:46 ` [PATCH/RFC 1/5] rtc-parisc: Add missing module alias Geert Uytterhoeven 2009-02-20 16:04 ` [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver Alessandro Zummo @ 2009-02-24 18:46 ` Helge Deller 2009-02-25 9:54 ` Geert Uytterhoeven 2 siblings, 1 reply; 34+ messages in thread From: Helge Deller @ 2009-02-24 18:46 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Alessandro Zummo, rtc-linux, Kyle McMartin, David Woodhouse, Richard Zidlicky, linux-parisc, linuxppc-dev, linux-m68k, linux-kernel, dann frazier 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH/RFC 0/5] Generic RTC class driver 2009-02-24 18:46 ` Helge Deller @ 2009-02-25 9:54 ` Geert Uytterhoeven 0 siblings, 0 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2009-02-25 9:54 UTC (permalink / raw) To: Helge Deller Cc: Alessandro Zummo, rtc-linux, Kyle McMartin, David Woodhouse, Richard Zidlicky, linux-parisc, linuxppc-dev, linux-m68k, linux-kernel, dann frazier 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 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... Thanks, they provide some nice cleanups. With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · 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 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2009-03-04 12:51 UTC | newest] Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-02-20 15:46 [PATCH/RFC 0/5] Generic RTC class driver Geert Uytterhoeven 2009-02-20 15:46 ` [PATCH/RFC 1/5] rtc-parisc: Add missing module alias Geert Uytterhoeven 2009-02-20 15:46 ` [PATCH/RFC 2/5] pa-risc: Rename rtc-parisc to rtc-generic Geert Uytterhoeven 2009-02-20 15:46 ` [PATCH/RFC 3/5] m68k: Enable rtc-generic Geert Uytterhoeven 2009-02-20 15:46 ` [PATCH/RFC 4/5] powerpc: Enable rtc-generic, and kill rtc-ppc Geert Uytterhoeven 2009-02-20 15:46 ` [PATCH/RFC 5/5] rtc: Kill genrtc, as all its users have been converted to rtc-generic Geert Uytterhoeven 2009-02-20 16:04 ` [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver Alessandro Zummo 2009-02-23 12:34 ` Geert Uytterhoeven 2009-02-23 15:05 ` [rtc-linux] " Alessandro Zummo 2009-02-24 17:56 ` Geert Uytterhoeven 2009-02-24 18:37 ` Alessandro Zummo 2009-02-25 1:14 ` Brad Boyer 2009-02-25 9:58 ` Geert Uytterhoeven 2009-02-24 21:35 ` [rtc-linux] " David Woodhouse 2009-02-24 22:11 ` Alessandro Zummo 2009-02-24 22:32 ` David Woodhouse 2009-02-25 10:00 ` Geert Uytterhoeven 2009-02-25 10:18 ` [rtc-linux] " Alessandro Zummo 2009-02-27 17:17 ` Maciej W. Rozycki 2009-02-27 17:19 ` Alessandro Zummo 2009-02-27 18:55 ` Richard Zidlicky 2009-03-02 9:54 ` Geert Uytterhoeven 2009-03-02 10:03 ` Alessandro Zummo 2009-03-02 10:28 ` Geert Uytterhoeven 2009-03-02 11:09 ` Alessandro Zummo 2009-03-03 10:41 ` Geert Uytterhoeven 2009-03-03 13:53 ` Alessandro Zummo 2009-03-03 19:06 ` Paul Mundt 2009-03-04 8:26 ` Geert Uytterhoeven 2009-03-04 12:47 ` Alessandro Zummo 2009-03-04 12:51 ` Geert Uytterhoeven 2009-02-25 9:54 ` [rtc-linux] " Geert Uytterhoeven 2009-02-24 18:46 ` Helge Deller 2009-02-25 9:54 ` Geert Uytterhoeven
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).