On Thu, Mar 22, 2018 at 12:19:18AM +0800, Chen-Yu Tsai wrote:
On Thu, Mar 22, 2018 at 12:14 AM, Sasha Levin Alexander.Levin@microsoft.com wrote:
On Tue, Mar 20, 2018 at 11:10:42AM +0800, Chen-Yu Tsai wrote:
Hi,
On Sun, Mar 4, 2018 at 6:28 AM, Sasha Levin Alexander.Levin@microsoft.com wrote:
From: Chen-Yu Tsai wens@csie.org
[ Upstream commit 68f37d862403e8f95337b2eca90af15d0b8cd5d7 ]
The DDR1 PLL on the A33 is an oddball amongst the A33 CCU clocks. It is a clock multiplier, with the effective multiplier in the range of 12 ~ 255 and no offset between the multiplier value and the value programmed into the register.
Implement the zero offset and minimum value of 12 for this clock.
Fixes: d05c748bd730 ("clk: sunxi-ng: Add A33 CCU support") Signed-off-by: Chen-Yu Tsai wens@csie.org Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com Signed-off-by: Sasha Levin alexander.levin@microsoft.com
drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c index e1dc4e5b34e1..bdbaf26f551f 100644 --- a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c +++ b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c @@ -159,13 +159,17 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_de_clk, "pll-de", BIT(28), /* lock */ CLK_SET_RATE_UNGATE);
-/* TODO: Fix N */ -static SUNXI_CCU_N_WITH_GATE_LOCK(pll_ddr1_clk, "pll-ddr1",
"osc24M", 0x04c,8, 6, /* N */BIT(31), /* gate */BIT(28), /* lock */CLK_SET_RATE_UNGATE);+static struct ccu_mult pll_ddr1_clk = {
.enable = BIT(31),.lock = BIT(28),As you undoubtedly noticed, this does not build. It needs commit cf719012b232 ("clk: sunxi-ng: mult: Support PLL lock detection") to be applied first. They were part of the same series.
Thanks for the heads up!
Incidentally, how can we note these kinds of dependencies to make life easier for stable kernel maintainers?
Yes! There are more details in Documentation/process/stable-kernel-rules.rst:
""" Additionally, some patches submitted via Option 1 may have additional patch prerequisites which can be cherry-picked. This can be specified in the following format in the sign-off area:
Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic Cc: <stable@vger.kernel.org> # 3.3.x Signed-off-by: Ingo Molnar <mingo@elte.hu>The tag sequence has the meaning of:
git cherry-pick a1f84a3 git cherry-pick 1b9508f git cherry-pick fd21073 git cherry-pick <this commit>"""
I know about these, and add them when I can. What I'm asking about is if a fix and its prerequisites are sent as part of a larger series for -next, then none of the prerequisites would be in Linus' tree, and I can't use this format. What then? Mention the prerequisite patches' subjects in the commit log?
We tend to bunch fixes into -next if they aren't critical (such as a faulty clock that doesn't have any in tree users yet) or related to the current -rc series.
Just including the subjects would be fine too.