- 30 Mar, 2019 1 commit
-
-
Robert M. Fosha authored
Currently we only retry to load GuC firmware if the load fails due to timeout. On Gen9 GuC loading may fail for different reasons, not just hang/timeout. Direction from the GuC team is to retry for all cases of GuC load failure on Gen9, not just for timeout. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108593Signed-off-by:
Robert M. Fosha <robert.m.fosha@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 29 Mar, 2019 5 commits
-
-
Chris Wilson authored
If drm_modeset_lock() reports a deadlock it sets the ctx->contexted field and insists that the caller calls drm_modeset_backoff() or else it generates a WARN on cleanup. <4> [1601.870376] WARNING: CPU: 3 PID: 8445 at drivers/gpu/drm/drm_modeset_lock.c:228 drm_modeset_drop_locks+0x35/0x40 <4> [1601.870395] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal i915 coretemp crct10dif_pclmul <6> [1601.870403] Console: switching <4> [1601.870403] snd_hda_intel <4> [1601.870406] to colour frame buffer device 320x90 <4> [1601.870406] crc32_pclmul snd_hda_codec snd_hwdep ghash_clmulni_intel e1000e snd_hda_core cdc_ether ptp usbnet mii pps_core snd_pcm i2c_i801 mei_me mei prime_numbers <4> [1601.870422] CPU: 3 PID: 8445 Comm: cat Tainted: G U 5.0.0-rc7-CI-CI_DRM_5650+ #1 <4> [1601.870424] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.2402.AD3.1810170014 10/17/2018 <4> [1601.870427] RIP: 0010:drm_modeset_drop_locks+0x35/0x40 <4> [1601.870430] Code: 29 48 8b 43 60 48 8d 6b 60 48 39 c5 74 19 48 8b 43 60 48 8d b8 70 ff ff ff e8 87 ff ff ff 48 8b 43 60 48 39 c5 75 e7 5b 5d c3 <0f> 0b eb d3 0f 1f 80 00 00 00 00 41 56 41 55 41 54 55 53 48 8b 6f <4> [1601.870432] RSP: 0018:ffffc90000d67ce8 EFLAGS: 00010282 <4> [1601.870435] RAX: 00000000ffffffdd RBX: ffffc90000d67d00 RCX: 5dbbe23d00000000 <4> [1601.870437] RDX: 0000000000000000 RSI: 0000000093e6194a RDI: ffffc90000d67d00 <4> [1601.870439] RBP: ffff88849e62e678 R08: 0000000003b7329a R09: 0000000000000001 <4> [1601.870441] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888492100410 <4> [1601.870442] R13: ffff88849ea50958 R14: ffff8884a67eb028 R15: ffff8884a67eb028 <4> [1601.870445] FS: 00007fa7a27745c0(0000) GS:ffff8884aff80000(0000) knlGS:0000000000000000 <4> [1601.870447] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [1601.870449] CR2: 000055af07e66000 CR3: 00000004a8cc2006 CR4: 0000000000760ee0 <4> [1601.870451] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4> [1601.870453] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 <4> [1601.870454] PKRU: 55555554 <4> [1601.870456] Call Trace: <4> [1601.870505] i915_dsc_fec_support_show+0x91/0x190 [i915] <4> [1601.870522] seq_read+0xdb/0x3c0 <4> [1601.870531] full_proxy_read+0x51/0x80 <4> [1601.870538] __vfs_read+0x31/0x190 <4> [1601.870546] ? __se_sys_newfstat+0x3c/0x60 <4> [1601.870552] vfs_read+0x9e/0x150 <4> [1601.870557] ksys_read+0x50/0xc0 <4> [1601.870564] do_syscall_64+0x55/0x190 <4> [1601.870569] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4> [1601.870572] RIP: 0033:0x7fa7a226d081 <4> [1601.870574] Code: fe ff ff 48 8d 3d 67 9c 0a 00 48 83 ec 08 e8 a6 4c 02 00 66 0f 1f 44 00 00 48 8d 05 81 08 2e 00 8b 00 85 c0 75 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 57 f3 c3 0f 1f 44 00 00 41 54 55 49 89 d4 53 <4> [1601.870576] RSP: 002b:00007ffcc05140c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 <4> [1601.870579] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007fa7a226d081 <4> [1601.870581] RDX: 0000000000020000 RSI: 000055af07e63000 RDI: 0000000000000007 <4> [1601.870583] RBP: 0000000000020000 R08: 000000000000007b R09: 0000000000000000 <4> [1601.870585] R10: 000055af07e60010 R11: 0000000000000246 R12: 000055af07e63000 <4> [1601.870587] R13: 0000000000000007 R14: 000055af07e634bf R15: 0000000000020000 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109745 Fixes: e845f099 ("drm/i915/dsc: Add Per connector debugfs node for DSC support/enable") Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190329165152.29259-1-chris@chris-wilson.co.uk
-
Uma Shankar authored
EXT2 GC MAX registers are introduced from Gen10+ to program values from 3.0 to 7.0. Enabled the same, but currently limiting it to 1.0 as userspace ABI is limited at that currently. v2: Updated the 1.0 programming and aligned as per GLK, also added GLK along with GEN10+ check, as per Ville's feedback. Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1553869756-4546-3-git-send-email-uma.shankar@intel.com
-
Uma Shankar authored
GC MAX register is used to program values from 1.0 to less than 3.0. A different register was used instead of the intended one. Fixed the same. Currently limiting it to 1.0 due to ABI limitations. v2: Updated the 1.0 programming and aligned as per GLK, based on Ville's feedback. Reported-by:
-
Daniele Ceraolo Spurio authored
Those functions are used on gen4 as well and gen4 does have a non-RCS engine, so remove the BUG_ON and flip back the logic to what it was before the ENGINE_READ/WRITE update v2: update the posting read as well (Chris, Ville). Fixes: baba6e57 ("drm/i915: take a reference to uncore in the engine and use it") Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Daniele Ceraolo Spurio authored
edram is not part of uncore and there is no requirement for the detection to be done before we initialize the uncore functions. The first check on HAS_EDRAM is in the ggtt_init path, so move it to i915_driver_init_hw, where other dram-related detection happens. While at it, save the size in MB instead of the capabilities because the size is the only thing we look at outside of the init function. Signed-off-by:
-
- 28 Mar, 2019 13 commits
-
-
Ville Syrjälä authored
Don't load the linear degamma LUT on ICL. The hardware no longer has any silly linkages between the CSC enable and degamma LUT enable so the degamma LUT is only needed when it's actually enabled. Also add comments to explain the situation on GLK. v2: Drop useless parens around 1<<16 v3: Add missing const Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190327155045.28446-11-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
We now bypass the legacy LUT when it's not needed, so no point in filling it up with a linear LUT. Signed-off-by:
-
Ville Syrjälä authored
With everything else moved out of the way only ilk+ remains using _intel_color_check(). Streamline the logic into ilk_color_check(). v2: Add some comments explaining we that we don't expose the full hardware capabilities currently (Matt) Signed-off-by: -
Ville Syrjälä authored
Provide a separate .color_check() for BDW+ where we currently provide the split gamma mode etc. Signed-off-by:
-
Ville Syrjälä authored
Unlike the earlier platforms GLK has dedicated degamma and gamma LUTs. And quite curiously the degamma LUT is actually controlled via the PLANE_COLOR_CTL CSC enable bit. Hence we must compute gamma_enable and csc_enable differently to pre-GLK platforms. Signed-off-by:
-
Ville Syrjälä authored
ICL is rather easy when it comes to .color_check() as it finally provides us with a full color pipeline with individual knobs for each stage. We'll also start bypassing each LUT individually when it is not needed. Signed-off-by:
-
Ville Syrjälä authored
Since CHV has the CGM unit we require a custom implementation of .color_check(). This fixes the computation of gamma_enable as previously we left it enabled even when were using the CGM gamma instead. Now we turn off the legacy LUT unless it's actually required. v2: Add some comment explaining the color pipeline (Matt) Signed-off-by:
-
Ville Syrjälä authored
Apart from CHV the other gmch platforms don't currently require much work in .color_check(). So let's start by extracting i9xx_color_check(). Signed-off-by:
-
Ville Syrjälä authored
The current intel_color_check() is a mess, and worse yet it is in fact incorrect for several platforms. The hardware has evolved quite a bit over the years, so let's just go for a clean split between the platforms by turning this into a vfunc. The actual work to split it up will follow. v2: Assign the vfuncs in the order they appear in the struct (Matt) Signed-off-by: -
Ville Syrjälä authored
In prepartion for per-platform color_check() functions extract the common code into a separate function. v2: Improve the C8 comment (Matt) Signed-off-by:
-
Joonas Lahtinen authored
Signed-off-by:Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Joonas Lahtinen authored
Signed-off-by: -
Joonas Lahtinen authored
Signed-off-by:
-
- 27 Mar, 2019 13 commits
-
-
Maarten Lankhorst authored
90/270 rotation is not supported for Y21x and the 12/16 bits XVYU formats, reject support for them. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190322135954.20434-3-maarten.lankhorst@linux.intel.comReviewed-by:
-
Maarten Lankhorst authored
This was missing in the original addition of those formats, but in PLANE_SIZE description it's mentioned that 8 cpp formats are not valid with Yf tiling. Reject this case properly. Also reject Y21x Yf tiling support this is also not supported. Changes since v1: - Reject Y21x as well. Signed-off-by:
-
Maarten Lankhorst authored
Y41x formats is a 4:4:4 format, so it can be addressed with pixel level accuracy. Meanwhile it seems that while rotating YUYV 4:2:2 formats need a multiple of 2 for width and height, otherwise corruption occurs. For YUV 4:2:2, the spec says that w/h should always be even, but we get away with odd height while unrotated. When rotating it seems corruption occurs with an odd x/y, and w/h should always be even. Just to be completely paranoid, reject odd x/y w/h when rotating 90/270. Signed-off-by:
-
Joonas Lahtinen authored
This is needed to get the fourcc code merged without conflicts. Signed-off-by: -
Chris Wilson authored
The intent was to expose these as part of the means to perform full context recovery (though not the SINGLE_TIMELINE, that is for later and just sucked as collateral damage). As that requires a couple more patches to complete the series, roll back the earlier chunks of ABI for an intervening PR. We keep all the internals intact and under selftests. Signed-off-by:
-
Zhenyu Wang authored
This is to disable semaphore usage when on vGPU for now. Unfortunately GVT-g hasn't fully enabled semaphore usage yet, so current guest with semaphore use would cause vGPU failure. Although current semaphore failure with vGPU can be simply resolved by allowing cmd parser to accept MI_SEMAPHORE_WAIT command with address audit, we're checking general usage of semaphore and how we should handle it properly for virtualization in consider of function and security concern. So we decide to request to disable it for now in guest driver. Once GVT could support it, we would add new compat bit to turn it on. Fixes: e8861964 ("drm/i915: Use HW semaphores for inter-engine synchronisation on gen8+") #vgpu Cc: Kevin Tian <kevin.tian@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Acked-by:
-
Ville Syrjälä authored
Update the DP MSA MISC bits for fastsets. This is needed when we change between limited and full range RGB output. On HSW+ changing limited_range does not currently result in a full modeset since we have don't have the readout code for it (for DP we could, and probably should, readout from TRANS_MSA_MISC itself, for HDMI we would have to rely on the infoframe). So the PIPE_CONF_CHECK() is only performed for pre-HSW platforms. That means any change in the value will result in a fastset instead. Fortunately there is no prohibition to changing TRANS_MSA_MISC dynamically, so it looks like we can legally do fastsets for this. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190326142556.21176-5-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
Allow the user to limit the output bpc with DP MST. Signed-off-by:
-
Ville Syrjälä authored
Allow DP MST to output any color depth. This means deep color as well as falling back to 6bpc if we would otherwise require too much bandwidth. TODO: We should probably extend bw_contstrained scheme to force all streams on the link to 6bpc if we can't fit the new stream(s) otherwise. v2: Use a proper for-loop (Jani) Signed-off-by:
-
Ville Syrjälä authored
We already expose the force_audio property with SST. Do the same with MST. Signed-off-by:
-
Ville Syrjälä authored
Add the "Broadcast RGB" property to MST connectors, and implement the same logic for it as we have in the SST code. v2: Extract and reuse intel_dp_limited_color_range() Cc: Ivan Vlk <ari@adyline.sk> Tested-by:
Ivan Vlk <ari@adyline.sk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108821Signed-off-by:
-
José Roberto de Souza authored
GT VEBOX DISABLE is only 4 bits wide but it was using a 8 bits wide mask, the remaning reserved bits is set to 0 causing 4 more nonexistent VEBOX engines being detected as enabled, triggering the BUG_ON() because of mismatch between vebox_mask and newly added VEBOX_MASK(). [ 64.081621] [drm:intel_device_info_init_mmio [i915]] vdbox enable: 0005, instances: 0005 [ 64.081763] [drm:intel_device_info_init_mmio [i915]] vebox enable: 00f1, instances: 0001 [ 64.081825] intel_device_info_init_mmio:925 GEM_BUG_ON(vebox_mask != ({ unsigned int first__ = (VECS0); unsigned int count__ = (2); ((&(dev_priv)->__info)->engine_mask & (((~0UL) - (1UL << (first__)) + 1) & (~0UL >> (64 - 1 - (first__ + count__ - 1))))) >> first__; })) [ 64.082047] ------------[ cut here ]------------ [ 64.082054] kernel BUG at drivers/gpu/drm/i915/intel_device_info.c:925! BSpec: 20680 Fixes: 9511cb64 ("drm/i915: Adding missing '; ' to ENGINE_INSTANCES") Fixes: 26376a7e ("drm/i915/icl: Check for fused-off VDBOX and VEBOX instances") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by:José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
When building with ARCH=i386, readq and writeq are not defined, resulting in: intel_uncore.h: In function ‘__raw_uncore_read64’: intel_uncore.h:257:9: error: implicit declaration of function ‘readq’; did you mean ‘readl’? [-Werror=implicit-function-declaration] return read##s__(uncore->regs + i915_mmio_reg_offset(reg)); \ ^ and: intel_uncore.h: In function ‘__raw_uncore_write64’: intel_uncore.h:264:2: error: implicit declaration of function ‘writeq’; did you mean ‘writel’? [-Werror=implicit-function-declaration] write##s__(val, uncore->regs + i915_mmio_reg_offset(reg)); \ ^ Add the io-64-nonatomic-lo-hi include to have readq and writeq available for all builds. This header internally includes linux/io.h, so the native readq and writeq definitions will be used when available. Fixes: 6cc5ca76 ("drm/i915: rename raw reg access functions") Signed-off-by:
-
- 26 Mar, 2019 8 commits
-
-
Chris Wilson authored
Tvrtko spotted that I left off the trailing ';'. It went unnoticed by CI because despite adding the macro, we didn't add a user, so include one as well (a simple debug print). Reported-by:
-
Michał Winiarski authored
Since GEM_CREATE is trying to outsmart the user by rounding up unaligned objects, we used to update the size returned to userspace. This update seems to have been lost throughout the history. v2: Use round_up(), reorder locals (Chris) References: ff72145b ("drm: dumb scanout create/mmap for intel/radeon (v3)") Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Janusz Krzysztofik <janusz.krzysztofik@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
-
Daniele Ceraolo Spurio authored
A few advantages: - Prepares us for the planned split of display uncore from GT uncore - Improves our engine-centric view of the world in the engine code and allows us to avoid jumping back to dev_priv. - Allows us to wrap accesses to engine register in nice macros that automatically pick the right mmio base. Signed-off-by:
-
Daniele Ceraolo Spurio authored
The intel_uncore structure is the owner of register access, so subclass the function to it. While at it, use a local uncore var and switch to the new read/write functions where it makes sense. Signed-off-by:
-
Daniele Ceraolo Spurio authored
The intel_uncore structure is the owner of register access, so subclass the function to it. While at it, use a local uncore var and switch to the new read/write functions where it makes sense. Signed-off-by:
-
Daniele Ceraolo Spurio authored
The intel_uncore structure is the owner of FW, so subclass the function to it. While at it, use a local uncore var and switch to the new read/write functions where it makes sense. Signed-off-by:
-
Daniele Ceraolo Spurio authored
The full read/write ops can now work on the intel_uncore struct. Introduce intel_uncore_read/write functions working on intel_uncore and switch the I915_READ/WRITE macro to internally call those. v2: no change v3: add intel_uncore_read/write functions (Chris), update commit msg Signed-off-by:
-
Daniele Ceraolo Spurio authored
Remove a bit of pointer dancing in the reg access path. Signed-off-by:
-
