Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752103AbcJJLSU (ORCPT ); Mon, 10 Oct 2016 07:18:20 -0400 Received: from hqemgate14.nvidia.com ([216.228.121.143]:6851 "EHLO hqemgate14.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752017AbcJJLSR (ORCPT ); Mon, 10 Oct 2016 07:18:17 -0400 X-PGP-Universal: processed; by hqnvupgp08.nvidia.com on Mon, 10 Oct 2016 04:11:36 -0700 Subject: Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains To: Ulf Hansson References: <1474367287-10402-1-git-send-email-jonathanh@nvidia.com> CC: "Rafael J. Wysocki" , Kevin Hilman , "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-tegra@vger.kernel.org" From: Jon Hunter Message-ID: <90faea7d-65b6-590a-83f1-24fcdffa0569@nvidia.com> Date: Mon, 10 Oct 2016 12:18:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [10.21.132.110] X-ClientProxiedBy: UKMAIL101.nvidia.com (10.26.138.13) To UKMAIL101.nvidia.com (10.26.138.13) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2685 Lines: 67 On 06/10/16 13:22, Ulf Hansson wrote: > On 20 September 2016 at 12:28, Jon Hunter wrote: >> The Tegra124/210 XUSB subsystem (that consists of both host and device >> controllers) is partitioned across 3 PM domains which are: >> - XUSBA: Superspeed logic (for USB 3.0) >> - XUSBB: Device controller >> - XUSBC: Host controller >> >> These power domains are not nested and can be powered-up and down >> independently of one another. In practice different scenarios require >> different combinations of the power domains, for example: >> - Superspeed host: XUSBA and XUSBC >> - Superspeed device: XUSBA and XUSBB >> >> Although it could be possible to logically nest both the XUSBB and XUSBC >> domains under the XUSBA, superspeed may not always be used/required and >> so this would keep it on unnecessarily. >> >> Given that Tegra uses device-tree for describing the hardware, it would >> be ideal that the device-tree 'power-domains' property for generic PM >> domains could be extended to allow more than one PM domain to be >> specified. For example, define the following the Tegra210 xHCI device ... >> >> usb@70090000 { >> compatible = "nvidia,tegra210-xusb"; >> ... >> power-domains = <&pd_xusbhost>, <&pd_xusbss>; >> }; >> >> This RFC extends the generic PM domain framework to allow a device to >> define more than one PM domain in the device-tree 'power-domains' >> property. > > First, I don't really like extending the internal logic of genpd to > deal with multiple PM domains per device. *If* this really is needed, > I think we should try to extend the struct device to cover this, then > make genpd to use it somehow. I had looked at that initially but it was looking quite complex because of the various structures (dev_pm_domain in the device structure, pm_domain_data in pm_subsys_data, etc). This implementation is quite simple and less intrusive. However, if there is a lot of interest in this and it does appear to be, I would agree that having the device structure handle this would be best. > Second, another way of seeing this is: Depending on the current > runtime selected configuration you need to re-configure the PM domain > topology - but the device would still remain in the same PM domain. > > In other words, you would need to remove/add subdomain(s) depending on > the selected configuration. Would that better reflect the HW? I am not 100% sure I follow what you are saying, but ultimately, I would like to get to ... usb@70090000 { compatible = "nvidia,tegra210-xusb"; ... power-domains = <&pd_xusbhost>, <&pd_xusbss>; }; Cheers Jon -- nvpublic