Several parts of the OMAP2/3 clock code use wmb() to try to ensure
that the hardware write completes before continuing.  This approach is
problematic: wmb() only ensures that the write leaves the ARM.  It
does not ensure that the write actually reaches the endpoint device.
The endpoint device in this case - either the PRM, CM, or SCM - is
three interconnects away from the ARM - and the final interconnect is
low-speed.  And the OCP interconnects will post the write, and who
knows how long that will take to complete.  So the wmb() is not what
we want.  Worse, the wmb() is indiscriminate; it causes the ARM to
flush any other unrelated buffered writes and wait for the local
interconnect to acknowledge them - potentially very expensive.

Fix this by converting the wmb()s into readbacks of the same PRM/CM/SCM
register.  Since the PRM/CM/SCM devices use a single OCP thread, this
will cause the MPU to block while waiting for posted writes to that device
to complete.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Consolidate the commit code for DELAYED_APP clocks into a subroutine,
_omap2xxx_clk_commit().  Also convert the MPU barrier wmb() into an
OCP barrier, since with an MPU barrier, we have no guarantee that the
write actually reached the endpoint device.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

clk_disable() previously used an ARM barrier, wmb(), to try to ensure
that the hardware write completed before continuing.  There are some
problems with this approach.

The first problem is that wmb() only ensures that the write leaves the
ARM -- not that it actually reaches the endpoint device.  In this
case, the endpoint device - either the PRM, CM, or SCM - is three
interconnects away from the ARM, and the final interconnect is
low-speed.  And the OCP interconnects will post the write, who knows
how long that will take to complete.  So the wmb() is not really what
we want.

Worse, the wmb() is indiscriminate; it will cause the ARM to flush any
other unrelated buffered writes and wait for the local interconnect to
acknowledge them - potentially very expensive.

This first problem could be fixed by doing a readback of the same PRM/CM/SCM
register.  Since these devices use a single OCP thread, this will cause the
MPU to wait for the write to complete.

But the primary problem is a conceptual one: clk_disable() should not
need any kind of barrier.  clk_enable() needs one since device driver
code must not access a device until its clocks are known to be
enabled.  But clk_disable() has no such restriction.

Since blocking the MPU on a PRM/CM/SCM write can be a very
high-latency operation - several hundred MPU cycles - it's worth
avoiding this barrier if possible.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

... to eliminate unnecessary padding.  We have rather a lot of these
structures, so eliminating unnecessary padding results in a saving of
1488 bytes.

[paul@pwsan.com: updated against current linux-omap clock tree, now saves
1512 bytes on OMAP3 builds]
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

clk->owner is always NULL, so its existence doesn't serve any useful
function other than bloating the kernel by 992 bytes.  Remove it.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

The CONFIG_PARTICIPANT flags indicates to the clock rate and parent
changing functions that they should not be used on this clock.  Better
just to remove the clock function pointers that operate on those
clocks.  The name of the flag is just terrible: its meaning has almost
nothing to do with its name, and the use of the CONFIG_ prefix makes
it appear to be a Kconfig option.  Get rid of it.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Nothing tests the clock flags for this bit, so it serves no purpose.
Remove it.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

The RATE_FIXED flag currently has no useful purpose.  Fixed rate clocks
should simply not implement the recalc, set_rate, set_parent, and round_rate
function pointers.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Now that clocks keep track of their children, the RATE_PROPAGATES flag
is no longer necessary.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Track child clocks for each struct clk.  This optimizes traversals of the
clock tree from parent to child, which happens during rate propagation, and
in the future, clock notifiers.

Previously, parent-to-child traversals sequentially scanned the entire
clock list at each step to determine the children of a particular
clock node.  Now each struct clk maintains a clock list of its
children.  For a DPLL3_M2_CK rate change, this converts what were
about O(6*180*2) operations into O(6*6*2) operations.  The savings
will be even more significant after the future notifier patches:
something like O(6*180*6) to O(6*6*6).

The price paid is additional runtime memory consumption - 8 bytes per
clock and 16 bytes per child clock - roughly 4.5KiB on OMAP3.  The
memory comes mostly from bootmem, since initial clock registration
takes place before slab is ready.  Several other operations will take
slightly more time due the extra bookkeeping: clk_register(),
clk_unregister(), clk_set_parent(), and omap2_init_clksel_parent().
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

For upcoming notifier support, modify the rate recalculation code to
take parent rate and rate storage parameters.  The goal here is to
allow the clock code to determine what the clock's rate would be after
a parent change or a rate change, without actually changing the
hardware registers.  This is used by the upcoming notifier patches to
pass a clock's current and planned rates to the notifier callbacks.

