For the purpose of state checking we only care about the DPLL HW flags
that we actually program, so mask off the ones that we don't.
This fixes one set of DPLL state check failures.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pull radeon and amdgpu fixes from Alex Deucher:
"First round of fixes for 4.2 for radeon and amdgpu. Stuff all over
the place:
- hibernation, suspend fixes for radeon and amdgpu
- radeon audio fix
- amdgpu ioctl optimzations and fixes
- amdgpu VCE cs checker improvements
- misc bug fixes"
[ Dave on vacation, pulling directly ]
* 'drm-next-4.2' of git://people.freedesktop.org/~agd5f/linux: (30 commits)
drm/radeon: only check the sink type on DP connectors
drm/amdgpu: add flag to delay VM updates
drm/amdgpu: add optional dependencies to the CS IOCTL v2
drm/amdgpu: recreate fence from user seq
gpu/drm/amdgpu: Fix build when CONFIG_DEBUG_FS is not set
Revert "drm/radeon: dont switch vt on suspend"
drm/amdgpu: disable enable_nb_ps_policy temporarily
drm/amdgpu: correct define SMU_EnabledFeatureScoreboard_SclkDpmOn
drm/amdgpu: allocate ip_block_enabled memory in common code
drm/amdgpu: remove unnecessary check before kfree
drm/amdgpu: use kzalloc for allocating one thing
drm/radeon: fix adding all VAs to the freed list on remove v2
drm/amdgpu: add chunk id validity check
drm/amdgpu: fix crash on invalid CS IOCTL
drm/amdgpu: reset wptr at cp compute resume (v2)
drm/amdgpu: check VCE feedback and bitstream index
drm/amdgpu: make VCE handle check more strict
drm/amdgpu: check VCE relocation buffer range
drm/amdgpu: silence invalid error message
drm/amdgpu: fix wrong type
...
Pull intel drm fixes from Jani Nikula:
"Almost all of it is regression fixes all around, with cc: stable, and
then there's Ander's fix for one of the warnings you reported. We're
still working on the rest"
[ Dave is on vacation, and Jani is heading out on vacation too ]
* tag 'drm-intel-next-fixes-2015-07-02' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Clear pipe's pll hw state in hsw_dp_set_ddi_pll_sel()
drm/i915: fix backlight after resume on 855gm
agp/intel: Fix typo in needs_ilk_vtd_wa()
drm/i915/ppgtt: Break loop in gen8_ppgtt_clear_range failure path
drm/i915: Fix IPS related flicker
Pull implicit module.h fixes from Paul Gortmaker:
"Fix up implicit <module.h> users that will break later.
The files changed here are simply modular source files that are
implicitly relying on <module.h> being present. We fix them up now,
so that we can decouple some of the module related init code from the
core init code in the future.
The addition of the module.h include to several files here is also a
no-op from a code generation point of view, else there would already
be compile issues with these files today.
There may be lots more implicit includes of <module.h> in tree, but
these are the ones that extensive build test coverage has shown that
must be fixed in order to avoid build breakage fallout for the pending
module.h <---> init.h code relocation we desire to complete"
* tag 'module-implicit-v4.1-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux:
frv: add module.h to mb93090-mb00/flash.c to avoid compile fail
drivers/cpufreq: include <module.h> for modular exynos-cpufreq.c code
drivers/staging: include <module.h> for modular android tegra_ion code
crypto/asymmetric_keys: pkcs7_key_type needs module.h
sh: mach-highlander/psw.c is tristate and should use module.h
drivers/regulator: include <module.h> for modular max77802 code
drivers/pcmcia: include <module.h> for modular xxs1500_ss code
drivers/hsi: include <module.h> for modular omap_ssi code
drivers/gpu: include <module.h> for modular rockchip code
drivers/gpio: include <module.h> for modular crystalcove code
drivers/clk: include <module.h> for clk-max77xxx modular code
This change updates the old_fb pointer only after acquiring the plane lock,
if there are no properties the fb cannot have been changed either, so
this works out correctly.
Found in a discussion with Rob Clark.
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Blank lines at the end of a function definition are not useful, so get
rid of it.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I've done some extensive history digging across libdrm, mesa and
xf86-video-{intel,nouveau,ati}. The only potential user of this with
kms drivers I could find was ttmtest, which once used drmGetLock
still. But that mistake was quickly fixed up. Even the intel xvmc
library (which otherwise was really good with using dri1 stuff in kms
mode) managed to never take the hw lock for dri2 (and hence kms).
Hence it should be save to unconditionally disallow this.
Cc: Peter Antoine <peter.antoine@intel.com>
Reviewed-by: Peter Antoine <peter.antoine@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
The context functions are not used by the i915 driver and should not
be used by modeset drivers. These driver functions contain several bugs
and security holes. This change makes these functions optional can be
turned on by a setting, they are turned off by default for modeset
driver with the exception of the nouvea driver that may require them with
an old version of libdrm.
The previous attempt was
commit 7c510133d9
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Aug 8 15:41:21 2013 +0200
drm: mark context support as a legacy subsystem
but this had to be reverted
commit c21eb21cb5
Author: Dave Airlie <airlied@redhat.com>
Date: Fri Sep 20 08:32:59 2013 +1000
Revert "drm: mark context support as a legacy subsystem"
v2: remove returns from void function, and formatting (Daniel Vetter)
v3:
- s/Nova/nouveau/ in the commit message, and add references to the
previous attempts
- drop the part touching the drm hw lock, that should be a separate
patch.
Signed-off-by: Peter Antoine <peter.antoine@intel.com> (v2)
Cc: Peter Antoine <peter.antoine@intel.com> (v2)
Reviewed-by: Peter Antoine <peter.antoine@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
align_pitch() uses ALIGN() to ensure the pitch is aligned to SGX's
requirement of 8 pixels. However, ALIGN() expects the alignment value to
be a power of two, which is not the case for 24 bits per pixels.
Use roundup() instead, which works for all alignments.
This fixes the error seen with 24 bits per pixel modes:
"buffer pitch (2176 bytes) is not a multiple of pixel size (3 bytes)"
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
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>
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>
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>
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>
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>
