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>

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>

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>

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>

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>

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>