The driver returns an error if a DSI DT node is populated, but no device
is connected to it or if the data-lane map isn't present. Ideally, such
a DSI node shouldn't be probed at all (i.e, its status should be set to
"disabled in DT"), but there isn't any harm in registering the DSI device
even if it doesn't have a bridge/panel connected to it.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

This code has been more or less picked up from the vc4 and intel
implementations of update_plane() funcs for cursor planes.

The update_plane() func is usually the drm_atomic_helper_update_plane
func that will issue an atomic commit with the plane updates. Such
commits are not intended to be done faster than the vsync rate.

The legacy cursor userspace API, on the other hand, expects the kernel
to handle cursor updates immediately.

Create a fast path in update_plane, which updates the cursor registers
and flushes the configuration. The fast path is taken when there is only
a change in the cursor's position in the crtc, or a change in the
cursor's crop co-ordinates. For anything else, we go via the slow path.

We take the slow path even when the fb changes, and when there is
currently no fb tied to the plane. This should hopefully ensure that we
always take a slow path for every new fb. This in turn should ensure that
the fb is pinned/prepared.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

In mdp5_plane_atomic_check, we get crtc_state from drm_plane_state.

Later, for cursor planes, we'll populate the update_plane() func that
takes a fast asynchronous path to implement cursor movements. There, we
would need to call a similar atomic_check func to validate the plane
state, but crtc_state would need to be derived differently.

Refactor mdp5_plane_atomic_check to mdp5_plane_atomic_check_with_state
such that the latter takes crtc_state as an argument.

This is similar to what the intel driver has done for async cursor
updates.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

Register cursor drm_planes. The loop in modeset_init that inits the
planes and crtcs has to be refactored a bit. We first iterate all the
hwpipes to find the cursor planes. Then, we loop again to create
crtcs.

In msm_atomic_wait_for_commit_done, remove the check which bypasses
waiting for vsyncs if state->legacy_cursor_updates is true.

We will later create a fast path for cursor position changes in the
cursor plane's update_plane func that doesn't go via the regular
atomic commit path. For rest of cursor related updates, we will have
to wait for vsyncs, so ignore the legacy_cursor_updates flag.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

These are various changes added in preparation for cursor planes:

- Add a pipe_cursor block for 8x96 in mdp5_cfg.
- Add a new pipe CAP called MDP_PIPE_CAP_CURSOR. Use this to ensure we
  assign a cursor SSPP for a drm_plane with type DRM_PLANE_TYPE_CURSOR.
- Update mdp5_ctl_blend_mask/ext_blend_mask funcs to incorporate cursor
  SSPPs.
- In mdp5_ctl_blend, iterate through MAX_STAGES instead of stage_cnt,
  we need to do this because we can now have empty stages in between.
- In mdp5_crtc_atomic_check, make sure that the cursor plane has the
  highest zorder, and stage the cursor plane to the maximum stage #
  present on the HW.
- Create drm_crtc_funcs that doesn't try to implement cursors using the
  older LM cursor HW.
- Pass drm_plane_type in mdp5_plane_init instead of a bool telling
  whether plane is primary or not.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

In MDP5 Layer Mixer HW, the blender output is only the blended color
components (i.e R, G and B, or COLOR0/1/2 in MDP5 HW terminology). This
is fed to the BG input of the next blender. We also need to provide an
alpha (COLOR3) value for the BG input at the next stage.

This is configured via using the REG_MDP5_LM_BLEND_COLOR_OUT register.
For each stage, we can propagate either the BG or FG alpha to the next
stage.

The approach taken by the driver is to propagate FG alpha, if the plane
staged on that blender has an alpha. If it doesn't, we try to propagate
the base layer's alpha.

This is borrowed from downstream MDP5 kernel driver. Without this, we
don't see any cursor plane content.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

The MDP5 plane's atomic_check ops doesn't perform clipping tests.
This didn't hurt us much in the past, but clipping becomes important
with cursor planes.

