Only OMAP2+ platforms have the System Control Module (SCM) IP block.
In the past, we've kept the SCM header file in plat-omap. This has
led to abuse - device drivers including it; includes being added that
create implicit dependencies on OMAP2+ builds; etc.
In response, move the SCM headers into mach-omap2/.
As part of this, remove the direct SCM access from the OMAP UDC
driver. It was clearly broken. The UDC code needs an indepth review for
use on OMAP2+ chips.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Cory Maccarrone <darkstar6262@gmail.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Add the MCBSP_CLKS clock and the clksel structures needed to support clock
framework-based source switching for McBSP 1 and 2. Also, add clkdev
aliases on the parent clocks for the McBSP source switching code, added
in a subsequent patch.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Updates to enable omap aes
Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@nokia.com>
[tony@atomide.com: updated to use CONFIG_ARCH_OMAP2/3 instead of old 24XX/34XX]
Signed-off-by: Tony Lindgren <tony@atomide.com>
The DEFAULT_RATE clksel_rate flag is essentially useless. It was set
on some of the lowest divisors, which, when switching to a much
higher-rate parent, could have potentially resulted in rates that
exceeded the hardware specifications for downstream clocks in the
window between the clk_set_parent(), and a subsequent clk_set_rate().
It seems much safer to just remove the flag and always use the highest
available divisor (resulting in the lowest possible rate) after the
switch, and this patch does so.
Ideally, it would be best to first attempt to switch to a divisor that
matches the clock's rate with the previous parent, if at all possible.
But that is a project for some other day or some other person. The
parent changing code is rarely used.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Fix all of the remaining OMAP2 PRCM register shift/bitmask macros that
did not use the _SHIFT/_MASK suffixes to use them. This makes the use
of these macros consistent. It is intended to reduce error, as code
can be inspected visually by reviewers to ensure that bitshifts and
bitmasks are used in the appropriate places.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
- registration with multi OMAP kernels support
- clocks
Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@nokia.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Based on Kalle's and Tony's patches. Some variables re-organized
and unused code removed.
Signed-off-by: Kalle Valo <kalle.valo@iki.fi>
Signed-off-by: Francisco Alecrim <francisco.alecrim@openbossa.org>
[tony@atomide.com: this is needed to fix the related tusb6010 DMA API changes]
Signed-off-by: Tony Lindgren <tony@atomide.com>
The RATE_FIXED clock flag is pointless. In the OMAP1 clock code, it
simply causes the omap1_clk_round_rate() function to return the
current rate of the clock. omap1_clk_round_rate(), however, should
never be called for a fixed-rate clock, since none of these clocks
have a .round_rate function pointer set in their struct clk records.
Similarly, in the OMAP2+ clock code, the RATE_FIXED flag just causes
the clock code to emit a warning if the OMAP clock maintainer was
foolish enough to add a .round_rate function pointer to a fixed-rate
clock. "Doctor, it hurts when I pretend that a fixed-rate clock is
rate-changeable." "Then don't pretend that a fixed-rate clock is
rate-changeable." It has no functional value. This patch drops the
RATE_FIXED clock flag, removing it from all clocks that are so marked.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
All of the clocks that are marked with DELAYED_APP are changed as part
of the virt_prcm_set OPP virtual clock. On 24xx, these clocks all
need to be changed as part of a group to keep the clock tree
functional - hence the need for the VALID_CONFIG bit, which is not
present on later OMAPs. These clocks should not be rate-changed
independently. So prevent these clocks from being changed
independently by dropping their .round_rate and .set_rate function
pointers. It then turns out that the DELAYED_APP clock flag is no
longer useful, so drop it and the associated code and renumber the
clock flags.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
In preparation for multi-OMAP2 kernels, split
mach-omap2/clock2xxx_data.c into mach-omap2/clock2420_data.c and
mach-omap2/clock2430_data.c. 2430 uses a different device space
physical memory layout than past or future OMAPs, and we use a
different virtual memory layout as well, which causes trouble for
architecture-level code/data that tries to support both. We tried
using offsets from the virtual base last year, but those patches never
made it upstream; so after some discussion with Tony about the best
all-around approach, we'll just grit our teeth and duplicate the
structures. The maintenance advantages of a single kernel config that
can compile and boot on OMAP2, 3, and 4 platforms are simply too
compelling.
This approach does have some nice benefits beyond multi-OMAP 2 kernel
support. The runtime size of OMAP2420-specific and OMAP2430-specific
kernels is smaller, since unused clocks for the other OMAP2 chip will
no longer be compiled in. (At some point we will mark the clock data
__initdata and allocate it during registration, which will eliminate
the runtime memory advantage.) It also makes the clock trees slightly
easier to read, since 2420-specific and 2430-specific clocks are no
longer mixed together.
This patch also splits 2430-specific clock code into its own file,
mach-omap2/clock2430.c, which is only compiled in for 2430 builds -
mostly for organizational clarity.
While here, fix a bug in the OMAP2430 clock tree: "emul_ck" was
incorrectly marked as being 2420-only, when actually it is present on
both OMAP2420 and OMAP2430.
Thanks to Tony for some good discussions about how to approach this
problem.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
Paul Walmsley