On Thu, Mar 22, 2018 at 12:14 AM, Sasha Levin
<Alexander.Levin@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> wrote:
>>> From: Chen-Yu Tsai <wens@xxxxxxxx>
>>>
>>> [ 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@xxxxxxxx>
>>> Signed-off-by: Maxime Ripard <maxime.ripard@xxxxxxxxxxxxxxxxxx>
>>> Signed-off-by: Sasha Levin <alexander.levin@xxxxxxxxxxxxx>
>>> ---
>>> 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@xxxxxxxxxxxxxxx> # 3.3.x: a1f84a3: sched: Check for idle
> Cc: <stable@xxxxxxxxxxxxxxx> # 3.3.x: 1b9508f: sched: Rate-limit newidle
> Cc: <stable@xxxxxxxxxxxxxxx> # 3.3.x: fd21073: sched: Fix affinity logic
> Cc: <stable@xxxxxxxxxxxxxxx> # 3.3.x
> Signed-off-by: Ingo Molnar <mingo@xxxxxxx>
>
> 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.
Thanks
ChenYu