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,
next prev parent 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: linkBe 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.