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: 2782 bytes --]

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?

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?

 Tomi


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