Revert "more timing ops"

This reverts commit fca6fd87f7706ffffc52945c471a07d81134fece.
Revert "optimize the ram timings more for 466"

This reverts commit 6dcb2d9477ad8c775b4abed01886085e089bb913.
Revert "optimize the ram timing setup"

This reverts commit c8cc480728d1bade21b1b2ec0e36970f1bf8081a.
Revert "update comment freqs+finish custom ram oc V3,ajusted the freq to original ram oc commit with the max topped at 466,hopefully this is decent"

This reverts commit 1fb9e2d4b5ac53fd7ecdc4de41b0e1e4bea3c7ec.
Revert "timing fix"

This reverts commit 51bf25bdc131828343a9e59dda996edaf17f8b00.
Revert "custom ram oc v2,just go to 466 mhz WITHOUT the rest of the omap 4470 stuff,maybe this will relieve the blurry logos"

This reverts commit 108dcb638979839a41fa024f6751f9954b32b646.
start cleanup
end cleanup
Revert "drivers/gpu/pvr/pvr_governor: add sysfs interface for current GPU freqeuncy"

This reverts commit c5d25ca558b7babefc22f4a7538aa8dc2611ba35.
Revert "drivers/gpu/pvr/pvr_governor: fix sysfs to show "powersave" governor"

This reverts commit bac1217854796464fac8e2be64a5ffca8d9e6251.
Revert "drivers/gpu/pvr/pvr_governor: add "powersave" governor as another option"

This reverts commit fb27a87d0ebc8c1c8d245c7ac62ab3ca05cb0367.
Revert "drivers/gpu/pvr/pvr_governor: add sysfs entry to switch governor type"

This reverts commit cf373be9ccd88b0e2432c8cc8fa80e33114ec85c.
Revert "drivers/gpu/pvr/pvr_governor: add a simple PVR GPU governor"

This reverts commit 8bfd2cecfc7bf1fee59bb97fac53093edfb23b17.
config
only overclock the gpu too 384
omap4/sysconfig.h: Set SYS_SGX_CLOCK_SPEED 384
board-omap4panda.c: omap_vwlan_device define but not used
block: fiops ioscheduler core

FIOPS (Fair IOPS) ioscheduler is IOPS based ioscheduler, so only targets
for drive without I/O seek. It's quite similar like CFQ, but the dispatch
decision is made according to IOPS instead of slice.

The algorithm is simple. Drive has a service tree, and each task lives in
the tree. The key into the tree is called vios (virtual I/O). Every request
has vios, which is calculated according to its ioprio, request size and so
on. Task's vios is the sum of vios of all requests it dispatches. FIOPS
always selects task with minimum vios in the service tree and let the task
dispatch request. The dispatched request's vios is then added to the task's
vios and the task is repositioned in the sevice tree.

Unlike CFQ, FIOPS doesn't have separate sync/async queues, because with I/O
less writeback, usually a task can only dispatch either sync or async requests.
Bias read or write request can still be done with read/write scale.

One issue is if workload iodepth is lower than drive queue_depth, IOPS
share of a task might not be strictly according to its priority, request
size and so on. In this case, the drive is in idle actually. Solving the
problem need make drive idle, so impact performance. I believe CFQ isn't
completely fair between tasks in such case too.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>

Conflicts:
	block/Kconfig.iosched
	block/Makefile

Conflicts:
	block/Kconfig.iosched
	block/Makefile

Conflicts:
	block/Kconfig.iosched
	block/Makefile
block: fiops read/write request scale

read/write speed of Flash based storage usually is different. For example,
in my SSD maxium thoughput of read is about 3 times faster than that of
write. Add a scale to differenate read and write. Also add a tunable, so
user can assign different scale for read and write.

By default, the scale is 1:1, which means the scale is a noop.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
block: fiops sync/async scale

CFQ gives 2.5 times more share to sync workload. This matches CFQ.

Note this is different with the read/write scale. We have 3 types of
requests:
1. read
2. sync write
3. write
CFQ doesn't differentitate type 1 and 2, but request cost of 1 and 2
are usually different for flash based storage. So we have both sync/async
and read/write scale here.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>