All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukasz Majewski <l.majewski@samsung.com>
To: Jassi Brar <jassisinghbrar@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>,
	Mike Turquette <mturquette@linaro.org>,
	abrestic@chromium.org, Viresh Kumar <viresh.kumar@linaro.org>,
	Arun Kumar K <arunkk.samsung@gmail.com>,
	rjw@rjwysocki.net, Tomasz Figa <tomasz.figa@gmail.com>,
	cpufreq@vger.kernel.org, Sachin Kamat <sachin.kamat@linaro.org>,
	linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	arjun.kv@samsung.com,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 3/3] cpufreq: exynos: Add exynos5420 cpufreq driver
Date: Tue, 17 Dec 2013 09:14:56 +0100	[thread overview]
Message-ID: <20131217091456.1af748c3@amdc2363> (raw)
In-Reply-To: <CABb+yY0C50va5UAgv5QKGKK6qE1wiDwcUmn54CC7PVQ8vpoEmg@mail.gmail.com>

Hi Jassi,

> On Tue, Dec 10, 2013 at 10:02 PM, Lukasz Majewski
> <l.majewski@samsung.com> wrote:
> >>
> >> Actually these values are not for PLL, but for the dividers.
> >> If you see below, the PLL rate setting is done through
> >> clk_set_rate() going via CCF. But I found an issue if the divider
> >> values are set via clk_set_rate API.
> >> What I found is, the system goes into freeze if all the divider
> >> values are not set in one shot. So we cannot call multiple
> >> clk_set_rate()'s on each divider. Thats why I continued with
> >> non-CCF way of setting the divider.
> >
> > I see. I'm not an expert on common clock framework (CCF), but for me
> > conceptually clock dividers setting shall be handled by CCF.
> >
> > However, I've poked a bit at CCF. There isn't any out of the box
> > solutions available.
> >
> > A "virtual" clock can be defined and inside its implementation we
> > can atomically set dividers. Another solution would be to hack the
> > current CCF to provide atomic clock operations
> >
> CCF isn't only for clocks that have single divider or gate control
> register. One could define a clock that manipulates more than one
> divider/gate in one CCF callback. It is already abstract enough. So
> implementing a virtual clock is the solution, imho.

Thanks for sharing your experience.

>  BTW, on my platform linux needs to send a 'non-atomic' IPC message to
> a master co-processor to scale up/down cpufreq. I just define a
> virtual clock and use the generic bL cpufreq driver
> drivers/cpufreq/arm_big_little.c

My use case is simpler - cpufreq-cpu0.c or arm_bit_little.c (for bL)
driver with maybe two virtual clocks to handle divider's update.

> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

WARNING: multiple messages have this Message-ID (diff)
From: l.majewski@samsung.com (Lukasz Majewski)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/3] cpufreq: exynos: Add exynos5420 cpufreq driver
Date: Tue, 17 Dec 2013 09:14:56 +0100	[thread overview]
Message-ID: <20131217091456.1af748c3@amdc2363> (raw)
In-Reply-To: <CABb+yY0C50va5UAgv5QKGKK6qE1wiDwcUmn54CC7PVQ8vpoEmg@mail.gmail.com>

Hi Jassi,

> On Tue, Dec 10, 2013 at 10:02 PM, Lukasz Majewski
> <l.majewski@samsung.com> wrote:
> >>
> >> Actually these values are not for PLL, but for the dividers.
> >> If you see below, the PLL rate setting is done through
> >> clk_set_rate() going via CCF. But I found an issue if the divider
> >> values are set via clk_set_rate API.
> >> What I found is, the system goes into freeze if all the divider
> >> values are not set in one shot. So we cannot call multiple
> >> clk_set_rate()'s on each divider. Thats why I continued with
> >> non-CCF way of setting the divider.
> >
> > I see. I'm not an expert on common clock framework (CCF), but for me
> > conceptually clock dividers setting shall be handled by CCF.
> >
> > However, I've poked a bit at CCF. There isn't any out of the box
> > solutions available.
> >
> > A "virtual" clock can be defined and inside its implementation we
> > can atomically set dividers. Another solution would be to hack the
> > current CCF to provide atomic clock operations
> >
> CCF isn't only for clocks that have single divider or gate control
> register. One could define a clock that manipulates more than one
> divider/gate in one CCF callback. It is already abstract enough. So
> implementing a virtual clock is the solution, imho.

