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 11:58:25 -0700 [thread overview]
Message-ID: <41ED5C51.8020809@mvista.com> (raw)
In-Reply-To: <20050118181330.GJ28724@smtp.west.cox.net>
Tom Rini wrote:
>On Tue, Jan 18, 2005 at 11:25:33AM -0500, Dan Malek wrote:
>
>
>>On Jan 18, 2005, at 11:15 AM, Tom Rini wrote:
>>
>>
>>
>>>On Mon, Jan 17, 2005 at 02:10:00PM -0700, 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 a module.
>>>>
>>>>
>>There are three reasons. You don't want to use an I2c rtc clock at
>>all in these functions because they get can get called from the
>>clock interrupt to update the time in the rtc. If it does happen to
>>work,
>>it creates long latencies in the timer interrupt. If the i2c requires
>>an
>>interrupt, they system will crash or hang.
>>
>>
>
>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. I want to
stress again that rtc chips typically have no care in the world what
processor happens to be stuck on the board that they are also stuck on.
There is no reason our software should either.
Mark
next prev parent reply other threads:[~2005-01-18 18:58 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 [this message]
2005-01-18 19:08 ` Tom Rini
2005-01-18 19:43 ` Mark A. Greer
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=41ED5C51.8020809@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).