Re: [PATCH v4 4/7] dt-bindings: remoteproc: qcom: Document pas for SoCCP on Kaanapali and Glymur platforms

[Krzysztof Kozlowski]

On 12/03/2026 05:53, Dmitry Baryshkov wrote:
> gn Wed, Mar 11, 2026 at 07:26:38AM +0100, Krzysztof Kozlowski wrote:
>> On Wed, Mar 11, 2026 at 04:04:09AM +0200, Dmitry Baryshkov wrote:
>>> On Tue, Mar 10, 2026 at 03:03:20AM -0700, Jingyi Wang wrote:
>>>> Document the component used to boot SoCCP on Kaanapali SoC and add
>>>> compatible for Glymur SoCCP which could fallback to Kaanapali. Extend
>>>> the "qcom,smem-states", "qcom,smem-state-names" in the pas-common.
>>>>
>>>> Signed-off-by: Jingyi Wang <jingyi.wang@xxxxxxxxxxxxxxxx>
>>>> ---
>>>>  .../remoteproc/qcom,kaanapali-soccp-pas.yaml       | 154 +++++++++++++++++++++
>>>>  .../bindings/remoteproc/qcom,pas-common.yaml       |   6 +-
>>>>  2 files changed, 159 insertions(+), 1 deletion(-)
>>>
>>> With all the changes to pas-common, what is being left in it? Would it
>>
>> You need place for definition of properties - smd/glink-edge and
>> qcom,smem-states. The latter is actually not properly defined in one
>> place, becuse there are bindings having  it but not refencing
>> pas-common.
> 
> So do we for schemas definig smd-edge.
> 
>>
>> It can also define common order of interrupts, but as you pointed out
>> this does not work for this new device anymore.
> 
> Nor does it work for SocCP smem-states. I think that having such a

It only does not work in full constraints, but for defining the type it
works.

> pas-common overcomplicates existing schema. What about splitting
> qcom,dsp-common from qcom,pas-common with the latter keeping properties
> that are common to existing DSP and SoCCP, while the former being used
> only for DSPs?
> 

What would be in the dsp-common then?

Best regards,
Krzysztof