Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933094AbcKVLMz (ORCPT ); Tue, 22 Nov 2016 06:12:55 -0500 Received: from hqemgate14.nvidia.com ([216.228.121.143]:10392 "EHLO hqemgate14.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932164AbcKVLMx (ORCPT ); Tue, 22 Nov 2016 06:12:53 -0500 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Tue, 22 Nov 2016 03:12:51 -0800 Subject: Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains To: "Rafael J. Wysocki" References: <1474367287-10402-1-git-send-email-jonathanh@nvidia.com> <90faea7d-65b6-590a-83f1-24fcdffa0569@nvidia.com> <63670abf-1d58-a7e3-6927-0c815d44d8a1@nvidia.com> CC: Ulf Hansson , Kevin Hilman , "Rafael J. Wysocki" , "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-tegra@vger.kernel.org" , Rajendra Nayak From: Jon Hunter Message-ID: Date: Tue, 22 Nov 2016 11:12:43 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [10.21.132.123] 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: 4846 Lines: 107 On 16/11/16 12:53, Rafael J. Wysocki wrote: > On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter wrote: >> Hi Kevin, Ulf, >> >> On 03/11/16 14:20, Jon Hunter wrote: >>> >>> On 11/10/16 10:15, Jon Hunter wrote: >>> >>> ... >>> >>>>>>> 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>; >>>>>> }; >>>>> >>>>> So, is this really is a proper description of the HW? Isn't it so, >>>>> that the usb device always resides in one and the same PM domain? >>>> >>>> I guess technically, the usbhost controller resides in one partition and >>>> the super-speed logic in another. So could the usbhost domain be the >>>> primary? Possibly, but the device cannot be probed without both enabled. >>>> >>>>> Now, depending on the selected speed mode (superspeed) additional >>>>> logic may needs to be powered on and configured for the usb device to >>>>> work? >>>>> Perhaps, one could consider those additional logics as a master/parent >>>>> PM domain for the usb device's PM domain? >>>>> >>>>> Or this is not how the HW works? :-) >>>> >>>> It might be possible for this case, but to be honest, the more I think >>>> about this, I do wonder if we need to be able to make the framework a >>>> lot more flexible for devices that need multiple power-domains. In other >>>> words, for devices that use multiple domains allow them to control them >>>> similarly to what we do for regulators or clocks. So if there is more >>>> than one defined, then the genpd core will not bind the device to the >>>> pm-domain and let the driver handle it. This way if you do need more >>>> granular control of the pm-domains in the driver you can do whatever you >>>> need to. >>>> >>>> I know that Rajendra (CC'ed) was looking into whether he had a need to >>>> control multiple power-domains individually from within the context of a >>>> single device driver. >>> >>> So Rajendra commented to say that he does not see a need for individual >>> control of power-domains for now, but a need for specifying multiple. >>> >>> One simple option would be to allow users to specify multiple and have >>> the genpd core effectively ignore such devices and leave it to the >>> driver to configure manually. I have been able to do this for XUSB by >>> dynamically adding power-domains to the device. >>> >>> Let me know if you have any more thoughts on how we can do this. >> >> Any more thoughts on this? Seems that there are a few others that would >> be interested in supporting multiple domains for a device. > > There is a design limitation to that, however. > > The PM domain concept really is about intercepting the flow of PM > callbacks for a device in order to carry out additional operations, > not covered by the bus type or driver. That's why there is only one > set of PM domain callbacks per device and I don't quite see how and > why it would be useful to add more of them in there. Sorry for the delay. We do, however, support the nesting of power-domains to allow more than one power-domain to be controlled for a device. For the current implementations that use nested power-domains, I am not sure if the power-domains are truly nested or just describing a relationship between power-domains. Nesting power-domains could also work for the Tegra XHCI device. However, I don't wish to statically nest the power-domains in device-tree where they are defined so they are always nested, because this may not be always necessary. However, I would rather the client of the power-domains specify which power-domains they require and dynamically nested the power-domains at runtime. This is slightly different to what I proposed in this RFC, but it is not really beyond the bounds of what we support today IMO. What is missing is a means to do this dynamically and not statically. By the way, I am not sure if you are suggesting that for devices that may need multiple power-domains we should architect the driver differently and split it up in some way such that we have a power-domain per device. But for the case of the Tegra XHCI it is quite complex because the driver loads firmware which runs on a micro-controller and we need to manage the various power-domains that are used. Cheers Jon -- nvpublic