IPQ5332 multipd: missing text PD level and qcom,rproc ownership

[Aaradhana Sahu]

On 9/3/2026 6:12 PM, Hideo Sumi wrote:
> On 9/3/2026, Aaradhana Sahu wrote:
>> Before we look into the SMEM handling, could you please confirm whether
>> you are using the latest ath.git ToT and whether the remoteproc v14
>> series is included?
> 
> No on both counts, and thank you for the pointer -- I had not seen v14.
> Let me be precise about the base so we compare like for like, and then
> ask you the one question that would settle most of this.
> 
> This is an OpenWrt build, not ath.git ToT:
> 
>   - kernel 6.18.44
>   - ath12k from the OpenWrt "backports-6.18.39" package
>   - the multipd remoteproc support is the *old* series: Manikanta
>     Mylavarapu's original multipd patches (Nov 2023) plus Ziyang Huang's
>     "split q6_wcss to rootpd and userpd" fixes (Sep 2024), carried as
>     OpenWrt target patches.
> 
> It does not include your v14 series. So it is very possible the issues I
> raised are already addressed there, and I do not want to send you
> chasing a three-year-old base.
> 
> The core of my first mail was a *text PD* level between the root PD and
> the user PDs, which the vendor firmware for this part requires and which
> the 2023/2024 series does not model, so I added it locally:
> 
>   q6v5_wcss   qcom,ipq5332-q6-mpd         q6_fw0.mdt   root PD
>     text-pd   qcom,ipq5332-mpd-upd-text   q6_fw3.mdt   shared RO text
>       pd1                                 q6_fw1.mdt   user PD
>       pd2                                 q6_fw2.mdt   user PD
> 
> So the question that would settle it: does the v14 series introduce this
> text-PD level (a shared read-only text image loaded between root and
> user PDs)? If it does, my local patch is redundant and the right move is
> simply to use v14 -- no need to debug the old base at all. You wrote the
> series, so you can answer that far faster than I can by porting it.
> 
> I am glad to help validate v14 on this hardware if that is useful -- if
> you can point me at the base it is meant to apply on (ath.git ToT plus
> the series, or a branch), I will build it for IPQ5332 and report what
> reproduces. I would just rather not promise a blind full rebase, since
> 2.4 GHz already works here on the old base and I do not want to trade a
> working setup for guesswork. The OpenWrt device support proceeds on the
> current base regardless; the upstream question is only about landing on
> your track correctly.
> 
> The details you asked for, in any case:
> 
> Firmware version, from the Q6 error record:
> 
>   WLAN.WBE.1.3.2-00067-QCAHKSWPL_SILICONZ-1.128291.1.135427.1
> 
> Platform: Qualcomm IPQ5332 (Xiaomi BE3600 Pro). Two on-chip WiFi
> devices, two user PDs, both attached to the single Q6 root PD via the
> shared text PD:
> 
>   - wifi0 / pd1: on-chip QCA5332, 2.4 GHz, AHB
>   - wifi1 / pd2: QCN6432, 5 GHz
> 
> The multipd DT (our downstream form on the old base):
> 
>   &q6v5_wcss {
>       firmware-name = "ath12k/IPQ5332/hw1.0/q6_fw0.mdt",
>                       "ath12k/IPQ5332/hw1.0/iu_fw.mdt",
>                       "ath12k/QCN6432/hw1.0/iu_fw.mdt";
>       status = "okay";
> 
>       text-pd3 {
>           compatible = "qcom,ipq5332-mpd-upd-text";
>           firmware-name = "ath12k/IPQ5332/hw1.0/q6_fw3.mdt";
> 
>           pd1 {  /* wifi0, 2.4 GHz */
>               firmware-name = "ath12k/IPQ5332/hw1.0/q6_fw1.mdt";
>               interrupts-extended =
>                   <&wcss_smp2p_in 8 IRQ_TYPE_NONE>,
>                   <&wcss_smp2p_in 9 IRQ_TYPE_NONE>,
>                   <&wcss_smp2p_in 12 IRQ_TYPE_NONE>,
>                   <&wcss_smp2p_in 11 IRQ_TYPE_NONE>;
>               interrupt-names = "fatal", "ready",
>                                 "spawn-ack", "stop-ack";
>               qcom,smem-states = <&wcss_smp2p_out 8>,
>                                  <&wcss_smp2p_out 9>,
>                                  <&wcss_smp2p_out 10>;
>               qcom,smem-state-names = "shutdown", "stop", "spawn";
>           };
> 
>           pd2 {  /* wifi1, 5 GHz */
>               firmware-name = "ath12k/IPQ5332/hw1.0/q6_fw2.mdt";
>               interrupts-extended =
>                   <&wcss_smp2p_in 16 IRQ_TYPE_NONE>,
>                   <&wcss_smp2p_in 17 IRQ_TYPE_NONE>,
>                   <&wcss_smp2p_in 20 IRQ_TYPE_NONE>,
>                   <&wcss_smp2p_in 19 IRQ_TYPE_NONE>;
>               interrupt-names = "fatal", "ready",
>                                 "spawn-ack", "stop-ack";
>               qcom,smem-states = <&wcss_smp2p_out 16>,
>                                  <&wcss_smp2p_out 17>,
>                                  <&wcss_smp2p_out 18>;
>               qcom,smem-state-names = "shutdown", "stop", "spawn";
>           };
>       };
>   };
> 
>   &wifi0 { qcom,rproc = <&wcss_upd1>; status = "okay"; };  /* pd1 */
>   &wifi1 { qcom,rproc = <&wcss_upd2>; status = "okay"; };  /* pd2 */
> 
> Thanks,
> Hideo

Thanks for providing the details. This helps clarify the setup.

I checked the backports-6.18.39 code you are using. With that version of the Multi-PD implementation,
the root PD and the Text PD handling is done by the remoteproc side, so for the issues related to the
Text PD, I think it would be better to confirm the expected behavior with the remoteproc team.

Regarding the latest ath.git ToT + remoteproc v14 series, please note that the firmware you are currently using:
WLAN.WBE.1.3.2-00067-QCAHKSWPL_SILICONZ-1.128291.1.135427.1

may not be directly compatible with the latest upstream flow. The WCSS secure PIL flow expects the Q6 DTB
rather than the bootargs-based flow.

I am also not yet sure whether the v14 remoteproc series contains all the changes required for the complete
Multi-PD bringup on IPQ5332.

I have added Vignesh from the remoteproc team to help clarify the Text PD handling, and also whether v14 is
sufficient for the IPQ5332 Multi-PD setup.