linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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: Thu, 20 Jan 2005 13:52:51 -0700	[thread overview]
Message-ID: <41F01A23.2090907@mvista.com> (raw)
In-Reply-To: <20050119180841.GP28724@smtp.west.cox.net>

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.

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 
boards, its for any board on any architecture.  Also, it isn't a 
different hook, its the same hook asm-ppc/rtc.c uses.  The only thing it 
doesn't work for is one kernel binary supporting more than one rtc 
chip.  So its about as generic as you can get given the rtc architecture 
that is there today.

Also, this is not without precedent.  drivers/char/ds1302.c, for 
example, is a complete parallel as what I'm doing.  The only difference 
is that it [essentially] duplicated the code in genrtc and its not an 
i2c device.

>
>Taking a look at arch/arm/common/rtctime.c again finally, it solves this
>problem rather elegantly.  The board registers with the driver the
>rtc_ops to get at the chip.
>

That's nice...  :)

>
>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)
>  config PPC_DIFFERENT_GENRTC_HOOKS
>  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.  :)

>- include/asm-ppc/rtc.h : what you had, basically.
>
>  
>

Mark

  reply	other threads:[~2005-01-20 20:53 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
2005-01-19 18:08             ` Tom Rini
2005-01-20 20:52               ` Mark A. Greer [this message]
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=41F01A23.2090907@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).