| Message ID | 20230419035646.43702-2-changhuang.liang@starfivetech.com |
|---|---|
| State | New |
| Headers | show |
| Series | [RESEND,v2,1/6] dt-bindings: power: Add JH7110 AON PMU support | expand |
Hey Changhuang, On Thu, Apr 20, 2023 at 03:00:10PM +0800, Changhuang Liang wrote: > On 2023/4/20 2:29, Conor Dooley wrote: > > On Tue, Apr 18, 2023 at 08:56:41PM -0700, Changhuang Liang wrote: > >> Add AON PMU for StarFive JH7110 SoC, it can be used to turn on/off DPHY > >> rx/tx power switch, and it don't need the properties of reg and > >> interrupts. > > > > Putting this here since the DT guys are more likely to see it this way.. > > Given how the implementation of the code driving this new > > power-controller and the code driving the existing one are rather > > different (you've basically re-written the entire driver in this series), > > should the dphy driver implement its own power-controller? > > > > I know originally Changuang had tried something along those lines: > > https://lore.kernel.org/linux-riscv/5dc4ddc2-9d15-ebb2-38bc-8a544ca67e0d@starfivetech.com/ > > > > I see that that was shut down pretty much, partly due to the > > non-standard property, hence this series adding the dphy power domain to > > the existing driver. > > > > If it was done by looking up the pmu with a > > of_find_compatible_node(NULL, "power-controller", "starfive,jh7110-aon-pmu") > > type thing, would that make sense? Although, maybe that is not a > > question for you, and this series may actually have been better entirely > > bundled with the dphy series so the whole thing can be reviewed as a > > unit. I've added > > > > IOW, don't change this patch, or the dts patch, but move all of the > > code back into the phy driver.. > > > > Maybe this way can not do that? power domain is binding before driver probe, > if I use "of_find_compatible_node" it phy(DPHY rx) probe. Maybe I can only operate > this power switch in my phy(DPHY rx) driver, so the all patch of this series isn't > make sense. I'm a wee bit lost here, as I unfortunately know little about how Linux handles this power-domain stuff. If the DPHY tries to probe and some pre-requisite does not yet exist, you can return -EPROBE_DEFER right? But I don't think that's what you are asking, as using of_find_compatible_node() doesn't depend on there being a driver AFAIU. > In my opinion, We will also submit DPHY TX module later which use this series. > Maybe this series should independent? Is the DPHY tx module a different driver to the rx one? If yes, does it have a different bit you must set in the syscon? +CC Walker, do you have a register map for the jh7110? My TRM only says what the registers are, but not the bits in them. Would make life easier if I had that info. I'm fine with taking this code, I just want to make sure that the soc driver doing this is the right thing to do. I was kinda hoping that combining with the DPHY-rx series might allow the PHY folk to spot if you are doing something here with the power domains that doesn't make sense. > > Sorry for not asking this sooner Changhuang, > > Conor. > > > > (hopefully this didn't get sent twice, mutt complained of a bad email > > addr during sending the first time) > > > > I'm sorry for that, I will notice later. No, this was my mail client doing things that I was unsure of. You didn't do anything wrong. > >> Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com> > >> --- > >> .../bindings/power/starfive,jh7110-pmu.yaml | 15 +++++++++++++-- > >> include/dt-bindings/power/starfive,jh7110-pmu.h | 3 +++ > >> 2 files changed, 16 insertions(+), 2 deletions(-) > >> > >> diff --git a/Documentation/devicetree/bindings/power/starfive,jh7110-pmu.yaml b/Documentation/devicetree/bindings/power/starfive,jh7110-pmu.yaml > >> index 98eb8b4110e7..c50507c38e14 100644 > >> --- a/Documentation/devicetree/bindings/power/starfive,jh7110-pmu.yaml > >> +++ b/Documentation/devicetree/bindings/power/starfive,jh7110-pmu.yaml > >> @@ -8,6 +8,7 @@ title: StarFive JH7110 Power Management Unit > >> > >> maintainers: > >> - Walker Chen <walker.chen@starfivetech.com> > >> + - Changhuang Liang <changhuang.liang@starfivetech.com> > >> > >> 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?' Do we actually need to add a new binding for this at all? Cheers, Conor. > >> > >> reg: > >> maxItems: 1 > >> @@ -29,10 +31,19 @@ properties: > >> > >> required: > >> - compatible > >> - - reg > >> - - interrupts > >> - "#power-domain-cells" > >> > >> +allOf: > >> + - if: > >> + properties: > >> + compatible: > >> + contains: > >> + const: starfive,jh7110-pmu > >> + then: > >> + required: > >> + - reg > >> + - interrupts > >> + > >> additionalProperties: false > >> > >> examples: > >> diff --git a/include/dt-bindings/power/starfive,jh7110-pmu.h b/include/dt-bindings/power/starfive,jh7110-pmu.h > >> index 132bfe401fc8..0bfd6700c144 100644 > >> --- a/include/dt-bindings/power/starfive,jh7110-pmu.h > >> +++ b/include/dt-bindings/power/starfive,jh7110-pmu.h > >> @@ -14,4 +14,7 @@ > >> #define JH7110_PD_ISP 5 > >> #define JH7110_PD_VENC 6 > >> > >> +#define JH7110_PD_DPHY_TX 0 > >> +#define JH7110_PD_DPHY_RX 1 > >> + > >> #endif > >> -- > >> 2.25.1 > >>
On 2023/4/25 0:52, Conor Dooley wrote: > Hey Changhuang, > > On Thu, Apr 20, 2023 at 03:00:10PM +0800, Changhuang Liang wrote: >> On 2023/4/20 2:29, Conor Dooley wrote: >>> On Tue, Apr 18, 2023 at 08:56:41PM -0700, Changhuang Liang wrote: >>>> Add AON PMU for StarFive JH7110 SoC, it can be used to turn on/off DPHY >>>> rx/tx power switch, and it don't need the properties of reg and >>>> interrupts. >>> >>> Putting this here since the DT guys are more likely to see it this way.. >>> Given how the implementation of the code driving this new >>> power-controller and the code driving the existing one are rather >>> different (you've basically re-written the entire driver in this series), >>> should the dphy driver implement its own power-controller? >>> >>> I know originally Changuang had tried something along those lines: >>> https://lore.kernel.org/linux-riscv/5dc4ddc2-9d15-ebb2-38bc-8a544ca67e0d@starfivetech.com/ >>> >>> I see that that was shut down pretty much, partly due to the >>> non-standard property, hence this series adding the dphy power domain to >>> the existing driver. >>> >>> If it was done by looking up the pmu with a >>> of_find_compatible_node(NULL, "power-controller", "starfive,jh7110-aon-pmu") >>> type thing, would that make sense? Although, maybe that is not a >>> question for you, and this series may actually have been better entirely >>> bundled with the dphy series so the whole thing can be reviewed as a >>> unit. I've added >>> >>> IOW, don't change this patch, or the dts patch, but move all of the >>> code back into the phy driver.. >>> >> >> Maybe this way can not do that? power domain is binding before driver probe, >> if I use "of_find_compatible_node" it phy(DPHY rx) probe. Maybe I can only operate >> this power switch in my phy(DPHY rx) driver, so the all patch of this series isn't >> make sense. > > I'm a wee bit lost here, as I unfortunately know little about how Linux > handles this power-domain stuff. If the DPHY tries to probe and some > pre-requisite does not yet exist, you can return -EPROBE_DEFER right? > > But I don't think that's what you are asking, as using > of_find_compatible_node() doesn't depend on there being a driver AFAIU. > >> In my opinion, We will also submit DPHY TX module later which use this series. >> Maybe this series should independent? > > Is the DPHY tx module a different driver to the rx one?> If yes, does it have a different bit you must set in the syscon? > Yes, DPHY tx module is a different driver to the DPHY rx. And I have do a different bit in PATCH 1: #define JH7110_PD_DPHY_TX 0 #define JH7110_PD_DPHY_RX 1 also in PATCH 5: static const struct jh71xx_domain_info jh7110_aon_power_domains[] = { [JH7110_PD_DPHY_TX] = { .name = "DPHY-TX", .bit = 30, }, [JH7110_PD_DPHY_RX] = { .name = "DPHY-RX", .bit = 31, }, }; > +CC Walker, do you have a register map for the jh7110? My TRM only says > what the registers are, but not the bits in them. Would make life easier > if I had that info. > > I'm fine with taking this code, I just want to make sure that the soc > driver doing this is the right thing to do. > I was kinda hoping that combining with the DPHY-rx series might allow > the PHY folk to spot if you are doing something here with the power > domains that doesn't make sense. > I asked about our soc colleagues. This syscon register, offset 0x00: bit[31] ---> dphy rx power switch bit[30] ---> dphy tx power switch other bits ---> Reserved >>> Sorry for not asking this sooner Changhuang, >>> Conor. >>> >>> (hopefully this didn't get sent twice, mutt complained of a bad email >>> addr during sending the first time) >>> >> >> I'm sorry for that, I will notice later. > > No, this was my mail client doing things that I was unsure of. You > didn't do anything wrong. > [...] >>>> - Walker Chen <walker.chen@starfivetech.com> >>>> + - Changhuang Liang <changhuang.liang@starfivetech.com> >>>> >>>> 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/ >>>> >>>> reg: >>>> maxItems: 1 >>>> @@ -29,10 +31,19 @@ properties: >>>>
>>>>>> >>>>>> 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.
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@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>; }; Cheers, Conor.
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@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>; > }; > > 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?
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.
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. I think there child-nodes just need to operate some clock signals. Maybe we don't need to discuss other platforms. If Rob's method is confirmed. I will try it next version. Maybe like this: aon_syscon: syscon@17010000 { compatible = "starfive,jh7110-aon-syscon", "syscon", "starfive,jh7110-aon-pmu"; reg = <0x0 0x17010000 0x0 0x1000>; #power-domain-cells = <1>; }; Rob and krzystof: And I think patch[1][2] need to change. Right? [1] https://lore.kernel.org/all/20230414024157.53203-6-xingyu.wu@starfivetech.com/ [2] https://lore.kernel.org/all/20230414024157.53203-7-xingyu.wu@starfivetech.com/
diff --git a/Documentation/devicetree/bindings/power/starfive,jh7110-pmu.yaml b/Documentation/devicetree/bindings/power/starfive,jh7110-pmu.yaml index 98eb8b4110e7..c50507c38e14 100644 --- a/Documentation/devicetree/bindings/power/starfive,jh7110-pmu.yaml +++ b/Documentation/devicetree/bindings/power/starfive,jh7110-pmu.yaml @@ -8,6 +8,7 @@ title: StarFive JH7110 Power Management Unit maintainers: - Walker Chen <walker.chen@starfivetech.com> + - Changhuang Liang <changhuang.liang@starfivetech.com> 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 reg: maxItems: 1 @@ -29,10 +31,19 @@ properties: required: - compatible - - reg - - interrupts - "#power-domain-cells" +allOf: + - if: + properties: + compatible: + contains: + const: starfive,jh7110-pmu + then: + required: + - reg + - interrupts + additionalProperties: false examples: diff --git a/include/dt-bindings/power/starfive,jh7110-pmu.h b/include/dt-bindings/power/starfive,jh7110-pmu.h index 132bfe401fc8..0bfd6700c144 100644 --- a/include/dt-bindings/power/starfive,jh7110-pmu.h +++ b/include/dt-bindings/power/starfive,jh7110-pmu.h @@ -14,4 +14,7 @@ #define JH7110_PD_ISP 5 #define JH7110_PD_VENC 6 +#define JH7110_PD_DPHY_TX 0 +#define JH7110_PD_DPHY_RX 1 + #endif
Add AON PMU for StarFive JH7110 SoC, it can be used to turn on/off DPHY rx/tx power switch, and it don't need the properties of reg and interrupts. Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com> --- .../bindings/power/starfive,jh7110-pmu.yaml | 15 +++++++++++++-- include/dt-bindings/power/starfive,jh7110-pmu.h | 3 +++ 2 files changed, 16 insertions(+), 2 deletions(-)