All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: Koen Kooi <koen@dominion.thruhere.net>,
	"Premi, Sanjeev" <premi@ti.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	"linux-omap@vger.kernel.org List" <linux-omap@vger.kernel.org>
Subject: Re: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents
Date: Mon, 27 Jun 2011 03:14:28 -0700	[thread overview]
Message-ID: <20110627101427.GH23145@atomide.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1106251635340.30205@utopia.booyaka.com>

* Paul Walmsley <paul@pwsan.com> [110625 15:42]:
> On Sun, 26 Jun 2011, Premi, Sanjeev wrote:
> 
> > [sp] I didn't include a reason - because the problem may not
> >      be reproducible on the public trees.
> > 
> >      During tests performed in internal development trees, the
> >      BogoMIPS calculations @ 1GHz wouldn't go beyond "830-850"
> >      range. While there was no such inconsistency on OMAP3EVM.
> 
> There are some other reasons to avoid GPTIMER12 when possible, which you 
> should probably put in the patch description.  The most important, in my 
> view, is that the clock source for GPTIMER12 is much less frequency-stable 
> than the clock sources for GPTIMER1.  So using GPTIMER12 can result in 
> major time skew over a fairly short interval.
> 
> I've been meaning to send a patch like this for some time, so I'm happy to 
> see this fixed.

This fix will cause bad dependency issues with sys_timer.

This patch has a dependency to omap3_beagle_init_rev, which depends on
the mux framework and gpio framework. Not cool for init_early. We just
want to initialize sys_timer early without any complicated dependencies.

The best way to fix this is to set a separate machine ID for the properly
working beagle boards like xm, then just set the .timer entry to omap3_timer
for working beagle boards and omap3_secure_timer for non-working beagle
boards. The rest of the board-*.c file can be shared.

The above assumes the patches in devel-timer branch where we no longer
have the non-standard timer interface, but use the sys_timer entries
instead like we should.

Regards,

Tony

WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents
Date: Mon, 27 Jun 2011 03:14:28 -0700	[thread overview]
Message-ID: <20110627101427.GH23145@atomide.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1106251635340.30205@utopia.booyaka.com>

* Paul Walmsley <paul@pwsan.com> [110625 15:42]:
> On Sun, 26 Jun 2011, Premi, Sanjeev wrote:
> 
> > [sp] I didn't include a reason - because the problem may not
> >      be reproducible on the public trees.
> > 
> >      During tests performed in internal development trees, the
> >      BogoMIPS calculations @ 1GHz wouldn't go beyond "830-850"
> >      range. While there was no such inconsistency on OMAP3EVM.
> 
> There are some other reasons to avoid GPTIMER12 when possible, which you 
> should probably put in the patch description.  The most important, in my 
> view, is that the clock source for GPTIMER12 is much less frequency-stable 
> than the clock sources for GPTIMER1.  So using GPTIMER12 can result in 
> major time skew over a fairly short interval.
> 
> I've been meaning to send a patch like this for some time, so I'm happy to 
> see this fixed.

This fix will cause bad dependency issues with sys_timer.

This patch has a dependency to omap3_beagle_init_rev, which depends on
the mux framework and gpio framework. Not cool for init_early. We just
want to initialize sys_timer early without any complicated dependencies.

The best way to fix this is to set a separate machine ID for the properly
working beagle boards like xm, then just set the .timer entry to omap3_timer
for working beagle boards and omap3_secure_timer for non-working beagle
boards. The rest of the board-*.c file can be shared.

The above assumes the patches in devel-timer branch where we no longer
have the non-standard timer interface, but use the sys_timer entries
instead like we should.

Regards,

Tony

  parent reply	other threads:[~2011-06-27 10:14 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-24 16:23 [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents Sanjeev Premi
2011-06-24 16:23 ` Sanjeev Premi
2011-06-24 16:32 ` Premi, Sanjeev
2011-06-24 16:32   ` Premi, Sanjeev
2011-06-25  8:16 ` Koen Kooi
2011-06-25  8:16   ` Koen Kooi
2011-06-25 18:51   ` Premi, Sanjeev
2011-06-25 18:51     ` Premi, Sanjeev
2011-06-25 20:10     ` Koen Kooi
2011-06-25 20:10       ` Koen Kooi
2011-06-27  4:45       ` Premi, Sanjeev
2011-06-27  4:45         ` Premi, Sanjeev
2011-06-27 12:32       ` Jonathan Cameron
2011-06-27 12:32         ` Jonathan Cameron
2011-06-25 22:47     ` Paul Walmsley
2011-06-25 22:47       ` Paul Walmsley
2011-06-27  4:47       ` Premi, Sanjeev
2011-06-27  4:47         ` Premi, Sanjeev
2011-06-27 10:14       ` Tony Lindgren [this message]
2011-06-27 10:14         ` Tony Lindgren
2011-06-27 15:29         ` Paul Walmsley
2011-06-27 15:29           ` Paul Walmsley
2011-06-27 15:40           ` Premi, Sanjeev
2011-06-27 15:40             ` Premi, Sanjeev
2011-06-27 16:55             ` Paul Walmsley
2011-06-27 16:55               ` Paul Walmsley
2011-06-27 18:03               ` Tony Lindgren
2011-06-27 18:03                 ` Tony Lindgren
2011-06-25 22:49 ` Paul Walmsley
2011-06-25 22:49   ` Paul Walmsley

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=20110627101427.GH23145@atomide.com \
    --to=tony@atomide.com \
    --cc=koen@dominion.thruhere.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.com \
    --cc=premi@ti.com \
    /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.