Re: [PATCH V2 1/5] Documentation: Add support for TI System Control Interface (TI-SCI) protocol

[Nishanth Menon]

On 09/05/2016 02:09 AM, Tero Kristo wrote:

On 02/09/16 23:27, Dave Gerlach wrote:

On 09/02/2016 12:07 PM, Nishanth Menon wrote:

Rob,

On Fri, Sep 2, 2016 at 10:06 AM, Rob Herring  wrote:

On Tue, Aug 30, 2016 at 08:06:43AM -0500, Nishanth Menon wrote:

[...]

+
+TI-SCI Client Device Node:
+
+
+Client nodes refer to the required TI-SCI device using the "ti,sci"
property.


As I mentioned for power domains, for clients that are self contained
(i.e. a single function) I think the should be child nodes.



Thanks for the feedback. I think we should be able to do that and also
assume you have no further improvements you'd like to see here.

Looking at current Documentation/devicetree/bindings/arm/arm,scpi.txt
-> it makes sense to stick along the same lines as you mentioned.

Dave, Tero: do you guys have any objections?


No objections, I think this is a logical move.


Yea, sounds like a valid change. I believe you are going to post a new
version so I can modify the clock driver also accordingly?


Just closing the loop here: https://lkml.org/lkml/2016/9/6/747 posted. 
the changes are in binding - clk driver itself should'nt by itself 
have any changes.



--
Regards,
Nishanth Menon

Re: [PATCH V2 1/5] Documentation: Add support for TI System Control Interface (TI-SCI) protocol

[Nishanth Menon]

On 09/05/2016 02:09 AM, Tero Kristo wrote:

On 02/09/16 23:27, Dave Gerlach wrote:

On 09/02/2016 12:07 PM, Nishanth Menon wrote:

Rob,

On Fri, Sep 2, 2016 at 10:06 AM, Rob Herring  wrote:

On Tue, Aug 30, 2016 at 08:06:43AM -0500, Nishanth Menon wrote:

[...]

+
+TI-SCI Client Device Node:
+
+
+Client nodes refer to the required TI-SCI device using the "ti,sci"
property.


As I mentioned for power domains, for clients that are self contained
(i.e. a single function) I think the should be child nodes.



Thanks for the feedback. I think we should be able to do that and also
assume you have no further improvements you'd like to see here.

Looking at current Documentation/devicetree/bindings/arm/arm,scpi.txt
-> it makes sense to stick along the same lines as you mentioned.

Dave, Tero: do you guys have any objections?


No objections, I think this is a logical move.


Yea, sounds like a valid change. I believe you are going to post a new
version so I can modify the clock driver also accordingly?


Just closing the loop here: https://lkml.org/lkml/2016/9/6/747 posted. 
the changes are in binding - clk driver itself should'nt by itself 
have any changes.



--
Regards,
Nishanth Menon

Re: [PATCH V2 1/5] Documentation: Add support for TI System Control Interface (TI-SCI) protocol

[Tero Kristo]

On 02/09/16 23:27, Dave Gerlach wrote:

On 09/02/2016 12:07 PM, Nishanth Menon wrote:

Rob,

On Fri, Sep 2, 2016 at 10:06 AM, Rob Herring  wrote:

On Tue, Aug 30, 2016 at 08:06:43AM -0500, Nishanth Menon wrote:

[...]

+
+TI-SCI Client Device Node:
+
+
+Client nodes refer to the required TI-SCI device using the "ti,sci"
property.


As I mentioned for power domains, for clients that are self contained
(i.e. a single function) I think the should be child nodes.



Thanks for the feedback. I think we should be able to do that and also
assume you have no further improvements you'd like to see here.

Looking at current Documentation/devicetree/bindings/arm/arm,scpi.txt
-> it makes sense to stick along the same lines as you mentioned.

Dave, Tero: do you guys have any objections?


No objections, I think this is a logical move.


Yea, sounds like a valid change. I believe you are going to post a new 
version so I can modify the clock driver also accordingly?


-Tero

Re: [PATCH V2 1/5] Documentation: Add support for TI System Control Interface (TI-SCI) protocol

[Tero Kristo]

On 02/09/16 23:27, Dave Gerlach wrote:

On 09/02/2016 12:07 PM, Nishanth Menon wrote:

Rob,

On Fri, Sep 2, 2016 at 10:06 AM, Rob Herring  wrote:

On Tue, Aug 30, 2016 at 08:06:43AM -0500, Nishanth Menon wrote:

[...]

