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
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
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
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
On Fri, 2012-09-14 at 15:33 +0530, Archit Taneja wrote:
On Friday 14 September 2012 03:19 PM, Tomi Valkeinen wrote:
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?
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
