Re: [PATCH 05/14] dt-bindings: remoteproc: Add Qualcomm RPM processor/subsystem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



<On Tue, Jun 06, 2023 at 08:36:10AM +0200, Krzysztof Kozlowski wrote:
> On 05/06/2023 09:08, Stephan Gerhold wrote:
> > On Qualcomm platforms, most subsystems (e.g. audio/modem DSP) are
> > described as remote processors in the device tree, with a dedicated
> > node where properties and services related to them can be described.
> > 
> > The Resource Power Manager (RPM) is also such a subsystem, with a
> > remote processor that is running a special firmware. Unfortunately,
> > the RPM never got a dedicated node representing it properly in the
> > device tree. Most of the RPM services are described below a top-level
> > /smd or /rpm-glink node.
> 
> Then what is rpm-requests? This is the true RPM. It looks like you now
> duplicate half of it in a node above. Unless you want here to describe
> ways to communicate with the RPM, not the RPM itself.
>

I think you're confusing hardware and firmware here. The rpm-proc node
represents the RPM hardware block (or perhaps the RPM firmware overall),
while rpm-requests is just *one* communication interface provided by the
RPM firmware. Here is a rough picture of the RPM "subsystem" I'm trying
to describe:

                +--------------------------------------------+      
                |       RPM subsystem (qcom,rpm-proc)        |      
                |                                            |      
          reset | +---------------+     +-----+  +-----+     |      
        --------->|               |     | MPM |  | CPR | ... |      
 IPC interrupts | | ARM Cortex-M3 |     +-----+  +-----+     |      
----------------->|               |---     |        |        |      
                | +---------------+  |---------------------- |      
                | +---------------+  |                       |      
                | |   Code RAM    |--|  +------------------+ |      
                | +---------------+  |  |                  | |      
                | +---------------+  |  |   Message RAM    | |      
                | |   Data RAM    |--|--|                  | |      
                | +---------------+  |  +------------------+ |      
                +--------------------|-----------------------+      
                                     v                              
                                    NoC                             

(Somewhat adapted from Figure 8-1 RPM overview in the APQ8016E Technical
 Reference Manual, but I added some extra stuff.)

As you can see neither "SMD" nor "rpm-requests" exist in hardware.
Again, it's just one communication protocol implemented by the RPM
firmware running on the Cortex-M3 processor, much like a webserver
running on a PC.

When the SoC is started only the hardware block exists. Usually a
component in the boot chain loads firmware into the code/data RAM and
then de-asserts the reset line to start the Cortex-M3 processor.

This is not guaranteed to happen. For example, I have a special firmware
version where the firmware is only loaded but not brought out of reset.
In this case Linux is responsible to de-assert the reset line.
In follow-up patches I add that to the outer qcom,rpm-proc node:

	remoteproc {
		compatible = "qcom,msm8916-rpm-proc", "qcom,rpm-proc";
		resets = <&gcc GCC_RPM_RESET>;
		iommus = <&apps_smmu 0x0040>;

		smd-edge {
			/* ... */
			rpm-requests {
				qcom,smd-channels = "rpm_requests";
			};
		};
	};

This reset line cannot be described on the rpm-requests node. Until the
firmware is started there is no such thing as "SMD" or "rpm-requests".

When the RPM firmware is started it sets up some data structures in the
message RAM and then begins serving requests, perhaps like this:

               +----------------------------------+                                    
               |          ARM Cortex-M3           |                                    
               | +------------------------------+ |  +--------------------------------+
               | |  RPM Firmware                | |  |          Message RAM           |
 IPC Interrupt | | +----------------------+     | |  | +----------------------------+ |
------------------>| SMD Server           |     | |  | | SMD Data Structures & FIFO | |
               | | | +--------------+     |     | |  | | +--------------+           | |
               | | | | rpm_requests | ... |     | |  | | | rpm_requests |    ...    | |
               | | | +--------------+     | ... | |  | | +--------------+           | |
               | | +----------------------+     | |  | +----------------------------+ |
               | +------------------------------+ |  |                ...             |
               +----------------------------------+  +--------------------------------+

