- 29 7月, 2019 2 次提交
-
-
由 Alexandre Mergnat 提交于
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: NAlexandre Mergnat <amergnat@baylibre.com> Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
-
由 Alexandre Mergnat 提交于
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: NAlexandre Mergnat <amergnat@baylibre.com> Reviewed-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Tested-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
-
- 11 6月, 2019 3 次提交
-
-
由 Martin Blumenstingl 提交于
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 7eaa44f6 ("clk: meson: gxbb: add cts_i958 clock") to the Meson8/Meson8b/Meson8m2 clock driver. Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
-
由 Martin Blumenstingl 提交于
Add the SPDIF master clock also referred as cts_mclk_i958. The setup for this clock is identical to GXBB, so this ports commit 3c277c24 ("clk: meson: gxbb: add cts_mclk_i958") to the Meson8/Meson8b/Meson8m2 clock driver. Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
-
由 Martin Blumenstingl 提交于
Add the I2S master clock also referred as cts_amclk. The setup for this clock is identical to GXBB, so this ports commit 4087bd4b ("clk: meson: gxbb: add cts_amclk") to the Meson8/Meson8b/Meson8m2 clock driver. Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
-
- 20 5月, 2019 1 次提交
-
-
由 Martin Blumenstingl 提交于
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: 41785ce5 ("clk: meson: meson8b: add the VPU clock trees") Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
-
- 01 4月, 2019 4 次提交
-
-
由 Martin Blumenstingl 提交于
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: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NMaxime Jourdan <mjourdan@baylibre.com> Acked-by: NJerome Brunet <jbrunet@baylibre.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20190324151423.19063-3-martin.blumenstingl@googlemail.com
-
由 Martin Blumenstingl 提交于
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: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com> Acked-by: NJerome Brunet <jbrunet@baylibre.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20190324151104.18397-5-martin.blumenstingl@googlemail.com
-
由 Martin Blumenstingl 提交于
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: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com> Acked-by: NJerome Brunet <jbrunet@baylibre.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20190324151104.18397-4-martin.blumenstingl@googlemail.com
-
由 Martin Blumenstingl 提交于
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: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com> Acked-by: NJerome Brunet <jbrunet@baylibre.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20190324151104.18397-3-martin.blumenstingl@googlemail.com
-
- 13 2月, 2019 1 次提交
-
-
由 Martin Blumenstingl 提交于
Fix a typo in the APB clock names by renaming them from "abp" to "apb". No functional changes. Fixes: a7d19b05 ("clk: meson: meson8b: add the CPU clock post divider clocks") Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Acked-by: NJerome Brunet <jbrunet@baylibre.com> Link: https://lkml.kernel.org/r/20190210222603.6404-2-martin.blumenstingl@googlemail.com
-
- 03 2月, 2019 1 次提交
-
-
由 Jerome Brunet 提交于
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: NJerome Brunet <jbrunet@baylibre.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20190201125841.26785-5-jbrunet@baylibre.com
-
- 07 1月, 2019 2 次提交
-
-
由 Martin Blumenstingl 提交于
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: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20181208171247.22238-4-martin.blumenstingl@googlemail.com
-
由 Martin Blumenstingl 提交于
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: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20181208171247.22238-3-martin.blumenstingl@googlemail.com
-
- 03 12月, 2018 3 次提交
-
-
由 Martin Blumenstingl 提交于
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: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20181202214220.7715-4-martin.blumenstingl@googlemail.com
-
由 Martin Blumenstingl 提交于
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: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20181202214220.7715-3-martin.blumenstingl@googlemail.com
-
由 Martin Blumenstingl 提交于
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: 28b9fcd0 ("clk: meson8b: Add support for Meson8b clocks") Reported-by: NJianxin Pan <jianxin.pan@amlogic.com> Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20181202214220.7715-2-martin.blumenstingl@googlemail.com
-
- 23 11月, 2018 10 次提交
-
-
由 Martin Blumenstingl 提交于
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: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by: NJerome Brunet <jbrunet@baylibre.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20181122214017.25643-5-martin.blumenstingl@googlemail.com
-
由 Martin Blumenstingl 提交于
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: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by: NJerome Brunet <jbrunet@baylibre.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20181122214017.25643-4-martin.blumenstingl@googlemail.com
-
由 Martin Blumenstingl 提交于
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: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: NJerome Brunet <jbrunet@baylibre.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20181115224048.13511-7-martin.blumenstingl@googlemail.com
-
由 Martin Blumenstingl 提交于
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: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: NJerome Brunet <jbrunet@baylibre.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20181115224048.13511-6-martin.blumenstingl@googlemail.com
-
由 Martin Blumenstingl 提交于
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: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by: NJerome Brunet <jbrunet@baylibre.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20181115224048.13511-5-martin.blumenstingl@googlemail.com
-
由 Martin Blumenstingl 提交于
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: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by: NJerome Brunet <jbrunet@baylibre.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20181115224048.13511-4-martin.blumenstingl@googlemail.com
-
由 Martin Blumenstingl 提交于
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: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: NJerome Brunet <jbrunet@baylibre.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20181115224048.13511-3-martin.blumenstingl@googlemail.com
-
由 Martin Blumenstingl 提交于
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 7a29a869 ("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: 251b6fd3 ("clk: meson: rework meson8b cpu clock") Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20180927085921.24627-3-martin.blumenstingl@googlemail.com
-
由 Martin Blumenstingl 提交于
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 28b9fcd0 ("clk: meson8b: Add support for Meson8b clocks") seems to handle this wrong. I still decided to use commit 251b6fd3 ("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: 251b6fd3 ("clk: meson: rework meson8b cpu clock") Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20180927085921.24627-2-martin.blumenstingl@googlemail.com
-
由 Martin Blumenstingl 提交于
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: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by: NNeil Armstrong <narmstrong@baylibre.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20181028120859.5735-3-martin.blumenstingl@googlemail.com
-
- 26 9月, 2018 6 次提交
-
-
由 Martin Blumenstingl 提交于
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: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
-
由 Martin Blumenstingl 提交于
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: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
-
由 Jerome Brunet 提交于
Putting hard-coded rates inside the parameter tables assumes that the parent is known and will never change. That's a big assumption we should not make. We have everything we need to recalculate the output rate using the parent rate and the rest of the parameters. Let's do so and drop the rates from the tables. Acked-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Tested-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
-
由 Jerome Brunet 提交于
Remove od parameters from pll clocks and add post dividers clocks instead. Some clock, especially the one which feature several ods, may provide output between those ods. Also, some drivers, such as the hdmi driver, may require a more detailed control of the clock dividers, compared to what CCF would perform automatically. One added benefit of removing ods is that it also greatly reduce the size of the rate parameter tables. In the future, we could possibly take the predivider 'n' out of this driver as well. To do so, we will need to understand the constraints for the PLL to lock and whether or not it depends on the input clock rate. Acked-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Tested-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
-
由 Jerome Brunet 提交于
CLK_GET_RATE_NOCACHE should only be necessary when the registers controlling the rate of clock may change outside of CCF. On Amlogic, it should only be the case for the hdmi pll which is directly controlled by the display driver (WIP to fix this). The other plls should not require this flag. Reviewed-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Tested-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
-
由 Jerome Brunet 提交于
Add the enable the bit of the pll clocks. These pll clocks may be disabled but we can't model this as an external gate since the pll needs to lock when enabled. Adding this bit allows to drop the poke of the first register of PLL. This will be useful to model the different components of the pll using generic clocks elements Acked-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Tested-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
-
- 21 5月, 2018 1 次提交
-
-
由 Martin Blumenstingl 提交于
Until commit 05f81440 ("clk: meson: add fdiv clock gates") we relied on the bootloader to enable the fclk_div clock gates. It turns out that our clock tree is incomplete at least on Meson8b (tested with an Odroid-C1, which uses an RGMII PHY) because after the mentioned commit Ethernet is not working anymore (no RX/TX activity can be seen). At the same time Ethernet was still working on Meson8m2 with a RMII PHY. Testing has shown that as soon as "fclk_div2" is disabled Ethernet stops working on Odroid-C1. Unfortunately it's currently not clear what the Ethernet controller IP block uses the fclk_div2 clock for. Mark the clock as CLK_IS_CRITICAL to keep it enabled (as it's already enabled by most bootloaders by default, which is why we didn't notice it before). Fixes: 05f81440 ("clk: meson: add fdiv clock gates") Cc: stable@vger.kernel.org Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Tested-by: NKevin Hilman <khilman@baylibre.com> Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
-
- 18 5月, 2018 1 次提交
-
-
由 Jerome Brunet 提交于
Replace every license notices in drivers/clk/meson by SPDX license identifiers, as described in license-rules.rst Acked-by: NNeil Armstrong <narmstrong@baylibre.com> Acked-by: NStephen Boyd <sboyd@kernel.org> Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
-
- 15 5月, 2018 1 次提交
-
-
由 Martin Blumenstingl 提交于
This adds the NAND clocks (from the HHI_NAND_CLK_CNTL register) to the Meson8b clock driver. There are three NAND clocks: a gate which enables or disables the NAND clock, a mux and a divider (which divides the mux output). Unfortunately the public S805 datasheet does not document the mux parents. However, the vendor kernel has a few hints for us which allows us to make an educated guess about the clock parents. To do this we need to have a look at set_nand_core_clk() from the vendor's NAND driver (see [0]): - XTAL = (4<<9) | (1<<8) | 0 - 160MHz = (0<<9) | (1<<8) | 3) - 182MHz = (3<<9) | (1<<8) | 1) - 212MHz = (1<<9) | (1<<8) | 3) - 255MHz = (2<<9) | (1<<8) | 1) While there is a comment for the XTAL parent (which indicates that it should only be used for debugging) we have to do a bit of math for the other parents: target_freq * divider = rate of parent clock Bit 8 above is the enable bit, so we can ignore it here. Bits 11:9 are the mux index and bits 6:0 are the 0-based divider (so we need to add 1). This gives us: - mux 0 (160MHz * 4) = fclk_div4 (actual rate = 637.5MHz, off by 2.5MHz) - mux 1 (212MHz * 4) = fclk_div3 (actual rate = 850MHz, off by 2MHz) - mux 2 (255MHz * 2) = fclk_div5 (matches exactly 510MHz) - mux 3 (182MHz * 2) = fclk_div7 (actual rate = 346.3MHz, off by 0.3MHz) [0] https://github.com/khadas/linux/blob/9587681285cb/drivers/amlogic/amlnf/dev/amlnf_ctrl.c#L314Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
-
- 25 4月, 2018 2 次提交
-
-
由 Martin Blumenstingl 提交于
meson8b_cpu_clk has two parent clocks: - meson8b_xtal - meson8b_cpu_scale_out_sel The name of the "xtal" clock parent is specified correctly. However, there is a typo in the name of the second parent clock. The meson8b_cpu_scale_out_sel definition uses the name "cpu_scale_out_sel" (which matches the name from the datasheet). However, the mux parent definition uses the name "cpu_out_sel" which does not match any existing clock. Fixes: 251b6fd3 ("clk: meson: rework meson8b cpu clock") Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
-
由 Martin Blumenstingl 提交于
The names of all fclk divider gate clocks follow the naming schema "fclk_divN" and the name of all fclk fixed dividers follow the naming schema "fclk_divN_div". There's one exception to this rule: meson8b_fclk_div3_div's name is "fclk_div_div3". It's child clock meson8b_fclk_div3 however references it as "fclk_div3_div" (following the naming schema explained above). Fix the naming of the meson8b_fclk_div3_div clock to follow the naming schema. This also fixes serial console on my Meson8m2 board because "clk81" uses fclk_div3 as parent. However, since the hierarchy stops at meson8b_fclk_div3 there's no known parent clock and the rate of "clk81" and all of it's children (UART clock, SDIO MMC controller clock, ...) are all 0. Fixes: 05f81440 ("clk: meson: add fdiv clock gates") Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
-
- 15 3月, 2018 1 次提交
-
-
由 Stephen Boyd 提交于
Fixes the following warnings: drivers/clk/meson/meson8b.c:512:19: warning: symbol 'meson8b_mpeg_clk_div' was not declared. Should it be static? drivers/clk/meson/meson8b.c:526:19: warning: symbol 'meson8b_clk81' was not declared. Should it be static? drivers/clk/meson/meson8b.c:540:19: warning: symbol 'meson8b_cpu_in_sel' was not declared. Should it be static? drivers/clk/meson/meson8b.c:591:19: warning: symbol 'meson8b_cpu_scale_div' was not declared. Should it be static? drivers/clk/meson/meson8b.c:608:19: warning: symbol 'meson8b_cpu_scale_out_sel' was not declared. Should it be static? drivers/clk/meson/meson8b.c:626:19: warning: symbol 'meson8b_cpu_clk' was not declared. Should it be static? drivers/clk/meson/gxbb.c:392:27: warning: symbol 'gxbb_gp0_init_regs' was not declared. Should it be static? drivers/clk/meson/gxbb.c:439:27: warning: symbol 'gxl_gp0_init_regs' was not declared. Should it be static? drivers/clk/meson/axg.c:195:27: warning: symbol 'axg_gp0_init_regs' was not declared. Should it be static? drivers/clk/meson/axg.c:248:27: warning: symbol 'axg_hifi_init_regs' was not declared. Should it be static? drivers/clk/meson/meson8b.c: In function 'meson8b_clkc_probe': drivers/clk/meson/meson8b.c:1052:14: warning: unused variable 'clk' [-Wunused-variable] Signed-off-by: NStephen Boyd <sboyd@kernel.org>
-
- 13 3月, 2018 1 次提交
-
-
由 Jerome Brunet 提交于
clk81 is a composite clock which parents all the peripheral clocks of the platform. It is a critical clock which is used as provided by the bootloader. We don't want to change its rate or reparent it, ever. Remove the CLK_IGNORE_UNUSED on the mux and divider. These clock can't gate so the flag is useless, and the gate is already critical, so the clock won't ever be unused. Remove CLK_SET_RATE_NO_REPARENT from mux, it is useless since the mux is read-only. Remove CLK_SET_RATE_PARENT from the gate and divider and use ro_ops for the divider. A peripheral clock should not try to change the rate of clk81. Stopping the rate propagation is good way to make sure such request would be ignored. Signed-off-by: NJerome Brunet <jbrunet@baylibre.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
-