Revert "dynamic read-ahead from CG"

This reverts commit e7e61ed1393bf43a5f1f51c214d3ef7335f6601a.

Signed-off-by: Dan Trifan <jimsth@gmail.com>
make default readahead size a kernel parameter
From: Nikanth Karthikesan <knikanth@suse.de>

Add new kernel parameter "readahead", which would be used instead of the
value of VM_MAX_READAHEAD. If the parameter is not specified, the default
of 128kb would be used.

CC: Ankit Jain <radical@gmail.com>
CC: Dave Chinner <david@fromorbit.com>
CC: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
Signed-off-by: Nikanth Karthikesan <knikanth@suse.de>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>

Conflicts:
	block/blk-core.c
	include/linux/mm.h
block: urgent request: remove unnecessary urgent marking

An urgent request is marked by the scheduler in rq->cmd_flags with the
REQ_URGENT flag. There is no need to add an additional marking by
the block layer.

Change-Id: I05d5e9539d2f6c1bfa80240b0671db197a5d3b3f
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
modified for Tuna hybrid kernel

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

Conflicts:
	block/blk-core.c
block: urgent request: Update dispatch_urgent in case of requeue/reinsert

The block layer implements a mechanism for verifying that the device
driver won't be notified of an URGENT request if there is already an
URGENT request in flight. This is due to the fact that interrupting an
URGENT request isn't efficient.
This patch fixes the above described mechanism in case the URGENT request
was returned back to the block layer from some reason: by requeue or
reinsert.

CRs-fixed: 473376, 473036, 471736
Change-Id: Ie8b8208230a302d4526068531616984825f1050d
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>

Conflicts:
	block/blk-core.c
block: urgent: Fix dispatching of URGENT mechanism

There are cases when blk_peek_request is called not from blk_fetch_request
thus the URGENT request may be started but the flag q->dispatched_urgent is
not updated.

Change-Id: I4fb588823f1b2949160cbd3907f4729767932e12
CRs-fixed: 471736
CRs-fixed: 473036
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
Linux v3.0.83

This is the 3.0.83 stable release.

Signed-off-by: Dan Trifan <jimsth@gmail.com>
remove GPU governor

no workie right.

Signed-off-by: Dan Trifan <jimsth@gmail.com>
OMAP4: PM: IVA AUTO RET relaxed workaround in idle path

AUTO RET for IVA VDD Cannot be permanently enabled during OFF mode due to
potential race between IVA VDD entering RET and start of Device OFF mode.

It is mandatory to have AUTO RET for IVA VDD exlusive with Devide OFF mode.
In order to avoid lockup in OFF mode sequence, system must ensure IVA
voltage domain transitions straight from stable ON to OFF.

In addition, management of IVA VDD SmartReflex sensor at exit of idle path
may introduce a misalignment between IVA Voltage Controller state and IVA
PRCM voltage FSM based on following identified scenario:

IVA Voltage Controller is woken-up due to SmartReflex management while
IVA PRCM voltage FSM stays in RET in absence of any IVA module wake-up event
(which is not systematic in idle path as opposed to MPU and CORE VDDs being
necessarily woken up with MPU and CORE PDs).

WA involves:
Ensure stable ON-OFF transition for IVA voltage domain during OFF mode sequence.
Ensure VCON and PRCM FSM are kept aligned due to IVA SR handling in idle path.
1) AUTO RET for IVA VDD is enabled entering in idle path, disabled exiting idle
   path and IVA VDD is always woken-up with a SW dummy wakeup.
2) OFF mode is enabled only in Suspend path.
3) AUTO RET for IVA VDD remains disabled in Suspend path (before OFF mode).

REVISIT: Update the patch once proper Errata is out for 44xx.

Benefits:
1) This patch ensures it is possible to gate SYS_CLK during OS-Idle LCD OFF
when all domains are idled, saving up to 2mA at VBAT from external clock buffer.

2) IVA voltage domain is now allowed to scale to Retention during idle which
reduces power consumption on all types of use case allowing extensive use of
idle path (e.g.: Home screen, Page reading). Effects are especially visible
if system uses Smart-Reflex Class 1.5 compared to Class 3 considering the
increased difference of voltage from converged Voltage SR vs Retention voltage.

TODO: quantify the actual savings from IVA-RET with further measurements.

Change-Id: I01f0431f7556f0baf0b5b6b42092cd11c2442f00
Signed-off-by: Cedric Vamour <c-vamour@ti.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>

Conflicts:
	arch/arm/mach-omap2/pm44xx.c

Signed-off-by: Dan Trifan <jimsth@gmail.com>
OMAP4: PM: Program pwrst of each pwdm as per their supported state

Configure next power state of each power domain based on their
supported state. This will be done one time during initialization of
power_setup function. Device can change their power domain state runtime
based on dev latency requirement.
Also, this API will be called during suspend path as well to make sure each power
domain has been configured the right state before entering OFF transition.

