* state of GEN_RTC vs rtc subsystem @ 2008-02-20 16:11 Kumar Gala 2008-02-20 17:03 ` [rtc-linux] " Alessandro Zummo 0 siblings, 1 reply; 7+ messages in thread From: Kumar Gala @ 2008-02-20 16:11 UTC (permalink / raw) To: a.zummo; +Cc: linuxppc-dev list, rz, LKML Kernel, rtc-linux Is the functionality provided by drivers/char/gen_rtc.c completely handled by the rtc subsystem in drivers/rtc? I ask for two reasons: 1. should we make it mutually exclusive in Kconfig 2. I've enabled both and get (we'll my defconfig did): proc_dir_entry 'rtc' already registered Call Trace: [df82bd70] [c0006b8c] show_stack+0x3c/0x1b0 (unreliable) [df82bda0] [c00cda48] proc_register+0xf8/0x1a0 [df82bdd0] [c00cdc44] create_proc_entry+0x64/0xf0 [df82bdf0] [c024a484] rtc_proc_add_device+0x54/0x90 [df82be00] [c0249048] rtc_device_register+0x1d8/0x220 [df82be40] [c046c0bc] cmos_platform_probe+0x13c/0x3c0 [df82be70] [c01cd524] platform_drv_probe+0x24/0x40 [df82be80] [c01cb15c] driver_probe_device+0xbc/0x200 [df82bea0] [c01cb4ac] __driver_attach+0xcc/0x100 [df82bec0] [c01ca0dc] bus_for_each_dev+0x5c/0xa0 [df82bef0] [c01caf44] driver_attach+0x24/0x40 [df82bf00] [c01cad70] bus_add_driver+0x1f0/0x270 [df82bf20] [c01cb778] driver_register+0x48/0x140 [df82bf40] [c01cd948] platform_driver_register+0x98/0xb0 [df82bf50] [c01cd97c] platform_driver_probe+0x1c/0x90 [df82bf60] [c046bf70] cmos_init+0x20/0x30 [df82bf70] [c0450218] kernel_init+0xa8/0x2b0 [df82bff0] [c000e638] kernel_thread+0x44/0x60 rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0 - k ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [rtc-linux] state of GEN_RTC vs rtc subsystem 2008-02-20 16:11 state of GEN_RTC vs rtc subsystem Kumar Gala @ 2008-02-20 17:03 ` Alessandro Zummo 2008-02-20 20:37 ` woodys 2008-05-30 22:45 ` [rtc-linux] " Geoff Levand 0 siblings, 2 replies; 7+ messages in thread From: Alessandro Zummo @ 2008-02-20 17:03 UTC (permalink / raw) To: rtc-linux; +Cc: linuxppc-dev list, rz, LKML Kernel On Wed, 20 Feb 2008 10:11:23 -0600 Kumar Gala <galak@kernel•crashing.org> wrote: > > Is the functionality provided by drivers/char/gen_rtc.c completely > handled by the rtc subsystem in drivers/rtc? > > I ask for two reasons: > 1. should we make it mutually exclusive in Kconfig > 2. I've enabled both and get (we'll my defconfig did): They shouldn't be enabled at once. I think a patch for Kconfig has been recently submitted to give a warning in such a case. rtc-cmos should be able to handle the vast majority of x86 rtcs out there. The only real open issue is related to the ntp synchronization mode and will be solved only when we can get rid of it :) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [rtc-linux] state of GEN_RTC vs rtc subsystem 2008-02-20 17:03 ` [rtc-linux] " Alessandro Zummo @ 2008-02-20 20:37 ` woodys 2008-02-21 0:14 ` [rtc-linux] " Alessandro Zummo 2008-05-30 22:45 ` [rtc-linux] " Geoff Levand 1 sibling, 1 reply; 7+ messages in thread From: woodys @ 2008-02-20 20:37 UTC (permalink / raw) To: Alessandro Zummo; +Cc: linuxppc-dev list, rz, rtc-linux, LKML Kernel Alessandro Zummo wrote: > On Wed, 20 Feb 2008 10:11:23 -0600 > Kumar Gala <galak@kernel•crashing.org> wrote: > > >> Is the functionality provided by drivers/char/gen_rtc.c completely >> handled by the rtc subsystem in drivers/rtc? >> >> I ask for two reasons: >> 1. should we make it mutually exclusive in Kconfig >> 2. I've enabled both and get (we'll my defconfig did): >> > > They shouldn't be enabled at once. I think a patch > for Kconfig has been recently submitted to give a warning > in such a case. > > rtc-cmos should be able to handle the vast majority of x86 > rtcs out there. > > The only real open issue is related to the ntp synchronization > mode and will be solved only when we can get rid of it :) > > On ARM genrtc has been arbitrary disabled in Kconfig circa 2.6.19 and the change to rtc_cmos it is not 100% transparent (ARM Netwinder, Debian). If I want to use a current (Etch) hwclock binary - I need genrtc with /dev/rtc at 10,135, however new rtc_cmos creates /dev/rtc0 at 254,0. As a result on new kernels hwclock claims that it is not able to access hardware. However upgrading the util-linux package will (sometime in the "unstable" future) solve it, so it is not completely broken... Still, at the moment - genrtc seems to be a better solution... Just my $.02... Woody Suwalski ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [rtc-linux] Re: state of GEN_RTC vs rtc subsystem 2008-02-20 20:37 ` woodys @ 2008-02-21 0:14 ` Alessandro Zummo 0 siblings, 0 replies; 7+ messages in thread From: Alessandro Zummo @ 2008-02-21 0:14 UTC (permalink / raw) To: rtc-linux; +Cc: linuxppc-dev list, LKML Kernel, rz, woodys On Wed, 20 Feb 2008 15:37:28 -0500 woodys <woodys@xandros•com> wrote: > On ARM genrtc has been arbitrary disabled in Kconfig circa 2.6.19 and > the change to rtc_cmos it is not 100% transparent (ARM Netwinder, Debian). > If I want to use a current (Etch) hwclock binary - I need genrtc with > /dev/rtc at 10,135, however new rtc_cmos creates /dev/rtc0 at 254,0. > As a result on new kernels hwclock claims that it is not able to access > hardware. > > However upgrading the util-linux package will (sometime in the > "unstable" future) solve it, so it is not completely broken... Still, at > the moment - genrtc seems to be a better solution... Strange that it has been disabled, I used to keep an eye to avoid touching anything outside of drivers/rtc . the rtc subsystem creates the device dynamically, you shouldn't count on having 254,0. I would eventually ack a patch that adds /dev/rtc at 10,135 as an alias for /dev/rtc0. however the best solution would be to upgrade hwclock. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [rtc-linux] state of GEN_RTC vs rtc subsystem 2008-02-20 17:03 ` [rtc-linux] " Alessandro Zummo 2008-02-20 20:37 ` woodys @ 2008-05-30 22:45 ` Geoff Levand 2008-06-02 22:27 ` Geoff Levand 1 sibling, 1 reply; 7+ messages in thread From: Geoff Levand @ 2008-05-30 22:45 UTC (permalink / raw) To: Alessandro Zummo; +Cc: linuxppc-dev list, rz, LKML Kernel, rtc-linux Alessandro Zummo wrote: > On Wed, 20 Feb 2008 10:11:23 -0600 > Kumar Gala <galak@kernel•crashing.org> wrote: > >> >> Is the functionality provided by drivers/char/gen_rtc.c completely >> handled by the rtc subsystem in drivers/rtc? >> >> I ask for two reasons: >> 1. should we make it mutually exclusive in Kconfig >> 2. I've enabled both and get (we'll my defconfig did): > > They shouldn't be enabled at once. I think a patch > for Kconfig has been recently submitted to give a warning > in such a case. > > rtc-cmos should be able to handle the vast majority of x86 > rtcs out there. gen_rtc was hooked up to the powerpc platform ppc_md.set_rtc_time and ppc_md.get_rtc_time via the arch specific get_rtc_time() and set_rtc_time() routines. >From what I can tell, those generic rtc routines the powerpc arch provides are not properly hooked into the new rtc subsystem. This causes problems for multi-platform builds where some platforms must use gen_rtc, and some must the new rtc subsytem. -Geoff ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [rtc-linux] state of GEN_RTC vs rtc subsystem 2008-05-30 22:45 ` [rtc-linux] " Geoff Levand @ 2008-06-02 22:27 ` Geoff Levand 2008-06-07 9:46 ` [rtc-linux] " David Woodhouse 0 siblings, 1 reply; 7+ messages in thread From: Geoff Levand @ 2008-06-02 22:27 UTC (permalink / raw) To: Alessandro Zummo; +Cc: linuxppc-dev list, rz, LKML Kernel, rtc-linux Geoff Levand wrote: > Alessandro Zummo wrote: >> On Wed, 20 Feb 2008 10:11:23 -0600 >> Kumar Gala <galak@kernel•crashing.org> wrote: >> >>> >>> Is the functionality provided by drivers/char/gen_rtc.c completely >>> handled by the rtc subsystem in drivers/rtc? >>> >>> I ask for two reasons: >>> 1. should we make it mutually exclusive in Kconfig >>> 2. I've enabled both and get (we'll my defconfig did): >> >> They shouldn't be enabled at once. I think a patch >> for Kconfig has been recently submitted to give a warning >> in such a case. >> >> rtc-cmos should be able to handle the vast majority of x86 >> rtcs out there. > > gen_rtc was hooked up to the powerpc platform > ppc_md.set_rtc_time and ppc_md.get_rtc_time via the arch > specific get_rtc_time() and set_rtc_time() routines. > >>From what I can tell, those generic rtc routines the powerpc > arch provides are not properly hooked into the new rtc subsystem. > This causes problems for multi-platform builds where some platforms > must use gen_rtc, and some must the new rtc subsytem. Just to follow up, I found that David Woodhouse has submitted a patch which does this: http://patchwork.ozlabs.org/linuxppc/patch?id=18139 -Geoff ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [rtc-linux] Re: state of GEN_RTC vs rtc subsystem 2008-06-02 22:27 ` Geoff Levand @ 2008-06-07 9:46 ` David Woodhouse 0 siblings, 0 replies; 7+ messages in thread From: David Woodhouse @ 2008-06-07 9:46 UTC (permalink / raw) To: rtc-linux; +Cc: linuxppc-dev list, Alessandro Zummo, rz, LKML Kernel On Mon, 2008-06-02 at 15:27 -0700, Geoff Levand wrote: > > Just to follow up, I found that David Woodhouse has submitted > a patch which does this: > > http://patchwork.ozlabs.org/linuxppc/patch?id=18139 It's merged now: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=aabe1885 -- dwmw2 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2008-06-07 9:46 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-02-20 16:11 state of GEN_RTC vs rtc subsystem Kumar Gala 2008-02-20 17:03 ` [rtc-linux] " Alessandro Zummo 2008-02-20 20:37 ` woodys 2008-02-21 0:14 ` [rtc-linux] " Alessandro Zummo 2008-05-30 22:45 ` [rtc-linux] " Geoff Levand 2008-06-02 22:27 ` Geoff Levand 2008-06-07 9:46 ` [rtc-linux] " David Woodhouse
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox