Re: [PATCH 6/9] remoteproc: qcom_q6v5_wcss: support IPQ9574

[Vignesh Viswanathan <vignesh.viswanathan@oss.qualcomm.com>]

On 1/7/2026 6:56 PM, Konrad Dybcio wrote:
> On 1/5/26 5:09 PM, mr.nuke.me@gmail.com wrote:
>>
>>
>> On 12/29/25 6:35 AM, Konrad Dybcio wrote:
>>> On 12/23/25 9:21 PM, Alex G. wrote:
>>>> On Friday, December 19, 2025 7:20:04 AM CST Konrad Dybcio wrote:
>>>>> On 12/19/25 5:34 AM, Alexandru Gagniuc wrote:
>>>>>> Q6 based firmware loading is also present on IPQ9574, when coupled
>>>>>> with a wifi-6 device, such as QCN5024. Populate driver data for
>>>>>> IPQ9574 with values from the downstream 5.4 kerrnel.
>>>>>>
>>>>>> Add the new sequences for the WCSS reset and stop. The downstream
>>>>>> 5.4 kernel calls these "Q6V7", so keep the name. This is still worth
>>>>>> using with the "q6v5" driver because all other parts of the driver
>>>>>> can be seamlessly reused.
>>>>>>
>>>>>> The IPQ9574 uses two sets of clocks. the first, dubbed "q6_clocks"
>>>>>> must be enabled before the Q6 is started by writing the Q6SS_RST_EVB
>>>>>> register. The second set of clocks, "clks" should only be enabled
>>>>>> after the Q6 is placed out of reset. Otherwise, the host CPU core that
>>>>>> tries to start the remoteproc will hang.
>>>>>>
>>>>>> The downstream kernel had a funny comment, "Pray god and wait for
>>>>>> reset to complete", which I decided to keep for entertainment value.
>>>>>>
>>>>>> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
>>>>>> ---
>>>>>
>>>>> [...]
>>>>>
>>>>>> @@ -128,6 +137,12 @@ struct q6v5_wcss {
>>>>>>
>>>>>>       struct clk *qdsp6ss_xo_cbcr;
>>>>>>       struct clk *qdsp6ss_core_gfmux;
>>>>>>       struct clk *lcc_bcr_sleep;
>>>>>>
>>>>>> +    struct clk_bulk_data *clks;
>>>>>> +    /* clocks that must be started before the Q6 is booted */
>>>>>> +    struct clk_bulk_data *q6_clks;
>>>>>
>>>>> "pre_boot_clks" or something along those lines?
>>>>
>>>> I like "pre_boot_clocks".
>>>>
>>>>> In general i'm not super stoked to see another platform where manual and
>>>>> through-TZ bringup of remoteprocs is supposed to be supported in parallel..
>>>>>
>>>>> Are you sure your firmware doesn't allow you to just do a simple
>>>>> qcom_scm_pas_auth_and_reset() like in the multipd series?
>>>>
>>>> I am approaching this from the perspective of an aftermarket OS, like OpenWRT.
>>>> I don't know if the firmware will do the right thing. I can mitigate this for
>>>> OS-loaded firmware, like ath11k 16/m3 firmware, because I can test the driver
>>>> and firmware together. I can't do that for bootloader-loaded firmware, so I try
>>>> to depend on it as little as possible. I hope that native remoterproc loading
>>>> for IPQ9574 will be allowed.
>>>
>>> These are two parallel questions. I didn't even know that the bootloader
>>> preloaded firmware on these platforms (are you sure that's the case?)
>>>
>>> qcom_scm_pas_auth_and_reset() is usually preceded by qcom_mdt_pas_init() +
>>> qcom_mdt_load_no_init() where *you* supply the loadable firmware for the
>>> remote processor.
>>
>> What I mean is that the init sequence is implemented in the trustzone firmware which is loaded at boot time. Irrespective of what Q6 and M3 firmware I supply, if trustzone doesn't cooperate, I can't start the remoteproc. I don't have that problem when the init sequence is implemented in the kernel.
> 
> The TZ will always "cooperate" in the sense that if you supply a valid set of
> loadable firmware files and allocate a chunk of memory, it will power up the
> remote processors. I wouldn't imagine any software release would have ever
> been approved with this not working (given the SCM call is marked available).
> 
> It may also be that you have something else in mind, but I didn't quite catch
> your concern.
> 
>>> The init sequence provided by this interface will be at worst identical to
>>> what you're proposing here (except abstracted out), and at best containing
>>> some fixes and/or workarounds that may be necessary.
>>
>> I think this portrays the TZ path as somehow superior. That's not how things work in my use casee.
> 
> Indeed the sequence baked into the TZ is generally to be considered
> authoritative.
> 
>> The bootloader/FW versions depends on when and who made the device. So while the newest TZ from upstream may have the latest fixes, I have no guarantee that they will be present on a given device at runtime. The best solution I found to get consistent behavior across devices is to do these sequences from the kernel. Is there something incomplete in my init sequence that I can fix?
> 
> Because of the complexity of these systems, it's absolutely not inconceivable
> that a fix/workaround is only necessary/desired when coupled with a specific
> TZ (or other proprietary component, such as RPMh) firmware version (because
> many HW settings are co-dependent).
> 
> I can not answer your last question.
> 
>>  > Please try using PAS and see if that works.
>>
>> I found the v6 of the multipd series [1]. It needed some minor adjustments to compile. I went as far as loading the Q6 firmware and starting the remoteproc without error. I did not test any further.
> 
> Please give it a shot.
> 
> Bjorn, Vignesh, do we see the multipd series going anywhere? It's been
> last posted in 2023..

Hi Konrad,

multipd series was dropped and replaced with WCSS secure PIL driver [1] which is
currently in v9. I see that except the actual driver itself, patch 3/6 in
the above series,  other patches in this series has a R-b tag.

Once this gets reviewed, it should enable secure PIL loading using the TZ interface
for WCSS remoteprocs in IPQ5018/IPQ5332/IPQ9574.

[1] https://lore.kernel.org/linux-remoteproc/20260106105412.3529898-1-varadarajan.narayanan@oss.qualcomm.com/T/#t

> 
> Konrad