All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthias Kaehlcke <matthias@kaehlcke.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/2 rev2] ep93xx: Refactoring of timer code
Date: Thu, 25 Feb 2010 20:47:46 +0100	[thread overview]
Message-ID: <20100225194746.GC3628@darwin> (raw)
In-Reply-To: <20100225192259.GA31347@morgana.gnudd.com>

Hi,

El Thu, Feb 25, 2010 at 08:22:59PM +0100 Alessandro Rubini ha dit:

> > i was/am working on a new version of the patch, taking into account
> > your remarks about the unit of TIMER_FREQ and fixing some issues
> > discussed with Alessandro Rubini off-list, who worked on a similar
> > patch.
> 
> Actually, I checked the point we disagreed about, which is the unit of
> get_ticks() and get_tbclk().  You currently return hw-ticks in
> get_ticks, and CONFIG_SYS_HZ (i.e. 1000) in get_tbclk.  However, these
> two functions are expected to be used together, so they must be
> consistent in their return value.

actually there is no disagreement between us, i totally agree with you
that the return value of get_ticks() should be in CONFIG_SYS_HZ
resolution and consistent with get_tbclk(). the patch i sent you
yesterday off-list fixes exactly this.

> It's true that the functions are little used (they are mostly used in
> ppc code, within cpu/*/interrupts), and that's why I didn't even
> provide them in cpu/arm926ejs/nomadik/timer.c. All few users assume
> they are consistent, but there is no documentation:
> 
>      tornado% grep -qr get_tbclk README* doc  || echo not found
>      not found
>      tornado% grep -qr get_ticks README* doc/* || echo not found
>      not found
> 
> I've made a quick tour of all definitions in cpu/ and here is the result.
> As you see, at91 (which you used as reference, I understand) is wrong,
> while all the others use either hwticks or SYS_HZ consistently.

yes, i used precisely at91 as reference, i liked it's code structure
and didn't notice that it is wrong in this point.

thanks for your research!

-- 
Matthias Kaehlcke
Embedded Linux Developer
Barcelona

              We build too many walls and not enough bridges
                             (Isaac Newton)
                                                                 .''`.
    using free software / Debian GNU/Linux | http://debian.org  : :'  :
                                                                `. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4                  `-

  reply	other threads:[~2010-02-25 19:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <7ee75976e78e2f82b4163fe1ff4233a850d4393c.1266966938.git.matthias@kaehlcke.net>
2010-02-23 23:22 ` [U-Boot] [PATCH 2/2 rev2] ep93xx: Refactoring of timer code Matthias Kaehlcke
2010-02-25 15:54   ` Tom
2010-02-25 18:15     ` Matthias Kaehlcke
2010-02-25 19:22       ` Alessandro Rubini
2010-02-25 19:47         ` Matthias Kaehlcke [this message]
2010-02-26  0:13       ` Tom

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=20100225194746.GC3628@darwin \
    --to=matthias@kaehlcke.net \
    --cc=u-boot@lists.denx.de \
    /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.