Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0 |
|
#
70fa8954 |
| 29-Sep-2022 |
Serge Semin <Sergey.Semin@baikalelectronics.ru> |
clk: baikal-t1: Move reset-controls code into a dedicated module
Before adding the directly controlled resets support it's reasonable to move the existing resets control functionality into a dedicat
clk: baikal-t1: Move reset-controls code into a dedicated module
Before adding the directly controlled resets support it's reasonable to move the existing resets control functionality into a dedicated object for the sake of the CCU dividers clock driver simplification. After the new functionality was added clk-ccu-div.c would have got to a mixture of the weakly dependent clocks and resets methods. Splitting the methods up into the two objects will make the code easier to read and maintain. It shall also improve the code scalability (though hopefully we won't need this part that much in the future).
The reset control functionality is now implemented in the framework of a single unit since splitting it up doesn't make much sense due to relatively simple reset operations. The ccu-rst.c has been designed to be looking like ccu-div.c or ccu-pll.c with two globally available methods for the sake of the code unification and better code readability.
This commit doesn't provide any change in the CCU reset implementation semantics. As before the driver will support the trigger-like CCU resets only, which are responsible for the AXI-bus, APB-bus and SATA-ref blocks reset. The assert/de-assert-capable reset controls support will be added in the next commit.
Note the CCU Clock dividers and resets functionality split up was possible due to not having any side-effects (at least we didn't found ones) of the regmap-based concurrent access of the common CCU dividers/reset CSRs.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Link: https://lore.kernel.org/r/20220929225402.9696-6-Sergey.Semin@baikalelectronics.ru Signed-off-by: Stephen Boyd <sboyd@kernel.org>
show more ...
|
Revision tags: v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43 |
|
#
353afa3a |
| 26-May-2020 |
Serge Semin <Sergey.Semin@baikalelectronics.ru> |
clk: Add Baikal-T1 CCU Dividers driver
Nearly each Baikal-T1 IP-core is supposed to have a clock source of particular frequency. But since there are greater than five IP-blocks embedded into the SoC
clk: Add Baikal-T1 CCU Dividers driver
Nearly each Baikal-T1 IP-core is supposed to have a clock source of particular frequency. But since there are greater than five IP-blocks embedded into the SoC, the CCU PLLs can't fulfill all the needs. Baikal-T1 CCU provides a set of fixed and configurable clock dividers in order to generate a necessary signal for each chip sub-block.
This driver creates the of-based hardware clocks for each divider available in Baikal-T1 CCU. The same way as for PLLs we split the functionality up into the clocks operations (gate, ungate, set rate, etc) and hardware clocks declaration/registration procedures.
In accordance with the CCU documentation all its dividers are distributed into two CCU sub-blocks: AXI-bus and system devices reference clocks. The former sub-block is used to supply the clocks for AXI-bus interfaces (AXI clock domains) and the later one provides the SoC IP-cores reference clocks. Each sub-block is represented by a dedicated DT node, so they have different compatible strings to distinguish one from another.
For some reason CCU provides the dividers of different types. Some dividers can be gateable some can't, some are fixed while the others are variable, some have special divider' limitations, some've got a non-standard register layout and so on. In order to cover all of these cases the hardware clocks driver is designed with an info-descriptor pattern. So there are special static descriptors declared for the dividers of each type with additional flags describing the block peculiarity. These descriptors are then used to create hardware clocks with proper operations.
Some CCU dividers provide a way to reset a domain they generate a clock for. So the CCU AXI-bus and CCU system devices clock drivers also perform the reset controller registration.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Rob Herring <robh+dt@kernel.org> Cc: linux-mips@vger.kernel.org Cc: devicetree@vger.kernel.org Link: https://lore.kernel.org/r/20200526222056.18072-5-Sergey.Semin@baikalelectronics.ru [sboyd@kernel.org: Drop return from void function, silence sparse warnings about initializing structs with NULL vs. integer] Signed-off-by: Stephen Boyd <sboyd@kernel.org>
show more ...
|
#
b7d950b9 |
| 26-May-2020 |
Serge Semin <Sergey.Semin@baikalelectronics.ru> |
clk: Add Baikal-T1 CCU PLLs driver
Baikal-T1 is supposed to be supplied with a high-frequency external oscillator. But in order to create signals suitable for each IP-block embedded into the SoC the
clk: Add Baikal-T1 CCU PLLs driver
Baikal-T1 is supposed to be supplied with a high-frequency external oscillator. But in order to create signals suitable for each IP-block embedded into the SoC the oscillator output is primarily connected to a set of CCU PLLs. There are five of them to create clocks for the MIPS P5600 cores, an embedded DDR controller, SATA, Ethernet and PCIe domains. The last three domains though named by the biggest system interfaces in fact include nearly all of the rest SoC peripherals. Each of the PLLs is based on True Circuits TSMC CLN28HPM IP-core with an interface wrapper (so called safe PLL' clocks switcher) to simplify the PLL configuration procedure.
This driver creates the of-based hardware clocks to use them then in the corresponding subsystems. In order to simplify the driver code we split the functionality up into the PLLs clocks operations and hardware clocks declaration/registration procedures.
Even though the PLLs are based on the same IP-core, they may have some differences. In particular, some CCU PLLs support the output clock change without gating them (like CPU or PCIe PLLs), while the others don't, some CCU PLLs are critical and aren't supposed to be gated. In order to cover all of these cases the hardware clocks driver is designed with an info-descriptor pattern. So there are special static descriptors declared for each PLL, which is then used to create a hardware clock with proper operations. Additionally debugfs-files are provided for each PLL' field to make sure the implemented rate-PLLs-dividers calculation algorithm is correct.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Rob Herring <robh+dt@kernel.org> Cc: linux-mips@vger.kernel.org Cc: devicetree@vger.kernel.org Link: https://lore.kernel.org/r/20200526222056.18072-4-Sergey.Semin@baikalelectronics.ru [sboyd@kernel.org: Silence sparse warning about initializing structs with NULL vs. integer] Signed-off-by: Stephen Boyd <sboyd@kernel.org>
show more ...
|
Revision tags: v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43 |
|
#
353afa3a |
| 26-May-2020 |
Serge Semin <Sergey.Semin@baikalelectronics.ru> |
clk: Add Baikal-T1 CCU Dividers driver Nearly each Baikal-T1 IP-core is supposed to have a clock source of particular frequency. But since there are greater than five IP-blocks embed
clk: Add Baikal-T1 CCU Dividers driver Nearly each Baikal-T1 IP-core is supposed to have a clock source of particular frequency. But since there are greater than five IP-blocks embedded into the SoC, the CCU PLLs can't fulfill all the needs. Baikal-T1 CCU provides a set of fixed and configurable clock dividers in order to generate a necessary signal for each chip sub-block. This driver creates the of-based hardware clocks for each divider available in Baikal-T1 CCU. The same way as for PLLs we split the functionality up into the clocks operations (gate, ungate, set rate, etc) and hardware clocks declaration/registration procedures. In accordance with the CCU documentation all its dividers are distributed into two CCU sub-blocks: AXI-bus and system devices reference clocks. The former sub-block is used to supply the clocks for AXI-bus interfaces (AXI clock domains) and the later one provides the SoC IP-cores reference clocks. Each sub-block is represented by a dedicated DT node, so they have different compatible strings to distinguish one from another. For some reason CCU provides the dividers of different types. Some dividers can be gateable some can't, some are fixed while the others are variable, some have special divider' limitations, some've got a non-standard register layout and so on. In order to cover all of these cases the hardware clocks driver is designed with an info-descriptor pattern. So there are special static descriptors declared for the dividers of each type with additional flags describing the block peculiarity. These descriptors are then used to create hardware clocks with proper operations. Some CCU dividers provide a way to reset a domain they generate a clock for. So the CCU AXI-bus and CCU system devices clock drivers also perform the reset controller registration. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Rob Herring <robh+dt@kernel.org> Cc: linux-mips@vger.kernel.org Cc: devicetree@vger.kernel.org Link: https://lore.kernel.org/r/20200526222056.18072-5-Sergey.Semin@baikalelectronics.ru [sboyd@kernel.org: Drop return from void function, silence sparse warnings about initializing structs with NULL vs. integer] Signed-off-by: Stephen Boyd <sboyd@kernel.org>
show more ...
|
#
b7d950b9 |
| 26-May-2020 |
Serge Semin <Sergey.Semin@baikalelectronics.ru> |
clk: Add Baikal-T1 CCU PLLs driver Baikal-T1 is supposed to be supplied with a high-frequency external oscillator. But in order to create signals suitable for each IP-block embedded
clk: Add Baikal-T1 CCU PLLs driver Baikal-T1 is supposed to be supplied with a high-frequency external oscillator. But in order to create signals suitable for each IP-block embedded into the SoC the oscillator output is primarily connected to a set of CCU PLLs. There are five of them to create clocks for the MIPS P5600 cores, an embedded DDR controller, SATA, Ethernet and PCIe domains. The last three domains though named by the biggest system interfaces in fact include nearly all of the rest SoC peripherals. Each of the PLLs is based on True Circuits TSMC CLN28HPM IP-core with an interface wrapper (so called safe PLL' clocks switcher) to simplify the PLL configuration procedure. This driver creates the of-based hardware clocks to use them then in the corresponding subsystems. In order to simplify the driver code we split the functionality up into the PLLs clocks operations and hardware clocks declaration/registration procedures. Even though the PLLs are based on the same IP-core, they may have some differences. In particular, some CCU PLLs support the output clock change without gating them (like CPU or PCIe PLLs), while the others don't, some CCU PLLs are critical and aren't supposed to be gated. In order to cover all of these cases the hardware clocks driver is designed with an info-descriptor pattern. So there are special static descriptors declared for each PLL, which is then used to create a hardware clock with proper operations. Additionally debugfs-files are provided for each PLL' field to make sure the implemented rate-PLLs-dividers calculation algorithm is correct. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Rob Herring <robh+dt@kernel.org> Cc: linux-mips@vger.kernel.org Cc: devicetree@vger.kernel.org Link: https://lore.kernel.org/r/20200526222056.18072-4-Sergey.Semin@baikalelectronics.ru [sboyd@kernel.org: Silence sparse warning about initializing structs with NULL vs. integer] Signed-off-by: Stephen Boyd <sboyd@kernel.org>
show more ...
|