For Si5351 clock driver, Michael Welling and Jean-Francois Moine reported issues with recent v4.x kernels due to broken/missing/wrong parent clock claming. This patch set now deals with the issues reported. Patch 1 amends the binding documentation mention clock-names property for the "xtal" and "clkin" parent clock inputs of Si5351 variants. Patch 2 adds the clock-names property for the SolidRun CuBox using Si5351 with a fixed oscillator connected to "xtal" input. Patch 3 reworks the way we claim parent clocks by using devm_clk_get() for both DT and platform_data based registration. Also, properly check for errors returned by devm_clk_get() and prepare/enable the parent clocks. Patch 4 introduces a function to reset PLLs on rate change. This should improve generated clock output stability. I currently have no scope at hand to actually test that properly, so there may be more issues remaining. @Michael, Jean-Francois: Please test and report if there are still issues remaining. Sebastian Sebastian Hesselbarth (4): clk: si5351: Mention clock-names in the binding documentation ARM: dove: Add clock-names to CuBox Si5351 clk generator clk: si5351: Do not pass struct clk in platform_data clk: si5351: Reset PLL after rate change .../devicetree/bindings/clock/silabs,si5351.txt | 4 +- arch/arm/boot/dts/dove-cubox.dts | 1 + drivers/clk/clk-si5351.c | 87 +++++++++++++++++----- include/linux/platform_data/si5351.h | 4 - 4 files changed, 73 insertions(+), 23 deletions(-) --- Cc: Mike Turquette <mturquette@xxxxxxxxxx> Cc: Stephen Boyd <sboyd@xxxxxxxxxxxxxx> Cc: Jean-Francois Moine <moinejf@xxxxxxx> Cc: Michael Welling <mwelling@xxxxxxxx> Cc: Russell King <rmk+linux@xxxxxxxxxxxxxxxx> Cc: Jason Cooper <jason@xxxxxxxxxxxxxx> Cc: Andrew Lunn <andrew@xxxxxxx> Cc: Gregory Clement <gregory.clement@xxxxxxxxxxxxxxxxxx> Cc: devicetree@xxxxxxxxxxxxxxx Cc: linux-clk@xxxxxxxxxxxxxxx Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx Cc: linux-kernel@xxxxxxxxxxxxxxx -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
