All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: Daniel Laird <danieljlaird@hotmail.com>
Cc: linux-mips@linux-mips.org, Vitaly Wool <vwool@ru.mvista.com>
Subject: Re: 2.6.19 timer API changes
Date: Wed, 20 Dec 2006 17:12:09 +0300	[thread overview]
Message-ID: <458944B9.1050204@ru.mvista.com> (raw)
In-Reply-To: <7987092.post@talk.nabble.com>

Hello.

Daniel Laird wrote:

>>Hm, then it seems writing to COMPARE does not clear COUNT.

>>How about this?  You should still fix pnx8550_hpt_read() anyway, but I
>>suppose gettimeofday() on PNX8550 was broken long time.

>>Subject: [MIPS] Use custom timer_ack and clocksource_mips.read for PNX8550

> I have not tried the suggested change yet, but I have fiund the mips manual
> and here is what it says:

> The 32-bit register is both readable and writable through the MTC0 and MFC0
> instructions as CP0 register 9. Upon reset, the Count register is set to 0.
> Count and Compare together make up Timer_1 in the PR4450 (see Section 3.12).
> The timer is active by default. When active, Count register contains a free
> running
> counter; on each processor clock-tick, the value in the register increments
> by one.
> However, when bit ST1 bit[3] in the CP0 Configuration register is enabled,
> the timer is
> stopped. When the ST1 bit is disabled, the timer returns to its default
> state.
> Timer_1 is active when the PR4450 is in Sleep mode, but is switched off when
> the
> PR4450 is in Coma mode.
> When active, the register can be reset with the assertion of the Terminal
> Count
> (TC_1) signal, which is asserted when the values in the Count and Compare
> registers
> match. After the Count register is reset, it restarts its count on the next
> processor
> clock-tick.
> In the PR4450, the TC_1 signal is fed to the external hardware interrupt
> signal to
> invoke an interrupt handler e.g., the timer interrupt. The TC_1 signal can
> only be
> reset to 0 when the interrupt handler performs a write to the Compare
> register.
> Consecutive writes to Count will result in undefined contents. At least one
> instruction
> must be inserted between consecutive writes to Count.

> This seems to suggest that writing to the compare register does in fact
> clear count.

    It actually doesn't suggest anything alike.  All it says is that "the 
register *can* be reset with the assertion of the Terminal Count (TC_1) signal 
which is asserted when the values in the Count and Compare registers match".
Whtat it doesn't say is what determines if it's really reset by TC_1 assertion 
or not.

> If I do the following:
> static void __init c0_hpt_timer_init(void)
> {
> #ifdef CONFIG_SOC_PNX8550 /* pnx8550 resets to zero */
>     expirelo = cycles_per_jiffy;
> #else
>     expirelo = read_c0_count() + cycles_per_jiffy;
> #endif
>     write_c0_compare(expirelo);
>     write_c0_count(cycles_per_jiffy); //Added DJL
> }

    Hmm, all it actually should do is warrant missing of the first jiffy 
interrupt... I'm even beginning to suspect the counter counts down, not up...
But well, after looking at some internal code, it seems that the Count 
register on PNX8550 always auto-reloads after mathing the Compare register.

> Then I get  a normal startup.  i.e it boots fast (no 10second hang).  If I
> remove the write_c0_count then I get the 10 second hang.
> I have no idea if gettimeofday is broken.  ANy ideas on testing this? Is

    It surely is, if I'm correct in my assumption... I'd suggest to use 
another PNX8550 timer as a clocksource (setting the its Compare register to 
all ones).

> there a test package / application that will do this?  Before I write my own

> Thanks for the suggestions keep them coming!
> Cheers
> Dan

WBR, Sergei

  reply	other threads:[~2006-12-20 14:12 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-18  9:15 2.6.19 timer API changes Daniel Laird
2006-12-19  8:17 ` Daniel Laird
2006-12-19 14:34   ` Atsushi Nemoto
2006-12-19 14:51     ` Daniel Laird
2006-12-19 16:23       ` Sergei Shtylyov
2006-12-19 15:01     ` Atsushi Nemoto
2006-12-19 15:34       ` Daniel Laird
2006-12-19 17:15         ` Atsushi Nemoto
2006-12-20  9:37           ` Daniel Laird
2006-12-20 14:12             ` Sergei Shtylyov [this message]
2006-12-20 14:50               ` Kevin D. Kissell
2006-12-20 14:50                 ` Kevin D. Kissell
2006-12-20 18:01                 ` Sergei Shtylyov
2006-12-20 15:24             ` Atsushi Nemoto
2006-12-20 15:46               ` Daniel Laird
2006-12-20 14:29           ` Sergei Shtylyov
2006-12-20 15:40             ` Atsushi Nemoto
2006-12-20 15:48               ` Daniel Laird
2006-12-20 15:48             ` Sergei Shtylyov
2006-12-19 15:52     ` Sergei Shtylyov
2006-12-19 16:29       ` Atsushi Nemoto

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=458944B9.1050204@ru.mvista.com \
    --to=sshtylyov@ru.mvista.com \
    --cc=danieljlaird@hotmail.com \
    --cc=linux-mips@linux-mips.org \
    --cc=vwool@ru.mvista.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.