From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751831AbdFHHsU (ORCPT ); Thu, 8 Jun 2017 03:48:20 -0400 Received: from mail-qt0-f175.google.com ([209.85.216.175]:33613 "EHLO mail-qt0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751518AbdFHHsS (ORCPT ); Thu, 8 Jun 2017 03:48:18 -0400 MIME-Version: 1.0 In-Reply-To: <20170608070505.GB4634@vireshk-i7> References: <4cc55fce0fd4199941f1d7b785e677255ff792d5.1495003720.git.viresh.kumar@linaro.org> <20170608070505.GB4634@vireshk-i7> From: Ulf Hansson Date: Thu, 8 Jun 2017 09:48:17 +0200 Message-ID: Subject: Re: [PATCH V7 1/2] PM / Domains: Add support to select performance-state of domains To: Viresh Kumar Cc: Rafael Wysocki , Kevin Hilman , Pavel Machek , Len Brown , linaro-kernel , "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Vincent Guittot , Stephen Boyd , Nishanth Menon , Rob Herring , Lina Iyer , Rajendra Nayak , Sudeep Holla Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [...] >> As you probably figured out from my above comments, the solution here >> isn't really working. >> >> Adding these new APIs, more or less requires us to manage reference >> counting on the genpd for the device. > > Hmm, I am not able to understand why would we need that with this series :( > >> I haven't thought about that in >> great detail, just that we of course need to be careful if we want to >> introduce something like that, to make sure all aspect of locking >> becomes correct. >> >> Moreover adding reference counting touches the idea of adding APIs to >> genpd, to allow users/drivers to control their genpd explicitly. This >> is required to support > 1 pm_domain per device. I assume you have >> been following that discussion for genpd on linux-pm as well. My point >> is that, we should consider that while inventing *any* new APIs. > > Not very deeply but yeah I have seen that thread. > > So, I couldn't find way to get the locking thing fixed to avoid deadlocks but we > can live with a constraint (if you guys think it is fine) to have this solved. > > Constraint: Update performance state API wouldn't support power domains that > don't provide a set_performance_state() callback and have multiple parent power > domains. No thanks. If we are going to do this, let's do it properly. To me some minor constraints would be okay, but this is just too much. > > Why: In order to guarantee that we read and update the performance_state of > subdomains and devices properly, we need to do that under the parent domain's > lock. And if we have multiple parent power domains, then we would be required to > get them locked at once before updating subdomain's state and that would be a > nightmare. It's not a nightmare, just a tricky thing to solve. :-) [...] Kind regards Uffe