On 12/04/2022 08:19, Kuldeep Singh wrote: > 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. I understand, you mentioned it before. However other spec is not the example-schema... > Which example schema are you talking about? There is only one example-schema. $ find ./linux -name 'example-schema*' >>>> 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. Honestly not now, because I don't have access to related datasheets (I am working on this). You can though try to look at original (vendor) sources: https://git.codelinaro.org/clo/la/kernel/msm-4.19 (sdm845) https://git.codelinaro.org/clo/la/kernel/msm-3.18 (msm8996) Best regards, Krzysztof
