msm:rq_stats: Register for Cpufreq policy notification

Currently the load of the system is calculated using the max
frequency that is read during startup(It does not get updated
when the policy changes). As a result, the average load of the
system is incorrectly calculated and the system might not bring
the cpus online to manage the additional load. This
reduces the performance of the system.

To fix this issue, register rq_stats to receive cpufreq policy
notifications. Update the policy's max frequency when a
notification is received and use that value to calculate the load.

Change-Id: Icc78e28c736c170e198f723fd96c13dfb2dafe8a
Signed-off-by: Archana Sathyakumar <asathyak@codeaurora.org>
Signed-off-by: Anji Jonnala <anjir@codeaurora.org>

Conflicts:
	arch/arm/mach-msm/msm_rq_stats.c

	modified:   arch/arm/mach-msm/msm_rq_stats.c
cpufreq: Resolve CPUFREQ_NOTIFY issue

When the cpufreq_stat receives the frequency policy notification,
it checks if the frequency table and stats table are present for the cpu.
If both are present, it returns with -EBUSY error to the notification.
Due to this, none of the other registered modules receive this
notification.

If the stat table and sysfs nodes are already created, return 0 instead
of returning EBUSY error.

Change-Id: I1fd4a46e6a65edfc6253c4271288f10912ae2ad7
Signed-off-by: Archana Sathyakumar <asathyak@codeaurora.org>
msm: rq_stats: Fix missing initalization of cur_freq

Initialize cur_freq variable of each online cpu to the current
running cpu clock frequency. This avoids zeroing out the load
calculations until the first notification of the change in CPU
frequency comes in after CPUFREQ governors are intialized.

Also when a non boot cpu is up, update its cur_freq variable.

(cherry picked from commit 1633a48b16614e6b85c047a19ec93867c2ced3b3)

Change-Id: I950686deff02e2339eefae7d09392dda2174a545
CRs-fixed: 446017
Signed-off-by: Venkat Devarasetty <vdevaras@codeaurora.org>
msm_fb: display: do not use ION_IOMMU_UNMAP_DELAYED

Since iommu buffers will be unmapped after two newer commits
had passed, there is no need to request iommu driver to further
delay unmapping an iommu buffer.

Change-Id: I8cf8d406cf509908035d12c9a04f0add12f3c7c7
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
Signed-off-by: Naseer Ahmed <naseer@codeaurora.org>
mms_fb: display: init pipe default configure as solidfill

Initialize mdp pipes default config as solid fill so that
there will have no memory fetch if pipe are staged into
mixer while flush bits are left behind and set at next vsync.
This is will prevent mdp iommu page fault from happening
at address 0x00000000 during resume.

Change-Id: Ide944ec1d069629f1ae2ecd0daf49c69ce2af2eb
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
msm_fb: Remove the extra freelist in display_commit

There is an extra freelist call to unmap IOMMU source buffers
in display_commit for LCDC interface. This is causing IOMMU
page faults during boot up on targets with LCDC interfaces.
Remove this extra freelist call.

Change-Id: I12a905efc82c5b9751acbc5941a66d0b58027509
Signed-off-by: Padmanabhan Komanduru <pkomandu@codeaurora.org>
msm_fb: display: free previous iommu buffer only at overlay_unset

Since wait4dmap is used at pipe_commit, there is possibility that
iommu buffer had been freed before vsync. Iommu page fault will
happen under this situation. Therefore only previous played iommu
buffer can be freed at overlay_unset. However all iommu buffers
are freed at suspend.

CRs-fixed: 440254
Change-Id: I9c3b77de255b74fd608aa28bb0f2277a58e2ba97
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
msm_fb: display: add one more pipe_commit delay before free ion buffer

It is possible that two consective pipe_commits happen within
same vsync period.  This will cause iommu page fault due to an ion buffer
that is being fetched by mdp's pipe is freed. It needs one pipe_commit
delay to free ion buffer to prevent iommu page from happening. Therefore
an extra free stage is needed to empty ion buffer free list.
Also, ION_IOMMU_UNMAP_DELAYED flag is not necessary at mapping of an
ion buffer since one pipe_commit delay had been added.

Change-Id: I340e002e8dc30b6faa0c095ba042eab50e8b7c88
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
Revert "msm_fb: display: free base layer pipe at adb stop"

This reverts commit d6825fb630a6d576b64c58690844d94aef5aecb7.

Conflicts:
	drivers/video/msm/mdp4_overlay.c
	drivers/video/msm/mdp4_overlay_dsi_video.c
	drivers/video/msm/mdp4_overlay_lcdc.c

Change-Id: Iaf77b0672b8b816a4ea34e687420f30ec203ba0d
msm_fb: display: Do a pre-fill to writeback buffers.

When switching mdp operating mode to blt, writeback buffers need
pre-fill. Move the pre-fill code from isr routine to do_blt, where
actual switch to blt mode happens.

CRs-fixed: 471098
Change-Id: I0f845397894c749ac518a1fa605f84cd5fc2ad15
Signed-off-by: Mayank Chopra <makchopra@codeaurora.org>
video: msm: Resolve mismerges

Change-Id: Ic7fe970cfe120fbb7486f8f6ac60501bce1c71a9
msm_fb: display: remove extra dmap irq disable

irq enable and disable need to be called symmetrically.
Remove an extra dmap irq disable call.

Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
Signed-off-by: Naseer Ahmed <naseer@codeaurora.org>
msm_fb: display: Wait for DMAE for external interface (DTV)

When calling FBIOPAN_DISPLAY for external, there is no wait
which results in irregular fps when tested with fbtest.
Enable DMAE wait to wait until DMAE is over thereby fixing
irregular fps shown in fbtest results.

Crs-fixed: 438078
Change-Id: Iff528ccc17a1e4078c8825b35d4778a7d9e40e7f
Signed-off-by: Mayank Chopra <makchopra@codeaurora.org>
msm_fb: display: calculate mdp clock including borderfill pipe

For hdmi case, mdp clock calculation needs including borderfill
pipe to prevent dtv underrun while system is in suspend.

Crs-fixed: 449027
Change-Id: I98789343317d5cfdf1f56e496cecb4dd663c907f
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>