summaryrefslogtreecommitdiff
path: root/drivers/clk
AgeCommit message (Collapse)AuthorFilesLines
2023-06-09clk: davinci: da8xx-cfgchip: Add a determine_rate hookMaxime Ripard1-0/+1
The Davinci DA8xxx cfgchip mux clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation. This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidates to trigger that parent change are either the assigned-clock-parents device tree property or a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate. The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock. However, the upstream device trees seem to use assigned-clock-parents on that clock to force the parent at boot time, so it's likely that the author intent was to force the parent through the device tree and prevent any reparenting but through an explicit call to clk_set_parent(). This case would be equivalent to setting the determine_rate implementation to clk_hw_determine_rate_no_reparent(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. Cc: David Lechner <david@lechnology.com> Cc: Sekhar Nori <nsekhar@ti.com> Acked-by: David Lechner <david@lechnology.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-24-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-09clk: wm831x: clkout: Add a determine_rate hookMaxime Ripard1-0/+1
The WM381x "clkout" clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation. This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidates to trigger that parent change are either the assigned-clock-parents device tree property or a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate. The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock. Similarly, it doesn't look like the device tree using that clock driver uses any of the assigned-clock properties on that clock. So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent(). The latter case would be equivalent to setting the determine_rate implementation to clk_hw_determine_rate_no_reparent(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line. Cc: patches@opensource.cirrus.com Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-23-971d5077e7d2@cerno.tech | Reported-by: kernel test robot <lkp@intel.com>: Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-09clk: vc5: clkout: Add a determine_rate hookMaxime Ripard1-0/+1
The Versaclock5 "clkout" clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation. This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidates to trigger that parent change are either the assigned-clock-parents device tree property or a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate. The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock. Similarly, it doesn't look like the device tree using that clock driver uses any of the assigned-clock properties on that clock. So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent(). The latter case would be equivalent to setting the determine_rate implementation to clk_hw_determine_rate_no_reparent(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line. Cc: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-22-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-09clk: vc5: mux: Add a determine_rate hookMaxime Ripard1-0/+1
The Versaclock5 mux clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation. This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidates to trigger that parent change are either the assigned-clock-parents device tree property or a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate. The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock. Similarly, it doesn't look like the device tree using that clock driver uses any of the assigned-clock properties on that clock. So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent(). The latter case would be equivalent to setting the determine_rate implementation to clk_hw_determine_rate_no_reparent(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line. Cc: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-21-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-09clk: stm32f4: mux: Add a determine_rate hookMaxime Ripard1-0/+1
The STM32F4 mux clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation. This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidates to trigger that parent change are either the assigned-clock-parents device tree property or a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate. The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock. However, the upstream device trees seem to use assigned-clock-parents on that clock to force the parent at boot time, so it's likely that the author intent was to force the parent through the device tree and prevent any reparenting but through an explicit call to clk_set_parent(). This case would be equivalent to setting the determine_rate implementation to clk_hw_determine_rate_no_reparent(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-stm32@st-md-mailman.stormreply.com Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-20-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-09clk: si5341: Add a determine_rate hookMaxime Ripard1-0/+1
The SI5341 clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation. This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidates to trigger that parent change are either the assigned-clock-parents device tree property or a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate. The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock. Similarly, it doesn't look like the device tree using that clock driver uses any of the assigned-clock properties on that clock. So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent(). The latter case would be equivalent to setting the determine_rate implementation to clk_hw_determine_rate_no_reparent(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-19-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-09clk: qoriq: Add a determine_rate hookMaxime Ripard1-0/+1
The Qoriq mux clocks implement a mux with a set_parent hook, but doesn't provide a determine_rate implementation. This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidates to trigger that parent change are either the assigned-clock-parents device tree property or a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate. The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock. Similarly, it doesn't look like the device tree using that clock driver uses any of the assigned-clock properties on that clock. So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent(). The latter case would be equivalent to setting the determine_rate implementation to clk_hw_determine_rate_no_reparent(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-18-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-09clk: lochnagar: Add a determine_rate hookMaxime Ripard1-0/+1
The lochnagar clocks implement a mux with a set_parent hook, but doesn't provide a determine_rate implementation. This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidates to trigger that parent change are either the assigned-clock-parents device tree property or a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate. The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock. Since there's no upstream device tree using that driver, it's a bit hard to tell if it uses the assigned-clock properties. The binding and its example uses them though, so it's likely that the author intent was to force the parent through the device tree and prevent any reparenting but through an explicit call to clk_set_parent(). This case is equivalent to setting the determine_rate implementation to clk_hw_determine_rate_no_reparent(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. Cc: Charles Keepax <ckeepax@opensource.cirrus.com> Cc: Richard Fitzgerald <rf@opensource.cirrus.com> Cc: patches@opensource.cirrus.com Tested-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-17-971d5077e7d2@cerno.tech | Reported-by: kernel test robot <lkp@intel.com>: | Reported-by: kernel test robot <lkp@intel.com>: Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-09clk: lmk04832: clkout: Add a determine_rate hookMaxime Ripard1-0/+1
The LKM04832 "CLKOUT" clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation. This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate. The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock. So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent(). The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line. Since the CLK_SET_RATE_NO_REPARENT flag was already set though, it seems unlikely. Reviewed-by: Liam Beguin <liambeguin@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-16-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-09clk: k210: mux: Add a determine_rate hookMaxime Ripard1-0/+1
The K210 mux clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation. This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidates to trigger that parent change are either the assigned-clock-parents device tree property or a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate. The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock. Similarly, it doesn't look like the device tree using that clock driver uses any of the assigned-clock properties on that clock. So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent(). The latter case would be equivalent to setting the determine_rate implementation to clk_hw_determine_rate_no_reparent(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-15-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-09clk: k210: aclk: Add a determine_rate hookMaxime Ripard1-0/+1
The K210 ACLK clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation. This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidates to trigger that parent change are either the assigned-clock-parents device tree property or a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate. The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock. Similarly, it doesn't look like the device tree using that clock driver uses any of the assigned-clock properties on that clock. So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent(). The latter case would be equivalent to setting the determine_rate implementation to clk_hw_determine_rate_no_reparent(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-14-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-09clk: k210: pll: Add a determine_rate hookMaxime Ripard1-0/+1
The K210 PLL clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation. This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidates to trigger that parent change are either the assigned-clock-parents device tree property or a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate. The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock. Similarly, it doesn't look like the device tree using that clock driver uses any of the assigned-clock properties on that clock. So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent(). The latter case would be equivalent to setting the determine_rate implementation to clk_hw_determine_rate_no_reparent(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-13-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-09clk: cdce706: Add a determine_rate hookMaxime Ripard1-0/+1
The cdce706 "clkin" clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation. This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidates to trigger that parent change are either the assigned-clock-parents device tree property or a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate. The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock. Similarly, it doesn't look like the device tree using that clock driver uses any of the assigned-clock properties on that clock. So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent(). The latter case would be equivalent to setting the determine_rate implementation to clk_hw_determine_rate_no_reparent(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line. Cc: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-12-971d5077e7d2@cerno.tech | Reported-by: kernel test robot <lkp@intel.com>: Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-09clk: berlin: div: Add a determine_rate hookMaxime Ripard1-0/+1
The Berlin2 divider clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation. This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidates to trigger that parent change are either the assigned-clock-parents device tree property or a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate. The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock. Similarly, it doesn't look like the device tree using that clock driver uses any of the assigned-clock properties on that clock. So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent(). The latter case would be equivalent to setting the determine_rate implementation to clk_hw_determine_rate_no_reparent(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-11-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-09clk: at91: sckc: Add a determine_rate hookMaxime Ripard1-0/+1
The SAM9x5 slow clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation. This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidates to trigger that parent change are either the assigned-clock-parents device tree property or a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate. The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock. Similarly, it doesn't look like the device tree using that clock driver uses any of the assigned-clock properties on that clock. So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent(). The latter case would be equivalent to setting the determine_rate implementation to clk_hw_determine_rate_no_reparent(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line. Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Claudiu Beznea <claudiu.beznea@microchip.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-10-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-09clk: at91: main: Add a determine_rate hookMaxime Ripard1-0/+1
The SAM9x5 main clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation. This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidates to trigger that parent change are either the assigned-clock-parents device tree property or a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate. The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock. Similarly, it doesn't look like the device tree using that clock driver uses any of the assigned-clock properties on that clock. So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent(). The latter case would be equivalent to setting the determine_rate implementation to clk_hw_determine_rate_no_reparent(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line. Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Claudiu Beznea <claudiu.beznea@microchip.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-9-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-09clk: actions: composite: Add a determine_rate hook for pass clkMaxime Ripard1-0/+1
The Actions "Pass" clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation. This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidates to trigger that parent change are either the assigned-clock-parents device tree property or a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate. The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock. Similarly, it doesn't look like the device tree using that clock driver uses any of the assigned-clock properties. So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent(). The latter case would be equivalent to setting the determine_rate implementation to clk_hw_determine_rate_no_reparent(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line. Cc: "Andreas Färber" <afaerber@suse.de> Cc: Manivannan Sadhasivam <mani@kernel.org> Cc: linux-actions@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-8-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-09clk: test: Add a determine_rate hookMaxime Ripard1-0/+17
The single parent clock in our kunit tests implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation. This is not entirely unexpected, since its whole purpose it to have a single parent. When determine_rate is missing, and since CLK_SET_RATE_PARENT is set for all its instances, the default behaviour of the framework will be to forward it to the current parent. This is totally fine as far as the tests are concerned, but we'll start to mandate a determine_rate implementation when set_parent is set, so let's fill it with __clk_mux_determine_rate() which will have the same behavior. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-7-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-09clk: nodrv: Add a determine_rate hookMaxime Ripard1-0/+7
The nodrv clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation. Even though it's a mock clock and the missing function is harmless, we'll start to require a determine_rate implementation when set_parent is set, so let's fill it. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-6-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-09clk: lan966x: Remove unused round_rate hookMaxime Ripard1-17/+0
The lan966x driver registers a gck clock with both a determine_rate and a round_rate implementation. Both are equivalent, and are only called by clk_core_determine_round_nolock() which favors determine_rate. Thus, lan966x_gck_round_rate() is never called, so we can just remove it. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-5-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-09clk: Introduce clk_hw_determine_rate_no_reparent()Stephen Boyd2-0/+171
Some clock drivers do not want to allow any reparenting on a given clock, but usually do so by not providing any determine_rate implementation. Whenever we call clk_round_rate() or clk_set_rate(), this leads to clk_core_can_round() returning false and thus the rest of the function either forwarding the rate request to its current parent if CLK_SET_RATE_PARENT is set, or just returning the current clock rate. This behaviour happens implicitly, and as we move forward to making a determine_rate implementation required for muxes, we need some way to explicitly opt-in for that behaviour. Fortunately, this is exactly what the clk_core_determine_rate_no_reparent() function is doing, so we can simply make it available to drivers. Cc: Abel Vesa <abelvesa@kernel.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: "Andreas Färber" <afaerber@suse.de> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Charles Keepax <ckeepax@opensource.cirrus.com> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Chen-Yu Tsai <wenst@chromium.org> Cc: Chunyan Zhang <zhang.lyra@gmail.com> Cc: Claudiu Beznea <claudiu.beznea@microchip.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@gmail.com> Cc: David Lechner <david@lechnology.com> Cc: Dinh Nguyen <dinguyen@kernel.org> Cc: Fabio Estevam <festevam@gmail.com> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: Kishon Vijay Abraham I <kishon@kernel.org> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Luca Ceresoli <luca.ceresoli@bootlin.com> Cc: Manivannan Sadhasivam <mani@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Markus Schneider-Pargmann <msp@baylibre.com> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Mikko Perttunen <mperttunen@nvidia.com> Cc: Miles Chen <miles.chen@mediatek.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Orson Zhai <orsonzhai@gmail.com> Cc: Paul Cercueil <paul@crapouillou.net> Cc: Peng Fan <peng.fan@nxp.com> Cc: Peter De Schrijver <pdeschrijver@nvidia.com> Cc: Prashant Gaikwad <pgaikwad@nvidia.com> Cc: Richard Fitzgerald <rf@opensource.cirrus.com> Cc: Samuel Holland <samuel@sholland.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Sekhar Nori <nsekhar@ti.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Takashi Iwai <tiwai@suse.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Vinod Koul <vkoul@kernel.org> Cc: dri-devel@lists.freedesktop.org Cc: linux-actions@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mips@vger.kernel.org Cc: linux-phy@lists.infradead.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-rtc@vger.kernel.org Cc: linux-stm32@st-md-mailman.stormreply.com Cc: linux-sunxi@lists.linux.dev Cc: linux-tegra@vger.kernel.org Cc: NXP Linux Team <linux-imx@nxp.com> Cc: patches@opensource.cirrus.com Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-4-971d5077e7d2@cerno.tech | Reported-by: kernel test robot <lkp@intel.com>:
2023-06-09clk: Move no reparent case into a separate functionStephen Boyd1-32/+43
We'll need to turn the code in clk_mux_determine_rate_flags() to deal with CLK_SET_RATE_NO_REPARENT into a helper clock drivers will be able to use if they don't want to allow reparenting. Cc: Abel Vesa <abelvesa@kernel.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: "Andreas Färber" <afaerber@suse.de> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Charles Keepax <ckeepax@opensource.cirrus.com> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Chen-Yu Tsai <wenst@chromium.org> Cc: Chunyan Zhang <zhang.lyra@gmail.com> Cc: Claudiu Beznea <claudiu.beznea@microchip.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@gmail.com> Cc: David Lechner <david@lechnology.com> Cc: Dinh Nguyen <dinguyen@kernel.org> Cc: Fabio Estevam <festevam@gmail.com> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: Kishon Vijay Abraham I <kishon@kernel.org> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Luca Ceresoli <luca.ceresoli@bootlin.com> Cc: Manivannan Sadhasivam <mani@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Markus Schneider-Pargmann <msp@baylibre.com> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Mikko Perttunen <mperttunen@nvidia.com> Cc: Miles Chen <miles.chen@mediatek.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Orson Zhai <orsonzhai@gmail.com> Cc: Paul Cercueil <paul@crapouillou.net> Cc: Peng Fan <peng.fan@nxp.com> Cc: Peter De Schrijver <pdeschrijver@nvidia.com> Cc: Prashant Gaikwad <pgaikwad@nvidia.com> Cc: Richard Fitzgerald <rf@opensource.cirrus.com> Cc: Samuel Holland <samuel@sholland.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Sekhar Nori <nsekhar@ti.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Takashi Iwai <tiwai@suse.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Vinod Koul <vkoul@kernel.org> Cc: dri-devel@lists.freedesktop.org Cc: linux-actions@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mips@vger.kernel.org Cc: linux-phy@lists.infradead.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-rtc@vger.kernel.org Cc: linux-stm32@st-md-mailman.stormreply.com Cc: linux-sunxi@lists.linux.dev Cc: linux-tegra@vger.kernel.org Cc: NXP Linux Team <linux-imx@nxp.com> Cc: patches@opensource.cirrus.com Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-3-971d5077e7d2@cerno.tech
2023-06-09clk: test: Fix type sign of rounded rate variablesMaxime Ripard1-5/+6
clk_round_rate() may return a negative error code, but most of the variables we defined to store its returned value are unsigned. This obviously leads to issues on error. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-2-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-09clk: Export clk_hw_forward_rate_request()Maxime Ripard1-0/+1
Commit 262ca38f4b6e ("clk: Stop forwarding clk_rate_requests to the parent") introduced the public clk_hw_forward_rate_request() function, but didn't export the symbol. Make sure it's the case. Fixes: 262ca38f4b6e ("clk: Stop forwarding clk_rate_requests to the parent") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-1-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-09clk: vc7: Use device_get_match_data() instead of of_device_get_match_data()Marek Vasut1-1/+2
Use device_get_match_data() which, unlike of_device_get_match_data(), is compatible with other firmware interfaces than just OF. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Link: https://lore.kernel.org/r/20230514191959.706269-2-marek.vasut+renesas@mailbox.org Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-09clk: vc5: Use device_get_match_data() instead of of_device_get_match_data()Marek Vasut1-1/+2
Use device_get_match_data() which, unlike of_device_get_match_data(), is compatible with other firmware interfaces than just OF. Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Link: https://lore.kernel.org/r/20230514191959.706269-1-marek.vasut+renesas@mailbox.org Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-05clk: renesas: rzg2l: Convert to readl_poll_timeout_atomic()Geert Uytterhoeven1-11/+5
Use readl_poll_timeout_atomic() instead of open-coding the same operation. As typically no retries are needed, 10 µs is a suitable timeout value. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/900543d4b9abc1004e6aecdb676f23e5508ae96f.1685692810.git.geert+renesas@glider.be
2023-06-05clk: renesas: mstp: Convert to readl_poll_timeout_atomic()Geert Uytterhoeven1-11/+7
Use readl_poll_timeout_atomic() instead of open-coding the same operation. As typically no retries are needed, 10 µs is a suitable timeout value. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/bce7d0bdd80c800aa150f1868b610b7d94f4cc66.1685692810.git.geert+renesas@glider.be
2023-06-05clk: renesas: cpg-mssr: Convert to readl_poll_timeout_atomic()Geert Uytterhoeven1-20/+11
Use readl_poll_timeout_atomic() instead of open-coding the same operation. As typically no retries are needed, 10 µs is a suitable timeout value. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/832d29fd9aa3239ea949535309d2bdb003d40c9e.1685692810.git.geert+renesas@glider.be
2023-06-05clk: nuvoton: Add clock driver for ma35d1 clock controllerJacky Huang7-0/+1454
The clock controller generates clocks for the whole chip, including system clocks and all peripheral clocks. This driver support ma35d1 clock gating, divider, and individual PLL configuration. There are 6 PLLs in ma35d1 SoC: - CA-PLL for the two Cortex-A35 CPU clock - SYS-PLL for system bus, which comes from the companion MCU and cannot be programmed by clock controller. - DDR-PLL for DDR - EPLL for GMAC and GFX, Display, and VDEC IPs. - VPLL for video output pixel clock - APLL for SDHC, I2S audio, and other IPs. CA-PLL has only one operation mode. DDR-PLL, EPLL, VPLL, and APLL are advanced PLLs which have 3 operation modes: integer mode, fraction mode, and spread specturm mode. Signed-off-by: Jacky Huang <ychuang3@nuvoton.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-05-30clk: meson: a1: add Amlogic A1 Peripherals clock controller driverDmitry Rokosov4-0/+2367
Introduce Peripherals clock controller for Amlogic A1 SoC family. A1 SoC has four clock controllers on the board: PLL, Peripherals, CPU, and Audio. This patchset adds support for Amlogic A1 Peripherals clock driver and allows to generate clocks for all A1 SoC peripheral IPs. Signed-off-by: Jian Hu <jian.hu@amlogic.com> Signed-off-by: Dmitry Rokosov <ddrokosov@sberdevices.ru> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/20230523135351.19133-7-ddrokosov@sberdevices.ru Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
2023-05-30clk: meson: a1: add Amlogic A1 PLL clock controller driverDmitry Rokosov4-0/+414
Introduce PLL clock controller for Amlogic A1 SoC family. The clock unit is an APB slave module that is designed for generating all of the internal and system clocks. The SoC uses an external 24MHz crystal; there are 4 internal PLLs: SYS_PLL/HIFI_PLL/USB_PLL/(FIXPLL), these PLLs generate 27 clock sources. Signed-off-by: Jian Hu <jian.hu@amlogic.com> Signed-off-by: Dmitry Rokosov <ddrokosov@sberdevices.ru> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/20230523135351.19133-5-ddrokosov@sberdevices.ru Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
2023-05-30clk: meson: introduce new pll power-on sequence for A1 SoC familyDmitry Rokosov2-0/+25
Modern meson PLL IPs are a little bit different from early known PLLs. The main difference is located in the init/enable/disable sequences; the rate logic is the same. In A1 PLL, the PLL enable sequence is different, so add new optional pll reg bits and use the new power-on sequence to enable the PLL: 1. enable the pll, delay for 10us 2. enable the pll self-adaption current module, delay for 40us 3. enable the lock detect module Signed-off-by: Jian Hu <jian.hu@amlogic.com> Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Dmitry Rokosov <ddrokosov@sberdevices.ru> Link: https://lore.kernel.org/r/20230523135351.19133-3-ddrokosov@sberdevices.ru Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
2023-05-30clk: meson: make pll rst bit as optionalDmitry Rokosov1-7/+17
Compared with the previous SoCs, self-adaption current module is newly added for A1, and there is no reset parameter except the fixed pll. Since we use clk-pll generic driver for A1 pll implementation, rst bit should be optional to support new behavior. Signed-off-by: Jian Hu <jian.hu@amlogic.com> Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Dmitry Rokosov <ddrokosov@sberdevices.ru> Link: https://lore.kernel.org/r/20230523135351.19133-2-ddrokosov@sberdevices.ru Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
2023-05-27clk: qcom: gpucc-sm8550: Add support for graphics clock controllerJagadeesh Kona3-0/+620
Add support for gpucc driver on SM8550, which provides clocks for the graphics subsystem. Co-developed-by: Taniya Das <quic_tdas@quicinc.com> Signed-off-by: Taniya Das <quic_tdas@quicinc.com> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230524181800.28717-3-quic_jkona@quicinc.com
2023-05-27clk: qcom: Add support for SM8450 GPUCCKonrad Dybcio3-0/+775
The GPUCC manages the clocks for the Adreno GPU found on the sm8450 SoCs. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230517-topic-waipio-gpucc-v1-4-4f40e282af1d@linaro.org
2023-05-27clk: qcom: gcc-sm8450: Enable hw_clk_ctrlKonrad Dybcio1-0/+39
Enable hardware clock control on all RCGs. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230517-topic-waipio-gpucc-v1-3-4f40e282af1d@linaro.org
2023-05-27clk: qcom: rcg2: Make hw_clk_ctrl toggleableKonrad Dybcio2-0/+4
Certain SoCs use the HW_CLK_CTRL feature on some of the clocks they host. This allows the clocks to be turned on automatically when a downstream branch tries to change rate or config. Make it togglable so that we can utilize this. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230517-topic-waipio-gpucc-v1-2-4f40e282af1d@linaro.org
2023-05-26clk: qcom: mmcc-msm8974: use clk_rcg2_shared_ops for mdp_clk_src clockDmitry Baryshkov1-1/+1
The mdp_clk_src clock should not be turned off. Instead it should be 'parked' to the XO, as most of other mdp_clk_src clocks. Fix that by using the clk_rcg2_shared_ops. Fixes: d8b212014e69 ("clk: qcom: Add support for MSM8974's multimedia clock controller (MMCC)") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by: Luca Weiss <luca@z3ntu.xyz> Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230507175335.2321503-1-dmitry.baryshkov@linaro.org
2023-05-26clk: qcom: ipq5332: fix the order of SLEEP_CLK and XO clockKathiravan T1-1/+1
The order of DT_SLEEP_CLK and DT_XO are swapped and it is incorrect. Due to which the clocks for which the parent should be XO is having parent as SLEEP_CLK and vice versa. So fix the same by re-ordering the entries. Fixes: 3d89d52970fd ("clk: qcom: add Global Clock controller (GCC) driver for IPQ5332 SoC") Reported-by: Devi Priya <quic_devipriy@quicinc.com> Signed-off-by: Kathiravan T <quic_kathirav@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230417105607.4091-1-quic_kathirav@quicinc.com
2023-05-26clk: qcom: ipq5332: fix the src parameter in ftbl_gcc_apss_axi_clk_srcKathiravan T1-1/+1
480MHz is derived from P_GPLL4_OUT_AUX not from P_GPLL4_OUT_MAIN. Update the freq_tbl with the correct src. Fixes: 3d89d52970fd ("clk: qcom: add Global Clock controller (GCC) driver for IPQ5332 SoC") Reported-by: Manikanta Mylavarapu <quic_mmanikan@quicinc.com> Signed-off-by: Kathiravan T <quic_kathirav@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230417044342.9406-1-quic_kathirav@quicinc.com
2023-05-26clk: qcom: dispcc-qcm2290: Fix GPLL0_OUT_DIV handlingKonrad Dybcio1-3/+4
GPLL0_OUT_DIV (.fw_name = "gcc_disp_gpll0_div_clk_src") was previously made to reuse the same parent enum entry as GPLL0_OUT_MAIN (.fw_name = "gcc_disp_gpll0_clk_src") in parent_map_2. Resolve it by introducing its own entry in the parent enum and correctly assigning it in disp_cc_parent_map_2[]. Fixes: cc517ea3333f ("clk: qcom: Add display clock controller driver for QCM2290") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230412-topic-qcm_dispcc-v2-2-bce7dd512fe4@linaro.org
2023-05-26clk: qcom: dispcc-qcm2290: Fix BI_TCXO_AO handlingKonrad Dybcio1-2/+3
BI_TCXO_AO (.fw_name = "bi_tcxo_ao") was previously made to reuse the same parent enum entry as BI_TCXO (.fw_name = "bi_tcxo") in parent_map_2. Resolve it by introducing its own entry in the parent enum and correctly assigning it in disp_cc_parent_map_2[]. Fixes: cc517ea3333f ("clk: qcom: Add display clock controller driver for QCM2290") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230412-topic-qcm_dispcc-v2-1-bce7dd512fe4@linaro.org
2023-05-26clk: qcom: ipq6018: fix networking resetsRobert Marko1-16/+16
Networking resets in IPQ6018 all use bitmask as they require multiple bits to be set and cleared instead of a single bit. So, current networking resets have the same register and bit 0 set which is clearly incorrect. Fixes: d9db07f088af ("clk: qcom: Add ipq6018 Global Clock Controller support") Signed-off-by: Robert Marko <robimarko@gmail.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230526190855.2941291-2-robimarko@gmail.com
2023-05-26clk: qcom: gcc-ipq6018: update UBI32 PLLRobert Marko1-1/+6
Update the UBI32 alpha PLL config to the latest values from the downstream QCA 5.4 kernel. Signed-off-by: Robert Marko <robimarko@gmail.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230526190855.2941291-1-robimarko@gmail.com
2023-05-26clk: qcom: apss-ipq-pll: Add support for IPQ9574Devi Priya1-0/+19
Add the compatible and configuration values for A73 Huayra PLL found on IPQ9574. Co-developed-by: Praveenkumar I <quic_ipkumar@quicinc.com> Signed-off-by: Praveenkumar I <quic_ipkumar@quicinc.com> Signed-off-by: Devi Priya <quic_devipriy@quicinc.com> Acked-by: Stephen Boyd <sboyd@kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230406061314.10916-3-quic_devipriy@quicinc.com
2023-05-26ARM: pxa: fix missing-prototypes warningsArnd Bergmann2-1/+4
The PXA platform has a number of configurations that end up with a warning like these when building with W=1: drivers/hwmon/max1111.c:83:5: error: no previous prototype for 'max1111_read_channel' [-Werror=missing-prototypes] arch/arm/mach-pxa/reset.c:86:6: error: no previous prototype for 'pxa_restart' [-Werror=missing-prototypes] arch/arm/mach-pxa/mfp-pxa2xx.c:254:5: error: no previous prototype for 'keypad_set_wake' [-Werror=missing-prototypes] drivers/clk/pxa/clk-pxa25x.c:70:14: error: no previous prototype for 'pxa25x_get_clk_frequency_khz' [-Werror=missing-prototypes] drivers/clk/pxa/clk-pxa25x.c:325:12: error: no previous prototype for 'pxa25x_clocks_init' [-Werror=missing-prototypes] drivers/clk/pxa/clk-pxa27x.c:74:14: error: no previous prototype for 'pxa27x_get_clk_frequency_khz' [-Werror=missing-prototypes] drivers/clk/pxa/clk-pxa27x.c:102:6: error: no previous prototype for 'pxa27x_is_ppll_disabled' [-Werror=missing-prototypes] drivers/clk/pxa/clk-pxa27x.c:470:12: error: no previous prototype for 'pxa27x_clocks_init' [-Werror=missing-prototypes] arch/arm/mach-pxa/pxa27x.c:44:6: error: no previous prototype for 'pxa27x_clear_otgph' [-Werror=missing-prototypes] arch/arm/mach-pxa/pxa27x.c:58:6: error: no previous prototype for 'pxa27x_configure_ac97reset' [-Werror=missing-prototypes] arch/arm/mach-pxa/spitz_pm.c:170:15: error: no previous prototype for 'spitzpm_read_devdata' [-Werror=missing-prototypes] The problem is that there is a declaration for each of these, but it's only seen by the caller and not the callee. Moving these into appropriate header files ensures that both use the same calling conventions and it avoids the warnings. Acked-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20230516153109.514251-11-arnd@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-05-25clk: qcom: restrict drivers per ARM/ARM64Krzysztof Kozlowski1-0/+71
There is no point to allow selecting clock controller drivers for Qualcomm ARMv7 SoCs when building ARM64 kernel, and vice versa. This makes kernel configuration more difficult as many do not remember the Qualcomm SoCs model names/numbers. No features should be lost because: 1. There won't be a single image for ARMv7 and ARMv8/9 SoCs. 2. Newer ARMv8/9 SoCs won't be running in arm32 emulation mode. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230514114711.18258-1-krzysztof.kozlowski@linaro.org
2023-05-25clk: qcom: Add GCC driver support for SDX75Imran Shaik3-0/+2979
Add Global Clock Controller (GCC) support for SDX75 platform. Signed-off-by: Imran Shaik <quic_imrashai@quicinc.com> Signed-off-by: Taniya Das <quic_tdas@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230512122347.1219-6-quic_tdas@quicinc.com
2023-05-25clk: qcom: rpmh: Add RPMH clocks support for SDX75Imran Shaik1-0/+19
Add support for RPMH clocks for SDX75 platform. Signed-off-by: Imran Shaik <quic_imrashai@quicinc.com> Signed-off-by: Taniya Das <quic_tdas@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230512122347.1219-5-quic_tdas@quicinc.com
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-24 12:49:43 +0300