mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ted Phelps <phelps@gnusto.com>
To: linux-kernel@vger.kernel.org
Subject: [PATCH] more reliable system timer for SC1100 CPU
Date: Fri, 11 Mar 2005 09:06:14 -0600	[thread overview]
Message-ID: <200503111506.j2BF6EWh030442@laika.gnusto.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1937 bytes --]

Hello,

The attached patch is an attempt to work around the buggy timestamp
counter on the NatSemi SC1100 CPU by using the on-board 27MHz
high-resolution timer as an alternative time source.  It should,
in theory, work with any of the SCx200 CPUs as well, though I have
been unable to test this.  I have tested it fairly thoroughly with NTP
on an SC1100 and it seems to behave sanely.

That said, there are three things about it that I'm not entirely
comfortable with:

(1) The high-resolution timer is driven by a separate crystal than the
    CPU's timer interrupt, and on the SC1100 I have access to, it's
    consistently slower.  I've found that it is necessary to
    periodically *decrement* the jiffies_64 counter in mark_offset in
    order to make gettimeofday produce anything reasonable.  In
    practice jiffies_64 is incremented again in do_timer before
    anything else reads it, so the net effect is minimal.

(2) The 27MHz timer is accessed via the PCI bus, which is not
    available when the system clock is initialized.  To work around
    this, I've written the init function to always fail so that
    loops_per_jiffy is computed using another timer (the TSC in my
    case).  Once the high-resolution timer is accessible, the kernel
    will switch to using it to compute gettimeofday and the monotonic
    clock, but still use the original timer's delay function.  This
    is somewhat kludgy, but I can't see a cleaner way.

(3) The timer depends on CONFIG_SCx200, which appears later in the
    configuration hierarchy to the timers, and in an entirely
    different part.  For now I've kept its Kconfig with the other
    timers, but I'm not entirely happy with this choice.
    
The patch is against linux-2.6.11-mm2 as it relies on the
'determine-scx200-cb-address-at-run-time.patch' patch which has not
made it into in the mainline.

Please CC me if you reply as I'm not subscribed to LKML.

Cheers,
-Ted


[-- Attachment #2: scx200-hr-timer-2.6.11-mm2-5.diff.gz --]
[-- Type: application/x-gzip, Size: 3856 bytes --]

             reply	other threads:[~2005-03-11 15:06 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-11 15:06 Ted Phelps [this message]
2005-03-11 22:07 ` George Anzinger

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=200503111506.j2BF6EWh030442@laika.gnusto.com \
    --to=phelps@gnusto.com \
    --cc=linux-kernel@vger.kernel.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

all inboxes | Powered by JetHome®