IA-64 does not have a directly accessible real-time clock. As far as
I know the only method to access the clock on this platform is to go
through EFI (Extensible Firmware Interface, like a BIOS), which is
handled by efirtc.c.
genrtc can be configured on for this platform but does not build
(because there is no asm/rtc.h), and anyhow it is never likely to be
useful. I suggest that it should be disabled in Kconfig, as rtc.c
already is.
Perhaps other platforms that don't support it should be turned off
too.
--- linux-2.6.0test2-ia64/drivers/char/Kconfig.~1~ 2003-07-11 06:04:38.000000000 +1000
+++ linux-2.6.0test2-ia64/drivers/char/Kconfig 2003-08-06 17:35:08.000000000 +1000
@@ -797,7 +797,7 @@ config RTC
config GEN_RTC
tristate "Generic /dev/rtc emulation"
- depends on RTC!=y
+ depends on RTC!=y && !IA64
---help---
If you say Y here and create a character special file /dev/rtc with
major number 10 and minor number 135 using mknod ("man mknod"), you
Regards,
--
Martin
On Wed, Aug 06, 2003 at 05:43:13PM +1000, Martin Pool wrote:
> IA-64 does not have a directly accessible real-time clock. As far as
> I know the only method to access the clock on this platform is to go
> through EFI (Extensible Firmware Interface, like a BIOS), which is
> handled by efirtc.c.
I think that this is the wrong approach. genrtc allows the platform to
specify how the rtc is to be accessed. Therefore, efirtc.c could quite
probably be removed in favor of genrtc.c, if the proper read/write
functions are provided, and if genrtc gets alarm code, which is
something others (rmk at least) have asked for.
--
Tom Rini
http://gate.crashing.org/~trini/
On Wed, 06 Aug 2003 09:37:53 -0700, Tom Rini wrote:
> I think that this is the wrong approach. genrtc allows the platform to
> specify how the rtc is to be accessed. Therefore, efirtc.c could quite
> probably be removed in favor of genrtc.c, if the proper read/write
> functions are provided, and if genrtc gets alarm code, which is something
> others (rmk at least) have asked for.
Yes, since EFI is the only method for this platform it should probably
be the platform's only implementation of genrtc.
At the moment it is a bit confusing because "generic RTC" sounds like
something that ought to work on any platform, when of course it does
not. So if the changes to genrtc would be large, perhaps it would be
better to just fix Kconfig for now...
Do you think a patch to refactor efirtc into genrtc would be accepted?
--
Martin
On Thu, Aug 07, 2003 at 11:18:25AM +1000, Martin Pool wrote:
> On Wed, 06 Aug 2003 09:37:53 -0700, Tom Rini wrote:
>
> > I think that this is the wrong approach. genrtc allows the platform to
> > specify how the rtc is to be accessed. Therefore, efirtc.c could quite
> > probably be removed in favor of genrtc.c, if the proper read/write
> > functions are provided, and if genrtc gets alarm code, which is something
> > others (rmk at least) have asked for.
>
> Yes, since EFI is the only method for this platform it should probably
> be the platform's only implementation of genrtc.
>
> At the moment it is a bit confusing because "generic RTC" sounds like
> something that ought to work on any platform, when of course it does
> not. So if the changes to genrtc would be large, perhaps it would be
> better to just fix Kconfig for now...
Well, it's a "generic RTC" driver because it lets the arch decide the
arch-specific things, like how to access an RTC. It really should be
able to work on any arch that has an RTC.
> Do you think a patch to refactor efirtc into genrtc would be accepted?
I don't know the EFI code as well as you do, but after skimming it I'm
lost as to what would need to be added to the genrtc driver, other than
alarm support (which is greatly wanted!).
--
Tom Rini
http://gate.crashing.org/~trini/