Message-ID: <19b2dd07-ed70-4eaa-8395-6a62d52ec862@oss.qualcomm.com>
Date: Mon, 5 Jan 2026 23:27:07 +0530
From: Vignesh Viswanathan <vignesh.viswanathan@....qualcomm.com>
To: mr.nuke.me@...il.com, Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
        andersson@...nel.org, mathieu.poirier@...aro.org,
        linux-kernel@...r.kernel.org
Cc: krzk+dt@...nel.org, Philipp Zabel <p.zabel@...gutronix.de>,
        linux-arm-msm@...r.kernel.org, linux-remoteproc@...r.kernel.org
Subject: Re: [PATCH 6/9] remoteproc: qcom_q6v5_wcss: support IPQ9574



On 1/5/2026 9:39 PM, mr.nuke.me@...il.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@...il.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 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.

Adding my 2 cents here, in some platforms, the regions which you are accessing
as part of the init sequence might be access protected by Trustzone.
This might lead to the kernel bringup failing due to an access violation.

This was the motivation behind me asking if this worked in my previous email.
Using the TZ interface, as suggested by Konrad, should work in any case.

Thanks,
Vignesh

> 
> 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/20231110091939.3025413-1-quic_mmanikan@quicinc.com/
> 
> 

Powered by blists - more mailing lists