Thanks for sharing your experience.

>  BTW, on my platform linux needs to send a 'non-atomic' IPC message to
> a master co-processor to scale up/down cpufreq. I just define a
> virtual clock and use the generic bL cpufreq driver
> drivers/cpufreq/arm_big_little.c

My use case is simpler - cpufreq-cpu0.c or arm_bit_little.c (for bL)
driver with maybe two virtual clocks to handle divider's update.

> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

  reply	other threads:[~2013-12-17  8:14 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-06  9:48 [PATCH 0/3] Exynos5420 Cpufreq support Arun Kumar K
2013-12-06  9:48 ` Arun Kumar K
2013-12-06  9:48 ` [PATCH 1/3] ARM: EXYNOS: Add exynos5 CPU clock divider offsets Arun Kumar K
2013-12-06  9:48   ` Arun Kumar K
2013-12-20 21:23   ` Kukjin Kim
2013-12-20 21:23     ` Kukjin Kim
2013-12-06  9:48 ` [PATCH 2/3] clk: exynos5420: Add alias names for cpu clocks Arun Kumar K
2013-12-06  9:48   ` Arun Kumar K
2013-12-19  8:00   ` Mike Turquette
2013-12-19  8:00     ` Mike Turquette
2013-12-06  9:48 ` [PATCH 3/3] cpufreq: exynos: Add exynos5420 cpufreq driver Arun Kumar K
2013-12-06  9:48   ` Arun Kumar K
2013-12-09  8:23   ` Lukasz Majewski
2013-12-09  8:23     ` Lukasz Majewski
2013-12-10  4:40     ` Arun Kumar K
2013-12-10  4:40       ` Arun Kumar K
2013-12-10 16:32       ` Lukasz Majewski
2013-12-10 16:32         ` Lukasz Majewski
2013-12-17  7:07         ` Jassi Brar
2013-12-17  7:07           ` Jassi Brar
2013-12-17  8:14           ` Lukasz Majewski [this message]
2013-12-17  8:14             ` Lukasz Majewski
2013-12-17  8:21             ` Arun Kumar K
2013-12-17  8:21               ` Arun Kumar K
2013-12-17  6:12   ` Viresh Kumar
2013-12-17  6:12     ` Viresh Kumar
2013-12-17  8:00     ` Lukasz Majewski
2013-12-17  8:00       ` Lukasz Majewski
2013-12-17  8:03       ` Viresh Kumar
2013-12-17  8:03         ` Viresh Kumar
2013-12-17  8:05       ` Arun Kumar K
2013-12-17  8:05         ` Arun Kumar K
2013-12-17  9:09         ` Lukasz Majewski
2013-12-17  9:09           ` Lukasz Majewski
2013-12-17  8:03     ` Arun Kumar K
2013-12-17  8:03       ` Arun Kumar K

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=20131217091456.1af748c3@amdc2363 \
    --to=l.majewski@samsung.com \
    --cc=abrestic@chromium.org \
    --cc=arjun.kv@samsung.com \
    --cc=arunkk.samsung@gmail.com \
    --cc=cpufreq@vger.kernel.org \
    --cc=jassisinghbrar@gmail.com \
    --cc=kgene.kim@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=mturquette@linaro.org \
    --cc=rjw@rjwysocki.net \
    --cc=sachin.kamat@linaro.org \
    --cc=tomasz.figa@gmail.com \
    --cc=viresh.kumar@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.