On 24/10/2025 09:42, Jingyi Wang wrote:
>
>
> On 10/24/2025 3:28 PM, Krzysztof Kozlowski wrote:
>> On 24/10/2025 04:10, Jingyi Wang wrote:
>>>>>
>>>>> Hi Krzysztof，
>>>>>
>>>>> I tested with falling back to sm8650 cdsp but it will fail with:
>>>>> [ 4.739615] qcom_q6v5_pas 26300000.remoteproc: unable to resolve
>>>>> shareable memory-region index 0
>>>>>
>>>>> sm8550 and kaanapali define 2 memory regions:
>>>>> "memory-region = <&cdsp_mem>, <&q6_cdsp_dtb_mem>;"
>>>>>
>>>>> sm8650 and sm8750 define 3 memory regions:
>>>>> "memory-region = <&cdsp_mem>, <&q6_cdsp_dtb_mem>, <&global_sync_mem>;"
>>>>> with the driver:
>>>>>
>>>>> static const struct qcom_pas_data sm8650_cdsp_resource = {
>>>>> .crash_reason_smem = 601,
>>>>> .firmware_name = "cdsp.mdt",
>>>>> .dtb_firmware_name = "cdsp_dtb.mdt",
>>>>> <...>
>>>>> .region_assign_idx = 2,
>>>>> .region_assign_count = 1,
>>>>> .region_assign_shared = true,
>>>>> .region_assign_vmid = QCOM_SCM_VMID_CDSP,
>>>>> };
>>>>>
>>>>> When kaanapali fallback to sm8650 it cannot parse this region_assign_idx.
>>>>>
>>>>> So shall we still fallback to sm8550 or define a new node
>>>>> "kaanapali_cdsp_resource"
>>>>> in the driver?
>>>>
>>>> And partially the point here is that you might need the third region, no?
>>>> Best regards,
>>>> Krzysztof
>>>
>>> On kaanapali, the global_sync_mem region is not managed by kernel, so it
>>> should
>>> be removed.
>>
>>
>> OK, then please mention this in the commit msg, so it is clear why this
>> is not compatible with previous generation.
>>
>> Best regards,
>> Krzysztof
>
> Sorry for being a bit verbose, but I would like to make it clear that we can
> still
> use this fallback if we clarify it in the commit message, right?
Yes, you can.
Best regards,
Krzysztof
