From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752967AbbJPGCg (ORCPT ); Fri, 16 Oct 2015 02:02:36 -0400 Received: from mail-pa0-f43.google.com ([209.85.220.43]:36135 "EHLO mail-pa0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752088AbbJPGCd (ORCPT ); Fri, 16 Oct 2015 02:02:33 -0400 Date: Fri, 16 Oct 2015 11:32:27 +0530 From: Viresh Kumar To: Stephen Boyd Cc: Rob Herring , Rafael Wysocki , nm@ti.com, linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, rob.herring@linaro.org, lee.jones@linaro.org, Mark Brown , devicetree@vger.kernel.org, Ian Campbell , Kumar Gala , open list , Mark Rutland , Pawel Moll , "Rafael J. Wysocki" Subject: Re: [PATCH 01/16] PM / OPP: Add 'supply-names' binding Message-ID: <20151016060227.GS19018@linux> References: <2b87b162eabd1570ae2311e1ef8655acda72f678.1441972771.git.viresh.kumar@linaro.org> <55F72C97.2030306@kernel.org> <20151016002243.GA23912@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151016002243.GA23912@codeaurora.org> 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 On 15-10-15, 17:22, Stephen Boyd wrote: > I'm lost why we need this property at all. What happened to using > > opp-microvolt-0 = <1 2 3>; > opp-microvolt-1 = <1>; > opp-microvolt-2 = <3 4 5>; > etc. Perhaps you are confusing this with the bindings we came up for picking right voltage levels based on the cuts/version of the hardware we are running on. The problem that Lee Jones mentioned and that can be used in your case as well. > That seems to avoid any problem with 3 vs. 1 element properties > combined into one large array. That's not the problem I was trying to solve here. > Having supply-names seems too > brittle and would tie us to a particular OPP user's decision to > call supplies by some name. No. The name has to match the -supply property present in the device's node, that's why we need this property :) > Also, I've seen devices that are split across two power domains. > These devices aren't CPUs, but they are other devices including > L2 caches. So we're going to need either multiple regulator > support or multiple "power domain at a particular performance > levels" support somehow. Right, that's a good example of why we need multi-regulator support :) -- viresh