clk: rockchip: fix mmc get phase

If the mmc clock has no rate, it can be assumed to be constant.
In such case, there is no measurable phase shift. Just return 0
in this case instead of returning an error.

Fixes: 2760878662a2 ("clk: Bail out when calculating phase fails during clk registration")
Tested-by: Markus Reichl <m.reichl@fivetechno.de>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lkml.kernel.org/r/20200303192956.64410-1-jbrunet@baylibre.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 157

Based on 3 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version this program is distributed in the
hope that it will be useful but without any warranty without even
the implied warranty of merchantability or fitness for a particular
purpose see the gnu general public license for more details

this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version [author] [kishon] [vijay] [abraham]
[i] [kishon]@[ti] [com] this program is distributed in the hope that
it will be useful but without any warranty without even the implied
warranty of merchantability or fitness for a particular purpose see
the gnu general public license for more details

this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version [author] [graeme] [gregory]
[gg]@[slimlogic] [co] [uk] [author] [kishon] [vijay] [abraham] [i]
[kishon]@[ti] [com] [based] [on] [twl6030]_[usb] [c] [author] [hema]
[hk] [hemahk]@[ti] [com] this program is distributed in the hope
that it will be useful but without any warranty without even the
implied warranty of merchantability or fitness for a particular
purpose see the gnu general public license for more details

extracted by the scancode license scanner the SPDX license identifier

GPL-2.0-or-later

has been chosen to replace the boilerplate/reference in 1105 file(s).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Allison Randal <allison@lohutok.net>
Reviewed-by: Richard Fontana <rfontana@redhat.com>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070033.202006027@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

clk: rockchip: Slightly more accurate math in rockchip_mmc_get_phase()

There's a bit of math in rockchip_mmc_get_phase() to calculate the
"fine delay". This math boils down to:

PSECS_PER_SEC = 1000000000000.
ROCKCHIP_MMC_DELAY_ELEMENT_PSEC = 60
card_clk * ROCKCHIP_MMC_DELAY_ELEMENT_PSEC * 360 * x / PSECS_PER_SEC

...but we do it in pieces to avoid overflowing 32-bits. Right now we
overdo it a little bit, though, and end up getting less accurate math
than we could. Right now we do:

DIV_ROUND_CLOSEST((card_clk / 1000000) *
(ROCKCHIP_MMC_DELAY_ELEMENT_PSEC / 10) *
(360 / 10) *
delay_num,
PSECS_PER_SEC / 1000000 / 10 / 10)

This is non-ideal because:
A) The pins on Rockchip SoCs are rated to go at most 150 MHz, so the
max card clock is 150 MHz. Even ignoring this the maximum SD card
clock (for SDR104) would be 208 MHz. This means you can decrease
your division by 100x and still not overflow:
hex(208000000 / 10000 * 6 * 36 * 0xff) == 0x44497200
B) On many Rockchip SoCs we end up with a card clock that is actually
148500000 because we parent off the 297 MHz PLL. That means the
math we're actually doing today is less than ideal. Specifically:
148500000 / 1000000 = 148

Let's fix the math to be slightly more accurate.

NOTE: no known problems are fixed by this. It was found simply by
code inspection. If you want to see the difference between the old
and the new on a 148.5 MHz clock, this python can help:

old = [x for x in
(int(round(148 * 6 * 36 * x / 10000.)) for x in range(256))
if x < 90]
new = [x for x in
(int(round(1485 * 6 * 36 * x / 100000.)) for x in range(256))
if x < 90]

The only differences are:
delay_num=17 54=>55
delay_num=22 70=>71
delay_num=27 86=>87

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

clk: rockchip: Don't yell about bad mmc phases when getting

At boot time, my rk3288-veyron devices yell with 8 lines that look
like this:
[ 0.000000] rockchip_mmc_get_phase: invalid clk rate

This is because the clock framework at clk_register() time tries to
get the phase but we don't have a parent yet.

