state of GEN_RTC vs rtc subsystem

state of GEN_RTC vs rtc subsystem

[Kumar Gala]

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

Re: [rtc-linux] state of GEN_RTC vs rtc subsystem

[Alessandro Zummo]

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

Re: [rtc-linux] state of GEN_RTC vs rtc subsystem

[woodys]

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

Re: [rtc-linux] Re: state of GEN_RTC vs rtc subsystem

[Alessandro Zummo]

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

Re: [rtc-linux] state of GEN_RTC vs rtc subsystem

[Geoff Levand]

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

Re: [rtc-linux] state of GEN_RTC vs rtc subsystem

[Geoff Levand]

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

Re: [rtc-linux] Re: state of GEN_RTC vs rtc subsystem

[David Woodhouse]

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