Anand Gadiyar [Fri, 22 Oct 2010 18:15:16 +0000 (11:15 -0700)]
omap: complete removal of machine_desc.io_pg_offst and .phys_io
Commit ab69bcd66fb4be64edfc767365cb9eb084961246 (arm: remove
machine_desc.io_pg_offst and .phys_io) could not update
the new boards in the omap tree. This causes the build of
omap2plus_defconfig to fail. Fix this.
Signed-off-by: Anand Gadiyar <gadiyar@ti.com> Cc: Nicolas Pitre <nicolas.pitre@linaro.org> Cc: Eric Miao <eric.miao at canonical.com>
[tony@atomide.com: updated description] Signed-off-by: Tony Lindgren <tony@atomide.com>
Kevin Hilman [Wed, 20 Oct 2010 23:19:03 +0000 (23:19 +0000)]
omap: UART: fix wakeup registers for OMAP24xx UART2
On OMAP24xx, UART2 WKEN and WKST registers are in PM_WKEN2_CORE and
PM_WKST2_CORE respecitvely. Fix the OMAP2 register init to use the
correct registers on OMAP24xx.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Anand Gadiyar [Tue, 12 Oct 2010 13:27:58 +0000 (13:27 +0000)]
ASoC: OMAP4: MCPDM: Remove unnecessary include of plat/control.h
Commit 346a5c890 (OMAP: control: move plat-omap/control.h
to mach-omap2/control.h) in the linux-omap tree removed
plat/control.h and most of its callers. This one slipped
through - breaking the build as below when
CONFIG_SND_OMAP_SOC_MCPDM is defined. Fix this.
CC sound/soc/omap/omap-mcpdm.o
sound/soc/omap/omap-mcpdm.c:35: fatal error: plat/control.h: No such file or directory
compilation terminated.
make[3]: *** [sound/soc/omap/omap-mcpdm.o] Error 1
make[2]: *** [sound/soc/omap] Error 2
make[1]: *** [sound/soc] Error 2
make: *** [sound] Error 2
Signed-off-by: Anand Gadiyar <gadiyar@ti.com> Cc: Misael Lopez Cruz <misael.lopez@ti.com> Cc: Liam Girdwood <lrg@slimlogic.co.uk> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Paul Walmsley <paul@pwsan.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Jarkko Nikula <jhnikula@gmail.com> Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Peter Ujfalusi [Mon, 11 Oct 2010 21:18:56 +0000 (14:18 -0700)]
OMAP3: DMA: Errata i541: sDMA FIFO draining does not finish
Implement the suggested workaround for OMAP3 regarding to sDMA draining
issue, when the channel is disabled on the fly.
This errata affects the following configuration:
sDMA transfer is source synchronized
Buffering is enabled
SmartStandby is selected.
The issue can be easily reproduced by creating overrun situation while
recording audio.
Either introduce load to the CPU:
nice -19 arecord -D hw:0 -M -B 10000 -F 5000 -f dat > /dev/null & \
dd if=/dev/urandom of=/dev/null
or suspending the arecord, and resuming it:
arecord -D hw:0 -M -B 10000 -F 5000 -f dat > /dev/null
CTRL+Z; fg; CTRL+Z; fg; ...
In case of overrun audio stops DMA, and restarts it (without reseting
the sDMA channel). When we hit this errata in stop case (sDMA drain did
not complete), at the coming start the sDMA will not going to be
operational (it is still draining).
This leads to DMA stall condition.
On OMAP3 we can recover with sDMA channel reset, it has been observed
that by introducing unrelated sDMA activity might also help (reading
from MMC for example).
The same errata exists for OMAP2, where the suggestion is to disable the
buffering to avoid this type of error.
On OMAP3 the suggestion is to set sDMA to NoStandby before disabling
the channel, and wait for the drain to finish, than configure sDMA to
SmartStandby again.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@nokia.com> Acked-by: Jarkko Nikula <jhnikula@gmail.com>
Acked-by : Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by : Manjunath Kondaiah G <manjugk@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Jarkko Nikula [Mon, 11 Oct 2010 21:18:45 +0000 (14:18 -0700)]
omap: dma: Fix buffering disable bit setting for omap24xx
An errata workaround for omap24xx is not setting the buffering disable bit
25 what is the purpose but channel enable bit 7 instead.
Background for this fix is the DMA stalling issue with ASoC omap-mcbsp
driver. Peter Ujfalusi <peter.ujfalusi@nokia.com> has found an issue in
recording that the DMA stall could happen if there were a buffer overrun
detected by ALSA and the DMA was stopped and restarted due that. This
problem is known to occur on both OMAP2420 and OMAP3. It can recover on
OMAP3 after dma free, dma request and reconfiguration cycle. However, on
OMAP2420 it seems that only way to recover is a reset.
Problem was not visible before the commit c12abc0. That commit changed that
the McBSP transmitter/receiver is released from reset only when needed. That
is, only enabled McBSP transmitter without transmission was able to prevent
this DMA stall problem in receiving side and underlying problem did not show
up until now. McBSP transmitter itself seems to no be reason since DMA
stall does not recover by enabling the transmission after stall.
Debugging showed that there were a DMA write active during DMA stop time and
it never completed even when restarting the DMA. Experimenting showed that
the DMA buffering disable bit could be used to avoid stalling when using
source synchronized transfers. However that could have performance hit and
OMAP3 TRM states that buffering disable is not allowed for destination
synchronized transfers so subsequent patch will implement a method to
complete DMA writes when stopping.
This patch is based on assumtion that complete lock-up on OMAP2420 is
different but related problem. I don't have access to OMAP2420 errata but
I believe this old workaround here is put for a reason but unfortunately
a wrong bit was typed and problem showed up only now.
Signed-off-by: Jarkko Nikula <jhnikula@gmail.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@nokia.com> Acked-by: Manjunath Kondaiah G <manjugk@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2. OMAP4 does a kernel PANIC
-------------------------------------
[ 0.000000] Calibrating delay loop... 1195.29 BogoMIPS (lpj=4669440)
[ 0.000000] pid_max: default: 32768 minimum: 301
[ 0.000000] Security Framework initialized
[ 0.000000] Mount-cache hash table entries: 512
[ 0.000000] CPU: Testing write buffer coherency: ok
[ 0.000000] L310 cache controller enabled
[ 0.000000] l2x0: 16 ways, CACHE_ID 0x410000c2, AUX_CTRL 0x0e050000
[ 0.000000] CPU1: Booted secondary processor
[ 0.000000] Brought up 2 CPUs
[ 0.000000] SMP: Total of 2 processors activated (2395.78 BogoMIPS).
[ 0.000000] regulator: core version 0.5
[ 0.000000] NET: Registered protocol family 16
[ 0.000000] mux: Could not set signal i2c2_scl.i2c2_scl
[ 0.000000] mux: Could not set signal i2c2_sda.i2c2_sda
[ 0.000000] mux: Could not set signal i2c3_scl.i2c3_scl
[ 0.000000] mux: Could not set signal i2c3_sda.i2c3_sda
[ 0.000000] mux: Could not set signal i2c4_scl.i2c4_scl
[ 0.000000] mux: Could not set signal i2c4_sda.i2c4_sda
-------------------------------------
This is happening because 'omap_serial_init()' is hanging in the boot.
On OMAP3 the watchdog is generating reboot because devices_init doesn't
happens where as on OMAP4 it just hangs without reboot.
The uart clock is not getting enabled after omap_device_idle as part
of omap_serial_init.
The omap_device_idle(will disable the clock) then omap_uart_block_sleep()
should enable clock back disabled during the boot up phase.
But omap_uart_block_sleep() stuffed version is binded only under
CONFIG_PM and other version is just empty. Hence it is not enabling
clock back as expected
This patch adds uart clock enable code to omap_uart_block_sleep() function
built with CONFIG_PM disabled.
Thanks to Charulatha and Govindraj for their help on this debug.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Charulatha V <charu@ti.com> Signed-off-by: Govindraj.R <govindraj.raja@ti.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Kevin Hilman [Fri, 8 Oct 2010 22:43:45 +0000 (22:43 +0000)]
OMAP3: PM: fix scratchpad memory accesses for off-mode
Commit 914bab936fe0388a529079679e2f137aa4ff548d (OMAP: mach-omap2: Fix
incorrect assignment warnings) changed a pointer from 'u32 *' to
'void *' without also fixing up the pointer arithmetic.
Fix the scratchpad offsets so they are byte offsets instead of
word offsets and thus work correctly with a void pointer base.
Special thanks to Jean Pihet for taking the time track down this
problem and propose an initial solution.
Tested with off-idle and off-suspend on 36xx/Zoom3 and 34xx/omap3evm.
Cc: Manjunath Kondaiah G <manjugk@ti.com> Reported-by: Jean Pihet <jean.pihet@newoldbits.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Jean Pihet <jean.pihet@newoldbits.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
David Anders [Thu, 7 Oct 2010 19:36:30 +0000 (19:36 +0000)]
omap4: pandaboard: enable the ehci port on pandaboard
The OMAP4 PandaBoard has EHCI port1 hooked up to an external
SMSC3320 transciever. GPIO 1 is used to power on the transceiver
and GPIO 62 for reset on the transceiver.
Signed-off-by: David Anders <x0132446@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Jarkko Nikula [Fri, 8 Oct 2010 17:40:21 +0000 (11:40 -0600)]
OMAP: McBSP: Swap CLKS source definition
This is just a readability and debugging improvement. As selection bit in
DEVCONF register is cleared when using 96 MHz PRCM source and set when using
external CLKS pin, change definitions to be sync with these.
Signed-off-by: Jarkko Nikula <jhnikula@gmail.com> Acked-by: Paul Walmsley <paul@pwsan.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Paul Walmsley [Fri, 8 Oct 2010 17:40:20 +0000 (11:40 -0600)]
OMAP2+: clock: reduce the amount of standard debugging while disabling unused clocks
Reduce the amount of debugging generated by default when unused clocks
are being disabled by the clock code. The previous code would only
generate debug-level messages, but some people who wished to run
production kernels with debug-level messages enabled reported that the
large number of clock disable messages were slowing boot. Now to
enable clock-by-clock disable messages, DEBUG needs to be defined in
mach-omap2/clock.c.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tuukka Tikkanen <tuukka.tikkanen@nokia.com> Cc: Tim Bird <tim.bird@am.sony.com>
Paul Walmsley [Fri, 8 Oct 2010 17:40:20 +0000 (11:40 -0600)]
OMAP: control: move plat-omap/control.h to mach-omap2/control.h
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>
Paul Walmsley [Fri, 8 Oct 2010 17:40:19 +0000 (11:40 -0600)]
OMAP: split plat-omap/common.c
Split plat-omap/common.c into three pieces:
1. the 32KiHz sync timer and clocksource code, which now lives in
plat-omap/counter_32k.c;
2. the OMAP2+ common code, which has been moved to mach-omap2/common.c;
3. and the remainder of the OMAP-wide common code, which includes the
deprecated ATAGs code and a deprecated video RAM reservation function.
The primary motivation for doing this is to move the OMAP2+-specific parts
into an OMAP2+-specific file, so that build breakage related to the
System Control Module code can be resolved.
Benoît Cousson <b-cousson@ti.com> suggested a new filename and found
some bugs in the counter_32k.c comments - thanks Benoît.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
Paul Walmsley [Fri, 8 Oct 2010 17:40:19 +0000 (11:40 -0600)]
OMAP: McBSP: implement functional clock switching via clock framework
Previously the OMAP McBSP ASoC driver implemented CLKS switching by
using omap_ctrl_{read,write}l() directly. This is against policy; the OMAP
System Control Module functions are not intended to be exported to drivers.
These symbols are no longer exported, so as a result, the OMAP McBSP ASoC
driver does not build as a module.
Resolve the CLKS clock changing portion of this problem by creating a
clock parent changing function that lives in
arch/arm/mach-omap2/mcbsp.c, and modify the ASoC driver to use it.
Due to the unfortunate way that McBSP support is implemented in ASoC
and the OMAP tree, this symbol must be exported for use by
sound/soc/omap/omap-mcbsp.c.
Going forward, the McBSP device driver should be moved from
arch/arm/*omap* into drivers/ or sound/soc/* and the CPU DAI driver
should be implemented as a platform_driver as many other ASoC CPU DAI
drivers are. These two steps should resolve many of the layering
problems, which will rapidly reappear during a McBSP hwmod/PM runtime
conversions.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Acked-by: Jarkko Nikula <jhnikula@gmail.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@nokia.com> Acked-by: Liam Girdwood <lrg@slimlogic.co.uk> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Paul Walmsley [Fri, 8 Oct 2010 17:40:19 +0000 (11:40 -0600)]
OMAP: McBSP: implement McBSP CLKR and FSR signal muxing via mach-omap2/mcbsp.c
The OMAP ASoC McBSP code implemented CLKR and FSR signal muxing via
direct System Control Module writes on OMAP2+. This required the
omap_ctrl_{read,write}l() functions to be exported, which is against
policy: the only code that should call those functions directly is
OMAP core code, not device drivers. omap_ctrl_{read,write}*() are no
longer exported, so the driver no longer builds as a module.
Fix the pinmuxing part of the problem by removing calls to
omap_ctrl_{read,write}l() from the OMAP ASoC McBSP code and
implementing signal muxing functions in arch/arm/mach-omap2/mcbsp.c.
Due to the unfortunate way that McBSP support is implemented in ASoC
and the OMAP tree, these symbols must be exported for use by
sound/soc/omap/omap-mcbsp.c.
Going forward, the McBSP device driver should be moved from
arch/arm/*omap* into drivers/ or sound/soc/*, and the CPU DAI driver
should be implemented as a platform_driver as many other ASoC CPU DAI
drivers are. These two steps should resolve many of the layering
problems, which will rapidly reappear during a McBSP hwmod/PM runtime
conversion.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Acked-by: Jarkko Nikula <jhnikula@gmail.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@nokia.com> Acked-by: Liam Girdwood <lrg@slimlogic.co.uk> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Paul Walmsley [Fri, 8 Oct 2010 17:40:18 +0000 (11:40 -0600)]
OMAP3xxx: clock: add clkdev aliases for McBSP fclk source switching
The OMAP3 clock tree already contains the infrastructure to support
clock framework-based McBSP functional clock source switching. But it
did not contain the clkdev aliases for the McBSP code to refer to the
parent clocks in an SoC integration-neutral way. So, add the clkdev
aliases for the parent clocks.
Paul Walmsley [Fri, 8 Oct 2010 17:40:18 +0000 (11:40 -0600)]
OMAP2430: clock: add MCBSP_CLKS node and clkdev aliases
Add the MCBSP_CLKS clock and the clksel structures needed to support clock
framework-based source switching for McBSPs 1-5. Also, add clkdev
aliases on the parent clocks for the McBSP source switching code, added
in a subsequent patch.
Paul Walmsley [Fri, 8 Oct 2010 17:40:17 +0000 (11:40 -0600)]
OMAP2420: clock: add MCBSP_CLKS node and clkdev aliases
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.
Paul Walmsley [Fri, 8 Oct 2010 17:40:17 +0000 (11:40 -0600)]
OMAP2420: CTRL: fix OMAP242X_CTRL_REGADDR macro
Conform the OMAP2420_CTRL_BASE macro name to the standard of the rest of the
OMAP*_CTRL_BASE macro names. This fixes a bug in the OMAP2420 SCM code that
prevented OMAP242X_CTRL_REGADDR from working.
Paul Walmsley [Fri, 8 Oct 2010 17:40:17 +0000 (11:40 -0600)]
OMAP2+: Kconfig: disallow builds for boards that don't use the currently-selected SoC
Currently, if, for example, CONFIG_ARCH_OMAP2420 is not selected, OMAP2420
board files can still be included in the build. This results in link errors:
arch/arm/mach-omap2/built-in.o: In function `omap_generic_map_io':
.../arch/arm/mach-omap2/board-generic.c:51: undefined reference to `omap2_set_globals_242x'
arch/arm/mach-omap2/built-in.o: In function `omap_h4_init':
.../arch/arm/mach-omap2/board-h4.c:330: undefined reference to `omap2420_mux_init'
arch/arm/mach-omap2/built-in.o: In function `omap_h4_map_io':
.../arch/arm/mach-omap2/board-h4.c:373: undefined reference to `omap2_set_globals_242x'
arch/arm/mach-omap2/built-in.o: In function `omap_apollon_init':
.../arch/arm/mach-omap2/board-apollon.c:325: undefined reference to `omap2420_mux_init'
arch/arm/mach-omap2/built-in.o: In function `omap_apollon_map_io':
.../arch/arm/mach-omap2/board-apollon.c:353: undefined reference to `omap2_set_globals_242x'
make: *** [.tmp_vmlinux1] Error 1
Fix this by making the boards depend on the Kconfig option for the
specific SoC that they use.
Also, while here, fix the mach-omap2/board-generic.c file to remove the
dependency on OMAP2420.
Charulatha Varadarajan <charu@ti.com> caught a typo - thanks Charu.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Charulatha Varadarajan <charu@ti.com>
Tony Lindgren [Fri, 8 Oct 2010 17:23:44 +0000 (10:23 -0700)]
omap: Update omap2plus_defconfig to use ttyO instead ttyS
With the omap-serial the device has changed from ttyS to ttyO as
the system may have both omap-serial and 8250 ports.
Note that systems using omap-serial need to be updated to use ttyO[012]
instead of ttyS[012] in the bootloader, CONFIG_CMDLINE, /etc/inittab,
and the root file system with mknod. Also you may need to add ttyO[012]
to /etc/securetty.
Kevin Hilman [Fri, 8 Oct 2010 17:23:32 +0000 (10:23 -0700)]
OMAP2: PM: check UART status before trying to idle
As is done on OMAP3, check omap_uart_can_sleep() as one of the
pre-conditions for entering the idle loop. Without this check,
entering idle introduces large latencies on active UARTs, and is
especially noticable on serial console.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Charulatha V [Fri, 8 Oct 2010 17:23:06 +0000 (10:23 -0700)]
OMAP2PLUS: WDT: Fix: Disable WDT after reset during init
Inorder to avoid any assumptions from bootloader, the watchdog
timer module is reset during init. This enables the watchdog
timer.
Therefore, it is required to disable WDT after it is reset
during init. Otherwise the system would reboot as per the default
watchdog timer registers settings.
Later, when the watchdog driver is loaded, the watchdog timer settings
is adjusted as per the default timer_margin set in the driver and the
driver would supports the normal operations supported by OMAP watchdog
timer.
Signed-off-by: Charulatha V <charu@ti.com> Reported-by: Kevin Hilman <khilman@deeprootsystems.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
omap3: fix and improve the LED handling on IGEP v2 board
The IGEP v2 board has four leds, this patch allows control all
of these LEDs using the LED class if CONFIG_LEDS_GPIO is selected
or using the General Purpose Input/Output (GPIO) interface if
CONFIG_LEDS_GPIO is not selected.
Signed-off-by: Enric Balletbo i Serra <eballetbo@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
omap3: Add external VBUS power switch and overcurrent detect onIGEP v2 board
GPIO for various devices are missing from the board initialization.
This patch adds support for the VBUS and over current gpios. Without this
patch, input/outputs from these two sources are ignored.
Signed-off-by: Enric Balletbo i Serra <eballetbo@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
The OMAP3 IGEP module is a low-power, high performance production-ready
system-on-module (SOM) based on TI's OMAP3 family. More about this
board at www.igep.es.
Signed-off-by: Enric Balletbo i Serra <eballetbo@gmail.com>
[tony@atomide.com: updated for the mmc changes and to be selected by default] Signed-off-by: Tony Lindgren <tony@atomide.com>
This patch fixes sparse warnings due non declarations of static functions.
arch/arm/plat-omap/sram.c:130:13: warning: symbol 'omap_detect_sram' was not declared. Should it be static?
arch/arm/plat-omap/sram.c:216:13: warning: symbol 'omap_map_sram' was not declared. Should it be static?
arch/arm/plat-omap/sram.c:450:12: warning: symbol 'omap_sram_init' was not declared. Should it be static?
arch/arm/plat-omap/sram.c:348:12: warning: symbol 'omap242x_sram_init' was not declared. Should it be static?
arch/arm/plat-omap/sram.c:369:12: warning: symbol 'omap243x_sram_init' was not declared. Should it be static?
arch/arm/plat-omap/sram.c:425:12: warning: symbol 'omap34xx_sram_init' was not declared. Should it be static?
arch/arm/plat-omap/sram.c:441:12: warning: symbol 'omap44xx_sram_init' was not declared. Should it be static
arch/arm/plat-omap/mcbsp.c:36:6: warning: symbol 'omap_mcbsp_write' was not declared. Should it be static?
arch/arm/plat-omap/mcbsp.c:50:5: warning: symbol 'omap_mcbsp_read' was not declared. Should it be static?
arch/arm/plat-omap/mcbsp.c:65:6: warning: symbol 'omap_mcbsp_st_write' was not declared. Should it be static?
arch/arm/plat-omap/mcbsp.c:70:5: warning: symbol 'omap_mcbsp_st_read' was not declared. Should it be static?
arch/arm/plat-omap/mcbsp.c:1648:15: warning: symbol 'omap_st_add' was not declared. Should it be static?
arch/arm/plat-omap/fb.c:414:15: warning: symbol 'omapfb_reserve_sram' was not declared. Should it be static?
arch/arm/plat-omap/cpu-omap.c:43:5: warning: symbol 'omap_verify_speed' was not declared. Should it be static?
arch/arm/plat-omap/cpu-omap.c:61:14: warning: symbol 'omap_getspeed' was not declared. Should it be static?
Signed-off-by: Manjunath Kondaiah G <manjugk@ti.com> Cc: linux-arm-kernel@lists.infradead.org Cc: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
This patch fixes sparse warnings due non declarations of static functions.
arch/arm/mach-omap2/timer-gp.c:115:12: warning: symbol 'omap2_gp_clockevent_set_gptimer' was not declared. Should it be static?
arch/arm/mach-omap2/powerdomain.c:993:5: warning: symbol 'pwrdm_set_lowpwrstchange' was not declared. Should it be static?
arch/arm/mach-omap2/board-flash.c:141:8: warning: symbol 'board_nand_init' was not declared. Should it be static?
arch/arm/mach-omap2/board-n8x0.c:416:6: warning: symbol 'n8x0_mmc_slot1_cover_handler' was not declared. Should it be static?
arch/arm/mach-omap2/board-n8x0.c:544:13: warning: symbol 'n8x0_mmc_init' was not declared. Should it be static?
arch/arm/mach-omap2/board-rx51-peripherals.c:902:13: warning: symbol 'rx51_peripherals_init' was not declared. Should it be static?
arch/arm/mach-omap2/board-rx51-video.c:107:13: warning: symbol 'rx51_video_mem_init' was not declared. Should it be static?
arch/arm/mach-omap2/board-zoom-debugboard.c:155:12: warning: symbol 'zoom_debugboard_init' was not declared. Should it be static?
arch/arm/mach-omap2/board-zoom-peripherals.c:280:13: warning: symbol 'zoom_peripherals_init' was not declared. Should it be static?
arch/arm/mach-omap2/board-igep0020.c:110:13: warning: symbol 'igep2_flash_init' was not declared. Should it be static?
arch/arm/mach-omap2/board-am3517evm.c:109:6: warning: symbol 'am3517_evm_ethernet_init' was not declared. Should it be static?
drivers/mtd/onenand/omap2.c:577:5: warning: symbol 'omap2_onenand_rephase' was not declared. Should it be static?
Signed-off-by: Manjunath Kondaiah G <manjugk@ti.com> Cc: linux-arm-kernel@lists.infradead.org Cc: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
This patch fixes sparse warnings due to non declaration of
static structures and variables.
Sparse warning logs fixed:
arch/arm/mach-omap2/control.c:88:6: warning: symbol 'omap3_secure_ram_storage' was not declared. Should it be static?
n
arch/arm/mach-omap2/timer-gp.c:50:22: warning: symbol 'gptimer_wakeup' was not declared. Should it be static?
arch/arm/mach-omap2/timer-gp.c:240:18: warning: symbol 'omap_timer' was not declared. Should it be static?
arch/arm/mach-omap2/prcm.c:121:24: warning: symbol 'prcm_context' was not declared. Should it be static?
arch/arm/mach-omap2/mux2420.c:510:29: warning: symbol 'omap2420_pop_ball' was not declared. Should it be static?
arch/arm/mach-omap2/mux2430.c:589:29: warning: symbol 'omap2430_pop_ball' was not declared. Should it be static?
arch/arm/mach-omap2/mux34xx.c:934:28: warning: symbol 'omap3_cus_subset' was not declared. Should it be static?
arch/arm/mach-omap2/mux34xx.c:1080:29: warning: symbol 'omap3_cus_ball' was not declared. Should it be static?
arch/arm/mach-omap2/mux34xx.c:1272:28: warning: symbol 'omap3_cbb_subset' was not declared. Should it be static?
arch/arm/mach-omap2/mux34xx.c:1393:29: warning: symbol 'omap3_cbb_ball' was not declared. Should it be static?
arch/arm/mach-omap2/mux34xx.c:1603:28: warning: symbol 'omap36xx_cbp_subset' was not declared. Should it be static?
arch/arm/mach-omap2/mux34xx.c:1821:29: warning: symbol 'omap36xx_cbp_ball' was not declared. Should it be static?
arch/arm/mach-omap2/pm-debug.c:165:15: warning: symbol 'pm_dbg_dir' was not declared. Should it be static?
arch/arm/mach-omap2/board-omap3evm.c:587:30: warning: symbol 'ads7846_config' was not declared. Should it be static?
arch/arm/mach-omap2/board-omap3evm.c:606:23: warning: symbol 'omap3evm_spi_board_info' was not declared. Should it be static?
arch/arm/mach-omap2/board-rx51-sdram.c:46:25: warning: symbol 'rx51_sdrc_params' was not declared. Should it be static?
arch/arm/mach-omap2/board-rx51-sdram.c:211:25: warning: symbol 'rx51_get_sdram_timings' was not declared. Should it be static?
arch/arm/mach-omap2/board-omap3touchbook.c:64:15: warning: symbol 'touchbook_revision' was not declared. Should it be static?
arch/arm/mach-omap2/board-am3517evm.c:350:24: warning: symbol 'am3517_evm_dss_device' was not declared. Should it be static?
arch/arm/mach-omap2/board-omap3stalker.c:567:23: warning: symbol 'omap3stalker_spi_board_info' was not declared. Should it be static?
Signed-off-by: Manjunath Kondaiah G <manjugk@ti.com> Cc: linux-arm-kernel@lists.infradead.org Cc: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
OMAP1: Amstrad Delta: add camera controlled LEDS trigger
This patch extends the Amstrad Delta camera support with LEDS trigger that can
be used for automatic control of the on-board camera LED. The led turns on
automatically on camera device open and turns off on camera device close.
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: Tony Lindgren <tony@atomide.com>
This patch adds configuration data and initialization code required for camera
support to the Amstrad Delta board.
Three devices are declared: SoC camera, OMAP1 camera interface and OV6650
sensor.
Default 12MHz clock has been selected for driving the sensor. Pixel clock has
been limited to get reasonable frame rates, not exceeding the board
capabilities. Since both devices (interface and sensor) support both pixel
clock polarities, decision on polarity selection has been left to drivers.
Interface GPIO line has been found not functional, thus not configured.
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: Tony Lindgren <tony@atomide.com>
This patch adds a definition of the OMAP1 camera interface platform device,
and a function that allows for providing a board specific platform data.
The device will be used with the upcoming OMAP1 SoC camera interface driver.
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: Tony Lindgren <tony@atomide.com>
omap4 hsmmc: Update ocr mask for MMC2 for regulator to use
On OMAP4, MMC2 controller has eMMC which draws power from VAUX regulator
on TWL. Though the eMMC supports dual voltage[1.8v/3v] as per ocr register,
its VCC is fixed at 3V for operation. With this once the mmc core selects
the minimum voltage[1.8] supported based on the ocr value read from OCR register,
eMMC will not get detected. Thus the platform data for MMC2 is updated with ocr
mask and same will be communicated to core which will set the regulator to
always operate at 3V when ever turned ON.
Cc: Tony Lindgren <tony@atomide.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Madhusudhan Chikkature <madhu.cr@ti.com> Cc: Adrian Hunter <adrian.hunter@nokia.com> Signed-off-by: Kishore Kadiyala <kishore.kadiyala@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
In OMAP4, as per new PM programming model, the legacy registers
which were there in OMAP3 are all shifted by 0x100 while new one's
are added from offset 0 to 0x10.
For OMAP4, the register offset appending of 0x100 done in devices.c
currently, is moved to driver file.This change fits in for current
implementation as well as once the driver undergoes hwmod adaptation.
Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Madhusudhan Chikkature <madhu.cr@ti.com> Cc: Adrian Hunter <adrian.hunter@nokia.com> Cc: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Kishore Kadiyala <kishore.kadiyala@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
The omap4 es2 hsmmc has a updated soft reset logic.After the
reset is issued monitor a 0->1 transition first. The reset of
CMD or DATA lines is complete only after a 0->1->0 transition
of SRC or SRD bits.
Instead of enabling the wifi module explicitly using GPIO, add a fixed
regulator and hook it to MMC host card power control. This way it will
only be enabled when SDIO subsystem wants to talk to it, saving power
(as done by Zoom boards).
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
OMAP: PM: Fix build when CONFIG_PM_DEBUG isn't set
Since 6cdee91257bee23a46dc869ca62469b67cba2c7e the references to
enable_off_mode and sleep_while_idle can't be resolved when CONFIG_PM_DEBUG
isn't set:
arch/arm/mach-omap2/built-in.o: In function `omap_uart_restore_context':
arch/arm/mach-omap2/serial.c:253: undefined reference to `enable_off_mode'
arch/arm/mach-omap2/built-in.o: In function `omap3_can_sleep':
arch/arm/mach-omap2/pm34xx.c:479: undefined reference to `sleep_while_idle'
Simply #define these in pm.h just like omap2_pm_debug.
Signed-off-by: Loïc Minier <loic.minier@linaro.org>
[khilman: moved down into existing #ifdef section] Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Kevin Hilman [Fri, 1 Oct 2010 15:35:47 +0000 (08:35 -0700)]
OMAP3: CPUidle: remove redundant setting of PER next power state
When checking how to program the next powerstate for the PER
powerdomain, the next state of PER powerdomain was written twice.
Remove the duplicate write.
Reported-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
OMAP3: SERIAL: Initialize all omap-uarts for zoom boards
Initialize all omap-uarts for zoom boards. Now zoom_peripheral_init
will initialise all uarts for 3630. 3630sdp_board_init call
zoom_peripheral_init so we can now remove serial_init from 3630sdp
board init as zoom_peripheral_init now will do that the same.
OMAP: SERIAL: Enable omap-serial driver in Kconfig
Enable omap-serial driver in /mach-omap2/Kconfig and
move 8250 driver selection for zoom boards. With omap-serial
driver addition all omap-uarts can be handled with
omap-serial driver.
With addition of omap-serial driver console parameter
needs be changed in bootargs from ttyS* should be
replaced with ttyO* [O --> OMAP not ZERO]
For example: ttyS0[UART1 on 3430SDP] changes to ttyO0.
But with some boards that do not use omap-uart as console uart.
we need to handle them with 8250 driver. Ex: ZOOM2/3.
For zoom2/3 board we need to use 8250 serial driver and
console parameter will remain ttyS0 which basically uses
a Quad uart placed on the debug board connected through a
gpio line.
Signed-off-by: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
This patch adds driver support for OMAP2/3/4 high speed UART.
The driver is made separate from 8250 driver as we cannot
over load 8250 driver with omap platform specific configuration for
features like DMA, it makes easier to implement features like DMA and
hardware flow control and software flow control configuration with
this driver as required for the omap-platform.
This patch involves only the core driver and its dependent.
Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Govindraj.R <govindraj.raja@ti.com> Acked-by: Alan Cox <alan@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Major rework of OMAP UART init for omap_device conversion as well as
use with either 8250 driver or new omap-serial driver.
In preparation for a new omap-serial driver, remove 8250 assumptions
and dependencies from the serial core.
Convert UART core and PM support to use omap_device layer. Also add
support for both console on 8250 or omap-serial driver.
omap_device conversion:
- Convert clock API calls to omap_device calls
- Remove all static platform_data setup and configuration. This is
all done by the omap_device build phase.
Signed-off-by: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
OMAP: WDT: Use PM runtime APIs instead of clk FW APIs
Call runtime pm APIs pm_runtime_put_sync() and pm_runtime_get_sync()
for enabling/disabling the clocks, sysconfig settings instead of using
clock FW APIs.
Signed-off-by: Charulatha V <charu@ti.com> Acked-by: Cousson, Benoit <b-cousson@ti.com> Acked-by: Wim Van Sebroeck <wim@iguana.be> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Kevin Hilman [Tue, 28 Sep 2010 19:07:29 +0000 (19:07 +0000)]
OMAP2+: defconfig: modularize bluetooth, audio and WLAN
In working towards a smaller default kernel, only devices used for
early boot should be built in. Toward that end, build the following
as modules by default:
Tim Nordell [Mon, 27 Sep 2010 16:05:48 +0000 (16:05 +0000)]
ARM: OMAP3LOGIC: Adding SDMMC support
Add low-level initialization for hsmmc controller for
LogicPD's OMAP 3530 LV SOM and OMAP 35x Torpedo board.
Signed-off-by: Tim Nordell <tim.nordell@logicpd.com>
[tony@atomide.com: updated for the recent mmc platform init changes] Signed-off-by: Tony Lindgren <tony@atomide.com>
Jon Hunter [Mon, 27 Sep 2010 20:02:59 +0000 (14:02 -0600)]
omap3: Prevent SDRC deadlock when L3 is changing frequency
When changing the L3 clock frequency, the CPU is executing from internal RAM
and the SDRC clock is disabled. During this time accesses made to external
DDR are stalled. If the ARM subsystem attempts to access the DDR while the
SDRC clock is disabled this will stall the CPU until the access to the SDRC
timeouts. A timeout on the SDRC should never occur. Once a timeout occurs all
the following accesses will be aborted and the DDR is no longer accessible.
Although the code being executed in the internal RAM does not directly access
the DDR, it was found that the branch prediction logic in the CPU may cause
the CPU to prefetch code from a DDR location while the SDRC clock is disabled.
This was causing an SDRC timeout which resulted in a system hang.
This patch fixes this problem by ensuring the branch prediction logic is
disabled while changing the L3 clock frequency. The branch prediction logic
is disabled by clearing the Z-bit in the ARM CTRL register.
Disabling the branch prediction logic does not have any noticable impact
on the execution time of this code section. The hardware observability
signals were used to monitor the sdrc idle time with and without this
patch when operating at different CPU frequencies (150MHz, 500MHz and
600MHz) and the total sdrc idle time when changing frequenct was in
the range of 9-11us. This was measured on an omap3430 SDP running the
omapzoom p-android-omap-2.6.29 branch.
Signed-off-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com> Cc: Tony Lindgren <tony@atomide.com>
omap4: control: Fix the control module register accesses
This patch has multiple fixes together. To ensure that git bisect work across
commits, all changes are clubbed together
1. Move the common control base address to control core
2. Remove the manually coeded defines and use the ones from headers.
3. Fix the the status register define in id.c for OMAP4
4. Fix all the register define in hsmmc.c
5. Use the control pad accessor API for omap4 hsmmc register accesses
omap4: control: Add the register definition headers
On OMAP4, control module is divided into 4 separate IPs
- OMAP44XX_CTRL_MODULE_CORE
- OMAP44XX_CTRL_MODULE_PAD_CORE
- OMAP44XX_CTRL_MODULE_WKUP
- OMAP44XX_CTRL_MODULE_PAD_WKUP
This patch adds all the omap4 control module register data and
includes them in the common control.h
The register data is autogenerated from the codebase thanks
to Benoit Cousson efforts
omap4: control: Add accessor api's for pad control module
On OMAP4 control pad are not addressable from control
core base. So the common omap_ctrl_read/write APIs breaks
Hence export separate APIs to manage the omap4 pad control
registers.
This APIs will work only for OMAP4
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
On omap4 control module is divided in four IP blocks.
- CTRL_MODULE_CORE 0x4a002000
- CTRL_MODULE_PAD_CORE 0x4a100000
- CTRL_MODULE_WKUP 0x4a30c000
- CTRL_MODULE_PAD_WKUP 0x4a31e000
Addressing all the modules with single base address is not possible
considering 16 bit offsets. The mux code manages the pad core and pad
wakeup related base address inside the mux framework. For other usage
only control core and control pad bases are necessary. So this patch
maps only needed pad control base address which is used by device drivers
and infrastructure code
The main control core base is still kept same in this patch to
keep git-bisect working. This will be fixed in the relevant patch
in this series.
projects / mv-sheeva.git / log