Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 08 12月, 2017 1 次提交
  3. 20 10月, 2017 1 次提交
  5. 29 7月, 2017 1 次提交
    • E
      drm/vc4: Add an ioctl for labeling GEM BOs for summary stats · f3099462
      由 Eric Anholt 提交于 
      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: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20170725182718.31468-2-eric@anholt.netReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      f3099462
  7. 23 6月, 2017 1 次提交
  9. 16 6月, 2017 1 次提交
  11. 01 6月, 2017 1 次提交
  13. 22 5月, 2017 1 次提交
  15. 10 5月, 2017 3 次提交
    • D
      drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos · 1bf6ad62
      由 Daniel Vetter 提交于 
      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: NNeil Armstrong <narmstrong@baylibre.com>
Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-4-daniel.vetter@ffwll.ch
      1bf6ad62
    • D
      drm/vblank: Switch to bool in_vblank_irq in get_vblank_timestamp · 3fcdcb27
      由 Daniel Vetter 提交于 
      It's overkill to have a flag parameter which is essentially used just
as a boolean. This takes care of core + adjusting drivers.

Adjusting the scanout position callback is a bit harder, since radeon
also supplies it's own driver-private flags in there.

v2: Fixup misplaced hunks (Neil).

v3: kbuild says v1 was better ...

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-2-daniel.vetter@ffwll.ch
      3fcdcb27
    • D
      drm/vblank: Switch drm_driver->get_vblank_timestamp to return a bool · d673c02c
      由 Daniel Vetter 提交于 
      There's really no reason for anything more:
- Calling this while the crtc vblank stuff isn't set up is a driver
  bug. Those places alrready DRM_ERROR.
- Calling this when the crtc is off is either a driver bug (calling
  drm_crtc_handle_vblank at the wrong time) or a core bug (for
  anything else). Again, we DRM_ERROR.
- EINVAL is checked at higher levels already, and if we'd use struct
  drm_crtc * instead of (dev, pipe) it would be real obvious that
  those are again core bugs.

The only valid failure mode is crap hardware that couldn't sample a
useful timestamp, to ask the core to just grab a not-so-accurate
timestamp. Bool is perfectly fine for that.

v2: Also fix up the one caller, I lost that in the shuffling (Jani).

v3: Fixup commit message (Neil).

Cc: Jani Nikula <jani.nikula@linux.intel.com>
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: NNeil Armstrong <narmstrong@baylibre.com>
Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-1-daniel.vetter@ffwll.ch
      d673c02c
  17. 09 5月, 2017 1 次提交
  19. 19 4月, 2017 1 次提交
  21. 14 4月, 2017 1 次提交
  23. 09 2月, 2017 1 次提交
  25. 02 2月, 2017 1 次提交
  27. 30 1月, 2017 1 次提交
  29. 18 1月, 2017 1 次提交
  31. 18 12月, 2016 1 次提交
  33. 10 12月, 2016 2 次提交
  35. 30 11月, 2016 1 次提交
  37. 17 11月, 2016 1 次提交
    • J
      drm/vc4: Add fragment shader threading support · c778cc5d
      由 Jonas Pfeil 提交于 
      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: NJonas Pfeil <pfeiljonas@gmx.de>
Signed-off-by: NEric Anholt <eric@anholt.net>
      c778cc5d
  39. 07 10月, 2016 2 次提交
  41. 20 8月, 2016 1 次提交
    • E
      drm/vc4: Fix overflow mem unreferencing when the binner runs dry. · 9326e6f2
      由 Eric Anholt 提交于 
      Overflow memory handling is tricky: While it's still referenced by the
BPO registers, we want to keep it from being freed.  When we are
putting a new set of overflow memory in the registers, we need to
assign the old one to the last rendering job using it.

We were looking at "what's currently running in the binner", but since
the bin/render submission split, we may end up with the binner
completing and having no new job while the renderer is still
processing.  So, if we don't find a bin job at all, look at the
highest-seqno (last) render job to attach our overflow to.
Signed-off-by: NEric Anholt <eric@anholt.net>
Fixes: ca26d28b ("drm/vc4: improve throughput by pipelining binning and rendering jobs")
Cc: stable@vger.kernel.org
      9326e6f2
  43. 16 7月, 2016 1 次提交
    • E
      drm/vc4: Add support for branching in shader validation. · 6d45c81d
      由 Eric Anholt 提交于 
      We're already checking that branch instructions are between the start
of the shader and the proper PROG_END sequence.  The other thing we
need to make branching safe is to verify that the shader doesn't read
past the end of the uniforms stream.

To do that, we require that at any basic block reading uniforms have
the following instructions:

load_imm temp, <next offset within uniform stream>
add unif_addr, temp, unif

The instructions are generated by userspace, and the kernel verifies
that the load_imm is of the expected offset, and that the add adds it
to a uniform.  We track which uniform in the stream that is, and at
draw call time fix up the uniform stream to have the address of the
start of the shader's uniforms at that location.
Signed-off-by: NEric Anholt <eric@anholt.net>
      6d45c81d
  45. 12 7月, 2016 1 次提交
    • M
      drm/vc4: Implement precise vblank timestamping. · 1bf59f1d
      由 Mario Kleiner 提交于 
      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: NMario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: NEric Anholt <eric@anholt.net>
Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> (v2)
      1bf59f1d
  47. 02 6月, 2016 1 次提交
  49. 15 4月, 2016 1 次提交
    • E
      drm/vc4: Add DPI driver · 08302c35
      由 Eric Anholt 提交于 
      The DPI interface involves taking a ton of our GPIOs to be used as
outputs, and routing display signals over them in parallel.

v2: Use display_info.bus_formats[] to replace our custom DT
    properties.
v3: Rebase on V3D documentation changes.
v4: Fix rebase detritus from V3D documentation changes.
Signed-off-by: NEric Anholt <eric@anholt.net>
Acked-by: NRob Herring <robh@kernel.org>
      08302c35
  51. 14 3月, 2016 1 次提交
  53. 17 2月, 2016 5 次提交
  55. 08 2月, 2016 1 次提交
  57. 08 12月, 2015 4 次提交