Asynchronous Fsync: initial extraction of Async Fsync from HTC

Signed-off-by: Paul Reioux <reioux@gmail.com>

Conflicts:
	fs/sync.c
	include/linux/fs.h
accidently added during merge
cflags
cflags
ARM: smp: Save CPU registers before IPI_CPU_STOP processing (faux123)
 ARM: OMAP2+: PRCM: Clear reset sources after boot

According to TRMs the reset source flags have to be cleared by
software, in another case the flags stay after reboot. So clear
them to avoid the flag gathering.

Change-Id: Ia4a5dadd67a2459f6b644d629768d7d51a365efb
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com
ext4: Add support for FIDTRIM, a best-effort ioctl for deep discard trim

* What
This provides an interface for issuing an FITRIM which uses the
secure discard instead of just a discard.
Only the eMMC command is "secure", and not how the FS uses it:
due to the fact that the FS might reassign a region somewhere else,
the original deleted data will not be affected by the "trim" which only
handles un-used regions.
So we'll just call it "deep discard", and note that this is a
"best effort" cleanup.

* Why
Once in a while, We want to be able to cleanup most of the unused blocks
after erasing a bunch of files.
We don't want to constantly secure-discard via a mount option.

From an eMMC spec perspective, it tells the device to really get rid of
all the data for the specified blocks and not just put them back into the
pool of free ones (unlike the normal TRIM). The eMMC spec says the
secure trim handling must make sure the data (and metadata) is not available
anymore. A simple TRIM doesn't clear the data, it just puts blocks in the
free pool.
JEDEC Standard No. 84-A441
  7.6.9 Secure Erase
  7.6.10 Secure Trim

From an FS perspective, it is acceptable to leave some data behind.
 - directory entries related to deleted files
 - databases entries related to deleted files
 - small-file data stored in inode extents
 - blocks held by the FS waiting to be re-used (mitigated by sync).
 - blocks reassigned by the FS prior to FIDTRIM.

Change-Id: I676a1404a80130d93930c84898360f2e6fb2f81e
Signed-off-by: Geremy Condra <gcondra@google.com>
Signed-off-by: JP Abgrall <jpa@google.com>

Backported to linux-3.0 by arter97
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
mmc: Disregard pending irqs in sdio

Change-Id: Iae57a9f04f5bcf5100ea532948a88e449f8f5621
Signed-off-by: Andrei F <luxneb@gmail.com>
ARM: OMAP2+: Fix parser-bug in platform muxing code

commit c021f241f4fab2bb4fc4120a38a828a03dd3f970 upstream.

Fix a parser-bug in the omap2 muxing code where muxtable-entries will be
wrongly selected if the requested muxname is a *prefix* of their
m0-entry and they have a matching mN-entry. Fix by additionally checking
that the length of the m0_entry is equal.

For example muxing of "dss_data2.dss_data2" on omap32xx will fail
because the prefix "dss_data2" will match the mux-entries "dss_data2" as
well as "dss_data20", with the suffix "dss_data2" matching m0 (for
dss_data2) and m4 (for dss_data20). Thus both are recognized as signal
path candidates:

Relevant muxentries from mux34xx.c:
        _OMAP3_MUXENTRY(DSS_DATA20, 90,
                "dss_data20", NULL, "mcspi3_somi", "dss_data2",
                "gpio_90", NULL, NULL, "safe_mode"),
        _OMAP3_MUXENTRY(DSS_DATA2, 72,
                "dss_data2", NULL, NULL, NULL,
                "gpio_72", NULL, NULL, "safe_mode"),

This will result in a failure to mux the pin at all:

 _omap_mux_get_by_name: Multiple signal paths (2) for dss_data2.dss_data2

Patch should apply to linus' latest master down to rather old linux-2.6
trees.

Signed-off-by: David R. Piegdon <lkml@p23q.org>
Cc: stable@vger.kernel.org
[tony@atomide.com: updated description to include full description]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
SDIO: Limit speed to the configured value

When reading the supported speed from the card, do not use a value
higher than indicated with the board data.  This is necessary with
the WL1271 TiWi module on the SDIO bus.  Emperically, it is found to
fail when run at the 25MHz it says it supports.

Signed-off-by: Steve Schefter <steve@scheftech.com>
OMAP4: USBTLL: Off mode disconnect workaround (Errata i754)

When resuming from OFF mode, the EHCI controller was performing a reset resume for ports using the TLL interface because the port status was being cleared. This was caused by the host controller not restoring the state of the ID pin in the TLL module correctly. This issue is workarounded by enabling the ID pin pull-up in the TLL (because the EHCI controller is always the host) and disabling ID pin events as these are not required for the TLL connection.

Change-Id: Ibc22d77606e05e4dd138819079028ebcf254039e Signed-off-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
fix false disconnect due to a signal sent to the reading process

