From mboxrd@z Thu Jan 1 00:00:00 1970 From: Saravana Kannan Subject: Re: [PATCH 04/18] cpufreq: Manage fallback policies in a list Date: Thu, 05 Feb 2015 14:55:57 -0800 Message-ID: <54D3F4FD.1080602@codeaurora.org> References: <6147604.f4mimnOd4x@vostro.rjw.lan> <54D2CD76.2030609@codeaurora.org> <1746505.56yzpQ04cT@vostro.rjw.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from smtp.codeaurora.org ([198.145.11.231]:45007 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750818AbbBEWz7 (ORCPT ); Thu, 5 Feb 2015 17:55:59 -0500 In-Reply-To: <1746505.56yzpQ04cT@vostro.rjw.lan> Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: "Rafael J. Wysocki" Cc: Viresh Kumar , Linaro Kernel Mailman List , "linux-pm@vger.kernel.org" , Stephen Boyd , Prarit Bhargava On 02/05/2015 07:11 AM, Rafael J. Wysocki wrote: > On Wednesday, February 04, 2015 05:55:02 PM Saravana Kannan wrote: >> On 02/04/2015 03:20 PM, Rafael J. Wysocki wrote: >>> On Wednesday, February 04, 2015 02:28:55 PM Saravana Kannan wrote: >>>> On 02/03/2015 10:20 PM, Viresh Kumar wrote: >>>>> On 4 February 2015 at 03:58, Saravana Kannan wrote: >>>>>> Can you explain why we need a fallback list in the first place? Now that we >>>>>> are not destroying and creating policy objects, I don't see any point in the >>>>>> fallback list. >>>>> >>>>> Because we wanted to mark the policy inactive. But as I have introduced another >>>>> field for that now, probably it can be fixed. Will check again on what >>>>> can be done. >>>> >>>> Thanks. That's why I was asking. Now that you have another flag. Also, >>>> you might not even need a flag. You can just check if policy->cpus is >>>> empty (btw, I think we should let that go to empty) >>> >>> So the idea would be to avoid clearig cpufreq_cpu_data during offline >>> tear-down (because we know that the CPU is offline anyway) and then start >>> using the same policy pointer during offline? >> >> Yeah. We still don't clear the policy->cpus today when the last CPU goes >> down. But that can be done easily by changing a few "if" conditions and >> rearranging the hotplug notifier code (I think it's mostly there with >> this series). Once we clear policy->cpus when all CPUs are offline, we >> can just use that data to figure out if it's "active" or not. > > OK > > I'm still concerned about the case when the last policy CPU is physically > going away, in which we do the offline as a preliminary step and then > will go for full CPU device unregistration. I made sure that would work in the patch series I sent out a while back. I now need to make sure that Viresh's patch series account for it correctly. I'll make sure to review this series at least once a week. The way to handle the case you mentioned is by treating the subsys_interface based add/remove ops as physical add/remove and the hotplug add/remove as logical add/remove. -Saravana -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation