Revert "msm: mdss: only pass display state to lcd notifier call_chain"

This reverts commit 2c457d5d197ce99a24aa34eaf97f9ede717c9363.
Revert "msm: mdss: Adding lcd notifier"

This reverts commit 4d037ead603d179ecd4694625c970f9a04398807.

Conflicts:
	drivers/video/msm/mdss/Makefile
msm: vidc: Increase I-frame period to INT_MAX

There is no restriction on I-frame and IDR period
values, so set them to INT_MAX.

Change-Id: I364ead16c3b8b8463fc8180159e5ee1f9fa10f37
Signed-off-by: Arun Menon <avmenon@codeaurora.org>
msm: mdss: Backport MDSS doze mode feature

msm: mdss: add support for different panel power states

Currently a panel either be in a powered on state or a powered off
state. However, it is possible for panels to be configured in an
intermediate low-power state where the panel is always kept on. In
order to support such use-cases, it is necessary to add the concept
of panel power states in MDSS so that each software layer can
independently maintain it's state and manage transitions between them.
This change just refactors the driver with only two existing power
states - panel on and panel off.

Change-Id: I49d1fda506761546c5e22d9106c5177e75053a81
Signed-off-by: Aravind Venkateswaran <aravindh@codeaurora.org>

msm: mdss: add support for display always on mode

Add a new panel power state to represent a panel low power mode. Add a
new sysfs node to control when to configure the panel into this new
mode.

Change-Id: I7df8bf63470bec893c6b7481678f00ce76b6875c
Signed-off-by: Aravind Venkateswaran <aravindh@codeaurora.org>

msm: mdss: use helper functions to check for panel power state

Whenever the display always-on feature is enabled, it is possible
that the display pipeline can be in an intermediate state between being
fully interactive to fully turned off. In the current implementation, a
number of state transition decisions are made based on whether the
display pipeline is on or not. Instead of explicitly checking for the
panel power state, define generic helper functions which classify the
panel power state into three different stages - interactive, low-power
and off. Replace any existing check for the panel power state with these
newly defined helper functions.

Change-Id: I4d6dd883ea6aca8abd57fa048a79e0c88da09a95
Signed-off-by: Aravind Venkateswaran <aravindh@codeaurora.org>

msm: mdss: support transition from suspend to doze mode

If a transition from full suspend to doze mode is requested, first
unblank the panel and then enter the doze mode. This is necessary
to ensure that all necessary panel supplies are turned on and the
panel is brought out of reset first.

Change-Id: I5757f01ec9843a332fd2d1034c068ff993f466bd
Signed-off-by: Aravind Venkateswaran <aravindh@codeaurora.org>

msm: mdss: fix race condition between commit thread and power off

There is a deadlock in use cases where the power off
is called concurrently with the overlay kickoff from
different threads. To avoid this condition, during
power off sequence we first make sure to stop the
fb display thread before the power off sequence is
handled.

Change-Id: I708143206b914f6f72c440c4dc3a1c73fceea6b2
Signed-off-by: Ingrid Gallardo <ingridg@codeaurora.org>

msm: mdss: fix issues related to transitions in and out of doze mode

When entering doze mode, ensure that the tear-check setup is not
torn down. In addition, do not disable the split-display configuration.
This is to ensure that mdss driver can continue to handle any display
updates in doze mode. Similarly, when transitioning from doze power
state to blank power state, ensure that we do not send panel unblank and
panel on events. These events should only be sent when transitioning to
unblank power state.

Change-Id: If5ca1cdd20bb442e773912575c0a6e204c0ca1a2
Signed-off-by: Aravind Venkateswaran <aravindh@codeaurora.org>

msm: mdss: fix transitions from off to doze mode

When doze mode is requested while the panel in powered off, the
panel needs to be first unblanked and then configured into low power
mode. While this sequence exists in the current implementation,
the execution sequence only calls MDP's on function while unblanking
the panel. The correct approach is to go through the full unblank
sequence which would also start the display commit thread. Without
this, screen updates while in doze mode will not work and could
lead to unexpected behaviors.

Change-Id: I4f65764acaf01d61d129e00179930af9ebb79c77
Signed-off-by: Aravind Venkateswaran <aravindh@codeaurora.org>

msm: mdss: Do not release all fences when going to doze mode

UI may update in doze mode and there may be tearing when going
from doze to unblank - with respect to synchronization, doze mode
must be treated as on.

Change-Id: I8635b0722bc6294f6850ab28ce43046f81ed49a5
Signed-off-by: Naseer Ahmed <naseer@codeaurora.org>

msm: mdss: do not turn off interface clocks for doze mode

