Switch from the "_ro" clock op variants to the mutable ones for all
video clocks. This will allow the VPU driver to change the clocks as
needed for the different video output modes.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20210713232510.3057750-6-martin.blumenstingl@googlemail.com
Add the reg_sequence to initialize the HDMI PLL with the settings for
a video mode that doesn't require PLL internal clock doubling. These
settings are taken from the 3.10 vendor kernel's driver for the 2970MHz
PLL setting used for the 1080P video mode. This puts the PLL into a
defined state and the Linux kernel can take over.
While not all bits for this PLL are implemented using these "defaults"
and then applying M, N and FRAC seems to work fine.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20210713232510.3057750-5-martin.blumenstingl@googlemail.com
The 3.10 vendor kernel uses only specific HDMI PLL M/N parameter
combinations. The PLL won't lock for values smaller than 50 if the
internal doubling (which is yet unknown how to use it) is disabled.
However, when this doubling is enabled then the values smaller than 50
will lock just fine. The only restriction for values greater than 50 is
that the resulting frequency must not exceed the 3.0GHz limit.
These values are taken from the endlessm 3.10 kernel which includes
additional M/N combinations for some VESA and 75Hz display modes.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20210713232510.3057750-4-martin.blumenstingl@googlemail.com
HHI_VID_DIVIDER_CNTL[11] must be enabled for the video clock tree to
work. This bit is described as "LVDS_CLK_EN". It is not 100% clear where
this bit has to be placed in the hierarchy. But since the "LVDS_OUT" of
the HDMI PLL uses it's own set of registers it's more likely that this
"LVDS_CLK_EN" bit actually enables the input of the "hdmi_pll_lvds_out"
clock to the "vid_pll_in_sel" tree.
Add a gate definition for this bit (which will not be exported) so that
the kernel can manage all required bits to enable and disable the video
clocks.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20210713232510.3057750-3-martin.blumenstingl@googlemail.com
Use CLK_SET_RATE_NO_REPARENT for the vclk{,2}_in_sel clocks. The only
parent which is actually used is vid_pll_final_div. This should be set
using assigned-clock-parents in the .dts rather than removing some
"unwanted" clock parents from the clock driver.
Suggested-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20210713232510.3057750-2-martin.blumenstingl@googlemail.com
The XTAL clock is provided via .dts since Linux 5.6. Remove
compatibility code for .dtbs which are older than that.
The switch to the HHI syscon has been done with Linux 5.1. Also remove
any code needed to support .dtbs that have not switched to the HHI
syscon yet.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20201221183624.932649-2-martin.blumenstingl@googlemail.com
HHI_VIID_CLK_CNTL[19] is not part of the public S805 datasheet. However,
the GXBB driver defines this bit as a gate called "vclk2" and in the
3.10 kernel GPL code dump the following line can found:
WRITE_LCD_CBUS_REG_BITS(HHI_VIID_CLK_CNTL, 0, 19, 1); //disable vclk2_en
Add this gate clock to the Meson8/Meson8b/Meson8m2 clock controller to
complete the VCLK2 clock tree.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20200629203904.2989007-3-martin.blumenstingl@googlemail.com
HHI_VID_CLK_CNTL[19] is documented as CLK_EN0. This description is the
same in the public S912 datasheet and the GXBB driver calls this gate
"vclk". Add this gate clock to the Meson8/Meson8b/Meson8m2 clock
controller because it's needed to make the video output work.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20200629203904.2989007-2-martin.blumenstingl@googlemail.com
Drop CLK_IS_CRITICAL from fclk_div2. This was added because we didn't
know the relation between this clock and RGMII Ethernet. It turns out
that fclk_div2 is used as "timing adjustment clock" to generate the RX
delay on the MAC side - which was enabled by u-boot on Odriod-C1. When
using the RX delay on the PHY side or not using a RX delay at all then
this clock can be disabled.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20200620161422.24114-1-martin.blumenstingl@googlemail.com
Not all u-boot versions initialize the HHI_GP_PLL_CNTL[2-5] registers.
In that case all HHI_GPLL_PLL_CNTL[1-5] registers are 0x0 and when
booting Linux the PLL fails to lock.
The initialization sequence from u-boot is:
- put the PLL into reset
- write 0x59C88000 to HHI_GP_PLL_CNTL2
- write 0xCA463823 to HHI_GP_PLL_CNTL3
- write 0x0286A027 to HHI_GP_PLL_CNTL4
- write 0x00003000 to HHI_GP_PLL_CNTL5
- set M, N, OD and the enable bit
- take the PLL out of reset
- check if it has locked
- disable the PLL
In Linux we already initialize M, N, OD, the enable and the reset bits.
Also the HHI_GP_PLL_CNTL[2-5] registers with these magic values (the
exact meaning is unknown) so the PLL can lock when the vendor u-boot did
not initialize these registers yet.
Fixes: b882964b37 ("clk: meson: meson8b: add support for the GP_PLL clock on Meson8m2")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20200501215717.735393-1-martin.blumenstingl@googlemail.com
The "vpu_0" or "vpu_1" clock trees should not be updated while the
clock is running. Enforce this by setting CLK_SET_RATE_GATE on the
"vpu_0" and "vpu_1" gates. This makes the CCF switch to the "vpu_1"
tree when "vpu_0" is currently active and vice versa, which is exactly
what the vendor driver does when updating the frequency of the VPU
clock.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20200417184127.1319871-5-martin.blumenstingl@googlemail.com
The DIV{1,2,4,6,12}_EN bits are actually located in HHI_VID_CLK_CNTL
register:
- HHI_VID_CLK_CNTL[0] = DIV1_EN
- HHI_VID_CLK_CNTL[1] = DIV2_EN
- HHI_VID_CLK_CNTL[2] = DIV4_EN
- HHI_VID_CLK_CNTL[3] = DIV6_EN
- HHI_VID_CLK_CNTL[4] = DIV12_EN
Update the bits accordingly so we will enable the bits in the correct
register once we switch these clocks to be mutable.
Fixes: 6cb57c678b ("clk: meson: meson8b: add the read-only video clock trees")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20200417184127.1319871-4-martin.blumenstingl@googlemail.com
CLKC_RESET_VID_DIVIDER_CNTL_RESET_N_POST and
CLKC_RESET_VID_DIVIDER_CNTL_RESET_N_PRE are active low. This means:
- asserting them requires setting the register value to 0
- de-asserting them requires setting the register value to 1
Set the register value accordingly for these two reset lines by setting
the inverted the register value compared to all other reset lines.
Fixes: 189621726b ("clk: meson: meson8b: register the built-in reset controller")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20200417184127.1319871-3-martin.blumenstingl@googlemail.com
Use hdmi_pll_lvds_out as parent of the vid_pll_in_sel clock. It's not
easy to see that the vendor kernel does the same, but it actually does.
meson_clk_pll_ops in mainline still cannot fully recalculate all rates
from the HDMI PLL registers because some register bits (at the time of
writing it's unknown which bits are used for this) double the HDMI PLL
output rate (compared to simply considering M, N and FRAC) for some (but
not all) PLL settings.
Update the vid_pll_in_sel parent so our clock calculation works for
simple clock settings like the CVBS output (where no rate doubling is
going on). The PLL ops need to be fixed later on for more complex clock
settings (all HDMI rates).
Fixes: 6cb57c678b ("clk: meson: meson8b: add the read-only video clock trees")
Suggested-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20200417184127.1319871-2-martin.blumenstingl@googlemail.com
The HDMI TX controller requires the hdmi_sys clock to be enabled. Allow
changing the whole clock tree now that we know that one of our drivers
requires this.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20200330234535.3327513-3-martin.blumenstingl@googlemail.com
The aiu devices peripheral clocks needs the aiu and aiu_glue clocks to
operate. Reflect this hierarchy in the clock tree.
Fixes: e31a1900c1 ("meson: clk: Add support for clock gates")
Suggested-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
The "mali_0" or "mali_1" clock trees should not be updated while the
clock is running. Enforce this by setting CLK_SET_RATE_GATE on the
"mali_0" and "mali_1" gates. This makes the CCF switch to the "mali_1"
tree when "mali_0" is currently active and vice versa, which is exactly
what the vendor driver does when updating the frequency of the mali
clock.
This fixes a potential hang when changing the GPU frequency at runtime.
Fixes: 74e1f2521f ("clk: meson: meson8b: add the GPU clock tree")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Switch from clk_hw_register to of_clk_hw_register so we can use
clk_parent_data.fw_name. This will be used to get the "xtal", "ddr_pll"
and possibly others from the .dtb.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
The XTAL clock is an actual crystal on the PCB. Thus the meson8b clock
driver should not register the XTAL clock - instead it should be
provided via .dts and then passed to the clock controller.
Skip the registration of the XTAL clock if a parent clock is provided
via OF. Fall back to registering the XTAL clock if this is not the case
to keep support for old .dtbs.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
The XTAL clock is an actual crystal which is mounted on the PCB. Thus
the meson8b clock controller driver should not provide the XTAL clock.
The meson8b clock controller driver must not use references to
the meson8b_xtal clock anymore before we can provide the XTAL clock
via OF. Replace the references to the meson8b_xtal.hw by using
clk_parent_data's .fw_name and .name = "xtal" (along with index = -1).
This makes the common clock framework use the clock provided via OF and
if that's not available it falls back to getting the clock by it's name
(which is then the clk_fixed_rate which we register in our driver).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Switch from clk_set_parent() to clk_hw_set_parent() now that we have a
way to configure a mux clock based on clk_hw pointers. This simplifies
the meson8b_cpu_clk_notifier_cb logic. No functional changes.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
This clock controller use the string comparison method to describe parent
relation between the clocks, which is not optimized.
Migrate to the new way by using .parent_hws where possible (ie. when
all clocks are local to the controller) and use .parent_data otherwise.
Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
This clock controller use the string comparison method to describe parent
relation between the clocks, which is not optimized.
Migrate to the new way by using .parent_hws where possible (ie. when
all clocks are local to the controller) and use .parent_data otherwise.
Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Add the cts_i958 clock to control the clock source of the spdif output
block. It is used to select whether the clock source of the spdif output
is cts_amclk (when data are taken from i2s buffer) or the cts_mclk_i958
(when data are taken from the spdif buffer). The setup for this clock is
identical to GXBB, so this ports commit 7eaa44f620 ("clk: meson:
gxbb: add cts_i958 clock") to the Meson8/Meson8b/Meson8m2 clock driver.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Add the SPDIF master clock also referred as cts_mclk_i958. The setup for
this clock is identical to GXBB, so this ports commit 3c277c247e
("clk: meson: gxbb: add cts_mclk_i958") to the Meson8/Meson8b/Meson8m2
clock driver.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Add the I2S master clock also referred as cts_amclk. The setup for this
clock is identical to GXBB, so this ports commit 4087bd4b21 ("clk:
meson: gxbb: add cts_amclk") to the Meson8/Meson8b/Meson8m2 clock
driver.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
The variable which holds the parent names for the VPU clocks has a typo
in it. Fix this typo to make the variable naming in the driver
consistent. No functional changes.
Fixes: 41785ce562 ("clk: meson: meson8b: add the VPU clock trees")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
This adds the four video decoder clock trees.
VDEC_1 is split into two paths on Meson8b and Meson8m2:
- input mux called "vdec_1_sel"
- two dividers ("vdec_1_1_div" and "vdec_1_2_div") and gates ("vdec_1_1"
and "vdec_1_2")
- and an output mux (probably glitch-free) called "vdec_1"
On Meson8 the VDEC_1 tree is simpler because there's only one path:
- input mux called "vdec_1_sel"
- divider ("vdec_1_1_div") and gate ("vdec_1_1")
- (the gate is used as output directly, there's no mux)
The VDEC_HCODEC and VDEC_2 clocks are simple composite clocks each
consisting of an input mux, divider and a gate.
The VDEC_HEVC clock seems to have two paths similar to the VDEC_1 clock.
However, the register offsets of the second clock path is not known.
Amlogic's 3.10 kernel (which is used as reference) sets
HHI_VDEC2_CLK_CNTL[31] to 1 before changing the VDEC_HEVC clock and back
to 0 afterwards. For now, leave a TODO comment and only add the first
path.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Maxime Jourdan <mjourdan@baylibre.com>
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lkml.kernel.org/r/20190324151423.19063-3-martin.blumenstingl@googlemail.com
The VPU clock tree is slightly different on all three supported SoCs:
Meson8 only has an input mux (which chooses between "fclk_div4",
"fclk_div3", "fclk_div5" and "fclk_div7"), a divider and a gate.
Meson8b has two VPU clock trees, each with an input mux (using the same
parents as the input mux on Meson8), divider and a gates. The final VPU
clock is a glitch-free mux which chooses between VPU_1 and VPU_2.
Meson8m2 uses a similar clock tree as Meson8b but the last input clock
is different: instead of using "fclk_div7" as input Meson8m2 uses
"gp_pll". This was probably done in hardware to improve the accuracy of
the clock because fclk_div7 gives us 2550MHz / 7 = 364.286MHz while
GP_PLL can achieve 364.0MHz.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lkml.kernel.org/r/20190324151104.18397-5-martin.blumenstingl@googlemail.com
Meson8m2 has a GP_PLL clock (similar to GP0_PLL on GXBB/GXL/GXM) which
is used as input for the VPU clocks.
The only supported frequency (based on Amlogic's vendor kernel sources)
is 364MHz which is achieved using the following parameters:
- input: XTAL (24MHz)
- M = 182
- N = 3
- OD = 2 ^ 2
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lkml.kernel.org/r/20190324151104.18397-4-martin.blumenstingl@googlemail.com
Meson8, Meson8b and Meson8m2 implement a similar clock controller.
However, there are a few differences between the three actual IP blocks.
One example where Meson8m2 differs from Meson8b is the VPU clock setup:
- the VPU input mux can choose between "fclk_div4", "fclk_div3",
"fclk_div5" and "fclk_div7" on Meson8b
- however, on Meson8m2 it can choose between "fclk_div4", "fclk_div3",
"fclk_div5" and "gp_pll" (GP_PLL only exists on Meson8m2, it's the
predecessor of the GP0_PLL clock on GXBB/GXL/GXM))
Add a separate clk_hw_onecell_data table for Meson8m2 so these
differences can be implemented in our clock controller driver. For now
meson8m2_hw_onecell_data is a clone of our existing
meson8b_hw_onecell_data.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lkml.kernel.org/r/20190324151104.18397-3-martin.blumenstingl@googlemail.com
Fix a typo in the APB clock names by renaming them from "abp" to "apb".
No functional changes.
Fixes: a7d19b05ce ("clk: meson: meson8b: add the CPU clock post divider clocks")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lkml.kernel.org/r/20190210222603.6404-2-martin.blumenstingl@googlemail.com
Initially, the meson clock directory only hosted 2 controllers drivers,
for meson8 and gxbb. At the time, both used the same set of clock drivers
so managing the dependencies was not a big concern.
Since this ancient time, entropy did its job, controllers with different
requirement and specific clock drivers have been added. Unfortunately, we
did not do a great job at managing the dependencies between the
controllers and the different clock drivers. Some drivers, such as
clk-phase or vid-pll-div, are compiled even if they are useless on the
target (meson8). As we are adding new controllers, we need to be able to
pick a driver w/o pulling the whole thing.
The patch aims to clean things up by:
* providing a dedicated CONFIG_ for each clock drivers
* allowing clock drivers to be compiled as a modules, if possible
* stating explicitly which drivers are required by each controller.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lkml.kernel.org/r/20190201125841.26785-5-jbrunet@baylibre.com
Add the GPU clock tree on Meson8, Meson8b and Meson8m2.
The GPU clock tree on Meson8b and Meson8m2 is almost identical to the
one one GXBB:
- there's a glitch-free mux at HHI_MALI_CLK_CNTL[31]
- there are two identical parents for this mux: mali_0 and mali_1, each
with a gate, divider and mux
- the parents of mali_0_sel and mali_1_sel are identical to GXBB except
there's no GP0_PLL on these 32-bit SoCs
Meson8 is different because it does not have the glitch-free mux.
Instead if only has the mali_0 clock tree. The parents of mali_0_sel are
identical to the ones on Meson8b and Meson8m2.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lkml.kernel.org/r/20181208171247.22238-4-martin.blumenstingl@googlemail.com
The Meson8 SoC is slightly different compared to Meson8b and Meson8m2
because it does not have the glitch-free Mali GPU clock mux. For Meson8b
and Meson8m2 there are currently no known differences.
Add a separate clk_hw_onecell_data table for Meson8 so these differences
can be implemented. For now meson8_hw_onecell_data is a clone of our
existing meson8b_hw_onecell_data.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lkml.kernel.org/r/20181208171247.22238-3-martin.blumenstingl@googlemail.com
Add all clocks to give us the final video clocks within the Meson8,
Meson8b and Meson8m2 SoCs. The final video clocks are:
- cts_enct
- cts_encl
- cts_encp
- cts_enci
- cts_vdac0
- hdmi_tx_pixel
- hdmi_sys
Add multiple clocks in between which are needed to implement these
clocks:
- Opposed to GXBB there is no pre-multiplier for the PLL input. The
assumption here is that the multiplier is required to achieve the HDMI
2.0 clock rates (which are up to twice the rate of the HDMI 1.4
rates).
- The main PLL is called "HDMI PLL" or "HPLL" in the datasheet. Rename
our existing "vid_pll_dco" to "hdmi_pll_dco". The actual VID_PLL clock
also exists further down the tree.
- Rename the existing "vid_pll" clock (which is the OD divider at
HHI_VID_PLL_CNTL[17:16]) to "hdmi_pll_lvds_out" to match the naming
from the datasheet.
- Add the second OD divider called "hdmi_pll_hdmi_out" at
HHI_VID_PLL_CNTL[19:18].
- Add the "vid_pll_in_sel" which can choose between "hdmi_pll_dco" and
another parent. However, the second parent is not use on Amlogic's
3.10 kernel for HDMI or CVBS output so just leave a TODO in the code.
- Add the "vid_pll_in_en" which is located after "vid_pll_in_sel"
according to the datasheet.
- Add "vid_pll_pre_div" which is used for divide-by-5 and divide-by-6 in
Amlogic's 3.10 kernel sources.
- Add "vid_pll_post_div" which divides the output of "vid_pll_pre_div"
further down. The Amlogic 3.10 kernel configures this as divide-by-2
with "vid_pll_pre_div" being configured as divide-by-5 to achieve a
total divider of 10.
- Add the real "vid_pll" clock which selects between "vid_pll_pre_div",
"vid_pll_post_div" and a third "vid_pll_pre_div_mult7_div2" (which is
"vid_pll_pre_div" divided by 3.5). The latter is not supported yet
because it's not used in Amlogic's 3.10 kernel. The "vid_pll" clock
rate can also be measured by clkmsr to check whether this
implementation is correct.
- Add "vid_pll_final_div" which is a post-divider for "vid_pll" and it's
used as input for "vclk" and "vclk2"
- Add the two symmetric "vclk" and "vclk" clock trees, each with a
divide-by-1, divide-by-2, divide-by-4, divide-by-6 and divide-by-12
clock and a divider for each clock.
- Add the "cts_enct", "cts_encp" and "hdmi_tx_pixel" clocks which each
have their own gate and can select between any of the five "vclk"
dividers.
- Add the "cts_encl" and "cts_vdac0" clocks which each have their own
gate and can select between any of the five "vclk2" dividers.
The "hdmi_sys" clock is a different than these video clocks. It takes
"xtal" as input (there are three more but unknown parents). Add this
clock as well as it's used by the HDMI controller. Amlogic's 3.10 kernel
always configures this as "xtal divided by 1", so we can ignore the
other parents for now.
This was tested on Meson8b and Meson8m2 boards by comparing the common
clock framework output with the clock measurer output. The following
video modes were first set in u-boot (by running "video dev open $mode")
before booting Linux:
4K2K30HZ (only supported by Meson8m2, not tested on Meson8b):
- vid_pll: 297000000Hz
- cts_encp: 297000000Hz
- hdmi_tx_pixel: 297000000Hz
1080P:
- vid_pll: 148500000Hz
- cts_encp: 148500000Hz
- hdmi_tx_pixel: 148500000Hz
720P:
- vid_pll: 148500000Hz
- cts_encp: 148500000Hz
- hdmi_tx_pixel: 74250000Hz
480P:
- vid_pll: 216000000Hz
- cts_encp: 54000000Hz
- hdmi_tx_pixel: 27000000Hz
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lkml.kernel.org/r/20181202214220.7715-4-martin.blumenstingl@googlemail.com
This "vid_pll_dco" (which should be named HDMI_PLL or - as the datasheet
calls it - HPLL) has a 12-bit wide fractional parameter at
HHI_VID_PLL_CNTL2[11:0]. Add this so we correctly calculate the rate of
this PLL when u-boot is configured for a video mode which uses this
fractional parameter.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lkml.kernel.org/r/20181202214220.7715-3-martin.blumenstingl@googlemail.com
Unlike the other PLLs on Meson8b the N value "vid_pll_dco" (a better
name would be hdmi_pll_dco or - as the datasheet calls it - HPLL) is
located at HHI_VID_PLL_CNTL[14:10] instead of [13:9].
This results in an incorrect calculation of the rate of this PLL because
the value seen by the kernel is double the actual N (divider) value.
Update the offset of the N value to fix the calculation of the PLL rate.
Fixes: 28b9fcd016 ("clk: meson8b: Add support for Meson8b clocks")
Reported-by: Jianxin Pan <jianxin.pan@amlogic.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lkml.kernel.org/r/20181202214220.7715-2-martin.blumenstingl@googlemail.com
There are four CPU clock post dividers:
- ABP
- PERIPH (used for the ARM global timer and ARM TWD timer)
- AXI
- L2 DRAM
Each of these clocks consists of two clocks:
- a mux to select between "cpu_clk" divided by 2, 3, 4, 5, 6, 7 or 8
- a "_clk_dis" gate. The public S805 datasheet states that this should
be set to 1 to disable the clock, the default value is 0. There is
also a hint that these are "just in case" bits which only exist in
case the corresponding mux implementation does not allow glitch-free
parent changes (the muxes are designed in a way that the clock can
stay enabled when changing the mux). It's still good practise to
describe this clock even if we're not supposed to modify it. Thus
this uses the read-only gate ops.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lkml.kernel.org/r/20181122214017.25643-5-martin.blumenstingl@googlemail.com
The "cpu_div2" and "cpu_div3" take "cpu_in" as input and divide that by
2 or 3. The clock controller can also generate various CPU clock
post-dividers (2, 3, 4, 5, 6, 7, 8) which are derived from "cpu_clk".
When adding support for these post-dividers our clock naming could be
misleading as we have "cpu_div2" as well as "cpu_clk_div2".
Rename the existing "cpu_in" dividers so the name of the divider's
parent is part of the divider clock's name.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lkml.kernel.org/r/20181122214017.25643-4-martin.blumenstingl@googlemail.com
Currently all clocks in the CPU clock tree are marked as read-only
(using the corresponding _ro_ clk_ops). This was correct since changing
the clock tree could cause the system to lock up.
Switch all clocks to their corresponding clk_ops variant which is not
read-only to allow changing the CPU clock tree since the bug which
locked up the system is now fixed (by switching the CPU clock temporary
to run off XTAL while changing the CPU clock tree).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lkml.kernel.org/r/20181115224048.13511-7-martin.blumenstingl@googlemail.com
Changing the CPU clock requires changing various clocks including the
SYS PLL. The existing meson clk-pll and clk-regmap drivers can change
all of the relevant clocks already.
However, changing for exampe the SYS PLL is problematic because as long
as the CPU is running off a clock derived from SYS PLL changing the
latter results in a full system lockup.
Fix this system lockup by switching the CPU clock to run off the XTAL
while we are changing the any of the clocks in the CPU clock tree.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lkml.kernel.org/r/20181115224048.13511-6-martin.blumenstingl@googlemail.com
The sys_pll on the EC-100 board is configured to 1584MHz at boot
(either by u-boot, firmware or chip defaults). This is achieved by using
M = 66, N = 1 (24MHz * 66 / 1).
At boot the CPU clock is running off sys_pll divided by 2 which results
in 792MHz. Thus M = 66 is considered to be a "safe" value for Meson8b.
To achieve 1608MHz (one of the CPU OPPs on Meson8 and Meson8m2) we need
M = 67, N = 1. I ran "stress --cpu 4" while infinitely cycling through
all available frequencies on my Meson8m2 board and could not spot any
issues with this setting (after ~12 hours of running this).
On Meson8, Meson8b and Meson8m2 we also want to be able to use 408MHz
and 816MHz CPU frequencies. These can be achieved by dividing sys_pll by
4 (for 408MHz) or 2 (for 816MHz). That means that sys_pll has to run at
1632MHz which can be generated using M = 68, N = 1.
Similarily we also want to be able to use 1008MHz as CPU frequency. This
means that sys_pll has to run either at 1008MHz or 2016MHz. The former
would result in an M value of 42, which is lower than the smallest value
used by the 3.10 GPL kernel sources from Amlogic (50 is the lower limit
there). Thus we need to run sys_pll at 2016MHz which can ge generated
using M = 84, N = 1.
I tested M = 68 and M = 84 on my Meson8b Odroid-C1 and my Meson8m2 board
by running "stress --cpu 4" while infinitely cycling thorugh all
available frequencies. I could not spot any issues after ~12 hours of
running this.
Amlogic's 3.10 GPL kernel sources have more M/N combinations. I did not
add them yet because M = 74 (to achieve close to 1800MHz on Meson8) and
M = 82 (to achieve close to 1992MHz on Meson8 as well) caused my
Meson8m2 board to hang randomly. It's not clear why this is (for example
because the board's voltage regulator design is bad, some missing bits
for these values in our clk-pll driver, etc.). Thus the following M
values from the Amlogic 3.10 GPL kernel sources are skipped as of now:
69, 70, 71, 72, 73, 74, 76, 78, 80, 82, 84, 86, 88, 90, 92, 94, 96, 98
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lkml.kernel.org/r/20181115224048.13511-5-martin.blumenstingl@googlemail.com
We don't want the common clock framework to disable the "cpu_clk" if
it's not used by any device. The cpufreq-dt driver does not enable the
CPU clocks. However, even if it would we would still want the CPU clock
to be enabled at all times because the CPU clock is also required even
if we disable CPU frequency scaling on a specific board.
The reason why we want the CPU clock to be enabled is a clock further up
in the tree:
Since commit 6f888e7bc7bd58 ("clk: meson: clk-pll: add enable bit") the
sys_pll can be disabled. However, since the CPU clock is derived from
sys_pll we don't want sys_pll to get disabled. The common clock
framework takes care of that for us by enabling all parent clocks of our
CPU clock when we mark the CPU clock with CLK_IS_CRITICAL.
Until now this is not a problem yet because all clocks in the CPU
clock's tree (including sys_pll) are read-only. However, once we allow
modifications to the clocks in that tree we will need this.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lkml.kernel.org/r/20181115224048.13511-4-martin.blumenstingl@googlemail.com
The cpu_div3 clock (cpu_in divided by 3) generates a signal with a duty
cycle of 33%. The CPU clock however requires a clock signal with a duty
cycle of 50% to run stable.
cpu_div3 was observed to be problematic when cycling through all
available CPU frequencies (with additional patches on top of this one)
while running "stress --cpu 4" in the background. This caused sporadic
hangs where the whole system would fully lock up.
Amlogic's 3.10 kernel code also does not use the cpu_div3 clock either
when changing the CPU clock.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lkml.kernel.org/r/20181115224048.13511-3-martin.blumenstingl@googlemail.com
According to the public S805 datasheet HHI_SYS_CPU_CLK_CNTL1[29:20] is
the register for the CPU scale_div clock. This matches the code in
Amlogic's 3.10 GPL kernel sources:
N = (aml_read_reg32(P_HHI_SYS_CPU_CLK_CNTL1) >> 20) & 0x3FF;
This means that the divider register is 10 bit wide instead of 9 bits.
So far this is not a problem since all u-boot versions I have seen are
not using the cpu_scale_div clock at all (instead they are configuring
the CPU clock to run off cpu_in_sel directly).
The fixes tag points to the latest rework of the CPU clocks. However,
even before the rework it was wrong. Commit 7a29a86943 ("clk: meson:
Add support for Meson clock controller") defines MESON_N_WIDTH as 9 (in
drivers/clk/meson/clk-cpu.c). But since the old clk-cpu implementation
this only carries the fixes tag for the CPU clock rewordk.
Fixes: 251b6fd38b ("clk: meson: rework meson8b cpu clock")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lkml.kernel.org/r/20180927085921.24627-3-martin.blumenstingl@googlemail.com
The public S805 datasheet only mentions that
HHI_SYS_CPU_CLK_CNTL1[20:29] contains a divider called "cpu_scale_div".
Unfortunately it does not mention how to use the register contents.
The Amlogic 3.10 GPL kernel sources are using the following code to
calculate the CPU clock based on that register (taken from
arch/arm/mach-meson8/clock.c in the 3.10 Amlogic kernel, shortened to
make it easier to read):
N = (aml_read_reg32(P_HHI_SYS_CPU_CLK_CNTL1) >> 20) & 0x3FF;
if (sel == 3) /* use cpu_scale_div */
div = 2 * N;
else
div = ... /* not relevant for this example */
cpu_clk = parent_clk / div;
This suggests that the formula is: parent_rate / 2 * register_value
However, running perf (which can measure the CPU clock rate thanks to
the ARM PMU) shows that this formula is not correct.
This can be reproduced with the following steps:
1. boot into u-boot
2. let the CPU clock run off the XTAL clock:
mw.l 0xC110419C 0x30 1
3. set the cpu_scale_div register:
to value 0x1: mw.l 0xC110415C 0x801016A2 1
to value 0x2: mw.l 0xC110415C 0x802016A2 1
to value 0x5: mw.l 0xC110415C 0x805016A2 1
4. let the CPU clock run off cpu_scale_div:
mw.l 0xC110419C 0xbd 1
5. boot Linux
6. run: perf stat -aB stress --cpu 4 --timeout 10
7. check the "cycles" value
I get the following results depending on the cpu_scale_div value:
- (cpu_in_sel - this is the input clock for cpu_scale_div - runs at
1.2GHz)
- 0x1 = 300MHz
- 0x2 = 200MHz
- 0x5 = 100MHz
This means that the actual formula to calculate the output of the
cpu_scale_div clock is: parent_rate / 2 * (register value + 1).
The register value 0x0 is reserved. When letting the CPU clock run off
the cpu_scale_div while the value is 0x0 the whole board hangs (even in
u-boot).
I also verified this with the TWD timer: when adding this to the .dts
without specifying it's clock it will auto-detect the PERIPH (which is
the input clock of the TWD) clock rate (and the result is shown in the
kernel log). On Meson8, Meson8b and Meson8m2 the PERIPH clock is CPUCLK
divided by 4. This also matched for all three test-cases from above (in
all cases the TWD timer clock rate was approx. one fourth of the CPU
clock rate).
A small note regarding the "fixes" tag: the original issue seems to
exist virtually since forever. Even commit 28b9fcd016 ("clk:
meson8b: Add support for Meson8b clocks") seems to handle this wrong. I
still decided to use commit 251b6fd38b ("clk: meson: rework meson8b
cpu clock") because this is the first commit which gets the CPU hiearchy
correct and thus it's the first commit where the cpu_scale_div register
is used correctly (apart from the bug in the cpu_scale_table).
Fixes: 251b6fd38b ("clk: meson: rework meson8b cpu clock")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lkml.kernel.org/r/20180927085921.24627-2-martin.blumenstingl@googlemail.com
The clock controller is located in a register range (called "HHI") which
contains more than just registers for the clock controller. Known
consumers of the HHI register range are:
- the clock controller
- a reset controller
- temperature sensor calibration coefficient (TSC) (only on Meson8b and
Meson8m2)
- HDMI controller
The main reason for using a syscon is the "temperature sensor
calibration coefficient" which has to be set for the built-in temperature
sensor to work correctly. Four TSC bits are located in the SAR ADC's
register space. However on Meson8b and Meson8m2 there is a fifth TSC bit
which is unfortunately located in the HHI register space. To be more
precise, bit 9 of the HHI_DPLL_TOP_0 register (which sits right between
the HHI_SYS_PLL and HHI_VID_PLL registers).
Get the regmap from the parent (HHI syscon) node to support all
functionality of the HHI register range. Backwards compatibility with
old .dtbs is ensured by falling back to parsing the registers just like
before this change.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lkml.kernel.org/r/20181028120859.5735-3-martin.blumenstingl@googlemail.com
For now the reset controller was using raw register access because the
early init did not initialize the regmap. However, now that clocks are
initialized early we can simply use the regmap also for the reset
controller.
No functional changes.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Until now only the reset controller (part of the clock controller
register space) was registered early in the boot process, while the
clock controller itself was registered later on.
However, some parts of the SoC are initialized early in the boot process,
such as the SRAM and the TWD timer. The bootloader already enables these
clocks so we didn't see any issues so far.
Register the clock controller early so other drivers (such as the SRAM
and TWD timer) can use the clocks early in the boot process.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Martin Blumenstingl