From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751387AbdGRF6J (ORCPT ); Tue, 18 Jul 2017 01:58:09 -0400 Received: from mail-pf0-f180.google.com ([209.85.192.180]:34247 "EHLO mail-pf0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751026AbdGRF6H (ORCPT ); Tue, 18 Jul 2017 01:58:07 -0400 Date: Tue, 18 Jul 2017 11:28:04 +0530 From: Viresh Kumar To: Rob Herring Cc: Greg Kroah-Hartman , Mark Rutland , Vincent Guittot , Mark Brown , Stephen Boyd , Rajendra Nayak , Shiraz Hashim , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" Subject: Re: [RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings Message-ID: <20170718055804.GV352@vireshk-i7> References: <0610277aef9830cff53b7b53cf41cc54886fdc7f.1499770771.git.viresh.kumar@linaro.org> <20170713093608.GF352@vireshk-i7> <20170717173407.x5qjnrxqkjvn5vdm@rob-hp-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170717173407.x5qjnrxqkjvn5vdm@rob-hp-laptop> 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 17-07-17, 12:34, Rob Herring wrote: > On Thu, Jul 13, 2017 at 03:06:08PM +0530, Viresh Kumar wrote: > > On 12-07-17, 16:28, Rob Herring wrote: > > > Display is a pretty well known use case here. Do you have other > > > examples in mind? > > > > No, I don't. > > > > @Stephen: Do you have more cases like this for your Qcom products ? > > > > > Other cases I've seen are automotive with keeping > > > the backup camera going and CAN bus handling. Though my new car has a > > > flicker shortly after coming on, so I guess the handoff doesn't have > > > to be completely seemless. :) > > > > :) > > > > > [...] > > > > > > > + mmc: mmc@0x0 { > > > > + ... > > > > + ... > > > > + vmmc-supply = <&twl_reg1>; > > > > + vmmcaux-supply = <&twl_reg2>; > > > > + boot-constraint-supplies = "vmmc", "vmmcaux"; > > > > + boot-constraint-uV = <1800000 2000000>, /* vmmc */ > > > > + <2000000 2000000>; /* vmmcaux */ > > > > > > No. I don't like how this is going to extend to all the other bindings > > > people are going to want constraints for. We don't need a parallel set > > > of properties for each type of binding. > > > > Fair enough. > > > > > I'm not convinced that we need a general solution for what's probably > > > a handful of things that need a handoff versus just re-initialize. > > > > What about keeping the first four patches (mostly) as it is and adding > > these constraints from a platform specific constraints driver ? > > > > Will that be acceptable ? > > Meaning no DT binding? Then I don't care (from a DT perspective). Yeah, kind of the way we decided to do the first step in the power domain performance state series [1]. And then later on we can see how to get such information from DT, as the kernel needs this information irrespective of the way we solve this problem in the kernel. -- viresh [1] https://marc.info/?l=linux-kernel&m=149802907711074&w=2 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Viresh Kumar Subject: Re: [RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings Date: Tue, 18 Jul 2017 11:28:04 +0530 Message-ID: <20170718055804.GV352@vireshk-i7> References: <0610277aef9830cff53b7b53cf41cc54886fdc7f.1499770771.git.viresh.kumar@linaro.org> <20170713093608.GF352@vireshk-i7> <20170717173407.x5qjnrxqkjvn5vdm@rob-hp-laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20170717173407.x5qjnrxqkjvn5vdm@rob-hp-laptop> Sender: linux-kernel-owner@vger.kernel.org To: Rob Herring Cc: Greg Kroah-Hartman , Mark Rutland , Vincent Guittot , Mark Brown , Stephen Boyd , Rajendra Nayak , Shiraz Hashim , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" List-Id: devicetree@vger.kernel.org On 17-07-17, 12:34, Rob Herring wrote: > On Thu, Jul 13, 2017 at 03:06:08PM +0530, Viresh Kumar wrote: > > On 12-07-17, 16:28, Rob Herring wrote: > > > Display is a pretty well known use case here. Do you have other > > > examples in mind? > > > > No, I don't. > > > > @Stephen: Do you have more cases like this for your Qcom products ? > > > > > Other cases I've seen are automotive with keeping > > > the backup camera going and CAN bus handling. Though my new car has a > > > flicker shortly after coming on, so I guess the handoff doesn't have > > > to be completely seemless. :) > > > > :) > > > > > [...] > > > > > > > + mmc: mmc@0x0 { > > > > + ... > > > > + ... > > > > + vmmc-supply = <&twl_reg1>; > > > > + vmmcaux-supply = <&twl_reg2>; > > > > + boot-constraint-supplies = "vmmc", "vmmcaux"; > > > > + boot-constraint-uV = <1800000 2000000>, /* vmmc */ > > > > + <2000000 2000000>; /* vmmcaux */ > > > > > > No. I don't like how this is going to extend to all the other bindings > > > people are going to want constraints for. We don't need a parallel set > > > of properties for each type of binding. > > > > Fair enough. > > > > > I'm not convinced that we need a general solution for what's probably > > > a handful of things that need a handoff versus just re-initialize. > > > > What about keeping the first four patches (mostly) as it is and adding > > these constraints from a platform specific constraints driver ? > > > > Will that be acceptable ? > > Meaning no DT binding? Then I don't care (from a DT perspective). Yeah, kind of the way we decided to do the first step in the power domain performance state series [1]. And then later on we can see how to get such information from DT, as the kernel needs this information irrespective of the way we solve this problem in the kernel. -- viresh [1] https://marc.info/?l=linux-kernel&m=149802907711074&w=2 From mboxrd@z Thu Jan 1 00:00:00 1970 From: viresh.kumar@linaro.org (Viresh Kumar) Date: Tue, 18 Jul 2017 11:28:04 +0530 Subject: [RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings In-Reply-To: <20170717173407.x5qjnrxqkjvn5vdm@rob-hp-laptop> References: <0610277aef9830cff53b7b53cf41cc54886fdc7f.1499770771.git.viresh.kumar@linaro.org> <20170713093608.GF352@vireshk-i7> <20170717173407.x5qjnrxqkjvn5vdm@rob-hp-laptop> Message-ID: <20170718055804.GV352@vireshk-i7> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 17-07-17, 12:34, Rob Herring wrote: > On Thu, Jul 13, 2017 at 03:06:08PM +0530, Viresh Kumar wrote: > > On 12-07-17, 16:28, Rob Herring wrote: > > > Display is a pretty well known use case here. Do you have other > > > examples in mind? > > > > No, I don't. > > > > @Stephen: Do you have more cases like this for your Qcom products ? > > > > > Other cases I've seen are automotive with keeping > > > the backup camera going and CAN bus handling. Though my new car has a > > > flicker shortly after coming on, so I guess the handoff doesn't have > > > to be completely seemless. :) > > > > :) > > > > > [...] > > > > > > > + mmc: mmc at 0x0 { > > > > + ... > > > > + ... > > > > + vmmc-supply = <&twl_reg1>; > > > > + vmmcaux-supply = <&twl_reg2>; > > > > + boot-constraint-supplies = "vmmc", "vmmcaux"; > > > > + boot-constraint-uV = <1800000 2000000>, /* vmmc */ > > > > + <2000000 2000000>; /* vmmcaux */ > > > > > > No. I don't like how this is going to extend to all the other bindings > > > people are going to want constraints for. We don't need a parallel set > > > of properties for each type of binding. > > > > Fair enough. > > > > > I'm not convinced that we need a general solution for what's probably > > > a handful of things that need a handoff versus just re-initialize. > > > > What about keeping the first four patches (mostly) as it is and adding > > these constraints from a platform specific constraints driver ? > > > > Will that be acceptable ? > > Meaning no DT binding? Then I don't care (from a DT perspective). Yeah, kind of the way we decided to do the first step in the power domain performance state series [1]. And then later on we can see how to get such information from DT, as the kernel needs this information irrespective of the way we solve this problem in the kernel. -- viresh [1] https://marc.info/?l=linux-kernel&m=149802907711074&w=2