From: "Cousson, Benoit" <b-cousson@ti.com>
To: "Valkeinen, Tomi" <tomi.valkeinen@ti.com>
Cc: "Hilman, Kevin" <khilman@ti.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
"paul@pwsan.com" <paul@pwsan.com>
Subject: Re: [PATCH 19/27] OMAP: DSS2: Use PM runtime & HWMOD support
Date: Mon, 06 Jun 2011 15:28:21 +0000 [thread overview]
Message-ID: <4DECF215.5020505@ti.com> (raw)
In-Reply-To: <1307368525.1910.50.camel@deskari>
On 6/6/2011 3:55 PM, Valkeinen, Tomi wrote:
> On Mon, 2011-06-06 at 15:46 +0200, Cousson, Benoit wrote:
>> On 6/6/2011 3:21 PM, Valkeinen, Tomi wrote:
>>> On Mon, 2011-06-06 at 15:15 +0200, Cousson, Benoit wrote:
>>>> On 6/6/2011 3:01 PM, Valkeinen, Tomi wrote:
>>>>> On Mon, 2011-06-06 at 14:56 +0200, Cousson, Benoit wrote:
>>>
>>>>> In this long term solution, if the dss_fclk is the main_clk, how does
>>>>> the framework handle the situation when we want to switch from the
>>>>> standard DSS fclk to the one from DSI PLL?
>>>>
>>>> That part cannot be done by the hwmod fmwk anyway. The goal of the fmwk
>>>> is to ensure that the module is accessible by the driver whatever the
>>>> PRCM clock used.
>>>> Enabling the DSI PLL will require the PRCM clock to be enabled first.
>>>>
>>>> Using the DSI PLL as the fclk is doable, but is it really useful or needed?
>>>
>>> Yes, it's useful and needed. It gives us much finer control to the clock
>>> frequencies, and so allows us to go to higher frequencies and also more
>>> exactly to the required pixel clock.
>>>
>>>> Assuming you need that mode, you will always have to explicitly switch
>>>> from DSI to PRCM clock before trying to disable the DSS.
>>>> This is something you will have to do inside the DSS driver. It should
>>>> be transparent to the hwmod fmwk.
>>>
>>> This sounds ok.
>>>
>>> I think the main question is how do we disable the standard DSS fclk
>>> from PRCM when using DSI PLL? As far as I know, disabling that clock
>>> will allow some areas of OMAP to be shut down even while DSS is working.
>>> So from power management point of view it sounds a needed feature.
>>
>> Yes, at least in theory, but considering that any use case that will
>> require the DSI PLL will use a LCD panel + backlight, or an OLED panel
>> that will consume 50 times more than the 186 MHz clock, I do not think
>> it is really needed.
>> Moreover, that clock is generated by the PER DPLL that will be always
>> enabled in most usecase because it does generate the UART, I2C and most
>> basic peripherals clocks. If we cannot gate the PER DPLL, there is no
>> saving to expect from gating the DSS fclk only.
>> Bottom-line is that there is no practical power saving to expect from
>> that mode.
>>
>>> If the clock is main_clk for the HWMOD, it sounds to me it's always
>>> enabled if the HWMOD is enabled?
>>
>> Yes, but that sounds to me a good trade off to avoid unnecessary
>> complexity in your driver or in the hwmod fmwk.
>
> Ok, if there are no real power savings there, then I agree, it's
> pointless to add that complexity.
>
> So how do we go forward in short term? I'd very much like to remove all
> the "silly" code from the DSS pm_runtime patch series caused by this
> opt_clock handling. Is it possible to get some kind of a temporary
> solution in the hwmod framework which would somehow solve this from DSS
> driver's point of view? A flag that causes hwmod fmwk to enable
> opt-clocks automatically? Or is it possible to have more than one
> mandatory clock?
Before doing that, could you maybe just try something to make OMAP4
looks a little bit more like OMAP3?
dss_fck -> ick
dss_dss_fck -> main_clk
That should ensure that both modulemode and the PRCM fclk will be
managed by pm_runtime.
I just did a basic patch for the first module, you should maybe change
some other entries.
Regards,
Benoit
---
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 614d680..4dfd18a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -1134,7 +1134,7 @@ static struct omap_hwmod_addr_space
omap44xx_dss_dma_addrs[] = {
static struct omap_hwmod_ocp_if omap44xx_l3_main_2__dss = {
.master = &omap44xx_l3_main_2_hwmod,
.slave = &omap44xx_dss_hwmod,
- .clk = "l3_div_ck",
+ .clk = "dss_fck",
.addr = omap44xx_dss_dma_addrs,
.addr_cnt = ARRAY_SIZE(omap44xx_dss_dma_addrs),
.user = OCP_USER_SDMA,
@@ -1167,14 +1167,13 @@ static struct omap_hwmod_ocp_if
*omap44xx_dss_slaves[] = {
static struct omap_hwmod_opt_clk dss_opt_clks[] = {
{ .role = "sys_clk", .clk = "dss_sys_clk" },
{ .role = "tv_clk", .clk = "dss_tv_clk" },
- { .role = "dss_clk", .clk = "dss_dss_clk" },
{ .role = "video_clk", .clk = "dss_48mhz_clk" },
};
static struct omap_hwmod omap44xx_dss_hwmod = {
.name = "dss_core",
.class = &omap44xx_dss_hwmod_class,
- .main_clk = "dss_fck",
+ .main_clk = "dss_dss_fck",
.prcm = {
.omap4 = {
.clkctrl_reg = OMAP4430_CM_DSS_DSS_CLKCTRL,
next prev parent reply other threads:[~2011-06-06 15:28 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-03 10:00 [PATCH 00/27] OMAP DSS runtime PM adaptation Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 01/27] OMAP: change get_context_loss_count ret value to int Tomi Valkeinen
2011-06-03 16:32 ` Kevin Hilman
2011-06-06 7:28 ` [PATCH 01/27] OMAP: change get_context_loss_count ret value to Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 02/27] OMAP: DSS2: Taal: Make driver more fault tolerant Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 03/27] OMAP: DSS2: Reset LANEx_ULPS_SIG2 bits after use Tomi Valkeinen
2011-06-06 5:53 ` Archit Taneja
2011-06-06 7:21 ` Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 04/27] OMAP: DSS2: Handle dpll4_m4_ck in dss_get/put_clocks Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 05/27] OMAP: DSS2: Clean up probe for DSS & DSI Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 06/27] OMAP: DSS2: Init dispc first before other components Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 07/27] OMAP: DSS2: Remove clk optimization at dss init Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 08/27] OMAP: DSS2: rewrite use of context_loss_count Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 09/27] OMAP: DSS2: Use omap_pm_get_dev_context_loss_count to get ctx loss count Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 10/27] OMAP: DSS2: DPI: remove unneeded SYSCK enable/disable Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 11/27] OMAP: DSS2: Add FEAT_VENC_REQUIRES_TV_DAC_CLK Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 12/27] OMAP: DSS2: Add new FEAT definitions for features missing from OMAP2 Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 13/27] OMAP: DSS2: Remove core_dump_clocks Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 14/27] OMAP: DSS2: Remove CONFIG_OMAP2_DSS_SLEEP_BEFORE_RESET Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 15/27] OMAP4: HWMOD: Modify DSS opt clocks Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 16/27] OMAP3: HWMOD: Add " Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 17/27] OMAP2420: " Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 18/27] OMAP2430: " Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 19/27] OMAP: DSS2: Use PM runtime & HWMOD support Tomi Valkeinen
2011-06-03 16:45 ` Kevin Hilman
2011-06-03 17:43 ` Tomi Valkeinen
2011-06-03 22:53 ` Kevin Hilman
2011-06-04 8:01 ` Tomi Valkeinen
2011-06-06 12:56 ` Cousson, Benoit
2011-06-06 13:01 ` Tomi Valkeinen
2011-06-06 13:15 ` Cousson, Benoit
2011-06-06 13:21 ` Tomi Valkeinen
2011-06-06 13:46 ` Cousson, Benoit
2011-06-06 13:55 ` Tomi Valkeinen
2011-06-06 15:28 ` Cousson, Benoit [this message]
2011-06-07 6:52 ` Tomi Valkeinen
2011-06-07 9:08 ` Tomi Valkeinen
2011-06-07 11:37 ` Cousson, Benoit
2011-06-07 11:51 ` Tomi Valkeinen
2011-06-07 16:43 ` Cousson, Benoit
2011-06-08 7:55 ` Tomi Valkeinen
2011-06-08 20:39 ` Cousson, Benoit
2011-06-07 6:47 ` Tomi Valkeinen
2011-06-07 7:12 ` Cousson, Benoit
2011-06-07 7:21 ` Tomi Valkeinen
2011-06-07 7:27 ` Cousson, Benoit
2011-06-03 10:00 ` [PATCH 20/27] OMAP4: HWMOD: Remove unneeded DSS opt clocks Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 21/27] OMAP: DSS2: Remove unused opt_clock_available Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 22/27] OMAP: DSS2: DISPC: remove finegrained clk enables/disables Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 23/27] OMAP: DSS2: Remove unused code from display.c Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 24/27] OMAP: DSS2: Remove ctx loss count from dss.c Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 25/27] OMAP4: CLKDEV: Remove omapdss clock aliases Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 26/27] OMAP: DSS2: DISPC: Fix context save/restore Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 27/27] OMAP: DSS2: DSS: " Tomi Valkeinen
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=4DECF215.5020505@ti.com \
--to=b-cousson@ti.com \
--cc=khilman@ti.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=tomi.valkeinen@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).