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 5b6804034a ("drm/rockchip: Enable
vblank without event").
Signed-off-by: Tomasz 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: Tomasz 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: Tomasz 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: Tomasz 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: Tomasz 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: Tomasz 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: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
This pull request contains the following rockchip drm changes:
- Introduce support for rk3399 vop/crtc
- Add PSR framework to the rockchip driver
- Implement PSR in the rockchip analogix edp driver
- Fix panel on/off in analogix to avoid damaging panels
- Some miscellaneous fixes to clean up logs and code readability
* 'for-next' of git://people.freedesktop.org/~seanpaul/dogwood:
drm/rockchip: analogix_dp: drop unnecessary probe deferral "error" print
drm/rockchip: Enable vblank without event
drm/rockchip: Improve analogix-dp psr handling
drm/rockchip: A couple small fixes to psr
drm/rockchip: Use a spinlock to protect psr state
drm/rockchip: Don't use a delayed worker for psr state changes
drm/rockchip: Convert psr_list_mutex to spinlock and use it
drm/rockchip: analogix_dp: implement PSR function
drm/bridge: analogix_dp: add the PSR function support
drm/rockchip: add an common abstracted PSR driver
drm/rockchip: vop: export line flag function
drm/bridge: analogix_dp: Ensure the panel is properly prepared/unprepared
dt-bindings: add compatible strings for big/little rockchip vops
dt-bindings: sort Rockchip vop compatible by chip's number
drm/rockchip: vop: add rk3399 vop support
drm/rockchip: vop: introduce VOP_REG_MASK
drm/rockchip: sort registers define by chip's number
vblank should be enabled regardless of whether an event
is expected back. This is especially important for a cursor
plane.
Reviewed-by: Yakir Yang <ykk@rock-chips.com>
Tested-by: Yakir Yang <ykk@rock-chip.com>
Signed-off-by: Sean 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: Yakir Yang <ykk@rock-chips.com>
[seanpaul removed leftover psr_enabled/psr_work kruft from drm_vop.c]
Signed-off-by: Sean 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: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Sean 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: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Sean 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: Mark Yao <mark.yao@rock-chips.com>
[seanpaul masked 'v' per tfiga's review comments]
Reviewed-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Sean Paul <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: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160818180017.20508-1-chris@chris-wilson.co.uk
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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1469549224-1860-8-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: 4e257d9eee ("drm/rockchip: get rid of rockchip_drm_crtc_mode_config")
Signed-off-by: John Keeping <john@metanate.com>
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Reviewed-by: Sean 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: Yakir Yang <ykk@rock-chips.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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Daniel 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: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Daniel 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: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Daniel 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: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Daniel 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: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Daniel 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: Sean 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: Daniel 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: 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: Thierry Reding <thierry.reding@gmail.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1462804451-15318-1-git-send-email-daniel.vetter@ffwll.ch
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: Mark 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: Mark Yao <mark.yao@rock-chips.com>
Tested-by: John 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: Douglas 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: Tomeu 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: John 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: John Keeping <john@metanate.com>
Commit dbb3d94 (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: John Keeping <john@metanate.com>
Add support for Synopsys DesignWare MIPI DSI controller which is
embedded in the rk3288 SoCs.
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Acked-by: Mark 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: Chris Zhong <zyw@rock-chips.com>
Acked-by: Mark Yao <mark.yao@rock-chips.com>
Fixes: a67719d182 ("drm/rockchip: vop: spilt register related into rockchip_reg_vop.c")
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Dave 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: Mark Yao <mark.yao@rock-chips.com>
Both connecter gate and out_mode are not conflict with mode set
configure. Direct setting connecter gate and out_mode, that allow
connector do rockchip_drm_crtc_mode_config after mode set.
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Rk3288 vop timing registers is immediately register, when configure
timing on display active time, will cause tearing. use dclk reset is
not a good idea to avoid this tearing. we can avoid tearing by using
standby register.
Vop standby register will take effect at end of current frame, and
go back to work immediately when exit standby.
So we can use standby register to protect this context.
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Rockchip vop not support hw vblank counter, needed check the committed
register if it's really take effect.
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
For vop, power by enable/disable is more suitable then legacy dpms
function, and enable/disable more closely to the new atomic API.
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
No functional update, drm_vblank_* is the legacy version of
drm_crtc_vblank_*. and use new api make driver more clean.
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
