mbox series

[V3,00/11] Add multipd remoteproc support

Message ID 20230718120501.3205661-1-quic_mmanikan@quicinc.com (mailing list archive)
Headers show
Series Add multipd remoteproc support | expand

Message

Manikanta Mylavarapu July 18, 2023, 12:04 p.m. UTC
APSS brings Q6 out of reset and then Q6 brings
WCSS block (wifi radio's) out of reset.

				   ---------------
			      -->  |WiFi 2G radio|
			      |	   --------------
			      |
--------	-------	      |
| APSS | --->   |QDSP6|  -----|
---------	-------       |
                              |
      			      |
			      |   --------------
			      --> |WiFi 5G radio|
				  --------------

Problem here is if any radio crashes, subsequently other
radio also should crash because Q6 crashed. Let's say
2G radio crashed, Q6 should pass this info to APSS. Only
Q6 processor interrupts registered with APSS. Obviously
Q6 should crash and raise fatal interrupt to APSS. Due
to this 5G radio also crashed. But no issue in 5G radio,
because of 2G radio crash 5G radio also impacted.

In multi pd model, this problem is resolved. Here WCSS
functionality (WiFi radio's) moved out from Q6 root pd
to a separate user pd. Due to this, radio's independently
pass their status info to APPS with out crashing Q6. So
other radio's won't be impacted.

Pd means protection domain. It's similar to process in Linux.
Here QDSP6 processor runs each wifi radio functionality on a
separate process. One process can't access other process
resources, so this is termed as PD i.e protection domain.

 APPS				QDSP6
-------                      -------------
|     |	 Crash notification  |		|	----------
|     |<---------------------|----------|-------|WiFi    |
|     |			     |		|    |->|2G radio|
|     |			     |	-------	|    | 	----------
|     |	     		     |	|     |	|    |
|Root |	 Start/stop  Q6	     |	|  R  | |    |
|PD   |<---------------------|->|     | |    |
|rproc|  Crash notification  |	|  O  | |    |
|     |			     |	|     |	|    |
|User |Start/stop UserPD1(2G)|  |  O  | |    |
|PD1  |----------------------|->|     |-|----|
|rproc|			     |	|  T  |	|    |
|     |			     |	|     | |    |
|User |Start/stop UserPD2(5G)|	|  P  | |    |
|PD2  |----------------------|->|     |-|----|
|rproc|			     |	|  D  |	|    |
|     |			     |	-------	|    |	-----------
|     |	Crash notification   |		|    |->|WiFi	  |
|     |<---------------------|----------|-------|5G radio |
-------			     |		|	-----------
                             ------------
According to linux terminology, here consider Q6 as root
i.e it provide all services, WCSS (wifi radio's) as user
i.e it uses services provided by root.

Since Q6 root & WCSS user pd's able to communicate with
APSS individually, multipd remoteproc driver registers
each PD with rproc framework. Here clients (Wifi host drivers)
intrested on WCSS PD rproc, so multipd driver start's root
pd in the context of WCSS user pd rproc start. Similarly
on down path, root pd will be stopped after wcss user pd
stopped.

Here WCSS(user) PD is dependent on Q6(root) PD, so first
q6 pd should be up before wcss pd. After wcss pd goes down,
q6 pd should be turned off.

rproc->ops->start(userpd_rproc) {
	/* Boot root pd rproc */
	rproc_boot(upd_dev->parent);
	---
	/* user pd rproc start sequence */
	---
	---
}
With this way we ensure that root pd brought up before userpd.

rproc->ops->stop(userpd_rproc) {
	---
	---
	/* user pd rproc stop sequence */
	---
	---
	/* Shutdown root pd rproc */
	rproc_shutdown(upd_dev->parent);
}
After userpd rproc stops, root pd rproc will be stopped.
IPQ5332, IPQ9574 supports multipd remoteproc driver.

[V3]:
	- Fixed all comments and rebased for TOT.
	- IPQ5018 support is dropped because it's base port
	  patches not yet merged. Dropped below patches.
	  https://lore.kernel.org/linux-arm-msm/20230521222852.5740-4-quic_mmanikan@quicinc.com/
	  https://lore.kernel.org/linux-arm-msm/20230521222852.5740-5-quic_mmanikan@quicinc.com/
	  https://lore.kernel.org/linux-arm-msm/20230521222852.5740-7-quic_mmanikan@quicinc.com/
	  https://lore.kernel.org/linux-arm-msm/20230521222852.5740-9-quic_mmanikan@quicinc.com/
	  https://lore.kernel.org/linux-arm-msm/20230521222852.5740-12-quic_mmanikan@quicinc.com/
	  https://lore.kernel.org/linux-arm-msm/20230521222852.5740-13-quic_mmanikan@quicinc.com/
	- IPQ5332 support is added with below patches.
	  [03/11], [05/11], [06/11], [07/11], [10/11].
[V2]:
	- Fixed all comments and rebased for TOT.
	- since clocks handled by QDSP6 firmware
 	  Added [04/13], [05/13], [06/13], [07/13] patches.

Manikanta Mylavarapu (11):
  dt-bindings: remoteproc: qcom: Add support for multipd model
  dt-bindings: clock: qcom: gcc-ipq9574: remove q6 bring up clock macros
  dt-bindings: clock: qcom: gcc-ipq5332: remove q6 bring up clock macros
  clk: qcom: ipq9574: remove q6 bring up clocks
  clk: qcom: ipq5332: remove q6 bring up clocks
  firmware: qcom_scm: ipq5332: add support to pass metadata size
  firmware: qcom_scm: ipq5332: add msa lock/unlock support
  remoteproc: qcom: q6v5: Add multipd interrupts support
  remoteproc: qcom: Add Hexagon based multipd rproc driver
  arm64: dts: qcom: ipq5332: Add nodes to bringup multipd
  arm64: dts: qcom: ipq9574: Add nodes to bring up multipd

 .../bindings/remoteproc/qcom,multipd-pil.yaml | 189 ++++
 arch/arm64/boot/dts/qcom/ipq5332-rdp441.dts   |  21 +
 arch/arm64/boot/dts/qcom/ipq5332.dtsi         |  60 ++
 arch/arm64/boot/dts/qcom/ipq9574.dtsi         |  59 ++
 drivers/clk/qcom/gcc-ipq5332.c                | 380 --------
 drivers/clk/qcom/gcc-ipq9574.c                | 326 -------
 drivers/firmware/qcom_scm.c                   |  86 ++
 drivers/firmware/qcom_scm.h                   |   3 +
 drivers/remoteproc/Kconfig                    |  19 +
 drivers/remoteproc/Makefile                   |   1 +
 drivers/remoteproc/qcom_q6v5.c                |  37 +-
 drivers/remoteproc/qcom_q6v5.h                |  11 +
 drivers/remoteproc/qcom_q6v5_mpd.c            | 851 ++++++++++++++++++
 include/dt-bindings/clock/qcom,ipq5332-gcc.h  |  20 -
 include/dt-bindings/clock/qcom,ipq9574-gcc.h  |  18 -
 include/linux/firmware/qcom/qcom_scm.h        |   2 +
 16 files changed, 1336 insertions(+), 747 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,multipd-pil.yaml
 create mode 100644 drivers/remoteproc/qcom_q6v5_mpd.c

Comments

Krzysztof Kozlowski July 19, 2023, 7:01 a.m. UTC | #1
On 18/07/2023 14:04, Manikanta Mylavarapu wrote:
> APSS brings Q6 out of reset and then Q6 brings
> WCSS block (wifi radio's) out of reset.
> 
> 				   ---------------
> 			      -->  |WiFi 2G radio|
> 			      |	   --------------
> 			      |
> --------	-------	      |
> | APSS | --->   |QDSP6|  -----|
> ---------	-------       |
>                               |
>       			      |
> 			      |   --------------
> 			      --> |WiFi 5G radio|
> 				  --------------
> 
> Problem here is if any radio crashes, subsequently other
> radio also should crash because Q6 crashed. Let's say
> 2G radio crashed, Q6 should pass this info to APSS. Only
> Q6 processor interrupts registered with APSS. Obviously
> Q6 should crash and raise fatal interrupt to APSS. Due
> to this 5G radio also crashed. But no issue in 5G radio,
> because of 2G radio crash 5G radio also impacted.

Your patches and cover letter is unnecessarily more difficult to parse
and filter:
1. Please use standard email subjects, so with the PATCH keyword in the
title. `git format-patch` helps here to create proper versioned patches.
Another useful tool is b4. Skipping the PATCH keyword makes filtering of
emails more difficult thus making the review process less convenient.

2. Please wrap message according to Linux coding style / submission
process (neither too early nor over the limit):
https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
This is wrapped way too early.
> 

Best regards,
Krzysztof
Manikanta Mylavarapu July 19, 2023, 7:09 a.m. UTC | #2
On 7/19/2023 12:31 PM, Krzysztof Kozlowski wrote:
> On 18/07/2023 14:04, Manikanta Mylavarapu wrote:
>> APSS brings Q6 out of reset and then Q6 brings
>> WCSS block (wifi radio's) out of reset.
>>
>> 				   ---------------
>> 			      -->  |WiFi 2G radio|
>> 			      |	   --------------
>> 			      |
>> --------	-------	      |
>> | APSS | --->   |QDSP6|  -----|
>> ---------	-------       |
>>                                |
>>        			      |
>> 			      |   --------------
>> 			      --> |WiFi 5G radio|
>> 				  --------------
>>
>> Problem here is if any radio crashes, subsequently other
>> radio also should crash because Q6 crashed. Let's say
>> 2G radio crashed, Q6 should pass this info to APSS. Only
>> Q6 processor interrupts registered with APSS. Obviously
>> Q6 should crash and raise fatal interrupt to APSS. Due
>> to this 5G radio also crashed. But no issue in 5G radio,
>> because of 2G radio crash 5G radio also impacted.
> 
> Your patches and cover letter is unnecessarily more difficult to parse
> and filter:
> 1. Please use standard email subjects, so with the PATCH keyword in the
> title. `git format-patch` helps here to create proper versioned patches.
> Another useful tool is b4. Skipping the PATCH keyword makes filtering of
> emails more difficult thus making the review process less convenient.
> 
I am wondering how i missed 'PATCH' keyword. Sorry for inconvenience.
I won't repeat next time.

> 2. Please wrap message according to Linux coding style / submission
> process (neither too early nor over the limit):
> https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
> This is wrapped way too early.

I will rework on cover page description and update it according
to standards.

Thanks & Regards,
Manikanta.

>>
> 
> Best regards,
> Krzysztof
>