On 23/10/2025 06:07, Jingyi Wang wrote: > > > On 10/9/2025 6:29 PM, Krzysztof Kozlowski wrote: >> On 29/09/2025 19:03, Dmitry Baryshkov wrote: >>> On Mon, Sep 29, 2025 at 05:41:10PM +0800, Jingyi Wang wrote: >>>> >>>> >>>> On 9/29/2025 5:34 PM, Dmitry Baryshkov wrote: >>>>> On Mon, Sep 29, 2025 at 02:20:54PM +0800, Jingyi Wang wrote: >>>>>> >>>>>> >>>>>> On 9/25/2025 9:48 AM, Krzysztof Kozłowski wrote: >>>>>>> On Thu, 25 Sept 2025 at 08:37, Jingyi Wang >>>>>>> <[email protected]> wrote: >>>>>>>> >>>>>>>> Add remote processor PAS loader for Kaanapali CDSP processor, >>>>>>>> compatible >>>>>>>> with earlier SM8550 with minor difference: one more sixth >>>>>>>> "shutdown-ack" >>>>>>>> interrupt. >>>>>>>> >>>>>>>> Signed-off-by: Jingyi Wang <[email protected]> >>>>>>>> --- >>>>>>>> .../bindings/remoteproc/qcom,sm8550-pas.yaml | 19 >>>>>>>> +++++++++++++++++++ >>>>>>>> 1 file changed, 19 insertions(+) >>>>>>>> >>>>>>>> diff --git >>>>>>>> a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml >>>>>>>> b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml >>>>>>>> index be9e2a0bc060..031fdf36a66c 100644 >>>>>>>> --- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml >>>>>>>> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml >>>>>>>> @@ -35,6 +35,9 @@ properties: >>>>>>>> - items: >>>>>>>> - const: qcom,sm8750-cdsp-pas >>>>>>>> - const: qcom,sm8650-cdsp-pas >>>>>>>> + - items: >>>>>>>> + - const: qcom,kaanapali-cdsp-pas >>>>>>>> + - const: qcom,sm8550-cdsp-pas >>>>>>> >>>>>>> >>>>>>> This time maybe without HTML: >>>>>>> >>>>>>> This looks wrong. This is not compatible with SM8550. >>>>>> >>>>>> Could you point out what is the difference from your perspecetive? >>>>>> it is the same as SM8550 except for there is one more interrupt, >>>>>> which is also described in this patch. >>>>> >>>>> I'd second Krzysztof here. Your description points out that it is _not_ >>>>> compatible to SM8550. >>>>> >>>> >>>> Here is the binding for sm8750 cdsp. Fallback to sm8650 but describe the >>>> difference in interrupt: >>>> https://lore.kernel.org/all/[email protected]/ >>> >>> Interesting. Let's wait for Krzysztof's response then. >>> >> >> >> Because it is evolution of sm8750, so it did not go back to old design. >> from three generations ago. This is compatible with sm8750 or with sm8650. >> >> >> Best regards, >> Krzysztof > > 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