Also add a new clock flag, RECALC_ON_ENABLE, which causes the clock
framework code to recalculate the current clock's rate and propagate
down the tree after a clk_enable() or clk_disable().  This is used by
the OMAP3 DPLLs, which change rates when they enable or disable, unlike
most clocks.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Now that rate recalculation and rate propagation are two separate
operations, drop recalc function pointers from all fixed rate clocks.
Their rates are fixed, so there's no need to recalculate.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Previously the individual clock recalculation functions handled their
own rate recalculation.  This can be handled in the clk_set_rate(),
clk_set_parent(), and recalculate_root_clocks() functions in
plat-omap/clock.c.  Removes duplicate code and clarifies the role of the
recalc functions.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Use the standard clk_set_rate() function in omap2_clk_arch_init()
rather than omap2_select_table_rate() -- this will ensure that clock
rates are recalculated and propagated correctly after those operations
are consolidated into clk_set_rate().
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Removed duplicated #include's in arch/arm/mach-omap1/board-voiceblue.c
Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Fix compile by removing remaining omap specific gpio
calls. Based on earlier patches by Jarkko Nikula.
Signed-off-by: Jarkko Nikula <jarkko.nikula@nokia.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Also change the dependency to ARCH_OMAPP2430 || ARCH_OMAP3.
Based on comments by David Brownell.
Signed-off-by: Tony Lindgren <tony@atomide.com>

The bus voltage was being reset to 3V even if card was not
removed. Move the reset code to happen after slot has been
powered down. Also clean-up for checkpatch.
Signed-off-by: Tony Lindgren <tony@atomide.com>

We should not set it in mmc_omap_detect, as that does not necessarily
tell that card got removed. Reset the voltage back to 3V after powering
off the slot instead.
Signed-off-by: Tony Lindgren <tony@atomide.com>

Merge branches 'master' and 'linus'

Happy holidays..

* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6:
  V4L/DVB (9920): em28xx: fix NULL pointer dereference in call to VIDIOC_INT_RESET command
  V4L/DVB (9908a): MAINTAINERS: mark linux-uvc-devel as subscribers only
  V4L/DVB (9906): v4l2-compat: test for unlocked_ioctl as well.
  V4L/DVB (9885): drivers/media Kconfig's: fix bugzilla #12204
  V4L/DVB (9875): gspca - main: Fix vidioc_s_jpegcomp locking.
  V4L/DVB (9781): [PATCH] Cablestar 2 I2C retries (fix CableStar2 support)
  V4L/DVB (9780): dib0700: Stop repeating after user stops pushing button

Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip

* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  x86: disable X86_PTRACE_BTS

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6:
  ALSA: hda - Add missing terminators in patch_sigmatel.c

Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Cc: stable@kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>

there's a new ptrace arch level feature in .28:

  config X86_PTRACE_BTS
  bool "Branch Trace Store"

it has broken fork() handling: the old DS area gets copied over into
a new task without clearing it.

Fixes exist but they came too late:

  c5dee617: x86, bts: memory accounting
  bf53de90: x86, bts: add fork and exit handling

and are queued up for v2.6.29. This shows that the facility is still not
tested well enough to release into a stable kernel - disable it for now and
reactivate in .29. In .29 the hardware-branch-tracer will use the DS/BTS
facilities too - hopefully resulting in better code.
Signed-off-by: Ingo Molnar <mingo@elte.hu>

flush_tlb_mm's "optimized" uniprocessor case of allocating a new
context for userspace is exposing a race where we can suddely return
to a syscall with the protection id and space id out of sync, trapping
on the next userspace access.
Debugged-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Tested-by: Helge Deller <deller@gmx.de>
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
  drm/radeon: fix correctness of irq_enabled check for radeon.

When deleting an edac device, we have to wait for its edac_dev.work to be
completed before deleting the whole edac_dev structure.  Since we have no
idea which work in current edac_poller's workqueue is the work we are
conerned about, we wait for all work in the edac_poller's workqueue to be
proceseed.  This is done via flush_cpu_workqueue() which inserts a
wq_barrier into the tail of the workqueue and then sleeping on the
completion of this wq_barrier.  The edac_poller will wake up sleepers when
it is found.

EDAC core creates only one kernel worker thread, edac_poller, to run the
works of all current edac devices.  They share the same callback function
of edac_device_workq_function(), which would grab the mutex of
device_ctls_mutex first before it checks the device.  This is exactly
where edac_poller and rmmod would have a great chance to deadlock.

In below call trace of rmmod > ... >
edac_device_del_device >
edac_device_workq_teardown > flush_workqueue > flush_cpu_workqueue,

device_ctls_mutex would have already been grabbed by
edac_device_del_device().  So, on one hand rmmod would sleep on the
completion of a wq_barrier, holding device_ctls_mutex; on the other hand
edac_poller would be blocked on the same mutex when it's running any one
of works of existing edac evices(Note, this edac_dev.work is likely to be
totally irrelevant to the one that is being removed right now)and never
would have a chance to run the work of above wq_barrier to wake rmmod up.