While the errors appear to be harmless they are still ugly and, in
general, we don't want yells like this in the log unless they are
important.

There's no real reason to be yelling here. We can still return
-EINVAL to indicate that the phase makes no sense without a parent.
If someone really tries to do tuning and the clock is reported as 0
then we'll see the yells in rockchip_mmc_set_phase().

Fixes: 4bf59902b500 ("clk: rockchip: Prevent calculating mmc phase if clock rate is zero")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

clk: rockchip: Use clk_hw_get_rate() in MMC phase calculation

When calculating the MMC phase we can just use clk_hw_get_rate()
instead of clk_get_rate(). This avoids recalculating the rate.

Suggested-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

clk: rockchip: Fix error return in phase clock registration

The newly added clock notifier may return an error code but so far the
error output in the function would only return an error pointer from
registering the clock.

So when the clock notifier fails the clock would be unregistered but the
return would still be the clock pointer which could then not be
dereferenced correctly. So fix the error handling to prevent that.

Fixes: 60cf09e45fbc ("clk: rockchip: Restore the clock phase after the rate was changed")
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

clk: rockchip: Correct the behaviour of restoring cached phase

We can't restore every phase, for instance the invalid phase and
the phase for coming rate which is out of the scope of boards'
ability. And this patch also corrects the error path to return
invalid pointer to clk if clk_notifier_register failed introduced
by the same offending commit.

Fixes: 60cf09e45fbc ("clk: rockchip: Restore the clock phase after the rate was changed")
Reported-by: wlq <wlq@rock-chips.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Tested-by: wlq <wlq@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

clk: rockchip: Restore the clock phase after the rate was changed

There are many factors affecting the clock phase, including clock
rate, temperature, logic voltage and silicon process, etc. But clock
rate is the most significant one here, and the driver should be aware
of the change of the clock rate. As mmc controller need a fixed phase
after tuning was completed, at least before explicitly doing re-tune,
so this patch try to restore the clock phase by monitoring the event
of rate change.

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

clk: rockchip: Prevent calculating mmc phase if clock rate is zero

The MMC sample and drv clock for rockchip platforms are derived from
the bus clock output to the MMC/SDIO card. So it should never happens
that the clk rate is zero given it should inherits the clock rate from
its parent. If something goes wrong and makes the clock rate to be zero,
the calculation would be wrong but may still make the mmc tuning process
work luckily. However it makes people harder to debug when the following
data transfer is unstable.

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

clk: rockchip: Revert "clk: rockchip: reset init state before mmc card initialization"

