From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 750F0C3279B for ; Wed, 4 Jul 2018 08:43:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 387CA2083E for ; Wed, 4 Jul 2018 08:43:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 387CA2083E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933822AbeGDImy (ORCPT ); Wed, 4 Jul 2018 04:42:54 -0400 Received: from foss.arm.com ([217.140.101.70]:33338 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933791AbeGDIjP (ORCPT ); Wed, 4 Jul 2018 04:39:15 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D41777A9; Wed, 4 Jul 2018 01:39:14 -0700 (PDT) Received: from [10.1.206.75] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0C7CE3F5BA; Wed, 4 Jul 2018 01:39:12 -0700 (PDT) Subject: Re: [PATCH 0/2] Allwinner A64 timer workaround To: Daniel Lezcano , Samuel Holland , Maxime Ripard , Chen-Yu Tsai , Catalin Marinas , Will Deacon , Thomas Gleixner Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com, Mark Rutland References: <20180511022751.9096-1-samuel@sholland.org> <2c16d5ab-38f7-8f3e-875c-19e8032f440a@arm.com> <5283f98e-6443-db7a-fe51-6379ed19002c@arm.com> <24b78819-5e3f-431f-3987-f7409742ef07@linaro.org> From: Marc Zyngier Organization: ARM Ltd Message-ID: <1d75c538-9166-5eec-a08c-b168f9770bd1@arm.com> Date: Wed, 4 Jul 2018 09:39:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <24b78819-5e3f-431f-3987-f7409742ef07@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/07/18 09:23, Daniel Lezcano wrote: > On 04/07/2018 10:16, Marc Zyngier wrote: >> On 03/07/18 19:42, Samuel Holland wrote: >>> On 07/03/18 10:09, Marc Zyngier wrote: >>>> On 11/05/18 03:27, Samuel Holland wrote: >>>>> Hello, >>>>> >>>>> Several people (including me) have experienced extremely large system >>>>> clock jumps on their A64-based devices, apparently due to the architectural >>>>> timer going backward, which is interpreted by Linux as the timer wrapping >>>>> around after 2^56 cycles. >>>>> >>>>> Investigation led to discovery of some obvious problems with this SoC's >>>>> architectural timer, and this patch series introduces what I believe is >>>>> the simplest workaround. More details are in the commit message for patch >>>>> 1. Patch 2 simply enables the workaround in the device tree. >>>> >>>> What's the deal with this series? There was a couple of nits to address, and >>>> I was more or less expecting a v2. >>> >>> I got reports that people were still occasionally having clock jumps after >>> applying this series, so I wanted to attempt a more complete fix, but I haven't >>> had time to do any deeper investigation. I think this series is still beneficial >>> even if it's not a complete solution, so I'll come back with another patch on >>> top of this if/once I get it fully fixed. >>> >>> I'll prepare a v2 with a bounded loop. Presumably, 3 * (max CPU Hz) / (24MHz >>> timer) ≈ 150 should be a conservative iteration limit? >> >> Should be OK. >> >> Maxime: How do you want to deal with the documentation aspect? We need >> an erratum number, but AFAIU the concept hasn't made it into the silicom >> vendor's brain yet. Any chance you could come up with something that >> uniquely identifies this? >> >>> Also, does this make sense to CC to stable? >> >> Probably not, as the HW never worked, so it is not a regression. > > If the patches fix a bug which already exist, it makes sense to > propagated the fix back to the stable versions. That's your call, but I'm not supportive of that decision, specially as we have information from the person developing the workaround that this doesn't fully address the issue. M. -- Jazz is not dead. It just smells funny... From mboxrd@z Thu Jan 1 00:00:00 1970 From: marc.zyngier@arm.com (Marc Zyngier) Date: Wed, 4 Jul 2018 09:39:11 +0100 Subject: [PATCH 0/2] Allwinner A64 timer workaround In-Reply-To: <24b78819-5e3f-431f-3987-f7409742ef07@linaro.org> References: <20180511022751.9096-1-samuel@sholland.org> <2c16d5ab-38f7-8f3e-875c-19e8032f440a@arm.com> <5283f98e-6443-db7a-fe51-6379ed19002c@arm.com> <24b78819-5e3f-431f-3987-f7409742ef07@linaro.org> Message-ID: <1d75c538-9166-5eec-a08c-b168f9770bd1@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 04/07/18 09:23, Daniel Lezcano wrote: > On 04/07/2018 10:16, Marc Zyngier wrote: >> On 03/07/18 19:42, Samuel Holland wrote: >>> On 07/03/18 10:09, Marc Zyngier wrote: >>>> On 11/05/18 03:27, Samuel Holland wrote: >>>>> Hello, >>>>> >>>>> Several people (including me) have experienced extremely large system >>>>> clock jumps on their A64-based devices, apparently due to the architectural >>>>> timer going backward, which is interpreted by Linux as the timer wrapping >>>>> around after 2^56 cycles. >>>>> >>>>> Investigation led to discovery of some obvious problems with this SoC's >>>>> architectural timer, and this patch series introduces what I believe is >>>>> the simplest workaround. More details are in the commit message for patch >>>>> 1. Patch 2 simply enables the workaround in the device tree. >>>> >>>> What's the deal with this series? There was a couple of nits to address, and >>>> I was more or less expecting a v2. >>> >>> I got reports that people were still occasionally having clock jumps after >>> applying this series, so I wanted to attempt a more complete fix, but I haven't >>> had time to do any deeper investigation. I think this series is still beneficial >>> even if it's not a complete solution, so I'll come back with another patch on >>> top of this if/once I get it fully fixed. >>> >>> I'll prepare a v2 with a bounded loop. Presumably, 3 * (max CPU Hz) / (24MHz >>> timer) ? 150 should be a conservative iteration limit? >> >> Should be OK. >> >> Maxime: How do you want to deal with the documentation aspect? We need >> an erratum number, but AFAIU the concept hasn't made it into the silicom >> vendor's brain yet. Any chance you could come up with something that >> uniquely identifies this? >> >>> Also, does this make sense to CC to stable? >> >> Probably not, as the HW never worked, so it is not a regression. > > If the patches fix a bug which already exist, it makes sense to > propagated the fix back to the stable versions. That's your call, but I'm not supportive of that decision, specially as we have information from the person developing the workaround that this doesn't fully address the issue. M. -- Jazz is not dead. It just smells funny...