2015-03-03 05:01:12 +08:00
|
|
|
/*
|
|
|
|
|
* Copyright (C) 2015 Broadcom
|
|
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
|
* it under the terms of the GNU General Public License version 2 as
|
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* DOC: VC4 CRTC module
|
|
|
|
|
*
|
|
|
|
|
* In VC4, the Pixel Valve is what most closely corresponds to the
|
|
|
|
|
* DRM's concept of a CRTC. The PV generates video timings from the
|
2017-02-28 04:11:43 +08:00
|
|
|
* encoder's clock plus its configuration. It pulls scaled pixels from
|
2015-03-03 05:01:12 +08:00
|
|
|
* the HVS at that timing, and feeds it to the encoder.
|
|
|
|
|
*
|
|
|
|
|
* However, the DRM CRTC also collects the configuration of all the
|
2017-02-28 04:11:43 +08:00
|
|
|
* DRM planes attached to it. As a result, the CRTC is also
|
|
|
|
|
* responsible for writing the display list for the HVS channel that
|
|
|
|
|
* the CRTC will use.
|
2015-03-03 05:01:12 +08:00
|
|
|
*
|
|
|
|
|
* The 2835 has 3 different pixel valves. pv0 in the audio power
|
|
|
|
|
* domain feeds DSI0 or DPI, while pv1 feeds DS1 or SMI. pv2 in the
|
|
|
|
|
* image domain can feed either HDMI or the SDTV controller. The
|
|
|
|
|
* pixel valve chooses from the CPRMAN clocks (HSM for HDMI, VEC for
|
|
|
|
|
* SDTV, etc.) according to which output type is chosen in the mux.
|
|
|
|
|
*
|
|
|
|
|
* For power management, the pixel valve's registers are all clocked
|
|
|
|
|
* by the AXI clock, while the timings and FIFOs make use of the
|
|
|
|
|
* output-specific clock. Since the encoders also directly consume
|
|
|
|
|
* the CPRMAN clocks, and know what timings they need, they are the
|
|
|
|
|
* ones that set the clock.
|
|
|
|
|
*/
|
|
|
|
|
|
2017-05-18 12:29:38 +08:00
|
|
|
#include <drm/drm_atomic.h>
|
|
|
|
|
#include <drm/drm_atomic_helper.h>
|
|
|
|
|
#include <drm/drm_crtc_helper.h>
|
|
|
|
|
#include <linux/clk.h>
|
|
|
|
|
#include <drm/drm_fb_cma_helper.h>
|
|
|
|
|
#include <linux/component.h>
|
|
|
|
|
#include <linux/of_device.h>
|
2015-03-03 05:01:12 +08:00
|
|
|
#include "vc4_drv.h"
|
|
|
|
|
#include "vc4_regs.h"
|
|
|
|
|
|
|
|
|
|
struct vc4_crtc {
|
|
|
|
|
struct drm_crtc base;
|
|
|
|
|
const struct vc4_crtc_data *data;
|
|
|
|
|
void __iomem *regs;
|
|
|
|
|
|
drm/vc4: Implement precise vblank timestamping.
Precise vblank timestamping is implemented via the
usual scanout position based method. On VC4 the
pixelvalves PV do not have a scanout position
register. Only the hardware video scaler HVS has a
similar register which describes which scanline for
the output is currently composited and stored in the
HVS fifo for later consumption by the PV.
This causes a problem in that the HVS runs at a much
faster clock (system clock / audio gate) than the PV
which runs at video mode dot clock, so the unless the
fifo between HVS and PV is full, the HVS will progress
faster in its observable read line position than video
scan rate, so the HVS position reading can't be directly
translated into a scanout position for timestamp correction.
Additionally when the PV is in vblank, it doesn't consume
from the fifo, so the fifo gets full very quickly and then
the HVS stops compositing until the PV enters active scanout
and starts consuming scanlines from the fifo again, making
new space for the HVS to composite.
Therefore a simple translation of HVS read position into
elapsed time since (or to) start of active scanout does
not work, but for the most interesting cases we can still
get useful and sufficiently accurate results:
1. The PV enters active scanout of a new frame with the
fifo of the HVS completely full, and the HVS can refill
any fifo line which gets consumed and thereby freed up by
the PV during active scanout very quickly. Therefore the
PV and HVS work effectively in lock-step during active
scanout with the fifo never having more than 1 scanline
freed up by the PV before it gets refilled. The PV's
real scanout position is therefore trailing the HVS
compositing position as scanoutpos = hvspos - fifosize
and we can get the true scanoutpos as HVS readpos minus
fifo size, so precise timestamping works while in active
scanout, except for the last few scanlines of the frame,
when the HVS reaches end of frame, stops compositing and
the PV catches up and drains the fifo. This special case
would only introduce minor errors though.
2. If we are in vblank, then we can only guess something
reasonable. If called from vblank irq, we assume the irq is
usually dispatched with minimum delay, so we can take a
timestamp taken at entry into the vblank irq handler as a
baseline and then add a full vblank duration until the
guessed start of active scanout. As irq dispatch is usually
pretty low latency this works with relatively low jitter and
good results.
If we aren't called from vblank then we could be anywhere
within the vblank interval, so we return a neutral result,
simply the current system timestamp, and hope for the best.
Measurement shows the generated timestamps to be rather precise,
and at least never off more than 1 vblank duration worst-case.
Limitations: Doesn't work well yet for interlaced video modes,
therefore disabled in interlaced mode for now.
v2: Use the DISPBASE registers to determine the FIFO size (changes
by anholt)
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> (v2)
2016-06-23 14:17:50 +08:00
|
|
|
/* Timestamp at start of vblank irq - unaffected by lock delays. */
|
|
|
|
|
ktime_t t_vblank;
|
|
|
|
|
|
2015-03-03 05:01:12 +08:00
|
|
|
/* Which HVS channel we're using for our CRTC. */
|
|
|
|
|
int channel;
|
|
|
|
|
|
2016-04-01 09:38:20 +08:00
|
|
|
u8 lut_r[256];
|
|
|
|
|
u8 lut_g[256];
|
|
|
|
|
u8 lut_b[256];
|
drm/vc4: Implement precise vblank timestamping.
Precise vblank timestamping is implemented via the
usual scanout position based method. On VC4 the
pixelvalves PV do not have a scanout position
register. Only the hardware video scaler HVS has a
similar register which describes which scanline for
the output is currently composited and stored in the
HVS fifo for later consumption by the PV.
This causes a problem in that the HVS runs at a much
faster clock (system clock / audio gate) than the PV
which runs at video mode dot clock, so the unless the
fifo between HVS and PV is full, the HVS will progress
faster in its observable read line position than video
scan rate, so the HVS position reading can't be directly
translated into a scanout position for timestamp correction.
Additionally when the PV is in vblank, it doesn't consume
from the fifo, so the fifo gets full very quickly and then
the HVS stops compositing until the PV enters active scanout
and starts consuming scanlines from the fifo again, making
new space for the HVS to composite.
Therefore a simple translation of HVS read position into
elapsed time since (or to) start of active scanout does
not work, but for the most interesting cases we can still
get useful and sufficiently accurate results:
1. The PV enters active scanout of a new frame with the
fifo of the HVS completely full, and the HVS can refill
any fifo line which gets consumed and thereby freed up by
the PV during active scanout very quickly. Therefore the
PV and HVS work effectively in lock-step during active
scanout with the fifo never having more than 1 scanline
freed up by the PV before it gets refilled. The PV's
real scanout position is therefore trailing the HVS
compositing position as scanoutpos = hvspos - fifosize
and we can get the true scanoutpos as HVS readpos minus
fifo size, so precise timestamping works while in active
scanout, except for the last few scanlines of the frame,
when the HVS reaches end of frame, stops compositing and
the PV catches up and drains the fifo. This special case
would only introduce minor errors though.
2. If we are in vblank, then we can only guess something
reasonable. If called from vblank irq, we assume the irq is
usually dispatched with minimum delay, so we can take a
timestamp taken at entry into the vblank irq handler as a
baseline and then add a full vblank duration until the
guessed start of active scanout. As irq dispatch is usually
pretty low latency this works with relatively low jitter and
good results.
If we aren't called from vblank then we could be anywhere
within the vblank interval, so we return a neutral result,
simply the current system timestamp, and hope for the best.
Measurement shows the generated timestamps to be rather precise,
and at least never off more than 1 vblank duration worst-case.
Limitations: Doesn't work well yet for interlaced video modes,
therefore disabled in interlaced mode for now.
v2: Use the DISPBASE registers to determine the FIFO size (changes
by anholt)
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> (v2)
2016-06-23 14:17:50 +08:00
|
|
|
/* Size in pixels of the COB memory allocated to this CRTC. */
|
|
|
|
|
u32 cob_size;
|
2016-04-01 09:38:20 +08:00
|
|
|
|
2015-03-03 05:01:12 +08:00
|
|
|
struct drm_pending_vblank_event *event;
|
|
|
|
|
};
|
|
|
|
|
|
2015-12-29 05:25:41 +08:00
|
|
|
struct vc4_crtc_state {
|
|
|
|
|
struct drm_crtc_state base;
|
|
|
|
|
/* Dlist area for this CRTC configuration. */
|
|
|
|
|
struct drm_mm_node mm;
|
|
|
|
|
};
|
|
|
|
|
|
2015-03-03 05:01:12 +08:00
|
|
|
static inline struct vc4_crtc *
|
|
|
|
|
to_vc4_crtc(struct drm_crtc *crtc)
|
|
|
|
|
{
|
|
|
|
|
return (struct vc4_crtc *)crtc;
|
|
|
|
|
}
|
|
|
|
|
|
2015-12-29 05:25:41 +08:00
|
|
|
static inline struct vc4_crtc_state *
|
|
|
|
|
to_vc4_crtc_state(struct drm_crtc_state *crtc_state)
|
|
|
|
|
{
|
|
|
|
|
return (struct vc4_crtc_state *)crtc_state;
|
|
|
|
|
}
|
|
|
|
|
|
2015-03-03 05:01:12 +08:00
|
|
|
struct vc4_crtc_data {
|
|
|
|
|
/* Which channel of the HVS this pixelvalve sources from. */
|
|
|
|
|
int hvs_channel;
|
|
|
|
|
|
2016-12-02 21:48:07 +08:00
|
|
|
enum vc4_encoder_type encoder_types[4];
|
2015-03-03 05:01:12 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#define CRTC_WRITE(offset, val) writel(val, vc4_crtc->regs + (offset))
|
|
|
|
|
#define CRTC_READ(offset) readl(vc4_crtc->regs + (offset))
|
|
|
|
|
|
|
|
|
|
#define CRTC_REG(reg) { reg, #reg }
|
|
|
|
|
static const struct {
|
|
|
|
|
u32 reg;
|
|
|
|
|
const char *name;
|
|
|
|
|
} crtc_regs[] = {
|
|
|
|
|
CRTC_REG(PV_CONTROL),
|
|
|
|
|
CRTC_REG(PV_V_CONTROL),
|
2016-02-16 09:06:02 +08:00
|
|
|
CRTC_REG(PV_VSYNCD_EVEN),
|
2015-03-03 05:01:12 +08:00
|
|
|
CRTC_REG(PV_HORZA),
|
|
|
|
|
CRTC_REG(PV_HORZB),
|
|
|
|
|
CRTC_REG(PV_VERTA),
|
|
|
|
|
CRTC_REG(PV_VERTB),
|
|
|
|
|
CRTC_REG(PV_VERTA_EVEN),
|
|
|
|
|
CRTC_REG(PV_VERTB_EVEN),
|
|
|
|
|
CRTC_REG(PV_INTEN),
|
|
|
|
|
CRTC_REG(PV_INTSTAT),
|
|
|
|
|
CRTC_REG(PV_STAT),
|
|
|
|
|
CRTC_REG(PV_HACT_ACT),
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static void vc4_crtc_dump_regs(struct vc4_crtc *vc4_crtc)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(crtc_regs); i++) {
|
|
|
|
|
DRM_INFO("0x%04x (%s): 0x%08x\n",
|
|
|
|
|
crtc_regs[i].reg, crtc_regs[i].name,
|
|
|
|
|
CRTC_READ(crtc_regs[i].reg));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_DEBUG_FS
|
|
|
|
|
int vc4_crtc_debugfs_regs(struct seq_file *m, void *unused)
|
|
|
|
|
{
|
|
|
|
|
struct drm_info_node *node = (struct drm_info_node *)m->private;
|
|
|
|
|
struct drm_device *dev = node->minor->dev;
|
|
|
|
|
int crtc_index = (uintptr_t)node->info_ent->data;
|
|
|
|
|
struct drm_crtc *crtc;
|
|
|
|
|
struct vc4_crtc *vc4_crtc;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
i = 0;
|
|
|
|
|
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
|
|
|
|
|
if (i == crtc_index)
|
|
|
|
|
break;
|
|
|
|
|
i++;
|
|
|
|
|
}
|
|
|
|
|
if (!crtc)
|
|
|
|
|
return 0;
|
|
|
|
|
vc4_crtc = to_vc4_crtc(crtc);
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(crtc_regs); i++) {
|
|
|
|
|
seq_printf(m, "%s (0x%04x): 0x%08x\n",
|
|
|
|
|
crtc_regs[i].name, crtc_regs[i].reg,
|
|
|
|
|
CRTC_READ(crtc_regs[i].reg));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos
If we restrict this helper to only kms drivers (which is the case) we
can look up the correct mode easily ourselves. But it's a bit tricky:
- All legacy drivers look at crtc->hwmode. But that is updated already
at the beginning of the modeset helper, which means when we disable
a pipe. Hence the final timestamps might be a bit off. But since
this is an existing bug I'm not going to change it, but just try to
be bug-for-bug compatible with the current code. This only applies
to radeon&amdgpu.
- i915 tries to get it perfect by updating crtc->hwmode when the pipe
is off (i.e. vblank->enabled = false).
- All other atomic drivers look at crtc->state->adjusted_mode. Those
that look at state->requested_mode simply don't adjust their mode,
so it's the same. That has two problems: Accessing crtc->state from
interrupt handling code is unsafe, and it's updated before we shut
down the pipe. For nonblocking modesets it's even worse.
For atomic drivers try to implement what i915 does. To do that we add
a new hwmode field to the vblank structure, and update it from
drm_calc_timestamping_constants(). For atomic drivers that's called
from the right spot by the helper library already, so all fine. But
for safety let's enforce that.
For legacy driver this function is only called at the end (oh the
fun), which is broken, so again let's not bother and just stay
bug-for-bug compatible.
The benefit is that we can use drm_calc_vbltimestamp_from_scanoutpos
directly to implement ->get_vblank_timestamp in every driver, deleting
a lot of code.
v2: Completely new approach, trying to mimick the i915 solution.
v3: Fixup kerneldoc.
v4: Drop the WARN_ON to check that the vblank is off, atomic helpers
currently unconditionally call this. Recomputing the same stuff should
be harmless.
v5: Fix typos and move misplaced hunks to the right patches (Neil).
v6: Undo hunk movement (kbuild).
Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Cc: Eric Anholt <eric@anholt.net>
Cc: Rob Clark <robdclark@gmail.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-4-daniel.vetter@ffwll.ch
2017-05-09 22:03:28 +08:00
|
|
|
bool vc4_crtc_get_scanoutpos(struct drm_device *dev, unsigned int crtc_id,
|
|
|
|
|
bool in_vblank_irq, int *vpos, int *hpos,
|
|
|
|
|
ktime_t *stime, ktime_t *etime,
|
|
|
|
|
const struct drm_display_mode *mode)
|
drm/vc4: Implement precise vblank timestamping.
Precise vblank timestamping is implemented via the
usual scanout position based method. On VC4 the
pixelvalves PV do not have a scanout position
register. Only the hardware video scaler HVS has a
similar register which describes which scanline for
the output is currently composited and stored in the
HVS fifo for later consumption by the PV.
This causes a problem in that the HVS runs at a much
faster clock (system clock / audio gate) than the PV
which runs at video mode dot clock, so the unless the
fifo between HVS and PV is full, the HVS will progress
faster in its observable read line position than video
scan rate, so the HVS position reading can't be directly
translated into a scanout position for timestamp correction.
Additionally when the PV is in vblank, it doesn't consume
from the fifo, so the fifo gets full very quickly and then
the HVS stops compositing until the PV enters active scanout
and starts consuming scanlines from the fifo again, making
new space for the HVS to composite.
Therefore a simple translation of HVS read position into
elapsed time since (or to) start of active scanout does
not work, but for the most interesting cases we can still
get useful and sufficiently accurate results:
1. The PV enters active scanout of a new frame with the
fifo of the HVS completely full, and the HVS can refill
any fifo line which gets consumed and thereby freed up by
the PV during active scanout very quickly. Therefore the
PV and HVS work effectively in lock-step during active
scanout with the fifo never having more than 1 scanline
freed up by the PV before it gets refilled. The PV's
real scanout position is therefore trailing the HVS
compositing position as scanoutpos = hvspos - fifosize
and we can get the true scanoutpos as HVS readpos minus
fifo size, so precise timestamping works while in active
scanout, except for the last few scanlines of the frame,
when the HVS reaches end of frame, stops compositing and
the PV catches up and drains the fifo. This special case
would only introduce minor errors though.
2. If we are in vblank, then we can only guess something
reasonable. If called from vblank irq, we assume the irq is
usually dispatched with minimum delay, so we can take a
timestamp taken at entry into the vblank irq handler as a
baseline and then add a full vblank duration until the
guessed start of active scanout. As irq dispatch is usually
pretty low latency this works with relatively low jitter and
good results.
If we aren't called from vblank then we could be anywhere
within the vblank interval, so we return a neutral result,
simply the current system timestamp, and hope for the best.
Measurement shows the generated timestamps to be rather precise,
and at least never off more than 1 vblank duration worst-case.
Limitations: Doesn't work well yet for interlaced video modes,
therefore disabled in interlaced mode for now.
v2: Use the DISPBASE registers to determine the FIFO size (changes
by anholt)
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> (v2)
2016-06-23 14:17:50 +08:00
|
|
|
{
|
|
|
|
|
struct vc4_dev *vc4 = to_vc4_dev(dev);
|
2017-01-09 19:25:45 +08:00
|
|
|
struct drm_crtc *crtc = drm_crtc_from_index(dev, crtc_id);
|
|
|
|
|
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
|
drm/vc4: Implement precise vblank timestamping.
Precise vblank timestamping is implemented via the
usual scanout position based method. On VC4 the
pixelvalves PV do not have a scanout position
register. Only the hardware video scaler HVS has a
similar register which describes which scanline for
the output is currently composited and stored in the
HVS fifo for later consumption by the PV.
This causes a problem in that the HVS runs at a much
faster clock (system clock / audio gate) than the PV
which runs at video mode dot clock, so the unless the
fifo between HVS and PV is full, the HVS will progress
faster in its observable read line position than video
scan rate, so the HVS position reading can't be directly
translated into a scanout position for timestamp correction.
Additionally when the PV is in vblank, it doesn't consume
from the fifo, so the fifo gets full very quickly and then
the HVS stops compositing until the PV enters active scanout
and starts consuming scanlines from the fifo again, making
new space for the HVS to composite.
Therefore a simple translation of HVS read position into
elapsed time since (or to) start of active scanout does
not work, but for the most interesting cases we can still
get useful and sufficiently accurate results:
1. The PV enters active scanout of a new frame with the
fifo of the HVS completely full, and the HVS can refill
any fifo line which gets consumed and thereby freed up by
the PV during active scanout very quickly. Therefore the
PV and HVS work effectively in lock-step during active
scanout with the fifo never having more than 1 scanline
freed up by the PV before it gets refilled. The PV's
real scanout position is therefore trailing the HVS
compositing position as scanoutpos = hvspos - fifosize
and we can get the true scanoutpos as HVS readpos minus
fifo size, so precise timestamping works while in active
scanout, except for the last few scanlines of the frame,
when the HVS reaches end of frame, stops compositing and
the PV catches up and drains the fifo. This special case
would only introduce minor errors though.
2. If we are in vblank, then we can only guess something
reasonable. If called from vblank irq, we assume the irq is
usually dispatched with minimum delay, so we can take a
timestamp taken at entry into the vblank irq handler as a
baseline and then add a full vblank duration until the
guessed start of active scanout. As irq dispatch is usually
pretty low latency this works with relatively low jitter and
good results.
If we aren't called from vblank then we could be anywhere
within the vblank interval, so we return a neutral result,
simply the current system timestamp, and hope for the best.
Measurement shows the generated timestamps to be rather precise,
and at least never off more than 1 vblank duration worst-case.
Limitations: Doesn't work well yet for interlaced video modes,
therefore disabled in interlaced mode for now.
v2: Use the DISPBASE registers to determine the FIFO size (changes
by anholt)
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> (v2)
2016-06-23 14:17:50 +08:00
|
|
|
u32 val;
|
|
|
|
|
int fifo_lines;
|
|
|
|
|
int vblank_lines;
|
drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos
If we restrict this helper to only kms drivers (which is the case) we
can look up the correct mode easily ourselves. But it's a bit tricky:
- All legacy drivers look at crtc->hwmode. But that is updated already
at the beginning of the modeset helper, which means when we disable
a pipe. Hence the final timestamps might be a bit off. But since
this is an existing bug I'm not going to change it, but just try to
be bug-for-bug compatible with the current code. This only applies
to radeon&amdgpu.
- i915 tries to get it perfect by updating crtc->hwmode when the pipe
is off (i.e. vblank->enabled = false).
- All other atomic drivers look at crtc->state->adjusted_mode. Those
that look at state->requested_mode simply don't adjust their mode,
so it's the same. That has two problems: Accessing crtc->state from
interrupt handling code is unsafe, and it's updated before we shut
down the pipe. For nonblocking modesets it's even worse.
For atomic drivers try to implement what i915 does. To do that we add
a new hwmode field to the vblank structure, and update it from
drm_calc_timestamping_constants(). For atomic drivers that's called
from the right spot by the helper library already, so all fine. But
for safety let's enforce that.
For legacy driver this function is only called at the end (oh the
fun), which is broken, so again let's not bother and just stay
bug-for-bug compatible.
The benefit is that we can use drm_calc_vbltimestamp_from_scanoutpos
directly to implement ->get_vblank_timestamp in every driver, deleting
a lot of code.
v2: Completely new approach, trying to mimick the i915 solution.
v3: Fixup kerneldoc.
v4: Drop the WARN_ON to check that the vblank is off, atomic helpers
currently unconditionally call this. Recomputing the same stuff should
be harmless.
v5: Fix typos and move misplaced hunks to the right patches (Neil).
v6: Undo hunk movement (kbuild).
Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Cc: Eric Anholt <eric@anholt.net>
Cc: Rob Clark <robdclark@gmail.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-4-daniel.vetter@ffwll.ch
2017-05-09 22:03:28 +08:00
|
|
|
bool ret = false;
|
drm/vc4: Implement precise vblank timestamping.
Precise vblank timestamping is implemented via the
usual scanout position based method. On VC4 the
pixelvalves PV do not have a scanout position
register. Only the hardware video scaler HVS has a
similar register which describes which scanline for
the output is currently composited and stored in the
HVS fifo for later consumption by the PV.
This causes a problem in that the HVS runs at a much
faster clock (system clock / audio gate) than the PV
which runs at video mode dot clock, so the unless the
fifo between HVS and PV is full, the HVS will progress
faster in its observable read line position than video
scan rate, so the HVS position reading can't be directly
translated into a scanout position for timestamp correction.
Additionally when the PV is in vblank, it doesn't consume
from the fifo, so the fifo gets full very quickly and then
the HVS stops compositing until the PV enters active scanout
and starts consuming scanlines from the fifo again, making
new space for the HVS to composite.
Therefore a simple translation of HVS read position into
elapsed time since (or to) start of active scanout does
not work, but for the most interesting cases we can still
get useful and sufficiently accurate results:
1. The PV enters active scanout of a new frame with the
fifo of the HVS completely full, and the HVS can refill
any fifo line which gets consumed and thereby freed up by
the PV during active scanout very quickly. Therefore the
PV and HVS work effectively in lock-step during active
scanout with the fifo never having more than 1 scanline
freed up by the PV before it gets refilled. The PV's
real scanout position is therefore trailing the HVS
compositing position as scanoutpos = hvspos - fifosize
and we can get the true scanoutpos as HVS readpos minus
fifo size, so precise timestamping works while in active
scanout, except for the last few scanlines of the frame,
when the HVS reaches end of frame, stops compositing and
the PV catches up and drains the fifo. This special case
would only introduce minor errors though.
2. If we are in vblank, then we can only guess something
reasonable. If called from vblank irq, we assume the irq is
usually dispatched with minimum delay, so we can take a
timestamp taken at entry into the vblank irq handler as a
baseline and then add a full vblank duration until the
guessed start of active scanout. As irq dispatch is usually
pretty low latency this works with relatively low jitter and
good results.
If we aren't called from vblank then we could be anywhere
within the vblank interval, so we return a neutral result,
simply the current system timestamp, and hope for the best.
Measurement shows the generated timestamps to be rather precise,
and at least never off more than 1 vblank duration worst-case.
Limitations: Doesn't work well yet for interlaced video modes,
therefore disabled in interlaced mode for now.
v2: Use the DISPBASE registers to determine the FIFO size (changes
by anholt)
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> (v2)
2016-06-23 14:17:50 +08:00
|
|
|
|
|
|
|
|
/* preempt_disable_rt() should go right here in PREEMPT_RT patchset. */
|
|
|
|
|
|
|
|
|
|
/* Get optional system timestamp before query. */
|
|
|
|
|
if (stime)
|
|
|
|
|
*stime = ktime_get();
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Read vertical scanline which is currently composed for our
|
|
|
|
|
* pixelvalve by the HVS, and also the scaler status.
|
|
|
|
|
*/
|
|
|
|
|
val = HVS_READ(SCALER_DISPSTATX(vc4_crtc->channel));
|
|
|
|
|
|
|
|
|
|
/* Get optional system timestamp after query. */
|
|
|
|
|
if (etime)
|
|
|
|
|
*etime = ktime_get();
|
|
|
|
|
|
|
|
|
|
/* preempt_enable_rt() should go right here in PREEMPT_RT patchset. */
|
|
|
|
|
|
|
|
|
|
/* Vertical position of hvs composed scanline. */
|
|
|
|
|
*vpos = VC4_GET_FIELD(val, SCALER_DISPSTATX_LINE);
|
2016-07-20 02:59:00 +08:00
|
|
|
*hpos = 0;
|
|
|
|
|
|
|
|
|
|
if (mode->flags & DRM_MODE_FLAG_INTERLACE) {
|
|
|
|
|
*vpos /= 2;
|
drm/vc4: Implement precise vblank timestamping.
Precise vblank timestamping is implemented via the
usual scanout position based method. On VC4 the
pixelvalves PV do not have a scanout position
register. Only the hardware video scaler HVS has a
similar register which describes which scanline for
the output is currently composited and stored in the
HVS fifo for later consumption by the PV.
This causes a problem in that the HVS runs at a much
faster clock (system clock / audio gate) than the PV
which runs at video mode dot clock, so the unless the
fifo between HVS and PV is full, the HVS will progress
faster in its observable read line position than video
scan rate, so the HVS position reading can't be directly
translated into a scanout position for timestamp correction.
Additionally when the PV is in vblank, it doesn't consume
from the fifo, so the fifo gets full very quickly and then
the HVS stops compositing until the PV enters active scanout
and starts consuming scanlines from the fifo again, making
new space for the HVS to composite.
Therefore a simple translation of HVS read position into
elapsed time since (or to) start of active scanout does
not work, but for the most interesting cases we can still
get useful and sufficiently accurate results:
1. The PV enters active scanout of a new frame with the
fifo of the HVS completely full, and the HVS can refill
any fifo line which gets consumed and thereby freed up by
the PV during active scanout very quickly. Therefore the
PV and HVS work effectively in lock-step during active
scanout with the fifo never having more than 1 scanline
freed up by the PV before it gets refilled. The PV's
real scanout position is therefore trailing the HVS
compositing position as scanoutpos = hvspos - fifosize
and we can get the true scanoutpos as HVS readpos minus
fifo size, so precise timestamping works while in active
scanout, except for the last few scanlines of the frame,
when the HVS reaches end of frame, stops compositing and
the PV catches up and drains the fifo. This special case
would only introduce minor errors though.
2. If we are in vblank, then we can only guess something
reasonable. If called from vblank irq, we assume the irq is
usually dispatched with minimum delay, so we can take a
timestamp taken at entry into the vblank irq handler as a
baseline and then add a full vblank duration until the
guessed start of active scanout. As irq dispatch is usually
pretty low latency this works with relatively low jitter and
good results.
If we aren't called from vblank then we could be anywhere
within the vblank interval, so we return a neutral result,
simply the current system timestamp, and hope for the best.
Measurement shows the generated timestamps to be rather precise,
and at least never off more than 1 vblank duration worst-case.
Limitations: Doesn't work well yet for interlaced video modes,
therefore disabled in interlaced mode for now.
v2: Use the DISPBASE registers to determine the FIFO size (changes
by anholt)
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> (v2)
2016-06-23 14:17:50 +08:00
|
|
|
|
2016-07-20 02:59:00 +08:00
|
|
|
/* Use hpos to correct for field offset in interlaced mode. */
|
|
|
|
|
if (VC4_GET_FIELD(val, SCALER_DISPSTATX_FRAME_COUNT) % 2)
|
|
|
|
|
*hpos += mode->crtc_htotal / 2;
|
|
|
|
|
}
|
drm/vc4: Implement precise vblank timestamping.
Precise vblank timestamping is implemented via the
usual scanout position based method. On VC4 the
pixelvalves PV do not have a scanout position
register. Only the hardware video scaler HVS has a
similar register which describes which scanline for
the output is currently composited and stored in the
HVS fifo for later consumption by the PV.
This causes a problem in that the HVS runs at a much
faster clock (system clock / audio gate) than the PV
which runs at video mode dot clock, so the unless the
fifo between HVS and PV is full, the HVS will progress
faster in its observable read line position than video
scan rate, so the HVS position reading can't be directly
translated into a scanout position for timestamp correction.
Additionally when the PV is in vblank, it doesn't consume
from the fifo, so the fifo gets full very quickly and then
the HVS stops compositing until the PV enters active scanout
and starts consuming scanlines from the fifo again, making
new space for the HVS to composite.
Therefore a simple translation of HVS read position into
elapsed time since (or to) start of active scanout does
not work, but for the most interesting cases we can still
get useful and sufficiently accurate results:
1. The PV enters active scanout of a new frame with the
fifo of the HVS completely full, and the HVS can refill
any fifo line which gets consumed and thereby freed up by
the PV during active scanout very quickly. Therefore the
PV and HVS work effectively in lock-step during active
scanout with the fifo never having more than 1 scanline
freed up by the PV before it gets refilled. The PV's
real scanout position is therefore trailing the HVS
compositing position as scanoutpos = hvspos - fifosize
and we can get the true scanoutpos as HVS readpos minus
fifo size, so precise timestamping works while in active
scanout, except for the last few scanlines of the frame,
when the HVS reaches end of frame, stops compositing and
the PV catches up and drains the fifo. This special case
would only introduce minor errors though.
2. If we are in vblank, then we can only guess something
reasonable. If called from vblank irq, we assume the irq is
usually dispatched with minimum delay, so we can take a
timestamp taken at entry into the vblank irq handler as a
baseline and then add a full vblank duration until the
guessed start of active scanout. As irq dispatch is usually
pretty low latency this works with relatively low jitter and
good results.
If we aren't called from vblank then we could be anywhere
within the vblank interval, so we return a neutral result,
simply the current system timestamp, and hope for the best.
Measurement shows the generated timestamps to be rather precise,
and at least never off more than 1 vblank duration worst-case.
Limitations: Doesn't work well yet for interlaced video modes,
therefore disabled in interlaced mode for now.
v2: Use the DISPBASE registers to determine the FIFO size (changes
by anholt)
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> (v2)
2016-06-23 14:17:50 +08:00
|
|
|
|
|
|
|
|
/* This is the offset we need for translating hvs -> pv scanout pos. */
|
|
|
|
|
fifo_lines = vc4_crtc->cob_size / mode->crtc_hdisplay;
|
|
|
|
|
|
|
|
|
|
if (fifo_lines > 0)
|
drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos
If we restrict this helper to only kms drivers (which is the case) we
can look up the correct mode easily ourselves. But it's a bit tricky:
- All legacy drivers look at crtc->hwmode. But that is updated already
at the beginning of the modeset helper, which means when we disable
a pipe. Hence the final timestamps might be a bit off. But since
this is an existing bug I'm not going to change it, but just try to
be bug-for-bug compatible with the current code. This only applies
to radeon&amdgpu.
- i915 tries to get it perfect by updating crtc->hwmode when the pipe
is off (i.e. vblank->enabled = false).
- All other atomic drivers look at crtc->state->adjusted_mode. Those
that look at state->requested_mode simply don't adjust their mode,
so it's the same. That has two problems: Accessing crtc->state from
interrupt handling code is unsafe, and it's updated before we shut
down the pipe. For nonblocking modesets it's even worse.
For atomic drivers try to implement what i915 does. To do that we add
a new hwmode field to the vblank structure, and update it from
drm_calc_timestamping_constants(). For atomic drivers that's called
from the right spot by the helper library already, so all fine. But
for safety let's enforce that.
For legacy driver this function is only called at the end (oh the
fun), which is broken, so again let's not bother and just stay
bug-for-bug compatible.
The benefit is that we can use drm_calc_vbltimestamp_from_scanoutpos
directly to implement ->get_vblank_timestamp in every driver, deleting
a lot of code.
v2: Completely new approach, trying to mimick the i915 solution.
v3: Fixup kerneldoc.
v4: Drop the WARN_ON to check that the vblank is off, atomic helpers
currently unconditionally call this. Recomputing the same stuff should
be harmless.
v5: Fix typos and move misplaced hunks to the right patches (Neil).
v6: Undo hunk movement (kbuild).
Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Cc: Eric Anholt <eric@anholt.net>
Cc: Rob Clark <robdclark@gmail.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-4-daniel.vetter@ffwll.ch
2017-05-09 22:03:28 +08:00
|
|
|
ret = true;
|
drm/vc4: Implement precise vblank timestamping.
Precise vblank timestamping is implemented via the
usual scanout position based method. On VC4 the
pixelvalves PV do not have a scanout position
register. Only the hardware video scaler HVS has a
similar register which describes which scanline for
the output is currently composited and stored in the
HVS fifo for later consumption by the PV.
This causes a problem in that the HVS runs at a much
faster clock (system clock / audio gate) than the PV
which runs at video mode dot clock, so the unless the
fifo between HVS and PV is full, the HVS will progress
faster in its observable read line position than video
scan rate, so the HVS position reading can't be directly
translated into a scanout position for timestamp correction.
Additionally when the PV is in vblank, it doesn't consume
from the fifo, so the fifo gets full very quickly and then
the HVS stops compositing until the PV enters active scanout
and starts consuming scanlines from the fifo again, making
new space for the HVS to composite.
Therefore a simple translation of HVS read position into
elapsed time since (or to) start of active scanout does
not work, but for the most interesting cases we can still
get useful and sufficiently accurate results:
1. The PV enters active scanout of a new frame with the
fifo of the HVS completely full, and the HVS can refill
any fifo line which gets consumed and thereby freed up by
the PV during active scanout very quickly. Therefore the
PV and HVS work effectively in lock-step during active
scanout with the fifo never having more than 1 scanline
freed up by the PV before it gets refilled. The PV's
real scanout position is therefore trailing the HVS
compositing position as scanoutpos = hvspos - fifosize
and we can get the true scanoutpos as HVS readpos minus
fifo size, so precise timestamping works while in active
scanout, except for the last few scanlines of the frame,
when the HVS reaches end of frame, stops compositing and
the PV catches up and drains the fifo. This special case
would only introduce minor errors though.
2. If we are in vblank, then we can only guess something
reasonable. If called from vblank irq, we assume the irq is
usually dispatched with minimum delay, so we can take a
timestamp taken at entry into the vblank irq handler as a
baseline and then add a full vblank duration until the
guessed start of active scanout. As irq dispatch is usually
pretty low latency this works with relatively low jitter and
good results.
If we aren't called from vblank then we could be anywhere
within the vblank interval, so we return a neutral result,
simply the current system timestamp, and hope for the best.
Measurement shows the generated timestamps to be rather precise,
and at least never off more than 1 vblank duration worst-case.
Limitations: Doesn't work well yet for interlaced video modes,
therefore disabled in interlaced mode for now.
v2: Use the DISPBASE registers to determine the FIFO size (changes
by anholt)
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> (v2)
2016-06-23 14:17:50 +08:00
|
|
|
|
|
|
|
|
/* HVS more than fifo_lines into frame for compositing? */
|
|
|
|
|
if (*vpos > fifo_lines) {
|
|
|
|
|
/*
|
|
|
|
|
* We are in active scanout and can get some meaningful results
|
|
|
|
|
* from HVS. The actual PV scanout can not trail behind more
|
|
|
|
|
* than fifo_lines as that is the fifo's capacity. Assume that
|
|
|
|
|
* in active scanout the HVS and PV work in lockstep wrt. HVS
|
|
|
|
|
* refilling the fifo and PV consuming from the fifo, ie.
|
|
|
|
|
* whenever the PV consumes and frees up a scanline in the
|
|
|
|
|
* fifo, the HVS will immediately refill it, therefore
|
|
|
|
|
* incrementing vpos. Therefore we choose HVS read position -
|
|
|
|
|
* fifo size in scanlines as a estimate of the real scanout
|
|
|
|
|
* position of the PV.
|
|
|
|
|
*/
|
|
|
|
|
*vpos -= fifo_lines + 1;
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Less: This happens when we are in vblank and the HVS, after getting
|
|
|
|
|
* the VSTART restart signal from the PV, just started refilling its
|
|
|
|
|
* fifo with new lines from the top-most lines of the new framebuffers.
|
|
|
|
|
* The PV does not scan out in vblank, so does not remove lines from
|
|
|
|
|
* the fifo, so the fifo will be full quickly and the HVS has to pause.
|
|
|
|
|
* We can't get meaningful readings wrt. scanline position of the PV
|
|
|
|
|
* and need to make things up in a approximative but consistent way.
|
|
|
|
|
*/
|
2016-09-29 08:30:25 +08:00
|
|
|
vblank_lines = mode->vtotal - mode->vdisplay;
|
drm/vc4: Implement precise vblank timestamping.
Precise vblank timestamping is implemented via the
usual scanout position based method. On VC4 the
pixelvalves PV do not have a scanout position
register. Only the hardware video scaler HVS has a
similar register which describes which scanline for
the output is currently composited and stored in the
HVS fifo for later consumption by the PV.
This causes a problem in that the HVS runs at a much
faster clock (system clock / audio gate) than the PV
which runs at video mode dot clock, so the unless the
fifo between HVS and PV is full, the HVS will progress
faster in its observable read line position than video
scan rate, so the HVS position reading can't be directly
translated into a scanout position for timestamp correction.
Additionally when the PV is in vblank, it doesn't consume
from the fifo, so the fifo gets full very quickly and then
the HVS stops compositing until the PV enters active scanout
and starts consuming scanlines from the fifo again, making
new space for the HVS to composite.
Therefore a simple translation of HVS read position into
elapsed time since (or to) start of active scanout does
not work, but for the most interesting cases we can still
get useful and sufficiently accurate results:
1. The PV enters active scanout of a new frame with the
fifo of the HVS completely full, and the HVS can refill
any fifo line which gets consumed and thereby freed up by
the PV during active scanout very quickly. Therefore the
PV and HVS work effectively in lock-step during active
scanout with the fifo never having more than 1 scanline
freed up by the PV before it gets refilled. The PV's
real scanout position is therefore trailing the HVS
compositing position as scanoutpos = hvspos - fifosize
and we can get the true scanoutpos as HVS readpos minus
fifo size, so precise timestamping works while in active
scanout, except for the last few scanlines of the frame,
when the HVS reaches end of frame, stops compositing and
the PV catches up and drains the fifo. This special case
would only introduce minor errors though.
2. If we are in vblank, then we can only guess something
reasonable. If called from vblank irq, we assume the irq is
usually dispatched with minimum delay, so we can take a
timestamp taken at entry into the vblank irq handler as a
baseline and then add a full vblank duration until the
guessed start of active scanout. As irq dispatch is usually
pretty low latency this works with relatively low jitter and
good results.
If we aren't called from vblank then we could be anywhere
within the vblank interval, so we return a neutral result,
simply the current system timestamp, and hope for the best.
Measurement shows the generated timestamps to be rather precise,
and at least never off more than 1 vblank duration worst-case.
Limitations: Doesn't work well yet for interlaced video modes,
therefore disabled in interlaced mode for now.
v2: Use the DISPBASE registers to determine the FIFO size (changes
by anholt)
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> (v2)
2016-06-23 14:17:50 +08:00
|
|
|
|
drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos
If we restrict this helper to only kms drivers (which is the case) we
can look up the correct mode easily ourselves. But it's a bit tricky:
- All legacy drivers look at crtc->hwmode. But that is updated already
at the beginning of the modeset helper, which means when we disable
a pipe. Hence the final timestamps might be a bit off. But since
this is an existing bug I'm not going to change it, but just try to
be bug-for-bug compatible with the current code. This only applies
to radeon&amdgpu.
- i915 tries to get it perfect by updating crtc->hwmode when the pipe
is off (i.e. vblank->enabled = false).
- All other atomic drivers look at crtc->state->adjusted_mode. Those
that look at state->requested_mode simply don't adjust their mode,
so it's the same. That has two problems: Accessing crtc->state from
interrupt handling code is unsafe, and it's updated before we shut
down the pipe. For nonblocking modesets it's even worse.
For atomic drivers try to implement what i915 does. To do that we add
a new hwmode field to the vblank structure, and update it from
drm_calc_timestamping_constants(). For atomic drivers that's called
from the right spot by the helper library already, so all fine. But
for safety let's enforce that.
For legacy driver this function is only called at the end (oh the
fun), which is broken, so again let's not bother and just stay
bug-for-bug compatible.
The benefit is that we can use drm_calc_vbltimestamp_from_scanoutpos
directly to implement ->get_vblank_timestamp in every driver, deleting
a lot of code.
v2: Completely new approach, trying to mimick the i915 solution.
v3: Fixup kerneldoc.
v4: Drop the WARN_ON to check that the vblank is off, atomic helpers
currently unconditionally call this. Recomputing the same stuff should
be harmless.
v5: Fix typos and move misplaced hunks to the right patches (Neil).
v6: Undo hunk movement (kbuild).
Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Cc: Eric Anholt <eric@anholt.net>
Cc: Rob Clark <robdclark@gmail.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-4-daniel.vetter@ffwll.ch
2017-05-09 22:03:28 +08:00
|
|
|
if (in_vblank_irq) {
|
drm/vc4: Implement precise vblank timestamping.
Precise vblank timestamping is implemented via the
usual scanout position based method. On VC4 the
pixelvalves PV do not have a scanout position
register. Only the hardware video scaler HVS has a
similar register which describes which scanline for
the output is currently composited and stored in the
HVS fifo for later consumption by the PV.
This causes a problem in that the HVS runs at a much
faster clock (system clock / audio gate) than the PV
which runs at video mode dot clock, so the unless the
fifo between HVS and PV is full, the HVS will progress
faster in its observable read line position than video
scan rate, so the HVS position reading can't be directly
translated into a scanout position for timestamp correction.
Additionally when the PV is in vblank, it doesn't consume
from the fifo, so the fifo gets full very quickly and then
the HVS stops compositing until the PV enters active scanout
and starts consuming scanlines from the fifo again, making
new space for the HVS to composite.
Therefore a simple translation of HVS read position into
elapsed time since (or to) start of active scanout does
not work, but for the most interesting cases we can still
get useful and sufficiently accurate results:
1. The PV enters active scanout of a new frame with the
fifo of the HVS completely full, and the HVS can refill
any fifo line which gets consumed and thereby freed up by
the PV during active scanout very quickly. Therefore the
PV and HVS work effectively in lock-step during active
scanout with the fifo never having more than 1 scanline
freed up by the PV before it gets refilled. The PV's
real scanout position is therefore trailing the HVS
compositing position as scanoutpos = hvspos - fifosize
and we can get the true scanoutpos as HVS readpos minus
fifo size, so precise timestamping works while in active
scanout, except for the last few scanlines of the frame,
when the HVS reaches end of frame, stops compositing and
the PV catches up and drains the fifo. This special case
would only introduce minor errors though.
2. If we are in vblank, then we can only guess something
reasonable. If called from vblank irq, we assume the irq is
usually dispatched with minimum delay, so we can take a
timestamp taken at entry into the vblank irq handler as a
baseline and then add a full vblank duration until the
guessed start of active scanout. As irq dispatch is usually
pretty low latency this works with relatively low jitter and
good results.
If we aren't called from vblank then we could be anywhere
within the vblank interval, so we return a neutral result,
simply the current system timestamp, and hope for the best.
Measurement shows the generated timestamps to be rather precise,
and at least never off more than 1 vblank duration worst-case.
Limitations: Doesn't work well yet for interlaced video modes,
therefore disabled in interlaced mode for now.
v2: Use the DISPBASE registers to determine the FIFO size (changes
by anholt)
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> (v2)
2016-06-23 14:17:50 +08:00
|
|
|
/*
|
|
|
|
|
* Assume the irq handler got called close to first
|
|
|
|
|
* line of vblank, so PV has about a full vblank
|
|
|
|
|
* scanlines to go, and as a base timestamp use the
|
|
|
|
|
* one taken at entry into vblank irq handler, so it
|
|
|
|
|
* is not affected by random delays due to lock
|
|
|
|
|
* contention on event_lock or vblank_time lock in
|
|
|
|
|
* the core.
|
|
|
|
|
*/
|
|
|
|
|
*vpos = -vblank_lines;
|
|
|
|
|
|
|
|
|
|
if (stime)
|
|
|
|
|
*stime = vc4_crtc->t_vblank;
|
|
|
|
|
if (etime)
|
|
|
|
|
*etime = vc4_crtc->t_vblank;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If the HVS fifo is not yet full then we know for certain
|
|
|
|
|
* we are at the very beginning of vblank, as the hvs just
|
|
|
|
|
* started refilling, and the stime and etime timestamps
|
|
|
|
|
* truly correspond to start of vblank.
|
drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos
If we restrict this helper to only kms drivers (which is the case) we
can look up the correct mode easily ourselves. But it's a bit tricky:
- All legacy drivers look at crtc->hwmode. But that is updated already
at the beginning of the modeset helper, which means when we disable
a pipe. Hence the final timestamps might be a bit off. But since
this is an existing bug I'm not going to change it, but just try to
be bug-for-bug compatible with the current code. This only applies
to radeon&amdgpu.
- i915 tries to get it perfect by updating crtc->hwmode when the pipe
is off (i.e. vblank->enabled = false).
- All other atomic drivers look at crtc->state->adjusted_mode. Those
that look at state->requested_mode simply don't adjust their mode,
so it's the same. That has two problems: Accessing crtc->state from
interrupt handling code is unsafe, and it's updated before we shut
down the pipe. For nonblocking modesets it's even worse.
For atomic drivers try to implement what i915 does. To do that we add
a new hwmode field to the vblank structure, and update it from
drm_calc_timestamping_constants(). For atomic drivers that's called
from the right spot by the helper library already, so all fine. But
for safety let's enforce that.
For legacy driver this function is only called at the end (oh the
fun), which is broken, so again let's not bother and just stay
bug-for-bug compatible.
The benefit is that we can use drm_calc_vbltimestamp_from_scanoutpos
directly to implement ->get_vblank_timestamp in every driver, deleting
a lot of code.
v2: Completely new approach, trying to mimick the i915 solution.
v3: Fixup kerneldoc.
v4: Drop the WARN_ON to check that the vblank is off, atomic helpers
currently unconditionally call this. Recomputing the same stuff should
be harmless.
v5: Fix typos and move misplaced hunks to the right patches (Neil).
v6: Undo hunk movement (kbuild).
Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Cc: Eric Anholt <eric@anholt.net>
Cc: Rob Clark <robdclark@gmail.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-4-daniel.vetter@ffwll.ch
2017-05-09 22:03:28 +08:00
|
|
|
*
|
|
|
|
|
* Unfortunately there's no way to report this to upper levels
|
|
|
|
|
* and make it more useful.
|
drm/vc4: Implement precise vblank timestamping.
Precise vblank timestamping is implemented via the
usual scanout position based method. On VC4 the
pixelvalves PV do not have a scanout position
register. Only the hardware video scaler HVS has a
similar register which describes which scanline for
the output is currently composited and stored in the
HVS fifo for later consumption by the PV.
This causes a problem in that the HVS runs at a much
faster clock (system clock / audio gate) than the PV
which runs at video mode dot clock, so the unless the
fifo between HVS and PV is full, the HVS will progress
faster in its observable read line position than video
scan rate, so the HVS position reading can't be directly
translated into a scanout position for timestamp correction.
Additionally when the PV is in vblank, it doesn't consume
from the fifo, so the fifo gets full very quickly and then
the HVS stops compositing until the PV enters active scanout
and starts consuming scanlines from the fifo again, making
new space for the HVS to composite.
Therefore a simple translation of HVS read position into
elapsed time since (or to) start of active scanout does
not work, but for the most interesting cases we can still
get useful and sufficiently accurate results:
1. The PV enters active scanout of a new frame with the
fifo of the HVS completely full, and the HVS can refill
any fifo line which gets consumed and thereby freed up by
the PV during active scanout very quickly. Therefore the
PV and HVS work effectively in lock-step during active
scanout with the fifo never having more than 1 scanline
freed up by the PV before it gets refilled. The PV's
real scanout position is therefore trailing the HVS
compositing position as scanoutpos = hvspos - fifosize
and we can get the true scanoutpos as HVS readpos minus
fifo size, so precise timestamping works while in active
scanout, except for the last few scanlines of the frame,
when the HVS reaches end of frame, stops compositing and
the PV catches up and drains the fifo. This special case
would only introduce minor errors though.
2. If we are in vblank, then we can only guess something
reasonable. If called from vblank irq, we assume the irq is
usually dispatched with minimum delay, so we can take a
timestamp taken at entry into the vblank irq handler as a
baseline and then add a full vblank duration until the
guessed start of active scanout. As irq dispatch is usually
pretty low latency this works with relatively low jitter and
good results.
If we aren't called from vblank then we could be anywhere
within the vblank interval, so we return a neutral result,
simply the current system timestamp, and hope for the best.
Measurement shows the generated timestamps to be rather precise,
and at least never off more than 1 vblank duration worst-case.
Limitations: Doesn't work well yet for interlaced video modes,
therefore disabled in interlaced mode for now.
v2: Use the DISPBASE registers to determine the FIFO size (changes
by anholt)
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> (v2)
2016-06-23 14:17:50 +08:00
|
|
|
*/
|
|
|
|
|
} else {
|
|
|
|
|
/*
|
|
|
|
|
* No clue where we are inside vblank. Return a vpos of zero,
|
|
|
|
|
* which will cause calling code to just return the etime
|
|
|
|
|
* timestamp uncorrected. At least this is no worse than the
|
|
|
|
|
* standard fallback.
|
|
|
|
|
*/
|
|
|
|
|
*vpos = 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2015-03-03 05:01:12 +08:00
|
|
|
static void vc4_crtc_destroy(struct drm_crtc *crtc)
|
|
|
|
|
{
|
|
|
|
|
drm_crtc_cleanup(crtc);
|
|
|
|
|
}
|
|
|
|
|
|
2016-04-01 09:38:20 +08:00
|
|
|
static void
|
|
|
|
|
vc4_crtc_lut_load(struct drm_crtc *crtc)
|
|
|
|
|
{
|
|
|
|
|
struct drm_device *dev = crtc->dev;
|
|
|
|
|
struct vc4_dev *vc4 = to_vc4_dev(dev);
|
|
|
|
|
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
|
|
|
|
|
u32 i;
|
|
|
|
|
|
|
|
|
|
/* The LUT memory is laid out with each HVS channel in order,
|
|
|
|
|
* each of which takes 256 writes for R, 256 for G, then 256
|
|
|
|
|
* for B.
|
|
|
|
|
*/
|
|
|
|
|
HVS_WRITE(SCALER_GAMADDR,
|
|
|
|
|
SCALER_GAMADDR_AUTOINC |
|
|
|
|
|
(vc4_crtc->channel * 3 * crtc->gamma_size));
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < crtc->gamma_size; i++)
|
|
|
|
|
HVS_WRITE(SCALER_GAMDATA, vc4_crtc->lut_r[i]);
|
|
|
|
|
for (i = 0; i < crtc->gamma_size; i++)
|
|
|
|
|
HVS_WRITE(SCALER_GAMDATA, vc4_crtc->lut_g[i]);
|
|
|
|
|
for (i = 0; i < crtc->gamma_size; i++)
|
|
|
|
|
HVS_WRITE(SCALER_GAMDATA, vc4_crtc->lut_b[i]);
|
|
|
|
|
}
|
|
|
|
|
|
2016-06-07 18:49:30 +08:00
|
|
|
static int
|
2016-04-01 09:38:20 +08:00
|
|
|
vc4_crtc_gamma_set(struct drm_crtc *crtc, u16 *r, u16 *g, u16 *b,
|
2017-04-03 16:33:01 +08:00
|
|
|
uint32_t size,
|
|
|
|
|
struct drm_modeset_acquire_ctx *ctx)
|
2016-04-01 09:38:20 +08:00
|
|
|
{
|
|
|
|
|
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
|
|
|
|
|
u32 i;
|
|
|
|
|
|
2016-06-07 18:49:30 +08:00
|
|
|
for (i = 0; i < size; i++) {
|
2016-04-01 09:38:20 +08:00
|
|
|
vc4_crtc->lut_r[i] = r[i] >> 8;
|
|
|
|
|
vc4_crtc->lut_g[i] = g[i] >> 8;
|
|
|
|
|
vc4_crtc->lut_b[i] = b[i] >> 8;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
vc4_crtc_lut_load(crtc);
|
2016-06-07 18:49:30 +08:00
|
|
|
|
|
|
|
|
return 0;
|
2016-04-01 09:38:20 +08:00
|
|
|
}
|
|
|
|
|
|
2015-03-03 05:01:12 +08:00
|
|
|
static u32 vc4_get_fifo_full_level(u32 format)
|
|
|
|
|
{
|
|
|
|
|
static const u32 fifo_len_bytes = 64;
|
|
|
|
|
static const u32 hvs_latency_pix = 6;
|
|
|
|
|
|
|
|
|
|
switch (format) {
|
|
|
|
|
case PV_CONTROL_FORMAT_DSIV_16:
|
|
|
|
|
case PV_CONTROL_FORMAT_DSIC_16:
|
|
|
|
|
return fifo_len_bytes - 2 * hvs_latency_pix;
|
|
|
|
|
case PV_CONTROL_FORMAT_DSIV_18:
|
|
|
|
|
return fifo_len_bytes - 14;
|
|
|
|
|
case PV_CONTROL_FORMAT_24:
|
|
|
|
|
case PV_CONTROL_FORMAT_DSIV_24:
|
|
|
|
|
default:
|
|
|
|
|
return fifo_len_bytes - 3 * hvs_latency_pix;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
2016-12-15 03:46:15 +08:00
|
|
|
* Returns the encoder attached to the CRTC.
|
|
|
|
|
*
|
|
|
|
|
* VC4 can only scan out to one encoder at a time, while the DRM core
|
|
|
|
|
* allows drivers to push pixels to more than one encoder from the
|
|
|
|
|
* same CRTC.
|
2015-03-03 05:01:12 +08:00
|
|
|
*/
|
2016-12-15 03:46:15 +08:00
|
|
|
static struct drm_encoder *vc4_get_crtc_encoder(struct drm_crtc *crtc)
|
2015-03-03 05:01:12 +08:00
|
|
|
{
|
|
|
|
|
struct drm_connector *connector;
|
2017-05-13 00:41:00 +08:00
|
|
|
struct drm_connector_list_iter conn_iter;
|
2015-03-03 05:01:12 +08:00
|
|
|
|
2017-05-13 00:41:00 +08:00
|
|
|
drm_connector_list_iter_begin(crtc->dev, &conn_iter);
|
|
|
|
|
drm_for_each_connector_iter(connector, &conn_iter) {
|
2015-10-23 13:38:00 +08:00
|
|
|
if (connector->state->crtc == crtc) {
|
2017-05-13 00:41:00 +08:00
|
|
|
drm_connector_list_iter_end(&conn_iter);
|
2016-12-15 03:46:15 +08:00
|
|
|
return connector->encoder;
|
2015-03-03 05:01:12 +08:00
|
|
|
}
|
|
|
|
|
}
|
2017-05-13 00:41:00 +08:00
|
|
|
drm_connector_list_iter_end(&conn_iter);
|
2015-03-03 05:01:12 +08:00
|
|
|
|
2016-12-15 03:46:15 +08:00
|
|
|
return NULL;
|
2015-03-03 05:01:12 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc)
|
|
|
|
|
{
|
2016-02-17 02:24:08 +08:00
|
|
|
struct drm_device *dev = crtc->dev;
|
|
|
|
|
struct vc4_dev *vc4 = to_vc4_dev(dev);
|
2016-12-15 03:46:15 +08:00
|
|
|
struct drm_encoder *encoder = vc4_get_crtc_encoder(crtc);
|
|
|
|
|
struct vc4_encoder *vc4_encoder = to_vc4_encoder(encoder);
|
2015-03-03 05:01:12 +08:00
|
|
|
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
|
|
|
|
|
struct drm_crtc_state *state = crtc->state;
|
|
|
|
|
struct drm_display_mode *mode = &state->adjusted_mode;
|
|
|
|
|
bool interlace = mode->flags & DRM_MODE_FLAG_INTERLACE;
|
2016-09-30 06:34:44 +08:00
|
|
|
u32 pixel_rep = (mode->flags & DRM_MODE_FLAG_DBLCLK) ? 2 : 1;
|
2016-12-15 03:46:15 +08:00
|
|
|
bool is_dsi = (vc4_encoder->type == VC4_ENCODER_TYPE_DSI0 ||
|
|
|
|
|
vc4_encoder->type == VC4_ENCODER_TYPE_DSI1);
|
|
|
|
|
u32 format = is_dsi ? PV_CONTROL_FORMAT_DSIV_24 : PV_CONTROL_FORMAT_24;
|
2015-03-03 05:01:12 +08:00
|
|
|
bool debug_dump_regs = false;
|
|
|
|
|
|
|
|
|
|
if (debug_dump_regs) {
|
|
|
|
|
DRM_INFO("CRTC %d regs before:\n", drm_crtc_index(crtc));
|
|
|
|
|
vc4_crtc_dump_regs(vc4_crtc);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Reset the PV fifo. */
|
|
|
|
|
CRTC_WRITE(PV_CONTROL, 0);
|
|
|
|
|
CRTC_WRITE(PV_CONTROL, PV_CONTROL_FIFO_CLR | PV_CONTROL_EN);
|
|
|
|
|
CRTC_WRITE(PV_CONTROL, 0);
|
|
|
|
|
|
|
|
|
|
CRTC_WRITE(PV_HORZA,
|
2016-09-30 06:34:44 +08:00
|
|
|
VC4_SET_FIELD((mode->htotal -
|
|
|
|
|
mode->hsync_end) * pixel_rep,
|
2015-03-03 05:01:12 +08:00
|
|
|
PV_HORZA_HBP) |
|
2016-09-30 06:34:44 +08:00
|
|
|
VC4_SET_FIELD((mode->hsync_end -
|
|
|
|
|
mode->hsync_start) * pixel_rep,
|
2015-03-03 05:01:12 +08:00
|
|
|
PV_HORZA_HSYNC));
|
|
|
|
|
CRTC_WRITE(PV_HORZB,
|
2016-09-30 06:34:44 +08:00
|
|
|
VC4_SET_FIELD((mode->hsync_start -
|
|
|
|
|
mode->hdisplay) * pixel_rep,
|
2015-03-03 05:01:12 +08:00
|
|
|
PV_HORZB_HFP) |
|
2016-09-30 06:34:44 +08:00
|
|
|
VC4_SET_FIELD(mode->hdisplay * pixel_rep, PV_HORZB_HACTIVE));
|
2015-03-03 05:01:12 +08:00
|
|
|
|
2016-02-16 09:31:41 +08:00
|
|
|
CRTC_WRITE(PV_VERTA,
|
2016-09-29 08:30:25 +08:00
|
|
|
VC4_SET_FIELD(mode->crtc_vtotal - mode->crtc_vsync_end,
|
2016-02-16 09:31:41 +08:00
|
|
|
PV_VERTA_VBP) |
|
2016-09-29 08:30:25 +08:00
|
|
|
VC4_SET_FIELD(mode->crtc_vsync_end - mode->crtc_vsync_start,
|
2016-02-16 09:31:41 +08:00
|
|
|
PV_VERTA_VSYNC));
|
|
|
|
|
CRTC_WRITE(PV_VERTB,
|
2016-09-29 08:30:25 +08:00
|
|
|
VC4_SET_FIELD(mode->crtc_vsync_start - mode->crtc_vdisplay,
|
2016-02-16 09:31:41 +08:00
|
|
|
PV_VERTB_VFP) |
|
2016-09-29 08:30:25 +08:00
|
|
|
VC4_SET_FIELD(mode->crtc_vdisplay, PV_VERTB_VACTIVE));
|
2016-02-16 09:31:41 +08:00
|
|
|
|
2015-03-03 05:01:12 +08:00
|
|
|
if (interlace) {
|
|
|
|
|
CRTC_WRITE(PV_VERTA_EVEN,
|
2016-09-29 08:30:25 +08:00
|
|
|
VC4_SET_FIELD(mode->crtc_vtotal -
|
|
|
|
|
mode->crtc_vsync_end - 1,
|
2015-03-03 05:01:12 +08:00
|
|
|
PV_VERTA_VBP) |
|
2016-09-29 08:30:25 +08:00
|
|
|
VC4_SET_FIELD(mode->crtc_vsync_end -
|
|
|
|
|
mode->crtc_vsync_start,
|
2015-03-03 05:01:12 +08:00
|
|
|
PV_VERTA_VSYNC));
|
|
|
|
|
CRTC_WRITE(PV_VERTB_EVEN,
|
2016-09-29 08:30:25 +08:00
|
|
|
VC4_SET_FIELD(mode->crtc_vsync_start -
|
|
|
|
|
mode->crtc_vdisplay,
|
2015-03-03 05:01:12 +08:00
|
|
|
PV_VERTB_VFP) |
|
2016-09-29 08:30:25 +08:00
|
|
|
VC4_SET_FIELD(mode->crtc_vdisplay, PV_VERTB_VACTIVE));
|
|
|
|
|
|
|
|
|
|
/* We set up first field even mode for HDMI. VEC's
|
|
|
|
|
* NTSC mode would want first field odd instead, once
|
|
|
|
|
* we support it (to do so, set ODD_FIRST and put the
|
|
|
|
|
* delay in VSYNCD_EVEN instead).
|
|
|
|
|
*/
|
|
|
|
|
CRTC_WRITE(PV_V_CONTROL,
|
|
|
|
|
PV_VCONTROL_CONTINUOUS |
|
2016-12-15 03:46:15 +08:00
|
|
|
(is_dsi ? PV_VCONTROL_DSI : 0) |
|
2016-09-29 08:30:25 +08:00
|
|
|
PV_VCONTROL_INTERLACE |
|
2016-09-30 06:34:44 +08:00
|
|
|
VC4_SET_FIELD(mode->htotal * pixel_rep / 2,
|
2016-09-29 08:30:25 +08:00
|
|
|
PV_VCONTROL_ODD_DELAY));
|
|
|
|
|
CRTC_WRITE(PV_VSYNCD_EVEN, 0);
|
|
|
|
|
} else {
|
2016-12-15 03:46:15 +08:00
|
|
|
CRTC_WRITE(PV_V_CONTROL,
|
|
|
|
|
PV_VCONTROL_CONTINUOUS |
|
|
|
|
|
(is_dsi ? PV_VCONTROL_DSI : 0));
|
2015-03-03 05:01:12 +08:00
|
|
|
}
|
|
|
|
|
|
2016-09-30 06:34:44 +08:00
|
|
|
CRTC_WRITE(PV_HACT_ACT, mode->hdisplay * pixel_rep);
|
2015-03-03 05:01:12 +08:00
|
|
|
|
|
|
|
|
CRTC_WRITE(PV_CONTROL,
|
|
|
|
|
VC4_SET_FIELD(format, PV_CONTROL_FORMAT) |
|
|
|
|
|
VC4_SET_FIELD(vc4_get_fifo_full_level(format),
|
|
|
|
|
PV_CONTROL_FIFO_LEVEL) |
|
2016-09-30 06:34:44 +08:00
|
|
|
VC4_SET_FIELD(pixel_rep - 1, PV_CONTROL_PIXEL_REP) |
|
2015-03-03 05:01:12 +08:00
|
|
|
PV_CONTROL_CLR_AT_START |
|
|
|
|
|
PV_CONTROL_TRIGGER_UNDERFLOW |
|
|
|
|
|
PV_CONTROL_WAIT_HSTART |
|
2016-12-15 03:46:15 +08:00
|
|
|
VC4_SET_FIELD(vc4_encoder->clock_select,
|
|
|
|
|
PV_CONTROL_CLK_SELECT) |
|
2015-03-03 05:01:12 +08:00
|
|
|
PV_CONTROL_FIFO_CLR |
|
|
|
|
|
PV_CONTROL_EN);
|
|
|
|
|
|
2016-02-17 02:24:08 +08:00
|
|
|
HVS_WRITE(SCALER_DISPBKGNDX(vc4_crtc->channel),
|
|
|
|
|
SCALER_DISPBKGND_AUTOHS |
|
2016-04-01 09:38:20 +08:00
|
|
|
SCALER_DISPBKGND_GAMMA |
|
2016-02-17 02:24:08 +08:00
|
|
|
(interlace ? SCALER_DISPBKGND_INTERLACE : 0));
|
|
|
|
|
|
2016-04-01 09:38:20 +08:00
|
|
|
/* Reload the LUT, since the SRAMs would have been disabled if
|
|
|
|
|
* all CRTCs had SCALER_DISPBKGND_GAMMA unset at once.
|
|
|
|
|
*/
|
|
|
|
|
vc4_crtc_lut_load(crtc);
|
|
|
|
|
|
2015-03-03 05:01:12 +08:00
|
|
|
if (debug_dump_regs) {
|
|
|
|
|
DRM_INFO("CRTC %d regs after:\n", drm_crtc_index(crtc));
|
|
|
|
|
vc4_crtc_dump_regs(vc4_crtc);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void require_hvs_enabled(struct drm_device *dev)
|
|
|
|
|
{
|
|
|
|
|
struct vc4_dev *vc4 = to_vc4_dev(dev);
|
|
|
|
|
|
|
|
|
|
WARN_ON_ONCE((HVS_READ(SCALER_DISPCTRL) & SCALER_DISPCTRL_ENABLE) !=
|
|
|
|
|
SCALER_DISPCTRL_ENABLE);
|
|
|
|
|
}
|
|
|
|
|
|
2017-06-30 17:36:45 +08:00
|
|
|
static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
|
|
|
|
|
struct drm_crtc_state *old_state)
|
2015-03-03 05:01:12 +08:00
|
|
|
{
|
|
|
|
|
struct drm_device *dev = crtc->dev;
|
|
|
|
|
struct vc4_dev *vc4 = to_vc4_dev(dev);
|
|
|
|
|
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
|
|
|
|
|
u32 chan = vc4_crtc->channel;
|
|
|
|
|
int ret;
|
|
|
|
|
require_hvs_enabled(dev);
|
|
|
|
|
|
2016-07-20 02:59:01 +08:00
|
|
|
/* Disable vblank irq handling before crtc is disabled. */
|
|
|
|
|
drm_crtc_vblank_off(crtc);
|
|
|
|
|
|
2015-03-03 05:01:12 +08:00
|
|
|
CRTC_WRITE(PV_V_CONTROL,
|
|
|
|
|
CRTC_READ(PV_V_CONTROL) & ~PV_VCONTROL_VIDEN);
|
|
|
|
|
ret = wait_for(!(CRTC_READ(PV_V_CONTROL) & PV_VCONTROL_VIDEN), 1);
|
|
|
|
|
WARN_ONCE(ret, "Timeout waiting for !PV_VCONTROL_VIDEN\n");
|
|
|
|
|
|
|
|
|
|
if (HVS_READ(SCALER_DISPCTRLX(chan)) &
|
|
|
|
|
SCALER_DISPCTRLX_ENABLE) {
|
|
|
|
|
HVS_WRITE(SCALER_DISPCTRLX(chan),
|
|
|
|
|
SCALER_DISPCTRLX_RESET);
|
|
|
|
|
|
|
|
|
|
/* While the docs say that reset is self-clearing, it
|
|
|
|
|
* seems it doesn't actually.
|
|
|
|
|
*/
|
|
|
|
|
HVS_WRITE(SCALER_DISPCTRLX(chan), 0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Once we leave, the scaler should be disabled and its fifo empty. */
|
|
|
|
|
|
|
|
|
|
WARN_ON_ONCE(HVS_READ(SCALER_DISPCTRLX(chan)) & SCALER_DISPCTRLX_RESET);
|
|
|
|
|
|
|
|
|
|
WARN_ON_ONCE(VC4_GET_FIELD(HVS_READ(SCALER_DISPSTATX(chan)),
|
|
|
|
|
SCALER_DISPSTATX_MODE) !=
|
|
|
|
|
SCALER_DISPSTATX_MODE_DISABLED);
|
|
|
|
|
|
|
|
|
|
WARN_ON_ONCE((HVS_READ(SCALER_DISPSTATX(chan)) &
|
|
|
|
|
(SCALER_DISPSTATX_FULL | SCALER_DISPSTATX_EMPTY)) !=
|
|
|
|
|
SCALER_DISPSTATX_EMPTY);
|
2017-06-16 16:30:33 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Make sure we issue a vblank event after disabling the CRTC if
|
|
|
|
|
* someone was waiting it.
|
|
|
|
|
*/
|
|
|
|
|
if (crtc->state->event) {
|
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
|
|
spin_lock_irqsave(&dev->event_lock, flags);
|
|
|
|
|
drm_crtc_send_vblank_event(crtc, crtc->state->event);
|
|
|
|
|
crtc->state->event = NULL;
|
|
|
|
|
spin_unlock_irqrestore(&dev->event_lock, flags);
|
|
|
|
|
}
|
2015-03-03 05:01:12 +08:00
|
|
|
}
|
|
|
|
|
|
2017-06-23 04:25:26 +08:00
|
|
|
static void vc4_crtc_update_dlist(struct drm_crtc *crtc)
|
|
|
|
|
{
|
|
|
|
|
struct drm_device *dev = crtc->dev;
|
|
|
|
|
struct vc4_dev *vc4 = to_vc4_dev(dev);
|
|
|
|
|
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
|
|
|
|
|
struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc->state);
|
|
|
|
|
|
|
|
|
|
if (crtc->state->event) {
|
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
|
|
crtc->state->event->pipe = drm_crtc_index(crtc);
|
|
|
|
|
|
|
|
|
|
WARN_ON(drm_crtc_vblank_get(crtc) != 0);
|
|
|
|
|
|
|
|
|
|
spin_lock_irqsave(&dev->event_lock, flags);
|
|
|
|
|
vc4_crtc->event = crtc->state->event;
|
|
|
|
|
crtc->state->event = NULL;
|
|
|
|
|
|
|
|
|
|
HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
|
|
|
|
|
vc4_state->mm.start);
|
|
|
|
|
|
|
|
|
|
spin_unlock_irqrestore(&dev->event_lock, flags);
|
|
|
|
|
} else {
|
|
|
|
|
HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
|
|
|
|
|
vc4_state->mm.start);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-06-30 17:36:44 +08:00
|
|
|
static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
|
|
|
|
|
struct drm_crtc_state *old_state)
|
2015-03-03 05:01:12 +08:00
|
|
|
{
|
|
|
|
|
struct drm_device *dev = crtc->dev;
|
|
|
|
|
struct vc4_dev *vc4 = to_vc4_dev(dev);
|
|
|
|
|
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
|
|
|
|
|
struct drm_crtc_state *state = crtc->state;
|
|
|
|
|
struct drm_display_mode *mode = &state->adjusted_mode;
|
|
|
|
|
|
|
|
|
|
require_hvs_enabled(dev);
|
|
|
|
|
|
2017-06-23 04:25:26 +08:00
|
|
|
/* Enable vblank irq handling before crtc is started otherwise
|
|
|
|
|
* drm_crtc_get_vblank() fails in vc4_crtc_update_dlist().
|
|
|
|
|
*/
|
|
|
|
|
drm_crtc_vblank_on(crtc);
|
|
|
|
|
vc4_crtc_update_dlist(crtc);
|
|
|
|
|
|
2015-03-03 05:01:12 +08:00
|
|
|
/* Turn on the scaler, which will wait for vstart to start
|
|
|
|
|
* compositing.
|
|
|
|
|
*/
|
|
|
|
|
HVS_WRITE(SCALER_DISPCTRLX(vc4_crtc->channel),
|
|
|
|
|
VC4_SET_FIELD(mode->hdisplay, SCALER_DISPCTRLX_WIDTH) |
|
|
|
|
|
VC4_SET_FIELD(mode->vdisplay, SCALER_DISPCTRLX_HEIGHT) |
|
|
|
|
|
SCALER_DISPCTRLX_ENABLE);
|
|
|
|
|
|
|
|
|
|
/* Turn on the pixel valve, which will emit the vstart signal. */
|
|
|
|
|
CRTC_WRITE(PV_V_CONTROL,
|
|
|
|
|
CRTC_READ(PV_V_CONTROL) | PV_VCONTROL_VIDEN);
|
|
|
|
|
}
|
|
|
|
|
|
2017-05-25 22:19:22 +08:00
|
|
|
static enum drm_mode_status vc4_crtc_mode_valid(struct drm_crtc *crtc,
|
|
|
|
|
const struct drm_display_mode *mode)
|
2016-07-20 02:58:58 +08:00
|
|
|
{
|
2016-07-20 02:58:59 +08:00
|
|
|
/* Do not allow doublescan modes from user space */
|
2017-05-25 22:19:22 +08:00
|
|
|
if (mode->flags & DRM_MODE_FLAG_DBLSCAN) {
|
2016-07-20 02:58:59 +08:00
|
|
|
DRM_DEBUG_KMS("[CRTC:%d] Doublescan mode rejected.\n",
|
|
|
|
|
crtc->base.id);
|
2017-05-25 22:19:22 +08:00
|
|
|
return MODE_NO_DBLESCAN;
|
2016-07-20 02:58:59 +08:00
|
|
|
}
|
|
|
|
|
|
2017-05-25 22:19:22 +08:00
|
|
|
return MODE_OK;
|
2016-07-20 02:58:58 +08:00
|
|
|
}
|
|
|
|
|
|
2015-03-03 05:01:12 +08:00
|
|
|
static int vc4_crtc_atomic_check(struct drm_crtc *crtc,
|
|
|
|
|
struct drm_crtc_state *state)
|
|
|
|
|
{
|
2015-12-29 05:25:41 +08:00
|
|
|
struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(state);
|
2015-03-03 05:01:12 +08:00
|
|
|
struct drm_device *dev = crtc->dev;
|
|
|
|
|
struct vc4_dev *vc4 = to_vc4_dev(dev);
|
|
|
|
|
struct drm_plane *plane;
|
2015-12-29 05:25:41 +08:00
|
|
|
unsigned long flags;
|
2016-06-02 22:21:44 +08:00
|
|
|
const struct drm_plane_state *plane_state;
|
2015-03-03 05:01:12 +08:00
|
|
|
u32 dlist_count = 0;
|
2015-12-29 05:25:41 +08:00
|
|
|
int ret;
|
2015-03-03 05:01:12 +08:00
|
|
|
|
|
|
|
|
/* The pixelvalve can only feed one encoder (and encoders are
|
|
|
|
|
* 1:1 with connectors.)
|
|
|
|
|
*/
|
2016-01-04 19:53:20 +08:00
|
|
|
if (hweight32(state->connector_mask) > 1)
|
2015-03-03 05:01:12 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
2016-06-02 22:21:44 +08:00
|
|
|
drm_atomic_crtc_state_for_each_plane_state(plane, plane_state, state)
|
2015-03-03 05:01:12 +08:00
|
|
|
dlist_count += vc4_plane_dlist_size(plane_state);
|
|
|
|
|
|
|
|
|
|
dlist_count++; /* Account for SCALER_CTL0_END. */
|
|
|
|
|
|
2015-12-29 05:25:41 +08:00
|
|
|
spin_lock_irqsave(&vc4->hvs->mm_lock, flags);
|
|
|
|
|
ret = drm_mm_insert_node(&vc4->hvs->dlist_mm, &vc4_state->mm,
|
2017-02-03 05:04:38 +08:00
|
|
|
dlist_count);
|
2015-12-29 05:25:41 +08:00
|
|
|
spin_unlock_irqrestore(&vc4->hvs->mm_lock, flags);
|
|
|
|
|
if (ret)
|
|
|
|
|
return ret;
|
2015-03-03 05:01:12 +08:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void vc4_crtc_atomic_flush(struct drm_crtc *crtc,
|
|
|
|
|
struct drm_crtc_state *old_state)
|
|
|
|
|
{
|
|
|
|
|
struct drm_device *dev = crtc->dev;
|
|
|
|
|
struct vc4_dev *vc4 = to_vc4_dev(dev);
|
2015-12-29 05:25:41 +08:00
|
|
|
struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc->state);
|
2015-03-03 05:01:12 +08:00
|
|
|
struct drm_plane *plane;
|
|
|
|
|
bool debug_dump_regs = false;
|
2015-12-29 05:25:41 +08:00
|
|
|
u32 __iomem *dlist_start = vc4->hvs->dlist + vc4_state->mm.start;
|
|
|
|
|
u32 __iomem *dlist_next = dlist_start;
|
2015-03-03 05:01:12 +08:00
|
|
|
|
|
|
|
|
if (debug_dump_regs) {
|
|
|
|
|
DRM_INFO("CRTC %d HVS before:\n", drm_crtc_index(crtc));
|
|
|
|
|
vc4_hvs_dump_state(dev);
|
|
|
|
|
}
|
|
|
|
|
|
2015-12-29 05:25:41 +08:00
|
|
|
/* Copy all the active planes' dlist contents to the hardware dlist. */
|
2015-03-03 05:01:12 +08:00
|
|
|
drm_atomic_crtc_for_each_plane(plane, crtc) {
|
|
|
|
|
dlist_next += vc4_plane_write_dlist(plane, dlist_next);
|
|
|
|
|
}
|
|
|
|
|
|
2015-12-29 05:25:41 +08:00
|
|
|
writel(SCALER_CTL0_END, dlist_next);
|
|
|
|
|
dlist_next++;
|
|
|
|
|
|
|
|
|
|
WARN_ON_ONCE(dlist_next - dlist_start != vc4_state->mm.size);
|
|
|
|
|
|
2017-06-23 04:25:26 +08:00
|
|
|
/* Only update DISPLIST if the CRTC was already running and is not
|
|
|
|
|
* being disabled.
|
|
|
|
|
* vc4_crtc_enable() takes care of updating the dlist just after
|
|
|
|
|
* re-enabling VBLANK interrupts and before enabling the engine.
|
|
|
|
|
* If the CRTC is being disabled, there's no point in updating this
|
|
|
|
|
* information.
|
|
|
|
|
*/
|
|
|
|
|
if (crtc->state->active && old_state->active)
|
|
|
|
|
vc4_crtc_update_dlist(crtc);
|
drm/vc4: Make pageflip completion handling more robust.
Protect both the setup of the pageflip event and the
latching of the new requested displaylist head pointer
by the event lock, so we can't get into a situation
where vc4_atomic_flush latches the new display list via
HVS_WRITE, then immediately gets preempted before queueing
the pageflip event, then the page-flip completes in hw and
the vc4_crtc_handle_page_flip() runs and no-ops due to
lack of a pending pageflip event, then vc4_atomic_flush
continues and only then queues the pageflip event - after
the page flip handling already no-oped. This would cause
flip completion handling only at the next vblank - one
frame too late.
In vc4_crtc_handle_page_flip() check the actual DL head
pointer in SCALER_DISPLACTX against the requested pointer
for page flip to make sure that the flip actually really
completed in the current vblank and doesn't get deferred
to the next one because the DL head pointer was written
a bit too late into SCALER_DISPLISTX, after start of
vblank, and missed the boat. This avoids handling a
pageflip completion too early - one frame too early.
According to Eric, DL head pointer updates which were
written into the HVS DISPLISTX reg get committed to hardware
at the last pixel of active scanout. Our vblank interrupt
handler, as triggered by PV_INT_VFP_START irq, gets to run
earliest at the first pixel of HBLANK at the end of the
last scanline of active scanout, ie. vblank irq handling
runs at least 1 pixel duration after a potential pageflip
completion happened in hardware.
This ordering of events in the hardware, together with the
lock protection and SCALER_DISPLACTX sampling of this patch,
guarantees that pageflip completion handling only runs at
exactly the vblank irq of actual pageflip completion in all
cases.
Background info from Eric about the relative timing of
HVS, PV's and trigger points for interrupts, DL updates:
https://lists.freedesktop.org/archives/dri-devel/2016-May/107510.html
Tested on RPi 2B with hardware timing measurement equipment
and shown to no longer complete flips too early or too late.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
2016-05-18 20:02:46 +08:00
|
|
|
|
|
|
|
|
if (debug_dump_regs) {
|
|
|
|
|
DRM_INFO("CRTC %d HVS after:\n", drm_crtc_index(crtc));
|
|
|
|
|
vc4_hvs_dump_state(dev);
|
2015-03-03 05:01:12 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-02-07 17:16:34 +08:00
|
|
|
static int vc4_enable_vblank(struct drm_crtc *crtc)
|
2015-03-03 05:01:12 +08:00
|
|
|
{
|
2017-01-09 19:25:45 +08:00
|
|
|
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
|
2015-03-03 05:01:12 +08:00
|
|
|
|
|
|
|
|
CRTC_WRITE(PV_INTEN, PV_INT_VFP_START);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2017-02-07 17:16:34 +08:00
|
|
|
static void vc4_disable_vblank(struct drm_crtc *crtc)
|
2015-03-03 05:01:12 +08:00
|
|
|
{
|
2017-01-09 19:25:45 +08:00
|
|
|
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
|
2015-03-03 05:01:12 +08:00
|
|
|
|
|
|
|
|
CRTC_WRITE(PV_INTEN, 0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void vc4_crtc_handle_page_flip(struct vc4_crtc *vc4_crtc)
|
|
|
|
|
{
|
|
|
|
|
struct drm_crtc *crtc = &vc4_crtc->base;
|
|
|
|
|
struct drm_device *dev = crtc->dev;
|
drm/vc4: Make pageflip completion handling more robust.
Protect both the setup of the pageflip event and the
latching of the new requested displaylist head pointer
by the event lock, so we can't get into a situation
where vc4_atomic_flush latches the new display list via
HVS_WRITE, then immediately gets preempted before queueing
the pageflip event, then the page-flip completes in hw and
the vc4_crtc_handle_page_flip() runs and no-ops due to
lack of a pending pageflip event, then vc4_atomic_flush
continues and only then queues the pageflip event - after
the page flip handling already no-oped. This would cause
flip completion handling only at the next vblank - one
frame too late.
In vc4_crtc_handle_page_flip() check the actual DL head
pointer in SCALER_DISPLACTX against the requested pointer
for page flip to make sure that the flip actually really
completed in the current vblank and doesn't get deferred
to the next one because the DL head pointer was written
a bit too late into SCALER_DISPLISTX, after start of
vblank, and missed the boat. This avoids handling a
pageflip completion too early - one frame too early.
According to Eric, DL head pointer updates which were
written into the HVS DISPLISTX reg get committed to hardware
at the last pixel of active scanout. Our vblank interrupt
handler, as triggered by PV_INT_VFP_START irq, gets to run
earliest at the first pixel of HBLANK at the end of the
last scanline of active scanout, ie. vblank irq handling
runs at least 1 pixel duration after a potential pageflip
completion happened in hardware.
This ordering of events in the hardware, together with the
lock protection and SCALER_DISPLACTX sampling of this patch,
guarantees that pageflip completion handling only runs at
exactly the vblank irq of actual pageflip completion in all
cases.
Background info from Eric about the relative timing of
HVS, PV's and trigger points for interrupts, DL updates:
https://lists.freedesktop.org/archives/dri-devel/2016-May/107510.html
Tested on RPi 2B with hardware timing measurement equipment
and shown to no longer complete flips too early or too late.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
2016-05-18 20:02:46 +08:00
|
|
|
struct vc4_dev *vc4 = to_vc4_dev(dev);
|
|
|
|
|
struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc->state);
|
|
|
|
|
u32 chan = vc4_crtc->channel;
|
2015-03-03 05:01:12 +08:00
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
|
|
spin_lock_irqsave(&dev->event_lock, flags);
|
drm/vc4: Make pageflip completion handling more robust.
Protect both the setup of the pageflip event and the
latching of the new requested displaylist head pointer
by the event lock, so we can't get into a situation
where vc4_atomic_flush latches the new display list via
HVS_WRITE, then immediately gets preempted before queueing
the pageflip event, then the page-flip completes in hw and
the vc4_crtc_handle_page_flip() runs and no-ops due to
lack of a pending pageflip event, then vc4_atomic_flush
continues and only then queues the pageflip event - after
the page flip handling already no-oped. This would cause
flip completion handling only at the next vblank - one
frame too late.
In vc4_crtc_handle_page_flip() check the actual DL head
pointer in SCALER_DISPLACTX against the requested pointer
for page flip to make sure that the flip actually really
completed in the current vblank and doesn't get deferred
to the next one because the DL head pointer was written
a bit too late into SCALER_DISPLISTX, after start of
vblank, and missed the boat. This avoids handling a
pageflip completion too early - one frame too early.
According to Eric, DL head pointer updates which were
written into the HVS DISPLISTX reg get committed to hardware
at the last pixel of active scanout. Our vblank interrupt
handler, as triggered by PV_INT_VFP_START irq, gets to run
earliest at the first pixel of HBLANK at the end of the
last scanline of active scanout, ie. vblank irq handling
runs at least 1 pixel duration after a potential pageflip
completion happened in hardware.
This ordering of events in the hardware, together with the
lock protection and SCALER_DISPLACTX sampling of this patch,
guarantees that pageflip completion handling only runs at
exactly the vblank irq of actual pageflip completion in all
cases.
Background info from Eric about the relative timing of
HVS, PV's and trigger points for interrupts, DL updates:
https://lists.freedesktop.org/archives/dri-devel/2016-May/107510.html
Tested on RPi 2B with hardware timing measurement equipment
and shown to no longer complete flips too early or too late.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
2016-05-18 20:02:46 +08:00
|
|
|
if (vc4_crtc->event &&
|
|
|
|
|
(vc4_state->mm.start == HVS_READ(SCALER_DISPLACTX(chan)))) {
|
2015-03-03 05:01:12 +08:00
|
|
|
drm_crtc_send_vblank_event(crtc, vc4_crtc->event);
|
|
|
|
|
vc4_crtc->event = NULL;
|
2016-05-07 01:26:06 +08:00
|
|
|
drm_crtc_vblank_put(crtc);
|
2015-03-03 05:01:12 +08:00
|
|
|
}
|
|
|
|
|
spin_unlock_irqrestore(&dev->event_lock, flags);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static irqreturn_t vc4_crtc_irq_handler(int irq, void *data)
|
|
|
|
|
{
|
|
|
|
|
struct vc4_crtc *vc4_crtc = data;
|
|
|
|
|
u32 stat = CRTC_READ(PV_INTSTAT);
|
|
|
|
|
irqreturn_t ret = IRQ_NONE;
|
|
|
|
|
|
|
|
|
|
if (stat & PV_INT_VFP_START) {
|
drm/vc4: Implement precise vblank timestamping.
Precise vblank timestamping is implemented via the
usual scanout position based method. On VC4 the
pixelvalves PV do not have a scanout position
register. Only the hardware video scaler HVS has a
similar register which describes which scanline for
the output is currently composited and stored in the
HVS fifo for later consumption by the PV.
This causes a problem in that the HVS runs at a much
faster clock (system clock / audio gate) than the PV
which runs at video mode dot clock, so the unless the
fifo between HVS and PV is full, the HVS will progress
faster in its observable read line position than video
scan rate, so the HVS position reading can't be directly
translated into a scanout position for timestamp correction.
Additionally when the PV is in vblank, it doesn't consume
from the fifo, so the fifo gets full very quickly and then
the HVS stops compositing until the PV enters active scanout
and starts consuming scanlines from the fifo again, making
new space for the HVS to composite.
Therefore a simple translation of HVS read position into
elapsed time since (or to) start of active scanout does
not work, but for the most interesting cases we can still
get useful and sufficiently accurate results:
1. The PV enters active scanout of a new frame with the
fifo of the HVS completely full, and the HVS can refill
any fifo line which gets consumed and thereby freed up by
the PV during active scanout very quickly. Therefore the
PV and HVS work effectively in lock-step during active
scanout with the fifo never having more than 1 scanline
freed up by the PV before it gets refilled. The PV's
real scanout position is therefore trailing the HVS
compositing position as scanoutpos = hvspos - fifosize
and we can get the true scanoutpos as HVS readpos minus
fifo size, so precise timestamping works while in active
scanout, except for the last few scanlines of the frame,
when the HVS reaches end of frame, stops compositing and
the PV catches up and drains the fifo. This special case
would only introduce minor errors though.
2. If we are in vblank, then we can only guess something
reasonable. If called from vblank irq, we assume the irq is
usually dispatched with minimum delay, so we can take a
timestamp taken at entry into the vblank irq handler as a
baseline and then add a full vblank duration until the
guessed start of active scanout. As irq dispatch is usually
pretty low latency this works with relatively low jitter and
good results.
If we aren't called from vblank then we could be anywhere
within the vblank interval, so we return a neutral result,
simply the current system timestamp, and hope for the best.
Measurement shows the generated timestamps to be rather precise,
and at least never off more than 1 vblank duration worst-case.
Limitations: Doesn't work well yet for interlaced video modes,
therefore disabled in interlaced mode for now.
v2: Use the DISPBASE registers to determine the FIFO size (changes
by anholt)
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> (v2)
2016-06-23 14:17:50 +08:00
|
|
|
vc4_crtc->t_vblank = ktime_get();
|
2015-03-03 05:01:12 +08:00
|
|
|
CRTC_WRITE(PV_INTSTAT, PV_INT_VFP_START);
|
|
|
|
|
drm_crtc_handle_vblank(&vc4_crtc->base);
|
|
|
|
|
vc4_crtc_handle_page_flip(vc4_crtc);
|
|
|
|
|
ret = IRQ_HANDLED;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2015-12-01 04:34:01 +08:00
|
|
|
struct vc4_async_flip_state {
|
|
|
|
|
struct drm_crtc *crtc;
|
|
|
|
|
struct drm_framebuffer *fb;
|
|
|
|
|
struct drm_pending_vblank_event *event;
|
|
|
|
|
|
|
|
|
|
struct vc4_seqno_cb cb;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* Called when the V3D execution for the BO being flipped to is done, so that
|
|
|
|
|
* we can actually update the plane's address to point to it.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
vc4_async_page_flip_complete(struct vc4_seqno_cb *cb)
|
|
|
|
|
{
|
|
|
|
|
struct vc4_async_flip_state *flip_state =
|
|
|
|
|
container_of(cb, struct vc4_async_flip_state, cb);
|
|
|
|
|
struct drm_crtc *crtc = flip_state->crtc;
|
|
|
|
|
struct drm_device *dev = crtc->dev;
|
|
|
|
|
struct vc4_dev *vc4 = to_vc4_dev(dev);
|
|
|
|
|
struct drm_plane *plane = crtc->primary;
|
|
|
|
|
|
|
|
|
|
vc4_plane_async_set_fb(plane, flip_state->fb);
|
|
|
|
|
if (flip_state->event) {
|
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
|
|
spin_lock_irqsave(&dev->event_lock, flags);
|
|
|
|
|
drm_crtc_send_vblank_event(crtc, flip_state->event);
|
|
|
|
|
spin_unlock_irqrestore(&dev->event_lock, flags);
|
|
|
|
|
}
|
|
|
|
|
|
2016-05-07 01:26:06 +08:00
|
|
|
drm_crtc_vblank_put(crtc);
|
2017-08-03 19:58:40 +08:00
|
|
|
drm_framebuffer_put(flip_state->fb);
|
2015-12-01 04:34:01 +08:00
|
|
|
kfree(flip_state);
|
|
|
|
|
|
|
|
|
|
up(&vc4->async_modeset);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Implements async (non-vblank-synced) page flips.
|
|
|
|
|
*
|
|
|
|
|
* The page flip ioctl needs to return immediately, so we grab the
|
|
|
|
|
* modeset semaphore on the pipe, and queue the address update for
|
|
|
|
|
* when V3D is done with the BO being flipped to.
|
|
|
|
|
*/
|
|
|
|
|
static int vc4_async_page_flip(struct drm_crtc *crtc,
|
|
|
|
|
struct drm_framebuffer *fb,
|
|
|
|
|
struct drm_pending_vblank_event *event,
|
|
|
|
|
uint32_t flags)
|
|
|
|
|
{
|
|
|
|
|
struct drm_device *dev = crtc->dev;
|
|
|
|
|
struct vc4_dev *vc4 = to_vc4_dev(dev);
|
|
|
|
|
struct drm_plane *plane = crtc->primary;
|
|
|
|
|
int ret = 0;
|
|
|
|
|
struct vc4_async_flip_state *flip_state;
|
|
|
|
|
struct drm_gem_cma_object *cma_bo = drm_fb_cma_get_gem_obj(fb, 0);
|
|
|
|
|
struct vc4_bo *bo = to_vc4_bo(&cma_bo->base);
|
|
|
|
|
|
|
|
|
|
flip_state = kzalloc(sizeof(*flip_state), GFP_KERNEL);
|
|
|
|
|
if (!flip_state)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
2017-08-03 19:58:40 +08:00
|
|
|
drm_framebuffer_get(fb);
|
2015-12-01 04:34:01 +08:00
|
|
|
flip_state->fb = fb;
|
|
|
|
|
flip_state->crtc = crtc;
|
|
|
|
|
flip_state->event = event;
|
|
|
|
|
|
|
|
|
|
/* Make sure all other async modesetes have landed. */
|
|
|
|
|
ret = down_interruptible(&vc4->async_modeset);
|
|
|
|
|
if (ret) {
|
2017-08-03 19:58:40 +08:00
|
|
|
drm_framebuffer_put(fb);
|
2015-12-01 04:34:01 +08:00
|
|
|
kfree(flip_state);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2016-05-07 01:26:06 +08:00
|
|
|
WARN_ON(drm_crtc_vblank_get(crtc) != 0);
|
|
|
|
|
|
2015-12-01 04:34:01 +08:00
|
|
|
/* Immediately update the plane's legacy fb pointer, so that later
|
|
|
|
|
* modeset prep sees the state that will be present when the semaphore
|
|
|
|
|
* is released.
|
|
|
|
|
*/
|
|
|
|
|
drm_atomic_set_fb_for_plane(plane->state, fb);
|
|
|
|
|
plane->fb = fb;
|
|
|
|
|
|
|
|
|
|
vc4_queue_seqno_cb(dev, &flip_state->cb, bo->seqno,
|
|
|
|
|
vc4_async_page_flip_complete);
|
|
|
|
|
|
|
|
|
|
/* Driver takes ownership of state on successful async commit. */
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int vc4_page_flip(struct drm_crtc *crtc,
|
|
|
|
|
struct drm_framebuffer *fb,
|
|
|
|
|
struct drm_pending_vblank_event *event,
|
2017-03-23 05:50:50 +08:00
|
|
|
uint32_t flags,
|
|
|
|
|
struct drm_modeset_acquire_ctx *ctx)
|
2015-12-01 04:34:01 +08:00
|
|
|
{
|
|
|
|
|
if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
|
|
|
|
|
return vc4_async_page_flip(crtc, fb, event, flags);
|
|
|
|
|
else
|
2017-03-23 05:50:50 +08:00
|
|
|
return drm_atomic_helper_page_flip(crtc, fb, event, flags, ctx);
|
2015-12-01 04:34:01 +08:00
|
|
|
}
|
|
|
|
|
|
2015-12-29 05:25:41 +08:00
|
|
|
static struct drm_crtc_state *vc4_crtc_duplicate_state(struct drm_crtc *crtc)
|
|
|
|
|
{
|
|
|
|
|
struct vc4_crtc_state *vc4_state;
|
|
|
|
|
|
|
|
|
|
vc4_state = kzalloc(sizeof(*vc4_state), GFP_KERNEL);
|
|
|
|
|
if (!vc4_state)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
__drm_atomic_helper_crtc_duplicate_state(crtc, &vc4_state->base);
|
|
|
|
|
return &vc4_state->base;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void vc4_crtc_destroy_state(struct drm_crtc *crtc,
|
|
|
|
|
struct drm_crtc_state *state)
|
|
|
|
|
{
|
|
|
|
|
struct vc4_dev *vc4 = to_vc4_dev(crtc->dev);
|
|
|
|
|
struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(state);
|
|
|
|
|
|
|
|
|
|
if (vc4_state->mm.allocated) {
|
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
|
|
spin_lock_irqsave(&vc4->hvs->mm_lock, flags);
|
|
|
|
|
drm_mm_remove_node(&vc4_state->mm);
|
|
|
|
|
spin_unlock_irqrestore(&vc4->hvs->mm_lock, flags);
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-11 00:44:06 +08:00
|
|
|
drm_atomic_helper_crtc_destroy_state(crtc, state);
|
2015-12-29 05:25:41 +08:00
|
|
|
}
|
|
|
|
|
|
2017-03-29 04:13:43 +08:00
|
|
|
static void
|
|
|
|
|
vc4_crtc_reset(struct drm_crtc *crtc)
|
|
|
|
|
{
|
|
|
|
|
if (crtc->state)
|
|
|
|
|
__drm_atomic_helper_crtc_destroy_state(crtc->state);
|
|
|
|
|
|
|
|
|
|
crtc->state = kzalloc(sizeof(struct vc4_crtc_state), GFP_KERNEL);
|
|
|
|
|
if (crtc->state)
|
|
|
|
|
crtc->state->crtc = crtc;
|
|
|
|
|
}
|
|
|
|
|
|
2015-03-03 05:01:12 +08:00
|
|
|
static const struct drm_crtc_funcs vc4_crtc_funcs = {
|
|
|
|
|
.set_config = drm_atomic_helper_set_config,
|
|
|
|
|
.destroy = vc4_crtc_destroy,
|
2015-12-01 04:34:01 +08:00
|
|
|
.page_flip = vc4_page_flip,
|
2015-03-03 05:01:12 +08:00
|
|
|
.set_property = NULL,
|
|
|
|
|
.cursor_set = NULL, /* handled by drm_mode_cursor_universal */
|
|
|
|
|
.cursor_move = NULL, /* handled by drm_mode_cursor_universal */
|
2017-03-29 04:13:43 +08:00
|
|
|
.reset = vc4_crtc_reset,
|
2015-12-29 05:25:41 +08:00
|
|
|
.atomic_duplicate_state = vc4_crtc_duplicate_state,
|
|
|
|
|
.atomic_destroy_state = vc4_crtc_destroy_state,
|
2016-04-01 09:38:20 +08:00
|
|
|
.gamma_set = vc4_crtc_gamma_set,
|
2017-02-07 17:16:34 +08:00
|
|
|
.enable_vblank = vc4_enable_vblank,
|
|
|
|
|
.disable_vblank = vc4_disable_vblank,
|
2015-03-03 05:01:12 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const struct drm_crtc_helper_funcs vc4_crtc_helper_funcs = {
|
|
|
|
|
.mode_set_nofb = vc4_crtc_mode_set_nofb,
|
2017-05-25 22:19:22 +08:00
|
|
|
.mode_valid = vc4_crtc_mode_valid,
|
2015-03-03 05:01:12 +08:00
|
|
|
.atomic_check = vc4_crtc_atomic_check,
|
|
|
|
|
.atomic_flush = vc4_crtc_atomic_flush,
|
2017-06-30 17:36:44 +08:00
|
|
|
.atomic_enable = vc4_crtc_atomic_enable,
|
2017-06-30 17:36:45 +08:00
|
|
|
.atomic_disable = vc4_crtc_atomic_disable,
|
2015-03-03 05:01:12 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const struct vc4_crtc_data pv0_data = {
|
|
|
|
|
.hvs_channel = 0,
|
2016-12-02 21:48:07 +08:00
|
|
|
.encoder_types = {
|
|
|
|
|
[PV_CONTROL_CLK_SELECT_DSI] = VC4_ENCODER_TYPE_DSI0,
|
|
|
|
|
[PV_CONTROL_CLK_SELECT_DPI_SMI_HDMI] = VC4_ENCODER_TYPE_DPI,
|
|
|
|
|
},
|
2015-03-03 05:01:12 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const struct vc4_crtc_data pv1_data = {
|
|
|
|
|
.hvs_channel = 2,
|
2016-12-02 21:48:07 +08:00
|
|
|
.encoder_types = {
|
|
|
|
|
[PV_CONTROL_CLK_SELECT_DSI] = VC4_ENCODER_TYPE_DSI1,
|
|
|
|
|
[PV_CONTROL_CLK_SELECT_DPI_SMI_HDMI] = VC4_ENCODER_TYPE_SMI,
|
|
|
|
|
},
|
2015-03-03 05:01:12 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const struct vc4_crtc_data pv2_data = {
|
|
|
|
|
.hvs_channel = 1,
|
2016-12-02 21:48:07 +08:00
|
|
|
.encoder_types = {
|
|
|
|
|
[PV_CONTROL_CLK_SELECT_DPI_SMI_HDMI] = VC4_ENCODER_TYPE_HDMI,
|
|
|
|
|
[PV_CONTROL_CLK_SELECT_VEC] = VC4_ENCODER_TYPE_VEC,
|
|
|
|
|
},
|
2015-03-03 05:01:12 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const struct of_device_id vc4_crtc_dt_match[] = {
|
|
|
|
|
{ .compatible = "brcm,bcm2835-pixelvalve0", .data = &pv0_data },
|
|
|
|
|
{ .compatible = "brcm,bcm2835-pixelvalve1", .data = &pv1_data },
|
|
|
|
|
{ .compatible = "brcm,bcm2835-pixelvalve2", .data = &pv2_data },
|
|
|
|
|
{}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static void vc4_set_crtc_possible_masks(struct drm_device *drm,
|
|
|
|
|
struct drm_crtc *crtc)
|
|
|
|
|
{
|
|
|
|
|
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
|
2016-12-02 21:48:07 +08:00
|
|
|
const struct vc4_crtc_data *crtc_data = vc4_crtc->data;
|
|
|
|
|
const enum vc4_encoder_type *encoder_types = crtc_data->encoder_types;
|
2015-03-03 05:01:12 +08:00
|
|
|
struct drm_encoder *encoder;
|
|
|
|
|
|
|
|
|
|
drm_for_each_encoder(encoder, drm) {
|
|
|
|
|
struct vc4_encoder *vc4_encoder = to_vc4_encoder(encoder);
|
2016-12-02 21:48:07 +08:00
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(crtc_data->encoder_types); i++) {
|
|
|
|
|
if (vc4_encoder->type == encoder_types[i]) {
|
|
|
|
|
vc4_encoder->clock_select = i;
|
|
|
|
|
encoder->possible_crtcs |= drm_crtc_mask(crtc);
|
|
|
|
|
break;
|
|
|
|
|
}
|
2015-03-03 05:01:12 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
drm/vc4: Implement precise vblank timestamping.
Precise vblank timestamping is implemented via the
usual scanout position based method. On VC4 the
pixelvalves PV do not have a scanout position
register. Only the hardware video scaler HVS has a
similar register which describes which scanline for
the output is currently composited and stored in the
HVS fifo for later consumption by the PV.
This causes a problem in that the HVS runs at a much
faster clock (system clock / audio gate) than the PV
which runs at video mode dot clock, so the unless the
fifo between HVS and PV is full, the HVS will progress
faster in its observable read line position than video
scan rate, so the HVS position reading can't be directly
translated into a scanout position for timestamp correction.
Additionally when the PV is in vblank, it doesn't consume
from the fifo, so the fifo gets full very quickly and then
the HVS stops compositing until the PV enters active scanout
and starts consuming scanlines from the fifo again, making
new space for the HVS to composite.
Therefore a simple translation of HVS read position into
elapsed time since (or to) start of active scanout does
not work, but for the most interesting cases we can still
get useful and sufficiently accurate results:
1. The PV enters active scanout of a new frame with the
fifo of the HVS completely full, and the HVS can refill
any fifo line which gets consumed and thereby freed up by
the PV during active scanout very quickly. Therefore the
PV and HVS work effectively in lock-step during active
scanout with the fifo never having more than 1 scanline
freed up by the PV before it gets refilled. The PV's
real scanout position is therefore trailing the HVS
compositing position as scanoutpos = hvspos - fifosize
and we can get the true scanoutpos as HVS readpos minus
fifo size, so precise timestamping works while in active
scanout, except for the last few scanlines of the frame,
when the HVS reaches end of frame, stops compositing and
the PV catches up and drains the fifo. This special case
would only introduce minor errors though.
2. If we are in vblank, then we can only guess something
reasonable. If called from vblank irq, we assume the irq is
usually dispatched with minimum delay, so we can take a
timestamp taken at entry into the vblank irq handler as a
baseline and then add a full vblank duration until the
guessed start of active scanout. As irq dispatch is usually
pretty low latency this works with relatively low jitter and
good results.
If we aren't called from vblank then we could be anywhere
within the vblank interval, so we return a neutral result,
simply the current system timestamp, and hope for the best.
Measurement shows the generated timestamps to be rather precise,
and at least never off more than 1 vblank duration worst-case.
Limitations: Doesn't work well yet for interlaced video modes,
therefore disabled in interlaced mode for now.
v2: Use the DISPBASE registers to determine the FIFO size (changes
by anholt)
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> (v2)
2016-06-23 14:17:50 +08:00
|
|
|
static void
|
|
|
|
|
vc4_crtc_get_cob_allocation(struct vc4_crtc *vc4_crtc)
|
|
|
|
|
{
|
|
|
|
|
struct drm_device *drm = vc4_crtc->base.dev;
|
|
|
|
|
struct vc4_dev *vc4 = to_vc4_dev(drm);
|
|
|
|
|
u32 dispbase = HVS_READ(SCALER_DISPBASEX(vc4_crtc->channel));
|
|
|
|
|
/* Top/base are supposed to be 4-pixel aligned, but the
|
|
|
|
|
* Raspberry Pi firmware fills the low bits (which are
|
|
|
|
|
* presumably ignored).
|
|
|
|
|
*/
|
|
|
|
|
u32 top = VC4_GET_FIELD(dispbase, SCALER_DISPBASEX_TOP) & ~3;
|
|
|
|
|
u32 base = VC4_GET_FIELD(dispbase, SCALER_DISPBASEX_BASE) & ~3;
|
|
|
|
|
|
|
|
|
|
vc4_crtc->cob_size = top - base + 4;
|
|
|
|
|
}
|
|
|
|
|
|
2015-03-03 05:01:12 +08:00
|
|
|
static int vc4_crtc_bind(struct device *dev, struct device *master, void *data)
|
|
|
|
|
{
|
|
|
|
|
struct platform_device *pdev = to_platform_device(dev);
|
|
|
|
|
struct drm_device *drm = dev_get_drvdata(master);
|
|
|
|
|
struct vc4_crtc *vc4_crtc;
|
|
|
|
|
struct drm_crtc *crtc;
|
2015-10-20 21:18:56 +08:00
|
|
|
struct drm_plane *primary_plane, *cursor_plane, *destroy_plane, *temp;
|
2015-03-03 05:01:12 +08:00
|
|
|
const struct of_device_id *match;
|
2015-10-20 21:18:56 +08:00
|
|
|
int ret, i;
|
2015-03-03 05:01:12 +08:00
|
|
|
|
|
|
|
|
vc4_crtc = devm_kzalloc(dev, sizeof(*vc4_crtc), GFP_KERNEL);
|
|
|
|
|
if (!vc4_crtc)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
crtc = &vc4_crtc->base;
|
|
|
|
|
|
|
|
|
|
match = of_match_device(vc4_crtc_dt_match, dev);
|
|
|
|
|
if (!match)
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
vc4_crtc->data = match->data;
|
|
|
|
|
|
|
|
|
|
vc4_crtc->regs = vc4_ioremap_regs(pdev, 0);
|
|
|
|
|
if (IS_ERR(vc4_crtc->regs))
|
|
|
|
|
return PTR_ERR(vc4_crtc->regs);
|
|
|
|
|
|
|
|
|
|
/* For now, we create just the primary and the legacy cursor
|
|
|
|
|
* planes. We should be able to stack more planes on easily,
|
|
|
|
|
* but to do that we would need to compute the bandwidth
|
|
|
|
|
* requirement of the plane configuration, and reject ones
|
|
|
|
|
* that will take too much.
|
|
|
|
|
*/
|
|
|
|
|
primary_plane = vc4_plane_init(drm, DRM_PLANE_TYPE_PRIMARY);
|
2015-11-04 21:21:40 +08:00
|
|
|
if (IS_ERR(primary_plane)) {
|
2015-03-03 05:01:12 +08:00
|
|
|
dev_err(dev, "failed to construct primary plane\n");
|
|
|
|
|
ret = PTR_ERR(primary_plane);
|
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
2015-10-20 21:18:56 +08:00
|
|
|
drm_crtc_init_with_planes(drm, crtc, primary_plane, NULL,
|
drm: Pass 'name' to drm_crtc_init_with_planes()
Done with coccinelle for the most part. However, it thinks '...' is
part of the semantic patch, so I put an 'int DOTDOTDOT' placeholder
in its place and got rid of it with sed afterwards.
I didn't convert drm_crtc_init() since passing the varargs through
would mean either cpp macros or va_list, and I figured we don't
care about these legacy functions enough to warrant the extra pain.
@@
identifier dev, crtc, primary, cursor, funcs;
@@
int drm_crtc_init_with_planes(struct drm_device *dev,
struct drm_crtc *crtc,
struct drm_plane *primary, struct drm_plane *cursor,
const struct drm_crtc_funcs *funcs
+ ,const char *name, int DOTDOTDOT
)
{ ... }
@@
identifier dev, crtc, primary, cursor, funcs;
@@
int drm_crtc_init_with_planes(struct drm_device *dev,
struct drm_crtc *crtc,
struct drm_plane *primary, struct drm_plane *cursor,
const struct drm_crtc_funcs *funcs
+ ,const char *name, int DOTDOTDOT
);
@@
expression E1, E2, E3, E4, E5;
@@
drm_crtc_init_with_planes(E1, E2, E3, E4, E5
+ ,NULL
)
v2: Split crtc and plane changes apart
Pass NULL for no-name instead of ""
Leave drm_crtc_init() alone
v3: Add ', or NULL...' to @name kernel doc (Jani)
Annotate the function with __printf() attribute (Jani)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449670771-2751-1-git-send-email-ville.syrjala@linux.intel.com
2015-12-09 22:19:31 +08:00
|
|
|
&vc4_crtc_funcs, NULL);
|
2015-03-03 05:01:12 +08:00
|
|
|
drm_crtc_helper_add(crtc, &vc4_crtc_helper_funcs);
|
|
|
|
|
primary_plane->crtc = crtc;
|
|
|
|
|
vc4_crtc->channel = vc4_crtc->data->hvs_channel;
|
2016-04-01 09:38:20 +08:00
|
|
|
drm_mode_crtc_set_gamma_size(crtc, ARRAY_SIZE(vc4_crtc->lut_r));
|
2015-03-03 05:01:12 +08:00
|
|
|
|
2015-10-20 21:18:56 +08:00
|
|
|
/* Set up some arbitrary number of planes. We're not limited
|
|
|
|
|
* by a set number of physical registers, just the space in
|
|
|
|
|
* the HVS (16k) and how small an plane can be (28 bytes).
|
|
|
|
|
* However, each plane we set up takes up some memory, and
|
|
|
|
|
* increases the cost of looping over planes, which atomic
|
|
|
|
|
* modesetting does quite a bit. As a result, we pick a
|
|
|
|
|
* modest number of planes to expose, that should hopefully
|
|
|
|
|
* still cover any sane usecase.
|
|
|
|
|
*/
|
|
|
|
|
for (i = 0; i < 8; i++) {
|
|
|
|
|
struct drm_plane *plane =
|
|
|
|
|
vc4_plane_init(drm, DRM_PLANE_TYPE_OVERLAY);
|
|
|
|
|
|
|
|
|
|
if (IS_ERR(plane))
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
plane->possible_crtcs = 1 << drm_crtc_index(crtc);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Set up the legacy cursor after overlay initialization,
|
|
|
|
|
* since we overlay planes on the CRTC in the order they were
|
|
|
|
|
* initialized.
|
|
|
|
|
*/
|
|
|
|
|
cursor_plane = vc4_plane_init(drm, DRM_PLANE_TYPE_CURSOR);
|
|
|
|
|
if (!IS_ERR(cursor_plane)) {
|
|
|
|
|
cursor_plane->possible_crtcs = 1 << drm_crtc_index(crtc);
|
|
|
|
|
cursor_plane->crtc = crtc;
|
|
|
|
|
crtc->cursor = cursor_plane;
|
|
|
|
|
}
|
|
|
|
|
|
drm/vc4: Implement precise vblank timestamping.
Precise vblank timestamping is implemented via the
usual scanout position based method. On VC4 the
pixelvalves PV do not have a scanout position
register. Only the hardware video scaler HVS has a
similar register which describes which scanline for
the output is currently composited and stored in the
HVS fifo for later consumption by the PV.
This causes a problem in that the HVS runs at a much
faster clock (system clock / audio gate) than the PV
which runs at video mode dot clock, so the unless the
fifo between HVS and PV is full, the HVS will progress
faster in its observable read line position than video
scan rate, so the HVS position reading can't be directly
translated into a scanout position for timestamp correction.
Additionally when the PV is in vblank, it doesn't consume
from the fifo, so the fifo gets full very quickly and then
the HVS stops compositing until the PV enters active scanout
and starts consuming scanlines from the fifo again, making
new space for the HVS to composite.
Therefore a simple translation of HVS read position into
elapsed time since (or to) start of active scanout does
not work, but for the most interesting cases we can still
get useful and sufficiently accurate results:
1. The PV enters active scanout of a new frame with the
fifo of the HVS completely full, and the HVS can refill
any fifo line which gets consumed and thereby freed up by
the PV during active scanout very quickly. Therefore the
PV and HVS work effectively in lock-step during active
scanout with the fifo never having more than 1 scanline
freed up by the PV before it gets refilled. The PV's
real scanout position is therefore trailing the HVS
compositing position as scanoutpos = hvspos - fifosize
and we can get the true scanoutpos as HVS readpos minus
fifo size, so precise timestamping works while in active
scanout, except for the last few scanlines of the frame,
when the HVS reaches end of frame, stops compositing and
the PV catches up and drains the fifo. This special case
would only introduce minor errors though.
2. If we are in vblank, then we can only guess something
reasonable. If called from vblank irq, we assume the irq is
usually dispatched with minimum delay, so we can take a
timestamp taken at entry into the vblank irq handler as a
baseline and then add a full vblank duration until the
guessed start of active scanout. As irq dispatch is usually
pretty low latency this works with relatively low jitter and
good results.
If we aren't called from vblank then we could be anywhere
within the vblank interval, so we return a neutral result,
simply the current system timestamp, and hope for the best.
Measurement shows the generated timestamps to be rather precise,
and at least never off more than 1 vblank duration worst-case.
Limitations: Doesn't work well yet for interlaced video modes,
therefore disabled in interlaced mode for now.
v2: Use the DISPBASE registers to determine the FIFO size (changes
by anholt)
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> (v2)
2016-06-23 14:17:50 +08:00
|
|
|
vc4_crtc_get_cob_allocation(vc4_crtc);
|
|
|
|
|
|
2015-03-03 05:01:12 +08:00
|
|
|
CRTC_WRITE(PV_INTEN, 0);
|
|
|
|
|
CRTC_WRITE(PV_INTSTAT, PV_INT_VFP_START);
|
|
|
|
|
ret = devm_request_irq(dev, platform_get_irq(pdev, 0),
|
|
|
|
|
vc4_crtc_irq_handler, 0, "vc4 crtc", vc4_crtc);
|
|
|
|
|
if (ret)
|
2015-10-20 21:18:56 +08:00
|
|
|
goto err_destroy_planes;
|
2015-03-03 05:01:12 +08:00
|
|
|
|
|
|
|
|
vc4_set_crtc_possible_masks(drm, crtc);
|
|
|
|
|
|
2016-04-01 09:38:20 +08:00
|
|
|
for (i = 0; i < crtc->gamma_size; i++) {
|
|
|
|
|
vc4_crtc->lut_r[i] = i;
|
|
|
|
|
vc4_crtc->lut_g[i] = i;
|
|
|
|
|
vc4_crtc->lut_b[i] = i;
|
|
|
|
|
}
|
|
|
|
|
|
2015-03-03 05:01:12 +08:00
|
|
|
platform_set_drvdata(pdev, vc4_crtc);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
2015-10-20 21:18:56 +08:00
|
|
|
err_destroy_planes:
|
|
|
|
|
list_for_each_entry_safe(destroy_plane, temp,
|
|
|
|
|
&drm->mode_config.plane_list, head) {
|
|
|
|
|
if (destroy_plane->possible_crtcs == 1 << drm_crtc_index(crtc))
|
|
|
|
|
destroy_plane->funcs->destroy(destroy_plane);
|
|
|
|
|
}
|
2015-03-03 05:01:12 +08:00
|
|
|
err:
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void vc4_crtc_unbind(struct device *dev, struct device *master,
|
|
|
|
|
void *data)
|
|
|
|
|
{
|
|
|
|
|
struct platform_device *pdev = to_platform_device(dev);
|
|
|
|
|
struct vc4_crtc *vc4_crtc = dev_get_drvdata(dev);
|
|
|
|
|
|
|
|
|
|
vc4_crtc_destroy(&vc4_crtc->base);
|
|
|
|
|
|
|
|
|
|
CRTC_WRITE(PV_INTEN, 0);
|
|
|
|
|
|
|
|
|
|
platform_set_drvdata(pdev, NULL);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const struct component_ops vc4_crtc_ops = {
|
|
|
|
|
.bind = vc4_crtc_bind,
|
|
|
|
|
.unbind = vc4_crtc_unbind,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static int vc4_crtc_dev_probe(struct platform_device *pdev)
|
|
|
|
|
{
|
|
|
|
|
return component_add(&pdev->dev, &vc4_crtc_ops);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int vc4_crtc_dev_remove(struct platform_device *pdev)
|
|
|
|
|
{
|
|
|
|
|
component_del(&pdev->dev, &vc4_crtc_ops);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct platform_driver vc4_crtc_driver = {
|
|
|
|
|
.probe = vc4_crtc_dev_probe,
|
|
|
|
|
.remove = vc4_crtc_dev_remove,
|
|
|
|
|
.driver = {
|
|
|
|
|
.name = "vc4_crtc",
|
|
|
|
|
.of_match_table = vc4_crtc_dt_match,
|
|
|
|
|
},
|
|
|
|
|
};
|