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: state of GEN_RTC vs rtc subsystem

[Richard Zidlicky]

On Wed, Feb 20, 2008 at 10:11:23AM -0600, Kumar Gala wrote:
>  Is the functionality provided by drivers/char/gen_rtc.c completely handled 
>  by the rtc subsystem in drivers/rtc?

they were not designed work parallel at the same. Not sure if there is
ever a valid reason to have both comiled into one kernel image - might be
for some architectures - but when the situation is not handled correctly 
the easiest fix is to make them mutually exclusive.

Richard

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

[J.A. Magallón]

On Wed, 20 Feb 2008 18:03:25 +0100, Alessandro Zummo <alessandro.zummo@towertech.it> 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. 
> 

In fact, you have 3 rtc implementations available.
Please, can you take a look at this question also:

http://marc.info/?l=linux-kernel&m=120355254713965&w=2

>  The only real open issue is related to the ntp synchronization
>  mode and will be solved only when we can get rid of it :)
> 


-- 
J.A. Magallon <jamagallon()ono!com>     \               Software is like sex:
                                         \         It's better when it's free
Mandriva Linux release 2008.1 (Cooker) for i586
Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT

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] state of GEN_RTC vs rtc subsystem

[Rogério Brito]

Hi there.

On Jun 02 2008, Geoff Levand wrote:
> Geoff Levand wrote:
> > 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

This is nice, since I was just going to ask why my config file (put at
http://www.ime.usp.br/~rbrito/debug/config-2.6.26-rc4-4) has

(...)
# CONFIG_PPC_CLOCK is not set
(...)

Even if I force it to yes. When I run a "make oldconfig", it sets back
the PPC_CLOCK to not set. :-(

If anybody can explain what is going on (and how to correct it), I would
kindly appreciate it (and even generate some documentation on the
options, if I understand the issue it well enough).


Regards, Rogério Brito.

-- 
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org

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