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