This reverts commit 7a03fe6f48f3 ("clk: rockchip: reset init state
before mmc card initialization").

Though not totally obvious from the commit message nor from the source
code, that commit appears to be trying to reset the "_drv" MMC clocks to
90 degrees (note that the "_sample" MMC clocks have a shift of 0 so are
not touched).

The major problem here is that it doesn't properly reset things. The
phase is a two bit field and the commit only touches one of the two
bits. Thus the commit had the following affect:
- phase 0 => phase 90
- phase 90 => phase 90
- phase 180 => phase 270
- phase 270 => phase 270

Things get even weirder if you happen to have a bootloader that was
actually using delay elements (should be no reason to, but you never
know), since those are additional bits that weren't touched by the
original patch.

This is unlikely to be what we actually want. Checking on rk3288-veyron
devices, I can see that the bootloader leaves these clocks as:
- emmc: phase 180
- sdmmc: phase 90
- sdio0: phase 90

Thus on rk3288-veyron devices the commit we're reverting had the effect
of changing the eMMC clock to phase 270. This probably explains the
scattered reports I've heard of eMMC devices not working on some veyron
devices when using the upstream kernel.

The original commit was presumably made because previously the kernel
didn't touch the "_drv" phase at all and relied on whatever value was
there when the kernel started. If someone was using a bootloader that
touched the "_drv" phase then, indeed, we should have code in the kernel
to fix that. ...and also, to get ideal timings, we should also have the
kernel change the phase depending on the speed mode. In fact, that's
the subject of a recent patch I posted at
<https://patchwork.kernel.org/patch/9075141/>.

Ideally, we should take both the patch posted to dw_mmc and this
revert. Since those will likely go through different trees, here I
describe behavior with the combos:

1. Just this revert: likely will fix rk3288-veyron eMMC on some devices
+ other cases; might break someone with a strange bootloader that
sets the phase to 0 or one that uses delay elements (pretty
unpredicable what would happen in that case).
2. Just dw_mmc patch: fixes everyone. Effectly the dw_mmc patch will
totally override the broken patch and fix everything.
3. Both patches: fixes everyone. Once dw_mmc is initting properly then
any defaults from the clock code doesn't mattery.

Fixes: 7a03fe6f48f3 ("clk: rockchip: reset init state before mmc card initialization")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>

[emmc and sdmmc still work on all current boards in mainline after this
revert, so they should take precedence over any out-of-tree board that
will hopefully again get fixed with the better upcoming dw_mmc change.]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

clk: rockchip: initialize flags of clk_init_data in mmc-phase clock

The flags element of clk_init_data was never initialized for mmc-
phase-clocks resulting in the element containing a random value
and thus possibly enabling unwanted clock flags.

Fixes: 89bf26cbc1a0 ("clk: rockchip: Add support for the mmc clock phases using the framework")
Cc: stable@vger.kernel.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

clk: rockchip: fix checkpatch warning in core code

We seem to have accumulated a bunch of checkpatch warnings, with mainly
overlong lines and two unnecessary allocation error messages.
Most were introduced with the recent multi-controller-support but some
were quite a bit older.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>

clk: rockchip: don't return NULL when registering mmc branch fails

Avoid return NULL if rockchip_clk_register_mmc fails, otherwise
rockchip_clk_register_branches print "unknown clock type". The acutal
case is that it's a known clock type but we fail to regiser it, which
may makes user confuse the reason of failure.

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

clk: rockchip: Make calculations use rounding

Let's use DIV_ROUND_CLOSEST for rounding, not just truncating
division. This lets us get closer to the right rate.

Before this:
set_phase(86) delay_nums=26 reg[0xf000420c]=0x468 actual_degrees=83
set_phase(89) delay_nums=27 reg[0xf000420c]=0x46c actual_degrees=86

After this:
set_phase(86) delay_nums=27 reg[0xf000420c]=0x46c actual_degrees=86
set_phase(89) delay_nums=28 reg[0xf000420c]=0x470 actual_degrees=90

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

clk: rockchip: Allow more precision for some mmc clock phases

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: Douglas 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: Heiko Stuebner <heiko@sntech.de>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

clk: rockchip: reset init state before mmc card initialization

mmc host controller's IO input/output timing is unpredictable if
bootloader execute tuning for HS200 mode. It might make kernel failed
to initialize mmc card in identification mode. The root cause is
tuning phase and degree setting for HS200 mode in bootloader aren't
applicable to that of identification mode in kernel stage. Anyway, we
can't force all bootloaders to reset tuning phase and degree setting
before into kernel. Simply reset it in rockchip_clk_register_mmc.

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>

clk: Convert __clk_get_name(hw->clk) to clk_hw_get_name(hw)

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: Heiko 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: Thierry 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: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Acked-by: Andrew 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: Geert 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: Stephen Boyd <sboyd@codeaurora.org>

clk: rockchip: Properly include clk.h

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: Stephen Boyd <sboyd@codeaurora.org>

clk: rockchip: fix issues in the mmc-phase clock

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: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>

clk: make several parent names const

Since commit 2893c379461a ("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: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>

clk: rockchip: Add support for the mmc clock phases using the framework

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: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>