kernel/drivers/clk/davinci, branch linux-6.9.y

clk: Use device_get_match_data()

2023-10-24T03:16:21Z

Use preferred device_get_match_data() instead of of_match_device() to get the driver match data. With this, adjust the includes to explicitly include the correct headers. Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20231006213959.334439-1-robh@kernel.org Reviewed-by: Dmitry Baryshkov #msm part Acked-by: Krzysztof Kozlowski # Samsung Acked-by: David Lechner Acked-by: Chanwoo Choi Acked-by: Charles Keepax Reviewed-by: Bjorn Andersson Signed-off-by: Stephen Boyd

clk: da8xx: clk48: Switch to determine_rate

2023-06-09T01:39:34Z

The TI DA8xx USB0 clk48 clocks 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 driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent. However, It's hard to tell whether it's been done on purpose or not. Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on. Cc: David Lechner Cc: Sekhar Nori Acked-by: David Lechner Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-57-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd

clk: davinci: da8xx-cfgchip: Add a determine_rate hook

2023-06-09T01:39:28Z

The Davinci DA8xxx cfgchip "clk48" 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: David Lechner Cc: Sekhar Nori Acked-by: David Lechner Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-25-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd

clk: davinci: da8xx-cfgchip: Add a determine_rate hook

2023-06-09T01:39:28Z

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 Cc: Sekhar Nori Acked-by: David Lechner Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-24-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd

clk: remove davinci dm3xx drivers

2023-01-12T09:53:12Z

The davinci dm3xx machines are all removed, so the clk driver is no longer needed. The da8xx platforms are now using DT exclusively, so those drivers remain untouched. Reviewed-by: David Lechner Acked-by: Linus Walleij Acked-by: Bartosz Golaszewski Acked-by: Stephen Boyd Signed-off-by: Arnd Bergmann

ARM: davinci: drop DAVINCI_DMxxx references

2023-01-12T09:53:12Z

Support for all the dm3xx/dm64xx SoCs is no longer available, so drop all other references to those. Acked-by: Stephen Boyd Signed-off-by: Arnd Bergmann

Merge branches 'clk-fixed-rate', 'clk-spreadtrum', 'clk-pxa' and 'clk-ti' into clk-next

2022-10-04T17:54:14Z

- More devm helpers for fixed rate registration - Add Spreadtrum UMS512 SoC clk support - Various PXA168 clk driver fixes * clk-fixed-rate: clk: fixed-rate: add devm_clk_hw_register_fixed_rate clk: asm9260: use parent index to link the reference clock * clk-spreadtrum: clk: sprd: Add clocks support for UMS512 * clk-pxa: clk: pxa: add a check for the return value of kzalloc() clk: mmp: pxa168: control shared SDH bits with separate clock dt-bindings: marvell,pxa168: add clock ids for SDH AXI clocks clk: mmp: pxa168: add clocks for SDH2 and SDH3 dt-bindings: marvell,pxa168: add clock id for SDH3 clk: mmp: pxa168: fix GPIO clock enable bits clk: mmp: pxa168: add muxes for more peripherals clk: mmp: pxa168: fix incorrect parent clocks clk: mmp: pxa168: fix const-correctness clk: mmp: pxa168: add new clocks for peripherals dt-bindings: marvell,pxa168: add clock ids for additional dividers clk: mmp: pxa168: fix incorrect dividers clk: mmp: pxa168: add additional register defines * clk-ti: clk: davinci: cfgchip: Use dev_err_probe() helper clk: davinci: pll: fix spelling typo in comment MAINTAINERS: add header file to TI DAVINCI SERIES CLOCK DRIVER

clk: davinci: cfgchip: Use dev_err_probe() helper

2022-09-30T20:47:21Z

dev_err() can be replace with dev_err_probe() which will check if error code is -EPROBE_DEFER. Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20220913032228.985852-1-yangyingliang@huawei.com Reviewed-by: David Lechner Signed-off-by: Stephen Boyd

clk: davinci: pll: fix spelling typo in comment

2022-09-30T20:46:22Z

Fix spelling typo in comment. Reported-by: k2ci Signed-off-by: Jiangshan Yi Link: https://lore.kernel.org/r/20220905065833.1831473-1-13667453960@163.com Reviewed-by: David Lechner Signed-off-by: Stephen Boyd

clk: davinci: remove PLL and PSC clocks for DaVinci DM644x and DM646x

2022-09-01T01:07:56Z

Commit 7dd33764486d ("ARM: davinci: Delete DM644x board files") and commit b4aed01de486 ("ARM: davinci: Delete DM646x board files") removes the support for DaVinci DM644x and DM646x boards. Hence, remove the PLL and PSC clock descriptions for those boards as well. Signed-off-by: Lukas Bulwahn Link: https://lore.kernel.org/r/20220720082934.17741-1-lukas.bulwahn@gmail.com Reviewed-by: David Lechner Reviewed-by: Linus Walleij Signed-off-by: Stephen Boyd