Hi Maxime,

On Thu, Jun 27, 2013 at 07:21:44PM +0200, Maxime Ripard wrote:

On Thu, Jun 27, 2013 at 12:46:49PM +0300, Baruch Siach wrote:

quoted

On Thu, Jun 27, 2013 at 11:35:58AM +0200, Maxime Ripard wrote:

quoted

On Thu, Jun 27, 2013 at 09:02:34AM +0300, Baruch Siach wrote:

quoted

On Wed, Jun 26, 2013 at 11:16:55PM +0200, Maxime Ripard wrote:

quoted

+static u32 sun4i_timer_sched_read(void)

You commit message mentions "64 bits free running counter", but this one only 
returns 32 bit.

Yeah, the callback setup by setup_sched_clock is supposed to be
returning a u32, and clocksource_mmio_init only accepts up to 32 bits as
well, so I'm only using the lower 32bits of this 64 bits counter.

I'll amend the commit log to state this.

But using 64 bit counter for sched_clock is much easier that using 32 bit one. 

Easier in what aspect? Both API looks similar.

You can just implement your own simple sched_clock() that just returns the 
current value of this 64 bit counter, and do away with all the tricky code in 
kernel/time/sched_clock.c (in tip.git) that is needed to make the 32 -> 64 
extension safe. This is not compatible with multi-platform kernel, though.

quoted

You can either wait for the rest of Stephen's patch set 
(http://thread.gmane.org/gmane.linux.ports.arm.msm/4092) before adding 64 
bit, or you can just make the trivial change to the now generic 
sched_clock code.

I'll wait for the Stephen's patches to be merged then, and add support
for 64bits counters to clocksource_mmio_init.

Sound reasonable.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -