Re: [PATCH 2/2] OMAPDSS: Ensure OPP100 when DSS is operational

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

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

Ping.

 Tomi

On Wed, 2012-03-14 at 08:38 +0200, Tomi Valkeinen wrote:
> On Tue, 2012-03-13 at 11:37 -0700, Kevin Hilman wrote:
> > Hi Tomi,
> > 
> > Tomi Valkeinen <tomi.valkeinen@ti.com> writes:
> > 
> > > Hi Kevin, Paul,
> > >
> > > I know you're busy, but I'd appreciate a comment/ack on these two small
> > > patches, so I could get them in to next merge window. Otherwise using
> > > any other OPP than OPP100 will most likely break the DSS.
> > >
> > > This looks quite straightforward fix for me, but I'm not sure if there
> > > could be any side effects.
> > 
> > How does it affect OMAP3?  OPP50/OPP100 names are specific to OMAP4.
> 
> They are? At least 3630 TRM speaks of them in the DSS chapter.
> 
> > Also, Can you help us understand the exact nature of the constraint?
> 
> The TRM lists maximum clock rates for the DSS clocks. You should be able
> to find them by searching "OPP100" in the DSS chapter. In my TRMs there
> are:
> 
> OMAP3630: Table 7-19. Display Subsystem Clocks
> OMAP4430: Table 10-4. DSS Clock Frequencies
> 
> > It sounds to me like it acutally is a throughput constraint on CORE.  If
> > so, wouldn't it be clearer to set a throughput constraint that is
> > calculated based on the pixel clock and resulting bitrate that would
> > have the same effect?
> 
> I don't see that these limits would have anything to do with CORE. I'm
> guessing that the DSS HW just can't function properly with high clocks
> and low voltage.
> 
> Making a constraint for the throughput is another matter, which should
> be also fixed at some point. So in the future I hope we'll have PM
> constraints coming from two sources: 1) a calculation based on the
> memory throughput needs 2) the minimum clock rates.
> 
> But both of those are non-trivial to code, so this patch aims to keep
> DSS working until those are implemented. Also, in practice, it's quite
> rare that the DSS clocks would all be below the limits in the tables.
> That could only happen with a fixed, known configuration with rather
> small displays.
> 
>  Tomi
> 
> 


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