All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: danieljlaird@hotmail.com, linux-mips@linux-mips.org,
	Vitaly Wool <vwool@ru.mvista.com>
Subject: Re: 2.6.19 timer API changes
Date: Tue, 19 Dec 2006 18:52:36 +0300	[thread overview]
Message-ID: <45880AC4.5010403@ru.mvista.com> (raw)
In-Reply-To: <20061219.233410.25911550.anemo@mba.ocn.ne.jp>

Hello.

Atsushi Nemoto wrote:

>>When I run the kernel it hangs in the calibrate_delay function. 
>>Eventually the complete kernel does run but it runs very slow. 
>>This is usually an issue with the Timer Interuppt setup etc.  But I have
>>looked at the other MIPS ports and seem to have made the same changes. 

>>On the PNX8550 it does not use the CP0 timer but use a different timer (the
>>Custom MIPS core has 3 extra timers) 

> Hmm, do the TIMER1 and CP0_COUNTER run at same speed?  If no, the
> PNX8550 port should be broken (i.e. gettimeofday() did not work
> properly) even without the timer API changes.  You should provide
> custom clocksource.mips_read (previously named mips_hpt_read) function
> which returns TIMER1 counter value.  If the TIMER1 was not 32-bit
> free-run counter, some trick would be required.  Refer sb1250 or
> jmr3927 for example.

    I would like to discourage you from repeating those JMR3927 clocksource 
"tricks" when you have 3 spare count/compare regs. This will warrant troubles 
when clockevents support gets merged into mainline (in fact, it was not 
necessary even on JMR3927 which has 3 timers). Although, if the timer isn't 
auto-reloading (I assume it isn't), the trick shouldn't be needed.

> ---
> Atsushi Nemoto

WBR, Sergei

  parent reply	other threads:[~2006-12-19 15:53 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
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 [this message]
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=45880AC4.5010403@ru.mvista.com \
    --to=sshtylyov@ru.mvista.com \
    --cc=anemo@mba.ocn.ne.jp \
    --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.