From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752463AbdCMKj5 (ORCPT ); Mon, 13 Mar 2017 06:39:57 -0400 Received: from mail-pf0-f170.google.com ([209.85.192.170]:33127 "EHLO mail-pf0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752235AbdCMKjj (ORCPT ); Mon, 13 Mar 2017 06:39:39 -0400 Date: Mon, 13 Mar 2017 16:09:33 +0530 From: Viresh Kumar To: Kevin Hilman Cc: Rafael Wysocki , ulf.hansson@linaro.org, Nishanth Menon , linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, Stephen Boyd , linux-kernel@vger.kernel.org, robh+dt@kernel.org, rnayak@codeaurora.org, lina.iyer@linaro.org Subject: Re: [PATCH V3 0/7] PM / Domains: Implement domain performance states Message-ID: <20170313103933.GA3102@vireshk-i7> References: 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 On 10-03-17, 12:38, Kevin Hilman wrote: > Why limit it to just voltage levels. > > As I suggested earlier, I think this should use OPPs. Remember that a > PM domain is not limited to a hardware power domain, but is just a > grouping mechanism for devices that share some PM properties. As > mentioned by Geert, this can also be a clock domain, where frequencies > would make sense as well. One can imagine using this type of PM domain > to manage an interconnect/bus which has scalable voltage/frequencies as > well. Okay, I tried to do that change today and am blocked a bit right now. The OPP core and all of its APIs/interfaces have dependency on the "struct device" for their working. It gets the of_node from it, stores the device pointer to manage cases where multiple devices share OPP table, uses it to get clk and regulators. But the "genpd" structure doesn't have a 'struct device' associated with it. How should I make both of them work together? I tried to create separate helpers that don't accept 'dev', but that is also not good. Just too much redundant code everywhere. Would creating a 'dev' structure within 'generic_pm_domain' be acceptable? Or should we ask the domain-drivers to call something like of_genpd_parse_idle_states(), with a fake 'dev' structure which has its of_node initialized? Or maybe move that hack within the OPP-core API, which can create a dev structure at runtime for the genpd passed to it and get the OPP table out? -- viresh