2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-25 13:43:55 +08:00
Commit Graph

10 Commits

Author SHA1 Message Date
Rajendra Nayak
d037e100d1 ARM: OMAP2: clock: Cleanup !CONFIG_COMMON_CLK parts
Clean all #ifdef's added to OMAP2 clock code to make it COMMON clk
ready, not that CONFIG_COMMON_CLK is enabled.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: also drop CONFIG_COMMON_CLK tests around APLL recalc_rate
 functions]
Signed-off-by: Mike Turquette <mturquette@ti.com>
[paul@pwsan.com: remove some ifdefs in mach-omap2/io.c]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-11-12 19:18:51 -07:00
Rajendra Nayak
ed1ebc4948 ARM: OMAP2: clock: Convert to common clk
Convert all OMAP2 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.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Mike Turquette <mturquette@ti.com>
[paul@pwsan.com: updated to apply]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-11-12 19:10:18 -07:00
Tony Lindgren
8634155ef4 The first set of OMAP PRM/CM-related cleanup patches for 3.8.
Prepares for the future move of the PRM/CM code to drivers/.  Also
 includes some prcm.[ch] cleanup patches from the WDTIMER cleanup
 series that don't need external acks.
 
 Basic test logs for this branch on top of v3.7-rc2 are here:
 
 http://www.pwsan.com/omap/testlogs/prcm_cleanup_a_3.8/20121021123719/
 
 But due to the number of unrelated regressions present in v3.7-rc[12],
 it's not particularly usable as a testing base.  With reverts, fixes,
 and workarounds applied as documented in:
 
 http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/README.txt
 
 the following test logs were obtained:
 
 http://www.pwsan.com/omap/testlogs/prcm_cleanup_a_3.8/20121020231757/
 
 which indicate that the series tests cleanly.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.12 (GNU/Linux)
 
 iQIcBAABAgAGBQJQhEVeAAoJEMePsQ0LvSpLXMAP/R823zHuhSBsFYTAzoLpOsBu
 1btfoXY+aTh/ZYQpn2zqbseHyBVoN7JuBNFA25UlgCIB/+tL2o+B62HQE3c31HZi
 zrOlUrSvIl7zYTLhbu8rezULSYGO3RHqtUGLJ9/RUV3su8zIATmHKgzA1f/aYH9x
 2OKVIijXjvK4kKRpHhg8BGlD6stbuFDJbmik2/wgcO+159lKY6ZTRnHsj6PgZVIO
 BjbxpBujLYVBhJRJP0NNLVtGToGK54GvnHZxfVCu9oJ87n2amgaP6RHHHfEX0eMJ
 K65toYNIzZEmMahnazCcsiB+xK2Y2iiSZdOMPhH0FspCPTKTUl+czOlMGq7oyHmU
 xVmDyVHOVd5JRt5d985VlVScDrye06GxjWri557eeGcvOyQrlhJSntjdL2RZZaiu
 bpIhT1PRo8hqxtajcZlqBT7jSaH8kxQIQRXgGqJzY9iYLfUGU6DU7WYoqQTrrev7
 aCZG8SnDbmltXMvhw13owDzy8xpdssCFaT8Fbxaxa6jq1GF1xyfEucDZDQPlZZd7
 vbhdjYCBMiFcgJ3xWAmivboLPR1r5nZQdpwuYJTqoIvuJutB8Y0dJza7Dm0DGehc
 uJw/K/L/2qBdlOatFU4nk1c4AoTXZ+zn+ZVziTFus6ajhdB46C0i/vMLAXF68aDQ
 23ow9fKjRsuHfKqjfzMP
 =asxx
 -----END PGP SIGNATURE-----

Merge tag 'omap-cleanup-a-for-3.8' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.8/cleanup-prcm

The first set of OMAP PRM/CM-related cleanup patches for 3.8.
Prepares for the future move of the PRM/CM code to drivers/.  Also
includes some prcm.[ch] cleanup patches from the WDTIMER cleanup
series that don't need external acks.

Basic test logs for this branch on top of v3.7-rc2 are here:

http://www.pwsan.com/omap/testlogs/prcm_cleanup_a_3.8/20121021123719/

But due to the number of unrelated regressions present in v3.7-rc[12],
it's not particularly usable as a testing base.  With reverts, fixes,
and workarounds applied as documented in:

http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/README.txt

the following test logs were obtained:

http://www.pwsan.com/omap/testlogs/prcm_cleanup_a_3.8/20121020231757/

which indicate that the series tests cleanly.

Conflicts:
	arch/arm/mach-omap2/Makefile
	arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
	arch/arm/mach-omap2/pm24xx.c
2012-10-24 17:05:59 -07:00
Paul Walmsley
ff4ae5d931 ARM: OMAP2+: CM/hwmod: split CM functions into OMAP2, OMAP3-specific files
Move OMAP3xxx-specific CM functions & macros into cm3xxx.[ch] and
OMAP2xxx-specific macros into cm2xxx.[ch].  Move basic CM register
access functions into static inline functions in cm2xxx_3xxx.h,
leaving only OMAP2/3 hardreset functions in cm2xxx_3xxx.c.

As part of this, split the CM and hwmod code that waits for devices to
become ready into SoC-specific functions.

This is in preparation for the upcoming move of this code to drivers/.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Reviewed-by: Russ Dill <Russ.Dill@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
2012-10-21 01:01:11 -06:00
Paul Walmsley
a135eaae52 ARM: OMAP: remove plat/clock.h
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>
2012-10-18 16:23:20 -07:00
Tony Lindgren
dbc0416104 ARM: OMAP: Split plat/hardware.h, use local soc.h for omap2+
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>
2012-09-12 18:06:31 -07:00
Tony Lindgren
2c799cef4d ARM: OMAP: Remove plat/io.h by splitting it into mach/io.h and mach/hardware.h
This is needed to minimize io.h so the SoC specific io.h
for ARMs can removed.

Note that minimal driver changes for DSS and RNG are needed to
include cpu.h for SoC detection macros.

Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-02-24 10:34:35 -08:00
Tony Lindgren
ee0839c22c ARM: OMAP2+: Move most of plat/io.h into local iomap.h
There's no need to have these defines in plat/io.h.

Note that we now need to ifdef omap_read/write calls
as they will be available for omap1 only.

While at it, clean up the includes to group them like
they typically are grouped.

Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-02-24 10:34:35 -08:00
Paul Walmsley
59fb659b06 OMAP2/3: PRCM: split OMAP2/3-specific PRCM code into OMAP2/3-specific files
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>
2010-12-21 20:01:55 -07:00
Paul Walmsley
81b34fbecb OMAP2 clock: split OMAP2420, OMAP2430 clock data into their own files
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>
2010-02-24 12:29:42 -07:00