Use drm_plane_helper_check_state, the way rockchip/intel/mtk drivers
already do. Use these drivers as reference.

Clipping requires knowledge of the crtc width and height. This requires
us to call drm_atomic_helper_check_modeset before
drm_atomic_helper_check_planes in the driver's atomic_check op, because
check_modetest will populate the mode for the crtc, needed to populate
the clip rectangle.

We update the plane_enabled(state) local helper to use state->visible,
since state->visible and 'state->fb && state->crtc' represent the same
thing.

One issue with the existing code is that we don't have a way to disable
the plane when it's completely clipped out. Until there isn't an update
on the crtc (which would de-stage the plane), we would still see the
plane in its last 'visible' configuration.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

Use SSPP_NONE in mdp5_plane_pipe() if there is now hwpipe allocated for
the drm_plane. Returning '0' means we are returning VIG0 pipe.

Also, use the mdp5_pipe enum to pass around the stage array. Initialize
the stage to SSPP_NONE by default.

We do the above because 1) Cursor plane has to be staged at the topmost
blender of the LM, which can result in empty stages in between 2) In
the future, when we support multiple LMs per CRTC. We could have stages
which don't have any pipe assigned to them.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

We currently create CRTCs equaling to the # of Layer Mixer blocks we
have on the MDP5 HW. This number is generally more than the # of encoders
(INTFs) we have in the MDSS HW. The number of encoders connected to
displays on the platform (as described by DT) would be even lesser.

Create only N drm_crtcs, where N is the number of drm_encoders
successfully registered. To do this, we call modeset_init_intf() before
we init the drm_crtcs and drm_planes.

Because of this change, setting encoder->possible_crtcs needs to be moved
from construct_encoder() to a later point when we know how many CRTCs we
have.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

Count can't be non-zero. Changing to uint will also prevent future
warnings.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

For the DSI interfaces, the mdp5_kms core creates 2 encoders for video
and command modes.

Create only a single encoder per interface. When creating the encoder, set
the interface type to MDP5_INTF_MODE_NONE. It's the bridge (DSI/HDMI/eDP)
driver's responsibility to set a different interface type. It can use the
the kms func op set_encoder_mode to change the mode of operation, which
in turn would configure the interface type for the INTF.

In mdp5_cmd_encoder.c, we remove the redundant code, and make the commmand
mode funcs as helpers that are used in mdp5_encoder.c
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

Rename the mdp5_encoder_* ops for active displays to
mdp5_vid_encoder_* ops.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

The mdp5 kms driver currently sets up multiple encoders per interface
(INTF), one for each kind of mode of operation it supports.
We create 2 drm_encoders for DSI, one for Video Mode and the other
for Command Mode operation. The reason behind this approach could have
been that we aren't aware of the DSI device's mode of operation when
we create the encoders.

This makes things a bit complicated, since these encoders have to
be further attached to the same DSI bridge. The easier way out is
to create a single encoder, and make the DSI driver set its mode
of operation when we know what the DSI device's mode flags are.

Start with providing a way to set the mdp5_intf_mode using a kms
func that sets the encoder's mode of operation. When constructing
a DSI encoder, we set the mode of operation to Video Mode as
default. When the DSI device is attached to the host, we probe the
DSI mode flags and set the corresponding mode of operation.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

We currently create 2 encoders for DSI interfaces, one for command
mode and other for video mode operation. This isn't needed as we
can't really use both the encoders at the same time. It also makes
connecting bridges harder.

Switch to creating a single encoder. For now, we assume that the
encoder is configured only in video mode. Later, the same encoder
would be usable in both modes.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

The commit "drm: bridge: Link encoder and bridge in core code" updated
the drm_bridge_attach() API to also include the drm_encoder pointer
the bridge attaches to.

The func msm_dsi_manager_bridge_init() now relies on the drm_encoder
pointer stored in msm_dsi->encoders to pass the encoder to the bridge
API.