The "smd-edge" node represents the SMD part and "rpm_requests" is one
of the communication channels that can be used to talk to the RPM firmware.

Everything below rpm-requests: clocks, regulators, power domains are
pure firmware constructions. They do not exist in the RPM hardware block,
the firmware just acts as a proxy to collect votes from different
clients and then configures the actual hardware.
 
> 
> > However, SMD/GLINK is just one of the communication channels to the RPM
> > firmware. For example, the MPM interrupt functionality provided by the
> > RPM does not use SMD/GLINK but writes directly to a special memory
> > region allocated by the RPM firmware in combination with a mailbox.
> > Currently there is no good place in the device tree to describe this
> > functionality. It doesn't belong below SMD/GLINK but it's not an
> > independent top-level device either.
> > 
> > Introduce a new "qcom,rpm-proc" compatible that allows describing the
> > RPM as a remote processor/subsystem like all others. The SMD/GLINK node
> > is moved to a "smd-edge"/"glink-edge" subnode consistent with other
> > existing bindings. Additional subnodes (e.g. interrupt-controller for
> > MPM, rpm-master-stats) can be also added there.
> 
> If this was about to stay, you should also update the qcom,smd.yaml, so
> there will be no duplication.
> 

qcom,smd.yaml is deprecated in the next patch (PATCH 07/14).

> > 
> > Signed-off-by: Stephan Gerhold <stephan@xxxxxxxxxxx>
> > ---
> >  .../bindings/remoteproc/qcom,rpm-proc.yaml         | 125 +++++++++++++++++++++
> >  1 file changed, 125 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,rpm-proc.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,rpm-proc.yaml
> > new file mode 100644
> > index 000000000000..c06dd4f66503
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/remoteproc/qcom,rpm-proc.yaml
> > @@ -0,0 +1,125 @@
> > [...]
> > +  interrupt-controller:
> > +    type: object
> > +    $ref: /schemas/interrupt-controller/qcom,mpm.yaml#
> > +    description:
> > +      MSM Power Manager (MPM) interrupt controller that monitors interrupts
> > +      when the system is asleep.
> 
> Isn't this a service of RPM?
> 
> > +
> > +  master-stats:
> > +    $ref: /schemas/soc/qcom/qcom,rpm-master-stats.yaml#
> > +    description:
> > +      Subsystem-level low-power mode statistics provided by RPM.
> 
> The same question.
> 

Yes, they are services of the RPM firmware. But they have no relation to
the SMD/GLINK channel.

To clarify this I extend my picture from above with MPM:

                 +----------------------------------+                                    
                 |          ARM Cortex-M3           |                                    
                 | +------------------------------+ |  +--------------------------------+
                 | |  RPM Firmware                | |  |          Message RAM           |
 IPC Interrupt 0 | | +----------------------+     | |  | +----------------------------+ |
 ------------------->| SMD Server           |     | |  | | SMD Data Structures & FIFO | |
                 | | | +--------------+     |     | |  | | +--------------+           | |
                 | | | | rpm_requests | ... |     | |  | | | rpm_requests |    ...    | |
                 | | | +--------------+     | ... | |  | | +--------------+           | |
                 | | +----------------------+     | |  | +----------------------------+ |
 IPC Interrupt 1 | | +----------------------+     | |  | +----------------------------+ |
 ------------------->| MPM virtualization   |<-----------| MPM register copy (vMPM)   | |
                 | | +----------------------+     | |  | +----------------------------+ |
                 | +-----------|------------------+ |  |              ...               |
                 +-------------v--------------------+  +--------------------------------+
                       +--------------+                                                  
                       | MPM Hardware |                                                  
                       +--------------+                                                  

As you can see, SMD and MPM are siblings. The MPM functionality
implemented by the RPM firmware is not a child of the SMD server.

It's a bit like a webserver and emailserver running on the same PC.
Two separate services accessible via different ports and protocols.

Thanks,
Stephan

NOTE: All of this is just my interpretation based on the public hints
that exist. I have no access to internal documentation or source code
that would prove that all of this is correct.



[Index of Archives]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux