kernel/drivers/gpu/drm/vc4/vc4_v3d.c, branch linux-4.17.y

drm/vc4: Expose performance counters to userspace

2018-02-10T22:23:26Z

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 Reviewed-by: Eric Anholt Signed-off-by: Eric Anholt Link: https://patchwork.freedesktop.org/patch/msgid/20180112090926.12538-1-boris.brezillon@free-electrons.com

drm/vc4: Move IRQ enable to PM path

2018-01-03T23:56:03Z

We were calling enable_irq on bind, where it was already enabled previously by the IRQ helper. Additionally, dev->irq is not set correctly until after postinstall and so was always zero here, triggering a warning in 4.15. Fix both by moving the enable to the power management resume path, where we know there was a previous disable invocation during suspend. Fixes: 253696ccd613 ("drm/vc4: Account for interrupts in flight") Signed-off-by: Stefan Schake Signed-off-by: Eric Anholt Link: https://patchwork.freedesktop.org/patch/msgid/1514563543-32511-1-git-send-email-stschake@gmail.com Tested-by: Stefan Wahren Reviewed-by: Eric Anholt

drm/vc4: Add an ioctl for labeling GEM BOs for summary stats

2017-07-28T23:04:53Z

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 Link: https://patchwork.freedesktop.org/patch/msgid/20170725182718.31468-2-eric@anholt.net Reviewed-by: Chris Wilson

drm/vc4: Mark the device as active when enabling runtime PM.

2017-06-02T20:00:47Z

Failing to do so meant that we got a resume() callback on first use of the device, so we would leak the bin BO that we allocated during probe. Signed-off-by: Eric Anholt Fixes: 553c942f8b2c ("drm/vc4: Allow using more than 256MB of CMA memory.") Link: http://patchwork.freedesktop.org/patch/msgid/20170515171615.10168-1-eric@anholt.net Reviewed-by: Boris Brezillon

drm/vc4: fix include notation and remove -Iinclude/drm flag

2017-05-22T07:36:01Z

Include 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 Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1495081793-9707-2-git-send-email-yamada.masahiro@socionext.com

drm/vc4: Add specific compatible strings for Cygnus.

2017-05-08T19:24:06Z

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 Acked-by: Rob Herring Link: http://patchwork.freedesktop.org/patch/msgid/20170428224223.21904-3-eric@anholt.net

drm/vc4: Turn the V3D clock on at runtime.

2017-05-08T19:24:06Z

For the Raspberry Pi's bindings, the power domain also implicitly turns on the clock and deasserts reset, but for the new Cygnus port we start representing the clock in the devicetree. v2: Document the clock-names property, check for -ENOENT for no clock in DT. v3: Drop NULL checks around clk calls which embed NULL checks. v4: Drop clk-names (feedback by Rob Herring) Signed-off-by: Eric Anholt Acked-by: Rob Herring Link: http://patchwork.freedesktop.org/patch/msgid/20170428224223.21904-1-eric@anholt.net

drm/vc4: Allow using more than 256MB of CMA memory.

2017-04-18T21:32:20Z

Until now, we've had to limit Raspberry Pi to 256MB of CMA memory to keep from triggering the hardware addressing bug between the tile binner and the tile alloc memory (where the top 4 bits come from the tile state data array's address). To work around that and allow more memory to be reserved for graphics, allocate a single BO to store tile state data arrays and tile alloc/overflow memory while the GPU is active, and make sure that that one BO doesn't happen to cross a 256MB boundary. With that in place, we can allocate textures and shaders anywhere in system memory (still contiguous, of course). Signed-off-by: Eric Anholt Link: http://patchwork.freedesktop.org/patch/msgid/20170327231025.19391-1-eric@anholt.net Reviewed-by: Boris Brezillon

drm/vc4: Use runtime autosuspend to avoid thrashing V3D power state.

2016-11-04T23:12:35Z

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

drm/vc4: Recognize a more specific compatible string for V3D.

2016-03-14T01:54:24Z

The Raspberry Pi Foundation's firmware updates are shipping device trees using the old string, so we'll keep recognizing that as this rev of V3D. Still, we should use a more specific name in the upstream DT to clarify which board is being supported, in case we do other revs of V3D in the future. Signed-off-by: Eric Anholt Acked-by: Stephen Warren