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 `-
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox