- 13 Dec, 2017 4 commits
-
-
Chris Wilson authored
If a fence allocation fails in a blocking context, we will sleep on the fence as a last resort. We can therefore allow ourselves to fail and sleep on the fence instead of triggering a system-wide oom. This allows us to throttle malicious clients that are consuming lots of system resources by capping the amount of memory used by fences. Testcase: igt/gem_shrink/execbufX Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171212180652.22061-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
As kmalloc is allowed to block (if given the right flags), mark up the two i915_sw_fence routines that may call kmalloc as potential sleeping routines. Signed-off-by:
-
Chris Wilson authored
i915_gem_wait_for_idle() is called from inside the shrinker, to ensure that we drain the last resources from the GPU in dire circumstances (OOM). As we may allocate whilst building a request, it is then possible to hit the shrinker with a request under construction, and so we must account for the incomplete request whilst waiting. In particular, we preincrement (in reserve_engine) the i915->gt.active_requests counter and mark the GPU as busy, therefore we can not use that counter for shortcircuiting the wait-for-idle. [ 950.859024] GEM_BUG_ON(i915->gt.active_requests) [ 950.859041] WARNING: CPU: 2 PID: 2178 at drivers/gpu/drm/i915/i915_gem.c:3615 i915_gem_wait_for_idle.part.56+0x166/0x4e0 [ 950.859041] Modules linked in: ccm tun fuse nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack libcrc32c ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_mangle iptable_security iptable_raw arc4 iwldvm mac80211 snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_codec_generic snd_hda_intel snd_hda_codec btusb snd_hda_core btrtl btbcm iwlwifi snd_hwdep btintel bluetooth snd_seq snd_seq_device snd_pcm ecdh_generic x86_pkg_temp_thermal tpm_infineon coretemp tpm_tis crc32_pclmul wmi_bmof crc32c_intel iTCO_wdt hp_wmi snd_timer iTCO_vendor_support sparse_keymap tpm_tis_core mei_me cfg80211 [ 950.859082] snd joydev tpm mei rfkill pcspkr wmi soundcore lpc_ich hp_accel lis3lv02d input_polldev binfmt_misc e1000e ptp serio_raw pps_core [ 950.859094] CPU: 2 PID: 2178 Comm: gem_exec_nop Tainted: G U 4.15.0-rc2+ #900 [ 950.859102] Hardware name: Hewlett-Packard HP ProBook 6360b/1620, BIOS 68SCF Ver. B.42 12/29/2010 [ 950.859107] task: c5119cb4 task.stack: f3ccb8d8 [ 950.859112] EIP: i915_gem_wait_for_idle.part.56+0x166/0x4e0 [ 950.859113] EFLAGS: 00010296 CPU: 2 [ 950.859114] EAX: 00000024 EBX: f36c1888 ECX: f777a044 EDX: 00000007 [ 950.859115] ESI: f36c1888 EDI: edd53958 EBP: edd53970 ESP: edd53938 [ 950.859116] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 950.859117] CR0: 80050033 CR2: b7f39000 CR3: 2f2b3000 CR4: 000406d0 [ 950.859118] Call Trace: [ 950.859125] ? drm_printk+0x70/0x70 [ 950.859129] i915_gem_wait_for_idle+0x18/0x30 [ 950.859133] i915_gem_shrink+0x360/0x410 [ 950.859138] ? vmpressure+0xa8/0xf0 [ 950.859142] ? ktime_get+0x4a/0x100 [ 950.859147] i915_gem_shrink_all+0x21/0x40 [ 950.859151] i915_gem_shrinker_oom+0x23/0x130 [ 950.859156] notifier_call_chain+0x4e/0x70 [ 950.859160] __blocking_notifier_call_chain+0x2f/0x60 [ 950.859164] blocking_notifier_call_chain+0x11/0x20 [ 950.859169] out_of_memory+0x207/0x280 [ 950.859174] __alloc_pages_nodemask+0xd47/0xe60 [ 950.859179] new_slab+0x32d/0x450 [ 950.859183] ___slab_alloc.constprop.81+0x358/0x4e0 [ 950.859189] ? i915_sw_fence_await_dma_fence+0x53/0x160 [ 950.859193] ? __slab_free+0x1fe/0x310 [ 950.859197] ? native_sched_clock+0x1e/0xc0 [ 950.859201] ? i915_gem_request_alloc+0xcf/0x510 [ 950.859205] ? sched_clock+0x9/0x10 [ 950.859209] __slab_alloc.constprop.80+0x29/0x40 [ 950.859212] ? __slab_alloc.constprop.80+0x29/0x40 [ 950.859216] kmem_cache_alloc_trace+0x160/0x1a0 [ 950.859220] ? i915_sw_fence_await_dma_fence+0x53/0x160 [ 950.859224] i915_sw_fence_await_dma_fence+0x53/0x160 [ 950.859229] i915_gem_request_await_dma_fence+0x1eb/0x390 [ 950.859233] i915_gem_request_await_object+0xee/0x230 [ 950.859239] i915_gem_do_execbuffer+0xc16/0x1200 [ 950.859246] ? irqtime_account_irq+0x3e/0xc0 [ 950.859251] ? irq_exit+0x4f/0xb0 [ 950.859257] ? smp_apic_timer_interrupt+0x5f/0x110 [ 950.859261] ? apic_timer_interrupt+0x35/0x3c [ 950.859266] i915_gem_execbuffer2_ioctl+0x212/0x440 [ 950.859270] ? apic_timer_interrupt+0x35/0x3c [ 950.859274] ? i915_gem_do_execbuffer+0x1200/0x1200 [ 950.859279] ? insn_get_seg_base+0x1b/0x50 [ 950.859283] ? i915_gem_do_execbuffer+0x1200/0x1200 [ 950.859287] drm_ioctl_kernel+0x51/0xa0 [ 950.859291] drm_ioctl+0x2a3/0x350 [ 950.859294] ? i915_gem_do_execbuffer+0x1200/0x1200 [ 950.859300] ? sched_clock+0x9/0x10 [ 950.859303] ? drm_getunique+0x70/0x70 [ 950.859308] do_vfs_ioctl+0x7d/0x640 [ 950.859311] ? native_sched_clock+0x1e/0xc0 [ 950.859315] ? sched_clock+0x9/0x10 [ 950.859319] ? sched_clock_cpu+0x13/0x120 [ 950.859323] SyS_ioctl+0x4e/0x80 [ 950.859326] do_fast_syscall_32+0x75/0x250 [ 950.859331] ? irq_exit+0x4f/0xb0 [ 950.859334] entry_SYSENTER_32+0x47/0x71 [ 950.859338] EIP: 0xb7f81d11 [ 950.859339] EFLAGS: 00000296 CPU: 2 [ 950.859340] EAX: ffffffda EBX: 00000003 ECX: 40406469 EDX: bfde4c20 [ 950.859340] ESI: 00000003 EDI: 40406469 EBP: 00000003 ESP: bfde4b38 [ 950.859341] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b [ 950.859343] Code: e8 30 60 01 00 83 c4 10 83 c3 04 39 f3 75 e0 8b 45 d8 8b 80 14 37 00 00 85 c0 74 13 68 dd 33 e4 c0 68 49 6f e3 c0 e8 4a 55 be ff <0f> ff 5e 5f b8 fe ff ff 3f bb 0a 00 00 00 e8 b7 14 c4 ff 8b 15 Signed-off-by:
-
Chris Wilson authored
It is illegal to perform an immediate free of the struct irq_work from inside the irq_work callback (as irq_work_run_list modifies work->flags after execution of the work->func()). As we use the irq_work to coordinate the freeing of the callback from two different softirq paths, we need to defer the kfree from inside our irq_work callback, for which we can use kfree_rcu. Fixes: 81c0ed21 ("drm/i915/fence: Avoid del_timer_sync() from inside a timer") Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171213094802.28243-1-chris@chris-wilson.co.uk
-
- 12 Dec, 2017 14 commits
-
-
Chris Wilson authored
If wait_for_engines() fails and we resort to declaring the HW wedged, dump the engine state for debugging. Signed-off-by:
-
Chris Wilson authored
Extract the timeout we use in i915_gem_idle_work_handler() and reuse it for wait_for_engines() in i915_gem_wait_for_idle(). It too has the same problem in sometimes having to wait for an extended period before the HW settles, so make use of the same timeout. References: 5427f207 ("drm/i915: Bump wait-times for the final CS interrupt before parking") Signed-off-by:
-
Chris Wilson authored
It never meant what it said, as it was always the total size of the Global GTT and not a limit upon memory usage. Originally it served as a quick guide to the largest batch that could be submitted by userspace, an approximation to its maximum RSS, but was phrased badly. Today with the 48b ppgtt, it is even more meaningless. Replace with a more specific debug message; those wanting to know how much "video ram" they have should consult the userspace libraries for the relevant approximation. v2: Rebase Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Reviewed-by:
-
Chris Wilson authored
Since on gen2, we do not universally have a GPU reset implementation, we fail i915_reset() at intel_has_gpu_reset(). However, this is also intentionally disabled for CI testing and so it only has a debug message. Promote that debug message to a user-facing error message that should explain why their machine became unusable following the GPU hang. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171211204040.22858-1-chris@chris-wilson.co.uk
-
Markus Heiser authored
With commit d9e2e014 the 'GuC-specific firmware loader' doc section was removed from intel_guc_loader.c without a replacement. So lets remove it from the Kernel-doc:: .. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c :doc: GuC-specific firmware loader With commit e8668bbc intel_guc_loader.c was renamed to to intel_guc_fw.c and to name just one, intel_guc_init_hw() was renamed to intel_guc_fw_upload(). Since we get errors in the Sphinx build like: - Error: Cannot open file ./drivers/gpu/drm/i915/intel_guc_loader.c Change the kernel-doc directive from intel_guc_loader.c to intel_guc_fw.c Signed-off-by:
Markus Heiser <markus.heiser@darmarit.de> [danvet: Rebase onto the partial fix 006c2332 ("documentation/gpu/i915: fix docs build error after file rename")] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1513078717-12373-1-git-send-email-markus.heiser@darmarit.de
-
Matthew Auld authored
Keeps things consistent now that we make use of struct resource. This should keep us covered in case we ever get huge amounts of stolen memory. v2: bunch of missing conversions (Chris) Signed-off-by:
-
Matthew Auld authored
Kick it out of i915_ggtt and keep it grouped with dsm and dsm_reserved, where it makes the most sense. Signed-off-by:
-
Matthew Auld authored
Now that we are using struct resource to track the stolen region, it is more convenient if we track the mappable region in a resource as well. v2: prefer iomap and gmadr naming scheme prefer DEFINE_RES_MEM Signed-off-by: -
Matthew Auld authored
Now that we are using struct resource to track the stolen region, it is more convenient if we track the reserved portion of that region in a resource as well. v2: s/<= end + 1/< end/ (Chris) v3: prefer DEFINE_RES_MEM Signed-off-by:
-
Matthew Auld authored
Now that we are using struct resource to track the stolen region, it is more convenient if we track dsm in a resource as well. v2: check range_overflow when writing to 32b registers (Chris) pepper in some comments (Chris) v3: refit i915_stolen_to_dma() v4: kill ggtt->stolen_size v5: some more polish Signed-off-by: -
Matthew Auld authored
We duplicate the stolen discovery code in early-quirks and in i915, however now that the stolen region is exported as a resource from early-quirks we can nuke the duplication. v2: check overflows_type Signed-off-by:
-
Matthew Auld authored
Replace the magical +2, +9 etc. with +MB, which is far easier to read. Suggested-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Matthew Auld authored
We duplicate the stolen discovery code in early-quirks and in i915, however if we just export the region as a resource from early-quirks we can nuke the duplication. Signed-off-by:
-
Joonas Lahtinen authored
To give upcoming SKU BIOSes more flexibility in placing the Intel graphics stolen memory, make all variables storing the placement or size compatible with full 64 bit range. Signed-off-by:
-
- 11 Dec, 2017 6 commits
-
-
Chris Wilson authored
If we attempt to wake up a waiter, who is currently checking the seqno it will be in the TASK_INTERRUPTIBLE state and ttwu will report success. However, it is actually awake and functioning -- so delay reporting the actual wake up until it sleeps. This fixes some spurious claims of missed_breadcrumbs when running under heavy load; i.e. sufficient load to preempt away the newly woken waiter before they complete their checks. However, it does so at the cost of a rare false negative; where the waiter changes between the check and ttwu -- the only way to fix that would be to extend the reporting from ttwu where the check could be done atomically. v2: Defend against !CONFIG_SMP v3: Don't filter out calls to wake_up_process v4: Drop risky microoptimisation to skip wakeups Testcase: igt/drv_missed_irq # sanity check we do detect missed_breadcrumb() Testcase: igt/gem_concurrent_blit # for generating false positives References: https://bugs.freedesktop.org/show_bug.cgi?id=100007Signed-off-by:
-
Chris Wilson authored
The intent here was that we would be listening to i915_gem_request_unsubmit in order to cancel the signaler quickly and release the reference on the request. Cancelling the signaler is done directly via intel_engine_cancel_signaling (called from unsubmit), but that does not directly wake up the signaling thread, and neither does setting the request->global_seqno back to zero wake up listeners to the request->execute waitqueue. So the only time that listening to the request->execute waitqueue would wake up the signaling kthread would be on the request resubmission, during which time we would already receive wake ups from rejoining the global breadcrumbs wait rbtree. Trying to wake up to release the request remains an issue. If the signaling was cancelled and no other request required signaling, then it is possible for us to shutdown with the reference on the request still held. To ensure that we do not try to shutdown, leaking that request, we kick the signaling threads whenever we disarm the breadcrumbs, i.e. on parking the engine when idle. v2: We do need to be sure to release the last reference on stopping the kthread; asserting that it has been dropped already is insufficient. Fixes: d6a2289d ("drm/i915: Remove the preempted request from the execution queue") Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
-
Chris Wilson authored
Even for the mock i915 device, we need to initialise the drm.mode_config, as we may ultimately query whether there are any KMS users deep in the bowels of some paths (e.g. eviction). As we initialise drm.mode_config we must cleanup after ourselves! Signed-off-by:
-
Chris Wilson authored
Before accessing the GGTT we must flush the PTE writes and make them visible to the chipset, or else the indirect access may end up in the wrong page. In commit 3497971a ("agp/intel: Flush chipset writes after updating a single PTE"), we noticed corruption of the uploads for pwrite and for capturing GPU error states, but it was presumed that the explicit calls to intel_gtt_chipset_flush() were sufficient for the execbuffer path. However, we have not been flushing the chipset between the PTE writes and access via the GTT itself. For simplicity, do the flush after any PTE update rather than try and batch the flushes on a just-in-time basis. References: 3497971a ("agp/intel: Flush chipset writes after updating a single PTE") Signed-off-by:
-
Chris Wilson authored
Since the seqno information shown from i915_interrupt_info is just a small subset of i915_engine_info, remove it. Signed-off-by:
-
Chris Wilson authored
The per-engine seqno info is now available from debugfs/i915_engine_info obsoleting debugfs/i915_seqno_info, so remove it. Signed-off-by:
-
- 08 Dec, 2017 10 commits
-
-
Chris Wilson authored
Comparing the state tested by intel_engine_is_idle() and printed by intel_engine_dump(), the only bit not shown is whether or not the device is wedged. Add that little bit of information to the pretty printer so that if the engine fails to idle we can see why. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171208012303.25504-5-chris@chris-wilson.co.uk
-
Chris Wilson authored
Since a global reset affects the engine, include that along side the per-engine reset counter when pretty printing the engine state in intel_engine_dump(). Signed-off-by:
-
Chris Wilson authored
Now that we have a common engine state pretty printer, we can use that instead of the adhoc information printed when we miss a breadcrumb. v2: Rearrange intel_engine_disarm_breadcrumbs() to avoid calling intel_engine_dump() under the rb spinlock (Mika) and to pretty-print the error state early so that we include the full list of waiters. v3: Pass missed breadcrumb msg to pretty-printer as the header v4: Preserve DRM_DEBUG_DRIVER filtering. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171208012303.25504-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
Pass in a format string (and args) to specify the header to be emitted along with the engine state when pretty-printing. This allows the header to be emitted inside the drm_printer stream, so sharing the same prefix and output characteristics (e.g. debug level and filtering). Signed-off-by:
-
Chris Wilson authored
When printing the execlist ports, we first print the ELSP header then follow it with the pretty-printed request. Since switching to drm_printer and show the output via printk, it automatically appends a newline to each call (unlike the old seq_printf output). To avoid the unwanted line break, construct the ELSP request header in a temporary buffer. Signed-off-by:
-
Rodrigo Vivi authored
Chris requested this backmerge for a reconciliation on drm_print.h between drm-misc-next and drm-intel-next-queued Signed-off-by:Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Chris Wilson authored
When intel_modeset_setup_plane_state() fails drop the local framebuffer reference before jumping to the error, otherwise we leak the framebuffer. Signed-off-by:
-
Daniel Vetter authored
Even fbc isn't using this stuff anymore, so time to remove it. Cleaning up one small piece of the atomic conversion cruft at the time ... Quick explanation on why the plane->fb assignment is ok to delete: The core code takes care of the refcounting and legacy ->fb pointer updating, but drivers are allowed to update it ahead of time. Most legacy modeset drivers did that as part of their set_config callback (since that's how the legacy/crtc helpers worked). In i915 we only need that to make the fbc code happy. v2: don't nuke the assignement of intel_crtc->config, I accidentally set CI ablaze :-) Spotted by Maarten. And better explain why nuking the ->fb assignement shouldn't set off alarm bells. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171207143202.6021-1-daniel.vetter@ffwll.ch
-
Tvrtko Ursulin authored
It seems that the DMC likes to transition between the DC states a lot when there are no connected displays (no active power domains) during command submission. This activity on DC states has a negative impact on the performance of the chip with huge latencies observed in the interrupt handlers and elsewhere. Simple tests like igt/gem_latency -n 0 are slowed down by a factor of eight. Work around it by introducing a new power domain named, POWER_DOMAIN_GT_IRQ, associtated with the "DC off" power well, which is held for the duration of command submission activity. CNL has the same problem which will be addressed as a follow-up. Doing that requires a fix for a DC6 context corruption problem in the CNL DMC firmware which is yet to be released. v2: * Add commit text as comment in i915_gem_mark_busy. (Chris Wilson) * Protect macro body with braces. (Jani Nikula) v3: * Add dedicated power domain for clarity. (Chris, Imre) * Commit message and comment text updates. * Apply to all big-core GEN9 parts apart for Skylake which is pending DMC firmware release. v4: * Power domain should be inner to device runtime pm. (Chris) * Simplify NEEDS_CSR_GT_PERF_WA macro. (Chris) * Handle async DMC loading by moving the GT_IRQ power domain logic into intel_runtime_pm. (Daniel, Chris) * Include small core GEN9 as well. (Imre) v5 * Special handling for async DMC load is not needed since on failure the power domain reference is kept permanently taken. (Imre) v6: * Drop the NEEDS_CSR_GT_PERF_WA macro since all firmwares have now been deployed. (Imre, Chris) Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171205132854.26380-1-tvrtko.ursulin@linux.intel.com
-
Chris Wilson authored
Currently on every submission, we recalculate the ELSP register offset for the engine, after chasing the pointers to find the iomem base. Since this is fixed for the lifetime of the driver, record the offset in the execlists struct. In practice the difference is negligible, it just happens to remove 27 bytes of eyesore pointer dancing from next to the hottest instruction (which is itself due to stalling for a cache miss) in perf profiles of the execlists_submission_tasklet(). v2: Trim off one more elsp local. Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Reviewed-by:
-
- 07 Dec, 2017 6 commits
-
-
Chris Wilson authored
In quite a few places, we have a list iteration over the vma on an object that only want to inspect GGTT vma. By construction, these are placed at the start of the list, so we have copied that knowledge into many callsites. Pull that knowledge back to i915_vma.h and provide a for_each_ggtt_vma() to tidy up the code. v2: Add a backreference from vma_create() to remind ourselves why we put ggtt vma at the head of the obj->vma_list (and ppgtt vma at the tail). v3: Fixup s/vma/V/ Suggested-by:
-
git://anongit.freedesktop.org/drm/drm-intelDave Airlie authored
[airlied: fix conflict in intel_dsi.c] drm-intel-next-2017-12-01: - Init clock gate fix (Ville) - Execlists event handling corrections (Chris, Michel) - Improvements on GPU Cache invalidation and context switch (Chris) - More perf OA changes (Lionel) - More selftests improvements and fixes (Chris, Matthew) - Clean-up on modules parameters (Chris) - Clean-up around old ringbuffer submission and hw semaphore on old platforms (Chris) - More Cannonlake stabilization effort (David, James) - Display planes clean-up and improvements (Ville) - New PMU interface for perf queries... (Tvrtko) - ... and other subsequent PMU changes and fixes (Tvrtko, Chris) - Remove success dmesg noise from rotation (Chris) - New DMC for Kabylake (Anusha) - Fixes around atomic commits (Daniel) - GuC updates and fixes (Sagar, Michal, Chris) - Couple gmbus/i2c fixes (Ville) - Use exponential backoff for all our wait_for() (Chris) - Fixes for i915/fbdev (Chris) - Backlight fixes (Arnd) - Updates on shrinker (Chris) - Make Hotplug enable more robuts (Chris) - Disable huge pages (TPH) on lack of a needed workaround (Joonas) - New GuC images for SKL, KBL, BXT (Sagar) - Add HW Workaround for Geminilake performance (Valtteri) - Fixes for PPS timings (Imre) - More IPS fixes (Maarten) - Many fixes for Display Port on gen2-gen4 (Ville) - Retry GPU reset making the recover from hang more robust (Chris) * tag 'drm-intel-next-2017-12-01' of git://anongit.freedesktop.org/drm/drm-intel: (101 commits) drm/i915: Update DRIVER_DATE to 20171201 drm/i915/cnl: Mask previous DDI - PLL mapping drm/i915: Remove unsafe i915.enable_rc6 drm/i915: Sleep and retry a GPU reset if at first we don't succeed drm/i915: Interlaced DP output doesn't work on VLV/CHV drm/i915: Pass crtc state to intel_pipe_{enable,disable}() drm/i915: Wait for pipe to start on i830 as well drm/i915: Fix vblank timestamp/frame counter jumps on gen2 drm/i915: Fix deadlock in i830_disable_pipe() drm/i915: Fix has_audio readout for DDI A drm/i915: Don't add the "force audio" property to DP connectors that don't support audio drm/i915: Disable DP audio for g4x drm/i915/selftests: Wake the device before executing requests on the GPU drm/i915: Set fake_vma.size as well as fake_vma.node.size for capture drm/i915: Tidy up signed/unsigned comparison drm/i915: Enable IPS with only sprite plane visible too, v4. drm/i915: Make ips_enabled a property depending on whether IPS is enabled, v3. drm/i915: Avoid PPS HW/SW state mismatch due to rounding drm/i915: Skip switch-to-kernel-context on suspend when wedged drm/i915/glk: Apply WaProgramL3SqcReg1DefaultForPerf for GLK too ...
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
UAPI Changes: - Add "panel orientation" property to DRM to indicate orientation of the panel vs the device's casing (Hans de Goede) Core Changes: - misc doc and bug fixes Driver Changes: - sun4i: Many improvements to the DE driver like multi-plane support and YUV formats (Jernej Skrabec) * tag 'drm-misc-next-2017-12-07' of git://anongit.freedesktop.org/drm/drm-misc: (50 commits) drm/sun4i: Fix uninitialized variables in vi layer drm/fb-helper: Fix potential NULL pointer dereference gpu: drm: stm: Adopt SPDX identifiers gpu: drm: sti: Adopt SPDX identifiers drm/fsl-dcu: Use drm_mode_config_helper_suspend/resume() drm/sun4i: Wire in DE2 YUV support drm/sun4i: Expand DE2 scaler lib with YUV support drm/sun4i: Add DE2 definitions for YUV formats drm/sun4i: Add DE2 CSC library drm/sun4i: Add CCSC property to DE2 configuration drm/sun4i: Add support for HW scaling to DE2 drm/sun4i: Add scaler configuration to DE2 mixers drm/sun4i: Add support for DE2 VI planes drm/sun4i: Reorganize UI layer code in DE2 drm/sun4i: Add support for all HW supported DE2 RGB formats drm/sun4i: Add multi plane support to DE2 driver drm/sun4i: Move interlace related code in DE2 drm/sun4i: Move channel size related code in DE2 drm/sun4i: Move line width setting in DE2 drm/sun4i: Use values calculated by atomic check ...
-
Chris Wilson authored
As writes through the GTT and GGTT PTE updates do not share the same path, they are not strictly ordered and so we must explicitly flush the indirect writes prior to modifying the PTE. We do track outstanding GGTT writes on the object itself, but since the object may have multiple GGTT vma, that is overly coarse as we can track and flush individual vma as required. Whilst here, update the GGTT flushing behaviour for Cannonlake. v2: Hard-code ring offset to allow use during unload (after RCS may have been freed, or never existed!) References: https://bugs.freedesktop.org/show_bug.cgi?id=104002Signed-off-by:
-
Chris Wilson authored
Originally we translated from the object to the vma by walking obj->vma_list to find the matching vm (for user lookups). Now we process user lookups using the rbtree, and we only use obj->vma_list itself for maintaining state (e.g. ensuring that all vma are flushed or rebound). As such maintenance needs to go on beyond the user's awareness of the vma, defer removal of the vma from the obj->vma_list from i915_vma_close() to i915_vma_destroy() Fixes: 5888fc9e ("drm/i915: Flush pending GTT writes before unbinding") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104155Signed-off-by:
-
Jernej Skrabec authored
min_scale and max_scale in sun8i_vi_layer_atomic_check() can be used without initialization. Fix that. Fixes: b862a648 ("drm/sun4i: Add support for HW scaling to DE2") Signed-off-by:
Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171206152603.25937-1-jernej.skrabec@siol.net
-
