- 29 Mar, 2017 6 commits
-
-
Ben Widawsky authored
They're the same, so use the one which makes more sense. Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Link: http://patchwork.freedesktop.org/patch/msgid/20170324212950.2206-1-ben@bwidawsk.netReviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
This reverts commit 6c943de6 ("drm/i915: Skip execlists_dequeue() early if the list is empty"). The validity of using READ_ONCE there depends upon having a mb to coordinate the assignment of engine->execlist_first inside submit_request() and checking prior to taking the spinlock in execlists_dequeue(). We wrote "the update to TASKLET_SCHED incurs a memory barrier making this cross-cpu checking safe", but failed to notice that this mb was *conditional* on the execlists being ready, i.e. there wasn't the required mb when it was most necessary! We could install an unconditional memory barrier to fixup the READ_ONCE(): diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 7dd732cb9f57..1ed164b16d44 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -616,6 +616,7 @@ static void execlists_submit_request(struct drm_i915_gem_request *request) if (insert_request(&request->priotree, &engine->execlist_queue)) { engine->execlist_first = &request->priotree.node; + smp_wmb(); if (execlists_elsp_ready(engine)) But we have opted to remove the race as it should be rarely effective, and saves us having to explain the necessary memory barriers which we quite clearly failed at. Reported-and-tested-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Fixes: 6c943de6 ("drm/i915: Skip execlists_dequeue() early if the list is empty") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170329100052.29505-1-chris@chris-wilson.co.ukReviewed-by:
-
Chris Wilson authored
Unlocking is dangerous. In this case we combine an early update to the out-of-queue request, because we know that it will be inserted into the correct FIFO priority-ordered slot when it becomes ready in the future. However, given sufficient enthusiasm, it may become ready as we are continuing to reschedule, and so may gazump the FIFO if we have since dropped its spinlock. The result is that it may be executed too early, before its dependencies. v2: Move all work into the second phase over the topological sort. This removes the shortcut on the out-of-rbtree request to ensure that we only adjust its priority after adjusting all of its dependencies. Fixes: 20311bd3 ("drm/i915/scheduler: Execute requests in order of priorities") Testcase: igt/gem_exec_whisper Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
-
Michal Wajdeczko authored
We can't sometimes use these macros in other headers due to include and definition order. As i915_utils.h already contains other helper macros move these macros there. v2: checkpatch cleanup for WARN() macro. Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170328084513.174200-1-michal.wajdeczko@intel.comSigned-off-by:
-
Daniel Vetter authored
Backmerge drm-next one more because Dave fumbled the conflict resolution slightly and I didn't notice it. We need Zhenyu's hotfix before he can assemble the gvt pull ... Signed-off-by:Daniel Vetter <daniel.vetter@intel.com>
-
Zhenyu Wang authored
From commit 73dec95e ("drm/i915: Emit to ringbuffer directly"), copy_gma_to_hva() now returns copied data length instead of 0, so need to change error return check for that. Note: Looks this is caused by backmerge conflict resolving, so 4.11-rc4 is not impacted as commit 73dec95e ("drm/i915: Emit to ringbuffer directly") is not in 4.11. But need to fix this before I can apply 4.12 stuff against drm-intel-next correctly. Fixes: e5c1ff14 ("Backmerge tag 'v4.11-rc4' into drm-next") Cc: Dave Airlie <airlied@redhat.com> Cc: Tina Zhang <tina.zhang@intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
- 28 Mar, 2017 10 commits
-
-
Jani Nikula authored
Several major vendor USB-C->HDMI converters, in particular the DA200, fail to recover a 5.4 GHz 1 lane signal if the link N is greater than 0x80000. The link M and N depend on the pixel clock and link clock ratio. With current code link N exceeds 0x80000 only when link clock >= 540000 kHz. Except for the eDP intermediate link clocks, at least the four least significant bits are always zero. Just one bit shift right would be enough to bring even the DP 1.4 810000 kHz link clock under 0x80000 link N. The pixel clock for modes that require a link clock >= 540000 kHz would also have several least significant bits zero. Unless the user provides a mode with an odd pixel clock value, we can reduce the numbers to reach the goal, with no loss in precision. The DP spec even mentions sources making choices that "allow for static and relatively small Mvid and Nvid values", thus reducing the link M/N regardless of the sink in question seems justified. Everything here is based on the work and information gathered by Clint Taylor <clinton.a.taylor@intel.com>. This is just an iteration to reduce the parameters regardless of lane count, link rate, or sink. Reference: http://patchwork.freedesktop.org/patch/msgid/1490225256-11667-1-git-send-email-clinton.a.taylor@intel.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93578Tested-by:
Mads <mads@ab3.no> Tested-by:
PJ <foobar@pjmodos.net> Tested-by:
François Guerraz <kubrick@fgv6.net> Tested-by:
Lev Popov <leo@nabam.net> Tested-by:
Igor Krivenko <igor.s.krivenko@gmail.com> Tested-by:
Clint Taylor <clinton.a.taylor@intel.com> Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1490614405-23337-1-git-send-email-jani.nikula@intel.com
-
Chris Wilson authored
Capturing GPU state requires the device to be awake in order to read registers. Normally, this is taken along the error handler, but for the direct debugfs access, we cannot make assumptions about the current device state and so either need to wake it up, or abort. Fixes: 5a4c6f1b ("drm/i915: The return of i915_gpu_info to debugfs") Testcase: igt/pm_rpm/debugfs-read Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com>
-
Imre Deak authored
We don't expect the core runtime PM get helpers to return any error, so add a WARN for this. Also print the return value for all the callsites to help debugging. v2: - Don't call pm_runtime_get_sync() as part of initing locals. (Chris) Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Matthew Auld authored
Don't throw a warning if we are given an invalid property id. While here let's also bring back Robert' original idea of catching unhandled enumeration values at compile time. Fixes: eec688e1 ("drm/i915: Add i915 perf infrastructure") Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Robert Bragg <robert@sixbynine.org> Reviewed-by:
Robert Bragg <robert@sixbynine.org> Signed-off-by:
-
Jani Nikula authored
The old URL works but gives 301 Moved Permanently. Update. Reviewed-by:
-
Daniel Vetter authored
Backmerge drm-next to get at -rc4, which we need to land the 4.12 gvt patches. Signed-off-by: -
Dave Airlie authored
Linux 4.11-rc4 The i915 GVT team need the rc4 code to base some more code on.
-
Matthew Auld authored
If we were to ever encounter a sample_flags mismatch we need to ensure we destroy the stream when we bail. Fixes: d7965152 ("drm/i915: Enable i915 perf stream for Haswell OA unit") Signed-off-by:
-
Shashank Sharma authored
Geminilake has a native HDMI 2.0 controller, which is capable of driving clocks upto 594Mhz. This patch updates the max tmds clock limit for the same. V2: rebase V3: rebase V4: added r-b from Ander V5: rebase V6: rebase V7: rebase V8: rebase V9: rebase V10: rebase Cc: Ander Conselvan De Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by:
Shashank Sharma <shashank.sharma@intel.com> Reviewed-by:
Ander Conselvan De Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by:
-
Shashank Sharma authored
Geminilake platform sports a native HDMI 2.0 controller, and is capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec mendates scrambling for these higher clocks, for reduced RF footprint. This patch checks if the monitor supports scrambling, and if required, enables it during the modeset. V2: Addressed review comments from Ville: - Do not track scrambling status in DRM layer, track somewhere in driver like in intel_crtc_state. - Don't talk to monitor at such a low layer, set monitor scrambling in intel_enable_ddi() before enabling the port. V3: Addressed review comments from Jani - In comments, function names, use "sink" instead of "monitor", so that the implementation could be close to the language of HDMI spec. V4: Addressed review comment from Maarten - scrambling -> hdmi_scrambling - high_tmds_clock_ratio -> hdmi_high_tmds_clock_ratio V5: Addressed review comments from Ville and Ander - Do not modifiy the crtc_state after compute_config. Move all scrambling and tmds_clock_ratio calcutations to compute_config. - While setting scrambling for source/sink, do not check the conditions again, just go by the crtc_state flags. This will simplyfy the condition checks. V6: Addressed review comments from Ville - Do not add IS_GLK check in disable/enable function, instead add it in compute_config, while setting state flags. - Remove unnecessary paranthesis. - Simplyfy handle_sink_scrambling function as suggested. - Add readout code for scrambling status in get_ddi_config and add a check for the same in pipe_config_compare. V7: Addressed review comments from Ander/Ville - No separate function for source scrambling, make it inline - Align the last line of the macro TRANS_DDI_HDMI_SCRAMBLING_MASK - Do not add platform check while setting source scrambling - Use pipe_config instead of crtc->config to set sink scrambling - To readout scrambling status, Compare with SCRAMBLING_MASK not any of its bits - Remove platform check in intel_pipe_config_compare while checking scrambling status V8: Fixed mege conflict, Addressed review comments from Ander - Remove the desciption/comment about scrambling fom the caller, move it to the function - Move the IS_GLK check into scrambling function - Fix alignment V9: Fixed review comments from Ville, Ander - Pass the scrambling state variables as bool input to the sink_scrambling function and let the disable call be unconditional. - Fix alignments in function calls and debug messages. - Add kernel doc for function intel_hdmi_handle_sink_scrambling V10: Rebase Signed-off-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by:
-
- 27 Mar, 2017 19 commits
-
-
Paulo Zanoni authored
All it does is pick the encoder and call intel_get_shared_dpll(). We can just do this in the caller. One less indirection level during code reading. As another plus, now the two callers of intel_get_shared_dpll() are {ironlake,haswell}_crtc_compute_clock(). Reported-by:Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
Chris Wilson authored
Use the incoming value from debugfs/i915_wedged to select which engines to marked as guilty in order to force us to reset those requests (required to quickly bypass simulated hangs). Testcase: igt/gem_exec_capture Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
Chris Wilson authored
Whilst I like having the assertions clearly visible in the code, they are quite repetitious! As we find new limits we want to incorporate into the set of assertions, it make sense to refactor them to a common routine. v2: Add a guc holdout. Signed-off-by:
-
Chris Wilson authored
In addition to being qword-aligned, the RING_TAIL offset must be within the ring! Signed-off-by:
-
Chris Wilson authored
If the request->wa_tail is 0 (because it landed exactly on the end of the ringbuffer), when we reconstruct request->tail following a reset we fill in an illegal value (-8 or 0x001ffff8). As a result, RING_HEAD is never able to catch up with RING_TAIL and the GPU spins endlessly. If the ring contains a couple of breadcrumbs, even our hangcheck is unable to catch the busy-looping as the ACTHD and seqno continually advance. v2: Move the wrap into a common intel_ring_wrap(). Fixes: a3aabe86 ("drm/i915/execlists: Reinitialise context image after GPU hang") Signed-off-by:
-
Ville Syrjälä authored
All the pre-SKL sprite planes compute the x/y/tile offsets in a similar way. There are a couple of minor differences but the primary planes have those as well. Thus i9xx_check_plane_surface() already does what we need, so let's use it. Signed-off-by:
-
Ville Syrjälä authored
The effective difference between i9xx_update_primary_plane() and ironlake_update_primary_plane() is only the HSW/BDW DSPOFFSET special case. So bring that over into i9xx_update_primary_plane() and eliminate the duplicated code. Signed-off-by:
-
Ville Syrjälä authored
Extract the primary plane surfae offset/x/y calculations for pre-SKL platforms into a common function, and call it during the atomic check phase to reduce the amount of stuff we have to do during the commit phase. SKL is already doing this. v2: Update the comment about the rotation adjustments to match the code better (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: -
Ville Syrjälä authored
Computing the plane control register value is branchy so moving it out from the plane commit hook seems prudent. Let's pre-compute it during the atomic check phase and store the result in the plane state. Signed-off-by:
-
Ville Syrjälä authored
Share the code to compute the primary plane control register value between the i9xx and ilk codepaths as the differences are minimal. Actually there are no differences between g4x and ilk, so the current split doesn't really make any sense. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Ville Syrjälä authored
Pull the code to calculate the pre-SKL primary plane control register value into separate functions. Allows us to pre-compute it in the future. v2: Split the pre-ilk vs. ilk+ unification to a separate patch (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Chris Wilson authored
Since the engine's flag is just the bit of its id, use BIT(). Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Chris Wilson authored
intel_flush_status_page() is defunct since commit f8dd2934 ("drm/i915: Remove BXT incoherent seqno write workaround"), time to remove it. Signed-off-by:
-
Chris Wilson authored
Not all of our target platforms have clflush. For those without, just assume the status page is sufficiently coherent that we do not need our paranoia. Reported-by:
-
Chris Wilson authored
Old devices have quite severe restrictions for using fences, and unlike more recent device (anything from Pineview onwards) we need to enforce those restrictions even for unfenced tiled access from the render pipeline. Fixes: 944397f0 ("drm/i915: Store required fence size/alignment for GGTT vma") Reported-by:
-
Chris Wilson authored
We have only 8bits of precise timestamps in which to complete our upper/load reads, along with the switch between precision. This is not always enough time to read the upper counter twice within the same time slice, leading to hard lockups. Limit the number of times to prevent an inifite loop (my fault for assuming we would have no trouble doing the write + reads fast enough). Fixes: 47c21d9a ("drm/i915: Extend vlv/chv residency resolution") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100377Signed-off-by:
-
Chris Wilson authored
We can assume that if the device is asleep then all pending GTT writes will have been posted, and so we can defer the flush from i915_gem_object_flush_gtt_write_domain() [ 1957.462568] WARNING: CPU: 0 PID: 6132 at drivers/gpu/drm/i915/intel_drv.h:1742 fwtable_read32+0x123/0x150 [i915] [ 1957.462582] RPM wakelock ref not held during HW access [ 1957.462583] Modules linked in: i915 intel_gtt drm_kms_helper prime_numbers [ 1957.462607] CPU: 0 PID: 6132 Comm: gem_concurrent_ Tainted: G U 4.11.0-rc1+ #464 [ 1957.462619] Hardware name: / , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015 [ 1957.462630] Call Trace: [ 1957.462646] dump_stack+0x4d/0x6f [ 1957.462657] __warn+0xc1/0xe0 [ 1957.462667] warn_slowpath_fmt+0x4a/0x50 [ 1957.462709] fwtable_read32+0x123/0x150 [i915] [ 1957.462750] i915_gem_object_flush_gtt_write_domain+0x43/0x70 [i915] [ 1957.462791] i915_gem_object_set_to_cpu_domain+0x46/0xa0 [i915] [ 1957.462831] i915_gem_set_domain_ioctl+0x15d/0x220 [i915] [ 1957.462843] drm_ioctl+0x1d7/0x440 [ 1957.462885] ? i915_gem_obj_prepare_shmem_write+0x1d0/0x1d0 [i915] [ 1957.462896] ? pick_next_task_fair+0x436/0x440 [ 1957.462906] ? mntput+0x1f/0x30 [ 1957.462915] do_vfs_ioctl+0x8f/0x5c0 [ 1957.462925] ? __schedule+0x16f/0x5f0 [ 1957.462935] ? ____fput+0x9/0x10 [ 1957.462943] SyS_ioctl+0x3c/0x70 [ 1957.462952] entry_SYSCALL_64_fastpath+0x17/0x98 [ 1957.462961] RIP: 0033:0x7fc542179ca7 [ 1957.462968] RSP: 002b:00007ffeef12ff98 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 1957.462982] RAX: ffffffffffffffda RBX: 00007ffeef1301d0 RCX: 00007fc542179ca7 [ 1957.462990] RDX: 00007ffeef12ffd0 RSI: 00000000400c645f RDI: 0000000000000003 [ 1957.462999] RBP: 0000000000000003 R08: 000055f433bc7c40 R09: 000000000000002c [ 1957.463006] R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000018 [ 1957.463015] R13: 000055f432c89d20 R14: 000055f432c87690 R15: 0000000000000000 Fixes: 3b5724d7 ("drm/i915: Wait for writes through the GTT to land before reading back") Signed-off-by:
-
Chris Wilson authored
I noticed that gcc was spilling the CSB to the stack, so rearrange the code to be more compact. Spilling in this function is slightly more interesting due to the mmio reads acting as memory barriers and so end up flushing the stack spills. Still miniscule to having to do at least the pair of uncached reads :( function old new delta intel_lrc_irq_handler 1039 878 -161 Signed-off-by:
-
Michal Wajdeczko authored
There is no need to expose this function as it is called from one function only. Also move it up to avoid forward declaration. v2: drop intel_ prefix (Oscar) and rename to fetch_uc_fw (Michal) Signed-off-by:
-
- 26 Mar, 2017 5 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-miscLinus Torvalds authored
Pull char/misc driver fixes from Greg KH: "A smattering of different small fixes for some random driver subsystems. Nothing all that major, just resolutions for reported issues and bugs. All have been in linux-next with no reported issues" * tag 'char-misc-4.11-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (21 commits) extcon: int3496: Set the id pin to direction-input if necessary extcon: int3496: Use gpiod_get instead of gpiod_get_index extcon: int3496: Add dependency on X86 as it's Intel specific extcon: int3496: Add GPIO ACPI mapping table extcon: int3496: Rename GPIO pins in accordance with binding vmw_vmci: handle the return value from pci_alloc_irq_vectors correctly ppdev: fix registering same device name parport: fix attempt to write duplicate procfiles auxdisplay: img-ascii-lcd: add missing sentinel entry in img_ascii_lcd_matches Drivers: hv: vmbus: Don't leak memory when a channel is rescinded Drivers: hv: vmbus: Don't leak channel ids Drivers: hv: util: don't forget to init host_ts.lock Drivers: hv: util: move waiting for release to hv_utils_transport itself vmbus: remove hv_event_tasklet_disable/enable vmbus: use rcu for per-cpu channel list mei: don't wait for os version message reply mei: fix deadlock on mei reset intel_th: pci: Add Gemini Lake support intel_th: pci: Add Denverton SOC support intel_th: Don't leak module refcount on failure to activate ...
-
Linus Torvalds authored
Merge tag 'driver-core-4.11-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core fix from Greg KH: "Here is a single kernfs fix for 4.11-rc4 that resolves a reported issue. It has been in linux-next with no reported issues" * tag 'driver-core-4.11-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: kernfs: Check KERNFS_HAS_RELEASE before calling kernfs_release_file()
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/ttyLinus Torvalds authored
Pull tty/serial driver fixes from Greg KH: "Here are some tty and serial driver fixes for 4.11-rc4. One of these fix a long-standing issue in the ldisc code that was found by Dmitry Vyukov with his great fuzzing work. The other fixes resolve other reported issues, and there is one revert of a patch in 4.11-rc1 that wasn't correct. All of these have been in linux-next for a while with no reported issues" * tag 'tty-4.11-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: tty: fix data race in tty_ldisc_ref_wait() tty: don't panic on OOM in tty_set_ldisc() Revert "tty: serial: pl011: add ttyAMA for matching pl011 console" tty: acpi/spcr: QDF2400 E44 checks for wrong OEM revision serial: 8250_dw: Fix breakage when HAVE_CLK=n serial: 8250_dw: Honor clk_round_rate errors in dw8250_set_termios
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/stagingLinus Torvalds authored
Pull IIO driver fixes from Greg KH: "Here are some small IIO driver fixes for 4.11-rc4 that resolve a number of tiny reported issues. All of these have been in linux-next for a while with no reported issues" * tag 'staging-4.11-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: iio: imu: st_lsm6dsx: fix FIFO_CTRL2 overwrite during watermark configuration iio: adc: ti_am335x_adc: fix fifo overrun recovery iio: sw-device: Fix config group initialization iio: magnetometer: ak8974: remove incorrect __exit markups iio: hid-sensor-trigger: Change get poll value function order to avoid sensor properties losing after resume from S3
-
