summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2017-09-06drm/i915: Move device_info.has_snoop into the static tablesChris Wilson
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 <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170906105653.3665-1-chris@chris-wilson.co.uk
2017-09-06drm/i915: Disable MI_STORE_DATA_IMM for i915g/i915gmChris Wilson
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 <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20170906152859.5304-1-chris@chris-wilson.co.uk
2017-09-06drm/i915: Re-enable GTT following a device resetChris Wilson
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 5fbd0418eef2 ("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: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: 5fbd0418eef2 ("drm/i915: Re-enable GGTT earlier during resume on pre-gen6 platforms") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101852 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170906111405.27110-1-chris@chris-wilson.co.uk Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2017-09-05drm/i915/cnp: Wa 1181: Fix Backlight issueRodrigo Vivi
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170831045223.3960-1-rodrigo.vivi@intel.com
2017-09-05drm/i915: Annotate user relocs with __userVille Syrjälä
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: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170901165434.24636-1-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
2017-09-05drm/i915: Constify load detect modeVille Syrjälä
Make the mode used for load detection const, and adjust all relevant functions to accept a const mode. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170518193837.393-2-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-09-05drm/i915/perf: Remove __user from u64 in drm_i915_perf_oa_configChris Wilson
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: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170901145729.21363-2-chris@chris-wilson.co.uk Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
2017-09-05drm/i915: Silence sparse by using gfp_tChris Wilson
Sparse enforces that GFP flags are only manipulated inside gfp_t locals. Fixes: 4d470f7359c4 ("drm/i915: Avoid undefined behaviour of "u32 >> 32"") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170901145729.21363-1-chris@chris-wilson.co.uk Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2017-09-04Merge drm-upstream/drm-next into drm-intel-next-queuedJani Nikula
Catch up with upstream while it's easy. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-09-04drm/i915: io unmap functions want __iomemVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170901171252.31025-2-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2017-09-04drm/i915: Add __rcu to radix tree slot pointerVille Syrjälä
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: 96d776345277 ("drm/i915: Use a radixtree for random access to the object's backing storage") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170901171252.31025-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2017-09-04drm/i915: Wake up the device for the fbdev setupVille Syrjälä
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170901195456.6386-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2017-09-04drm/i915: Add interface to reserve fence registers for vGPUChangbin Du
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: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/1504512061-5892-1-git-send-email-changbin.du@intel.com Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2017-09-04drm/i915: Use correct path to trace includeThierry Reding
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: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170901144954.19620-4-thierry.reding@gmail.com
2017-09-01drm/i915: Fix the missing PPAT cache attributes on CNLZhi Wang
Add back the GEN8_PPAT_WB cache attributes in cnl_setup_private_ppat(), which are missed on CNL. Fixes: 4e34935fcf69 ("drm/i915/cnl: Setup PAT Index.") Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Suggested-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1504208177-27784-1-git-send-email-zhi.a.wang@intel.com
2017-09-01drm/i915: Fix enum pipe vs. enum transcoder for the PCH transcoderVille Syrjälä
Use enum pipe for PCH transcoders also in the FIFO underrun code. Fixes the following new sparse warnings: intel_fifo_underrun.c:340:49: warning: mixing different enum types intel_fifo_underrun.c:340:49: int enum pipe versus intel_fifo_underrun.c:340:49: int enum transcoder intel_fifo_underrun.c:344:49: warning: mixing different enum types intel_fifo_underrun.c:344:49: int enum pipe versus intel_fifo_underrun.c:344:49: int enum transcoder intel_fifo_underrun.c:397:57: warning: mixing different enum types intel_fifo_underrun.c:397:57: int enum pipe versus intel_fifo_underrun.c:397:57: int enum transcoder intel_fifo_underrun.c:398:17: warning: mixing different enum types intel_fifo_underrun.c:398:17: int enum pipe versus intel_fifo_underrun.c:398:17: int enum transcoder Cc: Matthias Kaehlcke <mka@chromium.org> Fixes: a21960339c8c ("drm/i915: Consistently use enum pipe for PCH transcoders") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170901143123.7590-3-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2017-09-01drm/i915: Make i2c lock ops staticVille Syrjälä
Make gmbus_lock_ops and proxy_lock_ops static to appease sparse intel_i2c.c:652:34: warning: symbol 'gmbus_lock_ops' was not declared. Should it be static? intel_sdvo.c:2981:34: warning: symbol 'proxy_lock_ops' was not declared. Should it be static? Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Fixes: a85066840d29 ("drm/i915: Rework sdvo proxy i2c locking") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170901143123.7590-2-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2017-09-01drm/i915: Make i9xx_load_ycbcr_conversion_matrix() staticVille Syrjälä
Make i9xx_load_ycbcr_conversion_matrix() static to appease sparse: intel_color.c:110:6: warning: symbol 'i9xx_load_ycbcr_conversion_matrix' was not declared. Should it be static? Cc: Shashank Sharma <shashank.sharma@intel.com> Fixes: 25edf91501b8 ("drm/i915: prepare csc unit for YCBCR420 output") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170901143123.7590-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2017-09-01drm/i915: Eliminate crtc->state usage from intel_atomic_commit_tail and ↵Ville Syrjälä
.crtc_update() We already have the correct new crtc state so just use that instead of crtc->state. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170823152226.22938-7-ville.syrjala@linux.intel.com
2017-09-01drm/i915: Eliminate crtc->state usage from intel_update_pipe_config()Ville Syrjälä
Pass the correct new crtc state to intel_update_pipe_config() instead of using crtc->state. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170823152226.22938-6-ville.syrjala@linux.intel.com
2017-09-01drm/i915: Eliminate obj->state usage from pre/post plane updateVille Syrjälä
Dig up the appropriate new crtc and plane states from the top level atomic state in intel_pre_plane_update() and intel_post_plane_update(). Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170823152226.22938-5-ville.syrjala@linux.intel.com
2017-09-01drm/i915: Pass proper old/new states to intel_plane_atomic_check_with_state()Ville Syrjälä
Eliminate plane->state and crtc->state usage from intel_plane_atomic_check_with_state() and its callers. Instead pass the proper states in or dig them up from the top level atomic state. Note that intel_plane_atomic_check_with_state() itself isn't allowed to use the top level atomic state as there is none when it gets called from the legacy cursor short circuit path. v2: Rename some variables for easier comprehension (Maarten) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170823152226.22938-4-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2017-09-01drm/i915: rework IS_*_GT* macrosLionel Landwerlin
We can now make use of the intel_device_info.gt field. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20170830161208.29221-4-lionel.g.landwerlin@intel.com
2017-09-01drm/i915: mark all device info struct with __initconstLionel Landwerlin
As recommended by Chris. v2: Switch from __initdata to __initconst. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20170830161208.29221-3-lionel.g.landwerlin@intel.com
2017-09-01drm/i915: add GT number to intel_device_infoLionel Landwerlin
Up to Coffeelake we could deduce this GT number from the device ID. This doesn't seem to be the case anymore. This change reorders pciids per GT and adds a gt field to intel_device_info. We set this field on the following platforms : - SNB/IVB/HSW/BDW/SKL/KBL/CFL/CNL Before & After : $ modinfo drivers/gpu/drm/i915/i915.ko | grep ^alias | wc -l 209 v2: Add SNB & IVB (Chris) v3: Fix compilation error in early-quirks (Lionel) v4: Fix inconsistency between FEATURE/PLATFORM macros (Ville) Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20170830161208.29221-2-lionel.g.landwerlin@intel.com
2017-08-31drm/i915/edp: Increase T12 panel delay to 900 ms to fix DP AUX CH timeoutsManasi Navare
This patch fixes the DP AUX CH timeouts observed during CI runs causing CI Failures on a specific PCI device. This issue was fixed previously by adding a quirk but looks like we need to increase this delay even more in order to get rid all the DP AUX CH timeouts. Fixes: c99a259b4b5192ba ("drm/i915/edp: Add a T12 panel delay quirk to fix DP AUX CH timeouts") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101144 Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Cc: Clinton Taylor <clinton.a.taylor@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Tomi Sarvela <tomi.p.sarvela@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1502823591-25310-1-git-send-email-manasi.d.navare@intel.com
2017-08-31drm/i915: Eliminate obj->state usage in g4x/vlv/chv wm computationVille Syrjälä
Use explicit old/new states instead of relying on obj->state. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170823152226.22938-4-ville.syrjala@linux.intel.com
2017-08-31drm/i915: Pass the crtc state explicitly to intel_pipe_update_start/end()Ville Syrjälä
Pass the appropriate new crtc state explicitly to intel_pipe_update_start/end() instead of of mucking around with crtc->state. v2: The mmio flip stuff is gone Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #v1 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170823152226.22938-2-ville.syrjala@linux.intel.com
2017-08-31drm/i915: Pass the new crtc state to color management codeVille Syrjälä
In an effort to eliminate the obj->state usage let's pass on the new crtc state pointer (which we already have!) to the color management code. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170823152226.22938-1-ville.syrjala@linux.intel.com
2017-08-31drm/i915: Consolidate max_cdclk_freq check in intel_crtc_compute_min_cdclk()Ville Syrjälä
Currently the .modeset_calc_cdclk() hooks check the final cdclk value against the max allowed. That's not really sufficient since the low level calc_cdclk() functions effectively clamp the minimum required cdclk to the max supported by the platform. Hence if the minimum required exceeds the platforms capabilities we'd keep going anyway using the max cdclk frequency. To fix that let's move the check earlier into intel_crtc_compute_min_cdclk() and we'll check the minimum required cdclk of the pipe against the maximum supported by the platform. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170710193347.8734-2-ville.syrjala@linux.intel.com Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
2017-08-31drm/i915: Track minimum acceptable cdclk instead of "minimum dotclock"Ville Syrjälä
Make the min_pixclk thing less confusing by changing it to track the minimum acceptable cdclk frequency instead. This means moving the application of the guardbands to a slightly higher level from the low level platform specific calc_cdclk() functions. The immediate benefit is elimination of the confusing 2x factors on GLK/CNL+ in the audio workarounds (which stems from the fact that the pipes produce two pixels per clock). v2: Keep cdclk higher on CNL to workaround missing DDI clock voltage handling v3: Squash with the CNL cdclk limits patch (DK) v4: s/intel_min_cdclk/intel_pixel_rate_to_cdclk/ (DK) Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170830185703.8189-1-ville.syrjala@linux.intel.com
2017-08-31drm/i915/cnl: Fix DP max voltageRodrigo Vivi
On clock recovery this function is called to find out the max voltage swing level that we could go. However gen 9 functions use the old buffer translation tables to figure that out. That table is not valid for CNL causing an invalid number of entries and an invalid selection on the max voltage swing level. v2: Let's use same approach that previous platforms. v3: Actually use n_entries and avoid duplicated -1. v4: Avoid cnl_max_level and use current style. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170831145356.15932-1-rodrigo.vivi@intel.com
2017-08-31drm/i915/cnl: Fix DDI hdmi level selection.Rodrigo Vivi
Let's get a proper HDMI DDI entry level for vswing programming sequences on CNL. Spec doesn't specify any default for HDMI tables, so let's pick the last entry as the default for now. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170829232230.23051-7-rodrigo.vivi@intel.com
2017-08-31drm/i915/cnl: Move ddi buf trans related functions up.Rodrigo Vivi
No functional changes. But those functions will be needed to get max level for HDMI and DP, so let's move those up closer to other similar functions existent for previous platforms. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170829232230.23051-6-rodrigo.vivi@intel.com
2017-08-31drm/i915/cnl: Move voltage check into ddi buf trans functions.Rodrigo Vivi
Let's start converging CNL buf translations to same style used on previous platforms. So first thing is to use the standard signature so we don't need to propagate the voltage check into other parts of the code, but only on the parts that it is really useful. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170829232230.23051-5-rodrigo.vivi@intel.com
2017-08-31drm/i915: Enable voltage swing before enabling DDI_BUF_CTL.Rodrigo Vivi
Sequences for DisplayPort asks us to " Configure voltage swing and related IO settings. Refer to DDI Buffer section." before "Configure and enable DDI_BUF_CTL" On BXT and CNL this means to execute the ddi vswing sequences. At this point these sequences calls are getting duplicated for DP because they are all called from DP link trainning sequences. However this patch is not yet removing it before a futher discussion since spec also allows that during link training without disabling anything: " Notes Changing voltage swing during link training: Change the swing setting following the DDI Buffer section. The port does not need to be disabled. " Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170829232230.23051-4-rodrigo.vivi@intel.com
2017-08-31drm/i915: Align vswing sequences with old ddi buffer registers.Rodrigo Vivi
Vswing sequences on BXT and CNL are equivalent to the ddi buffer registers setting on other platforms. For some reason it got aligned with skl_ddi_set_iboost what is semantically incorrect. This forced us to keep skipping ddi buffer translation tables on the platforms that has the vswing sequences. v2: Don't mess with DP signal levels on this patch. Cc: Vandana Kannan <vandana.kannan@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170829232230.23051-3-rodrigo.vivi@intel.com
2017-08-31drm/i915: decouple gen9 and gen10 dp signal levels.Rodrigo Vivi
Let's decouple bxt, glk and cnl dp signal levels from other DDIs to avoid confusion. No functional change. Only a reorg to avoid messing with currently working DP signal levels when moving voltage swing sequences around to match spec. v2: ddi_signal_levels is also called from other ddi platforms, so don't remove IS_GEN9_BC check from skl_ddi_set_iboos. (Ville). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170829232230.23051-2-rodrigo.vivi@intel.com
2017-08-31drm/i915: Introduce intel_ddi_dp_level.Rodrigo Vivi
No functional changes. This only moves the DP level selection to a separated function that will be later used to organize better the vswing sequences. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170829232230.23051-1-rodrigo.vivi@intel.com
2017-08-31drm/i915/cnl: Avoid ioremap_wc on Cannonlake as well.Rodrigo Vivi
Driver’s CPU access to GTT is via the GTTMMADR BAR. The current HW implementation of that BAR is to only support <= DW (and maybe QW) writes—not 16/32/64B writes that could occur with WC and/or SSE/AVX moves. GTTMMADR must be marked uncacheable (UC). Accesses to GTTMMADR(GTT), must be 64 bits or less (ie. 1 GTT entry). v2: Get clarification on the reasons and spec is getting updated to reflect it now. Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Suggested-by: Ben Widawsky <benjamin.widawsky@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170829230907.21363-1-rodrigo.vivi@intel.com
2017-08-30drm/i915/cnl: WaDisableI2mCycleOnWRPortRodrigo Vivi
On CNL B0 stepping GAM is not able to detect some deadlock condition and then rise the rise the gam_coh_flush. WA database and spec both mentions to set 4AB8[24]=1 as workaround. Although register offset 0x4AB8 is not documented for any platform. References: HSD#1945815, BSID#1112 Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170829230751.21047-1-rodrigo.vivi@intel.com
2017-08-30drm/i915/cnl: WA FtrEnableFastAnisoL1BankingFixRodrigo Vivi
WA to enable HW L1 Banking fix that allows aniso to operate at full sample rate. References: HSD#1937670 Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Anuj Phogat <anuj.phogat@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170829230723.20898-1-rodrigo.vivi@intel.com
2017-08-30drm/i915: Stop using long platform names on clock gating functions.Rodrigo Vivi
No functional changes. Our code was only a bit messy with mixed style there so let's clean up a bit using the short codenames for the platforms. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170829052026.15038-1-rodrigo.vivi@intel.com
2017-08-30drm/i915: Skip fence alignemnt check for the CCS planeVille Syrjälä
The CCS won't have the same stride as the main surface anyway so trying to guard against the fence stride not matching the CCS stride is not sensible. Just skip the fence vs. fb alignment check for the aux plane. Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Daniel Stone <daniels@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170824191100.10949-3-ville.syrjala@linux.intel.com Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Fixes: 2e2adb05736c ("drm/i915: Add render decompression support") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2017-08-30drm/i915: Treat fb->offsets[] as a raw byte offset instead of a linear offsetVille Syrjälä
Userspace wants to treat fb->offsets[] as raw byte offsets into the gem bo. Adjust the kernel code to match. Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Daniel Stone <daniels@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170824191100.10949-2-ville.syrjala@linux.intel.com Acked-by: Ben Widawsky <ben@bwidawsk.net> Fixes: 2e2adb05736c ("drm/i915: Add render decompression support") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2017-08-30drm/i915: Always wake the device to flush the GTTChris Wilson
Since we hold the device wakeref when writing through the GTT (otherwise the writes would fail), we presumed that before the device sleeps those writes would naturally be flushed and that we wouldn't need our mmio read trick. However, that presumption seems false and a sleepy bxt seems to require us to always manually flush the GTT writes prior to direct access. Fixes: e2a2aa36a509 ("drm/i915: Check we have an wake device before flushing GTT writes") 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/20170829192546.1087-1-chris@chris-wilson.co.uk
2017-08-29drm/i915: Discard the request queue if we fail to sleep before suspendChris Wilson
If we fail to clear the outstanding request queue before suspending, mark those requests as lost. References: https://bugs.freedesktop.org/show_bug.cgi?id=102037 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170826110935.10237-3-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
2017-08-29drm/i915: Clear wedged status upon resumeChris Wilson
When we wake up from suspend, the device has been powered down and should come back afresh. We should be able to safely remove the wedged status from the previous session and start afresh. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170826110935.10237-2-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
2017-08-29drm/i915: Always sanity check engine state upon idlingChris Wilson
When we do a locked idle we know that afterwards all requests have been completed and the engines have been cleared of tasks. For whatever reason, this doesn't always happen and we may go into a suspend with ELSP still full, and this causes an issue upon resume as we get very, very confused. If the engines refuse to idle, mark the device as wedged. In the process we get rid of the maybe unused open-coded version of wait_for_engines reported by Nick Desaulniers and Matthias Kaehlcke. v2: Suppress the -EIO before suspend, but keep it for seqno wrap. References: https://bugs.freedesktop.org/show_bug.cgi?id=101891 References: https://bugs.freedesktop.org/show_bug.cgi?id=102456 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Matthias Kaehlcke <mka@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20170826110935.10237-1-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
2017-08-29drm/i915: Don't use GPU relocations prior to cmdparser stallsChris Wilson
If we are using the cmdparser, we will have to copy the batch and so stall for the relocations. Rather than prolong that stall by adding more relocation requests, just use CPU relocations and do the stall upfront. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170826135620.25949-1-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>