Re: [PATCH v3 02/10] dt-bindings: introduce RPMH RSC bindings for Qualcomm SoCs

2018-03-07 Thread Lina Iyer 

On Tue, Mar 06 2018 at 15:30 -0700, Stephen Boyd wrote:

Quoting Lina Iyer (2018-03-02 08:43:09)

Add device binding documentation for Qualcomm Technology Inc's RPMH RSC
driver. The hardware block is used for communicating resource state


s/driver/hardware/


Ok.


requests for shared resources.

Cc: devicet...@vger.kernel.org
Signed-off-by: Lina Iyer 
---

Changes in v2:
- Amend text to describe the registers in reg property
- Add reg-names for the registers
- Update examples to use GIC_SPI in interrupts instead of 0
- Rephrase incorrect description

Changes in v3:
- Fix unwanted capitalization
- Remove clients from the examples, this doc does not describe
  them
- Rephrase introductory paragraph
- Remove hardware specifics from DT bindings
---
 .../devicetree/bindings/arm/msm/rpmh-rsc.txt   | 131 +
 1 file changed, 131 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt

diff --git a/Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt 
b/Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt
new file mode 100644
index ..afd3817cc615
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt


Shouldn't this go into bindings/soc/qcom/ ?


Didn;t realize the location. Thanks for pointing out.


+

+Requests can be made for the state of a resource, when the subsystem is active
+or idle. When all subsystems like Modem, GPU, CPU are idle, the resource state
+will be an aggregate of the sleep votes from each of those subsystem. Drivers


s/subsystem/subsystems/
s/Drivers/Clients/ ?


Ok


+may request a sleep value for their shared resources in addition to the active
+mode requests.
+
+Control requests are instance specific requests that may or may not reach an
+accelerator. Only one platform device in Linux can request a control channel
+on a DRV.


Not sure what this last sentence has to do with the DT binding. We
generally try to avoid saying 'Linux' or 'driver' in DT binding
documents, because they usually document hardware.


This para can go away.


+
+Properties:
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: Should be "qcom,rpmh-rsc".
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: The first register specifies the base address of the DRV.
+   The second register specifies the start address of the
+   TCS.
+
+- reg-names:
+   Usage: required


optional?


No, it is required. Driver has been using the by_name for clarity.


+   Value type: 
+   Definition: Maps the register specified in the reg property. Must be
+   "drv" and "tcs".
+
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: The interrupt that trips when a message complete/response
+  is received for this DRV from the accelerators.
+
+- qcom,drv-id:
+   Usage: required
+   Value type: 
+   Definition: the id of the DRV in the RSC block.
+
+- qcom,tcs-config:
+   Usage: required
+   Value type: 
+   Definition: the tuple defining the configuration of TCS.
+   Must have 2 cells which describe each TCS type.
+   .
+   The order of the TCS must match the hardware
+   configuration.
+   - Cell #1 (TCS Type): TCS types to be specified -
+   SLEEP_TCS
+   WAKE_TCS
+   ACTIVE_TCS
+   CONTROL_TCS
+   - Cell #2 (Number of TCS): 
+
+- label:
+   Usage: optional
+   Value type: 
+   Definition: Name for the RSC. The name would be used in trace logs.
+
+Drivers that want to use the RSC to communicate with RPMH must specify their
+bindings as child of the RSC controllers they wish to communicate with.


Is that going to work for drivers that want to talk to two or more RSCs?
I suppose that they'll have to hook up into some sort of framework like
clk or regulator and then drivers that want to use two RSCs for those
things would be linked to those sub-device drivers with the normal clk
or regulator bindings?


Correct. This follows the same model as RPM SMD driver.


