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

Tom Rini trini at kernel.crashing.org
Fri Jan 21 09:53:21 EST 2005

On Thu, Jan 20, 2005 at 01:52:51PM -0700, Mark A. Greer wrote:
> Tom Rini wrote:
> >
> >I guess the problem I have is you're not providing a generic solution
> >(it won't work on PPC_MULTIPLATFORM), you're providing a different hook
> >for your board(s) :)
> Tom, again, [I think that] you are thinking the patch I submitted is 
> trying to solve something that it isn't.  I think we both agree that the 
> current rtc architecture (or lack thereof) needs to be improved.  And 
> maybe the ARM way is the way to go.  That's fine but that's not what the 
> patch I submitted is trying to do.

So you're saying that using the hook directly isn't a different hook?  I
suppose we can agree to disagree, since it's not relevant really :)

> The patch I submittted is only trying to be the most generic it can be 
> with the rtc architecture that is there today.  The patch will work on 
> any architecture, even on PPC/MULTIPLATFORM.  It is not only for my 

It can't work on PPC/MULTIPLATFORM as that's a kernel with multiple rtc
chips in one binary (pmac, todc for prep, chrp?).

> >So until we get around to stealing arch/arm/common/rtctime.c, I'd rather
> >you used something like:
> >- arch/ppc/Kconfig (or where ever you add the board bits)
> > default y if BOARD_A || BOARD_B
> Why?  There is no reason do add in the 'if BOARD_A' stuff.  I've added a 
> simple option, if you want to use the m41t00 rtc--this is what I'm doing 
> this for--select i2c and the correct i2c algo/adapter, select the m41t00 
> i2c client, and [if on ppc] select the option to turn off 
> include/asm-ppc/rtc.h.  If its too hard to remember, it can be easily 
> captured in a arch/ppc/configs/xxx_defconfig file.  :)

Why ask the user for something you know he wants?  If they've selected
GENRTC and are using the board, they'll probably want GENRTC to work.
It's exactly what you described except the user won't have to know about
anything going on.

Tom Rini

More information about the Linuxppc-dev mailing list