linux-dev/drivers/clk/meson/gxbb.c, branch linus/master

clk: meson: gxbb: Fix the SDM_EN bit for MPLL0 on GXBB

2021-11-30T09:28:52Z

There are reports that 48kHz audio does not work on the WeTek Play 2 (which uses a GXBB SoC), while 44.1kHz audio works fine on the same board. There are also reports of 48kHz audio working fine on GXL and GXM SoCs, which are using an (almost) identical AIU (audio controller). Experimenting has shown that MPLL0 is causing this problem. In the .dts we have by default: assigned-clocks = <&clkc CLKID_MPLL0>, <&clkc CLKID_MPLL1>, <&clkc CLKID_MPLL2>; assigned-clock-rates = <294912000>, <270950400>, <393216000>; The MPLL0 rate is divisible by 48kHz without remainder and the MPLL1 rate is divisible by 44.1kHz without remainder. Swapping these two clock rates "fixes" 48kHz audio but breaks 44.1kHz audio. Everything looks normal when looking at the info provided by the common clock framework while playing 48kHz audio (via I2S with mclk-fs = 256): mpll_prediv 1 1 0 2000000000 mpll0_div 1 1 0 294909641 mpll0 1 1 0 294909641 cts_amclk_sel 1 1 0 294909641 cts_amclk_div 1 1 0 12287902 cts_amclk 1 1 0 12287902 meson-clk-msr however shows that the actual MPLL0 clock is off by more than 38MHz: mp0_out 333322917 +/-10416Hz The rate seen by meson-clk-msr is very close to what we would get when SDM (the fractional part) was ignored: (2000000000Hz * 16384) / ((16384 * 6) = 333.33MHz If SDM was considered the we should get close to: (2000000000Hz * 16384) / ((16384 * 6) + 12808) = 294.9MHz Further experimenting shows that HHI_MPLL_CNTL7[15] does not have any effect on the rate of MPLL0 as seen my meson-clk-msr (regardless of whether that bit is zero or one the rate is always the same according to meson-clk-msr). Using HHI_MPLL_CNTL[25] on the other hand as SDM_EN results in SDM being considered for the rate output by the hardware. The rate - as seen by meson-clk-msr - matches with what we expect when SDM_EN is enabled (fractional part is being considered, resulting in a 294.9MHz output) or disable (fractional part being ignored, resulting in a 333.33MHz output). Reported-by: Christian Hewitt Tested-by: Christian Hewitt Signed-off-by: Martin Blumenstingl Signed-off-by: Jerome Brunet Link: https://lore.kernel.org/r/20211031135006.1508796-1-martin.blumenstingl@googlemail.com

clk: meson: enable building as modules

2020-11-23T08:08:23Z

Make it possible to build all clk drivers as modules, but default remains built-in. No functional changes. Signed-off-by: Kevin Hilman Signed-off-by: Jerome Brunet Acked-by: Stephen Boyd Link: https://lore.kernel.org/r/20201118191405.36798-1-khilman@baylibre.com

clk: meson: gxbb: Prepare the GPU clock tree to change at runtime

2020-04-16T10:23:05Z

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. Also propagate set_rate requests from the gate to the divider and from the divider to the the mux so the GPU clock frequency can be updated at runtime (which will be required for GPU DVFS). Don't propagate rate changes to the mux parents because we don't want to change the MPLL clocks (these are reserved for audio). Signed-off-by: Martin Blumenstingl Signed-off-by: Jerome Brunet Acked-by: Neil Armstrong Link: https://lore.kernel.org/r/20200414195031.224021-2-martin.blumenstingl@googlemail.com

clk: meson: gxbb: set audio output clock hierarchy

2020-02-13T16:26:51Z

The aiu devices peripheral clocks needs the aiu and aiu_glue clocks to operate. Reflect this hierarchy in the gxbb clock tree. Fixes: 738f66d3211d ("clk: gxbb: add AmLogic GXBB clk controller driver") Acked-by: Neil Armstrong Signed-off-by: Jerome Brunet

clk: meson: gxbb: add the gxl internal dac gate

2020-02-13T16:26:04Z

Add the ACODEC clock gate to the gxl clk controller driver Acked-by: Neil Armstrong Signed-off-by: Jerome Brunet

clk: meson: gxbb: let sar_adc_clk_div set the parent clock rate

2019-10-01T12:46:30Z

The meson-saradc driver manually sets the input clock for sar_adc_clk_sel. Update the GXBB clock driver (which is used on GXBB, GXL and GXM) so the rate settings on sar_adc_clk_div are propagated up to sar_adc_clk_sel which will let the common clock framework select the best matching parent clock if we want that. This makes sar_adc_clk_div consistent with the axg-aoclk and g12a-aoclk drivers, which both also specify CLK_SET_RATE_PARENT. Fixes: 33d0fcdfe0e870 ("clk: gxbb: add the SAR ADC clocks and expose them") Signed-off-by: Martin Blumenstingl Signed-off-by: Jerome Brunet

clk: meson: clk-regmap: migrate to new parent description method

2019-07-29T10:42:49Z

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 Signed-off-by: Jerome Brunet

clk: meson: gxbb: migrate to the new parent description method

2019-07-29T10:42:48Z

clk: meson: gxbb: no spread spectrum on mpll0

2019-05-20T10:18:38Z

The documentation says there is an SSEN bit on mpll0 but, after testing it, no spread spectrum function appears to be enabled by this bit on any of the MPLLs. Let's remove it until we know more Fixes: 1f737ffa13ef ("clk: meson: mpll: fix mpll0 fractional part ignored") Signed-off-by: Jerome Brunet

clk: meson-gxbb: round the vdec dividers to closest

2019-03-19T16:36:37Z

We want the video decoder clocks to always round to closest. While the muxes are already using CLK_MUX_ROUND_CLOSEST, the corresponding CLK_DIVIDER_ROUND_CLOSEST was forgotten for the dividers. Fix this by adding the flag to the two vdec dividers. Fixes: a565242eb9fc ("clk: meson: gxbb: add the video decoder clocks") Signed-off-by: Maxime Jourdan Acked-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://lkml.kernel.org/r/20190319102537.2043-1-mjourdan@baylibre.com