From: Sylwester Nawrocki <s.nawrocki@samsung.com>
To: Kukjin Kim <kgene.kim@samsung.com>
Cc: 'Chanwoo Choi' <cw00.choi@samsung.com>,
'Sylwester Nawrocki' <snjw23@gmail.com>,
'linux-samsung-soc' <linux-samsung-soc@vger.kernel.org>,
'Russell King - ARM Linux' <linux@arm.linux.org.uk>,
'Kyungmin Park' <kyungmin.park@samsung.com>,
linux-pm@lists.linux-foundation.org,
'linux-arm-kernel' <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/3 v3] ARM: EXYNOS4: Support for generic I/O power domains on EXYNOS4210/4212
Date: Thu, 03 Nov 2011 11:24:34 +0100 [thread overview]
Message-ID: <4EB26BE2.2060508@samsung.com> (raw)
In-Reply-To: <013301cc99cd$8d5a6a00$a80f3e00$%kim@samsung.com>
Hi Kgene,
On 11/03/2011 03:09 AM, Kukjin Kim wrote:
> As I said, I don't think we should control/gate the clocks with regarding power domain.
As far as I know there is a plan to let the drivers override start/stop_device callbacks,
moreover the clock control can be disabled globally by not implementing start/stop_device
callbacks or per device by not adding clkdev entities to the device clock list at runtime
PM core. So IMHO, there is/going to be enough flexibility.
> It should be controlled by each regarding device driver and in addition, as I know,
> to handle block of clock is not recommended on EXYNOS4 now.
What do you mean by this ? I couldn't find such information in any documentation.
Shouldn't "clock gate block" registers be touched by boot loader and the kernel?
Our boot loaders disable all clocks, and if the global clock gate is not enabled
by the kernel there is no chance any multimedia device will work.
Should the global clock block gate be always enabled then ? I'm afraid it is not
optimal form power management POV.
--
Thanks,
Sylwester
WARNING: multiple messages have this Message-ID (diff)
From: s.nawrocki@samsung.com (Sylwester Nawrocki)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3 v3] ARM: EXYNOS4: Support for generic I/O power domains on EXYNOS4210/4212
Date: Thu, 03 Nov 2011 11:24:34 +0100 [thread overview]
Message-ID: <4EB26BE2.2060508@samsung.com> (raw)
In-Reply-To: <013301cc99cd$8d5a6a00$a80f3e00$%kim@samsung.com>
Hi Kgene,
On 11/03/2011 03:09 AM, Kukjin Kim wrote:
> As I said, I don't think we should control/gate the clocks with regarding power domain.
As far as I know there is a plan to let the drivers override start/stop_device callbacks,
moreover the clock control can be disabled globally by not implementing start/stop_device
callbacks or per device by not adding clkdev entities to the device clock list at runtime
PM core. So IMHO, there is/going to be enough flexibility.
> It should be controlled by each regarding device driver and in addition, as I know,
> to handle block of clock is not recommended on EXYNOS4 now.
What do you mean by this ? I couldn't find such information in any documentation.
Shouldn't "clock gate block" registers be touched by boot loader and the kernel?
Our boot loaders disable all clocks, and if the global clock gate is not enabled
by the kernel there is no chance any multimedia device will work.
Should the global clock block gate be always enabled then ? I'm afraid it is not
optimal form power management POV.
--
Thanks,
Sylwester
next prev parent reply other threads:[~2011-11-03 10:24 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-25 10:35 [PATCH 1/3 v3] ARM: EXYNOS4: Support for generic I/O power domains on EXYNOS4210/4212 Chanwoo Choi
2011-10-25 10:35 ` Chanwoo Choi
2011-11-03 2:09 ` Kukjin Kim
2011-11-03 2:09 ` Kukjin Kim
2011-11-03 10:24 ` Sylwester Nawrocki [this message]
2011-11-03 10:24 ` Sylwester Nawrocki
2011-11-08 13:19 ` Chanwoo Choi
2011-11-15 9:21 ` Kukjin Kim
2011-11-15 9:21 ` [linux-pm] " Kukjin Kim
2011-11-15 9:21 ` Kukjin Kim
2011-11-15 9:32 ` Kyungmin Park
2011-11-15 9:32 ` [linux-pm] " Kyungmin Park
2011-11-15 9:32 ` Kyungmin Park
2011-11-03 10:24 ` Sylwester Nawrocki
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=4EB26BE2.2060508@samsung.com \
--to=s.nawrocki@samsung.com \
--cc=cw00.choi@samsung.com \
--cc=kgene.kim@samsung.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=snjw23@gmail.com \
/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.