[RFC] RTC policy questions

[RFC] RTC policy questions

[Alexander Schulz]

Hello,

I am currently working on porting the linux kernel to
the Shark, a StrongARM based computer (DNARD from digital)
that contains many parts known from PCs.

On the Shark I have to use the (PC-like) RealTimeClock as a
heartbeat source. This has two consequences:

1) No user may be allowed to alter the frequency of
   the RTC interrupt or even turn it off.
   AFAIK the alarm cannot be used, because it uses
   the same irq.
2) I would like to use the set_rtc_irq_bit and
   get_rtc_time functions from drivers/char/rtc.c in
   include/asm-arm/arch-shark/time.h to setup the
   rtc at bootup. That means that they cannot be
   static in rtc.c.

a) I could avoid 2) by duplicating the functions in time.h
   (it seems arch-ebsa285/time.h implements its own setup),
   but I hate duplicating code.
b) I solved 1) by patching rtc.c to exclude the offending
   code if CONFIG_ARCH_SHARK is defined. The only other way
   I can think of would be to have a complete rtc driver
   for the shark but that again would mean duplicating code.

What do you think? Is it ok to patch the rtc.c or would it be
better to duplicate the code? Are there more possible solutions
that I cannot think of?

I am using 2.4.12-ac6-rmk2 at the moment but the problem is
mostly version independent.

Thanks for all comments
   Alexander

Re: [RFC] RTC policy questions

[Tom Rini]

On Sun, Oct 28, 2001 at 05:32:30PM +0100, Alexander Schulz wrote:

> I am currently working on porting the linux kernel to
> the Shark, a StrongARM based computer (DNARD from digital)
> that contains many parts known from PCs.
[snip]
3) Re-write/replace drivers/char/rtc.c in 2.5.  This is something I've
been thinking about for a bit because of the number of 'generic' RTC
drivers, and how they only vary slighlty.  And then there are some
hw-specific RTC drivers (efirtc.c) which could be modified to be a
personality for the new generic rtc driver.  The m68k/APUS version right
now uses a 'mach_hwclk' which handles the actual get/set bits.  I
haven't worked out all of the details just yet, but I'm thinking some of
the arch/hw-specific bits will be in a different file and on a per-arch
baises on how mach_hwclk is actually done.  Eg PPC would still end up
calling the right ppc_md version, x86 (and default) would yeild the
current behavior.

And this all relates to the original post since we could make sure that
other arches have access to any functions they might need internally.

Is there anyone else out there who's been thinking about reworking the
RTC driver?

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/