RE: [Query] OMAP: DSS2: Margin for downscaling in clock calculations

RE: [Query] OMAP: DSS2: Margin for downscaling in clock calculations

[Taneja, Archit]

Hi,

I was going through the DSS2 code which sets up the FCLK
coming from PRCM and the DISPC divivors to get the required pixel
clock. 
 
The function dss_calc_clock_div() does a brute force search across
all possible values of: a) DPLL divisor whose output goes to DSS, b)
DISPC_DIVISOR.LCD, c) DISPC_DIVISOR.pcd

The combination which gives a clock frequency closest to the
required pixel clock is chosen.

Hence, it seems that the resultant DISPC_FCLK clock frequency doesn't
take into account the extra margin needed for downscaling:

Req dispc_fclk >= pck * hscale_ratio * vscale_ration * K

Do you thing putting a further constraint (like DISPC_FCLK needs to be
greater than a given value) should be a part of the calculations to
ensure successful scaling?

Regards,
Archit

RE: [Query] OMAP: DSS2: Margin for downscaling in clock calculations

[Tomi Valkeinen]

On Tue, 2011-01-18 at 10:45 +0530, ext Taneja, Archit wrote:
> Hi,
> 
> I was going through the DSS2 code which sets up the FCLK
> coming from PRCM and the DISPC divivors to get the required pixel
> clock. 
>  
> The function dss_calc_clock_div() does a brute force search across
> all possible values of: a) DPLL divisor whose output goes to DSS, b)
> DISPC_DIVISOR.LCD, c) DISPC_DIVISOR.pcd
> 
> The combination which gives a clock frequency closest to the
> required pixel clock is chosen.
> 
> Hence, it seems that the resultant DISPC_FCLK clock frequency doesn't
> take into account the extra margin needed for downscaling:
> 
> Req dispc_fclk >= pck * hscale_ratio * vscale_ration * K
> 
> Do you thing putting a further constraint (like DISPC_FCLK needs to be
> greater than a given value) should be a part of the calculations to
> ensure successful scaling?

It's been a while since I looked at the fclk requirements, but isn't the
current CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK enough? It is quite hackish and
static, but a proper implementation is much harder (dynamically changing
the clocks depending on the scaling).

Or were there some additional restrictions?

 Tomi

RE: [Query] OMAP: DSS2: Margin for downscaling in clock calculations

[Taneja, Archit]

Hi,

Tomi Valkeinen wrote:
> On Tue, 2011-01-18 at 10:45 +0530, ext Taneja, Archit wrote:
>> Hi,
>> 
>> I was going through the DSS2 code which sets up the FCLK coming
>> from PRCM and the DISPC divivors to get the required pixel clock.
>> 
>> The function dss_calc_clock_div() does a brute force search across
>> all possible values of: a) DPLL divisor whose output goes to DSS,
>> b) DISPC_DIVISOR.LCD, c) DISPC_DIVISOR.pcd
>> 
>> The combination which gives a clock frequency closest to the
>> required pixel clock is chosen. 
>> 
>> Hence, it seems that the resultant DISPC_FCLK clock frequency
>> doesn't take into account the extra margin needed for downscaling:
>> 
>> Req dispc_fclk >= pck * hscale_ratio * vscale_ration * K
>> 
>> Do you thing putting a further constraint (like DISPC_FCLK needs
>> to be greater than a given value) should be a part of the
>> calculations to ensure successful scaling?
> 
> It's been a while since I looked at the fclk requirements,
> but isn't the current CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK
> enough? It is quite hackish and static, but a proper
> implementation is much harder (dynamically changing the
> clocks depending on the scaling).
> 

I think I ignored this part of the code :), I suppose this should be good
enough for most cases.

I was wondering why we can't try to get the DSS_FCLK always at the max
clock supported? Which is 173 Mhz on omap2/3.

Is it because we won't get a close enough pck with the lcd, pcd divisor
combinations or is it needed to save power?

If we stick to 173 Mhz(or something close to it) we could provide the best
possible downscaling(which may need dispc_fck as much as 8 times the pixel clock)

Consider 2 hypothetical divisor combinations for a desired pixel clock:

