Subject: Re: [PATCH 2.6] enable genrtc for MIPS

From: Atsushi Nemoto <[email-masked]>
Date: Sun, 01 Feb 2004 20:30:05 +0900 (JST)

>>>>> On Fri, 30 Jan 2004 20:13:38 +0100 (CET), "Maciej W. Rozycki" <[email-masked]> said:

>> Of course, individual board is still free to choose the old rtc.c
>> or implement some peculiar ones of its own - although I can't see
>> why. :)

macro>  s/old/full-featured/

No, I suppose s/rtc/mips-rtc/ is what the original patch means.

By the way, with this patch, individual board can not implement it's
own genrtc routines.  How about making gen_rtc_time, etc. pointer to
functions to allow overrides?

I think implementing rtc_get_time (mips specific) with get_rtc_time
(genrtc) is more efficient than implementing get_rtc_time with
rtc_get_time for most RTC chips.

---
Atsushi Nemoto

---

From: Geert Uytterhoeven <[email-masked]>
Date: Sun, 1 Feb 2004 13:04:00 +0100 (MET)

> rtc_get_time for most RTC chips.

Indeed, that's what I noticed a while ago, too.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email-masked]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

---

From: Jun Sun <[email-masked]>
Date: Mon, 2 Feb 2004 13:19:50 -0800

> functions to allow overrides?

Is this necessary?  How about letting us wait until there is a sensible
need?

> rtc_get_time for most RTC chips.

If I understand you correctly, you like to have board rtc read routines to 
return a rtc structure instead of the unsigned long integer.

There are actually boards which makes the current implementation more efficient.  
See vr4181.

In general, however, this is not a bad idea, just involving a lot more
board level changes.  I think it deserves another patch or even debate.

Jun

---

From: Atsushi Nemoto <[email-masked]>
Date: Tue, 03 Feb 2004 10:30:25 +0900 (JST)

>>>>> On Mon, 2 Feb 2004 13:19:50 -0800, Jun Sun <[email-masked]> said:
>> By the way, with this patch, individual board can not implement
>> it's own genrtc routines.  How about making gen_rtc_time,
>> etc. pointer to functions to allow overrides?

jsun> Is this necessary?  How about letting us wait until there is a
jsun> sensible need?

OK, we can wait.  But still I suppose gen_rtc_time will become a
pointer sooner or later....

Anyway, I think using genrtc instead of mips-rtc is very good idea.
Thank you.

jsun> If I understand you correctly, you like to have board rtc read
jsun> routines to return a rtc structure instead of the unsigned long
jsun> integer.

jsun> There are actually boards which makes the current implementation
jsun> more efficient.  See vr4181.

I see.

jsun> In general, however, this is not a bad idea, just involving a
jsun> lot more board level changes.  I think it deserves another patch
jsun> or even debate.

Though I'm not have a real code yet, how about this idea?

1. Provide std_rtc_get_time (returns ulong) implemented with
   get_rtc_time (returns rtc struct) pointer.
2. Provide std_get_rtc_time (returns rtc struct) implemented with
   rtc_get_time returns ulong) pointer.
3. Each board implement its own rtc_get_time or get_rtc_time.
4. In generic time_init(), initialize rtc_get_time pointer or
   get_rtc_time pointer with std_rtc_get_time or std_get_rtc_time if
   they were NULL.

---
Atsushi Nemoto