[RESEND v2 1/6] dt-bindings: power: Add JH7110 AON PMU support
Changhuang Liang
changhuang.liang at starfivetech.com
Tue Apr 25 05:26:35 PDT 2023
On 2023/4/25 17:35, Conor Dooley wrote:
> On Tue, Apr 25, 2023 at 05:18:10PM +0800, Changhuang Liang wrote:
>>
>>
>> On 2023/4/25 16:19, Krzysztof Kozlowski wrote:
>>> On 25/04/2023 09:57, Changhuang Liang wrote:
>>>>>>>>>>
>>>>>>>>>> description: |
>>>>>>>>>> StarFive JH7110 SoC includes support for multiple power domains which can be
>>>>>>>>>> @@ -17,6 +18,7 @@ properties:
>>>>>>>>>> compatible:
>>>>>>>>>> enum:
>>>>>>>>>> - starfive,jh7110-pmu
>>>>>>>>>> + - starfive,jh7110-aon-pmu
>>>>>>>
>>>>>>> I was speaking to Rob about this over the weekend, he asked:
>>>>>>> 'Why isn't "starfive,jh7110-aon-syscon" just the power-domain provider
>>>>>>> itself?'
>>>>>>
>>>>>> Maybe not, this syscon only offset "0x00" configure power switch.
>>>>>> other offset configure other functions, maybe not power, so this
>>>>>> "starfive,jh7110-aon-syscon" not the power-domain itself.
>>>>>>
>>>>>>> Do we actually need to add a new binding for this at all?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Conor.
>>>>>>>
>>>>>>
>>>>>> Maybe this patch do that.
>>>>>> https://lore.kernel.org/all/20230414024157.53203-6-xingyu.wu@starfivetech.com/
>>>>>
>>>>> This makes it a child-node right? I think Rob already said no to that in
>>>>> and earlier revision of this series. What he meant the other day was
>>>>> making the syscon itself a power domain controller, since the child node
>>>>> has no meaningful properties (reg, interrupts etc).
>>>>>
>>>>> Cheers,
>>>>> Conor.
>>>>
>>>> Yes, "starfive,jh7110-aon-pmu" is a child-node of "starfive,jh7110-aon-syscon".
>>>> In my opinion, "0x17010000" is "aon-syscon" on JH7110 SoC, and this "aon-pmu" is just
>>>> a part of "aon-syscon" function, so I think it is inappropriate to make "aon-syscon"
>>>> to a power domain controller. I think using the child-node description is closer to
>>>> JH7110 SoC.
>>>
>>> Unfortunately, I do not see the correlation between these, any
>>> connection. Why being a child of syscon block would mean that this
>>> should no be power domain controller? Really, why? These are two
>>> unrelated things.
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>
>> Let me summarize what has been discussed above.
>>
>> There has two ways to describe this "starfive,jh7110-aon-syscon"(0x17010000).
>> 1. (0x17010000) is power-controller node:
>>
>> aon_pwrc: power-controller at 17010000 {
>> compatible = "starfive,jh7110-aon-pmu", "syscon";
>> reg = <0x0 0x17010000 0x0 0x1000>;
>> #power-domain-cells = <1>;
>> };
>>
>>
>> 2. (0x17010000) is syscon node, power-controller is child-node of syscon:
>>
>> aon_syscon: syscon at 17010000 {
>> compatible = "starfive,jh7110-aon-syscon", "syscon", "simple-mfd";
>> reg = <0x0 0x17010000 0x0 0x1000>;
>>
>> aon_pwrc: power-controller {
>> compatible = "starfive,jh7110-aon-pmu";
>> #power-domain-cells = <1>;
>> };
>> };
>
> I thought that Rob was suggesting something like this:
> aon_syscon: syscon at 17010000 {
> compatible = "starfive,jh7110-aon-syscon", ...
> reg = <0x0 0x17010000 0x0 0x1000>;
> #power-domain-cells = <1>;
> };
>
> Cheers,
> Conor.
>
I see the kernel:
https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/mediatek/mt8167.dtsi
this file line 42:
it's power-controller also has no meaningful properties.
What do you think?
More information about the linux-riscv
mailing list