If create_crtc fails in vop bind, ensure the irq refcount is zeroed
back out before exiting.
Reviewed-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NSean Paul <seanpaul@chromium.org>

After changes introduced by last patches, there is no useful data stored
in vop_plane_state struct.  Let's remove it and make the driver use
generic plane state alone.
Signed-off-by: NTomasz Figa <tfiga@chromium.org>

This patch makes the driver send the pending vblank event in next vblank
following the commit, relying on vblank signalling improvements done in
previous patches. This gives us vblank events that always represent the
real moment of changes hitting on the screen (which was the case only
for complete FB changes before) and lets us remove the manual window
update check.
Signed-off-by: NTomasz Figa <tfiga@chromium.org>

Originally we needed to enable vblank for any atomic commit to kick the
PSR machine, but that was changed and we no longer need to do so from
a vblank interrupt. Let's return to original behavior of enabling
vblank only if it is really necessary.

This essentially reverts commit 5b680403 ("drm/rockchip: Enable
vblank without event").
Signed-off-by: NTomasz Figa <tfiga@chromium.org>

Currently the driver uses a custom function to wait for flip to complete
after an atomic commit. It was needed before because of two problems:
 - there is no hardware vblank counter, so the original helper would
   have a race condition with the vblank interrupt,
 - the driver didn't support unreferencing cursor framebuffers
   asynchronously to the commit, which was what the helper expected.
Since both problems have been solved by previous patches, we can now
make the driver use the generic helper and remove custom waiting code.
Signed-off-by: NTomasz Figa <tfiga@chromium.org>

Currently the driver waits for vblank and then unreferences old
framebuffers from atomic commit code path. This is however breaking the
legacy cursor API, which requires the updates to be fully asynchronous.
Instead of just adding a special case for cursor, we can have actually
smaller amount of code to unreference any changed framebuffer from a
flip work.
Signed-off-by: NTomasz Figa <tfiga@chromium.org>

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>

The ->set() callback would always be called when transitioning
from FLUSH->DISABLE since we assign state to psr->state right
above the skip condition.
Reported-by: NDaniel Kurtz <djkurtz@chromium.org>
Reviewed-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NSean Paul <seanpaul@chromium.org>

3 seconds is a bit too conservative, drop this to 100ms for
better power savings.
Reviewed-by: NYakir Yang <ykk@rock-chips.com>
Signed-off-by: NSean Paul <seanpaul@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>

Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter
of the helper drm_atomic_helper_commit_planes() if the relevant display
controllers(e.g., IPUv3 for imx-drm) require to disable a CRTC's planes
when the CRTC is disabled. The helper would skip the ->atomic_disable
call for a plane if the CRTC of the old plane state needs a modesetting
operation. Of course, the drivers need to disable the planes in their CRTC
disable callbacks since no one else would do that.
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Peter Senna Tschudin <peter.senna@gmail.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: NLiu Ying <gnuiyl@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1472461923-14364-1-git-send-email-gnuiyl@gmail.com

This driver is the only user of of_drm_find_panel() which prints an
error before doing probe deferral, yielding messages like this on boot,
before eventually succeeding:

[    2.234271] [drm:rockchip_dp_probe] *ERROR* failed to find panel
...
[    4.797539] [drm:rockchip_dp_probe] *ERROR* failed to find panel
...

Let's just drop the message.
Signed-off-by: NBrian Norris <briannorris@chromium.org>
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>

Remove the delayed worker, opting instead for the non-delayed
variety. Also introduce a lock to ensure we don't have races
with the worker and psr_state. Finally, cancel and wait for
the worker to finish when disabling the bridge.
Reviewed-by: NYakir Yang <ykk@rock-chips.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>

A few things that need tidying up, no functional changes.
Reviewed-by: NYakir Yang <ykk@rock-chips.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>

The handling of psr state is racey, shore that up with
a per-psr driver lock.
Reviewed-by: NYakir Yang <ykk@rock-chips.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>

The delayed worker isn't needed and is racey. Remove it and do
the state change in line.
Reviewed-by: NYakir Yang <ykk@rock-chips.com>
Tested-by: NYakir Yang <ykk@rock-chips.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>

This patch converts the psr_list_mutex to a spinlock and locks
all access to psr_list to avoid races (however unlikely they
were).
Reviewed-by: NYakir Yang <ykk@rock-chips.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>

Alway enable the PSR function for Rockchip analogix_dp driver. If panel
don't support PSR, then the core analogix_dp would ignore this setting.
Signed-off-by: NYakir Yang <ykk@rock-chips.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>

No functional changes, sort the vop registers to make
code more readable.
Signed-off-by: NMark Yao <mark.yao@rock-chips.com>
[seanpaul resolved conflict with name change from _3066 to _3036]
Reviewed-by: NMark Yao <mark.yao@rock-chips.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>

The field "owner" is set by the core.
Thus delete an unneeded initialisation.

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/41e48fd3-f713-7225-1df2-3b1f4758f949@users.sourceforge.net

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

The dma-mapping core and the implementations do not change the DMA
attributes passed by pointer.  Thus the pointer can point to const data.
However the attributes do not have to be a bitfield.  Instead unsigned
long will do fine:

1. This is just simpler.  Both in terms of reading the code and setting
   attributes.  Instead of initializing local attributes on the stack
   and passing pointer to it to dma_set_attr(), just set the bits.

2. It brings safeness and checking for const correctness because the
   attributes are passed by value.

Semantic patches for this change (at least most of them):

    virtual patch
    virtual context

    @r@
    identifier f, attrs;

    @@
    f(...,
    - struct dma_attrs *attrs
    + unsigned long attrs
    , ...)
    {
    ...
    }

    @@
    identifier r.f;
    @@
    f(...,
    - NULL
    + 0
     )

and

    // Options: --all-includes
    virtual patch
    virtual context

    @r@
    identifier f, attrs;
    type t;

    @@
    t f(..., struct dma_attrs *attrs);

    @@
    identifier r.f;
    @@
    f(...,
    - NULL
    + 0
     )

Link: http://lkml.kernel.org/r/1468399300-5399-2-git-send-email-k.kozlowski@samsung.comSigned-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: NVineet Gupta <vgupta@synopsys.com>
Acked-by: NRobin Murphy <robin.murphy@arm.com>
Acked-by: NHans-Christian Noren Egtvedt <egtvedt@samfundet.no>
Acked-by: Mark Salter <msalter@redhat.com> [c6x]
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> [cris]
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> [drm]
Reviewed-by: NBart Van Assche <bart.vanassche@sandisk.com>
Acked-by: Joerg Roedel <jroedel@suse.de> [iommu]
Acked-by: Fabien Dessenne <fabien.dessenne@st.com> [bdisp]
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> [vb2-core]
Acked-by: David Vrabel <david.vrabel@citrix.com> [xen]
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> [xen swiotlb]
Acked-by: Joerg Roedel <jroedel@suse.de> [iommu]
Acked-by: Richard Kuo <rkuo@codeaurora.org> [hexagon]
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> [m68k]
Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> [s390]
Acked-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no> [avr32]
Acked-by: Vineet Gupta <vgupta@synopsys.com> [arc]
Acked-by: Robin Murphy <robin.murphy@arm.com> [arm64 and dma-iommu]
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add the missing clk_disable_unprepare() before return in the
error handling case.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NSean Paul <seanpaul@chromium.org>

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>

The drm_gem_object_unreference_unlocked() function tests whether
its argument is NULL and then returns immediately.
Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>

The priv->crtc_funcs[] array has ROCKCHIP_MAX_CRTC elements so > should
be >= here.

Fixes: 2048e328 ('drm: rockchip: Add basic drm driver')
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NSean Paul <seanpaul@chromium.org>

Signed-off-by: NMark Yao <mark.yao@rock-chips.com>
Reported-by: NTomasz Figa <tfiga@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>

The WIN0 of RK3036 VOP could support YUV data format, but driver
forget to add the uv_vir register field for it.
Signed-off-by: NYakir Yang <ykk@rock-chips.com>