From: "Dag-Erling Smørgrav" <des@linpro.no>
To: Clemens Koller <clemens.koller@anagramm.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC+PATCH] RTC calibration
Date: Tue, 11 Sep 2007 18:04:06 +0200 [thread overview]
Message-ID: <ujr1wd52npl.fsf@false.linpro.no> (raw)
In-Reply-To: <46E6B617.7030106@anagramm.de> (Clemens Koller's message of "Tue, 11 Sep 2007 17:36:55 +0200")
Clemens Koller <clemens.koller@anagramm.de> writes:
> Dag-Erling Smørgrav <des@linpro.no> writes:
> > Without knowing exacly which chip is present, there is no way for the
> > userland calibration tool to know how big a difference a calibration
> > step makes.
> I am not talking about the calibration algorithm and it's quality.
Neither am I.
> I am talking about _how_ the calibration register is addressed from
> userspace. It's a simple register, some bits at address 7 and I would
> expect to read/modify/write registers to do all the things you want
> to do. Register access in userspace doesn't put any limitation
> to applications.
It requires the application to know the hardware intimately.
Calibration of the M41T11 is implemented using the lower 6 bits of
register 7; this is not necessarily the case for other existing or
future chips.
Let's say I normalize this to [-128;127]; an application that tried to
speed up the clock would waste several hours increasing the
calibration value from 0 to 1, 2, 3 before seeing an effect after
increasing it to 4. And how do I normalize the assymetric range of
the M41T11?
> Having only incs and decs without getting the actual value back seems
> to be an absolutely unnecessary limitation here.
> You cannot get the current value back to see if it's i.e. in saturation in
> a way that it doesn't make sense to inc/decrement it further or in bigger steps
> or reset it to zero...
The driver will return EINVAL if you try to increment or decrement the
calibration register beyond its limits.
DES
--
Dag-Erling Smørgrav
Senior Software Developer
Linpro AS - www.linpro.no
next prev parent reply other threads:[~2007-09-11 16:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-11 13:48 [RFC+PATCH] RTC calibration Dag-Erling Smørgrav
2007-09-11 14:33 ` Clemens Koller
2007-09-11 15:02 ` Dag-Erling Smørgrav
2007-09-11 15:36 ` Clemens Koller
2007-09-11 16:04 ` Dag-Erling Smørgrav [this message]
2007-09-11 19:02 ` Clemens Koller
2007-10-31 11:03 ` Pavel Machek
2007-09-11 15:23 ` Mark Gross
2007-09-11 15:51 ` Dag-Erling Smørgrav
2007-09-11 16:28 ` Dag-Erling Smørgrav
2007-09-12 10:49 ` Arne Georg Gleditsch
2007-09-12 10:59 ` Dag-Erling Smørgrav
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=ujr1wd52npl.fsf@false.linpro.no \
--to=des@linpro.no \
--cc=clemens.koller@anagramm.de \
--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 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.