msm_dsi->encoders is unfortunately set after this function is called,
resulting in us passing a NULL pointer to drm_brigde_attach. This
results in an error and the DSI driver probe fails.

Move the initialization of msm_dsi->encoders[] a bit up. Also, don't
try to set the encoder's bridge. That's now managed by the bridge
API.

Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

Define the block in advance so that the generated mdp5.xml.h doesn't
break build.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

Signed-off-by: Rob Clark <robdclark@gmail.com>

Suggested by Rob Herring.  We still support the old names for
compatibility with downstream android dt files.

Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Acked-by: Rob Herring <robh@kernel.org>

This was never documented or used in upstream dtb.  It is used by
downstream bindings from android device kernels.  But the quirks are
a property of the gpu revision, and as such are redundant to be listed
separately in dt.  Instead, move the quirks to the device table.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

The original way we determined the gpu version was based on downstream
bindings from android kernel.  A cleaner way is to get the version from
the compatible string.

Note that no upstream dtb uses these bindings.  But the code still
supports falling back to the legacy bindings (with a warning), so that
we are still compatible with the gpu dt node from android device
kernels.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Acked-by: Rob Herring <robh@kernel.org>

The plan is to use the OPP bindings.  For now, remove the documentation
for qcom,gpu-pwrlevels, and make the driver fall back to a safe low
clock if the node is not present.

Note that no upstream dtb use this node.  For now we keep compatibility
with this node to avoid breaking compatibility with downstream android
dt files.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Acked-by: Rob Herring <robh@kernel.org>

It includes code cleanups from Bhumika and Liviu, a significant shader
performance fix and additions to the cmdstream validator from Wladimir
and the addition of a cmdbuf suballocator by myself.
The suballocator improves performance on all chips by reducing the CPU
overhead of the kernel driver and side steps the GC3000 FE MMU flush
erratum, now making the workarounds in IOVA allocation we had before
unnecessary, which results in a nice cleanup of the code in that area.

* 'drm-etnaviv-next' of https://git.pengutronix.de/git/lst/linux:
  drm/etnaviv: Remove duplicate header file include
  Revert "drm/etnaviv: trick drm_mm into giving out a low IOVA"
  drm/etnaviv: add cmdbuf suballocator
  drm/etnaviv: get cmdbuf physical address through the cmdbuf abstraction
  drm/etnaviv: wire up iova handling in new cmdbuf abstraction
  drm/etnaviv: move cmdbuf de-/allocation into own file
  drm/etnaviv: always flush MMU TLBs on map/unmap
  drm/etnaviv: constify etnaviv_iommu_ops structures
  drm/etnaviv: set up initial PULSE_EATER register
  drm/etnaviv: add new GC3000 sensitive states

etnaviv_gem.h header gets included twice. Remove duplicate.
Signed-off-by: Liviu Dudau <liviu@dudau.co.uk>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>

Now that commandstreams are handled through the cmdbuf suballocator
the workaround to make the IOVA games work is not needed anymore.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

There are 3 big benefits to suballocating a single big DMA buffer
for command submission:

1. Avoid hammering CMA. The old way of allocating and freeing a DMA
   buffer for each submission was hitting some of the real slow
   pathes in CMA, as this allocator was not designed for a concurrent
   small buffers load.

2. Less TLB flushes on IOMMUv2. If a new command buffer is mapped into
   the GPU address space the MMU TLBs need to be flushed. By having
   one big buffer statically mapped to the GPU, a lot of those flushes
   can be avoided.

3. No funky workarounds for GC3000. The FE TLB flush on GC3000 isn't
   reliable. To work around that we tried to lay out the cmdbufs in
   the GPU address space in a way to avoid this issue. This hasn't
   always worked if the address space is crowded. A single statically
   mapped buffer avoids the erratum completely.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

Don't allow IOMMUv2 to peek directly into the cmdbuf, but get the
needed PA through a dedicated function.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

