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