> Richard is really the best person to ask about this, so he's been added
> to
> the cc. My current understanding is below. Perhaps he can respond with
> more detail and correct any errors.
>
> In terms of original motivation, you might want to look at 34xx TRM
> 4.12.2.4.3. I don't think this actually works in practice on OMAP3.
See other mail response.
Paul hit some major points.
We do target auto handling on I-Clocks for active use cases. We depend on it to hit our given power targets for things like MP3. You can't handle in software all I clocks and even get close. All drivers have to be just so to make it work. Having individual control makes it possible especially for ones which are bugged in some fashion (hw or software).
Moving to some combined clock for the general case and having specific control of others seems like a good future goal.
Back in omap2 time the hardware designers did indicate they added all this flexibility as a way to compensate for possible design errors. This was a correct and needed a lot in omap2 and somewhat in omap3 to meet aggressive power targets. Our feed back at the time was that’s all fine, but it would have better to have a standard 'simple' interface which could be bypassed for direct usage if bugs/flexibility were needed. All the variables which exist can be confusing with out a lot of explaining.
Regards,
Richard W.
��.n��������+%������w��{.n�����{�������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
