On Mon, Apr 11, 2022 at 01:38:41PM +0200, Krzysztof Kozlowski wrote: > On 11/04/2022 12:58, Kuldeep Singh wrote: > >> This is something new and it seems only one SoC defines it (not even one > >> BAM version). I wonder whether this is actually correct or this > >> particular version of BAM is slightly different. Maybe someone could > >> clarify it, but if no - looks ok. > > > > Yes, sdm845.dtsi uses 4 entries and rest 1. > > Yes, I know. This does not solve my wonder. > > > > >> > >>> + > >>> + num-channels: > >>> + $ref: /schemas/types.yaml#/definitions/uint32 > >>> + description: > >>> + Indicates supported number of DMA channels in a remotely controlled bam. > >>> + > >>> + qcom,controlled-remotely: > >>> + $ref: /schemas/types.yaml#/definitions/flag > >> > >> type: boolean > > > > Boolean comes under flag in types.yaml > > > > definitions: > > flag: > > oneOf: > > - type: boolean > > const: true > > - type: 'null' > > > > I have seen other boolean properties(spi-cpol, spi-cpha and bunch of > > others) using type flag. I think we should keep flag here. > > type:boolean is just shorter and example-schema recommends it. If you > want to base on something (as a template, pattern) then the > example-schema is the source, the preferred one. I had seen other spec using flag and that's why kept same here. Which example schema are you talking about? > >> > >> clocks, clock-names, qcom-ee - these are required according to old bindings. > > > > I missed qcom,ee. Will add in v3. > > > > For clocks and clock-names , there are two platforms(msm8996.dtsi, > > sdm845.dtsi) where these properties are missing. And I don't want to add > > some random values. Shall I skip them here? and let board owners add > > them later. > > These are required, so the SoC DTSI should be fixed. Not with random > clocks but something proper. :) Yes absolutely :-) I have kept Srinivas in copy, who sent initial support for both the dtsi. Probably he can confirm provided his email doesn't bounce. Anyway Krzysztof, can you confirm the same as you have been actively contributing to Qcom peripherals. I will add credit in follow-up submission.
