[RFC] Option to disable mapping genrtc calls to ppc_md calls
Mark A. Greer
mgreer at mvista.com
Wed Jan 19 05:55:54 EST 2005
Tom Rini wrote:
>On Mon, Jan 17, 2005 at 02:10:00PM -0700, 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.
>>
>>
>
>But they check if it's set, so they can be assigned later and this is
>OK.
>
But looking at ppc_md.<anything> automatically makes it ppc only.
Pretty much any of the rtc chips that we use on ppc platforms could
appear on almost any other platform with a different processor
architecture. So the question is, why do we keep adding ppc-only
support for rtc chips? Why are we not putting our effort into making
code that works on all architectures? Its easy enough to do...
>>2) Its ppc-specific. Implementing get_rtc_time() et. al. directly makes
>>it generic across all architectures.
>>
>>
>
>Guessing, this is for a marvell chipset that's found on MIPS too.
>
That's an example but like I said above rtc chips are not tied to any
particular processor architecture.
>>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.
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.
Mark
More information about the Linuxppc-dev
mailing list