All of lore.kernel.org
 help / color / mirror / Atom feed
From: mturquette@linaro.org (Mike Turquette)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] clk: mediatek: Export CPU mux clocks for CPU frequency control
Date: Tue, 10 Mar 2015 16:59:12 -0700	[thread overview]
Message-ID: <20150310235912.14952.99786@quantum> (raw)
In-Reply-To: <CAKohponSqLPcULA9-T8y9b_b44Torti0p6W3sJfRZ1oKUWqtTw@mail.gmail.com>

Quoting Viresh Kumar (2015-03-05 00:59:50)
> On 5 March 2015 at 13:12, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > We have clk_set_parent for changing the parent and clk_set_rate to
> > change the rate. Use the former for changing the parent and the latter
> > for changing the rate. What you are interested in is changing the
> > parent, so use clk_set_parent for this and not abuse a side effect
> > of clk_set_rate.
> 
> clk_set_rate() for CPUs clock is responsible to change clock rate
> of the CPU. Whether it plays with PLLs or muxes, its not that relevant.

Agreed.

> 
> > My suggestion is to take another approach. Implement clk_set_rate for
> > these muxes and in the set_rate hook:
> >
> > - switch mux to intermediate PLL parent
> > - call clk_set_rate() for the real parent PLL
> > - switch mux back to real parent PLL
> >
> > This way the things happening behind the scenes are completely transparent
> > to the cpufreq driver and you can use cpufreq-dt as is without changes.
> 
> CPUFreq wants to change to intermediate frequency by itself against
> some magic change behind the scene. The major requirement for that
> comes from the fact that we want to send PRE/POST freq notifiers on
> which loops-per-jiffie depends.

I assume you are saying that you want to update loops-per-jiffie while
at an intermediate frequency. Why? This operation should not take very
long.

Imagine a (hypothetical?) processor that changes frequency in many small
steps until it converges to the target rate. Would you want to update
lpj for every step?

Regards,
Mike

WARNING: multiple messages have this Message-ID (diff)
From: Mike Turquette <mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: Viresh Kumar
	<viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cc: Pi-Cheng Chen
	<pi-cheng.chen-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	Matthias Brugger
	<matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
	Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	Ian Campbell
	<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
	Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	Henry Chen <henryc.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
	James Liao <jamesjj.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
	Chen Fan <fan.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
	Eddie Huang <eddie.huang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
	"Joe.C" <yingjoe.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
	Linux Kernel Mailing List
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Linaro Kernel Mailman List
	<linaro-kernel-cunTk1MwBs8s++Sfvej+rw@public.gmane.org>,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH] clk: mediatek: Export CPU mux clocks for CPU frequency control
Date: Tue, 10 Mar 2015 16:59:12 -0700	[thread overview]
Message-ID: <20150310235912.14952.99786@quantum> (raw)
In-Reply-To: <CAKohponSqLPcULA9-T8y9b_b44Torti0p6W3sJfRZ1oKUWqtTw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Quoting Viresh Kumar (2015-03-05 00:59:50)
> On 5 March 2015 at 13:12, Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> > We have clk_set_parent for changing the parent and clk_set_rate to
> > change the rate. Use the former for changing the parent and the latter
> > for changing the rate. What you are interested in is changing the
> > parent, so use clk_set_parent for this and not abuse a side effect
> > of clk_set_rate.
> 
> clk_set_rate() for CPUs clock is responsible to change clock rate
> of the CPU. Whether it plays with PLLs or muxes, its not that relevant.

Agreed.

> 
> > My suggestion is to take another approach. Implement clk_set_rate for
> > these muxes and in the set_rate hook:
> >
> > - switch mux to intermediate PLL parent
> > - call clk_set_rate() for the real parent PLL
> > - switch mux back to real parent PLL
> >
> > This way the things happening behind the scenes are completely transparent
> > to the cpufreq driver and you can use cpufreq-dt as is without changes.
> 
> CPUFreq wants to change to intermediate frequency by itself against
> some magic change behind the scene. The major requirement for that
> comes from the fact that we want to send PRE/POST freq notifiers on
> which loops-per-jiffie depends.

I assume you are saying that you want to update loops-per-jiffie while
at an intermediate frequency. Why? This operation should not take very
long.

Imagine a (hypothetical?) processor that changes frequency in many small
steps until it converges to the target rate. Would you want to update
lpj for every step?

Regards,
Mike
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Mike Turquette <mturquette@linaro.org>
To: Viresh Kumar <viresh.kumar@linaro.org>,
	"Sascha Hauer" <s.hauer@pengutronix.de>
Cc: "Pi-Cheng Chen" <pi-cheng.chen@linaro.org>,
	"Stephen Boyd" <sboyd@codeaurora.org>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Pawel Moll" <pawel.moll@arm.com>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Ian Campbell" <ijc+devicetree@hellion.org.uk>,
	"Kumar Gala" <galak@codeaurora.org>,
	"Henry Chen" <henryc.chen@mediatek.com>,
	"James Liao" <jamesjj.liao@mediatek.com>,
	"Chen Fan" <fan.chen@mediatek.com>,
	"Eddie Huang" <eddie.huang@mediatek.com>,
	"Joe.C" <yingjoe.chen@mediatek.com>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"Linaro Kernel Mailman List" <linaro-kernel@lists.linaro.org>,
	linux-mediatek@lists.infradead.org
