Since VOP does not have a hardware vblank count register, the ongoing
commit might be racing with a requested vblank interrupt, which would
increment the software vblank counter before the changes being committed
actually happen.

To avoid this, we can extend .atomic_flush(), so after it sets cfg_done
bit, it polls the vblank interrupt bit until it's inactive to make sure
that any old vblank interrupt gets to the handler and then uses
synchronize_irq(vop->irq) to make sure the handler finishes running.

The polling case should happen very rarely, but even if, the total wait
time should be relatively low and in practice almost equal to the vop
hardirq handler running time.
Signed-off-by: NTomasz Figa <tfiga@chromium.org>

Current code implements prepare_fb and cleanup_fb callbacks only to
grab/release fb references, which is already done by atomic framework
when creating/destryoing plane state. Let's remove these
unused bits.
Signed-off-by: NTomasz Figa <tfiga@chromium.org>

The enable register only masks the raw status bits to signal CPU
interrupt only for enabled interrupts. The status bits are activated
regardless of the enable register. This means that we might have an old
interrupt event queued, which we are not interested in. To avoid getting
a spurious interrupt signalled, we have to clear the old bit before we
update the enable register.
Signed-off-by: NTomasz Figa <tfiga@chromium.org>

Instead of keying off vblank for psr, just flush every time
we get an atomic update. This ensures that cursor updates
will properly disable psr (without turning vblank on/off),
and unifies the paths between fb_dirty and atomic psr
enable/disable.
Reviewed-by: NYakir Yang <ykk@rock-chips.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>

vblank should be enabled regardless of whether an event
is expected back. This is especially important for a cursor
plane.
Reviewed-by: NYakir Yang <ykk@rock-chips.com>
Tested-by: NYakir Yang <ykk@rock-chip.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>

The PSR driver have exported four symbols for specific device driver, and
it's safe to call them in interrupt context:
- rockchip_drm_psr_register()
- rockchip_drm_psr_unregister()
- rockchip_drm_psr_enable()
- rockchip_drm_psr_disable()
- rockchip_drm_psr_flush()

Encoder driver should call the register/unregister interfaces to hook
itself into common PSR driver, encoder have implement the 'psr_set'
callback which use the set PSR state in hardware side.

Crtc driver would call the enable/disable interfaces when vblank is
enable/disable, after that the common PSR driver would call the encoder
registered callback to set the PSR state.

Fb driver would call the flush interface in 'fb->dirty' callback, this
helper function would force all PSR enabled encoders to exit from PSR
for 3 seconds.
Signed-off-by: NYakir Yang <ykk@rock-chips.com>
[seanpaul removed leftover psr_enabled/psr_work kruft from drm_vop.c]
Signed-off-by: NSean Paul <seanpaul@chromium.org>

VOP have integrated a hardware counter which indicate the exact display
line that vop is scanning. And if we're interested in a specific line,
we can set the line number to vop line_flag register, and then vop would
generate a line_flag interrupt for it.

For example eDP PSR function is interested in the vertical blanking
period, then driver could set the line number to zero.

This patch have exported a symbol that allow other driver to listen the
line flag event with given timeout limit:
-  rockchip_drm_wait_line_flag()
Signed-off-by: NYakir Yang <ykk@rock-chips.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>

There are two VOP in rk3399 chip, respectively VOP_BIG and VOP_LIT.
most registers layout of this two vop is same, their framework are both
VOP_FULL, the Major differences of this two is that:

VOP_BIG max output resolution is 4096x2160.
VOP_LIT max output resolution is 2560x1600

VOP_BIG support four windows.
VOP_LIT only support two windows.

RK3399 vop register layout is similar with rk3288, so some feature
can reuse with rk3288.
Reviewed-by: NTomasz Figa <tfiga@chromium.org>
Signed-off-by: NMark Yao <mark.yao@rock-chips.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>

