Re: Adreno 829 (SM8845) zap shader: PAS init rejected by TZ under Gunyah

["James Wilson" <james.wilson@posteo.net>]

On Thu Oct 15, 2026 at 6:46 PM IST, Rob Clark wrote:
> + Sumit who would know more about the PAS stuff
>
> BR,
> -R
>
> On Wed, Oct 14, 2026 at 12:42 PM VENKAT YADLAPATI
> <venkat.yadlapati@hotmail.com> wrote:
>>
>> Hi,
>>
>> I am bringing up mainline on a Motorola Signature (SM8845 "alor", a
>> Kaanapali derivative with an Adreno 829 / gen8_9_0, chip id 0x44030a00).
>> It is a retail, secure-boot phone running Gunyah, with the shipped
>> firmware (A171WVH.21-16-16). Display, UFS, USB and the ADSP work.
>>
>> For the GPU I added a gen8_9_0 entry modelled on the A840 one (2 slices,
>> 2432 KiB GMEM, gen80900 firmware). The SQE/GMU/AQE firmware loads and the
>> GMU boots (v5.3.25), but loading the zap shader fails: the PAS init call
>> for PAS id 13 (0x42000201) returns a0 = 0xffcfffbb, i.e. -EINVAL. The zap
>> is the one shipped in the same vendor image (gen80900_zap.mbn).
>>
>> What I checked so far:
>>
>> - qcom_scm_pas_supported(13) returns true, and other PAS images load
>>   fine through the same path: the ADSP (PAS 36 + 1) boots.
>> - Moving the metadata buffer above 4 GiB, loading the zap after the ADSP,
>>   and skipping the CP SMMU aperture call change nothing. Passing an SHM
>>   bridge (tzmem) buffer gives a different error (0xffcffff6), so I assume
>>   the hypervisor bridges the plain buffer itself and 0x...bb comes from TZ.
>> - On the same device, the Android 6.18 GKI kernel with KGSL loads the
>>   zap with the identical sequence: PAS init(13) -> mem_setup(13,
>>   0x9959a000) -> auth_and_reset(13). The only GPU related secure calls
>>   before it are qcom_scm_gpu_init_regs (mask 0xb) and a series of
>>   MP_ASSIGN calls handing KGSL's secure buffers and secure page tables to
>>   VMID_CP_PIXEL. Assigning a page to CP_PIXEL before the zap load on
>>   mainline does not help.
>>
>> Is there a precondition in TZ for the GPU PAS on Gunyah based production
>> devices (for example a secure context bank on the GPU SMMU, or something
>> KGSL does at probe), or is the zap expected to work the same way as on
>> the Kaanapali QRD? Any hint on what 0xffcfffbb means would help too.
>>
>> A second, unrelated question about naming before I post the SoC patches:
>> SM8845 differs from SM8850 enough to need its own TLMM driver (205 GPIOs,
>> different pin functions and GPIO->PDC wakeup map), an extra PDC range, a
>> gpucc variant and its own GPU, so I describe it as a separate SoC on top
>> of kaanapali.dtsi (like purwa on hamoa). For now I used the downstream
>> codename "alor" (pinctrl-alor.c, qcom,alor-tlmm, qcom,alor-pdc,
>> qcom,alor-gpucc, alor.dtsi). Since kaanapali itself is not the
>> downstream name of SM8850, is there an upstream codename planned for
>> SM8845, or should I use "alor" (or plain sm8845)?
>>
>> I plan to post that series soon (TLMM driver and binding, PDC, gpucc
>> variant, SoC dtsi, and the A829 support once the zap issue is sorted
>> out), followed by the Motorola Signature board. If Qualcomm already has
>> SM8845 patches in the queue, please let me know so I don't duplicate the
>> work.

Hello Venkat,

I wanted to let you know, that I'm also working on SM8845 SoC bring up.
I have the SM8845 specific clock, pinctrl, interconnect drivers and much
of the dtsi ready.

No MDSS/DPU or GPU yet though, which you seem to have working.

Best,
James

>>
>> Thanks,
>> Venkat Yadlapati