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 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.
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?
> 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.
Alex
[1]
https://patchwork.kernel.org/project/linux-remoteproc/patch/[email protected]/
