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@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.
Just including the subjects would be fine too.
--
Thanks,
Sasha