If tiler_unpin() call in omap_gem_put_paddr() fails,
omap_gem_put_paddr() will immediately stop processing and return an
error.
This patch remoes that error checking, and also removes
omap_gem_put_paddr()'s return value, because:
* The caller of omap_gem_put_paddr() can do nothing if an error
happens, so it's pointless to return an error value
* If tiler_unpin() fails, the GEM object will possibly be left in an
undefined state, where the DMM mapping may have been removed, but the
GEM object still thinks everything is as it should be, leading to
crashes later.
* There's no point in returning an error from a "free" call, as the
caller can do nothing about it. So it's better to clean up as much as
possible.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
omap_framebuffer_unpin() check the return value of omap_gem_put_paddr()
and return immediately if omap_gem_put_paddr() fails.
This patch removes the check for the return value, and also removes the
return value of omap_framebuffer_unpin(), because:
* Nothing checks the return value of omap_framebuffer_unpin(), and even
something did check it, there's nothing the caller can do to handle
the error.
* If a omap_gem_put_paddr() fails, the framebuffer's other planes will
be left unreleased. So it's better to call omap_gem_put_paddr() for
all the planes, even if one would fail.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The DMM driver uses a timeout of 1 ms to wait for DMM transaction to
finish. While DMM should always finish the operation within that time,
the timeout is rather strict. Small misbehavior of the system (e.g. an
irq taking too long) could trigger the timeout.
As the DMM is a critical piece of code for display memory management,
let's increase the timeout to 100 ms so that we are less likely to fail
a memory allocation in case of system misbehaviors. 100 ms is just a
guess of a reasonably large timeout. The HW should accomplish the task
in less than 1 ms.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
DRM allows planes to be partially off-screen, but DSS hardware does not.
This patch adds the necessary check to reject plane configs if the plane
is not fully inside the crtc.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Use kvfree() instead of open-coding it.
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Similarly to what is done for SKL, clear the dpll_hw_state of the pipe
config in hsw_dp_set_ddi_pll_sel(), since it main contain stale values.
That can happen if a crtc that was previously driving an HDMI connector
switches to a DP connector. In that case, the wrpll field was left with
its old value, leading to warnings like the one below:
[drm:check_crtc_state [i915]] *ERROR* mismatch in dpll_hw_state.wrpll (expected 0xb035061f, found 0x00000000)
------------[ cut here ]------------
WARNING: CPU: 1 PID: 767 at drivers/gpu/drm/i915/intel_display.c:12324 check_crtc_state+0x975/0x10b0 [i915]()
pipe state doesn't match!
This regression was indroduced in
commit dd3cd74acf
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date: Fri May 15 13:34:29 2015 +0300
drm/i915: Don't overwrite (e)DP PLL selection on SKL
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Tested-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Add support for reading out the HW state for DDI ports. Since the actual
programming is very similar to the CHV/VLV DPIO PLL programming we can
reuse much of the logic from there.
This fixes the state checker failures I saw on my BXT with HDMI output.
v2:
- rebased on v2 of patch 4/5
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Depending on the platform the port clock fed to the pipe can be the PLL's
post-divided fast clock rate or a /5 divided version of it. To make this
more obvious across the platforms calculate this port clock along with
the rest of the PLL parameters.
This is also needed by the next patch where we can reuse the CHV helper
for the BXT PLL HW readout code; so export the corresponding helper.
While at it also add a more descriptive name to the helpers and a
comment explaining what's being calculated.
No functional change.
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Move the helper next to the PLL helpers of the other platforms for
clarity.
No functional change.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Although we have a fixed setting for the PLL9 and EBB4 registers, it
still makes sense to check them together with the rest of PLL registers.
While at it also remove a redundant comment about 10 bit clock enabling.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch adds support for 0.85V VccIO on Skylake Y,
separate buffer translation tables for Skylake U,
and support for I_boost for the entries that needs this.
Changes in v2:
* Refactored the code a bit to move all DDI signal level setup to
intel_ddi.c
Issue: VIZ-5677
Signed-off-by: David Weinehall <david.weinehall@linux.intel.com>
Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com>
[danvet: Apply style polish checkpatch suggested.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: remove unrelated whitespace change, fix C comment
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
And use common fence infrastructure for the wait.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
If the CONFIG_DEBUG_FS is not selected, compilation of the
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c provides two warnings that
amdgpu_debugfs_regs_init and amdgpu_debugfs_regs_cleanup are used but
never defined. And as result:
ERROR: "amdgpu_debugfs_regs_cleanup" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: "amdgpu_debugfs_regs_init" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
^
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alexander Kuleshov <kuleshovmail@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Remove duplication across asic families and make it symmetric
with the freeing of the code in amdgpu_device.c
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
kfree(NULL) is safe and this check is probably not required
Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
Reviewed-by: Vaneet Narang <v.narang@samsung.com>
Reviewed-by: Christian Konig <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Use kzalloc rather than kcalloc(1.. for allocating
one thing.
Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
Reviewed-by: Vaneet Narang <v.narang@samsung.com>
Reviewed-by: Christian Konig <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We only should do so when the BO_VA was actually mapped.
Otherwise we get a nice error message on the next CS.
v2: It actually doesn't matter if it was invalidated or not,
if it was mapped we need to clear the area where it was mapped.
Signed-off-by: Christian König <christian.koenig@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com> (v1)
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This patch is to resolve compute hang at resume time.
v2: (agd5f) squash in second fix
Signed-off-by: Sonny Jiang <sonny.jiang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
In order for hibernation to reliably work we need to properly turn
off the SDMA block, sadly after numerous attemps i haven't not found
proper sequence for clean and full shutdown. So simply reset both
SDMA block, this makes hibernation works reliably on sea island GPU
family (CI)
Hibernation and suspend to ram were tested (several times) on :
Bonaire
Hawaii
Mullins
Kaveri
Kabini
Cc: stable@vger.kernel.org
Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
In order for hibernation to reliably work we need to cleanup more
thoroughly the compute ring. Hibernation is different from suspend
resume as when we resume from hibernation the hardware is first
fully initialize by regular kernel then freeze callback happens
(which correspond to a suspend inside the radeon kernel driver)
and turn off each of the block. It turns out we were not cleanly
shutting down the compute ring. This patch fix that.
Hibernation and suspend to ram were tested (several times) on :
Bonaire
Hawaii
Mullins
Kaveri
Kabini
Changed since v1:
- Factor the ring stop logic into a function taking ring as arg.
Cc: stable@vger.kernel.org
Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Use kzalloc for allocating one thing rather than
kcalloc(1...
The semantic patch that makes this change is as follows:
// <smpl>
@@
@@
- kcalloc(1,
+ kzalloc(
...)
// </smpl>
Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
Reviewed-by: Vaneet Narang <v.narang@samsung.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Some 855gm models (at least ThinkPad X40) regressed because of
commit b0cd324fae
Author: Jani Nikula <jani.nikula@intel.com>
Date: Wed Nov 12 16:25:43 2014 +0200
drm/i915: don't save/restore backlight hist ctl registers
which tried to make our driver more robust by not blindly saving and
restoring registers, but it failed to take into account
commit 0eb96d6ed3
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Wed Oct 14 12:33:41 2009 -0700
drm/i915: save/restore BLC histogram control reg across suspend/resume
Fix the regression by enabling hist ctl on gen2.
v2: Improved the comment.
v3: Improved the comment, again.
Reported-and-tested-by: Philipp Gesang <phg@phi-gamma.net>
References: http://mid.gmane.org/20150623222648.GD12335@acheron
Fixes: b0cd324fae ("drm/i915: don't save/restore backlight hist ctl registers")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The hardware supposedly ignores the WM1 watermarks while the PND
deadline mode is enabled, but clear out the register just in case.
This is what the other OS does, and it does make register dumps look
more consistent when we don't have partial WM1 values lingering in
the registers (some WM1 watermarks already get zeroed when the actually
used DSPFW registers get written).
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Allow tweaking the VLV/CHV memory latencies thorugh sysfs, like we do
for ILK+.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Enabling PM5/DDR DVFS with multiple active pipes isn't a validated
configuration. It does seem to work most of the time at least, but
there is clearly an additional risk of underruns, so let's not play
with fire.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
CxSR (or maxfifo on VLV/CHV) blocks somne changes to the plane control
register (enable bit at least, not quite sure about the rest). So in
order to have the plane enable/disable when we want we need to first
kick the hardware out of cxsr.
Unfortunateloy this requires some extra vblank waits. For the CxSR
enable after the plane update we should eventually use an async
vblank worker, but since we don't have that just do sync vblank
waits. For the disable case we have no choice but to do it
synchronously.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In order to get decnet memory self refresh residency on VLV, flip it
over to the new CHV way of doing things. VLV doesn't do PM5 or DDR DVFS
so it's a bit simpler.
I'm not sure the currently memory latency used for CHV is really
appropriate for VLV. Some further testing will probably be needed to
figure that out.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Consider which planes are active and compute the FIFO split based on the
relative data rates. Since we only consider the pipe src width rather
than the plane width when computing watermarks it seems best to do the
same when computing the FIFO split as well. This means the only thing we
actually have to consider for the FIFO splut is the bpp, and we can
ignore the rest.
I've just stuffed the logic into the watermark code for now. Eventually
it'll need to move into the atomic update for the crtc.
There's also one extra complication I've not yet considered; Some of the
DSPARB registers contain bits related to multiple pipes. The registers
are double buffered but apparently they update on the vblank of any
active pipe. So doing the FIFO reconfiguration properly when multiple
pipes are active is not going to be fun. But let's ignore that mess for
now.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Turns out the VLV/CHV system agent doesn't understand memory
latencies, so trying to rely on the PND deadline mechanism is not
going to fly especially when DDR DVFS is enabled. Currently we try to
avoid the problems by lying to the system agent about the deadlines
and setting the FIFO watermarks to 8 cachelines. This however leads to
bad memory self refresh residency.
So in order to satosfy everyone we'll just give up on the deadline
scheme and program the watermarks old school based on the worst case
memory latency.
I've modelled this a bit on the ILK+ approach where we compute multiple
sets of watermarks for each pipe (PM2,PM5,DDR DVFS) and when merge thet
appropriate one later with the watermarks from other pipes. There isn't
too much to merge actually since each pipe has a totally independent
FIFO (well apart from the mess with the partially shared DSPARB
registers), but still decopuling the pipes from each other seems like a
good idea.
Eventually we'll want to perform the watermark update in two phases
around the plane update to avoid underruns due to the single buffered
watermark registers. But that's still in limbo for ILK+ too, so I've not
gone that far yet for VLV/CHV either.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
