Re: [PATCH 09/21] OMAPDSS: DISPC: Calculate scaling limits in a more generic way

[Archit Taneja <a0393947@ti.com>]

On Friday 14 September 2012 03:19 PM, Tomi Valkeinen wrote:
> On Fri, 2012-09-14 at 14:43 +0530, Archit Taneja wrote:
>> On Friday 14 September 2012 02:23 PM, Tomi Valkeinen wrote:
>>> On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote:
>>>> Scaling calculations for an overlay are done by comparing pixel clock of the
>>>> connected overlay manager and the core clock of DISPC. The pixel clock is the
>>>> output rate of the scalar. The scalar block needs to provide pixels at this rate
>>>> since the manager is connected to a panel, which has real time constraints.
>>>>
>>>> In the case of writeback in memory to memory mode, the output of the scalar
>>>> blocks aren't connected to a display, and hence there isn't a pixel clock which
>>>> causes downscaling limitations.
>>>>
>>>> Make the input to scaling calculations a bit more generic by passing the scalar
>>>> output rate rather than passing pixel clock of the overlay manager connected to
>>>> the pipeline, as we now have use cases where the scalar's output may not go to
>>>> a manager connected to a panel.
>>>
>>> Pixel clock is the rate at which pixels are processed. I don't see it
>>> only meaning a clock that's related to actual video signal going out of
>>> OMAP. So if in normal case the scaler outputs pixels at the rate of
>>> pixel clock, we can call it pixel clock with WB's case also, instead of
>>> renaming it to output clock.
>>
>> Pixel clock, in OMAP DSS terms, is the rate at which the video port of
>> an overlay manager provides pixels to an output. It is a fixed rate at
>> which the scaler needs to push out data.
>>
>> If we stick to this terminology of pixel clock, I don't think it applies
>> to writeback. As far as I see it, there is no specific rate at which the
>> scaler outputs data, it adjusts itself based on how much scaling is
>> done, and at the rate we can get/push data to the interconnect. That's
>> why I didn't want to call it pixel clock. Because, that sounds a lot
>> like a fixed rate at which pixels need to be output.
>
> I see your reasoning. I'm a bit reluctant to add a new clock term to
> omapdss. You can't (probably) find it in the TRM. Does the TRM talk
> about clocks with regard to WB?

Yes, you can't find the word pixel clock linked to WB in the TRM.

>
> I do think pixel clock can be used as well here. While normally used for
> output, it's just a clock used for pixels, and at each tick we process
> one pixel, which is exactly what happens with WB also.
>
> Also, if I understood right, this pixel clock is not even used for WB,
> and in a later patch you just use a dummy value of 1 for the clock for
> WB. So even if pixel clock would not be the best name, would it make
> sense to use the name of pixel clock, but return 0 as the pck for WB,
> implying that pck is not valid/does not exist, and the scaling
> restrictions can be skipped for that?

Yes, we could do that. I can check if zero leads to some bad results, or 
we could just bypass the scaler clock stuff if the pixel clock is 0.

Archit