diff mbox

[RFC,2/6] dt-bindings: remoteproc: add system resource manager (SRM)

Message ID 1511534202-12995-3-git-send-email-arnaud.pouliquen@st.com (mailing list archive)
State New, archived
Headers show

Commit Message

Arnaud POULIQUEN Nov. 24, 2017, 2:36 p.m. UTC
From: Fabien Dessenne <fabien.dessenne@st.com>

Add Documentation of devicetree bindings to support the remote processor
system resource manager.

Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Loic Pallardy <loic.pallardy@st.com>
---
 .../devicetree/bindings/remoteproc/rproc-srm.txt   | 45 ++++++++++++++++++++++
 1 file changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/rproc-srm.txt

Comments

Bjorn Andersson Dec. 14, 2017, 5:59 a.m. UTC | #1
On Fri 24 Nov 06:36 PST 2017, Arnaud Pouliquen wrote:

> +Example:
> +	system_resources {
> +		compatible = "rproc-srm-core";
> +
> +		mmc0: sdhci@09060000 {
> +			compatible = "rproc-srm-dev";
> +			pinctrl-names = "default", "idle";
> +			pinctrl-0 = <&pinctrl_mmc0>;
> +			pinctrl-1 = <&pinctrl_mmc1>;
> +			clock-names = "mmc", "icn";
> +			clocks = <&clk_s_c0_flexgen CLK_MMC_0>,
> +				 <&clk_s_c0_flexgen CLK_RX_ICN_HVA>;
> +			vdda-supply = <&vdda>;
> +		};
> +	};

From a DT perspective these properties are all on the remoteproc. This
has the additional benefit of making the dynamic case much saner to
implement. I.e. if you have:

acme_rproc {
	compatible = "acme,rproc";

	clock-names = "ddr", "mmc";
	clocks = <&clocker DDR>, <&clocker MMC>;
};

Then you can declare statically in the acme,rproc that the "ddr" clock
should be enabled between boot and shutdown, or we can do this based on
resource table information, and you can easily acquire a handle to this
clock from a rpmsg device acting as dynamic controller of resources.

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Arnaud POULIQUEN Dec. 21, 2017, 5:46 p.m. UTC | #2
Hello Bjorn,

On 12/14/2017 06:59 AM, Bjorn Andersson wrote:
> On Fri 24 Nov 06:36 PST 2017, Arnaud Pouliquen wrote:
> 
>> +Example:
>> +	system_resources {
>> +		compatible = "rproc-srm-core";
>> +
>> +		mmc0: sdhci@09060000 {
>> +			compatible = "rproc-srm-dev";
>> +			pinctrl-names = "default", "idle";
>> +			pinctrl-0 = <&pinctrl_mmc0>;
>> +			pinctrl-1 = <&pinctrl_mmc1>;
>> +			clock-names = "mmc", "icn";
>> +			clocks = <&clk_s_c0_flexgen CLK_MMC_0>,
>> +				 <&clk_s_c0_flexgen CLK_RX_ICN_HVA>;
>> +			vdda-supply = <&vdda>;
>> +		};
>> +	};
> 
> From a DT perspective these properties are all on the remoteproc. This
> has the additional benefit of making the dynamic case much saner to
> implement. I.e. if you have:
> 
> acme_rproc {
> 	compatible = "acme,rproc";
> 
> 	clock-names = "ddr", "mmc";
> 	clocks = <&clocker DDR>, <&clocker MMC>;
> };
> 
> Then you can declare statically in the acme,rproc that the "ddr" clock
> should be enabled between boot and shutdown, or we can do this based on
> resource table information, and you can easily acquire a handle to this
> clock from a rpmsg device acting as dynamic controller of resources.

Let's try to clarify the concept we propose.

We distinguish 2 kinds of resources.

1) The resource "inherent" to the remote processor itself:
	- Core clocks
	- associated memories RAM, DDR,...
	- reset...
These resources are already handled by remoteproc core and platform.

2) The peripheral resources like a serial bus, an ADC, a DAC, GPIOs...
This peripheral can be allocated to the remote processor.
In this case the remote processor is in charge of managing the
peripheral itself (peripheral registers).
This peripheral needs clocks, regulators, pins...that are managed by
Linux frameworks.
Aim of the SRM is to handles these particular resources, and so to
provide a way to configure clock, pins, regulators... requested by these
peripherals to operate.

For instance, if a remote processor needs to drive an I2C master.
Linux needs to:
- configure the clock tree to provide a clocks for the I2C peripheral
and bus,
- configure pintrl for the I2C bus.

2 additional assumptions:
- remote processor doesn't have to know the clock and pins used, Linux
manages them.
- remote processor should be able to get and release the I2C peripheral.

This is the purpose of the SRM:
- Provide a simple way to declare system resource associated to a
peripheral in DT. The declaration is similar to a peripheral used by
linux processor.
- Provide a dynamic way to get/release and reconfigure system resources
associated to a peripheral. This part will need RPMsg add-on to be fully
dynamic.

Associate a Linux device per peripheral allows to bind peripheral to its
resources and to choice either a generic driver (proc-srm-dev) or a
specific platform driver to handle it.
for instance, a specific platform driver can be need if platform has
some specific "system" resources that need to be handle only on Linux
side to avoid concurrent access.

Extra usecases that could be managed by srm ( to be confirmed by deeper
analysis):
- Remote peripheral suspend/resume.
- DMA channels.
- Pins configurations before and after peripheral initialization to
avoid glitches
- Dynamic reallocation of a peripheral, from one processor to the other
( low power use cases).
...

Notice that, perhaps "srm" name is confusing and should be changed...

Regards
Arnaud
> 
> Regards,
> Bjorn
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/Documentation/devicetree/bindings/remoteproc/rproc-srm.txt b/Documentation/devicetree/bindings/remoteproc/rproc-srm.txt
new file mode 100644
index 0000000..986dad1
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/rproc-srm.txt
@@ -0,0 +1,45 @@ 
+Remoteproc System Resource Manager
+----------------------------------
+
+The remoteproc SRM (System Resource Manager) handles resources allocated
+to remote processors.
+This makes it possible for remote proc to reserve and initialize system
+resources for a peripheral assigned to a coprocessor.
+
+The devices are grouped in a core node
+
+Core
+====
+Required properties:
+- compatible: should be "rproc-srm-core"
+
+Dev
+===
+Required properties:
+- compatible: should be "rproc-srm-dev"
+
+Optional properties:
+- clocks: clocks required by the coprocessor
+- clock-names: see clock-bindings.txt
+- assigned-clocks: see clock-bindings.txt
+- assigned-clock-parents: see clock-bindings.txt
+- assigned-clock-rates: see clock-bindings.txt
+- pinctrl-x: pins configurations required by the coprocessor
+- pinctrl-names: see pinctrl-bindings.txt
+- x-supply: power supplies required by the coprocessor
+
+Example:
+	system_resources {
+		compatible = "rproc-srm-core";
+
+		mmc0: sdhci@09060000 {
+			compatible = "rproc-srm-dev";
+			pinctrl-names = "default", "idle";
+			pinctrl-0 = <&pinctrl_mmc0>;
+			pinctrl-1 = <&pinctrl_mmc1>;
+			clock-names = "mmc", "icn";
+			clocks = <&clk_s_c0_flexgen CLK_MMC_0>,
+				 <&clk_s_c0_flexgen CLK_RX_ICN_HVA>;
+			vdda-supply = <&vdda>;
+		};
+	};