- 13 Mar, 2018 18 commits
-
-
Jerome Brunet authored
Instead of migrating meson cpu_clk to clk_regmap, like the other meson clock drivers, we take advantage of the massive rework to get rid of it completely, and solve (the first part) of the related FIXME notice. As pointed out in the code comments, the cpu_clk should be modeled with dividers and muxes it is made of, instead of one big composite clock. The cpu_clk was not working correctly to enable dvfs on meson8b. It hangs quite often when changing the cpu clock rate. This new implementation, based on simple elements improves the situation but the platform will still hang from time to time. This is not acceptable so, until we can make the mechanism around the cpu clock stable, the cpu clock subtree has been put in read-only mode, preventing any change of the cpu clock The notifier and read-write operation will be added back when we have a solution to the problem. Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
Jerome Brunet <jbrunet@baylibre.com> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com>
-
Jerome Brunet authored
The mpll clock is a kind of fractional divider which can gate. When the RW operation have been added, enable/disable ops have been mistakenly inserted in this driver. These ops are essentially a poor copy/paste of the generic gate ops. This change removes the gate ops from the mpll driver and inserts a generic gate clock on each mpll divider, simplifying the mpll driver and reducing code duplication. Signed-off-by:
-
Jerome Brunet authored
Rework meson pll driver to use clk_regmap and move meson8b, gxbb and axg's clock using meson_clk_pll to clk_regmap. This rework is not just about clk_regmap, there a serious clean-up of the driver code: * Add lock and reset field: Previously inferred from the n field. * Simplify the reset logic: Code seemed to apply reset differently but in fact it was always the same -> assert reset, apply params, de-assert reset. The 2 lock checking loops have been kept for now, as they seem to be necessary. * Do the sequence of init register pokes only at .init() instead of in .set_rate(). Redoing the init on every set_rate() is not necessary Signed-off-by:
-
Jerome Brunet authored
Rework meson audio divider driver to use clk_regmap and move gxbb clock using meson_clk_audio_divider to clk_regmap. Signed-off-by:
-
Jerome Brunet authored
Rework meson mpll driver to use clk_regmap and move meson8b, gxbb and axg clocks using meson_clk_mpll to clk_regmap Signed-off-by:
-
Jerome Brunet authored
Meson clock drivers are using struct parm to describe each field of the clock provider. Providing helpers to access these fields with regmap helps to keep drivers readable Signed-off-by:
-
Jerome Brunet authored
Move meson8b, gxbb and axg clocks using clk_mux to clk_regmap Also remove a few useless tables in the process Signed-off-by:
-
Jerome Brunet authored
Move meson8b, gxbb and axg clocks using clk_divider to clk_regmap Signed-off-by:
-
Jerome Brunet authored
Move meson8b, gxbb and axg clocks using clk_gate to clk_regmap Signed-off-by:
-
Jerome Brunet authored
This change registers a regmap in meson8b, gxbb and axg controllers. The clock are still accessing their registers directly through iomem. Once all clocks handled by these controllers have been move to regmap, the regmap register will be removed and replaced with a syscon request. This is needed because other drivers, such as the HDMI driver, need to access the HHI register region Acked-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
-
Jerome Brunet authored
aoclk_gate_regmap has been replaced by meson's clk_regmap. It is no longer necessary so, remove it Signed-off-by:
-
Jerome Brunet authored
Drop the gxbb ao specific regmap based clock and use the meson clk_regmap based clock instead. Signed-off-by:
-
Jerome Brunet authored
Meson clock controllers need to move the classical iomem registers to regmap. This is triggered because the HHI controllers found on the GXBB and GXL host more than just clocks. To properly handle this, we would like to migrate HHI to syscon. Also GXBB AO clock controller already use regmap, AXG AO and Audio clock controllers will as well. The purpose of this change is to provide a common structure to these meson controllers (and possibly others) for regmap based clocks. This change provides the basic gate, mux and divider, based on the helpers provided by the related generic clocks Signed-off-by:
-
Jerome Brunet authored
Over time things changes in CCF and issues have been fixed in meson controllers. Now, clk81 is decently modeled by read-only PLLs, a mux, a divider and a gate. We can remove the FIXME comments related to clk81. Also remove the comment about devm_clk_hw_register, as there is apparently nothing wrong with it. Signed-off-by:
-
Jerome Brunet authored
We don't need several loop index variables in the probe function This is far from being critical but since we are doing a vast rework of meson clock controllers, now is the time to lower the entropy a bit Signed-off-by:
-
Jerome Brunet authored
There is no remove callbacks in meson's clock controllers and of_clk_del_provider is never called if of_clk_add_hw_provider has been executed, introducing a potential memory leak. Fixing this by the using the devm variant. In reality, the leak would never happen since these controllers are never unloaded once in use ... still, this is worth cleaning. Signed-off-by:
-
Jerome Brunet authored
The 'dev' pointer is directly available in gxbb and axg clock controller, so consistently use it instead of going the through the 'pdev' pointer once in while Signed-off-by:
-
Neil Armstrong authored
-
- 12 Mar, 2018 8 commits
-
-
Jerome Brunet authored
There is now an helper function to round the rate when the divider is read-only. Let's use it Signed-off-by:
Michael Turquette <mturquette@baylibre.com> Signed-off-by:
Stephen Boyd <sboyd@kernel.org>
-
Jerome Brunet authored
When a divider clock has CLK_DIVIDER_READ_ONLY set, it means that the register shall be left un-touched, but it does not mean the clock should stop rate propagation if CLK_SET_RATE_PARENT is set This is properly handled in qcom clk-regmap-divider but it was not in the generic divider To fix this situation, introduce a new helper function divider_ro_round_rate, on the same model as divider_round_rate. Fixes: e6d5e7d9 ("clk-divider: Fix READ_ONLY when divider > 1") Signed-off-by:
David Lechner <david@lechnology.com> Signed-off-by:
-
Jerome Brunet authored
The mux documentation mentions the non-existing parameter width instead of mask, so just sed this. The table field is missing in the documentation of clk_mux. Add a small blurb explaining what it is Fixes: 9d9f78ed ("clk: basic clock hardware types") Signed-off-by:
-
Jerome Brunet authored
Some clocks may need to initialize things, whatever it is, before being able to properly operate. Move the .init() call before any other callback, such recalc_rate() or get_phase(), so the clock is properly setup before being used. Signed-off-by:
-
Jerome Brunet authored
Add helper functions for the translation between parent index and register value in the generic multiplexer function. The purpose of this change is avoid duplicating the code in other clock providers, using the same generic logic. Signed-off-by:
-
Jerome Brunet authored
Export clk_div_mask() in clk-provider header so every clock providers derived from the generic clock divider may share the definition instead of redefining it. Signed-off-by:
-
Jerome Brunet authored
If we try to determine the rate of a pass-through clock (a clock which does not implement .round_rate() nor .determine_rate()), clk_core_round_rate_nolock() will directly forward the call to the parent clock. In the particular case where the pass-through actually does not have a parent, clk_core_round_rate_nolock() will directly return 0 with the requested rate still set to the initial request structure. This is interpreted as if the rate could be exactly achieved while it actually cannot be adjusted. This become a real problem when this particular pass-through clock is the parent of a mux with the flag CLK_SET_RATE_PARENT set. The pass-through clock will always report an exact match, get picked and finally error when the rate is actually getting set. This is fixed by setting the rate inside the req to 0 when core is NULL in clk_core_round_rate_nolock() (same as in __clk_determine_rate() when hw is NULL) Fixes: 0f6cc2b8 ("clk: rework calls to round and determine rate callbacks") Signed-off-by:
-
Jerome Brunet authored
The orphan clocks reparents should migrate any existing count from the orphan clock to its new acestor clocks, otherwise we may have inconsistent counts in the tree and end-up with gated critical clocks Assuming we have two clocks, A and B. * Clock A has CLK_IS_CRITICAL flag set. * Clock B is an ancestor of A which can gate. Clock B gate is left enabled by the bootloader. Step 1: Clock A is registered. Since it is a critical clock, it is enabled. The clock being still an orphan, no parent are enabled. Step 2: Clock B is registered and reparented to clock A (potentially through several other clocks). We are now in situation where the enable count of clock A is 1 while the enable count of its ancestors is 0, which is not good. Step 3: in lateinit, clk_disable_unused() is called, the enable_count of clock B being 0, clock B is gated and and critical clock A actually gets disabled. This situation was found while adding fdiv_clk gates to the meson8b platform. These clocks parent clk81 critical clock, which is the mother of all peripheral clocks in this system. Because of the issue described here, the system is crashing when clk_disable_unused() is called. The situation is solved by reverting commit f8f8f1d0 ("clk: Don't touch hardware when reparenting during registration"). To avoid breaking again the situation described in this commit description, enabling critical clock should be done before walking the orphan list. This way, a parent critical clock may not be accidentally disabled due to the CLK_OPS_PARENT_ENABLE mechanism. Fixes: f8f8f1d0 ("clk: Don't touch hardware when reparenting during registration") Cc: Stephen Boyd <sboyd@codeaurora.org> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Tested-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
- 12 Feb, 2018 11 commits
-
-
Jerome Brunet authored
On axg, the rate of the mpll is stuck as if sdm value was 4 and could not change (expect for mpll2 strangely). Looking at the vendor kernel, it turns out a new magic bit from the undocumented HHI_PLL_TOP_MISC register is required. Setting this bit solves the problem and the mpll rates are back to normal Fixes: 78b4af31 ("clk: meson-axg: add clock controller drivers") Signed-off-by:
-
Yixun Lan authored
According to the datasheet, the od shift of sys_pll is actually 16. Fixes: 78b4af31 ('clk: meson-axg: add clock controller drivers') Signed-off-by:
Yixun Lan <yixun.lan@amlogic.com> [fixed commit message] Signed-off-by:
-
Jerome Brunet authored
The fixed_pll also has a fractional part. On axg s400 board, without this parameter, the calculated rate is off by ~8Mhz (0,4%). The fixed_pll being the root of the peripheral clock tree, this error is propagated to the rest of the clocks Adding the definition of the parameter fixes the problem Fixes: 78b4af31 ("clk: meson-axg: add clock controller drivers") Signed-off-by:
-
Jerome Brunet authored
The fixed_pll of gxbb and gxl also has a fractional parameter. This has not been a problem so far because the fractional part is actually set to 0 on these platforms, so the rate remains correct when it is ignored. Still, it is better represent the pll the way it is, so add the frac parameter now Signed-off-by: -
Jerome Brunet authored
The rate of the parent should not be multiplied by 2 when the pll has a fractional part. This is making the rate calculation of the gxl_hdmi_pll wrong (and others as well). This multiplication is specific to the hdmi_pll of gxbb and is most likely due to a multiplier sitting in front of this particular pll. Add a fixed factor clock in front on the gxbb pll and remove this constant from the calculation to fix the problem Fixes: 4a472951 ("clk: meson: fractional pll support") Signed-off-by:
-
Jerome Brunet authored
The hdmi pll used in the gxl family is actually different from the gxbb one. The register layout is completely different, which explain why the hdmi pll rate has always been rubbish on the gxl family. Adding the correct register field is the first part of the fix to get a correct rate out the hdmi pll Fixes: 0d48fc55 ("clk: meson-gxbb: Add GXL/GXM GP0 Variant") Signed-off-by:
-
Jerome Brunet authored
Some meson plls, such as the hdmi pll, are using a 3rd od parameter, which is yet another "power of 2" post divider. Add it to fix the calculation of the hdmi_pll rate Fixes: 738f66d3 ("clk: gxbb: add AmLogic GXBB clk controller driver") Signed-off-by:
-
Jerome Brunet authored
Use the fractional part width in the calculation instead of 12, which happens to be the witdh right now. This is safer in case the field width ever change in the future Signed-off-by: -
Jerome Brunet authored
The pll driver performs the rate calculation in Mhz, which adds an unnecessary rounding down to the Mhz of the rate. Use 64bits long integers to perform this calculation safely on meson8b and perform the calculation in Hz instead Fixes: 7a29a869 ("clk: meson: Add support for Meson clock controller") Signed-off-by:
-
Jerome Brunet authored
Read-only plls don't need param table to recalculate the rate. Providing them with a param table is just a waste of memory. Remove the useless tables from sys_pll on gxbb and axg. Signed-off-by: -
Jerome Brunet authored
Make sure the rate param table is available before using it. Some read-only plls don't provide it, which is ok since the table is not used by read-only clocks. R/W clocks are supposed to provide it, but it does not hurt check it. Signed-off-by:
-
- 11 Feb, 2018 3 commits
-
-
Linus Torvalds authored
-
Al Viro authored
except, again, POLLFREE and POLL_BUSY_LOOP. With this, we finally get to the promised end result: - POLL{IN,OUT,...} are plain integers and *not* in __poll_t, so any stray instances of ->poll() still using those will be caught by sparse. - eventpoll.c and select.c warning-free wrt __poll_t - no more kernel-side definitions of POLL... - userland ones are visible through the entire kernel (and used pretty much only for mangle/demangle) - same behavior as after the first series (i.e. sparc et.al. epoll(2) working correctly). Signed-off-by:Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
This is the mindless scripted replacement of kernel use of POLL* variables as described by Al, done by this script: for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'` for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done done with de-mangling cleanups yet to come. NOTE! On almost all architectures, the EPOLL* constants have the same values as the POLL* constants do. But they keyword here is "almost". For various bad reasons they aren't the same, and epoll() doesn't actually work quite correctly in some cases due to this on Sparc et al. The next patch from Al will sort out the final differences, and we should be all done. Scripted-by:
-
