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>

'SSPP_MAX + 1' is the max number of hwpipes that can be present on a
MDP5 platform. Recently, 2 new cursor hwpipes were added, which
caused overflows in arrays that used SSPP_MAX to represent the number
of elements. Update the SSPP_MAX value to incorporate the extra
hwpipes.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

A recent commit introduces a bug in dsi_mgr_phy_enable. In the non
dual DSI mode, we reset the mdsi (master DSI) PHY. This isn't right
since master and slave DSI exist only in dual DSI mode. For the normal
mode of operation, we should simply reset the PHY of the DSI device
(i.e. msm_dsi) corresponding to the current bridge.

Usage of the wrong DSI pointer also resulted in a static checker
warning. That too is resolved with this fix.

Fixes: b62aa70a (drm/msm/dsi: Move PHY operations out of host)
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Zero sized buffer objects tend to make various bits of the GEM
infrastructure complain:

 WARNING: CPU: 1 PID: 2323 at drivers/gpu/drm/drm_mm.c:389 drm_mm_insert_node_generic+0x258/0x2f0
 Modules linked in:

 CPU: 1 PID: 2323 Comm: drm-api-test Tainted: G        W 4.9.0-rc4-00906-g693af44 #213
 Hardware name: Qualcomm Technologies, Inc. DB820c (DT)
 task: ffff8000d7353400 task.stack: ffff8000d7720000
 PC is at drm_mm_insert_node_generic+0x258/0x2f0
 LR is at drm_vma_offset_add+0x4c/0x70

Zero sized buffers serve no appreciable value to the user so disallow
them at create time.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Output the upper 32 bits of a 64 bit iova in the RD_CMDSTREAM_ADDR
section while maintaining backwards compatibility for tools that
only understand 32 bit iovas.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The interrupt status was being cleared before processing the handlers.
a5xx_rbbm_err_irq() was checking the interrupt status again, which would
likely turn out bad because the interrupt status would be 0 (or at least
different). Pass the original status to the function instead.

Also, skip clearing RBBM_AHB_ERROR from the interrupt status. The interrupt
will keep firing until the error source is cleared.  Skip the clear to
avoid a storm until the error is cleared in a5xx_rbbm_err_irq().
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

priv->num_aspaces is increased and then checked to see if it still fits
in the priv->aspace array.  If it doesn't, we warn and exit but
priv->num_aspaces remains incremented.

Don't incremement the count until we know that it fits in the array.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Instead of checking for a5xx_gpu->gpmu_iova during destroy we
accidently check a5xx_gpu->gpmu_bo.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The core takes care of handling the send_event vs. close() issues, we
can remove that driver code.

Cc: Rob Clark <robdclark@gmail.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

I didn't spot anything that would require ordering here (well not
anywhere else either), and I'm trying to unify at least modern drivers
on one close hook.

Cc: Rob Clark <robdclark@gmail.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The newly added a5xx support fails to build when debugfs is diabled:

drivers/gpu/drm/msm/adreno/a5xx_gpu.c:849:4: error: 'struct msm_gpu_funcs' has no member named 'show'
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:849:11: error: 'a5xx_show' undeclared here (not in a function); did you mean 'a5xx_irq'?

This adds a missing #ifdef.

Fixes: b5f103ab ("drm/msm: gpu: Add A5XX target support")
Cc: stable@vger.kernel.org
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Probably a symptom of needing finer grained locking, but if we wait on
the incoming fence-fd (which could come from a different context) while
holding struct_mutex, that blocks retire_worker so gpu fences cannot get
signalled.

This causes a problem if userspace manages to get more than a frame
ahead, leaving the atomic-commit worker blocked waiting on fences that
cannot be signaled because submit is blocked waiting for a fence
signalled from vblank (after the atomic commit which is blocked).

If we start having multiple fence ctxs for the gpu, submit_fence_sync()
would probably need to move outside of struct_mutex as well.
Signed-off-by: NRob Clark <robdclark@gmail.com>

In particular, attach() and unmap() need pm-runtime get/put to ensure
iommu clks are enabled.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Significantly simplifies things.  Also iommu_unmap() can unmap an entire
iova range.

(If backporting to downstream kernel you might need to revert this.  Or
at least double check older iommu implementation.)
Signed-off-by: NRob Clark <robdclark@gmail.com>

We need to do this also in resume path when we need to re-hw_init().
Signed-off-by: NRob Clark <robdclark@gmail.com>

We need to use pm-runtime properly when IOMMU is using device_link() to
control it's own clocks.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Each of the per-generation callbacks was doing this.  Lets just simplify
and move it into toplevel show() fxn.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Signed-off-by: NAlex Xie <AlexBin.Xie@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NAlex Xie <AlexBin.Xie@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Implement the sr-iov mailbox for soc15 asics.
Signed-off-by: NMonk Liu <Monk.Liu@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NMonk Liu <Monk.Liu@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

they are lack in the bringup stage, we need them for GPU reset
feature.
Signed-off-by: NMonk Liu <Monk.Liu@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NMonk Liu <Monk.Liu@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

1,KIQ won't touch VRAM so no need to involv HDP flush/invalidate at all.
2,According to CP hw designer KIQ better not use any PM4 package lead to wait behave.
Signed-off-by: NMonk Liu <Monk.Liu@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

SRIOV currently only can load ucode directly, and PSP
block is not supported by VF temporarily.

will remove this restrict and use PSP load all ucode
even for SRIOV later

v2: squash in check against module parameter
Signed-off-by: NMonk Liu <Monk.Liu@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NEvan Quan <evan.quan@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Use new WREG32_FIELD15 macro
Signed-off-by: NTom St Denis <tom.stdenis@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Use new WREG32_FIELD15 macro
Signed-off-by: NTom St Denis <tom.stdenis@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Use new WREG32_FIELD15 macro
Signed-off-by: NTom St Denis <tom.stdenis@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NTom St Denis <tom.stdenis@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Use new WREG32_FIELD macro
Signed-off-by: NTom St Denis <tom.stdenis@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>