Because of the inexact nature of the extra MMC delay elements (it's
not possible to keep the phase monotonic and to also make phases (mod
90) > 70), we previously only allowed phases (mod 90) of 22.5, 45,
and 67.5.

But it's not the end of the world if the MMC clock phase goes
non-monotonic.  At most we'll be 25 degrees off.  It's way better to
test more phases to look for bad ones than to be 25 degrees off, because
in the case of MMC really the point is to find bad phases and get as far
asway from the as possible.  If we get to test extra phases by going
slightly non-monotonic then that might be fine.  Worst case we would
end up at a phases that's slight differnt than the one we wanted, but
at least we'd still be quite far away from the a bad phase.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Fold in more precise variance-values of 44-77 instead of 40-80.
Fold in the actual removal of the monotonic requirement and adapt
patch message accordingly.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Again a result of the gpio-clock-liberation the rk3368 needs the
pclk_pd_pmu marked as critical, to boot successfully.
Reported-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

Now that the rockchip clock subsystem does clock gating with GPIO banks,
these are no longer enabled once during probe and no longer stay enabled
for eternity. When all these clocks are disabled, the parent clock pclk_peri
might be disabled too, as no other child claims it. So, we need to add pclk_peri
to the critical clocks.
Signed-off-by: NRomain Perier <romain.perier@gmail.com>
Tested-by: NMichael Niewoehner <linux@mniewoehner.de>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

pclk_cpu needs to keep running because it is needed for devices like
the act8865 regulator but with the recent gpio clock handling this is
not always the case anymore. So add it to the list of critical clocks.
Signed-off-by: NMichael Niewoehner <linux@mniewoehner.de>
Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

Currently the registration of critical clocks is done in the function
shared between rk3066 and rk3188 clock trees. That results in them
getting handled maybe before all of them are registered.

Therefore move the critical clock handling down to the end of the soc-
specific clock registration function, so that all clocks are registered
before they're maybe handled as critical clock.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NMichael Niewoehner <linux@mniewoehner.de>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

The structure is xin24m -> pll -> pll-mux (xin24m,pll,xin32k). The pll
does have an init callback to make sure the boot-selected frequency is
using the expected pll settings and resets the same frequency using
the values provided in the driver if necessary.

The setting itself also involves remuxing the pll-mux temporarily to
the xin24m source to let the new pll rate settle. Until now this worked
flawlessly, even when it had the flaw of accessing the mux settings
before the mux actually got registered.

With the recent clock-core conversions this flaw became apparent in
null pointer dereference in
[<c03fc400>] (clk_hw_get_num_parents) from [<c0400df0>] (clk_mux_get_parent+0x14/0xc8)
[<c0400ddc>] (clk_mux_get_parent) from [<c040246c>] (rockchip_rk3066_pll_set_rate+0xd8/0x320)

So to fix that, simply register the pll-mux before the pll, so that
it will be fully initialized when the pll clock executes its init-
callback and possibly touches the pll-mux clock.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMichael Turquette <mturquette@baylibre.com>

Use the provider based method to get a clock's name so that we
can get rid of the clk member in struct clk_hw one day. Mostly
converted with the following coccinelle script.

@@
struct clk_hw *E;
@@

-__clk_get_name(E->clk)
+clk_hw_get_name(E)
Acked-by: NHeiko Stuebner <heiko@sntech.de>
Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Peter De Schrijver <pdeschrijver@nvidia.com>
Cc: Prashant Gaikwad <pgaikwad@nvidia.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Acked-by: NThierry Reding <treding@nvidia.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Acked-by: NAndrew Bresticker <abrestic@chromium.org>
Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Kevin Cernekee <cernekee@chromium.org>
Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Cc: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-rockchip@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-tegra@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

We're removing struct clk from the clk provider API, so switch
this code to using the clk_hw based provider APIs.
Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

