diff mbox

[v2,1/2] soc: qcom: Add device tree binding for GLINK RPM

Message ID 20170320210956.29641-1-bjorn.andersson@linaro.org (mailing list archive)
State Superseded
Headers show

Commit Message

Bjorn Andersson March 20, 2017, 9:09 p.m. UTC 
Add device tree binding documentation for the Qualcomm GLINK RPM, used
for communication with the Resource Power Management subsystem in
various Qualcomm SoCs.

Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Changes since v1:
- None

 .../devicetree/bindings/soc/qcom/qcom,glink.txt    | 73 ++++++++++++++++++++++
 1 file changed, 73 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt

Comments

Rob Herring March 24, 2017, 4:07 p.m. UTC | #1 
On Mon, Mar 20, 2017 at 02:09:55PM -0700, Bjorn Andersson wrote:
> Add device tree binding documentation for the Qualcomm GLINK RPM, used
> for communication with the Resource Power Management subsystem in
> various Qualcomm SoCs.
> 
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> 
> Changes since v1:
> - None
> 
>  .../devicetree/bindings/soc/qcom/qcom,glink.txt    | 73 ++++++++++++++++++++++
>  1 file changed, 73 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
> 
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
> new file mode 100644
> index 000000000000..da92c4f787f3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
> @@ -0,0 +1,73 @@
> +Qualcomm RPM GLINK binding
> +
> +This binding describes the Qualcomm RPM GLINK, a fifo based mechanism for
> +communication with the Resource Power Management system on various Qualcomm
> +platforms.
> +
> +- compatible:
> +	Usage: required
> +	Value type: <stringlist>
> +	Definition: must be "qcom,glink-rpm"

SoC specific compatibles please.

> +
> +- interrupts:
> +	Usage: required
> +	Value type: <prop-encoded-array>
> +	Definition: should specify the IRQ used by the remote processor to
> +		    signal this processor about communication related events
> +
> +- qcom,rpm-msg-ram:
> +	Usage: required
> +	Value type: <prop-encoded-array>
> +	Definition: handle to RPM message memory resource
> +
> +- qcom,ipc:
> +	Usage: required
> +	Value type: <prop-encoded-array>
> +	Definition: three entries specifying the outgoing ipc bit used for
> +		    signaling the remote processor:
> +		    - phandle to a syscon node representing the apcs registers
> +		    - u32 representing offset to the register within the syscon
> +		    - u32 representing the ipc bit within the register
> +
> += GLINK DEVICES
> +Each subnode of the GLINK node represent function tied to a virtual
> +communication channel. The name of the nodes are not important. The properties
> +of these nodes are defined by the individual bindings for the specific function
> +- but must contain the following property:
> +
> +- qcom,glink-channels:
> +	Usage: required
> +	Value type: <stringlist>
> +	Definition: a list of channels tied to this function, used for matching
> +		    the function to a set of virtual channels
> +
> += EXAMPLE
> +The following example represents the GLINK RPM node on a MSM8996 device, with
> +the function for the "rpm_request" channel defined, which is used for
> +regualtors and root clocks.
> +
> +	apcs: syscon@f9011000 {
> +		compatible = "syscon";

syscon alone is not valid.

> +		reg = <0xf9011000 0x1000>;
> +	};
> +
> +	rpm_msg_ram: memory@68000 {
> +		compatible = "qcom,rpm-msg-ram";

Is this more than just mmio-sram?

Or with a fixed use could be part of another node?

> +		reg = <0x68000 0x6000>;
> +	};
> +
> +        rpm-glink {
> +		compatible = "qcom,glink-rpm";
> +
> +		interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>;
> +
> +		qcom,rpm-msg-ram = <&rpm_msg_ram>;
> +		qcom,ipc = <&apcs 0x10 0>;
> +
> +		rpm-requests {
> +			compatible = "qcom,rpm-msm8996";
> +			qcom,glink-channels = "rpm_requests";
> +
> +			...
> +		};
> +	};
> -- 
> 2.12.0
> 
--
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
Bjorn Andersson March 26, 2017, 4:31 a.m. UTC | #2 
On Fri 24 Mar 09:07 PDT 2017, Rob Herring wrote:

> On Mon, Mar 20, 2017 at 02:09:55PM -0700, Bjorn Andersson wrote:
> > Add device tree binding documentation for the Qualcomm GLINK RPM, used
> > for communication with the Resource Power Management subsystem in
> > various Qualcomm SoCs.
> > 
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > ---
> > 
> > Changes since v1:
> > - None
> > 
> >  .../devicetree/bindings/soc/qcom/qcom,glink.txt    | 73 ++++++++++++++++++++++
> >  1 file changed, 73 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
> > new file mode 100644
> > index 000000000000..da92c4f787f3
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
> > @@ -0,0 +1,73 @@
> > +Qualcomm RPM GLINK binding
> > +
> > +This binding describes the Qualcomm RPM GLINK, a fifo based mechanism for
> > +communication with the Resource Power Management system on various Qualcomm
> > +platforms.
> > +
> > +- compatible:
> > +	Usage: required
> > +	Value type: <stringlist>
> > +	Definition: must be "qcom,glink-rpm"
> 
> SoC specific compatibles please.
> 

In addition to the generic qcom,glink-rpm I presume?

> > +
> > +- interrupts:
> > +	Usage: required
> > +	Value type: <prop-encoded-array>
> > +	Definition: should specify the IRQ used by the remote processor to
> > +		    signal this processor about communication related events
> > +
> > +- qcom,rpm-msg-ram:
> > +	Usage: required
> > +	Value type: <prop-encoded-array>
> > +	Definition: handle to RPM message memory resource
> > +
> > +- qcom,ipc:
> > +	Usage: required
> > +	Value type: <prop-encoded-array>
> > +	Definition: three entries specifying the outgoing ipc bit used for
> > +		    signaling the remote processor:
> > +		    - phandle to a syscon node representing the apcs registers
> > +		    - u32 representing offset to the register within the syscon
> > +		    - u32 representing the ipc bit within the register
> > +
> > += GLINK DEVICES
> > +Each subnode of the GLINK node represent function tied to a virtual
> > +communication channel. The name of the nodes are not important. The properties
> > +of these nodes are defined by the individual bindings for the specific function
> > +- but must contain the following property:
> > +
> > +- qcom,glink-channels:
> > +	Usage: required
> > +	Value type: <stringlist>
> > +	Definition: a list of channels tied to this function, used for matching
> > +		    the function to a set of virtual channels
> > +
> > += EXAMPLE
> > +The following example represents the GLINK RPM node on a MSM8996 device, with
> > +the function for the "rpm_request" channel defined, which is used for
> > +regualtors and root clocks.
> > +
> > +	apcs: syscon@f9011000 {
> > +		compatible = "syscon";
> 
> syscon alone is not valid.
> 

This is equivalent to how we have done this on all previous platforms.
On previous platforms this generally maps to one of the "Krait Processor
SubSystem" blocks, so I'm quite worried with coming up with a compatible
for this block will not be compatible with any future description of
this block.

> > +		reg = <0xf9011000 0x1000>;
> > +	};
> > +
> > +	rpm_msg_ram: memory@68000 {
> > +		compatible = "qcom,rpm-msg-ram";
> 
> Is this more than just mmio-sram?
> 
> Or with a fixed use could be part of another node?
> 

It represents one of the RAM modules of one of the other ARM cores in
the SoC, used for shared memory communication with this ARM core. So the
hardware is essentially mmio-sram. But it has none of the properties
that a mmio-sram seem to have.

The reason I did not put it in the rpm-glink node is that in previous
Qualcomm platforms we have exactly the same system design, but the data
structure of the RAM was different, so it felt natural to just keep the
same description of the hardware.

> > +		reg = <0x68000 0x6000>;
> > +	};
> > +
> > +        rpm-glink {
> > +		compatible = "qcom,glink-rpm";
> > +
> > +		interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>;
> > +
> > +		qcom,rpm-msg-ram = <&rpm_msg_ram>;
> > +		qcom,ipc = <&apcs 0x10 0>;
> > +
> > +		rpm-requests {
> > +			compatible = "qcom,rpm-msm8996";
> > +			qcom,glink-channels = "rpm_requests";
> > +
> > +			...
> > +		};
> > +	};

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
Rob Herring March 27, 2017, 6:44 p.m. UTC | #3 
On Sat, Mar 25, 2017 at 11:31 PM, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> On Fri 24 Mar 09:07 PDT 2017, Rob Herring wrote:
>
>> On Mon, Mar 20, 2017 at 02:09:55PM -0700, Bjorn Andersson wrote:
>> > Add device tree binding documentation for the Qualcomm GLINK RPM, used
>> > for communication with the Resource Power Management subsystem in
>> > various Qualcomm SoCs.
>> >
>> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>> > ---
>> >
>> > Changes since v1:
>> > - None
>> >
>> >  .../devicetree/bindings/soc/qcom/qcom,glink.txt    | 73 ++++++++++++++++++++++
>> >  1 file changed, 73 insertions(+)
>> >  create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
>> > new file mode 100644
>> > index 000000000000..da92c4f787f3
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
>> > @@ -0,0 +1,73 @@
>> > +Qualcomm RPM GLINK binding
>> > +
>> > +This binding describes the Qualcomm RPM GLINK, a fifo based mechanism for
>> > +communication with the Resource Power Management system on various Qualcomm
>> > +platforms.
>> > +
>> > +- compatible:
>> > +   Usage: required
>> > +   Value type: <stringlist>
>> > +   Definition: must be "qcom,glink-rpm"
>>
>> SoC specific compatibles please.
>>
>
> In addition to the generic qcom,glink-rpm I presume?

