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

[Mark A. Greer]

Geert Uytterhoeven wrote:

>On Mon, 17 Jan 2005, Mark A. Greer wrote:
>  
>
>><snip>
>>
>>There are 2 reasons to not use the ppc_md.get_rtc_time() et. al. interfaces:
>>1) They are called before the i2c driver is initialized and even loaded if its
>>a module.
>>    
>>
>
>How is this solved by your patch if genrtc is builtin?
>

It solved because the rtc interface isn't called until you do an hwclock 
presumably in a startup script.

> How is your solution
>different from setting ppc_md.get_rtc_time to your get_rtc_time routine?
>

It arch independent which was the whole motivation for doing it this 
way.  However, it does rely on a startup script to do a 'hwclock 
--hctosys' which happen after driver initialization.  From what I can 
tell sysvinit used to do the hwclock but doesn't anymore so you need a 
script.  The mvl userland has a startup script that does this; others 
probably do too.  Note that using a startup script to do a hwclock is 
pretty standard AFAICT.

>>2) Its ppc-specific.  Implementing get_rtc_time() et. al. directly makes it
>>generic across all architectures.
>>    
>>
>
>... but prevents you from building a kernel that supports both normal RTCs and
>your i2c RTC.
>

Well, yes but you aren't going to be able to do this and be 
arch-agnostic.  If you don't care about running on anything but ppc then 
you can to it the way i2c rtc's have been done before and either kludge 
into the i2c driver during early startup or setup ppc_md.get_rtc_time() 
once the i2c/rtc driver(s) are initialized.  This patch will not 
interfere with that unless you deliberately set that option.

I think the real question you should be ask is are the 
ppc_md.get_rtc_time() et. al. calls really necessary?  Or to put it 
another way, should we be grilling the people who are submitting 
ppc-only solutions and not the ones submitting generic solutions?  :)

Mark