- In the current implementation, when a signal is sent to the reading process,
  read is cancelled by calling usb_ep_dequeue, which lead into calling
  acc_complete_out with ECONNRESET, but the current logic treats it as
  disconnection, which makes the device inaccessible until cable is actually
  disconnected.
- The fix calls disconnect only when ESHUTDOWN error is passed.
- If data has already arrived while trying cancelling, the data is marked
  as available, and it will be read out on the next read. This is necessary
  as USB bulk is assumed to guarantee no data loss.

Signed-off-by: keunyoung <keunyoung@google.com>
usb: ehci: fix the host wakeup state machine.

usb: ehci: fix the host wakeup state machine.

Current code enables host clocks and disables immediately
which can have side effects if port status change is not propagated
and clocks are cut, so enable clocks if ports are suspended
in all wakeup paths either from io-pad wakeup or through
bus resume in suspend path.

Change-Id: I5a03fcf46160176289d41cda6574c0c261a13e94
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
Signed-off-by: Ruchika Kharwar <ruchika@ti.com>
OMAPDSS: DISPC: do not lose taps selection

Move taps selection logic before scaling check, so 3- of 5-tap always
get selected, no metter whether we do scaling or not.

Change-Id: I284b29933ca9fd69ae2088f279554dab9a66542c
Signed-off-by: Sergiy Kibrik <sergiy.kibrik@globallogic.com>
sync: allow async waits to be canceled

In order to allow drivers to cleanly handled teardown we need to allow them
to cancel pending async waits.  To do this cleanly, we move allocation of
sync_fence_waiter to the driver calling sync_async_wait().

Change-Id: Ifcd95648be6ec07026d67f810070a4310f099989
Signed-off-by: Erik Gilling <konkers@android.com>
Signed-off-by: Atanas (Tony) Zlatinski <zlatinski@gmail.com>
OMAP4: PM: Fix missed PRCM MPU interrupt events

OMAP PRCM detects events with EDGE sensitivity. Edge sensitivity
requires to clear the interrupt event status bit before acknowledging
the source event.
If the source event is cleared (1) before reseting the interrupt event
status bit (2), then a subsequent source event (i.e edge) between (1)
and (2) would be missed. Then, all the source events would be kept
"masked" until the source event is cleared again.

The bug seen here is that upon two consecutive PRCM interrupt events
from the IO daisy chain source event, the second event is missed if it
occurs before the PRCM interrupt event status is cleared.
Since the IO daisy chain source event has not been acknowledged, the
subseqent events from this source are missed too.

This patch fix the PRCM interrupt handler by acknowledging the interrupt
event status bit before clearing the source event.

Change-Id: I8c43a93c3b6c7c654ddaa262b7c1c3e7385da158
Signed-off-by: Patrick Combes <p-combes@ti.com>
Signed-off-by: Cedric Poignet <c-poignet@ti.com>
OMAP: dmtimer: Fix timer handling logic for non loses_context timers

The use of the enabled flag is currently tightly coupled with the
loses_context flag on the timer struct. This change makes the enabled
flag behave more sanely without consideration of the loses_context flag.

Change-Id: I9d33bb4cc3fd7917ad493adde75cf57cb240b106
Signed-off-by: Jared Suttles <jsuttles@motorola.com>
OMAP4: DVFS: Fix scaling dependent frequencies.

When scaling dependent frequencies down it is observed that the order
in which frequencies are changed is incorrect.  For example, when core
domain changes OPP down from OPP119 to OPP50 the order is:
a) scale L3 freq down to OPP50
b) scale SGX freq down to OPP50
which is wrong.

Frequencies are scaled in order devices are registered in omap dvfs
framework in device list. Devices are inserted to the list in order,
such as dependences are satisfied if scaling frequencies up.

When scaling frequencies down traverse list backwards.

Change-Id: I752bcb264cac12514f358986a906f29ee81ba75e
Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk@ti.com>
OMAP3+: PM: DVFS: Scale dependent domains to existing OPP

Currently dependent domain is scaled to:
 - dependent voltage that is got from voltage dependency table.
 - frequency that is got from OPP found for dependent voltage.

OPP for dependent voltage is found by _volt_to_opp() function
which looks for OPP with equal or _greater_ voltage.
So if there is no OPP with exact voltage (or this OPP is disabled),
then frequency from OPP with higher voltage will be used.

As a result device will run at not supported combination of frequency and voltage.
This may lead to instabilities.

This patch scales dependent domain to a correct voltage-frequency tuple,
by using both frequency and voltage from the matched OPP.

Change-Id: Ieb14be32ce2f6f2971ca0530dd077bb445a7e2f7
Signed-off-by: Taras Kondratiuk <taras@ti.com>
tweak entropy