Commit Graph

8 Commits

Author SHA1 Message Date
Tony Lindgren
e4c060db2c ARM: OMAP: Split plat/cpu.h into local soc.h for mach-omap1 and mach-omap2
We want to remove plat/cpu.h. To do this, let's first split
it to private soc.h to mach-omap1 and mach-omap2. We have to
keep plat/cpu.h around until the remaining drivers are fixed,
so let's include the local soc.h in plat/cpu.h and for drivers
still including plat/cpu.h.

Once the drivers are fixed not to include plat/cpu.h, we
can remove the file.

This is needed for the ARM common zImage support.

[tony@atomide.com: updated to not print a warning]
Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-10-18 16:23:46 -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
0d9596958d Merge branch 'for_2.6.39/pm-integration' of ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into omap-for-linus 2011-03-11 09:39:58 -08:00
Tony Lindgren
a2358a7bc3 Merge branch 'integration-2.6.39-for-tony' of git://git.pwsan.com/linux-integration into omap-for-linus
Conflicts:
	arch/arm/mach-omap2/pm34xx.c
2011-03-11 09:20:03 -08:00
Vishwanath BS
15f13e23e8 OMAP3+: OPP: Replace voltage values with Macros
Since all voltage data is now centralized in oppxxx_data.c, we can replace
the values in the opp table with the macros used for voltage values.

This will avoid opp table and voltage layer having conflicting values.

Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-03-11 07:21:44 -08:00
Paul Walmsley
c0718df4d6 OMAP2+: voltage: reorganize, split code from data
This is a first pass at reorganizing mach-omap2/voltage.c:

- Separate almost all of the data from the code of mach-omap2/voltage.c.
  The code remains in mach-omap2/voltage.c.  The data goes into one
  of several places, depending on what type of data it is:

  - Silicon process/validation data: mach-omap2/opp*_data.c
  - VC (Voltage Controller) data: mach-omap2/vc*_data.c
  - VP (Voltage Processor) data: mach-omap2/vp*_data.c
  - Voltage domain data: mach-omap2/voltagedomains*_data.c

  The ultimate goal is for all this data to be autogenerated, the same
  way we autogenerate the rest of our data.

- Separate VC and VP common data from VDD-specific VC and VP data.

- Separate common voltage.c code from SoC-specific code; reuse common code.

- Reorganize structures to avoid unnecessary memory loss due to unpacked
  fields.

There is much left to be done.  VC code and VP code should be separated out
into vc*.c and vp*.c files.  Many fields in the existing structures are
superfluous, and should be removed.  Some code in voltage.c seems to be
duplicated; that code should be moved into functions of its own.  Proper
voltage domain code should be created, as was done with the powerdomain
and clockdomains, and powerdomains should reference voltagedomains.

Thanks to Shweta Gulati <shweta.gulati@ti.com> for comments.  Thanks
to Rajendra Nayak <rnayak@ti.com> for finding and fixing some bugs
that prevented OMAP4 from booting:

   https://patchwork.kernel.org/patch/587311/

His patch has been folded into this one to avoid breaking OMAP4
between patches.  Thanks also to Kevin Hilman <khilman@ti.com> for
finding and fixing a compile problem when !CONFIG_PM:

   http://www.spinics.net/lists/arm-kernel/msg118067.html

His patch has also been folded into this one to avoid breaking
!CONFIG_PM builds.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Shweta Gulati <shweta.gulati@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
2011-03-10 22:17:45 -07:00
Menon, Nishanth
eb05ead90d OMAP3|4: OPP: make omapx_opp_init non-static
omap3 and omap4 opp_init should be made non-static to allow
for platform specific opp table tweaking. making these static
conflicts with the definition in pm.h(global) as well.
we include pm.h as well to ensure that there are no such prototype
conflicts with actual implementation in the future.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-03-09 16:15:49 -08:00
Nishanth Menon
fd1478cd61 omap: opp: add OMAP3 OPP table data and common init
Add OPP data for OMAP34xx and OMAP36xx and initialization functions
to populate OPP tables based on current SoC.
introduce an OMAP generic opp initialization routine which OMAP3
and OMAP4+ SoCs can use to register their OPP definitions.

Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-21 14:30:40 -08:00