pclk_pd_pmu needs to keep running and with the upcoming gpio clock
handling this is not always the case anymore. So add it to the list
of critical clocks for now.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NLin Huang <hl@rock-chips.com>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Acked-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Neither spdif_src nor spdif_pll exists, judging by the vendor kernel in
both cases spdif_pre was meant. This brings the naming in line and
hierachy in line with that of sclk_i2s0.

Also allow sclk_spdif and spdif_frac to change their parents rate as
that the upstream dividers are purely there to feed sclk_spdif
Signed-off-by: NSjoerd Simons <sjoerd.simons@collabora.co.uk>
Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMichael Turquette <mturquette@baylibre.com>

In the TRM we see that BWADJ is "a 12-bit bus that selects the values
1-4096 for the bandwidth divider (NB)":
 NB = BWADJ[11:0] + 1
The recommended setting of NB: NB = NF / 2.

So:
  NB = NF / 2
  BWADJ[11:0] + 1 = NF / 2
  BWADJ[11:0] = NF / 2 - 1

Right now, we have:

{                                               \
        .rate   = _rate##U,                     \
        .nr = _nr,                              \
        .nf = _nf,                              \
        .no = _no,                              \
        .bwadj = (_nf >> 1),                    \
}

That means we set bwadj to NF / 2, not NF / 2 - 1

All of this is a bit confusing because we specify "NR" (the 1-based
value), "NF" (the 1-based value), "NO" (the 1-based value), but
"BWADJ" (the 0-based value) instead of "NB" (the 1-based value).

Let's change to working with "NB" and fix the off by one error.  This
may affect PLL jitter in a small way (hopefully for the better).
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

Clock provider drivers generally shouldn't include clk.h because
it's the consumer API. Only include clk.h if it's actually used.

Cc: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

Describe the clock tree and software resets of the rk3368 ARM64 SoC
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

Both soc series' have inverters on the hsadc and camera interface clock
paths. So define them using the newly added inverter type.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

The review for the new inverter clock type uncovered some issues (missing
headers and name handling) that are also present in the mmc-phase clock
type, I got (to much) inspiration from. Fix these there too.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

Most Rockchip socs have optional phase inverters connected to some
clocks that move the clock-phase by 180 degrees.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
[sboyd@codeaurora.org: Dropped lazy part of commit text]
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

A clock branch consisting of a mux and divider with non-standard
divider values.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

The macros calculate the correct offset from the id in the parameter.
If this parameter does not consist of a single number, the calculation
will return wrong registers in the best case or create unaligned accesses
in the worst case. So protect the calculations against such values.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

The video input processor (vip) was called camera interface (cif) on
older socs which seems to have resulted in a copy'n'paste error when
creating the rk3288 camera clocks.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

The dwmac ethernet controller on the rk3288 supports phys connected
via rgmii and rmii. With rgmii phys it is expected that the mac clock
is provided externally while with rmii phys the clock can be external
but also generated from the plls. In the later case it of course needs
be at 50MHz, which gets set from the dwmac_rk driver.
As most devices use a rgmii phy it never surfaced so far that the mac
clk mux, doesn't go up one lever to the pll clock in the rmii case with
internal clock generation, as it is missing the CLK_SET_RATE_PARENT flag,
and thus will not set the correct frequency in most cases.

Fixes: b9e4ba54 ("clk: rockchip: add clock controller for rk3288")
Cc: stable@vger.kernel.org
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

