- 08 Apr, 2016 7 commits
-
-
Chris Wilson authored
When we change the current seqno, we also need to remember to reset the last_submitted_seqno for the engine. Testcase: igt/gem_exec_whisper Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460010558-10705-7-git-send-email-chris@chris-wilson.co.uk
-
Chris Wilson authored
An oversight is that when we wrap the seqno, we need to reset the hw semaphore counters to 0. We did this for gen6 and gen7 and forgot to do so for the new implementation required for gen8 (legacy). Signed-off-by:
-
Chris Wilson authored
We reuse the same calculation into two macros, and I want to add a third user. Time to refactor. Signed-off-by:
-
Chris Wilson authored
Since we are setting engine local values that are tied to the hardware, move it out of i915_gem_init_seqno() into the intel_ring_init_seqno() backend, next to where the other hw semaphore registers are written. v2: Make the explanatory comment about always resetting the semaphores to 0 irrespective of the value of the reset seqno. Signed-off-by:
-
Chris Wilson authored
We only use drm_i915_private within the function, so delete the unneeded drm_device local. Signed-off-by:
-
Chris Wilson authored
After the GPU reset and we discard all of the incomplete requests, mark the GPU as having advanced to the last_submitted_seqno (as having completed the requests and ready for fresh work). The impact of this is negligible, as all the requests will be considered completed by this point, it just brings the HWS into line with expectations for external viewers. Signed-off-by:
-
Chris Wilson authored
It's useful to look at the last seqno submitted on a particular engine and compare it against the HWS value to check for irregularities. Signed-off-by:
-
- 07 Apr, 2016 8 commits
-
-
Ramalingam C authored
At BXT DSI, PIPE registers are inactive. So we can't get the PIPE's mode parameters from them. The possible option is retriving them from the PORT registers. The required changes are added for BXT in intel_dsi_get_config (encoder->get_config). v2: Addressed the Jani's comments -removed the redundant call to encoder->get_config -read bpp from port register -removed retrival of src_size from encoder->get_config v3: pipe_config->pipe_bpp is fixed Jani's review comments addressed: Few horizontal timing parameters dropped from the patch to make progress, as there seems to be some disagreement on best/feasible/possible options. Signed-off-by:Ramalingam C <ramalingam.c@intel.com> Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Previously Reviewed at: https://lists.freedesktop.org/archives/intel-gfx/2016-April/091737.htmlSigned-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460019967-26501-2-git-send-email-ramalingam.c@intel.com
-
Ramalingam C authored
Shared the function pixel_format_from_vbt for whole display module. Function declaration is added to intel_dsi.h. V2: Moved the function to intel_dsi.c and renamed as per the purpose of the function. Suggested by Jani. Signed-off-by:
-
Jani Nikula authored
The shorthand is easier. Also change the struct name. No functional changes. Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Prepare for future. No functional changes. v2: Move earlier in the series. Use bool for gpio value. Reviewed-by:
-
Jani Nikula authored
Define and store the pad base offset in the array, and reference the pconf0 and padval registers through macros. Add VLV prefixes to macros. Use spec nomenclature for pconf0 and padval. v2: Address Ville's review comments, squash another patch here. v3: Use the names Ville dug up in the specs. Reviewed-by:
-
Joonas Lahtinen authored
dev_priv is what the macro works hard to extract, pass it directly. > sed 's/\([A-Z].*(dev_priv\)->dev)/\1)/g' v2: - Include all wrapper macros too (Chris) v3: - Include sed cmdline (Chris) v4: - Break long line - Rebase Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Joonas Lahtinen authored
According to Chris, use of i915_vm_to_ppgtt is visible in benchmark unless WARN_ON is removed, so lets get rid of it. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reported-by:
-
Joonas Lahtinen authored
Looks much better without container_of everywhere. v2: - In i915_gem_restore_gtt_mappings too (Chris) v3: - Do not cause WARN by calling on non PPGTT object (Chris) Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 06 Apr, 2016 4 commits
-
-
Matt Roper authored
intel_update_max_cdclk() doesn't have a switch case for Broxton, so dev_priv->max_cdclk_freq gets set to whatever clock frequency we're currently running at (e.g., 144 MHz) rather than the true maximum. This causes our max dotclock to also be set too low and in turn leads mode verification to reject perfectly valid modes while loading EDID firmware blobs. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459892239-14041-1-git-send-email-matthew.d.roper@intel.com
-
Kumar, Mahesh authored
Use plane size for relative data rate calculation. don't always use pipe source width & height. adjust height & width according to rotation. use plane size for watermark calculations also. v2: Address Matt's comments. Use intel_plane_state->visible to avoid divide-by-zero error. Where FB was present but not visible so causing total data rate to be zero, hence divide-by-zero. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93917 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94044 Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by:Kumar, Mahesh <mahesh1.kumar@intel.com> Reviewed-by:
-
Shubhangi Shrivastava authored
This patch sets the invert bit for hpd detection for each port based on VBT configuration. Since each AOB can be designed to depend on invert bit or not, it is expected if an AOB requires invert bit, the user will set respective bit in VBT. v2: Separated VBT parsing from the rest of the logic. (Jani) v3: Moved setting invert bit logic to bxt_hpd_irq_setup() and changed its logic to avoid looping twice. (Ville) v4: Changed the logic to mask out the bits first and then set them to remove need of temporary variable. (Ville) v5: Moved defines to existing set of defines for the register and added required breaks. (Ville) Signed-off-by:Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by:
Durgadoss R <durgadoss.r@intel.com> Signed-off-by:
Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> Reviewed-by:
-
Shubhangi Shrivastava authored
This patch adds new fields that are not yet added in drm code in child devices struct Signed-off-by:
-
- 05 Apr, 2016 10 commits
-
-
Ville Syrjälä authored
Currently we set the initial GPU frequency to min_freq_softlimit on gen9, and to efficient_freq on VLV/CHV. On all the other platforms we set it to idle_freq. Let's use idle_freq across the board to make sure we don't waste power. This is especially relevant for VLV since Vnn won't drop to minimum unless the GPU is at the minimum frequency. Signed-off-by:
-
Ville Syrjälä authored
Extract the GPLL reference frequency from CCK and use it in the GPU freq<->opcode conversions on VLV/CHV. This eliminates all the assumptions we have about which divider is used for which czclk frequency. Note that unlike most clocks from CCK, the GPLL ref clock is a divided down version of the CZ clock rather than the HPLL clock. CZ clock itself is a divided down version of the HPLL clock though, so in effect it just gets divided down twice. While at it, throw in a few comments explaining the remaining constants for anyone who later wants to compare this to the spreadsheets. v2: Add slow/fast notes for CHV clocks (Imre) Signed-off-by:
-
Dave Gordon authored
After a suspend-resume cycle, the resumed kernel has no idea what the booted kernel may have done to the GuC before replacing itself with the resumed image. In particular, it may have already loaded the GuC with firmware, which will then cause this kernel's attempt to (re)load the firmware to fail (GuC program memory is write-once!). The symptoms (GuC firmware reload fails after hibernation) are further described in the Bugzilla reference below. So let's *always* reset the GuC just before (re)loading the firmware; the hardware should then be in a well-known state, and we may even avoid some of the issues arising from unpredictable timing. Also added some more fields & values to the definition of the GUC_STATUS register, which is the key diagnostic indicator if the GuC load fails. Signed-off-by:
Dave Gordon <david.s.gordon@intel.com> Reviewed-by:
Arun Siluvery <arun.siluvery@linux.intel.com> Cc: Alex Dai <yu.dai@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94390Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
-
Arun Siluvery authored
Due to timing issues in the HW, some of the status bits required for GuC authentication occasionally don't get set; when that happens, the GuC cannot be initialized and we will be left with a wedged GPU. The W/A suggested is to perform a soft reset of the GuC and attempt to reload the F/W again for few times before giving up. As the failure is dependent on timing, tests performed by triggering manual full gpu reset (i915_wedged) showed that we could sometimes hit this after several thousand iterations, but sometimes tests ran even longer without any issues. Reset and reload mechanism proved helpful when we indeed hit f/w load failure, so it is better to include this to improve driver stability. This change implements the following WAs, WaEnableuKernelHeaderValidFix:skl,bxt WaEnableGuCBootHashCheckNotSet:skl,bxt Signed-off-by:
Alex Dai <yu.dai@intel.com> Signed-off-by:
-
Chris Wilson authored
Both the oom and vmap notifier callbacks have a loop to acquire the struct_mutex and set the device as uninterruptible, within a certain time. Refactor the common code into a pair of functions. Suggested-by:
-
Chris Wilson authored
If the core runs out of vmap address space, it will call a notifier in case any driver can reap some of its vmaps. As i915.ko is possibily holding onto vmap address space that could be recovered, hook into the notifier chain and try and reap objects holding onto vmaps. Signed-off-by:
-
Chris Wilson authored
vmaps are temporary kernel mappings that may be of long duration. Reusing a vmap on an object is preferrable for a driver as the cost of setting up the vmap can otherwise dominate the operation on the object. However, the vmap address space is rather limited on 32bit systems and so we add a notification for vmap pressure in order for the driver to release any cached vmappings. The interface is styled after the oom-notifier where the callees are passed a pointer to an unsigned long counter for them to indicate if they have freed any space. v2: Guard the blocking notifier call with gfpflags_allow_blocking() v3: Correct typo in forward declaration and move to head of file Signed-off-by:
-
Chris Wilson authored
Since we only attempt to purge an object if can_release_pages() report true, we should also only add it to the count of potential recoverable pages when can_release_pages() is true. Signed-off-by:
-
Jani Nikula authored
Reviewed-by:
-
Jani Nikula authored
In sequence block v2, and only in v2, the gpio source (i.e. IOSF port) is specified separately. v2: initialize gpio_source to 0 and handle v1 and v2 in the same branch Reviewed-by:
-
- 04 Apr, 2016 2 commits
-
-
Tvrtko Ursulin authored
Doing a lot of work in the interrupt handler introduces huge latencies to the system as a whole. Most dramatic effect can be seen by running an all engine stress test like igt/gem_exec_nop/all where, when the kernel config is lean enough, the whole system can be brought into multi-second periods of complete non-interactivty. That can look for example like this: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u8:3:143] Modules linked in: [redacted for brevity] CPU: 0 PID: 143 Comm: kworker/u8:3 Tainted: G U L 4.5.0-160321+ #183 Hardware name: Intel Corporation Broadwell Client platform/WhiteTip Mountain 1 Workqueue: i915 gen6_pm_rps_work [i915] task: ffff8800aae88000 ti: ffff8800aae90000 task.ti: ffff8800aae90000 RIP: 0010:[<ffffffff8104a3c2>] [<ffffffff8104a3c2>] __do_softirq+0x72/0x1d0 RSP: 0000:ffff88014f403f38 EFLAGS: 00000206 RAX: ffff8800aae94000 RBX: 0000000000000000 RCX: 00000000000006e0 RDX: 0000000000000020 RSI: 0000000004208060 RDI: 0000000000215d80 RBP: ffff88014f403f80 R08: 0000000b1b42c180 R09: 0000000000000022 R10: 0000000000000004 R11: 00000000ffffffff R12: 000000000000a030 R13: 0000000000000082 R14: ffff8800aa4d0080 R15: 0000000000000082 FS: 0000000000000000(0000) GS:ffff88014f400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa53b90c000 CR3: 0000000001a0a000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Stack: 042080601b33869f ffff8800aae94000 00000000fffc2678 ffff88010000000a 0000000000000000 000000000000a030 0000000000005302 ffff8800aa4d0080 0000000000000206 ffff88014f403f90 ffffffff8104a716 ffff88014f403fa8 Call Trace: <IRQ> [<ffffffff8104a716>] irq_exit+0x86/0x90 [<ffffffff81031e7d>] smp_apic_timer_interrupt+0x3d/0x50 [<ffffffff814f3eac>] apic_timer_interrupt+0x7c/0x90 <EOI> [<ffffffffa01c5b40>] ? gen8_write64+0x1a0/0x1a0 [i915] [<ffffffff814f2b39>] ? _raw_spin_unlock_irqrestore+0x9/0x20 [<ffffffffa01c5c44>] gen8_write32+0x104/0x1a0 [i915] [<ffffffff8132c6a2>] ? n_tty_receive_buf_common+0x372/0xae0 [<ffffffffa017cc9e>] gen6_set_rps_thresholds+0x1be/0x330 [i915] [<ffffffffa017eaf0>] gen6_set_rps+0x70/0x200 [i915] [<ffffffffa0185375>] intel_set_rps+0x25/0x30 [i915] [<ffffffffa01768fd>] gen6_pm_rps_work+0x10d/0x2e0 [i915] [<ffffffff81063852>] ? finish_task_switch+0x72/0x1c0 [<ffffffff8105ab29>] process_one_work+0x139/0x350 [<ffffffff8105b186>] worker_thread+0x126/0x490 [<ffffffff8105b060>] ? rescuer_thread+0x320/0x320 [<ffffffff8105fa64>] kthread+0xc4/0xe0 [<ffffffff8105f9a0>] ? kthread_create_on_node+0x170/0x170 [<ffffffff814f351f>] ret_from_fork+0x3f/0x70 [<ffffffff8105f9a0>] ? kthread_create_on_node+0x170/0x170 I could not explain, or find a code path, which would explain a +20 second lockup, but from some instrumentation it was apparent the interrupts off proportion of time was between 10-25% under heavy load which is quite bad. When a interrupt "cliff" is reached, which was >~320k irq/s on my machine, the whole system goes into a terrible state of the above described multi-second lockups. By moving the GT interrupt handling to a tasklet in a most simple way, the problem above disappears completely. Testing the effect on sytem-wide latencies using igt/gem_syslatency shows the following before this patch: gem_syslatency: cycles=1532739, latency mean=416531.829us max=2499237us gem_syslatency: cycles=1839434, latency mean=1458099.157us max=4998944us gem_syslatency: cycles=1432570, latency mean=2688.451us max=1201185us gem_syslatency: cycles=1533543, latency mean=416520.499us max=2498886us This shows that the unrelated process is experiencing huge delays in its wake-up latency. After the patch the results look like this: gem_syslatency: cycles=808907, latency mean=53.133us max=1640us gem_syslatency: cycles=862154, latency mean=62.778us max=2117us gem_syslatency: cycles=856039, latency mean=58.079us max=2123us gem_syslatency: cycles=841683, latency mean=56.914us max=1667us Showing a huge improvement in the unrelated process wake-up latency. It also shows an approximate halving in the number of total empty batches submitted during the test. This may not be worrying since the test puts the driver under a very unrealistic load with ncpu threads doing empty batch submission to all GPU engines each. Another benefit compared to the hard-irq handling is that now work on all engines can be dispatched in parallel since we can have up to number of CPUs active tasklets. (While previously a single hard-irq would serially dispatch on one engine after another.) More interesting scenario with regards to throughput is "gem_latency -n 100" which shows 25% better throughput and CPU usage, and 14% better dispatch latencies. I did not find any gains or regressions with Synmark2 or GLbench under light testing. More benchmarking is certainly required. v2: * execlists_lock should be taken as spin_lock_bh when queuing work from userspace now. (Chris Wilson) * uncore.lock must be taken with spin_lock_irq when submitting requests since that now runs from either softirq or process context. v3: * Expanded commit message with more testing data; * converted missed locking sites to _bh; * added execlist_lock comment. (Chris Wilson) v4: * Mention dispatch parallelism in commit. (Chris Wilson) * Do not hold uncore.lock over MMIO reads since the block is already serialised per-engine via the tasklet itself. (Chris Wilson) * intel_lrc_irq_handler should be static. (Chris Wilson) * Cancel/sync the tasklet on GPU reset. (Chris Wilson) * Document and WARN that tasklet cannot be active/pending on engine cleanup. (Chris Wilson/Imre Deak) Signed-off-by: -
Chris Wilson authored
Silences src/drivers/gpu/drm/i915/intel_ddi.c: warning: 'port' may be used uninitialized in this function [-Wuninitialized] Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
- 03 Apr, 2016 2 commits
-
-
Chris Wilson authored
As the current PCI power state is an essential feature of runtime pm, include it in the debugfs/i915_runtime_pm_status. v2: Use pci_power_name() Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1459689261-7920-2-git-send-email-chris@chris-wilson.co.uk
-
Chris Wilson authored
Since describe_obj() looks at state guarded by the struct_mutex, we need to be holding it. [ 580.201054] drv_suspend: starting subtest debugfs-reader [ 580.239652] ------------[ cut here ]------------ [ 580.239696] WARNING: CPU: 0 PID: 920 at include/linux/list_check.h:25 describe_obj+0x419/0x440() [ 580.239725] CPU: 0 PID: 920 Comm: cat Not tainted 4.5.0-rc6+ #835 [ 580.239745] Hardware name: /NUC5CPYB, BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015 [ 580.239767] 0000000000000000 ffff88027554fcf8 ffffffff812c1135 0000000000000000 [ 580.239815] ffffffff8193dc42 ffff88027554fd30 ffffffff8107419d ffff880071727c00 [ 580.239858] ffff8802757d8000 ffffffff818f693c ffffffff818f693c ffff8802757b9048 [ 580.239896] Call Trace: [ 580.239917] [<ffffffff812c1135>] dump_stack+0x67/0x92 [ 580.239939] [<ffffffff8107419d>] warn_slowpath_common+0x7d/0xb0 [ 580.239959] [<ffffffff810742ba>] warn_slowpath_null+0x1a/0x20 [ 580.239981] [<ffffffff813ce579>] describe_obj+0x419/0x440 [ 580.240006] [<ffffffff813ced22>] i915_gem_framebuffer_info+0xa2/0x100 [ 580.240033] [<ffffffff811a9286>] seq_read+0xe6/0x3b0 [ 580.240059] [<ffffffff81182288>] __vfs_read+0x28/0xd0 [ 580.240085] [<ffffffff81173378>] ? SyS_fadvise64+0x228/0x2c0 [ 580.240112] [<ffffffff811823b2>] vfs_read+0x82/0x110 [ 580.240137] [<ffffffff811827d9>] SyS_read+0x49/0xa0 [ 580.240162] [<ffffffff815bac57>] entry_SYSCALL_64_fastpath+0x12/0x6b [ 580.240187] ---[ end trace 3e2cbf34576c9878 ]--- [ 580.281900] ------------[ cut here ]------------ Signed-off-by:
-
- 01 Apr, 2016 7 commits
-
-
Ville Syrjälä authored
Deal with errors from drm_universal_plane_init() in primary and cursor plane init paths (sprites were already covered). Also make the code neater by using goto for error handling. v2: Rebased due to drm_universal_plane_init() 'name' parameter v3: Another rebase due to s/""/NULL/ v4: Rebased on drm-nightly (Matthew Auld) v5: Fix email address (Matthew Auld) Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458571402-32749-1-git-send-email-matthew.auld@intel.com
-
Ville Syrjälä authored
VLV DPLL is somewhat sane and doesn't run on luck. Signed-off-by:
-
Ville Syrjälä authored
Supposedly the power sequencer still locks out the DPLL registers on CHV, so let's issue a warning if it's still locked when enabling the DPLL. Also drop the redundant IS_MOBILE() check for VLV when we check the same thing. Signed-off-by:
-
Ville Syrjälä authored
Avoid redundant crtc->pipe lookups by giving vlv_enable_pll() a local pipe variable. Also makes it look more like the corresponding CHV code. While at is change the CHV code to enum pipe from int, Signed-off-by:
-
Ville Syrjälä authored
DPLL_MD(PIPE_C) is AWOL on CHV. Instead of fixing it someone added chicken bits to propagate the pixel multiplier from DPLL_MD(PIPE_B) to either pipe B or C. So do that to make pixel repeat work on pipes B and C. Pipe A is fine without any tricks. Fortunately the pixel repeat propagation appears to be a oneshot operation, so once the value has been written we can clear the chicken bits. So it is still possible to drive pipe B and C with different pixel multipliers simultaneosly. Looks like DPLL_VGA_MODE_DIS must also be set in DPLL(PIPE_B) for this to work. But since we keep that bit always set in all DPLLs there's no problem. This of course means we can't reliably read out the pixel multiplier for pipes B and C. That would make the state checker unhappy, so I added shadow copies of those registers in to dev_priv. The other option would have been to skip pixel multiplier, dpll_md an dotclock checks entirely on CHV, but that feels like a serious loss of cross checking, so just pretending that we have working DPLL MD registers seemed better. Obviously with the shadow copies we can't detect if the pixel multiplier was properly configured, nor can we take over its state from the BIOS, but hopefully people won't have displays that would be limitd to such crappy modes. There is one strange flicker still remaining. It's visible on pipe C/HDMID when HDMIB is enabled while driven by pipe B. It doesn't occur if pipe A drives HDMIB, nor is there any glitch on pipe B/HDMIB when port C/HDMID starts up. I don't have a board with HDMIC so not sure if it happens there too. So I'm not sure if it's somehow tied in with this strange linkage between pipe B and C. Sadly I was unable to find an enable sequence that would avoid the glitch, but at least it's not fatal ie. the output recovers afterwards. Signed-off-by:
-
Ville Syrjälä authored
The VLV and CHV DPLL disable and update are almost identical in how the DPLL/DPLL_MD registers need to be set up. But the code looks more different than it really is. Try to bring them into line. Note that we now leave the refclock always enabled for both DPLLs in the dual channel PHY. But that's perfectly fine since it's the same clock, and we anyway already do that when turning the disp2d power well on. v2: s/chv_update_pll/chv_compute_dpll/ v3: Add a note that we leave refclocks enabled for both DPLLs (Jani) Signed-off-by:
-
Ville Syrjälä authored
These BUGs don't serve any purpose IMO. Throw them out. Signed-off-by:
-
