2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-27 14:43:58 +08:00
Commit Graph

7 Commits

Author SHA1 Message Date
Eric Anholt
3a62234680 drm/vc4: Use runtime autosuspend to avoid thrashing V3D power state.
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>
2016-11-04 16:12:35 -07:00
Eric Anholt
90d7116061 drm/vc4: Recognize a more specific compatible string for V3D.
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 <eric@anholt.net>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
2016-03-13 18:54:24 -07:00
Eric Anholt
36cb6253f9 drm/vc4: Use runtime PM to power cycle the device when the GPU hangs.
This gets us functional GPU reset again, like we had until a refactor
at merge time.  Tested with a little patch to stuff in a broken binner
job every 100 frames.

Signed-off-by: Eric Anholt <eric@anholt.net>
2016-02-16 12:21:01 -08:00
Eric Anholt
001bdb55d9 drm/vc4: Enable runtime PM.
This may actually get us a feature that the closed driver didn't have:
turning off the GPU in between rendering jobs, while the V3D device is
still opened by the client.

There may be some tuning to be applied here to use autosuspend so that
we don't bounce the device's power so much, but in steady-state
GPU-bound rendering we keep the power on (since we keep multiple jobs
outstanding) and even if we power cycle on every job we can still
manage at least 680 fps.

More importantly, though, runtime PM will allow us to power off the
device to do a GPU reset.

v2: Switch #ifdef to CONFIG_PM not CONFIG_PM_SLEEP (caught by kbuild
    test robot)

Signed-off-by: Eric Anholt <eric@anholt.net>
2016-02-16 12:21:00 -08:00
Eric Anholt
8483d152db drm/vc4: Remove broken attempt at GPU reset using genpd.
I've tested and confirmed that it doesn't actually work.  We'll need
to sort out how to do this properly later, but for now just remove it
since it also caused build breakage due to using CONFIG_PM_SLEEP
functions without our Kconfig depending on PM_SLEEP.

Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
2016-01-19 13:16:31 -08:00
Eric Anholt
d5b1a78a77 drm/vc4: Add support for drawing 3D frames.
The user submission is basically a pointer to a command list and a
pointer to uniforms.  We copy those in to the kernel, validate and
relocate them, and store the result in a GPU BO which we queue for
execution.

v2: Drop support for NV shader recs (not necessary for GL), simplify
    vc4_use_bo(), improve bin flush/semaphore checks, use __u32 style
    types.

Signed-off-by: Eric Anholt <eric@anholt.net>
2015-12-07 20:05:10 -08:00
Eric Anholt
d3f5168a08 drm/vc4: Bind and initialize the V3D engine.
This is the component of the GPU that does 3D rendering.

Signed-off-by: Eric Anholt <eric@anholt.net>
2015-12-07 20:05:10 -08:00