From: d-gerlach@ti•com (Dave Gerlach)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v2 2/4] dt-bindings: Add TI SCI PM Domains
Date: Thu, 27 Oct 2016 08:15:53 -0500 [thread overview]
Message-ID: <5811FE09.8000006@ti.com> (raw)
In-Reply-To: <CAL_JsqJvm8+L0-pFQRQGYhvSzvqubWsBp8Q5kU-BPSiDmMau0A@mail.gmail.com>
+Jon
On 10/26/2016 04:59 PM, Rob Herring wrote:
> On Mon, Oct 24, 2016 at 12:00 PM, Kevin Hilman <khilman@baylibre•com> wrote:
>> Dave Gerlach <d-gerlach@ti•com> writes:
>>
>>> Hi,
>>> On 10/21/2016 01:48 PM, Kevin Hilman wrote:
>>>> Dave Gerlach <d-gerlach@ti•com> writes:
>>>>
>>>>> Add a generic power domain implementation, TI SCI PM Domains, that
>>>>> will hook into the genpd framework and allow the TI SCI protocol to
>>>>> control device power states.
>>>>>
>>>>> Also, provide macros representing each device index as understood
>>>>> by TI SCI to be used in the device node power-domain references.
>>>>> These are identifiers for the K2G devices managed by the PMMC.
>>>>>
>>>>> Signed-off-by: Nishanth Menon <nm@ti•com>
>>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti•com>
>>>>> ---
>>>>> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 54 +++++++++++++
>>>>> MAINTAINERS | 2 +
>>>>> include/dt-bindings/genpd/k2g.h | 90 ++++++++++++++++++++++
>>>>> 3 files changed, 146 insertions(+)
>>>>> create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>> create mode 100644 include/dt-bindings/genpd/k2g.h
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>> new file mode 100644
>>>>> index 000000000000..32f38a349656
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>> @@ -0,0 +1,54 @@
>>>>> +Texas Instruments TI-SCI Generic Power Domain
>>>>> +---------------------------------------------
>>>>> +
>>>>> +Some TI SoCs contain a system controller (like the PMMC, etc...) that is
>>>>> +responsible for controlling the state of the IPs that are present.
>>>>> +Communication between the host processor running an OS and the system
>>>>> +controller happens through a protocol known as TI-SCI [1]. This pm domain
>>>>> +implementation plugs into the generic pm domain framework and makes use of
>>>>> +the TI SCI protocol power on and off each device when needed.
>>>>> +
>>>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>>>> +
>>>>> +PM Domain Node
>>>>> +==============
>>>>> +The PM domain node represents the global PM domain managed by the PMMC,
>>>>> +which in this case is the single implementation as documented by the generic
>>>>> +PM domain bindings in Documentation/devicetree/bindings/power/power_domain.txt.
>>>>> +
>>>>> +Required Properties:
>>>>> +--------------------
>>>>> +- compatible: should be "ti,sci-pm-domain"
>>>>> +- #power-domain-cells: Must be 0.
>>>>> +- ti,sci: Phandle to the TI SCI device to use for managing the devices.
>>>>>
>>>>> +Example:
>>>>> +--------------------
>>>>> +k2g_pds: k2g_pds {
>>>>
>>>> should use generic name like "power-contoller", e.g. k2g_pds: power-controller
>>>
>>> Ok, that makes more sense.
>>>
>>>>
>>>>> + compatible = "ti,sci-pm-domain";
>>>>> + #power-domain-cells = <0>;
>>>>> + ti,sci = <&pmmc>;
>>>>> +};
>>>>> +
>>>>> +PM Domain Consumers
>>>>> +===================
>>>>> +Hardware blocks that require SCI control over their state must provide
>>>>> +a reference to the sci-pm-domain they are part of and a unique device
>>>>> +specific ID that identifies the device.
>>>>> +
>>>>> +Required Properties:
>>>>> +--------------------
>>>>> +- power-domains: phandle pointing to the corresponding PM domain node.
>>>>> +- ti,sci-id: index representing the device id to be passed oevr SCI to
>>>>> + be used for device control.
>>>>
>>>> This ID doesn't look right.
>>>>
>>>> Why not use #power-domain-cells = <1> and pass the index in the DT? ...
>
> Exactly. ti,sci-id is a NAK for me.
I was told not to use the onecell during v1 discussion. I agree this would be
ideal but I cannot due to what the bindings represent, the phandle parameter is
an index into a list of genpds, whereas we need an actual ID number we can use
and I do not have the ability to get that from the phandle.
@Ulf/Jon, is there any hope of bringing back custom xlate functions for genpd
providers? I don't have a good background on why it was even removed. I can
maintain a single genpd for all devices but I need a way to parse this ID,
whether it's from a separate property or a phandle. It is locked now to indexing
into a list of genpds but I need additional per device information for devices
bound to a genpd and I need either a custom parameter or the ability to parse
the phandle myself.
>
>>>>
>>>>> +See dt-bindings/genpd/k2g.h for the list of valid identifiers for k2g.
>>>>> +
>>>>> +Example:
>>>>> +--------------------
>>>>> +uart0: serial at 02530c00 {
>>>>> + compatible = "ns16550a";
>>>>> + ...
>>>>> + power-domains = <&k2g_pds>;
>>>>> + ti,sci-id = <K2G_DEV_UART0>;
>>>>
>>>> ... like this:
>>>>
>>>> power-domains = <&k2g_pds K2G_DEV_UART0>;
>>>
>>> That's how I did it in version one actually. I was able to define my
>>> own xlate function to parse the phandle and get that index, but Ulf
>>> pointed me to this series by Jon Hunter [1] that simplified genpd
>>> providers and dropped the concept of adding your own xlate. This locks
>>> the onecell approach to using a fixed static array of genpds that get
>>> indexed into (without passing the index to the provider, just the
>>> genpd that's looked up), which doesn't fit our usecase, as we don't
>>> want a 1 to 1 genpd to device mapping based on the comments provided
>>> in v1. Now we just use the genpd device attach/detach hooks to parse
>>> the sci-id and then use it in the genpd device start/stop hooks.
>
> I have no idea what any of this means. All sounds like driver
> architecture, not anything to do with bindings.
This was a response to Kevin, not part of binding description.
>
>>
>> Ah, right. I remember now. This approach allows you to use a single
>> genpd as discussed earlier.
>>
>> Makes sense now, suggestion retracted.
>
> IIRC, the bindings in Jon's case had a node for each domain and didn't
> need any additional property.
Yes but we only have one domain and index into it, not into a list of domains,
so the additional property is solving a different problem.
Regards,
Dave
>
> Rob
>
next prev parent reply other threads:[~2016-10-27 13:15 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-19 20:33 [PATCH v2 0/4] ARM: K2G: Add support for TI-SCI Generic PM Domains Dave Gerlach
2016-10-19 20:33 ` [PATCH v2 1/4] PM / Domains: Add generic data pointer to genpd data struct Dave Gerlach
2016-10-25 9:48 ` Ulf Hansson
2016-10-19 20:33 ` [PATCH v2 2/4] dt-bindings: Add TI SCI PM Domains Dave Gerlach
2016-10-21 18:48 ` Kevin Hilman
2016-10-21 19:49 ` Dave Gerlach
2016-10-24 17:00 ` Kevin Hilman
2016-10-26 21:59 ` Rob Herring
2016-10-27 13:15 ` Dave Gerlach [this message]
2016-11-10 19:56 ` Dave Gerlach
2016-11-11 12:34 ` Ulf Hansson
2016-11-14 19:20 ` Dave Gerlach
2016-10-26 22:04 ` Rob Herring
2016-10-27 9:02 ` Tero Kristo
2016-10-27 14:07 ` Dave Gerlach
2016-10-19 20:33 ` [PATCH v2 3/4] soc: ti: Add ti_sci_pm_domains driver Dave Gerlach
2016-10-21 19:00 ` Kevin Hilman
2016-10-21 19:02 ` Santosh Shilimkar
2016-10-21 19:15 ` Dave Gerlach
2016-10-25 9:48 ` Ulf Hansson
2016-10-19 20:33 ` [PATCH v2 4/4] ARM: keystone: Drop PM domain support for k2g Dave Gerlach
2016-10-21 13:28 ` [PATCH v2 0/4] ARM: K2G: Add support for TI-SCI Generic PM Domains Rafael J. Wysocki
2016-10-25 17:02 ` Kevin Hilman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5811FE09.8000006@ti.com \
--to=d-gerlach@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox