Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752546AbcKPMxh (ORCPT ); Wed, 16 Nov 2016 07:53:37 -0500 Received: from mail-qk0-f195.google.com ([209.85.220.195]:33470 "EHLO mail-qk0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751589AbcKPMxe (ORCPT ); Wed, 16 Nov 2016 07:53:34 -0500 MIME-Version: 1.0 In-Reply-To: References: <1474367287-10402-1-git-send-email-jonathanh@nvidia.com> <90faea7d-65b6-590a-83f1-24fcdffa0569@nvidia.com> <63670abf-1d58-a7e3-6927-0c815d44d8a1@nvidia.com> From: "Rafael J. Wysocki" Date: Wed, 16 Nov 2016 13:53:32 +0100 X-Google-Sender-Auth: 2xU9XQNXKaQ4dIHRyPhmr7YN1Bo Message-ID: Subject: Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains To: Jon Hunter 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 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3409 Lines: 77 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. Thanks, Rafael