Right.

>
>> > +
>> > +- interrupts:
>> > +   Usage: required
>> > +   Value type: <prop-encoded-array>
>> > +   Definition: should specify the IRQ used by the remote processor to
>> > +               signal this processor about communication related events
>> > +
>> > +- qcom,rpm-msg-ram:
>> > +   Usage: required
>> > +   Value type: <prop-encoded-array>
>> > +   Definition: handle to RPM message memory resource
>> > +
>> > +- qcom,ipc:
>> > +   Usage: required
>> > +   Value type: <prop-encoded-array>
>> > +   Definition: three entries specifying the outgoing ipc bit used for
>> > +               signaling the remote processor:
>> > +               - phandle to a syscon node representing the apcs registers
>> > +               - u32 representing offset to the register within the syscon
>> > +               - u32 representing the ipc bit within the register
>> > +
>> > += GLINK DEVICES
>> > +Each subnode of the GLINK node represent function tied to a virtual
>> > +communication channel. The name of the nodes are not important. The properties
>> > +of these nodes are defined by the individual bindings for the specific function
>> > +- but must contain the following property:
>> > +
>> > +- qcom,glink-channels:
>> > +   Usage: required
>> > +   Value type: <stringlist>
>> > +   Definition: a list of channels tied to this function, used for matching
>> > +               the function to a set of virtual channels
>> > +
>> > += EXAMPLE
>> > +The following example represents the GLINK RPM node on a MSM8996 device, with
>> > +the function for the "rpm_request" channel defined, which is used for
>> > +regualtors and root clocks.
>> > +
>> > +   apcs: syscon@f9011000 {
>> > +           compatible = "syscon";
>>
>> syscon alone is not valid.
>>
>
> This is equivalent to how we have done this on all previous platforms.

Then they are wrong...

> On previous platforms this generally maps to one of the "Krait Processor
> SubSystem" blocks, so I'm quite worried with coming up with a compatible
> for this block will not be compatible with any future description of
> this block.

Perhaps why we should get rid of syscon. It's not supposed to be a "I
don't know how to define a binding, so just make all registers
available for now".

I don't really see how a compatible string alone would create problems
to extend the binding if you need to later. Even if it did, you can
always rev compatible strings.

>> > +           reg = <0xf9011000 0x1000>;
>> > +   };
>> > +
>> > +   rpm_msg_ram: memory@68000 {
>> > +           compatible = "qcom,rpm-msg-ram";
>>
>> Is this more than just mmio-sram?
>>
>> Or with a fixed use could be part of another node?
>>
>
> It represents one of the RAM modules of one of the other ARM cores in
> the SoC, used for shared memory communication with this ARM core. So the
> hardware is essentially mmio-sram. But it has none of the properties
> that a mmio-sram seem to have.

Properties such as?

>
> The reason I did not put it in the rpm-glink node is that in previous
> Qualcomm platforms we have exactly the same system design, but the data
> structure of the RAM was different, so it felt natural to just keep the
> same description of the hardware.
>
>> > +           reg = <0x68000 0x6000>;
>> > +   };
>> > +
>> > +        rpm-glink {
>> > +           compatible = "qcom,glink-rpm";
>> > +
>> > +           interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>;
>> > +
>> > +           qcom,rpm-msg-ram = <&rpm_msg_ram>;
>> > +           qcom,ipc = <&apcs 0x10 0>;
>> > +
>> > +           rpm-requests {
>> > +                   compatible = "qcom,rpm-msm8996";
>> > +                   qcom,glink-channels = "rpm_requests";
>> > +
>> > +                   ...
>> > +           };
>> > +   };
>
> 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
Bjorn Andersson March 27, 2017, 11:30 p.m. UTC | #4 
On Mon 27 Mar 11:44 PDT 2017, Rob Herring wrote:

