ks8695_gettimeoffset

ks8695_gettimeoffset

[Dick Hollenbeck]

ks8695_gettimeoffset

[Russell King - ARM Linux]

On Mon, Dec 20, 2010 at 01:09:47PM -0600, Dick Hollenbeck wrote:
> >From userspace, printing the return values from a rapid looping
> sequence of calls to
> 
>    clock_gettime( CLOCK_MONOTONIC, &now );
> 
> leads me to believe that kernel function ks8695_gettimeoffset() is
> not worth anything.

That'll be because clock_gettime(CLOCK_MONOTONIC) doesn't use the old
gettimeoffset() method to correct the returned time - none of the POSIX
timers use the old gettimeoffset() stuff, only gettimeofday() does.

Platforms really should be using the clocksource/clockevents code
where ever possible, rather than selecting ARCH_USES_GETTIMEOFFSET.

Does someone with a KS8695-based platform want to have a go at
converting it over to clocksource/clockevents?

ks8695_gettimeoffset

[Dick Hollenbeck]

On 12/20/2010 01:30 PM, Russell King - ARM Linux wrote:
> On Mon, Dec 20, 2010 at 01:09:47PM -0600, Dick Hollenbeck wrote:
>> >From userspace, printing the return values from a rapid looping
>> sequence of calls to
>>
>>    clock_gettime( CLOCK_MONOTONIC, &now );
>>
>> leads me to believe that kernel function ks8695_gettimeoffset() is
>> not worth anything.
> That'll be because clock_gettime(CLOCK_MONOTONIC) doesn't use the old
> gettimeoffset() method to correct the returned time - none of the POSIX
> timers use the old gettimeoffset() stuff, only gettimeofday() does.
>
> Platforms really should be using the clocksource/clockevents code
> where ever possible, rather than selecting ARCH_USES_GETTIMEOFFSET.
>
> Does someone with a KS8695-based platform want to have a go at
> converting it over to clocksource/clockevents?

Thanks Russell. 

    As a quick aside, I posted the same question twice because web archive does not show the email
content getting through:

    http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/035978.html

If no one with more experience in this area steps up, I can do some work on this, but I would need
considerable hand holding since I have not been following the names of these major subsystems within
the kernel as of late. 

Let's wait, and then I may have to raise the issue again if no one steps up.

Dick

ks8695_gettimeoffset

[Yegor Yefremov]

Am 20.12.2010 20:30, schrieb Russell King - ARM Linux:
> On Mon, Dec 20, 2010 at 01:09:47PM -0600, Dick Hollenbeck wrote:
>> >From userspace, printing the return values from a rapid looping
>> sequence of calls to
>>
>>    clock_gettime( CLOCK_MONOTONIC, &now );
>>
>> leads me to believe that kernel function ks8695_gettimeoffset() is
>> not worth anything.
> 
> That'll be because clock_gettime(CLOCK_MONOTONIC) doesn't use the old
> gettimeoffset() method to correct the returned time - none of the POSIX
> timers use the old gettimeoffset() stuff, only gettimeofday() does.
> 
> Platforms really should be using the clocksource/clockevents code
> where ever possible, rather than selecting ARCH_USES_GETTIMEOFFSET.
> 
> Does someone with a KS8695-based platform want to have a go at
> converting it over to clocksource/clockevents?

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? 

Is there any documentation for clocksource/clockevents? 

Best regards,
Yegor

ks8695_gettimeoffset

[Russell King - ARM Linux]

On Mon, Dec 27, 2010 at 04:37:25PM +0100, Yegor Yefremov wrote:
> Am 20.12.2010 20:30, schrieb Russell King - ARM Linux:
> > On Mon, Dec 20, 2010 at 01:09:47PM -0600, Dick Hollenbeck wrote:
> >> >From userspace, printing the return values from a rapid looping
> >> sequence of calls to
> >>
> >>    clock_gettime( CLOCK_MONOTONIC, &now );
> >>
> >> leads me to believe that kernel function ks8695_gettimeoffset() is
> >> not worth anything.
> > 
> > That'll be because clock_gettime(CLOCK_MONOTONIC) doesn't use the old
> > gettimeoffset() method to correct the returned time - none of the POSIX
> > timers use the old gettimeoffset() stuff, only gettimeofday() does.
> > 
> > Platforms really should be using the clocksource/clockevents code
> > where ever possible, rather than selecting ARCH_USES_GETTIMEOFFSET.
> > 
> > Does someone with a KS8695-based platform want to have a go at
> > converting it over to clocksource/clockevents?
> 
> 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? 

If you have no register which ticks at a fixed rate, then you have no
hope to use the clocksource/clockevents code, and will be stuck with
the old gettimeoffset() stuff.

Note that even a 16-bit 32768Hz counter would be a candidate for a
clocksource (it'd be an improvement over either a buggy gettimeoffset()
or no gettimeoffset().)

> Is there any documentation for clocksource/clockevents? 

That's a question I've asked many times.

The answer is nothing beyond the comments in the header files
(include/linux/clocksource.h, include/linux/clockchips.h), source files
(kernel/time/), commits covering the same, the already merged
implementations, and some stuff in Documentation/timers/.

Clocksources themselves are very simple:

static cycle_t cksrc_foo_read(struct clocksource *cs)
{
	return readl(cycle_counter);
}

and add maths to make sure the returned value is incrementing if it
isn't.  Optionally implement the enable/disable callbacks if you can
turn on/off this clocksource:

static int cksrc_foo_enable(struct clocksource *cs)
{
	writel(enable_val, enable_reg);
}

static void clksrc_foo_disable(struct clocksource *cs)
{
	writel(disable_val, enable_reg);
}

Declare the clocksource structure:

static struct clocksource cksrc_foo = {
	.name		= "some_descriptive_name",
	.rating 	= 200,
	.read		= cksrc_foo_read,
	.enable 	= cksrc_foo_enable,
	.disable	= cksrc_foo_disable,
	.mask		= CLOCKSOURCE_MASK(number_of_bits_in_cycle_counter),
	.flags		= CLOCK_SOURCE_IS_CONTINUOUS,
};

Finally, register it in the sys_timer init method:

	clocksource_register_hz(&cksrc_foo, cycle_counter_tick_rate_in_hz);
or
	clocksource_register_khz(&cksrc_foo, cycle_counter_tick_rate_in_khz);

Once you have that in place, you can kill off the gettimeoffset() stuff
and ensure that you don't enable the ARCH_USES_GETTIMEOFFSET config symbol.

The gotcha here is that the cycle counter must not overflow between any
two timer interrupts - so make sure that it won't wrap within your normal
periodic timer tick rate.  If it does wrap, you won't keep good time.

The clockevent support is similar - but more complicated to explain in an
email without knowing the details of the hardware (because there's too
many possibilities.)  I believe the clockevent stuff needs the clocksource
stuff to be in place first though.

ks8695_gettimeoffset

[avictor.za at gmail.com]

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

ks8695_gettimeoffset

[Dick Hollenbeck]

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

ks8695_gettimeoffset

[Dick Hollenbeck]

On 01/04/2011 12:26 AM, Dick Hollenbeck wrote:
> 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.

Sorry, I should have just ran the program before posting.  Both registers
are constant at 25000 while running.   So my original summary is correct,
that this C function is not worth anything.

Where do we go from here?

Dick

ks8695_gettimeoffset

[Dick Hollenbeck]