The initialize of i2c subsystem will set pinmux, so it should be done
after the initialize of mux subsystem initialization.
Signed-off-by: Stanley.Miao <stanley.miao@windriver.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Change the name for the spi instances on omap44xx_clks to match
the names omap2 spi driver gives:
omap-mcspi.1 -> omap2_mcspi.1
omap-mcspi.2 -> omap2_mcspi.2
omap-mcspi.3 -> omap2_mcspi.3
omap-mcspi.4 -> omap2_mcspi.4
Signed-off-by: Abraham Arce <x0066660@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Disable the nonexistent ehci port on Devkit8000.
Signed-off-by: Thomas Weber <weber@corscience.de>
Acked-by: Anand Gadiyar <gadiyar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
IGEP v2 uses EHCI port 1 instead of EHCI port 2.
Signed-off-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>
Acked-by: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Fix warning: 'return' with a value, in function returning void
in n8x0_mmc_init. Also fix a search and replace typo.
Signed-off-by: Tony Lindgren <tony@atomide.com>
The value to check is 7 for V6 instead. The code has been
working as it falls through to 24xx code if the other checks
fail.
Signed-off-by: Tony Lindgren <tony@atomide.com>
The enable bit for dpll4_m4x2 clock should be OMAP3430_PWRDN_DSS1_SHIFT.
The code erroneously uses OMAP3430_PWRDN_CAM_SHIFT which is meant for
dpll4_m5x2 clock.
This came into notice during a recent review of the clock tree.
Signed-off-by: Ranjith Lohithakshan <ranjithl@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
This patch fixes usage of bitwise OR in if conditions, and instead
uses logical OR.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Cc: Abhijit Pagare <abhijitpagare@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
This patch adds check for presence of clockdomain structure in the API
omap_hwmod_get_pwrdm before trying to access the powerdomain structure.
This will prevent unnecessary crashing of the system in case of a
clock node with out an associated clockdomain.
Signed-off-by: Thara Gopinath <thara@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
This is now changed to PLAT8250_DEV_PLATFORM (= 0), because
it's the only port that's going to be initialized in
Zoom 2/3 boards.
So, it doesn't make sense to keep the hardcoded 3 value anymore.
Signed-off-by: Sergio Aguirre <saaguirre@ti.com>
This is useless, since in Zoom2/3 boards, the ports aren't even
physically accessible.
They must be explicitly initted in the board-zoom2.c, board-zoom3.c
and board-3630sdp.c files instead.
Signed-off-by: Sergio Aguirre <saaguirre@ti.com>
As we have a struct device populated at the time we are
printing the errors, using dev_* macros makes more sense,
as could give a better idea where the error/warning came from.
Signed-off-by: Sergio Aguirre <saaguirre@ti.com>
This is for protecting a wrong mapping attempt of a zero-based
physical address.
The result is that, no serial port will be attempted to be mapped.
Also add an additional protection for NULL clocks before attempting
to enable them (if above condition applies)
Signed-off-by: Sergio Aguirre <saaguirre@ti.com>
Remove the +x bit from a couple of source files
Signed-off-by: Andrew Clayton <andrew@digital-domain.net>
Signed-off-by: Tony Lindgren <tony@atomide.com>
When building for multi-omap, and OMAP4 is enabled, CONFIG_ARCH_OMAP4
will be true and prevent included code from building/running for
OMAP2/3 as well.
This problem exists in io.c where some hwmod/PM/SDRC init code is
prevented from running even on OMAP2/3 when OMAP4 is included in a
multi-OMAP build.
A quick glance suggests that this #ifndef is no longer needed in most
of the cases. In the remaining cases, the function is wrapped with
"if (cpu_is_omap24xx() || cpu_is_omap34xx())" which will be optimized
out for OMAP4-only builds.
Note that this is only a short-term fix. Longer-term, OMAP4
needs to create init functions for SDRC and hwmod late-init.
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Get rid of the following warnings:
warning: non-ANSI function declaration of function [...]
Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Select CONFIG_LEDS_GPIO to enable IGEP v2 LED support and control of supported
LEDs from userspace. Otherwise GPIO LEDs are exported as GPIO 26, 27 and 28 using
the gpiolib framework.
Signed-off-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This patch follows the commit be093beb60
by Russell King:
OMAP wishes to pass state to the boot loader upon reboot in order
to instruct it whether to wait for USB-based reflashing or not.
There is already a facility to do this via the reboot() syscall,
except we ignore the string passed to machine_restart().
The patch adds the missing parameter to omap1_arch_reset() and
omap_prcm_arch_reset(), and modifies the latter to pass the reboot
command parameter to the boot loader instead of reboot mode (which is
for kernel internal use only and cannot be modified by the userspace).
Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The omap_serial_early_init prints the following errors:
Could not get uart4_ick
Could not get uart4_fck
because all the uarts available in omap_uart[] will be initialized.
Only omap4430 and omap3630 have 4 uarts at the moment.
This patch reduces the number of uarts when cpu is not omap4430 or
omap3630.
Signed-off-by: Thomas Weber <weber@corscience.de>
Signed-off-by: Tony Lindgren <tony@atomide.com>
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>
This patch moves omap_smc1 function to a seperate omap44xx-smc.S file
and sets compile flags as -Wa,-march=armv7-a.
This fix was suggested by Tony Lindgren <tony@atomide.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[tony@atomide.com: otherwise multi-omap build with V6 and V7 breaks]
Signed-off-by: Tony Lindgren <tony@atomide.com>
the early_param() call in board-omap3touchbook.c expands to:
static const char __setup_str_early_touchbook_revision[]
__section(.init.rodata) _aligned(1) = tbr;
[...]
and we have a non-const variable being added to the
same section:
static struct ehci_hcd_omap_platform_data ehci_pdata
__section(.init.rodata);
because of that, gcc generates a section type conflict
which can (and actually should) be avoided by marking
const every variable marked with __initconst.
This patch fixes that for the ehci_hdc_omap_platform_data.
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Commit 2b0d8c251b changed ARM to use
the common early_param code. Fix compile for Touch Book accordingly.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Correct instances where tca6416 is misspelt as tca6516 in
the board-am3517evm file.
Signed-off-by: Sriramakrishnan <srk@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Adding GPIO mux config used for PHY reset of EHCI port on base board.
We get below failure message without this patch,
"hub 1-0:1.0: unable to enumerate USB device on port 1"
Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The commit b63128e812 broke the pin muxing
for I2C busses that are enabled from the kernel command line.
Fix this by defining the board registration function omap_register_i2c_bus
in common platform code as it was before but keep the muxing in architecture
dependent files.
Signed-off-by: Jarkko Nikula <jhnikula@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Now the omap4 clock framework is in mainline and clk_get_rate()
is functional. Hence reomve the hardcoded clock hacks.
This patch also fixes
Division by zero in kernel.
Backtrace:
[<c0025fb8>] (dump_backtrace+0x0/0x110) from [<c017febc>] (dump_stack+0x18/0x1c)
r7:60000093 r6:c0641050 r5:c0223e78 r4:c02126b4
[<c017fea4>] (dump_stack+0x0/0x1c) from [<c00260fc>] (__div0+0x18/0x20)
[<c00260e4>] (__div0+0x0/0x20) from [<c01431fc>] (Ldiv0+0x8/0x10)
[<c00318d4>] (omap_dm_timer_stop+0x0/0xb0) from [<c002c148>] (omap2_gp_timer_set_mode+0x1c/0x68)
r5:c0223e78 r4:00000000
[<c002c12c>] (omap2_gp_timer_set_mode+0x0/0x68) from [<c0063270>] (clockevents_set_mode+0x30/0x64)
r5:c020cae0 r4:00000000
[<c0063240>] (clockevents_set_mode+0x0/0x64) from [<c00632fc>] (clockevents_exchange_device+0x30/0x9c)
r5:c020cae0 r4:c02146e0
[<c00632cc>] (clockevents_exchange_device+0x0/0x9c) from [<c00636e0>] (tick_notify+0x17c/0x404)
r7:00000000 r6:c0641050 r5:00000000 r4:c020cae0
[<c0063564>] (tick_notify+0x0/0x404) from [<c005d5fc>] (notifier_call_chain+0x34/0x78)
[<c005d5c8>] (notifier_call_chain+0x0/0x78) from [<c005d684>] (__raw_notifier_call_chain+0x1c/0x24)
[<c005d668>] (__raw_notifier_call_chain+0x0/0x24) from [<c005d6ac>] (raw_notifier_call_chain+0x20/0x28)
[<c005d68c>] (raw_notifier_call_chain+0x0/0x28) from [<c0062e78>] (clockevents_do_notify+0x1c/0x24)
[<c0062e5c>] (clockevents_do_notify+0x0/0x24) from [<c0062f18>] (clockevents_register_device+0x98/0xd0)
[<c0062e80>] (clockevents_register_device+0x0/0xd0) from [<c001a194>] (percpu_timer_setup+0x80/0x9c)
r7:00000000 r6:00000002 r5:00000002 r4:00000003
[<c001a114>] (percpu_timer_setup+0x0/0x9c) from [<c000e9f0>] (smp_prepare_cpus+0xb0/0xe8)
[<c000e940>] (smp_prepare_cpus+0x0/0xe8) from [<c00084e8>] (kernel_init+0x5c/0x1fc)
r7:00000000 r6:00000000 r5:00000000 r4:c001b8a4
[<c000848c>] (kernel_init+0x0/0x1fc) from [<c0046c50>] (do_exit+0x0/0x604)
r7:00000000 r6:00000000 r5:00000000 r4:00000000
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
On OMAP4 platform the iclk control is completly under hardware control
and no software control is available.
This difference w.r.t previous OMAP's needs all the common driver
accross OMAP's , cpu_is_xxxx() checks. To avoid poulluting the
drivers dummy clock nodes are created (The autogeneration
script has been updated accordingly).
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
[paul@pwsan.com: made OMAP1 dummy_ck common and edited patch to reuse that]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
All leaf clock nodes are renamed for OMAP4 to have a clk name which
end with a _ick or a _fck. This is done so that the naming convention
is same as that followed on older OMAPs.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Simplify the code in the omap2_clk_disable() and omap2_clk_enable()
functions, reducing levels of indentation. This makes the code easier
to read. Add some additional debugging pr_debug()s here also to help
others understand what is going on.
Revise the omap2_clk_disable() logic so that it now attempts to
disable the clock's clockdomain before recursing up the clock tree.
Simultaneously, ensure that omap2_clk_enable() is called on parent
clocks first, before enabling the clockdomain. This ensures that a
parent clock's clockdomain is enabled before the child clock's
clockdomain. These sequences should be the inverse of each other.
Revise the omap2_clk_enable() logic so that it now cleans up after
itself upon encountering an error. Previously, an error enabling a
parent clock could have resulted in inconsistent usecounts on the
enclosing clockdomain.
Remove the trivial _omap2_clk_disable() and _omap2_clk_enable() static
functions, and replace it with the clkops calls that they were
executing.
For all this to work, the clockdomain omap2_clkdm_clk_enable() and
omap2_clkdm_clk_disable() code must not return an error on clockdomains
without CLKSTCTRL registers; so modify those functions to simply return 0
in that case.
While here, add some basic kerneldoc documentation on both functions,
and get rid of some old non-CodingStyle-compliant comments that have
existed since the dawn of time (at least, the OMAP clock framework's
time).
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
The OMAP2 and OMAP3 boot-time MPU rate change code is almost
identical. Merge them into mach-omap2/clock.c, and add kerneldoc
documentation.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
_clkdm_add_autodeps() and _clkdm_del_autodeps() will attempt to dereference
a NULL pointer if no autodeps were supplied to clkdm_init().
Based on a patch from Roel Kluin <roel.kluin@gmail.com> - thanks Roel.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Roel Kluin <roel.kluin@gmail.com>
Add support for categorizing and iterating over hardware IP blocks by
the "class" of the IP block. The class is the type of the IP block:
e.g., "timer", "timer1ms", etc. Move the OCP_SYSCONFIG/SYSSTATUS data
from the struct omap_hwmod into the struct omap_hwmod_class, since
it's expected to stay consistent for each class. While here, fix some
comments.
The hwmod_class structures in this patch were designed and proposed by
Benoît Cousson <b-cousson@ti.com> and were refined in a discussion
between Thara Gopinath <thara@ti.com>, Kevin Hilman
<khilman@deeprootsystems.com>, and myself.
This patch uses WARN() lines that are longer than 80 characters, as
Kevin noted a broader lkml consensus to increase greppability by
keeping the messages all on one line.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Benoît Cousson <b-cousson@ti.com>
Cc: Thara Gopinath <thara@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Code should be able to #include any header file without the fear that
the header file will go allocating memory. This is a coding style
issue, similar to commit 82e9bd5885.
Move the existing hwmod data from .h files to .c files.
While here, convert "omap34xx" to "omap3xxx" in the hwmod files, since
most of these structures should be reusable across all OMAP3 chips.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
The OMAP hwmod core code is intended to use SoC IP block description
structures that are autogenerated from TI's OMAP hardware database.
Currently the hwmod code uses clkdev device + connection addressing to
identify clocks. This causes problems in the hwmod autogeneration
process, since the TI hardware database doesn't use platform_device or
clkdev addressing; it uses a single clock signal name string, which
tends to bear some resemblance to what is used in the OMAP TRMs. This
patch converts the hwmod code and existing data to use omap_clk_get_by_name(),
introduced in the previous patch.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Add necessary clk_sel definitions to clock framework to allow changing
dpll4_m5_ck_3630 rate. This is used by the ISP driver.
Signed-off-by: Vimarsh Zutshi <vimarsh.zutshi@nokia.com>
[paul@pwsan.com: updated to apply]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Get rid of the ALWAYS_ENABLED clock flag - it doesn't actually do anything.
(The OMAP4 clock autogeneration scripts have been updated accordingly.)
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Benoît Cousson <b-cousson@ti.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>
func_96m_ck was incorrectly marked as being rate-selectable, when in
fact it is only parent-selectable. Remove the .set_rate and .round_rate
function pointers for this clk.
Signed-off-by: Paul Walmsley <paul@pwsan.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>
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 <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Ranjith Lohithakshan <ranjithl@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
stanley.miao