From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752498AbbGaDSu (ORCPT ); Thu, 30 Jul 2015 23:18:50 -0400 Received: from mail-pd0-f177.google.com ([209.85.192.177]:34962 "EHLO mail-pd0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751235AbbGaDSs (ORCPT ); Thu, 30 Jul 2015 23:18:48 -0400 Date: Fri, 31 Jul 2015 08:48:41 +0530 From: Viresh Kumar To: Radivoje Jovanovic Cc: Punit Agrawal , rjw@rjwysocki.net, LKML , Linux PM , Zhang Rui , Eduardo Valentin , Radivoje Jovanovic Subject: Re: [PATCH] thermal/cpu_cooling: remove local cooling state variable Message-ID: <20150731031841.GH17794@linux> References: <1437516835-198750-1-git-send-email-radivoje.jovanovic@linux.intel.com> <9hhegjxbmqz.fsf@e105922-lin.cambridge.arm.com> <20150724100905.7e2e53f4@radivoje-desk2> <9hhoaiuap3m.fsf@e105922-lin.cambridge.arm.com> <20150730080541.GD31351@linux> <20150730132130.3c957267@radivoje-desk2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150730132130.3c957267@radivoje-desk2> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thanks. I will try to add more layman terms here to map cooling state with frequencies. So, the cooling state 0 maps to the highest frequency the cpufreq table supports, and the highest cooling state n maps to the lowest frequency. Right ? On 30-07-15, 13:21, Radivoje Jovanovic wrote: > In this case both userspace thermal solution and cpu_cooling are > changing policy->max and the userspace solution will let governor or HW > (depends on architecture) decide the clipped-freq. Now let us say that > cpu_cooling has 4 available states 0-3 Lets say: 0 == 1.2 GHz 1 == 1.1 GHz 2 == 1 GHz 3 == 800 MHz > and let us say that cpu_cooling > has set the state 1 as the last state. i.e. cpu_cooling says "don't go over 1.1 GHz".. > Now userspace component comes in > and changes the state of the system that matches cpu_cooling state 0. So, policy->max reaches 1.2 GHz and that is not in sync with cpu_cooling. Right ? > cpu_cooling is unaware of this change and does not change the local > cur_state. That's where I think you one of us might be incorrect. At this point when policy->max is changed to 1.2 GHz, a notifier will get issued to cpu_cooling, which will bring policy->max again to 1.1 GHz and so things will be back in control. > Now the temperature changes and cpu_cooling should change > the system state to 1 (userspace component malfunctioned and is not > picking up this change) but since the cur_state is already at 1 > cpu_cooling will not do anything since it believes it is in the correct > state. Hope this explains it better -- viresh