diff options
author | Shawn Lin <shawn.lin@rock-chips.com> | 2018-03-21 03:39:20 +0100 |
---|---|---|
committer | Heiko Stuebner <heiko@sntech.de> | 2018-03-23 09:02:58 +0100 |
commit | 570fda972b3178f9a981d1b7ac18e05245a52eab (patch) | |
tree | c00a3df5d82d90834f68d615b1fa98fccced849b /drivers | |
parent | clk: rockchip: Fix wrong parents for MMC phase clock for rk3328 (diff) | |
download | linux-570fda972b3178f9a981d1b7ac18e05245a52eab.tar.xz 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')
-rw-r--r-- | drivers/clk/rockchip/clk-mmc-phase.c | 16 |
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; |