kernel/git/stable/linux.git/drivers/clk/rockchip, branch linux-4.4.y

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

2020-05-10T08:26:07+00:00

commit 4715f81afc342996f680b08c944a712d9cbef11b upstream. 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 . 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 Reviewed-by: Shawn Lin Signed-off-by: Greg Kroah-Hartman [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

clk: rockchip: fix rk3188 sclk_mac_lbtest parameter ordering

2019-12-21T09:34:28+00:00

[ Upstream commit ac8cb53829a6ba119082e067f5bc8fab3611ce6a ] Similar to commit a9f0c0e56371 ("clk: rockchip: fix rk3188 sclk_smc gate data") there is one other gate clock in the rk3188 clock driver with a similar wrong ordering, the sclk_mac_lbtest. So fix it as well. Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin

clk: rockchip: fix rk3188 sclk_smc gate data

2019-12-21T09:34:27+00:00

[ Upstream commit a9f0c0e563717b9f63b3bb1c4a7c2df436a206d9 ] Fix sclk_smc gate data. Change variable order, flags come before the register address. Signed-off-by: Finley Xiao Signed-off-by: Johan Jonker Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin

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

2019-09-21T05:12:44+00:00

commit 6943b839721ad4a31ad2bacf6e71b21f2dfe3134 upstream. 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 Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman

clk: rockchip: Turn on "aclk_dmac1" for suspend on rk3288

2019-06-22T06:18:20+00:00

[ Upstream commit 57a20248ef3e429dc822f0774bc4e00136c46c83 ] Experimentally it can be seen that going into deep sleep (specifically setting PMU_CLR_DMA and PMU_CLR_BUS in RK3288_PMU_PWRMODE_CON1) appears to fail unless "aclk_dmac1" is on. The failure is that the system never signals that it made it into suspend on the GLOBAL_PWROFF pin and it just hangs. NOTE that it's confirmed that it's the actual suspend that fails, not one of the earlier calls to read/write registers. Specifically if you comment out the "PMU_GLOBAL_INT_DISABLE" setting in rk3288_slp_mode_set() and then comment out the "cpu_do_idle()" call in rockchip_lpmode_enter() then you can exercise the whole suspend path without any crashing. This is currently not a problem with suspend upstream because there is no current way to exercise the deep suspend code. However, anyone trying to make it work will run into this issue. This was not a problem on shipping rk3288-based Chromebooks because those devices all ran on an old kernel based on 3.14. On that kernel "aclk_dmac1" appears to be left on all the time. There are several ways to skin this problem. A) We could add "aclk_dmac1" to the list of critical clocks and that apperas to work, but presumably that wastes power. B) We could keep a list of "struct clk" objects to enable at suspend time in clk-rk3288.c and use the standard clock APIs. C) We could make the rk3288-pmu driver keep a list of clocks to enable at suspend time. Presumably this would require a dts and bindings change. D) We could just whack the clock on in the existing syscore suspend function where we whack a bunch of other clocks. This is particularly easy because we know for sure that the clock's only parent ("aclk_cpu") is a critical clock so we don't need to do anything more than ungate it. In this case I have chosen D) because it seemed like the least work, but any of the other options would presumably also work fine. Signed-off-by: Douglas Anderson Reviewed-by: Elaine Zhang Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin

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

2018-05-30T05:49:14+00:00

[ Upstream commit 4bf59902b50012b1dddeeaa23b217d9c4956cdda ] 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 Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

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

2016-08-10T09:49:28+00:00

commit 595144c1141c951a3c6bb9004ae6a2bc29aad66f upstream. 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") Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman

clk: rockchip: free memory in error cases when registering clock branches

2016-05-11T09:21:12+00:00

commit 2467b6745e0ae9c6cdccff24c4cceeb14b1cce3f upstream. Add free memeory if rockchip_clk_register_branch fails. Fixes: a245fecbb806 ("clk: rockchip: add basic infrastructure...") Signed-off-by: Shawn Lin Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman

clk-divider: make sure read-only dividers do not write to their register

2016-05-11T09:21:11+00:00

commit 50359819794b4a16ae35051cd80f2dab025f6019 upstream. Commit e6d5e7d90be9 ("clk-divider: Fix READ_ONLY when divider > 1") removed the special ops struct for read-only clocks and instead opted to handle them inside the regular ops. On the rk3368 this results in breakage as aclkm now gets set a value. While it is the same divider value, the A53 core still doesn't like it, which can result in the cpu ending up in a hang. The reason being that "ACLKENMasserts one clock cycle before the rising edge of ACLKM" and the clock should only be touched when STANDBYWFIL2 is asserted. To fix this, reintroduce the read-only ops but do include the round_rate callback. That way no writes that may be unsafe are done to the divider register in any case. The Rockchip use of the clk_divider_ops is adapted to this split again, as is the nxp, lpc18xx-ccu driver that was included since the original commit. On lpc18xx-ccu the divider seems to always be read-only so only uses the new ops now. Fixes: e6d5e7d90be9 ("clk-divider: Fix READ_ONLY when divider > 1") Reported-by: Zhang Qing Signed-off-by: Heiko Stuebner Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman

clk: rockchip: add hclk_cpubus to the list of rk3188 critical clocks

2016-04-12T16:09:02+00:00

commit e8b63288b37dbb8457b510c9d96f6006da4653f6 upstream. hclk_cpubus needs to keep running because it is needed for devices like the rom, i2s0 or spdif to be accessible via cpu. Without that all accesses to devices (readl/writel) return wrong data. So add it to the list of critical clocks. Fixes: 78eaf6095cc763c ("clk: rockchip: disable unused clocks") Signed-off-by: Alexander Kochetkov Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman