| Age | Commit message (Collapse) | Author |
|---|
|
Not used at all yet, but lets hook it up now anyway.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
No other driver uses this, and userspace should be responsible for handling
locking between them if they share BOs.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
This fixes a race condition between fbcon acceleration and TTM buffer
moves. To reproduce:
- start X
- switch to vt and "while (true); do dmesg; done"
- switch to another vt and "sleep 2 && cat /path/to/debugfs/dri/0/evict_vram"
- switch back to vt running dmesg
We don't make use of this on any other channel yet, they're currently
protected by drm_global_mutex. This will change in the near future.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
A future commit will add locking to the DRM's channel, and there's numerous
problems that come up if we allow printk from an interrupt context to be
accelerated. It seems saner to just disallow it completely.
As a nice side-effect, all the "to accel or not to accel" logic gets moved
out of the chipset-specific code.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
* 'drm-radeon-fusion' of ../drm-radeon-next:
drm/radeon/kms: add Ontario APU ucode loading support
drm/radeon/kms: add Ontario Fusion APU pci ids
drm/radeon/kms: enable MSIs on fusion APUs
drm/radeon/kms: add power table parsing support for Ontario fusion APUs
drm/radeon/kms: refactor atombios power state fetching
drm/radeon/kms: add bo blit support for Ontario fusion APUs
drm/radeon/kms: add thermal sensor support for fusion APUs
drm/radeon/kms: fill in GPU init for AMD Ontario Fusion APUs
drm/radeon/kms: add radeon_asic struct for AMD Ontario fusion APUs
drm/radeon/kms: evergreen.c updates for fusion
drm/radeon/kms: MC setup changes for fusion APUs
drm/radeon/kms: move r7xx/evergreen to its own vram_gtt setup function
drm/radeon/kms: add support for ss overrides on Fusion APUs
drm/radeon/kms: Add support for external encoders on fusion APUs
drm/radeon/kms: atom changes for DCE4.1 devices
drm/radeon/kms: add new family id for AMD Ontario APUs
drm/radeon/kms: upstream power table updates
drm/radeon/kms: upstream atombios.h updates
drm/radeon/kms: upstream ObjectID.h updates
drm/radeon/kms: setup mc chremap properly on r7xx/evergreen
|
|
* 'drm-radeon-next' of ../drm-radeon-next:
drm/radeon/kms: improve pflip precision on r1xx-r4xx
drm/kms/radeon: Use high precision timestamps for pageflip completion events.
drm/kms/radeon: Reorder vblank and pageflip interrupt handling.
drm/radeon/kms: add pageflip ioctl support (v3)
drm/kms/radeon: Add support for precise vblank timestamping.
|
|
Conflicts:
drivers/gpu/drm/i915/intel_drv.h
|
|
This workaround only applies to Ironlake.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
|
|
The pipe is always set to 8BPC, but here we were leaving whatever
previous bits were set by the BIOS in place.
Signed-off-by: Eric Anholt <eric@anholt.net>
Tested-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
|
|
As the tracepoint is now decoupled from when the actual register is
assigned and was never complemented by detailing when the object lost
its fence, it has outlived its limited usefulness. Profiling the actual
stalls is a far more profitable venture anyway.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As the userspace mappings are torn down on every GPU write, we prefer to
track when the buffer is activated (via a fresh i915_gem_fault). This
makes the LRU conceptually simpler. With coherent mappings, the
remaining use-case for set_domain_ioctl is GPU synchronisation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
With this change, every batchbuffer can use all available fences (save
pinned and scanout, of course) without ever stalling the gpu!
In theory. Currently the actual pipelined update of the register is
disabled due to some stability issues. However, just the deferred update
is a significant win.
Based on a series of patches by Daniel Vetter.
The premise is that before every access to a buffer through the GTT we
have to declare whether we need a register or not. If the access is by
the GPU, a pipelined update to the register is made via the ringbuffer,
and we track the last seqno of the batches that access it. If by the
CPU we wait for the last GPU access and update the register (either
to clear or to set it for the current buffer).
One advantage of being able to pipeline changes is that we can defer the
actual updating of the fence register until we first need to access the
object through the GTT, i.e. we can eliminate the stall on set_tiling.
This is important as the userspace bo cache does not track the tiling
status of active buffers which generate frequent stalls on gen3 when
enabling tiling for an already bound buffer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=23752
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc:stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
6xx/7xx was hitting the wrong BUS_CNTL reg and bits.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
* 'intel/drm-intel-fixes' of /ssd/git/drm-next:
Revert "drm/i915/dp: use VBT provided eDP params if available"
drm/i915: Clear pfit registers when not used by any outputs
drm/i915: fix regression due to ba3d8d749b01548b9
|
|
This makes the various rings more consistent by removing the anomalous
handing of the rendering ring execbuffer dispatch.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This reverts commit 869184a675662bddcdf76c5b95665272facff2b8.
This is required for the Sony Vaio Jesse was working on at the time, but
breaks most other eDP machines - machines that were working in earlier
kernels.
Reported-and-tested-by: Dave Airlie <airlied@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31188
Tested-by: Zhao Jian <jian.j.zhao@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
... otherwise the panel-fitter may be left enabled with random settings
and cause unintended filtering (i.e. blurring of native modes on external
panels).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31942
Reported-and-tested-by: Ben Kohler <bkohler@gmail.com>
Tested-by: Ciprian Docan <docan@eden.rutgers.edu>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
In order to correctly report monitor connected status changes, the
previous monitor status must be recorded in the connector->status
value instead of being discarded.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
When setting a new crtc configuration, force the DPMS state of all
connectors to ON. Otherwise, they'll be left at OFF and a future mode set
that disables the specified connector will not turn the connector off.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
... so that upon first use after resume we will reacquire the fence reg.
Reported-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Conflicts:
drivers/gpu/drm/i915/i915_gem.c
|
|
As the error occurred on the current object, it means that its state was
not changed and so it should be excluded from the unwind.
Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
We don't track gpu flush request in any special way. So even with
obj->write_domain == 0, a gpu flush might be outstanding but no
yet executed. Even worse, the latest request might use the object
only for reading. So and unconditional call to object_wait_rendering
is needed for !pipelined.
Hence revert that patch fully and untangle the flushing from the
synchronization again.
Reported-by: Keith Packard <keithp@keithp.com>
Tested-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
* 'intel/drm-intel-fixes' of /ssd/git/drm-next:
drm/i915/sdvo: Always add a 30ms delay to make SDVO TV detection reliable
MAINTAINERS: INTEL DRM DRIVERS list (intel-gfx) is subscribers-only
drm/i915/sdvo: Always fallback to querying the shared DDC line
drm/i915: Handle pagefaults in execbuffer user relocations
drm/i915/sdvo: Only enable HDMI encodings only if the commandset is supported
drm/i915: Only save/restore cursor regs if !KMS
drm/i915: Prevent integer overflow when validating the execbuffer
|
|
The update pending bit has a separate enable bit.
Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This reverts commit d33ef52d9db8a36900dd53f2e32db9a521ace259.
This change seems to expose a bug in the 3D driver tiggered by
certain apps, so revert it to keep userspace working.
Reported-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Besides the minimal improvement in reducing the execbuffer overhead, the
real benefit is clarifying a few routines.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
A number of dragons have been seen lurking within the execbuffer code.
The first step is then to isolate them from the rest and begin to
scrutinise them in depth. Suggested by Daniel Vetter.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Simply remove our accounting of objects inside the aperture, keeping
only track of what is in the aperture and its current usage. This
removes the over-complication of BUGs that were attempting to keep the
accounting correct and also removes the overhead of the accounting on
the hot-paths.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
... to benefit from the compiler checking that we remember to handle
and propagate errors.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
With KMS, we can simply relinquish the fence when we idle the GPU and
reassign it upon first use.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Not employed just yet...
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Commit d09c23de intended to add a 30ms delay to give the ADD time to
detect any TVs connected. However, it used the sdvo->is_tv flag to do so
which is dependent upon the previous detection result and not whether the
output supports TVs.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
|
|
Based on a patch by Daniel Vetter.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Avoid evicting buffers that will be used later in the batch in order to
make room for the initial buffers by pinning all bound buffers in a
single pass before binding (and evicting for) fresh buffer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
On a few devices, like the Mac Mini, the CRT DDC pins are shared between
the analog connector and the digital connector. In this scenario, rely
on the EDID to determine if a digital panel is connected to the digital
connector.
Reported-and-tested-by: Tino Keitel <tino.keitel@tikei.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
... reduce the frequency of checking to further reduce the wakeups and
CPU overhead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
