This flag is a hint that userspace expects the BO to be accessed by the
CPU. We can use that hint to prevent such BOs from ever being stored in
the CPU inaccessible part of VRAM.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Add ptr to list of interesting registers to 'struct adreno_gpu' and use
that to move most of the debugfs show and register dump bits down into
adreno_gpu. This will avoid duplication as support for additional
adreno generations is added.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Push a few bits down into adreno_gpu so they won't have to be duplicated
as support for additional adreno generations is added.
Signed-off-by: Rob Clark <robdclark@gmail.com>
LVDS panel, make/model described as:
AU Optronics Corporation - B101XTN01.0 (H/W:0A)
See:
http://www.encore-electronic.com/media/B101XTN01.0.pdf
Tested with panel attached to an Inforce IFC6410 board.
Signed-off-by: Rob Clark <robdclark@gmail.com>
LVDS panel support uses the LCDC (parallel) encoder. Unlike with HDMI,
there is not a separate LVDS block, so no need to split things into a
bridge+connector. Nor is there is anything re-used with mdp5.
Note that there can be some regulators shared between HDMI and LVDS (in
particular, on apq8064, ext_3v3p), so we should not use the _exclusive()
variants of devm_regulator_get().
The drm_panel framework is used for panel-specific driver.
Signed-off-by: Rob Clark <robdclark@gmail.com>
In particular, blend_setup() should not overwrite the other crtc's mixer
settings. Also, the encoder needs to be able to specify the mixer-id
explicitly, since both LVDS and DTV use 'INTF_LVDC_DTV', so we cannot
guess the mixer-id from the interface.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Same as the other legacy APIs, most of this is internal, so prefix it with
drm_legacy_* and move into drm_legacy.h.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This merges all the remains of drm_usb into its only user, udl. We can
then drop all the drm_usb stuff, including dev->usbdev.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
..we will not miss you..
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
One step closer to dropping all the drm_bus_* code:
Add a driver->set_busid() callback and make all drivers use the generic
helpers. Nouveau is the only driver that uses two different bus-types with
the same drm_driver. This is totally broken if both buses are available on
the same machine (unlikely, but lets be safe). Therefore, we create two
different drivers for each platform during module_init() and set the
set_busid() callback respectively.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This field is unused and there is really no reason to optimize
unique-allocations. Drop it.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Lets use kasprintf() to avoid pre-allocating the buffer. This is really
nothing to optimize for speed and the input is trusted, so kasprintf() is
just fine.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The sigdata structure is only used to group two fields in drm_device.
Inline it and make it an unnamed object.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Calling vblank_disable_fn() will cause that function to no-op
if !dev->vblank_disable_allowed for some kms drivers, e.g.,
on nouveau-kms. This can cause the gpu vblank irq's to not get
disabled before freeing the dev->vblank array, so if a
vblank irq fires and calls into drm_handle_vblank() after
drm_vblank_cleanup() completes, it will cause use-after-free
access to dev->vblank array.
Call vblank_disable_and_save unconditionally, so vblank irqs
are guaranteed to be off, before we delete the data structures
on which they operate.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Fix subsystem name in patch subject.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
DRM_DEBUG_CODE is currently always set, so distributions enable it. The
only reason to keep support in code is if developers wanted to disable
debug support. Sounds unlikely.
All the DRM_DEBUG() printks are still guarded by a drm_debug read. So if
its cacheline is read once, they're discarded pretty fast.. There should
hardly be any performance penalty, it's even guarded by unlikely().
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The drm_memory.h header is only used to define PAGE_AGP, which is only
used in drm_memory.c. Fold the header into drm_memory.c and drop it.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
pte_wrprotect() is only used by drm_vm.c, so move the include there. Also
include it unconditionally, all architectures provide this header!
Furthermore, replace asm/current.h with sched.h, which includes
asm/current.h unconditionally. This way we get the same effect and avoid
direct asm/ includes. Furthermore, drop the weird __alpha__ protection.
It's safe to include sched.h everywhere (and the wait.h comment doesn't
apply, anyway).
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Move drm_agp_head to drm_agpsupport.h and drm_agp_mem into drm_legacy.h.
Unfortunately, drivers still heavily access drm_agp_head so we cannot
move it to drm_legacy.h. However, at least it's no longer visible in
drmP.h now (it's directly included from it, though).
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In drm_release(), we currently call drm_remove_magic() if the drm_file
has a drm-magic attached. Therefore, once drm_master_release() is called,
the magic-list _must_ be empty.
By dropping the no-op cleanup, we can move "struct drm_magic_entry" to
drm_auth.c and avoid exposing it to all of DRM.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Make all the drm_vma_entry handling local to drm_vm.c and hide it from
global headers. This requires to extract the inlined legacy drm_vma_entry
cleanup into a small helper and also move a weirdly placed drm_vma_info
helper into drm_vm.c.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Move internal declarations to drm_legacy.h and add drm_legacy_*() prefix
to all legacy functions.
[airlied: add a bit of an explaination to drm_legacy.h]
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Radeon UMS is the last user of drm_buffer. Move it out of sight so radeon
can drop it together with UMS.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
On systems with special thermal configurations make sure we make
note of the thermal setup. This is required for proper firmware
configuration on these systems.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
There is no need to use hex_dump_to_buffer() since we have a kernel helper to
dump up to 64 bytes just via printk(). In our case the actual size is 15 bytes.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Semaphore values have 64 bits, not 32. This fixes a very subtle bug
that disables synchronization when the upper 32bits wasn't zero.
Signed-off-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Reviewed-By: Grigori Goronzy <greg@chown.ath.cx>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The vblank waits in intel_tv_detect_type() are timing out for some
reason. This is a regression caused removing seemingly useless vblank
waits from the modeset seqeuence in:
commit 56ef52cad5
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Thu May 8 19:23:15 2014 +0300
drm/i915: Kill vblank waits after pipe enable on gmch platforms
So it turns out they weren't all entirely useless. Apparently the pipe
has to go through one full frame before we enable the TV port. Add a
vblank wait to intel_enable_tv() to make sure that happens.
Another approach was attempted by placing the vblank wait just after
enabling the port. The theory behind that attempt was that we need to
let the port stay enabled for one full frame before disabling it again
during load detection. But that didn't work, and we definitely must
have the vblank wait before enabling the port.
Cc: stable@vger.kernel.org
Cc: Alan Bartlett <ajb@elrepo.org>
Tested-by: Alan Bartlett <ajb@elrepo.org>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79311
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Running igt, I was encountering the invalid TLB bug on my 845g, despite
that it was using the CS workaround. Examining the w/a buffer in the
error state, showed that the copy from the user batch into the
workaround itself was suffering from the invalid TLB bug (the first
cacheline was broken with the first two words reversed). Time to try a
fresh approach. This extends the workaround to write into each page of
our scratch buffer in order to overflow the TLB and evict the invalid
entries. This could be refined to only do so after we update the GTT,
but for simplicity, we do it before each batch.
I suspect this supersedes our current workaround, but for safety keep
doing both.
v2: The magic number shall be 2.
This doesn't conclusively prove that it is the mythical TLB bug we've
been trying to workaround for so long, that it requires touching a number
of pages to prevent the corruption indicates to me that it is TLB
related, but the corruption (the reversed cacheline) is more subtle than
a TLB bug, where we would expect it to read the wrong page entirely.
Oh well, it prevents a reliable hang for me and so probably for others
as well.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
A bunch of warnings fire on some ->irq_postinstall hooks since those
can enable interrupts (e.g. rps interrupts). And then our ordering
self-checks fire and complain.
To fix that set the tracking boolen before enabling the irqs with
drm_irq_install. Quoting the discussion with Jesse why that's safe:
On Tue, Aug 26, 2014 at 11:18 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> Yes, it might work, but if you look through the history, we set this
> field carefully; first to true in the irq_init code, then to false only
> after the irq_install completes. So I think your fragility arguments
> apply to this change too.
Well we've done it in 4 commits or so, but currently we have:
- Set irqs_disabled to true early in driver load to make sure checks
that. That's done in irq_init, which is totally not the function that
enables interrupts, only the function that initializes all the vtables
and similar things. We actually have a fairly sane naming scheme
nowadays (not fully consistent ofc): _init is sw setup,
_enable/_hw_init is the actual hw setup. That is done in
95f25beddb
- Set irqs_disabled to false right after the irqs are actually
enabled. This is done in ed2e6df189
So my change should only move the flag change over the ->preinstall
and ->postinstall hooks. I've done a little audit and didn't spot
anything amiss. Furthermore the runtime pm setup already clears
irqs_disabled _before_ calling these two hooks.
This regression has been introduced in
commit ed2e6df189
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Fri Jun 20 09:39:36 2014 -0700
drm/i915: clear pm._irqs_disabled field after installing IRQs
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Oliver Hartkopp <socketcan@hartkopp.net>
Tested-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk> # gm45, ilk
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
In
commit 1f83fee08d
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Nov 15 17:17:22 2012 +0100
drm/i915: clear up wedged transitions
I've accidentally inverted the EIO/wedged handling in the fault
handler: We want to return the EIO as a SIGBUS only if it's not
because of the gpu having died, to prevent userspace from unduly
dying.
In my defence the comment right above is completely misleading, so fix
both.
v2: Drop the WARN_ON, it's not actually a bug to e.g. receive an -EIO
when swap-in fails.
v3: Don't remove too much ... oops.
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
During release of the GEM object we hold the struct_mutex. As the
object may be holding onto the last reference for the task->mm,
calling mmput() may trigger exit_mmap() which close the vma
which will call drm_gem_vm_close() and attempt to reacquire
the struct_mutex. In order to avoid that recursion, we have
to defer the mmput() until after we drop the struct_mutex,
i.e. we need to schedule a worker to do the clean up. A further issue
spotted by Tvrtko was caused when we took a GTT mmapping of a userptr
buffer object. In that case, we would never call mmput as the object
would be cyclically referenced by the GTT mmapping and not freed upon
process exit - keeping the entire process mm alive after the process
task was reaped. The fix employed is to replace the mm_users/mmput()
reference handling to mm_count/mmdrop() for the shared i915_mm_struct.
INFO: task test_surfaces:1632 blocked for more than 120 seconds.
Tainted: GF O 3.14.5+ #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
test_surfaces D 0000000000000000 0 1632 1590 0x00000082
ffff88014914baa8 0000000000000046 0000000000000000 ffff88014914a010
0000000000012c40 0000000000012c40 ffff8800a0058210 ffff88014784b010
ffff88014914a010 ffff880037b1c820 ffff8800a0058210 ffff880037b1c824
Call Trace:
[<ffffffff81582499>] schedule+0x29/0x70
[<ffffffff815825fe>] schedule_preempt_disabled+0xe/0x10
[<ffffffff81583b93>] __mutex_lock_slowpath+0x183/0x220
[<ffffffff81583c53>] mutex_lock+0x23/0x40
[<ffffffffa005c2a3>] drm_gem_vm_close+0x33/0x70 [drm]
[<ffffffff8115a483>] remove_vma+0x33/0x70
[<ffffffff8115a5dc>] exit_mmap+0x11c/0x170
[<ffffffff8104d6eb>] mmput+0x6b/0x100
[<ffffffffa00f44b9>] i915_gem_userptr_release+0x89/0xc0 [i915]
[<ffffffffa00e6706>] i915_gem_free_object+0x126/0x250 [i915]
[<ffffffffa005c06a>] drm_gem_object_free+0x2a/0x40 [drm]
[<ffffffffa005cc32>] drm_gem_object_handle_unreference_unlocked+0xe2/0x120 [drm]
[<ffffffffa005ccd4>] drm_gem_object_release_handle+0x64/0x90 [drm]
[<ffffffff8127ffeb>] idr_for_each+0xab/0x100
[<ffffffffa005cc70>] ? drm_gem_object_handle_unreference_unlocked+0x120/0x120 [drm]
[<ffffffff81583c46>] ? mutex_lock+0x16/0x40
[<ffffffffa005c354>] drm_gem_release+0x24/0x40 [drm]
[<ffffffffa005b82b>] drm_release+0x3fb/0x480 [drm]
[<ffffffff8118d482>] __fput+0xb2/0x260
[<ffffffff8118d6de>] ____fput+0xe/0x10
[<ffffffff8106f27f>] task_work_run+0x8f/0xf0
[<ffffffff81052228>] do_exit+0x1a8/0x480
[<ffffffff81052551>] do_group_exit+0x51/0xc0
[<ffffffff810525d7>] SyS_exit_group+0x17/0x20
[<ffffffff8158e092>] system_call_fastpath+0x16/0x1b
v2: Incorporate feedback from Tvrtko and remove the unnessary mm
referencing when creating the i915_mm_struct and improve some of the
function names and comments.
Reported-by: Jacek Danecki <jacek.danecki@intel.com>
Test-case: igt/gem_userptr_blits/process-exit*
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: "Gong, Zhipeng" <zhipeng.gong@intel.com>
Cc: Jacek Danecki <jacek.danecki@intel.com>
Cc: "Ursulin, Tvrtko" <tvrtko.ursulin@intel.com>
Reviewed-by: "Ursulin, Tvrtko" <tvrtko.ursulin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org # hold off until 3.17 ships for additional testing
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
If we successfully confuse the hardware, and cause it to drop a queued
pageflip, we wait for 60s and issue a warning before continuing on with
the modeset. However, this leaves the pending pageflip still stuck
indefinitely. Pretend to userspace that it does complete, and let us
start afresh following the modeset.
v2: Rebase after refactor
v3: Rebase, rebase.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=82612
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Long ago, back in the racy haydays of 915gm interrupt handling, page
flips would occasionally go astray and leave the hardware stuck, and the
display not updating. This annoyed people who relied on their systems
being able to display continuously updating information 24/7, and so
some code to detect when the driver missed the page flip completion
signal was added. Until recently, it was presumed that the interrupt
handling was now flawless, but once again Simon Farnsworth has found a
system whose display will stall. Reinstate the pageflip stall detection,
which works by checking to see if the hardware has been updated to the
new framebuffer address following each vblank. If the hardware is
scanning out from the new framebuffer, but we still think the flip is
pending, then we kick our driver into submision.
This is a continuation of the effort started with
commit 4e5359cd05
Author: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Date: Wed Sep 1 17:47:52 2010 +0100
drm/i915: Avoid pageflipping freeze when we miss the flip prepare interrupt
This now includes a belt-and-braces approach to make sure the driver
(or the hardware) doesn't miss an interrupt and cause us to stop
updating the display should the unthinkable happen and the pageflip fail - i.e.
that the user is able to continue submitting flips.
v2: Cleanup, refactor, and rename
v3: Only start counting vblanks after the flip command has been seen by
the hardware.
v4: Record the seqno after we touch the ring, or else there may be no
seqno allocated yet.
v5: Rebase on mmio-flip.
v6: Rebase, rebase.
Reported-by: Simon Farnsworth <simon@farnz.org.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75502
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [v4]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fixes not being able to init fence subsystem when multiple boards are
present.
Reported-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Tired of copy/pasting things around.
v2: Rebase on top of the for_each_pipe() change adding dev_priv as first
argument.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The new version of the macro does a few things better:
- protect the arguments,
- only evaluate the arguments once,
- check that the arguments are of the same type,
Change LC_FREQ_2K to be a unsigned 64bit constant and removed the '()'
from the caller as a result.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jani wanted some comments to explain why we call certain vdd on/off
functions in certain places.
v2: Make the comments more thorough (Imre)
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to turn the DP port off after the pipe, otherwise the pipe won't
turn off properly on certain pch platforms at least (happens on my ILK for
example). This also matches the BSpec modeset sequence better. We still
don't match the spec exactly though (eg. audio disable should happen
much earlier), but at last this eliminates the nasty
wait_for_pipe_off() timeouts.
We already did the port disable after the pipe for VLV/CHV and for CPU
eDP.
For g4x leave the port disable where it is since that matches the
modeset sequence in the documentation and I don't have a suitable
machine to test if the other order would work.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bspec says we should enable the DP port before enabling panel power,
and that the port must be enabled with training pattern 1. Do so.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On VLV/CHV the panel power sequencer may need to be "kicked" a bit to
lock onto the new port, and that needs to happen before any aux
transfers are attempted if we want the aux transfers to actaully
succeed. So turn on panel power (part of the "kick") before aux
transfers (DPMS_ON + link training).
This also matches the documented modeset sequence better for pch
platforms. The documentation doesn't explicitly state anything about the
DPMS or link training DPCD writes, but the panel power on step is
always listed before link training is mentioned.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=70117
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Try to make sure we find the power sequencer that the BIOS used
by first looking for one which has the panel power enabled, then
fall back to one with VDD force bit enabled, and finally look at
just the port select bits. This should make us pick the correct
power sequencer when the BIOS has already enabled the panel.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Shorten the vlv_intial_pps_pipe to make lines fit into 80
chars.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The power sequencer loses its state when the disp2d power well is down.
Clear the dev_priv->pps_pipe tracking so that the power sequencer state
gets reinitialized the next time it's needed.
v2: Fix the pps_mutex vs. power_domain mutex deadlock by taking power
domain reference first
v3: Rename from edp_pps_(un)lock() to just pps_(un)lock() for the future,
update due to backlight code changes
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
VLV/CHV have a per-pipe panel power sequencer which locks onto the
port once used. We need to keep track wich power sequencers are
locked to which ports.
v2: remove spurious whitespace change, rebase due to backlight changes (Imre)
Reviewed-by: Antti Koskipaa <antti.koskipaa@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Break some really long lines to appease checkpatch a bit.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Introduce a new mutex (pps_mutex) to protect the power sequencer
state. For now this state includes want_panel_vdd as well as the
power sequencer registers.
We need a single mutex (as opposed to per port) because later on we
will need to deal with VLV/CHV which have multiple power sequencer
which can be reassigned to different ports.
v2: Add the locking to intel_dp_encoder_suspend too (Imre)
v3: Take care intel_edp_backlight_power() and
_intel_edp_backlight_on/off(), deal with reboot notifier
vlv_power_sequencer_pipe() call (Imre)
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville found an old w/a documented for g4x that suggested that we need to
reset the HEAD after writing START. This is a useful fixup for some of
the g4x ring initialisation woes, but as usual, not all.
v2: Do the rewrite unconditionally anyway
References: https://bugs.freedesktop.org/show_bug.cgi?id=76554
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When unbinding, there is a possibility that we drop the active reference
on the object, thereby freeing it. If that happens, we may destroy the
vm link as well as the object and vma. So iterate carefully.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
here's a couple of display regression fixes for 3.17.
* tag 'drm-intel-fixes-2014-09-03' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Fix lock dropping in intel_tv_detect()
drm/i915: handle G45/GM45 pulse detection connected state.
This crash was already here before the conversion, but qxl never leaked
hard enough to hit this.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
The locking of release_lock was stupid; t should have been be called with
fence_lock_irq if it was legitimately used. Unfortunately it never protected
anything except the fence implementation correctly.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Really just for completeness - old init function ends up making the plane
exactly the same way due to the way the enums are set up.
Signed-off-by: Derek Foreman <derek.foreman@collabora.co.uk>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Check for !HAS_PCH_SPLIT() instead of 'gen < 5' in the PCH transcoder
enable functions.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A few open coded HAS_GMCH_DISPLAY() remain in the underrun reporting
code. Convert them over.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
IS_GEN8() is a bad check in the forcewake code due to bdw vs. chv
differences. Use IS_BROADWELL() instead.
The only actual bug here is that we currently call
__gen7_gt_force_wake_mt_reset() on chv. On the other places we
have checked for chv before using IS_GEN8(), but change them
to use IS_BROADWELL() anyway to reduce the chance of accidents in the
future.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
CHV doesn't have FBC, so don't go calling gen8_fbc_sw_flush() on it.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Add a FIXME comment while at it that we should rework this a
lot more.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We use the variable name latency_ns in both the local lowlevel wm
calculation routines and at the global level. Rename the global value to
reduce shadow warnings and future confusion.
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>
We have CHV code that already makes the test obsolete. Besides, when
num_wa_regs is 0 (platforms not gathering that W/A data), we expose
something sensible already.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we happen to emit more than I915_MAX_WA_REGS workarounds, we will
currently discard them, not even emit the LRI. Not really what we want,
so warn loudly.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When entering intel_ring_emit_wa() with num_wa_regs equal to
I915_MAX_WA_REGS, we end up indexing the intel_wa_regs array beyond its
allocation.
Fix the check then.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Those debugfs files are prefixed by i915, the name of the kernel module,
presumably to make the difference with files exposed by core DRM.
Also, add a ',' at the end of the last entry. This is to ease the
conflict resolution when rebasing internal patches that add a member at
the end of the array. Without it, wiggle can't do its job as we need to
modify an existing line (appending the ',').
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently, CHV is using the same functions as HSW/BDW instead of the
same functions as VLV. This looks wrong, especially since, for
example, valleyview_modeset_global_resouces even has an IS_CHERRYVIEW
check.
This patch has the potential to fix display audio and the CHV CDCLK.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
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>
As we may query the edid multiple times following a detect, record the
EDID found during output discovery and reuse it. This is a separate
issue from caching the output EDID across detection cycles.
v2: Also hookup the force() callback for audio detection when the user
forces the connection status.
v3: Ville spots a typo, s/==/!=/
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As we may query the edid multiple times following a detect, record the
EDID found during output discovery and reuse it. This is a separate
issue from caching the output EDID across detection cycles.
v2: Implement connector->force() callback so that edid is associated
with the connector for user overrides as well (Ville)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Both gmch and pch detection routines used the exact same routine for
eDP, so de-duplicate.
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>
Rename the defines to have levels instead of values for vswing and
pre-emph levels as the values may differ in other scenarios like low vswing of
eDP1.4 where the values are different.
Done using following cocci patch for each define:
@@
@@
# define DP_TRAIN_VOLTAGE_SWING_400 (0 << 0)
+ # define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0)
...
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rename the defines to have levels instead of values for vswing and
pre-emph levels as the values may differ in other scenarios like low vswing of
eDP1.4 where the values are different.
Done using following cocci patch for each define:
@@
@@
# define DP_TRAIN_VOLTAGE_SWING_400 (0 << 0)
+ # define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0)
...
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rename the defines to have levels instead of values for vswing and
pre-emph levels as the values may differ in other scenarios like low vswing of
eDP1.4 where the values are different.
Done using following cocci patch for each define:
@@
@@
# define DP_TRAIN_VOLTAGE_SWING_1200 (3 << 0)
+ # define DP_TRAIN_VOLTAGE_SWING_LEVEL_3 (0 << 0)
...
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Acked-by: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rename the defines to have levels instead of values for vswing and
pre-emph levels as the values may differ in other scenarios like low vswing of
eDP1.4 where the values are different.
Done using following cocci patch for each define:
@@
@@
# define DP_TRAIN_VOLTAGE_SWING_400 (0 << 0)
+ # define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0)
...
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rename the defines to have levels instead of values for vswing and
pre-emph levels as the values may differ in other scenarios like low vswing of
eDP1.4 where the values are different.
Done using following cocci patch for each define:
@@
@@
# define DP_TRAIN_VOLTAGE_SWING_400 (0 << 0)
+ # define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0)
...
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
No point in calling intel_plane_restore() in .set_property() if the
value didn't change.
More importantly this papers over a bug where the current primary plane
code forgets to update the user coordinates we store under intel_plane
unless the primary plane .update_plane() hook is actually called. This
means we have 0 in the coordinates straight after boot and any call
to intel_restore_plane() (such as from restore_fbdev_mode()) will
actually turn off the primary plane. This mess needs to be fixed properly
but that's a bigger task and the first step there is killing off
intel_pipe_set_base() and just calling the primary plane
.update_plane() hook. For the immediate problem of black screen after
boot this small patch is enough to hide it.
The problem originates from these two commits:
commit 3a5f87c286
Author: Thomas Wood <thomas.wood@intel.com>
Date: Wed Aug 20 14:45:00 2014 +0100
drm: fix plane rotation when restoring fbdev configuration
commit d91a2cb8e5104233c02bbde539bd4ee455ec12ac
Author: Sonika Jindal <sonika.jindal@intel.com>
Date: Fri Aug 22 14:06:04 2014 +0530
drm/i915: Add 180 degree primary plane rotation support
Cc: Thomas Wood <thomas.wood@intel.com>
Cc: Sonika Jindal <sonika.jindal@intel.com>
Tested-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Tested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There is no need to use hex_dump_to_buffer() since we have a kernel helper to
dump up to 64 bytes just via printk(). In our case the actual size is 15 bytes.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Add cast since %*ph expects and int for the size parameter.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
WaGsvRC0ResidenncyMethod is for vlv, it doesn't deal with chv
appropriately (eg. doesn't limit rps values to even numbers).
Fix a typo in the w/a name while at it.
Cc: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
My Fujistsu-Siemens Lifebook S6010 doesn't like to resume from
S3 unless VGACNTR has been restore to the original value. The BIOS
value in this case was 0x0124008E. Setting the "VGA disable" bit
doesn't interfere with the S3 resume fortunately.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
830M has problems when some of the pipes are disabled. Namely if a
plane, DVO port etc. is currently assigned to a disabled pipe, it
can't moved to the other pipe until the current pipe is also enabled.
To keep things simple just leave both pipes running all the time.
Ideally I think should turn the pipes off if neither is active, and
when either becomes active we enable both. But that would reuquire
proper atomic modeset support, and probably a bit of extra care in
the order things get enabled.
v2: Reorder wrt. double wide handling changes
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
830 really does want the pipe A quirk. The planes and ports don't
react to any register writes unless the pipe currently attached
to them is running, so it's impossible to move them to the other
pipe unless both pipes are running.
Also it's documented that the DPLL must be enabled on both pipes
whenever it's needed.
This reverts commit ac6696d3236bd61503f89a1a99680fd7894d5d53.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The vbt on my Fujitsu-Siemens Lifebook S6010 provides two 800x600 modes,
60Hz and 56Hz. The magic register values we have correspond to the 60Hz
mode, and as I don't know how one would trick the VGA BIOS to set up
the 56Hz mode we can't get the magic values for the orther mode. So
when checking whether a mode is valid also check the pixel clock so that
we filter out the 56Hz variant.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In my earlier rewrite I missed a few important registers. Thomas Richter
noticed that they're needed to make his machine resume correctly.
Looks like IEGD does a one time init of these three registers. We don't
have a good one time init place in the ns2501 driver, so let's just
stick them into the .mode_set() hook and see if that helps things along.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Try to use the same programming sequence as used by the IEGD driver.
Also shovel the magic register values into a big static const array.
The register values are actually the based on what the BIOS programs
on the Fujitsu-Siemens Lifebook S6010. IEGD seemed to have hardcoded
register values (which also enabled the scaler for 1024x768 mode).
However those didn't actually work so well on the S6010. Possibly the
pipe timings that got used didn't match the ns2501 configuration.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Calling the mode_set hook on DPMS changes doesn't seem to be necessary
for ns2501. Just drop it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To more closely match the IEGD ns2501 driver behaviour, call the
mode_set hook while the DVO port is still disabled, then enable the DVO
port, and finally call the dpms hook.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On Fujitsu-Siememens S6010 the ns2501 chip is hooked up to DVOB instead
of DVOC.
FIXME: Maybe need to dig out the correct DVO port from VBT
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Disable double wide even if the pipe quirk compels us to leave the
pipe running. Double wide has certain implications for the plane
assignments so best keep it off.
Also helps resuming from S3 on the Fujitsu-Siemens Lifebook S6010
when double wide was enabled prior to suspend.
We do leave the pixel clock ticking at the original rate which would
require double wide to be enabled. But since the planes are all disabled
I'm hoping that the overly fast clock won't cause any problems. Seems
to be fine so far.
v2: Disable double wide also when turning the pipe off
v3: Reorder wrt. force pipe B quirk
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just pass the intel_crtc around instead of dev_priv+pipe.
Also make intel_wait_for_pipe_off() static since it's only used in
intel_display.c.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
gen2/3 platforms have a boatload of rings we're not using. On my 830
the BIOS/hw can leave some of those "active" after resume which will
prevent c3 entry. The ring is apparently considered active whenever
head != tail even if the ring is disabled.
Disable and clear all such unused ringbuffers on init/resume.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
My 830 is unhappy with trickle feed enabled. The symptom is that
the image on the screen shifts a bit to right occasionally.
The BIOS initially disables trickle feed, but it gets reset during
suspend, so we need to re-disable it ourselves. Juse disable it
always.
Also disable it for all other gen2/3 platforms since we disable it
for all more recent platforms as well (until HSW that is). At least
my 855 doesn't seem to mind us doing this. I don't have gen3
hardware to test that.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The max watermark value for gen2 planes B and C is 0x1f, instead of
the 0x3f that plane A uses.
Also check against the max even if the pipe is disabled since the
FIFO size exceeds the plane B and C max watermark value.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This gets us out of our init code and out to userspace quite a bit
faster, but does open us up to some bugs given the state of our init
time locking.
v2: switch to async_schedule (Chris)
check with lockdep, seems happy (Jesse)
move hotplug enable flag set to fbdev_initial_config (Jesse)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Rebase on top of the dev_priv->enable_hotplug_processing
removal.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Follow the BDW example and apply the workarounds touching registers
which are saved in the context image through LRIs in the new
ring->init_context() hook.
This makes Mesa much happier and eg. glxgears doesn't hang after
the first frame.
Cc: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Add missing wa table initialization to avoid a functional
conflict with Arun's wa table debugfs support.]
Reviewed-by: "Barbalho, Rafael" <rafael.barbalho@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
At this point of the code the obj var is already NULL, so we don't
need to set it again to NULL.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
CHV wants even rps opcodes so print a warning of the
min/max/rpe/rp1 values are odd, and warn if an odd value
slips through to valleyview_set_rps() and truncate it to
an even value.
Also add a comment to chv_freq_opcode() to make sure no one
changes the code without considering this requirement.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
[danvet: Help git along in applying the patch, somehow it silently
ended up in the vlv init_gt_powersave function.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The batchbuffer that sets the render context state is submitted
in a different way, and from different places.
We needed to make both the render state preparation and free functions
outside accesible, and namespace accordingly. This mess is so that all
LR, LRC and Execlists functionality can go together in intel_lrc.c: we
can fix all of this later on, once the interfaces are clear.
v2: Create a separate ctx->rcs_initialized for the Execlists case, as
suggested by Chris Wilson.
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
v3: Setup ring status page in lr_context_deferred_create when the
default context is being created. This means that the render state
init for the default context is no longer a special case. Execute
deferred creation of the default context at the end of
logical_ring_init to allow the render state commands to be submitted.
Fix style errors reported by checkpatch. Rebased.
Signed-off-by: Thomas Daniel <thomas.daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
BDW supports GT C0 residency reporting in constant time unit. Driver
calculates GT utilization based on C0 residency and adjusts RP
frequency up/down accordingly. For offscreen workload specificly,
set frequency to RP0.
Offscreen task is not restricted by frame rate, it can be
executed as soon as possible. Transcoding and serilized workload
between CPU and GPU both need high GT performance, RP0 is a good
option in this case. RC6 will kick in to compensate power
consumption when GT is not active.
v2: Rebase on recent drm-intel-nightly
v3: Add flip timerout monitor, when no flip is deteced within
100ms, set frequency to RP0.
Signed-off-by: Daisy Sun <daisy.sun@intel.com>
[torourke: rebased on latest and resolved conflict]
Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
init_clock_gating() is too late to read out the mem_freq. We already
want to print out the GPU MHz numbers before it's called. Move the
mem_freq setup to init_gt_powersave().
v2: Also kill the CHV_CZ_CLOCK_FREQ_MODE_* defines
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the pixel_size we got from drm_format_plane_cpp() instead of
fb->bits_per_pixel/8 when computing the primary plane page/linear
offsets. Avoids a few divs and makes the code more future proof
against funky pixel formats where bits_per_pixel isn't well defined.
This is what we already did in the sprite code.
Note that the relevant sprite patch was
commit ca320ac456
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Dec 19 12:14:22 2012 +0000
drm/i915: Use pixel size for computing linear offsets into a sprite
This change was required on sprites because they support yuv formats
which have fb->bits_per_pixel undefined.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add Chris' software archeology as a note to the commit
message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
During driver init we may not have a valid framebuffer for the primary
plane even though the plane is enabled due to failed BIOS fb takeover.
This means we have to avoid dereferencing the fb in
.update_primary_plane() when disabling the plane.
The introduction of the primary plane rotation in
commit d91a2cb8e5104233c02bbde539bd4ee455ec12ac
Author: Sonika Jindal <sonika.jindal@intel.com>
Date: Fri Aug 22 14:06:04 2014 +0530
drm/i915: Add 180 degree primary plane rotation support
caused a regression by trying to look up the pixel format before we can
be sure there's a valid fb available. This isn't entirely unsurprising
since the rotation patches originally predate the change to the primary
plane code that calls .update_primary_plane() also when disabling the
plane:
commit fdd508a641
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Aug 8 21:51:11 2014 +0300
drm/i915: Call .update_primary_plane in intel_{enable,
disable}_primary_hw_plane()
v2: Warn but don't blow up when trying to enable a plane w/o an fb (Chris)
Cc: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The workarounds that are applied are exported to a debugfs file;
this is used to verify their state after the test case (reset or
suspend/resume etc). This patch is only required to support i-g-t.
Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For BDW workarounds are currently initialized in init_clock_gating() but
they are lost during reset, suspend/resume etc; this patch moves the WAs
that are part of register state context to render ring init fn otherwise
default context ends up with incorrect values as they don't get initialized
until init_clock_gating fn.
v2: Add workarounds to golden render state
This method has its own issues, first of all this is different for
each gen and it is generated using a tool so adding new workaround
and mainitaining them across gens is not a straightforward process.
v3: Use LRIs to emit these workarounds (Ville)
Instead of modifying the golden render state the same LRIs are
emitted from within the driver.
v4: Use abstract name when exporting gen specific routines (Chris)
For: VIZ-4092
Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
According to spec FBC on BDW and HSW are identical without any gaps.
So let's copy the nuke and let FBC really start compressing stuff.
Without this patch we can verify with false color that nothing is being
compressed. With the nuke in place and false color it is possible
to see false color debugs.
Unfortunatelly on some rings like BCS on BDW we have to avoid Bits 22:18 on
LRIs due to a high risk of hung. So, when using Blt ring for frontbuffer rend
cache would never been cleaned and FBC would stop compressing buffer.
One alternative is to cache clean on software frontbuffer tracking.
v2: Fix rebase conflict.
v3: Do not clean cache on BCS ring. Instead use sw frontbuffer tracking.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Try to avoid confusion with ARRAY_SIZE()/2 and hdmi_level*2.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Resolve silent patch conflict (didn't even fail to build)
with with Sonika's preceding patch to use the
hsw_ddi_translations_fdi table to driver the fdi link training
iteration loop. Also drop the double-write loop Damien spotted.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Renaming the HSW-specific macros for ddi buffer translation slot to denote the
slot and not the vswing/pre-emph values as they are platform-dependent.
This patch is based on top of the patch series for renaming the DP training
vswing/pre-emph defines:
http://lists.freedesktop.org/archives/intel-gfx/2014-August/050407.html
v2: Creating single macro with argument for slot number (Damien)
v3: Adding macro for num of translation entries (Damien)
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Previously, it was possible for the GPU memory accesses to be swizzled
to try to optimize the fetches for tiled buffers. This swizzling was on
top of what the memory controller in the uncore already does.
With broadwell, we drop that GPU side swizzling, and the corresponding
initialization in 3 units (GAM, GT, DE). All those bits are reserved, as
specs put it:
Before Gen8, there was a historical configuration control field to
swizzle address bit[6] for in X/Y tiling modes. This was set in three
different places: TILECTL[1:0], ARB_MODE[5:4], and
DISP_ARB_CTL[14:13]"
For Gen8 the swizzle fields are all reserved, and the CPU's memory
controller performs all address swizzling modifications.
This also means that user space doesn't have to manually swizzle when
accessing tiled buffers from the CPU, and so we always return
I915_BIT_6_SWIZZLE_NONE from i915_gem_detect_bit_6_swizzle(), which
short-circuits the initialization of the registers mentionned above in
i915_gem_init_swizzling().
v2: Refine the explanation a bit more (Daniel)
v3: Make it BDW+ specific (Steve)
Cc: Steve Aarnio <steve.j.aarnio@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Keep the actual code to set the tiling bits for now, in case
some bios escaped to the wild that uses this - we'd need it for
fastboot.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of going through hoops, just put the driver author directly as
DRM_AUTHOR() argument. This will also make it consistent when we add
Intel to the list.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fix assert_panel_unlocked for vlv/chv, and improve it a bit for
non-LVDS. Also don't pretend it works for DDI. There's still work to do
to get this right for eDP on PCH platforms, but this is a start.
v2: WARN_ON(HAS_DDI)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The patch introduces fixes for the debugfs attributes emitted by
the i915 driver for GEN8. Currently, it is not emitting the correct
attributes which include the status of RC6 states.
Change-Id: Ib2068a0cac9a5wq3f228e547fa1a097ad369d242df
Signed-off-by: Vedang Patel <vedang.patel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rather than describing an object as either "snooped or LLC", we can do
better as we should know what machine we are running on!
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>
On BDW we're seeing a problem that after we runtime resume, the
outputs connected to DDI C are not detected: they don't appear in the
SDEISR register and GMBUS transactions don't work. They stop working
at the moment we call intel_opregion_notify_adapter() during runtime
suspend, but they don't go back to work when we call the same function
during runtime resume. They only work after we do a modeset and call
intel_opregion_notify_encoder(), but this point is already too late.
While debugging, I tried to pass PCI_D3hot which is the value that
matches the spec, and it seems to have solved the problem. I couldn't
find any explanation of why this solves the problem, but there's also
no documented explanation - besides our code and git log - of why
Haswell should use PCI_D1, so keep this for now in order to keep BDW
runtime PM working.
Also add a comment to point the fact that there's no spec documenting
all the weirdness involved here.
Cc: kristen.c.accardi@intel.com
Testcase: igt/pm_rpm/drm-resources-equal
Testcase: igt/pm_rpm/i2c
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Because CHV uses cherryview_init_clock_gating instead of
gen8_init_clock_gating.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Because BDW has WPT, which is equivalent to LPT. This is just like the
CPT/PPT case.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the correct mask for the unlock bits. In theory this could have lead
to incorrect asserts but this is unlikely in practise.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-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>
These two functions make no sense in an Logical Ring Context & Execlists
world.
v2: We got rid of lrc_enabled and centralized everything in the sanitized
i915.enable_execlists instead.
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
v3: Rebased. Corrected a typo in comment for i915_switch_context and
added a comment that it should not be called in execlist mode. Added
WARN_ON if i915_switch_context is called in execlist mode. Moved check
for execlist mode out of i915_switch_context and into callers. Added
comment in context_reset explaining why nothing is done in execlist
mode.
Signed-off-by: Thomas Daniel <thomas.daniel@intel.com>
[danvet: Simplify the patch subject so I can understand it.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Programing GT IER interrupts was fumbled while enabling Interrupts for
gen8
We forgot to program PM IER interrupt in gen8_gt_irq_postinstall based
on the new re-worked interrupt routines.
v2: Kill the loop and init GT interrupts individually (Ville)
Signed-off-by: Deepak S <deepak.s@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Adjust commit message as per discussion with Deepak.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A pending commit removes synchronous mode from switch_mm. This breaks
execlists because switch_mm will always try to write to the legacy ring
buffer.
Return immediately from i915_ppgtt_init_gw in execlists mode.
No longer check for execlists mode in gen8_ppgtt_enable() because this
will no longer be called in execlists mode.
Signed-off-by: Thomas Daniel <thomas.daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Be sure to always flush a stuck pageflip even if we couldn't possibly
expect one to be there.
References: https://bugs.freedesktop.org/show_bug.cgi?id=82612
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>
Unfortunately, the gem_obj/vma relationship is not symmetrical; a gem_obj
can look up for the same vma more than once (where the ppgtt refcount is
incremented), but will free the vma only once (i915_gem_free_object).
This difference in refcount get/put means that the ppgtt is not removed
after the context and vma are destroyed, because sometimes the refcount
will never go back to zero.
v2: Just move the ppgtt refcount into vma_create.
OTC-Jira: VIZ-3719
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Less pointless indentation is always nice. There will be a bit more
code in this function once the power sequencer locking is fixed.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we force vdd off warn if someone is still using it. With this
change the delayed vdd off work needs to check want_panel_vdd
itself to make sure it doesn't try to turn vdd off when someone
is using it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Looks nicer.
Not functional change.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Add "No functional change" as requested by Jani.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add a comment to explain why we care about the current want_panel_vdd
state in intel_dp_aux_ch().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
edp_* are now the lower level functions and intel_edp_* the higher level
ones. One should use them in pairs.
v2: Don't return void (Jani)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We want to use the higher level vdd on func here. Not a big deal
yet (we'd just get the warn when things go awry) but when the
locking gets fixed this becomes more important.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Passing the port as a parameter to PANEL_PORT_SELECT_VLV results in
neater code. Sadly the PCH port select bits aren't suitable for the
same treatment and the resulting macro would be much uglier, so
leave those defines as is.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A previous commit broke aliasing PPGTT for lrc, resulting in a kernel oops
on boot. Add a check so that is full PPGTT is not in use the context is
populated with the aliasing PPGTT.
Issue: VIZ-4278
Signed-off-by: Thomas Daniel <thomas.daniel@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In the move over to use BIOS connector configs, we lost the ability to
force a specific set of connectors on or off. Try to remedy that by
dropping back to the old behavior if we detect a hard coded connector
config that tries to enable a connector (disabling is easy!).
Based on earlier patches by Jesse Barnes.
v2: Remove Jesse's patch
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need do forcewake before Disabling RC6, This is what the BIOS
expects while going into suspend.
v2: updated commit message. (Daniel)
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Deepak S <deepak.s@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Improve the debug message that tells us we've been waiting for a vblank
that never arrived. Printing the pipe could lead a "doh!" moment where
we've been waiting for a vblank on a pipe that was off for instance.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Thomas Wood <thomas.wood@intel.com>
[danvet: Polish commit message a bit.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris has decided that enough is enough. It's time to fixup dev Vs
dev_priv. This is a modest contribution to the crusade.
v2: Still use INTEL_INFO(), for the (mythical!) case we want to hardcode
the info struct with defines (Chris)
Rename the macro argument from 'dev' to 'dev_priv' (Jani)
v3: Use names unlikely to be used as macro arguments (Chris)
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
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>
Since the ringbuffer does not belong per engine anymore, we have to
make sure that we are always recording the correct ringbuffer.
TODO: This is only a small fix to keep basic error capture working, but
we need to add more information for it to be useful (e.g. dump the
context being executed).
v2: Reorder how the ringbuffer is chosen to clarify the change and
rename the variable, both changes suggested by Chris Wilson. Also,
add the TODO comment to the code, as suggested by Daniel.
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For cleanliness, i915_error_object_create() was written to handle the
NULL pointer in a central location. The macro that wrapped it and passed
it a num_pages to use, was not safe. As we now never limit the num_pages
to use (we did so at one point to only capture the first page of the
context), we can remove the redundant macro and be NULL safe again.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For stolen pages, since it is verboten to access them directly on many
architectures, we have to read them through the GTT aperture. If they
are not accessible through the aperture, then we have to abort.
This was complicated by
commit 8b6124a633
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Jan 30 14:38:16 2014 +0000
drm/i915: Don't access snooped pages through the GTT (even for error capture)
and the desire to use stolen memory for ringbuffers, contexts and
batches in the future.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Make backlight class sysfs brightness 0 value switch off the backlight
for connectors that have the backlight_power callback defined. For eDP,
this has the similar caveats regarding power savings as bl_power as only
the power sequencer backlight control is switched off.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed_by: Clinton Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This lets the userspace switch off the backlight using the backlight
class sysfs bl_power file. The switch is done using the power sequencer;
the backlight PWM, and everything else, remains enabled. The display
backlight won't draw power, but for maximum power savings the encoder
needs to be switched off.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed_by: Clinton Taylor <Clinton.A.Taylor@intel.com>
Tested_by: Clinton Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Make backlight class sysfs bl_power a sub-state of backlight enabled, if
a backlight power connector callback is defined. It's up to the
connector callback to handle the sub-state, typically in a way that
respects panel power sequencing.
v2: Post the version that does not oops. *facepalm*.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed_by: Clinton Taylor <Clinton.A.Taylor@intel.com>
Tested_by: Clinton Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Make it possible to change panel power control backlight state without
touching the PWM. No functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed_by: Clinton Taylor <Clinton.A.Taylor@intel.com>
Tested_by: Clinton Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The GEN6_PM* registers don't exist on BDW anymore, so when we read
this file we trigger unclaimed register errors. The equivalent BDW
register for PMs is GEN8_GT_I*R(2), so use it.
Testcase: igt/pm_rpm/debugfs-read
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Primary planes support 180 degree rotation. Expose the feature
through rotation drm property.
v2: Calculating linear/tiled offsets based on pipe source width and
height. Added 180 degree rotation support in ironlake_update_plane.
v3: Checking if CRTC is active before issueing update_plane. Added
wait for vblank to make sure we dont overtake page flips. Disabling
FBC since it does not work with rotated planes.
v4: Updated rotation checks for pending flips, fbc disable. Creating
rotation property only for Gen4 onwards. Property resetting as part
of lastclose.
v5: Resetting property in i915_driver_lastclose properly for planes
and crtcs. Fixed linear offset calculation that was off by 1 w.r.t
width in i9xx_update_plane and ironlake_update_plane. Removed tab
based indentation and unnecessary braces in intel_crtc_set_property
and intel_update_fbc. FBC and flip related checks should be done only
for valid crtcs.
v6: Minor nits in FBC disable checks for comments in intel_crtc_set_property
and positioning the disable code in intel_update_fbc.
v7: In case rotation property on inactive crtc is updated, we return
successfully printing debug log as crtc is inactive and only property change
is preserved.
v8: update_plane is changed to update_primary_plane, crtc->fb is changed to
crtc->primary->fb and return value of update_primary_plane is ignored.
v9: added rotation property to primary plane instead of crtc. Removing reset
of rotation property from lastclose. rotation_property is moved to
drm_mode_config, so drm layer will take care of resetting. Adding updation of
fbc when rotation is set to 0. Allowing rotation only if value is
different than old one.
v10: Calling intel_primary_plane_setplane instead of update_primary_plane in
set_property(Daniel).
v11: Using same set_property function for both primary and sprite, Adding
primary plane specific code in the same function (Matt).
v12: Removing disabling/ enabling of fbc from set_property because it is done
from intel_pipe_set_base. Other formatting
v13: we need to call disable_fbc before changing the rotation to 180,
disable_fbc from intel_pipe_set_base gets called very late, that will
be used to re-enable fbc if rotation is set to 0 (Ville).
Testcase: igt/kms_rotation_crc
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Sagar Kamble <sagar.a.kamble@intel.com>
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
[danvet: Add FIXME to explain why we need the open-coded update_fbc
hunk to disable fbc when rotated 180 degree. And make checkpatch
happier.]
Acked-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This unifies how the primary plane functions work with how the sprite
functions works, which allows us to reuse them to update primary plane
properties.
v2: Moving setting of plane members in the end to take care of failure cases and
not-visible cases (Matt).
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Acked-by: Matt Roper <matthew.d.roper@intel.com>
[danvet: Add a real commit message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch is to address Daniels concerns over different code during reset:
http://lists.freedesktop.org/archives/intel-gfx/2014-June/047758.html
"The reason for aiming as hard as possible to use the exact same code for
driver load, gpu reset and runtime pm/system resume is that we've simply
seen too many bugs due to slight variations and unintended omissions."
Tested using igt drv_hangman.
V2: Cleaner way of preventing check_wedge returning -EAGAIN
V3: Clean the last_context during reset, to ensure do_switch() does the MI_SET_CONTEXT. As per review.
Signed-off-by: McAulay, Alistair <alistair.mcaulay@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
[danvet: Rebase over ctx->ppgtt rework and extend the comment in
check_wedge a bit.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As there should not be any other virtual device that might share buffers,
the callbacks remain empty stubs. Still prime can be used to transfer buffers
between processes that use qxl.
Signed-off-by: Andreas Pokorny <andreas.pokorny@canonical.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Two vmwgfx fixes, marked for stable as well
* 'vmwgfx-fixes-3.17' of git://people.freedesktop.org/~thomash/linux:
drm/vmwgfx: Fix a potential infinite spin waiting for fifo idle
drm/vmwgfx: Fix an incorrect OOM return value
Merge the move to generic fences for TTM using drivers.
* 'for-airlied-next' of git://people.freedesktop.org/~mlankhorst/linux:
drm/nouveau: use shared fences for readable objects
drm/nouveau: Keep only a single list for validation.
drm/ttm: use rcu in core ttm
drm/vmwgfx: use rcu in vmw_user_dmabuf_synccpu_grab
drm/radeon: use rcu waits in some ioctls
drm/nouveau: use rcu in nouveau_gem_ioctl_cpu_prep
drm/ttm: flip the switch, and convert to dma_fence
drm/qxl: rework to new fence interface
drm/nouveau: rework to new fence interface
drm/vmwgfx: rework to new fence interface, v2
drm/vmwgfx: get rid of different types of fence_flags entirely
drm/radeon: use common fence implementation for fences, v4
drm/ttm: kill off some members to ttm_validate_buffer
drm/ttm: add interruptible parameter to ttm_eu_reserve_buffers
drm/ttm: kill fence_lock
drm/ttm: call ttm_bo_wait while inside a reservation
drm/nouveau: require reservations for nouveau_fence_sync and nouveau_bo_fence
drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep
drm-intel-next-2014-08-22:
- basic code for execlist, which is the fancy new cmd submission on gen8. Still
disabled by default (Ben, Oscar Mateo, Thomas Daniel et al)
- remove the useless usage of console_lock for I915_FBDEV=n (Chris)
- clean up relations between ctx and ppgtt
- clean up ppgtt lifetime handling (Michel Thierry)
- various cursor code improvements from Ville
- execbuffer code cleanups and secure batch fixes (Chris)
- prep work for dev -> dev_priv transition (Chris)
- some of the prep patches for the seqno -> request object transition (Chris)
- various small improvements all over
* tag 'drm-intel-next-2014-09-01' of git://anongit.freedesktop.org/drm-intel: (86 commits)
drm/i915: fix suspend/resume for GENs w/o runtime PM support
drm/i915: Update DRIVER_DATE to 20140822
drm: fix plane rotation when restoring fbdev configuration
drm/i915/bdw: Disable execlists by default
drm/i915/bdw: Enable Logical Ring Contexts (hence, Execlists)
drm/i915/bdw: Document Logical Rings, LR contexts and Execlists
drm/i915/bdw: Print context state in debugfs
drm/i915/bdw: Display context backing obj & ringbuffer info in debugfs
drm/i915/bdw: Display execlists info in debugfs
drm/i915/bdw: Disable semaphores for Execlists
drm/i915/bdw: Make sure gpu reset still works with Execlists
drm/i915/bdw: Don't write PDP in the legacy way when using LRCs
drm/i915: Track cursor changes as frontbuffer tracking flushes
drm/i915/bdw: Help out the ctx switch interrupt handler
drm/i915/bdw: Avoid non-lite-restore preemptions
drm/i915/bdw: Handle context switch events
drm/i915/bdw: Two-stage execlist submit process
drm/i915/bdw: Write the tail pointer, LRC style
drm/i915/bdw: Implement context switching (somewhat)
drm/i915/bdw: Emission of requests with logical rings
...
Conflicts:
drivers/gpu/drm/i915/i915_drv.c
nouveau keeps track in userspace whether a buffer is being
written to or being read, but it doesn't use that information.
Change this to allow multiple readers on the same bo.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Maintain the original order to handle VRAM/GART/mixed correctly for <nv50,
it's likely not as important on newer cards.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
With the conversion to the reservation api this should be safe.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Final driver! \o/
This is not a proper dma_fence because the hardware may never signal
anything, so don't use dma-buf with qxl, ever.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Use the new fence interface on vmwgfx too.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
---
Changes since v1:
Fix a sleeping function called from invalid context in enable_signaling.
Only one type was ever used. This is needed to simplify the fence
support in the next commit.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
When intel_tv_detect() fails to do load detection it would forget to
drop the locks and clean up the acquire context. Fix it up.
This is a regression from:
commit 208bf9fdcd
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Mon Aug 11 13:15:35 2014 +0300
drm/i915: Fix locking for intel_enable_pipe_a()
v2: Make the code more readable (Chris)
v3: Drop WARN_ON(type < 0) (Chris)
Cc: stable@vger.kernel.org
Cc: Tibor Billes <tbilles@gmx.com>
Reported-by: Tibor Billes <tbilles@gmx.com>
Tested-by: Tibor Billes <tbilles@gmx.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
In the HPD pulse handler we check for long pulses if the port is actually
connected, however we do that for IBX, but we use the pulse handling code on
GM45 systems as well, so we need to use a diffent check.
This patch refactors the digital port connected check out of the g4x detection
path and reuses it in the hpd pulse path.
Fixes: http://lkml.kernel.org/r/1409382202.5141.36.camel@marge.simpson.net
Reported-by: Mike Galbraith <umgwanakikbuti@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The code waiting for fifo idle was incorrect and could possibly spin
forever under certain circumstances.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reported-by: Mark Sheldon <markshel@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Reivewed-by: Mark Sheldon <markshel@vmware.com>
Cc: <stable@vger.kernel.org>
At the same time, make error paths return early for clarity.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: jakob Bornecrantz <jakob@vmware.com>
Cc: <stable@vger.kernel.org>
Changes since v1:
- Kill the sw interrupt dance, add and use
radeon_irq_kms_sw_irq_get_delayed instead.
- Change custom wait function, lockdep complained about it.
Holding exclusive_lock in the wait function might cause deadlocks.
Instead do all the processing in .enable_signaling, and wait
on the global fence_queue to pick up gpu resets.
- Process all fences in radeon_gpu_reset after reset to close a race
with the trylock in enable_signaling.
Changes since v2:
- Small changes to work with the rewritten lockup recovery patches.
Changes since v3:
- Call radeon_fence_schedule_check when exclusive_lock cannot be
acquired to always cause a wake up.
- Reset irqs from hangup check.
- Drop reading seqno in the callback, use cached value.
- Fix indentation in radeon_fence_default_wait
- Add a radeon_test_signaled function, drop a few test_bit calls.
- Make to_radeon_fence global.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
This reorders the list to keep track of what buffers are reserved,
so previous members are always unreserved.
This gets rid of some bookkeeping that's no longer needed,
while simplifying the code some.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
No users are left, kill it off! :D
Conversion to the reservation api is next on the list, after
that the functionality can be restored with rcu.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
This is the last remaining function that doesn't use the reservation
lock completely to fence off access to a buffer.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
This will ensure we always hold the required lock when calling those functions.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Apart from some code inside ttm itself and nouveau_bo_vma_del,
this is the only place where ttm_bo_wait is used without a reservation.
Fix this so we can remove the fence_lock later on.
After the switch to rcu the reservation lock will be
removed again.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Some more fixes for 3.17, mostly stable material.
* tag 'drm-intel-fixes-2014-08-28' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Remove bogus __init annotation from DMI callbacks
drm/i915: don't warn if backlight unexpectedly enabled
drm/i915: Move intel_ddi_set_vc_payload_alloc(false) to haswell_crtc_disable()
drm/i915: fix plane/cursor handling when runtime suspended
drm/i915: Ignore VBT backlight presence check on Acer C720 (4005U)
The __init annotations for the DMI callback functions are wrong as this
code can be called even after the module has been initialized, e.g. like
this:
# echo 1 > /sys/bus/pci/devices/0000:00:02.0/remove
# modprobe i915
# echo 1 > /sys/bus/pci/rescan
The first command will remove the PCI device from the kernel's device
list so the second command won't see it right away. But as it registers
a PCI driver it'll see it on the third command. If the system happens to
match one of the DMI table entries we'll try to call a function in long
released memory and generate an Oops, at best.
Fix this by removing the bogus annotation.
Modpost should have caught that one but it ignores section reference
mismatches from the .rodata section. :/
Fixes: 25e341cfc3 ("drm/i915: quirk away broken OpRegion VBT")
Fixes: 8ca4013d70 ("CHROMIUM: i915: Add DMI override to skip CRT...")
Fixes: 425d244c86 ("drm/i915: ignore LVDS on intel graphics systems...")
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Duncan Laurie <dlaurie@chromium.org>
Cc: Jarod Wilson <jarod@redhat.com>
Cc: Rusty Russell <rusty@rustcorp.com.au> # Can modpost be fixed?
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
llocating memory for UVD create and destroy messages can fail, which is
rather annoying when this happens in the middle of a GPU reset. Try to
avoid this condition by preallocating a page for those dummy messages.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This improves concurrent stream decoding.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This avoid reading past the end of the list for certain modes
Signed-off-by: Y.C. Chen <yc_chen@aspeedtech.com>
Reviewed-by: Egbert Eich <eich@freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
I have tested the 6 patches send on mailing list since you merge the sti driver.
I haven't seen issue with those patches except for the missing
dependency on Kconfig
where I have change "depends on" to "select".
* 'drm-3.17-rc2-sti-fixes' of git://git.linaro.org/people/benjamin.gaignard/kernel:
drm: sti: Add missing dependency on RESET_CONTROLLER
drm: sti: Make of_device_id array const
drm: sti: Fix return value check in sti_drm_platform_probe()
drm: sti: hda: fix return value check in sti_hda_probe()
drm: sti: hdmi: fix return value check in sti_hdmi_probe()
drm: sti: tvout: fix return value check in sti_tvout_probe()
misc msm fixes from Rob.
* 'msm-fixes-3.17' of git://people.freedesktop.org/~robclark/linux:
drm/msm: Fix missing unlock on error in msm_fbdev_create()
drm/msm: fix compile error for non-dt builds
drm/msm/mdp4: request vblank during modeset
drm/msm: avoid flood of kernel logs on faults
More radeon changes for drm-next. Highlights:
- UVD support for older asics
- Reset rework in preparation for Maarten's fence patches
I have a few more patches which depend on Christian's ttm changes,
I'll send them out separately once you've merged the ttm changes.
* 'drm-next-3.18' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: drop doing resets in a work item
drm/radeon: drop RADEON_FENCE_SIGNALED_SEQ v2
drm/radeon: add timeout argument to radeon_fence_wait_seq v2
drm/radeon: handle lockup in delayed work, v5
drm/radeon: take exclusive_lock in read mode during ring tests, v5
drm/radeon: force fence completion only on problematic rings (v2)
drm/radeon: wake up all fences on manual reset
drm/radeon: add UVD fw names for older asic
drm/radeon: enable RB_ARB before resetting the VCPU
drm/radeon: 760G/780V/880V don't have UVD
drm/radeon: implement UVD hw workarounds for R6xx v3
drm/radeon: add UVD support for older asics v4
drm/radeon: add set_uvd_clocks callback for r6xx v4
drm/radeon: properly init UVD MC bits on R600
drm/radeon: force UVD buffers into VRAM on RS[78]80 v2
drm/radeon: move the IB test after the AGP fallback
Kinda unexpected, but DIV_ROUND_UP() can overflow if passed an argument
bigger than UINT_MAX - DIVISOR. Fix this by testing for "!cpp" before
using it in the following division.
Note that DIV_ROUND_UP() is defined as:
#define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
..this will obviously overflow if (n + d - 1) is bigger than UINT_MAX.
Reported-by: Tommi Rantala <tt.rantala@gmail.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If we assign a Radeon device to a virtual machine, we can no longer
assume a fixed hardware topology, like the GPU having a parent device.
This patch simply adds a few pci_is_root_bus() tests to avoid passing
a NULL pointer to PCI access functions, allowing the radeon driver to
work in a QEMU 440FX machine with an assigned HD8570 on the emulated
PCI root bus.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Blocking completely innocent processes with a GPU reset is
a pretty bad idea. Just set needs_reset and let the next
command submission or fence wait do the job.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
It's causing issues with VMID handling and comparing the
fence value two times actually doesn't make handling faster.
v2: rebased on reset changes
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This makes it possible to wait for a specific amount of time,
rather than wait until infinity.
v2 (chk): rebased on other changes
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
v5 (chk): complete rework, start when the first fence is emitted,
stop when the last fence is signalled, make it work
correctly with GPU resets, cleanup radeon_fence_wait_seq
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This is needed for the next commit, because the lockup detection
will need the read lock to run.
v4 (chk): split out forced fence completion, remove unrelated changes,
add and handle in_reset flag
v5 (agd5f): rebase fix
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Instead of resetting all fence numbers, only reset the
number of the problematic ring. Split out from a patch
from Maarten Lankhorst <maarten.lankhorst@canonical.com>
v2 (agd5f): rebase build fix
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Wake up all fences when we manually trigger a reset.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This fixes "UVD not responding, trying to reset the VCPU"
messages on earlier ASICs.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Don't enable UVD on these asics as they don't have
UVD hardware.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Only the essentials, cause this hw generation is really buggy.
v2: start supporting RV670,RV620 and RV635 as well
v3: activate more workarounds
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
