From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752664AbdGSGyM (ORCPT ); Wed, 19 Jul 2017 02:54:12 -0400 Received: from mail-pg0-f52.google.com ([74.125.83.52]:32793 "EHLO mail-pg0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751922AbdGSGyK (ORCPT ); Wed, 19 Jul 2017 02:54:10 -0400 Date: Wed, 19 Jul 2017 12:24:06 +0530 From: Viresh Kumar To: Leonard Crestez Cc: "Rafael J. Wysocki" , Shuah Khan , linux-kselftest@vger.kernel.org, Octavian Purdila , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] selftests: cpufreq: Check cpuinfo_cur_freq set as expected Message-ID: <20170719065406.GE352@vireshk-i7> References: <704cfb6696840b3838576ea583b8ab8ed2265aaf.1499858779.git.leonard.crestez@nxp.com> <20170713085537.GD352@vireshk-i7> <1500406459.11874.1.camel@nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1500406459.11874.1.camel@nxp.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 18-07-17, 22:34, Leonard Crestez wrote: > The semantics of scaling_cur_freq and cpuinfo_cur_freq are not very > clear to me. cpuinfo_cur_freq reads the frequency right from hardware all the time and so can be slow. It can only be read by root if I remember correctly. Whereas scaling_cur_freq tries to read the cached frequency. But it has changed a bit with the below mentioned patch. > In my particular case I need to check cpuinfo_cur_freq because this is > what ends up returning the rate of the arm clk. Otherwise > scaling_cur_freq just returns policy->cur Yeah, we may actually need to use cpuinfo_cur_freq as that is what ends up giving the real freq. > unless the driver has a > setpolicy function (I don't understand that condition). That's because the core doesn't know the cached freq for setpolicy drivers and so we need to call the ->get() callback. But for non setpolicy drivers, core already has the cached value. -- viresh