+
+TI-SCI Client Device Node:
+
+
+Client nodes refer to the required TI-SCI device using the "ti,sci"
property.


As I mentioned for power domains, for clients that are self contained
(i.e. a single function) I think the should be child nodes.



Thanks for the feedback. I think we should be able to do that and also
assume you have no further improvements you'd like to see here.

Looking at current Documentation/devicetree/bindings/arm/arm,scpi.txt
-> it makes sense to stick along the same lines as you mentioned.

Dave, Tero: do you guys have any objections?


No objections, I think this is a logical move.


Yea, sounds like a valid change. I believe you are going to post a new 
version so I can modify the clock driver also accordingly?


-Tero

Re: [PATCH V2 1/5] Documentation: Add support for TI System Control Interface (TI-SCI) protocol

[Dave Gerlach]

On 09/02/2016 12:07 PM, Nishanth Menon wrote:

Rob,

On Fri, Sep 2, 2016 at 10:06 AM, Rob Herring  wrote:

On Tue, Aug 30, 2016 at 08:06:43AM -0500, Nishanth Menon wrote:

[...]

+
+TI-SCI Client Device Node:
+
+
+Client nodes refer to the required TI-SCI device using the "ti,sci" property.


As I mentioned for power domains, for clients that are self contained
(i.e. a single function) I think the should be child nodes.



Thanks for the feedback. I think we should be able to do that and also
assume you have no further improvements you'd like to see here.

Looking at current Documentation/devicetree/bindings/arm/arm,scpi.txt
-> it makes sense to stick along the same lines as you mentioned.

Dave, Tero: do you guys have any objections?


No objections, I think this is a logical move.

Regards,
Dave




---
Regards,
Nishanth Menon

Re: [PATCH V2 1/5] Documentation: Add support for TI System Control Interface (TI-SCI) protocol

[Dave Gerlach]

On 09/02/2016 12:07 PM, Nishanth Menon wrote:

Rob,

On Fri, Sep 2, 2016 at 10:06 AM, Rob Herring  wrote:

On Tue, Aug 30, 2016 at 08:06:43AM -0500, Nishanth Menon wrote:

[...]

+
+TI-SCI Client Device Node:
+
+
+Client nodes refer to the required TI-SCI device using the "ti,sci" property.


As I mentioned for power domains, for clients that are self contained
(i.e. a single function) I think the should be child nodes.



Thanks for the feedback. I think we should be able to do that and also
assume you have no further improvements you'd like to see here.

Looking at current Documentation/devicetree/bindings/arm/arm,scpi.txt
-> it makes sense to stick along the same lines as you mentioned.

Dave, Tero: do you guys have any objections?


No objections, I think this is a logical move.

Regards,
Dave




---
Regards,
Nishanth Menon

Re: [PATCH V2 1/5] Documentation: Add support for TI System Control Interface (TI-SCI) protocol

[Nishanth Menon]

Rob,

On Fri, Sep 2, 2016 at 10:06 AM, Rob Herring  wrote:
> On Tue, Aug 30, 2016 at 08:06:43AM -0500, Nishanth Menon wrote:
[...]
>> +
>> +TI-SCI Client Device Node:
>> +
>> +
>> +Client nodes refer to the required TI-SCI device using the "ti,sci" 
>> property.
>
> As I mentioned for power domains, for clients that are self contained
> (i.e. a single function) I think the should be child nodes.
>

Thanks for the feedback. I think we should be able to do that and also
assume you have no further improvements you'd like to see here.

Looking at current Documentation/devicetree/bindings/arm/arm,scpi.txt
-> it makes sense to stick along the same lines as you mentioned.

Dave, Tero: do you guys have any objections?


---
Regards,
Nishanth Menon

Re: [PATCH V2 1/5] Documentation: Add support for TI System Control Interface (TI-SCI) protocol

[Nishanth Menon]

Rob,

On Fri, Sep 2, 2016 at 10:06 AM, Rob Herring  wrote:
> On Tue, Aug 30, 2016 at 08:06:43AM -0500, Nishanth Menon wrote:
[...]
>> +
>> +TI-SCI Client Device Node:
>> +
>> +
>> +Client nodes refer to the required TI-SCI device using the "ti,sci" 
>> property.
>
> As I mentioned for power domains, for clients that are self contained
> (i.e. a single function) I think the should be child nodes.
>

Thanks for the feedback. I think we should be able to do that and also
assume you have no further improvements you'd like to see here.

