msm: mdss: Add error handling in mdss_fb_no_update_notify_timer_cb

Return in case mfd is NULL to avoid NULL pointer dereference.

CRs-Fixed: 563125
Change-Id: I82415ed5f1f7b3d27796e9e3a0c96178aa54bdc5
Signed-off-by: Jayant Shekhar <jshekhar@codeaurora.org>
msm: mdss: add error check for iommu attach API

Iommu device attach api returns error code if it fails.
MDP driver will check this error code and fall back to
recovery path if device attach fails.

Change-Id: I2b9d2d3aa16bc814739e466e9fc5a2c51c7b2b4b
Signed-off-by: Dhaval Patel <pdhaval@codeaurora.org>
msm: mdss: move mdss fudge factors to device-tree

MDSS has a common driver for multiple chip-sets. Each of these chip-sets
can have their own fudge factors for calculations of resource demand.
Move these pre-defined fudge factors to device-tree since they are
platform dependent.

Conflicts:

	Documentation/devicetree/bindings/fb/mdss-mdp.txt
	arch/arm/boot/dts/msmsamarium-mdss.dtsi
	drivers/video/msm/mdss/mdss.h

Change-Id: Ia558a2ad0a096b49cdabf41dd25cf30c843149c4
Signed-off-by: Ujwal Patel <ujwalp@codeaurora.org>
Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
ARM: dts: msm: change mdp bandwidth default fudge factors

Tune default bandwidth fudge factors to smaller values because mdp
driver implements bandwidth calculation equations.

Change-Id: Iba078ab55748c430238a2da58b88b93387f8b62d
Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
ARM: dts: msm: remove mdss-high-ib-factor

This factor was used to increase mdp bandwidth request and now it is
not needed any more after mdp driver implemented bandwidth calculation
equations.

Change-Id: I94c4f2499eb09a2db268a3db55bf7172a96315b5
Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
msm: mdss: calculate mdp clk requirement of each pipe with the fudge factor

Currently the mdp clk margin is added for the final calculated max of
all individual pipe clk requirements to avoid underruns. When this
final rate is greater than the max rate that h/w can support, pipe
decimation mode may not be enabled to avoid underruns. So, move this
margin calculation into each pipe clk so that when any individual pipe
has higher clk rate than the max, pipe decimation can be enabled.

CRs-fixed: 538803
Change-Id: Ia4dc500cfc27e7e4d08f03066b511ed3e4ae4664
Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
msm: mdss: add mdp overlap and prefill bandwidth calculations

This patch implements a set of new equations proposed by h/w team to
calculate mdp bandwidth. MDP has bandwidth requests during both
blanking and active periods. During blanking area, mdp needs to fill
its internal buffers, such as latency buffer, outstanding buffer,
pingpong buffer, etc. This bandwidth is called prefill bandwidth and
it is determined by the total amount of bytes of buffers to be filled
and the total amount of blanking time available. The bandwidth for the
active peroid is called overlap bandwidth which is the max bandwidth
request of all overlapped regions. The final vote from mdp would be
the worst case of prefill bandwidth and overlap bandwidth.

Change-Id: Ib83caf6a3e15c33a2cd71d14e8413b1d9049de29
Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
msm: mdss: support mdp prefill bandwith for multiple platforms

To calculate mdp prefill bandwidth, mdp driver needs to get h/w
dependent buffer constants from device tree. Also add h/w feature
dependent logic.

Conflicts:

	drivers/video/msm/mdss/mdss.h

Change-Id: I8d56ec502a6fd56eaae5b65a326ef966be46f14b
Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
Signed-off-by: Ujwal Patel <ujwalp@codeaurora.org>
msm: mdss: reduce mdp prefill bandwidth vote for command mode panel

The current result of mdp prefill bandwidth calculation for command
mode is larger than what is actually needed for many use cases. This
is due to the fact that for command mode panels during prefill time,
there are less buffer prefill requirement or time constraint than that
of video panels. This patch makes adjustment accordingly based on the
updated equations by h/w team.

Change-Id: I06935a29d771202b3f8dc2c62cf948a8ecc81481
Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
msm: mdss: calculate prefill bandwidth using the worst case vbp

The blanking period of a panel is determined by vbp factor: vertical
back porch plus vsync pulse width. The larger vbp, the larger blanking
time, and the smaller prefill bandwidth request. When two or more
types of interfaces/panels are involved, although each panel has its
own vbp, there is an option to calculate the prefill bandwidth for
each panel with the worst case vbp of all panels. This way there is no
need to increase fudge factor to avoid underruns.

