We're not supposed to store the adjusted mode into crtc->mode. We don't
use it anyway, so we can safely remove this.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Fix the start address calculation when overlay is partially off screen.
fb->bits_per_pixel is not set for YUV formats, and is always zero, which
led to the first component always starting at zero.
Use drm_format_plane_cpp() instead.
This also revealed a problem in that YUYV formats toggle the U/V data
for odd pixel start address offsets. We try to rectify that by
toggling the U/V swap, which for the most part works, but seemingly
introduces a flicker for one scan frame of swapped U/V.
However, these changes result in an overall improvement.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Use drm_plane_helper_check_update() rather than our own code to validate
and limit the size of the displayed image. As we are able to support
scaling, permit the full scaling ability.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Fix the gem object freeing after a partial import of a dma buffer,
eg, one which has been imported, but not mapped. This was provoking
a warning from the dma_buf code.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The Armada overlay plane wasn't being properly cleaned up as it was
missing a call to drm_plane_cleanup(). It also wasn't freeing the
right type of pointer (although we were still freeing the right
pointer value.)
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Nothing was waking up the overlay plane wait queue, so we were fully
reliant on the HZ/25 wait timing out to make progress. Fix the lack
of wake-up.
We were also mis-handling the wait_event_timeout() return value - this
returns an unsigned integer of the remaining time, or zero on timeout
and the condition evaluated false. Checking this for less than zero
is not sane.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
one fix, one revert
* tag 'drm-intel-fixes-2015-06-18' of git://anongit.freedesktop.org/drm-intel:
Revert "drm/i915: Don't skip request retirement if the active list is empty"
drm/i915: Always reset vma->ggtt_view.pages cache on unbinding
If you do radeon.mst=1 on a gpu without mst hw, and then
plug some mst hw it will oops instead of falling back.
So check we have DCE5 at least before proceeding.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
This tells userspace that it's safe to use the RADEON_VA_UNMAP operation
of the DRM_RADEON_GEM_VA ioctl.
Cc: stable@vger.kernel.org
(NOTE: Backporting this commit requires at least backports of commits
26d4d129b6,
48afbd70ac and
c29c0876ec as well, otherwise using
RADEON_VA_UNMAP runs into trouble)
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Turns out 1366x768 does not in fact work on this hardware.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
With the introduction of multiple views of an obj in the same vm, each
vma was taught to cache its copy of the pages (so that different views
could have different page arrangements). However, this missed decoupling
those vma->ggtt_view.pages when the vma released its reference on the
obj->pages. As we don't always free the vma, this leads to a possible
scenario (e.g. execbuffer interrupted by the shrinker) where the vma
points to a stale obj->pages, and explodes.
Fixes regression from commit fe14d5f4e5
Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Date: Wed Dec 10 17:27:58 2014 +0000
drm/i915: Infrastructure for supporting different GGTT views per object
Tvrtko says, if someone else will be confused how this can happen, key
is the reservation execbuffer path. That puts the VMA on the exec_list
which prevents i915_vma_unbind and i915_gem_vma_destroy from fully
destroying the VMA. So the VMA is left existing as an empty object in
the list - unbound and disassociated with the backing store. Kind of a
cached memory object. And then re-using it needs to clear the cached
pages pointer which is fixed above.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1227892
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
[Jani: Added Tvrtko's explanation to commit message.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Fix for the regression Linus called out, and another for probing
dongles.
* tag 'drm-intel-fixes-2015-06-11' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Fix DDC probe for passive adapters
drm/i915: Properly initialize SDVO analog connectors
Some error paths didn't unreserve the BO. This resulted in a deadlock
down the road on the next attempt to reserve the (still reserved) BO.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90873
Cc: stable@vger.kernel.org
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Laptop with Turks/Thames GPU will freeze if dpm is enabled. It seems
the SMC engine is relying on some state inside the CP engine. CP needs
to chew at least one packet for it to get in good state for dynamic
power management.
This patch simply disabled and re-enable DPM after the ring test which
is enough to avoid the freeze.
Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Passive DP->DVI/HDMI dongles on DP++ ports show up to the system as HDMI
devices, as they do not have a sink device in them to respond to any AUX
traffic. When probing these dongles over the DDC, sometimes they will
NAK the first attempt even though the transaction is valid and they
support the DDC protocol. The retry loop inside of
drm_do_probe_ddc_edid() would normally catch this case and try the
transaction again, resulting in success.
That, however, was thwarted by the fix for [1]:
commit 9292f37e1f
Author: Eugeni Dodonov <eugeni.dodonov@intel.com>
Date: Thu Jan 5 09:34:28 2012 -0200
drm: give up on edid retries when i2c bus is not responding
This added code to exit immediately if the return code from the
i2c_transfer function was -ENXIO in order to reduce the amount of time
spent in waiting for unresponsive or disconnected devices. That was
possible because the underlying i2c bit banging algorithm had retries of
its own (which, of course, were part of the reason for the bug the
commit fixes).
Since its introduction in
commit f899fc64cd
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Jul 20 15:44:45 2010 -0700
drm/i915: use GMBUS to manage i2c links
we've been flipping back and forth enabling the GMBUS transfers, but
we've settled since then. The GMBUS implementation does not do any
retries, however, bailing out of the drm_do_probe_ddc_edid() retry loop
on first encounter of -ENXIO. This, combined with Eugeni's commit, broke
the retry on -ENXIO.
Retry GMBUS once on -ENXIO on first message to mitigate the issues with
passive adapters.
This patch is based on the work, and commit message, by Todd Previte
<tprevite@gmail.com>.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=41059
v2: Don't retry if using bit banging.
v3: Move retry within gmbux_xfer, retry only on first message.
v4: Initialize GMBUS0 on retry (Ville).
v5: Take index reads into account (Ville).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85924
Cc: Todd Previte <tprevite@gmail.com>
Cc: stable@vger.kernel.org
Tested-by: Oliver Grafe <oliver.grafe@ge.com> (v2)
Tested-by: Jim Bride <jim.bride@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
In the commit below, I missed the connector allocation in the function
intel_sdvo_analog_init(), leading to those connectors to have a NULL
state pointer.
commit 08d9bc920d
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date: Fri Apr 10 10:59:10 2015 +0300
drm/i915: Allocate connector state together with the connectors
Reported-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Writing to a file is supposed to return the number of bytes written.
Returning zero unfortunately causes bash to constantly spin trying
to write to the sysfs file, to such an extent that even ^c and ^z
have no effect. The only way out of that is to kill the shell and
log back in. This isn't nice behaviour.
Fix it by returning the number of characters written to sysfs files.
[airlied: used suggestion from Al Viro]
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
bunch of i915 fixes.
* tag 'drm-intel-fixes-2015-06-05' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Move WaBarrierPerformanceFixDisable:skl to skl code from chv code
drm/i915: Include G4X/VLV/CHV in self refresh status
drm/i915: Initialize HWS page address after GPU reset
drm/i915: Don't skip request retirement if the active list is empty
drm/i915/hsw: Fix workaround for server AUX channel clock divisor
commit 65ca7514e2
Author: Damien Lespiau <damien.lespiau@intel.com>
Date: Mon Feb 9 19:33:22 2015 +0000
drm/i915/skl: Implement WaBarrierPerformanceFixDisable
got misapplied and the code landed in chv_init_workarounds() instead of
the intended skl_init_workarounds(). Move it over to the right place.
Cc: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Add all missing platforms handled by intel_set_memory_cxsr() to the
i915_sr_status debugfs entry.
v2: Add G4X too. (Ville)
Clarify the change also affects CHV. (Ander)
References: https://bugs.freedesktop.org/show_bug.cgi?id=89792
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
After GPU reset, HW is losing the address of HWS page in the register.
The page itself is valid except that HW is not aware of its location.
[ 64.368623] [drm:gen8_init_common_ring [i915]] *ERROR* HWS Page address = 0x00000000
[ 64.368655] [drm:gen8_init_common_ring [i915]] *ERROR* HWS Page address = 0x00000000
[ 64.368681] [drm:gen8_init_common_ring [i915]] *ERROR* HWS Page address = 0x00000000
[ 64.368704] [drm:gen8_init_common_ring [i915]] *ERROR* HWS Page address = 0x00000000
This patch reloads this value into the register during ring init.
Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
One minor fix for last -rc of 4.1. The fix moves the update of an attribute in
topology to *after* it is actually initialized.
* tag 'drm-amdkfd-fixes-2015-06-03' of git://people.freedesktop.org/~gabbayo/linux:
drm/amdkfd: fix topology bug with capability attr.
This patch fixes a bug where the number of watch points
was shown before it was actually calculated
Signed-off-by: Alexey Skidanov <Alexey.Skidanov@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Apparently we can have requests even if though the active list is empty,
so do the request retirement regardless of whether there's anything
on the active list.
The way it happened here is that during suspend intel_ring_idle()
notices the olr hanging around and then proceeds to get rid of it by
adding a request. However since there was nothing on the active lists
i915_gem_retire_requests() didn't clean those up, and so the idle work
never runs, and we leave the GPU "busy" during suspend resulting in a
WARN later.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
According to the HSW b-spec we need to try clock divisors of 63
and 72, each 3 or more times, when attempting DP AUX channel
communication on a server chipset. This actually wasn't happening
due to a short-circuit that only checked the DP_AUX_CH_CTL_DONE bit
in status rather than checking that the operation was done and
that DP_AUX_CH_CTL_TIME_OUT_ERROR was not set.
[v2] Implemented alternate solution suggested by Jani Nikula.
Cc: stable@vger.kernel.org
Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Regression fix for Fermi acceleration, and fixes important to bringing
up display-less Maxwell boards.
* 'linux-4.1' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nouveau/gr/gm204: remove a stray printk
drm/nouveau/devinit/gm100-: force devinit table execution on boards without PDISP
drm/nouveau/devinit/gf100: make the force-post condition more obvious
drm/nouveau/gr/gf100-: fix wrong constant definition
We have that bug for years and some users report side effects when fixing it on older hardware.
So revert it for VM_CONTEXT0_PAGE_TABLE_END_ADDR, but keep it for VM 1-15.
Signed-off-by: Christian König <christian.koenig@amd.com>
CC: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
here's a drm regression fix for drivers only partially
converted to atomic.
* tag 'topic/drm-fixes-2015-05-27' of git://anongit.freedesktop.org/drm-intel:
drm/plane-helper: Adapt cursor hack to transitional helpers
For actual sharing of buffers with other drivers (ie. actual hardware)
we'll need to pimp things out a bit better to deal w/ caching, multiple
memory domains, etc. See thread:
http://lists.freedesktop.org/archives/dri-devel/2015-May/083160.html
But for the llvmpipe use-case this isn't a problem. Nor do we really
need prime/dri3 (dri2 is sufficient). So until the other issues are
sorted lets remove DRIVER_PRIME.
v2: also drop the dead code
[airlied:
Okay I'm convinced this API could have a lot of use cases
that are really really bad, yes the upload use case is valid
however that isn't the only use case enabled, and if we allow
all the other use cases, people will start to (ab)use them,
and then they'll be ABI and my life will get worse, so disable
PRIME for now]
Acked-by: Thomas Hellstrom <thellstrom@vmware.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In
commit f02ad907cd
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Jan 22 16:36:23 2015 +0100
drm/atomic-helpers: Recover full cursor plane behaviour
we've added a hack to atomic helpers to never to vblank waits for
cursor updates through the legacy apis since that's what X expects.
Unfortunately we've (again) forgotten to adjust the transitional
helpers. Do this now.
This fixes regressions for drivers only partially converted over to
atomic (like i915).
Reported-by: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Just two small DP fixes for 4.1
* 'drm-fixes-4.1' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: fix error flag checking in native aux path
drm/radeon: retry dcpd fetch
There's a stable backport from Ander [1] that combines this and a few
other commits to fix the flickering on v4.0, reported in [2] among
others. Having this upstream is obviously a requirement for stable.
* tag 'drm-intel-fixes-2015-05-21' of git://anongit.freedesktop.org/drm-intel:
drm/i915: fix screen flickering
That atom table does not check these bits. Fixes aux
regressions on some boards.
Reported-by: Malte Schröder <malte@tnxip.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
The index of ->planes[] array (3rd parameter) cannot be equal to MAX_PLANE.
This looks like a typo that is now fixed.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Acked-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Don't pollute the dmesg with EDID read success message as an error.
Printing as debug should be fine.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The index for the hardware layer is always >=0. Previous
code that also used -1 as special index is now gone.
Also apply this to 'ch_enabled' (decon/fimd), since the
variable is on the same line (and is again always unsigned).
Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
