| Message ID | 20250226232320.93791-2-inochiama@gmail.com (mailing list archive) |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
| Series | clk: sophgo: add SG2044 clock controller support | expand |
Quoting Inochi Amaoto (2025-02-26 15:23:18) > diff --git a/Documentation/devicetree/bindings/clock/sophgo,sg2044-clk.yaml b/Documentation/devicetree/bindings/clock/sophgo,sg2044-clk.yaml > new file mode 100644 > index 000000000000..d55c5d32e206 > --- /dev/null > +++ b/Documentation/devicetree/bindings/clock/sophgo,sg2044-clk.yaml > @@ -0,0 +1,40 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/clock/sophgo,sg2044-clk.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Sophgo SG2044 Clock Controller > + > +maintainers: > + - Inochi Amaoto <inochiama@gmail.com> No description? > + > +properties: > + compatible: > + const: sophgo,sg2044-clk > + > + reg: > + maxItems: 1 > + > + clocks: > + maxItems: 1 > + > + '#clock-cells': > + const: 1 > + > +required: > + - compatible > + - reg > + - clocks > + - '#clock-cells' > + > +additionalProperties: false > + > +examples: > + - | > + clock-controller@50002000 { > + compatible = "sophgo,sg2044-clk"; > + reg = <0x50002000 0x1000>; > + #clock-cells = <1>; > + clocks = <&osc>; I think you want the syscon phandle here as another property. Doing that will cause the DT parsing logic to wait for the syscon to be probed before trying to probe this driver. It's also useful so we can see if the clock controller is overlapping withe whatever the syscon node is, or if that syscon node should just have the #clock-cells property as part of the node instead.
On Tue, Mar 11, 2025 at 12:26:21PM -0700, Stephen Boyd wrote: > Quoting Inochi Amaoto (2025-02-26 15:23:18) > > diff --git a/Documentation/devicetree/bindings/clock/sophgo,sg2044-clk.yaml b/Documentation/devicetree/bindings/clock/sophgo,sg2044-clk.yaml > > new file mode 100644 > > index 000000000000..d55c5d32e206 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/clock/sophgo,sg2044-clk.yaml > > @@ -0,0 +1,40 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/clock/sophgo,sg2044-clk.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Sophgo SG2044 Clock Controller > > + > > +maintainers: > > + - Inochi Amaoto <inochiama@gmail.com> > > No description? > I am not sure the things to be described. Maybe just tell the clock required and providing? > > + > > +properties: > > + compatible: > > + const: sophgo,sg2044-clk > > + > > + reg: > > + maxItems: 1 > > + > > + clocks: > > + maxItems: 1 > > + > > + '#clock-cells': > > + const: 1 > > + > > +required: > > + - compatible > > + - reg > > + - clocks > > + - '#clock-cells' > > + > > +additionalProperties: false > > + > > +examples: > > + - | > > + clock-controller@50002000 { > > + compatible = "sophgo,sg2044-clk"; > > + reg = <0x50002000 0x1000>; > > + #clock-cells = <1>; > > + clocks = <&osc>; > > I think you want the syscon phandle here as another property. Doing that > will cause the DT parsing logic to wait for the syscon to be probed > before trying to probe this driver. It's also useful so we can see if > the clock controller is overlapping withe whatever the syscon node is, It sounds like a good idea. At now, it does not seem like a good idea to hidden the device dependency detail. I will add a syscon property like "sophgo,pll-syscon" to identify its pll needs a syscon handle. > or if that syscon node should just have the #clock-cells property as > part of the node instead. This is not match the hardware I think. The pll area is on the middle of the syscon and is hard to be separated as a subdevice of the syscon or just add "#clock-cells" to the syscon device. It is better to handle them in one device/driver. So let the clock device reference it. Regards, Inochi
Quoting Inochi Amaoto (2025-03-11 16:31:29) > On Tue, Mar 11, 2025 at 12:26:21PM -0700, Stephen Boyd wrote: > > Quoting Inochi Amaoto (2025-02-26 15:23:18) > > > diff --git a/Documentation/devicetree/bindings/clock/sophgo,sg2044-clk.yaml b/Documentation/devicetree/bindings/clock/sophgo,sg2044-clk.yaml > > > new file mode 100644 > > > index 000000000000..d55c5d32e206 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/clock/sophgo,sg2044-clk.yaml > > > @@ -0,0 +1,40 @@ > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/clock/sophgo,sg2044-clk.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Sophgo SG2044 Clock Controller > > > + > > > +maintainers: > > > + - Inochi Amaoto <inochiama@gmail.com> > > > > No description? > > > > I am not sure the things to be described. Maybe just tell the > clock required and providing? Sure and point to the header file with the binding numbers? > > > + - | > > > + clock-controller@50002000 { > > > + compatible = "sophgo,sg2044-clk"; > > > + reg = <0x50002000 0x1000>; > > > + #clock-cells = <1>; > > > + clocks = <&osc>; > > > > I think you want the syscon phandle here as another property. Doing that > > will cause the DT parsing logic to wait for the syscon to be probed > > before trying to probe this driver. It's also useful so we can see if > > the clock controller is overlapping withe whatever the syscon node is, > > It sounds like a good idea. At now, it does not seem like a good idea > to hidden the device dependency detail. I will add a syscon property > like "sophgo,pll-syscon" to identify its pll needs a syscon handle. Cool. > > > or if that syscon node should just have the #clock-cells property as > > part of the node instead. > > This is not match the hardware I think. The pll area is on the middle > of the syscon and is hard to be separated as a subdevice of the syscon > or just add "#clock-cells" to the syscon device. It is better to handle > them in one device/driver. So let the clock device reference it. This happens all the time. We don't need a syscon for that unless the registers for the pll are both inside the syscon and in the register space 0x50002000. Is that the case? This looks like you want there to be one node for clks on the system because logically that is clean, when the reality is that there is a PLL block exposed in the syscon (someone forgot to put it in the clk controller?) and a non-PLL block for the other clks.
On Wed, Mar 12, 2025 at 04:14:37PM -0700, Stephen Boyd wrote: > Quoting Inochi Amaoto (2025-03-11 16:31:29) > > On Tue, Mar 11, 2025 at 12:26:21PM -0700, Stephen Boyd wrote: > > > Quoting Inochi Amaoto (2025-02-26 15:23:18) > > > > diff --git a/Documentation/devicetree/bindings/clock/sophgo,sg2044-clk.yaml b/Documentation/devicetree/bindings/clock/sophgo,sg2044-clk.yaml > > > > new file mode 100644 > > > > index 000000000000..d55c5d32e206 > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/clock/sophgo,sg2044-clk.yaml > > > > @@ -0,0 +1,40 @@ > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > > > +%YAML 1.2 > > > > +--- > > > > +$id: http://devicetree.org/schemas/clock/sophgo,sg2044-clk.yaml# > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > + > > > > +title: Sophgo SG2044 Clock Controller > > > > + > > > > +maintainers: > > > > + - Inochi Amaoto <inochiama@gmail.com> > > > > > > No description? > > > > > > > I am not sure the things to be described. Maybe just tell the > > clock required and providing? > > Sure and point to the header file with the binding numbers? > Good, I will add it. > > > > + - | > > > > + clock-controller@50002000 { > > > > + compatible = "sophgo,sg2044-clk"; > > > > + reg = <0x50002000 0x1000>; > > > > + #clock-cells = <1>; > > > > + clocks = <&osc>; > > > > > > I think you want the syscon phandle here as another property. Doing that > > > will cause the DT parsing logic to wait for the syscon to be probed > > > before trying to probe this driver. It's also useful so we can see if > > > the clock controller is overlapping withe whatever the syscon node is, > > > > It sounds like a good idea. At now, it does not seem like a good idea > > to hidden the device dependency detail. I will add a syscon property > > like "sophgo,pll-syscon" to identify its pll needs a syscon handle. > > Cool. > > > > > > or if that syscon node should just have the #clock-cells property as > > > part of the node instead. > > > > This is not match the hardware I think. The pll area is on the middle > > of the syscon and is hard to be separated as a subdevice of the syscon > > or just add "#clock-cells" to the syscon device. It is better to handle > > them in one device/driver. So let the clock device reference it. > > This happens all the time. We don't need a syscon for that unless the > registers for the pll are both inside the syscon and in the register > space 0x50002000. Is that the case? Yes, the clock has two areas, one in the clk controller and one in the syscon, the vendor said this design is a heritage from other SoC. > This looks like you want there to be one node for clks on the system > because logically that is clean, when the reality is that there is a > PLL block exposed in the syscon (someone forgot to put it in the clk > controller?) and a non-PLL block for the other clks. That is true, I prefer to keep clean and make less mistakes. Although the PLL is exposed in the syscon, the pll need to be tight with other clocks in the space 0x50002000 (especially between the PLL and mux). In this view, it is more like a mistake made by the hardware design. And I prefer not to add a subnode for the syscon. Regards, Inochi
Quoting Inochi Amaoto (2025-03-12 16:29:43) > On Wed, Mar 12, 2025 at 04:14:37PM -0700, Stephen Boyd wrote: > > Quoting Inochi Amaoto (2025-03-11 16:31:29) > > > > > > > or if that syscon node should just have the #clock-cells property as > > > > part of the node instead. > > > > > > This is not match the hardware I think. The pll area is on the middle > > > of the syscon and is hard to be separated as a subdevice of the syscon > > > or just add "#clock-cells" to the syscon device. It is better to handle > > > them in one device/driver. So let the clock device reference it. > > > > This happens all the time. We don't need a syscon for that unless the > > registers for the pll are both inside the syscon and in the register > > space 0x50002000. Is that the case? > > Yes, the clock has two areas, one in the clk controller and one in > the syscon, the vendor said this design is a heritage from other SoC. My question is more if the PLL clk_ops need to access both the syscon register range and the clk controller register range. What part of the PLL clk_ops needs to access the clk controller at 0x50002000? > > > This looks like you want there to be one node for clks on the system > > because logically that is clean, when the reality is that there is a > > PLL block exposed in the syscon (someone forgot to put it in the clk > > controller?) and a non-PLL block for the other clks. > > That is true, I prefer to keep clean and make less mistakes. Although > the PLL is exposed in the syscon, the pll need to be tight with other > clocks in the space 0x50002000 (especially between the PLL and mux). > In this view, it is more like a mistake made by the hardware design. > And I prefer not to add a subnode for the syscon. Ok. You wouldn't add a subnode for the syscon. You would just have #clock-cells in that syscon node and register an auxiliary device to provide the PLL(s) from there. Then in drivers/clk we would have an auxiliary driver that uses a regmap or gets an iomem pointer from the parent device somehow so that we can logically put the PLL code in drivers/clk while having one node in DT for the "miscellaneous register area" where the hardware engineer had to expose the PLL control to software.
On Wed, Mar 12, 2025 at 04:43:51PM -0700, Stephen Boyd wrote: > Quoting Inochi Amaoto (2025-03-12 16:29:43) > > On Wed, Mar 12, 2025 at 04:14:37PM -0700, Stephen Boyd wrote: > > > Quoting Inochi Amaoto (2025-03-11 16:31:29) > > > > > > > > > or if that syscon node should just have the #clock-cells property as > > > > > part of the node instead. > > > > > > > > This is not match the hardware I think. The pll area is on the middle > > > > of the syscon and is hard to be separated as a subdevice of the syscon > > > > or just add "#clock-cells" to the syscon device. It is better to handle > > > > them in one device/driver. So let the clock device reference it. > > > > > > This happens all the time. We don't need a syscon for that unless the > > > registers for the pll are both inside the syscon and in the register > > > space 0x50002000. Is that the case? > > > > Yes, the clock has two areas, one in the clk controller and one in > > the syscon, the vendor said this design is a heritage from other SoC. > > My question is more if the PLL clk_ops need to access both the syscon > register range and the clk controller register range. What part of the > PLL clk_ops needs to access the clk controller at 0x50002000? > The PLL clk_ops does nothing, but there is an implicit dependency: When the PLL change rate, the mux attached to it must switch to another source to keep the output clock stable. This is the only thing it needed. > > > > > This looks like you want there to be one node for clks on the system > > > because logically that is clean, when the reality is that there is a > > > PLL block exposed in the syscon (someone forgot to put it in the clk > > > controller?) and a non-PLL block for the other clks. > > > > That is true, I prefer to keep clean and make less mistakes. Although > > the PLL is exposed in the syscon, the pll need to be tight with other > > clocks in the space 0x50002000 (especially between the PLL and mux). > > In this view, it is more like a mistake made by the hardware design. > > And I prefer not to add a subnode for the syscon. > > Ok. You wouldn't add a subnode for the syscon. You would just have > #clock-cells in that syscon node and register an auxiliary device to > provide the PLL(s) from there. Then in drivers/clk we would have an > auxiliary driver that uses a regmap or gets an iomem pointer from the > parent device somehow so that we can logically put the PLL code in > drivers/clk while having one node in DT for the "miscellaneous register > area" where the hardware engineer had to expose the PLL control to > software. Cool, I understand what you mean. It is a good idea, I will have a try. Regards, Inochi
Quoting Inochi Amaoto (2025-03-12 18:08:11) > On Wed, Mar 12, 2025 at 04:43:51PM -0700, Stephen Boyd wrote: > > Quoting Inochi Amaoto (2025-03-12 16:29:43) > > > On Wed, Mar 12, 2025 at 04:14:37PM -0700, Stephen Boyd wrote: > > > > Quoting Inochi Amaoto (2025-03-11 16:31:29) > > > > > > > > > > > or if that syscon node should just have the #clock-cells property as > > > > > > part of the node instead. > > > > > > > > > > This is not match the hardware I think. The pll area is on the middle > > > > > of the syscon and is hard to be separated as a subdevice of the syscon > > > > > or just add "#clock-cells" to the syscon device. It is better to handle > > > > > them in one device/driver. So let the clock device reference it. > > > > > > > > This happens all the time. We don't need a syscon for that unless the > > > > registers for the pll are both inside the syscon and in the register > > > > space 0x50002000. Is that the case? > > > > > > Yes, the clock has two areas, one in the clk controller and one in > > > the syscon, the vendor said this design is a heritage from other SoC. > > > > My question is more if the PLL clk_ops need to access both the syscon > > register range and the clk controller register range. What part of the > > PLL clk_ops needs to access the clk controller at 0x50002000? > > > > The PLL clk_ops does nothing, but there is an implicit dependency: > When the PLL change rate, the mux attached to it must switch to > another source to keep the output clock stable. This is the only > thing it needed. I haven't looked at the clk_ops in detail (surprise! :) but that sounds a lot like the parent of the mux is the PLL and there's some "safe" source that is needed temporarily while the PLL is reprogrammed for a new rate. Is that right? I recall the notifier is in the driver so this sounds like that sort of design.
On Thu, Mar 13, 2025 at 01:22:28PM -0700, Stephen Boyd wrote: > Quoting Inochi Amaoto (2025-03-12 18:08:11) > > On Wed, Mar 12, 2025 at 04:43:51PM -0700, Stephen Boyd wrote: > > > Quoting Inochi Amaoto (2025-03-12 16:29:43) > > > > On Wed, Mar 12, 2025 at 04:14:37PM -0700, Stephen Boyd wrote: > > > > > Quoting Inochi Amaoto (2025-03-11 16:31:29) > > > > > > > > > > > > > or if that syscon node should just have the #clock-cells property as > > > > > > > part of the node instead. > > > > > > > > > > > > This is not match the hardware I think. The pll area is on the middle > > > > > > of the syscon and is hard to be separated as a subdevice of the syscon > > > > > > or just add "#clock-cells" to the syscon device. It is better to handle > > > > > > them in one device/driver. So let the clock device reference it. > > > > > > > > > > This happens all the time. We don't need a syscon for that unless the > > > > > registers for the pll are both inside the syscon and in the register > > > > > space 0x50002000. Is that the case? > > > > > > > > Yes, the clock has two areas, one in the clk controller and one in > > > > the syscon, the vendor said this design is a heritage from other SoC. > > > > > > My question is more if the PLL clk_ops need to access both the syscon > > > register range and the clk controller register range. What part of the > > > PLL clk_ops needs to access the clk controller at 0x50002000? > > > > > > > The PLL clk_ops does nothing, but there is an implicit dependency: > > When the PLL change rate, the mux attached to it must switch to > > another source to keep the output clock stable. This is the only > > thing it needed. > > I haven't looked at the clk_ops in detail (surprise! :) but that sounds > a lot like the parent of the mux is the PLL and there's some "safe" > source that is needed temporarily while the PLL is reprogrammed for a > new rate. Is that right? I recall the notifier is in the driver so this > sounds like that sort of design. You are right, this design is like what you say. And this design is the reason that I prefer to just reference the syscon node but not setting the syscon with "#clock-cell". Regards, Inochi
Quoting Inochi Amaoto (2025-03-13 15:46:22) > On Thu, Mar 13, 2025 at 01:22:28PM -0700, Stephen Boyd wrote: > > Quoting Inochi Amaoto (2025-03-12 18:08:11) > > > On Wed, Mar 12, 2025 at 04:43:51PM -0700, Stephen Boyd wrote: > > > > Quoting Inochi Amaoto (2025-03-12 16:29:43) > > > > > On Wed, Mar 12, 2025 at 04:14:37PM -0700, Stephen Boyd wrote: > > > > > > Quoting Inochi Amaoto (2025-03-11 16:31:29) > > > > > > > > > > > > > > > or if that syscon node should just have the #clock-cells property as > > > > > > > > part of the node instead. > > > > > > > > > > > > > > This is not match the hardware I think. The pll area is on the middle > > > > > > > of the syscon and is hard to be separated as a subdevice of the syscon > > > > > > > or just add "#clock-cells" to the syscon device. It is better to handle > > > > > > > them in one device/driver. So let the clock device reference it. > > > > > > > > > > > > This happens all the time. We don't need a syscon for that unless the > > > > > > registers for the pll are both inside the syscon and in the register > > > > > > space 0x50002000. Is that the case? > > > > > > > > > > Yes, the clock has two areas, one in the clk controller and one in > > > > > the syscon, the vendor said this design is a heritage from other SoC. > > > > > > > > My question is more if the PLL clk_ops need to access both the syscon > > > > register range and the clk controller register range. What part of the > > > > PLL clk_ops needs to access the clk controller at 0x50002000? > > > > > > > > > > The PLL clk_ops does nothing, but there is an implicit dependency: > > > When the PLL change rate, the mux attached to it must switch to > > > another source to keep the output clock stable. This is the only > > > thing it needed. > > > > I haven't looked at the clk_ops in detail (surprise! :) but that sounds > > a lot like the parent of the mux is the PLL and there's some "safe" > > source that is needed temporarily while the PLL is reprogrammed for a > > new rate. Is that right? I recall the notifier is in the driver so this > > sounds like that sort of design. > > You are right, this design is like what you say. And this design is > the reason that I prefer to just reference the syscon node but not > setting the syscon with "#clock-cell". > I don't see why a syscon phandle is preferred over #clock-cells. This temporary parent is still a clk, right? In my opinion syscon should never be used. It signals that we lack a proper framework in the kernel to handle something. Even in the "miscellaneous" register range sort of design, we can say that this grab bag of registers is exposing resources like clks or gpios, etc. as a one off sort of thing because it was too late to change other hardware blocks.
On Thu, Mar 27, 2025 at 02:21:55PM -0700, Stephen Boyd wrote: > Quoting Inochi Amaoto (2025-03-13 15:46:22) > > On Thu, Mar 13, 2025 at 01:22:28PM -0700, Stephen Boyd wrote: > > > Quoting Inochi Amaoto (2025-03-12 18:08:11) > > > > On Wed, Mar 12, 2025 at 04:43:51PM -0700, Stephen Boyd wrote: > > > > > Quoting Inochi Amaoto (2025-03-12 16:29:43) > > > > > > On Wed, Mar 12, 2025 at 04:14:37PM -0700, Stephen Boyd wrote: > > > > > > > Quoting Inochi Amaoto (2025-03-11 16:31:29) > > > > > > > > > > > > > > > > > or if that syscon node should just have the #clock-cells property as > > > > > > > > > part of the node instead. > > > > > > > > > > > > > > > > This is not match the hardware I think. The pll area is on the middle > > > > > > > > of the syscon and is hard to be separated as a subdevice of the syscon > > > > > > > > or just add "#clock-cells" to the syscon device. It is better to handle > > > > > > > > them in one device/driver. So let the clock device reference it. > > > > > > > > > > > > > > This happens all the time. We don't need a syscon for that unless the > > > > > > > registers for the pll are both inside the syscon and in the register > > > > > > > space 0x50002000. Is that the case? > > > > > > > > > > > > Yes, the clock has two areas, one in the clk controller and one in > > > > > > the syscon, the vendor said this design is a heritage from other SoC. > > > > > > > > > > My question is more if the PLL clk_ops need to access both the syscon > > > > > register range and the clk controller register range. What part of the > > > > > PLL clk_ops needs to access the clk controller at 0x50002000? > > > > > > > > > > > > > The PLL clk_ops does nothing, but there is an implicit dependency: > > > > When the PLL change rate, the mux attached to it must switch to > > > > another source to keep the output clock stable. This is the only > > > > thing it needed. > > > > > > I haven't looked at the clk_ops in detail (surprise! :) but that sounds > > > a lot like the parent of the mux is the PLL and there's some "safe" > > > source that is needed temporarily while the PLL is reprogrammed for a > > > new rate. Is that right? I recall the notifier is in the driver so this > > > sounds like that sort of design. > > > > You are right, this design is like what you say. And this design is > > the reason that I prefer to just reference the syscon node but not > > setting the syscon with "#clock-cell". > > > > I don't see why a syscon phandle is preferred over #clock-cells. This > temporary parent is still a clk, right? Yeah, it is true. > In my opinion syscon should never be used. It signals that we lack a > proper framework in the kernel to handle something. Even in the > "miscellaneous" register range sort of design, we can say that this > grab bag of registers is exposing resources like clks or gpios, etc. > as a one off sort of thing because it was too late to change other > hardware blocks. This is right, the syscon is not very good to be added. And I found mfd framework is used in most case to provide multi-function. So I think I make a mistake in design. I will try your advice and submit a new version for it. Thanks for your kindly explanation. Regards, Inochi
diff --git a/Documentation/devicetree/bindings/clock/sophgo,sg2044-clk.yaml b/Documentation/devicetree/bindings/clock/sophgo,sg2044-clk.yaml new file mode 100644 index 000000000000..d55c5d32e206 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/sophgo,sg2044-clk.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/sophgo,sg2044-clk.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sophgo SG2044 Clock Controller + +maintainers: + - Inochi Amaoto <inochiama@gmail.com> + +properties: + compatible: + const: sophgo,sg2044-clk + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + - clocks + - '#clock-cells' + +additionalProperties: false + +examples: + - | + clock-controller@50002000 { + compatible = "sophgo,sg2044-clk"; + reg = <0x50002000 0x1000>; + #clock-cells = <1>; + clocks = <&osc>; + }; diff --git a/include/dt-bindings/clock/sophgo,sg2044-clk.h b/include/dt-bindings/clock/sophgo,sg2044-clk.h new file mode 100644 index 000000000000..1da54354e5c3 --- /dev/null +++ b/include/dt-bindings/clock/sophgo,sg2044-clk.h @@ -0,0 +1,170 @@ +/* SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause */ +/* + * Copyright (C) 2024 Inochi Amaoto <inochiama@gmail.com> + */ + +#ifndef __DT_BINDINGS_SOPHGO_SG2044_CLK_H__ +#define __DT_BINDINGS_SOPHGO_SG2044_CLK_H__ + +#define CLK_FPLL0 0 +#define CLK_FPLL1 1 +#define CLK_FPLL2 2 +#define CLK_DPLL0 3 +#define CLK_DPLL1 4 +#define CLK_DPLL2 5 +#define CLK_DPLL3 6 +#define CLK_DPLL4 7 +#define CLK_DPLL5 8 +#define CLK_DPLL6 9 +#define CLK_DPLL7 10 +#define CLK_MPLL0 11 +#define CLK_MPLL1 12 +#define CLK_MPLL2 13 +#define CLK_MPLL3 14 +#define CLK_MPLL4 15 +#define CLK_MPLL5 16 +#define CLK_DIV_AP_SYS_FIXED 17 +#define CLK_DIV_AP_SYS_MAIN 18 +#define CLK_DIV_RP_SYS_FIXED 19 +#define CLK_DIV_RP_SYS_MAIN 20 +#define CLK_DIV_TPU_SYS_FIXED 21 +#define CLK_DIV_TPU_SYS_MAIN 22 +#define CLK_DIV_NOC_SYS_FIXED 23 +#define CLK_DIV_NOC_SYS_MAIN 24 +#define CLK_DIV_VC_SRC0_FIXED 25 +#define CLK_DIV_VC_SRC0_MAIN 26 +#define CLK_DIV_VC_SRC1_FIXED 27 +#define CLK_DIV_VC_SRC1_MAIN 28 +#define CLK_DIV_CXP_MAC_FIXED 29 +#define CLK_DIV_CXP_MAC_MAIN 30 +#define CLK_DIV_DDR0_FIXED 31 +#define CLK_DIV_DDR0_MAIN 32 +#define CLK_DIV_DDR1_FIXED 33 +#define CLK_DIV_DDR1_MAIN 34 +#define CLK_DIV_DDR2_FIXED 35 +#define CLK_DIV_DDR2_MAIN 36 +#define CLK_DIV_DDR3_FIXED 37 +#define CLK_DIV_DDR3_MAIN 38 +#define CLK_DIV_DDR4_FIXED 39 +#define CLK_DIV_DDR4_MAIN 40 +#define CLK_DIV_DDR5_FIXED 41 +#define CLK_DIV_DDR5_MAIN 42 +#define CLK_DIV_DDR6_FIXED 43 +#define CLK_DIV_DDR6_MAIN 44 +#define CLK_DIV_DDR7_FIXED 45 +#define CLK_DIV_DDR7_MAIN 46 +#define CLK_DIV_TOP_50M 47 +#define CLK_DIV_TOP_AXI0 48 +#define CLK_DIV_TOP_AXI_HSPERI 49 +#define CLK_DIV_TIMER0 50 +#define CLK_DIV_TIMER1 51 +#define CLK_DIV_TIMER2 52 +#define CLK_DIV_TIMER3 53 +#define CLK_DIV_TIMER4 54 +#define CLK_DIV_TIMER5 55 +#define CLK_DIV_TIMER6 56 +#define CLK_DIV_TIMER7 57 +#define CLK_DIV_CXP_TEST_PHY 58 +#define CLK_DIV_CXP_TEST_ETH_PHY 59 +#define CLK_DIV_C2C0_TEST_PHY 60 +#define CLK_DIV_C2C1_TEST_PHY 61 +#define CLK_DIV_PCIE_1G 62 +#define CLK_DIV_UART_500M 63 +#define CLK_DIV_GPIO_DB 64 +#define CLK_DIV_SD 65 +#define CLK_DIV_SD_100K 66 +#define CLK_DIV_EMMC 67 +#define CLK_DIV_EMMC_100K 68 +#define CLK_DIV_EFUSE 69 +#define CLK_DIV_TX_ETH0 70 +#define CLK_DIV_PTP_REF_I_ETH0 71 +#define CLK_DIV_REF_ETH0 72 +#define CLK_DIV_PKA 73 +#define CLK_MUX_DDR0 74 +#define CLK_MUX_DDR1 75 +#define CLK_MUX_DDR2 76 +#define CLK_MUX_DDR3 77 +#define CLK_MUX_DDR4 78 +#define CLK_MUX_DDR5 79 +#define CLK_MUX_DDR6 80 +#define CLK_MUX_DDR7 81 +#define CLK_MUX_NOC_SYS 82 +#define CLK_MUX_TPU_SYS 83 +#define CLK_MUX_RP_SYS 84 +#define CLK_MUX_AP_SYS 85 +#define CLK_MUX_VC_SRC0 86 +#define CLK_MUX_VC_SRC1 87 +#define CLK_MUX_CXP_MAC 88 +#define CLK_GATE_AP_SYS 89 +#define CLK_GATE_RP_SYS 90 +#define CLK_GATE_TPU_SYS 91 +#define CLK_GATE_NOC_SYS 92 +#define CLK_GATE_VC_SRC0 93 +#define CLK_GATE_VC_SRC1 94 +#define CLK_GATE_DDR0 95 +#define CLK_GATE_DDR1 96 +#define CLK_GATE_DDR2 97 +#define CLK_GATE_DDR3 98 +#define CLK_GATE_DDR4 99 +#define CLK_GATE_DDR5 100 +#define CLK_GATE_DDR6 101 +#define CLK_GATE_DDR7 102 +#define CLK_GATE_TOP_50M 103 +#define CLK_GATE_SC_RX 104 +#define CLK_GATE_SC_RX_X0Y1 105 +#define CLK_GATE_TOP_AXI0 106 +#define CLK_GATE_INTC0 107 +#define CLK_GATE_INTC1 108 +#define CLK_GATE_INTC2 109 +#define CLK_GATE_INTC3 110 +#define CLK_GATE_MAILBOX0 111 +#define CLK_GATE_MAILBOX1 112 +#define CLK_GATE_MAILBOX2 113 +#define CLK_GATE_MAILBOX3 114 +#define CLK_GATE_TOP_AXI_HSPERI 115 +#define CLK_GATE_APB_TIMER 116 +#define CLK_GATE_TIMER0 117 +#define CLK_GATE_TIMER1 118 +#define CLK_GATE_TIMER2 119 +#define CLK_GATE_TIMER3 120 +#define CLK_GATE_TIMER4 121 +#define CLK_GATE_TIMER5 122 +#define CLK_GATE_TIMER6 123 +#define CLK_GATE_TIMER7 124 +#define CLK_GATE_CXP_CFG 125 +#define CLK_GATE_CXP_MAC 126 +#define CLK_GATE_CXP_TEST_PHY 127 +#define CLK_GATE_CXP_TEST_ETH_PHY 128 +#define CLK_GATE_PCIE_1G 129 +#define CLK_GATE_C2C0_TEST_PHY 130 +#define CLK_GATE_C2C1_TEST_PHY 131 +#define CLK_GATE_UART_500M 132 +#define CLK_GATE_APB_UART 133 +#define CLK_GATE_APB_SPI 134 +#define CLK_GATE_AHB_SPIFMC 135 +#define CLK_GATE_APB_I2C 136 +#define CLK_GATE_AXI_DBG_I2C 137 +#define CLK_GATE_GPIO_DB 138 +#define CLK_GATE_APB_GPIO_INTR 139 +#define CLK_GATE_APB_GPIO 140 +#define CLK_GATE_SD 141 +#define CLK_GATE_AXI_SD 142 +#define CLK_GATE_SD_100K 143 +#define CLK_GATE_EMMC 144 +#define CLK_GATE_AXI_EMMC 145 +#define CLK_GATE_EMMC_100K 146 +#define CLK_GATE_EFUSE 147 +#define CLK_GATE_APB_EFUSE 148 +#define CLK_GATE_SYSDMA_AXI 149 +#define CLK_GATE_TX_ETH0 150 +#define CLK_GATE_AXI_ETH0 151 +#define CLK_GATE_PTP_REF_I_ETH0 152 +#define CLK_GATE_REF_ETH0 153 +#define CLK_GATE_APB_RTC 154 +#define CLK_GATE_APB_PWM 155 +#define CLK_GATE_APB_WDT 156 +#define CLK_GATE_AXI_SRAM 157 +#define CLK_GATE_AHB_ROM 158 +#define CLK_GATE_PKA 159 + +#endif /* __DT_BINDINGS_SOPHGO_SG2044_CLK_H__ */