Some new vop register support mask, bit[16-31] is mask,
bit[0-15] is value, the mask is correspond to the value.
Signed-off-by: NMark Yao <mark.yao@rock-chips.com>
[seanpaul masked 'v' per tfiga's review comments]
Reviewed-by: NMark Yao <mark.yao@rock-chips.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>

If vop_enable fails, don't continue on, it causes system hangs.
Reviewed-by: NYakir Yank <ykk@rock-chips.com>
Tested-by: NYakir Yank <ykk@rock-chips.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1471302749-2811-1-git-send-email-seanpaul@chromium.org

The drivers have to modify the atomic plane state during the prepare_fb
callback so they track allocations, reservations and dependencies for
this atomic operation involving this fb. In particular, how else do we
set the plane->fence from the framebuffer!
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160818180017.20508-1-chris@chris-wilson.co.uk

Since we can have multiple vops, use DRM_DEV_ERROR to
make logs easier to process.
Acked-by: NMark Yao <mark.yao@rockchip.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1471021254-2563-3-git-send-email-seanpaul@chromium.org

Replace the use of drm_plane_helper_check_update() with
drm_plane_helper_check_state() since we have a plane state.

Rockchip looks to handling plane clipping rather well already
(unlikje most arm drm drivers) so there are no function changes
here.

Cc: Yao <mark.yao@rock-chips.com>
Cc: linux-rockchip@lists.infradead.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NMark Yao <mark.yao@rock-chips.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1469549224-1860-8-git-send-email-ville.syrjala@linux.intel.com

Replace the private drm_rects in vop_plane_state with
the ones now living in drm_plane_state.

Cc: Yao <mark.yao@rock-chips.com>
Cc: linux-rockchip@lists.infradead.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NMark Yao <mark.yao@rock-chips.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1469549224-1860-7-git-send-email-ville.syrjala@linux.intel.com

Because we are using a custom crtc_state structure, we must override the
reset helper to allocate the correct amount of memory.

Cc: stable@vger.kernel.org
Fixes: 4e257d9e ("drm/rockchip: get rid of rockchip_drm_crtc_mode_config")
Signed-off-by: NJohn Keeping <john@metanate.com>
Signed-off-by: NMark Yao <mark.yao@rock-chips.com>
Reviewed-by: NSean Paul <seanpaul@chromium.org>

When the input color format is YUV, we need to do some external scale
for CBCR. Like,
 * In YUV420 data format:
     cbcr_xscale = dst_w / src_w * 2;
     cbcr_yscale = dst_h / src_h * 2;
 * In YUV422 data format:
     cbcr_xscale = dst_w / src_w * 2;
     cbcr_yscale = dst_h / src_h;
 * In YUV444 data format
     cbcr_xscale = dst_w / src_w;
     cbcr_yscale = dst_h / src_h;
Signed-off-by: NYakir Yang <ykk@rock-chips.com>

Combined with the previous commit, this fixes all of the sparse warnings
in drm/rockchip.
Signed-off-by: NJohn Keeping <john@metanate.com>

drm_plane_helper_check_update() needs to account for the plane rotation
for correct clipping/scaling calculations. Do so.

There was an earlier attempt [1] to add this into
intel_check_primary_plane() but I requested that it'd be put into the
helper instead. An updated patch never materialized AFAICS, so I went
ahead and cooked one up myself.

v2: Deal with new drm_plane_helper_check_update() callers

[1] https://patchwork.freedesktop.org/patch/65177/
Cc: Nabendu Maiti <nabendu.bikash.maiti@intel.com>
Cc: Noralf Trønnes <noralf@tronnes.org>
Cc: CK Hu <ck.hu@mediatek.com>
Cc: Mark Yao <mark.yao@rock-chips.com>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466172790-10025-1-git-send-email-ville.syrjala@linux.intel.com

This is now handled by the core, drivers can totally ignore lifetime
issues of drm events.

Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Mark yao <mark.yao@rock-chips.com>
Tested-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1465388359-8070-11-git-send-email-daniel.vetter@ffwll.ch

With the various bits fixed rockchip now has an atomic compliant
handling/signalling of crtc_state->event, which means we can just
switch over to the new nonblocking helpers and remove some code.

v2: Fixes from Tomeu.

v3: Send out vblank events correctly when shutting down a crtc for
good. This is part of the atomic interface contract.

v4: Properly protect vop->event.

v5: Add more WARN_ON to check vop->event isn't clobbered.

Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Mark yao <mark.yao@rock-chips.com>
Tested-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

It's not permissible to look at plane->state from interrupt context,
since doing that would need the irq handler to acquire the
plane->mutex lock.

The other problem is that if we pipeline updates using the new
nonblocking atomic helpers new state gets commit before the irq
handler fires, resulting in a lost event.

Fix both issues by caching the necessary values in vop_win, protected
by dev->event_lock.

Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Mark yao <mark.yao@rock-chips.com>
Tested-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1465388359-8070-19-git-send-email-daniel.vetter@ffwll.ch

With atomic helpers there's no need to track the enabled state of a pipe
any more, because atomic helpers track this accurately already.

Just disable the early returns, since the debug checks might be useful.

v2: Don't call drm_helper_disable_unused_functions, it blows up
without this check. At least explains why rockchip still needed this
old legacy-style state tracing - to work around issues from calling
other legacy style functions!

Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Mark yao <mark.yao@rock-chips.com>
Tested-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1465388359-8070-18-git-send-email-daniel.vetter@ffwll.ch

Now a drm_pending_event can either send a real drm_event or signal a
fence, or both. It allow us to signal via fences when the buffer is
displayed on the screen. Which in turn means that the previous buffer
is not in use anymore and can be freed or sent back to another driver
for processing.

v2: Comments from Daniel Vetter
	- call fence_signal in drm_send_event_locked()
	- remove unneeded !e->event check

v3: Remove drm_pending_event->destroy to fix a leak when e->file_priv
is not set.
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> (v2)
[danvet: fix one e->destroy in arcpgu due to rebasing.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1464818821-5736-13-git-send-email-daniel.vetter@ffwll.ch

It's unused, and really this helper should only look at the state
structure and nothing else.

v2: Fix commit message (Laurent).

v3: Rebase onto mtk driver merge.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Mark Yao <mark.yao@rock-chips.com>
Acked-by: NThierry Reding <thierry.reding@gmail.com>
Acked-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1462804451-15318-2-git-send-email-daniel.vetter@ffwll.ch

It's unused, and really this helper should only look at the state
structure and nothing else.

v2: Rebase on top of rockchip changes

v3: Drop unrelated hunk, spotted by Laurent.

v4: Rebase onto mtk driver merge.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Mark Yao <mark.yao@rock-chips.com>
Acked-by: NThierry Reding <thierry.reding@gmail.com>
Acked-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1462804451-15318-1-git-send-email-daniel.vetter@ffwll.ch

There is a path that use vskiplines with non-initialize.
That would cause vop abnormal behavior.
Signed-off-by: NMark Yao <mark.yao@rock-chips.com>

After async atomic_commit callback, drm_atomic_clean_old_fb will
clean all old fb, but because async, the old fb may be also on
the vop hardware, dma will access the old fb buffer, clean old
fb will cause iommu page fault.

Reference the fb and unreference it when the fb actuall swap out
from vop hardware.
Signed-off-by: NMark Yao <mark.yao@rock-chips.com>

We need to take care of the vop status when use
rockchip_drm_crtc_mode_config, if vop is disabled,
the function would failed, that is terrible.

Save output_type and output_mode into rockchip_crtc_state,
it's nice to make them into atomic.
Signed-off-by: NMark Yao <mark.yao@rock-chips.com>
Tested-by: NJohn Keeping <john@metanate.com>

This fixes a few problems in the vop crtc cleanup (handling error
paths and cleanup upon exit):

* The vop_create_crtc() error path had an unsafe version of the
  iterator used for iterating over all planes (though it was
  destroying planes in the iterator so should have used the safe
  version)

* vop_destroy_crtc() - wasn't calling vop_plane_destroy(), which made
  slub_debug unhappy, at least if we ended up running this due to a
  deferred probe.

* In vop_create_crtc() if we were missing the "port" device tree node
  we would fail but not return an error (found by code inspection).

Fix these problems.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>

When a VOP is re-enabled, it will start scanning right away the
framebuffers that were configured from the last time, even if those have
been destroyed already.

To prevent the VOP from trying to access freed memory, disable all its
windows when the CRTC is being disabled, then each window will get a
valid framebuffer address before it's enabled again.
Signed-off-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Link: http://lkml.kernel.org/g/CAAObsKAv+05ih5U+=4kic_NsjGMhfxYheHR8xXXmacZs+p5SHw@mail.gmail.com

So that when DRM_IOCTL_MODE_SETCRTC is called without a FB nor mode, the
CRTC gets disabled.
Signed-off-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Link: http://lkml.kernel.org/g/CAAObsKAv+05ih5U+=4kic_NsjGMhfxYheHR8xXXmacZs+p5SHw@mail.gmail.com

When closing the DRM device while a vblank is pending, we access
file_priv after it has been free'd, which gives:

  Unable to handle kernel NULL pointer dereference at virtual address 00000000
  ...
  PC is at __list_add+0x5c/0xe8
  LR is at send_vblank_event+0x54/0x1f0
  ...
  [<c02952e8>] (__list_add) from [<c031a7b4>] (send_vblank_event+0x54/0x1f0)
  [<c031a760>] (send_vblank_event) from [<c031a9c0>] (drm_send_vblank_event+0x70/0x78)
  [<c031a950>] (drm_send_vblank_event) from [<c031a9f8>] (drm_crtc_send_vblank_event+0x30/0x34)
  [<c031a9c8>] (drm_crtc_send_vblank_event) from [<c0339ad8>] (vop_isr+0x224/0x28c)
  [<c03398b4>] (vop_isr) from [<c0081780>] (handle_irq_event_percpu+0x12c/0x3e4)

This can be triggered somewhat reliably with:

	modetest -M rockchip -v -s ...

Add a preclose hook to the driver so that we can discard any pending
vblank events when the device is closed.
Signed-off-by: NJohn Keeping <john@metanate.com>

If the geometry of a crtc is changing in an atomic update then we must
validate the plane size against the new state of the crtc and not the
current size, otherwise if the crtc size is increasing the plane will be
cropped at the previous size and will not fill the screen.
Signed-off-by: NJohn Keeping <john@metanate.com>

Commit dbb3d944 (drm/rockchip: vop: move interrupt registers into
vop_data) introduced new macros for updating the interrupt control
registers but these always use the mask from the register definition
without refining it for the particular bits that are being changed.

This means that whenever we enable/disable a particular interrupt we end
up disabling all of the others as a side effect.
Signed-off-by: NJohn Keeping <john@metanate.com>

Add support for Synopsys DesignWare MIPI DSI controller which is
embedded in the rk3288 SoCs.
Signed-off-by: NChris Zhong <zyw@rock-chips.com>
Acked-by: NMark Yao <mark.yao@rock-chips.com>

Since the mipi dsi driver need to use the clock of vop to make the
calculation of Blanking. But sometimes the clock driver can not set a
accurate clock_rate for vop, get it by clk_round_rate before mode_set,
so we can get the true value.
Signed-off-by: NChris Zhong <zyw@rock-chips.com>
Acked-by: NMark Yao <mark.yao@rock-chips.com>

Fixes: a67719d1 ("drm/rockchip: vop: spilt register related into rockchip_reg_vop.c")
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Acked-by: NMark Yao <mark.yao@rock-chips.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

There are two version scale control register found on vop,
scale full version found on rk3288, support extension registers.
and scale little version found on rk3036, only support common scale.
Signed-off-by: NMark Yao <mark.yao@rock-chips.com>

No functional updates. Spilt register related into another file
would be nice to multi vop driver,
Signed-off-by: NMark Yao <mark.yao@rock-chips.com>

Move interrupt registers into vop_data, so it can use at multi-vop driver
Signed-off-by: NMark Yao <mark.yao@rock-chips.com>