summaryrefslogtreecommitdiff
path: root/drivers/clk/uniphier
Commit message (Collapse)AuthorAgeLines
* clk: uniphier: rework UniPhier clk driverMasahiro Yamada2016-10-18-240/+179
| | | | | | | | The initial design of the UniPhier clk driver for U-Boot was not very nice. Here is a re-work to sync it with Linux's clk and reset drivers, maximizing the code reuse from Linux's clk data. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* clk: uniphier: allow to have clock node under syscon nodeMasahiro Yamada2016-09-23-9/+9
| | | | | | | To sync the DT binding with Linux, the register base must be taken from the parent syscon node. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* clk: uniphier: move U_BOOT_DRIVER entry to core codeMasahiro Yamada2016-09-23-75/+74
| | | | | | | | Move U_BOOT_DRIVER() entry from the data file (clk-uniphier-mio.c) to the core support file (clk-uniphier-core.c) because I do not want to repeat the driver boilerplate when I add more clock data. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* clk: uniphier: constify clock data arrays/structuresMasahiro Yamada2016-09-23-9/+9
| | | | | | Clarify these clock data are constant. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: use (devm_)ioremap() instead of map_sysmem()Masahiro Yamada2016-07-24-16/+7
| | | | | | | | This does not have much impact on behavior, but makes code look more more like Linux. The use of devm_ioremap() often helps to delete .remove callbacks entirely. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* clk: convert API to match reset/mailbox styleStephen Warren2016-06-19-14/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following changes are made to the clock API: * The concept of "clocks" and "peripheral clocks" are unified; each clock provider now implements a single set of clocks. This provides a simpler conceptual interface to clients, and better aligns with device tree clock bindings. * Clocks are now identified with a single "struct clk", rather than requiring clients to store the clock provider device and clock identity values separately. For simple clock consumers, this isolates clients from internal details of the clock API. * clk.h is split so it only contains the client/consumer API, whereas clk-uclass.h contains the provider API. This aligns with the recently added reset and mailbox APIs. * clk_ops .of_xlate(), .request(), and .free() are added so providers can customize these operations if needed. This also aligns with the recently added reset and mailbox APIs. * clk_disable() is added. * All users of the current clock APIs are updated. * Sandbox clock tests are updated to exercise clock lookup via DT, and clock enable/disable. * rkclk_get_clk() is removed and replaced with standard APIs. Buildman shows no clock-related errors for any board for which buildman can download a toolchain. test/py passes for sandbox (which invokes the dm clk test amongst others). Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org>
* clk: uniphier: add Media I/O clock driver support for PH1-LD11Masahiro Yamada2016-05-26-0/+4
| | | | Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* clk: uniphier: add Media I/O clock driver support for PH1-LD20Masahiro Yamada2016-04-24-0/+4
| | | | | | PH1-LD20 needs this for its SD card controller. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* clk: uniphier: use devm_get_addr() to get base addressMasahiro Yamada2016-04-01-6/+3
| | | | | | | | | Currently, fdtdec_get_addr_size() does not support the address translation, so it cannot handle device trees with non-straight "ranges" properties. (This would be a problem with DTS for UniPhier ARMv8 SoCs.) Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* clk: uniphier: add Media I/O clock driver for UniPhier SoCsMasahiro Yamada2016-02-14-0/+410
This is the initial commit for the UniPhier clock drivers. Currently, only the Media I/O clock is supported. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>