edac_device_workq_teardown() should not be called within the critical
region of device_ctls_mutex.  Just like is done in edac_pci_del_device()
and edac_mc_del_mc(), where edac_pci_workq_teardown() and
edac_mc_workq_teardown() are called after related mutex are released.

Moreover, an edac_dev.work should check first if it is being removed.  If
this is the case, then it should bail out immediately.  Since not all of
existing edac devices are to be removed, this "shutting flag" should be
contained to edac device being removed.  The current edac_dev.op_state can
be used to serve this purpose.

The original deadlock problem and the solution have been witnessed and
tested on actual hardware.  Without the solution, rmmod an edac driver
would result in below deadlock:

root@localhost:/root> rmmod mv64x60_edac
EDAC DEBUG: mv64x60_dma_err_remove()
EDAC DEBUG: edac_device_del_device()
EDAC DEBUG: find_edac_device_by_dev()

(hang for a moment)

INFO: task edac-poller:2030 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
edac-poller   D 00000000     0  2030      2
Call Trace:
[df159dc0] [c0071e3c] free_hot_cold_page+0x17c/0x304 (unreliable)
[df159e80] [c000a024] __switch_to+0x6c/0xa0
[df159ea0] [c03587d8] schedule+0x2f4/0x4d8
[df159f00] [c03598a8] __mutex_lock_slowpath+0xa0/0x174
[df159f40] [e1030434] edac_device_workq_function+0x28/0xd8 [edac_core]
[df159f60] [c003beb4] run_workqueue+0x114/0x218
[df159f90] [c003c674] worker_thread+0x5c/0xc8
[df159fd0] [c004106c] kthread+0x5c/0xa0
[df159ff0] [c0013538] original_kernel_thread+0x44/0x60
INFO: task rmmod:2062 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
rmmod         D 0ff2c9fc     0  2062   1839
Call Trace:
[df119c00] [c0437a74] 0xc0437a74 (unreliable)
[df119cc0] [c000a024] __switch_to+0x6c/0xa0
[df119ce0] [c03587d8] schedule+0x2f4/0x4d8
[df119d40] [c03591dc] schedule_timeout+0xb0/0xf4
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

If cgroup_get_rootdir() failed, free_cg_links() will be called in the
failure path, but tmp_cg_links hasn't been initialized at that time.

I introduced this bug in the 2.6.27 merge window.
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Cc: Paul Menage <menage@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Remove spurious warning messages that are thrown onto the console during
cgroup operations.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Sharyathi Nagesh <sharyathi@in.ibm.com>
Acked-by: Serge E. Hallyn <serge@hallyn.com>
Cc: Paul Menage <menage@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

During test of the w1-gpio driver i found that in "w1.c:679
w1_slave_found()" the device id is converted to little-endian with
"cpu_to_le64()", but its not converted back to cpu format in "w1_io.c:293
w1_reset_select_slave()".

Based on a patch created by Andreas Hummel.

[akpm@linux-foundation.org: remove unneeded cast]
Reported-by: Andreas Hummel <andi_hummel@gmx.de>
Signed-off-by: Evgeniy Polyakov <zbr@ioremap.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

This patch for the rtc-isl1208 driver makes it reject invalid dates.
Signed-off-by: Chris Elston <celston@katalix.com>
[a.zummo@towertech.it: added comment explaining the check]
Signed-off-by: Alessandro Zummo <a.zummo@towertech.it>
Cc: Hebert Valerio Riedel <hvr@gnu.org>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Fix recent build breakage.  Boot-tested on N800.

  CC      arch/arm/mach-omap2/devices.o
arch/arm/mach-omap2/devices.c:110: error: 'OMAP34XX_MAILBOX_BASE' undeclared here (not in a function)
arch/arm/mach-omap2/devices.c:115: error: 'INT_34XX_MAIL_U0_MPU' undeclared here (not in a function)
make[1]: *** [arch/arm/mach-omap2/devices.o] Error 1
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Also remove "change vdd back to 3V" in omap_mmc_remove() as it
seems unnecessary. If it's a hw workaround, we can add it back
as needed.
Signed-off-by: Tony Lindgren <tony@atomide.com>

Fix a NULL pointer dereference that would occur if the video decoder tied to
the em28xx supports the VIDIOC_INT_RESET call (for example: the cx25840 driver)
Signed-off-by: Devin Heitmueller <dheitmueller@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

This check was introduced with the logic the wrong way around.

Fixes regression: http://bugzilla.kernel.org/show_bug.cgi?id=12216Tested-by: François Valenduc <francois.valenduc@tvcablenet.be>
Signed-off-by: Dave Airlie <airlied@redhat.com>

* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6:
  ACPI: don't cond_resched() when irqs_disabled()
  ACPI: fix 2.6.28 acpi.debug_level regression

* git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6:
  drivers/ide/{cs5530.c,sc1200.c}: Move a dereference below a NULL test