Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver
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.uytterhoe...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver
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 dw...@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.uytterhoe...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver
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 WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver
On Wed, 25 Feb 2009 06:35:27 +0900 David Woodhouse dw...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver
On Tue, 2009-02-24 at 23:11 +0100, Alessandro Zummo wrote: On Wed, 25 Feb 2009 06:35:27 +0900 David Woodhouse dw...@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 WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver
On Fri, 20 Feb 2009, Alessandro Zummo wrote: On Fri, 20 Feb 2009 16:46:44 +0100 Geert Uytterhoeven geert.uytterhoe...@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.uytterhoe...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver
On Fri, 20 Feb 2009 16:46:44 +0100 Geert Uytterhoeven geert.uytterhoe...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
