From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter De Schrijver Subject: Re: [PATCH 5/9] clocksource: tegra: Enable ARM arch_timer with TSC Date: Thu, 20 Dec 2012 14:22:46 +0200 Message-ID: <20121220122246.GA6819@tbergstrom-lnx.Nvidia.com> References: <1355996654-6579-1-git-send-email-hdoyu@nvidia.com> <1355996654-6579-6-git-send-email-hdoyu@nvidia.com> <50D2EFFB.8030702@arm.com> <20121220.135758.1347753620353343245.hdoyu@nvidia.com> <50D2FF19.4060600@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <50D2FF19.4060600-5wv7dgnIgG8@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: "devicetree-discuss" To: Marc Zyngier Cc: "andrew-g2DYL2Zd6BY@public.gmane.org" , "linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org" , "jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org" , "linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "johnstul-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org" , "devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org" , "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , Hiroshi Doyu List-Id: devicetree@vger.kernel.org > >>> + > >>> + /* CNTFRQ */ > >>> + asm("mcr p15, 0, %0, c14, c0, 0\n" : : "r" (freq)); > >>> + asm("mrc p15, 0, %0, c14, c0, 0\n" : "=r" (val)); > >>> + BUG_ON(val != freq); > >> > >> This is scary. CNTFRQ is only writable from secure mode, and will > >> explode in any other situation. > >> > >> Also, writing to CNTFRQ doesn't change the timer frequency! This is just > >> a way for secure mode to tell the rest of the world the frequency the > >> timer is ticking at. Unless you've wired the input clock to be able to > >> change the frequency? > > > > ATM, our upstream kernel is expected in secure mode. This situation > > may be changed later, though.... > > I appreciate this. But I expect this kernel to be also used on the > non-secure side if someone tried to run KVM with it. And this would go > bang right away. > But the guest wouldn't necessarily have this peripheral, or any other Tegra114 peripheral for that matter? Cheers, Peter.