msm_fb: display: keep borderfill pipe's iommu info

Keep borderfill pipe's iommu info during base layer pipe
swap with original base layer pipe. Otherwise, borderfill
pipe's may contain original base layer pipe's iommu info
which cause iommu page fault due to same iommu buffer is
unmapped two times.

CRs-fixed: 436711
Change-Id: Ibdb792055287283c4449db07c2de2901aa4fe9b6
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
Signed-off-by: Sangani Suryanarayana Raju <csuryan@codeaurora.org>
msm_fb: display: delay commit video tile frame size register

Video tile frame size register is NOT double buffered.
when this register updated, it kicks in immediatly.
During transition from smaller resolution to higher
resolution  it may have possibility that mdp still fetch
from smaller resolution buffer with new higher resolution
frame size. This will cause iommu page fault. This patch
delay commit frame size register until next frame update
if it is necessary.

CRs-fixed: 450126, 461598
Change-Id: I0339100b8b2d76adf2b4b4206d1942effae55e0a
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
Signed-off-by: Sangani Suryanarayana Raju <csuryan@codeaurora.org>
msm_fb: display: fix iommu page fault when iommu buffer freed

There has possibility that pipe commit come very close to next vsync.
This may cause two consecutive pipe_commits happen within same vsync
period which cause iommu page fault when previous iommu buffer is
freed since mdp stil fetching it. Set ION_IOMMU_UNMAP_DELAYED flag
at ion_map_iommu() to add delay un mapping iommu buffer to fix this problem.
Otherwise four buffer mechanism is needed to avoid this problem..
Also ion_unmap_iommu() may take long time to free an ion buffer. Move
mdp4_overlay_iommu_unmap_freelist(mixer) called after stage_commit()
to increase chance to have pipe_commit (up to stage_commit) is completed
within same vsync period
This patch also fix an potential race condition at wait_for_completion
between show_event thread and wait4vsync thread.

Change-Id: I089950ac61c0bd3c4207b8925817577e42fbb258
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
Signed-off-by: Sangani Suryanarayana Raju <csuryan@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>
Signed-off-by: Sangani Suryanarayana Raju <csuryan@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>
Signed-off-by: Sangani Suryanarayana Raju <csuryan@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>
Signed-off-by: Sangani Suryanarayana Raju <csuryan@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>
Signed-off-by: Sangani Suryanarayana Raju <csuryan@codeaurora.org>
msm: scm: Add scm_call_noalloc and helper macros

Currently, scm_call internally calls kmalloc() to allocate a command
buffer structure. This prevents scm_call from working before kmalloc
structures are initialized or during atomic contexts. Allow clients
to pass in a pre-allocated buffer for scm_call to be used for internal
structures.

Change-Id: Id09500c8c696298228aefdcc2a61953e654677c9
CRs-Fixed: 498392
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
arm: Add ARCH_RANDOM Kconfig

Some boards may support architecture generated random numbers. Add
the appropriate Kconfig.

Change-Id: I0077a982c9bb6d3a35435cc27fe40b7e0596ca84
CRs-Fixed: 498392
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
msm: implement ARCH_RANDOM

Currently, the software random number generator is not intialized
until relatively late in the boot process. Software that relies on
random numbers early will not be reliable. Entropy sources are
available early but not early enough for some use cases which means
that moving the software random number generation earlier is not an
option. As an alternate solution, implement the functions associated
with CONFIG_ARCH_RANDOM. These functions currently make a call into
trustzone to get reliable random numbers. The functions are disabled
once the regular random number generator is sufficiently reliable.

Change-Id: If40cfcb96b091fa26a28047c10a902287b26f6c1
CRs-Fixed: 498392
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
init: Move stack canary initialization after setup_arch

Stack canary intialization involves getting a random number.
Getting this random number may involve accessing caches or other
architectural specific features which are not available until
after the architecture is setup. Move the stack canary initialization
later to accomodate this.

Change-Id: I00b564a2c3172229a44339c061fa380c17fe7d8e
CRs-Fixed: 498392
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Merge "msm_fb: display: keep borderfill pipe's iommu info"
Merge "msm_fb: display: delay commit video tile frame size register"
Merge "msm_fb: display: fix iommu page fault when iommu buffer freed"
Merge "msm_fb: display: add one more pipe_commit delay before free ion buffer"
Merge "mms_fb: display: init pipe default configure as solidfill"
Merge "msm_fb: display: free previous iommu buffer only at overlay_unset"
Merge "msm_fb: Remove the extra freelist in display_commit"
Slim_msm: Wait for reconfig sequence to complete

Wait for current reconfiguration to complete during
reconfigure_now sequnce. Earlier we are not waiting
for reconfiguration done interrupt after sending the
reconfiguration message to the slimus hardware. This
may lead to hardware synchronization issues in lower
slimbus clock frequencies.

In this patch we are waiting for the reconfiguration
done interrupt from slimbus hardware.

CRs-Fixed: 490022
Change-Id: If0126dac9a1ad2d931e9a0e345d19559fe36f67a
Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
Merge "Slim_msm: Wait for reconfig sequence to complete"