Amongst its other duties, msm_gem_new_impl adds the newly created
GEM object to the shared inactive list which may also be actively
modifiying the list during submission.  All the paths to modify
the list are protected by the mutex except for the one through
msm_gem_import which can end up causing list corruption.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
[add extra WARN_ON(!mutex_is_locked(&dev->struct_mutex))]
Signed-off-by: NRob Clark <robdclark@gmail.com>

Use the dma_fence_match_context helper to check if all backing fences
are from our own context, in which case we don't have to wait.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Gustavo Padovan <gustavo.padovan@collabora.com>
[rebased on code-motion]
Signed-off-by: NRob Clark <robdclark@gmail.com>

struct irq_domain_ops is not modified, so it can be made const.
Signed-off-by: NTobias Klauser <tklauser@distanz.ch>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Otherwise, if userspace doesn't re-use a given plane, it's hwpipe(s)
could stay permanently assigned.
Signed-off-by: NRob Clark <robdclark@gmail.com>

If we follow the typical pattern of the base class being the first
member, we can use the default dma_fence_free function.
Signed-off-by: NEric Anholt <eric@anholt.net>
Cc: Rob Clark <robdclark@gmail.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Without this, polling on the dma-buf (and presumably other devices
synchronizing against our rendering) would return immediately, even
while the BO was busy.
Signed-off-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Cc: Rob Clark <robdclark@gmail.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Otherwise if someone was using old bindings with "core_clk" instead of
"core" as the clock name, we'd never find it and gpu would be stuck at
27MHz (or whatever it's slowest rate is).

Fixes: 98db803f ("msm/drm: gpu: Dynamically locate the clocks from the device tree")
Signed-off-by: NRob Clark <robdclark@gmail.com>

Somehow the helper was never retrofitted for mdp5.  Which meant when
plane_state->fence was added, it could get copied into new state in
mdp5_plane_duplicate_state().

If an update to disable the plane (for example on rmfb) managed to sneak
in after an nonblock update had swapped state, but before it was
committed, we'd get a splat:

    WARNING: CPU: 1 PID: 69 at ../drivers/gpu/drm/drm_atomic_helper.c:1061 drm_atomic_helper_wait_for_fences+0xe0/0xf8
   Modules linked in:

   CPU: 1 PID: 69 Comm: kworker/1:1 Tainted: G        W       4.11.0-rc8+ #1187
   Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
   Workqueue: events drm_mode_rmfb_work_fn
   task: ffffffc036560d00 task.stack: ffffffc036550000
   PC is at drm_atomic_helper_wait_for_fences+0xe0/0xf8
   LR is at complete_commit.isra.1+0x44/0x1c0
   pc : [<ffffff80084f6040>] lr : [<ffffff800854176c>] pstate: 20000145
   sp : ffffffc036553b60
   x29: ffffffc036553b60 x28: ffffffc0264e6a00
   x27: ffffffc035659000 x26: 0000000000000000
   x25: ffffffc0240e8000 x24: 0000000000000038
   x23: 0000000000000000 x22: ffffff800858f200
   x21: ffffffc0240e8000 x20: ffffffc02f56a800
   x19: 0000000000000000 x18: 0000000000000000
   x17: 0000000000000000 x16: 0000000000000000
   x15: 0000000000000000 x14: ffffffc00a192700
   x13: 0000000000000004 x12: 0000000000000000
   x11: ffffff80089a1690 x10: 00000000000008f0
   x9 : ffffffc036553b20 x8 : ffffffc036561650
   x7 : ffffffc03fe6cb40 x6 : 0000000000000000
   x5 : 0000000000000001 x4 : 0000000000000002
   x3 : ffffffc035659000 x2 : ffffffc0240e8c80
   x1 : 0000000000000000 x0 : ffffffc02adbe588

   ---[ end trace 13aeec77c3fb55e2 ]---
   Call trace:
   Exception stack(0xffffffc036553990 to 0xffffffc036553ac0)
   3980:                                   0000000000000000 0000008000000000
   39a0: ffffffc036553b60 ffffff80084f6040 0000000000004ff0 0000000000000038
   39c0: ffffffc0365539d0 ffffff800857e098 ffffffc036553a00 ffffff800857e1b0
   39e0: ffffffc036553a10 ffffff800857c554 ffffffc0365e8400 ffffffc0365e8400
   3a00: ffffffc036553a20 ffffff8008103358 000000000001aad7 ffffff800851b72c
   3a20: ffffffc036553a50 ffffff80080e9228 ffffffc02adbe588 0000000000000000
   3a40: ffffffc0240e8c80 ffffffc035659000 0000000000000002 0000000000000001
   3a60: 0000000000000000 ffffffc03fe6cb40 ffffffc036561650 ffffffc036553b20
   3a80: 00000000000008f0 ffffff80089a1690 0000000000000000 0000000000000004
   3aa0: ffffffc00a192700 0000000000000000 0000000000000000 0000000000000000
   [<ffffff80084f6040>] drm_atomic_helper_wait_for_fences+0xe0/0xf8
   [<ffffff800854176c>] complete_commit.isra.1+0x44/0x1c0
   [<ffffff8008541c64>] msm_atomic_commit+0x32c/0x350
   [<ffffff8008516230>] drm_atomic_commit+0x50/0x60
   [<ffffff8008517548>] drm_atomic_remove_fb+0x158/0x250
   [<ffffff80085186d0>] drm_framebuffer_remove+0x50/0x158
   [<ffffff8008518818>] drm_mode_rmfb_work_fn+0x40/0x58
   [<ffffff80080d5668>] process_one_work+0x1d0/0x378
   [<ffffff80080d5a54>] worker_thread+0x244/0x488
   [<ffffff80080db7fc>] kthread+0xfc/0x128
   [<ffffff8008082ec0>] ret_from_fork+0x10/0x50

Fixes: 96260142 ("drm/fence: add in-fences support")
Cc: stable@vger.kernel.org
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reported-by: NStanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Otherwise, if nothing else enabled selects it, dev_pm_opp_of_add_table()
will return -ENOTSUPP.

Fixes: e2af8b6b ("drm/msm: gpu: Use OPP tables if we can")
Signed-off-by: NRob Clark <robdclark@gmail.com>

Instead of using a fixed list of clock names use the clock-names
list in the device tree to discover and get the list of clocks
that we need.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

If a OPP table is defined for the GPU device in the device tree use
that in lieu of the downstream style GPU frequency table. If we do
use the downstream table convert it to a OPP table so that we can
take advantage of the OPP lookup facilities later.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Some A3XX and A4XX GPU targets required that the GPU clock be
programmed to a non zero value when it was disabled so
27Mhz was chosen as the "invalid" frequency.

Even though newer targets do not have the same clock restrictions
we still write 27Mhz on clock disable and expect the clock subsystem
to round down to zero.

For unknown reasons even though the slow clock speed is always
27Mhz and it isn't actually a functional level the legacy device tree
frequency tables always defined it and then did gymnastics to work
around it.

Instead of playing the same silly games just hard code the "slow" clock
speed in the code as 27MHz and save ourselves a bit of infrastructure.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

User space needs to know where the GMEM whole starts so that they
can set up the addressing correctly.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

There are reasons for a memory object to outlive the file descriptor
that created it and so the address space that a buffer object is
attached to must also outlive the file descriptor. Reference count
the address space so that it can remain viable until all the objects
have released their addresses.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

We should be detaching the MMU before destroying the address
space. To do this cleanly, the detach has to happen in
adreno_gpu_cleanup() because it needs access to structs
in adreno_gpu.c.  Plus it is better symmetry to have
the attach and detach at the same code level.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

3D mux is a small block placed after the DSPPs in MDP5. It can merge
2 LM/DSPP outputs and feed it to a single interface.

Enable 3D Mux if our mdp5_pipeline has 2 active LMs. This check
will need to be made more specific later when we add Dual DSI
support with source split enabled. In that use case, each LM feeds to a
separae INTF, so the 3D mux isn't needed.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Assigning LMs dynamically to CRTCs results in REG_MDP5_CTL_LAYER_REGs
and REG_MDP5_CTL_LAYER_EXT_REGs maintaining old values for a LM that
isn't used by our CTL instance anymore.

Clear the ctl's CTL_LAYER_REG and CTL_LAYER_EXT_REGs for all LM
instances. The ones that need to be configured are configured later
in this func.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Dynamically assign a right mixer to mdp5_crtc_state in the CRTC's
atomic_check path. Assigning the right mixer has some constraints,
i.e, only a few LMs can be paired together. Update mdp5_mixer_assign
to handle these constraints.

Firstly, we need to identify whether we need a right mixer or not.
At the moment, there are 2 scenarios where a right mixer might be
needed:
- If any of the planes connected to this CRTC is too wide (i.e, is
  comprised of 2 hwpipes).
- If the CRTC's mode itself is too wide (i.e, a 4K mode on HDMI).

We implement both these checks in the mdp5_crtc_atomic_check(), and
pass 'need_right_mixer' to mdp5_setup_pipeline.

If a CRTC is already assigned a single mixer, and a new atomic commit
brings in a drm_plane that needs 2 hwpipes, we can successfully commit
this mode without requiring a full modeset, provided that we still use
the previously assigned mixer as the left mixer. If such an assignment
isn't possible, we'd need to do a full modeset. This scenario has been
ignored for now.

The mixer assignment code is a bit messy, considering we have at most
4 LM instances in hardware. This can probably be re-visited later with
simplified logic.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

If a CRTC comprises of 2 LMs, it is mandatory to enable border out
and assign it to the base stage.

We had to enable border out also when the base plane wasn't fullscreen.
Club these checks and put them in a separate function called
get_start_stage() that returns the starting stage for assigning planes.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Now that our mdp5_planes can consist of 2 hwpipes, update the
blend_setup() code to stage the right hwpipe to the left and
right LMs
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

In order to enable Source Split in HW, we need to add/modify
a few LM register configurations:

- Configure the LM width to be half the mode width, so that
  each LM manages one half of the scanout.
- Tell the 'right' LM that it is configured to be the 'right'
  LM in source split mode.
- Since we now have 2 places where REG_MDP5_LM_BLEND_COLOR_OUT is
  configured, do a read-update-store for the register instead of
  directly writing a value to it.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Now that we have a right hwpipe in mdp5_plane_state, configure it
mdp5_plane_mode_set(). The only parameters that vary between the
left and right hwpipes are the src_w, src_img_w, src_x and crtc_x
as we just even chop the fb into left and right halves.

Add a mdp5_plane_right_pipe() which will be used by the crtc code
to set up LM stages.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

If the drm_plane has a source width that's greater than the max width
supported by a SSPP (2560 pixels on 8x96), then we assign a 'r_hwpipe'
to it in mdp5_plane_atomic_check().

TODO: There are a few scenarios where the hwpipe assignments aren't
recommended by HW. For example, an assignment which results in a
drm_plane to of two different types of hwpipes (say RGB0 on left
and DMA1 on right) is not recommended.
Also, hwpipes have a priority mapping, where the higher priority pipe
needs to be staged on left LM, and the lower priority needs to be
staged on the right LM. For example, the priority order for VIG pipes
in decreasing order of priority is VIG0, VIG1, VIG2, and VIG3. So, VIG0
on left and VIG1 on right is a correct configuration, but VIG1 on left
and VIG0 on right isn't. These scenarios are ignored for now for the
sake of simplicity.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Refactor mdp5_plane_mode_set to call mdp5_hwpipe_mode_set. The latter
func takes in only the hwpipe and the parameters that need to be
programmed into the hwpipe registers. All the code that calculates these
parameters is left as is in mdp5_plane_mode_set.

In the future, when we let drm_plane be comprised of 2 hwpipes, this func
allow us to configure each pipe without adding redundant code.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Add another mdp5_hw_mixer pointer (r_mixer) in mdp5_crtc_state.
This mixer will be used to generate the right half of the scanout.

With Source Split, a SSPP can now be connected to 2 Layer Mixers, but
has to be at the same blend level (stage #) on both Layer Mixers.

A drm_plane that has a lesser width than the max width supported, will
comprise of a single SSPP/hwpipe, staged on both the Layer Mixers at
the same blend level. A plane that is greater than max width will comprise
of 2 SSPPs, with the 'left' SSPP staged on the left LM, and the 'right'
SSPP staged on the right LM at the same blend level.

For now, the drm_plane consists of only one SSPP, therefore, it
needs to be staged on both the LMs in blend_setup() and mdp5_ctl_blend().
We'll extend this logic to support 2 hwpipes per plane later.

The crtc cursor ops (using the LM cursors, not SSPP cursors) simply
return an error if they're called when the right mixer is assigned to
the CRTC state. With source split is enabled, we're expected to only
SSPP cursors.

This commit adds code that configures the right mixer, but the r_mixer
itself isn't assigned at the moment.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Some of the newer MDP5 versions support Source Split of SSPPs. It is a
feature that allows us to route the output of a hwpipe to 2 Layer
Mixers. This is required to achieve the following use cases:

- Dual DSI: For high res DSI panels (such as 2560x1600 etc), a single
  DSI interface doesn't have the bandwidth to drive the required pixel
  clock. We use 2 DSI interfaces to drive the left and right halves
  of the panel (i.e, 1280x1600 each). The MDP5 pipeline here would look
  like:

         LM0 -- DSPP0 -- INTF1 -- DSI1
        /
hwpipe--
        \
         LM1 -- DSPP1 -- INTF2 -- DSI2

  A single hwpipe is used to scan out the left and right halves to DSI1
  and DSI2 respectively. In order to do this, we need to configure the
  2 Layer Mixers in Source Split mode.

- HDMI 4K: In order to support resolutions with width higher than the
  max width supported by a hwpipe, we club 2 hwpipes together:

hwpipe1 --- LM0 -- DSPP0
       -   -             \
         -                -- 3D Mux -- INTF0 -- HDMI
       -   -             /
hwpipe2 --- LM1 -- DSPP1

  hwpipe1 is staged on the 'left' Layer Mixer, and hwpipe2 is staged on
  the 'right' Layer Mixer. An additional block called the '3D Mux' is
  used to merge the output of the 2 DSPPs to a single interface.
  In this use case, it is possible that a 4K surface is downscaled and
  placed completely within one of the halves. In order to support such
  scenarios (and keep the programming simple), Layer Mixers with Source
  Split can be assigned 2 hw pipes per stage. While scanning out, the HW
  takes care of fetching the pixels fom the correct pipe.

Add a MDP cap to tell whether the HW supports source split or not.
Add a MDP LM cap that tells whether a LM instance can operate in
source split mode (and generate the 'left' part of the display
output).
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

These are a part of CRTC state, it doesn't feel nice to leave them
hanging in mdp5_ctl struct. Pass mdp5_pipeline pointer instead
wherever it is needed.

We still have some params in mdp5_ctl like start_mask etc which
are derivative of atomic state, and should be rolled back if
a commit fails, but it doesn't seem to cause much trouble.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

In the last few commits, we've been adding params to mdp5_crtc_state, and
assigning them in the atomic_check() funcs. Now it's time to actually
start using them.

Remove the duplicated params from the mdp5_crtc struct, and start using
them in the mdp5_crtc code. The majority of the references to these params
is in code that executes after the atomic swap has occurred, so it's okay
to use crtc->state in them. There are a couple of legacy LM cursor ops that
may not use the updated state, but (I think) it's okay to live with that.

Now that we dynamically allocate a mixer to the CRTC, we can also remove
the static assignment to it in mdp5_crtc_init, and also drop the code that
skipped init-ing WB bound mixers (those will now be rejected by
mdp5_mixer_assign()).
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Things like vblank/err irq masks, mode of operation (command mode or not)
are derivative of the interface and mixer state. Therefore, they need to
be a part of the CRTC state too.

Add them to mdp5_crtc_state, and assign them in the CRTC's atomic_check()
func, so that it can be rolled back to a clean state.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The INTF and CTL used in a display pipeline are going to be maintained as
a part of the CRTC state (i.e, in mdp5_crtc_state).

These entities, however, are currently statically assigned to drm_encoders
(i.e. mdp5_encoder). Since these aren't directly visible to the CRTC, we
assign them to the CRTC state in the encoder's atomic_check() op.

With this approach, we assign portions of CRTC state in two different
places: the layer mixer in CRTC's atomic_check(), and the INTF and CTL
pieces in the encoder's atomic_check() op.

We'd have more options here if the drm core maintained encoder state too,
but the current approach of clubbing everything in CRTC's state works just
fine.

Unlike hwpipes and mixers, we don't need to keep a track of INTF/CTL
assignments in the global atomic state. This is because they're currently
not sharable resources. For example, INTF0 and CTL0 will always be assigned
to one drm_encoder. This can change later when we implement writeback and
want a CRTC to use a CTL for a while, and then release it for others to use
it. Or, when a drm_encoder can switch between using a single INTF vs
2 INTFs.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Add the stuff needed to allow dynamically assigning a mixer to a CRTC.

Since mixers are a resource that can be shared across multiple CRTCs, we
need to maintain a 'hwmixer_to_crtc' map in the global atomic state,
acquire the mdp5_kms.state_lock modeset lock and so on.

The mixer is assigned in the CRTC's atomic_check() func, a failure will
result in the new state being cleanly rolled back.

The mixer assignment itself is straightforward, and almost identical to
what we do for hwpipes. We don't need to grab the old hwmixer_to_crtc
state like we do in hwpipes since we don't need to compare anything
with the old state at the moment.

The only LM capability we care about at the moment is whether the mixer
instance can be used to display stuff (i.e, connect to an INTF
downstream).
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Subclass drm_crtc_state so that we can maintain additional state for
our CRTCs.

Add mdp5_pipeline and mdp5_ctl pointers in the subclassed state.
mdp5_pipeline is a grouping of the HW entities that forms the downstream
pipeline for a particular CRTC. It currently contains pointers to
mdp5_interface and mdp5_hw_mixer tied to this CRTC. Later, we will
have 2 hwmixers in this struct. (We could also have 2 intfs if we want
to support dual DSI with Source Split enabled. Implementing that feature
isn't planned at the moment).

The mdp5_pipeline state isn't used at the moment. For now, we just
introduce mdp5_crtc_state and the crtc funcs needed to manage the
subclassed state.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The mdp5_ctl has an 'op_mode' struct which contains info on
the downstream pipeline.

Grouping these params together in a struct doesn't serve much
purpose in the code. Maybe there was a plan to expand this
further that never happened.

Remove the op_mode struct, and place its members directly in
mdp5_ctl. This will help avoid confusion later when I introduce
my own verion of a mdp5 pipeline :)
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

mdp5_interface struct contains data corresponding to a INTF
instance in MDP5 hardware. This sturct is memcpy'd to the
mdp5_encoder struct, and then later to the mdp5_ctl struct.

Instead of copying around interface data, create mdp5_interface
instances in mdp5_init, like how it's done currently done for
pipes and layer mixers. Pass around the interface pointers to
mdp5_encoder and mdp5_ctl. This simplifies the code, and allows
us to decouple encoders from INTFs in the future if needed.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

PingPong ID for a Layer Mixer is already contained in
mdp5_hw_mixer.

This avoids the need to retrieve PP ID using macros
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Use the mdp5_hw_mixer struct in the mdp5_crtc and mdp5_ctl instead of
using the LM index.

Like before, the Layer Mixers are assigned statically to the CRTCs.
The hwmixer(s) will later be dynamically assigned to CRTCs.

For now, ignore the hwmixers that can only do WB.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Create a struct to represent MDP5 Layer Mixer instances. This will
eventually allow us to detach CRTCs from the Layer Mixers, and
generally clean things up a bit.

This is very similar to how hwpipes were previously abstracted away
from drm planes.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The number of Layer Mixers and the downstream blocks (DSPPs and PPs)
connected to each LM can vary with different MDP5 revisions. These
parameters are also static.

Keep the per instance LM data in mdp5_cfg. This will avoid the need
to have macros which identify PP id or DSPP id the LM is connected
to. We don't configure DSPPs at the moment, but keeping the DSPP
instance # here might come handy later.

Also add a 'caps' field that identifies features supported by a
LM instance. Introduce the caps MDP_LM_CAP_DISPLAY and MDP_LM_CAP_WB
that identify whether a LM instance can be used for display or
writeback.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

We'd previously moved the pipe_lock spinlock to the hwpipe struct. Bring
it back to mdp5_plane. We will need this because an mdp5_plane in the
future could comprise of 2 hw pipes. It makes more sense to have a single
lock to protect the registers for the hw pipes used by a plane, rather
than trying to take individual locks per hwpipe when committing a
configuration.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

4 macros already defined in hdmi.h,
which is not required to redefine in hdmi_audio.c
Signed-off-by: NVinay Simha BN <simhavcs@gmail.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>