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

[Dmitry Baryshkov]

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
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?

> 
> > be easier to leave it as is for the traditional DSPs and copy necessary
> > functionality into the soccp schema?

-- 
With best wishes
Dmitry