On 12.04.2023 07:42, Rajendra Nayak wrote:
>
> On 4/11/2023 7:15 PM, Konrad Dybcio wrote:
>>
>>
>> On 11.04.2023 15:31, Rajendra Nayak wrote:
>>>
>>> On 4/11/2023 4:57 PM, Konrad Dybcio wrote:
>>>>
>>>>
>>>> On 11.04.2023 06:56, Rajendra Nayak wrote:
>>>>>
>>>>>
>>>>> On 4/8/2023 7:33 PM, Konrad Dybcio wrote:
>>>>>>
>>>>>>
>>>>>> On 8.04.2023 15:48, Krzysztof Kozlowski wrote:
>>>>>>> The GCC clock controller needs CX power domain, at least according to
>>>>>>> DTS:
>>>>>>>
>>>>>>> sc7180-trogdor-pompom-r3.dtb: clock-controller@100000: Unevaluated properties are not allowed ('power-domains' was unexpected)
>>>>>>>
>>>>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>
>>>>>>> ---
>>>>>> +CC Rajendra (author of 5d6fc6321db1 ("arm64: dts: qcom:
>>>>>> sc7180: Add required-opps for USB"))
>>>>>>
>>>>>> Rajendra, shouldn't SC7180 GCC have PM ops to make sure a vote
>>>>>> is only there when AP is active?
>>>> So IIUC, CX is never supposed to be shut down?
>>>
>>> Atleast sc7180 and sc7280 do not support full CX shutdown (or power
>>> collapse as its called), it only transitions to a Retention state
>>> and even that in the system-wide suspend path only
>> And won't outstanding votes on that resource prevent the system
>> from entering a system-wide low power state?
>
> I think most of what you are asking was discussed at https://lore.kernel.org/all/5ff21b1e-3af9-36ef-e13e-fa33f526d0e3@xxxxxxxxxxx/
>
OK so 7[12]80 never actually power off CX fully. Understood.
> Are we seeing something broken on sc7180/sc7280 platforms?
I don't know, I don't have any devices. I'm just asking questions
to make sure things weren't unintentionally broken.
> If there is an outstanding vote on CX it would prevent CX from
> going down, but ideally we should not have an outstanding vote
> from USB (atleast) since we now support RET for the USB GDSC.
> If there is some other GDSC (within GCC) thats left turned ON,
> yes, that would still prevent CX from going down.
Makes sense!
Konrad
>
>>
>> Konrad
>>>
>>>>
>>>> Konrad
>>>>>
>>>>> hmm, I am not quite sure why we would want the performance votes
>>>>> from peripherals dropped when CPUs go down in idle?
>>>>>
>>>>>> Are all GDSCs powered by CX?
>>>>>> If not, wouldn't this also need power-domain-names to
>>>>>> facilitate e.g. potential MX-powered ones?
>>>>>
>>>>> For sc7180 GCC, yes.
>>>>>
>>>>>>
>>>>>> Konrad
>>>>>>> .../devicetree/bindings/clock/qcom,gcc-sc7180.yaml | 7 +++++++
>>>>>>> 1 file changed, 7 insertions(+)
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml
>>>>>>> index 06dce0c6b7d0..8bf9b6f49550 100644
>>>>>>> --- a/Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml
>>>>>>> +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml
>>>>>>> @@ -32,6 +32,10 @@ properties:
>>>>>>> - const: bi_tcxo_ao
>>>>>>> - const: sleep_clk
>>>>>>> + power-domains:
>>>>>>> + items:
>>>>>>> + - description: CX domain
>>>>>>> +
>>>>>>> required:
>>>>>>> - compatible
>>>>>>> - clocks
>>>>>>> @@ -45,6 +49,8 @@ unevaluatedProperties: false
>>>>>>> examples:
>>>>>>> - |
>>>>>>> #include <dt-bindings/clock/qcom,rpmh.h>
>>>>>>> + #include <dt-bindings/power/qcom-rpmpd.h>
>>>>>>> +
>>>>>>> clock-controller@100000 {
>>>>>>> compatible = "qcom,gcc-sc7180";
>>>>>>> reg = <0x00100000 0x1f0000>;
>>>>>>> @@ -52,6 +58,7 @@ examples:
>>>>>>> <&rpmhcc RPMH_CXO_CLK_A>,
>>>>>>> <&sleep_clk>;
>>>>>>> clock-names = "bi_tcxo", "bi_tcxo_ao", "sleep_clk";
>>>>>>> + power-domains = <&rpmhpd SC7180_CX>;
>>>>>>> #clock-cells = <1>;
>>>>>>> #reset-cells = <1>;
>>>>>>> #power-domain-cells = <1>;
