summaryrefslogtreecommitdiffstats
path: root/drivers/clk/rockchip
diff options
context:
space:
mode:
authorShawn Lin <shawn.lin@rock-chips.com>2018-03-21 10:39:20 +0800
committerHeiko Stuebner <heiko@sntech.de>2018-03-23 09:02:58 +0100
commit570fda972b3178f9a981d1b7ac18e05245a52eab (patch)
treec00a3df5d82d90834f68d615b1fa98fccced849b /drivers/clk/rockchip
parentce84eca927af24ca27897ba5fee4fbeed443d5fc (diff)
downloadlinux-570fda972b3178f9a981d1b7ac18e05245a52eab.tar.gz
linux-570fda972b3178f9a981d1b7ac18e05245a52eab.tar.bz2
linux-570fda972b3178f9a981d1b7ac18e05245a52eab.zip
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>
Diffstat (limited to 'drivers/clk/rockchip')
-rw-r--r--drivers/clk/rockchip/clk-mmc-phase.c16
1 files changed, 14 insertions, 2 deletions
diff --git a/drivers/clk/rockchip/clk-mmc-phase.c b/drivers/clk/rockchip/clk-mmc-phase.c
index dc4c227732bd..b7b9f2e7d64b 100644
--- a/drivers/clk/rockchip/clk-mmc-phase.c
+++ b/drivers/clk/rockchip/clk-mmc-phase.c
@@ -170,18 +170,30 @@ static int rockchip_mmc_clk_rate_notify(struct notifier_block *nb,
unsigned long event, void *data)
{
struct rockchip_mmc_clock *mmc_clock = to_rockchip_mmc_clock(nb);
+ struct clk_notifier_data *ndata = data;
/*
* rockchip_mmc_clk is mostly used by mmc controllers to sample
* the intput data, which expects the fixed phase after the tuning
* process. However if the clock rate is changed, the phase is stale
* and may break the data sampling. So here we try to restore the phase
- * for that case.
+ * for that case, except that
+ * (1) cached_phase is invaild since we inevitably cached it when the
+ * clock provider be reparented from orphan to its real parent in the
+ * first place. Otherwise we may mess up the initialization of MMC cards
+ * since we only set the default sample phase and drive phase later on.
+ * (2) the new coming rate is higher than the older one since mmc driver
+ * set the max-frequency to match the boards' ability but we can't go
+ * over the heads of that, otherwise the tests smoke out the issue.
*/
+ if (ndata->old_rate <= ndata->new_rate)
+ return NOTIFY_DONE;
+
if (event == PRE_RATE_CHANGE)
mmc_clock->cached_phase =
rockchip_mmc_get_phase(&mmc_clock->hw);
- else if (event == POST_RATE_CHANGE)
+ else if (mmc_clock->cached_phase != -EINVAL &&
+ event == POST_RATE_CHANGE)
rockchip_mmc_set_phase(&mmc_clock->hw, mmc_clock->cached_phase);
return NOTIFY_DONE;