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?
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 pixe
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 an
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
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
> rat
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