+
+Example 1:
+
+For a TCS whose RSC base address is is 0x179C and is at a DRV id of 2, the
+register offsets for DRV2 start at 0D00, the register calculations are like
+this -
+First tuple: 0x179C + 0x1 * 2 = 0x179E
+Second tuple: 0x179E + 0xD00 = 0x179E0D00
+
+   apps_rsc: rsc@179e000 {
+   label = "apps_rsc";
+   compatible = "qcom,rpmh-rsc";
+   reg = <0x179e 0x1>, <0x179e0d00 0x3000>;
+   reg-names = "drv", "tcs";
+   interrupts = ;
+   qcom,drv-id = <2>;
+   qcom,tcs-config = ,
+ ,
+ ,
+

Re: [PATCH v3 02/10] dt-bindings: introduce RPMH RSC bindings for Qualcomm SoCs

2018-03-07 Thread Lina Iyer 

On Tue, Mar 06 2018 at 15:30 -0700, Stephen Boyd wrote:

Quoting Lina Iyer (2018-03-02 08:43:09)

Add device binding documentation for Qualcomm Technology Inc's RPMH RSC
driver. The hardware block is used for communicating resource state


s/driver/hardware/


Ok.


requests for shared resources.

Cc: devicet...@vger.kernel.org
Signed-off-by: Lina Iyer 
---

Changes in v2:
- Amend text to describe the registers in reg property
- Add reg-names for the registers
- Update examples to use GIC_SPI in interrupts instead of 0
- Rephrase incorrect description

Changes in v3:
- Fix unwanted capitalization
- Remove clients from the examples, this doc does not describe
  them
- Rephrase introductory paragraph
- Remove hardware specifics from DT bindings
---
 .../devicetree/bindings/arm/msm/rpmh-rsc.txt   | 131 +
 1 file changed, 131 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt

diff --git a/Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt 
b/Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt
new file mode 100644
index ..afd3817cc615
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt


Shouldn't this go into bindings/soc/qcom/ ?


Didn;t realize the location. Thanks for pointing out.


+

+Requests can be made for the state of a resource, when the subsystem is active
+or idle. When all subsystems like Modem, GPU, CPU are idle, the resource state
+will be an aggregate of the sleep votes from each of those subsystem. Drivers


s/subsystem/subsystems/
s/Drivers/Clients/ ?


Ok


+may request a sleep value for their shared resources in addition to the active
+mode requests.
+
+Control requests are instance specific requests that may or may not reach an
+accelerator. Only one platform device in Linux can request a control channel
+on a DRV.


Not sure what this last sentence has to do with the DT binding. We
generally try to avoid saying 'Linux' or 'driver' in DT binding
documents, because they usually document hardware.


This para can go away.


+
+Properties:
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: Should be "qcom,rpmh-rsc".
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: The first register specifies the base address of the DRV.
+   The second register specifies the start address of the
+   TCS.
+
+- reg-names:
+   Usage: required


optional?


No, it is required. Driver has been using the by_name for clarity.


+   Value type: 
+   Definition: Maps the register specified in the reg property. Must be
+   "drv" and "tcs".
+
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: The interrupt that trips when a message complete/response
+  is received for this DRV from the accelerators.
+
+- qcom,drv-id:
+   Usage: required
+   Value type: 
+   Definition: the id of the DRV in the RSC block.
+
+- qcom,tcs-config:
+   Usage: required
+   Value type: 
+   Definition: the tuple defining the configuration of TCS.
+   Must have 2 cells which describe each TCS type.
+   .
+   The order of the TCS must match the hardware
+   configuration.
+   - Cell #1 (TCS Type): TCS types to be specified -
+   SLEEP_TCS
+   WAKE_TCS
+   ACTIVE_TCS
+   CONTROL_TCS
+   - Cell #2 (Number of TCS): 
+
+- label:
+   Usage: optional
+   Value type: 
+   Definition: Name for the RSC. The name would be used in trace logs.
+
+Drivers that want to use the RSC to communicate with RPMH must specify their
+bindings as child of the RSC controllers they wish to communicate with.


Is that going to work for drivers that want to talk to two or more RSCs?
I suppose that they'll have to hook up into some sort of framework like
clk or regulator and then drivers that want to use two RSCs for those
things would be linked to those sub-device drivers with the normal clk
or regulator bindings?


Correct. This follows the same model as RPM SMD driver.


+
+Example 1:
+
+For a TCS whose RSC base address is is 0x179C and is at a DRV id of 2, the
+register offsets for DRV2 start at 0D00, the register calculations are like
+this -
+First tuple: 0x179C + 0x1 * 2 = 0x179E
+Second tuple: 0x179E + 0xD00 = 0x179E0D00
+
+   apps_rsc: rsc@179e000 {
+   label = "apps_rsc";
+   compatible = "qcom,rpmh-rsc";
+   reg = <0x179e 0x1>, <0x179e0d00 0x3000>;
+   reg-names = "drv", "tcs";
+   interrupts = ;
+   qcom,drv-id = <2>;
+   qcom,tcs-config = ,
+ ,
+ ,
+ ;


Could

Re: [PATCH v3 02/10] dt-bindings: introduce RPMH RSC bindings for Qualcomm SoCs

2018-03-06 Thread Stephen Boyd 
Quoting Lina Iyer (2018-03-02 08:43:09)
> Add device binding documentation for Qualcomm Technology Inc's RPMH RSC
> driver. The hardware block is used for communicating resource state

s/driver/hardware/

> requests for shared resources.
> 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Lina Iyer 
> ---
> 
> Changes in v2:
> - Amend text to describe the registers in reg property
> - Add reg-names for the registers
> - Update examples to use GIC_SPI in interrupts instead of 0
> - Rephrase incorrect description
> 
> Changes in v3:
> - Fix unwanted capitalization
> - Remove clients from the examples, this doc does not describe
>   them
> - Rephrase introductory paragraph
> - Remove hardware specifics from DT bindings
> ---
>  .../devicetree/bindings/arm/msm/rpmh-rsc.txt   | 131 
> +
>  1 file changed, 131 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt 
> b/Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt
> new file mode 100644
> index ..afd3817cc615
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt

Shouldn't this go into bindings/soc/qcom/ ?

> @@ -0,0 +1,131 @@
> +RPMH RSC:
> +
> +
> +Resource Power Manager Hardened (RPMH) is the mechanism for communicating 
> with
> +the hardened resource accelerators on Qualcomm SoCs. Requests to the 
> resources
> +can be written to the Trigger Command Set (TCS)  registers and using a (addr,
> +val) pair and triggered. Messages in the TCS are then sent in sequence over 
> an
> +internal bus.
> +
> +The hardware block (Direct Resource Voter or DRV) is a part of the h/w entity
> +(Resource State Coordinator a.k.a RSC) that can handle a multiple sleep and
> +active/wake resource requests. Multiple such DRVs can exist in a SoC and can
> +be written to from Linux. The structure of each DRV follows the same template
> +with a few variations that are captured by the properties here.
> +
> +A TCS may be triggered from Linux or triggered by the F/W after all the CPUs
> +have powered off to facilitate idle power saving. TCS could be classified as 
> -
> +
> +   SLEEP,  /* Triggered by F/W */
> +   WAKE,   /* Triggered by F/W */
> +   ACTIVE, /* Triggered by Linux */
> +   CONTROL /* Triggered by F/W */
> +
> +The order in which they are described in the DT, should match the hardware
> +configuration.
> +
> +Requests can be made for the state of a resource, when the subsystem is 
> active
> +or idle. When all subsystems like Modem, GPU, CPU are idle, the resource 
> state
> +will be an aggregate of the sleep votes from each of those subsystem. Drivers

s/subsystem/subsystems/
s/Drivers/Clients/ ?

> +may request a sleep value for their shared resources in addition to the 
> active
> +mode requests.
> +
> +Control requests are instance specific requests that may or may not reach an
> +accelerator. Only one platform device in Linux can request a control channel
> +on a DRV.

Not sure what this last sentence has to do with the DT binding. We
generally try to avoid saying 'Linux' or 'driver' in DT binding
documents, because they usually document hardware.

> +
> +Properties:
> +
> +- compatible:
> +   Usage: required
> +   Value type: 
> +   Definition: Should be "qcom,rpmh-rsc".
> +
> +- reg:
> +   Usage: required
> +   Value type: 
> +   Definition: The first register specifies the base address of the DRV.
> +   The second register specifies the start address of the
> +   TCS.
> +
> +- reg-names:
> +   Usage: required

optional?

> +   Value type: 
> +   Definition: Maps the register specified in the reg property. Must be
> +   "drv" and "tcs".
> +
> +- interrupts:
> +   Usage: required
> +   Value type: 
> +   Definition: The interrupt that trips when a message complete/response
> +  is received for this DRV from the accelerators.
> +
> +- qcom,drv-id:
> +   Usage: required
> +   Value type: 
> +   Definition: the id of the DRV in the RSC block.
> +
> +- qcom,tcs-config:
> +   Usage: required
> +   Value type: 
> +   Definition: the tuple defining the configuration of TCS.
> +   Must have 2 cells which describe each TCS type.
> +   .
> +   The order of the TCS must match the hardware
> +   configuration.
> +   - Cell #1 (TCS Type): TCS types to be specified -
> +   SLEEP_TCS
> +   WAKE_TCS
> +   ACTIVE_TCS
> +   CONTROL_TCS
> +   - Cell #2 (Number of TCS): 
> +
> +- label:
> +   Usage: optional
> +   Value type: 
> +   Definition: Name for the RSC. The name would be used in trace logs.
> +
> +Drivers that want

Re: [PATCH v3 02/10] dt-bindings: introduce RPMH RSC bindings for Qualcomm SoCs

2018-03-06 Thread Stephen Boyd 
Quoting Lina Iyer (2018-03-02 08:43:09)
> Add device binding documentation for Qualcomm Technology Inc's RPMH RSC
> driver. The hardware block is used for communicating resource state

s/driver/hardware/

> requests for shared resources.
> 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Lina Iyer 
> ---
> 
> Changes in v2:
> - Amend text to describe the registers in reg property
> - Add reg-names for the registers
> - Update examples to use GIC_SPI in interrupts instead of 0
> - Rephrase incorrect description
> 
> Changes in v3:
> - Fix unwanted capitalization
> - Remove clients from the examples, this doc does not describe
>   them
> - Rephrase introductory paragraph
> - Remove hardware specifics from DT bindings
> ---
>  .../devicetree/bindings/arm/msm/rpmh-rsc.txt   | 131 
> +
>  1 file changed, 131 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt 
> b/Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt
> new file mode 100644
> index ..afd3817cc615
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt

Shouldn't this go into bindings/soc/qcom/ ?

> @@ -0,0 +1,131 @@
> +RPMH RSC:
> +
> +
> +Resource Power Manager Hardened (RPMH) is the mechanism for communicating 
> with
> +the hardened resource accelerators on Qualcomm SoCs. Requests to the 
> resources
> +can be written to the Trigger Command Set (TCS)  registers and using a (addr,
> +val) pair and triggered. Messages in the TCS are then sent in sequence over 
> an
> +internal bus.
> +
> +The hardware block (Direct Resource Voter or DRV) is a part of the h/w entity
> +(Resource State Coordinator a.k.a RSC) that can handle a multiple sleep and
> +active/wake resource requests. Multiple such DRVs can exist in a SoC and can
> +be written to from Linux. The structure of each DRV follows the same template
> +with a few variations that are captured by the properties here.
> +
> +A TCS may be triggered from Linux or triggered by the F/W after all the CPUs
> +have powered off to facilitate idle power saving. TCS could be classified as 
> -
> +
> +   SLEEP,  /* Triggered by F/W */
> +   WAKE,   /* Triggered by F/W */
> +   ACTIVE, /* Triggered by Linux */
> +   CONTROL /* Triggered by F/W */
> +
> +The order in which they are described in the DT, should match the hardware
> +configuration.
> +
> +Requests can be made for the state of a resource, when the subsystem is 
> active
> +or idle. When all subsystems like Modem, GPU, CPU are idle, the resource 
> state
> +will be an aggregate of the sleep votes from each of those subsystem. Drivers

s/subsystem/subsystems/
s/Drivers/Clients/ ?

> +may request a sleep value for their shared resources in addition to the 
> active
> +mode requests.
> +
> +Control requests are instance specific requests that may or may not reach an
> +accelerator. Only one platform device in Linux can request a control channel
> +on a DRV.

Not sure what this last sentence has to do with the DT binding. We
generally try to avoid saying 'Linux' or 'driver' in DT binding
documents, because they usually document hardware.

> +
> +Properties:
> +
> +- compatible:
> +   Usage: required
> +   Value type: 
> +   Definition: Should be "qcom,rpmh-rsc".
> +
> +- reg:
> +   Usage: required
> +   Value type: 
> +   Definition: The first register specifies the base address of the DRV.
> +   The second register specifies the start address of the
> +   TCS.
> +
> +- reg-names:
> +   Usage: required

optional?

> +   Value type: 
> +   Definition: Maps the register specified in the reg property. Must be
> +   "drv" and "tcs".
> +
> +- interrupts:
> +   Usage: required
> +   Value type: 
> +   Definition: The interrupt that trips when a message complete/response
> +  is received for this DRV from the accelerators.
> +
> +- qcom,drv-id:
> +   Usage: required
> +   Value type: 
> +   Definition: the id of the DRV in the RSC block.
> +
> +- qcom,tcs-config:
> +   Usage: required
> +   Value type: 
> +   Definition: the tuple defining the configuration of TCS.
> +   Must have 2 cells which describe each TCS type.
> +   .
> +   The order of the TCS must match the hardware
> +   configuration.
> +   - Cell #1 (TCS Type): TCS types to be specified -
> +   SLEEP_TCS
> +   WAKE_TCS
> +   ACTIVE_TCS
> +   CONTROL_TCS
> +   - Cell #2 (Number of TCS): 
> +
> +- label:
> +   Usage: optional
> +   Value type: 
> +   Definition: Name for the RSC. The name would be used in trace logs.
> +
> +Drivers that want to use the RSC to

[PATCH v3 02/10] dt-bindings: introduce RPMH RSC bindings for Qualcomm SoCs

2018-03-02 Thread Lina Iyer 
Add device binding documentation for Qualcomm Technology Inc's RPMH RSC
driver. The hardware block is used for communicating resource state
requests for shared resources.

Cc: devicet...@vger.kernel.org
Signed-off-by: Lina Iyer 
---

Changes in v2:
- Amend text to describe the registers in reg property
- Add reg-names for the registers
- Update examples to use GIC_SPI in interrupts instead of 0
- Rephrase incorrect description

Changes in v3:
- Fix unwanted capitalization
- Remove clients from the examples, this doc does not describe
  them
- Rephrase introductory paragraph
- Remove hardware specifics from DT bindings
---
 .../devicetree/bindings/arm/msm/rpmh-rsc.txt   | 131 +
 1 file changed, 131 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt

diff --git a/Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt 
b/Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt
new file mode 100644
index ..afd3817cc615
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt
@@ -0,0 +1,131 @@
+RPMH RSC:
+
+
+Resource Power Manager Hardened (RPMH) is the mechanism for communicating with
+the hardened resource accelerators on Qualcomm SoCs. Requests to the resources
+can be written to the Trigger Command Set (TCS)  registers and using a (addr,
+val) pair and triggered. Messages in the TCS are then sent in sequence over an
+internal bus.
+
+The hardware block (Direct Resource Voter or DRV) is a part of the h/w entity
+(Resource State Coordinator a.k.a RSC) that can handle a multiple sleep and
+active/wake resource requests. Multiple such DRVs can exist in a SoC and can
+be written to from Linux. The structure of each DRV follows the same template
+with a few variations that are captured by the properties here.
+
+A TCS may be triggered from Linux or triggered by the F/W after all the CPUs
+have powered off to facilitate idle power saving. TCS could be classified as -
+
+   SLEEP,  /* Triggered by F/W */
+   WAKE,   /* Triggered by F/W */
+   ACTIVE, /* Triggered by Linux */
+   CONTROL /* Triggered by F/W */
+
+The order in which they are described in the DT, should match the hardware
+configuration.
+
+Requests can be made for the state of a resource, when the subsystem is active
+or idle. When all subsystems like Modem, GPU, CPU are idle, the resource state
+will be an aggregate of the sleep votes from each of those subsystem. Drivers
+may request a sleep value for their shared resources in addition to the active
+mode requests.
+
+Control requests are instance specific requests that may or may not reach an
+accelerator. Only one platform device in Linux can request a control channel
+on a DRV.
+
+Properties:
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: Should be "qcom,rpmh-rsc".
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: The first register specifies the base address of the DRV.
+   The second register specifies the start address of the
+   TCS.
+
+- reg-names:
+   Usage: required
+   Value type: 
+   Definition: Maps the register specified in the reg property. Must be
+   "drv" and "tcs".
+
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: The interrupt that trips when a message complete/response
+  is received for this DRV from the accelerators.
+
+- qcom,drv-id:
+   Usage: required
+   Value type: 
+   Definition: the id of the DRV in the RSC block.
+
+- qcom,tcs-config:
+   Usage: required
+   Value type: 
+   Definition: the tuple defining the configuration of TCS.
+   Must have 2 cells which describe each TCS type.
+   .
+   The order of the TCS must match the hardware
+   configuration.
+   - Cell #1 (TCS Type): TCS types to be specified -
+   SLEEP_TCS
+   WAKE_TCS
+   ACTIVE_TCS
+   CONTROL_TCS
+   - Cell #2 (Number of TCS): 
+
+- label:
+   Usage: optional
+   Value type: 
+   Definition: Name for the RSC. The name would be used in trace logs.
+
+Drivers that want to use the RSC to communicate with RPMH must specify their
+bindings as child of the RSC controllers they wish to communicate with.
+
+Example 1:
+
+For a TCS whose RSC base address is is 0x179C and is at a DRV id of 2, the
+register offsets for DRV2 start at 0D00, the register calculations are like
+this -
+First tuple: 0x179C + 0x1 * 2 = 0x179E
+Second tuple: 0x179E + 0xD00 = 0x179E0D00
+
+   apps_rsc: rsc@179e000 {
+   label = "apps_rsc";
+   compatible = "qcom,rpmh-rsc";
+   reg = <0x179e 0x1>, <0x179e0d00 0x3000>;
+

[PATCH v3 02/10] dt-bindings: introduce RPMH RSC bindings for Qualcomm SoCs

2018-03-02 Thread Lina Iyer 
Add device binding documentation for Qualcomm Technology Inc's RPMH RSC
driver. The hardware block is used for communicating resource state
requests for shared resources.

Cc: devicet...@vger.kernel.org
Signed-off-by: Lina Iyer 
---

Changes in v2:
- Amend text to describe the registers in reg property
- Add reg-names for the registers
- Update examples to use GIC_SPI in interrupts instead of 0
- Rephrase incorrect description

Changes in v3:
- Fix unwanted capitalization
- Remove clients from the examples, this doc does not describe
  them
- Rephrase introductory paragraph
- Remove hardware specifics from DT bindings
---
 .../devicetree/bindings/arm/msm/rpmh-rsc.txt   | 131 +
 1 file changed, 131 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt

diff --git a/Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt 
b/Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt
new file mode 100644
index ..afd3817cc615
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt
@@ -0,0 +1,131 @@
+RPMH RSC:
+
+
+Resource Power Manager Hardened (RPMH) is the mechanism for communicating with
+the hardened resource accelerators on Qualcomm SoCs. Requests to the resources
+can be written to the Trigger Command Set (TCS)  registers and using a (addr,
+val) pair and triggered. Messages in the TCS are then sent in sequence over an
+internal bus.
+
+The hardware block (Direct Resource Voter or DRV) is a part of the h/w entity
+(Resource State Coordinator a.k.a RSC) that can handle a multiple sleep and
+active/wake resource requests. Multiple such DRVs can exist in a SoC and can
+be written to from Linux. The structure of each DRV follows the same template
+with a few variations that are captured by the properties here.
+
+A TCS may be triggered from Linux or triggered by the F/W after all the CPUs
+have powered off to facilitate idle power saving. TCS could be classified as -
+
+   SLEEP,  /* Triggered by F/W */
+   WAKE,   /* Triggered by F/W */
+   ACTIVE, /* Triggered by Linux */
+   CONTROL /* Triggered by F/W */
+
+The order in which they are described in the DT, should match the hardware
+configuration.
+
+Requests can be made for the state of a resource, when the subsystem is active
+or idle. When all subsystems like Modem, GPU, CPU are idle, the resource state
+will be an aggregate of the sleep votes from each of those subsystem. Drivers
+may request a sleep value for their shared resources in addition to the active
+mode requests.
+
+Control requests are instance specific requests that may or may not reach an
+accelerator. Only one platform device in Linux can request a control channel
+on a DRV.
+
+Properties:
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: Should be "qcom,rpmh-rsc".
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: The first register specifies the base address of the DRV.
+   The second register specifies the start address of the
+   TCS.
+
+- reg-names:
+   Usage: required
+   Value type: 
+   Definition: Maps the register specified in the reg property. Must be
+   "drv" and "tcs".
+
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: The interrupt that trips when a message complete/response
+  is received for this DRV from the accelerators.
+
+- qcom,drv-id:
+   Usage: required
+   Value type: 
+   Definition: the id of the DRV in the RSC block.
+
+- qcom,tcs-config:
+   Usage: required
+   Value type: 
+   Definition: the tuple defining the configuration of TCS.
+   Must have 2 cells which describe each TCS type.
+   .
+   The order of the TCS must match the hardware
+   configuration.
+   - Cell #1 (TCS Type): TCS types to be specified -
+   SLEEP_TCS
+   WAKE_TCS
+   ACTIVE_TCS
+   CONTROL_TCS
+   - Cell #2 (Number of TCS): 
+
+- label:
+   Usage: optional
+   Value type: 
+   Definition: Name for the RSC. The name would be used in trace logs.
+
+Drivers that want to use the RSC to communicate with RPMH must specify their
+bindings as child of the RSC controllers they wish to communicate with.
+
+Example 1:
+
+For a TCS whose RSC base address is is 0x179C and is at a DRV id of 2, the
+register offsets for DRV2 start at 0D00, the register calculations are like
+this -
+First tuple: 0x179C + 0x1 * 2 = 0x179E
+Second tuple: 0x179E + 0xD00 = 0x179E0D00
+
+   apps_rsc: rsc@179e000 {
+   label = "apps_rsc";
+   compatible = "qcom,rpmh-rsc";
+   reg = <0x179e 0x1>, <0x179e0d00 0x3000>;
+   reg-names = "drv", "tcs";
+