Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp4339705imm; Fri, 18 May 2018 03:32:59 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqY1BYuEuFzk+yGgMf3oYYm7Uph3wLWbQPsg3IaNszE98blmWjugAWT0sVQwho/aPr04zDx X-Received: by 2002:a63:9d8e:: with SMTP id i136-v6mr3670330pgd.288.1526639579587; Fri, 18 May 2018 03:32:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526639579; cv=none; d=google.com; s=arc-20160816; b=S3R8YKbKdl0nzRT+OKE71JDp88xMQ3CrgHlGnX1udop/ZbxEGzXsMCGI27ftrwO0US +x0j/6LnzyyNBODv5cVGPSpWiqxUvI86Eg7XWm2faxOdjNCQ+5nMmax92Uk+I6g/S7Y0 bGWF50C9EirFlPiBnRrlgHhPH2XXFPf9D5vQnqRCvRWTjPrg4EebfQJdsEhHdtugNTyv tuksTdse2xDop1FPoWHmZaZEQZpj0FOpKxbSYSI1F87PHp3I7VRs7JtljAbC4vbiGW3y iA9zRQbTxptrFztE874VpaBD56qSoTB/YpHH5NQnN114W/MrSwZd4Sv9dTkVfDwDAxYX CSww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=ZcMqktTgVrlFyixB7rDxIq6FvIIB/LXvMKcWVjQol/I=; b=As81DcA+Bea+g7aZ5aQg0egxFoQCoWU8y8SU4oUVKkiIMpYbAMnj76OaG2O+rmlKCh n78pWVjC7tYVlVbxS1EunqhIJxPUaagOTYIqv14T9rDdPwdAmp50r5B7hl7CdmnoapZD SVQYPOffLQ1grSohbSSmvWjKIORLjU1yHbjbRWnx0AAU49tvJboqExu5L1QnjQ/7kLJY dnFe/3aRxloE3HRE1vqbJiC5qeosxKKLWIWDrYPMif7V04ZInRz/VStpdOtfmJS4vbXb zdcvZFGC/8YG6UJrZ1ubiQ+96kfVYyz01vMXcuvPrVYoc/WvIuo+AUHeAbLrXN7rsTKG /EVQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=kxVJatCT; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b6-v6si6954913plz.238.2018.05.18.03.32.45; Fri, 18 May 2018 03:32:59 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=kxVJatCT; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752714AbeERKcV (ORCPT + 99 others); Fri, 18 May 2018 06:32:21 -0400 Received: from mail-lf0-f65.google.com ([209.85.215.65]:34866 "EHLO mail-lf0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752650AbeERKcB (ORCPT ); Fri, 18 May 2018 06:32:01 -0400 Received: by mail-lf0-f65.google.com with SMTP id y72-v6so13230022lfd.2 for ; Fri, 18 May 2018 03:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=ZcMqktTgVrlFyixB7rDxIq6FvIIB/LXvMKcWVjQol/I=; b=kxVJatCTSOTh6Lqrzf13A9ATud2vAtbdxmpWBmHDU+gZilYcWS6t3W00VFtGFU8MhJ 5if4Hj6N8ZvupxeajqUt0/yT+yo09zUveZc8pxSdi/Yf9oYpcf6QOrCLb1sCedEkGzZF RZMebIvCf3WyaYEqg6vw0G7NPwYV8bqgy1qK4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=ZcMqktTgVrlFyixB7rDxIq6FvIIB/LXvMKcWVjQol/I=; b=BCDTzH3cG8MkQRPT8Du537tzf00WGhtoTNKIsjTMcwQF1JrXlYzd2cpdVMEe8i0lHO zwZfu6HlWN0ZSAbtrZzKrnVuC+jAB63m2pd0EszLMRs/QqtdKjtJkNOh2ucsPUCDVvtP T/MZjI/iyjaUZWi0ssVJgWJQaNOaPfYi4eO366qRxq+HqSppYj9qvoU5QCm+KPqGxmU9 PyZ17Lsv3OfHo7+jI6ECq1nMoolUK6n9EzhNzN1+mRIhfIOwUYh2YH1wJDdi3erIWY5E NKi//Cv2YF2vrQxPFrSgepWdnawzoHDhYUxVr0ElpA5AOhQL1Z4VM03SNHz19nEKcH7j QAAw== X-Gm-Message-State: ALKqPwf6kcIR3x3xB4KQVU+HUOdKW6U51eTnOwosK9L+r5Ss7l528iBw BxaV9VE6Ya4aNi3eVb/evNGrQw== X-Received: by 2002:a2e:2402:: with SMTP id k2-v6mr5751500ljk.20.1526639519449; Fri, 18 May 2018 03:31:59 -0700 (PDT) Received: from localhost.localdomain (h-158-174-22-210.NA.cust.bahnhof.se. [158.174.22.210]) by smtp.gmail.com with ESMTPSA id u14-v6sm393447lfk.55.2018.05.18.03.31.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 18 May 2018 03:31:58 -0700 (PDT) From: Ulf Hansson To: "Rafael J . Wysocki" , linux-pm@vger.kernel.org Cc: Ulf Hansson , Greg Kroah-Hartman , Jon Hunter , Geert Uytterhoeven , Todor Tomov , Rajendra Nayak , Viresh Kumar , Vincent Guittot , Kevin Hilman , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-tegra@vger.kernel.org Subject: [PATCH 9/9] PM / Domains: Add dev_pm_domain_attach_by_id() to manage multi PM domains Date: Fri, 18 May 2018 12:31:30 +0200 Message-Id: <1526639490-12167-10-git-send-email-ulf.hansson@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1526639490-12167-1-git-send-email-ulf.hansson@linaro.org> References: <1526639490-12167-1-git-send-email-ulf.hansson@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The existing dev_pm_domain_attach() function, allows a single PM domain to be attached per device. To be able to support devices that are partitioned across multiple PM domains, let's introduce a new interface, dev_pm_domain_attach_by_id(). The dev_pm_domain_attach_by_id() returns a new allocated struct device with the corresponding attached PM domain. This enables for example a driver to operate on the new device from a power management point of view. The driver may then also benefit from using the received device, to set up so called device-links towards its original device. Depending on the situation, these links may then be dynamically changed. The new interface is typically called by drivers during their probe phase, in case they manages devices which uses multiple PM domains. If that is the case, the driver also becomes responsible of managing the detaching of the PM domains, which typically should be done at the remove phase. Detaching is done by calling the existing dev_pm_domain_detach() function and for each of the received devices from dev_pm_domain_attach_by_id(). Note, currently its only genpd that supports multiple PM domains per device, but dev_pm_domain_attach_by_id() can easily by extended to cover other PM domain types, if/when needed. Signed-off-by: Ulf Hansson --- drivers/base/power/common.c | 33 ++++++++++++++++++++++++++++++++- include/linux/pm_domain.h | 7 +++++++ 2 files changed, 39 insertions(+), 1 deletion(-) diff --git a/drivers/base/power/common.c b/drivers/base/power/common.c index 7ae62b6..d3db974 100644 --- a/drivers/base/power/common.c +++ b/drivers/base/power/common.c @@ -117,13 +117,44 @@ int dev_pm_domain_attach(struct device *dev, bool power_on) EXPORT_SYMBOL_GPL(dev_pm_domain_attach); /** + * dev_pm_domain_attach_by_id - Attach a device to one of its PM domains. + * @index: The index of the PM domain. + * @dev: Device to attach. + * + * As @dev may only be attached to a single PM domain, the backend PM domain + * provider should create a virtual device to attach instead. As attachment + * succeeds, the ->detach() callback in the struct dev_pm_domain should be + * assigned by the corresponding backend attach function. + * + * This function should typically be invoked from drivers during probe phase. + * Especially for those that manages devices which requires power management + * through more than one PM domain. + * + * Callers must ensure proper synchronization of this function with power + * management callbacks. + * + * Returns the virtual attached device in case successfully attached PM domain, + * NULL in case @dev don't need a PM domain, else a PTR_ERR(). + */ +struct device *dev_pm_domain_attach_by_id(struct device *dev, + unsigned int index) +{ + if (dev->pm_domain) + return NULL; + + return genpd_dev_pm_attach_by_id(dev, index); +} +EXPORT_SYMBOL_GPL(dev_pm_domain_attach_by_id); + +/** * dev_pm_domain_detach - Detach a device from its PM domain. * @dev: Device to detach. * @power_off: Used to indicate whether we should power off the device. * * This functions will reverse the actions from dev_pm_domain_attach() and thus * try to detach the @dev from its PM domain. Typically it should be invoked - * from subsystem level code during the remove phase. + * during the remove phase, either from subsystem level code or from drivers in + * case attaching was done through dev_pm_domain_attach_by_id. * * Callers must ensure proper synchronization of this function with power * management callbacks. diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h index 82458e8..493ce67 100644 --- a/include/linux/pm_domain.h +++ b/include/linux/pm_domain.h @@ -299,6 +299,8 @@ struct generic_pm_domain *of_genpd_remove_last(struct device_node *np) #ifdef CONFIG_PM int dev_pm_domain_attach(struct device *dev, bool power_on); +struct device *dev_pm_domain_attach_by_id(struct device *dev, + unsigned int index); void dev_pm_domain_detach(struct device *dev, bool power_off); void dev_pm_domain_set(struct device *dev, struct dev_pm_domain *pd); #else @@ -306,6 +308,11 @@ static inline int dev_pm_domain_attach(struct device *dev, bool power_on) { return 0; } +static inline struct device *dev_pm_domain_attach_by_id(struct device *dev, + unsigned int index); +{ + return NULL; +} static inline void dev_pm_domain_detach(struct device *dev, bool power_off) {} static inline void dev_pm_domain_set(struct device *dev, struct dev_pm_domain *pd) {} -- 2.7.4