linux-fbdev.vger.kernel.org archive mirror
 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,

  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).