nouveau userspace back at 1.0.1 used to call the X server
DRIOpenDRMMaster interface even for DRI2 (doh!), this attempts
to map the sarea and fails if it can't.
Since 884c6dabb0 from Daniel,
this fails, but only ancient drivers would see it.
Revert the nouveau bits of that fix.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: <stable@vger.kernel.org> # 3.18
Signed-off-by: Dave Airlie <airlied@redhat.com>
On !SMP systems spinlocks do not exist. Thus checking of they
are active will always fail.
Use
assert_spin_locked(lock);
instead of
BUG_ON(!spin_is_locked(lock));
to not BUG() on all UP systems.
Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The failure paths if we fail to wake the card are less than desirable,
but there's not really a graceful way to handle this case currently.
I'll keep this situation in mind when I get to fixing other vm-related
issues.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nouveau_ttm_tt_unpopulate() is supposed to return right after calling
ttm_dma_unpopulate() in the case of a coherent buffer. The return
statement was omitted, leading to the pages being unmapped twice. Fix
this.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
When amdkfd and radeon are compiled inside the kernel image (not as modules),
radeon will load before amdkfd, which will cause a bug when radeon will probe
the GPUs.
When the two drivers are compiled as modules, amdkfd is loaded after radeon is
loaded but before radeon starts probing the GPUs. This is done because radeon
loads the amdkfd module through symbol_request function.
This patch makes amdkfd load before radeon when they are both compiled inside
the kernel image, which makes the behavior similar to the case when they are
modules, and prevents the kernel bug.
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
If crtc <-> encoder linkage changes, we could end up with the CRTC
listening for the wrong error or vsync irqs. Generally this problem
would correct itself relatively quickly, since we update the global
irqmask after dispatching irqs, but to be sure let the CRTC trigger
update_irq().
Signed-off-by: Rob Clark <robdclark@gmail.com>
We can't have multiple updates pending on a given CRTC, and we don't
want a sync update to race w/ an async update that preceeded it. So
keep track of which CRTCs have updates in flight, and block later
updates that would conflict.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Without this RPM ref we can hit the device suspended WARN via:
i915_gem_object_pin()->ggtt_bind_vma->gen6_ggtt_insert_entries(). I
noticed this on my BYT while keeping the i915 device in runtime
suspended state for a while. I chose this place to take the ref to
avoid the possible deadlock via the mutex_lock taken both later in this
function and in the runtime suspend handler. This can happen if an RPM
suspend event is queued and need to be flushed before taking the RPM
ref.
Testcase: igt/pm_rpm/gem-evict-pwrite
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87363
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The VGA_2X_MODE bit apparently affects the display even when the VGA
plane is disabled. The bit will set by the BIOS when the panel width
is at least 1280 pixels. So by preserving the bit from the BIOS we
end up with corrupted display on machines with such high res panels.
I only have 1024x768 panels on my gen2 machines so never ran into
this problem.
The original reason for preserving the VGACNTR register was to make
my 830 survive S3 with acpi_sleep=s3_bios option. However after
further 830 fixes that option is no longer needed to make S3 work
and preserving VGACNTR doesn't seem to be necessary without it,
so we can just revert the entire patch.
This reverts
commit 69769f9a42
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Aug 15 01:22:08 2014 +0300
drm/i915: Preserve VGACNTR bits from the BIOS
Cc: Bruno Prémont <bonbons@linux-vserver.org>
Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87171
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The flip stall detector kicks in when pending>=INTEL_FLIP_COMPLETE. That
means if we first call intel_prepare_page_flip() but don't call
intel_finish_page_flip(), the next stall check will erroneosly think
the page flip was somehow stuck.
With enough debug spew emitted from the interrupt handler my 830 hangs
when this happens. My theory is that the previous vblank interrupt gets
sufficiently delayed that the handler will see the pending bit set in
IIR, but ISR still has the bit set as well (ie. the flip was processed
by CS but didn't complete yet). In this case the handler will proceed
to call intel_check_page_flip() immediately after
intel_prepare_page_flip(). It then tries to print a backtrace for the
stuck flip WARN, which apparetly results in way too much debug spew
delaying interrupt processing further. That then seems to cause an
endless loop in the interrupt handler, and the machine is dead until
the watchdog kicks in and reboots. At least limiting the number of
iterations of the loop in the interrupt handler also prevented the
hang.
So it seems better to not call intel_prepare_page_flip() without
immediately calling intel_finish_page_flip(). The IIR/ISR trickery
avoids races here so this is a perfectly safe thing to do.
v2: Fix typo in commit message (checkpatch)
Cc: stable@vger.kernel.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88381
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85888
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
pps_{lock,unlock}() call intel_display_power_{get,put}() outside
pps_mutes to avoid deadlocks with the power_domain mutex. In theory
during aux transfers we should usually have the relevant power domain
references already held by some higher level code, so this should not
result in much overhead (exception being userspace i2c-dev access).
However thanks to the check_power_well() calls in
intel_display_power_{get/put}() we end up doing a few Punit reads for
each aux transfer. Obviously doing this for each byte transferred via
i2c-over-aux is not a good idea.
I can't think of a good way to keep check_power_well() while eliminating
the overhead, so let's just remove check_power_well() entirely.
Fixes a driver init time regression introduced by:
commit 773538e860
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Thu Sep 4 14:54:56 2014 +0300
drm/i915: Reset power sequencer pipe tracking when disp2d is off
Credit goes to Jani for figuring this out.
v2: Add the regression note in the commit message.
Cc: stable@vger.kernel.org (v3.18+)
Cc: Egbert Eich <eich@suse.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86201
Tested-by: Wendy Wang <wendy.wang@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
During plane operations, we read/write some registers that only operate
properly if we're not runtime suspended. At the moment we're not
holding the runtime PM reference across the whole plane operation, so
there's a potential for problems.
This issue was already partially addressed by commit
commit d6dd6843ff
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Fri Aug 15 15:59:32 2014 -0300
drm/i915: fix plane/cursor handling when runtime suspended
which took care of holding the runtime PM reference during the pin and
fence operations for plane updates. However there are still a few
actual plane registers that we also need to hold the runtime PM
reference for. Recent refactoring patches in preparation for atomic
have rearranged the code and made it increasingly likely that the
hardware will have time to suspend between the pin/fence operation and
the actual register writes. Examples of such registers are the stuff
touched by ivb_get_colorkey.
The solution here grabs the runtime PM reference around the 'commit'
operation for planes, which should cover all the relevant register
reads/writes.
Note that this has only been exposed with
commit 6beb8c23eb
Author: Matt Roper <matthew.d.roper@intel.com>
Date: Mon Dec 1 15:40:14 2014 -0800
drm/i915: Consolidate plane 'prepare' functions (v2)
so doesn't need to be ported to 3.19.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87180
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Testcase: igt/pm-rpm/legacy-planes
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Augment commit message with information Paulo supplied.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When a plane is being enabled, plane->crtc has not been set yet. Use
plane->state->crtc.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Let's be optimistic that for future platforms this will remain the same
and reorg a bit.
This reorg in if blocks instead of switch make life easier for future
platform support addition.
Cc: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Let's be optimistic that for future platforms this will remain the same
and reorg a bit.
This reorg in if blocks instead of switch make life easier for future
platform support addition.
Cc: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Let's be optimistic that for future platforms this will remain the same
and reorg a bit.
This reorg in if blocks instead of switch make life easier for future
platform support addition.
Cc: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Let's be optimistic that for future platforms memory management doesn't change
that much and reuse gen8 function for PPGTT init.
Cc: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Let's be optimistic that for future platforms this will remain the same
and reorg a bit.
This reorg in if blocks instead of switch make life easier for future
platform support addition.
v2: Jani pointed out I was missing reg_830 for some gen3 platforms. So let's make
this platforms subcases of Gen checks.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The release_firmware() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The functions framebuffer_release() and vunmap() perform also input
parameter validation. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
In finish pageflip, the driver was not selecting the root window when
dispatching events. This exposed a race where a plane update would
change the window selection and cause tegra_dc_finish_page_flip to check
the wrong base address.
This patch also protects access to the window selection register as well
as the registers affected by it.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
If the requested buffer size wasn't a multiple of the page size, the
IOMMU code would round down the size to the next multiple of the page
size, thereby causing translation errors. To fix this we no longer pass
around the requested size but reuse the computed size of the GEM object.
This is already rounded to the next page boundary, so mapping that size
works out fine.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Buffers obtained via shmem may still have associated cachelines. If they
aren't properly flushed they may cause framebuffer corruption if the
cache gets flushed after the application has drawn to it.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Page-flip completion could race with page-flip submission, so extend the
critical section to include all accesses to page-flip related data.
Reported-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The hardware pipe numbers don't always match the DRM CRTC indices. This
can happen for example if the first display controller defers probe,
causing it to be registered with DRM after the second display
controller. When that happens the hardware pipe numbers and DRM CRTC
indices become different. Make sure that the CRTC index is always used
when accessing per-CRTC VBLANK data. This can be ensured by using the
drm_crtc_vblank_*() API, which will do the right thing automatically
given a struct drm_crtc *.
Signed-off-by: Thierry Reding <treding@nvidia.com>
This function is the KMS native variant of drm_vblank_count(). It takes
a struct drm_crtc * instead of a struct drm_device * and an index of the
CRTC.
Eventually the goal is to access vblank data through the CRTC only so
that the per-CRTC data can be moved to struct drm_crtc.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This function is the KMS native variant of drm_handle_vblank(). It takes
a struct drm_crtc * instead of a struct drm_device * and an index of the
CRTC.
Eventually the goal is to access vblank data through the CRTC only so
that the per-CRTC data can be moved to struct drm_crtc.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This function is the KMS native variant of drm_send_vblank_event(). It
takes a struct drm_crtc * instead of a struct drm_device * and an index
of the CRTC.
Eventually the goal is to access vblank data through the CRTC only so
that the per-CRTC data can be moved to struct drm_crtc.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This patch fixes a bug in kgd_set_pasid_vmid_mapping(), where the function
only updated the ATC registers (IOMMU) with the new VMID <--> PASID mapping,
but didn't update the IH (Interrupt) registers.
The bug only occurs when using non-HWS mode. In HWS mode, the CP automatically
does the VMID <--> PASID mapping.
Signed-off-by: Ben Goz <ben.goz@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
If timeout happens, kgd_hqd_destroy() just returns -ETIME leaving queue
acquired.
It may cause a deadlock, so the patch proposes to release queue before return.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
This patch fixes a bug in DQM, where the MQD of a newly created compute queue
is not loaded to an HQD slot. As a result, the CP never reads packets from this
queue.
This bug happens only in non-HWS (hardware scheduling) mode. In HWS mode, the
CP is responsible of loading MQDs to HQDs slots.
Signed-off-by: Ben Goz <ben.goz@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
There exists a current workaround to prevent a hang on context switch
should the ring go to sleep in the middle of the restore,
WaProgramMiArbOnOffAroundMiSetContext (applicable to all gen7+). In
spite of disabling arbitration (which prevents the ring from powering
down during the critical section) we were still hitting hangs that had
the hallmarks of the known erratum. That is we are still seeing hangs
"on the last instruction in the context restore". By comparing -nightly
(broken) with requests (working), we were able to deduce that it was the
semaphore LRI cross-talk that reproduced the original failure. The key
was that requests implemented deferred semaphore signalling, and
disabling that, i.e. emitting the semaphore signal to every other ring
after every batch restored the frequent hang. Explicitly disabling PSMI
sleep on the RCS ring was insufficient, all the rings had to be awake to
prevent the hangs. Fortunately, we can reduce the wakelock to the
MI_SET_CONTEXT operation itself, and so should be able to limit the extra
power implications.
Since the MI_ARB_ON_OFF workaround is listed for all gen7 and above
products, we should apply this extra hammer for all of the same
platforms despite so far that we have only been able to reproduce the
hang on certain ivb and hsw models. The last question is whether we want
to always use the extra hammer or only when we know semaphores are in
operation. At the moment, we only use LRI on non-RCS rings for
semaphores, but that may change in the future with the possibility of
reintroducing this bug under subtle conditions.
v2: Make it explicit that the PSMI LRI are an extension to the original
workaround for the other rings.
v3: Bikeshedding variable names and whitespacing
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80660
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83677
Cc: Simon Farnsworth <simon@farnz.org.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Peter Frühberger <fritsch@xbmc.org>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
In order to act as a full command barrier by itself, we need to tell the
pipecontrol to actually stall the command streamer while the flush runs.
We require the full command barrier before operations like
MI_SET_CONTEXT, which currently rely on a prior invalidate flush.
References: https://bugs.freedesktop.org/show_bug.cgi?id=83677
Cc: Simon Farnsworth <simon@farnz.org.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
In the gen7 pipe control there is an extra bit to flush the media
caches, so let's set it during cache invalidation flushes.
v2: Rename to MEDIA_STATE_CLEAR to be more inline with spec.
Cc: Simon Farnsworth <simon@farnz.org.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Many distro's have mechanism in place to collect and automatically file
bugs for failed WARN()s. And since i915 has a lot of hw state sanity
checks which result in WARN(), it generates quite a lot of noise which
is somewhat disconcerting to the end user.
Separate out the internal hw-is-in-the-state-I-expected checks into
I915_STATE_WARN()s and allow configuration via i915.verbose_checks module
param about whether this will generate a full blown stacktrace or just
DRM_ERROR(). The new moduleparam defaults to true, so by default there
is no change in behavior. And even when disabled, you will still get
an error message logged.
v2: paint the macro names blue, clarify that the default behavior
remains the same as before
Signed-off-by: Rob Clark <robdclark@gmail.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Otherwise, new platforms without workarounds will hit this warning for
every new context created.
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In Gen8+, full ppgtt needs execlist, otherwise the ctx switch can hang.
Also remove the current restriction, a user should be able to explicitly set
ppgtt=2.
Note, this patch considers that execlist support has been enabled by
default on Gen8.
v2: Remove non-default restriction and clarify commit message (Daniel)
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
[danvet: s/comment/commit message/ in the commit message since that's
what Michel meant as per our irc discussion.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With cherryview onwards, Gunit hardware itself save and restore all the
Gunit registers. Skipping the "vlv_save_gunit_s0ix_state" &
"vlv_restore_gunit_s0ix_state" for cherryview in S3/S0ix sequence.
Signed-off-by: Deepak S <deepak.s@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Higher RC6 residency is observed using timeout mode
instead of EI mode. It's Recommended to use TO Method for RC6.
v2: Add comment about timeout threshold. (Tom)
Signed-off-by: Deepak S <deepak.s@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This will allow us to read the number of dispatched compute threads
for GL_ARB_pipeline_statistics_query.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Move it to a separate function since the main do_execbuffer function
already has so much going on.
v2:
- Move pin/unpin calls inside i915_parse_cmds() (Chris W, v4 7/7
feedback)
Issue: VIZ-4719
Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
Reviewed-By: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
