Eric Lee / smarc-fsl-linux-kernel

25 Feb, 2010

2 commits

  • 657ebfadc   OMAP3/4 clock: split into per-chip family files ... Browse Code »

    clock34xx_data.c now contains data for the OMAP34xx family, the
    OMAP36xx family, and the OMAP3517 family, so rename it to
    clock3xxx_data.c. Rename clock34xx.c to clock3xxx.c, and move the
    chip family-specific clock functions to clock34xx.c, clock36xx.c, or
    clock3517.c, as appropriate. So now "clock3xxx.*" refers to the OMAP3
    superset.

    The main goal here is to prepare to compile chip family-specific clock
    functions only for kernel builds that target that chip family. To get to
    that point, we also need to add CONFIG_SOC_* options for those other
    chip families; that will be done in future patches, planned for 2.6.35.

    OMAP4 is also affected by this. It duplicated the OMAP3 non-CORE DPLL
    clkops structure. The OMAP4 variant of this clkops structure has been
    removed, and since there was nothing else currently in clock44xx.c, it
    too has been removed -- it can always be added back later when there
    is some content for it. (The OMAP4 clock autogeneration scripts have been
    updated accordingly.)

    Signed-off-by: Paul Walmsley
    Cc: Benoît Cousson
    Cc: Rajendra Nayak
    Cc: Ranjith Lohithakshan
    Cc: Tony Lindgren

    Paul Walmsley
     
  • 93340a229   OMAP2/3/4 clock: fix DPLL multiplier value errors; also copyrights, includes, documentation ... Browse Code »

    The maximum DPLL multiplier (M) values for OMAP2xxx and OMAP3xxx are
    one increment higher than they should be. See for example the
    OMAP242x TRM Rev X Section 5.10.6 "Clock Generator Registers" and the
    OMAP36xx TRM Rev C Table 3-202 "CM_CLKSEL1_PLL". Programming a 0 into
    the DPLL's M register bitfield is valid for OMAP2/3 and indicates that
    the DPLL should enter MN-bypass mode. Also, increase the minimum
    multiplier (M) value for the DPLL rate rounding code from 1 to 2, to
    ensure that it does not inadvertently put the DPLL into bypass.

    Note that the register documentation in the OMAP2xxx and OMAP3xxx TRMs
    does not make clear that the actual DPLL divider value (the "N") is
    the content of the appropriate register bitfield for the N value,
    _plus one_. (In other words, an N register bitfield of 0 indicates a
    DPLL divider value of 1.) This is only clearly documented in the
    OMAP4430 TRM, in, for example, OMAP4430 TRM Rev A Table 3-1167
    "CM_CLKSEL_DPLL_USB".

    While here, update copyrights, add kerneldoc for struct dpll_data,
    drop the unused struct dpll_data.max_tolerance field, remove some
    unnecessary #includes in DPLL-related code, and replace the #include
    of with , which is what was really
    needed. The OMAP4 clock autogenerator script has been updated
    accordingly.

    Signed-off-by: Paul Walmsley
    Cc: Benoît Cousson
    Cc: Rajendra Nayak

    Paul Walmsley
     

16 Feb, 2010

1 commit

30 Jan, 2010

1 commit

  • e80a9729b   OMAP2/3/4 clock: rename and clean the omap2_clk_init() functions ... Browse Code »

    Rename the omap2_clk_init() in the OMAP2, 3, and 4 clock code to be
    omap2xxx_clk_init(), omap3xxx_clk_init(), etc. Remove all traces of
    the (commented) old virt_prcm_set code from omap3xxx_clk_init() and
    omap4xxx_clk_init(), since this will be handled with the OPP code that
    is cooking in the PM branch.

    After this patch, there should be very little else in the clock code
    that blocks a multi-OMAP 2+3 kernel. (OMAP2420+OMAP2430 still has some
    outstanding issues that need to be resolved; this is pending on some
    additions to the hwmod data.)

    Signed-off-by: Paul Walmsley

    Paul Walmsley
     

12 Dec, 2009

2 commits