On 24/09/2023 12:20, Bryan O'Donoghue wrote: > On 23/09/2023 17:13, Krzysztof Kozlowski wrote: >> On 23/09/2023 17:00, Bryan O'Donoghue wrote: >>> Move the various camcc yaml files into one. The Camera Clock Controller >>> is pretty similar from SoC to SoC. >>> >>> Mostly we have some SoCs which require fewer clocks than others. In some >>> cases we have SoCs which have required-opps and required-power-domains. >>> >>> It is likely we could and should extend the thin CAMCC descriptions such >>> as sdm845 an sm6350 to the more robust descriptions such as sm8250 and >>> sm8450. >>> >>> As a result of listing sm8250 and sm8450 together required-opps and >>> power-domains become required for sm8250, which is a NOP for the dtsi >>> since both declarations already exist for sm8250. >>> >>> sm8250 is also chosen as the example for the new combined camcc.yaml. >>> >>> A minor tweak to fix Bjorn's email address in the Maintainer list is >>> included. >>> >>> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@xxxxxxxxxx> >> >> No, that's not the right approach. For GCC and CamCC and all other >> Qualcomm clock controllers, we split into device schemas, not merge into >> one. The one schema is just becoming unreviewable over time with >> multiple if:then clauses. >> >> Please use approach like we have for GCC, RPMh interconnects or remote >> proc loaders - common file. What's more, here you probably don't even >> need common file because it is already there - qcom,gcc.yaml >> >> Best regards, >> Krzysztof >> > > Ah OK, I see what you mean. > > commit f8cc21d454c50157a528c900b60aa9588b4066b3 > Author: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> > Date: Tue Dec 27 15:40:56 2022 +0100 > > media: dt-bindings: qcom,venus: split common properties Yes, except that in case of camcc it might be enough to use existing gcc.yaml Best regards, Krzysztof
