lkml.org 
[lkml]   [2014]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v3] clk: respect the clock dependencies in of_clk_init
From
[+ imx6 maintainers ]

On Thu, Mar 20, 2014 at 8:52 PM, Mike Turquette <mturquette@linaro.org> wrote:
> Quoting Gregory CLEMENT (2014-02-28 02:46:12)
>> Hi Mike,
>>
>> On 24/02/2014 19:10, Gregory CLEMENT wrote:
>> > Until now the clock providers were initialized in the order found in
>> > the device tree. This led to have the dependencies between the clocks
>> > not respected: children clocks could be initialized before their
>> > parent clocks.
>> >
>> > Instead of forcing each platform to manage its own initialization order,
>> > this patch adds this work inside the framework itself.
>> >
>> > Using the data of the device tree the of_clk_init function now delayed
>> > the initialization of a clock provider if its parent provider was not
>> > ready yet.
>> >
>> > The strict dependency check (all parents of a given clk must be
>> > initialized) was added by Boris BREZILLON
>>
>> Are you ok with this version?
>> Will you take it for 3.15?
>> Or maybe you expected that it will be part of a pull request?
>>
>> However as it is modifying the core of the framework I thought that you
>> would take it and apply yourself.
>
> Hi Gregory,
>
> I have taken this into clk-next. If no regressions pop up over the next
> few days then it should go into 3.15.

$SUBJECT patch (as commit 1771b10d605) is in -next has been fingered
by bisection to be the reason behind boot failures[1] on imx6 wand
boards in the last several -next kernels.

Reverting the patch on top of next/master gets these boards booting again.

The boot failures result in no console output, so I haven't done any
further debugging.

Kevin

[1] http://lists.linaro.org/pipermail/kernel-build-reports/2014-March/002927.html


\
 
 \ /
  Last update: 2014-03-26 17:01    [W:0.051 / U:0.404 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site