[RFC] Option to disable mapping genrtc calls to ppc_md calls
Mark A. Greer
mgreer at mvista.com
Wed Jan 19 05:40:50 EST 2005
Geert Uytterhoeven wrote:
>On Mon, 17 Jan 2005, Mark A. Greer wrote:
>>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
>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? :)
More information about the Linuxppc-dev