When converting the mode hdisplay/vdisplay to primary plane src
coordinates we need to take into account the current plane
rotation.
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1444930802-8515-2-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Compared to wrapping the final kref_put with dev->struct_mutex this
allows us to only acquire the offset manager look both in the final
cleanup and in the lookup. Which has the upside that no locks leak out
of the core abstractions. But it means that we need to hold a
temporary reference to the object while checking mmap constraints, to
make sure the object doesn't disappear. Extended the critical region
would have worked too, but would result in more leaky locking.
Also, this is the final bit which required dev->struct_mutex in gem
core, now modern drivers can be completely struct_mutex free!
This needs a new drm_vma_offset_exact_lookup_locked and makes both
drm_vma_offset_exact_lookup and drm_vma_offset_lookup unused.
v2: Don't leak object references in failure paths (David).
v3: Add a comment from Chris explaining how the ordering works, with
the slight adjustment that I dropped any mention of struct_mutex since
with this patch it's now immaterial ot core gem.
Cc: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://mid.gmane.org/1444901623-18918-1-git-send-email-daniel.vetter@ffwll.ch
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
It's duplicating (without using some of the helpers) drm_gem_mmap with
the addition that it can redirect to drm-buf mmap support. But prime
import/export was dropped in
commit 990ed27207
Author: Rob Clark <robdclark@gmail.com>
Date: Thu May 21 11:58:30 2015 -0400
drm/vgem: drop DRIVER_PRIME (v2)
for now, so this is dead code. And since I want to rework the locking
for drm_gem_mmap it seems simpler to de-dupe this code for now and
then start over with the reworked one again, if we want to resurrect
this all indeed.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://mid.gmane.org/1444894601-5200-8-git-send-email-daniel.vetter@ffwll.ch
Acked-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In its original version, drm_framebuffer_init() returned a negative int
if drm_mode_object_get() failed (f453ba0460, "DRM: add mode setting
support").
This was accidentally disabled by commit 4b096ac10d ("drm: revamp
locking around fb creation/destruction"). Thus, drm_framebuffer_init()
pretends success if drm_mode_object_get() failed.
Reinstate the original behaviour. Also fix erroneous kernel-doc of
drm_mode_object_get().
Fixes: 4b096ac10d ("drm: revamp locking around fb creation/
destruction")
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add 3D support to the virtio-gpu.
* 'virtio-gpu-for-drm-next' of git://git.kraxel.org/linux:
virtio-gpu: add page flip support
virtio-gpu: mark as a render gpu
virtio-gpu: add basic prime support
virtio-gpu: add 3d/virgl support
virtio-gpu: don't free things on ttm_bo_init failure
virtio-gpu: wait for cursor updates finish
virtio-gpu: add & use virtio_gpu_queue_fenced_ctrl_buffer
virtio-gpu: add virtio_gpu_queue_ctrl_buffer_locked
Since
commit 131e663bd6
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Jul 9 23:32:33 2015 +0200
drm/gem: rip out drm vma accounting for gem mmaps
there is no need for this any more.
v2: Fixup compile noise spotted by 0-day build.
Link: http://mid.gmane.org/1444894601-5200-9-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Drop unused drm_atomic and fix comment for drm_debug.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add a new debug class for _verbose_ debug message from the vblank code.
That is message we spew out potentially for every vblank interrupt.
Thierry already got annoyed at the spew, and now I managed to lock up
my box with these debug prints (seems serial console + a few debug
prints every vblank aren't a good combination).
Or should I maybe call it DRM_DEBUG_IRQ?
Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
String literals get concatenated just fine on their own,
no need to use '\'.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just one special case (since i915 lost its ums code, yay):
- radeon: Has slots for the old ums ioctls which don't have
DRM_UNLOCKED, but all filled with drm_invalid_op. So ok to drop it
everywhere.
Every other kms driver just has DRM_UNLOCKED for all their ioctls, as
they should.
v2: admgpu happened, include that one too. And i915 lost its UMS
support which means we can change all the i915 ioctls too.
v3: Rebased on top of new vmwgfx DX interface extensions.
v4: Rebase on top of render-node support in exynos.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the prep patches for i915 all kms drivers either have
DRM_UNLOCKED on all their ioctls. Or the ioctl always directly returns
with an invariant return value when in modeset mode. But that's only
the case for i915 and radeon. The drm core ioctls are unfortunately
too much a mess still to dare this.
Follow-up patches will remove DRM_UNLOCKED from all kms drivers to
prove that this is indeed the case.
Also update the documentation.
v2: Really only do this for driver ioctls, spotted by David Herrmann.
And drop spurious whitespace change.
Cc: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With kms all the data getparam looks at is actually invariant, and
certainly not protected by the global kms mutex. With ums all the
setup code is already racy as hell, so this won't make things any
worse.
I've done this change so that all ioctl still used by kms drivers
are marked as DRM_UNLOCKED, besides that we obviously don't need
it any more in kms mode.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add helper function to handle the submission of fenced control requests.
Make sure we initialize the fence while holding the virtqueue lock, so
requests can't be reordered.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Add virtio_gpu_queue_ctrl_buffer_locked function, which does the same as
virtio_gpu_queue_ctrl_buffer but does not take the virtqueue lock. The
caller must hold the lock instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Fixes userspace compile error since list_head is not exported to userspace
headers.
Suggested by Emil Velikov <emil.l.velikov@gmail.com> at
https://lkml.org/lkml/2015/6/3/792
Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fixes userspace compile error:
drm/sis_drm.h:68:19: error: field ‘obj_list’ has incomplete type
struct list_head obj_list;
Suggested by Emil Velikov <emil.l.velikov@gmail.com> at
https://lkml.org/lkml/2015/6/3/792
Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This series:
* adds support for interlaced video modes to the ipu-v3 driver
and dw_hdmi bridge.
* reworks the dw_hdmi connector enable/disable support, to ensure that
when DRM disables the output, it stays disabled irrespective of the
hotplug state.
* adds support for connector forcing, so we can force the hotplug state
for this connector.
* adds the ALSA AHB audio driver to the bridge: Iwai has acked the
audio driver.
* a few fixes to the ACR calculations to allow more modes to work with
audio on iMX6.
Fabio has independently tested this series, so all patches here carry
his tested-by tag.
* 'drm-dwhdmi-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
drm: bridge/dw_hdmi: replace CTS calculation for the ACR
drm: bridge/dw_hdmi: remove ratio support from ACR code
drm: bridge/dw_hdmi: adjust pixel clock values in N calculation
drm: bridge/dw_hdmi: avoid being recursive in N calculation
drm: bridge/dw_hdmi-ahb-audio: allow larger buffer sizes
drm: bridge/dw_hdmi-ahb-audio: basic support for multi-channel PCM audio
drm: bridge/dw_hdmi-ahb-audio: parse ELD from HDMI driver
drm: bridge/dw_hdmi-ahb-audio: add audio driver
drm: bridge/dw_hdmi: improve HDMI enable/disable handling
drm: bridge/dw_hdmi: add connector mode forcing
drm: bridge/dw_hdmi: add support for interlaced video modes
gpu: imx: fix support for interlaced modes
gpu: imx: simplify sync polarity setting
Another round of drm-misc. Unfortunately the DRM_UNLOCKED removal for
DRIVER_MODESET isn't complete yet for lack of review on 1-2 patches.
Otherwise just various stuff all over.
* tag 'topic/drm-misc-2015-10-08' of git://anongit.freedesktop.org/drm-intel:
drm: Stop using drm_vblank_count() as the hw frame counter
drm/irq: Use unsigned int pipe in public API
drm: Use DRM_ROTATE_MASK and DRM_REFLECT_MASK
drm: Add DRM_ROTATE_MASK and DRM_REFLECT_MASK
vga_switcheroo: Add missing locking
vgaarb: use kzalloc in vga_arbiter_add_pci_device()
drm: Don't zero vblank timestamps from the irq handler
drm: Hack around CONFIG_AGP=m build failures
drm/i915: Remove setparam ioctl
drm: Remove dummy agp ioctl wrappers
drm/vmwgfx: Stop checking for DRM_UNLOCKED
drm/drm_ioctl.c: kerneldoc
drm: Define a drm_invalid_op ioctl implementation
drm: Remove __OS_HAS_AGP
drm/doc: Update docs about device instance setup
drm-intel-next-2015-09-28:
- fastboot by default for some systems (Maarten Lankhorts)
- piles of workarounds for bxt and skl
- more fbc work from Paulo
- fix hdmi hotplug detection (Sonika)
- first few patches from Ville to parametrize register macros, prep work for
typesafe mmio functions
- prep work for nv12 rotation (Tvrtko Ursulin)
- various other bugfixes and improvements all over
I have another backmerge here since things became messy and I didn't
realize you resolved some of them already (usually you complain when
there's a conflict ...).
For 4.4 I plan one more feature round after this and then that's it.
* tag 'drm-intel-next-2015-09-28-merged' of git://anongit.freedesktop.org/drm-intel: (80 commits)
drm/i915: Update DRIVER_DATE to 20150928
drm/i915: fix task reference leak in i915_debugfs.c
drm/i915: Defer adding preallocated stolen objects to the VM list
drm/i915: Remove extraneous request cancel.
drm/i915: Enable querying offset of UV plane with intel_plane_obj_offset
drm/i915: Support NV12 in rotated GGTT mapping
drm/i915: Support appending to the rotated pages mapping
drm/i915: Support planar formats in tile height calculations
drm/i915/bxt: Update revision id for BXT C0
drm/i915: Parametrize CSR_PROGRAM registers
drm/i915: Parametrize DDI_BUF_TRANS registers
drm/i915: Parametrize TV luma/chroma filter registers
drm/i915: Replace raw numbers with the approproate register name in ILK turbo code
drm/i915: Parametrize ILK turbo registers
drm/i915: Parametrize FBC_TAG registers
drm/i915: Parametrize GEN7_GT_SCRATCH and GEN7_LRA_LIMITS
drm/i915: Parametrize LRC registers
drm/i915: Don't pass sdvo_reg to intel_sdvo_select_{ddc, i2c}_bus()
drm/i915: Ignore "digital output" and "not HDMI output" bits for eDP detection
drm/i915: Make sure we don't detect eDP on g4x
...
This is the first radeon and amdgpu pull for drm-next. Highlights include:
- Efficiency improvements to the CS checker for pre-SI asics
- Cursor fixes ported from radeon to amdgpu
- Enable GPU scheduler by default
- Add a bunch of GPUVM debugging options
- Add support for some new atombios opcodes
- Misc cleanups and fixes
* 'drm-next-4.4' of git://people.freedesktop.org/~agd5f/linux: (42 commits)
drm/amdgpu: fix lockup when clean pending fences
drm/amdgpu: add timer to fence to detect scheduler lockup
drm/amdgpu: add VM CS mapping trace point
drm/amdgpu: add option to clear VM page tables after every submit
drm/amdgpu: add option to stop on VM fault
drm/amdgpu: only print meaningful VM faults
drm/amdgpu: also trace already allocated VMIDs
drm/amdgpu: Drop unnecessary #include <linux/vga_switcheroo.h>
drm/radeon: Drop unnecessary #include <linux/vga_switcheroo.h>
drm/amdgpu: clean up pageflip interrupt handling
drm/amdgpu: rework sdma structures
drm/amdgpu: unpin cursor BOs on suspend and pin them again on resume
drm/amdgpu/dce8: Fold set_cursor() into show_cursor()
drm/amdgpu/dce8: Clean up reference counting and pinning of the cursor BOs
drm/amdgpu/dce8: Move hotspot handling out of set_cursor
drm/amdgpu/dce8: Re-show the cursor after a modeset (v2)
drm/amdgpu/dce8: Use cursor_set2 hook for enabling / disabling the HW cursor
drm/amdgpu/dce11: Fold set_cursor() into show_cursor()
drm/amdgpu/dce11: Clean up reference counting and pinning of the cursor BOs
drm/amdgpu/dce11: Move hotspot handling out of set_cursor
...
* removes the now unused DRM slave encoder support, which all users have
migrated away from, allowing us to simplify the code.
* ensure all pending interrupts are processed together, rather than
needing the handler to be re-entered each time.
* use more HDMI helpers to setup the info frames.
* fix EDID read handling by ensuring that we always wait the specified time
before attempting to read the EDID, no matter where the EDID read request
came from.
* 'drm-tda998x-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
drm/i2c: tda998x: clean up after struct tda998x_priv2 removal
drm/i2c: tda998x: kill struct tda998x_priv2
drm/i2c: tda998x: move connector into struct tda998x_priv
drm/i2c: tda998x: remove encoder pointer
drm/i2c: tda998x: remove DRM slave encoder support
drm/i2c: tda998x: use more HDMI helpers
drm/i2c: tda998x: handle all outstanding interrupts
drm/i2c: tda998x: convert to u8/u16/u32 types
drm/i2c: tda998x: re-implement "Fix EDID read timeout on HDMI connect"
drm/i2c: tda998x: report whether we actually handled the IRQ
drm/i2c: tda998x: remove useless NULL checks
* remove support for the non-component support from the Armada DRM driver,
switching it to component-only mode.
* create a "armada plane" to allow the primary and overlay planes to share
some code.
* increase efficiency by using inherently atomic operations, rather than
spinlocking to achieve atomicity. Eg, if we want to exchange a value,
using xchg().
* increase PM savings by stopping the external pixel clock when we're in
DPMS mode.
* 'drm-armada-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
drm/armada: move frame wait wakeup into plane work
drm/armada: convert overlay plane vbl worker to a armada plane worker
drm/armada: move CRTC flip work to primary plane work
drm/armada: move frame wait into armada_frame
drm/armada: move the locking for armada_drm_vbl_event_remove()
drm/armada: move the update of dplane->ctrl0 out of spinlock
drm/armada: move write to dma_ctrl0 to armada_drm_crtc_plane_disable()
drm/armada: provide a common helper to disable a plane
drm/armada: allocate primary plane ourselves
drm/armada: add primary plane creation
drm/armada: introduce generic armada_plane struct
drm/armada: update armada overlay to use drm_universal_plane_init()
drm/armada: use xchg() to atomically update dplane->old_fb
drm/armada: factor out retirement of old fb
drm/armada: rename overlay identifiers
drm/armada: redo locking and atomics for armada_drm_crtc_complete_frame_work()
drm/armada: disable CRTC clock during DPMS
drm/armada: use drm_plane_force_disable() to disable the overlay plane
drm/armada: move vbl code into armada_crtc
drm/armada: remove non-component support
The first lockup fence will lock the fence list of scheduler.
Then cancel the delayed workqueues for all clean pending fences
without waiting the workqueues to finish.
Change-Id: I9bec826de1aa49d587b0662f3fb4a95333979429
Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Change-Id: I67e987db0efdca28faa80b332b75571192130d33
Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: David Zhou <david1.zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Output all VM mappings a command submission uses.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This makes it much easier to find when userspace misses to send some buffers.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This was added to two radeon files even though they don't use any
vga_switcheroo symbols, the amdgpu fork inherited them:
Added to amdgpu_acpi.c by commit d7a2952f1a ("drm/radeon: Add
support for the ATIF ACPI method to the radeon driver").
Added to amdgpu_bios.c by commit 6a9ee8af34 ("vga_switcheroo:
initial implementation (v15)").
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This was added to three files even though they don't use any
vga_switcheroo symbols:
Added to radeon_acpi.c by commit d7a2952f1a ("drm/radeon: Add
support for the ATIF ACPI method to the radeon driver").
Added to radeon_asic.c by commit 0a10c85129 ("drm/radeon: create
radeon_asic.c").
Added to radeon_bios.c by commit 6a9ee8af34 ("vga_switcheroo:
initial implementation (v15)").
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Check to make sure we aren't touching a non-existent
display controller and simplify the code.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Rework the sdma structures in the driver to
consolidate all of the sdma info into a single
structure and allow for asics that may have
different numbers of sdma instances.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Everything is evicted from VRAM before suspend, so we need to make
sure all BOs are unpinned and re-pinned after resume. Fixes broken
mouse cursor after resume introduced by commit b9729b17.
Port of radeon commit:
f3cbb17bcf
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Take a GEM reference for and pin the new cursor BO, unpin and drop the
GEM reference for the old cursor BO in dce8 crtc_cursor_set2, and use
amdgpu_crtc->cursor_addr in dce8 set_cursor.
This fixes dce8 cursor_reset accidentally incrementing the cursor BO
pin count, and cleans up the code a little.
Port of radeon commit:
cd404af0c9
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
It's only needed in dce8 crtc_cursor_set2.
Port of radeon commit:
2e007e611b
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Setting a mode seems to clear the cursor registers, so we need to
re-program them to make sure the cursor is visible.
Port of radeon commit:
6d3759fac6
v2: change radeon reference in error message
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The cursor_set2 hook provides the cursor hotspot position within the
cursor image. When the hotspot position changes, we can adjust the cursor
position such that the hotspot doesn't move on the screen. This prevents
the cursor from appearing to intermittently jump around on the screen
when the position of the hotspot within the cursor image changes.
Port of radeon commits:
78b1a6010b3feba08d79
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Take a GEM reference for and pin the new cursor BO, unpin and drop the
GEM reference for the old cursor BO in dce11 crtc_cursor_set2, and use
amdgpu_crtc->cursor_addr in dce11 set_cursor.
This fixes dce11 cursor_reset accidentally incrementing the cursor BO
pin count, and cleans up the code a little.
Port of radeon commit:
cd404af0c9
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
It's only needed in dce11 crtc_cursor_set2.
Port of radeon commit:
2e007e611b
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Setting a mode seems to clear the cursor registers, so we need to
re-program them to make sure the cursor is visible.
Port of radeon commit:
6d3759fac6
v2: change radeon reference in error output
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The cursor_set2 hook provides the cursor hotspot position within the
cursor image. When the hotspot position changes, we can adjust the cursor
position such that the hotspot doesn't move on the screen. This prevents
the cursor from appearing to intermittently jump around on the screen
when the position of the hotspot within the cursor image changes.
Port of radeon commits:
78b1a6010b3feba08d79
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Take a GEM reference for and pin the new cursor BO, unpin and drop the
GEM reference for the old cursor BO in dce10 crtc_cursor_set2, and use
amdgpu_crtc->cursor_addr in dce10 set_cursor.
This fixes dce10 cursor_reset accidentally incrementing the cursor BO
pin count, and cleans up the code a little.
Port of radeon commit:
cd404af0c9
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
It's only needed in dce10 crtc_cursor_set2.
Port of radeon commit:
2e007e611b
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Setting a mode seems to clear the cursor registers, so we need to
re-program them to make sure the cursor is visible.
Port of radeon commit:
6d3759fac6
v2: change radeon reference in error message
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The cursor_set2 hook provides the cursor hotspot position within the
cursor image. When the hotspot position changes, we can adjust the cursor
position such that the hotspot doesn't move on the screen. This prevents
the cursor from appearing to intermittently jump around on the screen
when the position of the hotspot within the cursor image changes.
Port of radeon commits:
78b1a6010b3feba08d79
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Better precision than the regular div opcode.
v2: drop 64 bit divide
v3: fix op handling. This actually is a 64 bit divide.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Better precision than the regular mul opcode.
v2: handle big endian properly.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Nothing too crazy here, a couple of regression fixes + runpm/fbcon
race fix.
* 'linux-4.3' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nouveau/bios: fix OF loading
drm/nouveau/fbcon: take runpm reference when userspace has an open fd
drm/nouveau/nouveau: Disable AGP for SiS 761
drm/nouveau/display: allow up to 16k width/height for fermi+
drm/nouveau/bios: translate devinit pri/sec i2c bus to internal identifiers
Currently OF bios load fails for a few reasons:
- checksum failure
- bios size too small
- no PCIR header
- bios length not a multiple of 4
In this change, we resolve all of the above by ignoring any checksum
failures (since OF VBIOS tends not to have a checksum), and faking the
PCIR data when loading from OF.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We need to do this in order to prevent accesses to the device while it's
powered down. Userspace may have an mmap of the fb, and there's no good
way (that I know of) to prevent it from touching the device otherwise.
This fixes some nasty races between runpm and plymouth on some systems,
which result in the GPU getting very upset and hanging the boot.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org
SiS 761 chipset does not support AGP cards but has AGP capability (for
the onboard video). At least PC Chips A31G board using this chipset has
an AGP-like AGPro slot that's wired to the PCI bus. Enabling AGP will
fail (GPU lockup and software fbcon, X11 hangs).
Add support for matching just the host bridge in nvkm_device_agp_quirks
and add entry for SiS 761 with mode 0 (AGP disabled).
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Given the TDMS clock, audio sample rate, and the N parameter, we can
calculate the CTS value for the audio clock regenerator (ACR) using the
following calculation given in the HDMI specification:
CTS = ftdms * N / (128 * fs)
The specification says that the CTS value is an average value, which is
true if the source hardware measures it. Where source hardware needs it
to be programmed, it is particularly difficult to alternate between two
values correctly to ensure that we achieve a correct "average"
fractional value at the sink.
Also, there's the problem that our "ftdms" is not a fully accurate
value; it is rounded to a kHz value. This introduces an unnecessary
(and harmless) fractional value into the above equation for combinations
like 148.5MHz/1.001 for 44100Hz - we still calculate the correct CTS
value.
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
We never set the ratio for CTS/N calculation for the audio clock
regenerator (ACR) to anything but 100, so this adds pointless
complexity. Should we support pixel repetition, we should update the
CTS/N calculation code to use those parameters or the actual TMDS clock
rate instead of a ratio.
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Adjust the pixel clock values in the N calculation to match the more
accurate clock values we're given by the DRM subsystem, which are the
kHz pixel rate, with any fractional kHz rounded down in the case of
the non-240, non-480 line modes, or rounded up for the others. So,
25.20 / 1.001 => 25175
27.00 * 1.001 => 27027
74.25 / 1.001 => 74176
148.50 / 1.001 => 148352
DRM derives these rates from the EDID CEA mode identifiers, which are
looked up in the tables in drivers/gpu/drm/drm_edid.c. The values on
the right are the clock values found in these tables, and are
currently expected to be passed to the HDMI driver unchanged.
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
There's no need to be recursive when computing the N value for the ACR
packet - we can instead calculate the multiplier prior to our switch()
based lookup, and multiply the N value appropriately afterwards.
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
With multichannel audio, we need to allow larger buffer sizes to avoid
XRUNs during playback. Push the buffer size up to 1024K, but as we
maintain two buffers, ensure that the vmalloc buffer does not exceed
the userspace buffer size.
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add basic support for multi-channel PCM audio, with fixed speaker
mappings. This has been tested with an AV receiver, and appears to
work for low sample rates up to 8 channels.
It should be noted that multi-channel mode using the IEC958 alsa-lib
conversion plugin requires correct AES channel status for the AV
receiver to recognise the stream, especially the sample rate bits.
"Not identified" does not work there.
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Parse the ELD (EDID like data) stored from the HDMI driver to restrict
the sample rates and channels which are available to ALSA. This causes
the ALSA device to reflect the capabilities of the overall audio path,
not just what is supported at the HDMI source interface level.
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add ALSA based HDMI AHB audio driver for dw_hdmi. The only buffer
format supported by the hardware is its own special IEC958 based format,
which is not compatible with any ALSA format. To avoid doing too much
data manipulation within the driver, we support only ALSAs IEC958 LE and
24-bit PCM formats for 2 to 6 channels, which we convert to its hardware
format.
A more desirable solution would be to have this conversion in userspace,
but ALSA does not appear to allow such transformations outside of
libasound itself.
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
It's been reported that the atomic watermark series triggers some
regressions on SKL, which we haven't been able to track down yet. Let's
temporarily revert these patches while we track down the root cause.
This commit squashes the reverts of:
76305b1 drm/i915: Calculate watermark configuration during atomic check (v2)
a4611e4 drm/i915: Don't set plane visible during HW readout if CRTC is off
a28170f drm/i915: Calculate ILK-style watermarks during atomic check (v3)
de4a9f8 drm/i915: Calculate pipe watermarks into CRTC state (v3)
de165e0 drm/i915: Refactor ilk_update_wm (v3)
Reference: http://lists.freedesktop.org/archives/intel-gfx/2015-October/077190.html
Cc: "Zanoni, Paulo R" <paulo.r.zanoni@intel.com>
Cc: "Vetter, Daniel" <daniel.vetter@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When submitting semaphores in execlist mode the hang checker crashes in this
function because it is only runnable in ring submission mode. The reason this
is of particular interest to the TDR patch series is because we use semaphores
as a mean to induce hangs during testing (which is the recommended way to
induce hangs for gen8+). It's not clear how this is supposed to work in
execlist mode since:
1. This function requires a ring buffer.
2. Retrieving a ring buffer in execlist mode requires us to retrieve the
corresponding context, which we get from a request.
3. Retieving a request from the hang checker is not straight-forward since that
requires us to grab the struct_mutex in order to synchronize against the
request retirement thread.
4. Grabbing the struct_mutex from the hang checker is nothing that we will do
since that puts us at risk of deadlock since a hung thread might be holding the
struct_mutex already.
Therefore it's not obvious how we're supposed to deal with this. For now, we're
doing an early exit from this function, which avoids any kernel panic situation
when running our own internal TDR ULT.
* v2: (Chris Wilson)
Turned the execlist mode check into a ringbuffer NULL check to make it more
submission mode agnostic and less of a layering violation.
Signed-off-by: Tomas Elf <tomas.elf@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit e9f24d5fb7
Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Date: Mon Oct 5 13:26:36 2015 +0100
drm/i915: Clean up associated VMAs on context destruction
Introduced a wrong assumption that all contexts have a ppgtt
instance. This is not true when full PPGTT is not active so
remove the WARN_ON_ONCE from the context cleanup code.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There isn't an explicit stolen memory base register on gen2.
Some old comment in the i915 code suggests we should get it via
max_low_pfn_mapped, but that's clearly a bad idea on my MGM.
The e820 map in said machine looks like this:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
[ 0.000000] BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
[ 0.000000] BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fff00000-0x00000000ffffffff] reserved
That makes max_low_pfn_mapped = 1f6f0000, so assuming our stolen memory
would start there would place it on top of some ACPI memory regions.
So not a good idea as already stated.
The 9MB region after the ACPI regions at 0x1f700000 however looks
promising given that the macine reports the stolen memory size to be
8MB. Looking at the PGTBL_CTL register, the GTT entries are at offset
0x1fee00000, and given that the GTT entries occupy 128KB, it looks like
the stolen memory could start at 0x1f700000 and the GTT entries would
occupy the last 128KB of the stolen memory.
After some more digging through chipset documentation, I've determined
the BIOS first allocates space for something called TSEG (something to
do with SMM) from the top of memory, and then it allocates the graphics
stolen memory below that. Accordind to the chipset documentation TSEG
has a fixed size of 1MB on 855. So that explains the top 1MB in the
e820 region. And it also confirms that the GTT entries are in fact at
the end of the the stolen memory region.
Derive the stolen memory base address on gen2 the same as the BIOS does
(TOM-TSEG_SIZE-stolen_size). There are a few differences between the
registers on various gen2 chipsets, so a few different codepaths are
required.
865G is again bit more special since it seems to support enough memory
to hit 4GB address space issues. This means the PCI allocations will
also affect the location of the stolen memory. Fortunately there
appears to be the TOUD register which may give us the correct answer
directly. But the chipset docs are a bit unclear, so I'm not 100%
sure that the graphics stolen memory is always the last thing the
BIOS steals. Someone would need to verify it on a real system.
I tested this on the my 830 and 855 machines, and so far everything
looks peachy.
v2: Rewrite to use the TOM-TSEG_SIZE-stolen_size and TOUD methods
v3: Fix TSEG size for 830
v4: Add missing 'else' (Chris)
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
According to my experiments (and later confirmation from the hardware
developers), the maximum sizes mentioned in the specification delimit
how far in the buffer the hardware tracking can go. And the hardware
calculates the size based on the plane address we provide - and the
provided plane address might not be the real x:0,y:0 point due to the
compute_page_offset() function.
On platforms that do the x/y offset adjustment trick it will be really
hard to reproduce a bug, but on the current SKL we can reproduce the
bug with igt/kms_frontbuffer_tracking/fbc-farfromfence. With this
patch, we'll go from "CRC assertion failure" to "FBC unexpectedly
disabled", which is still a failure on the test suite but is not a
perceived user bug - you will just not save as much power as you could
if FBC is disabled.
v2, rewrite patch after clarification from the Hadware guys:
- Rename function so it's clear what the check is for.
- Use the new intel_fbc_get_plane_source_sizes() function in order
to get the proper sizes as seen by FBC.
v3:
- Rebase after the s/sizes/size/ on the previous patch.
- Adjust comment wording (Ville).
- s/used_/effective_/ (Ville).
Testcase: igt/kms_frontbuffer_tracking/fbc-farfromfence (SKL)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We were considering the whole framebuffer height, but the spec says we
should only consider the active display height size. There were still
some unclear questions based on the spec, but the hardware guys
clarified them for us. According to them:
- CFB size = CFB stride * Number of lines FBC writes to CFB
- CFB stride = plane stride / compression limit
- Number of lines FBC writes to CFB = MIN(plane source height, maximum
number of lines FBC writes to CFB)
- Plane source height =
- pipe source height (PIPE_SRCSZ register) (before SKL)
- plane size register height (PLANE_SIZE register) (SKL+)
- Maximum number of lines FBC writes to CFB =
- plane source height (before HSW)
- 2048 (HSW+)
For the plane source height, I could just have made our code do
I915_READ() in order to be more future proof, but since it's not cool
to do register reads I decided to just recalculate the values we use
when we actually write to those registers.
With this patch, depending on your machine configuration, a lot of the
kms_frontbuffer_tracking subtests that used to result in a SKIP due to
not enough stolen memory still start resulting in a PASS.
v2: Use the clipped src size instead of pipe_src_h (Ville).
v3: Use the appropriate information provided by the hardware guys.
v4: Bikesheds: s/sizes/size/, s/fb_cpp/cpp/ (Ville).
v5: - Don't use crtc->config->pipe_src_x for BDW- (Ville).
- Fix the register name written in the comment.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The comment suggests the check was there for some non-fully-atomic
case, and I couldn't find a case where we wouldn't correctly
initialize plane_state, so remove the check.
Let's leave a WARN there just in case.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Technology has evolved and now we have eDP panels with 3200x1800
resolution. In the meantime, the BIOS guys didn't change the default
32mb for stolen memory. On top of that, we can't assume our users will
be able to increase the default stolen memory size to more than 32mb -
I'm not even sure all BIOSes allow that.
So just the fbcon buffer alone eats 22mb of my stolen memroy, and due
to the BDW/SKL restriction of not using the last 8mb of stolen memory,
all that's left for FBC is 2mb! Since fbcon is not the coolest feature
ever, I think it's better to save our precious stolen resource to FBC
and the other guys.
On the other hand, we really want to use as much stolen memory as
possible, since on some older systems the stolen memory may be a
considerable percentage of the total available memory.
This patch tries to achieve a little balance using a simple heuristic:
if the fbcon wants more than half of the available stolen memory,
don't use stolen memory in order to leave some for FBC and the other
features.
The long term plan should be to implement a way to set priorities for
stolen memory allocation and then evict low priority users when the
high priority ones need the memory. While we still don't have that,
let's try to make FBC usable with the simple solution.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With atomic drivers we need to make sure that (at least in general)
property reads hold the right locks. But the legacy dpms property is
special and can be read locklessly. Since userspace loves to just
randomly look at that all the time (like with "status") do that.
To make it clear that we play tricks use the READ_ONCE compiler
barrier (and also for paranoia).
Note that there's not really anything bad going on since even with the
new atomic paths we eventually end up not chasing any pointers (and
hence possibly freed memory and other fun stuff). The locking WARNING
has been added in
commit 88a48e297b
Author: Rob Clark <robdclark@gmail.com>
Date: Thu Dec 18 16:01:50 2014 -0500
drm: add atomic properties
but since drivers are converting not everyone will have seen this from
the start.
Jens reported this and submitted a patch to just grab the
mode_config.connection_mutex, but we can do a bit better.
v2: Remove unused variables I failed to git add for real.
Reference: http://mid.gmane.org/20150928194822.GA3930@kernel.dk
Reported-by: Jens Axboe <axboe@fb.com>
Tested-by: Jens Axboe <axboe@fb.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
radeon and amdgpu fixes for 4.3. Highlights:
- Move pm sysfs setup later in the driver init process to avoid
problems with laptop scripts attempting to change pm settings
before the driver has finished setting up the pm hardware.
- Fix console restore if a drm app (e.g. X) is forcibly killed
- Flag iceland support as experimental for now
- Misc bug fixes
* 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu: fix memory leak in amdgpu_vm_update_page_directory
drm/amdgpu: fix 32-bit compiler warning
drm/amdgpu: flag iceland as experimental
drm/amdgpu: check before checking pci bridge registers
drm/amdgpu: fix num_crtc on CZ
drm/amdgpu: restore the fbdev mode in lastclose
drm/radeon: restore the fbdev mode in lastclose
drm/radeon: add quirk for ASUS R7 370
drm/amdgpu: add pm sysfs files late
drm/radeon: add pm sysfs files late
This reverts commit 5d250b0591.
It results on a deadlock on platforms where we need to (at least
partially) re-init hpd interrupts from power domain code, since
->hot_plug might again grab a power well reference (to do edid/dp_aux
transactions. At least chv is affected.
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
References: http://mid.gmane.org/20151008133548.GX26517@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Use goto to handle the error path to avoid duplicating the same code. In
the error path intel_dig_port is the last one to be released as it was
the first one to be allocated and ideally the error path should be the
reverse of the execution path.
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There is a typo in the function i915_handle_error()
kernel-doc and the word register is spelled wrongly.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add the dev parameter for the functions i915_enable_asle_pipestat() and
i915_reset_and_wakeup() to the kernel-doc to fix the following warnings:
.//drivers/gpu/drm/i915/i915_irq.c:586: warning: No description found for parameter 'dev'
.//drivers/gpu/drm/i915/i915_irq.c:2400: warning: No description found for parameter 'dev'
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These are buggy on some asics and not really used anymore
now that the GPU schedular is enabled.
Change-Id: I67182b409d64de308392a15d1a0a15018071dc0b
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
need to decrease visible vram usage by default.
Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: monk.liu <monk.liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Calculate the driver state in sw_init and program the
registers in hw init.
Acked-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
intel_rcs_ctx_init() emits all workaround register writes on the list
to the ring, in addition to calling i915_gem_render_state_init(). The
workaround list is currently empty on Gen6-7 so this shouldn't cause
any functional changes.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's not an error for the workaround list to be empty if no
workarounds are needed. This will avoid spamming the logs
unnecessarily on Gen6 after the workaround list is hooked up on
pre-Gen8 hardware by the following commits.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
