All of lore.kernel.org
 help / color / mirror / Atom feed
From: woodys <woodys@xandros.com>
To: Alessandro Zummo <alessandro.zummo@towertech.it>
Cc: linuxppc-dev list <linuxppc-dev@ozlabs.org>,
	rz@linux-m68k.org, rtc-linux@googlegroups.com,
	LKML Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [rtc-linux] state of GEN_RTC vs rtc subsystem
Date: Wed, 20 Feb 2008 15:37:28 -0500	[thread overview]
Message-ID: <47BC8F88.80502@xandros.com> (raw)
In-Reply-To: <20080220180325.46446675@i1501.lan.towertech.it>

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

WARNING: multiple messages have this Message-ID (diff)
From: woodys <woodys@xandros.com>
To: Alessandro Zummo <alessandro.zummo@towertech.it>
Cc: rtc-linux@googlegroups.com, galak@kernel.crashing.org,
	LKML Kernel <linux-kernel@vger.kernel.org>,
	linuxppc-dev list <linuxppc-dev@ozlabs.org>,
	rz@linux-m68k.org
Subject: Re: [rtc-linux] state of GEN_RTC vs rtc subsystem
Date: Wed, 20 Feb 2008 15:37:28 -0500	[thread overview]
Message-ID: <47BC8F88.80502@xandros.com> (raw)
In-Reply-To: <20080220180325.46446675@i1501.lan.towertech.it>

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





  reply	other threads:[~2008-02-20 20:58 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-20 16:11 state of GEN_RTC vs rtc subsystem Kumar Gala
2008-02-20 16:11 ` Kumar Gala
2008-02-20 17:03 ` [rtc-linux] " Alessandro Zummo
2008-02-20 17:03   ` Alessandro Zummo
2008-02-20 20:37   ` woodys [this message]
2008-02-20 20:37     ` woodys
2008-02-21  0:14     ` [rtc-linux] " Alessandro Zummo
2008-02-21  0:14       ` Alessandro Zummo
2008-02-22  7:47   ` [rtc-linux] " J.A. Magallón
2008-05-30 22:45   ` Geoff Levand
2008-05-30 22:45     ` Geoff Levand
2008-06-02 22:27     ` Geoff Levand
2008-06-02 22:27       ` Geoff Levand
2008-06-07  6:38       ` Rogério Brito
2008-06-07  9:46       ` [rtc-linux] " David Woodhouse
2008-06-07  9:46         ` David Woodhouse
2008-02-21  9:26 ` Richard Zidlicky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47BC8F88.80502@xandros.com \
    --to=woodys@xandros.com \
    --cc=alessandro.zummo@towertech.it \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=rtc-linux@googlegroups.com \
    --cc=rz@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.