Adds a way for clock consumers to set maximum and minimum rates. This
can be used for thermal drivers to set minimum rates, or by misc.
drivers to set maximum rates to assure a minimum performance level.
Changes the signature of the determine_rate callback by adding the
parameters min_rate and max_rate.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
[sboyd@codeaurora.org: set req_rate in __clk_init]
Signed-off-by: Michael Turquette <mturquette@linaro.org>
[mturquette@linaro.org: min/max rate for sun6i_ahb1_clk_determine_rate
migrated clk-private.h changes to clk.c]
Moves clock state to struct clk_core, but takes care to change as little API as
possible.
struct clk_hw still has a pointer to a struct clk, which is the
implementation's per-user clk instance, for backwards compatibility.
The struct clk that clk_get_parent() returns isn't owned by the caller, but by
the clock implementation, so the former shouldn't call clk_put() on it.
Because some boards in mach-omap2 still register clocks statically, their clock
registration had to be updated to take into account that the clock information
is stored in struct clk_core now.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
[mturquette@linaro.org: adapted clk_has_parent to struct clk_core
applied OMAP3+ DPLL fix from Tero & Tony]
While the change for determine_rate clock operation was merged,
the OMAP counterpart using these calls was overlooked for some reason,
and caused boot failures on at least OMAP4 platforms. Fixed by updating
the DPLL API calls to use the new parameters.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Fixes: 646cafc6aa ("clk: Change clk_ops->determine_rate")
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Kevin Hilman <khilman@linaro.org>
Reported-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
Currently, DPLLs are hiding the gory details of switching parent
within set_rate, which confuses the common clock code and is wrong.
Fixed by applying the new determine_rate() and set_rate_and_parent()
functionality to any clock-ops previously using the broken approach.
This patch also removes the broken legacy code.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Currently, DPLL code hides the re-parenting within its internals, which
is wrong. This needs to be exposed to the common clock code via
determine_rate and set_rate_and_parent APIs. This patch adds support
for these, which will be taken into use in the following patches.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
or the next one below it. This is intended to resolve some DSS problems.
Basic build, boot, and PM test results are available here:
http://www.pwsan.com/omap/testlogs/clock-b-v3.17/20140725061121/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJT0lK2AAoJEMePsQ0LvSpLUkEQAKpqkh9UYUixXBaeIQnoFcwH
uW7/cjYPfTY1ogFgMaFJN14cTmat+Xm97Es8hgEIZYyY5OmRNYqcdBXmfQ5Mls8b
mtxZu9FAPRfFZkfNst7Y1i969GoyTnOyOG3Ea7PlAzQacnjq7HVACLMKIDEOmGhG
rzDSj1eFaJWTUdY0yGFQAkwd5LvuNIfuXIwQ9DlHm84/tpKEpi32tmRJBPzLaKz1
Cu88ZiW1pfMR8BRw247wlJ9v2DJmhnrluhKhM6UFGJR6X31kw/s7wqbTi3+yNXqL
BToTQs1xVwMnnOAntM7sc39UFg3pgZBqWFemQCHtshGqhgo1MJ8nznIvxyPXAcAp
cLHMxMdBbs4Ds9vbJKTNVzntoam8PGO8mff0wMePqAPAuE/m/JMxBTPc5vZijI7f
SmjirUEhK47BEtUBRQNTVX/B1ABvmodaU93ous8gbKagjH358DkrIlCwP2rerJWc
eg9UxYNNRvK0iUsjl19vfr/qfT7vXnkp3YGfkJlR22KBJOQd1+M3X/NIBrU0fV2e
00H9O2YdScBGzFMLvbnT0LkH4/VgilR3667Kx6LkK/r62LrG1z296kTpnfwLtivH
1jfmhMyt1MfgOylPx/5Dh39xKqUqKeUVoBCFUr/45y3nFbEFZkILiNEuPzRNFUPK
AgSz5lyNGFfd4mb144hM
=fXvM
-----END PGP SIGNATURE-----
Merge tag 'for-v3.17/omap-clock-b' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.17/soc
Modify OMAP PLL rate rounding function to round to the exact rate requested
or the next one below it. This is intended to resolve some DSS problems.
Basic build, boot, and PM test results are available here:
http://www.pwsan.com/omap/testlogs/clock-b-v3.17/20140725061121/
Change the behavior of omap2_dpll_round_rate() to round to either the
exact rate requested, or the next lowest rate that the clock is able to
provide.
This is not an ideal fix, but is intended to provide a relatively safe
way for drivers to set PLL rates, until a better solution can be
implemented.
For the time being, omap3_noncore_dpll_set_rate() is still allowed to
set its rate to something other than what the caller requested; but will
warn when this occurs.
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Mike Turquette <mturquette@linaro.org>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Some of the machine specific header includes are no longer used, so remove
these from the source file. This allows migration of the file under clock
driver.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Mike Turquette <mturquette@linaro.org>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Currently DPLL code uses runtime cpu_is_343x checks to see if the DPLL
has freqsel fields in its control register or not. Instead, add a new
flag to the clk_features.flags and use this during runtime. Allows
eventual move of the DPLL code under clock driver.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Mike Turquette <mturquette@linaro.org>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Duty Cycle Correction(DCC) needs to be enabled if the MPU is to run at
frequencies beyond 1.4GHz for OMAP5, DRA75x, DRA72x.
MPU DPLL has a limitation on the maximum frequency it can be locked
at. Duty Cycle Correction circuit is used to recover a correct duty
cycle for achieving higher frequencies (hardware internally switches
output to M3 output(CLKOUTHIF) from M2 output (CLKOUT)).
For further information, See the note on OMAP5432 Technical Reference
Manual(SWPU282U) chapter 3.6.3.3.1 "DPLLs Output Clocks Parameters",
and also the "OMAP543x ES2.0 DM Operating Conditions Addendum v0.5"
chapter 2.1 "Micro Processor Unit (MPU)". Equivalent information is
present in relevant DRA75x, 72x documentation(SPRUHP2E, SPRUHI2P).
Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>
Signed-off-by: Taras Kondratiuk <taras@ti.com>
Signed-off-by: J Keerthy <j-keerthy@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
[t-kristo@ti.com: added TRM / DM references for DCC clock rate]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Lots of changes specific to one of the SoC families. Some that
stick out are:
* mach-qcom gains new features, most importantly SMP support for
the newer chips (Stephen Boyd, Rohit Vaswani)
* mvebu gains support for three new SoCs: Armada 375, 380 and 385
(Thomas Petazzoni and Free-electrons team)
* SMP support for Rockchips (Heiko Stübner)
* Lots of i.MX changes (Shawn Guo)
* Added support for BCM5301x SoC (Hauke Mehrtens)
* Multiplatform support for Marvell Kirkwood and Dove
(Andrew Lunn and Sebastian Hesselbarth doing the final part
of a long journey)
* Unify davinci platforms and remove obsolete ones (Sekhar Nori,
Arnd Bergmann)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIVAwUAUz/yT2CrR//JCVInAQJN8A/9Ft1rfp4LEe8Lpr9yAZydG4UaJKy8Hh7Z
fmohMAuy88J+8jzdwQKKCeEiId+nIf+WmFIQDn9YRDev1/T2v32Ax49XuGtY47JX
4loIC2wR0+j1aSwhEVOmlM03lX7Hbu6iNDkxaLkDKTRrt3DhDNA6cPZYwNOT273W
Yx7hIDpvsoOVN3zbPwqhwLrXgywsaNB9E7ly1GixRd1thdg46kMRcM0LJSXPH3we
pyx7sZbILTVMeUx79XUTvBDJYsbjJWFZknVDYXGkrS5YxAASVsVW2KW9fP9E+UXE
wTmOxg6spsHGgCezwy8NL5UmfaAOXL3mm6ginFwWpyz7Iu+P5IvfR1W+8UA/O8tp
K9y8wLA64chPQJkAGaPQBqUPq9QkNHodZWgaPKxKuuv3qF481DCnQKkFRz+sl7mu
oQVGnoMCnTY6L6yYcIq/GpgiJ731vwefirAwPR8FEBN/gw/gC01b+DDchx/5inPJ
6V6dCEtPZxXMOsIaYBWFauk3pMFU3E8coklmteyYDQg7eb+55Zq3vsNEpu/vb6ll
M660AQzzbkZ7lgsSBdNODEvkNH15kC35G2UCfwy99uCE4k/0Vi7reJ1BzXkc+dtJ
+maBtA6NMALXQ/EI+B+fZLccI4Hv7avwFy1rQJaf+TLiFvTd9yp0qUX8JjXWDPgu
pPWQOC4a9mU=
=AGpV
-----END PGP SIGNATURE-----
Merge tag 'soc-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC specific changes from Arnd Bergmann:
"Lots of changes specific to one of the SoC families. Some that stick
out are:
- mach-qcom gains new features, most importantly SMP support for the
newer chips (Stephen Boyd, Rohit Vaswani)
- mvebu gains support for three new SoCs: Armada 375, 380 and 385
(Thomas Petazzoni and Free-electrons team)
- SMP support for Rockchips (Heiko Stübner)
- Lots of i.MX changes (Shawn Guo)
- Added support for BCM5301x SoC (Hauke Mehrtens)
- Multiplatform support for Marvell Kirkwood and Dove (Andrew Lunn
and Sebastian Hesselbarth doing the final part of a long journey)
- Unify davinci platforms and remove obsolete ones (Sekhar Nori, Arnd
Bergmann)"
* tag 'soc-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (126 commits)
ARM: sunxi: Select HAVE_ARM_ARCH_TIMER
ARM: cache-tauros2: remove ARMv6 code
ARM: mvebu: don't select CONFIG_NEON
ARM: davinci: fix DT booting with default defconfig
ARM: configs: bcm_defconfig: enable bcm590xx regulator support
ARM: davinci: remove tnetv107x support
MAINTAINERS: Update ARM STi maintainers
ARM: restrict BCM_KONA_UART to ARCH_BCM_MOBILE
ARM: bcm21664: Add board support.
ARM: sunxi: Add the new watchog compatibles to the reboot code
ARM: enable ARM_HAS_SG_CHAIN for multiplatform
ARM: davinci: remove da8xx_omapl_defconfig
ARM: davinci: da8xx: fix multiple watchdog device registration
ARM: davinci: add da8xx specific configs to davinci_all_defconfig
ARM: davinci: enable da8xx build concurrently with older devices
ARM: BCM5301X: workaround suppress fault
ARM: BCM5301X: add early debugging support
ARM: BCM5301X: initial support for the BCM5301X/BCM470X SoCs with ARM CPU
ARM: mach-bcm: Remove GENERIC_TIME
ARM: shmobile: APMU: Fix warnings due to improper printk formats
...
omap3_noncore_dpll_set_rate forces a reparent to the same clk_ref
for every call that takes place. This is an can be done only if a change
is detected.
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
If CLK_SET_RATE_PARENT is set for a clkoutx2 clock, calling
clk_set_rate() on the clock "skips" the x2 multiplier as there are no
set_rate and round_rate functions defined for the clkoutx2.
This results in getting double the requested clock rates, breaking the
display on omap3430 based devices. This got broken when
d0f58bd3bb and related patches were merged
for v3.14, as omapdss driver now relies more on the clk-framework and
CLK_SET_RATE_PARENT.
This patch implements set_rate and round_rate for clkoutx2.
Tested on OMAP3430, OMAP3630, OMAP4460.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Clock nodes shall use the services provided by underlying drivers to access
the hardware registers instead of direct memory read/write. Thus, change
all the code to use the new omap2_clk_readl / omap2_clk_writel APIs for this.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
omap3_noncore_dpll_set_rate() attempts an enable of bypass clk as well
as ref clk for every .set_rate attempt on a noncore DPLL, regardless of
whether the .set_rate results in the DPLL being locked or put in bypass.
Early at boot, while some of these DPLLs are programmed and locked
(using .set_rate for the DPLL), this causes an ordering issue.
For instance, on OMAP5, the USB DPLL derives its bypass clk from ABE DPLL.
If a .set_rate of USB DPLL which programmes the M,N and locks it is called
before the one for ABE, the enable of USB bypass clk (derived from ABE DPLL)
then attempts to lock the ABE DPLL and fails as the M,N values for ABE
are yet to be programmed.
To get rid of this ordering needs, enable bypass clk for a DPLL as part
of its .set_rate only when its being put in bypass, and only enable the
ref clk when its locked.
Reported-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
OMAP5 does not have freqsel either, so checks needs to be extended.
Infact only OMAP343X devices has the freqsel support, so fix the check
accordingly so that future patching can be avoided.
Reported-by: Archit Taneja <archit@ti.com>
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
From Tony Lindgren:
Here are few more patches to finish the omap changes for
multiplatform conversion that are not strictly fixes, but
were too complex to do with the dependencies during the
merge window. Those are to move of serial-omap.h to
platform_data, and the removal of remaining cpu_is_omap
macro usage outside mach-omap2.
Then there are several trivial fixes for typos and few
minimal omap2plus_defconfig updates.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJQ3es9AAoJEIwa5zzehBx3bpwP/j4k4mGm4RMLTY9e8KNNxrDW
FAeU52h91qDONn3EXcF7oSd5IqbDoQRCQx9vn4XBfSm23uOzvP3hOSDe8iIz9t8C
XdLSXJfJDuYKuEBYxFNOVBdBziZoE7Gtp1JP9s79qfGfQurUfnRQ9gg6zoMMoxMg
KdVnzFbaCeN/Dgbyq/WToDdOCUv2jeiSNI0gf6oe3Tju0uVjBSmlZUnkbAsRMvOW
RL2uwp66yS6uLc/w5cfPI/wcp1jRZDYm2E7JB+TmHWqCYx2qpDE5EuDuW5+cY/DR
RTBr1c0fSl3k3o3iNOEijkFwGShivf1PksesMA+Fx9BrFwtrhtYT/dVZbuS3AjVL
1vIn3c+8rp3p63EsS1WxAMBvBq3qgqAl2shgow1B3QlXdErB9HNRErFKjU9rJ1ES
fZgtWkzLtCqFaN/WnQAj0nfooPmrmhaDrbHJd7Bt7g8dfgGBHl9nkmQ4tMAa/z4x
f/mZ0MxtXwhSUYBDvJ9vvtcNdeo9WmVV5zCfHUiMB7LB4wjxJUf7xMT9AquQUGqj
H5EkaSyRjWG35293WDmxAOKlAkMP+AH5cuROKNNwNN5+i7ypJC+jrMDcgwfwQoXl
i0yJeJhzFg9WV9buNB7+uWTA9vz7uveHSeaVXbbTVbuZ+apTgWl+MTsua0C2hhbU
81k7fmqW2fCWkiw5eUeZ
=RE6Z
-----END PGP SIGNATURE-----
Merge tag 'omap-late-cleanups' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull late ARM cleanups for omap from Olof Johansson:
"From Tony Lindgren:
Here are few more patches to finish the omap changes for multiplatform
conversion that are not strictly fixes, but were too complex to do
with the dependencies during the merge window. Those are to move of
serial-omap.h to platform_data, and the removal of remaining
cpu_is_omap macro usage outside mach-omap2.
Then there are several trivial fixes for typos and few minimal
omap2plus_defconfig updates."
* tag 'omap-late-cleanups' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
arch/arm/mach-omap2/dpll3xxx.c: drop if around WARN_ON
OMAP2: Fix a typo - replace regist with register.
ARM/omap: use module_platform_driver macro
ARM: OMAP2+: PMU: Remove unused header
ARM: OMAP4: remove duplicated include from omap_hwmod_44xx_data.c
ARM: OMAP2+: omap2plus_defconfig: enable twl4030 SoC audio
ARM: OMAP2+: omap2plus_defconfig: Add tps65217 support
ARM: OMAP2+: enable devtmpfs and devtmpfs automount
ARM: OMAP2+: omap_twl: Change TWL4030_MODULE_PM_RECEIVER to TWL_MODULE_PM_RECEIVER
ARM: OMAP2+: Drop plat/cpu.h for omap2plus
ARM: OMAP: Split fb.c to remove last remaining cpu_is_omap usage
MAINTAINERS: Add an entry for omap related .dts files
Just use WARN_ON rather than an if containing only WARN_ON(1).
A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression e;
@@
- if (e) WARN_ON(1);
+ WARN_ON(e);
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Tony Lindgren <tony@atomide.com>
On OMAP4 devices, the ABE DPLL has an internal 4X multiplier that can
be enabled or disabled in addition to the standard configurable
multiplier (M) for OMAP DPLLs. When configuring the ABE DPLL the 4X
multiplier is accounted for by checking to see whether it is enabled or
not. However, when calculating a new rate we only check to see if the
rate can be achieved with the current setting for the 4X multiplier.
Enhance the round_rate() function for such DPLLs to see if the rate
can be achieved with the 4X multiplier if it cannot be achieved without
the 4X multiplier.
This change is necessary, because when using the 32kHz clock as the
source clock for the ABE DPLL, the default DPLL frequency for the ABE
DPLL cannot be achieved without enabling the 4X multiplier.
When using the 32kHz clock as the source clock for the ABE DPLL and
attempting to lock the DPLL to 98.304MHz (default frequency), it was
found that the DPLL would fail to lock if the low-power mode for the DPLL
was not enabled. From reviewing boot-loader settings that configure the
ABE DPLL it was found that the low-power mode is enabled when using the
32kHz clock source, however, the documentation for OMAP does not state
that this is a requirement. Therefore, introduce a new function for
OMAP4 devices to see if low-power mode can be enabled when calculating a
new rate to ensure the DPLL will lock.
New variables for the last calculated 4X multiplier and low-power
setting have been added to the dpll data structure as well as variables
defining the bit mask for enabling these features via the DPLL's
control_reg. It is possible that we could eliminate these bit masks from
the dpll data structure as these bit masks are not unique to OMAP4, if
it is preferred.
The function omap3_noncore_program_dpll() has been updated to avoid
passing the calculated values for the multiplier (M) and divider (N) as
these are stored in the clk structure.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Remove all of the code that is compiled when CONFIG_COMMON_CLK=n in the
OMAP3+ DPLL handling code.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Mike Turquette <mturquette@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Convert all OMAP4 specific platform files to use COMMON clk
and keep all the changes under the CONFIG_COMMON_CLK macro check
so it does not break any existing code. At a later point switch
to COMMON clk and get rid of all old/legacy code.
This converts all apis which will be called directly from COMMON
clk to take a struct clk_hw parameter, and all the internal platform
apis to take a struct clk_hw_omap parameter.
Changes are based off the original patch from Mike Turquette.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: created new omap2_clksel_find_parent_index() rather than
modifying omap2_init_clksel_parent(); moved clkhwops_iclk_wait to
clkt_iclk.c to fix OMAP4-only builds; added clk-provider.h include to clock.h
to try to fix some 3430-builds]
[mturquette@ti.com: squash patch for omap2_clkops_{en,dis}able_clkdm;
omap2_dflt_clk_is_enabled should not enable clocks]
Signed-off-by: Mike Turquette <mturquette@ti.com>
[paul@pwsan.com: fix compiler warning; update to apply; added kerneldoc on
non-trivial new functions; added the dpll3xxx clockdomain modifications]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Remove arch/arm/plat-omap/include/plat/clock.h by merging it into
arch/arm/mach-omap1/clock.h and arch/arm/mach-omap2/clock.h.
The goal here is to facilitate ARM single image kernels by removing
includes via the "plat/" symlink.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
[tony@atomide.com: fixed to remove duplicate clock.h includes]
Signed-off-by: Tony Lindgren <tony@atomide.com>
AM33xx hwmod data and miscellaneous clock and hwmod fixes. AM33xx
should now boot on mainline after this is applied, according to
Vaibhav.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJQUWFsAAoJEBvUPslcq6VzI70P/2ECL6bunE1s53JInm7u3HFB
SM5RkOXsF8Sl+2zW0V2R8ZO9OQZC1co8e+6SmlPftv1pVXYP4wtNiFHy1MMQ5Nr7
O2ajKzAcGM1TAiJQ4A1yyfRZucOQQx7pPifACWkjagWy06JaYSUWGaea3z/g/n/U
2CGySqfyzwisiMnyZvIyxHD+cSDtERoweEEbFBKeLRlfecuBs91tIyHNbMqy7cc2
Bf+2G8m0AnrzMqhtzNAKCGJSzFEFDlr0umpLFxC+QLVFHKMJWJ7o2RwuAqf/Z9lw
AS8q2sqzypOPz7eW7z9WLqCW1YlJWhBJmLCJ1alvkebRvWRM0idlVVS3wKjHaP6q
NXF91mn21Xd9xzjXTtgigiDav0MpMuH6+FVWENanx1Rhn23GUIyRdKGMFQOeze2l
lS/vitiTDsCbXQ/EJNlDNHI2skv6AgbBbSpCsg+YivjF16DfZWhlZrFKSvQbWKfW
Mv5PnOnrpcIFNzcH8tGv9XUa61wM/HvRFbcICePAKOKy+vn2VkR/Q1XMmwHANhVf
+AMDtRNCfuspmed1pIdy4vOAcWFdXhL2jZFOBeX6rENJ2+rwJuziEuwsc1xQ8BZ5
KV9RZcg9NwvhEBiLK+K4nViRwTeeSC1OZGIEpIsJ6YOTOfWClYSnTW7In5gY1jNL
HetIvmP55Mm21G4L02D/
=UyqO
-----END PGP SIGNATURE-----
Merge tag 'omap-devel-am33xx-for-v3.7' into test_v3.6-rc6_ocb3.7_cff3.7_odaf3.7
From Paul Walmsley <paul@pwsan.com>:
AM33xx hwmod data and miscellaneous clock and hwmod fixes. AM33xx
should now boot on mainline after this is applied, according to
Vaibhav.
twl-core driver and to fix omap1_defconfig compile when
led driver changes and omap sparse IRQ changes are merged
together. Also fix warnings for omaps not using pinctrl
framework yet.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJQV9rrAAoJEBvUPslcq6Vz2AEQAIwbb/tKUgxubP6i31fuy/33
rP5RsgEMcnh3lD81+3G3hWECvxkfbs2LM06qi20YG90SPXYVd9koIWil407gvcTQ
Nqq+36QBDsQo06ou1Pmy0DeBJ8yo2j3YU+lB6m+Qn7WS+KPqrebt/DMFdMW3Yfc3
zZ87DMfw/5S787z2Uru2CLGLpgv3bOooLvJYv0xBgkKTsRmJGIKJQJ7QoXIQMves
0sLAm/nORu7UU7WvYHd+tU/gC4svfm3WEL+QX4vNvPszCQdTayh7kdZN02eaNLJF
vTUNiKjsW/xmda8+XS6YhP6lPFTPoCkDJWrIZqSWFaCnIIpsQZ+IBNdQMiB8uLtR
eMdngBqIDTmRo5BOLMM/6eU2yzZ/PLeJI1pMQOTylgz2qaugQEnd77mIzEj6sNVn
qSNtAwXTiBEhvA+8cjgsePnJxNtBdwcZ1c8YpEWigFC3cGOl3vHpt0XimIUfrkYX
kKMHnVe9WHQGPFXdkA48ZXrACwzrDb1/3GUVbtGM7rX6/OiS6b4iJzplvBN4j1t1
eOH670dVbU2LhkStHhzV2rbQm7LUyVECkn+CGh13VRJDQrVlzA70g6Vp2KBNkgM+
bxyE7sirHHtzeJtFelYGeuRJ1RULAPxPBrVX7kPsrwcSAshKFnuAC6f9IQjCy3jf
uYcmix5Qg14mN18H0l6S
=omEP
-----END PGP SIGNATURE-----
Merge tag 'cleanup-fixes-for-v3.7' into test_v3.6-rc6_ocb3.7_cff3.7_odaf3.7
These fixes are needed to fix non-omap build breakage for
twl-core driver and to fix omap1_defconfig compile when
led driver changes and omap sparse IRQ changes are merged
together. Also fix warnings for omaps not using pinctrl
framework yet.
While we move to Common Clk Framework (CCF), direct deferencing of struct
clk wouldn't be possible anymore. Hence get rid of all such instances
in the current clock code and use macros/helpers similar to the ones that
are provided by CCF.
While here also concatenate some strings split across multiple lines
which seem to be needed anyway.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: simplified some compound expressions; reformatted some
messages]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Mike Turquette <mturquette@linaro.org>
should now boot on mainline after this is applied, according to
Vaibhav.
This second version includes trailing commas at the end of structure
records at Tony's request. It also adds a OMAP_INTC_START macro
expansion to each IRQ number to make the sparseirq conversion easier.
Basic build, boot, and PM test transcripts are here:
http://www.pwsan.com/omap/testlogs/am33xx_hwmod_clock_devel_3.7/20120912165952/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJQURsaAAoJEMePsQ0LvSpLl24QAIMeCOw7z+SEjOetmWPRekS6
uPj9mz7EkWjBITMAPToQ7v9oESn+M0jcaD7wkOKaVBhPj6shXUwaMy6KmcZ5BuKf
1zrjL57ljhVLYumX8sKO3vPfKt1JvRCvcgu7xtgDKc9ywmuJLqolbi9BNxh/xo94
7IQHJk6Snrz6DxRTcvX2jUOwHG5o8WCGjPST5ZTQCKQKdpxKyeUILrhddbJMQdaq
U7DTxZVdk75KM0dbt8wVRP7AWczh8TLBEKR/bsWF47g/iL0neMDuLXyfrOd0A5ct
+JyGycl5a6lF/TiTQ7Is36s0uquidKozIx+2PwCdJGX/ntvme1wOZUGq1NSET/sw
/Uos1NjJqhM1wLPL0AbuJ8hQlZkvZThYL6c0a+GSxKGKE2dtk5ZH8vC/JMv17u21
RUzxjq1rDZVGYnm3CtO305kzQYxdUu/7aBMCE29gWKrlPr8Pz2O6wvkFePja9Qxe
YmlxakogwpFkmMaQ3eeN14VEuXCd7c2i1o8XiF/9ph250qzzKd6wTSra6Xggd32L
17GXtAfGWySqgFhb3Mfupbbr/lWGSFLeW2NhT7ZGsORvTC8J4KCql0r7f9V0/1WH
DjUcljoYF15CdOxh71vIsUOKDqN0RtyRIgeBXaIam8RDNhaF5WJjjtiIbFIS4EAm
Xw9zTjalQzJnbivxz/cy
=yRjp
-----END PGP SIGNATURE-----
Merge tag 'omap-devel-a2-for-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into devel-am33xx
AM33xx hwmod data and miscellaneous clock and hwmod fixes. AM33xx
should now boot on mainline after this is applied, according to
Vaibhav.
This second version includes trailing commas at the end of structure
records at Tony's request. It also adds a OMAP_INTC_START macro
expansion to each IRQ number to make the sparseirq conversion easier.
Basic build, boot, and PM test transcripts are here:
http://www.pwsan.com/omap/testlogs/am33xx_hwmod_clock_devel_3.7/20120912165952/
As the plat and mach includes need to disappear for single zImage work,
we need to remove plat/hardware.h.
Do this by splitting plat/hardware.h into omap1 and omap2+ specific files.
The old plat/hardware.h already has omap1 only defines, so it gets moved
to mach/hardware.h for omap1. For omap2+, we use the local soc.h
that for now just includes the related SoC headers to keep this patch more
readable.
Note that the local soc.h still includes plat/cpu.h that can be dealt
with in later patches. Let's also include plat/serial.h from common.h for
all the board-*.c files. This allows making the include files local later
on without patching these files again.
Note that only minimal changes are done in this patch for the
drivers/watchdog/omap_wdt.c driver to keep things compiling. Further
patches are needed to eventually remove cpu_is_omap usage in the drivers.
Also only minimal changes are done to sound/soc/omap/* to remove the
unneeded includes and to define OMAP44XX_MCPDM_L3_BASE locally so there's
no need to include omap44xx.h.
While at it, also sort some of the includes in the standard way.
Cc: linux-watchdog@vger.kernel.org
Cc: alsa-devel@alsa-project.org
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
Cc: Liam Girdwood <lrg@ti.com>
Acked-by: Wim Van Sebroeck <wim@iguana.be>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Add missing soc_is_am33xx() check for DPLL common control & clock
related functions, without this dpll programmability would be broken
for am33xx family of devices.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Resolve the following warnings from smatch:
arch/arm/mach-omap2/gpmc.c:282 gpmc_cs_set_timings() info: why not propagate 'div' from gpmc_cs_calc_divider() instead of -1?
arch/arm/mach-omap2/serial.c:328 omap_serial_init_port() error: 'pdev' dereferencing possible ERR_PTR()
arch/arm/mach-omap2/timer.c:213 omap2_gp_clockevent_init() Error invalid range 4096 to -1
arch/arm/mach-omap2/gpio.c:63 omap2_gpio_dev_init() warn: possible memory leak of 'pdata'
arch/arm/mach-omap2/omap_hwmod.c:1478 _assert_hardreset() warn: assigning -22 to unsigned variable 'ret'
arch/arm/mach-omap2/omap_hwmod.c:1487 _assert_hardreset() warn: 4294963201 is more than 255 (max '(ret)' can be) so this is always the same.
arch/arm/mach-omap2/omap_hwmod.c:1545 _read_hardreset() warn: assigning -22 to unsigned variable 'ret'
arch/arm/mach-omap2/omap_hwmod.c:1554 _read_hardreset() warn: 4294963201 is more than 255 (max '(ret)' can be) so this is always the same.
arch/arm/mach-omap2/dpll3xxx.c:629 omap3_clkoutx2_recalc() error: we previously assumed 'pclk' could be null (see line 627)
arch/arm/mach-omap2/board-n8x0.c:422 n8x0_mmc_late_init() Error invalid range 14 to 13
arch/arm/mach-omap1/leds-h2p2-debug.c:71 h2p2_dbg_leds_event() error: potentially derefencing uninitialized 'fpga'.
arch/arm/plat-omap/mux.c:79 omap_cfg_reg() Error invalid range 4096 to -1
Thanks to Tony Lindgren <tony@atomide.com> for pointing out that BUG()
can be disabled. The changes in the first version that removed the
subsequent return() after BUG() states have been dropped.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
In order to remove unnecessary idefs, move noncore and core
dpll ops to dpll3xxx.c file (where it should have been already).
The clkops (clkops_omap3_core_dpll_ops & clkops_omap3_noncore_dpll_ops)
is used in clock data files, and dependency is already handled by
Makefile rule.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
If the dpll is already locked, code can be optimized
to return much earlier than doing redundent set of lock mode
and wait on idlest.
Cc: Tony Lindgren <tony@atomide.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Mike Turquette <mturquette@ti.com>
Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
The current DPLL code enables and disables autoidle features
without checking whether the autoidle register is available.
Fix this by putting a check for the existence of the autoidle
register in the DPLL data.
With such a check in place, for DPLLs which do not support this
feature, simply skipping the autoidle_reg entry in the DPLL data
is sufficient.
Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
This is a continuation of Mike Turquette's patch "OMAP3+: use
DPLL's round_rate when setting rate".
omap3_noncore_dpll_set_rate() and omap3_noncore_dpll_enable() call
omap2_get_dpll_rate() explicitly. It may be necessary for some
DPLLs to use a different function and so use the DPLLs recalc()
function pointer instead.
An example is the DPLL_ABE on OMAP4 which can have a 4X multiplier
in addition to the usual MN multipler and dividers and therefore
uses a different round_rate and recalc function.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Cc: Mike Turquette <mturquette@ti.com>
Cc: Misael Lopez Cruz <misael.lopez@ti.com>
[paul@pwsan.com: merged this patch with Mike's "use clock's recalc in DPLL
handling" patch; also reported by Misael]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
The rounded rate can differ from target rate, so to better reflect
reality set clk->rate equal to the rounded rate when setting DPLL frequency.
This avoids issues where the DPLL frequency is slightly different than what
debugfs clock tree reports using the old target rate.
An example of a clock that requires this is DPLL_ABE on OMAP4 which
can have a 4x multiplier on top of the usual MN dividers depending on
register settings. This requires a special round_rate function that
might yield a rate different from the initial target.
Signed-off-by: Mike Turquette <mturquette@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
omap3_noncore_dpll_set_rate uses omap2_dpll_round_rate explicitly. Instead
use the struct clk pointer's round_rate function to allow for DPLL's with
special needs.
An example of a clock that requires this is DPLL_ABE on OMAP4 which
can have a 4x multiplier on top of the usual MN dividers depending on
register settings. This requires a special round_rate function that
might yield a rate different from the initial target.
Signed-off-by: Mike Turquette <mturquette@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: split rate assignment portion into a separate patch]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
* 'omap-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6: (243 commits)
omap2: Make OMAP2PLUS select OMAP_DM_TIMER
OMAP4: hwmod data: Fix alignment and end of line in structurefields
OMAP4: hwmod data: Move the DMA structures
OMAP4: hwmod data: Move the smartreflex structures
OMAP4: hwmod data: Fix missing SIDLE_SMART_WKUP in smartreflexsysc
arm: omap: tusb6010: add name for MUSB IRQ
arm: omap: craneboard: Add USB EHCI support
omap2+: Initialize serial port for dynamic remuxing for n8x0
omap2+: Add struct omap_board_data and use it for platform level serial init
omap2+: Allow hwmod state changes to mux pads based on the state changes
omap2+: Add support for hwmod specific muxing of devices
omap2+: Add omap_mux_get_by_name
OMAP2: PM: fix compile error when !CONFIG_SUSPEND
MAINTAINERS: OMAP: hwmod: update hwmod code, data maintainership
OMAP4: Smartreflex framework extensions
OMAP4: hwmod: Add inital data for smartreflex modules.
OMAP4: PM: Program correct init voltages for scalable VDDs
OMAP4: Adding voltage driver support
OMAP4: Register voltage PMIC parameters with the voltage layer
OMAP3: PM: Program correct init voltages for VDD1 and VDD2
...
Fix up trivial conflict in arch/arm/plat-omap/Kconfig
J-Type DPLLs have additional configuration parameters that need to
be programmed when setting the multipler and divider for the DPLL.
These parameters being the sigma delta divider (SD_DIV) for the DPLL
and the digital controlled oscillator (DCO) to be used by the DPLL.
The current code is implemented specifically to configure the
OMAP3630 PER J-Type DPLL. The OMAP4430 USB DPLL is also a J-Type DPLL
and so this code needs to be updated to work for both OMAP3 and OMAP4
devices and any other future devices that have J-TYPE DPLLs.
For the OMAP3630 PER DPLL both the SD_DIV and DCO paramenters are
used but for the OMAP4430 USB DPLL only the SD_DIV field is used.
The current implementation will only program the SD_DIV and DCO
fields if the DPLL has both and hence this does not work for
OMAP4430.
In order to make the code more generic add two new fields to the
dpll_data structure for the SD_DIV field and DCO field bit-masks
and only program these fields if the masks are defined for a specific
DPLL. This simplifies the code and allows us to remove the flag
DPLL_NO_DCO_SEL.
Tested on OMAP36xx Zoom3 and OMAP4 Blaze.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: removed explicit inlining and added '_' prefix on lookup_*()
functions; added testing info to commit message; added 35xx comments back in]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
In preparation for adding OMAP4-specific PRCM accessor/mutator
functions, split the existing OMAP2/3 PRCM code into OMAP2/3-specific
files. Most of what was in mach-omap2/{cm,prm}.{c,h} has now been
moved into mach-omap2/{cm,prm}2xxx_3xxx.{c,h}, since it was
OMAP2xxx/3xxx-specific.
This process also requires the #includes in each of these files to be
changed to reference the new file name. As part of doing so, add some
comments into plat-omap/sram.c and plat-omap/mcbsp.c, which use
"sideways includes", to indicate that these users of the PRM/CM includes
should not be doing so.
Thanks to Felipe Contreras <felipe.contreras@gmail.com> for comments on this
patch.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
Cc: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>
Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
Acked-by: Omar Ramirez Luna <omar.ramirez@ti.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>
Acked-by: Felipe Contreras <felipe.contreras@gmail.com>
Cc: Greg Kroah-Hartman <greg@kroah.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
factorise some generic infrastructure to assist looking up struct clks
for the ARM & SH architecture.
as the code is identical at 99%
put the arch specific code for allocation as example in asm/clkdev.h
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
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>
DPLL4 for 3630 introduces a changed block called j type dpll, requiring
special divisor bits and additional reg fields. To allow for silicons to
use this, this is introduced as a flag and is enabled for 3630 silicon.
OMAP4 also has j type dpll for usb.
Tested with 3630 ZOOM3 and OMAP3430 ZOOM2
Signed-off-by: Richard Woodruff <r-woodruff2@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Vishwanath BS <Vishwanath.bs@ti.com>
[paul@pwsan.com: added some comments; updated copyrights and credits; fixed
some style issues]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
DPLL_FREQSEL field in CLKEN_PLL register is no longer valid for
OMAP3630. So remove references to that.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Cc: Sergei Shtylyov <sshtylyov@mvista.com>
[paul@pwsan.com: added comment fix from Sergei Shtylyov]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Move all static functions up to the top of the file to match the
practice in other OMAP clock code. Make omap3_noncore_dpll_program()
static (noted by sparse) and prepend an underscore to the function
name to mark that it is file-local.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Mark the OMAP3-specific DPLL functions as being OMAP3-specific by moving
them from mach-omap2/dpll.c to mach-omap2/dpll3xxx.c.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Tomeu Vizoso