- 04 May, 2016 3 commits
-
-
Daniel Vetter authored
LPT is pch, so might run into the fdi bandwidth constraint (especially since it has only 2 lanes). But right now we just force pipe_bpp back to 24, resulting in a nice loop (which we bail out with a loud WARN_ON). Fix this. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=93477Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Tested-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: stable@vger.kernel.org Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1462264381-7573-1-git-send-email-daniel.vetter@ffwll.ch
-
Matthew Auld authored
Only has one user and is nothing more than a shim on top of i915_vma_unbind, so let's just get rid of it. Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Suggested-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Signed-off-by:
-
Tvrtko Ursulin authored
They use dev_priv exclusively so pass it in instead of dev for smaller source and binary. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
-
- 03 May, 2016 5 commits
-
-
Lyude authored
Right now MST audio is causing too many kernel panics to really keep around in the kernel. On top of that, even after fixing said panics it's still basically non-functional (at least on all the setups I've tested it on). Revert until we have a proper solution for this. This reverts commit 3d52ccf5. Signed-off-by:
Lyude <cpaul@redhat.com> Fixes: 3d52ccf5 ("drm/i915: start adding dp mst audio") Cc: stable@vger.kernel.org Signed-off-by:
-
Ville Syrjälä authored
GPIO lookup tables are supposed to be zero terminated. Let's do that and avoid accidentally walking off the end. Cc: Shobhit Kumar <shobhit.kumar@intel.com> Cc: Samuel Ortiz <sameo@linux.intel.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Alexandre Courbot <gnurou@gmail.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Lee Jones <lee.jones@linaro.org> Cc: stable@vger.kernel.org Fixes: 61dd2ca2 ("mfd: intel_soc_pmic_core: Add lookup table for Panel Control as GPIO signal") Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Thierry Reding <treding@nvidia.com> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Imre Deak authored
While browsing BSpec I bumped into a note saying we need to tune these values based on actual measurements done after initial enabling. I've checked that it indeed improves things on BXT. I haven't checked this on CHV, but here it is if someone wants to give it a go. v2: - Add note about the discrepancy wrt. to the spec in the formula calculating the credit encodings. (Mika, Ville) - Move the WA comment to the new function. (Ville) v3: - Keep the comment about the SQC WA in the caller. (Ville) CC: Ville Syrjälä <ville.syrjala@linux.intel.com> CC: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Imre Deak authored
No need for hard-coding the register value, the corresponding fields are defined properly in BSpec. No functional change. v2: - Rebased on BXT L3 SQC tuning patch merged meanwhile. CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
BSpec requires us to wait ~100 clocks before re-enabling clock gating, so make sure we do this. CC: stable@vger.kernel.org CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
- 02 May, 2016 4 commits
-
-
Deepak M authored
These fields in VBT indicates the PWM source which is used and also the controller number. v2 by Jani: check for out of bounds access, some renames, change default type, etc. v3 by Jani: s/INTEL_BACKLIGHT_CABC/INTEL_BACKLIGHT_DSI_DCS/ Signed-off-by:
Deepak M <m.deepak@intel.com> Signed-off-by:
-
Praveen Paneri authored
i915_gem_shrink() will scan the bound list only if device is not suspended but in OOM failure scenario it becomes absolutely necessary to release as much memory as possible. Also in allocation failure from vmap address space, it is incumbent on the Driver to reap all its vmaps. So, adding rpm get/put in i915_gem_shrinker_oom() and i915_gem_shrinker_vmap() to ensure shrinking of bound objects as well. Signed-off-by:
Praveen Paneri <praveen.paneri@intel.com> Reviewed-by:
-
Praveen Paneri authored
When the system is running low on memory, gem shrinker is invoked. In this process objects will be unbounded from GTT and unbinding process will require access to GTT(GTTADR) and also to fence register potentially. That requires a resume of gfx device, if suspended, in the shrinker path. Considering the power leakage due to intermediate resume, perform unbinding operation only if device is already runtime active. v2: Use newly implemented intel_runtime_pm_get_if_in_use (Chris) Signed-off-by:
Akash Goel <akash.goel@intel.com> Signed-off-by:
-
Jani Nikula authored
The LVDS border enable is independent from the panel fitter. Move the readout of the "border bits" from i9xx_get_pfit_config() to intel_lvds_get_config(), where it will be read if LVDS is enabled even if the panel fitter is not. This fixes the state checker warning: [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in gmch_pfit.lvds_border_bits (expected 0x00008000, found 0x00000000) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: drm-intel-fixes@lists.freedesktop.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87632Reviewed-by:
Sitsofe Wheeler <sitsofe@yahoo.com> Signed-off-by:
-
- 29 Apr, 2016 19 commits
-
-
Chris Wilson authored
We have sufficient evidence from igt to support that semaphores are in a working state. Enabling semaphores now for legacy provides a better comparison of execlists against legacy ring submission. Signed-off-by:
-
Chris Wilson authored
When the engine idles waiting upon a semaphore, it loses its pagetables and we must reload them before executing the batch. v2: Restrict w/a to non-RCS rings (RCS works correctly apparently). Signed-off-by:
-
Chris Wilson authored
In order for the MI_SEMAPHORE_SIGNAL command to wait until after the pipecontrol writing the signal value is complete, we have to pause the CS inside the PIPE_CONTROL with the CS_STALL bit. Signed-off-by:
-
Chris Wilson authored
With the introduction of a distinct engine->id vs the hardware id, we need to fix up the value we use for selecting the target engine when signaling a semaphore. Note that these values can be merged with engine->guc_id. Fixes: de1add36Signed-off-by:
-
Chris Wilson authored
The i915.enable_ppgtt option depends upon the state of i915.enable_execlists option - so we need to sanitize execlists first. Signed-off-by:
-
Chris Wilson authored
For legacy ringbuffer mode, we need the new ordered breadcrumb emission tried and tested on execlists in order to avoid the dreaded "missed interrupt" syndrome. A secondary advantage of the execlists method is that it writes to an arbitrary address, useful if one wants to write a breadcrumb elsewhere. This fix is taken from commit 7c17d377 (drm/i915: Use ordered seqno write interrupt generation on gen8+ execlists). Signed-off-by:
-
Chris Wilson authored
At the start of request emission, we flush some space for the request, estimating the typical size for the request body. The common tail is now much larger than the typical body, so we can shrink the flush substantially. Signed-off-by:
-
Chris Wilson authored
At the start of request emission, we flush some space for the request, estimating the typical size for the request body. The tail is now much larger than the typical body, so we can shrink the flush slightly. Signed-off-by:
-
Chris Wilson authored
With 5 rings and a flush, we need 192 bytes of space to emit the breadcrumb and semaphores. However, we need some spare room the size of the single largest packet (36 dwords, 144 bytes) to accommodate wraparound giving a grand total of 336 bytes Signed-off-by:
-
Ander Conselvan de Oliveira authored
This moves the last phy specific code from the encoders to the phy specific file. Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by:
Jim Bride <jim.bride@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461761065-21195-11-git-send-email-ander.conselvan.de.oliveira@intel.com
-
Ander Conselvan de Oliveira authored
The phy code in vlv_pre_enable_dp() and vlv_hdmi_pre_enable() is exectly the same, so extract it to intel_dpio_phy.c. Signed-off-by:
-
Ander Conselvan de Oliveira authored
The code used by the DP and HDMI paths was very similar, so make them share it. Note that this removes the write to signal level registers from the HDMI pre pll enable path, but that's OK since those are set in vlv_hdmi_pre_enable() function. Signed-off-by:
-
Ander Conselvan de Oliveira authored
The logic for setting signal levels is used for both HDMI and DP with small variations. But it is similar enough to put behind a function called from the encoders. v2: Remove unrelated MST changes due to rebase fumble. (Jim Bride) Fix typo in the commit message. (Jim Bride) v3: Really fix the typo. (Jim) Cc: Jim Bride <jim.bride@linux.intel.com> Signed-off-by: -
Ander Conselvan de Oliveira authored
The exact same code was used by HDMI and DP encoders, so move it to intel_dpio_phy.c. v2: Fix typo in the commit message. (Jim Bride) v3: Call the new function chv_phy_post_pll_disable() instead of chv_phy_post_disable(), as it should be called after the pll is disabled. (Ville) Cc: Jim Bride <jim.bride@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: -
Ander Conselvan de Oliveira authored
The only difference between the DP and HDMI versions was the lane count. Since lane_count is now set appropriately for HDMI too, get rid of the duplication and move this to intel_dpio_phy.c v2: Don't move comments about 2nd common lane staying alive. (Ville) Signed-off-by:
-
Ander Conselvan de Oliveira authored
The same logic is used for DP and HDMI so move it to intel_dpio_phy.c. v2: Rebase Signed-off-by:
-
Ander Conselvan de Oliveira authored
The function chv_data_lane_soft_reset() was duplicated in DP and HDMI code. Move it to intel_dpio_phy.c. Signed-off-by:
-
Ander Conselvan de Oliveira authored
The code for programming voltage swing and emphasis was duplicated between DP and HDMI code. Move that to a new file, intel_dpio_phy.c. v2: Keep the "Use 800mV-0dB" comment in the HDMI code. (Ville) Signed-off-by:
-
Ander Conselvan de Oliveira authored
Set the lane count for HDMI to 4. This will make it easier to unduplicate CHV phy code. This also fixes the the soft reset programming for HDMI with CHV. After commit a8f327fb ("drm/i915: Clean up CHV lane soft reset programming"), it wouldn't set the right bits for PCS23 since it relied on a lane count that was never set. v2: Set lane_count in *_get_config() to please state checker. (0day) v3: Set lane_count for DDI in DVI mode too. (CI) v4: Add note about CHV soft lane reset. (Ander) Fixes: a8f327fb ("drm/i915: Clean up CHV lane soft reset programming") Signed-off-by:
-
- 28 Apr, 2016 9 commits
-
-
Ville Syrjälä authored
The comment about GMBUSFREQ is confused. The spec actually explains the 4MHz thing perfectly by noting that the 4MHz divider values is actually just bits [9:2] not [9:0], hence the divide by 1000 correct. Replace the confused note with a quote from the spec, and eliminate the duplicated comment that snuck in. Signed-off-by:
Mika Kahola <mika.kahola@intel.com>
-
Ville Syrjälä authored
No point in reading the cdclk out from the hardware every single time since we have it cached already. Just return the cached value to the audio driver. Signed-off-by:
-
Ville Syrjälä authored
Update CDCLK_FREQ on BDW after changing the cdclk frequency. Not sure if this is a late addition to the spec, or if I simply overlooked this step when writing the original code. This is what Bspec has to say about CDCLK_FREQ: "Program this field to the CD clock frequency minus one. This is used to generate a divided down clock for miscellaneous timers in display." And the "Broadwell Sequences for Changing CD Clock Frequency" section clarifies this further: "For CD clock 337.5 MHz, program 337 decimal. For CD clock 450 MHz, program 449 decimal. For CD clock 540 MHz, program 539 decimal. For CD clock 675 MHz, program 674 decimal." Cc: stable@vger.kernel.org Cc: Mika Kahola <mika.kahola@intel.com> Fixes: b432e5cf ("drm/i915: BDW clock change support") Signed-off-by:
-
Ramalingam C authored
In BXT DSI there is no regs programmed with few horizontal timings in Pixels but txbyteclkhs.. So retrieval process adds some ROUND_UP ERRORS in the process of PIXELS<==>txbyteclkhs. Actually here for the given adjusted_mode, we are calculating the value programmed to the port and then back to the horizontal timing param in pixels. This is the expected value at the end of get_config, including roundup errors. And if that is same as retrieved value from port, then retrieved (HW state) adjusted_mode's horizontal timings are corrected to match with SW state to nullify the errors. Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> Acked-by:
-
Ramalingam C authored
Retriving the horizontal timings from the port registers as part of get_config(). This fixes a division by zero: [ 56.916557] divide error: 0000 [#1] PREEMPT SMP [ 56.921741] Modules linked in: i915(+) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm intel_gtt agpgart cf g80211 rfkill binfmt_misc ax88179_178a kvm_intel kvm irqbypass crc32c_intel efivars tpm_tis tpm fuse [ 56.944106] CPU: 3 PID: 1097 Comm: modprobe Not tainted 4.6.0-rc4+ #433 [ 56.951501] Hardware name: Intel Corp. Broxton M/RVP, BIOS BXT1RVPA.X64.0131.B30.1604142217 04/14/2016 [ 56.961908] task: ffff88007a854d00 ti: ffff88007aea0000 task.ti: ffff88007aea0000 [ 56.970273] RIP: 0010:[<ffffffffa01235b2>] [<ffffffffa01235b2>] drm_mode_hsync+0x22/0x40 [drm] [ 56.980043] RSP: 0018:ffff88007aea3788 EFLAGS: 00010206 [ 56.985982] RAX: 000000000788b600 RBX: ffff880073c22108 RCX: 0000000000000000 [ 56.993957] RDX: 0000000000000000 RSI: ffff88007ab06800 RDI: ffff880073c22108 [ 57.001935] RBP: ffff88007aea3788 R08: 0000000000000001 R09: ffff880073c221e8 [ 57.009903] R10: ffff880073c22108 R11: 0000000000000001 R12: ffff88007a300000 [ 57.017872] R13: ffff880073c22000 R14: ffff880175f78000 R15: ffff880175f78798 [ 57.025849] FS: 00007f105d3e6700(0000) GS:ffff88017fd80000(0000) knlGS:0000000000000000 [ 57.034894] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 57.041317] CR2: 00007f4d485101d0 CR3: 000000007a820000 CR4: 00000000003406e0 [ 57.049292] Stack: [ 57.051539] ffff88007aea37a0 ffffffffa043b632 ffff880175f787c8 ffff88007aea3810 [ 57.059825] ffffffffa043d59e ffff880175f787b0 ffff88007ab68c00 ffff88007aea37f0 [ 57.068128] ffff880073c221e8 ffff880073c22108 ffff880175f78780 ffff880100000000 [ 57.076430] Call Trace: [ 57.079254] [<ffffffffa043b632>] intel_mode_from_pipe_config+0x82/0xb0 [i915] [ 57.087405] [<ffffffffa043d59e>] intel_modeset_setup_hw_state+0x55e/0xd60 [i915] [ 57.095847] [<ffffffffa043ff94>] intel_modeset_init+0x8e4/0x1630 [i915] [ 57.103415] [<ffffffffa047bcf0>] i915_driver_load+0xbe0/0x1980 [i915] [ 57.110745] [<ffffffffa0116c19>] drm_dev_register+0xa9/0xc0 [drm] [ 57.117681] [<ffffffffa011921d>] drm_get_pci_dev+0x8d/0x1e0 [drm] [ 57.124600] [<ffffffff8195f942>] ? _raw_spin_unlock_irqrestore+0x42/0x70 [ 57.132253] [<ffffffffa03b0384>] i915_pci_probe+0x34/0x50 [i915] [ 57.139070] [<ffffffff8149c375>] local_pci_probe+0x45/0xa0 [ 57.145303] [<ffffffff8149d300>] ? pci_match_device+0xe0/0x110 [ 57.151924] [<ffffffff8149d6cb>] pci_device_probe+0xdb/0x130 [ 57.158355] [<ffffffff81579b93>] driver_probe_device+0x223/0x440 [ 57.165169] [<ffffffff81579e85>] __driver_attach+0xd5/0x100 [ 57.171500] [<ffffffff81579db0>] ? driver_probe_device+0x440/0x440 [ 57.178510] [<ffffffff81577736>] bus_for_each_dev+0x66/0xa0 [ 57.184841] [<ffffffff815793de>] driver_attach+0x1e/0x20 [ 57.190881] [<ffffffff81578d6e>] bus_add_driver+0x1ee/0x280 [ 57.197212] [<ffffffff8157abc0>] driver_register+0x60/0xe0 [ 57.203447] [<ffffffff8149bc50>] __pci_register_driver+0x60/0x70 [ 57.210285] [<ffffffffa0119450>] drm_pci_init+0xe0/0x110 [drm] [ 57.216911] [<ffffffff810dcd8d>] ? trace_hardirqs_on+0xd/0x10 [ 57.223434] [<ffffffffa023a000>] ? 0xffffffffa023a000 [ 57.229237] [<ffffffffa023a092>] i915_init+0x92/0x99 [i915] [ 57.235570] [<ffffffff810003db>] do_one_initcall+0xab/0x1d0 [ 57.241900] [<ffffffff810f9eef>] ? rcu_read_lock_sched_held+0x7f/0x90 [ 57.249205] [<ffffffff81204f18>] ? kmem_cache_alloc_trace+0x248/0x2b0 [ 57.256509] [<ffffffff811a5eee>] ? do_init_module+0x27/0x1d9 [ 57.262934] [<ffffffff811a5f26>] do_init_module+0x5f/0x1d9 [ 57.269167] [<ffffffff8112392f>] load_module+0x20ef/0x27b0 [ 57.275401] [<ffffffff8111f8e0>] ? store_uevent+0x40/0x40 [ 57.281541] [<ffffffff81124243>] SYSC_finit_module+0xc3/0xf0 [ 57.287969] [<ffffffff8112428e>] SyS_finit_module+0xe/0x10 [ 57.294203] [<ffffffff81960069>] entry_SYSCALL_64_fastpath+0x1c/0xac [ 57.301406] Code: ff 5d c3 66 0f 1f 44 00 00 0f 1f 44 00 00 8b 87 d8 00 00 00 55 48 89 e5 85 c0 75 22 8b 4f 68 85 c9 78 1b 69 47 58 e8 03 00 00 99 <f7> f9 b9 d3 4d 62 10 05 f4 01 00 00 f7 e1 89 d0 c1 e8 06 5d c3 [ 57.322964] RIP [<ffffffffa01235b2>] drm_mode_hsync+0x22/0x40 [drm] [ 57.330103] RSP <ffff88007aea3788> [ 57.334276] ---[ end trace d414224cb2e2a4cf ]--- [ 57.339861] modprobe (1097) used greatest stack depth: 12048 bytes left Fixes: 6f0e7535 ("drm/i915/BXT: Get pipe conf from the port registers") Signed-off-by:
-
Chris Wilson authored
Both execlists and legacy need to reset the context (and mode) of the GPU before we lose control of the system. By resetting the GPU, we revert back to default settings. This simplifies the life of any subsequent driver (in particular for virtualized setups) as it does not then have to try and recover from an unknown condition. As both paths need to reset for the same reason, move the reset to a common point. This unifies the resets added in a647828a (drm/i915: Also perform gpu reset under execlist mode) and 8e96d9c4 (drm/i915: reset the GPU on context fini). v2: Restrict the reset to "modern" gen (where we enable HW contexts) to try and avoid leaving the machine in an unusable state with a risky reset on older GPU. This should keep the status quo as to who performs resets (i.e. currently only GPUs with HW contexts perform a reset on shutdown). Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461833819-3991-25-git-send-email-chris@chris-wilson.co.uk
-
Tvrtko Ursulin authored
With the previous patch having extended the pinned lifetime of contexts by referencing the previous context from the current request until the latter is retired (completed by the GPU), we can now remove usage of execlist retired queue entirely. This is because the above now guarantees that all execlist object access requirements are satisfied by this new tracking, and we can stop taking additional references and stop keeping request on the execlists retired queue. The latter was a source of significant scalability issues in the driver causing performance hits on some tests. Most dramatical of which was igt/gem_close_race which had run time in tens of minutes which is now reduced to tens of seconds. Signed-off-by:
Tvrtko Ursulin <tvrtko@ursulin.net> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Tvrtko Ursulin authored
This way in the following patch we can disconnect requests from contexts. Signed-off-by:
-
Chris Wilson authored
As the contexts are accessed by the hardware until the switch is completed to a new context, the hardware may still be writing to the context object after the breadcrumb is visible. We must not unpin/unbind/prune that object whilst still active and so we keep the previous context pinned until the following request. We can generalise the tracking we already do via the engine->last_context and move it to the request so that it works equally for execlists and GuC. v2: Drop the execlists double pin as that exposes a race inside the lrc irq handler as it tries to access the context after it may be retired. Signed-off-by:
-