Don't call the IOMMU directly, but go through the new cmdbuf abstraction.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

This will get more complex with the following changes, so move it
into its own place.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

This ensures that the GPU isn't able to write into already freed
objects, as doing this in the IOVA reaper isn't enough, as the
gem_free_object path will also cause unmaps to happen.

On MMUv2 this also ensures that stale entries, which may have
been prefetched into the TLB will be purged.

The flush is low overhead, as it gets batched up with the next
user command buffer, so this isn't incuring an overhead for
each buffer map/unmap.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

Declare etnaviv_iommu_ops structure as const as it is only used when
the reference of one of its field is stored in the ops field of a
iommu_domain structure. This ops field is of type const, so
etnaviv_iommu_ops structures having similar properties can be declared
const too.

Done using Coccinelle.
Before and after size details of .o file remains the same after
cross compiling for arm architecture.

lst: Trimmed commit message, apply the same change to iommu_v2.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>

Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next

adding runtime PM support to MIC driver, and including some
cleanups - especially using atomic helper functions
instead of specific ones - and fixups.

* 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
  drm/exynos: g2d: prevent integer overflow in
  drm/exynos: fix a timeout loop
  drm/exynos: use atomic helper commit
  drm/exynos: remove unnecessary codes
  drm/exynos: mic: Add runtime PM support
  drm/exynos: Stop using drm_framebuffer_unregister_private
  drm/exynos: mic: Fix parse_dt function
  drm/exynos: mic: Add mode_set callback function

Merge tag 'sunxi-drm-for-4.11' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into drm-next

Allwinner DRM changes for 4.11

Just one minor fix.

* tag 'sunxi-drm-for-4.11' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux:
  drm/sun4i: Fix a return value in case of error

This is to address what we've discussed, moving some of the minor changes
into a drm-next request.

* 'drm-vmwgfx-next' of git://people.freedesktop.org/~syeh/repos_linux:
  drm/vmwgfx: Use kmemdup instead of kmalloc and memcpy
  drm/vmwgfx: Fix depth input into drm_mode_legacy_fb_format
  drm/vmwgfx: Fix a potential integer overflow
  drm/vmwgfx: Clear an uninitialized struct member
  drm/vmwgfx: Annotate ignored return values
  drm/vmwgfx: Clear uninitialized fields of a parameter

This is the main feature pull for radeon and amdgpu for 4.11.  Highlights:
- Power and clockgating improvements
- Preliminary SR-IOV support
- ttm buffer priority support
- ttm eviction fixes
- Removal of the ttm lru callbacks
- Remove SI DPM quirks due to MC firmware issues
- Handle VFCT with multiple vbioses
- Powerplay improvements
- Lots of driver cleanups

* 'drm-next-4.11' of git://people.freedesktop.org/~agd5f/linux: (120 commits)
  drm/amdgpu: fix amdgpu_bo_va_mapping flags
  drm/amdgpu: access stolen VRAM directly on CZ (v2)
  drm/amdgpu: access stolen VRAM directly on KV/KB (v2)
  drm/amdgpu: fix kernel panic when dpm disabled on Kv.
  drm/amdgpu: fix dpm bug on Kv.
  drm/amd/powerplay: fix regresstion issue can't set manual dpm mode.
  drm/amdgpu: handle vfct with multiple vbios images
  drm/radeon: handle vfct with multiple vbios images
  drm/amdgpu: move misc si headers into amdgpu
  drm/amdgpu: remove unused header si_reg.h
  drm/radeon: drop pitcairn dpm quirks
  drm/amdgpu: drop pitcairn dpm quirks
  drm: radeon: radeon_ttm: Handle return NULL error from ioremap_nocache
  drm/amd/amdgpu/amdgpu_ttm: Handle return NULL error from ioremap_nocache
  drm/amdgpu: add new virtual display ID
  drm/amd/amdgpu: remove the uncessary parameter for ib scheduler
  drm/amdgpu: Bring bo creation in line with radeon driver (v2)
  drm/amd/powerplay: fix misspelling in header guard
  drm/ttm: revert "add optional LRU removal callback v2"
  drm/ttm: revert "implement LRU add callbacks v2"
  ...

