Re: [PATCH] OMAP4: Extend clock data.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxx>
Acked-by: Kevin Hilman<khilman@xxxxxxxxxxxxxxxxxxx>
---
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux