diff options
author | Paul Walmsley <paul@pwsan.com> | 2010-02-22 22:09:12 -0700 |
---|---|---|
committer | Paul Walmsley <paul@pwsan.com> | 2010-02-24 12:15:03 -0700 |
commit | 93340a22943f3169de7d359ea14cd618114da6f6 (patch) | |
tree | e9736b9fb4e9f2fdd31491b2b7a5b3dfe60ed453 /arch/arm/mach-shark/leds.c | |
parent | 7356f0b26b3176610b4de439e8c7bfe10c797347 (diff) |
OMAP2/3/4 clock: fix DPLL multiplier value errors; also copyrights, includes, documentation
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 <linux/module.h> with <linux/list.h>, which is what was really
needed. The OMAP4 clock autogenerator script has been updated
accordingly.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: BenoƮt Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Diffstat (limited to 'arch/arm/mach-shark/leds.c')
0 files changed, 0 insertions, 0 deletions