Subject: Re: [PATCH] clk: mediatek: Export CPU mux clocks for CPU frequency control
Date: Tue, 10 Mar 2015 16:59:12 -0700	[thread overview]
Message-ID: <20150310235912.14952.99786@quantum> (raw)
In-Reply-To: <CAKohponSqLPcULA9-T8y9b_b44Torti0p6W3sJfRZ1oKUWqtTw@mail.gmail.com>

Quoting Viresh Kumar (2015-03-05 00:59:50)
> On 5 March 2015 at 13:12, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > We have clk_set_parent for changing the parent and clk_set_rate to
> > change the rate. Use the former for changing the parent and the latter
> > for changing the rate. What you are interested in is changing the
> > parent, so use clk_set_parent for this and not abuse a side effect
> > of clk_set_rate.
> 
> clk_set_rate() for CPUs clock is responsible to change clock rate
> of the CPU. Whether it plays with PLLs or muxes, its not that relevant.

Agreed.

> 
> > My suggestion is to take another approach. Implement clk_set_rate for
> > these muxes and in the set_rate hook:
> >
> > - switch mux to intermediate PLL parent
> > - call clk_set_rate() for the real parent PLL
> > - switch mux back to real parent PLL
> >
> > This way the things happening behind the scenes are completely transparent
> > to the cpufreq driver and you can use cpufreq-dt as is without changes.
> 
> CPUFreq wants to change to intermediate frequency by itself against
> some magic change behind the scene. The major requirement for that
> comes from the fact that we want to send PRE/POST freq notifiers on
> which loops-per-jiffie depends.

I assume you are saying that you want to update loops-per-jiffie while
at an intermediate frequency. Why? This operation should not take very
long.

Imagine a (hypothetical?) processor that changes frequency in many small
steps until it converges to the target rate. Would you want to update
lpj for every step?

Regards,
Mike

  parent reply	other threads:[~2015-03-10 23:59 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-04 10:49 [PATCH] clk: mediatek: Export CPU mux clocks for CPU frequency control pi-cheng.chen
2015-03-04 10:49 ` pi-cheng.chen
2015-03-04 11:21 ` Sascha Hauer
2015-03-04 11:21   ` Sascha Hauer
2015-03-05  2:43   ` Pi-Cheng Chen
2015-03-05  2:43     ` Pi-Cheng Chen
2015-03-05  7:42     ` Sascha Hauer
2015-03-05  7:42       ` Sascha Hauer
2015-03-05  8:58       ` Pi-Cheng Chen
2015-03-05  8:58         ` Pi-Cheng Chen
2015-03-05  8:58         ` Pi-Cheng Chen
2015-03-05  8:59       ` Viresh Kumar
2015-03-05  8:59         ` Viresh Kumar
2015-03-05  8:59         ` Viresh Kumar
2015-03-05  9:19         ` Sascha Hauer
2015-03-05  9:19           ` Sascha Hauer
2015-03-05  9:19           ` Sascha Hauer
2015-03-05  9:39           ` Pi-Cheng Chen
2015-03-05  9:39             ` Pi-Cheng Chen
2015-03-05  9:39             ` Pi-Cheng Chen
2015-03-05 10:51             ` Sascha Hauer
2015-03-05 10:51               ` Sascha Hauer
2015-03-05 11:02               ` Viresh Kumar
2015-03-05 11:02                 ` Viresh Kumar
2015-03-11  0:13                 ` Mike Turquette
2015-03-11  0:13                   ` Mike Turquette
2015-03-12  9:21                   ` Viresh Kumar
2015-03-12  9:21                     ` Viresh Kumar
2015-03-12  9:21                     ` Viresh Kumar
2015-03-12 10:36                 ` Russell King - ARM Linux
2015-03-12 10:36                   ` Russell King - ARM Linux
2015-03-05 11:33               ` Pi-Cheng Chen
2015-03-05 11:33                 ` Pi-Cheng Chen
2015-03-05 10:23           ` Viresh Kumar
2015-03-05 10:23             ` Viresh Kumar
2015-03-05 10:59         ` Sascha Hauer
2015-03-05 10:59           ` Sascha Hauer
2015-03-10 23:59         ` Mike Turquette [this message]
2015-03-10 23:59           ` Mike Turquette
2015-03-10 23:59           ` Mike Turquette
2015-03-12  9:22           ` Viresh Kumar
2015-03-12  9:22             ` Viresh Kumar
2015-03-12  9:22             ` Viresh Kumar
2015-03-10  1:53       ` Pi-Cheng Chen
2015-03-10  1:53         ` Pi-Cheng Chen
2015-03-10  7:55         ` Sascha Hauer
2015-03-10  7:55           ` Sascha Hauer
2015-03-11  7:00           ` Pi-Cheng Chen
2015-03-11  7:00             ` Pi-Cheng Chen
  -- strict thread matches above, loose matches on Subject: below --
2015-07-14 12:47 [PATCH v4] " Daniel Kurtz
2015-07-15  6:38 ` [PATCH] " Pi-Cheng Chen
2015-07-15  6:38   ` Pi-Cheng Chen
2015-08-03 11:13   ` Pi-Cheng Chen
2015-08-03 11:13     ` Pi-Cheng Chen
2015-08-03 11:13     ` Pi-Cheng Chen

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=20150310235912.14952.99786@quantum \
    --to=mturquette@linaro.org \
    --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.