Change-Id: I030f2b5df3186cb147e919d9d98dbcdfc75269a8
Signed-off-by: Gilles-Arnaud Bleu-Laine <gilles@ti.com>
Signed-off-by: Girish S G <girishsg@ti.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
OMAP4: PM: Regulator: suspend prepare and finish call.

Before entering suspend configure regulator resource to desired
state.
While resuming from system wide suspend, the  un-connected regulator
resource's are not turned off. By calling regulator_suspend_finish, it
ensures that resources will be gated if the usecount = 0.

Change-Id: I0cff12f24b1c0879fdb27e079baf1c6793f5a1d3
Signed-off-by: Ambresh K <ambresh@ti.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
OMAP4: PM: Re-factor configuring pwrst settings

Refactoring configure_pwrst to allow setting of pwrdm states from init
and suspend path as well.
This takes care of:
- Allow achievable state to be programmed from init and suspend path
- Error if pwrdm state is not set.
- Remove duplication of code.

Change-Id: I1a42566cc83d67b870e9fe1076522ea8ce7ccb4a
Signed-off-by: Girish S G <girishsg@ti.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
OMAP4: PM: Correct powerstates initialization sequence

  During initialization of new powerstate item it
should be added into list before it's configuration.

  Initialization of powerstates skiped for CORE, MPU,
CPU0, CPU1 powerdomains. Current implementation caused
incorrect initialization of powerstate at least for
GFX PWRDM because it masked by CORE PWRDM.

We should add powerstate node to list before it will
been initialized.

Change-Id: I2f9274a9ec951eb9f6b54e104a0e14921b61264e
Signed-off-by: Volodymyr Riazantsev <v.riazantsev@ti.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
OMAP4: PM: fix for "re-factor configuring pwrst setting"

The error has been admitted in merge branch 3ae032677.
The additional source code in function pwrdms_setup(...)
was added in patch "OMAP4: PM: Re-factor configuring pwrst
settings" commitId faa96477.

Change-Id: Ie0d5efbaa41e7b5eab361292d621b8fe98bd69ec
Signed-off-by: Eugen Mandrenko <ievgen.mandrenko@ti.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
OMAP4: PM: setup initial OPP configuration

pm.c setups the initial voltage and frequencies for init devices
on bootup to be careful of invalid device configurations by
custom bootloaders. However, DVFS data structures are not aware
of these - As a result, when doing the first time scale of
a differnt device we could have a following scenario:

At boot - MPU,IVA,Core at OPP100

after pm framework has completed initialization, lets say IVA/AESS
transitions to OPP50, DVFS framework does not have information about
the OPP current frequency/voltage of IVA/MPU and sees that only
IVA is requested, moves the IVA and core to OPP50. This configuration
is invalid as MPU is currently at OPP100 and device should not have
scaled core to OPP50 without looking at OPP100 configuration of
MPU.

To resolve this, we populate the dvfs data structure with the
requisite init devices' frequency configuration by doing a
omap_device_scale.

Change-Id: Ib3048fb7fadec5adabbbcbce56c1ead026953de6
Reported-by: Hemanth V <hemanthv@ti.com>
Tested-by: Akash Choudhari <akashc@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Dan Trifan <jimsth@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>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
OMAP4460: TWL: disable PD on VCORE1 shutdown

When the PREQ goes low, both VCORE1(VDD_CORE) and VDDD_MPU
start transitioning to 0 volt but VCORE1 discharge is faster
than VDD_MPU discharge. This causes reliability concern from
OMAP's perspective. So, we disable  pulldown on VCORE1 to
slow down VDD_CORE discharge to make it comparable to VDD_MPU.

The Pulldown does not impact DVFS transition, and actual
OFF timing is not changed as well.

Change-Id: I707bb4c4ae50b3452304180e6b42db6b2bfdedd9
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>

Conflicts:
	arch/arm/mach-omap2/omap_twl.c

Signed-off-by: Dan Trifan <jimsth@gmail.com>
OMAP4: Enable main inst clock for save to ram.

In HS-devices we must ensure that l3_main_inst
clock is enabled for saveram operation

Change-Id: Id9a5ab013ed99499f0fde89d9251ae5a95a49b45
Signed-off-by: Axel Haslam <axelhaslam@ti.com>
Signed-off-by: Akash Choudhari <akashc@ti.com>
Signed-off-by: Chittim Madhusudan <c-madhu@ti.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
OMAP4: PM: Fix L3INSTR/IVAHD save/restore context logic

The L3INSTR/IVAHD contexts are restored
when MPU is going through both OSWR and OFF states
on HS/EMU devices (not only OFF state).

Change-Id: I516a9e88932485f6d77c529602647f7199fa7212
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
SIOplus: Allow 0ms deadline latency, increase the read speed

Source: previous commit
Signed-off-by: Dan Trifan <jimsth@gmail.com>
LMK: re-added contacts

hopefuly it fixes the sod after a phonecall.

Signed-off-by: Dan Trifan <jimsth@gmail.com>