Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751731AbcJGJPI (ORCPT ); Fri, 7 Oct 2016 05:15:08 -0400 Received: from mail-pa0-f53.google.com ([209.85.220.53]:34175 "EHLO mail-pa0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751521AbcJGJO6 (ORCPT ); Fri, 7 Oct 2016 05:14:58 -0400 From: Kevin Hilman To: Jon Hunter Cc: "Rafael J. Wysocki" , Ulf Hansson , , , Subject: Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains Organization: BayLibre References: <1474367287-10402-1-git-send-email-jonathanh@nvidia.com> <1474367287-10402-3-git-send-email-jonathanh@nvidia.com> Date: Fri, 07 Oct 2016 02:14:56 -0700 In-Reply-To: <1474367287-10402-3-git-send-email-jonathanh@nvidia.com> (Jon Hunter's message of "Tue, 20 Sep 2016 11:28:06 +0100") Message-ID: <7hlgy0frlb.fsf@baylibre.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1541 Lines: 34 Jon Hunter writes: > Some devices may require more than one PM domain to operate and this is > not currently by the PM domain framework. Furthermore, the current Linux > 'device' structure only allows devices to be associated with a single PM > domain and so cannot easily be associated with more than one. To allow > devices to be associated with more than one PM domain, if multiple > domains are defined for a given device (eg. via device-tree), then: > 1. Create a new PM domain for this device. The name of the new PM domain > created matches the device name for which it was created for. > 2. Register the new PM domain as a sub-domain for all PM domains > required by the device. > 3. Attach the device to the new PM domain. Did you look at what might be involved to extend struct device to hace a list of pm_domains? Like Ulf, I'm a bit unsettled by this implementation that has to work around the basic limitation in the driver model. Having devices in multitple domains is needed for SoCs I'm familiar with also, so is a needed feature. I think removing the struct device limitation and corresponding assumptions in the driver and PM core is a prerequisite for this feature. Doing that will lead to several questions about how to handle runtime PM operations (e.g. which of the multiple PM domains should the one to call the drivers runtime PM hooks when a device changes runtime PM state?) Anyways, even with the potential complexities, I think attempting this is the right way forward. Kevin