Looking at current Documentation/devicetree/bindings/arm/arm,scpi.txt
-> it makes sense to stick along the same lines as you mentioned.

Dave, Tero: do you guys have any objections?


---
Regards,
Nishanth Menon

Re: [PATCH V2 1/5] Documentation: Add support for TI System Control Interface (TI-SCI) protocol

[Rob Herring]

On Tue, Aug 30, 2016 at 08:06:43AM -0500, Nishanth Menon wrote:
> Texas Instrument's System Control Interface (TI-SCI) Message Protocol
> is used in Texas Instrument's System on Chip (SoC) such as those in
> newer SoCs in the keystone processor family starting with K2G.
> 
> This message protocol is used to communicate between various compute
> or processing entities (such as ARM, DSP etc.) with a central system
> controller entity.
> 
> TI-SCI message protocol provides support for management of various
> hardware entities within the SoC.
> 
> The message protocol can be found here:
> http://processors.wiki.ti.com/index.php/TISCI
> 
> Signed-off-by: Nishanth Menon 
> ---
> Changes since v1:
>   - squashed the bindings changes for reset on review comments from
>   https://patchwork.kernel.org/patch/9291351/
> 
> V1: https://patchwork.kernel.org/patch/9291343/
> 
>  .../devicetree/bindings/arm/keystone/ti,sci.txt| 66 
> ++
>  MAINTAINERS|  8 +++
>  2 files changed, 74 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt 
> b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> new file mode 100644
> index ..ed5b8fc185f1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> @@ -0,0 +1,66 @@
> +Texas Instruments System Control Interface (TI-SCI) Message Protocol
> +---
> +
> +Texas Instrument's processors including those belonging to Keystone 
> generation
> +of processors have separate hardware entity which is now responsible for the
> +management of the System on Chip (SoC) system. These include various system
> +level functions as well.
> +
> +An example of such an SoC is K2G, which contains the system control hardware
> +block called Power Management Micro Controller (PMMC). This hardware block is
> +initialized early into boot process and provides services to Operating 
> Systems
> +on multiple processors including ones running Linux.
> +
> +See http://processors.wiki.ti.com/index.php/TISCI for protocol definition.
> +
> +TI-SCI controller Device Node:
> +=
> +
> +Required properties:
> +
> +- compatible: should be "ti,k2g-sci"
> +- mbox-names:
> + "rx" - Mailbox corresponding to receive path
> + "tx" - Mailbox corresponding to transmit path
> +
> +- mboxes: Mailboxes corresponding to the mbox-names. Each value of the mboxes
> +   property should contain a phandle to the mailbox controller device
> +   node and an args specifier that will be the phandle to the intended
> +   sub-mailbox child node to be used for communication.
> +
> +See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details
> +about the generic mailbox controller and client driver bindings. Also see
> +Documentation/devicetree/bindings/mailbox/ti,message-manager.txt for typical
> +controller that is used to communicate with this System controllers.
> +
> +Optional Properties:
> +
> +- reg-names:
> + debug_messages - Map the Debug message region
> +- reg:  register space corresponding to the debug_messages
> +- ti,system-reboot-controller: If system reboot can be triggered by SoC 
> reboot
> +
> +Example (K2G):
> +
> + pmmc: pmmc {
> + compatible = "ti,k2g-sci";
> + mbox-names = "rx", "tx";
> + mboxes= < _proxy_pmmc_rx>,
> + < _proxy_pmmc_tx>;
> + reg-names = "debug_messages";
> + reg = <0x02921800 0x800>;
> + };
> +
> +
> +TI-SCI Client Device Node:
> +
> +
> +Client nodes refer to the required TI-SCI device using the "ti,sci" property.

As I mentioned for power domains, for clients that are self contained 
(i.e. a single function) I think the should be child nodes.

> +
> +Example (K2G):
> +-
> + my_dev_node: dev_node {
> + ...
> + ti,sci = <>;
> + ...
> + }
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 20bb1d00098c..ce7306897ae0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11564,6 +11564,14 @@ S:   Maintained
>  F:   arch/xtensa/
>  F:   drivers/irqchip/irq-xtensa-*
>  
> +Texas Instruments' System Control Interface (TISCI) Protocol Driver
> +M:   Nishanth Menon 
> +M:   Tero Kristo 
> +M:   Santosh Shilimkar 
> +L:   linux-arm-ker...@lists.infradead.org
> +S:   Maintained
> +F:   Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> +
>  THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER
>  M:   Hans Verkuil 
>  L:   linux-me...@vger.kernel.org
> -- 
> 2.9.1.200.gb1ec08f
> 