Since commit 2893c379 ("clk: make strings in parent name arrays
const") the name of parent clocks can be const. So add more const in
several clock drivers.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

Add missing static to local (file-scope only) symbols.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

The statement

	static const char *name[];

defines a modifiable array of pointers to constant chars. That is

	*name[0] = 'f';

is forbidden, but

	name[0] = "f";

is not. So marking an array that is defined as above with __initconst is
wrong. Either an additional const must be added such that the whole
definition reads:

	static const char *const name[] __initconst;

or where this is not possible __initdata must be used.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NMichael Turquette <mturquette@linaro.org>

The pclk supplying the watchdog is controlled via the SGRF register area.
Currently we don't have any clock-type handling external clock bits like
this one. Additionally the SGRF isn't even writable in every boot mode.

But still the clock control is available and in the future someone might
want to use it. Therefore define a simple clock for the time being so
that the watchdog driver can read its rate.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

Process-Voltage-Temperatiure Monitor block on RK3288 has two clocks:
PVTM_CORE and PVTM_GPU.
Signed-off-by: NHuang Lin <hl@rock-chips.com>
Signed-off-by: NDmitry Torokhov <dtor@chromium.org>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

Use the clock ID for usbphy480m_src so that we can find
this clock node in dts.
Signed-off-by: NKever Yang <kever.yang@rock-chips.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

Lockdep reported a possible deadlock between the cpuclk lock and for example
the i2c driver.

       CPU0                    CPU1
       ----                    ----
  lock(clk_lock);
                               local_irq_disable();
                               lock(&(&i2c->lock)->rlock);
                               lock(clk_lock);
  <Interrupt>
    lock(&(&i2c->lock)->rlock);

 *** DEADLOCK ***

The generic clock-types of the core ccf already use spin_lock_irqsave when
touching clock registers, so do the same for the cpuclk.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NMichael Turquette <mturquette@linaro.org>
[mturquette@linaro.org: removed initialization of "flags"]

modify CRU config for GMAC driver

changes since v2:
1. remove SCLK_MAC_PLL
Signed-off-by: NRoger Chen <roger.chen@rock-chips.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We've been seeing some crashes at resume time on rk3288-based systems.
On some machines they simply never wake up from suspend.  Symptoms
include:

- System clearly got to sleep OK.  Power consumption is low, the PWM
  for the PWM regulator has stopped, and the "global_pwroff" output
  shows that the system is down.

- When system tries to wake up power consumption goes up.

- No kernel resume code (which was left in PMU SRAM) ran.  We added
  some basic logging to this code (write to a location in SRAM right
  at resume time) and didn't see the logging run.

It appears that we can fix the problem by slowing down APLL before we
suspend.  On the system I tested things seemed reliable if I disabled
1.8GHz and 1.7GHz.  The Mask ROM itself tries to slow things down
(which is why PLLs are in slow mode by the time we get to the kernel),
but apparently it is crashing before it even gets there.

We'll be super paranoid and not just go down to 1.6GHz but we'll match
what the Mask ROM seems to be doing and go into slow mode.  We'll also
be safe and put all PLLs (not just APLL) into slow mode (well, except
DPLL which is needed for SDRAM).  We'll even put NPLL into slow mode
which the Mask ROM didn't do (not that it's used for much important
stuff at early resume time).

Note that the old Rockchip reference code did something just like
this, though they jammed it into pm.c instead of putting it in the
syscore ops of the clock driver.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

Commit 0e5bdb3f (clk: rockchip: switch to using the new cpuclk type
for armclk) didn't take into account that the divider used on rk3288
are of the (n+1) type.

The rk3066 and rk3188 socs use more complex divider types making it
necessary for the list-elements to be the real register-values to write.

Therefore reduce divider values in the table accordingly so that they
really are the values that should be written to the registers and match
the dividers actually specified for the rk3288.
Reported-by: NSonny Rao <sonnyrao@chromium.org>
Fixes: 0e5bdb3f ("clk: rockchip: switch to using the new cpuclk type for armclk")
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NDoug Anderson <dianders@chromium.org>
Cc: stable@vger.kernel.org

The bit locations indicating the locking status of the plls on rk3066 are
shifted by one to the right when compared to the rk3188, bits [7:4] instead
of [8:5] on the rk3188, thus indicating the locking state of the wrong pll
or a completely different information in case of the gpll.

The recently introduced pll init code exposed that problem on some rk3066
boards when it tried to bring the boot-pll value in line with the value
from the rate table.