Another round of -misc stuff:
- Noralf debugfs cleanup cleanup (not yet everything, some more driver
  patches awaiting acks).
- More doc work.
- edid/infoframe fixes from Ville.
- misc 1-patch fixes all over, as usual

Noralf needs this for his tinydrm pull request.

* tag 'drm-misc-next-2017-01-30' of git://anongit.freedesktop.org/git/drm-misc: (48 commits)
  drm/vc4: Remove vc4_debugfs_cleanup()
  dma/fence: Export enable-signaling tracepoint for emission by drivers
  drm/tilcdc: Remove tilcdc_debugfs_cleanup()
  drm/tegra: Remove tegra_debugfs_cleanup()
  drm/sti: Remove drm_debugfs_remove_files() calls
  drm/radeon: Remove drm_debugfs_remove_files() call
  drm/omap: Remove omap_debugfs_cleanup()
  drm/hdlcd: Remove hdlcd_debugfs_cleanup()
  drm/etnaviv: Remove etnaviv_debugfs_cleanup()
  drm/etnaviv: allow build with COMPILE_TEST
  drm/amd/amdgpu: Remove drm_debugfs_remove_files() call
  drm/prime: Clarify DMA-BUF/GEM Object lifetime
  drm/ttm: Make sure BOs being swapped out are cacheable
  drm/atomic: Remove drm_atomic_debugfs_cleanup()
  drm: drm_minor_register(): Clean up debugfs on failure
  drm: debugfs: Remove all files automatically on cleanup
  drm/fourcc: add vivante tiled layout format modifiers
  drm/edid: Set YQ bits in the AVI infoframe according to CEA-861-F
  drm/edid: Set AVI infoframe Q even when QS=0
  drm/edid: Introduce drm_hdmi_avi_infoframe_quant_range()
  ...

Merge tag 'drm/atmel-hlcdc/for-4.11' of git://git.kernel.org/pub/scm/linux/kernel/git/bbrezillon/linux into drm-next

Contains a single patch to create the fbdev at driver's registration
time instead of waiting for the connector status change.

* tag 'drm/atmel-hlcdc/for-4.11' of git://git.kernel.org/pub/scm/linux/kernel/git/bbrezillon/linux:
  drm/atmel-hlcdc: Rework the fbdev creation logic

Merge tag 'zxdrm-4.11' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into drm-next

ZTE DRM driver updates for 4.11:
 - Add missing selection of VIDEOMODE_HELPERS in Kconfig, since ZTE DRM
   driver uses drm_display_mode_to_videomode().
 - Enable HDMI audio support through SPDIF interface based on generic
   hdmi-audio-codec driver.
 - Enable VOU VL (Video Layer) to support overlay plane with scaling
   function.
 - Refine zx_vou driver a bit and then add TV Encoder output device
   support.

[airlied: fixup plane format change]

* tag 'zxdrm-4.11' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
  drm: zte: add tvenc driver support
  dt: add bindings for ZTE tvenc device
  drm: zte: add function to configure vou_ctrl dividers
  drm: zte: move struct vou_inf into zx_vou driver
  drm: zte: add interlace mode support
  drm: zte: add overlay plane support
  drm: zte: add .atomic_disable hook to disable graphic layer
  drm: zte: make zx_plane accessible from zx_vou driver
  drm: zte: support hdmi audio through spdif
  drm: zte: select VIDEOMODE_HELPERS in Kconfig

Updated pull request after I pulled first time :)

* 'drm-intel-next' of git://anongit.freedesktop.org/git/drm-intel:
  drm/i915: Pevent copying uninitialised garbage into vma->ggtt_view