Re: [PATCH V2 1/5] Documentation: Add support for TI System Control Interface (TI-SCI) protocol

[Rob Herring]

On Tue, Aug 30, 2016 at 08:06:43AM -0500, Nishanth Menon wrote:
> Texas Instrument's System Control Interface (TI-SCI) Message Protocol
> is used in Texas Instrument's System on Chip (SoC) such as those in
> newer SoCs in the keystone processor family starting with K2G.
> 
> This message protocol is used to communicate between various compute
> or processing entities (such as ARM, DSP etc.) with a central system
> controller entity.
> 
> TI-SCI message protocol provides support for management of various
> hardware entities within the SoC.
> 
> The message protocol can be found here:
> http://processors.wiki.ti.com/index.php/TISCI
> 
> Signed-off-by: Nishanth Menon 
> ---
> Changes since v1:
>   - squashed the bindings changes for reset on review comments from
>   https://patchwork.kernel.org/patch/9291351/
> 
> V1: https://patchwork.kernel.org/patch/9291343/
> 
>  .../devicetree/bindings/arm/keystone/ti,sci.txt| 66 
> ++
>  MAINTAINERS|  8 +++
>  2 files changed, 74 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt 
> b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> new file mode 100644
> index ..ed5b8fc185f1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> @@ -0,0 +1,66 @@
> +Texas Instruments System Control Interface (TI-SCI) Message Protocol
> +---
> +
> +Texas Instrument's processors including those belonging to Keystone 
> generation
> +of processors have separate hardware entity which is now responsible for the
> +management of the System on Chip (SoC) system. These include various system
> +level functions as well.
> +
> +An example of such an SoC is K2G, which contains the system control hardware
> +block called Power Management Micro Controller (PMMC). This hardware block is
> +initialized early into boot process and provides services to Operating 
> Systems
> +on multiple processors including ones running Linux.
> +
> +See http://processors.wiki.ti.com/index.php/TISCI for protocol definition.
> +
> +TI-SCI controller Device Node:
> +=
> +
> +Required properties:
> +
> +- compatible: should be "ti,k2g-sci"
> +- mbox-names:
> + "rx" - Mailbox corresponding to receive path
> + "tx" - Mailbox corresponding to transmit path
> +
> +- mboxes: Mailboxes corresponding to the mbox-names. Each value of the mboxes
> +   property should contain a phandle to the mailbox controller device
> +   node and an args specifier that will be the phandle to the intended
> +   sub-mailbox child node to be used for communication.
> +
> +See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details
> +about the generic mailbox controller and client driver bindings. Also see
> +Documentation/devicetree/bindings/mailbox/ti,message-manager.txt for typical
> +controller that is used to communicate with this System controllers.
> +
> +Optional Properties:
> +
> +- reg-names:
> + debug_messages - Map the Debug message region
> +- reg:  register space corresponding to the debug_messages
> +- ti,system-reboot-controller: If system reboot can be triggered by SoC 
> reboot
> +
> +Example (K2G):
> +
> + pmmc: pmmc {
> + compatible = "ti,k2g-sci";
> + mbox-names = "rx", "tx";
> + mboxes= < _proxy_pmmc_rx>,
> + < _proxy_pmmc_tx>;
> + reg-names = "debug_messages";
> + reg = <0x02921800 0x800>;
> + };
> +
> +
> +TI-SCI Client Device Node:
> +
> +
> +Client nodes refer to the required TI-SCI device using the "ti,sci" property.

As I mentioned for power domains, for clients that are self contained 
(i.e. a single function) I think the should be child nodes.

> +
> +Example (K2G):
> +-
> + my_dev_node: dev_node {
> + ...
> + ti,sci = <>;
> + ...
> + }
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 20bb1d00098c..ce7306897ae0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11564,6 +11564,14 @@ S:   Maintained
>  F:   arch/xtensa/
>  F:   drivers/irqchip/irq-xtensa-*
>  
> +Texas Instruments' System Control Interface (TISCI) Protocol Driver
> +M:   Nishanth Menon 
> +M:   Tero Kristo 
> +M:   Santosh Shilimkar 
> +L:   linux-arm-ker...@lists.infradead.org
> +S:   Maintained
> +F:   Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> +
>  THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER
>  M:   Hans Verkuil 
>  L:   linux-me...@vger.kernel.org
> -- 
> 2.9.1.200.gb1ec08f
>