Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls

["Mark A. Greer" <mgreer@mvista.com>]

Tom Rini wrote:

>On Tue, Jan 18, 2005 at 11:55:54AM -0700, Mark A. Greer wrote:
>  
>
>>Tom Rini wrote:
>>    
>>
>[snip]
>  
>
>>>>Is there a better way to do this?
>>>>  
>>>>
>>>>        
>>>>
>>>How about we try borrowing the MIPS abstraction and force todc_time,
>>>pmac_time (any others?) to directly define (and EXPORT_SYMBOL)
>>>get_rtc_time / set_rtc_time / etc.
>>>
>>>      
>>>
>>Yep, MIPS has a solution...and so does ARM...and so does PPC.  This is 
>>sort of my point.
>>    
>>
>
>And my point was to use someone elses solution, 'cuz that's how we go
>from N to N-1 to 1 :)
>

If effort is going to be put into this then why not just go from N 
directly to 1?  BTW, I am not volunteering.  ;)

>
>  
>
>>If we really want to do it right then someone needs to architect a 
>>generic solution.  What I have done is generic but does not handle the 
>>case that Geert mentioned when you have one kernel binary and several 
>>possible rtc chips.  In the meantime, what I have done works fine for 
>>all but that case.
>>    
>>
>
>I guess there's two points:
>- How does your solution differ from what MIPS does, and probably ARM
>  does of saying the backend (todc_time, i2c-foo) provides
>  get_rtc_time/set_rtc_time?
>
First, I want to make sure we all on the same page.  There are really 
two issues being discussed and I think we're all swinging back and forth 
between the two.

Issue 1) -  My patch:

I had to write some support for an ST m41t00 rtc w/ an i2c interface.  I 
could have made it ppc only or generic with the same amount of effort so 
I chose the generic one.  The gereric one I chose was to use the code in 
genrtc and interface directly to the bottom of that code b/c that's 
where things become arch-specific.  However, that is where I collided 
with asm-ppc/rtc.h, hence the patch.

What I did is generic because genrtc.c is generic, the rtc "driver" is 
generic, and you can plug in any generic i2c algo/adapter driver 
underneath the entire thing.

Issue 2) - What should the *real* rtc architecture be?

RMK's solution may be fine, I'd have to look.  I think a discussion like 
this is good but I know I don't have the time right now to do it.

This is the one I think you, Tom, are talking about.  That's good but 
just understand that my patch has nothing to do with a generic solution 
for all rtc's.  I'm just trying to get this one to work (issue 1).

>- I horribly briefly talked with rmk about this a long time ago, and I
>  think he has the generic solution, siting in arch/arm/common/rtctime.c
>  (sure it would need to be moved to drivers/char/something, but..).
>

Yep, if it isn't in the right place, it doesn't help (for now anyway).

>- I lied, #3 how does ARM, which I think lets you select multiple
>  boards, and thus probably end up with multiple rtc chip choices, deal
>  with it.
>

Yep, ARM has  a reasonable solution but its ARM only and I'm not trying 
to rewrite anything at this point (see above).

Mark