This is mostly a revert of commit 55bb6a633c ("clk: rockchip: mark
noc and some special clk as critical on rk3288") except that we're
keeping "pmu_hclk_otg0" as critical still.
NOTE: turning these clocks off doesn't seem to do a whole lot in terms
of power savings (checking the power on the logic rail). It appears
to save maybe 1-2mW. ...but still it seems like we should turn the
clocks off if they aren't needed.
About "pmu_hclk_otg0" (the one clock from the original commit we're
still keeping critical) from an email thread:
> pmu ahb clock
>
> Function: Clock to pmu module when hibernation and/or ADP is
> enabled. Must be greater than or equal to 30 MHz.
>
> If the SOC design does not support hibernation/ADP function, only have
> hclk_otg, this clk can be switched according to the usage of otg.
> If the SOC design support hibernation/ADP, has two clocks, hclk_otg and
> pmu_hclk_otg0.
> Hclk_otg belongs to the closed part of otg logic, which can be switched
> according to the use of otg.
>
> pmu_hclk_otg0 belongs to the always on part.
>
> As for whether pmu_hclk_otg0 can be turned off when otg is not in use,
> we have not tested. IC suggest make pmu_hclk_otg0 always on.
For the rest of the clocks:
atclk: No documentation about this clock other than that it goes to
the CPU. CPU functions fine without it on. Maybe needed for JTAG?
jtag: Presumably this clock is only needed if you're debugging with
JTAG. It doesn't seem like it makes sense to waste power for every
rk3288 user. In any case to do JTAG you'd need private patches to
adjust the pinctrl the mux the JTAG out anyway.
pclk_dbg, pclk_core_niu: On veyron Chromebooks we turn these two
clocks on only during kernel panics in order to access some coresight
registers. Since nothing in the upstream kernel does this we should
be able to leave them off safely. Maybe also needed for JTAG?
hsicphy12m_xin12m: There is no indication of why this clock would need
to be turned on for boards that don't use HSIC.
pclk_ddrupctl[0-1], pclk_publ0[0-1]: On veyron Chromebooks we turn
these 4 clocks on only when doing DDR transitions and they are off
otherwise. I see no reason why they'd need to be on in the upstream
kernel which doesn't support DDRFreq.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Elaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
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 <dianders@chromium.org>
Reviewed-by: Elaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The USB PHY clock can be configured as (grand) parent of uart0_sclk and
sclk_gpu. It has been observed that UART0 doesn't work reliably in high
speed mode with the PHY clock as input when certain USB devices are
plugged to the USB HOST1 port (see https://crrev.com/c/320543).
Prefix the name of the PHY clock with a '.' in the non-USB muxes to
effectively remove the clock as input from these muxes.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
It appears that there is a typo in the rk3288 TRM. For
GRF_SOC_CON0[7] it says that 0 means "vepu" and 1 means "vdpu". It's
the other way around.
How do I know? Here's my evidence:
1. Prior to commit 4d3e84f996 ("clk: rockchip: describe aclk_vcodec
using the new muxgrf type on rk3288") we always pretended that we
were using "aclk_vdpu" and the comment in the code said that this
matched the default setting in the system. In fact the default
setting is 0 according to the TRM and according to reading memory
at bootup. In addition rk3288-based Chromebooks ran like this and
the video codecs worked.
2. With the existing clock code if you boot up and try to enable the
new VIDEO_ROCKCHIP_VPU as a module (and without "clk_ignore_unused"
on the command line), you get errors like "failed to get ack on
domain 'pd_video', val=0x80208". After flipping vepu/vdpu things
init OK.
3. If I export and add both the vepu and vdpu to the list of clocks
for RK3288_PD_VIDEO I can get past the power domain errors, but now
I freeze when the vpu_mmu gets initted.
4. If I just mark the "vdpu" as IGNORE_UNUSED then everything boots up
and probes OK showing that somehow the "vdpu" was important to keep
enabled. This is because we were actually using it as a parent.
5. After this change I can hack "aclk_vcodec_pre" to parent from
"aclk_vepu" using assigned-clocks and the video codec still probes
OK.
6. Rockchip has said so on the mailing list [1].
...so let's fix it.
Let's also add CLK_SET_RATE_PARENT to "aclk_vcodec_pre" as suggested
by Jonas Karlman. Prior to the same commit you could do
clk_set_rate() on "aclk_vcodec" and it would change "aclk_vdpu".
That's because "aclk_vcodec" was a simple gate clock (always gets
CLK_SET_RATE_PARENT) and its direct parent was "aclk_vdpu". After
that commit "aclk_vcodec_pre" gets in the way so we need to add
CLK_SET_RATE_PARENT to it too.
[1] https://lkml.kernel.org/r/1d17b015-9e17-34b9-baf8-c285dc1957aa@rock-chips.com
Fixes: 4d3e84f996 ("clk: rockchip: describe aclk_vcodec using the new muxgrf type on rk3288")
Suggested-by: Jonas Karlman <jonas@kwiboo.se>
Suggested-by: Randy Li <ayaka@soulik.info>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Most rk3288-based boards are derived from the EVB and thus use a PWM
regulator for the logic rail. However, most rk3288-based boards don't
specify the PWM regulator in their device tree. We'll deal with that
by making it critical.
NOTE: it's important to make it critical and not just IGNORE_UNUSED
because all PWMs in the system share the same clock. We don't want
another PWM user to turn the clock on and off and kill the logic rail.
This change is in preparation for actually having the PWMs in the
rk3288 device tree actually point to the proper PWM clock. Up until
now they've all pointed to the clock for the old IP block and they've
all worked due to the fact that rkpwm was IGNORE_UNUSED and that the
clock rates for both clocks were the same.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add and correct PLL rates for better hdmi output.
This includes minimizing jitter on 213 MHz for better 71 MHz,
250.5 MHz for better 83.5 MHz, 428 MHz for better 25.175 Mhz,
low jitter 273 MHz for better 68.25 mhz, 356 MHz for better 118.68 Mhz
and 300MHz.
Increase the used Fvco for 308, 324 MHz, 292.5 MHz, 273.6 MHz,
238 MHz and 216 MHz.
And add some additional rates allowing to reach better hdmi-related
rates in general.
These match the rates used by ChromeOS, so have been quite widely tested.
Signed-off-by: Urja Rannikko <urjaman@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The atclk/dbg/jtag/hsic-xin12m/pclk_core clks no driver to handle them.
But this clks need enable,so make it as ignore_unused for now.
The ddrupctl0/ddrupctl1/publ0/publ1 clks no driver to handle them,
Chip design requirements for these clock to always on,
The pmu_hclk_otg0 is Chip design defect, must be always on,
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
NIU clocks are related to the interconnect and it's important to other blocks.
Since we don't have a driver to handle it, we should always enable it to avoid
casually close.
Make all of them critical,so that we don't have to each clock on its own
once things break.
Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
[dropped the matching CLK_IGNORE_UNUSED flags]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reference the newly added vip clock-ids in the clock-tree.
Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reference the newly added isp clock-ids in the clock-tree.
Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
With the newly introduced clk type for muxes in the grf we now can
describe some missing clocks, like the aclk_vcodec that selects between
aclk_vdpu and aclk_vepu based on a bit set in the general register files.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
We should call iounmap to relase reg_base since it's not going
to be used any more if failing to init clk.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
There are need to support Multi-CRUs probability in future, but
it is not supported on the current Rockchip Clock Framework.
Therefore, this patch add support a provider as the parameter
handler when we call the clock register functions for per CRU.
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Thers are only two parent PLLs that APLL and GPLL for core on the
previous SoCs (RK3066/RK3188/RK3288/RK3368). Hence, we set fixed
GPLL as alternate parent when core is switching freq.
Since RK3399 big.LITTLE architecture, we need to select and adapt
more PLLs (ALPLL/ABPLL/DPLL/GPLL) sources.
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Clean up the init code and move the creation of factor clocks to the
appropriate positions coming from the clock architecture diagrams.
This also unifies the artificial separation of the hclk_vcodec etc clocks
again.
We do keep the separate definition of some watchdog and usb480m pseudo
clocks for now, as they're not real factor clocks from the clock-tree
but placeholders for fixes to come (usb480m gets supplied by the
missing driver for the new usbphy type and the watchdog-gate is sitting
somewhere else together which we cannot model currently).
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The otgphy clocks really only drive the phy blocks. These in turn
contain plls that then generate the 480m clocks the clock controller
uses to supply some other clocks like uart0, gpu or the video-codec.
So fix this structure to actually respect that hirarchy and removed
that usb480m fixed-rate clock working as a placeholder till now, as
this wouldn't even work if the supplying phy gets turned off while
its pll-output gets used elsewhere.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Michael Turquette <mturquette@baylibre.com>
To model the muxes downstream of fractional dividers we introduced the
child property, allowing to describe a direct child clock.
The first implementation seems to cause section warnings, as the core
clock-tree is marked as initdata while the data pointed to from the
child element is not.
While there may be some way to also set that missing property in the
inline notation I didn't find it, so to actually fix the issue for now
move the sub-definitions into separate declarations that can have
their own __initdata properties.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Michael Turquette <mturquette@baylibre.com>
The clock branches leading to sclk_spdif and sclk_spdif_8ch on RK3288
SoCs only feed those clocks, allow those clocks to change their parents
all the way up the hierarchy.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Michael Turquette <mturquette@baylibre.com>
Use the newly introduced possibility to combine the fractional dividers
with their downstream muxes for all fractional dividers on currently
supported Rockchip SoCs.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Reviewed-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Signed-off-by: Michael Turquette <mturquette@baylibre.com>
As commit 1d33929e2a ("clk: rockchip: switch PLLs to slow mode before
reboot for rk3288") states, switching the PLLs to slow-mode is only
necessary when rebooting using the soft-reset done through the CRU.
The dwc2 controllers used create really big number of interrupts in
special constellations involving usb-hubs and their number is so high,
it can even overwhelm the interrupt handler if the cpu-speed os to low.
Right now the PLLs are put into slow-mode in a shutdown syscore_ops
callback which means it happens on all reboots (not only the soft-reset
ones) and even on poweroff actions.
This can result in the system not powering off and getting stuck instead,
so we should move the slow-mode change nearer to the actual reboot action.
For this we introduce the possiblity to also set a callback that gets
called from the restart-handler directly prior to restarting the system
and move the shutdown-callback to this new option.
With this the slow-mode switch is done only on the necessary reboots
and also has a smaller possibility of causing artifacts.
Fixes: 1d33929e2a ("clk: rockchip: switch PLLs to slow mode before reboot for rk3288")
Signed-off-by: Heiko Stuebner <heiko.stuebner@collabora.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reference the newly added efuse clock-ids in the clock-tree.
Signed-off-by: ZhengShunQian <zhengsq@rock-chips.com>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
We've been seeing some crashes at reboot test on rk3288-based systems,
which boards have not reset pin connected to NPOR, they reboot by
setting 0xfdb9 to RK3288_GLB_SRST_FST register. If the APLL works in
a high frequency mode, some IPs might hang during soft reset.
It appears that we can fix the problem by switching to slow mode before
reboot, just like what we did before suspend.
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
sclk_mipidsi_24m is the gating of mipi dsi phy.
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Set the newly added id for the crypto clk, so that it can be called
in other parts.
Signed-off-by: Zain Wang <zain.wang@rock-chips.com>
Acked-by: Michael Turquette <mturquette@baylibre.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
cycle
Core changes:
- It is possible configure groups in debugfs.
- Consolidation of chained IRQ handler install/remove replacing
all call sites where irq_set_handler_data() and
irq_set_chained_handler() were done in succession with a
combined call to irq_set_chained_handler_and_data(). This
series was created by Thomas Gleixner after the problem was
observed by Russell King.
- Tglx also made another series of patches switching
__irq_set_handler_locked() for irq_set_handler_locked() which
is way cleaner.
- Tglx also wrote a good bunch of patches to make use of
irq_desc_get_xxx() accessors and avoid looking up irq_descs
from IRQ numbers. The goal is to get rid of the irq number
from the handlers in the IRQ flow which is nice.
Driver feature enhancements:
- Power management support for the SiRF SoC Atlas 7.
- Power down support for the Qualcomm driver.
- Intel Cherryview and Baytrail: switch drivers to use raw
spinlocks in IRQ handlers to play nice with the realtime
patch set.
- Rework and new modes handling for Qualcomm SPMI-MPP.
- Pinconf power source config for SH PFC.
New drivers and subdrivers:
- A new driver for Conexant Digicolor CX92755.
- A new driver for UniPhier PH1-LD4, PH1-Pro4, PH1-sLD8,
PH1-Pro5, ProXtream2 and PH1-LD6b SoC pin control support.
- Reverse-egineered the S/PDIF settings for the Allwinner
sun4i driver.
- Support for Qualcomm Technologies QDF2xxx ARM64 SoCs
- A new Freescale i.mx6ul subdriver.
Cleanup:
- Remove platform data support in a number of SH PFC
subdrivers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJV6YzgAAoJEEEQszewGV1zbIAQAILzMrzWkxsy7bhvL4QdP5/K
OG3EodE//AE0G5gKugUDjg5t2lftdiIJVhjDA17ruETCSciuAxZSLThlMy1sQgyN
LPxy9LlCrmsqrYt9+fmJ9js8j52RBJikKK0RUyUVz0VojTBplRpElyEx/KxwM5sG
Hy3+hU61uKO0j9AyIcsa/RKP6SGavwZdHytJBsHNw+pODyE3UZCf52ChAVBsTPfE
MV70g3Qzfqur7ZFqcNgtUV7qCyYvlF12ooiihrGFDOsTL3sSq4/OXB7z1z1mGGHL
Dgq8pXJ6EIZlCbk+jFMTzPRSzy46dxNai0eErjTUVEldH1tOphzGMvKmOdm/nczH
4M/UOWOKBE1aOYZNPtnUgDy2MRt5K9VJStCNSHEQCB2lGdojNAtmj2cmr8flBN5m
gM9FDpIS1/C+OYYTkOY9ftPsH5zOk7sCLEHSH5USYRGJHihzLnkV90eiN6a7vlF1
hyTGrIyl6e//E5JBgamjnR3+fYuxQGr6WeAZEP/gXZRm7BCKCaPwCarq+kPZVG4A
nolZ/QQN6XYPSlveSPU97VYvLYEUvXaKN0Hf2DTbwkqvNFp7JORD65QLESPtQoIp
x95iHMdB/1+0OfgOqMmlOtKpOKREeQ/R+KWACxsrr5Rfv3/7CP4BMRGypIZ/iPmz
HWoyDI4lIebBR+JnjMjK
=4QFX
-----END PGP SIGNATURE-----
Merge tag 'pinctrl-v4.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control updates from Linus Walleij:
"This is the bulk of pin control changes for the v4.3 development
cycle.
Like with GPIO it's a lot of stuff. If my subsystems are any sign of
the overall tempo of the kernel v4.3 will be a gigantic diff.
[ It looks like 4.3 is calmer than 4.2 in most other subsystems, but
we'll see - Linus ]
Core changes:
- It is possible configure groups in debugfs.
- Consolidation of chained IRQ handler install/remove replacing all
call sites where irq_set_handler_data() and
irq_set_chained_handler() were done in succession with a combined
call to irq_set_chained_handler_and_data(). This series was
created by Thomas Gleixner after the problem was observed by
Russell King.
- Tglx also made another series of patches switching
__irq_set_handler_locked() for irq_set_handler_locked() which is
way cleaner.
- Tglx also wrote a good bunch of patches to make use of
irq_desc_get_xxx() accessors and avoid looking up irq_descs from
IRQ numbers. The goal is to get rid of the irq number from the
handlers in the IRQ flow which is nice.
Driver feature enhancements:
- Power management support for the SiRF SoC Atlas 7.
- Power down support for the Qualcomm driver.
- Intel Cherryview and Baytrail: switch drivers to use raw spinlocks
in IRQ handlers to play nice with the realtime patch set.
- Rework and new modes handling for Qualcomm SPMI-MPP.
- Pinconf power source config for SH PFC.
New drivers and subdrivers:
- A new driver for Conexant Digicolor CX92755.
- A new driver for UniPhier PH1-LD4, PH1-Pro4, PH1-sLD8, PH1-Pro5,
ProXtream2 and PH1-LD6b SoC pin control support.
- Reverse-egineered the S/PDIF settings for the Allwinner sun4i
driver.
- Support for Qualcomm Technologies QDF2xxx ARM64 SoCs
- A new Freescale i.mx6ul subdriver.
Cleanup:
- Remove platform data support in a number of SH PFC subdrivers"
* tag 'pinctrl-v4.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (95 commits)
pinctrl: at91: fix null pointer dereference
pinctrl: mediatek: Implement wake handler and suspend resume
pinctrl: mediatek: Fix multiple registration issue.
pinctrl: sh-pfc: r8a7794: add USB pin groups
pinctrl: at91: Use generic irq_{request,release}_resources()
pinctrl: cherryview: Use raw_spinlock for locking
pinctrl: baytrail: Use raw_spinlock for locking
pinctrl: imx6ul: Remove .owner field
pinctrl: zynq: Fix typos in smc0_nand_grp and smc0_nor_grp
pinctrl: sh-pfc: Implement pinconf power-source param for voltage switching
clk: rockchip: add pclk_pd_pmu to the list of rk3288 critical clocks
pinctrl: sun4i: add spdif to pin description.
pinctrl: atlas7: clear ugly branch statements for pull and drivestrength
pinctrl: baytrail: Serialize all register access
pinctrl: baytrail: Drop FSF mailing address
pinctrl: rockchip: only enable gpio clock when it setting
pinctrl/mediatek: fix spelling mistake in dev_err error message
pinctrl: cherryview: Serialize all register access
pinctrl: UniPhier: PH1-Pro5: add I2C ch6 pin-mux setting
pinctrl: nomadik: reflect current input value
...
pclk_pd_pmu needs to keep running and with the upcoming gpio clock
handling this is not always the case anymore. So add it to the list
of critical clocks for now.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Lin Huang <hl@rock-chips.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
In the TRM we see that BWADJ is "a 12-bit bus that selects the values
1-4096 for the bandwidth divider (NB)":
NB = BWADJ[11:0] + 1
The recommended setting of NB: NB = NF / 2.
So:
NB = NF / 2
BWADJ[11:0] + 1 = NF / 2
BWADJ[11:0] = NF / 2 - 1
Right now, we have:
{ \
.rate = _rate##U, \
.nr = _nr, \
.nf = _nf, \
.no = _no, \
.bwadj = (_nf >> 1), \
}
That means we set bwadj to NF / 2, not NF / 2 - 1
All of this is a bit confusing because we specify "NR" (the 1-based
value), "NF" (the 1-based value), "NO" (the 1-based value), but
"BWADJ" (the 0-based value) instead of "NB" (the 1-based value).
Let's change to working with "NB" and fix the off by one error. This
may affect PLL jitter in a small way (hopefully for the better).
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Both soc series' have inverters on the hsadc and camera interface clock
paths. So define them using the newly added inverter type.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
The video input processor (vip) was called camera interface (cif) on
older socs which seems to have resulted in a copy'n'paste error when
creating the rk3288 camera clocks.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
The dwmac ethernet controller on the rk3288 supports phys connected
via rgmii and rmii. With rgmii phys it is expected that the mac clock
is provided externally while with rmii phys the clock can be external
but also generated from the plls. In the later case it of course needs
be at 50MHz, which gets set from the dwmac_rk driver.
As most devices use a rgmii phy it never surfaced so far that the mac
clk mux, doesn't go up one lever to the pll clock in the rmii case with
internal clock generation, as it is missing the CLK_SET_RATE_PARENT flag,
and thus will not set the correct frequency in most cases.
Fixes: b9e4ba5416 ("clk: rockchip: add clock controller for rk3288")
Cc: stable@vger.kernel.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Add missing static to local (file-scope only) symbols.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
The statement
static const char *name[];
defines a modifiable array of pointers to constant chars. That is
*name[0] = 'f';
is forbidden, but
name[0] = "f";
is not. So marking an array that is defined as above with __initconst is
wrong. Either an additional const must be added such that the whole
definition reads:
static const char *const name[] __initconst;
or where this is not possible __initdata must be used.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
enhancements and fixes mostly for ARM32, ARM64, MIPS and Power-based
devices. Additionaly the framework core underwent a bit of surgery with
two major changes. The boundary between the clock core and clock
providers (e.g clock drivers) is now more well defined with dedicated
provider helper functions. struct clk no longer maps 1:1 with the
hardware clock but is a true per-user cookie which helps us tracker
users of hardware clocks and debug bad behavior. The second major change
is the addition of rate constraints for clocks. Rate ranges are now
supported which are analogous to the voltage ranges in the regulator
framework. Unfortunately these changes to the core created some
breakeage. We think we fixed it all up but for this reason there are
lots of last minute commits trying to undo the damage.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJU54D5AAoJEDqPOy9afJhJs6AQAK5YuUwjDchdpNZx9p7OnT1q
+poehuUwE/gYjmdACqYFyaPrI/9f43iNCfFAgKGLQqmB5ZK4sm4ktzfBEhjWINR2
iiCx9QYMQVGiKwC8KU0ddeBciglE2b/DwxB45m9TsJEjowucUeBzwLEIj5DsGxf7
teXRoOWgXdz1MkQJ4pnA09Q3qEPQgmu8prhMfka/v75/yn7nb9VWiJ6seR2GqTKY
sIKL9WbKjN4AzctggdqHnMSIqZoq6vew850bv2C1fPn7GiYFQfWW+jvMlVY40dp8
nNa2ixSQSIXVw4fCtZhTIZcIvZ8puc7WVLcl8fz3mUe3VJn1VaGs0E+Yd3GexpIV
7bwkTOIdS8gSRlsUaIPiMnUob5TUMmMqjF4KIh/AhP4dYrmVbU7Ie8ccvSxe31Ku
lK7ww6BFv3KweTnW/58856ZXDlXLC6x3KT+Fw58L23VhPToFgYOdTxn8AVtE/LKP
YR3UnY9BqFx6WHXVoNvg3Piyej7RH8fYmE9om8tyWc/Ab8Eo501SHs9l3b2J8snf
w/5STd2CYxyKf1/9JLGnBvGo754O9NvdzBttRlygB14gCCtS/SDk/ELG2Ae+/a9P
YgRk2+257h8PMD3qlp94dLidEZN4kYxP/J6oj0t1/TIkERWfZjzkg5tKn3/hEcU9
qM97ZBTplTm6FM+Dt/Vk
=zCVK
-----END PGP SIGNATURE-----
Merge tag 'clk-for-linus-3.20' of git://git.linaro.org/people/mike.turquette/linux
Pull clock framework updates from Mike Turquette:
"The clock framework changes contain the usual driver additions,
enhancements and fixes mostly for ARM32, ARM64, MIPS and Power-based
devices.
Additionally the framework core underwent a bit of surgery with two
major changes:
- The boundary between the clock core and clock providers (e.g clock
drivers) is now more well defined with dedicated provider helper
functions. struct clk no longer maps 1:1 with the hardware clock
but is a true per-user cookie which helps us tracker users of
hardware clocks and debug bad behavior.
- The addition of rate constraints for clocks. Rate ranges are now
supported which are analogous to the voltage ranges in the
regulator framework.
Unfortunately these changes to the core created some breakeage. We
think we fixed it all up but for this reason there are lots of last
minute commits trying to undo the damage"
* tag 'clk-for-linus-3.20' of git://git.linaro.org/people/mike.turquette/linux: (113 commits)
clk: Only recalculate the rate if needed
Revert "clk: mxs: Fix invalid 32-bit access to frac registers"
clk: qoriq: Add support for the platform PLL
powerpc/corenet: Enable CLK_QORIQ
clk: Replace explicit clk assignment with __clk_hw_set_clk
clk: Add __clk_hw_set_clk helper function
clk: Don't dereference parent clock if is NULL
MIPS: Alchemy: Remove bogus args from alchemy_clk_fgcs_detr
clkdev: Always allocate a struct clk and call __clk_get() w/ CCF
clk: shmobile: div6: Avoid division by zero in .round_rate()
clk: mxs: Fix invalid 32-bit access to frac registers
clk: omap: compile legacy omap3 clocks conditionally
clkdev: Export clk_register_clkdev
clk: Add rate constraints to clocks
clk: remove clk-private.h
pci: xgene: do not use clk-private.h
arm: omap2+ remove dead clock code
clk: Make clk API return per-user struct clk instances
clk: tegra: Define PLLD_DSI and remove dsia(b)_mux
clk: tegra: Add support for the Tegra132 CAR IP block
...
Conflicts:
arch/arm/boot/dts/imx6sx-sdb.dts
net/sched/cls_bpf.c
Two simple sets of overlapping changes.
Signed-off-by: David S. Miller <davem@davemloft.net>
we currently only "fake" as the clock gate control is living in a
very strange place, but the watchdog driver needs to read the clock
rate from it and the setting of rk3288 plls to slow mode upon suspend.
Other than that some more exported clocks and a CLK_SET_RATE_PARENT
flag for the uart clocks.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABCAAGBQJUwT2NAAoJEPOmecmc0R2BjmsH/1Mp2vS9E9RBREhL/uuwtVlE
6FhINcpzVkDrwXGfupVbrWmzHTxKcyUbnluVPsLs0BCRqhhKSU0t+TT5j+mRMOpu
oNq/d3cp//fuBaiLr4G0jrgd/a9Gq4SsshPP6kH41r5CBN87jTt9wazX2GjNBf4C
LYsNNWj/qpXxeA/rFuMsI15ntPiFvap8Ag/5+IDCHuT9nwCLy7iI3G0MRGZ1kfGT
byOJd/FOqfAk3UJXuEgGOu27ZAOcbGLk7EL7YUdq7C70wAlUTu/8smTLqJFbXc9T
Xgum3FnYcuPZqNQSxQMXFpgyzE0q7KLyufv5gU1A4s2Ac69cD3nDVh9k1LAcu4s=
=arKA
-----END PGP SIGNATURE-----
Merge tag 'v3.20-rockchip-clk1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into clk-next
The two big changes are the additional of the watchdog clock, which
we currently only "fake" as the clock gate control is living in a
very strange place, but the watchdog driver needs to read the clock
rate from it and the setting of rk3288 plls to slow mode upon suspend.
Other than that some more exported clocks and a CLK_SET_RATE_PARENT
flag for the uart clocks.
The pclk supplying the watchdog is controlled via the SGRF register area.
Currently we don't have any clock-type handling external clock bits like
this one. Additionally the SGRF isn't even writable in every boot mode.
But still the clock control is available and in the future someone might
want to use it. Therefore define a simple clock for the time being so
that the watchdog driver can read its rate.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Process-Voltage-Temperatiure Monitor block on RK3288 has two clocks:
PVTM_CORE and PVTM_GPU.
Signed-off-by: Huang Lin <hl@rock-chips.com>
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Use the clock ID for usbphy480m_src so that we can find
this clock node in dts.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
modify CRU config for GMAC driver
changes since v2:
1. remove SCLK_MAC_PLL
Signed-off-by: Roger Chen <roger.chen@rock-chips.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We've been seeing some crashes at resume time on rk3288-based systems.
On some machines they simply never wake up from suspend. Symptoms
include:
- System clearly got to sleep OK. Power consumption is low, the PWM
for the PWM regulator has stopped, and the "global_pwroff" output
shows that the system is down.
- When system tries to wake up power consumption goes up.
- No kernel resume code (which was left in PMU SRAM) ran. We added
some basic logging to this code (write to a location in SRAM right
at resume time) and didn't see the logging run.
It appears that we can fix the problem by slowing down APLL before we
suspend. On the system I tested things seemed reliable if I disabled
1.8GHz and 1.7GHz. The Mask ROM itself tries to slow things down
(which is why PLLs are in slow mode by the time we get to the kernel),
but apparently it is crashing before it even gets there.
We'll be super paranoid and not just go down to 1.6GHz but we'll match
what the Mask ROM seems to be doing and go into slow mode. We'll also
be safe and put all PLLs (not just APLL) into slow mode (well, except
DPLL which is needed for SDRAM). We'll even put NPLL into slow mode
which the Mask ROM didn't do (not that it's used for much important
stuff at early resume time).
Note that the old Rockchip reference code did something just like
this, though they jammed it into pm.c instead of putting it in the
syscore ops of the clock driver.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Commit 0e5bdb3f9f (clk: rockchip: switch to using the new cpuclk type
for armclk) didn't take into account that the divider used on rk3288
are of the (n+1) type.
The rk3066 and rk3188 socs use more complex divider types making it
necessary for the list-elements to be the real register-values to write.
Therefore reduce divider values in the table accordingly so that they
really are the values that should be written to the registers and match
the dividers actually specified for the rk3288.
Reported-by: Sonny Rao <sonnyrao@chromium.org>
Fixes: 0e5bdb3f9f ("clk: rockchip: switch to using the new cpuclk type for armclk")
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Cc: stable@vger.kernel.org
We'd like to be able to set the clock rate of the sclk_uart clocks and
actually be able to achieve clock rates greater than 24MHz. To do
this we need to be able to pass rate changes upward.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
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>
This exposes the clock that comes out of the i2s block which generally
goes to the audio codec.
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
[removed CLK_SET_RATE_PARENT from original patch]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The DMC clocks need to be turned off at runtime. Use the newly
assigned clock IDs to export them.
Signed-off-by: Jeff Chen <cym@rock-chips.com>
[dianders: split into two patches; adjusted commit msg]
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add the new flag to gpll and cpll on rk3188 and similar and to
gpll, cpll and npll on rk3288.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Tested-by: Kever Yang <kever.yang@rock-chips.com>
This adds a flag parameter to plls that allows us to create
special flags to tweak the behaviour of the plls if necessary.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Tested-by: Kever Yang <kever.yang@rock-chips.com>
Stephen Boyd