From: "Mark A. Greer" <mgreer@mvista.com>
To: Tom Rini <trini@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
Date: Tue, 18 Jan 2005 12:43:12 -0700 [thread overview]
Message-ID: <41ED66D0.2090506@mvista.com> (raw)
In-Reply-To: <20050118190848.GM28724@smtp.west.cox.net>
Tom Rini wrote:
>On Tue, Jan 18, 2005 at 11:58:25AM -0700, Mark A. Greer wrote:
>
>
>>Tom Rini wrote:
>>
>>
>>
>>>I think one of us wasn't clear. I'm not arguing for nuking
>>>ppc_md.{get,set}_rtc_time(), I'm arguing for nuking
>>>get_rtc_time()/set_rtc_time() inlines from <asm-ppc/rtc.h> (which are
>>>used by drivers/char/genrtc.c) in favor of todc_time et al providing the
>>>functions for genrtc. So all of the other places we use
>>>ppc_md.{get,set}_rtc_time() are unchanged.
>>>
>>>
>>Ahh. Okay, that's good but it should be done in drivers/rtc or
>>something like and not just another arch specific solution.
>>
>>
>
>It's not an arch specific solution today.
>
Okay, I see what you mean and yes moving that up (or something
equivalent) would be a good idea.
That's not what my patch is about though. My patch is just so I can
provide a generic solution with what is there today. Its not
redesigning anything, its just getting asm-ppc/rtc.h out of the way so I
can make my own, generic get_rtc_time(), etc.
> It's just that no one that's
>written an rtc chip library (*cough* todc_time.c *cough*)
>
Heh!
> has placed one
>in drivers/char/ and let the chips (or the file) be selected. genrtc.c
>already says "someone else tell me how to get the time". I kinda sorta
>think arch/arm/common/rtctime.c does too, except it has hooks for alarm.
>
Yeah, its probably time for a better solution to what's there today...
Maybe I can get to it but it won't be for a while.
Mark
next prev parent reply other threads:[~2005-01-18 19:43 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-17 21:10 [RFC] Option to disable mapping genrtc calls to ppc_md calls Mark A. Greer
2005-01-18 9:20 ` Geert Uytterhoeven
2005-01-18 18:40 ` Mark A. Greer
2005-01-18 19:01 ` Eugene Surovegin
2005-01-18 16:15 ` Tom Rini
2005-01-18 16:25 ` Dan Malek
2005-01-18 17:39 ` Tolunay Orkun
2005-01-18 18:33 ` Tom Rini
2005-01-18 18:13 ` Tom Rini
2005-01-18 18:58 ` Mark A. Greer
2005-01-18 19:08 ` Tom Rini
2005-01-18 19:43 ` Mark A. Greer [this message]
2005-01-19 18:08 ` Tom Rini
2005-01-20 20:52 ` Mark A. Greer
2005-01-20 22:53 ` Tom Rini
2005-01-20 23:21 ` Mark A. Greer
2005-01-20 23:47 ` Tom Rini
2005-01-20 23:56 ` Mark A. Greer
2005-01-18 18:54 ` Eugene Surovegin
2005-01-20 22:27 ` Benjamin Herrenschmidt
2005-01-18 18:55 ` Mark A. Greer
2005-01-18 19:05 ` Tom Rini
2005-01-18 19:33 ` Mark A. Greer
2005-01-20 22:25 ` Benjamin Herrenschmidt
2005-01-20 23:54 ` Mark A. Greer
2005-01-21 0:01 ` Benjamin Herrenschmidt
2005-01-21 0:09 ` Mark A. Greer
2005-01-21 0:12 ` Benjamin Herrenschmidt
2005-01-21 9:14 ` Geert Uytterhoeven
2005-01-21 14:39 ` Corey Minyard
2005-01-21 22:01 ` Benjamin Herrenschmidt
2005-01-21 9:44 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41ED66D0.2090506@mvista.com \
--to=mgreer@mvista.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=trini@kernel.crashing.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.