From patchwork Wed May 14 21:42:55 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 4178251 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 24308BFF02 for ; Wed, 14 May 2014 21:45:50 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 40633201BA for ; Wed, 14 May 2014 21:45:49 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DD3952017D for ; Wed, 14 May 2014 21:45:47 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1WkgxN-0003DF-34; Wed, 14 May 2014 21:43:21 +0000 Received: from mail-vc0-x22e.google.com ([2607:f8b0:400c:c03::22e]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WkgxK-000396-PN for linux-arm-kernel@lists.infradead.org; Wed, 14 May 2014 21:43:19 +0000 Received: by mail-vc0-f174.google.com with SMTP id lh14so3268722vcb.19 for ; Wed, 14 May 2014 14:42:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=G0PzDQ6C/AXMlGR+P9b8eCc7iNOe8HuWv2KGOWUCoDI=; b=YTI4pD0ruLDThSfh2hz4xhm4wJdvOiw1j7Sti3B73nUiDSb80Zaos2rZ3pQdTgNucz iRdIo+DGw2r5MFMYKI5duTzY9c3LujLteziiWHFohrcyHdUABGBsBQQ7P/WmlfD8mWxh YJTB91opOK7uWFz/uCNpSuiXyFBvpJEkNaViiepfRzzJvVkqrkZNYFph7NSuus2Z2r8E O1IX9SiWG4msmBsAwL3UvKJsYAJ6/+N1cFSoyL2Q8Yd0e6aNlpgfRiPY324CdswCAVbH /XgKsFFwTVmZlfh7uwJQV0+Z7j4pueT7tHXzZn29LymfeNql/EQaM38bWr2c9DdLWL16 sKqQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=G0PzDQ6C/AXMlGR+P9b8eCc7iNOe8HuWv2KGOWUCoDI=; b=fvfKwgWIFR2S0WkEVP6yi072ON+8Dmz/OrVfBUtWX3BYMqql5jC2mAlN0r9Y5ECxs3 XgFVdXoedemg9uHMYvfbwcbKwOzidPzKLkCCK6bkYSb1ABSEnAU6OhMpf4sq1YArcgYu 49368qnv21CwJidE5mV0NywZJPDF4QEZRUZ48= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=G0PzDQ6C/AXMlGR+P9b8eCc7iNOe8HuWv2KGOWUCoDI=; b=e6nIXzlSjM1OvczScqp8n83i1brxBvVZ+pv0g1w0f/TbczTxEHDcRTBcj3wsCQVqku /41OgK5hn9BGOAmzIR4WhpKiFLSjKKsdLcT5zAX9XYqlxBb9LxtlTPpw4W92PvMJ1VlU 0nIe37cXakgLFrjPytgZyPlop4vi9I5InMj1RcPQo1GiZfoxtwyjYQqbABiYJgb+EjHd 94SddHyorDePw+zfQBUEiqbMYpfTgfQirAL1W/xA2Y/9jWKhv6oTvXQLutuLpDiiFAcG APwhnBSAwWA2RHbIRf1mXWWBZ+gYJQs5hoNqnNHm6O/JjY/RXrkHdCD4tDDKU2d57t8z l0+w== X-Gm-Message-State: ALoCoQmSXcC608OTHkDaulbR5s3FcZrRM7ldlRDdof/5bz99jAcOeRY1Z1xPBEvIt4gogVLZ4bBF MIME-Version: 1.0 X-Received: by 10.221.40.193 with SMTP id tr1mr4855105vcb.31.1400103775964; Wed, 14 May 2014 14:42:55 -0700 (PDT) Received: by 10.52.66.140 with HTTP; Wed, 14 May 2014 14:42:55 -0700 (PDT) In-Reply-To: References: <20140508192209.GH3693@n2100.arm.linux.org.uk> <20140508205223.GI3693@n2100.arm.linux.org.uk> <20140509091824.GL3693@n2100.arm.linux.org.uk> <20140509182245.GM3693@n2100.arm.linux.org.uk> <5372998F.6020502@wwwdotorg.org> Date: Wed, 14 May 2014 14:42:55 -0700 X-Google-Sender-Auth: oIEsm9IyIdXVFVZvGjMhS9px3XA Message-ID: Subject: Re: [PATCH] ARM: Don't ever downscale loops_per_jiffy in SMP systems# From: Doug Anderson To: Nicolas Pitre X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140514_144318_907100_A7BD5488 X-CRM114-Status: GOOD ( 24.90 ) X-Spam-Score: -0.8 (/) Cc: Russell King - ARM Linux , Santosh Shilimkar , Stephen Warren , Marc Zyngier , Viresh Kumar , "Rafael J. Wysocki" , Stephen Warren , Will Deacon , "linux-kernel@vger.kernel.org" , Paul Gortmaker , John Stultz , "olof@lixom.net" , David Riley , Shawn Guo , Sonny Rao , Stephen Boyd , "linux-arm-kernel@lists.infradead.org" X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi, On Tue, May 13, 2014 at 4:29 PM, Nicolas Pitre wrote: > On Tue, 13 May 2014, Nicolas Pitre wrote: > >> On Tue, 13 May 2014, Stephen Warren wrote: >> >> > On 05/13/2014 03:50 PM, Doug Anderson wrote: >> > ... >> > > ...but then I found the true problem shows up when we transition >> > > between very low frequencies on exynos, like between 200MHz and >> > > 300MHz. While transitioning between frequencies the system >> > > temporarily bumps over to the "switcher" PLL running at 800MHz while >> > > waiting for the main PLL to stabilize. No CPUFREQ notification is >> > > sent for that. That means there's a period of time when we're running >> > > at 800MHz but loops_per_jiffy is calibrated at between 200MHz and >> > > 300MHz. >> > > >> > > >> > > I'm welcome to any suggestions for how to address this. It sorta >> > > feels like it would be a common thing to have a temporary PLL during >> > > the transition, ... >> > >> > We definitely do that on Tegra for some cpufreq transitions. >> >> Ouch... If this is a common strategy to use a third frequency during a >> transition phase, especially if that frequency is way off (800MHz vs >> 200-300MHz) then it is something the cpufreq layer must capture and >> advertise. > > Of course if only the loops_per_jiffy scaling does care about frequency > changes these days, and if in those cases udelay() can instead be moved > to a timer source on those hick-up prone platforms, then all this is > fairly theoretical and may not be worth pursuing. Yup, I think I'm going to abandon this. If anyone ever runs into this problem later and can't use a bloody timer, hopefully they'll stumble on this thread and at least end up with a good starting point. For the record, the fix I made locally (which actually worked) was: 1. Add a new "temp" field to cpufreq_freqs: ...depending on whether all users of this structure zero-initialize it (I didn't check) you might also need to add a flag to say whether the temp field is actually valid. 2. Set the "temp" to the switching PLL frequency in the cpufreq driver. 3. Change the ARM cpufreq_callback() to take the temp freq into account: + if (val == CPUFREQ_PRECHANGE) { + old_freq = freq->old; + new_freq = max(freq->new, freq->temp); + } else if (val == CPUFREQ_POSTCHANGE) { + old_freq = max(freq->old, freq->temp); + new_freq = freq->new; + } ...then use old_freq and new_freq in the place of freq->old and freq->new -Doug --- a/include/linux/cpufreq.h +++ b/include/linux/cpufreq.h @@ -133,6 +133,7 @@ struct cpufreq_freqs { unsigned int cpu; /* cpu nr */ unsigned int old; unsigned int new; + unsigned int temp; u8 flags; /* flags of cpufreq_driver, see below. */ };