> On Sat, Mar 25, 2017 at 11:31 PM, Bjorn Andersson
> <bjorn.andersson@linaro.org> wrote:
> > On Fri 24 Mar 09:07 PDT 2017, Rob Herring wrote:
> >
> >> On Mon, Mar 20, 2017 at 02:09:55PM -0700, Bjorn Andersson wrote:
> >> > Add device tree binding documentation for the Qualcomm GLINK RPM, used
> >> > for communication with the Resource Power Management subsystem in
> >> > various Qualcomm SoCs.
> >> >
> >> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> >> > ---
> >> >
> >> > Changes since v1:
> >> > - None
> >> >
> >> >  .../devicetree/bindings/soc/qcom/qcom,glink.txt    | 73 ++++++++++++++++++++++
> >> >  1 file changed, 73 insertions(+)
> >> >  create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
> >> >
> >> > diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
> >> > new file mode 100644
> >> > index 000000000000..da92c4f787f3
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
> >> > @@ -0,0 +1,73 @@
> >> > +Qualcomm RPM GLINK binding
> >> > +
> >> > +This binding describes the Qualcomm RPM GLINK, a fifo based mechanism for
> >> > +communication with the Resource Power Management system on various Qualcomm
> >> > +platforms.
> >> > +
> >> > +- compatible:
> >> > +   Usage: required
> >> > +   Value type: <stringlist>
> >> > +   Definition: must be "qcom,glink-rpm"
> >>
> >> SoC specific compatibles please.
> >>
> >
> > In addition to the generic qcom,glink-rpm I presume?
> 
> Right.
> 
> >
> >> > +
> >> > +- interrupts:
> >> > +   Usage: required
> >> > +   Value type: <prop-encoded-array>
> >> > +   Definition: should specify the IRQ used by the remote processor to
> >> > +               signal this processor about communication related events
> >> > +
> >> > +- qcom,rpm-msg-ram:
> >> > +   Usage: required
> >> > +   Value type: <prop-encoded-array>
> >> > +   Definition: handle to RPM message memory resource
> >> > +
> >> > +- qcom,ipc:
> >> > +   Usage: required
> >> > +   Value type: <prop-encoded-array>
> >> > +   Definition: three entries specifying the outgoing ipc bit used for
> >> > +               signaling the remote processor:
> >> > +               - phandle to a syscon node representing the apcs registers
> >> > +               - u32 representing offset to the register within the syscon
> >> > +               - u32 representing the ipc bit within the register
> >> > +
> >> > += GLINK DEVICES
> >> > +Each subnode of the GLINK node represent function tied to a virtual
> >> > +communication channel. The name of the nodes are not important. The properties
> >> > +of these nodes are defined by the individual bindings for the specific function
> >> > +- but must contain the following property:
> >> > +
> >> > +- qcom,glink-channels:
> >> > +   Usage: required
> >> > +   Value type: <stringlist>
> >> > +   Definition: a list of channels tied to this function, used for matching
> >> > +               the function to a set of virtual channels
> >> > +
> >> > += EXAMPLE
> >> > +The following example represents the GLINK RPM node on a MSM8996 device, with
> >> > +the function for the "rpm_request" channel defined, which is used for
> >> > +regualtors and root clocks.
> >> > +
> >> > +   apcs: syscon@f9011000 {
> >> > +           compatible = "syscon";
> >>
> >> syscon alone is not valid.
> >>
> >
> > This is equivalent to how we have done this on all previous platforms.
> 
> Then they are wrong...
> 
> > On previous platforms this generally maps to one of the "Krait Processor
> > SubSystem" blocks, so I'm quite worried with coming up with a compatible
> > for this block will not be compatible with any future description of
> > this block.
> 
> Perhaps why we should get rid of syscon. It's not supposed to be a "I
> don't know how to define a binding, so just make all registers
> available for now".
> 

I know...

> I don't really see how a compatible string alone would create problems
> to extend the binding if you need to later. Even if it did, you can
> always rev compatible strings.
> 

The problem is that the "apcs" region is just one of the regions related
to the KPSS; this one being the "global" region.

I could just replace the current occurrences with
"qcom,msm8974-apcs-kpss-glb" and "qcom,msm8916-apcs-kpss-glb" and then
try to figure out what it's called in this platform. I am worried,
however, that this description of the "kpss" hardware won't be the right
approach if/when anyone else tries to actually model it.


There has been talks about replacing the use of syscon here with a new
"ipc-kicker" description. Should I propose a completely new binding for
"invoking IRQs on remote processors" instead of using syscon? What's the
name of such a bike shed?

> >> > +           reg = <0xf9011000 0x1000>;
> >> > +   };
> >> > +
> >> > +   rpm_msg_ram: memory@68000 {
> >> > +           compatible = "qcom,rpm-msg-ram";
> >>
> >> Is this more than just mmio-sram?
> >>
> >> Or with a fixed use could be part of another node?
> >>

On prior platforms it was part of the qcom,smem node but was extracted
to better represent the hardware design.

> >
> > It represents one of the RAM modules of one of the other ARM cores in
> > the SoC, used for shared memory communication with this ARM core. So the
> > hardware is essentially mmio-sram. But it has none of the properties
> > that a mmio-sram seem to have.
> 
> Properties such as?
> 

Probably unwise of me to use the word "properties" here, as I wasn't
thinking in DT lingo, but the first paragraph of sram.txt states:

"Simple IO memory regions to be managed by the genalloc API."

This memory is not managed by genalloc, it consists of a read-only
section where we can find a pointer to the subregion that we are allowed
to read and write - any accesses outside this region will cause a access
violation.

The subregion provided is shared with a remote processor and as such
must follow the predefined data-structure - implemented by something
claiming to implement "qcom,glink-rpm".

Looking at the sram implementation there's nothing even close to useful
for us there. Claiming that this memory is something that the Linux
implementation of mmio-sram will deal with just wrong.


It might be SRAM (although I believe it's on-chip DRAM) and it is memory
mapped, but that's where the similarities ends...

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/soc/qcom/qcom,glink.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
new file mode 100644
index 000000000000..da92c4f787f3
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
@@ -0,0 +1,73 @@ 
+Qualcomm RPM GLINK binding
+
+This binding describes the Qualcomm RPM GLINK, a fifo based mechanism for
+communication with the Resource Power Management system on various Qualcomm
+platforms.
+
+- compatible:
+	Usage: required
+	Value type: <stringlist>
+	Definition: must be "qcom,glink-rpm"
+
+- interrupts:
+	Usage: required
+	Value type: <prop-encoded-array>
+	Definition: should specify the IRQ used by the remote processor to
+		    signal this processor about communication related events
+
+- qcom,rpm-msg-ram:
+	Usage: required
+	Value type: <prop-encoded-array>
+	Definition: handle to RPM message memory resource
+
+- qcom,ipc:
+	Usage: required
+	Value type: <prop-encoded-array>
+	Definition: three entries specifying the outgoing ipc bit used for
+		    signaling the remote processor:
+		    - phandle to a syscon node representing the apcs registers
+		    - u32 representing offset to the register within the syscon
+		    - u32 representing the ipc bit within the register
+
+= GLINK DEVICES
+Each subnode of the GLINK node represent function tied to a virtual
+communication channel. The name of the nodes are not important. The properties
+of these nodes are defined by the individual bindings for the specific function
+- but must contain the following property:
+
+- qcom,glink-channels:
+	Usage: required
+	Value type: <stringlist>
+	Definition: a list of channels tied to this function, used for matching
+		    the function to a set of virtual channels
+
+= EXAMPLE
+The following example represents the GLINK RPM node on a MSM8996 device, with
+the function for the "rpm_request" channel defined, which is used for
+regualtors and root clocks.
+
+	apcs: syscon@f9011000 {
+		compatible = "syscon";
+		reg = <0xf9011000 0x1000>;
+	};
+
+	rpm_msg_ram: memory@68000 {
+		compatible = "qcom,rpm-msg-ram";
+		reg = <0x68000 0x6000>;
+	};
+
+        rpm-glink {
+		compatible = "qcom,glink-rpm";
+
+		interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>;
+
+		qcom,rpm-msg-ram = <&rpm_msg_ram>;
+		qcom,ipc = <&apcs 0x10 0>;
+
+		rpm-requests {
+			compatible = "qcom,rpm-msm8996";
+			qcom,glink-channels = "rpm_requests";
+
+			...
+		};
+	};