When entering doze mode, do not turn off the interface clocks since
display updates are expected in this mode. This also avoid unnecessary
delays when entering doze mode while trying to wait for the clocks to be
turned off.

Change-Id: Ie6658a561f5d49aff50881c561fef858f3d26c61
Signed-off-by: Aravind Venkateswaran <aravindh@codeaurora.org>

msm: mdss: unblank panel when entering doze mode for video mode panels

For video mode panels, MDSS hardware needs to be on as long as the
panel is on. When doze mode is requested for a video mode panel,
no special optimizations can be done in the display driver to
configure the hardware in a low power state. As such, when doze mode is
requested for video mode panels, simply unblank the panel if it is not
already on.

Change-Id: I0f279d78b9b5c8eebb2bf654df628acafa408f23
Signed-off-by: Aravind Venkateswaran <aravindh@codeaurora.org>

msm: mdss: synchronize command mode intf stop

In dual DSI case, both interfaces need to finish before the panel is
turned off. In order to make sure these are synchronized, both
interfaces need to be stopped before sending blank/off events to panel
driver.

Change-Id: Ie5bcf5ce53515a5c02696c7be1665c3330be0417
Signed-off-by: Adrian Salido-Moreno <adrianm@codeaurora.org>

msm: mdss: fix watchdog bite due to ping-pong timeout log flooding

Most likely root cause of ping-pong timeouts is a pipeline hang in the
display controller. These pipeline hangs can happen due to bad frame
configuration and if this bad configuration persists every frame then
ping-pong timeouts will flood the console with warning logs and may lead
to watchdog bite. Fix this by reporting ping-pong timeout only once
every bad configuration.

Change-Id: I1dc7a729f10e70e2bed947dd72713c0adfe96942
Signed-off-by: Ujwal Patel <ujwalp@codeaurora.org>

msm: mdss: refactor ping pong completion logic

Replace completion structures with waitq and track the completion of
ping pong transfer with a single kickoff count variable. This prevents
race conditions when using completion structure and provides a cleaner
way to identify whether wait is required.

CRs-Fixed: 720541
Change-Id: Iebb8077d520649db427470fc4963d892967a920c
Signed-off-by: Adrian Salido-Moreno <adrianm@codeaurora.org>

mdss: display: move mdss_mdp_irq_enable out of clk_lock scope

There are potential deadlock between irq handler and
mdss_mdp_irq_enable() since both can acquire mdss_lock
before trying to grab local lock. Add koff_lock for kickoff
related function in addition to original clk_lock which used
for clock related function to reduce unnecessary lock contention.

CRs-Fixed: 665524
Change-Id: Iebc5023eb9dc99f2a2709379bfac67ec275046a7
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
msm: mdss: fix fb device pm suspend and resume handlers

Under normal circumstances, the framebuffer device should have been
blanked or configured to a low power mode prior to the pm suspend
callback getting executed. In cases when this sequence is not followed,
blank the framebuffer as part of pm suspend handler to ensure that all
display resources are freed. Similarly, if the framebuffer was
explicitly blanked during suspend, then unblank it when resuming. This
also eliminates the need for the existing sysfs node to indicate
always-on display mode.

Change-Id: I1613f5eba420c9587af2ecb04bc5cb115b7a1095
Signed-off-by: Aravind Venkateswaran <aravindh@codeaurora.org>
msm: mdss: avoid race conditions during fb release

During fb release we should release all resources that are associated to
that process. However, in current release function this can lead to
kickoff being done, if this is done while display thread is running
there can be race condition between the updates from two different
threads. Fix this by pushing the commit through the display thread in
cases where display thread should be running, or otherwise shutdown this
thread and do it along with panel blanking.

Change-Id: I9ff6316c18adfdb67d0250a144ddc2f9f2634273
Signed-off-by: Adrian Salido-Moreno <adrianm@codeaurora.org>
msm: mdss: fix deadlock between commit thread and shutdown

There is a deadlock in use cases where fb shutdown
is called. To avoid this condition we need to
kill display thread before release happens during
shutdown.

Change-Id: I24b03e60179c605a8572b5a011d746002e26ca18
Signed-off-by: Ingrid Gallardo <ingridg@codeaurora.org>
msm: mdss: wait for idle when wait for kickoff not available

When underlying mdp driver doesn't support waiting for kickoff trigger,
wait for panel to be idle instead. This will ensure proper
synchronization of updates.

Change-Id: I8fcb75c1873cd55b1aade3442aa99c6c1eba62a8
Signed-off-by: Adrian Salido-Moreno <adrianm@codeaurora.org>