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 <[email protected]> > > > --- > > > .../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
