We access it through the cpu window. No functional difference expected
atm since we default to a bottom-up allocation scheme. But that might
eventually change so that we prefer the unmappable range for buffers
that don't need cpu gtt access.
Split out from Chris vma-bind rework.
Note that this is only possible due to the split-up of the mappable
pin flag into PIN_GLOBAL and PIN_MAPPABLE.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tighter code since legacy gem has only mappable anyway.
Split out from Chris vma-bind rework.
Note that this is only possible due to the split-up of the mappable
pin flag into PIN_GLOBAL and PIN_MAPPABLE.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Split out from Chris vma-bind rework.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With abitrary pin flags it makes sense to split out a "please bind
this into global gtt" from the "please allocate in the mappable
range".
Use this unconditionally in our global gtt pin helper since this is
what its callers want. Later patches will drop PIN_MAPPABLE where it's
not strictly needed.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Anything more than just one bool parameter is just a pain to read,
symbolic constants are much better.
Split out from Chris' vma-binding rework patch.
v2: Undo the behaviour change in object_pin that Chris spotted.
v3: Split out misplaced hunk to handle set_cache_level errors,
spotted by Jani.
v4: Keep the current over-zealous binding logic in the execbuffer code
working with a quick hack while the overall binding code gets shuffled
around.
v5: Reorder the PIN_ flags for more natural patch splitup.
v6: Pull out the PIN_GLOBAL split-up again.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is the same what we do for DP connectors, so make things more
consistent.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Atm we set the parent of the dp i2c device to be the correspondig
connector device. During driver cleanup we first remove the connector
device through intel_modeset_cleanup()->drm_sysfs_connector_remove() and
only after that the i2c device through the encoder's destroy callback.
This order is not supported by the device core and we'll get a warning,
see the below bugzilla ticket. The proper order is to remove first any
child device and only then the parent device.
The first part of the fix changes the i2c device's parent to be the drm
device. Its logical owner is not the connector anyway, but the encoder.
Since the encoder doesn't have a device object, the next best choice is
the drm device. This is the same what we do in the case of the sdvo i2c
device and what the nouveau driver does.
The second part creates a symlink in the connector's sysfs directory
pointing to the i2c device. This is so, that we keep the current ABI,
which also makes sense in case someone wants to look up the i2c device
belonging to a specific connector.
Reference: http://lists.freedesktop.org/archives/intel-gfx/2014-January/038782.html
Reference: http://lists.freedesktop.org/archives/intel-gfx/2014-February/039427.html
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70523
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since
commit d9255d5714
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Thu Sep 26 20:05:59 2013 -0300
it became clear that we need to separate the unload sequence into two
parts:
1. remove all interfaces through which new operations on some object
(crtc, encoder, connector) can be started and make sure all pending
operations are completed
2. do the actual tear down of the internal representation of the above
objects
The above commit achieved this separation for connectors by splitting
out the sysfs removal part from the connector's destroy callback and
doing this removal before calling drm_mode_config_cleanup() which does
the actual tear-down of all the drm objects.
Since we'll have to customize the interface removal part for different
types of connectors in the upcoming patches, add a new unregister
callback and move the interface removal part to it.
No functional change.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Coverity points out that, if we end up in the 'failed' label, that's
precisely because we couldn't retrieve a fixed mode (ie fixed_mode is
NULL) and then "if (fixed_mode)" is always false.
Remove that dead code.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It can be corrected later and may be what was actually desired, but
generally isn't, so if we find nothing is enabled, let the core DRM fb
helper figure something out.
v2: free the array too (Jesse)
Note that this also undoes any changes in case we bail out due to hw
cloning.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This will make the code more readable, and extensible which is needed
for upcoming feature work. Eventually, we'll do the same for init.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We have a couple of switch cases to compute the port value for the
VIDEO_DIP_CTL register. Replace them with a simple macro.
We do lose a few BUG() calls, but many people may consider that
an improvement.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... past the check for DRIVER_MODESET. Avoids races with userspace
opening a master and our sarea setup.
Cc: Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We assign the sarea_priv pointer only in the dma ioctl, which is
disallowed when kernel modesetting is enabled. So this is dead code.
Cc: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The BIOS or boot loader will generally create an initial display
configuration for us that includes some set of active pipes and
displays. This routine tries to figure out which pipes and connectors
are active and stuffs them into the crtcs and modes array given to us by
the drm_fb_helper code.
The overall sequence is:
intel_fbdev_init - from driver load
intel_fbdev_init_bios - initialize the intel_fbdev using BIOS data
drm_fb_helper_init - build fb helper structs
drm_fb_helper_single_add_all_connectors - more fb helper structs
intel_fbdev_initial_config - apply the config
drm_fb_helper_initial_config - call ->probe then register_framebuffer()
drm_setup_crtcs - build crtc config for fbdev
intel_fb_initial_config - find active connectors etc
drm_fb_helper_single_fb_probe - set up fbdev
intelfb_create - re-use or alloc fb, build out fbdev structs
v2: use BIOS connector config unconditionally if possible (Daniel)
check for crtc cloning and reject (Daniel)
fix up comments (Daniel)
v3: use command line args and preferred modes first (Ville)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Re-add the WARN_ON for a missing encoder crtc - the state
sanitizer should take care of this. And spell-ocd the comments.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This allows drivers to use them in custom initial_config functions.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just a bit of polish which I hope will help me with massaging some
internal patches to use Imre's reworked pipestat handling:
- Don't check for underrun reporting or enable pipestat interrupts
twice.
- Frob the comments a bit.
- Do the iir PIPE_EVENT to pipe mapping explicitly with a switch. We
only have one place which does this, so better to make it explicit.
v2: Ville noticed that I've broken the logic a bit with trying to
avoid checking whether we're interested in a given pipe twice. push
the PIPESTAT read down after we've computed the mask of interesting
bits first to avoid that duplication properly.
v3: Squash in fixups from Imre on irc.
Cc: Imre Deak <imre.deak@intel.com>
Cc: 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>
We want to reuse this in the fbdev initial config code independently
from any fastboot hacks. So allow a bit more flexibility.
v2: Forgot to git add ...
v3: make non-static (Jesse)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We want to do this early on before we try to fetch the plane config,
which depends on some of the pipe config state.
Note that the important part is that we do this before we initialize
gem, since otherwise we can't properly pre-reserve the stolen memory
for framebuffers inherited from the bios.
v2: split back out from get_plane_config change (Daniel)
update for recent locking & reset changes (Jesse)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Explain a bit more why we need to move this.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So far during driver unload we called drm_framebuffer_cleanup() for the
fbdev fb, which only removes the fb from the drm fb list regardless of
its reference count, but leaves the fb bound on an active crtc. Since
the fb's backing storage was freed this could mean we scan some random
memory content out afterwards. It's not a big issue since the fb is
allocated from stolen memory and afaik there is no other user for that
than i915. It's still cleaner to properly unbind the fb and disable the
crtc, which is what drm_framebuffer_remove() does.
Note that after
commit 88891eb1e9eca0ba619518bed31580f91e9cf84d
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Feb 10 18:00:38 2014 +0100
we call drm_framebuffer_cleanup() only after dropping the last reference
on the fb, but that won't happen since we don't unbind the fb. This
results in a drm core warn about a leaked fb.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Everything can be overridden by module parameters, so don't confuse the
users that are using them.
We have RC6 turned on for all platforms which support it, but Ironlake,
so the need to explain the situation is no longer pressing.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Deepak S <deepak.s@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It wasn't ever used by the caller anyway with the exception of what we
show in sysfs.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Deepak S <deepak.s@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Apply Deepak's suggestion.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
At one time, we though all future platforms would have the deeper RC6
states. As it turned out, they killed it after Ivybridge, and began
using other means to achieve the power savings (the stuff we need to get
to PC7+).
The enable function was left in a weird state of odd corner cases as a
result. Since the future is now, and we also have some insight into
what's currently the future, we have an opportunity to simplify, and
future proof the function.
NOTE: VLV will be addressed in a subsequent patch. This patch was trying
not to change functionality.
NOTE2: All callers sanitize the return value anyway, so this patch is
simply to have the code make a bit more sense.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Deepak S <deepak.s@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... and QUIRK_PIPEA_FORCE is not present.
I initially thought that case was impossible and just added a WARN on
it, but then I was told this case is possible due to
QUIRK_PIPEA_FORCE. So let's add a WARN that serves two purposes:
- tell us in case we have done something wrong;
- document the only case where we expect this.
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>
Add a nice comment explaining why we shouldn't wait for a vblank on
all cases, wait based on the HW gen, and add a comment saying we
should probably skip that wait on some of the previous HW gens.
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>
Now that we pass struct intel_crtc as an argument, we can check for
DSI inside the function, removing one more of those confusing boolean
arguments.
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>
Now that we pass struct intel_crtc as an argument, there's no need for
it.
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>
We want to remove those 3 boolean arguments. This is the first step.
The "pipe" passed as the argument is always intel_crtc->pipe.
Also adjust the function documentation.
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>
When I forked haswell_crtc_enable I copied all the code from
ironlake_crtc_enable. The last piece of the function contains a big
comment with a call to intel_wait_for_vblank. After this fork, we
rearranged the Haswell code so that it enables the planes as the very
last step of the modeset sequence, so we're sure that we call
intel_enable_primary_plane after the pipe is really running, so the
vblank waiting functions work as expected. I really believe this is
what fixes the problem described by the big comment, so let's give it
a try and get rid of that intel_wait_for_vblank, saving around 16ms
per modeset (and init/resume). We can always revert if needed :)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Because on Haswell, the pipe is never running at this point, so we hit
the 50ms timeout waiting for nothing. We already have two other places
where we wait for vblanks on haswell_crtc_enable, so we're safe.
This gets us rid of one instance of "vblank wait timed out" for each
mode set, which means driver init and resume are also 50ms faster.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Depending on the HW gen and the connector type, the pipe won't start
running right after we call intel_enable_pipe, so that
intel_wait_for_vblank call we currently have will just sit there for
the full 50ms timeout. So this patch adds an argument that will allow
us to avoid the vblank wait in case we want. Currently all the callers
still request for the vblank wait, so the behavior should still be the
same.
We also added a POSTING_READ on the register: previously
intel_wait_for_vblank was acting as a POSTING_READ, but now if
wait_for_vblank is false we'll stkip it, so we need an explicit
POSTING_READ.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of modifying intel_panel in lvds_init_connector/dsi_init/
edp_init_connector, making changes to move intel_panel->downclock_mode
initialization to intel_panel_init()
v2: Jani's review comments incorporated
Removed downclock_mode local variable in dsi_init and
edp_init_connector
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Signed-off-by: Pradeep Bhat <pradeep.bhat@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Can be expanded up on to include all sorts of things (HDMI infoframe
data, more DP status, etc). Should be useful for bug reports to get a
baseline on the display config and info.
v2: use seq_putc (Rodrigo)
describe mode field names (Rodrigo)
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just like we have for connector type etc.
v2: drop static array (Chris)
v3: add kdoc (Daniel)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For use by get_plane_config.
v2: cleanup tile_height bits (Chris)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In Jesse's patch to switch the fbdev framebuffer from an embedded
struct to a pointer the kfree in case of an error was missed. Fix this
up by using our own internal fb allocation helper directly instead of
reinventing that wheel.
We need a to_intel_framebuffer cast unfortunately since all the other
callers of _create still look better whith using a drm_framebuffer as
return pointer.
v2: Add an unlocked __intel_framebuffer_create function since our
dev->struct_mutex locking is too much a mess. With ppgtt we even need
it to take a look at the global gtt offset of pinned objects, since
the vma list might chance from underneath us. At least with the
current global gtt lookup functions. Reported by Mika.
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that it's a normally kmalloce buffer we can use the usual cleanup
paths. The upside here is that if we get the refcounting wrong will be
able to catch it, since the drm core will complain about leftover
framebuffers and kref about underflows.
v2: Kill intel_framebuffer_fini - no longer needed now that we
refcount all fbs properly and only confusing.
v3: We actually still need to call unregister_private to remove the fb
from the idr and drop the idr reference - the final unref doesn't do
that. So much for remembering my own fb liftime rules. Reported by
Imre Deak.
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we can't actually determine at run-time we have a fused-off display,
provide at least an option to disable it.
v2: Move the i915.disable_display test in a separate check
(Daniel Vetter)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
FUSE_STRAP has a bit to inform us that the display has been fused off.
Use it to setup the definitive number of pipes at run-time.
v2: actually tweak num_pipes, not num_planes
v3: also tests SFUSE_STRAP bit 7
v4: rebase on top of drm-nightly
use DRM_INFO() for the message telling display is fused off
try to read the FUSE_LOCK bit to determine if PCH display is disabled
v5: Don't read SFUSE_STRAP (register on the PCH) if num_pipes is already 0
from the initial device info struct (to prevent hangs) (Daniel Vetter)
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> (for v3)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (for v3)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Arjan van de Ven reported that on his test machine that he was seeing
stalls of greater than 1 frame greatly impacting the user experience. He
tracked this down to being the locked flush during a pagefault as being
the culprit hogging the struct_mutex and so blocking any other user from
proceeding. Stalling on a pagefault is bad behaviour on userspace's
part, for one it means that they are ignoring the coherency rules on
pointer access through the GTT, but fortunately we can apply the same
trick as the set-to-domain ioctl to do a lightweight, nonblocking flush
of outstanding rendering first.
"Prior to the patch it looks like this
(this one testrun does not show the 20ms+ I've seen occasionally)
4.99 ms 2.36 ms 31360 __wait_seqno i915_wait_seqno i915_gem_object_wait_rendering i915_gem_object_set_to_gtt_domain i915_gem_fault __do_fault handle_
+pte_fault handle_mm_fault __do_page_fault do_page_fault page_fault
4.99 ms 2.75 ms 107751 __wait_seqno i915_gem_wait_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret
4.99 ms 1.63 ms 1666 i915_mutex_lock_interruptible i915_gem_fault __do_fault handle_pte_fault handle_mm_fault __do_page_fault do_page_fault page_fa
+ult
4.93 ms 2.45 ms 980 i915_mutex_lock_interruptible intel_crtc_page_flip drm_mode_page_flip_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_
+sysret
4.89 ms 2.20 ms 3283 i915_mutex_lock_interruptible i915_gem_wait_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret
4.34 ms 1.66 ms 1715 i915_mutex_lock_interruptible i915_gem_pwrite_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret
3.73 ms 3.73 ms 49 i915_mutex_lock_interruptible i915_gem_set_domain_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret
3.17 ms 0.33 ms 931 i915_mutex_lock_interruptible i915_gem_madvise_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret
2.97 ms 0.43 ms 1029 i915_mutex_lock_interruptible i915_gem_busy_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret
2.55 ms 0.51 ms 735 i915_gem_get_tiling drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret
After the patch it looks like this:
4.99 ms 2.14 ms 22212 __wait_seqno i915_gem_wait_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret
4.86 ms 0.99 ms 14170 __wait_seqno i915_gem_object_wait_rendering__nonblocking i915_gem_fault __do_fault handle_pte_fault handle_mm_fault __do_page_
+fault do_page_fault page_fault
3.59 ms 1.31 ms 325 i915_gem_get_tiling drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret
3.37 ms 3.37 ms 65 i915_mutex_lock_interruptible i915_gem_wait_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret
2.58 ms 2.58 ms 65 i915_mutex_lock_interruptible i915_gem_do_execbuffer.isra.23 i915_gem_execbuffer2 drm_ioctl i915_compat_ioctl compat_sys_ioctl
+ia32_sysret
2.19 ms 2.19 ms 65 i915_mutex_lock_interruptible intel_crtc_page_flip drm_mode_page_flip_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_
+sysret
2.18 ms 2.18 ms 65 i915_mutex_lock_interruptible i915_gem_busy_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret
1.66 ms 1.66 ms 65 i915_gem_set_tiling drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret
It may not look like it, but this is quite a large difference, and I've
been unable to reproduce > 5 msec delays at all, while before they do
happen (just not in the trace above)."
gem_gtt_hog on an old Pineview (GMA3150),
before: 4969.119ms
after: 4122.749ms
Reported-by: Arjan van de Ven <arjan.van.de.ven@intel.com>
Testcase: igt/gem_gtt_hog
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Atm we call the handlers for pending pipestat interrupt events even if
they aren't explicitly enabled by i915_enable_pipestat(). This isn't an
issue for events other than the vblank start event, since those are
always enabled anyways. Otoh, we enable the vblank start event
on-demand, so we'll end up calling the vblank handler at times when they
are disabled.
I haven't checked if this causes any real problem, but for consistency
and to remove some overhead we should still fix this by clearing /
handling only the enabled interrupt events. Also this is a dependency
for the upcoming VLV power domain patchset where we need to disable all
the pipestat interrupts whenever the display power well is off.
v2:
- inline the status->enable mask mapping (Ville)
- don't check for invalid PSR bit on platforms other than VLV (Ville)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Frob conflict due to different merge order.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
At least on VLV we can't get at the pipestat status bits by simply right
shifting the corresponding enable bits. The mapping between enable and
status bits for the sprite0,1 flip done and the PSR events don't follow
this rule, so we need to map them separately.
The PSR enable for pipe A is DPFLIPSTAT[22], but I haven't added support
for this, since there is no user of it atm. Until support is added WARN
if someone tries to enable PSR interrupts, or tries to enable the same
(1 << 6) bit on pipe B, which MBZ.
v2:
- inline the status->enable mask mapping (Ville)
- fix bogus use of status bits in enable mask (Ville)
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>
There isn't any PSR interrupt enable bit for pipe A, so we couldn't
enable it through the current API. Passing the corresponding status bits
solves this and also makes the mapping between enable and status bits
simpler on VLV (addressed in an upcoming patch).
Except of checking for invalid status bit arguments, no functional
change.
v2: split out the low level parts of i915_enable_pipestat accepting
separate enabled and status masks, to make the non-standard mapping
between those masks stand out more (added in the next patch)
(Jesse,Daniel)
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>
Touching the VGA registers risks a hard machine hang, at least on this
ivb machine after removing a conflicting efifb. This is more than likely
related to the discovery that VGA IO decode on the more recent PCH
platforms is terminally broken.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This has very little effect other than log the errors in case of failure,
and we then hope for the best.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Allocate this struct instead, so we can re-use another allocated
elsewhere if needed.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: WARN_ON if there's no backing storage attached to an fb,
that's a bug.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When we detect that the user passed along an invalid handle or object,
we emit a warning as an aide for debugging. Since these are indeed only
for debugging user triggerable errors (and the errors are reported back
to userspace by the errno), the messages should only be at the debug
level and not claiming that there is a catastrophic error in the
driver/hardware.
References: https://bugs.freedesktop.org/show_bug.cgi?id=74704
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We had 2 set of defines for the same register, so make it one.
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And rename it to num_sprites as this value doesn't count the primary
plane.
This limit lives with num_pipes really, and now that dev_priv->info is
writable we can put it there instead.
While at it, introduce a intel_device_info_runtime_init() where we'll be
able to gather the device info fields at run-time.
v2: rename num_plane to num_sprites (Ville Syrjälä)
v3: rebase on top of latest drm-nightly
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> (for v2)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (for v2)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Turns out it'd be nice to change some device information at run-time or simply
have some code to fill in the info struct instead of having to declare the
values in 30+ structures.
What prompted this change is handling fused out display/pipe and tweaking
num_pipes at run-time, but I'm quite sure we'll find other flags/limits to
stick into dev_priv->info.
Most of the changes were done with a sed:
sed -i -e 's/dev_priv->info->/dev_priv->info./g' drivers/gpu/drm/i915/*[ch]
with a few tweaks to make it all work:
- Change the field definition in struct drm_i915_private
- adjust i915_dump_device_info()
- adjust i915_driver_load()
- adjust the INTEL_INFO() macro
v2: cast the info pointer returned by INTEL_INFO() to be const to catch
uses that would modify the structure post-initialization.
(Ville Syrjälä)
v3: Redo the patch onto latest drm-nightly,
Keep the info field const to catch post initialization writes
instead of the v2 solution,
Use a direct structure copy for the initial info initialization to
use the compiler type safety (Ville Syrjälä)
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> (for v2)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (for v2)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we make sure that all the dev_priv->info usages are wrapped by
INTEL_INFO(), we can easily modify the ->info field to be structure and
not a pointer while keeping the const protection in the INTEL_INFO()
macro.
v2: Rebased onto latest drm-nightly
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
According to Bspec we need to disable SF pipelined attribute fetch
whenever SF outputs exceed 16 and normal clip mode is used. A quick
glance at Mesa suggests that these conditions could happen. So let's
just always set the magic bit.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
sysfs changes to rps min and max delay were only triggering an update
of the rps interrupt limits if the active delay required an update.
This change ensures that interrupt limits are always updated.
v2: correct compile issue missed on rebase
v3: add igt testcases to signed-off-by section
Testcase: igt/pm_rps/min-max-config-idle
Testcase: igt/pm_rps/min-max-config-loaded
Signed-off-by: Jeff McGee <jeff.mcgee@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A check of rps/rc6 state after i915_reset determined that the ring
MAX_IDLE registers were returned to their hardware defaults and that
the GEN6_PMIMR register was set to mask all interrupts. This change
restores those values to their pre-reset states by re-initializing
rps/rc6 in i915_reset. A full re-initialization was opted for versus
a targeted set of restore operations for simplicity and maintain-
ability. Note that the re-initialization is not done for Ironlake,
due to a past comment that it causes problems.
Also updated the rps initialization sequence to preserve existing
min/max values in the case of a re-init. We assume the values were
validated upon being set and do not do further range checking. The
debugfs interface for changing min/max was updated with range
checking to ensure this condition (already present in sysfs
interface).
v2: fix rps logging to output hw_max and hw_min, not rps.max_delay
and rps.min_delay which don't strictly represent hardware limits.
Add igt testcase to signed-off-by section.
Testcase: igt/pm_rps/reset
Signed-off-by: Jeff McGee <jeff.mcgee@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As the VM do not track activity of objects and instead use a large
hammer to forcibly idle and evict all of their associated objects when
one is released, it is possible for that to cause a recursion when we
need to wait for free space on a ring and call retire requests.
(intel_ring_begin -> intel_ring_wait_request ->
i915_gem_retire_requests_ring -> i915_gem_context_free ->
i915_gem_evict_vm -> i915_gpu_idle -> intel_ring_begin etc)
In order to remove the requirement for calling retire-requests from
intel_ring_wait_request, we have to inline a couple of steps from
retiring requests, notably we have to record the position of the request
we wait for and use that to update the available ring space.
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 get a large number of bugs which have a, "hey I have that too"
because they see a GPU hang in dmesg. While two machines of the same
model having a GPU hang is indeed a coincidence, it is far from enough
evidence to suggest they are the same.
In order to reduce this effect, and hopefully get people to file new bug
reports, clearly the error message itself has been insufficient (see ref
at the bottom for a new bug report with this characteristic).
The algorithm is purposely pretty naive. I don't think we need much in
order to avoid the problem I am trying to solve, and keeping it naive
gives us some ability to make a decent test case.
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
References: https://bugs.freedesktop.org/show_bug.cgi?id=73276
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
s/FLIPDONE/FLIP_DONE/ to make all FLIP_DONE macro names consistent.
No functional change.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This will be used by other platforms too, so factor it out.
The only functional change is the reordeing of gmbus_irq_handler() wrt.
the hotplug handling, but since it only schedules a work, it isn't an
issue.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Don't keep on using the private_t typedef.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bspec and the code suggests that the interrupt signaled by IIR[7,5]
(DISPLAY_PIPE_A/B_VBLANK) is a first level IRQ flag for the second
level PIPEA/BSTAT[2] (Start of Vertical Blank) interrupt. Measuring
the relative timings of when IIR[7] and PIPEASTAT[1,2] get set and
checking the effect of unmasking different pipestat and IIR events
shows that this isn't so:
First, ISR/IIR[7] gets set independently of PIPEASTAT[18] (Start of
Vertical Blank Enable) or any other pipestat enable bit, so it isn't
a first level IRQ bit showing the state of PIPEASTAT[2], but is
connected directly to the timing generator.
Second, setting only PIPEASTAT[18] and leaving all other pipestat events
disabled, IIR[6] (DISPLAY_PIPE_A_EVENT) gets set close to the moment when
PIPEASTAT[2] gets set, so the former is a first level interrupt flag for
the latter. The bspec is rather unclear about this, but I also assume
that IIR[6] signals all pipestat A events, except PIPEASTAT[31] (FIFO
Under-run Status).
Third, IIR[7] is set close to the moment when PIPEASTAT[1] (Framestart
Interrupt) gets set, in the mode I used about 12usec after PIPEASTAT[2]
and IIR[6] gets set. This means the IIR[7] isn't marking the start of
vblank, but rather signals the framestart event.
Based on the above, we don't need to unmask IIR[7] when waiting for
start of vblank events, but we can rely on IIR[6] being always unmasked,
which will signal when PIPEASTAT[2] gets set. Doing this will also get
rid of the overhead of getting an interrupt and servicing IIR[7], which
is atm raised always some time after IIR[6]/PIPEASTAT[2] is raised.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
RFCv2: Reorganize array indexing so that full offsets can be used as
is. It makes grepping for registers in i915_reg.h much easier. Also
move offset arrays to intel_device_info.
v1: Fixed offsets for VLV, proper eDP handling
v2: Fixed BCLRPAT, PIPESRC, PIPECONF and DSP* macros.
v3: Added EDP pipe comment, removed redundant offset arrays for
MSA_MISC and DDI_FUNC_CTL.
v4: Rename patch and report object size increase.
v5: Change location of commas, add PIPE_EDP into enum pipe
v6: Insert PIPE_EDP_OFFSET into pipe offset array
v7: Set I915_MAX_PIPES back to 3, change more registers accessors
to use the new macros, get rid of _PIPE_INC and add dev_priv
as a parameter where required by the new macros.
Upcoming hardware will not have the various display pipe register
ranges evenly spaced in memory. Change register address calculations
into array lookups.
Tested on SNB, VLV, IVB, Gen2 and HSW w/eDP.
I left the UMS cruft untouched.
Size differences:
text data bss dec hex filename
596431 4634 56 601121 92c21 i915.ko (new)
593199 4634 56 597889 91f81 i915.ko (old)
Signed-off-by: Antti Koskipaa <antti.koskipaa@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since a purged buffer is one without any associated pages, attempting to
use it should generate EFAULT rather than EINVAL, as it is not strictly
an invalid parameter.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
EFAULT will be a possible return code where backing storage is
transient, such after it is purged by madvise. As such it is to be
expected and so should not trigger a WARN inside i915_gem_fault() but be
converted silently to SIGBUS.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When we enter RC6 and GFX Clocks are off, the voltage remains higher
than Vmin. When we try to set the freq to RPn, it might fail since the
Gfx clocks are down. So to fix this in Gfx idle, Bring the GFX clock up
and set the freq to RPn then move GFx down.
v2: remove vlv_update_rps_cur_delay function. Update commit message (Daniel)
v3: Fix the timeout during wait for gfx clock (Jesse)
v4: addressed comments on set freq and punit wait (Ville)
v5: use wait_for while waiting for GFX clk to be up. (Daniel)
update cur_delay before requesting min_delay. (Ville)
v6: use wait_for while waiting for punit. (Ville)
Signed-off-by: Deepak S <deepak.s@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As we seek the guilty batch using request and hangcheck
score, this code is not needed anymore.
v2: Rebase. Passing dev_priv instead of getting it from last_ring
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With full ppgtt using acthd is not enough to find guilty
batch buffer. We get multiple false positives as acthd is
per vm.
Instead of scanning which vm was running on a ring,
to find corressponding context, use a different, simpler,
strategy of finding batches that caused gpu hang:
If hangcheck has declared ring to be hung, find first non complete
request on that ring and claim it was guilty.
v2: Rebase
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73652
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Both Bspec and the W/A database state that WaDisablePSDDualDispatchEnable
is only needed for IVB GT1.
The only real confusion here is that the the W/A database also says to
write to the GT2 only register as well, which is strange if the W/A is
only for GT1.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
IVB GT2 has two registers for these things, and both must be written.
To add a bit more confusion both Bspec and the W/A database state that
WaDisablePSDDualDispatchEnable is only needed for IVB GT1, but the W/A
database also says to write even the second GT2 only register. So I
don't really know what the right thing here is.
Note that Bspec disagrees with the w/a database here, but Ville
confirmed (by asking Chris) that on gt1 the 2nd reg doesn't exist.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Add note as requested by Rodrigo.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We want to use the GTT for reading back objects upon an error so that we
have exactly the information that the GPU saw. However, it is verboten
to access snoopable pages through the GTT and causes my PineView GPU to
throw a page fault instead.
This has not been a problem in the past as we only dumped ringbuffers
and batchbuffers, both of which must be not snooped. However, the
introduction of HWS page dumping leads to a read of a snooped object
through the GTT. This was introduced by
commit f3ce382139
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Jan 23 22:40:36 2014 +0000
drm/i915: Include HW status page in error capture
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet:s/uncached/not snooped/ for one case in the commit message as
requested by Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Repeating the same information multiple times is just annoying.
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>
If we have stopped rings then we know that test is running
so no need for spam. In addition, only spam when default
context gets banned.
v2: - make sure default context ban gets shown (Chris)
- use helper for checking for default context, everywhere (Chris)
v3: - dont be quiet when debug is set (Ben, Daniel)
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=73652
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With full ppgtt support drm_i915_file_private gained knowledge
about the default context. Also reset stats are now inside
i915_hw_context so we can use proper abstraction.
v2: Move BUG_ON and WARN_ON to more proper locations (Ben)
v3: Pass dev directly to i915_context_is_banned to avoid the need to
dereference ctx->last_ring. Spotted by Mika when checking my
s/BUG/WARN/ change, I've missed this ->last_ring dereference.
Suggested-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> (v2)
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v2)
[danvet: s/BUG/WARN/]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The optimization helps IVB too. No piglit regression.
Signed-off-by: Chia-I Wu <olv@lunarg.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The optimization is available on Ivy Bridge and later, and is disabled by
default. Enabling it helps certain workloads such as GLBenchmark TRex test.
No piglit regression.
v2
- no need to save the register before suspend as init_clock_gating can
correctly program it after resume
- split IVB change to another commit
Signed-off-by: Chia-I Wu <olv@lunarg.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Rebased upon cleaned up error state
v3: Make sure hangcheck info remains last (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris:
Do we also want to capture?
GAC_ECO_BITS /* gen6,7 */
GAM_ECOCHK /* gen6,7 */
GAB_CTL /* gen6 */
GFX_MODE /* gen6 */
Requested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Moved num_requests up (Chris)
Rebased on new hws page capture which required a rename since it made
two members named, 'hws' in the per ring error state. (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This helps make an upcoming patch a bit more reviewable
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Create logical sections in an attempt to clean up, and continue to keep
future additions clean.
v2: Reworded the comments. Added section headers (Chris)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The code has become quite hairy. By relocating all the generic registers
it will become more obvious where future ones should go. There is still
admittedly a bit of confusion left for things like per ring registers.
A subsequent patch will clean this function up.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Backmerge drm-next - I need to backmerge drm-intel-fixes patches
touching the error capture code to be able to merge Ben's cleanup
patches.
Conflicts:
drivers/gpu/drm/i915/i915_gpu_error.c
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
more fixes for nouveau.
* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nouveau: resume display if any later suspend bits fail
drm/nouveau: fix lock unbalance in nouveau_crtc_page_flip
drm/nouveau: implement hooks for needed for drm vblank timestamping support
drm/nouveau/disp: add a method to fetch info needed by drm vblank timestamping
drm/nv50: fill in crtc mode struct members from crtc_mode_fixup
If either idling channels or suspending the fence were to fail, the
display would never be resumed. Also if a client fails, resume the fence
(not functionally important, but it would potentially leak memory).
See https://bugs.freedesktop.org/show_bug.cgi?id=70213
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Fixes a regression introduced by d5c1e84b3a
"drm/nouveau: hold mutex while syncing to kernel channel".
Cc: stable@vger.kernel.org #3.13
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The DRM uses the adjusted mode to calculate constants for vblank
timestamping. Our encoder mode_fixup (usually) replaces this data
with our backend mode information, which doesn't have the needed
data filled in already.
Reported-by: Mario Kleiner mario.kleiner.de@gmail.com
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Request by Ben Widawsky in his review of a patch touching this code.
v2: Clarify the disdinction between evicting vmas (to free up virtual
address space) and evicting objects (to free up actual system memory).
Suggested by Ben.
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Acked-by: Ben Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some DCE8 boards have a funky BlankCrtc table that results
in a timeout when trying to blank the display. The
timeout is harmless (all operations needed from the table
are complete), but wastes time and is confusing to users so
work around it.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=73420
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
This is effectively a revert of 4573388c92.
Forcing a display active when there is none causes problems with
dpm on some SI boards which results in improperly initialized
dpm state and boot failures on some boards. As for the bug commit
4573388c92 tried to address, one can manually force the state to
high for better performance when using the card as a headless compute
node until a better fix is developed.
bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=73788https://bugs.freedesktop.org/show_bug.cgi?id=69395
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
cc: stable@vger.kernel.org
During eviction, we are only considering how to free up space within the
current address space and not concerned with freeing up physical memory.
As such we need only skip nodes that pinned in the current VM and not
globally.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
DCE5 and newer hardware only has 1 DAC. Use the correct
offset. This may fix display problems on certain board
configurations.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
If we are not able to properly initialize one of the gpu
engines for buffer paging, we limit vram to the size of
the cpu visible aperture. We generally either use the gfx
or dma engine to do this. Clean up the size limiting code
to only adjust the size based on what ring is selected
for buffer paging rather than making assumptions about which
engine is selected for paging.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
The hw is buggy and it's not currently used, but it's
currently still initialized by the driver. Skip the init.
Skipping init also seems to improve stability with dpm on
some r6xx asics.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=66963
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Prevent runtime suspend of non-PX GPUs. Runtime suspend is
not what we want in those cases.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Otherwise we allocate a new VMID on nearly every submit.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The initial jiffies value can be non-0, so set the inital panel power
sequencer timestamps accordingly. This didn't cause a problem on 64 bit
machines but on 32 bit jiffies is initially -300*HZ, so if the panel
power is initally off in the call from edp_panel_vdd_on()->
wait_panel_power_cycle() we'd wait up to ~300 sec more than needed.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
schedule_timeout_uninterruptible() takes jiffies not ms.
v2:
- ignore the overflow issue, the practical part of that should
be solved instead in the caller (Chris)
Note that this issue was introduced in
commit dce56b3c62
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Thu Dec 19 14:29:40 2013 -0200
drm/i915: save some time when waiting the eDP timings
I've accidentally merged the broken v4 version of the patch (where
Jani noticed the issue [1]) instead of the v5, which was fixed [2].
[1] http://mid.gmane.org/87fvpnkgyg.fsf@intel.com
[2] http://mid.gmane.org/1388778311-2020-1-git-send-email-przanoni@gmail.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add admission of incompetence in the form of a note.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When current delay is already at max delay, Let's disable the PM UP
THRESHOLD INTRRUPTS, so that we will not get further interrupts until
current delay is less than max delay, Also request for the PM DOWN
THRESHOLD INTRRUPTS to indicate the decrease in clock freq. and
viceversa for PM DOWN THRESHOLD INTRRUPTS.
v2: Use bool variables (Daniel)
v3: Fix Interrupt masking bit (Deepak)
v4: Use existing symbolic constants in i915_reg.h (Daniel)
v5: Add pm interrupt mask after new_delay calculation (Ville)
Signed-off-by: Deepak S <deepak.s@intel.com>
[danvet: Pass new_delay by value as suggested by Ville. Also appease
checkpatch.]
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We're disabling a boatload of clock gating features on VLV. Maybe these
days we don't need to do that. At least I'm not aware of any workarounds
with this level of paranoia.
This reverts commit 4e8c84a5b1.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
WaDisable4x2SubspanOptimization isn't listed for VLV in the workaround
database, but BSpec says that the relevant bit must be set. Add a
comment to remind people of this.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Call gen7_setup_fixed_func_scheduler() on VLV as well.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
BSpec states that the thread override values set by
gen7_setup_fixed_func_scheduler() are invalid for HSW. So let's not
muck around with them.
Since gen7_setup_fixed_func_scheduler() now has two totally independent
parts, one for IVB and one for HSW, move the HSW part directly into
haswell_init_clock_gating().
Note tht there's another workaround by the name of
WaHSWVSRefCountFullforceMissDisable which basically claims that later
steppings don't need the fix, but since WaVSRefCountFullforceMissDisable
is listed to be needed for all steppings play it safe and keep applying
the workaround.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The current comments indicate that this function implements
WaVSRefCountFullforceMissDisable, which is only true for HSW.
The original purpose of the function is to implement
WaVSThreadDispatchOverride (and a bit more). Fix up the comments
to match reality.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
WaDisableTDLUnitClockGating is only relevant for early steppings of VLV.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
WaDisableVDSUtnitClockGating was only relevant for early steepings of
VLV.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These patches fix some issues caused by the DRM panel support from the
previous pull request and add two more panels (for the Toshiba AC100 as
well as the Seaboard and Ventana).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJS4TK6AAoJEN0jrNd/PrOhwXoP/i09xa9CKOnpy8Ewdmgi5gBt
vnjzqjwmHzZRpNeWw2xvcqzv5kKgXkpPdMhNUjErlJTUC1S6uCf/Uj+ExppYYysW
7uxNjPQQc6jgX+0342MabKITeZyTk9iEWPqTDtHDP5O2vXi4XSaQTMm9HpWGe1qZ
1CTb0yJc1epXGJPutlqhJSZgKwzrs6Pm2Q/nsTdxpGPAoTQj9J0NebDaZwJmmFGi
qNyfI4DVBp1sj8AgtUkQQn9x5oLDpdvHKLPHsAWgHnNTKqRxY8C0EL+S2TYGa812
sx8jvZgjvBoPuwaOr4hcOx91OFdfOoKVap9D/corU+UjstF9lTd+PvAHzZMO5qte
yQhWmYFn1gGr/I9b9K/mAB98s83W7lMmSs/7HtiawvLtogZ/t8xvSp94R7X8SGd1
wYcw3NqzgDxrcpJjDOsLIw1Pa4PxXoChtV0SfiaEoVlGn5WSONS/8cKeNwbO6e9D
gKkd/zvCMsYqHt7p8zDizcQKi4W+8zYiZySOfLohZzhf0qaoQnnD5yirfiIpljqA
Ql40F4XP3OF3CliikcSwFhvrTUCLb08Ol0MV6FX1H1iMae0dgiFqtz7AihFTbKHZ
PQeskMgEemxhIqKEsH0JcpV3+YxLRlWy/3I+OO7QczsL0xKD30FQ9Xhsu9EFx8gu
jXVvMDldeefaVBuTdqCb
=NfNj
-----END PGP SIGNATURE-----
Merge tag 'drm/for-3.14-rc1-20140123' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/tegra: Changes for v3.14-rc1 (update)
These patches fix some issues caused by the DRM panel support from the
previous pull request and add two more panels (for the Toshiba AC100 as
well as the Seaboard and Ventana).
* tag 'drm/for-3.14-rc1-20140123' of git://anongit.freedesktop.org/tegra/linux:
drm/tegra: Obtain head number from DT
drm/panel: update EDID BLOB in panel_simple_get_modes()
gpu: host1x: Remove unnecessary include
drm/tegra: Use proper data type
drm/tegra: Clarify how panel modes override others
drm/tegra: Fix possible CRTC mask for RGB outputs
drm/i915: Use drm_encoder_crtc_ok()
drm: Move drm_encoder_crtc_ok() to core
drm: provide a helper for the encoder possible_crtcs mask
drm/tegra: Don't check resource with devm_ioremap_resource()
drm/panel: Add support for Chunghwa CLAA101WA01A panel
drm/panel: Add support for Samsung LTN101NT05 panel
these 3 were checking in_interrupt but we have situations where
calling vunmap under this could cause a BUG to be hit in
smp_call_function_many. Use the drm_can_sleep macro instead,
which should stop this path from been taken in this case.
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Pile of -fixes all over the place. Lot's of cc: stable.
Only big thing is that we've dropped the preliminary hw support tag for
bdw - it seems to work. Which also means that I'll shovel a few more bdw
patches through -fixes, there's 5 w/a patches from Ken already on
intel-gfx.
* tag 'drm-intel-fixes-2014-01-28' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: Fix the offset issue for the stolen GEM objects
drm/i915: Decouple GPU error reporting from ring initialisation
i915: remove pm_qos request on error
Revert "drm/i915: Mask reserved bits in display/sprite address registers"
drm/i915: VLV2 - Fix hotplug detect bits
drm/i915: Allow reading the TIMESTAMP register on Gen8.
drm/i915: Repeat evictions whilst pageflip completions are outstanding
drm/i915: Wait for completion of pending flips when starved of fences
drm/i915: don't disable DP port after a failed link training
drm/i915: don't disable the DP port if the link is lost
drm/i915: Eliminate lots of WARNs when there's no backlight present
drm/i915: g4x/vlv: fix dp aux interrupt mask
drm/i915/ppgtt: Defer request freeing on reset
i915: send D1 opregion notification
drm/i915/bdw: remove preliminary_hw_support flag from BDW
drm/i915: Tune down reset_stat output from ERROR to debug
drm/i915: Make semaphore modparam RO
drm/i915: Fix disabled semaphores
drm/i915: Clarify relocation errnos
drm/i915: Spelling s/auxilliary/auxiliary/
Just one-liner which corrects a select statement for DRM_KMS_FB_HELPER
which looks like it was missed in the initial merge. Based on 3.13.
* 'drm-armada-fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-cubox: (55 commits)
DRM: armada: fix missing DRM_KMS_FB_HELPER select
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAABAgAGBQJSzqPyAAoJEPo9qoy8lh715MoP/i/70QZKPT4LxObqu+sVwqwp
YEksEOgPFJZoUeZSs/7d7jgN/52bM9LCrARakEJdN8q+VyNWymXyi84VYE+vZB/D
fHdDX5fTWsB09ORN2f4hRRPVJLr7kunJcMtNb3E0KTZKbDh6XOjdQ/pN+y6C9Gvt
TzLLW9uuqFeziG5UVwgFIUgA99Z8BQYe7EMqs0k44vygq5/SNRkh7dbfGTiXVCnr
NaMM1sa1MD3LW1Ec42StQ3bZDDE553V+SKWW3Xv7/x7kPQZmIs+wP+MxRa1DZGd1
a2acZvcDlbcp9Ea6UkErHxJKnWyW2ttqqTwljNvB88pJDFQ1RhNEslYMJCwDGDTn
BYE9lhYfYZp9X4rP4OOazB1OGafoWguz+CzRidxsV17RloTHTVIgCZVQCcVOMmPK
pPYUgVNHSJvo7kIaN0K/BEOSDYPyN92SAvdVlZMhE3blc2Zdu6R5l5uZ6TKmSlLs
wFqagyLelM0k4JlvVwkwkPTSh1tLUO2UAnFUeiW7sPJlBxg5kV5jOwsisK69v5db
arUkXXHO002L3P79LxCHqUIoRZG8FA73qRR6q2fqH4Yusq8GA0pWuNs31Ni5+Jha
jjdGV+GMEXeula6q5H/JBRUvBUuWqxrR592DDuWE/C1M4ZHym6S04lN2h3bg2XRb
4yK+RbzfyZh/D3pZg+98
=/Uwk
-----END PGP SIGNATURE-----
Merge tag 'omapdrm-3.14' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next
omapdrm patches for 3.14
* tag 'omapdrm-3.14' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux:
drm/omap: Enable DT support for DMM
drm/omap: fix: change dev_unload order
drm/omap: fix: disable encoder before destroying it
drm/omap: fix: disconnect devices when omapdrm module is removed
drm/omap: fix: Defer probe if an omapdss device requests for it at connect
drm/omap: fix (un)registering irqs inside an irq handler
Conflicts:
drivers/gpu/drm/omapdrm/omap_drv.c
Only two patches this time around. One trivial and one locking fix.
* 'gma500-next' of git://github.com/patjak/drm-gma500:
drm/gma500: Lock struct_mutex around cursor updates
drivers: gpu: Mark function as static in cdv_intel_dp.c
Add a few new debugfs files which allow changing the watermark memory
latency values during runtime. This can be used to determine the if the
original BIOS provided latency values are no good.
v2: Drop superfluous plane name from output
Take modeset locks around the latency value read/write
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Only early VLV steppings needed thist. Should no longer be relevant.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
WaApplyL3ControlAndL3ChickenMode is only relevant to early HSW
steppings..
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
WaDisableRCZUnitClockGating was needed with early HSW steppings only.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Someone copy pasted the comment from the SNB code w/o reading it.
We never actually implemented the workaround to disable RCPB unit
clock gating on IVB. It would have been needed for early steppings,
but we don't care about those anymore, so just remove the stale
comment.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
WaDisableRCCUnitClockGating is only relevant for SNB.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
WaDisableRCCUnitClockGating is only relevant for SNB.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Can't find any mention of WaDisableVDSUnitClockGating ever being
relevant for SNB. Remove it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There are cases where we want to know if there is a full, or aliased
PPGTT. Currently, in fact the only distinction we ever need to make is
when we're using full PPGTT.
This patch is simply to promote readability and clarify for the
confusing existing usage where "aliasing" meant aliasing and full.
v2: Remove USES_ALIASING_PPGTT since there are currently no cases where
we need to check if we're using aliasing, but not full PPGTT. (Daniel)
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The 'offset' field of the 'scatterlist' structure was wrongly
programmed with the offset value from the base of stolen area,
whereas this field indicates the offset from where the interested
data starts within the first PAGE pointed to by 'scattterlist'
structure. As a result when a new GEM object allocated from stolen
area is mapped to GTT, it could lead to an overwrite of GTT entries
as the page count calculation will go wrong, refer the function
'sg_page_count'.
v2: Modified the commit message. (Chris)
Signed-off-by: Akash Goel <akash.goel@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71908
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69104
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Commit 92b6f89f6b8f (drm: Add separate Kconfig option for fbdev helpers)
happened in parallel with the inclusion of Armada DRM into mainline,
and so missed this update. Add the necessary select statement to avoid
build errors.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Having to use i915.i915_foo is inconsistent and a bit on the verbose
side. Drop the prefix per Daniel's request, who also says this is not
ABI we need to maintain.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
At least I couldn't find it in the Haswell Bspec any more and we've
tried to test-boot a Haswell machine with num_pipes forced to 0 (i.e.
hit the PCH_NOP path) and the unclaimed register logic complained.
So restrict this dance to just ivb platforms.
v2: Art pointed out that the bits simply moved on hsw+
v3: Buy code terseneness with a notch of sublety as suggested by
Chris.
v4: Frob the right bit, spotted by Art.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Arthur Ranyan <arthur.j.runyan@intel.com>
Cc: Dave Airlie <airlied@gmail.com>
Reviewed-by: Art Runyan <arthur.j.runyan@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A lot of the WM functions are only reading from that structure and are
already using const. While converting the code to use dev_priv instead
of dev, I noticed a few places where we can give that hint.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With 20+ module parameters, I think referring to them via a struct
improves clarity over just having a bunch of globals. While at it, move
the parameter initialization and definitions into a new file
i915_params.c to reduce clutter in i915_drv.c.
Apart from the ill-named i915_enable_rc6, i915_enable_fbc and
i915_enable_ppgtt parameters, for which we lose the "i915_" prefix
internally, the module parameters now look the same both on the kernel
command line and in code. For example, "i915.modeset".
The downsides of the change are losing static on a couple of variables
and not having the initialization and module_param_named() right next to
each other. On the other hand, all module parameters are now defined in
one place at i915_params.c. Plus you can do this to find all module
parameter references:
$ git grep "i915\." -- drivers/gpu/drm/i915
v2:
- move the definitions into a new file
- s/i915_params/i915/
- make i915_try_reset i915.reset, for consistency
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
WaMiSetContext_Hang tells us that a MI_NOOP must follow MI_SET_CONTEXT.
The other thing WaMiSetContext_Hang seems to say is that URB_FENCE isn't
allowed to straddle two cachelines. But we don't issue those from the
kernel so we don't care.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
WaApplyL3ControlAndL3ChickenMode is only listed for IVB and HSW in
W/A database and BSpec.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The w/a database lists both WaPsdDispatchEnable and
WaDisablePSDDualDispatchEnable for VLV. They appear to be the same
thing, so list both names.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Many times in the past we have concluded that the cause of the GPU hang
has been that the hw status page was stale, usually because the GPU and
CPU disagreed over the address of the page. Having stumbled across yet
another issue that seems to be related to the HWSP, it is time to
include that information in the GPU error dump.
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>
Daniel Vetter
Imre Deak
Paulo Zanoni
Damien Lespiau
Jesse Barnes
Ben Widawsky
Ville Syrjälä
Vandana Kannan
Chris Wilson
Jeff McGee
Antti Koskipaa
Mika Kuoppala
Deepak S
Chia-I Wu
Dave Airlie
Ilia Mirkin
Maarten Lankhorst
Ben Skeggs
Alex Deucher
Christian König
Patrik Jakobsson
Akash Goel
Russell King
Jani Nikula