From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932490AbcBCCWk (ORCPT ); Tue, 2 Feb 2016 21:22:40 -0500 Received: from mail-pf0-f176.google.com ([209.85.192.176]:35687 "EHLO mail-pf0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754866AbcBCCWi (ORCPT ); Tue, 2 Feb 2016 21:22:38 -0500 Date: Wed, 3 Feb 2016 07:52:34 +0530 From: Viresh Kumar To: "Rafael J. Wysocki" Cc: Rafael Wysocki , Juri Lelli , Lists linaro-kernel , "linux-pm@vger.kernel.org" , Saravana Kannan , Peter Zijlstra , Michael Turquette , Steve Muckle , Vincent Guittot , Morten Rasmussen , dietmar.eggemann@arm.com, Linux Kernel Mailing List Subject: Re: [PATCH 0/5] cpufreq: governors: Solve the ABBA lockups Message-ID: <20160203022234.GM31828@vireshk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02-02-16, 21:04, Rafael J. Wysocki wrote: > On Tue, Feb 2, 2016 at 11:57 AM, Viresh Kumar wrote: > > Hi Rafael, > > > > Sorry for doing this, I know you were also looking to fix this in a > > possibly different way. But I thought, it would be better if we fix > > that. We can scrap this version and take yours if that looks better. > > That's not nice to be honest. At the very least you could have asked > me about the status of my work before sending this. I started looking into this yesterday morning, while you were away and finished it before you came back. So, it would have taken more time and so I just sent them. I don't have any issues (as mentioned earlier) is discarding them for the work you might have already done. > Fortunately, though, when I started to look deeper into fixing this > problem I thought I didn't like the overall design of things in the > governor land, so I started to change that and my modifications turn > out to be sort of complementary with respect to this patchset. That's good. > Of > course, they do conflict, but I can redo my patches on top of these if > that's necessary. Yeah, even I don't have any issues in rebasing over your work, if I have to. > That said I'm going to post them in their current > form anyway, at least to show the direction I want to take going > forward. Sure. > > I thought, perhaps the best way to fix it is to give separate sysfs-ops > > to governors. And that's what I did. > > Yes, that's what I was talking about in the other thread. I must have missed that then :( > My overall impression here is that the code changes make sense. Some > details need to be improved (like the concurrent ->store for governor > tunables pointed out by Juri). > The patch changelogs suck, though. Like always :( > If your hope was that this might go into 4.5, there is a small chance > of that happening, but only if it can be made ready this week. Will try my best. > Otherwise, I'd prefer it to be redone on top of my changes. No worries. > Let me comment on the individual patches. Thanks for taking this up Rafael, really appreciate it :) -- viresh