On Wednesday, December 24, 2025 3:44:56 AM CST Vignesh Viswanathan wrote: > On 12/24/2025 1:51 AM, 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.
Hi Vignesh, > Does this rproc start sequence work on IPQ9574 without using the > qcom_scm_pas_auth_and_reset ? Yes, it works as presented in this series, without qcom_scm_pas_auth_and_reset(). Alex
