Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751947AbdF3FMI (ORCPT ); Fri, 30 Jun 2017 01:12:08 -0400 Received: from mail-pf0-f173.google.com ([209.85.192.173]:33488 "EHLO mail-pf0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751599AbdF3FMH (ORCPT ); Fri, 30 Jun 2017 01:12:07 -0400 Date: Fri, 30 Jun 2017 10:42:03 +0530 From: Viresh Kumar To: Chen-Yu Tsai Cc: "Enrico Weigelt, metux IT consult" , Rafael Wysocki , Vincent Guittot , Rob Herring , Greg Kroah-Hartman , Stephen Boyd , linux-kernel , Mark Brown , rnayak@codeaurora.org, Shiraz Hashim , linux-arm-kernel Subject: Re: [RFC 0/5] drivers: Add boot constraints core Message-ID: <20170630051203.GY29665@vireshk-i7> References: <20170629144711.GO29665@vireshk-i7> <1522ae7b-fd5b-5403-62bf-b0140e116d65@gr13.net> <20170630031648.GR29665@vireshk-i7> <20170630035533.GV29665@vireshk-i7> <20170630041211.GX29665@vireshk-i7> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Content-Length: 2239 Lines: 49 On 30-06-17, 12:22, Chen-Yu Tsai wrote: > On Fri, Jun 30, 2017 at 12:12 PM, Viresh Kumar wrote: > > On 30-06-17, 12:05, Chen-Yu Tsai wrote: > >> I also want to mention that for DT based platforms, this constraint > >> should already be set in the device tree for the regulator, so the > >> scenario where DMA comes up and sets a voltage level that LCD cannot > >> use should not even be possible. > > What I'm saying is for the DT case, the constraints are already limited > to the intersection of all users, regardless of whether they are turned > on or not. Right, but someone needs to get the regulator first to have that considered by the regulator core while deciding the final range. Both DMA and LCD driver do regulator_get() for their devices but if only DMA driver is probed until now, then the regulator core wouldn't consider LCD as regulator_get() is never called for LCD. > I think what you mean is that the DT constraints are the union of all > consumer constraints (1.8 - 3.0 V in this case), then each consumer > comes in and adds its own constraints. And for such a design, the kernel > needs to know which and what constraints to apply. Sorry, I am confused with what you just said and not sure if I understand it completely. Each consumer DT node will have its own set of constraints for the regulator device. The kernel will do regulator_get() for them one by one, based on when their drivers get probed. And an intersection of those constraints (which already did regulator_get()) will be used by the regulator core. Now this series is saying that even if the driver didn't come up (for LCD) and haven't done its regulator_get() yet, consider that device's constraint while calculating the target voltage for the regulator. > Either way regulators already support constraints, so they are easier > to deal with. Clocks on the other hand, while the core does support > clock rate constraints, AFAIK no one really uses or supports them. Yeah, so I started with just regulators and that's when Mark suggested to do something generic which can be reused by other resource types. We may end up covering clk for sure I believe. Not sure yet about other resource types though. -- viresh