a)DISPC_FCLK=120Mhz, delta between calculated pck and desired pck ~ 1%
b)DISPC_FCLK=160Mhz, delta between calculated pck and desired pck ~ 2%

Wouldn't it be better to go with option (b) since it gives me something close
to a desired pixel clock and also ensures better downscaling?

Using CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK may or may not let me arrive at(b), since
it will ensure jumps at discrete multiples of pck.

I am not totally sure if I make much sense, but would appreciate comments anyway :)

Archit


> Or were there some additional restrictions?
> 
>  Tomi

RE: [Query] OMAP: DSS2: Margin for downscaling in clock calculations

[Tomi Valkeinen]

On Wed, 2011-01-19 at 02:39 +0530, ext Taneja, Archit wrote:
> Hi,
> 
> Tomi Valkeinen wrote:
> > On Tue, 2011-01-18 at 10:45 +0530, ext Taneja, Archit wrote:
> >> Hi,
> >> 
> >> I was going through the DSS2 code which sets up the FCLK coming
> >> from PRCM and the DISPC divivors to get the required pixel clock.
> >> 
> >> The function dss_calc_clock_div() does a brute force search across
> >> all possible values of: a) DPLL divisor whose output goes to DSS,
> >> b) DISPC_DIVISOR.LCD, c) DISPC_DIVISOR.pcd
> >> 
> >> The combination which gives a clock frequency closest to the
> >> required pixel clock is chosen. 
> >> 
> >> Hence, it seems that the resultant DISPC_FCLK clock frequency
> >> doesn't take into account the extra margin needed for downscaling:
> >> 
> >> Req dispc_fclk >= pck * hscale_ratio * vscale_ration * K
> >> 
> >> Do you thing putting a further constraint (like DISPC_FCLK needs
> >> to be greater than a given value) should be a part of the
> >> calculations to ensure successful scaling?
> > 
> > It's been a while since I looked at the fclk requirements,
> > but isn't the current CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK
> > enough? It is quite hackish and static, but a proper
> > implementation is much harder (dynamically changing the
> > clocks depending on the scaling).
> > 
> 
> I think I ignored this part of the code :), I suppose this should be good
> enough for most cases.
> 
> I was wondering why we can't try to get the DSS_FCLK always at the max
> clock supported? Which is 173 Mhz on omap2/3.
> 
> Is it because we won't get a close enough pck with the lcd, pcd divisor
> combinations or is it needed to save power?

Main reason has been power saving. I don't know how much changing the
clock itself affects, but then there are things like the lowest OPP is
only possible when DSS_FCLK is lower than 96MHz (or someting like that,
can't remember), and that may have a bigger impact.

> If we stick to 173 Mhz(or something close to it) we could provide the best
> possible downscaling(which may need dispc_fck as much as 8 times the pixel clock)
> 
> Consider 2 hypothetical divisor combinations for a desired pixel clock:
> 
> a)DISPC_FCLK=120Mhz, delta between calculated pck and desired pck ~ 1%
> b)DISPC_FCLK=160Mhz, delta between calculated pck and desired pck ~ 2%
> 
> Wouldn't it be better to go with option (b) since it gives me something close
> to a desired pixel clock and also ensures better downscaling?

It's difficult to say. I have to say I have no idea how picky panels are
with the pixels clocks. If your panel works with option a but not with
b, then obviously a is a better choice =).

> Using CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK may or may not let me arrive at(b), since
> it will ensure jumps at discrete multiples of pck.
> 
> I am not totally sure if I make much sense, but would appreciate comments anyway :)

While I think it's very important to somehow be able to get whatever
clock settings one's particular use case requires, and for many cases it
may be important to get the FCLK as low as possible, perhaps there's a
point in what you say.

We could have some kind of "non-power-saving-mode", in which DSS doesn't
aim to aim for low clock, but to give best performance and scaling. This
would probably be fine for cases where your board is powered from a wall
supply, and you are not concerned about a few milliamps.

But then again, that would still be a bit hacky. What we should have is
a dynamically changed clock depending on the clock requirements. But
that's a bit tricky...

 Tomi