From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753036AbdHIKG6 (ORCPT ); Wed, 9 Aug 2017 06:06:58 -0400 Received: from mail-pg0-f54.google.com ([74.125.83.54]:37020 "EHLO mail-pg0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753016AbdHIKGy (ORCPT ); Wed, 9 Aug 2017 06:06:54 -0400 Date: Wed, 9 Aug 2017 15:36:51 +0530 From: Viresh Kumar To: Sudeep Holla Cc: ALKML , LKML , DTML , Roy Franz , Harb Abdulhamid , Nishanth Menon , Arnd Bergmann , Loc Ho , Alexey Klimov , Ryan Harkin , Jassi Brar , "Rafael J. Wysocki" , linux-pm@vger.kernel.org Subject: Re: [PATCH v2 17/18] cpufreq: add support for CPU DVFS based on SCMI message protocol Message-ID: <20170809100651.GA29383@vireshk-i7> References: <1501857104-11279-1-git-send-email-sudeep.holla@arm.com> <1501857104-11279-18-git-send-email-sudeep.holla@arm.com> <20170809041840.GH28857@vireshk-i7> <97497123-2c24-6297-2d12-4f407d101b66@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <97497123-2c24-6297-2d12-4f407d101b66@arm.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 09-08-17, 10:59, Sudeep Holla wrote: > On 09/08/17 05:18, Viresh Kumar wrote: > > This stores the same handle pointer which is stored in the global variable > > below. Right? Why keep a local variable here at all ? > > Yes, you are right. Initially, started with just private pointers and > then added global. I was thinking of calling devm_scmi_handle_get per > policy to reflect the refcount correctly and drop global variable. Let > me know what you think. A refcount of 1 should be fine as well, i.e. For the cpufreq driver. Why would SCMI care if we manage multiple policies here ? Unless it makes something within SCMI core better. > > This is something special which is used only when we are returning indexes and > > I am not sure if this will have benefit here. I will rather return 0 here. > > That's what other drivers are doing. > > Indeed had 0 initially but changed as per Juri's suggestion. Maybe he suggested doing that in the fast switch routine ? As that's the normal protocol there. Though I have sent a patch today to propose using 0 there as well (you cc'd). > But is 0 > treated as failure and still running at current OPP ? You have used that in the ->get() routine. So the OPP isn't changing, but we are just trying to fetch it. cpufreq core doesn't do a lot with the value returned from here, but at one place we break early if 0 is returned. And so all drivers are returning that. > and not 0KHz I assume. Yeah, 0 KHz is dead CPU really :) > > I suppose any CPU can change the frequency of any other CPU here, right? You > > must set policy->dvfs_possible_from_any_cpu = true, from ->init() then. > > > > OK, I missed to see something like that exists, will do. Fairly recent stuff, present in pm/linux-next only. > >> + /* > >> + * But we need OPP table to function so if it is not there let's > >> + * give platform code chance to provide it for us. > >> + */ > > > > How are we getting the OPPs? DT or non DT ? > > > > Non DT :), from the firmware. I would improve the above comment in that case to clearly say that OPPs are added by the platform, lets wait for it. -- viresh