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