- 04 Mar, 2014 9 commits
-
-
Ville Syrjälä authored
BSpec recommends using 8x4 hashing mode when MSAA is used. But in practice 16x4 seems to have a slight edge in performance (on IVB and HSW at least). So just use 16x4. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
BSpec recommends using 8x4 hashing mode when MSAA is used. But in practice 16x4 seems to have a slight edge in performance (on IVB and HSW at least). So just use 16x4. Signed-off-by:
-
Ville Syrjälä authored
BSpec recommends using 8x4 hashing mode when MSAA is used. But in practice 16x4 seems to have a slight edge in performance (on IVB and HSW at least). So just use 16x4. Signed-off-by:
-
Ville Syrjälä authored
The need to set all of the mask bits for 3D_CHICKEN3 was required only for pre-production hardware. Signed-off-by:
-
Ville Syrjälä authored
Based on the name, the workaround we implement is WaStripsFansDisableFastClipPerformanceFix. Unfortunately there's no description in the w/a database, so this is just a guess. Signed-off-by:
-
Ville Syrjälä authored
On SNB we set up WaSetupGtModeTdRowDispatch:snb early in gen6_init_clock_gating(). That sets a bit in the GEN6_GT_MODE register. However later we go and disable all the bits in the same register. And then we go on to set some other bit. So apparently we never actually implemented this workaround since the "disable all bits" part was there already before the w/a got supposedly implemented. These are the relevant commits: commit 6547fbdb Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Dec 14 23:38:29 2012 +0100 drm/i915: Implement WaSetupGtModeTdRowDispatch commit f8f2ac9a Author: Ben Widawsky <ben@bwidawsk.net> Date: Wed Oct 3 19:34:24 2012 -0700 drm/i915: Fix GT_MODE default value So, let's drop the "disable all bits" part, move both writes to closer proxomity to each other, and name the WIZ hashing bits appropriately. BSpec is still a bit confused how the bits should actually be interpreted, but I took the the description for the high bit since the low bit part only lists values for a single bit. Also add a comment about our choice of WIZ hashing mode. Signed-off-by:
-
Paulo Zanoni authored
We'll need this when we merge PC8 and Runtime PM: the PC8 enable/disable functions need that lock. Also, it's good practice to not hold a lock for longer than strictly needed. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Paulo Zanoni authored
To modeset_update_crtc_power_domains, since this function is responsible for updating all the power domains of all CRTCs after a modeset. In the future we should also run this function on all platforms, not just Haswell. Signed-off-by:
-
Thierry Reding authored
The i915 driver sets DRIVER_GEM unconditionally, so testing for the feature will always fail. Signed-off-by:
Thierry Reding <treding@nvidia.com> [danvet: Fix up conflicts.] Signed-off-by:
-
- 02 Mar, 2014 1 commit
-
-
Daniel Vetter authored
Apparently we've missed a few more than what Fengguang's 0-day tester recently reported in i915_irq.c ... Makes sparse happy again (ignore some spurious stuff about ksyms of exported functions). Cc: kbuild test robot <fengguang.wu@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
-
- 14 Feb, 2014 17 commits
-
-
Daniel Vetter authored
Spotted while auditing the code for fencing issues. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Daniel Vetter authored
Looks like I've missed one of the potential NULL deref bugs in Jesse's fbdev->fb embedded struct to pointer conversions. Fix it up. This regression has been introduced in commit 8bcd4553 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Feb 7 12:10:38 2014 -0800 drm/i915: alloc intel_fb in the intel_fbdev struct Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Daniel Vetter authored
One side-effect of the introduction of ppgtt was that we needed to rebind the object into the appropriate vm (and global gtt in some peculiar cases). For simplicity this was done twice for every object on every call to execbuffer. However, that adds a tremendous amount of CPU overhead (rewriting all the PTE for all objects into WC memory) per draw. The fix is to push all the decision about which vm to bind into and when down into the low-level bind routines through hints rather than performing the bind unconditionally in the execbuffer routine. Note that this is a regression introduced in the full ppgtt feature branch, before this we've only done re-bound objects when the relevant has_(aliasing_ppgtt|global_gtt)_mapping flag was clear. But since that's per-object and not per-vma that optimization broke. v2: Split out prep work and unrelated changes. v3: Bring back functional change around PIN_GLOBAL that I've accidentally split out. v4: Remove the temporary hack for the old binding logic to avoid bisection issues. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72906 Tested-by: jianx.zhou@intel.com Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Daniel Vetter authored
This is prep work for reworking the object_pin logic. Atm it still does a (now redundant) lookup of the vma. The next patch will fix this. Split out from Chris vma-bind rework. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Daniel Vetter authored
Split out from Chris vma-bind rework. Jani wondered why this is save, and the reason is that i915_vma_unbind does all these checks, too. So they're redundant. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Daniel Vetter authored
There's no need not to, really. Split out from Chris vma-bind rework. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Reviewed-by:
-
Daniel Vetter authored
Only the hardware really access them, so no need to have cpu gtt access available. 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:
-
Daniel Vetter authored
Split out from Chris vma-bind rework. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Reviewed-by:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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:
-
Imre Deak authored
This is the same what we do for DP connectors, so make things more consistent. Signed-off-by:
-
Imre Deak authored
Signed-off-by:
-
Imre Deak authored
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=70523Signed-off-by:
-
Imre Deak authored
Since commit d9255d57 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:
-
- 13 Feb, 2014 5 commits
-
-
Paulo Zanoni authored
Reproducible by runtime suspending a Haswell machine with eDP + HDMI outputs connected. [ 209.600086] [drm:i915_runtime_suspend], Suspending device [ 209.688435] BUG: unable to handle kernel NULL pointer dereference at 0000000000000060 [ 209.688500] IP: [<ffffffffa0109d4e>] i915_sink_crc+0x6e/0xf0 [i915] [ 209.688577] PGD 36aba067 PUD 35d7f067 PMD 0 [ 209.688613] Oops: 0000 [#1] SMP [ 209.688641] Modules linked in: fuse ip6table_filter ip6_tables ebtable_nat ebtables iTCO_wdt iTCO_vendor_support x86_pkg_temp_thermal coretemp microcode serio_raw e1000e pcspkr i2c_i801 ptp mei_me mei lpc_ich mfd_core pps_core dm_crypt i915 i2c_algo_bit crc32_pclmul drm_kms_helper crc32c_intel drm ghash_clmulni_intel video [ 209.688893] CPU: 1 PID: 1797 Comm: pm_pc8 Not tainted 3.13.0+ #118 [ 209.688937] Hardware name: Intel Corporation Shark Bay Client platform/WhiteTip Mountain 1, BIOS HSWLPTU1.86C.0133.R00.1309172123 09/17/2013 [ 209.689023] task: ffff88007fb4b690 ti: ffff88007d9d2000 task.ti: ffff88007d9d2000 [ 209.689074] RIP: 0010:[<ffffffffa0109d4e>] [<ffffffffa0109d4e>] i915_sink_crc+0x6e/0xf0 [i915] [ 209.689169] RSP: 0018:ffff88007d9d3e68 EFLAGS: 00010246 [ 209.689205] RAX: 0000000000000000 RBX: ffff880036a03478 RCX: ffff8800366c9770 [ 209.689252] RDX: ffff88014325cf38 RSI: ffff88007fb4bd08 RDI: ffff88007fb4b690 [ 209.689299] RBP: ffff88007d9d3e98 R08: 0000000000000000 R09: 0000000000000000 [ 209.689346] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8800366c9148 [ 209.689393] R13: 00000000ffffffed R14: ffff88007d9d3f50 R15: ffff880036a03478 [ 209.689441] FS: 00007f5a74bc29c0(0000) GS:ffff88014f240000(0000) knlGS:0000000000000000 [ 209.689494] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 209.689533] CR2: 0000000000000060 CR3: 0000000079d7e000 CR4: 00000000001407e0 [ 209.689580] Stack: [ 209.689594] 0000000000001000 ffff880146083980 ffff880146083980 0000000000000000 [ 209.689649] ffff880146083980 0000000000000001 ffff88007d9d3f00 ffffffff811d0744 [ 209.689702] 0000000000000046 00007fff7949fe20 ffff880036a034b8 0000000000000080 [ 209.689756] Call Trace: [ 209.689778] [<ffffffff811d0744>] seq_read+0x164/0x3e0 [ 209.689816] [<ffffffff811ab165>] vfs_read+0x95/0x160 [ 209.689851] [<ffffffff811abc79>] SyS_read+0x49/0xa0 [ 209.689888] [<ffffffff810ef64c>] ? __audit_syscall_entry+0x9c/0xf0 [ 209.689933] [<ffffffff81659412>] system_call_fastpath+0x16/0x1b Testcase: igt/pm_pc8 (do a full run, it will fail at the debugfs-read subtest) Signed-off-by:
-
Damien Lespiau authored
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:
-
Jesse Barnes authored
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:
-
Ben Widawsky authored
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:
-
Ville Syrjälä authored
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:
-
- 12 Feb, 2014 8 commits
-
-
Daniel Vetter authored
... 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 authored
Avoids surprises when userspace races open/closes against this. Cc: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by: -
Daniel Vetter authored
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: -
Jesse Barnes authored
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 authored
This allows drivers to use them in custom initial_config functions. Signed-off-by:
Dave Airlie <airlied@gmail.com> Signed-off-by:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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: -
Jesse Barnes authored
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:
-
