All of lore.kernel.org
 help / color / mirror / Atom feed
From: sebastian.hesselbarth@gmail.com (Sebastian Hesselbarth)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] clk: respect the clock dependencies in of_clk_init
Date: Thu, 06 Feb 2014 00:11:39 +0100	[thread overview]
Message-ID: <52F2C52B.60001@gmail.com> (raw)
In-Reply-To: <1391554766-11285-1-git-send-email-gregory.clement@free-electrons.com>

On 02/04/2014 11:59 PM, 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.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> [...]
> this patch could solve the issues we get on severals mvebu platform
> since 3.14-rc1. This is an alternate solution of the patch set sent by
> Sebastian. However as it modifies the clock framework itself, it is
> more sensible.
>
> I find this solution more elegant than changing the order of the
> initialization of the clock at the platform level. However as it
> should be tested on more platforms that only the mvebu ones, it would
> take some time, and I don't want to still have "broken" platform
> during more release candidate. So at the end this patch should be part
> of the 3.15 kernel.

Gregory,

I admit, your patch is more general and I am looking forward to revert
the reorder fix as soon as this is ready :)

BTW, what happened to the early device discussion? Couldn't this be
picked up here to allow -EPROBE_DEFER also for those early drivers?

Sebastian

WARNING: multiple messages have this Message-ID (diff)
From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
To: Gregory CLEMENT <gregory.clement@free-electrons.com>,
	Mike Turquette <mturquette@linaro.org>
Cc: linux-kernel@vger.kernel.org, Jason Cooper <jason@lakedaemon.net>,
	Andrew Lunn <andrew@lunn.ch>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] clk: respect the clock dependencies in of_clk_init
Date: Thu, 06 Feb 2014 00:11:39 +0100	[thread overview]
Message-ID: <52F2C52B.60001@gmail.com> (raw)
In-Reply-To: <1391554766-11285-1-git-send-email-gregory.clement@free-electrons.com>

On 02/04/2014 11:59 PM, 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.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> [...]
> this patch could solve the issues we get on severals mvebu platform
> since 3.14-rc1. This is an alternate solution of the patch set sent by
> Sebastian. However as it modifies the clock framework itself, it is
> more sensible.
>
> I find this solution more elegant than changing the order of the
> initialization of the clock at the platform level. However as it
> should be tested on more platforms that only the mvebu ones, it would
> take some time, and I don't want to still have "broken" platform
> during more release candidate. So at the end this patch should be part
> of the 3.15 kernel.

Gregory,

I admit, your patch is more general and I am looking forward to revert
the reorder fix as soon as this is ready :)

BTW, what happened to the early device discussion? Couldn't this be
picked up here to allow -EPROBE_DEFER also for those early drivers?

Sebastian

  parent reply	other threads:[~2014-02-05 23:11 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-04 22:59 [PATCH] clk: respect the clock dependencies in of_clk_init Gregory CLEMENT
2014-02-04 22:59 ` Gregory CLEMENT
2014-02-05  5:09 ` Jason Cooper
2014-02-05  5:09   ` Jason Cooper
2014-02-05  8:45 ` Boris BREZILLON
2014-02-05  8:45   ` Boris BREZILLON
2014-02-05  9:48 ` [PATCH] clk: add strict of_clk_init dependency check Boris BREZILLON
2014-02-05  9:48   ` Boris BREZILLON
2014-02-05 14:48   ` Gregory CLEMENT
2014-02-05 14:48     ` Gregory CLEMENT
2014-02-05 15:05     ` Gregory CLEMENT
2014-02-05 15:05       ` Gregory CLEMENT
2014-02-05 15:07       ` Boris BREZILLON
2014-02-05 15:07         ` Boris BREZILLON
2014-02-05 23:11 ` Sebastian Hesselbarth [this message]
2014-02-05 23:11   ` [PATCH] clk: respect the clock dependencies in of_clk_init Sebastian Hesselbarth
2014-02-07 13:06 ` Emilio López
2014-02-07 13:06   ` Emilio López
2014-02-07 14:24   ` Jason Cooper
2014-02-07 14:24     ` Jason Cooper
2014-02-07 14:43     ` Ezequiel Garcia
2014-02-07 14:43       ` Ezequiel Garcia
2014-02-07 14:49       ` Gregory CLEMENT
2014-02-07 14:49         ` Gregory CLEMENT
2014-02-07 15:00         ` Emilio López
2014-02-07 15:00           ` Emilio López
2014-02-07 15:12           ` Gregory CLEMENT
2014-02-07 15:12             ` Gregory CLEMENT
2014-02-07 16:16             ` Emilio López
2014-02-07 16:16               ` Emilio López
2014-02-07 18:10               ` Gregory CLEMENT
2014-02-07 18:10                 ` Gregory CLEMENT
2014-02-07 18:17                 ` Emilio López
2014-02-07 18:17                   ` Emilio López
2014-02-07 23:15         ` Sebastian Hesselbarth
2014-02-07 23:15           ` Sebastian Hesselbarth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52F2C52B.60001@gmail.com \
    --to=sebastian.hesselbarth@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.