lkml.org 
[lkml]   [2016]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains
    From
    Date

    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.

    Cheers
    Jon

    --
    nvpublic

    \
     
     \ /
      Last update: 2016-11-03 15:21    [W:5.011 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site