This is the recommended setting from the hw team for newer
versions of the firmware.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
In
commit bbb1e52402
Author: Rob Clark <robdclark@gmail.com>
Date: Tue Aug 25 15:35:58 2015 -0400
drm/fb-helper: atomic restore_fbdev_mode()..
we've forgotten to do the plane->old_fb refcount dance for
pan_display_atomic, which can result in refcount leaks if the current
configuration is not from fbcon. Which apparently can happen when
vt-switching - fbcon does a pan first before a set_par.
OCD-align function parameters while at it.
v2: Actually git add the OCD.
Cc: Rob Clark <robdclark@gmail.com>
Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92483
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445015490-27682-1-git-send-email-daniel.vetter@ffwll.ch
Tested-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The point behind standardizing properties into core drm state
structures is also that internal code looks prettiers. Take advantage
of that and set rotation directly in the fbdev atomic code.
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445012594-25988-1-git-send-email-daniel.vetter@ffwll.ch
Acked-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In Linux 4.3-rc5, there is an error case in drm_dp_get_branch_device
that returns without releasing mgr->lock, resulting a spew of kernel
messages about a kernel work function possibly having leaked a mutex
and presumably more serious adverse consequences later. This patch
changes the error to "goto out" to unlock the mutex before returning.
Signed-off-by: Adam J. Richter <adam_richter2004@yahoo.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of relying on the old crtc-{x,y,mode} gunk, dig out the primary
plane coordinates from the plane state when checking them against the
new framebuffer during page flip.
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-5-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>
On atomic drivers we can dig out the primary plane rotation from the
plane state instead of looking at the legacy crtc->invert_dimensions
flag. The flag is not set by anyone except omapdrm, and it would be
racy to set it the same way in the atomic helpers.
v2: Kill crtc->invert_dimensions totally since omap is state based
already and no one else ever used it (Matt)
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445009919-22746-1-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>
Pull the plane src coordinate checks into a separate function so that we
can share them for the legacy and new stuff.
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-3-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>
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
...
We still had one lingering RMW in ivb_sprite_disable(), all the other
RMWs were killed off from the sprite code some time ago. Kill the
straggler too.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This removes the last depency of radeon for dev->struct_mutex!
Also the locking scheme for hyperz/cmask owners seems a bit unsound,
there's no protection in the preclose handler (and that never did hold
dev->struct_mutex while being called). So grab the same lock there,
too.
There's also all the checks in the cs checker, but since the overall
design seems to never stall for the previous owner I figured it's ok
if I leave this racy. It was racy even before I touched it after all
too.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This was accidentally lost in
commit 75d04a3773
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date: Tue Apr 28 17:56:17 2015 +0300
drm/i915/gtt: Allocate va range only if vma is not bound
While at it implement an improved version suggested by Chris which
avoids the double-bind irrespective of what type of bind is done
first.
Note that this exact bug was already addressed in
commit d0e30adc42
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Jul 29 20:02:48 2015 +0100
drm/i915: Mark PIN_USER binding as GLOBAL_BIND without the aliasing ppgtt
but the problem is still that originally in
commit 0875546c53
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Apr 20 09:04:05 2015 -0700
drm/i915: Fix up the vma aliasing ppgtt binding
if forgotten to take into account there case where we have a
GLOBAL_BIND before a LOCAL_BIND. This patch here fixes that.
v2: Pimp commit message and revert the partial fix.
v3: Split into two functions to specialize on aliasing_ppgtt y/n.
v4: WARN_ON for paranoia in the init sequence, since the ggtt probe
and aliasing ppgtt setup are far apart.
v5: Style nits.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://mid.gmane.org/1444911781-32607-1-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since SKL has universal planes, we should configure the sprite planes
and the primary plane the same. For the primary plane we do enable
the pipe gamma on the plane so do the same for the non-primary planes.
Without this, the pipe CRC values will be different for something
displayed on the primary plane and something displayed on a sprite
plane when the ARGB8888 format is used.
Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Extend this to SKL and BXT as it's needed for these platforms as well.
v2: Change if condition to HAS_DDI() instead of listing each platform
Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* 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>
Some registers are, naturally, lost in gpu reset/suspend cycle.
And some registers, for example in display domain, are not subject
to gpu reset so they retain their contents.
As hang recovery triggers a reset, recoverable gpu hang can currently
flush out essential workarounds and cause havoc later on.
When register GEN8_GARBNTL is missing the WaEnableGapsTsvCreditFix:skl,
it can cause random system hangs [1]. This workaround was added in:
commit 245d96670d ("drm/i915:skl: Add WaEnableGapsTsvCreditFix")
But another set of system hangs were observed and the failure pattern
indicated that there was random gpu hang preceding the system hang [2].
This lead to the realization that we lose this workaround and BDW_SCRATCH1
on reset.
Add these workarounds setup in display init to skl/bxt ring init
where LRI workarounds are also setup. This way their setup is not
dependent on display side init.
References: [1] https://bugs.freedesktop.org/show_bug.cgi?id=90854
References: [2] https://bugs.freedesktop.org/show_bug.cgi?id=92315
Reported-by: Tomi Sarvela <tomix.p.sarvela@intel.com>
Cc: Tomi Sarvela <tomix.p.sarvela@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Tomi Sarvela <tomix.p.sarvela@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since the remove of the pin-ioctl, we only care about not changing the
cache level on buffers pinned to the hardware as indicated by
obj->pin_display. By knowing that only objects pinned to the hardware
will have an elevated vma->pin_count, so we can coallesce many of the
linear walks over the obj->vma_list.
v2: Try and retrospectively add comments explaining the steps in
rebinding the active VMA.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is a squash of the following commits:
Revert "drm/i915: Drop intel_update_sprite_watermarks"
This reverts commit 47c99438b5.
Revert "drm/i915/ivb: Move WaCxSRDisabledForSpriteScaling w/a to atomic check"
This reverts commit 7809e5ae35.
Revert "drm/i915/skl: Eliminate usage of pipe_wm_parameters from SKL-style WM (v3)"
This reverts commit 3a05f5e2e7.
With these reverts, SKL finally stops failing every single FBC test
with FIFO underrun error messages. After some brief testing, it also
seems that this commit prevents the machine from completely freezing
when we run igt/kms_fbc_crc (see fd.o #92355).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92355
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Keep single 'lvds_reg' and 'lvds' variable around in
intel_lvds_init(), and read it just once at the start.
Also intel_lvds_get_config() doesn't need to figure out which reg to use
since it can just consult lvds_encoder->reg.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Drop some useless 'reg' variables when we only use them once.
v2: A few more, including a few variable moves
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Parametrize the SWF registers. This also fixes the register offsets,
which were mostly garbage in the old defines.
Also save/restore only as many SWF registers that each platform has.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The PIPE_FRMCOUNT_GM45 and PIPE_FLIPCOUNT_GM45 names have bothered me
for a long time. The work equally well for ELK and onwards, so let's
s/GM45/G4X/.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A few register mask defines were missing the '0x' from hex numbers. Or
at least I assume those were meant to be hex numbers. Put the '0x' in
place.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Always put parens around macro argument evaluations.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Keep using the same registers (PCH_*) instead of accidentally
starting to use the other ones (BXT_*)2) (Jesse)
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We should serialise access to the intel_crtc->unpin_work through the
dev->event_lock spinlock. It should not be possible for it to disappear
without severe error as the mmio_flip worker has not tagged the
unpin_work pending flip-completion. Similarly if the error exists, just
taking the unpin_work whilst holding the spinlock and then using it
unserialised just masks the race. (It is supposed to be valid as the
unpin_work exists until the flip completion interrupt which should not
fire until we flush the mmio writes to update the display base which is
the last time we access the unpin_work from the kthread.)
References: https://bugs.freedesktop.org/show_bug.cgi?id=92335
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly
map it with memremap rather than the implied cache setting of
acpi_os_ioremap().
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Commit 599bbb9de0 ("drm/i915: i915 cannot provide switcher services.")
removed all remaining vga_switcheroo symbols from intel_acpi.c but left
the include. Drop it.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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>
In
commit 8f0e2b9d95
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Dec 2 16:19:07 2014 +0100
drm/i915: Move golden context init into ->init_context
I've shuffled around per-ctx init code a bit for legacy contexts but
accidentally dropped the render state init call on gen6/7. Resurrect
it.
Reported-by: Francisco Jerez <currojerez@riseup.net>
Cc: Francisco Jerez <currojerez@riseup.net>
Cc: Dave Gordon <david.s.gordon@intel.com>
Cc: Thomas Daniel <thomas.daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Appease gcc and remove the unused variable.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm_vblank_count() returns the software counter. We should not pretend
it's the hw counter since we use the hw counter to figuere out what the
software counter value should be. So instead provide a new function
drm_vblank_no_hw_counter() for drivers that don't have a real hw
counter. The new function simply returns 0, which is about the only
thing it can do.
Cc: Vincent Abriou <vincent.abriou@st.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
[danvet: s/int pipe/unsigned int pipe/ to follow Thierry's interface
change.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Note that in Bspec you have to dig around in a section called
"Timestamp bases" and Bspec update request is filed.
Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
Signed-off-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Add note about state of Bspec.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Passing cliprects into the kernel for it to re-execute the batch buffer
with different CMD_DRAWRECT died out long ago. As DRI1 support has been
removed from the kernel, we can now simply reject any execbuf trying to
use this "feature".
To keep Daniel happy with the prospect of being able to reuse these
fields in the next decade, continue to ensure that current userspace is
not passing garbage in through the dead fields.
v2: Fix the cliprects_ptr check
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Exclude active GPU pages from the purview of the background shrinker
(kswapd), as these cause uncontrollable GPU stalls. Given that the
shrinker is rerun until the freelists are satisfied, we should have
opportunity in subsequent passes to recover the pages once idle. If the
machine does run out of memory entirely, we have the forced idling in the
oom-notifier as a means of releasing all the pages we can before an oom
is prematurely executed.
Note that this relies upon an up-front retire_requests to keep the
inactive list in shape, which was added in a previous patch, mostly as
execlist ctx pinning band-aids.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Add note about retire_requests.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With UMS gone, we no longer use it during suspend. And with the last
user removed from the shrinker, we can remove the dead code.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We can forgo an evict-everything here as the shrinker operation itself
will unbind any vma as required. If we explicitly idle the GPU through a
switch to the default context, we not only create a request in an
illegal context (e.g. whilst shrinking during execbuf with a request
already allocated), but switching to the default context will not free
up the memory backing the active contexts - unless in the unlikely
situation that context had already been closed (and just kept arrive by
being the current context). The saving is near zero and the danger real.
To compensate for the loss of the forced retire, add a couple of
retire-requests to i915_gem_shirnk() - this should help free up any
transitive cache from the requests.
Note that the second retire_requests is for the benefit of the
hand-rolled execlist ctx active tracking: We need to manually kick
requests to get those unpinned again. Once that's fixed we can try to
remove this again.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add summary of why we need a pile of retire_requests.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Often it is very useful to know why we suddenly purge vast tracts of
memory and surprisingly up until now we didn't even have a tracepoint
for when we shrink our memory.
Note that there are slab_start/end tracepoints already, but those
don't cover the internal recursion when we directly call into our
shrinker code. Hence a separate tracepoint seems justified. Also note
that we don't really need a separate tracepoint for the actual amount
of pages freed since we already have an unbind tracpoint for that.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add a note that there's also slab_start/end and why they're
insufficient.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add the item of i915_component.h in DocBook and add the DOC for
i915_component.h. Explain the struct i915_audio_component_ops and
struct i915_audio_component_audio_ops usage.
Signed-off-by: Libin Yang <libin.yang@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pull in the i915/hda changes for N/CTS setting so I can apply the
follow-up documentation work for drm/i915.
Some conflicts because ofc we had to rework i915 while that N/CTS work
was going on. But not more than adjacent changes really.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
As the shrinker_control now passes us unsigned long targets, update our
shrinker functions to match.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I've botched this, so let's fix it.
Botched in
commit eb0b44adc0
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Mar 18 14:47:59 2015 +0100
drm/i915: kerneldoc for i915_gem_shrinker.c
v2: Be a good citizen^Wmaintainer and add the proper commit citation.
Noticed by Jani.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
The new amdgpu driver passes a user space pointer in a 64-bit structure
member, which is the correct way to do it, but it attempts to
directly cast it to a __user pointer in the kernel, which causes
a warning in three places:
drm/amd/amdgpu/amdgpu_cs.c: In function 'amdgpu_cs_parser_init':
drm/amd/amdgpu/amdgpu_cs.c:180:21: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
chunk_array_user = (uint64_t __user *)(cs->in.chunks);
This changes all three to add an intermediate cast to 'unsigned long'
as other drivers do. This avoids the warning and works correctly on
both 32-bit and 64-bit architectures.
Fixes: e60b344f6c ("drm/amdgpu: optimize amdgpu_parser_init")
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
qxl_bo_unref calls drm_gem_object_unreference_unlocked which
locks dev->struct_mutex. However this lock could be already
locked if the call came from qxl_gem_object_free.
As we don't need to call qxl_bo_ref/qxl_bo_unref cause
qxl_release_list_add will hold a reference by itself avoid
to call them and the possible deadlock.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This avoid a dependency lock error.
According to https://lwn.net/Articles/548909/ users of WW mutex API
should avoid using different context.
When a buffer is reserved with qxl_bo_reserve a ww_mutex_lock without
context is used. However during qxl_draw_dirty_fb different locks
with specific context are used.
This is detected during a machine booting with a debug kernel with lock
dependency checking enabled.
Like many other function in this file to avoid this problem object
pinning is used. Once the object is pinned is not necessary to keep
the lock so it can be released avoiding the locking problem.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Commit "c0fe07a drm/qxl: rewrite framebuffer support" has a bug in the
dirty rectangle tracking: Instead of ignoring an empty dirty rectangle
when adding a new dirty region the dirty region gets extended to the
upper left corner. Fix it.
Cc: linux-stable@vger.kernel.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
HDMI sinks are permitted to de-assert and re-assert the HPD signal to
indicate that their EDID has been updated, which may not involve a
change of video information.
An example of where such a situation can arise is when an AV receiver
is connected between the source and the display device. Events which
can cause the HPD to be deasserted include:
* turning on or switching to standby the AV receiver.
* turning on or switching to standby the display device.
Each of these can change the entire EDID data, or just a part of the
EDID data - it's up to the connected HDMI sink to do what they desire
here. For example
- with the AV receiver and display device both in standby, a source
connected to the AV receiver may provide its own EDID to the source.
- turning on the display device causes the display device's EDID to be
made available in an unmodified form to the source.
- subsequently turning on the AV receiver then provides a modified
version of the display device's EDID.
Moreover, HPD doesn't tell us whether something is actually listening
on the HDMI TDMS signals. The phy gives us a set of RXSENSE indications
which tell us whether there is a sink connected to the TMDS signals.
Currently, we use the HPD signal to enable or disable the HDMI block,
which is questionable when HPD is used in this manner. Using the
RXSENSE would be more appropriate, but there is some bad behaviour
which needs to be coped with. The iMX6 implementation lets the TMDS
signals float when the phy is "powered down", which cause spurious
interrupts. Rather than just using RXSENSE, use RXSENSE and HPD
becoming both active to signal the presence of a device, but loss
of RXSENSE to indicate that the device has been unplugged.
The side effect of this change is that a sink deasserting the HPD
signal to cause a re-read of the EDID data will not cause the bridge
to immediately disable the video signal.
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
When connected to HDMI sources, some DVI monitors de-assert their HPD
signal and TDMS loads for one seconds every four seconds when there is
no signal present on the connection.
Unfortunately, this behaviour is indistinguishable from a proper HDMI
setup with an AV receiver in the path to the display: the HDMI spec
requires us to detect HPD deassertions as short as 100ms, which indicate
that the EDID has changed.
Since it is possible to connect a DVI monitor to an AV receiver and then
to a HDMI source, merely working around this by detecting the lack of
HDMI vendor block in the EDID is insufficient - the AV receiver is at
liberty to modify the EDID as it sees fit, and it will place its own
parameters into the EDID including the HDMI vendor block.
DRM has support for forcing the state of a connector, which we should
implement to allow us to work around these broken DVI monitors - we can
tell DRM to force the connection state to indicate that there is always
a device connected to work around this problem. Although this requires
manual configuration, it is better than nothing at all.
When a forced connection state has been set, there is no point handling
our RXSENSE interrupts, so disable them in this circumstance.
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add support for interlaced video modes to the dw_hdmi bridge. This
mainly involves halving the vertical parameters to be programmed into
the bridge registers, and setting the interlace_allowed connector flag.
This brings working 1080i support. However, 480i and 576i fail to
work due to the lack of proper pixel repetition support, which is not
trivial to add due to the tabular PLL parameterisation. Hence, we
filter out these modes in our mode_valid() method.
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