Change-Id: I60dda6ad41bbb353c58ef93cf97787c4da3929dc
Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
msm: mdss: Fix for bus bandwidth issue

Fixing possible large values handling.

Change-Id: Id9e4aafa2a922c2c90def037b110826344487fcd
Signed-off-by: Radhika Ranjan Soni <rrsoni@codeaurora.org>
msm: mdss: add tile format condition for prefill bytes calculation

Latency buffer requires more lines to be prefilled for use cases that
supports tile format.

Change-Id: I552bade677822d47cdd5b43c01f795552e94b406
Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
msm: mdss: release mdp bandwidth voting for command mode when idle

There is no bandwidth usage for command mode panel if no new commit
comes, so mdp bandwidth request can be zero as soon as data transfer
to panel is done. This could bring power savings for use cases of
short transfer time relatively to long idle time (duty cycle) such as
partial update, and slow fps. When video mode panel is present, this
bandwidth cannot be released since the timing of this release is
unpredictable.

Change-Id: Ia67143aa421b7b8d8b1f359244dd397dab369b4a
Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
msm: mdss: update latency buffer bytes calculation for prefill bandwidth

This is a s/w change to reflect the new h/w update of latency buffer
byte calculation for prefill bandwidth. Previously this number of
latency buffer bytes is the amount of allocated smp bytes, however,
for some use cases this doesn't not match the bandwidth equation
result. So for the purpose of matching mdp prefill bandwidth
equations, a standalone calculation is needed.

Change-Id: Ic74599d2c2bfe9610ebc22dee137a0df7171dcb5
Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
msm: mdss: add bandwidth check function

Add function which calculates the bandwidth that would be required by
MDP to display the frame. If the bandwidth is over the defined limits,
an error is returned which means the configuration is not acceptable and
may lead to display underruns.

Change-Id: I991ac458d347487c5c634d271814222aa661fd58
Signed-off-by: Adrian Salido-Moreno <adrianm@codeaurora.org>
Signed-off-by: Anusha Koduru <kanusha@codeaurora.org>
msm: mdss: add bandwidth check while performing frame level checks

Add frame level check inside overlay prepare API, for the bandwidth that
would be required by MDP to display the frame. If the bandwidth is over
the defined limits, then we need to fail the configuration to allow an
alternative composition configuration to happen instead.

Change-Id: I7721047589ce9239f1fb63c37ca5d97127c90f7e
Signed-off-by: Adrian Salido-Moreno <adrianm@codeaurora.org>
Signed-off-by: Saurabh Shah <saurshah@codeaurora.org>
msm: mdss: Perform bandwidth check before applying any fudge

Earlier the bandwidth check is done after applying an ib_fudge.
This causes some valid use cases to fall back to GPU. Perform
bandwidth check against the actual value without considering
any fudges.

Change-Id: I09d10724c473c76ade8cf2a2b8d1bda9862816a2
Signed-off-by: Anusha Koduru <kanusha@codeaurora.org>
msm: mdss: protect command mode BW votes by tracking HW/SW states

Track two states where the BW is needed for the command mode panels
and prevent the BW vote to be released during any of those two states:
1. SW Commit State: This state is the time when the SW has requested
a BW vote, and it will be processing it; it starts at the beginning of
Commit and finish once the kickoff is issued.
2. HW MDP State: This state is the time when the HW is busy
doing the actual transaction, so bandwidth must be kept until
HW finishes; it starts at the beginning of the kickoff and finishes
once the ping pong done interrupt is received.

Change-Id: I2e56128be3ab25a1b065692ae76387a3cd383df3
Signed-off-by: Ingrid Gallardo <ingridg@codeaurora.org>
msm: mdss: Define number of concurrent Assertive Display HW

Define the maximum number of Assertive Display (AD) hardware blocks per
display.

Change-Id: I458400d361be7c58491d9bc44c30580e5405fb96
Signed-off-by: Carl Vanderlip <carlv@codeaurora.org>
msm: mdss: move MDSS revision macros to /linux/msm_mdp.h

Currently kernel driver and user mode libraries keep their own
copies of HW revision numbers. This strategy is prone to errors
and usually frowned upon. Fix this by moving revision information
to sanitized header which is shared by kernel drivers and user mode
libraries.

Change-Id: I59d1256ffd98e07f4ef9ae2b534f04b67abd2119
Signed-off-by: Ujwal Patel <ujwalp@codeaurora.org>
Signed-off-by: Jayant Shekhar <jshekhar@codeaurora.org>