drm-next-5.3-2019-06-25:
Merge drm-next
amdgpu:
- SR-IOV L1 policy fixes
- Removed no longer needed vram_page_split module parameter
- Add module parameter to override default ABM level
- Gamma fixes
- No need to check return values for debugfs
- Improve HMM error handling
- Avoid possible OOM situations when lots of thread are submitting with
memory contention
- Improve hw i2c access abritration
- DSC (Display Stream Compression) support in DC
- Initial navi10 support
* DC support
* GFX/Compute support
* SDMA support
* Power Management support
* VCN support
- Static checker fixes
- Misc cleanups
- fix long udelay on arm
amdkfd:
- Implement priority controls for gfx9
- Enable VEGAM
- Rework mqd allocation and init
- Circular locking fix
- Fix SDMA queue allocation race condition
- No need to check return values for debugfs
- Add proc style process information
- Initial navi10 support
radeon:
- No need to check return values for debugfs
UAPI changes:
- GDDR6 added to vram type query
- New Navi10 details added gpu info query
- Navi family added to asic family query
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190625195520.3817-1-alexander.deucher@amd.com
The crc computation worker needs to be able to get at some data
structures and framebuffer mappings, while potentially more atomic
updates are going on. The solution thus far is to copy relevant bits
around, but that's very tedious.
Here's a new approach, which tries to be more clever, but relies on a
few not-so-obvious things:
- crtc_state is always updated when a plane_state changes. Therefore
we can just stuff plane_state pointers into a crtc_state. That
solves the problem of easily getting at the needed plane_states.
- with the flushing changes from previous patches the above also holds
without races due to the next atomic update being a bit eager with
cleaning up pending work - we always wait for all crc work items to
complete before unmapping framebuffers.
- we also need to make sure that the hrtimer fires off the right
worker. Keep a new distinct crc_state pointer, under the
vkms_output->lock protection for this. Note that crtc->state is
updated very early in the atomic commit, way before we arm the
vblank event - the vblank event should always match the buffers we
use to compute the crc. This also solves an issue in the hrtimer,
where we've accessed drm_crtc->state without holding the right locks
(we held none - oops).
- in the worker itself we can then just access the plane states we
need, again solving a bunch of ordering and locking issues.
Accessing plane->state requires locks, accessing the private
vkms_crtc_state->active_planes pointer only requires that the memory
doesn't get freed too early.
The idea behind vkms_crtc_state->active_planes is that this would
contain all visible planes, in z-order, as a first step towards a more
generic blending implementation.
Note that this patch also fixes races between prepare_fb/cleanup_fb
and the crc worker accessing ->vaddr.
Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Tested-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190606222751.32567-10-daniel.vetter@ffwll.ch
Currently, we flush pending CRC workers very late in the commit flow,
when we destroy all the old crtc states. Unfortunately, at that point,
the framebuffers are already unpinned (and our vaddr possible gone), so
this isn't good. Also, the plane_states we need might also already be
cleaned up, since cleanup order of state structures isn't well defined.
Fix this by waiting for all CRC workers of the old state to complete
before we start any of the cleanup work. For correct ordering and
avoiding races, we can only flush_work after
drm_atomic_helper_wait_for_vblanks() since we know that all subsequent
queue_work will be for the new state. Only once that's done is
flush_work() useful, before that we might flush the work, and then right
after the hrtimer that simulates vblank queues it again. Every time you
have a flush_work before cleaning up the work structure, the following
sequence must be obeyed, or it can go wrong:
1. Make sure no one else can re-queue the work anymore (in our case
that's done by a combination of first updating output->crc_state and
then waiting for the vblank to pass to make sure the hrtimer has noticed
that change).
2. flush_work()
3. Actually clean up stuff (which isn't done here).
Doing the flush_work before we even completed the output->state update,
much less waited for the vblank to make sure that's happened, missed the
point.
Note that this is not yet race-free because of the hrtimer and crc
worker look at the wrong state pointers, but that will be fixed in
subsequent patches.
Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Tested-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190606222751.32567-7-daniel.vetter@ffwll.ch
The issue we have is that the crc worker might fall behind. We've
tried to handle this by tracking both the earliest frame for which it
still needs to compute a crc, and the last one. Plus when the
crtc_state changes, we have a new work item, which are all run in
order due to the ordered workqueue we allocate for each vkms crtc.
Trouble is there's been a few small issues in the current code:
- we need to capture frame_end in the vblank hrtimer, not in the
worker. The worker might run much later, and then we generate a lot
of crc for which there's already a different worker queued up.
- frame number might be 0, so create a new crc_pending boolean to
track this without confusion.
- we need to atomically grab frame_start/end and clear it, so do that
all in one go. This is not going to create a new race, because if we
race with the hrtimer then our work will be re-run.
- only race that can happen is the following:
1. worker starts
2. hrtimer runs and updates frame_end
3. worker grabs frame_start/end, already reading the new frame_end,
and clears crc_pending
4. hrtimer calls queue_work()
5. worker completes
6. worker gets re-run, crc_pending is false
Explain this case a bit better by rewording the comment.
v2: Demote warning level output to debug when we fail to requeue, this
is expected under high load when the crc worker can't quite keep up.
Cc: Shayenne Moura <shayenneluzmoura@gmail.com>
Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Tested-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190606222751.32567-2-daniel.vetter@ffwll.ch
TDA998x updates:
- improve the driver's approach to audio, adding support for more I2S
based formats, particularly other justifications, and preparing the
driver to support other bclk ratios.
- add support for pixel repeated modes, tested with a Panasonic TV.
- correct the quantisation range handling; in particular, do not send
full range RGB to the sink when the sink does not support full range
RGB.
- Send the HDMI vendor info frame when required.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Russell King <rmk@armlinux.org.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190625125005.GA31503@rmk-PC.armlinux.org.uk
If we issue a reset to a currently idle engine, leave it idle
afterwards. This is useful to excise a linkage between reset and the
shrinker. When waking the engine, we need to pin the default context
image which we use for overwriting a guilty context -- if the engine is
idle we do not need this pinned image! However, this pinning means that
waking the engine acquires the FS_RECLAIM, and so may trigger the
shrinker. The shrinker itself may need to wait upon the GPU to unbind
and object and so may require services of reset; ergo we should avoid
the engine wake up path.
The danger in skipping the recovery for idle engines is that we leave the
engine with no context defined, which may interfere with the operation of
the power context on some older platforms. In practice, we should only
be resetting an active GPU but it something to look out for on Ironlake
(if memory serves).
Fixes: 79ffac8599 ("drm/i915: Invert the GEM wakeref hierarchy")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190626154549.10066-2-chris@chris-wilson.co.uk
Gen2 doesn't have a frame counter and apparently we no longer provide
a fake .get_vblank_counter() hook for it. That means all tracepoints
calling that hook will oops. Update the tracepoints to use
intel_crtc_get_vblank_counter() which will gracefully fall back to
using the software counter. This is actually a better approach since
we now get (hopefully accurate) frame numbers in the traces.
This also gets rid of the raw driver->get_vblank_counter() calls, which
we need to do in order to switch to the per-crtc vblank vfuncs.
v2: Deal with new tracepoints
v3: Use a distinct variable name for the internal crtc iterator (Chris)
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Fixes: 967dd48417 ("drm: remove drm_vblank_no_hw_counter assignment from driver code")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190619170842.20579-2-ville.syrjala@linux.intel.com
