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.. Konrad
