From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755886AbaFBQu1 (ORCPT ); Mon, 2 Jun 2014 12:50:27 -0400 Received: from avon.wwwdotorg.org ([70.85.31.133]:48006 "EHLO avon.wwwdotorg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753470AbaFBQuY (ORCPT ); Mon, 2 Jun 2014 12:50:24 -0400 Message-ID: <538CAB4C.9070103@wwwdotorg.org> Date: Mon, 02 Jun 2014 10:50:20 -0600 From: Stephen Warren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Viresh Kumar CC: "Rafael J. Wysocki" , Lists linaro-kernel , "linux-pm@vger.kernel.org" , Linux Kernel Mailing List , Arvind Chauhan , Stephen Warren , Doug Anderson , Russell King - ARM Linux , Nicolas Pitre , Thomas Abraham , Peter De Schrijver Subject: Re: [PATCH V4 3/3] cpufreq: Tegra: implement intermediate frequency callbacks References: <53877103.8070604@wwwdotorg.org> <5388B134.9090307@wwwdotorg.org> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/02/2014 04:06 AM, Viresh Kumar wrote: > On 30 May 2014 21:56, Stephen Warren wrote: >> ... [This patch causes issues on Tegra20] ... >> I believe the issue is this: ... > Okay, that was very helpful.. > > What about this ? (Attached for testing) : > > Author: Viresh Kumar > Date: Fri May 16 14:22:40 2014 +0530 > > cpufreq: Tegra: implement intermediate frequency callbacks > > Tegra had always been switching to intermediate frequency (pll_p_clk) since > ever. CPUFreq core has better support for handling notifications for these > frequencies and so we can adapt Tegra's driver to it. > > Also do a WARN() if clk_set_parent() fails while moving back to pll_x as we > should have atleast restored to earlier frequency on error. Tested-by: Stephen Warren I'd prefer a couple of changes though: a) Rename "pll_p_clk_count" to better describe what it represents. It represents the fact that pll_x has been prepare_enabled, so why not call it "pll_x_prepared"? b) I think it should be a Boolean not an integer; there should never be a case where the value is not 0 or 1. The only way that could happen is if the cpufreq core called tegra_target_intermediate() out of sequence too many times.