On Friday 24 August 2012 02:25 PM, Tomi Valkeinen wrote:
On Fri, 2012-08-24 at 11:46 +0530, Archit Taneja wrote:
On Thursday 23 August 2012 07:15 PM, Tomi Valkeinen wrote:
+ /* pck = TxByteClkHS * datalanes * 8 / bitsperpixel */
This formula looks a bit simplified, we aren't considering the header
and footers of long packets that will add to the DDR clock. But I guess
not considering these would only give a higher pixel clock than needed,
which isn't that bad.
Hmm. The TRM (omap4460) gives this formula in "10.3.4.5.12 How to
Configure the DSI PLL in Video Mode". The headers/footers etc. are
handled with adjusting the blanking periods so that DISPC and DSI Tline
times match.
But obviously they are not used for command mode transfers, so perhaps
you have a point there. Then again, at least in theory, in command mode
the DISPC pck should be configurable as high as possible because the
stall mechanism should stop DISPC when DSI has had enough. And so the
pck calculation is a bit unneeded for cmd mode, we could just configure
pck to max.
But if it's correct for video mode, and very close for cmd mode, I guess
it should be fine?
Yes, it's fine, and we shouldn't try to have an unnecessarily high pixel
clock in command mode anyway, that would reduce the amount of
downscaling we could do.
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
