OSDN Git Service
Michele CURTI [Mon, 19 May 2014 15:18:52 +0000 (11:18 -0400)]
drm/radeon: use NULL instead of zero in object functions
Signed-off-by: Michele Curti <michele.curti@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Rafał Miłecki [Fri, 16 May 2014 09:10:31 +0000 (11:10 +0200)]
drm/radeon/hdmi: DCE2: simplify audio workaround
Thanks to advanced RE of fglrx we finally know what exactly needs to be
handled of AFMT change.
This has been tested for possible regressions on:
1) DCE2 HD2400 (RV610)
2) DCE3 HD3470 (RV620)
For a reference and details see:
https://bugzilla.kernel.org/show_bug.cgi?id=76231
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Rafał Miłecki [Fri, 16 May 2014 09:10:30 +0000 (11:10 +0200)]
drm/radeon/hdmi: DCE2: update setmode
Recent RE efforts revealed ops performed by fglrx during HDMI setup.
This mostly adds masks to r/w ops plus few single missing bits.
This has been tested for possible regressions on:
1) DCE2 HD2400 (RV610)
2) DCE3 HD3470 (RV620)
For a reference and details see:
https://bugzilla.kernel.org/show_bug.cgi?id=76231
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Rafał Miłecki [Fri, 16 May 2014 09:10:29 +0000 (11:10 +0200)]
drm/radeon/hdmi: DCE3: clean ACR control
What initially seemed to be a typo in fglrx (using register 0x740c
instead of 0x74dc) appeared to be a correct behavior. DCE3 has ACR and
CRC registers swapped which explains why we needed
WREG32(HDMI0_AUDIO_CRC_CONTROL + offset, 0x1000);
This has been tested for possible regressions on DCE3 HD3470 (RV620).
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Rafał Miłecki [Fri, 16 May 2014 09:36:24 +0000 (11:36 +0200)]
drm/radeon/hdmi: use separated file for DCE 3.1/3.2 code
DCE 3.1 and 3.2 should be programmed in a different way than DCE 2 and
DCE 3. The order of setting registers and sets of registers are
different.
It's still unsure how we will handle DCE 3.1 vs. DCE 3.2, since they
have few differences as well.
For now separate DCE 2 and DCE 3 path, so we can work on it without a
risk of breaking DCE 3.1+.
This has been tested for possible regressions on DCE32 HD4550 (RV710).
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Christian König [Sat, 10 May 2014 10:17:56 +0000 (12:17 +0200)]
drm/radeon: add proper support for RADEON_VM_BLOCK_SIZE v2
This patch makes it possible to decide how many address
bits are spend on the page directory vs the page tables.
v2: remove unintended change
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Christian König [Sat, 10 May 2014 10:17:55 +0000 (12:17 +0200)]
drm/radeon: add large PTE support for NI, SI and CIK v5
This patch implements support for VRAM page table entry compression.
PTE construction is enhanced to identify physically contiguous page
ranges and mark them in the PTE fragment field. L1/L2 TLB support is
enabled for 64KB (SI/CIK) and 256KB (NI) PTE fragments, significantly
improving TLB utilization for VRAM allocations.
Linear store bandwidth is improved from 60GB/s to 125GB/s on Pitcairn.
Unigine Heaven 3.0 sees an average improvement from 24.7 to 27.7 FPS
on default settings at 1920x1200 resolution with vsync disabled.
See main comment in radeon_vm.c for a technical description.
v2 (chk): rebased and simplified.
v3 (chk): add missing hw setup
v4 (chk): rebased on current drm-fixes-3.15
v5 (chk): fix comments and commit text
Signed-off-by: Jay Cornwall <jay@jcornwall.me>
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alex Deucher [Thu, 8 May 2014 14:58:04 +0000 (10:58 -0400)]
drm/radeon: add a i2c bus mutex
The i2c and aux buses use the same pads so add
a mutex to protect access to the pads.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Dave Airlie [Fri, 2 May 2014 01:09:54 +0000 (11:09 +1000)]
drm: add DP MST encoder type
This adds an encoder type for DP MST encoders.
Reviewed-by: Todd Previte <tprevite@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Jani Nikula [Wed, 14 May 2014 13:58:20 +0000 (16:58 +0300)]
drm: store encoder name in encoder struct
This makes drm_get_encoder_name() thread safe.
Reference: http://lkml.kernel.org/r/
645ee6e22cad47d38a2b35c21c8d5fe3@DC1-MBX-01\
.ptsecurity.ru
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Jani Nikula [Wed, 14 May 2014 13:58:19 +0000 (16:58 +0300)]
drm: store connector name in connector struct (v2)
This makes drm_get_connector_name() thread safe.
[airlied: fix to build.]
Reference: http://lkml.kernel.org/r/
645ee6e22cad47d38a2b35c21c8d5fe3@DC1-MBX-01.ptsecurity.ru
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Thierry Reding [Wed, 23 Apr 2014 13:49:04 +0000 (15:49 +0200)]
drm/dp: Add missing kernel-doc
Commit
9dc4056026e0 (drm/dp: let drivers specify the name of the I2C-
over-AUX adapter) introduced a new field but didn't add the proper
kernel-doc for it.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
David Herrmann [Sun, 25 May 2014 12:34:09 +0000 (14:34 +0200)]
drm/armada: use shmem helpers if possible
shmem_read_mapping_page() uses mapping_gfp_mask(mapping) as default gfp
mask. No reason to use shmem_read_mapping_page_gfp() directly if we want
the default behavior.
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
David Herrmann [Sun, 25 May 2014 12:34:08 +0000 (14:34 +0200)]
drm/gem: replace misleading comment
shmem supports page-relocations during swapin since quite some time. It
was implemented in:
commit
bde05d1ccd512696b09db9dd2e5f33ad19152605
Author: Hugh Dickins <hughd@google.com>
Date: Tue May 29 15:06:38 2012 -0700
shmem: replace page if mapping excludes its zone
The gem-comment about wrongly placed DMA32 pages is no longer valid.
Replace it with a proper comment but keep the BUG_ON() to verify correct
shmem behavior.
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>
Benoit Taine [Mon, 26 May 2014 15:21:22 +0000 (17:21 +0200)]
drm/edid: Use kmemdup instead of kmalloc + memcpy
This issue was reported by coccicheck using the semantic patch
at scripts/coccinelle/api/memdup.cocci
Signed-off-by: Benoit Taine <benoit.taine@lip6.fr>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Jean Delvare [Mon, 26 May 2014 12:52:13 +0000 (14:52 +0200)]
drm/shmobile: Add run-time dependencies
The shmobile DRM driver is only useful on SuperH and shmobile unless
build testing. I am dropping the SuperH dependencies though because
the driver doesn't even build there, so in practice it is an arm-only
driver for now.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Acked-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Jean Delvare [Mon, 26 May 2014 11:01:35 +0000 (13:01 +0200)]
drm/rcar-du: Add run-time dependencies
The Renesas R-Car Display Unit driver is only useful on shmobile
unless build testing. The LVDS output is useful on an even more
reduced hardware set.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Acked-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Daniel Vetter [Mon, 26 May 2014 21:44:42 +0000 (23:44 +0200)]
MAINTAINERS: Shovel drivers/gpu/vga/* to Dave
DRM is pretty much the main user of this stuff (if we ignore the sysfs
interface used by X, i.e. by the same gang of people writing the drm
drivers). So shovel it into Dave's responsibility to avoid patches
getting lost on lkml.
With this get_maintainers will rout vgaarb and switcheroo patches
correctly.
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: linux-kernel@vger.kernel.org
References: https://lkml.org/lkml/2014/5/25/94
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Sagar Kamble [Tue, 11 Mar 2014 14:25:29 +0000 (19:55 +0530)]
Documentation: drm: describing drm properties exposed by various drivers
Started documenting drm properties for drm drivers. This patch provides
information about properties in drm, i915, psb and cdv/gma-500. Information
about other properties can be added on top of these.
v2: Added description of drm properties in armada, exynos, i2c/ch7006, noveau,
omap, qxl, radeon, rcar-du
v3: Removed "Property Object" column since it is implementation related. Property
type column refined.[Ville's review comments]
v4: Removed whitespace warnings and minor nits. [Randy's review comments]
v5: Restructured output for ENUM properties
v6: Review comments on formatting the table. [Laurent's review comments]
v7: Minor restructuring. [Laurent's review comments]
Cc: Rob Landley <rob@landley.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Sagar Kamble <sagar.a.kamble@intel.com>
Cc: "Purushothaman, Vijay A" <vijay.a.purushothaman@intel.com>
Cc: linux-doc@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Sagar Kamble <sagar.a.kamble@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Alexandre Courbot [Fri, 23 May 2014 03:58:06 +0000 (12:58 +0900)]
drm/ttm: fix kerneldoc of ttm_bo_create
The kerneldoc header of ttm_bo_create() was referring to another
(nonexisting) function and had a few obsolete or incorrect arguments.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Daniel Thompson [Fri, 23 May 2014 15:01:43 +0000 (16:01 +0100)]
drm: Add 800x600 (SVGA) screen resolution to the built-in EDIDs
The 800x600 (SVGA) screen resolution was lacking in the set of
built-in selectable EDID screen resolutions that can be used to
repair misbehaving monitor firmware.
This patch adds the related data set and expands the documentation.
Note that the SVGA bit occupies a different byte to all the existing
users of the established timing bits forcing a rework of the
ESTABLISHED_TIMINGS_BITS macro.
Tested new EDID on an aged (and misbehaving) industrial LCD panel;
existing EDIDs still pass edid-decode's checksum checks.
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Carsten Emde <C.Emde@osadl.org>
Cc: linux-doc@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Masanari Iida [Thu, 15 May 2014 20:54:06 +0000 (13:54 -0700)]
Documentation: fix typos in drm docbook
Fix spelling typo in DocBook/drm.tmpl
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Rob Clark [Sat, 24 May 2014 18:30:10 +0000 (14:30 -0400)]
drm: fix typo
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Fri, 2 May 2014 01:05:21 +0000 (11:05 +1000)]
drm/dp_helper: add defines for DP 1.2 and MST support. (v2)
This just adds the defines from the DP 1.2 spec, which we
will use later.
fix some DP MST to 1.2 MST
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Todd Previte <tprevite@gmail.com>
Reviewed-by: Jingoo Han <jg1.han@samsung.com>
Dave Airlie [Mon, 19 May 2014 01:15:08 +0000 (11:15 +1000)]
Merge branch 'ast-updates' of ssh://people.freedesktop.org/~/linux into drm-next
Pull in latest updates to AST driver.
* 'ast-updates' of ssh://people.freedesktop.org/~/linux:
drm/ast: initial DP501 support (v0.2)
drm/ast: rename the mindwm/moutdwm and deinline them
drm/ast: resync the dram post code with upstream
drm/ast: add AST 2400 support.
drm/ast: add widescreen + rb modes from X.org driver (v2)
Dave Airlie [Fri, 28 Mar 2014 01:05:12 +0000 (11:05 +1000)]
drm/ast: initial DP501 support (v0.2)
This is the initial attempt at porting the DP501 code from the userspace
driver,
the firmware file is in
http://people.freedesktop.org/~airlied/ast_dp501_fw.bin
this should really be exposed as another encoder/connector that is cloneable
v0.2:
init 3rd tx properly,
add scratch reduction of VRAM size
backup firmware properly.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Fri, 28 Mar 2014 00:22:41 +0000 (10:22 +1000)]
drm/ast: rename the mindwm/moutdwm and deinline them
we'll need these elsewhere for dp501.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Fri, 17 Jan 2014 01:36:14 +0000 (11:36 +1000)]
drm/ast: resync the dram post code with upstream
This resyncs the dram post code with the upstream X.org driver
where ast have improved the code for setting up the dram chips.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Thu, 27 Mar 2014 23:18:45 +0000 (09:18 +1000)]
drm/ast: add AST 2400 support.
This is ported from the userspace driver.
Untested on any ast2400 hw so far.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Fri, 17 Jan 2014 00:56:09 +0000 (10:56 +1000)]
drm/ast: add widescreen + rb modes from X.org driver (v2)
This syncs up the mode code from the X.org driver upstream,
and adds the mode validation step for hw that doesn't have
widescreen.
v2: (from Egbert Eich <eich@suse.de)
squash drm/ast: Use correct structure member for mode validation
to avoid bisect regression.
In struct drm_display_mode crtc_hdisplay and crtc_vdisplay are holding
the crtc parameters after mode fixup. For validation we need hdisplay and
vdisplay.
Signed-off-by: Egbert Eich <eich@suse.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Sun, 18 May 2014 21:42:27 +0000 (07:42 +1000)]
Merge tag 'drm-intel-next-2014-05-06' of git://anongit.freedesktop.org/drm-intel into drm-next
- ring init improvements (Chris)
- vebox2 support (Zhao Yakui)
- more prep work for runtime pm on Baytrail (Imre)
- eDram support for BDW (Ben)
- prep work for userptr support (Chris)
- first parts of the encoder->mode_set callback removal (Daniel)
- 64b reloc fixes (Ben)
- first part of atomic plane updates (Ville)
* tag 'drm-intel-next-2014-05-06' of git://anongit.freedesktop.org/drm-intel: (75 commits)
drm/i915: Remove useless checks from primary enable/disable
drm/i915: Merge LP1+ watermarks in safer way
drm/i915: Make sure computed watermarks never overflow the registers
drm/i915: Add pipe update trace points
drm/i915: Perform primary enable/disable atomically with sprite updates
drm/i915: Make sprite updates atomic
drm/i915: Support 64b relocations
drm/i915: Support 64b execbuf
drm/i915/sdvo: Remove ->mode_set callback
drm/i915/crt: Remove ->mode_set callback
drm/i915/tv: Remove ->mode_set callback
drm/i915/tv: Rip out pipe-disabling nonsense from ->mode_set
drm/i915/tv: De-magic device check
drm/i915/tv: extract set_color_conversion
drm/i915/tv: extract set_tv_mode_timings
drm/i915/dvo: Remove ->mode_set callback
drm/i915: Make encoder->mode_set callbacks optional
drm/i915: Make primary_enabled match the actual hardware state
drm/i915: Move ring_begin to signal()
drm/i915: Virtualize the ringbuffer signal func
...
Dave Airlie [Fri, 16 May 2014 01:47:13 +0000 (11:47 +1000)]
Merge tag 'topic/core-stuff-2014-05-05' of git://anongit.freedesktop.org/drm-intel into drm-next
Update pull request with drm core patches. Mostly some polish for the
primary plane stuff and a pile of patches all over from Thierry. Has
survived a few days in drm-intel-nightly without causing ill.
I've frobbed my scripts a bit to also tag my topic branches so that you
have something stable to pull - I've accidentally pushed a bunch more
patches onto this branch before you've taken the old pull request.
* tag 'topic/core-stuff-2014-05-05' of git://anongit.freedesktop.org/drm-intel:
drm: Make drm_crtc_helper_disable() return void
drm: Fix indentation of closing brace
drm/dp: Fix typo in comment
drm: Fixup flip-work kerneldoc
drm/fb: Fix typos
drm/edid: Cleanup kerneldoc
drm/edid: Drop revision argument for drm_mode_std()
drm: Try to acquire modeset lock on panic or sysrq
drm: remove unused argument from drm_open_helper
drm: Handle ->disable_plane failures correctly
drm: Simplify fb refcounting rules around ->update_plane
drm/crtc-helper: gc usless connector loop in disable_unused_functions
drm/plane_helper: don't disable plane in destroy function
drm/plane-helper: Fix primary plane scaling check
drm: make mode_valid callback optional
drm/edid: Fill PAR in AVI infoframe based on CEA mode list
Dave Airlie [Fri, 2 May 2014 03:22:19 +0000 (13:22 +1000)]
drm: fix memory leak around mode_group (v2)
This mode group id_list was never being freed.
v2: take David's suggestion to free in minor_free.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Ville Syrjälä [Mon, 28 Apr 2014 12:53:25 +0000 (15:53 +0300)]
drm/i915: Remove useless checks from primary enable/disable
We won't be calling intel_enable_primary_plane() or
intel_disable_primary_plane() with the primary plane in the
wrong state. So remove the useless DISPLAY_PLANE_ENABLE checks.
v2: Convert the checks to WARNs instead (Daniel,Paulo)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Mon, 28 Apr 2014 12:44:57 +0000 (15:44 +0300)]
drm/i915: Merge LP1+ watermarks in safer way
On ILK when we disable a particular watermark level, we must
maintain the actual watermark values for that level for some time
(until the next vblank possibly). Otherwise we risk underruns.
In order to achieve that result we must merge the LP1+ watermarks a
bit differently since we must also merge levels that are to be
disabled. We must also make sure we don't overflow the fields in the
watermark registers in case the calculated watermarks come out too
big to fit.
As early as possbile we mark all computed watermark levels as
disabled if they would exceed the register maximums. We make sure
to leave the actual watermarks for such levels zeroed out. Then during
merging, we take the maxium values for every level, regardless if
they're disabled or not. That may seem a bit pointless since at the
moment all the watermark levels we merge should have their values
zeroed if the level is already disabled. However soon we will be
dealing with intermediate watermarks that, in addition to the new
watermark values, also contain the previous watermark values, and so
levels that are disabled may no longer be zeroed out.
v2: Split the patch in two (Paulo)
Use if() instead of & when merging ->enable (Paulo)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Fix commit message as noted by Paulo.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Mon, 28 Apr 2014 12:44:56 +0000 (15:44 +0300)]
drm/i915: Make sure computed watermarks never overflow the registers
When we calculate the watermarks for a pipe make sure we leave any
level fully zeroed out if it would exceed any of the maximum values
that fit in the registers.
This will be important later when we start to use also disabled
watermark levels during LP1+ merging.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 29 Apr 2014 10:35:48 +0000 (13:35 +0300)]
drm/i915: Add pipe update trace points
Add trace points for observing the atomic pipe update mechanism.
v2: Rebased due to earlier changes
v3: Pass intel_crtc instead of drm_crtc (Daniel)
v4: Pass frame counter from the caller to evaded/end since
the caller now always has that ready
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Sourab Gupta <sourabgupta@gmail.com>
Reviewed-by: Akash Goel <akash.goels@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 29 Apr 2014 10:35:47 +0000 (13:35 +0300)]
drm/i915: Perform primary enable/disable atomically with sprite updates
Move the primary plane enable/disable to occur atomically with the
sprite update that caused the primary plane visibility to change.
FBC and IPS enable/disable is left to happen well before or after
the primary plane change.
v2: Pass intel_crtc instead of drm_crtc (Daniel)
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Sourab Gupta <sourabgupta@gmail.com>
Reviewed-by: Akash Goel <akash.goels@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 29 Apr 2014 10:35:46 +0000 (13:35 +0300)]
drm/i915: Make sprite updates atomic
Add a mechanism by which we can evade the leading edge of vblank. This
guarantees that no two sprite register writes will straddle on either
side of the vblank start, and that means all the writes will be latched
together in one atomic operation.
We do the vblank evade by checking the scanline counter, and if it's too
close to the start of vblank (too close has been hardcoded to 100usec
for now), we will wait for the vblank start to pass. In order to
eliminate random delayes from the rest of the system, we operate with
interrupts disabled, except when waiting for the vblank obviously.
Note that we now go digging through pipe_to_crtc_mapping[] in the
vblank interrupt handler, which is a bit dangerous since we set up
interrupts before the crtcs. However in this case since it's the vblank
interrupt, we don't actually unmask it until some piece of code
requests it.
v2: preempt_check_resched() calls after local_irq_enable() (Jesse)
Hook up the vblank irq stuff on BDW as well
v3: Pass intel_crtc instead of drm_crtc (Daniel)
Warn if crtc.mutex isn't locked (Daniel)
Add an explicit compiler barrier and document the barriers (Daniel)
Note the irq vs. modeset setup madness in the commit message (Daniel)
v4: Use prepare_to_wait() & co. directly and eliminate vbl_received
v5: Refactor intel_pipe_handle_vblank() vs. drm_handle_vblank() (Chris)
Check for min/max scanline <= 0 (Chris)
Don't call intel_pipe_update_end() if start failed totally (Chris)
Check that the vblank counters match on both sides of the critical
section (Chris)
v6: Fix atomic update for interlaced modes
v7: Reorder code for better readability (Chris)
v8: Drop preempt_check_resched(). It's not available to modules
anymore and isn't even needed unless we ourselves cause
a wakeup needing reschedule while interrupts are off
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Sourab Gupta <sourabgupta@gmail.com>
Reviewed-by: Akash Goel <akash.goels@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Tue, 29 Apr 2014 00:18:28 +0000 (17:18 -0700)]
drm/i915: Support 64b relocations
All the rest of the code to enable this is in my branch. Without my
branch, hitting > 32b offsets is impossible. The code has always
"supported" 64b, but it's never actually been run of tested. This change
doesn't actually fix anything. [1] I am not sure why X won't work yet. I
do not get hangs or obvious errors.
There are 3 fixes grouped together here. First is to remove the
hardcoded 0 for the upper dword of the relocation. The next fix is to
use a 64b value for target_offset. The final fix is to not directly
apply target_offset to reloc->delta. reloc->delta is part of ABI, and so
we cannot change it. As it stands, 32b is enough to represent everything
we're interested in representing anyway. The main problem is, we cannot
add greater than 32b values to it directly.
[1] Almost all of intel-gpu-tools is not yet ready to test 64b
relocations. There are a few places that expect 32b values for offsets
and these all won't work.
Cc: Rafael Barbalho <rafael.barbalho@intel.com>
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>
Ben Widawsky [Tue, 29 Apr 2014 02:29:25 +0000 (19:29 -0700)]
drm/i915: Support 64b execbuf
Previously, our code only had a 32b offset value for where the
batchbuffer starts. With full PPGTT, and 64b canonical GPU address
space, that is an insufficient value. The code to expand is pretty
straight forward, and only one platform needs to do anything with the
extra bits.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Rafael Barbalho <rafael.barbalho@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 24 Apr 2014 21:54:45 +0000 (23:54 +0200)]
drm/i915/sdvo: Remove ->mode_set callback
SDVO is used by both crtcs using the i9xx_ and the ironlake_
functions. For both cases there is nothing between the
encoder->mode_set and the encoder->pre_enable calls that touches the
hardware.
The vlv_ functions are different since they enable the pll before the
->pre_enable hook. But SDVO isn't supported on vlv platforms, so this
doesn't matter.
We've also already clean up all the sdvo state computation logic, all
relevant parts are already in the ->compute_config hook. So we can
just get rid of the ->mode_set hook by converting it to a ->pre_enable
hook.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 24 Apr 2014 21:54:44 +0000 (23:54 +0200)]
drm/i915/crt: Remove ->mode_set callback
We only set a few bits in the ADPA register, which we then read back
in the enable/disable hooks. So we can just move that bit of state
computation code to the place where we need it since setting these
bits without enabling the CRT encoder has no effects.
The only exceptions are the hotplug bits since they affect the hotplug
detection logic, but we already set those in the ->reset function and
then never touch them.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 24 Apr 2014 21:54:43 +0000 (23:54 +0200)]
drm/i915/tv: Remove ->mode_set callback
Currently for the i9xx crtc hooks there's nothing between the call to
encoder->mode_set and encoder->pre_enable which touches the hardware.
Therefore, since tv is only used on gen3/4, we can just move the hook.
Yay for easy cases!
The only other important thing to check is that the new
->pre_enable hook is idempotent wrt the sw state since now it can
be called multiple times (due to DPMS). After a the bit of refactoring
this is now easy to check: It only reads crtc->config and computes
derived state but otherwise leaves it as-is, so we're good.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 24 Apr 2014 21:54:42 +0000 (23:54 +0200)]
drm/i915/tv: Rip out pipe-disabling nonsense from ->mode_set
The pipe and plane _are_ disabled when we call this. So replace it
all with the corresponding assert (as self-documenting code) and
rip out all the lore.
Checking for a disabled plane would require us to export those macros
from intel_display.c, but if the pipe is off the plane isn't working
either. So this single check is good enough.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 24 Apr 2014 21:54:41 +0000 (23:54 +0200)]
drm/i915/tv: De-magic device check
We only support TV-out on gen3/4 mobile platforms, and i915gm is the
only one that matches.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 24 Apr 2014 21:54:40 +0000 (23:54 +0200)]
drm/i915/tv: extract set_color_conversion
intel_tv_mode_set is still too bug.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 24 Apr 2014 21:54:39 +0000 (23:54 +0200)]
drm/i915/tv: extract set_tv_mode_timings
intel_tv_mode_set is just too big.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 24 Apr 2014 21:54:38 +0000 (23:54 +0200)]
drm/i915/dvo: Remove ->mode_set callback
Currently for the i9xx crtc hooks there's nothing between the call to
encoder->mode_set and encoder->pre_enable which touches the hardware.
Therefore, since dvo is only used on gen2, we can just move the hook.
Yay for easy cases!
The only other important thing to check is that the new
->pre_enable hook is idempotent wrt the sw state since now it can be
called multiple times (due to DPMS). It only reads crtc->config but
otherwise leaves it as-is, so we're good.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 24 Apr 2014 21:54:37 +0000 (23:54 +0200)]
drm/i915: Make encoder->mode_set callbacks optional
For a bunch of reasons we want to move away from the ->mode_set
callbacks: All hw state setup needs to move into ->enable hooks (so
that DOMS can do runtime pm) and all the configuration setup needs to
move into the compute_config functions.
To start with this make the enocer->mode_set callback optional.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Wed, 30 Apr 2014 14:43:01 +0000 (17:43 +0300)]
drm/i915: Make primary_enabled match the actual hardware state
The BIOS can enable a pipe but leave the primary plane disabled. This
coflicts with out current idea of primary_enabled. Read the actual
hardware plane state and set primary_enabled appropriately.
We currently assume that primary_enabled is always true when we're about
to disable a crtc. That needs to change now as the plane may not be
enabled. So replace the relevant WARNs with early returns in
intel_{enable,disable}_primary_hw_plane().
Fixes the following warning
[ 3.831602] WARNING: CPU: 0 PID: 1112 at linux/drivers/gpu/drm/i915/intel_display.c:1918 intel_disable_primary_hw_plane+0xe4/0xf0 [i915]()
which got introduced here by me:
commit
e9e39655c0c30cddc3f8c09a757678a24dd36737
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Mon Apr 28 15:53:25 2014 +0300
drm/i915: Remove useless checks from primary enable/disable
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Tue, 29 Apr 2014 21:52:30 +0000 (14:52 -0700)]
drm/i915: Move ring_begin to signal()
Add_request has always contained both the semaphore mailbox updates as
well as the breadcrumb writes. Since the semaphore signal is the one
which actually knows about the number of dwords it needs to emit to the
ring, we move the ring_begin to that function. This allows us to remove
the hideously shared #define
On a related not, gen8 will use a different number of dwords for
semaphores, but not for add request.
v2: Make number of dwords an explicit part of signalling (via function
argument). (Chris)
v3: very slight comment change
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Tue, 29 Apr 2014 21:52:29 +0000 (14:52 -0700)]
drm/i915: Virtualize the ringbuffer signal func
This abstraction again is in preparation for gen8. Gen8 will bring new
semantics for doing this operation.
While here, make the writes of MI_NOOPs explicit for non-existent rings.
This should have been implicit before.
NOTE: This is going to be removed in a few patches.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Tue, 29 Apr 2014 21:52:28 +0000 (14:52 -0700)]
drm/i915: Move semaphore specific ring members to struct
This will be helpful in abstracting some of the code in preparation for
gen8 semaphores.
v2: Move mbox stuff to a separate struct
v3: Rebased over VCS2 work
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Imre Deak [Fri, 25 Apr 2014 10:19:05 +0000 (13:19 +0300)]
drm/i915: vlv: init only needed state during early power well enabling
During the initial power well enabling on the driver init/resume path
we can avoid initialzing part of the HW/SW state that will be
initialized anyway by the subsequent init/resume code. For some steps
like HPD initialization this redundancy is not only an overhead but an
actual problem, since they can't be run this early in the overall init
sequence.
Add a flag marking the init phase and skip reinitialzing state that is
not strictly necessary based on that.
This is also needed by the upcoming HPD init restructuring by Thierry
and Daniel.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Wed, 30 Apr 2014 07:30:00 +0000 (08:30 +0100)]
drm/i915: Avoid NULL ctx->obj dereference in debugfs/i915_context_info
In commit
691e6415c891b8b2b082a120b896b443531c4d45
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Apr 9 09:07:36 2014 +0100
drm/i915: Always use kref tracking for all contexts.
we populated fake contexts on all platforms. These were identical to the
full hardware context tracking structs, except for the ctx->obj used to
store the hardware state. However, there remained one place where we
assumed that if a context existed, it would have an object associated
with it.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77717
Testcase: igt/drv_suspend/debugfs-reader
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 29 Apr 2014 10:35:45 +0000 (13:35 +0300)]
drm/i915: Add intel_get_crtc_scanline()
Add a new function intel_get_crtc_scanline() that returns the current
scanline counter for the crtc.
v2: Rebase after vblank timestamp changes.
Use intel_ prefix instead of i915_ as is more customary for
display related functions.
Include DRM_SCANOUTPOS_INVBL in the return value even w/o
adjustments, for a bit of extra consistency.
v3: Change the implementation to be based on DSL on all gens,
since that's enough for the needs of atomic updates, and
it will avoid complicating the scanout position calculations
for the vblank timestamps
v4: Don't break scanline wraparound for interlaced modes
Reviewed-by: Sourab Gupta <sourabgupta@gmail.com>
Reviewed-by: Akash Goel <akash.goels@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 29 Apr 2014 10:35:44 +0000 (13:35 +0300)]
drm/i915: Fix scanout position for real
Seems I've been a bit dense with regards to the start of vblank
vs. the scanline counter / pixel counter.
After staring at the pixel counter on gen4 I came to the conclusion
that the start of vblank interrupt and scanline counter increment
happen at the same time. The scanline counter increment is documented
to occur at start of hsync, which means that the start of vblank
interrupt must also trigger there. Looking at the pixel counter value
when the scanline wraps from vtotal-1 to 0 confirms that, as the pixel
counter at that point reads hsync_start. This also clarifies why we see
need the +1 adjustment to the scaline counter. The counter actually
starts counting from vtotal-1 on the first active line.
I also confirmed that the frame start interrupt happens ~1 line after
the start of vblank, but the frame start occurs at hblank_start instead.
We only use the frame start interrupt on gen2 where the start of vblank
interrupt isn't available. The only important thing to note here is that
frame start occurs after vblank start, so we don't have to play any
additional tricks to fix up the scanline counter.
The other thing to note is the fact that the pixel counter on gen3-4
starts counting from the start of horizontal active on the first active
line. That means that when we get the start of vblank interrupt, the
pixel counter reads (htotal*(vblank_start-1)+hsync_start). Since we
consider vblank to start at (htotal*vblank_start) we need to add a
constant (htotal-hsync_start) offset to the pixel counter, or else we
risk misdetecting whether we're in vblank or not.
I talked a bit with Art Runyan about these topics, and he confirmed my
findings. And that the same rules should hold for platforms which don't
have the pixel counter. That's good since without the pixel counter it's
rather difficult to verify the timings to this accuracy.
So the conclusion is that we can throw away all the ISR tricks I added,
and just increment the scanline counter by one always.
Reviewed-by: Sourab Gupta <sourabgupta@gmail.com>
Reviewed-by: Akash Goel <akash.goels@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Fri, 18 Apr 2014 21:04:29 +0000 (18:04 -0300)]
drm/i915/bdw: Disable idle DOP clock gating
It seems we need this at least for the current platforms we have, but
probably not later. In any event, it should cause too much harm as we do
the same thing on several other platforms.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Fri, 18 Apr 2014 21:04:28 +0000 (18:04 -0300)]
drm/i915/bdw: enable eDRAM.
The same register exists for querying and programming eDRAM AKA eLLC. So
we can simply use it. For now, use all the same defaults as we had
for Haswell, since like Haswell, I have no further details.
I do not actually have a part with eDRAM, so I cannot test this.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Fri, 18 Apr 2014 21:04:27 +0000 (18:04 -0300)]
drm/i915/bdw: Add WT caching ability
I don't have any insight on what parts can do what. The docs do seem to
suggest WT caching works in at least the same manner as it does on
Haswell.
The addr = 0 is to shut up GCC:
drivers/gpu/drm/i915/i915_gem_gtt.c:80:7: warning: 'addr' may be used
uninitialized in this function [-Wmaybe-uninitialized]
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Imre Deak [Mon, 28 Apr 2014 09:03:59 +0000 (12:03 +0300)]
drm/i915: bdw: fix RC6 enabled status reporting and disable runtime PM
On BDW we don't enable RC6 at the moment, but this isn't reflected in
the (sanitized) i915.enable_rc6 option. So make enable_rc6 report
correctly that RC6 is disabled, which will also effectively disable RPM
on BDW (since RPM depends on RC6).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77565
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 25 Apr 2014 19:12:07 +0000 (22:12 +0300)]
drm/i915: Fix assert_plane warning during FDI link train
assert_plane_enabled() is now triggering during FDI link train because
we no longer enable planes that early.
This problem got introduced in:
commit
a5c4d7bc187bd13bc11ac06bb4ea3a0d4001aa4d
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Mar 7 18:32:13 2014 +0200
drm/i915: Disable/enable planes as the first/last thing during modeset on ILK+
Just drop the assert since we shouldn't need planes for link training.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Squash in fixup for now unused plane local variable, reported
by 0-day tester.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jan Moskyto Matejka [Mon, 28 Apr 2014 13:03:23 +0000 (15:03 +0200)]
Revert "drm/i915: fix build warning on 32-bit (v2)"
This reverts commit
60f2b4af1258c05e6b037af866be81abc24438f7.
The same warning has been fixed in
e5081a538a565284fec5f30a937d98e460d5e780 and
these two commits got merged in
74e99a84de2d0980320612db8015ba606af42114 which
caused another warning. Simply, the reverted commit casted the pointer
difference to unsigned long and the other commit changed the output type from
long to ptrdiff_t.
The other commit fixes the original warning the better way so I'm reverting
this commit now.
Signed-off-by: Jan Moskyto Matejka <mq@suse.cz>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 25 Apr 2014 19:11:51 +0000 (22:11 +0300)]
drm/i915: Fix deadlock during driver init on ILK
We have a struct_mutex deadlock during driver init on ILK
[ 54.320273] =============================================
[ 54.320371] [ INFO: possible recursive locking detected ]
[ 54.320471] 3.15.0-rc2-flip_race+ #2 Not tainted
[ 54.320567] ---------------------------------------------
[ 54.320665] modprobe/2178 is trying to acquire lock:
[ 54.320762] (&dev->struct_mutex){+.+.+.}, at: [<
ffffffffa0568b05>] intel_enable_gt_powersave+0xa5/0x9d0 [i915]
[ 54.321111]
[ 54.321111] but task is already holding lock:
[ 54.321250] (&dev->struct_mutex){+.+.+.}, at: [<
ffffffffa05b4c2e>] intel_modeset_init_hw+0x3e/0x60 [i915]
[ 54.321583]
[ 54.321583] other info that might help us debug this:
[ 54.321724] Possible unsafe locking scenario:
[ 54.321724]
[ 54.321863] CPU0
[ 54.321954] ----
[ 54.322046] lock(&dev->struct_mutex);
[ 54.322221] lock(&dev->struct_mutex);
[ 54.322397]
[ 54.322397] *** DEADLOCK ***
[ 54.322397]
[ 54.322638] May be due to missing lock nesting notation
[ 54.322638]
[ 54.322781] 4 locks held by modprobe/2178:
[ 54.322875] #0: (&dev->mutex){......}, at: [<
ffffffff813592eb>] __driver_attach+0x5b/0xb0
[ 54.323230] #1: (&dev->mutex){......}, at: [<
ffffffff813592f9>] __driver_attach+0x69/0xb0
[ 54.323582] #2: (drm_global_mutex){+.+.+.}, at: [<
ffffffffa04e1e0d>] drm_dev_register+0x2d/0x120 [drm]
[ 54.323945] #3: (&dev->struct_mutex){+.+.+.}, at: [<
ffffffffa05b4c2e>] intel_modeset_init_hw+0x3e/0x60 [i915]
This regression got introduced in:
commit
586d5270b60dc1f35cc3ca982d403765bad77965
Author: Imre Deak <imre.deak@intel.com>
Date: Mon Apr 14 20:24:28 2014 +0300
drm/i915: move getting struct_mutex lower in the callstack during GPU reset
Fix the problem by not taking struct_mutex around intel_enable_gt_powersave()
in intel_modeset_init_hw() since intel_enable_gt_powersave() now grabs the
mutex itself.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Imre Deak [Fri, 25 Apr 2014 14:28:00 +0000 (17:28 +0300)]
drm/i915: remove extraneous VGA power domain put calls
In recent dmesg logs reported for unrelated issues I noticed some power
domain WARNs caused by the following.
The workaround
commit
ce352550327b394f3072a07c9cd9d27af9276f15
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Sep 20 10:14:23 2013 +0300
drm/i915: Fix unclaimed register access due to delayed VGA memory disable
and following fixup of it
commit
a14853206517b0c8102accbc77401805a0dbdb9e
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Mon Sep 16 17:38:34 2013 +0300
drm/i915: Move power well init earlier during driver load
was partially reverted by
commit
7f16e5c1416070dc590dd333a2d677700046a4ab
Merge:
9d1cb91 5e01dc7
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Nov 4 16:28:47 2013 +0100
Merge tag 'v3.12' into drm-intel-next
but kept the power domain put calls on the error path.
I think for now we can keep things as-is (not reintroduce the w/a) and just fix
the error path, since
- nobody complained seeing this issue
- according to Ville someone is reworking the VGA arbitration scheme at the
moment and when that's ready we have to rethink this part anyway
So fix this by just removing the put calls from the error path as well.
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>
Daniel Vetter [Fri, 25 Apr 2014 14:59:00 +0000 (16:59 +0200)]
drm/i915: Integrate cmd parser kerneldoc
Ville noticed that we have this nice kerneldoc but it's not integrated
anywhere. Fix this asap!
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Brad Volkin <bradley.d.volkin@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Mon, 17 Mar 2014 12:21:55 +0000 (12:21 +0000)]
drm/i915: Do not call retire_requests from wait_for_rendering
A common issue we have is that retiring requests causes recursion
through GTT manipulation or page table manipulation which we can only
handle at very specific points. However, to maintain internal
consistency (enforced through our sanity checks on write_domain at
various points in the GEM object lifecycle) we do need to retire the
object prior to marking it with a new write_domain, and also clear the
write_domain for the implicit flush following a batch.
Note that this then allows the unbound objects to still be on the active
lists, and so care must be taken when removing objects from unbound lists
(similar to the caveats we face processing the bound lists).
v2: Fix i915_gem_shrink_all() to handle updated object lifetime rules,
by refactoring it to call into __i915_gem_shrink().
v3: Missed an object-retire prior to changing cache domains in
i915_gem_object_set_cache_leve()
v4: Rebase
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Mon, 17 Mar 2014 12:21:54 +0000 (12:21 +0000)]
lib: Export interval_tree
lib/interval_tree.c provides a simple interface for an interval-tree
(an augmented red-black tree) but is only built when testing the generic
macros for building interval-trees. For drivers with modest needs,
export the simple interval-tree library as is.
v2: Lots of help from Michel Lespinasse to only compile the code
as required:
- make INTERVAL_TREE a config option
- make INTERVAL_TREE_TEST select the library functions
and sanitize the filenames & Makefile
- prepare interval_tree for being built as a module if required
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Lespinasse <walken@google.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Michel Lespinasse <walken@google.com>
[Acked for inclusion via drm/i915 by Andrew Morton.]
[danvet: switch to _GPL as per the mailing list discussion.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Imre Deak [Mon, 14 Apr 2014 17:24:43 +0000 (20:24 +0300)]
drm/i915: vlv: increase timeout when forcing on the GFX clock
I've seen latencies up to 15msec, so increase the timeout to 20msec.
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>
Imre Deak [Fri, 18 Apr 2014 13:35:02 +0000 (16:35 +0300)]
drm/i915: vlv: factor out vlv_force_gfx_clock and check for pending force-off
This will be needed by the VLV runtime PM helpers too, so factor it out.
Also add a safety check for the case where the previous force-off is
still pending, since I'm not sure if Punit can handle a new setting
while the previous one hasn't settled yet.
v2:
- unchanged
v3:
- add a note to the commit message about the safety check (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>
Imre Deak [Mon, 14 Apr 2014 17:24:41 +0000 (20:24 +0300)]
drm/i915: vlv: setup RPS min/max frequencies once during init time
When enabling runtime PM on VLV, GT power save enabling becomes relatively
frequent, so optimize it a bit.
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>
Imre Deak [Tue, 22 Apr 2014 17:21:07 +0000 (20:21 +0300)]
drm/i915: reinit GT power save during resume
During runtime suspend there can be a last pending rps.work, so make
sure it's canceled. Note that in the runtime suspend callback we can't
get any RPS interrupts since it's called only after the GPU goes idle
and we set the minimum RPS frequency. The next possibility for an RPS
interrupt is only after getting an RPM ref (for example because of a new
GPU command) and calling the RPM resume callback.
v2:
- patch introduced in v2 of the patchset
v3:
- Change the order of canceling the rps.work and disabling interrupts to
avoid the race between interrupt disabling and the the rps.work. Race
spotted by 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>
Imre Deak [Mon, 14 Apr 2014 17:24:39 +0000 (20:24 +0300)]
drm/i915: make runtime PM swizzling/ring_freq init platform independent
We need to re-init sizzling on all platforms so move it to the
platform independent runtime resume callback. The ring frequency reinit
is also needed everywhere except on VLV, but gen6_update_ring_freq()
will be a noop on VLV, so we can move this function too to platform
independent code.
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>
Imre Deak [Fri, 18 Apr 2014 13:16:23 +0000 (16:16 +0300)]
drm/i915: factor out gen6_update_ring_freq
This is needed by the next patch moving the call out from platform
specific RPM callbacks to platform independent code.
No functional change.
v2:
- patch introduce in v2 of the patchset
v3:
- simplify platform check condition (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>
Imre Deak [Mon, 14 Apr 2014 17:24:37 +0000 (20:24 +0300)]
drm/i915: make runtime PM interrupt enable/disable platform independent
We need to disable the interrupts for all platforms, so make the helpers
for this platform independent and call them from them platform
independent runtime suspend/resume callbacks.
On HSW/BDW this will move interrupt disabling/re-enabling at the
beginning/end of runtime suspend/resume respectively, but I don't see
any reason why this would cause a problem there. In any case this seems
to be the correct thing to do even on those platforms.
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>
Imre Deak [Mon, 14 Apr 2014 17:24:36 +0000 (20:24 +0300)]
drm/i915: disable runtime PM if RC6 is disabled
On VLV we depend on RC6 to save the GT render and media HW context
before going to the D3 state via RPM, so as a preparation for the
VLV RPM support (added in an upcoming patch) disable RPM if RC6 is
disabled.
There is probably a similar dependency on other platforms too, so for
safety require RC6 for those too. For these platforms (SNB, HSW, BDW)
this is then a possible fix.
v2:
- require RC6 for all RPM platforms, not just for VLV (Paulo, 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>
Imre Deak [Fri, 18 Apr 2014 13:01:02 +0000 (16:01 +0300)]
drm/i915: sanitize enable_rc6 option
Atm, an invalid enable_rc6 module option will be silently ignored, so
emit an info message about it. Doing an early sanitization we can also
reuse intel_enable_rc6() in a follow-up patch to see if RC6 is actually
enabled. Currently the caller would have to filter a non-zero return
value based on the platform we are running on. For example on VLV with
i915.enable_rc6 set to 2, RC6 won't be enabled but atm
intel_enable_rc6() would still return 2 in this case.
v2:
- simplify the platform check condition (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>
Imre Deak [Mon, 14 Apr 2014 17:24:34 +0000 (20:24 +0300)]
drm/i915: fix unbalanced GT powersave enable / disable calls
Atm, we call intel_gt_powersave_enable() for GEN6 and GEN7 but disable
it for everything starting from GEN6. This is a problem in case of BDW.
Since I don't have a BDW to test if RC6 works properly, just keep it
disabled for now and fix only the disable function.
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>
Imre Deak [Mon, 14 Apr 2014 17:24:33 +0000 (20:24 +0300)]
drm/i915: vlv: check port power domain instead of only D0 for eDP VDD on
Some platforms need additional power domains to be on in addition to the
device D0 state to access the panel registers.
Suggested by Daniel.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76987
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>
Imre Deak [Fri, 18 Apr 2014 12:55:04 +0000 (15:55 +0300)]
drm/i915: add missing error capturing of the PIPESTAT reg
While checking the error capture path I noticed that we lacked the
power domain-on check for PIPESTAT so fix this by moving that to where
the rest of pipe registers are captured.
The move also revealed that we actually don't include this register in
the error report, so fix that too.
v2:
- patch introduced in v2 of the patchset
v3:
- add back !HAS_PCH_SPLIT check (Ville)
[ Ignore my previous comment about the gen<=5 || vlv check, I realized
that it's the same as !HAS_PCH_SPLIT. ]
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>
Imre Deak [Mon, 14 Apr 2014 17:24:31 +0000 (20:24 +0300)]
drm/i915: gen2: move error capture of IER to its correct place
While checking the error capture path I noticed that this register is
read twice for GEN2, so fix this and also move the read where it's done
for other platforms.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Imre Deak [Tue, 22 Apr 2014 22:09:04 +0000 (01:09 +0300)]
drm/i915: get a runtime PM ref for the deferred GPU reset work
Atm we can end up in the GPU reset deferred work in D3 state if the last
runtime PM reference is dropped between detecting a hang/scheduling the
work and executing the work. At least one such case I could trigger is
the simulated reset via the i915_wedged debugfs entry. Fix this by
getting an RPM reference around accessing the HW in the reset work.
v2:
- Instead of getting/putting the RPM reference in the reset work itself,
get it already before scheduling the work. By this we also prevent
going to D3 before the work gets to run, in addition to making sure
that we run the work itself in D0. (Ville, Daniel)
v3:
- fix inverted logic fail when putting the RPM ref on behalf of a
cancelled GPU reset work (Ville)
v4:
- Taking the RPM ref in the interrupt handler isn't really needed b/c
it's already guaranteed that we hold an RPM ref until the end of the
reset work in all cases we care about. So take the ref in the reset
work (for cases like i915_wedged_set). (Daniel)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Fri, 18 Apr 2014 21:04:22 +0000 (18:04 -0300)]
drm/i915: Validate VBT header before trusting it
Be we read and chase pointers from the VBT, it is prudent to make sure
that those accesses are wholly contained within the MMIO region, or else
we may cause a kernel panic during boot.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Fri, 18 Apr 2014 21:04:23 +0000 (18:04 -0300)]
drm/i915: Validate BDB section before reading
Make sure that the whole BDB section is within the MMIO region prior to
accessing it contents. That we don't read outside of the secion is left
up to the individual section parsers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Imre Deak [Mon, 14 Apr 2014 17:24:29 +0000 (20:24 +0300)]
drm/i915: get a runtime PM ref for the deferred GT powersave enabling
At least on VLV but probably on other platforms too we depend on RC6
being enabled for RPM, so disable RPM until the delayed RC6 enabling
completes.
v2:
- explain the reason for the _noresume version of RPM get (Daniel)
- use the simpler 'if (schedule_work()) rpm_get();' instead of
'if (!cancel_work_sync()) rpm_get(); schedule_work();'
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>
Imre Deak [Mon, 14 Apr 2014 17:24:28 +0000 (20:24 +0300)]
drm/i915: move getting struct_mutex lower in the callstack during GPU reset
Getting struct_mutex around the whole intel_enable_gt_powersave()
function is not necessary, since it's only needed for the ILK path
therein.
This will make intel_enable_gt_powersave() useable on the RPM resume
path for >=GEN6 (added in an upcoming patch to reset the RPS state
during RPM resume), where we can't (and need not) get this mutex.
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>
Imre Deak [Mon, 14 Apr 2014 17:24:27 +0000 (20:24 +0300)]
drm/i915: get a runtime PM ref for debugfs entries where needed
These debugfs entries access registers that need the D0 power state so
get an RPM ref for them.
v2:
- for all these entries we only need D0 state, so get only an RPM ref,
not a power domain ref (Daniel, Paulo)
- the dpio entry is not an issue any more as it got removed (Ville)
- restore commit message from v1 (Paulo)
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>
Imre Deak [Mon, 14 Apr 2014 17:24:26 +0000 (20:24 +0300)]
drm/i915: remove the i915_dpio debugfs entry
There are igt tools that can read/write the DPIO registers, so having a
debugfs entry for only some of those registers is somewhat arbitrary /
redundant. Remove it.
v2:
- instead of fixing the entry by taking a power domain reference around
the register accesses, remove the entry (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>
Imre Deak [Mon, 14 Apr 2014 17:24:25 +0000 (20:24 +0300)]
drm/i915: fix the RC6 status debug print
The parsing was incorrect for ILK and VLV.
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>
Imre Deak [Mon, 14 Apr 2014 17:24:24 +0000 (20:24 +0300)]
drm/i915: vlv: add RC6 residency counters
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>
Imre Deak [Mon, 14 Apr 2014 17:24:23 +0000 (20:24 +0300)]
drm/i915: vlv: clear master interrupt flag when disabling interrupts
Not clearing this flag causes spurious interrupts at least in D3 state,
so before enabling RPM we need to fix this. We were already setting this
flag when enabling interrupts, only clearing it was missing.
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>
Imre Deak [Mon, 14 Apr 2014 17:24:22 +0000 (20:24 +0300)]
drm/i915: vlv: clean up GTLC wake control/status register macros
These will be needed by the upcoming VLV RPM helpers.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-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>
Zhao Yakui [Thu, 17 Apr 2014 02:37:40 +0000 (10:37 +0800)]
drm/i915: Use the coarse ping-pong mechanism based on drm fd to dispatch the BSD command on BDW GT3
The BDW GT3 has two independent BSD rings, which can be used to process the
video commands. To be simpler, it is transparent to user-space driver/middle.
Instead the kernel driver will decide which ring is to dispatch the BSD video
command.
As every BSD ring is powerful, it is enough to dispatch the BSD video command
based on the drm fd. In such case it can play back video stream while encoding
another video stream. The coarse ping-pong mechanism is used to determine
which BSD ring is used to dispatch the BSD video command.
V1->V2: Follow Daniel's comment and use the simple ping-pong mechanism.
This is only to add the support of dual BSD rings on BDW GT3 machine.
The further optimization will be considered in another patch set.
V2->V3: Follow Daniel's comment to use the struct_mutext instead of
atomic_t during determining which ring can be used to dispatch Video command.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Zhao Yakui [Thu, 17 Apr 2014 02:37:39 +0000 (10:37 +0800)]
drm/i915:Add the VCS2 switch in Intel_ring_setup_status_page
The Gen7 doesn't have the second BSD ring. But it will complain the switch check
warning message during compilation. So just add it to remove the
switch check warning.
V1->V2: Follow Daniel's comment to update the comment
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Zhao Yakui [Thu, 17 Apr 2014 02:37:38 +0000 (10:37 +0800)]
drm/i915:Handle the irq interrupt for the second BSD ring
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Zhao Yakui [Thu, 17 Apr 2014 02:37:37 +0000 (10:37 +0800)]
drm/i915:Initialize the second BSD ring on BDW GT3 machine
Based on the hardware spec, the BDW GT3 machine has two independent
BSD ring that can be used to dispatch the video commands.
So just initialize it.
V3->V4: Follow Imre's comment to do some minor updates. For example:
more comments are added to describe the semaphore between ring.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
[danvet: Fix up checkpatch error.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Zhao Yakui [Thu, 17 Apr 2014 02:37:36 +0000 (10:37 +0800)]
drm/i915: Update the restrict check to filter out wrong Ring ID passed by user-space
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Zhao Yakui [Thu, 17 Apr 2014 02:37:35 +0000 (10:37 +0800)]
drm/i915: Split the BDW device definition to prepare for dual BSD rings on BDW GT3
Based on the hardware spec, the BDW GT3 has the different configuration
with the BDW GT1/GT2. So split the BDW device info definition.
This is to do the preparation for adding the Dual BSD rings on BDW GT3 machine.
V1->V2: Follow Daniel's comment to pay attention to the stolen check for BDW
in kernel/early-quirks.c
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 24 Apr 2014 06:09:11 +0000 (08:09 +0200)]
drm/i915: Catch dirt in unused execbuffer fields
We need to make sure that userspace keeps on following the contract,
otherwise we won't be able to use the reserved fields at all.
v2: Add DRM_DEBUG (Chris)
Testcase: igt/gem_exec_params/*-dirt
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>