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=-11.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable 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 90BD6C433E6 for ; Sat, 11 Jul 2020 10:46:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 67EEB207D4 for ; Sat, 11 Jul 2020 10:46:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=aurel32.net header.i=@aurel32.net header.b="T3rF3OsC" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726261AbgGKKq5 (ORCPT ); Sat, 11 Jul 2020 06:46:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33470 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726203AbgGKKq5 (ORCPT ); Sat, 11 Jul 2020 06:46:57 -0400 X-Greylist: delayed 2696 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Sat, 11 Jul 2020 03:46:57 PDT Received: from hall.aurel32.net (hall.aurel32.net [IPv6:2001:bc8:30d7:100::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6A1E7C08C5DD; Sat, 11 Jul 2020 03:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=aurel32.net ; s=202004.hall; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Content-Transfer-Encoding:From:Reply-To: Subject:Content-ID:Content-Description:X-Debbugs-Cc; bh=Brj2Uur/vWw8fobBoxnPCAHoheyz+8lGCkL8KGgE4kk=; b=T3rF3OsCphU2NAQsomSG79Gt7G toOUn6F5KjoMhxsr7qwX0TqKajhOBb5Yiwwk7CK6VeFp8KlTLYtmadtvGpULqvEEUVGwymznvessY 5skk9TM12Wf3h47kZUDIbTMD+cCSJKHfCtijxevGHedRQlD857qWYp3owOp3DlgxEyGEfxGy4830G gnkd1pPeUZxEgirqLUdI96a9Rw8nnJCgofAUmv0QwIE1RbxsMZ1HBL1dUTMt182DuKbQuKqqducmU BmSvsX7hSsF8s3RJnoBcSCU0ZChdIhHvDUwQDF85JjEsXYUhEK2eAq0gPt7+eFVxbqotky0YlLYOj IDry8pzw==; Received: from [2a01:e35:2fdd:a4e1:fe91:fc89:bc43:b814] (helo=ohm.rr44.fr) by hall.aurel32.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1juCKN-0005Xf-Iz; Sat, 11 Jul 2020 12:01:51 +0200 Received: from aurel32 by ohm.rr44.fr with local (Exim 4.94) (envelope-from ) id 1juCKL-00A3er-Fn; Sat, 11 Jul 2020 12:01:49 +0200 Date: Sat, 11 Jul 2020 12:01:49 +0200 From: Aurelien Jarno To: Sasha Levin Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, Serge Semin , Alexey Malahov , Jiaxun Yang , Thomas Bogendoerfer , Paul Burton , Ralf Baechle , Arnd Bergmann , Rob Herring , devicetree@vger.kernel.org, linux-mips@vger.kernel.org Subject: Re: [PATCH AUTOSEL 4.19 080/106] mips: Add udelay lpj numbers adjustment Message-ID: <20200711100149.GA2397222@aurel32.net> Mail-Followup-To: Sasha Levin , linux-kernel@vger.kernel.org, stable@vger.kernel.org, Serge Semin , Alexey Malahov , Jiaxun Yang , Thomas Bogendoerfer , Paul Burton , Ralf Baechle , Arnd Bergmann , Rob Herring , devicetree@vger.kernel.org, linux-mips@vger.kernel.org References: <20200608232238.3368589-1-sashal@kernel.org> <20200608232238.3368589-80-sashal@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200608232238.3368589-80-sashal@kernel.org> User-Agent: Mutt/1.14.0 (2020-05-02) Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 2020-06-08 19:22, Sasha Levin wrote: > From: Serge Semin > > [ Upstream commit ed26aacfb5f71eecb20a51c4467da440cb719d66 ] > > Loops-per-jiffies is a special number which represents a number of > noop-loop cycles per CPU-scheduler quantum - jiffies. As you > understand aside from CPU-specific implementation it depends on > the CPU frequency. So when a platform has the CPU frequency fixed, > we have no problem and the current udelay interface will work > just fine. But as soon as CPU-freq driver is enabled and the cores > frequency changes, we'll end up with distorted udelay's. In order > to fix this we have to accordinly adjust the per-CPU udelay_val > (the same as the global loops_per_jiffy) number. This can be done > in the CPU-freq transition event handler. We subscribe to that event > in the MIPS arch time-inititalization method. > > Co-developed-by: Alexey Malahov > Signed-off-by: Alexey Malahov > Signed-off-by: Serge Semin > Reviewed-by: Jiaxun Yang > Cc: Thomas Bogendoerfer > Cc: Paul Burton > Cc: Ralf Baechle > Cc: Arnd Bergmann > Cc: Rob Herring > Cc: devicetree@vger.kernel.org > Signed-off-by: Thomas Bogendoerfer > Signed-off-by: Sasha Levin > --- > arch/mips/kernel/time.c | 70 +++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 70 insertions(+) > > diff --git a/arch/mips/kernel/time.c b/arch/mips/kernel/time.c > index bfe02ded25d1..1e631a484ddf 100644 > --- a/arch/mips/kernel/time.c > +++ b/arch/mips/kernel/time.c > @@ -22,12 +22,82 @@ > #include > #include > #include > +#include > +#include > > #include > #include > #include > #include > > +#ifdef CONFIG_CPU_FREQ > + > +static DEFINE_PER_CPU(unsigned long, pcp_lpj_ref); > +static DEFINE_PER_CPU(unsigned long, pcp_lpj_ref_freq); > +static unsigned long glb_lpj_ref; > +static unsigned long glb_lpj_ref_freq; > + > +static int cpufreq_callback(struct notifier_block *nb, > + unsigned long val, void *data) > +{ > + struct cpufreq_freqs *freq = data; > + struct cpumask *cpus = freq->policy->cpus; ^^^^^^ The policy member has been added in kernel 5.2, so kernel 4.19.129 and later do not build anymore when CONFIG_CPU_FREQ=y. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net