Re: [RESEND v2 1/6] dt-bindings: power: Add JH7110 AON PMU support

[Changhuang Liang <changhuang.liang@starfivetech.com>]

On 2023/5/4 14:13, Krzysztof Kozlowski wrote:
> On 04/05/2023 03:34, Changhuang Liang wrote:
>>
>>
>> On 2023/4/26 0:56, Conor Dooley wrote:
>>> On Tue, Apr 25, 2023 at 08:26:35PM +0800, Changhuang Liang wrote:
>>>> 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:
>>>>>>>> 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.
>>>>>>
>>>>>> 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@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@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@17010000 {
>>>>> 		compatible = "starfive,jh7110-aon-syscon", ...
>>>>> 		reg = <0x0 0x17010000 0x0 0x1000>;
>>>>> 		#power-domain-cells = <1>;
>>>>> 	};
>>>
>>>> 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?
>>>
>>> I'm not sure that I follow. It has a bunch of child-nodes does it not,
>>> each of which is a domain?
>>>
>>> I didn't see such domains in your dts patch, they're defined directly in
>>> the driver instead AFAIU. Assuming I have understood that correctly,
>>> your situation is different to that mediatek one?
>>>
>>> Cheers,
>>> Conor.
>>
>> Conor and Rob, 
>>
>> How about this way:
>>
>> aon_syscon: syscon@17010000 {
>> 	compatible = "starfive,jh7110-aon-syscon", "syscon", "simple-mfd";
>> 	reg = <0x0 0x17010000 0x0 0x1000>;
>> 	
>> 	aon_pwrc: power-controller {
>> 		compatible = "starfive,jh7110-aon-pmu";
>> 		regmap = <&aon_syscon>;
>> 		#power-domain-cells = <1>;
>> 	};
>> };
>>
>> Add a "regmap" property which is phandle. And it can keep the present child-node
>> structure. This is more consistent with our soc design.
> 
> Adding property from child to parent does not make any sense. Didn't you
> already receive comment on this?
> 
> Best regards,
> Krzysztof
> 

Krzysztof,

I am confused about what to do next. How to add this power-controller's
node in device tree?

Best regards,
Changhuang


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv