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

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

[-- Attachment #1: Type: text/plain, Size: 1263 bytes --]

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.

Or was there some other reason for the rename, that I missed?

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]