All of lore.kernel.org
 help / color / mirror / Atom feed
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,

WARNING: multiple messages have this Message-ID (diff)
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, 6 Jun 2011 17:28:21 +0200	[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,

  reply	other threads:[~2011-06-06 15:28 UTC|newest]

Thread overview: 108+ 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 ` 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 10:00   ` Tomi Valkeinen
2011-06-03 16:32   ` Kevin Hilman
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-06  7:28       ` [PATCH 01/27] OMAP: change get_context_loss_count ret value to int 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   ` Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 03/27] OMAP: DSS2: Reset LANEx_ULPS_SIG2 bits after use Tomi Valkeinen
2011-06-03 10:00   ` Tomi Valkeinen
2011-06-06  5:41   ` Archit Taneja
2011-06-06  5:53     ` Archit Taneja
2011-06-06  7:21     ` Tomi Valkeinen
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   ` 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   ` 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   ` 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   ` 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   ` 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   ` 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   ` 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   ` 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   ` Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 13/27] OMAP: DSS2: Remove core_dump_clocks Tomi Valkeinen
2011-06-03 10:00   ` 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   ` Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 15/27] OMAP4: HWMOD: Modify DSS opt clocks Tomi Valkeinen
2011-06-03 10:00   ` Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 16/27] OMAP3: HWMOD: Add " Tomi Valkeinen
2011-06-03 10:00   ` Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 17/27] OMAP2420: " Tomi Valkeinen
2011-06-03 10:00   ` Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 18/27] OMAP2430: " Tomi Valkeinen
2011-06-03 10:00   ` Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 19/27] OMAP: DSS2: Use PM runtime & HWMOD support Tomi Valkeinen
2011-06-03 10:00   ` Tomi Valkeinen
2011-06-03 16:45   ` Kevin Hilman
2011-06-03 16:45     ` Kevin Hilman
2011-06-03 17:43     ` Tomi Valkeinen
2011-06-03 17:43       ` Tomi Valkeinen
2011-06-03 22:53       ` Kevin Hilman
2011-06-03 22:53         ` Kevin Hilman
2011-06-04  8:01         ` Tomi Valkeinen
2011-06-04  8:01           ` Tomi Valkeinen
2011-06-06 12:56           ` Cousson, Benoit
2011-06-06 12:56             ` Cousson, Benoit
2011-06-06 13:01             ` Tomi Valkeinen
2011-06-06 13:01               ` Tomi Valkeinen
2011-06-06 13:15               ` Cousson, Benoit
2011-06-06 13:15                 ` Cousson, Benoit
2011-06-06 13:21                 ` Tomi Valkeinen
2011-06-06 13:21                   ` Tomi Valkeinen
2011-06-06 13:46                   ` Cousson, Benoit
2011-06-06 13:46                     ` Cousson, Benoit
2011-06-06 13:55                     ` Tomi Valkeinen
2011-06-06 13:55                       ` Tomi Valkeinen
2011-06-06 15:28                       ` Cousson, Benoit [this message]
2011-06-06 15:28                         ` Cousson, Benoit
2011-06-07  6:52                         ` Tomi Valkeinen
2011-06-07  6:52                           ` Tomi Valkeinen
2011-06-07  9:08                           ` Tomi Valkeinen
2011-06-07  9:08                             ` Tomi Valkeinen
2011-06-07 11:37                           ` Cousson, Benoit
2011-06-07 11:37                             ` Cousson, Benoit
2011-06-07 11:51                             ` Tomi Valkeinen
2011-06-07 11:51                               ` Tomi Valkeinen
2011-06-07 16:43                               ` Cousson, Benoit
2011-06-07 16:43                                 ` Cousson, Benoit
2011-06-08  7:55                                 ` Tomi Valkeinen
2011-06-08  7:55                                   ` Tomi Valkeinen
2011-06-08 20:39                                   ` Cousson, Benoit
2011-06-08 20:39                                     ` Cousson, Benoit
2011-06-07  6:47             ` Tomi Valkeinen
2011-06-07  6:47               ` Tomi Valkeinen
2011-06-07  7:12               ` Cousson, Benoit
2011-06-07  7:12                 ` Cousson, Benoit
2011-06-07  7:21                 ` Tomi Valkeinen
2011-06-07  7:21                   ` Tomi Valkeinen
2011-06-07  7:27                   ` Cousson, Benoit
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   ` Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 21/27] OMAP: DSS2: Remove unused opt_clock_available Tomi Valkeinen
2011-06-03 10:00   ` 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   ` 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   ` 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   ` Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 25/27] OMAP4: CLKDEV: Remove omapdss clock aliases Tomi Valkeinen
2011-06-03 10:00   ` Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 26/27] OMAP: DSS2: DISPC: Fix context save/restore Tomi Valkeinen
2011-06-03 10:00   ` Tomi Valkeinen
2011-06-03 10:00 ` [PATCH 27/27] OMAP: DSS2: DSS: " Tomi Valkeinen
2011-06-03 10:00   ` 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 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.