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
next prev 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.