From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753810AbbJ0VPe (ORCPT <rfc822;w@1wt.eu>);
	Tue, 27 Oct 2015 17:15:34 -0400
Received: from mailapp01.imgtec.com ([195.59.15.196]:5844 "EHLO
	mailapp01.imgtec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753329AbbJ0VP3 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 27 Oct 2015 17:15:29 -0400
Message-ID: <562FE96C.3070002@imgtec.com>
Date: Tue, 27 Oct 2015 14:15:24 -0700
From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: David Daney <ddaney.cavm@gmail.com>
CC: Ralf Baechle <ralf@linux-mips.org>,
        Markos Chandras <markos.chandras@imgtec.com>,
        <linux-mips@linux-mips.org>, Alex Smith <alex.smith@imgtec.com>,
        <linux-kernel@vger.kernel.org>
Subject: Re: [v3, 3/3] MIPS: VDSO: Add implementations of gettimeofday() and
 clock_gettime()
References: <1445417864-31453-1-git-send-email-markos.chandras@imgtec.com> <5629904A.2070400@imgtec.com> <20151027144748.GA23785@linux-mips.org> <562FE29C.8040106@imgtec.com> <562FE678.2030307@gmail.com>
In-Reply-To: <562FE678.2030307@gmail.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.20.3.92]
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 10/27/2015 02:02 PM, David Daney wrote:
> On 10/27/2015 01:46 PM, Leonid Yegoshin wrote:
> [...]
>>
>> And finally. clock scaling - what we would do if there are two CPUs with
>> different clock ratios in system? It seems like common kernel timing
>> subsystem can handle that.
>>
>
> The code that executes in userspace must have access to a consistent 
> clock source.  If you are running on a SMP system that doesn't have 
> synchronized CP0.Count registers, then your gettimeofday() cannot use 
> CP0.Count (RDHWR $2).

Right, I agree.

>
> As far as I know, CP0.Count is the only available counter visible to 
> userspace, so you would have to disable the accelerated versions of 
> gettimeofday() where you cannot assert that the counters are always 
> synchronized.

Any system with GIC may have access to the same GIC global counter in a 
special separate page available for mapping by user in RO mode and it 
seems Alex did that.

Besides that this GIC global counter is used as a major system 
clocksource in systems with GIC.

- Leonid