On 1/7/2026 6:56 PM, Konrad Dybcio wrote:
> On 1/5/26 5:09 PM, [email protected] 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 <[email protected]>
>>>>>> ---
>>>>>
>>>>> [...]
>>>>>
>>>>>> @@ -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/[email protected]/T/#t
>
> Konrad
