linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: dick@softplc.com (Dick Hollenbeck)
To: linux-arm-kernel@lists.infradead.org
Subject: ks8695_gettimeoffset
Date: Tue, 04 Jan 2011 00:26:50 -0600	[thread overview]
Message-ID: <4D22BDAA.2030902@softplc.com> (raw)
In-Reply-To: <AANLkTi=+9h20je24F+pnoZRFE-of-VZ5Xax8-tDzFs4=@mail.gmail.com>

On 01/03/2011 01:55 PM, avictor.za at gmail.com wrote:
> hi,
>
>> Is it possible at all to implement clocksource/clockevents for KS8695? As Dick and "Register Description" already said you cannot read the time register, so clocksource->read cannot be implemented to return ticks elapsed. Or do I see it wrong?
> I'm pretty sure I tested this when I originally submitted the KS8685
> processor support (May 2007), and the timer registers are readable.
> I would of tested with a userspace program that sat in a tight loop
> calling gettimeofday().
>
>
> Regards,
>   Andrew Victor
>

Thanks Andrew.  Can you explain how this is supposed to be a duration, even
if one of these two registers was a readable down counter?

 elapsed = __raw_readl(KS8695_TMR_VA + KS8695_T1TC) + __raw_readl(KS8695_TMR_VA + KS8695_T1PD);


Which of the two is a down counter, and why would it be added to one that is not, or is?

While you are thinking about that, I have a userspace test program that can peek at the two registers using a memory mapped region pointer, and it will tell us if the value is changing over time.


The register description PDF document says the values *are readable*, but that description does not specifically say what is being read back, the preload value or the dynamically down counting value.

Doc Extraction:

TOUT1PC aka T1PD offset 0xE40C

This field specifies the duration that the TOUT1 pin is High in each
timeout period. Writing zero to this register may cuase unpredictalbe
behavior.

TOUT1TC aka T1TC offset 0xE404

This field specifies the duration that the TOUT1 pin is Low in each
timeout period. Writing zero to this register may cuase unpredictalbe
behavior.


Thanks,

Dick

  reply	other threads:[~2011-01-04  6:26 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-20 19:09 ks8695_gettimeoffset Dick Hollenbeck
2010-12-20 19:30 ` ks8695_gettimeoffset Russell King - ARM Linux
2010-12-20 19:37   ` ks8695_gettimeoffset Dick Hollenbeck
2010-12-27 15:37   ` ks8695_gettimeoffset Yegor Yefremov
2011-01-03  0:28     ` ks8695_gettimeoffset Russell King - ARM Linux
2011-01-03 19:55     ` ks8695_gettimeoffset avictor.za at gmail.com
2011-01-04  6:26       ` Dick Hollenbeck [this message]
2011-01-04  6:32         ` ks8695_gettimeoffset Dick Hollenbeck
  -- strict thread matches above, loose matches on Subject: below --
2010-12-20 19:32 ks8695_gettimeoffset Dick Hollenbeck

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=4D22BDAA.2030902@softplc.com \
    --to=dick@softplc.com \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).