Fixed MMC DMA writes on 15xx

Skip reset check for DSP domain clocks as they need api_ck

Make 24xx timer check source clock instead of hardcoded value

Fix compile error in 16xx camera driver
Signed-off-by: Todd Poynor <tpoynor@mvista.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

1610-only LOW_PWR pin muxing only on 1610
Signed-off-by: Todd Poynor <tpoynor@mvista.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

OMAP MUX: dump stack on invalid requests if CONFIG_DEBUG_ERROR,
to show what code made the bad request.
Signed-off-by: Todd Poynor <tpoynor@mvista.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

It should be 0x3, not 0x2

Turns out the problem was not in consistent_sync(), but blockops.c
overriding the the dmac_ functions with buggy ones... Undo previous
commit a9a31cc4, and remove blockops.c
from Makefile until it's completely removed from mainline kernel.

Errors with largers and reads turned out not be cache issues, but
a bug in consistent_sync() instead. After fixing consistent_sync()
DMA transfers on 24xx MMC work fine.

It looks like consistent_sync() is off by one on arm as the dmac
functions are being called with start and end instead of start and length.

Also posted to linux-arm-kernel mailing list:

http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2005-November/032037.html

This patch adds support for 24xx MMC DMA. Since looks like
large reads and writes cause some cache problems, the dma
feature is still disabled for 24xx with use_dma = 0;

Make 24xx dma callback status work

This patch modifies omap dma.c to add support for 24xx.
Functionality should be the same as earlier.

Signed-off-by: Imre Deak <imre.deak@nokia.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Signed-off-by: Imre Deak <imre.deak@nokia.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Signed-off-by: Imre Deak <imre.deak@nokia.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

It does not seem to be respond at all?

I put together this basic OMAP2 identification code, since I would need
to distinguish between 2410 and 2420.

The second patch makes an attempt to fix up places where
cpu_is_omap2420() is used, replacing them with the newly introduced more
type specific macros. These are based on comments in the code.

Change DMA interface to allow adding 24xx DMA support. Note that this
interface will change again after the 24xx DMA support has been merged.

Add cpu_class_is_omap1() and cpu_class_is_omap2() macros

"Better late than never"

Don't try to access not-present CPUs.  Conservative governor will always
oops on SMP without this fix.

Fixes http://bugzilla.kernel.org/show_bug.cgi?id=4781Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Commit id 6142891a

Andi Kleen reports that it seems to break things for some people,
and since it's purely a small optimization, revert it for now.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

I forgot that the fbconsole code is using a palette even though we
are in true color mode, so we have to handle that case separately.

all unnecessary clocks at the loader caught this.

The BURST_4 is 2 instead of 1

OMAP: Add 24xx DMA irq defines

This bug is responsible for causing the infamous "Treason uncloaked"
messages that's been popping up everywhere since the printk was added.
It has usually been blamed on foreign operating systems.  However,
some of those reports implicate Linux as both systems are running
Linux or the TCP connection is going across the loopback interface.

In fact, there really is a bug in the Linux TCP header prediction code
that's been there since at least 2.1.8.  This bug was tracked down with
help from Dale Blount.

The effect of this bug ranges from harmless "Treason uncloaked"
messages to hung/aborted TCP connections.  The details of the bug
and fix is as follows.

When snd_wnd is updated, we only update pred_flags if
tcp_fast_path_check succeeds.  When it fails (for example,
when our rcvbuf is used up), we will leave pred_flags with
an out-of-date snd_wnd value.

When the out-of-date pred_flags happens to match the next incoming
packet we will again hit the fast path and use the current snd_wnd
which will be wrong.

In the case of the treason messages, it just happens that the snd_wnd
cached in pred_flags is zero while tp->snd_wnd is non-zero.  Therefore
when a zero-window packet comes in we incorrectly conclude that the
window is non-zero.

In fact if the peer continues to send us zero-window pure ACKs we
will continue making the same mistake.  It's only when the peer
transmits a zero-window packet with data attached that we get a
chance to snap out of it.  This is what triggers the treason
message at the next retransmit timeout.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>

This just makes sure that a thread's expiry times can't get reset after
it clears them in do_exit.

This is what allowed us to re-introduce the stricter BUG_ON() check in
a362f463.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This reverts commit 3de463c7.

Roland has another patch that allows us to leave the BUG_ON() in place
by just making sure that the condition it tests for really is always
true.

That goes in next.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

There's a silly off-by-one error in the code that updates the expiration
of posix CPU timers, causing them to not be properly updated when they
hit exactly on their expiration time (which should be the normal case).

This causes them to then fire immediately again, and only _then_ get
properly updated.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Pointed out by Oleg Nesterov, who has been walking over the code
forwards and backwards.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

I've seen similar failure on alpha.

Obviously, someone forgot to convert sg->handle stuff for
PCI gart case.
Signed-off-by: Dave Airlie <airlied@linux.ie>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Convert nanoseconds to microseconds correctly.

Spotted by Steve Dickson <SteveD@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

fsck_hfs reveals lots of temporary files accumulating in the hidden
directory "\000\000\000HFS+ Private Data".  According to the HFS+
documentation these are files which are unlinked while in use.  However,
there may be a bug in the Linux hfsplus implementation which causes this to
happen even when the files are not in use.  It looks like the "opencnt"
field is never initialized as (I think) it should be in hfsplus_read_inode.
 This means that a file can appear to be still in use when in fact it has
been closed.  This patch seems to fix it for me.
Signed-off-by: Anton Altaparmakov <aia21@cantab.net>
Cc: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Although this message is having the intended effect of causing wireless
driver maintainers to upgrade their code, I never should have merged this
patch in its present form.  Leading to tons of bug reports and unhappy
users.

Some wireless apps poll for statistics regularly, which leads to a printk()
every single time they ask for stats.  That's a little bit _too_ much of a
reminder that the driver is using an old API.

Change this to printing out the message once, per kernel boot.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>