Message ID | 20230923150045.1068556-1-bryan.odonoghue@linaro.org |
---|---|
Headers | show |
Series | Add sc8280xp CAMCC bindings and driver | expand |
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@linaro.org> > > 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@linaro.org> Date: Tue Dec 27 15:40:56 2022 +0100 media: dt-bindings: qcom,venus: split common properties --- bod
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@linaro.org> >> >> 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@linaro.org> > 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