From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752562AbcG2Kbu (ORCPT ); Fri, 29 Jul 2016 06:31:50 -0400 Received: from foss.arm.com ([217.140.101.70]:53062 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751504AbcG2Kbs (ORCPT ); Fri, 29 Jul 2016 06:31:48 -0400 Subject: Re: [PATCH] clocksource: arm_arch_timer: Support reading clock rate from a driver To: Mark Rutland , =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= References: <1469784191-3998-1-git-send-email-zajec5@gmail.com> <20160729101811.GB21580@leverpostej> Cc: Daniel Lezcano , Thomas Gleixner , =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= , "open list:CLOCKSOURCE, CLOCKEVENT DRIVERS" , linux-arm-kernel@lists.infradead.org From: Marc Zyngier X-Enigmail-Draft-Status: N1110 Organization: ARM Ltd Message-ID: <579B3090.1070709@arm.com> Date: Fri, 29 Jul 2016 11:31:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160729101811.GB21580@leverpostej> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 29/07/16 11:18, Mark Rutland wrote: > [adding Marc to Cc] > > On Fri, Jul 29, 2016 at 11:23:11AM +0200, Rafał Miłecki wrote: >> From: Rafał Miłecki >> >> On some devices using arch code for reading clock rate doesn't work. So >> far the only option was to specify clock-frequency in a DT. This works >> only if a clock frequency doesn't have to be calculated on runtime. >> >> On BCM53573 SoC (with Cortex-A7) there is ILP clock that needs its own >> driver. With this change we can query such clocks by using a standard: >> clocks = <&foo>; > > The clock for the architected timer(s) are supposed to be configured > before entering Linux. The clock-frequency property is at best a dodgy > workaround, and this is even worse. > > Please fix your firmware to configure and enabled this clock before > entering Linux, and to program CNTFRQ appropriately. I'll add that failure to do so breaks other subsystems which do rely on CNTFRQ to be correctly programmed *on each CPU* (like KVM and Xen). Please follow the requirements of the architecture and don't just paper over such a bug. > As this path stands, NAK. Seconded. M. -- Jazz is not dead. It just smells funny...