From a9402dfe17bddeee5c72943385eaa13c39f106f7 Mon Sep 17 00:00:00 2001 From: Colin Ian King Date: Thu, 2 Jun 2016 10:38:29 +0100 Subject: drm/vc4: clean up error exit path on failed dpi_connector allocation There is redundant code in the clean up exit path when dpi_connector fails to be allocated. The current code checks if connector is NULL before destroying it, in fact, connector is NULL at this point so the check is redundant and can be removed. The final clean up is that we can remove the goto fail with a simple return and the unused variable ret. Signed-off-by: Colin Ian King Reviewed-by: Eric Anholt --- drivers/gpu/drm/vc4/vc4_dpi.c | 14 +++----------- 1 file changed, 3 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c index 9817dbfa4ac3..9cb2d3e6e1c0 100644 --- a/drivers/gpu/drm/vc4/vc4_dpi.c +++ b/drivers/gpu/drm/vc4/vc4_dpi.c @@ -236,14 +236,12 @@ static struct drm_connector *vc4_dpi_connector_init(struct drm_device *dev, { struct drm_connector *connector = NULL; struct vc4_dpi_connector *dpi_connector; - int ret = 0; dpi_connector = devm_kzalloc(dev->dev, sizeof(*dpi_connector), GFP_KERNEL); - if (!dpi_connector) { - ret = -ENOMEM; - goto fail; - } + if (!dpi_connector) + return ERR_PTR(-ENOMEM); + connector = &dpi_connector->base; dpi_connector->encoder = dpi->encoder; @@ -260,12 +258,6 @@ static struct drm_connector *vc4_dpi_connector_init(struct drm_device *dev, drm_mode_connector_attach_encoder(connector, dpi->encoder); return connector; - - fail: - if (connector) - vc4_dpi_connector_destroy(connector); - - return ERR_PTR(ret); } static const struct drm_encoder_funcs vc4_dpi_encoder_funcs = { -- cgit v1.2.3 From 93977767f092fbf0787e5d2a0bf2e0a3fc6f6ced Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Thu, 9 Jun 2016 16:19:25 -0500 Subject: drm: vc4: enable XBGR8888 and ABGR8888 pixel formats DRM_FORMAT_XBGR8888 and DRM_FORMAT_ABGR8888 are 2 of the native formats used in Android, so enable them for VC4. There seems to be no logic behind HVS_PIXEL_ORDER_xxxx naming, but HVS_PIXEL_ORDER_ARGB seems to work correctly. Signed-off-by: Rob Herring Reviewed-by: Eric Anholt --- drivers/gpu/drm/vc4/vc4_plane.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c index 4037b52fde31..b12deef2527d 100644 --- a/drivers/gpu/drm/vc4/vc4_plane.c +++ b/drivers/gpu/drm/vc4/vc4_plane.c @@ -93,6 +93,14 @@ static const struct hvs_format { .drm = DRM_FORMAT_ARGB8888, .hvs = HVS_PIXEL_FORMAT_RGBA8888, .pixel_order = HVS_PIXEL_ORDER_ABGR, .has_alpha = true, }, + { + .drm = DRM_FORMAT_ABGR8888, .hvs = HVS_PIXEL_FORMAT_RGBA8888, + .pixel_order = HVS_PIXEL_ORDER_ARGB, .has_alpha = true, + }, + { + .drm = DRM_FORMAT_XBGR8888, .hvs = HVS_PIXEL_FORMAT_RGBA8888, + .pixel_order = HVS_PIXEL_ORDER_ARGB, .has_alpha = false, + }, { .drm = DRM_FORMAT_RGB565, .hvs = HVS_PIXEL_FORMAT_RGB565, .pixel_order = HVS_PIXEL_ORDER_XRGB, .has_alpha = false, -- cgit v1.2.3 From 027a697677b0d5ff211773596d96f84078ceda80 Mon Sep 17 00:00:00 2001 From: Peter Chen Date: Tue, 5 Jul 2016 10:04:54 +0800 Subject: gpu: drm: vc4_hdmi: add missing of_node_put after calling of_parse_phandle of_node_put needs to be called when the device node which is got from of_parse_phandle has finished using. Signed-off-by: Peter Chen Reviewed-by: Eric Anholt --- drivers/gpu/drm/vc4/vc4_hdmi.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c index fd2644d231ff..26b6b067567c 100644 --- a/drivers/gpu/drm/vc4/vc4_hdmi.c +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c @@ -465,12 +465,6 @@ static int vc4_hdmi_bind(struct device *dev, struct device *master, void *data) if (IS_ERR(hdmi->hd_regs)) return PTR_ERR(hdmi->hd_regs); - ddc_node = of_parse_phandle(dev->of_node, "ddc", 0); - if (!ddc_node) { - DRM_ERROR("Failed to find ddc node in device tree\n"); - return -ENODEV; - } - hdmi->pixel_clock = devm_clk_get(dev, "pixel"); if (IS_ERR(hdmi->pixel_clock)) { DRM_ERROR("Failed to get pixel clock\n"); @@ -482,7 +476,14 @@ static int vc4_hdmi_bind(struct device *dev, struct device *master, void *data) return PTR_ERR(hdmi->hsm_clock); } + ddc_node = of_parse_phandle(dev->of_node, "ddc", 0); + if (!ddc_node) { + DRM_ERROR("Failed to find ddc node in device tree\n"); + return -ENODEV; + } + hdmi->ddc = of_find_i2c_adapter_by_node(ddc_node); + of_node_put(ddc_node); if (!hdmi->ddc) { DRM_DEBUG("Failed to get ddc i2c adapter by node\n"); return -EPROBE_DEFER; -- cgit v1.2.3 From 7a100969f30b77761901c05a5c810bcaea65df44 Mon Sep 17 00:00:00 2001 From: Eric Anholt Date: Fri, 8 Jul 2016 11:25:09 -0700 Subject: drm/vc4: Bind the HVS before we bind the individual CRTCs. We need to be able to look at the CRTC's registers in the HVS as part of initialization, while the HVS doesn't need to look at the PV registers. Signed-off-by: Eric Anholt Reviewed-and-tested-by: Mario Kleiner --- drivers/gpu/drm/vc4/vc4_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c index 250ed7e3754c..6d97d3edb2d2 100644 --- a/drivers/gpu/drm/vc4/vc4_drv.c +++ b/drivers/gpu/drm/vc4/vc4_drv.c @@ -259,8 +259,8 @@ static const struct component_master_ops vc4_drm_ops = { static struct platform_driver *const component_drivers[] = { &vc4_hdmi_driver, &vc4_dpi_driver, - &vc4_crtc_driver, &vc4_hvs_driver, + &vc4_crtc_driver, &vc4_v3d_driver, }; -- cgit v1.2.3 From 1bf59f1dcbe25272f6b5d870054647e58a8a9c55 Mon Sep 17 00:00:00 2001 From: Mario Kleiner Date: Thu, 23 Jun 2016 08:17:50 +0200 Subject: 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 Signed-off-by: Eric Anholt Reviewed-and-tested-by: Mario Kleiner (v2) --- drivers/gpu/drm/vc4/vc4_crtc.c | 162 +++++++++++++++++++++++++++++++++++++++++ drivers/gpu/drm/vc4/vc4_drv.c | 2 + drivers/gpu/drm/vc4/vc4_drv.h | 7 ++ drivers/gpu/drm/vc4/vc4_regs.h | 22 +++++- 4 files changed, 192 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c index 0f18b76c7906..3b7db17c356d 100644 --- a/drivers/gpu/drm/vc4/vc4_crtc.c +++ b/drivers/gpu/drm/vc4/vc4_crtc.c @@ -46,12 +46,17 @@ struct vc4_crtc { const struct vc4_crtc_data *data; void __iomem *regs; + /* Timestamp at start of vblank irq - unaffected by lock delays. */ + ktime_t t_vblank; + /* Which HVS channel we're using for our CRTC. */ int channel; u8 lut_r[256]; u8 lut_g[256]; u8 lut_b[256]; + /* Size in pixels of the COB memory allocated to this CRTC. */ + u32 cob_size; struct drm_pending_vblank_event *event; }; @@ -146,6 +151,144 @@ int vc4_crtc_debugfs_regs(struct seq_file *m, void *unused) } #endif +int vc4_crtc_get_scanoutpos(struct drm_device *dev, unsigned int crtc_id, + unsigned int flags, int *vpos, int *hpos, + ktime_t *stime, ktime_t *etime, + const struct drm_display_mode *mode) +{ + struct vc4_dev *vc4 = to_vc4_dev(dev); + struct vc4_crtc *vc4_crtc = vc4->crtc[crtc_id]; + u32 val; + int fifo_lines; + int vblank_lines; + int ret = 0; + + /* + * XXX Doesn't work well in interlaced mode yet, partially due + * to problems in vc4 kms or drm core interlaced mode handling, + * so disable for now in interlaced mode. + */ + if (mode->flags & DRM_MODE_FLAG_INTERLACE) + return ret; + + /* 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); + + /* No hpos info available. */ + if (hpos) + *hpos = 0; + + /* 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) + ret |= DRM_SCANOUTPOS_VALID; + + /* 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; + if (mode->flags & DRM_MODE_FLAG_INTERLACE) + *vpos /= 2; + + ret |= DRM_SCANOUTPOS_ACCURATE; + 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. + */ + ret |= DRM_SCANOUTPOS_IN_VBLANK; + vblank_lines = mode->crtc_vtotal - mode->crtc_vdisplay; + + if (flags & DRM_CALLED_FROM_VBLIRQ) { + /* + * 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. + */ + if ((val & SCALER_DISPSTATX_FULL) != SCALER_DISPSTATX_FULL) + ret |= DRM_SCANOUTPOS_ACCURATE; + } 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; +} + +int vc4_crtc_get_vblank_timestamp(struct drm_device *dev, unsigned int crtc_id, + int *max_error, struct timeval *vblank_time, + unsigned flags) +{ + struct vc4_dev *vc4 = to_vc4_dev(dev); + struct vc4_crtc *vc4_crtc = vc4->crtc[crtc_id]; + struct drm_crtc *crtc = &vc4_crtc->base; + struct drm_crtc_state *state = crtc->state; + + /* Helper routine in DRM core does all the work: */ + return drm_calc_vbltimestamp_from_scanoutpos(dev, crtc_id, max_error, + vblank_time, flags, + &state->adjusted_mode); +} + static void vc4_crtc_destroy(struct drm_crtc *crtc) { drm_crtc_cleanup(crtc); @@ -526,6 +669,7 @@ static irqreturn_t vc4_crtc_irq_handler(int irq, void *data) irqreturn_t ret = IRQ_NONE; if (stat & PV_INT_VFP_START) { + vc4_crtc->t_vblank = ktime_get(); CRTC_WRITE(PV_INTSTAT, PV_INT_VFP_START); drm_crtc_handle_vblank(&vc4_crtc->base); vc4_crtc_handle_page_flip(vc4_crtc); @@ -730,6 +874,22 @@ static void vc4_set_crtc_possible_masks(struct drm_device *drm, } } +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; +} + static int vc4_crtc_bind(struct device *dev, struct device *master, void *data) { struct platform_device *pdev = to_platform_device(dev); @@ -806,6 +966,8 @@ static int vc4_crtc_bind(struct device *dev, struct device *master, void *data) crtc->cursor = cursor_plane; } + vc4_crtc_get_cob_allocation(vc4_crtc); + CRTC_WRITE(PV_INTEN, 0); CRTC_WRITE(PV_INTSTAT, PV_INT_VFP_START); ret = devm_request_irq(dev, platform_get_irq(pdev, 0), diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c index 6d97d3edb2d2..65f77cc243a6 100644 --- a/drivers/gpu/drm/vc4/vc4_drv.c +++ b/drivers/gpu/drm/vc4/vc4_drv.c @@ -92,6 +92,8 @@ static struct drm_driver vc4_drm_driver = { .enable_vblank = vc4_enable_vblank, .disable_vblank = vc4_disable_vblank, .get_vblank_counter = drm_vblank_no_hw_counter, + .get_scanout_position = vc4_crtc_get_scanoutpos, + .get_vblank_timestamp = vc4_crtc_get_vblank_timestamp, #if defined(CONFIG_DEBUG_FS) .debugfs_init = vc4_debugfs_init, diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h index 37cac59401d7..1b5dc6074244 100644 --- a/drivers/gpu/drm/vc4/vc4_drv.h +++ b/drivers/gpu/drm/vc4/vc4_drv.h @@ -415,6 +415,13 @@ extern struct platform_driver vc4_crtc_driver; int vc4_enable_vblank(struct drm_device *dev, unsigned int crtc_id); void vc4_disable_vblank(struct drm_device *dev, unsigned int crtc_id); int vc4_crtc_debugfs_regs(struct seq_file *m, void *arg); +int vc4_crtc_get_scanoutpos(struct drm_device *dev, unsigned int crtc_id, + unsigned int flags, int *vpos, int *hpos, + ktime_t *stime, ktime_t *etime, + const struct drm_display_mode *mode); +int vc4_crtc_get_vblank_timestamp(struct drm_device *dev, unsigned int crtc_id, + int *max_error, struct timeval *vblank_time, + unsigned flags); /* vc4_debugfs.c */ int vc4_debugfs_init(struct drm_minor *minor); diff --git a/drivers/gpu/drm/vc4/vc4_regs.h b/drivers/gpu/drm/vc4/vc4_regs.h index f99eece4cc97..160942a9180e 100644 --- a/drivers/gpu/drm/vc4/vc4_regs.h +++ b/drivers/gpu/drm/vc4/vc4_regs.h @@ -366,7 +366,6 @@ # define SCALER_DISPBKGND_FILL BIT(24) #define SCALER_DISPSTAT0 0x00000048 -#define SCALER_DISPBASE0 0x0000004c # define SCALER_DISPSTATX_MODE_MASK VC4_MASK(31, 30) # define SCALER_DISPSTATX_MODE_SHIFT 30 # define SCALER_DISPSTATX_MODE_DISABLED 0 @@ -375,6 +374,24 @@ # define SCALER_DISPSTATX_MODE_EOF 3 # define SCALER_DISPSTATX_FULL BIT(29) # define SCALER_DISPSTATX_EMPTY BIT(28) +# define SCALER_DISPSTATX_FRAME_COUNT_MASK VC4_MASK(17, 12) +# define SCALER_DISPSTATX_FRAME_COUNT_SHIFT 12 +# define SCALER_DISPSTATX_LINE_MASK VC4_MASK(11, 0) +# define SCALER_DISPSTATX_LINE_SHIFT 0 + +#define SCALER_DISPBASE0 0x0000004c +/* Last pixel in the COB (display FIFO memory) allocated to this HVS + * channel. Must be 4-pixel aligned (and thus 4 pixels less than the + * next COB base). + */ +# define SCALER_DISPBASEX_TOP_MASK VC4_MASK(31, 16) +# define SCALER_DISPBASEX_TOP_SHIFT 16 +/* First pixel in the COB (display FIFO memory) allocated to this HVS + * channel. Must be 4-pixel aligned. + */ +# define SCALER_DISPBASEX_BASE_MASK VC4_MASK(15, 0) +# define SCALER_DISPBASEX_BASE_SHIFT 0 + #define SCALER_DISPCTRL1 0x00000050 #define SCALER_DISPBKGND1 0x00000054 #define SCALER_DISPBKGNDX(x) (SCALER_DISPBKGND0 + \ @@ -385,6 +402,9 @@ (x) * (SCALER_DISPSTAT1 - \ SCALER_DISPSTAT0)) #define SCALER_DISPBASE1 0x0000005c +#define SCALER_DISPBASEX(x) (SCALER_DISPBASE0 + \ + (x) * (SCALER_DISPBASE1 - \ + SCALER_DISPBASE0)) #define SCALER_DISPCTRL2 0x00000060 #define SCALER_DISPCTRLX(x) (SCALER_DISPCTRL0 + \ (x) * (SCALER_DISPCTRL1 - \ -- cgit v1.2.3 From deb4765db386db67626ffd075d8b5eb5fdf9c4f6 Mon Sep 17 00:00:00 2001 From: Colin Ian King Date: Sat, 9 Jul 2016 23:26:03 +0100 Subject: drm/vc4: remove redundant ret status check At the current point where ret is being checked for non-zero it has not changed since it was initialized to zero, hence the check and the label unref are redundant and can be removed. Signed-off-by: Colin Ian King Reviewed-by: Eric Anholt --- drivers/gpu/drm/vc4/vc4_drv.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c index 65f77cc243a6..2f30214ee810 100644 --- a/drivers/gpu/drm/vc4/vc4_drv.c +++ b/drivers/gpu/drm/vc4/vc4_drv.c @@ -198,8 +198,6 @@ static int vc4_drm_bind(struct device *dev) vc4_bo_cache_init(drm); drm_mode_config_init(drm); - if (ret) - goto unref; vc4_gem_init(drm); @@ -233,7 +231,6 @@ unbind_all: component_unbind_all(dev, drm); gem_destroy: vc4_gem_destroy(drm); -unref: drm_dev_unref(drm); vc4_bo_cache_destroy(drm); return ret; -- cgit v1.2.3