An error occurred fetching the project authors.
- 30 May, 2018 1 commit
-
-
Eric Anholt authored
Signed-off-by:
Eric Anholt <eric@anholt.net> Fixes: 65101d8c ("drm/vc4: Expose performance counters to userspace") Link: https://patchwork.freedesktop.org/patch/msgid/20180409205813.7077-1-eric@anholt.netReviewed-by:
Boris Brezillon <boris.brezillon@bootlin.com>
-
- 30 Apr, 2018 1 commit
-
-
Stefan Schake authored
This doesn't require any additional functionality from the driver but is a prerequisite to userland calling the syncobj ioctls. Signed-off-by:
Stefan Schake <stschake@gmail.com> Signed-off-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/1524607427-12876-4-git-send-email-stschake@gmail.com
-
- 23 Apr, 2018 2 commits
-
-
Stefan Schake authored
The hardware has a single block for applying a CTM prior to gamma lut. It can be fed with pixels from one of our CRTC at a time and uses a matrix with S0.9 scalars. Use private atomic state to reject attempts from userland to apply CTM for more than one CRTC at a time and reject matrices with scalars that we can't approximate without integer bits. Signed-off-by:
Stefan Schake <stschake@gmail.com> Signed-off-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/218067/
-
Wolfram Sang authored
We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20180419140641.27926-17-wsa+renesas@sang-engineering.com
-
- 10 Feb, 2018 1 commit
-
-
Boris Brezillon authored
The V3D engine has various hardware counters which might be interesting to userspace performance analysis tools. Expose new ioctls to create/destroy a performance monitor object and query the counter values of this perfmance monitor. Note that a perfomance monitor is given an ID that is only valid on the file descriptor it has been allocated from. A performance monitor can be attached to a CL submission and the driver will enable HW counters for this request and update the performance monitor values at the end of the job. Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20180112090926.12538-1-boris.brezillon@free-electrons.com
-
- 08 Dec, 2017 1 commit
-
-
Noralf Trønnes authored
Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on the fact that drm_device holds a pointer to the drm_fb_helper structure. This means that the driver doesn't have to keep track of that. Also use the drm_fb_helper functions directly. Cc: Eric Anholt <eric@anholt.net> Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Reviewed-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20171115142001.45358-18-noralf@tronnes.org
-
- 19 Oct, 2017 1 commit
-
-
Boris Brezillon authored
This ioctl will allow us to purge inactive userspace buffers when the system is running out of contiguous memory. For now, the purge logic is rather dumb in that it does not try to release only the amount of BO needed to meet the last CMA alloc request but instead purges all objects placed in the purgeable pool as soon as we experience a CMA allocation failure. Note that the in-kernel BO cache is always purged before the purgeable cache because those objects are known to be unused while objects marked as purgeable by a userspace application/library might have to be restored when they are marked back as unpurgeable, which can be expensive. Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20171019125748.3152-1-boris.brezillon@free-electrons.com
-
- 08 Aug, 2017 1 commit
-
-
Eric Anholt authored
This is useful to allow GL to provide defined results for overlapping glBlitFramebuffer, which X11 in turn uses to accelerate uncomposited window movement without first blitting to a temporary. x11perf -copywinwin100 goes from 1850/sec to 4850/sec. v2: Default to the same behavior as before when the flags aren't passed. (suggested by Boris) Signed-off-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20170725162733.28007-2-eric@anholt.netReviewed-by:
Boris Brezillon <boris.brezillon@free-electrons.com>
-
- 29 Jul, 2017 1 commit
-
-
Noralf Trønnes authored
This driver can use the drm_driver.dumb_destroy and drm_driver.dumb_map_offset defaults, so no need to set them. Cc: Eric Anholt <eric@anholt.net> Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Reviewed-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/1500837417-40580-20-git-send-email-noralf@tronnes.org
-
- 28 Jul, 2017 1 commit
-
-
Eric Anholt authored
This has proven immensely useful for debugging memory leaks and overallocation (which is a rather serious concern on the platform, given that we typically run at about 256MB of CMA out of up to 1GB total memory, with framebuffers that are about 8MB ecah). The state of the art without this is to dump debug logs from every GL application, guess as to kernel allocations based on bo_stats, and try to merge that all together into a global picture of memory allocation state. With this, you can add a couple of calls to the debug build of the 3D driver and get a pretty detailed view of GPU memory usage from /debug/dri/0/bo_stats (or when we debug print to dmesg on allocation failure). The Mesa side currently labels at the gallium resource level (so you see that a 1920x20 pixmap has been created, presumably for the window system panel), but we could extend that to be even more useful with glObjectLabel() names being sent all the way down to the kernel. (partial) example of sorted debugfs output with Mesa labeling all resources: kernel BO cache: 16392kb BOs (3) tiling shadow 1920x1080: 8160kb BOs (1) resource 1920x1080@32/0: 8160kb BOs (1) scanout resource 1920x1080@32/0: 8100kb BOs (1) kernel: 8100kb BOs (1) v2: Use strndup_user(), use lockdep assertion instead of just a comment, fix an array[-1] reference, extend comment about name freeing. Signed-off-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20170725182718.31468-2-eric@anholt.netReviewed-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
- 15 Jun, 2017 1 commit
-
-
Eric Anholt authored
This allows mesa to set the tiling format for a BO and have that tiling format be respected by mesa on the other side of an import/export (and by vc4 scanout in the kernel), without defining a protocol to pass the tiling through userspace. Signed-off-by:
Eric Anholt <eric@anholt.net> Link: http://patchwork.freedesktop.org/patch/msgid/20170608001336.12842-2-eric@anholt.netAcked-by:
Dave Airlie <airlied@redhat.com>
-
- 22 May, 2017 1 commit
-
-
Masahiro Yamada authored
Include <drm/*.h> instead of relative path from include/drm, then remove the -Iinclude/drm compiler flag. While we are here, use <...> instead of "..." for include/linux/*.h and include/sound/*.h headers too. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1495081793-9707-2-git-send-email-yamada.masahiro@socionext.com
-
- 10 May, 2017 1 commit
-
-
Daniel Vetter authored
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
-
- 08 May, 2017 1 commit
-
-
Eric Anholt authored
Cygnus has V3D 2.6 instead of 2.1, and doesn't use the VC4 display modules. The V3D can be uniquely identified by the IDENT[01] registers, and there's nothing to key off of for the display change other than the lack of DT nodes for the display components, but it's convention to have new compatible strings anyway. Signed-off-by:
Eric Anholt <eric@anholt.net> Acked-by:
Rob Herring <robh@kernel.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170428224223.21904-3-eric@anholt.net
-
- 13 Apr, 2017 1 commit
-
-
Eric Anholt authored
This is needed for proper synchronization with display on another DRM device (pl111 or tinydrm) with buffers produced by vc4 V3D. Fixes the new igt vc4_dmabuf_poll testcase, and rendering of one of the glmark2 desktop tests on pl111+vc4. This doesn't yet introduce waits on another device's fences before vc4's rendering/display, because I don't have testcases for them. v2: Reuse dma_fence_free(), retitle commit message to clarify that it's not a full dma-buf fencing implementation yet. Signed-off-by:
Eric Anholt <eric@anholt.net> Link: http://patchwork.freedesktop.org/patch/msgid/20170412191202.22740-6-eric@anholt.netAcked-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 17 Mar, 2017 1 commit
-
-
Philipp Zabel authored
Use platform_register_drivers instead of open coding the iteration over component platform drivers in the vc4_drv module. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by:
Eric Anholt <eric@anholt.net> Link: http://patchwork.freedesktop.org/patch/msgid/20170317170059.17821-1-p.zabel@pengutronix.de
-
- 28 Feb, 2017 1 commit
-
-
Eric Anholt authored
This makes for more sensible documentation of the whole module than jumping straight into the details of display. Signed-off-by:
Eric Anholt <eric@anholt.net> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170227201144.10970-5-eric@anholt.net
-
- 09 Feb, 2017 1 commit
-
-
Shawn Guo authored
The vblank hooks in struct drm_driver are deprecated and only meant for legacy drivers. For modern drivers with DRIVER_MODESET flag, the hooks in struct drm_crtc_funcs should be used instead. Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Cc: Eric Anholt <eric@anholt.net> Reviewed-by:
Eric Anholt <eric@anholt.net> Link: http://patchwork.freedesktop.org/patch/msgid/1486458995-31018-23-git-send-email-shawnguo@kernel.org
-
- 07 Feb, 2017 1 commit
-
-
Shawn Guo authored
Core code already makes drm_driver.get_vblank_counter hook optional by letting drm_vblank_no_hw_counter be the default implementation for the function hook. So the drm_vblank_no_hw_counter assignment in the driver code becomes redundant and can be removed now. Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Cc: Alexey Brodkin <abrodkin@synopsys.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Mali DP Maintainers <malidp@foss.arm.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Boris Brezillon <boris.brezillon@free-electrons.com> Cc: Inki Dae <inki.dae@samsung.com> Cc: Stefan Agner <stefan@agner.ch> Cc: Xinliang Liu <z.liuxinliang@hisilicon.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: CK Hu <ck.hu@mediatek.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Marek Vasut <marex@denx.de> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Mark Yao <mark.yao@rock-chips.com> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Jyri Sarha <jsarha@ti.com> Cc: Eric Anholt <eric@anholt.net> Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Acked-by:
Neil Armstrong <narmstrong@baylibre.com> Acked-by:
Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Alexey Brodkin <abrodkin@synopsys.com> Acked-by:
Liviu Dudau <liviu.dudau@arm.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1486458995-31018-3-git-send-email-shawnguo@kernel.org
-
- 01 Feb, 2017 1 commit
-
-
Eric Anholt authored
The DSI0 and DSI1 blocks on the 2835 are related hardware blocks. Some registers move around, and the featureset is slightly different, as DSI1 (the 4-lane DSI) is a later version of the hardware block. This driver doesn't yet enable DSI0, since we don't have any hardware to test against, but it does put a lot of the register definitions and code in place. v2: Use the clk_hw interfaces, don't set CLK_IS_BASIC (from review by Stephen Boyd) Signed-off-by:
Eric Anholt <eric@anholt.net> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v1) Link: http://patchwork.freedesktop.org/patch/msgid/20170131192912.11316-1-eric@anholt.net
-
- 30 Jan, 2017 1 commit
-
-
Noralf Trønnes authored
drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so the drm_driver.debugfs_cleanup callback is not needed. Cc: eric@anholt.net Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170126225621.12314-17-noralf@tronnes.org
-
- 09 Dec, 2016 2 commits
-
-
Daniel Vetter authored
vc4 already has a proper load sequence, but the unload one needed some fixups: First unregister, and last drop the final ref. Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
Eric Anholt <eric@anholt.net>
-
Boris Brezillon authored
The VEC IP is a TV DAC, providing support for PAL and NTSC standards. Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by:
Eric Anholt <eric@anholt.net>
-
- 16 Nov, 2016 1 commit
-
-
Jonas Pfeil authored
FS threading brings performance improvements of 0-20% in glmark2. The validation code checks for thread switch signals and ensures that the registers of the other thread are not touched, and that our clamps are not live across thread switches. It also checks that the threading and branching instructions do not interfere. (Original patch by Jonas, changes by anholt for style cleanup, removing validation the kernel doesn't need to do, and adding the flag for userspace). v2: Minor style fixes from checkpatch. Signed-off-by:
Jonas Pfeil <pfeiljonas@gmx.de> Signed-off-by:
Eric Anholt <eric@anholt.net>
-
- 04 Nov, 2016 2 commits
-
-
Eric Anholt authored
The pm_runtime_put() we were using immediately released power on the device, which meant that we were generally turning the device off and on once per frame. In many profiles I've looked at, that added up to about 1% of CPU time, but this could get worse in the case of frequent rendering and readback (as may happen in X rendering). By keeping the device on until we've been idle for a couple of frames, we drop the overhead of runtime PM down to sub-.1%. Signed-off-by:
Eric Anholt <eric@anholt.net>
-
Eric Anholt authored
The validation for it ends up being quite simple, but I hadn't got around to it before merging the driver. For backwards compatibility, we also need to add a flag so that the userspace GL driver can easily tell if the kernel will allow ETC1 textures (on an old kernel, it will continue to convert to RGBA8) Signed-off-by:
Eric Anholt <eric@anholt.net>
-
- 02 Nov, 2016 1 commit
-
-
Jani Nikula authored
If we define drm_compat_ioctl NULL on CONFIG_COMPAT=n, we don't have to check for the config everywhere. Reviewed-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1478014844-27454-1-git-send-email-jani.nikula@intel.com
-
- 22 Sep, 2016 1 commit
-
-
Tom Gundersen authored
There are many reasons other than ENOMEM that drm_dev_init() can fail. Return ERR_PTR rather than NULL to be able to distinguish these in the caller. Signed-off-by:
Tom Gundersen <teg@jklm.no> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20160921145919.13754-2-teg@jklm.no
-
- 20 Aug, 2016 1 commit
-
-
Eric Anholt authored
If the device was already up, a 1 is returned instead of 0. We were erroring out, leading the 3D driver to sometimes fail at screen initialization (generally with ENOENT returned to it). Signed-off-by:
Eric Anholt <eric@anholt.net> Fixes: af713795 ("drm/vc4: Add a getparam ioctl for getting the V3D identity regs.")
-
- 12 Aug, 2016 1 commit
-
-
Daniel Vetter authored
Lots of drivers don't properly compile without this when CONFIG_FB=n. It's kinda a hack, but since CONFIG_FB doesn't stub any fucntions when it's disabled I think it makes sense to add it to drm_fb_helper.h. Long term we probably need to rethink all the logic to unload firmware framebuffer drivers, at least if we want to be able to move away from CONFIG_FB and fbcon. v2: Unfortunately just stubbing out remove_conflicting_framebuffers in drm_fb_helper.h upset gcc about static vs. non-static declarations, so a new wrapper it needs to be. Means more churn :( Cc: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: tomi.valkeinen@ti.com Cc: dh.herrmann@gmail.com Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470847958-28465-2-git-send-email-daniel.vetter@ffwll.ch
-
- 18 Jul, 2016 1 commit
-
-
Markus Elfring authored
The following functions test whether their argument is NULL and then return immediately. * drm_fbdev_cma_hotplug_event * drm_fbdev_cma_restore_mode Thus the tests around their calls are not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/fb33d930-6a5c-c501-6676-26bd486f1cb5@users.sourceforge.net
-
- 15 Jul, 2016 1 commit
-
-
Eric Anholt authored
Userspace needs to know if it can create shaders that do branching. Otherwise, for backwards compatibility with old kernels it needs to lower if statements to conditional assignments. Signed-off-by:
Eric Anholt <eric@anholt.net>
-
- 14 Jul, 2016 1 commit
-
-
Eric Anholt authored
As I extend the driver to support different V3D revisions, userspace needs to know what version it's targeting. This is most easily detected using the V3D identity registers. v2: Make sure V3D is runtime PM on when reading the registers. v3: Switch to a 64-bit param value (suggested by Rob Clark in review) Signed-off-by:
Eric Anholt <eric@anholt.net> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v2) Reviewed-by: Rob Clark <robdclark@gmail.com> (v3, over irc)
-
- 12 Jul, 2016 3 commits
-
-
Colin Ian King authored
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 <colin.king@canonical.com> Reviewed-by:
Eric Anholt <eric@anholt.net>
-
Mario Kleiner authored
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)
-
Eric Anholt authored
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 <eric@anholt.net> Reviewed-and-tested-by:
Mario Kleiner <mario.kleiner.de@gmail.com>
-
- 22 Jun, 2016 2 commits
-
-
Daniel Vetter authored
Somehow I didn't spot this when pushing :( Fixes: 398e9799 ("drm/vc4: Remove open-coded drm_connector_register_all()") Acked-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Chris Wilson authored
drm_dev_register() will now register all known connectors, so we no longer have to do so manually. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Eric Anholt <eric@anholt.net> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1466501283-19976-3-git-send-email-chris@chris-wilson.co.uk
-
- 06 Jun, 2016 1 commit
-
-
Herve Jourdain authored
Contrary to other flags to DRM_IOCTL_DEF_DRV(), which restrict usage, the flag for render node is an enabler (the IOCTL can't be used from render node if it's not present). So DRM_RENDER_ALLOW needs to be added to all the flags that were previously 0. Signed-off-by:
Herve Jourdain <herve.jourdain@neuf.fr> Reviewed-by:
Eric Anholt <eric@anholt.net> Fixes: 0cd3e274 ("drm/vc4: Add missing render node support")
-
- 31 May, 2016 1 commit
-
-
Mario Kleiner authored
get_vblank_counter hooked up to drm_vblank_count() which alway was non-sensical but didn't hurt in the past. Since Linux 4.4 it triggers a WARN_ON_ONCE in drm_update_vblank_count on first vblank irq disable, so fix it by hooking to drm_vblank_no_hw_counter(). Tested against Raspian kernel 4.4.8 tree on RPi 2B. Signed-off-by:
Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Fixes: c8b75bca ("drm/vc4: Add KMS support for Raspberry Pi.")
-