From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S944216AbdDTJxU (ORCPT ); Thu, 20 Apr 2017 05:53:20 -0400 Received: from mail-yb0-f171.google.com ([209.85.213.171]:34226 "EHLO mail-yb0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S944191AbdDTJww (ORCPT ); Thu, 20 Apr 2017 05:52:52 -0400 Date: Thu, 20 Apr 2017 15:22:48 +0530 From: Viresh Kumar To: Sudeep Holla Cc: Rafael Wysocki , ulf.hansson@linaro.org, Kevin Hilman , Viresh Kumar , Nishanth Menon , Stephen Boyd , linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Vincent Guittot , robh+dt@kernel.org, lina.iyer@linaro.org, rnayak@codeaurora.org, devicetree@vger.kernel.org Subject: Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains Message-ID: <20170420095248.GJ5436@vireshk-i7> References: <0a7146f9-72f1-317c-3aab-770a72462968@arm.com> <20170413053736.GM5910@vireshk-i7> <3adbef6a-7b43-528f-e88f-c2121d30a5d3@arm.com> <20170417052758.GF28191@vireshk-i7> <95aa4b97-4e1a-13bb-f4d8-982b778012ba@arm.com> <20170419114740.GD5436@vireshk-i7> <9dee7c0d-e5f4-9fcd-3c92-bf7ec9d43a3b@arm.com> <20170420052533.GF5436@vireshk-i7> <34c7fb69-0324-ad06-678d-8726064e9a18@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34c7fb69-0324-ad06-678d-8726064e9a18@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 20-04-17, 10:43, Sudeep Holla wrote: > Just that the term performance is closely related to frequency, it needs > to be explicit on what *exactly* it means. As it stands now, > it can be used for OPP as I explain which controls both but as you > clarify that's not what it's designed for. We are talking about active states of a power domain here and *performance* is the best word I got. And yes we can still have frequency as a configurable here, just that current platforms don't have it. > I am not sure if choosing highest performance point makes it difficult > to fit it in regulator framework. It could be some configuration. I was just pointing out a difference :) > Also IIUC the actual programming is done in the firmware in this case > and I fail to see how that adds lot of platform code. Oh I meant that for converting general regulator only cases to OPP. No firmware was involved there. -- viresh