Re: [PATCH 19/27] OMAP: DSS2: Use PM runtime & HWMOD support

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

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?

This way when your long-term solution is done, the driver would not need
any changes.

 Tomi