mbox series

[0/4] Add sc8280xp CAMCC bindings and driver

Message ID 20230923150045.1068556-1-bryan.odonoghue@linaro.org
Headers show
Series Add sc8280xp CAMCC bindings and driver | expand

Message

Bryan O'Donoghue Sept. 23, 2023, 3 p.m. UTC
This is a bog-standard series to add in the CAMCC for 8280xp.
As a precursor to adding in sc8280xp I thought a bit of tidy up on the
existing yaml for the camcc controllers in general would be worthwhile.

As a result there's a precursor patch which aggregates the various camcc
yaml files into one location.

The sc8280xp looks like sdm845 with more blocks. Similar to sc8280xp we
park GDSC to CXO. Thanks to Dmitry for the suggestion the GDSC parking.

Link: https://git.codelinaro.org/bryan.odonoghue/kernel/-/tree/linux-next-23-09-23-sc8280xp-camcc

Bryan O'Donoghue (4):
  dt-bindings: clock: qcom,camcc.yaml: Convert qcom,camcc to a single
    yaml file
  dt-bindings: clock: qcom,camcc.yaml: Add sc8280xp CAMCC compatible
  clk: qcom: camcc-sc8280xp: Add sc8280xp CAMCC
  arm64: boot: dts: qcom: sc8280xp: Add in CAMCC for sc8280xp

 .../bindings/clock/qcom,camcc-sm8250.yaml     |   84 -
 .../devicetree/bindings/clock/qcom,camcc.yaml |  173 +
 .../bindings/clock/qcom,sc7180-camcc.yaml     |   72 -
 .../bindings/clock/qcom,sc7280-camcc.yaml     |   71 -
 .../bindings/clock/qcom,sdm845-camcc.yaml     |   65 -
 .../bindings/clock/qcom,sm6350-camcc.yaml     |   49 -
 .../bindings/clock/qcom,sm8450-camcc.yaml     |   85 -
 arch/arm64/boot/dts/qcom/sc8280xp.dtsi        |   15 +
 drivers/clk/qcom/Kconfig                      |    9 +
 drivers/clk/qcom/Makefile                     |    1 +
 drivers/clk/qcom/camcc-sc8280xp.c             | 3051 +++++++++++++++++
 .../dt-bindings/clock/qcom,camcc-sc8280xp.h   |  179 +
 12 files changed, 3428 insertions(+), 426 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/clock/qcom,camcc-sm8250.yaml
 create mode 100644 Documentation/devicetree/bindings/clock/qcom,camcc.yaml
 delete mode 100644 Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml
 delete mode 100644 Documentation/devicetree/bindings/clock/qcom,sc7280-camcc.yaml
 delete mode 100644 Documentation/devicetree/bindings/clock/qcom,sdm845-camcc.yaml
 delete mode 100644 Documentation/devicetree/bindings/clock/qcom,sm6350-camcc.yaml
 delete mode 100644 Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml
 create mode 100644 drivers/clk/qcom/camcc-sc8280xp.c
 create mode 100644 include/dt-bindings/clock/qcom,camcc-sc8280xp.h

Comments

Bryan O'Donoghue Sept. 24, 2023, 10:20 a.m. UTC | #1
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
Krzysztof Kozlowski Sept. 24, 2023, 11:45 a.m. UTC | #2
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