aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/drivers/clk/bcm/clk-raspberrypi.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2023-06-14clk: bcm: rpi: Fix off by one in raspberrypi_discover_clocks()Dan Carpenter1-2/+2
Smatch detected an off by one in this code: drivers/clk/bcm/clk-raspberrypi.c:374 raspberrypi_discover_clocks() error: buffer overflow 'data->hws' 16 <= 16 The data->hws[] array has RPI_FIRMWARE_NUM_CLK_ID elements so the > comparison needs to changed to >=. Fixes: 12c90f3f27bb ("clk: bcm: rpi: Add variant structure") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/5a850b08-d2f5-4794-aceb-a6b468965139@kili.mountain Reviewed-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-03-28clk: bcm: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230312161512.2715500-6-u.kleine-koenig@pengutronix.de Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-10-28firmware: raspberrypi: Move the clock IDs to the firmware headerMaxime Ripard1-19/+0
We'll need the clock IDs in more drivers than just the clock driver from now on, so let's move them in the firmware header. Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20220815-rpi-fix-4k-60-v5-2-fe9e7ac8b111@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-10-08Merge tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linuxLinus Torvalds1-0/+11
Pull clk updates from Stephen Boyd: "We have some late breaking reports that a patch series to rework clk rate range support broke boot on some devices, so I've left that branch out of this. Hopefully we can get to that next week, or punt on it and let it bake another cycle. That means we don't really have any changes to the core framework this time around besides a few typo fixes. Instead this is all clk driver updates and fixes. The usual suspects are here (again), with Qualcomm dominating the diffstat. We look to have gained support for quite a few new Qualcomm SoCs and Dmitry worked on updating many of the existing Qualcomm drivers to use clk_parent_data. After that we have MediaTek drivers getting some much needed updates, in particular to support GPU DVFS. There are also quite a few Samsung clk driver patches, but that's mostly because there was a maintainer change and so last release we missed some of those patches. Overall things look normal, but I'm slowly reviewing core framework code nowadays and that shows given the rate range patches had to be yanked last minute. Let's hope this situation changes soon. New Drivers: - Support for Renesas VersaClock7 clock generator family - Add Spreadtrum UMS512 SoC clk support - New clock drivers for MediaTek Helio X10 MT6795 - Display clks for Qualcomm SM6115, SM8450 - GPU clks for Qualcomm SC8280XP - Qualcomm MSM8909 and SM6375 global and SMD RPM clk drivers Deleted Drivers: - Remove DaVinci DM644x and DM646x clk driver support Updates: - Convert Baikal-T1 CCU driver to platform driver - Split reset support out of primary Baikal-T1 CCU driver - Add some missing clks required for RPiVid Video Decoder on RaspberryPi - Mark PLLC critical on bcm2835 - More devm helpers for fixed rate registration - Various PXA168 clk driver fixes - Add resets for MediaTek MT8195 PCIe and USB - Miscellaneous of_node_put() fixes - Nuke dt-bindings/clk path (again) by moving headers to dt-bindings/clock - Convert gpio-clk-gate binding to YAML - Various fixes to AMD/Xilinx Zynqmp clk driver - Graduate AMD/Xilinx "clocking wizard" driver from staging - Add missing DPI1_HDMI clock in MT8195 VDOSYS1 - Clock driver changes to support GPU DVFS on MT8183, MT8192, MT8195 - Fix GPU clock topology on MT8195 - Propogate rate changes from GPU clock gate up the tree - Clock mux notifiers for GPU-related PLLs - Conversion of more "simple" drivers to mtk_clk_simple_probe() - Hook up mtk_clk_simple_remove() for "simple" MT8192 clock drivers - Fixes to previous |struct clk| to |struct clk_hw| conversion on MediaTek - Shrink MT8192 clock driver by deduplicating clock parent lists - Change order between 'sim_enet_root_clk' and 'enet_qos_root_clk' clocks for i.MX8MP - Drop unnecessary newline in i.MX8MM dt-bindings - Add more MU1 and SAI clocks dt-bindings Ids - Introduce slice busy bit check for i.MX93 composite clock - Introduce white list bit check for i.MX93 composite clock - Add new i.MX93 clock gate - Add MU1 and MU2 clocks to i.MX93 clock provider - Add SAI IPG clocks to i.MX93 clock provider - add generic clocks for U(S)ART available on SAMA5D2 SoCs - reset controller support for Polarfire clocks - .round_rate and .set rate support for clk-mpfs - code cleanup for clk-mpfs - PLL support for PolarFire SoC's Clock Conditioning Circuitry - Add watchdog, I2C, pin control/GPIO, and Ethernet clocks on R-Car V4H - Add SDHI, Timer (CMT/TMU), and SPI (MSIOF) clocks on R-Car S4-8 - Add I2C clocks and resets on RZ/V2M - Document clock support for the RZ/Five SoC - mux-variant clock using the table variant to select parents - clock controller for the rv1126 soc - conversion of rk3128 to yaml and relicensing of the yaml bindings to gpl2+MIT (following dt-binding guildelines) - Exynos7885: add FSYS, TREX and MFC clock controllers - Exynos850: add IS and AUD (audio) clock controllers with bindings - ExynosAutov9: add FSYS clock controllers with bindings - ExynosAutov9: correct clock IDs in bindings of Peric 0 and 1 clock controllers, due to duplicated entries. This is an acceptable ABI break: recently developed/added platform so without legacies, acked by known users/developers - ExynosAutov9: add few missing Peric 0/1 gates - ExynosAutov9: correct register offsets of few Peric 0/1 clocks - Minor code improvements (use of_device_get_match_data() helper, code style) - Add Krzysztof Kozlowski as co-maintainer of Samsung SoC clocks, as he already maintainers that architecture/platform - Keep Qualcomm GDSCs enabled when PWRSTS_RET flag is there, solving retention issues during suspend of USB on Qualcomm sc7180/sc7280 and SC8280XP - Qualcomm SM6115 and QCM2260 are moved to reuse PLL configuration - Qualcomm SDM660 SDCC1 moved to floor clk ops - Support for the APCS PLLs for Qualcomm IPQ8064, IPQ8074 and IPQ6018 was added/fixed - The Qualcomm MSM8996 CPU clocks are updated with support for ACD - Support for Qualcomm SDM670 GCC and RPMh clks was added - Transition to parent_data, parent_hws and use of ARRAY_SIZE() for num_parents was done for many Qualcomm SoCs - Support for per-reset defined delay on Qualcomm was introduced" * tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: (283 commits) clk: qcom: gcc-sm6375: Ensure unsigned long type clk: qcom: gcc-sm6375: Remove unused variables clk: qcom: kpss-xcc: convert to parent data API clk: introduce (devm_)hw_register_mux_parent_data_table API clk: allow building lan966x as a module clk: clk-xgene: simplify if-if to if-else clk: ast2600: BCLK comes from EPLL clk: clocking-wizard: Depend on HAS_IOMEM clk: clocking-wizard: Use dev_err_probe() helper clk: nxp: fix typo in comment clk: pxa: add a check for the return value of kzalloc() clk: vc5: Add support for IDT/Renesas VersaClock 5P49V6975 dt-bindings: clock: vc5: Add 5P49V6975 clk: mvebu: armada-37xx-tbg: Remove the unneeded result variable clk: ti: dra7-atl: Fix reference leak in of_dra7_atl_clk_probe clk: Renesas versaclock7 ccf device driver dt-bindings: Renesas versaclock7 device tree bindings clk: ti: Balance of_node_get() calls for of_find_node_by_name() clk: imx: scu: fix memleak on platform_device_add() fails clk: vc5: Use regmap_{set,clear}_bits() where appropriate ...
2022-09-30clk: bcm: rpi: Add support for VEC clockDom Cobley1-0/+5
Platform driver clk-bcm2835 gets an inaccurate clock for VEC (107MHz). Export VEC clock trough clk-raspberrypi which uses the right PLL to get an accurate 108MHz. Signed-off-by: Dom Cobley <popcornmix@gmail.com> [iivanov: Adapted on top of v5.17-rc6] Signed-off-by: Ivan T. Ivanov <iivanov@suse.de> Link: https://lore.kernel.org/r/20220829152154.147250-4-iivanov@suse.de Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-30clk: bcm: rpi: Handle pixel clock in firmwareIvan T. Ivanov1-0/+3
The clk-bcm2835 handling of the pixel clock does not function correctly when the HDMI power domain is disabled. The firmware supports it correctly, so add it to the firmware clock driver. Acked-by: Maxime Ripard <maxime@cerno.tech> Acked-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Ivan T. Ivanov <iivanov@suse.de> Link: https://lore.kernel.org/r/20220829152154.147250-3-iivanov@suse.de Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-30clk: bcm: rpi: Add support HEVC clockIvan T. Ivanov1-0/+3
Export clock required for RPiVid video decoder hardware. Cc: Dom Cobley <popcornmix@gmail.com> Acked-by: Maxime Ripard <maxime@cerno.tech> Signed-off-by: Ivan T. Ivanov <iivanov@suse.de> Link: https://lore.kernel.org/r/20220829152154.147250-2-iivanov@suse.de Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-08-23clk: bcm: rpi: Show clock id limit in error caseStefan Wahren1-1/+2
The clock id limit will be extended in the future, so it would be helpful to see the actual clock id limit in case the firmware response has been rejected. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Link: https://lore.kernel.org/r/20220713154953.3336-4-stefan.wahren@i2se.com Acked-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Ivan T. Ivanov <iivanov@suse.de> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-08-23clk: bcm: rpi: Add missing newlineStefan Wahren1-3/+3
Some log messages lacks the final newline. So add them. Fixes: 93d2725affd6 ("clk: bcm: rpi: Discover the firmware clocks") Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Link: https://lore.kernel.org/r/20220713154953.3336-3-stefan.wahren@i2se.com Acked-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Ivan T. Ivanov <iivanov@suse.de> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-08-23clk: bcm: rpi: Prevent out-of-bounds accessStefan Wahren1-1/+6
The while loop in raspberrypi_discover_clocks() relies on the assumption that the id of the last clock element is zero. Because this data comes from the Videocore firmware and it doesn't guarantuee such a behavior this could lead to out-of-bounds access. So fix this by providing a sentinel element. Fixes: 93d2725affd6 ("clk: bcm: rpi: Discover the firmware clocks") Link: https://github.com/raspberrypi/firmware/issues/1688 Suggested-by: Phil Elwell <phil@raspberrypi.com> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Link: https://lore.kernel.org/r/20220713154953.3336-2-stefan.wahren@i2se.com Acked-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Ivan T. Ivanov <iivanov@suse.de> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-08-22clk: bcm: rpi: Fix error handling of raspberrypi_fw_get_rateStefan Wahren1-1/+1
The function raspberrypi_fw_get_rate (e.g. used for the recalc_rate hook) can fail to get the clock rate from the firmware. In this case we cannot return a signed error value, which would be casted to unsigned long. Fix this by returning 0 instead. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Link: https://lore.kernel.org/r/20220625083643.4012-1-stefan.wahren@i2se.com Fixes: 4e85e535e6cc ("clk: bcm283x: add driver interfacing with Raspberry Pi's firmware") Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-05-20clk: bcm: rpi: Use correct order for the parameters of devm_kcalloc()Christophe JAILLET1-1/+1
We should have 'n', then 'size', not the opposite. This is harmless because the 2 values are just multiplied, but having the correct order silence a (unpublished yet) smatch warning. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/49d726d11964ca0e3757bdb5659e3b3eaa1572b5.1653081643.git.christophe.jaillet@wanadoo.fr Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-03-11clk: bcm: rpi: Run some clocks at the minimum rate allowedMaxime Ripard1-0/+37
The core clock and M2MC clocks are shared between some devices (Unicam controllers and the HVS, and the HDMI controllers, respectively) that will have various, varying, requirements depending on their current work load. Since those loads can require a fairly high clock rate in extreme conditions (up to ~600MHz), we can end up running those clocks at their maximum frequency even though we no longer require such a high rate. Fortunately, those devices don't require an exact rate but a minimum rate, and all the drivers are using clk_set_min_rate. Thus, we can just rely on the fact that the clk_request minimum (which is the aggregated minimum of all the clock users) is what we want at all times. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220225143534.405820-11-maxime@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-03-11clk: bcm: rpi: Set a default minimum rateMaxime Ripard1-0/+26
The M2MC clock provides the state machine clock for both HDMI controllers. However, if no HDMI monitor is plugged in at boot, its clock rate will be left at 0 by the firmware and will make any register access end up in a CPU stall, even though the clock was enabled. We had some code in the HDMI controller to deal with this before, but it makes more sense to have it in the clock driver. Move it there. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220225143534.405820-10-maxime@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-03-11clk: bcm: rpi: Add variant structureMaxime Ripard1-17/+47
We only export a bunch of firmware clocks, and some of them require special treatment. This has been do so far using some tests on the clock id in various places, but this is fairly hard to extend and doesn't scale very well. Since we'll need some more cases in the next patches, let's switch to a variant structure that defines the behaviour we need to have for a given clock. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220225143534.405820-9-maxime@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2021-03-22clk: bcm: rpi: Release firmware handle on unbindNicolas Saenz Julienne1-1/+1
Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware interface when unbinding the device. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Stephen Boyd <sboyd@kernel.org> drivers/clk/bcm/clk-raspberrypi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
2020-09-22clk: bcm: rpi: Add register to control pixel bvb clkHoegeun Kwon1-0/+1
To use QHD or higher, we need to modify the pixel_bvb_clk value. So add register to control this clock. Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Link: https://lore.kernel.org/r/20200901040759.29992-2-hoegeun.kwon@samsung.com Reviewed-by: Maxime Ripard <mripard@kernel.org> Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-06-19clk: bcm: rpi: Remove the quirks for the CPU clockMaxime Ripard1-164/+0
The CPU clock has had so far a bunch of quirks to expose the clock tree properly, but since we reverted to exposing them through the MMIO driver, we can remove that code from the firmware driver. Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/acdf820c2f78a25dd7480a0c018b8b387acd013e.1592210452.git-series.maxime@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-06-19clk: bcm: rpi: Give firmware clocks a nameMaxime Ripard1-1/+20
We've registered the firmware clocks using their ID as name, but it's much more convenient to register them using their proper name. Since the firmware doesn't provide it, we have to duplicate it. Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/a52a5f5768cd33716cdd35237c6613f26ad75013.1592210452.git-series.maxime@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-06-19clk: bcm: rpi: Discover the firmware clocksMaxime Ripard1-12/+141
The RaspberryPi4 firmware actually exposes more clocks than are currently handled by the driver and we will need to change some of them directly based on the pixel rate for the display related clocks, or the load for the GPU. Since the firmware implements DVFS, this rate change can have a number of side-effects, including adjusting the various PLL voltages or the PLL parents. The firmware also implements thermal throttling, so even some thermal pressure can change those parameters behind Linux back. DVFS is currently implemented on the arm, core, h264, v3d, isp and hevc clocks, so updating any of them using the MMIO driver (and thus behind the firmware's back) can lead to troubles, the arm clock obviously being the most problematic. In order to make Linux play as nice as possible with those constraints, it makes sense to rely on the firmware clocks as much as possible. However, the firmware doesn't seem to provide some equivalents to their MMIO counterparts, so we can't really replace that driver entirely. Fortunately, the firmware has an interface to discover the clocks it exposes. Let's use it to discover, register the clocks in the clocks framework and then expose them through the device tree for consumers to use them. Cc: Michael Turquette <mturquette@baylibre.com> Cc: Stephen Boyd <sboyd@kernel.org> Cc: linux-clk@vger.kernel.org Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/438d73962741a8c5f7c689319b7443b930a87fde.1592210452.git-series.maxime@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-06-19clk: bcm: rpi: Add an enum for the firmware clocksMaxime Ripard1-4/+19
While the firmware allows us to discover the available clocks, we need to discriminate those clocks to only register the ones meaningful to Linux. The firmware also doesn't provide a clock name, so having a list of the ID will help us to give clocks a proper name later on. Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/4738f77ee7de9b48a3bb1c558ead958d0cc064d9.1592210452.git-series.maxime@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-06-19clk: bcm: rpi: Add DT provider for the clocksMaxime Ripard1-0/+16
For the upcoming registration of the clocks provided by the firmware, make sure it's exposed to the device tree providers. Cc: Michael Turquette <mturquette@baylibre.com> Cc: linux-clk@vger.kernel.org Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/4d8dbe4aaae98b3d3812ad7c3dba53d645cadbaf.1592210452.git-series.maxime@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-06-19clk: bcm: rpi: Make the PLLB registration function return a clk_hwMaxime Ripard1-22/+24
The raspberrypi_register_pllb has been returning an integer so far to notify whether the functions has exited successfully or not. However, the OF provider functions in the clock framework require access to the clk_hw structure so that we can expose those clocks to device tree consumers. Since we'll want that for the future clocks, let's return a clk_hw pointer instead of the return code. Cc: Michael Turquette <mturquette@baylibre.com> Cc: linux-clk@vger.kernel.org Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/97218559db643e62fdd2b5e3046a2a05b8c2e769.1592210452.git-series.maxime@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-06-19clk: bcm: rpi: Split pllb clock hooksMaxime Ripard1-8/+22
The driver only supports the pllb for now and all the clock framework hooks are a mix of the generic firmware interface and the specifics of the pllb. Since we will support more clocks in the future let's split the generic and specific hooks Cc: Michael Turquette <mturquette@baylibre.com> Cc: linux-clk@vger.kernel.org Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/fdc21962fdc7de5c46232f198672d5d5c868ec74.1592210452.git-series.maxime@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-06-19clk: bcm: rpi: Rename is_prepared functionMaxime Ripard1-2/+2
The raspberrypi_fw_pll_is_on function doesn't only apply to PLL registered in the driver, but any clock exposed by the firmware. Since we also implement the is_prepared hook, make the function consistent with the other function names. Cc: Michael Turquette <mturquette@baylibre.com> Cc: linux-clk@vger.kernel.org Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/ac93cc4e245316bb7e7426ac5ab0de8f3d919731.1592210452.git-series.maxime@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-06-19clk: bcm: rpi: Pass the clocks data to the firmware functionMaxime Ripard1-15/+14
The raspberry_clock_property only takes the clock ID as an argument, but now that we have a clock data structure it makes more sense to just pass that structure instead. Cc: Michael Turquette <mturquette@baylibre.com> Cc: Stephen Boyd <sboyd@kernel.org> Cc: linux-clk@vger.kernel.org Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/d7a3b4df3ca23feb6e0d9c7ae2d232bfb913f926.1592210452.git-series.maxime@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-06-19clk: bcm: rpi: Add clock id to dataMaxime Ripard1-9/+9
The driver has really only supported one clock so far and has hardcoded the ID used in communications with the firmware in all the functions implementing the clock framework hooks. Let's store that in the clock data structure so that we can support more clocks later on. Cc: Michael Turquette <mturquette@baylibre.com> Cc: linux-clk@vger.kernel.org Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/e23c37961b97b027e21efa3b818578970f88527a.1592210452.git-series.maxime@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-06-19clk: bcm: rpi: Create a data structure for the clocksMaxime Ripard1-10/+21
So far the driver has really only been providing a single clock, and stored both the data associated to that clock in particular with the data associated to the "controller". Since we will change that in the future, let's decouple the clock data from the provider data. Cc: Michael Turquette <mturquette@baylibre.com> Cc: linux-clk@vger.kernel.org Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/ee7f508db226214fab4add7f93a351f4137c86a1.1592210452.git-series.maxime@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-06-19clk: bcm: rpi: Use CCF boundaries instead of rolling our ownMaxime Ripard1-10/+8
The raspberrypi firmware clock driver has a min_rate / max_rate clamping by storing the info it needs in a private structure. However, the CCF already provides such a facility, so we can switch to it to remove the boilerplate. Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/d4c53dab6de5d5f70743d9c139d0117589530e62.1592210452.git-series.maxime@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-06-19clk: bcm: rpi: Make sure the clkdev lookup is removedMaxime Ripard1-2/+3
The clkdev lookup created for the cpufreq device is never removed if there's an issue later in probe or at module removal time. Let's convert to the managed variant of the clk_hw_register_clkdev function to make sure it happens. Cc: Michael Turquette <mturquette@baylibre.com> Cc: linux-clk@vger.kernel.org Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/075e2c6d315eccdaf8fb72b320712b86e6c25b22.1592210452.git-series.maxime@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-06-19clk: bcm: rpi: Switch to clk_hw_register_clkdevMaxime Ripard1-6/+5
Since we don't care about retrieving the clk_lookup structure pointer returned by clkdev_hw_create, we can just use the clk_hw_register_clkdev function. Cc: Michael Turquette <mturquette@baylibre.com> Cc: linux-clk@vger.kernel.org Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/59f6208b6fe3367e735b0cca4f65c2c937639af9.1592210452.git-series.maxime@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-06-19clk: bcm: rpi: Remove pllb_arm_lookup global pointerMaxime Ripard1-4/+4
The pllb_arm_lookup pointer in the struct raspberrypi_clk is not used for anything but to store the returned pointer to clkdev_hw_create, and is not used anywhere else in the driver. Let's remove that global pointer from the structure. Cc: Michael Turquette <mturquette@baylibre.com> Cc: linux-clk@vger.kernel.org Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/189407f54906d2b07c91de7a4eeb6d8c8934280f.1592210452.git-series.maxime@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-06-19clk: bcm: rpi: Make sure pllb_arm is removedMaxime Ripard1-2/+1
The pllb_arm clock was created at probe time, but was never removed if something went wrong later in probe, or if the driver was ever removed from the system. Now that we are using clk_hw_register(), we can just use its managed variant to take care of that for us. Cc: Michael Turquette <mturquette@baylibre.com> Cc: Stephen Boyd <sboyd@kernel.org> Cc: linux-clk@vger.kernel.org Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/34254ed1556614658e5dad5cca4cf4fe617df7fc.1592210452.git-series.maxime@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-06-19clk: bcm: rpi: Remove global pllb_arm clock pointerMaxime Ripard1-4/+3
The pllb_arm clk_hw pointer in the raspberry_clk structure isn't used anywhere but in the raspberrypi_register_pllb_arm. Let's remove it, this will make our lives easier in future patches. Cc: Michael Turquette <mturquette@baylibre.com> Cc: Stephen Boyd <sboyd@kernel.org> Cc: linux-clk@vger.kernel.org Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/842859cf1a77478620f45049178a588448202858.1592210452.git-series.maxime@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-06-19clk: bcm: rpi: Use clk_hw_register for pllb_armMaxime Ripard1-6/+18
The pllb_arm clock is defined as a fixed factor clock with the pllb clock as a parent. However, all its configuration is entirely static, and thus we don't really need to call clk_hw_register_fixed_factor() but can simply call clk_hw_register() with a static clk_fixed_factor structure. Cc: Michael Turquette <mturquette@baylibre.com> Cc: linux-clk@vger.kernel.org Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/1146177664999eeda65856d28ce94025021dd85e.1592210452.git-series.maxime@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-06-19clk: bcm: rpi: Statically init clk_init_dataMaxime Ripard1-2/+1
Instead of declaring the clk_init_data and then calling memset on it, just initialise properly. Cc: Michael Turquette <mturquette@baylibre.com> Cc: Stephen Boyd <sboyd@kernel.org> Cc: linux-clk@vger.kernel.org Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/0342572daa561dc1bb4c9fd10641b2016493e32b.1592210452.git-series.maxime@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-06-19clk: bcm: rpi: Allow the driver to be probed by DTMaxime Ripard1-2/+17
The current firmware clock driver for the RaspberryPi can only be probed by manually registering an associated platform_device. While this works fine for cpufreq where the device gets attached a clkdev lookup, it would be tedious to maintain a table of all the devices using one of the clocks exposed by the firmware. Since the DT on the other hand is the perfect place to store those associations, make the firmware clocks driver probe-able through the device tree so that we can represent it as a node. Cc: Michael Turquette <mturquette@baylibre.com> Cc: linux-clk@vger.kernel.org Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/cb8203b862e386ac6c3df3eff0bb5a238b6ec97a.1592210452.git-series.maxime@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-06-25clk: raspberrypi: register platform device for raspberrypi-cpufreqNicolas Saenz Julienne1-0/+15
As 'clk-raspberrypi' depends on RPi's firmware interface, which might be configured as a module, the cpu clock might not be available for the cpufreq driver during it's init process. So we register the 'raspberrypi-cpufreq' platform device after the probe sequence succeeds. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Acked-by: Eric Anholt <eric@anholt.net> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-06-25clk: bcm283x: add driver interfacing with Raspberry Pi's firmwareNicolas Saenz Julienne1-0/+300
Raspberry Pi's firmware offers an interface though which update it's clock's frequencies. This is specially useful in order to change the CPU clock (pllb_arm) which is 'owned' by the firmware and we're unable to scale using the register interface provided by clk-bcm2835. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Acked-by: Eric Anholt <eric@anholt.net> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.