Todd Poynor [Tue, 11 Oct 2005 15:35:40 +0000 (18:35 +0300)]
[PATCH] ARM: OMAP: OMAP730 PM core
A first cut at OMAP730 system suspend/resume. I've only tried keypad
wakeup, which fails to wake up. /proc/interrupts shows no interrupts
from that device, so some P2 keypad fix is needed. But this might be a
start. Could work harder to avoid duplicated/ifdefed code for OMAP16xx
vs. OMAP730.
--- snip ---
OMAP730 PM system suspend/resume core.
Based on code by Dave Peverley, Dirk Behme, a.o.
Signed-off-by: Todd Poynor <tpoynor@mvista.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
[PATCH] ARM: OMAP: Correction for recently pushed arch_reset for omap2.
Attached is a patch which does work. I went ahead and cleaned up the
bypass table entry for PRCM VIII. Before it was using a shared entry
which wasn't quite like a boot reset.
[PATCH] ARM: OMAP: Replace last occurrences of ARCH_OMAP1510 with ARCH_OMAP15XX
The attached patch fixes a problem noticed when compiling the kernel
for the OSK 5912 board using default config:
make omap_osk_5912_defconfig
make uImage
Jarkko Lavinen [Mon, 3 Oct 2005 11:04:15 +0000 (14:04 +0300)]
[PATCH] ARM: OMAP: CMD7 failing on ATP & Transcend MMC cards
I see ATP and Transcend cards failing repeatedly in the card select command
(CMD7) due to illegal instruction after CMD2. Doing an extra status inquiry
when leaving the card identification mode seems to fix this problem.
This bug occured when opening the mmc cover with mounted card inside and
closing the cover again. This will cause detection of any new cards in
the card detection mode and ATP and Transcend cards get confused.
I don't know why only ATP and Transcend have this problem and why
doing status inquiry helps. Status inquiry command CMD13 is neutral
and is claimed to not chnage the card state in the MMC spec.
The order of commands must be CMD13 first, then CMD7. CMD13 fails
also due to illegal instruction error after CMD2 but after this the
card is back to its senses.
If CMD7 is run first, and CMD13 once CMD7 is seen failing, this fails
to bring the card back to its senses. Then the CMD7 fails repeatedly
due to command timeout before and after CMD13.
The attached patch does the extra probing in mmc_setup() during
low clock which is perhaps an overkill. One could do it also in
mmc_rescan() after switching back to higher clock.
Remove warnings:
arch/arm/plat-omap/dsp/dsp_core.c:760: warning: initialization from
incompatible pointer type
arch/arm/plat-omap/dsp/dsp_mem.c:1579: warning: initialization from
incompatible pointer type
Signed-off-by: Dirk Behme <dirk.behme_at_de.bosch.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Make omap-aic23.c compile again:
CC [M] sound/arm/omap-aic23.o
sound/arm/omap-aic23.c: In function snd_omap_aic23_suspend' Signed-off-by: Dirk Behme <dirk.behme_at_de.bosch.com>
If omap-alsa-mixer.c is compiled as module,
CONFIG_SENSORS_TLV320AIC23_MODULE is missing:
CC [M] sound/arm/omap-alsa-mixer.o
sound/arm/omap-alsa-mixer.c: In function SND_OMAP_WRITE'
sound/arm/omap-alsa-mixer.c: In function MIXER_NAME' undeclared (first
use in this function)
sound/arm/omap-alsa-mixer.c:487: error: (Each undeclared identifier is
reported only once
sound/arm/omap-alsa-mixer.c:487: error: for each function it appears in.) Signed-off-by: Dirk Behme <dirk.behme_at_de.bosch.com>
Btw: omap-alsa-mixer.c will not compile if CONFIG_SENSORS_TLV320AIC23 or
CONFIG_SENSORS_TLV320AIC23_MODULE aren't defined. May be this ifdef
should be removed?
Make omapfb_main.c compile again and remove warnings:
CC drivers/video/omap/omapfb_main.o
drivers/video/omap/omapfb_main.c: In function omapfb_suspend'
drivers/video/omap/omapfb_main.c: At top level:
drivers/video/omap/omapfb_main.c:1645: warning: initialization from
incompatible pointer type
drivers/video/omap/omapfb_main.c:1646: warning: initialization from
incompatible pointer type
drivers/video/omap/omapfb_main.c:1702: warning: initialization from
incompatible pointer type
drivers/video/omap/omapfb_main.c:1704: warning: initialization from
incompatible pointer type
drivers/video/omap/omapfb_main.c:1704: warning: initialization from
incompatible pointer type
drivers/video/omap/omapfb_main.c:1705: warning: initialization from
incompatible pointer type
drivers/video/omap/omapfb_main.c:1728: warning: initialization from
incompatible pointer type
[PATCH] m68knommu: optimized local_irq_disable, and platform reboot code
Switch to a space optimized version of local_irq_disable() for ColdFire
platforms. Also add reboot support for the Freescale M5272 platform.
Patch originally submitted by Philippe De Muyter <phdm@macqel.be>.
Add reboot support for the Freescale M523x ColdFire platform. Patch originally
submitted by Jate Sujjavanich.
[PATCH] m68knommu: startup code for the Drangen Engine 68328 based board
Specialized startup code for the 68328 based DragenEngine board.
It doesn't easily fit into the common 68x328 startup code framework.
It doesn't want any of the common hardware setup to be done here.
[PATCH] m68knommu: fix cache actions for ColdFire 5249, 527x and 528x processors
Add better support for flushing the cache's on some ColdFire processors.
The 5249 cache code is now enabled (it was stubbed out), it really is
needed. Add support for the 527x and 528x families - we only use the
simple instruction cache on them.
[NETROM]: Implement G8PZT Circuit reset for NET/ROM
NET/ROM is lacking a connection reset like TCP's RST flag which at times
may result in a connecting having to slowly timing out instead of just being
reset. An earlier attempt to reset the connection by sending a
NR_CONNACK | NR_CHOKE_FLAG transport was inacceptable as it did result in
crashes of BPQ systems. An alternative approach of introducing a new
transport type 7 (NR_RESET) has be implemented several years ago in
Paula Jayne Dowie G8PZT's Xrouter.
Implement NR_RESET for Linux's NET/ROM but like any messing with the state
engine consider this experimental for now and thus control it by a sysctl
(net.netrom.reset) which for the time being defaults to off.
Signed-off-by: Ralf Baechle DL5RB <ralf@linux-mips.org> Signed-off-by: David S. Miller <davem@davemloft.net>
projects / linux-2.6-omap-h63xx.git / log