Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753771AbcJZDVc (ORCPT ); Tue, 25 Oct 2016 23:21:32 -0400 Received: from mail-pf0-f170.google.com ([209.85.192.170]:36584 "EHLO mail-pf0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751779AbcJZDV3 (ORCPT ); Tue, 25 Oct 2016 23:21:29 -0400 Date: Wed, 26 Oct 2016 08:51:24 +0530 From: Viresh Kumar To: Dave Gerlach Cc: "Rafael J. Wysocki" , Rafael Wysocki , Nishanth Menon , Stephen Boyd , Lists linaro-kernel , Linux PM , Linux Kernel Mailing List , Vincent Guittot , Rob Herring , Mark Brown Subject: Re: [PATCH V2 0/8] PM / OPP: Multiple regulator support Message-ID: <20161026032124.GG9162@vireshk-i7> References: <41a8b4a1-94d3-e086-a328-495f69815d1c@ti.com> <20161024042659.GD24749@vireshk-i7> <4059f5a9-5308-8a5e-827b-4f822d9049d2@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4059f5a9-5308-8a5e-827b-4f822d9049d2@ti.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 Content-Length: 1887 Lines: 43 On 25-10-16, 16:13, Dave Gerlach wrote: > I think what you have shared below is a good safety check but if I rename > the regulator properties in the DT for the cpu (to vdd and vbb, meaning > cpufreq detects no regulator) and do *not* call dev_pm_opp_set_regulators > before cpufreq-dt probes we fail before we even get to that point: > > [16.946] cpu cpu0: opp_parse_supplies: Invalid number of elements in > opp-microvolt property (6) with supplies (1) > [16.967] cpu cpu0: _of_add_opp_table_v2: Failed to add OPP, -22 > [16.982] cpu cpu0: dev_pm_opp_get_opp_count: OPP table not found (-19) > [16.982] cpu cpu0: OPP table is not ready, deferring probe > > This failure is because opp_parse_supplies assumes a count of 1 regulator if > no regulators at all are present and then hard fails if too many voltages > have been passed for each OPP. Exactly. And yes this is intentional. > It seems we need a check much earlier similar > to what you suggested below to allow us to defer if an OPP has supplied > voltages but no regulator has been registered with the system. I think this > is reasonable even for the 1 regulator case, no? No. OPP core needs to know about regulators only if the user drivers want it to manage DVFS. It is still possible for cpufreq drivers to use OPP framework for managing the tables, but do the real DVFS stuff themselves. That's why it is not compulsory in the code to set regulator names. And its only wrong if dev_pm_opp_set_rate() is called without first setting the regulators.. > cpufreq-dt won't handle this properly as is, but now that the opp core is > evolving perhaps it makes sense to modify the resources_available check > slightly to rely on the OPP core rather than just a dummy > regulator_get_optional to see if the regulator is ready. I am not sure yet on what to change there. You mean regarding multiple regulators? -- viresh