Fix this by defining separate pll definitions for rk3066 with the correct
locking indices.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Fixes: 2c14736c ("clk: rockchip: add clock driver for rk3188 and rk3066 clocks")
Tested-by: NFUKAUMI Naoki <naobsd@gmail.com>
Cc: stable@vger.kernel.org

Do not disable clock gate "hclk_emem_peri", otherwise EMAC clocks no longer work
and it breaks ethernet on RK3066 and RK3188. It fixes a regression introduced by
commit 78eaf609 ("clk: rockchip: disable unused clocks").
Signed-off-by: NRomain Perier <romain.perier@gmail.com>
Fixes: 78eaf609 ("clk: rockchip: disable unused clocks")
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

This patch adds CLK_IGNORE_UNUSED flag to hclk_usb_peri, hclk_usbotg0
and hclk_usbotg1 because these clocks must remain enabled to use the
USB controllers in host mode.

This fixes a regression introduced by commit 78eaf609
("clk: rockchip: disable unused clocks").
Signed-off-by: NJulien CHAUVEAU <julien.chauveau@neo-technologies.fr>
Fixes: 78eaf609 ("clk: rockchip: disable unused clocks")
Reviewed-by: NRomain Perier <romain.perier@gmail.com>
Tested-by: NRomain Perier <romain.perier@gmail.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

We'd like to be able to set the clock rate of the sclk_uart clocks and
actually be able to achieve clock rates greater than 24MHz.  To do
this we need to be able to pass rate changes upward.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

This patch adds the 2 physical clocks for the mmc (drive and sample). They're
mostly there for the phase properties, but they also show the true clock
(by dividing by RK3288_MMC_CLKGEN_DIV).

The drive and sample phases are generated by dividing an upstream parent clock
by 2, this allows us to adjust the phase by 90 deg.

There's also an option to have up to 255 delay elements (40-80 picoseconds long).
This driver uses those elements (under the assumption that they're 60 ps long)
to generate approximate 22.5 degrees options. 67.5 (22.5*3) might be as high as
90 deg if the delay elements are as big as 80 ps, so a finer division (smaller
than 22.5) was not picked because the phase might not be monotonic anymore.
Suggested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NAlexandru M Stan <amstan@chromium.org>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

This exposes the clock that comes out of the i2s block which generally
goes to the audio codec.
Signed-off-by: NSonny Rao <sonnyrao@chromium.org>
[removed CLK_SET_RATE_PARENT from original patch]
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

The DMC clocks need to be turned off at runtime.  Use the newly
assigned clock IDs to export them.
Signed-off-by: NJeff Chen <cym@rock-chips.com>
[dianders: split into two patches; adjusted commit msg]
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

Add the new flag to gpll and cpll on rk3188 and similar and to
gpll, cpll and npll on rk3288.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NKever Yang <kever.yang@rock-chips.com>
Tested-by: NKever Yang <kever.yang@rock-chips.com>

In some cases firmware brings up plls with different parameters than the ones
noted in the rate table for the specific frequency. These firmware-selected
parameters are worse than the tested ones in the pll rate tables but cannot
be changed by a simple clk_set_rate call when the rate stays the same.

Therefore add a ROCKCHIP_PLL_SYNC_RATE flag and implement an init callback
that checks the runtime-parameters against the matching rate table entry
and adjusts them to the table-ones if necessary.

If no rate table is set or the current rate does not match any rate-table
entry no changes are made.

Being able to limit this adjustment to specific plls is necessary to not
touch the ones supplying core components like the apll and dpll supplying
the armcores and dram.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NKever Yang <kever.yang@rock-chips.com>
Tested-by: NKever Yang <kever.yang@rock-chips.com>

In some cases we might need to access the data of the pll mux before the actual
mux gets registered - like in the following patch adding an init-callback.

Therefore populate pll_mux before registering the core pll-clock.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NKever Yang <kever.yang@rock-chips.com>
Tested-by: NKever Yang <kever.yang@rock-chips.com>