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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
