Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751664AbdFINZE (ORCPT ); Fri, 9 Jun 2017 09:25:04 -0400 Received: from mail-it0-f65.google.com ([209.85.214.65]:33806 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751545AbdFINZD (ORCPT ); Fri, 9 Jun 2017 09:25:03 -0400 MIME-Version: 1.0 In-Reply-To: References: From: "Rafael J. Wysocki" Date: Fri, 9 Jun 2017 15:25:01 +0200 X-Google-Sender-Auth: M4w_EfhXceCZQwzkUeyhuVLb58k Message-ID: Subject: Re: [PATCH 0/3] cpufreq: schedutil: Fix 4.12 regressions To: Viresh Kumar Cc: "Rafael J. Wysocki" , Rafael Wysocki , Lists linaro-kernel , Linux PM , Linux Kernel Mailing List , Vincent Guittot , Juri Lelli , Ingo Molnar , Peter Zijlstra , Patrick Bellasi , John , Srinivas Pandruvada , Joel Fernandes , Morten Rasmussen Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1269 Lines: 34 On Fri, Jun 9, 2017 at 2:32 PM, Viresh Kumar wrote: > On 9 June 2017 at 17:54, Rafael J. Wysocki wrote: >> Hi, >> >> On Fri, Jun 9, 2017 at 12:15 PM, Viresh Kumar wrote: >>> Hi Rafael, >>> >>> I have identified some regressions with the schedutil governor which >>> happen due to one of your patches that got merged in 4.12-rc1. >>> >>> This series fixes all the drivers which provide a ->target_index() >>> callback but doesn't fix the drivers which provide ->target() callback. >>> >>> Such platforms need to implement the ->resolve_freq() callback in order >>> to get this fixed and I only had hardware for testing intel_pstate, >>> which I fixed in this series. >>> >>> I am wondering if there is another way to fix this issue (than what I >>> tried) or if we should revert the offending commit (39b64aa1c007) and >>> look for other solutions. >> >> To my eyes, patch [1/3] fixes the problem and then the remaining ones >> deal with the issues resulting from that. > > So I saw the issue reported and fixed by 2/3 first and noticed 1/3 while > doing code reviews. So, 1/3 isn't the culprit really as the problem happens > without it as well. I see. OK, let me consider that. Thanks, Rafael