All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomasz Figa <tomasz.figa@gmail.com>
To: linux-arm-kernel@lists.infradead.org
Cc: Chander Kashyap <chander.kashyap@linaro.org>,
	thomas.abraham@linaro.org, linux-samsung-soc@vger.kernel.org,
	mturquette@linaro.org
Subject: Re: [RFC Patch v2 0/3] add temporary parent migration support
Date: Wed, 04 Sep 2013 00:36:50 +0200	[thread overview]
Message-ID: <3927125.3UOplv4uU5@localhost> (raw)
In-Reply-To: <1378208072-10173-1-git-send-email-chander.kashyap@linaro.org>

Hi Chander,

On Tuesday 03 of September 2013 17:04:28 Chander Kashyap wrote:
> Some platform has provision to change cpu parent clock during
> cpu frequency scaling. This patch series provides a mechanism to
> implement the same using CCF.
> 
> Patch1 provides mechanism to migrate to new parent temporarily.
> 
> Patch2 updates the user of clk_register_mux and DEFINE_CLK_MUX which are
> modified to add support for clk migration.
> 
> Patch3 adds support to Exynos5250 to use the clock parent migration
> feature implemented in CCF.

I don't really like this approach. A need to change mux setting 
temporarily is heavily platform-specific and I don't think it should be 
handled by generic code. First of all there are many factor that you would 
have to account for to make this solution generic, such as:
 - board specific alternative parents,
 - exact moment of parent change,
 - some other platform specific conditions, like CPU voltage that must be 
changed when mux is changed, because it changes CPU frequency,
 - and probably a lot of more factors that only people working with all 
the platforms supported (and unsupported yet) by Linux.

I can see at least two solutions for this problem that don't require 
changing core code of common clock framework:

1) Implementing a special clock type using normal mux ops, but also 
registering a notifier for its PRE_RATE_CHANGE and POST_RATE_CHANGE events 
to perform parent switching.

2) Using normal mux clock, but registering such notifiers in clock 
controller or cpufreq driver.

Best regards,
Tomasz

WARNING: multiple messages have this Message-ID (diff)
From: tomasz.figa@gmail.com (Tomasz Figa)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC Patch v2 0/3] add temporary parent migration support
Date: Wed, 04 Sep 2013 00:36:50 +0200	[thread overview]
Message-ID: <3927125.3UOplv4uU5@localhost> (raw)
In-Reply-To: <1378208072-10173-1-git-send-email-chander.kashyap@linaro.org>

Hi Chander,

On Tuesday 03 of September 2013 17:04:28 Chander Kashyap wrote:
> Some platform has provision to change cpu parent clock during
> cpu frequency scaling. This patch series provides a mechanism to
> implement the same using CCF.
> 
> Patch1 provides mechanism to migrate to new parent temporarily.
> 
> Patch2 updates the user of clk_register_mux and DEFINE_CLK_MUX which are
> modified to add support for clk migration.
> 
> Patch3 adds support to Exynos5250 to use the clock parent migration
> feature implemented in CCF.

I don't really like this approach. A need to change mux setting 
temporarily is heavily platform-specific and I don't think it should be 
handled by generic code. First of all there are many factor that you would 
have to account for to make this solution generic, such as:
 - board specific alternative parents,
 - exact moment of parent change,
 - some other platform specific conditions, like CPU voltage that must be 
changed when mux is changed, because it changes CPU frequency,
 - and probably a lot of more factors that only people working with all 
the platforms supported (and unsupported yet) by Linux.

I can see at least two solutions for this problem that don't require 
changing core code of common clock framework:

1) Implementing a special clock type using normal mux ops, but also 
registering a notifier for its PRE_RATE_CHANGE and POST_RATE_CHANGE events 
to perform parent switching.

2) Using normal mux clock, but registering such notifiers in clock 
controller or cpufreq driver.

Best regards,
Tomasz

  parent reply	other threads:[~2013-09-03 22:36 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-03 11:34 [RFC Patch v2 0/3] add temporary parent migration support Chander Kashyap
2013-09-03 11:34 ` Chander Kashyap
2013-09-03 11:34 ` [RFC Patch v2 1/3] clk: add support for temporary parent clock migration Chander Kashyap
2013-09-03 11:34   ` Chander Kashyap
2013-09-03 21:47   ` Sylwester Nawrocki
2013-09-03 21:47     ` Sylwester Nawrocki
2013-09-04  6:06     ` Chander Kashyap
2013-09-04  6:06       ` Chander Kashyap
2013-09-07  3:37       ` Saravana Kannan
2013-09-07  3:37         ` Saravana Kannan
2013-09-03 11:34 ` [RFC Patch v2 2/3] clk: update users of "clk_register_mux" and "DEFINE_CLK_MUX" Chander Kashyap
2013-09-03 11:34   ` Chander Kashyap
2013-09-03 11:34 ` [RFC Patch v2 3/3] clk: samsung: Exynos5250: Add alternate parent name for mout_cpu Chander Kashyap
2013-09-03 11:34   ` Chander Kashyap
2013-09-03 22:36 ` Tomasz Figa [this message]
2013-09-03 22:36   ` [RFC Patch v2 0/3] add temporary parent migration support Tomasz Figa
2013-09-04  6:02   ` Chander Kashyap
2013-09-04  6:02     ` Chander Kashyap
2013-09-04 17:43   ` Mike Turquette
2013-09-04 17:43     ` Mike Turquette
2013-09-04 18:01     ` Tomasz Figa
2013-09-04 18:01       ` Tomasz Figa
2013-09-05 18:32       ` Mike Turquette
2013-09-05 18:32         ` Mike Turquette
2013-09-11  4:22         ` Chander Kashyap
2013-09-11  4:22           ` Chander Kashyap
2013-09-11  4:19       ` Chander Kashyap
2013-09-11  4:19         ` Chander Kashyap

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=3927125.3UOplv4uU5@localhost \
    --to=tomasz.figa@gmail.com \
    --cc=chander.kashyap@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=mturquette@linaro.org \
    --cc=thomas.abraham@linaro.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.