From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751291AbdGMIzn (ORCPT ); Thu, 13 Jul 2017 04:55:43 -0400 Received: from mail-pf0-f179.google.com ([209.85.192.179]:35369 "EHLO mail-pf0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750949AbdGMIzl (ORCPT ); Thu, 13 Jul 2017 04:55:41 -0400 Date: Thu, 13 Jul 2017 14:25:37 +0530 From: Viresh Kumar To: Leonard Crestez Cc: Shuah Khan , linux-kselftest@vger.kernel.org, "Rafael J. Wysocki" , 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: <20170713085537.GD352@vireshk-i7> References: <704cfb6696840b3838576ea583b8ab8ed2265aaf.1499858779.git.leonard.crestez@nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <704cfb6696840b3838576ea583b8ab8ed2265aaf.1499858779.git.leonard.crestez@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 12-07-17, 14:29, Leonard Crestez wrote: > This checks that the cpufreq driver actually sets the requested > frequency. > > Signed-off-by: Leonard Crestez > > --- > > I've been looking at using kselftests for imx. This patch exposes an > issue with the imx6 cpufreq driver on imx6sx where frequencies are set > incorrectly because of clk mishandling. This is already caught by some > internal test scripts which also run against upstream but it's nice to > make this visible through kselftest. Sure, thanks for that. > I'm not sure it's correct to check that frequency matches exactly, > perhaps something like a 5% tolerance should be included for complex > drivers where the target freq is only a "hint"? We can do better, see below.. > I checked intel_pstate > but it doesn't even seem to expose an userspace governor for manual > frequency selection anyway. Sure, and so that wouldn't be affected by this. > Unfortunately cpufreq selftests don't seem to have a clear idea of > "pass" or "fail" results. Yeah, I had this test setup for a while and just pushed it through. Over that many tests aren't really tests but just looking out for crashes, etc. Never got a chance to improve it :( > This patch will just print some TAP-like > "ok" and "not ok" lines but failures are not actually propagated upwards > in a well-defined way. That would be fine for now. > Have you considered what it would take to TAP-ify the output of cpufreq > tests? Output is very complex so perhaps it might make sense to adopt some > sort of subtest syntax for kselftest, something like this: Not yet :( > diff --git a/tools/testing/selftests/cpufreq/cpufreq.sh b/tools/testing/selftests/cpufreq/cpufreq.sh > index 1ed3832..323b5bb 100755 > --- a/tools/testing/selftests/cpufreq/cpufreq.sh > +++ b/tools/testing/selftests/cpufreq/cpufreq.sh > @@ -151,6 +151,14 @@ test_all_frequencies() > # Set all frequencies one-by-one > for freq in $freqs; do > set_cpu_frequency $1 $freq > + > + local cur_freq > + cur_freq=`cat $CPUFREQROOT/$1/cpuinfo_cur_freq` Yes, we want to verify if freq change happened or not, but may be only reading scaling_cur_freq would be enough for now? And that wouldn't be a problem for X86 (which Rafael mentioned) as well IIUC. -- viresh