- 07 Sep, 2017 22 commits
-
-
Oscar Mateo authored
GEN7_UCGCTL4 does not live in the context. v2: Missing parenthesis Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Oscar Mateo <oscar.mateo@intel.com> Reviewed-by:
Michał Winiarski <michal.winiarski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1504798809-5653-4-git-send-email-oscar.mateo@intel.comSigned-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Oscar Mateo authored
So do it correctly. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Oscar Mateo authored
GAMT_CHKN_BIT_REG does not live in the context. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Oscar Mateo authored
Afaict, GEN9_GAMT_ECO_REG_RW_IA does not live in the context, so writing it on every context creation is overkill (and wrong). v2: Missing end parenthesis Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Chris Wilson authored
We also see the delayed GTT write issue on i915g/i915gm, so let's presume that it is a universal problem for all !llc machines, and that we just haven't yet noticed on g33, gen4 and gen5 machines. v2: Use a register that exists on all platforms Testcase: igt/gem_mmap_gtt/coherency # i915gm References: https://bugs.freedesktop.org/show_bug.cgi?id=102577Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com>
-
Ville Syrjälä authored
drm_pci_alloc() refuses to cooperate if the passed alignment exceeds the object size. So round up the obj size to the next power of two as well to make this actually work. Obviously things work just fine as long as the size was a power of two to begin with. However kms_cursor_crc doesn't always use power of two sizes so we hit a failure when we try to allocate the phys memory. Testcase: igt/kms_cursor_crc Signed-off-by:
-
Chris Wilson authored
If the user bypasses i915 and accesses mmio directly, that easily confuses our automatic mmio debugging (any error we then detect is likely to be as a result of the user). Since we expect userspace to open debugfs/i915_forcewake_user if i915.ko is loaded and they want mmio access, that makes the opportune time to disable our debugging for duration of the bypass. v2: Move the fiddling of uncore internals to uncore.c References: https://bugs.freedesktop.org/show_bug.cgi?id=102543Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170907134441.12881-1-chris@chris-wilson.co.uk
-
Kumar, Mahesh authored
This patch creates an entry in debugfs to check the status of IPC. This can also be used to enable/disable IPC in supported platforms. Changes since V1: - fix use of HAS_IPC - use kstrtobool_from_user (Maarten) - drm_info log, while enabling IPC (Maarten) Signed-off-by:
Mahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Kumar, Mahesh authored
This patch adds IPC support. This patch also enables IPC in all supported platforms based on has_ipc flag. IPC (Isochronous Priority Control) is the hardware feature, which dynamically controls the memory read priority of Display. When IPC is enabled, plane read requests are sent at high priority until filling above the transition watermark, then the requests are sent at lower priority until dropping below the level 0 watermark. The lower priority requests allow other memory clients to have better memory access. When IPC is disabled, all plane read requests are sent at high priority. Changes since V1: - Remove commandline parameter to disable ipc - Address Paulo's comments Changes since V2: - Address review comments - Set ipc_enabled flag Changes since V3: - move ipc_enabled flag assignment inside intel_ipc_enable function Changes since V4: - Re-enable IPC after suspend/resume Changes since V5: - Enable IPC for all gen >=9 except SKL Changes since V6: - fix commit msg - after resume program IPC based on SW state. Changes since V7: - Modify IPC support check based on HAS_IPC macro (suggested by Chris) Signed-off-by:
-
Mahesh Kumar authored
New Isochronous Priority Control (IPC) capability is introduced in newer GEN platforms. This patch adds a device info flag to indicate if platform supports IPC. Patch also sets this flag in supported platforms. Signed-off-by:
-
Kumar, Mahesh authored
CNL:A & CNL:B have same workaround as KBL to increase wm level latency by 4us if IPC is enabled. Signed-off-by:
-
Kumar, Mahesh authored
IF IPC is enabled LINETIME_WM value should be half of calculated value line time = ROUNDDOWN(1/2 * Calculated Line Time) Earlier code was rounding-up the value, But updated Bspec says we should take the ROUNDDOWN. This patch corrects that as well. Signed-off-by:
-
Kumar, Mahesh authored
GEN > 9 require transition WM to be programmed if IPC is enabled. This patch calculates & enable transition WM for supported platforms. If transition WM is enabled, Plane read requests are sent at high priority until filling above the transition watermark, then the requests are sent at lower priority until dropping below the level-0 WM. The lower priority requests allow other memory clients to have better memory access. transition minimum is the minimum amount needed for trans_wm to work to ensure the demote does not happen before enough data has been read to meet the level 0 watermark requirements. transition amount is configurable value. Higher values will tend to cause longer periods of high priority reads followed by longer periods of lower priority reads. Tuning to lower values will tend to cause shorter periods of high and lower priority reads. Keeping transition amount to 10 in this patch, as suggested by HW team. Changes since V1: - Address review comments from Maarten Signed-off-by:
-
Kumar, Mahesh authored
Plane configuration parameters doesn't change for each WM-level calculation. Currently we compute same parameters 8 times for each wm-level. This patch optimizes it by calculating these parameters in beginning & reuse during each level-wm calculation. Changes since V1: - rebase on top of Rodrigo's series for CNL Signed-off-by:
-
Kumar, Mahesh authored
As per suggestion from Jani, cleanup the code. Cleanup includes - Instead of left shifting & check, compare with U32/16_MAX - Use typecast instead of clamp_t Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Tvrtko Ursulin authored
Exercise the new __sg_alloc_table_from_pages API (and through it also the old sg_alloc_table_from_pages), checking that the created table has the expected number of segments depending on the sequence of input pages and other conditions. v2: Move to data driven for readability. v3: Add some more testcases and -fsanitize=undefined. (Chris Wilson) Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: linux-kernel@vger.kernel.org Reviewed-by:
-
Tvrtko Ursulin authored
With the addition of __sg_alloc_table_from_pages we can control the maximum coalescing size and eliminate a separate path for allocating backing store here. Similar to 871dfbd6 ("drm/i915: Allow compaction upto SWIOTLB max segment size") this enables more compact sg lists to be created and so has a beneficial effect on workloads with many and/or large objects of this class. v2: * Rename helper to i915_sg_segment_size and fix swiotlb override. * Commit message update. v3: * Actually include the swiotlb override fix. v4: * Regroup parameters a bit. (Chris Wilson) v5: * Rebase for swiotlb_max_segment. * Add DMA map failure handling as in abb0deac ("drm/i915: Fallback to single PAGE_SIZE segments for DMA remapping"). v6: Handle swiotlb_max_segment() returning 1. (Joonas Lahtinen) v7: Rebase. v8: Commit spelling fix. Signed-off-by:
-
Tvrtko Ursulin authored
Drivers like i915 benefit from being able to control the maxium size of the sg coalesced segment while building the scatter- gather list. Introduce and export the __sg_alloc_table_from_pages function which will allow it that control. v2: Reorder parameters. (Chris Wilson) v3: Fix incomplete reordering in v2. v4: max_segment needs to be page aligned. v5: Rebase. v6: Rebase. v7: Fix spelling in commit and mention max segment size in __sg_alloc_table_from_pages kerneldoc. (Andrew Morton) Signed-off-by: -
Tvrtko Ursulin authored
Since the scatterlist length field is an unsigned int, make sure that sg_alloc_table_from_pages does not overflow it while coalescing pages to a single entry. v2: Drop reference to future use. Use UINT_MAX. v3: max_segment must be page aligned. v4: Do not rely on compiler to optimise out the rounddown. (Joonas Lahtinen) v5: Simplified loops and use post-increments rather than pre-increments. Use PAGE_MASK and fix comment typo. (Andy Shevchenko) v6: Commit spelling fix. Signed-off-by: -
Tvrtko Ursulin authored
Scatterlist entries have an unsigned int for the offset so correct the sg_alloc_table_from_pages function accordingly. Since these are offsets withing a page, unsigned int is wide enough. Also converts callers which were using unsigned long locally with the lower_32_bits annotation to make it explicitly clear what is happening. v2: Use offset_in_page. (Chris Wilson) Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170731185512.20010-1-tvrtko.ursulin@linux.intel.com
-
Chris Wilson authored
The original gen4 has an issue where writes (both render and blt) into snoopable pages are lost. We've previously worked around this in userspace (ddx, igt) by simply not requesting snoopable buffers, but upon rediscovering this problem for a third time, make the kernel reject such requests with -ENODEV. This disables snooping on userspace buffers for i965g and i965gm (original gen4) machines. Signed-off-by:
-
Jani Nikula authored
Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
- 06 Sep, 2017 7 commits
-
-
Rodrigo Vivi authored
Wa for B-stepping only. A for a hang issue that requires throttling EU performace to 12.5% to avoid back pressure to thread dispatch v2: Rebased. No change from v1. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Chris Wilson authored
i915_gem_object_attach_phys() is trying to swap out its shmemfs pages for a new set of physically contiguous pages, but unfortunately triggers an assert inside get-pages. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102561Signed-off-by:
Matthew Auld <matthew.auld@intel.com>
-
Rodrigo Vivi authored
Skip compressing 1 segment at the end of the frame, avoid a pixel count mismatch nuke event when last active pixel and dummy pixel has same color for Odd Plane Width / Height. For both platforms Gemini Lake and Cannon Lake. v2: Use function-like macro and also use mask to clean to make sure bit 11 is 0. (Suggested by Paulo). v3: Add Display WA notation and also apply for GLK. Both Forgotten on v2. Using "GLK_" prefix since GLK came before CNL. v4: Forgot to "|=" when moving directly macro to masked val. (Noticed by Paulo.) v5: Rebased on top of 0a46ddd5 ("drm/i915/cnp: Wa 1181: Fix Backlight issue") Cc: Imre Deak <imre.deak@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170905193013.31710-1-rodrigo.vivi@intel.com
-
Nanley Chery authored
This enables the Mesa driver to advertise support for ARB_timer_query, and thus an OpenGL version higher than 3.2. Suggested-by:
Ben Widawsky <ben@bwidawsk.net> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Nanley Chery <nanley.g.chery@intel.com> Reviewed-by:
-
Chris Wilson authored
Currently we define any !llc machine as using snoop instead. However, some platforms run into trouble using snoop that we would like to disable, and to do so easily we want to be able to use the static device_info tables. v2: Leave the old snoop = !llc as a warning for the time being to check that all stanzas are filled as either llc or snoop. Signed-off-by:
-
Chris Wilson authored
The early gen3 machines (i915g/Grantsdale and i915gm/Alviso) share a lot of characteristics in their MI/GTT blocks with gen2, and in particular can only use physical addresses in MI_STORE_DATA_IMM. This makes it incompatible with our usage, so include those two machines in the blacklist to prevent usage. v2: Make it easy for gcc and rewrite it as a switch to save some space. Signed-off-by:
-
Chris Wilson authored
Ville Syrjälä spotted that PGETBL_CTL was losing its enable bit upon a reset. That was causing the display to show garbage on his 945gm. On my i915gm the effect was far more severe; re-enabling the display following the reset without PGETBL_CTL being enabled lead to an immediate hard hang. We do have a routine to re-enable PGETBL_CTL which is applicable to gen2-4, although on gen4 it is documented that a graphics reset doesn't alter the register (no such wording is given for gen3) and should be safe to call to punch back in the enable bit. However, that leaves the question of whether we need to completely re-initialise the register and the rest of the GSM. For g33/pnv/gen4+, where we do have a configurable page table, its contents do seem to be kept, and so we should be able to recover without having to reinitialise the GTT from scratch (as prior to g33, that register is configured by the BIOS and we leave alone except for the enable bit). This appears to have been broken by commit 5fbd0418 ("drm/i915: Re-enable GGTT earlier during resume on pre-gen6 platforms"), which moved the intel_enable_gtt() from i915_gem_init_hw() (also used by reset) to add it earlier during hw init and resume, missing the reset path. v2: Find the culprit, rearrange ggtt_enable to be before gem_init_hw to match init/resume Reported-by:
Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170906111405.27110-1-chris@chris-wilson.co.ukTested-by:
-
- 05 Sep, 2017 5 commits
-
-
Rodrigo Vivi authored
This workaround fixes a CNL PCH bug when changing backlight from a lower frequency to a higher frequency. During random reboot cycles, display backlight seems to be off/ dim for 2-3 mins. The only functional change on this patch is to set bit 13 of 0xC2020 for CNL PCH. The rest of patch is organizing identation around those bits definitions and re-organizing CFL workarounds. v2: Only add the bit that matters without touching others around (Jani). Rebase on top of clock gating functions rename. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Arthur J Runyan <arthur.j.runyan@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170831045223.3960-1-rodrigo.vivi@intel.com
-
Ville Syrjälä authored
Add the missing __user to the urelocs cast to fix the following sparse warning: i915_gem_execbuffer.c:1541:47: warning: cast removes address space of expression i915_gem_execbuffer.c:1541:62: warning: incorrect type in argument 2 (different address spaces) i915_gem_execbuffer.c:1541:62: expected void const [noderef] <asn:1>*from i915_gem_execbuffer.c:1541:62: got char * Cc: Chris Wilson <chris@chris-wilson.co.uk> Fixes: 2889caa9 ("drm/i915: Eliminate lots of iterations over the execobjects array") Signed-off-by:
-
Ville Syrjälä authored
Make the mode used for load detection const, and adjust all relevant functions to accept a const mode. Signed-off-by:
-
Chris Wilson authored
Sparse complains that these integers from which we form void __user *, and so we don't need the annotation itself inside the uABI. Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com>
-
Chris Wilson authored
Sparse enforces that GFP flags are only manipulated inside gfp_t locals. Fixes: 4d470f73 ("drm/i915: Avoid undefined behaviour of "u32 >> 32"") Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
- 04 Sep, 2017 6 commits
-
-
Jani Nikula authored
Catch up with upstream while it's easy. Signed-off-by: -
Ville Syrjälä authored
Don't cast away the __iomem from the io_mapping functions so that sparse won't be so unhappy when we pass the pointer to the unmap functions. Instead let's move the cast to where we actually use the pointer. Fixes the following sparse warnings: i915_gem.c:1022:33: warning: incorrect type in argument 1 (different address spaces) i915_gem.c:1022:33: expected void [noderef] <asn:2>*vaddr i915_gem.c:1022:33: got void *[assigned] vaddr i915_gem.c:1027:34: warning: incorrect type in argument 1 (different address spaces) i915_gem.c:1027:34: expected void [noderef] <asn:2>*vaddr i915_gem.c:1027:34: got void *[assigned] vaddr i915_gem.c:1199:33: warning: incorrect type in argument 1 (different address spaces) i915_gem.c:1199:33: expected void [noderef] <asn:2>*vaddr i915_gem.c:1199:33: got void *[assigned] vaddr i915_gem.c:1204:34: warning: incorrect type in argument 1 (different address spaces) i915_gem.c:1204:34: expected void [noderef] <asn:2>*vaddr i915_gem.c:1204:34: got void *[assigned] vaddr Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Ville Syrjälä authored
radix_tree_for_each_slot() wants an __rcu annotated pointer for the slot. So let's add the annotation. Fixes the following sparse warnings: i915_gem.c:2217:9: warning: incorrect type in assignment (different address spaces) i915_gem.c:2217:9: expected void **slot i915_gem.c:2217:9: got void [noderef] <asn:4>** i915_gem.c:2217:9: warning: incorrect type in assignment (different address spaces) i915_gem.c:2217:9: expected void **slot i915_gem.c:2217:9: got void [noderef] <asn:4>** i915_gem.c:2217:9: warning: incorrect type in argument 1 (different address spaces) i915_gem.c:2217:9: expected void [noderef] <asn:4>**slot i915_gem.c:2217:9: got void **slot i915_gem.c:2217:9: warning: incorrect type in assignment (different address spaces) i915_gem.c:2217:9: expected void **slot i915_gem.c:2217:9: got void [noderef] <asn:4>** Cc: Chris Wilson <chris@chris-wilson.co.uk> Fixes: 96d77634 ("drm/i915: Use a radixtree for random access to the object's backing storage") Signed-off-by:
-
Ville Syrjälä authored
Our fbdev setup requires the device to be awake for access through the GTT. If one boots without connected displays and later plugs one in, we won't have any runtime PM references when the fbdev setup runs. Explicitly grab a runtime PM reference during the fbdev setup to avoid the following spew: [ 62.518435] RPM wakelock ref not held during HW access [ 62.518459] ------------[ cut here ]------------ [ 62.518546] WARNING: CPU: 3 PID: 37 at ../drivers/gpu/drm/i915/intel_drv.h:1800 i915_vma_pin_iomap+0x144/0x150 [i915] [ 62.518585] Modules linked in: i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm intel_gtt agpgart netconsole nls_iso8859_1 nls_cp437 vfat fat efi_pstore coretemp hwmon intel_rapl x86_pkg_temp_thermal e1000e efivars ptp pps_core video evdev ip_tables x_tables ipv6 autofs4 [ 62.518741] CPU: 3 PID: 37 Comm: kworker/3:1 Not tainted 4.13.0-rc7-skl+ #1077 [ 62.518770] Hardware name: /NUC7i5BNB, BIOS BNKBL357.86A.0048.2017.0704.1415 07/04/2017 [ 62.518827] Workqueue: events i915_hotplug_work_func [i915] [ 62.518853] task: ffff88046c00dc00 task.stack: ffffc90000184000 [ 62.518896] RIP: 0010:i915_vma_pin_iomap+0x144/0x150 [i915] [ 62.518919] RSP: 0018:ffffc90000187cc8 EFLAGS: 00010292 [ 62.518942] RAX: 000000000000002a RBX: ffff880460044000 RCX: 0000000000000006 [ 62.518969] RDX: 0000000000000006 RSI: ffffffff819c3e6f RDI: ffffffff819f1c0e [ 62.518996] RBP: ffffc90000187cd8 R08: ffff88046c00e4f0 R09: 0000000000000000 [ 62.519022] R10: ffff8804669ca800 R11: 0000000000000000 R12: ffff880461d20000 [ 62.519049] R13: ffffc90000187d48 R14: ffff880461d20000 R15: ffff880460044000 [ 62.519076] FS: 0000000000000000(0000) GS:ffff88047ed80000(0000) knlGS:0000000000000000 [ 62.519107] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 62.519130] CR2: 000056478ae213f0 CR3: 0000000002c0f000 CR4: 00000000003406e0 [ 62.519156] Call Trace: [ 62.519190] intelfb_create+0x176/0x360 [i915] [ 62.519216] __drm_fb_helper_initial_config_and_unlock+0x1c7/0x3c0 [drm_kms_helper] [ 62.519251] drm_fb_helper_hotplug_event.part.18+0xac/0xc0 [drm_kms_helper] [ 62.519282] drm_fb_helper_hotplug_event+0x1a/0x20 [drm_kms_helper] [ 62.519324] intel_fbdev_output_poll_changed+0x1a/0x20 [i915] [ 62.519352] drm_kms_helper_hotplug_event+0x27/0x30 [drm_kms_helper] [ 62.519395] i915_hotplug_work_func+0x24e/0x2b0 [i915] [ 62.519420] process_one_work+0x1d3/0x6d0 [ 62.519440] worker_thread+0x4b/0x400 [ 62.519458] ? schedule+0x4a/0x90 [ 62.519475] ? preempt_count_sub+0x97/0xf0 [ 62.519495] kthread+0x114/0x150 [ 62.519511] ? process_one_work+0x6d0/0x6d0 [ 62.519530] ? kthread_create_on_node+0x40/0x40 [ 62.519551] ret_from_fork+0x27/0x40 [ 62.519569] Code: c4 78 e6 e0 0f ff e9 08 ff ff ff 80 3d d5 bc 0c 00 00 0f 85 0b ff ff ff 48 c7 c7 d8 50 32 a0 c6 05 c1 bc 0c 00 01 e8 9d 78 e6 e0 <0f> ff e9 f1 fe ff ff 0f 1f 44 00 00 0f 1f 44 00 00 0f b6 87 98 [ 62.519771] ---[ end trace 5fbe271f991a58ae ]--- Signed-off-by:
-
Changbin Du authored
In the past, vGPU alloc fence registers by walking through mm.fence_list to find fence which pin_count = 0 and vma is empty. vGPU may not find enough fence registers this way. Because a fence can be bind to vma even though it is not in using. We have found such failure many times these days. An option to resolve this issue is that we can force-remove fence from vma in this case. This patch added two new api to the fence management code: - i915_reserve_fence() will try to find a free fence from fence_list and force-remove vma if need. - i915_unreserve_fence() reclaim a reserved fence after vGPU has finished. With this change, the fence management is more clear to work with vGPU. GVTg do not need remove fence from fence_list in private. v3: (Chris) - Add struct_mutex lock assertion. - Only count for unpinned fence. v2: (Chris) - Rename the new api for symmetry. - Add safeguard to ensure at least 1 fence remained for host display. Signed-off-by:
Changbin Du <changbin.du@intel.com> Reviewed-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
-
Thierry Reding authored
The header comment in include/trace/define_trace.h specifies that the TRACE_INCLUDE_PATH needs to be relative to the define_trace.h header rather than the trace file including it. Most instances get that wrong and work around it by adding the $(src) directory to the include path. While this works, it is preferable to refer to the correct path to the trace file in the first place and avoid any workaround. Signed-off-by:
Thierry Reding <treding@nvidia.com> Acked-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
