Re: [PATCH] OMAP4: Extend clock data.

["Cousson, Benoit" <b-cousson@ti.com>]

Hi Thara,

Here is the full email...

On 9/30/2010 10:57 AM, Paul Walmsley wrote:
> Hello Thara,
>
> On Thu, 30 Sep 2010, Thara Gopinath wrote:
>
>> This patch extends the OMAP4 clock data to include
>> various x2 clock nodes as the clock framework
>> skips a *2 whie calculating the dpll locked frequency.
>>
>> Signed-off-by: Thara Gopinath<thara@ti.com>
>> Acked-by: Kevin Hilman<khilman@deeprootsystems.com>
>> ---
>> Currently the framework is extended to include x2 nodes
>> only for a few clocks critical for OMAP4 DVFS. This
>> exercise needs to be done for most of the other post divider
>> clocks as and when necessary.
>
> Benoît and I have been discussing this - I think we should probably fix
> this problem for all of the DPLLs and HSDIVIDERs in one patch.  I'll let
> Benoît comment further, but I think the current plan will be to generate a
> CLKOUTX2 node after the DPLLs, and then to use that as the parent for
> the various HSDIVIDERs that use that X2 output.

Here is the way it should look for my point of view in order to be 
closer to the HW implementation:

                              +-> /2 -> M2
                              |
                    +-> M2x2 -+------->
                    |	
  DPLL ---> DPLLx2 -+-----------------> M3 (should be M3x2)
                    |
                    +-----------------> M4 (should be M4x2)
                    |
                    +-----------------> M5 (should be M5x2)
                    |
                    +-----------------> M6 (should be M6x2)
                    |
                    +-----------------> M7 (should be M7x2)


All DPLL, except the USB one, will use the same pattern. Only the number 
of HS dividers will change.

For information, here is an extract from the ES1 DB. The HS name is
indeed not very consistent.
There is no x2 in the HS dividers name whereas it should.

      'dpll_abe': {
          'outputs': {
              'm2': 'dpll_abe_m2',
              'm2x2': 'dpll_abe_m2x2',
              'm3': 'dpll_abe_m3'},
      'dpll_core': {
          'outputs': {
              'm2': 'dpll_core_m2',
              'm3': 'dpll_core_m3',
              'm4': 'dpll_core_m4',
              'm5': 'dpll_core_m5',
              'm6': 'dpll_core_m6',
              'm7': 'dpll_core_m7'},
      'dpll_iva': {
          'outputs': {
              'm4': 'dpll_iva_m4',
              'm5': 'dpll_iva_m5'},
      'dpll_mpu': {
          'outputs': {
              'm2': 'dpll_mpu_m2'},
      'dpll_per': {
          'outputs': {
              'm2': 'dpll_per_m2',
              'm2x2': 'dpll_per_m2x2',
              'm3': 'dpll_per_m3',
              'm4': 'dpll_per_m4',
              'm5': 'dpll_per_m5',
              'm6': 'dpll_per_m6',
              'm7': 'dpll_per_m7'},
      'dpll_unipro': {
          'outputs': {
              'm2x2': 'dpll_unipro_m2x2'},
      'dpll_usb': {
          'outputs': {
              'clkdcoldo': 'dpll_usb_clkdcoldo',
              'm2': 'dpll_usb_m2'},


So we should probably rename all the m3..m7 with m3x2..m7x2 name.

> Also, I think we should make this change in a consistent way with regards
> to what the autogeneration scripts should generate.  This way, we won't
> have to redo it later and cause unnecessary patch noise.
>
> Perhaps you can help Benoît update the autogeneration scripts for the
> above changes?

You can ask Rajendra if you need some detail about the tools.

Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html