- 12 Jan, 2022 2 commits
-
-
Stephen Boyd authored
* clk-x86: clk: x86: Fix clk_gate_flags for RV_CLK_GATE clk: x86: Use dynamic con_id string during clk registration ACPI: APD: Add a fmw property clk-name drivers: acpi: acpi_apd: Remove unused device property "is-rv" x86: clk: clk-fch: Add support for newer family of AMD's SOC clk: Introduce clk-tps68470 driver platform/x86: int3472: Deal with probe ordering issues platform/x86: int3472: Pass tps68470_regulator_platform_data to the tps68470-regulator MFD-cell platform/x86: int3472: Pass tps68470_clk_platform_data to the tps68470-regulator MFD-cell platform/x86: int3472: Add get_sensor_adev_and_name() helper platform/x86: int3472: Split into 2 drivers platform_data: Add linux/platform_data/tps68470.h file i2c: acpi: Add i2c_acpi_new_device_by_fwnode() function i2c: acpi: Use acpi_dev_ready_for_enumeration() helper ACPI: delay enumeration of devices with a _DEP pointing to an INT3472 device * clk-stm: clk: stm32: Fix ltdc's clock turn off by clk_disable_unused() after system enter shell * clk-amlogic: clk: meson: gxbb: Fix the SDM_EN bit for MPLL0 on GXBB * clk-allwinner: clk: sunxi-ng: Add support for the D1 SoC clocks clk: sunxi-ng: gate: Add macros for gates with fixed dividers clk: sunxi-ng: mux: Add macros using clk_parent_data and clk_hw clk: sunxi-ng: mp: Add macros using clk_parent_data and clk_hw clk: sunxi-ng: div: Add macros using clk_parent_data and clk_hw dt-bindings: clk: Add compatibles for D1 CCUs clk: sunxi-ng: Allow the CCU core to be built as a module clk: sunxi-ng: Convert early providers to platform drivers clk: sunxi-ng: Allow drivers to be built as modules clk: sunxi-ng: Export symbols used by CCU drivers
-
Stephen Boyd authored
* clk-doc: clk: Gemini: fix struct name in kernel-doc clk: zynq: pll: Fix kernel-doc warnings clk: imx: pllv1: fix kernel-doc notation for struct clk_pllv1 * clk-renesas: (31 commits) clk: renesas: r9a07g044: Add GPU clock and reset entries clk: renesas: r9a07g044: Add mux and divider for G clock clk: renesas: r9a07g044: Rename CLK_PLL3_DIV4 macro clk: renesas: cpg-mssr: Add support for R-Car S4-8 clk: renesas: rcar-gen4: Introduce R-Car Gen4 CPG driver dt-bindings: clock: Add r8a779f0 CPG Core Clock Definitions dt-bindings: power: Add r8a779f0 SYSC power domain definitions clk: renesas: r9a07g044: Add TSU clock and reset entry mmc: renesas_sdhi: Simplify an expression mmc: renesas_sdhi: Use devm_clk_get_optional() to obtain CD clock dt-bindings: clock: renesas,cpg-mssr: Document r8a779f0 clk: renesas: cpg-mssr: propagate return value of_genpd_add_provider_simple() clk: renesas: cpg-mssr: Check return value of pm_genpd_init() clk: renesas: rzg2l: propagate return value of_genpd_add_provider_simple() clk: renesas: rzg2l: Check return value of pm_genpd_init() clk: renesas: r9a07g044: Add RSPI clock and reset entries clk: renesas: r9a07g044: Change core clock "I" from DEF_FIXED->DEF_DIV clk: renesas: rzg2l: Add CPG_PL1_DDIV macro mmc: renesas_sdhi: Parse DT for SDnH mmc: renesas_sdhi: Use dev_err_probe when getting clock fails ... * clk-at91: clk: lan966x: Extend lan966x clock driver for clock gating support dt-bindings: clock: lan966x: Extend includes with clock gates dt-bindings: clock: lan966x: Extend for clock gate support clk: gate: Add devm_clk_hw_register_gate() clk: lan966x: Add lan966x SoC clock driver dt-bindings: clock: lan966x: Add LAN966X Clock Controller dt-bindings: clock: lan966x: Add binding includes for lan966x SoC clock IDs * clk-cleanup: clk: stm32mp1: remove redundant assignment to pointer data clk: __clk_core_init() never takes NULL clk: clk_core_get() can also return NULL clk/ti/adpll: Make const pointer error a static const array * clk-debugfs: clk: Enable/Disable runtime PM for clk_summary clk: Emit a stern warning with writable debugfs enabled clk: Add write operation for clk_parent debugfs node
-
- 07 Jan, 2022 5 commits
-
-
Ajit Kumar Pandey authored
In newer SoC we have to clear bit for disabling 48MHz oscillator clock gate. Remove CLK_GATE_SET_TO_DISABLE flag for proper enable and disable of 48MHz clock. Signed-off-by:
Ajit Kumar Pandey <AjitKumar.Pandey@amd.com> Reviewed-by:
Mario Limonciello <Mario.Limonciello@amd.com> Link: https://lore.kernel.org/r/20211212180527.1641362-6-AjitKumar.Pandey@amd.comSigned-off-by:
Stephen Boyd <sboyd@kernel.org>
-
Ajit Kumar Pandey authored
Replace hard coded con_id string with fch_data->name. We have clk consumers looking up with different clock names, hence use dynamic con_id string during clk lookup registration. fch_data->name will be initialized in acpi driver based on fmw property value. Signed-off-by:
-
Ajit Kumar Pandey authored
Add a new device property to fetch clk-name from firmware. Signed-off-by:
-
Ajit Kumar Pandey authored
Initially "is-rv" device property is added for 48MHz fixed clock support on Raven or RV architecture. It's unused now as we moved to pci device_id based selection to extend such support on other architectures. This change removed unused code from acpi driver. Signed-off-by:
-
Ajit Kumar Pandey authored
FCH controller clock configuration slightly differs across AMD's SOC architectures. Newer family of SOC only support a 48MHz fix clock while stoney SOC family has a clk_mux to choose 48MHz and 25 MHz clk. At present fixed clk support is only enabled for RV architecture using "is-rv" device property initialized from boot loader. This limit 48MHz fixed clock gate support to RV platform unless we add similar device property in boot loader for other architectures. Add pci_device_id table with Stoney platform id and replace "is-rv" device property check with pci id match to add clk mux support with 25MHz and 48MHz clk support based on clk mux selection. This enable 48Mhz fixed fch clock support by default on all newer SOC's except stoney. Also replace RV with FIXED as a generic naming conventions across all platforms and changed module description. Signed-off-by:
-
- 06 Jan, 2022 1 commit
-
-
Taniya Das authored
The registers for some clocks in the SOC area, which are under the power domain are required to be enabled before accessing them. During the clk_summary if the power-domains are not enabled they could result into NoC errors. Thus ensure the register access of the clock controller is done with pm_untime_get/put functions. Signed-off-by:
Taniya Das <tdas@codeaurora.org> Link: https://lore.kernel.org/r/1640018638-19436-3-git-send-email-tdas@codeaurora.orgSigned-off-by:
-
- 29 Dec, 2021 3 commits
-
-
Stephen Boyd authored
Merge tag 'renesas-clk-for-v5.17-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into clk-renesas Pull Renesas clk driver updates from Geert Uytterhoeven: - Add support for the new Renesas R-Car S4-8 (R8A779F0) SoC - Add GPU clock and resets on Renesas RZ/G2L - Miscellaneous fixes and improvements * tag 'renesas-clk-for-v5.17-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers: clk: renesas: r9a07g044: Add GPU clock and reset entries clk: renesas: r9a07g044: Add mux and divider for G clock clk: renesas: r9a07g044: Rename CLK_PLL3_DIV4 macro clk: renesas: cpg-mssr: Add support for R-Car S4-8 clk: renesas: rcar-gen4: Introduce R-Car Gen4 CPG driver dt-bindings: clock: Add r8a779f0 CPG Core Clock Definitions dt-bindings: power: Add r8a779f0 SYSC power domain definitions
-
Stephen Boyd authored
Merge tag 'sunxi-clk-for-5.17-1' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into clk-allwinner Pull Allwinner clk driver updates from Maxime Ripard: Our usual PR for the Allwinner SoCs, this time enabling our sub-framework to be built as a module, converting most drivers to platform drivers and allow them to be built as modules, and support for the Allwinner D1 * tag 'sunxi-clk-for-5.17-1' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux: clk: sunxi-ng: Add support for the D1 SoC clocks clk: sunxi-ng: gate: Add macros for gates with fixed dividers clk: sunxi-ng: mux: Add macros using clk_parent_data and clk_hw clk: sunxi-ng: mp: Add macros using clk_parent_data and clk_hw clk: sunxi-ng: div: Add macros using clk_parent_data and clk_hw dt-bindings: clk: Add compatibles for D1 CCUs clk: sunxi-ng: Allow the CCU core to be built as a module clk: sunxi-ng: Convert early providers to platform drivers clk: sunxi-ng: Allow drivers to be built as modules clk: sunxi-ng: Export symbols used by CCU drivers
-
https://github.com/BayLibre/clk-mesonStephen Boyd authored
Pull an Amlogic clock driver update from Jerome Brunet: - Fix MPLL0 gxbb SDM enable * tag 'clk-meson-v5.17-1' of https://github.com/BayLibre/clk-meson: clk: meson: gxbb: Fix the SDM_EN bit for MPLL0 on GXBB
-
- 16 Dec, 2021 4 commits
-
-
Colin Ian King authored
The pointer data is being initialized with a value and a few lines later on being re-assigned the same value, so this re-assignment is redundant. Clean up the code and remove it. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20211126221239.1100960-1-colin.i.king@gmail.comSigned-off-by:
-
Dillon Min authored
stm32's clk driver register two ltdc gate clk to clk core by clk_hw_register_gate() and clk_hw_register_composite() first: 'stm32f429_gates[]', clk name is 'ltdc', which no user to use. second: 'stm32f429_aux_clk[]', clk name is 'lcd-tft', used by ltdc driver both of them point to the same offset of stm32's RCC register. after kernel enter console, clk core turn off ltdc's clk as 'stm32f429_gates[]' is no one to use. but, actually 'stm32f429_aux_clk[]' is in use. stm32f469/746/769 have the same issue, fix it. Fixes: daf2d117 ("clk: stm32f4: Add lcd-tft clock") Link: https://lore.kernel.org/linux-arm-kernel/1590564453-24499-7-git-send-email-dillon.minfei@gmail.com/ Link: https://lore.kernel.org/lkml/CAPTRvHkf0cK_4ZidM17rPo99gWDmxgqFt4CDUjqFFwkOeQeFDg@mail.gmail.com/Signed-off-by:
Dillon Min <dillon.minfei@gmail.com> Reviewed-by:
Patrice Chotard <patrice.chotard@foss.st.com> Acked-by:
Gabriel Fernandez <gabriel.fernandez@foss.st.com> Acked-by:
-
Hans de Goede authored
The TPS68470 PMIC provides Clocks, GPIOs and Regulators. At present in the kernel the Regulators and Clocks are controlled by an OpRegion driver designed to work with power control methods defined in ACPI, but some platforms lack those methods, meaning drivers need to be able to consume the resources of these chips through the usual frameworks. This commit adds a driver for the clocks provided by the tps68470, and is designed to bind to the platform_device registered by the intel_skl_int3472 module. This is based on this out of tree driver written by Intel: https://github.com/intel/linux-intel-lts/blob/4.14/base/drivers/clk/clk-tps68470.c with various cleanups added. Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211203102857.44539-7-hdegoede@redhat.comSigned-off-by:
-
Stephen Boyd authored
Merge tag 'platform-drivers-x86-int3472-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 into clk-x86 Signed tag for the immutable platform-drivers-x86-int3472 branch This branch contains 5.16-rc1 + the pending ACPI/i2c, tps68570 platform_data and INT3472 driver patches. * tag 'platform-drivers-x86-int3472-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: platform/x86: int3472: Deal with probe ordering issues platform/x86: int3472: Pass tps68470_regulator_platform_data to the tps68470-regulator MFD-cell platform/x86: int3472: Pass tps68470_clk_platform_data to the tps68470-regulator MFD-cell platform/x86: int3472: Add get_sensor_adev_and_name() helper platform/x86: int3472: Split into 2 drivers platform_data: Add linux/platform_data/tps68470.h file i2c: acpi: Add i2c_acpi_new_device_by_fwnode() function i2c: acpi: Use acpi_dev_ready_for_enumeration() helper ACPI: delay enumeration of devices with a _DEP pointing to an INT3472 device
-
- 13 Dec, 2021 9 commits
-
-
Hans de Goede authored
The clk and regulator frameworks expect clk/regulator consumer-devices to have info about the consumed clks/regulators described in the device's fw_node. To work around this info missing from the ACPI tables on devices where the int3472 driver is used, the int3472 MFD-cell drivers attach info about consumers to the clks/regulators when registering these. This causes problems with the probe ordering wrt drivers for consumers of these clks/regulators. Since the lookups are only registered when the provider-driver binds, trying to get these clks/regulators before then results in a -ENOENT error for clks and a dummy regulator for regulators. All the sensor ACPI fw-nodes have a _DEP dependency on the INT3472 ACPI fw-node, so to work around these probe ordering issues the ACPI core / i2c-code does not instantiate the I2C-clients for any ACPI devices which have a _DEP dependency on an INT3472 ACPI device until all _DEP-s are met. This relies on acpi_dev_clear_dependencies() getting called by the driver for the _DEP-s when they are ready, add a acpi_dev_clear_dependencies() call to the discrete.c probe code. In the tps68470 case calling acpi_dev_clear_dependencies() is already done by the acpi_gpiochip_add() call done by the driver for the GPIO MFD cell (The GPIO cell is deliberately the last cell created to make sure the clk + regulator cells are already instantiated when this happens). However for proper probe ordering, the clk/regulator cells must not just be instantiated the must be fully ready (the clks + regulators must be registered with their subsystems). Add MODULE_SOFTDEP dependencies for the clk and regulator drivers for the instantiated MFD-cells so that these are loaded before us and so that they bind immediately when the platform-devs are instantiated. Reviewed-by:
-
Hans de Goede authored
Pass tps68470_regulator_platform_data to the tps68470-regulator MFD-cell, specifying the voltages of the various regulators and tying the regulators to the sensor supplies so that sensors which use the TPS68470 can find their regulators. Since the voltages and supply connections are board-specific, this introduces a DMI matches int3472_tps68470_board_data struct which contains the necessary per-board info. This per-board info also includes GPIO lookup information for the sensor IO lines which may be connected to the tps68470 GPIOs. Reviewed-by:
-
Hans de Goede authored
Pass tps68470_clk_platform_data to the tps68470-clk MFD-cell, so that sensors which use the TPS68470 can find their clock. Reviewed-by:
-
Hans de Goede authored
The discrete.c code is not the only code which needs to lookup the acpi_device and device-name for the sensor for which the INT3472 ACPI-device is a GPIO/clk/regulator provider. The tps68470.c code also needs this functionality, so factor this out into a new get_sensor_adev_and_name() helper. Reviewed-by:
-
Hans de Goede authored
The intel_skl_int3472.ko module contains 2 separate drivers, the int3472_discrete platform driver and the int3472_tps68470 I2C-driver. These 2 drivers contain very little shared code, only skl_int3472_get_acpi_buffer() and skl_int3472_fill_cldb() are shared. Split the module into 2 drivers, linking the little shared code directly into both. This will allow us to add soft-module dependencies for the tps68470 clk, gpio and regulator drivers to the new intel_skl_int3472_tps68470.ko to help with probe ordering issues without causing these modules to get loaded on boards which only use the int3472_discrete platform driver. While at it also rename the .c and .h files to remove the cumbersome intel_skl_int3472_ prefix. Reviewed-by:
-
Hans de Goede authored
The clk and regulator frameworks expect clk/regulator consumer-devices to have info about the consumed clks/regulators described in the device's fw_node. To work around cases where this info is not present in the firmware tables, which is often the case on x86/ACPI devices, both frameworks allow the provider-driver to attach info about consumers to the provider-device during probe/registration of the provider device. The TI TPS68470 PMIC is used x86/ACPI devices with the consumer-info missing from the ACPI tables. Thus the tps68470-clk and tps68470-regulator drivers must provide the consumer-info at probe time. Define tps68470_clk_platform_data and tps68470_regulator_platform_data structs to allow the x86 platform code to pass the necessary consumer info to these drivers. Reviewed-by:
-
Hans de Goede authored
Change i2c_acpi_new_device() into i2c_acpi_new_device_by_fwnode() and add a static inline wrapper providing the old i2c_acpi_new_device() behavior. This is necessary because in some cases we may only have access to the fwnode / acpi_device and not to the matching physical-node struct device *. Suggested-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by:
Wolfram Sang <wsa@kernel.org> Signed-off-by:
-
Hans de Goede authored
The clk and regulator frameworks expect clk/regulator consumer-devices to have info about the consumed clks/regulators described in the device's fw_node. To work around cases where this info is not present in the firmware tables, which is often the case on x86/ACPI devices, both frameworks allow the provider-driver to attach info about consumers to the clks/regulators when registering these. This causes problems with the probe ordering wrt drivers for consumers of these clks/regulators. Since the lookups are only registered when the provider-driver binds, trying to get these clks/regulators before then results in a -ENOENT error for clks and a dummy regulator for regulators. To ensure the correct probe-ordering the ACPI core has code to defer the enumeration of consumers affected by this until the providers are ready. Call the new acpi_dev_ready_for_enumeration() helper to avoid enumerating / instantiating i2c-clients too early. Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
-
Hans de Goede authored
The clk and regulator frameworks expect clk/regulator consumer-devices to have info about the consumed clks/regulators described in the device's fw_node. To work around cases where this info is not present in the firmware tables, which is often the case on x86/ACPI devices, both frameworks allow the provider-driver to attach info about consumers to the clks/regulators when registering these. This causes problems with the probe ordering wrt drivers for consumers of these clks/regulators. Since the lookups are only registered when the provider-driver binds, trying to get these clks/regulators before then results in a -ENOENT error for clks and a dummy regulator for regulators. One case where we hit this issue is camera sensors such as e.g. the OV8865 sensor found on the Microsoft Surface Go. The sensor uses clks, regulators and GPIOs provided by a TPS68470 PMIC which is described in an INT3472 ACPI device. There is special platform code handling this and setting platform_data with the necessary consumer info on the MFD cells instantiated for the PMIC under: drivers/platform/x86/intel/int3472. For this to work properly the ov8865 driver must not bind to the I2C-client for the OV8865 sensor until after the TPS68470 PMIC gpio, regulator and clk MFD cells have all been fully setup. The OV8865 on the Microsoft Surface Go is just one example, all X86 devices using the Intel IPU3 camera block found on recent Intel SoCs have similar issues where there is an INT3472 HID ACPI-device, which describes the clks and regulators, and the driver for this INT3472 device must be fully initialized before the sensor driver (any sensor driver) binds for things to work properly. On these devices the ACPI nodes describing the sensors all have a _DEP dependency on the matching INT3472 ACPI device (there is one per sensor). This allows solving the probe-ordering problem by delaying the enumeration (instantiation of the I2C-client in the ov8865 example) of ACPI-devices which have a _DEP dependency on an INT3472 device. The new acpi_dev_ready_for_enumeration() helper used for this is also exported because for devices, which have the enumeration_by_parent flag set, the parent-driver will do its own scan of child ACPI devices and it will try to enumerate those during its probe(). Code doing this such as e.g. the i2c-core-acpi.c code must call this new helper to ensure that it too delays the enumeration until all the _DEP dependencies are met on devices which have the new honor_deps flag set. Acked-by:
-
- 10 Dec, 2021 5 commits
-
-
Stephen Boyd authored
We don't want vendors to be enabling this part of the clk code and shipping it to customers. Exposing the ability to change clk frequencies and parents via debugfs is potentially damaging to the system if folks don't know what they're doing. Emit a strong warning so that the message is clear: don't enable this outside of development systems. Fixes: 37215da5 ("clk: Add support for setting clk_rate via debugfs") Cc: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20211210014237.2130300-1-sboyd@kernel.orgSigned-off-by:
-
Sam Protsenko authored
Useful for testing mux clocks. One can write the index of the parent to be set into clk_parent node, starting from 0. Example # cd /sys/kernel/debug/clk/mout_peri_bus # cat clk_possible_parents dout_shared0_div4 dout_shared1_div4 # cat clk_parent dout_shared0_div4 # echo 1 > clk_parent # cat clk_parent dout_shared1_div4 CLOCK_ALLOW_WRITE_DEBUGFS has to be defined in drivers/clk/clk.c in order to use this feature. Signed-off-by:Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Fabio Estevam <festevam@gmail.com> Acked-by:
Michael Turquette <mturquette@baylibre.com> Link: https://lore.kernel.org/r/20211013172042.10884-1-semen.protsenko@linaro.org [sboyd@kernel.org: Collapse ifdefs] Signed-off-by:
-
Stephen Boyd authored
The only caller of __clk_core_init() allocates the pointer and checks the allocation for NULL so this check is impossible. Remove it. Signed-off-by:
-
Stephen Boyd authored
Nothing stops a clk controller from registering an OF clk provider before registering those clks with the clk framework. This is not great but we deal with it in the clk framework by refusing to hand out struct clk pointers when 'hw->core' is NULL, the indication that clk_register() has been called. Within clk_core_fill_parent_index() we considered this case when a clk_hw pointer is referenced directly by filling in the parent cache with an -EPROBE_DEFER pointer when the core pointer is NULL. When we lookup a parent with clk_core_get() we don't care about the return value being NULL though, because that was considered largely impossible, but it's been proven now that it can be NULL if two clk providers are probing in parallel and the parent provider has been registered before the clk has. Let's check for NULL here as well and treat it the same as direct clk_hw references. Signed-off-by:
-
Colin Ian King authored
Make const pointer error a static const array, removes a dereference and shrinks object code a little. Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
- 09 Dec, 2021 1 commit
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/at91/linuxStephen Boyd authored
Pull AT91 clk driver updates from Nicolas Ferre: - Lan966x Generic Clock Controller driver and associated DT bindings - Lan966x clock driver extended to support clock gating * tag 'clk-at91-5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux: clk: lan966x: Extend lan966x clock driver for clock gating support dt-bindings: clock: lan966x: Extend includes with clock gates dt-bindings: clock: lan966x: Extend for clock gate support clk: gate: Add devm_clk_hw_register_gate() clk: lan966x: Add lan966x SoC clock driver dt-bindings: clock: lan966x: Add LAN966X Clock Controller dt-bindings: clock: lan966x: Add binding includes for lan966x SoC clock IDs
-
- 08 Dec, 2021 10 commits
-
-
Horatiu Vultur authored
Extend the clock driver to add support also for clock gating. The following peripherals can be gated: UHPHS, UDPHS, MCRAMC, HMATRIX. Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Acked-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by:
-
Horatiu Vultur authored
On lan966x it is allow to control the clock to some peripherals like USB. So extend the include file with these clocks. Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Horatiu Vultur authored
Allow to add an optional resource to be able to access the clock gate registers. Signed-off-by:
-
Horatiu Vultur authored
Add devm_clk_hw_register_gate() - devres-managed version of clk_hw_register_gate() Suggested-by:
-
Kavyasree Kotagiri authored
This adds Generic Clock Controller driver for lan966x SoC. Lan966x clock controller contains 3 PLLs - cpu_clk, ddr_clk and sys_clk. It generates and supplies clock to various peripherals within SoC. Register settings required to provide GCK clocking to a peripheral is as below: GCK_SRC_SEL = Select clock source. GCK_PRESCALER = Set divider value. GCK_ENA = 1 - Enable GCK clock. Signed-off-by:
Kavyasree Kotagiri <kavyasree.kotagiri@microchip.com> Co-developed-by:
-
Kavyasree Kotagiri authored
This adds the DT bindings documentation for lan966x SoC generic clock controller. Signed-off-by:
-
Kavyasree Kotagiri authored
LAN966X supports 14 clock outputs for its peripherals. This include file is introduced to use identifiers for clocks. Signed-off-by:
-
Biju Das authored
Add GPU clock and reset entries to CPG driver. Signed-off-by:
Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by:
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20211203115154.31864-4-biju.das.jz@bp.renesas.comSigned-off-by:
-
Biju Das authored
G clock is sourced from PLL3 and PLL6. The output of the mux is connected to divider. This patch adds a mux and divider for getting different rates from this clock sources. Signed-off-by:
-
Biju Das authored
Rename the macro CLK_PLL3_DIV4->CLK_PLL3_DIV2_2 to match the clock tree mentioned in the hardware manual(Rev.1.00 Sep, 2021). Signed-off-by:
-
