From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752502AbcISXO6 (ORCPT ); Mon, 19 Sep 2016 19:14:58 -0400 Received: from mail-pf0-f177.google.com ([209.85.192.177]:36756 "EHLO mail-pf0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751146AbcISXO5 (ORCPT ); Mon, 19 Sep 2016 19:14:57 -0400 Date: Mon, 19 Sep 2016 16:14:42 -0700 From: Brian Norris To: Marc Zyngier Cc: Daniel Lezcano , Thomas Gleixner , Mark Rutland , Stephen Boyd , linux-rockchip@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, wxt@rock-chips.com Subject: Re: [PATCH] clocksource: arm_arch_timer: Don't assume clock runs in suspend Message-ID: <20160919231441.GA60928@google.com> References: <20160916054917.16930-1-briannorris@chromium.org> <57DBA81F.2060404@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57DBA81F.2060404@arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 16, 2016 at 09:06:55AM +0100, Marc Zyngier wrote: > Hi Brian, Hi Marc, Thanks for the quick response. > On 16/09/16 06:49, Brian Norris wrote: > > Since commit 4fbcdc813fb9 ("clocksource: arm_arch_timer: Use clocksource > > for suspend timekeeping"), this driver assumes that the ARM architected > > timer keeps running in suspend. This is not the case for some ARM SoCs, > > depending on the HW state used for system suspend. Let's not assume that > > all SoCs support this, and instead only support this if the device tree > > explicitly tells us it's "always on". In all other cases, just fall back > > to the RTC. This should be relatively harmless. > > I'm afraid you're confusing two things: > - the counter, which *must* carry on counting no matter what, as > (quoting the ARM ARM) "The system counter must be implemented in an > always-on power domain" > - the timer, which is allowed to be powered off, and can be tagged with > the "always-on" property to indicate that it is guaranteed to stay up > (which in practice only exists in virtual machines and never on real HW). Indeed, sorry for that confusion, and thanks for the explanations. > If your counter does stop counting when suspended, then this is starting > to either feel like a HW bug, or someone is killing the clock that feeds > this counter when entering suspend. > > If this is the former, then we need a separate quirk to indicate the > non-standard behaviour. If it is the latter, don't do it! ;-) It's beginning to seem more like a HW quirk which yields nonstandard behavior. AIUI, this SoC normally runs the counter off its 24 MHz clock, but for low power modes, this "always-on" domain switches over to a 32 KHz alternative clock. Unfortunately, the counter doesn't actually tick when run this way. I'm trying to confirm with the chip designers (Rockchip, RK3399) about the nature of the quirk, but I think we'll need a separate DT flag for this behavior. Brian