Commit Graph

11 Commits

Author SHA1 Message Date
Philipp Tomsich
cf8aceb1c9 rockchip: clk: rk3368: add support for configuring the SPI clocks
As SPI support may be useful in the boot-flow, this adds support for
configuring the SPI controller's clocks in the RK3368 clock driver.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2017-08-13 17:12:33 +02:00
Philipp Tomsich
4e4c40df30 rockchip: clk: rk3368: mark 'priv' __maybe_unused in rk3368_clk_set_rate()
With the clock support in rk3368_clk_set_rate() conditionalized on
various feature definitions, 'priv' can remain unused (e.g. in the
SPL build when only MMC is enabled).

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2017-08-13 17:12:32 +02:00
Philipp Tomsich
df0ae00041 rockchip: clk: rk3368: add support for GMAC (SLCK_MAC) clock
To enable the GMAC on the RK3368, we need to set up the clocking
appropriately to generate a tx_clk for the MAC.

This adds an implementation that implements the use of the <&ext_gmac>
clock (i.e. an external 125MHz clock for RGMII provided by the PHY).
This is the clock setup used by the boards currently supported by
U-Boot (i.e. Geekbox, Sheep and RK3368-uQ7).

This includes the change from commit
 - rockchip: clk: rk3368: define GMAC_MUX_SEL_EXTCLK

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2017-08-13 17:12:32 +02:00
Philipp Tomsich
6292469073 rockchip: clk: rk3368: support configuring the DRAM PLL (from TPL)
As part of the DRAM initialisation process (running as part of the TPL
stage) on the RK3368, we need to set up the DRAM PLL.

This implements support for configuring the PLL to for 1200, 1332 or
1600 MHz (i.e. for DDR3-1200, DDR3-1333, DDR3-1600 operating modes).

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2017-08-13 17:12:32 +02:00
Philipp Tomsich
f5a432959a rockchip: clk: rk3368: implement MMC/SD clock reparenting
The original clock support for MMC/SD cards on the RK3368 suffered
from a tendency to select a divider less-or-equal to the the one
giving the requested clock-rate: this can lead to higher-than-expected
(or rather: higher than supported) clock rates for the MMC/SD
communiction.

This change rewrites the MMC/SD clock generation to:
 * always generate a clock less-than-or-equal to the requested clock
 * support reparenting among the CPLL, GPLL and OSC24M parents to
   generate the highest clock that does not exceed the requested rate

In addition to this, the Linux DTS uses HCLK_MMC/HCLK_SDMMC instead of
SCLK_MMC/SCLK_SDMMC: to match this (and to ensure that clock setup
always works), we adjust the driver appropriately.

This includes the changes from:
 - rockchip: clk: rk3368: convert MMC_PLL_SEL_* definitions to shifted-value form

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2017-08-13 17:12:32 +02:00
Philipp Tomsich
a00dfa042d rockchip: clk: rk3368: implement DPLL (DRAM PLL) support
To implement a TPL stage (incl. its DRAM controller setup) for the
RK3368, we'll want to configure the DPLL (DRAM PLL).

This commit implements setting the DPLL (CLK_DDR) and provides PLL
configuration details for the common DRAM operating speeds found on
RK3368 boards.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2017-08-13 17:12:32 +02:00
Philipp Tomsich
4bebf94e85 rockchip: clk: rk3368: do not change CPLL/GPLL before returning to BROM
The RK3368 has a somewhat temperamental BootROM (which I learned the
hard way) when it comes to reconfiguring the CPLL and GPLL (in fact,
experiments show that changing the GPLL broke things for me, while
changing the CPLL seems to be more benign).  These should not be
modified by the SPL stage, if we intend to return to the BootROM for
chain booting the next stage.

This commit changes the clock initialisation to not change CPLL/GPLL
before returning to the BootROM (i.e. in TPL).  As it's safe to change
these settings if we no longer intend to return to U-Boot, we'll run
the full PLL setup a little later (i.e. in SPL).

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2017-08-13 17:12:32 +02:00
Philipp Tomsich
bee6180126 rockchip: clk: rk3368: support OF_PLATDATA for the RK3368 clk driver
With the RK3368's limited TPL size, we'll want to use OF_PLATFDATA for
the SPL stage.  This implements support for OF_PLATDATA in the clock
driver for the RK3368.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2017-08-13 17:12:30 +02:00
Philipp Tomsich
ddfe77df15 rockchip: clk: rk3368: implement bandwidth adjust for PLLs
The RK3368 TRM recommends to configure the bandwith adjustment (CON2)
for PLLs to NF/2.  This implements this for all reconfigurations of
PLLs and removes the 'has_bwadj' flag (as the RK3368 always has the
bandwidth-adjustment feature according to its manual).

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2017-08-13 17:12:28 +02:00
Philipp Tomsich
cdc6080a28 rockchip: clk: rk3368: use correct (i.e. 'rk3368_clk_priv') structure for auto-alloc
The clk driver for the RK3368 picked the wrong data structure's size
for its auto-alloc size: the size was calculated on the structure
representing the CRU hardware block instead of the priv structure.
As the CRU's register file is much larger than the driver's priv,
this did not cause any pain (except wasting memory).

Fix this by using the correct data structure's size.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2017-07-27 14:59:02 +02:00
Andy Yan
d1dcf8527e rockchip: rk3368: Add clock driver
Add driver to setup the various PLLs and peripheral
clocks on the RK3368.

Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2017-06-07 07:29:19 -06:00